Segurança por estrutura, não por correção

O OmegaOS™ é fail-closed por defeito, apenas de adição por estrutura e apenas consultivo por desenho. Cada mitigação é estrutural — integrada no esquema, no runtime e no modelo de implementação.

Modelo de ameaças

🔒

Acesso não autorizado a dados

Mitigado por Row-Level Security (RLS) aplicado por tenant ao nível do Postgres, complementado por autenticação por chave API com ~285 bits de entropia.

📓

Adulteração do registo de auditoria

Mitigado por esquema apenas de adição. Os serviços de runtime (hovo_app) apenas podem INSERT — sem UPDATE ou DELETE em tabelas do registo. Revogações criam novos registos.

🔑

Contorno de licença

Mitigado por verificação Ed25519 offline. Chave pública incorporada em tempo de compilação. Sem servidor de licenças, sem dependência de rede. Tokens adulterados falham na verificação criptográfica.

🔎

Fugas de builds

Mitigado por impressão digital do build. Cada binário incorpora git_sha + build_timestamp + customer_tag em tempo de compilação. A impressão digital aparece nos health checks e nos registos de decisão.

Fail-closed por defeito

Quando o PDP upstream não está acessível ou a avaliação falha, o gateway aplica DENY por defeito em modo enforce. Isto é controlado por OPA_FAIL_MODE, que tem o valor closed por defeito.

Sistemas fail-open concedem acesso silenciosamente quando falham. Sistemas fail-closed bloqueiam o acesso quando falham. Para ambientes sensíveis à conformidade, fail-closed é o padrão seguro.

Cenário	Fail-Closed	Fail-Open
OPA inacessível	403 Forbidden	Permit sintético (registado)
Erro interno	403 Forbidden	Permit sintético (registado)
Licença expirada	Auto-downgrade para OBSERVE

Desenho apenas consultivo. O OmegaOS™ produz decisões estruturadas que informam operadores humanos. Não executa autonomamente ações a jusante. Nos modos observe e shadow, é puramente consultivo.

Row-Level Security

Cada consulta passa pelas políticas RLS do Postgres. O papel hovo_app só pode aceder a linhas que correspondem ao contexto do tenant atual, definido no início de cada transação.

Mesmo que um atacante consiga injeção SQL através da camada aplicacional, não pode aceder aos dados de outro tenant — a base de dados aplica o isolamento ao nível da linha.

Papel	RLS	Utilizado por
hovo_admin	BYPASSRLS	Ferramentas CLI, migrações
hovo_app	Aplicado	hovo-api, hovo-gateway

Garantia chave: hovo_admin nunca é utilizado por serviços de runtime. Está restrito a ferramentas de operador que funcionam separadamente.

Registo apenas de adição

Seis tabelas do registo são INSERT-only para o papel de runtime. Nenhuma decisão pode ser alterada retroativamente.

 -- Grants para hovo_app (serviços de runtime): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- Sem UPDATE ou DELETE concedido.
-- Revogações são novos registos INSERT, não eliminações.
-- Histórico completo sempre disponível para auditoria. 

Integridade da evidência

Cadeia de custódia HMAC-SHA256 da fonte externa ao registo de decisão.

Conectores externos (CRIF, Zefix, WorldCheck) assinam cada item de evidência com HMAC-SHA256, criando uma cadeia de custódia infalsificável da fonte externa ao registo de decisão. Evidência que chegue sem assinatura HMAC válida pode ser sinalizada ou rejeitada na ingestão — comprovando a integridade dos dados na camada aplicacional, independentemente da encriptação de transporte.

Tags de separação de domínio (OMEGAOS:EVIDENCE:v1:) previnem colisão de hashes entre contextos de segurança.

Propriedade	Valor
Algoritmo	HMAC-SHA256
Separação de domínio	`OMEGAOS:EVIDENCE:v1:`
Âmbito	Por item de evidência, por conector
Verificação	Na ingestão — antes da decisão

Cadeia de prova criptográfica

Três camadas criptográficas independentes — cada uma verificável sem confiar nas outras.

Árvore de Merkle (RFC 9162)

