Freigeben über

Schlüsselverwaltungskontrollen

In diesem Artikel werden wichtige Verwaltungskontrollen für souveräne Cloudszenarien erläutert, wobei sie sich auf die Sicherheitsüberlegungen und Kompromisse zwischen verschiedenen Ansätzen zur Schlüsselverwaltung und Souveränität konzentrieren. Es bietet Anleitungen für Organisationen, die bewerten, wo ihre kryptografischen Schlüssel basierend auf Souveränität, Compliance und betrieblichen Anforderungen gespeichert und verwaltet werden sollen.

Umfassende Informationen zu den wichtigsten Verwaltungslösungen von Azure, einschließlich detaillierter Produktvergleiche und Auswahlleitfaden, finden Sie unter:

Azure Key Vault verwaltete HSM für Schlüssel-Souveränität

Kryptografieschlüssel sind für den Schutz vertraulicher Daten und die Gewährleistung der Integrität und Authentizität digitaler Transaktionen unerlässlich. Organisationen, die wichtige Verwaltungsansätze für souveräne Cloudszenarien bewerten, müssen die verfügbaren Optionen und ihre Kompromisse verstehen.

Azure Key Vault verwaltete HSM bietet wichtige Souveränität über FIPS 140-3 Stufe 3 validierte Sicherheit mit vollständiger Kundensteuerung von Schlüsseln, Einzelmandantenisolierung und kundengesteuerten Sicherheitsdomänen – während die Vereinbarungen auf Dienstebene von Azure beibehalten wird und den betrieblichen Aufwand der physischen HSM-Verwaltung eliminiert. Weitere Informationen finden Sie unter Azure Key Vault Managed HSM.

Azure erweitert weiterhin sein Schlüsselverwaltungsportfolio, um vielfältige Souveränitätsanforderungen zu erfüllen. In diesem Artikel wird auch die externe Schlüsselverwaltung als konzeptioneller Ansatz erläutert, bei dem Schlüssel in kundeneigenen HSMs physisch von der Cloudinfrastruktur getrennt werden, um Kontext für die Bewertung verschiedener Souveränitätsmodelle bereitzustellen.

Schlüsselschutzarchitektur

Bei der Auswertung von Schlüsselverwaltungslösungen ist es wichtig, die Angriffsvektoren zu verstehen, die die Schlüsselsicherheit gefährden könnten:

Private Schlüsselmaterialextraktion: Das private Schlüsselmaterial wird durch viele Mechanismen geschützt, die ein physisches HSM bereitstellt. Das Extrahieren der Schlüssel kann zu Offlineangriffen führen, bei denen ein Angreifer eine Kopie der verschlüsselten Daten und der privaten Schlüssel aus dem HSM benötigt. Standardmäßig schützt ein HSM sowohl innerhalb als auch außerhalb des HSM private Schlüsselmaterial oder private Schlüssel. Für den Schutz verlassen sich HSMs auf Sicherheitswelten oder Partitionen, um das Schlüsselmaterial innerhalb und außerhalb des HSM zu sichern. Die Umhüllungs- und Entschlüsselungsfunktionen (Verschlüsseln oder Entschlüsseln eines Schlüssels zur Datenverschlüsselung) eines Schlüssels sollten nur innerhalb der vertrauenswürdigen Umgebung des HSM ausgeführt werden. Darüber hinaus sind auch geschützte Sicherungen und geschützter externer Schlüsselspeicher verfügbar. Das HSM behandelt den Schutz durch Verpacken des gesamten Materials und verlässt das HSM mit einem Maskierungsschlüssel, der nur für die Partition bekannt ist, von der der Schlüssel losgelassen wird. In der Regel kann nur die Kombination aus maskierendem Schlüssel und HSM-Sicherung einen privaten Schlüssel verfügbar machen. In einigen Fällen können Schlüssel jedoch als exportierbar gekennzeichnet werden, sodass sie das HSM in einem nicht geschützten Zustand belassen können.

Nicht autorisierte Nutzung des Diensts: Obwohl das HSM die Schlüssel schützt, können Angreifer den Dienst missbrauchen, ohne dass die Schlüssel verloren gehen. Nicht autorisierte Benutzer, die die Wrap/Unrap-Funktion der Schlüsselverwaltungs-API (fronting the HSM) verwenden können, können den Datenverschlüsselungsschlüssel (DEK) verfügbar machen, indem sie die verschlüsselte DEK an den Dienst senden und daher die durch die DEK geschützten Daten kompromittieren. Während das HSM das private Schlüsselmaterial schützt, muss die API vor dem HSM, das zwischen dem aufrufenden Dienst und dem HSM interagiert, ebenfalls geschützt werden.

