Visão geral – Proteger identidades e segredos

A iniciativa SFI (Secure Future Initiative) é uma iniciativa multianual da Microsoft para proteger cada vez mais a maneira como a Microsoft projeta, compila, testa e opera seus produtos e serviços. O SFI é baseado em:

  • Um conjunto de princípios de segurança que impulsionam a maneira como inovamos no design de segurança, implementamos essas inovações em produtos da Microsoft como padrões e padrões seguros e fornecemos diretrizes de segurança internas e externas. Saiba mais.
  • Um conjunto de pilares e objetivos de segurança priorizados. Saiba mais.

Este artigo fornece uma visão geral do pilar SFI "Proteger identidades e segredos".

Antes de começar

Pilar e objetivos

O pilar "Proteger identidades e segredos" visa:

  • Fortaleça a confiança em todas as identidades e credenciais usadas em sistemas da Microsoft eliminando pontos fracos na forma como contas, tokens e segredos são emitidos, armazenados e usados.
  • Reduza o risco de acesso não autorizado aplicando padrões para proteger a infraestrutura de identidade e segredos e controlar a autenticação e a autorização do usuário e do aplicativo.

Os objetivos da Microsoft e o mapeamento de Confiança Zero/NIST para esse pilar são resumidos na tabela a seguir.

Objetivo do pilar Confiança Zero Mapeamento NIST
1. Proteger chaves de assinatura criptográficas

Proteja a assinatura e as chaves de plataforma da infraestrutura de identidade com a rotação rápida e automática de chaves de infraestrutura de identidade, utilizando o armazenamento e a proteção de hardware.		 Verifique explicitamente: proteja os ativos de assinatura de identidade. Incorpore forte verificação de chaves nos fluxos de trabalho.

Suponha violação: proteja as chaves como se o comprometimento possa ocorrer, usando o isolamento assistido por hardware.		 PR. AA-04 (o Access é restrito usando segmentação e privilégios mínimos)
A proteção de chave depende da segmentação de acesso estrita e da autorização de privilégio mínimo para restringir o uso de chaves a ambientes isolados e dedicados do cofre de chaves e remover caminhos desnecessários de acesso e movimentação lateral para o armazenamento de chaves.

PR.PS-01 (os ativos são formalmente avaliados para garantir que atendam aos requisitos de segurança antes de serem aprovados para uso)
As chaves devem ser geradas e armazenadas de acordo com os padrões seguros por padrão.
2. Adote SDKs padrão para o gerenciamento de identidade

Fortaleça os padrões de identidade e impulsione a adoção de padrões com o uso de SDKs padrão entre aplicativos, para que aplicativos e serviços usem uma biblioteca uniforme e protegida para validar tokens.		 Verifique explicitamente: as bibliotecas validadas padrão reduzem a variabilidade e o risco. Use a validação consistente.

Assuma a violação: Reduz a superfície de ataque associada a implementações personalizadas.		 PR. AA-01 (as identidades são autenticadas proporcionalmente ao risco)
O uso de SDKs padrão impõe fluxos de autenticação fortes e consistentes.

PR.AA-02 (acesso é autorizado usando atributos baseados em função)
Os SDKs Standard integram-se ao RBAC do Microsoft Entra e impõem declarações de token com reconhecimento de função.

PR.AA-03 (O acesso é autorizado usando atributos baseados em atributos/contextuais)
Os SDKs Standard aplicam automaticamente acesso condicional, contexto do dispositivo, requisitos de MFA e sinais de risco para autorização contextual.
3. Implementar MFA resistente ao phishing

Verifique se as contas de usuário estão protegidas com MFA resistente a phishing e gerenciada com segurança.		 Verifique explicitamente: técnicas de autenticação fortes verificam a identidade do usuário a cada tentativa de acesso.

