Az - Informações Básicas

Reading time: 23 minutes

Hierarquia da Organização

Grupos de Gerenciamento

• Pode conter outros grupos de gerenciamento ou assinaturas.
• Isso permite aplicar controles de governança como RBAC e Azure Policy uma vez no nível do grupo de gerenciamento e tê-los herdados por todas as assinaturas no grupo.
• 10.000 grupos de gerenciamento podem ser suportados em um único diretório.
• Uma árvore de grupos de gerenciamento pode suportar até seis níveis de profundidade. Este limite não inclui o nível raiz ou o nível de assinatura.
• Cada grupo de gerenciamento e assinatura pode suportar apenas um pai.
• Mesmo que vários grupos de gerenciamento possam ser criados, existe apenas 1 grupo de gerenciamento raiz.
• O grupo de gerenciamento raiz contém todos os outros grupos de gerenciamento e assinaturas e não pode ser movido ou excluído.
• Todas as assinaturas dentro de um único grupo de gerenciamento devem confiar no mesmo inquilino do Entra ID.

Assinaturas do Azure

• É outro container lógico onde recursos (VMs, DBs…) podem ser executados e serão cobrados.
• Seu pai é sempre um grupo de gerenciamento (e pode ser o grupo de gerenciamento raiz), pois assinaturas não podem conter outras assinaturas.
• Confia apenas em um diretório do Entra ID
• Permissões aplicadas no nível da assinatura (ou em qualquer um de seus pais) são herdadas para todos os recursos dentro da assinatura.

Grupos de Recursos

Dos docs: Um grupo de recursos é um container que contém recursos relacionados para uma solução do Azure. O grupo de recursos pode incluir todos os recursos para a solução ou apenas aqueles recursos que você deseja gerenciar como um grupo. Geralmente, adicione recursos que compartilham o mesmo ciclo de vida ao mesmo grupo de recursos para que você possa facilmente implantar, atualizar e excluí-los como um grupo.

Todos os recursos devem estar dentro de um grupo de recursos e podem pertencer apenas a um grupo e, se um grupo de recursos for excluído, todos os recursos dentro dele também são excluídos.

IDs de Recursos do Azure

Cada recurso no Azure tem um ID de Recurso do Azure que o identifica.

O formato de um ID de Recurso do Azure é o seguinte:

• /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

Para uma máquina virtual chamada myVM em um grupo de recursos myResourceGroup sob o ID da assinatura 12345678-1234-1234-1234-123456789012, o ID de Recurso do Azure se parece com isto:

• /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Serviços de Domínio do Azure AD

Azure

Azure é a plataforma de computação em nuvem abrangente da Microsoft, oferecendo uma ampla gama de serviços, incluindo máquinas virtuais, bancos de dados, inteligência artificial e armazenamento. Ele atua como a base para hospedar e gerenciar aplicativos, construir infraestruturas escaláveis e executar cargas de trabalho modernas na nuvem. O Azure fornece ferramentas para desenvolvedores e profissionais de TI criarem, implantarem e gerenciarem aplicativos e serviços de forma contínua, atendendo a uma variedade de necessidades, desde startups até grandes empresas.

Entra ID (anteriormente Azure Active Directory)

Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem projetado para lidar com autenticação, autorização e controle de acesso do usuário. Ele fornece acesso seguro a serviços da Microsoft, como Office 365, Azure e muitos aplicativos SaaS de terceiros. Com recursos como autenticação única (SSO), autenticação multifator (MFA) e políticas de acesso condicional, entre outros.

Serviços de Domínio do Entra (anteriormente Azure AD DS)

Os Serviços de Domínio do Entra estendem as capacidades do Entra ID, oferecendo serviços de domínio gerenciados compatíveis com ambientes tradicionais do Windows Active Directory. Ele suporta protocolos legados como LDAP, Kerberos e NTLM, permitindo que as organizações migrem ou executem aplicativos mais antigos na nuvem sem implantar controladores de domínio locais. Este serviço também suporta a Política de Grupo para gerenciamento centralizado, tornando-o adequado para cenários onde cargas de trabalho legadas ou baseadas em AD precisam coexistir com ambientes modernos de nuvem.

