Partilhar via

Gerenciamento de identidade e acesso de aplicativos

  • Artigo

Este artigo descreve considerações e recomendações que os proprietários e desenvolvedores de aplicativos podem usar para projetar o gerenciamento de identidade e acesso para aplicativos nativos da nuvem.

Se sua equipe migrar ou criar aplicativos nativos da nuvem, você deverá considerar os requisitos de autenticação e acesso para os aplicativos. Esses requisitos determinam como os usuários se autenticam em aplicativos e como os recursos do aplicativo se autenticam uns nos outros, por exemplo, quando um aplicativo Web acessa um banco de dados SQL.

Na área de automação de plataforma e design de DevOps, recomendamos que sua equipe de aplicativos faça a transição de cargas de trabalho para a concessão de assinatura. Como parte do processo de venda automática de assinaturas, sua equipe de aplicativos precisa fornecer requisitos de identidade e acesso à equipe da plataforma para que eles possam criar as assinaturas apropriadas. Os proprietários de aplicativos são responsáveis pelo gerenciamento de identidade e acesso de aplicativos individuais. Eles devem gerenciar seu aplicativo usando os serviços centralizados que a equipe da plataforma fornece.

Considerações de design

Para ajudar a reduzir o risco de acesso não autorizado aos seus aplicativos, incorpore as seguintes considerações em seu design.

  • Existem vários padrões de autenticação e autorização, como OAuth 2.0, OpenID Connect, JSON web tokens (JWTs) e SAML (Security Assertion Markup Language). Determine quais padrões de autenticação e autorização usar para seu aplicativo.

  • Ao solicitar uma zona de aterrissagem de aplicativo da equipe da plataforma, você pode ajudar a garantir que eles criem as assinaturas apropriadas fazendo as seguintes perguntas:

    • Como os usuários finais se autenticarão e acessarão o aplicativo?

    • Quem precisa de permissões de controle de acesso baseado em função (RBAC) para recursos e serviços que o aplicativo usa?

    • As funções internas existentes cobrem os requisitos de acesso RBAC para acesso ao plano de controle e ao plano de dados ou você precisa criar novas funções personalizadas?

    • A equipe da plataforma implementou alguma política de conformidade que possa causar problemas com o aplicativo?

    • Quais componentes do aplicativo precisam se comunicar entre si?

    • Existem requisitos para acessar os recursos compartilhados, como os Serviços de Domínio Microsoft Entra, que são implantados na zona de aterrissagem da plataforma?

