Visão geral dos provedores de identidade para o Azure Stack Hub
O Azure Stack Hub requer Microsoft Entra ID ou Serviços de Federação do Active Directory (AD FS) (AD FS), com o suporte do Active Directory como um provedor de identidade. A escolha de um provedor é uma decisão única que você tomará na primeira implantação do Azure Stack Hub. Os conceitos e detalhes de autorização neste artigo podem ajudá-lo a escolher entre provedores de identidade.
Sua escolha de Microsoft Entra ID ou AD FS é determinada pelo modo no qual você implanta o Azure Stack Hub:
- Ao implantá-lo em um modo conectado, você pode usar Microsoft Entra ID ou AD FS.
- Ao implantá-lo no modo desconectado, sem uma conexão com a Internet, somente o AD FS tem suporte.
Para obter mais informações sobre suas opções, que dependem do ambiente do Azure Stack Hub, consulte os seguintes artigos:
- Kit de desenvolvimento do Azure Stack Hub: considerações sobre identidade.
- Sistemas integrados do Azure Stack Hub: decisões de planejamento de implantação para sistemas integrados do Azure Stack Hub.
Importante
Azure AD Graph está sendo preterido e será desativado em 30 de junho de 2023. Para obter mais informações, consulte esta seçã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.
- Microsoft Entra ID dá suporte a vários locatários e pode dar suporte a várias organizações, cada uma em seu próprio diretório. Se você usar Microsoft Entra ID e tiver vários locatários, poderá conceder a aplicativos e usuários de um locatário acesso a outros locatários desse mesmo diretório.
- O AD FS é compatível apenas com um único locatário e, portanto, apenas com uma única organização.
Usuários e grupos
As contas de usuário (identidades) são contas padrão que autenticam indivíduos usando uma ID de usuário e uma senha. Os grupos podem incluir usuários ou outros grupos.
A maneira como você cria e gerencia os 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 Active Directory, o AD FS não dá suporte ao uso do formato \<domain>\<alias> .
- Pode ser configurado para usar a autenticação multifator.
- São restritas ao diretório em que elas se registram pela primeira vez, que é o diretório da organização.
- Podem ser importadas dos diretórios locais. Para obter mais informações, consulte Integrar seus diretórios locais com Microsoft Entra ID.
Ao entrar no portal do usuário da sua organização, você usa a URL https://portal.local.azurestack.external. 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 que está fazendo 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.
Usuários convidados
Os usuários convidados são contas de usuário de outros locatários de diretório que receberam acesso aos recursos no seu diretório. Para dar suporte a usuários convidados, use Microsoft Entra ID e habilite o suporte para multilocação. Quando o suporte está habilitado, você pode permitir que os usuários convidados acessem os recursos no seu locatário de diretório, o que, por sua vez, habilita sua colaboração com organizações externas.
Para convidar usuários convidados, operadores de nuvem e usuários podem usar Microsoft Entra colaboração B2B. Os usuários convidados obtê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 do diretório de outra organização. Para fazer isso, você deve acrescentar o nome do diretório da organização à URL do portal. Por exemplo, se você pertencer à organização Contoso e quiser entrar no diretório da Fabrikam, use https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.
Aplicativos
Você pode registrar aplicativos para Microsoft Entra ID ou AD FS e, em seguida, oferecer os aplicativos aos usuários em sua organização.
Os aplicativos incluem:
- Aplicativos Web: os exemplos incluem o portal do Azure e o Azure Resource Manager. Eles dão suporte a chamadas de API Web.
- Cliente nativo: os exemplos incluem a CLI do Azure, do Azure PowerShell e do Visual Studio.
Os aplicativos podem dar suporte a dois tipos de locação:
Locatário único: dá suporte a usuários e serviços somente do mesmo diretório no qual o aplicativo está registrado.
Observação
Como o AD FS dá suporte apenas a um único diretório, os aplicativos que você cria em uma topologia AD FS são, por design, aplicativos de locatário único.
Multilocatário: dá suporte ao uso por usuários e serviços do diretório no qual o aplicativo está registrado e a partir de diretórios de locatário adicionais. Com aplicativos multilocatários, os usuários de outro diretório de locatário (outro Microsoft Entra locatário) 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ários.
Ao registrar um aplicativo, você cria dois objetos:
Objeto de aplicativo: a representação global do aplicativo em todos os locatários. Essa relação é de um-para-um com o aplicativo de software e existe somente no diretório no qual o aplicativo foi registrado primeiro.
Objeto de entidade de serviço: uma credencial que é criada para um aplicativo no diretório no qual o aplicativo foi registrado primeiro. Uma entidade de serviço também é criada no diretório de cada locatário adicional em que o aplicativo é usado. Essa relação pode ser de um-para-muitos com o aplicativo de software.
Para saber mais sobre objetos de aplicativo e entidade de serviço, consulte Objetos de aplicativo e entidade de serviço no Microsoft Entra ID.
Entidades de serviço
Uma entidade de serviço é um conjunto de credenciais para um aplicativo ou serviço que concede acesso aos recursos do 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 em que o aplicativo é usado. A entidade de serviço estabelece uma identidade para entrada e acesso aos 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 ele foi criado pela primeira vez. Essa entidade de serviço é criada e consente em ser usada durante o registro do aplicativo.
- Um aplicativo Web multilocatário ou uma API tem uma entidade de serviço que é criada em cada locatário em que um usuário desse locatário consentiu no uso do aplicativo.
As credenciais para entidades de serviço podem ser uma chave que é gerada por meio da 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.
Observação
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 PEP (ponto de extremidade privilegiado). Para obter mais informações, consulte Usar uma identidade de aplicativo para acessar recursos.
Para saber mais sobre as entidades de serviço do Azure Stack Hub, confira 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 no provedor de identidade. Como os aplicativos, o registro permite que um serviço seja autenticado com o sistema de identidade.
Todos os serviços do Azure usam protocolos OpenID Connect e Tokens Web JSON para estabelecer sua identidade. Como Microsoft Entra ID e O AD FS usam protocolos consistentemente, você pode usar a MSAL (Biblioteca de Autenticação da Microsoft) para obter um token de segurança para autenticar localmente ou no Azure (em um cenário conectado). Com a MSAL, você também pode usar ferramentas como Azure PowerShell e a CLI do Azure para gerenciamento de recursos entre nuvens e locais.
Identidades e seu sistema de identidade
As identidades no 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 são registrados automaticamente no provedor de identidade no locatário do diretório. Alguns serviços registrados são usados 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ê adicionar mais tarde.
Se você configurar 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 tipos diferentes 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, ferramentas e clientes usam um Token Web JSON para fazer uma chamada ao Azure Resource Manager. O Azure Resource Manager valida o Token Web JSON e espia as declarações no token emitido para estimar o nível de autorização que o usuário ou a entidade de serviço tem no Azure Stack Hub. |
| Azure Resource Manager e seus principais serviços | O Azure Resource Manager se comunica com provedores de recursos para transferir a comunicação dos usuários. As transferências usam chamadas imperativas diretas ou chamadas declarativas por meio de modelos de Resource Manager do Azure. |
| Provedores de recursos | As chamadas passadas para os 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 o modo de autenticação de sua escolha. Os provedores de recursos padrão que acompanham 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): a URL pela qual o provedor de identidade pode ser acessado. Por exemplo, https://login.windows.net.
- URI da ID do aplicativo do Azure Resource Manager: o identificador exclusivo do Azure Resource Manager registrado no provedor de identidade. Ele também é exclusivo para cada instalação do Azure Stack Hub.
- Credenciais: a credencial usada para autenticar com o provedor de identidade.
- URL do Azure Resource Manager: a URL é o local do serviço do 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 da entidade de segurança.
- 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 que o URI da ID do aplicativo é para um aplicativo registrado e que 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.
O token deve então enviar o cabeçalho de uma solicitação ao Azure Resource Manager. O Azure Resource Manager faz o seguinte, sem ordem específica:
- Valida a declaração do emissor (iss) para confirmar se 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 que o Token Web JSON está assinado com um certificado configurado por meio do OpenID e é conhecido no Azure Resource Manager.
- Examina as declarações emitidas em (iat) e a expiração (exp) para confirmar se o token está ativo e pode ser aceito.
Quando todas as validações forem concluídas, o Azure Resource Manager usará a ID de objeto (oid) e as declarações de grupos para criar uma lista de recursos que a entidade de segurança pode acessar.
Observação
Após a implantação, Microsoft Entra permissão de Administrador Global não é necessária. No entanto, algumas operações podem exigir as credenciais de administrador global (por exemplo, um script de instalador de provedor de recursos ou um novo recurso que exige uma permissão para ser concedido). Você pode restabelecer temporariamente as permissões de administrador global da conta ou usar uma conta de administrador global separada que seja proprietária da assinatura do provedor padrão.
Usar o controle de acesso baseado em função
Role-Based Controle de Acesso (RBAC) no Azure Stack Hub é consistente com a implementação no Microsoft Azure. Você pode gerenciar o acesso aos 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:
- Comece a usar Role-Based Controle de Acesso no portal do Azure.
- Use Role-Based Controle de Acesso para gerenciar o acesso aos recursos de assinatura do Azure.
- Crie funções personalizadas para Role-Based Controle de Acesso do Azure.
- Gerenciar Role-Based Controle de Acesso no Azure Stack Hub.
Autenticar com o Azure PowerShell
Detalhes sobre como usar Azure PowerShell para autenticar com o Azure Stack Hub podem ser encontrados em Configurar o ambiente do PowerShell do usuário do Azure Stack Hub.
Autenticar com a CLI do Azure
Para obter informações sobre como usar 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
O Azure Policy ajuda a impor padrões organizacionais e a avaliar a conformidade em escala. Por meio do dashboard de conformidade, ele fornece uma exibição agregada para avaliar o estado geral do ambiente, com a capacidade de detalhamento para a granularidade por recurso, por política. Ele também ajuda a deixar seus recursos em conformidade por meio da correção em massa de recursos existentes e da correção automática para novos recursos.
Casos de uso comuns do Azure Policy incluem implementar a governança para consistência de recursos, conformidade regulatória, segurança, custo e gerenciamento. As definições de política para esses casos de uso comuns já estão integradas ao seu ambiente do Azure para ajudá-lo a começar.
Observação
no momento, não há suporte para Azure Policy 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 de 30 de junho de 2023. A Microsoft informou os clientes por email sobre essa alteração. Para obter informações mais detalhadas, consulte o blog Azure AD Desativação do Graph e Substituição do Módulo do PowerShell.
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 funcionando além de 30 de junho de 2023, se necessário, para garantir uma transição tranquila. A ação mais importante é garantir que você esteja em conformidade com a política de manutenção do Azure Stack Hub. Os clientes receberão um alerta no portal de administrador do Azure Stack Hub e precisarão atualizar o diretório base e todos os diretórios convidados integrados.
A maior parte da migração em si será feita pela experiência de atualização integrada do sistema; haverá uma etapa manual exigida pelos clientes para conceder novas permissões a esses aplicativos, o que exigirá permissões de administrador global em cada diretório Microsoft Entra usado com seus ambientes do Azure Stack Hub. Depois que o pacote de atualização com essas alterações terminar de ser instalado, um alerta será gerado no portal de administração orientando você a concluir esta etapa usando a interface do usuário de várias locações ou scripts do PowerShell. Essa é a mesma operação que você executa ao integrar diretórios ou provedores de recursos adicionais; 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 do Graph não afetarão diretamente o sistema. No entanto, as versões mais recentes de ferramentas como a 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 têm suporte explícito com o build do Azure Stack Hub fornecido.
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 atualização do diretório base e de todos os diretórios convidados integrados.