Zum Sichern von Schlüsseln müssen sowohl die HSM-Grenze als auch die umgebenden Dienste und Architekturen geschützt werden, die mit dem HSM interagieren.

Über Azure Key Vault verwaltetes HSM

Azure Key Vault Managed HSM ist ein vollständig verwalteter, cloudbasierter HSM-Dienst, der FIPS 140-3-Level 3 überprüfte Sicherheit mit Einzelmandantenisolation und vollständiger Kundenkontrolle kryptografischer Schlüssel bereitstellt. Dieser Dienst bietet eine wichtige Souveränität und gleichzeitig die betriebliche Einfachheit. Ausführliche Informationen zu dem Dienst, seinen Funktionen und der Architektur finden Sie unter Was ist azure Key Vault Managed HSM?

Der Dienst behandelt wichtige Sicherheitsanforderungen durch vertrauliche Computerarchitektur:

Verwaltete HSM-Architektur

Highlights der Sicherheitsarchitektur

Azure Key Vault Managed HSM nutzt Azure Confidential Computing , um eine Umgebung zu erstellen, die der externen HSM-Sicherheit entspricht oder überschreitet. Umfassende technische Details finden Sie in den technischen Details von Managed HSM.

  • Für jede Instanz, die der Kunde verwendet, wird eine Trusted Execution Environment (TEE) erstellt.
  • Der TEE basiert auf externen Vertrauensstellungen und Schlüsseln außerhalb der Microsoft-Kontrolle (Intel Software Guard Extensions (SGX)).
  • Alle geheimen Schlüssel, die vom Dienst verwendet werden, werden innerhalb der TEE-gesicherten Instanz generiert.
  • Keine geheimen Klartextschlüssel im aktiven Speicher auf den physischen Hosts
  • Kein Mensch oder System außerhalb der vertrauenswürdigen Umgebung verfügt über die HSM-Anmeldeinformationen.
  • Der Zugriff auf den Dienst ist programmgesteuert auf die Microsoft Entra-ID-Instanz des Kunden beschränkt.
  • Nur Kunden können die Sicherheitsdomäne anfordern, herunterladen und entschlüsseln (einschließlich Maskierungsschlüssel). Diese Informationen werden nicht in der Cloud gespeichert.
  • Private Schlüsselmaterial im HSM ist auf nichtexportierbar festgelegt, es sei denn, es wird eine sichere Schlüsselfreigabe angefordert. Normale Schlüssel sind nicht exportierbar, und das HSM gibt daher das private Schlüsselmateriel nicht in einem unmaskierten Zustand frei.
  • Das HSM verfügt über einen Audit-Log, um Interaktionen auf der HSM-Partition zu protokollieren und anzuzeigen.

Sicherheitsbewertung gegen Angriffsvektoren

Da das HSM und die Schlüssel in der Azure-Infrastruktur gehostet werden, ist es wichtig, den Schutz vor den beiden primären Angriffsvektoren zu bewerten:

