SaaS-Zugangsdatenverwaltung: 5 Schritte zur Zentralisierung

Illustration einer Cloud mit der Beschriftung „SaaS

SaaS-Zugangsdatenverwaltung bezeichnet die Praxis, jedes Passwort, jeden gemeinsam genutzten Login und jeden Zugriffsschlüssel zu erfassen, den ein Unternehmen für Cloud-Anwendungen wie Salesforce oder Slack verwendet, und zu kontrollieren, wer jeden einzelnen davon einsehen und nutzen kann. Es bedeutet, jede Zugangsdaten als Inventar zu behandeln, das Sie finden, gezielt teilen und entziehen können, wenn Mitarbeiter das Unternehmen verlassen. Das Ziel ist ein kontrollierter Tresor für menschliche Passwörter und maschinelle Secrets — nicht fünf Tools, von denen jedes nur einen Teil der Wahrheit enthält.

Die meisten Unternehmen nutzen mehr SaaS-Anwendungen, als die IT offiziell erfasst: ein CRM-Login in einem Browser-Profil, ein Gmail-Passwort, das über Slack geteilt wird, Staging-Datenbank-Strings, die in einem privaten Repository liegen. Niemand ist zentral für diese Logins verantwortlich, was bedeutet, dass auch niemand sie überwacht. Jedes einzelne ist ein offener Einstiegspunkt, der monatelang bestehen kann, bevor jemand bemerkt, dass er missbraucht wurde.

Passwork ist für genau diese Aufgabe konzipiert: ein Business-Passwort- und Secrets-Manager, den Sie auf Ihren eigenen Servern oder als Cloud-Dienst betreiben können, mit gemeinsam genutzten Tresoren, rollenbasiertem Zugriff, LDAP/SSO und einer REST API für die Automatisierung. Die fünf Schritte unten funktionieren gleichermaßen für Teams, die Passwork bereits nutzen, wie für Teams, die noch ein System evaluieren.

Wichtige Erkenntnisse

Ein SaaS-Zugangsdateninventar, das nach Risiko und Verantwortlichem gruppiert ist, deckt Schatten-Zugriffe auf, bevor sie zu einem Sicherheitsvorfall werden.
Eine Tresor-Struktur hilft nur dann, wenn sie widerspiegelt, wie Teams bereits nach Zugriffen suchen — nicht das alte Chaos, das sie ersetzt.
Migration funktioniert nur mit einem festen Umstellungstermin. Chat, Tabellen und einen Tresor parallel zu betreiben, verlagert das Chaos nur.
Zugriff über Gruppen statt individueller Berechtigungen macht das Offboarding zu einer einzelnen Aktion anstatt einer Suche in fünf Tools.
Die Anbindung von SSO, LDAP/AD und einer CI-kompatiblen API erweitert die Kontrolle auf maschinelle Secrets, nicht nur auf menschliche Logins.

Was als SaaS-Zugangsdaten zählt

SaaS-Zugangsdaten sind alles, was verwendet wird, um Identität nachzuweisen und Zugang zu erhalten: ein Passwort, ein gemeinsam genutzter Login, ein API-Schlüssel oder ein Sicherheitszertifikat. Die Liste der SaaS-Anwendungen eines Unternehmens (wofür es bezahlt) ist nicht dasselbe wie die Liste seiner Zugangsdaten (wie auf jede Anwendung tatsächlich zugegriffen wird). Eine Anwendung kann mehrere haben: zehn Personen, die sich über SSO anmelden, ein gemeinsam genutztes Abrechnungskonto und ein API-Schlüssel, den ein Skript verwendet, um Berichte abzurufen.

Die Anwendungen zu kennen, die ein Unternehmen nutzt, zeigt, wofür es bezahlt. Die Zugangsdaten zu kennen zeigt, wer Zugang hat, und das ist die Liste, die für die Sicherheit relevant ist.

Schritt 1: Erstellen Sie Ihr SaaS-Zugangsdatenverwaltungs-Inventar

Beginnen Sie mit einer SaaS-Zugangsdatenliste. Gruppieren Sie nach Risiko. Führen Sie während dieses Schritts keine „Aufräumarbeiten" durch. Aufräumen während der Inventur schafft ein zweites Chaos. Erfassen, dann verschieben. Notieren Sie für jede SaaS-Anwendung und jeden internen Dienst:

Um welches Tool es sich handelt (Name der SaaS-Anwendung)
Wer für das Konto verantwortlich ist (Person oder Team)
Wo das Secret aktuell liegt (Chat, Wiki, CI-Variable, Klebezettel)
Wer es im nächsten Quartal benötigt (neue Mitarbeiter, Projekte oder Teams)
Was ausfällt, wenn es verschwindet (abhängige Workflows, Integrationen oder Dienste)

Beispiel:

Feld	Wert
Tool	Marketing-Analysetool
Verantwortlicher	Marketing-Leitung
Aktueller Speicherort	In einen gemeinsamen Slack-Kanal eingefügt
Benötigt von (nächstes Quartal)	Zwei neue Mitarbeiter, die zum Marketing-Team stoßen
Auswirkung bei Verlust	Team verliert Zugang zu Kampagnen-Reporting-Dashboards

Ein solcher Eintrag sagt jedem genau, wen er fragen muss, wo er suchen soll und was auf dem Spiel steht.

Schritt 2: Gestalten Sie Tresore und Ordner entsprechend Ihrer Arbeitsweise

Ein Passwort-Tresor unterstützt die SaaS-Zugangsdatenverwaltung nur dann, wenn seine Ordnerhierarchie widerspiegelt, wie Teams bereits nach Zugriffen suchen — nicht wie das alte, chaotische System gewachsen ist. Zentralisierung scheitert, wenn der neue Speicherort das Chaos nur verlagert. Wählen Sie eine Hierarchie, die jemand in einem Satz erklären kann. Gruppieren Sie Tresore nach Abteilung oder Produkt, dann teilen Sie Infrastruktur-Secrets nach Umgebung auf.

Beispiel einer Zugangsdaten-Hierarchie in Passwork: gemeinsam genutzte Tresore, Abteilungsordner und verschachtelte Unterordner mit einzelnen Passworteinträgen — Beispiel einer Zugangsdaten-Hierarchie in Passwork

Die Verschachtelung bleibt in den meisten Bereichen flach. Zwei Ebenen sind normalerweise ausreichend: ein Tresor für das Team, ein Ordner für die Tool-Kategorie. Fügen Sie eine dritte Ebene nur hinzu, wenn ein Ordner der zweiten Ebene allein nicht einheitlich ist. Wenn ein Ordner bereits alles beschreibt, was er enthält, hören Sie dort auf.

Beispiel für eine Datenhierarchie:

Tresor: Marketing

Ordner: Analysetools

Google Analytics — Admin-Login

Mixpanel — Projekt-Token

Tresor: Vertrieb

Ordner: CRM-Systeme

Salesforce — Admin-Login

HubSpot — Login

Ordner: Outreach-Tools

Outreach.io — Login

Salesloft — Login

Tresor: IT-Abteilung

Ordner: Cloud-Konsolen

Verschachtelter Ordner: Cloud-Konten

AWS — Root-Konto

Azure AD — Global Admin

Grafana Cloud — Login

Ordner: Monitoring

Datadog — Application Key

Zwei Zielgruppen nutzen denselben Baum unterschiedlich. Menschen navigieren nach Teamnamen. Pipelines rufen nach Ordner-ID ab, weshalb Onboarding-Dokumentationen für DevOps Umgebungs-basierte Ordner empfehlen: Ein Job kann alles, was er braucht, mit einer einzigen --folder-id abrufen, anstatt SaaS-Zugangsdaten in Code einzufügen.

Namensregeln helfen mehr als tiefe Verschachtelung:

Bevorzugen Sie stripe-prod-dashboard gegenüber Neues Passwort (2)
Setzen Sie die Umgebung in den Namen oder Ordner, nicht nur in jemandes Kopf
Verwenden Sie benutzerdefinierte Felder für Nicht-Passwort-Secrets (API-Schlüssel, Client-IDs), anstatt alles in das Passwortfeld zu packen

Die letzte Entscheidung ist, wer den Tresor überhaupt sehen kann. Unternehmenstresore sind der Ort, an den Team-SaaS-Zugangsdaten gehören. Private Tresore sind für persönliche Arbeits-Logins, die den Mitarbeiter nicht überdauern sollten.

Schritt 3: Einmal migrieren, dann die parallelen Speicherorte löschen

Die Migration von SaaS-Zugangsdaten reduziert das Cloud-Management-Risiko nur dann, wenn der alte Speicherort zu einem festen Datum abgeschaltet wird. Einen Chat-Kanal, eine Tabelle und einen Passwort-Manager parallel als konkurrierende Wahrheitsquellen zu betreiben, reproduziert nur das Chaos, das die Migration eigentlich beheben sollte.

Import schlägt Neueintippen. Passwork akzeptiert strukturierte Importe (JSON, CSV und gängige Passwort-Manager-Exportformate). Migrieren Sie zuerst eine Pilotabteilung — genug Datensätze, damit die Leute den Schmerz der alten Methode spüren, aber nicht so viele, dass ein schlechtes Ordnerdesign permanent wird.

Beispiel des Importprozesses in Passwork

Regeln für eine ehrliche Migration:

Eine Wahrheitsquelle nach der Umstellung. Der Slack-Kanal und das gemeinsam genutzte Google Sheet werden zu schreibgeschützten Archiven und werden dann an einem veröffentlichten Datum gelöscht.
Rotieren Sie SaaS-Zugangsdaten nach dem Import, wenn der alte Kanal geteilt wurde. Alles, was im Chat existierte, ist per Definition kompromittiert. Das Passwort in der SaaS-Anwendung zu ändern und dann den Tresor zu aktualisieren, ist besser, als zuerst den Tresor zu aktualisieren und zu hoffen, dass die Anwendung den alten Wert noch akzeptiert.
Shortcuts statt Kopien. Wenn zwei Teams dieselben SaaS-Zugangsdaten benötigen, teilen Sie den Zugriff oder verwenden Sie einen Shortcut, anstatt das Secret zu duplizieren. Duplikate driften auseinander.

Rechnen Sie mit zwei chaotischen Wochen. Das ist normal. Der Fehlermodus ist, Notion und den Passwort-Tresor sechs Monate lang beide als „offiziell" zu belassen.

Schritt 4: Zugriff mit Rollen, Gruppen und Tresor-Berechtigungen steuern

Zentrale SaaS-Zugangsdatenspeicherung ohne Least-Privilege-Prinzip macht aus einem Passwort-Tresor eine sehr große, durchsuchbare Ablage. Effektive SaaS-Zugangsdatenverwaltung trennt, was eine Person mit der Plattform selbst tun kann, von dem, was sie mit einem bestimmten Satz gemeinsam genutzter Secrets tun kann.

Passwork trennt zwei Ebenen:

Systemrollen — was jemand mit der Instanz tun kann (Benutzer einladen, SSO ändern, das Aktivitätsprotokoll lesen). Integrierte Rollen umfassen Besitzer, Admin und Benutzer. Unbegrenzte benutzerdefinierte Rollen ermöglichen es, Support- oder Auditor-Rollen zu erstellen, ohne vollständige Admin-Rechte zu vergeben.
Benutzergruppen — was sie mit gemeinsam genutzten SaaS-Zugangsdaten tun können. Die Stufen reichen von Verboten über Lesen, Bearbeiten und Vollständiger Zugang bis hin zu Admin für diese Ressource.

Erteilen Sie Zugriff an Gruppen und ordnen Sie dann Personen den Gruppen zu. Wenn jemand dem Support beitritt, erbt er den Tresor-Zugriff mit der Gruppe. Wenn er geht, entfernen Sie ihn einmal. LDAP/AD kann die Gruppenmitgliedschaft synchronisieren, sodass Verzeichnisänderungen in den Passwort-Tresor fließen, anstatt auf ein Ticket zu warten.

Beispiel von Benutzergruppen in Passwork

Seien Sie streng mit Admin-Rechten für Tresore. Die meisten Personen benötigen Lese-Zugriff auf die Anwendungen, die sie nutzen. Admin ist für Teamleiter, die Ordner organisieren und überprüfen, wer Zugriff hat.

Schritt 5: Identität, Automatisierung und Offboarding verbinden

Ein Passwort-Tresor, der nur für interaktive Logins verwendet wird, deckt die Hälfte der SaaS-Zugangsdatenverwaltung ab. Die andere Hälfte sind die Machine-to-Machine-Secrets, die Pipelines zur Build- oder Deploy-Zeit abrufen. Die Anbindung des Tresors an SSO, LDAP/AD und eine CI-kompatible API macht ihn zum einzigen Kontrollpunkt für sowohl menschliche Logins als auch automatisierte Cloud-Management-Workflows.

SAML SSO damit Personen den Passwort-Tresor mit demselben IdP betreten, den sie für den Rest des SaaS-Stacks verwenden (Azure AD, Okta, ADFS, Google Workspace und ähnliche).
LDAP/AD wenn das Verzeichnis die Wahrheitsquelle für Konten und gruppenbasierten Tresor-Zugriff ist.
Browser-Erweiterung und Desktop-/Mobile-Clients damit der tägliche Weg Autofill ist, nicht Kopieren-Einfügen aus einem Web-Tab.

Für die maschinelle Seite des Stacks halten Sie Menschen aus CI heraus:

Verwenden Sie ein Service-Konto mit einem API-Schlüssel (oder Sitzungs-Tokens, die von passwork-cli verwendet werden), das auf die Tresore und Ordner beschränkt ist, die die Pipeline für den SaaS-Zugangsdatenzugriff benötigt.
Rufen Sie Secrets zur Job-Zeit ab. Baken Sie sie nicht in Images ein.
Rotieren: Aktualisieren Sie das Secret zuerst im Zielsystem, dann speichern Sie den neuen Wert im Passwort-Tresor — die umgekehrte Reihenfolge verursacht stille Ausfälle.
Überprüfen Sie das Aktivitätsprotokoll (und Syslog/CEF-Export an SIEM, falls vorhanden) auf Kopien, Exporte und Zugriffsänderungen.

Offboarding ist der Punkt, an dem sich dieses Setup auszahlt. Deaktivieren Sie das Konto des ausscheidenden Benutzers, widerrufen Sie seine API-Sitzungen und bestätigen Sie, dass er aus jeder Gruppe entfernt wurde. Wenn ein gemeinsam genutztes SaaS-Admin-Passwort nur im Tresor lag, ist das Rotieren eine Aktion, keine Suche durch fünf Postfächer, um zu sehen, wer sonst noch eine Kopie hatte.

Wie richtige SaaS-Zugangsdatenverwaltung aussieht

SaaS-Zugangsdatenverwaltung ist zentralisiert, wenn der Zugriff über Gruppen statt über Direktnachrichten läuft, das Offboarding den Passwort-Tresor-Zugriff mit einer Aktion entzieht und jede Zugangsdatenabfrage in einem Aktivitätsprotokoll nachverfolgt werden kann. Nichts davon erfordert ein langes Programm — Inventur, Struktur und Migration laufen parallel über einige Wochen.

Sie sind zentralisiert, wenn:

Ein neuer Mitarbeiter Tresor-Zugriff über eine Gruppe erhält, nicht über eine Direktnachricht mit fünf Passwörtern
Ein ausscheidender Mitarbeiter den SaaS-Zugriff verliert, ohne eine Schnitzeljagd
Entwickler eine Pipeline auf eine Ordner-ID richten können und aufhören, .env-Dateien zu committen
Die Sicherheitsabteilung die Frage „Wer konnte den Stripe-Login letzten Monat sehen?" aus dem Aktivitätsprotokoll beantworten kann

Nichts davon erfordert ein Zwölf-Monats-Programm. Inventur in einer Woche. Struktur und Pilot in einer weiteren. Migration in Wellen. Berechtigungen und SSO parallel zu den Wellen. Automatisierung zuletzt — nachdem die Ordnerstruktur steht.

Fazit

Die Zentralisierung von SaaS-Zugangsdaten funktioniert nur, wenn das Tool, das sie verwaltet, durchsetzt, wer für jeden Tresor verantwortlich ist, menschliche Logins und Service-Konten auf getrennten Pfaden hält und einen Nachweis produziert, den Sie der Sicherheitsabteilung übergeben können, ohne ihn aus dem Gedächtnis zu rekonstruieren.

Passwork bindet diese Verantwortlichkeit an eine Rolle, die Sie im Voraus definieren, nicht an denjenigen, der zufällig zuerst auf „Tresor erstellen" geklickt hat. Wenn also die Person, die den Marketing-Tresor eingerichtet hat, das Unternehmen verlässt, verschwindet die Aufsicht nicht mit ihr — sie bleibt bei der Rolle. Service-Konten handhaben die maschinelle Seite auf dieselbe Weise: Eine CI-Pipeline erhält ihre eigene begrenzte Identität, anstatt still auf dem persönlichen Login von jemandem zu laufen, lange nachdem diese Person das Team gewechselt hat.

Menschliche Passwörter und maschinelle Secrets landen auf derselben Plattform, zu einem Preis. Das ist ein Anbieter statt zwei und ein Aktivitätsprotokoll statt zusammengestückter Exporte aus einem Passwort-Manager und einem separaten Secrets-Tool.

💡

Bereit, Ihre Zugangsdaten unter einem Dach zu vereinen? Testen Sie Passwork und führen Sie Ihre eigene Tresor-Struktur durch das System.

Häufig gestellte Fragen

Was ist SaaS-Zugangsdatenverwaltung?

SaaS-Zugangsdatenverwaltung bezeichnet die Praxis, zu verfolgen, wer jedes Passwort und jeden Login besitzt, verwendet und darauf zugreifen kann, der mit den Cloud-Anwendungen eines Unternehmens verbunden ist. Sie umfasst Konten, die nicht über Single Sign-On laufen, einschließlich gemeinsam genutzter Logins und Software-Zugangsdaten wie API-Schlüssel.

Sollten persönliche SaaS-Logins im selben Tresor wie Team-Zugangsdaten liegen?

Nein. Persönliche Arbeits-Logins gehören in private Tresore, die an die Einzelperson gebunden sind, während gemeinsam genutzte SaaS-Zugangsdaten in Unternehmenstresore gehören, die an ein Team oder eine Abteilung gebunden sind. Die Vermischung beider bedeutet, dass der persönliche Zugriff den Mitarbeiter überdauert und Team-Zugangsdaten während eines Audits schwerer zu finden sind.

Was ist der Unterschied zwischen einem Passwort und einer Zugangsdaten?

Ein Passwort ist etwas, das eine Person eingibt, um sich bei einem Konto anzumelden. Zugangsdaten sind weiter gefasst: Sie umfassen API-Schlüssel, Sicherheitszertifikate und Tokens, die Software anstelle von Menschen verwendet. Jedes Passwort ist eine Zugangsdaten, aber nicht jede Zugangsdaten ist ein Passwort.

Brauchen wir noch einen Passwort-Tresor, wenn wir bereits SSO nutzen?

Ja. SSO deckt nur die Anwendungen ab, die es unterstützen, und viele SaaS-Tools tun das immer noch nicht. Ein Passwort-Tresor übernimmt alles, was SSO nicht erreichen kann: gemeinsam genutzte Logins, Legacy-Systeme, Lieferantenportale und die API-Schlüssel, die einen Identity Provider überhaupt nie berühren.

Wie unterscheidet sich ein Secrets Manager von einem Passwort-Tresor?

Ein Secrets Manager speichert maschinelle Zugangsdaten wie API-Schlüssel, Tokens und Zertifikate, oft mit integrierter automatischer Rotation. Ein Passwort-Tresor speichert Zugangsdaten, die Menschen manuell eingeben. Vollständige SaaS-Zugangsdatenverwaltung benötigt beides, erfasst in einem Inventar statt zwei getrennter Systeme.

Wie vereinfacht SaaS-Zugangsdatenverwaltung das Offboarding?

Wenn Zugangsdaten in einem gemeinsamen Tresor gespeichert werden, anstatt über Chat und Tabellen verstreut zu sein, wird das Offboarding zu einer einzigen Aktion: Konto deaktivieren, API-Sitzungen widerrufen und die Person aus jeder Gruppe entfernen. Niemand muss fünf Postfächer durchsuchen, um herauszufinden, wer sonst noch eine Kopie eines gemeinsam genutzten Passworts hatte.

Wie verfolgt man SaaS-Zugangsdaten, die von CI/CD-Pipelines verwendet werden?

Pipelines verwenden ein begrenztes Service-Konto mit einem API-Schlüssel oder Sitzungs-Token, nicht einen persönlichen Login. Das Konto erhält nur Zugriff auf die Tresore und Ordner, die ein bestimmter Job benötigt, und Secrets werden zur Build- oder Deploy-Zeit abgerufen, anstatt in Images eingebacken oder als .env-Dateien committet zu werden.

Wie lange dauert die Migration zu einem zentralisierten Passwort-Tresor normalerweise?

Eine Pilotabteilung kann in etwa einer Woche migrieren, wobei die Inventur- und Strukturarbeiten parallel im Vorfeld laufen. Die vollständige Einführung erfolgt typischerweise in Wellen statt auf einmal, wobei Berechtigungen und SSO parallel zu jeder Welle konfiguriert werden und die Automatisierung zuletzt hinzugefügt wird, nachdem die Ordnerstruktur stabil ist.

SaaS-Zugangsdaten verwalten: 5 Schritte zur Zentralisierung Ihres App-Stacks