Absicherung einer verteilten Plattform — Identitäts-, Geheimnis- und Schlüsselverwaltung

Ankur Singla

Dies ist der dritte Beitrag in einer Blogreihe, die verschiedene Aspekte dessen beleuchtet, was nötig war, um unseren SaaS-Dienst aufzubauen und zu betreiben:

1. Steuerungsebene für eine verteilte Kubernetes-PaaS
2. Globales Service Mesh für verteilte Anwendungen
3. Plattformsicherheit für verteilte Infrastruktur, Anwendungen und Daten
4. Anwendungs- und Netzwerksicherheit verteilter Cluster
5. Observability auf einer global verteilten Plattform
6. Betrieb und SRE einer global verteilten Plattform
7. Golang-Service-Framework für verteilte Microservices

Mein erster Blogbeitrag lieferte einige Hintergrundinformationen zu den Anforderungen, die uns dazu veranlassten, eine neue Plattform für verteilte Clouds zu entwickeln. Mithilfe dieser Plattform erstellen unsere Kunden eine komplexe und vielfältige Palette von Anwendungen – etwa für intelligente Fertigung, videobasierte Forensik im Bereich der öffentlichen Sicherheit, algorithmischen Handel und 5G-Netze von Telekommunikationsanbietern.

Da viele dieser Anwendungen geschäftskritisch sind, erwarten unsere Kunden von uns, dass wir nicht nur mehrschichtige Sicherheit bieten, sondern auch kontinuierliche Verbesserungen vornehmen können, um ihre verteilten Cluster zu schützen. Dieser Blogbeitrag befasst sich mit den Herausforderungen beim Schutz von Infrastruktur, Anwendungen und Daten über mehrere Cluster hinweg.

Kurz gesagt (Zusammenfassung)

1. Während weitgehend bekannt ist, wie Benutzern und Mitarbeitern ein sicherer Zugriff auf Anwendungen ermöglicht werden kann (das tun wir jeden Tag, wenn wir auf unsere Bankkonten oder geschäftlichen E-Mails zugreifen), ist dies beim Zugriff von Anwendung zu Anwendung oder von Anwendungen auf Daten nicht ganz so einfach, da am Verifizierungsprozess kein Mensch beteiligt ist.
2. Die Absicherung von Anwendungen und Daten in einer heterogenen Umgebung (Edge, mehrere Clouds und Netzwerk-PoPs) erforderte die Lösung eines mehrschichtigen Problems — Identität, Authentifizierung und Autorisierung, Geheimnisse und Schlüsselverwaltung
3. Obwohl für diese vier Probleme zahlreiche Einzellösungen verfügbar sind (z. B. verschiedene Dienste einzelner Cloud-Anbieter, Hashicorp Vault, SPIFFE/Spire usw.), gibt es keine integrierte Lösung, die Cloud-Anbieter übergreifend funktioniert oder all diese Dienste nahtlos und benutzerfreundlich miteinander kombiniert.
4. Da es unseren Entwickler- und DevOps-Teams an Fachwissen darüber mangelte, wie diese Komponenten zusammengeführt werden können, musste unser Plattformteam diese Funktionen als integrierte, benutzerfreundliche Lösung bereitstellen. Die sich ständig weiterentwickelnde Sicherheitslandschaft und neue Technologien erschweren es diesen Teams zusätzlich, da ihnen das erforderliche Fachwissen und die Kapazitäten fehlen, um mit all den Veränderungen Schritt zu halten.
5. Im Rahmen der Bereitstellung einer mehrschichtigen Plattformsicherheit entwickelten wir neue Softwarekomponenten, die drei kritische Probleme auf völlig neue Weise lösten: die sichere Initialisierung einer universellen Identität, bei der das Problem des unendlichen Regresses („Turtles all the way down“) nicht auftritt, Geheimnisse, die gespeichert und verteilt werden können, ohne dass eine Kompromittierung eines zentralen Tresors befürchtet werden muss (Goldminenproblem), sowie eine verteilte Schlüsselverwaltung, die den Schutz ruhender Daten erleichtert.

Hintergrund zum Sicherheitsproblem

Wie oben erläutert, ist die Problematik der Absicherung des Benutzerzugriffs auf Anwendungen (zum Beispiel des Zugriffs auf unsere Bankkonten oder E-Mails) hinlänglich bekannt. Die Absicherung des Zugriffs zwischen Anwendungen oder von Anwendungen auf Daten ist jedoch weniger einfach, da am Verifizierungsprozess kein Mensch beteiligt ist.

Damit eine Anwendung sicher auf eine andere Ressource zugreifen kann – beispielsweise auf Daten, die in einem Objektspeicher gespeichert sind, oder um einen API-Aufruf an eine andere Anwendung zu senden –, müssen die folgenden Schritte erfolgen:

1. Identität – der Anfordernde muss auf sichere Weise eine überprüfbare Identität erhalten, die beim Zugriff auf die benötigten Ressourcen zu Authentifizierungs- und Autorisierungszwecken verwendet werden kann. Außerdem müssen dem Anfordernden auf sichere Weise die erforderlichen Vertrauensanker bereitgestellt werden, mit denen die Identitäten der Kommunikationspartner überprüft werden können.
   
2. Authentifizierung — Beim Zugriff auf eine bestimmte Ressource müssen der Anfordernde und der Eigentümer der Ressource die Identität des jeweils anderen sicher überprüfen. Der Vorgang, bei dem die angegebene Identität eines Kommunikationspartners anhand der vorgelegten Identität überprüft wird, wird als Authentifizierung bezeichnet.
   
3. Autorisierung — sobald der Anfragende authentifiziert ist, wird der Vorgang, bei dem geprüft wird, ob er auf die Ressource zugreifen darf (oder nicht), als Autorisierung bezeichnet.

Im Rahmen des Authentifizierungsprozesses kann die anfragende Anwendung ihre Identität in Form eines PKI-Zertifikats, eines Geheimnisses (z. B. eines Passworts) oder eines Schlüssels nachweisen. Bei der Verwendung von Geheimnissen oder Schlüsseln zur Identifizierung müssen zwei Aspekte berücksichtigt werden:

• Geheimnisse und Schlüssel sollten nicht direkt im Code gespeichert werden, da dies einen leicht ausnutzbaren Angriffsvektor darstellt und kompromittierte Schlüssel erhebliche Probleme verursachen können.
• Wenn die Geheimnisse in einem externen Tresor gespeichert werden, welche Identität (in der Regel ein weiteres Geheimnis) sollte dann verwendet werden, um auf das Geheimnis zuzugreifen, und wie sichern wir diese Identität ab?

Die zuverlässige und reproduzierbare Durchführung dieser Sicherheitsvorgänge (für die Interaktion zwischen Anwendungen) ist eine komplexe Aufgabe. Dafür gibt es viele Gründe:

1. Anwendungen können problemlos geklont und als neue Instanzen gestartet werden (z. B. Microservices). Wie lässt sich jedem Klon eine eindeutige Identität zuweisen, die möglicherweise für forensische Analysen, Audits oder die Beobachtbarkeit erforderlich ist?
2. Die Identität einer Anwendung unterscheidet sich je nach Umgebung, in der sie ausgeführt wird. Beispielsweise handelt es sich in der Entwicklungs- und Produktionsumgebung um dieselbe Anwendung, sie benötigt jedoch in jeder Umgebung eine andere Identität.
3. Wie lässt sich Vertrauen darin schaffen, dass die Infrastruktur, in der die Anwendung gestartet wird, nicht unbemerkt die Identität oder Geheimnisse und Schlüssel stiehlt?
4. Wie lässt sich der zentrale Tresor vor Angriffen schützen und die Sicherheit aller darin gespeicherten Geheimnisse und Schlüssel gewährleisten?

Daher ist die Absicherung von Infrastruktur, Anwendungen und Daten in einer dynamischen Umgebung eine äußerst anspruchsvolle Aufgabe. Cloud-Anbieter haben sich dieser Herausforderung zwar gestellt und zahlreiche Werkzeuge zur Bewältigung dieser Probleme bereitgestellt, doch deren Integration und Wartung sind aus den folgenden Gründen nicht einfach:

• Komplexität – Jeder Cloud-Anbieter verlangt vom Kunden, mehrere Dienste zu konfigurieren und zu verwalten. Dazu gehören beispielsweise bei AWS der Metadatendienst, IAM-Rollen, Dienstkonten, RBAC, KMS und Secrets Manager. Diese Dienste unterscheiden sich je nach Cloud-Anbieter erheblich – sowohl hinsichtlich ihrer Semantik und APIs als auch ihrer Überwachung.
  
• Interoperabilität — Selbst wenn die Dienste des Cloud-Anbieters konfiguriert und in Betrieb genommen wurden, ermöglicht keiner von ihnen Interoperabilität. Beispielsweise kann eine in GCP ausgeführte VM nicht auf eine Ressource in AWS zugreifen, da die über das GCP-Dienstkonto zugewiesene Identität von einer AWS-Ressource nicht erkannt wird.
  
• Heterogene Umgebungen — Wenn sich die Umgebung über öffentliche und private Clouds, mehrere öffentliche Clouds oder – noch schlimmer – Edge-Standorte erstreckt, stellt sich die Frage, wie und wo vertrauliche Daten wie Passwörter, Schlüssel usw. gespeichert werden sollen – zentral oder dezentral.
  
• Umgebungsspezifisch — Die Lösung für die Rotation und/oder den Widerruf von Anmeldedaten unterscheidet sich je nach Cloud-Anbieter erheblich, während für Edge-Cluster keine entsprechende Lösung existiert.

Während viele Unternehmen ausschließlich auf einen einzigen Cloud-Anbieter setzen und es für sie möglicherweise ausreicht, Ressourcen in die Verwaltung und Verbesserung der Sicherheitsmechanismen dieses Anbieters zu investieren, arbeiten wir in einer heterogenen Umgebung (Hybrid-Cloud und Edge) und mussten eine neue Lösung entwickeln, um diese Probleme zu lösen.

Lösung zur Absicherung einer verteilten Plattform

Unser Team wurde damit beauftragt, die Sicherheit der Anwendungen, Infrastruktur und Daten zu gewährleisten, die sich über eine verteilte Infrastruktur erstrecken können, wie in Abbildung 1 dargestellt.

Abbildung 1: Absicherung einer verteilten Plattform – Identitäts-, Geheimnis- und Schlüsselverwaltung

Daher beschloss unser Plattformteam, neue Softwaredienste zu entwickeln, die die folgenden vier Aspekte integrieren, um die Plattformsicherheit am Edge, in jeder Cloud und an unseren Netzwerk-PoPs zu gewährleisten:

1. Identitätsmanagement — wir beschreiben, wie wir nicht nur Anwendungen, sondern auch der Infrastruktur, die über eine heterogene Umgebung verteilt ist (mehrere Clouds, unsere globalen PoPs und geografisch verteilte Edge-Standorte) und in mehreren Umgebungen betrieben wird (z. B. Entwicklungsrechner, Komponententests, Produktion usw.), eine kryptografisch sichere und fälschungssichere PKI-basierte Identität bereitstellen.
   
2. Authentifizierung und Autorisierung — unsere Infrastruktur basiert auf Microservices, die eine PKI-basierte Identität verwenden und sämtliche Kommunikation unabhängig vom verwendeten Kommunikationsprotokoll gegenseitig authentifizieren. Darüber hinaus haben wir die Autorisierung von der Authentifizierung entkoppelt, sodass eine gemeinsame Autorisierungs-Engine für verschiedene Autorisierungsentscheidungen verwendet und die Richtlinienstruktur vereinheitlicht werden kann.
   
3. System zur Verwaltung von Geheimnissen — es gibt viele Arten von Geheimnissen (wie TLS-Zertifikate, Passwörter, Token usw.), die von unserer Software sowie für Kunden-Workloads benötigt werden. Die einfachste Methode wäre die Verwendung eines zentralen Tresors gewesen, in dem alle Geheimnisse gespeichert werden. Dieser Ansatz hätte jedoch den Nachteil, dass bei einer Kompromittierung sämtliche Geheimnisse offengelegt würden. Wir beschreiben einen anderen, von uns implementierten Ansatz, mit dem wir durch den Verzicht auf ein gewisses Maß an Einfachheit ein höheres Sicherheitsniveau erreichen.
   
4. Schlüsselverwaltungssystem (KMS) — Datensicherheit ist für unser verteiltes System von entscheidender Bedeutung, und das Team musste ein KMS bereitstellen, das nahtlos über verschiedene Cloud-Anbieter hinweg funktioniert. Das KMS muss Schlüssel verwalten, versionieren und rotieren, die zur symmetrischen Ver- und Entschlüsselung ruhender Daten, für HMACs von CSRF-Tokens und zum digitalen Signieren von Binärdateien verwendet werden. Wir erläutern, wie wir mithilfe dieses KMS Funktionen für sicherheitskritische Vorgänge und mithilfe des Systems zur Verwaltung von Geheimnissen Funktionen für latenzkritische Vorgänge bereitstellen.

Fälschungssichere Identitäten für Infrastruktur und Anwendungen

Identität ist ein grundlegendes Thema, da sich viele Sicherheitsherausforderungen leichter bewältigen lassen, sobald das Identitätsproblem gelöst ist. Um dieses Problem zu lösen, müssen wir jedoch definieren, was wir unter Identität verstehen und wie sie zuverlässig vergeben werden kann. Kryptografie-Freaks interpretieren gern alles auf ihre eigene Weise, und die Definition von Identität bildet da keine Ausnahme:

Die einzigartige und vollständige Gesamtheit der fälschungssicheren und kryptografisch überprüfbaren Merkmale, die von einer vertrauenswürdigen Instanz über ein nicht delegiertes, sicheres Protokoll kryptografisch zertifiziert wurden und bestimmen, als was eine Person oder Sache bekannt ist oder angesehen wird.

Im Wesentlichen wird eine fälschungssichere und kryptografisch überprüfbare Identität benötigt, die sicher bereitgestellt wird. Die Ausstellung einer solchen Identität ist aus zwei Gründen schwierig: 1) Initialisierung der Identität und 2) Vertrauensanker

Im Zusammenhang mit Identitäten werden häufig einige Ansätze diskutiert – darunter SPIFFE und Hashicorp Vault. Wir möchten klarstellen, dass SPIFFE ein Namensschema ist, das in unserem System als Identitätsdokument (X.509-Zertifikat) verwendet werden könnte. Das Format eignet sich jedoch nicht für bestimmte Identitätsattribute, die Binärdaten enthalten. Vault kann zwar zur Ausstellung eines Identitätsdokuments verwendet werden, löst jedoch weder die Herausforderungen bei der initialen Einrichtung der Identität noch das Problem der Vertrauensbasis:

1. Initialisierung der Identität — im wirklichen Leben wird die Identität eines Menschen bei seiner Geburt durch die Geburtsurkunde festgestellt. Damit wird die Identität der Person logisch initialisiert, und anhand dieser Urkunde kann die Person weitere Identitätsnachweise wie einen Reisepass, einen Führerschein usw. ableiten bzw. beantragen. Analog dazu muss in der IT-Welt bei jedem Start einer Anwendung (oder eines Microservices) eine Identität initialisiert werden. Die Feststellung der Identität ist einer der ersten Schritte, die jeder ausgeführte Code durchführen muss, um mit anderen Diensten interagieren zu können. Da derselbe Anwendungscode zudem mehrfach und in unterschiedlichen Umgebungen ausgeführt werden kann (Entwickler-Laptop, Komponententest oder Produktion), muss bei jedem dieser Starts eine eigene initiale Identität eingerichtet werden.
2. Vertrauensanker — auch wenn die Ausstellung einer Bootstrap-Identität unkompliziert erscheinen mag, stellt sich die Frage, wer diese Identität bereitstellen darf. In der realen Welt beginnt die Bereitstellung einer Identität beispielsweise damit, dass das Krankenhaus bestätigt, dass ein Kind zu einem bestimmten Datum und einer bestimmten Uhrzeit von einer bestimmten Person geboren wurde. Dabei wird davon ausgegangen, dass das Krankenhaus den Geburtseintrag nach ordnungsgemäßer Prüfung ausstellt und dieser nicht gefälscht werden kann. Daher kann die Geburtsurkunde als maßgebliche Informationsquelle (oder Vertrauensanker) verwendet werden. Wenn eine Anwendung von einem Menschen oder durch automatisierten Code gestartet wird, muss es entsprechend einen Vertrauensanker geben, der die Identität der gestarteten Anwendung nachweisbar bestätigen kann. Anhand dieser Bestätigung kann anschließend ein Identitätsdokument für die Anwendung erstellt werden.

Wenn beispielsweise eine VM in AWS gestartet wird, erhält sie eine Bootstrap-Identität, wobei der Metadatendienst von AWS als Vertrauensanker fungiert. Das Identitätsdokument, das AWS mit seinem eigenen kryptografischen Schlüssel signiert, sieht in etwa so aus:

Die instanceId kann zwar die eindeutige Identität der gestarteten Anwendungsinstanz bezeichnen, muss jedoch mit einem allgemein bekannten Namen (myserver.acmecorp.com) verknüpft werden, den andere Anwendungen zur Kommunikation mit dieser bestimmten Instanz verwenden. Daher reicht selbst dieses AWS-Bootstrap-Identitätsdokument nicht aus. Es kann jedoch dazu verwendet werden, eine weitere Identität auszustellen, über die Anwendungen miteinander kommunizieren können.

Wie bereits erwähnt, war es für uns von entscheidender Bedeutung, eine Identität bereitzustellen, die es Anwendungen ermöglicht, über verschiedene Cloud-Anbieter und/oder Edge-Standorte hinweg zu kommunizieren und Informationen auszutauschen (Abbildung 2). Das bedeutete, dass wir ein System sowohl für das Bootstrapping von Identitäten als auch für den Vertrauensanker entwickeln mussten, das in all diesen Umgebungen funktioniert.

Abbildung 2: Kommunikation zwischen Cloud-Anbietern, Netzwerk-PoPs und Edge-Standorten

Da wir Kubernetes zur Verwaltung und Orchestrierung von Anwendungen (sowohl Microservices als auch VMs) verwenden, musste das Bootstrapping einer eindeutigen Identität für jeden gestarteten Pod in den Pod-Erstellungsprozess von Kubernetes integriert werden. Abbildung 3 zeigt, wie wir uns mithilfe des K8s-Webhook-Mechanismus in den Pod-Erstellungsprozess einklinken. Dieser Webhook namens Voucher fügt allen im Cluster erstellten Pods einen Sicherheits-Sidecar namens Wingman hinzu und stellt außerdem die erforderlichen kryptografisch signierten Informationen bereit, die als Vertrauensanker verwendet werden können. Dieser Webhook stellt ein kurzlebiges signiertes Token bereit, mit dem Wingman ein X.509-Zertifikat von der Identity Authority im SaaS-Backend von Volterra anfordert.

Die Identity Authority setzt die Regeln für die Ausstellung der Identität so durch, dass der „Schadensradius“ minimiert wird, falls einer der K8s-Cluster kompromittiert wird. Viele andere Lösungen, die auf einer gemeinsamen Root-CA oder einem Verbund von K8s-Clustern basieren, können den Schadensradius nicht begrenzen. Dies war ein wesentlicher Faktor bei unserer Designentscheidung.

Abbildung 3: Vertrauensanker in jedem Kubernetes-Cluster

Bei einem bestimmten Pod in K8s können sich die Attribute nach der Erstellung des Pods ändern. Beispielsweise kann ein Pod nach seiner Erstellung einem neuen Service zugeordnet werden. Daher mussten die Identitätszertifikate um den neuen Service ergänzt werden. Wingman überwacht kontinuierlich den Voucher, der den K8s-API-Server auf derartige Aktualisierungen prüft.

Dieser Mechanismus verleiht jeder auf unserer Plattform ausgeführten Anwendungsinstanz eine eindeutige und universelle globale Identität – unabhängig davon, ob es sich um unsere eigene Workload oder die eines Kunden handelt. Diese eindeutige Identität und der Sidecar (Wingman) werden anschließend verwendet, um die gesamte Kommunikation sowie den Zugriff auf Schlüssel und Secrets in einem verteilten System abzusichern.

Authentifizierung und Autorisierung

Eine eindeutige Identität pro Pod ist ein hervorragender Ausgangspunkt, da sie die Implementierung einer gegenseitigen Authentifizierung zwischen kommunizierenden Diensten erleichtert. Unsere zugrunde liegende Infrastruktur besteht aus vielen verschiedenen Diensten, die unterschiedliche Protokolle wie gRPC, REST, IPSec, BGP usw. verwenden. Von Anfang an verfolgte das Team das Ziel, für alle miteinander kommunizierenden Parteien unabhängig vom jeweiligen Protokoll eine gegenseitige Authentifizierung und eine sichere Kommunikation (über einen verschlüsselten Kanal) zu gewährleisten. Das bedeutete auch, dass wir unsere Identität nicht an eine Lösung (z. B. Istio) binden konnten, die auf bestimmte Protokolle beschränkt ist (z. B. HTTP/TCP im Gegensatz zu IP-basierten Protokollen).

Da unsere Plattform es Kunden außerdem ermöglicht, Workloads ihrer Wahl auszuführen, gehen wir davon aus, dass diese Workloads eine Vielzahl von Protokollen verwenden können. Die Plattform sollte ihre Möglichkeiten daher nicht durch die Bereitstellung einer Identität einschränken, die auf bestimmte Protokolle beschränkt ist. Stattdessen ist die Authentifizierung von der Identität entkoppelt (über Wingman), wodurch sich verschiedene Service-Mesh-Technologien anbinden lassen. Unser Service-Mesh-Sidecar bzw. unsere Service-Mesh-Datenebene (in einem früheren Blogbeitrag behandelt) nutzt diese Identität, um mTLS für Kunden-Workloads bereitzustellen.

Da viele unserer eigenen Infrastrukturdienste mit dem Volterra Golang Service Framework entwickelt wurden (das in einem zukünftigen Blogbeitrag näher erläutert wird), haben wir beschlossen, die Logik zur Nutzung der von Wingman bereitgestellten Identität direkt in das Framework zu integrieren. Dadurch konnten unsere Entwickler die Kommunikation zwischen Diensten standardmäßig absichern, ohne für mTLS auf einen Service-Mesh-Sidecar angewiesen zu sein.

Der nächste logische Schritt nach dem Aufbau eines gegenseitig authentifizierten, sicheren Kanals ist die Autorisierung – ein Prozess, bei dem der Empfänger der Anfrage (Server) entscheidet, ob die Anfrage des identifizierten Aufrufers (Client) zugelassen wird. Es kann viele Gründe geben, eine Anfrage abzulehnen – etwa Kontingentbeschränkungen, Berechtigungen usw. Da sich diese Gründe und die zugehörigen Schwellenwerte dynamisch ändern, kam ein fest codierter Regelsatz (eine Richtlinie) für die Autorisierung auf unserer Plattform nicht infrage.

Wir entschieden uns, die Engine von Open Policy Agent als Ausgangspunkt zu verwenden, und entwickelten einen Wrapper für die Autorisierung innerhalb des Wingman-Sidecars. Dieser Wrapper-Code ruft die relevanten Richtlinien dynamisch ab und hält sie für eine schnelle Auswertung im Arbeitsspeicher bereit. Ähnlich wie bei der Authentifizierung ermöglicht uns die Entkopplung der Autorisierungs-Engine von der Identität (und der Authentifizierung), Autorisierungsrichtlinien in mehreren Phasen der Anfrageverarbeitung durchzusetzen – auch tief in der Geschäftslogik und nicht nur unmittelbar nach der Authentifizierung.

Da Wingman in alle Workloads eingebunden ist, einschließlich der Workloads unserer Kunden, stellt unsere Plattform eine integrierte Autorisierungs-Engine bereit. Obwohl Open Policy Agent (OPA) auf der leistungsfähigen Sprache Rego basiert, wollten wir deren Komplexität vor unseren Entwicklern und Kunden verbergen. Sämtliche Richtlinien auf unserer Plattform können auch mithilfe einer wesentlich leichter verständlichen und intuitiven Richtlinienstruktur definiert werden. Dadurch müssen die Benutzer (DevOps) Rego nicht erlernen und können Fehler vermeiden. Ähnlich wie bei der Authentifizierungskonfiguration wurde unser Golang Service Framework an die Autorisierungs-Engine von Wingman angebunden, indem es Wingman automatisch zur Autorisierung aufruft und so die Komplexität der Autorisierung vor den Entwicklern verbirgt.

Durch die Verwendung einer eindeutigen Identität (ausgestellt über Wingman) zur Authentifizierung und einer programmierbaren Policy-Engine (innerhalb von Wingman) zur Autorisierung können wir die Kommunikation mittels mTLS absichern und jeden Zugriff anhand einer robusten und programmierbaren Richtlinie steuern.

Geheimnisverwaltung ohne zentralen Tresor

Jeden Tag unterlaufen Entwicklern unbeabsichtigte Fehler, indem sie Schlüssel und Passwörter in ihrem Code speichern, die dann irgendwie in öffentlichen Code- oder Artefakt-Repositorys landen. Die Verwaltung von Geheimnissen ist schwierig, und ohne ein benutzerfreundliches Toolkit und einen klar definierten Prozess wählen Entwickler meist den Weg des geringsten Widerstands. Daher bestand die Aufgabe unseres Teams für Plattformsicherheit (im Unterschied zu Netzwerk- und Anwendungssicherheit) von Beginn des Unternehmens an darin, dafür zu sorgen, dass Entwickler sich nicht fragen müssen: „Wo speichere ich Geheimnisse – im Quellcode, in Artefakten oder …?“

Als wir mit der Entwicklung unserer Plattform begannen, prüften wir zwei gängige Ansätze für die Verwaltung von Geheimnissen, die uns damals zur Verfügung standen. Beide hatten jedoch gewisse Nachteile:

1. Kubernetes Secrets — Obwohl wir Kubernetes verwenden und es eine eigene Lösung für Secrets mitbringt, ist diese aus verschiedenen Gründen nicht besonders nützlich: Secrets werden im Ruhezustand nicht verschlüsselt, die Richtlinienmechanismen sind nicht umfassend und Multi-Cluster-Szenarien werden nicht unterstützt.
   
2. Zentralisierter Vault (z. B. Hashicorp oder Cyberark Vault) — Ein anderer Ansatz wäre die Verwendung eines Vaults gewesen, in dem die Secrets zentral gespeichert und an autorisierte Anfordernde ausgegeben werden. Die Secrets werden durch einen einzigen Verschlüsselungsschlüssel geschützt, der für die verschlüsselte Speicherung im Vault verwendet wird. Das Problem bei diesem Ansatz besteht jedoch darin, dass das Secret-Management-System Zugriff auf die Secrets im Klartext hat (selbst wenn sie verschlüsselt gespeichert sind) und eine Kompromittierung des Systems alle Secrets offenlegen könnte.

Da es sich in unserem Fall um einen SaaS-Dienst handelt, mussten wir eine robustere Methode zum Schutz der Geheimnisse unserer Kunden entwickeln, damit diese selbst im Falle einer Kompromittierung nicht offengelegt werden.

Daher haben wir uns für die Implementierung einer neuen Technik entschieden, die wir Volterra Blindfold (Markenzeichen) nennen und die, wie in Abbildung 4 dargestellt, mit unserem Sicherheits-Sidecar Wingman zusammenarbeitet. Mit diesem Ansatz kann der Eigentümer des Geheimnisses dieses so sperren (verschlüsseln), dass es keiner unbefugten Partei (einschließlich des Entschlüsselungsservers) jemals im Klartext offengelegt wird. Das Geheimnis wird nicht einmal auf einem zentralen Entschlüsselungsserver gespeichert, und dieses Konzept vereinfacht in mancher Hinsicht den Aufbau des Servers erheblich.

Abbildung 4: Blindfold und Wingman für die Verwaltung von Geheimnissen

Wir stellen Benutzern ein Blindfold-Tool zur Verfügung, mit dem das Geheimnis (S) vollständig offline verschlüsselt und anschließend verteilt werden kann. Beispielsweise kann das Geheimnis zusammen mit dem Workload gespeichert und in die Registry hochgeladen werden. Danach sind die folgenden Schritte erforderlich:

Dadurch wird sichergestellt, dass die zentrale Steuerungsebene niemals Zugriff auf das Geheimnis im Klartext (S) erhält und dass das Geheimnis nur für die Dauer des Zugriffs im Laufzeitspeicher des Pods verfügbar ist. Darüber hinaus kann mithilfe einer Zugriffsrichtlinie festgelegt werden, wer Zugriff auf ein Geheimnis erhält. Die Richtlinie kann anhand von Identitätsattributen wie Anwendungsname, Standort, Compliance-Stufe usw. definiert werden. Auf diese Weise lassen sich beliebig komplexe Teilmengen von Workloads abgrenzen und präzise Zugriffskontrollen umsetzen. Die Richtlinie ist kryptografisch in den Prozess der Verschlüsselung, Verblindung, Entschlüsselung und Aufhebung der Verblindung eingebunden – es ist rechnerisch nicht praktikabel, die Vorgaben der Richtlinie zu umgehen.

Mithilfe unserer einzigartigen Blindfold-Technik, mit der jedes Secret gesperrt wird, und Wingman, das jedes Secret auf Grundlage von Richtlinien und einer fälschungssicheren Identität entsperrt, können wir die Probleme bestehender Lösungen überwinden und eine Verwaltung von Secrets in einer verteilten Umgebung ermöglichen, ohne uns jemals Sorgen über eine Kompromittierung des zentralen Datenschatzes machen zu müssen.

Schlüsselverwaltung für verteilte Systeme

Obwohl Geheimnis- und Schlüsselverwaltung wie zwei unterschiedliche Bezeichnungen für dasselbe Problem klingen mögen, gibt es zwischen beiden subtile (in der Praxis jedoch wichtige) Unterschiede – je nachdem, wen man fragt und wie die Lösungen implementiert werden sollen.

Als Geheimnis werden alle Informationen bezeichnet, die vertraulich bleiben und Unbefugten nicht zugänglich sein sollen. Kryptografische Schlüssel sind gewissermaßen eine besondere Form von Geheimnissen. Schlüsselverwaltung hingegen bezeichnet im Allgemeinen ein System, das sensibles kryptografisches Schlüsselmaterial sicher speichert und dessen Verwendung kontrolliert. In manchen Fällen gibt das Schlüsselverwaltungssystem die Rohdaten des Schlüssels an autorisierte Parteien aus und kann daher mit einem System zur Verwaltung von Geheimnissen verwechselt werden. In den meisten Fällen gibt das Schlüsselverwaltungssystem die Rohdaten des Schlüsselmaterials jedoch nicht aus, sondern führt Operationen für autorisierte Anfragende durch und übermittelt lediglich deren Ergebnis. Viele Schlüsselverwaltungssysteme nutzen zudem Hardwarespeicher (z. B. HSM) für das Schlüsselmaterial, sodass der Schlüssel der Software gegenüber niemals im Klartext offengelegt wird.

In verteilten Umgebungen ist die Verwaltung, Synchronisierung und Rotation kryptografischer Schlüssel selbst bei nur einem Cloud-Anbieter äußerst anspruchsvoll, und die derzeitigen Lösungen sind fehleranfällig, ineffizient und sogar unsicher. Wenn man beispielsweise heute drei AWS-Regionen nutzt und in allen drei Regionen denselben kryptografischen Schlüssel verwenden möchte, müssen die Schlüssel manuell synchronisiert und rotiert werden. Noch schwieriger wird es, wenn sich die Umgebung über mehrere Cloud-Anbieter erstreckt (öffentliche und/oder private). Und selbst wenn all dies erledigt ist, müssen die Anwendungsverantwortlichen weiterhin komplexen Code schreiben, um diese KMS-Funktionen nutzen zu können.

Unsere Plattform verbirgt sämtliche Komplexität der Schlüsselverwaltung vor der Anwendung, indem der Wingman-Sidecar die gesamte aufwendige Arbeit übernimmt und der Anwendung einfache Schnittstellen für Schlüsselverwaltungsanfragen bereitstellt, darunter Verschlüsselung, Entschlüsselung, HMAC, HMAC-Verifizierung, digitale Signatur, Signaturprüfung, Schlüsselabruf (sofern zulässig) usw. Dadurch stellt die Schlüsselverwaltung weder für unsere eigenen Infrastrukturdienste noch für die Workloads unserer Kunden eine Herausforderung dar.

Das folgende Diagramm (Abbildung 5) zeigt, wie das KMS von Volterra umgebungsübergreifend funktioniert und Workloads dabei unterstützt, ihre Schlüsselverwaltung und kryptografischen Operationen an den Wingman-Sidecar auszulagern. Je nach Konfiguration kann Wingman Schlüssel zwischenspeichern und den Cache aktualisieren, ohne dass die Anwendung dies überhaupt bemerkt. Ermöglicht wird dies durch die zuvor vorgestellte universelle und fälschungssichere Identität. Da jeder Pod unabhängig von seinem Standort eine global eindeutige Identität erhält, kann das Volterra-KMS-System Zugriffsrichtlinien für kryptografische Schlüssel und bestimmte Operationen wie Verschlüsselung, Entschlüsselung, HMAC, HMAC-Verifizierung, digitale Signatur und Signaturverifizierung sehr präzise anwenden.

Abbildung 5: Wingman und KMS-Server in unserem SaaS-Backend

Da alle Schlüssel über das SaaS-Backend von Volterra verwaltet werden, müssen sich die in heterogenen Umgebungen ausgeführten Workloads nicht mit der Synchronisierung, Rotation oder dem Widerruf von Schlüsseln usw. befassen – sie müssen lediglich die einfachen Wingman-APIs kennen, um alle Sicherheitsanforderungen für ruhende Daten abzudecken.

Vorteile unserer Plattformsicherheitslösung

Durch den Einsatz einer mehrschichtigen Plattformsicherheit konnten wir auf völlig neue Weise eine umfassende Lösung für drei kritische Probleme bereitstellen! Unser System kann auf sichere Weise eine universelle Identität initialisieren, bei der das Problem „Schildkröten bis ganz nach unten“ nicht auftritt, Geheimnisse verwalten, die gespeichert und verteilt werden können, ohne dass dabei jemals das Goldminenproblem zu befürchten ist, und eine Schlüsselverwaltung bereitstellen, die den Schutz ruhender Daten in einer verteilten Umgebung erleichtert. Dies hat für unsere internen Teams und unsere Kunden zu folgenden Vorteilen geführt:

1. Sicherheit und Compliance — eine fälschungssichere und universelle Identität, Blindfold sowie ein Sicherheits-Sidecar (Wingman), das vollständig in die Plattform integriert und automatisch von ihr verwaltet wird, um die gesamte Kommunikation abzusichern, jeden Zugriff zu autorisieren und Schlüssel sowie Geheimnisse in einem verteilten System zu verwalten. Dank dieser Fortschritte können wir eine robustere Sicherheitslösung bereitstellen, die es uns und unseren Kunden erleichtert, Compliance-Anforderungen zu erfüllen.
   
2. Produktivitätssteigerungen — durch den Einsatz einer Sicherheitslösung, die in unseren DevOps-Prozess und unser Service-Framework integriert ist, können sich Entwickler und DevOps-Teams problemlos auf ihre Aufgaben konzentrieren, ohne sich um zentrale Aspekte der Anwendungs- und Datensicherheit sorgen zu müssen.
   
3. Kontinuierliche Weiterentwicklung — die sich wandelnde Sicherheitslandschaft und neue Technologien führen zu einer kontinuierlichen Weiterentwicklung von Blindfold, Wingman und unserem Golang Service Framework. Dadurch stellt die Plattform neue Funktionen automatisch bereit, ohne dass Änderungen an der Anwendungslogik erforderlich sind.

Fortsetzung folgt…

In dieser Blogreihe beleuchten wir verschiedene Aspekte der Entwicklung und des Betriebs unseres weltweit verteilten SaaS-Dienstes mit zahlreichen Anwendungsclustern in der Public Cloud sowie unseren privaten Netzwerk-PoPs und Edge-Standorten. Als Nächstes folgt Anwendungs- und Netzwerksicherheit…

Wir suchen einige freiwillige Entwickler und Lösungsarchitekten, die uns dabei unterstützen, diese Funktion als Open-Source-Projekt einer breiteren Community zugänglich zu machen. Wenn Sie Interesse haben, Teil eines spannenden Projekts zu werden, wenden Sie sich bitte direkt an asingla@volterra.io!

Über den Autor

Ankur Singla

Weitere Blogbeiträge von Ankur Singla