Principais do Entra ID

Usuários

• Novos usuários
• Indicar nome de e-mail e domínio do inquilino selecionado
• Indicar nome de exibição
• Indicar senha
• Indicar propriedades (primeiro nome, cargo, informações de contato…)
• O tipo de usuário padrão é “membro”
• Usuários externos
• Indicar e-mail para convidar e nome de exibição (pode ser um e-mail não Microsoft)
• Indicar propriedades
• O tipo de usuário padrão é “Convidado”

Permissões Padrão de Membros e Convidados

Você pode verificá-las em https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions, mas entre outras ações, um membro poderá:

• Ler todos os usuários, Grupos, Aplicações, Dispositivos, Funções, Assinaturas e suas propriedades públicas
• Convidar Convidados (pode ser desativado)
• Criar grupos de segurança
• Ler associações de grupos não ocultos
• Adicionar convidados a grupos de propriedade
• Criar nova aplicação (pode ser desativado)
• Adicionar até 50 dispositivos ao Azure (pode ser desativado)

Permissões Configuráveis Padrão de Usuários

• Membros (docs)
• Registrar Aplicações: Padrão Sim
• Restringir usuários não administradores de criar inquilinos: Padrão Não
• Criar grupos de segurança: Padrão Sim
• Restringir acesso ao portal de administração do Microsoft Entra: Padrão Não
• Isso não restringe o acesso à API do portal (apenas web)
• Permitir que os usuários conectem contas de trabalho ou escolares com o LinkedIn: Padrão Sim
• Manter o usuário conectado: Padrão Sim
• Restringir usuários de recuperar a(s) chave(s) do BitLocker para seus dispositivos de propriedade: Padrão Não (verifique nas Configurações do Dispositivo)
• Ler outros usuários: Padrão Sim (via Microsoft Graph)
• Convidados
• Restrições de acesso de usuários convidados opções:
• Usuários convidados têm o mesmo acesso que membros.
• Usuários convidados têm acesso limitado a propriedades e associações de objetos de diretório (padrão). Isso restringe o acesso do convidado apenas ao seu próprio perfil de usuário por padrão. O acesso a informações de outros usuários e grupos não é mais permitido.
• O acesso de usuários convidados é restrito a propriedades e associações de seus próprios objetos de diretório é o mais restritivo.
• Opções de convite para convidados:
• Qualquer pessoa na organização pode convidar usuários convidados, incluindo convidados e não administradores (mais inclusivo) - Padrão
• Usuários membros e usuários atribuídos a funções administrativas específicas podem convidar usuários convidados, incluindo convidados com permissões de membro
• Apenas usuários atribuídos a funções administrativas específicas podem convidar usuários convidados
• Ninguém na organização pode convidar usuários convidados, incluindo administradores (mais restritivo)
• Saída de usuário externo: Padrão Verdadeiro
• Permitir que usuários externos deixem a organização

Grupos

Existem 2 tipos de grupos:

• Segurança: Este tipo de grupo é usado para dar acesso a membros a aplicações, recursos e atribuir licenças. Usuários, dispositivos, principais de serviço e outros grupos podem ser membros.
• Microsoft 365: Este tipo de grupo é usado para colaboração, dando acesso a uma caixa de correio compartilhada, calendário, arquivos, site do SharePoint, e assim por diante. Os membros do grupo podem ser apenas usuários.
• Isso terá um endereço de e-mail com o domínio do inquilino do EntraID.

Existem 2 tipos de associações:

• Atribuído: Permite adicionar manualmente membros específicos a um grupo.
• Associação dinâmica: Gerencia automaticamente a associação usando regras, atualizando a inclusão do grupo quando os atributos dos membros mudam.

Principais de Serviço

