zurück zum Artikel

Egal ob wild gewachsene oder geplant eingeführte Cloud-Projekte – es gibt viele Dinge, die sich da noch verbessern ließen, gerade was die Security angeht.

Die Autoren dieser Serie zu "Cloud für Unternehmen" begleiten und analysieren seit vielen Jahren Cloud-Projekte. Die vorherigen Teile befassten sich vor allem mit der Vorbereitung und Einführung der Cloud-Nutzung im Unternehmen. Im abschließenden Teil geht es darum, was man bei bereits im produktiven Betrieb befindlichen Projekten alles verbessern kann und sollte.

In vielen Unternehmen, die nicht schon sehr früh eine klare Policy für die Nutzung von Cloud-Diensten formuliert haben, dürfte es inzwischen einen beträchtlichen Wildwuchs geben. Das beginnt bei einzelnen Mitarbeitern, die private Google-Kalender nutzen und hört bei ganzen Abteilungen, die Dienste wie Dropbox zum Datenaustausch nutzen noch lange nicht auf. Da gibt es den Entwickler, der Alibaba nutzt oder die Fachabteilung, die eine schwer zu beschaffende Spezialanwendung kurzerhand durch einen "Webdienst" ersetzt.

Hier muss die IT zunächst eine Bestandsaufnahme machen, um sich einen Überblick über die aktuelle Cloud-Nutzung und insbesondere auch deren Sicherheitsstand zu verschaffen. Dazu lässt man sich am besten von den Mitarbeitern die aktuellen Nutzungsszenarien erklären und vorführen.

Dabei ist dann umgehend zu klären, wie aktuell die jeweils eingesetzte Software ist, um eventuell akute Sicherheitsprobleme sofort adressieren zu können. Im nächsten Schritt sollte man den Schutzbedarf der involvierten Daten bewerten. Auf dieser Basis kann dann eine Sicherheitsbewertung stattfinden. Besonders kritische Betrachtung verdienen dabei Anwendungen, die eigentlich für den lokalen Betrieb vorgesehen waren, aber jetzt innerhalb einer virtuellen Umgebung oder in Containern in der Cloud laufen.

Ersatz finden

Ein Cloud Access Security Broker (CASB) kann dabei helfen, eventuell vorhandene Schatten-IT zu erkennen und Richtlinien für die Cloud-Nutzung durchzusetzen. Wichtig ist jedoch, dass es nicht damit getan ist, eine bei der Bestandsaufnahme entdeckte, ungenehmigte Cloud-Nutzung zu verbieten. Denn dieser Einsatz der Cloud geschah ja nicht aus bösem Willen sondern weil die betreffenden Mitarbeiter eine Aufgabe zu erledigen hatten. Man sollte also in Zusammenarbeit mit diesen Mitarbeitern klären, worin diese Aufgabe besteht und welche Anforderungen es an eine Lösung gibt.

Mit den so gewonnenen Informationen kann man dann zusammen mit den Mitarbeitern passende Lösungen für diese Aufgaben erarbeiten. Das kann unter Umständen darin bestehen, dass man die bisher kostenlose Nutzung eines Dienstes auf ein kostenpflichtiges Modell umstellt, bei dem dann aber etwa Datenschutzanforderungen im Rahmen eines Vertrags über Auftragsdatenverarbeitung geregelt sind. In anderen Fällen kann man vielleicht die wilde Dropbox-Nutzung auf ein selbst gehostetes System mit ownCloud oder Nextcloud umstellen.

Bei den noch ungeregelt eingeführten Cloud-Diensten sollte man anstreben, die im vorherigen Artikel beschriebenen Konzepte und Prinzipien so weit als irgend möglich nachzuziehen. Das beginnt mit einer sinnvollen Namenskonvention und den Kennzeichnungen (Tagging!), um die zukünftige Administration zu erleichtern. Es geht weiter mit den Anforderungen an den Schutz vor Identitätsdiebstahl – also etwa die Einführung von Multifaktor-Authentifizierung mit TOTP-Apps und Hardware-Tokens wie Smartcards für administrative Zugänge. Auch die beschriebenen Rollen- und Berechtigungskonzepte und die Prinzipien des Least Privilege und Need-to-Know sollte man so weit wie möglich auch nachträglich umsetzen.

