Sensitive Daten in Microservice-Architekturen mit konsistenten Policies schützen

Autor: Ryan Aebi

In modernen Microservice und Zero-Trust Architekturen werden Zugriffsentscheidungen on the go auf jeder Komponente unabhängig voneinander gefällt. Dies birgt eine sehr grosse Herausforderung:

Die Zugriffsautorisierung auf sensitive Daten kann von den Produktteams ganz unterschiedlich in den jeweiligen Microservices umgesetzt werden.
Änderungen in den Zugriffsberechtigungen müssen wiederum in jedem Microservice angepasst werden.

Der Open Policy Agent (OPA) dient als Policy Engine dazu:

Den Policy Decision Point (PDP) vom Policy Enforcement Point (PEP) zu entkoppeln
Autorisierung in Microservice und Devops getriebenen Architekturen als Policy Decision Point durchzusetzen
Zugriffsautorisierungen zentral zu verwalten

Autorisierung in Microservice Architekturen

Wie funktionieren Autorisierungsentscheidungen formell

In einem Autorisierungsentscheid für einen API-Call sind mehrere (logische) Komponenten beteiligt. Diese Komponenten können grob durch die folgende Grafik und Text beschrieben werden:

Figure 1: Components of an authorization decision for an API call https://www.yenlo.com/blogs/api-policies-pap-pdp-pep-and-pip-oh-my/

Der Policy Enforcement Point (PEP) ist die Komponente, welche den Entscheid für einen API-Request (z.B. Allow / deny) umsetzt.
Die Entscheidung, ob ein Zugriff erlaubt ist, wird durch den Policy Decision Point (PDP) gefällt.
Damit der PDP diesen Entscheid fällen kann, greift er auf den Policy Information Point (PIP) zu; dieser verwaltet die Policies, welche vom PDP als Entscheidungsgrundlage verwendet werden.
Die Policies im PIP können durch den sogenannten Policy Administration Point (PAP) eingesehen, administriert und editiert werden.

Cloud-Native Entwicklung und Micro Services

Neue Trends befassen sich mit Zero-Trust [2], es gibt keine zentrale Security mehr, welche alles kontrolliert.
Dabei ist das Ziel, jeden API-Call / jeden Request separat zu betrachten und so die Autorisierung in jeder Komponente und deshalb auch in jedem Zugriff durchzuführen.
Dies bedingt, dass jede Komponente einen PEP implementiert und selbstständig einen entsprechenden API-Call erlauben oder ablehnen kann.

Autorisierungs-Implementierung in jedem Service

Dadurch, dass jede Komponente selbst überprüfen muss, ob ein API-Call erlaubt werden soll oder nicht, muss jede Komponente auch fähig sein, diese Entscheidung zu fällen.
Als Micro-Service Entwickler bedeutet dies, dass nebst der Aufgabe des PEP (“ich muss einen Zugriff erlauben oder blockieren können”) ebenfalls ein PDP (“ich muss entscheiden können, ob ein Zugriff erlaubt ist”) implementiert werden muss. Dies sollte innerhalb desselben Microservices geschehen.
In der Regel führt das dazu, dass jeder Microservice seinen PDP anders implementiert und insbesondere andere Regeln und Policies als Entscheidungsgrundlage verwendet. Sprich, es gibt keinen zentralen PIP, Policies sind überall verteilt und werden unterschiedlich formalisiert.
Nebst einem massiven Governance-Overhead, um die Situation im Griff zu behalten, bedeutet dies ebenfalls, dass jede informelle Policy-Änderung zu einer Codeänderung führt:

neuer Build / Release
neue Regression-Tests
neue Deployments (Downtime / Wartefenster)

Im Worst-Case könnte es wie nachfolgend abgebildet aussehen und dies für jeden Microservice.

Policy-Änderungen führen zu Änderungen in jedem Microservice.png

Abbildung 2: Policy-Änderungen führen zu Änderungen in jedem Microservice

Dazu kommt die Thematik der Service-Level/User-Level Authorization. Dabei geht es darum, welcher Microservice darf welche API konsumieren (what-can-do-what) und was darf ein User von einem Service/einer Applikation konsumieren (who-can-do-what). Alle diese Entscheidungen müssen pro Micro-Service, genauer pro API, implementiert werden.

Sind Sie bereit für diesen Architekturentscheid, die Mehrkosten sowie das daraus entstehende Risiko zu tragen?

Wie kann ein Governance-Overhead verhindert werden?

In vieler Hinsicht macht es Sinn, dass in einer Zero-Trust getriebener Architektur jede Komponente einen PEP implementiert. Sowohl das Backend, der Microservice und auch die Datenbank müssen selbst verantwortlich sein, um eine Policy-Entscheidung durchsetzen zu können.
Stellen Sie sich folgendes Szenario vor:

Ein neuer Mitarbeiter startet in Ihrem Unternehmen als Microservice Entwickler.
Dazu braucht die Person sowohl Zugriff auf die internen Tools (z.B. Jira, Confluence, Gitlab, etc.) (User-Level Authorization) wie auch weitere Berechtigungen auf dem Microservice (Service-Level Authorization) für die Weiterentwicklung seines Microservices.
Wer beurteilt nun, welche Microservices wie angepasst müssen?

