Zugänge für Kundenprojekte sicher teilen

• Weil der Artikel zeigt, wie kleine Teams Zugänge ordentlich speichern, gezielt teilen und am Projektende sauber weitergeben können.
• Der Nutzen liegt in der einfachen Trennung von drei Dingen: normale Logins, geheime Technik-Daten und gemeinsame 2FA-Zugänge. Dazu kommt eine Einordnung nach Teamgröße, die viele allgemeine Listen nicht bieten.

Die Einleitung soll die Kernregel sofort verständlich machen: Kleine Agenturen brauchen keine Tool-Sammlung, sondern eine klare Trennung zwischen normalen Logins, technischen Geheimnissen, 2FA und Übergabe. Danach sollte der Leser wissen, warum der Artikel genau diese vier Bausteine sortiert.

Welcher Passwortmanager passt fuer kleine Agenturen?

Wenn eine Agentur mehrere Kunden betreut, ist ein Passwortmanager der erste feste Ort fuer Logins. Einfach gesagt: Das Tool ersetzt Chat-Nachrichten, Tabellen und lose Notizen. Wichtig ist nicht nur, dass Passwoerter gespeichert werden, sondern wie sie fuer Projekte geteilt werden.

Fuer kleine Agenturen zaehlen im Alltag vor allem drei Fragen:

• Gibt es gemeinsame Bereiche fuer einzelne Kundenprojekte?
• Kann jede Person nur das sehen, was sie wirklich braucht?
• Laesst sich ein Zugang spaeter sauber an den Kunden uebergeben oder wieder entziehen?

1Password: stark, wenn Kunden gezielt mit hineinmuessen

1Password arbeitet mit Tresoren. Das bedeutet: Du legst getrennte Bereiche an, zum Beispiel einen Tresor pro Kunde oder pro Projekt. Laut 1Password sind geteilte Tresore genau dafuer gedacht, Daten sauber zu trennen und den Zugriff nur an die richtigen Personen zu geben. Ausserdem gibt es Gastkonten fuer externe Personen. Diese Gaeste koennen nur auf einen geteilten Tresor zugreifen. Das ist im Agenturalltag sehr praktisch, wenn ein Kunde nur die Logins fuer sein eigenes Projekt sehen soll und sonst nichts. (1password.com)

Wichtig fuer Uebergaben: In 1Password ist das Exportieren kein verstecktes Nebenfeature, sondern eine eigene Berechtigung auf Tresor-Ebene. Das bedeutet: Du kannst genauer steuern, wer Inhalte nur sieht und wer sie wirklich aus dem System herausziehen darf. Fuer kleine Agenturen ist das hilfreich, wenn nicht jede Mitarbeiterin und nicht jeder Mitarbeiter Daten frei exportieren soll. (developer.1password.com)

Kurz gesagt: 1Password passt gut, wenn du Kundenzugaenge fein abgrenzen willst und oft mit externen Personen arbeitest.

Bitwarden: klarer Start fuer kleine Teams mit Projektordnern

Bitwarden organisiert Teamzugriffe ueber Organisationen und Collections. Einfach gesagt: Eine Collection ist ein gemeinsamer Bereich fuer bestimmte Eintraege, zum Beispiel fuer einen Kunden, ein internes Tool oder ein einzelnes Projekt. Nutzer oder Gruppen werden diesen Collections zugewiesen. So laesst sich gut trennen, wer welchen Kunden sehen darf. (bitwarden.com)

Fuer kleine Teams ist auch die Einordnung einfach: Der offizielle Teams-Plan wird von Bitwarden mit 4 US-Dollar pro Nutzer und Monat bei jaehrlicher Abrechnung ausgewiesen. Fuer eine Agentur mit zwei oder fuenf Personen ist das ein leicht verstaendlicher Startpunkt. Wenn spaeter eine Uebergabe oder ein Wechsel noetig ist, koennen Mitglieder mit passender Verwaltungsberechtigung Organisationsdaten exportieren. (bitwarden.com)

Kurz gesagt: Bitwarden passt gut, wenn du schnell eine saubere Teamstruktur aufbauen willst und einfache Projektbereiche brauchst.

Welche Wahl ist fuer Solo-, Zwei- und Fuenf-Personen-Teams sinnvoll?

Solo: Du brauchst vor allem einen zentralen Ort statt Browser, Chat und Notizen. Entscheidend ist, dass du fuer jeden Kunden einen getrennten Bereich anlegst. Beide Modelle koennen das leisten. Wenn du haeufig spaeter Kunden direkt Zugang geben willst, ist 1Password mit Gastkonten besonders naheliegend. (support.1password.com)

Zwei Personen: Hier wird sicheres Teilen wichtig. Bitwarden ist leicht zu verstehen, weil ihr mit einer Organisation und klaren Collections arbeiten koennt. 1Password ist ebenfalls stark, wenn ihr frueh mit getrennten Tresoren pro Kunde arbeiten wollt. (bitwarden.com)

Fuenf Personen: Ab dieser Groesse werden Rollen und Grenzen wichtiger. Dann sollte nicht mehr jede Person alles sehen. 1Password bringt dafuer eine starke Logik mit getrennten Tresoren und begrenzten Gastzugriffen mit. Bitwarden bleibt gut, wenn ihr eure Collections sauber nach Kunden und Verantwortlichen pflegt. (support.1password.com)

Einfache redaktionelle Einordnung

Wenn du eine kundennahe Agentur bist und oft externe Personen einbeziehen musst, ist 1Password meist die klarere Wahl.

Wenn du ein kleines internes Team mit sauberer Projektstruktur suchst und einen einfachen Preiseinstieg willst, ist Bitwarden oft der schnellere Start.

Der wichtigste Punkt ist am Ende nicht die Marke. Der wichtigste Punkt ist die Struktur: ein Bereich pro Kunde, klare Rechte pro Person und kein Teilen von Logins ueber Chat oder E-Mail. Genau dort spart ein guter Team-Passwortmanager im Alltag am meisten Zeit und Fehler.

Wohin mit API-Schlüsseln und anderen Geheimnissen?

Viele kleine Teams werfen anfangs alles in einen Passwortmanager: Website-Logins, API-Schlüssel, Server-Tokens und private Keys. Für den Start ist das verständlich. Auf Dauer wird es aber unübersichtlich. Der wichtigste Grund ist: Technische Geheimnisse werden oft nicht nur von Menschen gelesen, sondern auch von Apps, Skripten oder Build-Prozessen genutzt. Dafür brauchen sie andere Abläufe als normale Team-Logins.

Genau hier hilft eine einfache Trennung. Normale Konten bleiben im Passwortmanager. API-Schlüssel, Tokens und andere Laufzeit-Geheimnisse gehören in ein Secret-Tool. So vermischst du nicht den Kundenlogin für ein Dashboard mit dem Schlüssel, den dein Deployment oder ein Script automatisch braucht.

Secret-Manager wie Doppler und Infisical sind genau für diesen zweiten Teil gebaut. Beide ordnen Geheimnisse nicht einfach in einer langen Liste, sondern nach Projekten und Umgebungen. Das ist praktisch, weil Entwicklung, Test und Live-System sonst schnell durcheinander geraten. Ein API-Schlüssel für eine Testumgebung sollte nicht neben dem Produktionswert liegen, wenn mehrere Personen im Team zugreifen.

Doppler passt vor allem dann gut, wenn Secrets als Umgebungsvariablen an Anwendungen übergeben werden sollen. Die Dokumentation zeigt außerdem, dass Rechte auf Projekt- und Umgebungsebene vergeben werden können. Für kleine Agenturen ist das nützlich, wenn nicht jede Person automatisch jedes Kundenprojekt oder jede Live-Umgebung sehen soll.

Infisical ist besonders dann gut einzuordnen, wenn du Secrets sichtbar nach Projekt, Umgebung und Ordnern strukturieren willst. Dazu kommt die CLI, also die Nutzung per Kommandozeile. Damit lassen sich Secrets auch in Entwicklungsabläufe, Skripte oder automatisierte Prozesse einbinden. Wenn ein Team schon etwas technischer arbeitet, ist das oft näher am Alltag als das manuelle Kopieren aus einem Tresor.

Wichtig ist aber die Abgrenzung: Ein Passwortmanager wird dadurch nicht überflüssig. Er bleibt der richtige Ort für normale Logins, geteilte Kundenkonten und andere Zugänge, die Menschen aktiv öffnen und benutzen. Für Secrets, die in Code, Build-Prozessen oder Server-Umgebungen gebraucht werden, ist er meist nicht der beste Hauptablageort.

