Declaración de privacidad Entra: URL y pruebas de invitados

Qué aporta una declaración de privacidad Entra

Una declaración de privacidad Entra es un enlace, a nivel de organización, al documento que explica cómo trata su organización los datos de las personas. Configúrela con un contacto de privacidad actualizado para que los empleados y los invitados externos encuentren la información destinada a ellos. El resultado útil es un documento legible y pertinente y un responsable localizable, en lugar de un campo rellenado que nadie ha probado.

La guía de Microsoft para configurar la información de privacidad abarca tanto el contacto global de privacidad como la URL de la declaración. Describe su uso para empleados internos e invitados externos, incluida la experiencia de invitación B2B. Cuando no se proporciona ninguno, Learn muestra un mensaje Review Permissions que indica que la organización no ha facilitado enlaces para consultar. Considere esa presentación un motivo para inspeccionar el recorrido real del invitado, sin afirmar por ello que las invitaciones estén bloqueadas.

Decida quién es responsable del documento antes de cambiar el tenant. Un socio que recibe una invitación puede necesitar información diferente del manual interno de los empleados. Pida a los responsables de las revisiones jurídicas y de privacidad que confirmen el alcance y el idioma del documento. La falta de una URL en el tenant es una observación de configuración; no demuestra una infracción jurídica universal ni determina qué obligaciones se aplican a su organización.

Cómo se diferencia la información de privacidad de la aceptación de un documento

El recurso Graph privacyProfile separa contactEmail de statementUrl. Ambas propiedades son opcionales en el esquema. El correo electrónico identifica al contacto de la declaración de privacidad, mientras que la URL apunta a la declaración de la organización. Un campo opcional de la API puede seguir siendo útil para sus necesidades operativas; su carácter opcional no decide si su organización necesita esa información.

Learn define una URL de declaración que empieza por HTTP o HTTPS. Para un despliegue nuevo, elija un destino HTTPS estable y pruébelo desde las poblaciones que lo consultarán. Un documento disponible solo después de la autenticación de un empleado puede no ser adecuado para un colaborador externo recién invitado. No suponga que la capacidad de un administrador para abrir la página demuestra que un invitado puede acceder a ella.

Publicar este enlace proporciona información. No configura un control de concesión Conditional Access que exija aceptación, no crea un registro de aceptación ni demuestra que alguien haya leído el texto. La guía de condiciones de uso Entra y aceptación con Conditional Access aborda ese requisito separado: un acuerdo aprobado y una directiva que lo imponga deben estar conectados cuando la aceptación sea la condición de acceso deseada.

Detección: verificar la configuración, el destino y la presentación para invitados

Leer el perfil de la organización con el acceso Graph adecuado

Primero confirme el tenant que está revisando. En el centro de administración Entra, inspeccione Entra ID > Overview > Properties, incluidos el contacto global de privacidad y la URL de la declaración. Conserve la hora de la observación y los valores exactos para comparar el portal con una lectura independiente de la API.

La documentación Microsoft List organization admite GET /organization y el parámetro de consulta $select. Utilice esta solicitud para obtener el perfil:

GET https://graph.microsoft.com/v1.0/organization?$select=privacyProfile
Authorization: Bearer {token}

Es una plantilla de solicitud para su cliente autorizado, no una consulta ejecutada contra el tenant de un cliente para este artículo. Inspeccione tanto privacyProfile.contactEmail como privacyProfile.statementUrl en la organización devuelta. Guarde la respuesta y los errores de recopilación con el expediente de revisión; no sustituya un resultado de la API por una captura del portal al investigar el comportamiento de la recopilación.

La documentación de lectura de la organización incluye Organization.Read.All para el acceso de aplicaciones y lo admite para el acceso delegado con cuentas profesionales o educativas. Advierte expresamente que User.Read solo expone id, displayName y verifiedDomains, y que las demás propiedades devuelven null. Utilice como mínimo Organization.Read.All para leer el perfil de privacidad y compruebe los requisitos de roles admitidos para un cliente delegado. Una respuesta correcta con visibilidad insuficiente de las propiedades no debe convertirse en prueba de ausencia.

Probar el destino independientemente de la consulta Graph

Una consulta de organización completada y un documento de privacidad disponible son observaciones distintas. Registre la URL exacta devuelta y envíe después una solicitud HTTP independiente a ese destino. Para una declaración pública autorizada, una solicitud de diagnóstico puede tener este aspecto:

