wladimir1804 - stock.adobe.com
Zugangsdaten: Die Gefahr lauert auch in der Applikation
Nicht nur die personifizierten Admin-Accounts, sondern auch die nicht-menschlichen privilegierten Zugriffsrechte müssen in einem Sicherheitskonzept berücksichtigt werden.
Viele Unternehmen unterschätzen die Anzahl der privilegierten Accounts, da sie sie mit privilegierten Benutzern gleichsetzen. In der Regel sind aber in einem Unternehmen dreimal mehr privilegierte Konten als Mitarbeiter vorhanden. Vor allem werden die nicht-menschlichen Zugriffsrechte nur unzureichend beachtet. Dabei handelt es sich etwa um Application Accounts oder technische Accounts, das heißt um die in Anwendungen, Skripten oder Konfigurationsdateien gespeicherten Zugangsdaten und Passwörter.
Im Unterschied zu privilegierten Accounts, die von Administratoren und damit Personen genutzt werden, greifen Applikationen automatisch auf Backend-Systeme zu, die eine Authentifizierung erfordern. Die Application Accounts werden zum Beispiel für den Datenbank-Zugriff einer Anwendung oder für die Ausführung von Batch-Jobs benötigt. Da die Passwörter meistens im Klartext oder in einer einfachen Verschlüsselung vorliegen, bieten sie eine sicherheitskritische Zugangsmöglichkeit zu vertraulichen Datenbeständen.
Applikationen und Tools brauchen privilegierte Zugriffsrechte
Bei der nicht-personifizierten Zugriffssteuerung sind in erster Linie die Applikation-zu-Applikation-Verbindungen zu berücksichtigen. Auf der Applikationsebene erfordern alle technischen Verknüpfungen zwischen Teilen einer Applikationslandschaft einen privilegierten Zugang für den Datenzugriff, auch wenn es nur um Lese- und nicht Änderungsrechte geht. Solche Verbindungen bestehen etwa zwischen Applikation und Datenbank, zwischen Applikation und Middleware-Produkten oder auch direkt zwischen Anwendungen.
Die für den privilegierten Verbindungsaufbau nötigen User Credentials befinden sich herkömmlicherweise in der Applikation selbst beziehungsweise in einer zugehörigen Konfigurationsdatei. Da die Passwörter nicht geändert werden, stellen sie ein hohes Sicherheitsrisiko dar. Zudem verwenden Entwickler oft identische Zugangsdaten für mehrere Applikationen. Auch dieses Vorgehen ist unter Compliance-Gesichtspunkten äußerst problematisch, da damit letztlich nicht mehr nachvollziehbar ist, welche Applikation welche Änderung vorgenommen hat, und die Übernahme eines solchen Accounts gleichzeitig mehrere Systeme kompromittiert.
Nicht nur die Applikationen müssen ins Kalkül gezogen werden, sondern auch sonstige genutzte Tools, etwa Schwachstellenscanner. Sie besitzen in der Regel ebenfalls privilegierte Rechte bis hin zum Domain-Admin-Level, um etwa den aktuellen Patch-Stand oder die detaillierte Konfiguration von Systemen überprüfen zu können. Darüber hinaus ist auf Toolebene die Automation zu beachten, die in immer stärkerem Maße an Bedeutung gewinnt. Hier geht es um Lösungen wie Jenkins, Puppet, Chef, OpenShift oder auch RPA. Auch sie müssen adäquat eingesetzt und gesichert werden – mit einer Authentifizierung der Automatismen.
„Das zentrale Sicherheitsproblem bei Applikationen, Tools und Systemen ist, dass privilegierte Zugangsdaten fest integriert sind und in der Regel nie geändert werden.“
Michael Kleist, Cyberark
Abgesehen von der Applikations- und Tool-Ebene ist unter Sicherheitsaspekten noch die technologische Systemebene von hoher Relevanz, also die System-zu-System-Verbindung. Sie betrifft die in vielen Systemen vorhandenen Service-Accounts. Windows etwa verfügt über zahlreiche Service-Accounts, um Services im richtigen Kontext zu starten und zu stoppen und um eine Automation auf einem granularen Level zuzulassen. Normalerweise werden auch bei Konten für Systemdienste die Zugangsdaten nur selten geändert, da Passwort-Änderungen bei Active-Directory- oder Domain-Service-Accounts zusätzlich eine systemübergreifende Koordination erfordern.
Doch warum werden die privilegierten Accounts in den Applikationen, Tools und Systemen noch zu wenig berücksichtigt? Ein Grund ist, dass der CISO vielfach primär Themen wie IT-Betrieb, Netzwerktechnik oder Perimeter-Sicherheit im Blick hat, Applikationen aber eher zum Aufgabengebiet von Datenschutzbeauftragten gehören. Eine Risikobewertung von Applikationen aus IT-Sicht findet deshalb häufig nicht statt, ebenso wenig wie eine zwingend erforderliche End-to-End-Risikobewertung einer gesamten Applikationslandschaft.
Eingebettete Anmeldeinformationen müssen beseitigt werden
Das zentrale Sicherheitsproblem bei Applikationen, Tools und Systemen ist somit, dass privilegierte Zugangsdaten fest integriert sind und in der Regel nie geändert werden. In der Hand eines externen Angreifers oder auch böswilligen Insiders stellen diese privilegierten vertraulichen Zugangsdaten eine erhebliche Gefahr dar, da sie eine vollständige Kontrolle über die gesamte IT-Infrastruktur eines Unternehmens ermöglichen können. Doch wie sollte ein Unternehmen, dieses Sicherheitsrisiko beseitigen? Ein Lösungsansatz ist, die in Skripten oder Konfigurationsdateien eingebetteten statischen Passwörter zu eliminieren, das heißt also, auch die Application-Account-Passwörter zentral zu sichern, automatisch zu verwalten und dynamisch zur Laufzeit zur Verfügung zu stellen. Durch die automatische Passwort-Rotation wird die Sicherheit deutlich erhöht. Zudem sind damit auch bei nicht-menschlichen Zugriffen keine Personen mehr involviert – irgendjemand muss ja sonst das Passwort erstmalig eintragen – und Use-Case-spezifische Least-Privilege-Konzepte innerhalb von Applikationen umsetzbar.
Hinsichtlich der Vorgehensweise gilt wie fast immer auch hier: Start mit den „Low-hanging fruits“. So sollte bei Neuentwicklungen konsequent auf eine hartkodierte Programmierung von Zugangsdaten verzichtet werden. Aufwendiger ist der Prozess bei selbstentwickelten Applikationen mit eigenständiger Logik. Hier sollten die Veränderungen in Abhängigkeit von einer Kritikalitäts- und Risikobewertung sukzessive in Angriff genommen werden. Oft besteht etwa die Möglichkeit, selbstgebaute Skripte mit klassischen Suchen-und-Ersetzen-Verfahren zu eliminieren. Allerdings sind vereinzelt durchaus auch komplexe Source-Code-Veränderungen erforderlich.
Trotz aller offensichtlichen Herausforderungen führt aber aus Sicherheitssicht an einer Verwaltung und Überwachung aller Anmeldeinformationen und vertraulichen Zugangsdaten, die von nicht-menschlichen Benutzern verwendet werden, kein Weg vorbei. Die Beseitigung fest programmierter Anmeldeinformationen in Anwendungen und ihre Rotation gemäß definierter Richtlinien ist eine wesentliche Komponente eines stringenten Secrets-Management und damit für die Erhöhung der Unternehmenssicherheit von entscheidender Bedeutung.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
