Kundenzugänge sicher teilen: ohne Passwort-Chaos

Die kurze Antwort

Kundenzugänge teilt man am sichersten, indem man gar kein gemeinsames Passwort verteilt. Der Kunde legt für jede Person ein eigenes Konto an, gibt nur die nötige Rolle frei und entfernt den Zugang nach dem Projekt. So bleibt sichtbar, wer etwas geändert hat.

Bietet ein Dienst keine persönlichen Konten oder Gastrollen, ist ein gemeinsamer Zugang manchmal unvermeidbar. Dann gehört das Passwort in einen verwalteten Team-Tresor eines Passwortmanagers – nicht in E-Mail, Messenger, Ticket, Notiz oder Tabelle. Das britische NCSC empfiehlt das Teilen von Passwörtern nicht. Wo es noch keine Alternative gibt, nennt es zentrale Rechteverwaltung, Protokolle und synchronisierte Passwortänderungen als wichtige Schutzmaßnahmen (NCSC-Leitfaden).

Kurz gesagt

• Erste Wahl: persönliches Konto mit passender Rolle und eigener MFA.
• Zweite Wahl: zeitlich begrenzter Gastzugang oder delegierte Berechtigung.
• Nur als Notlösung: gemeinsames Passwort in einem geschäftlichen Team-Tresor.
• Für Technik: API-Schlüssel, SSH-Schlüssel und andere Secrets getrennt in einem Secret-Manager verwalten.
• Immer festlegen: Eigentümer, Umfang, Ablaufdatum, Wiederherstellung und Entzug.

Diese Anleitung richtet sich an Freelancer, Agenturen, IT-Dienstleister und kleine Teams, die auf Kundenkonten für Websites, Werbung, Cloud, Support oder Buchhaltung zugreifen. Wer nur sein eigenes Privatkonto schützen will, braucht weniger Prozess. Sobald jedoch mehrere Firmen beteiligt sind, reicht „Ich schicke dir kurz das Passwort“ nicht mehr.

Das eigentliche Problem ist nicht das Übertragen

Eine verschlüsselte Nachricht kann den Transport schützen. Danach liegen aber oft Kopien auf mehreren Geräten. Niemand weiß sicher, wer den Zugang noch besitzt. Ein gemeinsames Konto erschwert außerdem die Zuordnung von Änderungen. Das NCSC empfiehlt deshalb getrennte Benutzerkonten; der CIS Control 5 behandelt das Erstellen, Verwalten und Entfernen von Benutzer-, Admin- und Dienstkonten als eigenen Sicherheitsprozess (NCSC zu getrennten Konten, CIS Control 5).

Ich halte daher die Frage „Wie sende ich das Passwort sicher?“ für zu klein. Die bessere Frage lautet: Wie erteile, begrenze und entziehe ich Zugang, ohne dass das Kundengeschäft von einer einzelnen Person abhängt?

So richtest du Kundenzugänge sauber ein

1. Der Kunde behält die Kontrolle

Das geschäftliche Hauptkonto sollte dem Kunden gehören. Das gilt auch für die Rechnungsadresse, die primäre Domain, die Wiederherstellungs-E-Mail und mindestens ein dauerhaftes Admin-Konto. Ein Kundenkonto im privaten Passwort-Tresor eines Freelancers ist für mich ein Eigentumsfehler: Endet die Zusammenarbeit, darf der Kunde nicht erst nach seinen eigenen Schlüsseln suchen.

Wenn der Dienst mehrere Nutzer erlaubt, nutze eigene Zugänge statt gemeinsamer Logins. Vergib nicht vorsorglich Adminrechte. Wer nur Berichte liest, braucht keine Berechtigung zum Löschen oder Bezahlen. Das entspricht dem Prinzip der kleinsten Rechte, das auch OWASP für Secrets fordert (OWASP Secrets Management).

2. Erstelle ein kleines „Zugangspaket“

Für jeden Dienst reichen sieben Angaben:

