Identität und Zugriff
IAM, Zero Trust und sichere Cloud-Zugriffe
SKAFFON entwirft und implementiert Identitäts- und Zugriffsmodelle für Cloud, Kubernetes und Anwendungen: SSO mit OpenID Connect und SAML, Rollen nach Least Privilege, befristeter Admin-Zugriff, Identitäten für Dienste und Secrets, die sich selbst rotieren. Für IT-Leitung, CISO und CTO, die gewachsene Zugriffe aufräumen und Zero Trust als Architektur umsetzen wollen.
- SSO über OIDC und SAML, Keycloak oder Ihr vorhandener IdP
- Admin-Rechte befristet, genehmigt und protokolliert
- Kurzlebige Identitäten statt statischer Schlüssel
01Ausgangslage
Fünf Anzeichen, dass Ihre Zugriffe aufgeräumt werden müssen
Sie erkennen sich in mindestens einem davon wieder? Dann beginnt die Arbeit beim Inventar, nicht bei einem Produkt.
-
Gewachsene Zugänge
Geteilte Konten, Administratorrechte „auf Zuruf“ und Rechte, die nach Rollenwechseln nie entzogen wurden.
-
Jede Anwendung führt eigene Benutzer
MFA gibt es nur dort, wo es jemand nachgerüstet hat.
-
Statische Schlüssel im Umlauf
Dienste sprechen mit langlebigen Schlüsseln, die in Repositories, Pipelines oder Konfigurationsdateien liegen.
-
Dauerzugänge für Dienstleister
Partner haben Zugänge ohne Ablauf und ohne Überblick, wer sie noch nutzt.
-
Eine Auflage verlangt Nachweise
Eine Prüfung oder Vorgabe fordert belegbare Zugriffskontrolle, etwa nach NIS2 oder DORA.
02Einordnung
Zero Trust ist eine Architektur, kein Produkt
Das NIST beschreibt Zero Trust in der Special Publication 800-207 (Zero Trust Architecture, August 2020) als eine Reihe von Sicherheitsparadigmen, die Schutzmaßnahmen von statischen, netzbasierten Perimetern auf Nutzer, Assets und Ressourcen verlagern. Keinem Asset und keinem Benutzerkonto wird allein wegen seiner Netzposition implizit vertraut; Authentifizierung und Autorisierung (von Subjekt und Gerät) sind getrennte Funktionen; der Schutz richtet sich auf die Ressourcen selbst. Für die Praxis heißt das:
- Kein Produkt zum Kaufen. Zero Trust besteht aus Identität, Gerätezustand, Autorisierung je Ressource, Segmentierung und Protokollierung.
- Schrittweise einführbar. Wir beginnen dort, wo Schutzbedarf und Lücke am größten sind, nicht mit einem Komplettumbau.
- Kein umbenanntes VPN. Wer ein VPN nur „Zero Trust“ nennt, ohne Autorisierung je Ressource, ändert nichts am Modell.
03Zugriffsmodell
Wer wie auf was zugreift: sechs Identitätsklassen im Überblick
Die Matrix zeigt unser Standardmodell. Die Spalten sind die Entscheidungen, die ein Zugriffskonzept treffen muss. Welche Ausprägung für Sie passt, folgt aus Schutzbedarf und Betriebsmodell.
| Identitätsklasse | Authentifizierung | Autorisierung | Lebensdauer des Zugangs | Protokollierung |
|---|---|---|---|---|
| Mitarbeitende (Standardzugriff) | SSO über zentralen IdP, MFA | Rollen aus dem IdP, Attribute wie Abteilung oder Gerätezustand, soweit sinnvoll | Sitzung mit Ablauf, Rechte per Rollenzuordnung | Anmeldungen, Rollenänderungen |
| Administratoren (privilegiert) | MFA, möglichst phishing-resistent; getrennte Administrationskonten | Rechte nur über befristete Rollen mit Genehmigung (Just-in-Time) | Minuten bis Stunden, automatisch entzogen | Jede privilegierte Sitzung und jeder Befehl, soweit technisch möglich |
| Notfall-Zugang (Break-Glass) | Getrennte Konten, außerhalb des normalen IdP-Pfads gesichert | Voller Zugriff, nur für definierte Notfälle | Dauerhaft vorhanden, Nutzung löst Alarm aus | Jede Nutzung mit Alarmierung und Nachprüfung |
| Dienste und Workloads | Kurzlebige Identität (zum Beispiel OIDC-Token der Plattform oder SPIFFE-Identität), keine statischen Schlüssel | Minimale Rechte je Dienst, Netz- und Identitätsregeln | Stunden oder kürzer, automatisch erneuert | Aufrufe auf Plattform- und Dienstebene |
| Partner und Dienstleister | Eigene Konten im IdP oder Federation mit deren IdP, MFA | Rollen auf Projekt oder Ressource begrenzt | Befristet auf Vertrag oder Auftrag | Vollständig, regelmäßig geprüft |
| Kundenidentitäten (CIAM) | Anmeldung über OIDC, optional MFA und Social Login nach Anforderung | Rechte aus Mandant und Rolle, strikt mandantengetrennt | Sitzungsregeln nach Anwendung | Anmeldungen, sicherheitsrelevante Änderungen |
04Referenzarchitektur
Identitätsgestützter Zugriff: Prüfung bei jedem Zugriff
Der Weg eines Zugriffs: von den Identitätsklassen über IdP, Secrets-Management und Workload-Identität zur Autorisierung je Ressource, begleitet von Protokollierung und Berechtigungsreview.
05Reihenfolge der Einführung
Acht Schritte zu Zero Trust, geordnet nach Risikosenkung
Die Reihenfolge ist unsere Empfehlung aus der Praxis, keine Norm. Sie priorisiert Maßnahmen, die Risiko schnell senken und Voraussetzung für die nächsten sind. Schritt 3 und 5 sind meist die größten Aufwandsblöcke, weil sie Anwendungen berühren; wir planen sie pro Anwendung und nicht als Big Bang.
- 01
Identitäten und Zugänge inventarisieren
Ohne Überblick keine Entscheidung. Auch verwaiste Konten und Dienstkonten erfassen.
- 02
MFA für Administratoren und Fernzugriffe
Danach für alle Mitarbeitenden, mit phishing-resistenten Verfahren, wo Ihre Umgebung sie unterstützt.
- 03
Zentraler IdP mit SSO
Die Anwendungen mit dem höchsten Schutzbedarf zuerst.
- 04
Privilegierten Zugriff befristen
Befristen und protokollieren; Dauer-Administratorrechte abbauen.
- 05
Statische Schlüssel ersetzen
Passwörter und Schlüssel in Pipelines und Konfigurationen durch kurzlebige Identitäten und dynamische Secrets ablösen.
- 06
Autorisierung je Ressource
Segmentierung, Netzregeln nach Default-Deny, Prüfung von Identität und Gerätezustand an der Ressource statt Netzvertrauen.
- 07
Berechtigungsreview als Routine
Festgelegter Turnus, Verantwortlicher je Rolle, Protokoll.
- 08
Messen und nachschärfen
Abdeckung von MFA, Zahl der Dauerrechte, Alter der Schlüssel.
06Technische Bausteine
Keycloak, OpenBao, SPIFFE, Cloud-IAM: wofür wir was einsetzen
Die Wahl folgt der Anwendung und Ihrem Betriebsmodell, nicht dem Produkt.
-
Keycloak als eigener IdP
Keycloak beschreibt sich als Identity-and-Access-Management-Lösung auf Basis von OpenID Connect, OAuth 2.0 und SAML, mit SSO, Identity Brokering gegenüber vorhandenen OIDC- oder SAML-Identitätsanbietern und Anbindung an LDAP oder Active Directory. Es ist laut Projektseite ein Incubating-Projekt der Cloud Native Computing Foundation. Wir setzen es ein, wenn Sie einen eigenen, selbst betriebenen IdP brauchen, zum Beispiel für Kunden- oder Partnerzugänge oder bei hohen Souveränitätsanforderungen. Ist bereits ein IdP im Einsatz, etwa in Ihrer Microsoft-Umgebung, binden wir ihn an, statt ein zweites System aufzubauen.
-
OIDC und SAML für SSO
OIDC für moderne Anwendungen und APIs, SAML für Anwendungen, die es verlangen. Anwendungen, die keines von beiden sprechen, behandeln wir einzeln.
-
OpenBao für Secrets
Laut Dokumentation mit Engines unter anderem für Key/Value, Datenbanken (dynamisch erzeugte Zugangsdaten auf Abruf), PKI, SSH, Kubernetes und Transit. Dynamische Zugangsdaten sind der Weg, statische Datenbankpasswörter abzulösen; die Rotation entfällt dann als manuelle Aufgabe. Zum Betrieb von Schlüsseln siehe Datensicherheit.
-
SPIFFE und SPIRE für Workload-Identität
SPIFFE ist laut Projektseite ein Satz offener Standards zur sicheren Identifikation von Softwaresystemen; SVIDs sind kurzlebige kryptographische Identitätsdokumente (X.509 oder JWT). SPIRE ist eine Implementierung, die laut der Tabelle der Projektseite X.509- und JWT-SVIDs, attestierungsbasierte Ausstellung und eine Workload API bietet. Wir setzen es dort ein, wo Dienste über Cluster- oder Cloud-Grenzen hinweg gegenseitig authentifiziert werden müssen. Für Dienste innerhalb eines Kubernetes-Clusters reichen oft die Bordmittel der Plattform; wir bewerten das im Einzelfall, ohne SPIRE als Selbstzweck einzuführen.
-
Cloud-IAM und Kubernetes-RBAC als Durchsetzung
AWS IAM, Azure-Rollenmodell und STACKIT setzen die Entscheidungen durch. Für Kubernetes beschreibt die offizielle RBAC-Dokumentation Leitlinien wie Berechtigungen auf Namespace-Ebene zu vergeben, Platzhalterrechte zu vermeiden,
cluster-adminnur bei Bedarf zu verwenden und das automatische Einhängen von Service-Account-Tokens zu vermeiden, wo es nicht gebraucht wird. Mehr dazu unter Kubernetes Security.
07Leistungsumfang
Von der Bestandsaufnahme bis zur Übergabe der Rechtematrix
In sieben Arbeitspaketen gehen wir von Ihrem Ist-Stand zu einem belegbaren Zugriffsmodell:
- Bestandsaufnahme. Identitätsquellen (Verzeichnisse, Cloud-Konten, Anwendungs-Konten), Anmeldewege, privilegierte Zugänge, Dienstkonten, Secrets und deren Speicherorte.
- Zielmodell. Identitätsklassen, Rollen, Autorisierungsmodell, Anmelde- und Sitzungsregeln (siehe Matrix oben).
- Zentrale Identität (IdP). Einführung oder Härtung von Keycloak oder Anbindung an Ihren vorhandenen IdP; SSO über OIDC und SAML.
- Rollen und Berechtigungen. Rollenmodell, Zuordnung zu Cloud-Rollen und Kubernetes-RBAC, Berechtigungsreview-Verfahren.
- Privilegierter Zugriff. Just-in-Time mit Genehmigung und Protokollierung, Break-Glass-Konten mit Überwachung.
- Workload-Identitäten und Secrets. Kurzlebige Identitäten, Secrets-Management mit Rotation, Wegfall statischer Schlüssel in Pipelines.
- Nachweise und Übergabe. Rollen- und Rechtematrix, Konfigurationsstände, Reviewprotokolle, Runbooks, Einweisung.
08Arbeitsweise
Erst lesen, dann ändern: wie wir in Ihrer Umgebung arbeiten
Wir arbeiten zuerst lesend (Inventar, Konfiguration) und ändern Rollen, Richtlinien und Konfigurationen nur über Ihre Änderungsprozesse und IaC-Reviews. Zugangsdaten werden nicht in Repositories abgelegt; für unseren eigenen Zugriff nutzen wir befristete Zugänge.
Die Integration prüft Verzeichnisse (LDAP, Active Directory) und Anwendungsschnittstellen. Anwendungen, die weder OIDC noch SAML sprechen, brauchen Anpassungsaufwand oder eine vorgelagerte Lösung.
09Voraussetzungen
Was wir von Ihrer Seite für den Start brauchen
- Überblick über Anwendungen, Identitätsquellen und vorhandene SSO-Lösungen.
- Eine entscheidungsbefugte Person für Rollenmodell und Berechtigungsfreigabe sowie Verantwortliche je Anwendung.
- Lesender Zugriff auf Cloud-Konten, Cluster und Verzeichnisdienste, vergeben nach Least Privilege.
- Anforderungen aus Aufsicht, Kunden oder Verträgen an Zugriffskontrolle und Nachweise.
Aufwand
Was den Aufwand eines IAM-Projekts bestimmt
Den Aufwand bestimmen vor allem die Zahl der Anwendungen und Identitätsquellen, der Anteil von Anwendungen ohne OIDC- oder SAML-Unterstützung, die Zahl der Plattformen (Cloud-Konten, Cluster), die Tiefe der Umsetzung (Konzept, Umsetzung, Betrieb des IdP) und die Komplexität des Rollenmodells. Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang.
Projekt anfragen10Abgrenzung
IAM mit SKAFFON: was Sie bekommen und was nicht
Das liefern wir
- Ein Zugriffskonzept mit Rollenmodell, umgesetzt in Ihrem IdP, Ihren Cloud-Konten und Clustern.
- Befristete Admin-Zugänge, kurzlebige Workload-Identitäten und Secrets-Management mit Rotation.
- Rollen- und Rechtematrix, Reviewprotokolle und Runbooks zur Übergabe.
Das gehört nicht dazu
- Ein reines Lizenzprodukt, das ohne Konzept und Anpassung Zero Trust „liefert“.
- Personal- oder Berechtigungsentscheidungen für Sie: Rollenfreigabe bleibt Ihre Aufgabe.
- Ein Security-Operations-Betrieb zur Auswertung von Anmeldeereignissen.
- Ein Zertifikat oder Testat für Dritte.
11Weiterlesen
Angrenzende Sicherheitsthemen
-
Cybersecurity-Überblick
Alle Sicherheitsleistungen von SKAFFON im Zusammenhang.
-
Cloud Security
Die Plattformseite zu Cloud-Konfiguration und -Absicherung.
-
Kubernetes Security
RBAC, Service-Accounts und Härtung von Clustern.
-
Datensicherheit
Schlüsselbetrieb und Schutz von Daten.
Erstgespräch
Zeigen Sie uns Ihre Anwendungen und Identitätsquellen
Beschreiben Sie Anwendungen, Identitätsquellen und Ziel.