Als Faustregel gilt daher: Menschen-Logins in den Passwortmanager, Anwendungs-Geheimnisse in ein Secret-Tool. Diese kleine Trennung schafft oft schon mehr Ordnung als jede spätere Sicherheitsdiskussion.

Wie teilen Teams gemeinsame Zugänge mit Zwei-Faktor-Schutz?

Wenn mehrere Menschen denselben Kundenzugang nutzen, ist meist nicht das Passwort das größte Problem, sondern der zweite Faktor. Unscharf wird es dann, wenn Einmalcodes per Chat weitergereicht werden oder nur auf dem Privatgerät einer Person liegen. Für kleine Teams ist ein gemeinsamer Organisations-Tresor der sauberere Weg: Der Login wird kontrolliert geteilt, statt in Tabellen, Notizen oder Einzelnachrichten zu landen.

Für den zweiten Faktor gibt es im Alltag zwei praktikable Wege.

Erstens: Passwort und 2FA-Code liegen zusammen im Passwortmanager. Das ist die bequemste Lösung. 1Password und Bitwarden können Einmalcodes direkt beim gespeicherten Login hinterlegen und anzeigen. Der Vorteil ist simpel: Teammitglieder müssen nicht zwischen Passwort-App und zweiter App springen. Für sehr kleine Teams mit wenigen gemeinsam genutzten Konten ist das oft der einfachste Start.

Zweitens: Der 2FA-Code liegt getrennt in einer Authenticator-App. Das ist oft die klarere Lösung, wenn mehrere Personen denselben Zugang brauchen oder wenn der Kunde den Zugang später leicht übernehmen soll. Google Authenticator eignet sich dafür als einfache, getrennte Option. Laut Google lassen sich Codes über mehrere Geräte synchronisieren, wenn man sich mit einem Google-Konto anmeldet. Alternativ können Codes per QR-Code auf ein neues Gerät übertragen werden.

Die praktische Abwägung ist daher nicht kompliziert: zusammen ist bequemer, getrennt ist oft sauberer. Wenn ihr schnell arbeiten müsst und nur wenige feste Personen beteiligt sind, kann ein Passwortmanager mit eingebautem Authenticator reichen. Wenn Vertretung, Übergabe oder klare Zuständigkeiten wichtiger sind, ist die Trennung von Passwort und 2FA oft robuster.

Wichtig ist vor allem, dass ihr euch für einen klaren Weg entscheidet. Also: Login in den Team-Tresor, 2FA bewusst entweder dort oder in einer separaten App, aber nicht nebenbei über Chats oder private Notizen organisieren. So bleibt ein gemeinsamer Kundenlogin auch dann handhabbar, wenn jemand ausfällt oder das Projekt später an den Kunden zurückgeht.

Wie trennst du interne Zugänge von Kunden-Zugängen sauber?

Die einfachste Regel lautet: Lege interne Zugänge, Kunden-Zugänge und heikle Sonderfälle nicht in einen gemeinsamen Sammelbereich. Wenn alles in einem einzigen Tresor liegt, wird der Alltag schnell unübersichtlich. Dann sehen Mitarbeitende zu viel, Freigaben werden unklar und bei einer Übergabe ist schwer zu erkennen, was wirklich zum Kunden gehört.

Sauberer ist eine Struktur mit getrennten Tresoren oder Bereichen. Die Herstellerdokumentation zu Proton Pass beschreibt einen Vault als eigenen Container für Logins und andere Einträge. Daraus lässt sich für kleine Agenturen eine klare Ordnung ableiten: ein Bereich für interne Logins, eigene Bereiche pro Kunde und bei Bedarf ein zusätzlicher Bereich für besonders sensible oder spätere Übergabe-Zugänge.

Wichtig ist dabei nicht nur die Trennung selbst, sondern auch die Rechte pro Bereich. Geteilte Vaults lassen sich mit unterschiedlichen Berechtigungen versehen, etwa nur zum Ansehen, Bearbeiten oder Verwalten. Für Kundenprojekte ist das praktisch, weil nicht jede Person automatisch Vollzugriff braucht. Das passt auch zum allgemeinen Rechteprinzip: Zugriffe sollten auf den Teil begrenzt werden, der für die Aufgabe wirklich nötig ist.

