This chapter outlines the planning process for a secure installation and describes several recommended deployment topologies for the systems.
To better understand security needs, the following questions must be asked:
You can protect many of the resources in the production environment. Consider the type of resources that you want to protect when determining the level of security to provide.
When using Oracle HSM, protect the following resources:
These disk resources are used to build Oracle HSM file systems. They are typically Fibre Channel (FC) connected. Independent access to these disks (not by means of Oracle HSM) presents a security risk because normal Oracle HSM file and directory permissions are bypassed. This type of external access might be from a rogue system that reads or writes the FC disks, or from an internal system that accidentally provides non-root access to raw device files.
Independent access to tapes, typically in a tape library, where file data is written when staged off an Oracle HSM file system is a security risk.
File system dumps that are created from samfsdump contain data and metadata. This data and metadata should be protected from access other than by the system administrator during a routine dump or restore activity.
Oracle HSM clients require TCP/IP access to the MDS. However, ensure that the clients are protected from external WAN access.
Oracle HSM configuration settings must be protected from non-administrator access. In general, these settings are protected automatically by Oracle HSM when you use the Manager GUI. Note that making the configuration files writable to non-administrative users presents a security risk.
This section describes how to install and configure an infrastructure component securely.For information about installing Oracle HSM, see the Oracle Hierarchical Storage Manager Release 6.0 Customer Documentation Library at: http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#samqfs
Consider the following points when installing and configuring Oracle HSM:
To connect Oracle HSM clients to the MDS servers, provide a separate TCP/IP network and switch hardware that is not connected to any WAN. Because the metadata traffic is implemented by using TCP/IP, an external attack on this traffic is theoretically possible. Configuring a separate metadata network mitigates this risk and also provides enhanced performance. The improved performance is achieved by providing a guaranteed data path to the metadata. If a separate metadata network is infeasible, at least deny traffic to the Oracle HSM ports from the external WAN and any untrusted hosts on the network. See "Restrict Network Access to Critical Services".
Use FC zoning to deny access to the Oracle HSM disks from any server that does not require access to the disks. Preferably, use a separate FC switch to physically connect only to the servers that require access.
SAN RAID disks can usually be accessed for administrative purposes by means of TCP/IP or more typically HTTP. You must protect the disks from external access by limiting the administrative access to SAN RAID disks to systems only within a trusted domain. Also, change the default password on the disk arrays.
First, install only those packages that you require. For example, if you do not hierarchical storage management, install only the QFS packages. The default Oracle HSM file and directory permissions and owners should not be changed after installation without considering the security implications of such changes.
If you plan to configure shared clients, determine which clients must have access to the file system in the hosts file. See the hosts.fs(4) man page. Configure only those hosts that require access to the particular file system being configured.
For information about hardening the Oracle Solaris OS, see the Oracle Solaris 10 Security Guidelines and the Oracle Solaris 11 Security Guidelines. At a minimum, choose a good root password, install an up-to-date version of the Oracle Solaris OS, and keep current on patches, particularly security patches.
Check the Linux documentation about how to harden Linux clients. At a minimum, choose a good root password, install an up-to-date version of the Linux operating system, and keep current on patches, particularly security patches.
Prevent external access to Oracle HSM tapes from outside of Oracle HSM, or limit such access to administrators only. Use FC zoning to limit the access to tape drives to only the MDS (or potential MDS if a backup MDS is configured). Solaris clients that will be configured to use distributed I/O will need access to tape drives. Also, limit tape device file access by granting root only permissions. Unauthorized access to Oracle HSM tapes can compromise or destroy user data.
Set up and perform backups of Oracle HSM data by using the samfsdump or qfsdump command. Limit access to dump tapes as is recommended for Oracle HSM tapes.
For information about securely installing the SAM-Remote software, see the Oracle Hierarchical Storage Manager and StorageTek QFS Software Release 6.0 Customer Documentation Library at: http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#samqfs
For information about securely installing the Manager GUI, Oracle Hierarchical Storage Manager and StorageTek QFS Software Release 6.0 Customer Documentation Library at: http://www.oracle.com/technetwork/documentation/tape-storage-curr-187744.html#samqfs
After installing any of the Oracle HSM packages, go through the security checklist in Appendix A, "Secure Deployment Checklist."