Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Healthcare Confidential Computing (HCC)

Version
0.9.1_CC
Revision
1617869
Stand
01.06.2026
Status
zur Abstimmung freigegeben
Klassifizierung
öffentlich_Entwurf
Referenzierung
gemSpec_HCC

Dokumentinformationen

Bei dieser Version des Dokumentes handelt es sich um die Grundlage für die Abstimmung zwischen der gematik und ihren Gesellschaftern sowie mit BSI / BfDI.

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Dokument definiert den Produkttyp Healthcare Confidential Computing (HCC) einschließlich der Sicherheits- und Datenschutzanforderungen. HCC stellt eine Cloud-basierte Form einer Vertrauenswürdigen Ausführungsumgebungen dar. Die Anforderungen richten sich an Hersteller von für HCC verwendete Komponenten, an Anbieter von HCC-Infrastrukturen sowie an Anbieter, die HCC als Plattform für den Betrieb von Diensten in der TI nutzen.

1.2 Zielgruppe

Das Dokument richtet sich an Anbieter, Hersteller und Betreiber von HCC-Infrastrukturen (HCC-Provider), an HCC-Dienstanbieter, die einen HCC-Provider nutzen, HCC-Workload-Hersteller, die eine Implementierung für einen HCC-Dienst liefern, sowie an ihre Sicherheitsgutachter.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des Deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

1.4 Abgrenzung des Dokuments

Diese Spezifikation ersetzt keine der bereits existierenden Anforderungslagen zur VAU, wie sie im Kontext verschiedener Anwendungen und in verschiedenen Formen definiert worden sind. Der Umstieg einer Anwendung von ihrer bisherigen Anforderungslage bzgl. der VAU auf HCC erfolgt bei Bedarf seitens der Anwendung und explizit im Zuge einer Änderung ihrer Spezifikation und dann durch Referenz auf das vorliegende Dokument bzw. seine zukünftigen Releases.

1.5 Methodik

1.5.1 Normative Festlegungen

Anforderungen und Anwendungsfälle als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Da in dem Beispielsatz „Eine leere Liste DARF NICHT ein Element besitzen.“ die Phrase „DARF NICHT“ semantisch irreführend wäre (wenn nicht ein, dann vielleicht zwei?), wird in diesem Dokument stattdessen „Eine leere Liste DARF KEIN Element besitzen.“ verwendet. Die Schlüsselworte werden außerdem um Pronomen in Großbuchstaben ergänzt, wenn dies den Sprachfluss verbessert oder die Semantik verdeutlicht.

Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung / der Anwendungsfall sämtliche zwischen ID und Textmarke [<=]  angeführten Inhalte. 
Der Identifier (ID) bei Anforderungen hat in der Regel die Vorsilbe "A_", bei Anwendungsfällen die Vorsilbe "AF_" gefolgt von einer Nummer.

1.5.2 Hinweis auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Übersicht

Die Verarbeitung von personenbezogenen medizinischen Daten im Rechenzentrum erfordert Maßnahmen, die ihre Sicherheit und Vertraulichkeit gewährleisten. Mit diesem Ziel werden schon aktive Anwendungen (u. a. ePA und eRezept) in Vertrauenswürdigen Ausführungsumgebungen betrieben. Healthcare Confidential Computing (HCC) ist eine Ausprägung der Vertrauenswürdigen Ausführungsumgebung, die in Cloud-Infrastrukturen umgesetzt werden kann.

HCC baut auf der etablierten Technologie von Confidential Virtual Machines (cVM) auf. Diese nutzt spezielle Hardwarefunktionen im Prozessor für eine Arbeitsspeicherverschlüsselung, wodurch die Daten auch während der Verarbeitung geschützt sind. In Verbindung mit konsequenter Transportverschlüsselung und verschlüsselter Speicherung der Daten wird ein Datenzugriff durch Personen beim Cloud-Provider ausgeschlossen.

Für die Verarbeitung von medizinischen Daten genügt der Ausschluss des Cloud-Providers jedoch nicht, sondern es muss auch der Datenzugriff durch den Dienstbetreiber ausgeschlossen werden.

Neben der Arbeitsspeicherverschlüsselung unterstützen die Prozessoren daher auch, das Speicherabbild einer cVM mit der darin enthaltenen Dienstsoftware zu messen und diese Information zur Verfügung zu stellen (Remote Attestation). Dadurch wird ein unabhängiger Dritter wie die gematik in die Lage versetzt, gültig betriebene Dienste eindeutig zu identifizieren und nur solche mit dem Zugriff auf die für die Datenverarbeitung notwendigen kryptographischen Identitäten in HSMs auszustatten.

HCC stellt ein Framework für die Nutzung der Confidential Computing Technologie in einer Cloud dar, das einen kryptographischen Vertrauensraum für die TI bei Cloud-Providern etabliert und damit drei Probleme technisch löst:

• Die gematik kann als unabhängiger Dritter ihre Policies in der Betriebsumgebung durchsetzen und damit die Rolle eines Trust Domain Providers einnehmen.
• Nur als zulässig registrierte Dienste (Workloads) können mit TI-Identitäten gestartet werden.
• Manipulationen oder Verletzungen der Sorgfaltspflichten in der Betriebsumgebung führen nicht zu Datenschutzverletzungen, weil die verarbeiteten Daten durchgängig durch Verschlüsselung geschützt sind.

HCC stellt auch einen Rahmen für die Prüfung und Einbringung der Dienstsoftware bereit, mit dem sichergestellt wird, dass alle Dienstsoftware die sicherheitstechnischen Anforderungen erfüllt.

HCC wird durch eine Reihe von in Cloud betriebenen sicherheitsfunktionalen Dienste umgesetzt.

Eine Reihe von Anforderungen an den Cloud-Provider adressiert die Grenzen der Sicherheitsgarantien der Confidential Computing Technologie, indem eine geschützte und korrekt betriebene Cloud-Umgebung durchgesetzt wird.

Offen: Übersichtsbild

3 Einleitung

Die Architektur der TI 2.0 ist u. a. durch die Abkehr von der rein dezentralen Verarbeitung der medizinischen Daten (im Klartext) geprägt. Die Datenverarbeitung wird in Zukunft primär in professionell betriebenen Rechenzentrumsinfrastrukturen stattfinden, um die Mehrwerte digitaler Prozesse und Daten im Gesundheitswesen schneller und mit höherer Verfügbarkeit und Qualität erschließen und funktionale Erweiterungen und Fixes schnell, flexibel, kontrolliert und kosteneffizient in der Breite verfügbar machen zu können.

Während die Nutzer der TI der zentralen Infrastruktur im Sinne des Datenschutzes bisher nur ein begrenztes Vertrauen entgegenbringen mussten, steigt in der TI 2.0 der Bedarf, die Vertrauenswürdigkeit der zentralisierten Datenverarbeitung sicherzustellen und für die Nutzer transparent und glaubhaft darstellbar zu machen. Dieser Bedarf soll mit Confidential Computing adressiert werden, ergänzt durch weitere Mechanismen und Maßnahmen.

Gleichzeitig – und unabhängig von Anforderungen an die Vertrauenswürdigkeit der Infrastruktur im engeren Sinne – befinden sich Rechenzentrumsinfrastrukturen im Wandel zum Cloud Computing. Dedizierte Systeme zur Bereitstellung von Netzwerk-, Verarbeitungs- und Speicherressourcen gehen in hochskalierten Multi-Mandanten-Infrastrukturen auf, in denen Ressourcen bedarfsgesteuert dynamisch bereitgestellt werden.

Lösungsanbieter in der TI, die Cloud-Infrastrukturen nutzen, können auf diesem Weg Up-Front-Investitionen in anwendungsbezogene Infrastruktur vermeiden. Compute-, Speicher-, Zugangs- und Transport-Ressourcen – inkl. Redundanz und Reservekapazitäten – werden anwendungs- und mandantenübergreifend ausgelastet und damit die Kosten pro Anwendungsfall gesenkt.

Die Infrastruktur für die Bereitstellung der TI-Dienste wird längerfristig eine Konsolidierung erfahren, die in Verbindung mit höherer Automatisierung und Ausreifung von Infrastruktur- Betriebsprozessen – aufgrund von Skalierungseffekten – wesentlich zur Verbesserung der betrieblichen Stabilität der TI beitragen werden.

Höherwertige Funktionalitäten, z. B. Datenbanksysteme, werden als mandantenfähige Managed Services vom Cloud-Anbieter bereitgestellt, skaliert, administriert, überwacht und aktuell gehalten, um betriebliche Aufwände für die Lösungsanbieter zu verringern, Fehlerquellen zu eliminieren und das beim Lösungsanbieter erforderliche technische Know-how zu reduzieren.

Dem Lösungsanbieter werden Werkzeuge zur eigenständigen Verwaltung der von ihm benötigten Ressourcen zur Verfügung gestellt, wobei auch Ressourcen bereitgestellt werden, bspw. für Confidential Compute, die im Rahmen definierter Grenzen automatisch mit dem Aufkommen an Requests hoch- und herunterskalieren.

Healthcare Confidential Computing ist als Begriff für die Verbindung von Cloud Computing mit dem für die Verarbeitung von Klartextdaten im Gesundheitswesen erforderlichen Vertrauensniveau definiert.

Die Datenverarbeitung soll anbieterübergreifende Standards in einem existierenden Markt für Verarbeitungs-, Speicher- und Zugangsressourcen nutzen und zur Erreichung des erforderlichen Vertrauensniveaus ggf. ergänzen.

Mit Healthcare Confidential Computing soll die Weiterentwicklung der fachlichen Funktionalität der TI von der Bereitstellung der physischen Infrastruktur entkoppelt werden, um die Umsetzung neuer Dienste der TI für ihre Anbieter substanziell zu vereinfachen.

3.1 Inhaltlicher Aufbau dieser Spezifikation

Healthcare Confidential Computing definiert eine Plattform für die vertrauenswürdige Ausführung von Diensten der TI, jedoch keine fachliche Funktionalität. Diese wird mit den Spezifikationen für die Fachanwendungen oder für unterstützende Funktionen der TI geliefert. Zur Erreichung der Sicherheitsziele von Healthcare Confidential Computing wird jedoch umfangreiche Sicherheitsfunktionalität benötigt, z. B. zur Attestation, für die Verwaltung der Umgebungen etc.

Gleichzeitig soll Healthcare Confidential Computing ein gewisses Maß an anbieterübergreifender Portabilität für (Fach-) Dienste sowie die Interoperabilität von Client-Zugriffs-Protokollen gewährleisten. Hieraus ergeben sich weitere funktionale Festlegungen und damit auch die Form des vorliegenden Dokuments als Produkttypspezifikation.

Healthcare Confidential Computing als Produkttyp ist zudem durch die Zuständigkeit der gematik für die Governance der TI motiviert, sowie durch das Ziel, Dienstanbieter auf der Plattform von vielen sicherheitstechnischen und betrieblichen Nachweispflichten sowie von der eigenen Umsetzung von Governance-Schnittstellen zu entlasten. Die gematik muss dazu die Anbieter von Healthcare Confidential Computing direkt zulassen, so dass Dienstanbieter mit der Wahl eines zugelassenen Anbieters die Zusicherungen von Healthcare Confidential Computing unmittelbar nutzen können.

Der Fokus von Healthcare Confidential Computing auf technische Sicherheitsmechanismen, auf einen anbieter- und anwendungsübergreifenden Plattformcharakter sowie auf das Ziel einer möglichst weitgehenden Bündelung der Verantwortung für die Verfügbarkeit der Dienste beim Plattformanbieter motivieren darüber hinaus die direkte Integration der Governance-Funktionen der gematik in die Healthcare Confidential Computing Infrastrukturen der Anbieter und damit auch ihre Darstellung als Teil der vorliegenden Spezifikation.

Die Abbildung der Governance-Rolle der gematik über integrierte technische Mechanismen zielt auch darauf ab, das Automatisierungspotenzial der digitalen Transformation zu erschließen und den organisatorischen Aufwand zur Aufrechterhaltung des Betriebs und der Garantien von Healthcare Confidential Computing zu begrenzen.

Die Sicherheitsleistung von Healthcare Confidential Computing bestimmt den Aufbau der vorliegenden Spezifikation. Die Sicherheitsfunktionalitäten werden aus ihrem jeweiligen Sicherheitskontext motiviert. Interoperabilitätsanforderungen werden unabhängig begründet. Betriebliche Anforderungen berücksichtigen die neue Anbieterstruktur mit ihren Rollen und Verantwortlichkeiten.

3.2 Formaler Aufbau dieser Spezifikation

Der sicherheitsfunktionale Aufbau von Healthcare Confidential Computing erfordert eine Darstellung der funktionalen Komponenten. Diese Darstellung bestimmt den ersten Teil des Dokuments, formuliert keine normativen Anforderungen im Sinne von RFC 2119 und dient dem Gesamtverständnis. Die normativen Anforderungen werden im zweiten Teil des Dokuments nach Adressaten gebündelt gestellt.

3.3 Fortschreibung dieser Spezifikation

Confidential Computing ist ein noch neues Paradigma zur Gewährleistung von Vertraulichkeit bei der Datenverarbeitung in IT-Infrastrukturen Dritter:

• Die technischen Mechanismen von Confidential Computing ändern sich noch stark von einer Hardware-Generation zur nächsten. Zudem unterscheiden sich die Confidential Computing Modelle verschiedener Hersteller. Damit unterscheiden sich auch die Wege zur Erreichung der Sicherheitsziele der TI auf Basis dieser Modelle. Die gematik setzt in Zukunft auf Confidential Virtual Machine Technologien, da diese von den verschiedenen Hardware-Herstellern unterstützt werden.
  
• Die Umsetzung der Hardware-gestützten On-Chip Mechanismen für Confidential Computing sind proprietär und damit nur eingeschränkt einer unabhängigen Begutachtung zugänglich. Dem Hersteller der Hardware muss damit ein gewisses Vertrauen entgegengebracht werden. Dieses Vertrauen ist jedoch dadurch begrenzt, dass die Systeme bei einem unabhängigen Betreiber genutzt werden und nur zu sehr begrenzten Zwecken (z. B. Plattform-Attestation, TCB-Recovery) über Proxies mit dem Hersteller in Verbindung gebracht werden.
  
• Die notwendige Ausrichtung der Hardware (z. B. CPUs) auf optimale Performance erfordert viele Optimierungen auf Hardware-Ebene mit von Prozessen gemeinsam genutzten Ressourcen (wie Pipelines, Page Tables, Caches, Translation Lookaside Buffers, Branch Predictors etc.) und einer eigenen Semantik, die bisher nicht klar mit einer Semantik zur Isolation von Verarbeitungsprozessen zusammengesetzt werden konnte. Hierbei könnte es sich um ein prinzipielles Problem handeln. So ergeben sich regelmäßig neue Schwachstellen, die für Angreifer ein „Window of Opportunity“ darstellen können. Die Schwachstellen müssen durch den Infrastrukturbetreiber gepatcht werden und nehmen diesen damit wieder organisatorisch in die Pflicht. Maßnahmen zur Begrenzung der resultierenden Risiken können Einschränkungen hinsichtlich der Flexibilität des Deployments von Workloads beim Cloud-Computing mit sich bringen. Konkret: Die Isolationsgarantien von Enklaven oder Confidential VMs werden regelmäßig durch neu entdeckte Schwachstellen, insbesondere durch Seitenkanäle, infrage gestellt. Dies wird auch für die Zukunft erwartet und es resultiert in Anforderungen zur Ausführung von HCC-Workloads auf exklusiv für HCC bereitgestellten Hosts und zur Attestation und Offenlegung des Host-OS. Es wird davon ausgegangen, dass sich hieran in absehbarer Zukunft nichts ändern wird.
  
• Die industriellen Möglichkeiten zur Abbildung einer anbieterunabhängigen Governance-Rolle befinden sich noch in der Entstehung. Das vorliegende Dokument stellt gerade hierzu einen Entwurf dar. Die Integration dieser Rolle innerhalb der gematik wird ein fortwährender Prozess sein, der sich auch auf die Schnittstellen zu HCC-Providern auswirken wird.
  
• Standards z. B. für die Formate, Inhalte und Protokolle für Remote Attestation befinden sich noch im Entstehungsprozess. Die gematik wird diesem Prozess auf der Ebene ihrer Spezifikationen folgen, wo es sinnvoll erscheint.

Die vorliegende Spezifikation versucht bereits die genannten Einschränkungen durch geeignete Anforderungen und TI-spezifische Festlegungen zu adressieren. Gleichwohl muss sich jeder Anbieter, der eine Zulassung als HCC-Provider gemäß dieser Spezifikation anstrebt, darauf einstellen, dass die Spezifikation mit dem sich weiter entwickelnden Stand von Technik und Forschung fortgeschrieben wird, und dass damit in Zukunft eventuell zusätzliche Anforderungen oder Änderungen an bestehenden Anforderungen verbunden sein werden, die er in der Folge umsetzen muss, um seine Zulassung zu erhalten.

Weitere Quellen zukünftiger Änderungen an dieser Spezifikation betreffen folgende Aspekte:

• Standardisierungsbemühungen internationaler Organisationen, wie IETF und Confidential Computing Consortium.
  Diese betreffen kryptographische Primitiven, Attestationsprotokolle, Attestation Evidence sowie Trust und Provisioning, Insbesondere die Integration von Confidential Computing mit den dominierenden Technologien im Cloud-Stack (z. B. Kubernetes) erscheint derzeit noch kein standardisiertes Modell hervorgebracht zu haben,
  
• die schrittweise Integration und Automatisierung der Governance-Rolle der gematik im Rahmen der Einführung der TI 2.0.
  Hiervon werden primär Formate, Protokolle und Prozesse an der Schnittstelle zur gematik betroffen sein,
• Veränderungen am organisatorischen Rahmen der gematik für Zulassung und Betriebsprozesse,
• die Erweiterung von Steuerungsmöglichkeiten, die der HCC-Provider seinen Kunden zur Verfügung stellen, insbesondere Möglichkeiten zur Kombination der (fachlichen) Lösung des Kunden mit generischen Komponenten der TI 2.0, z. B. Komponenten der anwendungsübergreifenden Zero Trust Architektur (Policy Enforcement, Policy Decision) sowie
  
• die Erweiterungen der Service Portfolios der HCC-Anbieter z. B. mit Cloud-native Services.

Die Integration von Healthcare Confidential Computing mit Cloud-native Services, d. h. mit Subsystemen in der Cloud-Infrastruktur, die auf eine Nutzung der Systemressourcen durch viele Kunden des Cloud Providers optimiert sind, bedarf in jedem Einzelfall einer Überprüfung ihrer Vereinbarkeit mit den Sicherheitsgarantien.

3.4 Standardisierung des Confidential Computing Ansatzes

Die gematik hat traditionell ihre Spezifikationen möglichst technologieneutral zu gestalten versucht. Dieser Ansatz war insbesondere im Falle von "Gesamtlösungen aus einer Hand", wie bei den bisher umgesetzten (Fach-)Diensten, plausibel.

Mit der Nutzung von Confidential Computing Technologie und insbesondere der Attestation von Systemen durch Dienste in der (Co-) Hoheit der gematik, wird eine neue Konstruktion für den Vertrauensraum in der TI möglich, die eine erhebliche Steigerung der Transparenz aus Sicht der Nutzer der TI und aus Sicht der gematik als öffentlichem Garanten für Datenschutz und Sicherheit darstellt.

Attestation wird bereits seit der ersten Implementierung der elektronischen Patientenakte in einer Vertrauenswürdigen Ausführungsumgebung als Basis für die Ermöglichung der Klartextverarbeitung von personenbezogenen medizinischen Daten der TI in Rechenzentren genutzt und mit der vorliegenden Spezifikation für Cloud-Umgebungen nutzbar gemacht sowie weiter ausgebaut (siehe 6.3 Shared Responsibility Model).

Dies erfordert ein gewisses Maß an technologischer Standardisierung, um:

• die erforderliche Transparenz auf einem einheitlichen Sicherheitsniveau zu erreichen,
• die Plattform steuerungsfähig zu machen und
• im Zuge der schrittweisen Weiterentwicklung der Plattform eine Fragmentierung des Designs, technische Barrieren sowie ausufernde Aufwände zu verhindern.

Darüber hinaus müssen die bereits in 3.3 Fortschreibung dieser Spezifikation genannten industriellen Entwicklungen beim Confidential Computing berücksichtigt und mit der für Cloud-Computing erforderlichen Trennung zwischen Plattform und Diensten (sowie ihren jeweiligen Anbietern) in Einklang gebracht werden. Diese Trennung bringt einen Bedarf an Interfaces mit sich, der stark von der genutzten Confidential Computing Technologie abhängt.

In der Industrie hat sich im Verlauf der letzten Jahre eine Präferenz für Confidential Virtual Machines etabliert, die insbesondere auf die Nutzung in der Cloud ausgerichtet ist. Confidential Virtual Machines werden daher von der gematik als Grundlage für die Standardisierung genutzt.

Die mit diesem Trend verbundenen Herausforderungen (z. B. deutlich vergrößerte Trusted Computing Base im Sinne der industrieüblichen Definition für Confidential Computing) werden in Kauf genommen (und adressiert), um keine der am weitesten verbreiteten Hardware-Plattformen (Intel, AMD, ARM, NVIDIA, IBM, etc.) auszuschließen und gleichzeitig eine einheitliche Abgrenzung zwischen (Cloud-) Plattform und Workloads (confidential laufende Virtual Machines, in denen die Dienstkomponenten laufen) zu erhalten.

Im Einklang mit der weiteren Strategie für die TI 2.0 wird gleichzeitig die Interoperabilität mit Kubernetes als Mechanismus für das Provisionieren und zur Steuerung von Workloads insbesondere in der Cloud berücksichtigt. Kubernetes handhabt Workloads auf Basis von Containern gemäß OCI (Open Container Initiative).

Aus der Kombination von Confidential VMs (cVM) und Managed Containers resultiert ein Design-Problem, für das es verschiedene Lösungsansätze aus der Industrie gibt, jedoch derzeit noch keinen Ansatz, der sowohl hinsichtlich Sicherheit, als auch Performance, als auch Verbreitung gut etabliert ist. Hierbei spielt es eine Rolle, dass Kubernetes von sich aus z. B. keinen verschlüsselten Transport von Konfigurationsdaten vorsieht und dass die Control Plane von Kubernetes generell die Pods steuert, die bei cVMs innerhalb des Verarbeitungskontextes laufen, was dem Betreiberausschluss entgegensteht.

Um diesem Problem auszuweichen, wird der Integrationspunkt zwischen containerisierter Workload und cVM-basierter Ausführungsumgebung in der Cloud aus der Laufzeitumgebung heraus in eine Build-Umgebung für HCC-Dienste verlagert, die kontinuierlich weiterentwickelt wird.

HCC-Provider implementieren ihre Laufzeitumgebungen auf der Grundlage von (attestierbaren) cVMs und gemäß den Sicherheitsanforderungen auf in Teilen jeweils eigene Weise und stellen eine Provider-spezifische Build-Pipeline bereit, die standardmäßig containerisierte Workloads von Dienstanbietern in bei dem jeweiligen Provider attestierbare und ausführbare cVMs transformiert und - nach Freigabe - an seine Cloud-Systeme (Deployment Repository, Attestation Service) übermittelt, damit sie in der Cloud instanziiert werden können.

Im Laufe der Zeit können sich herausbildende Standards oder Verbesserungen der bestehenden Lösungen seitens der HCC-Provider umgesetzt werden. Auch wird zum aktuellen Zeitpunkt eine starre Auslegung der Standardisierung hinsichtlich Kubernetes vermieden, damit HCC-Provider das Workload-Deployment selbst gestalten und optimieren können.

4 Sicherheitsziel

Personenbezogene medizinische Daten besitzen einen sehr hohen Schutzbedarf und erfordern daher besondere Maßnahmen zu ihrem Schutz, wenn sie von Anbietern in der TI verarbeitet, gespeichert oder transportiert werden.

Wenn darüber hinaus (und bei der Nutzung von Cloud-Computing anzunehmen) eine sehr große Zahl von Personen von unberechtigten Zugriffen in der Betriebsumgebung eines Anbieters betroffen sein könnten, ist eine noch größere Sorgfalt bei der Festlegung und Umsetzung der Maßnahmen gerechtfertigt.

Rein organisatorische Maßnahmen bei Betreibern von Diensten, die solche Daten verarbeiten, sowie bei den Betreibern der darunterliegenden Infrastrukturen werden als nicht ausreichend angesehen, um unberechtigte Zugriffe ausreichend zu unterbinden.

Das Sicherheitsziel für Healthcare Confidential Computing entspricht dem Sicherheitsziel für die Vertrauenswürdige Ausführungsumgebung:

