Skip Headers
Oracle® Secure Backup Installation and Configuration Guide
Release 10.4

Part Number E21477-05
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Managing Security for Backup Networks

This chapter describes how to make your backup network more secure. Oracle Secure Backup is automatically configured for network security in your administrative domain, but you can enhance that basic level of security in several ways. Secure communications among the nodes of your administrative domain concerns the encryption of network traffic among your hosts. Secure communications is distinct from Oracle Secure Backup user and roles security concerns and security addressed by the encryption of backups to tape.

See Also:

Oracle Secure Backup Administrator's Guide for more information on users and roles management or backup encryption

This chapter contains these sections:

6.1 Backup Network Security Overview

An Oracle Secure Backup administrative domain is a network of hosts. Any such network has a level of vulnerability to malicious attacks. The task of the security administrator is to learn the types of possible attacks and techniques to guard against them. Your backup network must meet the following requirements to be both useful and secure:

  • Software components must not expose the hosts they run on to attack.

    For example, daemons should be prevented from listening on a well-known port and performing arbitrary privileged operations.

  • Data managed by the backup software must not be viewable, erasable, or modifiable by unauthorized users.

  • Backup software must permit authorized users to perform these tasks.

Oracle Secure Backup meets these requirements in its default configuration. By default, all hosts that run Oracle Secure Backup must have their identity verified before they can join the administrative domain. A host within the domain uses an X.509 certificate for host authentication. After a Secure Sockets Layer (SSL) connection is established between hosts, control and data messages are encrypted when transmitted over the network. SSL protects the administrative domain from eavesdropping, message tampering or forgery, and replay attacks.

Network backup software such as Oracle Secure Backup is only one component of a secure backup network. Oracle Secure Backup can supplement but not replace the physical and network security provided by administrators.

6.2 Planning Security for an Administrative Domain

If security is of primary concern in your environment, then you might find it helpful to plan for network security in the following stages:

After completing these stages, you can proceed to the implementation phase as described in "Configuring Security for the Administrative Domain".

6.2.1 Identifying Assets and Principals

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:

  • 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 a larger network that contains 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.

  • Host owners

    Each host owner has complete access to its file system.

  • System administrators

    These users might 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 a larger network that contains the Oracle Secure Backup domain. Onlookers might own a host outside the domain.

The relationships between assets and principals partially determine the level of security in the Oracle Secure Backup administrative domain:

  • 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 can 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.

6.2.2 Identifying Your Backup Environment Type

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 assets and principals 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.

6.2.2.1 Single System

The most basic administrative domain is illustrated in Figure 6-1. It consists of an administrative server, media server, and client on a single host.

Figure 6-1 Administrative Domain with One Host

Description of Figure 6-1 follows
Description of "Figure 6-1 Administrative Domain with One Host"

This type of environment is small and isolated from the wider network. The data in this network type is probably on the low end of the sensitivity range. For example, the domain might consist of a server used to host personal Web sites within a corporate network.

The assets include only a host and a tape device. The users probably include only the backup administrator and system administrator, who might 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, tape devices, and networks used by the domain.

In this network type, the domain is fairly secure because it has one isolated host accessed by only a few trusted users. The administrator of the domain would probably not make security administration a primary concern, and the backup administrator could reasonably expect almost no overhead for maintaining and administering security in the Oracle Secure Backup domain.

6.2.2.2 Data Center

The administrative domain illustrated in Figure 6-2 is of medium size and is deployed in a secure environment such as a data center.

Figure 6-2 Administrative Domain with Multiple Hosts

Description of Figure 6-2 follows
Description of "Figure 6-2 Administrative Domain with Multiple Hosts"

The number of hosts, devices, and users in the administrative domain is much larger than in the single system network type, but it is still a small subset of the network at large. The data in this network type is probably on the high end of the sensitivity range. An example could be a network of hosts used to store confidential employee data. Network backups are conducted on a separate, secure, dedicated network.

The assets are physically secure computers in a dedicated network. The administrative domain could potentially include a dozen media server hosts 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 computers, devices, and network.

  • Database administrators can access their own databases and possibly have physical access to their database computers.

  • Host administrators can access their file systems and possibly have physical access to their computers.

