Überblick über Vaults, Key Management und Secret Management

Der Key Management-Service speichert und verwaltet Schlüssel in Vaults für den sicheren Zugriff auf Ressourcen.

Der Oracle Cloud Infrastructure (OCI) Key Management Service (KMS) ist ein cloudbasierter Service, der eine zentrale Verwaltung und Kontrolle von Verschlüsselungsschlüsseln für in OCI gespeicherte Daten bietet.

OCI KMS führt Folgendes aus:

  • Vereinfacht die Schlüsselverwaltung, indem Verschlüsselungsschlüssel zentral gespeichert und verwaltet werden.
  • Schützt Daten im Ruhezustand und während der Übertragung, indem verschiedene Verschlüsselungsschlüsseltypen unterstützt werden, einschließlich symmetrischer Schlüssel und asymmetrischer Schlüssel.
  • Erfüllt Sicherheits- und Complianceanforderungen mit verschiedenen Optionen zum Erstellen und Speichern von Schlüsseln. Zu diesen Features gehören: Importieren von Schlüsselmaterial in OCI ("Bring Your Own Keys" oder BYOK), Erstellen von Schlüsseln in OCI und externes Speichern von Schlüsseln ("Eigene Schlüssel sperren" oder HYOK) mit externer Schlüsselverwaltung. Key Management unterstützt FIPS 140-2 Level 3-zertifizierte Hardwaresicherheitsmodule (HSMs), um Ihre Verschlüsselungsschlüssel zu speichern und zu schützen.
  • Integriert die Verschlüsselung mit anderen OCI-Services wie Speicher, Datenbank und Fusion Applications zum Schutz der in diesen Services gespeicherten Daten.

Konzepte zur Verwaltung von Schlüsseln und Secrets

Machen Sie sich mit den Vault- und Schlüsselverwaltungskonzepten für den Zugriff auf und die Verwaltung von Vaults, Schlüsseln und Secrets vertraut.

Vaults
Vaults sind logische Entitys, in denen der Key Management-Service Vault-Schlüssel und Secrets erstellt und dauerhaft speichert. Der Vault-Typ bestimmt die Features und Funktionalitäten, z.B. den Grad der Speicherisolierung, den Zugriff auf Verwaltung und Verschlüsselung, die Skalierbarkeit und das Backup. Außerdem wirkt sich der Vault-Typ auf den Preis aus. Sie können den Vault-Typ nicht ändern, nachdem Sie den Vault erstellt haben.
Der Key Management-Service stellt zur Anpassung an die Anforderungen und das Budget Ihrer Organisation verschiedene Vault-Typen bereit. Alle Vault-Typen gewährleisten die Sicherheit und Integrität der Verschlüsselungsschlüssel und Secrets, die von Vaults gespeichert werden. Ein virtueller privater Vault ist eine isolierte Partition auf einem Hardwaresicherheitsmodul (HSM). Ansonsten verwenden Vaults Partitionen auf dem HSM mit anderen Vaults gemeinsam.
Virtual Private Vaults umfassen standardmäßig 1000 Schlüsselversionen. Wenn Sie nicht den größeren Isolationsgrad benötigen oder den Vault sichern können, benötigen Sie keinen virtuellen privaten Vault. Ohne einen Virtual Private Vault können Sie die Kosten verwalten, indem Sie Schlüsselversionen nach Bedarf einzeln bezahlen. (Die Schlüsselversionen werden auf das Schlüssellimit und die Schlüsselkosten angerechnet. Ein Vault-Schlüssel enthält immer mindestens eine aktive Schlüsselversion. Genauso hat ein Secret immer mindestens eine Secret-Version. Secret-Limits gelten jedoch für den Mandanten und nicht einen Vault.)

Für Kunden, die behördliche Vorschriften zum Speichern von Schlüsseln außerhalb der Oracle Cloud oder anderer Cloud-Standorte von Drittanbietern haben, bietet OCI KMS jetzt eine Funktionalität namens External Key Management Service (External KMS). In External KMS können Sie Masterverschlüsselungsschlüssel (als externe Schlüssel) auf einem außerhalb von OCI gehosteten Schlüsselverwaltungssystem eines Drittanbieters speichern und steuern. Sie können diese Schlüssel dann zur Verschlüsselung Ihrer Daten in Oracle verwenden. Sie können Ihre Schlüssel auch jederzeit deaktivieren. Wenn sich die tatsächlichen Schlüssel im Schlüsselverwaltungssystem eines Drittanbieters befinden, erstellen Sie nur Schlüsselreferenzen (die mit dem Schlüsselmaterial verknüpft sind) in OCI.

