Partilhar via

Descrição geral dos fornecedores de identidade do Azure Stack Hub

  • Artigo

O Azure Stack Hub requer Microsoft Entra ID ou Serviços de Federação do Active Directory (AD FS) (AD FS), apoiado pelo Active Directory como fornecedor de identidade. A escolha de um fornecedor é uma decisão única que toma quando implementa o Azure Stack Hub pela primeira vez. Os conceitos e os detalhes de autorização neste artigo podem ajudá-lo a escolher entre fornecedores de identidade.

A sua escolha de Microsoft Entra ID ou AD FS é determinada pelo modo em que implementa o Azure Stack Hub:

  • Ao implementá-lo num modo ligado, pode utilizar Microsoft Entra ID ou AD FS.
  • Quando o implementa num modo desligado, sem uma ligação à Internet, apenas o AD FS é suportado.

Para obter mais informações sobre as suas opções, que dependem do ambiente do Azure Stack Hub, veja os seguintes artigos:

Importante

Azure AD Graph está a ser preterido e será descontinuado a 30 de junho de 2023. Para obter mais informações, consulte esta secção.

Conceitos comuns para fornecedores de identidade

As secções seguintes abordam conceitos comuns sobre fornecedores de identidade e a sua utilização no Azure Stack Hub.

Terminologia para fornecedores de identidade

Inquilinos e organizações de diretórios

Um diretório é um contentor que contém informações sobre utilizadores, aplicações, grupos e principais de serviço.

Um inquilino de diretório é uma organização, como a Microsoft ou a sua própria empresa.

  • Microsoft Entra ID suporta vários inquilinos e pode suportar várias organizações, cada uma no seu próprio diretório. Se utilizar Microsoft Entra ID e tiver vários inquilinos, pode conceder acesso a aplicações e utilizadores de um inquilino a outros inquilinos desse mesmo diretório.
  • O AD FS suporta apenas um único inquilino e, portanto, apenas uma única organização.

Utilizadores e grupos

As contas de utilizador (identidades) são contas padrão que autenticam indivíduos com um ID de utilizador e palavra-passe. Os grupos podem incluir utilizadores ou outros grupos.

A forma como cria e gere utilizadores e grupos depende da solução de identidade que utiliza.

No Azure Stack Hub, contas de utilizador:

  • São criados no formato username@domain . Embora o AD FS mapeie contas de utilizador para uma instância do Active Directory, o AD FS não suporta a utilização do formato \<domain>\<alias> .
  • Pode ser configurado para utilizar a autenticação multifator.
  • Estão restritos ao diretório onde se registam pela primeira vez, que é o diretório da organização.
  • Pode ser importado dos diretórios no local. Para obter mais informações, veja Integrar os diretórios no local com Microsoft Entra ID.

Quando inicia sessão no portal de utilizador da sua organização, utiliza o https://portal.local.azurestack.external URL. Ao iniciar sessão no portal do Azure Stack Hub a partir de domínios que não o utilizado para registar o Azure Stack Hub, o nome de domínio utilizado para registar o Azure Stack Hub tem de ser acrescentado ao URL do portal. Por exemplo, se o Azure Stack Hub tiver sido registado com fabrikam.onmicrosoft.com e a conta de utilizador a iniciar sessão for admin@contoso.com, o URL a utilizar para iniciar sessão no portal de utilizador será: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Utilizadores convidados

Os utilizadores convidados são contas de utilizador de outros inquilinos de diretórios aos quais foi concedido acesso aos recursos no seu diretório. Para suportar utilizadores convidados, utilize Microsoft Entra ID e ative o suporte para multi-inquilinos. Quando o suporte está ativado, pode convidar utilizadores convidados para acederem a recursos no seu inquilino de diretório, o que, por sua vez, permite a colaboração com organizações externas.

Para convidar utilizadores convidados, os operadores da cloud e os utilizadores podem utilizar Microsoft Entra colaboração B2B. Os utilizadores convidados obtêm acesso a documentos, recursos e aplicações a partir do seu diretório e mantém o controlo sobre os seus próprios recursos e dados.

