| 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 |
This chapter gives you a broad overview of the many types of tasks you must confront in order to build good security. Understanding the diverse categories of such tasks improves your likelihood of preventing security gaps. Such gaps, 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 here, 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 the important details necessary to their implementation are described.
Practical concerns must also be met: minimizing the costs of equipment, personnel, and training; minimizing delays and errors; and 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 shouldn't be easy to walk into your facility without a key or badge, or without being required to show identity or authorization. Controlling physical access is your first line of defense, 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. Of course, the security of these measures, too, depends on how alert and security conscious each of your staff is, but physical access control stops a variety of potential problems before they even get started.
Each organization must evaluate its own risks and budget. Elaborate measures may well 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 your facility's physical access control can add to your security. Make it hard to get in, hard to remain or leave unobserved or unidentified, hard to get at sensitive or secure areas inside, and hard not to leave a trace.
Your staff makes your organization work, well or poorly 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 they get careless, resentful, or larcenous, tight security loosens or disappears. Your other measures won't 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: 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 organization's data and products.
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". Further specific descriptions of database-related tasks and actions can be found throughout the Oracle documentation set.
Implementing the following ten recommendations provides the basis for a secure configuration:
Do a custom installation. Avoid installing options and products you don't need. Choose to install only those additional products and options, in addition to the database server, that you do clearly need. Or, if you choose to do a "typical" installation instead, improve your security after the installation processes finish, by deinstalling the options and products you don't need.
The 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.
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 username, maintaining accountability. If you only need access for database startup and shutdown, 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 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, a database administrator can simply unlock and activate that account with a new, meaningful password.
Security is most easily broken when a default database server user account still has a default password even after installation. Three steps fix this:
In any Oracle environment (production or test), assign strong, meaningful 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 remain in their default states. Similarly, for production environments, do not use default passwords for any administrative accounts, including SYSMAN and DBSNMP.
Lock and expire all default accounts after installation. If any such account is later activated, change its default password to a new meaningful password.
Apply basic password management rules, such as password length, history, and complexity, to all user passwords.
Require all users to 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.
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).
Three practices implement this principle:
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, and
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.
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, a minimally privileged user could access and execute packages otherwise inaccessible to him. The more powerful packages that may potentially be misused are listed in Chapter 7, "Security Policies".
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".
Authenticate clients properly.
Although remote authentication can be turned on (TRUE), your installation is more secure with it 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).
Four practices implement appropriate restrictions on operating system access:
(See Networking Security Checklists later in this chapter for appropriate practices.)
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 itself, 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:
http://otn.oracle.com/deploy/security/alerts.htm
Also check Oracle Worldwide Support Service's site, Metalink, for details on available and upcoming security-related patches:
http://metalink.oracle.com
If you believe that you have found a security vulnerability in Oracle Database, 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 create thoroughgoing protection. Using SSL (Secure Sockets Layer) 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 all these protections and minimize gaps or disclosures that threaten them. While the primary documentation for Oracle's SSL configuration and practices is Oracle Advanced Security Administrator's Guide, the following basic list illustrates the cautious attention to detail necessary for successful, secure use of SSL:
https://secure.server.dom:4445/server.key file, which requires that you enter your pass-phrase to read and parse this file. (A non-SSL-aware server does not require such a 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 server. Otherwise, anyone who gets this key can impersonate you on the net.
See Also:
|
Since authenticating client computers is problematic over the Internet, user authentication is typically done 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:
Using SSL (Secure Sockets Layer) communication makes eavesdropping unfruitful and enables the use of certificates for user and server authentication.
Because the listener acts as the database's gateway to the network, it is important to limit the consequences of malicious interference:
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 sepasrate listener process should not be the owner that installed Oracle or executes the Oracle instance (such as ORACLE, the default owner).
| See Also:
See the section A Security Checklist in Chapter 7, "Security Policies", for more specific details. |
Protecting the network and its traffic from inappropriate access or modification is the essence of network security. The following practices improve network security:
Appropriately placed and configured firewalls can prevent outsider access to your organization's intranet when you allow internal users to have Internet access.
For example, do not leave open Oracle Listener's 1521 port, allowing the database to connect to the Internet or the Internet to connect with the database. Such a hole introduces significant security vulnerabilities that hackers are likely to exploit. They can enable even more port openings through the firewall, create multi-threaded operating system server problems, and gain access to crucial information on databases behind the firewall. If the Listener is running without an established password, they 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.
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 respectively denied or allowed connections to the Oracle Listener. This action prevents potential Denial of Service attacks.
If possible, utilize Oracle Advanced Security to encrypt network traffic between clients, databases, and application servers. (Note that Oracle Advanced Security is available only with the Enterprise Edition of the Oracle database).
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 successful breach of security. Also monitor and audit to detect either increased threat levels or successful penetration.
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|