Zugänge sicher teilen: Einladungen statt Passwörter

Wer einen Dienstleister beauftragt, muss ihm irgendwann Zugang geben: zum Code, zur Website, zum Shop, zum Automatisierungswerkzeug. Erstaunlich oft geschieht das per E-Mail mit dem Satz „Hier die Zugangsdaten" und einem Passwort im Klartext. Das ist bequem, aber aus mehreren Gründen eine schlechte Idee.

Warum ein geteiltes Passwort ein Problem ist

• Es bleibt liegen. Die E-Mail liegt danach in mindestens zwei Postfächern, oft auch in Chatverläufen und Notizen, auf unbestimmte Zeit.
• Es ist nicht zuzuordnen. Wenn mehrere Personen dasselbe Konto nutzen, ist hinterher nicht nachvollziehbar, wer was geändert hat.
• Es lässt sich nicht gezielt entziehen. Um den Dienstleister auszuschließen, müssen Sie das Passwort für alle ändern.
• Es gibt zu viel frei. Das Hauptkonto hat meist volle Rechte, inklusive Abrechnung, Benutzerverwaltung und Löschen.
• Es umgeht die Zwei-Faktor-Authentifizierung, oder Sie müssen den zweiten Faktor ebenfalls weitergeben, was ihn wertlos macht.

Die bessere Lösung bieten fast alle gängigen Systeme bereits an: ein eigener Zugang für den Dienstleister, per Einladung, mit genau den Rechten, die er braucht.

Drei Grundregeln

1. Einladung statt Passwort. Der Dienstleister bekommt einen eigenen Benutzer, der an seine E-Mail-Adresse gebunden ist und mit seinem eigenen Passwort und Zweitfaktor geschützt wird.
2. So wenig Rechte wie möglich. Wer an einem Workflow arbeitet, braucht keinen Zugriff auf die Abrechnung. Wer eine Funktion programmiert, muss nicht in die Produktivdatenbank.
3. Kopie statt Original. Wo es geht, arbeitet der Dienstleister auf einer Staging-Umgebung, einem Branch oder einer Theme-Kopie, nicht im Live-System.

So geht es in den gängigen Systemen

System	Empfohlener Weg	Worauf achten
GitHub	Einladung als Collaborator bzw. in der Organisation mit Rolle „Write"	Branch-Schutz für main aktivieren, damit Änderungen nur per Pull Request kommen
GitLab	Projektmitglied mit Rolle „Developer"	Geschützte Branches; „Maintainer" nur bei Bedarf
Bitbucket	Benutzer mit Schreibrecht auf das Repository	Branch-Berechtigungen setzen
WordPress	Staging-Kopie anlegen, dort eigenen Benutzer anlegen	Live-Seite bleibt unberührt; Benutzer nach Abschluss löschen
Shopify	Mitarbeiter-Zugriffsanfrage (Collaborator) bestätigen	Nur benötigte Berechtigungen freigeben; Arbeit in einer Theme-Kopie
n8n	Benutzer in die Instanz einladen	Rolle ohne Instanz-Administration, wenn möglich
Make / Zapier	Einladung in Team oder Organisation (je nach Tarif)	Zugriff auf benötigte Verbindungen beschränken
Google Drive / OneDrive / SharePoint	Einen bestimmten Ordner mit der Person teilen	Nicht das ganze Laufwerk; nicht „Jeder mit dem Link"

Ein Wort zu Shopify

Shopify hat für Dienstleister ein eigenes Verfahren: Mitarbeiterkonten für Partner, sogenannte Collaborator-Konten. Der Dienstleister stellt aus seinem Partner-Konto eine Zugriffsanfrage, Sie als Inhaber bestätigen sie und wählen die Berechtigungen aus. Optional können Sie in den Einstellungen festlegen, dass Anfragen nur mit einem Code möglich sind, den Sie vorher weitergeben. Ein Passwort wird dabei nie geteilt, und der Zugriff lässt sich jederzeit einzeln entfernen.

Ein Wort zu WordPress

Viele Hoster bieten auf Knopfdruck eine Staging-Kopie Ihrer Website an. Auf dieser Kopie legen Sie unter „Benutzer → Neu hinzufügen" einen Benutzer für den Dienstleister an. Er arbeitet auf der Kopie, Sie prüfen das Ergebnis dort und übernehmen es danach auf die Live-Seite. Für Fehlersuchen bei Plugins ist das ohnehin der sicherere Weg, weil man auf der Live-Seite nicht gefahrlos Plugins deaktivieren kann.

Wenn es doch ein Geheimnis sein muss

Manche Zugänge lassen sich nicht per Einladung erteilen: ein FTP-Zugang beim Hoster, ein API-Schlüssel eines Drittanbieters, ein älteres System ohne Benutzerverwaltung. Dann gilt:

1. Eigenen Zugang anlegen, wenn das System das zulässt, etwa einen zusätzlichen FTP-Benutzer, beschränkt auf ein Verzeichnis, oder einen eigenen API-Schlüssel mit eingeschränkten Rechten.
2. Über einen ablaufenden Link teilen, nicht per E-Mail oder Chat. Dienste wie Bitwarden Send oder die Freigabefunktion von 1Password erzeugen einen Link, der nach einer festgelegten Zeit oder einer Anzahl von Aufrufen verfällt. Bei Bitwarden Send können Sie zusätzlich ein Passwort für den Link setzen und es auf einem anderen Weg mitteilen.
3. Nach Abschluss ändern oder löschen. Ein Schlüssel, der für eine Aufgabe erstellt wurde, wird danach widerrufen.

Was Sie nie tun sollten: Zugangsdaten in ein Ticket, in eine Aufgabenbeschreibung, in ein Repository oder in eine geteilte Tabelle schreiben. Diese Orte sind zum Lesen durch viele gedacht und werden selten aufgeräumt.

