Skip to main content

Audit trails requirements

Every Document Provider has the right to define its own audit trails system. The following document describes the minimum requirements on audit trail for each integration with e-Box Federated Enterprise. So this step is needed so that the e-Box integration team checks that those minimum requirements are fulfilled and plays a role as advisor for the complete audit trails process.

Context​

  • The eBox Enterprise system allows a company to consult through the eBox Enterprise GUI its own documents that are managed in external Document Providers (DP) that were received by the DPs from public entity Document Senders (DS).

  • This document is based on the official documentation of the audit trail requirements defined at BOSA. Since we both manage e-Box, we uniformize the most this part of the on-boarding process There are some subtilities linked to the business of e-Box entreprise and for BOSA to the business of e-Box citizen, so we will manage a documentation at e-Box entreprise and ONSS too.

Audit Trail - Audit Logging​

The scope of audit trail or also called audit logging for EBox Enterprise system is to manage information that proves in a non-repudiable way "who" or "what" did what and when on "enterprise-owned data" in the EBox Enterprise system. "Who" might be the "owner" of the data or the data might have a different owner. Other requirements to be imposed on all EBox Enterprise subsystems when writing audit information :

Audit trail REQ NumberRequirementDescription
ATREQ01Non-repudiationAudit logging data must not be modifiable and not be deletable within the legal retention period of 10 years. From the first January 1st onwards after the moment the action was performed for which the audit logging was written (so in worst case might be almost 11 years). Non-repudiation applies on the phases when the audit logging is written or being written.
ATREQ02Not overproportionalAudit logging data content must be proportional meaning : minimal to no duplication, only audit info that is relevant for the audit purposes.
ATREQ03Respects privacy requirementsAudit logging data must be secured so that it could only be consulted when you have the appropriate authorizations. This also means that searchable metadata on audit data must be properly protected (e.g. hash citizen identification number if part of metadata).
ATREQ04Only audit log successful transactionsOnly audit log the transaction that has to be audit logged when it is successful.
Description for ATREQ04​

This means for API Calls:

  • if API Call is a read-only operation (GET): don't audit log if it fails with HTTP technical error code, timeout, ...
  • if API Call is a write operation POST / PUT / DELETE / PATCH: always audit log, except when it is certain that the transaction didn't succeed (e.g. socket timeout because server not available). You might have borderline cases : e.g. a receive timeout occurs during the POST but in the end the transaction might or might not have succeeded on server-side : in this case audit log (the API Call response code written in the audit log will indicate the timeout situation that occurred)

Audit Trail Requirements for DP​

Audit logging keyAudit logging information
TIMESTAMPTimestamp of the incoming API call. Format : ISO 8601 datetimeyyyy-mm-ddThh:mm:ss.ffffff with timezone CET GMT+1
SUBJECT_TOKEN_HASHEDSHA-256 hash of the OIDC access token (in case the incoming call uses OIDC Token)
CLIENT_IDclientId retrieved from the OAuth token (in case the incoming call uses OAuth Token)
API_CALL_REQUEST_METHODAPI request method (POST, GET, ...)
API_CALL_REQUEST_URLAPI request URL
API_CALL_RESPONSE_CODEAPI call HTTP response code (or generic error code in case of timeout)
API_CALL_DETAILSAPI call details : see below
API call details: exemples​
  • GET /ebox/messages
    • messageId
  • GET /ebox/messages/{messageId}
    • messageId
    • paymentData.paymentDataId
  • GET /ebox/messages/{messageId}/attachments/{attachmentId}/content
    • messageId
    • attachmentId
    • contentId
  • GET /ebox/messages/{messageId}/paymentData
    • messageId
    • paymentDataId
  • POST /ebox/messages
    • attachments.{attachementId}.size
    • attachments.{attachementId}.digest.digestValue
    • attachments.{attachementId}.digest.digestMethod
    • messageId (returned in response)
  • POST /ebox/messages/{messageId}/reply
    • attachments.{attachementId}.size
    • attachments.{attachementId}.digest.digestValue
    • attachments.{attachementId}.digest.digestMethod
    • messageId (returned in response)