Configurações Padrão de Usuário do Tenant do Entra ID Restringem o Registro de Aplicativos Só Após um Administrador Mudar Isso

Configurações Padrão de Usuário do Tenant do Entra ID Restringem o Registro de Aplicativos Só Depois de um Administrador Mudar Isso

As configurações padrão de usuário do tenant do Entra ID restringem o registro de aplicativos, a criação de grupos e a navegação pelo admin center — mas só depois que um administrador as altera. Até que alguém o faça, a linha de base documentada para um usuário membro comum é deliberadamente generosa, e a maioria dos tenants nunca a revisita.

A Microsoft é explícita sobre o que um usuário membro comum pode fazer. A referência de permissões padrão afirma que usuários membros podem registrar aplicativos, gerenciar sua própria foto de perfil e número de celular, alterar sua própria senha e convidar convidados B2B. Esses usuários também podem ler todas as informações de diretório (com poucas exceções). A mesma página lista, em Groups, que usuários membros podem criar grupos de segurança e criar grupos do Microsoft 365; em Applications, que podem registrar (criar) novos aplicativos e enumerar a lista de todos os aplicativos; e em Roles and scopes, que podem ler todas as funções administrativas e associações (Default user permissions).

Essa é a parte incômoda. As duas pré-condições que fazem o phishing de consentimento OAuth e o reconhecimento de diretório funcionarem não são capacidades exóticas de atacante — são configurações do tenant. Quatro chaves fecham a maior parte da lacuna, e nenhuma delas exige upgrade de licença.

Como funciona: quatro chaves, três objetos diferentes

O Microsoft Entra admin center apresenta isso como uma lista organizada em User settings e Group settings. Por baixo, elas ficam armazenadas em três lugares sem relação entre si — e é exatamente por isso que auditorias parciais as deixam passar.

As duas primeiras ficam no objeto singleton authorizationPolicy, válido para todo o tenant. O Microsoft Graph documenta allowedToCreateApps como correspondente à configuração "Users can register applications" no menu User settings, e allowedToCreateSecurityGroups como correspondente à configuração "Users can create security groups" nos Microsoft Entra admin centers, API ou PowerShell (defaultUserRolePermissions). O mesmo objeto também carrega allowedToCreateTenants, allowedToReadOtherUsers, allowedToReadBitlockerKeysForOwnedDevice e permissionGrantPoliciesAssigned.

A criação de grupos do Microsoft 365 fica em outro lugar completamente diferente: a configuração EnableGroupCreation dentro do template Group.Unified, cujo padrão documentado pela Microsoft é true (Overview of group settings).

A quarta chave é a incômoda, e é tratada em sua própria seção mais adiante.

A cadeia de ataque

Passo 1 — Obter uma conta comum

Sem função, sem consentimento de admin, sem escalonamento de privilégios. Password spraying, roubo de token por adversary-in-the-middle ou phishing de código de dispositivo terminam todos no mesmo lugar: uma sessão como usuário membro padrão. Tudo abaixo é aquilo que essa sessão está autorizada a fazer por padrão.

Passo 2 — Mapear o diretório de dentro

Usuários membros podem enumerar todos os usuários e contatos, todos os grupos, todos os dispositivos e todos os aplicativos, e ler todas as funções administrativas e associações. Na prática, isso significa que um atacante com uma sessão comum pode listar todo Global Administrator do tenant, identificar quais contas são cloud-only e escolher alvos — sem tocar em uma única superfície de admin.

Passo 3 — Registrar um aplicativo e adicionar uma credencial

Com allowedToCreateApps deixado no padrão, a conta cria um registro de aplicativo. A Microsoft documenta a consequência: quando um usuário registra um aplicativo, ele é automaticamente adicionado como owner do aplicativo. Owners podem então atualizar applications.credentials, entre outras propriedades.

Esse é o ponto de pivô. Adicionar um segredo ou certificado controlado pelo atacante a um aplicativo ou service principal está catalogado pela MITRE ATT&CK como T1098.001 — Account Manipulation: Additional Cloud Credentials, que observa que atacantes podem adicionar credenciais para Service Principals e Applications no Azure/Entra ID além das credenciais legítimas já existentes — essas credenciais incluem tanto chaves x509 quanto senhas. Uma credencial em um objeto de aplicativo não está vinculada à senha do usuário comprometido, então redefinir essa senha não expulsa o atacante.

O aplicativo ainda precisa de permissões para ser útil, e é aí que entra o lado do consentimento do tenant: por padrão, todos os usuários têm permissão para consentir aplicativos para permissões que não exigem consentimento de administrador (Configure how users consent to applications). Cobrimos essa metade do problema em detalhe em Phishing de consentimento OAuth: como aplicativos maliciosos contornam o roubo de senha e em Registro de aplicativo Entra: permissões perigosas da Graph API.

Passo 4 — Criar um grupo que ninguém governa

