Acceso Condicional en report-only: cómo validar una política antes de activarla

1. Qué demuestra el modo report-only

Report-only evalúa una política durante los inicios de sesión, pero no impone sus controles de concesión y sesión. Por tanto, un usuario que accede correctamente no demuestra que pudiera trabajar igual después de activar esa política. El acceso actual puede estar permitido por la configuración vigente mientras la propuesta exigiría un requisito adicional.

La distinción importa especialmente cuando el objetivo es exigir una autenticación concreta, un dispositivo conforme o limitar determinados accesos. El informe permite formular una hipótesis sobre el impacto; la prueba operativa debe confirmar si el usuario dispone del método o dispositivo necesario y puede completar su tarea.

No sustituya una política activa por report-only para hacer pruebas. Ese cambio dejaría de aplicar su protección. Cuando necesite revisar un control existente, conserve la configuración que protege el entorno y documente una propuesta separada, con un nombre que identifique su propósito y su versión. El procedimiento de cambio deberá decidir posteriormente qué configuración se mantiene.

Esta guía complementa las diez políticas base de Acceso Condicional: aquí el problema es decidir si un cambio concreto está listo para producción, no volver a definir toda la estrategia de identidad.

2. Preparar alcance, permisos y licencias

Antes de abrir el portal, escriba una frase verificable: «Los usuarios del grupo piloto que accedan al recurso seleccionado desde los clientes incluidos deberán satisfacer este control». Identifique también quién queda fuera y por qué. Si el equipo no puede describir la condición y el resultado esperado, todavía no tiene una prueba que ejecutar.

Compruebe el derecho de uso de Acceso Condicional en su suscripción. Microsoft Entra ID P1 cubre su uso general; funciones asociadas al riesgo pueden necesitar P2. El workbook de información y generación de informes requiere además los componentes de Azure Monitor y Log Analytics descritos por Microsoft. Su disponibilidad no se deduce simplemente de que exista una licencia Microsoft 365.

Separe las responsabilidades. Quien configura políticas necesita el rol apropiado, como Conditional Access Administrator; quien interpreta registros debe disponer de acceso suficiente a los registros y a las políticas. No asigne Global Administrator solo para facilitar una revisión. Si faltan detalles en el portal, confirme los permisos antes de concluir que no hubo evaluación.

Registre el identificador de la política, sus grupos, recursos, condiciones, controles y exclusiones. Incluya el responsable funcional de la aplicación y el contacto de soporte. Este inventario breve evita discutir posteriormente sobre una captura que pertenece a otra versión del cambio.

Las cuentas de emergencia deben seguir el diseño de acceso de emergencia del tenant y contar con supervisión. Revise cualquier exclusión con nombre, justificación y responsable. Una exclusión indefinida de departamentos completos no es un criterio de éxito: es una parte del alcance que sigue sin resolver.

3. Interpretar resultados sin confundirlos con disponibilidad

Lea el resultado de la política concreta dentro del evento. El estado general del inicio de sesión y el resultado de report-only responden a preguntas distintas. Un inicio correcto puede coexistir con una evaluación que detecta un control pendiente, y un inicio fallido puede deberse a otra política activa.

No agregue estas categorías como si fueran una tasa de disponibilidad contractual. Un mismo usuario puede aparecer en resultados diferentes a lo largo del período observado. Defina si está contando usuarios únicos, eventos o procesos de negocio, y mantenga esa unidad en todo el informe.

Un «Not applied» merece atención cuando la política debería cubrir ese caso. Puede revelar un grupo incorrecto, un recurso distinto o un supuesto de red que no se cumple. En cambio, que una cuenta excluida tenga ese resultado puede ser la evidencia exacta que se buscaba. El valor depende de la matriz esperada.

También evite interpretar «Success» como «la persona ha completado una autenticación nueva». La evaluación puede utilizar información de la sesión existente. Si el cambio busca modificar la experiencia de autenticación, debe comprobarse esa experiencia de forma controlada, sin extraer conclusiones de un único acceso repetido.

