5 Best Practices für moderne Zugriffskontrollen in Cloud-Anwendungen

Kürzlich habe ich mich mit Or Weis – einem Snyk Ambassador – über Zugriffskontrollen in der Cloud unterhalten. Or ist Unternehmer und lebt in Tel Aviv, wo er Permit.io gegründet hat. Die Lösung ermöglicht es Entwicklerinnen und Entwicklern, Berechtigungen und Zugriffskontrollen in wenigen Minuten in jedes Produkt zu integrieren und erspart ihnen die mühsame Arbeit, diese ständig neu zu entwickeln.

In unserem Vortrag haben wir verschiedene Themen behandelt, darunter:

• Warum es so wichtig ist, in der Cloud stets moderne Zugriffskontrollen zu verwenden

• Warum RBAC allein nicht ausreicht

• Sicherheit und Compliance

• Die verschiedenen Zugriffskontrollschichten in der Cloud

• Der IAM-Wasserfall

• Die Angriffsfläche beim Aufbau von Zugriffskontrollen reduzieren

Außerdem haben wir Best Practices für Zugriffskontrollen besprochen, die Sie direkt auf Ihre Cloud-Anwendungen anwenden können. In diesem Blogbeitrag fassen wir diese Praktiken zusammen und greifen dabei auf Inhalte aus unserem ausführlicheren Gespräch zurück. Wenn Sie tiefer in das Thema einsteigen möchten, empfehlen wir Ihnen, sich die gesamte Diskussion anzusehen:

Play Video: Building Modern Access-Control for Cloud Applications with Or Weis | SnykLIVE Recording

5 Best Practices für moderne Zugriffskontrollen in der Cloud

Ganz gleich, ob Sie Zugriffskontrollen selbst, mit Open Source oder mithilfe proprietärer Tools entwickeln möchten: Mit diesen fünf Best Practices stellen Sie sicher, dass Ihre Lösung zukunftssicher und robust ist und die nötigen Leitplanken bietet, um Ihr System zu stabilisieren und zu schützen.

1. Code und Richtlinien entkoppeln

2. Ereignisgesteuerte Aktualisierungen einplanen (Daten und Code entkoppeln)

3. Ein Backoffice für Stakeholder entwickeln

4. Eine Schnittstelle für Kunden erstellen

5. GitOps implementieren

1. Code und Richtlinien entkoppeln

Die erste und wahrscheinlich wichtigste Best Practice besteht darin, Richtlinien und Code voneinander zu entkoppeln. Häufig werden Autorisierungslogik und Anwendungslogik direkt miteinander verknüpft. Das Ergebnis ist Spaghetti-Code mit „if“-Bedingungen, die sowohl die Datenbank als auch andere Quellen nach Autorisierungslogik abfragen – und parallel dazu auch die Anwendungslogik verarbeiten. Mit der Zeit verschmelzen beide meist vollständig. Wenn Entwicklerinnen und Entwickler nach und nach neue Bedingungen hinzufügen, lässt sich kaum noch erkennen, welche Teile der „if“-Bedingung der Autorisierung und welche der Anwendung dienen.

Wenn Sie Ihre Autorisierungsschicht oder die Anwendung selbst aktualisieren möchten, müssen Sie deshalb alles Zeile für Zeile prüfen und umgestalten. Das führt schnell zu schmerzhaftem Refactoring. Daher sollten Sie die Richtlinien vom Code entkoppeln. Wechseln Sie zu Policy as Code (PaC) und verwalten Sie den entsprechenden Code separat – idealerweise als eigenen Microservice, den andere Anwendungskomponenten abfragen können, um die benötigte Logik abzurufen.

Neue Entwicklerinnen und Entwickler fragen sich bei diesem Thema möglicherweise:

1. Wer kontrolliert den Zugriff auf diesen Dienst?

2. Was kommt zuerst: die Authentifizierung oder die Anwendung?

Um es direkt zu sagen: Das ist ein riesiges, hochgradig rekursives Komplexitätsfeld, das als Autorisierung der Autorisierung bezeichnet wird. Vereinfacht gesagt können Sie den Zugriff auf die nachfolgende Schicht begrenzen und ihn oft ausschließlich auf die Authentifizierung beschränken. Wenn Ihre Microservices eine Verbindung zum Autorisierungs-Microservice herstellen, dürfen sie das also nur, wenn sie über eine Identität verfügen, die von diesem Microservice verifiziert wird. Mehrere Schichten erhöhen die Komplexität. Die meisten Tools versuchen jedoch, dieses Problem für Sie zu lösen oder Ihnen zumindest einen erheblichen Teil der Arbeit abzunehmen.