Um Principal de Serviço é uma identidade criada para uso com aplicações, serviços hospedados e ferramentas automatizadas para acessar recursos do Azure. Esse acesso é restrito pelos papéis atribuídos ao principal de serviço, dando controle sobre quais recursos podem ser acessados e em qual nível. Por razões de segurança, é sempre recomendado usar principais de serviço com ferramentas automatizadas em vez de permitir que eles façam login com uma identidade de usuário.

É possível fazer login diretamente como um principal de serviço gerando um segredo (senha), um certificado ou concedendo acesso federado a plataformas de terceiros (por exemplo, Github Actions) sobre ele.

• Se você escolher a autenticação por senha (por padrão), salve a senha gerada, pois você não poderá acessá-la novamente.
• Se você escolher a autenticação por certificado, certifique-se de que a aplicação terá acesso à chave privada.

Registros de Aplicativos

Um Registro de Aplicativo é uma configuração que permite que uma aplicação se integre ao Entra ID e realize ações.

Componentes Chave:

1. ID da Aplicação (Client ID): Um identificador único para seu aplicativo no Azure AD.
2. URIs de Redirecionamento: URLs onde o Azure AD envia respostas de autenticação.
3. Certificados, Segredos e Credenciais Federadas: É possível gerar um segredo ou um certificado para fazer login como o principal de serviço da aplicação ou conceder acesso federado a ele (por exemplo, Github Actions).
4. Se um certificado ou segredo for gerado, é possível que uma pessoa faça login como o principal de serviço com ferramentas CLI conhecendo o ID da aplicação, o segredo ou certificado e o inquilino (domínio ou ID).
5. Permissões da API: Especifica quais recursos ou APIs o aplicativo pode acessar.
6. Configurações de Autenticação: Define os fluxos de autenticação suportados pelo aplicativo (por exemplo, OAuth2, OpenID Connect).
7. Principal de Serviço: Um principal de serviço é criado quando um aplicativo é criado (se for feito a partir do console da web) ou quando é instalado em um novo inquilino.
8. O principal de serviço receberá todas as permissões solicitadas com as quais foi configurado.

Permissões de Consentimento Padrão

Consentimento do usuário para aplicativos

• Não permitir consentimento do usuário
• Um administrador será necessário para todos os aplicativos.
• Permitir consentimento do usuário para aplicativos de editores verificados, aplicativos internos e aplicativos que solicitam apenas permissões selecionadas (Recomendado)
• Todos os usuários podem consentir aplicativos que solicitam apenas permissões classificadas como "baixo impacto", aplicativos de editores verificados e aplicativos registrados no inquilino.
• Permissões de baixo impacto padrão (embora você precise aceitar para adicioná-las como baixo):
• User.Read - fazer login e ler o perfil do usuário
• offline_access - manter acesso a dados que os usuários deram acesso
• openid - fazer login dos usuários
• profile - ver o perfil básico do usuário
• email - ver o endereço de e-mail do usuário
• Permitir consentimento do usuário para aplicativos (Padrão)
• Todos os usuários podem consentir para qualquer aplicativo acessar os dados da organização.

Solicitações de consentimento do administrador: Padrão Não

• Os usuários podem solicitar consentimento do administrador para aplicativos aos quais não conseguem consentir
• Se Sim: É possível indicar Usuários, Grupos e Funções que podem consentir solicitações
• Configure também se os usuários receberão notificações por e-mail e lembretes de expiração

Identidade Gerenciada (Metadados)

Identidades gerenciadas no Azure Active Directory oferecem uma solução para gerenciar automaticamente a identidade de aplicativos. Essas identidades são usadas por aplicativos para o propósito de conectar-se a recursos compatíveis com autenticação do Azure Active Directory (Azure AD). Isso permite remover a necessidade de codificar credenciais de nuvem no código, pois o aplicativo poderá contatar o serviço de metadados para obter um token válido para realizar ações como a identidade gerenciada indicada no Azure.

Existem dois tipos de identidades gerenciadas:

• Atribuída pelo sistema. Alguns serviços do Azure permitem que você ative uma identidade gerenciada diretamente em uma instância de serviço. Quando você ativa uma identidade gerenciada atribuída pelo sistema, um principal de serviço é criado no inquilino do Entra ID confiável pela assinatura onde o recurso está localizado. Quando o recurso é excluído, o Azure automaticamente exclui a identidade para você.
• Atribuída pelo usuário. Também é possível que os usuários gerem identidades gerenciadas. Essas são criadas dentro de um grupo de recursos dentro de uma assinatura e um principal de serviço será criado no EntraID confiável pela assinatura. Em seguida, você pode atribuir a identidade gerenciada a uma ou mais instâncias de um serviço do Azure (múltiplos recursos). Para identidades gerenciadas atribuídas pelo usuário, a identidade é gerenciada separadamente dos recursos que a utilizam.

Identidades Gerenciadas não geram credenciais eternas (como senhas ou certificados) para acessar como o principal de serviço anexado a ela.

Aplicações Empresariais

É apenas uma tabela no Azure para filtrar principais de serviço e verificar as aplicações que foram atribuídas a.

Não é outro tipo de “aplicação”, não há nenhum objeto no Azure que seja uma “Aplicação Empresarial”, é apenas uma abstração para verificar os Principais de Serviço, Registros de Aplicativos e Identidades Gerenciadas.

Unidades Administrativas

Unidades administrativas permitem dar permissões de um papel sobre uma parte específica de uma organização.

Exemplo:

• Cenário: Uma empresa deseja que administradores de TI regionais gerenciem apenas os usuários em sua própria região.
• Implementação:
• Criar Unidades Administrativas para cada região (por exemplo, "AU América do Norte", "AU Europa").
• Preencher AUs com usuários de suas respectivas regiões.
• AUs podem conter usuários, grupos ou dispositivos
• AUs suportam associações dinâmicas
• AUs não podem conter AUs
• Atribuir Funções Administrativas:
• Conceder o papel de "Administrador de Usuários" ao pessoal de TI regional, limitado à AU de sua região.
• Resultado: Administradores de TI regionais podem gerenciar contas de usuário dentro de sua região sem afetar outras regiões.

Funções e Permissões do Entra ID

• Para gerenciar o Entra ID, existem algumas funções integradas que podem ser atribuídas a principais do Entra ID para gerenciar o Entra ID
• Verifique as funções em https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference
• Funções marcadas como PRIVILEGIADAS pelo EntraID devem ser atribuídas com cautela, pois como a Microsoft explica na documentação: Atribuições de função privilegiadas podem levar a elevação de privilégios se não forem usadas de maneira segura e intencional.
• A função mais privilegiada é Administrador Global
• As funções agrupam permissões granulares e podem ser encontradas em suas descrições.
• É possível criar funções personalizadas com as permissões desejadas. Embora, por algum motivo, nem todas as permissões granulares estejam disponíveis para os administradores criarem funções personalizadas.
• As funções no Entra ID são completamente independentes das funções no Azure. A única relação é que os principais com a função Administrador Global no Entra ID podem elevar para a função Administrador de Acesso do Usuário no Azure.
• Não é possível usar curingas nas funções do Entra ID.

Funções e Permissões do Azure

• Funções são atribuídas a principais em um escopo: principal -[HAS ROLE]->(scope)
• Funções atribuídas a grupos são herdadas por todos os membros do grupo.
• Dependendo do escopo ao qual a função foi atribuída, a função pode ser herdada para outros recursos dentro do contêiner de escopo. Por exemplo, se um usuário A tem uma função na assinatura, ele terá essa função em todos os grupos de recursos dentro da assinatura e em todos os recursos dentro do grupo de recursos.

Funções Integradas

Dos docs: O controle de acesso baseado em função do Azure (Azure RBAC) tem várias funções integradas do Azure que você pode atribuir a usuários, grupos, principais de serviço e identidades gerenciadas. As atribuições de função são a maneira de controlar o acesso aos recursos do Azure. Se as funções integradas não atenderem às necessidades específicas de sua organização, você pode criar suas próprias funções personalizadas do Azure.

