Networked systems are at greater risk than closed systems and require even greater attention to security issues. This chapter covers database security issues in a distributed system. The following topics are covered:
- Oracle Secure Network Services
For more detailed information on how network security is implemented using authentication services such as Kerberos (V5), see Secure Network Services Administrator's Guide, Understanding SQL*Net and the Oracle7 Server Administrator's Guide. See the Oracle Network Manager Administrator's Guide for information on configuring Secure Network Services' encryption and authentication services.
- security through authentication methods
Some Terms Related to Network Security
Below are brief descriptions of some terms related to network security.
The process by which a client is identified and authenticated by something other than an Oracle username and password. For example, a user can be authenticated by the operating system or by a network authentication service such as Cybersafe Challenger or Kerberos.
Operating-system authorized login or OPS$ login
A term formerly used to refer to the process by which a user's identity is authenticated by the operating system (same as operating system authentication). The client passes its operating system user name to the server. The server then verifies that the user has an operating-system account by calling the operating system.
Used by the server to impersonate the client in performing an operation for the client. Proxy logins are performed for database links, or server-to-server connections. Data is only as secure as the underlying protocol can provide. Security will vary depending on the underlying protocol in use, and network topology.
Privileges and roles
They control the access a user has to database functions and the schema objects within the database.
For more information, see Understanding SQL*Net, and the Oracle7 Server Administrator's Guide.
Introduction to Network Security
The network security provided in Secure Network Services version 2.0 and Oracle7 Server release 7.2 and higher extended the Oracle7 Server's current operating system authentication mechanisms to include network authentication services. Like the Oracle Protocol Adapters, authentication adapters are designed for a specific service, such as Kerberos, Cybersafe Challenger and SecureID Smart Cards. A site has a choice of which ones to link into their SQL*Net configuration.
Note: Authentication adapters are a part of Secure Network Services version 2.0. Availability of specific adapters will be tied to the release of Secure Network Services, which is scheduled for phased introduction throughout the lifetime of
SQL*Net release 2.2.
The major features related to network security in Oracle7 Server
release 7.2 and Secure Network Services version 2.0 are:
- Secure external authentication. For connections made using authentication services, the database will trust the authentication service for authorization.
Note: The following feature will be supported in a future release of Secure Network Services.
- Network roles. The database recognizes roles granted by network services, similar to the way operating system roles are recognized (where supported by the underlying authentication system).
New security features in release 7.2 are described in more detail below. See Understanding SQL*Net and Secure Network Services Administrator's Guide for more information on network security in release 7.2.
- Secure database links. Any user who is authenticated by a network service that supports proxy logins will be authenticated using that service when calling a remote database using an anonymous database link.
In addition to authenticating the identity of the user when a connection to a database is established, SQL*Net also provides the ability to accept or refuse connections on the basis of the system from which a client application is connecting. Using a pre-configured table, SQL*Net validates a connection request and determines whether the source system has the right to establish connections to the server.
This feature, called "valid node", can be administered with inclusive or exclusive authority, allowing you to explicitly list the systems from which you will and will not allow valid connections.
Valid node must be configured in PROTOCOL.ORA manually--it cannot be configured with Network Manager. Refer Understanding SQL*Net for information on the valid node feature.
Attention: Use the valid node feature with caution, as it only provides the degree of assurance that the underlying protocol provides about who is on the other side of the connection.
Password Protection and Encryption
All SQL*Net components can be protected from startup and shutdown using a password mechanism. Password protection provides additional security beyond normal connection establishment security and prevents malicious tampering with the network infrastructure. In addition, SQL*Net protects all passwords used in client applications during login by encrypting them when they are sent across the network. Password encryption, unique among database vendors, prevents passwords from being compromised by network tracing tools. For more information about password security, see the Oracle7 Server Administrator's Guide.
Oracle Secure Network Services
Secure Network Services, an optional product, allows customers to protect the valuable data travelling across their networks from eavesdropping and data modification by unauthorized third parties. System architects are free to build sophisticated, distributed networks of Oracle7 databases without having to worry about the security of their data as it fans out across the globe. Even connections to third-party data repositories can be encrypted with Secure Network Services.
Unlike many competing products, the Oracle client library encrypts login passwords before they are transmitted across the network. This makes Oracle client-server applications more secure than most traditional host-based systems that used insecure terminal emulation protocols such as TELNET for PC-to-server communication. In addition, Oracle's sophisticated network authentication architecture allows for the installation of Oracle Authentication Adapters that enable Oracle to take advantage of sophisticated network security systems such as Kerberos, Cybersafe Challenger and SecureID Smart Cards, and biometric identification devices.
Secure Network Services Ensures Tamper-Proof Data
To detect modification or replay of data during transmission, the optional Secure Network Services can generate a cryptographically secure message digest and include it with each SQL*Net packet sent across the network. Upon reception at the destination, an integrity check is immediately performed on each packet.
This makes it virtually impossible for an intruder to alter data or commands without detection, and ensures that any attempt to do so is immediately reported to the user and written to the system log files.
Secure Network Services Provides High-Speed Global Data Encryption
To protect data from unauthorized viewing, the optional Secure Network Services includes an encryption module that uses the RSA Data Security RC4(tm) encryption algorithm. Using a secret, randomly-generated 40-bit key for every SQL*Net session, all user network traffic is fully safeguarded, including all data values, SQL statements, and stored procedure calls and results.
Use of the encryption module can be requested or required by either the client, the server, or both for guaranteed data protection. Oracle's highly optimized implementation provides a high degree of security for an almost imperceptible performance penalty. Since Secure Network Services Version 1.0 meets the new U.S. government export guidelines for encryption products, it is available in all but a few countries, allowing most companies to safeguard their entire worldwide operations with this software. Version 1.1 also includes DES encryption for domestic users, with crypto-algorithm negotiation between client and server at connect time.
Secure Network Services is fully supported by the Oracle MultiProtocol Interchange, making secure data transfer a reality across network protocol boundaries. Clients using LAN protocols, such as NetWare (SPX/IPX), can now securely share data with large servers using different network protocols like LU6.2, TCP/IP, or DECnet. To eliminate potential weak points in the network infrastructure and to maximize performance, Interchanges pass encrypted data from protocol to protocol without the cost and exposure of decryption and re-encryption.
Functionally, gateway security is identical to that of an Oracle7 Server, as described in Oracle7 Server Concepts. For SQL-based transparent gateways, Oracle7 database security is mapped to the native data dictionary of the data source. For file-based transparent gateways, the Transparent Gateway Utility is used to administer gateway users, roles, privileges, tables, and views.
Authentication Services Provide Enhanced Security
In Secure Network Services version 2.0, it will be possible to use network authentication services to authenticate connections to the database. An authentication service is usually part of a network operating system (NOS) that overlays several machines. The purpose of authentication services is to provide enhanced security in a distributed environment with network authentication.
Network administration of machines can be centralized by creating a group of network users that have the same identity and privileges, verified by authentication services.
Secure External Authentication
Users need to use a slash (/) to indicate the lack of a username when requesting external authentication. If an authentication adapter is available (installed and linked into the SQL*Net configuration), then the server will use it to find the user's network identity. Alternatively, leave the username and password fields in the pop-up login box of an application (such as SQL*Plus) empty.
SVRMGR> CONNECT /@ny
Following are some important points related to secure
- The connection fails and an error is returned if the user does not have a valid externally-authenticated database account.
- It is recommended that you do not set REMOTE_OS_AUTHENT=TRUE initialization parameter because this exposes the database to certain security risks.
Note: The REMOTE_OS_AUTHENT parameter only applies to operating system authentication, not to NOS authentication.
- Set REMOTE_OS_AUTHENT to TRUE only when migrating from a non-secure connection to an authentication service (that is, where some users still need to connect to this database based on the operating system authentication of their host client system.
Using the network identity from the authentication service, the Oracle7 Server can provide secure external authentication over a non-secure protocol such as TCP/IP.
There is no change in connection syntax from Oracle7 Release 7.1.
Whether or not an authentication is available in Network Manager, the operating system username is retrieved by prepending the OS_AUTHENT_PREFIX for Oracle7. If the account exists, then login succeeds. If the connection is not secure, then the value of REMOTE_OS_AUTHENT checks if access should be granted.
Proxy Authentication for Remote Login
Proxy authentication provides the client with a credential or token that identifies a user with valid network access by proxy authentication. See Figure 6 - 1 for an illustration of proxy authentication.
Proxy authentication enables a database link to inherit the security credentials established in the initial login.
Following are some important points related to proxy authentication:
- Proxy authentication is not supported by all network authentication services.
- Proxy authentication is used when an externally authenticated user attempts to use an anonymous database link.
- Secure database links also do not require any change in syntax from Oracle7 Server Release 7.1. Proxy authentication offers a secure and authenticated login, whereas operating system authentication will fail if no authentication service is available and REMOTE_OS_AUTHENT is not set to TRUE.
Figure 6 - 1. Proxy Authentication for Remote Login
Authorization Using Network Roles
Network roles, verified by the authentication service, allow users valid network-wide access to database objects.
Use the global database name to specify roles that are valid on the various databases in the network, instead of using the SID as operating system roles do.
Defining Oracle Network Roles
Some authentication services, such as DCE, use the following syntax to define Oracle Network roles. For example, using DCE syntax:
"ORA_" indicates that this token applies to Oracle products.
<global_db_name>: specifies the database on which the token is valid.
The example shows how the literal constant "global" can be used as a valid token on all databases served by this authentication service.
[A]: represents the administrative capability for this role.
[D]: indicates this role is active by default.
- Network roles are obtained from the network and not the operating system.
- The global database name consists of the local database name and the domain name.
For example, the global database name HR.US.ACME.COM consists of the database name HR and the domain name US.ACME.COM. It must be unique within the enterprise.
The consequences of having two databases with the same network role is that the same role could be accessed on two different databases.
- The database reads all the user's network roles at connection time. Therefore, if the network administrator revokes a role from a user then this is not reflected until the user reconnects to the database.
Authentication Through Network Privileges
Authentication through network privileges alleviates the need to maintain a password file by providing network privileges that map to the operating system privileges (SYSDBA and SYSOPER). The DBA or network administrator can make remote administration over a non-secure connection possible by using network privileges. See Figure 6 - 2 for an illustration of authentication through
How a Remote User is Authenticated through Network Privileges
The benefit of authentication through network privileges is that it removes the need to maintain a password file by providing network privileges that map to the operating system privileges (SYSDBA and SYSOPER). This makes secure remote administration possible over a non-secure network connection.
Figure 6 - 2. Authentication Through Network Privileges
If a remote user tries to connect to a local database through a non-secure connection, the local database checks whether it should use network authentication (by checking the appropriate parameters). If the parameters indicate that network authentication should be used, then the database attempts to authenticate the user by looking for SYSDBA/SYSOPER authentication.
If a remote user tries to connect over a secure connection by using a password, the password is verified using the authentication service first. If that fails, the database performs the verification.
Following are some points related to authentication through
- Some authentication adapters implement network privileges in the same manner that operating systems implement the SYSOPER and SYSDBA roles.
ORA_<global db name>_[DBA|OPER]_SYS
This naming convention eases administration of multi-
Note: The method of naming network privileges can vary, depending on the authentication adapter. The previous example is the naming method for DCE authentication.
For successful internal connections, the database instance should be up and running. Otherwise, the database name cannot be read from the control file.
- Use the global database name to request internal connections.
The following points relate to authentication through
- To verify initial connection, the name defined in the CONNECT_DATA string is used to fetch the proper privileges when the instance is down.
- Because the connect descriptor is clear text and can be changed, the Oracle startup code performs a consistency check and does not allow the connection to pass through if a match is not found.
Database Security in a Distributed System
Because a distributed system allows many users to access the same data, you will need some method of limiting access to certain types of data. For example, you would want employee salaries to be available only to those authorized to see them. You may also have multiple databases in your system and will need to control who, specifically, has access to the database as a whole.
Oracle allows you to limit user access on several levels through:
User authentication can be performed by identifying the user with a username/password registered with the database, by operating system authentication of the user's identity, or by network authentication.
Warning: In a distributed system, operating system authentication of the user's identity is very susceptible to security breach. Therefore, even though operating system authentication can be performed, it is strongly discouraged.
Privileges and Roles
Privileges control what a user can and cannot access or do while attached to a database. Privileges grant the right to a user to execute a particular type of SQL statement or the right to access another user's object. Oracle has two types of privileges: system privileges and object privileges.
Privileges are also defined by who they will be assigned to: the DBA or the user. For example, some DBA privileges might be:
Roles provide a way of assigning a predetermined group of privileges to users. A role groups several privileges so that they can be simultaneously granted to or revoked from users.
See the Oracle7 Server Administrator's Guide for a full explanation of privileges and roles and how they are created, altered, enabled, disabled, and dropped.
Additional Information: Server Manager can greatly simplify creating roles. See the Oracle Server Manager User's Guide for more information.
There are approximately 80 different system privileges. So, in a large distributed system, it may be necessary to divide DBA responsibilities among several people. Such a division also limits potential security problems if a single DBA's account is compromised.
This can be accomplished by creating specialized DBA roles for, for example, backups, IMPORT/EXPORT, security, and so on.
The roles listed in Table 6 - 1 are automatically defined for Oracle databases. These roles are provided for backward compatibility to earlier versions of Oracle. You can grant and revoke privileges and roles to these predefined roles, as you can to any role you define.
Table 6 - 1. DBA Roles and their Privileges
||Privileges Granted To Role
||ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW
||CREATE CLUSTER, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER
||All system privileges WITH ADMIN OPTION
||SELECT ANY TABLE, BACKUP ANY TABLE, INSERT, DELETE, AND UPDATE ON THE TABLES SYS.INCVID, SYS.INCFIL, AND SYS.INCEXP
||BECOME USER, WRITEDOWN6
1 created by SQL.BSQ
2 grantees of the RESOURCE role also receive the UNLIMITED TABLESPACE system privilege as an explicitly grant (not as part of the RESOURCE role)
3 grantees of the DBA role also receive the UNLIMITED TABLESPACE system privilege with the ADMIN OPTION as an explicit grant (not as part of the DBA role). Therefore when the DBA role is revoked, any explicit grant of UNLIMITED TABLESPACE is also revoked.
4 also includes the EXP_FULL_DATABASE and IMP_FULL_DATABASE roles if CATEXP.SQL has been run
5 created by CATEXP.SQL
6 a Trusted ORACLE privilege only; see the Trusted ORACLE7 Server Administrator's Guide