Authentifizierung und Zugriffskontrolle
Bevor wir uns ansehen, wie Sie mithilfe der von KMS verwalteten Schlüssel Daten verschlüsseln, ist es wichtig zu verstehen, wie Sie den Zugriff auf KMS sowie auf die verwendeten Schlüssel absichern. Den Zugriff auf die KMS Control Plane, also den Teil der API, der die Konfiguration oder das Auflisten von Schlüsseln beschreibt, kontrollieren Sie über AWS Identity and Access Management – kurz AWS IAM.

Darüber steuern Sie neben der Authentifizierung über IAM-Entitäten, also Benutzer oder Rollen, auch die Autorisierung über Policies, die an Entitäten angehängt sind. Über IAM-Regeln legen Sie fest, welche Berechtigungen einer Entität zugewiesen sind. So können Sie den Zugriff auf bestimmte Komponenten des KMS-Services verwalten. Im Listing 1 sehen Sie eine beispielhafte IAM-Policy, die dem Benutzer mehrere Berechtigungen auf den KMS-Dienst erteilt.

Mit dieser Richtlinie kann der Benutzer

• Verschlüsselungsschlüssel erstellen (kms:CreateKey)
• Schlüssel zum Ver- und Entschlüsseln nutzen (kms:Encrypt und kms:Decrypt)
• Von KMS verwaltete Schlüssel sowie ihre Attribute ansehen (kms:List* und kms:Get*)

Denken Sie daran, Berechtigungen immer nach dem Prinzip der am geringsten benötigten Rechte zu vergeben. So besteht die Möglichkeit, die Zugriffsrechte auf bestimmte API-Aufrufe sowie auf spezifische Ressourcen zu begrenzen. Wir empfehlen, mit einem Mindestsatz von Berechtigungen zu beginnen und zusätzliche nur sofern erforderlich zu gewähren. Dies ist sicherer, als mit Zugriffsmöglichkeiten zu beginnen, die zu weit gefasst sind, und dann später zu versuchen, diese zu begrenzen.

Richtlinien korrekt nutzen
Neben den IAM-Berechtigungen, die wir Identitäten, also Nutzern, Gruppen oder Rollen zuweisen, haben KMS-Keys außerdem eigene Key-Policies. Diese nutzen Sie, um zu definieren, welche Entitäten mit dem spezifischen Schlüssel interagieren können. Ein Vorteil der Verwendung von KMS ist, dass die Richtlinien, die zur Kontrolle der Schlüssel zum Einsatz kommen, durch die gleiche Richtliniensprache, die wir von den IAM-Policies kennen, aufgebaut sind.

Key-Policies sind die primäre Methode zur Zugriffssteuerung für KMS-Schlüssel. Jeder Schlüssel hat eine Key-Policy, die Anweisungen enthält, von wem der Schlüssel administriert, also zum Beispiel geändert oder zur Löschung markiert werden kann, und wer den Schlüssel unter welchen Umständen zur Ausführung von kryptografischen Methoden nutzen kann. In diesem Zusammenhang ist oftmals auch von Schlüsseladministratoren und Schlüsselbenutzern die Rede – eine logische Trennung dieser Personen ist prinzipiell erstrebenswert.

Im Gegensatz zu IAM Policies, die global wirken, sind die Key-Policies nur für einen bestimmten Schlüssel und nur in einer Region nutzbar. Jede Key-Policy kann eine oder mehrere Anweisungen enthalten. Listing 2 zeigt eine gültige Richtlinie für einen KMS-Schlüssel, der für die symmetrische Verschlüsselung Verwendung findet.

Mithilfe dieser Key-Policy erlauben wir durch zwei Statements die folgenden Operationen:

• Dem IAM-Benutzer "KMSAdminUser" die Administration des KMS-Schlüssels
• Dem IAM-Benutzer "EncryptionUser" die Nutzung des Schlüssels für Ver- und Entschlüsselungsoperationen

KMS mit AWS-Diensten verwenden
Viele AWS-Services unterstützen mithilfe von KMS die Verschlüsselung von Daten. Wenn ein Dienst mit KMS verzahnt ist, lassen sich mithilfe der KMS-Keys die Daten schützen, die der Service empfängt, speichert oder verwaltet. Wir legen die Operationen, die bei AWS-Diensten bei der Verschlüsselung ablaufen, am Beispiel von Amazon Elastic Block Storage (Amazon EBS) im Detail dar.

EBS bietet Volumes für die Speicherung auf Blockebene, die in Verbindung mit EC2-Instanzen zum Einsatz kommen. Greifen Sie dabei auf EBS-Volume-Verschlüsselungsfunktionen zurück, wird jedes Volume mithilfe des AES-256-XTS-Algorithmus verschlüsselt, der für das Codieren von Speicherblöcken ausgelegt ist. Dies erfordert zwei 256-Bit-Volume-Schlüssel, die Sie sich vereinfacht als einen 512-Bit-Volume-Schlüssel vorstellen können.