Und schließlich muss man Cloud-Provider-spezifische Aspekte prüfen. So sollte man beispielsweise in Office 365 darauf achten, dass die Anwender nur zuvor freigegebene Apps installieren dürfen, damit der Erfolg eines OAuth-Angriffs unwahrscheinlicher wird.

Die Frage, die sich jeder bei der Bestandsaufnahme stellen wird, ist natürlich, ob die vorhandenen Sicherheitsmechanismen ausreichend sind. Meistens kann man dies nicht sofort und ohne weiteres beurteilen. Aber alles, was bereits vorhanden ist, kann man schon mal notieren, um es in eine entsprechende Auswertung einfließen zu lassen, etwa in Form eines Reifegradmodells. So kann man dann das Sicherheitsniveau auf der Basis bereits vorhandener Sicherheitsmechanismen schrittweise erhöhen.

Die nächsten Schritte

Apropos Erhöhen des Sicherheits-Niveaus: Auch nach einer systematischen Einführung eines Cloud-Projekts sollte man sich in Bezug auf Security nicht auf dem Erreichten Ausruhen. Es gibt reihenweise Verbesserungen, die sich wirklich lohnen, weil sie die Sicherheit nicht nur graduell anheben, sondern auf ein neues Niveau bringen.

So ist es überaus sinnvoll, den Zugang zu SSH, RDP und Admin-Zugängen der Cloud-Dienste zu beschränken, damit nicht Hinz und Kunz aus dem Internet darauf zugreifen können. Dazu bieten sich sogenannte Jump Hosts beziehungsweise Bastion Hosts an. Das sind speziell gehärtete und überwachte Systeme, die als Zwischenstation für die Zugriffe dienen. Man gestattet dann den Zugriff auf die geschützten Dienste nur von diesen Bastion Hosts aus. Das kann man selber bauen; es gibt dafür aber auch Dienste wie Azure Bastion.

Viel Optimierungspotential bieten auch die im Betrieb erzeugten Protokollierungsdaten. Die werden in der Cloud nicht auf ewig gespeichert. Befassen sie sich also damit, welche Logdaten sie wie lange vorhalten möchten oder müssen und wie Sie das realisieren. Vielleicht möchten Sie ja eine Teil davon in ein On-Premis-SIEM überführen oder Einweg-synchronisieren, um sie auch im Falle des Verlusts der Verbindung zur Cloud noch im Zugriff zu haben.

Die von Cloud-Diensten erzeugten Alarme sollte man auf jeden Fall selbst konfigurieren. Denn der Cloud-Provider kann ihre Anforderungen und Verarbeitungsmöglichkeiten nicht kennen. Am besten machen Sie das in enger Zusammenarbeit mit den jeweiligen Fachbereichen. Denn die können dabei viel Knowhow über normale Abläufe und Alarmierungs-würdige Abweichungen davon einbringen.

Verschlüsselung

Gerade im Hinblick auf das Urteil des Europäischen Gerichtshofs (EuGH), welches das Privacy-Shield-Abkommen kippte, gewinnt die Verschlüsselung von Daten in der Cloud an Bedeutung. Das kann sogar so weit gehen, dass damit eine Nutzung amerikanischer Cloud-Dienste möglich wird. Etwa dann, wenn der Cloud-Anbieter keine Möglichkeit hat, auf die Schlüssel zuzugreifen.

In aller Regel übernimmt der Cloud-Provider die Verschlüsselung komplett selbst. So verschlüsselt etwa Google standardmäßig den Datenverkehr zwischen den eigenen Rechenzentren ebenso wie die auf (virtuellen) Speichermedien abgelegten Daten seiner Cloud-Kunden (Encryption at Rest [6]). Doch alle dabei eingesetzten Schlüssel erzeugt Google selbst und hat sie im Zweifelsfall natürlich auch im Zugriff. Das ist bei anderen Cloud-Anbietern im Wesentlichen nicht anders.

