Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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
- Saiba mais sobre os pilares do SFI.
- Revise e acompanhe o progresso mais recente nos objetivos dos pilares no artigo What's New do SFI.
- Aprenda sobre os princípios do Zero Trust e as funções e categorias do CSF do NIST.
- Obtenha uma lista de categorias e acrónimos do NIST para ajudar enquanto revê a tabela deste artigo.
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
- Veja os progressos mais recentes nos objetivos dos pilares no What's New.
- Saiba como adotar as melhores práticas do Microsoft SFI.