A criação de grupos self-service não é, por si só, uma escalada de privilégio — um novo grupo não concede acesso a nada. O dano está na governança. Um usuário membro que cria um grupo normalmente é adicionado como seu owner automaticamente, com direitos sobre groups.members e groups.owners — com uma exceção documentada: para grupos de segurança criados no portal do Azure, a Microsoft observa que o owner não é atribuído automaticamente na criação do grupo. A Microsoft observa ainda que grupos de segurança criados via self-service pelo portal My Groups ficam disponíveis para qualquer usuário entrar, seja a associação aprovada pelo owner ou aprovada automaticamente (Set up self-service group management).

O resultado é um diretório com milhares de grupos cuja ownership não significa nada, no qual um grupo controlado por um atacante é indistinguível dos demais — até que um administrador conceda a esse grupo acesso a um aplicativo, um site ou uma exceção de Conditional Access.

Por que a chave do admin center é fricção, não um controle

Essa é a chave mais frequentemente relatada como "corrigida" e mais frequentemente mal compreendida. A própria documentação da Microsoft traz um aviso acima da tabela: a configuração Restrict access to Microsoft Entra administration portal limita o acesso a um conjunto de páginas do admin center comumente visitadas. Ela não é uma medida de segurança.

O detalhe vale uma leitura atenta. Configurá-la como Yes adiciona uma camada de fricção à navegação casual, restringindo que não administradores carreguem páginas frequentemente visitadas, como a página inicial, a visão geral do tenant e a lista de usuários. Mas a Microsoft afirma que isso não bloqueia o acesso programático aos dados do Microsoft Entra via PowerShell, Microsoft Graph API ou outras ferramentas como o Visual Studio, que não se aplica a usuários com uma função administrativa, e que a maioria das páginas no admin center permanece acessível se o usuário tiver um link direto (deep link).

Todo passo da cadeia de ataque acima passa pelo Microsoft Graph. Nenhum deles é afetado por essa chave.

Há uma segunda consequência para auditores: diferente das outras três configurações, esta não tem propriedade no recurso authorizationPolicy. Sua lista de propriedades documentada — tanto em v1.0 quanto em beta — contém defaultUserRolePermissions, guestUserRoleId, allowInvitesFrom, blockMsolPowerShell e afins, e nada para o acesso ao admin portal. Se a linha de base do seu tenant afirma ler essa configuração via Graph, verifique o que ela realmente está lendo.

🚨 Perigo: Não conte a chave do portal como controle compensatório para o registro de aplicativos aberto. A orientação da Microsoft é usar uma política de Conditional Access direcionada à Windows Azure Service Management API para bloquear o acesso de não administradores aos endpoints de gerenciamento do Azure.

Detecção

Leia o estado real em vez da renderização do admin center. Três das quatro chaves podem ser recuperadas com escopos somente leitura; a quarta — a chave do admin center — não tem propriedade para ler, pelo motivo já explicado.

Connect-MgGraph -Scopes "Policy.Read.All","Directory.Read.All"

$policy = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
$policy.defaultUserRolePermissions

$settings = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/groupSettings"
$settings.value

Um tenant que nunca foi corrigido retorna algo bem próximo disto, com uma coleção groupSettings vazia:

{
  "allowedToCreateApps": true,
  "allowedToCreateSecurityGroups": true,
  "allowedToCreateTenants": true,
  "allowedToReadOtherUsers": true,
  "permissionGrantPoliciesAssigned": ["managePermissionGrantsForSelf.microsoft-user-default-legacy"]
}

Combine a leitura da configuração com o log de auditoria. Estes nomes de atividade são exatos, e todos estão disponíveis no log de auditoria do Microsoft Entra:

Fonte de cada nome de atividade: a Microsoft Entra audit log activity reference.

Duas detecções práticas surgem daí. Primeira: alerte em Add application ou Add service principal quando o principal iniciador não possuir nenhuma função de diretório — em um tenant com uma população de desenvolvedores controlada, isso deveria ser uma lista curta. Segunda: alerte incondicionalmente em Update authorization policy; há muito poucos motivos legítimos para essa política mudar, e um atacante que alcance Privileged Role Administrator vai usá-la para reabrir o que você fechou. Se o seu tenant não retém esses logs por tempo suficiente para investigar, corrija isso primeiro — veja Retenção de logs e configurações de diagnóstico do Entra ID.

Remediação

1. Fechar as permissões da função padrão de usuário. O próprio exemplo em PowerShell da Microsoft para desativar a criação de aplicativos é a base; as duas propriedades adicionais estão documentadas no mesmo objeto.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

$params = @{
    defaultUserRolePermissions = @{
        allowedToCreateApps           = $false
        allowedToCreateSecurityGroups = $false
        allowedToCreateTenants        = $false
    }
}

Update-MgPolicyAuthorizationPolicy -BodyParameter $params

