Distributed Databases   «Prev  Next»

Lesson 9 Snapshot security
Objective Implement snapshot security.

Implement Snapshot Security (Administration)

One of the ongoing problems with Oracle snapshot is administration security. Prior to Oracle 8, you were required to use the same administrator on the master and all snapshot nodes. This meant that if security were breached on one database node, all nodes were in jeopardy. Oracle continues to support this technique (called trusted[1] snapshot security), but also provides a method (called untrusted[2] snapshot security) that allows individual nodes to have their own administrators.

Implementing Snapshot Security

Oracle provides two methods for implementing snapshot security: the Replication Manager and the replication management API. In either method, you use the following steps to implement snapshot security:
  1. Establish replication management accounts on each remote server. Oracle user IDs are added at each remote server with appropriate GRANT statements.
  2. Define database links from each remote database to the master site.
  3. Grant the appropriate privileges depending on the type of DBA function.

There are three user functions in administering snapshot replication, and they must have the following privileges:

Function Privileges required
Replication administrator DBMS_REPCAT_ADMIN.
GRANT_ADMIN_ANY_SCHEMA
Propagator user DBMS_DEFER_SYS.
REGISTER_PROPAGATOR
Refresher CREATE ANY SNAPSHOT
ALTER ANY SNAPSHOT

After defining the users and their privileges, you are ready to implement the security for your snapshots. Oracle provides two snapshot security models: trusted and untrusted.

Trusted Snapshot Security

In a trusted environment, the snapshot administrator has access to all snapshots, both at the master sites as well as the remote sites. Using trusted security greatly simplifies administration of snapshots; the DBA can perform snapshot administration functions on a remote site and the changes will be propagated back to the master site and all other remote sites. The downside to using a trusted environment is that a hacker might breach security at a remote site and gain access to the master site, where he or she could corrupt your data.

Untrusted snapshot security

With untrusted security, the administration security is partitioned to the master site and each remote site. At the master site, the snapshot administrator and propagator only have access to their master snapshot groups. At each remote site, the remote snapshot administrator and the propagator can only access the snapshots at the remote site.
In practice, most snapshot administrators use the trusted model since the threat of data corruption can always be corrected by a restore and roll-forward of any corrupted snapshot. However, for sites where the contents of the replicated material is sensitive, the untrusted model is preferred.
Oracle's new Replication Manager setup wizard will implement snapshot security, but the GUI tool still has some bugs in this early release. Most DBA's utilize the native replication management API commands. Next, let us take a look at the process for deploying full-snapshot replication using the Oracle export utility, called instantiating snapshot sites offline.

Replication Concepts - Quiz


Click the Quiz link below to test your understanding of replication concepts.
Replication Concepts - Quiz
[1]Trusted: A security model in which an administrator has access privileges to local and remote sites.
[2] Untrusted: A security model in which an administrator has access privileges only to the local site.
Distributed Databases