4. Construir una matriz pequeña que represente el trabajo real

Una matriz útil combina personas, aplicaciones y condiciones que cambian la decisión de seguridad. No necesita enumerar todas las combinaciones posibles. Empiece por los procesos críticos, las excepciones conocidas y los equipos que suelen abrir incidencias al cambiar la autenticación.

• Identidad: empleado habitual, administrador dedicado, invitado cuando esté dentro del alcance y cuenta excluida justificada.
• Dispositivo: equipo gestionado conforme, equipo gestionado no conforme y dispositivo no gestionado cuando el diseño contemple ese acceso.
• Cliente: navegador y aplicaciones de escritorio o móviles realmente utilizadas.
• Recurso: aplicación solicitada y recursos relacionados que utiliza para completar la tarea.
• Situación: acceso habitual, sesión nueva y escenario de recuperación del usuario.

Para cada fila, anote el resultado esperado, el motivo y el responsable de ejecutarla. Defina una tarea concreta: abrir un documento compartido, acceder al portal administrativo o utilizar una función de la aplicación. «Entrar en Microsoft 365» es demasiado amplio para validar un proceso que depende de varios recursos.

What If ayuda a comprobar qué políticas afectan a las condiciones seleccionadas. Úselo como revisión de diseño y para casos difíciles de reproducir. Microsoft indica que no prueba las dependencias de servicio; una simulación de Teams, por ejemplo, no sustituye la comprobación del acceso al recurso dependiente.

Conserve la salida de What If junto con los registros reales cuando ambos aporten información. Si difieren, investigue los parámetros introducidos, la versión de la política y el recurso realmente solicitado. No ajuste la matriz retrospectivamente para que todos los casos parezcan aprobados.

5. Recoger evidencias que permitan decidir

En Microsoft Entra, abra los registros de inicio de sesión y seleccione un evento representativo. Revise usuario, hora, aplicación, recurso, cliente y detalles de Acceso Condicional. Localice la política propuesta en su evaluación report-only y compare sus condiciones con la matriz.

La navegación y las etiquetas del portal pueden evolucionar. Lo relevante es conservar una referencia trazable al evento y al identificador de la política, no una captura genérica de la pantalla principal. Registre las horas con zona horaria y evite mezclar ventanas temporales entre informes.

Si utiliza el workbook, filtre por las políticas y el período que corresponde al cambio. Compruebe que la integración de registros ya estaba funcionando durante esa ventana. Una gráfica sin datos no prueba que no exista impacto: puede significar que no se ha recogido todavía la información necesaria.

El registro de aceptación debe contener, como mínimo, caso de prueba, resultado esperado, evento observado, resultado real, causa de discrepancia y decisión. Limite el acceso a estas evidencias: los registros de identidad pueden contener datos personales y detalles internos que no deben copiarse a un informe público.

Busque patrones además de casos individuales. Si un cliente móvil concentra los requisitos pendientes, revise su preparación antes de ampliar el grupo. Si un recurso dependiente produce un comportamiento diferente, involucre a su propietario. Una captura favorable de un administrador no representa a usuarios con dispositivos y tareas distintas.

La ventana de observación debe incluir los ciclos relevantes para el negocio. MSAdvance recomienda explicitar qué procesos periódicos no se han visto y asignarles una prueba adicional. No existe una duración universal que convierta automáticamente una simulación en un despliegue seguro.

6. Pasar del informe a un piloto con aplicación efectiva

Cuando las discrepancias estén explicadas, prepare un grupo pequeño y representativo para aplicar el cambio. Asegure que sus usuarios conocen el requisito, tienen el método o dispositivo preparado y saben dónde pedir ayuda. La selección debe cubrir los casos importantes, no limitarse a los miembros del equipo técnico.

Compruebe antes que el alcance del piloto no altera involuntariamente las protecciones existentes. Documente la relación entre la propuesta y las políticas activas. Revise los cambios con una segunda persona autorizada cuando su proceso de gestión lo contemple; esta recomendación no implica que un revisor concreto haya validado este artículo.

