EU GDPR compliant logs

Note EU law does provide exception for the logging of IP addresses, which are classed as personal data, for the purposes of maintaining system security. (See Article 6, Paragraph 1, Point F, Recital 49) for some thoughts on the matter see this blog post which also provided the basis for this article.

Use gnuPGP to create key pair. Archive the private key securely. Import the public key onto the relevant machines and use it to encrypt the stored logs.

Note you will need the private key to view them in the future.

The configure logrotate as follows and taken from the same blog post quoted above:

dailyshredcompresscompresscmd /usr/bin/gpg2compressoptions --encrypt --default-key your-key-idcompressext .gpg/var/log/httpd/access* {    rotate 90}/var/log/httpd/error* {    rotate 180}/var/log/httpd/mod_security* {    rotate 400}

In the above example, access logs are deleted after 90 days, error logs after 180 days, and ModSecurity logs (which would usually contain suspicious activity), are retained for 400 days. After these time periods, the logs are securely erased using the shred utility.

The "daily" setting means the logs may be unencrypted for up to 24 hours, after they have been written. During this time window log data will be in clear text. This enables administrators to inspect the logs and automated tools to analyze and process the logs (e.g. Fail2Ban). These tools use the information gleaned from the logs to automatically detect and prevent unauthorized or unlawful access to the system.

By setting log rotation to "hourly" the window during which logs exist in unencrypted from on the system can be reduced. Alternatively logs could be sent to a remote fully encrypted log server or storage space. Depending on the volume of logging data generated by your system this may adversely impact performance and network congestion. Further more this approach also complicates setup and operation of local security software that relies on log analysis for threat detection and prevention.

Closing thought:

Any IPs by people caught trying to illegally log into a system and those blocked and logged by the firewall do not fall under the regulations in my view as they are not actual customers or users nor are the hosted offerings targeted at these people. Of course I am not a lawyer, just a humble lay person...

Update, June 2020

Obviously GDPR compliance goes way beyond your logs. The journey towards launching a compliant system and then staying in compliance can seem a daunting one. There are resources a plenty to help you get there. However, this particular article I came across recently stood out to me as a good starting point, particularly with regards to auditing your system:

https://linux-audit.com/gdpr-compliance-technical-requirements-for-linux-systems/

The site itself also provides valuable pointers with regards to maintaining good security posture and offers an introduction to the Lynis project lead by the site's publishers. Lynis will analyze your system's current configuration for potential points of vulnerability and come up with a set of human readable warnings and suggestions on how to harden your server.