curl --location --silent --show-error --output privacy-statement.html --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' 'https://example.org/privacy'

Sustituya el ejemplo por el destino aprobado. Revise la respuesta final y el cuerpo guardado, sin aceptar únicamente el código de estado. Una respuesta correcta podría contener una página de inicio genérica, un formulario de inicio de sesión o un documento ajeno al propósito. Compruebe las redirecciones, la organización citada en el texto y si la página explica el tratamiento de datos previsto. Inspecciónela también en un navegador, incluidas la navegación y la legibilidad.

Pruebe el acceso desde un contexto de empleado y desde un contexto externo representativo del flujo de invitación. Si el destino exige autenticación, determine si ese requisito es intencionado y viable antes de que se incorpore el invitado. Registre una página no disponible, una redirección inesperada, un documento obsoleto o un idioma inadecuado como un problema del destino, aunque el campo del tenant esté rellenado. Confirme por separado que el contacto indicado se supervisa y tiene un responsable asignado.

Realizar una invitación B2B representativa

Utilice una invitación de prueba aprobada y observe la experiencia real del invitado. Verifique la organización mostrada, la información de privacidad ofrecida, el destino al que llega al seguir el enlace y el contacto presentado. Registre el contexto del invitado y el recorrido utilizado, porque un invitado existente que vuelve a una aplicación no reproduce una nueva invitación.

La revisión de Conditional Access para invitados y de colaboración externa ayuda a delimitar la población externa prevista y su configuración de acceso. Conserve esa revisión de acceso junto con esta comprobación de la información. Un enlace de privacidad que funciona no demuestra que las invitaciones, las asignaciones de directivas, el acceso a aplicaciones o la configuración del ciclo de vida de los invitados cumplan sus requisitos.

Observación	Evidencias que conservar	Qué demuestra
Lectura Graph autorizada	Contexto del tenant, respuesta, hora, errores	Valores recopilados del perfil de privacidad
Solicitud independiente al destino	Estado, URL final, cuerpo revisado	Qué devolvió el destino en ese contexto de prueba
Revisión en navegador y de la invitación	Contexto, información mostrada, navegación observada	Presentación y facilidad de uso para el recorrido probado
Responsabilidad del contacto y del documento	Responsables y decisión de mantenimiento	Quién gestionará las preguntas y los cambios

Corrección: publicar y mantener una URL de tenant utilizable (Remediation)

1. Asignar responsables al documento y al contacto

Identifique al revisor responsable de la declaración y al equipo encargado de responder a las preguntas de privacidad. Acuerden los públicos de empleados e invitados previstos, los idiomas y el lugar de publicación. Entregue al administrador del tenant valores aprobados para introducir. No permita que el administrador invente el texto de privacidad simplemente para eliminar un hallazgo de auditoría.

Utilice una dirección de contacto con un proceso explícito de traspaso cuando cambie el personal. Decida quién comprueba los mensajes entrantes y quién gestiona un enlace roto al documento. Registre dónde se mantiene el documento aprobado y cómo se revisan los cambios de su alcance. Son decisiones operativas que se deben tomar localmente, no conclusiones jurídicas derivadas de la configuración del tenant.

2. Validar el destino antes de configurar Entra

Publique la declaración aprobada en una URL estable. Verifique que los lectores internos y externos previstos puedan acceder al contenido pertinente y que los idiomas admitidos sigan siendo accesibles desde ese destino. Mantenga una página comprensible sin exigir al invitado que navegue por una biblioteca de documentos exclusiva para empleados.

Registre la prueba del destino por separado del cambio del tenant. Si su sistema de publicación redirige el enlace, revise el destino final y asegúrese de que las futuras redirecciones permanezcan bajo el control del responsable del documento. Una URL permanente de la organización es más fácil de mantener que un enlace vinculado a una campaña temporal, a un espacio personal o a un token de uso compartido que caduca.

3. Introducir los valores en Properties

Siga el procedimiento Properties de Learn: inicie sesión como mínimo con el rol Billing Administrator, vaya a Entra ID > Overview > Properties, introduzca Global privacy contact y Privacy statement URL, y seleccione Accept como se documenta. Esa acción del portal guarda la información de la organización; no es la aceptación de su documento por parte de un invitado.

