Maester ScubaGear Entra ID testes de baseline: guia

O que são Maester ScubaGear Entra ID testes de baseline?

Maester ScubaGear Entra ID testes de baseline transformam a revisão da configuração de segurança numa avaliação repetível: selecionar asserções documentadas, recolher as definições do tenant, avaliá-las e conservar os resultados. Maester oferece automação de testes em PowerShell; ScubaGear avalia a configuração do Microsoft 365 face às baselines SCuBA da CISA. O seu valor está numa revisão que pode ser repetida após uma alteração, preservando o âmbito e as evidências.

Um resultado de baseline responde a uma pergunta delimitada. Pode estabelecer que uma asserção correspondeu à configuração disponível para a avaliação. Não estabelece que todos os percursos de autenticação estão protegidos nem que não ocorreu um ataque à identidade. O fluxo abaixo separa a medição da configuração, a investigação dos resultados, a correção controlada e a verificação posterior. Inclui comandos documentados e identificadores de testes reais, sem apresentar um exemplo como uma avaliação de tenant que tenhamos realizado.

Para as questões de cobertura das políticas que antecedem a seleção das ferramentas, consulte Lacunas de cobertura das políticas de baseline de Acesso Condicional no Entra ID. Esse artigo examina a existência de políticas para administradores, utilizadores, recursos e dispositivos. Este guia centra-se em tornar uma avaliação repetível e interpretar a sua saída.

Como funcionam as ferramentas: testes Pester e avaliação de políticas SCuBA

Maester e as suas diferentes suites de testes

Maester é um framework PowerShell de código aberto para manter a configuração de segurança através de testes automatizados. O seu repositório documenta testes Pester personalizados, exportações de resultados e integrações com pipelines. Pester fornece o modelo de execução dos testes; Maester acrescenta testes de segurança e relatórios a esse modelo. O framework pode ser ampliado, pelo que deve registar os testes efetivamente instalados em vez de tratar o nome do produto como uma declaração fixa de cobertura. README do repositório Maester.

As suites têm origens diferentes. A suite Maester contém testes de configuração de segurança da comunidade. A suite EIDSCA baseia-se no Entra ID Security Config Analyzer e verifica mitigações para cenários de ataque à identidade. A suite CISA testa a configuração do Microsoft 365 face às orientações SCuBA. Conserve a suite e o identificador do teste junto de cada resultado para que o leitor possa distinguir as suas fontes.

Os testes CISA do Maester não estabelecem que Maester executa o motor OPA do ScubaGear. Partilhar orientações de baseline também não estabelece implementações idênticas. Ao comparar constatações, use o requisito, a implementação do teste e a versão em análise. Dois testes com nomes semelhantes podem examinar condições diferentes, como demonstram os exemplos de autenticação legada abaixo.

ScubaGear e baselines por produto

ScubaGear pertence ao projeto Secure Cloud Business Applications da CISA. A sua avaliação documentada separa a recolha da avaliação: PowerShell consulta APIs do Microsoft 365, Open Policy Agent avalia as definições recolhidas face a políticas Rego, e a ferramenta gera resultados em HTML, JSON e CSV. O documento da baseline descreve a expectativa de segurança; a sua implementação automatizada determina o que a execução pode medir. README do ScubaGear.

O repositório fornece documentos de baseline separados para Entra ID, a suite de produtos de segurança, Exchange Online, Power BI, Power Platform, SharePoint e Teams. A presença de um documento de baseline não prova que todas as versões possam executar a avaliação de todos os produtos. Em particular, a tabela de parâmetros de v1.8.0 apresenta Entra ID como aad e enumera os seletores de produto aceites. Consulte essa tabela antes de selecionar um produto. README versionado, parâmetros de v1.8.0.

Para trabalho centrado no Entra, recomendamos começar pelo seletor aad e rever os seus pré-requisitos. Amplie para outros produtos quando as ligações, funções e responsáveis pelas evidências estiverem prontos. Trata-se de uma recomendação operacional, não de uma afirmação de que o restante Microsoft 365 é avaliado apenas através do Graph.

Distinguir versões e documentação em evolução

As referências de versão verificadas em 3 de outubro de 2026 para este guia são Maester 2.2.0 e ScubaGear v1.8.0. Nessa data de revisão, o README de main do ScubaGear já abordava v2.0.0. Por isso, este guia identifica explicitamente as referências de execução e permissões de v1.8.0; as afirmações sobre a documentação de baseline em evolução são citadas separadamente. Antes de adotar estes exemplos, fixe a versão do módulo, as versões das dependências e a revisão dos testes como especificação da avaliação.

Preparar o acesso de leitura ao Graph antes de executar uma avaliação

