One of X-Road’s key features is to provide undeniable and tamper-proof evidence of data exchange. X-Road does this by digitally signing, timestamping, and logging all the messages processed by the Security Server. The logs can be used in a court proceeding as evidence. This logging feature is known as the message log. These previous blog posts provide additional information about the message log:
Depending on the data exchange use case, indisputable proof that can be used as legal evidence may be required. On the other hand, regular application logs provide enough information in many cases, and no additional guarantees are needed. In the latter case, X-Road message logs may not be required, or it's enough to log only the metadata. To better support different kinds of use cases and logging requirements, message logging has been made more configurable in X-Road 7. This blog post provides more information about different configuration alternatives available in X-Road 7.
Supported alternatives in X-Road 7
Starting from X-Road 7.0.0, the Security Server supports three options for configuring message logging:
Full logging
The whole message, including both message body and metadata, is logged.
The log records can be verified afterward, and they can be used as evidence.
Timestamping service is required.
Metadata logging
Only metadata which includes X-Road-specific message headers is logged while the message body is not logged.
Verifying the log records afterward is not possible, and they cannot be used as evidence.
Timestamping service is required.
No message logging
Message logging is fully disabled. Neither message body nor metadata is logged.
No log records are generated.
Timestamping service is not required.
Regardless of how logging is configured, messages exchanged between Security Servers are always signed and encrypted. Also, when full logging or metadata logging is enabled, the Security Server produces a signed and timestamped document (Associated Signature Container - ASiC) for each request and response.
Is it possible to combine different alternatives?
Full logging and metadata logging can be configured on Security Server and subsystem level. When the Security Server level configuration is used, the same configuration is applied to all the subsystems. Instead, when the subsystem level configuration is used, the configuration is applied to specific subsystems only. In addition, combining the Security Server and subsystem level configurations is also possible, e.g., set metadata logging on the Security Server level and enable full logging for specific subsystems only (or vice versa). Instead, message logging is fully disabled on a Security Server level and it cannot be combined with the other alternatives. Therefore, a subsystem that requires full or metadata logging should not be registered on the Same Security server with a subsystem that requires entirely disabling message logging.
Which alternative should I use?
Multiple factors should be considered when selecting the logging configuration for a data exchange use case. First, there may be legal requirements regarding logging and retention period of the logs. Second, some logging-related requirements that all the member organisations must follow may have been set by the X-Road operator. Third, there may be some organization-specific requirements for different kinds of use cases. Fourth, the other data exchange party of a specific data exchange use case may have requirements for logging. It's essential to be aware of the different requirements and configure logging accordingly.
To make the decision easier for member organisations, X-Road operators may define a default value for logging-related configuration in a country-specific meta-package. Without any country-specific configuration, the Security Server uses full logging by default. For example, suppose the operator requires using metadata logging by default. In that case, the operator can set the configuration in the country-specific meta-package so that all member organisations use metadata logging by default. The configuration must be updated manually only if some other logging alternative should be used. However, fully disabling message logging is not possible using country-specific meta-packages. Instead, it must be configured separately by the Security Server administrator.
How does the logging configuration affect the Security Server in general?
The logging configuration has some direct and indirect effects on the other features of the Security Server. Fully disabling logging increases the overall performance, reduces disk space consumption, and doesn't require a timestamping service to be configured. Also, moving the message log archives to external long-term storage is not needed since, without the message logging, there are no archive files either. Overall, fully disabling message logging improves the performance and decreases the environmental footprint of the Security Server. If logging is disabled in the whole X-Road ecosystem, running the ecosystem without a timestamping service is possible. However, even if performance and environmental reasons are essential, legal and administrative requirements must not be forgotten.
All the changes related to the message log encryption and archive grouping will be covered in a separate blog post together with other new encryption features.