1. Trang chủ
  2. » Công Nghệ Thông Tin

Applied Oracle Security: Developing Secure Database and Middleware Environments- P36 docx

10 221 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Cấu trúc

  • Applied Oracle Security: Developing SecureDatabase and MiddlewareEnvironments

    • Contents

    • Foreword

    • Acknowledgments

    • Part I: Oracle Database Security New Features

      • 1 Security Blueprints and New Thinking

        • About This Book

        • Database Security Today

        • Security Motivators

        • Modeling Secure Schemas

        • Getting Started

        • Summary

      • 2 Transparent Data Encryption

        • Encryption 101

        • Encrypting Data Stored in the Database

        • The Transparent Data Encryption Solution

        • Tablespace Encryption: New with Oracle 11g

        • Oracle 11g Configuration

        • Summary

      • 3 Applied Auditing and Audit Vault

        • An Era of Governance

        • Auditing for Nonsecurity Reasons

        • The Audit Data Warehouse

        • What to Audit and When to Audit

        • The Audit Warehouse Becomes the Audit Vault

        • Installation Options

        • Summary

    • Part II: Oracle Database Vault

      • 4 Database Vault Introduction

        • The Security Gap

        • Database Vault Components

        • Installing Oracle Database Vault

        • Summary: Database Vault Is Differentiating Security

      • 5 Database Vault Fundamentals

        • Realms

        • Command Rules

        • Rule Sets

        • Factors

        • DBV Secure Application Roles

        • Summary

      • 6 Applied Database Vault for Custom Applications

        • Notional Database Applications Environment

        • From Requirements to Security Profile Design

        • Requirements Technique: Use Cases and Scenarios

        • Identify Coarse-Grained Security Profile

        • Identify Fine-Grained Security Profile

        • Identify DBV Factors Based on Business or System Conditions

        • Identify DBV Realms and Realm Objects Based on Objects

        • Identify Accounts, Roles, and DBV Realm Authorizations from Use Case Actors

        • Establish DBV Command Rules from Conditions

        • Establish DBV Secure Application Roles from Conditions

        • Summary

      • 7 Applied Database Vault for Existing Applications

        • Audit Capture Preparation

        • Capturing Audits

        • Analyzing the Audit Trail

        • Integrating DBV with Oracle Database Features

        • Advanced Monitoring and Alerting with a DBV Database

        • Summary

    • Part III: Identity Management

      • 8 Architecting Identity Management

        • Understanding the Problem with Identity Management

        • Architecting Identity Management

        • Oracle Identity Management Solutions

        • Summary

      • 9 Oracle Identity Manager

        • The User Provisioning Challenge

        • Oracle Identity Manager Overview

        • User Provisioning Processes

        • User Provisioning Integrations

        • Reconciliation Integrations

        • Compliance Solutions

        • OIM Deployment

        • Summary

      • 10 Oracle Directory Services

        • Identity Management and the LDAP Directory

        • Oracle Internet Directory

        • Directory Virtualization and Oracle Virtual Directory

        • OVD Applied

        • Summary

    • Part IV: Applied Security for Oracle APEX and Oracle Business Intelligence

      • 11 Web-centric Security in APEX

        • Introduction to the APEX Environment

        • Securing an APEX Instance

        • Protecting the APEX Database Schemas

        • Summary

      • 12 Secure Coding Practices in APEX

        • Authentication and Authorization

        • SQL Injection

        • Cross-site Scripting

        • Leveraging Database Security Features

        • Summary

      • 13 Securing Access to Oracle BI

        • The Challenge in Securing BI

        • What Needs To Be Secured

        • Mechanics of Accessing Data with Oracle BI

        • Authentication and Authorization

        • Single Sign-On

        • Deploying in a Secure Environment

        • Securing the BI Cache

        • Public-facing Applications

        • Summary

      • 14 Securing Oracle BI Content and Data

        • Securing Web Catalog Content

        • Conveying Identity to the Database

        • Securing Data Presented by Oracle BI

        • Oracle BI and Database Vault

        • Auditing

        • BI Features with Security Implications

        • Summary

    • A: Using the Oracle BI Examples

      • Users and Groups

      • Database Preparations

        • Database Auditing

        • Database Scripts

      • Oracle BI Setup

        • Credential Store

        • BI Publisher Superuser

        • Other BI Publisher Configuration Steps

        • Sample BI Publisher Report

        • Scheduler Configuration

        • Usage Tracking

      • Recommend Testing

        • Oracle BI Tests

        • BI Publisher Tests

        • Oracle Delivers Tests

      • Sample Web Catalog Description

        • SH Dashboard

        • Utilities Dashboard

        • Other Dashboards

      • Sample RPD Descriptions

        • Common to All RPDs

        • Internal Authentication

        • Internal Authentication with Act as Proxy Enabled

        • Column-based Security

        • Table-based Authentication

        • Database Authentication

        • LDAP Authentication

        • SSO Integration

      • Summary

    • Index

      • A

      • B

      • C

      • D

      • E

      • F

      • G

      • H

      • I

      • J

      • K

      • L

      • M

      • N

      • O

      • P

      • Q

      • R

      • S

      • T

      • U

      • V

      • W

      • X