Definir allowedToCreateTenants como $false restringe a criação de tenants à função Tenant Creator. Isso importa mais do que parece: a Microsoft observa que, por padrão, o usuário que cria um tenant do Microsoft Entra recebe automaticamente a função Global Administrator, e o evento é registrado como Create Company.

2. Fechar e delegar a criação de grupos do Microsoft 365. Isso exige um objeto groupSettings criado a partir do template Group.Unified, porque um tenant padrão não tem nenhum. Leia o ID do template primeiro no seu próprio tenant com GET https://graph.microsoft.com/v1.0/groupSettingTemplates, em vez de fixá-lo no código.

{
  "templateId": "62375ab9-6b52-47ed-826b-58e47e0e304b",
  "values": [
    { "name": "EnableGroupCreation", "value": "false" },
    { "name": "GroupCreationAllowedGroupId", "value": "<object-id-of-your-approved-creators-group>" }
  ]
}

GroupCreationAllowedGroupId é documentado como o identificador do grupo de segurança cujos membros têm permissão para criar grupos do Microsoft 365 mesmo quando EnableGroupCreation é false — essa é a sua válvula de escape, e ela não exige licença P1.

3. Reforçar o gerenciamento self-service de grupos. No admin center, em Groups → General settings, defina Users can create security groups in Azure portals, API or PowerShell e Users can create Microsoft 365 groups in Azure portals, API or PowerShell como No. A Microsoft é explícita sobre a válvula de escape: se você quiser habilitar alguns, mas não todos os usuários, a criar grupos, pode atribuir a esses usuários uma função capaz de criar grupos, como Groups Administrator. Conheça o limite da chave vizinha antes de confiar nela — Restrict user ability to access groups features in the Access Panel restringe apenas o acesso a informações de grupo em My Groups. Ela não restringe o acesso a informações de grupo por outros métodos, como chamadas à Microsoft Graph API ou pelo próprio Microsoft Entra admin center.

4. Substituir a chave do admin center por um controle de verdade. Defina-a como Yes se você quiser a fricção, mas implemente o controle que a Microsoft realmente recomenda: uma política de Conditional Access direcionada à Windows Azure Service Management API que bloqueie o acesso de não administradores aos endpoints de gerenciamento do Azure. Verifique primeiro em modo report-only — veja Modo somente relatório do Conditional Access e exclusões obsoletas.

5. Verificar, e atentar para as duas pegadinhas. Execute novamente o bloco de detecção acima e confirme que cada valor mudou. Dois comportamentos documentados, do contrário, vão fazer você achar que a mudança falhou ou funcionou quando não foi o caso:

• As configurações de grupo podem levar até 15 minutos para entrar em vigor.
• Essas configurações são para usuários e não afetam service principals. Por exemplo, se um service principal tinha permissões para criar grupos, mesmo que você defina essas configurações como No, o service principal ainda pode criar grupos.

Esse segundo ponto é o motivo pelo qual essa etapa de correção deve acontecer junto com um inventário de aplicativos. Fechar a criação do lado do usuário enquanto service principals com privilégios excessivos permanecem ativos apenas move o problema, em vez de resolvê-lo — veja Registros de aplicativo Azure: apps com privilégios excessivos e a linha de base mais ampla de Fortalecimento do tenant Azure: security defaults.

Como a EtcSec detecta isso

A EtcSec divide essa superfície em quatro achados distintos em cada auditoria do Azure, em vez de agrupá-la em uma pontuação vaga de "fortalecimento do tenant". Todos os quatro são reportados em severidade média.

• AZ_APP_REGISTRATION_OPEN — App Registration Open to All Users: acionado quando authorizationPolicy → defaultUserRolePermissions.allowedToCreateApps retorna true. Esse valor é lido diretamente do Microsoft Graph.
• AZ_SELF_SERVICE_GROUPS_OPEN — Self-Service Group Creation Open: acionado quando o tenant não carrega nenhuma restrição de criação de grupos — o que corresponde ao estado de um tenant padrão, já que EnableGroupCreation permanece true até que exista um objeto Group.Unified.
• AZ_GROUP_SELF_SERVICE — Self-Service Group Management Unrestricted: o mesmo estado irrestrito, avaliado pelo lado dos grupos — grupos sem governança, e uma ownership que não significa nada.
• AZ_ADMIN_PORTAL_ACCESS_OPEN — Admin Portal Access Not Restricted: acionado a menos que o tenant esteja registrado como restringindo o acesso ao admin center a administradores. Reportado como higiene de configuração, não como fronteira de segurança, em linha com a própria ressalva da Microsoft.

Mantê-los separados importa porque a correção difere por achado: um é uma atualização de authorizationPolicy, dois exigem um objeto groupSettings que precisa ser criado primeiro, e o quarto é uma política de Conditional Access. Para a sequência completa, veja Como auditar a segurança do Microsoft Entra ID: guia prático.