Audit Logging

Introduction

Logging in the operation of SSoB means the creation of records from which the following questions can be answered:

  • Who initiated what or accessed what by what means and when?

  • Who had what access rights from when to when (derive system statuses)?

The aim of logging is to be able to trace significant changes in the product and applications in order to understand their security. The audit logging includes the selective event types monitor / activity / control.

Note - This feature is enabled by global.audit.enabled flag set while deployment.

PreRequisite

The Audit logging in SSoB requires pre-installed instance to FluentD service before setting the global.audit.enabled to true. Please check the prerequisite section for more information.

Audit data format:

SSoB follows CADF format to record audit events.

This standard provides all round information about the occurred event such as,

  • initiator (who),

  • target (on what),

  • observer (from/to where),

  • action (what),

  • outcome (result),

  • timestamp (when), etc.

SSoB Audit Common Service:

Deployment and Binding:

The Audit Common Service creates custom binding k5-auditlog-settings. This Audit binding contains a connectionString which should contains internal url of deployed FluentD service as mentioned in pre-requisite.

The secret can be read/updated by using k5-configurator Apis.

Implementation:

The internal components which needs to register Audit events makes HTTP call to the SSoB Audit Common Service. The Audit Common Service receives the audit log in API request body and validates.

The configured FluentD service url is invoked with the CADF Audit payload for log collection and further to the configured visualizer.

Note - In case of downtime / unavailability of FluentD service the audit payload is stored in log files within the Audit Common Service container.