Wie wir Geheimnisse teilen

Es gibt viele Möglichkeiten, private Nachrichten und Geheimnisse sicher auszutauschen: PGP/GnuPG, S/MIME und verschiedene hausgemachte oder kommerzielle Lösungen.

In einer perfekten Welt würden sich alle unsere Partner (andere würden sie Kunden nennen, aber wir sehen unsere Beziehung anders) auf einen Standard einigen, wenn es um den Austausch sensibler Informationen geht. Einige haben sich auf S/MIME geeinigt, andere auf PGP, viele betreiben ihre eigenen webbasierten Tools und einige wenige haben gar kein Verfahren im Einsatz. Das macht es uns schwer, effizient und schnell auf sichere Weise zu kommunizieren.

Eine große Herausforderung in Bezug auf die Kommunikation für unsere Fakultäten CSM (Customer Success Management) und TAM (Technical Account Management) ist die Verteilung eines ersten Satzes von Anmeldedaten für unsere Produkt-APIs (z.B. Gini Pay). Zu diesem Zeitpunkt haben wir oft noch keine etablierten Kommunikationswege und wir wollen, dass unsere Partner schnell loslegen können, ohne ihre Anmeldedaten zu gefährden.

.        .        .

 

Wie wir angefangen haben (und ja, das mag Dich etwas schockieren)

Zu Beginn einer neuen Partnerschaft interagieren wir meist mit den Produktspezialisten unseres zukünftigen Partners, und Verschlüsselung ist in dieser Phase ein schwieriges Thema. Um diese Sackgasse zu überwinden, wählten wir ein Muster, das zumindest einige Vorteile im Vergleich zu Klartext-E-Mails bot: Die Aufteilung der Geheimnisse und die Verwendung von zwei Kommunikationskanälen.

Je nach Partner konnte dies eine beliebige Kombination aus E-Mail, SMS, Telefonat oder Fax bedeuten. Du hast richtig gelesen – Fax.

Wir waren dringend auf der Suche nach einer sicheren Lösung, die für alle Partnerstufen und Szenarien funktionieren würde.

Version 1 – burn after reading

Es begann als Nebenprojekt und wurde schnell zum Tool der Wahl für den geheimen Nachrichtenaustausch hier bei Gini: “burn after reading” oder zu deutsch, “nach dem Lesen verbrennen”.

Die Idee ist alt (sie wurde kürzlich in Gmails „Nachricht mit Ablaufdatum“-Funktion wiederverwendet) und funktioniert wie folgt:
Du generierst eine eindeutige URL, die Du Deinem Partner im Klartext (z. B. per E-Mail) schicken kannst.
Dein Partner kann die URL im eigenen Browser öffnen, aber nur einmal.
Nachdem der Link besucht wurde, ist die Nachricht „verbrannt“ und kann nicht mehr aufgerufen werden.

Der Prototyp war eine kleine TLS-geschützte Web-Applikation, die in Go gebaut wurde und von einem netten In-Memory-Schlüsselwertspeicher namens go-cache angetrieben wurde, der von Patrick Mylund Nielsen geschrieben wurde. Der k/v-Speicher bot einen automatischen Verfall von Elementen nach einer bestimmten Zeit und wir entfernten das Element aus dem Speicher, wenn der Partner es ansah. Wenn jemand die E-Mail abfing und die Anmeldedaten ansah, wussten wir das (das Geheimnis wäre weg) und konnten entsprechend handeln.

Das Nutzungserlebnis war schon sehr gut und eine große Verbesserung zu unserem bisherigen Verfahren, aber es hatte auch einige Nachteile:

• Geheimnisse werden im Speicher gehalten und ein erneutes Deployment oder ein Neustart des Servers löschte die Daten
• Die Daten wurden unverschlüsselt im Speicher abgelegt

Es war Zeit für eine Neuimplementierung mit einem größeren Fokus auf Sicherheit – und hier betritt Vault die Bühne.

Version 2 – powered by Vault

Zu dieser Zeit haben wir viel mit Vault von HashiCorp experimentiert, und wenn Du es noch nicht ausprobiert hast, solltest Du heute damit anfangen. Die Verwendung von Vault für unsere Neuimplementierung brachte uns auf Anhieb eine Reihe von Vorteilen:

