2 Sichere Installation

In diesem Abschnitt werden die Schritte bei der Planung und Implementierung für eine sichere Installation und Konfiguration aufgeführt, und die empfohlenen Deployment-Topologien für ACSLS werden beschrieben.

Umgebung analysieren

Damit Sie die Sicherheitsanforderungen besser verstehen, müssen die folgenden Fragen gestellt werden:

Welche Ressourcen müssen geschützt werden?

Die Schlüsselressourcen, die von ACSLS verwaltet werden, sind Bandbibliotheken, Laufwerke und Kassetten. Sie müssen vor unbeabsichtigtem und böswilligem Zugriff geschützt werden. Beispiel: Es muss verhindert werden, dass Personen sich versehentlich bei einem anderen ACSLS-Server anmelden, indem unterschiedliche Passwörter für die ACSLS-Benutzer-IDs auf unterschiedlichen Servern verwendet werden.

Vor wem müssen die Ressourcen geschützt werden?

Sie möchten die Bandspeicherungsressourcen vor unautorisiertem internen und externen Zugriff schützen.

Was geschieht, wenn der Schutz bei strategischen Ressourcen versagt?

ACSLS kann Kassetten in Bandlaufwerken mounten. Wenn ein Benutzer über den Datenpfad eine Verbindung zum Bandlaufwerk herstellen kann, kann er Daten auf dem Band lesen, die nicht verschlüsselt sind.

Benutzer, die sowohl auf ACSLS als auch auf eine Bandbibliothek Zugriff haben, können Kassetten in Bandbibliotheken einlegen und daraus entnehmen.

Empfohlene Prozedur zur Sicherung von ACSLS

Bei der Sicherung von ACSLS und der erforderlichen Infrastrukturkomponenten gehen Sie wie hier beschrieben vor, um sicherzustellen, dass ACSLS auch nach den Änderungen weiter funktioniert:

• Installieren Sie ACSLS.

• Prüfen Sie, ob ACSLS ordnungsgemäß funktioniert. Konfigurieren und prüfen Sie dabei Bibliotheken, mounten und dismounten Sie Bänder, legen Sie Bänder ein, und entnehmen Sie diese. Erstellen Sie außerdem ein Backup der Datenbank, und stellen Sie diese wieder her.

• Implementieren Sie die Änderung, um die Sicherheit zu erhöhen.

• Prüfen Sie, ob ACSLS weiterhin ordnungsgemäß funktioniert.

Sichern der ACSLS-Internetkommunikation

In diesem Abschnitt wird beschrieben, wie Sie ACSLS für einen sicheren Internetzugang bereitstellen.

Sichern von ACSLS und Bandbibliotheken hinter der Unternehmensfirewall

ACSLS und die davon unterstützten Bandbibliotheken müssen hinter der Unternehmensfirewall bereitgestellt werden. Wenn sich Personen, die entfernt arbeiten, beim ACSLS-Server anmelden müssen, können sie über ein VPN auf den Server zugreifen.

Hinweis:

Wenn Sie eine IPv4-basierte Edge-Firewall verwenden, muss diese so konfiguriert werden, dass alle ausgehenden IPv4-Protokoll-41-Pakete und UDP-Port-3544-Pakete gelöscht werden, um zu verhindern, dass Internethosts mit IPv6-over-IPv4-Tunnelmechanismen auf interne Hosts zugreifen können.

ACSLS Firewall Security-Option

Wenn Clientanwendungen, die ACSLS für das Mounten von Bändern und Verwalten von Bandbibliotheken verwenden, durch eine Firewall von ACSLS getrennt sind, wird empfohlen, die Firewall Security-Option zu aktivieren. Selbst wenn die Clientanwendungen nicht durch eine Firewall von ACSLS getrennt sind, bietet die Implementierung der Firewall Security-Option zusätzliche ACSLS-Sicherheit, indem die Ports begrenzt werden, die für die Kommunikation zwischen ACSLS und den Clientanwendungen verwendet werden (wie unten gezeigt). Deshalb ist die statische Variable CSI_FIREWALL_SECURE in ACSLS 8.1 und späteren Releases standardmäßig auf TRUE gesetzt.

Einzelheiten finden Sie im Anhang "Firewall Security-Option" im ACSLS-Administratorhandbuch.

Für die ACSLS-Kommunikation verwendete Ethernetports