As funções integradas se aplicam apenas aos recursos para os quais são destinadas, por exemplo, verifique estes 2 exemplos de funções integradas sobre recursos de Computação:

Essas funções também podem ser atribuídas sobre contêineres lógicos (como grupos de gerenciamento, assinaturas e grupos de recursos) e os principais afetados as terão sobre os recursos dentro desses contêineres.

• Encontre aqui uma lista com todas as funções integradas do Azure.
• Encontre aqui uma lista com todas as funções integradas do Entra ID.

Funções Personalizadas

• Também é possível criar funções personalizadas
• Elas são criadas dentro de um escopo, embora uma função possa estar em vários escopos (grupos de gerenciamento, assinaturas e grupos de recursos)
• É possível configurar todas as permissões granulares que a função personalizada terá
• É possível excluir permissões
• Um principal com uma permissão excluída não poderá usá-la, mesmo que a permissão esteja sendo concedida em outro lugar
• É possível usar curingas
• O formato utilizado é um JSON
• actions refere-se a permissões para operações de gerenciamento em recursos, como criar, atualizar ou excluir definições e configurações de recursos.
• dataActions são permissões para operações de dados dentro do recurso, permitindo que você leia, escreva ou exclua os dados reais contidos no recurso.
• notActions e notDataActions são usados para excluir permissões específicas da função. No entanto, elas não as negam, se uma função diferente as conceder, o principal as terá.
• assignableScopes é um array de escopos onde a função pode ser atribuída (como grupos de gerenciamento, assinaturas ou grupos de recursos).

Exemplo de JSON de permissões para uma função personalizada:

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

Ordem de Permissões

• Para que um principal tenha algum acesso a um recurso, ele precisa de um papel explícito sendo concedido a ele (de qualquer forma) concedendo-lhe essa permissão.
• Uma atribuição de negação explícita tem precedência sobre o papel que concede a permissão.

Administrador Global

O Administrador Global é um papel do Entra ID que concede controle total sobre o locatário do Entra ID. No entanto, ele não concede nenhuma permissão sobre recursos do Azure por padrão.

Usuários com o papel de Administrador Global têm a capacidade de 'elevar' para o papel de Administrador de Acesso do Usuário no Grupo de Gerenciamento Raiz. Assim, Administradores Globais podem gerenciar o acesso em todas as assinaturas e grupos de gerenciamento do Azure.
Essa elevação pode ser feita no final da página: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Condições de Atribuições & MFA

De acordo com a documentação: Atualmente, condições podem ser adicionadas a atribuições de papéis integrados ou personalizados que tenham ações de dados de armazenamento de blob ou ações de dados de armazenamento de fila.

Atribuições de Negação

Assim como as atribuições de papéis, atribuições de negação são usadas para controlar o acesso a recursos do Azure. No entanto, atribuições de negação são usadas para negar explicitamente o acesso a um recurso, mesmo que um usuário tenha recebido acesso por meio de uma atribuição de papel. Atribuições de negação têm precedência sobre atribuições de papel, o que significa que se um usuário receber acesso por meio de uma atribuição de papel, mas também for explicitamente negado acesso por meio de uma atribuição de negação, a atribuição de negação terá precedência.

Assim como as atribuições de papel, atribuições de negação são aplicadas sobre algum escopo indicando os principais afetados e as permissões que estão sendo negadas. Além disso, no caso de atribuições de negação, é possível impedir que a negação seja herdada por recursos filhos.

Políticas do Azure

Políticas do Azure são regras que ajudam as organizações a garantir que seus recursos atendam a padrões e requisitos de conformidade específicos. Elas permitem que você aplique ou audite configurações em recursos no Azure. Por exemplo, você pode impedir a criação de máquinas virtuais em uma região não autorizada ou garantir que todos os recursos tenham tags específicas para rastreamento.