Für kleine Agenturen ist deshalb oft dieses Modell am klarsten:

• Intern: eigene Tools, Abrechnung, Domains, Admin-Zugänge
• Pro Kunde ein eigener Bereich: nur projektbezogene Logins und Notizen
• Optional Sonderfall oder Übergabe: besonders sensible Einträge oder alles, was am Projektende gesammelt weitergegeben wird

Sobald mehr als zwei Personen an Kundenprojekten arbeiten, sind Gruppen meist ordentlicher als einzelne Freigaben. Ein Vault kann dann einer Projektgruppe statt jeder Person einzeln zugewiesen werden. Neue Teammitglieder erhalten den passenden Zugriff über die Gruppe. Das spart Pflege und senkt das Risiko, dass alte oder falsche Freigaben liegen bleiben.

Auch für die spätere Übergabe hilft diese Trennung. Wenn der Kundenbereich separat geführt wird, lassen sich Zugriffe gesammelt entziehen oder an andere Personen übergeben. Das ist meist einfacher, als einzelne Logins aus einem gemischten Haupttresor herauszusuchen.

Als Praxisregel reicht oft schon diese Dreiteilung: intern, Kunde, Übergabe. Sie ist nicht kompliziert, verhindert aber viel typisches Agentur-Chaos.

Was passt zu kleinen Teams?

Kleine Agenturen brauchen meist keine große Sicherheitslösung. Wichtig ist vor allem: Passt das Tool zu eurer Teamgröße und zu eurem Alltag?

Einfach gesagt: Für normale Kunden-Logins ist ein Passwortmanager der erste Schritt. Für geheime technische Daten wie API-Schlüssel oder Tokens ist oft ein zweites, getrenntes Tool sinnvoll. Bitwarden trennt diese beiden Dinge klar. GitHub macht das auch, aber nur für Projekte, die dort ohnehin laufen.

Solo-Agentur

Wenn du allein arbeitest, reicht oft ein einfacher Passwortmanager. Dort speicherst du Kunden-Logins, Admin-Zugänge und Wiederherstellungscodes an einem sicheren Ort. Ein Secret-Manager lohnt sich erst, wenn du auch technische Schlüssel regelmäßig brauchst, zum Beispiel für Deployments oder Schnittstellen.

Zwei Personen

Ab zwei Personen wird Teilen wichtig. Dann braucht ihr einen Passwortmanager mit gemeinsamen Bereichen. So liegen Kunden-Logins nicht in Chats oder privaten Notizen. Für technische Schlüssel sollte es einen eigenen Ort geben. Das kann ein Secret-Manager sein oder GitHub-Secrets, wenn ihr Kundencode ohnehin in GitHub verwaltet.

Drei bis fünf Personen

Ab drei Personen wird klare Rechtevergabe wichtiger. Proton nennt für seine Business-Pläne eine Mindestgröße von drei Nutzern. Dort gibt es geteilte Vaults, Benutzerrechte und in passenden Plänen auch 2FA-Regeln. Das heißt: Nicht jeder sieht alles, und Zugriffe lassen sich wieder entfernen.

Gute Faustregel

• Solo: möglichst einfach starten
• 2 Personen: gemeinsam teilen, aber getrennt für Login und Technik
• 3 bis 5 Personen: Rechte, Gruppen und saubere Ordnung werden wichtig

So vermeidest du Chaos, ohne gleich ein schweres System einzuführen.

Wie übergibst du Zugänge am Projektende ohne Stress?

Am Projektende hilft keine große Einmallösung, sondern eine feste Reihenfolge. Für kleine Agenturen ist meist dieses Muster am saubersten: erst Besitz oder Admin-Rechte an den Kunden übergeben, dann alte Zugriffe entfernen, danach wichtige geheime Werte neu setzen.

Der erste Schritt ist die offizielle Übergabe. Bei GitHub ist ein Repository-Transfer oft sauberer als das Weiterreichen einzelner Zugangsdaten. Dabei wandern zentrale Projektinhalte mit. Wichtig ist aber der Haken: Auch Secrets und Deploy Keys bleiben laut GitHub mit dem Repository verknüpft. Ein Transfer allein beendet also nicht automatisch alle Altlasten.

