Managing Security for Backup Networks

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.

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

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.

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.

Single System

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

Figure 9-1 Administrative Domain with One Host

Description of "Figure 9-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.

Data Center

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

Figure 9-2 Administrative Domain with Multiple Hosts

Description of "Figure 9-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.

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.

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.

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.

See Also:

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 certificate provisioning mode

In this case, no manual administration is required. When you configure the hosts, the CA issues identity certificates to the 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 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:

"Managing Certificates with obcm"
Oracle Secure Backup Reference for more information on the obcm utility

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.

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.

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.

You can validate the authenticity of your domain by using the obtool –authenticate command. This command invokes obtool and requests for the domain credentials, before executing a command.

This section contains these topics:

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 9-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 9-3 Using Public and Private Keys to Encrypt and Sign Messages

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

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.

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.

For more information on managing CA, see Managing Certificates with obcm.

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.

To transfer the certificate:

Use the obcm utility to export a signed certificate from the CA.
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.
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.

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 does not back them up. The obfuscated version of a wallet is named cwallet.sso. 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 9-4 illustrates the relationship between the certificate authority and other hosts in the domain.

Figure 9-4 Oracle Wallets

Description of "Figure 9-4 Oracle Wallets"

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

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 when you install Oracle Secure Backup on the administrative server. Figure 9-5 shows the interaction between Web server and client.

Figure 9-5 Web Server Authentication

Description of "Figure 9-5 Web Server Authentication"

The X.509 certificate and keys for the Web server are stored separately from the Oracle Secure Backup authentication keys. 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. When you access the Oracle Secure Backup Web tool, if the browser does not display a warning that the certificate is not trusted, or if the browser reports unable to connect or can't find the page, the web certificates may have expired. To renew the web certificates, open a command prompt and run obwebcert upgrade, then follow the instructions on your command prompt.

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.

Encryption of Data in Transit

Figure 1-2 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 encryptdataintransmit 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, 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 User’s Guide to learn about encryption of RMAN backups

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:

Secure Sockets Layer (SSL) is used for host authentication and message integrity.
The CA signs and issues the identity certificate for each domain host in automated certificate provisioning mode.
The size of the public key and private key for every host in the domain is 3072 bits.
Host communications within the domain are encrypted by SSL.

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 3072 bits
Enable encryption for backup data in transit by setting the encryptdataintransit security policy

Configuring Security for the Administrative Domain

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

This section contains these topics:

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.

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.

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:

