Elastic ist ein sehr mächtiges Werkzeug, mit dem man viele Daten sammeln, grafisch aufbereiten und vor allem Zusamenhänge erkennen kann. Diese Daten können durchaus sehr sensibel sein und auch unter die Datenschutzgrundverordnung fallen. Das beginnt z.B. bei Windows Logs vom Active Directory Server. Da kann man nachverfolgen, wer sich wann angemeldet hat. Falls man einen Proxy für den Internetzugang betreibt, werden dort auch die IP Adressen der Firmencomputer abgespeichert. Da die IP Adressen entweder fest vergeben oder doch zumindest zu bestimmten Computern/Personen zugeordnet werden können, ist auch diese Information äußerst datenschutzrelevant.
Es gibt mehrere Möglichkeiten die Datenerhebung im Elastic DSGVO konform zu gestalten. Die sauberste Lösung ist sicherlich, die Daten gar nicht erst zu erheben. Man könnte z.B. bei den Daten, die vom Apache-Proxy gesendet werden, die IP Adresse einfach heraus lassen. Nebenbei bemerkt, sollte man auch auf die lokalen Apache Logs achten, dass diese durch z.B. Logrotate nicht älter als 7 Tage sind. Die DSGVO verbietet nämlich nicht grundsätzlich auch solche Daten zu erheben. Man kann sie für einen gewissen Zeitraum aufbewahren, wenn es zur Betriebsicherheit nötig ist. Im Unternehmensumfeld ist es durchaus sinnvoll, dass man bis zu einer Woche auf diese Daten zurück greifen kann. Bei bestimmten Daten kann dieser Zeitraum auch länger sein. Dabei sollte man immer im Hinterkopf behalten, was man einem Polizeibeamten als Begründung sagen würde, warum man diese Daten so lang vorgehalten hat. Dieser Blickwechsel kann durchaus helfen, die Notwendigkeit doch etwas herunterzuschrauben.
Wenn es sich nicht vermeiden lässt oder zu aufwändig ist, die Daten nicht zu erheben, muss man dafür Sorge tragen, dass die Daten innerhalb eines bestimmten Zeitraumes wieder gelöscht werden.
Rollover
Elasticsearch bietet dafür einen so genannten „Rollover“. Da werden automatisch Daten die älter als der gewünschte Zeitraum sind gelöscht. (Der Rollover ist ein sehr komplexes System, bei dem man z.B. Daten auch auslagern kann, indem man diese von High-Performance Servern auf günstigere Storage Systeme auslagert.)
Damit dieses Rollover automatisch greift, erstellt man am Besten eine Template für den gewünschten Index. Dieses Template verknüpft man dann mit der entsprechenden nach-7-Tagen-Löschen-Policy.
Man kann das Ganze natürlich auch manuell, oder mit einem cronjob lösen.
POST web-log-*/_delete_by_query?refresh&slices=5
{
"query": {
"range": {
"@timestamp": {
"lt": "now-7d"
}
}
}
}Dieser Befehl löscht alle Daten der web-log-* Indexe (falls es mehrere gibt), durch den „range“ Parameter gibt man den Zeitraum an, dass alles was älter („lt“ = less than) als „Jetzt – 7 Tage“ ist, gelöscht wird.
Falls man dies gleich generell für bestimmte Indizies veralgemeinern möchte, empfehle ich folgendes Vorgehen:
- Eine Policy anlegen, die nach 7 Tagen die Daten automatisch löscht
- Ein Template für die entsprechenden Indizies (im Beispiel windows-defender-*) erstellen
- Einen Index anlegen, der dann automatisch von Elastic immer wieder überschrieben wird
PUT _ilm/policy/windows-defender-policy
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_age": "7d"
},
"set_priority": {
"priority": null
}
}
},
"delete": {
"min_age": "0d",
"actions": {
"delete": {
"delete_searchable_snapshot": true
}
}
}
}
}
}
PUT _template/windows-defender-logs
{
"index_patterns": ["windows-defender-*"],
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"index.lifecycle.name": "windows-defender-policy",
"index.lifecycle.rollover_alias": "windows-defender-logs"
}
}
PUT windows-defender-logs-000001
{
"aliases": {
"windows-defender-logs": {
"is_write_index": true
}
}
}ElasticAlert
Elastic selbst bietet in der Enterprise Version eine Möglichkeit sich über bestimmte Zustände informieren zu lassen. Dies kann klassisch per aber auch über diverse Messenger Dienste geschehen. Da wir den Server in der Basisversion betreiben, kam das für uns nicht in Frage. Auf meiner Suche nach Alternativen bin ich bei ElastAlert gelandet. Das wird von Mitarbeitern von yelp entwickelt und hat sich als gute Möglichkeit entwickelt auf bestimmte Vorgänge proaktiv zu reagieren. Wir überwachen darüber z.B. unseren Frontendserver. Auf diesem läuft ModSecurity und wenn dort z.B. mehrere 403 Fehler auftauchen, kann dass ein Hinweis auf einen Angriff sein oder aber worum es uns geht, einen Hinweis auf einen zu scharf eingestelltes ModSecurity. Vor allem unser viel verwendetes CMS Typo3 benötigt hier eine ganze Latte von Ausnahmen, damit es wie gewünscht funktioniert.
