O10g security 12

http://www.ggola.com 장 경 상

5. Virtual Private Database.......................................................................5-2

5.1. VPD New Features.....................................................................5-3

5.1.1. Overview..............................................................................5-3

5.1.2. Column Level VPD................................................................5-3

5.1.3. New Policy Types..................................................................5-9

5.1.3.1............................................................................Static Policies

5-10

5.1.3.2.......................................................Context Sensitive Policies

5-10

5.2. Auditing Enhancement............................................................5-13

5.2.1. Fine-Grained Auditing (FGA)...............................................5-13

5.2.2. Traditional Auditing............................................................5-18

5.2.3. New Audit Information........................................................5-18

5.2.4. Audit Command Syntax......................................................5-22

5.2.5. Simple Audit Example........................................................5-24

[email protected] 1


5. Virtual Private Database

이번 장에서는 Virtual Private Database(VPD)에 대해서 다루게 된다. 사실 이

내용들은 보안 즉, security를 의미한다고 봐도 무방하다. Oracle9i부터 security를

위한 개념을 제시하면서 VPD가 설명되기 시작하였고 그래서 보다 oracle다운 용어로

이 장의 제목을 VPD로 표현하였다.

보다 고급화된 VPD 정책과 기능, auditing에 대한 내용들을 알아보자.

CF. 여기서 다루지는 않지만 oracle10g release 2부터는 이른바 “Transparent Data

Encryption”이 지원된다. 즉, application code의 변화 없이 원하는 data의 암,

복호화(encryption and decryption)를 자동화할 수 있다. 따라서 주민등록번호와

같은 보안이 중요한 data의 보안을 보다 쉽게 보장할 수 있게 된다.

[email protected] 2


5.1. VPD New Features

5.1.1.Overview

앞서 이야기 했듯이 VPD는 이전 oracle9i에서 소개된 feature이다. 물론, oarcle8i

부터 지원하는 application context를 구성요소로 삼고 있다.

종합하면 VPD는 server level의 FGAC(Fine Grained Access Control)과 secure

application context를 통해 보안정책들(security policies)을 구현함으로써

이루어진다. 그야말로 가상의 개인(보안이 된) data관리라 할 수 있다. 사실 이

내용들은 기 정의된 보안 정책에 따라 policy function을 이용하여 사용자의 SQL을

변형하고 그 결과로 display data를 제한하는 것으로 이해하면 된다.

CF. application context는 이미 oracle8i에서 소개된 바 있음으로 FGAC와 상관없이

사용 가능한 것임은 물론이다.

5.1.2.Column Level VPD

이전 버전의 VPD는 row level security까지 지원을 했었다. 이번 oracle10g는 이를

column level까지 확장하여 보다 고급화된 보안정책을 수립할 수 있도록 지원한다.

예를 들어 특정 table의 column에 대하여 protecting 정책을 수립하였다면 그

column을 포함하는 모든 query는 access에 제한을 받는다.

제한이란? 이전 버전에서 수립한 oracle policy는 row level security였고 이 경우 기

정의한 policy function을 이용하여 predicated where를 통해 row의 제한을 하는

것이었다. 따라서 조회하는 column과는 상관이 없었다는 것이고 이제 원한다면

column에 대한 제한까지 확장을 할 수 있는 기능이 Column Level VPD이다.

CF. 사실 이 기능은 기존의 package dbms_rls에 추가된 parameter를 가지고

적용한다. 이 package를 통해 수립하는 policy의 대상 objects는 table, view 또는

synonym이 될 수 있다.

다음의 간단한 예제를 통해 column level security를 구현해보자. 대상 table은

직원의 직통 전화번호를 담고 있는 조직관련 data이다. 보안상의 이유로 외부로부터의

직원에 대한 직접 접근을 막기 위해 전화번호 column을 protecting하는 정책을

수립해보자.

먼저 환경을 구성하고 조회결과를 확인한다.

SCOTT> create table x_emp (x_name varchar2(12), x_id varchar2(10),

[email protected] 3


2 x_phone varchar2(20), x_addr varchar2(50));

Table created.

SCOTT> insert into x_emp values ('KIM', '100001', '345-3521', 'EAST');

1 row created.

SCOTT> insert into x_emp values ('JANG', '200001', '345-3520', 'WEST');

1 row created.

SCOTT> insert into x_emp values ('LEE', '300001', '345-7649', 'NORTH');

1 row created.

SCOTT> insert into x_emp values ('CHOI', '400001', '345-7600', 'SOUTH');

1 row created.

SCOTT> commit;

Commit complete.

SCOTT> select x_name, x_phone from x_emp;

X_NAME X_PHONE

------------- ----------------

KIM 345-3521

JANG 345-3520

LEE 345-7649

CHOI 345-7600

다음은 적절한 권한을 설정하고 이전 버전의 oracle row level policy를 테스트한다.

최대한 간단히 만들었으니 이해하기 쉬울 것이다.

[email protected] 4


SYSTEM> grant execute on dbms_rls to scott;

