Gemeinsame Logins im Team: Wann eigene Konten besser sind

Dann reicht es nicht, das Passwort „sicher zu teilen“. Der Zugang braucht einen benannten Verantwortlichen, eine aktuelle Zugriffsliste, Mehrfaktor-Authentifizierung (MFA), einen geschützten Passwort-Tresor oder einen vorgeschalteten Identitätsdienst, Protokolle und eine feste Regel für Entzug und Passwortwechsel.

So ist der Vergleich aufgebaut

Die Entscheidungshilfe vergleicht vier Fragen: Lässt sich eine Aktion einer Person zuordnen? Kann der Zugriff einer einzelnen Person entzogen werden? Wie viele Menschen kennen das Geheimnis? Und handelt es sich überhaupt um einen menschlichen Zugang – oder um eine technische Identität für eine Automation?

Die kurze Antwort: Bequemlichkeit allein ist kein ausreichender Grund für einen gemeinsamen Login.

Warum persönliche Konten fast immer die bessere Wahl sind

Bei einem persönlichen Konto erhält jede Person eine eigene Benutzerkennung. Rollen und Rechte lassen sich passend zur Aufgabe vergeben und später einzeln ändern oder entziehen. Das britische NCSC empfiehlt für kleine und mittlere Organisationen ausdrücklich getrennte Arbeitskonten, weil gemeinsame Konten Datenschutz, Nachvollziehbarkeit und Schadensbegrenzung erschweren.

Auch das BSI stellt beim Identitäts- und Berechtigungsmanagement auf tatsächlichen Bedarf, klare Zuordnung, dokumentierte Rechte und den Entzug nicht mehr benötigter Zugänge ab. Für kleine Teams ist das keine Bürokratieübung: Es beantwortet die praktische Frage, ob nach einem Personalwechsel wirklich nur die richtige Person ausgesperrt wird.

Wann ein gemeinsamer Zugang vertretbar sein kann

Eine Ausnahme kann sinnvoll sein, wenn ein älterer SaaS-Dienst nur einen einzigen Benutzer unterstützt, ein gemeinsam betreuter Markenkanal technisch keine persönlichen Rollen anbietet oder ein getrenntes Notfallkonto für die Wiederherstellung vorgesehen ist.

Vor der Ausnahme stehen drei Prüfungen:

1. Unterstützt der Anbieter wirklich keine persönlichen Nutzer, Rollen, Gäste oder Single Sign-on? Wenn doch, ist das die sauberere Lösung.
2. Ist der Zugang für die tägliche Arbeit nötig? Ein Notfallkonto darf kein bequemer Admin-Login für den Alltag werden.
3. Kann die Nutzung trotz gemeinsamer Zielanmeldung einer Person zugeordnet werden? Ein Identitätsdienst oder Passwort-Tresor kann den Zugriff vermitteln und protokollieren, ohne das Passwort offen zu verteilen. Microsoft beschreibt dieses Broker-Modell für Anwendungen mit passwortbasiertem Single Sign-on.

Fehlt eine dieser Bedingungen, sollte das Team den gemeinsamen Zugang nicht als Dauerlösung akzeptieren, sondern Anbieterwechsel, Tarifwechsel oder eine andere technische Anbindung prüfen.

Technische Konten sind keine Teamkonten

Automationen, Integrationen und Skripte sollten nicht unter dem persönlichen Konto eines Mitarbeiters laufen. Dafür sind – je nach Plattform – verwaltete Identitäten, Service Principals oder klar begrenzte Servicekonten vorgesehen. Microsoft empfiehlt, Zweck, Verantwortlichen, Rechte, Laufzeit und Überprüfung solcher Konten zu dokumentieren und ihre Rechte auf das notwendige Maß zu beschränken.

Das verhindert zwei typische Abhängigkeiten: Eine Automation fällt nicht unbemerkt aus, nur weil eine Person das Unternehmen verlässt; zugleich muss kein menschlicher Login dauerhaft für eine Maschine freigegeben bleiben.

Sechs Kontrollen für eine unvermeidbare Ausnahme

