Recomendações para a gestão de identidades e acessos

  • Artigo

Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Security:

SE:05 Implemente uma gestão de identidades e acessos estrita, condicional e auditável (IAM) em todos os utilizadores da carga de trabalho, membros da equipa e componentes do sistema. Limite o acesso exclusivamente ao , conforme necessário. Utilize normas modernas do setor para todas as implementações de autenticação e autorização. Restringir e auditar rigorosamente o acesso que não se baseia na identidade.

Este guia descreve as recomendações para autenticar e autorizar identidades que estão a tentar aceder aos recursos da carga de trabalho.

Do ponto de vista do controlo técnico, a identidade é sempre o perímetro primário. Este âmbito não inclui apenas os limites da carga de trabalho. Também inclui componentes individuais que estão dentro da carga de trabalho. As identidades típicas incluem:

  • Os humanos. Utilizadores de aplicações, administradores, operadores, auditores e maus atores.

  • Sistemas. Identidades de carga de trabalho, identidades geridas, chaves de API, principais de serviço e recursos do Azure.

  • Anónimo. Entidades que não forneceram provas sobre quem são.

Definições 

Termos Definição
Autenticação (AuthN) Um processo que verifica se uma identidade é quem ou o que diz ser.
Autorização (AuthZ) Um processo que verifica se uma identidade tem permissão para efetuar uma ação pedida.
Acesso condicional Um conjunto de regras que permite ações com base em critérios especificados.
URL de Um fornecedor de identidade, como Microsoft Entra ID.
Persona Uma função de trabalho ou um título que tenha um conjunto de responsabilidades e ações.
Chaves pré-partilhadas Um tipo de segredo que é partilhado entre um fornecedor e um consumidor e utilizado através de um mecanismo seguro e acordado.
Identidade do recurso Uma identidade definida para recursos na cloud que é gerida pela plataforma.
Função Um conjunto de permissões que definem o que um utilizador ou grupo pode fazer.
Âmbito Diferentes níveis de hierarquia organizacional em que uma função é autorizada a operar. Também um grupo de funcionalidades num sistema.
Principal de segurança Uma identidade que fornece permissões. Pode ser um utilizador, um grupo ou um principal de serviço. Todos os membros do grupo obtêm o mesmo nível de acesso.
Identidade do utilizador Uma identidade para uma pessoa, como um funcionário ou um utilizador externo.
Identidade da carga de trabalho Uma identidade de sistema para uma aplicação, serviço, script, contentor ou outro componente de uma carga de trabalho que é utilizada para se autenticar noutros serviços e recursos.

Nota

Uma identidade pode ser agrupada com outras identidades semelhantes num principal denominado principal de segurança. Um grupo de segurança é um exemplo de um principal de segurança. Esta relação hierárquica simplifica a manutenção e melhora a consistência. Uma vez que os atributos de identidade não são processados ao nível individual, as probabilidades de erros também são reduzidas. Neste artigo, o termo identidade inclui principais de segurança.

A função de um fornecedor de identidade

Um fornecedor de identidade (IdP) é um serviço alojado na cloud que armazena e gere utilizadores como identidades digitais.

Tire partido das capacidades fornecidas por um IdP fidedigno para a sua gestão de identidades e acessos. Não implemente sistemas personalizados para substituir um IdP. Os sistemas IdP são melhorados frequentemente com base nos vetores de ataque mais recentes ao capturar milhares de milhões de sinais em vários inquilinos todos os dias. Microsoft Entra ID é o IdP da plataforma cloud do Azure.

Autenticação

A autenticação é um processo que verifica identidades. A identidade de pedido é necessária para fornecer alguma forma de identificação verificável. Por exemplo:

  • Um nome de utilizador e palavra-passe.

  • Um segredo pré-partilhado, como uma chave de API que concede acesso.

  • Um token de assinatura de acesso partilhado (SAS).

  • Um certificado que é utilizado na autenticação mútua TLS.

Tanto quanto possível, o processo de verificação deve ser processado pelo seu IdP.

Autorização

A autorização é um processo que permite ou nega ações pedidas pela identidade verificada. A ação pode estar operacional ou relacionada com a gestão de recursos.

A autorização requer que atribua permissões às identidades, o que tem de fazer com a funcionalidade fornecida pelo seu IdP.

Principais estratégias de conceção

