Applied Oracle Security: Developing Secure Database and Middleware Environments- P20 doc

We can define these identities based on these notional environment conditions with the Authentication_ Method, Client_IP, and Session_User factors contributing to identify the Connection

Trang 1

The following table depicts a new DBV factor Connection_Type and its identities We can define these identities based on these notional environment conditions with the Authentication_ Method, Client_IP, and Session_User factors contributing to identify the Connection_Type factor.

Connection_Type Identity Authentication_Method Client_IP Session_User

CORPORATE_

PASSWORD

'192.168.0.%'

%

The approach to identifying factors based on the identity of other factors requires the

following steps:

1 Define the factor to be identified by other factors The factor that is identified by other

factors is called the parent factor.

2 Define factor links between the parent and contributing factors With the DVA web

application, this factor linking is done automatically with the underlying DBMS_

MACADM APIs.

3 Define the identities for the parent factor.

4 Define factors and identities for all factors that identify the parent factor The factors that

identify the parent factor are called child factors.

5 Define the identity maps that map the identities of the child factors to the parent factor First we define the Connection_Type factor, which is our parent factor, with a get_expr

parameter set to an expression that will resolve to one of our identities for the factor This is simply a default expression before the other factors are resolved and it should default to our least trusted identity.

BEGIN

dbms_macadm.create_factor(

factor_name => 'Connection_Type' ,

factor_type_name => 'Application',

description => 'Categorizes the connection security level.',

rule_set_name => NULL ,

get_expr => 'UPPER(''OTHER'')',

validate_expr => NULL,

identify_by => dbms_macutl.g_identify_by_factor,

labeled_by => dbms_macutl.g_labeled_by_self,

eval_options => dbms_macutl.g_eval_on_session,

audit_options => dbms_macutl.g_audit_on_get_error,

fail_options => dbms_macutl.g_fail_with_message);

END;

/

PL/SQL procedure successfully completed

Trang 2

Next we define factor links that identify all the child factors that could be used in our identity maps (which we will define in a bit) to identify the parent factor The PL/SQL API should be called for each child factor you plan to use in at least one identity map.

dbvowner@aos> create a link for the Client IP address

dbvowner@aos> BEGIN

dbms_macadm.add_factor_link(

parent_factor_name =>'Connection_Type',

child_factor_name =>'Client_IP',

label_indicator => 'N');

END;

/

dbvowner@aos> create a link for the Authentication Method

dbvowner@aos> BEGIN

child_factor_name =>'Authentication_Method',

END;

/

dbvowner@aos> create a link for the Session User

dbvowner@aos> BEGIN

child_factor_name =>'Session_User',

END;

/

The label_indicator parameter is required for DBV’s integration capability with OLS and should

be set to ‘N’ (FALSE) by default.

Next we define the identities for the parent factor based on the preceding table Four possible classifications of the connection are shown next in order of the trust we have in the connection

(highest to lowest) The trust_level parameter is a number that can be defined at your discretion

The level set for each identity should be indicative the trust you would place on a session that has the identity set relative to sessions with other identities.

dbvowner@aos> BEGIN

create identity for LOCAL_DBA value

or connections on the database console

dbms_macadm.create_identity(factor_name=>'Connection_Type',

value=>'LOCAL_DBA',trust_level=>4);

create identity for CORPORATE_SSL value

or connections within the corporate network

using PKI/SSL authentication

value=>'CORPORATE_SSL',trust_level=>3);

create identity for CORPORATE_PASSWORD value

or connections within the corporate network

Trang 3

using username/password authentication

value=>'CORPORATE_PASSWORD',trust_level=>2);

create identity for OTHER value

or connections coming from outside the

corporate network, such as over a VPN connection

value=>'OTHER',trust_level=>1);

END;

/

Next we define the child factors whose identities will be used to resolve the parent factor The factors that are used in this example are all installed by DBV, so we’ve saved some time in this case The Client_IP factor will use the LIKE comparison operator in this example, so we do not need to define identities for this factor The DBV product installs all the possible identities for the Authentication_Method factor as the following query shows:

dbvowner@aos> SELECT factor_name,value

FROM dvsys.dv$identity

WHERE factor_name = 'Authentication_Method'

ORDER BY factor_name

/

FACTOR_NAME VALUE

-

-Authentication_Method DCE

Authentication_Method KERBEROS

Authentication_Method NONE

Authentication_Method OS

Authentication_Method PASSWORD

Authentication_Method RADIUS

Authentication_Method SSL

7 rows selected

The only child factor identities that remain are the trusted accounts we want to define for the database console, SYS and SYSTEM:

dbvowner@aos> BEGIN

dbms_macadm.create_identity(factor_name=>'Session_User',

value=>'SYS',trust_level=>10);

dbms_macadm.create_identity(factor_name=>'Session_User',

value=>'SYSTEM',trust_level=>10);

END;

/

