Heimdall

PLATAFORMA DE ENGENHARIA · SELF-HOSTED

Boas práticas que não dependem de disciplina.

Catálogo, infraestrutura, secrets, banco de dados, acesso interno, release e incidente numa só plataforma, rodando na sua infraestrutura. Cada acesso segue uma regra e fica registrado.

Falar com engenharia Ver a segurança

Abre uma conversa no WhatsApp. Prefere e-mail? heimdall@yops.cloud

TERMINALheimdall db access
heimdall db access request pg-orders-orders --operations SELECT,UPDATE --tables public.orders,public.customers --reason "corrigir pedidos com total errado" --task-key OPS-101
✓ Access request submitted for database 'pg-orders-orders'
  Operations: SELECT, UPDATE
  Reason: corrigir pedidos com total errado
  Task: OPS-101
  Expires: 2026-10-10T08:13:58.978413Z
  Duration: this database's default for those operations
  ('heimdall db expiry show --database pg-orders-orders' shows the defaults and the ceilings.)
  Status: pending approval
  An approver decides it with 'heimdall db access approve <grant-id>'.

heimdall db access approve 05512517-3276-4918-af87-79ef234fbd9d
✓ Access request 05512517-3276-4918-af87-79ef234fbd9d approved
  Status: active
  The requester can connect now with 'heimdall db connect <database>'.
Saída real do CLI. Quem pede não aprova o próprio pedido.

A PLATAFORMA

O ciclo inteiro sob as mesmas regras.

Do mapa do que você roda até a resposta a um incidente, são sete módulos com o mesmo controle de acesso, e todo acesso fica registrado.

  • 01

    CATÁLOGO

    O mapa que serve de endereço para todos os módulos.

    Domain, System, Component e environment. É a base de tudo: release, incidente, secret e serviço de rede apontam para o mesmo Component, em vez de cadastros separados que ninguém reconcilia.

    Ver o módulo

  • 02

    INFRASTRUCTURE MANAGER

    Infraestrutura pedida pelo catálogo, aplicada dentro da sua rede.

    O Heimdall planeja e aplica o Terraform na sua infraestrutura e guarda o state no bucket da sua conta. Na AWS, no GCP e no Azure, a credencial vem, por padrão, da federação OIDC e não fica guardada. Quando o resource schema exige aprovação, outra pessoa aprova exatamente a versão que viu. Funciona com AWS, GCP, Azure, Kubernetes, Helm e Cloudflare.

    Ver o módulo

  • 03

    SECRET MANAGER

    O valor de um secret só existe no seu Agente.

    A API se recusa a receber o valor; ela governa o nome, a versão, quem pode ler e quem leu. O Agente guarda o valor cifrado com uma chave sua e só entrega uma leitura depois de conseguir registrá-la. Quando alguém sai da empresa, cada secret que a pessoa leu passa a at_risk.

    $ heimdall secret access-log db-password
    ACCESSED_AT           ACCESSOR                ENVIRONMENT  VERSION  SERVED_BY   FROM       READS
2026-10-10T06:18:58Z  agent site-agent        prod         3        site-agent  127.0.0.1  1
2026-10-10T06:18:45Z  admin@demo.example.com  prod         2        site-agent  127.0.0.1  1
2026-10-10T06:18:45Z  admin@demo.example.com  prod         3        site-agent  127.0.0.1  1

    Ver o módulo

  • 04

    DATABASE MANAGER

    Acesso à produção com pedido, aprovação de outra pessoa e prazo.

    Cada acesso tem aprovador nomeado e prazo, e ninguém aprova o próprio pedido. Comando e migration respeitam a janela de horário do banco. A senha nasce no Agente e não sai de lá.

    masking pela coluna de origem: o CPF chega como [CPF] mesmo quando a consulta o renomeia, o lê numa subquery ou passa por uma view. guardrails recusam na hora o DELETE sem WHERE; para que ele rode, outra pessoa precisa aprovar, e a aprovação vale para uma execução só.

    NOTICE:  Heimdall authenticated this connection as PostgreSQL role "hd_pg_orders_orders_7cyjmwi7_hdm" under access grant 05512517-3276-4918-af87-79ef234fbd9d; any credentials you supplied were not used and were not sent to the database.