Para obter uma vista holística das necessidades de identidade para uma carga de trabalho, tem de catalogar os fluxos, os recursos de carga de trabalho e as pessoas fictícias, bem como as ações que os recursos e personas irão realizar. A sua estratégia tem de abranger todos os casos de utilização que processam os fluxos que atingem a carga de trabalho ou os respetivos componentes (acesso externo) e fluxos que chegam da carga de trabalho a outras origens (acesso interno).

Cada caso de utilização terá provavelmente o seu próprio conjunto de controlos que precisa de conceber com uma mentalidade de violação de pressupor. Com base nos requisitos de identidade do caso de utilização ou das personas, identifique as opções condicionais. Evite utilizar uma solução para todos os casos de utilização. Por outro lado, os controlos não devem ser tão granulares que introduza overheads de gestão desnecessários.

Tem de registar o registo de acesso de identidade. Fazê-lo ajuda a validar os controlos e pode utilizar os registos para auditorias de conformidade.

Determinar todas as identidades para autenticação

  • Acesso externo. A estrutura de identidade tem de autenticar todos os utilizadores que acedem à carga de trabalho para várias finalidades. Por exemplo, um utilizador final que acede à aplicação ao chamar APIs.

    A um nível granular, os componentes da carga de trabalho também podem precisar de acesso externo. Por exemplo, um operador que precisa de acesso através do portal ou acesso à computação para executar comandos.

    Ambos são exemplos de identidades de utilizador que têm personas diferentes.

  • Acesso de dentro para fora. A sua aplicação terá de aceder a outros recursos. Por exemplo, ler ou escrever na plataforma de dados, obter segredos do arquivo de segredos e registar telemetria nos serviços de monitorização. Pode até ter de aceder a serviços de terceiros. Estas necessidades de acesso requerem a identidade da carga de trabalho, o que permite que a aplicação se autentique nos outros recursos.

    O conceito aplica-se ao nível do componente. No exemplo seguinte, o contentor poderá precisar de acesso aos pipelines de implementação para obter a configuração. Estas necessidades de acesso requerem identidade de recursos.

Todas estas identidades devem ser autenticadas pelo seu IdP.

Eis um exemplo de como a identidade pode ser implementada numa arquitetura:

Diagrama que mostra como a identidade pode ser implementada numa arquitetura.

Determinar ações de autorização

Em seguida, tem de saber o que cada identidade autenticada está a tentar fazer para que essas ações possam ser autorizadas. As ações podem ser divididas pelo tipo de acesso de que necessitam:

  • 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, uma aplicação a ler dados de uma base de dados e a escrever dados numa base de dados, a obter segredos ou a escrever registos num sink de monitorização. Ao nível do componente, a computação que está a solicitar ou a enviar imagens de/para um registo são consideradas operações do plano de dados.

  • Controlar o acesso ao plano. As ações que ocorrem no plano de controlo fazem com que um recurso do Azure seja criado, modificado ou eliminado. Por exemplo, alterações às propriedades dos recursos.

Normalmente, as aplicações visam operações de planos de dados, enquanto as operações acedem frequentemente a planos de controlo e dados. Para identificar as necessidades de autorização, tenha em atenção as ações operacionais que podem ser executadas no recurso. Para obter informações sobre as ações permitidas para cada recurso, veja Operações do fornecedor de recursos do Azure.

Fornecer autorização baseada em funções

Com base na responsabilidade de cada identidade, autorize ações que devem ser permitidas. Uma identidade não pode fazer mais do que o necessário. Antes de definir regras de autorização, tem de ter uma compreensão clara de quem ou o que está a fazer pedidos, o que essa função pode fazer e até que ponto pode fazê-lo. Estes fatores levam a escolhas que combinam identidade, função e âmbito.

Considere uma identidade de carga de trabalho como um exemplo. A aplicação tem de ter acesso de plano de dados à base de dados, pelo que as ações de leitura e escrita no recurso de dados têm de ser permitidas. No entanto, a aplicação precisa de acesso de plano de controlo ao arquivo de segredos? Se a identidade da carga de trabalho for comprometida por um mau ator, 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 só permitem que a identidade conclua a tarefa e não mais. Quando as permissões do utilizador estão restritas aos respetivos requisitos de trabalho, é mais fácil identificar comportamentos suspeitos ou não autorizados no sistema.

Faça perguntas como estas:

  • O acesso só de leitura é suficiente?
  • A identidade precisa de permissões para eliminar recursos?