OCI KMS bietet das Dedicated KMS, ein vom Kunden verwaltetes, hochverfügbares, einzelmandantenfähiges HSM-Partitions-Resource-as-a-Service. Dadurch haben Sie mehr Kontrolle, indem Sie Eigentümer der HSM-Partition und der verschlüsselten Schlüssel sowie der Benutzer in der Partition sind. In einem dedizierten KMS-Setup enthält das HSM-Cluster standardmäßig drei HSM-Partitionen, die automatisch synchronisiert werden. Sie können Schlüssel und Benutzer in den in OCI-Compute-Instanzen integrierten HSMs über Clientutilitys und PKCS #11-Bibliotheken verwalten. Dedicated KMS unterstützt nur HSM-geschützte Schlüssel und keine softwaregeschützten Schlüssel. Für kryptografische Operationen unterstützt die Lösung sowohl symmetrische als auch asymmetrische Verschlüsselung mit AES-, RSA- und ECDSA-Algorithmen.

Im Vault-Service werden Vaults als Oracle Cloud Infrastructure-Ressource bezeichnet.
Schlüssel
Schlüssel sind logische Entitys, die eine oder mehrere Schlüsselversionen darstellen, von denen jede ein kryptografisches Material enthält. Das kryptografische Material eines Vault-Schlüssels wird für einen bestimmten Algorithmus generiert, mit dem Sie den Schlüssel für die Verschlüsselung oder bei der digitalen Signatur verwenden können. Bei der Verschlüsselung verschlüsselt und entschlüsselt ein Schlüssel- oder Schlüsselpaar Daten und schützt dort, wo die Daten gespeichert werden oder während der Übertragung sind. Mit einem symmetrischen AES-Schlüssel verschlüsselt und entschlüsselt derselbe Schlüssel Daten. Mit einem asymmetrischen RSA-Schlüssel verschlüsselt der Public Key Daten, und der Private Key entschlüsselt Daten.
Sie können AES-Schlüssel bei der Verschlüsselung und Entschlüsselung verwenden, jedoch nicht bei der digitalen Signatur. RSA-Schlüssel können jedoch nicht nur zur Verschlüsselung und Entschlüsselung von Daten, sondern auch zur digitalen Signierung von Daten und zur Überprüfung der Authentizität signierter Daten verwendet werden. Sie können ECDSA-Schlüssel beim digitalen Signieren verwenden, aber keine Daten verschlüsseln oder entschlüsseln.
Wenn ein Schlüssel als Teil eines Verschlüsselungsalgorithmus verarbeitet wird, gibt er an, wie bei der Verschlüsselung Klartext in Cipher-Text und bei der Entschlüsselung Cipher-Text in Klartext umgewandelt wird. Wenn sie als Teil eines Signaturalgorithmus verarbeitet werden, erzeugen der private Schlüssel eines asymmetrischen Schlüssels und einer Nachricht eine digitale Signatur, die mit der Nachricht während der Übertragung einhergeht. Bei Verarbeitung als Teil eines Signaturüberprüfungsalgorithmus durch den Empfänger der signierten Nachricht bestätigen die Nachricht, die Signatur und der öffentliche Schlüssel desselben asymmetrischen Schlüssels die Authentizität und Integrität der Nachricht oder lehnen sie ab.
Im Wesentlichen erkennt der Key Management-Service drei Arten von Verschlüsselungsschlüsseln: Masterverschlüsselungsschlüssel, Wickelschlüssel und Datenverschlüsselungsschlüssel.
Zu den Verschlüsselungsalgorithmen, die der Key Management-Service für Vault-Masterverschlüsselungsschlüssel unterstützt, gehören AES, RSA und ECDSA. Sie können AES-, RSA- oder ECDSA-Masterverschlüsselungsschlüssel mit der Konsole, CLI oder API erstellen. Wenn Sie einen Masterverschlüsselungsschlüssel erstellen, kann der Key Management-Service das Schlüsselmaterial entweder intern generieren oder das Schlüsselmaterial aus einer externen Quelle in den Service importieren. (Die Unterstützung für den Import von Schlüsselmaterial hängt vom Verschlüsselungsalgorithmus des Schlüsselmaterials ab.) Wenn Sie Vault-Masterverschlüsselungsschlüssel erstellen, erstellen Sie sie in einem Vault. Wo ein Schlüssel gespeichert und verarbeitet wird, hängt jedoch vom Schutzmodus ab.
Vault-Masterverschlüsselungsschlüssel können einen von zwei Schutzmodi aufweisen: HSM oder Software. Ein durch ein HSM geschützter Masterverschlüsselungsschlüssel wird in einem HSM gespeichert und kann nicht aus dem HSM exportiert werden. Alle kryptografischen Vorgänge mit dem Schlüssel erfolgen auch auf dem HSM. In der Zwischenzeit wird ein durch Software geschützter Masterverschlüsselungsschlüssel auf einem Server gespeichert und kann daher vom Server exportiert werden, um kryptografische Vorgänge auf dem Client statt auf dem Server auszuführen. Im Ruhezustand wird der softwaregeschützte Schlüssel durch einen Root-Schlüssel im HSM verschlüsselt. Bei einem softwaregeschützten Schlüssel erfolgt jede Verarbeitung im Zusammenhang mit dem Schlüssel auf dem Server. Der Schutzmodus eines Schlüssels wirkt sich auf die Preisfindung aus und kann nach dem Erstellen des Schlüssels nicht mehr geändert werden.
Nachdem Sie Ihren ersten symmetrischen Masterschlüsselungsschlüssel erstellt haben, können Sie mit der API Datenverschlüsselungsschlüssel generieren, die der Key Management-Service an Sie zurückgibt. Beachten Sie, dass ein Datenverschlüsselungsschlüssel mindestens dieselbe Verschlüsselungsstärke aufweisen muss wie der Masterverschlüsselungsschlüssel, mit dem er erstellt wurde. Einige Services können mit einem symmetrischen Masterschlüsselungsschlüssel ihre eigenen Datenverschlüsselungsschlüssel generieren.
Ein Typ von Verschlüsselungsschlüssel, der standardmäßig in jedem Vault enthalten ist, ist ein Wrapping-Schlüssel. Ein Wrapping-Schlüssel ist ein asymmetrischer 4096-Bit-Verschlüsselungsschlüssel, der auf dem RSA-Algorithmus basiert. Das Public/Private-Key-Paar wird nicht auf die Servicelimits angerechnet. Es entstehen auch keine Servicekosten. Sie verwenden den Public Key als Schlüsselverschlüsselungsschlüssel, wenn Sie Schlüsselmaterial für den Import in den Key Management-Service wrappen müssen. Wrapping-Schlüssel können nicht erstellt, gelöscht oder rotiert werden.
Der Key Management-Service erkennt Master-Verschlüsselungsschlüssel als Oracle Cloud Infrastructure-Ressource.
Schlüsselversionen und Rotationen
Jedem Masterverschlüsselungsschlüssel wird automatisch eine Schlüsselversion zugewiesen. Wenn Sie einen Schlüssel rotieren, generiert der Key Management-Service eine neue Schlüsselversion. Der Key Management Service kann das Schlüsselmaterial für die neue Schlüsselversion generieren oder Sie können Ihr eigenes Schlüsselmaterial importieren.
Durch regelmäßiges Rotieren der Schlüssel wird die Datenmenge, die durch eine Schlüsselversion verschlüsselt oder signiert wird, begrenzt. Wenn ein Schlüssel kompromittiert wird, reduziert die Schlüsselrotation das Risiko. Jeder Schlüssel entspricht eine eindeutige, von Oracle zugewiesene ID, die als "Oracle Cloud-ID (OCID)" bezeichnet wird. Mithilfe der Schlüsselversion kann der Key Management-Service Schlüssel jedoch nahtlos rotieren, um Ihre Complianceanforderungen zu erfüllen.
Eine ältere Schlüsselversion können Sie nach dem Rotieren eines Schlüssels zwar nicht mehr zur Verschlüsselung verwenden, die Schlüsselversion ist jedoch weiterhin verfügbar, um Daten zu entschlüsseln, mit denen sie verschlüsselt wurde. Wenn Sie einen asymmetrischen Schlüssel rotieren, kann der Public Key nicht mehr zur Verschlüsselung von Daten verwendet werden. Der Private Key bleibt jedoch zur Entschlüsselung von Daten verfügbar, die mit dem Public Key verschlüsselt wurden. Wenn Sie einen asymmetrischen Schlüssel rotieren, der bei der digitalen Signierung verwendet wird, können Sie die Private-Key-Version nicht mehr zum Signieren von Daten verwenden. Die Public-Key-Version bleibt jedoch verfügbar, um die digitale Signatur von Daten zu überprüfen, die zuvor von der älteren Private-Key-Version signiert wurden.
Bei symmetrischen Schlüsseln müssen Sie nicht verfolgen, welche Schlüsselversion zur Verschlüsselung welcher Daten verwendet wurde, da der Cipher-Text des Schlüssels die Informationen enthält, die der Service zu Entschlüsselungszwecken benötigt. Durch Rotationen asymmetrischer Schlüssel müssen Sie jedoch verfolgen, welche Schlüsselversion verwendet wurde, um welche Daten zu verschlüsseln oder zu signieren. Bei asymmetrischen Schlüsseln enthält der Ciphertext des Schlüssels nicht die Informationen, die der Service zur Entschlüsselung oder Verifizierung benötigt.
Bei symmetrischen AES-Schlüsseln zählt jede Schlüsselversion bei der Berechnung der Servicelimits als eine Schlüsselversion. Bei asymmetrischen RSA- und ECDSA-Schlüsseln zählt jede Schlüsselversion jedoch als zwei bei der Berechnung der Verwendung anhand von Servicelimits, da ein asymmetrischer Schlüssel sowohl einen Public Key als auch einen Private Key enthält. (Asymmetrische Schlüssel werden auch als Schlüsselpaare bezeichnet.)
Automatische Schlüsselrotation
Hinweis