Das Sicherheitsziel für Healthcare Confidential Computing baut auf den in der TI bereits geltenden Anforderungen für den Schutz von transportierten Daten durch Verschlüsselung und von gespeicherten Daten durch Verschlüsselung und geeignete Speichersysteme auf (siehe [gemSpec_Krypt] und die Spezifikation der jeweiligen Anwendung).

Die Übergänge in den Verarbeitungskontext mit Klartextverarbeitung (Entschlüsselung von eingehenden Client-Requests und von Daten aus der Speicherung) und aus ihm heraus (Verschlüsselung von Responses und von Daten, die gespeichert werden) werden als Teil der vertrauenswürdigen Verarbeitung innerhalb des Dienstes betrachtet.

5 Begriffsdefinitionen

Dieser Abschnitt führt die in diesem Dokument genutzten Begriffe ein.

Schützenswerte Daten: Umfasst alle Daten einer Anwendung mit sehr hohem Schutzbedarf, die kein Unbefugter einsehen oder ändern darf.
Der Anbieter des Dienstes, in dem die Daten im Klartext verarbeitet werden, sowie der Anbieter der betrieblichen Infrastruktur des Dienstes zählen als unbefugt, sofern sie nicht gemäß Spezifikation der Anwendung auf Daten zugreifen dürfen. Zu den Unbefugten zählen des Weiteren externe Angreifer sowie ggf. andere Dienstanbieter innerhalb oder außerhalb der TI, deren Dienste in einer gemeinsamen Betriebsumgebung mit dem Anwendungsdienst betrieben werden.

Vertrauenswürdige Ausführungsumgebung (VAU): Gesamtheit der für eine sichere Klartextverarbeitung erforderlichen Software und Hardware beim Betreiber eines VAU-Dienstes.

Healthcare Confidential Computing (HCC): Das im vorliegenden Dokument spezifizierte sicherheitstechnische Rahmenwerk der gematik zur Definition von Anforderungen an Anbieter, Infrastrukturen, Anwendungen und Prozesse in der TI, die eine VAU bei nach den Prinzipien des Cloud-Computings operierenden Anbietern realisieren.
HCC setzt voraus, dass der Anbieter (HCC-Provider) am Markt auftritt und für jeden seiner Kunden einen Mandantenkontext bereitstellt, in dem die administrativen Funktionen für die Ressourcenallokation, für das Deployment und zur weiteren Steuerung des Betriebs von Diensten verfügbar sind. Weiterhin wird vorausgesetzt, dass Dienste bis zu einem gewissen Grad automatisch skalieren. Die Sicherheitsleistungen des HCC-Providers sollen seine Mandanten (die Anbieter von HCC-Diensten in der HCC-Infrastruktur) im Hinblick auf die an sie gerichteten Anforderungen zum Nachweis der Sicherheit ihrer Dienste weitgehend entlasten. Der HCC-Provider unterhält eine direkte Beziehung mit der gematik und stellt für diese einen Mandantenkontext bzw. geeignete Schnittstellen bereit, die dazu dienen, den kryptographischen Vertrauensraum der TI für HCC (HCC-Trust-Domain) in seiner Infrastruktur verfügbar zu machen.

HCC-Dienst: Fachdienst oder anderer Dienst der TI. Enthält die Anwendungslogik und alle Logik, die zu ihrer Steuerung notwendig ist. Der Dienst wird auf einer HCC-Infrastruktur betrieben, um schützenswerte Daten im Klartext zu verarbeiten.

HCC-Infrastruktur: Gesamtheit der für eine sichere Klartextverarbeitung erforderlichen Software und Hardware bei einem Cloud-Anbieter.
HCC-Infrastruktur stellt eine Cloud-basierte Form der VAU-Infrastruktur dar. Zur Hardware gehören insbesondere die HCC-Server sowie alle für ihre betriebliche Steuerung erforderlichen Komponenten. Zur HCC-Infrastruktur gehören Komponenten für das Routing von Requests aus dem Internet (oder - solange dieses noch erforderlich ist - aus dem Netz der TI) an den HCC-Dienst und das Routing der Responses zurück an Clients, wenn solche Komponenten dem Betreiber oder Angreifern Einblick in individuelles Nutzerverhalten ermöglichen könnten und daher regulatorisch relevant sind. Zur HCC-Infrastruktur gehören die Systeme zur verschlüsselten Speicherung von Daten insoweit, als auch für die verschlüsselten Daten sichergestellt werden muss, dass diese nicht in Systeme außerhalb zugelassener Regionen oder nicht zugelassener Anbieter abfließen.

Trusted Computing Base (TCB): Gesamtheit der Software und Hardware beim Betreiber, deren sicherheitstechnische Korrektheit gegeben sein muss, um den Ausschluss unbefugter Zugriffe sicherzustellen.
Ein grundlegendes Prinzip bei der Konstruktion von HCC-Infrastruktur besteht darin, die TCB möglichst klein zu halten, um die Angriffsfläche zu minimieren und um zu ermöglichen, dass z. B. ein Gutachter die Sicherheitsgarantien mit möglichst großer Gewissheit feststellen kann. Die TCB ist der wesentliche Teil der Gesamtheit der HCC-Infrastruktur aus der Perspektive der Sicherheit. Neben der TCB umfasst die Gesamtheit der HCC-Infrastruktur Komponenten, die ihren Betrieb ermöglichen und steuern und somit zur Gewährleistung der Verfügbarkeit beitragen, jedoch keine Auswirkung auf Vertraulichkeit und Integrität der Klartext-Datenverarbeitung haben. Die TCB umfasst grundsätzlich die Komponente, die die fachliche Verarbeitung implementiert, d. h. den fachlichen Kern des HCC-Dienstes.

HCC-Host: Für die Ausführung von HCC-Diensten (als Workloads) geeignete und genutzte Server-Hardware.
HCC-Hosts implementieren eine Confidential Computing Technologie und die für eine Attestation des gesamten Servers sowie aller darauf installierten Workloads erforderlichen Mechanismen. Hierzu gehören mindestens Measured Boot, ein Hardware-geschützter Root of Trust für die Attestation sowie ein Mechanismus für die sichere Trennung der Klartextdatenverarbeitung von den Funktionen zur betrieblichen Steuerung des Servers durch den Betreiber. Es wird davon ausgegangen, dass HCC-Hosts als virtualisierte Ablaufumgebungen für Workloads konfiguriert sind.

Workload-Image: Container Image oder Virtual Machine Image, das die Implementierung der Verarbeitung der Anwendungsdaten im Klartext im HCC-Dienst umfasst.
Das Workload-Image stellt die Workload zur Ausführung in der virtualisierten Infrastruktur bereit. Im Zuge der Attestation wird für jedes vom HCC-Host geladene Workload-Image eine eindeutige Workload Identity (in Form von Hardware-signierten Hash-Werten) ermittelt, die mit Soll-Werten in einer Konfigurationsdatenbank abgeglichen werden kann, um die Berechtigung der Workload zur Verwendung der kryptographischen Identität (X.509-Zertifikat) des durch sie implementierten HCC-Dienstes und von weiterem Schlüsselmaterial zu erteilen.

Verarbeitungskontext: Der Verarbeitung eines Requests im HCC-Dienst zugeordneter Prozess, Thread oder Scope einschließlich aller sicherheitsrelevanten Abhängigkeiten.
Client-Requests erreichen den Verarbeitungskontext verschlüsselt. Im Scope des Verarbeitungskontextes sind alle für die Verarbeitung des Client-Requests erforderlichen Schlüssel erreichbar. Der Verarbeitungskontext führt die fachliche Logik (inkl. Autorisierung) zur Behandlung des Requests aus und antwortet dem Client mit einer verschlüsselten Response. Falls im Rahmen der Request-Verarbeitung schützenswerte Daten persistiert oder mit anderen Diensten bzw. anderen Verarbeitungskontexten ausgetauscht werden müssen, so verschlüsselt der Verarbeitungskontext diese Daten vorher. Der Verarbeitungskontext stellt den technischen Kern der TCB dar.

HCC-Client: Software-Client, der das Protokoll zum Zugriff auf einen Verarbeitungskontext umsetzt.
Der Software-Client nutzt Mechanismen der Hardware, des Betriebssystems oder der Plattform des Client-Gerätes, auf dem er läuft, um Schlüsselmaterial zu schützen oder die im Kontext von Zero Trust erforderlichen Nachweise (Client-Attestation) zu erzeugen. Der HCC-Client spielt in der vorliegenden Spezifikation u. A. deshalb eine Rolle, weil die HCC-Infrastruktur als Plattform für verschiedene Dienste der TI mindestens ein anwendungs- und anbieterübergreifend interoperables Zugriffsprotokoll für HCC-Clients unterstützen muss.

Anwendungs-Client: Software-Client einer Anwendung.
Der Anwendungs-Client nutzt einen HCC-Client zum Zugriff auf einen HCC-Dienst. Anwendungs-Clients können den HCC-Client als Komponente integrieren.

HCC-Kanal: Durchgehend verschlüsselte Verbindung zwischen HCC-Client und Verarbeitungskontext.
Der HCC-Kanal kommt in zwei Ausprägungen vor, als reiner TLS-Kanal sowie als TLS-Kanal mit zusätzlicher Verschlüsselung auf Anwendungsebene mittels des VAU-Protokolls bzw. ZETA/ASL (siehe [gemSpec_Krypt], Kap. 7). Insbesondere die Möglichkeit zur Verwendung von reinem TLS kann sich auf die dem Verarbeitungskontext vorgelagerten Infrastrukturkomponenten auswirken, da in diesem Fall DDoS-Schutzkomponenten, Firewalls, Load Balancer, API- und Ingress-Gateways keine TLS-Entschlüsselung von Requests durchführen können.

Persistenzschlüssel: Kryptographische(r) Schlüssel, mit dem Daten bei ihrer Speicherung außerhalb der TCB (in Dateisystemen, Datenbanken, etc.) vor dem Zugriff Unbefugter geschützt werden.
Persistenzschlüssel werden anwendungsspezifisch gebildet und im Verarbeitungskontext oder aus ihm heraus in einem HSM-Cluster oder einem HCC-Host-lokalen Hardware-Krypto-Modul generiert und genutzt.

HCC-Dienst-Hersteller: Entwickelt die Software für den HCC-Dienst, beauftragt ihre Begutachtung und beantragt ihre Zulassung.
Zu der Software zählt insbesondere das Workload-Image. Die Entwicklung von HCC-Workloads zielt auf ihre Lauffähigkeit bei einem oder mehreren HCC-Providern ab. Hieraus ergeben sich Anforderungen hinsichtlich der Interoperabilität der Laufzeitumgebungen von HCC-Providern, aber ggf. auch Anforderungen zur Nutzung HCC-Provider spezifischer Templates (z. B. für confidential Virtual Machines) durch den HCC-Workload-Hersteller.

HCC-Dienstanbieter: Bietet einen HCC-Dienst in der TI an.
Die Rolle des HCC-Dienstanbieters ist eine primär geschäftlich-organisatorische und umfasst die Konfiguration des Mandantenkontextes sowie den User-Rollout und den Support.

HCC-Provider: Durch die gematik zugelassener Anbieter, der eine mandantenfähige Infrastruktur für den Betrieb von HCC-Diensten bereitstellt.
Dies umfasst Kapazitäten für die Datenverarbeitung, die Datenspeicherung, den Netzwerktransport inkl. Anbindung an das Internet (und ggf. das bisherige Netz der TI) sowie Cloud-Services. Kunden bzw. Mandanten des HCC-Providers sind HCC-Dienstanbieter. Wenn ein Cloud Provider neben seiner Rolle als HCC-Provider auch andere Sektoren, Märkte oder Kunden adressiert, so werden nur die HCC-spezifischen Teile seiner Infrastruktur, Services, Komponenten und Prozesse dem HCC-Provider zugerechnet. Wenn ein Anbieter gleichzeitig als HCC-Provider und als HCC-Dienstanbieter auftritt, dann können organisatorische Trennungsanforderungen zum Tragen kommen.

HCC-Mandant: Kunde bzw. Mandant eines HCC-Providers, der mittels Konfiguration des durch den HCC-Provider bereitgestellten Mandantenkontextes die Dienste (eigene oder Dienste aus dem Portfolio des HCC-Providers oder von Dritten) definiert und parametrisiert, welche für ihn in der Infrastruktur des HCC-Providers laufen.
HCC-Mandanten sind HCC-Dienstanbieter aus der Perspektive des HCC-Providers betrachtet.

HCC-Trust-Domain (HCC-TD): Der HCC-Provider-übergreifend implementierte und durch die gematik verantwortete kryptographische Vertrauensraum aller HCC-Dienste und Komponenten.
Die HCC-TD baut auf einer oder mehreren (auch externer) PKI auf und spannt das Netz kryptographisch prüfbarer Beziehungs-, Verbindungs- und Nutzungsmöglichkeiten auf. Eine Besonderheit von Confidential Computing besteht darin, dass Confidential Services als vollständige Automaten mit kryptographischer Workload Identity und einer zugeordneten Signer Identity ausgestattet werden können. Von solchen Services generierte und signierte Artefakte können dann eingesetzt werden, um Vertrauensbeziehungen über komplexe Regelwerke (Policies oder Code) zu etablieren.

Confidential Computing Stack (CC-Stack): Integrierter Satz von Technologien, die eine Implementierung von Confidential Computing realisieren.
Ein solcher Stack kann auf verschiedene Weise aufgebaut sein, um u. a. sein Ziel der Abwehr von Angriffen aus dem betrieblichen Umfeld des HCC-Providers zu erreichen. Er muss mittels Hardware-Unterstützung mindestens die folgenden Eigenschaften aufweisen:

• Verschlüsselung des Arbeitsspeichers zur Abwehr von Angriffen auf Daten im Arbeitsspeicher mittels Entnahme des Arbeitsspeichers und Auslesens außerhalb des Schutzes durch den Server sowie
• Fähigkeit zur Attestation des Systems inkl. Hardware, Firmware, Hypervisor, Betriebssystem, Plattformkomponenten und Anwendungskomponenten (Workloads) auf der Basis von Hardware-geschützten Host-lokalen Vertrauensankern.

6 Konzepte, Systemkontext und Akteure

In den folgenden Abschnitten werden die grundlegenden Konzepte dargestellt, die Healthcare Confidential Computing definieren und begründen.

6.1 Confidential Computing

Confidential Computing ist eine aus Sicht des Datenschutzes zwingende Voraussetzung für die Zulässigkeit einer aus dem Verantwortungsbereich der Akteure des Gesundheitswesens ausgelagerten Verarbeitung personenbezogener medizinischer Klartextdaten in der TI.

Der Grundgedanke des Confidential Computings ist bereits in den Vertrauenswürdigen Ausführungsumgebungen der Fachdienste der ePA, des E-Rezepts und der sektoralen Identity Provider umgesetzt. Er besteht darin, die Klartextverarbeitung (von personenbezogenen medizinischen Daten) innerhalb der physischen Infrastruktur mit technischen Mitteln so weit zu isolieren, dass es selbst einem Angreifer aus dem betrieblichen Umfeld der Infrastruktur nicht möglich ist, Vertraulichkeit, Integrität oder Authentizität der Datenverarbeitung bzw. der Daten selbst zu verletzen. Confidential Computing liefert Schutz für Data in Use.

Die Klartextverarbeitung erfolgt damit in isolierten Verarbeitungskontexten. Nur innerhalb dieser Verarbeitungskontexte können die schützenswerten Nutzdaten im Klartext vorliegen und für den Transport und die Speicherung der Nutzdaten benötigtes Schlüsselmaterial zur Ver- und Entschlüsselung verwendet werden. Gleichzeitig ist die Code-Basis der Verarbeitungskontexte, die Trusted Computing Base (TCB), möglichst klein gehalten, um in der Begutachtung eine starke Zusicherung über die Sicherheitseigenschaften erzielen zu können.

Daneben gelten weitere Anforderungen:

• Schutz für Data at Rest: Nutzdaten werden verschlüsselt gespeichert und ein Abfluss der Nutzdaten aus der geschützten Infrastruktur wird mittels baulich-physikalischer und organisatorischer Maßnahmen ausgeschlossen.
• Schutz für Data in Transit: Nutzdaten werden grundsätzlich verschlüsselt und nur zwischen wechselseitig authentisierten und zulässigen (autorisierten) Systemen transportiert.
• Verbot von Nutzertracking und Profilbildung: Die Auswertung nutzer- bzw. institutionsbezogenen Verhaltens durch den Anbieter ist im Confidential Computing weitgehend systematisch durch die Gesamtarchitektur auszuschließen. Notwendige und zulässige Auswertungen sind auf Anwendungsebene umgesetzt und damit Teil der spezifizierten Autorisierungsmodelle der Anwendungen. Hierzu gehören auch alle erforderlichen Mechanismen zur Entstörung soweit sie einen Umgang mit den verarbeiteten Nutzdaten oder Einblick in Nutzerverhalten erfordern.
• Sichere Entwicklung und Inbetriebnahme: Die Software der Dienste und an der Verarbeitung der Nutzdaten beteiligter Komponenten wird mittels sicherer Prozesse entwickelt, durch anerkannte Prüfstellen begutachtet und authentisiert sowie integritätsgeschützt in die Betriebsumgebung eingebracht.
• Sichere Hardware: Die Hardware von an der Verarbeitung der Nutzdaten beteiligten Systemen ist hinsichtlich ihrer Eignung für das erforderliche Vertrauensniveau geprüft und wird über sichere Prozesse beschafft und verwaltet.
• Governance durch gematik: De Wirksamkeit der technischen Mittel wird durch die gematik, als unabhängige Institution und Governance-Verantwortliche für die TI, möglichst öffentlich, kontinuierlich und prüfbar dargestellt.
• Datenschutzgarantien: Die gematik gründet ihre Datenschutzgarantien auf einer (Produkt-)Zulassung für die HCC-Infrastruktur, auf geeigneten weiteren Zulassungs-, Begutachtungs- und Zertifizierungsprozessen, die den Anbietern auferlegt sind, sowie auf der Attestation der laufenden Dienste.
• Schutz vor Seitenkanalangriffen: Aufgrund der Grenzen der Schutzwirkung der als Confidential Computing vermarkteten Technologien gegenüber Seitenkanalangriffen muss ausgeschlossen werden, dass Nicht-HCC-Prozesse auf derselben CPU parallel mit HCC-Prozessen laufen. Prozesse des Infrastrukturbetreibers, die aus technischen (z. B. Hypervisor) oder betrieblichen Gründen (z. B. Observability-Funktionen) mit auf der CPU laufen müssen, müssen als Teil der TCB betrachtet, mit begutachtet und mit attestiert werden.

Dem Anbieter der Confidential Computing Infrastruktur obliegt damit im Betrieb primär die Sicherstellung der Verfügbarkeit seiner Infrastruktur und der darauf laufenden Dienste, d. h. die Erfüllung von betrieblichen Service Level Agreements bezüglich Erreichbarkeit der HCC-Dienste aus dem Internet (und ggf. noch aus dem zentralen Netz der TI) und Verfügbarkeit der Transport-, Verarbeitungs- und Speicherkapazitäten sowie die bedarfsgerechte Provisionierung der HCC-Dienste. Seine eigenen administrativen Eingriffsmöglichkeiten enden an den Grenzen der Trusted Computing Base.

6.2 Cloud Computing

Im Unterschied zu den bisher anwendungsspezifisch umgesetzten Infrastrukturen u. a. der ePA und des E-Rezepts ist Healthcare Confidential Computing darauf ausgerichtet, eine generische Infrastruktur für die Umsetzung von Basis- und Fachdiensten bereitzustellen und damit eine Form des Cloud Computing zu ermöglichen sowie auch tatsächlich in hochskalierten (Public) Cloud Infrastrukturen betrieben zu werden. Mit dieser Ausrichtung werden verschiedene Ziele verfolgt:

• Verbesserungen der betrieblichen Stabilität der TI durch längerfristige Konsolidierung, Standardisierung und Integration der Infrastruktur,
• Verringerung der personellen und prozessualen Aufwände für die Bereitstellung der Infrastruktur für die TI-Dienste, die exklusiv durch das Gesundheitswesen getragen werden müssen,
• Nachnutzung der Weiterentwicklung der Technologien, der Automatisierung, der Qualitätssteigerungen, der Verfügbarkeit und des wachsenden nativen Service-Portfolios in der Cloud für die Dienste der TI sowie
• Nutzung der elastischen Skalierbarkeit von Diensten in der Cloud.

Anbieter von Healthcare Confidential Computing (HCC-Provider) bieten ihre Infrastrukturen marktoffen für die Anbieter von (Fach-) Diensten der TI an.

Ein TI-Dienstanbieter tritt als Kunde mit seinem HCC-Provider in eine Geschäftsbeziehung und erhält damit Zugang zu einem Mandantenkontext innerhalb der Infrastruktur. Er erhält damit auch die Werkzeuge zur eigenständigen Buchung von Systemressourcen, zur Konfiguration und zur betrieblichen Überwachung der Systemressourcen und seiner Dienste sowie für die Aufnahme seiner Dienste in den Vertrauensraum von HCC bzw. der TI 2.0. Charakteristisch für Cloud Computing ist dabei insbesondere, dass die Bereitstellung der Infrastruktur-Ressourcen auf bereits betriebsbereiten Systemen automatisiert erfolgt, sobald der Kunde dies via Web-Schnittstelle oder über APIs angefordert hat. Darüber können Dienste mit dem Volumen der an sie gerichteten Anfragen automatisch hoch- und herunterskaliert werden. Dem Dienstanbieter werden generell nur die tatsächlich genutzten Ressourcen in Rechnung gestellt.

Der Dienstanbieter kann für seinen Dienst damit die vom HCC-Provider bereitgestellten Systemressourcen nutzen und darauf verzichten entsprechende eigene Infrastruktur aufzubauen. Er kann darüber hinaus die Funktionalitäten von Cloud-Services nachnutzen, indem diese in seinem Mandantenkontext für ihn instanziiert oder als Shared Cloud-native Services für den Dienstanbieter konfiguriert werden, und muss daher solche Funktionalitäten nicht selbst entwickeln. Der Dienstanbieter nutzt dabei (ggf. teilweise automatisch) die in der Infrastruktur umgesetzten Sicherheits- und Betriebsmechanismen, die Schnittstellen zu den TI-spezifischen SIEM und Monitoringsystemen der gematik sowie die erteilten Zulassungen und Zertifizierungen des HCC-Providers nach und kann damit die Zulassungsprozesse für seinen Fachdienst substanziell vereinfachen.

Cloud Computing liefert mit seinen Container- oder VM-basierten Deployment-Möglichkeiten auch die Grundlage für eine Integration (durch Konfiguration in der Laufzeitumgebung) von fertigen Komponenten in (Fach-) Dienste. Für eine solche Nutzung sind z. B. Komponenten zur Autorisierung vorgesehen, die im Rahmen der Einführung der Zero Trust Architektur der TI 2.0 durch die gematik bereitgestellt werden sollen. Sie werden im Dienstkontext instanziiert und liefern z. B. eine Integration in die Sicherheitsadministration der TI mit.

6.3 Shared Responsibility Model

Für die Bereitstellung von Diensten resultiert beim Confidential Computing in der Cloud ein Modell von „Shared Responsibility“ in dem der Dienstanbieter die Verantwortung für die funktionale Korrektheit und Sicherheit der von ihm eingebrachten Implementierung seines Dienstes trägt und diese auch begutachten lässt und zur Zulassung einreicht. Dabei muss er den durch die Infrastruktur gesetzten rechtlichen, betrieblichen und sicherheitstechnischen Rahmen berücksichtigen. Der HCC-Provider unterstützt dies, indem er offene, industrieübliche und stabile Schnittstellen für die Nutzung seiner HCC-Infrastruktur anbietet.

Die geteilte Verantwortlichkeit zwischen HCC-Dienstanbieter und HCC-Provider wird durch die Verantwortung der gematik als Garant für Verfügbarkeit, Performance und Sicherheit der TI erweitert:

• Verfügbarkeit: Die Abgrenzung der Verantwortlichkeiten von Dienstanbietern und HCC-Provider erfolgt technisch durch geeignete "Übergabemesspunkte" (z. B. "Request an die Eingangsschnittstelle der Dienst-Workload geroutet", "Request durch Dienst-Workload verarbeitet") im Rahmen der Festlegungen zur Gesamtverfügbarkeit des Dienstes.
• Performance: Optimierung der HCC-Plattformen hinsichtlich dienstübergreifender Stabilität und Performance (im Sinne der Effizienz) seitens der HCC-Providers gemeinsam mit der gematik in einem fortlaufenden Prozess.
• Sicherheit: Implementierung des dienstübergreifenden souveränen HCC-Vertrauensraums (HCC Trust Domain) einschließlich des Policy Managements unter (Co-)Hoheit der gematik in der Infrastruktur des HCC-Providers.

