Icinga Web and GDPR / DSGVO

Introduction into GDPR / DSGVO

How does it apply to Icinga Web?

Icinga Web 2 doesn’t provide a registration interface where users need to explicitly agree on a ToS for example. User management is totally handed over to either locally by the responsible admin, or external auth providers.

Neither does Icinga Web 2 provide terms of service where one need to explicitly agree on. If you’ve built a commercial product on top of Icinga Web 2 where this is required, it is your task to fulfill the GDPR requirements.

German law requires an additional thing for publicly available websites: Have the legal notice with the one responsible on all pages (you can see such here on Discourse). If you’re putting Icinga Web 2 into public domain, you also need to take care about this by yourself.

Request User Related Data

Users may request all their stored data. Not immediately, that’s the point, responsible persons and organisations have time to collect and send the data. Which in term is rather simple, as you as site owner can extract the details from the database.

There’s no audit or session logging implemented by default, nor are IP addresses stored. The latter may be available in your apache logs where you need to take care of. German data retention laws might already cut this. If you have the audit web module installed, that should be taken into account.

The most common thing you might need to extract are acknowledgements and comments, created with the user’s name. Still, that’s something I wouldn’t explicitly see under the terms mentioned inside the GDPR, since someone explicitly needs to grant a user the permission to do so. That’s to be discussed and might also generate troll activity in companies and communities testing out the effective meaning of the GDPR compliancy.

Right to be forgotten

The right to be forgotten requires one to anonymize the data which is related to this user account. If you are working at a company which grants you access to Icinga Web, there’s a certain possibility that your work contract prohibits such deletion or anonymizing. That’s to be discussed and learned from upcoming changes.

Password Changes and Two-Factor-Auth

I don’t know of any law or regulation which enforces a password change on first login. That’s also not mentioned inside the GDPR or other regulative policies. One thing which will become important in the future is the possibility to have 2-factor-auth (2FA) as an additional layer of security. One could also use an existing SSO provider with e.g. oauth and put that on top of the web application. On the other hand, Icinga Web doesn’t offer a “self service” where users can request a password reset, that’s something you’d need to build on top by yourself too - depending on the auth method you’ve configured this may be leveraged into your companies AD and affect many other applications too.


Other than that, the GDPR mainly affects organizations and companies using your data. Web applications could likely make it easier for your usage case (e.g. have a ToS, accept it, terms of consent, request data, forget data, add more secure auth methods). I would start with the policies and requirements in your company and see how far you need to adjust data collection, not only for Icinga.

In terms of this community platform, you can already see that you’re required to explicitly accept the ToS. It is also possible to use external oauth providers (GitHub, Twitter) for a more secure login, they also provide 2FA. For Discourse itself, we may need to provide the data stored here in an applicable format on user’s request. That’s currently discussed in this topic and Discourse provides a tool set to anonymize/delete users as well as extract their data on request. Users can download their data too from their profile’s activity tab (“Download all”).

Your thoughts on the matter? :slight_smile:


1 Like

Hi @dnsmichi,

in general your bottomline isn’t wrong :wink:
On the other side even more things come in place, e.g. downtime / ACK logs or comments of users. They might contain personal data.
But the rights of data subjects are “relative”, especially when the service is used internally and you are data subject as an employee. Then maybe legal duties are also in place (e.g. that you have to track actions of your employees and so on…).

So I would be fine if the tool is used internally by employees. Sure, you have to document that process and inform the users about their personal data beeing processed. Also a rule for deletion should be in place. But there are a lot of so called “legitimate interests” of the business / company that a right for deletion of a former employee might be neglected.

If customers come into that game and use your service actively it might get a lot harder…

Just my two cents,

1 Like