F5 Freitag: Wie Standardisierung einen anpassbaren Ansatz für die App-Sicherheit pro App (Microservices) ermöglicht
Ich habe und noch mehr über den zunehmenden Bedarf an anwendungsaffinen Diensten gesprochen , um die Apps, die sie schützen, skalieren und optimieren, noch sicherer zu machen. Genauso wie App-Entwickler feststellen, dass es effizienter und flexibler ist, Monolithen in fokussiertere, granularere Microservices aufzuteilen, muss sich auch die Infrastruktur an dieser Entwicklung orientieren, um im großen Maßstab weiterhin das gleiche Serviceniveau und die gleiche Servicequalität bieten zu können.
Dieser Ansatz ist jedoch nicht nur für Microservices-Architekturen geeignet. Es ist außerdem für Organisationen gedacht, die schnell und in großem Umfang Richtlinien für einzelne Apps bereitstellen müssen. So ergab beispielsweise eine Studie , dass „85 % der Unternehmen einen Rückstand bei der mobilen Nutzung zwischen einer und 20 Anwendungen haben, bei der Mehrheit (50 %) liegt der Rückstand bei 10 bis 20 Apps“. Hinzu kommt die Vielzahl bereits bestehender Apps, für die Updates ausgerollt werden müssen (unsere Untersuchungen ergaben, dass fast die Hälfte der Unternehmen zwischen 1 und 200 Apps hat, die andere Hälfte weit über 200, einschließlich der unglaublichen 10 %, die mehr als 3.000 Apps verwalten müssen).
Für die meisten davon sind sehr spezifische Richtlinien erforderlich, um Umfang, Sicherheit und Leistung sicherzustellen. Sie müssen skalieren, aber Sie müssen schnell skalieren, um alles zu bewältigen.
Einer der Nachteile eines Pro-App-Service-Ansatzes besteht natürlich darin, dass jeder Service individuell an die individuellen Anforderungen der jeweiligen App angepasst werden muss, die er bereitstellt. Das ist natürlich der springende Punkt, doch ohne einen strategischen Ansatz zur Skalierung der Abläufe hinter der Richtlinienerstellung und -bereitstellung, um dieser Nachfrage gerecht zu werden, könnte ein solcher Ansatz möglicherweise zu längeren und nicht zu schnelleren Bereitstellungszeiten führen.
Aus diesem Grund sollten DevOps und seine Infrastruktur-als-Code-Philosophie in Kombination mit einem Schwerpunkt auf Automatisierung für Sicherheitsoperationen nicht nur als angemessen, sondern als wünschenswert angesehen werden. Denn nur durch die Verlagerung der Web-Sicherheit nach links kann ein ganzheitlicher Microservices-Ansatz über Apps und App-Dienste hinweg erfolgreich sein. Tatsächlich ist es von entscheidender Bedeutung, dass die Sicherheit mit der Geschwindigkeit Schritt halten kann, mit der die IT heute ihre Dienste den unterstützten Kunden bereitstellen soll.
Aus diesem Grund hat Catholic Education South Australia (CESA), das IT-Dienste für über 98 Schulen in ganz Südaustralien bereitstellt, die F5-Plattform eingeführt. CESA kämpfte mit Herausforderungen, die sich aus herkömmlichen Bereitstellungs- und Implementierungsmethoden ergaben, die einfach nicht die horizontale Skalierung ermöglichten, die erforderlich war, um mit der Nachfrage Schritt zu halten. Was sie brauchten, war ein anpassbares Framework für die Bereitstellung von Anwendungen und die Automatisierung damit verbundener Aufgaben. Und dazu gehörte schließlich auch die Websicherheit.
Simon Sigre, leitender Netzwerkingenieur bei CESA, erklärt, warum eine Änderung notwendig war: „ Wir mussten mit der Entwicklung von Layer-7-Sicherheitsrichtlinien (L7) beginnen, die sich wie angegossen um jede Web-Anwendung legten .“
CESA musste Richtlinien für jede App bereitstellen, dies musste jedoch schnell und im großen Maßstab geschehen. Das heißt, um dieses Kunststück zu vollbringen, war Automatisierung erforderlich. Aber das war nicht alles, was sie brauchten. Das Anpassen von Richtlinien – insbesondere von Richtlinien, die so eng mit der App verknüpft sind, die sie schützen – braucht Zeit. Aber nicht alles an einer Anwendung ist einzigartig. Es gibt gemeinsame Elemente, insbesondere solche im Zusammenhang mit Protokollen (wie TCP und HTTP) und Plattformen (wie der Web- oder App-Server-Software), die bei vielen Anwendungen gleich bleiben. Das Konfigurieren von Richtlinien zum Sichern dieser Aspekte nimmt ebenfalls Zeit in Anspruch – Zeit, die auf mehrere Anwendungen verteilt wird.
Hier kommt die Standardisierung zur Rettung. Eines der Kennzeichen der Standardisierung ist die Fähigkeit, Gemeinsamkeiten bei APIs, Vorlagen, Befehls- und Kontrollsystemen sowie Skripten zu nutzen, um die Effizienz zu verbessern, was sich in geringeren Betriebskosten und einer schnelleren Markteinführung niederschlägt. Und genau das hat CESA getan, als es sich die Programmierbarkeit von F5 zunutze machte, um nicht nur die Skalierbarkeit zu automatisieren, sondern auch Sicherheitsrichtlinien zu standardisieren. Dazu wurden hochrangige Vorlagen für häufig verwendete Technologien erstellt und diese dann angepasst, um den Unterschieden bei jedem neuen Dienst Rechnung zu tragen. Sie konnten die benötigten Sicherheitsrichtlinien für einzelne Apps entwickeln, ohne die normalerweise mit Anpassungen verbundenen Kosten zu verursachen, indem sie die Infrastruktur (Websicherheit) als Code (Vorlagen) behandelten. Dadurch entfielen effektiv die Kosten, die mit der Neuerstellung der Basisrichtlinie bei jeder Bereitstellung eines neuen Dienstes verbunden sind.
Weitere Informationen zu CESAs Erfahrungen mit F5 und seinen Technologien finden Sie direkt hier in dieser Kundengeschichte.