The last set of steps requires us to define a set of identity conditions for the child factors that will resolve each identity of our parent factor These mappings of child factor identities to the identity of the parent factor are called identity maps For the LOCAL_DBA identity of the

Connection_Type factor, the following identity maps will consider the authentication method, the database client’s IP address, and the name of the user:

Trang 4

dbvowner@aos> BEGIN

WHEN authenticating by OS, such as / AS SYSDBA,

or by PASSWORD

dbms_macadm.create_identity_map(

identity_factor_name => 'Connection_Type'

, identity_factor_value => 'LOCAL_DBA'

, parent_factor_name => 'Connection_Type'

, child_factor_name =>'Authentication_Method'

, operation => '='

, operand1 => 'OS'

, operand2 => NULL );

, operation => '='

, operand1 => 'PASSWORD'

AND the client IP address is NULL, as is the case

when logging into the database on the console

outside the control of the database listener, or

when the IP address is that of the database server

when coming through the listener

, child_factor_name =>'Client_IP'

, operation => 'IS NULL'

, operand1 => 'NULL'

, operation => '='

, operand1 => '192.168.0.251'

AND the user is SYS or SYSTEM

, child_factor_name =>'Session_User'

, operation => '='

, operand1 => 'SYS'

Trang 5

, child_factor_name =>'Session_User'

, operation => '='

, operand1 => 'SYSTEM'

END;

/

It is important that you understand the processing logic for a DBV identity map that makes use of multiple child factors and more than one factor identity in the map configuration The preceding map has three child factors that will be evaluated with AND logic For multiple identities within each child factor, such as the case with the Authentication_Method, Client_IP, and Session_User identities used, the evaluation will use an OR logic within each child factor In

other words, the DBV identity map for the Connection_Type = 'LOCAL_DBA' will be TRUE when

the following occurs:

( Authentication_Method = 'OS' OR Authentication_Method = 'PASSWORD' )

AND ( Client_IP IS NULL OR Client_IP = '192.168.0.251' )

AND (Session_User = 'SYS' OR Session_User = 'SYSTEM')

For the CORPORATE_SSL identity, the following identity maps consider the authentication method and the database client’s IP address:

dbvowner@aos> BEGIN

WHEN the authentication method is PKI/SSL (certificate)

, identity_factor_value => 'CORPORATE_SSL'

, operation => '='

, operand1 => 'SSL'

AND the client's IP address is on the corporate network,

which we have defined as the 192.168.0 subnet

, identity_factor_value => 'CORPORATE_SSL'

, operation => 'LIKE'

, operand1 => '192.168.0%'

END;

/

For the CORPORATE_PASSWORD identity, the following identity maps consider the

authentication method and the database client’s IP address:

Trang 6

dbvowner@aos> BEGIN

WHEN the authentication method is PASSWORD

, identity_factor_value => 'CORPORATE_PASSWORD'

, operation => '='

, operand1 => 'PASSWORD'

AND the client's IP address is on the corporate network,

which we have defined as the 192.168.0 subnet

, identity_factor_value => 'CORPORATE_PASSWORD'

, operation => 'LIKE'

, operand1 => '192.168.0%'

END;

/

For the OTHER identity, the identity map is simply based on the database client’s IP address not being on the 192.168.0 subnet and is coming from some other network:

dbvowner@aos> BEGIN

, identity_factor_value => 'OTHER'

, operation => 'NOT LIKE'

, operand1 => '192.169.0.%'

END;

/

dbvowner@aos>COMMIT;

Commit completed

Now that DBV identity maps are defined, we can test them under various scenarios to understand how they work If we log in as SYS on the database console, we should expect the Connection_Type factor to resolve to LOCAL_DBA:

$ sqlplus / AS SYSDBA

SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:18:04 2009

Trang 7

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining,

Oracle Database Vault and Real Application Testing options

sys@aos> SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type

, DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method

, DVSYS.GET_FACTOR('Client_IP') Client_IP

FROM DUAL;

CONNECTION AUTHENTICA CLIENT_IP

-LOCAL_DBA OS

1 row selected

If we log in as MARY on the corporate network using password authentication, for example,

we should expect the Connection_Type factor to resolve to CORPORATE_PASSWORD:

$ sqlplus mary@aos

Enter password:

Connected to:

mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type

FROM DUAL;

CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP

-CORPORATE_PASSWORD PASSWORD 192.168.0.200

1 row selected

If we log in as MARY over a VPN connection, with an access point external to the corporate

network, we should expect the Connection_Type factor to resolve to the value 'OTHER':

C:\> sqlplus mary@aos

Enter password:

Connected to:

FROM DUAL;

Trang 8

-OTHER PASSWORD 10.10.10.10

1 row selected

This example demonstrates how to create a security-relevant factor whose foundation is based on multiple (other) factors using a declarative method that required no PL/SQL programming The factors we used in this example are provided by the database kernel code, but your custom factors could also be used with this approach You can establish a multifactor security policy when these factors are used DBV rule sets or in your own PL/SQL code.

