Ein externer Dienstleister, der einen Import reparieren, eine Abfrage optimieren oder eine Tabelle migrieren soll, braucht dafür meist einen Datenbank-Login. Das Risiko ist selten die Person selbst. Es ist der Login: in Eile angelegt, mit mehr Rechten als nötig, in eine E-Mail kopiert und sechs Monate nach Bezahlung der Rechnung immer noch gültig.
Die Lösung ist eine kurze Routine. Klären Sie, ob direkter Zugriff überhaupt nötig ist, legen Sie einen Benutzer an, der eingeschränkt ist und schon ein Enddatum hat, schicken Sie das Passwort über einen Einmal-Link statt über eine Nachricht, die Kopien hinterlässt, sichern Sie den Netzwerkweg ab und schließen Sie das Konto, wenn die Arbeit erledigt ist. Dieser Leitfaden geht jeden Schritt durch, mit den genauen Befehlen, wo sie helfen.
Braucht der externe Dienstleister direkten Zugriff auf die Datenbank?
Beginnen Sie bei der Aufgabe, nicht bei der Anfrage. „Den Import reparieren“ kann heißen, eine einzige Tabelle zu lesen, oder Schreibzugriff auf das halbe Schema. Fragen Sie nach der Operation, der Umgebung und den betroffenen Tabellen, und suchen Sie dann nach einem günstigeren Weg, genau das zu ermöglichen.
- Eine Staging-Datenbank mit einer aktuellen, bereinigten Kopie deckt die meisten Diagnose- und Migrationsarbeiten ab, ohne echte Kundendaten offenzulegen.
- Eine Anwendungs- oder Admin-API reicht oft, wenn Daten geändert werden müssen und nicht das Schema.
- Eine Read Replica gibt reinen Leseanalysen einen Ort, an dem sie laufen können, ohne die primäre Datenbank zu berühren.
Passt nichts davon und ist Zugriff auf die Produktion unvermeidbar, schreiben Sie in einem Satz auf, warum. Diese Notiz ist die Begründung, wenn jemand den Zugriff später prüft.
Legen Sie einen Benutzer an, der eingeschränkt ist und schon abläuft
Geben Sie nie einen gemeinsam genutzten Login oder die Zugangsdaten von Beschäftigten weiter. Erst ein eigener Benutzer macht sichtbar, was der Dienstleister getan hat, begrenzt, was er erreichen kann, und lässt sich entfernen, ohne andere zu beeinträchtigen. Legen Sie den Ablauf schon beim Anlegen des Benutzers fest, dann endet der Zugriff auch, wenn Sie es vergessen.
In PostgreSQL sieht ein Benutzer, der nur zwei Tabellen lesen darf und an einem festen Datum aufhört zu funktionieren, so aus:
CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;
MySQL hat CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY, und verwaltete Dienste wie RDS, Cloud SQL und Supabase erlauben dasselbe über ihre Konsolen oder mit kurzlebigen Tokens auf IAM-Basis. Nutzen Sie, was Ihre Plattform unterstützt, und erzeugen Sie das Passwort mit einem Passwortmanager, statt selbst eines einzutippen.
Vergeben Sie die kleinste Menge an Rechten, mit der sich die benannte Aufgabe erledigen lässt. Für eine Diagnose heißt das SELECT auf bestimmte Tabellen. Für eine Migration heißt es Schreibzugriff auf die Objekte, die sich ändern, und auf nichts sonst. Owner- und Superuser-Rollen sind für ein temporäres Konto nie die richtige Antwort.
So senden Sie einen temporären Datenbank-Login sicher an einen externen Dienstleister
Das Passwort ist der einzige Teil der Übergabe, der geheim bleiben muss. Host, Port, Datenbankname und Benutzername sind für Angreifer nützlich, aber nicht ausreichend. Sie dürfen deshalb in einer normalen Nachricht reisen. Halten Sie beides getrennt.
- Prüfen Sie die Identität des Empfängers über einen Kanal, dem Sie bereits vertrauen, etwa den E-Mail-Verlauf zum Vertrag oder einen Anruf. Zum Verwechseln ähnliche Adressen sind ein häufiger Grund, warum Zugangsdaten im falschen Postfach landen.
- Erstellen Sie einen One-Time-Secret-Link, der nur das Passwort enthält. Bei LinkPilot wird der Text in Ihrem Browser verschlüsselt, bevor er gespeichert wird. Die gespeicherte Kopie wird beim ersten Öffnen des Links gelöscht, und Sie können als Ablauf eine Stunde, 24 Stunden oder sieben Tage wählen. Pro-Konten können einen eigenen Ablauf festlegen, eine Passphrase hinzufügen und in einem Audit-Verlauf sehen, wann der Link geöffnet wurde.
- Schicken Sie den Link im bestehenden E-Mail-Verlauf, mit einer kurzen Notiz, wofür er ist und wann er abläuft. Schreiben Sie den Benutzernamen nicht in dieselbe Nachricht wie den Link.
- Schicken Sie die Verbindungsdaten getrennt: Host, Port, Datenbank, Benutzername und ob TLS erforderlich ist. Eine zweite E-Mail oder ein Ticketkommentar ist in Ordnung, denn nichts davon ist für sich allein geheim.
- Geben Sie eine Passphrase über einen anderen Kanal weiter, falls Sie eine festgelegt haben, etwa per SMS oder am Telefon.
- Lassen Sie sich bestätigen, dass sich der Link öffnen ließ. Meldet er, dass er schon angesehen wurde, obwohl der Dienstleister ihn nicht geöffnet hat, gilt das Passwort als offengelegt und wird erneuert.
Die Teilen-Funktion eines Passwortmanagers ist eine vernünftige Alternative, wenn der Dienstleister schon Zugang zu Ihrem Tresor hat. Bei einem einmaligen Auftrag erspart ein Einmal-Link, nur für die Übergabe eines einzigen Werts ein Konto anzulegen. Der Leitfaden Secret-Links oder Passwortmanager beschreibt, wann was passt.
Sichern Sie die Verbindung ab
Ein gut eingeschränkter Benutzer auf einem offenen Port bleibt ein Problem. Drei Maßnahmen schließen den größten Teil der Lücke.
- Verlangen Sie TLS für die Verbindung und sagen Sie dem Dienstleister, dass er in seinem Client
sslmode=requireoder die entsprechende Einstellung setzen soll. Viele Clients fallen stillschweigend auf Klartext zurück, wenn Sie nicht darauf bestehen. - Beschränken Sie die Herkunft mit einer IP-Allowlist, einem VPN oder einem Bastion Host. Die Adresse des Dienstleisters für die Dauer der Arbeit freizuschalten, ist schnell eingerichtet und schnell wieder entfernt.
- Teilen Sie nur, was die Aufgabe braucht. Der Dienstleister braucht weder den Plan des internen Netzwerks noch die anderen Datenbanken auf dem Server noch die URL der Admin-Konsole.
Bietet Ihre Plattform kurzlebige IAM-Tokens statt statischer Passwörter, ist das meist die bessere Wahl. Die Übergabe eines Passworts entfällt damit ganz.
Behalten Sie das Konto im Blick und schließen Sie es
Schalten Sie für den neuen Benutzer das Protokollieren von Anmeldungen und Abfragen ein, bevor die Arbeit beginnt. So können Sie vergleichen, was passiert ist und was vereinbart war. Anmeldungen zu ungewöhnlichen Zeiten oder Abfragen auf fremden Tabellen sind eine Nachfrage wert, keinen Vorwurf.
Wenn die Aufgabe endet oder sich der Umfang ändert, erledigen Sie noch am selben Tag vier Dinge:
- Löschen oder deaktivieren Sie den Benutzer und prüfen Sie, dass er sich nicht mehr verbinden kann.
- Entfernen Sie die Netzwerkfreigabe, die Sie für den Dienstleister eingerichtet haben.
- Erneuern Sie jedes Geheimnis, das zusammen mit dem Login verschickt wurde, etwa ein Anwendungspasswort, das im selben Ticket stand.
- Dokumentieren Sie die Übergabe: wer Zugriff hatte, worauf, von wann bis wann und warum. Bewahren Sie die Aufzeichnung auf, nicht das Passwort.
Ein temporärer Login, der eingeschränkt ist, abläuft, einmal übergeben und pünktlich geschlossen wird, ist keine Ausnahme von den Sicherheitsregeln. So sollte der Zugriff von Externen schlicht funktionieren.