| Oracle® Secure Backup Administrator's Guide Release 10.1 Part Number B14234-02 |
|
|
View PDF |
| Oracle® Secure Backup Administrator's Guide Release 10.1 Part Number B14234-02 |
|
|
View PDF |
This chapter provides a detailed explanation of security in an Oracle Secure Backup domain and how to configure it. This chapter contains the following topics:
See Also:
"Network Backup Security" for an overview of security architecture of an administrative domainIf security is of primary concern in your environment, then you may find it helpful to plan for the security implementation in the following stages:
Choosing Secure Hosts for the Administrative and Media Servers
Determining the Distribution Method of Host Identity Certificates
After completing these stages, you can proceed to the implementation phase as described in "Configuring Security for the Administrative Domain".
The first step in planning security for an administrative domain is determining the assets and principals associated with the domain.
The assets of the domain include the following:
The database and file system data requiring backup
Metadata about the database and file system data
Passwords
Identities
Hosts and storage devices
Principals are users who either have access to the assets associated with the administrative domain or to the network that forms the superset of the domain. Principals include the following users:
Backup administrators
These Oracle Secure Backup users have administrative rights in the domain, access to the tapes containing backup data, and the rights required to perform backup and restore operations.
Database administrators
Each database administrator has complete access to his or her own database.
Hosts owners
Each host owner has complete access to the file system of this host.
System administrators
These users may have access to the corporate network and to the hosts in the administrative domain (although not necessarily root access).
Onlookers
These users do not fall into any of the preceding categories of principals, but can access the network that forms the superset of the Oracle Secure Backup domain. Onlookers may own a host outside of the domain.
Principals stand in a variety of relationships to the assets. These relationships partially determine the level of security in the Oracle Secure Backup administrative domain.
One way to view the security level of the domain is in terms of which principals have access to assets that they do not own. In the highest level of security, the only principal with access to an asset is the owner. For example, only the owner of a client host has the ability to read or modify data from this host. In a medium level of security, the asset owner and the administrator of the domain both have access to the asset. In the lowest level of security, any principal can access any asset in the domain.
After you have identified the assets and principals involved in your administrative domain, you can characterize the type of environment in which you are deploying the domain. The type of environment partially determines which security model to use.
The following criteria partially distinguish types of network environments:
Scale
The number of principals and assets associated with a domain plays an important role in domain security. A network that includes 1000 hosts and 2000 users has more points of entry for an attacker than a network of 5 hosts and 2 users.
Sensitivity of data
The sensitivity of data is measured by how dangerous it would be for the data to be accessed by a malicious user. For example, the home directory on a rank-and-file corporate employee's host is presumably less sensitive than a credit card company's subscriber data.
Isolation of communication medium
The security of a network is contingent on the accessibility of network communications among hosts and devices in the domain. A private, corporate data center is more isolated in this sense than an entire corporate network.
The following sections describe types of network environments in which Oracle Secure Backup administrative domains are typically deployed. The sections also describe the security model typical for each environment.
The most basic administrative domain consists of an administrative server, media server, and client. As shown in Figure 1-3, "Administrative Domain with One Host", a single host can assume all three roles.
This type of environment has the following characteristics:
Scale
The number of hosts, devices, and users in the administrative domain is small.
Sensitivity of data
The data in this scenario is assumed to be on the low end of the sensitivity range. For example, the domain may consist of two servers used to host personal Web sites within a corporate network.
Isolation of communication medium
This type of network is isolated from the wider network.
The assets include only a few hosts and a tape device. The users may include only the backup administrator and system administrator, which could conceivably be the same person. The backup administrator is the administrative user of the Oracle Secure Backup domain and is in charge of backups on the domain. The system administrator manages the hosts, devices, and networks used by the domain.
In this scenario, the domain is fairly secure because it has only a few, isolated hosts accessed by a few trusted users. Thus, the administrator of the domain would probably not make security administration a primary concern. In this scenario, the backup administrator could reasonably expect almost no overhead for maintaining and administering security in the Oracle Secure Backup domain.
This administrative domain is of medium size and is deployed in a secure environment such as a data center.
This type of environment has the following characteristics:
Scale
The number of hosts, devices, and users in the administrative domain is much larger than in the single system scenario, although still a small subset of the network at large.
Sensitivity of data
The data in this scenario is assumed to be on the high end of the sensitivity range. An example could be a network of hosts used to store confidential employee data.
Isolation of communication medium
Network backups are conducted on a separate, secure, dedicated network.
The assets are physically secure machines in a dedicated network. The administrative domain could potentially include a dozen media servers that service the backups of a few hundred databases and file systems.
Principals include the following users:
The backup administrator accesses the domain as an Oracle Secure Backup administrative user.
The system administrator administers the machines, devices, and the network.
Database administrators can access their own databases and possibly have physical access to their database machines.
Host administrators can access their file systems and possibly have physical access to their machines.
As with the single system scenario, the administrative domain exists in a network environment that is already secure. Administrators secure hosts, drives, and tapes by external means. Active attacks by a hacker are not likely. Thus, administrators assume that security maintenance and administration for the domain requires almost no overhead. Backup and system administrators are concerned with performance, that is, whether Oracle Secure Backup moves data between hosts efficiently.
In this environment, one or more administrative domains, multiple media servers, and numerous client hosts exist in a corporate network.
This type of environment has the following characteristics:
Scale
The number of hosts, devices, and users in the administrative domains is extremely large.
Sensitivity of data
Data backed up includes both highly sensitive data such as HR information as well as less sensitive data such as the home directories of low-level employees.
Isolation of communication medium
Backups probably occur on the same corporate network used for email, Internet access, and so on, and are protected by a firewall from the broader Internet.
The assets include basically every piece of data and every computer in the corporation. Each administrative domain—and there may be several—could have multiple users. Some host owners could have their own Oracle Secure Backup account to initiate a restore of their host's file system or database.
The security requirements for this backup environment are different from the single system and data center examples. Given the scope and distribution of the product, compromised client hosts are highly likely. For example, someone could steal a laptop used on a business trip. Malicious employees could illicitly log in to computers or run tcpdump or similar utilities to listen to network traffic.
The compromise of a client host should not lead to the disablement or compromise of an entire administrative domain. A malicious user on a compromised machine should not be able to access data that was backed up by other users on other hosts. This user should also not be able to affect normal operation of the other hosts in the administrative domain.
Security administration and performance overhead is expected. Owners of sensitive assets should encrypt their backups so that physical access to backup media does not reveal the backup contents. These users should perform encryption and decryption on the client host itself so that sensitive data never leaves the host in unencrypted form.
Note:
The RMAN Backup Encryption feature provides encryption for database backups on disk or tape. Oracle Secure Backup does not encrypt file system backup data stored on tape.Your primary task when configuring security for your domain is providing physical and network security for your hosts and determining which hosts should be the administrative and media servers.
When choosing administrative and media servers, remember that a host should only be an administrative or media server if it is protected by both physical and network security. For example, a host in a data center could be a candidate for an administrative server because it presumably belongs to a private, secured network accessible to a few trusted administrators.
Oracle Secure Backup cannot itself provide physical or network security for any host nor verify whether such security exists. For example, Oracle Secure Backup cannot stop malicious users from performing the following illicit activities:
Physically compromising a host
An attacker who gains physical access to a host can steal or destroy the primary or secondary storage. For example, a thief could break into an office and steal servers and tapes. Encryption can reduce some of the threat to data, but not all. Note that an attacker who gains physical access to the administrative server compromises the entire administrative domain.
Accessing the operating system of a host
Suppose an onlooker steals a password by looking at the fingers of the owner of a client host as he types his password. This malicious user could telnet to this host and delete, replace, or copy the data from primary storage. The most secure backup system in the world cannot protect data from attackers if they can access the data in its original location.
Infiltrating or eavesdropping on the network
Although backup software can in some instances communicate securely over insecure networks, it cannot always do so. Network security is an important part of a backup system, especially for NDMP-based communications.
Deliberating misusing an Oracle Secure Backup identity
If a person with Oracle Secure Backup administrator rights turns bad, he can wreak havoc on the administrative domain. For example, he could overwrite the file system on every host in the domain. No backup software can force a person to behave morally.
After you have analyzed your backup environment and considered how to secure it, you can decide how hosts in the domain obtain their identity certificates. As explained in "Host Authentication and Communication", Oracle Secure Backup uses SSL to establish a secure and trusted communication channel between domain hosts. Each host has an identity certificate signed by the Certification Authority (CA) that uniquely identifies this host within the domain. The identity certificate is required for authenticated SSL connections.
As explained in "Certification Authority", the administrative server of the domain is the CA for the administrative domain. After you configure the administrative server, you can create the media servers and clients in the domain. You can create the media servers and clients in either of the following modes:
automated certificate provisioning mode
In this case, no manual administration is required. When you configure the hosts, the CA issues identity certificates to the new hosts over the network.
manual certificate provisioning mode
In this case, you must manually import the identity certificate for each host into its wallet.
Automated mode is easier to use but is vulnerable to unlikely man-in-the-middle attacks in which an attacker steals the name of a new host right before you invite it to join the domain. This attacker could use the stolen host identity to join the domain illicitly. Manual mode is more difficult to use than automated mode, but is not vulnerable to the same kinds of attacks.
In manual mode, the administrative server does not transmit certificate responses to the new host. Instead, you must carry a copy of the signed identity certificate on physical media to the new host and then use the obcm utility to import the certificate into the wallet of the new host. The obcm utility verifies that the certificate request in the wallet matches the signed identity certificate. A verification failure indicates that a rogue host likely attempted to masquerade as the new host. You can reissue the mkhost command after the rogue host has been eliminated from the network.
When deciding between manual and automated certificate provisioning modes, consider the following question: Is the extra protection provided by manual certificate provisioning mode worth the administrative overhead? The single system and data center environments have isolated network communications; thus, automated mode is probably the better choice. The corporate network is much more vulnerable to the man-in-the-middle attack, so manual mode is a more reasonable option. Nevertheless, the number of hosts in the domains is probably very large, so the administrative overhead is significant.
This section describes how to configure security for the administrative domain. This section includes the following topics:
Providing Certificates for Hosts in the Administrative Domain
Enabling and Disabling Encryption for Backup Data in Transit
Enabling and Disabling SSL for Host Authentication and Communication
Configuring the domain involves the following tasks:
If you install Oracle Secure Backup on a host and specify this host as the administrative server, then this server is the CA. Oracle Secure Backup configures the host as the CA automatically as part of the standard installation. You do not need to take additional steps to provide a signing certificate for this server.
Oracle Secure Backup automatically performs the following actions:
Creates a host object corresponding to the administrative server in the object repository on the administrative server.
Creates a wallet to contain the administrative server's certificates. The wallet resides in the directory tree of the Oracle Secure Backup home. Oracle Secure Backup uses the host ID as the wallet password.
Creates a request for a signing certificate in the wallet.
Creates a signed certificate in response to the request and stores the certificate in the wallet.
Creates a request for an identity certificate in the wallet.
Creates a signed certificate in response to the request and stores it in the wallet.
Creates the obfuscated wallet in the local wallet directory.
The administrative server now has the signing certificate, which it needs to sign the identity certificates for other hosts, and its identity certificate, which it needs to establish authenticated SSL connections with other hosts in the domain.
Oracle Secure Backup creates security credentials for a new host when you use the Web tool or execute the mkhost command in obtool to configure the host. As explained in "Determining the Distribution Method of Host Identity Certificates", the procedure differs depending on whether you add hosts in automated or manual certificate provisioning mode.
If you create the new hosts in automated mode, then you do not need to perform additional steps. Oracle Secure Backup creates the wallet, keys, and certificates for the host automatically as part of the normal host configuration.
When you execute the mkhost command, Oracle Secure Backup automatically performs the following steps over a secure (but nonauthenticated) SSL connection:
Oracle Secure Backup creates a host object corresponding to the new host in the administrative server's object repository.
Oracle Secure Backup sends a "set host ID" message to observiced on the new host.
The observiced on the new host performs the following actions during processing of the "set host ID" message:
observiced creates a wallet to contain the host's certificates. The wallet resides in the directory tree of the Oracle Secure Backup home. Oracle Secure Backup uses the host ID as the wallet password.
observiced creates a request for an identity certificate in the wallet.
observiced returns a status message indicating success or failure of the operation.
The observiced on the new host sends a certificate request message to the observiced running on the administrative server. The request contains the new host's identity certificate to be signed by the CA.
On the administrative server, observiced signs the new host's identity certificate and returns the signed certificate and trusted certificates to the new host in the response to the certificate request message.
On the new host, observiced performs the following actions as part of processing the certificate response message:
observiced stores the signed identity certificate in the wallet along with the trusted certificates of the CA.
observiced creates the obfuscated wallet in the file system of the Oracle Secure Backup home.
observiced returns a status message indicating success or failure of the operation.
The new host now owns a key pair, an identity certificate, and the trusted certificates. The host has everything it needs to create secure, two-way authenticated SSL connections with other hosts in the administrative domain.
If you choose to add new hosts in manual mode, then you must perform the following steps for each new host:
Issue the mkhost command to configure the host.
In response to the mkhost command, Oracle Secure Backup performs the same steps as it does in automated mode, but stops short of step 5. In manual mode, the observiced running on the administrative server does not transmit certificates to the new host over the network.
Export the signed certificate for the new host from the administrative server by using the obcm utility. This task is described in "Exporting Signed Certificates".
Copy the signed identity certificate to some type of physical media and physically transfer the media to the new host.
Import the signed certificate into the wallet of the new host by using the obcm utility. This task is described in "Importing Signed Certificates".
The obcm utility checks that the public key associated with the certificate for the new host corresponds to the private key stored in the wallet with the certificate request. If the keys match, then the new host is a member of the domain. If the keys do not match, then an attacker probably attempted to pass off their own host as the new host during processing of the mkhost command. You can execute the mkhost command again after the rogue host has been eliminated from the network.
As a general rule, the larger the size of the public and private key, the more secure it is. On the other hand, the smaller the key, the better the performance. The default key size for all hosts in the domain is 1024 bits. If you accept this default, then you do not need to perform any additional configuration.
Oracle Secure Backup enables you to set the key to any of the following bit values, which are listed in descending order of security:
4096 (very secure)
3072 (very secure)
2048 (secure)
1024 (secure)
768 (not secure)
512 (not secure)
You can set the key size in the follow ways:
Setting the Key Size in obparameters
The obparameters file specifies the default key size in the security policy. The key size for all hosts in the domain defaults to this value.
Setting the Key Size in the certkeysize Security Policy
You can change the default key size in the security policy at any time. Any hosts configured after the change default to the new key size.
Setting the Key Size in mkhost
You can override the default key size for any individual host. Thus, different hosts in the domain can have different key sizes.
You can set the key size in the obparameters file when you install Oracle Secure Backup on the administrative server. When you install Oracle Secure Backup interactively, the install script gives you an opportunity to modify obparameters.
To set the key size in obparameters when installing interactively:
Before running the install script on the administrative server, or when the install script prompts you to modify obparameters, open the file in a text editor.
Search for the following string: certificate key size. Set the key size to the desired default value. Example 11-1 sets the default key size to 2048 bits.
Save and close the file after making any other changes to obparameters.
Proceed with the installation.
Oracle Secure Backup uses the key size in obparameters to set the initial value for the certkeysize security policy. This security policy specifies the default security key size for hosts in the domain. You can change or override this default when configuring an individual host.
You can set the key size in the certkeysize security policy through obtool or the Web tool. Oracle Secure Backup uses the modified key size the next time you configure a new host. You can change the certkeysize value at any time, but the change only applies to the next mkhost command.
To set the certkeysize security policy:
Log in to obtool as a user with the modify administrative domain's configuration right.
Set the certkeysize policy to the desired default value. Example 11-2 shows how to use obtool to set the key size to 3072 bits.
See Also:
"Setting a Policy" to learn how to set a policyYou can set the key size when you use the mkhost command or Web tool to configure a new host. If you specify the --certkeysize option on the mkhost command, the value overrides the default certificate key size set in the security policy. The key size applies only to the newly configured host and does not affect the key size of any other current or future hosts.
Because larger key sizes require more computation time to generate the key pair than smaller key sizes, the key size setting can affect the processing time of the mkhost command. While the mkhost command is executing, obtool may display a status message every 5 seconds. obtool displays a command prompt when the process has completed (see Example 11-3).
To set the key size in the mkhost command:
Log in to obtool as a user with the modify administrative domain's configuration right.
Issue the mkhost command to set the key size for a new host. Example 11-3 shows how to set the key size to 4096 bits when configuring new client stadf56. This setting applies only to host stadf56.
Example 11-3 Setting the Key Size in mkhost
ob> mkhost --inservice --role client --certkeysize 4096 stadf56 Info: waiting for host to update certification status... Info: waiting for host to update certification status... Info: waiting for host to update certification status... Info: waiting for host to update certification status... ob> lshost stadf56 stadf56 client (via OB) in service
As explained in "Data Encryption", the default is for backup data to be encrypted while it is transferred within the administrative domain. For example, if a backup job backs up the root directory on client C to media server M, then the file system backup data is encrypted while being sent from C to M.
You can disable encryption for backup data in transit by setting the encryptdataintransit security policy to no.
To enable backup encryption in the encryptdataintransit security policy:
Log in to obtool as a user with the modify administrative domain's configuration right.
Use the setp command to switch the encryptdataintransit policy to no. Example 11-4 shows how to perform this task.
See Also:
"Setting a Policy" to learn how to set a policyAs explained in "Host Authentication and Communication", by default Oracle Secure Backup uses authenticated and encrypted SSL connections for all inter-host control message traffic.
You can disable SSL encryption by setting the securecomms security policy to off. Disabling SSL may help to improve performance, but be aware of the inherent security risks in this action.
To set the securecomms security policy:
Log in to obtool as a user with the modify administrative domain's configuration right.
Use the setp command to switch the securecomms policy to off. Example 11-5 shows how to perform this task.
See Also:
"Setting a Policy" to learn how to set a policyThis section explains how to use the obcm utility. You can use this utility to import certificates, export certificates, and export certificate requests.
You need to use obcm when you add new hosts in the domain in manual rather than automated certificate provisioning mode. In this case, the CA does not issue a signed certificate to a new host over the network, so you must export the signed certificate from the administrative server, manually transfer the certificate to the newly configured host, and then import the certificate into the host's wallet.
Both an identity certificate and a wallet exist as files on the operating system. The operating system user running obcm must have write permissions in the wallet directory. By default, the wallet used by Oracle Secure Backup is located in the following locations:
/usr/etc/ob/wallet (UNIX and Linux)
C:\Program Files\Oracle\Backup\db\wallet (Windows)
obcm always accesses the wallet in the preceding locations. You cannot override the default location.
Use obcm on the administrative server to export a signed certificate for a newly configured host.
To export a signed identity certificate:
Log on to the administrative server.
Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the utility. The operating system user running obcm must have write permissions in the wallet directory.
Enter the following command, where hostname is the name of the host requesting the certificate and certificate_file is the file name of the exported request:
export --certificate --file certificate_file --host hostname
For example, the following command exports the signed certificate for host brhost2 to file /tmp/brhost2_cert.f:
export --certificate --file /tmp/brhost2_cert.f --host brhost2
Use obcm on the new host to import a signed certificate into the host's wallet.
To import a signed certificate into the wallet of a new host:
Log on to the host whose wallet will contain the certificate.
Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the utility. The operating system user running obcm must have write permissions in the wallet directory.
Copy the signed identity certificate to a temporary location on the file system.
Enter the following command at the obcm prompt, where signed_certificate_file is the file name of the certificate:
import --file signed_certificate_file
Because only one Oracle Secure Backup wallet exists on the host, you do not need to specify the --host option. For example, the following example imports the certificate from /tmp/brhost2_cert.f:
import --file /tmp/brhost2_cert.f
Note that obcm issues an error message if the certificate being imported does not correspond to the certificate request in the wallet.
Remove the certificate file from its temporary location on the operating system. For example:
rm /tmp/brhost2_cert.f
