Policy Acknowledgement Los roles del producto controlan las operaciones y vistas disponibles en Policy Acknowledgement. Policy Admin también aplica permisos de SharePoint basados en roles a las listas del centro. Revise ambas capas al diseñar el acceso.
Comprenda los roles
| Rol | Uso principal en los elementos web |
|---|---|
| Administrador de producto | Configuración, ajustes, roles y administración; acceso a gestión e informes. |
| Responsable de cumplimiento | Políticas, campañas, informes y exenciones en todo el producto. |
| Autor de la política | Creación de políticas y gestión de las políticas de las que es propietario. |
| Auditor | Informes e inspección sin acciones de gestión de políticas. |
| Empleado | Asignaciones personales y contenido de políticas. |
El ámbito de un responsable de equipo se deriva de las relaciones jerárquicas, con un ajuste para subordinados directos o toda la rama jerárquica. No es una sexta asignación de rol en la lista de roles. La propiedad se almacena en cada política; la vista del autor filtra las políticas por ese propietario.
Asigne grupos
- Abra Policy Admin como administrador del producto y seleccione Roles.
- Seleccione grupos de seguridad de Entra ID o grupos de SharePoint pertenecientes al sitio del centro para los roles necesarios.
- Mantenga al menos un grupo para Administrador de producto.
- Revise la población de empleados y Los responsables pueden ver a todos sus subordinados directos e indirectos.
- Seleccione Guardar y aplicar permisos y espere a que finalice la sincronización.
Utilice grupos explícitos de empleados cuando necesite un límite de acceso preciso. Aunque la interfaz ofrece Todos los usuarios con licencia, el mecanismo actual de resolución de roles considera que esta opción coincide con el usuario actual sin comprobar su licencia. No debe utilizarse como prueba de que el acceso se limita a cuentas con licencia.
Comprenda qué cambia al aplicar permisos
La sincronización concede acceso de lectura al sitio a los grupos de roles, rompe la herencia de permisos en las listas del producto y aplica la matriz de permisos de listas. La cuenta que realiza la sincronización conserva Control total sobre esas listas. Revise el impacto antes de aplicarlo a un sitio compartido existente.
En el modo Direct, los empleados reciben permisos de contribución sobre asignaciones y registros de confirmación. En el modo Service, las entradas de empleados en esa matriz son de solo lectura para esas dos listas. Los empleados conservan permisos de contribución sobre preguntas. Un usuario con varios roles puede recibir los permisos combinados de sus grupos.
❗ Importante
El filtrado por propietario de la política y el filtrado de asignaciones personales se implementan en los elementos web. La matriz de permisos funciona a nivel de lista, no con aislamiento por política o empleado. No presente estos filtros como garantía de que los usuarios no pueden acceder a otros registros mediante SharePoint. Una sincronización correcta tampoco demuestra que se hayan revocado todas las concesiones previas o elevadas.
Separar audiencia, propiedad y permisos
Estos conceptos responden a preguntas distintas. La audiencia de campaña decide quién debe recibir una tarea. El propietario de la política determina la responsabilidad y la vista de gestión filtrada por autor. Un rol habilita acciones del producto, mientras los permisos de SharePoint gobiernan el acceso a registros almacenados. Cambiar uno no logra automáticamente los demás objetivos.
Por ejemplo, asignar una política al departamento financiero no convierte sus registros de lista subyacentes en privados para finanzas. Cambiar el propietario de una ficha cambia qué autor debe gestionarla, pero no transfiere permisos por elemento. Ocultar una página de gestión en la navegación del portal tampoco revoca el acceso existente del usuario a las listas.
Diseñe los grupos de roles según responsabilidades y después revise el acceso efectivo a datos de esos grupos. Cuando alguien pertenezca a varios grupos, pruebe esa pertenencia combinada. Un usuario con rol de autor y un grupo administrativo puede ver o cambiar mucho más que una cuenta de prueba solo de autor. Quitar una pertenencia puede dejar acceso mediante otro grupo o un permiso elevado del sitio.
Usar una prueba de acceso representativa
| Cuenta de prueba | Comprobación de aplicación | Comprobación adicional de acceso |
|---|---|---|
| Administrador | Abra Policy Admin e inspeccione los roles configurados. | Confirme que la administración esperada sigue disponible después de sincronizar. |
| Autor | Abra las políticas propias y verifique las acciones de gestión previstas. | Inspeccione permisos reales de listas en lugar de deducir aislamiento de la vista filtrada. |
| Auditor | Abra el informe pertinente y descargue una exportación permitida. | Compruebe si las acciones que guardan resultados o eventos de auditoría requieren escritura adicional. |
| Empleado | Abra una política asignada y envíe una confirmación piloto. | Verifique el acceso al origen y la ruta configurada de escritura de pruebas. |
| Responsable | Cargue el equipo jerárquico esperado. | Compruebe de forma independiente el acceso efectivo a datos y el comportamiento del ámbito. |
Algunas acciones aparentemente orientadas a lectura también escriben datos. Por ejemplo, una comprobación de integridad guarda su resultado y una exportación de informe escribe un evento de auditoría después de generar el archivo. Por ello, una cuenta de solo lectura puede ver resultados útiles y después encontrar un error de escritura. Investigue la operación concreta que falló antes de ampliar su rol.
Mantener el acceso tras cambios organizativos
Cuando un autor cambie de puesto, revise tanto su pertenencia a grupos como la propiedad de las políticas que mantenía. Cuando cambien los responsables, inspeccione las relaciones del directorio y los campos de responsable almacenados en asignaciones; recargar la página no reescribe asignaciones históricas. Cuando cambie el modo de registro, revise el servicio y vuelva a aplicar la matriz de permisos correspondiente.
Mantenga un registro breve de quién aplicó permisos, qué grupos se pretendían y qué pruebas representativas pasaron. La cuenta sincronizadora conserva Full Control, así que evalúela expresamente en lugar de suponer que una etiqueta de modo de servicio significa que todas las cuentas humanas son de solo lectura. El selector actual de Team Compliance tampoco impone el ajuste de toda la rama; consulte KB10530. Team Compliance: cómo supervisar a su equipo y realizar seguimiento para la limitación resultante de informes.
Verifique y mantenga el acceso
Pruebe con cuentas independientes de administrador, autor, usuario de informes y empleado. Confirme tanto las páginas previstas como los permisos de las listas subyacentes. Después de cambiar el modo de registro de confirmaciones, ejecute Guardar y aplicar permisos de nuevo e inspeccione los derechos efectivos. Consulte KB10509. Almacenamiento de datos de Policy Acknowledgement: modos Direct y Service para conocer los modos de registro y sus limitaciones.