Die Verantwortlichkeit der gematik bildet sich bei HCC über technische Mittel zur direkten Überwachung der beteiligten Systeme ab. Sie erstreckt sich damit von der Ebene der Zulassung über die Sicherheits- und Betriebsüberwachung bis in die Ebene der Infrastruktur, ohne HCC-Provider oder Fachdienstanbieter aus ihrer jeweiligen Verantwortung zu entbinden.

Abbildung 1: Shared Responsibility - Verteilung der Aufgaben

Ein möglichst großer Teil der querschnittlich benötigten Plattformdienste soll im Mandantenkontext des Dienstanbieters instanziiert werden, um komplexe Cost Sharing Modelle zu vermeiden und ein immer noch hohes Maß an organisatorischer Trennung zwischen Dienstanbietern auch innerhalb einer HCC-Infrastruktur zu gewährleisten.

6.4 Implementierte HCC-Governance

Die Zulassung eines HCC-Dienstes zur TI impliziert seinen Betrieb bei einem zugelassenen HCC-Provider sowie die Integration des Dienstes in die vom HCC-Provider bereitgestellten (oder angebundenen) und von der gematik gesteuerten HCC-Basisdienste der TI, die sowohl den HCC-Dienst als auch die HCC-Infrastruktur zur Laufzeit den Governance-Prozessen der gematik unterstellen.

Abbildung 2: Governance - Deployment View

Die HCC-Basisdienste werden direkt in der Infrastruktur der HCC-Provider bereitgestellt, damit gleichzeitig die hohen Schutzbedarfe für die verarbeiteten Daten erfüllt und eine hohe Verfügbarkeit aller Schnittstellen innerhalb der Betriebsverantwortung des HCC-Providers erreicht werden.

HCC-Basisdienste sind die im Kapitel HCC Platform Services definierten Dienste zur Verwaltung der HCC-Infrastruktur.

Um die HCC-Basisdienste hoheitlich steuern zu können, stellt der HCC-Provider der gematik einen spezifischen Mandantenkontext oder einen Plattformzugang zur Verfügung in dem die HCC-Basisdienste verwaltet werden. Die (sicherheits-) funktionalen Schnittstellen der HCC-Basisdienste müssen für HCC-Dienste der (Fach-)Dienstanbieter erreichbar sein.

Alle dargestellten Beziehungen und die zugehörigen Konfigurationen werden über die TI-Policy definiert und zur Laufzeit automatisiert um- und durchgesetzt. Die TI-Policy wird dazu, falls erforderlich, auf Schnittstellen des Cloud Management Systems des HCC-Providers abgebildet, d. h. verteilt und ggf. vorher übersetzt.

6.5 Integration mit Diensten außerhalb von HCC

Während die Bereitstellung von generischer Infrastruktur durch HCC-Provider die Verfügbarkeit von Ressourcen zur Verarbeitung besonders vertraulicher Gesundheitsdaten sicherstellt und standardisiert, gibt es angrenzende Bedarfe für IT-Infrastruktur und Lösungen, die nicht auf dieses spezifische Vertrauensniveau angewiesen sind, aber in der Cloud betrieben werden.

Diese Bedarfe können seitens der Akteure flexibel über einen Mix aus Cloud-Angeboten, anwendungsspezifischen Managed Services und On-Premises Systemen aufgebaut werden und mit HCC-Diensten integriert werden, soweit dies datenschutzrechtlich zulässig ist und keine Verletzung von Sicherheitsanforderungen bzgl. der in HCC verarbeiteten Daten impliziert. Hierbei müssen alle Kommunikationspartner der HCC-Dienste mindestens authentifiziert werden können.

Beispiele sind Entwicklungs- und Testplattformen, Verwaltungswerkzeuge, Primärsysteme der Leistungserbringer und Systeme der Kostenträger, die in der Hoheit anderer Akteure im Gesundheitswesen liegen sowie Dienste, die keine personenbezogenen Daten verarbeiten. Auch Bestandssysteme verschiedenster Art, die weder nach den Prinzipien des Confidential Computing noch als Cloud-Lösungen entwickelt worden sind, müssen eingebunden werden können.

Die Integration von HCC-Diensten mit diesen anderen Diensten erfolgt über Gateway-Funktionen beim HCC-Provider, die neben der Datenverkehrssteuerung auch eine erste Stufe des Ausschlusses von unbekannten externen Verbindungspartnern umsetzen. Die Verwendung solcher Gateways im Kontext eines HCC-Dienstes setzt damit Konfigurationseinstellungen auf Policy- und Netzwerkebene voraus. Diese Konfigurationseinstellungen sollen im Mandantenkontext angesiedelt sein.

Abbildung 3: Integration von HCC-Diensten mit TI-Diensten und externen Diensten

7 Sicherheitsarchitektur von HCC

HCC ist eine Sicherheitsarchitektur für den Betrieb von Diensten im Rechenzentrum, die konsequent nach den Prinzipien von Security by Design aufgebaut ist. Sie hat zum Ziel, neben allen weiteren Unberechtigten, auch den Betreiber der physischen Infrastruktur mit technischen Mitteln daran zu hindern, auf die verarbeiteten Klartextdaten oder auf laufende Verarbeitungsprozesse zuzugreifen.

Die Sicherheitsarchitektur von HCC ist eingebettet in die umfangreichen baulichen, technischen, personellen und prozeduralen Sicherheitsmaßnahmen, die für größere Rechenzentrumsinfrastrukturen ohnehin üblich und durch ihre gutachterlich bestätigte Konformität mit geeigneten Normen abgesichert sind. Ein entsprechendes betriebliches Umfeld wird vorausgesetzt (siehe Kapitel 9 Zulassungen und Bestätigungen). 

Die Sicherheitsarchitektur von HCC beschreibt daher primär den Aufbau und die Komponenten, die innerhalb der Rechenzentrumsumgebung das substanziell oberhalb einer üblichen Zertifizierung liegende Schutzniveau abbilden, welches für die Klartextdatenverarbeitung von personenbezogenen medizinischen Daten erforderlich ist. Entscheidend für dieses höhere Schutzniveau sind die technischen Mechanismen von Confidential Computing und die Einbeziehung der gematik als vom Betreiber unabhängige Stelle in diese Mechanismen.

HCC stellt einen Sonderfall von Confidential Computing in der Cloud dar, da Confidential Cloud Computing i. A. keinen unabhängigen Dritten (hier die gematik) als technisch in die Laufzeitumgebung integrierten Garanten für die Sicherheits- und Privacy-Eigenschaften und keinen technischen Ausschluss des Anwendungsbetreibers von der Datenverarbeitung vorsieht. Vergleichbare Konstellationen könnten jedoch auch für andere Anwendungsbereiche mit staatlicher Aufsicht und hohem Schutzbedarf entstehen.

Abbildung 4: gematik als Garant für HCC

In den folgenden Unterkapiteln wird die Sicherheitsarchitektur von HCC dargestellt und begründet.

7.1 Trennung zwischen Designtime und Runtime

Der Gesamtaufbau des Systems trennt die zur Laufzeit der Basis- und Anwendungsdienste erforderlichen Komponenten und Artefakte (beim HCC-Provider) von den Designtime-Systemen zur organisatorischen Handhabung und Bereitstellung dieser Artefakte. Dadurch wird die Komplexität der Steuerung von HCC aus der Laufzeitumgebung so weit wie möglich herausgehalten und die Angriffsfläche der Laufzeitumgebung minimiert.

Die Verbindung zwischen Designtime und Runtime wird mittels Signierung der zur Laufzeit benötigten Artefakte in der Designtime erreicht.

Ein TI Design & Configuration Repository in dem ggf. komplexe organisatorische Abläufe umgesetzt werden müssen, um die Qualität der bereitgestellten Artefakte und bspw. eine Umsetzung des Mehraugenprinzips sicherstellen zu können, liefert die zur Laufzeit benötigten Artefakte in signierter Form.

Artefakte werden als Endresultat so weit wie möglich automatisierter Prüfprozesse signiert – durch Sign-off seitens autorisierter Akteure oder durch vertrauenswürdige Dienste der Plattform automatisiert. Vertrauenswürdige Dienste werden genutzt, wenn Artefakte als Ergebnis automatisierter Verarbeitungs- und Prüfprozesse entstehen (z. B. im TI Verification & Build Service) oder wenn eine Vielzahl verschiedener Akteure an den Prozessen in den Designtime-Systemen beteiligt ist und deren Signaturen zur Vereinfachung auf wenige in der Laufzeitumgebung zu prüfende Signaturen reduziert werden müssen.

Dienstsoftware soll zunächst unabhängig von den spezifischen Confidential Computing Implementierungen der HCC-Provider entwickelt und in einem zweiten Schritt für die Ausführung bei einem HCC-Provider vorbereitet werden können. Jeder HCC-Provider stellt dazu einen Trust Domain Build Service bereit (bzw. ein Plug-in für eine Build Pipeline der gematik, wie in 3.4 Standardisierung des Confidential Computing Ansatzes dargestellt), der die Umwandlung durchführt, die umgewandelten Artefakte zurückliefert (und ggf. signiert) und gleichzeitig die Referenzwerte für die Attestation ermittelt. Der Vorgang soll automatisiert durchgeführt werden können, aber zu Test- und Prüfzwecken auch manuell angestoßen werden können.

Ein Trust Domain Deployment Repository je HCC-Provider nimmt die fertigen Artefakte aus dem TI Verification & Build Service auf. Jede Laufzeitumgebung bzw. jeder Standort eines HCC-Providers, enthält eine für die dort verfügbaren Anwendungen vollständige Replik des Deployment Repositories, um zeitlich begrenzte Unterbrechungen in der Verfügbarkeit der Designtime-Systeme überbrücken zu können.

Abbildung 5: Designtime- und Runtime-Umgebung

Die Trennung von Runtime und Designtime wird auch auf der betrieblichen Ebene der Designtime-Services umgesetzt. Die Designtime-Services benötigen eine Laufzeitumgebung, die die gematik z. B. bei einem HCC-Provider beziehen kann. Confidential Computing wird für den TI Verification & Build Service benötigt, da dieser Prozesse zur automatisierten Erzeugung von geprüften Artefakten und zur automatisierten Signierung bereitstellt. Für Designtime-Services ist ein gesonderter Mandantenkontext der gematik – neben dem Kontext für den Betrieb der Trust Domain Runtime-Services – erforderlich.

7.2 Attestation des Sicherheitszustands

Basis für die Erreichung der Sicherheitsziele von HCC ist ein wohldefinierter Soll-Zustand und eine stets aktuelle und gegen den Soll-Zustand validierte Erfassung des Ist-Zustands aller Systeme in der Trusted Computing Base.

Die Definition des Soll-Zustands ist durch Referenzwerte der geprüften technischen Artefakte (Software-Pakete, Konfigurationsdatensätze) und durch Attribute von registrierten Komponenten in der Betriebsumgebung (Server-Typ, Betriebszustand, Signaturschlüssel, etc.) gegeben.

Die Funktionen zur Erfassung des Ist-Zustands, zum Abgleich mit dem Soll-Zustand sowie zur Aufnahme von Diensten in die HCC Trust Domain wird in den Infrastrukturen der HCC-Provider jeweils durch einen Attestations- und Konfigurationsdienst (Trust Domain Configuration & Attestation Service, TDCAS) übernommen.

Da die Attestation auf Mechanismen der Hardware und Software aufbaut, die von den seitens des Anbieters verwendeten Systemkomponenten abhängen, ist der TDCAS anbieterspezifisch umgesetzt. HCC-Provider können ihre HCC-Stacks auf der Basis der Technologien Intel TDX, AMD SEV-SNP, ARM CCA, IBM Z und äquivalenten zukünftigen Technologien aufbauen, da diese Technologien sowohl die Speicherverschlüsselung als auch die Attestation der HCC-Workloads (cVMs) unterstützen. Hinzu kommt eine Attestation der HCC-Hosts (Hardware, Firmware, Hypervisor, Host-Services) mittels TPM oder einem anderen Verfahren, das einen vom HCC-Provider unabhängigen Vertrauensanker in Hardware und eine Messung mittels Komponenten der TCB bieten. Beide Ebenen der Attestation müssen miteinander integriert sein, um sicherzustellen, dass attestierte Workloads auf attestierten Hosts laufen.

Der TDCAS wird der gematik vom HCC-Provider zur Verfügung gestellt, von HCC-Provider und gematik gemeinsam in Betrieb genommen und dabei mit dem Vertrauensanker im HSM-Cluster verbunden.

In der Konfigurationsdatenbank des TDCAS sind stets die HCC-Hosts bzw. ihre Signer Identities, die aktuell zugelassenen Versionen aller zur TCB gehörenden Software-Komponenten und Konfigurationen sowie weitere Daten registriert. Die Konfigurationsdatenbank bildet den Soll-Zustand ab und wird über administrative Prozesse gefüllt, die in der Designtime-Umgebung liegen.

Die Attestation erfolgt in zwei Stufen:

1. Attestation des Hosts inkl. Firmware und Hypervisor und
2. Attestation je gestarteter Workload.

Für jeden für den HCC-Vertrauensraum gestarteten Host wird mittels TPM und Secure Boot Attestationsfähigkeit erreicht. Der Hypervisor bzw. ein damit gestarteter Dienst ist für den Abruf und die Weitergabe der signierten PCR-Werte aus dem TPM zuständig. Der Hypervisor muss sicherstellen, dass Workloads, die nicht aus dem HCC-Vertrauensraum stammen, auf HCC-Hosts nicht gestartet werden können.

Für jede HCC-Dienstinstanz wird das Speicherabbild gemessen, während sie als Confidential VM gestartet wird. Anschließend ruft sie einen lokalen Attestation Report ab, der von der Hardware und Firmware der CPU des registrierten HCC-Hosts produziert und mit einem in der Hardware verankertem Schlüssel signiert ist. Der Report enthält auch die für Confidential Computing notwendigen Angaben zur Konfiguration des Hosts bzw. der CPU.

Der Signer Key in der CPU sowie der Signer Key des TPM müssen von HCC-Provider-unabhängigen Hardware-Herstellern stammen, um sie jedem Einfluss seitens des HCC-Providers zu entziehen.

Eine Kombination der Attestation Reports aus CPU und TPM wird als Nachweis über einen bestimmungsgemäßen Betriebszustand an den lokalen TDCAS übermittelt und vom TDCAS gegen seine Konfigurationsdatenbank geprüft. Die Konfigurationsdatenbank des TDCAS enthält dazu neben den Referenzwerten die Hardware-Signer-Identitäten aller beim HCC-Provider in der jeweiligen Location für die potenzielle Nutzung für HCC registrierten Server. Damit kann der TDCAS die Signaturen der Attestation Reports prüfen und damit gleichzeitig feststellen, dass es sich um Server in der sicheren Betriebsumgebung handelt.

Die Attestation auf der Grundlage der kombinierten Reports auf Ebene der cVM und der Host-Software kann auf verschiedene Arten umgesetzt sein, muss aber sicherstellen, dass beide signierte Reports "fresh" sind und von demselben Host stammen (inkl. Abwehr von z. B. "Kuckucksangriffen").

Die Datenbank des TDCAS enthält die Signer-Identität des TI Verification & Build Service, so dass der TDCAS die Authentizität der Konfigurationseinträge stets selbst prüfen kann. Im einfachsten Fall sind alle Registrierungseinträge von nur einer Service-Identität signiert, die als Teil des TI Verification & Build Service den Übergang der Einträge von der Designtime- in die Runtime-Umgebungen automatisiert.

Erst im Anschluss an eine erfolgreiche Verifikation der Attestation Reports durch den TDCAS wird ein HCC-Dienst in den HCC-Vertrauensraum aufgenommen. Hierzu werden der HCC-Dienstinstanz vom TDCAS Credentials zum Zugriff auf den privaten Schlüssel für die TLS-Identität (X.509-Zertifikat) des HCC-Dienstes und ggf. auf weiteres benötigtes Schlüsselmaterial im HSM-Cluster übermittelt. Kurzlebige Zertifikate bzw. Schlüssel können auch direkt in den Verarbeitungskontext des HCC-Dienstes eingebracht werden. Die konkreten Vorgaben hierzu liefert die Spezifikation des HCC-Dienstes.

Der TDCAS erzeugt über jeden Attestationsvorgang einen kryptographisch gegen Veränderungen geschützten Log-Eintrag.

Der TDCAS kann gegenüber den HCC-Diensten als Sub-CA der PKI der TI arbeiten und dann dienstspezifische Zertifikate ausstellen, die mit seinem Sub-CA-Zertifikat signiert sind. Damit eröffnen sich Möglichkeiten für:

• Dienstzertifikate mit kurzer Laufzeit
• Das Setzen eines erweiterten Attributs im Dienstzertifikat, dass eine Referenz auf den Log-Eintrag des spezifischen Attestationsvorgangs darstellt. Clients können eine Funktion zur Interpretation der Referenz als URL sowie zum Abruf und zur Anzeige des Log-Eintrags implementieren.

Die Konfigurationsdatenbank des TDCAS wird durch den TDCAS selbst verwaltet und ist mittels Signaturen und Hardware-basierten Sicherheitsfunktionen der TDCAS-Hosts gegen Manipulationen (z. B. Veränderungen an Datenbankdateien, Laden einer ungültigen Datenbank) und gegen Rollback geschützt, z. B. mittels monotoner Versionszähler.

Der TDCAS ist mit dem HCC-Vertrauensanker der TI beim HCC-Provider kryptographisch verknüpft. Über diese Verknüpfung wird auch seine Identität abgesichert und seine Authentisierung gegenüber dem HCC-Vertrauensanker ermöglicht.

Der HCC-Vertrauensanker besteht aus einem unter Einbeziehung der gematik und ggf. weiterer Akteure zeremoniell administrierten HSM-Cluster. Um auch die initiale Zeremonie remote durchführen zu können – eine Möglichkeit, die insbesondere für Cloud-Provider relevant ist – sollten die HSMs Key Attestation unterstützen. Damit kann in der Zeremonie auch ohne physischen Zugang überprüft werden, dass die Erzeugung des Schlüsselmaterials tatsächlich in einem HSM stattfindet.

Während des Betriebs der HCC-Service-Instanzen können weitere Mechanismen zum Schutz der Integrität der attestierten Systeme eingesetzt werden, bspw. die Linux Integrity Measurement Architecture.

Der Hardware-geschützte Signer-Schlüssel für die Workload-Attestation ist in die CPU integriert, für die Host-Attestation in ein TPM. In der Kombination können diese Schlüssel die Anforderung zur Erfassung des gesamten CC-Stacks umsetzen.

Die folgende Abbildung zeigt ein vereinfachtes Beispiel einer kombinierten Attestation auf Basis von Intel TGX und einem TPM:

Abbildung 6: Attestation beispielhaft, vereinfacht

Die genaue Ausgestaltung der Attestation durch die HCC-Provider ist system- und technologiespezifisch und wird in der vorliegenden Spezifikation daher nicht weiter im Detail standardisiert. Ein Standard könnte jedoch im Zuge internationaler Strukturen, wie dem Confidential Computing Consortium oder der IETF, entstehen und längerfristig für die TI adaptiert werden.

Als wichtigste Anforderung an jede Umsetzung der Attestation wird nur gefordert, dass die Attestation den Sicherheitszustand der TCB vollständig abbilden muss. Hierbei ist die Annahme zulässig, dass gut gehärtete Komponenten ihren Sicherheitszustand erhalten, nachdem sie korrekt gestartet und attestiert wurden. Die Anforderungen an den Nachweis einer entsprechenden Härtung können jedoch hoch sein. Im Ergebnis werden Mechanismen zur kontinuierlichen bzw. häufig wiederholten Attestation nicht zwingend gefordert.

Für alle außerhalb der Confidential VMs laufenden Software-Komponenten der HCC-Host-Plattform – wie Firmware, Hypervisor, Betriebssystem und Provisionierungskomponenten – muss nachgewiesen sein, dass diese Komponenten keine Angriffe aus dem Bertriebsumfeld auf die Confidential VMs ermöglichen und dass nur entsprechend geprüfte Software-Komponenten laufen können.

Die Attestation der Host-Plattform außerhalb der cVMs dient primär dem Integritätsschutz der HCC-Hosts. Dieser ist erforderlich, da cVMs keinen perfekten Schutz vor Angriffen bieten, falls es einem Angreifer (Innentäter aus dem betrieblichen Umfeld) gelingt, spezifischen Angriffs-Code auf dem Host einzuschleusen, der die in cVMs laufenden Verarbeitungen über Seitenkanäle angreift. Der TPM-basierte Attestationsreport wird in die Attestation cVMs eingebettet oder anderweitig kryptographisch sicher verknüpft in das Attestationsschema eingebunden.

TPM-basierte Attestation wird in Verbindung mit einer organisatorischen Trennung innerhalb der Organisation des HCC-Providers – zwischen Verantwortlichen für den physischen Betrieb der Hosts einerseits und Verantwortlichen für die Bereitstellung der Host-Software andererseits – dazu genutzt, um das Angriffspotential von Innentätern zu reduzieren. Die Referenzwerte für das TI-Design & Configuration Repository werden von der verantwortlichen Stelle für die Bereitstellung der Software-Komponenten mittels einer in der HCC-Trust-Domain registrierten Identität signiert übermittelt.

Um die attestierte Integrität der Betriebssystemumgebung über den gesamten Boot-Zyklus eines Hosts zu erhalten, muss die Host-Plattform so aufgebaut sein, dass sie nicht aus betrieblichen Gründen während der Laufzeit verändert werden muss.

Wenn ein neuer HCC-Host ins Rechenzentrum eingebracht wird, müssen die Signaturschlüssel seines TPMs und seiner CPU im TI-Design & Configuration Repository registriert werden, damit diese nachfolgend vom TDCAS erkannt werden können. Darüber hinaus muss die Attestation gegenüber dem Hardware-Hersteller durchgeführt werden, z. B., um zu bestätigen, dass es sich um eine originale CPU des Herstellers handelt. So weit wie möglich sollen auch Daten zur Lieferkette und zum Prozess der Einbringung des Servers in die Umgebung erfasst werden (z. B. im Rahmen des regulären Asset Managements). Diese Daten werden, ggf. auszugsweise, zusammen mit einer eindeutigen Host-ID und ggf. weiteren Daten an das TI-Design & Configuration Repository übermittelt und ggf. im Rahmen von Audits verwendet.

Für HCC-Hosts wird auf der Grundlage ihrer Registrierung angenommen, dass sie sich in der gegen physische Eingriffe geschützten Betriebsumgebung des HCC-Providers befinden. Der HCC-Provider muss mit organisatorischen Mitteln das Einbringen manipulierter Einträge verhindern. Dies bedeutet insbesondere, dass es ausgeschlossen sein muss, Server zu registrieren, die sich außerhalb der geschützten Betriebsumgebung des HCC-Providers befinden.

7.3 Bootstrapping der technischen Sicherheitsarchitektur

Die technischen Mittel zur Abwehr von Innentätern müssen derart gestaltet sein, dass sie die HCC-Plattform während des Betriebs zur autonomen Aufrechterhaltung ihrer Sicherheitsgarantien in die Lage versetzen. Sie müssen die HCC-Plattform daher mit der Fähigkeit zur Introspektion und Attestation ihres Sicherheitszustands ausstatten. Die TCB muss sowohl möglichst klein als auch möglichst transparent gehalten sein. Sämtliche Mechanismen müssen auf wirksamen kryptographischen Verfahren in Kombination mit physischen Schutzmaßnahmen und mit Rollentrennung aufbauen. Alle Prozesse zur Umsetzung, zum Rollout und zur Veränderung der TCB müssen damit selbstevident aufgebaut sein und für alle kritischen Änderungen ein Zusammenwirken geeigneter unabhängiger Akteure erfordern.

Den Ausgangspunkt für die kryptographische Absicherung der Prozesse bildet der HCC Root of Trust, ein privater Schlüssel in einem HSM-Cluster beim HCC-Provider. Dieser gewinnt seine Legitimität im Rahmen einer Initialisierungszeremonie, an der hinreichend viele, geeignete und voneinander unabhängige Akteure inkl. der gematik beteiligt sind. Dieser organisatorische Rahmen ist noch zu definieren. Die initiale Zeremonie wird einmal pro HCC-Anbieter durchgeführt und für Dritte nachprüfbar protokolliert. Das Zertifikat des HCC Root of Trust wird von einer hoheitlichen PKI der TI abgeleitet. Die Replikation des Root of Trust auf HSM-Cluster an anderen Standorten wird innerhalb der Zeremonie vorbereitet und nutzt die Mechanismen der verwendeten HSMs oder auch spezifisch dafür entwickelter, gehärteter Erweiterungssoftware.

