Recomendações para gerenciamento de identidade e acesso
Aplica-se a esta recomendação de lista de verificação de Segurança do Azure Well-Architected Framework:
| SE:05 | Implemente IAM (gerenciamento de identidade e acesso) estrito, condicional e auditável em todos os usuários de carga de trabalho, membros da equipe e componentes do sistema. Limite o acesso exclusivamente a , conforme necessário. Use padrões modernos do setor para todas as implementações de autenticação e autorização. Restrinja e audite rigorosamente o acesso que não se baseia na identidade. |
|---|
Este guia descreve as recomendações para autenticar e autorizar identidades que estão tentando acessar seus recursos de carga de trabalho.
Do ponto de vista do controle técnico, a identidade é sempre o perímetro primário. Esse escopo não inclui apenas as bordas da carga de trabalho. Ele também inclui componentes individuais que estão dentro de sua carga de trabalho. As identidades típicas incluem:
Humanos. Usuários de aplicativos, administradores, operadores, auditores e maus atores.
Sistemas. Identidades de carga de trabalho, identidades gerenciadas, chaves de API, entidades de serviço e recursos do Azure.
Anônimo. Entidades que não forneceram nenhuma evidência sobre quem são.
Definições
| Termos | Definição |
|---|---|
| Autenticação (AuthN) | Um processo que verifica se uma identidade é quem ou o que ela diz que é. |
| Autorização (AuthZ) | Um processo que verifica se uma identidade tem permissão para executar uma ação solicitada. |
| Acesso condicional | Um conjunto de regras que permite ações com base em critérios especificados. |
| IdP | Um provedor de identidade, como Microsoft Entra ID. |
| Persona | Uma função de trabalho ou um título que tem um conjunto de responsabilidades e ações. |
| Chaves pré-compartilhadas | Um tipo de segredo compartilhado entre um provedor e um consumidor e usado por meio de um mecanismo seguro e acordado. |
| Identidade do recurso | Uma identidade definida para recursos de nuvem gerenciados pela plataforma. |
| Função | Um conjunto de permissões que definem o que um usuário ou grupo pode fazer. |
| Escopo | Diferentes níveis de hierarquia organizacional em que uma função tem permissão para operar. Também um grupo de recursos em um sistema. |
| Entidade de segurança | Uma identidade que fornece permissões. Pode ser um usuário, um grupo ou uma entidade de serviço. Todos os membros do grupo obtêm o mesmo nível de acesso. |
| Identidade do usuário | Uma identidade para uma pessoa, como um funcionário ou um usuário externo. |
| Identidade de carga de trabalho | Uma identidade do sistema para um aplicativo, serviço, script, contêiner ou outro componente de uma carga de trabalho que é usada para se autenticar em outros serviços e recursos. |
Observação
Uma identidade pode ser agrupada com outras identidades semelhantes em um pai chamado de entidade de segurança. Um grupo de segurança é um exemplo de uma entidade de segurança. Essa relação hierárquica simplifica a manutenção e melhora a consistência. Como os atributos de identidade não são tratados no nível individual, as chances de erros também são reduzidas. Neste artigo, o termo identidade é inclusivo de entidades de segurança.
A função de um provedor de identidade
Um IdP (provedor de identidade) é um serviço hospedado na nuvem que armazena e gerencia usuários como identidades digitais.
Aproveite os recursos fornecidos por um IdP confiável para o gerenciamento de identidade e acesso. Não implemente sistemas personalizados para substituir um IdP. Os sistemas IdP são aprimorados com frequência com base nos vetores de ataque mais recentes capturando bilhões de sinais em vários locatários todos os dias. Microsoft Entra ID é o IdP para a plataforma de nuvem do Azure.
Autenticação
A autenticação é um processo que verifica identidades. A identidade solicitante é necessária para fornecer alguma forma de identificação verificável. Por exemplo:
Um nome de usuário e senha.
Um segredo pré-compartilhado, como uma chave de API que concede acesso.
Um token SAS (Assinatura de Acesso Compartilhado).
Um certificado usado na autenticação mútua do TLS.
Tanto quanto possível, o processo de verificação deve ser tratado pelo IdP.
Autorização
A autorização é um processo que permite ou nega ações solicitadas pela identidade verificada. A ação pode estar operacional ou relacionada ao gerenciamento de recursos.
A autorização exige que você atribua permissões às identidades, o que você precisa fazer usando a funcionalidade fornecida pelo IdP.
Principais estratégias de design
Para obter uma visão holística das necessidades de identidade de uma carga de trabalho, você precisa catalogar os fluxos, os ativos de carga de trabalho e as personas e as ações que os ativos e personas executarão. Sua estratégia deve abranger todos os casos de uso que lidam com os fluxos que atingem a carga de trabalho ou seus componentes (acesso externo) e fluxos que alcançam da carga de trabalho para outras fontes (acesso interno).
Cada caso de uso provavelmente terá seu próprio conjunto de controles que você precisa projetar com uma mentalidade de presumir violação. Com base nos requisitos de identidade do caso de uso ou das personas, identifique as opções condicionais. Evite usar uma solução para todos os casos de uso. Por outro lado, os controles não devem ser tão granulares que você introduz sobrecarga de gerenciamento desnecessária.
Você precisa registrar a trilha de acesso à identidade. Isso ajuda a validar os controles e você pode usar os logs para auditorias de conformidade.
Determinar todas as identidades para autenticação
Acesso externo. Seu design de identidade deve autenticar todos os usuários que acessam a carga de trabalho para várias finalidades. Por exemplo, um usuário final que acessa o aplicativo chamando APIs.
Em um nível granular, os componentes da carga de trabalho também podem precisar de acesso de fora. Por exemplo, um operador que precisa de acesso por meio do portal ou acesso à computação para executar comandos.
Ambos são exemplos de identidades de usuário que têm personas diferentes.
Acesso interno. Seu aplicativo precisará acessar outros recursos. Por exemplo, leitura ou gravação na plataforma de dados, recuperação de segredos do repositório de segredos e registro em log de telemetria para serviços de monitoramento. Pode até mesmo precisar acessar serviços de terceiros. Essas necessidades de acesso exigem identidade de carga de trabalho, o que permite que o aplicativo se autentique em relação aos outros recursos.
O conceito se aplica no nível do componente. No exemplo a seguir, o contêiner pode precisar de acesso aos pipelines de implantação para obter sua configuração. Essas necessidades de acesso exigem identidade de recurso.
Todas essas identidades devem ser autenticadas pelo IdP.
Aqui está um exemplo de como a identidade pode ser implementada em uma arquitetura:
Determinar ações para autorização
Em seguida, você precisa saber o que cada identidade autenticada está tentando fazer para que essas ações possam ser autorizadas. As ações podem ser divididas pelo tipo de acesso necessário:
Acesso ao plano de dados. As ações que ocorrem no plano de dados causam a transferência de dados para acesso interno ou externo. Por exemplo, um aplicativo lendo dados de um banco de dados e gravando dados em um banco de dados, buscando segredos ou gravando logs em um coletor de monitoramento. No nível do componente, a computação que está extraindo ou enviando imagens de ou para um registro são consideradas operações de plano de dados.
Acesso ao painel de controle. As ações que ocorrem no painel de controle fazem com que um recurso do Azure seja criado, modificado ou excluído. Por exemplo, alterações nas propriedades do recurso.
Os aplicativos normalmente se destinam a operações de plano de dados, enquanto as operações geralmente acessam planos de controle e de dados. Para identificar as necessidades de autorização, observe as ações operacionais que podem ser executadas no recurso. Para obter informações sobre as ações permitidas para cada recurso, consulte Operações do provedor de recursos do Azure.
Fornecer autorização baseada em função
Com base na responsabilidade de cada identidade, autorize ações que devem ser permitidas. Uma identidade não deve ter permissão para fazer mais do que precisa. Antes de definir regras de autorização, você precisa ter uma compreensão clara de quem ou o que está fazendo solicitações, o que essa função tem permissão para fazer e até que ponto ela pode fazê-lo. Esses fatores levam a opções que combinam identidade, função e escopo.
Considere uma identidade de carga de trabalho como um exemplo. O aplicativo deve ter acesso ao plano de dados para o banco de dados, portanto, ações de leitura e gravação no recurso de dados devem ser permitidas. No entanto, o aplicativo precisa de acesso do painel de controle ao repositório de segredos? Se a identidade da carga de trabalho for comprometida por um ator inválido, qual seria o impacto para o sistema em termos de confidencialidade, integridade e disponibilidade?
Atribuição de função
Uma função é um conjunto de permissões atribuídas a uma identidade. Atribua funções que permitem apenas que a identidade conclua a tarefa e não mais. Quando as permissões do usuário são restritas aos requisitos de trabalho, é mais fácil identificar comportamentos suspeitos ou não autorizados no sistema.
Faça perguntas como estas:
- O acesso somente leitura é suficiente?
- A identidade precisa de permissões para excluir recursos?
Limitar o nível de acesso que usuários, aplicativos ou serviços têm aos recursos do Azure reduz a superfície de ataque potencial. Se você conceder apenas as permissões mínimas necessárias para executar tarefas específicas, o risco de um ataque bem-sucedido ou acesso não autorizado será significativamente reduzido. Por exemplo, as equipes de segurança só precisam de acesso somente leitura a atributos de segurança para todos os ambientes técnicos. Esse nível é suficiente para avaliar fatores de risco, identificar possíveis mitigações e relatar os riscos.
Há cenários em que os usuários precisam de mais acesso devido à estrutura organizacional e à organização da equipe. Pode haver uma sobreposição entre várias funções ou usuários únicos podem executar várias funções padrão. Nesse caso, use várias atribuições de função baseadas na função de negócios em vez de criar uma função personalizada para cada um desses usuários. Isso facilita o gerenciamento das funções.
Evite permissões que referenciam especificamente usuários ou recursos individuais. Permissões granulares e personalizadas criam complexidade e confusão porque não passam a intenção para novos recursos semelhantes. Isso pode criar uma configuração herdada complexa que é difícil de manter e afetar negativamente a segurança e a confiabilidade.
Compensação: uma abordagem de controle de acesso granular permite uma melhor auditoria e monitoramento das atividades do usuário.
Uma função também tem um escopo associado. A função pode operar no grupo de gerenciamento permitido, assinatura, grupo de recursos ou escopo de recursos ou em outro escopo personalizado. Mesmo que a identidade tenha um conjunto limitado de permissões, ampliar o escopo para incluir recursos que estão fora da função de trabalho da identidade é arriscado. Por exemplo, o acesso de leitura a todos os dados e código-fonte pode ser perigoso e deve ser controlado.
Você atribui funções a identidades usando o RBAC (controle de acesso baseado em função). Sempre use o RBAC fornecido por IdP para aproveitar os recursos que permitem aplicar o controle de acesso de forma consistente e revogá-lo rigorosamente.
Use funções internas. Eles foram projetados para cobrir a maioria dos casos de uso. As funções personalizadas são poderosas e, às vezes, úteis, mas você deve reservar para cenários em que as funções internas não funcionarão. A personalização leva à complexidade, o que aumenta a confusão e torna a automação mais complexa, desafiadora e frágil. Esses fatores afetam negativamente a segurança.
Conceda funções que começam com privilégios mínimos e adicionem mais com base em suas necessidades operacionais ou de acesso a dados. Suas equipes técnicas devem ter diretrizes claras para implementar permissões.
Se você quiser um controle refinado no RBAC, adicione condições à atribuição de função com base no contexto, como ações e atributos.
Fazer opções de acesso condicional
Não dê a todas as identidades o mesmo nível de acesso. Baseie suas decisões em dois fatores main:
Tempo. Por quanto tempo a identidade pode acessar seu ambiente.
Privilégio. O nível de permissões.
Esses fatores não são mutuamente exclusivos. Uma identidade comprometida que tem mais privilégios e duração ilimitada de acesso pode obter mais controle sobre o sistema e os dados ou usar esse acesso para continuar a alterar o ambiente. Restrinja esses fatores de acesso como uma medida preventiva e para controlar o raio da explosão.
As abordagens JIT (Just-In-Time) fornecem os privilégios necessários somente quando necessário.
O JEA (Just Enough Access) fornece apenas os privilégios necessários.
Embora tempo e privilégio sejam os principais fatores, há outras condições que se aplicam. Por exemplo, você também pode usar o dispositivo, a rede e o local do qual o acesso se originou para definir políticas.
Use controles fortes que filtram, detectam e bloqueiam o acesso não autorizado, incluindo parâmetros como identidade e localização do usuário, integridade do dispositivo, contexto de carga de trabalho, classificação de dados e anomalias.
Por exemplo, sua carga de trabalho pode precisar ser acessada por identidades de terceiros, como fornecedores, parceiros e clientes. Eles precisam do nível apropriado de acesso em vez das permissões padrão que você fornece aos funcionários em tempo integral. A diferenciação clara de contas externas facilita a prevenção e a detecção de ataques provenientes desses vetores.
Sua escolha de IdP deve ser capaz de fornecer essa diferenciação, fornecer recursos internos que concedem permissões com base no privilégio mínimo e fornecer inteligência interna contra ameaças. Isso inclui o monitoramento de solicitações de acesso e entradas. O IdP do Azure é Microsoft Entra ID. Para obter mais informações, consulte a seção Facilitação do Azure deste artigo.
Contas de impacto crítico
As identidades administrativas apresentam alguns dos riscos de segurança de maior impacto porque as tarefas que executam exigem acesso privilegiado a um amplo conjunto desses sistemas e aplicativos. O comprometimento ou uso indevido pode ter um efeito prejudicial em sua empresa e em seus sistemas de informações. A segurança da administração é uma das áreas de segurança mais críticas.
Proteger o acesso privilegiado em relação a determinados adversários requer uma abordagem completa e elaborada para isolar esses sistemas contra riscos. Veja algumas estratégias:
Minimize o número de contas de impacto crítico.
Use funções separadas em vez de elevar privilégios para identidades existentes.
Evite o acesso permanente ou permanente usando os recursos JIT do seu IdP. Para situações de emergência, siga um processo de acesso de emergência.
Use protocolos de acesso modernos , como autenticação sem senha ou autenticação multifator. Externalize esses mecanismos para seu IdP.
Impor atributos de segurança de chave usando políticas de acesso condicional.
Desativar contas administrativas que não estão sendo usadas.
Use uma única identidade entre ambientes e associe uma única identidade ao usuário ou à entidade de segurança. A consistência de identidades em ambientes locais e na nuvem reduz os erros humanos e os riscos de segurança resultantes. As equipes em ambos os ambientes que gerenciam recursos precisam de uma fonte consistente e autoritativa para atender às garantias de segurança. Trabalhe com sua equipe de identidade central para garantir que as identidades em ambientes híbridos sejam sincronizadas.
Risco: há um risco associado à sincronização de identidades de alto privilégio. Um invasor pode obter controle total dos ativos locais e isso pode levar a um comprometimento bem-sucedido de uma conta de nuvem. Avalie sua estratégia de sincronização filtrando contas que podem ser adicionadas à superfície de ataque.
Estabelecer processos para gerenciar o ciclo de vida de identidade
O acesso a identidades não deve durar mais do que os recursos que as identidades acessam. Verifique se você tem um processo para desabilitar ou excluir identidades quando houver alterações na estrutura da equipe ou nos componentes de software.
Essas diretrizes se aplicam ao controle do código-fonte, dados, planos de controle, usuários de carga de trabalho, infraestrutura, ferramentas, monitoramento de dados, logs, métricas e outras entidades.
Estabeleça um processo de governança de identidade para gerenciar o ciclo de vida de identidades digitais, usuários com privilégios elevados, usuários externos/convidados e usuários de carga de trabalho. Implemente revisões de acesso para garantir que, quando as identidades saírem da organização ou da equipe, suas permissões de carga de trabalho sejam removidas.
Proteger segredos não baseados em entidade
Os segredos do aplicativo, como chaves pré-compartilhadas, devem ser considerados pontos vulneráveis no sistema. Na comunicação bidirecional, se o provedor ou o consumidor estiver comprometido, riscos significativos de segurança poderão ser introduzidos. Essas chaves também podem ser pesadas porque introduzem processos operacionais.
Quando puder, evite usar segredos e considere usar a autenticação baseada em identidade para o acesso do usuário ao próprio aplicativo, não apenas aos seus recursos.
A lista a seguir fornece um resumo das diretrizes. Para obter mais informações, consulte Recomendações para segredos do aplicativo.
Trate esses segredos como entidades que podem ser extraídas dinamicamente de um repositório secreto. Eles não devem ser embutidos em código no código do aplicativo, scripts iac, pipelines de implantação ou em qualquer outro artefato.
Verifique se você tem a capacidade de revogar segredos.
Aplique práticas operacionais que lidam com tarefas como rotação e expiração de chaves.
Para obter informações sobre políticas de rotação, consulte Automatizar a rotação de um segredo para recursos que têm dois conjuntos de credenciais de autenticação e Tutorial: Atualizando a frequência de rotação automática do certificado em Key Vault.
Manter os ambientes de desenvolvimento seguros
Todos os códigos e scripts, ferramentas de pipeline e sistemas de controle do código-fonte devem ser considerados ativos de carga de trabalho. O acesso a gravações deve ser fechado com automação e revisão por pares. O acesso de leitura ao código-fonte deve ser limitado a funções de acordo com a necessidade de saber. Os repositórios de código devem ter controle de versão e as revisões de código de segurança por pares devem ser uma prática regular integrada ao ciclo de vida de desenvolvimento. Você precisa ter um processo em vigor que examine os recursos regularmente e identifique as vulnerabilidades mais recentes.
Use identidades de carga de trabalho para conceder acesso a recursos de ambientes de implantação, como o GitHub.
Manter uma trilha de auditoria
Um aspecto do gerenciamento de identidades é garantir que o sistema seja auditável. As auditorias validam se as estratégias de pressupor violação são eficazes. Manter uma trilha de auditoria ajuda você a:
Verifique se a identidade está autenticada com autenticação forte. Qualquer ação deve ser rastreável para evitar ataques de repúdio.
Detecte protocolos de autenticação fracos ou ausentes e obtenha visibilidade e insights sobre entradas de usuário e aplicativo.
Avalie o acesso de identidades para a carga de trabalho com base nos requisitos de segurança e conformidade e considere o risco da conta de usuário, o status do dispositivo e outros critérios e políticas que você definir.
Acompanhe o progresso ou o desvio dos requisitos de conformidade.
A maioria dos recursos tem acesso ao plano de dados. Você precisa saber as identidades que acessam os recursos e as ações que eles executam. Você pode usar essas informações para diagnóstico de segurança.
Para obter mais informações, consulte Recomendações sobre monitoramento de segurança e análise de ameaças.
Facilitação do Azure
Recomendamos que você sempre use protocolos de autenticação modernos que levem em conta todos os pontos de dados disponíveis e usem o acesso condicional. Microsoft Entra ID fornece gerenciamento de identidade e acesso no Azure. Ele abrange o plano de gerenciamento do Azure e é integrado aos planos de dados da maioria dos serviços do Azure. Microsoft Entra ID é o locatário associado à assinatura de carga de trabalho. Ele rastreia e gerencia identidades e suas permissões permitidas e simplifica o gerenciamento geral para minimizar o risco de supervisão ou erro humano.
Esses recursos se integram nativamente ao mesmo modelo de identidade e permissão Microsoft Entra para segmentos de usuário:
Microsoft Entra ID. Funcionários e recursos corporativos.
ID externa do Microsoft Entra. Parceiros.
Azure AD B2C. Clientes.
Microsoft Entra lista de compatibilidade de federação. Soluções de federação de terceiros.
Você pode usar Microsoft Entra ID para autenticação e autorização de aplicativos personalizados por meio da MSAL (Biblioteca de Autenticação da Microsoft) ou recursos de plataforma, como autenticação para aplicativos Web. Ele abrange o plano de gerenciamento do Azure, os planos de dados da maioria dos serviços do Azure e as funcionalidades de integração para seus aplicativos.
Você pode se manter atualizado visitando Novidades em Microsoft Entra ID.
O Azure dá suporte a protocolos abertos como OAuth2 e OpenID Connect. Recomendamos que você use esses mecanismos padrão de autenticação e autorização em vez de projetar seus próprios fluxos.
RBAC do Azure
O RBAC do Azure representa entidades de segurança no Microsoft Entra ID. Todas as atribuições de função são feitas por meio do RBAC do Azure. Aproveite as funções internas que fornecem a maioria das permissões necessárias. Para obter mais informações, confira Funções internas do Microsoft Entra.
Aqui estão alguns casos de uso:
Ao atribuir usuários a funções, você pode controlar o acesso aos recursos do Azure. Para obter mais informações, consulte Visão geral do controle de acesso baseado em função no Microsoft Entra ID.
Você pode usar Privileged Identity Management para fornecer ativação de função baseada em tempo e aprovação para funções associadas a identidades de alto impacto. Para obter mais informações, consulte O que é Privileged Identity Management?.
Para obter mais informações sobre o RBAC, consulte Práticas recomendadas para o RBAC do Azure.
Para obter informações sobre controles baseados em atributo, consulte O que é o Azure ABAC?.
Identidade de carga de trabalho
Microsoft Entra ID pode lidar com a identidade do aplicativo. A entidade de serviço associada ao aplicativo pode ditar seu escopo de acesso.
Para obter mais informações, consulte O que são identidades de carga de trabalho?.
A entidade de serviço também é abstraida quando você usa uma identidade gerenciada. A vantagem é que o Azure gerencia todas as credenciais para o aplicativo.
Nem todos os serviços dão suporte a identidades gerenciadas. Se você não puder usar identidades gerenciadas, poderá usar entidades de serviço. No entanto, o uso de entidades de serviço aumenta a sobrecarga de gerenciamento. Para obter mais informações, consulte O que são identidades gerenciadas para recursos do Azure?.
Identidade do recurso
O conceito de identidades gerenciadas pode ser estendido para recursos do Azure. Os recursos do Azure podem usar identidades gerenciadas para se autenticarem em outros serviços que dão suporte à autenticação Microsoft Entra. Para obter mais informações, consulte Serviços do Azure que podem usar identidades gerenciadas para acessar outros serviços.
Políticas de acesso condicional
O acesso condicional descreve sua política para uma decisão de acesso. Para usar o acesso condicional, você precisa entender as restrições necessárias para o caso de uso. Configure Microsoft Entra Acesso Condicional configurando uma política de acesso para que seja baseada em suas necessidades operacionais.
Para obter mais informações, consulte Acesso condicional: usuários, grupos e identidades de carga de trabalho.
Gerenciamento de acesso a grupos
Em vez de conceder permissões a usuários específicos, atribua acesso a grupos em Microsoft Entra ID. Se um grupo não existir, trabalhe com sua equipe de identidade para criar um. Em seguida, você pode adicionar e remover membros do grupo fora do Azure e verificar se as permissões estão atualizadas. Você também pode usar o grupo para outras finalidades, como listas de endereçamento.
Para obter mais informações, consulte Proteger o controle de acesso usando grupos no Microsoft Entra ID.
Detecção de ameaças
Microsoft Entra ID Protection pode ajudá-lo a detectar, investigar e corrigir riscos baseados em identidade. Para obter mais informações, consulte O que é o Identity Protection?.
A detecção de ameaças pode assumir a forma de reagir a um alerta de atividade suspeita ou pesquisar proativamente eventos anormais nos logs de atividades. A UEBA (Análise de Comportamento de Usuários e Entidades) no Microsoft Sentinel facilita a detecção de atividades suspeitas. Para obter mais informações, consulte Identificar ameaças avançadas com UEBA.
Sistemas híbridos
No Azure, não sincronize contas com Microsoft Entra ID que tenham privilégios elevados em seu Active Directory existente. Essa sincronização é bloqueada no padrão Microsoft Entra configuração do Connect Sync, portanto, você só precisa confirmar que não personalizou essa configuração.
Para obter informações sobre filtragem em Microsoft Entra ID, consulte Microsoft Entra Connect Sync: Configurar a filtragem.
Registro em log de identidade
Habilite as configurações de diagnóstico nos recursos do Azure para emitir informações que você pode usar como uma trilha de auditoria. As informações de diagnóstico mostram quais identidades tentam acessar quais recursos e o resultado dessas tentativas. Os logs coletados são enviados para o Azure Monitor.
Exemplo
O exemplo a seguir mostra uma implementação de identidade. Diferentes tipos de identidades são usados juntos para fornecer os níveis de acesso necessários.
Componentes de identidade
Identidades gerenciadas pelo sistema. Microsoft Entra ID fornece acesso a planos de dados de serviço que não enfrentam usuários, como armazenamentos de dados e Key Vault do Azure. Essas identidades também controlam o acesso, via RBAC, ao plano de gerenciamento do Azure para componentes de carga de trabalho, agentes de implantação e membros da equipe.
Identidades de carga de trabalho. Os serviços de aplicativo no cluster do AKS (Serviço de Kubernetes do Azure) usam identidades de carga de trabalho para se autenticarem em outros componentes na solução.
Identidades gerenciadas. Os componentes do sistema na função de cliente usam identidades gerenciadas pelo sistema, incluindo agentes de build.
Identidades humanas. A autenticação de usuário e operador é delegada para Microsoft Entra ID ou ID de Microsoft Entra (nativa, B2B ou B2C).
A segurança de segredos pré-compartilhados é essencial para qualquer aplicativo. O Azure Key Vault fornece um mecanismo de armazenamento seguro para esses segredos, incluindo o Redis e segredos de terceiros.
Um mecanismo de rotação é usado para ajudar a garantir que os segredos não sejam comprometidos. Os tokens para a implementação plataforma de identidade da Microsoft do OAuth 2 e do OpenID Connect são usados para autenticar usuários.
Azure Policy é usado para garantir que componentes de identidade como Key Vault usem o RBAC em vez de políticas de acesso. JIT e JEA fornecem permissões permanentes tradicionais para operadores humanos.
Os logs de acesso são habilitados em todos os componentes por meio de Diagnóstico do Azure ou por meio de código para componentes de código.
Links relacionados
- Tutorial: Automatizar a rotação de um segredo para recursos que têm dois conjuntos de credenciais de autenticação
- Tutorial: Atualizando a frequência de rotação automática do certificado no Key Vault
- O que há de novo na ID do Microsoft Entra?
- Funções internas do Microsoft Entra
- Visão geral do controle de acesso baseado em função no Microsoft Entra ID
- O que são identidades de carga de trabalho?
- O que são identidades gerenciadas para recursos do Azure?
- Acesso condicional: usuários, grupos e identidades de carga de trabalho
- Sincronização do Microsoft Entra Connect: configurar a filtragem
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de