2 Sichere Installation und Konfiguration

In diesem Abschnitt werden die Schritte bei der Planung einer sicheren Installation aufgeführt. Außerdem werden verschiedene empfohlene Deployment-Topologien für die Systeme beschrieben.

Analysieren der Umgebung

Die folgenden Punkte helfen Ihnen, ein besseres Verständnis Ihrer Sicherheitsanforderungen zu erlangen:

Welche Ressourcen werden geschützt?

Viele Ressourcen in der Production-Umgebung können geschützt werden. Bei der Entscheidung über die erforderliche Sicherheitsstufe berücksichtigen Sie die Ressourcen, die geschützt werden müssen.

Die primären zu sichernden Ressourcen sind in der Regel Ihre Daten. Im Folgenden werden weitere Ressourcen aufgeführt, da sie mit der Verwaltung und dem Schutz Ihrer Daten verknüpft sind. Beim Datenschutz geht es darum, vor Datenverlust (also der Nichtverfügbarkeit von Daten) und vor Verletzung von Daten oder vor Offenbarung von Daten gegenüber Unbefugten zu schützen.

Zum Schutz von Daten vor der Offenbarung gegenüber Unbefugten werden oft kryptographische Schlüssel verwendet. Deshalb sind sie eine weitere Ressource, die geschützt werden muss. Hochzuverlässiges Schlüsselmanagement ist bei der Verwaltung von hochverfügbaren Daten äußerst wichtig. Eine weitere Gruppe von zu schützenden Ressourcen sind Assets innerhalb des Oracle Key Manager-Clusters selbst, einschließlich der Key Management Appliances.

Vor wem werden die Ressourcen geschützt?

Diese Ressourcen müssen vor jeder Person geschützt werden, die über keine Zugriffsberechtigung verfügt. Diese Ressourcen müssen physisch geschützt werden. Überlegen Sie, welche Ihrer Mitarbeiter Zugang zu diesen Ressourcen haben sollen. Geben Sie dann an, welche Art Vorgänge jeder Mitarbeiter in der Oracle Key Manager-Umgebung herausgeben kann.

Was geschieht, wenn der Schutz bei strategischen Ressourcen versagt?

In einigen Fällen kann ein Fehler in Ihrem Sicherheitsschema einfach entdeckt und nur als eine Unannehmlichkeit eingestuft werden. In anderen Fällen kann ein Fehler großen Schaden für Unternehmen oder einzelne Kunden anrichten, die Ihre Ressourcen verwenden. Wenn Sie die Sicherheitsauswirkungen jeder Ressource kennen, können Sie diese richtig schützen.

Empfohlene Deployment-Topologien

Die folgende Abbildung zeigt eine typische Bereitstellung einer Oracle Key Manager-Lösung.

Abbildung 2-1 Typische Bereitstellung einer OKM-Lösung

Beschreibung von Abbildung 2-1 Typische Bereitstellung einer OKM-Lösung

Installieren einer Key Management Appliance (KMA)

In diesem Abschnitt wird die sichere Installation und Konfiguration einer OKM Key Management Appliance beschrieben.

KMAs werden als gehärtete Appliances mit verfügbarer Oracle Key Manager-Funktionalität hergestellt.

Die Installation und Konfiguration von KMAs in einem OKM-Cluster umfasst folgende Schritte:

Installieren Sie jede KMA in einem Rack.
Sichern Sie den ILOM jeder KMA.
Konfigurieren Sie die erste KMA im OKM-Cluster.
Fügen Sie weitere KMAs zum OKM-Cluster hinzu.

Weitere Informationen zur Planung des Deployments eines OKM-Clusters finden Sie in Oracle Key Manager - Übersichts- und Planungshandbuch.

Installieren einer KMA in einem Rack

Eine KMA wird von einem Oracle Customer Service Engineer in einem Rack installiert, wie in Oracle Key Manager - Installations- und Servicehandbuch beschrieben. Dieses Handbuch bietet Oracle-Kundendienstmitarbeitern ausführlichere Informationen.

Sichern des ILOM einer KMA

Oracle Key Manager-KMAs werden mit aktueller ILOM-Firmware hergestellt. Der ILOM einer KMA muss entweder von einem Oracle Customer Service Engineer oder vom Kunden gesichert werden. Der ILOM muss außerdem nach einem Upgrade der ELOM- oder ILOM-Firmware gesichert werden.

