Permisos

El tercer paso para aterrizar el modelo de gobierno de la organización en Anjana Data, tras la definición de unidades organizativas y de roles, es establecer la configuración de permisos.

Los permisos son los que habilitan a cada rol a realizar acciones a bajo nivel en la plataforma. Constituyen el vínculo entre el rol definido y las acciones efectivas que los usuarios pueden ejecutar sobre los distintos objetos y módulos de Anjana Data.

Gracias a ellos, es posible granular el control operativo y garantizar que las responsabilidades asociadas a cada rol se materialicen de acuerdo con el modelo de gobierno de la organización.

Concepto de Permisos en Anjana Data

Cada permiso especifica qué puede hacer un rol sobre un objeto o conjunto de objetos de la plataforma. Existen permisos aplicables de dos formas:

• Permisos específicos por tipo de entidad o relación:
  Se aplican en función del metamodelo (ej. Dataset, Términos de negocio, Informes, Modelos de IA…) y determinan qué operaciones se pueden realizar sobre cada tipo de objeto (Creación y modificación, cambio de estado, deprecación, cambio de unidad organizativa y owner de la unidad organizativa).

• Permisos globales de aplicación:
  Se aplican de manera transversal en la plataforma, independientemente del dominio o entidad (ej. PLATFORM_ACCESS, ADMIN_ACCESS, LINEAGE_ACCESS).

Tipos de Permisos

1. Permisos por entidades y relaciones (metamodelo)

• AUTOMATIC_METADATA: creación de entidades o relaciones de manera asistida en el wizard de creación del portal de datos mediante descubrimiento e importación automática vía plugin.

• CHANGE_STATUS: activar o desactivar entidades o relaciones no nativas.

• CHANGE_OU: modificar la unidad organizativa de una entidad para cambiar la custodia del activo.

• CREATION_MODIF: crear, modificar y enviar a validar entidades o relaciones.

• DELETE_ALL: eliminar entidades o relaciones, independientemente del creador.

• DELETE_MY_OBJ: eliminar entidades o relaciones creados por el propio usuario.

• DEPRECATION: deprecar manualmente entidades nativas.

• EDIT_ACCESS_INFO: editar la información de acceso a un objeto al que está adherido el usuario

• ORGANIZATIONAL_UNIT_OWNER: actuar como propietario de entidades dentro de la Unidad Organizativa (OU) asignada.

  • Los usuarios con este permiso aparecerán en la pantalla de Intervinientes (Stakeholders) como Propietario.

  • Al crear y aprobar un DSA, dichos usuarios podrán ser añadidos automáticamente al grupo de acceso correspondiente (esta automatización dependerá de la configuración técnica del plugin que gestione las adherencias)

2. Permisos globales a nivel plataforma

• ADHERENCE_ACCESS: acceso al marketplace para visualización de objetos (para el subtipo ALL) que habilita el uso del carrito.

• ADMIN_ACCESS: acceso al panel de administración.

• API_ADMIN: uso de la API administrativa, uso de edición masiva de objetos en el portal de datos y uso de las acciones del panel de administración ( Actions) .

• API_DOC: acceso a la visualización a la documentación de la API mediante la aplicación.

• CATALOG_ACCESS: acceso al catálogo donde se visualiza el inventario de activos gobernados.

• CREDENTIAL_ADMIN: gestión de credenciales para autenticación (por base de datos) y autorización (acceso a tablas Users y User-OU-Roles) y acceso a configuración técnica ( tabla appConfigurations del panel de configuración).

• GOV_AUDIT_ACCESS: acceso a la auditoría de gobierno

• JOBS_ACCESS: acceso al módulo de trabajos

• LINEAGE_ACCESS: visualización de linaje en el portal de datos.

• SEC_AUDIT_ACCESS: acceso a la auditoría de seguridad

• OBJ_AUDIT_ACCESS: acceso a la pestaña de auditoría de un objeto

• OBJ_RELATIONS_ACCESS: el acceso a la pestaña de relaciones de un objeto

• OBJ_SAMPLE_DATA_ACCESS: acceso a la pestaña de muestra de datos de un objeto

• OBJ_STAKEHOLDERS_ACCESS: acceso a la pestaña de intervinientes de un objeto

• OBJ_VERSIONS_ACCESS: acceso a la pestaña de versiones de un objeto

