Illustration Absmeier Quelle Tenable

Worauf Unternehmen bei der Umsetzung von Shared-Responsibility-Modellen achten müssen, um teure Missverständnisse zu vermeiden.

Das Shared Responsibility Model (SRM) ist ein Schlüsselkonzept der Cloud Security – kann Unternehmen aber auch überfordern und vor erhebliche Herausforderungen stellen. Bernard Montel, EMEA Technical Director und Security Stratagist beim Exposure-Management-Spezialisten Tenable, erläutert im Folgenden, worauf Unternehmen bei der Umsetzung des SRM achten müssen.

Von einem Shared Responsibility Model (SRM) spricht man in der Cloud Security, wenn der Cloud Service Provider (CSP) und der Kunde spezifische Rollen bei der Absicherung der Systeme übernehmen. Der CSP zeichnet dabei typischerweise für die zugrundeliegende Infrastruktur und die Services in der Cloud verantwortlich, während der Kunde die Verantwortung für die Daten und Anwendungen in der Cloud übernimmt. Hinter dem Ansatz steht die Idee, die Verantwortlichkeiten klar voneinander abzugrenzen und verbindliche Zuständigkeiten zu definieren, um einen sicheren Betrieb der Cloud-Umgebung zu garantieren.

So ist die Verantwortung beim SRM von Amazon Web Services (AWS) klar zweigeteilt: für einige Aspekte ist AWS verantwortlich, für andere der Kunde – und die Bereiche sind klar getrennt.

Quelle Tenable

Eben diese vermeintlich klaren Grenzen führen in der Praxis aber oft zu Missverständnissen. Viele Anwender interpretieren das Modell so, dass die Cloud Security im Prinzip ausschließlich Sache des CSPs ist – und sie selbst nur kleine Teilbereiche verantworten, etwa den Schutz von Zugriffen und Daten. Das ist, wie Security-Experten wissen, schlichtweg falsch. Das Gegenteil ist der Fall: Beim SRM geht es nicht darum, die Verantwortung in einzelne Aufgabenbereiche zu unterteilen und diese großen Blöcke zuzuweisen – sondern darum, sich gemeinsam der gesamten Verantwortung bewusst zu werden und diese auch gemeinsam zu schultern.

Die Verantwortlichkeiten hängen vom Delivery-Modell ab

Wie viel Verantwortung dem Kunden im SRM zukommt, hängt primär vom Cloud-Modell ab. Die folgende Grafik zeigt die klassischen Abgrenzungen für den Bezug von Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS):

Die orange hinterlegten Bereiche stellen die Komponenten der Cloud-Umgebung dar, für deren Schutz typischerweise große CSPs wie AWS, Google Cloud Platform (GCP) oder Microsoft Azure die Verantwortung übernehmen, zum Beispiel die Server, den Speicher und die Netzwerkkomponenten – kurz: das Fundament der Cloud-Infrastruktur.

Blau sind die Aspekte der Security markiert, für die primär die Kunden verantwortlich sind, vor allem die in der Cloud gespeicherten Daten, etwa Kundenakten und andere personenbezogene Daten, sowie die Identitäten. Ganz egal, ob wir über IaaS, PaaS oder SaaS sprechen: Diese beiden Aspekte – die Daten und die Identitäten – fallen auf jeden Fall in die Verantwortung des Kunden. Auf den Punkt gebracht: Wenn Sie es in die Cloud hochgeladen haben, müssen Sie sich darum kümmern.

Korrekt implementiert, ist ein solches Shared Responsibility Model für IT-Teams eine wertvolle Hilfe, um die Rollen und Verantwortlichkeiten in der Cloud Security strategisch zu analysieren, geeignete Security-Systeme zu integrieren und Optimierungspotenziale zu identifizieren. Außerdem kommt dem SRM eine Schlüsselrolle zu, wenn es gilt, Workloads in der Cloud zu schützen und Sicherheitslücken proaktiv zu identifizieren und zu schließen.

Gängige Fallstricke bei der SRM-Umsetzung

