Verbesserte IT-Sicherheit durch Automatisierung mit Ansible
In diesem Beitrag möchte ich Ihnen erläutern warum Sie unbedingt an einer Automatisierung Ihrer IT Sicherheitsaufgaben mit Ansible arbeiten sollten. Ich möchte deutlich machen, wie Sie substantiell finanzielle Risiken minimieren, eine höhere Qualität Ihrer Serverabsicherung erreichen können und regelmäßige Überprüfungen aller Server ermöglichen könnten.
Etwas detaillierter mit einer realen Demonstration haben ich dazu ein Video veröffentlicht.
Durch den Ansatz von integrierter Entwicklung (Dev) und dem Betrieb (Ops) möchte man eine schnellere Entwicklung und einen besseren Betrieb der Anwendungen erreichen. Damit die Sicherheit hierbei nicht verloren geht wird in den meisten Organisation bei dem Betrieb der Server auf Checklisten und manuelle Einstellungen zurückgegriffen. Je erfahrener der Administrator desto größer und umfangreicher die Checkliste.
Dieser Ansatz mag sich in der Vergangenheit bewährt haben. Er zeigt aber für die nahe Zukunft eine Vielzahl von Schwächen auf:
- Abhängigkeit von einzelnen wenigen Personen
- Fehleranfälligkeit durch menschliche Fehler oder spezielle Skripte
- mangelnde Integrationsfähigkeit in vorhanden Prozesse
- Hohe Aufwände bei wiederhohlten Compliance Überprüfungen der Einstellungen
- Schwerfällige Dokumentation der Einstellungen
Auch hier kann die Automatisierung helfen reproduzier- und wiederhohlbare Ergebnisse zu erzielen und durch die Integration von verfügbaren öffentlichen Templates kann man dann auch schnell von Erfahrungen und Best Practise aus der Community profitieren.
Automatisierung im Security Umfeld kann aber auch substantiell Geld sparen. Die IBM Studie zu Data Breaches im Jahr 2020 hat ergeben, daß ohne eine Automatisierung der Sicherheitsprozesse die durchschnittlichen Kosten eines Databreaches bei 3.8 M Dollar liegen. Dem gegenüber stehen durchschnittliche Kosten von 286K Dollar bei unternehmen welche ihre Sicherheitskonfigurationen und -prozesse automatisiert haben.
Wir wollen und jetzt einen denkbaren Ansatz aus drei verschiedenen Perspektiven betrachten:
Da haben wir zum einen Sandra Meier. Sandra ist die Spezialistin für Linux und insbesondere für die Sicherheit der eingesetzten Server verantwortlich. Sandra möchte zum einen von Erfahrungen aus der Community profitieren aber auch natürlich Anpassungen für den eigenen Bedarf einbringen.
Daneben haben wird Karl Fischer. Karl ist verantwortlich für den Betrieb von Anwendungen. Er braucht dafür natürlich Server und möchte auf diesen seine Anwendungen verteilen. Karl ist kein Spezialist für Security und will aber ohne auf die Verfügbarkeit von Sandra angewiesen zu sein selber Server mit den Empfehlungen von Sandra betreiben.
Und wir haben Karin Adams. Karin ist für die IT Verantwortlich und möchte regelmäßig mit Sandra zusammen prüfen ob deren Einstellungen auch auf allen Servern umgesetzt werden.
Sandra ist ein Tecki. Sie möchte Dinge unter Kontrolle haben aber gleichzeitig auch Arbeitsaufgaben so weit wie möglich delegieren. Was sie überhaupt nicht leider kann ist das Neuerfinden von Rädern. Sie möchte ausreichend Zeit für Dokumentation haben und Änderungen in einer Versionskontrolle nachvollziehen können.
Eine hervorragende Ressource für das automatisierte Absichern von unterschiedlichen Systemen sind die Vorlagen von dev-sec.io. Sie wurden ursprünglich bei der Deutschen Telekom unter dem Projektnamen “Hardening.io” entwickelt und dann in Dev-Sec.io umbenannt. Hier findet man Empfehlung und Automatisierungen um verschiedenste Bereiche abzusichern. Natürlich sollte man solche Konfigurationen nicht ungelesen übernehmen aber sie stellen einen tollen Startpunkt dar und lassen sich einfach auf die eigenen Bedürfnisse anpassen.
In dem Projekt werden verschiedene Komponenten von der Ebene Betriebssystem bis zu einzelnen Anwendungen betrachtet und es werden explizit die Konfigurationen angesprochen und welche Einstellungen welche konfigurationsparameter haben sollten. Spannend und automatisierbar wird das durch bereitgestellte Ansiblerollen. Hier finden sie ein komplettes Playbook mit allen Elementen die Sie für eine eigene Nutzung übernehmen und konfigurieren können.
Wichtig ist zu wissen: alles ist lesbar und kann geprüft werden. Die Assets können über Git direkt von den Administratoren genutzt werden und in eigenen Playbooks integriert werden.
Schauen wir uns jetzt das ganze aus einer Perspektive von Karl an. Karl ist nicht an den Details interessiert muss aber die Sicherheit seiner Anwendungsserver sicherstellen. Er hasst es auf Spezialisten warten zu müssen ist aber auf deren Wissen angewiesen. Wenn Karl jetzt eine neue Anwendung einrichten die verschiedene Server einrichten muss kann er direkt die Vorgaben von Sandra übernehmen.
Falls unser Freund Karl allerdings ein Freund von flexiblen Abkürzungen ist besteht natürlich die Gefahr das er die Vorgaben von Sandra eigenmächtig ändert.
Das führt uns zu Karin. Karin will das Sandra regelmäßig auf allen Servern prüft ob die Einstellungen wie gewünscht sind und keiner unberechtigt geändert hat. Sandra möchten natürlich dazu nicht auf dutzenden von Servern nachschauen. Sie startet einfach das Playbook auf allen Servern und sieht was passiert. Außerdem möchte Sie natürlich schnell Änderungen auf allen Server durchführen. Dazu passt sie das Playbook an und startet es erneut. Es werden alle neuen Änderungen eingetragen und unerwünschte Anpassungen wieder gerade gezogen.
Vermutlich werden viele dieser Schritte weiter automatisiert und im realen leben nicht manuell ausgeführt. Vieles läßt sich mit der Opensource Variante von Ansible machen. Für eine Vielzahl von Anforderungen bietet es sich an auf das kostenpflichtige Produkt Ansible Tower zurückzugreifen und die Automatisierung auch in nicht IT affine Bereiche auszubreiten, erweiterte Rollenkonzepte zu nutzen und umfangreiche Reportingfunktionen einfach nutzen zu können.