Manche Cloud-Provider bieten allerdings auch an, dass Kunden das Schlüsselmanagement selbst übernehmen und eigene Schlüssel zur Verschlüsselung bereitstellen. In der Regel wird der vom Kunden generierte Schlüssel dann im Schlüsselverwaltungsdienst oder einem Hardware Security Modul (HSM) des Cloud-Providers gespeichert. Dabei übernehmen jedoch immer noch Mitarbeiter des Cloud-Providers zumindest Teile des Schlüssel-Managements und haben somit Zugriff auf Schlüsselmaterial, das sie im Zweifelsfall anfragenden Behörden übergeben müssen.

Eine mögliche Lösung hierfür wäre das Verfahren Hold Your Own Key (HYOK). Dabei generiert und verwaltet der Cloud-Nutzer die Schlüssel und bringt diese selber in sein eigenes, lokales HSM ein. Da dabei alle Ver- und Entschlüsselungsoperationen in diesem lokalen HSM stattfinden müssen, ist der Cloud-Dienst dann allerdings gegebenenfalls nur eingeschränkt nutzbar. Einen Zwischenweg bietet beispielsweise die Google Cloud Platform (GCP). Sie hält dabei einen vom Kunden erzeugten und bereitgestellten Schlüssel für die Ver- und Entschlüsselung im RAM vor. Dort wird er aber sofort wieder gelöscht, sobald er nicht mehr benötigt wird.

Darüber hinaus bieten auch bereits einige Dritt-Hersteller Verschlüsselungs-Gateways an, die schützenswerte Daten vor dem Zugriff durch den Cloud-Provider schützen sollen. Allerdings bringen diese Lösungen häufig Funktionseinbußen mit sich – etwa dass die Suche eines Saas-Dienstes nach oder in Dateien nicht mehr oder nur eingeschränkt funktionsfähig ist.

Im Zweifelsfall sollte der Nutzer eines Cloud-Dienstes genau prüfen, ob sich der zu betreibende Aufwand für mehr, beziehungsweise selbst verwaltete, Verschlüsselung tatsächlich lohnt. Oft kann man etwa schon mit einem feinkörniger justierten Berechtigungskonzept eine vergleichbare Verbesserung des Sicherheitsniveaus erreichen.

Notfallmanagement

Ein Punkt der vor der Inbetriebnahme eines (Cloud-)Dienstes häufig zu kurz kommt, ist das Notfallmanagement beziehungsweise dessen Vorbereitung. Deshalb sollte dieser Punkt nach dem Start der ersten Cloud-Projekte auf der Todo-Liste deutlich nach oben wandern. Führen Sie dazu eine systematische Analyse durch, was der Ausfall einzelner Dienste bedeutet und welche Vorkehrungen es bereits gibt, damit umzugehen.

Berücksichtigen Sie dabei vor allem die Besonderheiten der Cloud. Sind etwa bereits Redundanzen vorhanden? Gibt es Backups? Sind diese auch bei einem Ausfall der Internetanbindung noch verfügbar? Kann man eine Wiederherstellung mit den im Notfall verfügbaren Ressourcen in einem vertretbaren Zeitrahmen durchführen? Hat das tatsächlich mal jemand getestet?

Forensik und Incident Response

Immer mehr Firmen gehen zu einem Konzept von "Assume Compromise" über. Die entscheidenden Kriterien für den sicheren Betrieb der IT sind dabei nicht mehr, ob man angegriffen wird und es dann gelingt diesen Angriff erfolgreich abzuwehren. Sondern es geht vielmehr darum, die Reaktion auf Angriffe zu optimieren. Dabei stehen die folgenden Fragen im Zentrum: Wie lange dauert es nach einem erfolgreichen Angriff, bis wir diesen bemerken und beenden können? Wie hoch ist der bei solchen Angriffen anfallende Schaden? Und vor allem: Wie kann ich diese Werte senken?

Dabei kommt der Incident Response eine Schlüsselrolle zu. Alles was man bereits vorab tun kann, um deren Effizienz zu verbessern, wirkt sich direkt positiv auf die Bilanz aus. Das fängt damit an, dass man Zuständigkeiten für IT-Sicherheitsvorfälle klärt, dokumentiert und allgemein bekannt macht. Es geht weiter damit, dass sich die Incident-Response- und Forensik-Spezialisten bereits vorab mit den verschiedenen Protokolldateien vertraut machen, die die genutzten Cloud-Provider bereitstellen. Man kann sogar eine separierte Forensik-Umgebung in der Cloud konzipieren, in der die Kollegen der Incident Response oder Forensik bereits alle notwendigen Berechtigungen haben.