Limitar o nível de acesso que os utilizadores, aplicações ou serviços têm aos recursos do Azure reduz a potencial superfície de ataque. Se conceder apenas as permissões mínimas necessárias para realizar tarefas específicas, o risco de um ataque bem-sucedido ou acesso não autorizado é significativamente reduzido. Por exemplo, as equipas de segurança só precisam de acesso só de leitura a atributos de segurança para todos os ambientes técnicos. Este nível é suficiente para avaliar fatores de risco, identificar potenciais mitigações e comunicar os riscos.

Existem cenários em que os utilizadores precisam de mais acesso devido à estrutura organizacional e à organização da equipa. Pode existir uma sobreposição entre várias funções ou os utilizadores individuais podem desempenhar várias funções padrão. Neste caso, utilize várias atribuições de funções baseadas na função empresarial em vez de criar uma função personalizada para cada um destes utilizadores. Fazê-lo facilita a gestão das funções.

Evite permissões que referenciem especificamente recursos ou utilizadores individuais. As permissões granulares e personalizadas criam complexidade e confusão porque não transmitem a intenção a novos recursos semelhantes. Isto pode criar uma configuração legada complexa que é difícil de manter e afetar negativamente a segurança e a fiabilidade.

Compromisso: uma abordagem granular de controlo de acesso permite uma melhor auditoria e monitorização das atividades dos utilizadores.

Uma função também tem um âmbito associado. A função pode funcionar no grupo de gestão permitido, subscrição, grupo de recursos ou âmbito de recursos, ou noutro âmbito personalizado. Mesmo que a identidade tenha um conjunto limitado de permissões, o alargamento do âmbito para incluir recursos que estão fora da função de trabalho da identidade é arriscado. Por exemplo, o acesso de leitura a todos os códigos e dados de origem pode ser perigoso e tem de ser controlado.

Pode atribuir funções a identidades através do controlo de acesso baseado em funções (RBAC). Utilize sempre o RBAC fornecido por IdP para tirar partido das funcionalidades que lhe permitem aplicar o controlo de acesso de forma consistente e revogá-lo rigorosamente.

Utilizar funções incorporadas. Foram concebidos para abranger a maioria dos casos de utilização. As funções personalizadas são poderosas e, por vezes, úteis, mas deve reservá-las para cenários em que as funções incorporadas não irão funcionar. A personalização leva à complexidade que aumenta a confusão e torna a automatização mais complexa, desafiante e frágil. Todos estes fatores afetam negativamente a segurança.

Conceda funções que comecem com menos privilégios e adicionem mais com base nas suas necessidades operacionais ou de acesso a dados. As suas equipas técnicas têm de ter orientações claras para implementar permissões.

Se quiser um controlo detalhado no RBAC, adicione condições à atribuição de função com base no contexto, como ações e atributos.

Fazer escolhas de acesso condicional

Não dê a todas as identidades o mesmo nível de acesso. Baseie as suas decisões em dois fatores principais:

  • Hora. Durante quanto tempo a identidade pode aceder ao seu ambiente.

  • Privilégio. O nível de permissões.

Estes factores não são mutuamente exclusivos. Uma identidade comprometida que tenha mais privilégios e duração ilimitada de acesso pode obter mais controlo sobre o sistema e os dados ou utilizar esse acesso para continuar a alterar o ambiente. Restrinja esses fatores de acesso como medida preventiva e controle o raio da explosão.

  • As abordagens just-in-Time (JIT) fornecem os privilégios necessários apenas quando são necessárias.

  • O Just Enough Access (JEA) fornece apenas os privilégios necessários.

Embora o tempo e o privilégio sejam os principais fatores, existem outras condições que se aplicam. Por exemplo, também pode utilizar o dispositivo, a rede e a localização a partir da qual o acesso teve origem para definir políticas.

Utilize controlos fortes que filtram, detetam e bloqueiam o acesso não autorizado, incluindo parâmetros como a identidade e localização do utilizador, o estado de funcionamento do dispositivo, o contexto da carga de trabalho, a classificação de dados e anomalias.

Por exemplo, a carga de trabalho poderá ter de ser acedida por identidades de terceiros, como fornecedores, parceiros e clientes. Precisam do nível de acesso adequado em vez das permissões predefinidas que fornece aos colaboradores a tempo inteiro. Limpar a diferenciação de contas externas facilita a prevenção e deteção de ataques provenientes destes vetores.

A sua escolha de IdP tem de ser capaz de fornecer essa diferenciação, fornecer funcionalidades incorporadas que concedam permissões com base no menor privilégio e fornecer informações sobre ameaças incorporadas. Isto inclui a monitorização de pedidos de acesso e inícios de sessão. O IdP do Azure é Microsoft Entra ID. Para obter mais informações, veja a secção Facilitação do Azure deste artigo.

