Cloud für Unternehmen: Ich bin schon drin – was nun? (4/4)

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.

In Pocket speichern vorlesen Druckansicht 26 Kommentare lesen
Cloud für Unternehmen: Der Weg zu sicheren Cloud
Lesezeit: 12 Min.
Von
  • Inés Atug
  • Manuel Atug
Inhaltsverzeichnis

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.

Weitere Teile der Serie "Cloud für Unternehmen"

Die Autoren bereiten den Inhalt der kompletten Serie auch gezielt für Administratoren, IT- und Datenschutzverantwortliche in einem heise-Security-Webinar auf: In die Cloud – aber sicher

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.

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.

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.

Ein Bastion Host erlaubt nur definierte Zugriffe und sorgt für Monitoring und Protokollierung.

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.