Visão geral dos provedores de identidade para o Azure Stack Hub
O Azure Stack Hub requer o Microsoft Entra ID ou os Serviços de Federação do Ative Directory (AD FS), apoiados pelo Ative Directory como um provedor de identidade. A escolha de um provedor é uma decisão única que você toma quando implanta o Azure Stack Hub pela primeira vez. Os conceitos e detalhes de autorização neste artigo podem ajudá-lo a escolher entre provedores de identidade.
Sua escolha entre Microsoft Entra ID ou AD FS é determinada pelo modo em que você implanta o Azure Stack Hub:
- Ao implantá-lo em um modo conectado, você pode usar a ID do Microsoft Entra ou o AD FS.
- Quando você o implanta em um modo desconectado, sem uma conexão com a Internet, apenas o AD FS é suportado.
Para obter mais informações sobre suas opções, que dependem do seu ambiente do Azure Stack Hub, consulte os seguintes artigos:
- Kit de desenvolvimento do Azure Stack Hub: considerações de identidade.
- Sistemas integrados do Azure Stack Hub: decisões de planejamento de implantação para sistemas integrados do Azure Stack Hub.
Importante
O Azure AD Graph está sendo preterido e será desativado em 30 de junho de 2023. Para obter mais informações, veja esta secção.
Conceitos comuns para provedores de identidade
As próximas seções discutem conceitos comuns sobre provedores de identidade e seu uso no Azure Stack Hub.
Locatários e organizações de diretório
Um diretório é um contêiner que contém informações sobre usuários, aplicativos, grupos e entidades de serviço.
Um locatário de diretório é uma organização, como a Microsoft ou sua própria empresa.
- O Microsoft Entra ID suporta vários inquilinos e pode suportar múltiplas organizações, cada uma no seu diretório. Se você usa o Microsoft Entra ID e tem vários locatários, pode conceder aos aplicativos e usuários de um locatário acesso a outros locatários desse mesmo diretório.
- O AD FS suporta apenas um único locatário e, portanto, apenas uma única organização.
Utilizadores e grupos
Contas de usuário (identidades) são contas padrão que autenticam indivíduos usando um ID de usuário e senha. Os grupos podem incluir usuários ou outros grupos.
A forma como você cria e gerencia usuários e grupos depende da solução de identidade usada.
No Azure Stack Hub, as contas de usuário:
- São criados no formato username@domain . Embora o AD FS mapeie contas de usuário para uma instância do Ative Directory, o AD FS não oferece suporte ao uso do formato \<domínio>\<alias> .
- Pode ser configurado para usar autenticação multifator.
- Estão restritos ao diretório onde eles se registram primeiro, que é o diretório de sua organização.
- Pode ser importado de seus diretórios locais. Para obter mais informações, consulte Integrar seus diretórios locais com o Microsoft Entra ID.
Quando inicia sessão no portal de utilizador da sua organização, utiliza o https://portal.local.azurestack.external URL. Ao entrar no portal do Azure Stack Hub a partir de domínios diferentes daquele usado para registrar o Azure Stack Hub, o nome de domínio usado para registrar o Azure Stack Hub deve ser anexado à URL do portal. Por exemplo, se o Azure Stack Hub tiver sido registrado com fabrikam.onmicrosoft.com e a conta de usuário fizer logon for admin@contoso.com, a URL a ser usada para fazer logon no portal do usuário será: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.
Utilizadores convidados
Os usuários convidados são contas de usuário de outros locatários de diretório aos quais foi concedido acesso a recursos em seu diretório. Para oferecer suporte a usuários convidados, use o Microsoft Entra ID e habilite o suporte para multilocação. Quando o suporte está habilitado, você pode convidar usuários convidados para acessar recursos em seu locatário de diretório, o que, por sua vez, permite a colaboração deles com organizações externas.
Para convidar usuários convidados, os operadores de nuvem e os usuários podem usar a colaboração B2B do Microsoft Entra. Os usuários convidados têm acesso a documentos, recursos e aplicativos do seu diretório e você mantém o controle sobre seus próprios recursos e dados.
Como usuário convidado, você pode entrar no locatário de diretório de outra organização. Para fazer isso, anexe o nome do diretório dessa organização à URL do portal. Por exemplo, se você pertencer à organização da Contoso e quiser entrar no diretório da Fabrikam, use https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.
Aplicações
Pode registar aplicações no Microsoft Entra ID ou AD FS e, em seguida, oferecer as aplicações aos utilizadores na sua organização.
As aplicações incluem:
- Aplicativos Web: os exemplos incluem o portal do Azure e o Azure Resource Manager. Eles suportam chamadas de API da Web.
- Cliente nativo: os exemplos incluem o Azure PowerShell, o Visual Studio e a CLI do Azure.
As aplicações podem suportar dois tipos de arrendamento:
Inquilino único: suporta utilizadores e serviços apenas a partir do mesmo diretório onde a aplicação está registada.
Nota
Como o AD FS oferece suporte a apenas um único diretório, os aplicativos criados em uma topologia do AD FS são, por design, aplicativos de locatário único.
Multilocatário: Suporta o uso por usuários e serviços do diretório onde o aplicativo está registrado e diretórios de locatários adicionais. Com aplicativos multilocatário, os usuários de outro diretório de locatário (outro locatário do Microsoft Entra) podem entrar em seu aplicativo.
Para obter mais informações sobre multilocação, consulte Habilitar multilocação.
Para obter mais informações sobre como desenvolver um aplicativo multilocatário, consulte Aplicativos multilocatário.
Ao registrar um aplicativo, você cria dois objetos:
Objeto do aplicativo: a representação global do aplicativo em todos os locatários. Essa relação é um-para-um com o aplicativo de software e existe apenas no diretório onde o aplicativo é registrado pela primeira vez.
Objeto principal do serviço: uma credencial criada para um aplicativo no diretório onde o aplicativo foi registrado pela primeira vez. Uma entidade de serviço também é criada no diretório de cada locatário adicional onde esse aplicativo é usado. Essa relação pode ser um-para-muitos com o aplicativo de software.
Para saber mais sobre objetos de entidade de aplicativo e serviço, consulte Objetos principais de aplicativo e serviço na ID do Microsoft Entra.
Principais de serviço
Uma entidade de serviço é um conjunto de credenciais para um aplicativo ou serviço que concede acesso a recursos no Azure Stack Hub. O uso de uma entidade de serviço separa as permissões do aplicativo das permissões do usuário do aplicativo.
Uma entidade de serviço é criada em cada locatário onde o aplicativo é usado. A entidade de serviço estabelece uma identidade para entrada e acesso a recursos (como usuários) que são protegidos por esse locatário.
- Um aplicativo de locatário único tem apenas uma entidade de serviço, que está no diretório onde foi criado pela primeira vez. Essa entidade de serviço é criada e consente em ser usada durante o registro do aplicativo.
- Uma API ou aplicativo Web multilocatário tem uma entidade de serviço criada em cada locatário em que um usuário desse locatário consente com o uso do aplicativo.
As credenciais para entidades de serviço podem ser uma chave gerada através do portal do Azure ou um certificado. O uso de um certificado é adequado para automação porque os certificados são considerados mais seguros do que as chaves.
Nota
Quando você usa o AD FS com o Azure Stack Hub, somente o administrador pode criar entidades de serviço. Com o AD FS, as entidades de serviço exigem certificados e são criadas por meio do ponto de extremidade privilegiado (PEP). Para obter mais informações, consulte Usar uma identidade de aplicativo para acessar recursos.
Para saber mais sobre entidades de serviço para o Azure Stack Hub, consulte Criar entidades de serviço.
Serviços
Os serviços no Azure Stack Hub que interagem com o provedor de identidade são registrados como aplicativos com o provedor de identidade. Assim como os aplicativos, o registro permite que um serviço se autentique com o sistema de identidade.
Todos os serviços do Azure usam protocolos OpenID Connect e Web Tokens JSON para estabelecer sua identidade. Como o Microsoft Entra ID e o AD FS usam protocolos de forma consistente, você pode usar a Biblioteca de Autenticação da Microsoft (MSAL) para obter um token de segurança para autenticar no local ou no Azure (em um cenário conectado). Com o MSAL, você também pode usar ferramentas como o Azure PowerShell e a CLI do Azure para gerenciamento de recursos entre nuvens e locais.
Identidades e seu sistema de identidade
As identidades do Azure Stack Hub incluem contas de usuário, grupos e entidades de serviço.
Quando você instala o Azure Stack Hub, vários aplicativos e serviços internos se registram automaticamente com seu provedor de identidade no locatário do diretório. Alguns serviços que se registam são utilizados para administração. Outros serviços estão disponíveis para os usuários. Os registros padrão fornecem identidades de serviços principais que podem interagir entre si e com identidades que você adiciona posteriormente.
Se você configurar o Microsoft Entra ID com multilocação, alguns aplicativos se propagarão para os novos diretórios.
Autenticação e autorização
Autenticação por aplicativos e usuários
Para aplicativos e usuários, a arquitetura do Azure Stack Hub é descrita por quatro camadas. As interações entre cada uma dessas camadas podem usar diferentes tipos de autenticação.
| Camada | Autenticação entre camadas |
|---|---|
| Ferramentas e clientes, como o portal do administrador | Para acessar ou modificar um recurso no Azure Stack Hub, as ferramentas e os clientes usam um Token Web JSON para fazer uma chamada para o Gerenciador de Recursos do Azure. O Azure Resource Manager valida o Token Web JSON e espreita as declarações no token emitido para estimar o nível de autorização que o utilizador ou entidade de serviço tem no Azure Stack Hub. |
| Azure Resource Manager e seus serviços principais | O Azure Resource Manager comunica com fornecedores de recursos para transferir comunicações dos utilizadores. As transferências usam chamadas imperativas diretas ou chamadas declarativas por meio de modelos do Azure Resource Manager. |
| Fornecedores de recursos | As chamadas passadas para provedores de recursos são protegidas com autenticação baseada em certificado. O Azure Resource Manager e o provedor de recursos permanecem em comunicação por meio de uma API. Para cada chamada recebida do Azure Resource Manager, o provedor de recursos valida a chamada com esse certificado. |
| Infraestrutura e lógica de negócios | Os provedores de recursos se comunicam com a lógica de negócios e a infraestrutura usando um modo de autenticação de sua escolha. Os provedores de recursos padrão fornecidos com o Azure Stack Hub usam a Autenticação do Windows para proteger essa comunicação. |
Autenticar no Azure Resource Manager
Para autenticar com o provedor de identidade e receber um token Web JSON, você deve ter as seguintes informações:
- URL do sistema de identidade (Autoridade): o URL no qual seu provedor de identidade pode ser acessado. Por exemplo, https://login.windows.net.
- URI da ID do Aplicativo para o Gerenciador de Recursos do Azure: o identificador exclusivo do Gerenciador de Recursos do Azure registrado com seu provedor de identidade. Também é exclusivo para cada instalação do Azure Stack Hub.
- Credenciais: a credencial que você usa para autenticar com o provedor de identidade.
- URL para o Azure Resource Manager: A URL é o local do serviço Azure Resource Manager. Por exemplo, https://management.azure.com ou https://management.local.azurestack.external.
Quando uma entidade de segurança (um cliente, aplicativos ou usuário) faz uma solicitação de autenticação para acessar um recurso, a solicitação deve incluir:
- As credenciais do diretor.
- O URI da ID do aplicativo do recurso que a entidade de segurança deseja acessar.
As credenciais são validadas pelo provedor de identidade. O provedor de identidade também valida se o URI da ID do aplicativo é para um aplicativo registrado e se a entidade de segurança tem os privilégios corretos para obter um token para esse recurso. Se a solicitação for válida, um token Web JSON será concedido.
Em seguida, o token deve passar o cabeçalho de uma solicitação para o Gerenciador de Recursos do Azure. O Azure Resource Manager faz o seguinte, sem ordem específica:
- Valida a declaração do emissor (iss) para confirmar que o token é do provedor de identidade correto.
- Valida a declaração de audiência (aud) para confirmar que o token foi emitido para o Azure Resource Manager.
- Valida se o Token Web JSON está assinado com um certificado configurado por meio do OpenID e conhecido pelo Gerenciador de Recursos do Azure.
- Analise as declarações emitidas em (iat) e expiração (exp) para confirmar que o token está ativo e pode ser aceito.
Quando todas as validações são concluídas, o Azure Resource Manager usa a id do objeto (oid) e os grupos afirmam fazer uma lista de recursos que a entidade de segurança pode acessar.
Usar controle de acesso baseado em função
O RBAC (Controle de Acesso Baseado em Função) no Azure Stack Hub é consistente com a implementação no Microsoft Azure. Você pode gerenciar o acesso a recursos atribuindo a função RBAC apropriada a usuários, grupos e aplicativos. Para obter informações sobre como usar o RBAC com o Azure Stack Hub, consulte os seguintes artigos:
- Introdução ao Controle de Acesso Baseado em Função no portal do Azure.
- Use o Controle de Acesso Baseado em Função para gerenciar o acesso aos recursos de assinatura do Azure.
- Crie funções personalizadas para o Controle de Acesso Baseado em Função do Azure.
- Gerencie o controle de acesso baseado em função no Azure Stack Hub.
Autenticar com o Azure PowerShell
Detalhes sobre como usar o Azure PowerShell para autenticar com o Azure Stack Hub podem ser encontrados em Configurar o ambiente PowerShell do usuário do Azure Stack Hub.
Autenticar com a CLI do Azure
Para obter informações sobre como usar o Azure PowerShell para autenticar com o Azure Stack Hub, consulte Instalar e configurar a CLI do Azure para uso com o Azure Stack Hub.
Azure Policy
A Política do Azure ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Por meio de seu painel de conformidade, ele fornece uma visão agregada para avaliar o estado geral do ambiente, com a capacidade de detalhar a granularidade por recurso e por política. Também ajuda a fazer com que os recursos fiquem em conformidade através da remediação em massa dos recursos existentes e da reparação automática dos recursos novos.
Casos comuns de utilização do Azure Policy incluem a implementação de governação para consistência de recursos, conformidade regulamentar, segurança, custos e gestão. As definições de política para esses casos de uso comuns já estão incorporadas ao seu ambiente do Azure para ajudá-lo a começar.
Nota
Atualmente, não há suporte para a Política do Azure no Azure Stack Hub.
Azure AD Graph
O Microsoft Azure anunciou a substituição do Azure AD Graph em 30 de junho de 2020 e sua data de desativação em 30 de junho de 2023. A Microsoft informou os clientes por e-mail sobre essa alteração. Para obter informações mais detalhadas, consulte o blog Azure AD Graph Retirement and Powershell Module Deprecation .
A seção a seguir descreve como essa substituição afeta o Azure Stack Hub.
A equipe do Azure Stack Hub está trabalhando em estreita colaboração com a equipe do Azure Graph para garantir que seus sistemas continuem a funcionar além de 30 de junho de 2023, se necessário, para garantir uma transição suave. A ação mais importante é garantir que você esteja em conformidade com a política de serviço do Azure Stack Hub. Os clientes receberão um alerta no portal do administrador do Azure Stack Hub e serão obrigados a atualizar o diretório base e todos os diretórios de convidados integrados.
A maior parte da migração em si será feita pela experiência de atualização do sistema integrado; haverá uma etapa manual exigida pelos clientes para conceder novas permissões a esses aplicativos, o que exigirá permissões de administrador de aplicativos em cada diretório do Microsoft Entra usado com seus ambientes do Azure Stack Hub. Depois que o pacote de atualização com essas alterações concluir a instalação, um alerta será gerado no portal de administração orientando você a concluir esta etapa usando a interface do usuário de multilocação ou os scripts do PowerShell. Esta é a mesma operação que você executa ao integrar diretórios adicionais ou provedores de recursos; para obter mais informações, consulte Configurar multilocação no Azure Stack Hub.
Se você usar o AD FS como seu sistema de identidade com o Azure Stack Hub, essas alterações no Graph não afetarão seu sistema diretamente. No entanto, as versões mais recentes de ferramentas como CLI do Azure, Azure PowerShell, etc., exigem as novas APIs do Graph e elas não funcionarão. Certifique-se de usar apenas as versões dessas ferramentas que são explicitamente suportadas com sua compilação do Azure Stack Hub.
Além do alerta no portal de administração, comunicaremos as alterações por meio das notas de versão de atualização e comunicaremos qual pacote de atualização requer a atualização do diretório inicial e de todos os diretórios de convidados integrados.