psql (18.6, server 17.11)
Type "help" for help.

=> select cpf as documento, upper(email) as e, name from customers limit 1;
 documento |    e    |   name    
-----------+---------+-----------
 [CPF]     | [EMAIL] | Ana Souza
(1 row)

=> UPDATE customers SET name = 'cliente de teste';
ERROR:  HEIMDALL GUARDRAIL: UPDATE without WHERE clause is blocked by guardrail "DELETE and UPDATE need a WHERE" [require-where]. To run it, get it approved first, then run it again: heimdall db command submit 'b4bc0108-1814-47df-a9a9-7e591423dae6' --reason '<why this must run>' --sql 'UPDATE customers SET name = '\''cliente de teste'\'';'
    Saída real, pelo proxy do Heimdall.

    Ver o módulo

  • 05

    ACESSO A APLICAÇÕES INTERNAS

    Aplicações internas pelo browser, sem VPN.

    A borda roda na sua infraestrutura, e é nela que o TLS termina. Cada acesso é concedido a uma pessoa para um serviço, com prazo e motivo, e fica registrado antes de passar o primeiro byte.

    Ver o módulo

  • 06

    RELEASE MANAGER

    Você aprova exatamente a mudança que vai para produção.

    O Heimdall commita a nova versão no seu repositório de manifestos, e o seu GitOps faz a entrega. Quem aprova vê o diff, o portão é consultado de novo antes do commit, e o rollback volta à versão anterior conhecida, sem que ninguém escolha o destino à mão.

    Ver o módulo

  • 07

    INCIDENT MANAGER

    Um incidente só fecha com o postmortem aprovado.

    Todo rollback abre um incidente automaticamente, datado do momento em que a versão ruim chegou. Um break-glass de banco fica vinculado ao incidente aberto, mas o incidente nunca concede acesso: ele registra por que o acesso aconteceu.

    Ver o módulo

A REGRA É SUA

Você define a regra. A plataforma faz cumprir.

Cada organização configura, banco a banco, por quanto tempo um acesso vale, quem aprova e em que horário um comando pode rodar. A partir daí, a regra não depende de ninguém se lembrar dela. Alguns limites, porém, nenhuma configuração ultrapassa: nenhum acesso passa de 30 dias, e nenhum break-glass passa de 4 horas.

VOCÊ DEFINE
heimdall db expiry set --database pg-orders-orders --class write --default 2h --max 8h
✓ write access to 'orders' now defaults to 2h and is capped at 8h

  Grants already open keep the window they were approved with — withdraw one with
  'heimdall db access revoke <grant-id>', which is attributable and audited.

heimdall db expiry set --database pg-orders-orders --class read --default 8h --max 7d
✓ read access to 'orders' now defaults to 8h and is capped at 7d

  Grants already open keep the window they were approved with — withdraw one with
  'heimdall db access revoke <grant-id>', which is attributable and audited.

heimdall db expiry show --database pg-orders-orders
CLASS  DEFAULT  CEILING  SOURCE
read   8h       7d       configured on this database
write  2h       8h       configured on this database

  A request mixing SELECT with INSERT, UPDATE or DELETE takes the write ceiling.
  No access may ever exceed 30d, whatever is configured here.
  Change one with 'heimdall db expiry set --database pg-orders-orders --class write --default 8h --max 72h'.
A PLATAFORMA FAZ CUMPRIR
heimdall db window add --database pg-orders-orders --kind command --timezone America/Sao_Paulo --days weekdays --from 09:00 --to 18:00
✓ command may be released on 'orders' during weekdays 09:00-18:00 America/Sao_Paulo
  Window ID: 9ab22742-4c85-4537-8f47-b3d826d40588

  Run 'heimdall db window list --database pg-orders-orders' to see whether it is open now.

