Errata exists for this version of the document.
AuditEvents are Events of AuditEventType that are generated as a result of an action taken on the Server by a Client of the Server. For example, in response to a Client issuing a write to a Variable, the Server would generate an AuditEvent describing the Variable as the source and the user and Client session as the initiators of the Event.
Figure 30 illustrates the defined behaviour of an OPC UA Server in response to an auditable action request. If the action is accepted, then an action AuditEvent is generated and processed by the Server. If the action is not accepted due to security reasons, a security AuditEvent is generated and processed by the Server. The Server may involve the underlying device or system in the process but it is the Server’s responsibility to provide the Event to any interested Clients. Clients are free to subscribe to Events from the Server and will receive the AuditEvents in response to normal Publish requests.
All action requests include a human readable AuditEntryId. The AuditEntryId is included in the AuditEvent to allow human readers to correlate an Event with the initiating action. The AuditEntryId typically contains who initiated the action and from where it was initiated.
The Server may elect to optionally persist the AuditEvents in addition to the mandatory Event Subscription delivery to Clients.
Figure 30 – Audit Behaviour of a Server
Figure 31 illustrates the expected behaviour of an aggregating Server in response to an auditable action request. This use case involves the aggregating Server passing on the action to one of its aggregated Servers. The general behaviour described above is extended by this behaviour and not replaced. That is, the request could fail and generate a security AuditEvent within the aggregating Server. The normal process is to pass the action down to an aggregated Server for processing. The aggregated Server will, in turn, follow this behaviour or the general behaviour and generate the appropriate AuditEvents. The aggregating Server periodically issues publish requests to the aggregated Servers. These collected Events are merged with self-generated Events and made available to subscribing Clients. If the aggregating Server supports the optional persisting of AuditEvent, then the collected Events are persisted along with locally-generated Events.
The aggregating Server may map the authenticated user account making the request to one of its own accounts when passing on the request to an aggregated Server. It shall, however, preserve the AuditEntryId by passing it on as received. The aggregating Server may also generate its own AuditEvent for the request prior to passing it on to the aggregated Server, in particular, if the aggregating Server needs to break a request into multiple requests that are each directed to separate aggregated Servers or if part of a request is denied due to security on the aggregating Server.
