defense

[DEFENSE_REPORT] Identity-Centric Governance: Keycloak, OIDC & Zero-Trust NAC

Dieter Bänisch

Dieter Bänisch

— 2 min read
[DEFENSE_REPORT] Identity-Centric Governance: Keycloak, OIDC & Zero-Trust NAC

In hochverfügbaren KRITIS-Infrastrukturen ist der klassische "Schutzwall-Gedanke" tot. Wer Sicherheit heute noch an Switch-Ports oder IP-Listen festmacht, hat bereits verloren. Echte Resilienz entsteht durch einen Security & Identity Backbone, der Identität über alle Ebenen – vom Container bis zum physischen Kupferport – erzwingt.

1. Die Architektur: Security & Identity Backbone

Unser Blueprint [image_2] bricht das Silo-Denken auf. Wir zentralisieren die Autorität in einem dedizierten Backbone, der Governance, Identität und Observability vereint.

  • Zentrale Governance: NetBox fungiert als Single Source of Truth (SSoT). Jede Änderung wird über GitLab CI/CD validiert und ausgerollt.
  • Identity Control Plane: Keycloak (OIDC) liefert den Identitäts-Kontext für alle administrativen Zugriffe.
  • Network Access Control (NAC): Aruba ClearPass nutzt diesen Kontext, um dynamische Policies in der Unified Fabric (OT & IT) durchzusetzen.
  • AI-Intelligence: Sentinel Core (Local LLM) verarbeitet den Threat-Context aus dem SIEM (Elastic/Wazuh) ohne Datenabfluss nach extern.

2. Implementierung: OIDC-Härtung für NetBox

Um "Shadow-Admins" zu verhindern, binden wir die SSoT-Instanz (NetBox) direkt via OpenID Connect an Keycloak an. Jede administrative Sitzung ist kryptographisch signiert und MFA-geschützt.

Konfigurations-Snippet (docker-compose.override.yml):

codeYaml

environment:
  REMOTE_AUTH_ENABLED: "True"
  REMOTE_AUTH_BACKEND: "social_core.backends.open_id_connect.OpenIdConnectAuth"
  SOCIAL_AUTH_OIDC_KEY: "netbox-production"
  SOCIAL_AUTH_OIDC_SECRET: "${KEYCLOAK_NETBOX_SECRET}"
  SOCIAL_AUTH_OIDC_OIDC_ENDPOINT: "https://auth.baenisch.com/realms/Ontras"
  REMOTE_AUTH_AUTO_CREATE_USER: "True"

Wichtig: Der Redirect-URI-Endpoint muss zwingend auf /oauth/complete/oidc/ enden, um den Handshake mit Keycloak erfolgreich abzuschließen.

3. Der GitOps-Zyklus: Change-Management ohne CLI

Änderungen an der NAC-Policy oder den VLAN-Strukturen erfolgen ausschließlich deklarativ.

  1. Terraform: SSoT-Update in NetBox.
  2. Git Push: GitLab Pipeline triggert Ansible-Playbooks.
  3. Audit Trail: Jeder Commit wird automatisch in das Elastic SIEM gestreamt.

4. Operational Hardening: Troubleshooting aus dem Maschinenraum

Theorie ist schön, aber KRITIS-Sicherheit entscheidet sich bei den Day-2 Operations. Hier sind drei reale Szenarien und deren Lösung:

  • Issue: Ansible-Parsing-Fehler bei AOS-CX
    • Ursache: Inline-Kommentare in der hosts.ini korrumpieren den ansible_network_os String.
    • Fix: Striktes Clean-Up der Inventar-Dateien. Kommentare gehören in die Dokumentation, nicht in die Variablendeklaration.
  • Issue: Privilege Escalation auf Aruba Leafs
    • Ursache: RADIUS-User landen standardmäßig im Operator-Level (Level 1).
    • Fix: Zuweisung der administrators-Gruppe auf der Switch-CLI: user admin group administrators password plaintext <PWD>.
  • Issue: LVM-Partition "/" vollgelaufen
    • Ursache: ML-Bibliotheken und Docker-Images auf dem Management-Host sprengen den Standard-LVM.
    • Fix: Dynamische Erweiterung im laufenden Betrieb: lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv && resize2fs /dev/ubuntu-vg/ubuntu-lv.

Fazit

Sicherheit ist kein Produkt, sondern ein deterministischer Prozess. Durch die konsequente Kopplung von Identität (Keycloak) und Infrastruktur-Code (Ansible/Terraform) eliminieren wir den Faktor Mensch als größte Sicherheitslücke.

Status: Backbone Operational
Architekt: Dieter Bänisch

Read more