Im Übrigen müssen auch ausgewiesene Forensik-Spezialisten ihre Skills in Bezug auf Cloud-Dienste auf den Prüfstand stellen und anpassen. So haben wir es wirklich erlebt, dass ein Forensiker zunächst versuchte, viele Terabytes zu analysierender Daten in seine lokale Forensikumgebung zu kopieren. Dabei hätte ihm schon eine kurze Überschlagsrechnung im Kopf sagen müssen, dass dieser Vorgang mehrere Tage dauert – Zeit, die wir nicht hatten, weil die Hecke brannte. In einem solchen Fall sollte man besser Funktionen nutzen, die Cloud-Provider bereitstellen. Da kann man dann beispielsweise in der Cloud einen Snapshot des zu analysierenden Systems ziehen und direkt dort in einer separierten Forensik-Umgebung analysieren. Das spart in solchen Notfällen wertvolle Zeit – wenn man weiß wie.

Sicherheit integrieren

Wenn Sie selbst Cloud-Anwendungen entwickeln, hatten Sie sicher bereits Berührung mit Konzepten wie DevOps und Continuous Delivery. Unser Tipp: Erweitern Sie diese um Sicherheitskomponenten, die möglichst Cloud-native Maßnahmen und Lösungen integrieren. DevSecOps bietet die Möglichkeit, kontinuierliche Sicherheit sowohl in den Softwareentwicklungsprozess als auch beim Software-Deployment zu verankern. Das sprengt den Rahmen hier, aber bei heise Developer gibt es eine interessante Artikelserie zu DevSecOps [7].

Fazit

Wenn man sich auf die Nutzung der Cloud einlässt, sollte man es richtig und nicht halbherzig machen. Das heißt zum einen, dass man nicht mit aller Gewalt an althergebrachten Konzepten und Maßnahmen festhält. Statt dessen sollte man Dinge, die sich in der Cloud erledigen lassen, möglichst auch dort umsetzen und dabei vorhandene Infrastruktur bestmöglich nutzen. Das gilt auch für die Sicherheit.

Und zum anderen muss die Nutzung der Cloud im Unternehmen auf eine breite Basis gestellt werden. Der Einsatz von Cloud-Diensten betrifft immer auch die Security und den Datenschutz. Nehmen Sie also möglichst früh alle Beteiligten mit an Bord und sorgen sie dafür, dass sich das Wissen um die Möglichkeiten und Besonderheiten der Cloud-Nutzung verbreitet. Viele Angreifer profitieren von der Unwissenheit ihrer Opfer. Nehmen Sie ihnen diesen Vorteil.

(ju [13])

URL dieses Artikels:
https://www.heise.de/-4918993

Links in diesem Artikel:
[1] https://www.heise-events.de/webinare/cloud-aber-sicher
[2] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Fehler-und-was-man-daraus-lernen-kann-1-4-4912754.html
[3] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Angriffe-und-wie-Sie-sich-schuetzen-2-4-4913820.html
[4] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Der-sichere-Weg-in-die-Cloud-3-4-4917363.html
[5] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Ich-bin-schon-drin-was-nun-4-4-4918993.html
[6] https://cloud.google.com/security/encryption-at-rest
[7] https://www.heise.de/hintergrund/DevSecOps-der-naechste-Hype-nach-DevOps-und-Containern-4325496.html
[8] https://www.heise-events.de/webinare/cloud-aber-sicher
[9] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Fehler-und-was-man-daraus-lernen-kann-1-4-4912754.html
[10] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Typische-Angriffe-und-wie-Sie-sich-schuetzen-2-4-4913820.html
[11] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Der-sichere-Weg-in-die-Cloud-3-4-4917363.html
[12] https://www.heise.de/hintergrund/Cloud-fuer-Unternehmen-Ich-bin-schon-drin-was-nun-4-4-4918993.html
[13] mailto:ju@ct.de

Copyright © 2020 Heise Medien