Was ist eine Konfigurationsabweichung?

Bis zu einem gewissen Grad ist eine Konfigurationsabweichung im Laufe des Lebenszyklus eines Systems unvermeidlich. Dies kann durch manuelle Änderungen an einem Netzwerk verursacht werden, die die Interaktion der Komponenten untereinander beeinflussen, oder durch automatisierte Tools, die Einstellungen auf eine Weise verändern, die von den Administratoren nicht beabsichtigt war. Ohne die entsprechende Dokumentation können inkompatible oder schädliche Änderungen vorgenommen werden, wenn alte Administratoren ausscheiden und neue hinzukommen.

Ein Paradebeispiel für Konfigurationsdrift ist der Fall, dass ein Administrator in einer lastausgeglichenen Umgebung ein Fix auf einem Server anwendet, nicht aber auf den anderen. Selbst wenn das System vorerst normal weiterläuft, können später Probleme auftreten. Der gepatchte Server könnte eine neue Bibliothek verwenden, die mit zukünftigen Updates des Netzwerks, die die ursprünglichen Bedingungen annehmen, nicht kompatibel ist, was möglicherweise zu Ausfällen und Ineffizienzen führen kann.

Konfigurationsabweichungen stellen nicht nur eine Gefahr für die Leistung dar. Systeme, die von ihren vorgesehenen Einstellungen abweichen, können anfälliger für böswillige Akteure und Datenpannen werden. Wenn zum Beispiel die Firewall-Regeln nicht aktualisiert werden, wenn neue Ressourcen einem Netzwerk hinzugefügt werden, können Hacker direkt eindringen.

Konfigurationsabweichungen können sich auch auf den Compliance-Status auswirken. Ein Unternehmen kann ein Audit nicht bestehen, wenn die Netzwerkdokumentation eine Reihe von Sicherheitseinstellungen beschreibt, die Live-Umgebung jedoch anders ist.

DevOps-Profis und Systemadministratoren stehen ihnen Werkzeuge zur Verfügung, um Fehlkonfigurationen zu verhindern und Konfigurationsabweichungen zu bekämpfen. Infrastructure as Code (IaC)-Tools wie Terraform binden die Netzwerkkonfiguration an eine Konfigurationsdatei, die als Quelle der Wahrheit dient. Konfigurationsdateien stellen sicher, dass neue Netzwerkressourcen automatisch im richtigen Zustand bereitgestellt werden, wodurch die Anzahl möglicher Abweichungen reduziert wird.

Observability- Tools geben Administratoren Einblick in Metriken, Protokolle und Traces und helfen ihnen so, Konfigurationsabweichungen in Echtzeit zu erkennen und Korrekturen vorzunehmen. Eine unveränderliche Infrastruktur begrenzt Abweichungen, indem veraltete Server ausgemustert werden, anstatt überhaupt Korrekturen vorzunehmen. Konfigurationsabweichungen werden auch durch Konfigurationsmanagement-Tools wie Ansible behandelt.

Konfigurationsabweichungen werden am häufigsten durch manuelle Änderungen an Systemkonfigurationen, fehlerhafte Automatisierung, Probleme auf Unternehmensebene, die zu Inkonsistenzen führen, oder eine Kombination dieser Faktoren verursacht.

Manuelle Einmalkorrekturen sind die Hauptursache für Konfigurationsabweichungen.

Ein „Hotfix“ oder eine Korrektur, die außerhalb des normalen Aktualisierungszeitplans angewendet wird, kann sofortige, dringende Probleme beheben, wie zum Beispiel einen Server, der auf den falschen Timeout-Wert eingestellt ist und daher ständig abstürzt. Aber diese Art von Konfigurationsänderung kann das System später kaputt machen:

• Ein späteres Systemupdate, das diese Korrekturen nicht berücksichtigt, könnte sie überschreiben und den ursprünglichen Fehler wiederherstellen.
  
  
• Die Korrekturen könnten eine Abhängigkeit beinhalten, die nicht berücksichtigt wurde und mit zukünftigen Aktualisierungen des Netzwerks inkompatibel ist.
  
  
• Die für die Fehlerbehebung erstellten temporären Administratoranmeldeinformationen könnten weiterhin gültig bleiben und somit ein zusätzliches Sicherheitsrisiko darstellen.