Azure Key Vault e identidades gerenciadas

  • As violações de segurança dos recursos de nuvem pública geralmente têm origem em credenciais vazadas que são incorporadas em código ou outro texto. Você pode usar identidades gerenciadas e o Cofre de Chaves para implementar o acesso programático e ajudar a reduzir o risco de roubo de credenciais.

  • Se seu aplicativo ou carga de trabalho exigir um serviço para armazenar credenciais com segurança, você poderá usar o Cofre da Chave para gerenciar segredos, chaves e certificados.

  • Para evitar ter credenciais em seu código, você pode usar identidades gerenciadas com VMs do Azure para autenticar em qualquer serviço que ofereça suporte à autenticação de ID do Microsoft Entra. Para obter mais informações, consulte Usar identidades gerenciadas para recursos do Azure em uma VM para adquirir um token de acesso.

  • As identidades gerenciadas fornecem uma entidade de identidade gerenciada automaticamente que os aplicativos e recursos usam quando se conectam a recursos que oferecem suporte à autenticação de ID do Microsoft Entra. Os aplicativos podem usar identidades gerenciadas para obter tokens de ID do Microsoft Entra sem precisar gerenciar nenhuma credencial.

    • Você pode usar identidades gerenciadas atribuídas pelo sistema ou pelo usuário.

    • É fácil confundir como entidades de serviço e identidades gerenciadas acessam recursos do Azure. Para entender a diferença entre os dois, consulte Desmistificando entidades de serviço — identidades gerenciadas.

    • Sempre que possível, use identidades gerenciadas para dar suporte à autenticação em vez de usar entidades de serviço e registros de aplicativos Microsoft Entra ID. Você deve ter as funções RBAC de Administrador de Aplicativos ou Desenvolvedor de Aplicativos para criar entidades de serviço e registros de aplicativos. Essas funções privilegiadas geralmente são atribuídas à equipe da plataforma ou à equipe de identidade. Use identidades gerenciadas para eliminar a necessidade de a equipe da plataforma criar entidades de serviço e registros de aplicativos para sua equipe de aplicativos.

    • Você pode usar identidades gerenciadas para autenticar em qualquer serviço que ofereça suporte à autenticação do Microsoft Entra. No entanto, nem todos os serviços suportam identidades gerenciadas para acessar outros serviços. Para alguns serviços, pode ser necessário armazenar credenciais. Você deve armazenar credenciais com segurança, evitar compartilhar credenciais com outros serviços e seguir o princípio de menor privilégio. Para obter mais informações, consulte Serviços do Azure que podem usar identidades gerenciadas para acessar outros serviços.

    • Você pode usar identidades gerenciadas com máquinas virtuais (VMs) do Azure para autenticar em qualquer serviço que ofereça suporte à autenticação de ID do Microsoft Entra. Para obter mais informações, consulte Usar identidades gerenciadas para recursos do Azure em uma VM para adquirir um token de acesso.

    • Há restrições para mover recursos com identidades gerenciadas entre assinaturas e regiões. Por exemplo, você pode mover recursos entre assinaturas ou regiões para uma fusão, aquisição ou repatriação de recursos por motivos de soberania de dados.

      Se um recurso do Azure tiver identidades atribuídas pelo usuário ou pelo sistema, você não poderá transferir o recurso para outra assinatura ou região do Azure. Você deve excluir as identidades gerenciadas antes de mover o recurso. Após a mudança, você deve recriar as identidades gerenciadas e atribuí-las ao recurso. Para obter mais informações, veja Mover recursos para um novo grupo de recursos ou subscrição.

    • Se você mover uma assinatura de um diretório para outro, as identidades gerenciadas não serão preservadas. Você deve mover o recurso e, em seguida, recriar manualmente as identidades gerenciadas.

    • Semelhante às atribuições de função RBAC do usuário, siga o princípio do menor privilégio ao conceder acesso a uma identidade gerenciada a um recurso.

Utilizadores externos

Você pode avaliar cenários que envolvem a configuração de usuários externos, clientes ou parceiros para que eles possam acessar recursos. Determine se esses cenários envolvem configurações do Microsoft Entra B2B ou do Azure Ative Directory B2C (Azure AD B2C). Para obter mais informações, consulte Visão geral da ID externa do Microsoft Entra.

Recomendações de design

Considere as seguintes recomendações ao projetar o gerenciamento de identidade e acesso de seus aplicativos.

OpenID Connect

Se sua equipe de aplicativos usa pipelines de integração contínua e entrega contínua (CI/CD) para implantar aplicativos programaticamente, configure a autenticação do OpenID Connect para seus serviços do Azure. O OpenID Connect usa um token temporário sem credenciais para autenticar nos serviços do Azure. Para obter mais informações, consulte Federação de identidades de carga de trabalho.

Se o OpenID Connect não for suportado, crie uma entidade de serviço e atribua as permissões necessárias para permitir que a infraestrutura ou o código do aplicativo sejam implantados. Para obter mais informações, consulte o módulo de treinamento, Autenticar seu pipeline de implantação do Azure usando entidades de serviço.

Controle de acesso baseado em atributos

Para restringir ainda mais o acesso e impedir o acesso não autorizado aos dados, use o controle de acesso baseado em atributos (ABAC) onde houver suporte, por exemplo, com o Armazenamento de Blobs do Azure.

Acesso à máquina virtual

Sempre que possível, use identidades de ID do Microsoft Entra para controlar o acesso às máquinas virtuais do Azure. Use o ID do Microsoft Entra em vez da autenticação local para fornecer acesso a máquinas virtuais, aproveitando o Acesso Condicional do Microsoft Entra, o log de auditoria e a autenticação multifator (MFA) do Microsoft Entra. Essa configuração reduz o risco de invasores explorarem serviços de autenticação local inseguros. Para obter mais informações, consulte Entrar em uma máquina virtual Linux no Azure usando o Microsoft Entra ID e o OpenSSH e Fazer logon em uma máquina virtual do Windows no Azure usando o Microsoft Entra ID, incluindo sem senha.

