Acdc Das Geheimnis Hinter Robusten Berechtigungsmodellen

Hallo zusammen,

wenn es um Berechtigungen in unseren Anwendungen geht, denken die meisten von uns zuerst an Rollen (Admin, User) oder ACLs (Access Control Lists). Das funktioniert, aber bei komplexen Systemen wird das schnell unübersichtlich. Hier kommt ACDC ins Spiel, ein Denkmodell, das uns hilft, Berechtigungslogik sauberer und skalierbarer zu gestalten.

ACDC steht für:

• Attribute
• Context
• Definition
• Constraints

ACDC ist kein neues Framework, sondern ein systematischer Ansatz, um Berechtigungen zu entwerfen. Es ist eine mentale Checkliste, die uns zwingt, über alle Aspekte einer Berechtigungsanfrage nachzudenken.

Attribute: Wer oder was?

Die Attribute sind die grundlegenden Eigenschaften von allem, was an einer Berechtigungsanfrage beteiligt ist. Das sind die Subjekte, Objekte und Aktionen.

• Subjekt-Attribute: Wer ist der Nutzer? Was sind seine Eigenschaften?
  • Benutzer-ID, Rolle, Abteilung, Standort
• Objekt-Attribute: Worauf wird zugegriffen?
  • Dokumenten-ID, Dokumenten-Typ, Besitzer, Status
• Aktions-Attribute: Was soll getan werden?
  • lesen, schreiben, löschen, genehmigen

Indem wir diese Attribute klar definieren, schaffen wir die Bausteine für unsere Berechtigungsregeln.

Context: Wo, wann, wie?

Der Context beschreibt die Umstände der Anfrage. Er liefert dynamische Informationen, die über die statischen Attribute hinausgehen und die Berechtigung beeinflussen können.

• Zeit: Ist der Zugriff nur während der Arbeitszeit erlaubt?
• Ort/Netzwerk: Kommt die Anfrage aus dem Firmennetzwerk oder von extern?
• Gerät: Wird ein mobiles Gerät oder ein Desktop verwendet?
• Anfrage-Daten: Welche zusätzlichen Informationen sind in der Anfrage enthalten?

Der Kontext ist entscheidend, um Berechtigungen adaptiv zu machen.

Definition: Die Regel selbst

Die Definition ist die eigentliche Berechtigungsregel, die wir aufstellen. Sie kombiniert Attribute und Kontext, um eine klare Anweisung zu formulieren. Die Definition ist typischerweise in natürlicher Sprache formuliert, bevor wir sie in Code gießen.

Beispiel einer Definition:

“Ein Benutzer mit der Rolle Mitarbeiter darf ein Dokument vom Typ Bericht lesen, wenn er Teil der gleichen Abteilung ist, in der das Dokument erstellt wurde.”

Diese Definition ist präzise und leicht zu verstehen. Sie bildet die Grundlage für unseren Code.

Constraints: Ausnahmen und Einschränkungen

Die Constraints sind die feingranularen Einschränkungen oder Bedingungen, die erfüllt sein müssen, damit die Regel gilt. Sie sind oft boolesche Ausdrücke.

Beispiel von Constraints:

• Benutzer.abteilung == Dokument.abteilung
• Dokument.status == 'veröffentlicht'
• Anfrage.zeit >= 08:00 && Anfrage.zeit <= 17:00

Constraints machen die Regeln mächtig und ausdrucksstark, ohne sie unnötig komplex zu machen.

ACDC in der Praxis

Stellen wir uns vor, wir implementieren die obige Regel in unserem Code:

public boolean darfLesen(Benutzer benutzer, Dokument dokument) {
    // 1. Definition (wer, was, was)
    if (!benutzer.hatRolle("Mitarbeiter")) {
        return false;
    }
    if (!dokument.getTyp().equals("Bericht")) {
        return false;
    }

    // 2. Constraints (Bedingungen)
    if (!benutzer.getAbteilung().equals(dokument.getAbteilung())) {
        return false;
    }

    // 3. Wenn alle Constraints erfuellt sind, ist die Berechtigung erteilt
    return true;
}

Die if-Statements dienen als unsere Constraints. Aber stellt euch vor, wir hätten auch den Kontext, dass der Zugriff nur von einem bestimmten Netzwerk erlaubt ist. Dann würden wir einfach einen weiteren Constraint hinzufügen.

