Spezifikation der Cloud Security Alliance

So setzen Sie Zero Trust mit dem Software-Defined Perimeter um

Zero Trust ist in aller Munde. Veredeln können Sie das Konzept mit dem Software-Defined Perimeter. Welche Möglichkeiten es dafür gibt, lesen Sie hier.
Von 
CSO | 28. April 2022 05:08 Uhr
Kein Zutritt für Unberechtigte. Kombinieren CSOs das Zero-Trust-Konzept mit dem Sofware-Defined Perimeter, verringern sie das Risiko für Cyberangriffe.
Kein Zutritt für Unberechtigte. Kombinieren CSOs das Zero-Trust-Konzept mit dem Sofware-Defined Perimeter, verringern sie das Risiko für Cyberangriffe.
Foto: Imilian - shutterstock.com

Nach sieben Jahren hat die Cloud Security Alliance (CSA) eine neue Spezifikation des Sicherheitskonzepts Software-Defined Perimeter (SDP) veröffentlicht. Während in dem Report von 2014 beschrieben wurde, wie der SDP eingesetzt werden kann, um Air-Gap-Netzwerke bereitzustellen, geht die CSA in der Neuauflage darauf ein, wie der Software-Defined Perimeter und das Konzept Zero Trust sich ergänzen.

Konkret erfahren CSOs in dem Report, wie sie mit entsprechenden Lösungen

  • einen dynamischen, softwaredefinierten Perimeter bereitstellen,

  • Netzwerke und Ressourcen verbergen, um unbefugten Zugriff zu verhindern und

  • ein identitätszentriertes Zugriffsmodell mit klaren Richtlinien durchsetzen.

Was ist die Cloud Security Alliance?

Die Cloud Security Alliance ist eine weltweit tätige Organisation, die sich auf Best Practices spezialisiert hat, um für sichere Cloud-Computing-Umgebungen zu sensibilisieren. Dafür nutzt die CSA das Wissen von Branchenpraktikern, Verbänden, Regierungen sowie den eigenen Unternehmensmitgliedern und einzelnen Mitgliedern. Die Community profitiert von dem gesammelten Wissen.

Neben Best Practices und Zertifizierungen bietet die CSA Handbücher und Roadmaps, mit denen die Organisation Maßstäbe für Cloud Security setzen will.

Was ist Software-Defined Perimeter?

Eines der Sicherheitskonzepte der CSA ist der Software-Defined Perimeter. Das Ziel ist es, den Zugriff auf Unternehmensdaten zu kontrollieren. Man spricht auch von der "Black Cloud".

Bei dem Architekturmodell handelt sich um einen Perimeter, der durch Software und nicht durch Hardware zustande kommt und Systeme vor nicht authentifizierten Nutzern verbirgt.

Der Hersteller Zscaler erklärt SDP wie folgt: "SDP ist eine Sicherheitsstrategie für die Cloud-Welt und die mobile Welt. Während die traditionelle Sicherheit im Rechenzentrum zentralisiert ist, ist SDP überall, wird von der Cloud bereitgestellt und verwendet Geschäftsrichtlinien, um zu bestimmen, wer Zugriff auf welche Ressourcen erhält."

Der Unterschied zwischen Zero Trust und Software-Defined Perimeter

SDP verfolgt ähnliche Grundsätze wie das Zero-Trust-Modell: Zugriff auf Anwendungen erhalten nur Nutzer, die ihre Vertrauenswürdigkeit nachweisen können. Deckungsgleich sind die beiden Ansätze allerdings nicht. Vielmehr können Unternehmen mithilfe von SDP Zero-Trust-Umgebungen implementieren.

Hinsichtlich ihrer Funktionsweisen unterscheiden sich die Ansätze: Zero Trust bezieht sich auf den Datenverkehr im Netzwerk. Der Zugriff auf Ressourcen wird blockiert, außer der Anwender authentifiziert sich und ist für den Zugriff zugelassen. Bei SDP sieht der nicht autorisierte Nutzer nicht einmal mehr die Tür. Die Ressourcen werden im Netzwerk hinter dem Perimeter verborgen, so dass Unberechtigte nicht darauf zugreifen können.

So funktioniert der Software-Defined Perimeter

Zu den grundlegenden Architekturkomponenten des SDP 2.0, wie ihn die CSA definiert, gehören SDP-Hosts und SDP-Controller. Aber auch eine Steuerungs- und eine Datenebene, die sowohl in Cloud-Umgebungen zu finden sind, als auch Umgebungen, die eine Service-Mesh-Architektur implementieren.