Como utilizador convidado, pode iniciar sessão no inquilino do diretório de outra organização. Para tal, acrescente o nome do diretório dessa organização ao URL do portal. Por exemplo, se pertencer à organização da Contoso e quiser iniciar sessão no diretório da Fabrikam, utilize https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Aplicações

Pode registar aplicações para Microsoft Entra ID ou AD FS e, em seguida, oferecer as aplicações aos utilizadores na sua organização.

As aplicações incluem:

  • Aplicações Web: os exemplos incluem o portal do Azure e o Azure Resource Manager. Suportam chamadas à API Web.
  • Cliente nativo: os exemplos incluem Azure PowerShell, Visual Studio e CLI do Azure.

As aplicações podem suportar dois tipos de inquilinos:

  • Inquilino único: suporta utilizadores e serviços apenas a partir do mesmo diretório onde a aplicação está registada.

    Nota

    Uma vez que o AD FS suporta apenas um único diretório, as aplicações que cria numa topologia do AD FS são, por predefinição, aplicações de inquilino único.

  • Multi-inquilino: suporta a utilização por utilizadores e serviços do diretório onde a aplicação está registada e por diretórios de inquilinos adicionais. Com aplicações multi-inquilino, os utilizadores de outro diretório de inquilino (outro inquilino Microsoft Entra) podem iniciar sessão na sua aplicação.

    Para obter mais informações sobre multi-inquilinos, veja Ativar multi-inquilinos.

    Para obter mais informações sobre como desenvolver uma aplicação multi-inquilino, veja Aplicações multi-inquilino.

Quando regista uma aplicação, cria dois objetos:

  • Objeto de aplicação: a representação global da aplicação em todos os inquilinos. Esta relação é um-para-um com a aplicação de software e existe apenas no diretório onde a aplicação é registada pela primeira vez.

  • Objeto do principal de serviço: uma credencial criada para uma aplicação no diretório onde a aplicação é registada pela primeira vez. Também é criado um principal de serviço no diretório de cada inquilino adicional onde essa aplicação é utilizada. Esta relação pode ser um-para-muitos com a aplicação de software.

Para saber mais sobre objetos de principal de serviço e de aplicação, veja Objetos de principal de serviço e aplicação no Microsoft Entra ID.

Principais de serviço

Um principal de serviço é um conjunto de credenciais para uma aplicação ou serviço que concede acesso a recursos no Azure Stack Hub. A utilização de um principal de serviço separa as permissões da aplicação das permissões do utilizador da aplicação.

É criado um principal de serviço em cada inquilino onde a aplicação é utilizada. O principal de serviço estabelece uma identidade para início de sessão e acesso a recursos (como utilizadores) que são protegidos por esse inquilino.

  • Uma aplicação de inquilino único tem apenas um principal de serviço, que está no diretório onde é criada pela primeira vez. Este principal de serviço é criado e consente ser utilizado durante o registo da aplicação.
  • Uma aplicação Web ou API multi-inquilino tem um principal de serviço criado em cada inquilino em que um utilizador desse inquilino consente a utilização da aplicação.

As credenciais dos principais de serviço podem ser uma chave gerada através do portal do Azure ou de um certificado. A utilização de um certificado é adequada para automatização porque os certificados são considerados mais seguros do que chaves.

Nota

Quando utiliza o AD FS com o Azure Stack Hub, apenas o administrador pode criar principais de serviço. Com o AD FS, os principais de serviço necessitam de certificados e são criados através do ponto final privilegiado (PEP). Para obter mais informações, veja Utilizar uma identidade de aplicação para aceder aos recursos.

Para saber mais sobre os principais de serviço do Azure Stack Hub, veja Criar principais de serviço.

Serviços

Os serviços no Azure Stack Hub que interagem com o fornecedor de identidade são registados como aplicações com o fornecedor de identidade. Tal como as aplicações, o registo permite que um serviço se autentique com o sistema de identidade.

Todos os serviços do Azure utilizam protocolos OpenID Connect e Tokens Web JSON para estabelecer a respetiva identidade. Uma vez que Microsoft Entra ID e o AD FS utilizam protocolos de forma consistente, pode utilizar a Biblioteca de Autenticação da Microsoft (MSAL) para obter um token de segurança para autenticar no local ou no Azure (num cenário ligado). Com a MSAL, também pode utilizar ferramentas como Azure PowerShell e a CLI do Azure para gestão de recursos entre clouds e no local.

Identidades e o seu sistema de identidade

As identidades do Azure Stack Hub incluem contas de utilizador, grupos e principais de serviço.

Quando instala o Azure Stack Hub, várias aplicações e serviços incorporados registam-se automaticamente no seu fornecedor de identidade no inquilino do diretório. Alguns serviços registados são utilizados para administração. Estão disponíveis outros serviços para os utilizadores. Os registos predefinidos fornecem identidades de serviços principais que podem interagir entre si e com identidades que adicionar mais tarde.

Se configurar Microsoft Entra ID com vários inquilinos, algumas aplicações são propagadas para os novos diretórios.

Autenticação e autorização

Autenticação por aplicações e utilizadores

Identidade entre camadas do Azure Stack Hub

Para aplicações e utilizadores, a arquitetura do Azure Stack Hub é descrita por quatro camadas. As interações entre cada uma destas camadas podem utilizar diferentes tipos de autenticação.

Camada Autenticação entre camadas
Ferramentas e clientes, como o portal de administrador Para aceder ou modificar um recurso no Azure Stack Hub, as ferramentas e os clientes utilizam um Token Web JSON para efetuar uma chamada para o Azure Resource Manager.
O Azure Resource Manager valida o Token Web JSON e pré-visualiza as afirmações no token emitido para estimar o nível de autorização que o utilizador ou o principal de serviço tem no Azure Stack Hub.
Azure Resource Manager e os seus principais serviços O Azure Resource Manager comunica com os fornecedores de recursos para transferir a comunicação dos utilizadores.
As transferências utilizam chamadas imperativas diretas ou chamadas declarativasatravés de modelos de Resource Manager do Azure.
Fornecedores de recursos As chamadas transmitidas aos fornecedores de recursos são protegidas com autenticação baseada em certificados.
O Azure Resource Manager e o fornecedor de recursos permanecem em comunicação através de uma API. Para cada chamada recebida do Azure Resource Manager, o fornecedor de recursos valida a chamada com esse certificado.
Lógica de infraestrutura e negócio Os fornecedores de recursos comunicam com a lógica de negócio e a infraestrutura através de um modo de autenticação à sua escolha. Os fornecedores de recursos predefinidos que são enviados com o Azure Stack Hub utilizam a Autenticação do Windows para proteger esta comunicação.

Informações necessárias para a autenticação

Autenticar no Azure Resource Manager

Para autenticar com o fornecedor de identidade e receber um Token Web JSON, tem de ter as seguintes informações:

  1. URL do sistema de identidade (Autoridade): o URL no qual o seu fornecedor de identidade pode ser alcançado. Por exemplo, https://login.windows.net.
  2. URI do ID da Aplicação para o Azure Resource Manager: o identificador exclusivo do Azure Resource Manager que está registado no seu fornecedor de identidade. Também é exclusivo de cada instalação do Azure Stack Hub.
  3. Credenciais: a credencial que utiliza para autenticar com o fornecedor de identidade.
  4. URL do Azure Resource Manager: o URL é a localização do serviço Resource Manager do Azure. Por exemplo, https://management.azure.com ou https://management.local.azurestack.external.

Quando um principal (um cliente, aplicações ou utilizador) faz um pedido de autenticação para aceder a um recurso, o pedido tem de incluir:

  • As credenciais do principal.
  • O URI do ID da aplicação do recurso ao qual o principal quer aceder.

As credenciais são validadas pelo fornecedor de identidade. O fornecedor de identidade também valida que o URI de ID da aplicação é para uma aplicação registada e que o principal tem os privilégios corretos para obter um token para esse recurso. Se o pedido for válido, é concedido um Token Web JSON.

Em seguida, o token tem de passar no cabeçalho de um pedido para o Azure Resource Manager. O Azure Resource Manager faz o seguinte, sem nenhuma ordem específica:

  • Valida a afirmação do emissor (iss) para confirmar que o token é do fornecedor de identidade correto.
  • Valida a afirmaçã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 através do OpenID e conhecido pelo Azure Resource Manager.
  • Reveja as afirmações emitidas em (iat) e expiração (exp) para confirmar que o token está ativo e pode ser aceite.