Dieses Feature ist nur für private Vaults verfügbar.

Mit dem Key Management-Service von OCI können Sie die automatische Schlüsselrotation für einen Verschlüsselungsschlüssel in einem virtuellen privaten Vault planen. Wenn Sie die automatische Rotation konfigurieren, legen Sie die Rotationshäufigkeit und das Startdatum des Rotationsplans fest. Für die Häufigkeit haben Sie ein Rotationsintervall zwischen 60 Tagen und 365 Tagen gewählt. KMS unterstützt die automatische Schlüsselrotation sowohl für HSM- als auch für Softwareschlüssel und unterstützt die automatische Rotation sowohl symmetrischer als auch asymmetrischer Schlüssel. Beachten Sie, dass ein Schlüssel den Status "enabled" aufweisen muss, um die automatische Rotation zu konfigurieren.

Merkmale und Anforderungen der automatischen Schlüsselrotation:
  • Sie können den Rotationsplan für einen Schlüssel aktualisieren, nachdem Sie die automatische Rotation aktiviert haben.
  • Sie können einen Schlüssel bei Bedarf rotieren (manuelle Rotation ausführen), wenn die automatische Schlüsselrotation für den Schlüssel aktiviert ist.
  • Sie können Aktivitäten zur automatischen Schlüsselrotation für einen Schlüssel verfolgen, einschließlich des letzten Rotationsstatus und der Statusmeldung, Aktualisierungen des Rotationsintervalls und des nächsten Rotationsstartdatums.
  • Sie können eine Ereignisbenachrichtigung senden, wenn eine Schlüsselrotation nicht erfolgreich verläuft.