Ein SDP-Controller kann als Policy Decision Point (PDP) im Zero-Trust-Kontext betrachtet werden, an dem Administratoren Richtlinien für die Zugriffskontrolle definieren würden. Und ein SDP-Host funktioniert ähnlich wie ein Policy Enforcement Point (PEP). Er hilft bei der Durchsetzung der Zugriffsrichtlinien des SDP-Controllers. In der Regel werden SDP-Hosts vor Anwendungen und Diensten eingesetzt, um den Zugriff gemäß den Unternehmensrichtlinien zu kontrollieren.

Auf Grundlage dieser Informationen kommuniziert der SDP-Controller auch mit internen Instanzen wie Identitäts- und Zugriffsverwaltungs-Diensten (IAM) und möglicherweise mit externen Instanzen, wenn Unternehmen beispielsweise Cloud-basierte Identity-as-a-Service-Optionen (IDaaS) nutzen.

SDP-Hosts orientieren sich am Workflow der Zugriffsanfragen und agieren sowohl als initiierende wie auch als akzeptierende Hosts. Der initiierende Host liefert Informationen über die Identität des Nutzers, in manchen Organisationen auch Signale über den Zustand des Endgeräts oder dessen geografischen Standort.

Am anderen Ende steht ein akzeptierender Host. Im Wesentlichen fungiert dieser als PEP, um den Zugriff auf Unternehmensressourcen oder -dienste zu kontrollieren. Diese Hosts nehmen Anweisungen von den SDP-Kontrolleuren entgegen und erleichtern so die Durchsetzung von Entscheidungen über die Zugangskontrolle.

So stellen Sie den Software-Defined Perimeter bereit

Die CSA nennt sechs Möglichkeiten, wie Unternehmen eine SDP-Architektur bereitstellen können:

  • Client-to-Gateway: Wenn ein oder mehrere Server hinter einem Gateway geschützt werden müssen, werden die Verbindungen zwischen dem Client beziehungsweise dem initiierenden Host und dem Gateway unabhängig von der zugrunde liegenden Netzwerktopologie gesichert.

  • Client-to-Server: Wenn eine Organisation Anwendungen zu einem IaaS-Anbieter verlagert, um End-to-End-Verbindungen zu sichern, kombiniert dieses Modell einen Server und ein Gateway in einem einzigen Host.

  • Server-to-Server: Dieses Modell eignet sich am besten für IoT- und VM-Umgebungen und stellt sicher, dass alle Verbindungen zwischen Servern verschlüsselt werden, unabhängig von der zugrundeliegenden Netzwerk- oder IP-Infrastruktur.

  • Client-to-Server-to-Client: In einigen Fällen wird der Peer-to-Peer-Verkehr über einen zwischengeschalteten Server geleitet, wie bei IP-Telefon-, Chat- und Videokonferenzdiensten. In diesen Fällen verschleiert der SDP die IP-Adressen der sich verbindenden Clients, verschlüsselt Netzwerkverbindungen zwischen den Komponenten und schützt den Server beziehungsweise den akzeptierenden Host vor nicht autorisierten Netzwerkverbindungen.

  • Client-to-Gateway-to-Client:Dieses Modell ist eine Variante des Modells Client-to-Server-to-Client. Es unterstützt Peer-to-Peer-Netzwerkprotokolle, die von Clients verlangen, dass sie sich direkt miteinander verbinden, während SDP-Zugriffsrichtlinien durchgesetzt werden.

  • Gateway-to-Gateway: Auch dieses Modell eignet sich gut für bestimmte IoT-Umgebungen. In diesem Szenario sitzen ein oder mehrere Server hinter dem akzeptierenden Host, sodass das dieser als Gateway zwischen Clients und Servern fungiert. Gleichzeitig sitzen ein oder mehrere Clients hinter einem initiierenden Host, so dass er auch als Gateway fungiert.

Grundsätzlich sollten Unternehmen die verschiedenen Bereitstellungsmodelle prüfen und diejenige verwenden, die am besten zu ihren individuellen Anforderungen passen.

Zusammenfassend sagen die Autoren des Reports, dass SDP ein Ersatz für das Virtual Private Network (VPN) sein kann. Letztendlich ist es jedoch möglich, SDP für die Zugriffskontrollen aller Nutzer zu verwenden. Unternehmen sollten sich, was die Vorsichtsmaßnahmen angeht, schließlich nicht nur auf Remote-Mitarbeiter beschränken. (ms)

Dieser Artikel basiert auf einem Beitrag der US-Schwesterpublikation CSO Online.

Chris Hughes schreibt für unsere US-Schwesterpublikation CSO Online.