Leider bleibt das SRM oft hinter diesem Potenzial zurück, weil die praktische Umsetzung nicht der Komplexität des Themas gerecht wird – vor allem bei der Abgrenzung in der Grauzone zwischen dem CSP und den Kunden. Die wichtigsten Herausforderungen im Überblick:

Das größte Problem beim SRM ist es, klare Grenzen zwischen den Verantwortungsbereichen zu ziehen. Denn sowohl die CSPs als auch die Kunden tun sich schwer, festzulegen, wo der Aufgabenbereich des einen aufhört und der des anderen beginnt. Gängige Fragestellungen in diesem Kontext sind zum Beispiel: »Wer schützt den Hypervisor in einer Bare-Metal-IaaS-Umgebung?« oder »Wer ist für die Runtime Security in Serverless PaaS zuständig, wenn der Kunde seine eigene Runtime-Umgebung mitbringt?«

Zusätzlich verschärft wird die Situation, weil es viele große SaaS-Plattformen ihren Kunden heute gestatten, über offene APIs eigene Anwendungen oder Third-Party-Code zu integrieren. Wenn das geschieht, muss der Kunde automatisch auch einen Teil der Verantwortung für die API Security übernehmen, was zu weiteren Abstimmungsproblemen führt – zumal, wenn das SRM nicht genug ins Detail geht, um präzise Grenzen ziehen zu können.

Wie Unternehmen ihr SRM optimieren können

Die harten, trennscharfen Grenzen, die das oben gezeigte SRM-Diagramm vorgaukelt, werden der Realität also nicht gerecht. Missverständnisse sind vor allem in drei Bereichen vorprogrammiert:

Konfiguration
Identitäten & Berechtigungen
Visibilität & Monitoring

Die folgende Grafik zeigt ein realitätsnäheres SRM, dass die Bereiche »Konfiguration«, »Identitäten & Berechtigungen« und »Visibilität & Monitoring« ausdrücklich berücksichtigt und als geteilte Verantwortungsbereiche einordnet. Im Folgenden werden wir jeden davon im Detail betrachten.

Quelle Tenable

Automatisierung der Cloud-Konfiguration

Der Bereich, in dem viele SRMs die meisten blinden Flecken aufweisen, ist die Cloud-Konfiguration. Der Großteil der Angriffe auf Cloud-Ressourcen lässt sich auf unsichere oder fehlerhafte Konfigurationseinstellungen auf Kundenseite zurückführen. Das ist kein Vorwurf: Durch die schiere Anzahl von Objekten, Berechtigungen und Konfigurationsoptionen hat die Komplexität der Multi-Cloud-Umgebungen längst so zugenommen, dass die Konfiguration manuell nicht zu managen ist.

Abhilfe verspricht vor allem die voranschreitende Automatisierung der CI/CD-Pipelines: Standardisierte IaC-Templates können den Schutz von IaaS- und PaaS-Umgebungen maßgeblich stärken. Allerdings gehen diese stets mit der Gefahr einher, dass auch unsichere Konfigurationen oder Fehler vielfach repliziert werden könnten – die Unternehmen müssen beim Einsatz dieser Tools also die notwendige Sorgfalt walten lassen.

Auch die Konfiguration der SaaS-Dienste stellt viele Unternehmen vor erhebliche Herausforderungen. Doch immerhin ist inzwischen eine Reihe von Best-Practice-Guides für die sichere Konfiguration von SaaS verfügbar – beispielsweise die CIS-Benchmarks des Center for Internet Security. Auf diesem Fundament hat sich ein breites Angebot von Lösungen für das Cloud Security Posture Management (CSPM) entwickelt, mit denen Unternehmen ihre Konfigurationen gegen die CIS-Benchmarks und andere Frameworks validieren können. Besonders spannend: Die CSPM-Tools werden nach dem »Shift-Left«-Prinzip kontinuierlich weiterentwickelt und setzen heute schon in der Frühphase der Entwicklungspipeline an. So lassen sich Risiken proaktiv identifizieren, bevor die Infrastruktur bereitgestellt wird, und durch den hohen Automatisierungsgrad können Konfigurationen sogar proaktiv in der Entwicklungspipeline bewertet werden.