Contas de impacto crítico

As identidades administrativas introduzem alguns dos maiores riscos de segurança de impacto porque as tarefas que executam requerem acesso privilegiado a um vasto conjunto destes sistemas e aplicações. O comprometimento ou utilização indevida podem ter um efeito prejudicial na sua empresa e nos respetivos sistemas de informação. A segurança da administração é uma das áreas de segurança mais críticas.

Proteger o acesso privilegiado contra adversários determinados requer uma abordagem completa e ponderada para isolar estes sistemas dos riscos. Seguem-se algumas estratégias:

  • Minimizar o número de contas de impacto crítico.

  • Utilize funções separadas em vez de elevar privilégios para identidades existentes.

  • Evite o acesso permanente ou permanente com as funcionalidades JIT do seu IdP. Para situações de quebra de vidro, siga um processo de acesso de emergência.

  • Utilize protocolos de acesso modernos , como autenticação sem palavra-passe ou autenticação multifator. Externalize esses mecanismos para o seu IdP.

  • Impor atributos de segurança principais através de políticas de acesso condicional.

  • Desativar contas administrativas que não estão a ser utilizadas.

Utilize uma única identidade entre ambientes e associe uma única identidade ao utilizador ou principal. A consistência das identidades em ambientes na cloud e no local reduz os erros humanos e os riscos de segurança resultantes. As equipas em ambos os ambientes que gerem recursos precisam de uma origem consistente e autoritativa para cumprir as garantias de segurança. Trabalhe com a sua equipa de identidade central para garantir que as identidades em ambientes híbridos são sincronizadas.

Risco: existe um risco associado à sincronização de identidades de privilégios elevados. Um atacante pode obter o controlo total dos recursos no local, o que pode levar a um comprometimento bem-sucedido de uma conta na cloud. Avalie a estratégia de sincronização ao filtrar as contas que podem ser adicionadas à superfície de ataque.

Estabelecer processos para gerir o ciclo de vida da identidade

O acesso às identidades não pode durar mais do que os recursos aos quais as identidades acedem. Certifique-se de que tem um processo para desativar ou eliminar identidades quando existirem alterações na estrutura da equipa ou nos componentes de software.

Esta documentação de orientação aplica-se ao controlo de origem, dados, planos de controlo, utilizadores de cargas de trabalho, infraestrutura, ferramentas, monitorização de dados, registos, métricas e outras entidades.

Estabeleça um processo de governação de identidades para gerir o ciclo de vida de identidades digitais, utilizadores com privilégios elevados, utilizadores externos/convidados e utilizadores de cargas de trabalho. Implemente revisões de acesso para garantir que, quando as identidades saem da organização ou da equipa, as respetivas permissões de carga de trabalho são removidas.

Proteger segredos não baseados em identidades

Os segredos da aplicação, como chaves pré-partilhadas, devem ser considerados pontos vulneráveis no sistema. Na comunicação bidirecional, se o fornecedor ou o consumidor estiver comprometido, podem ser introduzidos riscos de segurança significativos. Essas chaves também podem ser pesadas porque introduzem processos operacionais.

Quando puder, evite utilizar segredos e considere utilizar a autenticação baseada em identidade para o acesso do utilizador à própria aplicação e não apenas aos respetivos recursos.

A lista seguinte fornece um resumo das orientações. Para obter mais informações, veja Recomendações para segredos da aplicação.

  • Trate estes segredos como entidades que podem ser extraídas dinamicamente de um arquivo secreto. Não devem ser codificados no código da aplicação, scripts IaC, pipelines de implementação ou em qualquer outro artefacto.

  • Certifique-se de que tem a capacidade de revogar segredos.

  • Aplique práticas operacionais que processam tarefas como rotação de chaves e expiração.

Para obter informações sobre as políticas de rotação, veja Automatizar a rotação de um segredo para recursos com dois conjuntos de credenciais de autenticação e Tutorial: Atualizar a frequência de rotação automática de certificados no Key Vault.

Manter os ambientes de desenvolvimento seguros

Todos os códigos e scripts, ferramentas de pipeline e sistemas de controlo de origem devem ser considerados ativos de carga de trabalho. O acesso às escritas deve ser fechado com a automatização e a revisão em modo de peering. O acesso de leitura ao código fonte deve ser limitado a funções numa base de necessidade de saber. Os repositórios de código têm de ter controlo de versões e as revisões do código de segurança por parte dos pares têm de ser uma prática regular integrada no ciclo de vida de desenvolvimento. Tem de ter um processo em vigor que analise os recursos regularmente e identifique as vulnerabilidades mais recentes.

Utilize identidades de cargas de trabalho para conceder acesso a recursos de ambientes de implementação, como o GitHub.

Manter um registo de auditoria

Um aspeto da gestão de identidades é garantir que o sistema é auditável. As auditorias validam se as estratégias assume-violação são eficazes. Manter um registo de auditoria ajuda-o:

  • Verifique se a identidade está autenticada com autenticação forte. Qualquer ação tem de ser rastreável para evitar ataques de repúdio.

  • Detete protocolos de autenticação fracos ou em falta e obtenha visibilidade e informações sobre inícios de sessão de utilizadores e aplicações.

  • Avalie o acesso das identidades à carga de trabalho com base nos requisitos de segurança e conformidade e considere o risco da conta de utilizador, o estado do dispositivo e outros critérios e políticas que definiu.

  • Controlar o progresso ou desvio dos requisitos de conformidade.

A maioria dos recursos tem acesso ao plano de dados. Precisa de saber as identidades que acedem aos recursos e as ações que efetuam. Pode utilizar essas informações para diagnósticos de segurança.

Para obter mais informações, veja Recomendações sobre monitorização de segurança e análise de ameaças.

Facilitação do Azure

Recomendamos que utilize sempre protocolos de autenticação modernos que tenha em conta todos os pontos de dados disponíveis e utilizem o acesso condicional. Microsoft Entra ID fornece gestão de identidades e acessos no Azure. Abrange o plano de gestão do Azure e está integrado com os planos de dados da maioria dos serviços do Azure. Microsoft Entra ID é o inquilino associado à subscrição da carga de trabalho. Controla e gere identidades e as respetivas permissões permitidas e simplifica a gestão geral para minimizar o risco de descuido ou erro humano.

Estas capacidades integram-se nativamente no mesmo modelo de identidade e permissão Microsoft Entra para segmentos de utilizador:

Pode utilizar Microsoft Entra ID para autenticação e autorização de aplicações personalizadas através da Biblioteca de Autenticação da Microsoft (MSAL) ou funcionalidades da plataforma, como a autenticação para aplicações Web. Abrange o plano de gestão do Azure, os planos de dados da maioria dos serviços do Azure e as capacidades de integração das suas aplicações.

Pode manter-se atualizado ao visitar Novidades no Microsoft Entra ID.

Contrapartida: o Microsof Microsoft Entra ID é um ponto único de falha, tal como qualquer outro serviço fundamental. Não existe solução até que a falha seja corrigida pela Microsoft. No entanto, o conjunto de funcionalidades avançadas de Microsoft Entra supera o risco de utilizar soluções personalizadas.

O Azure suporta protocolos abertos, como o OAuth2 e o OpenID Connect. Recomendamos que utilize estes mecanismos padrão de autenticação e autorização em vez de criar os seus próprios fluxos.

RBAC do Azure

O RBAC do Azure representa principais de segurança no ID de Microsoft Entra. Todas as atribuições de funções são efetuadas através do RBAC do Azure. Tire partido das funções incorporadas que fornecem a maioria das permissões de que precisa. Para obter mais informações, veja Microsoft Entra funções incorporadas.

Eis alguns casos de utilização:

Para obter mais informações sobre o RBAC, veja Melhores práticas para o RBAC do Azure.

Para obter informações sobre controlos baseados em atributos, veja O que é o Azure ABAC?.

Identidade da carga de trabalho

Microsoft Entra ID pode processar a identidade da sua aplicação. O principal de serviço associado à aplicação pode ditar o âmbito de acesso.

Para obter mais informações, consulte O que são identidades de carga de trabalho?.

O principal de serviço também é abstrato quando utiliza uma identidade gerida. A vantagem é que o Azure gere todas as credenciais da aplicação.

Nem todos os serviços suportam identidades geridas. Se não conseguir utilizar identidades geridas, pode utilizar principais de serviço. No entanto, a utilização de principais de serviço aumenta a sobrecarga de gestão. Para obter mais informações, veja O que são identidades geridas para os recursos do Azure?.

Identidade do recurso

O conceito de identidades geridas pode ser alargado aos recursos do Azure. Os recursos do Azure podem utilizar identidades geridas para se autenticarem noutros serviços que suportam Microsoft Entra autenticação. Para obter mais informações, veja Serviços do Azure que podem utilizar identidades geridas para aceder a outros serviços.

