01 / 03·REBUILD DE SCHEMA
PRÉ/PÓS-CONDIÇÃO- GATILHO →
- Tabela é dropada e recriada em ciclo de manutenção.
- CONDIÇÃO →
- Tabela estava registrada como coberta por isolamento.
- EFEITO →
- Políticas são reaplicadas automaticamente, sem intervenção manual.
§SEGURANÇA / ARQUITETURA / AUDITORIA
Infra de governança
Governança aplicada por design. Auditoria matematicamente verificável.
Isolamento de dados enforçado no banco, segregação de funções em quatro níveis, histórico imutável com encadeamento criptográfico. Fechado por padrão, demonstrável com evidência.
FIG-01 · CORTE TRANSVERSALv2026.04
Arquitetura em 4 camadasESC 1:1 · LÓGICA
- CAMADA 01·APP / FILTRO
Camada de aplicação
Cada consulta passa por filtros por instituição e por usuário antes de tocar o banco.
BLOCO7f4a·9c21
- CAMADA 02·DB / ISOLAMENTO
Camada de banco
Políticas rodam dentro do próprio PostgreSQL. Bloqueiam acesso cruzado mesmo se um bug na aplicação tentar violar.
BLOCOae3d·b5e2
- CAMADA 03·AUDIT / CADEIA
Camada de auditoria
Registro append-only com encadeamento criptográfico. Alteração posterior quebra a cadeia e é detectável.
BLOCOc407·1fd9
- CAMADA 04·APROVAÇÃO / SoD
Camada de segregação
Operações sensíveis passam por alçadas de um a três aprovadores, configuradas por política do cliente.
BLOCO38c2·e06b
POLÍTICAS560
TABELAS140
SCHEMAS15
SNAPSHOT17 ABR 2026
§01·A POSTURA
Três princípios que sustentam cada decisão de arquitetura.
Antes de descrever mecanismos, é útil declarar a postura. Sem ela, cada item técnico vira detalhe desconexo; com ela, cada item é consequência de uma decisão anterior.
- 01
Fechado por padrão
Acesso é negado até ser concedido. Ausência de política explícita não é permissão — é negação. A responsabilidade de liberar é do operador, não do sistema.
- 02
Duas barreiras independentes
Filtro de aplicação é a primeira. Isolamento enforçado no banco é a segunda. Exploit em uma não vaza para a outra: são decisões tomadas em pontos diferentes da pilha, por razões diferentes.
- 03
Auditabilidade é default
Cada operação relevante fica registrada em histórico imutável. Governança é demonstrável com evidência, não apenas declarada em apresentação.
§02·ISOLAMENTO EM DUAS BARREIRAS
O banco recusa porque recusa — não porque a aplicação filtrou.
Quando a plataforma armazena dados de uma empresa, o isolamento é garantido em duas camadas simultâneas. Elas não substituem uma à outra — operam em paralelo, com razões de existir distintas.
BARREIRA 1 · APLICAÇÃO·CAMADA 1
Filtra cada consulta
Toda consulta passa por filtros por instituição e por usuário antes de ser emitida. É a camada que o time de produto enxerga e mantém.
EFEITOFalha comum: bug de programação deixa passar uma consulta sem filtro.
BARREIRA 2 · BANCO·CAMADA 2
Recusa mesmo se a app falhar
Políticas de isolamento rodam dentro do próprio PostgreSQL. Não conhecem o código da aplicação, não confiam nele. Mesmo que o filtro acima falhe, o banco bloqueia o acesso cruzado.
EFEITORazão de existir: um bug de aplicação não deve virar vazamento de dados.
O resultado é concreto: um usuário com acesso direto ao banco, usando o pool de runtime, não consegue ler dados de uma instituição que não é a dele. O banco recusa antes da aplicação ter chance de filtrar.
SNAPSHOT DE PRODUÇÃO·17 ABR 2026
Em Homologação em 17 de abril de 2026: políticas de isolamento ativas sobre tabelas em operação real, distribuídas em schemas dedicados. O número cresce organicamente à medida que novas tabelas são criadas pelo cliente.
- POLÍTICAS
- 560
- TABELAS
- 140
- SCHEMAS
- 15
Outros contextos na Aether citam "mais de 500 políticas ativas" — esta é a única página que registra o número exato com data.
§03·GOVERNANÇA APLICADA AUTOMATICAMENTE
O esquecimento como categoria de falha.
Um dos maiores vetores de falha em plataformas configuráveis é o momento em que um desenvolvedor ou administrador cria uma nova tabela e esquece de aplicar as políticas corretas. A cobertura de ontem não garante a cobertura de hoje.
Na Aether, esse momento não existe. Quando a plataforma gera uma tabela associada a uma instituição, as políticas de isolamento são aplicadas automaticamente — sem ação manual, sem passo opcional. O crescimento da cobertura é orgânico: cada módulo novo herda a governança do núcleo.
02 / 03·RESTORE DE BACKUP
PRÉ/PÓS-CONDIÇÃO- GATILHO →
- Restore substitui o schema por uma versão anterior.
- CONDIÇÃO →
- Registro de governança da plataforma preservado.
- EFEITO →
- Passo de recuperação posterior reaplica políticas a todas as tabelas que registradamente tinham.
03 / 03·REMOÇÃO ACIDENTAL
PRÉ/PÓS-CONDIÇÃO- GATILHO →
- Alguém tenta remover ou renomear uma coluna usada por políticas de isolamento.
- CONDIÇÃO →
- Política ativa depende da coluna.
- EFEITO →
- Operação é bloqueada com erro explícito antes de completar.
Cada salvaguarda é pré/pós-condição de engenharia, não workflow humano. Operação acidental não degrada cobertura — o sistema recupera sozinho ou recusa em alto e bom som.
§04·SEGREGAÇÃO DE FUNÇÕES — QUATRO NÍVEIS
Quem cria fornecedor não aprova pagamento para ele.
Segregação de funções (SoD) previne conflito de responsabilidades em operações sensíveis. Na Aether, SoD é primeira classe: cada operação relevante pode exigir um de quatro níveis de aprovação, configurado pelo cliente conforme o marco regulatório aplicável.
- N01 · AUTO
Automático
APROVADORES
Nenhuma aprovação adicional.
EXEMPLO TÍPICO
Operação de baixo risco, dentro de limite previamente definido e contexto corriqueiro. - N02 · SIMPLE
Um aprovador
APROVADORES
Um gerente da área responsável.
EXEMPLO TÍPICO
Ajuste operacional acima do limite automático, sem impacto regulatório direto. - N03 · DUAL
Dois aprovadores
APROVADORES
Gerente de área + compliance.
EXEMPLO TÍPICO
Operação com implicação fiscal ou contratual que precisa revisão cruzada antes de concretizar. - N04 · TRIPLE
Três aprovadores
APROVADORES
Gerente de área + compliance + diretor.
EXEMPLO TÍPICO
Operação de alto valor, mudança estrutural, ou item sujeito a controle de auditoria externa.
A política específica de cada operação é configurada pelo cliente, alinhada ao marco regulatório aplicável (SOX, ISO 27001, políticas setoriais).
§05·AUDITORIA COM VERIFICAÇÃO MATEMÁTICA
Governança deixa de ser declaração para virar prova.
Cada operação relevante gera um registro em histórico imutável com três propriedades que permitem verificação externa do log sem confiar na plataforma que o emitiu.
- APPEND-ONLY
Registros não mudam
Depois de emitido, o registro não pode ser alterado nem removido. A única operação permitida é append.
- ENCADEAMENTO CRIPTOGRÁFICO
Cada bloco assina o anterior
Cada registro inclui a assinatura do anterior. Qualquer alteração posterior quebra a cadeia e é detectável por quem a verificar.
- BANCO DEDICADO
Infraestrutura separada
Auditoria roda em infraestrutura separada da operação transacional. Carga operacional não compete com carga de auditoria.
BLOCOS ENCADEADOS · CADA UM ASSINA O ANTERIORFIG-05 · CADEIA DE AUDITORIA
- #001APPROVE7f4a·9c21PREV: ∅
- #002WRITEae3d·b5e2PREV: 7f4a·9c21
- #003ACCESSc407·1fd9PREV: ae3d·b5e2
- #004APPROVE38c2·e06bPREV: c407·1fd9
- #005WRITE6d18·2a50PREV: 38c2·e06b
- #006EMITf9b3·4e87PREV: 6d18·2a50
Os tokens acima são ilustrativos. No log real, cada bloco contém a assinatura do anterior. Quebra de cadeia = alteração detectável. Um auditor externo consegue verificar matematicamente que o log de uma data específica não foi alterado desde a emissão.
COBERTURA REGULATÓRIA
Como essa arquitetura se encaixa em frameworks reconhecidos.
- 01
LGPD
Rastreabilidade completa de acesso a dados pessoais, minimização na apresentação, base legal registrada por operação.
✓ Atende exigências - 02
SOX
Segregação de funções demonstrável, auditoria imutável de transações críticas, quatro níveis de alçada configuráveis.
✓ Atende exigências - 03
ISO 27001
Controles de acesso baseados em contexto, logging centralizado, gestão de segredos alinhada ao padrão.
◐ Arquitetura compatível · certificação em roadmap - 04
SOC 2
Observabilidade, gestão de acesso, monitoramento contínuo dos principais pontos de controle.
◐ Arquitetura compatível · certificação em roadmap
LGPD e SOX são frameworks legais/regulatórios com exigências de capability — a plataforma atende. ISO 27001 e SOC 2 são certificações formais: a arquitetura é compatível, o processo de certificação é calendário, não capability.
§06·CONTROLE DE ACESSO EM CAMADAS
A decisão não é "permitido ou negado" simplista.
Decisão de autorização na Aether passa por múltiplas camadas combinadas. Cada camada responde a uma pergunta diferente e, juntas, elas determinam se a operação segue em frente, exige aprovação, ou é recusada.
- L01CONTEXTO
Usuário autenticado, instituição selecionada, unidade de operação definida. Sem contexto, não há decisão — a operação é recusada por ausência de ancoragem.
- L02PAPEL
O que esse usuário pode fazer no contexto estabelecido. Papel é concedido, nunca presumido.
- L03ISOLAMENTO
Dentro do que o papel permite, ele vê apenas os dados da sua instituição. Filtro em aplicação, enforcement no banco.
- L04ATRIBUTOS DO OBJETO
Decisão sensível pode exigir aprovação adicional dependendo do valor, do horário, do tipo de cliente ou do marco regulatório aplicável.
- L05CONTROLES DO AGENTE
Se a operação é feita por uma IA (Nous), controles adicionais como rate limit, validação de conteúdo sensível e escopo read-only se aplicam.
Resultado prático: a decisão é contextual, auditável e registrável. Cada recusa é tão rastreável quanto cada autorização.
§07·CRIPTOGRAFIA E GESTÃO DE SEGREDOS
Três frentes tratadas com o mesmo rigor.
- REPOUSO
Dados em repouso
Dados sensíveis são criptografados com algoritmos atualizados. Chave por instituição, sem reuso entre clientes.
- CERTIFICADOS
Certificados digitais
Cada cliente opera com certificados próprios, armazenados com proteção criptográfica adequada ao marco regulatório aplicável.
- TRANSPORTE
Comunicação entre pontas
Comunicação entre plataforma e clientes usa TLS atualizado. Integração com órgãos fiscais usa os padrões exigidos pelos órgãos correspondentes.
§08·READ-ONLY VS WRITE
O limite de vetor da IA é escrito, não declarado.
O Nous, assistente de IA da plataforma, não representa vetor de alteração silenciosa de dados. O escopo atual e o planejado são diferentes — e a diferença está desenhada no produto, não na postura de uso.
HOJE · READ-ONLY EFFECTIVE·EM HOMOLOGAÇÃO HOJE
Consulta sob permissões do usuário
O assistente opera em modo de leitura. Consulta dados respeitando as mesmas políticas de isolamento e alçada que se aplicam ao usuário em sessão. Não executa ações de escrita.
- Sem capacidade de modificar dados por iniciativa própria
- Mesmas políticas de RLS do usuário em sessão
- Auditoria do que foi consultado, sem distinção de canal
PLANEJADO · WRITE GATEADO·PLANEJADO PARA O PRÓXIMO CICLO
Escrita sempre com confirmação
Ações governadas pelo Nous são planejadas com modelo de confirmação explícita antes da execução. Quando entrar em homologação, cada ação de escrita passa por aprovação do operador, registrada em auditoria como qualquer outra.
- Nenhuma escrita autônoma — sempre passa pelo operador
- Sujeita aos mesmos níveis de alçada (SoD) de qualquer operação humana
- Ainda não disponível: modelo fica inativo até entrega formal
Relevante para o CIO: a IA da plataforma não representa vetor de alteração silenciosa de dados. Hoje por desenho, amanhã por gateway de confirmação.
§09·O QUE AINDA ESTÁ EM CONSTRUÇÃO
Honestidade sobre limites atuais.
Certificações e expansões em roadmap. A arquitetura é compatível; o processo formal é calendário, não capability.
- 01 / 03CAPABILITY
Certificações formais (ISO 27001, SOC 2)
Arquitetura compatível com as exigências de cada framework. O processo formal de certificação é calendário, não capability — e não pode ser declarado como concluído antes de sê-lo.
STATUSARQUITETURA COMPATÍVEL · CALENDÁRIO, NÃO CAPABILITY
- 02 / 03CAPABILITY
Multi-região
Clusters dedicados hoje operam em uma região única por cliente. Expansão para multi-região está planejada, sem cronograma público vinculante.
STATUSREGIÃO ÚNICA HOJE · EXPANSÃO EM ROADMAP
- 03 / 03CAPABILITY
Pen test periódico documentado publicamente
Pen test é política interna contínua. Publicação recorrente de resultados sanitizados ainda não é prática; decisão de cadência fica para quando houver público externo qualificado demandando.
STATUSPOLÍTICA INTERNA · PUBLICAÇÃO NÃO RECORRENTE
✕FIM DO DOCUMENTO · ARQUITETURA AETHERv2026.04
Revisar esta arquitetura com sua engenharia.
Se o próximo passo for um diálogo técnico profundo, é assim que começamos: documento em mesa, arquiteto contra arquiteto, sem camada de venda.