O acesso de leitura tem duas dimensões: o que a ferramenta faz e o que a sua identidade está autorizada a fazer. Microsoft Graph distingue o acesso delegado, em nome de um utilizador com sessão iniciada, do acesso de aplicação sem esse utilizador. O consentimento e as funções de diretório suportadas continuam a ser relevantes. Criar uma aplicação, conceder consentimento ou configurar a autenticação é preparação administrativa; deve distingui-la das leituras de configuração subsequentes. Referência das permissões Graph, autenticação do Graph PowerShell.

Por exemplo, listar políticas de Acesso Condicional é uma operação de leitura Graph cuja permissão documentada é Policy.Read.All. O requisito desse endpoint não é evidência suficiente para conceder acesso a uma suite de avaliação inteira: outros testes leem outros recursos. Listar conditionalAccessPolicies.

Scopes predefinidos do Maester

O código-fonte Get-MtGraphScope de 2.2.0 define os scopes de leitura predefinidos, incluindo acesso ao diretório, políticas, auditoria, relatórios, gestão de dispositivos, risco de identidade e métodos de autenticação. Esta é a lista do framework, não o mínimo para um único teste de Acesso Condicional. Directory.Read.All, por exemplo, é mais abrangente do que ler apenas a coleção de políticas.

O mesmo código separa acréscimos opcionais: -Privileged acrescenta ReportSettings.ReadWrite.All, -SendMail acrescenta Mail.Send e -SendTeamsMessage acrescenta ChannelMessage.Send. Mantenha esses acréscimos fora de uma avaliação Graph de leitura predefinida, salvo se um requisito revisto separadamente precisar deles. Connect-Maester explica as ligações opcionais e o comportamento dos scopes privilegiados.

Não descreva Maester como incapaz de ler logs. A sua lista predefinida inclui AuditLog.Read.All e ThreatHunting.Read.All; as definições de permissões da Microsoft descrevem leituras de auditoria e consultas de hunting. O ponto mais restrito é que os testes de baseline aqui abordados são asserções de configuração. O seu sucesso não prova que um início de sessão específico tenha sido bloqueado.

Pré-requisitos Entra do ScubaGear

ScubaGear v1.8.0 documenta Global Reader para a avaliação interativa do Entra e estas permissões Graph: Directory.Read.All, Policy.Read.All, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup, RoleManagement.Read.Directory, RoleManagementPolicy.Read.AzureADGroup e User.Read.All. Reveja o processo de consentimento efetivo com o administrador do tenant antes da execução. Pré-requisitos interativos.

Os seus pré-requisitos não interativos listam as permissões por produto. Também explicam que SharePoint e Power Platform precisam de permissões com privilégios de escrita devido a requisitos das APIs, embora ScubaGear não use esses privilégios nas avaliações. Consequentemente, uma avaliação de todos os produtos não deve ser descrita como usando exclusivamente permissões de leitura. Esta distinção também se aplica à revisão das ligações opcionais do Maester a serviços.

Executar os comandos documentados e conservar o seu âmbito

Os comandos seguintes são exemplos da documentação. Não foram executados num tenant para este artigo. Primeiro provisione e reveja o ambiente de avaliação; depois use a documentação correspondente à versão selecionada.

Passo 1: Preparar os testes Maester

O guia de instalação fornece o comando de instalação do Pester:

Install-Module Pester -MinimumVersion 5.7.1 -MaximumVersion 5.7.1 -SkipPublisherCheck -Force -Scope CurrentUser

Instala Maester separadamente:

Install-Module Maester -Scope CurrentUser

Esse comando não fixa a versão do Maester. Determine a versão pretendida antes de o usar para evidências reproduzíveis. A partir do diretório de testes escolhido, o guia instala os testes fornecidos:

Install-MaesterTests

Passo 2: Ligar e avaliar

O exemplo de ligação Graph em Connect-Maester é:

Connect-Maester

A mesma documentação e o helper de scopes versionado apresentam este equivalente direto em Graph. Usa a lista de scopes fornecida pelo módulo Maester instalado:

Connect-MgGraph -Scopes (Get-MtGraphScope)

Estas são formas alternativas de ligação. O exemplo direto em Graph não é motivo para executar ambas. Com os testes disponíveis, o comando de avaliação documentado é:

Invoke-Maester

A referência Invoke-Maester descreve a seleção do caminho dos testes, tags, exclusões e saída do relatório. Registe a seleção usada na sua execução. Também fornece um exemplo explícito de saída HTML:

Invoke-Maester -OutputHtmlFile './test-results/TestResults.html'

Escolha essa variante de relatório quando for adequada. É outra invocação de avaliação, não apenas um comando que muda o nome de um relatório existente. Módulos de serviço ou ligações opcionais em falta podem fazer com que testes sejam ignorados, como explica o guia de instalação.

