Wozu überhaupt Cloud-Dienste zertifizieren?
Der Trend, dass immer mehr Unternehmen in die Cloud ziehen, ist keineswegs neu, aber bleibt weiterhin ungebrochen. Auch kleine und mittelständische Unternehmen überlegen immer öfter, die Cloud zu nutzen – hauptsächlich aus Kostengründen[4].
Dabei stellt sich die Frage, warum ein Unternehmen überhaupt ein Zertifikat für die Sicherheit seiner Cloud-Dienste braucht. Wir sehen die folgenden drei Hauptgründe:
- Vertrauen der Kunden: Ein Unternehmen kann bei seinen Kunden Vertrauen aufbauen, wenn es nachweist, dass es die einschlägigen Standards der Branche erfüllt, z. B. indem es auf seiner Website die entsprechenden Siegel anführt.
- Vertragliche Pflichten: Ein häufiger Grund für die Zertifizierung heute ist, dass Kunden voraussetzen, dass ihre Partner bestimmte Zertifizierungskataloge erfüllen.
- Gesetzgebung: Nationale oder länderübergreifende (z. B. in der EU) Rechtsvorschriften verpflichten Unternehmen in bestimmten Bereichen zur Einhaltung der jeweiligen Standards. Im folgenden Abschnitt nehmen wir daher das europäische Zertifizierungssystem genauer unter die Lupe.
Standardisierung in der EU
In Sachen Sicherheitszertifizierung schlagen wir in der EU gerade einen neuen Weg ein. Aktuell haben wir europaweit einen regelrechten Flickenteppich an Standards. Jeder Mitgliedsstaat hat seine eigenen Standards für bestimmte Bereiche. In Deutschland gibt es zum Beispiel den Kriterienkatalog Cloud Computing Compliance Criteria Catalogue (C5) für den Cloud-Bereich oder das Medizinproduktegesetz (MPG)[5] für medizinische Geräte.
Während letzteres bereits formell durch die neue europäische MDR (Medical Devices Regulation)[6] abgelöst wurde, ist der C5 immer noch der Standard für Cloud Computing in Deutschland. Dies dürfte sich allerdings ändern, denn mit dem European Cybersecurity Certification Scheme for Cloud Services (EUCS) steht bereits ein neuer EU-Kandidat in den Startlöchern.
Es gibt zwei wesentliche Treiber für das EUCS: Der EU Cybersecurity Act[7] und der EU Cyber Resilience Act[8].
Der Cybersecurity Act ist seit 2019 in Kraft und schafft einen einheitlichen Rahmen für Sicherheitszertifizierungen auf EU-Ebene. Auf Grundlage von Artikel 48 dieses Gesetzes schlägt die Agentur der Europäischen Union für Cybersicherheit (ENISA)[9] ein europäisches Schema für die Cybersicherheitszertifizierung vor, das EUCS. Dabei handelt es sich um einen Sicherheitskatalog für Cloud-Dienste. Einer seiner Hauptbezugsquellen ist der C5. Wie bei den Medizinprodukten soll das EUCS nationale Standards ersetzen.
Die Zertifizierung ist allerdings keine Pflicht – zumindest noch nicht. Auf (physischen) Produkten kennen wir europaweit das CE-Label, das bestätigt, dass das Produkt „die EU-Anforderungen an Sicherheit, Gesundheits- und Umweltschutz erfüllt“. Mit dem Gesetzesvorschlag für den EU Cyber Resilience Act (CRA) will die EU diesen Ansatz ab 2025 analog auf digitale Produkte übertragen. Per Definition fallen darunter Produkte, die zumindest einige „digitale Elemente“ aufweisen. Gemeint sind also reine Software- oder Hardwareprodukte. Ein solches Label soll Vertrauen stärken, die Sicherheit von EU-Produkten erhöhen und mehr Transparenz für EU-Bürgerinnen und -Bürger schaffen.
Die Ambition des Gesetzesvorschlags, Sicherheitsstandards nachzuweisen und für mehr Transparenz für Kunden zu sorgen, ist bereits ein deutliches Zeichen dafür, dass Cybersicherheitszertifizierungen Teil eines größeren Ganzen sind. Außerdem soll der Vorschlag mit anderen EU-Vorschriften, z. B. dem EU Cybersecurity Act, zusammenwirken, der ja, wie wir gerade erfahren haben, wiederum den Vorschlag für das EUCS enthält.
Zertifizierung heute (Überblick)
Schauen wir uns anhand eines Beispiels einmal genauer an, wie eine Zertifizierung abläuft. Ein internationales Unternehmen – nennen wir es HyperIoT – betreibt einen industriellen IoT-Cloud-Dienst. Damit der Dienst in verschiedenen Ländern verlässlich und ausfallsicher verfügbar ist, nutzt es unterschiedliche öffentlich zugängliche Cloud-Anbieter, darunter Microsoft Azure und Amazon Web Services (AWS). Diese Anbieter stellen eine Vielzahl von Ressourcen zur Verfügung, wie virtuelle Maschinen (VMs), Speicher, Netzwerke und Funktionen, wobei jeder Anbieter über Zehntausende dieser Ressourcen verfügt.
Viele Logistikunternehmen sind überzeugt, dass sie mit diesen Diensten ihre Produktivität steigern können, sei es beim Asset-Tracking oder beim Flottenmanagement. Gemäß ihren Richtlinien muss HyperIoT jedoch mit dem EUCS konform sein, um z. B. sicherzustellen, dass ihre Daten sicher verarbeitet werden. Der Zertifizierungsprozess könnte wie folgt aussehen:
Da für die Zertifizierung Aspekte der Informationssicherheit eine Rolle spielen, ist der Chief Information Security Officer (CISO) von HyperIoT verantwortlich.
Damit es erfolgreich verläuft und der Berg an Dokumentation bewältigt werden kann, empfiehlt es sich, die Unterstützung Dritter hinzuzuziehen. Deswegen beauftragt HyperIoT für die Zusammenstellung der notwendigen Informationen, Nachweise und Unterlagen für das Audit sowie für die korrekte Abwicklung der Formalitäten einen Berater.
Der CISO kann die unzähligen Aufgaben unmöglich allein bewältigen. Weiteres Personal wird zur Unterstützung hinzugezogen. Der CISO, der Berater und andere beteiligte Mitarbeitende stehen in ständigem Austausch und treffen sich regelmäßig, um das weitere Vorgehen zu besprechen und zu klären, was verbessert werden muss.
Erst wenn alle erforderlichen Nachweise gesammelt und die Unterlagen fertig sind, ist es Zeit für das eigentliche Audit. Dafür kommt ein Auditor in das Unternehmen und prüft die gesammelten Informationen wie Dokumente zu Richtlinien und Ressourcenkonfigurationen stichprobenartig.
Kann der Zertifizierungsprozess automatisiert werden?
Üblicherweise laufen die Vorbereitung auf das Audit und das Audit selbst nicht automatisiert ab. Vielmehr ist es üblich, die Nachweise bei der Auditvorbereitung in riesigen Excel-Tabellen zu sammeln. Wo bisher viele Zertifizierungsanforderungen die automatisierte Erfassung und Bewertung von Nachweisen erschweren, verlangen neuere Standards, wie z. B. das kommende EUCS, sogar ausdrücklich das automatisierte Monitoring einiger technischer Anforderungen. Wir sind der festen Überzeugung, dass die Automatisierung unverzichtbar ist:
- Bei der manuellen Auditvorbereitung schleichen sich unweigerlich Fehler ein. Weil zahlreiche Personen beteiligt sind, spielt auch der Faktor Mensch eine Rolle. Beim Zusammentragen großer Mengen von Nachweisen und ihrer Erfassung in Excel-Tabellen sind menschliche Fehler vorprogrammiert.
- Auditvorbereitungen sind teuer. Wie in der Abbildung oben zu sehen ist, dauert die Vorbereitung auf ein Audit etwa drei bis fünf Monate, in denen das beteiligte Personal Nachweise zusammentragen und erstellen muss, anstatt seine reguläre Arbeit zu erledigen. Dem Unternehmen entstehen also hohe Kosten.
- Die Arbeitsweise ist angesichts künftiger EU-Verordnungen nicht zukunftsfähig. Der größte Nachteil der manuellen Auditvorbereitung wurde bereits erwähnt, nämlich die Gesetzeslage des CRA. In der aktuellen Fassung des EUCS sehen einige Anforderungen ein kontinuierliches Monitoring von Cloud-Ressourcen vor. Branchenexpertinnen und -experten sind sich einig: In der EU erteilte Zertifizierungen werden im CRA eine wesentliche Rolle spielen. Und selbst wenn der CRA das EUCS nicht einschließen würde, ersetzt es wahrscheinlich die nationale Zertifizierungskataloge. Das bedeutet, dass deutsche Unternehmen, die heute C5-konform sind, höchstwahrscheinlich versuchen werden, „morgen“ mit dem EUCS konform zu sein. Die Forderung nach einem „kontinuierlichen Monitoring“ der Assets eines Unternehmens würde eine Auditvorbereitung im klassischen Sinne, also eine einmalige manuelle Vorbereitung, schlicht unmöglich machen.
- Der Faktor „Schlaf“ des CISO (wie wir es nennen). Eine nicht zu vernachlässigende Tatsache, die wir in unseren Projekten und in Gesprächen mit CISOs beobachten, ist, dass CISOs jederzeit einen umfassenden Überblick über ihre aktuellen (Multi-)Cloud-Setups brauchen. In einer Welt sich schnell wandelnder Cloud-Systeme ist das händische Zusammentragen von Unterlagen für ein Audit, das alle zwei Jahre stattfindet, schlicht nicht zielführend. Automatisierte Prozesse lassen CISOs ruhig schlafen – im Wissen, dass ihr Unternehmen jederzeit für ein Audit bereit ist.
Automatisierte Prozesse sind also nicht nur sinnvoll, um die Sicherheit zu steigern und Kosten zu sparen, sondern sie werden vermutlich auch schon bald gesetzlich verpflichtend sein. Und genau hier kommt der Clouditor ins Spiel. Selbst er kann zwar nicht den gesamten Zertifizierungsprozess automatisieren. Zum Beispiel muss das eigentliche Audit Stand heute noch durch einen geprüften Auditor durchgeführt werden. Wir können auch nicht den kompletten Vorbereitungsprozess ersetzen, da es immer Nachweise geben wird, die nicht automatisiert beschafft werden können. Ein Beispiel dafür ist die „physische“ Sicherheit. Aber auch für diese Fälle haben wir eine (teil-automatisierte) Lösung im Sinn; dazu später mehr.
Unsere Lösung: Der Clouditor
Wir entwickeln den Clouditor, um die Auditvorbereitung so weit wie möglich zu automatisieren. CISOs sollen die Vorteile des kontinuierlichen Monitorings ausschöpfen können und sich hohe Personalkosten sparen und menschliche Fehler vermeiden. Und natürlich sollen sie sicherstellen können, dass ihr System jederzeit für ein Audit gewappnet ist.
Wie oben angekündigt, lassen sich nicht alle Nachweise automatisch abrufen. Für technische Nachweise, die sich automatisch erfassen lassen, ist der Clouditor jedoch die passende Lösung. Im Folgenden beschreiben wir kurz die Architektur und Funktionalität unseres Tools, veranschaulicht durch unser Anwendungsbeispiel.
Der Clouditor folgt einer Microservices-Architektur. In der folgenden vereinfachten Übersicht über den Clouditor stellt jeder ovale Kasten einen Microservice dar:
Über die APIs der jeweiligen Cloud-Systeme oder der Instanziierungen der Container-Orchestrierungsplattform Kubernetes[10] (oben im Bild) überprüft der Clouditor die Konfigurationen der in diesen Systemen bereitgestellten Ressourcen. Konkret übernimmt ein systemspezifischer Discoverer diese Aufgabe. Die gesammelten Informationen (also Konfigurationen) werden dann als gespeichert. Diese Nachweise sind in einem einheitlichen Format gehalten, das auf einer Ontologie zur Beschreibung von Cloud-Ressourcen basiert; siehe dazu auch die Arbeit von Banse et al.[11]. Diese Abstraktion ermöglicht es uns, Regeln zu definieren, ohne die spezifischen Details der Cloud-Systeme zu kennen (schließlich definiert jede Cloud ihre Ressourcen auf ihre ganz eigene Weise). So würden wir für eine neue Cloud-Verbindung (z. B. zur Google Cloud[12]) einen neuen Discoverer entwickeln, der die entsprechende API nutzt, die Informationen in das Ontologie-basierte Nachweisformat umwandelt und sie an die Bewertungskomponente sendet. In unserem Beispiel verwendet HyperIoT Hunderte von VMs, die über AWS und Azure verteilt sind. Unsere beiden Cloud-Discoverer, nämlich AWS Discoverer und Azure Discoverer, rufen die Konfigurationen für jede VM in der jeweiligen Cloud ab, wandeln sie in unser Nachweisformat um und leiten sie weiter. Hier ein Beispiel für einen solchen Nachweis:
{
„id“: „83f0ef13-1341-4704-89f3-c314a1b56079“,
„name“: „Location Tracker“,
„type“: „VirtualMachine“,
„resource“: {
„automaticUpdates“: {
„enabled“: true
},
„malwareProtection“: {
„enabled“: true
},
…
}
Die Bewertungskomponente evaluiert dann die eingehenden Nachweise anhand einer Reihe von Regeln. Heutzutage sind Standards in natürlicher Sprache verfasst. Daher verwenden wir bei Cloud-Zertifizierungen „Metriken“. Das sind technische Regeln, die aus den Anforderungen der jeweiligen Kataloge extrahiert werden und die Eigenschaften einer Cloud-Ressource (des Nachweises) messen. Stellen Sie sich die Metriken als eine maschinenlesbare Darstellung einer Anforderung vor, bei der eine Anforderung in einer oder mehreren Metriken gebündelt ist. Diese Metriken folgen dem Format der Ontologie und sind daher mit den von den Discoverer-Komponenten gesendeten Nachweisen konsistent. Inzwischen gibt es Ansätze, stärker auf maschinenlesbare Formate zu setzen (siehe OSCAL[13]), doch bis wir so weit sind, besteht eine unserer Hauptaufgaben noch darin, Metriken anhand von Katalogen in natürlicher Sprache zu definieren. Als Beispiel sei hier eine einfache Regel genannt, die misst, ob automatische Updates aktiviert sind (geschrieben in der Policy-Sprache Rego[14]):
compliant if input.automaticUpdates.enabled == true Hier sehen wir , wie die Ontologie vorschreibt, wie ein AutomaticUpdate-Feature vom Discoverer (der den Nachweis erstellt) gesetzt sein muss, damit bei der Bewertung die Metrik darauf angewendet werden kann (mit Punktnotation).
Die Ergebnisse der auf die Nachweise angewandten Regeln sind die Bewertungsergebnisse , die an den Orchestrator gesendet werden. Der Orchestrator ist das Herzstück des Clouditors, denn er bildet die Schnittstelle zur Außenwelt, steuert intern die Komponenten und speichert die notwendigen Informationen (Metriken, Bewertungsergebnisse und Kataloge) in einer Datenbank.
Aus Datenschutzgründen werden die Nachweise von der Bewertung an den Nachweisspeicher weitergeleitet. Die Idee, den Nachweisspeicher vom Orchestrator zu trennen, entstand, als wir uns überlegten, wie der Clouditor bereitgestellt werden könnte. Bei einer in der Cloud gehosteten Lösung oder einer Software-as-a-Service-Lösung könnten Clouditor-User den Nachweisspeicher in ihren Räumlichkeiten vor Ort hosten, um die Nachweise bei sich zu behalten.
Zu guter Letzt möchten wir, dass die User eine einheitliche Übersicht über ihre Nachweise, Bewertungsergebnisse usw. haben. Aus diesem Grund gibt es die Möglichkeit, den gesamten Zustand des Systems auf dem Dashboard einzusehen. Bei Abweichungen von Standards können wir hier nachvollziehen, welche Nachweise falsch konfiguriert sind, und entsprechende Korrekturen vornehmen.
Über die Befehlszeilenschnittstelle (CLI, Command Line Interface) können wir direkt mit dem Clouditor auf dem Terminal anstelle der GUI-Benutzeroberfläche interagieren. Weil wir in Zukunft den gesamten Zertifizierungsprozess unterstützen möchten, arbeiten wir im Forschungsprojekt MEDINA[15] bereits heute an der Automatisierung der Zertifikatspflege. Daher sind die Speicherung und Ansicht von Zertifikaten bereits möglich.
Der Clouditor der Zukunft: Nächste Schritte
Aktuell arbeiten wir daran, dass der Clouditor bei der Zertifizierung zu einer noch größeren Hilfe wird:
- Unterstützung von mehr (Cloud-)Systemen, z. B. der Google Cloud und Office 365 Security Data
- Unterstützung von weiteren Katalogen, z. B. für domänenspezifische Regelungen wie die Medical Devices Regulation als Rechtsrahmen für Medizinprodukte in der EU
- Erstellung eines Ergebnisdokuments, aus dem hervorgeht, welche Anforderungen bereits erfüllt sind und welche noch nicht. Dieses Dokument kann vom zuständigen Auditor eingesehen werden.
- Die Möglichkeit, Anforderungen zu bewerten, die nicht vom Clouditor selbst abgedeckt werden – entweder manuell über das User Interface (natürlich mit Nachweisen) oder über externe Tools, z. B. Geschäftsprozesse über bereitgestellte APIs.
Mit dem letzten Schritt würde der Clouditor den Usern so viel Arbeit wie möglich abnehmen und ihnen nur noch so wenige händische Aufgaben wie nötig aufbürden.
Fazit
Zertifizierungen sind zeitraubend und fehleranfällig. Mit unserer Lösung optimieren wir die Auditvorbereitung durch zusätzliche Automatisierung. Denn heute wird in den meisten Unternehmen fast der gesamte Zertifizierungsprozess noch manuell durchgeführt, d. h. viel Personal ist involviert.
Vergleichen wir den heutigen Prozess (siehe Bild oben) mit dem Zertifizierungsprozess mit dem Clouditor:
Mit unserer Lösung können wir die Konfigurationen in Cloud-Systemen oder in Systemen, die Kubernetes verwenden, automatisch überprüfen. Wir können sehen, welche Ressourcen bereitgestellt werden und wie ihr Compliance-Status gemäß dem gewählten Katalog ist. Zwar gibt es immer noch einige Aufgaben, die nur manuell ausgeführt werden können (obere rechte Ecke). Mit dem Clouditor sinkt die Menge dieser händischen Aufgaben jedoch deutlich, und wir entlasten die Mitarbeitenden von allen Aufgaben, die automatisiert erledigt werden können. Außerdem planen wir, externe Tools zu integrieren, um den Abdeckungsgrad von Cloud-Katalogen noch weiter zu erhöhen.
Vergessen Sie dabei nicht, dass ein Audit in regelmäßigen Abständen (z. B. jährlich) durchgeführt werden muss. Manuelle Audits fressen dann immer viel Zeit. Mit dem Clouditor lassen sich viel Zeit und Ressourcen sparen sowie menschliche Fehler reduzieren und – zu guter Letzt – kann der CISO hoffentlich ruhig schlafen.
Weitere Details zum Clouditor finden Sie auf unsere GitHub-Seite[16] und in unserem frei zugänglichen Open-Source-Repository. Oder kontaktieren Sie uns einfach! Auch Verbesserungsvorschläge sind herzlich willkommen.
Quellen
[1] https://www.bsi.bund.de/dok/13368652
[2] https://www.enisa.europa.eu/publications/eucs-cloud-service-scheme
[3] https://cloudsecurityalliance.org/research/cloud-controls-matrix/
[4] https://info.flexera.com/CM-REPORT-State-of-the-Cloud
[5] https://www.gesetze-im-internet.de/mpg/
[6] https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=uriserv:OJ.L_.2017.117.01.0001.01.ENG
[7] https://digital-strategy.ec.europa.eu/en/policies/cybersecurity-act
[8] https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
[9] https://www.enisa.europa.eu/
[11] C. Banse, I. Kunz, A. Schneider and K. Weiss, „Cloud Property Graph: Connecting Cloud Security Assessments with Static Code Analysis,“ 2021 IEEE 14th International Conference on Cloud Computing (CLOUD), Chicago, IL, USA, 2021, pp. 13-19, doi: 10.1109/CLOUD53861.2021.00014.
[12] https://cloud.google.com/
[13] https://pages.nist.gov/OSCAL/
[14] https://www.openpolicyagent.org/docs/latest/policy-language/
Autor
Nico Haas
Nachdem Nico Haas seinen Master in Informatik an der Universität Stuttgart absolvierte, schloss er sich 2021 der Abteilung Service and Application Security am Fraunhofer AISEC an.
Sein Hauptaugenmerk liegt auf der Forschung und Entwicklung im Bereich Cloud Security mit dem Schwerpunkt Continuous Cloud Security Monitoring und Certification.
