Früher war die Unternehmensarchitektur physisch und einzigartig, praktischerweise an einem Ort untergebracht, der leicht verwaltet und gesichert werden konnte.
Jetzt hat sich die Situation umgekehrt. Der Ansturm auf die Digitalisierung zwingt Unternehmen dazu, mit beispielloser Geschwindigkeit zu agieren. Organisationen, die agile Methoden und DevOps-Praktiken übernommen haben, konnten ihre Umgebungen, Application und Bereitstellungen modernisieren, zuvor monolithische Applications in Microservices-Architekturen zerlegen, Routineaufgaben automatisieren, Kubernetes (k8s) für die Containerverwaltung übernehmen und für die Bereitstellung agiler Dienste auf die öffentliche Cloud umsteigen.
Obwohl dadurch der Komfort für Unternehmen und ihre Endbenutzer deutlich erhöht wurde, sind damit auch erhebliche Sicherheitsprobleme verbunden.
Bei diesem Tempo des Wandels hinkt die Sicherheit meist hinterher. In vielen Fällen wurden DevOps ohne Berücksichtigung der Sicherheit implementiert und verteilt, sodass die IT Probleme beheben musste, sobald sie auftraten – und in einigen bedeutenden, öffentlich bekannten Beispielen sogar nachdem sie aufgetreten waren.
Was ist also der beste Weg, um die Sicherheitstechniker zu entlasten und gleichzeitig Sicherheitsverletzungen zu verhindern, ohne Reibungsverluste für die Benutzer zu verursachen?
In vielerlei Hinsicht haben die Sicherheitsanforderungen bei der Dezentralisierung in virtualisierte Umgebungen die Organisationen überrascht. Da wir uns von unseren herkömmlichen zentralisierten Sicherheitskontrollen verabschiedet haben, reichen die vorhandenen verteilten Kontrollen nicht mehr wirklich aus.
Da zentralisierte Umgebungen gut bekannt und quantifiziert waren, war es relativ einfach, eine Einheitlichkeit der Sicherheitskontrollen, -abläufe, -berichte und -warnungen zu erreichen. Aufgrund hoher Investitionen, des angehäuften geistiges Eigentum und der hohen Änderungskosten wurden Änderungen an übernommenen Technologien nur selten vorgenommen.
Die Unterstützung mehrerer neuer Umgebungen brachte eine Reihe von Herausforderungen und Überlegungen mit sich, beispielsweise mangelnde Reife und Leistungsfähigkeit, unterschiedliche Cloud-Umgebungen, ein Mischmasch aus Technologien, unklare Abläufe, mangelnde Transparenz, schwierige Berichterstellung und oft geringe Reife.
Als Antwort auf diese Herausforderungen stellten uns die Anbieter öffentlicher Clouds Transit-Gateways zur Verfügung, einen zentralen Kontrollpunkt, über den der gesamte Datenverkehr zu und von den Mietern läuft.
In modernen Umgebungen mit Applications , die über Clouds, Mandanten und Rechenzentren verteilt sind, ist es sehr sinnvoll, die Sicherheit in der einzelnen App zu haben. Dadurch wird sichergestellt, dass die Sicherheit inhärent ist, d. h. sie kann nicht vergessen, entfernt oder umgangen werden. Dies bedeutet auch, dass die Sicherheit dann und dort vorhanden ist, wenn sie benötigt wird, und im Rahmen der Außerbetriebnahme der Application entfernt wird.
Dieses Modell bietet auch die Möglichkeit, die Sicherheit insofern zu verlagern, als dass sie in allen Lebenszyklusphasen und in allen Umgebungen präsent ist. Dies bedeutet, dass Sicherheitskontrollen nicht zum ersten Mal bei der Bereitstellung und Ausführung oder in der Vorproduktion und Produktion auftreten.
Sicherheitsteams möchten nicht länger das „Büro des Neins“ sein, sondern die Sicherheit in die Organisation bringen, statt die Organisation zur Sicherheit zu zwingen. Unserer Meinung nach lässt sich dies am besten erreichen, indem DevOps-Teams die Möglichkeit erhalten, Sicherheit auf eine Weise zu nutzen, die ihren Anforderungen entspricht. Dies bedeutet, dass Sicherheit von Beginn einer App oder eines Programms an implementiert und verwendet werden muss und nicht erst danach.
Dies wird als „Shifting Left“ der Sicherheit bezeichnet und bedeutet die Implementierung von Sicherheitskontrollen in früheren Phasen des Entwicklungslebenszyklus, z. B.: Bedrohungsmodellierung, statische Tests der Application , Softwarezusammensetzungsanalyse; und Bereitstellung von Sicherheitskontrollen in späteren Phasen in Umgebungen in früheren Phasen, z. B.: Web Application Firewall, dynamische Application usw. in Entwicklungs- und Testumgebungen.
Natürlich bringt verteilte Sicherheit eine Reihe von Herausforderungen mit sich. Um verteilte Sicherheit zu erreichen, war bisher der Einsatz unterschiedlicher Technologien, Stapel und Steuerelemente für unterschiedliche Umgebungen erforderlich. Dies führt jedoch zu keinen Skaleneffekten, da die Vielfalt der Umgebungen zunimmt und es exponentiell schwieriger wird, jede neue, unterschiedliche Umgebung und jeden neuen Steuerelementsatz zu unterstützen.
Dies bedeutet auch, dass die Sicherheit in unterschiedlichen Umgebungen kaum konsistent ist, was zu Problemen führen kann. Der wichtigste Punkt ist wohl, dass Sie für jede Umgebung unterschiedliche Warn-, Berichts- und Protokollierungsfunktionen haben, was die Verwaltung oder Vorhersage Ihrer Umgebungen sehr schwierig macht.
Wie funktioniert in einer idealen Welt die Sicherheit in einer dezentralen Umgebung mit mehreren Benutzern, Apps und Clouds?
Die Antwort ist ein einheitlicher Stapel, der überall dort eingesetzt werden kann, wo er benötigt wird. Der Stapel hätte einen kleinen Formfaktor, wäre für moderne Umgebungen geeignet und würde eine schnelle Bereitstellung und Außerbetriebnahme unterstützen. Dazu gehören auch umfassende Sicherheitskontrollen, die ausgereift und auf Unternehmensniveau sind.
Es gäbe einen zentralen Kontrollpunkt; einen einzigen Punkt, an dem die Richtlinien einmal definiert und global umgesetzt werden könnten. Die Richtliniendefinition wäre flexibel und würde Netzwerk, Identität, Sicherheit und Application definieren. Der zentrale Kontrollpunkt würde außerdem eine zentralisierte und einheitliche Sichtbarkeit, Protokollierung und Berichterstattung ermöglichen.
Und die gesamte Lösung wäre zu 100 % API-gesteuert, um es den Entwicklungs-, Sicherheits- und Betriebsteams wirklich zu ermöglichen, gemeinsam mit dem Geschäftstempo Schritt zu halten.
F5 kann Ihnen helfen, eine solche Vision zu verwirklichen. Mehr erfahren.