Denken Sie daran: Im Idealfall erstellen Sie einen eigenen Microservice für die Autorisierung. Dieser muss anfangs nicht perfekt sein. Zunächst kann es eine einfache Funktion sein, die immer „true“ zurückgibt. Sie müssen nicht gleich alles von Anfang an entwickeln. Wichtig ist, Platzhalter richtig anzubinden, damit Sie sie schrittweise aktualisieren können, sobald neue Anforderungen hinzukommen. Ob Lambda-Funktion, kleiner Container oder eine andere Lösung – sie muss sich unabhängig weiterentwickeln und bei neuen Anforderungen leicht refaktorieren lassen.

2. Ereignisgesteuerte Aktualisierungen einplanen (Daten und Code entkoppeln)

Die zweite Best Practice lautet: Arbeiten Sie ereignisgesteuert. Komplexe Systeme haben komplexe Richtlinien, die sich mit der Oberfläche der Anwendung verändern. Wenn Sie Ihre Anwendung von Anfang an ereignisgesteuert konzipieren, lassen sich künftige Aktualisierungen leichter verwalten.

Nehmen wir ein Beispiel. Stellen Sie sich eine einfache Richtlinie vor: Nur Nutzerinnen und Nutzer, die für ein Feature bezahlt haben, dürfen es verwenden. Diese Information befindet sich inzwischen weder in Ihrer Datenbank noch in Ihrer Anwendung. Sie liegt bei einem Drittanbieterdienst wie Stripe, Chargebee oder PayPal. Deshalb sollten Sie Änderungen dieser Dienste in Echtzeit weitergeben und in Ihrer Autorisierungsschicht berücksichtigen können.

Am besten gelingt das mit einem ereignisgesteuerten Ansatz. Das bedeutet, Webhooks von externen Diensten oder Komponenten zu empfangen und an Ihre Autorisierungsschicht weiterzuleiten. Das nennt sich „Daten und Code entkoppeln“ und ist genauso wichtig wie die Entkopplung von Richtlinien und Code.

3. Backoffice für Stakeholder + 4. Schnittstelle für Kunden

Da wir wissen, dass es Kunden und andere Stakeholder geben wird (etwa Produktmanager, Sicherheitsunternehmen und weitere), ist klar, dass sie Schnittstellen zur Verwaltung der Zugriffskontrollen benötigen. Sie müssen diese Schnittstellen nicht sofort entwickeln, sollten aber darauf vorbereitet sein, sie bei Bedarf erstellen und bereitstellen zu können.

Richten Sie also ein Backoffice ein, in dem verschiedene Stakeholder die Anwendung verwalten können. Außerdem benötigen Sie Schnittstellen für Ihre Kunden, über die sie selbst Nutzerinnen und Nutzer einladen, Rollen zuweisen und sogar Richtlinien konfigurieren können. Wie die meisten Engineers bestätigen werden: Der beste Service ist Self-Service.

5. GitOps implementieren

Abschließend – und damit sind wir wieder bei Policy as Code – lässt sich die Sicherheit mit GitOps vereinfachen. Gemeint ist die Verwaltung komplexer Regeln und Anweisungen in einer Umgebung, die sich ständig verändert und viele Stakeholder umfasst. Am besten gelingt das mit Code. So wie wir Infrastructure as Code und Security as Code nutzen, sollten wir auch Policy as Code einsetzen.

Wenn Sie Ihre Richtlinien als separaten Code in einem Git-Repository verwalten – idealerweise in einem dafür geeigneten Framework –, können Sie Versionen, Tests, Benchmarks und Code-Reviews effizient organisieren. So müssen Sie nicht jedes Mal neu überlegen, wie Sie Richtlinien verwalten und mit Ihrem System verknüpfen.

Bleiben Sie auf dem neuesten Stand

Behalten Sie diese fünf Best Practices im Hinterkopf, wenn Sie mit der Entwicklung beginnen. Wenn Sie frühzeitig berücksichtigen, dass diese Anforderungen auf Sie zukommen, sparen Sie sich später monatelange Refactoring-Arbeit.

Zum Schluss ein großes Dankeschön an Or Weis, dass er mit mir gesprochen und sein Fachwissen geteilt hat. Wenn Sie Fragen zu diesem Thema haben, empfehlen wir Ihnen, Or Weis auf Twitter oder LinkedIn zu kontaktieren oder dem DevSecCon community Discord beizutreten und ihm dort direkt Ihre Fragen zu stellen.