Zugriffsrichtlinien

Zugriffsrichtlinien fügen attributbasierte Regeln (ABAC) über Rollen und Gruppen hinzu. Eine Richtlinie prüft, wer anfragt, was die Person tun möchte und in welchem Kontext, und erlaubt oder verweigert. Verwenden Sie Richtlinien, um einzuschränken, was Rollen und Gruppen sonst erlauben würden, zum Beispiel „niemand darf kritische Befehle von außerhalb des Anlagennetzwerks senden“ oder „Firmware darf nur aus einer mit einem Passkey angemeldeten Sitzung zugewiesen werden“. Richtlinien sind ein Werkzeug für Fortgeschrittene: Die meisten Organisationen benötigen nur Rollen und Gruppen.

Sie benötigen die Rolle Owner. Öffnen Sie Settings > Access Policies (Adresse /admin/access-policies).

So wird eine Entscheidung getroffen

Für jede geschützte Anfrage:

1. Jede aktive Richtlinie, deren Ziel passt (ihre Aktionen und Ressourcentypen) und deren Bedingungen alle zutreffen, wird in Prioritätsreihenfolge gesammelt (niedrigere läuft zuerst).
2. Wenn eine davon verweigert, wird die Anfrage abgelehnt. Verweigern hat immer Vorrang.
3. Andernfalls, wenn eine erlaubt, wird die Anfrage ausgeführt.
4. Wenn keine Richtlinie zutrifft, gilt die Entscheidung aus Rolle, Gruppe und Matrix („RBAC-Fallback“).

Richtlinien sind additive Einschränkungen: Schreiben Sie Anforderungen als Deny-Richtlinien. Eine Permit-Richtlinie, deren Bedingungen nicht zutreffen, verweigert nichts; die Anfrage fällt einfach auf die Rollenentscheidung zurück.

Welche Anfragen Richtlinien sehen

Richtlinien werden auf Routen geprüft, die die Richtlinien-Engine aufrufen. Die meisten Seiten und API-Routen von Hermetry tun dies; einige nicht, weil es kein angemeldetes Mitglied gibt, das beurteilt werden könnte (Anmeldung selbst, Geräteverbindungen, Webhook-Rückrufe, geplante Aufträge, Anfragen mit dem eigenen Vertrag eines API-Schlüssels wie SCIM). Die Seite Coverage listet genau auf, welche Routen die Engine erreichen und, bei den übrigen, „What guards it instead“. Prüfen Sie sie, bevor Sie sich auf eine Richtlinie verlassen.

Richtlinie erstellen

1. Wählen Sie New policy (oder Load examples, um mit fertigen Richtlinien zu beginnen).
2. Geben Sie einen Name, den Effect (Permit oder Deny (overrides any permit)) und die Priority (lower runs first) ein. Wählen Sie Create & edit.
3. Legen Sie unter Definition Folgendes fest:
   • Actions (comma-separated, empty = all): Berechtigungs-IDs wie iot_rpc.send.critical, iot_ota.assign.
   • Resource types (comma-separated, empty = all).
   • Description: warum die Richtlinie existiert.
   • Status: Active oder Inactive. Wählen Sie Save definition.
4. Wählen Sie unter Conditions für jeden Test Add condition. „Alle Bedingungen müssen zutreffen (AND), damit die Richtlinie greift.“ Wählen Sie Save conditions.

Eine Richtlinie ohne Bedingungen gilt für jede Anfrage, die ihrem Ziel entspricht.

Bedingungen

Jede Bedingung besteht aus einem Attribute, einem Operator und einem Value (oder Values (comma-separated)).

Attribut	Bedeutung
subject.role	Die eingebaute Rolle: OWNER, ADMIN, USER
subject.roles	Die Rolle plus die Gruppenschlüssel des Mitglieds
subject.permissions	Die Berechtigungen, die die Gruppen des Mitglieds gewähren
subject.id, subject.email	Das Mitglied
subject.department, subject.jobTitle	Aus dem Profil des Mitglieds, sofern gesetzt
subject.amr	Wie die Sitzung angemeldet wurde: pwd, otp, mfa, hwk (Passkey), fed:saml, fed:<provider>
subject.acr	Das daraus abgeleitete Vertrauensniveau: NONE, LOW (nur Passwort oder föderiert), SUBSTANTIAL (ein verifizierter zweiter Faktor), HIGH (ein Passkey)
environment.ip	Die Adresse des Aufrufers
environment.now, environment.method, environment.userAgent, environment.host	Zeit, HTTP-Methode, Browser, Hostname
action	Die geprüfte Berechtigung

Operatoren: equals, not equals, in list, not in list, contains, greater than, less than, exists, matches regex, DN equals (RDN).

Ein fehlendes Attribut wird als leer gelesen, was not equals und not in list erfüllt. Deshalb sind Verweigerungsregeln sicher und Erlaubnisregeln nicht.

Beispiele

Kritische und Rohbefehle verweigern, sofern die Sitzung nicht einen zweiten Faktor oder einen Passkey verwendet hat:

Feld	Wert
Effekt	Deny
Aktionen	iot_rpc.send.critical, iot_rpc.send.raw
Bedingung	subject.acr not in list SUBSTANTIAL, HIGH

Mitgliedern einer Gruppe contractors das Schreiben von Attributen oder das Senden von Befehlen untersagen, unabhängig von ihrer Rolle:

Feld	Wert
Effekt	Deny
Aktionen	iot_device.attributes.write, iot_rpc.send.basic, iot_rpc.send.privileged
Bedingung	subject.roles contains contractors

Um ein Recht nur einer Gruppe zu geben, ist die Matrix Access Rights meist einfacher als eine Richtlinie: Entfernen Sie die Berechtigung für Admin und setzen Sie sie für die Gruppe. Siehe Groups and permissions.

Shadow-Modus, Access Tester und Entscheidungsprotokoll

Werkzeug	Ort	Verwendung
Shadow Mode	Settings auf der Richtlinienseite (Access Control Settings)	„Richtlinien werden ausgewertet und Entscheidungen protokolliert, aber ein „deny“ blockiert die Anfrage NIE.“ Standardmäßig aus. Schalten Sie es ein, bevor Sie eine neue Richtlinie erzwingen, beobachten Sie das Protokoll und schalten Sie es danach wieder aus.
Access tester	Simulator	„Eine Entscheidung gegen aktive Richtlinien trocken durchspielen – nichts wird gespeichert oder protokolliert.“ Geben Sie Subject id, Subject role, Action, Resource type, Resource ownerId, Environment IP und eine RBAC fallback role ein und wählen Sie dann Evaluate. Die Policy trace zeigt Ziel und Regeln jeder Richtlinie.
Decision log	Decision log	Jede ausgewertete Anfrage mit Effect, Action, Reason (Policy permit, Explicit deny, RBAC fallback, Default deny, Not applicable) und Subject. Verweigerungen im Shadow-Modus sind mit Shadow markiert.

Decision Log Mode (All decisions, Deny only, Off; Standard: all) und Permit Log Sample Rate (%) bestimmen, wie viel in das Audit-Protokoll geschrieben wird. Verweigerungen werden immer protokolliert.

Bewährte Praxis

• Beginnen Sie mit Load examples und lesen Sie die Beispiele, bevor Sie eigene schreiben.
• Verwenden Sie Verweigerungsrichtlinien mit engen Aktionslisten. Vermeiden Sie Richtlinien ohne Aktionen: Sie beurteilen jede Anfrage.
• Sperren Sie niemals die Owner aus: Testen Sie jede Richtlinie mit der Rolle eines Owners im Access Tester.
• Änderungen wirken sofort auf allen Knoten.