Grant succeeded.

SYSTEM> conn scott/tiger

Connected.

SCOTT> create or replace function xp_sec_emp (obj_owner varchar2,

obj_name varchar2)

2 return varchar2 is

3 begin

4 return 'x_phone not like ''%0''';

5 end;

6 /

Function created.

SCOTT> select xp_sec_emp('x', 'x') from dual;

XP_SEC_EMP('X','X')

--------------------------------------------------------------------------------

x_phone not like '%0'

SCOTT> exec dbms_rls.add_policy(object_name => 'X_EMP',-

> policy_name => 'VPD_MANAGER',-

> policy_function => 'XP_SEC_EMP',-

> statement_types => 'select, delete');

PL/SQL procedure successfully completed.


X_NAME X_PHONE

------------- ---------------

KIM 345-3521

[email protected] 5


LEE 345-7649

SCOTT> select x_name from x_emp;

X_NAME

------------

KIM

LEE

SCOTT> exec dbms_rls.drop_policy('SCOTT', 'X_EMP', 'VPD_MANAGER');


위의 예는 where절에 manager를 조회하지 못하도록 설정한 것이다. 즉, 전화번호가

“0”으로 끝나는 data는 where절에서 제거함으로써 row level security를 구현할 수

있었다. 다음은 추가된 parameter column에 대한 제한을 사용하여 column level

VPD를 구현해 보자.




> statement_types => 'select, delete',-

> sec_relevant_cols => 'x_phone');



X_NAME X_PHONE

------------- ---------------

KIM 345-3521

LEE 345-7649


X_NAME

[email protected] 6


------------

KIM

JANG

LEE

CHOI

SCOTT> select count(*) from x_emp;

COUNT(*)

--------------

2

SCOTT> select count(x_name) from x_emp;

COUNT(X_NAME)

--------------------------

4

분명한 차이가 나타난다. 앞서 row level에서는 어떤 조건에서도 무조건 manager가

filtering되었지만 지금은 정책을 생성할 때 지정한 column “X_PHONE”을 참조하는

경우만 해당 정책이 적용된다. 즉, x_phone을 참조하는 query는 where절에

manager를 제거하도록 정책이 적용되었지만 x_phone을 참조하지 않고 이름만을

조회하면 모든 data가 다 display되는 것을 볼 수 있다. 간단하지만 column level

VPD가 구현되었다.

CF. 마지막 두 SQL의 count결과를 보면 그 차이가 매우 명확해 진다.

다음은 column level VPD의 또 다른 예이다. 이는 보안정책으로 지정한 column에

대한 data 표현을 추가적으로 제어하는 것이다. 어떤 결과가 나오는지 잘 확인하라.




> statement_types => 'select, delete',-

> sec_relevant_cols => 'x_phone',-

> sec_relevant_cols_opt => dbms_rls.all_rows);

[email protected] 7


BEGIN dbms_rls.add_policy(object_name => 'X_EMP', policy_name =>

'VPD_MANAGER', policy_function => 'XP_SEC_EMP', statement_types =

> 'select, delete', sec_relevant_cols => 'x_phone', sec_relevant_cols_opt =>

dbms_rls.all_rows); END;

*

ERROR at line 1:

ORA-28104: input value for sec_relevant_cols_opt is not valid

ORA-06512: at "SYS.DBMS_RLS", line 20

ORA-06512: at line 1




> statement_types => 'select',-

> sec_relevant_cols => 'x_phone',-

> sec_relevant_cols_opt => dbms_rls.all_rows);


처음에는 error가 return되었지만 두 번째는 성공하였다. 둘간의 차이는 parameter

statement_types의 차이다. 즉, column level VPD에서 보안정책으로 지정한

column에 대한 option(display option)을 지정할 때는 반드시 statement_types이

select only이어야 한다. 이제 앞서 테스트한 column level VPD의 SQL 4가지를

그대로 수행해 보자.


X_NAME X_PHONE

------------- ----------------

KIM 345-3521

JANG

LEE 345-7649

CHOI

[email protected] 8



X_NAME

------------

KIM

JANG

LEE

CHOI

SCOTT> select count(*) from x_emp;

COUNT(*)

--------------

4

SCOTT> select count(x_name) from x_emp;

COUNT(X_NAME)

--------------------------

4

위에서 보듯 모든 data가 어떤 상황에서도 다 나오며 data 건수도 모두 4개로

동일하다. 즉, where절에 predicated 조건이(policy function) 일률적으로 적용되지

않은 것처럼 보인다. 하지만 첫 번째 SQL에서 manager의 전화번호는 NULL로

나타나고 있다. 즉, column level VPD의 display option을 추가하면 row level의

data를 제거하는 것이 아니라 해당 row의 지정된 보안 column이 화면에 나타나야

하는 경우 그 data의 값을 NULL로 표현하여 사용자에게 보여주지 않도록 한다.

5.1.3.New Policy Types

Oracle10g는 성능상의 이유로 policy type을 여러 형태로 제공하고 있다. 이전

까지는 default인 “dynamic”을 사용해왔고 이러한 방식은 매번 policy function을

수행하고 parsing을 발생시킴으로 부담을 가질 수 밖에 없다.

따라서 oracle10g는 이러한 부분의 성능향상을 위해 기존의 dynamic외에 static 2

가지와 context_sensitive 2가지 총 5가지 policy types을 지원한다.

CF. dynamic type은 “dbms_rls.dynamic”으로 지정하며 아무 type도 지정하지

[email protected] 9


않으면 default로 이 값이 적용된다. 앞서 테스트한 정책들은 모두 default가 적용된

것이다.

CF. 적용방법( dbms_rls.[dynamic, static, shared_static, context_sensitive,

shared_context_sensitive] )

SQL> exec dbms_rls.add_policy(….

…….

policy_type => dbms_rls.dynamic, ………….

…………….

5.1.3.1. Static Policies

Static Policy :

이 형태의 policy type은 policy function을 한번만 수행하여 SGA에 cache하고

이를 반복적으로 가져다 사용을 하기 때문에 policy function의 재 수행을 막아 빠르게

보안정책을 적용할 수 있다.

즉, 이 형태는 policy function의 결과가 동일한 object에 대해서는 runtime과 상관이

없이 항상 일정하다고 가정하는 것이다. 따라서 이런 type의 policy는 특정

사용자집단에게 있어 항상 동일한 predicated 조건이 적용된다는 확신이 있을 때에만

사용한다.

예를 들어 web을 통해 접속하는 어떤 사용자 집단이 동일한 data를 공유하는 형태의

application이 있다면 해당 object에 대한 policy를 static type을 정의함으로써

성능향상을 꾀할 수 있다. 이 값은 “dbms_rls.static”으로 지정한다.

Shared_static policy :

이 type의 policy는 static과 달리 여러 object에 대하여 동일한 policy type과

function을 사용할 때 유용하다. 즉, 알고리즘은 앞서 설명한 static과 똑 같지만 여러

objects를 대상으로 동일한 policy type의 동일한 policy function으로 생성된

predicated 조건이 있는가를 먼저 찾아보는 과정이 추가된다.

CF. 특별한 것이 아니다. 고객의 e-mail이 ID인 회원정보 table과 ID관리 table에 있는

ID는 항상 동일함으로 ID에 대한 policy function을 구현한다면 이는 이들 두 table

모두에 공히 적용될 수 있고 이런 경우 두 table에 대한 policy는 동일한 policy

function과 동일한 policy type을 사용할 수 있을 것이다.

[email protected] 10


5.1.3.2. Context Sensitive Policies

Context_sensitive Policy :

이 형태의 policy type은 특정 database session에서 context change가 예상될 때

사용한다. 즉, context가 변경이 되었다고 감지되면 다시 policy function을 수행하고

그렇지 않다면 predicated 조건을 session memory내에 cache하여 사용한다.

CF. 어렵지 않다. Multiple clients가 database session을 공유하는 session pooling

형태의(대표적으로 middle tier를 사용하여 clients가 session을 공유하는) 시스템의

경우 한 session내에서 clients의 switch가 발생할 수 있고 따라서 이 switch

시점에는 매번 policy function이 reset되어야 한다. 이런 경우에 사용한다.

Shared_context_sensitive Policy :

Policy를 공유한다는 점에서 이 type의 의미는 앞서 설명한 shared_static policy와

같으며 단지 그 조건이 context_sensitive policy에 대하여 적용된다는 것이 다를

뿐이다.

CF. 주의할 것은 찾아야 하는 cache를(predicated 조건) static처럼 SGA가 아닌

context_sensitive의 속성상 session memory에서 찾는다는 점이다.

CF. 앞서 살펴본 shred policy type는(shared_static, shared_context_sensitvie)

기업의 business 정책을 수립할 때에 여러 objects에 대하여 single policy function

을 제공하는 아주 좋은 방식이 될 수 있다.



OCP point

==============================================

=================

1. column level VPD의 column list와 statement type간의 관계에 대한 이해

2. dbms_rls.add_policy의 대상이 되는 object 3가지

3. column level policy를 추가할 때 policy type의 종류와 의미

4. single policy function을 사용하는 shared policy type의 장점

참조

==============================================

=================

Virtual Private Database(VPD) : o9i 46p

application context : o8i 157p, o9i 46p, o9i 53p

FGAC : o8i 159p, o9i 53p



5.2. Auditing Enhancement

5.2.1.Fine-Grained Auditing (FGA)

FGA는 이미 oracle9i에서 소개되면서 dbms_fga package를 통해 select trigger

처럼 access하는 row에 대한 auditing을 지원하고 있다. 그러나 이러한 기능은 DML

에 적용할 수 없었고 원한다면 trigger나 log miner를 이용하여 구현을 해야 했다.

아시다시피 DML trigger는 만만치 않은 trade-off가 있고 log miner는 일일이

수작업을 해야 하는 불편을 무시할 수 없다. Oracle10g는 이런 많은 어려움을 제거해

준다.

다음의 간단한 예를 통해 DML과 관련한 FGA를 구현해 보자. 먼저 해당 package의

spec을 살펴보면 다음과 같다.

SCOTT> conn system/manager

Connected.

SYSTEM> grant execute on dbms_fga to scott;

Grant succeeded.


Connected.

SCOTT> desc dbms_fga

PROCEDURE ADD_POLICY

Argument Name Type In/Out Default?

----------------------------------------------------- ------------------------------- ----------

--------------

OBJECT_SCHEMA VARCHAR2 IN DEFAULT

OBJECT_NAME VARCHAR2 IN

POLICY_NAME VARCHAR2 IN

AUDIT_CONDITION VARCHAR2 IN DEFAULT

AUDIT_COLUMN VARCHAR2 IN DEFAULT

HANDLER_SCHEMA VARCHAR2 IN DEFAULT

HANDLER_MODULE VARCHAR2 IN DEFAULT

ENABLE BOOLEAN IN DEFAULT

STATEMENT_TYPES VARCHAR2 IN DEFAULT

AUDIT_TRAIL BINARY_INTEGER IN DEFAULT



AUDIT_COLUMN_OPTS BINARY_INTEGER IN DEFAULT

PROCEDURE DISABLE_POLICY


----------------------------------------------------- ------------------------------- ----------

--------------




PROCEDURE DROP_POLICY


----------------------------------------------------- ------------------------------- ----------

--------------




PROCEDURE ENABLE_POLICY


----------------------------------------------------- ------------------------------- ----------

--------------




ENABLE BOOLEAN IN DEFAULT

별로 복잡한 것은 없지만 procedure add_policy의 경우에는 의미파악을 잘 해야

함으로 간단히 설명해 보자.

Parameter Description Default

object_schema auditing대상 object의

schema

NULL : current schema

object_name auditing대상 object

policy_name auditing policy의 이름

audit_condition auditing조건 NULL : TRUE처럼

audit_column check할 column을(혹은

list를)

NULL : 모든 column 대상

handler_schema event handler의 owner NULL : current schema


표 5-1

add_policy 와

parameters


handler_module event handler function NULL : no event

enable policy enable 여부 TRUE

statement_types SQL type지정(insert,

update, delete, select)

select

audit_trail 사용된 SQL text와 bind

변수의 값을 기록할

것인가를 지정

dbms_fga.db_extened :

fga_log$의 lsqltext, lsqlbind

column에 기록

audit_column_opt

s

auditing column으로

지정한 columns중

하나라도 access하면

auditing을 할 것인가

아니면 모두다 access

해야 auditing을 할

것인가를 지정

dbms_fga.any_columns :

audit_column중 아무 column이나

access하면 auditing

CF. audit_condition은 auditing조건을 직접 입력하는 것으로 boolean expression

으로 작성하게 된다. 즉, 어떤 조건(col1 = 'a')이 TRUE면 auditing, FALSE면 no

auditing이 되는 것이다. 따라서 default인 NULL은 항상 true auditing이 된다.

CF. handler_module은 function을 통해 DBA로 하여금 auditing에 대한 action을

구현할 수 있게 해준다. 그러나 반대로 해당 function이 fail되면 user SQL도 fail된다

CF. audit_trail은 앞서 설명한 default외에 dbms_fga.db를 사용할 수 있는데 이 값을

사용하는 경우 SQL기록은 남기지 않는다.

CF. audit_column_opts : default외에 모든 audit_column을 access하는 경우에

한하여 auditing을 하려면 dbms_fga.all_columns를 사용할 수 있다.

다음은 위 기능을 이용하여 x_emp table에 대하여 조회 및 update를 할 때 x_name,

x_id 두 columns을 모두 access하는 경우에 한하여 auditing을 하되 부가적으로

sqltext 및 bind 변수를 모두 기록하도록 한 예이다.

SCOTT> exec dbms_fga.add_policy(-

> object_name => 'X_EMP', policy_name => 'FGA_XEMP_SU',-

> audit_column => 'X_NAME, X_ID',-

> statement_types => 'SELECT, UPDATE',-



> audit_column_opts => dbms_fga.all_columns);


SCOTT> col policy_name for a15

SCOTT> col sql_bind for a20

SCOTT> col sql_text for a40

SCOTT> select x_name from x_emp where x_name = 'LEE';

X_NAME

------------

LEE

SCOTT> select policy_name, scn, sql_text, sql_bind

2 from dba_fga_audit_trail;

no rows selected

Auditing정책을 수립한 x_emp에 대한 조회를 했지만 auditing이 되지 않았다. 그

이유는 정책을 만들 때 audit_column의 모든 column을 access하는 경우에만

auditing을 하도록 설정을 했기 때문이다. 다음 결과를 보자.

SCOTT> select x_name, x_id from x_emp where x_name = 'LEE';

X_NAME X_ID

-------------- ----------

LEE 300001



POLICY_NAM SCN SQL_TEXT

SQL_BIND

--------------------- ----------------

--------------------------------------------------------------------------------

----------------



FGA_XEMP_SU 9722612013 select x_name, x_id from x_emp where x_name =

:"SYS_B_0"

#1(3):LEE

정상적으로 auditing이 되었다. 그런데 bind 변수를 사용하지 않았음에도 bind변수에

값이 들어와 있다. 그것은 initial parameter cursor_sharing을 similar로 설정했기

때문이다. 그래서 system이 generation한 bind 변수 이름으로 기록이 되었다. 다음을

통해 bind 변수를 만들어 확인해 보자.

SCOTT> var v_name varchar2(10)

SCOTT> exec :v_name := 'LEE';


SCOTT> print :v_name

V_NAME

--------------------------------

LEE

SCOTT> select x_name, x_id, x_addr from x_emp where x_name = :v_name;

X_NAME X_ID X_ADDR

-------------- ----------- --------------------------------------------------

LEE 300001 NORTH

SCOTT> update x_emp set x_name = 'BANG' where x_id = '300001';

1 row updated.



POLICY_NAM SCN SQL_TEXT

SQL_BIND

--------------------- ----------------



----------------------------------------------------------------------------------------

---------------------------------

FGA_XEMP_SU 9722612013 select x_name, x_id from x_emp where x_name

= :"SYS_B_0"

#1(3):LEE

FGA_XEMP_SU 9722612080 select x_name, x_id, x_addr from x_emp where x_name

= :v_name

#1(3):LEE

FGA_XEMP_SU 9722613041 update x_emp set x_name = :"SYS_B_0" where x_id =

:"

SY

S_

B_

1”

#1(4):BANG #2(6):300001

SCOTT> rollback;

Rollback complete.

직접 binding을 하자 그 이름이 그대로 나타나고 있다. 또한 update 문장도 auditing

이 되고 있음을 확인할 수 있다.

CF. dba_fga_audit_trail view는 sys 소유의 fga_log$에 기록된 내용을 확인해 주며

앞서 audit_trail의 기록을 fga_log$에 저장한다고 했는데 dba_fga_audit_trail에서

확인할 수 있는 것은 바로 이 이유이다.

CF. 이전 버전과 마찬가지로 sys 계정으로 login하여 dba_fga_audit_trail의 정보를

직접 delete하여 log 기록을 정리할 수 있다.

5.2.2.Traditional Auditing

앞서 설명한 FGA의 기능과 전통적인 방식인 audit command를 통한 기능은 감사라는

측면에서 차이는 없다. 그러나 이전 버전부터 사용해온 audit는 전통적인(general,

standard) 방식으로써 object를 기반으로 한다. 이런 측면에서 볼 때 앞서 설명한 FAG

는 oracle9i에서부터 지원하는 value based auditing이라 표현 할 수 있겠다.즉, 앞서

우리는 value을 기준으로 하여 보다 세밀한 data단위의 auditing을 구현해 본 것이다.



지금부터는 object를 대상으로 하는 전통적 방식의 audit command에 대해 개괄적인

이해를 중심으로 알아보고자 한다.

CF. FGA package와 audit command을 통합하여 적절하게 구성함으로써 사용자의

행위 즉, user activity에 대해 보다 유연하고 정확한 tracking을 할 수 있을 것이다.

(다시 말해, fine-grained auditing 과 standard auditing의 통합을 잘 고려하라)

5.2.3.New Audit Information

Oracle10g에서 auditing 결과를 기록하는 내용이 어떻게 확장되었는지 알아보자.

새롭게 확장된 정보는 곧 auditing 정보를 확인하는 column의 추가내지는 변화를

의미함으로 이를 살펴보면 되겠다.

FGA와 달리 audit command에 의한 정보의 gathering은 sys소유의 aud$로

취합되며 dba_audit_trail을 통해 확인한다.

1. extended_timestamp : timestamp(6) with time zone의 형식으로 기록된다.

따라서 auditing의 시간정보를 GMT(혹은 UCT(Universal Coordinated Time))를

기준으로 time zone과 함께 소수점 9자리까지 자세하게 기록을 해준다.

2. global_uid : OID(Oracle Internet Directory)와 같은 LDAP을 사용하는

enterprise user환경에서는 enterprise user와 database user schema가 1:1

mapping이 되거나 하나의 database schema를 share할 수 있다. 이런 환경에서의

auditing은 부가적인 정보의 저장이 필요할 수 있다.

이때 1:1 mapping이 되는 경우 enterprise user는 username column에 기록되고

(FAG를 사용하는 경우에는 dba_fga_audit_trail의 db_user column) global_uid는

동일한 user를 식별하는 정보를(the same user’s global identity) 저장한다. 그러나

1:1 mapping이 아닌 shared schema형태에서는 username column에(FAG를

사용하는 경우에는 dba_fga_audit_trail의 db_user column) shared schema가

저장되고 global_uid는 enterprise id를 저장한다.

3. proxy_sessionid : proxy mechanism에 의해 login하는 enterprise user

환경에서 proxy session id를 저장한다. 즉, multi-tier환경에서 여러 사용자가 proxy

user로 database에 접속을 하는 경우 그 proxy session id를 저장하는 것으로 예를

들면 “appuser1”, “appuser2”, ….”appusern”들이 proxy user인 “prxuser”

하나로 database에 접속하는 형태를 말한다. 그런 경우 database user는 prxuser

하나이지만 실제 user는 다를 수 있기 때문에 보다 상세한 정보가 필요한 것이다. 이

경우 다음과 같은 인증명령들을 사용해야 한다.



CF. 아래 내역은 가상의 user “XA”를 만들어 “SCOTT” user를 통하는 proxy clause를

사용한 예이다.

SYSTEM> alter user xa grant connect through scott;

User altered.

SYSTEM> alter user xa revoke connect through scott;

User altered.

4. instance_number : RAC환경에서 node구분을 해준다.

5. os_process : 과거 SID만을 기록하던 session정보를 보다 구체화할 수 있도록 OS

상의 process id를 저장한다.

6. transactionid : 이 값은 auditing 대상의 transaction정보를 찾기 위해 그 id를

기록하는 것으로 필요하다면 이 값을 통해 해당 transaction 정보를 query할 수 있다

7. SCN : system change number를 기록하여 transaction 시점에 대한 정보를

제공한다. 이 값을 이용하면 변경된 transaction의 그 이전 data를 확인하는 것도

가능하다. 그러나 이 방식을 이용한 추적은 두 가지 문제가 있다. 첫 째 scn은

transaction의 rollback과 상관없이 발생하며 따라서 항상 기록이 된다. 즉,

autonomous transaction을 사용한다는 뜻이다. 그렇기 때문에 track을 하는

입장에서는 rollback된 정보는 알고 싶지 않지만 rollback된 transaction도 마치 이미

실제로 변경된 것처럼 느낄 수 있다는 문제와 또 한가지 이 정보는 undo_retention

동안만 유지되기 때문에 항상 존재 한다는 가정도 없다. 이러한 문제들을 피하기

위해서는 어쩔 수 없이 trigger를 사용하여 해당 정보를 commit된 것만 유지하고

undo_retention과 상관없이 보관해야 한다. 앞서 FAG에서 update를 통해 x_name

을 변경한 후 다시 rollback한 것을 기억하며 아래의 예를 보자.

SCOTT> select scn, sql_text, sql_bind from dba_fga_audit_trail

2 where statement_type = 'UPDATE';

SCN SQL_TEXT SQL_BIND

-------------- --------------------------------------------------------------------------------------

----------------------------------

9722613041 update x_emp set x_name = :"SYS_B_0" where x_id = :"SYS_B_1" #1(4):BANG

#2(6):300001



이 정보를 보면 id “300001”의 사용자 명을 “BANG”으로 변경한 update 문장이

수행된 것을 알 수 있다. 그러나 사실 rollback을 했기 때문에 이 정보는 필요가 없을 수

있다. 왜냐하면 rollback을 했기 때문에 이 transaction의 변경 전 data나 현재 data

가 변한 것이 없기 때문이다.

즉, 아래처럼 현재 data와 이전 data(scn 9722613041)를 확인하는 결과가

동일하다는 것이다.

CF. 아래의 SQL문에서 사용된 “AS OF”절은 추후 flashback version query에서

설명됨으로 그대로 따라 하도록 한다.

SCOTT> select x_name from x_emp where x_id = '300001';

X_NAME

------------

LEE

SCOTT> select x_name from x_emp as of scn 9722613041

2 where x_id = '300001';

X_NAME

------------

LEE

그러나 다음의 경우를 보면 이 정보는 매우 쓸만하다는 것을 알 수 있다.

SCOTT> update x_emp set x_name = 'KANG' where x_id = '300001';

1 row updated.

SCOTT> commit;

Commit complete.

SCOTT> select scn, sql_text, sql_bind from dba_fga_audit_trail

2 where statement_type = 'UPDATE';

SCN SQL_TEXT SQL_BIND



-------------- --------------------------------------------------------------------------------------

----------------------------------

9722613041 update x_emp set x_name = :"SYS_B_0" where x_id = :"SYS_B_1" #1(4):BANG

#2(6):300001

9722655997 update x_emp set x_name = :"SYS_B_0" where x_id = :"SYS_B_1" #1(4):KANG

#2(6):300001

위 경우 id “300001”의 사용자 이름을 “KANG”으로 변경하고 commit을 했기 때문에

이 transaction전의 즉, 변경 전 사용자 이름을 알 수가 없다. 따라서 다음과 같이 이전

data를 확인하는 것은 매우 효율적이다.

SCOTT> select x_name from x_emp where x_id = '300001';

X_NAME

------------

KANG

SCOTT> select x_name from x_emp as of scn 9722655997

2 where x_id = '300001';

X_NAME

------------

LEE

위 결과를 통해 현재 사용자 이름은 “KANG”이지만 이전 data(scn 9722655997)는

“LEE”였다는 것을 알 수 있다.

8. sql_bind, sql_text : 사용자가 사용한 SQL문장과 그 안의 bind 값을 저장한다.

하지만 이 정보가 필요하다면 initial parameter “audit_trail=db_extended”로

설정을 해야 한다.

CF. audit_trail : 이 parameter에 줄 수 있는 값은 다음과 같다.

audit_trail = {db|os|none|true|false|db_extended}

각각의 의미를 간략히 정의하면.

Value Description

db Enable auditing (write to sys.aud$ table)


표 5-2

Audit 값과 의미


true

noneDisable auditing

false

os Enable auditing and write to os audit file

db_extendedEnable auditing and write to sys.aud$ table including

sqltext & bind variable

이 값을 OS로 하는 경우에는 또 다른 initial parameter “audit_file_dest”에 적절한

위치를 지정을 하여야만 auditing 정보를 file로 write할 수 있다.

CF. 사실 이러한 새로운 auditing 정보들은 FGA에서도 동일하며 따라서

dba_fga_audit_trail에서도 같은 정보를 확인할 수 있다. 그래서 FGA와 audit에 의한

auditing정보를 통합하여 볼 수 있는 view인 “dba_common_audit_trail”은 이 두

view(dba_audit_trail, dba_fga_audit_trail)의 union all로 표현된다.

5.2.4.Audit Command Syntax

Audit command는 매우 복잡하고 다양한 구성이 가능하지만 이를 다 다룰 수는 없고

그 사용방식과 조건에 대한 정보를 살펴보고 간단한 예제를 구현해 보자.

SQL> audit [sql_statement|schema_object] by [session|access] whenever

(not) successful;

1. sql_statement : 이 절은 [statement option|system privilege] by [proxy|

user]로 이루어 진다. Statement option으로는 직접 options를 기록하거나 모든

options을 통칭하는 “ALL”을 사용할 수 있다. System privilege는 직접 privileges를

지정하거나 모든 privileges를 통칭하는 “ALL PRIVILEGES”를 사용할 수 있다. By

절은 proxy와 user를 지칭하는데 proxy는 지정하는 proxy user에 대해서만 auditing

을 user는 지정한 user에 대해서만 auditing을 한다는 의미이다.

CF. statement options : CLUSTER, CONTEXT, DATABASE LINK, DIMENSION,

DIRECTORY, INDEX, MATERIALIZED VIEW, NOT EXISTS, PROCEDURE,

PROFILE, PUBLIC DATABASE LINK, CREATE PUBLIC DATABASE LINK, PUBLIC

SYNONYM, ROLE, ROLLBACK SEGMENT, SEQUENCE, SESSION, SYNONYM,

SYSTEM AUDIT, SYSTEM GRANT, TABLE, TABLESPACE, TRIGGER, TYPE, USER,

VIEW, CLUSTER, CONTEXT, ALTER SEQUENCE, ALTER TABLE, COMMENT

TABLE, DELETE TABLE, EXECUTE PROCEDURE, GRANT DIRECTORY, GRANT

PROCEDURE, GRANT SEQUENCE, GRANT TABLE, GRANT TYPE, INSERT TABLE,



LOCK TABLE, SELECT SEQUENCE, SELECT TABLE, UPDATE TABLE

CF. system privileges : create table과 같은 모든 system privileges를 다 기술할

수 있다.

2. schema_object : 이 절은 [object_option] on [schema.object|directory|

default]로 이루어 진다. Object option은 “alter”와 같은 특정 operation을 지정하는

형태를 말한다. On절은 auditing하고자 하는 object를 지정하는 방법과 auditing할

directory 이름을 지정하는 방법, 마지막으로 default를 지정하여 현재 이후에

생성되는 objects에 대해서 자동으로 auditing을 실시하도록 하는 방법을 말한다.

3. by : 이 절은 session단위로 최소화 정보를 저장할 것인가 아니면 다 저장할

것인가를 지정한다. Session단위로 하면 동 session에서 동 object에 대하여 같은

형식의 operation이나 SQL은 하나의 record로 기록하고 access로 하면 모든 작업을

개개의 record로 저장한다. 아무 값도 지정을 하지 않으면 default 값인 by session이

적용되지만 DDL문은 이 option과 상관없이 항상 “by access”로 저장한다.

CF. by session으로 지정을 하더라도 audit_trail을 OS로 지정한 경우에는 해당

auditing 정보를 file로 write를 해야 하기 때문에 한번 write한 정보를 file에서 다시

read할 수가 없음으로 여러 record가 저장될 수 있다.

4. whenever (not) successful : 이 절은 성공한 SQL만 저장할 것인가, 실패한 SQL

만 저장할 것인가를 지정한다. 만일 아무것도 지정을 하지 않으면 즉, 이 절을 생략하면

성공, 실패와 상관없이 모두 auditing을 수행한다.

CF. audit를 해제하기 위해서는 audit command대신 “noaudit” command를 사용

하면 된다.

5.2.5.Simple Audit Example

다음은 간단한 예제를 통해 auditing 정보를 확인하는 방법이다.


Connected.


Connected.

SYSTEM> show parameter audit_trail

NAME TYPE VALUE

------------------------------------ -------------------------------- ------------------------------



audit_trail string NONE

SYSTEM> audit delete on scott.x_emp by access;

Audit succeeded.


Connected.

SCOTT> delete from x_emp where x_id = '300001';

1 row deleted.

SCOTT> rollback;

Rollback complete.


Connected.

SYSTEM> select transactionid, scn, sql_text, sql_bind

2 from dba_audit_trail;

no rows selected

SYSTEM> alter system set audit_trail = db;

alter system set audit_trail = db

*

ERROR at line 1:

ORA-02095: specified initialization parameter cannot be modified

위에서 보듯 audit 설정이 되어있지 않기 때문에 audit command를 통한 설정이

무시된 것을 알 수 있다. 또한 이 parameter 설정은 system level에서 running

중에는 변경이 불가함도 확인된다. 즉, dynamic parameter가 아니다. 이 값을

조정하여 database를 다시 restart해 보자.

SYSTEM> !vi /app/oracle/admin/NEWSVC/pfile/initNEWSVC.ora

…….

…….



# -------------------------- miscellaneous parameters ------------------------

## Security, auditing and queuing monitor

audit_trail = db

……..

……..

……..

……..

……..

~

~

~

:wq!

SYSTEM> conn sys/manager as sysdba

Connected.

SYS> shutdown immediate

SYSTEM> conn sys/manager as sysdba

Connected.

SYS> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SYS> startup

ORACLE instance started.

Total System Global Area 427819008 bytes

Fixed Size 779516 bytes

Variable Size 212081412 bytes

Database Buffers 209715200 bytes

Redo Buffers 5242880 bytes

Database mounted.

Database opened.

SYS> conn scott/tiger

Connected.

SYSTEM> select transactionid, scn, sql_text, sql_bind

2 from dba_audit_trail;



TRANSACTIONID SCN SQL_TEXT SQL_BIND

-------------------------- ----------------- -----------------------------------------------------

---------------

03000B00B2120000 9722661050

Auditing이 제대로 되고 있음이 확인된다. 그러나 SQL문과 bind variable 정보는

나타나지 않는다. 왜? 앞서 설명을 했지만 audit_trail의 값이 db_extended인

경우에만 이 값들이 나타나기 때문이다. 현재는 db로 설정을 했기 때문에 나타나지

않는다.

다음은 새로운 정보인 transactionid를 활용하여 변경 전 정보를 확인하는 예이다.

CF. 아래 SQL문에서 사용된 flashback관련 view는 추후 chapter 6의 flashback

transaction query에서 설명될 것이다. 여기서는 그대로 따라 한다.

SYSTEM> select start_scn, undo_change#, row_id, undo_sql

2 from flashback_transaction_query

3 where xid = (select transactionid from dba_audit_trail);

START_SCN UNDO_CHANGE# ROW_ID

UNDO_SQL

----------------- -------------------------- ----------------------------------------

----------------------------------------------------------------------------------------------------------

---------

9722661051 1

현재 이 transaction은 rollback을 했기 때문에 별다른 정보를 보여주지 못한다.

다음은 commit transaction을 해본 결과이다.


Connected.

SCOTT> delete from x_emp where x_id = '300001';

1 row deleted.

SCOTT> commit;



Commit complete.


Connected.

SYSTEM> select start_scn, undo_change#, row_id, undo_sql

2 from flashback_transaction_query

3 where xid in (select transactionid from dba_audit_trail where scn <>

9722661050);

START_SCN UNDO_CHANGE# ROW_ID

UNDO_SQL

----------------- --------------------------- --------------------------------------

----------------------------------------------------------------------------------------------------------

---------

9722662250 1 AAAOssAAQAAAn6cAAC

insert into "SCOTT"."X_EMP"("X_NAME","X_ID","X_PHONE","X_ADDR") values

('KANG','300001','345-7649','NORTH');

9722662250 2

이미 사라진 data를 복원하는 undo SQL을 포함하여 auditing된 transaction의

정보를 보여주고 있다.

다음은 x_emp에 대한 모든 auditing을 제거하는 작업이다. 현재의 audit command

와 앞서 적용했던 column VPD(RLS), FGA 정책을 제거하자.

SYSTEM> noaudit delete on scott.x_emp;

Noaudit succeeded.

SYSTEM> exec dbms_fga.drop_policy('SCOTT', 'X_EMP', 'FGA_XEMP_SU');





Connected.

SCOTT> exec dbms_rls.drop_policy(object_name => 'X_EMP', policy_name

=> 'VPD_MANAGER');




OCP point

==============================================

=================

1. dbms_fga.add_policy를 통해 설정하는 parameter audit_trail,

audit_column_opts

참조

==============================================

=================

FGA : o9i 62p

log miner : o8i 126p, o9i 87p


O10g security 12

Documents

Transcript of O10g security 12