--- title: "IAM, Zero Trust und sichere Cloud-Zugriffe | SKAFFON" description: "IAM-Beratung und Umsetzung: Keycloak, SSO mit OIDC und SAML, Rollenmodelle, privilegierter Zugriff, Workload-Identitäten und Secret-Rotation." url: https://skaffon.de/cybersecurity/iam-zero-trust/ --- ![Leuchtender Fingerabdruck auf einem dunklen, kreisrunden Scanner mit konzentrischen Linien](/_astro/fingerabdruck-biometrische-anmeldung.B2iy40Yd_2fnJvW.jpg) 1. [Startseite](/) 2. [Cybersecurity](/cybersecurity/) 3. IAM, Zero Trust und sichere Cloud-Zugriffe 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. [Projekt anfragen](/projekt-anfragen/) [Zugriffsmodell ansehen](/cybersecurity/iam-zero-trust/#zugriffsmodell-je-identitaetsklasse) - SSO über OIDC und SAML, Keycloak oder Ihr vorhandener IdP - Admin-Rechte befristet, genehmigt und protokolliert - Kurzlebige Identitäten statt statischer Schlüssel Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## 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](/cybersecurity/nis2-beratung/) oder [DORA](/cybersecurity/dora-it-resilienz/). Einordnung ## Zero Trust ist eine Architektur, kein Produkt Das NIST beschreibt Zero Trust in der [Special Publication 800-207 (Zero Trust Architecture, August 2020)](https://csrc.nist.gov/pubs/sp/800/207/final) 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. ![Zahlenschloss mit Schlüsseln auf einer Computertastatur vor unscharfem Holzhintergrund](/_astro/vorhaengeschloss-schluessel-tastatur.By4qM1QN_Z135uAd.jpg) Zugriffsmodell ## 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. __Standardmodell: Authentifizierung, Autorisierung, Lebensdauer und Protokollierung je Identitätsklasse__ | 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 | Referenzarchitektur ## 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. Reihenfolge 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. 1. 01 ### Identitäten und Zugänge inventarisieren Ohne Überblick keine Entscheidung. Auch verwaiste Konten und Dienstkonten erfassen. 2. 02 ### MFA für Administratoren und Fernzugriffe Danach für alle Mitarbeitenden, mit phishing-resistenten Verfahren, wo Ihre Umgebung sie unterstützt. 3. 03 ### Zentraler IdP mit SSO Die Anwendungen mit dem höchsten Schutzbedarf zuerst. 4. 04 ### Privilegierten Zugriff befristen Befristen und protokollieren; Dauer-Administratorrechte abbauen. 5. 05 ### Statische Schlüssel ersetzen Passwörter und Schlüssel in Pipelines und Konfigurationen durch kurzlebige Identitäten und dynamische Secrets ablösen. 6. 06 ### Autorisierung je Ressource Segmentierung, Netzregeln nach Default-Deny, Prüfung von Identität und Gerätezustand an der Ressource statt Netzvertrauen. 7. 07 ### Berechtigungsreview als Routine Festgelegter Turnus, Verantwortlicher je Rolle, Protokoll. 8. 08 ### Messen und nachschärfen Abdeckung von MFA, Zahl der Dauerrechte, Alter der Schlüssel. Technische 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](https://www.keycloak.org/) 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](https://openbao.org/docs/secrets/) 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](/cybersecurity/datensicherheit/). - ### SPIFFE und SPIRE für Workload-Identität [SPIFFE](https://spiffe.io/docs/latest/spiffe-about/overview/) 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](https://kubernetes.io/docs/concepts/security/rbac-good-practices/) Leitlinien wie Berechtigungen auf Namespace-Ebene zu vergeben, Platzhalterrechte zu vermeiden, `cluster-admin` nur 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](/cybersecurity/kubernetes-security/). Leistungsumfang ## 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. ![Gläsernes blaues Cloud-Symbol mit Datenschichten über einem silbernen Vorhängeschloss](/_astro/cloud-symbol-ueber-vorhaengeschloss.Dnhk8oo2_Z1ad43d.jpg) Arbeitsweise ## 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. Ihr IdP bleibt Ihrer Wir übernehmen die Hoheit über Ihre Identitätsdaten nicht: Der IdP gehört Ihnen, Betrieb durch uns nur nach gesondertem Auftrag. Voraussetzungen ## 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 anfragen](/projekt-anfragen/) Abgrenzung ## 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. Weiterlesen ## Angrenzende Sicherheitsthemen - ### [Cybersecurity-Überblick](/cybersecurity/) Alle Sicherheitsleistungen von SKAFFON im Zusammenhang. Weiter - ### [Cloud Security](/cybersecurity/cloud-security/) Die Plattformseite zu Cloud-Konfiguration und -Absicherung. Weiter - ### [Kubernetes Security](/cybersecurity/kubernetes-security/) RBAC, Service-Accounts und Härtung von Clustern. Weiter - ### [Datensicherheit](/cybersecurity/datensicherheit/) Schlüsselbetrieb und Schutz von Daten. Weiter Erstgespräch ## Zeigen Sie uns Ihre Anwendungen und Identitätsquellen Beschreiben Sie Anwendungen, Identitätsquellen und Ziel. [Projekt anfragen](/projekt-anfragen/) [Cybersecurity-Überblick](/cybersecurity/)