Use privilégios mínimos: o MFA fortalece a imposição de privilégios mínimos reduzindo o acesso não autorizado.		 PR. AA-01 (as identidades são autenticadas proporcionalmente ao risco)
A MFA resistente a phishing usa autenticação forte e aplicável ao risco.

PR.AA-03 (O acesso é autorizado usando atributos baseados em atributos e contextuais)
A MFA resistente a phishing fortalece as decisões de acesso contextual.
4. Padrão de segredos seguros

Afaste-se de segredos de longa duração, como credenciais de conta de serviço, para garantir que os aplicativos sejam protegidos com credenciais gerenciadas pelo sistema, como identidades gerenciadas.		 Use privilégios mínimos: restringir o acesso a segredos. Evite credenciais codificadas ou persistentes.

Suponha violação: trate cada segredo como potencialmente comprometido, a menos que fortemente protegido.		 PR. AA-04 (o Access é restrito usando segmentação e princípio de privilégios mínimos)
Os padrões de segredos seguros restringem quais identidades e serviços podem acessar ou usar segredos, impondo menos privilégios e eliminando caminhos de movimentação lateral causados por credenciais estáticas.

PR.DS-01 (os dados são gerenciados de acordo com os requisitos da empresa)
Os segredos são tratados de acordo com os requisitos de ciclo de vida e armazenamento, como armazenamento seguro centralizado, rotação de chaves e registro.

PR.PS-01 (os ativos são formalmente avaliados para garantir que atendam aos requisitos de segurança antes de serem aprovados para uso)
Usar segredos seguros significa que aplicativos e serviços devem estar em conformidade com as linhas de base de segurança.
5. Validação com estado para tokens de identidade

Garanta que os tokens de identidade estão protegidos com validação de estado e duração.		 Verifique explicitamente: valide completamente os tokens de identidade em cada ponto de verificação.

Suponha violação: verifique se tokens inválidos ou malformados são rejeitados.		 PR.AA-03 (O acesso é autorizado usando atributos baseados em atributos e contextuais)
A validação de token fornece contexto de identidade em tempo real para decisões de autorização.

DE. AE-02 (eventos detectados são analisados para entender os destinos e métodos de ataque)
A validação baseada em estado detecta atividades anômalas, como tokens forjados e uso anômalo de token.

DE. AE-07 (os processos detectam e analisam atividades anômalas para dar suporte à resposta e à recuperação)
Como os tokens são verificados continuamente, o SFI pode identificar e responder rapidamente à atividade de token não autorizada, para melhorar a detecção e reduzir os tempos de permanência do invasor.
6. Particionamento granular de chaves

Adote um particionamento mais refinado de chaves de assinatura de identidade e chaves de plataforma.		 Use privilégios mínimos: o particionamento limita os escopos de privilégio para uso de chave.

Suponha violação: limita o impacto se o segmento de chave estiver comprometido.		 PR. AA-04 (O acesso é restrito usando os princípios de segmentação e de privilégios mínimos)
O particionamento de chave de grão fino impõe uma segmentação estrita do material de chave, impedindo a movimentação lateral entre os ativos de chave.

PR. AA-05 (permissões e autorizações são gerenciadas, impostas e verificadas periodicamente)
As chaves particionadas exigem controles de autorização rígidos, verificação contínua e imposição de limites para garantir que apenas as identidades de serviços corretas possam acessar partições de chave isoladas.
7. Sistemas PKI quânticos seguros

Verifique se os sistemas PKI de identidade e certificado estão prontos para um mundo de criptografia pós-quantum.		 Verifique explicitamente: use criptografia pós-quântica para declarações de identidade.

Assumir violação: prever ameaças futuras; preparar-se para uma resistência mais forte.		 PR. AA-04 (O acesso é restrito usando os princípios de segmentação e de privilégios mínimos)
A PKI com segurança quântica requer acesso segmentado e de privilégios mínimos a sistemas de assinatura de chave, CAs, HSMS etc.

Próximas etapas

  • Last updated on