Zwei-Faktor-Authentifizierung als Pflicht

Ein eigener Benutzer für den Dienstleister ist nur so sicher wie dessen Anmeldung. Viele Systeme erlauben es, für alle Mitglieder eine Zwei-Faktor-Authentifizierung vorzuschreiben. GitHub-Organisationen haben dafür eine eigene Einstellung, ebenso Google Workspace und Microsoft 365. Wenn Sie diese Einstellung aktivieren, gilt sie für Ihr Team und für alle Externen.

Der umgekehrte Fall kommt ebenfalls vor: Ein System lässt nur einen Hauptbenutzer zu, dessen zweiter Faktor auf Ihrem Handy liegt. Dann ist eine Einladung schlicht nicht möglich. Statt den Code jedes Mal weiterzugeben, lohnt sich ein Blick, ob das System einen zusätzlichen Benutzer oder einen API-Zugang anbietet. Wenn nicht, ist das ein Punkt für die Liste der Systeme, die bei Gelegenheit ersetzt werden sollten.

Zugänge nach Abschluss entziehen

Der zweite Teil wird oft vergessen. Wenn die Aufgabe abgenommen ist, braucht der Dienstleister keinen Zugang mehr. Eine kurze Routine nach jeder abgeschlossenen Aufgabe:

• Benutzer im Repository, CMS, Shop oder Workflow-Werkzeug entfernen
• Freigabe des Cloud-Ordners aufheben
• Eigens erstellte API-Schlüssel oder FTP-Benutzer löschen
• Staging-Kopie löschen, falls sie nicht mehr gebraucht wird
• Prüfen, ob irgendwo doch ein Passwort geteilt wurde, und es ändern

Wer regelmäßig mit externen Dienstleistern arbeitet, sollte einmal im Quartal die Benutzerlisten seiner wichtigsten Systeme durchsehen. Alte Zugänge von Agenturen und Freelancern, mit denen seit Jahren niemand mehr spricht, sind ein typischer Fund.

Datenschutz nicht vergessen

Wenn der Dienstleister durch den Zugang personenbezogene Daten sehen kann, etwa Kundendaten im Shop oder im CRM, verarbeitet er diese Daten in Ihrem Auftrag. Dann brauchen Sie nach Art. 28 DSGVO einen Vertrag zur Auftragsverarbeitung, und zwar bevor der Zugang erteilt wird. Auch das spricht für eingeschränkte Rechte und Staging-Umgebungen mit Testdaten: Was der Dienstleister nicht sehen kann, muss auch nicht geregelt werden.

Eine kurze Checkliste vor der Freigabe

• Gibt es eine Einladungsfunktion? Dann diese nutzen.
• Welche Rolle ist die kleinste, mit der die Aufgabe erledigt werden kann?
• Gibt es eine Kopie oder Staging-Umgebung, auf der gearbeitet werden kann?
• Ist der Hauptzweig bzw. das Live-System vor direkten Änderungen geschützt?
• Sind personenbezogene Daten sichtbar, und ist dafür ein AV-Vertrag geschlossen?
• Wann und von wem wird der Zugang wieder entzogen?

Häufige Fragen

Warum sollte ich Dienstleistern kein Passwort schicken?

Ein geteiltes Passwort bleibt in Postfächern und Chats liegen, lässt sich keiner Person zuordnen und nur für alle gemeinsam entziehen. Zudem gibt das Hauptkonto meist volle Rechte frei und umgeht die Zwei-Faktor-Authentifizierung. Besser ist ein eigener Zugang per Einladung, mit genau den Rechten, die für die Aufgabe nötig sind.

Wie teile ich einen Zugang, wenn es keine Einladungsfunktion gibt?

Legen Sie nach Möglichkeit einen eigenen Zugang mit eingeschränkten Rechten an, etwa einen zusätzlichen FTP-Benutzer oder einen eigenen API-Schlüssel. Teilen Sie ihn über einen ablaufenden Link, zum Beispiel mit Bitwarden Send oder der Freigabefunktion von 1Password, nicht per E-Mail oder Chat. Nach Abschluss wird der Zugang geändert oder gelöscht.

Brauche ich einen AV-Vertrag, wenn ein Dienstleister Kundendaten sehen kann?

In der Regel ja: Kann der Dienstleister personenbezogene Daten sehen, verarbeitet er sie in Ihrem Auftrag, und Art. 28 DSGVO verlangt einen Vertrag zur Auftragsverarbeitung. Er sollte geschlossen sein, bevor der Zugang erteilt wird. Eingeschränkte Rechte und Staging-Umgebungen mit Testdaten verringern, was überhaupt geregelt werden muss.

---

Bei uns ist das fest geregelt. Im Prozess-Abo verbinden Sie Ihre Systeme einmal in Ihrem Workspace, indem Sie unser Konto einladen: bei GitHub, GitLab, Bitbucket oder Azure DevOps, in WordPress, Shopify, n8n, Make oder Zapier oder über einen geteilten Ordner. Für jede Plattform gibt es vorgegebene Schritte. Passwörter, API-Schlüssel oder Tokens nehmen wir nie entgegen. Wir arbeiten nie direkt im Produktivsystem, sondern auf einem Branch, einer Staging-Seite, einer Theme-Kopie oder in einem deaktivierten Workflow. Die Einladungen nutzen wir nur für die Arbeit an Ihren Karten. Sie können jede jederzeit selbst entziehen; nach dem Ende des Abos gehört das in die Routine oben. Wie das in der Praxis aussieht, zeigt Ihre erste Aufgabe, die wir kostenlos erledigen (eine pro Unternehmen). Welche Zugänge typische Aufgaben brauchen, steht im Leistungskatalog.