Der Governance-Overhead besteht nicht im PEP, sondern im PDP, PIP und PAP. Eine mögliche Lösung dazu bietet der Open Policy Agent (OPA) [3].

Open Policy Agent

Das Projekt OPA wurde von der Cloud Native Computing Foundation (CNCF) im April 2018 in der CNCF Sandbox und ein Jahr später in die Inkubationsphase aufgenommen [11].

Abbildung 3: Logo der Cloud Native Computing Foundation (CNCF)

Im Februar 2021 erreichte der OPA schliesslich den Status ‘graduated’, ein reservierter Begriff, welcher die CNCF an Projekte verleiht, welche eine gewisse Maturität in mehreren Bereichen erlangt haben [11].

Decoupling von Policy Governance & Policy Decision von Services

Der OPA erlaubt es Policies als Code zu verwalten. So kann ein Git Repository (Github, Gitlab, Bitbucket, usw.) verwendet werden um Policies:

versionierbar
nachvollziehbar
zentral zu verwalten

So muss nicht mehr jeder Microservice seine Policies selbst verwalten und editieren. Die Entwickler werden sogar befähigt, ihre Continuous Deployment Pipeline / Rolling Releases zu bauen, während sie den OPA / PDP einfach als Service zur Build-/Deploy- und Runtime konsumieren können. Insofern entfallen die Aufgaben von PIP (Policies werden zentral in einem Repo verwaltet) und PAP (Policies können zentral im Repo bearbeitet werden) für die Microservices.
Während die Policies in Rego geschrieben werden, übernimmt der OPA die Publikation als REST-Service. Der OPA bearbeitet den Request anhand der hinterlegten Rego-Policy und entscheidet dann entsprechend, ob der Zugriff erlaubt werden soll oder nicht. Der OPA übernimmt also die Aufgabe des Policy Decision Points (PDP), indem er Auskunft gibt, ob ein Request erlaubt ist. Das Durchsetzen des Policy-Entscheides (PEP) bleibt beim Microservice.

Abbildung 4: Der OPA hilft PDP, PIP und PAP aus Microservices zu entflechten

Mehr Nutzen mit OPA: Kubernetes & Terraform

Eine der schönsten Eigenschaften von OPA und Rego ist, dass sie nicht auf Microservices limitiert sind. Mit Rego kann prinzipiell alles modelliert werden. So kann in einem Kubernetes-Umfeld kontrolliert werden, dass [6]:

nur Images aus vordefinierten Repos verwendet werden dürfen
nur Images mit gewissen Labels verwendet werden dürfen
nur vordefinierte Ports verwendet werden dürfen
TLS verwendet wird

OPA_Kubernetes Admission Flow_Abbiludng 5.png

Abbildung 5: Kubernetes Admission Flow https://www.openpolicyagent.org/docs/latest/kubernetes-introduction/

Analog kann in einem Terraform Umfeld forciert werden:

dass nur gewisse Services in einem Terraform Plan genutzt werden dürfen (Service Whitelisting) [7]
wie viele Instanzen eines Service hinzugefügt/gelöscht oder modifiziert werden dürfen [8]

Fazit

Weniger Risiken für Datenabfluss

In vielerlei Hinsicht macht es Sinn in modernen Microservice/Devops Architekturen eine mehrstufige Security umzusetzen, indem jede Komponente selbst ihren Policy Enforcement Point (PEP) implementiert. Der Open Policy Agent unterstützt dies, indem er PDP, PIP und PAP mittels zentralen Policies zur Verfügung stellt.

Governance zentral verwaltbar

Da der Open Policy Agent seine Policies durch ein Source Code Repository bezieht, gibt es eine Single-Source of Truth. Es gibt kein Delta, weil Microservices ihre Policies selbst implementieren, stattdessen können diese zentral eingesehen und editiert werden. So ist es zu jedem Zeitpunkt möglich nachzuvollziehen, welche Policy deployed/aktiv war, aber auch welche Änderungen zuletzt gemacht wurden.

Zusammenfassend sind die Vorteile:

Policies können versioniert werden.
Policy-Änderungen sind dokumentiert und können in einen Freigabeprozess zentral eingebunden werden.
Policy-/Security-Audits können zentral durchgeführt werden.

Anwendbar für Microservices und Kubernetes

Der Open Policy Agent kann überall dort verwendet werden, wo Entscheidungen anhand einer Policy gefällt werden müssen. Die Policy-Sprache Rego ist dabei universell definiert und kann deshalb überall angewendet werden.

Transparente Entscheide durch Policies as Code

Ein zentrales Enabling von OPA ist, dass Policies zentral in einem Source-Code Repository geführt werden können. So werden Policies versionierbar und nachvollziehbar verwaltet. In Kombination mit einer sauberen Deployment Pipeline kann zu jedem Zeitpunkt überprüft werden, welche Policy auf welchen OPA deployed wurde, wie sie konfigurativ ausgesehen hat und so auch Policy-Entscheidungen erfassen. Dieses Zusammenspiel von Code-basierten Policies und Nachvollziehbarkeit durch Deployments eignet sich hervorragend für allfällige Audits.

Quellen:

Ihr ipt-Experte

Ich freue mich auf Ihre Kontaktaufnahme

Ryan Aebi

IT Architect