Ein Remote-Team teilt vertrauliche Informationen so, wie es alles andere teilt: im Chat, über Zeitzonen hinweg, oft vom Küchentisch aus auf einem Laptop, auf dem auch der Streamingdienst der Familie läuft. Früher beugte man sich im Büro zum Kollegen hinüber und las ein Passwort vom Bildschirm ab. Heute fügt man es in eine Direktnachricht ein, und die Direktnachricht bleibt für immer.
Sicheres Teilen von Geheimnissen in Remote-Teams braucht kein großes Programm. Es braucht eine Bestandsaufnahme, eine Regel für die Wahl des Tools, eine kurze Richtlinie, die man sich merken kann, das Tool dort, wo das Team ohnehin arbeitet, und einen Plan für die zwei Momente, in denen die meisten Lecks entstehen: Abgänge und Fehler. So sieht das in fünf Schritten aus.
Schritt 1: Wissen, was Sie schützen
Nehmen Sie sich eine Stunde und listen Sie auf, mit welchen vertraulichen Informationen das Team umgeht und wo jede davon heute liegt. Die meisten Teams finden dasselbe:
- Gemeinsame Logins für SaaS-Tools, die weder SSO noch Konten pro Person unterstützen.
- API-Schlüssel und Tokens für Zahlungs-, E-Mail-, Cloud- und Analyseanbieter.
- Zugangsdaten für die Infrastruktur: Datenbankpasswörter, SSH-Schlüssel, Deploy-Schlüssel, Signaturschlüssel, Zertifikate.
- Wiederherstellungscodes und MFA-Backups für die oben genannten Konten.
- Zugangsdaten von Kunden, die der Support für ein Ticket braucht.
Verfolgen Sie für jeden Eintrag den Weg von der Erstellung bis zu jeder Stelle, an der er gespeichert ist oder hingeschickt wurde. Die Liste aus Chatverläufen, privaten Notiz-Apps und Passwortspeichern im Browser ist das eigentliche Risikoregister, und sie ist länger, als irgendjemand erwartet.
Schritt 2: Eine Regel für die Wahl des Tools
Remote-Teams brauchen zwei Tools und eine einfache Regel, wann welches zum Einsatz kommt.
| Wenn die vertrauliche Information | Verwenden Sie | Weil |
|---|---|---|
| von mehreren Personen wiederholt genutzt wird | Einen Passwortmanager für Teams oder einen Secrets-Manager | Namentlicher Zugriff, Widerruf, Erneuerung, MFA für den Tresor |
| einmal an eine Person geht oder nur vorübergehend gilt | Einen Einmal-Link | Im Browser verschlüsselt, beim ersten Öffnen gelöscht, nichts bleibt in der Nachricht |
| von Code oder CI gelesen wird | Den Secret-Speicher der Plattform oder einen Secrets-Manager | Überhaupt keine Kopie bei einem Menschen |
Der Tresor ist die maßgebliche Ablage. Der Einmal-Link ist der Übertragungsweg für alles, was nicht in den Tresor passt: den Dienstleister, der nie Zugang zu Ihrem Tresor bekommt, die Zugangsdaten für den ersten Arbeitstag einer neuen Kollegin, das vorübergehende Admin-Passwort, das jemand genau jetzt braucht, um 2 Uhr nachts seiner Zeit. Der Leitfaden Secret-Links oder Passwortmanager behandelt die Grenzfälle.
Stellen Sie bei der Bewertung beider Tools vier Fragen: Wo findet die Verschlüsselung statt, wer kann den Klartext sehen, was wird protokolliert, und lässt sich der Zugriff widerrufen? Für Secret-Links von LinkPilot lauten die Antworten: in Ihrem Browser, niemand außer dem Empfänger, ein Audit-Verlauf mit Pro, und ja, solange der Link nicht geöffnet wurde. Der Leitfaden zur clientseitigen Verschlüsselung erklärt, was die Verschlüsselung im Browser schützt und was nicht.
Schritt 3: Eine Richtlinie mit drei Regeln schreiben
Wer allein zu ungewöhnlichen Zeiten arbeitet, liest keine langen Richtlinien. Drei Regeln decken den größten Teil des Risikos ab:
- Vertrauliche Informationen gehören nie in Chat, E-Mail, Tickets oder Dokumente. Auch nicht „vorübergehend“. Auch nicht mit anschließendem Löschen. Nutzen Sie den Tresor oder einen Einmal-Link.
- Jede Person bekommt ihren eigenen Login, wo das System es zulässt, mit den Rechten, die ihre Rolle braucht. Gemeinsame Logins liegen mit namentlichem Zugriff im Tresor, nie in einer angehefteten Nachricht.
- Jede Übergabe hat eine verantwortliche Person und ein Enddatum. Wer eine vertrauliche Information weitergibt, hält fest, wer sie bekommen hat, warum und wann der Zugriff endet, ohne den Wert selbst zu notieren.
Ergänzen Sie diese Regeln durch Multi-Faktor-Authentifizierung für den Tresor und für jedes Konto, das Geheimnisse erstellen oder öffnen kann, sowie durch Vorgaben für die Geräte: vollständige Festplattenverschlüsselung, eine Bildschirmsperre und keine vertraulichen Informationen in privaten Notiz-Apps oder in über den Browser synchronisierten Passwortspeichern.
Schritt 4: Das Tool dorthin bringen, wo das Team schon ist
Eine Richtlinie, für die man einen weiteren Tab öffnen muss, verliert gegen die Gewohnheit. Legen Sie den sicheren Weg in das Chat-Tool.
- Installieren Sie die LinkPilot-App für Slack.
/secretantwortet nur Ihnen, mit einem Einmal-Link, den Sie im Kanal posten.--ttl 1h,6h,24hoder7dlegt den Ablauf fest. Das ist wichtig, wenn der Empfänger gerade schläft. Die Verknüpfung „Send as secret link“ rettet ein Passwort, das jemand bereits eingefügt hat, und ersetzt es durch einen Link. - Machen Sie die Browsererweiterung des Tresors zum Standard, damit Nachschlagen weniger Aufwand macht als eine Frage im Chat.
- Automatisieren Sie dort, wo Code vertrauliche Informationen braucht. CI und Deployments holen sie direkt aus dem Secret-Speicher. So kopiert niemand im Entwicklungsteam je einen Produktionswert, um ihn irgendwo einzufügen.
Für eine Übergabe über Zeitzonen hinweg ist die Reihenfolge: Erstellen Sie den Link mit 24 Stunden Ablauf, schicken Sie ihn mit einer Zeile zum Zweck, schicken Sie Benutzernamen und Kontext in einer getrennten Nachricht und bitten Sie den Empfänger, den Zugriff zu bestätigen, sobald er online ist. Meldet der Link, dass er geöffnet wurde, bevor der Empfänger dazu kam, erneuern Sie die Zugangsdaten. Der Leitfaden zu Zugangsdaten zwischen Teams beschreibt den vollständigen Ablauf der Übergabe.
Schritt 5: Abgänge und Lecks einplanen
Die meisten Offenlegungen passieren in zwei Momenten: wenn jemand das Team verlässt und wenn jemandem ein Fehler unterläuft.
Abgänge. Führen Sie eine Checkliste: Entfernen Sie die Person aus dem Tresor und aus jedem System mit eigenem Konto, erneuern Sie alle gemeinsamen Zugangsdaten, die sie gesehen haben könnte, widerrufen Sie ihre API-Schlüssel und Sitzungen, und prüfen Sie, ob sie vertrauliche Informationen außerhalb des Tresors aufbewahrt hat. Arbeiten Sie die Liste noch am selben Tag ab, auch bei Dienstleistern, deren Auftrag stillschweigend endet.
Rollenwechsel. Ein Wechsel zwischen Teams ist eine Überprüfung, kein Neuanfang. Entziehen Sie den Zugriff auf die Tresor-Sammlungen des alten Teams und auf alles in der Produktion, womit die Person nichts mehr zu tun hat.
Lecks. Machen Sie das Melden einfach und schuldfrei. Wer einen Schlüssel in den falschen Kanal eingefügt hat, sollte das in einer Nachricht sagen können und wissen, was dann passiert: Die verantwortliche Person erneuert den Wert, aktualisiert die Jobs, die ihn nutzen, und prüft den Exportverlauf des Kanals. Schlimm ist nur das Leck, das niemand erwähnt.
Überwachung. Prüfen Sie das Zugriffsprotokoll des Tresors und die Audit-Verläufe der Secret-Links in einem Rhythmus, der zur Vertraulichkeit passt. Achten Sie auf Öffnungen zu ungewöhnlichen Zeiten, Zugriffe von unerwarteten Orten und Freigaben, zu denen keine dokumentierte Übergabe passt.
Fünf Schritte, zwei Tools, drei Regeln. Ein Remote-Team, das diese Dinge eingerichtet hat, teilt vertrauliche Informationen sicherer, als es die meisten Teams im Büro je getan haben, weil der Ablauf nicht davon abhängt, wer gerade in der Nähe sitzt.