Durante el piloto, ejecute las tareas de la matriz y observe tanto accesos permitidos como rechazos previstos. Un rechazo correcto también debe tener una explicación útil para soporte. Registre las incidencias por causa y proceso afectado, evitando que varios intentos repetidos de una persona se interpreten como usuarios independientes.

Criterios de aceptación propuestos

• Las filas críticas de la matriz tienen evidencia y responsable de aceptación.
• Los bloqueos previstos se producen en el alcance correcto.
• Los procesos permitidos funcionan con los métodos aprobados.
• Las exclusiones tienen propietario, motivo y fecha de revisión.
• Soporte dispone de diagnóstico y recuperación probados.
• Las discrepancias pendientes tienen una decisión explícita antes de ampliar.

Estos criterios son una propuesta operativa de MSAdvance. Adáptelos a la criticidad del servicio y a sus obligaciones internas. No anuncie «cero impacto» cuando solo haya observado una parte de los clientes o cuando algún proceso mensual siga sin probarse.

Reversión concreta

Defina qué cambio del piloto se revertiría, quién puede hacerlo y cómo se confirmaría el resultado. Conserve la configuración previa y sus identificadores. La reversión debe corregir el cambio problemático dentro del alcance acordado; desactivar indiscriminadamente Acceso Condicional puede introducir un riesgo mayor que la incidencia inicial.

Tras ampliar, mantenga la observación de las políticas activas y cierre las excepciones temporales conforme al plan. El éxito de la primera mañana no elimina la necesidad de revisar clientes menos frecuentes, altas de usuarios y renovaciones de equipos.

7. Ejemplo hipotético: acceso desde dispositivos gestionados

Una empresa quiere exigir dispositivos conformes para un recurso utilizado por personal de oficina y comerciales. Conserva su protección actual y prepara una política de evaluación para un grupo piloto. La matriz incluye navegador corporativo, aplicación móvil y un acceso externo que debería rechazarse.

Los resultados muestran accesos de oficina satisfechos y varios dispositivos móviles con requisitos pendientes. El equipo no interpreta esos eventos como errores del producto ni los elimina del informe: comprueba la inscripción, la conformidad y el cliente utilizados. Además, detecta una fila sin eventos porque la tarea solo se ejecuta al cierre de mes.

La decisión es aplazar esa parte de la ampliación, completar la preparación móvil y ejecutar una prueba controlada del proceso periódico. Después, el piloto activo confirma las tareas permitidas y el rechazo esperado del dispositivo no gestionado. El acta recoge qué se aprobó y qué permanece fuera.

El ejemplo no describe un proyecto real ni resultados medidos de MSAdvance. Ilustra por qué el dato técnico necesita contexto de negocio: una mayoría de eventos favorables puede coexistir con un proceso crítico que todavía no tiene evidencia.

8. Errores que invalidan la conclusión

Los fallos más habituales son observar solo el estado global del inicio de sesión, sumar usuarios y eventos sin distinguirlos, dejar que las exclusiones crezcan sin revisión y usar What If como sustituto de una prueba real. También resulta arriesgado cambiar varias políticas simultáneamente: después cuesta identificar qué modificación causó la incidencia.

Si su tenant necesita ordenar previamente políticas superpuestas, una revisión de seguridad de Microsoft 365 y Azure puede concretar el alcance y las responsabilidades del despliegue. El objetivo comercial debe ser una validación defendible, no prometer que cualquier configuración se activará sin incidencias.

Fuentes oficiales y límites

• Microsoft Learn: evaluación de políticas en report-only.
• Microsoft Learn: herramienta What If y sus limitaciones.
• Microsoft Learn: workbook de información e informes.
• Microsoft Learn: políticas aplicadas en los registros.
• Microsoft Learn: exigir conformidad de dispositivos.

Compruebe licencias, permisos y opciones actuales en su tenant antes de implementar. Esta guía no evalúa su entorno ni sustituye la aprobación interna de cambios.