Proteção criptográfica
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 avalia a proteção criptográfica em três estados da informação:
- dados em repouso, enquanto armazenados em um dispositivo ou sistema institucional;
- dados em trânsito, enquanto se movem entre participantes e serviços;
- dados em uso, enquanto uma operação autorizada processa informação sensível.
Proteger apenas um estado é insuficiente. A criptografia de um banco de dados não protege um segredo exposto a uma aplicação com privilégios excessivos, e transporte seguro não corrige governança de chaves inadequada.
Proteção em repouso
Dados do titular e da instituição devem ser armazenados de forma criptografada, apropriada à sua sensibilidade. Os princípios públicos incluem:
- criptografia autenticada;
- contexto de criptografia único e salvaguardas contra reutilização;
- separação entre dados criptografados e material de chaves;
- isolamento de dispositivo e aplicação;
- envelopes versionados que permitam migração controlada;
- testes de backup e recuperação;
- exclusão segura e evidência de ciclo de vida.
Uma tecnologia de armazenamento não é um cofre seguro por si só. A propriedade de segurança vem de como as chaves são derivadas, protegidas, usadas, rotacionadas e removidas da memória.
Proteção em trânsito
A proteção de transporte deve fornecer confidencialidade, integridade, autenticação entre pares e resistência a replay ou direcionamento indevido.
Diferentes fluxos da UbID podem usar protocolos web, mensagens seguras entre agentes ou canais específicos de aplicações. Em todos os casos, a decisão de confiança deve estar vinculada ao participante, à finalidade e à transação pretendidos, e não depender apenas da localização de rede.
Proteção em uso
Algumas operações sensíveis exigem isolamento mais forte enquanto os dados são processados. Serviços criptográficos governados e execução confidencial podem reduzir a exposição, assegurando que as aplicações recebam somente o resultado de uma operação aprovada, e não material de chaves irrestrito.
Quando execução protegida é utilizada, attestation e política de workload devem estabelecer que o código e o ambiente esperados estão em execução antes da liberação de material sensível. Execução confidencial não substitui software seguro, patches, controle de acesso, monitoramento ou revisão independente.
Finalidade e separação de chaves
Finalidade, proprietário, ambiente, algoritmo, provedor e ciclo de vida de uma chave são dimensões arquitetônicas separadas.
Finalidades diferentes devem usar identidades de chave e políticas distintas, por exemplo:
- emissão de credenciais;
- autenticação de serviços;
- criptografia protegida de documentos;
- proteção de recuperação;
- integridade de auditoria;
- ambientes de teste e produção.
Usar uma chave para finalidades não relacionadas torna mais difícil conter comprometimentos e interpretar evidências.
Operações criptográficas controladas
As aplicações devem solicitar uma operação limitada e aprovada — como assinatura, criptografia, descriptografia, verificação ou wrapping — sem receber a chave institucional subjacente.
O plano de controle criptográfico deve avaliar:
- identidade e autorização do chamador;
- finalidade e versão atual da chave;
- operação e algoritmo permitidos;
- ambiente e contexto da transação;
- estado do ciclo de vida;
- evidência e controles de taxa.
Credenciais root ou administrativas irrestritas não devem ser usadas por serviços comuns de aplicações.
Ciclo de vida das chaves
Um ciclo de vida governado inclui:
- criação e atribuição de proprietário;
- ativação para uma finalidade aprovada;
- uso monitorado;
- rotação e coexistência;
- suspensão ou revogação após comprometimento;
- retirada e requisitos de arquivamento;
- destruição quando apropriado;
- backup e recuperação testados.
Verificadores e partes confiantes devem conseguir distinguir validade histórica do status atual da chave.
Criptoagilidade
Criptoagilidade é a capacidade de alterar algoritmos, tamanhos de chave, provedores, formatos e políticas de confiança sem perder o controle da evidência histórica nem quebrar todas as integrações de uma só vez.
Ela exige inventários, políticas versionadas, testes de compatibilidade, planos de migração, rótulos claros de assurance e rejeição de comportamentos de downgrade não aprovados.
Chaves do titular e institucionais
Chaves controladas pelo titular e chaves institucionais têm finalidades diferentes. Proteger uma chave de assinatura do emissor não torna a instituição proprietária da identidade do titular. Da mesma forma, o controle do titular não o autoriza a alterar claims institucionais.
Limite da documentação pública
O portal não publica chaves privadas, nomes secretos, credenciais de fornecedores, caminhos internos de chaves, procedimentos de unsealing, pacotes de backup, recovery shares, algoritmos exatos de produção nem cronogramas de rotação.
Consulte UbID KeyVault, Preparação pós-quântica e Modelo de segurança.