...

Introducción

• La plataforma dispone de un sistema de auditoría que permite que cada operación que ocurre en la plataforma sea auditada. Entre estas operaciones

...

• se incluye inicios de sesión y cierres de sesión en el Panel de control, comunicaciones entre dispositivos y sistemas, etc.

• La información asociada a la auditoría se almacena en una ontología particular de cada usuario para que cada usuario pueda acceder a esta información de una manera simple (y, por ejemplo, crear un panel de monitorización). 

• Para esto, cuando un usuario se registra en la plataforma, se crea una ontología con identificación Audit_ <userName> 

• Los usuarios administradores pueden acceder a la información de auditoría de cualquier usuario al poder acceder a todas las ontologías existentes.

...

Acceder a los Logs de Auditoría en el Control Panel

Existe una opción de menú que permite acceder a esta funcionalidad:  TOOLS>My audit:

...

Se mostrará el siguiente interfaz:

...

Se podrá realizar consultas sobre los datos de auditoría filtrando por los atributos que se muestran:

• Resultado: ERROR, SUCCESS, WARNING (dependiendo del resultado de la operación auditada).

• Módulo: Componente desde el que se realizó la operación auditada (CONTROLPANEL,...).

• Operación: Tipo de operación auditada (LOGIN,JOIN, QUERY,...).

• Numero de registros a recuperar.

• Usuario: En caso de acceder con un usuario administrador, se podrá seleccionar el usuario del que se quieren recuperar sus registros de auditoria.

Al realizar la consulta, se mostrarán los registros en el panel inferior (ordenados por timestamp de inserción):

...

Para facilitar la visualización, se permite alternar con una vista en modo tabla:

...

Al estar almacenados los datos en una ontología de plataforma, también pueden consultarse a través del Query Tools, permitiendo realizar consultas y filtrados más complejos.

También pueden utilizarse los gadgets y dashboards de plataforma para realizar un análisis de la información almacenada (accesos desde dispositivos, etc):

...

Información técnica

Por defecto (si está habilitado), la información de auditoría se almacena en el Elasticsearch integrado con plataforma. Si no tiene Elastic desplegado, la información de auditoría se almacena en MongoDB.

...

Como puede verse en la imagen, cada registro de auditoría contiene esta información:

• MODULE: Módulo en el que ocurre la acción / operación. Puede ser uno de estos módulos:

  • CONTROLPANEL

  • APIMANAGER

  • IOTBROKER

  • FLOWENGINE

  • ROUTER

  • RTDBMAINTAINER

  • SQLENGINE

  • PERSISTENCE

• TIMESTAMP: momento en el que se ha producido la operación.

• USER: usuario que activa la operación

• OPERATIONTYPE: tipo de operación. Dependiendo del módulo será uno u otro. Puede ser uno de estos:

  • LOGIN

  • LOGIN_OAUTH

  • LOGOUT

  • JOIN

  • LEAVE

  • INSERT

  • UPDATE

  • DELETE

  • QUERY

  • SUBSCRIBE

  • UNSUBSCRIBE

  • INDICATION
    COMMAND

  • START

  • STOP

  • LOG

  • START_TRANSACTION

  • COMMIT_TRANSACTION

  • ROLLBACK_TRANSACTION

• MESSAGE: Detalle de la operación, dependiendo del OperationType.

• TYPE: Tipo de evento. Entre los siguientes:

  • USER

  • SECURITY

  • ERROR

  • DATA

  • GENERAL

  • IOTBROKER

  • APIMANAGER

  • FLOWENGINE

  • BATCH

  • QUERY

• [OPTIONAL] ONTOLOGY: Ontología afectada en la operación

• [OPTIONAL] DATA: la información adicional de la operación, por ejemplo, cuando se envía una instancia de una ontología para su inserción, contiene el JSON de la instancia recibida.

Auditoría de sistema