Die Zeremonie zur Instanziierung eines HCC-Anbieters und seiner Infrastruktur ist darauf ausgelegt, nachfolgende administrative Aktivitäten lückenlos als kryptographisch gesicherte (delegierte) Fortsetzungen der Zeremonie abzubilden. Dies bedeutet insbesondere, dass die im Anschluss erforderliche Bereitstellung von Schlüsselmaterial, Zertifikaten, Softwarekomponenten, Konfigurationen und Policies für den Betrieb von Plattform- und Fachdiensten nicht dem Anbieter der Infrastruktur allein überantwortet und nur mittels organisatorischer Vorgaben abgesichert wird, sondern dass ein Mehraugenprinzip systematisch als kryptographisch gesicherte Kette von Delegationen als Teil der Plattform umgesetzt wird. Hierzu ist es notwendig, bereits in der Zeremonie die administrativen Möglichkeiten über die des HSM-Clusters hinaus zu erweitern.

Daher wird in der Zeremonie bereits der TDCAS initialisiert, d. h. mit seinem kryptographischen Credential zur Anmeldung am HSM-Cluster ausgestattet und auf diese Weise an den Root of Trust gebunden (Pairing). Wie im Abschnitt 7.2 Attestation des Sicherheitszustands dargestellt, verbindet der TDCAS den Sollzustand des Systems mit den während der Instanziierung von Services gemessenen Istzuständen. Für den sicheren Import der Referenzwerte für den Sollzustand in die Konfigurationsdatenbank muss der TDCAS ihren Signer kryptographisch prüfen können. Der TDCAS wird also bereits in der Zeremonie z. B. mit dem Signer-Zertifikat des TI Verification & Build Service konfiguriert.

7.4 Umfang und Grenzen der Initialisierungszeremonie

Innerhalb der Initialisierungszeremonie für den Root of Trust muss das System genau so weit initialisiert, konfiguriert und mit Identitäten ausgestattet werden, dass im Anschluss Erweiterungen durch verteilt arbeitende Akteure auch von außerhalb der Rechenzentrumsumgebung auf der Grundlage der registrierten Identitäten umgesetzt werden können.

Bei den Erweiterungen bzw. Änderungen handelt es sich um:

• die Registrierung oder Deregistrierung von HCC-Dienstanbietern und HCC-Diensten unter der Aufsicht der gematik,
• die Registrierung oder Deregistrierung von Software-Komponenten zur funktionalen Erweiterung der Plattform,
• die Registrierung oder Deregistrierung von HCC-Hosts und ggf. von anderen Komponenten der TCB. Sie erfolgt durch den HCC-Provider im Zuge der Einbringung solcher Komponenten in die Rechenzentrumsumgebung und mittels abgesicherter Prozesse sowie
• die Registrierung oder Deregistrierung administrativer Identitäten, Rollen und Zuordnungen.

Mit jeder Art von Erweiterung sind Akteure bzw. Rollen verbunden, die als Signer der jeweiligen Registrierungseinträge autorisiert werden müssen. Auch diese (Meta-)Ebene der Autorisierung wird mittels signierter Einträge im Policy Administration System für HCC (als Teil des TI Design & Configuration Repositories) realisiert.

7.5 HCC Plattform Services

Im Folgenden werden die Dienste der HCC-Plattform dargestellt, die für die Bereitstellung der Software- und Konfigurationsartefakte der TCB von HCC sowie für die Instanziierung der HCC-Services benötigt werden. Sie stellen im Verbund sicher, dass nur gültig autorisierte und konfigurierte Software auf HCC-Hosts ausgeführt wird.

Aus logischer Sicht könnten alle Änderungen an der HCC-Plattform über ein einziges Repository gesteuert werden. Dies erscheint jedoch weder aus technischer noch aus betrieblicher oder organisatorischer Sicht sinnvoll. Daher werden die verschiedenen Arten der Erweiterung auf einen Satz von Basisdiensten verteilt. Diensttypen sind jeweils einem an der Bereitstellung der Plattform beteiligten Akteur zugeordnet. Wenn Diensttypen keinem Akteur zugeordnet sind, dann sind sie oder ihre Inhalte durch die Inhalte anderer Dienste vollständig definiert. Die Dienste sind entweder der HCC-Runtime oder der HCC-Designtime zugeordnet.

HCC Runtime Services sind Teil jeder Laufzeitumgebung, d. h. sie werden in jeder Rechenzentrums-Location instanziiert, um die Verfügbarkeit aller weiteren Dienste abzusichern. Sie werden vom HCC-Provider als Teil seines HCC-Angebots bereitgestellt. Ihre Bereitstellungs- und Betriebskosten werden nutzungsbezogen durch die HCC-Mandanten getragen, auch wenn sie aus Gründen der Governance in einem der gematik zugeordneten Mandantenkontext betrieben werden.

HCC Designtime Services sind einmalige Dienste zur Steuerung administrativer Prozesse der HCC-Plattform. Sie können im Auftrag der gematik bei einem der HCC-Provider betrieben werden. Änderungen, die sich auf die Laufzeitumgebungen beziehen, müssen ausgehend von diesen Systemen auf die Runtime Services verteilt werden.

Die folgende Abbildung liefert einen Überblick über die Services, ihre Zuordnung zur Runtime bzw. zur Designtime sowie die wichtigsten Beziehungen zwischen den Services:

Abbildung 7: HCC-Services in Designtime- und Runtime-Umgebung

7.5.1 HSM-Cluster (Runtime)

Der Vertrauensanker für HCC in der jeweiligen Infrastruktur eines HCC-Providers liegt in einem standortübergreifend synchronisierten HSM-Cluster mit mehreren HSM-Appliances pro Location. Er ist Basis des HSM-Service für HCC, der neben dem Vertrauensanker weitere kryptographische Operationen bereitstellt.

Der HSM-Cluster kann Funktionen für Trust Domains außerhalb von HCC oder der TI übernehmen, solange eine Partitionierung sicherstellt, dass der HSM-Service für HCC exklusiv unter der HCC-Governance liegt.

Der HSM-Service wird für die Verwaltung des Vertrauensankers und weiteren Schlüsselmaterials im Kontext der HCC-Plattform oder der HCC-Dienste genutzt. Der Zugriff auf den Cluster durch eine HCC-Dienstinstanz erfolgt immer lokal innerhalb des Rechenzentrums, in dem sie läuft. 

Um die Vertrauenskette auch remote bis auf den Vertrauensanker zurückverfolgen zu können, sollen HSMs eingesetzt werden, die Key Attestation für die im HSM-Cluster verwalteten asymmetrischen Schlüssel unterstützten. Hiermit wird insbesondere auch nachvollziehbar, dass die Verwaltung der wichtigsten Schlüssel der Einflussnahme durch den HCC-Provider entzogen ist, da der Vertrauensanker für die Key Attestation beim unabhängigen Hersteller der HSMs liegt.

Die Nutzung des HSM-Clusters durch HCC-Dienste wird z. B. mittels einer Client-Library zur Integration in das Workload-Image realisiert. HCC-Diensthersteller müssen solche Client-Libraries in ihre Workloads integrieren können (operativ und rechtlich). Alternativ kann ein separat als HCC-Dienst betriebener HSM-Proxy zum Einsatz kommen, der es ermöglicht, HCC-Dienste ohne Integration einer ggf. vom HSM-Hersteller abhängigen Client-Library zu entwickeln und der gleichzeitig eine Abstraktion über herstellerspezifische funktionale Merkmale von HSMs bieten kann.

7.5.2 Trust Domain Configuration & Attestation Service (Runtime)

Während der Root of Trust HSM-Cluster mit den im Rahmen der Zeremonie initialisierten und personalisierten Smartcards der HSM-Administratoren den ersten Ring der TCB bildet, stellt der Trust Domain Configuration & Attestation Service (TDCAS) den zweiten Ring dar. Seine Initialisierung und das Pairing mit dem HSM-Cluster bilden den zweiten Schritt im Bootstrapping des Vertrauensraums.

Das Pairing des TDCAS mit dem Root of Trust basiert auf der Einrichtung von Credentials in den TDCAS auf dedizierten TDCAS-Hosts.TDCAS-Hosts können damit eine Untergruppe der HCC-Hosts darstellen, aber auch als HSMs mit TDCAS-Funktionalität ausgeführt sein. Der TDCAS wird als Confidential Service ausgeführt. Die Credentials werden als Sealed Secrets, d. h. mittels eines in der Hardware verankerten Schlüssels verschlüsselt, durch den TDCAS gespeichert, so dass sie nach einem Neustart des TDCAS-Hosts und des TDCAS-Dienstes wieder verfügbar sind. Das Sealing berücksichtigt die Werte aus dem Measured Boot Process, so dass die Credentials nur dann wiederhergestellt werden können, wenn dieselbe Software auf demselben Host gestartet wurde. Key Rolling und Update der Software werden durch einen darauf aufbauenden Mechanismus unterstützt.

Bei den auf diese Weise in den TDCAS eingebrachten Credentials handelt es sich in erster Linie um Authentisierungsschlüssel für den HSM-Cluster bzw. für dort eingerichtete Rollen. Je nach genauer Ausgestaltung des Aufbaus des Vertrauensraums kann jedoch auch Schlüsselmaterial dazugehören, das es dem TDCAS ermöglicht, Credentials für den HSM-Zugriff für andere Dienste zu generieren.

Zu den für den Attestationsdienst notwendigen Konfigurationsdaten gehören das Sub-CA-Zertifikat für die Ausstellung der HCC-Dienstidentitäten sowie die kryptographische Identität des vom TI Verification & Build Service verwendeten Signers der vom TDCAS benötigten Attestations-Referenzdaten zur Prüfung der Authentizität dieser Daten. Das Schlüsselpaar des Sub-CA-Zertifikats wird während der Zeremonie im HSM-Cluster erzeugt, von einer Sub-CA der Komponenten-PKI der TI zertifiziert und dem TDCAS zugänglich gemacht. Das Zertifikat des TI Verification & Build Service wird während der Zeremonie eingebracht. Die Gesamtheit der für die Zeremonie erforderlichen Zuordnungen von Signer- und Service-Identitäten zu Autorisierungen bilden die initiale Policy der HCC-Plattform für den HCC-Provider.

Der TDCAS und Repliken seiner Konfigurationsdatenbank werden in alle Rechenzentrumsstandorte des HCC-Providers verteilt. Der TDCAS in einer Location kann nur HCC-Workloads in derselben Location attestieren.

Je nach eingesetztem CC-Stack kann die spätere Attestation der HCC-Dienste verschiedene Formen annehmen. Im Beispiel der Nutzung von Intel TDX in Kombination mit einem TPM werden folgende Schritte durchlaufen:

• Der TDCAS wird von jedem HCC-Host zunächst nach Beendigung der Bootphase kontaktiert. Er erhält die vom TPM des Hosts signierten Werte aus dem Measured Boot Process und prüft diese gegen registrierte Referenzwerte in seiner Konfigurationsdatenbank (die aus dem TI Design & Configuration Repository stammen und ggf. auch aus der Host Registry des HCC-Providers), um festzustellen, ob der Host mit zulässiger Firmware und einem zulässigen Boot Image inkl. aller für den Betrieb als cVM-Runtime erforderlichen Software-Komponenten gestartet wurde.
• Wenn das der Fall ist, wird angenommen, dass weiteres Laden von Software-Komponenten, z. B. das Laden der cVM-Images, von einer bekannten und vertrauenswürdigen Software-Komponente auf dem Host ausgeführt wird, so dass nur korrekt signierte cVMs gestartet werden. Hierdurch wird sichergestellt, dass auf HCC-Hosts keine unbekannte Software gestartet werden kann.
• Downgrade-Angriffe werden mit der nächsten Stufe, der Attestation, abgewehrt. In dieser Stufe kontaktiert jeder HCC-Dienst nach seinem Start den TDCAS erneut, um die vom registrierten TDX-Signer-Key des Hosts der cVM signierten Attestation Reports gegen Referenzwerte für cVMs prüfen zu lassen. Im Erfolgsfall provisioniert der TDCAS die Service-Identitäten für die cVM bzw. die Access Credentials für die entsprechenden Funktionsaufrufe im HSM-Cluster. Hierbei handelt es sich um das HCC-interne TLS-Zertifikat für die Service-to-Service Kommunikation sowie, falls der Service aus dem Internet erreichbar ist, ein TLS-Zertifikat aus einer öffentlichen CA. Mit dem HCC-internen TLS-Zertifikat fungiert der TDCAS als Sub-CA einer hoheitlichen PKI der gematik für die Services von HCC.

Eine derzeit noch ungelöste Schwierigkeit für die Umsetzung des kombinierten Attestationsverfahrens für Host und cVMs auf dem Host besteht darin, dass die Virtualisierung mittels cVMs gerade verhindern soll, dass cVMs (genau wie normale VMs) die Spezifika der darunterliegenden Hardware-Plattform kennen müssen bzw. direkt ermitteln können. Bei einer möglichen Umsetzung mittels eines vom Hypervisor gestarteten Moduls mit lokaler Netwerkschnittstelle ergibt sich ein Angriffsszenario durch einen manipulierten Hypervisor, der Anfragen an das eigene TPM an einen anderen Host mit korrektem Hypervisor weiterreicht und der cVM mit dessen Rückgabewerten einen eigenen zulässigen Zustand bestätigt (Kuckucksangriff).

Es wird davon ausgegangen, dass sich eine geeignete Konstruktion mittels der Registrierung der individuellen Signer-Keys für die TPMs und die cVMs aller HCC-Hosts (genutzt durch den TDCAS) sowie mit geeigneter Ausgestaltung eines TPM-Attestierungsmoduls umsetzen lässt. Da diese Konstruktion jedoch eng mit den betrieblichen Gegebenheiten des jeweiligen HCC-Providers abgestimmt sein muss, wird hierfür derzeit keine technische Vorgabe gemacht. Eine Konkretisierung wird im Rahmen der ersten Umsetzungen bei HCC-Providern erfolgen.

Der TDCAS muss eine Schnittstelle für den Empfang von Konfigurationsdaten aus dem TI Verification & Build Service anbieten.

7.5.3 Key Management Service (Runtime)

Der Key Management Service (KMS) übermittelt verschlüsseltes Schlüsselmaterial zwischen HCC-Dienstinstanzen. Der mit der HCC-Plattform direkt verknüpfte Anwendungsfall ist die HCC-Host-individuelle Bereitstellung von dienst- bzw. anwendungsspezifischen Schlüsseln. Der KMS kann jedoch auch für weitere anwendungsspezifische Zwecke seitens der Workload-Hersteller genutzt werden.

Das vom KMS vorgehaltene und übermittelte Schlüsselmaterial ist für diesen selbst nicht zu entschlüsseln. Weil der KMS nur mit verschlüsseltem Schlüsselmaterial arbeitet, gehört er nicht zur TCB. Es muss trotzdem sichergestellt sein, dass (verschlüsseltes) Schlüsselmaterial nur innerhalb der für HCC qualifizierten Rechenzentrumsumgebungen verwaltet wird und diese nicht verlässt.

Workloads verwenden den KMS des HCC-Providers entweder mittels einer Remote-API oder mittels einer lokal eingebundenen Library. Eine Provider-übergreifende Standardisierung dieser Schnittstellen ist derzeit nicht vorgesehen.

7.5.4 Trust Domain Deployment Repository (Runtime)

Das Trust Domain Deployment Repository enthält die Binaries der Software-Komponenten für Core Services, Anwendungsdienste und Dienstkomponenten inkl. Konfigurationsschemata in signierter Form. Den Großteil dieser Artefakte bilden die Workload Images für HCC-Dienste. Die Software-Komponenten können in mehreren zum jeweiligen Zeitpunkt für den Einsatz freigegebenen Versionen vorliegen. Das Deployment Repository bietet Funktionalitäten für die Steuerung der Deployment-Lifecycles, z. B. für eine Revokation im Notfall.

Das Trust Domain Deployment Repository kann auch als Policy Hub dienen und dann alle für eine HCC-Umgebung benötigten Policies für die Zero Trust Komponenten und den TDCAS in der Laufzeitumgebung als signierte und gebündelte Artefakte bereitstellen. Es empfängt alle Änderungen an Policies vom Policy Administration Point der TI.

Das Trust Domain Deployment Repository gehört nicht zur TCB, da die Gültigkeit der Artefakte über Signaturen abgesichert wird. Es muss jedoch gegen unautorisierte Einträge geschützt sein, um seine Funktionsfähigkeit zu schützen und jederzeit den gültigen Stand der Deployment-Basis von HCC abzubilden. Es kann als Teil des Deployment Management Systems des HCC-Providers (HCC-Provider Deployment Repository) umgesetzt sein, muss dann jedoch eine prüfbare Abgrenzung zwischen Artefakten für den Vertrauensraum der TI und anderen Artefakten umsetzen, um den Schutz der Funktionsfähigkeit gewährleisten zu können und um HCC-spezifische Abfragen zu ermöglichen.

Das Trust Domain Deployment Repository hat Repliken an allen Rechenzentrumsstandorten des HCC-Providers, um ein performantes Deployment der Dienste ohne externe betriebliche Abhängigkeit zu ermöglichen. Nur die beim jeweiligen HCC-Provider nutzbaren Artefakte aus dem HCC-Gesamtportfolio der TI müssen in der jeweiligen (selektiven) Replik vorhanden sein.

Das Trust Domain Deployment Repository muss eine Schnittstelle für den TI Verification & Build Service bereitstellen, über die Deployment-Artefakte eingebracht werden können.

7.5.5 HCC-Provider Deployment Repository (Runtime)

Das HCC-Provider Deployment Repository ist der (logische) Teil des betrieblichen Steuerungssystems des HCC-Providers, der die Software-Komponenten und Konfigurationen zur Bereitstellung der HCC-Laufzeitumgebungen sowie die Registrierungsdaten für alle beim HCC-Provider eingesetzten HCC-Hosts umfasst. Es kann durch verschiedene Systeme des HCC-Providers realisiert sein, wird von ihm verwaltet und gehört nicht zur unmittelbaren TCB.

7.5.6 TI Policy Administration Point (Designtime)

Der TI Policy Administration Point stellt das Verwaltungssystem für die Policy des Vertrauensraums im Kontext der Zero Trust Architektur für HCC dar.

Der TI Policy Administration Point stellt alle Funktionalitäten zur Administration der Policy der HCC Trust Domain inkl. der Abgrenzung von Teilen der Policy, Delegation von Verantwortlichkeiten für die abgegrenzten Teile und integritätsgeschützter Änderungsverfolgung bereit. Er ist so strukturiert, dass er den an der Verwaltung der Policy beteiligten Akteuren ihre jeweilige Sicht auf die Policy ermöglicht und er unterstützt den Sign-off von Policies mittels Multi-Party-Signaturen, bspw. Threshold Signature Schemes.

Der TI Policy Administration Point enthält Registrierungsdaten für alle Identitäten menschlicher oder institutioneller Akteure oder Dienste, die an der Verwaltung der HCC Trust Domain beteiligt sind. Er enthält nicht die Registrierungsdaten der Endnutzeridentitäten der TI oder der an den fachlichen Prozessen der TI beteiligten Institutions- oder Organisationsidentitäten. Diese werden durch TI Identity Provider bereitgestellt und in Policies nur genutzt oder referenziert. Spezifisch für HCC bilden Policies auch die Identitäten der Hosts und Workloads (auf Basis ihrer gemessenen Hash-Werte) sowie deren Zugriff auf Schlüssel und Schnittstellen ab. Attribute based Access Control wird auf diese Weise auch auf die Steuerung des HCC-Vertrauensraums angewendet.

Der TI Policy Administration Point bietet die Administrationsfunktionalität für die Verwaltung der für HCC und Zero Trust benötigten Identitäten, Rollen und Zuordnungen, wird initial mit den Identitäten der an der Zeremonie teilnehmenden Personen sowie dem Root of Trust Public Key und den Public Keys der Core Services befüllt und bildet die Kette der Verantwortlichkeiten für jede Operation (z. B. Registrierung einer neuen Identität) dadurch ab, dass nur von registrierten und (via Policy) autorisierten Autoren und Reviewern signierte Einträge akzeptiert werden. Alle Veränderungen werden auditfähig versioniert.

Der TI Policy Administration Point ist ein Dienst der gematik. Er wird von der gematik verantwortet, entwickelt und weiterentwickelt. Er ist daher nicht Gegenstand der Zulassung von HCC-Providern, jedoch notwendig für das Verständnis und das Funktionieren der Sicherheitsarchitektur von HCC und daher hier dargestellt.

7.5.7 TI Design & Configuration Repository (Designtime)

Das TI Design & Configuration Repository enthält den Quellcode von Plattformdiensten und von Open Source Anwendungsdiensten inkl. Build Scripts, Revision Tags und Konfigurationsschemata für Software-Komponenten, die für Laufzeitumgebungen konfiguriert werden müssen, sowie weitere Software-Artefakte. Es enthält daneben auch binäre Artefakte, z. B. Dienst-Software, die unabhängig begutachtet und auf dieser Grundlage durch die gematik zugelassen wurden.

Das TI Design & Configuration Repository bietet Code Management Funktionalität inkl. Review und Sign-off im Mehraugenprinzip. Es basiert auf einer Git-Versionsverwaltung und bietet die Möglichkeit externe Quellen einzubinden. Commits, Tags und Imports sind nur mit Signatur eines in der Trust Domain registrierten und autorisierten „Importeurs“ gültig. Der „Importeur“ kann selbst ein Dienst sein. Auch Komponenten, die nur in binärer Form zur Verfügung stehen, werden über das Repository mittels autorisiertem (signiertem) Import registriert und damit verfügbar gemacht.

Das TI Design & Configuration Repository bildet, gemeinsam mit dem im folgenden Absatz dargestellten TI Verification & Build Service, die Grundlage für sichere Zulassungs- und ggf. auch Entwicklungsprozesse für HCC-Dienste. Die Entwicklungsprozesse waren bisher den Anbietern oder Herstellern von Diensten überlassen. Aufgrund der Shared Responsibility und des Charakters von HCC als Plattform sowie im Sinne der Open Source Strategie ist es notwendig, sichere (Teil-)Entwicklungsprozesse auch als Teil der Platform zu verankern. Sie werden zunächst in einem funktional wie organisatorisch einfachen Modell umgesetzt und später verfeinert und ausgebaut.

Das TI Design & Configuration Repository ist ein einmaliger Dienst der gematik. Es wird von der gematik verantwortet, entwickelt und weiterentwickelt. Es ist daher nicht Gegenstand der Zulassung von HCC-Providern, jedoch notwendig für das Verständnis und das Funktionieren der Sicherheitsarchitektur von HCC und daher hier dargestellt. Der Dienst selbst gehört nicht zur TCB, muss jedoch gegen unautorisierte Einträge geschützt sein, um seine Funktionsfähigkeit zu schützen und jederzeit den gültigen Stand der Code-Basis der HCC-Services abzubilden.

7.5.8 TI Verification & Build Service (Designtime)

Der TI Verification & Build Service besteht aus Build-Diensten, die Software-Artefakte aus dem TI Design & Configuration Repository und dem TI Policy Administration Point verifizieren, bauen und als signierte Container Images, Binaries, Konfigurationsdateien oder Policy Sets in die Trust Domain Deployment Repositories und die Trust Domain Configuration & Attestation Services verteilen. Builds führen über die eingeflossenen Quellen Buch und sind im besten Fall (Bit für Bit) reproduzierbar. Quelldateien werden vor der Verwendung auf valide Signaturen von für das jeweilige Artefakt autorisierten Identitäten geprüft.

Im Zuge des Builds werden Verfahren zur automatisierten Prüfung und Verifikation der Quellen eingesetzt. Prüf- und Verifikationscode wird selbst als Quelle interpretiert. Es kommen für die verwendeten Sprachen relevante Compiler, Checker und Build-Tools zum Einsatz. Der TI Verification & Build Service besteht daher aus einer Mehrzahl von Services, die in ihrer Gesamtheit und im Zusammenspiel das Build System der Plattform darstellen. Damit sind auch die Provider-spezifischen Trust Domain Build Services (siehe 7.5.9 Trust Domain Build Service (Designtime)) Teil des TI Verification & Build Service.

Referenzwerte für Binaries und Konfigurationen werden durch den Build Service (bzw. durch eingebundene Trust Domain Build Services) in einer Form erzeugt, die für den Abgleich mit den Messwerten während des Starts der jeweiligen Dienste geeignet sind. Dazu werden die Measured Boot Hash-Werte z. B. durch Instanziierung in einer vertrauenswürdigen Mess-cVM und Erzeugung des Attestation Reports (oder mittels eines anderen geeigneten Tools zur Bestimmung derselben Werte) ermittelt und anschließend signiert.

Der TI Verification & Build Service ist ein einmaliger Dienst in der Verantwortung der gematik. Der Dienst gehört zur TCB. Er erfordert daher eine Begutachtung durch eine qualifizierte und unabhängige Stelle. Er wird als Confidential Service mit einer Signer-Identität betrieben, die während einer Zeremonie erstellt wird, die den Start der HCC Trust Domain markiert. Die Zeremonie wird bei dem HCC-Provider durchgeführt, bei dem die Designtime-Dienste betrieben werden, hat aber einen HCC-Provider-unabhängigen Charakter hat.