• Die folgenden Ports werden auf dem ACSLS-Server verwendet. Stellen Sie sicher, dass die Firewalls so konfiguriert sind, dass Datenverkehr an diese Ports zulässig ist. Dies umfasst Firewalls, die mit ipfilter auf Solaris oder iptables auf Linux implementiert wurden.

  • 22 beide Richtungen – für SSH-Zugriff verwendet.

  • 111 Portmapper, es sei denn, Portmapper wurde deaktiviert.

  • 115 für SFTP (Secure File Transfer Protocol) verwendet.

  • 161 Standardport für ACSLS-SNMP-Agent - get/set/walk.

  • 162 Standardport für ACSLS-SNMP-Agent - Traps.

    Hinweis:

    Die vom ACSLS-SNMP-Agent verwendeten Ports können mit folgendem Befehl konfiguriert werden: AcslsAgtdSnmpConf [ -p port ] [-t trap port] [-d].  Die Option -d zeigt die aktuelle Einstellung an.  Nach Änderung der Porteinstellung müssen Sie den Agent mit dem Befehl agentRegister neu starten.

  • 5432 Standardport für die interne Kommunikation von ACSLS mit der PostgreSQL-Datenbank (die PGPORT-Umgebungsvariable für die acsss-Benutzer-ID).

    Wenn Port 5432 belegt ist, wird die nächsthöhere verfügbare Portnummer verwendet.

    Hinweis:

    Port 5432 muss nur für localhost (127.0.0.1) zugänglich sein.

  • 7001 und 7002 - werden von WebLogic und der ACSLS-GUI verwendet.

  • 30031 oder der Listening-Port von ACSLS CSI, wird von CSI_INET_PORT festgelegt.

  • 50003 Port wird zur internen Kommunikation zwischen der ACSLS-GUI und Java-Komponenten zur Legacy-ACSLS-Verarbeitung verwendet. Dieser Port ist nicht konfigurierbar.

• Damit Clientanwendungen über die ACSAPI mit ACSLS kommunizieren können, müssen die folgenden Ports geöffnet sein:

  • Die Clientanwendung muss mit dem Listening-Port von ACSLS CSI kommunizieren können. Der Standardport ist 30031. Er wird von der statischen Variable CSI_INET_PORT festgelegt.

    Mit dem folgenden Befehl aus der Unix-Shell können Sie ermitteln, welche Ports von ACSLS verwendet werden, um auf Anforderungen von ACSAPI-Clients zu horchen:

    rpcinfo -p | egrep "300031 | 536871166"

    Die Port-IDs werden im letzten Feld der Anzeige aufgeführt.

  • Der ACSAPI-Client (Beispiel: ein NetBackup- oder SAM-QFS-Server) legt seinen festen eingehenden Port mit der Umgebungsvariable SSI_INET_PORT fest. Geben Sie einen Port im Bereich von 1024 - 65535 an, ausgenommen die Ports 50001 und 50004. Der ACSLS-Server muss mit diesem Port kommunizieren können.

    Hinweis:

    Auf einem ACSAPI-Clientserver werden die Ports 50001 und 50004 für die AF_INET-Domain-IPC-Kommunikation mit dem Mini-Event Logger und von Clientanwendungen zu SSI verwendet.

  Im Anhang "Firewall Security-Option" im ACSLS-Administratorhandbuch finden Sie weitere Details zur Kommunikation zwischen Clientanwendungen und ACSLS.

• Wenn die XAPI-Komponente installiert ist. verwendet der XAPI-Server einen festen Listening-Port, um eingehende TCP-Anforderungen von ELS-Clients zu empfangen. Der XAPI-Listening-Port wird von der statischen Variablen XAPI_PORT definiert. XAPI_PORT ist standardmäßig 50020. Er muss zwischen 1024 und 65535 liegen und darf nicht mit anderen von ACSLS oder anderen Anwendungen verwendeten Ports in Konflikt stehen.

  Weitere Einzelheiten zum XAPI_PORT finden Sie im Anhang zur XAPI-Clientbenutzeroberfläche im ACSLS-Administratorhandbuch. Dieser Anhang enthält auch Details dazu, wie Sie die statische Variable XAPI_PORT anzeigen und festlegen.

