Audite o Entra ID antes que a deriva cloud se transforme em compromisso
A EtcSec executa 158 deteções em 9 categorias de Microsoft Entra ID. A cobertura foca os controlos que os atacantes abusam primeiro em Microsoft 365 e Azure: lacunas em Conditional Access, ausência de MFA, administradores permanentes de risco, permissões perigosas em aplicações, deriva guest e resposta fraca a utilizadores ou sign-ins de risco.
A recolha utiliza Microsoft Graph API apenas com permissões de aplicação. Não é necessária sessão delegada, não é instalado nenhum agente em endpoints e a auditoria não altera o tenant.
A auditoria verifica se todos os utilizadores e roles admin estão cobertos, se MFA é exigida, se legacy auth está bloqueada, se device compliance ou token protection são usados e se exclusões demasiado amplas deixam falhas.
O collector observa o uso de PIM, atribuições permanentes, contas de emergência, definições de approval e justification, duração de ativação e service principals com roles administrativas.
O catálogo cobre consentimentos tenant-wide, política de admin consent, permissões Graph altamente privilegiadas, implicit grant, multi-tenant, owners em falta, secrets expirados e credenciais com vida excessiva.
Guest admins, convites sem controlo, contas guest obsoletas, ausência de MFA para guests, confiança cross-tenant e exposição B2B fazem parte da revisão Entra base.
As 9 categorias alinham com a forma real como a identidade cloud é abusada
A auditoria Entra não é um score cloud genérico. É uma revisão de controlos organizada em torno de Conditional Access, privilégios, consentimento de aplicações, governação externa e resposta baseada em risco.
Identity e MFA
25 deteções cobrindo políticas de registo, métodos fortes, passwordless, contas de utilizador obsoletas, SSPR e proteção de passwords.
Aplicações e service principals
24 deteções sobre permissões Graph perigosas, consentimentos tenant-wide, owners de apps, implicit grant, multi-tenant e higiene de secrets.
Conditional Access
20 deteções sobre cobertura de todos os utilizadores e admins, MFA, bloqueio de legacy auth, device compliance, políticas baseadas em risco e exclusões.
Privileged Access e PIM
18 deteções sobre PIM, atribuições permanentes, contas de emergência, approval, justification, MFA na ativação e número de Global Admins.
Guests, grupos e configuração
39 deteções sobre guests, confiança cross-tenant, grupos dinâmicos, role-assignable groups, definições do tenant e exportação de logs.
Conformidade e Risk Protection
18 deteções sobre licenças P2, access reviews, postura de Identity Protection, utilizadores de risco e lacunas em resposta automatizada.
Porque as equipas usam a EtcSec para revisões de Entra ID
A identidade cloud muda continuamente. Uma auditoria útil precisa de poder ser relançada após alterações de policy, onboarding de aplicações, colaboração externa ou revisões de acesso privilegiado.
Workflow Graph em leitura apenas
A auditoria assenta em permissões de aplicação Graph. Não é necessária sessão delegada de utilizador nem mutação do tenant para produzir findings.
Rápida o suficiente para janelas de mudança
O runtime típico situa-se entre 8 e 30 segundos consoante o tamanho do tenant e o throttling Graph. Isso torna realista a revisão recorrente.
Findings nomeados alinhados com o trabalho dos operadores
Os owners de Conditional Access, IAM, plataforma de aplicações e governação veem os findings do seu perímetro em vez de um score cloud misturado.
Um collector para cloud e on-prem
O mesmo ETC Collector pode auditar Active Directory e Microsoft Entra ID, o que conta em programas híbridos em que a deriva de um plano amplia o risco do outro.
O que uma auditoria séria de Entra ID deve tornar explícito
A postura cloud é demasiado vezes reduzida a “temos MFA?”. O catálogo publicado mostra porque isso é insuficiente: permissões, definições do tenant, governação guest e resposta ao risco interagem.
Recolha Graph em leitura apenas e endpoints chave
A auditoria lê `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy` e os endpoints relevantes de auditoria ou Identity Protection. Assim, os findings ficam associados a objetos concretos em vez de afirmações genéricas sobre postura cloud.
A utilização de permissões de aplicação também torna o workflow adequado à automação. As equipas de segurança não precisam de uma sessão admin interativa para verificar se uma policy continua a proteger todos os admins ou se o onboarding de uma aplicação voltou a introduzir permissões excessivas.
As 9 categorias e as perguntas operacionais a que respondem
| Categoria | Controlos | O que o operador aprende |
|---|---|---|
| Identity | 25 | Se MFA, política de passwords, SSPR, enrollment e contas obsoletas resistem a ataques modernos. |
| Applications | 24 | Se app registrations, service principals, consentimentos e credenciais dão acesso excessivo ou órfão. |
| Conditional Access | 20 | Se a cobertura é completa para todos os utilizadores, admins, legacy, risco e sessões. |
| Privileged Access | 18 | Se PIM é bem usado, se existem contas de emergência e se as roles admin continuam permanentes. |
| Guest External | 15 | Se guests, convites e colaboração cross-tenant permanecem limitados e auditáveis. |
| Config | 12 | Se as definições do tenant, diagnósticos, consentimentos e app registration suportam uma operação segura. |
| Groups | 12 | Se grupos dinâmicos, role-assignable ou geridos por externos escondem privilégio. |
| Compliance | 8 | Se o tenant está licenciado e configurado para access reviews e Identity Protection. |
| Risk Protection | 10 | Se utilizadores e sign-ins de risco são detetados e tratados automaticamente. |
As famílias de deteção que mais frequentemente desencadeiam remediação
Lacunas em Conditional Access
Os findings chave incluem CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN e CA_POLICY_REPORT_ONLY.
- Mostra se o tenant assenta numa cobertura parcial.
- Separa controlos baseados em risco do baseline de MFA.
- Torna visíveis exclusões que muitas vezes ficam escondidas no JSON.
Deriva de acesso privilegiado
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS e PA_SERVICE_PRINCIPAL_ADMIN descrevem se o privilégio continua permanente e mal protegido.
- Útil para IAM, cloud platform e governação.
- Distingue o desenho de contas de emergência da higiene PIM.
- Destaca service principals porque a MFA não compensa aí.
Risco de aplicações e consentimento
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY e SP_HIGH_PRIVILEGE expõem os caminhos de escalada e exfiltração mais frequentes.
- Combina revisão de app registrations e postura dos service principals.
- Mostra higiene de credenciais e não apenas permissões.
- Ajuda à limpeza após M&A ou sprawl cloud.
Governação guest e cross-tenant
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS e GUEST_NO_ACCESS_REVIEW mostram se a colaboração externa continua controlada.
- Particularmente útil em ambientes de parceiros ou M&A.
- Distingue a policy de convite da população guest realmente obsoleta.
- Mostra onde os guests já estão presentes em grupos sensíveis.
Identity Protection e resposta ao risco
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS e RISK_USERS_NOT_REMEDIATED mostram se o tenant reage quando a Microsoft sinaliza uma conta ou um sign-in de risco.
- Deteção sem resposta significa compromisso ainda ativo.
- Liga licença, configuração de policy e resposta operacional.
- Distingue telemetria simples de proteção realmente aplicada.
Como os findings se mapeiam às fronteiras de responsabilidade
Os owners de Conditional Access olham primeiro para a categoria CA, mas as suas decisões determinam também a proteção de admins, guests e utilizadores de risco. Os owners de plataformas aplicacionais precisam dos findings de Applications porque consentimentos e privilégios de service principals surgem muitas vezes fora do fluxo IAM central. A governação concentra-se em Compliance e Risk Protection, porque estas categorias revelam se PIM, Identity Protection e access reviews estão realmente a ser usados.
Uma página Entra útil precisa por isso de fazer mais do que anunciar “auditamos Entra ID”. Tem de mostrar como os findings se ligam a modelos operacionais concretos: onboarding de aplicações, atribuição de roles admin, colaboração externa, automação de resposta ao risco e visibilidade híbrida.
- IAM e cloud engineering são donos das decisões de Conditional Access e PIM.
- As equipas aplicacionais são responsáveis por registrations, owners e rotação de secrets.
- A governação é responsável por access reviews, provas de conformidade e resposta ao risco.
- Os programas híbridos precisam de um workflow comum cloud e on-prem.
Porque o collector importa mesmo numa revisão puramente cloud
A documentação do collector mostra o mesmo workflow para Entra via Graph e para Active Directory via LDAP ou SMB. Isso permite rever riscos híbridos numa única análise, em vez de separar o que acontece no cloud do que acontece on-prem.
A EtcSec acrescenta a camada de dashboards e exploração acima do collector. O resultado é passar de uma revisão bruta de controlos cloud para remediação recorrente e acompanhamento histórico, e não apenas para uma exportação CSV.
Perguntas frequentes
O que cobre exatamente a auditoria de Entra ID?
O catálogo publicado lista 158 deteções em Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8) e Risk Protection (10).
A auditoria precisa de permissões delegadas ou de uma sessão admin interativa?
Não. A revisão assenta em permissões de aplicação Microsoft Graph e não requer sessão delegada interativa. Isso torna o workflow compatível com automação.
É possível rever Entra e Active Directory no mesmo workflow?
Sim. O ETC Collector suporta Entra ID e Active Directory para que equipas híbridas executem ambas as revisões com o mesmo modelo de recolha.
Porque tratar permissões de aplicações e governação guest como temas principais?
Porque muitos incidentes de identidade cloud começam com consent phishing, permissões Graph excessivas, service principals obsoletos ou definições de colaboração externa demasiado abertas, e não apenas com uma caixa MFA em falta.
Páginas relacionadas com segurança de identidade
Veja o catálogo on-prem que complementa a revisão Entra em programas híbridos de identidade.
Inspecione as deteções nomeadas que alimentam as páginas cloud e on-prem.
Compreenda o workflow de recolha, o modo standalone, o daemon e a superfície API.
Compare o motor de recolha open-source com a camada SaaS para dashboards e acompanhamento.
Inicie a sua auditoria Microsoft Entra ID
Ligue-se com permissões Graph em leitura apenas, reveja Conditional Access, privilégios, aplicações, guests e risco, e transforme a saída em remediação recorrente.