Durchgängiges Management von Identitäten & Berechtigungen

Ein zweiter Teilbereich des SRM, in dem Risiken leicht übersehen werden, ist das Management der Identitäten & Berechtigungen. Die meisten typischen Herausforderungen sind aber zu meistern: Schließlich wurden die modernen Multi-Tenant-Lösungen der großen Cloud-Provider mit Augenmerk auf eine strikte Abgrenzung multipler Kunden entwickelt. Starke Identitäten können als robuster Perimeter dazu beitragen, Accounts zuverlässig zu isolieren und im Falle eines Angriffs eine strenge Trennung zu gewährleisten. Und auch eine feingranulare Autorisierung ist bei modernen IaaS-, PaaS- and SaaS-Angeboten in der Regel standardmäßig vorgesehen – typischerweise über rollenbasierte Zugriffssteuerung und delegierte Administration. Um das Schutzniveau weiter zu erhöhen, können Kunden ihre Anwender heute außerdem verpflichten, starke MFA zu nutzen. Bei den großen IaaS- und PaaS-Anbietern ist dies bereits standardmäßig verfügbar, bei SaaS-Angeboten lässt sich die MFA komfortabel über einen externen Identity-as-a-Service-Anbieter (IDaaS) realisieren.

Letzten Endes kommen die Unternehmen aber nicht umhin, Identitäten im Sinne eines ganzheitlichen Zero-Trust-Modells in den Mittelpunkt ihrer Cloud-Security zu rücken und kontinuierlich zu bewerten, wie vertrauenswürdig die angemeldeten Anwender sind. Nur so lässt sich die Gefahr von Insider-Angriffen und kompromittierten Zugangsdaten nachhaltig minimieren. Neben robuster Authentisierung und Autorisierung erfordert dies auch ein durchgängiges Monitoring der Aktivitäten, das über externe CSP-Services oder Third-Party-Lösungen für das Cloud Infrastructure Entitlement Management (CIEM) umgesetzt werden kann. Die entsprechenden Tools helfen auch dabei, das Least-Privilege-Prinzip durchzusetzen und Just-in-Time-Zugriffe (JIT) zu ermöglichen.

Lückenlose Visibilität & Monitoring in der Cloud

Der dritte Teilbereich von SRM, der besondere Beachtung verdient, ist das Thema Visibilität und Monitoring. Auch hier sind viele positive Entwicklungen zu beobachten: In der Regel ist es für Unternehmen in der Cloud heute leichter als On-Premises, den Überblick über ihre IT zu behalten. Voraussetzung ist, dass sie die detaillierten Auditing- und Log-Files, die sie von ihrem CSP erhalten, auch konsequent auswerten. Dies gilt umso mehr, da viele CSPs in den letzten Jahren in eigene Cloud-Security-Lösungen in den Bereichen Threat Detection und Threat Response investiert haben. Wer heute neue Cloud-Services ordert, profitiert also oft schon ab dem ersten Tag von umfangreichen Monitoring- und Logging-Funktionalitäten.

Es bleiben aber noch Herausforderungen: So fehlt es oft an einer strukturierten Datenauswertung, und die erfassten Daten bleiben ungenutzt auf den Systemen liegen. Oder, noch schlimmer: Die Telemetriedaten werden ohne Sichtung in ein SIEM hochgeladen, wo sie lediglich die Performance beinträchtigen und Kosten verursachen. Hinzu kommt, dass es ohne ein dediziertes SaaS Security Posture Management (SSPM) und einen Cloud Access Security Broker (CASB) an Transparenz über die Schnittstellen zwischen Clouds, Identities und Berechtigungen fehlt – und auch Cloud-native Container- und Kubernetes-Dienste, die gerne ohne Wissen der Security-Teams implementiert werden, sind ein Problem.

