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 DIVArchive, protect the following resources:
There are Data Disk and Cache Disk resources used to build DIVArchive systems. They are typically local or remote disks connected to the DIVArchive systems. Independent access to these disks (other than by DIVArchive) presents a security risk. This type of external access might be from a rogue system that reads or writes to these disks, or from an internal system that accidentally provides access to these disk devices.
There are Database Disk, Metadata Disk and Backup Disk resources used to build DIVArchive systems with complex objects. They are typically local or remote disks connected to the DIVArchive systems. Independent access to these disks (other than by DIVArchive) presents a security risk. This type of external access might be from a rogue system that reads or writes to these disks, or from an internal system that accidentally provides access to these disk devices.
It is a security risk to allow independent access to tapes, typically in a tape library controlled by DIVArchive systems, where data is written.
Tape Metadata dumps that are created from export operations contain data and metadata. This data and metadata permissions must be restricted to only the Administrator (or root) operating system account, or the DIVA operating system user (or group) during a routine export or import activity.
DIVArchive system configuration settings must be protected from operating system level non-administrator users. Making the configuration files writable to non-administrative operating system users presents a security risk, therefore, these file permissions must be restricted to only the Administrator (or root) operating system account, or the DIVA operating system user (or group).
This section describes how to install and configure an infrastructure component securely.For more information, see the Oracle DIVArchive documentation set for this release located at https://docs.oracle.com/en/storage/#csm
.
Consider the following points when installing and configuring DIVArchive:
For connections between DIVArchive services components, connection to Metadata Database, and the connection from its clients, provide a separate TCP/IP network and switch hardware that is not connected to any WAN. Because the metadata traffic is implemented 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. If a separate network is infeasible, at least deny traffic to the DIVArchive 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 DIVArchive disks connected through the Fibre Channel 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 through 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 DIVArchive services that you require. For example, if you do not plan to run the GUI or Configuration Utility from a system, then uncheck them in the list of components to be installed during installation. The default DIVArchive installation directory permissions and owners must be restricted to only the Administrator (or root) account, or the DIVA operating system user (or group).
After installing any of the DIVArchive, go through the security checklist in Appendix A.