Az - Basic Information
Hierarquia da Organização
Grupos de Gerenciamento
Se sua organização possui muitas assinaturas do Azure, pode ser necessário uma forma de gerenciar o acesso, políticas e conformidade para essas assinaturas. 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.
Das documentações: Cada diretório recebe um único grupo de gerenciamento de nível superior chamado grupo de gerenciamento raiz. O grupo de gerenciamento raiz é incorporado à hierarquia para que todos os grupos de gerenciamento e assinaturas se reúnam a ele. Este grupo de gerenciamento raiz permite que políticas globais e atribuições de função do Azure sejam aplicadas no nível do diretório. O Administrador Global do Azure AD precisa se elevar ao papel 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ário do grupo de gerenciamento raiz.
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 em 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 container lógico para o propósito de provisionar recursos de negócios ou técnicos. Este container mantém os detalhes dos recursos como máquinas virtuais (VMs), bancos de dados, entre outros. Ao criar um recurso do Azure, como uma VM, a assinatura associada a ele é especificada. Esta estrutura facilita a delegação de acesso, utilizando mecanismos de controle de acesso baseado em função.
Grupos de Recursos
Das documentações: 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 implantá-los, atualizá-los 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.
Unidades Administrativas
Das documentações: Unidades administrativas permitem que você subdivida sua organização em qualquer unidade que desejar, e então atribua administradores específicos que podem gerenciar apenas os membros dessa unidade. Por exemplo, você poderia usar unidades administrativas para delegar permissões a administradores de cada escola em uma grande universidade, para que eles pudessem 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 essa unidade administrativa que poderão usar para gerenciar os membros da unidade administrativa.
Azure vs Azure AD vs Azure AD Domain Services
É importante notar que Azure AD é um serviço dentro do Azure. Azure é a plataforma de nuvem da Microsoft, enquanto Azure AD é o serviço de identidade empresarial no Azure. Além disso, Azure AD não é como o Active Directory do Windows, é um serviço de identidade que funciona de maneira completamente diferente. Se você quiser executar um Controlador de Domínio no Azure para seu ambiente do Active Directory do Windows, precisará usar Azure AD Domain Services.
Principais
O Azure suporta diferentes tipos de principais:
Usuário: Uma pessoa regular com credenciais para acessar.
Grupo: Um grupo de principais gerenciados juntos. Permissões concedidas a grupos são herdadas por seus membros.
Principal de Serviço/Aplicações Empresariais: É 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 a você 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.
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): Identidades gerenciadas no Azure Active Directory oferecem uma solução para gerenciar automaticamente a identidade de aplicações. Essas identidades são usadas por aplicações para o propósito de conectar-se a recursos compatíveis com a autenticação do Azure Active Directory (Azure AD). Ao utilizar identidades gerenciadas, as aplicações podem proteger tokens do Azure AD enquanto eliminam 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 automaticamente exclui a identidade para você. Por design, apenas aquele 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 autônomo 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.
Papéis e Permissões
Papéis são atribuídos a principais em um escopo: principal -[HAS ROLE]->(scope)
Papéis atribuídos a grupos são herdados por todos os membros do grupo.
Dependendo do escopo ao qual o papel foi atribuído, o papel pode ser herdado para outros recursos dentro do container de escopo. Por exemplo, se um usuário A tem um papel na assinatura, ele terá esse papel em todos os grupos de recursos dentro da assinatura e em todos os recursos dentro do grupo de recursos.
Papéis Clássicos
Papéis Integrados
Das documentações: O controle de acesso baseado em função do Azure (Azure RBAC) possui vários papéis integrados do Azure que você pode atribuir a usuários, grupos, principais de serviço e identidades gerenciadas. As atribuições de papéis são a forma como você controla o acesso aos recursos do Azure. Se os papéis integrados não atenderem às necessidades específicas da sua organização, você pode criar seus próprios papéis personalizados do Azure.
Os papéis integrados se aplicam apenas aos recursos para os quais são destinados, por exemplo, confira estes 2 exemplos de papéis integrados sobre recursos de Computação:
Esses papéis também podem ser atribuídos sobre containers lógicos (como grupos de gerenciamento, assinaturas e grupos de recursos) e os principais afetados os terão sobre os recursos dentro desses containers.
Encontre aqui uma lista com todos os papéis integrados do Azure.
Encontre aqui uma lista com todos os papéis integrados do Azure AD.
Papéis Personalizados
O Azure também permite criar papéis personalizados com as permissões que o usuário precisa.
Permissão Negada
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 papel de negação explícita tem precedência sobre o papel que concede a permissão.
Administrador Global
Usuários com o papel de Administrador Global têm a capacidade de 'elevar' para o papel de Administrador de Acesso do Usuário do Azure no 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 impor padrões organizacionais e a avaliar a conformidade em grande escala. Essas políticas impõem 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 na nuvem, ajudando a garantir que os recursos sejam usados de forma adequada e eficiente, e que estejam em conformidade com regulamentos externos e políticas internas. Alguns exemplos:
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.
Impondo Padrões de Nomeação: As políticas podem impor convenções de nomenclatura para recursos do Azure. Isso ajuda a organizar e identificar facilmente os recursos com base em seus nomes, o que é útil em grandes ambientes.
Restringindo 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 impedir a criação de tipos de recursos caros, como certos tamanhos de VM, para controlar custos.
Impondo Políticas de Marcação: As marcas são pares chave-valor associados a recursos do Azure usados para gerenciamento de recursos. As políticas podem impor que certas marcas devem estar presentes, ou ter valores específicos, para todos os recursos. Isso é útil para rastreamento de custos, propriedade ou categorização de recursos.
Limitando o Acesso Público a Recursos: As 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.
Aplicando Configurações de Segurança Automaticamente: As 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.
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 da entidade onde foram atribuídas.
Essa estrutura hierárquica permite um gerenciamento 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 um papel a um principal para conceder-lhe acesso a um recurso. No entanto, em alguns casos, você pode querer fornecer um gerenciamento de acesso mais granular ou simplificar o gerenciamento de centenas de atribuições de papéis.
O ABAC do Azure (controle de acesso baseado em atributos) se baseia no Azure RBAC, adicionando condições de atribuição de papel com base em atributos no contexto de ações específicas. Uma condição de atribuição de papel é uma verificação adicional que você pode opcionalmente adicionar à sua atribuição de papel para fornecer um controle de acesso mais granular. Uma condição filtra as permissões concedidas como parte da definição de papel e atribuição de papel. Por exemplo, você pode adicionar uma condição que exige que um objeto tenha uma marca específica para ler o objeto. Você não pode explicitamente negar 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 Azure AD:
Ler todos os usuários, Grupos, Aplicações, Dispositivos, Papéis, Assinaturas e suas propriedades públicas
Convidar Convidados (pode ser desativado)
Criar Grupos de Segurança
Ler associações de Grupos não ocultas
Adicionar convidados a Grupos de Propriedade
Criar nova aplicação (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 nas documentações. Além disso, observe que nessa lista você também pode ver a lista de permissões padrão dos 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 melhora a segurança ao fornecer acesso privilegiado sob demanda e limitado no tempo, impondo 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 um período específico.
Tokens de Autenticação
Existem três tipos de tokens usados no OIDC:
Tokens de Acesso: O cliente apresenta este 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é a expiração - 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: Fornecidos ao cliente com o token de acesso. Usados 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. A expiração padrão é de 90 dias para tokens de atualização inativos e sem expiração para tokens ativos.
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.
Verifique a página a seguir para aprender diferentes maneiras de solicitar tokens de acesso e fazer login com eles:
Os endpoints de API mais comuns são:
Gerenciador de Recursos do Azure (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (O Azure AD Graph, que está obsoleto, é graph.windows.net)
Referências
Last updated