Plataforma de identidade da Microsoft

  • Quando os desenvolvedores criam um aplicativo nativo da nuvem, eles devem usar a plataforma de identidade da Microsoft para desenvolvedores como o provedor de identidade para seus aplicativos. A plataforma de identidade da Microsoft fornece um serviço de autenticação compatível com o padrão OpenID Connect que os desenvolvedores podem usar para autenticar vários tipos de identidade, incluindo:

    • Contas corporativas ou de estudante, provisionadas por meio do Microsoft Entra ID

    • Contas pessoais da Microsoft (Skype, Xbox, Outlook.com)

    • Contas sociais ou locais, usando o Microsoft Entra ID

  • A lista de verificação de práticas recomendadas e recomendações da plataforma de identidade da Microsoft fornece orientação sobre a integração eficaz do aplicativo com a plataforma de identidade da Microsoft.

Identidades geridas

  • Para habilitar o acesso entre recursos do Azure que não precisam usar credenciais, use identidades gerenciadas.

  • Você não deve compartilhar credenciais ou identidades gerenciadas entre vários ambientes ou aplicativos. Por exemplo, não use identidades para recursos de produção e também em recursos de desenvolvimento/teste, mesmo para o mesmo aplicativo. Crie credenciais separadas para cada instância de um aplicativo para reduzir a probabilidade de uma instância de teste comprometida afetar os dados de produção. Credenciais separadas também facilitam a revogação de credenciais quando elas não são mais necessárias.

  • Quando houver um requisito para usar identidades gerenciadas em escala, use uma identidade gerenciada atribuída pelo usuário para cada tipo de recurso em cada região. Essa abordagem evita uma rotatividade de identidades. Por exemplo, o Azure Monitor Agent requer uma identidade gerenciada em VMs do Azure monitoradas, o que pode fazer com que o Microsoft Entra ID crie (e exclua) um número substancial de identidades. Você pode criar identidades gerenciadas atribuídas pelo usuário uma vez e compartilhá-las em várias VMs. Use a Política do Azure para implementar essa recomendação.

Key Vault

  • Você pode usar o Cofre da Chave para gerenciar os segredos, chaves, certificados que os aplicativos usam.

  • Você deve usar cofres de chaves separados para cada ambiente de aplicativo (desenvolvimento, pré-produção, produção) em cada região. Use o RBAC para gerenciar o acesso a segredos, chaves e certificados (operações de plano de dados) e o acesso ao Cofre de Chaves (plano de controle). Implante cofres de chaves com segredos de aplicativos nas zonas de aterrissagem do aplicativo.

Proxy de aplicativo Microsoft Entra

  • Para acessar aplicativos que usam autenticação local remotamente por meio do Microsoft Entra ID, use o proxy de aplicativo Microsoft Entra. O proxy de aplicativo Microsoft Entra fornece acesso remoto seguro a aplicativos Web locais, incluindo aplicativos que usam protocolos de autenticação mais antigos. Após um logon único no Microsoft Entra ID, os usuários podem acessar aplicativos na nuvem e locais por meio de uma URL externa ou de um portal de aplicativo interno.

    • Você pode implantar o proxy de aplicativo do Microsoft Entra como uma única instância em um locatário do Microsoft Entra ID. A configuração requer as funções de ID privilegiadas do Microsoft Entra de Administrador de Aplicativos ou Administrador Global. Se sua organização usa a democratização da assinatura como um modelo de atribuição de função, os proprietários de aplicativos podem não ter as permissões necessárias para configurar o proxy de aplicativo do Microsoft Entra. Nesse caso, a equipe da plataforma deve configurar o proxy do aplicativo Microsoft Entra para o proprietário do aplicativo.

    • Se você usar pipelines de implantação de CI/CD com permissões suficientes, os proprietários de aplicativos poderão configurar o proxy de aplicativo do Microsoft Entra usando a API do Microsoft Graph.

  • Se o aplicativo usar protocolos herdados, como Kerberos, verifique se a zona de aterrissagem do aplicativo tem conectividade de rede com controladores de domínio na assinatura da plataforma de identidade da Microsoft.

Próximos passos

Organização de recursos