Nội dung

324 Part II: Oracle Database Vault This audit trail records reveal a pattern that involves three SELECT statements, followed by an INSERT statement, and then an UPDATE statement on tables related to product costs. We can assert that this sequence of statements constitute the normal context of the transaction. You can then develop DBV factors that query the audit trail for the records to validate the correct sequence of statements. It is possible that data other than the audit trail records exists, which you can use to perform this validation. You can use these factors in your DBV rules to prevent direct INSERT or UPDATE statements on the cost-related table unless the proper transactional sequence can be verified. This approach is similar to the types of controls you might find in an intrusion detection system (IDS) that performs pattern matching and anomaly detection. Factors Based on Data or Events Stored Externally The use of identity management information, when coupled with Oracle EUS, is one form of a DBV factor that is based on information stored externally. Many Oracle database environments reach out to other systems on the same network to retrieve information for one purpose or another. There is no reason you cannot use these external systems for event information that would be useful to your DBV security policy. This information could be as simple as supplemental data about the current user that is not stored in an identity management infrastructure but is stored in a human resources system. An advanced usage could even query a physical access system used by the company to determine whether the user swiped his or her access badge to get into the building at some point in the business day. We can use several queries to determine whether a database relies on external system for information. First, we can check for the dependency on the following types of PL/SQL routines by custom database application code: Oracle file-based APIs (UTL_FILE) Oracle network-based APIs (UTL_TCP, UTL_HTTP, DBMS_LDAP) Oracle Heterogeneous Services APIs (DBMS_HS_PASSTHROUGH) We can perform this type of dependency check with the following query, and we see that an application such as HTML DB (APEX) 3.0 has dependencies on these external access APIs: sys@aos>SELECT owner,name,type,referenced_name FROM dba_dependencies WHERE referenced_name IN ('UTL_FILE', 'UTL_TCP', 'UTL_HTTP', 'DBMS_LDAP', 'DBMS_HS_PASSTHROUGH') AND owner NOT IN ( 'SYS' ,'PUBLIC' ,'OLAPSYS' ,'ORDSYS' ,'ORDPLUGINS' ,'ORACLE_OCM' ,'MDSYS' ,'SYSMAN' ,'XDB' ,'WMSYS' ,'WKSYS' ) ORDER BY owner,name,type; ■ ■ ■ Chapter 7: Applied Database Vault for Existing Applications 325 OWNER NAME TYPE REFERENCED_NAME FLOWS_030000 UTL_FILE SYNONYM UTL_FILE FLOWS_030000 WWV_FLOW_CUSTOM_AUTH_LDAP PACKAGE BODY DBMS_LDAP FLOWS_030000 WWV_FLOW_WEB_SERVICES PACKAGE BODY UTL_HTTP 3 rows selected. We can also query the Oracle fine-grained access privileges for network services to determine which accounts may have been granted connection privileges to external hosts: sys@aos> SELECT p.principal, p.privilege, h.host, h.lower_port, h.upper_port FROM dba_network_acl_privileges p,dba_network_acls h WHERE p.aclid = h.aclid AND p.principal != 'DVSYS' ORDER BY 1,2; PRINCIPAL PRIVILEGE HOST LOWER_PORT UPPER_PORT FLOWS_030000 connect * SH connect hr-system.mycompany.com 8080 8085 SH connect badge-system.mycompany.com 2100 2150 SH resolve hr-system.mycompany.com 8080 8085 SH resolve badge-system.mycompany.com 2100 2150 5 rows selected. Some database applications may use Java stored procedures in the database and the Java socket APIs (versus PL/SQL network APIs) to connect to external systems. We can investigate this case by querying the accounts that may have socket “connect” permissions in the DBA_JAVA_ POLICY view as follows: sys@aos>SELECT grantee, action privilege, name host FROM dba_java_policy WHERE type_name = 'java.net.SocketPermission' AND action LIKE '%connect%'; GRANTEE PRIVILEGE HOST SH connect, resolve badge-system.mycompany.com SH connect, resolve hr-system.mycompany.com 2 rows selected. In this example, we’ve created a notional pair of hosts that run the physical access badging system and human resources system to illustrate the point. In a real-world scenario, we could investigate the purpose of these external systems being accessed to determine how those systems might be used to contribute information that can become DBV factors. Factors Based on Existing PL/SQL Code As you have seen so far, many opportunities and areas can be researched to uncover attributes that can be used as DBV factors. The process involves the use of queries on database audit trails and configurations as we have shown. For several areas, we may find only that name of a PL/SQL program and the next step is simply to employ a code inspection to determine what exists within the code that we can use as a DBV factor. For example, we used a query on the JOB$ table and 326 Part II: Oracle Database Vault DBA_SCHEDULER views to determine whether any time-based factors existed in the system. This query also provided us insight into the PL/SQL programs that were run. The next step in investigating these jobs would be to research the details of those programs to determine whether security-relevant data attributes or conditions exist that could be used as DBV factors and DBV rules, respectively. Many similar components in the database might be required for detailed research on PL/SQL code as a means to reach the same end result. The following table provides a short list of database features and the queries that can be used to uncover those PL/SQL program names. Database Feature or Option Query Standard Oracle views and the use of security-relevant conditions in the WHERE clause SELECT owner , view_name , text FROM dba_views WHERE owner = '<sensitive data object-owner>'; Standard Oracle PL/SQL functions, procedure, or package body If code is unwrapped in the database: SELECT name, type, text FROM dba_source WHERE owner = '<sensitive data object-owner>' ORDER BY name, type, line; Oracle VPD’s policy function SELECT object_owner, object_name, pf_owner, package , function FROM dba_policies WHERE pf_owner != 'XDB' ORDER BY 1,2 ; Oracle OLS and its policy labeling function or SQL predicate clause SELECT policy_name, schema_name, table_name, function, predicate FROM dba_sa_table_policies WHERE function IS NOT NULL OR predicate IS NOT NULL ORDER BY 1,2,3; Standard Oracle rules engine SELECT rule_owner, rule_name, rule_condition FROM dba_rules WHERE rule_owner != 'DVSYS' ORDER BY 1,2; Chapter 7: Applied Database Vault for Existing Applications 327 Refining the DBV Policy Design Once you’ve run the queries on the database audit trail, you should capture the results and categorize them using the section headers provided in this chapter. This process yields a draft specification of the DBV policy you want to review with the team of experts and stakeholders with which you are working. Once this policy specification has been reviewed and validated, you can begin writing your PL/SQL scripts with the appropriate DBMS_MACADM procedure calls to implement the policy. Deploying and Validating the DBV Policy After you’ve fleshed out the detailed DBV policy, you can deploy the policy to your existing development environment for unit testing. The next step is to migrate the policy to a formal test environment to perform complete system and load testing. You can use the Oracle Real Application Testing replay feature and the workloads you’ve captured without DBV enabled on your development and test environments. This will help ensure that the policy does not adversely affect the existing applications under real workload scenarios. Once the change has been officially validated, you will be ready to deploy the DBV policy to your existing production systems. The most recent version of the Oracle Enterprise Manager Grid Control (OEM GC) product, 10.2.0.5, includes provisioning capabilities for DBV policy to make this deployment process much easier on you. For any DBV-enabled database you’ve defined in OEM GC, you can select all or parts of the DBV policy and propagate them to the selected databases, as shown in Figure 7-5. Once you selected the DBV policy components you want to propagate, you can choose the destination database(s) that you want to propagate and the propagate options that control the provisioning of this policy. The OEM GC interface is shown in Figure 7-6. FIGURE 7-5 Selecting DBV policy components to propagate in OEM GC 328 Part II: Oracle Database Vault The combination of Oracle Real Application Testing and OEM GC enables full lifecycle deployment and testing for your enterprise, as shown in Figure 7-7. FIGURE 7-6 Selecting destination database and propagation options in OEM GC FIGURE 7-7 DBV policy deployment and testing lifecycle Chapter 7: Applied Database Vault for Existing Applications 329 This capability not only provides a higher level of assurance that your deployments from development to test and from test to production are successful, but it reduces both deployment risk and deployment time. Refer to Metalink note 760748.1 for more information on how to integrate DBV with OEM GC. Integrating DBV with Oracle Database Features We’ve already presented examples of DBV integration with various security features of the database such as OLS, VPD, and Oracle FGA. The Oracle DBV product leverages the Oracle Data Dictionary realm to protect the object-owner schemas for many of the data processing features, such Oracle Text or Oracle Spatial. We need to account for this realm protection and any application-specific realms you create to ensure the successful use of these features in your applications. DBV components can be integrated with the existing Oracle Database features to add value to the features. To help illustrate the tricks and techniques presented in this section, in this example, a notional object-owner account for an application is named APP_OBJECT_OWNER. In this object-owner account is a CUSTOMERS table with the following structure: app_object_owner@aos> DESCRIBE customers Name Null? Type ID NOT NULL NUMBER FIRST_NAME NOT NULL VARCHAR2(20) LAST_NAME NOT NULL VARCHAR2(40) GENDER NOT NULL CHAR(1) YEAR_OF_BIRTH NOT NULL NUMBER(4) MARITAL_STATUS VARCHAR2(20) STREET_ADDRESS NOT NULL VARCHAR2(40) POSTAL_CODE NOT NULL VARCHAR2(10) CITY NOT NULL VARCHAR2(30) STATE_PROVINCE NOT NULL VARCHAR2(40) MAIN_PHONE_NUMBER NOT NULL VARCHAR2(25) INCOME_LEVEL VARCHAR2(30) CREDIT_LIMIT NUMBER EMAIL VARCHAR2(30) TOTAL NOT NULL VARCHAR2(14) EFF_FROM DATE EFF_TO DATE VALID VARCHAR2(1) GEO_LOCATION MDSYS.SDO_GEOMETRY SEARCH_TERMS CLOB Oracle Text Oracle Text is a database feature that uses standard Oracle SQL to store, index, search, and analyze text and documents stored in the Oracle database, in files, and on the Web. Oracle Text can perform linguistic analysis on documents and can search text using a variety of strategies including keyword searching, context queries, pattern matching, thematic queries, and so on. A simple keyword search using Oracle Text against the CUSTOMERS table requires the use of 330 Part II: Oracle Database Vault the CONTAINS operator in a traditional SQL WHERE clause. The CONTAINS operator can be combined with normal SQL WHERE clause predicates as shown in the following example: SELECT SCORE(1), first_name, last_name, street_address FROM app_object_owner.customers WHERE state_province = 'TX' AND CONTAINS(search_terms, 'hospital', 1) > 0 ; To provide enterprise-level performance with the CONTAINS operator and the other operators provided with the Oracle Text feature, we can use function-based indexes on the column that is being searched. If we attempt to create (or maintain) an Oracle Text index once DBV is installed, the following error will occur: app_object_owner@aos>CREATE INDEX app_object_owner.customers_keyword_index ON app_object_owner.customers(search_terms) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('SYNC (ON COMMIT)'); CREATE INDEX app_object_owner.customers_keyword_index * ERROR at line 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-01031: insufficient privileges ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 75 This error occurs because the Oracle Data Dictionary realm protects the CTXSYS objects. We can fix this problem by authorizing the APP_OBJECT_OWNER account in the Oracle Data Dictionary realm as a participant. We create an application-specific realm at the same time. app_object_owner@aos>CONNECT diego_dbvmgr Enter password: Connected. diego_dbvmgr@aos> authorize the application's object-owner account diego_dbvmgr@aos> in the Oracle Data Dictionary realm diego_dbvmgr@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name => 'Oracle Data Dictionary' , grantee => 'APP_OBJECT_OWNER' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_participant); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos> create the realm protections for the diego_dbvmgr@aos> application's object-owner account diego_dbvmgr@aos>BEGIN dbms_macadm.create_realm( realm_name => 'Sample DBV Application' , description => 'Sample to demonstrate feature integration with DBV' , enabled => dbms_macutl.g_yes Chapter 7: Applied Database Vault for Existing Applications 331 , audit_options => dbms_macutl.g_realm_audit_fail ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sample DBV Application' ,object_owner => 'APP_OBJECT_OWNER' ,object_name => '%' ,object_type => '%' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name => 'Sample DBV Application' , grantee => 'APP_OBJECT_OWNER' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner); END; / PL/SQL procedure successfully completed. Authorizing APP_OBJECT_OWNER as a participant in this realm is not a security concern because this account does not have system ANY privileges for SELECT, DML, or DDL that would allow the account to read, write, or modify objects protected by this realm, such as CTXSYS. The account simply has system privileges that enable structural administration for objects that will be owned by the APP_OBJECT_OWNER account. diego_dbvmgr@aos>CONNECT app_object_owner Enter password: Connected. app_object_owner@aos>SELECT * FROM session_privs ORDER BY 1; PRIVILEGE CREATE CLUSTER CREATE INDEXTYPE CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION CREATE TABLE CREATE TRIGGER CREATE TYPE 9 rows selected. 332 Part II: Oracle Database Vault With the realm authorization in place, the object-owner account can now create and maintain the index and query the CUSTOMERS table using Oracle Text CONTAINS clause as follows: app_object_owner@aos> remove the invalid index created previously app_object_owner@aos>DROP INDEX app_object_owner.customers_keyword_index; Index dropped. app_object_owner@aos> create the new valid index app_object_owner@aos>CREATE INDEX app_object_owner.customers_keyword_index ON app_object_owner.customers(search_terms) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('SYNC (ON COMMIT)'); Index created. app_object_owner@aos> perform the keyword query app_object_owner@aos>SELECT SCORE(1) , first_name , last_name , street_address FROM app_object_owner.customers WHERE state_province = 'TX' AND CONTAINS(search_terms, 'hospital', 1) > 0 ; SCORE(1) FIRST_NAME LAST_NAME STREET_ADDRESS 12 Blaine Fernandez 17 South Hospital Court 12 Emery Ryan 37 North Hospital Street 12 Ian Tansey 17 South Hospital Court 12 Chloe Bishop 37 North Hospital Street 4 rows selected. As you can see, the authorization of the APP_OBJECT_OWNER in the Oracle Data Dictionary realm enables the successful creation of CTXSYS.CONTEXT index types. This approach is also required to enable the creation of CTXSYS.CTXCAT and CTXSYS.CTXRULE index types. TIP Enable object-owner accounts in the Oracle Data Dictionary realm when using function-based indexes. Make sure your object-owner accounts are not granted system ANY privileges that would cause a privilege escalation concern. Oracle Spatial Oracle Spatial is a database feature in the Oracle Enterprise Edition that provides advanced spatial features to support high-end geographic information system (GIS) and location-based services (LBS). The option can store complex vector-based geographic data such as points, lines, polygons, and even advanced geospatial data types such as raster (bitmap) formats for digital images. Like Oracle Text, Oracle Spatial offers a rich set of Oracle operators to query geographic data to Chapter 7: Applied Database Vault for Existing Applications 333 discover spatial relationships, and these operators perform best when used with a special function-based index called a spatial index. In addition to geographic data points, the Oracle Spatial option includes support for the Resource Description Framework (RDF) data standard for storing metadata about relationships between people, places, and objects, known as triples. Spatial indexes and RDF indexes rely on the extensible indexing capability of the database in the same way Oracle Text indexes do, so attempting to create spatial indexes with DBV installed results in the same type of error we encountered with Oracle Text: app_object_owner@aos> attempting to create a spatial index will fail app_object_owner@aos> with the default locked-down DBV policy app_object_owner@aos> CREATE INDEX app_object_owner.customers_geo_index ON app_object_owner.customers (geo_location) INDEXTYPE IS MDSYS.SPATIAL_INDEX; CREATE INDEX app_object_owner.customers_geo_index * ERROR at line 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine ORA-01031: insufficient privileges ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10 To enable index creation with the MDSYS.SPATIAL_INDEX index type, add the application’s object-owner account (APP_OBJECT_OWNER) as a participant of the Oracle Data Dictionary realm. This index type supports both vector-based and raster-based geographic formats. This approach is also required for indexes that are created with the MDSYS.SEM_INDEXTYPE index type in support of Oracle RDF capability. TIP You will need to drop function-based indexes before issuing a DROP TABLE on a table protected by a realm. The underlying database kernel will issue DROP INDEX statements that will result in realm violations if you do not first remove the indexes. One interesting integration approach for DBV and Oracle Spatial is centered around the Spatial operator SDO_RELATE and its mask, min_resolution, and max_resolution parameters. These parameters control how many results are returned when used with the operator in a SQL WHERE clause. They can be used as a security control, much like row-level security. We could define a set of DBV factors that assert the values of these parameters for any given session. The actual values of the control factors could be based on other factors such as the Connection_Type example presented in Chapter 5. Using this approach, you might reduce the resolution of imagery or types of geographic intersection matches that are supported when a session has a connection type with less trust (such as OTHER) compared to a session whose connection type has a greater level of trust (such as CORPORATE_SSL). Expression Filters An Expression Filter is a feature of the Oracle database that allows you to store rule expressions in a table so that you can compare those expressions against information stored in typical data table. The intent is to compare the rule expressions to the data table so that application code can dynamically respond to matches on those rules without having to hard-code these rules in an application. This might allow a corporation to compare incoming data on solicited customer . CLOB Oracle Text Oracle Text is a database feature that uses standard Oracle SQL to store, index, search, and analyze text and documents stored in the Oracle database, in files, and on the Web. Oracle. GC. Integrating DBV with Oracle Database Features We’ve already presented examples of DBV integration with various security features of the database such as OLS, VPD, and Oracle FGA. The Oracle DBV product. provides a short list of database features and the queries that can be used to uncover those PL/SQL program names. Database Feature or Option Query Standard Oracle views and the use of security-relevant

Ngày đăng: 06/07/2014, 23:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN