Pruebas de seguridad Entra ID Maester ScubaGear: guía

¿Qué son las pruebas de seguridad Entra ID Maester ScubaGear?

Las pruebas de seguridad Entra ID Maester ScubaGear convierten la revisión de la configuración de seguridad en una evaluación repetible: elegir aserciones documentadas, recopilar la configuración del tenant, evaluarla y conservar los resultados. Maester ofrece automatización de pruebas con PowerShell; ScubaGear evalúa la configuración de Microsoft 365 frente a las líneas base CISA SCuBA. Su valor reside en una revisión que puede repetirse después de un cambio, conservando el alcance y las evidencias.

Un resultado de línea base responde a una pregunta acotada. Puede establecer que una aserción coincidió con la configuración disponible para la evaluación. No establece que todas las rutas de autenticación estén protegidas ni que no se haya producido ningún ataque contra las identidades. El flujo siguiente separa la medición de la configuración, la investigación de los resultados, la remediación controlada y la verificación posterior. Incluye comandos documentados e identificadores de pruebas reales, sin presentar un ejemplo como una evaluación de tenant que hayamos realizado.

Para las preguntas de cobertura de políticas que preceden a la selección de herramientas, consulte las brechas de cobertura de políticas base de acceso condicional en Entra ID. Ese artículo examina la existencia de políticas para administradores, usuarios, recursos y dispositivos. Esta guía se centra en hacer repetible una evaluación e interpretar sus resultados.

Cómo funcionan las herramientas: pruebas Pester y evaluación de políticas SCuBA

Maester y sus distintas suites de pruebas

Maester es un framework PowerShell de código abierto para mantener la configuración de seguridad mediante pruebas automatizadas. Su repositorio documenta pruebas Pester personalizadas, exportaciones de resultados e integraciones con pipelines. Pester proporciona el modelo de ejecución de las pruebas; Maester añade pruebas de seguridad e informes sobre ese modelo. El framework se puede ampliar, por lo que debe registrar las pruebas realmente instaladas en lugar de tratar el nombre del producto como una declaración fija de cobertura. README del repositorio Maester.

Las suites tienen distintos orígenes. La suite Maester contiene pruebas comunitarias de configuración de seguridad. La suite EIDSCA se basa en Entra ID Security Config Analyzer y comprueba mitigaciones de escenarios de ataque contra identidades. La suite CISA prueba la configuración de Microsoft 365 frente a las directrices SCuBA. Conserve la suite y el identificador de la prueba junto a cada resultado para que el lector pueda distinguir sus fuentes.

Las pruebas CISA de Maester no establecen que Maester ejecute el motor OPA de ScubaGear. Compartir directrices de línea base tampoco establece que las implementaciones sean idénticas. Al comparar hallazgos, utilice el requisito, la implementación de la prueba y la versión revisada. Dos pruebas con nombres similares pueden inspeccionar condiciones diferentes, como muestran los ejemplos de autenticación heredada siguientes.

ScubaGear y las líneas base por producto

ScubaGear pertenece al proyecto Secure Cloud Business Applications de CISA. Su evaluación documentada separa recopilación y evaluación: PowerShell consulta las API de Microsoft 365, Open Policy Agent evalúa la configuración recopilada frente a políticas Rego y la herramienta genera resultados HTML, JSON y CSV. El documento de línea base describe la expectativa de seguridad; su implementación automatizada determina qué puede medir la ejecución. README de ScubaGear.

El repositorio proporciona documentos de línea base separados para Entra ID, la suite de productos de seguridad, Exchange Online, Power BI, Power Platform, SharePoint y Teams. La presencia de un documento de línea base no prueba que cada versión pueda ejecutar todas las evaluaciones de productos. En particular, la tabla de parámetros de v1.8.0 identifica Entra ID como aad y enumera los selectores de productos aceptados. Compruebe esa tabla antes de seleccionar un producto. README versionado, parámetros v1.8.0.

Para trabajos centrados en Entra, recomendamos comenzar con el selector aad y revisar sus requisitos previos. Amplíe a otros productos cuando las conexiones necesarias, los roles y los responsables de las evidencias estén preparados. Es una recomendación operativa, y no una afirmación de que el resto de Microsoft 365 se evalúe únicamente mediante Graph.

Separar las versiones de la documentación en evolución

Las referencias de versiones comprobadas el 3 de octubre de 2026 para esta guía son Maester 2.2.0 y ScubaGear v1.8.0. En esa fecha de revisión, el README main de ScubaGear ya trata v2.0.0. Por tanto, esta guía identifica explícitamente las referencias de ejecución y permisos de v1.8.0; las afirmaciones sobre la documentación de líneas base en evolución se citan por separado. Antes de adoptar estos ejemplos, fije la versión del módulo, las versiones de las dependencias y la revisión de las pruebas como especificación de la evaluación.

Preparar el acceso de lectura a Graph antes de una evaluación

El acceso de lectura tiene dos dimensiones: qué hace la herramienta y qué está autorizada a hacer su identidad. Microsoft Graph distingue el acceso delegado, en nombre de un usuario que ha iniciado sesión, del acceso de aplicación sin ese usuario. El consentimiento y los roles de directorio compatibles siguen siendo relevantes. Crear una aplicación, otorgar consentimiento o configurar la autenticación es preparación administrativa; debe distinguirse de las posteriores lecturas de configuración. Referencia de permisos Graph, autenticación de Graph PowerShell.

Por ejemplo, listar las políticas de acceso condicional es una operación de lectura de Graph cuyo permiso documentado es Policy.Read.All. El requisito de ese endpoint no es evidencia suficiente para conceder acceso a toda una suite de evaluación: otras pruebas leen otros recursos. List conditionalAccessPolicies.

Ámbitos predeterminados de Maester

El código fuente de Get-MtGraphScope 2.2.0 define los ámbitos de lectura predeterminados, incluidos los accesos a directorio, políticas, auditoría, informes, gestión de dispositivos, riesgo de identidad y métodos de autenticación. Esta es la lista del framework, no el mínimo para una sola prueba de acceso condicional. Directory.Read.All, por ejemplo, es más amplio que leer únicamente la colección de políticas.

El mismo código separa las adiciones opcionales: -Privileged añade ReportSettings.ReadWrite.All, -SendMail añade Mail.Send y -SendTeamsMessage añade ChannelMessage.Send. Mantenga esas adiciones fuera de una evaluación Graph de lectura predeterminada salvo que un requisito revisado por separado las necesite. Connect-Maester explica las conexiones opcionales y el comportamiento de los ámbitos privilegiados.

No describa Maester como incapaz de leer registros. Su lista predeterminada incluye AuditLog.Read.All y ThreatHunting.Read.All; las definiciones de permisos de Microsoft describen las lecturas de auditoría y las consultas de búsqueda de amenazas. El punto más concreto es que las pruebas de línea base aquí tratadas son aserciones de configuración. Su éxito no prueba que se haya bloqueado un inicio de sesión determinado.

Requisitos previos de Entra para ScubaGear

ScubaGear v1.8.0 documenta Global Reader para la evaluación interactiva de Entra y estos permisos Graph: Directory.Read.All, Policy.Read.All, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup, RoleManagement.Read.Directory, RoleManagementPolicy.Read.AzureADGroup y User.Read.All. Revise el proceso real de consentimiento con el administrador del tenant antes de ejecutar. Requisitos previos interactivos.

Sus requisitos previos no interactivos enumeran permisos por producto. También explican que SharePoint y Power Platform necesitan permisos con privilegios de escritura debido a los requisitos de sus API, aunque ScubaGear no usa esos privilegios para las evaluaciones. En consecuencia, una evaluación de todos los productos no debe describirse como realizada exclusivamente con permisos de lectura. Esta distinción también se aplica al revisar las conexiones de servicio opcionales de Maester.

Ejecutar los comandos documentados y conservar su alcance

Los comandos siguientes son ejemplos de la documentación. No se ejecutaron contra un tenant para este artículo. Prepare y revise primero el entorno de evaluación; después utilice la documentación correspondiente a la versión seleccionada.

Paso 1: preparar las pruebas Maester

La guía de instalación proporciona el comando de instalación de Pester:

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

Instala Maester por separado:

Install-Module Maester -Scope CurrentUser

Ese comando no fija la versión de Maester. Determine la versión prevista antes de utilizarlo para obtener evidencias reproducibles. Desde el directorio de pruebas elegido, la guía instala las pruebas suministradas:

Install-MaesterTests

Paso 2: conectar y evaluar

El ejemplo de conexión Graph de Connect-Maester es:

Connect-Maester

La misma documentación y el asistente de ámbitos versionado proporcionan este equivalente Graph directo. Utiliza la lista de ámbitos que suministra el módulo Maester instalado:

Connect-MgGraph -Scopes (Get-MtGraphScope)

Son enfoques alternativos de conexión. El ejemplo Graph directo no es motivo para ejecutar ambos. Con las pruebas disponibles, el comando de evaluación documentado es:

Invoke-Maester

La referencia Invoke-Maester describe la selección de rutas de pruebas, etiquetas, exclusiones y salida de informes. Registre la selección utilizada en su ejecución. También ofrece un ejemplo explícito de salida HTML:

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

Elija esa variante de informe cuando corresponda. Es otra invocación de la evaluación, no simplemente un comando que cambia el nombre de un informe existente. La falta de módulos o conexiones de servicio opcionales puede hacer que se omitan pruebas, como explica la guía de instalación.

Paso 3: elegir deliberadamente los productos ScubaGear

La guía de ejecución v1.8.0 describe la ejecución en Windows, las dependencias necesarias y la importación de un módulo descargado en PowerShell 5.1. Su ejemplo literal para todos los productos es:

Invoke-SCuBA -ProductNames *

Esto ilustra el comodín documentado; úselo solo después de revisar los requisitos previos del alcance ampliado. Para la recomendación de esta guía limitada a Entra, sustituya el comodín por aad, usando el parámetro de producto documentado. Esa sustitución adapta el ejemplo; no es un comando literal de la guía de ejecución. Conserve la selección de productos resultante en el registro de ejecución.

Medir lo que realmente establecen los resultados

Maester proporciona resultados de pruebas y exportaciones de informes. ScubaGear proporciona un informe HTML global, informes individuales de productos, JSON estructurado y CSV de resultados. El JSON de ScubaGear puede conservar el contexto de ejecución y la salida del proveedor, según sus opciones; ScubaResults.csv es una exportación de resultados más limitada. Su ActionPlan.csv filtra controles SHALL fallidos e incluye espacio para explicar los fallos y los plazos de remediación. No es el registro completo de la evaluación. Funciones de exportación de Maester, informes ScubaGear.

Recomendamos revisar los resultados en colas separadas:

Son recomendaciones de tratamiento, no etiquetas de resultados inventadas para todas las versiones de cualquiera de las herramientas. Evitan confundir un cambio en la población evaluada con una mejora. Una comparación operativa útil registra qué aserciones se ejecutaron con éxito, cuáles no pudieron ejecutarse y cuáles requieren otro método.

La línea base Entra SCuBA actual limita explícitamente la evaluación automatizada de las condiciones de acceso condicional a las especificadas en sus implementaciones. También marca algunos requisitos como manuales. Por tanto, un resultado automatizado favorable deja abiertas preguntas sobre condiciones, excepciones y verificación operativa que la aserción no cubre.

Para la investigación complementaria, lea las brechas de acceso condicional y las evidencias de inicio de sesión. Ese artículo examina la aplicación real de las políticas, las exclusiones y las rutas de autenticación. Complementa un informe de línea base sin convertir las pruebas de configuración en una afirmación sobre cada inicio de sesión.

Detección mediante evaluaciones recurrentes y CI

La evaluación recurrente de líneas base detecta cambios entre configuraciones observadas correctamente. Recomendamos conservar el identificador del tenant, la marca temporal, la versión, la revisión de las pruebas, el alcance de productos, el perfil de permisos, los errores, los informes y las excepciones de cada ejecución. Compare elementos equivalentes. Si cambia una suite o una dependencia, identifique primero si la diferencia procede de la configuración del tenant, la lógica de pruebas o la cobertura de recopilación.

La guía de monitorización con GitHub de Maester documenta la federación de identidades de cargas de trabajo con OIDC, los permisos de aplicación, la ejecución programada y el lanzamiento manual de workflows. Su ejemplo de programación se ejecuta diariamente a las 07:30 UTC. Elija una frecuencia acorde con sus necesidades operativas; el ejemplo no establece un intervalo de respuesta adecuado para todos los tenants. -NonInteractive controla la presentación, incluida la supresión de la apertura del navegador, y no configura la autenticación. Referencia de parámetros Invoke-Maester.

La documentación de ejecución de ScubaGear describe la ejecución mediante un principal de servicio con certificado para pipelines y trabajos programados. Los requisitos previos versionados deben regir la configuración de permisos. Recomendamos mantener los identificadores de aplicación y las referencias de certificados en la configuración del trabajo, gestionando la clave privada real mediante el proceso de credenciales aprobado por la organización. Trate el aprovisionamiento y el mantenimiento de credenciales como tareas administrativas separadas.

Para ambas herramientas, recomendamos fijar conjuntamente el módulo, las pruebas, las dependencias y la revisión de la acción CI. Un fallo del trabajo debe iniciar una investigación operativa en lugar de reutilizar el resultado favorable de ayer como evidencia de hoy. Dirija las regresiones de configuración a sus responsables y conserve el motivo de toda excepción aceptada. Son recomendaciones de flujo de trabajo; no se afirma aquí ninguna ejecución de pipelines ni rendimiento de respuesta.

Una programación de evaluaciones produce observaciones en los momentos de ejecución. No puede probar que la configuración permaneciera sin cambios entre ellos. Mantenga la evaluación recurrente junto al proceso existente de monitorización de seguridad y haga visible a los revisores la fecha de la recopilación correcta más reciente.

Remediación: de una prueba fallida a un cambio verificado (Remediation)

Paso 1: leer Maester MT.1009 con precisión

