Sicherheitsregel Nummer eins: Wahrscheinlich verstoßen Sie gerade dagegen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Inzwischen haben Sie Security Rule Zero oft genug gehört, um sie auswendig zu kennen. Sie kennen sie doch auswendig, oder?

Nur für alle Fälle – hier noch einmal zur Erinnerung:

DU SOLLST NIEMALS BENUTZEREINGABEN VERTRAUEN. NIEMALS.

Ausgezeichnet. Nachdem wir diese grundlegende Regel nun festgehalten und abgehakt haben, sprechen wir über Sicherheitsregel Nummer eins. Denn wie Sie vielleicht schon vermutet haben, gibt es mehr als nur eine Sicherheitsregel. Kommen wir also zu Regel Nummer eins, einverstanden?

SICHERHEITSREGEL NUMMER EINS: ZUGANGSDATEN DÜRFEN NIEMALS FEST IM CODE HINTERLEGT WERDEN. AUSNAHMSLOS.

In einer Zeit, in der die Zugriffskontrolle über Tokenisierung (beliebt bei APIs) und föderierte Identitäten erfolgt, wird diese Regel bei öffentlich zugänglichen Anwendungen nur selten verletzt. Häufig verletzt und missachtet wird sie hingegen innerhalb des Unternehmens. Und das entwickelt sich rasch zu einem Problem, da NetOps verstärkt auf Skripting und Automatisierung setzt, um seinen Beitrag zur Optimierung der IT und damit zur Unterstützung der Initiativen des Unternehmens zur digitalen Transformation zu leisten.

Lassen Sie mich das anhand eines sehr realen Beispiels veranschaulichen, das ich im Internet gefunden habe. Ich sage bewusst „eines“, denn mir fehlen sowohl die Zeit als auch die Kapazitäten, um eine vollständige Liste zu erstellen. So weit verbreitet ist diese Praxis.

Rechts sehen Sie einen erschreckend häufigen Sicherheitsfehler: fest im Code hinterlegte Zugangsdaten im Klartext. Es gibt nicht einmal einen Kommentar, der darauf hinweist, dass dies in einer produktiven Umgebung inakzeptabel ist, geschweige denn einen Hinweis darauf, dass eine sicherere Authentifizierungsmethode verwendet werden sollte.

Das bereitet mir insbesondere im NetOps-Kontext große Sorgen, da der potenzielle Schadensradius erheblich größer ist, wenn man am gemeinsam genutzten Unternehmensnetzwerk Änderungen vornimmt.

Einer der Gründe, warum wir diese Art von Sicherheitsproblem beobachten, liegt darin, dass NetOps zwar zunehmend auf Automatisierung setzt, diese aber nicht unbedingt strategisch einführt. Wir sehen, dass ein erheblicher Anteil der NetOps-Fachkräfte Python nutzt und mit einer herkömmlichen, CLI-basierten Methode zur Konfiguration und Verwaltung kombiniert.

So wie sie ihre Zugangsdaten in die Befehlszeile eingeben würden, packen sie dieselben Zugangsdaten einfach in ein Skript und belassen es dabei.

Letztendlich wird das zum Problem werden. Irgendjemand wird diese Vorgehensweise ausnutzen, und unsere Newsfeeds werden tagelang voll davon sein. Denn so etwas ist schon einmal passiert. Erinnern Sie sich an OneLogin? Dort wurden zwar keine Skripte mit Zugangsdaten gespeichert, dafür aber Dateien mit Zugangsdaten. Sie können sich vorstellen, was für ein Chaos das verursacht hat.

Das Problem ist: NetOps mag sich zwar ziemlich sicher dabei fühlen, Anmeldedaten für die Befehlszeile in einem Skript zu hinterlegen, aber wo landet dieses Skript letztendlich? Wird es so verwaltet, wie es sein sollte? Etwa wie Infrastructure as Code? Wird es versioniert und in einem Repository gespeichert?

Vielleicht erinnern Sie sich an eine Community-Umfrage von Network to Code aus der hervorging, dass GitHub bei NetOps eine hohe Akzeptanz genießt (jetzt kommt’s …).

Fragen wir uns also: Wo befindet sich unser Repository? Ist es extern oder vor Ort gespeichert? Wie ist es geschützt, und wie groß wäre der potenzielle Schaden, wenn jemand darauf zugreifen könnte?

Um Schritt zu halten und die Anforderungen des Unternehmens zu erfüllen, müssen wir den Betrieb mithilfe von Skripten und Automatisierung skalieren. NetOps muss sich in diese Richtung entwickeln, sollte dabei jedoch die Folgen von im Klartext gespeicherten Zugangsdaten – ganz gleich, wo sie gespeichert sind – ernsthaft berücksichtigen.

Skripte sollten zumindest beim Aufruf die Eingabe von Anmeldedaten verlangen. Anmeldedaten sollten niemals in einer Datei oder im Skript gespeichert werden, und schon gar nicht im Klartext. Im Idealfall würden Sie eine fortschrittlichere Lösung zur Verwaltung von Anmeldedaten einsetzen, um eine Authentifizierung zu erzwingen und in internen Skripten mit Tokenisierung zu arbeiten. Mir ist jedoch bewusst, dass wir bei der breiten Einführung der Automatisierung im NetOps-Bereich gerade erst am Anfang stehen und Schritt für Schritt vorgehen müssen.

Vor diesem Hintergrund sollten Sie zumindest bei der Ausführung die Eingabe von Anmeldedaten verlangen. Wenn das mit Ihrer aktuellen Implementierung zu schwierig ist, ist es vielleicht an der Zeit, einen Schritt zurückzutreten und Ihre übergreifende IT-Automatisierungsstrategie zu überprüfen. Die erste Frage lautet: Haben Sie überhaupt eine? Oder ist das, was Sie tun, lediglich eine taktische (und primitive) Reaktion auf die Anforderungen des Unternehmens?

Denn die langfristige Lösung sollte nicht – kann nicht – darin bestehen, Anmeldedaten im Klartext in jedem Skript zu hinterlegen. Abgesehen vom offensichtlichen Sicherheitsrisiko sollten Sie auch die technischen Schulden bedenken, die Sie damit anhäufen. Wenn Sie die Anmeldedaten ändern müssen, müssen Sie sie überall ändern. Sie alle ausfindig zu machen, kostet Zeit und Mühe. Zeit und Mühe, die Sie wahrscheinlich nicht haben – sonst wären Sie wohl kaum so erpicht darauf, durch Automatisierung überhaupt erst Zeit zu gewinnen.

Verstoßen Sie also bitte nicht gegen die erste Sicherheitsregel. Gehen Sie auf Nummer sicher und handeln Sie klüger. Automatisierung sollte keine taktische Reaktion auf Anforderungen an Skalierbarkeit und Geschwindigkeit sein. Sie sollte strategisch ausgerichtet sein – und ist es auch. Das bedeutet, dass Sie den langfristigen Auswirkungen Ihrer Umsetzung mehr Aufmerksamkeit schenken müssen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie