Case-Study: Secrets- & Password-Management

Die Digio hat im Rahmen von periodischen Sicherheitsüberprüfungen in Kundensystemen Massnahmen umgesetzt, um die Sicherheit von Secrets und Passwörtern bei deren Aufbewahrung und Benutzung nochmals zu erhöhen.

Problematik

Secrets und Passwörter erlauben einer Applikation oder Person, sich gegen Dritt-Systemen zu authentifizieren und entsprechend für gewisse Aktionen und Befehle autorisiert zu werden. Somit ist es eminent wichtig, dass Secrets und Passwörter weder erraten noch geknackt werden können. Aus diesem Grund werden oft nur längere Secrets oder nur sehr starke Passwörter erlaubt. Diese Sicherheit ist zum einen nicht absolut und kann zum anderen durch falsche Benutzung und Aufbewahrung teils oder sogar vollständig ausgehebelt werden.

Secrets

Secrets sind meistens Keys, Tokens, Zertifikate und Passwörter, welche eine Applikation benötigt, um sich gegenüber Dritt-Systemen (z.B. Mail-, Log-, Backup-, Kreditkarten-, Buchhaltungs-, CRM-, ERP-Systemen) zu authentifizieren. Besitzt eine Person diese Secrets kann sie Aktionen und Befehle im Namen der berechtigten Applikation aber ohne deren Businesslogik/ACL¹⁾ ausführen. Solch ein Szenario führt nicht selten zu Datendiebstahl, Datenverlust oder Erpressung.

¹⁾ Eine ACL legt fest, in welchem Umfang einzelne Benutzer und Systemprozesse Zugriff auf bestimmte Objekte (wie Dienste, Dateien, Registriereinträge usw.) haben.

Passwörter

Zusammen mit einem Benutzernamen oder E-Mail-Adresse gewähren Passwörter einem Zugang zu Service-Provider. Kein Mensch kann sich jedoch all seine und durch die starken Anforderungen meist komplizierten Passwörter merken. Auch Eselsbrücken helfen bei zunehmender Anzahl Passwörter nicht. Identische Passwörter für verschiedene Systeme zu verwenden kommt aus sicherheitsrelevanten Aspekten ebenfalls nicht in Frage. Identity Providers (IdP), wie wir sie heute von Google, Apple, Microsoft, Facebook, Instagram und evtl. bald eID kennen, lösen die existierenden Probleme mittels Single Sign-On (SSO). Allerdings basiert SSO darauf, dass diese IdP vertrauenswürdig sind und Zugänge sowie Nutzungsinformationen nicht zu eigenen Zwecken (z.B. kommerziell) weiterverwenden.

Lösung

Unsere Analyse hat aufgezeigt, dass die Aufbewahrung und die Benutzung dieser schützenswerten Informationen vermehrt vernachlässigt wird und somit Türen für Cyberkriminalität öffnet. In einer Case-Study haben wir Lösungen ausgearbeitet, um diese Schwachstellen zu schliessen.

Secrets

Um Secrets vor Missbrauch zu schützen, muss dessen Aufbewahrung verschlüsselt und getrennt von der Applikation stattfinden. Die Applikation (als einziges) soll diese Secrets bei Bedarf über einen sicheren Kanal anfordern und benützen können, ohne diese lokal speichern zu müssen.

Um diese strengen Anforderungen gerecht zu werden, haben wir nach einiger Evaluation das Produkt Vault von HashiCorp ausgewählt. Dessen Sicherheitsmechanismen sind so ausgelegt, dass keine unbefugte Person/Instanz auf die schützenswerten Secrets zugreifen kann.

Secrets werden im Vault in einem stark verschlüsselten Tresor gespeichert, welcher bei jedem Neustart des Servers, mittels langen Unseal-Keys vorerst Mal für den Gebrauch entschlüsselt werden muss. Wird der Tresor entwendet oder kopiert, ist dieser ohne diese Unseal-Keys unbrauchbar. Mittels Policies und AppRoles können Zugriffe fein granular auf einzelne oder Gruppen von Secrets definiert und für bestimmte Tokens und bestimmte IPs/CIDRs erlaubt werden. Somit kann bei einem Diebstahl des Tokens nicht auf die Secrets zugegriffen werden.

Passwörter

Damit Passwörter weder erraten noch geknackt werden können, sollen diese möglichst kompliziert und zufällig gewählt werden. Um diese vielen sensitiven Passwörter sicher und verschlüsselt zu verwahren, existieren so genanten Passwort-Manager.

Wichtig bei einem Passwort-Manager ist, dass die Passwörter jeweils verschlüsselt gespeichert werden. Am besten auf einer Cloud des Passwortmanager-Anbieters, welcher viel Zeit und Ressourcen beim Schützen der Daten einsetzt. Bei diesem Modell soll der Anbieter selbst nicht auf die Daten zugreifen können, was eine Verschlüsselung vor dem Abspeichern verlangt. Vor der Benutzung eines Passworts aus dem Passwort-Manager muss eine Authentifizierung stattfinden.

Um diesen Anforderungen gerecht zu werden, haben wir uns für das Produkt 1Password entschieden. Nebst der vollständigen Erfüllung der sicherheitsrelevanten Anforderungen ermöglich 1Password auch die Kollaboration zwischen Teams und Mitarbeiter in einem Unternehmen in einem geschützten Umfeld.

Schlusswort

Die Sicherheit von Daten und Zugriffen wird eigentlich nie durch nur eine einzige Massnahme implementiert. Es ist die Summe der Massnahmen in einer Sicherheitsstrategie, welche eine reale und hohe Sicherheit bieten kann. In unserer Case-Study haben wir lediglich den Aspekt der Lagerung und der Benutzung von Secrets und Passwörter thematisiert. Passwortstärke, Zugriffskontrolle (Source, Zeit, Netz), Erneuerung, 2FA, etc. sind weitere Massnahmen um eine Sicherheitsstrategie zu verbessern.

Einfachheit und Bequemlichkeit darf im Bereich der Sicherheit kein primäres Ziel sein. Sehr oft bedeutet eine vereinfachte Authentifizierung, dass man auf Vertrauen statt auf architektonische Grundlagen setzt. Aus diesem Grund haben wir bei unserer Evaluation auf einen öffentlichen Identity-Provider verzichtet und speichern unsere Passwörter stark verschlüsselt in einer Cloud, wo sie vor Angriffen und Verlust geschützt werden.