Ausschluss von Betreiberzugriff (Workload-Umfang)

Warum wichtig?

Technische Reduktion von Betreiberzugriff (z.B. TEEs, Attestation, kundenseitige Schlüsselhoheit) – relevant für hochregulierte Daten/Workloads.

Wie gemessen?

• 0 = Operator kann auf Workloads/OS zugreifen (kein Schutz)
• 1 = Zugriff eingeschränkt, aber möglich (Break-glass ohne starke Kontrollen)
• 2 = Kontrollen vorhanden (Just-in-time, Logging), aber nicht ausgeschlossen
• 3 = Zugriff auf Workloads weitgehend ausgeschlossen oder stark reduziert (Scope begrenzt)
• 4 = starke technische Enforced Controls (z.B. Nitro/Confidential Compute) + Prozesse
• 5 = Zero/No-Operator-Access (Workload Scope) + prüfbar belegt (Attestation/Evidence)
• N/A = keine belastbare Evidence

Quellen / Evidence

• https://aws.amazon.com/security/confidential-computing/
• https://aws.amazon.com/ec2/nitro/nitro-enclaves/
• https://www.open-telekom-cloud.com/en/blog/benefits/sovereign-with-a-european-cloud
• https://docs.aws.eu/esc/latest/userguide/ec2.html
• https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/design-approach.html
• https://aws.amazon.com/de/blogs/germany/aws-nitro-system-erhaelt-unabhaengige-bestaetigung-seiner-vertraulichen-compute-faehigkeiten/
• https://aws.amazon.com/blogs/security/announcing-initial-services-available-in-the-aws-european-sovereign-cloud/
• https://documentation.syseleven.de/en/howtos/openstack-terraform-example/
• https://learn.microsoft.com/en-us/azure/developer/terraform/overview

Validierungsfragen (RFP)

• Welche TEE/Confidential-Compute-Optionen sind GA? Gibt es Remote Attestation? Wer besitzt/verwaltet Schlüssel (BYOK/HYOK)? Welche Debug/Break-glass-Pfade existieren? Gibt es produktive Referenzen?

Scores im Vergleich