Si su proceso de cambio aprobado utiliza Graph, Update organization documenta PATCH /organization/{id} con Organization.ReadWrite.All para el acceso delegado con cuentas profesionales o educativas y para el acceso de aplicaciones. Utilice el identificador verificado de la organización e inspeccione los requisitos de roles delegados antes de escribir. Envíe los valores previstos del perfil sin cambiar otras propiedades de la organización:

PATCH https://graph.microsoft.com/v1.0/organization/{organization-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "privacyProfile": {
    "contactEmail": "[email protected]",
    "statementUrl": "https://example.org/privacy"
  }
}

El ejemplo es un patrón de solicitud documentado con valores de sustitución, no un cambio ejecutado en un tenant. Mantenga los permisos de escritura separados del cliente de revisión de solo lectura. Una respuesta correcta de actualización es un punto de partida para la verificación, no la prueba final de que las personas puedan utilizar el documento.

4. Volver a leer el perfil y repetir la prueba del invitado

Repita el GET de organización con la selección indicada y compare ambas propiedades con los valores aprobados. Vuelva a comprobar el destino de forma independiente y repita después la revisión de la invitación representativa. Conserve los fallos y las observaciones satisfactorias. Si el perfil difiere, investigue el contexto del tenant y el resultado de la actualización antes de repetir una escritura.

Si la información está configurada pero el recorrido probado del invitado no la muestra como se esperaba, conserve las evidencias de la API y la presentación observada como hechos separados. Investigue ese recorrido en lugar de sustituir repetidamente una URL correcta. Evite añadir un requisito de condiciones de uso como solución improvisada a la falta de información de privacidad; la aceptación necesita su propio propósito y alcance aprobados.

5. Mantener los idiomas, los enlaces y la responsabilidad

Revise la declaración cuando cambien el tratamiento de los datos, el alojamiento del documento, las poblaciones de invitados o la responsabilidad del contacto. Actualice las traducciones junto con el documento fuente aprobado. Tras una migración de alojamiento, repita las comprobaciones HTTP y de navegador aunque la URL del tenant no cambie. Tras un traspaso del contacto, verifique que la dirección siga llegando al equipo responsable.

Mantenga juntos los valores aprobados, la lectura de comprobación Graph, las pruebas del destino, las observaciones de invitados y las decisiones de los responsables. Esto permite distinguir una desviación de configuración de una interrupción de la publicación o un cambio en la experiencia de invitación. Defina una periodicidad de revisión adecuada para su organización en lugar de considerar el primer guardado correcto como prueba permanente.

Cómo EtcSec detecta esta configuración

El detector AZ_NO_PRIVACY_STATEMENT de etc-collector lee AzurePrivacyStatementProbed y AzurePrivacyStatementURL. Su implementación Detect() tiene tres ramas:

Estado recopilado	Resultado real del detector	Interpretación
`AzurePrivacyStatementProbed` es false	Hallazgo Info, Count 1	No determinable: esta auditoría no consultó el perfil; inspeccione `audit.warnings` y los requisitos previos de recopilación.
Perfil consultado y `AzurePrivacyStatementURL != ""`	`nil`, ningún hallazgo	La cadena recopilada no está vacía.
Perfil consultado y URL vacía	Hallazgo Low, Count 1	La recopilación completada no proporcionó ninguna URL de declaración.

Count 1 es el número de hallazgos, no el número de invitados afectados. No consultado no significa ausente, y la rama Info no es un veredicto de cumplimiento. Resuelva los fallos de recopilación antes de extraer una conclusión sobre la configuración.

El proveedor envía GET /organization?$select=privacyProfile, lee statementUrl de la primera organización y devuelve una cadena vacía sin error cuando la lista de organizaciones está vacía o el perfil está ausente. Los errores de solicitud y de decodificación se devuelven por separado. Por tanto, un inventario vacío inesperado merece una investigación junto con los permisos y el contexto del tenant.

Ni el proveedor ni este detector eliminan espacios de la cadena: una cadena de espacios no está vacía y supera la comparación. Ninguno solicita la URL de la declaración, verifica el contacto ni revisa el contenido o los idiomas del documento. El proveedor no recopila contactEmail para esta comprobación. Una URL no vacía puede eliminar este hallazgo aunque el destino no esté disponible o no sea adecuado. Combine este resultado limitado de configuración con las pruebas independientes del destino y de la invitación descritas anteriormente, y conserve la decisión del responsable sobre la idoneidad del documento.