Die Möglichkeiten, wie menschliches Versagen – oder auch nur unvorhergesehene Folgen – das System aus dem Zustand, in dem es sich „befinden sollte“, bringen können, sind nahezu unbegrenzt. Selbst kleine Änderungen können sich so anhäufen, dass die Produktionsumgebung nur noch wenig Ähnlichkeit mit dem Repository hat und mit Fehlern und Sicherheitsrisiken behaftet ist.

Ohne angemessene Tests und Überwachung können automatische Updates und Prozesse dazu führen, dass wichtige Netzwerkressourcen von ihren vorgesehenen Konfigurationen abweichen.

Die Automatisierung ist nur so gut wie ihre Datenquelle. Wenn sich ein IaC-Tool beispielsweise auf veraltete Konfigurationsdateien stützt, um neue Server einzurichten, kann dies die Umgebung beeinträchtigen. Automatisierte Software-Updates für Apps und Betriebssysteme wie Microsoft Windows könnten zu unterschiedlichen Serverzeiten angewendet werden und potenziell schädliche Abweichungen verursachen. Und diese Updates funktionieren möglicherweise nicht gut mit der einzigartigen Netzwerkarchitektur eines Unternehmens, was weitere Probleme verursacht.

Selbst Tools, die für die Verwaltung der Konfiguration gedacht sind, können unter den richtigen Umständen eine Abweichung verursachen. Beispielsweise könnten Verbindungsprobleme dazu führen, dass Ansible ein Konfigurationsupdate ungleichmäßig anwendet, sodass ein Server unverändert bleibt. Dieser Server wird sich nach und nach von seiner Umgebung entfernen, was möglicherweise zu Serviceausfällen führt.

Auf Organisationsebene können Probleme mit der Continuous Integration/Continuous Delivery (CI/CD)-Pipeline und DevOps-Praktiken zu Konfigurationsproblemen führen.

Wenn Entwicklungs-, Betriebs- und Sicherheitsteams voneinander isoliert arbeiten, sind Verwirrung, Kommunikationsprobleme und unzureichende Fehlerbehebung unvermeidlich. Neben unterschiedlichen technischen Praktiken können Teams innerhalb eines Unternehmens eigene Praktiken für Change Management haben. In einigen Unternehmen fehlen formelle Change-Management-Prozesse völlig.

Das Fehlen etablierter, klarer Praktiken zur Vornahme und Dokumentation von Änderungen kann zu inkonsistenten Änderungsprotokollen, unautorisierten Änderungen und nicht erzwungenen Genehmigungsabläufen führen. Letztlich könnten Administratoren, Entwickler und Ingenieure den Change-Management-Prozess komplett umgehen.

Konfigurationsabweichung birgt erhebliche Risiken für die Sicherheit, Leistung und den Compliance-Status eines Systems.

Konfigurationsdrift kann die Angriffsfläche einer Organisation erheblich erhöhen, indem sie Ausnahmen für Sicherheitsrichtlinien schafft, die Administratoren unbekannt sind und daher nicht behoben sind.

So kann beispielsweise ein Berechtigungsnachweis, der zur Anwendung eines Hotfixes erstellt wurde, an Ort und Stelle verbleiben und von Hackern für böswillige Zwecke verwendet werden. Ebenso könnte ein Techniker eine Ausnahme von einer Firewall-Regel einrichten, die er später nie wieder schließt, wodurch die allgemeine Sicherheitslage des Netzwerks erheblich geschwächt wird. Entwickler könnten eine Anwendung mit unvollständigen Sicherheitskontrollen zu Testzwecken aktivieren und nie deaktivieren, wodurch eine weitere Sicherheitslücke entsteht, die böswillige Akteure ausnutzen können.

Ebenso kann jede neue App, jedes neue Endgerät oder jede andere Ressource, die einem System hinzugefügt wird, zu einer Konfigurationsabweichung führen, wenn nicht die entsprechenden Sicherheitskontrollen angewendet werden. Zum Beispiel kann das Hinzufügen eines neuen Servers ohne die eigentliche Konfiguration des Endpoint Detection and Response (EDR)-Systems eine Schwachstelle schaffen. Ein einfacher Fehler in der Microservices-Konfiguration kann dazu führen, dass eine große Anzahl ungeschützter Assets ins Netzwerk gelangt.

