Mekovault
Empezar gratis

Políticas de Seguridad

Vigencia: 2026 · Última revisión: 31 de agosto de 2026

Mekovault gestiona el ciclo de vida de identidades en Google Workspace, Microsoft Entra y otros directorios corporativos. Para funcionar, recibe credenciales muy sensibles (Service Accounts, App Registrations con permisos de administración global). Este documento describe cómo las almacenamos, cómo las usamos, y cómo el Cliente puede auditar cada uso.

Está redactado como referencia para equipos de seguridad, auditores y compradores enterprise. Complementa —no reemplaza— la Política de Privacidad, los Términos y el DPA.

1. Alcance

Estas políticas aplican a toda credencial que el Cliente entrega a Mekovault para operar sobre su directorio corporativo, incluyendo pero no limitado a:

  • Google Workspace: archivo JSON de Service Account con Domain-Wide Delegation.
  • Microsoft Entra ID (Azure AD): Client Secret y Client/Tenant ID de una App Registration con Application permissions.
  • Cualquier otra credencial de integración con Okta, JumpCloud, HRIS o IdP futuro que Mekovault soporte.

2. Arquitectura de almacenamiento

2.1 Separación física de secretos y metadatos

Ninguna credencial se almacena en la base de datos relacional de Mekovault. La arquitectura separa dos planos:

  • Plano de metadatos (PostgreSQL, host mekovault-data): solo guarda un puntero al secreto (nombre de la clave dentro del vault), el proveedor, el dominio primario, timestamps y resultados del último health check. Row-Level Security por company_id.
  • Plano de secretos (Infisical, host mekovault-vault): instancia auto-hospedada de Infisical en red privada Tailscale, no expuesta a Internet público. Contiene los valores reales (JSON completo del SA, secretos de la App).

Un bug o compromiso del servicio de metadatos no expone credenciales: los secretos requieren autenticación aparte contra Infisical mediante una identidad de máquina distinta.

2.2 Aislamiento por tenant (multi-tenancy hard)

Cada tenant recibe un proyecto Infisical dedicado (ejemplo: setting-cl-415514, mmglatam-com-872039). Los secretos nunca se comparten. Consecuencia:

  • El radio de impacto de cualquier falla en el código de Mekovault que construya mal la referencia al proyecto está limitado al mismo tenant: no puede leer, listar ni tocar secretos de otros clientes.
  • Las políticas de acceso de Infisical rechazan solicitudes a proyectos para los que la identidad de máquina de Mekovault no tiene permiso, aunque los conozca por nombre.

2.3 Cifrado

  • En tránsito: TLS 1.2+ obligatorio en todas las conexiones (HTTPS del portal, PostgreSQL con SSL, canal Mekovault → Infisical, canal Mekovault → Google/Microsoft). No aceptamos conexiones no cifradas.
  • En reposo: los secretos se cifran en Infisical con la clave maestra del vault (AES-256-GCM); el volumen del vault se cifra a nivel de disco (LUKS / EBS encryption). PostgreSQL corre con cifrado de disco.
  • Rotación de claves de servicio: las llaves de firma de JWT y las credenciales de la identidad de máquina de Infisical se rotan al menos cada 12 meses y ante cualquier evento de compromiso sospechado.

2.4 Red y perímetro

  • Todas las máquinas del backend (mekovault-app, mekovault-data, mekovault-obs, mekovault-vault) están conectadas por Tailscale sobre WireGuard.
  • mekovault-vault no tiene IP pública ni puerto abierto a Internet. Solo escucha en la interfaz privada Tailscale. Ni siquiera desde el frontend público (Vercel) se puede alcanzar directamente.
  • El acceso administrativo por parte del equipo de Mekovault requiere Tailscale con MFA + clave SSH gestionada. Sin credenciales personales SSH root en ningún host.

3. Uso de las credenciales

3.1 Principio de mínimo privilegio en la solicitud

Al conectar el directorio, Mekovault solicita exactamente los scopes que necesita, ni uno más. Publicamos la lista completa en la guía del Wizard de conexión y la reproducimos acá:

Google Workspace — Domain-Wide Delegation

  • admin.directory.user — crear, suspender, reactivar, modificar usuarios.
  • admin.directory.user.security — reset de contraseña y cierre de sesiones activas (SSO revocation).
  • admin.directory.orgunit — mover usuarios entre OU durante onboarding/offboarding.
  • admin.directory.group — crear/eliminar grupos y listas de distribución.
  • admin.directory.group.member — agregar/quitar miembros a grupos.
  • admin.directory.domain.readonly — solo lectura del listado de dominios (para validar que el SA opera sobre el dominio correcto).
  • admin.directory.customer.readonly — solo lectura de los datos de la cuenta de cliente Google (para reportes agregados).

No solicitamos: acceso a Gmail (Mail scopes), Drive, Calendar, Chat, ni ningún dato de contenido del usuario. Mekovault no lee correos ni archivos.

Microsoft Entra — Application permissions

  • User.ReadWrite.All — lifecycle de usuarios.
  • Group.ReadWrite.All — creación y gestión de grupos.
  • Directory.ReadWrite.All — modificaciones estructurales menores del directorio.
  • AdministrativeUnit.Read.All — solo lectura de unidades administrativas para segmentación.
  • User.RewritePassword.All — opcional, solo si el Cliente desea que Mekovault resetee contraseñas desde el portal. Sin este permiso las demás operaciones funcionan; el reset queda deshabilitado y los usuarios usan el Self-Service Password Reset de Microsoft.

No solicitamos: permisos Delegated, acceso a Exchange (Mail.*, Calendars.*), Teams messages, SharePoint content ni políticas de Conditional Access.

3.2 Nunca en logs, nunca fuera del proceso

  • Los adaptadores cargan el secreto en memoria justo antes de llamar al proveedor externo y lo descartan al terminar el request.
  • El logger estructurado filtra automáticamente cualquier campo cuyo nombre contenga password, secret, token, key o credential. Las entradas de log muestran el hash truncado del request-id pero nunca el contenido del secreto.
  • No hay backups del vault en almacenamiento externo no cifrado. Los snapshots se cifran con la misma clave maestra del vault.

4. Auditoría de cada uso

4.1 Log inmutable credential_usage_log