Private Schlüsselmaterialextraktion:

  • Ein Marvel Liquid HSM, das normale Firmware ausführt, wird verwendet, um den schutz des privaten Schlüsselmaterials zu gewährleisten.
  • Die Anmeldeinformationen für das HSM selbst sind nicht lesbar und werden ausschließlich in den vertrauenswürdigen Ausführungsumgebungen des Systems gespeichert.
  • Der Maskierungsschlüssel, der die privaten Schlüsselmaterialien schützt, liegt ausschließlich beim Kunden – geschützt durch die schlüssel, die Sie generieren und verwalten – und es liegt in der Verantwortung des Kunden, den Maskierungsschlüssel zu schützen. Diese Trennung stellt sicher, dass die Schlüssel (Sicherungen) und der Maskierungsschlüssel (Schutz für diese Schlüssel) an zwei verschiedenen Stellen gespeichert werden.
  • Während Microsoft Azure vollständige Sicherungen des physischen HSM (einschließlich aller Partitionen) ausführen kann, wird diese Sicherung durch jeden einzelnen Partitionsmaskenschlüssel geschützt (auf den nur der Kunde Zugriff hat, geschützt durch die Schlüsselpaare, die der Kunde erstellt und verwaltet)
  • Beabsichtigte oder unbeabsichtigte Gefährdung der Sicherheitsdomäne bietet keinen Zugriff auf die Schlüssel. Damit Angreifer Zugriff auf privates Schlüsselmaterial erlangen können, müssten sie Zugriff auf eine (Schlüssel)-Sicherung, die Sicherheitsdomäne und die vom Kunden generierten Schlüssel erhalten, die zur Absicherung der Sicherheitsdomäne verwendet werden.
  • Beabsichtigte oder unbeabsichtigte Gefährdung der Sicherung würde Es Angreifern nicht ermöglichen, Zugriff auf private Schlüsselmaterial zu erhalten, da sie auch über die Sicherheitsdomäne und die vom Kunden generierten Schlüssel verfügen müssen, um die Sicherheitsdomäne zu schützen, die nicht in Azure gespeichert werden sollte.

Nicht autorisierter Zugriff oder verwendung:

  • Der Zugriff auf den Dienst ist auf die microsoft Entra ID-signierten Authentifizierungstoken des Kunden beschränkt. Der Dienst verwendet zwei ACL-Listen: Azure RBAC zum Erstellen und Löschen von Instanzen und HSM RBAC für HSM-Rollen. Während eine einzelne Entra-ID verwendet wird, kann ein Azure-Abonnementbesitzer keine erzwungene Kontrolle über das verwaltete HSM übernehmen, wenn er keinen Zugriff auf das HSM hat.
  • Eine Notfall-HSM-Administratorrolle ist für die Gruppe "Globale Entra-ID-Administratoren" vorhanden. Unabhängig von den Berechtigungen für Azure-Abonnements ermöglicht der Zugriff auf die verwaltete HSM-Instanz einem globalen Entra-ID-Administrator die Kontrolle über das HSM. Es bietet ihnen keinen Zugriff auf private Schlüsselmaterialien, ermöglicht es ihnen jedoch, die HSM-ACL-Liste zu ändern. Vorsicht bei globalen Administratormitgliedschaften ist erforderlich.
  • Die Anmeldeinformationen jeder einzelnen HSM-Partition werden niemals preisgegeben, und deshalb können nicht autorisierte Systeme oder Personen diese Anmeldeinformationen nicht unbefugt verwenden.
  • Die TLS-Zertifikate (https) werden von und innerhalb der Trusted Execution Environment generiert, wodurch der private Schlüssel der TLS-Verbindungen des Diensts ausschließlich für die Instanz verfügbar ist.
  • Der Front-End-Dienst wird vollständig in vertraulichen Computern ausgeführt, und der externe Zugriff durch andere Systeme oder Menschen ist nicht möglich. Die Instanz kann nicht in einen kompromittierten Host verschoben werden, da sich die TEE-Parameter ändern können. Darüber hinaus ist der Zugriff auf den "geheimen Speicher", der die Anmeldeinformationen und privaten Dienstschlüssel enthält, nur aufgrund der Verwendung eines CPU-Versiegelungsschlüssels innerhalb des TEEs auf der ursprünglichen physischen CPU möglich.

Zusätzliche Sicherheitsfeatures:

  • Der Dienst verfügt über integrierte Redundanzen. Jeder erstellte verwaltete HSM-Dienst erstellt 3 (einzelne) Back-End-Instanzen. Der Schlüsselaustausch zwischen den Instanzen wird durch einen Datenbankverschlüsselungsschlüssel (gemeinsam zwischen allen Instanzen) und dem HSM-Partitionsformatierungsschlüssel gesichert, wodurch sichergestellt wird, dass privates Schlüsselmaterial nur zwischen Instanzen im selben Dienst ausgetauscht werden kann und dass auf private Schlüsselmaterialien nur zugegriffen werden kann, wenn sie in die HSM-Partitionen importiert werden, die derselben Dienstinstanz angehören.
  • Verwaltungs- und Betriebsverfahren auf den HSMs sind auf Azure Fabric-Controller beschränkt. Daher können Vorgänge außerhalb des zulässigen Bereichs, die nicht in den Dienst integriert sind, nicht aufgerufen werden. Direkter Zugriff auf die Partitionen (und daher Schlüsselvorgänge oder partitionsweite Vorgänge) ist auf jede eindeutige Instanz innerhalb ihrer jeweiligen TEEs beschränkt. Es ist kein menschlicher oder nicht autorisierter Zugriff auf die Partition möglich, da die Anmeldeinformationen zu einer Partition nur der jeweiligen Instanz bekannt sind.

