ZURÜCK

Security als Enabler für Multi-Tenant-Lösungen

Zuerst erschienen in der .public Ausgabe 02/2023

von Bernhard Weber

Viele Unternehmen sehen ihre Zukunft in der Cloud – konkreter: in SAAS-Lösungen (Software-as-a-Service). Doch kann ich als Unternehmen meinem System-, Service-, Cloud- und/oder SAAS-Provider wirklich vertrauen? Will ich meine Daten in fremde Hände geben?

Die Lünendonk-Studie 2021 „Der Markt für IT-Beratung und IT-Service in Deutschland“ zeigt, dass für 59 Prozent der darin befragten Banken und Versicherungen für die Jahre 2022 und 2023 die Cloud-Transformation, also der Umbau von Teilen der IT-Landschaft zu einer Cloud-Native-IT-Architektur, eines der wichtigsten Investitionsthemen war. 66 Prozent der in der Lünendonk-Studie des Folgejahres befragten Banken und Versicherer gaben an, dass sie ihre Software in Zukunft als SAAS bereitstellen werden.¹

SAAS ist also das neue Zauberwort. Es verspricht Zukunftssicherheit, Skalierbarkeit, Synergieeffekte, Wirtschaftlichkeit, Unabhängigkeit und vieles mehr.

Natürlich geht mit SAAS meist auch ein umfassendes Sicherheitsversprechen einher. Die meisten Provider haben längst erkannt, dass Sicherheit – je nach Ausprägung – ein Enabler, aber auch ein Show-Stopper sein kann: Natürlich kommt faktisch immer eine Übertragungsverschlüsselung für die Daten zum Einsatz. Auch werben immer mehr Provider damit, selbst für die Datenspeicherung (Persistierung) State-of-the-Art-Verschlüsselungstechniken zu verwenden. Viele Konzerne und Großunternehmen zeigen sich an dieser Stelle hocherfreut und haken ihre Governance- und Compliance- Anforderungen hinsichtlich Datenschutz, Sicherheit und Verschlüsselung als „erfüllt“ ab.

Doch so einfach ist es nicht. Dass sie hier einer Mogelpackung aufgesessen sind, wird – wenn überhaupt – erst später erkennbar: Das Problem liegt in der fehlerhaften Annahme, dass durch die Verwendung einer einzelnen Verschlüsselungsmaßnahme keine Angriffe mehr auf die Vertraulichkeit der Daten möglich sind. Dem ist aber leider nicht so.

Ein Beispiel: Ein Bitlocker-verschlüsseltes Notebook hat einen ausreichend hohen Vertraulichkeitsschutz gegen Diebstahl und Verlust. Hingegen schützt diese Verschlüsselungsart nicht gegen einen Virus (etwa über E-Mail oder USB eingefangen) und auch nicht gegen interne Administratorinnen und Administratoren, die Böses im Schilde führen. Denn im laufenden System arbeitet die Bitlocker-Ver- und Entschlüsselung quasi transparent „im Hintergrund“. Ein Blick in den File Explorer und in die Dateien verdeutlicht, dass Anwenderinnen und Anwender alles wie gewohnt sehen und bearbeiten können.

Soll heißen: Die Daten werden zwar physikalisch verschlüsselt auf die HDD/SSD abgelegt und schützen in einem ausgeschalteten System die Vertraulichkeit der Daten (etwa wenn das Notebook im Zug vergessen wurde). Wenn das System jedoch angemeldet ist, bestehen sehr viele andere Angriffsvektoren auf die Vertraulichkeit der Daten, da die Verschlüsselung faktisch nicht wahrnehmbar ist.

Entsprechendes ist bei einigen Cloud-/SAAS-Providern erkennbar: Die angepriesene Verschlüsselung wirkt oftmals nur auf der Ebene des Datenträgers. Sollten also die SSD-Platten beispielsweise aus dem Rechenzentrum des Providers gestohlen werden, wirkt die Verschlüsselung. Gegen Angriffe aus dem Internet oder durch die Administration des Providers bietet diese Verschlüsselungsart jedoch keinen Schutz.

Übrigens: Die meisten handelsüblichen SSDs bringen bereits kostenlos eine entsprechende Hardwareverschlüsselung mit. Falls gewünscht, können dann beispielsweise NAS-Systeme (Network Attached Storage) oder Bitlocker diese Hardwareverschlüsselung direkt nutzen und es entstehen keine nennenswerten Performance-Einbußen.

