Wie Sie NetOps-Initiativen mit Agile-Methoden absichern
Immer mehr NetOps-Teams nutzen agile Methoden. Daher müssen Netzwerk- und Sicherheitstests einem ganzheitlichen Ansatz folgen, bei dem verschiedene Teams zusammenarbeiten.
NetOps kann einfache eine Abkürzung für Network Operations (Netzwerkbetrieb) sein. Es ist aber auch eine Disziplin, die Netzwerkteams den Umgang mit Infrastructure as Code (IaC) erleichtert. IaC bietet Netzwerk- und Sicherheitsteams eine Option, um DevOps zu nutzen und Netzwerkautomatisierung mithilfe von Continuous Integration und Continuous Development zu realisieren.
Continuous Integration und Continuous Development definieren die neue Grenze bei Orchestrierung und Automatisierung. Stellen Sie sich vor, die Agile-Methodologie würde über den Software Development Lifecycle (SDLC) hinausgehen und eine Anwendung vom Testen bis zur Qualitätssicherung (Quality Assurance, QA) oder von der QA zur Produktion begleitend unterstützen. Automation kann die notwendigen Änderungen an Netzwerk-, Storage- und Sicherheits-Appliances vornehmen, die es einer Anwendung ermöglichen, Dienste für die Benutzer bereitzustellen.
Ein Überblick über DevOps und Agile
DevOps ist ein Konzept, das auf dem Modell der agilen Softwareentwicklung basiert. Es stellt die traditionelle Wasserfall-Entwicklungsmethodik auf den Kopf. Hierbei handelt es sich um eine unkomplizierte Methode, die sich sequenziell von den Anforderungen über das Design, die Implementierung, das Testen und die Bereitstellung erstreckt – gefolgt von ebenso wichtigen Wartungszyklen. Das Hauptproblem bei diesem Ansatz besteht jedoch in einer langsamen Markteinführung, und das Endprodukt ist bis zur Bereitstellung nicht nutzbar. Die Entwicklung vieler solcher Systeme kann Monate oder sogar Jahre dauern.
Bei Agile hingegen entstehen die Funktionen im Laufe der Zeit, während die grundlegende Funktionalität bereits nach wenigen Wochen zur Verfügung stehen kann. Die iterativen Sprints ermöglichen ein schnelles Prototyping, und Agile stellt Funktionen deutlich schneller bereit als frühere Modelle.
DevOps erzeugt zwar eine Umgebung für Continuous Development, hat aber den Nachteil, dass die Software eine reale Bereitstellung über eine Infrastruktur erfordert, was nach wie vor weitgehend manuell erfolgt und sich am Wasserfallmodell orientiert. Die Infrastruktur kann virtuell sein und in einer Cloud oder physisch bereitgestellt werden. Aber sie muss trotzdem vorhanden sein, um eine Anwendung zu unterstützen und auf die erforderlichen Daten zuzugreifen.
NetOps und Service Chaining
Wasserfallsysteme verwenden in der Regel eine statische Infrastruktur, und die Application Delivery Chain umfasst alle Aspekte einer statischen Infrastrukturänderung. Diese Aufgabe lässt sich automatisieren, besteht aber oft aus separaten, nicht koordinierten Tätigkeiten – etwa Automatisierung der Bereitstellung im Data Center oder Anfragen zum Hinzufügen von Firewall- oder Load-Balancer-Regeln. Jedes Team kümmert sich um seine eigenen Aufgaben und automatisiert seine eigenen Prozesse. Doch der Dienst steht erst dann zur Verfügung, wenn das letzte Element in einer relativ langen Service Chain abgeschlossen ist.
NetOps hingegen sieht den Einsatz einer agileren Methodologie vor und betrachtet alle beteiligten Komponenten. Dieser Prozess wird als Service Chaining bezeichnet, bei dem SDN-Funktionen (Software-defined Networking) in einer bestimmten Reihenfolge hinzugefügt werden, um den Traffic-Fluss zwischen den Services in einem virtuellen Netzwerk zu automatisieren. Service Chaining kann eine Anwendung in einem Rutsch bereitstellen, zusammen mit dem entsprechenden Netzwerk, den Netzwerkdiensten und der erforderlichen Sicherheit, um Workloads von Test/Entwicklung über QA bis hin zur Produktion zu unterstützen.
Diese Art von Automatisierung kann vorlagengestützte Ansätze ermöglichen. Diese Vorlagen bilden die Grundlage für den Code, den die Service Chain für die gesamte IT Delivery Chain über die DevOps-SDLC-Prozesse hinweg verwenden wird.
Der Prozess, bei dem ein System End-to-End-Services bereitstellt, wird oft als Serviceorchestrierung bezeichnet. Einige Unternehmen zögern, sich auf dieses Prinzip einzulassen, da sie der Meinung sind, dass Automatisierung ein Sicherheitsalptraum sein könnte, beispielsweise wenn jemand Automatisierung gegen ein Unternehmen einsetzt. Diese Einschätzung ist kurzsichtig, da eine ordnungsgemäße Implementierung keine manuelle Aktivierung dieser Art von Diensten außerhalb einer zugelassenen Change Control erlauben würde – wobei eine Rücknahme der Änderung, ebenfalls per Automatisierung, vorgeschrieben ist.
Eine Frage der Kultur
Traditionelle IT-Prozesse nach dem Wasserfallmodell erfordern die Koordination mehrerer Teams. Im Allgemeinen müssen die Server-, Netzwerk- und Sicherheitsteams des Unternehmens zusammenarbeiten, um einen neuen Dienst bereitzustellen. Aber das Zusammenspiel funktioniert häufig nicht gut. Die Anwendungs- und Serverteams schlagen üblicherweise einen neuen Service vor und überlassen es dem Netzwerkteam, die erforderlichen Subnetze, Load Balancing, Verschlüsselung und Firewalls zu konzipieren. Wenn die Netzwerkgruppe fertig ist, ist das Sicherheitsteam an der Reihe.
Als Fazit lässt sich festhalten, dass der operative Bereich einen ganzheitlichen Ansatz verfolgen muss. In einer DevOps-Welt müssen Security und Networking Teil der Lösung sein.
Ich habe die folgende Erfahrung gemacht, als einer unserer Kunden DevOps für Webanwendungen implementierte. Das Serverteam erstellte ein Automationssystem, das Ressourcen für eine vollständige SDLC-Umgebung mit Workloads für eine Sandbox-, Test-/Entwicklungs-, QA- und Produktionsumgebung bereitstellen konnte. Die Entwicklungsabteilung war hellauf begeistert. Da die Bereiche Netzwerk und Sicherheit jedoch nicht einbezogen wurden, generierte das System E-Mails an die Teams, die sich um Load Balancing, Network Address Translation (NAT) und die Firewall kümmern.
Man sagt, die Automatisierung einer Komponente einer Service Chain bewirke nichts anderes als die Verlagerung eines Engpasses. In Wahrheit ist es noch viel schlimmer. Da der Kunde eine agile Arbeitsumgebung für Entwickler aufgebaut hatte und das Serverteam die von anderen Teams geleistete externe Arbeit nicht verfolgte, traten erhebliche Probleme auf. Die Automatisierung deaktivierte nicht benötigte Workloads, berücksichtigte aber nicht die von diesen Workloads genutzten Netzwerk- und Sicherheitskomponenten. Im Laufe der Jahre wurden verwaiste Firewall-Regeln zum Top-Problem für den Kunden.
Wie man Anwendungen in Agile absichert
Diese Infrastruktur- und DevOps-Konzepte eignen sich ideal für die Einbindung in ein Agile-System. Mit dem möglichen Automatisierungsgrad können Sicherheitstests Teil des Prozesses werden und zwischenzeitliches Feedback liefern. Dies kann von Sprint zu Sprint geschehen, anstatt bis zum Ende eines Projekts zu warten, wenn bereits Zusagen für die Bereitstellung gemacht wurden. In Wasserfallsystemen sind die Sicherheits- und Testgruppen häufig diejenigen, die die Bereitstellung verzögern.
Als Fazit lässt sich festhalten, dass der operative Bereich einen ganzheitlichen Ansatz verfolgen muss. In einer DevOps-Welt müssen Security und Networking Teil der Lösung sein. Ein neuer Begriff, den man in Erwägung zieht, sieht eine Variante der diversen DevNetSecOps-Abkürzungen vor, was eine umfassendere Zusammenarbeit von Entwicklern, Networking-Teams und Sicherheitsmitarbeitern unterstützt.
