Condiciones de uso Entra: aceptación mediante Conditional Access

Qué exigen realmente las condiciones de uso Entra

Las condiciones de uso Entra presentan un documento durante un inicio de sesión interactivo y pueden hacer de su aceptación una condición de acceso. La pregunta útil es si las personas previstas deben aceptar el documento aprobado antes de acceder a la aplicación prevista. Encontrar un PDF en el tenant solo responde a una parte de esa pregunta.

Parta de una necesidad de negocio: ¿quién debe reconocer qué reglas, para qué recursos y quién es responsable del texto? Pida a los responsables de negocio y jurídicos adecuados que aprueben el documento antes de configurar su aplicación. La ausencia de un acuerdo es una señal de configuración que investigar, no la prueba de una infracción normativa universal. Algunos tenants pueden no tener un caso de uso justificado para esta función; registre esa decisión en lugar de crear un acuerdo vacío para eliminar un hallazgo.

Un piloto práctico podría abarcar un espacio de trabajo de un socio cuyo responsable quiere que los colaboradores externos reconozcan sus reglas de tratamiento de datos. Defina explícitamente la población y la aplicación. No suponga que todas las vías de uso compartido externo crean una cuenta de invitado Entra o pasan por el mismo recorrido de inicio de sesión. Utilice la revisión de Conditional Access para invitados y de colaboración externa para delimitar esa población y sus exclusiones antes de añadir la aceptación del documento.

El despliegue debe aportar pruebas para tres preguntas distintas: ¿existe el acuerdo, una directiva que lo impone lo exige para la población y el recurso elegidos, y las respuestas de los usuarios muestran que el documento esperado se aceptó o se rechazó? Mantenga esas respuestas separadas en el registro del cambio.

Cómo se relacionan el acuerdo y Conditional Access

La guía de configuración de condiciones de uso de Microsoft exige una licencia Entra ID P1 y un PDF. Indica Security Reader como rol mínimo para leer la configuración y Conditional Access Administrator para crearla o modificarla. Confirme la suscripción y la asignación del administrador antes de programar el piloto.

El acuerdo contiene los ajustes del documento; un control de concesión de Conditional Access lo vincula con las decisiones de acceso. Las decisiones sobre idiomas y versiones también forman parte del diseño. Un acuerdo que existe sin estar vinculado a la directiva prevista puede satisfacer una comprobación de existencia mientras la necesidad de negocio sigue sin cumplirse.

El recurso agreement de Graph expone un identificador, requisitos de visualización y por dispositivo, un calendario de expiración y una duración de nueva aceptación por usuario. Su relación file identifica el PDF predeterminado; files se documenta como en proceso de desuso en favor de file. La relación acceptances es una colección independiente de respuestas de los usuarios.

Utilice estas distinciones al planificar las pruebas. Mantenga juntos el ID del acuerdo y la versión aprobada del PDF, y después registre la directiva que exige ese acuerdo. Un nombre para mostrar es cómodo para las personas, pero el identificador es una clave de correlación más segura para los registros de configuración y respuesta. Asigne un responsable que mantenga el documento y sus traducciones, y un responsable de la directiva que mantenga su alcance. Si uno cambia, revise el otro lado de la relación.

Detección: comprobar por separado la existencia, la vinculación y las respuestas

Inventariar los acuerdos sin confundir una lectura fallida con ausencia

En el centro de administración de Entra, abra Entra ID > Conditional Access > Terms of use. Identifique el acuerdo previsto para el escenario de negocio, los idiomas del documento y su historial de versiones. Si la página está vacía, compruebe que examina el tenant correcto con un rol de lectura adecuado antes de registrar una ausencia.

Para un inventario independiente mediante API, Microsoft documenta esta solicitud en List agreements:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements
Authorization: Bearer {token}

Se trata de una plantilla de solicitud documentada, no de una consulta ejecutada contra un tenant de un cliente para este artículo. La página indica el permiso delegado Agreement.Read.All para cuentas profesionales o educativas, con Security Reader como rol admitido con menos privilegios. Indica que los permisos de aplicación no se admiten para esta operación. Compruebe el modelo de permisos actual del cliente utilizado en lugar de suponer que un token de aplicación y uno delegado proporcionan una cobertura equivalente.

Trate un error de autorización, una recopilación interrumpida o una respuesta ilegible como una observación sin resolver. Solo un inventario satisfactorio y completo permite concluir que no se devolvieron acuerdos. Conserve el contexto del tenant, la hora de recopilación y cualquier error junto con el resultado.

Examinar la directiva que debe exigir el acuerdo

Abra la directiva de Conditional Access pertinente y examine su estado, los usuarios o grupos incluidos, las exclusiones, los recursos de destino y los controles de concesión. Confirme que el acuerdo previsto está seleccionado en Grant access, con el requisito Require terms of use. Compruebe la combinación de controles de concesión para que la decisión de acceso prevista exija realmente la aceptación.

El nombre de una directiva que menciona condiciones de uso no es una prueba suficiente. La configuración Report-only sirve para revisar el impacto, pero la prueba de aplicación debe usar una directiva piloto habilitada. Siga a un usuario de prueba previsto a través de las asignaciones y exclusiones, y después pruebe el inicio de sesión en el recurso. Si el inventario contiene acuerdos pero ninguna directiva prevista los selecciona, registre una carencia de vinculación por separado de la ausencia de acuerdos.

Revisar las pruebas de aceptación de la versión prevista

El portal muestra las respuestas de aceptación y rechazo y el historial de versiones. Para obtener pruebas mediante API, List acceptances documenta:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements/{agreementsId}/acceptances
Authorization: Bearer {token}

Los objetos devueltos son registros agreementAcceptance, comúnmente llamados aceptaciones de acuerdos. La referencia del recurso describe agreementId, agreementFileId, userId, state, recordedDateTime y expirationDateTime. Los estados de respuesta documentados son accepted y declined. Correlacione el usuario, el acuerdo y el archivo en lugar de tratar cualquier aceptación histórica como prueba del documento actual.

Para este endpoint limitado a un acuerdo, la operación de listado documenta el permiso delegado AgreementAcceptance.Read y el permiso superior AgreementAcceptance.Read.All, con Security Reader como rol admitido con menos privilegios. Indica que los permisos de aplicación no se admiten. Trate las exportaciones de aceptación como datos de usuario, limite el acceso a quienes necesitan revisarlas y siga las reglas de conservación de su organización. La exportación sirve para respaldar el piloto, no para crear una copia sin restricciones de la actividad de los usuarios.

Remediación: desplegar un acuerdo aprobado mediante un piloto acotado (Remediation)

1. Aprobar el texto y definir el requisito de aceptación

Registre el responsable del recurso, el responsable del documento, los usuarios previstos, los idiomas necesarios, las excepciones y el comportamiento esperado de nueva aceptación. Determine si una versión actualizada exige una nueva respuesta. Proporcione al personal de soporte un contacto para las preguntas sobre las condiciones y otro distinto para los problemas de inicio de sesión. Hágalo antes de cargar el PDF, para que un cambio de autenticación no se convierta en un ejercicio improvisado de redacción de reglas.

2. Crear el acuerdo y verificar su presentación

Utilice Conditional Access > Terms of use > New terms. Cargue el PDF finalizado, elija su idioma y el título que verán los usuarios, y configure Require users to expand the terms of use cuando la experiencia aprobada exija abrir el documento antes de aceptarlo. Añada las variantes lingüísticas aprobadas y revise lo que ve un usuario previsto. Registre el ID del acuerdo y qué PDF se cargó para cada idioma.

Decida las opciones de expiración y por dispositivo a partir del caso de uso en lugar de activarlas automáticamente. En particular, Learn excluye a los usuarios B2B de la compatibilidad con condiciones de uso por dispositivo. Para un piloto de usuarios externos, distinga el requisito ordinario del acuerdo de esa opción por dispositivo y valide el recorrido real de colaboración.

3. Vincular el acuerdo al control de concesión de Conditional Access previsto

La directiva de ejemplo de Microsoft selecciona las condiciones creadas en Access controls > Grant > Grant access, empieza en Report-only y pasa a On tras revisar el impacto. Su ejemplo se dirige a Microsoft Admin Portals; adapte la asignación de recursos a su escenario aprobado en lugar de copiar ese destino en un piloto de espacio de trabajo que no tenga relación.