• Ports, die in einer SL8500- oder SL3000-Bibliothek geöffnet sein müssen:

  ACSLS kommuniziert mit diesen Ports über die 2A- und 2B-Ethernetverbindungen einer SL8500- oder SL3000-Bibliothek. Wenn die Kommunikation von ACSLS zu diesen Ports blockiert ist, kann ACSLS die Bibliothek nicht verwalten.

  • 50001 – Wird für die gesamte normale Kommunikation zwischen ACSLS und der Bibliothek verwendet

  • 50002 – Wird von ACSLS HA verwendet, um zu bestimmen, ob der alternative HA-Knoten mit der Bibliothek kommunizieren kann, bevor ein Failover zum alternativen Knoten erfolgt

Konfigurieren von Firewalls, die auf dem ACSLS-Server ausgeführt werden

Neben externen Firewalls kann der Firewallschutz auf dem ACSLS-Server über ipfilter bei Solaris oder iptables bei Linux implementiert werden. Hier wird beschrieben, wie diese Firewalls auf Ihrem ACSLS-Server verwaltet werden.

• Verwalten von ipfilter auf Solaris:

  Auf den Manpages finden Sie detaillierte Informationen zu ipf und ipfilter.

  • Die ipfilter-Firewall wird von "root" mit folgendem Befehl aktiviert (deaktiviert):

    svcadm enable ipfilter (svcadm disable ipfilter)

  • So ermitteln Sie die aktuellen Status von ipfilter:

    svcs ipfilter

  • Firewallrichtlinien werden in der Datei: /etc/ipf/ipf.conf definiert.

    Um die freie Kommunikation zwischen Komponenten auf dem lokalen Host zuzulassen (beispielsweise zwischen ACSLS und WebLogic oder zwischen der GUI und der ACSLS-Datenbank), nehmen Sie eine Anweisung wie die Folgende auf:

    pass in quick from 127.0.0.1 to 127.0.0.1

    oder

    pass in quick from 127.0.0.1 to all

    Sie müssen Richtlinien definieren, die den Zugriff auf alle Ports ermöglichen, die für ACSLS benötigt werden. Beispiel: Um eine Richtlinie aufzunehmen, mit der entfernte webbasierte Browser auf die ACSLS-GUI zugreifen können, müssen Sie die Ports 7001 und 7002 öffnen.

    pass in quick from any to any port = 7001

    pass in quick from any to any port = 7002

    Nachdem Sie ermittelt haben, welche Ports von ACSLS verwendet werden, um auf Anforderungen von ACSAPI-Clients zu horchen, fügen Sie "pass in quick"-Anweisungen für jeden dieser Ports hinzu.

    Möglicherweise müssen Sie eine "pass in quick"-Anweisung für den RPC-Portmapper-Port 111 hinzufügen.

    Die letzte Anweisung in der vorgeschlagenen Regelgruppe, "block in from any", gibt an, dass kein Datenverkehr den Host erreichen soll, wenn dies nicht in vorherigen Anweisungen ausdrücklich zugelassen wird.

• Verwalten von iptables auf Linux:

  • Die iptables-Firewall wird von "root" mit folgendem Befehl aktiviert (deaktiviert):

    service iptables start (service iptables stop)

  • So wird der Status von iptables geprüft:

    service iptables status

  • Die Richtliniendatei für iptables ist /etc/sysconfig/iptables:

    Sie müssen Richtlinien definieren, die den Zugriff auf alle Ports ermöglichen, die für ACSLS benötigt werden. Beispiel: Zur Aufnahme einer Richtlinie, die Remote-HTTP/HTTPS-Zugriff auf die ACSLS GUI zulässt, müssen Sie die Datei so aktualisieren, dass sie Ausnahmen für Ports 7001 und 7002 einbezieht. Dazu verwenden Sie Anweisungen wie die Folgenden:

    -A input -p tcp --dport 7001 -j ACCEPT

    -A input -p tcp --dport 7002 -j ACCEPT

    Nachdem Sie ermittelt haben, mit welchen Ports ACSLS auf Anforderungen von ACSAPI-Clients horcht, müssen Sie Ausnahmen für jeden dieser Ports zur iptables-Richtliniendatei hinzufügen. Möglicherweise müssen Sie eine Ausnahmeanweisung für den RPC-Portmapper-Port 111 hinzufügen.

Installieren und Konfigurieren von Solaris

In diesem Abschnitt wird beschrieben, wie Sie Solaris sicher installieren und konfigurieren.

Empfehlungen umfassen:

• Spielen Sie alle wichtigen Sicherheitspatches in das BS und in Services, die im BS installiert sind, ein. Spielen Sie diese Patches selektiv ein. Wenn Sie nämlich alle verfügbaren Updates anwenden, können dadurch neue Funktionen und sogar neue BS-Releases installiert werden, mit denen ACSLS und ACSLS HA nicht getestet wurden.

• Deaktivieren Sie telnet und rlogin. Verwenden Sie stattdessen ssh. Deaktivieren Sie außerdem ftp, und verwenden Sie stattdessen sftp.

  Deaktivieren Sie die telnet-, rlogin- und ftp-Services, indem Sie die folgenden Befehle als "root" ausgeben.

  So zeigen Sie alle Services an:

  svcs

  So deaktivieren Sie telnet, rlogin und ftp:

  svcadm disable telnet

  svcadm disable rlogin

  svcadm disable ftp

• Deaktivieren Sie ssh nicht. Benutzer sollen sich entfernt bei ACSLS mit ssh und nicht mit telnet oder rlogin anmelden. Deaktivieren Sie auch nicht sftp.

• ACSLS erfordert rpc-bind. Deaktivieren Sie es nicht.

  Wenn Solaris mit der Option "Secure by Default" installiert wird, müssen Sie eine Netzwerkkonfigurationseigenschaft für rpc-bind ändern, damit ACSAPI-Clients Anforderungen an ACSLS senden können.

  Weitere Einzelheiten finden Sie im ACSLS-Installationshandbuch, Kapitel "Installieren von ACSLS unter Solaris", Abschnitt "Installieren von Solaris".

• Einige Ethernetports auf dem ACSLS-Server müssen zur Kommunikation mit ACSLS geöffnet sein. Clientanwendungen verwenden spezifische Ethernetports zur Kommunikation mit ACSLS, und ACSLS kommuniziert mit spezifischen Ports in Bandbibliotheken. In Für die ACSLS-Kommunikation verwendete Ethernetports werden die Ports aufgeführt, die für die ACSLS-Kommunikation verfügbar sein müssen. Stellen Sie auf dem ACSLS-Server sicher, dass ipfilter so konfiguriert ist, dass Datenverkehr zu den von ACSLS verwendeten Ports zugelassen ist.

Bestimmen Sie die Solaris-Auditingrichtlinie. Anhand des Abschnitts "Auditing in Oracle Solaris" in "Oracle System Administration: Security Services" können Sie die Ereignisse planen, die auditiert werden sollen. Außerdem können Sie angeben, wo die Auditlogs gespeichert werden sollen und wie sie geprüft werden sollen.

Installieren und Konfigurieren von Linux

Empfehlungen zur sicheren Installation und Konfiguration von Linux:

• Spielen Sie alle wichtigen Sicherheitspatches in das BS und in Services, die im BS installiert sind, ein. Spielen Sie diese Patches selektiv ein. Wenn Sie nämlich alle verfügbaren Updates anwenden, können dadurch neue Funktionen und sogar neue BS-Releases installiert werden, mit denen ACSLS und ACSLS HA nicht getestet wurden.

• Stellen Sie sicher, dass telnet und rlogin nicht installiert sind oder deaktiviert sind. Verwenden Sie stattdessen ssh.

  Stellen Sie außerdem sicher, dass ftp nicht installiert ist oder deaktiviert ist, und verwenden Sie stattdessen sftp.

  Um alle Services anzuzeigen, melden Sie sich als root an, und führen Sie folgenden Befehl aus:

  service –-status-all

• Um Services endgültig zu löschen, verwenden Sie:

  svccfg delete -f service-name

• Deaktivieren Sie ssh nicht. Benutzer sollen sich entfernt bei ACSLS mit ssh und nicht mit telnet oder rlogin anmelden. Deaktivieren Sie auch nicht sftp.

• Netzwerkservices, insbesondere rpcbind, müssen aktiviert sein, um die ACSLS-Clientkommunikation zu ermöglichen.

  Wenn rpc auf Linux gestartet werden soll, starten Sie es mit dem Kennzeichen –i.