heimdall db command approve 03fd8c04-9800-4369-a93a-6a1f1431316a
Error: OUTSIDE_EXECUTION_WINDOW: outside the permitted execution window for this database: a command may only be released during weekdays 09:00-18:00 America/Sao_Paulo. The next window opens Mon 2026-10-12 09:00 -03 (in 53h42m)

NO LUGAR DE

Um só modelo de permissão, um só lugar para procurar.

Hoje, cada ponto do ciclo tem ferramenta, fatura e modelo de permissão próprios. O Heimdall coloca tudo isso sob a mesma policy.

NO LUGAR DEO QUE O HEIMDALL OFERECE
Catálogo de serviços Domain, System, Component e environment, que release, incidente, acesso e infraestrutura usam como endereço. Dependência circular recusada. O que cai junto, em um comando
Provisionamento de infraestrutura Resource pedido a partir de um resource schema do seu time, com aprovação de outra pessoa. Terraform rodando no Agente, na sua rede. State no bucket da sua conta de cloud. Federação OIDC no lugar da chave
Gerenciador de secrets O valor fica no seu Agente, cifrado com chave sua, com a trilha de quem leu cada versão. Entrega pelo heimdall run e pelo External Secrets Operator. Uma versão vazada é desativada na hora, e o que a pessoa leu vira at_risk quando ela sai. A senha do service user de banco também é rotacionada
Acesso a banco Cada acesso tem aprovador nomeado e prazo, definidos pela sua organização, e ninguém vê a senha; comando e migration respeitam a janela de horário do banco. O dado sensível é mascarado pela coluna de origem, o guardrail recusa antes de chegar ao banco, e o comando aprovado passa uma vez só. O break-glass tem teto e revisão, e a migration é aprovada e executada dentro da sua rede
Acesso a aplicações internas Aplicações web e APIs pelo browser, sem VPN, e serviços TCP pelo nome real, no terminal. O acesso é concedido por pessoa e por serviço, com prazo e motivo, e cada fluxo fica registrado antes do primeiro byte
Aprovação de deploy O diff exato, aprovado por pessoa nomeada e recusado se o arquivo mudou. Janela e congelamento conferidos no instante antes do commit. Rollback em um passo, para uma versão já aprovada
Gestão de incidentes Um ciclo fixo, que só se encerra com o postmortem aprovado. O rollback abre o incidente, o break-glass fica ligado a ele, e um incidente parado gera aviso

Converse com quem constrói o Heimdall.

Conte como a sua engenharia guarda secrets e acessa o banco hoje. Respondemos dizendo o que o Heimdall colocaria sob regra primeiro e como a implantação chegaria lá.

Falar com engenharia

Abre uma conversa no WhatsApp. Prefere e-mail? heimdall@yops.cloud

O DADO É SEU

Tudo roda na sua infraestrutura, e o dado não sai do seu perímetro.

API, Agente, borda e banco ficam com você, e a chave de criptografia fica sob o seu controle. O valor dos seus secrets, a senha e o resultado das consultas ao seu banco, o state da sua infraestrutura, o conteúdo do seu tráfego e a trilha de auditoria não saem da sua rede.

Ver onde cada coisa fica

IMPLANTAÇÃO

A Yops implanta junto com o seu time.

A implantação é parte do produto. Ela acontece dentro da sua infraestrutura, lado a lado com a sua engenharia, e termina com o seu time operando o Heimdall.

  1. Definir com você a primeira fase: o que passa a seguir as regras primeiro e o que precisa ser construído para isso, com prazo combinado.
  2. Instalar a API, o Agente e a borda na sua infraestrutura, com o seu time.
  3. Colocar os primeiros secrets e bancos sob as regras, já com os seus dados reais.
  4. Treinar quem opera e quem aprova.

Sair não depende de nós: você exporta a organização a qualquer momento, e o state do Terraform já está no seu bucket.

Converse com quem constrói o Heimdall.

Conte como a sua engenharia guarda secrets e acessa o banco hoje. Respondemos dizendo o que o Heimdall colocaria sob regra primeiro e como a implantação chegaria lá.

Falar com engenharia

Abre uma conversa no WhatsApp. Prefere e-mail? heimdall@yops.cloud