Mythos Cloud Security

20.02.2022
Klaus Haller

Das Geschäft läuft super für die großen Cloud-Provider – und für Cyberkriminelle, die Fehlkonfigurationen im industriellen Massstab gnadenlos monetarisieren. Wie können IT-Organisationen ihre Cloud-Umgebungen schützen? Was sind die Erfolgsfaktoren und  Stolpersteine? Dieser Artikel liefert Antworten. Er basiert auf Erfahrungen in der Absicherung von Applikationslandschaften und Artificial Intelligence (AI)-Umgebungen in der Azure Cloud und der Google Cloud Plattform.

HERAUSFORDERUNG CLOUD SECURITY

Bevor ein Cloud-Projekt überhaupt startet, gibt es  ein  erstes  großes  Security-Risiko:  Manager ohne Erfahrung mit komplexem  Outsourcing und ohne Verständnis für das Zusammenarbeitsmodell in der Cloud. Wenn bei einer Migration in die Cloud der Umfang der Security-Aufgaben falsch eingeschätzt und unzutreffend in Budget und Projekteplan aufgenommen werden, kommt das Projekt früher oder später in Schieflage In der eher traditionellen Welt der IT-Service-Provider bestellen Kunden eine Virtual Machine (VM). Sie bekommen ein Rundum-Sorglospaket. Ein  Solution-Architekt  überlegt, in welcher Zone sie platziert wird, welche Firewall Ports geöffnet werden und wie die Active-Directoy-Integration gelingt. In der Cloud gibt es kein Rundum-Sorglospaket Es gilt das Prinzip Ryanair. Wer eine VM bestellt, bekommt eine VM, sonst nichts. Viel günstiger als früher, aber ohne Sorglospaket.

Die Cloud-Anbieter übernehmen die Verantwortung für die Sicherheit der Cloud-Services. Sie investieren hohe Summen dafür. Doch der Kunde baut solche Services mit eigenen Komponenten und eingekauften Softwarekomponenten zu Lösungen und Applikationslandschaften zusammen. Seine Lösungen und seine Applikationslandschaft muss jeder Kunde selbst absichern. Der Cloudanbieter sichert die Cloud, der Kunde, was auf der Cloud läuft. Das ist die neue Aufgabenverteilung. Dafür benötigen die Kunden Cloud-(Security-)Engineering und Architekturkompetenz, was oft im Projekt aufgebaut werden muss.

CLOUD SECURITY ALS (KONZEPTIONELLE) FLEIßARBEIT

Wer in die Cloud geht, baut ein vollständiges Data Center mit neuem Technologie-Stack auf. Natürlich übernehmen die  Cloud-Provider  viele Aufgaben wie physische Server aufstellen oder Strom- und Netzwerkleitungen Dank «Infrastructure as Code» werden Netzwerke, Firewalls, VMs und alle anderen Komponenten in Konfigurationsfiles spezifiziert und von der Cloud automatisiert bereitgestellt. Was aber bereitgestellt wird und wie Komponenten und Services konfiguriert sind, das konzipieren die Kunden eigenverantwortlich.

Das Azure Defense-in-Depth-Modell mit seinen sieben Schichten (Abb. 1) gibt Projekt- und Programmleitern einen ersten Überblick über die Aufgabenvielfalt. Die Schichten sind:

  • Physische Sicherheit, beispielsweise wer die Azure Rechenzentren betreten kann. Das ist die einzige Schicht, die die Cloudanbieter alleine verantworten.
  • Identity & Access Management, insbesondere also Authentisierung und Autorisierung
  • Perimeterschutz mit Themen wie Firewalls zum Internet oder Schutz gegen Denial-of-Service- Attacken
  • Netzwerkschutz wie beispielsweise die interne Netzwerk-Zonierung
  • Schutz der Compute-Services wie VMs oder Constainern
  • Schutz der Applikationen
  • Schutz der Daten beispielsweise in Datenbanken, Storage-Services oder Files

Das Schöne ist, dass alle Cloud-Anbieter umfangreiche Tools und Security-Checklisten bereitstellen. Manager (und Architekten) sollten allerdings die Themenbreite und die damit verbundene Arbeitsmenge nicht unterschätzen.

