Confidential Computing

Was Sie lernen

• Den spezifischen Bedrohungsvektor erklären, den Hardware-TEEs (Intel SGX, AMD SEV-SNP) adressieren -- Data-in-Use-Exposition -- und ihn von den Schutzmaßnahmen unterscheiden, die Standard-Verschlüsselung im Ruhezustand und während der Übertragung in SAP-Cloud-Architekturen bietet.
• Die architektonische Eignung von SGX gegenüber SEV-SNP für eine gegebene SAP-Analytics-Workload bewerten, indem die SGX-EPC-Speicherbeschränkung, das VM-Ebenen-Isolationsmodell von SEV-SNP und die Anforderungen der Remote Attestation angewendet werden, um die geeignete TEE-Technologie auszuwählen.
• Eine Mehrparteien-Analytics-Architektur mit Confidential Compute für einen Anwendungsfall in einer regulierten Branche entwerfen (Finanzdienstleistungs-Konsortium oder pharmazeutische Cross-Trial-Studie), den Attestierungs-Flow, die Schlüsselmanagement-Integration mit SAP Data Custodian und die Governance-Struktur für die Enklave spezifizieren.
• Den aktuellen TRL (Technology Readiness Level) von Confidential Computing in SAP BTP und SAP HANA gegenüber einem Kunden-Stakeholder präzise darstellen und DORA-, EU-Data-Act- und Gaia-X-Regulierungsanforderungen dem passenden SAP-Engagement-Pfad zuordnen.

Das Problem, das Confidential Computing tatsächlich löst

Jede Cloud-Analytics-Architektur trifft eine Sicherheitsannahme, die die meisten Architekten nie explizit prüfen: Daten, die im Ruhezustand (auf der Festplatte) und während der Übertragung (im Netzwerk) verschlüsselt sind, werden im Arbeitsspeicher entschlüsselt, wenn sie verarbeitet werden. Das bedeutet, dass der Hypervisor, das Betriebssystem und privilegierte administrative Konten des Cloud-Anbieters — im Prinzip — Einsicht in die Klartextdaten haben, während die Berechnung stattfindet. Für die meisten Enterprise-Analytics-Workloads ist das eine akzeptable Risikohaltung. Für bestimmte Klassen von SAP-Workloads — Mehrparteien-Analytics mit Daten, die keine Partei den anderen offenlegen möchte, regulierte Finanz- oder Gesundheitsdaten unter strengen Souveränitätsanforderungen oder hochsensible Fusions- und Übernahme-Analytik — ist es das nicht.

Confidential Computing adressiert genau diese Lücke, indem es eine hardwarebasierte Isolation einführt, die selbst privilegierte Systemsoftware daran hindert, den Speicherinhalt eines Prozesses zu lesen. Das Schlüsselkonzept ist die Trusted Execution Environment (TEE): eine hardwaregestützte Enklave innerhalb der CPU, in der Code und Daten mit kryptografischen Garantien ausgeführt werden können, dass die Inhalte für das Host-Betriebssystem, den Hypervisor und jeden anderen Prozess unzugänglich sind — einschließlich der Infrastruktursoftware des Cloud-Anbieters.

Voraussetzungen

• Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
• Zunächst die Kernkonzepte durcharbeiten: C087, C083, C047

Lernergebnisse

• Ein realistisches Szenario durcharbeiten: Ein Konsortium aus fünf europäischen Banken möchte gemeinsam ein Betrugserkennungsmodell auf gepoolten Transaktionsdaten trainieren, ohne dass eine Bank Rohdatensätze den anderen offenlegt.
• Das Anti-Pattern erkennen und vermeiden: Confidential Computing als Ersatz für Verschlüsselung während der Übertragung und im Ruhezustand zu behandeln — Der Kunde investiert zu wenig in TLS- und Ruhezustands-Kontrollen.
• Die Kernentscheidung des Moduls anwenden: SGX versus SEV-SNP für die Workload — entscheiden Sie sich für AMD SEV-SNP (VM-Ebenen-Isolation) für jede HANA-In-Memory-Analytics-Workload oberhalb der Enklavengröße -- sie läuft unverändert.
• Den Lernerfolg mit dem KPI verfolgen: EPC-Speicherspielraum (Ziel: Arbeitsspeicherbedarf der Workload bei oder unter 80 % der EPC-Größe der gewählten SGX-Enklave).