Quando todas as validações estiverem concluídas, o Azure Resource Manager utiliza o ID do objeto (oid) e os grupos afirmam criar uma lista de recursos aos quais o principal pode aceder.

Diagrama do protocolo de troca de tokens

Nota

Após a implementação, não é necessária Microsoft Entra permissão de Administrador Global. No entanto, algumas operações podem exigir as credenciais de administrador global (por exemplo, um script do instalador do fornecedor de recursos ou uma nova funcionalidade que exija a concessão de uma permissão). Pode voltar a indicar temporariamente as permissões de administrador global da conta ou utilizar uma conta de administrador global separada que seja um proprietário da subscrição de fornecedor predefinida.

Utilizar Role-Based Controlo de Acesso

Role-Based Controlo de Acesso (RBAC) no Azure Stack Hub é consistente com a implementação no Microsoft Azure. Pode gerir o acesso aos recursos ao atribuir a função RBAC adequada aos utilizadores, grupos e aplicações. Para obter informações sobre como utilizar o RBAC com o Azure Stack Hub, veja os seguintes artigos:

Autenticar com o Azure PowerShell

Os detalhes sobre como utilizar Azure PowerShell para autenticar com o Azure Stack Hub podem ser encontrados em Configurar o ambiente do PowerShell do utilizador do Azure Stack Hub.

Autenticar com a CLI do Azure

Para obter informações sobre como utilizar Azure PowerShell para autenticar com o Azure Stack Hub, veja Instalar e configurar a CLI do Azure para utilização com o Azure Stack Hub.

Azure Policy

Azure Policy ajuda a impor normas organizacionais e a avaliar a conformidade em escala. Através do dashboard de conformidade, fornece uma vista agregada para avaliar o estado geral do ambiente, com a capacidade de desagregar para a granularidade por recurso, 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 estes casos de utilização comuns já estão incorporadas no seu ambiente do Azure para o ajudar a começar.

Nota

Azure Policy não é atualmente suportado no Azure Stack Hub.

Azure AD Graph

O Microsoft Azure anunciou a descontinuação do Azure AD Graph a 30 de junho de 2020 e a data de descontinuação de 30 de junho de 2023. A Microsoft informou os clientes por e-mail sobre esta alteração. Para obter informações mais detalhadas, veja o blogue Azure AD Graph Retirement and Powershell Module Deprecation (Descontinuação do Módulo do PowerShell) Azure AD.

A secção seguinte descreve como esta preterição afeta o Azure Stack Hub.

A equipa do Azure Stack Hub está a trabalhar em estreita colaboração com a equipa do Azure Graph para garantir que os seus sistemas continuam a funcionar para além de 30 de junho de 2023, se necessário, para garantir uma transição suave. A ação mais importante é garantir que está 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 terão de atualizar o diretório principal e todos os diretórios convidados integrados.

A maior parte da migração em si será feita pela experiência integrada de atualização do sistema; haverá um passo manual exigido pelos clientes para conceder novas permissões a essas aplicações, que exigirão permissões de administrador global em cada Microsoft Entra diretório utilizado com os seus ambientes do Azure Stack Hub. Após a instalação do pacote de atualização com estas alterações, é gerado um alerta no portal de administração a direcioná-lo para concluir este passo com a IU multi-inquilino ou scripts do PowerShell. Esta é a mesma operação que executa ao integrar diretórios ou fornecedores de recursos adicionais; Para obter mais informações, veja Configurar o multi-inquilino no Azure Stack Hub.

Se utilizar o AD FS como o seu sistema de identidade com o Azure Stack Hub, estas alterações ao Graph não afetarão diretamente o seu sistema. No entanto, as versões mais recentes de ferramentas como a CLI do Azure, Azure PowerShell, etc., requerem as novas APIs do Graph e não funcionarão. Certifique-se de que utiliza apenas as versões destas ferramentas que são explicitamente suportadas com a compilação do Azure Stack Hub.

Além do alerta no portal de administração, comunicaremos as alterações através das notas de versão de atualização e comunicaremos qual o pacote de atualização que requer a atualização do diretório principal e todos os diretórios convidados integrados.

Passos seguintes