Für das Sichern des ILOM müssen bestimmte ILOM-Einstellungen festgelegt werden, um Änderungen am ILOM zu verhindern, die die Sicherheit beeinträchtigen können. Weitere Anweisungen finden Sie im Abschnitt über die ILOM-Sicherheitshärtung im Anhang "Serviceprozessorprozeduren" des Oracle Key Manager - Administrationshandbuchs.

Konfigurieren der ersten KMA in einem OKM-Cluster

Stellen Sie vor dem Konfigurieren der ersten KMA zunächst die Schlüsselaufteilungszugangsdaten und in diesem OKM-Cluster zu definierende Benutzer-IDs und Passphrases heraus. Dazu können Sie ein Arbeitsblatt verwenden, wie das Arbeitsblatt in Oracle Key Manager - Installations- und Servicehandbuch (nur intern). Wenden Sie sich dazu an den zuständigen Oracle Support-Ansprechpartner.

Geben Sie dem entsprechenden Personal diese Schlüsselaufteilungszugangsdaten, Benutzer-IDs und Passphrases. Weitere Informationen finden Sie unter Quorumschutz im weiteren Verlauf des Dokuments.

Hinweis:

Bewahren Sie diese Schlüsselaufteilungszugangsdaten, Benutzer-IDs und Passphrases an einem sicheren Ort auf.

Öffnen Sie einen Webbrowser, starten Sie die Remotekonsole, und starten Sie dann das OKM QuickStart-Dienstprogramm in der Remotekonsole. Um das OKM-Cluster in dieser KMA zu initialisieren, folgen Sie den unter "Initialisieren des Clusters" beschriebenen Anweisungen im Oracle Key Manager - Administrationshandbuch in den Oracle Key Manager-Dokumentationsbibliotheken.

Die Schlüsselaufteilungszugangsdaten und ein Benutzer mit Berechtigungen für Sicherheitsbeauftragte werden in diesem Verfahren definiert. Nach Abschluss des QuickStart-Vorgangs muss der Sicherheitsbeauftragte sich bei der KMA anmelden und weitere OKM-Benutzer definieren.

Aspekte beim Definieren von Schlüsselaufteilungszugangsdaten

Das Definieren von weniger Benutzer-IDs und Passphrases für die Schlüsselaufteilung und ein niedrigerer Schwellenwert sind praktischer, aber weniger sicher. Das Definieren von mehr Benutzer-IDs und Passphrases für die Schlüsselaufteilung und ein höherer Schwellenwert sind weniger praktisch, aber sicherer.

Aspekte beim Definieren von zusätzlichen OKM-Benutzern

Das Definieren von weniger OKM-Benutzern, von denen einigen mehrere Rollen zugewiesen wurden, ist praktischer, aber weniger sicher. Das Definieren von mehr OKM-Benutzern, von denen den meisten nur eine Rolle zugewiesen wurde, ist weniger praktisch, aber sicherer, da so die von bestimmten OKM-Benutzern durchgeführten Vorgänge besser verfolgt werden können.

Hinzufügen von weiteren KMAs zum OKM-Cluster

Öffnen Sie einen Webbrowser, starten Sie die Remotekonsole, und starten Sie dann das OKM QuickStart-Dienstprogramm in der Remotekonsole. Um diese KMA zu dem OKM-Cluster hinzuzufügen, befolgen Sie die entsprechende Prozedur in Oracle Key Manager - Administrationshandbuch unter:

http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#crypto

Aspekte beim Hinzufügen von zusätzlichen KMAs

Oracle Key Manager bietet als praktische Option das autonome Entsperren der einzelnen KMAs. Diese Option wird während des QuickStart-Vorgangs für die erste und weitere KMAs in einem Cluster definiert und kann später von einem Sicherheitsbeauftragten geändert werden.

Wenn die Option zum autonomen Entsperren aktiviert ist, hebt die KMA beim Starten automatisch ihre Sperre auf und kann umgehend Schlüssel bereitstellen, ohne dass die Quorumgenehmigung erforderlich ist. Wenn das autonome Entsperren deaktiviert ist, bleibt die KMA beim Starten gesperrt und stellt erst dann Schlüssel bereit, wenn der Sicherheitsbeauftragte die Entsperrung anfordert und ein Quorum diese Anforderung genehmigt.

Um maximale Sicherheit zu gewährleisten, rät Oracle davon ab, das autonome Entsperren zu aktivieren. Weitere Informationen zur Option für autonomes Entsperren finden Sie in Oracle Key Manager Version 2.x - Whitepaper zu Sicherheit und Authentifizierung unter:

http://www.oracle.com/technetwork/articles/systems-hardware-architecture/okm-security-auth-300497.pdf

Eigenschaften von gehärteten KMAs

Wie oben angegeben, werden KMAs als gehärtete Appliances mit verfügbarer Oracle Key Manager-Funktionalität hergestellt. Sie haben wie gehärtete Appliances folgende Eigenschaften:

Nicht erforderliche Solaris-Pakete sind nicht im Solaris-Image vorhanden. Beispiel: FTP- und Telnet-Dienste sowie Dienstprogramme werden nicht im Solaris-Image angezeigt.
KMAs erstellen keine Core-Dateien.
Das standardmäßige Solaris Login(1)-Dienstprogramm wurde durch die OKM-Konsole ersetzt. Deshalb können sich Benutzer nicht bei der Solaris-Konsole anmelden.
Der SSH-Service ist standardmäßig deaktiviert. Zu Kundendienstzwecken kann der Sicherheitsbeauftragte den SSH-Service aktivieren und ein Supportkonto für einen begrenzten Zeitraum definieren. Dieses Supportkonto ist das einzige verfügbare Konto und verfügt über begrenzten Zugang und eingeschränkte Berechtigungen. Beim Solaris-Auditing werden Befehle verfolgt, die vom Supportkonto aufgerufen werden.
Das Root-Konto ist deaktiviert und als Rolle konfiguriert.
KMAs sind nicht mit einem DVD-Laufwerk ausgestattet.
USB-Anschlüsse werden wirksam deaktiviert.
Nicht verwendete Netzwerkanschlüsse werden geschlossen.
Nicht-ausführbare Stacks werden aktiviert.
Zufällige Adressbereichssuche ist konfiguriert.
Nicht-ausführbare Heaps sind aktiviert.
ZFS-Verschlüsselung wird für sicherheitsrelevante Dateisysteme verwendet.
Solaris ist gemäß der SCAP PCI-DSS-Benchmark konfiguriert.
Nicht erforderliche SMF-Services sind deaktiviert.
Oracle Solaris Verified Boot kann auf SPARC T7-1-basierten KMAs konfiguriert werden, um den Boot-Prozess des Systems zu sichern und vor Beschädigung der Kernel-Module, Einfügen von Root-Kits oder anderen böswilligen Programmen zu schützen.
Die neueren KMAs, die auf SPARC T7-1- und Netra SPARC T4-1-Servern basieren, sind originalgesichert (ILOM-Fehler), wodurch der Zugriff auf die Gehäusetür bei vorhandener Stromzufuhr offensichtlich wird.
Die ILOM 3.2-Firmware ist jetzt für FIPS 140-2 Level 1 zertifiziert und kann im FIPS-Modus konfiguriert werden.
Das Basis-Audit- und -Report-Tool wird in regelmäßigen Abständen im Hinblick auf forensische Verfahren ausgeführt. Diese Berichte sind in den OKM-Systemdumps enthalten.
Das Solaris Cryptographic Security Framework ist gemäß FIPS 140-2 Level 1-Sicherheitsrichtlinien (die für Solaris 11.1 dokumentiert sind) mit oder ohne Vorhandensein eines Hardware Security Modules konfiguriert.

TCP/IP-Verbindungen und die KMA

Wenn zwischen den Entitys (OKM-Manager, Agents und anderen KMAs in demselben Cluster) und der KMA eine Firewall vorhanden ist, muss die Firewall zulassen, dass die Entity TCP/IP-Verbindungen zu den folgenden Ports innerhalb der KMA herstellt:

OKM-Manager-zu-KMA-Kommunikation erfordert die Ports 3331, 3332, 3333, 3335.
Agent-zu-KMA-Kommunikation erfordert die Ports 3331, 3332, 3334, 3335.
KMA-zu-KMA-Kommunikation erfordert die Ports 3331, 3332, 3336.

Hinweis:

Für Benutzer, die ihre KMAs zur Verwendung von IPv6-Adressen konfigurieren, konfigurieren Sie IPv4-basierte Edgefirewalls, um alle ausgehenden IPv4-Protokoll-41-Pakete und UDP-Port-3544-Pakete zu löschen und so zu verhindern, dass IPv6-über-IPv4-Tunneldatenverkehr interne Hosts erreicht.