Letztlich ist jeder für die Security-Systeme unsichtbare Traffic ein gefährlicher Vektor für Cloud-Angriffe. Cyberkriminelle nutzen diese blinden Flecken schon heute aus, um Schwachstellen hybrider und Cloud-basierter Umgebungen zu finden, in Netzwerke einzudringen und sensible Daten zu kompromittieren.

CSPM: Vom umständlichen Monitoring-Tool zum Must-have

Die gute Nachricht ist, dass inzwischen viele Tools verfügbar sind, die Unternehmen helfen, ihre Cloud-Security-Maßnahmen über alle CSPs hinweg abzustimmen und zu automatisieren. Eine Schlüsselrolle kommt dabei dem Cloud Security Posture Management (CSPM) zu, das sich längst vom umständlichen Konfigurationsmonitoring zu einer echten Cloud-nativen Application Protection Platform (CNAPP) weiterentwickelt hat.

Die Zukunft ist agentenlos

Weil es sich als unpraktikabel erwiesen hat, jeden Asset in der Cloud über einen dedizierten Agent zu managen, setzen Unternehmen heute bevorzugt auf agentenlose Cloud-Security-Technologien, die sich über APIs implementieren lassen und die Einhaltung von Compliance-Vorgaben erleichtern. Mit Blick auf die abstrakten Workloads und die hochkomplexen Orchestrierungsplattformen steigt dabei die Nachfrage nach automatisierten Lösungen mit integriertem Kubernetes Security Posture Management (KSPM). Und auch automatisierte Identity-Management-Werkzeuge, die die Aktivitäten nach der Authentisierung überwachen und die durchgängige Umsetzung des Least-Privilege-Prinzips sicherstellen, stehen bei den Security-Teams hoch im Kurs.

Innovative, API-zentrierte Security-Lösungen und intelligente Datenanalysen haben die Reichweite der CSPM-Tools weit über die Infrastrukturebene hinaus vergrößert und die Voraussetzungen für Out-of-Band-Image-Scans und prädiktive Angriffssimulationen geschaffen. Die Technologieführer auf dem Markt integrieren dabei zunehmend Telemetriedaten aus dem External Attack Surface Management (EASM), um die Auswirkungen von Exploits zu untersuchen. So lässt sich sicherstellen, dass Risiken korrekt priorisiert und den richtigen Teams zur Bearbeitung übergeben werden.

Fazit

Das Shared Responsibility Model ist zurecht ein Eckpfeiler moderner Cloud-Security-Strategien – aber beileibe kein Selbstläufer. Das größte Problem ist die unscharfe Abgrenzung der Verantwortlichkeiten, und es ist von zentraler Bedeutung, dass die Unternehmen diese Herausforderung adressieren. Nur so können sie einen zuverlässigen Schutz ihrer Cloud-Ressourcen sicherstellen. Dafür sind in der Regel einige zusätzliche Schritte erforderlich, darunter eine sorgfältige Ausarbeitung der vertraglichen Vereinbarungen mit den CSPs, die präzise Grenzen für jeden Teilbereich definiert. Regelmäßige Audits, Security-Assessments und umfangreiche Trainings helfen sicherzustellen, dass alle Beteiligten ihre Zuständigkeiten kennen und ihrer Verantwortung jederzeit gerecht werden. Anschließend müssen die Security-Teams die richtigen Tools auswählen und implementieren, um sicherzustellen, dass ihre Systeme jederzeit korrekt konfiguriert und optimal geschützt sind.

157 Artikel zu „Shared Responsibility Cloud“

NEWS | CLOUD COMPUTING | IT-SECURITY | AUSGABE 5-6-2020 | SECURITY SPEZIAL 5-6-2020

Shared Responsibility erhöht die Sicherheit in der Public Cloud – Gemeinsame Verantwortung

19. Juni 2020

Schon längst nutzen große Unternehmen Cloud-Angebote, aber auch immer mehr kleine und mittelständische Betriebe treten in ihre Fußstapfen. Dabei herrschen bezüglich der Sicherheit nach wie vor Bedenken. Provider und Nutzer tragen gleichermaßen dafür die Verantwortung.