Welchen Schutz benötige ich für meine Daten?

Jeder gewissenhafte Sicherheitsverantwortliche stellt sich die Frage „Welchen konkreten Schutzbedarf haben unsere Unternehmensdaten, beziehungsweise uns anvertraute Daten?“ Damit ist es in einem späteren Schritt möglich, Schlussfolgerungen für das gebotene Sicherheitsniveau herzustellen. Gleichzeitig ist es auch erforderlich zu identifizieren, welche Angriffsvektoren beziehungsweise welche speziellen Bedrohungen für das Unternehmen oder für die Business oder Use Cases bestehen. Hierfür gibt es typische Dienstleistungen (etwa Schutzbedarfsfeststellung/-analyse, Bedrohungsmodellierung, IT-Risikoanalyse), die dabei unterstützen.

Die Erkenntnisse aus diesen Aktivitäten sind wesentliche Aspekte, die es mit dem Cloud- beziehungsweise SAAS-Provider abzuklären gilt. Nicht selten stehen dann Fragen im Raum, die seitens des Providers nur vage oder im Konjunktiv beantwortet werden. Beispielhafte Fragen:

• Wie sind Systeme beziehungsweise Systeminstanzen voneinander abgeschottet?
• Wie ist das übergreifende Berechtigungsmanagement ausgeprägt?
• Welche Defense-in-Depth-Maßnahmen sind etabliert?
• Welche 3rd-Party-Unternehmen haben welche Zugriffe und sind mit welchen Aufgaben betraut?
• Wie wird sichergestellt, dass der SAAS-Provider nicht in die Unternehmensdaten Einblick nimmt?
• Für welche Arten von dolosen Handlungen wurden (welche) Gegenmaßnahmen etabliert?
• Wie erfolgt das Key-Management?

Sollten einige Fragen etwa mit „organisatorische Regelungen“ oder „optionale Leistungen“ beantwortet werden, ist Vorsicht geboten:

• Möglicherweise wurden diese Aspekte beim Provider noch nicht oder zumindest nicht im gebotenen Reifegrad berücksichtigt.
• „Organisatorische Maßnahmen“ sind ein vergleichsweise stumpfes Schwert. Zudem funktionieren sie nur in einem kooperativen Ansatz. Sollten sich beispielsweise Mitarbeitende des Betriebs oder der Administration nicht an die Vorgaben halten (Stichwort „dolose Handlungen“), können die Daten schnell in fremde Hände gelangen – mit beträchtlichem Schadenspotenzial!
• Für viele Business und Use Cases (etwa im Behörden-, Banken- und Versicherungsumfeld) ist oftmals die vertragliche Zusicherung von Sicherheit nicht ausreichend (wie NDA, Administration, Schlüsselmanagement). Immer häufiger wird eine technische Forcierung von Sicherheitsmaßnahmen gefordert.

Am Ende hängt vieles vom Schutzbedarf der Daten und der Einschätzung der identifizierten IT-Risiken ab: Das Ziel sollte dabei nicht sein, ein „Maximum an Sicherheit“ herzustellen, sondern vielmehr ein angemessenes (und lebbares) Sicherheitsniveau zu etablieren.

Sich ehrlich machen …

Unter einem „angemessenen Sicherheitsniveau“ versteht jedes Unternehmen etwas anderes. Die Einflussfaktoren werden nicht nur durch Gesetze, Standards (wie ISO 27xxx, BSI, IDW PS, PCI DSS, NIST), regulatorische Vorgaben und Compliance festgelegt, sondern sind auch ein Stück weit in der Risiko-Bereitschaft (Stichwort „Risiko-Appetit“) des Unternehmens zu suchen. Selbstredend, dass nicht alle Aspekte als „Restrisiko“ verortet werden dürfen. Dem Autor sind dennoch zahlreiche Fälle bekannt, wo einer „formalen Korrektheit“ (etwa „Risikoanalyse wurde durchgeführt“) höhere Bedeutung beigemessen wurde als der Intensität und der Qualität der Risikoanalyse. Nicht selten mündet auch die Risikomitigation² in eine Vielzahl von einzelnen Risikoakzeptanzen – obwohl teilweise technische Lösungen existieren.