• Einige Ethernetports auf dem ACSLS-Server müssen zur Kommunikation mit ACSLS geöffnet sein. Clientanwendungen verwenden spezifische Ethernetports zur Kommunikation mit ACSLS, und ACSLS kommuniziert mit spezifischen Ports in Bandbibliotheken. In Für die ACSLS-Kommunikation verwendete Ethernetports werden die Ports aufgeführt, die für die ACSLS-Kommunikation verfügbar sein müssen. Stellen Sie auf dem ACSLS-Server sicher, dass iptables so konfiguriert ist, dass Datenverkehr zu den von ACSLS verwendeten Ports zugelassen ist.

Auditing von Linux-Sicherheit

Bestimmen Sie die Linux-Auditingrichtlinien. Im Abschnitt "Configuring and Using Auditing" in Oracle Linux: Security Guide for Release 6 können Sie die Ereignisse planen, die auditiert werden sollen. Außerdem können Sie angeben, wo die Auditlogs gespeichert werden sollen und wie sie geprüft werden sollen.

Einige nützliche Logs und Befehle zum Auditing der Linux-Sicherheit umfassen:

• Zeigen Sie var/log/secure als root an, um die Historie der Anmeldeversuche und andere Zugriffsmeldungen anzuzeigen.

• Mit dem Befehl "last | more" erhalten Sie eine Historie der angemeldeten Benutzer.

• Das /var/log/audit/audit.log.[0-9] enthält ein Log der Zugriffsversuche, die von SELinux abgelehnt wurden. Sie könne diese nur als Root-Benutzer anzeigen.

SELinux-Sicherheit

ACSLS 8.4 ist zur Ausführung in optionalen Security Enhanced Linux-Umgebungen ausgelegt. SELinux ermöglicht eine Zugriffskontrolle für Dateien, Verzeichnisse und andere Systemressourcen, die über den üblichen Standardschutz in Unix-Umgebungen hinausgeht. Zusätzlich zur "owner-group-public"-Zugriffsberechtigung umfasst SELinux eine Zugriffskontrolle basierend auf Benutzerrolle, Domain und Kontext. Der Agent, der die Zugriffskontrolle über alle Systemressourcen durchsetzt, ist der Linux-Kernel.

Der Root-Benutzer in einem Linux-System kann das Enforcement mit dem Befehl setenforce aktivieren oder deaktivieren.

setenforce [Enforcing | Permissive | 1 | 0 ]

Verwenden Sie Enforcing oder 1, um SELinux in den Enforcing-Modus zu versetzen. Verwenden Sie Permissive oder 0, um SELinux in den Permissive-Modus zu versetzen

Um den aktuellen System-Enforcement-Status anzuzeigen, verwenden Sie den Befehl getenforce.

Drei SELinux-Richtlinienmodule werden in den Kernel geladen, wenn Sie ACSLS installieren: allowPostgr, acsdb und acsdb1. Diese Module stellen die Definitionen und Enforcement-Ausnahmen bereit, die ACSLS benötigt, um auf seine eigene Datenbank und andere Systemressourcen zuzugreifen, während das SELinux Enforcement aktiv ist. Wenn diese Module installiert sind, sollten Sie in der Lage sein, normale ACSLS-Vorgänge auszuführen, einschließlich Datenbankvorgänge wie bdb.acsss, rdb.acsss, db_export.sh und db_import.sh, ohne dass das SELinux-Enforcement deaktiviert werden muss.

Weitere Informationen finden Sie im Abschnitt zu SELinux im Anhang "Fehlerbehebung" im StorageTek ACSLS 8.4 Administratorhandbuch.

Installieren und Konfigurieren von ACSLS

In diesem Abschnitt wird beschrieben, wie ACSLS sicher installiert wird.

Standard-ACSLS-Installation durchführen

Bei einer Standard-ACSLS-Installation wird gewährleistet, dass Sie über alle erforderlichen Komponenten verfügen.

Wenn Sie von einem früheren ACSLS-Release zu einem späteren ACSLS-Release migrieren, prüfen Sie die Einstellungen für dynamische und statische Variablen. Dabei können Sie feststellen, ob Sie sicherere Optionen verwenden möchten, insbesondere was die Firewall Secure-Option betrifft.

Sichere Passwörter für die ACSLS-Benutzer-IDs verwenden

ACSLS erfordert die ACSLS-Benutzer-IDs: acsss, acssa und acsdb. Wählen Sie sichere Passwörter für diese IDs, und ändern Sie die Passwörter regelmäßig.

Zugriff auf ACSLS-Dateien begrenzen