Benachrichtigung über automatisches Rotationsereignis: Um Benachrichtigungen über automatische Schlüsselrotationsereignisse zu erhalten, müssen Sie den OCI Events-Service konfigurieren. Nach jeder Schlüsselrotation sendet KMS eine Benachrichtigung über den Rotationsstatus und ggf. Fehlermeldungen. Mit dem OCI Events-Service können Sie Ereignisregeln verwenden, um eine Funktion aufzurufen, die Sie zur Automatisierung verwenden können. Beispiel: Mit Funktionen können Sie die folgenden Aufgaben automatisieren:

  • Daten mit einer neuen Schlüsselversion erneut verschlüsseln
  • Alte Schlüsselversion löschen
  • Verteilen des öffentlichen Teils asymmetrischer Schlüssel zum Signieren oder Verifizieren von Daten

Weitere Informationen finden Sie unter Ereignisregeln erstellen und Funktionen - Überblick.

Hardwaresicherheitsmodule
Wenn Sie ein symmetrisches AES-Masterverschlüsselungsschlüssel erstellen, dessen Schutzmodus auf HSM gesetzt ist, speichert der Key Management-Service die Schlüsselversion in einem Hardwaresicherheitsmodul (HSM), um eine Schicht physischer Sicherheit bereitzustellen. (Wenn Sie ein Secret erstellen, werden Secret-Versionen base64codiert und durch einen Masterverschlüsselungsschlüssel verschlüsselt, aber nicht im HSM gespeichert.) Nachdem Sie die Ressourcen erstellt haben, verwaltet der Service Kopien einer bestimmten Schlüsselversion oder Secret-Version innerhalb der Serviceinfrastruktur, um Resilienz gegen Hardwarefehler zu gewährleisten. Schlüsselversionen von HSM-geschützten Schlüsseln werden anderweitig nicht gespeichert und können nicht aus einem HSM exportiert werden.
Wenn Sie einen asymmetrischen RSA- oder ECDSA-Masterverschlüsselungsschlüssel mit dem Schutzmodus HSM erstellen, speichert der Key Management-Service den Private Key in einem HSM und lässt den Export aus dem HSM nicht zu. Sie können den Public Key jedoch herunterladen.
Der Key Management-Service verwendet HSMs, die der Sicherheitszertifizierung nach Federal Information Processing Standards (FIPS) 140-2 der Sicherheitsebene 3 entsprechen. Diese Zertifizierung bedeutet, dass die HSM-Hardware offensichtliche Manipulationen, physische Garantien zur Manipulationssicherheit bietet, eine identitätsbasierte Authentifizierung erfordert und bei erkannter Manipulation Schlüssel vom Gerät löscht.
Envelope-Verschlüsselung
Der Datenverschlüsselungsschlüssel, mit dem Ihre Daten verschlüsselt werden, ist wiederum selbst mit einem Masterverschlüsselungsschlüssel verschlüsselt. Dieses Konzept wird als Envelope-Verschlüsselung bezeichnet. Oracle Cloud Infrastructure-Services haben ohne Interaktion mit dem Key Management-Service und ohne Zugriff Auf den Masterverschlüsselungsschlüssel, der durch Oracle Cloud Infrastructure Identity and Access Management (IAM) geschützt wird, keinen Zugriff auf die Klartextdaten. Zu Entschlüsselungszwecken speichern integrierte Services wie Object Storage, Block Volume und File Storage nur die verschlüsselte Form des Datenverschlüsselungsschlüssels.
Secrets
Secrets sind Zugangsdaten wie Kennwörter, Zertifikate, SSH-Schlüssel oder Authentifizierungstoken, die Sie mit Oracle Cloud Infrastructure-Services verwenden. Das Speichern von Secrets in einem Vault ist sicherer als die Speicherung an anderer Stelle, wie z.B. in Code oder Konfigurationsdateien. Sie können Geheimnisse aus dem Key Management-Service abrufen, wenn Sie sie für den Zugriff auf Ressourcen oder andere Services benötigen.
Sie können Secrets mit der Konsole, CLI oder API erstellen. Secret-Inhalte für ein Secret werden aus einer externen Quelle in den Service importiert. Der Vault-Service speichert Secrets in Vaults.
Im Key Management-Service werden Secrets als Oracle Cloud Infrastructure-Ressource unterstützt.
Secret-Versionen
Jedem Secret wird automatisch eine Secret-Version zugewiesen. Wenn Sie das Secret rotieren, stellen Sie dem Key Management-Service neue Secret-Inhalte zur Verfügung, damit diese eine neue Secret-Version erstellen können. Regelmäßiges Rotieren von Secret-Inhalten verringert die Auswirkungen eventueller Offenlegungen eines Secrets. A secret's unique Oracle Cloud ID (OCID) remains the same across rotations, but the secret version lets the Key Management service rotate secret contents to meet any rules or compliance requirements you might have. Sie können die Inhalte einer älteren Secret-Version nach dem Rotieren nicht verwenden, wenn eine Regel die Wiederverwendung des Secrets verhindert. Doch selbst dann bleibt die Secret-Version verfügbar und wird mit einem anderen Rotationsstatus als "Aktuell" markiert. Weitere Informationen zu Secret-Versionen und deren Rotationsstatus finden Sie unter Secret-Versionen und Rotationsstatus.
Secret-Bundles
Ein Vault Secret Bundle besteht aus den Secret-Inhalten, Eigenschaften der Secret- und Secret-Version (wie Versionsnummer oder Rotationsstatus) und vom Benutzer bereitgestellten kontextbezogenen Metadaten für das Secret. Wenn Sie ein Secret rotieren, erstellen Sie eine neue Secret-Version, die auch eine neue Secret-Bundle-Version enthält.