Der genutzte Volume-Key wird mit einem selbst gewählten KMS-Schlüssel verschlüsselt, die erforderlichen Berechtigungen dafür geben Sie in den KMS-Policies an. Die folgenden Workflows beschreiben den Ablauf der Ver- und Entschlüsselung von Daten, die auf ein EBS-Volume geschrieben werden, das an eine EC2-Instanz angeschlossen ist. Beim Erstellen eines neuen verschlüsselten EBS-Volumes (Encrypt) läuft folgender Prozess ab:

1. Das EBS-Subsystem des EC2-Hosts fordert einen neuen Volume-Schlüssel unter einem von Ihnen gewählten Key von KMS über eine TLS-Sitzung an. Das KMS-System liefert den angeforderten Schlüssel in verschlüsselter und unverschlüsselter Form über einen sicheren Kanal zurück an das EBS-Subsystem des EC2-Hosts (Hypervisor).
2. Das EBS-Subsystem speichert den mit dem KMS-Key verschlüsselten Volume-Schlüssel in den Metadaten des Volumes.
3. Das EBS-Subsystem hält den unverschlüsselten Volume-Schlüssel im volatilen Speicher, um die Daten zu verschlüsseln, bevor sie das EBS-Subsystem des EC2-Hosts verlassen.
4. Sobald das Volume nicht mehr an die virtuelle Maschine angebunden ist, wird der Volume-Schlüssel aus dem Speicher gelöscht und ausschließlich in verschlüsselter Form in den Metadaten des Volumes vorgehalten.

Das Anbinden eines bestehenden verschlüsselten Volumes (Decrypt) läuft folgendermaßen ab:

1. Das EBS-Subsystem des EC2-Hosts lädt den verschlüsselten Volume-Schlüssel aus den Metadaten des Volumes und übersendet ihn mit einen Decrypt-Befehl an den Key Management Service.
2. Der Key Management Service entschlüsselt den Volume-Schlüssel mit dem zugehörigen KMS-Key und sendet den unverschlüsselten Schlüssel über eine sichere Verbindung zurück an den EC2-Host.
3. Das EBS-Subsystem des EC2-Hosts speichert den Volume-Schlüssel in seinem volatilen Speicher, um die Daten zu verschlüsseln oder zu entschlüsseln.
4. Sobald das Volume nicht mehr an die virtuelle Maschine angebunden ist, wird der Volume-Schlüssel aus dem Speicher gelöscht und ausschließlich in verschlüsselter Form in den Metadaten des Volumes vorgehalten.

Bei näherer Betrachtung dieser Workflows fallen uns einige interessante Details auf. Zunächst sehen wir, dass der EC2-Host, im Speziellen das EBS-Subsystem, die eigentliche Verschlüsselung selbst durchführt. Müssten die Datenmengen der EBS-Volumes erst zu KMS gelangen, um dort verschlüsselt zu werden, würde dies einen enormen Ressourcenaufwand darstellen und eine entsprechende Latenz in der Verarbeitungszeit mit sich bringen. Das EBS-Subsystem hält den Schlüssel in Klartext vor, das bedeutet also, dass, solange ein EBS-Volume an einer Instanz hängt, keine weiteren API-Aufrufe zum Key Management System notwendig sind.

Außerdem wird der genutzte Datenschlüssel chiffriert mit den Volume-Metadaten abgelegt. Nicht KMS selbst hält demnach die Datenschlüssel vor – in diesem Fall tut dies der Amazon EBS Service für Sie. Nutzen Sie die KMS-Schlüssel also in eigenen Applikationen, müssen Sie sich auch um die Ablage und Sicherung der Datenschlüssel kümmern oder die dafür vordefinierten Methoden aus dem AWS Encryption SDK nutzen. Damit lassen sich kryptografische Operationen anhand von Best Practices und Industriestandards in vordefinierten Methoden definieren und auf einfache Weise in Applikationen integrieren.

So generiert das AWS Encryption SDK zum Beispiel einen eindeutigen Datenschlüssel für jedes zu verschlüsselnde Datenobjekt. Dies entspricht der bewährten Praxis der Kryptografie, eindeutige Datenschlüssel für jeden Verschlüsselungsvorgang zu verwenden. Auch die Arbeit mit den Datenschlüsseln lässt sich vereinfachen, indem über das SDK der Cipher-Text und der dazugehörige Datenschlüssel als gemeinsame Datenstruktur gespeichert werden. Das AWS Encryption SDK ist unter anderem für C, .NET, Java, JavaScript und Python nutzbar.

Der am Beispiel der EBS-Volume-Verschlüsselung beschriebene Ablauf findet sich in unterschiedlichen Varianten der serverseitigen Verschlüsselung wieder. Details zu den mit KMS verzahnten Speicherdiensten und ihrer Funktionsweise sind hier abrufbar.

ln/Simon Philipp und Armin Schneider

Im dritten und letzten Teil der Workshopserie dreht sich alles um den AWS Secrets Manager. Im ersten Teil haben wir erklärt, wie Sie mit Envelope Encryption und Schlüsselhierarchien für Sicherheit sorgen und wie Policies den Schlüsseleinsatz steuern.