As with the single system network type, the administrative domain exists in a network environment that is secure. Administrators secure each host, tape device, and tapes by external means. Active attacks by a hacker are not likely. Administrators assume that security maintenance and administration for the domain requires almost no overhead. Backup and system administrators are primarily concerned with whether Oracle Secure Backup moves data between hosts efficiently.

6.2.2.3 Corporate Network

In this environment, multiple administrative domains, multiple media server hosts, and numerous client hosts exist in a corporate network.

The number of hosts, devices, and users in the administrative domains is extremely large. Data backed up includes both highly sensitive data such as human resources information and less sensitive data such as the home directories of low-level employees. Backups probably occur on the same corporate network used for e-mail, and Internet access. The corporate network is 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 can have multiple users. Some host owners can have their own Oracle Secure Backup account to initiate a restore of their file systems or databases.

The security requirements for this backup environment are different from the single system and data center examples. Given the scope and distribution of the network, 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 must not compromise an entire administrative domain. A malicious user on a compromised computer must not be able to access data that was backed up by other users on other hosts. This user must 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 must encrypt their backups, so physical access to backup media does not reveal the backup contents. The encryption and decryption must be performed on the client host itself, so sensitive data never leaves the host in unencrypted form.

Note:

Oracle Secure Backup offers an optional and highly configurable backup encryption mechanism that ensures that data stored on tape is safe from prying eyes. Backup encryption is fully integrated with Oracle Secure Backup and is ready to use as soon as Oracle Secure Backup is installed. Backup encryption applies to both file-system data and Recovery Manager (RMAN) generated backups.

6.2.3 Choosing Secure Hosts for the Administrative and Media Servers

Your primary task when configuring security for your domain is providing physical and network security for your hosts and determining which hosts should perform the administrative server and media server roles.

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 threats to data, but not all. 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 observing the owner of a client host entering his or her 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 communications based on Network Data Management Protocol (NDMP).

  • Deliberately misusing an Oracle Secure Backup identity

    If a person with Oracle Secure Backup administrator rights turns malicious, then he or she can wreak havoc on the administrative domain. For example, he or she could overwrite the file system on every host in the domain. No backup software can force a person always to behave in the best interests of your organization.

6.2.4 Determining the Distribution Method of Host Identity Certificates

After you have analyzed your backup environment and considered how to secure it, you can decide how each host in the domain obtains its identity certificate. Oracle Secure Backup uses Secure Sockets Layer (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.

The administrative server of the administrative domain is the CA for the domain. After you configure the administrative server, you can create each media server and client in the domain in either of the following modes:

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 host just 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 identity certificate responses to the host. Instead, you must carry a copy of the signed identity certificate on physical media to the host and then use the obcm utility to import the certificate into the wallet of the 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 host. You can reissue the mkhost command after the rogue host has been eliminated from the network.

See Also:

If you are considering manual certificate provisioning modes, then you must decide if the extra protection provided is worth the administrative overhead. Automated mode is safe in the single system and data center environments, because network communications are usually isolated.

Automated mode is also safe in the vast majority of corporate network cases. The corporate network is vulnerable to man-in-the-middle attacks only if attackers can insert themselves into the network between the administrative server and the host being added. This is the only place they can intercept network traffic and act as the man in the middle. This is difficult without the assistance of a rogue employee.

Manual certificate provisioning mode is recommended if the host being added is outside the corporate network, because communications with off-site hosts offer more interception and diversion opportunities.

6.3 Trusted Hosts

Starting with Oracle Secure Backup release 10.3 certain hosts in the administrative domain are assumed to have a higher level of security, and are treated as having an implicit level of trust. These hosts are the administrative server and each media server. These hosts are classified by Oracle Secure Backup as trusted hosts. Hosts configured with only the client role are classified as non-trusted hosts.

Many Oracle Secure Backup operations are reserved for use by trusted hosts, and fail if performed by a non-trusted host. These operations include:

  • Use of obtar commands

  • Direct access to physical devices and libraries

  • Access to encryption keys

This policy provides an extra level of security against attacks that might originate from a compromised client system. For example, consider an Oracle Secure Backup administrative domain with host admin as the administrative server, host media as the media server, and host client as the client. An Oracle Secure Backup user belonging to a class that has the manage devices class right attempts to run lsvol -L library_name in obtool. If the attempt is made on client, then it fails with an illegal request from non-trusted host error. The same command succeeds when attempted on admin or media.

You can turn off these trust checks by setting the Oracle Secure Backup security policy trustedhosts to off. This disables the constraints placed on non-trusted hosts.

Note:

Commands that originate from the Oracle Secure Backup Web tool are always routed to the administrative server for processing, and are not affected by the trustedhosts policy.

6.4 Host Authentication and Communication

By default, Oracle Secure Backup uses the Secure Sockets Layer (SSL) protocol to establish a secure communication channel between hosts in an administrative domain. Each host has an X.509 certificate known as an identity certificate. This identity certificate is signed by a Certification Authority (CA) and uniquely identifies this host within the administrative domain. The identity certificate is required for authenticated SSL connections.

Note:

Currently, the Network Data Management Protocol (NDMP) does not support an SSL connection to a filer.

This section contains these topics:

6.4.1 Identity Certificates and Public Key Cryptography

An identity certificate has both a body and a digital signature. The contents of a certificate include the following:

  • A public key

  • The identity of the host

  • What the host is authorized to do

Every host in the domain, including the administrative server, has a private key known only to that host that is stored with the host's identity certificate. This private key corresponds to a public key that is made available to other hosts in the administrative domain.

Any host in the domain can use a public key to send an encrypted message to another host. But only the host with the corresponding private key can decrypt the message. A host can use its private key to attach a digital signature to the message. The host creates a digital signature by submitting the message as input to a cryptographic hash function and then encrypting the output hash with a private key.

The receiving host authenticates the digital signature by decrypting it with the sending host's public key. Afterwards, the receiving host decrypts the encrypted message with its private key, inputs the decrypted message to the same hash function used to create the signature, and then compares the output hash to the decrypted signature. If the two hashes match, then the message has not been tampered with.

Figure 6-3 illustrates how host B can encrypt and sign a message to host A, which can in turn decrypt the message and verify the signature.

Figure 6-3 Using Public and Private Keys to Encrypt and Sign Messages

Description of Figure 6-3 follows
Description of "Figure 6-3 Using Public and Private Keys to Encrypt and Sign Messages"

6.4.2 Authenticated SSL Connections

For hosts to securely exchange control messages and backup data within the domain, they must first authenticate themselves to one another. Host connections are always two-way authenticated except for the initial host invitation to join a domain and communication with Network Data Management Protocol (NDMP) servers.

In two-way authentication, the hosts participate in a handshake process whereby they mutually decide on a cipher suite to use, exchange identity certificates, and validate that each other's identity certificate has been issued by a trusted Certification Authority (CA). At the end of this process, a secure and trusted communication channel is established for the exchange of data.

The use of identity certificates and Secure Sockets Layer (SSL) prevents outside attackers from impersonating a client in the administrative domain and accessing backup data. For example, an outside attacker could not run an application on a non-domain host that sends messages to domain hosts that claim origin from a host within the domain.

6.4.3 Certification Authority

The service daemon (observiced) on the administrative server is the root Certification Authority (CA) of the administrative domain. The primary task of the CA is to issue and sign an identity certificate for each host in the administrative domain. The CA's signing certificate, which it issues to itself and then signs, gives the CA the authority to sign identity certificates for hosts in the domain. The relationship of trust requires that all hosts in the administrative domain can trust certificates issued by the CA.

Each host stores its own identity certificate and a trusted certificate (or set of certificates) that establishes a chain of trust to the CA. Like other hosts in the domain, the CA stores its identity certificate. The CA also maintains a signing certificate that authorizes the CA to sign the identity certificates for the other hosts in the domain.

6.4.3.1 Automated and Manual Certificate Provisioning Mode

Oracle Secure Backup provides automated and manual modes for initializing the security credentials for a client host that wants to join the domain. The automated mode is easy to use, but it has potential security vulnerabilities. The manual mode is harder to use, but it is less vulnerable to tampering.

In automated certificate provisioning mode, which is the default, adding a host to the domain is transparent. The host generates a public key/private key pair and then sends a certificate request, which includes the public key, to the Certification Authority (CA). The CA issues the host an identity certificate, which it sends to the host along with any certificates required to establish a chain of trust to the CA.

The communication between the two hosts is over a secure but non-authenticated Secure Sockets Layer (SSL) connection. It is conceivable that a rogue host could insert itself into the network between the CA and the host, thereby masquerading as the legitimate host and illegally entering the domain.

In manual certificate provisioning mode, the CA does not automatically transmit certificate responses to the host. You must transfer the certificate as follows:

  1. Use the obcm utility to export a signed certificate from the CA.

  2. Use a secure mechanism such as a floppy disk or USB key chain drive to transfer a copy of the signed identity certificate from the CA to the host.

  3. Use obcm on the host to import the transferred certificate into the host's wallet. The obcm utility verifies that the certificate request in the wallet matches the signed identity certificate.

You must balance security and usability to determine which certificate provisioning mode is best for your administrative domain.

6.4.4 Oracle Wallet

Oracle Secure Backup stores every certificate in an Oracle wallet. The wallet is represented on the operating system as a password-protected, encrypted file. Each host in the administrative domain has its own wallet in which it stores its identity certificate, private key, and at least one trusted certificate. Oracle Secure Backup does not share its wallets with other Oracle products.

Besides maintaining its password-protected wallet, each host in the domain maintains an obfuscated wallet. This version of the wallet does not require a password. The obfuscated wallet, which is scrambled but not encrypted, enables the Oracle Secure Backup software to run without requiring a password during system startup.

Note:

To reduce risk of unauthorized access to obfuscated wallets, Oracle Secure Backup, by default, does not back them up. The obfuscated version of a wallet is named cwallet.sso. Oracle Secure Backup will backup a cwallet.sso file only if that file is included as part of an encrypted backup or the backup dataset includes an explicit path name of the cwallet.sso file. For more information about including an encrypted wallet in the dataset, see Oracle Secure Backup Reference.

By default, the wallet is located in /usr/etc/ob/wallet on Linux and UNIX and C:\Program Files\Oracle\Backup\db\wallet on Windows.

The password for the password-protected wallet is generated by Oracle Secure Backup and not made available to the user. The password-protected wallet is not usually used after the security credentials for the host have been established, because the Oracle Secure Backup daemons use the obfuscated wallet.

Figure 6-4 illustrates the relationship between the certificate authority and other hosts in the domain.

Figure 6-4 Oracle Wallets

Description of Figure 6-4 follows
Description of "Figure 6-4 Oracle Wallets"

6.4.4.1 Oracle Secure Backup Encryption Wallet

The administrative server has a second wallet that is used to store the master keys that encrypt secure data, such as the passwords for Network Data Management Protocol (NDMP) servers and the backup encryption key store. This wallet is separate from the wallet used for a host identity certificate. The key wallet is named ewallet.p12 and is located in OSB_HOME/admin/encryption/wallet.

It is a best practice to use Oracle Secure Backup catalog recovery to back up the wallet.

If you do not use Oracle Secure Backup catalog recovery to back up the wallet, then Oracle recommends that the ewallet.p12 encryption wallet not be backed up on the same media as encrypted data. Encryption wallets are not excluded from backup operations automatically. You must use the exclude dataset statement to specify what files to skip during a backup:

exclude name *.p12

See Also:

Oracle Secure Backup Administrator's Guide for more information on dataset statements and catalog recovery

6.4.5 Web Server Authentication

The Apache Web server for the administrative domain runs on the administrative server as the obhttpd daemon. When you issue commands through the Oracle Secure Backup Web tool, obhttpd repackages them as obtool commands and passes them to an instance of obtool running on the administrative server.

The Web server requires a signed X.509 certificate and associated public key/private key pair to establish an Secure Sockets Layer (SSL) connection with a client Web browser. The X.509 certificate for the Web server is self-signed by the installob program when you install Oracle Secure Backup on the administrative server. Figure 6-5 shows the interaction between Web server and client.

Figure 6-5 Web Server Authentication

Description of Figure 6-5 follows
Description of "Figure 6-5 Web Server Authentication"

The Web server X.509 certificate and keys are not stored in the wallet used for host authentication in the Oracle Secure Backup administrative domain, but are stored in files in the /apache/conf subdirectory of the Oracle Secure Backup home. A single password protects the certificates and keys. This password is stored in encrypted form in the daemons file located in /admin/config/default. When the Web server starts, it obtains the password by using a mechanism specified in the Web server configuration file. This password is never transmitted over the network.

6.4.6 Revoking a Host Identity Certificate

Revoking a host identity certificate is an extreme measure that would only be performed if the backup administrator determined that the security of a computer in the Oracle Secure Backup administrative domain had been breached in some way.

You can revoke a host identity certificate with the revhost command in obtool.

See Also:

Oracle Secure Backup Reference for revhost syntax and semantics

If you revoke a host identity certificate, then none of the Oracle Secure Backup service daemons accept connections from that host. Revocation is not reversible. If you revoke a host identity certificate and then change your mind, then you must reinstall the Oracle Secure Backup software on the affected host.

6.5 Encryption of Data in Transit

Figure 1-2, "Oracle Secure Backup Administrative Domain with Multiple Hosts" illustrates the control flow and data flow within an administrative domain. Control messages exchanged by hosts in the administrative domain are encrypted by Secure Sockets Layer (SSL).

Data flow in the domain includes both file-system and database backup data. To understand how backup encryption affects data, it is helpful to distinguish between data at rest, which is backup data that resides on media such as disk or tape, and data in transit, which is backup data in the process of being transmitted over the network.

File-system backups and unencrypted RMAN backups on tape (data at rest) can be encrypted by Oracle Secure Backup. RMAN-encrypted backups made through the Oracle Secure Backup SBT interface are supported, but the encryption is provided by RMAN before the backup is provided to the SBT interface. The Oracle Secure Backup SBT interface is the only supported interface for making encrypted RMAN backups directly to tape.

See Also:

Oracle Secure Backup Administrator's Guide for more information on Oracle Secure Backup encryption

If you have selected RMAN or Oracle Secure Backup encryption, then Oracle Secure Backup does not apply additional encryption to data in transit within an administrative domain. If you have not selected either RMAN encryption or Oracle Secure Backup encryption, then backup data in transit, both file-system and database data, is not encrypted through SSL by default. To improve security, you can enable encryption for data in transit within the administrative domain with the encryptdataintransit security policy.

To enable backup encryption in the encryptdataintransit security policy:

  1. Log in to obtool as a user with the modify administrative domain's configuration right.

  2. Use the setp command to switch the encryptdataintransit policy to no, as shown in the following example:

    ob> cdp security
    ob> setp encryptdataintransit yes
    

See Also:

Oracle Secure Backup Reference for more information on the encryptdataintransit security policy

Suppose you want to back up data on client host client_host to a tape drive attached to media server media_server. Data encryption depends on what encryption options you choose and on what you are backing up, as shown in the following examples:

  • Encrypted RMAN backup of a database on client_host.

    RMAN encrypts the backup before it is provided to the SBT interface on client_host. Oracle Secure Backup transfers the RMAN-encrypted data over the network to media_server. Oracle Secure Backup does not apply additional encryption to the data as it passes over the network. After Oracle Secure Backup writes the data to tape, the data resides on tape in encrypted form.

  • Unencrypted RMAN backup of a database on client_host.

    Oracle Secure Backup does not encrypt the data before transferring it over the network to media_server. After Oracle Secure Backup writes the data to tape, the data resides on tape in unencrypted form.

  • Unencrypted RMAN backup of a database on client_host with encryptdataintransit set to yes.

    Oracle Secure Backup encrypts the data before transferring it over the network to media_server. The encrypted data is decrypted at media_server. After Oracle Secure Backup writes the data to tape, the data resides on tape in unencrypted form.

  • Encrypted Oracle Secure Backup backup of the file system on client_host.

    Oracle Secure Backup transfers the encrypted backup data over the network to media_server. Oracle Secure Backup does not apply additional encryption to the data as it passes over the network. After Oracle Secure Backup writes the data to tape, the file-system data resides on tape in encrypted form.

  • Unencrypted Oracle Secure Backup of the file system on client_host.

    Oracle Secure Backup does not encrypt the data before transferring it over the network to media_server. After Oracle Secure Backup writes the data to tape, the data resides on tape in unencrypted form.

  • Unencrypted Oracle Secure Backup of the file system on client_host with encryptdataintransit set to yes.

    Oracle Secure Backup encrypts the data before transferring it over the network to media_server. The encrypted data is decrypted at media_server. After Oracle Secure Backup writes the data to tape, the data resides on tape in unencrypted form.

See Also:

Oracle Database Backup and Recovery Advanced User's Guide to learn about encryption of RMAN backups

6.6 Default Security Configuration

When you install Oracle Secure Backup on the administrative server, the installation program configures the administrative server as the Certification Authority (CA) automatically. By default, security for an administrative domain is configured as follows:

When you add hosts to the administrative domain, Oracle Secure Backup creates the wallet, keys, and certificates for each host when you create the hosts in obtool or the Oracle Secure Backup Web tool. No additional intervention or configuration is required.

You can also change the default configuration in any of the following ways:

  • Disable SSL for inter-host authentication and communication by setting the securecomms security policy

  • Transmit identity certificates in manual certificate provisioning mode

  • Set the key size for a host to a value greater or less than the default of 1024 bits

  • Enable encryption for backup data in transit by setting the encryptdataintransit security policy

6.7 Configuring Security for the Administrative Domain

This section describes how to configure security for the administrative domain.

This section contains these topics:

6.7.1 Providing Certificates for Hosts in the Administrative Domain

Providing a certificate for each host in the Oracle Secure Backup administrative domain requires that you first configure the administrative server and then configure each media server and client.

6.7.1.1 Configuring the Administrative Server

If you install Oracle Secure Backup on a host and specify this host as the administrative server, then this server is the Certification Authority (CA) for the Oracle Secure Backup administrative domain. Oracle Secure Backup configures the host as the CA automatically as part of the standard installation. You are not required to take additional steps to provide a signing certificate for this server.

Oracle Secure Backup automatically creates the following items:

  • A host object corresponding to the administrative server in the object repository on the administrative server.

  • 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.

  • A request for a signing certificate in the wallet.

  • A signed certificate in response to the request and stores the certificate in the wallet.

  • A request for an identity certificate in the wallet.

  • A signed certificate in response to the request and stores it in the wallet.

  • An obfuscated wallet in the local wallet directory.

The administrative server now has the signing certificate, which it must have to sign the identity certificates for other hosts, and its identity certificate, which it must have to establish authenticated Secure Sockets Layer (SSL) connections with other hosts in the domain.

6.7.1.2 Configuring Media Servers and Clients

Oracle Secure Backup creates security credentials for a host when you use the Oracle Secure Backup Web tool or run the mkhost command in obtool to configure the host. The procedure differs depending on whether you add hosts in automated or manual certificate provisioning mode.

Automated Certificate Provisioning Mode

If you create the hosts in automated certificate provisioning mode, then you are not required to perform additional steps. Oracle Secure Backup creates the wallet, keys, and certificates for the host automatically as part of the normal host configuration.

Manual Certificate Provisioning Mode

You must use the obcm utility when you add hosts in the domain in manual rather than automated certificate provisioning mode. In this case, the certificate authority does not issue a signed certificate to a 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)

