In diesem Abschnitt werden die spezifischen Sicherheitsverfahren bei ACSLS beschrieben.
Die ACSLS-Sicherheitsanforderungen ergeben sich aus der Notwendigkeit, Daten zu schützen: erstens vor versehentlichem Verlust oder Beschädigung und zweitens vor absichtlichen nicht autorisierten Versuchen, auf diese Daten zuzugreifen oder sie zu ändern. Danach kommt der Schutz vor ungebührlichen Verzögerungen beim Zugriff auf Daten oder der Verwendung von Daten oder sogar vor Störungen bis zu Denial of Service.
Folgende kritische Sicherheitsfunktionen bieten diesen Schutz:
Authentifizierung: Stellt sicher, dass nur autorisierte Personen auf das System und die Daten zugreifen können.
Autorisierung: Ermöglicht Zugriffskontrolle für Systemberechtigungen und Daten. Dies baut auf der Authentifizierung auf, um sicherzustellen, dass Einzelpersonen nur den erforderlichen Zugriff erhalten.
Audit: Beim Audit können Administratoren versuchte Verletzungen des Authentifizierungsverfahrens und versuchte oder erfolgreiche Verletzungen der Zugriffskontrolle erkennen.
Standardmäßig werden ACSLS-Benutzer bei Linux oder Solaris über PAM (Pluggable Authentication Modules) authentifiziert. Weitere Informationen finden Sie auf den Solaris-Manpages oder im Linux-PAM System Administrators Guide.
Benutzer der ACSLS-GUI werden über den eingebetteten LDAP-Server in WebLogic authentifiziert. Weitere Informationen finden Sie im Dokument "Managing the Embedded LDAP Server":
http://docs.oracle.com/cd/E13222_01/wls/docs81/secmanage/ldap.html
Die ACSLS-Benutzer acsss und acssa müssen sich bei Solaris oder Linux anmelden. Sie werden vom Betriebssystem authentifiziert, bevor sie cmd_proc verwenden oder (beim acsss-Benutzer) ACSLS-Dienstprogramme und Konfigurationsbefehle ausführen können. Außerdem wird die acsdb-Benutzer-ID bei datenbankbezogenen Vorgängen verwendet. Im Rahmen der ACSLS-Installation müssen Kunden die Passwörter für diese IDs festlegen, wenn sie sich das erste Mal bei ihnen anmelden. Weitere Einzelheiten finden Sie im ACSLS-Installationshandbuch.
ACSLS-GUI-Benutzer müssen sich bei WebLogic anmelden und von WebLogic authentifiziert werden. Der acsls_admin wird während der ACSLS-Installation erstellt, und Kunden müssen sein Passwort festlegen. Kunden können nach Bedarf andere GUI-Benutzer mit dem Dienstprogramm userAdmin.sh hinzufügen. Weitere Einzelheiten finden Sie im ACSLS-Installationshandbuch und im Kapitel "Utilitys", Abschnitt userAdmin.sh, im ACSLS-Administratorhandbuch.
Hier werden allgemeine Überlegungen zum Auditing bei ACSLS beschrieben.
Auch wenn das Auditing relativ unaufwendig ist, begrenzen Sie die Anzahl von auditierten Ereignissen so weit wie möglich. Auf diese Weise werden die Performanceauswirkungen bei der Ausführung von auditierten Anweisungen und die Größe des Audittrails minimiert, sodass dieser einfacher zu analysieren, zu verstehen und zu verwalten ist.
Beachten Sie die folgenden allgemeinen Richtlinien bei der Festlegung einer Auditstrategie:
ACSLS verfügt über verschiedene Logs mit Informationen, mit denen Sie die ACSLS-Aktivität aufzeichnen und prüfen können.
Die meisten Logs können mit vi und anderen Editoren angezeigt werden. Systemereignisse können nur mit der ACSLS-GUI angezeigt werden.
Die meisten dieser Logs können automatisch archiviert werden, wenn sie eine bestimmte vom Kunden definierte Größe erreichen. Eine vom Kunden festgelegte Anzahl von Logs wird beibehalten. Damit das ACSLS-Dateisystem nicht zu sehr gefüllt wird, gibt es einen konfigurierbaren Grenzwert für die Anzahl von beibehaltenen Logs. Wenn Sie mehr Logdateien beibehalten oder diese auf einem anderen System beibehalten möchten, müssen Sie Ihre eigene Prozedur entwickeln, um sie an einem Ort mit ausreichend Speicherplatz zu archivieren.
Größe, Anzahl von beizubehaltenden archivierten Logs und andere Eigenschaften dieser Dateien werden von dynamischen und statischen ACSLS-Variablen definiert.
Das ACSLS-Logverzeichnis wird von der statischen Variable LOG_PATH gesteuert. Das Standardverzeichnis ist $ACS_HOME/log. Dieses Verzeichnis enthält folgende Logs:
In diesem Log werden Meldungen für wichtige ACSLS-Systemereignisse, Bibliotheksereignisse und Fehler aufgezeichnet.
Wenn die Größe von acsss_event.log einen von der dynamischen Variable LOG_SIZE definierten Schwellenwert erreicht, wird es in das event0.log kopiert und gelöscht. Beim Kopieren werden die beibehaltenen Ereignislogs in beibehaltene Logs mit einer höheren Nummer kopiert, und das beibehaltene Log mit der höchsten Nummer wird überschrieben. Beispiel: event8.log wird über event9.log kopiert, event7.log wird über event8.log kopiert, …, event0.log wird über event1.log kopiert, acsss_event.log wird über event0.log kopiert, und acsss_event.log wird gelöscht. Dies wird von folgenden Variablen gesteuert:
EVENT_FILE_NUMBER gibt die Anzahl von beizubehaltenden Ereignislogs an.
LOG_SIZE gibt die Schwellenwertgröße an, bei der das Ereignislog in ein beibehaltenes Ereignislog kopiert und abgeschnitten wird.
Mit dem Dienstprogramm greplog können Sie das acsss_event-Log so filtern, dass Meldungen mit bestimmten Schlüsselwörtern einbezogen oder ausgeschlossen werden. Weitere Einzelheiten finden Sie unter "greplog" im Kapitel "Utilitys" im ACSLS-Administratorhandbuch.
Es gibt zwei Logs, in denen Details aufgezeichnet werden, wenn ACSLS die Bibliothekskonfiguration aktualisiert, die in der ACSLS-Datenbank gespeichert ist. Konfigurationsänderungen von acsss_config und Dynamic Config (dem Dienstprogramm config) werden hier aufgezeichnet.
Zeichnet die Details aller Konfigurationen oder erneuten Konfigurationen der Bibliotheken auf, die von ACSLS unterstützt werden. Die letzte Konfigurationsänderung wird an die Aufzeichnung der vorherigen Konfigurationen angehängt.
Zeichnet Ereignisse während der Konfiguration oder erneuten Konfiguration auf.
Zeichnet die Antwort auf alle Anforderungen an ACSLS von ACSAPI-Clients oder cmd_proc und alle Anforderungen an die GUI oder die SCSI-Clientschnittstelle für logische Bibliotheken auf, mit Ausnahme von Datenbankabfragen. Die protokollierten Informationen umfassen den Anforderer, die Anforderung und den Zeitstempel der Anforderung.
rpTrail.log wird von den folgenden Variablen verwaltet:
LM_RP_TRAIL aktiviert diesen Audittrail von ACSLS-Ereignissen. Der Standardwert ist TRUE.
RP_TRAIL_LOG_SIZE gibt die Schwellenwertgröße an, bei der rpTrail.log komprimiert und archiviert wird.
RP_TRAIL_FILE_NUM gibt die Anzahl von archivierten rpTrail-Logs an, die beibehalten werden sollen.
RP_TRAIL_DIAG gibt an, ob die rpTrail-Meldungen zusätzliche Diagnoseinformationen enthalten sollen. Der Standardwert ist FALSE.
Zeichnet alle Ereignisse auf, die sich auf Datenträger (Kassetten) in einer Bandbibliothek auswirken. Dies umfasst die Angabe, wann ein Datenträger gemountet, dismountet, verschoben, eingelegt, entnommen oder beim Audit oder der Wiederherstellung von Kassetten gefunden wurde. Wenn "Library Volume Statistics" aktiviert ist, werden diese Informationen im acsss_stats.log aufgezeichnet.
Library Volume Statistics werden von folgenden Variablen verwaltet:
LIB_VOL_STATS aktiviert diese Library Volume Statistics. Der Standardwert ist OFF.
VOL_STATS_FILE_NUM gibt die Anzahl von archivierten acsss_stats.log-Dateien an, die beibehalten werden sollen.
VOL_STATS_FILE_SIZE gibt die Schwellenwertgröße an, bei der acsss_stats.log archiviert wird.
Innerhalb des ACSLS-Logverzeichnisses werden Informationen zur ACSLS-GUI und zur SCSI-Clientschnittstelle zu logischen Bibliotheken im sslm-Verzeichnis aufgezeichnet. Dieses Verzeichnis umfasst Links zu WebLogic-Auditlogs. Das sslm-Verzeichnis enthält die folgenden Logs:
In diesem Log werden Ereignisse aus der ACSLS-GUI und der SCSI-Clientschnittstelle aufgezeichnet. Es enthält Meldungen über Änderungen der logischen Bibliothekskonfiguration und SCSI-Clientereignisse.
.g# ist die Generierungsnummer dieses Logs.
.pp# ist die parallele Prozessnummer dieses Logs. Wenn mehrere Prozesse gleichzeitig protokolliert werden, wird den Logs aus den zusätzlichen Prozessen eine parallele Prozessnummer zugewiesen.
Dieses Log verfolgt Aktivitäten von SCSI-Clients zu logischen ACSLS-Bibliotheken mit der SCSI Media Changer Interface-Emulation.
Dies ist ein Link zu access.log von WebLogic. Siehe Konfigurieren und Verwenden der WebLogic-Auditlogs.
Dies ist ein Link zu AcslsDomain.log von WebLogic. Siehe Konfigurieren und Verwenden der WebLogic-Auditlogs.
Dies ist ein Link zu AdminServer.log von WebLogic. Siehe Konfigurieren und Verwenden der WebLogic-Auditlogs.
Rufen Sie den Log-Viewer aus dem Abschnitt "Configuration and Administration" des GUI-Navigationsbaums auf. Der Log-Viewer zeigt aus acsss_event.log und smce_trace.log kombinierte Informationen an.
Sie können im Abschnitt "Configuration and Administration" des GUI-Navigationsbaums auch Systemereignisse anzeigen. Jeder einzelne Bibliotheksvorgang wird im Systemereignislog aufgezeichnet. Jeder Datensatz in diesem Log enthält einen Ereigniszeitstempel, einen Ereignistyp und eine Beschreibung des Ereignisses.
Bestimmen Sie die Solaris-Auditingrichtlinie. Im Abschnitt "Oracle Solaris Auditing" im Oracle System Administration: Security Services-Handbuch wird beschrieben, wie Sie die Ereignisse planen, die auditiert werden sollen, und wie Sie angeben, wo die Auditlogs gespeichert und wie sie geprüft werden sollen.
Wenn Sie keine benutzerdefinierten Solaris-Audittrails aktiviert haben, sind diese Audittrails zu Anmeldungen und Unix-Befehlen, die von den acsss-, acsdb- und acssa-Benutzern abgesetzt wurden, verfügbar:
Benutzer, die derzeit bei Unix angemeldet sind, werden in der Unix utmpx-Datenbank und frühere Benutzerzugriffe in der wtmpx-Datenbank aufgezeichnet.
Mit dem Befehl last können Sie alle Zugriffe auf eine Benutzer-ID anzeigen (Beispiel: last acsss). Weitere Informationen finden Sie in den Manpages für: wtmpx, last und getutxent.
In den .*_history-(d.h. [dot]*_history-)Dateien im Home-Verzeichnis eines Benutzers werden die von diesem Benutzer abgesetzten Befehle aufgezeichnet.
Für den acsss-Benutzer können dies folgende Dateien sein:
.bash_history
.psql_history
.sh_history
Unter Solaris werden in /var/adm/sulog erfolgreiche und nicht erfolgreiche Versuche aufgezeichnet, su auszuführen und Superuser oder ein anderer Benutzer zu werden.
In den Abschnitten "Configuring and Using Auditing" und "Configuring and Using System Logging" im Oracle Linux: Security Guide for Release 6 wird beschrieben, wie Audit- und Systemlogs erfasst und analysiert werden.
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.
WebLogic zeichnet die Zugriffe auf die ACSLS-GUI in folgendem Verzeichnis auf:
/export/home/SSLM/AcslsDomain/servers/AdminServer/logs
Dieses Verzeichnis umfasst die folgenden Dateien:
access.log
Es enthält die archivierten Versionen namens access.log##### (Beispiel: access.log00001)
So erhalten Sie einen detaillierten Audittrail der GUI-Benutzeraktivität.
Anmeldungen finden Sie in "AcslsLoginForm".
Hinweis:
Es gibt einen Link zum Zugriffslog in: $ACS_HOME/logs/sslm/guiAccess.log.AcslsDomain.log
In diesem Log werden WebLogic- und ACSLS-GUI-Vorgänge aufgeführt.
Hinweis:
Es gibt einen Link zum Zugriffslog in: $ACS_HOME/logs/sslm/AcslsDomain.log.AdminServer.log
In diesem Log werden WebLogic- und ACSLS-GUI-Vorgänge aufgeführt.
Hinweis:
Es gibt einen Link zum Zugriffslog in: $ACS_HOME/logs/sslm/AdminServer.log.