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.
