👮‍♂️ Datensicherheit 101 - Zugriffskontrolle

Hintergrund

Eine der am häufigsten gestellten Fragen unserer Kunden ist:

Wie sicher sind meine Daten in der Cloud?

Obwohl, oder auch gerade weil diese Frage sehr abstrakt ist, lohnt es sich, diese Frage aufzubrechen und als Einzelthemen genauer zu beleuchten, zu erläutern und zu beantworten - besonders im Hinblick auf die CERTAIN CE-Kennzeichnungssoftware.

Die “Datensicherheit 101” Serie auf unserem CERTAIN Blog soll erstens ein Verständnis dafür vermitteln, wie Daten in “der Cloud” verarbeitet und gespeichert werden und zweitens, durch dieses neugewonnene Verständnis, mehr Vertrauen in cloud-basierte Software geben. In dieser Serie werden wir uns mit den folgenden Themen befassen:

• der Begriffsbestimmung “der Cloud”
• einem Blick auf Daten-Verschlüsselung aus der Vogelperspektive
• einem theoretischen Ansatz der Zugriffsbeschränkung in Cloud-Systemen
• dem Sprung in eine passwortlose Zukunft
• der spezielleren Anwendung der oben genannten Themen in der CERTAIN App. Ich werde Fokus darauf legen, diese technisch recht anspruchsvollen Themen verallgemeinert, aber für Laien verständlich zu erklären. Ich setze keine IT-Vorkenntnisse der Lesenden voraus.

Im dritten Teil der Serie schauen wir uns an, wie der Zugriff auf Ressourcen in Multi-Tenant-Systemen (kleine Erinnerungshilfe zu dem Konzept gibt’s im 1. Teil) gehandhabt wird. In der ersten Hälfte befassen wir uns theoretisch mit der Frage, ob “Daten in der Cloud sicher sind vor dem Zugriff anderer Nutzer”. In der zweiten Hälfte veranschauliche ich die praktische Umsetzung der Zugriffskontrollen.

Zugriff in Multi-Tenant-Systemen

Wie im ersten Teil der Serie erläutert, nutzen alle User einer Multi-Tenant-Anwendung die selben Infrastruktur-Ressourcen (Datenbanken, Server, etc) des Anbieters. Das bedeutet auch, dass, ohne Kontrollmechanismen, alle Nutzer auf sämtliche Daten auf diesen Ressourcen zugreifen können. In CERTAIN’s Fall würde das bedeuten, dass ein User die Projekte eines anderen Users einsehen könnte. Selbstverständlich ist das ein absolutes No-Go. Im Folgenden schauen wir uns zwei Konzepte an, mit denen sich der Zugriff steuern lässt.

Attribute-Based Access Control (ABAC)

ABAC ist ein Sicherheitsmodell, bei dem der Zugriff auf Ressourcen basierend auf Attributen (Eigenschaften) gesteuert wird. Diese Attribute können sich auf Nutzer, Ressourcen (z.B. Projekte bei CERTAIN) oder sogar Umgebungsbedingungen beziehen.

Konkrete Attribute sind:

• der Sitz eines Users, z.B. nur EU-basierte User dürfen Projekte eines Herstellers bearbeiten
• die Besitzstruktur eines Projekts, z.B. ein Projekt darf nur von seinem Besitzer bearbeitet werden

Role-Based Access Control (RBAC)

RBAC hingegen konzentriert sich auf die Ressourcen selbst, also das Projekt oder den Hersteller, und steuert den Zugriff basierend auf der Rolle des Nutzers im System.

Beispiel-Rollen in einem CERTAIN Account:

• Admin, hat Zugriff auf sämtliche Projekte, Hersteller, Risikovorlagen und hat auch die Erlaubnis Zahlungsdaten und Abo-Modelle zu ändern
• Dokumentationsbevollmächtiger, hat vollständigen Zugriff auf Projekte, Hersteller und Risikovorlagen, kann aber accountweite Einstellungen nicht anpassen
• Auditor, kann ausschließlich Projektdaten anschauen, aber keinerlei Änderungen vornehmen

Kombination von ABAC und RBAC für optimale Sicherheit

Die Kombination von ABAC und RBAC bietet eine robuste Sicherheitslösung für Multi-Tenant-Systeme. Während ABAC die Flexibilität bietet, den Zugriff basierend auf einer Vielzahl von Attributen zu steuern, sorgt RBAC dafür, dass nur Benutzer mit der richtigen Rolle auf bestimmte Ressourcen zugreifen können. Diese doppelte Kontrolle trägt wesentlich dazu bei, die Sicherheit in Cloud-Umgebungen zu erhöhen.

