Database Security: Beyond Password

Recently, public and corporate awareness of private and private information protection has been significantly enhanced. With specific regulations introduced by many countries and regions, protecting personal information is not only a matter of public relations, but also a legal obligation.

In any case, protecting confidential data in the IT system (whether in the transaction processing (OLTP) or in the data warehouse environment) is the primary consideration of enterprise operations. For example, can you imagine a sales system that does not store the customer name, address, and credit card number in the database? Private Data is the strategic asset of the current system. Therefore, the company should adopt a positive and robust comprehensive approach to protect confidential data through security policy implementation. From this perspective, the organization's strategic and tactical decisions must be ultimately result-oriented, rather than focusing on specific projects or current business needs, this avoids the high cost or even the loss of customers caused by redesign.

Many complex measures are usually used to block unauthorized access at the network and operating system level and integrate them into non-customized or customized application systems. However, databases that actually store information often only use the standard username/password mechanism for protection. Oracle Database 10 Gb is the best implementation for this mechanism. Even so, if the password leaks, the protection will no longer exist. Oracle databases can provide more protection through Oracle Virtual Private Database, Oracle tag Security, and other mechanisms, but these mechanisms are not fully applied in actual production.

In this technical article, I will introduce (and demonstrate) how to implement security mechanisms when one or more database passwords have been leaked. This method provides a simple method to combine the security features of Oracle Database 10g 1st (Oracle9i includes some of these features ), this allows intruders to achieve high-level protection even if a database connection is established. The main purpose is to avoid the destruction of confidential data by unauthorized users (whether the user is a foreign hacker or a database administrator within the company. The provided examples are dedicated to the transaction environment, but the principles can also be applied to business intelligence and data warehouse environments.

Database security goals

Oracle Database is an important component of actual security implementation. Generally, servers running the Oracle database engine are well protected by the firewall, but this does not eliminate the possibility of unauthorized access attempts (including internal employee access attempts. In addition to the traditional user name/password method, the Oracle database engine also provides its own security mechanism to protect its data even if it passes all other security barriers. The security measures identified in the following sections assume that the intrusion has penetrated to the database level. These measures will be used as the last line of defense for the database itself, but they cannot be used to replace external protection.

If all other security measures have been bypassed and unauthorized database access has started, the solutions defined in the following sections are used to build Database defense features to ensure:

The Oracle Application Server (as the database security client) can read, insert, and update all data as needed. The Oracle Application Server uses its internal security mechanism and application-specific security mechanism to ensure that private data is not infiltrated by unauthorized users in the presentation layer.

SQL * Plus allows you to access a secure database during error resolution, including viewing confidential information.

Other databases cannot access private client information.

Demo Installation

This exercise contains a typical sales data model. The data to be protected is stored in the CUSTOMER database, specifically in the CARD_NO column. In this example, the entire table is displayed as null for unauthorized requests, so SELECT * from CUSTOMER; no records can be retrieved. A table that does not seem to contain any records on the surface will not attract the attention of intruders (they think the former may be fundamental) than a table that contains records but hides or shields "interesting" columns. not used ).

However, after DBMS_RLS.ADD_POLICY is called, this solution hides (displayed as NULL) or shields (displayed as ***) the value of CARD_NO in the protected column, but the record that shows the values of other columns. You can specify the sec_relevant_cols and sec_relevant_cols_opt parameters in DBMS_RLS.ADD_POLICY. The initial_setup. SQL script in the support file in this article creates a very basic CUSTOMER table, which serves as an example in this process.

It is best to avoid using the mode owner identity to access data. Instead, it should be a different account (such as mongovr), which is shared by all clients and processed by the Oracle Application Server. The AppSvr database user does not have any objects and only has the create session system permission, but has the permission to all owners of the include mode (such as owners of the SHIP2004 mode) SELECT, INSERT, UPDATE, and DELETE permissions for tables of application data.

Supports the enable_connection. SQL script in the file to create a user (as described above) that is usually used by applications running on the Oracle Application Server ).

Security Implementation

To achieve the security goals described above, unless you "authorize" the connection (enabled by the Oracle Application Server running at the specified IP address ), we will use a database policy to hide records in the CUSTOMER table ,. This policy is implemented by security manager users (such as Sec_Manager), so it is not visible even in SHIP2004 or trusted VR mode.

Determining the environment variables to be used and the specific values to be checked by security predicates is a problem. A large number of potential combinations and special website details will create significant intrusion attempts.

