Zero Trust operationalisieren — Schritt 5: Entwerfen Sie die Richtlinie

Diese Blogserie erweitert die Ideen, die ich in meinem März-Beitrag vorgestellt habe,“Zero Trust ist nicht schwer... Wenn Sie pragmatisch sind.“

In diesem Beitrag habe ich sechs Schritte zur Erreichung von Zero Trust skizziert, und hier möchte ich auf einen dieser Schritte näher eingehen, nämlich die Gestaltung der Richtlinie. Ich werde Ihnen zeigen, wie dieser Schritt die Implementierung eines soliden Frameworks unterstützen kann, das von jedem Experten im Bereich Mikrosegmentierung genutzt werden kann, um seine Projekte unabhängig von der Größe des Unternehmens erfolgreicher zu machen.

Bevor ich anfange, hier eine Auffrischung der sechs Schritte:

Schritt 5: Entwerfen Sie die Richtlinie

In der letzter Beitrag In dieser Serie habe ich mich mit „Vorschreiben, welche Daten benötigt werden“ befasst. In diesem Artikel habe ich auf folgenden Punkt hingewiesen:

„Einer der wichtigsten Aspekte von Zero Trust — und es wird nicht annähernd so viel Beachtung geschenkt, wie es sollte — ist Eine effektive Umsetzung von Zero Trust hängt vom Zugang zu Kontextinformationen oder Metadaten ab, um bei der Formulierung von Richtlinien zu helfen. Wenn es also um Mikrosegmentierung im Zusammenhang mit dem Schutz von Workloads geht, beschreiben die minimalen Metadaten außerhalb eines Standarddatenverkehrsberichts, die Sie benötigen, Workloads im Kontext Ihrer Rechenzentrumsanwendungen und -umgebungen.“

Basierend auf dieser Aussage sind die drei wichtigsten Daten, die wir benötigen, folgende:

1. Verkehrsereignisse in Echtzeit für die Workloads, die wir schützen wollen.
2. Kontextdaten für jeden Workload und jede Verbindung — Dazu gehören Metadaten im Zusammenhang mit der Arbeitslast, die von einem Aufzeichnungssystem wie einer CMDB stammen würden, sowie Informationen wie Details des Kommunikationsprozesses, die direkt aus dem Workload stammen. “
3. Ein Abbildung der Anwendungsabhängigkeiten (abgeleitet aus den Punkten 1 und 2), das es einem Anwendungsbesitzer oder Segmentierungsexperten ermöglicht, die vor- und nachgelagerten Abhängigkeiten einer bestimmten Anwendung schnell zu visualisieren.

Alles zusammenfügen

Jetzt sind Sie fast bereit, diese Richtlinie zu erstellen, aber lassen Sie mich Sie an die Ziele erinnern:

• Sie möchten eine Mikrosegmentierungsrichtlinie erstellen, um Ihre Workloads zu schützen.
• Sie möchten, dass diese Richtlinie den Prinzipien von Zero Trust folgt.
• Daher müssen die Regeln, die Sie erstellen, nur den Zugriff auf und aus den Workloads zulassen, die für die Ausführung ihrer Geschäftsfunktion erforderlich sind.

Im Anschluss an die Daten, die ich für „notwendig“ hielt, finden Sie unten Beispiele für einige Verkehrsprotokolleinträge, die zum Erstellen einer Richtlinie verwendet werden können:

Verkehrsprotokollverbindung 1:

• Quelle: 10.0.0.1, 10.0.0.2
• Quellkontext: Webserver, Zahlungsanwendung, Produktion, Großbritannien
• Zielort: 192.168.0.1
• Ziel: Kontext: DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien o Zielprozess: benannt
• Hafen: 53
• Protokoll: UDP
• Aktion: Erlauben

Verkehrsprotokollverbindung 2:

• Quelle: 10.0.0.1,10.0.0.2
• Quellkontext: Webserver, Zahlungsanwendung, Produktion, Großbritannien
• Ziel: 10.0.1.5,10.0.1.6,10.0.1.7
• Zielkontext: App-Server, Zahlungsanwendung, Produktion, Großbritannien
• Zielprozess: Tomcat
• Hafen: 8080
• Protokoll: TCP
• Aktion: Erlauben

Verkehrsprotokollverbindung 3:

• Quelle: 10.0.1.5, 10.0.1.6,10.0.1.7
• Quellkontext: App Server, Zahlungsanwendung, Produktion, Großbritannien
• Zielort: 192.168.0.1
• Ziel: Kontext: DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien
• Zielprozess: benannt
• Hafen: 53
• Protokoll: UDP
• Aktion: Erlauben

Verkehrsprotokollverbindung 4:

