En este tema se describen las mejoras y modificaciones incluidas en las versiones de septiembre de 2025 de Data360 Govern y se recogen los cambios que podrían afectar a su implementación actual.
El mes pasado, actualizamos los entornos Dev y UAT con algunos cambios significativos en las funciones y responsabilidades, y los cambiamos a funciones y políticas de seguridad. A continuación, encontrará información adicional sobre estos cambios.
Hemos rediseñado por completo la sección Funciones y políticas de seguridad para que la gestión del control de acceso sea más intuitiva, flexible y eficiente. Esta actualización simplifica la creación de funciones, mejora la administración de permisos y aumenta el rendimiento del sistema al pasar a un modelo de política dinámico y basado en eventos.
-
Cambio de nombre de página y rediseño de la interfaz de usuario: la página se ha cambiado a "Funciones y políticas". Ahora, la interfaz de usuario presenta un diseño más limpio para facilitar la creación y administración de Funciones y Políticas de seguridad.
-
Flexibilidad de funciones: ya no es necesario asignar funciones a un tipo de activo específico. Ahora se pueden utilizar en cualquier tipo de activo sin necesidad de una asignación específica.
-
Interfaz de permisos de funciones mejorada: ahora puede configurar fácilmente los permisos de lectura, creación, actualización y eliminación en los tipos Activo, Relación y Propietario. Los permisos predeterminados se pueden anular mediante la asignación de permisos personalizados a varios tipos de activos dentro de una función.
-
Panel de detalles: se ha agregado un panel de detalles a la derecha de la pantalla que muestra los permisos adicionales y los detalles de la política de seguridad.
-
Cambios de terminología:
- los "Tipos de responsabilidades" ahora se denominan "Funciones". Los términos "Propiedad" y "Funciones" se han estandarizado en toda la aplicación para sustituir a "Responsabilidades".
- Las "Reglas de propiedad" ahora se denominan "Políticas de seguridad". La ficha Políticas de seguridad muestra una lista completa de las políticas de seguridad disponibles, que ya no se segmentan según las funciones.
- El nombre de la sección "Cuándo" se ha cambiado a ¿A qué se aplica la política?, que indica las condiciones para la aplicación de la política.
- El nombre de la sección "Then" se ha cambiado a ¿A quién se aplica esta política?.
-
Políticas basadas en eventos: las políticas ahora se basan en eventos en lugar de en programación, lo que mejora el rendimiento. Los cambios en los activos o las relaciones desencadenan recalculaciones de políticas específicas. Esto significa que cuando un usuario actualiza un activo, cualquier política de seguridad en uso aplicará automáticamente las actualizaciones necesarias para garantizar el cumplimiento.
- Nuevas API: se han agregado los siguientes puntos de conexión para mejorar la funcionalidad:
- GET /api/v2/security/{assetUid}/owners
- GET api/v2/security/policies
- POST /api/v2/security/policies
- DELETE /api/v2/security/policies/{uid}
- PUT /api/v2/security/policies/{uid}
- POST /api/v2/security/policy-overrides
- DELETE /api/v2/security/policy-overrides/{uid}
- PUT /api/v2/security/policy-overrides/{uid}
- GET /api/v2/security/roles
- ¿Necesitamos volver a configurar las funciones y las políticas de seguridad para garantizar que no se vean afectados los casos de uso que requieren diferentes niveles de permisos para diferentes tipos de activos dentro de la misma función? No, los diferentes tipos de activos bajo la misma función pueden tener permisos únicos.
- ¿Cuáles son los efectos de los nuevos permisos de funciones que ya no se asignan a tipos de activos específicos? En el sistema rediseñado, las funciones pueden tener permisos para todos los tipos de activos sin asignaciones explícitas de tipos de activos, lo que mejora la flexibilidad y simplifica la gestión.
-
¿Cómo podemos garantizar que los nuevos permisos de funciones funcionen de la misma manera que los antiguos? Dado que la funcionalidad sigue siendo la misma y que solo se ha actualizado la terminología de la IU y la asignación estructural, Responsabilidad ahora se denomina Función, y Regla de propiedad como Política de seguridad. Nuestro enfoque principal es mantener la equivalencia semántica y el comportamiento coherente.
Problemas corregidos
| Resumen del problema | Número de problema |
|---|---|
| Se ha introducido una opción de botón de opción para seleccionar el tipo de grupo de miembros como "Dinámico", lo que proporciona un control mejorado sobre la accesibilidad de los miembros. | MON-462 |
| Se ha aplicado el acceso de UID en minúsculas para mantener la uniformidad del producto. | MON-609 |
| Los administradores ahora pueden restringir las asignaciones de funciones solo a los tipos de activos para los que se hayan establecido anulaciones de permisos. | MON-607 |
| Se ha solucionado un problema que impedía que los usuarios fueran visibles en un grupo con pertenencia dinámica incluso cuando se cumplían las condiciones. | MON-612 |
| Se ha solucionado un problema en el que había un conflicto entre POST /api/v2/security/roles y POST /api/v2/responsibilities/types/{uid:Guid}/allocations. | MON-586 |
| Se ha solucionado un problema en el que los permisos no se aplicaban correctamente al usar la anulación de función a nivel de política. | MON-590 |
| Se ha solucionado un problema que impedía que algunas actualizaciones se reflejaran en el registro de cambios. | MON-595 |
| Se ha solucionado un problema que provocaba una respuesta incorrecta con el punto de conexión GET /api/v2/membership/groups. | MON-596 |
| Se ha solucionado un problema en el que los usuarios de la carga en masa no rellenaban los valores de los campos personalizados. | MON-616 |
| Se ha solucionado un problema en el que la condición de pertenencia al grupo mostraba un valor en blanco al editar un grupo. | MON-617 |
| Se ha expuesto la creación, actualización y eliminación de puntos de conexión para funciones en Swagger. | MON-624 |