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 6 Next »

Securing audit trails and making them available for the Get Audit Trails functionality

  • Letting each client and pillar ensure their audit trails individually, and including functionality to provide audit trails to Get Audit Trails function
  • Letting each client and pillar ensure their audit trails via a specific sub-SLA, which the Get Audit Trails function can access directly

To support securing of audit trails we use the PutFile functionality along with special AuditTrail-SLAs and to access logs we use the GetFile functionality along with the special AuditTrail-SLAs.The GetAuditTrails Client provides the GetAuditTrail functionality to the user.

A special Audit Trails Servcie is responsible for securing audit trails is not in the illustration but is also a possibility.

which asks the pillars and other clients for logs to secure or receives request to secure audit trails from pillars and other clients.

The Get Audit Trail Client collects audit trails from different parts of the bit repository, i.e. audit trails information from pillars, clients, bus, alarms. These audit trails must therefore be secured either on individual initiative or by a dedicated client. The approach described here is that audit trails are ensured by letting pillars and clients secure copies on other pillars according to a Log-SLA. Especially the integrity client is important here.

An alternative could be to introduce Log-client secures the log, either by requesting log-updates from pillars and clients  or the pillars and clients request log-updates on the log-client.But the recommendation here is that Pillars and clients secure their own logs.


  • No labels