Políticas de acesso condicional

O acesso condicional descreve a sua política para uma decisão de acesso. Para utilizar o acesso condicional, tem de compreender as restrições necessárias para o caso de utilização. Configure Microsoft Entra Acesso Condicional ao configurar uma política de acesso com base nas suas necessidades operacionais.

Para obter mais informações, veja Acesso condicional: Utilizadores, grupos e identidades de cargas de trabalho.

Gestão de acesso a grupos

Em vez de conceder permissões a utilizadores específicos, atribua acesso a grupos no Microsoft Entra ID. Se um grupo não existir, trabalhe com a sua equipa de identidade para criar um. Em seguida, pode adicionar e remover membros do grupo fora do Azure e certificar-se de que as permissões estão atuais. Também pode utilizar o grupo para outros fins, como listas de correio.

Para obter mais informações, veja Controlo de acesso seguro com grupos no Microsoft Entra ID.

Deteção de ameaças

Microsoft Entra ID Protection pode ajudá-lo a detetar, investigar e remediar riscos baseados em identidades. Para obter mais informações, consulte O que é o Identity Protection?.

A deteção de ameaças pode assumir a forma de reagir a um alerta de atividade suspeita ou procurar proativamente eventos anómalos nos registos de atividades. A Análise de Comportamento de Utilizadores e Entidades (UEBA) no Microsoft Sentinel facilita a deteção de atividades suspeitas. Para obter mais informações, veja Identificar ameaças avançadas com a UEBA.

Sistemas híbridos

No Azure, não sincronize as contas com Microsoft Entra ID com privilégios elevados no Active Directory existente. Esta sincronização está bloqueada na configuração predefinida do Microsoft Entra Connect Sync, pelo que só tem de confirmar que não personalizou esta configuração.

Para obter informações sobre a filtragem no ID do Microsoft Entra, veja Microsoft Entra Connect Sync: Configurar a filtragem.

Registo de identidades

Ative as definições de diagnóstico nos recursos do Azure para emitir informações que pode utilizar como um registo de auditoria. As informações de diagnóstico mostram que identidades tentam aceder a que recursos e o resultado dessas tentativas. Os registos recolhidos são enviados para o Azure Monitor.

Desvantagem: o registo implica custos devido ao armazenamento de dados utilizado para armazenar os registos. Também pode causar um impacto no desempenho, especialmente no código e nas soluções de registo que adicionar à aplicação.

Exemplo

O exemplo seguinte mostra uma implementação de identidade. São utilizados diferentes tipos de identidades em conjunto para fornecer os níveis de acesso necessários.

Diagrama que mostra uma implementação de identidade.

Componentes de identidade

  • Identidades geridas pelo sistema. Microsoft Entra ID fornece acesso a planos de dados de serviço que não enfrentam utilizadores, como Key Vault do Azure e arquivos de dados. Estas identidades também controlam o acesso, através do RBAC, ao plano de gestão do Azure para componentes de carga de trabalho, agentes de implementação e membros da equipa.

  • Identidades da carga de trabalho. Os serviços de aplicação no cluster Azure Kubernetes Service (AKS) utilizam identidades de carga de trabalho para se autenticarem noutros componentes na solução.

  • Identidades geridas. Os componentes do sistema na função de cliente utilizam identidades geridas pelo sistema, incluindo agentes de compilação.

  • Identidades humanas. A autenticação de utilizador e operador é delegada para Microsoft Entra ID ou ID de Microsoft Entra (nativo, B2B ou B2C).

A segurança dos segredos pré-partilhados é fundamental para qualquer aplicação. O Azure Key Vault fornece um mecanismo de armazenamento seguro para estes segredos, incluindo o Redis e segredos de terceiros.

Um mecanismo de rotação é utilizado para ajudar a garantir que os segredos não são comprometidos. Os tokens para a implementação plataforma de identidades da Microsoft do OAuth 2 e do OpenID Connect são utilizados para autenticar utilizadores.

Azure Policy é utilizado para garantir que componentes de identidade como Key Vault utilizam o RBAC em vez de políticas de acesso. O JIT e a JEA fornecem permissões permanentes tradicionais para operadores humanos.

Os registos de acesso são ativados em todos os componentes através de Diagnóstico do Azure ou através de código para componentes de código.

Lista de verificação de segurança

Veja o conjunto completo de recomendações.

Lista de verificação de segurança