| Oracle® Database Security Guide 10g Release 1 (10.1) Part Number B10773-01 |
|
|
View PDF |
| Oracle® Database Security Guide 10g Release 1 (10.1) Part Number B10773-01 |
|
|
View PDF |
Authentication means verifying the identity of someone (a user, device, or other entity) who wants to use data, resources, or applications. Validating that identity establishes a trust relationship for further interactions. Authentication also enables accountability by making it possible to link access and actions to specific identities. After authentication, authorization processes can allow or limit the levels of access and action permitted to that entity, as described in Chapter 5, "Authorization: Privileges, Roles, Profiles, and Resource Limitations".
Oracle allows a single database instance to use any or all methods. Oracle requires special authentication procedures for database administrators, because they perform special database operations. Oracle also encrypts passwords during transmission to ensure the security of network authentication.
To validate the identity of database users and prevent unauthorized use of a database username, you can authenticate using any combination of the methods described in the following sections:
| Authentication Considerations About ... | Links to Topics |
|---|---|
|
Operating Systems |
|
|
Networks and LDAP Directories |
|
|
Databases |
|
|
Multitier Systems |
|
|
Secure Socket Layer Usage |
|
|
Database Administrators |
See Also:
|
Some operating systems permit Oracle to use information they maintain to authenticate users, with the following benefits:
SQLPLUS /
When an operating system is used to authenticate database users, managing distributed database environments and database links requires special care.
See Also:
|
Authentication capabilities at the network layer are handled by the SSL protocol or by third-party services, as described in the following subsections:
The Secure Socket Layer (SSL) protocol is an application layer protocol. It can be used for user authentication to a database, independent of global user management in Oracle Internet Directory. That is, users can use SSL to authenticate to the database even without a directory server in place.
Authentication at the network layer makes use of third-party network authentication services. Prominent examples include the Distributed Computing Environment (DCE), Kerberos, public key infrastructure, the Remote Authentication Dial-In User Service (RADIUS), and directory-based services, as described in subsequent subsections.
If network authentication services are available to you, Oracle can accept authentication from the network service. To use a network authentication service with Oracle, you need Oracle Enterprise Edition with the Oracle Advanced Security option.
See Also:
|
The Distributed Computing Environment (DCE) from the Open Group is a set of integrated network services that works across multiple systems to provide a distributed environment. The network services include remote procedure calls (RPCs), directory service, security service, threads, distributed file service, diskless support, and distributed time service.
DCE is the middleware between distributed applications and the operating system/network services and is based on a client/server model of computing. By using the services and tools that DCE provides, users can create, use, and maintain distributed applications that run across a heterogeneous environment.
Kerberos is a trusted third-party authentication system that relies on shared secrets. It presumes that the third party is secure, and provides single sign-on capabilities, centralized password storage, database link authentication, and enhanced PC security. It does this through a Kerberos authentication server, or through Cybersafe Active Trust, a commercial Kerberos-based authentication server.
| See Also:
Oracle Advanced Security Administrator's Guide for more information about DCE and Kerberos. |
Authentication systems based on public key infrastructure issue digital certificates to user clients, which use them to authenticate directly to servers in the enterprise without directly involving an authentication server. Oracle provides a public key infrastructure (PKI) for using public keys and certificates, consisting of the following components:
Oracle's public key infrastructure is illustrated in Figure 4-1.
Text description of the illustration cncpt136.gif
|
Note: To use public key infrastructure-based authentication with Oracle, you need Oracle Enterprise Edition with the Oracle Advanced Security option. |
Oracle supports remote authentication of users through the Remote Authentication Dial-In User Service (RADIUS), a standard lightweight protocol used for user authentication, authorization, and accounting.
|
Note: To use remote authentication of users through RADIUS with Oracle, you need Oracle Enterprise Edition with the Advanced Security option. |
| See Also:
Oracle Advanced Security Administrator's Guide for information about Oracle Advanced Security |
Using a central directory can make authentication and its administration extremely efficient.
Oracle Internet Directory, which uses the Lightweight Directory Access Protocol (LDAP), enables information about users (called enterprise users) to be stored and managed centrally. Whereas database users must be created (with passwords) in each database they need to access, enterprise user information is accessible centrally in the Oracle Internet Directory. This directory is readily integrated with Active Directory and iPlanet.
Oracle can authenticate users attempting to connect to a database, by using information stored in that database.
To set up Oracle to use database authentication, you create each user with an associated password that must be supplied when the user attempts to establish a connection. This process prevents unauthorized use of the database, since the connection will be denied if the user provides an incorrect password. Oracle stores a user's password in the data dictionary in an encrypted format to prevent unauthorized alteration, but a user can change his own password at any time.
To establish which authentication protocols are allowed by the client or database, a DBA can explicitly set the SQLNET.ALLOWED_LOGON_VERSION parameter in the server sqlnet.ora file. Then each connection attempt is tested, and if the client or server does not meet the minimum version specified by its partner, authentication fails with an ORA-28040 error. The parameter can take the values 10, 9, or 8, the default, representing database server versions. Oracle recommends the value 10.
Database authentication includes the following facilities:
Passwords are always automatically and transparently encrypted during network (client/server and server/server) connections, using a modified DES (Data Encryption Standard) or 3DES algorithm, before sending them across the network.
Oracle can lock a user's account after a specified number of consecutive failed log-in attempts. You can configure the account to unlock automatically after a specified time interval or to require database administrator intervention to be unlocked.
Use the CREATE PROFILE statement to establish how many failed logins a user can attempt before the account locks, and how long it remains locked before it unlocks automatically.
The database administrator can also lock accounts manually, so that they cannot unlock automatically but must be unlocked explicitly by the database administrator.
The database administrator can specify a lifetime for passwords, after which they expire and must be changed before account login is again permitted. A grace period can be established, during which each attempt to login to the database account receives a warning message to change the password. If it is not changed by the end of that period, the account is locked. No further logins to that account are allowed without assistance by the database administrator.
The database administrator can also set the password state to expired, causing the user's account status to change to expired. The user or the database administrator must then change the password before the user can log in to the database.
| See Also:
Password Management Policy in Chapter 7, "Security Policies" |
The password history option checks each newly specified password to ensure that a password is not reused for a specified amount of time or for a specified number of password changes. The database administrator can configure the rules for password reuse with CREATE PROFILE statements.
See Also:
|
Complexity verification checks that each password is complex enough to provide reasonable protection against intruders who try to break into the system by guessing passwords.
The sample Oracle password complexity verification routine (PL/SQL script UTLPWDMG.SQL, which sets the default profile parameters) checks that each password meet the following requirements:
| See Also:
Chapter 7's discussion of Password Complexity Verification,. |
In a multitier environment, Oracle controls the security of middle-tier applications by limiting their privileges, preserving client identities through all tiers, and auditing actions taken on behalf of clients. In applications that use a heavy middle tier, such as a transaction processing monitor, the identity of the client connecting to the middle tier must be preserved. Yet one advantage of a middle tier is connection pooling, which allows multiple users to access a data server without each of them needing a separate connection. In such environments, you need to be able to set up and break down connections very quickly.
For these environments, Oracle database administrators can use the Oracle Call Interface to create lightweight sessions, allowing database password authentication for each user. This method preserves the identity of the real user through the middle tier without the overhead of a separate database connection for each user.
You can create lightweight sessions with or without passwords. However, if a middle tier is outside or on a firewall, security is better when each lightweight session has its own password. For an internal application server, lightweight sessions without passwords might be appropriate.
Issues of administration and security in multitier environments are discussed in the following sections:
In a multitier environment, an application server provides data for clients and serves as an interface from them to one or more database servers. The application server can validate the credentials of a client, such as a web browser, and the database server can audit operations performed by the application server. These auditable operations include actions performed by the application server on behalf of clients, such as requests that information be displayed on the client. A request to connect to the database server is an example of an application server operation not related to a specific client.
|
Note: While client-side authentication is possible, Oracle strongly recommends disallowing it by setting the remote_os_authentication parameter to FALSE. |
Authentication in a multitier environment is based on trust regions. Client authentication is the province of the application server, which itself is authenticated by the database server. The following operations are performed:
Application servers can also enable roles for a client on whose behalf they connect. The application server can obtain these roles from a directory, which thus serves as an authorization repository. The application server can only request that these roles be enabled. The database verifies the following requirements:
Figure 4-2 shows an example of multitier authentication.
Text description of the illustration cncpt137.gif
Security for middle-tier applications must address the following key issues:
Multitier authentication maintains the identity of the client through all tiers of the connection in order to maintain useful audit records. If the originating client's identity is lost, specific accountability of that client is lost. It becomes impossible to distinguish operations performed by the application server on behalf of the client from those done by the application server for itself.
Privileges in a multitier environment are limited to those necessary to perform the requested operation.
Client privileges are as limited as possible in a multitier environment. Operations are performed on behalf of the client by the application server.
Application server privileges in a multitier environment are also limited, so that the application server cannot perform unwanted or unneeded operations while performing a client operation.
| See Also:
Chapter 9, "Administering Authentication", and the Oracle Database Administrator's Guide, for more information about multitier authentication |
Database administrators perform special operations (such as shutting down or starting up a database) that should not be performed by normal database users. Oracle provides for secure authentication of database administrator usernames, for which you can choose either operating system authentication or password files.
Figure 4-3 illustrates the choices you have for database administrator authentication schemes. Different choices apply to administering your database locally (on the machine where the database resides) and to administering many different database machines from a single remote client.
Text description of the illustration cncpt081.gif
Operating system authentication for a database administrator typically involves establishing a group on the operating system, assigning the DBA privileges to that group, and then adding to that group the names of persons who should have those privileges. (On UNIX systems, the special group is called the dba group.)
The database uses password files to keep track of those database usernames that have been granted the SYSDBA and SYSOPER privileges. These privileges enable the following operations and capabilities:
SYSOPER lets database administrators perform STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, and RECOVER. SYSOPER also includes the RESTRICTED SESSION privilege.SYSDBA has all system privileges with ADMIN OPTION, including the SYSOPER system privilege, and permits CREATE DATABASE and time-based recovery.
|
Note: Connections requested AS SYSDBA or AS SYSOPER must use these phrases; without them, the connection fails. The Oracle parameter 07_DICTIONARY_ACCESSIBILITY is set to FALSE by default, to limit sensitive data dictionary access only to those authorized. The parameter also enforces the required AS SYSDBA or AS SYSOPER syntax. See also Administrator Security in Chapter 7, "Security Policies" |
See Also:
|
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|