Der TI Verification & Build Service ist nicht Gegenstand der Zulassung von HCC-Providern, jedoch notwendig für das Verständnis und das Funktionieren der Sicherheitsarchitektur von HCC und daher hier dargestellt.

7.5.9 Trust Domain Build Service (Designtime)

Der Trust Domain Build Service ist ein vom HCC-Provider bereitgestelltes Werkzeug zur Konvertierung von Workload Images in die vom HCC-Provider genutzte Confidential-Computing-Technologie bzw. -Lösung und zur Ermittlung der Referenzwerte für die Attestation. Die Konvertierung kann auf einem cVM-Template basieren. Der Diesnt kann als Plug-in für den TI Verification & Build Service umgesetzt werden. Standardmäßig wird er via API durch den TI Verification & Build Service angesteuert. Der Trust Domain Build Service kann von der gematik, von HCC-Dienstanbietern oder von HCC-Workload Herstellern zu Testzwecken auch manuell genutzt werden.

Als Input verarbeitet der Trust Domain Build Service OCI-standardkonforme Container Images. 

Der Trust Domain Build Service ist ein einmaliger Dienst je HCC-Provider. Er ist ein HCC-Dienst, weil die Referenzwerte vertrauenswürdig ermittelt werden müssen und um eine manipulationsgeschützte Signer-Identität für den Dienst zu ermöglichen, die seine Verwendung innerhalb von automatisierten Abläufen ermöglicht.

7.6 Schlüsselmanagement

Instanzen von HCC-Services benötigen Zugriff auf eine Reihe von Schlüsseln, um Daten beim Transport sowie bei der Speicherung abzusichern. Es wurde bereits dargestellt, dass dieser Zugriff durch den TDCAS bereitgestellt wird und dass dies nur nach einer erfolgreichen Attestation geschieht. Als Quelle des Schlüsselmaterials kommen der HSM-Cluster (Schlüssel verbleiben in den HSMs und werden über Zugriffskontrollierte Schnittstellen genutzt) und der Key Management Service (Schlüssel werden für jeden Ziel-Host individuell verschlüsselt gehalten und übermittelt) infrage. Im Folgenden wird die Bereitstellung von Schlüsselmaterial im Hinblick auf die verschiedenen Einsatzzwecke dargestellt.

7.6.1 Öffentliche HCC-Service-Identität

Jede für Clients erreichbare Instanz eines HCC-Service benötigt eine für diese Clients zu authentisierende, Instanz-übergreifende Service-Identität, die an den Zugriff auf den privaten Schlüssel zum TLS-Zertifikat des Service gebunden ist. Es kommen zwei Modelle der Bereitstellung infrage:

• Nach erfolgreicher Attestierung wird an die HCC-Service-Instanz ein kryptographisches Zugriffs-Credential übermittelt, mit dem sie TLS-Challenges durch den HSM-Service signieren lassen kann. Das private Schlüsselmaterial zur Service-Identität verbleibt im HSM-Cluster. Der pro Standort bereitgestellter HSM-Cluster muss die Last bewältigen können, die für alle Vorgänge zum Aufbau von TLS-Sessions über alle öffentlich erreichbaren HCC-Services am Standort anfällt. Dies gilt auch, wenn z. B. andere Standorte unerreichbar sind, d. h. im Fall von erhöhter Last beim Failover.
• Nach erfolgreicher Attestierung wird an die HCC-Service-Instanz der private Schlüssel für die Service-Identität übermittelt. Hierbei ist der HSM-Service nur einmal beim Start involviert und es muss eine entsprechend geringere Kapazität bereitgestellt werden. Voraussetzung für dieses Modell der Schlüsselbereitstellung ist das Vorhandensein eines in die HCC-Hosts integrierten kryptographischen Hardware-Moduls, um die privaten Schlüssel der Service-Identitäten aus der Angriffsfläche des CC-Stacks zu entfernen. Die Provisionierung des Schlüsselmaterials muss für den individuellen Host verschlüsselt erfolgen. Das Hardware-Modul muss sicherheitstechnisch zertifiziert sein.
• Offene dritte Option: Bereitstellung kurzlebiger Service-Identitäten, wie es durch die Konstruktion mit der Sub-CA im TDCAS bereits möglich geworden ist. Welche Gültigkeitszeiträume wären dann angemessen?

7.6.2 TI-Identität von HCC-Services

Für die Service-to-Service Kommunikation innerhalb der Trust Domain werden dienstspezifische Zertifikate aus einer hoheitlichen PKI der TI verwendet. Die Bereitstellung der Schlüssel erfolgt entsprechend der ersten Variante (aus Abschnitt 5.6.1), d. h. die Schlüssel verbleiben im HSM-Cluster. Zwischen Services müssen pro Instanz nur eine begrenzte Anzahl von TLS-Verbindungen aufgebaut werden und diese können mittels Session Resumption aktiv gehalten werden, so dass nur eine vergleichsweise geringe HSM-Last zustande kommt.

7.6.3 Session-Cache-Schlüssel

Damit HCC-Dienste hochverfügbar als (zustandsloser) Cluster funktionieren können, müssen die Session-Daten der Nutzer Instanz-übergreifend in einem Shared Cache gehalten werden. Alle Instanzen eines HCC-Dienstes nutzen in einem Standort-übergreifend synchronisierten Cache denselben symmetrischen Schlüssel, so dass jede Instanz von einer anderen Instanz angelegte oder aktualisierte Session-Daten entschlüsseln kann. Das Caching von Session-Daten ist anwendungsspezifisch, d. h. je Typ von HCC-Dienst wird ein eigener Schlüssel verwendet. Session-Cache-Schlüssel müssen in regelmäßigen Abständen getauscht werden.

Offene Frage: Diese Konstruktion erzeugt eine noch relativ große Angriffsfläche. da jeder Verarbeitungskontext eines Dienstes denselben Schlüssel erhält. Wie könnte hier eine bessere Trennung realisiert werden?

Der Schlüssel wird je HCC-Host in einer an die Server-Hardware und die Attestation des CC-Stacks (inkl. Anwendung) gebundenen Form – d. h. individuell für diese verschlüsselt – bereitgestellt. Bei der Registrierung von HCC-Hosts durch den HCC-Provider werden deren Hardware-Schlüssel registriert. Bei der Registrierung eines HCC-Dienstes wird ein Schlüssel im HSM-Cluster erzeugt und je registriertem Host verschlüsselt an den Key Management Service exportiert. Für nachträglich hinzugefügte Hosts wird diese Hinterlegung für alle registrierten HCC-Dienste ergänzt.

Der symmetrische Session-Cache-Schlüssel kann zusätzlich nutzer- oder Session-spezifisch ausgestaltet werden. Eine Entscheidung hierzu ist noch zu treffen und sollte sich an bereits erprobten Verfahren orientieren. In diesem Fall wird anstelle eines übergreifend gültigen symmetrischen Session-Cache-Schlüssels vom Key Management Service ein Key Derivation Key an die HCC-Dienstinstanz übergeben, von dem die nutzer- oder Session-spezifischen symmetrischen Schlüssel lokal abgeleitet werden können, indem Nutzer- bzw. Session-Identifier als Parameter für die Schlüsselableitung verwendet werden.

Offene Frage: Ist das wirklich eine bessere Lösung? Lässt sie sich ohne große Komplikationen umsetzen?

7.6.4 Persistenz-Schlüssel

Daten, die aus dem Verarbeitungskontext einer HCC-Dienstinstanz an ein System zur Persistierung der Daten übergeben werden, müssen mittels eines symmetrischen Schlüssels geschützt werden. Dieser Schlüssel ist spezifisch für den HCC-Dienst und ggf. für den Daten-Owner. Daten-Owner-spezifische Schlüssel werden generiert, wenn der Daten-Owner den HCC-Dienst erstmalig nutzt. Jede Instanz desselben HCC-Dienstes muss den Schlüssel rekonstruieren oder anderweitig (wieder)erlangen können, um nachfolgende Requests desselben Nutzers verarbeiten zu können.

Die Persistenz-Schlüssel (ggf. Master Keys für eine Schlüsselableitungsfunktion) werden vom Key Management Service bereitgestellt. Sie sind mittels eines vergleichbaren Mechanismus geschützt wie die Session-Cache-Schlüssel, d. h. im KMS an die registrierte Server-Hardware gebunden verschlüsselt sowie ggf. als Key Derivation Keys ausgelegt.

Da Persistenz-Schlüssel nicht ohne Umschlüsselung persistierter Daten (mindestens datensatzspezifischer Schlüssel) getauscht werden können, sollen sie jeweils auf Daten eingeschränkt sein, die innerhalb eines anwendungsspezifisch festgelegten, begrenzten Zeitintervalls gespeichert werden. Die Rekonstruktion des jeweils benötigten Schlüssels im Verarbeitungskontext des HCC-Dienstes erfolgt auf der Basis von unverschlüsselt mit den Daten persistierten Zeitstempeln als Parameter für eine Schlüsselableitungsfunktion.

7.7 Ausschluss der Betreiber und anderer Angreifer

Eine wesentliche Eigenschaft von Healthcare Confidential Computing besteht darin, nicht nur externe Angreifer, sondern auch alle beteiligten Betreiber vom Zugriff auf die verarbeiteten sensiblen Daten auszuschließen. Als Betreiber gelten in diesem Zusammenhang der Infrastrukturanbieter (Cloud Provider, HCC-Provider), der Dienstanbieter, die gematik sowie ggf. ein durch die gematik beauftragter HCC-Plattformanbieter, der den Vertrauensraum HCC-Provider-übergreifend administriert. Die Gesamtheit der technischen Mechanismen sowie der physischen und organisatorischen Rahmenbedingungen, die diese Eigenschaft gewährleisten, wird im folgenden dargestellt.

Die bisher dargestellten Mechanismen der Sicherheitsarchitektur von Healthcare Confidential Computing zielen primär darauf ab, dass die Trusted Computing Base der Laufzeitumgebung zu jedem Zeitpunkt aus wohlbekannten Komponenten aufgebaut ist, die aus einem Prozess mit unabhängiger und TI-übergreifender Governance hervorgehen.

Die sicherheitstechnische Abgrenzung dieser Komponenten von weiteren Komponenten in der Infrastruktur, insbesondere von den Cloud-Management-Komponenten des HCC-Providers, hängt jedoch zusätzlich davon ab, dass die eingesetzte Confidential Computing Technologie eine sichere Isolation der umgesetzten Prozesse gewährleistet.

Die Gesamtsicherheit der Trusted Computing Base der Laufzeitumgebung hängt darüber hinaus davon ab, dass diese Prozesse, d. h. die (fachlichen) Dienste selbst, sicher und spezifikationsgemäß umgesetzt sind.

7.7.1 Physische Sicherheit der Rechenzentrumsumgebung

Die Sicherheitsleistung von kryptographischen Verfahren hängt davon ab, dass die eingesetzten (privaten oder symmetrischen) Schlüssel außerhalb der vorgesehenen Komponenten und Funktionen nicht bekannt werden oder genutzt werden können. Die Sicherheit von Confidential Computing hängt davon ab, dass der in der CPU instanziierte Verarbeitungskontext nicht „belauscht“ werden kann. Eine Extraktion von Schlüsselmaterial oder eine Beobachtung von Verarbeitungen (über physikalische Seitenkanäle) können nicht ausgeschlossen werden, wenn Unberechtigte physische Kontrolle über oder physischen Zugriff auf die verarbeitenden Systeme erlangen können.

„Klassische Rechenzentrumssicherheit“ spielt daher eine weiterhin grundlegende Rolle auch beim Einsatz von Confidential Computing Technologien. Wenn es beim Cloud Computing gängige Auffassung ist, dass es gleichgültig ist, wo eine Verarbeitung stattfindet, dann ist es für Confidential Computing entscheidend, dass die physische Rechenzentrumssicherheit überall sichergestellt ist, wo Verarbeitungen stattfinden können. Dies gilt insbesondere vor dem Hintergrund der Anforderung des Betreiberausschlusses.

Neben der Erfüllung der grundsätzlichen Zertifizierungsanforderungen (siehe Kapitel 9 Zulassungen und Bestätigungen) müssen HCC-Provider daher insbesondere sicherstellen und nachweisen, dass ihre Prozesse zur Einrichtung und Wartung der Infrastruktur ihren damit betrauten Mitarbeitern keine Möglichkeiten für physische Angriffe auf die Vertraulichkeit der Verarbeitungen bieten, die nicht zuverlässig und kurzfristig erkannt und mitigiert werden.

Ähnlich zum Gebot der Minimierung der TCB gilt hier das Gebot der Minimierung von physischer Präsenz in der Rechenzentrumsumgebung. Darüber hinaus müssen alle Aktivitäten in der physischen Rechenzentrumsumgebung aufgabenbezogen organisiert und organisatorisch unabhängig überwacht werden. Geeignete Schleusen müssen verhindern, dass unzulässige Mittel durch Mitarbeiter in die Rechenzentrumsumgebung eingebracht werden können.

7.7.2 Isolation von Mandanten im Netz

Ein wesentlicher Faktor der Sicherheit von Cloud-Infrastrukturen ist die Isolation der Dienste verschiedener Mandanten auf der Ebene des Netzwerks. Jeder Mandant existiert zunächst in einem eigenen Software Defined Network. Die grundlegende Einrichtung pro Mandanten ist automatisiert und kann im Anschluss durch den Mandanten selbst erweitert und konfiguriert werden, wobei die Einstellungsmöglichkeiten des Mandanten derart eingeschränkt sind, dass die Mandantenisolation für alle anderen Mandanten erhalten bleibt, selbst wenn der Mandant Dienste erreichbar macht.

Änderungen an der Netzwerkkonfiguration werden u. a. implizit ausgelöst, wenn der Mandant Services des Cloud-Anbieters hinzubucht. Hierbei sind sowohl die buchbaren Services als auch die Mechanismen zum Hinzubuchen so umgesetzt, dass die Mandantentrennung erhalten bleibt. Im Falle von Cloud-native Services ist dabei evtl. ein Übergang von der Trennung auf Netzwerkebene zur Trennung auf Anwendungsebene erforderlich.

Die Systeme und Mechanismen zur Mandantentrennung in der Infrastruktur eines HCC-Providers werden nicht unmittelbar zur Trusted Computing Base von HCC gerechnet. Die Sicherheit auf Netzwerkebene ist jedoch eine wichtige Voraussetzung dafür, dass die Verfügbarkeit der HCC-Dienste gewährleistet werden kann. Es wird daher vorausgesetzt, dass eine wirksame Mandantentrennung umgesetzt ist. Die Prüfung dieser Voraussetzung erfolgt im Rahmen der grundlegenden Zertifizierung des HCC-Providers (gemäß Kapitel 9 Zulassungen und Bestätigungen). Weitergehende Anforderung müssen im Rahmen der vorliegenden Spezifikation nicht gestellt werden.

7.7.3 Prozessisolation

Confidential Computing Technologie wird als Mittel zur sicheren Auslagerung von Verarbeitungsprozessen an externe Infrastrukturbetreiber vermarktet, u. a., weil sie die Isolation von Daten im Arbeitsspeicher mittels Verschlüsselung garantiert. Insbesondere bei VM-basierten Varianten von Confidential Computing (z. B. Intel TDX oder AMD SEV-SNP) wird jeder VM ein eigener symmetrischer Schlüssel zur Verschlüsselung ihres Arbeitsspeichers zugeordnet, so dass Zugriffe außerhalb der vorgesehenen Speicherbereiche (Out of Bounds Access) durch andere Prozesse keine verwertbaren Daten der Confidential VM offenlegen. Der kryptographische Speicherschutz besteht zudem auch gegenüber privilegierten Prozessen, wie dem Betriebssystem oder dem Hypervisor.

Der auf diese Weise zu erreichende Isolationsgrad hat seine Grenzen darin, dass alle Prozesse auf einer CPU (oder GPU, etc.) auf gemeinsame Ressourcen zur Optimierung der Performance zurückgreifen, die sowohl in der zeitlichen Dimension als auch bzgl. ihrer Speicheranforderungen charakteristische Muster offenbaren können, die von Prozessen außerhalb der Confidential VM beobachtet und zur Extraktion von Geheimnissen genutzt werden können. Solche Angriffsmöglichkeiten werden seitens der Prozessorhersteller als Schwachstellen behandelt und – meist unter Inkaufnahme von Performanceverlusten – mittels Firmware- oder Microcode-Updates geschlossen. Sie sind jedoch schwer prinzipiell auszuschließen, da Mechanismen zur Steigerung der Performance der Prozessoren ihren eigenen komplizierten Logiken folgen und meist auf der Einführung zusätzlicher prozessübergreifend geteilter Hardware-Ressourcen beruhen.

Vor diesem Hintergrund werden die Garantien hinsichtlich der Prozessisolation von Confidential Computing Technologien für HCC nur mit gewissen Einschränkungen als gegeben angesehen. Insbesondere der Betreiberausschluss erfordert, dass die Sicherheitsarchitektur auf hochprivilegierte potenzielle Angreifer ausgerichtet sein muss.

Es werden zwei Szenarien unterschieden:

• Angriffscode aus dem Anbieterkontext könnte versuchen Seitenkanäle auszunutzen, um Schlüsselmaterial oder sensible Nutzdaten aus der Confidential VM zu extrahieren. Insbesondere solcher Code kann auch privilegiert sein und z. B. Mechanismen zur Aufdeckung von Angriffen (die z. B. auf Behavioral Analyses basieren) unterlaufen.
• Angriffscode, der innerhalb anderer Confidential VMs (anderer Mandanten) läuft, könnte versuchen Seitenkanäle auszunutzen, um Schlüsselmaterial oder sensible Nutzdaten aus der Confidential VM zu extrahieren.

Die Ausnutzung von Seitenkanal-Schwachstellen ohne eine Ausführung von Angriffscode auf dem Zielsystem erscheint nahezu unmöglich, weil nur Code auf dem Prozessor die erforderlichen Beobachtungen machen oder den „Opferprozess“ gezielt stören kann. Ein entsprechender Angriff müsste Schwachstellen und sog. "Gadgets“ in einer auf demselben Prozessor ausgeführten Software-Komponente ausnutzen, um seinen Angriffscode „on the fly“ zu generieren. Es wird angenommen, dass dies durch Härtung sowohl der HCC-Systemsoftware als auch der HCC-Dienstsoftware hinreichend abgewehrt wird.

Angesichts des sehr hohen Schutzbedarfs der in der TI verarbeiteten Daten ist es ein Ziel von HCC, die beiden genannten Angriffsszenarien über Seitenkanäle systematisch auszuschließen.

Angriffe aus Confidential VMs auf demselben Prozessor können zuverlässig dadurch ausgeschlossen werden, dass keine Kunden-Workloads geladen werden dürfen bzw. können, die nicht zum Vertrauensraum von HCC gehören. Für Workloads aus der HCC Trust Domain kann angenommen bzw. gefordert werden, dass sie hinreichend gründlich geprüft sind, um Angriffscode zur Ausnutzung von Seitenkanalangriffen auszuschließen. HCC-Hosts müssen daher so konfiguriert sein, dass sie kein Deployment von Nicht-HCC-Workloads zulassen.

Diese Anforderung schränkt den HCC-Provider in seiner Flexibilität bei der Verteilung von Workloads ein. HCC-Hosts sollen jedoch keine dauerhaft exklusiv bereitgestellten Server sein, sondern Server, die durch "Starten als HCC-Hosts" bei Bedarf zum Pool von HCC-Hosts hinzugefügt werden können und durch Neustart auch wieder aus dem Pool entfernt werden können. Darüber hinaus kann ein HCC-Host HCC-Workloads verschiedener HCC-Mandanten ausführen und damit als geteilte Ressource innerhalb der HCC-Trust-Domain verwendet werden. Der HCC-Provider muss sein Cloud-Management mit der Fähigkeit ausstatten, HCC-Hosts als HCC-exklusive aber HCC-Mandanten-übergreifend nutzbare Ressourcen zu konfigurieren und zu provisionieren. Er muss ein Abrechnungsmodell für ihre Nutzung anbieten, das der gemeinsamen Nutzung der Ressourcen durch seine Mandanten und der bedarfsgesteuerten Provisionierung der HCC-Hosts in den Vertrauensraum Rechnung trägt.

Für den Ausschluss von Angriffscode des HCC-Providers kommen verschiedene Möglichkeiten infrage:

• Der HCC-Provider kann seinen CC-Stack offenlegen und damit einer Begutachtung durch beliebige unabhängige Dritte zugänglich machen. Gerade in Verbindung mit der Attestation kann hierdurch weitgehende Transparenz geschaffen und die Vertrauenswürdigkeit gesteigert werden.
• Der HCC-Provider kann seinen CC-Stack durch einen akkreditierten Gutachter prüfen lassen und das Gutachten der gematik zu Prüfung vorlegen.
• Der HCC-Provider kann seine Cloud-Management-Funktionen auf eine vom Workload-Prozessor unabhängige Komponente auslagern. Solche Komponenten werden z. B. als „Infrastructure Processing Units“ (IPU) bezeichnet. Sie verfügen über einen eigenen Prozessor und ggf. weitere Komponenten zur Beschleunigung von Netzwerkfunktionen und können anstelle von SmartNICs eingesetzt werden. Auf dem Workload-Prozessor verbleibt dann z. B. lediglich ein Hypervisor, d. h. eine besonders kleine, gut gehärtete und ggf. Open Source Komponente.

Jede der dargestellten Möglichkeiten bringt ihre eigenen Trade-offs mit sich.

Die Auslagerung der Cloud-Management-Funktionen auf eine IPU erhöht die Hardware-Kosten pro HCC-Host und erfordert angepasste Betriebssoftware, stellt aber ein von der Art des Workload-Prozessors unabhängiges Isolationsmuster dar, das daher auch für zukünftig relevante Prozessortypen, z. B. für die Verarbeitung von KI-Workloads, nutzbar bleibt und lässt dem HCC-Provider die größte Freiheit in der Gestaltung, Pflege und Geheimhaltung seines Cloud-Management-Systems. Die Nutzung von IPUs ist derzeit (jenseits der Hyperscaler) nicht sehr verbreitet. Sie bietet sich jedoch längerfristiger als Standard für HCC an.

7.7.4 Sichere Hardware-Komponenten der Runtime TCB

Jede Komponente der Trusted Computing Base von HCC hat das Potenzial, bei fehlerhafter Umsetzung die Garantien von HCC zu kompromittieren. Die TCB von HCC muss daher mit großer Sorgfalt entwickelt werden.

Für die Hardware-Komponenten der TCB inkl. ihrer Firmware ist eine geeignete Wahl sowohl des Herstellers als auch der spezifischen Komponenten zu treffen. Aufgrund der geringen Zahl von Herstellern von Server-CPUs mit Confidential Computing Funktionen und der gleichzeitig großen Verbreitung der Komponenten dieser Hersteller ist ein gewisses Vertrauen gerechtfertigt, dass diese Hersteller keine dedizierten Backdoors in ihre Systeme integrieren. Dieses Vertrauen erstreckt sich auch auf die Firmware der Systeme.

Damit können und sollen die für Confidential Computing bereitstehenden Online-Services der Hersteller zur Bestätigung der Authentizität der Komponenten (insb. Attestation der CPUs) genutzt werden, um den lokalen Vertrauensanker der HCC-Hosts abzusichern. Hierbei ist ein Verfahren zu wählen, dass zur Laufzeit keine direkte Verbindung der Attestation Services der CPU-Hersteller zu den attestierten HCC-Hosts benötigt, d. h. ein Verfahren zur Attestation über einen in der Verantwortung des HCC-Providers betriebenen Proxy Service. Die Attestation der CPUs der HCC-Hosts muss nach jedem CPU-Firmware-Update neu durchlaufen werden. Als Ergebnis liegt eine vom CPU-Hersteller signierte Bestätigung für die beim Booten ermittelten Messwerte über die Firmware vor, die als Ausgangspunkt für die lokale Vertrauenskette auf dem jeweiligen Host genutzt wird und dem TI Policy Administration Point bekannt gemacht wird.

Für die Lieferkette muss ausgeschlossen werden können, dass die Komponenten, insbesondere auch ihre Firmware, auf ihrem Weg vom Herstellungsort zum Einsatzort manipuliert werden. Beim Aufbau der Lieferkette sind auch Angriffsmöglichkeiten feindlich gesinnter Staaten zu berücksichtigen, die aufgrund der Internationalität der Hardware-Märkte gegeben sein können.