Consider the DBV CONNECT command rule example presented earlier In this example, two DBV rules were used to authorize a connection to the database The rules ‘Is Secure Authentication Method’ and ‘Is Console Client’ examined the authentication method and database client’s IP address in a manner similar to the way that the Connection_Type factor is identified We can replace these two DBV rules with a single DBV rule, ‘Is Trusted Client’, to achieve the same result

simply by checking for the factor Connection_Type not being ‘OTHER’, as shown in this example:

dbvowner@aos> BEGIN

dbms_macadm.create_rule(

rule_name => 'Is Trusted Client'

, rule_expr =>

'DVSYS.GET_FACTOR(''Connection_Type'') <> ''OTHER'''

);

END;

/

To demonstrate multifactor security within PL/SQL, we can create a VPD policy on the CUSTOMERS table in the Sales History (SH) schema In this policy, we will use the factor in the VPD policy function to provide either column-level or row-level security on the table First we need to grant a named account the ability to manage VPD policy The realm owner of the Sales History realm, MARY, is authorized to perform not only administration on objects in the SH object owner account, but she can also perform VPD policy administration on the objects The only step that is required to enable this VPD administration is to grant MARY execute privileges on the VPD administration package, SYS.DBMS_RLS This package is protected by the Oracle Database Vault realm and requires the DV_OWNER role to grant the privilege.

dbvowner@aos> GRANT EXECUTE ON sys.dbms_rls TO mary;

MARY must first create the VPD policy function that will leverage our factor to provide row-level security on the SH.CUSTOMERS table:

mary@aos>CREATE OR REPLACE FUNCTION sh.customer_policy_function(

schema_name IN VARCHAR2

, table_name IN VARCHAR2 ) RETURN VARCHAR2

AS

BEGIN

prevent access to sensitive customer data

outside of the corporate network

Trang 9

IF schema_name = 'SH'

AND table_name = 'CUSTOMERS' THEN

when the connection type factor is OTHER we know

the database client has not connection from

the corporate network

IF DVSYS.GET_FACTOR('CONNECTION_TYPE')

= 'OTHER' THEN

RETURN '1=0';

for all other connection types allow

access to all rows

ELSE

RETURN '1=1';

END IF;

END;

/

Function created

Next MARY can create a VPD policy using the DBMS_RLS package In this example policy,

we will restrict just the ability to show sensitive columns such as date of birth, marital status, and income outside of the corporate network:

mary@aos> BEGIN

dbms_rls.add_policy(

object_schema => 'SH'

,object_name => 'CUSTOMERS'

,policy_name => 'POLICY_CUSTOMERS'

,function_schema => 'SH'

,policy_function => 'CUSTOMER_POLICY_FUNCTION' ||

,sec_relevant_cols => 'CUST_GENDER,CUST_YEAR_OF_BIRTH' ||

',CUST_MARITAL_STATUS,CUST_INCOME_LEVEL,CUST_CREDIT_LIMIT'

,sec_relevant_cols_opt => dbms_rls.all_rows

);

END;

/

If MARY queries the SH.CUSTOMERS table from within the corporate network, the security sensitive columns are visible:

mary@aos> show the Connection_Type factor and session context

FROM DUAL;

-CORPORATE_PASSWORD PASSWORD 192.168.0.200

1 row selected

Trang 10

mary@aos> query the SH.CUSTOMERS table

mary@aos> SELECT

cust_last_name

, cust_year_of_birth

, cust_marital_status

, cust_income_level

FROM sh.customers

WHERE cust_state_province = 'TX'

AND ROWNUM < 10

ORDER BY cust_last_name

/

CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL

- - -

-Beiers 1982 single K: 250,000 - 299,999

Duval 1981 single H: 150,000 - 169,999

Greeley 1977 F: 110,000 - 129,999

Grover 1970 married D: 70,000 - 89,999

Hamilton 1961 single G: 130,000 - 149,999

Krider 1967 F: 110,000 - 129,999

Majors 1948 single G: 130,000 - 149,999

Rowley 1969 single H: 150,000 - 169,999

Stone 1978 single I: 170,000 - 189,999

9 rows selected

If MARY queries the SH.CUSTOMERS table from outside the corporate network, the security sensitive columns are not visible and VPD will set them to NULL in the result set returned: mary@aos> show the Connection_Type factor and session context

FROM DUAL;

-OTHER PASSWORD 10.10.10.10

1 row selected

mary@aos> query the SH.CUSTOMERS table

mary@aos> SELECT

cust_last_name

, cust_year_of_birth

, cust_marital_status

, cust_income_level

FROM sh.customers

WHERE cust_state_province = 'TX'

AND ROWNUM < 10

ORDER BY cust_last_name

/

Định dạng
Số trang	10
Dung lượng	139,59 KB