In diesem Abschnitt werden die spezifischen Sicherheitsverfahren beschrieben, die das Produkt bietet.
Kunden mit verschlüsselungsfähigen Agents sorgen sich hauptsächlich um:
Richtlinienverletzende Offenbarung von Informationen
Verlust oder Zerstörung von Daten
Inakzeptable Verzögerungen bei der Wiederherstellung von Daten bei fatalem Ausfall (Beispiel: bei einem Notfallsystem)
Nicht erkannte Änderung von Daten
Die Ziele der Sicherheitsfunktionen von Oracle Key Manager sind:
Schutz verschlüsselter Daten vor der Offenbarung.
Minimierung des Angriffsrisikos.
Ausreichend hohe Zuverlässigkeit und Verfügbarkeit.
Dieser Abschnitt des Sicherheitshandbuchs soll einen umfassenden Überblick über die Bedrohungen geben, für die das System konzipiert wurde, und darüber, wie die einzelnen Sicherheitsfunktionen zusammen Angriffe abwehren.
Folgende kritische Sicherheitsfunktionen bieten diesen Schutz:
Authentifizierung - Stellt sicher, dass nur autorisierte Personen auf das System und die Daten zugreifen können.
Autorisierung - Zugangskontrolle auf Systemberechtigungen und Daten. Diese Zugangskontrolle baut auf der Authentifizierung auf, um sicherzustellen, dass Einzelpersonen ausschließlich den für sie angemessenen Zugang erhalten.
Audit - Beim Audit können Administratoren versuchte Verletzungen des Authentifizierungsverfahrens und versuchte oder erfolgreiche Verletzungen der Zugriffskontrolle erkennen.
Weitere Informationen zum Sicherheits- und Authentifizierungsaspekt von Oracle Key Manager finden Sie in Oracle Key Manager Version 2.x - Whitepaper zu Sicherheit und Authentifizierung unter:
Die Oracle Key Manager-Architektur sorgt für die gegenseitige Authentifizierung zwischen allen Elementen des Systems: KMA zu KMA, Agent zu KMA und Oracle Key Manager GUI zu CLI zu KMA für Benutzervorgänge.
Jedes Element des Systems (zum Beispiel ein neuer Verschlüsselungs-Agent) wird beim System registriert, indem eine ID und eine Passphrase in OKM erstellt werden, die dann im hinzuzufügenden Element eingegeben werden. Beispiel: Wenn dem System ein Bandlaufwerk hinzugefügt wird, führen der Agent und die KMA automatisch ein Challenge-/Antwortprotokoll basierend auf der gemeinsamen Passphrase aus, durch das der Agent das Root Certificate Authority (CA)-Zertifikat, ein neues Schlüsselpaar und ein signiertes Zertifikat für den Agent erhält. Nach dem Erstellen von Root CA-Zertifikat, Agent-Zertifikat und Schlüsselpaar kann der Agent das Transport Layer Security (TLS)-Protokoll für alle nachfolgenden Kommunikationen mit der KMA ausführen. Alle Zertifikate sind X.509-Zertifikate.
Der OKM dient als Root-Zertifizierungsstelle, die ein Root-Zertifikat erstellt, das KMAs wiederum zur Ableitung (selbstsigniert) von Zertifikaten verwenden, die von anderen Agents, Benutzern und neuen KMAs genutzt werden.
Es gibt folgende Arten von Zugriffskontrolle:
Benutzer- und rollenbasierte Zugriffskontrolle
Quorumschutz
Oracle Key Manager bietet die Möglichkeit, mehrere Benutzer mit je einer ID und Passphrase zu definieren. Jedem Benutzer wird mindestens eine vordefinierte Rolle zugewiesen. Diese Rollen bestimmen, welche Vorgänge ein Benutzer auf einem Oracle Key Manager-System durchführen darf. Diese Rollen sind:
Sicherheitsbeauftragter - Richtet Oracle Key Manager ein und verwaltet es
Bediener - Richtet den Agent ein und führt alltägliche Vorgänge durch
Compliance-Mitarbeiter - Definiert Schlüsselgruppen und kontrolliert den Agent-Zugriff auf Schlüsselgruppen
Backupoperator - Führt Backupvorgänge durch
Auditor - Überprüft Audittrails des Systems
Quorummitglied - Überprüft und genehmigt ausstehende Quorumvorgänge
Ein Sicherheitsbeauftragter wird während des QuickStart-Prozesses definiert, bei dem eine KMA in einem OKM-Cluster eingerichtet wird. Später muss sich ein Benutzer über die Oracle Key Manager-GUI als Sicherheitsbeauftragter beim Cluster anmelden, um weitere Benutzer zu definieren. Der Sicherheitsbeauftragte kann wahlweise einem bestimmten Benutzer mehrere Rollen oder eine bestimmte Rolle mehreren Benutzern zuweisen.
Weitere Informationen über die zulässigen Vorgänge der einzelnen Rollen und darüber, wie ein Sicherheitsbeauftragter Benutzer erstellt und ihnen Rollen zuweist, finden Sie im Oracle Key Manager - Administrationshandbuch in den Oracle Key Manager-Dokumentationsbibliotheken unter:
http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto
Diese rollenbasierte Zugriffskontrolle unterstützt die betrieblichen Rollen der National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60 zur Abgrenzung von betrieblichen Funktionen.
Für einige Vorgänge ist wegen ihrer kritischen Natur eine zusätzliche Sicherheitsebene erforderlich. Zu diesen Vorgängen gehören das Hinzufügen einer KMA zu einem OKM-Cluster, das Entsperren einer KMA, das Erstellen von Benutzern und das Hinzufügen von Rollen zu Benutzern. Zur Implementierung dieser Sicherheitsebene wird vom System neben dem oben beschriebenen rollenbasierten Zugriff eine Gruppe von Schlüsselaufteilungszugangsdaten verwendet.
Schlüsselaufteilungszugangsdaten bestehen aus einer Gruppe von Benutzer-ID- und Passphrase-Paaren und der Mindestanzahl an Paaren, die erforderlich sind, damit das System bestimmte Vorgänge abschließen kann. Die Schlüsselaufteilungszugangsdaten werden auch als "Quorum" bezeichnet, und die Mindestanzahl wird "Quorumschwellenwert" genannt.
In Oracle Key Manager können bis zu 10 Benutzer-ID-/Passphrase-Paare zur Schlüsselaufteilung und ein Schwellenwert festgelegt werden. Sie werden während des QuickStart-Prozesses bei der ersten Konfiguration der KMA in einem OKM-Cluster definiert. Die Benutzer-IDs und Passphrases für die Schlüsselaufteilung unterscheiden sich von denen zur Anmeldung beim System. Wenn ein Benutzer einen Vorgang durchführen möchte, für den eine Quorumgenehmigung erforderlich ist, muss dieser Vorgang vom definierten Schwellenwert der Benutzer-IDs und Passphrases für die Schlüsselaufteilung genehmigt werden, bevor das System diesen Vorgang durchführt.
Jede KMA protokolliert Auditereignisse für von ihr durchgeführte Vorgänge, einschließlich der Ereignisse, die von Agents, Benutzern und anderen KMAs im OKM-Cluster ausgegeben wurden. KMAs protokollieren auch Auditereignisse, wenn ein Agent, Benutzer oder eine andere KMA sich nicht selbst authentifiziert. Auditereignisse, die auf eine Sicherheitsverletzung hinweisen, werden festgehalten. Die Nichtauthentifizierung ist ein Beispiel eines Auditereignisses, das auf eine Sicherheitsverletzung hinweist. Wenn SNMP-Agents im OKM-Cluster identifiziert werden, senden KMAs außerdem SNMP INFORMs an diese SNMP-Agents, sobald sie eine Sicherheitsverletzung erkennen. Wenn "Remote-Syslog" konfiguriert ist, leitet eine KMA auch diese Auditnachrichten an konfigurierte Server weiter. Siehe Remote-Syslog.
Ein Benutzer muss sich ordnungsgemäß beim OKM-Cluster anmelden, und ihm muss eine Rolle zugewiesen sein, damit er in der Lage ist, Auditereignisse anzuzeigen.
KMAs verwalten ihre Auditereignisse. KMAs entfernen ältere Auditereignisse basierend auf Aufbewahrungsbedingungen und -begrenzungen (Anzahl). Diese Aufbewahrungsbedingungen und -begrenzungen können vom Sicherheitsbeauftragten nach Bedarf geändert werden.
Oracle Key Manager bietet noch weitere Sicherheitsfunktionen. Weitere Informationen darüber und über sonstige OKM-Funktionen finden Sie in Oracle Key Manager - Überblick unter:
Das Kommunikationsprotokoll zwischen einem Agent und einer KMA, einem Benutzer und einer KMA ist dasselbe wie zwischen einer KMA und einer Peer-KMA. In beiden Fällen verwendet das System die Passphrase für die Entity, die die Kommunikation initiiert, um ein Challenge-/Antwortprotokoll durchzuführen. Verläuft dieser Vorgang erfolgreich, erhält die Entity ein Zertifikat und den dazugehörigen privaten Schlüssel. Dieses Zertifikat und der zugehörige private Schlüssel können einen Transport Layer Security (TLS) 1.0 (Secure Sockets) Kanal einrichten. Die gegenseitige Authentifizierung wird durchgeführt, sodass jedes Verbindungsende die jeweils andere Partei authentifiziert. OKM 3.1+ KMAs verwenden immer TLS 1.2 für den Peer-zu-Peer-Replikationsdatenverkehr.
Für KMAs steht ein Hardware Security Module zur Verfügung, dass separat bestellt werden kann. Dieses Hardware Security Module - eine Sun Cryptographic Accelerator (SCA) 6000-Karte - war für FIPS 140-2 Level 3 zertifiziert und stellt Advanced Encryption Standard (AES) 256-Bit-Verschlüsselungschlüssel bereit (dieses Zertifikat ist am 31.12.2015 abgelaufen und wird nicht erneuert. Ein alternatives HSM wird in einem nachfolgenden Release bereitgestellt). Die SCA 6000-Karte unterstützt einen FIPS 140-2 Level 3-Betriebsmodus, und die Karte wird von OKM stets auf diese Weise verwendet. Wenn das OKM-Cluster im FIPS-konformen Modus betrieben wird, verlassen keine Verschlüsselungsschlüssel unverpackt den kryptographischen Grenzbereich der SCA 6000-Karte. Die SCA 6000-Karte verwendet für das Generieren der Verschlüsselungsschlüssel einen von FIPS genehmigten Zufallszahlengenerator (wie in FIPS 186-2 DSA Random Number Generator angegeben) unter Verwendung von SHA-1.
Wenn eine KMA nicht mit einer SCA 6000-Karte konfiguriert ist, erfolgt die Kryptographie mittels des Solaris Cryptographic Framework (SCF) PKCS#11 Soft Token. Das SCF wird im FIPS 140-Modus gemäß den zuletzt veröffentlichten Solaris FIPS 140-2-Sicherheitsrichtlinien konfiguriert.
Oracle Key Manager verwendet den AES-Schlüssel-Wrap-Algorithmus (RFC 3994) mit 256-Bit Schlüssel-Verschlüsselungsschlüssel zum Schutz von symmetrischen Schlüsseln, während sie erstellt, auf der KMA gespeichert und an Agents übertragen werden, oder innerhalb von Schlüsselübertragungsdateien.
Wenn die erste KMA eines OKM-Clusters initialisiert wird, generiert die KMA einen großen Pool von Schlüsseln. Wenn weitere KMAs hinzugefügt werden, werden die Schlüssel für die neuen KMAs repliziert, wodurch diese umgehend zur Verschlüsselung von Daten bereit sind. Jede KMA, die dem Cluster hinzugefügt wird, generiert einen Pool von Schlüsseln und repliziert diese für andere KMAs im Cluster. Alle KMAs generieren je nach Bedarf neue Schlüssel, um die Schlüsselpoolgröße zu erhalten. So stehen den Agents stets Schlüssel zur Verfügung. Wenn ein Agent einen neuen Schlüssel benötigt, kann er eine KMA im Cluster kontaktieren und einen neuen Schlüssel anfordern. Die KMA bezieht einen verfügbaren Schlüssel aus ihrem Pool von Schlüsseln und weist ihn der Standardschlüsselgruppe des Agent und der Dateneinheit zu. Anschließend repliziert die KMA diese Datenbankupdates im ganzen Netzwerk für die anderen KMAs im Cluster. Später kann der Agent eine andere KMA im Cluster kontaktieren, um den Schlüssel abzurufen. Dabei wird zu keiner Zeit irgendwelches Textschlüsselmaterial im Netzwerk übertragen.
Im Dezember 2013 hat das National Institute of Standards and Technology (NIST) das FIPS 140-2 Level 1-Validierungszertifikat #2061 für das Oracle Solaris Kernel Cryptographic Framework-Modul in Solaris 11 genehmigt. Im Januar 2014 hat NIST das FIPS 140-2 Level 1-Validierungszertifikat #2076 für das Oracle Solaris Userland Cryptographic Framework mit SPARC T4 und SPARC T5 genehmigt. Die Oracle Key Manager 3.1.0 KMA basiert jetzt auf Solaris 11.3, das immer noch in der FIPS 140-2-Validierungstestphase ist. Oracle Solaris Kernel Cryptographic Framework in einer Oracle Key Manager 3.1.0 KMA ist gemäß den Oracle Kernel Cryptographic Framework - Sicherheitsrichtlinien konfiguriert. Gleichermaßen ist die KMA ebenfalls gemäß den Oracle Solaris Userland Cryptographic Framework with SPARC T4- and SPARC T5 - Sicherheitsrichtlinien konfiguriert. OKM wird auf neuere Solaris-Sicherheitsrichtlinien upgedatet sobald diese verfügbar sind.