Cada decisão é encadeada numa árvore de Merkle apenas de adição. Qualquer modificação retroativa quebra o hash raiz. Provas de inclusão são verificáveis em O(log n) operações sem revelar outras decisões.

Assinaturas Ed25519

Manifestos de exportação, licenças e atestações de build são assinados com Ed25519. Chave pública incorporada em tempo de compilação. A verificação é totalmente offline — sem serviço externo necessário.

Carimbos Temporais RFC 3161

As raízes Merkle são periodicamente ancoradas a uma Autoridade de Carimbo Temporal qualificada (RFC 3161, conforme com ZertES e eIDAS). Fornece prova juridicamente vinculativa de temporalidade da decisão, admissível em tribunais suíços e da UE.

Verificação formal

Os cinco invariantes do sistema são formalmente especificados em TLA+ e verificados pelo model checker TLC em espaços de estado finitos. Trata-se de verificação de modelos — exploração exaustiva de um espaço de estado limitado — não de prova de teoremas.

Os invariantes verificados são:

Indeterminado é o primitivo — T/F requerem resolve()
Registo apenas de adição — sem UPDATE, sem DELETE
Determinismo — mesmas entradas produzem mesmas saídas
Isolamento de tenants — sem acesso a dados entre tenants
Sem ação irreversível automática — humano no circuito obrigatório

Especificação	Âmbito
OmegaResolve.tla	Determinismo, sem T/F primitivo, isolamento de tenant
OmegaLedger.tla	Apenas adição, cadeia de hash, sem mutação
OmegaInvariants.tla	Todos os 5 invariantes combinados

Nuance: O TLC verifica invariantes num modelo finito. Isto prova a ausência de violações no espaço de estado explorado. Para prova matemática completa, seria necessária prova formal de teoremas (e.g. Coq, Isabelle) — isto não é reivindicado.

Autenticação por chave API

Formato: delk_ + 48 caracteres alfanuméricos (~285 bits de entropia)
Armazenamento: Hash bcrypt (custo 12) — texto simples mostrado uma vez na geração
Rotação: Máximo de 2 hashes por tenant para rotação de chaves sem interrupção
Mapeamento: Chave API → tenant_id é a única fonte de verdade para o contexto RLS

Verificação de licença

Algoritmo: Verificação de assinatura Ed25519
Gestão de chaves: Chave pública incorporada no binário em tempo de compilação
Rede: Totalmente offline — sem servidor de licenças, sem phone-home
Fallback: Tokens expirados/inválidos fazem auto-downgrade do gateway para OBSERVE

Marca de água de build

Cada binário incorpora uma impressão digital forense em tempo de compilação para rastreabilidade.

 # Impressão digital incorporada no build: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Aparece em: # - Resposta /gateway/health # - Resposta /api/v1/health # - Logs estruturados para cada decisão 

Vinculação de customer tag: As licenças podem opcionalmente incluir um customer_tag que deve corresponder ao tag incorporado no build. Tags não correspondentes fazem com que a licença falhe — prevenindo a reutilização de licenças entre builds de clientes diferentes.

Reforço de rede

Kubernetes

A NetworkPolicy restringe o tráfego: apenas o gateway aceita conexões externas. A API é interna ao cluster. Ferramentas de administração funcionam como Jobs pontuais, não como implementações persistentes.

Limites HTTP

Tamanho máximo do corpo: 1 MiB (configurável). Timeout de pedido: 30 segundos. Timeout de conexão OPA: 3 segundos. Timeout de leitura OPA: 10 segundos. Tudo configurável via variáveis de ambiente.

Segurança de contentor

Utilizador não root (65534), sistema de ficheiros raiz apenas de leitura, todas as capabilities removidas, perfil seccomp RuntimeDefault. Sem escalação de privilégios permitida.

Infraestrutura & Jurisdição

A infraestrutura que suporta este website está alojada na Suíça e opera sob jurisdição suíça.

Dados alojados na Suíça
Sujeito ao quadro jurídico suíço
Sem transferência intencional de dados para fora da Suíça
Sem análise comportamental de terceiros

Explore as opções de implementação

A arquitetura de segurança é consistente em todas as edições. Escolha o âmbito de implementação que corresponde aos seus requisitos de governança.

Explorar Edições