Übrigens: Die Durchführung einer (übergreifenden) IT-Risikoanalyse ist die Aufgabe des Unternehmens. Wie aus prominenten Standards und Normen (wie ISO 27001, IT-Grundschutz nach BSI) ersichtlich wird, darf diese Aufgabe nicht einfach an den/die Provider delegiert werden. Risiko ist Chefsache.

Manchmal drängt sich förmlich die Frage auf, ob es dem Unternehmen primär darum geht, „compliant“ zu sein, oder ob es darüber hinaus auch tatsächlich einen Schutz herstellen möchte, der für die entsprechende Situation geboten ist.

Gleichzeitig gibt es auch positive Signale: Zitat aus der oben erwähnten Lünendonk-Studie 2021: „Neben einem Umbau der IT-Architektur zur Nutzung hybrider und multipler Cloud-Services (73 Prozent) sehen 56 Prozent der Befragten die Notwendigkeit, mehr in die IT-Sicherheit zu investieren.“

Was bedeutet das nun für konkrete Cloud-/SAAS-Vorhaben?

Nehmen wir einmal an, dass Sie zwar ein „gutes Gefühl“ mit dem SAAS-Provider ihrer Wahl haben – aber ein restloses Vertrauen besteht nicht oder dürfen Sie sich für Ihren Business Case nicht leisten. Sie wollen beispielsweise sicherstellen, dass der Provider – obwohl das auch rechtlich und vertragstechnisch zugesichert wird – gar keine physikalische Möglichkeit hat, in die ihm anvertrauten Daten Einblick zu nehmen.

Wir haben bereits gesehen, dass eine Hardwareverschlüsselung der Datenträger für manche Angriffsarten durchaus sinnvoll ist, jedoch bei verschiedenen Angriffsvektoren keinen umfassenden Schutz abbildet. Ähnlich verhält es sich mit einer System- oder Datenbankverschlüsselung: Jede Verschlüsselungsart hilft gegen spezielle Angriffsarten – nicht jedoch gegen alle Angriffe auf die Vertraulichkeit. So schützt die Datenbankverschlüsselung vor übergriffigen System-Administratorinnen und -Administratoren, während die System-/Volumeverschlüsselung ihrerseits die „Sicherheits-Latte“ noch ein wenig höher legt.

Anmerkung: Ein Stück weit fühlt man sich hierbei an das Sicherheits- Prinzip „Defense in Depth“ erinnert. Und ja, es ist generell sinnvoll, nicht alles auf eine Karte zu setzen.

Tabelle 1: Verschiedene Verschlüsselungsebenen (in Anlehnung an das Prinzip des ISO/OSI-Modells)


Zurück zum Thema – die entscheidende Frage ist und bleibt: Wo liegt der „Vertrauensanker“? Wer hat schlussendlich die Entscheidungsgewalt, um festlegen zu können, wer auf die Daten welche Art von Zugriff erhält? Solange sich die Verschlüsselungs-Keys im Zugriffsbereich des Providers bewegen, ist nicht auszuschließen, dass ein unberechtigter Zugriff möglicherweise stattfinden kann. Zumindest aus theoretischer Sicht ist er möglich.

Abb. 1: Denkbare Verschlüsselungsebenen bei einem SAAS-Einsatz (stark vereinfacht)


Und genau hier ist die Krux! Wenn wir die erwähnte „Verschlüsselungshierarchie“ weiterdenken, ist es nur konsequent, zusätzlich auch einen Tenant Key zu etablieren (manchmal auch BYOK³ genannt), mit dem beispielsweise eine Content-Verschlüsselung vorgenommen wird. Wichtig dabei: Dieser Tenant-Key darf dann auch nur durch den Tenant zugreifbar/verwaltbar sein und nicht durch den Provider! Um dies technisch zu forcieren, kommen hier üblicherweise „Hardware Security Modules“ (kurz: HSM, siehe auch nachfolgender Kasten) zum Einsatz (etwa nCipher). Man darf sich ein solches HSM als eine Blackbox vorstellen, mit der man Schlüssel in sicherer Form erstellen, verwahren und managen kann: Ein einmal generierter oder importierter Schlüssel kann das HSM nicht wieder verlassen. Auch bei der Verwendung der Schlüssel gilt dieses Prinzip.