1. Verantwortlichen benennen: Eine Person oder Rolle entscheidet über Freigabe, Entzug und regelmäßige Prüfung.
2. Berechtigte sichtbar halten: Eine aktuelle Liste zeigt, wer den Zugang nutzen darf. „Das ganze Team“ ist keine belastbare Zugriffsliste.
3. Geheimnis abschirmen: Das Passwort gehört in einen Team-Tresor oder hinter einen Identitätsdienst. Es gehört nicht in Chat, Wiki, Ticket oder Tabellenblatt.
4. MFA passend organisieren: Mehrfaktor-Authentifizierung bleibt aktiv. Wiederherstellungscodes und Sicherheitsgeräte werden kontrolliert verwahrt; Codes werden nicht spontan im Chat weitergereicht.
5. Nutzung protokollieren: Wo möglich, zeigen Tresor, Identitätsdienst oder Anwendung, wer den Zugriff ausgelöst hat. NIST weist darauf hin, dass geteilte Konten ein erhöhtes Risiko darstellen können und dass gemeinsame Authentisierungsmerkmale bei Änderungen der Gruppe gewechselt werden müssen.
6. Austritt vollständig behandeln: Beim Offboarding werden Berechtigung und aktive Sitzungen entzogen. Bei einem gemeinsamen Geheimnis wird es gewechselt; Tokens und verbundene Integrationen werden auf fortbestehenden Bedarf geprüft.

Die australische Cyber-Sicherheitsbehörde fasst die Ausnahme ähnlich knapp: persönliche Konten bevorzugen; wenn ein gemeinsamer Zugang unvermeidbar ist, MFA einsetzen und die berechtigten Personen dokumentieren.

So stellst du ohne Unterbrechung um

Beginne mit den kritischsten Diensten: primäre E-Mail, Passwort-Tresor, Domain und DNS, Buchhaltung, Zahlungsdienste, Cloud-Administration und zentrale Kundensysteme.

• Erfasse jeden gemeinsamen Login mit Dienst, Zweck, Verantwortlichem und berechtigten Personen.
• Prüfe, ob der Anbieter persönliche Nutzer, Rollen, Gäste oder Single Sign-on anbietet.
• Lege persönliche Konten an und vergib nur die nötigen Rechte.
• Teste Anmeldung, MFA, Wiederherstellung und mindestens einen Entzug.
• Ändere danach das alte gemeinsame Passwort oder deaktiviere den Zugang.
• Dokumentiere, was beim Eintritt, Rollenwechsel und Austritt zu tun ist.

Für die breitere Absicherung des gesamten Bestands hilft der Leitfaden Team-Zugänge absichern: 5 Regeln für kleine Teams. Wenn du MFA noch sauber einrichten musst, führt Konten besser schützen: So klappt der zweite Schutz durch Methode und Wiederherstellung. Bei Agentur- und Kundenkonten ergänzt Kundenzugänge sicher teilen: ohne Passwort-Chaos die Trennung von internen und externen Zugriffsbereichen.

Der 60-Sekunden-Test

Der Zugang ist nur dann sauber geregelt, wenn du alle fünf Fragen mit Ja beantworten kannst:

• Ist jede berechtigte Person namentlich oder über eine klar gepflegte Gruppe sichtbar?
• Kannst du den Zugriff einer einzelnen Person entziehen, ohne alle anderen auszusperren?
• Ist MFA aktiv, ohne dass Codes unkontrolliert geteilt werden?
• Lässt sich eine Nutzung einer Person oder einem kontrollierten Prozess zuordnen?
• Gibt es einen dokumentierten Ablauf für Rollenwechsel, Austritt und Notfall?

Schon ein Nein zeigt die nächste konkrete Aufgabe. Es ist kein Grund, den gesamten Zugriff auf einmal neu zu bauen.

Quellen und Einordnung

Die Empfehlung stützt sich auf Leitlinien des NCSC zu getrennten Arbeitskonten, die BSI-Umsetzungshinweise zum Identitäts- und Berechtigungsmanagement, NIST SP 800-53 Rev. 5, Microsofts Dokumentation zu gemeinsam genutzten Anmeldedaten und Servicekonten sowie die Hinweise der australischen Cyber-Sicherheitsbehörde für kleine Unternehmen. Die konkrete Umsetzung hängt von den Funktionen und Lizenzbedingungen des jeweiligen Dienstes ab.