Die Cloud mag für Startups mit einer wichtigen Applikation ein Kinderspiel sein. Größere Unternehmen mit bestehenden Applikationslandschaften sind eine andere Liga, denn sie benötigen von Anfang an den ganzen Cloud-Security-Stack, wie er in der On-Premise-Welt üblich ist.

Abbildung 1: Die sieben Schichten des Azure Defense-in-Depth-Modells

CLOUD-RISIKEN UND HANDLUNGSFELDER

Innovationskraft, On-Premise-Exzellenz und die Unmittelbarkeit von Konfigurationsänderungen auf die Security sind die drei Top-Risiken und Handlungsfelder für Cloud-Security (Abb. 2).

Security-Sicht ist die Innovationskraft eine Herausforderung, da eben Webservices und ihre Daten potenziell gegenüber dem Internet exponiert und deswegen gehärtet sein sollten. Es ist ein Sicherheitsrisiko, wenn jeder Entwickler jeden Service, auch die ungehärteten, nutzen kann. Die Google Cloud ermöglicht, zentral Services freizuschalten oder zu blockieren. Bei anderen Cloud-Anbietern fehlen solche Features teilweise, was für Cloud-Projekte und den sicheren Cloud-Betrieb eine echte Herausforderung sein kann.

On-Premise-Exzellenz beim   Security-Tooling wird bei der Migration in die Cloud zu einem Stolperstein. Viele CIOs und CISOs sind stolz auf die Erfolge in der On-Premise-Welt. Ihre Organisationen haben über Jahrzehnte Tools, Prozesse und Frameworks weiterentwickelt und perfekt aufeinander abgestimmt. Das bedeutet: hoher Sicherheitslevel und hohe Effizienz. Doch die Cloud erfordert ein Neudenken und eine Generalüberholung.

Abbildung 2: Cloud Security – Die Übersicht

Unmittelbarkeit meint, dass in  der  Cloud  alles schneller, einfacher und unbürokratischer geht, auch katastrophale Fehlkonfigurationen. Wenn ein Engineer einen Storage Service mit allen Scans von Kundendokumenten weltweit freischalten will – eins, zwei Klicks reichen. Einfach, unkompliziert und ohne Umweg geht es blitzschnell in die Katastrophe. Das ist neu. In der On-Premise-Welt müssen aufgrund komplexerer Abläufe oft zwei oder mehr Teams einen Fehler begehen, beispielsweise ein Datenbanken- oder Archivierungsteam und das Netzwerk und Firewall-Team. Auch in der Cloud sind vergleichbare Sicherheitsmechanismen möglich. Diese müssen der Cloud-Lead, der  CISO  oder CIO aber explizit planen, fordern und selbst implementieren und finanzieren.

Die Cloud-Provider sind Innovationsmaschinen, die immer neue Services bringen. Nicht nur bei Artificial Intelligence, Machine Learning oder Chatbots übertreffen sich die Anbieter mit Innovationen. Die Cloud ist in ihrer Paraderolle als Enabler für Business-Innovationen, der immer neue Services hervorbringt,  nach  denen das Business und die Engineers schreiben. Aus

Mit der Cloud ändern sich die Applikationsarchitekturen und damit die Security-Bedürfnisse. Lizenzprobleme können eine Mitnahme der Tools in die Cloud erschweren und natürlich sind technische Anpassungen und eine neue Integration notwendig. Der Umzug und die Anpassung an die Cloud brauchen Zeit. Ein einziger verzögerter Service, beispielsweise ein fehlender DDoS-Schutz, kann die Migration in die Cloud blockieren. Das ist fatal und unnötig. Schliesslich bieten die Cloud-Anbieter für viele Herausforderungen Cloud-Native-Services an. Sie sind kinderleicht zu aktivieren, wenn auch nicht optimal in die unternehmensspezifische Tooling-Infrastruktur eingebunden. Sie bieten oft auch weniger Konfigurationsmöglichkeiten als Software spezialisierter Anbieter, die die On-Premise-Welt heute dominieren. Doch diese Cloud-Native-Services eröffnen neue Alternativen zu einem «go live» ohne Schutz oder einer  Projektverzögerung. Hier sind Projektleitung und (Security-)Architektur gefordert, notwendige Entscheidungen systematisch herbeizuführen – für die Einführungsphase und für die mittelfristige Ziellösung.

SECURITY HERAUSFORDERUNGEN IM MULTI-CLOUD-UMFELD