• PLATFORM_ACCESS: acceso al portal de datos para visualización de objetos (para el subtipo ANJANA)

• WORKFLOW_ACCESS: acceso, aprobación o rechazo de flujos de validación en el portal de datos.

• WORKSPACE_ACCESS: acceso al módulo de Workspace

Tabla Permissions del Panel de Configuración (Visión administrador)

Los permisos se configuran en la tabla Permissionsdel panel de configuración. La definición de los permisos es un paso indispensable para poder acceder a la plataforma (portal de datos o panel de configuración) y realizar acciones dentro de la misma.

Estructura de la tabla Permissions

Cada permiso registrado se caracteriza por los siguientes campos:

Cada registro de la tabla define un permiso y se compone de los siguientes campos:

• id: identificador único del permiso dentro de la tabla.

  • Se asigna automáticamente en base a las secuencias de base de datos.

• action: acción específica que se autoriza.

  • Para asignar acciones, ver las combinaciones posibles de la tabla de permisos

• subType: objeto o entidad del metamodelo sobre el que aplica la acción permitida.

  • Para asignar acciones, ver las combinaciones posibles de la tabla de permisos

• role: referencia al rol al que se le asigna el permiso.

  • El combo de selección muestra los roles configurados en Roles. En caso de no aparecer el rol esperado, revisar la configuración de Roles.

Combinaciones de action y subType:

(1): Name de la tabla object_subtype

(2): No se deben definir permisos para DATASET_FIELD ya que, para él, aplican los permisos de DATASET

(3): CHANGE_OU no puede ser utilizado para INSTANCE

Alta de un Permiso en la tabla Permissions

El alta de un nuevo permiso para un rol (por ejemplo, el borrado de tratamientos de datos creados por cualquier usuario) implica añadir en la tabla Permissionsun nuevo registro.

Para añadir el registro y dar de alta un nuevo permiso:

1. Pulsar el botón New en la esquina superior derecha. Esto abrirá un asistente (wizard) con los campos definidos en el apartado Estructura de la tabla Permissions.

2. Completar los campos de permiso conforme a la estructura descrita en el apartado anterior.

3. Pulsar en Save para guardar el permiso o en Cancel para descartar.

Modificación de un Permiso en la tabla Permissions

La modificación de los campos action, subType o role debe realizarse con precaución, ya que puede tener impacto en:

• Las capacidades de los usuarios dentro de la plataforma.

• La validación workflows ya que si el usuario validador no tiene acceso al módulo, no podrá realizar el paso de validación.

Consulta y explotación de los permisos en base de datos (Visión desarrollador)

Además de configurarse desde el Panel de configuración, la información de los permisos queda almacenada en la base de datos y puede consultarse en modo lectura para explotarla con fines analíticos. Por ejemplo, permite que el cliente construya su propio data mart, cuadros de mando o informes sobre el modelo de permisos de su plataforma (matriz de rol / acción / subtipo, número de permisos por rol, etc.).

Tabla zeus."permission"

La configuración de cada permiso se almacena en la tabla zeus."permission". Sus columnas, disponibles para su consulta, son:

Tablas relacionadas para enriquecer las consultas

Para obtener una vista más completa, la tabla de permisos puede cruzarse con otras tablas del modelo:

• zeus."role": resuelve el id_role con el nombre del rol (role_name).

• object_subtype: resuelve el sub_type con el subtipo de objeto del metamodelo (campo name).

• User-OU-Roles: al combinarse con los roles, permite analizar los permisos efectivos de cada usuario por unidad organizativa.

Ejemplos de consulta

Listado de permisos con el rol al que están asignados:

SELECT p.id_permission,
       r.role_name,
       p.permission_action,
       p.sub_type
FROM zeus."permission" p
JOIN zeus."role" r ON p.id_role = r.id_role
ORDER BY r.role_name, p.permission_action;

Permisos asignados a un rol concreto:

SELECT p.permission_action, p.sub_type
FROM zeus."permission" p
JOIN zeus."role" r ON p.id_role = r.id_role
WHERE r.role_name = 'DPO'
ORDER BY p.permission_action;

Recuento de permisos por rol (útil como métrica para un data mart):

SELECT r.role_name,
       COUNT(*) AS total_permisos
FROM zeus."permission" p
JOIN zeus."role" r ON p.id_role = r.id_role
GROUP BY r.role_name
ORDER BY total_permisos DESC;