Ausführliche Informationen zu verwalteter HSM-Architektur, Sicherheitsfeatures und bewährten Methoden finden Sie unter:

Architektur der externen Schlüsselverwaltung

Die verwaltung externer Schlüssel ist ein konzeptioneller Ansatz, bei dem Organisationen ihre eigenen Hardwaresicherheitsmodule (HARDWARE Security Modules, HSMs) für kryptografische Vorgänge verwenden, während Clouddienste genutzt werden, wobei Schlüssel physisch von Daten und Cloudinfrastruktur getrennt werden.

Dieser Abschnitt bietet Bildungskontext für das Verständnis externer Schlüsselverwaltungsarchitekturen, deren Sicherheitsüberlegungen und betrieblicher Kompromisse. Dieses Architekturmuster kann bei der Bewertung von Souveränitätsanforderungen mit cloudverwalteten HSM-Diensten wie Azure Key Vault Managed HSM verglichen werden. Informationen zu den wichtigsten Verwaltungsfunktionen von Azure finden Sie unter:

Architekturen für externe Schlüsselspeicher

Architekturkomponenten

Eine Architektur eines externen Schlüsselspeichers umfasst in der Regel vier Komponenten:

  • Der Clouddienst: Dieser Dienst ruft einen Schlüsselverwaltungsdienst auf, um die unverschlüsselte DEK bereitzustellen, die zum Verarbeiten/Entsperren der Daten erforderlich ist. Der Clouddienst verwendet in der Regel eine (verwaltete) Identität, um sich selbst für den gezielten Schlüsselverschlüsselungsschlüssel zu autorisieren.
  • Der cloudbasierte Schlüsselverwaltungsdienst: Diese Komponente ist in der Regel erforderlich, da die meisten Clouddienste eng in den Schlüsselverwaltungsdienst des Anbieters integriert sind. Der Schlüsselverwaltungsdienst kann in der Cloud gehostete Schlüssel bedienen oder Referenz-/Verweisschlüssel enthalten, die auf einen externen Schlüssel verweisen.
  • Der Schlüsselverwaltungsproxy: Da Organisationen ihr eigenes HSM (Anbieter/Typ) auswählen können, muss eine Übersetzung zwischen dem Schlüsselverwaltungsdienst und dem tatsächlichen HSM-Aufruf erfolgen. Der Proxy verfügt über eine (externe) URL, an die der Schlüsselverwaltungsdienst die Wrap/Unwrap-Aufrufe weiterleitet, und der Proxy muss diese in die spezifischen HSM-API-Aufrufe des Anbieters konvertieren. In vielen Fällen führt der Proxy auch Identitätskonvertierung und Überprüfung durch, da der HSM-Identitätsanbieter möglicherweise nicht mit der verwalteten Identität des Clouddiensts identisch ist.
  • Das HSM: Verschiedene HSMs können im Back-End verwendet werden, aber da ein kontinuierlicher Zugriff erforderlich ist, muss das ausgewählte HSM immer online sein, und der Zugriff muss auf Dienstprinzipien oder Benutzerkonten gewährt werden (vom Proxy verwaltet). Da Clouddienste regelmäßig die Schlüssel nutzen müssen, kann das HSM in der Regel keine quorumbasierten MFA-Steuerelemente (z. B. Smartcards) für Umhüll- und Entschlüsselungsverfahren verwenden.

Überlegungen zur Verwendung

In externen Schlüsselspeicherarchitekturen haben Kunden die volle Kontrolle über die physischen HSM und ihre betrieblichen Prozesse, einschließlich MFA- und Multi-Approval-Workflows für Administrative Vorgänge wie die Schlüsselerstellung, Sicherung und Wiederherstellung.