Größere etablierte Unternehmen haben meist eine Multi-Cloud-Strategie. Sie wollen nicht zu stark von einem Cloud-Anbieter abhängig sein oder dürfen das aus regulatorischen Gründen nicht. Außerdem haben die diversen Cloudanbieter unterschiedliche Stärken. Aus Security-Sicht sind die drei Herausforderungen im Multi-Cloud-Umfeld die technische Heterogenität, die Authentisierung und das Reporting.

„Same same but different“, diese bekannte Formulierung umschreibt die Herausforderung der technischen Heterogenität. Irgendwie sind alle Clouds ähnlich, doch gerade bei der  Security gibt es Unterschiede im Detail. Mal kann man Services abschalten, mal Komponenten gegenüber dem Internet sperren, mal kann man unsichere Situationen nur erkennen, aber nicht aktiv blockieren. Daher müssen Architekten und Engineers die gleichen Security-Risiken in verschiedenen Clouds mit unterschiedlichen Ansätzen adressieren. An einem detaillierten technischen Verständnis jeder Cloud und ihrer Security- Features führt kein Weg vorbei.

IT-Abteilungen haben in den letzten Jahren viel Geld investiert, um ihr Identity and Access Management (IAM) zu modernisieren. Warum also sollte das Thema Authentisierung eine Herausforderung sein? Im Multi-Cloud-Umfeld sind nicht persönliche User im  Fokus,  mit  denen sich Mitarbeitende am Laptop und Kunden an Online-Portalen anmelden. Multi-Faktor-Authentisierung, also beispielsweise eine Kombination von Username/Passwort und einem Token auf einer Mobile App, sind weiterhin sicher. Das Risiko liegt bei den Service-Accounts, mit denen Applikationen beispielsweise auf Datenbanken zugreifen. In der On-Premise-Welt sind Zertifikate ein beliebter  Schutzmechanismus, um sicherzustellen, dass Administratoren, andere Applikationen oder Angreifer einen technischen Zugang nicht einfach kapern und nutzen können. Innerhalb eines Öko-Systems in der Cloud – beispielsweise als Plattform-as-a-wie Messaging, Storage und AI-Services  interagieren – ist der Schutzlevel vergleichbar oder höher. Doch die Situation ist bei Applikationen anders, die auf VMs oder in Containern laufen und auf Plattformservices wie Cloud-Storage-Services zugreifen. Besonders kritisch sind Cloud- übergreifende Service-Aufrufe. Hier gibt es eine Tendenz  User/Passwort-Kombinationen  beziehungsweise Zugriffschlüssel zu akzeptieren. Bei Verlust eines Schüssels beziehungsweise Passworts hat die ganze Welt Zugriff, insbesondere wenn die Inter-Cloud-Kommunikation über das offene Internet und nicht über spezielle Cloud- to-Cloud-Netzwerkverbindungen   läuft. Solche Pattern würden schon seit Jahren in der On-Premise-Welt kein einziges Audit mehr überstehen, in der Cloud erleben sie eine Wiedergeburt.

Reporting als Sicherheitsrisiko, das klingt zunächst einmal überraschend. Doch in der Einführungsphase von Clouds kann aber ein unpassender Umgang mit Reports dazu führen, dass relevante Sicherheitsrisiken nicht wahrgenommen werden. Die gute Nachricht ist zunächst, dass alle Cloud-Anbieter Security-Center anbieten. Diese weisen ohne jeden Aufwand und ohne Integration auf Fehlkonfigurationen und Vulnerabilitäten hin und sind in der Basisversion kostenlos. Einfacher geht es nicht. Die Herausforderung ist dann, die vielen Warnungen in allen Clouds durchzuarbeiten und die kritischsten Punkte zu beheben. Dieser Bottom-Up-Ansatz hilft, die wichtigsten Sicherheitsanforderungen nach und nachzulösen.