The obcm utility always accesses the wallet in the preceding locations. You cannot override the default location.

If you choose to add hosts in manual certificate provisioning mode, then you must perform the following steps for each host:

  1. Log on to the administrative server.

  2. Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the obcm utility. The operating system user running obcm must have write permissions in the wallet directory.

  3. 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
    
  4. Copy the signed identity certificate to some type of physical media and physically transfer the media to the host.

  5. Log on to the host whose wallet contains the certificate.

  6. Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the obcm utility. The operating system user running obcm must have write permissions in the wallet directory.

  7. Copy the signed identity certificate to a temporary location on the file system.

  8. 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 are not required to specify the --host option. For example, the following example imports the certificate from /tmp/brhost2_cert.f:

    import --file /tmp/brhost2_cert.f
    

    The obcm utility issues an error message if the certificate being imported does not correspond to the certificate request in the wallet.

  9. Remove the certificate file from its temporary location on the operating system. For example:

    rm /tmp/brhost2_cert.f
    

The obcm utility checks that the public key associated with the certificate for the host corresponds to the private key stored in the wallet with the certificate request. If the keys match, then the 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 host during processing of the mkhost command. You can run the mkhost command again after the rogue host has been eliminated from the network.

6.7.2 Setting the Size for Public and Private Keys

As a general rule, the larger the sizes of the public key and the private key, the more secure they are. 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 are not required 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

  • 3072

  • 2048

  • 1024

  • 768

  • 512

This section contains these topics:

6.7.2.1 Setting the Key Size in obparameters

The obparameters file specifies the default key size in the security policy, which if used is set up during the installation process. The key size for all hosts in the domain defaults to this value.

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 the obparameters file.

To set the key size in obparameters when installing interactively:

  1. 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.

  2. Search for the following string: certificate key size. Set the key size to the desired default value. The following example sets the default key size to 2048 bits:

    identity certificate key size: 2048
    
  3. Save and close the file after making any other changes to obparameters.

  4. 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.

Note:

There is no equivalent procedure for Windows. Windows users are restricted to the default value.

6.7.2.2 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 changed key size.

You can set the key size in the certkeysize security policy through obtool or the Oracle Secure Backup Web tool. Oracle Secure Backup uses the modified key size the next time you configure a 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:

  1. Log in to obtool as a user with the modify administrative domain's configuration right.

  2. Set the certkeysize policy to the desired default value. The following example shows how to use obtool to set the key size to 3072 bits:

    ob> cdp security
    ob> setp certkeysize 3072
    

See Also:

Oracle Secure Backup Administrator's Guide to learn how to set a policy

6.7.2.3 Setting the Key Size in mkhost

You can override the default key size for any individual host. Different hosts in the domain can have different key sizes.

You can set the key size when you use the mkhost command or Oracle Secure Backup Web tool to configure a host. If you specify the --certkeysize option on the mkhost command, then the specified 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 running, obtool might display a status message every 5 seconds. obtool displays a command prompt when the process has completed.