Cada vez que Mekovault ejecuta una operación sobre el directorio del Cliente con las credenciales almacenadas, se persiste un registro en la tabla credential_usage_log con:

  • Quién: ID y email del usuario Mekovault (o identificador del worker/scheduler) que originó la operación.
  • Por qué: propósito humano obligatorio (ejemplo: “Onboarding user@empresa.cl vía ticket #4213”, “Health check nocturno”, “Bulk deprovision batch #123”).
  • Qué: operación exacta (create_user, suspend_user, reset_password, add_group_member, etc.).
  • Qué scopes: lista de scopes OAuth / Application permissions consumidos.
  • Sobre qué recurso: email del usuario, grupo, OU, u otro identificador (sin datos sensibles del contenido).
  • Resultado: success / failure / partial, error_code, error_message, duration_ms, request_id para correlacionar con nginx.
  • Cuándo: timestamp en UTC con precisión de milisegundos.

4.2 Inmutabilidad

La tabla tiene triggers PostgreSQL que rechazan cualquier UPDATE y DELETE. Ni el equipo de Mekovault con acceso root puede modificar un registro individual. La única forma de purgar es el retention worker con reglas explícitas publicadas —hoy: retención de 24 meses, planeado configurable por Cliente en Hito 7— que corre con SECURITY DEFINER y deja constancia del batch purgado.

4.3 Visibilidad para el Cliente

Cada admin del tenant puede consultar el log en:

  • https://app.mekovault.com/<tu-slug>/admin/credential-usage

Filtros por provider, resultado, operación, rango de fechas y actor. La consulta usa Row-Level Security por company_id: cada tenant ve exclusivamente sus propios registros.

Exportación programada CSV/JSON firmada para auditores externos en el Hito 7. Mientras tanto, se puede solicitar bajo demanda escribiendo a soporte@mekovault.com.

4.4 Correlación con el sistema de auditoría

credential_usage_log es específico para llamadas al directorio externo. Existe una segunda tabla, audit_events, que registra acciones humanas dentro del portal (login, aprobación de ticket, creación de rol, etc.). Ambas comparten request_id para reconstruir una cadena completa: “admin X aprobó el ticket Y, que disparó la operación Z sobre el usuario W en Google, con scope A, resultado B”.

5. Control de accesos internos (Mekovault staff)

  • El acceso administrativo a los hosts requiere Tailscale con MFA y clave SSH personal. No hay cuentas compartidas.
  • Ningún miembro del equipo de Mekovault necesita —ni tiene por defecto— la capacidad de descifrar secretos individuales de un Cliente para operar la plataforma.
  • Acceso al vault Infisical restringido a los miembros del equipo de plataforma. Los cambios de política quedan en el audit interno de Infisical.
  • El acceso a la base de datos productiva se hace vía cuentas nominales con RLS activo. La cuenta mekovault_superadmin (BYPASSRLS) tiene uso restringido y deja registros en audit_events.

6. Respuesta ante incidentes

  • Notificación al Cliente afectado dentro de las 72 horas de confirmado un incidente que involucre datos personales suyos o sus credenciales (RGPD art. 33, Ley 21.719 Chile art. 33).
  • Rotación forzosa de todas las credenciales del tenant afectado y revocación de la conexión: el Cliente debe reconectar el directorio con un Service Account nuevo (nosotros no reutilizamos el comprometido).
  • Reporte post-mortem al Cliente con la línea de tiempo, alcance, contramedidas y aprendizajes.
  • Canal de reporte responsable de vulnerabilidades: security@mekovault.com. Respondemos en ≤ 48h hábiles.

7. Ejercicios de derechos y portabilidad

Si el Cliente rescinde el servicio o solicita eliminación total de sus datos:

  • Borrado del proyecto Infisical (elimina atómicamente todos los secretos del tenant).
  • Borrado en cascada de las filas del tenant en PostgreSQL, incluyendo la conexión y el catálogo de identidades.
  • El credential_usage_log del tenant se conserva 24 meses adicionales por obligaciones de auditabilidad (Ley 21.719 art. 12, RGPD art. 30). El Cliente puede solicitar antes su hash pseudónimo si su política interna lo requiere.

8. Marcos de referencia

Alineamos las prácticas descritas con:

  • SOC 2 Type II — controles CC6 (accesos), CC7 (monitoreo), CC8 (change management). Certificación planeada 2027.
  • ISO/IEC 27001 — controles A.5 (información), A.8 (activos), A.9 (accesos), A.12 (operaciones), A.16 (incidentes).
  • GDPR / RGPD (UE 2016/679) — arts. 25 (privacy by design), 30 (registro de actividades), 32 (seguridad del tratamiento), 33 (notificación).
  • Ley 21.719 (Chile) — arts. 12 (registro de actividades), 33 (notificación de brechas), 34 (medidas de seguridad).
  • Google Workspace — condiciones de uso del Admin SDK Directory API y del programa de Marketplace.
  • Microsoft Entra — condiciones del Microsoft Graph API y del Trust Center.

9. Preguntas y contacto

Los equipos de seguridad de Clientes actuales o prospectos pueden solicitar:

  • Copia de nuestro DPA firmable (Data Processing Agreement).
  • Cuestionario de seguridad (CAIQ, VSA, SIG Lite) —lo respondemos en ≤ 5 días hábiles.
  • Evidencia de auditorías internas y reportes de pen-testing (bajo NDA).

Escríbenos a security@mekovault.com o contáctanos por el formulario de contacto.

10. Cambios a esta política

Publicamos la fecha de última revisión en el encabezado. Cambios materiales (por ejemplo, nuevos scopes solicitados, cambios en el modelo de retención) se comunican con 30 días de anticipación por email a los administradores del tenant y quedan reflejados en el historial público del sitio.

Este documento describe controles operativos y no constituye certificación formal. Para certificaciones vigentes o en curso ver el Trust Center (próximamente en trust.mekovault.com) o solicitarlo por security@mekovault.com.

Políticas de Seguridad — Mekovault · Mekovault