Policy Acknowledgement Policy Acknowledgement almacena sus datos de trabajo en un centro de políticas de SharePoint. El modo de registro determina cómo se escriben las confirmaciones normales de los empleados. No traslada los datos de la solución a otro sitio de almacenamiento.
Qué almacena el centro
| Lista o biblioteca | Finalidad |
|---|---|
Policies | Fichas de políticas, versión actual y controles de lectura. |
PolicyVersions | Metadatos de versiones e instantáneas de documentos cuando se admiten. |
PolicyCategories | Categorías y sus textos de confirmación. |
PolicyCampaigns | Definiciones de audiencia, plazos y ajustes de recordatorios. |
PolicyAssignments | Asignaciones de empleados y su estado actual. |
PolicyAcknowledgements | Confirmaciones y otros eventos de evidencia con hashes encadenados. |
PolicyQuestions | Preguntas, motivos y respuestas de empleados. |
PolicyNotificationLog | Almacenamiento del registro de notificaciones. |
PolicyAuditLog | Eventos administrativos y de flujo de trabajo. |
PolicySettings | Ajustes del producto. |
PolicyRoleAssignments | Correspondencias entre roles y grupos. |
Los documentos de origen permanecen en sus URL configuradas. Publicar un documento del mismo origen puede guardar una instantánea en PolicyVersions; los orígenes externos no reciben esa instantánea ni un hash del contenido.
Compare los modos de registro
| Aspecto | Direct | Service |
|---|---|---|
| Escritura de confirmaciones normales | El elemento web escribe en SharePoint utilizando la sesión del empleado. | El elemento web envía la confirmación al servicio conectado. |
| Permisos de empleados en la matriz de roles | Contribución sobre asignaciones y confirmaciones. | Acceso de lectura a esas dos listas. |
| Servicio independiente necesario para esta escritura | No. | Sí, con un punto de conexión operativo y consentimiento. |
| Recordatorios automáticos y actualizaciones de audiencia | No los proporciona el modo Direct. | Dependen de la implementación y el funcionamiento del servicio conectado. |
El modo Direct es el ajuste predeterminado. Seleccionar Service no instala el servicio ni verifica todo su comportamiento operativo.
Configure y verifique un cambio de modo
- Abra Notificaciones en Policy Admin.
- Para el modo Service, introduzca URL del servicio de recordatorio, abra el consentimiento del administrador y ejecute Verificar el consentimiento.
- Elija la opción necesaria en ¿Quién registra las confirmaciones de lectura? y guarde.
- Abra Roles y seleccione Guardar y aplicar permisos.
- Inspeccione los permisos efectivos de SharePoint y pruebe una confirmación utilizando una cuenta de empleado independiente.
Guardar un ajuste de modo no vuelve a aplicar los permisos automáticamente. El lector bloquea el envío normal si el modo Service carece de URL o consentimiento confirmado; una interrupción posterior del servicio se comunica como error de envío.
Seguir el registro a través de la aplicación
Ficha, asignación y confirmación son registros distintos. La ficha describe la política actual; la asignación identifica el trabajo de una persona para una versión y campaña; la confirmación registra un evento probatorio. Un justificante muestra campos de prueba seleccionados. Estos registros suelen concordar después de un envío correcto, pero no deben tratarse como un único objeto atómico.
En la ruta directa, la aplicación lee el hash precedente, añade la confirmación y actualiza la asignación. En la ruta de servicio, envía los datos al punto configurado y recupera el registro resultante. Una lectura o actualización posterior puede fallar aunque una escritura anterior haya funcionado. Por eso la investigación debe comparar la referencia de asignación y el registro probatorio antes de pedir al empleado que reintente.
Cambiar el modo de registro cambia la ruta de confirmaciones ordinarias, no la ubicación de todos los datos de políticas ni todas las operaciones administrativas. Tampoco reescribe eventos anteriores en un nuevo modelo probatorio. Conserve los registros originales e inspeccione cómo los permisos efectivos y el comportamiento del servicio del despliegue respaldan los requisitos de protección previstos.
Separar las comprobaciones necesarias para cambiar de modo
| Comprobación | Qué verificar |
|---|---|
| Configuración | Modo guardado, punto de conexión y consentimiento coinciden con la configuración prevista. |
| Permisos | Se volvió a aplicar la matriz del producto y se inspeccionaron los derechos reales de listas. |
| Confirmación de empleado | Un empleado representativo puede enviar y obtener el justificante correcto. |
| Conciliación de asignación | La asignación correspondiente tiene el estado y la referencia probatoria esperados. |
| Flujo de excepciones | Un operador autorizado puede resolver un caso de prueba, incluida la ruta independiente de exención cuando se utilice. |
| Trabajo en segundo plano | El propietario del servicio puede demostrar las tareas programadas y el comportamiento de entrega requeridos. |
Realice estas comprobaciones con cuentas que representen los roles de producción. Probar solo como administrador sincronizador puede ocultar la concesión adicional de Full Control que conserva esa cuenta. Asimismo, una respuesta correcta de consentimiento no establece que todas las operaciones de escritura, programación y entrega del servidor funcionen bien.
Interpretar la integridad como una parte de la protección
Una cadena de hashes enlaza registros para que un registro modificado o ciertos registros ausentes produzcan una discrepancia. No proporciona un inventario fiable e independiente de todo lo que debería existir. Detectar la eliminación del final de una cadena o la sustitución completa puede requerir otros controles o pruebas conservadas. Por tanto, el indicador verde significa que la cadena cargada superó las comprobaciones de coherencia implementadas.
Use el resultado de integridad junto con permisos, pruebas de origen y versión y registros operativos. Un hash coincidente no demuestra que el lector mostrara un archivo archivado, que existan todos los eventos requeridos de empleados ni que el empleado comprendiera el texto. Si encuentra una incoherencia, conserve identificadores y datos originales antes de corregir; consulte KB10533. Cómo comprobar la integridad del registro de confirmaciones y KB10538. Resolver confirmaciones fallidas y notificaciones ausentes.
Comprenda los límites de la evidencia
Un evento de evidencia incluye identidad, información de política y versión, marca de tiempo, texto de confirmación, datos de controles de lectura y hashes. La aplicación comprueba una cadena de hashes de registros para detectar incoherencias. Esto no constituye una garantía absoluta de inmutabilidad.
❗ Importante
La interfaz describe el modo Service como un modo que impide escrituras directas incluso a los administradores, pero el código actual de sincronización de permisos conserva Control total para la cuenta que realiza la sincronización. Las concesiones elevadas o existentes también deben inspeccionarse. El modo Direct concede derechos de contribución a los empleados y la matriz no aísla los registros por empleado. No afirme que todas las evidencias son técnicamente inmutables ni que el filtrado de elementos web proporciona seguridad a nivel de registro.
Actualmente, los eventos de exención utilizan una escritura directa en SharePoint incluso en el modo Service. Esa vía puede fallar para un responsable de cumplimiento que solo tenga los permisos documentados en la matriz. Consulte KB10507. Cómo atender preguntas sobre políticas y eximir a empleados. La implementación independiente del servicio no forma parte del proyecto de elementos web, por lo que sus permisos de aplicación, procesamiento en segundo plano y controles de protección deben verificarse en la implementación real.