Weitere Einzelheiten finden Sie in der Dokumentation zur Firewallkonfiguration. Tabelle 2-1 führt Ports auf, die KMAs explizit verwenden oder Ports, an denen KMAs Services bereitstellen.

Tabelle 2-1 KMA-Portverbindungen

Portnummer	Protokoll	Richtung	Beschreibung
22	TCP	Listening	SSH (nur wenn Technischer Support aktiviert ist)
123	TCP/UDP	Listening	NTP
3331	TCP	Listening	OKM-CA-Service
3332	TCP	Listening	OKM-Zertifikatsservice
3333	TCP	Listening	OKM-Managementservice
3334	TCP	Listening	OKM-Agent-Service
3335	TCP	Listening	OKM-Discovery-Service
3336	TCP	Listening	OKM-Replikationsservice

Tabelle 2-2 zeigt andere Services, die auf Ports hören, die möglicherweise nicht verwendet werden.

Tabelle 2-2 Andere Services

Portnummer	Protokoll	Richtung	Beschreibung
53	TCP/UDP	Verbindung wird hergestellt	DNS (nur wenn KMA zur Verwendung von DNS konfiguriert ist)
68	UDP	Verbindung wird hergestellt	DHCP (nur wenn KMA zur Verwendung von DHCP konfiguriert ist)
111	TCP/UDP	Listening	RPC (KMAs antworten auf rpcinfo-Abfragen). Dieser Port ist nur bei KMS 2.1 und früher für externe Anforderungen geöffnet.
161	UDP	Verbindung wird hergestellt	SNMP (nur wenn SNMP-Manager definiert sind)
161	UDP	Listening	SNMP (nur wenn Hardware Management Pack aktiviert ist)
514	TCP	Verbindung wird hergestellt	Remote-Syslog (nur wenn Remote-Syslog-Server definiert und zur Verwendung von TCP unverschlüsselt konfiguriert sind)
546	UDP	Verbindung wird hergestellt	DHCPv6 (nur wenn KMA zur Verwendung von DHCP und IPv6 konfiguriert ist)
4045	TCP/UDP	Listening	NFS Lock Daemon (nur KMS 2.0)
6514	TLS über TCP	Verbindung wird hergestellt	Remote-Syslog (nur wenn Remote-Syslog-Server definiert und zur Verwendung von TLS konfiguriert sind)

Hinweis:

Port 443 muss geöffnet sein, damit Kunden auf die Serviceprozessor-Weboberfläche und die OKM-Konsole über die Firewall zugreifen können. Im Oracle Key Manager - Installations- und Servicehandbuch (nur intern) werden die ELOM- und ILOM-Ports aufgeführt.

In Tabelle 2-3 werden die ELOM-/ILOM-Ports von KMA aufgeführt. Diese Ports würden aktiviert, wenn von außerhalb der Firewall auf ELOM/ILOM zugegriffen werden muss; sonst müssen sie für die ELOM-/ILOM-IP-Adresse nicht aktiviert werden:

Tabelle 2-3 ELOM-/ILOM-Ports

Portnummer	Protokoll	Richtung	Beschreibung
22	TCP	Listening	SSH (für ELOM-/ILOM-Befehlszeilenoberfläche)
53	TCP/UDP	Verbindung wird hergestellt	DNS (nur erforderlich, wenn DNS konfiguriert ist)
68	UDP	Verbindung wird hergestellt	Wenn DHCP für ELOM/ILOM benötigt wird. Hinweis: Dokumentation für DHCP und ELOM/ILOM ist nicht verfügbar, auch wenn diese unterstützt werden.
80	TCP	Listening	HTTP (für die ELOM-/ILOM-Weboberfläche) Wenn HTTP erforderlich ist; sonst können Benutzer die Anweisungen zur Verbindung zu der Remotekonsole aufrufen unter: ELOM: `http://docs.oracle.com/cd/E19121-01/sf.x2100m2/819-6588-14/819-6588-14.pdf` ILOM: `http://docs.oracle.com/cd/E19860-01/index.html`
161	UDP	Listening/Verbindung wird hergestellt	SNMPv3 (konfigurierbar, dies ist der Standardport)
443	TCP /TLS	Listening	Embedded/Integrated Lights Out Manager Desktop Management Task Force-(DMTF-)Webservices für Management Protocol (WS-Man) über Transport Layer Security (TLS)
623	UDP	Listening	Intelligent Platform Management Interface (IPMI)