Operationalisierung von Zero Trust – Schritt 6: Validieren, Implementieren und Überwachen

Diese Blog-Serie erweitert die Ideen, die ich in meinem März-Beitrag "Zero Trust ist nicht schwer ... Wenn du pragmatisch bist."

In diesem Beitrag habe ich sechs Schritte zum Erreichen von Zero Trust skizziert, und hier möchte ich auf den letzten Schritt eingehen, nämlich Valide, Implementierung und Überwachung. Ich zeige Ihnen, wie dieser Schritt die Implementierung eines soliden Frameworks unterstützen kann, das von jedem Mikrosegmentierungspraktiker verwendet werden kann, um seine Projekte erfolgreicher zu machen, unabhängig von der Größe der Organisation.

Bevor ich beginne, hier eine Auffrischung der sechs Schritte:

Zusammenfassung – Schritt 5: Entwerfen der Richtlinie

Im letzten Beitrag dieser Serie habe ich mich mit dem Thema "Designing the Policy" befasst. Dort habe ich gezeigt, wie das Application Dependency Mapping relevante Flows identifiziert:

Und von hier aus haben wir den folgenden Satz von Zulassungsregeln abgeleitet:

• Regel 1:
• Quelle: Webserver, Zahlungen, Produktion, Großbritannien
• Ziel: DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien
• Zieldienst: 53/udp
• Zielprozess: benannt
• Regel 2:
• Quelle: App Server, Payments, Production, UK
• Ziel: DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien
• Zieldienst: 53/udp
• Zielprozess: benannt
• Regel 3:
• Quelle: Webserver, Zahlungen, Produktion, Großbritannien
• Ziel: App Server, Zahlungen, Produktion, Großbritannien
• Zieldienst: 8080/tcp
• Zielprozess: Tomcat

Unter Berücksichtigung der Prinzipien von Zero Trust definieren die oben aufgeführten Zulassungsregeln genau, was erlaubt ist – alles, was nicht explizit erlaubt ist, wird implizit fallen gelassen, wodurch die Eigenschaft der geringsten Rechte erhalten bleibt.

Schritt 6: Validieren, Implementieren und Überwachen

Jetzt, da Sie Mikrosegmentierungsregeln definiert haben, sind Sie bereit, diese durchzusetzen und Ihre Workloads zu schützen – eine große Herausforderung bleibt jedoch bestehen. Ihre Zahlungsanwendung befindet sich in der Produktionsphase, und Sie möchten ihre Funktionalität nicht unterbrechen, während Sie sie abgrenzen. Wie können Sie dieses Risiko mindern?

Bei allen Segmentierungsbemühungen besteht die Phase, die das größte Risiko birgt, darin, die Richtlinien durchzusetzen, die so geschrieben wurden, dass kein anderer Datenverkehr in oder aus den Workloads zugelassen wird. Wenn die Richtlinien falsch sind, besteht die Möglichkeit, dass es zu einem Produktionsausfall kommt. Daher muss der Übergang zur Durchsetzung kontrolliert werden und über ausreichende Überwachungsmöglichkeiten verfügen, damit Probleme schnell erkannt und behoben werden können.

Hier kommt das Testen von Richtlinien ins Spiel. Illumio Core bietet eine leistungsstarke, aber einfache Möglichkeit, dies durchzuführen. Eine der nützlichsten Funktionen der Illumio Core-Plattform ist die Möglichkeit, Workloads (oder Gruppen von Workloads) in den Testmodus zu verschieben – wie der Build-Modus ist der Testmodus ein nicht blockierender Modus mit dem zusätzlichen Vorteil, dass er Richtlinienverstöße meldet. Für eine Workload im Testmodus überlagert der PCE das Konnektivitätsdiagramm, das mit Flow-Daten von Workloads erstellt wurde, mit dem Richtliniendiagramm.

Das Richtliniendiagramm kann so betrachtet werden, dass Blasen um Workloads gelegt werden, die über einen bestimmten Satz von Ports und Protokollen miteinander kommunizieren dürfen. Das Konnektivitätsdiagramm zeigt die versuchte Kommunikation zwischen Workloads.

• Wenn sich das Konnektivitätsdiagramm innerhalb einer Blase im Richtliniendiagramm befindet, erhalten Sie grüne Linien – dies sind Flows, die mit der von uns erstellten Richtlinie übereinstimmen.