• Quelle: 10.1.0.1,10.1.0.2
• Quellkontext: Webserver, Zahlungsanwendung, Produktion, Deutschland
• Ziel: 10.0.1.5,10.0.1.6,10.0.1.7
• Zielkontext: App-Server, Zahlungsanwendung, Produktion, Großbritannien
• Zielprozess: httpd
• Hafen: 80
• Protokoll: TCP
• Aktion: Erlauben

Verkehrsprotokollverbindung 5:

• Quelle: 10.1.2.1,10.1.2.2
• Quellkontext: Datenbankserver, Zahlungsanwendung, Produktion, Deutschland
• Ziel: 10.0.1.5,10.0.1.6,10.0.1.7
• Zielkontext: App-Server, Zahlungsanwendung, Produktion, Großbritannien
• Zielprozess: httpd
• Hafen: 80
• Protokoll: TCP
• Aktion: Erlauben

Auf diese Weise können Sie schnell die Anwendungsabhängigkeitskarte ableiten.

So weit, so gut.

Jetzt können Sie sich Ihre Anwendungsabhängigkeitskarte ansehen, um festzustellen, welche Flows Sie tatsächlich zulassen möchten. Aufgrund der Kenntnis Ihrer Anwendung wissen Sie, dass beispielsweise die folgenden Abläufe erforderlich sind:

1. Webserver, Zahlungen, Produktion, Großbritannien -> DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien auf 53/udp
2. App-Server, Zahlungen, Produktion, Großbritannien -> DNS-Responder, DNS-Infrastruktur, Produktion, Großbritannien auf 53/udp
3. Webserver, Zahlungen, Produktion, Großbritannien -> App Server, Zahlungen, Produktion, Großbritannien auf 8080/tcp

Sie wissen auch, dass die folgenden beiden Abläufe nicht richtig aussehen und daher nicht in Ihren ursprünglichen Regeln enthalten sein sollten:

1. Webserver, Zahlungen, Produktion, Deutschland -> App Server, Zahlungen, Produktion, Großbritannien auf 80/tcp
2. DB-Server, Zahlungen, Produktion, Deutschland -> App Server, Zahlungen, Produktion, Großbritannien auf 80/tcp

Die Anwendungsabhängigkeitskarte, aus der Sie Regeln erstellen, sieht am Ende wie folgt aus:

Nun, wie drückt man diese Regeln eigentlich aus? Bei herkömmlichen Firewalls müssten Sie diese mithilfe von Quell- und Ziel-IP-Adressen definieren. Auf diese Weise werden jedoch alle umfangreichen Kontextinformationen, von denen Sie bei der Entdeckung dieser Datenflüsse profitiert haben, vollständig entfernt. Schlimmer noch, bedeutet, dass dieser Kontext erneut eingefügt werden muss, wenn die Regel überprüft wird. Was passiert außerdem, wenn Sie einen zusätzlichen DNS-Responder oder einen neuen App Server oder Webserver für die Zahlungs-App hinzufügen?

Denken wir daran, dass Sie versuchen, eine Richtlinie zu entwickeln, die den Zero-Trust-Prinzipien entspricht, d. h. sicherzustellen, dass immer die geringsten Privilegien gelten. Ein kontextbasierter Ansatz, bei dem eine adaptive Sicherheits-Engine im Hintergrund ihre Magie entfaltet, ermöglicht genau das. So wie Ihre Richtlinie erweitert wird, um einen neuen Server mit vorhandenem Kontext einzubeziehen, möchten Sie auch, dass Ihre Richtlinie schrumpft, wenn Sie einen Server außer Betrieb nehmen. Wenn Sie beispielsweise einen Ihrer DNS-Responder stilllegen, möchten Sie, dass alle Regeln, die zuvor den Zugriff auf/von diesem Server aus erlaubten, aktualisiert werden, sodass dieser Zugriff nicht mehr möglich ist. Das ist genau das, was Illumio ist Richtlinie Compute Engine (PCE) ist dafür gemacht — die Mikrosegmentierungsrichtlinie wird mithilfe von Metadaten definiert, und das PCE bestimmt dann, welche Workloads zu diesem bestimmten Zeitpunkt mit den Metadaten übereinstimmen, um dann die tatsächlichen Regeln zu berechnen, die bei jedem Workload durchgesetzt werden müssen, um die Zero-Trust-Sicherheitslage aufrechtzuerhalten. Jedes Mal, wenn sich der Kontext ändert, passt das PCE die Richtlinie an und benachrichtigt Workloads über Aktualisierungen.

Vor diesem Hintergrund läuft Ihre Zero-Trust-Richtlinie auf die folgenden Regeln hinaus:

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, Zahlungen, Produktion, Großbritannien
• 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

Und das war's.

Sind Sie bereit, den nächsten Schritt auf Ihrer Zero-Trust-Reise zu machen? Besuchen unsere Seite darüber, wie Sie Ihre Zero-Trust-Strategie mit Mikrosegmentierung operationalisieren können, um Insiderinformationen zu erhalten.