MT.1009 comprueba si existe una política de acceso condicional que bloquea otras autenticaciones heredadas. La implementación inspeccionada selecciona políticas habilitadas, elimina las que contienen passwordChange y busca una concesión de bloqueo con tipo de cliente other, aplicaciones incluidas All y usuarios incluidos All. Devuelve false si ninguna coincide. Una condición de licencia Entra Free o un error capturado puede producir en su lugar un resultado omitido.

Si esa prueba falla en su evaluación, inspeccione los datos seleccionados y confirme que el fallo representa el requisito previsto. La función no prueba que no existan exclusiones ni que se bloqueen todas las conexiones pertinentes. Su implementación es un punto de partida concreto para investigar, no un simulador completo de políticas. Conserve la revisión del código fuente con el hallazgo para distinguir los cambios posteriores de implementación de la remediación.

Paso 2: comparar SCuBA MS.AAD.1.1v1 sin asumir equivalencia

MS.AAD.1.1v1 en la línea base v1.8.0 exige bloquear la autenticación heredada. Sus instrucciones de implementación requieren identificar las dependencias heredadas existentes, dirigirse a todos los usuarios y todos los recursos, seleccionar Exchange ActiveSync y Other clients y conceder Block Access. El test other de MT.1009 por sí solo no representa todas esas instrucciones. Son identificadores de Maester y SCuBA, no números de controles CIS.

Recomendamos abrir un registro de remediación con el identificador fallido, los datos de política evaluados, el requisito pertinente, el responsable, las dependencias afectadas y el cambio propuesto. Si se omite un resultado, abra primero una investigación de requisitos previos. Si es manual, documente el método manual. Ninguno de estos ejemplos es un fallo observado en un tenant evaluado para este artículo.

Paso 3: validar el impacto antes de aplicar

La guía de Microsoft para bloquear la autenticación heredada inicia la nueva política en report-only, revisa el impacto y la pasa a On tras la validación. Siga el tratamiento documentado de las cuentas de acceso de emergencia y cualquier despliegue gradual necesario. Identifique las dependencias heredadas legítimas y planifique su migración o una excepción explícitamente gobernada antes de una aplicación generalizada.

Recomendamos probar rutas representativas del acceso previsto y revisar las evidencias de impacto de la política con sus responsables. Registre exactamente cuándo se habilita la aplicación. Una política report-only es útil para evaluar el impacto, pero no puede establecer que el bloqueo previsto se haya aplicado. No elimine la validación únicamente para satisfacer una aserción automatizada que busca el estado habilitado.

Paso 4: volver a ejecutar y programar la misma revisión

Después del cambio aprobado, vuelva a ejecutar las pruebas Maester pertinentes o la evaluación del producto ScubaGear con la selección y las versiones conservadas. Revise los datos nuevos además del resultado. Adjunte ambas evaluaciones al registro de remediación y confirme por separado el comportamiento previsto mediante el proceso documentado de revisión del impacto de políticas y de los inicios de sesión. Referencia de ejecución Maester, ejecución ScubaGear, procedimiento de validación Microsoft.

Recomendamos añadir la aserción resuelta a la revisión recurrente, con un responsable para las regresiones y una caducidad para las excepciones. Si la siguiente ejecución pierde permisos u omite la prueba, reabra la cuestión de las evidencias. Cerrar un registro de remediación debe significar que se volvió a comprobar el requisito definido y se completó su validación operativa.

Cómo detecta EtcSec estas brechas

AZ_CIS_BENCHMARK_GAPS de EtcSec es un agregado de configuración que contiene cuatro comprobaciones independientes. La implementación leída es public/internal/audit/detectors/azure/compliance/standards/cis-benchmark-gaps.go, con Detect() comenzando en la línea 68. Cada condición contabilizada suma uno; Count va de 0 a 4. No es un porcentaje ni el CIS Microsoft 365 Foundations Benchmark completo.

Estas condiciones aparecen en el mismo archivo en las líneas 82–178. La advertencia AZURE_CONDITIONAL_ACCESS_POLICIES_FAILED suprime las tres comprobaciones basadas en políticas. La falta de datos del tenant puede dejar sin contar la comprobación Security Defaults. Sin esa advertencia, una colección de políticas vacía contabiliza las tres ausencias de políticas. Por tanto, Count = 0 no prueba que las cuatro condiciones se hayan evaluado correctamente.

La función devuelve su hallazgo incluso con cero; un recuento positivo e IncludeDetails gobiernan la inclusión de los detalles de las brechas. Lee configuración y advertencias de recopilación, sin consumir resultados Maester, informes ScubaGear ni evidencias de inicio de sesión. Úsela para seguir estas cuatro condiciones en las auditorías EtcSec e investigar después su alcance. Mantenga la evaluación completa de líneas base y la validación operativa de la aplicación como partes distintas de la revisión.