Seu tenant Microsoft 365 é infraestrutura de nuvem: centenas de configurações relevantes para segurança espalhadas por Entra ID, Exchange Online, SharePoint e Teams, e elas sofrem drift exatamente como uma conta AWS sem gestão. Um admin altera uma configuração durante um incidente e nunca a reverte. A Microsoft muda um padrão em uma atualização de serviço. Um fornecedor ganha acesso de convidado para um piloto que terminou dois trimestres atrás. Ninguém revisa nada disso, porque o tenant é "coisa de TI", não "coisa de infraestrutura". Posture scanning é a correção entediante e eficaz: comparar continuamente a configuração real do tenant contra uma baseline de segurança publicada e reportar as lacunas. E em 2026 a forma prática de rodar esse scanner é como SaaS, o que significa que você está checando nuvem com nuvem. Este post é o 101, usando o Aether365 como exemplo. Transparência total: o Aether365 é produto meu.

Um princípio antes de começar: read-only é o padrão. Nada recebe acesso de escrita ao seu tenant sem um consentimento separado e explícito.

Trate o tenant como uma conta de produção

Se alguém rodasse AWS em produção sem auditoria de configuração, sem detecção de drift e sem histórico de mudanças, você chamaria isso de negligência. A maioria das organizações roda o Microsoft 365 exatamente assim, enquanto ele guarda o provedor de identidade, todo o e-mail e a maior parte dos arquivos. O tenant é o plano de identidade de todo o resto que você opera; uma má configuração de Conditional Access ali vale mais para um atacante do que um bucket S3 público.

A mentalidade de infraestrutura se transfere diretamente. Você quer uma baseline declarada, uma comparação agendada da realidade contra ela e um alerta quando as duas divergirem. No mundo AWS, você recorreria a regras do Config ou standards do Security Hub. Para o Microsoft 365, os equivalentes são os benchmarks de postura.

Os três benchmarks que valem a pena conhecer

Três baselines cobrem a maior parte do que importa, e todo scanner sério mapeia para pelo menos uma delas:

  • CIS Microsoft 365 Foundations Benchmark: o mais amplo, mais de 800 verificações cobrindo a suíte inteira, de exigência de MFA a auditoria de caixa de correio e políticas de compartilhamento. A resposta padrão para "auditado contra o quê?"
  • EIDSCA (Entra ID Security Configuration Analyzer): focado inteiramente no Entra ID, as configurações que decidem quem pode autenticar, consentir e registrar aplicações. Superfície pequena, maior raio de explosão.
  • CISA ScuBA (Secure Cloud Business Applications): a baseline do governo federal americano para o M365. Mais rígida e mais opinativa; útil mesmo fora do governo como referência de "o que um alvo difícil faria".

Os benchmarks se sobrepõem, e tudo bem. Sobreposição em controles de identidade mostra onde está o consenso, e achados de consenso são os primeiros a corrigir.

Scripts ou SaaS: o trade-off de verdade

Você pode absolutamente rodar essas verificações por conta própria. A Graph API está ali, ferramentas da comunidade como o Maester encapsulam boa parte dela, e uma execução agendada de PowerShell contra um tenant é projeto de fim de semana. Gosto dessa abordagem para aprender o que as verificações realmente fazem.

Ela para de escalar em três eixos. Manutenção: benchmarks ganham versões, endpoints do Graph mudam, e sua coleção de scripts silenciosamente vira um produto que você é dono. Histórico: um script pontual mostra o estado de hoje, mas perguntas de postura são perguntas de tendência, quando este controle regrediu e o que mudou ao redor dele. Multi-tenancy: no momento em que você administra mais de um tenant, um MSP com trinta clientes, por exemplo, scripts e credenciais por tenant viram o risco.

Um scanner SaaS inverte a troca: você concede a ele consentimento somente leitura no Microsoft Graph, ele roda scans de compliance e de exposição em um cronograma, diário, semanal ou mensal, e mantém o histórico. O modelo de consentimento é a parte a escrutinar, porque você está conectando um serviço externo ao seu plano de identidade. Somente leitura deve ser o padrão e qualquer coisa além disso deve ser um consentimento separado e explícito que você pode recusar. É essa única propriedade que torna nuvem-checando-nuvem aceitável para um tenant europeu regulado.

O que o Aether365 cobre

O Aether365 é a minha versão desse scanner. O núcleo é scanning de compliance contra os três benchmarks acima mais scanning de exposição, agendado por tenant, com gestão multi-tenant para MSPs, notificações por Teams e e-mail, e uma REST API mais um servidor MCP embutido caso você queira seu assistente de IA consultando resultados de scan. É baseado na União Europeia e em conformidade com o GDPR, você escolhe sua região de dados no cadastro, e dados de scan nunca são usados para treinar nenhum modelo.

Duas capacidades vão além da visão interna do tenant. O External Attack Surface verifica o que o tenant expõe de fora para dentro: registros SPF, DKIM e DMARC, que são estruturais para o e-mail do M365, expiração de certificados com avisos de 90 dias, DNS pendente e risco de subdomain takeover, endpoints de autenticação legada deixados abertos e compartilhamentos públicos de SharePoint e OneDrive. E o AI Pilot, opt-in e restrito aos planos Pro e Enterprise, transforma achados em correções concretas via Microsoft Graph que você aprova item por item antes de qualquer coisa ser aplicada, com trilha de auditoria verificada. Somente leitura continua sendo o padrão; o caminho de escrita é um consentimento separado da Microsoft que você habilita apenas se quiser. Existe um plano Free com scans mensais em um tenant, o suficiente para ver seu primeiro score CIS, e esse primeiro score costuma ser a motivação.

A conclusão

O 101 é simples: seu tenant Microsoft 365 merece a mesma disciplina de postura que suas contas de nuvem, os benchmarks para medir já existem, e a questão operacional é apenas se você mesmo roda o scanner ou consente que um SaaS o faça em modo somente leitura, em um cronograma. Scripts ensinam os controles; um serviço mantém você honesto ao longo do tempo. De qualquer forma, o modo de falha a evitar é o padrão atual: ninguém checando nada.

Leia isto a seguir

Para o lado de IA da mesma plataforma, por que remediação precisa de um portão de aprovação e para que serve de fato o relatório gerado por IA, veja M365 Security 101: AI Pilot and Business Impact Reports em ercan.ai. Para consultoria em nuvem, postura de segurança e trabalho de plataforma, ou só para dizer olá, comece em ercanermis.com.