Empiece con el grupo piloto y el recurso previstos. Preserve el acceso de recuperación de emergencia y documente las exclusiones. Learn también advierte que las cuentas de servicio no pueden satisfacer este requisito de aceptación interactiva; identifique esas dependencias antes de activar su aplicación. Revise primero el impacto en Report-only y después habilite el piloto para las pruebas interactivas. Una revisión del impacto y una prueba de aceptación obligatoria responden a preguntas diferentes, así que conserve ambas.

4. Probar la aceptación, el rechazo y la vía de recuperación excluida

Utilice identidades de prueba representativas de la población prevista. Para la vía de aceptación, entre en el recurso de destino por su ruta normal de inicio de sesión, compruebe el PDF y el idioma mostrados, expándalo si es necesario, acéptelo y verifique el acceso al recurso. Para la vía de rechazo, utilice una identidad sin aceptación previa y compruebe que rechazar impide el acceso. Mantenga estos resultados como expectativas de prueba hasta que los haya observado y registrado.

Compruebe los registros de aceptación respecto al usuario de prueba y al ID del archivo. Verifique también que la cuenta de recuperación prevista permanece fuera de la directiva piloto. Si un usuario previsto no recibe ninguna solicitud, investigue la aceptación existente, el estado de la sesión, las asignaciones, las exclusiones y el recurso seleccionado en la directiva. No concluya de inmediato que el acuerdo está defectuoso o que el usuario está cubierto correctamente.

5. Mantener las versiones y probar cuándo se exige aceptar de nuevo

Revise Edit terms, actualice el PDF del idioma correspondiente y tome una decisión explícita sobre Require reaccept. Preserve las pruebas anteriores antes de cambiar el documento y después compruebe el registro de respuesta del nuevo archivo. Trate los PDF localizados como versiones gestionadas del mismo mensaje aprobado; un documento inglés revisado debe desencadenar una revisión de sus otras variantes lingüísticas.

Require reaccept no interrumpe al instante una sesión activa. Learn indica que las sesiones existentes deben expirar antes de que se presente el nuevo requisito de aceptación. Planifique la verificación en torno al siguiente inicio de sesión o evaluación de sesión pertinente y registre ese contexto junto con la solicitud observada. La guía de controles de sesión y frecuencia de inicio de sesión explica por qué hay que considerar conjuntamente una directiva de acceso y el momento en que se evalúa una sesión. No prometa un plazo inmediato de nueva aceptación para todo el tenant solo porque se haya actualizado un PDF.

6. Registrar las pruebas y transferir el mantenimiento

Conserve en el registro del cambio la referencia del texto aprobado, los identificadores del acuerdo y la directiva, el alcance, las exclusiones, las versiones PDF y los resultados observados del piloto. Registre los fallos y las vías sin resolver además de los éxitos. Amplíe la directiva solo cuando los responsables acepten las pruebas y las implicaciones para el soporte. Organice una revisión cuando cambien el documento, la población de la aplicación o el modelo de colaboración; el inventario de acuerdos por sí solo no revelará desviaciones en esas relaciones.

Cómo detecta EtcSec esta configuración

El detector AZ_NO_TERMS_OF_USE de etc-collector lee AzureTermsOfUseProbed y AzureTermsOfUseCount. Su implementación Detect() tiene tres ramas:

Count 1 es el recuento del hallazgo; no es un recuento de usuarios que no han aceptado. La rama sin sondeo no es un resultado de ausencia ni un veredicto de cumplimiento. Una recopilación fallida debe permanecer visible hasta que se pueda investigar.

Esta comprobación solo establece la existencia de acuerdos. No valida la vinculación a Conditional Access, el estado habilitado de la directiva, la selección de destinatarios, las excepciones, la calidad del PDF, la cobertura de idiomas ni las aceptaciones de usuarios. Crear un acuerdo sin uso puede eliminar este hallazgo concreto sin imponer la necesidad de negocio. Combine el resultado del collector con la inspección de la directiva y las pruebas de aceptación anteriores, y conserve una decisión explícita de idoneidad cuando las condiciones de uso sean innecesarias para el tenant.