Der sichere Weg in die Cloud [Teil 2]

Im ersten Teil unserer zweiteiligen Blogreihe beleuchteten wir generelle Aspekte zu Cloud-Anbietern, -Modellen und -Architekturen sowie den Verantwortlichkeiten bei der Nutzung von Cloud-Services. Erinnern Sie sich noch daran? Im zweiten Beitrag erfahren Sie, worauf Sie bei der Umsetzung Ihrer Cloud-Umgebung achten müssen, damit die Business-Anforderungen und die Sicherheit gleichermassen abgedeckt werden können.

Die «Egregious Eleven» – oder die 11 ungeheuerlichen Risiken der Cloud

Es wäre ein fataler Fehler, sich bei der Sicherheit der Daten in der Cloud nur auf den Anbieter zu verlassen. Unternehmen sind gut beraten, sich selbst ebenfalls um dieses Thema zu kümmern. Die folgenden elf Bedrohungen von der «CSA – Cloud Security Alliance» – als «Egregious Eleven» bezeichnet – stellen generell die aktuelle Risiko-Situation mit Cloud-Services dar:

Data Breaches: Daten-Lecks und -diebstähle mit Bereicherungsabsicht des Täters und/oder anschliessender Veröffentlichung.
Misconfiguration & Inadequate Change Control: Unsicher konfigurierte Cloud-Services oder Schwachstellen durch unangemessen verwaltete Änderungen.
Lack of Cloud Security Architecture & Strategy: Ungenaue Spezifikation der notwendigen Cloud-Security-Architektur sowie keine oder unangemessene Strategie zur Nutzung von Cloud-Services in Unternehmen.
Insufficient Identity, Credential, Access & Key Management: Schon im eigenen Betrieb On-Premise zu betreiben, ist eine Herausforderung. Dadurch wird das IAM (Identity & Access Management) in der Cloud zur kritischen Komponente, insbesondere auch bezüglich des Managements von kryptographischen Schlüsseln.
Account Hijacking: Die Entführung bzw. unberechtigte Fremdnutzung von Benutzer-Accounts durch (externe) Angreifer.
Insider Threat: Die Bedrohungen von Insidern beim CSP (Cloud Service Provider) sowie im eigenen Unternehmen, v.a. Mitarbeitende und Partner (Drittparteien wie Subcontractors, Lieferanten etc.).
Insecure Interfaces & API: Unsichere Schnittstellen und APIs (Application Programming Interfaces) sind ein generelles Problem. Gründe dafür sind unter anderem unsichere Konfigurationen, schwaches Hardening oder unsachgemässer Betrieb.
Weak Control Plane: Die Steuerung der Cloud-Services erfolgt über die «Cloud Control Plane». Entsprechend muss der Fokus auf der Sicherheit und Stabilität dieser Schicht gelegt werden. Wenn diese nicht entsprechend abgesichert wird, könnten administrative Privilegien der Cloud-Administrationskonsolen von einem Angreifer missbraucht werden.
Metastructure & Applistructure Failures: Mangelhafte oder unangemessene Abgrenzung der Verantwortlichkeiten auf der Trennlinie bei den verschiedenen Service-Modellen (mehr dazu finden Sie im ersten Artikel).
Limited Cloud Usage Visibility: Unvollständige oder inkorrekte Visibilität der (tatsächlichen) Nutzung von Cloud-Services – Stichwort «Shadow IT» durch Geschäftseinheiten, Abteilungen und Teams.
Abuse & Nefarious Use of Cloud-Services: Missbrauch oder unzweckmässige Nutzung von Cloud-Services, was für Kunde und CSP gleichermassen riskant ist. Beispiel: Wenn Kunden sich nicht an den vereinbarten Nutzungszweck halten und gegebenenfalls illegale Funktionen auf der Infrastruktur des CSP ausführen. Das kann sich auch auf andere Kunden auswirken, beispielsweise bei einem behördlichen Einsatz wie Beschlagnahmung von Systemen beim CSP.