Enter the following command to set the security policy autocertissue to No:
```
obtool setp security/autocertissue --no
```
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 obcm 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 filename 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
```
Copy the signed identity certificate to some type of physical media and physically transfer the media to the host.
Log on to the host whose wallet contains the certificate.
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.
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 filename 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.
Remove the certificate file from its temporary location on the operating system. For example:
```
rm /tmp/brhost2_cert.f
```
Enter the following command to reset the security policy:
```
obtool resetp security/autocertissue
```

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.

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 3072 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:

Setting the Key Size During Installation

The key size in the security policy can be set when you install Oracle Secure Backup on the administrative server. Oracle Secure Backup uses the key size specified at installation time 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.

The Oracle Secure Backup installer uses a default value for the key size. To modify this default value, you must configure advanced installation settings during installation.

See Also:

Setting the Key Size in the certkeysize Security Policy

You can change the default certificate key size security policy at any time. This change will not affect existing hosts. It will only affect new hosts added to the domain.

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:

Log in to obtool as a user with the modify administrative domain's configuration right.
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

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:

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

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.

See Also:

"Host Authentication and Communication"

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, 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

Managing Certificates with obcm

This section explains how to use the obcm utility. You can use this utility to renew certificates in either certification mode, import certificate chains, export certificate chains, and export certificate requests.

You must use obcm when you add hosts to the domain in manual rather than automated certificate provisioning mode. In this case, the Certification Authority (CA) does not issue a signed certificate chain to a host over the network, so you must export the signed certificate chain from the administrative server, manually transfer the certificate chain to the newly configured host, and then import the certificate chain 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.

In case of any errors, use the obcm verifycomm command to diagnose any connection issues in your domain and ensure that you describe the location of the obcm log file.

This section contains the following topics:

Renewing Certificates in Automated Certificate Provisioning Mode

This section lists the steps to renew the certification authority on your domain, in automated certificate provisioning mode.

From Oracle Secure Backup 12.1.0.2 and later, you can use obcm to renew certificates on your domain in automated certificate provisioning mode.

For more information on how to renew certificates in automated certificate provisioning mode, on Oracle Secure Backup 12.1.0.1 and 10.4 versions, see Renewing Certificates in Automated Certificate Provisioning Mode on Earlier Versions of Oracle Secure Backup

On the administrative host, complete the following steps to renew certification authority in automated certificate provisioning mode for your domain.

Enter the following command to temporarily disable your backup domain:
```
obtool ctldameon --command suspend
```
Enter the following command to list all active jobs in your domain:
```
obtool lsjobs --active
```
Once all active jobs have completed, enter the following command to regenerate the signing certificates:
```
obcm recertifydomain
```
Use the following command to identify existing unauthenticated hosts:
```
obtool lshost --unauthenticated
```
Complete the steps listed in Manually Authenticating Hosts to manually update unauthenticated hosts.
Verify that all hosts in your domain have been authenticated by repeating step 4.
Enter the following command to verify that you can successfully reach all hosts in your domain:
```
obtool --pinghost all
```
Resume all backup operations.
```
obtool ctldaemon --command resume
```

Renewing Certificates in Manual Certificate Provisioning Mode

This section lists the steps to renew certificates in manual certificate provisioning mode on OSB 12.1.0.2 and later.

Oracle Secure Backup 12.1.0.2 and later allow you to use obcm to renew certificates on your domain in manual certificate provisioning mode

For more information on renewing certification authority in manual certificate provisioning mode on Oracle Secure Backup 12.1.0.1 and 10.4 versions, see Renewing Certificates in Manual Certificate Provisioning Mode on Earlier Oracle Secure Backup Versions

On the administrative host, complete the following steps to renew certification authority in manual certificate provisioning mode for your domain.

Enter the following command to set the security policy to no:
```
obtool setp security/autocertissue --no
```
Enter the following command to temporarily disable your domain:
```
obtool ctldaemon --command suspend
```
Enter the following command to list all active jobs in your domain:
```
obtool lsjobs --active
```
Once all active jobs have completed, enter the following command to regenerate the signing certificate:
```
obcm recertifydomain
```

Enter the following command to export signed certificates for each non-administrative host:

obcm export --certificate --file non-admistrative hostname.cert --host non-administrative hostname

Make the non-administrative host.cert file accessible to the non-administrative host. Then, import the signed certificates on each unauthenticated host by using the following command:
```
obtool import --file non-administrative host.cert
```
Restart the non-administrative host so that it picks the renewed certificates.
Run the following command to verify that all hosts in the domain have been authenticated:
```
obtool lshost --unauthenticated
```
Verify that you can reach all hosts in your domain:
```
obtool pinghost --all
```
Enter the following command to resume all backup operations:
```
obtool ctldaemon --command resume
```
Enter the following command to reset the security policy:
```
obtool resetp security/autocertissue
```

Renewing Certificates in Automated Certificate Provisioning Mode on Earlier Versions of Oracle Secure Backup

This section lists the steps for certificate renewal in automated certificate provisioning mode for OSB 10.4.x and 12.1.0.1.

This section lists the steps to renew certification authority in automated certificate provisioning mode on Oracle Secure Backup 12.1.0.1 and 10.4 versions.

To regenerate signing certificates in automated certificate provisioning mode for your domain, complete the following steps:

Download the latest version of obcm.
For more information on obcm, see the Oracle Secure Backup Reference
Run the following command to temporarily disable the domain:
```
obtool ctldaemon --command suspend
```
Run the following command to list all active jobs in your domain:
```
obtool lsjobs --active
```
Once all active jobs have completed, remove expired signed certificates on each non-administrative host:
```
obcm decertify
```
On the administrative host, log in as the root user.
Enter the following command to regenerate the signing certificate:
```
obcm recertifydomain --nocomm --expire months
```
Stop and restart the observiced daemon.

See Also:

Oracle Secure Backup Reference for more information on observiced scripts
Run the following command to regenerate the signed certificates for each non-administrative host:
```
obtool updatehost --recertify non-administrative hostname
```
Repeat step 7 on each non-administrative host.
Resume all host operations:
```
obtool ctldaemon --command resume
```
Verify that all hosts can be reached:
```
obtool pinghost --all
```

Renewing Certificates in Manual Provisioning Mode on Earlier Versions of Oracle Secure Backup

This section lists the steps to renew certification authority in manual provisioning mode on Oracle Secure Backup 12.1.0.1 and 10.4 versions.

This section lists the steps to renew certification authority in manual certificate provisioning mode on Oracle Secure Backup 12.1.0.1 and 10.4 versions.

To regenerate signing certificates in manualcertificate provisioning mode for your domain, complete the following steps:

Download the latest version of obcm.
For more information on obcm, see the Oracle Secure Backup Reference
Run the following command to temporarily disable the domain:
```
obtool ctldaemon --command suspend
```
Run the following command to list all active jobs in your domain:
```
obtool lsjobs --active
```
Once all active jobs have completed, remove expired signed certificates on each non-administrative host:
```
obcm recertify
```
On each non-administrative host, run the following scripts to stop and start the observiced daemon:
```
/etc/init.d/obcerviced stop
/etc/init.d/observiced start
```
On the administrative host, log in as the root user.
Enter the following command to regenerate the signing certificate:
```
obcm recertifydomain --nocomm --expire months
```
Stop and restart the observiced daemon.

See Also:

Oracle Secure Backup Reference for more information on observiced scripts
Run the following command to regenerate the signed certificates for each non-administrative host:
```
obtool updatehost --recertify non-administrative hostname
```
Assign the certificates using the obcm export and obcm import commands.
For more information on exporting and importing certificates, see Exporting Signed Certificates and Importing Signed Certificates, respectively.
Resume all host operations:
```
obtool ctldaemon --command resume
```
Verify that all hosts can be reached:
```
obtool pinghost --all
```

Manually Authenticating Hosts After Certificate Renewal

This section describes how to authenticate unauthenticated, non-administrative hosts.

Ensure that you run the obcm recertifydomain command to renew certificates for your host.

To manually authenticate an unauthenticated, non-administrative hosts, complete the following steps:

On the unauthenticated host, remove all expired signed certificates by using the following command:
```
obcm decertify
```
On the administrative host, regenerate the signed certificates by using the following command:
```
obtool updatehost --recertify uncertified hostname
```
Assign the certificates by using the obcm export and obcm import commands.
For more information on exporting and importing certificates using obcm, see Exporting Signed Certificates and Importing Signed Certificates, respectively.

Exporting Signed Certificates

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

To export a signed certificate chain:

Log on to the administrative server.
Enter the following command, where hostname is the name of the host requesting the certificate and certificate_file is the filename of the exported request:
```
obcm export --certificate --file certificate_file --host hostname
```
For example, the following command exports the signed certificate chain for host brhost2 to file /tmp/brhost2_cert.f:
```
obcm export --certificate --file /tmp/brhost2_cert.f --host brhost2
```

Importing Signed Certificate Chains

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

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

Log in to the host whose wallet contains the certificate.
Copy the signed certificate chain to a temporary location on the file system.
Enter the following command, where signed_certificate_file is the filename of the certificate:
```
obcm 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:
```
obcm import --file /tmp/brhost2_cert.f
```
The obcm utility issues an error message if the certificate chain 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
```