1. Dienst und Projekt: Wofür wird der Zugang gebraucht?
2. Geschäftlicher Eigentümer: Wer beim Kunden entscheidet über Rechte?
3. Person oder System: Wer oder was erhält Zugang?
4. Rolle und Umfang: Lesen, bearbeiten, veröffentlichen, abrechnen oder administrieren?
5. MFA und Wiederherstellung: Wer verwaltet zweiten Faktor und Wiederherstellungscodes?
6. Prüf- oder Enddatum: Wann wird der Zugang erneut geprüft oder entfernt?
7. Entzugsplan: Muss man nur einen Nutzer löschen oder zusätzlich Passwort, Schlüssel und Sitzungen wechseln?

Dieses Paket ist keine große Bürokratie. Eine Zeile pro Dienst genügt. Der Nutzen: Schon beim Einrichten ist klar, wie der Zugang später wieder verschwindet.

3. Sichere den Zugang mit MFA

Für persönliche Konten sollte jede Person ihren eigenen zweiten Faktor einrichten. MFA verlangt mehr als nur ein Passwort und erschwert damit unberechtigte Anmeldungen; CISA empfiehlt Unternehmen nach Möglichkeit phishing-resistente Verfahren (CISA zu MFA). Eine einfache Einführung bietet unser Leitfaden zum Schutz von Konten mit einem zweiten Faktor.

Bei einem unvermeidbaren gemeinsamen Login wird es schwieriger. Lege fest, wer das MFA-Gerät und die Wiederherstellungscodes kontrolliert. Speichere Wiederherstellungscodes nicht im Chat. Werden Passwort und Einmalcode im selben Tresor für dieselben Personen freigegeben, ist die Bedienung leichter, aber die Trennung der Faktoren schwächer. Für kritische Konten ist ein persönlicher, hardware- oder passkeybasierter Zugang meist die bessere Lösung.

4. Nutze für gemeinsame Passwörter einen Team-Tresor

Ein Passwortmanager löst nicht jedes Zugriffsproblem. Er ist aber deutlich besser als eine verstreute Tabelle, wenn ein Passwort wirklich gemeinsam genutzt werden muss. Achte auf:

• geschäftliche statt private Eigentümerschaft,
• getrennte Tresore oder Sammlungen je Kunde,
• Rechte pro Person oder Gruppe,
• MFA für den Tresor,
• nachvollziehbare Zugriffe und Änderungen,
• einen klaren Prozess für Eintritt und Austritt,
• Wiederherstellung, die nicht an nur einer Person hängt.

Das NCSC nennt genau solche Verwaltungs- und Protokollfunktionen als Auswahlkriterien. Das BSI rät zu einzigartigen Passwörtern, Passwortmanagern und zusätzlicher Zwei-Faktor-Authentisierung (BSI-Basistipps).

5. Behandle technische Secrets anders

API-Schlüssel, SSH-Schlüssel, Datenbankpasswörter und Zertifikate sind keine normalen Team-Passwörter. Lege pro Projekt oder Anwendung eigene Schlüssel an. Begrenze Berechtigungen und – wenn der Dienst es erlaubt – Laufzeit, Herkunft oder Umgebung. Schreibe Secrets niemals in Quellcode, Chat oder Aufgabenbeschreibung.

OWASP beschreibt für Secrets einen Lebenszyklus aus Erzeugung, Rotation, Widerruf und Ablauf. Es empfiehlt zudem zentrale Verwaltung, feine Zugriffskontrollen und Protokollierung. Genau deshalb gehört ein Produktionsschlüssel in einen Secret-Manager und nicht in denselben Ordner wie ein Kundenbriefing.

Was am Projektende passieren muss

Plane das Offboarding bereits beim Onboarding. Am letzten Arbeitstag sollte eine verantwortliche Person:

1. persönliche Nutzer- und Gastkonten entfernen,
2. aktive Sitzungen und verbundene Geräte prüfen,
3. gemeinsame Passwörter ändern, wenn die ausgeschiedene Person sie sehen konnte,
4. API- und SSH-Schlüssel widerrufen oder ersetzen,
5. MFA-Geräte und Wiederherstellungskontakte kontrollieren,
6. unnötige Integrationen und App-Freigaben entfernen,
7. den Kunden den verbleibenden Eigentümer- und Adminzugang bestätigen lassen.

