Cloud-Security: Grundlagen

Cloud-Security: Grundlagen

Man sollte sich beim Thema Cloud-Security genau überlegen, welche Ziele man genau verfolgt und wie man diese am besten umsetzen kann. © Adobe: kras99 / stock.adobe.com / 309005583
© Adobe: kras99

Sicherheit ist wichtig – aber Security ist an sich ein eher unbequemes Thema. Sicherheitsvorkehrungen bedeuten in der Regel zusätzlichen Aufwand beim Zugriff auf abgesicherte Bereiche. Das können im täglichen Leben zusätzliche Schlösser an Türen und Fenstern sein, die man beim Heimkommen aufschließen muss, plus zusätzliche Wohnungsschlüssel, die man mit sich herum trägt.

Die besten Schlösser nutzen aber nichts, wenn man die Balkontür versehentlich oder zum einfacheren Zugang offen stehen lässt, oder gar freundlich anklopfende Diebe auf einen Kaffee herein bittet. Wenn man Hauseigentümer ist, steht man hier selbst voll in der Verantwortung. Aber wie sieht es mit einer Mietwohnung aus? Wofür ist der Vermieter verantwortlich und wofür man selbst? Und wie schaut es im Urlaub aus, wenn man ein Hotelzimmer oder eine Ferienwohnung hat? Ähnliche Überlegungen zu Verantwortlichkeiten spielen eine Rolle wenn man sich mit dem Thema IT-Security On-Premises und in der Cloud befasst.

IT-Security allgemein

IT-Security versucht Daten und Systeme vor unerwünschtem Zugriff zu schützen, egal ob diese im eigenen Rechenzentrum lokalisiert sind oder nicht. Das beinhaltet sowohl gezielte Angriffe von Extern oder Intern, als auch unbeabsichtigte Aktionen durch eigene Mitarbeiter. Daten sollen vor Löschung, Änderung, Kopieren oder Lesen geschützt werden. Systeme sollen ungestört funktionieren und nicht als Hintertür für Angriffe genutzt werden können, und Services sollen unterbrechungsfrei und performant zur Verfügung stehen. IT-Security sichert den störungsfreien Betrieb und verhindert Systemausfälle und die dadurch entstehenden Kosten.

Zuallererst möchte man natürlich verhindern, dass überhaupt etwas passiert. Hierzu gehört aber auch ein Monitoring: es muss nachvollziehbar dokumentiert werden, dass wirklich nichts passiert ist. Wenn es aber eine Sicherheitslücke gab, möchte man so schnell wie möglich informiert werden, um Schadensbegrenzung zu betreiben. Hierzu muss auch nachvollziehbar sein, wer wann was genau gestohlen, kopiert, gelöscht oder verändert hat, auch, um eventuelle Schadensersatzansprüche geltend machen zu können.

Einen Überblick über die vielfältigen Themen, die in der IT-Security eine Rolle spielen, liefert Abb. 1. Je nach Branche können einzelne Bestandteile einer Sicherheitsstrategie durch Regularien genau definiert werden.

Abb. 1: Bestandteile einer IT Sicherheitsstrategie – deren Umfang  durch branchenspezifische  Regularien genau vorgegeben sein kann. © Dr. Nadine Schöne
Abb. 1: Bestandteile einer IT Sicherheitsstrategie – deren Umfang durch branchenspezifische Regularien genau vorgegeben sein kann. © Dr. Nadine Schöne

Selbst wenn z.B. Schadsoftware frühzeitig erkannt wird, d. h. bevor sie ihren geplanten Zweck erfüllt hat (Daten löschen, Hintertüren in Systemen öffnen etc.), führt dies unweigerlich zu Ausfällen, da die Schadsoftware erst entfernt werden muss, bevor alle Systeme wieder voll genutzt werden können.

Hierzu ein Beispiel: Am 8. Dezember 2019 führte ein Hackerangriff zu einem Ausfall von IT-Systemen an der Justus-Liebig-Universität Gießen: „Die Justus-Liebig-Universität Gießen (JLU) ist nach einem schwerwiegenden IT-Sicherheitsvorfall nach wie vor und bis auf weiteres offline. Internet, E-Mail-Systeme und interne Netzwerke sind nicht nutzbar. Wegen des Verdachts auf einen Cyber-Angriff hat die JLU am Montagnachmittag Strafanzeige erstattet.“ Einen Monat später war der IT-Betrieb noch nicht wieder voll hergestellt, obwohl sehr schnell reagiert und aus Sicherheitsgründen sofort alle Server heruntergefahren wurden [1,2].

Cloud-Services

