| Oracle® Database Security Guide 10g Release 2 (10.2) Part Number B14266-02 |
|
|
View PDF |
| Oracle® Database Security Guide 10g Release 2 (10.2) Part Number B14266-02 |
|
|
View PDF |
Authentication means verifying the identity of someone (a user, device, or an entity) who wants to access 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 user name, you can authenticate users by using any combination of the methods described in the following sections:
| Authentication Considerations About ... | Links to Topics |
|---|---|
| Operating Systems | Authentication by the Operating System |
| Networks and LDAP Directories | Authentication by the Network |
| Databases | Authentication by Oracle Database |
| Multitier Systems | Multitier Authentication and Authorization |
| Secure Socket Layer Usage | Authentication of Database Administrators |
| Database Administrators | Authentication of Database Administrators |
See Also:
Chapter 10, "Administering Authentication", discusses how to configure and administer these authentication methods.
Chapter 16, "Preserving User Identity in Multitiered Environments", discusses proxy authentication.
Some operating systems permit Oracle to use information they maintain to authenticate users. This has the following benefits:
Once authenticated by the operating system, users can connect to Oracle more conveniently, without specifying a user name or password. For example, an operating-system-authenticated user can invoke SQL*Plus and skip the user name and password prompts by entering the following:
SQLPLUS /
With control over user authentication centralized in the operating system, Oracle need not store or manage user passwords, though it still maintains user names in the database.
Audit trails in the database and operating system can use the same user names.
When an operating system is used to authenticate database users, managing distributed database environments and database links requires special care.
See Also:
Oracle Database Administrator's Guide sections on (and index entries for) authentication, operating systems, distributed database concepts, and distributed data management
Operating system-specific documentation by Oracle for more information about authenticating by using your operating system
Authentication over a network is 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, and it is 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 over a network makes use of third-party network authentication services. Prominent examples include Kerberos, Public Key Infrastructure (PKI), the Remote Authentication Dial-In User Service (RADIUS), and directory-based services, as described in the following subsections.
If network authentication services are available to you, then Oracle can accept authentication from the network service. If you use a network authentication service, then some special considerations arise for network roles and database links.
Note:
To use a network authentication service with Oracle, you need Oracle Enterprise Edition with the Oracle Advanced Security option.See Also:
Oracle Database Administrator's Guide for more information about network authentication.
Oracle Database Advanced Security Administrator's Guide for information about Oracle Enterprise Edition with the Oracle Advanced Security option
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 Database Advanced Security Administrator's Guide for more information about Kerberos.Authentication systems based on PKI 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 PKI for using public keys and certificates, consisting of the following components:
Authentication and secure session key management using SSL.
Oracle Call Interface (OCI) and PL/SQL functions
These are used to sign user-specified data using a private key and certificate. The verification of the signature on data is done by using a trusted certificate.
Trusted certificates
These are used to identify third-party entities that are trusted as signers of user certificates when an identity is being validated. When the user certificate is being validated, the signer is checked by using trust points or a trusted certificate chain of certificate authorities stored in the validating system. If there are several levels of trusted certificates in this chain, then a trusted certificate at a lower level is simply trusted without needing to have all its higher-level certificates reverified.
These are data structures that contain the private key of a user, a user certificate, and the set of trust points of a user (trusted certificate authorities).
OracleAS Certificate Authority
This is a component of the Oracle Identity Management infrastructure, which provides an integrated solution for provisioning X.509 version 3 certificates for individuals, applications, and servers that require certificates for PKI-based operations such as authentication, SSL, S/MIME, and so on.
This is a standalone Java application used to manage and edit the security credentials in Oracle wallets. It performs the following operations:
Protects user keys
Manages X.509 version 3 certificates on Oracle clients and servers
Generates a public-private key pair and creates a certificate request for submission to a certificate authority
Installs a certificate for the entity
Configures trusted certificates for the entity
Creates wallets
Opens a wallet to enable access to PKI-based services
X.509 version 3 certificates obtained from (and signed by) a trusted entity, a certificate authority. Because the certificate authority is trusted, these certificates certify that the requesting entity's information is correct and that the public key on the certificate belongs to the identified entity. The certificate is loaded into an Oracle wallet to enable future authentication.
Oracle public key infrastructure is illustrated in Figure 4-1.
Figure 4-1 Oracle Public Key Infrastructure
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.
See Also:
Oracle Database Advanced Security Administrator's Guide for information about Oracle Advanced SecurityUsing a central directory can make authentication and its administration extremely efficient. Directory-based sevices include the following:
Oracle Internet Directory, which uses the Lightweight Directory Access Protocol (LDAP), enables information about users (called enterprise users) to be stored and managed centrally. Although database users must be created (with passwords) in each database that they need to access, enterprise user information is accessible centrally in the Oracle Internet Directory. You can also integrate this directory with Active Directory and iPlanet.
Oracle Internet Directory lets you manage the security attributes and privileges for users, including users authenticated by X.509 certificates. Oracle Internet Directory also enforces attribute-level access control. This feature enables read, write, or update privileges on specific attributes to be restricted to specific users, such as an enterprise security administrator. Directory queries and responses can use SSL encryption for enhanced protection during authentication and other interactions.
Oracle Enterprise Security Manager, which provides centralized privilege management to make administration easier and increase security levels. Oracle Enterprise Security Manager lets you store and retrieve roles from Oracle Internet Directory.
Oracle Database can authenticate users attempting to connect to a database, by using information stored in that database itself. To set up Oracle Database to use database authentication, you must create each user with an associated password. The user must provide this user name and password when attempting to establish a connection. This process prevents unauthorized use of the database, because the connection will be denied if the user provides an incorrect password. Oracle Database stores user passwords in the data dictionary in an encrypted format to prevent unauthorized alteration. Users can change their passwords at any time.
To identify the authentication protocols that are allowed by a client or a 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, which is the default. These values represent database server versions. Oracle recommends the value 10.
Database authentication includes the following features:
Password Encryption While Connecting. This protection is always in force, by default.
Passwords are always automatically and transparently encrypted during network (client/server and server/server) connections, using AES (Advanced Encryption Standard) before sending them across the network.
See Also:
For more information about encrypting passwords in network systems, refer to:Oracle can lock a user's account after a specified number of consecutive failed login 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 login attempts 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.
See Also:
"Profiles"Note:
Failed login attempts will be limited by default in future Oracle Database releases.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, then 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 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.
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:
For the complete syntax of the CREATE PROFILE command, see the Oracle Database SQL Reference .
For a more complete discussion of password history policies, see the Password History section in Chapter 7, "Security Policies"
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 (the PL/SQL script UTLPWDMG.SQL, which sets the default profile parameters) checks that each password meet the following requirements:
Be a minimum of four characters in length
Not equal the userid
Include at least one alphabet character, one numeric character, and one punctuation mark
Not match any word on an internal list of simple words like welcome, account, database, user, and so on
Differ from the previous password by at least three characters
See Also:
Discussion about 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 clients connecting to the middle tier must be preserved. One advantage of using 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, which allow 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, then 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 disabling it by setting the
remote_os_authentication parameter to FALSE.Authentication in a multitier environment is based on trust regions. Client authentication is the domain of the application server. The application server itself is authenticated by the database server. The following operations are performed:
The client provides proof of authenticity to the application server, typically, by using a password or an X.509 certificate.
The application server authenticates the client and then authenticates itself to the database server.
The database server authenticates the application server, verifies that the client exists, and verifies that the application server has the privilege to connect for this client.
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:
That the client has these roles by checking its internal role repository
That the application server has the privilege to connect on behalf of the user, and thus to use these roles as the user could
Figure 4-2 shows an example of multitier authentication.
Security for middle-tier applications must address the following key issues:
Accountability: The database server must be able to distinguish between the actions of a client and the actions an application takes on behalf of a client. It must be possible to audit both kinds of actions.
Differentiation: The database server must be able to distinguish between a client accessing the database directly and an application server acting either for itself or on behalf of a browser client.
Least privilege: Users and middle tiers should be given the fewest privileges necessary to perform their actions, to minimize the danger of inadvertent or malicious unauthorized activities.
Multitier authentication maintains the identity of the client through all tiers of the connection in order to maintain useful audit records. If the identity of the originating client is lost, then 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 by itself.
Privileges in a multitier environment must be limited to those necessary to perform the requested operation.
Client privileges must be 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 must also be limited, so that the application server cannot perform unwanted or unneeded operations while performing a client operation.
See Also:
Chapter 10, "Administering Authentication", and the Oracle Database Administrator's Guide, for more information about multitier authenticationDatabase 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 user names, 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.
Figure 4-3 Database Administrator Authentication Methods
Operating system authentication for a database administrator typically involves establishing a group on the operating system, assigning DBA privileges to that group, and then adding the names of persons who should have those privileges to that group.
Note:
On UNIX systems, the special group is called the dba group.The database uses password files to keep track of those database user names 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:
Your Oracle operating system-specific documentation for information about configuring operating system authentication of database administrators
Oracle Database Administrator's Guide for information on creation and maintenance of password files
Oracle Database 10g Release 2 (10.2) enhances password file based authentication by making it easier to use. The following enhancements have been made:
Password file based authentication is enabled by default. This means that the database is ready to use a password file for authenticating users that have SYSDBA or SYSOPER system privileges. Password file based authentication is activated as soon as you create a password file using the ORAPWD utility.
A password file containing users with SYSDBA or SYSOPER privileges can be shared between different databases. You can have a shared password file that contains users in addition to the SYS user.
Note:
In order to share a password file between different databases, theREMOTE_LOGIN_PASSWORDFILE parameter needs to be changed to SHARED in the init.ora file. The default value of this parameter is EXCLUSIVE. This is the recommended setting.