To set the key size in the mkhost command:

  1. Log in to obtool as a user with the modify administrative domain's configuration right.

  2. Issue the mkhost command to set the key size for a host. The following example sets the key size to 4096 bits when configuring client stadf56. This setting applies only to host stadf56.

    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
    
    

See Also:

Oracle Secure Backup Reference to learn how to use the mkhost command

6.7.3 Enabling and Disabling SSL for Host Authentication and Communication

By default Oracle Secure Backup uses authenticated and encrypted Secure Sockets Layer (SSL) connections for all control message traffic among hosts.

You can disable SSL encryption by setting the securecomms security policy to off. Disabling SSL might improve performance, but be aware of the inherent security risks in this action.

To set the securecomms security policy:

  1. Log in to obtool as a user with the modify administrative domain's configuration right.

  2. Use the setp command to switch the securecomms policy to off, as shown in the following example:

    ob> cdp security
    ob> setp securecomms off
    

See Also:

Oracle Secure Backup Administrator's Guide to learn how to set a policy

6.8 Managing Certificates with obcm

This section explains how to use the obcm utility. You can use this utility to import certificates, export certificates, and export certificate requests.

You must use obcm when you add hosts in the domain in manual rather than automated certificate provisioning mode. In this case, the Certification Authority (CA) does not issue a signed certificate to a 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)

The obcm utility always accesses the wallet in the preceding locations. You cannot override the default location.

6.8.1 Exporting Signed Certificates

You can use obcm on the administrative server to export a signed certificate for a newly configured host.

To export a signed identity certificate:

  1. Log on to the administrative server.

  2. Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the obcm utility. The operating system user running obcm must have write permissions in the wallet directory.

  3. 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
    

6.8.2 Importing Signed Certificates

You can use obcm on the host to import a signed certificate into the host's wallet.

To import a signed identity certificate into the wallet of a host:

  1. Log on to the host whose wallet contains the certificate.

  2. Assuming that your PATH variable is set correctly, enter obcm at the operating system command line to start the obcm utility. The operating system user running obcm must have write permissions in the wallet directory.

  3. Copy the signed identity certificate to a temporary location on the file system.

  4. 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 are not required to specify the --host option. For example, the following example imports the certificate from /tmp/brhost2_cert.f:

    import --file /tmp/brhost2_cert.f
    

    The obcm utility issues an error message if the certificate being imported does not correspond to the certificate request in the wallet.

  5. Remove the certificate file from its temporary location on the operating system. For example:

    rm /tmp/brhost2_cert.f