ACSLS begrenzt den Zugriff auf die ACSLS-Dateien im Allgemeinen nur auf die acsls-Gruppe, die die acsss-, acssa-, acsdb- und root-Benutzer-IDs umfasst. Auf einige Datenbank- und Diagnosedateien kann nur mit einer einzelnen acsls-Benutzer-ID zugegriffen werden. ACSLS wird mit einer umask-Einstellung von 027 ausgeführt.

ACSLS-Dateien dürfen nicht global lesbar oder beschreibbar gemacht werden. Die Einschränkung des Zugriffs über die Installationsstandardwerte hinaus kann jedoch dazu führen, dass ACSLS-Funktionen nicht erfolgreich ausgeführt werden.

"root" als effektive Benutzer-ID für drei ACSLS-Dateien festlegen

Im Installationsskript werden Kunden darauf hingewiesen, dass die effektive Benutzer-ID "root" in drei ausführbaren Dateien im /export/home/ACSSS-Dateisystem festgelegt werden muss (setuid):

• acsss  (Diese Binärdatei muss mit "root"-Berechtigungen ausgeführt werden, da sie für das Starten und Stoppen von Systemservices verwendet wird, die von der ACSLS-Anwendung benötigt werden.)

• db_command  (Diese Binärdatei startet und stoppt die PostgreSQL-Datenbank-Engine, die die ACSLS-Datenbank steuert und verwaltet.)

• get_diags  (Diese Binärdatei wird von einem Kunden aufgerufen, um umfassende Systemdiagnoseinformationen zu erfassen, die möglicherweise bei einem Servicesupportanruf benötigt werden.)

Während der Installation von ACSLS mit pkgadd wird der folgende Prompt für Kunden angezeigt: Do you want to install these as setuid/setgid files? Wenn Sie den Prompt mit y beantworten, lassen Sie zu, dass diese drei Befehle von Benutzern in der acsls-Gruppe ausgeführt werden, selbst wenn die Dienstprogramme bestimmte Systemvorgänge ausführen, die Root-Berechtigungen erfordern.

Einstellungen für statische und dynamische ACSLS-Variablen prüfen

Die statischen und dynamischen ACSLS-Variablen steuern das Verhalten von vielen ACSLS-Funktionen. Legen Sie diese Variablen mit dem Dienstprogramm acsss_config fest. In diesem Dokument werden sichere Einstellungen für viele dieser Variablen beschrieben. Wenn die Optionen für eine Variable von acsss_config angezeigt werden und Sie mit einem Fragezeichen (?) antworten, wird eine detaillierte Erläuterung der Variable angezeigt. Diese Informationen sind auch im Kapitel "Variablen festlegen, die das ACSLS-Behavior kontrollieren" im ACSLS-Administratorhandbuch verfügbar.

Konfigurieren von WebLogic

ACSLS 8.1 Releases und höher verwenden WebLogic als Webserver. WebLogic wird mit ACSLS installiert.

In Oracle Fusion Middleware; Sicherheit für Oracle WebLogic Server 11g Release 1 (10.3.6) werden die Optionen zur Sicherung eines WebLogic-Servers und die Audittrailmöglichkeiten bei WebLogic beschrieben.

Erstellen und Verwalten von ACSLS-GUI-Benutzern mit dem ACSLS-Dienstprogramm userAdmin.sh

Das menügesteuerte Dienstprogramm userAdmin.sh wird zur Verwaltung von ACSLS-GUI-Benutzerpasswörtern verwendet. Sie können Benutzer hinzufügen, Benutzer entfernen, Benutzer auflisten und Benutzerpasswörter ändern. WebLogic muss gestartet sein, damit dieses Dienstprogramm verwendet werden kann. Wenn WebLogic nicht hochgefahren ist, startet dieses Dienstprogramm es und prüft, ob es online ist, bevor das Menü angezeigt wird.

Das Dienstprogramm userAdmin.sh muss von root ausgeführt werden und erfordert die acsls_admin-Authentifizierung. Das acsls_admin-Benutzerkonto wird während der ACSLS-Installation konfiguriert.

Verwenden der ACSLS-GUI

Zur Verwendung der ACSLS-GUI müssen Sie die neueste JRE-Version installieren und über einen Browser auf die ACSLS-GUI zugreifen.

Neueste JRE-Version auf GUI-Clientsystemen installieren