Um dann beispielsweise aus Applikationssicht eine Ver- oder Entschlüsselungsoperation durchzuführen, muss die Applikation – vereinfacht gesagt – die entsprechenden Daten (in kleineren Datenpaketen) an das HSM senden und erhält das Gegenstück zurück. Mit dem Einsatz eines HSM kann auf diese Weise sichergestellt werden, dass der Vertrauensanker beim Unternehmen (Tenant) verbleibt. Selbst wenn das HSM als solches im Rechenzentrum des Providers steht, ist der Zugriff auf die relevanten Keys unter der alleinigen Kontrolle des Tenants.

Hardware Security Module (HSM): Eine Enterprise-konforme Security Appliance, die digitale Schlüssel in hochsicherer Weise erstellen, verwahren und anwenden kann. HSMs haben in der Regel einen sehr hohen Durchsatz von Crypto-Operationen und sind Multi- Tenant-fähig. Die wesentlichen Sicherheitsaspekte liegen darin, dass die Schlüssel niemals das Gerät verlassen können und auch ein sehr hoher mechanischer Schutz (tamper resistant) besteht. Hierfür existieren qualitativ hochwertige Zertifizierungs-Level (EAL4, EAL5 etc.) für die Appliances.

Zur Reduktion von Angriffsvektoren bieten sich verschiedene Verschlüsselungsebenen an – je nach Schutzbedarf und Zielsetzung ist eine Kombination mehrerer Ebenen durchaus zweckmäßig. Der Performance-Verlust durch Mehrfachverschlüsselung bewegt sich – je nach Kombination – überwiegend im einstelligen Prozentbereich. Die massive Förderung des Sicherheitsniveaus ist meist von deutlich höherer Bedeutung als dieser Verlust.



Abb. 2: Verschlüsselung im Zusammenspiel SAAS-Provider – Unternehmen

Für ein konkretes Vorhaben (bei einem SAAS-Provider Ihrer Wahl oder bei einem Hyperscaler) könnten sich die verschiedenen Verschlüsselungsebenen wie in Abbildung 1 gezeigt darstellen.

Fazit

Durch eine Kombination von Verschlüsselungen auf verschiedenen Ebenen reduziert sich die Anzahl valider Angriffsszenarien erheblich. Aufgrund der Tatsache, dass für manche Ebenen der Vertrauensanker für die Verschlüsselungs-Keys nicht beim Provider liegt, sondern im eigenen Unternehmen, sind unberechtigte Übergriffe oder Datenabzüge (etwa durch das Administrations- oder Betriebspersonal des Providers) nicht mehr erfolgversprechend. Auch ein Virus hätte – zumindest in Bezug auf die Verletzung der Vertraulichkeit der Daten – eine faktisch unlösbare Aufgabe vor sich. Zwar liegt die Intention von Viren oftmals in der Beeinträchtigung der Verfügbarkeit, das ist jedoch ein anderer Problemkreis.

Welche konkreten Verschlüsselungskombinationen für ein Unternehmen zweckmäßig sind, darf individuell – unter Berücksichtigung der Risikoanalyse, der Schutzbedarfe und auch der „Auslagerungspolitik“ – beurteilt werden.

Mit dieser Vorgehensweise lässt sich – in Ergänzung zu den üblichen vertraglichen Anforderungen an Sicherheit und Vertraulichkeit – nun auch eine technisch forcierte Sicherheit bewerkstelligen: Das Unternehmen bleibt Herr über die Vertraulichkeit der Daten. Insbesondere bei KRITIS-relevanten Unternehmen oder auch bei High-Tech-Unternehmen mit sehr hohen Anforderungen an die Vertraulichkeit eröffnen sich hiermit neue Möglichkeiten auf dem Weg zu einer Multi-Tenant-fähigen SAAS-Lösung.


Quellen

¹ Lünendonk & Hossenfelder GmbH: Lünendonk-Studie 2022: Von Cyber Security zur Cyber Resilience – mehr Digitalisierung, mehr Cyber-Bedrohung?, www.luenendonk.de, (abgerufen am 05.06.2023).
² Risikomitigation: Der Prozess, wie mit einem identifizierten Risiko weiter vorgegangen werden soll (typische Vertreter: Risikovermeidung, Risikoreduktion, Risikoweitergabe, Risikoakzeptanz).
³ BYOK: Bring Your Own Key.