Ok I know time is over, but it is better to do something still now than nothing.
GDPR asks to retain audit logs to explain breaches and exploit on the personal data. The penalties set for breaches of GDPR can be up to 4% of a company’s annual global turnover. When an exploit is found, you have to explain what data you lost and how.
This drives to a strong log retention but also your local state might ask a minimum time retention (In France we need to keep at least one year of email transaction).
However by essence the log retains a lot of personal data, probably hard to filter and hide…For example the IP address. These information must be kept on the server and be sure that nobody except your system administrators can read them.
There is a lot of rules you must comply when you are GDPR concerned, not sure it is really the NS goal, but we could bring some features. Some are already available like the log retention policy (template based, four weeks for the community OS, 52 for the enterprise) but we could add also the log encryption (PGP for example with the compression) to ensure that even if an exploit is made, logs are not readable … easily.
I believe it is an aspect that we do not talk much, maybe time to start a thread.
EDIT: With PGP only the public key is hold on the server and used to encrypt, the private key is not hosted and it is a necessary key to read the files
Having a template-base policy where the admin can explicitly define a log retention policy other than the defaults would be useful. Agreed that it is not an NS goal, but its definitely a good to have and it makes a sysadmin’s life a little easier from not only a GDPR perspective, but a general system configuration and other potential regulatory compliancy (aside from GDPR).
Encrypting the logs is a nice to have, but almost quite pointless if I may be honest. If the hacker is able to get to the logs with an exploit, then the chances are fairly high that they have the relevant permissions (or abilities/skill-set to gain the relevant permissions) to read the logs. Also GDPR does not require encryption, it only recommends encryption where appropriate.
A review of the permissions for the access to the logs to may be a wiser move both in the short and longer term. By permissions I mean file permissions for both human and system user access for both read and write (just because you have write access does not mean you require read access and vice versa).
I need to give back the honor to Caesar, excuse my translation…
The original idea comes from @davide_marini, you can find a card on the bugtracker to adapt the squid logrotate configuration
If you want to set the week retention, then do
config setprop logrotate Times 52
signal-event nethserver-base-update
you can check other options by
[root@prometheus ~]# config show logrotate
logrotate=configuration
Compression=disabled
Rotate=weekly
Times=52
However some services bring their own rotation policies, therefore either we have to change the setting when we can, or create a template if we do not own the rpm (epel for example)
The encryption could be only by db command (by the public key), the private key must not be owned by the server and the decryption needs it.
Adapt all services to comply the log retention policy could be a nice first shot, after that some services are probably not really important and we could not care of them.
Yep this decision is up to lead dev, I do not have a full vision on this, but the update could be pushed without a minor release and we should not delay 7.5