Hierarchie der CERTAIN Ressourcen

Um besser zu verstehen, wie CERTAIN Zugriffe kontrolliert sind, müssen wir eine kurze Sektion über die existierenden Entitäten und deren Beziehung untereinander einschieben.

1. Account

Accounts sind die äußerste Organisationsstruktur im CERTAIN System. Ein Account “besitzt” mindestens einen Nutzer und kein, ein oder mehrere Projekte und Hersteller, Risikovorlagen etc.

2. User

User sind menschliche Akteure, die sich einloggen, Projekte und Hersteller bearbeiten, einsehen oder auch löschen können. Bestimmte User können auch sensible Daten eines Accounts einsehen und bearbeiten. Dazu gehören Zahlungsdaten oder die Zugriffskontrolle anderer User im Account.

3. Projekte, Hersteller, Vorlagen und andere

Fachliche Ressourcen wie Projekte usw. sind immer nur einem Account zugeordnet, können aber von mehreren Usern verwendet, bearbeitet oder eingesehen werden.

Diese Zusammenhänge lassen sich vereinfacht visualisieren:

Visualisierung der CERTAIN Entitäten und ihrer Beziehungen

Mit dieser Verbildlichung können wir uns nun exemplarische Richtlinien anschauen.

Zugriffs-Richtlinien bei CERTAIN

In der Praxis gibt es einige Möglichkeiten, ABAC und RBAC zu implementieren.

Bei CERTAIN steuern wir den Zugriff auf die Ressourcen unserer Nutzer mit Cedar Policies. Das sind Richtlinien, durch die der Zugriff explizit anhand von Nutzer-Rollen (RBAC) und/oder Attributen der zugreifenden User bzw. zugegriffenen Ressourcen (ABAC) definiert wird.

Beispiel: Zugriff der Dokumentationsbevollmächtigen

Beispielsweise können wir den Zugriff auf Ressourcen in einem Account “1234” (vereinfachte Account-ID) auf die Aktivitäten “Update” und “Describe” begrenzen, wenn der anfragende Nutzer die Rolle “Editor” (ebenfalls vereinfacht) einnimmt und der Nutzer im selben Account agiert.

In der Cedar-Sprache ausgedrückt, gestaltet sich die Richtlinie wie folgt:

permit (
    principal in Certain::Account::1234,
    action in [Certain::Action::Project:Update, Certain::Action::Project:Describe],
    resource in Certain::Account::1234
) when {
    principal.role == "Editor"
};

Beispiel: Auditor für ein einziges Projekt

Wollten wir einem bestimmten Auditor (das könnte eine Kontroll-Funktion innerhalb des eigenen Unternehmens sein oder auch eine benannte Stelle oder sonstige Aufsichtsinstitution) Lese-Zugriff auf ein einziges bestimmtes Projekt geben, würde unsere Richtlinie so aussehen:

permit (
    principal == Certain::Auditor::000,
    action == Certain::Action::Project:Describe,
    resource == Certain::Project::123
);

Es gibt noch eine ganze Reihe weiterer logischer Operatoren, um Attribute, Rollen oder den Kontext zu prüfen und komplexere Richtlinien zu erstellen bzw. zu prüfen.

Alles andere verboten

Ein wichtiges Grundprinzip dieser Policies ist, dass alle Aktionen abgelehnt werden, außer sie sind explizit erlaubt. Das bedeutet, dass auf keine Ressource zugegriffen kann, es sei denn, es gibt eine Richtlinie, die genau diesen Zugriff definiert. Dadurch kehren wir die Sicherheitsverantwortung um: Statt alle Möglichkeiten eines Zugriffs zu begrenzen, was das Risiko birgt, manche zu übersehen, müssen wir die Zugriffe ausdrücklich erlauben. Und damit führt ein Fehler zu einem nicht erlaubten Zugriff, statt zu einem Datenleck. CERTAINs Zugriffskontrolle wird damit “secure by default”.

Fazit

Kommen wir zurück zu der Ausgangsfrage "Sind meine Daten in der Cloud sicher vor dem Zugriff anderer Nutzer?"

Ja, mit der Zugriffskontrolle durch RBAC und ABAC Richtlinien sind Ihre Daten im CERTAIN System sicher vor dem Zugriff anderer Nutzer.

In den ersten drei Teilen der Blog-Serie haben wir die Sicherheit innerhalb der CERTAIN Cloud untersucht. Im nächsten Teil sehen wir uns Ihren Zugang zur Cloud an und erläutern, wie wir diesen so sicher wie möglich machen.