• Die Daten sind nicht mehr an eine einzige Serverinstanz gebunden
• Sichere Persistenz für Nachrichten im k/v-Speicher
• Verhinderung des einfachen Ausprobierens von Geheimnissen mit HMAC
• Automatischer Ablauf der Token (und zugehörigen Nachrichten)
• Einrichtung von Hochverfügbarkeit und verbesserte Skalierbarkeit

Achtung! Wir werden jetzt einige Details der Vault-Integration behandeln. Wenn Du nicht mehr weiter weißt, besuch die hervorragende Vault-Dokumentation und -Anleitungen und vergiss nicht, wiederzukommen!

Wie Geheimnisse geboren werden und wie sie verschwinden:

Die Geburt eines Geheimnisses

• Wenn ein neues Geheimnis in der Weboberfläche hinzugefügt wird, erstellt der Server ein neues Vault-Token. Dieses Token hat eine Time To Live (TTL), die dafür sorgt, dass eine ungelesene Nachricht nach einer bestimmten Anzahl von Nutzungen automatisch gelöscht wird. Die TTL kann nach Bedarf eingestellt werden.
• Die Anzahl der Verwendungen ist immer 2 (1, um etwas in den Speicher zu schreiben + 1, um es später wieder abzurufen).
• Der eigentliche Satz von Anmeldeinformationen wird in das Cubbyhole Vault Backend geschrieben. Jeder Token hat sein eigenes Cubbyhole, und das macht es zum perfekten Backend für unsere Geheimnisse. Dies erzwingt eine klare Trennung der gespeicherten Geheimnisse – der Zugriff auf ein Token gefährdet nicht die anderen Geheimnisse.
• Zusätzliche Metadaten-Parameter werden in einem speziellen Bereich in einem gemeinsamen k/v-Backend gespeichert. Der Grund dafür ist, dass diese Parameter gelesen werden müssen, bevor das Geheimnis aus Cubbyhole geholt wird (z.B. ob eine akzeptierte GDPR-Erklärung erforderlich ist, bevor das Geheimnis offengelegt wird).
• Ein eindeutiger Link wird aus dem Token, gefolgt vom HMAC des Tokens, generiert und an den Partner verteilt.

Töte es mit Feuer

• Der Partner klickt auf den TLS-geschützten Link und der Server rendert eine HTML-Seite mit einer Enthüllungsschaltfläche.
• Wenn die Schaltfläche angeklickt wird, extrahiert der Server das Token und den HMAC aus der URL und verifiziert den HMAC. Er verwendet das Vault Transit-Backend, um den HMAC-Schlüssel zu speichern und die Verifizierung durchzuführen. Dies fügt dem Geheimnis eine zusätzliche Schutzebene hinzu.
• Sobald das Token validiert ist, wird es verwendet, um das Geheimnis aus Cubbyhole zu lesen. Der Token wird automatisch ungültig gemacht, da die Anzahl der Verwendungen nun erschöpft ist.
• Eine HTML-Seite wird gerendert und das Geheimnis wird dem Partner angezeigt.

Zeit für einige Screenshots

Dies ist der Eingabebildschirm in unserem internen Self-Service-Portal. Wir verwenden die Slack-Webhook-Integration, um benachrichtigt zu werden, wenn ein Geheimnis gelüftet wird.

 

Dies ist der Begrüßungsbildschirm, den der Partner sieht, wenn der Link geöffnet wird.

Zeit, das Geheimnis zu lüften.

Fazit

Es ist nur ein kleines Tool, das wir gebaut haben, um eine Herausforderung im B2B2C-Markt zu bewältigen, aber es hat sich für uns als sehr wertvoll erwiesen.

Wir haben Vault und „Burn after reading“ in unser internes Self-Service-Portal integriert und beide passen perfekt zueinander. Das Feedback von internen Nutzern und Partnern war bisher großartig und wir haben noch keinen Partner gefunden, der es nicht benutzen kann.

Vault erwies sich als sehr flexibel und machte es einfach, gute Sicherheitsprinzipien auf unsere Implementierung anzuwenden. Es ist beruhigend, Krypto-Operationen an ein Tool delegieren zu können, das speziell für diesen Zweck entwickelt wurde.

Schreib uns, wenn Du mehr über die technischen Details der Implementierung wissen möchtest oder wenn Du andere Fragen hast. Wir freuen uns, sie alle zu beantworten!

 

.        .        .

 

Wenn Du bis hierher gelesen hast, schau Dir unsere offenen Stellen an. Wir sind immer auf der Suche nach exzellenten Technikern, die sich uns anschließen möchten!