Change (or not) the user's data deletion policy

(Stéphane de Labrusse) #1

The GDPR protects the data of users on your systems, you must for example remove all the data of users if asked and you must do a lot of stuffs more of course(thank GDPR). But when you are an enterprise, the data of your employee might be owned by the company, and even if the employee left the company, you could need some of his email, files in his home, addresses of his customers, his agendas…

Actually when you delete a user in the server-manager, you remove all the data owned by this user.

Hence we could have two ways to protect the data of a possible erasure, one conservative, one active

  • We could only state in the documentation, if you want to keep the data of a user, please deactivate the account in the server-manager…simple and efficient, but I must add too the @giacomo’s sentence : Less code, less bug :smiley:

  • We could make a global property in the esmith database and do not remove the data when the event user-delete is launched. This way might be better for me because in a real environment, you are several admin and an error could occur…damn I removed the user. Of course backup are for this situation, restore data removed.

Delete user from active directory
(Mark Verlinde) #2

Up front, I am not a system administrator; my insight can be completely wrong :sunglasses: ; and am curious about the opinion of experienced sys-admins

(As said in one sentence before @gitbub)
I think deleting the user (primary key) and keeping the data (records) in the live environment on disk and in the databases of the applications seems to me as a bad thing to do.

Ideally the user-data of the removed user would be retained on a more static place. To make it even more complex ( sorry @giacomo) : do this asynchronous by a “garbage collector”. A cron job querying the account provider for non-existing users and moving the user-data to this static place…(This would make it work with all variants of account-providers)

But let’s take some distance and try to describe the behavior of the solution with the simple keywords:
{ shall , shall-not , may }

my 2ct:

The solution shall :

  • make it possible to remove all user-data immediately
  • make it possible to retain user-data
  • make it possible to delete all user date any given time after retention

The solution shall-not :

  • Orphan user-data, making it very hard to delete all user-data any given time after retention.

The solution may :

  • Keep retained user-data in the live environment.
(Davide Principi) #3

Really nice idea Mark! An original way of considering the remote accounts provider use case…

Could you make an example?

(Mark Verlinde) #4

do not want to rule out:

(Davide Principi) #5

Thank you for clarifying!

What are you thinking about?

(Mark Verlinde) #6

Do not have a clear vision. :grinning:

In my mind is the project-data archiving after finishing it I encountered a lot, move the (static) project data to a “cheap” storage.
Do not bother cleaning it up, just move it out of the (expensive) live environment. You may argue user-data is so limited this is not really a issue… But carrying it around forever does not appeal to me.

(Davide Principi) #7

I like the garbage collector approach because it allows to decide how long data is to be retained.

However we have to think about an easy implementation :thinking:

(Mark Verlinde) #8

You are right, did not think of this. You may retain the user-data for x period of time before the “garbage collector” kicks in.

May be not easy, but it can be simple (that are the most rewarding ones)

However still curious about the 2’ct of experienced sys-admins :grinning:

(Michael Träumner) #9

In my opinion the admin should choose to delete all data by deleting a user or to save the data. To save the data I like the way of @mark_nl

It should be possible to delete all the data after a time is “one click”.

(HF) #10

I believe there are some more legal considerations to make.

Employee data is always owned by the company. Data of a consumer must be GDPR compliant and to be wiped in an instance on first request.

I myself am using Nethserver in commercial environments, where the data is always owned fully by the client. I do not even know what they store, but still I am ‘processing’ personal data, or at least that could be the case so with that possibility, my company serving clients based on Nethserver, has to be fully GDPR compliant.

It is a legal issue that, in my opinion, should be discussed first. For a US customer (not an employee) must have choices, where a EU customer can demand…

My 2cents

(Giacomo Sanchietti) #11

I like the idea and it’s really similar to mine.
My objection is the usual: the implementation is tricky and error prone.

We already are in this scenario :frowning:

I agree! We are waiting input from our privacy consultant since a month …

Finally, I think that Mark solution is the only viable one, but does it worth the effort?

(HF) #12

I think so, for not being GDPR compliant or adhere to the GDPR rules may lead to a fine of 4% of global revenue or 20 million euro’s, whatever is the greatest amount :slight_smile:

(Giacomo Sanchietti) #13

The GDPR doesn’t require a software implementation of listed policy.
You are just required to have some procedures to handle user data, so you can comply even with a simple documentation. You just need to make sure that are procedures are available on request.

(HF) #14

And those procedures must be there to be able to EXECUTE GDPR compliancy. So we have the required paperwork, and the actual execution and compliancy.

Just having some procedures on paper and (for a bigger company) a compliance officer does not cut it.

Good talk and exchanging thoughts. With me in this is a friend who is a lawyer specializing in GDPR.

(Davide Principi) #15

:slight_smile: Yes, we are here to “ease the life of the sysadmin” /cc @alefattorini

(Davide Principi) #16

We could also base our deletion policy on the account “expired” state. Once an account is both “disabled” and “expired” its data is automatically removed.

Active Directory allows an account to be enabled/disabled but also to set an expiration time. That could be the point in time when any data associated with it is deleted. And it works also with a remote account provider.

Of course, it will be an opt-in policy, I’d say disabled by default.

(HF) #17

Does LDAP allow that too ?

(Davide Principi) #18

It depends on too many things… Maybe a local ldap provider can be configured for that, but as openldap is deprecated in rhel 7 we have to plan for directory 389 too

(Gabriel GHEORGHIU) #19

Hi everybody!

My opinion about this subject.

We have three possible situations for NethServer utilisation:

  1. for home -> no GDPR rules. Q: are we sure? :grinning:
  2. for commercial environment “where the data is always owned fully by the client” (as @LayLow said), generally for hosted web servers, hosted e-mail servers, hosted backups, … -> “Data of a consumer must be GDPR compliant and to be wiped in an instance on first request”.
  3. for company environment where “data of your employee might be owned by the company, and even if the employee left the company, you could need some of his email, files in his home, addresses of his customers, his agendas …” (as @stephdl said).

In any of the above situations we would use NethServer, I do not think an automatic data erasure solution would be indicated, at least for the reason given by @giacomo: “Less code, less bug”.

Also, I don’t think that an automatically erase mechanism will make NethServer to be GDPR compliant.
And I don’t know if a software must or can be GDPR compliant.
It’s not about “GDPR compliant”, it’s about “GDPR rules”.
As far as I know and understand, in a few words, to respect GDPR rules, means that the users data are kept safe, can be deleted by request and there is a mechanism to audit the access to these data.
NethServer keep data safe, there is at least an audit mechanism (samba audit module) and by request, the Administrator can delete data.

Best regards,
Gabriel

(Stéphane de Labrusse) #20

sure, the sysadmin is responsible at the end, never the nethserver project (at least I hope :D)