Esta página pode estar parcialmente traduzida. Alguns conteúdos são apresentados em inglês.

Nota de arquitetura de segurança

Propriedades estruturais, pressupostos e comportamento em caso de falha do OmegaOS™ Kernel.

Âmbito & pressupostos

Esta página descreve as propriedades estruturais de segurança do runtime do OmegaOS™ Kernel tal como foi concebido. Abrange o motor de decisão, o registo de auditoria e o modelo de implementação do operador.

Pressupostos

  • O operador controla o ambiente de implementação.
  • O operador é responsável pelo perímetro de rede, pelo reforço do OS do servidor e pelo controlo de acesso à implementação.
  • O runtime não realiza chamadas de rede de saída durante a avaliação de políticas.
  • O OmegaOS™ Kernel é apenas consultivo por defeito. Nos modos observe e shadow, produz decisões sem executar ações a jusante.

O que esta página não cobre

  • Federação de identidade na camada aplicacional (responsabilidade do operador).
  • Vulnerabilidades do OS do servidor ou do runtime de contentor (específico da implementação).
  • Negação de serviço na camada de rede (preocupação de infraestrutura).
  • Resultados de testes de penetração (não publicados publicamente).

Propriedades estruturais

Defeito fail-closed

Quando o motor de políticas é inatingível ou a avaliação falha, o gateway aplica DENY por defeito em modo enforce. O fail-open não é uma configuração disponível.

Registo apenas de adição

Os serviços de runtime apenas podem criar novos registos. Sem modificação ou eliminação de entradas do registo. As revogações criam novos registos, não eliminações.

Isolamento de dados multi-tenant

Cada consulta é filtrada através de políticas de isolamento ao nível da infraestrutura. Os serviços de runtime acedem apenas a registos pertencentes ao contexto do tenant atual.

Design apenas consultivo

O OmegaOS™ Kernel produz decisões estruturadas que informam operadores humanos. Não executa autonomamente ações a jusante.

Comportamento em caso de falha

Cada caminho de falha assume como defeito o estado mais restritivo. Sem concessão silenciosa, sem autorização sintética.

CenárioComportamento
Motor de políticas inatingível DENY (modo enforce)
Erro interno durante avaliação DENY (modo enforce)
Licença expirada Auto-downgrade para OBSERVE
Evidência sem assinatura válida Sinalizada ou rejeitada na ingestão

Modelo de isolamento de tenant

O isolamento de dados ao nível da infraestrutura é aplicado ao nível do registo. Mesmo que um atacante consiga injeção através da camada aplicacional, o acesso entre tenants é estruturalmente impedido.

Nível de acessoIsolamentoUtilizado por
Administrativo Acesso total Ferramentas de operador, migrações
Runtime Limitado ao tenant Serviços aplicacionais
Limite: O acesso administrativo nunca é utilizado por serviços de runtime. Está restrito a ferramentas de operador que funcionam separadamente.

Integridade criptográfica

Autenticação de evidências

Cada item de evidência é autenticado criptograficamente na ingestão. Evidências que chegam sem uma assinatura válida podem ser sinalizadas ou rejeitadas — provando a integridade dos dados na camada aplicacional, independente da encriptação do transporte.

PropriedadeValor
AutenticaçãoCódigo de autenticação de mensagem
Separação de domínioPor contexto de segurança
ÂmbitoPor item de evidência
VerificaçãoNa ingestão — antes da decisão

Cadeia de prova

Cada decisão é encadeada numa estrutura criptográfica apenas de adição. A modificação retroativa quebra a verificação de integridade. As provas de inclusão são verificáveis sem revelar outras decisões.

Assinaturas digitais

Os manifestos de exportação, licenças e atestações de build são assinados com assinaturas digitais criptográficas. A verificação é totalmente offline.

Marcação de tempo de confiança

As raízes criptográficas são periodicamente ancoradas a uma Autoridade de Marcação de Tempo externa. Quando configurada com uma TSA qualificada, as marcações de tempo podem suportar requisitos de temporalidade probatória ao abrigo do ZertES e eIDAS. O efeito jurídico depende da jurisdição e do contexto.

Limite do operador

Isolamento de rede

Apenas o gateway aceita ligações externas. Os serviços internos não são acessíveis externamente. As ferramentas administrativas funcionam como processos isolados, não como serviços persistentes.

Isolamento de runtime

Execução não-root, sistema de ficheiros apenas de leitura, capacidades desnecessárias removidas. Sem caminho de escalada de privilégios.

Controlos de pedidos

Limites configuráveis no tamanho dos pedidos, timeouts de ligação e timeouts de avaliação. Parâmetros ajustáveis por implementação.

Verificação formal

Cinco invariantes do sistema são formalmente verificados usando verificação matemática de modelos sobre espaços de estados finitos. Trata-se de exploração exaustiva de um espaço de estados delimitado — não de prova de teoremas.

  • INDETERMINATE é o primitivo — ALLOW/DENY requerem resolução explícita
  • Registo apenas de adição — sem modificação, sem eliminação
  • Determinismo — as mesmas entradas produzem as mesmas saídas
  • Isolamento de tenant — sem acesso entre tenants
  • Sem ação automática irreversível — requer intervenção humana
ÂmbitoInvariantes cobertos
Resolução de decisõesDeterminismo, lógica tri-estado, isolamento de tenant
Registo de auditoriaApenas adição, cadeia de integridade, sem mutação
Modelo combinadoTodos os 5 invariantes combinados
Nota de âmbito: A verificação de modelos verifica invariantes sobre um modelo finito. Isto prova a ausência de violações no espaço de estados explorado. A prova matemática completa exigiria prova formal de teoremas — o que não é afirmado.

Autenticação API

  • Credenciais: Chaves API criptograficamente fortes
  • Armazenamento: Hash seguro
  • Rotação: Rotação de chaves sem interrupção suportada
  • Mapeamento: Chave API mapeada ao contexto do tenant para isolamento de dados

Verificação de licença

  • Método: Verificação criptográfica
  • Gestão de chaves: Verificação por chave integrada
  • Rede: Totalmente offline
  • Fallback: Degradação gradual na expiração

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

Documentação relacionada

O Artefacto Técnico descreve a semântica de runtime. As Edições cobrem o âmbito de implementação.