Cloud-Services sind nicht gleich Hosting. Die allgemein anerkannte Definition ist die NIST-Definition of Cloud-Computing [3]: „Cloud-Computing ist ein Modell, das universellen, bequemen, bedarfsgerechten Netzwerkzugriff auf einen gemeinsam genutzten Pool konfigurierbarer Computing-Ressourcen (z. B. Netzwerke, Server, Speicher, Applikationen und Services) erlaubt, die schnell bereitgestellt und mit minimalem Aufwand oder Interaktion mit dem Service-Provider zur Verfügung gestellt werden.“

Generell werden hier die Cloud-Services in drei Kategorien eingeteilt:

  1. IaaS (Infrastructure-as-a-Service): Bereitstellung der Infrastruktur zur Installation und Nutzung von Software wie Betriebssystemen und Applikationen. Dies beinhaltet u. a. Speicher, Prozessoren und Netzwerke. Der Nutzer hat keinerlei Kontrolle über die zugrundeliegende Cloud-Infrastruktur, wohl aber über Betriebssysteme, Speicher, installierte Applikationen und eventuell über einzelne Netzwerkkomponenten wie Firewalls.
  2. PaaS (Platform-as-a-Service): Hier wird dem Nutzer die Möglichkeit geboten, selbst Applikationen zu installieren. Er hat jedoch keine Kontrolle über die zugrundeliegende Cloud-Infrastruktur inklusive Netzwerk, Server, Betriebssystem und Speicher, wohl aber über die Applikationen selbst sowie über bestimmte Umgebungseinstellungen.
  3. SaaS (Software-as-a-Service): Applikationen werden als Cloud-Services bereitgestellt. Der Nutzer hat keinerlei Zugriff auf die zugrundeliegende Infrastruktur und höchstens eingeschränkten Zugriff auf die nutzerspezifischen Konfigurationen der Applikationen.

Cloud-Services bieten einige Vorteile gegenüber eigenen On-Premises-Rechenzentren, wie Skalierbarkeit mit möglicher Pay-as-you-go-Abrechnung, Redundanz (auch für Hochverfügbarkeit), die Art der  Investitionsausgaben (Opex statt Capex), standardisierte Software, Zugang zu neuester Hardware wie GPUs, und die geringere Abhängigkeit von Fachleuten im eigenen Haus zur Wartung der Systeme. Die Absicherung der Rechenzentren durch den Cloud-Provider ist in der Regel sehr stringent, meist sogar rigoroser als man dies im eigenen On-Premises-Rechenzentrum durchsetzen würde. Deshalb sind heutzutage hybride Architekturen, die sowohl On-Premises-IT als auch Cloud-Services eines oder auch mehrerer Cloud-Provider beinhalten, weit verbreitet.

Je nachdem was für eine Art von Cloud-Service man betrachtet, liegen unterschiedliche Handlungsmöglichkeiten und Verantwortlichkeiten beim Nutzer oder beim Cloud-Provider. Beim Speichern personenbezogener Daten in einem Cloud-Service gibt es z. B. folgende grundlegende Unterschiede zwischen unterschiedlichen Typen von Cloud-Services:

  1. IaaS: Der Nutzer installiert alle Applikationen selbst. Der Cloud-Provider kann also nicht wissen, ob es sich bei den im Cloud-Service gespeicherten und verarbeiteten Daten um personenbezogene Daten handelt. Handlungsmöglichkeiten und die Verantwortung, Daten konform zur Datenschutz-Grundverordnung (DSGVO) zu verarbeiten, liegen komplett beim Nutzer [4].
  2. SaaS: Wenn die bereitgestellte Software explizit mit personenbezogenen Daten arbeitet, dann sollten im Service entsprechende Sicherheits-Funktionalitäten enthalten sein (z. B. Verschlüsselung, feingranulare Zugriffskontrollen etc.).
IT-Tage - Cloud

Risikominimierung auch in Cloud-Umgebungen

Wie geht man jetzt aber damit um, dass die Verantwortung (Haftbarkeit) bei einem selbst liegt, man aber beim Nutzen von Cloud-Services einen Teil der Handlungsmöglichkeiten an den Cloud-Provider abgibt? Wir werden uns im Folgenden an zwei Whitepapern orientieren [4,5]. Sie beschreiben detailliert  u. a. die Schritte, die bei der Evaluation und dem Management der Sicherheit von Cloud-Umgebungen unterstützen, um Risiken zu minimieren und angemessenen Support zu sichern.

Prozesse für Governance, Risikobewertung und Compliance