Stellen Sie sicher, dass die neueste Version von Java Runtime Environment (JRE) auf den Systemen installiert ist, die die ACSLS-GUI für den Zugriff auf ACSLS verwenden.

Zugreifen auf die ACSLS-GUI

Öffnen Sie einen Browser, und geben Sie eine URL mit dem Serverhostnamen oder der IP-Adresse im folgenden Format ein:

https://myAcslsHostName.myDomainName:7002/SlimGUI/faces/Slim.jsp or https://127.99.99.99:7002/SlimGUI/faces/Slim.jsp

Am besten geben Sie einen vollqualifizierten Hostnamen oder die IP-Adresse des Hostrechners ein. Einige Seiten, einschließlich der ACSLS-Hilfeseiten, werden möglicherweise nicht korrekt angezeigt, wenn die URL nicht vollständig von WebLogic aufgelöst werden kann.

Wenn Sie HTTP mit Port 7001 verwenden, nimmt WebLogic automatisch eine Umleitung zu HTTPS auf Port 7002 vor.

Weil WebLogic das sichere HTTPS-Protokoll verwendet, wird im Browser möglicherweise eine Warnung angezeigt, dass das Sitesicherheitszertifikat nicht registriert wurde und die Site somit nicht vertrauenswürdig ist. Wenn Sie sicher sind, dass die URL dem lokalen ACSLS-Rechner entspricht, können Sie gefahrlos fortfahren. Daraufhin sollte der Anmeldebildschirm angezeigt werden.

Verwenden der ACSLS-GUI

Sie greifen mit dem sicheren HTTPS-Protokoll auf die AcslsDomain in WebLogic zu. Dieses Protokoll nutzt verschlüsselte Kommunikation zwischen Browser und Server anhand von Private Keys und digitalen Zertifikaten. Sie haben folgende Optionen, ein digitales Zertifikat zu erhalten:

ACSLS-Demozertifikat

ACSLS wird mit einem so genannten "Demozertifikat" bereitgestellt. Dieses Zertifikat bietet eine minimale Ebene an Verschlüsselungssicherheit, sodass Kunden mit der Verwendung der ACSLS-GUI beginnen können, ohne weitere Konfigurationsschritte ausführen zu müssen. Wenn die Kundeninteraktion mit der ACSLS-Bibliothek vollständig innerhalb eines gesicherten Intranets stattfindet, ist dieses Demozertifikat normalerweise ausreichend. Bei dieser Methode wird aber ein 512-Bit-Verschlüsselungsschlüssel eingesetzt, der bei bestimmten Browsern nicht unterstützt wird, vor allem Internet Explorer und FireFox Version 39 und höher.

Konfigurieren eines selbstsignierten digitalen Zertifikats

Im ACSLS-Installationshandbuch wird die Methode, mit der ACSLS-Administratoren ein selbstsigniertes digitales Zertifikat mit einer Länge von 2048 Bit konfigurieren, ausführlich beschrieben. Mit der Methode im Abschnitt "Konfigurieren eines SSL-Verschlüsselungsschlüssels" erhalten Sie ein Zertifikat, das auf allen Browsern unterstützt wird. Benutzer, die mit einem selbstsignierten Zertifikat auf eine HTTPS-Site zugreifen, sollten die Site nur dann verwenden, wenn sie genau wissen, dass die Webressource eine vertrauenswürdige Site ist. Im Kontext von ACSLS-Benutzern und dem Bibliothekskontrollserver ist diese Vertrauensebene normalerweise klar umrissen, und in den meisten Fällen ist es nicht erforderlich, dass die Site ihre Integrität anhand einer Drittanbieter-Signaturüberprüfung nachweist.

Von einer Drittanbieter-Signaturstelle signierte digitale Zertifikate

Jede Kundensite kann bestimmen, ob die Zertifikatsauthentifizierung durch eine Drittanbieter-Signaturstelle, wie Verisign oder Entrust.net, bereitgestellt werden muss. Das Verfahren zum Generieren eines derartigen signierten digitalen Zertifikats wird im Oracle-Onlinedokument "Configuring Identity and Trust" unter:

http://docs.oracle.com/cd/E13222_01/wls/docs92/secmanage/identity_trust.html beschrieben

Installieren von ACSLS HA

Wenn Sie die ACSLS High Availability-Lösung verwenden, befolgen Sie die Anweisungen in ACSLS-HA-Cluster: Installation, Konfiguration und Vorgänge.