Die Attestation mit dem CPU-Hersteller stellt für die Absicherung der Lieferkette von HCC-Hosts eine nur teilweise Lösung dar, weil auch andere Komponenten innerhalb von HCC-Hosts für Angriffe genutzt werden könnten. Technologien zur Attestation aller on-board Systemkomponenten sind derzeit in der Entwicklung, jedoch noch nicht der Regelfall. Die Lieferketten müssen daher noch mit organisatorischen Maßnahmen abgesichert werden, aufbauend auf der Wahl von Systemherstellern mit guter Reputation und eigenem detaillierten Management ihrer Zulieferer sowie ausreichendem Integration Testing.

Lange Lieferketten sind zu vermeiden. Als Mindestanforderungen kommen die für die allgemeine Zertifizierung der HCC-Provider zur Anwendung (siehe 9 Zulassungen und Bestätigungen).

Informationen zur Lieferkette der HCC-Hosts werden im Zuge der Registrierung der HCC-Hosts miterfasst und einer Prüfung und ggf. Beanstandung seitens der gematik zugänglich gemacht.

HCC-Hosts müssen zudem insoweit physisch geschlossene Systeme sein, dass in Verbindung mit den organisatorischen Sicherheitsanforderungen zur Zutrittskontrolle der Rechenzentrumsumgebung ausgeschlossen werden kann, dass HCC-Hosts unbemerkt physisch manipuliert werden können.

7.7.5 Sichere Software-Komponenten der Runtime TCB

HCC-Dienste müssen wirksam gegen Angriffe über ihre bestimmungsgemäßen Schnittstellen gehärtet werden. Der HCC-Workload-Hersteller, sein Gutachter, oder – im Falle von Open Source Software – auch die Allgemeinheit, müssen daher zunächst einmal in der Lage sein, die Widerstandsfähigkeit des Dienstes gegen Angriffe zu beurteilen. Eine solche Beurteilung ist nur möglich, wenn die Komplexität der Workload begrenzt ist. Die erste Regel für die Entwicklung sicherer Software für die TCB von HCC lautet daher, nichts in die Software einzubauen oder darin zu belassen, was nicht benötigt wird.

Insbesondere für VM-basierte Workloads bedeutet dies, ein auf ein Minimum reduziertes Betriebssystem zu verwenden und sämtliche Werkzeuge zu entfernen, die für administrative Zugriffe normalerweise Teil von Betriebssystemen sind. Die Virtualisierung der Netzwerkschnittstelle, mit der die VM-Verbindungen nach außen aufbaut, ermöglicht ggf. die Verwendung eines vereinfachten Treibers. Die statische Natur der attestierbaren Workload-Images kann die Verwendung von Komponenten zur Absicherung von Veränderungen an der Software erübrigen. Eine Nutzung der Linux Integrity Measurement Architecture innerhalb der cVM kann je nach Art der Workload und ihres Lifecycles sinnvoll sein.

Die Cloud ermöglicht Lösungsdesigns, in denen Dienste jeweils nur eine Aufgabe erfüllen. Im Falle von HCC gehören dazu immer die Terminierung des VAU-Protokolls (TLS mit oder ohne ASL-Kanal) und die Verarbeitung von User Credentials zur Prüfung der Berechtigung zur Ausführung eines Requests. Hierfür strebt die gematik im Rahmen der Einführung der Zero Trust Architektur eine Standardisierung an. Für einen Großteil der fachlichen Aufrufe sind Schnittstellenstandards wie JSON/FHIR vorgesehen, so dass auch für das Parsing von Requests gehärtete Open Source Standardkomponenten denkbar sind.

Für die Umsetzung der fachlichen Verarbeitung stehen sichere Programmiersprachen wie Rust zur Verfügung, deren Compiler bereits ganze Klassen von Fehlern vermeidbar machen und damit auch die Begutachtung vereinfachen. Gleichzeitig ist z. B. Rust systemnah, d. h. für speichereffiziente und performante Implementierungen geeignet. Sprachen, die Speichersicherheit mittels eigener Laufzeitumgebungen mit Garbage Collection realisieren, sollten vermieden werden, da hierdurch eine zusätzliche Ebene von Komplexität mit Auswirkungen auf die sicherheitstechnische Evaluierung und das Laufzeitverhalten eingeführt wird.

Bei der Entwicklung von Virtualisierung bzw. Container Runtime, von VM-Templates und Standardkomponenten sowie von fachlichen Verarbeitungskomponenten sind alle genannten Möglichkeiten zur Vereinfachung und Härtung der Code-Basis zu nutzen.

HCC-Provider müssen für die TCB eine zu jedem Zeitpunkt aktuell gehaltene und änderungsverfolgte Software Bill of Materials führen, die der gematik zugänglich ist.

7.7.6 Validierung des Mandantenkontextes

In der Cloud stellt der Mandantenkontext einen „äußeren“ Security Perimeter dar, der die Dienste des Mandanten von den Diensten anderer Mandanten in derselben Rechenzentrumsumgebung isoliert und der die Gesamtheit der Konfigurationseinstellungen beherbergt. Der Mandantenkontext spielt damit eine entscheidende Rolle für die Verfügbarkeit der Dienste.

Während Verfügbarkeit nicht das führende Kriterium im Kontext von Confidential Computing darstellt, so ist sie für die TI entscheidend. Aufgrund der Härtung der TCB von Confidential Computing entstehen zusätzliche kryptographische Bindungen, die zusätzliche Quellen für Störungen der Verfügbarkeit darstellen können. Daher sollen HCC-Provider ihren Mandanten Werkzeuge zur Validierung ihrer HCC-Dienstkonfigurationen auf der Ebene des Mandantenkontextes anbieten, die prüfen, ob für die konfigurierten Workloads alle Abhängigkeiten erfüllt werden.

In der vorliegenden Spezifikation wird diese Anforderung derzeit nicht weiter qualifiziert. Eine Umsetzung muss im Kontext des jeweiligen HCC-Providers konzipiert werden.  

7.8 Service Runtime

Cloud-Infrastrukturen können eine ganze Reihe verschiedener Ebenen für die Einbringung von Diensten bereitstellen (z. B. Bare Metal, Virtual Machine, Container, Serverless). Während die Minimierung der TCB in Richtung Bare Metal weist, zeigen die Anforderungen nach High Availability, Elastizität und Resource Sharing (auf der Basis von z. B. Managed Kubernetes) in Richtung höherer Ebenen des Deployments. Als Standard für das Deployment normaler Cloud-Dienste werden derzeit containerisierte Workloads angesehen. Gleichzeitig definiert Confidential Computing virtuelle Maschinen als Standard (siehe 3.4 Standardisierung des Confidential Computing Ansatzes).

Zur Vermeidung divergierender Bewertungen der Sicherheitsleistungen unterschiedlich konstruierter Service Runtimes, zur Vereinheitlichung der Änderungsanforderungen gegenüber den HCC-Providern im Zuge der konzeptionellen Weiterentwicklung von HCC sowie zur Minimierung von Änderungsbedarfen beim Wechsel des HCC-Providers legt die vorliegende Spezifikation folgendes fest:

1. HCC-Workloads werden in Confidential Virtual Machines ausgeführt, die je eine containerisierte Workload des Dienstanbieters enthält, wobei hierzu mehrere Container gehören können, die auch miteinander zusammenarbeiten können, z. B. im Sidecar-Muster. Verschiedene fachliche Dienste der TI werden grundsätzlich in getrennten cVMs implementiert.
2. Die Sicherheitsleistung, insb. hinsichtlich des Betreiberausschlusses, wird auf der Grundlage von Host-Attestation in Kombination mit cVM-Attestation transparent und durchsetzbar gemacht. Der Host-Attestation kommt dabei in Verbindung mit der Speicherverschlüsselung durch die cVMs die Rolle der primären Absicherung gegenüber dem Infrastrukturanbieter zu. Die cVM-Attestation setzt, darauf aufbauend, die Trennung der Dienste und damit auch der Mandanten durch.

Eine Klasse der Bereitstellung von Funktionalitäten in der Cloud sind die Cloud-Native Services. Diese sind typischerweise so aufgebaut, dass sie Kontexttrennung für Mandanten dienstintern implementieren. Die Nutzung von Cloud-native Services in HCC ist im Regelfall darauf beschränkt, diesen Diensten verschlüsselte und gegen De-Anonymisierung bzw. Profilbildung geschützte Daten zu übermitteln. Cloud-native Services könnten in Zukunft auch als Confidential Services bereitgestellt werden. Hierfür ist je Service eine Analyse der Vertraulichkeit bzw. des Betreiberausschlusses einerseits und der Isolationseigenschaften andererseits erforderlich. Die Garantien von Confidential Computing können bei derartigen Services nicht ohne Weiteres „von außen“, d. h. durch „Enklaven“ in der Laufzeitumgebung dargestellt werden.

7.9 Integration mit den Zero Trust Services der TI

Die HCC-Plattform ist eine Ausprägung von Rechenzentrumsumgebung für Dienste der TI, die – wie alle anderen Ausprägungen – in die Gesamtarchitektur der TI 2.0 eingebettet sein soll. Damit werden auch die Ressourcen des HCC von der Zero Trust Architektur der TI 2.0 geschützt. Dies gilt bereits für die dargestellten Core Services und bedeutet, dass jedem Core Service ein Policy Enforcement Point zur Durchsetzung der Zugriffsregeln und ein Policy Decision Point zur Auswertung der Zugriffsattribute von Requests gegen die für den jeweiligen Dienst definierten Zugriffskontrollregeln (Access Policies) zugeordnet sind.

Die für HCC definierten Policies werden innerhalb des TI 2.0-weit gültigen Policy Administration Points verwaltet. Die von den PDP der HCC Core Services verarbeiteten Zugriffsregeln werden von dort bezogen. Der Policy Administration Point muss daher alle für die sichere Verarbeitung der HCC-Policies erforderlichen Funktionen bereitstellen.

In der Überblicksdarstellung Abbildung 7 sind PEP / PDP als dem Fachdienst bzw. Core Service zugeordnete Komponenten enthalten.

Gleichzeitig stellt HCC auch eine Umsetzung von Zero Trust dar. Identitäten von HCC-Diensten werden durch die Attestation auf die Grundlage von Evidence über das den Dienst ausführende System gestellt.

Die normativen Festlegungen zur Zero Trust Architektur der TI werden in gemSpec_ZETA getroffen.

7.10 Erreichbarkeit aus dem Internet

Die TI 2.0 Strategie der gematik sieht vor, dass in Zukunft alle Fachdienste über das Internet erreichbar sein werden. Dies gilt für die Versicherten und ihren Zugriff auf die ePA und das E-Rezept bereits heute. Für die Seite der Leistungserbringer ist ein schrittweiser Wandel vorgezeichnet. Im Kontext der vorliegenden Spezifikation wird bereits kein Zugang über das Netz der TI mehr vorgesehen. Falls ein solcher Zugang doch noch erforderlich werden sollte, wird er als auf Basis von bestehenden Konzepten weiterhin realisierbar angesehen.

Für die Protokolle für den Zugriff auf die Anwendungen der TI über das Internet ist von einer schrittweisen Entwicklung auszugehen. Die Einführung der wesentlichen TI-Dienste (ePA, E-Rezept, KIM, TIM, VZD) hat mit zeitlichem Versatz stattgefunden und etliche parallele Entwicklungsstränge hervorgebracht, die erst dann konvergieren können, wenn auch die Zero Trust Architektur der TI 2.0 generell einsatzbereit ist. Daher ist es im Interesse auch der HCC-Provider, potenziell alle Zugriffsprotokolle der Fachanwendungen zu unterstützen und den Weg zur anwendungsübergreifenden Konvergenz mitzugehen.

Generell folgt die für HCC benötigte Erreichbarkeit aus dem Internet den Vorgaben gemäß gemSpec_ZETA.

7.11 Abwehr von Überlastungsangriffen aus dem Internet

HCC-Provider müssen grundsätzlich Überlastungsangriffe aus dem Internet abwehren können und damit die in ihren Infrastrukturen betriebenen HCC-Dienste schützen. Dies schließt nicht aus, dass einzelne Dienstanbieter einen vom HCC-Provider unabhängigen DDoS-Schutzanbieter wählen und ihre Außenschnittstellen entsprechend konfigurieren.

Aufgrund der starken Bündelung von Internet-Verkehr mit anwendungsübergreifendem Charakter beim HCC-Provider ist dieser möglicherweise besonders gut positioniert, um Profilbildung zu betreiben, d. h. Endnutzer aufgrund ihrer Zugriffsmuster zu erkennen und zu beobachten. Profilbildung muss jedoch aus Gründen des Datenschutzes ausgeschlossen werden.

Hier bietet es sich an, die Zusammenarbeit des HCC-Providers mit einem unabhängigen DDoS-Schutzanbieter zu nutzen. Während es nicht ausgeschlossen werden kann, dass der DDoS-Schutzanbieter aus den Quellnetzen genug Informationen erhält, um Nutzer zu identifizieren, kann er solche Informationen beim Durchleiten des Verkehrs an den HCC-Provider auf allen Ebenen unterhalb des Application Layers verschleiern. Der DDoS-Schutzanbieter „sieht“ dann möglicherweise noch die Aktivitäten von Nutzern, weiß jedoch nicht, auf welchen Anwendungskontext sie sich beziehen, während der HCC-Provider keine Möglichkeit zur Identifizierung von Endnutzern mehr hat, da deren Verbindungen in der VAU terminieren.

In einem solchen Szenario ist es dann erforderlich, den DDoS-Schutzanbieter mit Informationen darüber zu versorgen, welche Nutzerverbindungen als legitim angesehen werden können, um ihn in die Lage zu versetzen, andere Requests einfach herauszufiltern. Daher ist der Einsatz eines Protokolls zur Rückmeldung von erfolgreich authentisierten Sessions an den DDoS-Schutzanbieter zu empfehlen. Dieses Protokoll muss auf pseudonymen Session-Identities aufbauen.

Derzeit bleiben derzeit sowohl der Einsatz eines solchen Aufbaus als auch die Ausgestaltung offen.

8 Organisatorische Sicherheit

Die technischen Sicherheitsmechanismen von HCC müssen eingerichtet und gewartet werden. Dies führt zu Prozessen der organisatorischen Sicherheit als Voraussetzung für die Wirksamkeit der technischen Sicherheitsmechanismen. Erweiterungen der Infrastruktur, die Aufnahme und Zulassung von Dienstanbietern als Mandanten, aber auch ihr Ausscheiden, sowie die Aufnahme von (Fach-) Diensten als TI-Dienste stellen weitere Prozesse dar, die notwendigerweise organisatorischer Natur sind. Insgesamt sind die technischen Sicherheitsmaßnahmen von organisatorischen Strukturen und Maßnahmen eingerahmt.

Insbesondere für den HCC-Provider stellen sich die spezifischen Anforderungen zur organisatorischen Sicherheit als Erweiterungen, Spezialisierungen, teilweise auch Umsetzungen seines allgemeinen System- und Prozess-Frameworks zur Erreichung der erforderlichen Zertifizierungen gemäß entsprechender Prüfkataloge und Normen dar (siehe Kapitel 9 Zulassungen und Bestätigungen). Soweit anwendbar sollten die im Folgenden geforderten Prozesse und Maßnahmen in die bestehenden Frameworks der HCC-Provider integriert implementiert werden.

8.1 Rollen und Verantwortlichkeiten

Die folgende Tabelle liefert eine Übersicht über die mit den Rollen der bei HCC beteiligten Akteure verbundenen Aufgaben.

Tabelle 1 : Akteure und ihre Aufgaben

Die hier aufgeführten Rollen und Verantwortlichkeiten müssen im Rahmen der Schaffung der organisatorischen Voraussetzungen für eine Zulassung der Anbieter und Hersteller konkretisiert und ausgearbeitet werden. Hierfür werden die bestehenden Zulassungsprozesse und Verantwortlichkeiten bei der gematik entsprechend erweitert.

9 Zulassungen und Bestätigungen

Die Darstellungen in diesem Abschnitt orientieren sich an den Zulassungs- und Bestätigungsprozessen der gematik für Produkte und Anbieter.

Die gematik erteilt Zulassungen für Produkte. Dies können Komponenten oder Dienste sein – insbesondere auch solche, die aufgrund der Verarbeitung schutzwürdiger Daten eine VAU umfassen.

Die Zulassung eines Produkts umfasst dabei das Produkt im Umfang der Spezifikation der gematik und den sicheren Softwareentwicklungsprozess des Herstellers. Im Produktumfang ist insbesondere auch das VAU-Image enthalten.

Falls der Hersteller des Produkts die VAU selbst umsetzt, muss das Produkt auch die Anforderungen an die VAU erfüllen. Den Nachweis über die Erfüllung der Anforderungen muss der Hersteller gemäß den im Produkttypsteckbrief vermerkten Prüfverfahren erbringen. Der Anbieter bzw. Betreiber des zugelassenen Produkts muss in diesem Fall die Erfüllung der Anforderungen an den VAU-Betreiber nachweisen.

Anderenfalls muss der Anbieter bzw. Betreiber des Produkts einen bei der gematik gelisteten HCC-Provider auswählen. Die gelisteten HCC-Provider erfüllen die Anforderungen an VAU-Betreiber und haben dies in einem Assessment der gematik und durch die Vorlage folgender Dokumente nachgewiesen:

• Erklärung über die Erfüllung der Anforderungen in diesem Dokument,
• Erklärung zur DSGVO-Konformität,
• Testat des HCC-Providers über die Zertifizierung nach geeigneten Standards (siehe folgende Ausführungen).

Als geeigneter Standard für die Zertifizierung des HCC-Providers wird in Zukunft EUCS zur Anwendung kommen. Dieser Standard ist derzeit noch in der Erarbeitung durch die entsprechenden EU-Gremien. Seine Anwendung ist erst möglich, wenn der Standard normativ geworden ist. Ab dem Zeitpunkt seiner normativen Geltung ersetzt er bisher geltende Normen, insbesondere den Kriterienkatalog C5 des BSI. EUCS baut auf einer Vielzahl von ISO/IEC-Normen auf, die dadurch implizit normativ geltend werden.

EUCS ist in seinem an einer Liste von „Controls“ ausgerichteten Aufbau mit dem Kriterienkatalog C5 des BSI vergleichbar, definiert im Gegensatz zu C5 jedoch Zertifizierungslevels.

EUCS wird voraussichtlich drei Zertifizierungslevels definieren CS-EL1, CS-EL2 und CS-EL3. Sie unterscheiden sich durch eine deutliche Konkretisierung der geforderten Nachweise zu vielen der Controls, insbesondere beim Übergang von CS-EL1 (basic) zu CS-EL2 (substantial). Es ist davon auszugehen, dass durch EUCS für die Verarbeitung von personenbezogenen medizinischen Daten die Anwendung des Level CS-EL3 vorgeschrieben sein wird.

EUCS ist darauf ausgerichtet, möglichst viele Zertifikate auf der Grundlage von z. B. C5 oder auf der Grundlage verschiedener ISO/IEC-Normen nachnutzbar zu machen. Die Anhebung des Zertifizierungsniveaus auf EUCS sollte daher bei den Anbietern nicht zu völlig anders strukturierten Prozessen führen.

Eine Zertifizierung gemäß EUCS hat stets Bezug zu einem definierten Service. In diesem Sinne kann HCC als Zertifizierungsgegenstand aufgefasst werden. Die Umsetzung von HCC gemäß der vorliegenden Spezifikation sollte für den HCC-Provider die Erfüllung vieler EUCS-Anforderungen auf Level CS-EL3 abdecken oder mindestens vereinfachen.

Bis zum Zeitpunkt, einer normativen Geltung von EUCS in der EU werden HCC-Provider auf der Grundlage der folgenden Testate und Zertifizierungen zugelassen:

• Testat über die Erfüllung der Anforderungen aus dem Kriterienkatalog C5 (Typ 2) des BSI in der jeweils gültigen Version,
• ISO 27001 Zertifizierung (Information security, cybersecurity and privacy protection – Information security management systems - Requirements),
• ISO 27017 Zertifizierung (Information Technology - Security Techniques - Code of practice for Information Security Controls based on ISO/IEC 27002 for Cloud Services Standard),
• ISO 27018 Zertifizierung (Information technology – Security techniques – Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors),
• ISO 27701 Zertifizierung (Security techniques - Extension to ISO/IEC 27001 and ISO 27002 for privacy information management - requirements and guidelines Standard).

Die folgende Tabelle fasst die Zulassungsgrundlagen für HCC-Provider zusammen:

Tabelle 2: Zulassung von HCC-Providern

10 Interoperabilität

Die folgenden Schnittstellen der HCC-Provider für die Nutzung durch Dienste der gematik müssen anbieterübergreifend interoperabel ausgeführt sein, damit die HCC-Plattform für die TI handhabbar funktioniert:

1. Web-API des Trust Domain Deployment Repository für die Aufnahme der signierten HCC Workload Images, Konfigurationen, Policies und zugehöriger Metadaten aus dem TI Verification & Build Service,
2. Web-API des Trust Domain Build Service zur Entgegennahme von Workload Images und Rückgabe konvertierter Workload-Images mit den dazu ermittelten Referenzwerten aus dem TI Verification & Build Service (die manuelle Alternative muss nicht interoperabel gestaltet sein),
3. Web-API des Trust Domain Configuration & Attestation Service zur Befüllung der Konfigurationsdatenbank mit signierten Einträgen aus dem TI Verification & Build Service,
4. Web-API zur Steuerung und Konfiguration von Trust Domain Deployment Repository und Trust Domain Configuration & Attestation Service im Mandantenkontext der gematik – soweit nicht abgedeckt durch die vorstehenden Schnittstellen für die Verteilung von deren Inhalten,
5. Schnittstelle für das Einbringen von Workload-Images in ggf. Provider-neutraler Form in das TI Design & Configuration Repository. Hierbei geht es um die Standardisierung der für ein Einbringen geeigneten Formate der Images (Container- oder VM-Images) sowie ggf. um Metadaten und Konfigurationsdaten. (Diese Schnittstelle wird erst im Zuge des Aufbaus des Service bei der gematik spezifiziert.)

Die Web-APIs 1 bis 4 sollen als Ergebnis der Konsultationen mit der Industrie spezifiziert werden. Die gematik bittet hierzu um Input und Hinweise auf geeignete Standards oder bereits implementierte Lösungen. Für diese WebAPIs ist es für eine Übergangszeit denkbar, dass auch spezifische (nicht interoperable) Schnittstellen von HCC-Providern unterstützt werden, die es erfordern, dass Artefakte zunächst (z. B. per Skript) konvertiert werden müssen, bevor sie übermittelt werden können.

11 Integration in das SIEM der TI

Dieser Abschnitt wird in einer zukünftigen Version der Spezifikation ausgearbeitet.

12 Integration in das Testing Framework der TI

Die Integration von Healthcare Confidential Computing (HCC) in das Testing Framework der TI dient dazu, Qualität, Stabilität und Evolvierbarkeit der HCC‑Plattform und der darauf betriebenen HCC‑Dienste in allen Lebenszyklusphasen systematisch zu prüfen. Im Vordergrund steht dabei eine testgetriebene Nutzung von Cloud‑ und CI/CD‑Mechanismen, die es ermöglicht, funktionale und nicht‑funktionale Eigenschaften iterativ zu verifizieren, die Weiterentwicklung zu unterstützen und Regressionen frühzeitig zu erkennen. Ziel ist es, die Vertrauenswürdigkeit, Reproduzierbarkeit und Auditierbarkeit der Plattform nachweisbar zu machen.

12.1 Tests der HCC Cloud Plattform

Für die HCC Cloud Plattform kommt ein fachlich neutraler Testcontainer zum Einsatz, der als Referenz‑Workload die grundlegenden Plattform‑Funktionen aus Sicht eines HCC‑Dienstes nutzt. Der Testcontainer ist als einfaches, OCI‑konformes Container‑Image ausgelegt, das die für HCC erforderlichen Mechanismen implementiert und dadurch eine neutrale, reproduzierbare Basis für Plattformtests schafft. Der fachlich neutrale Ansatz ermöglicht provider‑ und umgebungsübergreifende Vergleichbarkeit und reduziert Abhängigkeiten von domänenspezifischer Logik; die Entscheidungsbegründung ist damit dokumentiert.

Der Referenz‑Workload des Testcontainers bildet eine definierte Menge an grundlegenden Plattformfunktionen ab, die ein HCC‑Dienst typischerweise nutzen muss. Dazu zählen insbesondere die Bereitstellung standardisierter HTTP(S)‑Schnittstellen zur Entgegennahme und Verarbeitung von Test‑Requests und die Nutzung der vorgesehenen Routing Mechanismen. Der Container interagiert in minimaler, fachlich neutraler Weise mit ausgewählten HCC‑Basisdiensten, um deren Erreichbarkeit und korrektes Zusammenspiel zu validieren, ohne dabei domänenspezifische Logik abzubilden. Darüber hinaus ist der Referenz‑Workload so ausgelegt, dass sein Verhalten deterministisch und reproduzierbar ist, um konsistente Testergebnisse über verschiedene Umgebungen und Provider hinweg zu gewährleisten. Ergänzend kann der Container gezielt einfache Fehler- und Grenzfallszenarien auslösen, um das Verhalten der Plattform unter definierten Störbedingungen überprüfbar zu machen.