Die Details der Verarbeitung von Daten werden in einem rechtlich bindenden Data Processing Agreement (DPA) festgelegt. Hierzu gehören die Art und Dauer sowie der Grund der Verarbeitung, die Art der (persönlichen) Daten, sowie Rechte und Pflichten des Cloud-Providers und des Kunden. DPAs sind in der Regel ein essentieller Bestandteil der Compliance mit Regularien, wie z. B.

  1. Datenschutzgrundverordnung [6],
  2. Health Insurance Portability and Accountability Act (HIPAA),
  3. Family Educational Rights and Privacy Act (FERPA) und
  4. Payment Card Industry Data Security Standard (PCI DSS).

Zertifizierungen und Standards sind weitere Faktoren beim Thema Cloud-Security. Zu beachten ist, dass Zertifizierungen meist nur für Services, nicht aber für den Provider selbst vergeben werden. Sie stellen das Ergebnis einer Auditierung zu einem bestimmten Zeitpunkt dar. Wichtige Standards sind die  ISO/IEC 27000-Serie (insbesondere 27017 und 27018), ISO/IEC 19086, ISO/IEC 27036-4  und  ISO/IEC 2000. Diese betreffen unterschiedliche Aspekte von Cloud-Security, wie z. B. den Schutz persönlicher Daten und Risikomanagement.

Auditierung

Welche Auflagen für Auditierung hat man selbst, und kann der Cloud-Anbieter diese Auflagen auch erfüllen? Reicht z. B. eine Selbst-Auditierung des Cloud-Providers oder ist eine Auditierung durch Drittanbieter gewünscht? Die Details  sollten im Cloud-Service-Agreement festgehalten werden.

Hilfreich sind auch sogenannte Cloud Access Security Broker (CASB), die alle Aktivität  zwischen Nutzern und Cloud-Services überwachen und Security Policies durchsetzen. Diese sind jedoch bisher nicht standardisiert, d. h. man muss auf jeden Fall untersuchen, ob die gebotenen Möglichkeiten für den jeweiligen Anwendungsfall ausreichend sind.

Management von Nutzern, Rollen und Identitäten

Management von Nutzern, Rollen und Identitäten muss sowohl von Seiten des Cloud-Providers für seine Kunden als auch von Seiten des Kunden für seine Mitarbeiter betrachtet werden. Der Zugriff auf Daten und Anwendungen der Cloud-Nutzer muss von Seiten des Cloud-Providers genau geregelt sein, und zwar individuell für jeden Service. Multi-Factor-Authorization für den Zugriff auf Cloud-Services ist inzwischen Standard und sollte wenn möglich genutzt werden. Darüber hinaus muss jeder Zugriff genau überwacht und geloggt werden. Der Kunde muss die Möglichkeit haben, für jeden genutzten Cloud-Service Rollen und Zugriffsrechte feingranular und seinen Security Policies folgend zu vergeben.

Datenschutz

Hybride und Multi-Cloud-Architekturen stellen besondere Herausforderungen an den Datenschutz. Eine Verschlüsselung (Encryption) der Daten ist sowohl für Data-at-Rest als auch für Data-in-Motion wichtig. Die Encryption Keys sollten sicher durch den Kunden verwahrt werden. Damit wird das Risiko für Datenverlust, Änderung der Daten incl. Löschen und unautorisierten Zugriff minimiert.

Der Schutz personenbezogener Daten ist insbesondere mit der Datenschutzgrundverordnung, aber auch durch andere Regularien, ein zentrales Thema geworden. Auch beim Nutzen von Cloud-Services sind hier insbesondere Zugriffskontrollen und die Maskierung der Daten ein Thema. Je nachdem, welche Kategorie von Cloud-Service man nutzt (IaaS, PaaS, SaaS), kann oder muss der Cloud-Provider entsprechende Tools zur Verfügung stellen. Die Verantwortung des Schutzes personenbezogener Daten liegt am Ende aber beim Nutzer des Cloud-Services.

Netzwerke und Netzwerkanbindungen

Nicht nur der Cloud-Service selbst, sondern auch Netzwerke und Netzwerkanbindungen müssen abgesichert werden. Der gewünschte Datenverkehr soll ungehindert fließen, bösartiger Datenverkehr (Malicious Traffic) muss hingegen blockiert werden. In vielen Fällen ist es für den Cloud-Anbieter aber nicht möglich, zwischen erwünschtem und unerwünschtem Datenverkehr seiner Kunden zu unterscheiden. Neben der grundlegenden Absicherung des Network Perimeters durch den Cloud-Provider (z. B. gegen Denial-of-Service-Attacken oder Traffic zu Malware Ports), ist es deshalb wichtig, dass dem Cloud-Nutzer Tools zum Schutz der eigenen Umgebung zur Verfügung gestellt werden. Hierzu gehören zur Network-Security neben einer zeitnahen Benachrichtigung im Falle eines erfolgreichen Angriffs auch die Möglichkeiten des Monitorings und die Einsicht in Logfiles. Von Vorteil sind auch Statistiken zur Anzahl erfolgreich erkannter und abgewehrter Angriffe.

