Mekovault

Políticas de Segurança

Tradução para referência. A versão em espanhol é a que prevalece.

Vigência: 2026 · Última revisão: 31 de agosto de 2026

A Mekovault gerencia o ciclo de vida de identidades no Google Workspace e em outras plataformas que venham a ser conectadas no futuro. Para funcionar, recebe credenciais muito sensíveis (Service Accounts com permissões de administração). Este documento descreve como as armazenamos, como as usamos e como o Cliente pode auditar cada uso.

Foi redigido como referência para equipes de segurança, auditores e compradores enterprise. Complementa, não substitui, a Política de Privacidade, os Termos e o DPA.

1. Escopo

Estas políticas se aplicam a toda credencial que o Cliente entrega à Mekovault para operar sobre seu diretório corporativo, incluindo, mas não limitado a:

  • Google Workspace: arquivo JSON de Service Account com Domain-Wide Delegation.
  • Qualquer outra credencial de integração com outras plataformas, sistemas de pessoas ou diretórios que a Mekovault venha a suportar no futuro.

2. Arquitetura de armazenamento

2.1 Separação física de segredos e metadados

Nenhuma credencial é armazenada no banco de dados relacional da Mekovault. A arquitetura separa dois planos:

  • Plano de metadados (PostgreSQL, host mekovault-data): guarda apenas um ponteiro para o segredo (nome da chave dentro do vault), o provedor, o domínio primário, timestamps e os resultados do último health check. Row-Level Security por company_id.
  • Plano de segredos (Infisical, host mekovault-vault): instância auto-hospedada do Infisical em rede privada Tailscale, não exposta à Internet pública. Contém os valores reais (por exemplo, o JSON completo da Service Account).

Um bug ou comprometimento do serviço de metadados não expõe credenciais: os segredos exigem autenticação separada no Infisical por meio de uma identidade de máquina distinta.

2.2 Isolamento por tenant (multi-tenancy rígido)

Cada tenant recebe um projeto Infisical dedicado (exemplo: setting-cl-415514, mmglatam-com-872039). Os segredos nunca são compartilhados. Consequência:

  • O raio de impacto de qualquer falha no código da Mekovault que construa incorretamente a referência ao projeto fica limitado ao mesmo tenant: não é possível ler, listar ou tocar segredos de outros clientes.
  • As políticas de acesso do Infisical rejeitam solicitações a projetos para os quais a identidade de máquina da Mekovault não tem permissão, ainda que os conheça pelo nome.

2.3 Criptografia

  • Em trânsito: TLS 1.2+ obrigatório em todas as conexões (HTTPS do portal, PostgreSQL com SSL, canal Mekovault → Infisical, canal Mekovault → Google). Não aceitamos conexões não criptografadas.
  • Em repouso: os segredos são criptografados no Infisical com a chave mestra do vault (AES-256-GCM); o volume do vault é criptografado em nível de disco (LUKS / EBS encryption). O PostgreSQL roda com criptografia de disco.
  • Rotação de chaves de serviço: as chaves de assinatura de JWT e as credenciais da identidade de máquina do Infisical são rotacionadas pelo menos a cada 12 meses e diante de qualquer evento de comprometimento suspeito.

2.4 Rede e perímetro

  • Todas as máquinas do backend (mekovault-app, mekovault-data, mekovault-obs, mekovault-vault) estão conectadas por Tailscale sobre WireGuard.
  • mekovault-vault não tem IP público nem porta aberta para a Internet. Escuta apenas na interface privada Tailscale. Nem mesmo a partir do frontend público (Vercel) é possível alcançá-lo diretamente.
  • O acesso administrativo pela equipe da Mekovault exige Tailscale com MFA + chave SSH gerenciada. Sem credenciais SSH root pessoais em nenhum host.

3. Uso das credenciais

3.1 Princípio do mínimo privilégio na solicitação

Ao conectar o diretório, a Mekovault solicita exatamente os escopos de que precisa, nem um a mais. Publicamos a lista completa no guia do Assistente de conexão e a reproduzimos aqui:

Google Workspace: Domain-Wide Delegation

  • admin.directory.user: criar, suspender, reativar e modificar usuários.
  • admin.directory.user.security: redefinição de senha e encerramento de sessões ativas (SSO revocation).
  • admin.directory.orgunit: mover usuários entre OUs durante onboarding/offboarding.
  • admin.directory.group: criar/excluir grupos e listas de distribuição.
  • admin.directory.group.member: adicionar/remover membros de grupos.
  • admin.directory.domain.readonly: somente leitura da lista de domínios (para validar que a SA opera sobre o domínio correto).
  • admin.directory.customer.readonly: somente leitura dos dados da conta de cliente Google (para relatórios agregados).

Não solicitamos: acesso ao Gmail (Mail scopes), Drive, Calendar, Chat, nem qualquer dado de conteúdo do usuário. A Mekovault não lê e-mails nem arquivos.

Outras plataformas

Quando uma nova plataforma for conectada, publicaremos nesta mesma seção a lista exata de permissões que ela solicita antes de ficar disponível para os Clientes. O critério é o mesmo: apenas permissões de administração de contas, nunca acesso ao conteúdo das pessoas.

3.2 Nunca em logs, nunca fora do processo

  • Os adaptadores carregam o segredo em memória logo antes de chamar o provedor externo e o descartam ao terminar a requisição.
  • O logger estruturado filtra automaticamente qualquer campo cujo nome contenha password, secret, token, key ou credential. As entradas de log mostram o hash truncado do request-id, mas nunca o conteúdo do segredo.
  • Não há backups do vault em armazenamento externo não criptografado. Os snapshots são criptografados com a mesma chave mestra do vault.

4. Auditoria de cada uso

4.1 Log imutável credential_usage_log

