— 01
Chaves envelope por tenant
Cada org tem sua própria KEK no seu KMS ou no nosso. As chaves de dados são encapsuladas por ela. Bifurcar um tenant é uma derivação de chave, não uma migração de dados.
Criptografado em repouso.
Criptografado na sua cabeça.
Chaves por tenant, acesso declarativo, auditoria completa. A gente nunca vê o texto claro — e o usuário errado também não deveria ver.
VAULT · CRIPTOGRAFADO POR LINHAtenant acmeobjetos 284último acesso 17:41
OBJ_01HZX9 · CONFIDENCIAL⚿
acme · MSA · 2026.pdf
A8F2 4B91 E6CD 7012 9F4A 33B7 D5E8 1C0F 8E3A 7B62 4D9F 1A05 C8B3 E2F7 7C13 9A2E 4F8B D061 5E29 8B7A C4F1 0D93 2E5A 9F18 6B27 E0C4 71AD F38B 3D90 E5F1 B274 8A6C 0E1F 9B23 C7D4 5A82 F4E0 1C39 7B6A 2E5D 8F90 4C12 A8F2 4B91 E6CD 7012 9F4A 33B7 D5E8 1C0F 8E3A 7B62 4D9F 1A05 C8B3 E2F7
DEK
key_acme_v3
KMS
aws · us-east-1
ALG
AES-256-GCM
ROTAÇÃO
90d
tenant_acme⚿
w9-vendor.pdf
7C13 9A2E 4F8B D061 5E29 8B7A C4F1 0D93 …
tenant_contoso⚿
soc2-evidence.zip
3D90 E5F1 B274 8A6C 0E1F 9B23 C7D4 5A82 …
tenant_pinpoint⚿
phi · 2026q1.csv
A8F2 4B91 E6CD 7012 9F4A 33B7 D5E8 1C0F …
tenant_lumen⚿
api-secrets.env
7C13 9A2E 4F8B D061 5E29 8B7A C4F1 0D93 …
KEYRING · KMSHSM
⚿
key_acme_v3
AES-256 · wrapped · aws-kms
14d
⚿
key_contoso_v2
AES-256 · wrapped · aws-kms
31d
⚿
key_pinpoint_v5
AES-256 · cmk · BYOK
8d
⚿
key_lumen_v1
AES-256 · wrapped · aws-kms
62d
ACESSOS RECENTES
17:41val@acme leu obj_01HZX9
17:38rotação de chave · key_acme v2→v3
16:24rod@acme upload · 1 obj
15:02política negou · support → tenant_pinpoint
O formato
Armazenamento construído sobre as mesmas primitivas de sessão, tenant, role, política que você já está usando.
Todo produto B2B acumula arquivos que pertencem a um cliente e só a esse cliente — contratos, exportações, certificados, folha de pagamento. O Locker armazena tudo com as mesmas regras de escopo que você já escreveu pro resto.
— 02
Política, não listas de acesso
Regras declarativas de quem-pode-abrir — por role, frescor de MFA, geo, tempo. Amigável pra auditoria, revisável por diff.
— 03
Zero-trust por padrão
O Authaz nunca guarda o texto claro. O caminho dos dados é cliente → DEK → encapsulado pelo KMS → object store. A gente só vê ciphertext.
A mecânica
Criptografado na entrada. Auditado na saída.
— 01
Criptografia envelope, ponta a ponta.
Cada objeto recebe sua própria chave de criptografia de dados. A DEK é encapsulada pela KEK do tenant no seu KMS (ou no nosso). A gente armazena ciphertext + uma chave encapsulada — nada mais.
- payload AES-256-GCM · auth tag por chunk
- encapsule com AWS KMS, GCP KMS, Azure Key Vault ou BYOK
- rotacione KEKs sem reenviar dados
CLIENTarquivo escolhido · enviado em chunkschunks de 4 mb
↓
DEKchave de dados geradaaes-256-gcm
↓
WRAPDEK encapsulada pela KEK da orgkms · hsm
↓
STOREciphertext · object store · prefixo por tenants3 · gcs · azure
o authaz nunca vê o texto claro · nunca
— 02
Políticas de acesso que seu auditor consegue ler.
Mesma engine do RBAC do Authaz. Conceda por role, exija MFA, negue por geo, expire por inatividade. Políticas ficam ao lado dos dados; tenants podem adicionar as suas sem tocar no seu código.
- role + ABAC + condições de frescor de MFA
- concessões com TTL · compartilhamentos com prazo
- escopo por tenant — admins só veem a própria org
// quem pode abrir o quê — declarativo
access "contracts/*" {
grant role "legal"
grant role "admin" exige mfa "webauthn"
expires "30d" após last_open
}
access "payroll/*" {
grant role "hr-admin" exige step_up
deny se request.geo not_in ["US"]
audit open · download · share
}
— 03
Cada abertura. Cada compartilhamento. Cada negação.
Cada decisão de acesso é transmitida pro seu log de auditoria. Compradores podem assinar o feed do próprio tenant. Times de compliance recebem o export que pedem, automaticamente.
- stream pra S3 · Datadog · Splunk
- visões com escopo de tenant pros compradores
- evidência de adulteração · assinatura por evento
09:14val@acme.comabriu msa-northwind-2026.pdfallow
09:12jess@acme.comcompartilhou soc2.pdf · 7d ttlallow
09:08rod@acme.comtentou q4-payroll.csvdeny
09:02val@acme.comenviou wire-instructions.txtallow
08:51admin@acme.comrotacionou org KEK · v3 → v4allow
API
Mesma superfície do resto do Authaz.
Seu handle de escopo, o path, os dados. Política por referência. A gente faz o resto.
app/contracts/upload.tscriptografado ponta a ponta
await authaz.locker.put({
org_id: session.org,
path: "contracts/msa-northwind-2026.pdf",
data: file.stream(),
policy: "contracts/*",
labels: ["legal", "signed"],
});
Spec
As letras miúdas, na frente.
Criptografia
AES-256-GCM · auth por chunk · DEK por objeto · encapsulada pelo KMS
Suporte a KMS
AWS KMS · GCP KMS · Azure Key Vault · BYOK · enterprise com HSM
Rotação de chaves
rotação de KEK in place · DEK reencapsulada lazy · zero downtime
Backends de storage
S3 · GCS · Azure Blob · residência fixada por tenant
Política de acesso
roles · ABAC · frescor de MFA · geo · tempo · concessões com TTL
Auditoria
todo put · get · share · deny · stream · evidência de adulteração
Compliance
SOC 2 · ISO 27001 · elegível pra HIPAA · pronto pra GDPR
Modelo de preço
por GB-mês · sem cobrança por duplicação de ciphertext
Combina com
Uma plataforma. Toda primitiva.
Todo produto Authaz compartilha as mesmas primitivas — sessões, políticas, auditoria, tenants. Escolha o que precisa hoje; adicione o resto quando precisar.
01 · ORGANIZAÇÕES MULTI-TENANT
Organizações Multi-tenant
Modele organizações, membros e limites de tenant de forma limpa.
Saiba mais →
02 · RBAC E PERMISSÕES
RBAC e Permissões
Controles de acesso baseados em funções para superfícies de cliente e admin.
Saiba mais →
03 · ACESSO ADMIN E DASHBOARD
Acesso Admin e Dashboard
Autenticação que funciona para back-office e ferramentas internas.
Saiba mais →
Começar
Dados com escopo de tenant. Chaves com escopo de tenant.
Armazenamento de documentos criptografado que cabe no seu modelo de auth — não o contrário.