Visão geral - Proteger identidades e segredos

A iniciativa Secure Future Initiative (SFI) é uma iniciativa multianual e transversal à Microsoft para garantir cada vez mais a forma como a Microsoft desenha, constrói, testa e opera os seus produtos e serviços. O SFI baseia-se sobre:

  • Um conjunto de princípios de segurança que orientam a forma como inovamos no design de segurança, implementam essas inovações nos produtos Microsoft como padrões e padrões seguros, e fornecem orientação de segurança interna e externa. Mais informações.
  • Um conjunto de pilares e objetivos de segurança prioritários. Mais informações.

Este artigo apresenta 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 a:

  • Fortalecer a confiança em cada identidade e credencial utilizada nos sistemas Microsoft, eliminando fraquezas na forma como contas, tokens e segredos são emitidos, armazenados e utilizados.
  • Reduzir o risco de acesso não autorizado aplicando normas para reforçar a infraestrutura de identidade e segredos, e para controlar a autenticação e autorização de utilizadores e aplicações.

Os objetivos da Microsoft e o mapeamento Zero Trust/NIST para este pilar são resumidos na tabela seguinte.

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

Proteger a assinatura da infraestrutura de identidade e as chaves da plataforma com rotação rápida e automática das chaves de infraestrutura de identidade, utilizando armazenamento e proteção por hardware.
Verifique explicitamente: Proteja os ativos de assinatura de identidade. Integre uma robusta comprovação de chaves em fluxos de trabalho.

Assumir violação: Proteger as chaves como se pudesse haver comprometimento, usando isolamento assistido por hardware.
PR. AA-04 (O acesso é restrito usando segmentação e privilégio mínimo)
A proteção de chaves baseia-se numa segmentação rigorosa de acesso e autorização de privilégio mínimo para restringir o uso de chaves a ambientes de cofre de chaves isolados e dedicados, e remover acessos desnecessários e caminhos de movimento lateral para o armazenamento de chaves.

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

Reforçar os padrões de identidade e impulsionar a adoção de padrões através do uso de SDKs padrão em todas as aplicações, para que aplicações e serviços utilizem uma biblioteca uniforme e reforçada para validar tokens.
Verifique explicitamente: Bibliotecas validadas padrão reduzem a variabilidade e o risco. Use validação consistente.

Assumir violação: Reduz a superfície de ataque das implementações personalizadas.
PR. AA-01 (As identidades são autenticadas de acordo com o risco)
A utilização de SDKs padrão impõe fluxos de autenticação fortes e consistentes.

PR. AA-02 (O acesso é autorizado usando atributos baseados em funções)
Os SDKs padrão integram-se com o Microsoft Entra RBAC e aplicam reivindicações de tokens sensíveis ao papel.

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

Garanta que as contas de utilizador estão protegidas com MFA gerida de forma segura e resistente ao phishing.
Verificar explicitamente: Técnicas fortes de autenticação verificam a identidade do utilizador em cada tentativa de acesso.

Utilize o princípio do menor privilégio: A autenticação multifator reforça a aplicação do menor privilégio ao reduzir o acesso não autorizado.
PR. AA-01 (As identidades são autenticadas de acordo com o risco)
O MFA resistente ao phishing utiliza autenticação forte e adequada ao risco.

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

Afaste-se de segredos de longa duração, como credenciais de contas de serviço, para garantir que as aplicações estão protegidas com credenciais geridas pelo sistema, como identidades geridas.
Use o privilégio mínimo: Restringa o acesso a segredos. Evite credenciais codificadas ou persistentes.

Assumir violação: Trate todas as informações confidenciais como potencialmente comprometidas, a menos que estejam fortemente protegidas.
PR. AA-04 (O acesso é restrito usando segmentação e princípio do privilégio mínimo)
Os padrões de segredos seguros restringem que identidades e serviços podem aceder ou usar segredos, aplicando o privilégio mínimo e eliminando caminhos de movimento lateral causados por credenciais estáticas.

PR.DS-01 (Os dados são geridos de acordo com os requisitos empresariais)
Os segredos são tratados de acordo com o ciclo de vida e os requisitos de armazenamento, como o armazenamento centralizado, rotação e registo de registos.

PR.PS-01 (Os ativos são formalmente avaliados para garantir que cumprem os requisitos de segurança antes de serem aprovados para uso)
Usar segredos seguros significa que as aplicações e serviços devem cumprir as normas de segurança.
5. Validação com estado para tokens de identidade

Garantir que os tokens de identidade estão protegidos com validação com estado e duração.
Verificar explicitamente: Validar totalmente os tokens de identidade em todos os pontos de aplicação.

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

DE. AE-02 (Os eventos detetados são analisados para compreender alvos e métodos de ataque)
A validação de estado deteta atividades anómalas, como tokens falsificados, e o uso invulgar de tokens.

DE. AE-07 (Processos detetam e analisam atividade anómala para apoiar a resposta e recuperação)
Como os tokens são verificados continuamente, o SFI pode identificar e responder rapidamente a atividades não autorizadas de tokens, para melhorar a deteção e reduzir os tempos de permanência dos atacantes.
6. Particionamento de chaves granular

Adotar uma partição mais detalhada das chaves de assinatura de identidade e das chaves da plataforma.
Usar privilégio mínimo: A partição limita os escopos de privilégios para o uso de chaves.

Assumir violação: Limita o impacto se o segmento-chave for comprometido.
PR. AA-04 (O acesso é restrito usando segmentação e princípios de privilégio mínimo)
A partição de chaves de granulação fina impõe uma segmentação rigorosa do material-chave, prevenindo movimentos laterais entre ativos-chave.

PR. AA-05 (Permissões e autorizações são geridas, aplicadas e periodicamente verificadas)
Chaves particionadas requerem controlos rigorosos de autorização, verificação contínua e aplicação de limites para garantir que apenas as identidades corretas dos serviços possam aceder a partições de chave isoladas.
7. Sistemas PKI resistentes a ataques quânticos

Garantir que os sistemas PKI de identidade e certificados estejam prontos para um mundo pós-criptografia quântica.
Verifique explicitamente: Use criptografia pós-quântica para afirmações de identidade.

Assumir violação: antecipar ameaças futuras; preparar para uma resistência mais forte.
PR. AA-04 (O acesso é restrito usando segmentação e princípios de privilégio mínimo)
A PKI quântica segura requer acesso segmentado e de menor privilégio a sistemas de assinatura de chaves, CAs, HSMS, etc.

Próximos passos