Der Build‑ und Deploy‑Prozess des Testcontainers ist vollständig CI/CD‑gestützt: Änderungen an Quellcode oder Basis‑Images werden automatisiert zu einem neuen Container‑Artefakt gebaut, versioniert und in ein Repository eingestellt. In einer nachgelagerten Pipeline‑Stufe wird das Container‑Image über den Trust Domain Build Service in ein für die HCC‑Plattform ausführbares cVM‑Workload‑Image überführt, sodass dieselbe Workload konsistent in verschiedenen Umgebungen – verstanden als technisch getrennte Ausführungs- und Testkontexte entlang definierter Test‑ und Freigabephasen – sowie bei unterschiedlichen HCC‑Providern ausgeführt werden kann. Eine weitere Pipeline‑Stufe instanziiert den Workload in einer solchen Testumgebung und führt automatisierte Funktionstests durch, die u. a. Konnektivität, Erreichbarkeit über HTTPS, die Verarbeitung von Test‑Requests sowie die Interaktion mit den HCC‑Basisdiensten prüfen, ohne dabei sicherheitsrelevante Eigenschaften selbst zu bewerten.

Die so gestalteten Tests verstehen den Referenz-Workload als Durchstich durch die Schichten der Cloud‑Plattform: Sie decken den technischen Weg von der Bereitstellung eines OCI‑Images über die Build‑Verarbeitung bis hin zum Lauf eines HCC‑Dienstes im produktionsnahen Mandantenkontext ab. Im Mittelpunkt stehen dabei Aspekte wie korrekte Orchestrierung, konsistente Nutzung von Mandanten‑Ressourcen, funktionierendes Routing und Logging sowie das Zusammenspiel der CI/CD‑Pipelines mit den Plattformkomponenten. Negative und Grenzfall‑Szenarien können anhand abgeleiteter Varianten desselben Testworkloads (z. B. bewusst fehlerhafte Konfigurationen, nicht erreichbare Abhängigkeiten) geprüft werden, um Plattformverhalten unter Störungssituationen zu beobachten.

Durch die konsequente Nutzung dieser einfachen Referenz‑Workloads wird die HCC‑Plattform selbst testbar, ohne dass fachliche Dienste oder sensible Daten erforderlich sind. Der Testcontainer dient zudem als Beispiel für HCC‑Dienste, wie ein cloud‑nativer, CI/CD‑integrierter Entwicklungs‑ und Testprozess in HCC auszusehen hat, und schafft eine gemeinsame Grundlage für Provider‑übergreifende Qualitätssicherung.

Darüber hinaus wird der Referenz‑Workload genutzt, um die Konfiguration und Trennung von Mandantenkontexten zu validieren: Tests prüfen, ob gematik‑Mandanten und HCC‑Dienstanbieter‑Mandanten über die vorgesehenen APIs vollständig konfigurierbar sind, ob Mandantentrennung und TI‑Policy‑Durchsetzung im SDN und an den relevanten Gateways greifen und ob nur die vorgesehenen Verbindungen zwischen Diensten und Basisdiensten der Plattform hergestellt werden können.

Ergänzend adressiert die Teststrategie nichtfunktionale Plattformaspekte: Mit Hilfe des Testcontainers und geeigneter Fault‑Injection‑Mechanismen werden Standortausfälle, HSM‑Cluster‑Verhalten sowie Scale‑out/Scale‑in von Pods und cVM‑Nodes überprüft, um die geforderte Verfügbarkeit und elastische Skalierung der HCC‑Plattform nachzuweisen.

12.2 Tests mit der HCC Cloud Plattform

Kernbestandteile der Cloud-basierten Teststrategie sind:

• Continuous Testing und Continuous Delivery: Durch die Integration automatisierter Tests in die von der Cloud-Plattform bereitgestellten CI/CD-Pipelines – ergänzt durch konfigurierbare Zugriffskontrollen sowie HCC-basierte Build- und Deployment-Prozesse auf allen Umgebungen – wird Continuous Testing systematisch ermöglicht und die Softwarequalität kontinuierlich sowie nachvollziehbar sichergestellt.
• Förderung einer CI/CD-nativen Entwicklung: Einsatz von Infrastructure as Code, containerbasierten Deployments sowie vollständig automatisierten Test-Pipelines.

Diese Ausrichtung folgt Test Prinzipien, nach denen Tests fokussiert, zeitnah, häufig ausgeführt, aussagekräftig und zuverlässig sein müssen; genau dies wird durch automatisierte Pipelines auf konsistent bereitgestellten Umgebungen erreicht.

Abbildung 8:  Überblicksdarstellung Tests auf der HCC-Plattform

Die HCC Cloud Plattform muss dafür CI/CD Pipelines mit konfigurierbarer Rechtevergabe bereitstellen. Für die Nutzungs- und Zugriffskontrolle muss eine Mandantentrennung mit klaren Verantwortlichkeiten unterstützt werden. Das gilt für CI/CD Pipelines wie auch für Artefakte und Testumgebungen. Eine klar geregelte Mandantentrennung und Rollenvergabe reduziert dabei Koordinationsaufwand und Wartezeiten zwischen den am Test beteiligten Akteueren und verhindert typische Engpässe, die entstehen, wenn Testen als getrennte Phase organisiert wird.

Die HCC Cloud Plattform muss eine Speicherlösung bereitstellen, in der signierte Testreports abgelegt werden können. Auf diese Reports wird im Software-Attest referenziert. Zusätzlich muss sichergestellt sein, dass die Testreports eindeutig auf die jeweils getesteten, kryptografisch identifizierten Workload‑Images als System under Test (SuT) verweisen, sodass eine nachvollziehbare und reproduzierbare Zuordnung zwischen Attest, Report und dem getesteten Workload hergestellt wird. Ziel ist die Integrität (Unveränderbarkeit) der Testreports und ihre eindeutige Verknüpfung mit dem kryptografisch identifizierten SuT‑Image. Eine solche eindeutige Nachvollziehbarkeit entspricht einem „Tests als First‑Class‑Citizen“ Gedanken: Testartefakte werden wie Produktcode behandelt, versioniert und auditierbar gehalten, um regulatorische Anforderungen mit möglichst wenig Prozess‑Overhead erfüllen zu können.

Tests auf der HCC‑Plattform müssen in ephemeren Testumgebungen durchgeführt werden können, die on‑demand aufgebaut und nach Nutzung automatisiert wieder abgebaut werden. Grundlage ist eine „Single Source of Truth“ aus Source Code, Infrastructure as Code (IaC) und Konfiguration, die versioniert vorliegt und alle Stages – von Entwicklungs‑ über Integrations‑ bis zu produktionsnahen Umgebungen und Produktion selber – konsistent beschreibt. Damit werden Konfigurationsdrift und manuelle Sonderwege vermieden und die Nachvollziehbarkeit von Testergebnissen über Releases und Provider‑Instanzen hinweg erleichtert.

Das Prinzip „build once, deploy often“ ist für alle Teststufen verbindlich: identische Artefakte werden in verschiedenen Umgebungen ausgerollt, sodass Unterschiede im Verhalten auf Umgebungsfaktoren und nicht auf Artefaktvarianten zurückzuführen sind. Deployments erfolgen vollautomatisiert über CI/CD‑Pipelines, die durch Commits, Pull Requests oder zeitgesteuert angestoßen werden und sowohl Infrastruktur‑ als auch Applikationsanteile abdecken. Infrastruktur und Applikation sind strikt getrennt konfigurierbar; Infrastrukturänderungen erfolgen ausschließlich über IaC‑Änderungen, während dienstspezifische Konfigurationen in klar abgegrenzten Parametern oder Konfigurationsdateien gehalten werden. Umgebung ist in diesem Sinne eine logische Zuordnung und keine statische Infrastruktur. Durch die in der CI/CD‑Pipeline ausgeführten Tests kann für eine bestimmte Version der Software under Test – im Sinne einer Testinstanz – eine schrittweise steigende Betriebsreife nachgewiesen werden. Unter ‘Umgebung‘ verstehen wir also die Kombination aus Deployment‑ und Qualifizierungsstufen sowie den jeweils zugehörigen Anforderungen an Verfügbarkeit und Skalierung, ergänzt um ihre Einbettung in eine spezifische Trust‑Domain (z. B. eine TI‑Föderation) und eine zugehörige Network‑Domain (z. B. Cloud VPC).

Ephemere Testumgebungen müssen zu jedem Zeitpunkt reproduzierbar sein; Versionierung von IaC, Artefakten und Konfiguration erlaubt es, jeden früheren Teststand gezielt wiederherzustellen, z. B. für Fehleranalysen oder Regressionstests. Die Plattform unterstützt schnelles Re‑Deployment, damit Rollback‑Szenarien, Blue‑Green‑ oder Canary‑Deployment‑Strategien sowie komplexe Integrationsfälle unter realistischen Bedingungen getestet werden können. Durch eine horizontale Skalierung der Container-Instanzen in Testumgebungen lassen sich umfangreiche Testreihen (z. B. Last‑, Skalierungs‑ oder Kompatibilitätstests) effizient durchführen, ohne dass sich Tests gegenseitig beeinflussen.

Alle relevanten Infrastrukturkomponenten (Compute, Netzwerk, Storage, Security‑Funktionen und Orchestrierung) sind deklarativ als IaC beschrieben, und Änderungen werden ausschließlich über diesen Weg vorgenommen; manuelle Eingriffe in laufende Instanzen sind nicht vorgesehen („Immutable Infrastructure“). Fachdienste werden in Form dynamischer Produktketten aus containerisierten Services betrieben, die sich flexibel zu Testketten zusammensetzen lassen – inklusive Mischszenarien aus neuen Versionen als Testobjekten und freigegebenen Referenzversionen. Ephemere Infrastruktur ermöglicht es, Testumgebungen schnell und reproduzierbar bereitzustellen, Kosten zu senken und Seiteneffekte zwischen Tests zu minimieren, da jede Umgebung neu aufgebaut und nach der Nutzung wieder entfernt werden kann. Dadurch sinkt die Abhängigkeit von lange laufenden, gemeinsam genutzten Testumgebungen, die schwer konsistent zu halten sind und häufig zu Wartezeiten, Fehlkonfigurationen und damit zu nicht aussagekräftigen Testergebnissen führen. Die Cloud Plattform muss also dynamisches Routing unterstützen. Dynamisches Routing unterstützt Ansätze wie Contract‑Testing und das Aufsetzen kurzlebiger Produktketten, die das Testen lose gekoppelter Systeme deutlich erleichtern.

Observability ist integraler Bestandteil jeder Testumgebung: Logs werden zentral aggregiert, und Monitoring‑Funktionen stehen bereits in den Testumgebungen zur Verfügung. Observability ist wichtig, um Tests nicht nur binär „pass/fail“ zu bewerten, sondern deren Ergebnisse hinsichtlich Stabilität, Performance und Ressourcennutzung auszuwerten und gezielt Verbesserungsmaßnahmen abzuleiten. Dadurch lassen sich funktionale und nicht‑funktionale Testergebnisse (z. B. Antwortzeiten, Fehlerraten, Ressourcennutzung) automatisiert auswerten und mit den Anforderungen an HCC‑Dienste und Plattformbetrieb verknüpfen. Die so gewonnenen Daten können über die bestehenden Mechanismen zur betrieblichen Überwachung in die Systeme der TI eingebracht und für Qualitätssicherung, Kapazitätsplanung und kontinuierliche Verbesserung der HCC‑Plattform genutzt werden.

Die folgende beispielhafte Darstellung verdeutlicht den Aufbau der Build Piplines für das Staging von Diensten durch die Testumgebungen:

Abbildung 9:  Staging von Diensten auf der HCC-Plattform

13 Integration in die betriebliche Steuerung der TI

Die konkrete Anforderungslage für die betriebliche Organisation und Performance wird zu einem späteren Entwicklungsstand dieses Dokuments erweitert und konkretisiert. Die hier skizzierten Ideen und Prozesse sollen einen Rahmen setzen, zum Diskurs anregen und im Verlauf der weiteren Abstimmungen konkretisiert werden. Es ist angedacht, dass die für HCC spezialisierten Anforderungen in diesem Dokument geführt und diese mit den übergreifenden, normativen Regelungen aus [gemRL_Betr_TI], [gemSpec_Perf] und [gemKPT_Betr] harmonisiert werden.

In der Telematikinfrastruktur liegen Anwendungs- und Infrastrukturbetrieb bisher stets in einer integrierten Betriebsverantwortung: Ein zugelassener Anbieter verantwortete beide Schichten vom Rechenzentrum bis zur fachlichen Verarbeitungslogik. Das Health-Confidential-Computing-Modell (HCC) verändert dieses Grundprinzip strukturell. Infrastruktur und Anwendung werden künftig durch separate, rechtlich eigenständige Akteure betrieben. Dieser Wesensunterschied ist nicht das Ergebnis einer organisatorischen Präferenz, sondern die technische Konsequenz des Confidential-Computing-Architekturprinzips: Infrastruktur und Anwendung operieren in getrennten Vertrauenssphären und können im laufenden Betrieb nicht unilateral aufeinander zugreifen.

Diese strukturelle Neuordnung birgt erhebliche Qualitätsgewinne. Cloud-Infrastrukturen gewährleisten kryptographisch erzwungene Integritätsgarantien, die im klassischen Rechenzentrumsbetrieb nur auf prozessualer Basis sichergestellt werden konnten. Skalierbarkeit, Ausfallsicherheit und Konfigurationsüberwachung erreichen ein strukturell höheres Niveau. Zugleich entstehen neue Anforderungen an Steuerung, Prozessgestaltung und vertragliche Absicherung, weil bisher intern gelöste Koordinationsaufgaben nunmehr explizit zwischen mehreren, rechtlich eigenständigen Akteuren geregelt werden müssen.

13.1 Verfügbarkeit und Performance

Die Verfügbarkeitsverantwortung und Verantwortung für die Einhaltung der Performance-Vorgaben ist folgendermaßen aufgeteilt:

• Der HCC-Provider ist verantwortlich für die Zuleitung aller Requests an den HCC-Dienst bzw. die Rückleitung aller Responses sowie für die bedarfsgerechte Instanziierung des HCC-Dienstes gemäß seiner Konfigurationseinstellungen.
• Der HCC-Dienstanbieter ist verantwortlich für die fachliche Verarbeitung, aber auch für die Performance im Zusammenspiel mit den genutzten Services des HCC-Providers (z.B. Datenbank-Service).
• Die Verantwortung gegenüber den Endnutzern des HCC-Dienstes liegt, wie bisher in der TI, beim HCC-Dienstanbieter (Anbieter TI-Fachdienst).

13.2 Logging- und Monitoringsysteme

Der HCC-Provider ist dafür verantwortlich, geeignete und robuste Logging- und Monitoringsysteme bereitzustellen, die sich leicht in die Anwendungen der HCC-Diensteanbieter integrieren lassen. So können beispielsweise maschinennahe Lösungen wie Softwarebibliotheken mit standardisierten Logging-Zielen des HCC-Providers integriert oder auf Ebene der Laufzeitumgebung mittels Logging-Agent die Ausleitung von Textdaten umgesetzt werden. Ziel ist es, zu jeder Zeit genügend Informationen über den Zustand und die Funktionsfähigkeit des eingesetzten Cloud-Ressourcen zu erhalten und damit jederzeit Aussagen zum Gesundheitszustand der Laufzeitumgebung treffen zu können. Diese Anforderung gilt auch für die Netzwerkinfrastruktur vor der Anwendung, Managed-Services des HCC-Providers und die HCC-spezifischen Dienste.

Der HCC-Dienstanbieter ist dafür verantwortlich, Telemetrie- und Performancedaten in seiner Anwendung zu erheben und als Betriebsdaten an die gematik zu senden. Für Ressourcen, für die der HCC-Provider keine Performancedaten bereitstellt, muss die Anwendung des HCC-Dienstanbieters Verfügbarkeit und Performance messen und der gematik zugängig machen, u.a. damit die gematik eine SLA-Verletzung eindeutig dem HCC-Dienstanbieter oder HCC-Provider zuordnen kann.

Folgende Anstriche führen die hier gezeigten Lösungsideen weiter:

• Wie Loggingdaten des HCC-Providers zur gematik transportiert werden und wer für eine ggf. notwendige Konvertierung verantwortlich ist. 
• Der HCC-Provider stellt durch interne Kategorisierung sicher, dass Loggingdaten eindeutig einem Quellsystem zugeordnet werden können. Dies betrifft vorrangig Metadaten wie Umgebungstyp (DEV/PU/RU), den Dienst- und Mandantenkontext.

Die gematik aggregiert die Monitoring- und Observability-Daten beider Dienstleister zu einer systemisch konsolidierten E2E-Sicht. Diese Sicht bildet die operative Grundlage für alle übergreifenden Steuerungsentscheidungen. Die gematik konsolidiert eingehende Betriebsdaten zu einem plattformübergreifenden Lagebild und leitet daraus erforderliche Maßnahmen ab. Sicherheitsrelevante Ereignisse sind von allen Dienstleistern unverzüglich zu melden. 

13.3 Betriebliche Rollen und Verantwortung

Das HCC-Betriebsmodell gründet auf zwei abgegrenzten Akteuren, HCC-Cloud-Provider und HCC-Anwendungsbetreiber, mit eigenständigen Verantwortungssphären.

Der HCC-Provider betreibt eine mandantenfähige Cloud-Infrastruktur mit von der gematik definierten Vertrauensraäumen. Seine Leistung umfasst Rechenkapazität, Speicher, Netzwerktransport sowie Cloud-Services. Mandanten in einem gematik Vertrauensraum sind ausschließlich HCC-Dienstanbieter. Der HCC-Provider verantwortet den Nachweis der Infrastruktursicherheit durch anerkannte Zertifizierungen.

Der HCC-Dienstanbieter verantwortet als Anwendungsbetreiber den Betrieb des jeweiligen Dienstes im Mandantenkontext des HCC-Providers. Zu seinen Aufgaben zählen die Herstellung und Testung des Dienstes, Bereitstellung umgebungsabhängiger Konfiguration, Deployment in Referenz- und Testumgebungen, Begutachtung und Zulassung des Workload-Images, Überwachung und Steuerung des produktiven Dienstes, Nutzer-Rollout und Support.

Die gematik übernimmt als alleiniger Vertragshalter und SIAM-Integrator (Service Integration and Management) folgende zentrale Aufgabenbereiche:

• Erstens die Steuerung von Verträgen und Vergütung: aktive Überwachung der Leistungserbringung aller Lose (HCC-Provider & HCC-Diensteanbieter), Durchsetzung vertraglicher Verpflichtungen und Einhaltung des Schnittstellendesigns. 

• Zweitens das Multi-Provider-Management: Koordination der Dienstleister über Losgrenzen, Abstimmung übergreifender Roadmaps und Funktion als zentrale Eskalationsinstanz bei loskoordinierten Abhängigkeiten. 

• Drittens die Ende-zu-Ende-Verantwortung für Leistungsfähigkeit und Verfügbarkeit der Gesamtplattform sowie Koordination bei plattformübergreifenden Vorfällen.

13.4 Betriebliche Schnittstellen

Zur effizienten Verwaltung der HCC-Umgebung sind klar definierte organisatorische und technische Strukturen erforderlich. Dies umfasst insbesondere die Provisionierung und Administration von Ressourcen, die Mandantenverwaltung, eine konsistente Rechte‑ und Rollenverwaltung sowie die kontinuierliche Betriebsüberwachung.

Um einen sicheren, stabilen und revisionsfähigen Betrieb zu gewährleisten, sind Schnittstellen zwischen dem HCC‑Provider, der gematik sowie der HCC‑Mandanten‑Administration notwendig. Darüber hinaus muss die Vergabe und Verwaltung von Berechtigungen strikt nach dem Prinzip der minimalen Privilegien erfolgen, um Sicherheitsrisiken zu minimieren und die Verantwortlichkeiten transparent abzubilden.

13.5 Provisionierung und Service-Fullfillment

HCC Anbieter ist Laufzeit Umgebung für Dritte. Zusammenspiel, Aufsicht der gematik, muss einen Regisitrierungsprozess bei der gematik durchlaufen, in diesem Prozess werden Informationen über provisionierte Ressourcen/Komponenten/Dienste/Services bereitgestellt, um eine sichere komm mit anderen Diensten der TI und Integration in die Föderation zu ermöglichen.

13.6 Anwendbarkeit betrieblicher Prozesse (TI-ITSM)

Die nachfolgenden Ausführungen betrachten die IT Service Management Prozesse auf Basis des ITIL-Rahmenwerks und des aktuellen TI-Betriebsmodells. Die beschriebenen Prozesse sind dabei so gestaltet, dass sie mit dem bestehenden TI-ITSM-Rahmen der TI kompatibel sind und diesen erweitern, nicht ersetzen. Der aktuelle Fokus liegt auf Change Management und Incident Management, da diese Prozesse im Übergang zu einem Cloud-Betriebsmodell den größten konzeptionellen Anpassungsbedarf aufweisen. Die konkreten Anpassungsbedarfes für diese Prozesse sowie die übrigen ITSM-Prozesse werden im weiteren zeitlichen Verlauf detailliert ausgearbeitet.

13.6.1 Change Management

Das Change Management ist die prozessuale Schlüsselschnittstelle des Betriebsmodells. Die Trennung von Infrastruktur und Anwendung erzeugt zwei strukturell eigenständige Change-Pfade, die sich in ihren Freigabemechanismen, Vorlaufzeiten und Verantwortlichkeiten grundlegend unterscheiden. Eine Aufgabe mit besonderem Fokus ist die Ausdefinition der Change Management Prozesse über alle Change Auslöser hinweg mit unterschiedlichen Ausprägungen („Change Arten“), unter der Berücksichtigung der veränderten Rahmenbedingungen.

Der HCC-Provider ist Initiator und Durchführungsverantwortlicher für Infrastruktur-Changes. Dies umfasst Firmware, Hypervisor und Plattform-Software sowie alle weiteren TCB-relevanten Komponenten. Jeder Change-Antrag (RFC) enthält eine verpflichtende TCB-Relevanzprüfung. Bei positiver Bewertung ist ein Delta-Gutachten durch einen unabhängigen Gutachter obligatorisch.

Der HCC-Dienstanbieter verantwortet Workload-Changes vollständig im eigenen Mandantenkontext. Er plant und führt Deployments eigenständig durch, einschließlich der Wahl der Deployment-Strategie (Blue/Green oder Canary Release) und des Rollback-Mechanismus. Gegenüber der aktuelle TI-Architektur entsteht eine neue Pflicht: Die Kompatibilität des eigenen Workload-Images mit einer veränderten Infrastruktur ist bei jedem Infrastruktur-Change des HCC-Providers zu prüfen und zu bestätigen. 

Infrastruktur-Changes des HCC-Providers erzwingen beim HCC-Dienstanbieter damit eine unmittelbare operative Reaktion. Der HCC-Provider ist daher zur rechtzeitigen Ankündigung von Maintenance Windows verpflichtet. Der HCC-Dienstanbieter hat in einer zu definierenden Frist die Workload-Kompatibilität im Rahmen der dafür vorgesehenen Staging-Instanz zu prüfen und zwischen Bestätigung und Rollback zu entscheiden. Durch Instanziierung/ Staging kann das höchste Verfügbarkeitsniveau an der Schnittstelle der Dienstleister im Public Cloud Modell umgesetzt werden. 

Die gematik kann im Change-Prozess je nach Change Art unterschiedlich ausgeprägt sein. Die Rolle im Prozess kann zwischen Beobachter- und Unterstützer-Rolle sowie der Gate-Keeper-Rolle (Freigabe) variieren. Unter welchen Bedingungen welches Modell gilt, ist im weiteren zeitlichen Verlauf intensiv zu bearbeiten. Bei Root-of-Trust-relevanten Änderungen ist eine formale Zeremonie erforderlich. Changes, welche die Trusted Computing Base berühren, gehen nicht ohne erfolgreiche Attestation durch den TDCAS (Trust Domain Configuration and Attestation Service) in Betrieb, unabhängig von prozessualer Compliance. Zusätzlich verantwortet die gematik die Freigabe aller Workload-Images über den TI-Verification- and Build-Service sowie deren Registrierung im D&C Repository. Gleichzeitig kann auch hier der Betrieb durch Instanziierung und Staging in unverändert hoher Qualität aufrecht erhalten werden. Diese Kombination aus regulatorischem und technisch erzwungenem Durchgriff ist eine Weiterentwicklung des aktuell gelebten VAU-Konstrukts im bisherigen E-Rezept-Fachdienst. 

13.6.2 Incident Management

