Modelo de ameaças

Este é o modelo de ameaças da plataforma como ela roda em 30/09/2026: uma célula em us-east-2, com uma máquina k3s e um PostgreSQL gerenciado. Cada controle aponta para o arquivo ou a configuração que o implementa nos repositórios da Niadra (niadra-back, o servidor; niadra-infra, a nuvem e o cluster; niadra-frontend, o site e o Console), que o seu time de segurança pode ler sob acordo de confidencialidade. A última seção diz o que fica sem controle, ou com controle parcial.

​

Ativos

O que a plataforma protege, do mais sensível ao menos:

​

Fronteiras de confiança

Cada linha é uma fronteira que o tráfego cruza, quem está de cada lado e o que a atravessa.

​

Ameaças por componente

Para cada componente, a ameaça, o controle que existe hoje e onde ele está. “Teste” nomeia o teste que prova o controle no CI do servidor, que roda em todo pull request contra PostgreSQL, PgBouncer, RabbitMQ e Redis reais (niadra-back/.github/workflows/ci.yml).

​

Borda pública

​

Autenticação e autorização

​

Banco de dados e isolamento entre clientes

​

Chaves e criptografia

​

Modelos de IA

​

Saídas para endpoints do cliente

​

Auditoria

​

Logs e observabilidade

​

Cadeia de entrega

​

Disponibilidade

​

Riscos residuais

O que este desenho não cobre hoje, dito como está.

1. Uma máquina e uma zona. A célula roda numa máquina k3s e num RDS sem Multi-AZ. A perda da máquina ou da zona derruba a API e o Console até a reconstrução pelo template (scripts/stack.sh e uma implantação); a perda do banco volta pela cópia automática da instância ou pelos pg_dump da noite anterior. O tempo de reconstrução não foi medido. O caminho para duas máquinas a mais e um banco Multi-AZ está descrito no niadra-infra/README.md e não está implantado.
2. Trânsito em claro dentro do nó. Entre os pods, o pooler de conexões, o cache e a fila o tráfego não é cifrado; ele não sai da máquina, e a política de rede limita quem alcança cada processo. O TLS 1.3 começa na borda e no salto do pooler ao banco. Quem tiver acesso de administrador ao nó vê esse tráfego.
3. Texto mascarado sai da região. A extração e as decisões vão ao OpenRouter e daí à OpenAI e à TypeSafe, fora de us-east-2, com retenção zero pedida em cada chamada. O mascaramento é por regras e por um detector; um valor que os dois deixem passar viaja como texto. O provedor de decisão não publica região nem prazo de retenção próprios.
4. Cópia da instância guarda tudo junto. A cópia automática do RDS contém o banco da célula (com as chaves embrulhadas) e os bancos dos espaços; restaurar a instância inteira traria um espaço apagado de volta, até a cópia expirar. Por isso o comprovante de apagamento de um espaço diz quando expira a última cópia. Hoje a cópia da instância dura um dia (o plano da conta); as cópias noturnas por banco duram 35 dias.
5. Varredura só das dependências de código. Uma vulnerabilidade conhecida nas dependências barra o merge (o questionário diz como), mas os pacotes do sistema das imagens de contêiner não são varridos, e as dependências de desenvolvimento dos repositórios de TypeScript não barram. Um aviso publicado depois do merge só aparece na próxima execução da auditoria.
6. Sem teste de invasão e sem certificação própria. Os selos ISO 27001, SOC 2 e PCI DSS são da nuvem em que a Niadra roda, não da Niadra. O teste de invasão por empresa independente entra no contrato do plano Regulado.
7. Uma pessoa de plantão. Os alertas chegam ao fundador; não há time de plantão em turnos. O plano de resposta a incidentes diz o que isso significa em tempo de resposta.
8. Acesso operacional existe. A operação da Niadra alcança a máquina pelo Systems Manager e os bancos pelos runbooks, para restaurar e apagar espaços. Esse acesso fica no CloudTrail da conta e, quando toca um espaço, deixa comprovante admin; não há um segundo aprovador para ele.

​

Próximos passos