Az - Basic Information
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Treinamento AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Treinamento GCP Red Team Expert (GRTE)
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.
É 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.
Ele confia em apenas 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
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 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 são excluídos.
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 de 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 é a abrangente plataforma de computação em nuvem 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 é 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.
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 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.
Novos usuários
Indique o nome e domínio do e-mail do inquilino selecionado
Indique o nome de exibição
Indique a senha
Indique as propriedades (primeiro nome, cargo, informações de contato…)
O tipo de usuário padrão é “membro”
Usuários externos
Indique o e-mail para convidar e o nome de exibição (pode ser um e-mail não Microsoft)
Indique as propriedades
O tipo de usuário padrão é “Convidado”
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 ocultas
Adicionar convidados a Grupos de Propriedade
Criar nova aplicação (pode ser desativado)
Adicionar até 50 dispositivos ao Azure (pode ser desativado)
Lembre-se de que, para enumerar recursos do Azure, o usuário precisa de uma concessão explícita da permissão.
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
Mostrar 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
Usuários convidados têm o mesmo acesso que membros concede todas as permissões de usuários membros a usuários convidados por padrão.
Usuários convidados têm acesso limitado a propriedades e associações de objetos de diretório (padrão) restringe o acesso de convidados 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.
Convidados podem convidar
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)
Usuário externo sai: Padrão Verdadeiro
Permitir que usuários externos deixem a organização
Mesmo que restritos por padrão, usuários (membros e convidados) com permissões concedidas poderiam realizar as ações anteriores.
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.
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.
Um Registro de Aplicativo é uma configuração que permite que uma aplicação se integre ao Entra ID e realize ações.
ID da Aplicação (Client ID): Um identificador único para seu aplicativo no Azure AD.
URIs de Redirecionamento: URLs onde o Azure AD envia respostas de autenticação.
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 para conceder acesso federado a ele (por exemplo, Github Actions).
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).
Permissões da API: Especifica quais recursos ou APIs o aplicativo pode acessar.
Configurações de Autenticação: Define os fluxos de autenticação suportados pelo aplicativo (por exemplo, OAuth2, OpenID Connect).
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.
O principal de serviço receberá todas as permissões solicitadas com as quais foi configurado.
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, para permissões selecionadas (Recomendado)
Todos os usuários podem consentir para permissões classificadas como "baixo impacto", para aplicativos de editores verificados ou aplicativos registrados nesta organização.
Padrão permissões de baixo impacto (embora você precise aceitar para adicioná-las como baixo):
User.Read - fazer login e ler o perfil do usuário
offline_access - manter acesso aos dados que os usuários deram acesso
openid - fazer login dos usuários
profile - visualizar o perfil básico do usuário
email - visualizar 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
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 ao 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 ao 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.
É 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 existe 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 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.
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
A função mais privilegiada é Administrador Global
Na descrição da função, é possível ver suas permissões granulares
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.
Proprietário
Acesso total a todos os recursos
Pode gerenciar o acesso de outros usuários
Todos os tipos de recurso
Contribuidor
Acesso total a todos os recursos
Não pode gerenciar acesso
Todos os tipos de recurso
Leitor
• Visualizar todos os recursos
Todos os tipos de recurso
Administrador de Acesso do Usuário
Visualizar todos os recursos
Pode gerenciar o acesso de outros usuários
Todos os tipos de recurso
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, confira esses 2 exemplos de Funções Integradas sobre recursos de Computação:
Fornece permissão ao cofre de backup para realizar backup de disco.
3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
Visualizar Máquinas Virtuais no portal e fazer login como um usuário regular.
fb879df8-f326-4884-b1cf-06f3ad86be52
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.
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 são para controlar ações sobre o recurso
dataActions são permissões sobre os dados dentro do objeto
Exemplo de JSON de permissões para uma função personalizada:
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.
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 do Azure 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
Políticas do Azure são regras que ajudam as organizações a garantir que seus recursos atendam a padrões específicos e requisitos de conformidade. 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.
Definição de Política: Uma regra, escrita em JSON, que especifica o que é permitido ou exigido.
Atribuição de Política: A aplicação de uma política a um escopo específico (por exemplo, assinatura, grupo de recursos).
Iniciativas: Uma coleção de políticas agrupadas para uma aplicação mais ampla.
Efeito: Especifica o que acontece quando a política é acionada (por exemplo, "Negar", "Auditar" ou "Anexar").
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 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.
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 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.
Limitando Acesso Público a Recursos: Políticas podem impor 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.
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:
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.
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 um gerenciamento de acesso mais detalhado 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
