Zugangsdaten wandern ständig von einem Team zum anderen. Das Plattform-Team gibt einem Produktteam einen Deploy-Schlüssel, der Support bekommt den Admin-Login für ein Lieferantenportal, die Buchhaltung reicht das Token für die Bank-API zur Integration an die Entwicklung weiter. Jede dieser Übergaben ist Routine, und genau dabei landen Zugangsdaten am häufigsten für immer in einem Slack-Thread.
Eine sichere Übergabe von Zugangsdaten zwischen Teams hängt weniger an einem cleveren Tool als an einer klaren Regel, welches von zwei Tools Sie nehmen, und an ein paar Gewohnheiten drumherum. Dieser Leitfaden beschreibt diese Regel und die Gewohnheiten: die Zugangsdaten beschränken, sie übergeben, ohne sie in eine Nachricht zu schreiben, eine verantwortliche Person benennen und sie rechtzeitig entfernen.
Die eine Entscheidung, auf die es ankommt: Tresor oder Einmal-Link
Alles andere ergibt sich daraus, wie das empfangende Team die Zugangsdaten nutzen wird.
| Das empfangende Team wird sie | Verwenden Sie | Warum |
|---|---|---|
| dauerhaft nutzen, mit mehreren Personen | Einen gemeinsamen Tresor in Ihrem Passwort- oder Secrets-Manager | Namentlicher Zugriff, Widerruf und Erneuerung an einer Stelle |
| einmal nutzen, oder eine Person braucht sie kurz | Einen Einmal-Link | Die Nachricht enthält nur einen Link, die Kopie wird beim ersten Öffnen gelöscht |
| aus Code oder CI heraus verwenden | Einen Secrets Manager mit Maschinenidentitäten | Kein Mensch sieht den Wert jemals |
Der Tresor ist die verbindliche Quelle. Wenn die Zugangsdaten über die Übergabe hinaus gebraucht werden, gehören sie in einen gemeinsamen Tresor, der dem empfangenden Team gehört und dem Mitglieder namentlich hinzugefügt werden. Die meisten Passwortmanager für Unternehmen und Tools wie Vault oder AWS Secrets Manager können das gut.
Der Einmal-Link ist für den Moment der Übergabe gedacht, wenn ein Tresor nicht passt: Der Empfänger hat keinen Zugang zu Ihrem Tresor, die Zugangsdaten sind nur vorübergehend, oder Sie müssen einer Person sofort einen Wert geben. Die vertrauliche Information wird in Ihrem Browser verschlüsselt, die gespeicherte Kopie wird beim ersten Öffnen des Links gelöscht, und der Link selbst läuft ab, wenn ihn bis dahin niemand geöffnet hat. Secret-Links oder Passwortmanager geht die Sonderfälle durch.
Niemals per E-Mail, Chat, in geteilten Dokumenten oder Tickets. Sie alle behalten Kopien, sie alle synchronisieren auf Geräte, die Sie nicht kontrollieren, und sie alle lassen sich von der nächsten Person durchsuchen, die sich Zugang zum Konto verschafft.
Beschränken Sie die Zugangsdaten, bevor sie weitergegeben werden
Ein guter Kanal macht zu weit reichende Zugangsdaten nicht wieder gut.
- Legen Sie ein eigenes Konto für das empfangende Team oder die Person an, statt eines zu verleihen, das an eine einzelne Person gebunden ist. Geteilte Identitäten lassen sich weder prüfen noch sauber entfernen.
- Vergeben Sie die Rechte, die die Aufgabe braucht. Ein Team, das Berichte liest, braucht keinen Schreibzugriff. Ein Team, das deployt, braucht keinen Zugriff auf die Abrechnung.
- Erneuern Sie zuerst, wenn der Wert schon herumgereicht wurde. Wenn der bestehende Schlüssel an verschiedenen Stellen eingefügt wurde, erstellen Sie für die Übergabe einen neuen, statt den alten noch weiter zu verbreiten.
- Durchsuchen Sie das Material rund um die Aufgabe. Tickets, Runbooks, Beispielkonfigurationen und Skripte, die an der Aufgabe hängen, enthalten oft genau die Zugangsdaten, die Sie gleich übergeben wollen. Entfernen Sie sie vor der Übergabe, sonst ist die Übergabe Ihr kleinstes Risiko.
Die Übergabe selbst
- Prüfen Sie die empfangende Person über einen Kanal, dem Ihre Organisation bereits vertraut: das Ticket, eine bekannte Führungskraft, ein Videoanruf. Ähnlich aussehende Adressen und automatisch ergänzte Namen sind der übliche Weg, auf dem ein Geheimnis an die falsche Stelle gerät.
- Übergeben Sie über das gewählte Tool. Tresor: Fügen Sie die Person der gemeinsamen Sammlung hinzu. Link: Fügen Sie den Wert in das Tool für Einmal-Links ein, setzen Sie den Ablauf auf das tatsächliche Zeitfenster (eine Stunde, wenn die Person wartet, einen Tag über Zeitzonen hinweg), begrenzen Sie die Aufrufe auf einen, fügen Sie bei allem Sensiblen mit einem Pro-Konto eine Passphrase hinzu und senden Sie den Link.
- Schicken Sie den Kontext getrennt. Benutzername, Host und wofür die Zugangsdaten gelten, gehören in eine normale Nachricht, nie neben den Link. Gelangt eine einzelne Nachricht in falsche Hände, darf sie nie beide Hälften enthalten.
- Dokumentieren Sie die Übergabe in Ihrem verbindlichen System, ohne das Geheimnis: Empfänger, Zweck, System, verantwortliche Person, Enddatum.
- Lassen Sie sich den Zugang bestätigen, nicht den Wert. „Können Sie sich anmelden?“ ist die richtige Frage. „Schicken Sie mir den Schlüssel zur Kontrolle zurück“ ist es nicht.
Für Teams, die das oft machen, verwandelt die LinkPilot-App für Slack ein eingefügtes Passwort direkt im Kanal in einen Einmal-Link. So hängt die Gewohnheit nicht davon ab, dass alle daran denken, ein weiteres Tool zu öffnen.
Benennen Sie eine verantwortliche Person und prüfen Sie regelmäßig
Zugangsdaten ohne verantwortliche Person werden nie erneuert oder entfernt. Das empfangende Team sollte eine Person benennen, die für den Wert verantwortlich ist: wer ihn hat, wer ihn sonst noch braucht und wann er wegfällt.
- Minimale Rechte nach Rolle, mit Rollen oder Gruppen, wo sie die Verwaltung vereinfachen, damit ein Abgang nicht einen Reset pro System bedeutet.
- Multi-Faktor-Authentifizierung für den Tresor, denn jetzt lohnt sich ein Angriff auf den Tresor.
- Ein Prüfrhythmus, der zur Sensibilität passt: vierteljährlich für die meisten geteilten Zugangsdaten, bei jedem Teamwechsel für Produktionszugänge.
- Prüfen Sie die Übergaben. Ein Tresor zeigt, wer worauf zugegriffen hat. Ein LinkPilot-Konto im Pro-Tarif zeigt für jeden Secret-Link einen Audit-Verlauf. So sehen Sie, wann ein Einmal-Link geöffnet wurde, und können das mit der Bestätigung der empfangenden Person abgleichen.
Ablauf, Erneuerung und Offenlegung
Legen Sie das Ende der Zugangsdaten fest, bevor sie überhaupt in Gebrauch sind.
- Vorübergehender Zugang endet am vereinbarten Datum. Entfernen Sie das Konto oder die Tresor-Mitgliedschaft und widerrufen Sie jeden Einmal-Link, der nie geöffnet wurde.
- Die Erneuerung richtet sich nach dem Risiko, nicht nur nach dem Kalender: nach einem Abgang, nach einem Wechsel des Dienstleisters, nach jedem Verdacht auf Offenlegung und nach Plan bei allem, was lange in Gebrauch ist.
- Ein vermutetes Leck ist ein Leck, bis das Gegenteil bewiesen ist. Erneuern Sie die Zugangsdaten in dem System, das sie akzeptiert, informieren Sie die verantwortliche Person und aktualisieren Sie die Jobs und Dienste, die vom alten Wert abhingen. Der Leitfaden zu API-Schlüsseln enthält eine Checkliste zur Erneuerung, die für die meisten Arten von Zugangsdaten gilt.
Zwei Tools, eine Regel für die Wahl zwischen ihnen und eine verantwortliche Person für jeden Wert. Das ist das ganze System, und es trägt bei weit mehr Übergaben als jedes Richtliniendokument, das irgendwann niemand mehr liest.