3 Security Features

This section describes the specific security mechanisms offered by ACSLS.

The Security Model

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.

Configuring and Using Authentication

ACSLS users are authenticated by the Solaris or Linux OSs while ACSLS GUI users are authenticated by WebLogic.

ACSLS User Authentication by the Solaris or Linux Operating Systems

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 User Authentication by WebLogic

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.

Audit Considerations

General audit considerations that apply to ACSLS are described here.

Keeping Audited Information Manageable

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:

Evaluate the purpose for auditing

After you have a clear understanding of the reasons for auditing, you can devise an appropriate auditing strategy and avoid unnecessary auditing.

Audit knowledgeably

Audit the minimum number of statements, users, or objects required to get the targeted information.

Configuring and Using the ACSLS Audit Logs

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.

ACSLS Log Directory

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:

acsss_event.log

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.

Configuration logs

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.

acsss_config.log

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.

acsss_config_event.log

Records events during the configuration or re-configuration process.

rpTrail.log

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.

Library Volume Statistics

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.

ACSLS Log/sslm Directory

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:

slim_event.g#.log[.pp#]

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.

smce_trace.log

This traces activity from SCSI clients to ACSLS logical libraries using SCSI Media Changer Interface emulation.

guiAccess.log

This is a link to WebLogic's access.log. See Configuring and Using the WebLogic Audit Logs.

AcslsDomain.log

This is a link to WebLogic's AcslsDomain.log. See Configuring and Using the WebLogic Audit Logs.

AdminServer.log

This is a link to WebLogic's AdminServer.log. See Configuring and Using the WebLogic Audit Logs.

Viewing ACSLS Audit Trails from the GUI's Log Viewer

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.

View System Events from the GUI

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.

Configuring and Using the Solaris Audit Logs

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.

Configuring and Using the Linux Audit Logs

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.

Configuring and Using the WebLogic Audit 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.