Beispiel 2: Mehrmandantenfähige Zugriffskontrolle und benutzerdefiniertes RBAC mit OPA und Rego

In diesem Beispiel wird anhand von OPA und Rego demonstriert, wie die Zugriffskontrolle auf einer API für eine Mehrmandantenanwendung mit benutzerdefinierten Rollen implementiert werden kann, die von Mandantenbenutzern definiert werden. Es zeigt auch, wie der Zugriff je nach Mandant eingeschränkt werden kann. Dieses Modell zeigt, wie OPA detaillierte Genehmigungsentscheidungen auf der Grundlage von Informationen treffen kann, die in einer hochrangigen Rolle bereitgestellt werden.

Die Rollen für die Mandanten werden in externen Daten (RBAC-Daten) gespeichert, die verwendet werden, um Zugriffsentscheidungen für OPA zu treffen:

{
    "roles": {
        "tenant_a": {
            "all_access_role": ["viewData", "updateData"]
        },
        "tenant_b": {
            "update_data_role": ["updateData"],
            "view_data_role": ["viewData"]
        }
    }
}

Wenn diese Rollen von einem Mandantenbenutzer definiert werden, sollten sie in einer externen Datenquelle oder einem Identitätsanbieter (IdP) gespeichert werden, der als Informationsquelle bei der Zuordnung von mandantendefinierten Rollen zu Berechtigungen und zum Mandanten selbst dienen kann. 

In diesem Beispiel werden zwei Richtlinien in OPA verwendet, um Autorisierungsentscheidungen zu treffen und zu untersuchen, wie diese Richtlinien die Mandantenisolierung erzwingen. Diese Richtlinien verwenden die zuvor definierten RBAC-Daten.

default allowViewData = false
allowViewData = true {
    input.method == "GET"
    input.path = ["viewData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "viewData")
}

Um zu verdeutlichen, wie diese Regel funktioniert, stellen Sie sich eine OPA-Abfrage mit der folgenden Eingabe vor:

{
    "tenant_id": "tenant_a",
    "role": "all_access_role",
    "path": ["viewData", "tenant_a"],
    "method": "GET"
}

Eine Autorisierungsentscheidung für diesen API-Aufruf wird wie folgt getroffen, indem die RBAC-Daten, die OPA-Richtlinien und die OPA-Abfrageeingabe kombiniert werden:

1. Ein Benutzer von tätigt einen Tenant A API-Aufruf an. /viewData/tenant_a

2. Der Data-Microservice empfängt den Aufruf und fragt die allowViewData Regel ab. Dabei wird die im Beispiel für die OPA-Abfrageeingabe gezeigte Eingabe übergeben.

3. OPA verwendet die abgefragte Regel in OPA-Richtlinien, um die bereitgestellten Eingaben auszuwerten. OPA verwendet auch die Daten aus RBAC-Daten, um die Eingabe auszuwerten. OPA macht Folgendes:

   1. Überprüft, ob die für den API-Aufruf verwendete Methode GET

   2. Überprüft, ob der angeforderte Pfad viewData

   3. Überprüft, ob tenant_id der Pfad mit dem Pfad übereinstimmt, der dem Benutzer input.tenant_id zugeordnet ist. Dadurch wird sichergestellt, dass die Mandantenisolierung aufrechterhalten wird. Ein anderer Mandant kann, selbst mit einer identischen Rolle, nicht autorisiert werden, diesen API-Aufruf durchzuführen.

   4. Ruft eine Liste mit Rollenberechtigungen aus den externen Daten der Rollen ab und weist sie der Variablen zu. role_permissions Diese Liste wird mithilfe der vom Mandanten definierten Rolle abgerufen, die dem Benutzer in zugeordnet ist input.role.

   5. Überprüftrole_permissions, ob es die Berechtigung enthält viewData.

4. OPA gibt die folgende Entscheidung an den Data-Microservice zurück:

{
    "allowViewData": true
}

Dieser Prozess zeigt, wie RBAC und Tenant Awareness dazu beitragen können, eine Autorisierungsentscheidung mit OPA zu treffen. Um diesen Punkt weiter zu veranschaulichen, sollten Sie einen API-Aufruf von /viewData/tenant_b mit der folgenden Abfrageeingabe in Betracht ziehen:

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["viewData", "tenant_b"],
    "method": "GET"
}

Diese Regel würde dieselbe Ausgabe wie die OPA-Abfrageeingabe zurückgeben, obwohl sie für einen anderen Mandanten gilt, der eine andere Rolle innehat. Das liegt daran, dass dieser Aufruf für die RBAC-Daten bestimmt ist /tenant_b und den view_data_role darin enthaltenen RBAC-Daten immer noch die viewData entsprechende Berechtigung zugewiesen ist. Um dieselbe Art von Zugriffskontrolle durchzusetzen/updateData, können Sie eine ähnliche OPA-Regel verwenden:

default allowUpdateData = false
allowUpdateData = true {
    input.method == "POST"
    input.path = ["updateData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "updateData")
}

Diese Regel entspricht funktionell der allowViewData Regel, überprüft jedoch einen anderen Pfad und eine andere Eingabemethode. Die Regel gewährleistet weiterhin die Mandantenisolierung und überprüft, ob die vom Mandanten definierte Rolle dem API-Aufrufer die Berechtigung erteilt. Um zu sehen, wie dies durchgesetzt werden könnte, überprüfen Sie die folgende Abfrageeingabe für einen API-Aufruf an: /updateData/tenant_b

{
    "tenant_id": "tenant_b",
    "role": "view_data_role",
    "path": ["updateData", "tenant_b"],
    "method": "POST"
}

Diese Abfrageeingabe gibt, wenn sie mit der allowUpdateData Regel ausgewertet wird, die folgende Autorisierungsentscheidung zurück:

{
    "allowUpdateData": false
}

Dieser Anruf wird nicht autorisiert. Der API-Aufrufer ist zwar mit der richtigen verknüpft tenant_id und ruft die API mithilfe einer zugelassenen Methode auf, aber die input.role ist die vom Mandanten view_data_role definierte. Der view_data_role hat nicht die updateData Erlaubnis, daher ist der Aufruf von nicht autorisiert. /updateData Dieser Aufruf wäre für einen tenant_b Benutzer erfolgreich gewesen, der über das verfügtupdate_data_role.