Sicherheitsregel Eins: Wahrscheinlich verstoßen Sie gerade dagegen
Sie haben die Sicherheitsregel Null mittlerweile oft genug gehört, um sie auswendig zu kennen. Du kennst es doch auswendig, oder?
Nur zur Sicherheit, lassen Sie mich Ihr Gedächtnis auffrischen:
DU SOLLST BENUTZEREINGABEN NICHT VERTRAUEN. IMMER.
Exzellent. Nachdem wir diese grundlegende Regel nun festgelegt und aus dem Weg geräumt haben, sprechen wir über Sicherheitsregel Nummer Eins. Denn wie Sie vielleicht schon vermutet haben, gibt es für die Sicherheit mehr als eine Regel. Fahren wir also mit Regel eins fort, einverstanden?
SICHERHEITSREGEL EINS: DU SOLLST KEINE ANMELDEINFORMATIONEN FEST CODIEREN. IMMER.
Im Zeitalter der Zugriffskontrolle über Tokenisierung (beliebt bei APIs) und föderierte Identitäten wird diese Regel bei öffentlich zugänglichen Apps nur selten gebrochen. Diese Regel wird häufig innerhalb der Organisation gebrochen und ignoriert. Und es entwickelt sich schnell zu einem Problem, da NetOps den Einsatz von Skripting und Automatisierung verstärkt, um seinen Beitrag zur IT-Optimierung und Unterstützung der Initiativen zur digitalen Transformation ihres Unternehmens zu leisten.
Lassen Sie mich dies anhand eines sehr realen Beispiels veranschaulichen, das ich im Internet gefunden habe. Ich sage „eines“, weil mir weder die Zeit noch die Bandbreite zur Bereitstellung einer umfassenden Liste zur Verfügung steht. So weit verbreitet ist diese Praxis.
Auf der rechten Seite sehen Sie einen abscheulich häufigen Sicherheits-Fauxpas: fest codierte Anmeldeinformationen im Klartext. Es gibt nicht einmal einen Kommentar, in dem anerkannt wird, dass dies in einer Arbeitsumgebung nicht akzeptabel ist, und auch kein Nicken in Richtung der Notwendigkeit, eine sicherere Authentifizierungsmethode zu verwenden.
Dies bereitet mir im Zusammenhang mit NetOps große Sorgen, da der Explosionsradius erheblich größer ist, wenn man in das gemeinsam genutzte Unternehmensnetzwerk eingreift.
Einer der Gründe für diese Art von Sicherheitsproblemen liegt darin, dass NetOps zwar die Automatisierung annimmt, diese jedoch nicht unbedingt strategisch umsetzt. Was wir beobachten, ist ein erheblicher Prozentsatz von NetOps-Experten, die sich Python zuwenden und es mit einer herkömmlichen, CLI-basierten Methode zur Konfiguration und Verwaltung kombinieren.
Sie geben die Anmeldeinformationen genauso in die Befehlszeile ein, wie sie es tun, und klatschen diese Anmeldeinformationen auch in ein Skript, und fertig.
Letztendlich wird dies ein Problem sein. Wir werden sehen, wie jemand diese Praxis ausnutzt, und es wird tagelang in unseren Newsfeeds zu sehen sein. Denn so etwas ist schon einmal passiert. Erinnern Sie sich an OneLogin ? Sie speicherten zwar keine Skripte mit Anmeldeinformationen, aber Dateien mit Anmeldeinformationen. Sie können sich vorstellen, was für ein Chaos das verursacht hat.
Die Sache ist die, dass sich NetOps möglicherweise ziemlich sicher fühlt, wenn es darum geht, Befehlszeilenanmeldeinformationen in ein Skript einzufügen, aber wo landet dieses Skript? Wird es so verwaltet, wie es sollte? Wie Infrastruktur als Code? Ist es versioniert und wird es in einem Repository gespeichert?
Sie erinnern sich vielleicht an eine Umfrage der Network to Code-Community , die eine hohe Akzeptanzrate unter NetOps für (Achtung…) Github zeigte.
Fragen wir uns also: Wo ist unser Repository? Ist es außerhalb des Standorts? Vor Ort? Wie ist es geschützt und wie groß ist der Explosionsradius, wenn es jemand in die Hände bekommt?
Um das Geschäft aufrechtzuerhalten und voranzutreiben, müssen wir die Abläufe über Skripte und Automatisierung skalieren. NetOps muss sich in diese Richtung bewegen, sollte dies jedoch nicht tun, ohne die Auswirkungen von im Klartext gespeicherten Anmeldeinformationen – nun ja, überall – ernsthaft zu bedenken.
Zumindest sollten Skripte beim Aufruf die Eingabe von Anmeldeinformationen erfordern. Anmeldeinformationen sollten niemals in einer Datei oder im Skript und schon gar nicht im Klartext gespeichert werden . Optimalerweise verwenden Sie eine erweiterte Lösung zur Anmeldeinformationsverwaltung, um die Authentifizierung zu erzwingen und die Tokenisierung in internen Skripten zu verwenden. Ich weiß aber auch, dass wir uns gerade in der Anfangsphase der Masseneinführung der Automatisierung in NetOps befinden und dass wir es Schritt für Schritt angehen müssen.
In diesem Sinne sollten Sie bei Aufruf zumindest Anmeldeinformationen anfordern. Wenn dies mit Ihrer aktuellen Implementierung zu schwierig ist, ist es vielleicht an der Zeit, einen Schritt zurückzutreten und Ihre allgemeine Automatisierungsstrategie für die IT unter die Lupe zu nehmen. Die erste Frage lautet: Haben Sie eins? Oder handelt es sich bei Ihrem Vorgehen um eine taktische (und ursprüngliche) Reaktion auf geschäftliche Anforderungen?
Denn die langfristige Lösung sollte – und kann – nicht darin bestehen , in jedem Skript Anmeldeinformationen im Klartext anzugeben. Bedenken Sie neben dem offensichtlichen Sicherheitsrisiko auch die technischen Schulden, die Sie machen. Wenn Sie Anmeldeinformationen ändern müssen, müssen Sie sie überall ändern. Es kostet Zeit und Mühe, sie aufzuspüren. Sie haben wahrscheinlich weder Zeit noch Mühe, sonst würden Sie sich nicht so sehr die Zeit nehmen, die Sie durch die Einführung einer Automatisierung aufwenden möchten.
Verstoßen Sie also bitte nicht gegen Sicherheitsregel Nr. 1. Gehen Sie sicherer und intelligenter vor. Automatisierung sollte keine taktische Reaktion auf Größen- und Geschwindigkeitsanforderungen sein. Es sollte strategisch sein – und ist es auch. Das bedeutet, dass Sie den langfristigen Auswirkungen Ihrer Umsetzung mehr Aufmerksamkeit schenken müssen.