Passwortmanager · Teamzugänge · Notfallvorsorge
Ein betrieblicher Passwortmanager ist mehr als ein verschlüsseltes Adressbuch. Er muss persönliche und gemeinsam benötigte Zugangsdaten sauber trennen, Rechte nachvollziehbar vergeben, Gerätewechsel und Austritte beherrschen und den Zugriff auch dann ermöglichen, wenn eine verantwortliche Person ausfällt.
Zielzustand: Jedes Konto erhält ein langes, zufälliges und ausschließlich dort verwendetes Kennwort. Beschäftigte greifen über persönliche Tresore und freigegebene Team-Sammlungen zu. Master-Zugang, MFA, Wiederherstellung, Export und Notfallzugang sind getestet und dokumentiert.
Die Kurzantwort: Erst das Betriebsmodell festlegen, dann ein Produkt auswählen
Für kleine Teams ist meist eine zentral verwaltete Geschäftslösung sinnvoll: persönliche Konten, rollenbasierte Freigaben, nachvollziehbarer Entzug, starke MFA und ein geprüfter Wiederherstellungsweg. Eine gemeinsam genutzte private Tresordatei oder das Browserkonto einer Führungskraft erfüllt diese Anforderungen nicht.
| Frage | Tragfähige Antwort | Warnsignal |
|---|---|---|
| Wem gehört der Tresor? | Der Organisation; Personen erhalten eigene Konten und definierte Rollen. | Alles liegt im privaten Konto einer einzelnen Person. |
| Wie werden Zugänge geteilt? | Über Team-Sammlungen oder Gruppen mit minimalen Rechten. | Kennwörter werden per E-Mail, Chat oder Tabellenblatt verteilt. |
| Wie wird der Tresor geschützt? | Lange persönliche Master-Passphrase, starke MFA, Geräteschutz und kurze Sperrfrist. | Master-Zugang wird im selben Tresor oder Browser gespeichert. |
| Wie erfolgt Wiederherstellung? | Identitätsprüfung, freigegebener Recovery-Prozess und unabhängige Ersatzmethode sind getestet. | Der Support könne das Master-Kennwort „irgendwie zurücksetzen“. |
| Was geschieht beim Austritt? | Zugriff wird entzogen, persönliche Methoden entfernt und besonders exponierte Geheimnisse rotiert. | Niemand weiß, welche Kennwörter die Person sehen oder exportieren konnte. |
| Wie bleibt das Unternehmen handlungsfähig? | Notfallrollen, geschützter Ersatzzugang und verschlüsselter, getesteter Export sind geregelt. | Nur eine Person besitzt alle Administrations- und Recovery-Möglichkeiten. |
Der Passwortmanager ersetzt weder MFA noch Identitätsmanagement
Er erzeugt und schützt Kennwörter, kann Freigaben organisieren und die Nutzung vereinfachen. Kritische Dienste erhalten dennoch eigene Mehrfaktorauthentifizierung, persönliche Konten und angemessene Rollen. Wo Passkeys verfügbar und betrieblich beherrschbar sind, können sie Kennwörter schrittweise ersetzen; der Tresor bleibt für zahlreiche Alt- und Fachanwendungen erforderlich.
1. Die Auswahl folgt einem prüfbaren Anforderungskatalog
Eine Funktionsliste des Herstellers reicht nicht. Das Unternehmen bewertet, ob die konkrete Tarifstufe die benötigten Rollen, Protokolle, Wiederherstellungswege und Plattformen enthält und wie diese Funktionen technisch umgesetzt werden.
| Prüffeld | Musskriterium | Praktischer Nachweis |
|---|---|---|
| Verschlüsselung | Tresorinhalte werden mit anerkannten Verfahren geschützt; Schlüsselableitung und Schlüsselmodell sind nachvollziehbar dokumentiert. | Technische Dokumentation, unabhängige Prüfung und Test der Client-Sperre |
| Mandant und Eigentum | Organisation kann Administratoren, Abrechnung, Richtlinien und Mitgliedschaft unabhängig von einer Einzelperson verwalten. | Testmandant mit zwei Organisationsverantwortlichen |
| Rollen | Administration, Recovery, Gruppenpflege und Nutzung lassen sich sinnvoll trennen. | Rollenmatrix und Test mit eingeschränktem Benutzer |
| Freigaben | Geheimnisse werden Sammlungen oder Gruppen zugeordnet; Änderungen und Entzug wirken nachvollziehbar. | Testfreigabe ohne Übermittlung des Kennworts |
| MFA und Passkeys | Starke zweite Faktoren für den Tresorzugang; idealerweise phishing-resistente Optionen für Administratoren. | Registrierung, Ersatzmethode und Richtlinienprüfung |
| Clients | Unterstützte Apps und Browser-Erweiterungen für alle tatsächlich verwendeten Plattformen. | Pilot auf Windows, macOS, iOS, Android und relevanten Browsern |
| Autofill | Domainbezogenes Ausfüllen, klare Anzeige des Ziels und kontrollierbare Zwischenablage. | Test mit ähnlicher, aber falscher Domain und Subdomain |
| Protokollierung | Administrative Änderungen, Mitgliedschaften und relevante Freigabeereignisse sind nachvollziehbar. | Exportierbares Ereignisprotokoll der gebuchten Tarifstufe |
| Import und Export | Unterstützte Quellformate, vollständiger Export und dokumentierte Wiederherstellung ohne Herstellerbindung. | Testmigration mit Anhängen, benutzerdefinierten Feldern und TOTP |
| Herstellerbetrieb | Sicherheitsprozess, Schwachstellenkommunikation, Updatepflege, Statusseite und Supportwege sind belastbar. | Veröffentlichte Sicherheitsdokumentation und Reaktionstest |
| Datenschutz | Auftragsverarbeitung, Unterauftragnehmer, Speicherorte, Löschkonzept und Vertragsbedingungen sind prüfbar. | Aktuelle Vertragsunterlagen der konkreten Leistung |
| Notfall | Recovery und Emergency Access passen zum eigenen Rollenmodell und können kontrolliert getestet werden. | Protokollierter Test ohne Kenntnis des Master-Kennworts |
Ein veröffentlichtes Sicherheitsaudit ist ein wichtiges Indiz, aber keine automatische Freigabe. Geprüft werden Umfang, Datum, untersuchte Komponenten, festgestellte Grenzen und der Umgang mit Schwachstellen. Ebenso wenig beweist der Begriff „Zero Knowledge“ allein, dass Recovery, Freigaben, Metadaten, Clients und Browser-Erweiterungen den eigenen Anforderungen entsprechen.
Ein Musterbestand deckt Auswahlfehler vor dem Vertragsabschluss auf
- Eine Webanmeldung mit Hauptdomain und abweichender Login-URL
- Ein Microsoft-365-Administratorkonto mit separater MFA
- Eine Fachanwendung mit mehreren Feldern oder Mandanten
- Ein Serverzugang mit SSH-Schlüssel oder zusätzlicher Notiz
- Ein WLAN- oder Gerätekennwort, das nur die IT sehen darf
- Ein geteilter Lieferantenzugang mit genau zwei berechtigten Rollen
- Ein Eintrag mit Dateianhang, Versionshistorie und benutzerdefiniertem Feld
- Ein Testbenutzer, dessen Zugriff vollständig entzogen und anschließend geprüft wird
2. Cloud-Dienst, selbst betriebener Server und lokale Datei verteilen Verantwortung unterschiedlich
Die Frage „Cloud oder lokal?“ beantwortet nicht allein, welche Lösung sicherer ist. Entscheidend ist, wer Updates, Verfügbarkeit, Backups, Gerätesynchronisierung, Zugriffsprotokolle und Wiederherstellung zuverlässig betreibt.
| Modell | Vorteile | Verantwortung und Grenzen |
|---|---|---|
| Verwalteter Cloud-Dienst | Einfache Synchronisierung, zentrale Teams, Herstellerbetrieb und meist gute Geräteunterstützung | Anbieter, Vertrag, Client-Sicherheit und Recovery prüfen; Internet- und Herstellerabhängigkeit beherrschen. |
| Selbst betriebener Team-Server | Mehr Kontrolle über Betrieb und Datenpfad; eigene Integrationen möglich | Organisation verantwortet Härtung, Updates, TLS, Monitoring, Backups, Hochverfügbarkeit und Notfallzugriff. |
| Lokale Tresordatei | Einfaches Datenmodell und kein laufender Serverdienst | Mehrbenutzerbetrieb, Konflikte, sichere Synchronisierung, Rechteentzug, Protokolle und mobile Nutzung sind schwieriger. |
| Private Einzelkonten | Schneller persönlicher Einstieg | Kein belastbares Unternehmenseigentum, unklare Freigaben, Abrechnung und Offboarding; für den Teamkern ungeeignet. |
Ein kleiner Betrieb ohne eigene Serverpflege erreicht mit einem sorgfältig ausgewählten, zentral verwalteten Cloud-Dienst oft das bessere Gesamtergebnis. Selbstbetrieb ist nur dann ein Sicherheitsvorteil, wenn Aktualisierung, Überwachung, verschlüsselte Sicherung und Wiederherstellung tatsächlich dauerhaft geleistet werden. Eine ungepatchte Installation ohne getestetes Backup verlagert das Risiko lediglich in den eigenen Verantwortungsbereich.
3. Die Tresorstruktur folgt Verantwortlichkeiten und nicht dem Organigramm allein
Zu grobe Freigaben machen jedes Teammitglied zum Mitwisser sämtlicher Zugangsdaten. Zu feine Einzelrechte werden unübersichtlich und bleiben beim Rollenwechsel liegen. Sinnvoll sind wenige stabile Sammlungen nach Schutzbedarf und Aufgabe.
| Sammlung | Typische Inhalte | Berechtigung |
|---|---|---|
| Persönlicher Tresor | Individuelle dienstliche Zugänge und noch nicht freigegebene Entwürfe | Nur jeweilige Person; Unternehmensrichtlinie bleibt wirksam. |
| Allgemeine Dienste | Versandportal, Raumtechnik oder gemeinsame Lieferantenplattform | Benannte Nutzergruppe mit Leserecht; Änderung nur Verantwortliche |
| Finanzen | Buchhaltung, Zahlungsdienstleister und Steuerportal | Kleiner geprüfter Personenkreis; starke MFA außerhalb des Tresors |
| Personal | Personalportal und geschützte Verwaltungszugänge | Ausschließlich HR-Verantwortliche und geregelte Vertretung |
| IT-Betrieb | Router, Backup, Hosting, Domains und Geräteverwaltung | IT-Rolle; tägliche und privilegierte Konten getrennt |
| Notfall | Wiederanlaufdaten, Eigentumsnachweise und Break-Glass-Zugänge | Getrennte Notfallverantwortliche; jede Nutzung protokolliert |
Jeder Eintrag braucht genügend Kontext für eine sichere Nutzung
- Eindeutiger Dienst- und Mandantenname statt „Admin“ oder „Login“
- Vollständige, geprüfte Anmelde-URL und zulässige Domains
- Persönlicher oder funktionaler Benutzername mit zugehöriger Rolle
- Automatisch erzeugtes, nur für diesen Dienst verwendetes Kennwort
- Verantwortliche Stelle und geschäftlicher Zweck
- Verknüpfte MFA-Methode, ohne deren geheimen Faktor unnötig gemeinsam abzulegen
- Datum der letzten sachlichen Prüfung und Anlass einer Kennwortänderung
- Hinweis auf Abhängigkeiten, etwa API-Schlüssel, Wiederherstellungscodes oder hinterlegte E-Mail-Adresse
Tags können Suche und Auswertung ergänzen, ersetzen aber keine Berechtigungsgrenze. Ein Eintrag mit dem Tag „vertraulich“ bleibt für alle sichtbar, die auf seine Sammlung zugreifen dürfen. Schutz entsteht durch Gruppen, Sammlungen und Rollen; Benennung und Tags erklären den Inhalt.
4. Die Einführung beginnt mit Verantwortlichen, Pilot und verbindlichen Regeln
Der Passwortmanager wird nicht einfach installiert. Zuerst entstehen Organisationskonto, Rollen, Richtlinien und ein Pilotbestand. Erst nach einem vollständigen Export- und Recovery-Test werden produktive Zugangsdaten migriert.
Schritt für Schritt: Den Team-Passwortmanager einführen
- Projektverantwortung, technischen Administrator, Recovery-Verantwortliche und Vertretung namentlich festlegen.
- Kontenarten, Endgeräte, Browser, Standorte, vorhandene Passwortspeicher und gemeinsam verwendete Zugänge erfassen.
- Schutzbedarf und Ausschlüsse bestimmen, etwa besonders kritische Schlüssel, die getrennt verwahrt werden.
- Zwei oder drei Produkte anhand derselben Musskriterien und desselben Musterbestands testen.
- Vertrag, Auftragsverarbeitung, Tarifgrenzen, Support und Exportmöglichkeiten der favorisierten Lösung prüfen.
- Organisationsmandant auf eine betriebliche, dauerhaft kontrollierte Adresse registrieren.
- Mindestens zwei geeignete Organisationsverantwortliche einrichten; ihre Tageskonten nicht unnötig zu Superadministratoren machen.
- Persönliche lange Master-Passphrasen festlegen. Sie werden nicht zwischen Beschäftigten geteilt oder vom Administrator gesammelt.
- Starke MFA für alle aktivieren und für Administratoren eine phishing-resistente Methode einsetzen, sofern unterstützt.
- Automatische Sperre, Zwischenablage, Gerätefreigabe, Browser-Integration und Sitzungsdauer passend zum Arbeitsprofil konfigurieren.
- Gruppen, Sammlungen und Rollen zunächst mit leeren Testeinträgen aufbauen.
- Mit Pilotpersonen aus Verwaltung, Fachbereich und IT reale Anmeldungen und Freigaben testen.
- Erstausgabe, Gerätewechsel, verlorene MFA-Methode, gesperrtes Konto und Offboarding durchspielen.
- Vollständigen Export erstellen, sicher verschlüsseln, auf getrenntem Medium verwahren und probeweise wieder einlesen.
- Kurze Nutzungsregeln mit konkreten Beispielen veröffentlichen: speichern, erzeugen, ausfüllen, teilen und Verdacht melden.
- Produktive Daten in abgegrenzten Wellen migrieren; besonders kritische Zugänge zuerst oder zuletzt nach Risikoplan behandeln.
- Browserinterne Passwortspeicherung deaktivieren, nachdem Inhalte geprüft und Nutzer arbeitsfähig sind.
- Alte Dateien, Notizen und Tabellen kontrolliert entfernen, ohne den einzigen verbliebenen Nachweis voreilig zu löschen.
- Nach zwei bis vier Wochen ungenutzte Konten, doppelte Einträge, Fehlfreigaben und Supportfälle auswerten.
- Regelmäßige Prüfungen für Mitglieder, Rollen, Exporte, Schwachstellenmeldungen und Notfalltest terminieren.
| Situation | Regel | Begründung |
|---|---|---|
| Neues Konto | Zufälliges, eindeutiges Kennwort direkt im Manager erzeugen. | Keine Wiederverwendung oder vorherige Kenntnis |
| Teamzugang | In passender Sammlung freigeben; niemals per Nachricht versenden. | Rechte können geändert und entzogen werden. |
| Autofill fehlt | Domain und gespeicherte URL prüfen, bevor kopiert wird. | Fehlendes Autofill kann vor einer falschen Domain warnen. |
| Unerwartete Anmeldeseite | Nicht ausfüllen; bekannten Diensteinstieg separat öffnen. | Der Tresor verhindert kein bewusstes Einfügen auf einer Phishing-Seite. |
| Export | Nur für genehmigten Zweck, verschlüsselt und mit dokumentierter Löschung temporärer Klartextdateien. | Viele Exportformate sind unverschlüsselt. |
| Verdacht | Betroffenen Eintrag und Kontext melden; nicht eigenmächtig sämtliche Kennwörter ändern. | Abhängigkeiten und Priorität müssen koordiniert werden. |
5. Die Migration bereinigt den Bestand statt alte Fehler nur zu importieren
Browser, Tabellen, Notizen und private Tresore enthalten oft Dubletten, veraltete Konten und mehrfach verwendete Kennwörter. Der Import ist deshalb nur eine Zwischenstufe. Jeder relevante Zugang wird einem Eigentümer, Zweck und Zielort zugeordnet.
Schritt für Schritt: Vorhandene Zugangsdaten sicher migrieren
- Quellen je Person und System erfassen, ohne Kennwörter in einer neuen Sammelliste zusammenzuführen.
- Für jede Quelle Exportformat, Verschlüsselung, Speicherort und sichere Löschung klären.
- Arbeitsgerät aktualisieren, auf Schadsoftwarehinweise prüfen und temporären Migrationsordner lokal verschlüsseln.
- Nur den benötigten Bestand exportieren; private Zugangsdaten nicht in den Unternehmensmandanten übernehmen.
- Exportdatei nicht über E-Mail, allgemeinen Cloudordner oder Chat transportieren.
- Import in einen zunächst nur für die bearbeitende Person sichtbaren Bereich durchführen.
- Fehlerprotokoll, übersprungene Felder, Anhänge und Sonderzeichen prüfen.
- Dubletten anhand Dienst, Benutzername, URL und tatsächlicher Anmeldung zusammenführen.
- Veraltete Konten als zu prüfen kennzeichnen; nicht allein aufgrund des letzten Änderungsdatums löschen.
- Jeden aktiven Eintrag einer Person oder betrieblichen Rolle sowie einer Sammlung zuordnen.
- Mehrfach verwendete Kennwörter nach Schadenpotenzial priorisieren und an den jeweiligen Diensten ändern.
- Schwache Kennwörter durch zufällige, vom Zielsystem akzeptierte Werte ersetzen.
- Wiederherstellungsadressen, Sicherheitsfragen, MFA und API-Schlüssel des Dienstes mitprüfen.
- Bei gemeinsam genutzten Konten feststellen, ob persönliche Benutzer und Rollen eingerichtet werden können.
- Freigaben gruppenbasiert setzen und mit einem eingeschränkten Testkonto kontrollieren.
- Temporäre Exportdateien nach bestätigtem Import sicher entfernen; Papier- und Altkopien nach festgelegtem Verfahren behandeln.
- Originalspeicher erst deaktivieren, wenn Vollständigkeit, Anmeldung, Ersatzweg und Export des neuen Systems geprüft sind.
- Migration mit Quelle, Anzahl, Abweichungen, offenen Änderungen und verantwortlicher Person abschließen.
Ein Sicherheitsbericht mit „wiederverwendeten Kennwörtern“ ist eine Arbeitsliste, kein Beweis für eine laufende Kompromittierung. Die Änderung beginnt bei Administrator-, E-Mail-, Finanz-, Domain-, Backup- und Fernzugriffskonten. Wird ein konkreter Missbrauch vermutet, werden außerdem Sitzungen, Wiederherstellungswege und Protokolle untersucht; ein bloßer Kennwortwechsel kann einen bestehenden Zugriff unberührt lassen.
6. Im Alltag verhindert ein klarer Ablauf neue Schattenlisten
Der eingeführte Tresor bleibt nur vollständig, wenn neue Konten, Kennwortänderungen und Teamfreigaben unmittelbar dort gepflegt werden. Eine Ausnahme „für später“ erzeugt schnell wieder Browserlisten, Chatnachrichten und persönliche Notizen.
Schritt für Schritt: Einen neuen Dienstzugang anlegen und freigeben
- Vor der Registrierung klären, ob bereits ein Unternehmenskonto, Mandant oder Vertrag für den Dienst existiert.
- Persönliches Konto verwenden, wenn der Dienst Rollen und einzelne Benutzer unterstützt; ein gemeinsames Konto nur bei technischer Notwendigkeit anlegen.
- Offizielle Anmeldedomain über Vertrag, bekannte Herstellerseite oder vorhandenen Mandanten prüfen.
- Eintrag im persönlichen Arbeitsbereich anlegen und Dienst, Mandant, Zweck sowie verantwortliche Stelle eindeutig benennen.
- Mit dem Generator ein zufälliges, ausschließlich für diesen Dienst bestimmtes Kennwort erzeugen. Maximale unterstützte Länge und ausgeschlossene Zeichen des Zielsystems beachten.
- Registrierung abschließen und Wiederherstellungsadresse sowie Kontoinhaber prüfen.
- Stärkste verfügbare MFA oder einen Passkey am Zielsystem registrieren; Recovery-Codes entsprechend ihrem Schutzbedarf getrennt verwahren.
- Abmelden und den Zugang über die gespeicherte, geprüfte URL mit Autofill testen.
- Falls ein Teamzugang erforderlich ist, Eintrag in die passende Sammlung verschieben und eine bestehende Gruppe berechtigen.
- Mit einer berechtigten Person prüfen, ob Nutzung funktioniert, ohne ihr Kennwort über einen zweiten Kanal zu senden.
- Mit einem unberechtigten Testkonto kontrollieren, dass Sammlung und Eintrag nicht sichtbar sind.
- Verantwortung, Datum und besondere Abhängigkeiten im Eintrag ergänzen.
| Beobachtung | Nicht vorschnell tun | Gezielte Prüfung |
|---|---|---|
| Autofill erscheint nicht | Kennwort blind kopieren und in die offene Seite einsetzen | Vollständige Domain, gespeicherte URL, Subdomain und Browser-Erweiterung prüfen. |
| Gespeichertes Kennwort wird abgelehnt | Alten Eintrag überschreiben, bevor Ursache klar ist | Richtiges Konto, Mandant, Caps Lock, Dienststatus und letzte Änderung prüfen. |
| Änderung wird nicht synchronisiert | Zwei konkurrierende Versionen in Chat oder Notiz verteilen | Clientstatus, Tresorsperre, Konflikt, Offlinezustand und Versionshistorie prüfen. |
| Kollege sieht Eintrag nicht | Einzelkopie im persönlichen Tresor anlegen | Gruppenmitgliedschaft, Sammlung, Rolle und Synchronisierung kontrollieren. |
| Unerwartete Freigabe oder Exportmeldung | Meldung löschen und nur Master-Passphrase ändern | Sitzungen, Geräte, Ereignisprotokoll, Mitgliedschaften und betroffene Geheimnisse untersuchen. |
| Browser bietet eigenes Speichern an | Zweite parallele Passwortliste weiterpflegen | Browserinterne Speicherung nach erfolgreichem Rollout zentral deaktivieren. |
Wird ein Kennwort am Zielsystem geändert, erfolgt die Aktualisierung in derselben kontrollierten Sitzung. Danach wird abgemeldet und die neue Anmeldung getestet. Versionshistorie ist für Fehlersuche hilfreich, darf aber nicht als dauerhafte Sammlung kompromittierter Altkennwörter missverstanden werden. Bei Verdacht werden betroffene Sitzungen und Wiederherstellungswege zusätzlich zum Kennwort geprüft.
Die Zwischenablage bleibt ein bewusster Ausnahmeweg, wenn Autofill technisch nicht möglich ist. Der Client löscht kopierte Geheimnisse nach kurzer Zeit, sofern die eingesetzte Plattform dies zuverlässig unterstützt. In Remote-Sitzungen, Bildschirmfreigaben und Supportterminen wird vor dem Kopieren geprüft, welches System die Zwischenablage mitlesen oder zwischen Geräten übertragen kann.
7. Notfallzugang schützt Verfügbarkeit, ohne den Tresor im Alltag zu öffnen
Der Ausfall einer Geschäftsführung oder Administration darf kritische Systeme nicht dauerhaft unzugänglich machen. Gleichzeitig darf die Notfallvorsorge keinen einfachen zweiten Weg um Master-Passphrase und MFA schaffen.
| Baustein | Gestaltung | Kontrolle |
|---|---|---|
| Auslöser | Handlungsunfähigkeit, bestätigter Verlust, Ausscheiden oder technischer Totalausfall klar definieren | Kein Einsatz nur aus Bequemlichkeit |
| Freigabe | Mindestens zwei benannte Personen oder Rollen entscheiden nach dokumentierter Prüfung. | Vier-Augen-Nachweis |
| Recovery-Funktion | Herstellermechanismus und seine Reichweite genau verstehen; Wartezeit und Benachrichtigung aktivieren, wenn verfügbar. | Test mit nicht produktivem Konto |
| Ersatz-Authenticator | Separat verwahrter Sicherheitsschlüssel oder Recovery-Code | Inventar, Siegel und Zugriffsnachweis |
| Export | Verschlüsselte, offline verwahrte und regelmäßig erneuerte Kopie kritischer Teamdaten | Wiederherstellungstest auf isolierter Testumgebung |
| Nachbereitung | Alle im Notfall offengelegten oder exportierten Geheimnisse nach Risiko rotieren. | Abschlussliste mit Verantwortlichen und Terminen |
Schritt für Schritt: Den Notfallzugang testen
- Konkreten Auslöser wählen, etwa nicht erreichbarer Hauptadministrator und verlorenes Diensttelefon.
- Übung ankündigen, ohne produktive Hauptzugänge oder reale Master-Passphrasen offenzulegen.
- Prüfen, ob Kontaktdaten, Rollen und Vertretungen außerhalb des Tresors verfügbar sind.
- Vorgesehene zwei Freigabepersonen identifizieren und Entscheidung dokumentieren lassen.
- Ersatzschlüssel, Recovery-Unterlage oder Herstellerfunktion anhand des Inventars auffinden.
- Siegel, Zugriff, Zeit und handelnde Personen protokollieren.
- Mit einem Testkonto oder eigens vorbereiteten Notfallobjekt den Zugang vollständig durchführen.
- Prüfen, welche Daten tatsächlich sichtbar, exportierbar oder wiederherstellbar werden.
- Ein verschlüsseltes Testexportpaket auf einer getrennten Umgebung öffnen und ausgewählte Einträge kontrollieren.
- Temporäre Klartextdaten, Browser-Downloads und Zwischenablage nachweisen und entfernen.
- Benachrichtigungen und Ereignisprotokolle kontrollieren.
- Notfallzugang wieder sperren, Testgeheimnisse ändern und physische Unterlagen neu versiegeln.
- Zeitbedarf, unklare Schritte, fehlende Rechte und Einzelabhängigkeiten auswerten.
- Verfahren korrigieren und offenen Maßnahmen Eigentümer sowie Termin zuweisen.
Ein Export kann selbst zum größten Klartextbestand werden
Viele Austauschformate speichern Kennwörter unverschlüsselt. Der Export wird deshalb nur auf einem kontrollierten Gerät erzeugt, unmittelbar verschlüsselt, nicht synchronisiert und nach dem vorgesehenen Zweck aus Downloadordner, Papierkorb, temporären Dateien und Sicherungswegen entfernt. Die verschlüsselte Notfallkopie erhält einen getrennt verwahrten Schlüssel und ein Erneuerungsdatum.
8. Beim Austritt werden Rechte entzogen und exponierte Geheimnisse bewertet
Das Entfernen eines Mitglieds verhindert künftigen Tresorzugriff, kann aber bereits gesehene, kopierte oder exportierte Kennwörter nicht zurückholen. Deshalb verbindet Offboarding den technischen Entzug mit einer risikobasierten Rotation.
Schritt für Schritt: Eine Person sicher aus dem Passwortmanager entfernen
- Austrittszeitpunkt, verantwortliche Führungskraft und technisch ausführende Person festlegen.
- Mitgliedschaften, Gruppen, Sammlungen, Organisationsrolle, Geräte und aktive Sitzungen erfassen.
- Offene persönliche Einträge mit betrieblichem Zweck in zuständige Team-Sammlungen überführen.
- Private Inhalte weder einsehen noch übernehmen; Zweifelsfälle mit klarer Verantwortlichkeit klären.
- Zugang zum Organisationsmandanten zum festgelegten Zeitpunkt sperren und Sitzungen beenden.
- Registrierte Geräte, API-Zugriffe, Erweiterungen und Recovery-Berechtigungen entfernen.
- Alle Geheimnisse priorisieren, die sichtbar oder exportierbar waren und kritische Systeme schützen.
- Administrator-, E-Mail-, Finanz-, Domain-, Backup-, VPN- und Fernwartungszugänge zuerst rotieren.
- Bei gemeinsamem Konto neues Kennwort im Tresor erzeugen, am Zielsystem ändern und Funktion testen.
- MFA, Wiederherstellungscodes, hinterlegte Telefonnummern und E-Mail-Adressen am Zielsystem mitprüfen.
- Protokolle auf ungewöhnliche Exporte, Freigaben oder Änderungen im relevanten Zeitraum prüfen, soweit verfügbar und sachlich erforderlich.
- Rollen- und Gruppenbestand nach dem Entzug erneut kontrollieren.
- Abschluss mit entfernten Zugängen, rotierten Geheimnissen, offenen Risiken und Verantwortlichen dokumentieren.
9. Die Abnahme prüft reale Nutzung, Entzug und Wiederherstellung
Eine erfolgreiche Anmeldung beweist nur einen Teil der Einführung. Die Abnahme umfasst Berechtigungsgrenzen, Autofill, Importvollständigkeit, Gerätewechsel, Notfallzugang und den kontrollierten Austritt.
| Testfall | Erwartetes Ergebnis | Nachweis |
|---|---|---|
| Persönliche Anmeldung | Master-Passphrase und starke MFA funktionieren; Tresor sperrt nach Vorgabe. | Anmeldung auf freigegebenen Plattformen |
| Falsche Domain | Autofill bietet Zugang nicht auf ähnlich aussehender fremder Domain an. | Dokumentierter Browsertest |
| Teamfreigabe | Nur vorgesehene Gruppe sieht und verwendet den Eintrag. | Tests mit berechtigtem und unberechtigtem Konto |
| Rechteänderung | Entzug wirkt zeitnah auf Clients und aktive Sitzungen gemäß Produktverhalten. | Vorher-Nachher-Protokoll |
| Import | Felder, URLs, Anhänge und Sonderzeichen sind vollständig; Dubletten geklärt. | Stichprobe und Mengenabgleich |
| Export | Vollständige, verschlüsselte Kopie ist wiederherstellbar; Klartextreste sind entfernt. | Restore-Protokoll |
| Geräteverlust | Gerät und Methode werden entfernt; unabhängiger Ersatz funktioniert. | Übung mit Testkonto |
| Notfall | Zwei Rollen können kritische Teamdaten kontrolliert wieder zugänglich machen. | Notfallprotokoll und Benachrichtigung |
| Austritt | Mitgliedschaft, Geräte und Rollen sind entfernt; kritische Kennwörter priorisiert rotiert. | Offboarding-Checkliste |
Abschlusscheck für den Regelbetrieb
- Organisationsmandant, Vertrag und Abrechnung hängen nicht von einer einzelnen Privatadresse ab.
- Mindestens zwei geeignete Personen können Organisations- und Notfallaufgaben übernehmen.
- Jede beschäftigte Person verwendet ein eigenes Konto, eine eigene Master-Passphrase und starke MFA.
- Gruppen und Sammlungen bilden den minimal erforderlichen Zugriff ab.
- Gemeinsame Kennwörter werden ausschließlich im vorgesehenen Team-Bereich geteilt.
- Browser und Geräte sperren den Tresor nach der festgelegten Inaktivität.
- Importierte Dubletten, veraltete Konten und wiederverwendete Kennwörter besitzen einen Bearbeitungsstatus.
- Notfallzugang und verschlüsselter Export wurden praktisch wiederhergestellt.
- Offboarding umfasst Entzug, Sitzungen, Geräte und risikobasierte Rotation.
- Updates, Schwachstellenmeldungen, Mitglieder und Notfallverfahren werden regelmäßig geprüft.
Häufige Fragen zu Passwortmanagern in kleinen Unternehmen
Darf die Master-Passphrase im Notfallumschlag liegen?
Für ein persönliches Tageskonto ist eine zentral hinterlegte Kopie problematisch. Besser sind ein geregelter Organisations-Recovery-Prozess und getrennte Notfallzugänge. Falls ein versiegeltes Geheimnis unvermeidbar ist, werden Zugriff, Lagerort, zweite Freigabe, regelmäßige Kontrolle und Rotation nach Öffnung ausdrücklich geregelt.
Sollten TOTP-Codes zusammen mit dem Kennwort gespeichert werden?
Das erhöht die Bedienbarkeit, verringert aber die Trennung der Faktoren: Wer den entsperrten Tresor übernimmt, erhält beide Werte. Für weniger kritische Dienste kann das nach bewusster Abwägung vertretbar sein. Administrator-, E-Mail-, Finanz- und Recovery-Konten sollten eine unabhängige, möglichst phishing-resistente MFA verwenden.
Müssen Kennwörter regelmäßig geändert werden?
Eine pauschale periodische Änderung ohne Anlass führt häufig zu vorhersehbaren Varianten und zusätzlicher Arbeit. Geändert wird bei Verdacht oder bestätigter Kompromittierung, nach relevanter Offenlegung, bei unsicherem Standardkennwort und wenn der Zugriff nach einem Austritt nicht anders zuverlässig entzogen werden kann.
Reicht der im Browser eingebaute Passwortspeicher?
Für persönliche Nutzung kann er viele Grundfunktionen erfüllen. Ein Unternehmen benötigt zusätzlich Eigentum am Mandanten, Gruppenfreigaben, Rollen, Protokolle, Recovery, kontrolliertes Offboarding und einen vollständigen Export. Ob ein Browser-Ökosystem das in der eingesetzten Geschäftstarifstufe leistet, wird anhand derselben Kriterien geprüft.
Was geschieht, wenn der Anbieter ausfällt?
Viele Clients halten einen verschlüsselten lokalen Datenstand vor, doch Verhalten und Dauer unterscheiden sich. Der Pilot prüft Anmeldung ohne Serverkontakt, Synchronisierung nach Wiederkehr und Grenzen mobiler Geräte. Für einen längeren oder endgültigen Ausfall benötigt das Unternehmen zusätzlich einen aktuellen, verschlüsselten und tatsächlich wiederherstellbaren Export.
Weiterführende fachliche Grundlagen
Passwortmanager strukturiert auswählen und einführen
fra.digital unterstützt kleine Unternehmen in Frankfurt bei Anforderungskatalog, Produkttest, Tresorstruktur, Migration, MFA, Notfallzugang und der technischen Abnahme des Regelbetriebs.