Además de la auditoría disponible para cada usuario, existe un auditoría de sistema centralizada en la que se guardan eventos de los módulos IDENTITY_MANAGER y PERSISTENCE, así podemos ver desde un punto único todos los eventos relacionados con las sesiones del IM y la creación/modificación de recursos en plataforma como entidades, dashboards, apis…

Image Added

API REST de Auditoría

...

Adicionalmente se disponibiliza un API Rest de Auditoria para permitir que los usuarios puedan auditar sus propias aplicaciones utilizando plataforma.

Accediendo a la sección de APIs del control Panel, aparecerá la nueva entrada Audit.

Image Removed

...

Hay disponibles 2 operaciones:

...

• La primera permite recuperar la información de un usuario filtrando por los campos: ResultType, Module Name, Operation, Number of Records y User. Se han visto con anterioridad los valores que pueden tomar. El filtro usuario sólo se tendrá en cuenta si la invocación la realiza un usuario con rol administrador. El valor por defecto del resto de los filtros es "all" lo que hará que no se tenga en cuenta dichos filtros.

• La segunda permite registrar información de auditoria desde aplicaciones/sistemas externos. La información a registrar tendría la forma:

...

Los valores de los campos a introducir se corresponden con los que se han visto anteriormente.

• formatedTimeStamp (fecha formateada)

• message (mensaje de auditoria)

• operationType (tipo de operación, se corresponde con Operation Type)

• otherType (permite categorización libre)

• resultOperacion (resultado de la operación, ERROR, SUCCESS, WARNING)

• timeStamp (fecha en formato long)

• type (tipo de operación, se corresponde con TYPE)

Al invocar a esta operación se realizará una inserción en la ontología de auditoría asociada al usuario que está realizando la invocación.

Dicha información quedará disponible y podrá ser explotada mediante los distintos módulos que ofrece la plataforma.

Mejoras en Auditoría

La plataforma dispone de un sistema de auditoría que permite que cada operación que ocurre en la plataforma sea auditada. Entre estas operaciones se incluye inicios de sesión y cierres de sesión en el Panel de control, comunicaciones entre dispositivos y sistemas, etc. Puedes consultar la información sobre cómo funciona la auditoría aquí.

Hasta ahora todas las operaciones que se realizaban a través del Digital Broker de Plataforma se categorizaban dentro de la auditoría como IoTBroker, lo que no permitía saber si la operación se realizaba desde un Microservicio (a través de un cliente Java, SpringBoot, Python…), un Pipeline del Dataflow o un Notebook. Dentro de las mejoras que se están implementando dentro del ámbito del Gobierno del Dato, hemos mejorado esta parte de la auditoría para tener mayor trazabilidad sobre los datos, por lo que ahora podremos saber específicamente desde dónde se están insertando, modificando o consultando los datos.

Modificaciones en el DigitalBroker

Se ha incluido en las operaciones del DigitalBroker un nuevo parámetro opcional tags, de tal manera que si dicho campo no se especifica la operación se categorizará como hasta ahora (IoTBroker), mientras que si añadimos dicho parámetro podremos especificar el origen del dato.

Para ello basta con introducir el parámetro tags con un valor con la siguiente estructura:

{"source":"<data_source>"}

Donde data_source puede tomar los siguiente valores: CONTROLPANEL, APIMANAGER, IOTBROKER, FLOWENGINE, ROUTER, RTDBMAINTAINER, SQLENGINE, PLANNER, OAUTHSERVER, DATAFLOW, NOTEBOOK, JAVACLIENT, PYTHONCLIENT

Modificaciones en clientes

Se han modificado los clientes para que a partir de la versión 3.1.0 las operaciones que provengan de dichos clientes se categoricen correctamente (JAVACLIENT, PYTHONCLIENT…)

También se han modificado las librerías propias de Plataforma del Dataflow, para que todas las operaciones que se originen desde el Dataflow sean categorizadas como DATAFLOW.