• An der Stelle, an der das Konnektivitätsdiagramm die Blase im Richtliniendiagramm kreuzt, erhalten Sie rote Linien – dies sind Flows, die nicht mit einer erstellten Richtlinie übereinstimmen.

Im Testmodus blockieren diese "roten" Linien zwar keine Datenflüsse, zeigen aber an, wo wir Verbindungsversuche haben, die gegen die Richtlinie verstoßen. Als Anwendungsbesitzer überprüfen Sie die folgenden Flows, und Sie haben folgende Auswahlmöglichkeiten:

• Flow ist erforderlich – > Richtlinie schreiben, um die Zeile grün zu machen
• Flow ist nicht erforderlich – > es müssen keine Maßnahmen ergriffen werden

Der Prozess der Richtlinienvalidierung erfordert also das Durchlaufen all dieser "roten" Linien, um zu bestimmen, ob sie grün werden müssen. Sobald Sie alle diese "Verstöße" überprüft und Ihre Wahl getroffen haben, können Sie mit dem Schutz der Workloads beginnen – unser Validierungsprozess ist abgeschlossen, Zeit für die Durchsetzung.

Wenn Sie bedenken, dass der Zweck der Phase "Validieren, Implementieren und Überwachen" in Wirklichkeit darin besteht, das Risiko zu minimieren, sollten Sie im Idealfall keinen "Big Bang"-Ansatz verfolgen, um Richtlinien für Ihre Workloads durchzusetzen. Trotz der detaillierten Validierung, die Sie möglicherweise bereits durchgeführt haben, sollten Sie in dieser letzten Phase noch inkrementelle Schritte unternehmen. Auch hier ermöglicht die granulare Kontrolle, die Illumio über die Arbeitslasten bietet, genau dies. Jede Workload in einer Anwendung kann einzeln in den erzwungenen Modus verschoben werden – das bedeutet, dass Sie, sobald Sie eine vollständig validierte Richtlinie haben, auswählen können, für welche Workloads Sie zuerst den vollständigen Schutz aktivieren möchten, und diese mit der erzwungenen Richtlinie ausführen lassen können (d. h. Nur Datenverkehr, der von der Richtlinie zugelassen ist, ist in der Lage, die Workload ein- bzw. auszugeben) und die anderen Workloads nach einer gewissen "Soak-Time" in einen erzwungenen Zustand zu versetzen. Der Vorteil dieses Ansatzes besteht darin, dass im Falle von Problemen mit der Richtlinie nur eine kleine Anzahl von Workloads und nicht die gesamte Flotte betroffen ist – und er bietet eine weitere Möglichkeit zur Feinabstimmung, bevor die gesamte Anwendung aktiviert wird.

Jetzt, da alle unsere Workloads durchgesetzt werden und die Anwendung geschützt ist, besteht die Aufgabe darin, Datenverkehrsereignisse kontinuierlich auf Unerwartetes zu überwachen – Verwerfungen und Akzepte – und alles zu untersuchen, was außerhalb des Normalen liegt.

Einhüllend

Da haben wir es also: eine exemplarische Vorgehensweise der sechs Schritte eines pragmatischen Ansatzes in Richtung Zero Trust. Wie Forrester feststellt, ist Zero Trust kein Ergebnis an sich, sondern eine Sicherheitsstrategie, und jedes Unternehmen muss seinen eigenen Reifegrad in den Zero-Trust-Säulen verstehen, herausfinden, auf welche Säulen der Fokus am meisten gelegt werden muss, und schrittweise Schritte unternehmen, um diesen Reifegrad zu verbessern. Illumio ist ein führender Anbieter von ZTX-Ökosystem-Plattformen und bietet ein vollständiges Leistungsspektrum, um diese Schritte in den Bereichen Netzwerk- und Workload-Transparenz und -Sicherheit durchzuführen.

Haben Sie die Schritte 1-5 in unserer Serie zur Operationalisierung von Zero Trust verpasst? Schauen Sie sie sich jetzt an:

• Schritt 1: Identifizieren Sie, was geschützt werden soll
• Schritt 2 und 3: Bestimmen Sie, auf welche Zero-Trust-Säule Sie sich konzentrieren möchten, und legen Sie die genaue Kontrolle fest
• Schritt 4: Vorschreiben, welche Daten benötigt werden
• Schritt 5: Entwerfen der Richtlinie

Und wenn Sie mehr über Zero Trust erfahren möchten, besuchen Sie unsere Lösungsseite – erfahren Sie, wie Sie noch heute mit Ihrer Reise beginnen können.