Der sichere Weg in die Cloud

Dies sind die häufigsten Bedrohungen bei der Nutzung von Cloud-Services für Unternehmen. Bevor Sie also irgendeinen Service in die Cloud umsiedeln, sollten Sie sich über all diese Faktoren Gedanken machen. Die anschliessende Migration braucht eine Kooperation zwischen Ihnen als Kunde und dem Cloud Provider, um maximale Sicherheit zu gewährleisten.

Auf dem sicheren Weg in die Cloud gibt es verschiedene Meilensteine, die idealerweise vor Reisebeginn analysiert und festgelegt werden:

- Identifizieren und Erheben rechtlicher Anforderungen
  Nebst den klassischen gesetzlichen Anforderungen, zu einem guten Teil bestehend aus dem Datenschutzgesetz und Obligationenrecht/Vertragsrecht (nicht alle Verträge bzw. AGB von internationalen Anbietern sind je nach Vertragsverhältnis für schweizerische Verhältnisse angemessen), sind auch allfällige regulatorische Anforderungen zu klären – und nicht zu vergessen die individuellen Vereinbarungen mit Kunden und Lieferanten, die sogenannten «Contractual Obligations». Vielleicht dürfen Daten aus gesetzlicher und regulatorischer Perspektive in einem Cloud-Service bearbeitet werden, aber nicht aufgrund einer entsprechenden, individuellen vertraglichen Vereinbarung!
- Datenklassifizierung
  Die Klassifikation ist wichtig, um festzulegen, welche Daten überhaupt in die Cloud dürfen und in welcher Form diese geschützt werden müssen – und zwar vor dem «Go-to-Cloud». Dabeisind nicht nur die Vertraulichkeit, sondern auch die Verfügbarkeit sowie allenfalls Integritäts-Anforderungen zu spezifizieren und auf die Datensammlungen anzuwenden. Denken Sie dabei auch an den Daten-Lebenszyklus, den wir im ersten Artikel beschrieben hatten. Denn von der Entstehung bis zur Entsorgung der Daten liegt die Verantwortung für die Sicherheit bei Ihnen! Aber Achtung: Die Klassifikation der unstrukturierten Datenbestände kann möglicherweise einiges an Zeit in Anspruch nehmen.

- Definition der Cloud (Security)-Architektur
  Wie und zu welchem Zweck sollen zukünftig welche Cloud-Services genutzt werden? Definieren Sie die notwendige Architektur und die Schnittstellen zu internen/On-Premise Systemen sowie Applikationen frühzeitig – idealerweise natürlich nicht «am laufenden Projekt» oder auf Basis einer Applikation, die in die Cloud-Services integriert werden soll. Sonst laufen Sie Gefahr, dass die Cloud-Architektur sich um eine einzelne Applikation dreht, anstatt eine generische und zweckmässige Basis für den unternehmensweiten Cloud-Einsatz dazustellen.
- Evaluation der möglichen CSP
  Bei der Evaluation gibt es nicht nur die «üblichen Verdächtigen». Neben den Giganten (auch «Hyperscaler» genannt; vornehmlich aus den USA mit entsprechender Wirkung durch US Patriot Act und US Cloud Act auf die angebotenen Cloud-Services), gibt es auch viele mittelständische und kleinere Anbieter. Führen Sie eine systematische Evaluation durch und lassen Sie die Sicherheitsaspekte dabei nicht zu kurz kommen.
- Vergessen Sie das Fokus-Thema «Identity & Access Management» (IAM) nicht
  Spezifizieren Sie zudem neben dem Daten-Lebenszyklus auch unbedingt ein zweckmässiges Key Management. Und bedenken Sie: Auch Cloud-Services können ausfallen. Deshalb ist auch hier eine Backup-Strategie notwendig, um die Daten bei einem Ausfall ausreichend zu sichern!