Regionen und Availability-Domains

Der Vault-Service ist in allen kommerziellen Regionen von Oracle Cloud Infrastructure verfügbar. Unter Informationen zu Regionen und Availability-Domains finden Sie die Liste der verfügbaren Regionen sowie die zugehörigen Standorte, Regions-IDs, Regionsschlüssel und Availability-Domains.

Im Gegensatz zu einigen Oracle Cloud Infrastructure-Services verfügt der Vault-Service jedoch nicht über einen regionalen Endpunkt für alle API-Vorgänge. Der Service hat einen regionalen Endpunkt für den Provisioning-Service, der Erstellungs-, Aktualisierungs- und Auflistungsvorgänge für Vaults verarbeitet. Für Erstellungs-, Aktualisierungs- und Auflistungsvorgänge für Schlüssel befinden sich die Serviceendpunkte auf mehreren unabhängigen Clustern. Serviceendpunkte für Secrets sind zudem noch auf verschiedene unabhängige Cluster verteilt.

Da der Vault-Service öffentliche Endpunkte aufweist, können Sie Datenverschlüsselungsschlüssel, die durch den Service generiert wurden, direkt für kryptografische Vorgänge in Ihren Anwendungen verwenden. Wenn Sie jedoch Masterverschlüsselungsschlüssel mit einem Service verwenden möchten, der in Vault integriert ist, müssen der Service und der Vault, der den Schlüssel enthält, sich in derselben Region befinden. Für Schlüsselverwaltungsvorgänge, kryptografische Schlüsselvorgänge, Secret-Verwaltungsvorgänge und Secret-Abrufvorgänge gibt es verschiedene Endpunkte. Weitere Informationen finden Sie in der Oracle Cloud Infrastructure-API-Dokumentation

Der Vault-Service verwaltet Kopien von Vaults und deren Inhalt, um sie dauerhaft zu persistieren und es dem Vault-Service zu ermöglichen, auf Anfrage Schlüssel oder Secrets zu erstellen, selbst wenn eine Availability-Domain nicht verfügbar ist. Diese Replikation ist unabhängig von der regionsübergreifenden Replikation, die ein Kunde konfigurieren könnte.

Bei Regionen mit mehreren Availability-Domains bewahrt der Vault-Service Kopien von Verschlüsselungsschlüsseln in allen Availability-Domains innerhalb der Region auf. Regionen mit mehreren Availability-Domains verfügen über ein Rack für jede Availability-Domain. Das bedeutet, dass die Replikation über drei Racks insgesamt in diesen Regionen erfolgt, in denen jedes Rack zu einer anderen Availability-Domain gehört. In Regionen mit einer einzelnen Availability-Domain verwaltet der Vault-Service Verschlüsselungsschlüsselkopien über Faultdomains hinweg.

Bei Secrets verteilt der Vault-Service in Regionen mit mehreren Availability-Domains Secret-Kopien auf zwei verschiedene Availability-Domains. In Regionen mit einer einzelnen Availability-Domain verteilt der Vault-Service die Kopien auf zwei verschiedene Faultdomains.

Jede Availability-Domain umfasst drei Faultdomains. Faultdomains bieten High Availability und Fehlertoleranz, indem sie es dem Vault-Service ermöglichen, Ressourcen auf verschiedene physische Hardware innerhalb einer bestimmten Availability-Domain zu verteilen. Die physische Hardware selbst verfügt auch über unabhängige und redundante Netzteile, die einen Stromausfall in einer Fehlerdomain daran hindern, sich auf andere Fehlerdomänen zu auswirken.

