Políticas de acesso (RBAC)

O CipherVault implementa RBAC (Role-Based Access Control) granular com políticas declarativas em JSON, no estilo AWS IAM. Você define quem pode fazer o quê em quais recursos, sob quais condições.

Estrutura de uma policy

{
  "version": "2025-01-01",
  "statement": [
    {
      "sid": "leitura-stripe-prod",
      "effect": "allow",
      "principal": {
        "user": ["alice@acme.com.br", "bob@acme.com.br"],
        "group": ["billing-readers"]
      },
      "action": [
        "secrets:read",
        "secrets:listVersions"
      ],
      "resource": "vault/producao/api/stripe/*",
      "condition": {
        "ipAddress": {
          "request:sourceIp": ["177.123.0.0/16", "10.0.0.0/8"]
        },
        "stringEquals": {
          "request:mfaPresent": "true"
        },
        "dateGreaterThan": {
          "request:currentTime": "08:00:00-03:00"
        },
        "dateLessThan": {
          "request:currentTime": "20:00:00-03:00"
        }
      }
    }
  ]
}

Ações disponíveis

Recurso	Ações
secrets:*	read, create, update, delete, listVersions, rotate, rollback
vaults:*	list, read, create, update, delete, share
policies:*	attach, detach, simulate
audit:*	read, export
app_connections:*	create, rotate, revoke

Princípios

A maior parte da governança decorre de quatro princípios:

1. Menor privilégio. Conceda apenas o que é necessário; revise trimestralmente.
2. Grupos, não usuários. Atribua policies a grupos (LDAP/AD/Keycloak/manuais), não diretamente a pessoas.
3. Aprovação multi-nível. Para produção, exija aprovação de 2 admins via fluxo break-the-glass.
4. Condições contextuais. Restrinja por IP, horário, MFA, AppConnection e nível de risk score do usuário.

Aprovação multi-nível (break-the-glass)

Para acessos pontuais a secrets críticos, configure aprovação em duas etapas:

{
  "sid": "acesso-emergencial-db-prod",
  "effect": "allow",
  "principal": { "group": ["sre-oncall"] },
  "action": ["secrets:read"],
  "resource": "vault/producao/db/postgres/*",
  "condition": {
    "approval": {
      "minApprovers": 2,
      "approverGroup": "sre-leads",
      "ttlMinutes": 60,
      "reasonRequired": true
    }
  }
}

O SRE faz a request, dois leads aprovam (com motivo), o acesso é concedido por 60 minutos e cada operação é registrada em log imutável.

Revisão periódica

Em Configurações → Acessos → Revisão, você define ciclos de auditoria:

• Frequência: 30, 60, 90 ou 180 dias.
• Aprovadores: gerentes diretos (via integração HRIS) ou grupo fixo.
• Ação default se não revisado: revogar (recomendado) ou notificar.

O CipherVault gera relatório PDF/CSV pronto para auditoria LGPD/ISO 27001.

Simulador de policies

Antes de aplicar, valide:

curl -X POST https://api.ciphervault.com.br/v1/policies/simulate \
  -H "Authorization: Bearer $CIPHERVAULT_TOKEN" \
  -d '{
    "principal": "alice@acme.com.br",
    "action": "secrets:read",
    "resource": "vault/producao/api/stripe/secret_key",
    "context": {
      "sourceIp": "177.123.45.67",
      "mfaPresent": true,
      "currentTime": "2026-05-04T14:30:00-03:00"
    }
  }'

Resposta:

{
  "decision": "allow",
  "matchingStatements": ["leitura-stripe-prod"],
  "evaluatedConditions": {
    "ipAddress": "match",
    "stringEquals.mfaPresent": "match",
    "dateBetween": "match"
  }
}

Boas práticas

• Nunca use resource: "*" em produção.
• Negue por padrão. Adicione policies effect: "deny" para PII/PCI sobrepondo allows.
• Combine com Risk Scoring. Bloqueie automaticamente principais com score de risco > 70.
• AppConnections para serviços. Não use credenciais de pessoas em pipelines — use OIDC Federation ou AppConnections.

Próximo passo

Habilitar rotação automática de credenciais →