Fazit

Das ACDC-Modell hilft uns, über die einfachen Rollen und ACLs hinauszublicken und wirklich adaptive, verständliche Berechtigungsmodelle zu entwerfen. Indem wir systematisch über Attribute, Context, Definition und Constraints nachdenken, schaffen wir eine solide Basis für unsere Sicherheitsarchitektur, die mit unseren Systemen wächst und sich nicht in einem Wirrwarr von if-else-Blöcken verliert.

Wie designt ihr eure Berechtigungsmodelle? Nutzt ihr einen ähnlichen Ansatz?

Aber das war noch nicht Alles! Das ACDC-Modell lässt sich hervorragend auf die Arbeit mit Kubernetes und OpenShift übertragen. Die Konzepte helfen dabei, die Berechtigungslogik in diesen Container-Plattformen klarer zu strukturieren und zu verwalten.

ACDC in der Praxis mit Kubernetes und OpenShift

In Kubernetes und OpenShift basieren Berechtigungen auf Role-Based Access Control (RBAC). Das ACDC-Modell bietet einen übergeordneten Denkrahmen, um diese RBAC-Regeln besser zu entwerfen.

Attribute in Kubernetes

Die Attribute sind die Kernelemente, die in der RBAC-Konfiguration definiert werden:

• Subjekt-Attribute: Dies sind die Identitäten. In Kubernetes sind das:
  • User: Ein menschlicher Benutzer.
  • Group: Eine Gruppe von Benutzern.
  • ServiceAccount: Ein Pod oder eine Anwendung, die auf die API zugreift.
• Objekt-Attribute: Die Ressourcen, auf die zugegriffen wird:
  • Pods, Deployments, Services, Secrets, etc.
• Aktions-Attribute: Die Operationen, die ausgeführt werden dürfen:
  • get, list, watch, create, update, delete, exec.

Diese Attribute werden in Roles und ClusterRoles gebündelt, die festlegen, welche Aktionen auf welchen Ressourcen erlaubt sind.

Context und Constraints in OpenShift

Der Context und die Constraints sind in OpenShift besonders wichtig, da die Plattform erweiterte Sicherheitsfunktionen bietet:

• Namespace als Context: Ein Namespace ist ein perfektes Beispiel für einen Kontext. Eine RoleBinding bindet eine Role an ein Subjekt innerhalb eines bestimmten Namenspaces. Das schränkt die Geltung der Berechtigung automatisch auf diesen Kontext ein.
• Security Context Constraints (SCCs): Dies sind die ultimativen Constraints in OpenShift. SCCs regeln, was ein Pod tun darf, z. B. welche Volumes er nutzen kann, ob er als root laufen darf oder ob er privilegierte Container verwenden darf. Eine SCC ist eine Sammlung von Einschränkungen, die sicherstellen, dass die Aktionen eines Pods (der ServiceAccount) den Sicherheitsrichtlinien entsprechen.
• Netzwerkrichtlinien (Network Policies): Diese definieren, wie Pods untereinander und mit externen Endpunkten kommunizieren dürfen. Sie dienen als Constraints im Kontext des Netzwerks.

ACDC im Design-Workflow

Das ACDC-Modell hilft uns, eine Berechtigungsanfrage wie die folgende zu zerlegen und in RBAC-Konfigurationen zu übersetzen:

“Ein Team-Mitglied (Subjekt) darf Deployments (Objekt) in seinem Entwicklungs-Namespace (Kontext) aktualisieren (Aktion), aber nur, wenn die Container nicht als root laufen (Constraint).”

• Attribute: Benutzer, Deployment, Update-Aktion.
• Context: Der spezifische Namespace.
• Definition: Role zum Aktualisieren von Deployments.
• Constraints: Die Security Context Constraint, die verhindert, dass der Pod als root läuft, und die RoleBinding im spezifischen Namespace, die die Berechtigung auf diesen Kontext beschränkt.

Durch die Anwendung dieses Modells können wir eine klare, lesbare und sichere Berechtigungsstrategie für unsere Kubernetes- und OpenShift-Umgebungen entwickeln, die weit über einfache Admin vs. User-Rollen hinausgeht.