Az - Basic Information
Hierarquia da Organização
Grupos de Gerenciamento
Se sua organização possui muitas assinaturas do Azure, pode ser necessário uma maneira de gerenciar eficientemente o acesso, políticas e conformidade para essas assinaturas. Os grupos de gerenciamento fornecem um escopo de governança acima das assinaturas.
Observe que 10.000 grupos de gerenciamento podem ser suportados em um único diretório e uma árvore de grupos de gerenciamento pode suportar até seis níveis de profundidade.
Da documentação: Cada diretório recebe um único grupo de gerenciamento de nível superior chamado de raiz. O grupo de gerenciamento raiz é integrado à hierarquia para ter todos os grupos de gerenciamento e assinaturas vinculados a ele. Esse grupo de gerenciamento raiz permite a aplicação de políticas globais e atribuições de funções do Azure no nível do diretório. O Administrador Global do Azure AD precisa elevar suas permissões para a função de Administrador de Acesso do Usuário deste grupo raiz inicialmente. Após elevar o acesso, o administrador pode atribuir qualquer função do Azure a outros usuários ou grupos do diretório para gerenciar a hierarquia. Como administrador, você pode atribuir sua própria conta como proprietária da raiz do grupo de gerenciamento.
O grupo de gerenciamento raiz não pode ser movido ou excluído, ao contrário de outros grupos de gerenciamento.
Os grupos de gerenciamento oferecem gerenciamento de nível empresarial em escala, independentemente do tipo de assinaturas que você possa ter. No entanto, todas as assinaturas dentro de um único grupo de gerenciamento devem confiar no mesmo locatário do Azure Active Directory (Azure AD).
Assinaturas do Azure
No Azure, uma assinatura serve como um contêiner lógico para o propósito de provisionamento de recursos comerciais ou técnicos. Este contêiner mantém os detalhes dos recursos como máquinas virtuais (VMs), bancos de dados, entre outros. Após a criação de um recurso do Azure, como uma VM, a assinatura associada a ele é especificada. Essa estrutura facilita a delegação de acesso, utilizando mecanismos de controle de acesso baseados em funções.
Grupos de Recursos
Da documentação: Um grupo de recursos é um contêiner que mantém recursos relacionados para uma solução do Azure. O grupo de recursos pode incluir todos os recursos da 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 implantá-los, atualizá-los e excluí-los facilmente 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 serão excluídos.
Unidades Administrativas
Da documentação: As unidades administrativas permitem que você divida sua organização em qualquer unidade que desejar e, em seguida, atribua administradores específicos que podem gerenciar apenas os membros dessa unidade. Por exemplo, você poderia usar unidades administrativas para delegar permissões aos administradores de cada escola em uma grande universidade, para que eles possam controlar o acesso, gerenciar usuários e definir políticas apenas na Escola de Engenharia.
Apenas usuários, grupos e dispositivos podem ser membros de uma unidade administrativa.
Portanto, uma unidade administrativa conterá alguns membros e outros principais terão permissões atribuídas sobre aquela unidade administrativa que eles podem usar para gerenciar os membros da unidade administrativa.
Azure vs Azure AD vs Azure AD Domain Services
É importante notar que o Azure AD é um serviço dentro do Azure. O Azure é a plataforma de nuvem da Microsoft, enquanto o Azure AD é um serviço de identidade empresarial no Azure. Além disso, o Azure AD não é como o Active Directory do Windows, é um serviço de identidade que funciona de maneira completamente diferente. Se você deseja executar um Controlador de Domínio no Azure para seu ambiente do Active Directory do Windows, você precisa usar Azure AD Domain Services.
Princípios
O Azure suporta diferentes tipos de princípios:
Usuário: Uma pessoa com credenciais para acessar.
Grupo: Um grupo de princípios gerenciados juntos. As permissões concedidas aos grupos são herdadas por seus membros.
Principal de Serviço/Aplicações Corporativas: É uma identidade criada para uso com aplicativos, serviços hospedados e ferramentas automatizadas para acessar recursos do Azure. Este acesso é restrito pelos papéis atribuídos ao principal de serviço, dando a você controle sobre quais recursos podem ser acessados e em qual nível. Por motivos de segurança, é sempre recomendado usar princípios de serviço com ferramentas automatizadas em vez de permitir que eles façam login com uma identidade de usuário.
Ao criar um principal de serviço você pode escolher entre autenticação por senha ou autenticação por certificado.
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.
Identidade Gerenciada (Credenciais de Metadados): As identidades gerenciadas no Azure Active Directory oferecem uma solução para gerenciar automaticamente a identidade de aplicativos. Essas identidades são usadas por aplicativos com o objetivo de conectar-se a recursos compatíveis com a autenticação do Azure Active Directory (Azure AD). Ao utilizar identidades gerenciadas, os aplicativos podem proteger tokens do Azure AD eliminando a necessidade de lidar diretamente com credenciais. 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, uma identidade é criada no Azure AD. A identidade está vinculada ao ciclo de vida daquela instância de serviço. Quando o recurso é excluído, o Azure exclui automaticamente a identidade para você. Por design, apenas esse recurso do Azure pode usar essa identidade para solicitar tokens do Azure AD.
Atribuída pelo Usuário. Você também pode criar uma identidade gerenciada como um recurso independente do Azure. Você pode criar uma identidade gerenciada atribuída pelo usuário e atribuí-la 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.
Funções e Permissões
Funções são atribuídas a principais em um escopo: principal -[TEM FUNÇÃO]->(escopo)
As 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 por 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 Clássicas
Proprietário |
| Todos os tipos de recursos |
Contribuinte |
| Todos os tipos de recursos |
Leitor | • Visualizar todos os recursos | Todos os tipos de recursos |
Administrador de Acesso do Usuário |
| Todos os tipos de recursos |
Funções Integradas
A partir da documentação: Controle de Acesso Baseado em Função do Azure (Azure RBAC) possui várias funções integradas do Azure que você pode atribuir a usuários, grupos, princípios de serviço e identidades gerenciadas. As atribuições de função são a maneira de controlar acesso aos recursos do Azure. Se as funções integradas não atenderem às necessidades específicas da sua organização, você pode criar seus próprios funções personalizadas do Azure.
As funções integradas se aplicam apenas aos recursos para os quais são destinadas, por exemplo, confira esses 2 exemplos de funções integradas sobre recursos de Computação:
Fornece permissão para backup de disco no cofre. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Visualizar Máquinas Virtuais no portal e fazer login como usuário regular. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Essas funções também podem ser atribuídas a contêineres lógicos (como grupos de gerenciamento, assinaturas e grupos de recursos) e os principais afetados terão essas funções 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 Azure AD.
Funções Personalizadas
O Azure também permite criar funções personalizadas com as permissões necessárias para o usuário.
Permissão Negada
Para que um principal tenha acesso a um recurso, ele precisa de uma função explícita sendo concedida a ele (de qualquer maneira) concedendo a ele essa permissão.
Uma atribuição de função de negação explícita tem precedência sobre a função que concede a permissão.
Administrador Global
Usuários com a função de Administrador Global têm a capacidade de 'elevar' para a função de Administrador de Acesso do Usuário ao grupo de gerenciamento raiz. Isso significa que um Administrador Global poderá gerenciar o acesso a 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
Políticas do Azure
As políticas do Azure são um conjunto de regras e regulamentos no Microsoft Azure, um serviço de computação em nuvem, que ajudam a gerenciar e fazer cumprir padrões organizacionais e avaliar a conformidade em escala. Essas políticas fazem cumprir diferentes regras sobre seus recursos do Azure, garantindo que esses recursos permaneçam em conformidade com os padrões corporativos e acordos de nível de serviço.
As políticas do Azure são cruciais para a governança e segurança em nuvem, ajudando a garantir que os recursos sejam usados corretamente e de forma eficiente, e que estejam em conformidade com regulamentações externas e políticas internas. Alguns exemplos:
Garantir 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.
Aplicação de Padrões de Nomenclatura: As políticas podem impor convenções de nomenclatura para os recursos do Azure. Isso ajuda na organização e identificação fácil de recursos com base em seus nomes, o que é útil em ambientes grandes.
Restringir Certos Tipos de Recursos: Esta política pode restringir a criação de certos tipos de recursos. Por exemplo, uma política poderia ser definida para evitar a criação de tipos de recursos caros, como determinados tamanhos de VM, para controlar os custos.
Aplicação de Políticas de Tags: Tags são pares de chave-valor associados aos recursos do Azure usados para gerenciamento de recursos. As políticas podem garantir que determinadas tags estejam presentes, ou tenham valores específicos, para todos os recursos. Isso é útil para rastreamento de custos, propriedade ou categorização de recursos.
Limitar o Acesso Público a Recursos: As políticas podem garantir que certos recursos, como contas de armazenamento ou bancos de dados, não tenham pontos de extremidade públicos, garantindo que sejam acessíveis apenas dentro da rede da organização.
Aplicação Automática de Configurações de Segurança: As políticas podem ser usadas para aplicar automaticamente configurações de segurança aos 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.
Escopo 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 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 gerenciamento de acesso mais refinado ou simplificar o gerenciamento de centenas de atribuições de função.
O Azure ABAC (controle de acesso baseado em atributos) baseia-se no Azure RBAC adicionando condições de atribuição de função com base 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 adicionar opcionalmente à sua atribuição de função para fornecer um controle de acesso mais refinado. 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 negar explicitamente acesso a recursos específicos usando condições.
Permissões Padrão do Usuário
Um usuário básico terá algumas permissões padrão para enumerar algumas partes do AzureAD:
Ler todos os usuários, Grupos, Aplicativos, Dispositivos, Funções, Assinaturas e suas propriedades públicas
Convidar Convidados (pode ser desativado)
Criar grupos de segurança
Ler associações de Grupo não ocultas
Adicionar convidados a grupos de propriedade
Criar novo aplicativo (pode ser desativado)
Adicionar até 50 dispositivos ao Azure (pode ser desativado)
Você pode ver a lista completa de permissões padrão dos usuários na documentação. Além disso, observe que nessa lista você também pode ver a lista de permissões padrão de convidados.
Lembre-se de que para enumerar recursos do Azure, o usuário precisa de uma concessão explícita da permissão.
Gerenciamento de Identidade Privilegiada (PIM)
O Gerenciamento de Identidade Privilegiada (PIM) no Azure é uma ferramenta que gerencia, controla e monitora o acesso privilegiado no Azure Active Directory e no Azure. Ele aprimora a segurança fornecendo acesso privilegiado just-in-time e com tempo limitado, aplicando fluxos de trabalho de aprovação e exigindo autenticação adicional. Essa abordagem minimiza o risco de acesso não autorizado, garantindo que permissões elevadas sejam concedidas apenas quando necessário e por uma duração específica.
Tokens de Autenticação
Existem três tipos de tokens usados no OIDC:
Tokens de Acesso: O cliente apresenta esse token ao servidor de recursos para acessar recursos. Ele pode ser usado apenas para uma combinação específica de usuário, cliente e recurso e não pode ser revogado até o vencimento - que é de 1 hora por padrão. A detecção é baixa usando isso.
Tokens de ID: O cliente recebe este token do servidor de autorização. Ele contém informações básicas sobre o usuário. Ele está vinculado a uma combinação específica de usuário e cliente.
Tokens de Atualização: Fornecido ao cliente com o token de acesso. Usado para obter novos tokens de acesso e ID. Ele está vinculado a uma combinação específica de usuário e cliente e pode ser revogado. O vencimento padrão é de 90 dias para tokens de atualização inativos e sem vencimento para tokens ativos.
As informações para acesso condicional são armazenadas dentro do JWT. Portanto, se você solicitar o token de um endereço IP permitido, esse IP será armazenado no token e então você pode usar esse token de um IP não permitido para acessar os recursos.
Confira a seguinte página para aprender diferentes maneiras de solicitar tokens de acesso e fazer login com eles:
pageAz - AzureAD (AAD)Os endpoints de API mais comuns são:
Gerenciador de Recursos do Azure (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph, que está obsoleto, é graph.windows.net)
Referências
Última actualización