NIST beschreibt Widerruf als das Aufheben der Bindung zwischen Authentifikator und Konto und verlangt bei Kompromittierung eine schnelle Ungültigmachung. Die Richtlinie weist zugleich darauf hin, dass absichtliches Teilen technischer Authentifikatoren nur begrenzt verhindert werden kann (NIST SP 800-63B). Ein Prozess ist deshalb wichtiger als die Hoffnung, dass niemand eine Kopie angelegt hat.

Unsere fünf einfachen Regeln für sichere Team-Zugänge eignen sich als kurze wiederkehrende Kontrolle.

Passwort versehentlich im Chat geteilt: Was jetzt?

Behandle das Passwort als offengelegt – auch wenn die Nachricht gelöscht wurde. Gehe in dieser Reihenfolge vor:

1. Passwort über die echte Website oder App ändern.
2. Andere Sitzungen und Geräte abmelden, soweit der Dienst das erlaubt.
3. MFA, Wiederherstellungs-E-Mail und Wiederherstellungscodes prüfen.
4. Unbekannte Änderungen und Anmeldungen im Protokoll suchen.
5. Dasselbe Passwort überall ersetzen, wo es wiederverwendet wurde.
6. Den Zugang anschließend korrekt als persönliches Konto oder über einen Team-Tresor einrichten.

Nur die Chatnachricht zu löschen reicht nicht. Kopien können in Benachrichtigungen, Backups oder auf anderen Geräten bleiben.

Häufige Fragen

Darf ich ein Passwort per E-Mail oder WhatsApp schicken?

Für dauerhafte Kundenzugänge ist das keine gute Lösung. Der Empfänger kann die Nachricht weiterleiten, kopieren oder auf einem ungeschützten Gerät behalten. Richte lieber ein persönliches Konto ein. Wenn das nicht geht, teile den Eintrag über einen verwalteten Team-Tresor.

Was, wenn der Kunde keinen zusätzlichen Nutzer bezahlen will?

Erkläre zuerst das Risiko und prüfe Gastrollen, delegierte Rechte oder einen zeitlich begrenzten Zugang. Bleibt nur ein gemeinsamer Login, dokumentiere die Ausnahme, begrenze den Personenkreis und ändere das Passwort beim Austritt. Bei besonders sensiblen Systemen – etwa primärer E-Mail, Domain, Zahlungs- oder Cloud-Admin – würde ich ohne persönlichen Zugang keine dauerhafte Verantwortung übernehmen.

Wem sollte der Passwortmanager gehören?

Dem Unternehmen, das die Zugänge kontrollieren muss. Kundeneigene Kernkonten sollten nicht ausschließlich im privaten Tresor einer Agentur oder eines Freelancers liegen. Für Agenturarbeit kann ein geschäftlicher Tresor sinnvoll sein, solange Eigentum, Export, Wiederherstellung und Übergabe klar geregelt sind.

Muss ein Passwort regelmäßig geändert werden?

Nicht allein, weil ein Kalenderdatum erreicht ist. Wichtiger sind einzigartige Passwörter, MFA und eine Änderung bei vermutetem Verlust oder wenn eine Person ein gemeinsames Passwort nicht mehr kennen darf. Technische Schlüssel können dagegen nach einem geplanten Lebenszyklus rotieren.

Kann ein Passwortmanager garantieren, dass niemand das Passwort kopiert?

Nein. Wer ein Geheimnis sehen oder benutzen darf, kann es unter Umständen kopieren. Ein Team-Tresor reduziert unkontrollierte Verteilung und erleichtert Entzug, Änderung und Protokollierung. Persönliche Konten sind trotzdem die sauberere Lösung.

Fazit

Sicheres Teilen beginnt nicht mit einem Übertragungskanal, sondern mit klarer Eigentümerschaft. Persönliche Konten, kleine Rollen, MFA und ein festes Enddatum lösen die meisten Probleme. Ein Team-Passwortmanager ist der Plan B für Dienste, die keine bessere Rechteverwaltung anbieten. Für API- und Infrastrukturzugänge braucht es einen eigenen Secret-Prozess.

Bence – oder auf Deutsch: Meiner Ansicht nach – ist die beste Regel erstaunlich einfach: Teile so wenig Geheimnisse wie möglich und so viele klar begrenzte Zugänge wie nötig.