Incident Management im HCC-Betriebsmodell folgt derselben strukturellen Logik wie das Change Management: Die Trennung der Betriebssphären erzeugt eigenständige Zuständigkeitsbereiche mit einer systemisch kritischen Schnittstelle. Die entscheidende neue Herausforderung liegt nicht in den eindeutig zuordenbaren Incidents, sondern in jenen, deren Ursache an der Grenze zwischen Infrastruktur- und Anwendungssphäre liegt. Diese Schnittstelle muss in den Anforderungen und der Prozessgestaltung antizipiert werden.

Der HCC-Provider trägt die Lösungsverantwortung für alle Infrastruktur-Incidents. Dazu zählen Attestation-Fehler, Ausfälle von TCB-Komponenten und Rechenzentrum-Sicherheitsvorfälle. Der HCC-Cloud-Provider betreibt eigene First- und Second-Level-Prozesse innerhalb seiner Infrastruktursphäre und ist zur unverzüglichen Information des HCC-Dienstanbieter und der gematik bei betriebsrelevanten Ereignissen verpflichtet.

Der HCC-Dienstanbieter trägt die vollständige Lösungsverantwortung für Anwendungs-Incidents. Er ist Empfänger von Infrastruktur-Incident-Informationen und muss auf diese reaktiv antworten können, durch Failover oder strukturierten Dienst-Wiederanlauf, ohne dabei in die Ursachenbehebung auf Infrastrukturebene einzugreifen. Meldepflichten bei sicherheitsrelevanten Vorfällen gegenüber der gematik bleiben dem HCC-Dienstanbieter unverändert zugeordnet.

Die strukturell neue und höchste Prozessanforderung liegt bei Incidents, deren Ursache nicht unmittelbar einer Sphäre zuzuordnen sind. Eine Anwendungsstörung kann Symptom eines Infrastruktur-Incidents sein, der sich bspw. über fehlerhafte Attestation oder gesperrtes Schlüsselmaterial manifestiert. Ohne definierte Abgrenzungskriterien und Eskalationspfade entsteht an dieser Schnittstelle das operativ kritische „Ping-Pong-Risiko“ zwischen HCC-Provider und HCC-Dienstanbieter, mit direkten Auswirkungen auf Verfügbarkeit und SLA-Erfüllung. Die Abgrenzung ist daher vertraglich, in den Anforderungen und der Prozessgestaltung zu hinterlegen. Voraussetzung ist die Definition klar messbarer Messpunkte an der Infrastruktur-Workload-Grenze als Grundlage für die Ursachenzuordnung.  

Die gematik übernimmt im Incident Management eine Rolle als losübergreifender Eskalationsautorität und überbrückt damit die Verantwortungsgrenzen zwischen HCC-Provider und HCC-Dienstanbieter. Da beide Dienstleister jeweils nur ihre eigene Sphäre vollständig überblicken, erwächst der gematik daraus eine aktive Betriebsaufgabe. Incident-Informationen des HCC-Providers werden zwar bereitgestellt, müssen jedoch von der gematik, insbesondere an der Schnittstelle zwischen den Dienstleistern, im Bedarfsfall aktiv überwacht, konsolidiert, ausgewertet und nachgesteuert werden. Erst durch diese aktive Auswertung, auf Basis Betriebsdaten, entsteht der notwendige Informationsumfang, um als neutrale und informierte Schiedsinstanz auftreten zu können. 

13.6.3 ITSM-Toolanbindung

Der HCC-Provider sowie der HCC-Dienstanbieter betreiben jeweils ein eigenständiges ITSM-Tool, das über eine standardisierte Schnittstelle bidirektional an das zentrale ITSM-System der gematik angebunden wird, so dass eine übergreifende Bearbeitung von Changes, Incidents, Problems und anderem erfolgen kann.

14 Anforderungen an HCC

14.1 HCC-Provider – marktoffenes Angebot

Die Anforderungen in diesem Abschnitt sollen sicherstellen, dass Healthcare Confidential Computing von unabhängigen Dienst- und Anwendungsanbietern genutzt werden kann.

[Herstellererklärung]

Hinweis: Die tatsächliche Nutzung von HCC durch einen Dienstanbieter für einen HCC-Dienst in der TI steht unter dem Vorbehalt der Zulassung des Dienstanbieters und des Dienstes durch die gematik.

[Herstellererklärung]

[Herstellererklärung]

Hinweis: A_26835 stellt keine Sicherheitsanforderung dar, sondern eine Anforderung zur Realisierung eines marktoffenen Angebots.

[Herstellererklärung]

[Herstellererklärung]

14.2 HCC-Provider – Bereitstellung HCC-Infrastruktur

Die Anforderungen in diesem Abschnitt dienen der Darstellung des grundlegenden HCC-Provider Angebots sowie der Abgrenzung zwischen HCC-Providern und anderen Anbietern innerhalb der TI.

14.2.1 Cloud-Infrastruktur

[Anbietererklärung]

[Sicherheitsgutachten]

[Sicherheitsgutachten]

[Sicherheitsgutachten]

[Anbietererklärung]

Offen: Anforderung in gemSpec_Perf präzisieren

[Sicherheitsgutachten]

[Anbietererklärung]

Offen: Schema für die initial kalkulierte und später aus Betriebsdaten abgeschätzte Maximallast entwickeln

[Produktgutachten]

[Sicherheitsgutachten, Produktgutachten]

Hinweis: Autoscaling kann z. B. als Funktion von Managed Kubernetes umgesetzt sein.

[Sicherheitsgutachten, Produktgutachten]

14.2.2 DDoS-Abwehr

[Sicherheitsgutachten]

[Produktgutachten]

Hinweis: Die Anforderung besteht sowohl beim Einsatz eigener Systeme zur DDoS-Abwehr als auch bei der Zusammenarbeit mit einem spezialisierten Anbieter.

[Produktgutachten]

[Sicherheitsgutachten]

14.3 HCC-Provider – Integration mit gematik

Die Anforderungen in diesem Abschnitt definieren die in der Laufzeitumgebung des HCC-Providers implementierte Beziehung zwischen der gematik als Trust Domain Provider für HCC und dem HCC-Provider als Betreiber seiner Infrastruktur. Die Beziehungen zwischen den HCC-Dienstanbietern und der gematik bauen auf dieser Beziehung auf.

[Herstellererklärung, Test durch gematik]

[Produktgutachten]

[Herstellererklärung, Test durch gematik]

Hinweis: Das Trust Domain Deployment Repository kann als „Partition“ im Cloud Management System des HCC-Providers umgesetzt sein, d. h. es wird nicht zwingend ein eigenes System oder eine eigene Dienstinstanz gefordert.

Hinweis: Der Vertrauensanker kann in einer „Partition“ eines auch für andere Zwecke eingesetzten HSM-Clusters verwaltet werden.

[Produktgutachten]

[Herstellererklärung, Test durch gematik]

[Herstellererklärung, Test durch gematik]

[Herstellererklärung, Test durch gematik]

[Produktgutachten]

[Herstellererklärung, Test durch gematik]

[Herstellererklärung, Produktgutachten]

Hinweis: Für diese Ebene der TI-Policy ist derzeit keine formale Darstellung verfügbar. Die Anforderung ist so zu interpretieren, dass der in dieser Spezifikation dargestellte Funktionsaufbau für HCC im Sinne einer Policy interpretiert und funktionsfähig gemacht wird.

14.4 HCC-Provider – Mandanten für HCC-Dienstanbieter

Als Cloud-Provider stellt der HCC-Provider jedem seiner Kunden, den Anbietern von HCC-Diensten, einen individuellen Zugang in Form eines Mandantenkontextes zur Verfügung.

[Herstellererklärung, Produktgutachten]

[Herstellererklärung]

[Herstellererklärung]

[Herstellererklärung]

Hinweis: Unter einem HCC-Dienst zugeordnete Policies fallen beispielsweise die Access Control Policies von Zero Trust Komponenten.

Hinweis: Das Einbinden von Standardkomponenten der TI und dem HCC-Dienst zugeordneten Policies kann beispielsweise über Sidecar-Muster oder Service Mesh Konfiguration erfolgen.

[Produktgutachten]

[Herstellererklärung, Produktgutachten, Test durch gematik]

[Herstellererklärung]

[Produktgutachten]

[Herstellererklärung]

[Produktgutachten]

[Herstellererklärung, Produktgutachten, Test durch gematik]

[Herstellererklärung]

Hinweis: Bei den zu integrierenden Diensten kann es sich um HCC-Dienste in seiner Infrastruktur oder in der Infrastruktur eines anderen HCC-Providers oder um Nicht-HCC-Dienste handeln.

[Produktgutachten]

Offen: Anwendung der Policy Administration der gematik auf die Gateways

[Herstellererklärung]

14.5 HCC-Provider – HCC-Sicherheitsfunktionalität

Neben den betrieblichen und fachlichen Funktionalitäten, die der HCC-Provider für die gematik und für HCC-Dienstanbieter bereitstellt, um HCC-Dienste zur Ausführung bringen zu können, und neben den Sicherheitsanforderungen, die seine betrieblichen Umgebungen (Rechenzentrumsstandorte) sowie seine Systeme, Software und Prozesse erfüllen, um die in Kapitel 9 Zulassungen und Bestätigungen geforderten Zertifizierungen zu erhalten, müssen HCC-Provider Sicherheitsfunktionalitäten implementieren, die zur Erreichung des besonders hohen Sicherheitsstandards von HCC erforderlich sind.

[Produktgutachten]

Hinweis: Die Anforderung gilt nur für die vom HCC-Provider verantworteten Teile des Gesamtsystems. Dieses muss jedoch in jedem Fall eine Erreichung des Sicherheitsziel ermöglichen, wenn alle anderen Akteure ihre Anteile am Gesamtsystem entsprechend umsetzen.

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

Hinweis: Die Beschränkung der Geo-Location kann dabei über eine Whitelist, eine Blacklist oder über eine Kombination von beidem umgesetzt werden, bei der je Mandantenkontext neu entschieden werden kann, ob eine Whitelist oder eine Blacklist genutzt wird. Die Granularität der Geo-Locations soll dabei auf dem Level von Staaten umgesetzt werden. Ist eine Konfiguration der Beschränkung der Geo-Locations durch den HCC-Provider vorgesehen, muss die Auswahl der plausiblen Geo-Locations, auf die der Zugriff eingeschränkt wird, in Absprache mit dem Mandanten (der gematik bzw. dem HCC-Dienstanbieter) geschehen.

[Herstellererklärung]

[Produktgutachten]

14.6 HCC-Provider – Sicherheitsanforderungen

14.6.1 Bereitstellung geeigneter Hardware

[Anbieterklärung]

[Anbietererklärung, Audit durch gematik]

[Anbietererklärung, Sicherheitsgutachten]

[Anbietererklärung]

[Anbietererklärung, Sicherheitsgutachten]

[Sicherheitsgutachten]

[Sicherheitsgutachten]

[Sicherheitsgutachten]

[Herstellererklärung, Audit durch gematik]

Hinweis: Für die Signer-ID des HCC-Providers für den Onboarding-Protokolleintrag kann der HCC-Provider im Zuge des Zulassungsverfahrens einen Vorschlag machen. Z. B. könnte das Asset Management System des HCC-Providers selbst die Übertragung steuern und zu diesem Zweck mit einer Signer-ID ausgestattet werden. Die Signer-ID und das sie verwendende System müssen dafür entsprechenden Schutz gegen Verlust und missbräuchliche Verwendung aufweisen.

[Produktgutachten]

Hinweis: Für die Machbarkeit dieses Nachweises kann die Architektur der Confidential Computing Lösung entscheidend sein, z. B. wenn die Cloud Management Software im Wesentlichen außerhalb der Trusted Computing Base ausgeführt wird.

[Sicherheitsgutachten]

[Sicherheitsgutachten]

Hinweis: Hierbei handelt es sich um den Signaturschlüssel für die Attestation Reports, der in die Hardware der HCC-Hosts vom Hersteller der CPU oder des TPM eingebracht ist (Root of Trust for Measurement).

Hinweis: Der Nachweis kann durch Nutzung eines Fremdherstellers geeigneter Reputation erbracht werden oder durch Zertifizierung eigner Root of Trust Komponenten auf hohem Evaluierungsniveau.

[Sicherheitsgutachten]

14.6.2 Schutz der Integrität der VAU

Im Folgenden wird die beim HCC-Provider betriebene Umgebung für HCC als Vertrauenswürdige Ausführungsumgebung (VAU) bezeichnet. Dies entspricht der bisherigen Benennung in entsprechenden Spezifikationen der gematik und stellt eine für die Formulierung der Sicherheitsanforderungen weiterhin geeignete Abstraktion gegenüber der konkreten Architektur von HCC dar.

Die Anforderungen richten sich an den HCC-Provider, an den HCC-Dienstanbieter oder an die HCC-Workload (Dienst-Software), je nach Quelle des Gegenstands der jeweiligen Anforderung.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

Hinweis: Für den geforderten Integritätsschutzes der Hardware ist es ausreichend, wenn HCC-Server und Hosts zur Ausführung der HCC Platform Services durch Gehäuse geschützt sind, die eine Manipulation hinreichend erschweren, um Manipulationen für die Prozesse der Sicherheitsüberwachung im Rechenzentrum, die für die Zertifizierung des Anbieters nach C5 Typ 2 umgesetzt sind, zuverlässig erkennbar werden zu lassen. Die Sicherheitsüberwachung muss dabei durch Personen durchgeführt und verantwortet werden, die nicht selbst zum Kreis der Zutrittsberechtigten zu den Räumlichkeiten gehören, in denen die HCC-Hosts betrieben werden. Für die Gehäuse von HSMs gelten die Anforderungen der FIPS-Zertifizierung.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

Hinweis: Die Umsetzung kann dadurch erfolgen, dass die Laufzeitumgebung auf den HCC-Hosts (z. B. Hypervisor, Container-Runtime) so konfiguriert ist, dass sie nur Workload-Images aus dem (authentifizierten) Trust Domain Deployment Repository ausführt und dass das Trust Domain Deployment Repository nachweislich nur entsprechend signierte und nicht zurückgezogene Workload-Images enthält.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider als Provider des TDCAS und der attestationsfähigen Server-Plattform und an das Workload-Image, das die Attestation initiieren muss.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider als Provider des TDCAS und der attestationsfähigen Server-Plattform und an das Workload-Image, das die Attestation initiieren muss.

[Produktgutachten]

Hinweis: Die Anforderungen stellt sicher, dass die attestierte Integrität der Betriebssystemumgebung über den gesamten Boot-Zyklus eines HCC-Hosts erhalten bleiben kann. Updates erfordern daher grundsätzlich einen Neustart des HCC-Hosts.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

Hinweis: Die Umsetzung kann z. B. dadurch erfolgen, dass die Konfiguration nur bei der Instanziierung der Workload ausgewertet wird, so dass spätere Änderungen an Konfigurationsdateien keine Auswirkungen haben können.

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

14.6.3 Schutz der Datenverarbeitung

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider, den HCC-Dienstanbieter und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider, den HCC-Dienstanbieter und an das Workload-Image.

Hinweis: Diese Anforderung kann durch hinreichend tiefe Prüfung der Software des Dienstes auch für Verarbeitungskontexte erfüllt werden, die auf Thread-Ebene voneinander getrennt sind, wie z. B. bei regulären HTTP-Servern.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

Hinweis: Die Daten können in verschlüsselter Form in einem (ggf. verteilten) In-Memory-Cache gehalten werden, um folgende Requests – ggf. in einer anderen Instanz des Dienstes – performant beantworten zu können.

14.6.4 Schutz der Daten bei Speicherung

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

14.6.5 Schutz der Daten beim verteilten Caching

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

Hinweis: Der Wechsel des Cache-Schlüssels muss so umgesetzt werden, dass dafür keine Unterbrechung des Dienstes erforderlich wird und dass keine noch relevanten Cache-Inhalte unbrauchbar werden.

14.6.6 Schutz der Daten beim Transport

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

[Produktgutachten]

[Produktgutachten]

Hinweis: Die Anforderung richtet sich an den HCC-Provider und an das Workload-Image.

14.6.7 Konsistenz des Systemzustands, Logging und Monitoring

[Produktgutachten]

Hinweis: Diese Anforderung ist insbesondere dann von Bedeutung, wenn in Verarbeitungskontexten mehrere gleichzeitig aktive Nutzer-Sessions auf einen gemeinsam genutzten Datenbestand zugreifen können und die transaktionale Integrität des Datenbestandes gewährleistet werden muss.

[Produktgutachten]

14.7 HCC-Provider – Trust Domain Services und Komponenten

[Herstellererklärung]

14.7.1 Trust Domain Deployment Repository

[Produktgutachten]

Hinweis: Bei den Artefakten handelt es sich um Workload-Images, für den Betrieb der Workload-Images relevante Konfigurationsdatensätze sowie Policy Sets.

[Produktgutachten]

[Produktgutachten]

Hinweis: Berechtigter HCC-Mandant ist im Regelfall der Dienstanbieter, der das Workload-Image bzw. die dazu gehörenden Konfigurations- und Policy-Datensätze eingebracht hat. In anderen Fällen, z. B. für durch die gematik bereitgestellte Zero Trust Komponenten, ist für diese Artefakte explizit festgelegt, dass sie z. B. für alle HCC-Mandanten nutzbar sind.

[Produktgutachten]

14.7.2 Trust Domain Configuration & Attestation Service

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

Hinweis: Der TDCAS und Repliken seiner Konfigurationsdatenbank werden in alle Rechenzentrumsstandorte des HCC-Providers verteilt. Der TDCAS in einer Location kann nur HCC-Workloads in derselben Location attestieren.

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Herstellererklärung]

Hinweis: (Auszug aus dem konzeptionellen Teil dieser Spezifikation) Das Pairing des TDCAS mit dem Root of Trust basiert auf dem Einbringen eines Authentisierungsschlüssels für den HSM-Zugriff auf dedizierten TDCAS-Hosts. Der TDCAS wird als Confidential Service ausgeführt. Der Schlüssel wird als Sealed Key, d. h. mittels eines in der Hardware verankerten Schlüssels verschlüsselt, lokal gespeichert, so dass er nach einem Neustart des TDCAS-Hosts wieder verfügbar ist. Das Sealing berücksichtigt die Werte aus dem Measured Boot Process, so dass der Authentisierungsschlüssel nur dann wiederhergestellt werden kann, wenn dieselbe Software auf demselben Host gestartet wurde. Key Rolling und Update der Software werden durch einen darauf aufbauenden Mechanismus unterstützt.

[Produktgutachten]

[Herstellererklärung]

[Produktgutachten]

Hinweis: (Auszug aus dem konzeptionellen Teil dieser Spezifikation) Das Pairing des TDCAS mit dem Root of Trust basiert auf dem Einbringen eines Authentisierungsschlüssels für den HSM-Zugriff auf dedizierten TDCAS-Hosts. Der TDCAS wird als Confidential Service ausgeführt. Der Schlüssel wird als Sealed Key, d. h. mittels eines in der Hardware verankerten Schlüssels verschlüsselt, lokal gespeichert, so dass er nach einem Neustart des TDCAS-Hosts wieder verfügbar ist. Das Sealing berücksichtigt die Werte aus dem Measured Boot Process, so dass der Authentisierungsschlüssel nur dann wiederhergestellt werden kann, wenn dieselbe Software auf demselben Host gestartet wurde. Key Rolling und Update der Software werden durch einen darauf aufbauenden Mechanismus unterstützt.

[Produktgutachten]

[Herstellererklärung]

Hinweis: Der TDCAS und Repliken seiner Konfigurationsdatenbank werden in alle Rechenzentrumsstandorte des HCC-Providers verteilt. Der TDCAS in einer Location kann nur HCC-Workloads in derselben Location attestieren.

[Herstellererklärung]

14.7.3 Trust Domain Build Service

[Produktgutachten]

Hinweis: Die Web-Schnittstelle zur manuellen Durchführung der Konvertierung soll Entwicklungs-, Test- und Deployment-Aktivitäten unterstützen.

Hinweis: Die generischen Workload-Images sollen einem weit verbreiteten Standard für Binaries oder Container entsprechen und mittels weit verbreiteten, offenen und bestenfalls lizenzfreien Entwicklungswerkzeugen hergestellt werden können.

[Herstellererklärung]

[Produktgutachten]

[Herstellererklärung]

14.7.4 HSM-Cluster

[Anbietererklärung]

[Anbietererklärung]

[Anbietererklärung]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

[Produktgutachten]

14.7.5 HCC-Hosts

[Herstellererklärung]

[Produktgutachten]

[Produktgutachten]

14.7.6 HCC-Stack

[Produktgutachten]

[Herstellererklärung]

[Produktgutachten]

[Produktgutachten]

14.7.7 Key Management Service

[Herstellererklärung, Produktgutachten]

[Produktgutachten]

Hinweis: Die Bereitstellung des KMS ist eine KANN-Anforderung und die Anforderung gilt nur dann, wenn auch ein KMS bereitgestellt wird.

[Produktgutachten]

Hinweis: Die Bereitstellung des KMS ist eine KANN-Anforderung und die Anforderung gilt nur dann, wenn auch ein KMS bereitgestellt wird.

[Produktgutachten]

Hinweis: Die Bereitstellung des KMS ist eine KANN-Anforderung und die Anforderung gilt nur dann, wenn auch ein KMS bereitgestellt wird.

[Produktgutachten]

Hinweis: Die Bereitstellung des KMS ist eine KANN-Anforderung und die Anforderung gilt nur dann, wenn auch ein KMS bereitgestellt wird.

14.7.8 Weitere Dienste

[Herstellererklärung]

[Herstellererklärung]

[Herstellererklärung]

[Herstellererklärung]

Hinweis: Aufgrund der in solchen Diensten stattfindenden Verarbeitung unverschlüsselter personenbezogener medizinischer Daten im Klartext müssen Dienste nach A_26846 als HCC-Dienste zugelassen werden, wobei der HCC-Provider in dem Zulassungsprozess in einer dualen Rolle als HCC-Diensthersteller und HCC-Dienstanbieter fungiert. Es werden somit dieselben (hohen) Anforderung an die sicherheitstechnische Prüfung gestellt wie an andere HCC-Dienste.

14.7.9 Sicherheitsgutachten

Die in diesem Abschnitt verzeichneten Festlegungen sind Gegenstand der Prüfung der Sicherheitseignung gemäß [gemRL_PruefSichEig_DS]. Das entsprechende Sicherheitsgutachten ist der gematik vorzulegen.

Tabelle 3: Festlegungen zur sicherheitstechnischen Eignung "Sicherheitsgutachten"

14.7.10 Herstellererklärung funktionale Eignung

In diesem Abschnitt sind alle funktionalen und nichtfunktionalen Festlegungen an den technischen Teil des Produkttyps verzeichnet, deren durchgeführte bzw. geplante Umsetzung und Beachtung der Hersteller bzw. der Anbieter durch eine Herstellererklärung bestätigt bzw. zusagt. 

Tabelle 4: Festlegungen zur funktionalen Eignung "Herstellererklärung"

14.7.11 Herstellererklärung sicherheitstechnische Eignung

Sofern in diesem Abschnitt Festlegungen verzeichnet sind, muss der Hersteller bzw. der Anbieter deren Umsetzung und Beachtung zum Nachweis der sicherheitstechnischen Eignung durch eine Herstellererklärung bestätigen bzw. zusagen.

Tabelle 5: Festlegungen zur sicherheitstechnischen Eignung "Herstellererklärung"

14.8 Anforderungen an HCC-Dienstanbieter

Dieser Abschnitt wird in einer zukünftigen Version der Spezifikation ausgearbeitet.

[Sicherheitsgutachten]

14.9 Anforderungen an die HCC-Dienste der gematik

Dieser Abschnitt wird in einer zukünftigen Version der Spezifikation ausgearbeitet.

14.10 Anforderungen an HCC-Clients

Anforderungen an HCC-Clients wird in dieser Spezifikation nicht betrachtet, sondern in den Spezifikationen zu ZeroTrust (ZETA)

Die Vertraulichkeit auf Cloud-Seite wird erreicht, indem die Serverkomponente ZETA-Guard als HCC-Workload innerhalb der VAU läuft.

15 Anhang A – Verzeichnisse

15.1 A1 – Abkürzungen

Tabelle 6 : Im Dokument verwendete Abkürzungen

15.2 A2 - Glossar

Tabelle 7 : Glossar der explizit im Dokument verwendeten Begriffe

Weitere Begriffserklärungen befinden sich in [gemGlossar].

15.3 A3 – Abbildungsverzeichnis

15.4 A4 – Tabellenverzeichnis

15.5 A5 – Referenzierte Dokumente

15.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. 

Tabelle 8 : Referenzierte Dokumente der gematik

15.5.2 Weitere Dokumente

Tabelle 9 : Weitere Referenzen