- Behalten Sie die Cloud im Griff
  Und zu aller Letzt noch ein Thema, das gerne «etwas später» zum Zuge kommt – leider oft mit einer Ernüchterung hinsichtlich Erwartungen: Reporting, Service Level Monitoring, Capacity- und Security Monitoring sowie Integration in die eigenen oder die Managed Security Services (SOC, CDC).
  
  Cloud-Service-Providers bieten oft bereits eigene Dashboards und Berichte an. Aber decken sie auch alles ab, was Sie benötigen? Können Sie auf die Rohdaten (Events) und auf die Systeme selber zugreifen zwecks Monitoring, oder müssen Sie mit dem Vorlieb nehmen, was angeboten wird (inkl. Layout)? Eine nachträgliche (manuelle) Integration in das Enterprise Reporting ist bei Cloud-Services ein nicht zu unterschätzender Komplexitäts- und Aufwandfaktor.
- Und wenn wir schon beim Thema sind: Auch Cloud Security Event/Incident Management, Security/Penetration Testing und «Cloud Forensics» müssen vor dem GO geregelt werden.

Zertifizierungen, Standards und Frameworks

Um das Leben von Cloud-Verantwortlichen im Unternehmen etwas angenehmer zu gestalten, gibt es diverse Zertifizierungen und Attestierungen, an denen man sich orientieren kann. Die bekanntesten sind ISO 27001 – mit der Ausprägung ISO 27017 (Cloud Security) – und ISO 27018 zur Verarbeitung von personenbezogenen Daten in Cloud-Services, speziell für CSP.

Bei den Attestierungen gibt es die SOC 2 (Service Operator Controls) Reports, mit dem Typ 1 (Accuracy & Completeness, Suitablity of Controls) und Typ 2 (wie Typ 1, aber zusätzlich «Operational Effectiveness Throughout Period»), unter dem Standard ISAE 3402 oder ISAE 3000. Die CSA (Cloud Security Alliance) bietet mit dem STAR-Programm (Security Trust & Assurance Registry) insgesamt drei Stufen eines Audits an, mit dem die Sicherheit und auch die Einhaltung von Datenschutz-Anforderungen belegt werden kann.

Cloud-Sicherheit geht nur gemeinsam

Klar, für Sie ergeben sich dadurch neue Herausforderungen, zumal auch die Compliance-Anforderungen immer strenger werden. Aber genau dieser Nachweis kann mit einer Hybrid- oder Multi-Cloud schwierig sein. So gilt es nicht nur sicherzustellen, dass On-Premise, Public Cloud und Private Cloud Compliance-konform sind. Es muss auch nachgewiesen werden, dass die Koordinationsmöglichkeiten zwischen den Clouds gewährleistet und sicher sind. Multi-Cloud-Umgebungen erfordern deshalb einen plattformunabhängigen und standardisierten Sicherheitsansatz. Der Provider und Sie als Kunde teilen sich dabei die Zuständigkeiten auf, wobei der Provider für den Betrieb sowie die Sicherheit der physischen Umgebung verantwortlich ist und Sie für die logische Umgebung.

Starten Sie mit einer klaren Sicht auf Ihre Cloud

Die Nutzung von Cloud-Services ist ein kritischer Erfolgsfaktor. Lassen Sie sich von den Herausforderungen jedoch nicht abschrecken! Wenn Sie die Anforderungen und Vorgaben berücksichtigen, bieten Hybrid- und Multi-Cloud-Umgebungen grosses Potenzial, das Sie nutzen sollten.

Wissen Sie, welche Cloud-Services in Ihrem Unternehmen bereits im Einsatz sind?

Unsere Erfahrung zeigt, dass häufig Cloud-Services für spezifische Projekte oder in Abteilungen genutzt werden, von denen die IT-Abteilung gar nichts weiss. Unser Cloud Access Audit verschafft Ihnen die volle Transparenz und zeigt die damit verbundenen Risiken klar und übersichtlich auf. Hier erfahren Sie mehr!