Eine Access Control List (ACL) in Access Gate ist die Tabelle, die für jede Sitzung eine Frage beantwortet: Darf dieser Principal dieses Asset über dieses Protokoll jetzt erreichen? Die Tabelle ist pro Enklave bearbeitbar, über die gesamte Bereitstellung durchsuchbar und an Ihren Identity Provider gebunden.
Aufbau eines ACL-Eintrags
Jede Zeile verknüpft fünf Elemente:
| Feld | Beispiel | Hinweise |
|---|---|---|
| Principal | alice@acme.com, group:ot-ops, asset A | Ein Benutzer, eine Gruppe aus Ihrem IdP oder ein anderes Asset |
| Asset | plc-42.ot-cell-a, all assets in enclave | Ein bestimmtes Asset oder alle Assets in der Enklave |
| Protokoll | rdp, ssh, https, any | Die für die Sitzung erlaubten Protokolle |
| Berechtigung | allow, block | Standard ist Deny, nur allow-Regeln öffnen einen Pfad |
| Erweiterte Konfiguration | tls required, VPN allowed, Secured Remote Acces, Access Agreement | Spezifische Konfigurationen zusätzlich zur Berechtigung |
ACLs für Benutzer
Das individuelle Hinzufügen jedes Benutzers skaliert schlecht. Access Gate unterstützt ACLs, die an Benutzergruppen gebunden sind, die aus Ihrem IdP synchronisiert werden, Entra ID, Okta oder Microsoft 365.
Gruppenbasierte ACL hinzufügen
- Synchronisieren Sie zuerst Ihre IdP-Gruppen: siehe Benutzerverzeichnis synchronisieren (Entra ID).
- Navigieren Sie zu Enclaves → [Ihre Enklave] → Access Control.
- Klicken Sie auf Add rule.
- Wählen Sie unter Principal die Option Group und wählen Sie die IdP-Gruppe aus.
- Wählen Sie die Assets und Protokolle aus.
- Speichern.
Die Gruppenmitgliedschaft wird bei jeder Sitzung neu ausgewertet, der Benutzer muss sich nicht erneut anmelden, damit eine Mitgliedschaftsänderung wirksam wird.
Benutzerspezifische ACL hinzufügen
Die Zugriffsverwaltung auf Benutzerebene ist ebenfalls möglich.
Standard: Deny
Access Gate arbeitet nach dem Default-Deny-Prinzip: Eine Sitzung wird abgelehnt, sofern keine passende allow-Regel existiert. Es gibt kein implizites „Mitglieder der Enklave dürfen alles", jedes Protokoll auf jedem Asset muss explizit freigegeben werden.
Das bedeutet, dass die erstmalige Einrichtung einer Enklave bewusst restriktiv wirkt. Planen Sie folgende Schritte:
- Enklave erstellen und Mitglieder hinzufügen.
- Traffic-Inspektion aktivieren, um zu beobachten, was die Mitglieder tatsächlich versuchen.
- Beobachtete Verbindungen in ACL-Regeln übersetzen.
Der Schnellstart führt durch diesen Ablauf.
Änderungen werden auditiert
Jede ACL-Änderung wird in der Änderungshistorie der Enklave erfasst (siehe Änderungshistorie der Enklave anzeigen), mit Operator, Zeitstempel sowie Vor- und Nachher-Werten. Änderungen an Access-Screen-Berechtigungen werden auf dieselbe Weise protokolliert.
Zusammenfassung
Wir haben pro Enklave ACL-Regeln geschrieben, die einem Principal (Benutzer, IdP-Gruppe oder Asset) Zugriff auf bestimmte Assets über bestimmte Protokolle gewähren, nach dem Default-Deny-Prinzip.
Greifen Sie hierzu, wenn Sie feingranulare, gruppenbasierte Kontrolle darüber benötigen, wer was und wie erreicht, und Zugriffsentscheidungen über Ihren Identitätsanbieter skalieren möchten statt über Änderungen Benutzer für Benutzer.