Passo 3: Escolher deliberadamente os produtos ScubaGear

O guia de execução de v1.8.0 descreve a execução em Windows, as dependências necessárias e a importação de um módulo descarregado no PowerShell 5.1. O seu exemplo literal para todos os produtos é:

Invoke-SCuBA -ProductNames *

Isto ilustra o wildcard documentado; use-o apenas depois de rever os pré-requisitos do âmbito ampliado. Para a recomendação deste guia de avaliar apenas Entra, substitua o wildcard por aad, usando o parâmetro de produto documentado. Essa substituição é uma adaptação do exemplo, não um comando literal do guia de execução. Conserve a seleção de produtos resultante no registo da execução.

Medir o que os resultados efetivamente estabelecem

Maester fornece resultados de testes e exportações de relatórios. ScubaGear fornece um relatório HTML global, relatórios individuais por produto, JSON estruturado e CSV de resultados. O JSON do ScubaGear pode conservar o contexto da execução e a saída do provider, dependendo das opções; ScubaResults.csv é uma exportação de resultados mais restrita. ActionPlan.csv filtra os controlos SHALL que falharam e inclui espaço para explicar as falhas e os prazos de correção. Não é o registo completo da avaliação. Funcionalidades de exportação do Maester, relatórios do ScubaGear.

Recomendamos rever os resultados em filas separadas:

Estas são recomendações de tratamento, não rótulos de resultados inventados para todas as versões das duas ferramentas. Evitam que uma alteração da população avaliada seja confundida com uma melhoria. Uma comparação operacional útil regista quais asserções foram executadas com sucesso, quais não puderam ser executadas e quais requerem outro método.

A baseline SCuBA atual do Entra limita explicitamente a avaliação automatizada das Condições de Acesso Condicional às especificadas nas suas implementações. Também identifica alguns requisitos como manuais. Um resultado automatizado aprovado deixa, portanto, questões sobre condições, exceções e verificação operacional que a asserção não abrange.

Para a investigação complementar, leia Lacunas de Acesso Condicional e evidências de início de sessão. Esse artigo examina a aplicação efetiva das políticas, exclusões e percursos de autenticação. Complementa um relatório de baseline sem transformar testes de configuração numa afirmação sobre todos os inícios de sessão.

Deteção através de avaliações recorrentes e CI

A avaliação recorrente de baseline deteta alterações entre configurações observadas com sucesso. Recomendamos conservar o identificador do tenant, a data e hora, a versão, a revisão dos testes, o âmbito dos produtos, o perfil de permissões, erros, relatórios e exceções de cada execução. Compare elementos equivalentes. Se uma suite ou dependência mudar, identifique primeiro se a diferença vem da configuração do tenant, da lógica dos testes ou da cobertura da recolha.

O guia de monitorização GitHub do Maester documenta a federação de identidades de workload com OIDC, permissões de aplicação, execução agendada e acionamento manual do workflow. O seu exemplo de agendamento executa diariamente às 07:30 UTC. Escolha uma frequência de acordo com as suas necessidades operacionais; o exemplo não estabelece um intervalo de resposta adequado para todos os tenants. -NonInteractive controla o comportamento de apresentação, incluindo suprimir a abertura do browser, e não configura a autenticação. Referência de parâmetros Invoke-Maester.

A documentação de execução do ScubaGear descreve a execução com service principal baseada em certificado para pipelines e tarefas agendadas. Os pré-requisitos versionados devem orientar a configuração das permissões. Recomendamos manter os identificadores da aplicação e as referências dos certificados na configuração da tarefa, gerindo a chave privada efetiva através do processo de credenciais aprovado pela organização. Trate o provisionamento e a manutenção das credenciais como trabalho administrativo separado.

Para qualquer das ferramentas, recomendamos fixar conjuntamente o módulo, os testes, as dependências e a revisão da action de CI. Uma falha da tarefa deve desencadear uma investigação operacional em vez de reutilizar o resultado favorável de ontem como evidência de hoje. Encaminhe regressões de configuração para os seus responsáveis e conserve o motivo de qualquer exceção aceite. Estas são recomendações de fluxo de trabalho; não é alegada aqui qualquer execução de pipeline ou desempenho de resposta.

Um agendamento de avaliação produz observações nos momentos das execuções. Não pode provar que a configuração permaneceu inalterada entre elas. Mantenha a avaliação recorrente a par do processo de monitorização de segurança existente e torne visível para os revisores a data da recolha bem-sucedida mais recente.

Correção: de um teste falhado a uma alteração verificada (Remediation)

Passo 1: Ler Maester MT.1009 com precisão

