31. 03. 2025
NetEye, Service Management
The regulations of the GDPR in many cases require that some user data is not always present, and / and or that they are anonymized. So I would like to show you now how NetEye 4 responds to this new requirement.
NetEye 4 is composed of various modules. In the NetEye 4 Log Manager, we have Elastic Stack 6.5 with Search Guard.
Search Guard is an Open Source security plugin for Elasticsearch and the entire Elastic Stack. Search Guard offers encryption, authentication, authorization, audit logging, multitenancy along with compliance features for regulations like GDPR, HIPAA, PCI DSS and SOX.
In NetEye 4, we have the best solution that Search Guard offers: the Compliance Edition. At the link here you can see the feature comparison between the various versions:https://search-guard.com/product/
I decided to try the feature fields anonymized, role, role mapping, and index security.
In order to get an example of an anonymized field in NetEye 4, I stored one simple log that I downloaded from the Elastic Stack samples, and loaded it into the Elastic Stack using Logstash. It’s also possible to define a new server in Icinga Director with one of the Safed profiles as shown in the following screenshot:
Then in the Log Manager section you can configure the server you just created in order to permit it to send via rsyslog the log stored locally on NetEye, sign it, and send it to Elasticsearch using Logstash. For this it’s necessary to click on Deploy Server Configuration as shown in the following screenshot:
Now it’s time to anonymize for example one field for a group of users. I selected the IP information and created a new role in Search Guard. I selected a Search Guard session and created sg_index_logstashin order to see just the Logstash index with an anonymized IP field as shown here:
Next I created a background role called read_logstashand then created a new role in Icinga 2 called rolebwith a corresponding unique member called userb.
So I ran a test. I selected a Logstash index as the root user and saw the IP field:
Instead, userbcould only see the anonymized version of the IP address.
Finally, to test that userbcould not open the other index, I tried to open yet another index and correctly saw this error message:
Franco Federico
Hi, I’m Franco and I was born in Monza. For 20 years I worked for IBM in various roles. I started as a customer service representative (help desk operator), then I was promoted to Windows expert. In 2004 I changed again and was promoted to consultant, business analyst, then Java developer, and finally technical support and system integrator for Enterprise Content Management (FileNet). Several years ago I became fascinated by the Open Source world, the GNU\Linux operating system, and security in general. So for 4 years during my free time I studied security systems and computer networks in order to extend my knowledge. I came across several open source technologies including the Elastic stack (formerly ELK), and started to explore them and other similar ones like Grafana, Greylog, Snort, Grok, etc. I like to script in Python, too. Then I started to work in Würth Phoenix like consultant. Two years ago I moved with my family in Berlin to work for a startup in fintech(Nuri), but the startup went bankrupt due to insolvency. No problem, Berlin offered many other opportunities and I started working for Helios IT Service as an infrastructure monitoring expert with Icinga and Elastic, but after another year I preferred to return to Italy for various reasons that we can go into in person 🙂 In my free time I continue to dedicate myself to my family(especially my daughter) and I like walking, reading, dancing and making pizza for friends and relatives.
Author
Latest posts by Franco Federico
17. 02. 2025
Unified Monitoring
Monitoring Printer Logs
10. 12. 2024
Log-SIEM
Let’s Discover ES|QL
18. 10. 2024
DevOps
My Laptop Is Broken …. What Can I Do?
20. 08. 2024
APM, Log-SIEM, Unified Monitoring
A Journey through Elastic Integrations