Organisationen sind voll verantwortlich für das Hosten und Sichern von Proxykomponenten, die eine wichtige Rolle bei der Dienstkommunikation spielen. Die Proxysoftware muss API-Aufrufe korrekt übersetzen und häufig Identitätsübersetzungen zwischen Clouddiensten und HSM-Schlüsselverwendung durchführen. Während Proxys häufig von HSM-Anbietern bereitgestellt werden, ermöglichen die open-standards-basierten Spezifikationen benutzerdefinierte Implementierungen.

Sicherheitsbewertung gegen Angriffsvektoren

Organisationen, die externe Schlüsselspeicher in Betracht ziehen, müssen den Schutz vor denselben Angriffsvektoren bewerten:

Private Schlüsselmaterialextraktion:

  • Die HSM-Sicherung (mit allen Schlüsseln im verschlüsselten Zustand) und der Maskierungsschlüssel (zum Aufheben der Verschlüsselung der Sicherung) befinden sich an demselben Speicherort, verwaltet von derselben Entität und geschützt durch denselben Identitätsanbieter (mit oder ohne MFA)
  • Menschlich lesbare Anmeldeinformationen sind erforderlich, um den Besitz des HSM zu übernehmen und tägliche Aufgaben wie Sicherungen, Schlüsselrotation, Überwachung sowie Aktionen in der HSM-Stammpartition durchzuführen.
  • Die Proxykomponente ist eine proprietäre, open-source- oder selbstverwaltete Komponente, die vollständigen Zugriff auf HSM, Schlüssel und Interaktionen hat. Eine Kompromittierung des Proxydiensts kann zu einer Kompromittierung von Schlüsselmaterial führen. Je nachdem, wie sicher der Proxy entworfen/geschrieben wurde, könnte der Proxy über "alle Schlüsselnutzungsberechtigungen" verfügen – wodurch der Kompromittierungsbereich größer wird.
  • Der Schlüsselverwaltungsproxy hostt eine externe barrierefreie URL, die mit einem TLS-Zertifikat geschützt ist. Es ist wichtig, dass die Kommunikation zwischen Cloud Key Management Service und Key Management Proxy nicht unterbrochen oder kompromittiert wird, während die (unverschlüsselte) DEK zurückgegeben wird.

Nicht autorisierte Nutzung des Diensts:

  • Das Speichern oder Behandeln der Anmeldeinformationen für die tatsächliche HSM-Verwendung (Wrap/Unwrap-Vorgänge) durch den Proxy stellt ein Risiko für den Diebstahl von Anmeldeinformationen dar. Mit diesen Anmeldeinformationen kann ein nicht autorisiertes System direkte HSM-Aufrufe für Wrap-/Unwrap-Vorgänge ohne Überprüfung durchführen.
  • Der cloudbasierte Schlüsselverwaltungsdienst erfordert Vertrauen als Komponente in der Architektur. Dieser Dienst leitet Anfragen von Clouddiensten unter Verwendung eines Verweisungsschlüssels an den Schlüsselverwaltungsproxy weiter. Eine Kompromittierung dieses Dienstes könnte unautorisierte Schlüsselersetzungen oder fehlerhafte Verpackungs-/Entpackungs-Anweisungen ermöglichen.
  • Der cloudbasierte Schlüsselverwaltungsdienst ist für die Autorisierung des Clouddiensts für die Verwendung des Empfehlungsschlüssels verantwortlich. Sobald der Verweisschlüssel aufgerufen wird, kennt die weitergeleitete Anforderung an den Schlüsselverwaltungsproxy nicht unbedingt den aufrufenden Dienst oder kann überprüfen, ob die Anforderung ordnungsgemäß autorisiert wurde – außer der Überprüfung der Anforderung des Schlüsselverwaltungsdiensts.

Weitere Überlegungen:

  • Organisationen sind voll verantwortlich für die Beschaffung, das Hosting und die Wartung komplexer, redundanter HSM- und Proxyinfrastrukturen, einschließlich Schulungen, betrieblicher Verfahren und Risikomanagement für unbeabsichtigte und absichtliche Sicherheitsvorfälle.
  • Organisationen steuern HSM-Richtlinien, einschließlich der Möglichkeit, Schlüssel als exportierbar zu kennzeichnen, was die Sicherheit verringern könnte, wenn sie nicht ordnungsgemäß verwaltet wird.
  • Der Verlust von Schlüsseln, Proxydienstverfügbarkeit oder Verlust von API-Konnektivität führt zu sofortiger und unwiederbringlicher Datenunzugänglichkeit für abhängige Clouddienste.

