In kleinen Betrieben entstehen Zugangsdaten häufig über Jahre hinweg: Ein Konto wird angelegt, mehrere Personen benötigen Zugriff, ein Passwort wird per E-Mail weitergegeben und bei einem Personalwechsel bleibt die Berechtigung bestehen. Dieses Vorgehen wirkt im Alltag zeitsparend, erschwert aber die Kontrolle über Zugriffe. Zudem steigt das Risiko, dass ein Passwort mehrfach verwendet, unverschlüsselt gespeichert oder nicht rechtzeitig geändert wird.
Ein Passwortmanager für Teams soll diese Probleme nicht nur technisch, sondern auch organisatorisch lösen. Er verwaltet Zugangsdaten in verschlüsselten Tresoren, ermöglicht die gezielte Freigabe einzelner Einträge und unterstützt bei der Nutzung starker, unterschiedlicher Passwörter. Je nach Produkt kommen Funktionen für Mehrfaktor-Authentisierung, Rollen, Protokollierung, Notfallzugriff und die Anbindung an Verzeichnisdienste hinzu.
Entscheidend ist die Abgrenzung zwischen persönlichen Zugangsdaten und gemeinsam verwalteten Konten. Ein privates Konto einer Mitarbeiterin oder eines Mitarbeiters gehört nicht in einen gemeinsamen Tresor. Ein Zugang zu einer gemeinsamen Verwaltungsoberfläche, einem Hosting-Konto oder einem Social-Media-Arbeitskonto kann dagegen einen begrenzten Teamzugriff benötigen. Diese Unterscheidung verhindert, dass persönliche Informationen bei der Umstellung versehentlich offengelegt werden.
Die Auswahl sollte mit einer Bestandsaufnahme beginnen, nicht mit einer Funktionsliste aus Werbematerial. Zunächst wird dokumentiert, welche Konten, Identitäten und Arbeitsabläufe tatsächlich vorhanden sind. Dabei gehören auch Zugangsdaten dazu, die nicht als klassisches Passwort erscheinen, etwa Wiederherstellungscodes, API-Schlüssel, Zertifikate oder PINs für Geräte.
Aus dieser Bestandsaufnahme entsteht eine Anforderungsliste. Dazu können verschlüsselte Synchronisation, getrennte Tresore, granular vergebene Rechte, Mehrfaktor-Authentisierung, sichere Freigabeprozesse und Exportmöglichkeiten gehören. Auch die Frage nach der Datenhaltung ist relevant: Zu prüfen sind unter anderem der Sitz des Anbieters, die Vertragsbedingungen, die Verarbeitung personenbezogener Daten und die Möglichkeiten für Auftragsverarbeitung, sofern personenbezogene Daten betroffen sind.
Ein Anbieter sollte nachvollziehbar erklären, welche Verschlüsselung eingesetzt wird, wo die Verschlüsselung stattfindet und welche Informationen der Dienst selbst einsehen kann. Aussagen wie „militärische Verschlüsselung“ ersetzen keine technische Dokumentation. Aussagekräftiger sind Angaben zu Ende-zu-Ende-Verschlüsselung, Schlüsselableitung, Mehrfaktorverfahren, unabhängigen Sicherheitsprüfungen und zum Umgang mit Sicherheitsvorfällen.
Nicht jede verfügbare Funktion ist für jedes Team erforderlich. Die folgenden Kriterien helfen, den praktischen Nutzen von Marketingbegriffen zu trennen:
| Kriterium | Worauf bei der Prüfung zu achten ist | Nutzen im Alltag |
|---|---|---|
| Verschlüsselung | Dokumentierte Verschlüsselung während der Übertragung und Speicherung, möglichst mit clientseitiger Verarbeitung | Begrenzt das Risiko bei abgefangenen oder unberechtigt ausgelesenen Daten |
| Rechteverwaltung | Rollen, Gruppen und getrennte Tresore mit differenzierten Lese- und Änderungsrechten | Verhindert unnötig weitreichende Zugriffe |
| Mehrfaktor-Authentisierung | Unterstützung von Sicherheitsschlüsseln oder anerkannten Authentisierungs-Apps | Schützt Konten auch bei bekannt gewordenem Masterpasswort |
| Wiederherstellung | Definierter Prozess für verlorene Geräte, ausgeschiedene Administratoren und Notfälle | Reduziert das Risiko eines dauerhaften Datenverlusts |
| Protokollierung | Nachvollziehbarkeit von Einladungen, Freigaben, Änderungen und Entzügen | Unterstützt Kontrolle und Aufklärung von Unregelmäßigkeiten |
| Import und Export | Kontrollierter Import aus bisherigen Tresoren und ein dokumentierter Export | Erleichtert die Migration und verringert die Abhängigkeit von einem Dienst |
Ein Auditprotokoll ist kein Ersatz für eine Sicherheitsorganisation. Es muss geklärt werden, wer die Einträge regelmäßig prüft und wie lange Protokolle aufbewahrt werden. Ebenso sollte ein Export nicht ungeprüft als Sicherung betrachtet werden. Exportdateien liegen je nach Format möglicherweise unverschlüsselt vor und müssen während Erstellung, Transport und Löschung besonders geschützt werden.
Vor dem ersten Import sollte eine Zielstruktur feststehen. Bewährt hat sich eine Aufteilung nach Aufgaben oder Schutzbedarf, etwa „Administration“, „Finanzen“, „Kundenportale“, „Marketing“ und „Notfall“. Die Namen sollten verständlich sein und keine geheimen Informationen enthalten. Ein Tresor mit der Bezeichnung „Kritische Produktionszugänge“ ist organisatorisch hilfreicher als eine lange Liste einzelner Freigaben ohne Kontext.
Das Prinzip der geringsten Rechte bildet die Grundlage. Jede Person erhält nur den Zugriff, den sie für ihre aktuelle Aufgabe benötigt. Leserechte und Änderungsrechte sollten getrennt werden, wenn das Produkt diese Unterscheidung erlaubt. Für technische Konten ist festzulegen, wer verantwortlich ist, wo die Verwendung dokumentiert wird und unter welchen Bedingungen ein Schlüssel ersetzt wird.
Mindestens zwei Personen sollten für zentrale Verwaltungsaufgaben vorgesehen werden, damit ein Ausfall nicht zu einer Zugriffssperre führt. Das bedeutet nicht, dass alle Administratoren uneingeschränkten Zugriff erhalten. Administrationskonten sollten persönliche Identitäten verwenden, durch Mehrfaktor-Authentisierung geschützt und nur für administrative Tätigkeiten eingesetzt werden.
Für das Masterpasswort gelten besondere Regeln. Es sollte lang, einzigartig und nicht aus Informationen des Betriebs, der Domain oder der betreffenden Person ableitbar sein. Die Wiederverwendung für andere Dienste ist auszuschließen. Ein Verfahren für die sichere Hinterlegung eines Notfallzugangs muss schriftlich festgelegt werden. Dabei sollte der Notfallzugriff nur unter definierten Bedingungen und nach dem Vier-Augen-Prinzip genutzt werden, wenn das eingesetzte System diese Möglichkeit unterstützt.
Die Umstellung aller Konten an einem Tag erhöht den Druck und erschwert die Fehlersuche. Eine Pilotphase mit wenigen Personen aus unterschiedlichen Arbeitsbereichen liefert aussagekräftigere Erkenntnisse. Die Auswahl sollte nicht nur technisch versierte Nutzerinnen und Nutzer umfassen, sondern auch Personen mit typischen Alltagsanforderungen.
Der Pilot sollte auch die unangenehmen Fälle abdecken. Dazu gehören ein verlorenes Smartphone, ein gesperrtes Konto, eine fehlerhafte Einladung, ein versehentlich gelöschter Eintrag und der Ausfall einer verantwortlichen Administrationsperson. Erst wenn diese Szenarien verstanden sind, kann eine belastbare Betriebsanweisung entstehen.
Die Migration beginnt mit einer Bereinigung. Doppelte Einträge, veraltete Konten und unbekannte Zugangsdaten sollten gekennzeichnet werden. Bei jedem Eintrag sind mindestens Besitzer oder Verantwortliche, Zweck, Zielsystem, betroffene Personen und erforderliche Freigaben zu dokumentieren. Unklare Datensätze gehören in eine separate Prüfliste, nicht ungeprüft in den neuen Tresor.
Ein möglicher Ablauf sieht so aus:
Ein Passwortmanager beseitigt keine bereits kompromittierten Zugangsdaten. Wenn ein Passwort in der Vergangenheit per E-Mail, Chat oder unverschlüsselter Datei geteilt wurde, sollte das betreffende Konto im Zuge der Migration ein neues Passwort erhalten. Bei besonders schützenswerten Konten ist zusätzlich zu prüfen, ob aktive Sitzungen, App-Passwörter, API-Schlüssel oder Wiederherstellungscodes widerrufen und neu erstellt werden müssen.
Technische Vorgaben werden nicht dauerhaft eingehalten, wenn der praktische Zweck unklar bleibt. Eine kurze Einführung sollte zeigen, wie ein persönlicher Tresor funktioniert, wie ein gemeinsamer Eintrag gefunden wird und wann ein neues Passwort erzeugt werden muss. Ebenso wichtig ist die Erklärung, welche Daten nicht in gemeinsame Tresore gehören.
Eine interne Arbeitsanweisung sollte mindestens folgende Punkte beantworten:
Automatisches Ausfüllen sollte nur auf vertrauenswürdigen Websites und in erwarteten Anmeldefeldern eingesetzt werden. Bei unbekannten Domains kann das Ausbleiben eines passenden Eintrags ein nützliches Warnsignal sein. Zugangsdaten sollten nicht in Tickets, Tabellen oder Chatnachrichten kopiert werden, auch wenn dies kurzfristig schneller erscheint.
Die Einweisung sollte keine Masterpasswörter oder Wiederherstellungscodes im Schulungsraum sammeln. Jede Person richtet persönliche Authentisierung selbst ein. Für Nachfragen eignet sich eine anonymisierte Testumgebung besser als ein produktiver Zugang.
Die Einführung endet nicht mit dem Import. Ein Passwortmanager benötigt einen geregelten Lebenszyklus. Bei neuen Mitarbeitenden werden nur die für die Rolle erforderlichen Gruppen freigegeben. Bei einer internen Versetzung werden alte Berechtigungen entfernt, bevor neue Rechte hinzukommen. Beim Ausscheiden werden Sitzungen widerrufen, persönliche Geräte abgemeldet, gemeinsam genutzte Passwörter bewertet und bei Bedarf geändert.
Ein regelmäßiger Berechtigungsreview kann in einem festen Turnus stattfinden. Entscheidend ist weniger ein pauschaler Zeitraum als die nachvollziehbare Zuständigkeit: Eine verantwortliche Person prüft, ob jeder Zugriff noch erforderlich ist, dokumentiert Abweichungen und lässt unnötige Freigaben entfernen. Besonders kritische Konten sollten zusätzlich nach Änderungen an der Teamstruktur oder nach Sicherheitsvorfällen geprüft werden.
Für Notfälle braucht es einen schriftlichen Ablauf. Er sollte festlegen, wie ein gesperrtes Administrationskonto wiederhergestellt wird, wer eine Notfallfreigabe genehmigt, wie der Zugriff protokolliert wird und wann danach Passwörter oder Schlüssel ersetzt werden. Ein Notfallplan, der nur im Passwortmanager selbst liegt, ist unvollständig. Die Kontaktdaten und die grundlegenden Entscheidungsschritte müssen auch außerhalb des Systems erreichbar sein, ohne dabei geheime Zugangsdaten offenzulegen.
Ein häufiger Fehler besteht darin, alle Konten in einen einzigen gemeinsamen Tresor zu legen. Das vermindert zwar zunächst den Verwaltungsaufwand, verletzt aber die Trennung von Aufgaben und macht Entzüge unpräzise. Besser sind klar benannte Bereiche und Gruppen mit möglichst kleinen Berechtigungsumfängen.
Problematisch ist auch die Nutzung eines gemeinsamen Masterkontos für mehrere Personen. Dadurch gehen Verantwortlichkeit und Nachvollziehbarkeit verloren. Persönliche Konten mit individuellen Mehrfaktorverfahren sind vorzuziehen. Gemeinsame Konten des Zielsystems sollten nur dort verwendet werden, wo das Zielsystem keine persönliche Anmeldung ermöglicht oder der Arbeitsablauf sie ausdrücklich erfordert.
Weitere Risiken entstehen durch:
Ein Passwortmanager schützt außerdem nicht vor einer manipulierten Website, einem kompromittierten Endgerät oder einem bereits angemeldeten Browserprofil. Deshalb bleiben Betriebssystem-Updates, Geräteschutz, sichere Wiederherstellungsverfahren und Sensibilisierung gegen Phishing notwendige Bestandteile des Sicherheitskonzepts. Die Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik und die Leitlinien des National Institute of Standards and Technology können bei der Ausgestaltung von Authentisierung und Zugangsschutz als Orientierung dienen.
Für einen kleinen Betrieb lässt sich die Umstellung in klar getrennte Arbeitspakete gliedern:
Die Reihenfolge kann je nach Teamgröße und Systemlandschaft angepasst werden. Eine schriftliche Abnahme sollte festhalten, welche Konten migriert wurden, welche Altbestände gelöscht werden dürfen, wer für die Verwaltung zuständig ist und wann die nächste Berechtigungsprüfung stattfindet. So wird die Einführung von einem einmaligen IT-Projekt zu einem kontrollierten Sicherheitsprozess.
Nein. Persönliche Tresore und gemeinsame Bereiche sollten getrennt werden. Zugriff auf gemeinsame Bereiche erhalten nur Personen, die ihn für ihre Aufgabe benötigen. Die genaue Aufteilung richtet sich nach Rollen, Schutzbedarf und Arbeitsabläufen.
Das hängt vom Verschlüsselungs- und Wiederherstellungsmodell des jeweiligen Produkts ab. Vor der Einführung muss geklärt werden, ob eine Wiederherstellung durch einen Notfallkontakt, einen Administrationsprozess oder gar nicht möglich ist. Die Option sollte mit Testkonten geprüft werden.
Viele Systeme bieten Felder für sichere Notizen oder andere Geheimnisse. Solche Daten sollten nach demselben Prinzip klassifiziert werden wie Passwörter: klarer Verantwortlicher, begrenzte Freigabe, dokumentierter Zweck und geregelte Erneuerung. Ob ein bestimmtes Format geeignet ist, muss die technische Dokumentation des eingesetzten Systems beantworten.
Eine pauschale Frequenz ist weniger aussagekräftig als ein anlassbezogener Prozess. Eine Änderung ist unter anderem nach vermutetem Abfluss, nach einem unklaren Personalwechsel, bei Änderungen am Schutzbedarf oder wenn das Zielsystem dies verlangt sinnvoll. Entscheidend ist, dass Verantwortlichkeit und Auslöser dokumentiert sind.
Nein. Er kann durch einzigartige Passwörter, Mehrfaktor-Authentisierung und die Erkennung passender Domains unterstützen. Gegen täuschend echte Anmeldeseiten, kompromittierte Geräte oder die Freigabe eines zweiten Faktors durch eine getäuschte Person sind zusätzliche Schutzmaßnahmen und Aufmerksamkeit erforderlich.