Neben der Cybersicherheit ist die Netzwerkleistung das bedeutendste – und teuerste – Risiko durch Konfigurationsabweichungen.

Nehmen wir das Beispiel eines Servers, der mehr Traffic hat als seine Gegenstücke. Der Connection Pool dieses Servers könnte mit einem Hotfix erhöht werden, um die Leistung zu verbessern. Da dieser Server hinter einem Load Balancer steht, legt der Balancer automatisch eine Richtlinie fest, um mehr Traffic auf seine Art zu leiten und die Serverlast gleichmäßiger zu verteilen.

Wenn der Server bei einer Bereitstellung ausgetauscht wird, ist der Hotfix, der den Pool erhöht hat, nicht mehr vorhanden und der Server stürzt aufgrund des zusätzlichen Datenverkehrs ab. Der ursprüngliche Hotfix, der zur Beschleunigung des Datenverkehrs angewendet wurde, ist die Abweichung. Wenn dies nicht berücksichtigt wird, können weitere Änderungen am Netzwerk zu teurer Ausfallzeit führen, bis die Ursache identifiziert ist.

Konfigurationsabweichungen können dazu führen, dass ein Unternehmen die Vorschriften nicht einhält, ohne sich dessen bewusst zu sein. Wenn der Zustand eines Netzwerks von dem abweicht, was ein Unternehmen „denkt“, dass es tut – oder von dem, was in der Dokumentation steht –, läuft das Unternehmen Gefahr, die Vorschriften nicht einzuhalten. Selbst wenn die Nichteinhaltung unbeabsichtigt erfolgt, könnten dem Unternehmen trotzdem Bußgelder und Gebühren drohen.

Nehmen wir das Beispiel des Health Insurance Portability and Accountability Act (HIPAA). HIPAA verlangt, dass Unternehmen bestimmte Verschlüsselung verwenden, um sensible Daten während der Übertragung und in Ruhe zu schützen.

Angenommen, ein Administrator muss ein Altlast-System in sein HIPAA-konformes Netzwerk integrieren, und dieses Altlast-System verwendet eine veraltete Verschlüsselung. Wenn diese Verschlüsselung nicht berücksichtigt wird, verstößt die Integration des Unternehmens gegen HIPAA.

Die Abweichungserkennung – die Praxis, Änderungen im Netzwerk zu verfolgen und Abweichungen vom beabsichtigten Zustand zu identifizieren – erfordert eine Kombination von Werkzeugen, darunter Infrastructure as Code, GitOps, unveränderliche Infrastruktur und Observability.

Infrastructure-as-Code, die Praxis der Bereitstellung und Verwaltung der IT-Infrastruktur mithilfe von Skripten anstelle manueller Prozesse, ist eines der leistungsstärksten Tools für das Management von Konfigurationsabweichungen.

IaC hilft, Konfigurationsabweichung zu bekämpfen, indem der gewünschte Zustand des Netzwerks in einen versionskontrollierten Code umgewandelt wird, mit dem jede Netzwerkkomponente verglichen werden kann.

Zum Beispiel vergleicht das IaC-Tool in Terraform bei einer Änderung die Zustandsdatei (die aktuellste Ansicht des Netzwerks der Plattform) mit den deklarierten Konfigurationsdateien – also mit den Dateien, die angeben, was das Netzwerk „sein sollte“. Terraform löst dann Diskrepanzen zwischen der Statusdatei und der deklarierten Konfiguration auf, indem es die Infrastruktur an die Konfigurationsdatei anpasst.

Wenn Organisationen strenge Zugriffskontrolle für IaC-Tools anlegen, kann dies die Möglichkeiten für Abweichungen noch weiter verringern. Durch die Beschränkung des IaC-Zugriffs auf autorisierte Personen, die ihn benötigen, schränken Unternehmen die Möglichkeit ein, Infrastrukturkonfigurationen im Allgemeinen zu ändern. Und wenn Änderungen vorgenommen werden, durchlaufen sie den IaC-Versionskontrollprozess, was das Risiko von Abweichungen weiter mindert.