MT.1009 verifica a existência de uma política de Acesso Condicional que bloqueie outra autenticação legada. A implementação examinada seleciona políticas ativadas, remove políticas que contêm passwordChange e procura uma concessão de bloqueio com tipo de cliente other, aplicações incluídas All e utilizadores incluídos All. Devolve false se nenhuma corresponder. Uma condição de licenciamento Entra Free ou um erro capturado pode, em alternativa, produzir um resultado ignorado.

Se esse teste falhar na sua avaliação, examine os dados correspondentes e confirme que a falha representa o requisito pretendido. A função não prova que não existam exclusões nem que todas as ligações relevantes estejam bloqueadas. A sua implementação é um ponto de partida concreto para a investigação, não um simulador completo de políticas. Conserve a revisão do código-fonte junto da constatação para que alterações posteriores da implementação continuem a ser distinguíveis da correção.

Passo 2: Comparar SCuBA MS.AAD.1.1v1 sem assumir equivalência

MS.AAD.1.1v1 na baseline de v1.8.0 exige bloquear a autenticação legada. As suas instruções de implementação pedem para identificar dependências legadas existentes, visar todos os utilizadores e todos os recursos, selecionar Exchange ActiveSync e Other clients, e conceder Block Access. O teste other do MT.1009, por si só, não representa todas essas instruções. Estes são identificadores Maester e SCuBA, não números de controlos CIS.

Recomendamos abrir um registo de correção com o identificador que falhou, os dados de políticas avaliados, o requisito relevante, o responsável, as dependências afetadas e a alteração proposta. Se um resultado for ignorado, abra primeiro uma investigação dos pré-requisitos. Se for manual, documente o método manual. Nenhum destes exemplos é uma falha observada num tenant avaliado para este artigo.

Passo 3: Validar o impacto antes de aplicar

O guia da Microsoft para bloquear autenticação legada inicia a nova política em report-only, revê o impacto e muda-a para On após a validação. Siga o tratamento documentado das contas de acesso de emergência e qualquer implementação faseada necessária. Identifique dependências legadas legítimas e planeie a sua migração ou uma exceção explicitamente governada antes da aplicação abrangente.

Recomendamos testar percursos de acesso pretendidos representativos e rever as evidências de impacto da política com os seus responsáveis. Registe exatamente quando a aplicação é ativada. Uma política report-only é útil para avaliar o impacto, mas não pode estabelecer que o bloqueio pretendido foi aplicado. Não elimine a etapa de validação apenas para satisfazer uma asserção automatizada que procura o estado ativado.

Passo 4: Executar novamente e agendar a mesma revisão

Após a alteração aprovada, volte a executar os testes Maester relevantes ou a avaliação de produto ScubaGear com a seleção e as versões conservadas. Reveja os novos dados, além do resultado. Anexe ambas as avaliações ao registo de correção e confirme separadamente o comportamento pretendido através do processo documentado de revisão do impacto das políticas e dos inícios de sessão. Referência de execução Maester, execução ScubaGear, procedimento de validação da Microsoft.

Recomendamos acrescentar a asserção resolvida à revisão recorrente, com um responsável pelas regressões e uma validade para as exceções. Se a execução seguinte perder permissões ou ignorar o teste, reabra a questão das evidências. Encerrar um registo de correção deve significar que o requisito definido foi novamente verificado e que a sua validação operacional foi concluída.

Como o EtcSec deteta esta situação

AZ_CIS_BENCHMARK_GAPS do EtcSec é um agregado de configuração que contém quatro verificações independentes. A implementação lida é public/internal/audit/detectors/azure/compliance/standards/cis-benchmark-gaps.go, com Detect() a começar na linha 68. Cada condição contabilizada acrescenta uma unidade; Count varia de 0 a 4. Não é uma percentagem nem o CIS Microsoft 365 Foundations Benchmark completo.

Estas condições estão visíveis no mesmo ficheiro nas linhas 82–178. O aviso AZURE_CONDITIONAL_ACCESS_POLICIES_FAILED suprime as três verificações baseadas em políticas. Dados de tenant em falta podem deixar a verificação de Security Defaults por contabilizar. Sem esse aviso, uma coleção de políticas vazia contabiliza as três ausências de políticas. Assim, Count = 0 não prova que as quatro condições tenham sido avaliadas com sucesso.

A função devolve a sua constatação mesmo a zero; uma contagem positiva e IncludeDetails regem a anexação dos detalhes das lacunas. Lê a configuração e os avisos da recolha, sem consumir resultados Maester, relatórios ScubaGear ou evidências de início de sessão. Use-a para acompanhar estas quatro condições ao longo das auditorias EtcSec e depois investigue o seu âmbito. Mantenha a avaliação completa de baseline e a validação operacional da aplicação como partes distintas da revisão.