| 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 |
This chapter gives you a broad overview of the many types of tasks you must perform in order to build good security. Understanding the diverse categories of tasks improves your likelihood of preventing security vulnerabilities. Such vulnerabilities, whether exploited accidentally or intentionally, can undermine or overwhelm otherwise tight security that you have created in other areas.
Chapter 1 introduced the requirements for good security, the threats against it, and concepts that have proven useful in creating practical methods for developing and sustaining it.
The overview presented in this chapter identifies categories of tasks useful in meeting those requirements and threats. This chapter presents brief descriptions of these categories and tasks, with cross-references to Parts 2 and 3, where important details necessary to their implementation are described.
Good security requires physical access control, reliable personnel, trustworthy installation and configuration procedures, secure communications, and control of database operations such as selecting, viewing, updating, or deleting database records. Since some of these requirements involve applications or stored procedures as well as human action, security procedures must also account for how these programs are developed and dealt with.
The following practical concerns must also be met:
Minimizing the costs of equipment, personnel, and training
Minimizing delays and errors
Maximizing rapid and thorough accountability
Scalability, too, is an important and independent practical criterion that should be assessed for each proposed solution.
These, then, are the categories with which this overview is concerned. They are discussed in the following sections:
It should not be easy to walk into a facility without a key or badge, or without being required to show identity or authorization. Controlling physical access is your first line of defense, by protecting your data (and your staff) against the simplest of inadvertent or malicious intrusions and interferences.
Lack of such control can make it easier to observe, copy, or steal your other security controls, including internal keys, key codes, badge numbers or badges, and so on. The security of these measures also depends on how alert and security conscious each of your staff is, but physical access control stops a variety of potential problems.
Each organization must evaluate its own risks and budget. Elaborate measures may not be needed depending on many factors: company size, risk of loss, internal access controls, quantity and frequency of outside visitors, and so on. Preparing for accountability and recovery are additional considerations, possibly prompting alarms or video surveillance of entryways. The visibility of these preparations can also act as deterrence.
Improving physical access control to your facility can add to your security. Make it difficult to get in, difficult to remain or leave unobserved or unidentified, difficult to get at sensitive or secure areas inside, and difficult not to leave a trace.
Your staff makes your organization work well, depending on who they are and how they are managed. Your security is critically dependent on them: first, on how honest and trustworthy they are, and second, on how aware and alert they are to security concerns and considerations. The first issue is a matter of selection, interviewing, observation, and reference checking. Done well, these skills can prevent your hiring people who are (or are likely to become) inappropriate for tasks or environments that depend on establishing and maintaining security. To a very large degree, security depends on individuals. When personnel get careless, resentful, or larcenous, tight security loosens or disappears. Your other measures will not matter if they are carelessly or deliberately undermined or sabotaged.
The second issue is how aware and alert your staff is to security concerns and considerations. Such consciousness is only partly a matter of background, and the environment and training you provide are the most significant influences, given basic honesty and intent to cooperate. When an organization both shows and says that security is important, by establishing and enforcing security procedures and by providing training and bulletins about it, people learn and adapt. The result is better security and safety for them as well as for the data and products of an organization.
Information security, privacy, and protection of corporate assets and data are of critical importance to every business. For databases, establishing a secure configuration is a very strong first line of defense, using industry-standard best security practices for operational database deployments. The following list of such practices is deliberately general to remain brief. Additional details for each recommendation as it applies to Oracle Database appear in Chapter 7, "Security Policies".
Implementing the following recommendations provides the basis for a secure configuration:
Install only what is required.
Do a custom installation. Avoid installing options and products you do not need. Choose to install only those additional products and options, in addition to the database server, that you require. Or, if you choose to do a typical installation instead, then improve your security after the installation processes finish, by removing the options and products you do not need.
Lock and expire default user accounts.
Oracle Database installs with many default (preset) database server user accounts. Upon the successful creation of a database server instance, the Database Configuration Assistant automatically locks and expires most default database user accounts.
Note:
If you use Oracle Universal Installer or Database Configuration Assistant, then they will prompt for new
SYS and SYSTEM passwords, and will not accept the defaults "change_on_install" or "manager", respectively.Once the database is installed, lock SYS and SYSTEM as well, and use AS SYSDBA for administrator access. Specify administrative passwords individually.
This account (AS SYSDBA) tracks the operating system user name, maintaining accountability. If you only need access for database startup and shutdown, then use AS SYSOPER instead. SYSOPER has fewer administrative privileges than SYS, but enough to perform basic operations such as startup, shutdown, mount, backup, archive, and recover.
Database Configuration Assistant is not used during a manual installation, so all default database users remain unlocked and are able to gain unauthorized access to data or to disrupt database operations. Therefore, after a manual installation, use SQL to lock and expire all default database user accounts except SYS, SYSTEM, SCOTT, and DBSNMP. Do it to SCOTT, too, unless it is being actively used. Also lock SYS and SYSTEM as described earlier. If a locked account is later needed, then a database administrator can simply unlock and activate that account with a new password.
Change default user passwords.
Security is most easily broken when a default database server user account still has a default password even after installation. The following steps fix this:
Change the default passwords of administrative users immediately after installing the database server.
In any Oracle environment (production or test), assign strong, secure passwords to the SYS and SYSTEM user accounts immediately upon successful installation of the database server. Under no circumstances should the passwords for SYS and SYSTEM retain their default values. Similarly, for production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.
Change the default passwords of all users immediately after installation.
Lock and expire all default accounts after installation. If any such account is later activated, then change its default password to a new secure password.
Enforce password management.
Apply basic password management rules, such as password length, history, and complexity, to all user passwords.
Mandate that all users change their passwords regularly, such as every eight weeks.
If possible, use Oracle Advanced Security (an option to the Enterprise Edition of Oracle Database) with network authentication services (such as Kerberos), token cards, smart cards, or X.509 certificates. These services provide strong user authentication and enable better protection against unauthorized access.
Enable data dictionary protection.
Implement data dictionary protection to prevent users who have the ANY system privilege from using it on the data dictionary. Oracle Database sets the O7_DICTIONARY_ACCESSIBILITY to FALSE. This setting prevents using the ANY system privilege on the data dictionary, except for authorized users making DBA-privileged connections (for example CONNECT/AS SYSDBA).
Practice the principle of least privilege.
The following practices implement this principle:
Grant necessary privileges only.
Do not provide database users more privileges than necessary. Enable only those privileges actually required to perform necessary jobs efficiently:
1) Restrict the number of system and object privileges granted to database users.
2) Restrict the number of SYS-privileged connections to the database as much as possible. For example, there is generally no need to grant CREATE ANY TABLE to any non-DBA-privileged user.
Revoke unnecessary privileges and roles from the database server user group PUBLIC.
This default role, granted to every user in an Oracle database, enables unrestricted use of its privileges, such as EXECUTE on various PL/SQL packages. If unnecessary privileges and roles are not revoked from PUBLIC, then a minimally privileged user could access and execute packages otherwise inaccessible to him. The important packages that may potentially be misused are listed in Chapter 7, "Security Policies".
Restrict permissions on run-time facilities.
Do not assign all permissions to any database server run-time facility, such as the Oracle Java Virtual Machine (OJVM).
Instead, grant specific permissions to the explicit document root file paths for such facilities that may execute files and packages outside the database server. Examples are listed in Chapter 7, "Security Policies".
Enforce access controls effectively.
Authenticate clients properly. Although remote authentication can be turned on (TRUE), your installation is more secure with it turned off (FALSE, which is the default). With remote authentication turned on, the database implicitly trusts every client, because it assumes every client was authenticated by the remote authenticating system. However, clients in general (such as remote PCs) cannot be trusted to perform proper operating system authentication, so turning on this feature is a very poor security practice. To enforce proper server-based authentication of clients connecting to an Oracle database, leave or turn this feature off (remote_os_authentication=FALSE, which is the default).
Restrict operating system access.
The following practices implement appropriate restrictions on operating system access:
Limit the privileges of the operating system accounts (administrative, root-privileged, or DBA) on the Oracle Database host (computer) to the fewest and least powerful privileges required for each user.
Disallow modifying the default permissions for the Oracle Database home (installation) directory or its contents, even by privileged operating system users or the Oracle owner.
Restrict symbolic links. Ensure that when any path or file to the database is provided, neither that file nor any part of that path is modifiable by an untrusted user. The file and all components of the path should be owned by the DBA or some trusted account, such as root. This recommendation applies to all types of files, such as data files, log files, trace files, external tables, bfiles, and so on.
Restrict network access.
Details about restricting network access are provided in the Networking Security Checklists section.
Apply all security patches and workarounds.
Plug every security hole or flaw as soon as corrective action is identified. Always apply all relevant and current security patches for both the host operating system and Oracle Database, and for all installed Oracle Database options and components.
Periodically, check the security site on Oracle Technology Network for details on security alerts released by Oracle Corporation at
http://www.oracle.com/technology/deploy/security/alerts.htm
Also check the Oracle Worldwide Support Service site, Metalink, for details on available and upcoming security-related patches at
http://metalink.oracle.com
Contact Oracle security products.
If you believe that you have found a security vulnerability in Oracle Database, then submit an iTAR to Oracle Worldwide Support Services using Metalink, or e-mail a complete description of the problem, including product version and platform, together with any exploit scripts and examples, to the following address:
secalert_us@oracle.com
Security for network communications is improved by using client, listener, and network checklists to ensure thorough protection. Using SSL is an essential element in these lists, enabling top security for authentication and communications.
SSL is the Internet standard protocol for secure communication, providing mechanisms for data integrity and data encryption. These mechanisms can protect the messages sent and received by you or by applications and servers, supporting secure authentication, authorization, and messaging by means of certificates and, if necessary, encryption. Good security practices maximize protection and minimize gaps or disclosures that threaten security. While the primary documentation for Oracle SSL configuration and practices is Oracle Database Advanced Security Administrator's Guide, the following list illustrates the cautious attention to detail necessary for the successful use of SSL:
Ensure that configuration files (such as for clients and listeners) use the correct port for SSL, which is the port configured upon installation. You can run HTTPS on any port, but the standards specify port 443, where any HTTPS-compliant browser looks by default. Or the port can be specified in the URL, for example,
https://secure.server.com:4445/
If a firewall is in use, then it too must use the same port(s) for secure (SSL) communication.
Ensure that tcps is specified as the PROTOCOL in the ADDRESS parameter in the tnsnames.ora file (typically on the client or in the LDAP directory). An identical specification must appear in the listener.ora file (typically in the $ORACLE_HOME/network/admin directory).
Ensure that the SSL mode is consistent for both ends of every communication. For example, between the database on one side and the user or application on the other. The mode can specify either client or server authentication (one-way), both client and server authentication (two-way), or no authentication.
Ensure that the server supports the client cipher suites and the certificate key algorithm in use.
Do not remove the encryption from your RSA private key inside your server.key file, which requires that you enter your pass phrase to read and parse this file.
Note:
A non-SSL-aware server does not require such a pass phrase.However, if you were to decide your server is secure enough, you could remove the encryption from the RSA private key while preserving the original file. This would enable system boot scripts to start the server, because no pass phrase would be needed. However, be very sure that permissions on the server.key file allow only root or the Web server user to read it. Ideally, restrict permissions to root alone, and have the Web server start as root but run as another user. Otherwise, anyone who gets this key can impersonate you on the net.
See Also:
For general SSL information, including configuration, see the Oracle Database Advanced Security Administrator's Guide
For tcps information, see Oracle Database Net Services Administrator's Guide and Oracle Database Net Services Reference
Because authenticating client computers is problematic over the Internet, typically, user authentication is performed instead. This approach avoids client system issues that include falsified IP addresses, hacked operating systems or applications, and falsified or stolen client system identities. Nevertheless, the following steps improve the security of client connections:
Because the listener acts as the database gateway to the network, it is important to limit the consequences of malicious interference:
Restrict the privileges of the listener, so that it cannot read or write files in the database or the Oracle server address space.
This restriction prevents external procedure agents spawned by the listener (or procedures executed by such an agent) from inheriting the ability to do such reads or writes. The owner of this separate listener process should not be the owner that installed Oracle or executes the Oracle instance (such as ORACLE, the default owner).
Secure administration by doing the following:
Protect the listener with a password.
Prevent online administration.
Use SSL when administering the listener.
Remove the external procedure configuration from the listener.ora file if you do not intend to use such procedures.
See Also:
See the section A Security Checklist in Chapter 7, "Security Policies", for more specific details.Monitor listener activity.
Protecting the network and its traffic from inappropriate access or modification is the essence of network security. The following practices improve network security:
Restrict physical access to the network. Make it difficult to attach devices for listening to, interfering with, or creating communications.
Protect the network access points from unauthorized access. This goal includes protecting the network-related software on the computers, bridges, and routers used in communication.
Because you cannot protect physical addresses when transferring data over the Internet, use encryption when this data needs to be secure.
Appropriately placed and configured firewalls can prevent outsider access to your organization intranet when you allow internal users to have Internet access.
Keep the database server behind a firewall. The Oracle Database network infrastructure supports a variety of firewalls from various vendors. Examples are listed in Chapter 7, "Security Policies".
Ensure that the firewall is placed outside the network to be protected.
Configure the firewall to accept only those protocols, applications, or client/server sources that you know are safe.
Use a product like Oracle Connection Manager to multiplex multiple client network sessions through a single network connection to the database. It can filter on source, destination, and host name. This functionality enables you to ensure that connections are accepted only from physically secure terminals or from application Web servers with known IP addresses. (Filtering on IP address alone is not enough for authentication, because it can be faked.)
Never poke a hole through a firewall.
For example, do not leave the Oracle Listener port 1521 open, allowing the database to connect to the Internet or the Internet to connect with the database. This could introduce significant security vulnerabilities that hackers are likely to exploit. Hackers could enable even more port openings through the firewall, create multithreaded operating system server problems, and enable access to crucial information on databases behind the firewall. If the Listener is running without a password, then hackers can probe for critical details about the databases on which it is listening. These details include trace and logging information, banner information, and database descriptors and service names, enabling malicious and damaging attacks on the target databases.
Prevent unauthorized administration of the Oracle Listener.
Always establish a meaningful, well-formed password for the Oracle Listener, to prevent remote configuration of the Oracle Listener. Further, prevent unauthorized administration of the Oracle Listener, as described in Chapter 7, "Security Policies".
Use the Oracle Net valid node checking security feature to allow or deny access to Oracle server processes from network clients with specified IP addresses. Set parameters in the protocol.ora file (Oracle Net configuration file) to specify client IP addresses that are denied or allowed connections to the Oracle Listener. This action prevents potential Denial of Service attacks.
Encrypt network traffic.
If possible, utilize Oracle Advanced Security to encrypt network traffic between clients, databases, and application servers.
Note:
Oracle Advanced Security is available only with the Enterprise Edition of Oracle Database.Harden the host operating system (the system on which Oracle Database resides).
Disable all unnecessary operating system services. Many UNIX and Windows services are not necessary for most deployments. Such services include FTP, TFTP, TELNET, and so forth.
For each disabled service, be sure to close both the UDP and TCP ports. Leaving either type of port enabled leaves the operating system vulnerable.
In summary, consider all paths the data travels and assess the threats that impinge on each path and node. Then, take steps to lessen or eliminate those threats and the consequences of a breach of security. In addition, monitor and audit to detect either increased threat levels or successful penetration.
