Gerenciamento de identidade e acesso ao aplicativo
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 de nuvem.
Se sua equipe migrar ou criar aplicativos nativos de 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 entre si, por exemplo, quando um aplicativo Web acessa um banco de dados SQL.
Na área de design de automação de plataforma e DevOps, recomendamos que sua equipe de aplicativos faça a transição das cargas de trabalho para a venda de assinaturas. 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 sobre o 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 landing zone do 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 RBAC (controle de acesso baseado em função) 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?
Há algum requisito para acessar os recursos compartilhados, como os Serviços de Domínio Microsoft Entra, implantados na zona de destino da plataforma?
Azure Key Vault e identidades gerenciadas
As violações de segurança de recursos de nuvem pública geralmente se originam de credenciais vazadas incorporadas em código ou outro texto. Você pode usar identidades gerenciadas e o Key Vault 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 Key Vault 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 dê 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 dão 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 as entidades de serviço e as identidades gerenciadas acessam os 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 aplicativo de ID do Microsoft Entra. 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 normalmente 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 aplicativo para sua equipe de aplicativos.
Você pode usar identidades gerenciadas para autenticar em qualquer serviço que dê suporte à autenticação do Microsoft Entra. No entanto, nem todos os serviços dão suporte a 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 do 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 VMs (máquinas virtuais) do Azure para autenticar em qualquer serviço que dê 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 movimentação, você deve recriar as identidades gerenciadas e atribuí-las ao recurso. Para obter mais informações, consulte Mover recursos para um novo grupo de recursos ou assinatura.
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 de privilégios mínimos ao conceder acesso a uma identidade gerenciada a um recurso.
Usuários externos
Você pode avaliar cenários que envolvem a configuração de usuários, clientes ou parceiros externos para que eles possam acessar recursos. Determine se esses cenários envolvem configurações do Microsoft Entra B2B ou do Azure Active Directory B2C (Azure AD B2C). Para obter mais informações, consulte Visão geral da ID externa do Microsoft Entra.
Recomendações sobre design
Considere as recomendações a seguir ao projetar o gerenciamento de identidade e acesso de seus aplicativos.
OpenID Connect
Se sua equipe de aplicativos usar pipelines de CI/CD (integração contínua e entrega contínua) 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 e sem credenciais para autenticar nos serviços do Azure. Para obter mais informações, consulte Federação de identidade de carga de trabalho.
Se não houver suporte para o OpenID Connect, crie uma entidade de serviço e atribua as permissões necessárias para permitir que o código da infraestrutura ou do aplicativo seja implantado. 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 atributo
Para restringir ainda mais o acesso e impedir o acesso não autorizado aos dados, use o ABAC (controle de acesso baseado em atributo) quando houver suporte, por exemplo, com o Armazenamento de Blobs do Azure.
Acessar 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 a 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 MFA (autenticação multifator) 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 Fazer logon em uma máquina virtual Linux no Azure usando a ID do Microsoft Entra e o OpenSSH e Fazer logon em uma máquina virtual do Windows no Azure usando a ID do Microsoft Entra, incluindo sem senha.
Plataforma de identidade da Microsoft
Quando os desenvolvedores criam um aplicativo nativo de 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
Para contas pessoais da Microsoft (Skype, Xbox, Outlook.com)
Contas sociais ou locais, usando a ID do Microsoft Entra
A lista de verificação de práticas recomendadas e recomendações da plataforma de identidade da Microsoft fornece diretrizes sobre como integrar efetivamente o aplicativo à plataforma de identidade da Microsoft.
Identidades gerenciadas
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 Agente do Azure Monitor requer uma identidade gerenciada em VMs do Azure monitoradas, o que pode fazer com que a ID do Microsoft Entra 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 o Azure Policy para implementar essa recomendação.
Key Vault
Você pode usar o Key Vault para gerenciar os segredos, chaves e certificados que os aplicativos usam.
Para gerenciar o acesso a segredos (plano de dados) e para acesso administrativo (plano de controle), use o RBAC.
Para controlar o acesso do aplicativo ao Key Vault, use identidades gerenciadas.
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 do plano de dados) e o acesso ao Key Vault (painel de controle). Implante cofres de chaves que tenham segredos de aplicativo nas zonas de destino do aplicativo.
Proxy do aplicativo do Microsoft Entra
Para acessar aplicativos que usam a autenticação local remotamente por meio da ID do Microsoft Entra, use o proxy de aplicativo do Microsoft Entra. O proxy de aplicativo do 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 na ID do Microsoft Entra, os usuários podem acessar aplicativos locais e na nuvem por meio de uma URL externa ou de um portal de aplicativos interno.
Você pode implantar o proxy de aplicativo do Microsoft Entra como uma única instância em um locatário de ID do Microsoft Entra. A configuração requer pelo menos a função de ID do Microsoft Entra com privilégios de Administrador de Aplicativos. Se sua organização usar a democratização de assinatura como um modelo de atribuição de função, os proprietários do aplicativo podem não ter as permissões necessárias para configurar o proxy de aplicativo do Microsoft Entra. Nesse caso, a equipe de plataforma deve configurar o proxy de aplicativo do 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 do aplicativo 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 destino do aplicativo tem conectividade de rede com controladores de domínio na assinatura da plataforma de identidade da Microsoft.