Modelo de segurança

Status da revisão: Esta página-base exige revisão especializada antes da aprovação pública. Suas afirmações devem permanecer dentro do escopo declarado aqui.

A UbID aplica defesa em profundidade a todo o ciclo de vida da identidade. Nenhum controle isolado — senha, passkey, verificação biométrica, assinatura, banco de dados criptografado, referência blockchain ou dashboard de monitoramento — é considerado suficiente por si só.

O modelo de segurança conecta controles preventivos, validação, detecção, evidência e recuperação, para que uma fraqueza em uma camada não comprometa automaticamente todo o sistema de confiança.

Objetivos de segurança

Os objetivos públicos de segurança da UbID são:

• proteger as credenciais do titular e seu controle criptográfico;
• impedir emissão, apresentação, recuperação e ações administrativas não autorizadas;
• assegurar que verificadores rejeitem evidência inválida, desatualizada, não confiável ou inadequada ao contexto;
• isolar chaves institucionais do acesso comum das aplicações;
• limitar cada participante e serviço à autoridade necessária;
• detectar eventos anormais de serviço, política, dispositivo, credencial e recuperação;
• preservar evidência suficiente para investigação sem expor material secreto;
• recuperar-se com segurança de perda de dispositivo, rotação de chaves, falha de serviço e incidentes de segurança.

Camadas de defesa em profundidade

Camada	Responsabilidade de segurança
Proofing de identidade	Estabelecer evidência antes de emitir claims de alto valor ou aprovar ações sensíveis.
Autenticação	Confirmar o controle de um autenticador e de uma sessão aprovados.
Autorização	Determinar se um ator pode executar uma operação específica.
Ciclo de vida das credenciais	Proteger emissão, assinatura, entrega, status, renovação, suspensão e revogação.
Custódia do titular	Proteger credenciais, chaves locais, dispositivos e consentimento de apresentação.
Verificação	Validar confiança do emissor, integridade, status, atualidade, contexto e política.
Recuperação	Restaurar o controle legítimo por autorização em etapas, distribuída e evidenciada.
Controle criptográfico	Separar finalidade, política, versão, provedor e ciclo de vida das chaves.
Segurança da plataforma	Aplicar identidade de serviço, menor privilégio, transporte protegido, isolamento e entrega segura.
Operações	Detectar falhas, encaminhar alertas, investigar eventos e testar procedimentos de restauração.

Princípios Zero Trust

Zero Trust na UbID significa que a confiança não é herdada apenas porque uma solicitação vem de uma rede interna, de uma sessão autenticada ou de um dispositivo anteriormente aprovado.

Operações sensíveis exigem validação explícita das condições relevantes, que podem incluir:

• identidade do ator e do serviço;
• finalidade e escopo da operação;
• status da credencial ou do dispositivo;
• contexto e atualidade da transação;
• versão da política;
• evidência de autorização;
• status da chave e do algoritmo;
• assurance do ambiente quando aplicável.

A interface do usuário pode exibir ações disponíveis, mas decisões autoritativas de política são tomadas por serviços controlados.

Separação de funções

Operações de alto impacto não devem depender de um único ator irrestrito. A separação de funções pode ser aplicada a:

• preparação de credenciais e emissão final;
• alteração e aprovação de políticas;
• administração de chaves e uso por aplicações;
• solicitação de recuperação e liberação protegida;
• coleta de evidência e decisão final de negócio;
• interpretação por IA e execução determinística.

Isso reduz o risco de que uma conta, serviço, administrador ou agente automatizado comprometido execute silenciosamente uma ação sensível de ponta a ponta.

Comportamento fail-closed

Quando uma condição de confiança obrigatória não pode ser validada, o padrão seguro é interromper ou retornar um resultado indeterminado, em vez de aceitar silenciosamente evidência mais fraca.

Exemplos incluem:

• emissor não confiável ou não resolvido;
• algoritmo não permitido;
• credencial expirada, suspensa ou revogada;
• ausência de atualidade ou vínculo de audiência;
• falha na verificação da relação com o titular;
• fonte autoritativa de política ou status indisponível;
• etapa de recuperação não autorizada.

Medidas de disponibilidade e caminhos de fallback devem permanecer mais restritos do que o acesso normal e produzir evidência clara.

Evidência e revisão de segurança

Os controles de segurança devem produzir evidência que apoie:

• revisão de arquitetura e ameaças;
• testes de controles internos;
• investigação do ciclo de vida de credenciais e dispositivos;
• rotação de chaves e resposta a incidentes;
• exercícios de recuperação;
• assurance independente e auditoria.

A evidência deve ser minimizada. Registrar um segredo para provar que um controle foi executado invalida o propósito do controle.

Responsabilidade compartilhada

A UbID fornece capacidades de segurança, mas cada deployment deve configurá-las e operá-las adequadamente. As instituições continuam responsáveis por governança, atribuição de funções, aplicação de patches, infraestrutura segura, aceitação de riscos, resposta a incidentes, testes, supervisão de fornecedores e obrigações regulatórias.

Limite da documentação pública

O portal público exclui design de rede de produção, limiares de segurança, hostnames privados, regras detalhadas de fallback, identificadores de chaves, modelos antiabuso, vulnerabilidades, procedimentos de incidentes e critérios internos de aceitação.

Consulte Autenticação e segurança de dispositivos, Proteção criptográfica e Auditabilidade e observabilidade.