Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

ES | EN

Introduction


  • Onesait Platform has an audit system that allows each operation that occurs on the platform to be audited. These operations include logins and logouts in the Control Panel, communications between devices and systems, etc.
  • The information associated is stored in a particular ontology of each user so that each user can access this information in a simple way (and, for example, create a monitoring panel).
  • For this, when a user registers on the platform, an ontology is created with identification Audit_ <userName>
  • Admin users can access the audit information of any user by accessing all existing ontologies.

Accessing Audit Logs from the Control Panel


There is a menu option that allows you to access this functionality:  TOOLS>My audit:



Then you´ll see this interface:


You can make querys over the audit data by filtering the attributes shown:

  • Result: ERROR, SUCCESS, WARNING (depending on the result of the audited operation)
  • Module: Component from which the audited operation was performed (CONTROLPANEL, ...).
  • Operation: Type of audited operation (LOGIN, JOIN, QUERY, ...)
  • Number of records to recover
  • User: If you access with an administrator, you can select the user from whom you want to recover the audit records.

When making the query, the records will be displayed in the lower panel (sorted by insertion timestamp):



To ease visualization, it is allowed to alternate with a table view:


The data is stored in a platform ontology so it can also be consulted through the Query Tools, allowing more complex queries and filtering.

You can also use the platform's gadgets and dashboards to perform an analysis of the stored information (access from devices, etc.):



Technical Information

By default (if you have it enabled), audit information is stored in the Elasticsearch integrated with Platform. If you don´t have Elastic deployed, audit information is stored on MongoDB.

As you can see in the image, each Audit Log contains this information:

  • MODULE: Module in which the action / operation occurs. It can be one of these modules:
    • CONTROLPANEL
    • APIMANAGER
    • IOTBROKER
    • FLOWENGINE
    • ROUTER
    • RTDBMAINTAINER
    • SQLENGINE
  • TIMESTAMP: Moment in which the operation has occurred.
  • USER: User triggering the operation
  • OPERATIONTYPE: Type of operation. Depending on the module will be one or the other. It can be one of these:
    • LOGIN
    • LOGIN_OAUTH
    • LOGOUT
    • JOIN
    • LEAVE
    • INSERT
    • UPDATE
    • DELETE
    • QUERY
    • SUBSCRIBE
    • UNSUBSCRIBE
    • INDICATION
      COMMAND
    • START
    • STOP
    • LOG
    • START_TRANSACTION
    • COMMIT_TRANSACTION
    • ROLLBACK_TRANSACTION
  • MESSAGE: Detail of the operation, depending on the OperationType.
  • TYPE: Event type. One of the following ones:
    • USER
    • SECURITY
    • ERROR
    • DATA
    • GENERAL
    • IOTBROKER
    • APIMANAGER
    • FLOWENGINE
    • BATCH
    • QUERY
  • [OPTIONAL] ONTOLOGY: Ontology affected in the operation.
  • [OPTIONAL] DATA: Additional information of the operation, for example when an instance of an ontology is sent for insertion, it contains the JSON of the received instance.

Audit API for applications

Additionally, a REST API for Audit is available to allow users to audit their own applications using the platform.

Accessing the API section of the Panel control, the new Audit entry will appear




There are 2 available operations:

  • The first one allows to retrieve an user's audit data by filtering through the fields: ResultType, Module Name, Operation, Number of Records and User. The values ​​they can take have been seen before. User filter will be used if the invocation is made by a user with an administrator role. The default value of the rest of the filters is "all" (which will not take these filters into account).
  • The second one allows recording audit information from external applications / systems. The information to register would have the form:


Fields values must correspond to those seen previously.

  • formatedTimeStamp (formatted date)
  • message (audit message)
  • operationType (type of operation, corresponds to Operation Type)
  • otherType (allows free categorization)
  • resultOperacion (result of the operation, ERROR, SUCCESS, WARNING)
  • timeStamp (date in long format)
  • type (type of operation, corresponds to TYPE)

When invoking this operation, an insertion will be made in the audit ontology associated with the user who is performing the invocation.

This information will be available and can be exploited through the platform.


  • No labels