GDPR > IP Anonymization


(Fedir RYKHTIK) #1

Discussion Topic

As I mentioned in general GDPR topic (Making TYPO3 GDPR-ready), some important action should be done to make TYPO3 GDPR-ready.

Here’s what I would like to propose about IP anonymization implementation. Please tell me, what do You think about it. If it’s a good way of doing, I could take care about the implementation. If You have some advices, better propositions, I’ll be happy to read Your propositions.

Implement IP anonymizer.

We could use https://packagist.org/packages/geertw/ip-anonymizer or implement some internal fork / development of it, if there are any special needs. Personally, I prefer to use specialized external modules, so it’ll be easier to move further, all together.

It should be possible to configure it from TYPO3_CONF_VARS (masks, etc).

$GLOBALS['TYPO3_CONF_VARS']['SYS']['IpAnonymizer']['ipv4NetMask'] = "255.255.255.0";
$GLOBALS['TYPO3_CONF_VARS']['SYS']['IpAnonymizer']['ipv6NetMask'] = "ffff:ffff:ffff:ffff:0000:0000:0000:0000";

Implementation should be done in a transversal way, so the anonymization could be called in any time in any place by any extension, which uses private data.

Implement optional anonymization it in all places, where it’s stored in the DB sys_log:

  • typo3/sysext/core/Classes/Authentication/BackendUserAuthentication.php
  • typo3/sysext/core/Classes/Error/ErrorHandler.php
  • typo3/sysext/core/Classes/Error/AbstractExceptionHandler.php

Pro

  • TYPO3 will be GDPR compliant and will allow IP anonymization.

Con

  • Will be harder to implement security rules, currently based on IP.
  • Should be done carefully with TYPO3 Security Team control, so no potential holes in current TYPO3 security model.

Organizational

Topic Initiator: fedir
Topic Mentor:


(Stefan Neufeind) #2

Note that at least for sessions the locking already “masks” those IPs, so only the first parts (/24) of an IPv4-address are saved in DB fir you set lockIP to 3 (default) etc.
For logging that is true of course.

Maybe we can use part of what is there to “anonymize” IPs in the locking-parts also for logging, exceptions etc. (There is a patch targeting locking for IPv6 in review currently.)


(Stefan Neufeind) #3

For other tools like log-analysis afaik IPs aren’t just “masked” to the /24-boundary or so but instead mapped, so that you can still correlate which accesses came from the same IP but don’t know the actual IP itself. The key to anonymize that IP would change once per day or so. Such more complex solutions try to find a way between de-personalisation and still not breaking logfile-analysis completely. Hmm …


(Benni Mack) #4

Well, it’s about tracking the IP, so the “limit to IP” feature could stay. However, this makes it really harder to figure out who logged in to your system.

I’m thinking of all the iCloud/Google security features “Hey, somebody from South africa logged in to your account, this is unusual, please check if this isn’t you”.

My underlying question is, if we want to anonymize IPs by default or have that as an option.


(Markus Klein) #5

If we follow the law, the answer is pretty clear: by default.

This is still possible, as one can store such info - actually a conclusion based on source data like IP - and work with the conclusion instead of the raw source data.

Not sure about this, because mapping is a bi-directional function. It helps to hide the IP from the user of the stats tool, but it does not safe us from storing the IP.


(Fedir RYKHTIK) #6

For some internal not public projects, as intranets, we could keep the possibility to track full IP addresses. I would keep this possibility. But hide it by the /24 mask in the default configuration.


(system) #7

This topic was automatically closed after 28 days. New replies are no longer allowed.