As Políticas do Azure são proativas: elas podem impedir que recursos não conformes sejam criados ou alterados. Elas também são reativas, permitindo que você encontre e corrija recursos não conformes existentes.

Conceitos Chave

1. Definição de Política: Uma regra, escrita em JSON, que especifica o que é permitido ou exigido.
2. Atribuição de Política: A aplicação de uma política a um escopo específico (por exemplo, assinatura, grupo de recursos).
3. Iniciativas: Uma coleção de políticas agrupadas para uma aplicação mais ampla.
4. Efeito: Especifica o que acontece quando a política é acionada (por exemplo, "Negar", "Auditar" ou "Anexar").

Alguns exemplos:

1. Garantindo Conformidade com Regiões Específicas do Azure: Esta política garante que todos os recursos sejam implantados em regiões específicas do Azure. Por exemplo, uma empresa pode querer garantir que todos os seus dados sejam armazenados na Europa para conformidade com o GDPR.
2. Impondo Padrões de Nomenclatura: Políticas podem impor convenções de nomenclatura para recursos do Azure. Isso ajuda na organização e identificação fácil de recursos com base em seus nomes, o que é útil em grandes ambientes.
3. Restringindo Certos Tipos de Recursos: Esta política pode restringir a criação de certos tipos de recursos. Por exemplo, uma política pode ser definida para impedir a criação de tipos de recursos caros, como certos tamanhos de VM, para controlar custos.
4. Impondo Políticas de Tagging: Tags são pares chave-valor associados a recursos do Azure usados para gerenciamento de recursos. Políticas podem impor que certas tags devem estar presentes ou ter valores específicos para todos os recursos. Isso é útil para rastreamento de custos, propriedade ou categorização de recursos.
5. Limitando Acesso Público a Recursos: Políticas podem impor que certos recursos, como contas de armazenamento ou bancos de dados, não tenham endpoints públicos, garantindo que sejam acessíveis apenas dentro da rede da organização.
6. Aplicando Configurações de Segurança Automaticamente: Políticas podem ser usadas para aplicar automaticamente configurações de segurança a recursos, como aplicar um grupo de segurança de rede específico a todas as VMs ou garantir que todas as contas de armazenamento usem criptografia.

Observe que as Políticas do Azure podem ser anexadas a qualquer nível da hierarquia do Azure, mas são comumente usadas no grupo de gerenciamento raiz ou em outros grupos de gerenciamento.

Exemplo de política do Azure em json:

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}

Herança de Permissões

No Azure, as permissões podem ser atribuídas a qualquer parte da hierarquia. Isso inclui grupos de gerenciamento, assinaturas, grupos de recursos e recursos individuais. As permissões são herdadas pelos recursos contidos na entidade onde foram atribuídas.

Essa estrutura hierárquica permite uma gestão eficiente e escalável das permissões de acesso.

Azure RBAC vs ABAC

RBAC (controle de acesso baseado em função) é o que já vimos nas seções anteriores: Atribuir uma função a um principal para conceder acesso a um recurso.
No entanto, em alguns casos, você pode querer fornecer uma gestão de acesso mais detalhada ou simplificar a gestão de centenas de atribuições de função.

O ABAC do Azure (controle de acesso baseado em atributos) se baseia no Azure RBAC, adicionando condições de atribuição de função baseadas em atributos no contexto de ações específicas. Uma condição de atribuição de função é uma verificação adicional que você pode opcionalmente adicionar à sua atribuição de função para fornecer um controle de acesso mais detalhado. Uma condição filtra as permissões concedidas como parte da definição de função e da atribuição de função. Por exemplo, você pode adicionar uma condição que exige que um objeto tenha uma tag específica para ler o objeto.
Você não pode explicitamente negar acesso a recursos específicos usando condições.

Referências

• https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions
• https://abouttmc.com/glossary/azure-subscription/#:~:text=An%20Azure%20subscription%20is%20a,the%20subscription%20it%20belongs%20to.
• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-azure-rbac-determines-if-a-user-has-access-to-a-resource
• https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration