Wolkig, aber zuverlässig: Reise in die Zukunft mit einer sicheren Cloud Basis

Deine Reisebegleiter: Die Werkzeuge zum Absichern der Cloud Plattform

Eine Möglichkeit ist die Nutzung von Tools und Services, die ein Hyperscaler out-of-the-box zur Verfügung stellt. So können sogenannte Security Recommendations den Anwender eines Cloud Services unterstützen. Diese Empfehlungen sind meist kategorisiert, so dass die Severity eines Sicherheitsrisikos angegeben ist. Ein Beispiel für eine solche Anwendung ist “Microsoft Defender for Cloud”, welche auf der Azure Cloud von Microsoft eingesetzt wird. Allgemein werden diese Anwendungen als Cloud Native Application Protection Platforms (CNAPP) bezeichnet.
Ist das Sicherheitsrisiko erst einmal identifiziert, sollte im Anschluss eine Einschätzung und gegebenenfalls eine Reaktion stattfinden. Hierfür bietet sich klassischerweise eine zentrale SOAR (Security Orchestration, Automate, and Response) Plattform an. Mithilfe dieser können verschiedene Security Tools, Systeme und Datenquellen in eine zentrale Umgebung integriert werden. Anhand der gesammelten Daten können spezifizierte Aktionen erfolgen. Im einfachsten Fall sind das Benachrichtigungen über Kanäle wie E-Mail oder Telefon. Im komplexeren Fall ist das ein technisch automatisiertes Eingreifen, um den betroffenen Cloud Service umzukonfigurieren (siehe Abb. 2).

Eine weitere Möglichkeit, eine sichere Cloud Foundation aufzubauen, ist der Einsatz von festen Leitplanken, die jedoch zu Einschränkungen in der alltäglichen Entwicklung für Applikations-Teams führen können (siehe Abb. 3). Hyperscaler bieten auf unterschiedliche Art und Weise die Möglichkeit, Konfigurationen auf ihren Plattformen einzuschränken. Namentliche Beispiele sind Azure Policies bei Microsoft Azure, Service Control Policies bei Amazon Web Services oder das Security Command Center bei der Google Cloud Platform. Alle drei haben die Gemeinsamkeit, ungewollte Konfigurationen durch Entwickler anhand harter Verbotsregeln zu verhindern. So kann beispielsweise vermieden werden, dass Daten in Rechenzentren unerwünschter Regionen gelangen. Eine Region kann unerwünscht sein, da die Rechtsgrundlage in jedem Land unterschiedlich ist. Zudem kann es aus der eigenen Unternehmung Standards zur Datenhaltung geben, die Daten nur in vorgeschriebenen Ländern erlauben.

Neben individuellen, benutzerdefinierten Regeln kann auch ein standardisierter Ansatz gewählt werden. So bietet der sogenannte “CIS Benchmark” für Cloud Provider vom Center for Internet Security eine effektive Möglichkeit einen vorgefertigten Standard für seine Cloud Plattform anzuwenden.  Bei richtiger Umsetzung erreicht man so eine sichere Plattform, die zu verschiedenen anerkannten Internet-Security Standards konform ist, wie zum Beispiel zum NIST Cybersecurity Framework (CSF) und NIST SP 800-53 oder den ISO 27000 Standards. Gerade für Unternehmen mit sensitiven Daten, die am Anfang ihrer Cloud Journey stehen, kann dies auch ein Ansatz sein, sicherer in der Public Cloud anzukommen.

Die passende Reiseorganisation: Organisationsstrukturen für die Public Cloud

Neben den technologischen Herausforderungen, die der Weg in die Public Cloud mit sich bringt, muss auch die Organisationsstruktur überdacht werden. Meist wird ein sogenanntes Plattform Team gegründet. Neben dem Aufbau und der Weiterentwicklung der Cloud Foundation fungiert das Team als Unterstützer für Applikations Teams, welche auf der Cloud ihre Applikationen entwickeln. Zudem ist es meist stark mit einem dedizierten Security Team verflochten oder gar zusammengelegt, um Security Anforderungen zu recherchieren, umzusetzen und auch Bewusstsein bei allen Stakeholdern zu schaffen. Dabei ergänzen sich das technisch versierte Plattform Team und das Security Team, welches den Fokus auf Sicherheit und Compliance legt. So können Synergien aus beiden Bereichen genutzt werden. Schliesslich teilt sich die Security Verantwortung auf Security, Plattform und Applikations Teams auf.