Danach folgt der zweite Schritt: alte Rechte wirklich entziehen. Genau das wird im Alltag oft vergessen. GitHub beschreibt klar, dass sich externe Mitwirkende wieder aus einzelnen Repositories oder aus allen Repositories einer Organisation entfernen lassen. Für Projektordner gilt eine ähnliche Logik in Google Workspace: Admins können Mitglieder in Shared Drives entfernen oder ihre Rolle absenken. Wer entfernt wird, verliert damit auch den Zugriff auf die Inhalte im Shared Drive. Das ist für Kundenübergaben oft deutlich sauberer als verstreute Einzelfreigaben.

Beim Offboarding von Personen ist die Reihenfolge ebenfalls wichtig. Microsoft empfiehlt, den Sign-in zuerst zu blockieren und danach Daten wie E-Mails oder OneDrive-Inhalte an die nächste zuständige Person zu übergeben. Für kleine Teams ist das eine gute Grundregel: erst Zugang stoppen, dann Inhalte geordnet weiterreichen.

Der dritte Schritt betrifft alles, was über ein normales Passwort hinausgeht: API-Schlüssel, Tokens und Deploy Keys. Hier ist Vorsicht sinnvoll. Wenn solche Secrets schon im Einsatz waren, mit mehreren Personen geteilt wurden oder in lokalen Kopien gelandet sein könnten, solltest du sie nach der Übergabe gezielt erneuern. Das ist keine starre Herstellervorgabe, sondern eine naheliegende Sicherheitsfolge aus zwei Punkten: GitHub lässt Secrets und Deploy Keys beim Transfer bestehen, und entzogene Zugriffe löschen keine bereits vorhandenen lokalen Kopien.

Die praktische Faustregel lautet deshalb: Übergabe, Entzug, Rotation. So vermeidest du, dass der Kunde zwar formal Eigentümer ist, alte Agenturzugriffe aber noch offen bleiben oder technische Schlüssel unnötig weiterleben.

Was B2B-Teams daraus ableiten sollten

Der Schluss soll die einfache Faustregel verdichten und dem Leser einen klaren Startpunkt geben: erst Passwortmanager, dann Secret-Tool bei Bedarf, dann 2FA-Ordnung und am Ende ein sauberer Übergabeprozess.

• Welcher Passwortmanager ist für eine kleine Agentur ein guter Start? Einfach nach Teamarbeit, getrennten Bereichen, Rechten und Übergabe erklären; 1Password und Bitwarden als Beispiele einordnen.
• Was gehört in den Passwortmanager und was nicht? Normale Logins von technischen Geheimnissen wie API-Schlüsseln trennen.
• Brauchen wir für API-Schlüssel ein extra Tool? Erklären, wann ein Secret-Manager sinnvoll ist und wann eine einfachere Lösung reicht.
• Wie teilen wir einen gemeinsamen Kundenlogin mit 2FA, ohne Codes herumzuschicken? Zwei Wege zeigen: integriert im Passwortmanager oder getrennt in einer Authenticator-App.
• Wie trennt man interne Zugänge und Kundenzugänge sauber? Mit getrennten Bereichen, Gruppen und wenigen Rechten erklären.

Quellenlage und offene Punkte

Die Einordnung stuetzt sich auf 8 Quellen. Besonders wichtig ist, dass die wichtigsten Themenbereiche jeweils mit eigener Quellenbasis und nachvollziehbarer Zuordnung behandelt werden.

• Viele Quellen sind offizielle Herstellerdokumentationen und daher stark für Produktfunktionen, aber schwächer für neutrale Praxistests.
• Einige Preis- und Planangaben sind veränderlich und sollten vor Publikation frisch geprüft werden.
• Der Secret-Handling-Abschnitt ist funktional gut belegt, aber weniger mit unabhängigen Kleinagentur-Beispielen unterfüttert.
• GitHub-, Google- und Microsoft-Quellen belegen Übergabe- und Offboarding-Schritte gut, aber nicht jede Spezialsoftware für Kundenzugänge.
• Eine neutrale, kleine-Agentur-nahe Vergleichsquelle zu Passwortmanagern mit gleicher Quellentiefe fehlt.