Cloud für Unternehmen: Typische Fehler und was man daraus lernen kann (1/4)
Immer mehr Unternehmen wollen das Potential der Cloud nutzen. Doch nicht selten sorgen grundsätzliche Fehler für ein Fiasko.
- Inés Atug
- Manuel Atug
Die Autoren dieser Serie zu "Cloud für Unternehmen" begleiten und analysieren seit vielen Jahren Cloud-Projekte. Dabei stoßen sie immer wieder auf ähnliche Probleme und leicht vermeidbare Fehler. Die im folgenden exemplarisch aufgeführten Unternehmen und Personen sind zwar fiktiv, beruhen aber auf sehr realen Erfahrungen.
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
Der Sparfuchs
Egon Müller ist Geschäftsführer eines erfolgreichen mittelständischen Unternehmens. Eines seiner ständig wiederholten Mantras ist "Kosteneffizienz", was ihm auch intern den Spitznamen "der Sparfuchs" eingebracht hat. Müller setzt dabei keineswegs immer auf die billigste Lösung. Vielmehr besteht sein Erfolgsrezept daraus, aus der vielleicht zweitbilligsten Kombination von Angeboten den maximalen Benefit zu ziehen. Bei seinem letzten Projekt, der Umstellung eines zentralen Teils der IT, ging das jedoch gründlich in die Hose.
Um den Anschluss an die Mitbewerber nicht zu verlieren und um sich auf den Weg in die Digitalisierung zu begeben, wurde beschlossen, die zum Großteil bereits virtualisierten Anwendungen in die Cloud zu überführen. So wurden dabei unter anderem die Lohnbuchhaltung und die Reisekostenabrechnung als virtualisierte Maschinen in die Cloud überführt.
(Bild: Sam Johnston - CC BY-SA 3.0)
Die Option, diese Anwendungen mit externen Cloud-Diensten zu realisieren, wurde nach kurzer Diskussion verworfen, weil dies eine schnelle Umsetzung des Projekts auf unbestimmte Zeit verschoben hätte. Schließlich hätte man zunächst ein Anforderungsprofil erstellen, die Angebote sichten müssen und so weiter. Müller wollte jedoch möglichst schnell ein erfolgreiches Vorzeigeprojekt für seine Modernisierungskampagne.
Ausgeraubt
Doch dieses Cloud-Projekt erwies sich sehr schnell als veritabler Fail. Bei einer Bestandsaufnahme nach einem Jahr stellte sich heraus, dass die Betriebskosten keineswegs im erwarteten Umfang gesunken waren – im Gegenteil. Darüber hinaus kam es zu einem massiven IT-Sicherheitsvorfall, der das Unternehmen in ernste Schwierigkeiten brachte.
Eine Cybercrime-Bande hatte sich Zugang zu einer der Datenbanken verschafft, die auf einer virtuellen Maschine in der Cloud betrieben wurde, und drohte mit der Veröffentlichung der gestohlenen Daten. Erst nach Zahlung einer fünfstelligen Summe löschten sie den Datenbank-Dump, den sie erstellt hatten. Haben sie zumindest behauptet ...
Das Problem war, dass man die Datenbanken unverändert zusammen mit den Anwendungen auf der gleichen virtuellen Maschine belassen hatte. An eine zusätzliche Absicherung der jetzt nicht mehr im lokalen Netz sondern in der Cloud betriebenen Dienste oder der virtuellen Maschinen hatte niemand gedacht.
Die Umgebung innerhalb der Cloud wurde ebenfalls nicht ausreichend abgesichert. So hat jeder Nutzer der Einfachheit halber schnell globale Rechte im Identitäts- und Berechtigungsmanagement erhalten, statt ein Rechte- und Rollenmodell auf Basis der Anwendungen zu entwickeln und in der Cloud auszurollen.
Die zu Hilfe gerufenen Incident-Response-Experten bescheinigten Müller, dass die Angreifer damit denkbar leichtes Spiel hatten. Der seit der Migration auch aus dem Internet erreichbare RDP-Zugang auf der virtuellen Maschine exponierte einen Account mit einem schwachen Passwort, das die Angreifer erraten konnten. Mit dem interaktiven Zugang zum System war der Rest ein Kinderspiel.
Lehren aus dem Sparfuchs-Debakel
Zwar ist das gerade geschilderte Beispiel – inklusive der Person Egon Müller – fiktiv. Doch es ist direkt abgeleitet aus den Erfahrungen, die wir immer wieder in unseren Analysen von realen Cloud-Projekten erleben.
Ein Grundproblem ist, dass viele Cloud-Neulinge die Aufgabenverteilung in Bezug auf Security nicht verstehen. Die Sicherheit der Cloud-Umgebung und ihrer Cloud-Dienste liegt in der gemeinsamen Verantwortung von Cloud-Provider und Cloud-Kunde.
Der Cloud-Provider kümmert sich dabei beispielsweise um die physische Sicherheit und den Schutz der Hardware. Außerdem ist er für die Sicherheit der genutzten Cloud-Dienste verantwortlich. Der Cloud-Kunde hingegen muss sich um die Sicherheit der von ihm betriebenen Umgebung kümmern. Hierzu gehört dann auch, dass Sicherheitsaktualisierungen für das Gastbetriebssystem auf den virtuellen Maschinen durch den Kunden eingespielt werden müssen. Auch um Backups oder die Wartung der Datenbanken muss sich der Cloud-Kunde dann selber kümmern.
Auf das für Zugangs- und Rechteverwaltung zuständige Identity und Access Management der Kunden-Komponenten und Umgebung hat der Cloud-Provider ebenfalls kaum Einfluss. Insofern muss der Kunde selber die Cloud-Umgebung mit den Möglichkeiten des Monitorings und der angemessenen Vergabe von Zugriffsrechten absichern.
Ein anderer kritischer Punkt ist das von Müllers Unternehmen praktizierte "Lift & Shift" – also der simple Umzug einer vorher lokal betriebenen, kompletten Anwendung in eine Virtuelle Maschine in der Cloud. Dieses Konzept ermöglicht zwar einen recht schnellen und weitgehend reibungslosen Umzug in die Cloud. Das stellt sich aber sehr häufig erst im Nachhinein als Verursacher hoher Kosten heraus. Da berücksichtigen dann zum Beispiel die Schätzungen für das benötigte Netzwerk-Traffic-Kontingent das nächtliche Offsite-Komplett-Backup nicht. Häufig sind auch die in der Cloud-Umgebung betriebenen virtuellen Maschinen zu groß dimensioniert. Das böse Erwachen folgt dann nach der nächsten Rechnung.
In vielen Fällen zeigt eine sorgfältige Analyse, die wirklich alle anfallenden Kosten einschließt, dass sich nennenswerte Einsparungsziele nur dann erreichen lassen, wenn man die Anwendungen mit den angebotenen SaaS-Diensten in der Cloud betreibt oder die Anwendungsarchitektur weitgehend einem Cloud-nativen Ansatz annähert. Das erfordert zwar in beiden Fällen vorab ein größeres Investment und mehr Vorlauf, rentiert sich aber im laufenden Betrieb oft sehr schnell. Darüber hinaus entlastet es auch die eigenen Admins, da so unter anderem die Automatisierung auch für die Absicherung der genutzten Dienste verwendet werden kann.
Die Sicherheitsperfektionistin
Bei der Firma Schneider leitet Paula Schrader die IT. Sie ist zu Recht stolz auf ihre nach Stand der Technik abgesicherte IT-Umgebung. Als die Geschäftsführung die Migration der Anwendungen in die Cloud verkündet, steht für Paula Schrader fest: Cloud ist erstmal unsicher und muss vorher bestmöglich abgesichert werden. Und schon legt sie los, ein sicheres virtuelles Netzwerk und eine sichere Umgebung für virtuelle Maschinen (VMs) in der Cloud zu konzipieren.
Als Schrader sich genauer in der Cloud-Umgebung umsah, stellte sie fest, dass viele bekannte Komponenten zum Einsatz kommen – nur eben virtuell. Entsprechend hat sie die Umgebung mit bekannten Konzepten abgesichert, also mittels Firewalls und ACLs auf der Netzwerkseite. Da der Infrastruktur-Anbieter in der Cloud (Infrastructure as a Service, IaaS) keine Firewall-Services anbot, lässt sie kurzerhand auch virtuelle Firewall-Appliances namhafter Hersteller im virtuellen Netzwerk aufsetzen.
Auch die Härtung der virtuellen Maschinen und derer Gast-Betriebssysteme erfolgte entsprechend der bewährten Vorgehensweise. Die VMs erhielten dazu lokale Firewalls, Host Intrusion Dection Systems (HIDS) und Antimalware-Software. Für das Monitoring und die Protokollierung übertrugen die in der Cloud betriebenen Anwendungen und Sicherheitssysteme ihre Log-Daten zum lokalen SIEM – natürlich abgesichert über ein VPN. Um zu verhindern, dass Daten in die Hände Unbefugter gelangen, sorgte Schrader auch dafür, dass die in den Datenbanken gespeicherten Daten mit Oracles Transparent Data Encryption (TDE) verschlüsselt werden.
Allerdings wurden schon bald erste Beschwerden laut. So war für jede neue Anwendung zunächst ein dokumentiertes IT-Sicherheitskonzept vorzulegen. In aller Regel mussten dazu dann auch neue Freischaltungen auf der Firewall eingerichtet – beziehungsweise genauer: definiert, begründet, getestet und anschließend freigeschaltet werden.
Insgesamt dauerte die Installation neuer Anwendungen geschätzt viermal so lang wie zuvor. Dabei wollte man doch eigentlich flexibler und schneller werden. Letztlich führten Schraders Sicherheitsmaßnahmen sogar dazu, dass die IT-Kosten nicht wie geplant gesunken sondern sogar noch gestiegen sind. Aber dafür war wenigstens alles sicher...
Der blinde Fleck
Das dachte Schrader jedenfalls. Bis sie eines Tages eine E-Mail des Cloud-Providers erreichte. Es gäbe Hinweise auf verdächtige Kommunikation ihrer Cloud-Systeme mit bekannten Kontrollservern einer Cybercrime-Bande. Sie solle dringendst all ihre Systeme auf das Linux-Rootkit Skidmap checken, das die Prozesse der Kriminellen versteckt. “Linux ???” Bei Schrader gingen sofort alle Alarmsirenen an. Ihre Infrastruktur setzte fast komplett auf Windows; der einzige Linux-Server wurde durch Firewall-Regeln an der Kommunikation mit der Außenwelt gehindert. Irgendwas lief da schief – und zwar gewaltig.
Wie die sofort eingeleitete Untersuchung ergab, hatten sich durch einen Konfigurationsfehler Eindringlinge Zugang zur Ressourcenverwaltung verschaffen können und dort fleißig neue VM-Instanzen gestartet. Die schürften dann fleißig Crypto-Geld, das in den Wallets der Einbrecher landete. Auf den Kosten für den Betrieb blieb jedoch die Firma Schneider sitzen. Und die waren beträchtlich, immerhin liefen die meisten bereits mehrere Wochen.
In den Gesprächen mit dem Support des Cloud-Providers stellte sich heraus, dass er nicht die gesamte Kundenumgebung überwacht und abgesichert hat, da dies Aufgabe des Kunden sei. Und die eigenen Firewalls und VPNs sicherten zwar die selbst erstellten VMs und Anwendungen ab, nicht jedoch die vom Provider gestellte Management-Infrastruktur und das neue virtuelle Netz der Einbrecher.
Lehren aus dem Perfektionisten-Debakel
Bei Cloud-Umgebungen handelt es sich um eine verteilte und verzahnte Infrastruktur. Es kommt einerseits bekanntes, wie virtuelle Maschinen, zum Einsatz. Doch auf der anderen Seite gibt es darüber hinaus Speicherdienste, verschiedene Datenbankdienste, Container und viele weitere Cloud-Dienste. Das bedeutet, dass traditionelle Sicherheitsmaßnahmen, wie Firewalls in der Cloud-Umgebung nur bedingt mehr Sicherheit bringen.
Stattdessen sollten die bereits vorhandenen Sicherheitsfunktionen der Cloud-Umgebung das Fundament des Sicherheitskonzepts bilden. Bringt man statt dessen eigene Basis-Komponenten ein, wird die Integration der existierenden Sicherheitsfunktionen aufwändig und schwierig. Insgesamt vergrößert sich damit der zu betreibende Aufwand gewaltig und das Projekt wird unnötig teuer.
Die bereits vorhandenen Sicherheitsfunktionen der Cloud-Infrastruktur kann man hingegen im Idealfall so automatisieren, dass sie die gesamte Angriffsfläche abdecken. Also alle virtuellen Maschinen und Anwendungen und auch die genutzten Anteile der Provider-Umgebung. So hätte man mit den Diensten des Cloud-Providers die Auffälligkeiten hinsichtlich der Ressourcenverwendung früher bemerken können.
Ganz essentiell für ein effizientes Sicherheitskonzept ist es auch, dass die Maßnahmen und Werkzeuge dem agilen und dynamischen Spirit der Cloud entsprechen. Wenn das Aufsetzen eines neuen Dienstes eine Sache von wenigen Mausklicks ist, darf der damit verbundene Sicherheits-Overhead nicht in Stunden oder gar Tage ausufern. Sonst lassen sich auf diesem Weg keine Einsparungen erzielen – und der erzielte Sicherheitsgewinn bleibt trotzdem fraglich.
Der Weg des Pragmatikers
Der Weg, sowohl das Sparfuchs-Debakel als auch die aus Perfektionismus resultierenden Probleme zu vermeiden, setzt auf Pragmatismus. Dabei muss allen Beteiligten klar sein, dass es bei der verstärkten Cloud-Nutzung nicht nur um Technik und IT geht, sondern ein Kulturwechsel erforderlich wird. Die Cloud bringt Flexibilität und Skalierbarkeit. Doch diese Eigenschaften kann man nur nutzen, wenn man lernt, agil und flexibel zu (re-)agieren.
Ein sinnvoller Einstieg in ein solches Projekt ist ein Workshop, an dem alle dafür wichtigen Stakeholder teilnehmen. Ein zentraler Punkt dabei sollte die Frage der Sicherheit sein. Also ganz konkret die Frage: "Was sind die Voraussetzungen für einen sicheren Cloud-Betrieb?" Und daran anschließend natürlich gleich: "Wie kommen wir mit unserer Infrastruktur dort hin?". Ein daraus abgeleitetes Konzept wird dann typischerweise die folgenden Punkte thematisieren.
Least Privilege-Prinzip durchsetzen – Zur Absicherung der Cloud-Umgebung wird ein Berechtigungskonzept erstellt, das mit Hilfe der in der Cloud vorhandenen Rollen die Berechtigungen an die Benutzer vergibt. Der Root-Benutzer wird nicht verwendet und die Zugangsdaten werden sicher verwahrt. Die Nutzung der zugeteilten Rollen wird überwacht. Die Berechtigungen werden entsprechend angepasst, wenn Berechtigungen fehlen, oder innerhalb von drei Monaten nicht verwendet wurden.
Sichere Authentifizierungsmethoden – Die Anmeldung der Benutzer ist nur noch mittels zweitem Faktor erlaubt. Im ersten Schritt wird MFA für alle Benutzer über eine Authenticator-App aktiviert, die etwa auf dem Smartphone TOTP-Tokens erzeugt. In einem weiteren Schritt sollen Administratoren und Benutzer mit besonders weitreichenden Rechten Hardware-Tokens als zweiten Faktor erhalten.
Kennzeichnung der Cloud-Dienste – Man kann nur das managen und überwachen, was man auch kennt und messen kann. Die Kennzeichnung der Cloud-Dienste hilft bei der Verwaltung der Cloud. Je länger die Cloud ungekennzeichnet betrieben wird, umso schwerer bis nahezu unmöglich wird es, die Kennzeichnung nachzuholen und Cloud-Dienste zu erkennen, die nicht mehr benötigt werden. Dazu empfiehlt es sich, vorher eine Namenskonvention für Labels und Tags zu definieren und konsequent einzusetzen, um die Zusammengehörigkeit der vorhandenen Cloud-Assets zueinander abzubilden.
Arbeiten mit globalen Sicherheitsregeln – Es werden globale Sicherheitsregeln als sogenannte Mindeststandards für die eigene Cloud implementiert. Hierzu gehört etwa, dass eine neue Ressource nur dann angelegt werden darf, wenn auch eine Kennzeichnung vorhanden ist. Oder man legt wegen Compliance-Vorgaben fest, dass grundsätzlich nur Dienste genutzt werden, die in europäischen Rechenzentren gehostet werden. Solche Regeln helfen, trotz des agilen und flexiblen Umfelds in der Cloud einen einheitlichen Sicherheitsstandard umzusetzen.
Ausweitung des Monitorings – Das Monitoring wird auf die Cloud-Umgebung, die Aktivitäten von administrativen Benutzern und die Überwachung der Integrität der Logdaten selbst ausgedehnt. Es wird sichergestellt, dass nur ein kleiner Kreis von berechtigten Personen auf die Logdaten zugreifen kann und dass die vom Cloud-Provider bereitgestellten Read-Only-Speicher zum Einsatz kommen. Eine Übertragung der Protokolldaten an ein lokales SIEM ist der nächste logische Schritt, um im Falle des Falles die Protokolle auch unabhängig von der Verfügbarkeit der Cloud im Zugriff zu haben.
Aufgaben an den Cloud-Provider abgeben – Wenn möglich und sinnvoll, sollten von der Cloud angebotene native Dienste den eigenen Anwendungen vorgezogen werden, da diese insbesondere aus Sicherheitssicht besser in das gesamte Zusammenspiel integriert sind. Beispielsweise sollte das Berechtigungsmanagement über die von der Cloud bereitgestellten Dienste und Möglichkeiten erfolgen. Auch beim Loadbalancer sollte in der Regel eher der nativ bereitgestellte Loadbalancer in der Cloud verwendet werden, da dieser vom Cloud-Provider gemanagt wird und bereits passend in die Infrastruktur der Cloud und ihren Sicherheitsfunktionen integriert ist.
Kostenkontrolle - Die Kosten in der Cloud werden zukünftig von den zuständigen Administratoren überwacht. Werden neue Cloud-Dienste hinzugefügt, wird deren Ressourcenverbrauch überwacht, um bedarfsgerecht nachjustieren zu können und um einen Missbrauch von Ressourcen möglichst schnell zu erkennen.
Fazit
Die Nutzung der Cloud hat großes Potential, nicht nur für Kosteneinsparungen und Skalierbarkeit – sondern auch für mehr Sicherheit. Wer es richtig anstellt, profitiert von vorhandener Security-Tools, professionell gewarteter Infrastruktur und gutem Monitoring.
Probleme wie plötzlich explodierende Kosten oder Security-Albträume sind in aller Regel nicht der inhärent "bösen Cloud" geschuldet, sondern zumeist der falschen Herangehensweise. Das passiert insbesondere dann, wenn man sich nicht genügend mit den neuen Bedrohungen und Angriffsszenarien auseinander gesetzt hat, die die Nutzung von Cloud-Infrastruktur mit sich bringt. Deshalb nimmt der nächste Teil die Perspektive eines Angreifers ein und zeigt, welche neuen Möglichkeiten sich einem da plötzlich eröffnen. Um dann die Perspektive zu wechseln und Ihnen zu erläutern, wie Sie sich und Ihre IT davor effizient schützen.
(ju)