Nach Norden oder doch in den Süden: Zentrale Security, dezentrale Security - Was ist der richtige Ansatz?

Traditionell ist Security eher zentral organisiert. Alle Security-Events im Unternehmen werden an ein zentrales Security Team gesendet, welches diese analysiert und mitigiert. Ebenso wird das Schwachstellen-Management von zentraler Stelle verwaltet. Das Security Team profitiert dabei von einem grossen Erfahrungsschatz, Prozesse sind gut etabliert und Security-Events werden strukturiert behandelt.
Die Cloud bietet den immensen Vorteil von höherwertigen Services (PaaS/FaaS/SaaS), Applikations Teams werden agiler und die Time-to-market wird kürzer. Schnellere Entwicklungszyklen bedeuten aber auch sich wandelnde Architekturen und Komponenten. Das bringt das zentral organisierte Security Team an seine Grenzen. Gegenüber einer eher statischen Infrastruktur und Plattform in einer On-Premises-Landschaft, kann es für ein zentrales IT Security Team schwierig werden, das notwendige Know-how in einer sich stetig verändernden Cloud-Umgebung mit einer Vielzahl von eingesetzten Technologien und Services aufrechtzuerhalten.
Demgegenüber steht ein dezentral organisiertes Security-Operations-Modell, in welchem Applikations Teams die volle Verantwortung für den sicheren Betrieb ihrer Applikationen haben. Dies hat einerseits den Vorteil, dass Applikations Teams den Business-Impact von Security-Events besser abschätzen können. Andererseits kennen diese die eingesetzten Technologien bestens und können so bei einem Incident schnell und effektiv Massnahmen einleiten. Genauso wie ein Applikations Team in einer DevOps-Organisation bei der Entwicklung mehr Bewusstsein für betriebliche Aspekte entwickelt, gilt dies auch für die Security. Die Security-Awareness nimmt zu und die Security ist bereits in der Entwicklungsphase ein wichtiger Bestandteil - Shift Left und DevSecOps-Prinzipien werden gelebt.
Aber auch hier gilt es, die Vor- und Nachteile zu erwägen. Eine komplett dezentral organisiertes IT Security Team birgt jedoch die Gefahr, dass Erkenntnisse aus Security-Events nicht dem gesamten Unternehmen zu Gute kommen. Warum also nicht das Beste aus beiden Ansätzen wählen?

Eine Rundreise: Das Beste aus beiden Ansätzen

Unternehmen entscheiden sich oftmals für ein hybrides Security-Operations-Modell, um die Vorteile beider Ansätze bestmöglich zu nutzen. AWS bezeichnet ein solches hybrides Modell als "Global monitoring, local response". Die Applikations Teams bringen das notwendige Fach- und Technologiewissen mit, um den konkreten Impact von Security-Events abzuschätzen sowie geeignete Massnahmen umzusetzen. Das zentrale Security Team steht unterstützend zur Seite und behält die Security Posture des Unternehmens im Überblick.
Nachfolgend demonstrieren wir ein mögliches Security-Betriebsmodell, welches folgende Ziele verfolgt:

• Sichtbarkeit der Security-Posture in der Cloud
• Fähigkeit, schnell und effektiv auf Security-Events reagieren zu können
• Hilfestellungen, damit Dev-Teams ihre eigenen Security-Entscheidungen treffen können

Aus der Cloud Governance sowie Hyperscaler- und Industry-Best Practices definiert ein zentrales Security Team Leitplanken und Guidelines und kümmert sich um deren technische Umsetzung. Ziel ist es, die Security-Posture der Organisation, aber auch der einzelnen Applikationen sichtbar zu machen (siehe Abb. 4). Die Security-Posture wird häufig mittels eines Security-Scores beurteilt, eine Kombination aus Anzahl Security-Findings und deren Severity, um einen Grobüberblick zu geben. Entscheidend ist, dass Vorgaben kontinuierlich automatisiert geprüft werden und potentielle Schwachstellen zeitnah adressiert werden können. 
Diese kontinuierliche Prüfung der Konformität gegenüber Vorgaben und Best-Practices stellt sicher, dass die Plattform und Applikationen optimal vor Angriffen geschützt sind. Hinzu kommt der Einsatz von Threat-Detection-Services, welche Auffälligkeiten in Logs detektieren und alarmieren. 
Ein Grundpfeiler zur zeitnahen und effektiven Abwicklung von Security-Incidents ist auch hier die Zusammenarbeit zwischen Security und Applikations Teams. Das Applikations Team untersucht Security-Events, bewertet diese und leitet bei Bedarf entsprechende Massnahmen zur Mitigation ein. Die zentrale Security-Operations steht bei Bedarf in der Analyse unterstützend zur Seite. Die Erkenntnisse fliessen in beide Teams zurück, die Security-Posture kann weiter gestärkt werden und Detection-Prozesse werden optimiert. 
Ein kritischer Aspekt für den Erfolg des hybriden SecOps-Modell ist die klare Regelung der Zuständigkeiten (z.B. mit Hilfe einer RACI-Matrix) sowie geregelte Kommunikationswege.

Das Plattform Team übernimmt hierbei eine zentrale Rolle bei einer DevSecOps Organisation, nämlich die des Enablers. Sie legt genau so viele Regeln auf wie nötig, aber ermöglicht so viel Spielraum und Freiheit, wie möglich.
Ein gutes Praxisbeispiel ist der Trade-off für die Anwendung von Verbotsregeln. Denn eine Plattform, auf der die Funktionsentwicklung von Applikationen so eingeschränkt wird, dass sie kaum mehr möglich ist, ist genauso wenig zielführend wie eine Plattform, auf der alles erlaubt ist und Sicherheit nicht gelebt wird. Das richtige Mass an Eigenverantwortung der Applikations Teams gepaart mit der Unterstützung von Plattform und Security Team sowie umgesetzte Verbotsregeln kann die passende Mischung für eine erfolgreich nutzbare und sichere Cloud Plattform sein. 

Fazit: Security ist Teil jeder Zukunftsreise, in der nur als Team das Ziel erreicht werden kann

Das Thema Security begleitet den IT-Engineer wahrscheinlich schon sein ganzes Arbeitsleben. Doch gerade mit den schier unendlichen Möglichkeiten in der Public Cloud wird das Thema relevanter denn je. Mit einer einfachen, leicht übersehbaren Checkbox einer Cloud Service Konfiguration kann eine riesige Sicherheitslücke in die IT-Infrastruktur eines Unternehmens gerissen werden. In früheren Zeiten war die Vermeidung solcher Sicherheitslücken immer Aufgabe eines dedizierten zentralen Security Teams. In den Zeiten der Public Cloud und DevSecOps verteilt sich die Verantwortung auf mehrere Schultern. So ist für eine sichere Cloud Foundation und deren darauf befindlichen Applikationen von höchster Bedeutung, ein breites Bewusstsein und Akzeptanz für Security innerhalb der Organisation zu erreichen. Denn Cybersecurity betrifft jeden und jede. 

Quellen

https://learn.microsoft.com/en-us/compliance/regulatory/offering-cis-benchmark

https://www.cloudmagazin.com/2022/01/28/sicherheitsrisiko-cloud-fehlkonfiguration/

https://www.cisecurity.org/cis-benchmarks

https://www.techtarget.com/searchsecurity/feature/Cloud-security-policy-configuration-in-AWS-Azure-and-GCP

https://aws.amazon.com/blogs/security/considerations-for-security-operations-in-the-cloud/