GitOps ist eine DevOps-Praxis, die das Open Source-Repository Git als Single-Source-of-Truth (SSOT) für Konfigurationsdateien verwendet. GitOps hilft vielen Unternehmen dabei, IaC mit maximaler Effizienz und Sicherheit bereitzustellen.

GitOps-Praktiken konzentrieren sich auf die Nutzung von Automatisierung, um den Zustand des Netzwerks in Echtzeit mit dem in Git gespeicherten Sollzustand abzugleichen. GitOps-Plattformen können Netzwerke kontinuierlich scannen, Fehlkonfigurationen erkennen und diese kennzeichnen oder korrigieren, sodass etwaige Abweichungen nur vorübergehend sind. Und da alle Änderungen an Git gebunden sind, werden sie mit einem Autor, einem Zeitstempel und einer Beschreibung nachverfolgt.

Eine unveränderliche Infrastruktur verringert die Konfigurationsabweichung, indem sie die Gesamtzahl der Möglichkeiten zur Änderung der Netzwerkkonfiguration drastisch reduziert.

Bei einer unveränderlichen Infrastruktur werden Server und andere IT-Ressourcen ersetzt, nicht verändert, wenn Änderungen erforderlich sind.

Nehmen wir zum Beispiel an, dass ein Server ein Sicherheitsupdate benötigt. Anstatt das Update auf den bestehenden Server anzuwenden, würden Administratoren den Server außer Betrieb nehmen und durch einen neuen, aktualisierten ersetzen.

Die unveränderliche Infrastruktur stützt sich auf IaC-Tools, um automatisch neue Systeme wie im Code beschrieben bereitzustellen, wenn Änderungen erforderlich sind. Jede neu zum Netzwerk hinzugefügte Komponente entspricht automatisch dem gewünschten Zustand.

Die drei Praktiken von IaC, GitOps und unveränderlicher Infrastruktur sind eng miteinander verknüpft. IaC-Tools definieren die Images für Netzwerkkomponenten, während GitOps die Bereitstellung erleichtert, eine umfassende Dokumentation des Netzwerks erstellt und Diskrepanzen verhindert.

Die drei Säulen der Observability (Protokolle, Metriken und Traces) spielen auch eine Rolle bei der Vermeidung von Konfigurationsabweichungen.

Eine Observabilitätsplattform könnte beispielsweise erkennen, dass Metriken auf einem Server (wie Antwortzeiten oder CPU-Auslastung) deutlich von Servern abweichen, die identische Konfigurationen haben sollten. Diese Divergenz ist ein mögliches Symptom einer Abweichung. Ebenso könnten Diskrepanzen in den Fehlerratenprotokollen für jeden Server auf eine Abweichung hinweisen, wenn ein Server eine ungewöhnlich hohe Anzahl von Fehlern einer bestimmten Art aufweist. Die Aufzeichnungen der Aufrufkette einer Anwendung können auch Stellen aufdecken, an denen Abweichungen auftreten.

Bei der Abweichungserkennung wird der tatsächliche Zustand eines Netzwerks mit dem gewünschten Zustand verglichen, um Diskrepanzen zu erkennen. Obwohl man diesen Prozess hypothetisch manuell durchführen kann, bieten viele Cloud- und IaC-Anbieter Tools mit Erkennung an, die helfen, ein ansonsten zeitaufwändiges Projekt zu automatisieren und zu optimieren.

AWS Config zeichnet zum Beispiel die Konfigurationen der AWS-Module auf, markiert alles, was vom gewünschten Zustand abweicht, und hilft bei der Behebung von Abweichungen. Die Bewertungen von Terraform überprüfen, dass die tatsächlichen Infrastruktureinstellungen mit den im Zustandsdatei des Arbeitsbereichs erfassten Einstellungen übereinstimmen und kontinuierlich validieren, dass die Ressourcen die erforderlichen Kontrollen erfüllen, die in den Systemkonfigurationen definiert sind.

Terraform Enterprise vergleicht die Bedingungen mit der Zustandsdatei oder aktualisiert die Zustandsdatei, um die tatsächlichen Bedingungen wiederzugeben und Änderungen aufzudecken. Zur Abweichungserkennung können auch Konfigurationsmanagement-Tools wie Ansible und Puppet verwendet werden.