StorageTek Automated Cartridge System Library Software Security Guide Release 8.3 E49313-02 |
|
Previous |
Next |
This section describes the specific security mechanisms offered by ACSLS.
ACSLS security requirements arise from the need to protect data: first, from accidental loss and corruption; and second from deliberate unauthorized attempts to access or alter that data. Secondary concerns include protecting against undue delays in accessing or using data, or even against interference to the point of denial of service.
The critical security features that provide these protections are:
Authentication – ensures that only authorized individuals get access to the system and data.
Authorization – provides access control to system privileges and data. This builds on authentication to ensure that individuals only get appropriate access.
Audit – allows administrators to detect attempted breaches of the authentication mechanism and attempted or successful breaches of access control.
ACSLS users are authenticated by the Solaris or Linux OSs while ACSLS GUI users are authenticated by WebLogic.
The ACSLS users: acsss and acssa must log into Solaris or Linux and be authenticated by the operating system before they can use cmd_proc or for the acsss user, execute ACSLS utilities and configuration commands. The acsdb user ID is also used for database-related operations. As part of the ACSLS installation process, customers must set the passwords for these IDs the first time they log into them. See the ACSLS Installation Guide for details.
ACSLS GUI users must log into and be authenticated by WebLogic. The acsls_admin is created during ACSLS installation, and customers must set its password. Customers can add other GUI users as desired using the userAdmin.sh
utility. For details see the ACSLS Installation Guide and the ACSLS Administrator's Guide, ”Utilities” chapter, section on userAdmin.sh
.
General audit considerations that apply to ACSLS are described here.
Although auditing is relatively inexpensive, limit the number of audited events as much as possible. Doing so minimizes the performance impact on the execution of audited statements and the size of the audit trail, making it easier to analyze, understand, and manage.
Use the following general guidelines when devising an auditing strategy:
ACSLS has several logs of information that let you record and inspect ACSLS activity.
You can view most of them using vi and other editors. System Events can only be viewed by using the ACSLS GUI.
Most of these logs can be automatically archived when they reach a customer defined size, and a customer specified number of logs will be retained. To avoid filling the ACSLS filesystem there is a configurable limit to the number of logs that will be retained. If you want to retain more of these log files or retain them on another system, you need to develop your own procedure to archive them in a location that has sufficient space.
The size, number of archived logs to retain, and other characteristics of these files are defined by ACSLS dynamic and static variables.
The ACSLS log directory is controlled by the LOG_PATH static variable. The default is the $ACS_HOME/log directory. This directory includes these logs:
This records messages for significant ACSLS system events, library events, and errors.
When the acsss_event.log reaches a threshold size defined by the LOG_SIZE dynamic variable, it is copied to the event0.log and cleared. During the copy process, the retained event logs are copied into higher numbered retained logs and the highest numbered retained log is overlaid. For example: the event8.log is copied over the event9.log, the event7.log is copied over the event8.log, …, the event0.log is copied over the event1.log, the acsss_event.log is copied over the event0.log, and the acsss_event.log is cleared. This is controlled by the following variables:
EVENT_FILE_NUMBER specifies the number of event logs to retain.
LOG_SIZE specifies the threshold size at which the event log is copied to a retained event log and truncated.
Use the greplog
utility to filter the acsss_event log to include or to exclude messages containing specific keywords. See greplog in the ”Utilities” Chapter in the ACSLS Administrator's Guide for more details.
There are two logs that record details when ACSLS updates the library configuration stored in the ACSLS database. Configuration changes from both acsss_config
and Dynamic Config
(the config
utility) are recorded here.
Records the details of all configurations or re-configurations of the library(s) that ACSLS supports. The last configuration change is appended to the record of previous configurations.
Records events during the configuration or re-configuration process.
Records the response to all requests to ACSLS from ACSAPI clients or cmd_proc, and all requests to the GUI or the SCSI Client interface to logical libraries except for database queries. The information logged includes the requestor, the request, and the request's time stamp.
rpTrail.log is managed by the following variables:
LM_RP_TRAIL enables this audit trail of ACSLS events. The default is TRUE.
RP_TRAIL_LOG_SIZE specifies the threshold size at which the rpTrail.log is compressed and archived.
RP_TRAIL_FILE_NUM specifies the number of archived rpTrail logs to retain.
RP_TRAIL_DIAG specifies whether the rpTrail messages should include additional diagnostic information. The default is FALSE.
Records all events affecting volumes (cartridges) in a tape library, including whenever a volume is mounted, dismounted, moved, entered, ejected, or found by audit or Cartridge Recovery. If Library Volume Statistics is enabled, this information is recorded in the acsss_stats.log.
Library Volume Statistics is managed by the following variables:
LIB_VOL_STATS enables this Library Volume Statistics. The default is OFF.
VOL_STATS_FILE_NUM specifies the number of archived acsss_stats.log files to retain.
VOL_STATS_FILE_SIZE specifies the threshold size at which the acsss_stats.log is archived.
Within the ACSLS log directory, information about the ACSLS GUI and the SCSI Client interface to logical libraries is logged in the sslm directory. This directory includes links to WebLogic audit logs. The sslm directory includes these logs:
This records both events from the ACSLS GUI and the SCSI client interface. It includes messages of logical library configuration changes, and SCSI client events.
The .g# is the generation number of this log.
The .pp# is the parallel process number of this log. If there are multiple processes logging at the same time, the logs from the additional processes will be assigned a parallel process number.
This traces activity from SCSI clients to ACSLS logical libraries using SCSI Media Changer Interface emulation.
This is a link to WebLogic's access.log. See Configuring and Using the WebLogic Audit Logs.
This is a link to WebLogic's AcslsDomain.log. See Configuring and Using the WebLogic Audit Logs.
This is a link to WebLogic's AdminServer.log. See Configuring and Using the WebLogic Audit Logs.
Access the Log Viewer from the Configuration and Administration section of the GUI Navigation Tree. The Log Viewer displays information combined from the acsss_event.log and the smce_trace.log.
You can also view System Events from the Configuration and Administration section of the GUI navigation tree. Every discrete library operation is recorded in the System Events log. Each record in this log contains an event time stamp, an event type, and a description of the event.
Determine your Solaris auditing policy. The Oracle Solaris Auditing section in the Oracle System Administration: Security Services manual can help you plan for what events to audit, where your audit logs should be saved, and how you want to review them.
If you have not enabled custom Solaris audit trails, these audit trails of logins and Unix commands issued by the acsss, acsdb, and acssa users are available:
Users who are currently signed on to Unix are recorded in the Unix utmpx and past user access is recorded in the wtmpx database.
Use the last
command to see all access to a user ID (for example last acsss
). For more information see the man pages for: wtmpx, last
, and getutxent.
The .*_history (that is [dot]*_history) files in a user's home directory record the commands issued by that user.
For the acsss user these may include:
.bash_history
.psql_history
.sh_history
On Solaris /var/adm/sulog records successful and unsuccessful attempts to execute su
and become superuser or another user.
Refer to the Configuring and Using Auditing and Configuring and Using System Logging sections in Oracle Linux: Security Guide for Release 6 for details about collecting and analyzing audit and system logs.
Refer to Oracle Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.5) for the options for securing a WebLogic server, and the audit trail possibilities with WebLogic.
WebLogic records access to the ACSLS GUI in the following directory:
/export/home/SSLM/AcslsDomain/servers/AdminServer/logs
This directory includes the following files:
access.log
There are archived versions named access.log##### (for example access.log00001)
This provides a detailed audit trail of a GUI user activity.
For logins look for ”AcslsLoginForm”.
Note: There is a link to the access log in: $ACS_HOME/logs/sslm/guiAccess.log. |
AcslsDomain.log
This reports WebLogic and ACSLS GUI operations.
Note: There is a link to the access log in: $ACS_HOME/logs/sslm/AcslsDomain.log. |
AdminServer.log
This reports WebLogic and ACSLS GUI operations.
Note: There is a link to the access log in: $ACS_HOME/logs/sslm/AdminServer.log. |