SEGURANÇA
Para cada garantia, o mecanismo que a sustenta.
Esta página foi escrita para ser encaminhada, e por isso cada resposta explica o mecanismo e mostra onde ele está no produto.
Abre uma conversa no WhatsApp. Prefere e-mail? [email protected]
Onde cada coisa fica.
Tudo roda na sua infraestrutura, e o dado fica no seu perímetro. Mesmo assim, a divisão entre o Agente e a API importa dentro da sua empresa, porque quem administra a API não tem acesso ao valor dos secrets nem à senha dos bancos.
No Agente e na borda
- O valor de cada
secret. - A credencial administrativa dos bancos e a senha de cada
service user. - O histórico de cada sessão do proxy de banco.
- O conteúdo do tráfego de rede, cifrado de ponta a ponta entre a borda e o Agente.
- O state e o lock do Terraform ficam no bucket da sua conta de cloud.
Na API, que também é sua
- Organizações, pessoas, papéis e
policy. - O catálogo, com os inputs e outputs do Terraform (um output
sensitivefica como<sensitive>) e o log de cada execução. - O metadado de cada secret e o registro de quem o leu.
- O schema dos bancos e o texto de cada comando SQL.
- O metadado de cada fluxo de rede.
- A trilha de auditoria.
- A CA que assina Agentes e bordas e a chave OIDC, ambas cifradas.
-
Quem administra o Heimdall consegue ler o valor dos secrets?
A API se recusa a receber o valor e responde
400 VALUE_NOT_ACCEPTED. O valor que o seu time grava fica no Agente, cifrado com uma master key sua (em variável de ambiente, arquivo ou AWS KMS), e o Agente só entrega o valor depois de conseguir registrar a leitura. Quem administra a API vê o nome, a versão e quem leu. -
A Yops tem acesso à minha instalação?
Não existe nenhum canal que leve da Yops para dentro da sua instalação. Durante a implantação, a equipe da Yops trabalha com o acesso que o seu time conceder.
-
Como o dado é cifrado, e com a chave de quem?
Na API, cada organização tem uma chave de dados própria, cifrada por uma master key sua, que pode ser local ou uma CMK do AWS KMS. No Agente, a master key também é sua.
-
Quem pode fazer o quê, e quem decide?
Quem decide é o Cedar, no servidor; a tela só pergunta. A recusa na entrada de uma rota fica registrada na trilha de auditoria (
authz.denied). Aspoliciesde sistema são imutáveis, e uma regraforbid, que o motor injeta, bloqueia as ações que entregariam a identidade do owner. -
A trilha de auditoria pode ser alterada?
A trilha só aceita acréscimos, porque um trigger faz o banco recusar
UPDATEeDELETE. -
Como uma organização é isolada das outras?
O PostgreSQL aplica row-level security por organização, habilitada e forçada em toda tabela que pertence a uma organização. Um teste varre o schema e reprova qualquer tabela que tenha ficado sem ela.
-
Como as pessoas entram?
Por senha, com segundo fator por e-mail (definido pela política da organização e ligado por padrão para o owner); por Google ou GitHub; ou pelo IdP OIDC da própria organização, com prova de posse do domínio por registro TXT. Num domínio federado, o Heimdall recusa o cadastro por senha.
Esta página descreve mecanismos, não certificações.
Tem um questionário de segurança? Fale com a engenharia.
Abre uma conversa no WhatsApp. Prefere e-mail? [email protected]