All dies ermöglicht es dem Vault-Service, auf Anfrage Schlüssel und Secrets zu erstellen, selbst wenn eine Availability-Domain in einer Region mit mehreren Availability-Domains nicht verfügbar ist oder wenn eine Faultdomain in einer Region mit einer einzelnen Availability-Domain nicht verfügbar ist.

Privater Zugriff auf Vault

Der Vault-Service unterstützt den privaten Zugriff durch Oracle Cloud Infrastructure-Ressourcen in einem virtuellen Cloud-Netzwerk (VCN) über ein Servicegateway. Durch die Einrichtung und Verwendung eines Servicegateways auf einem VCN können Ressourcen (wie die Instanzen, an die Ihre verschlüsselten Volumes angehängt sind) auf öffentliche Oracle Cloud Infrastructure-Services wie den Vault-Service zugreifen, ohne das öffentliche Internet nutzen zu müssen. Es ist kein Internetgateway erforderlich, und Ressourcen können sich in einem privaten Subnetz befinden und nur private IP-Adressen verwenden. Weitere Informationen finden Sie unter Zugriff auf Oracle Services: Servicegateway.

Ressourcen-IDs

Im Vault-Service werden Vaults, Schlüssel und Secrets als Oracle Cloud Infrastructure-Ressourcen unterstützt. Die meisten Oracle Cloud Infrastructure-Ressourcentypen verfügen über eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Informationen zum OCID-Format und zu anderen Möglichkeiten zur Identifizierung der Ressourcen finden Sie unter Ressourcen-IDs..

Möglichkeiten für den Zugriff auf Oracle Cloud Infrastructure

Sie können auf Oracle Cloud Infrastructure zugreifen, indem Sie Ihren Cloud-Account eingeben.

Auf Oracle Cloud Infrastructure (OCI) können Sie über die Konsole (eine browserbasierte Schnittstelle), die REST-API oder die OCI-CLI zugreifen. Anweisungen zur Verwendung der Konsole, API und CLI sind in verschiedenen Themen in dieser Dokumentation enthalten. Eine Liste der verfügbaren SDKs finden Sie unter Softwareentwicklungs-Kits und Befehlszeilenschnittstelle.

Um auf die Konsole zuzugreifen, müssen Sie einen unterstützten Browser verwenden. Um zur Anmeldeseite der Konsole zu wechseln, öffnen Sie das Navigationsmenü oben auf dieser Seite, und wählen Sie Infrastrukturkonsole aus. Dort werden Sie aufgefordert, Ihren Cloud-Mandanten, Benutzernamen und Ihr Kennwort einzugeben.

Authentifizierung und Autorisierung

Jeder Service in Oracle Cloud Infrastructure lässt sich mit IAM zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) integrieren.

Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die steuern, welche Benutzer auf Services und Ressourcen zugreifen können, und welche Zugriffsart. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für die einzelnen Services finden Sie in der Policy-Referenz.

Wenn Sie ein regulärer Benutzer sind (nicht ein Administrator), der die Oracle Cloud Infrastructure-Ressourcen verwenden muss, für die das Unternehmen verantwortlich ist, bitten Sie einen Administrator, eine Benutzer-ID für Sie einzurichten. Der Administrator kann festlegen, welche Compartments Sie verwenden können.

Limits für Vault-Ressourcen

Machen Sie sich mit der Begrenzung des Vault-Service und der zugehörigen Ressourcennutzung vertraut, bevor Sie sie verwenden.

Eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen finden Sie unter Servicelimits. Um compartment-spezifische Grenzwerte für eine Ressource oder Ressourcenfamilie festzulegen, können Administratoren Compartment-Quotas verwenden.

Anleitungen zum Anzeigen der Nutzungsebene im Vergleich zu den Ressourcenlimits des Mandanten finden Sie unter Servicelimits, -Quotas und -nutzung anzeigen. Sie können auch die Nutzung jedes einzelnen Vaults im Vergleich zu den Schlüsselgrenzwerten abrufen, indem Sie die Anzahl der Schlüssel und Schlüsselversionen in den Vault-Details anzeigen.