It is advisable to create a separate mode (such as Sec_Manager) without any permissions (or even CONNECT) for all definitions used in security implementation as placeholders. All objects will be created by the database administrator account in Sec_Manager mode. Because you do not have permissions, this user name cannot even be used to log on to the database. Therefore, the security definition is reliably protected. (No one can even see the definition of security-related objects .)

However, one of the initial objectives of this article is to implement SQL * Plus-level access for several maintenance and support personnel members. This emergency access requires a "Secure Channel" that can be easily remembered by authorized users, but it cannot be written to the desktop instant stickers because it is too long (visible to anyone ), this is caused by the number of reserved passwords. This example uses the CLIENT_IDENTIFIER environment variable, but it can be a combination of any environment variables or environment variables you choose.

The create_setup. SQL script (in the support file) demonstrates how to create a security implementation mode, predicate function, and security policy based on the preceding description. It also generates several data lists and uses different database logon permissions to demonstrate different connections that will be seen (or invisible) in the CUSTOMER table. It also demonstrates how to use the dbms_session.set_identifier function to decrypt and access data through SQL * Plus connections.

Direct SQL * Plus access

Since the Oracle Application Server has robust built-in security features (used for authentication and authorization requests), direct SQL * Plus access is a common entry point for intruders. After implementing the security policy described above, you will have the following features:

Even if the ghost VR password has been damaged and someone uses ghost VR to log on to SQL * Plus for unauthorized access, the CUSTOMER data is not displayed, this is because the IP address and/or external session name are not as expected by the Security Predicate-the system does not even display any records in the protected table.

Online applications will not log on using the mode owner account. It will only be used for maintenance purposes, so it will strictly control the number of people it issues. In addition, they must correctly complete one or more environment settings (CLIENT_IDENTIFIER in this example) to view CUSTOMER data. Even if the password is damaged (for example, when someone finds the instant sticker on the desktop), as long as the backdoor settings hidden in the security predicate are not leaked, the protected table will also be blank for unauthorized users accessing it. Since intruders do not even know that the table has data, it is impossible to study it further.

No other database users (or even users with database administrator permissions) can see the records in the protected table. However, even if other database users obtain the SHIP2004 table access permission in some way, the preceding considerations are still valid. (You must understand the security features to see private data .)

The data list in the sample script demonstrates the content described above.

Encrypt data and packages

Data Encryption of CARD_NO ensures that a layer of data protection is added for confidential data. You can use the static key defined in the external process or the static key stored in the column of the database for encryption. A more desirable method is to divide the encryption component (key and function) into two separate servers, to increase the complexity of the environment and the workload required by potential intruders to retrieve all required information to decrypt protected data.

If a key is defined in an application, the attacker must not only access the database server, but also access the application server to obtain the key for data decryption. Even if a person breaks the access protection described in the preceding sections, he must still crack the package code (encoding according to the description in the following section "Protect the security environment) in order to know the encryption function applied. Attackers must also crack compiled application code on the application server to identify the keys used. If the key is not stored in any plaintext file (such as a parameter file or source code), it is only stored in the compiled version, the skill and difficulty required to retrieve the actually encrypted data through unauthorized access will increase accordingly.

However, to be independent from applications, other columns can be used as encryption keys in the example demonstrated in files. The value stored in the key column must be static because if this value is changed, the CARD_NO data cannot be decrypted. In this example, we select the CREATED_BY column for this key because it will not be updated after the record is created.

The most convenient solution to minimize the extra work required for encryption is to create a package that will be used to fundamentally hide calls to Oracle's encryption utility. Developers only need to generate a function call instead of directly using protected columns. This is a small inconvenience caused by security assurance. This example uses the ENCRYPT and DECRYPT functions in the DBMS_CRYPTO package. This package provides many encryption methods (for more information, see the Oracle documentation ). A large number of options (for the selected key) increase the complexity of attacking the solution provided, especially after packaging the source code of the customized package as described below. (The create_packages. SQL script provides sample settings for the encryption/decryption functions described in this article .)

Oracle Database 10g 2nd provides on-demand transparent data encryption, allowing you to transparently encrypt any common database column (date, String, number) it is automatically decrypted when the user passes the necessary access control check. The Oracle engine itself (not controlled by database users) can process encryption keys. Therefore, you do not have to manage these keys for table applications or SQL access. Through expansion, the database administrator can manage tables but cannot see the actual data values, which solves some of the problems involved in the above settings.

Operation of encrypted data

O