Cloud Service Agreement (CSA)

Im Cloud Service Agreement (CSA) wird festgehalten, wofür der Nutzer und wofür der Cloud-Provider verantwortlich ist. Hierzu gehören Zertifizierungen, implementierte Standards, Regeln zum Reporting von Vorfällen, Recovery nach Ausfällen und Metriken. Die Service Level Agreements (SLAs) sind Teil des CSAs. Sie setzen klare Erwartungen zwischen dem Nutzer und dem Cloud-Provider zu Frequenz und Art erwarteter Ausfällen oder schlechter Performanz der Services.

Exit-Prozess: „das Recht vergessen zu werden“

Was passiert, wenn man irgendwann den Cloud-Provider wechseln oder die abgebildete Funktionalität ins eigene Rechenzentrum verlagern möchte? Der Exit-Prozess sollte schon vor Abschluss eines Vertrages definiert werden. Hierzu gehört das garantierte Löschen von Backups, Logs etc. erst nach einer bestimmten Zeit nach einer Migration, und auch das Recht auf das vollständige Löschen der Daten (the right to be forgotten). Neben den Kosten für das Hochladen von Daten (Inbound Traffic) in den Cloud-Service sollte man auch die Kosten des Rücktransfers der Daten (Outbound Traffic) betrachten, diese können je nach Cloud-Provider unterschiedlich hoch sein.

Unterschiede zwischen Cloud-Providern

Eine pauschale Aussage, welcher Cloud-Anbieter jetzt „besser“ oder „sicherer“ ist als der andere, lässt sich nicht treffen, und Details der Angebote können sich auch von einem auf den anderen Tag ändern.

Bei der Auswahl eines Cloud-Anbieters sollte man aber besonders auf folgende Punkte achten:

  1. Welche Sicherheitsaspekte sind „eingebaut“, d. h. standardmäßig Bestandteil des jeweiligen Cloud-Services, und was ist als extra Service (evtl. mit zusätzlichen Kosten) verfügbar? Gibt es Sicherheitsaspekte, die gar nicht abgedeckt werden (können)?
  2. Je nach Cloud-Provider sind standardmäßig unterschiedliche Ports und Protokolle geöffnet und erlaubt. Es kann sein, dass nach Provisionierung eines Cloud-Services alle Ports zu sind, und man öffnet selbst diejenigen, die man braucht. Aber auch der gegensätzliche Fall ist möglich, und stellt ein Sicherheitsrisiko dar, das man selbst beheben kann und muss.
  3. Wie schnell sind neue Einträge in den Activity Logs sichtbar (handelt es sich um Sekunden, Minuten, oder gar Stunden?), und wo und wie hat man Zugriff auf die Logs?

Konkrete Schritte

Wo fängt man nun an, wenn man sich für einen Cloud-Service oder Cloud-Provider entscheiden will? Welche Überlegungen sind wichtig?

  1. Was braucht man genau? Wie genau sieht der technische Bedarf aus, d. h. was muss der Cloud-Service an Funktionalität liefern? Welchen Policies und Regularien muss man (und damit auch der Cloud-Service) genügen? Welche Abrechnungsmodalitäten wären optimal? Und welche Integration mit den bereits vorhandenen Systemen muss gewährleistet werden?
  2. Wer ist wofür verantwortlich? Verantwortlichkeiten werden im Cloud Service Agreement (CSA) sowie in Service Level Agreements (SLAs) festgelegt. Hier sollte man auch auf eventuelle Lücken achten – gibt es Aspekte, die in den Agreements nicht definiert sind, die aber vom Nutzer aus technischen Gründen nicht abgedeckt werden können?
  3. Welche Sicherheitsstandards werden eingehalten/sind implementiert? Sicherheitsstandards garantieren, dass Best Practices befolgt werden – sowohl intern als auch beim Cloud-Provider. Damit wird sowohl eine Integration mit bereits bestehender Infrastruktur gewährleistet, als auch ein Vendor-lock-in vermieden, d. h. Flexibilität erhalten. Zudem erleichtern Sicherheitsstandards die Einhaltung von Regularien und Policies.
  4. Welche Experten kann und sollte man in den Entscheidungsprozess involvieren? Neben der eigenen IT-Abteilung, dem Chief Security Officer (CSO) und der Rechtsabteilung ist oft auch die Einbindung anderer Abteilungen und Personas, wie z. B. der Finanzabteilung, sinnvoll.
  5. Wenn noch Fragen offen sind, sollten diese auf jeden Fall vor Abschluss eines Vertrages geklärt werden!

Quelle: https://www.informatik-aktuell.de

Share..

Schreibe einen Kommentar