Public Cloud Security

Mit dem Hosting von Business-Software in einer Public Cloud ergeben sich neue Angriffsszenarien. Sechs Schritte helfen, das Risiko in Public Clouds zu reduzieren. [...]

Mit dem Hosting von Business-Software in einer Public Cloud ergeben sich neue Angriffsszenarien. Durch die Auslagerung kritischer Geschäftsprozesse in die Cloud ist ein Unternehmen sämtlichen Gefahren ausgeliefert, die im Internet existieren, von Viren, Trojanern und Bot-Netzen bis hin zu Abhöraktionen und Spionage. Business-Software ist jedoch gar nicht dafür ausgelegt, vor solchen Risiken zu schützen. Viel wichtiger ist deshalb die Frage für Unternehmen, wie bzw. welche Daten und Anwendungen in die Cloud verlagert werden und wie sie dort an die Risiken anzupassen sind. Sechs Schritte helfen, das Risiko in Public Clouds zu reduzieren.

• 1. Auf Sicherheitszertifikate achten: Dem zunehmenden Bewusstsein der Kunden für die Sicherheit von Business-Software begegnen Softwareanbieter damit, dass sie ihre Produkte verstärkt auf Sicherheits­lücken testen lassen. Anwender sollten deshalb auf Sicherheitsevaluierungen achten, wie sie zum Beispiel Spezialisten für Sicherheitstests ausstellen, oder ihre Software durch Dritte prüfen lassen.
• 2. Business-Software prüfen: Wenn Softwareanbieter trotz Zertifizierung Sicherheitsversprechen nicht halten, können sie haftbar gemacht werden. Ist der Anbieter aber nicht identifizierbar, wie etwa bei Open-Source-Komponenten, trägt der ­Anwender das Risiko, da er die Software eigenverantwortlich einsetzt. Diese Problematik ist akut, da Business-Software-Architekturen nicht mehr von Grund auf neu und aus einem Guss geschrieben und aufgesetzt werden. Architekturen bestehen aus Komponenten, die von den unterschiedlichsten Anbietern entwickelt wurden. Eine Gefahrenanalyse lässt sich mit Hilfe öffentlicher Datenbanken bewerkstelligen, in denen die Risiken von Open-Source-Komponenten aufgelistet sind.
• 3. Daten nach Relevanz trennen: Grundsätzlich sollten sich Unternehmen Gedanken machen, welche Daten und Anwendungen sinnvollerweise in die Cloud ausgelagert werden können und welche besser on Premise im Unternehmen bleiben sollten. Handelt es sich um unkritische Informationen, steht einer Cloud-Verwendung nichts im Weg. Bei sensiblen und kritischen Daten stellt sich jedoch die Frage, ob eine Schnittstelle in die Cloud angebracht ist. Dabei sind zwei Dinge generell zu ­beachten: Bei Business-Software aus der Public Cloud stellt der Anbieter in der ­Regel die Schnittstellen vorab ein, die der Anwender dann individuell konfigurieren sollte, damit nur die unkritischen Daten mit dem Internet verbunden sind. Darüber hinaus kann aber auch der Cloud-Betreiber in die Verantwortung genommen werden, denn grundsätzlich haftet er für die Sicherheit der Daten.
• 4. Verschlüsselung der kritischen Daten: Durch die in Service Level Agreements vertraglich geregelten Sicherheitsvorkehrungen kann ein Anbieter für Schäden durch Sicherheitslücken haftbar gemacht werden. Doch selbst wenn der Cloud-­Betreiber höchste Sicherheit verspricht, bleibt immer ein Restrisiko. Daher bietet es sich an, die kritischen Unternehmensdaten zu verschlüsseln, bevor sie in die Public Cloud ausgelagert werden. Eine ­Bearbeitung der Daten erst in der Public Cloud ist nicht möglich, weil das eine Entschlüsselung in der IT-Wolke voraussetzt, was die Verschlüsselung ad absurdum führen würde. Kritische Daten sollten deshalb nicht mit Business-Software aus der Public Cloud bearbeitet werden.
• 5. Mobile Geräte richtig sichern: Mit der zunehmenden Verwendung von Smart Devices im Unternehmensumfeld und der Entwicklung von Business-Software-Apps werden mobile Endgeräte ebenfalls zu ­einem Sicherheitsrisiko. Denn ob eine App auf das Internet zugreift und die Daten damit einem möglichen Angriff ausliefert, bestimmt die Vorkonfiguration, die der Anwender nicht beeinflussen kann. Deshalb wurden zum Schutz kritischer Daten Zusatzdienste entwickelt, die das Gerät in zwei Sicherheitszonen teilen und aus ­einem Smart Device virtuell zwei Geräte machen. Die private Zone ist nicht gesichert und quasi öffentlich zugänglich. Dort werden die Apps installiert. In der zweiten Zone, der Unternehmenszone, lassen sich dagegen keine Applikationen aufspielen. Dieser gesicherte Bereich hält ein gehärtetes Betriebssystem und die kritischen Daten vor.
• 6. Security-Response-Plan: Trotz aller Sicherheitsmaßnahmen sollten sich Unternehmen auch auf den Ernstfall vorbereiten. Es muss ein Plan B, ein Security-Response-Plan, vorliegen, damit für den Notfall festgelegt ist, mit welchen Aktionen auf einen eingetretenen Angriff reagiert werden soll. Diese zweite Verteidigungslinie dient der Schadensbegrenzung, denn in solchen Situationen ist es maßgeblich, schnell und richtig zu reagieren.

* Der Autor Harald Schöning arbeitet als Head of Research bei der Software AG.