Cada vez que a Mekovault executa uma operação sobre o diretório do Cliente com as credenciais armazenadas, um registro é persistido na tabela credential_usage_log com:

  • Quem: ID e e-mail do usuário Mekovault (ou identificador do worker/scheduler) que originou a operação.
  • Por quê: propósito humano obrigatório (exemplo: “Onboarding user@empresa.cl via ticket #4213”, “Health check noturno”, “Bulk deprovision batch #123”).
  • O quê: operação exata (create_user, suspend_user, reset_password, add_group_member, etc.).
  • Quais escopos: lista de escopos OAuth / Application permissions consumidos.
  • Sobre qual recurso: e-mail do usuário, grupo, OU ou outro identificador (sem dados sensíveis de conteúdo).
  • Resultado: success / failure / partial, error_code, error_message, duration_ms, request_id para correlacionar com o nginx.
  • Quando: timestamp em UTC com precisão de milissegundos.

4.2 Imutabilidade

A tabela tem triggers PostgreSQL que rejeitam qualquer UPDATE e DELETE. Nem a equipe da Mekovault com acesso root pode modificar um registro individual. A única forma de expurgar é o retention worker com regras explícitas publicadas (retenção mínima de 24 meses, configurável por Cliente até 84, ou até a exclusão do tenant, o que ocorrer primeiro), que roda com SECURITY DEFINER e deixa registro do lote expurgado.

4.3 Visibilidade para o Cliente

Cada admin do tenant pode consultar o log em:

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

Filtros por provedor, resultado, operação, intervalo de datas e ator. A consulta usa Row-Level Security por company_id: cada tenant vê exclusivamente seus próprios registros.

Exportação programada CSV/JSON assinada para auditores externos no Marco 7. Enquanto isso, pode ser solicitada sob demanda escrevendo para soporte@mekovault.com.

4.4 Correlação com o sistema de auditoria

credential_usage_log é específico para chamadas ao diretório externo. Existe uma segunda tabela, audit_events, que registra ações humanas dentro do portal (login, aprovação de ticket, criação de papel, etc.). Ambas compartilham request_id para reconstruir uma cadeia completa: “admin X aprovou o ticket Y, que disparou a operação Z sobre o usuário W no Google, com escopo A, resultado B”.

5. Controle de acessos internos (equipe Mekovault)

  • O acesso administrativo aos hosts exige Tailscale com MFA e chave SSH pessoal. Não há contas compartilhadas.
  • Nenhum membro da equipe da Mekovault precisa, nem tem por padrão, a capacidade de descriptografar segredos individuais de um Cliente para operar a plataforma.
  • Acesso ao vault Infisical restrito aos membros da equipe de plataforma. As alterações de política ficam no audit interno do Infisical.
  • O acesso ao banco de dados de produção é feito por contas nominais com RLS ativo. A conta mekovault_superadmin (BYPASSRLS) tem uso restrito e deixa registros em audit_events.

6. Resposta a incidentes

  • Notificação ao Cliente afetado em até 72 horas após a confirmação de um incidente que envolva seus dados pessoais ou suas credenciais (RGPD art. 33, Ley 21.719 Chile art. 33).
  • Rotação forçada de todas as credenciais do tenant afetado e revogação da conexão: o Cliente deve reconectar o diretório com uma Service Account nova (não reutilizamos a comprometida).
  • Relatório post-mortem ao Cliente com a linha do tempo, escopo, contramedidas e aprendizados.
  • Canal de divulgação responsável de vulnerabilidades: security@mekovault.com. Respondemos em ≤ 48h úteis.

7. Exercício de direitos e portabilidade

Se o Cliente rescindir o serviço ou solicitar a exclusão total de seus dados:

  • Exclusão do projeto Infisical (elimina atomicamente todos os segredos do tenant).
  • Exclusão em cascata das linhas do tenant no PostgreSQL, incluindo a conexão e o catálogo de identidades.
  • O credential_usage_log do tenant é conservado até a exclusão do tenant ou por 24 meses, o que ocorrer primeiro (Ley 21.719 art. 12, RGPD art. 30). Ao excluir o tenant, ele é apagado junto com o restante dos seus dados; a Mekovault conserva apenas um registro próprio com contadores e sem dados pessoais. O Cliente pode solicitar antes o seu hash pseudônimo se a política interna dele exigir.

8. Marcos de referência

Alinhamos as práticas descritas com:

  • SOC 2 Type II: controles CC6 (acessos), CC7 (monitoramento), CC8 (change management). Sem certificação planejada por ora: usamos o marco como guia de controles, não como promessa de auditoria.
  • ISO/IEC 27001: controles A.5 (informação), A.8 (ativos), A.9 (acessos), A.12 (operações), A.16 (incidentes).
  • GDPR / RGPD (UE 2016/679): arts. 25 (privacy by design), 30 (registro de atividades), 32 (segurança do tratamento), 33 (notificação).
  • Ley 21.719 (Chile): arts. 12 (registro de atividades), 33 (notificação de violações), 34 (medidas de segurança).
  • Google Workspace: condições de uso da Admin SDK Directory API e do programa do Marketplace.

9. Dúvidas e contato

As equipes de segurança de Clientes atuais ou potenciais podem solicitar:

  • Cópia do nosso DPA assinável (Data Processing Agreement).
  • Questionário de segurança (CAIQ, VSA, SIG Lite): respondemos em ≤ 5 dias úteis.
  • Evidências de auditorias internas e relatórios de pen-testing (sob NDA).

Escreva para security@mekovault.com ou fale conosco pelo formulário de contato.

10. Alterações nesta política

Publicamos a data da última revisão no cabeçalho. Alterações materiais (por exemplo, novos escopos solicitados, mudanças no modelo de retenção) são comunicadas com 30 dias de antecedência por e-mail aos administradores do tenant e ficam refletidas no histórico público do site.

Este documento descreve controles operacionais e não constitui certificação formal. Para certificações vigentes ou em andamento, consulte o Trust Center (em breve em trust.mekovault.com) ou solicite por security@mekovault.com.