Cloud-individuelles Security-Reporting ist allerdings nicht managementgerecht. Ein CIO oder CISO braucht eine Gesamtübersicht. Wie sicher ist unsere IT-Infrastruktur und wird es von Monat zu Monat besser  oder  schlechter?  Sollen wir mehr in das Projekt für Azure-Security, für AWS oder für GCP investieren? Das  Management braucht eine Gesamtsicht und eine Gesamtsicht erfordert eine Angleichung der Warnungen der diversen Clouds und  ein  Mapping auf zentrale Klassen an Warnungen. Dadurch gehen Details und die Spezialitäten der diversen Clouds verloren. Können wir Services blockieren oder nur Fehlverhalten auflisten und müssen das anschließend über Security-Pro- zesse mit den Applikationen beheben? Zentra- le Klassen an Warnungen dürfen daher nicht zur Steuerung eingesetzt werden, welche Warnungen in welcher Cloud zuerst behoben werden. Sonst besteht das Risiko, dass nur Warnungen angegangen werden, für die zentrale Klassen existieren – ganz abgesehen davon, dass verschiedene Konstellationen in verschiedenen Clouds unterschiedlich kritisch sind, weil sich beispielsweise Cloud-Nutzung und  gespeicherte Daten stark unterscheiden.

IHRE CLOUD-UMGEBUNG IST SICHER! SICHER?

Viel zu oft laufen bei IT-Projekten die ursprünglichen Visionen und Konzepte und die implementierte Realität auseinander. Das hat bei der IT-Sicherheit von Cloud-Umgebungen schnell unangenehme Folgen. Qualitätssicherungsmassnahmen beziehungsweise Security-Assurance-Konzepte helfen, solche Lücken frühzeitig zu erkennen. Sie basieren auf drei Säulen (Abb. 3):

  • Feature-Implementation  verifizieren
  • Security-Center-Warnungen abarbeiten
  • Prozessreife sicherstellen

 

 

 

 

Abbildung 3: Qualitätssicherung für das Security-Engineering bei Cloud-Einführungen

 

Security-Konfigurationen verifizieren, dies ähnelt dem klassischen Software-Testen. Tester überprüfen, ob die spezifizierte Funktionalität vollständig und korrekt umgesetzt wurde. Allerdings: Beim Überprüfen der Cloud-Konfiguration setzen Projekte eher nicht auf Tester. Cloud- Engineers können viele QA-Aufgaben selbst übernehmen, da viele Security-Anforderungen einfache Konfigurationen erfordern, keine tausenden Zeilen an Code. Vieles ist Fleißarbeit, die die Cloud-Engineers erledigen und  abhaken. Bei der Qualitätssicherung geht es also darum – je nach Kritikalität der Features – ob und welche weiteren Maßnahmen notwendig  sind, um Fehler und Missverständnisse zu  vermeiden. Zusätzlich möglich wäre beispielsweise, Evidenzen für die Umsetzung wie zum Beispiel Bildschirmfotos oder sogar formale, durchspezifizierte Tests und Testfälle zu fordern.

Die Security Centers der Cloud-Anbieter sind Dashboards, die konkrete Vorfälle und Vulnerabilitäten oder potenzielle Probleme zusammenstellen. In der Projektphase enthalten sie viele Warnungen auch solche, die für ein konkretes Umfeld unzutreffend sind. Schleppen Teams hunderte von falschen Warnungen mit sich herum, erkennen sie die wirklich kritischen Meldungen nicht. Außerdem sind diese automatisierten Checks wie ein technischer Audit, der mögliche Lücken im Sicherheitskonzept erkennt. Daher ist ein sauberer Zustand so zentral vor einem Go-Live. Das Projektteam muss die Warnungen durch- und abarbeiten – vor oder kurz nach der Migration realer Daten und produktiv genutzter Applikationen.

Eine Überprüfung der Prozessreife ist der finale Baustein und bringt einen nicht-technischen Aspekt ein. In der Cloud verschieben sich Aufgaben zwischen Teams, viele fallen weg und neue kommen hinzu. IT-Organisationen sollten validieren, ob alle Prozesse nach dem Move-to-the- Cloud wie gewünscht funktionieren.

Cloud-Technologien und Cloud-Anbieter sorgen für eine fundamentale Transformation von IT-Organisationen und Data Centern. Das Thema Security ist eine echte Herausforderung, die viel kreatives Engineering erfordert. Wer weiß, vielleicht wäre das ja die perfekte nächste Aufgabe für Sie? ■

 

https://de.statista.com/statistik/daten/studie/1230157/umfrage/unternehmen-die-in-denletzten-12-monaten-einecyber-attacke-erlebt-haben/

Rund 46% der befragten Unternehmen in Deutschland wurden 2021 mindestens ein Mal Opfer einer Cyber-Attacke.

0 Kommentare

Einen Kommentar abschicken

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.