Hürden nicht zu hoch setzen Cloud-basierte Sicherheitsverstöße erkennen und vermeiden
Anbieter zum Thema
Cloud-Technologien werden ständig weiterentwickelt. Die Vorteile der Nutzung geteilter Ressourcen-Pools für Rechenleistung und Daten liegen auf der Hand. Wie bei jeder verteilten und öffentlich zugänglichen IT-Infrastruktur ergeben sich daraus Sicherheitsrisiken, die Anwender kennen, in ihrer Sicherheitsarchitektur berücksichtigen und entsprechende Gegenmaßnahmen ergreifen sollten.

Die Gefahren-Vektoren lassen sich grob in zwei sehr weit gefasste Kategorien einteilen: Sicherheitsprobleme, die im Verantwortungsbereich der Cloud-Anbieter liegen sowie Sicherheitsprobleme, die im Verantwortungs- und Wirkungsbereich der Nutzer der Cloud-Angebote liegen.
Die Angriffsvektoren sind vielfältig. Hacker könnten sich beispielsweise Zugriff auf Daten (auf dem Übertragungsweg oder dort, wo sie gespeichert werden – in transit / at rest), einzelne Workloads oder Dienste oder etwa auf Benutzer- und Administrationskonten verschaffen wollen. Die Ziele der Angreifer sind unterschiedlich und es stellt sich die Frage, wie die Angreifer klassifiziert werden können. Generell liegt die Motivation der Angreifer entweder in der technischen Herausforderung oder dem finanziellen oder politischen Gewinn, den sie sich dadurch erhoffen.
Zu den maliziösen Aktivitäten gehören unter anderem die Manipulation oder Verschlüsselung von Daten bei Angriffen wie Ransomware, Nutzung von Rechenleistung z.B. für Crypto-Currency und das Aufstellen von Bot-Nets, mit denen man sogenannte DDoS-Attacken starten kann. DDoS steht für Distributed Denial of Service, d.h. eine Vielzahl zuvor manipulierter Systeme fängt beispielsweise zu einem bestimmten Zeitpunkt oder auf externen Befehl hin an, pausenlos Anfragen an bestimmte Serversysteme zu schicken und diese somit komplett zu überlasten, sodass die Serverdienste für Dritte zeitweilig nicht mehr zu erreichen sind.
Der Kreativität der Angreifer sind hier keine Grenzen gesetzt. Oft werden Verwundbarkeiten in den Betriebssystemen oder Anwenderprogrammen der Endbenutzersysteme oder Server verwendet - aber auch der Faktor Mensch sollte hier nicht außer Acht gelassen werden (Stichwort: Social Engineering).
Über Viren, Würmer, E-Mail-Anhänge, aktive Inhalte und Pop-up-Fenster auf Webseiten, Messengern etc. können Schadprogramme beziehungsweise Code auf den Anwendersystemen und Servern installiert und ausgeführt werden. Mit einem Ziel: Zugriff auf diese Systeme zu erhalten. Zeitweilig lassen sich auch Systemtools, die nicht regelkonform angesteuert werden, dazu nutzen, Kommandos als root-User auszuführen und damit beispielsweise maliziösen Programmcode über das Netz nachzuladen.
Erhalten Unbefugte durch das Ausnutzen einer fehlerbehafteten Implementation eines Dienstes (Buffer-Overflow, SQL-Injection etc.) auf einem Server Zugriff auf eine Nutzer-Datenbank (Benutzernamen, Passwörter, ggf. noch Adressdaten und Konto-/Kreditkarten-Informationen), so ist dies für den betroffenen Dienste-Anbieter oder auch Cloud-Anwender sehr ärgerlich. Zusätzlich eröffnet der unbefugte Besitz einer Datenbank – neben der Möglichkeit, diese im Darknet zu monetarisieren, – auch die Nutzung der Daten im Zusammenhang mit dem sog. „Credential-Stuffing“. Das bedeutet, die Nutzername/Passwort-Kombinationen werden auch auf anderen Websites ausprobiert. Sie sind sicherlich beim Lesen dieser Zeilen vollkommen entspannt, da Sie einzigartige Passwörter für jeden unterschiedlichen Account verwenden, nicht wahr? Interessanterweise haben derartige Angriffe eine Erfolgsquote von bis zu 2 Prozent.
Zugriff verhindern durch starke Passwörter und 2FA
Die Erfolgswahrscheinlichkeit, Zugriff via Exploits zu erlangen, lässt sich schon durch regelmäßiges Einspielen von Patches auf den Server-Systemen stark vermindern. Weiterhin sollte die Verwendung gleicher Passwörter auf unterschiedlichen Systemen strikt vermieden werden, zumal aktuelle Betriebssysteme oft die Möglichkeit bieten, sich vom System automatisch starke Passwörter generieren zu lassen.
Zudem sollte die Integration von Zwei-Faktor-Authentifizierung (2FA), wie beispielsweise Twilio Authy / Verify, selbstverständlich sein, da zusätzlich zum Passwort noch ein weiterer Faktor (Einmalpasswörter, die über Token, Apps etc. generiert werden, oder biotmetrische Charakteristika wie Fingerabdruck oder Stimme) überprüft wird – und somit gegen Angriffe via Credential Stuffing, Keylogger oder auf anderem Wege ausgespähte Passwörter hilft. Ist der Einsatz von Software-Appliances angedacht, sollte darauf geachtet werden, Default-Passwörter zu ändern oder noch besser, die Systeme ins (hoffentlich) vorhandene SSO-System zu integrieren.
Daten sollten auf dem Übertragungsweg und auch am Speicherort immer verschlüsselt sein – laut den Ergebnissen der Thales Cloud Security Studie von 2021 leider noch immer keine Selbstverständlichkeit. Viele verlassen sich auf die trügerische Sicherheit, die einem die inhärente Redundanz z.B. des GFS (Google File System) verspricht. Daten werden redundant abgelegt und können den Ausfall diverser Knoten schadlos überstehen. Das hilft natürlich wenig, wenn man Opfer einer Ransomware-Attacke geworden ist (dies gilt natürlich auch für On-Prem-Implementierungen).
Eine umfassende Data-Protection-Strategie wird hier gerne außer Acht gelassen, ein regelmäßiges Wegsichern von sog. „immutable“ Snapshots sollte Bestandteil jeder vernünftigen Datensicherungsstrategie sein. Wenn die eigene Cloud-Umgebung kompromittiert ist, sollte die Schadsoftware nicht auch noch die Backups zerstören können. Hier lohnt sich das Nachfragen in Ihrer IT-Abteilung, wie es sich mit den Shares auf Google Drive oder OneDrive verhält.
In Builder-Environments sollte auch tunlichst darauf geachtet werden, wie mit den im Einsatz befindlichen API-Keys umgegangen wird. Wer sich ein wenig auf GitHub umschaut, wird mit Sicherheit API Keys und Secrets in hochgeladenen Code Repos finden. Mit der Verwendung von Umgebungsvariablen lässt sich das einfach und sicher vermeiden. Zudem sollten die Code-Dependencies regelmäßig darauf überprüft werden, ob sie nicht veraltete Bibliotheken und Pakete vorschreiben, für die bekannte Exploits existieren. Das lässt sich mittlerweile über Software-Tools automatisieren.
Sicherheit sollte dem eigentlichen Einsatzzweck der IT nicht entgegenstehen
Die Liste von Schutzmaßnahmen und -Systemen für Cloud-Security lässt sich beliebig fortsetzen. Bei der Auswahl des Cloud-Anbieters sollte der Anwender in erster Linie von seinen Zielvorstellungen angeleitet werden. Es ist davon auszugehen, dass die Cloud-Anbieter alle Maßnahmen ergreifen werden, die Bereiche, die in deren Verantwortung liegen, entsprechend zu schützen und sicher zu gestalten.
Der Anwender sollte eine adäquate und verständliche Security-Policy aufstellen und hierzu den Buy-In des eigenen Managements (CEO, COO, CISO) bis hin zum Endanwender im eigenen Haus haben. Sicherheit sollte so gestaltet sein, dass sie dem eigentlichen Einsatzzweck der IT nicht entgegensteht und diesen unnötig komplex und schwierig gestaltet. Ansonsten werden die erwünschten Vorteile nicht eintreten oder Anwender finden einen Weg, die Maßnahmen zu umgehen.
Abschließend ist es bei der Nutzung von Cloud-Diensten unerlässlich, die inhärenten Möglichkeiten neuer Technologien und die Skalierbarkeit zu nutzen. Mit der in vielen Bereichen üblichen „Lift & Shift“-Migration, der Migration von On-Prem-Workloads eins zu eins in die Cloud, verpasst man die Chance, sich von Legacy Strukturen zu verabschieden und hochskalierbare, flexible, performante und zukunftssichere cloud-native Umgebungen zu bauen, die der Wettbewerbsfähigkeit des eigenen Unternehmens sehr zuträglich sind.
(ID:48089585)