Hinweis

Während externer Zugriff auf den Schlüsselverwaltungsproxy vorgesehen ist, kann dieser Datenverkehr in vom Kunden oder Cloud-Anbieter kontrollierten Netzwerken gehostet werden, z. B. direkte Verbindungen und WAN-Verbindungen, und erfordert keinen öffentlichen Internetzugang.

Bewerten von Schlüsselverwaltungsansätzen

Überlegungen zum Vertrauens- und Sicherheitsmodell

Das Vertrauen in die Schlüsselverwaltung geht über den physischen Standort des Schlüsselmaterials hinaus. Unabhängig vom Ansatz ist Vertrauen in Verschlüsselungsmethoden, Firmware und Dienste erforderlich, die zwischen Anwendungen und der Speicherung von Schlüsseln vermitteln.

Externer Schlüsselverwaltungsansatz:

  • Physische Trennung von Schlüsseln von der Cloudinfrastruktur
  • Erfordert Vertrauen in Proxykomponenten, die von der Cloud initiierte Aufrufe in HSM-spezifische Vorgänge übersetzen
  • Beibehaltung der Abhängigkeit von Cloud-basierten Schlüsselverwaltungsdienst-Integrationspunkten
  • Übernimmt volle Verantwortung für Sicherheit, Zuverlässigkeit, Haltbarkeit und Leistung in der Organisation

Verwaltetes Azure Key Vault-HSM:

  • Bietet wichtige Souveränität über die Azure Confidential Computing-Architektur mit intel SGX-geschützten Anmeldeinformationen
  • Stellt FIPS 140-3 Level 3 validierten HSM-Schutz in Azure-Rechenzentren bereit.
  • Ermöglicht mehrstufige Authentifizierung, Mehrgenehmigungsprozesse und Quorumanforderungen über das Microsoft Entra ID- und Sicherheitsdomänen-Quorum
  • Verwendet eindeutige Sicherheitsdomänen mit vom Kunden gesteuerten Maskierungsschlüsseln und Schutzmechanismen
  • Unterstützt standardmäßige Azure Key Vault-API mit RSA-HSM und OCT-HSM Schlüsseltypen und Algorithmen
  • Der Vertrauensanker befindet sich außerhalb des Cloud-Anbieters (sowohl HSM als auch Intel-CPU-Silizium).
  • Verantwortungsausgleich: Microsoft behandelt Leistung, Schlüsselintegrität, Dienstsicherheit und Haltbarkeit; Kunden schützen die Sicherheitsdomäne und Schutzschlüssel

Detaillierte Vergleiche von Azure Key Management-Lösungen finden Sie unter Auswählen der richtigen Schlüsselverwaltungslösung.

Conclusion

Organisationen, die wichtige Souveränitätsansätze bewerten, müssen Sicherheitsanforderungen, betriebliche Fähigkeiten und Vertrauensmodelle ausgleichen. Es existieren verschiedene Architekturmuster zum Schutz von Schlüsselmaterial, die jeweils unterschiedliche Kompromisse mit sich bringen.

Azure Key Vault verwaltetes HSM bietet heute über FIPS 140-3-Level 3 validierten Schutz mit vertraulicher Computing-Architektur und bietet zentrale Mandanten- und Kundenkontrolle von Schlüsseln, während Microsoft die operativen Verantwortlichkeiten übernimmt. Externe Schlüsselverwaltungsarchitekturen bieten maximale Kontrolle über HSM-Zugriff und -Richtlinien, erfordern jedoch, dass Organisationen komplexe Infrastruktur verwalten und die Dienstverfügbarkeit für abhängige Cloudworkloads verwalten.

Organisationen sollten Ansätze basierend auf Complianceanforderungen, operativer Kapazität, Integrationsanforderungen und der Verantwortungsabwägung bewerten, die ihren Souveränitätszielen entspricht.

Nächste Schritte

  • Klassifizieren von Workloads nach erforderlicher Schlüsselstärke (plattformverwaltete Schlüssel → vom Kunden verwaltete Schlüssel → verwalteten HSM)
  • Rotationsrhythmen und Widerrufsauslöser pro Schlüsseldomäne
  • Bewerten der Machbarkeit vertraulicher Datenverarbeitung und sicherer Schlüsselfreigabe für hochempfindliche Workloads

Siehe auch

  • Last updated on