데이터베이스 보안(Security)은 사용자가 고의나 실수로 데이터베이스에 저장된 데이터를 조작해 일관성을 손상시키거나 전체 데이터베이스를 파손시키는 일을 방지하려는 데 목적이 있다.
본 장에서는 Tibero의 데이터베이스 보안을 위한 사용자 계정과 사용자의 특권(Privilege) 및 역할(Role) 등을 효율적으로 관리하고 데이터베이스 사용을 감시(Audit)하기 위한 방법을 설명한다.
Tibero 내부의 데이터에 접근하기 위해서는 사용자 계정(Account)이 필요하다. 각 계정은 패스워드(Password)를 통해 보안이 유지된다. 패스워드는 사용자 계정을 생성할 때 설정하며, 생성된 이후에 변경할 수 있다. Tibero는 패스워드를 데이터 사전(Data Dictionary)에 암호화된 형태로 저장한다.
Tibero에서 하나의 사용자 계정은 하나의 스키마를 가지며 스키마의 이름은 사용자의 이름과 같다.
특정 스키마에 속한 스키마 객체를 나타내려면 다음과 같이 입력한다.
사용자 계정.스키마 객체
다음은 tibero라는 사용자 계정으로 접속하여 SYS 사용자의 SYSTEM_PRIVILEGES에 접근하는 예이다.
$ tbsql tibero/tmax tbSQL 5 SP1 Copyright (c) 2008, 2009, 2011 TmaxData Corporation. All rights reserved. Connected to Tibero. SQL> SELECT * FROM SYS.SYSTEM_PRIVILEGES; ...
다음은 스키마 객체 앞에 특정한 사용자 계정을 명시하지 않았을 경우의 예이다.
SELECT * FROM V$DATABASE;
사용자 계정이 생략되면 스키마 객체에 접근할 때 다음과 같은 과정을 거친다.
사용자 자신이 소유한 스키마 객체 중에 V$DATABASE가 있는지 검색한다.
tibero라는 사용자 계정으로 접속했다고 가정하면 tibero.V$DATABASE를 검색한다.
사용자가 소유한 스키마 객체 중 V$DATABASE가 존재하지 않으면 PUBLIC 사용자가 소유한 동의어를 검색한다. 즉, PUBLIC.V$DATABASE를 검색한다.
PUBLIC 사용자는 오직 동의어만을 소유할 수 있다. PUBLIC 사용자가 소유한 동의어를 검색할 때 스키마 객체 앞에 PUBLIC 사용자 계정을 명시할 수 없다. PUBLIC 사용자가 소유한 동의어 V$DATABASE를 찾는다고 가정하면 PUBLIC.V$DATABASE라고 입력할 수 없고 V$DATABASE만 입력해야 한다.
PUBLIC.V$DATABASE라는 이름의 스키마 객체가 없거나 있어도 사용자가 PUBLIC.V$DATABASE 객체에 대한 특권이 없다면 에러를 반환한다.
사용자를 새로 생성하거나 변경, 제거하기 위해서는 DBA 특권을 가진 사용자로 Tibero에 접속한다.
Tibero에서는 기본적으로 SYS라는 사용자를 제공한다. SYS 사용자는 Tibero를 설치하는 과정에서 생기는 계정으로 DBA 역할이 부여된다.
SYS 사용자로 Tibero에 접속하는 방법은 다음과 같다.
$ tbsql SYS/tibero tbSQL 5 SP1 Copyright (c) 2008, 2009, 2011 TmaxData Corporation. All rights reserved. Connected to Tibero. SQL>
SYS 사용자는 DBA의 역할이 부여된 만큼 될 수 있으면 다른 사용자 계정을 사용할 것을 권장한다.
사용자를 생성할 때에는 데이터베이스 보안 정책에 따라 적당한 특권을 가진 사용자 계정을 생성한다.
사용자를 생성하는 방법은 다음과 같다.
SQL> CREATE USER Steve ... ① ... IDENTIFIED BY dsjeoj134 ... ② ... DEFAULT TABLESPACE USR; ... ③ ...
① CREATE USER 문을 사용하여 Steve라는 사용자를 생성한다.
② 사용자 Steve의 패스워드를 dsjeoj134로 설정한다. CREATE USER 문을 사용할 때에는 반드시 패스워드를 설정해야 한다.
③ 디폴트 테이블 스페이스를 USR로 설정한다.
다음은 위와 동일한 방법으로 여러 사용자를 생성하는 예이다.
SQL> CREATE USER Peter IDENTIFIED BY abcd; User 'PETER' created. SQL> CREATE USER John IDENTIFIED BY asdf; User 'JOHN' created. SQL> CREATE USER Smith IDENTIFIED BY aaaa; User 'SMITH' created. SQL> CREATE USER Susan IDENTIFIED BY bbbb; User 'SUSAN' created.
위와 같이 테이블 스페이스를 지정하지 않으면 자동으로 시스템 테이블 스페이스를 사용하게 된다. 새로 생성된 사용자는 아무런 특권을 가지지 않으며 데이터베이스에 접속할 수 없다. 데이터베이스에 접속하기 위해서는 CREATE SESSION 시스템 특권이나 이를 포함하는 역할을 부여 받아야 한다.
다음은 생성된 사용자에게 특권을 할당하는 예이다.
SQL> GRANT CONNECT TO Peter; Granted. SQL> GRANT RESOURCE TO John; Granted. SQL> GRANT CONNECT TO Smith; Granted. SQL> GRANT DBA TO Susan; Granted.
자세한 내용은 “5.2. 특권”을 참고한다.
사용자에게 설정된 패스워드, 테이블 스페이스 등을 변경하는 방법은 다음과 같다.
ALTER USER Peter ... ① ... IDENTIFIED BY abcdef ... ② ... DEFAULT TABLESPACE SYSTEM; ... ③ ...
① ALTER USER 문을 사용하여 Peter라는 사용자의 정보를 변경한다.
② 사용자 Peter의 패스워드를 abcdef로 변경한다.
③ 테이블 스페이스를 SYSTEM 테이블 스페이스로 변경한다.
사용자를 제거하는 방법은 다음과 같다.
DROP USER user_name CASCADE;
다음은 John 이라는 사용자를 제거하는 예이다.
DROP USER John CASCADE;
Tibero에서는 사용자의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있다. DBA나 일반 사용자 모두 사용할 수 있다.
| 정적 뷰 | 설명 |
|---|---|
| ALL_USERS | 데이터베이스의 모든 사용자의 기본적인 정보를 조회하는 뷰이다. |
| DBA_USERS | 데이터베이스의 모든 사용자의 자세한 정보를 조회하는 뷰이다. |
| USER_USERS | 현재 사용자의 정보를 조회하는 뷰이다. |
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고한다.
데이터베이스 사용자가 계정에 접속할 수 없도록 계정을 잠금 상태로 설정하거나 잠금 상태를 해제할 수 있다.
SQL> ALTER USER Peter ACCOUNT LOCK; User 'PETER' altered.
계정 잠금 상태에서 해당 계정에 접속을 시도하면 다음과 같은 오류 코드와 함께 접속이 중단된다.
SQL> conn peter/abcd; TBR-17006: Account is locked. No longer connected to server.
계정 잠금을 해제하려면 다음의 SQL을 수행한다.
SQL> ALTER USER Peter ACCOUNT UNLOCK; User 'PETER' altered.
프로파일 설정에 따라 패스워드 사용 기한이 만료되거나 패스워드 오류 횟수 초과 등으로 계정 잠금 상태가 된 경우에도 동일한 방법으로 잠금 해제할 수 있다.
사용자가 데이터베이스의 특정 스키마 객체에 접근하려면 특권을 부여 받아야 한다. 특권을 부여받으면 허용된 스키마 객체에 SQL 문장 등을 실행할 수 있다.
다음은 사용자에게 특권을 부여하는 예이다.
SQL> conn Peter/abcdef ... ① ... Connected. SQL> CREATE TABLE EMPLOYEE (ID NUMBER, EMPLOYEE_NAME VARCHAR(20), ADDRESS VARCHAR(50)); ... ② ... Created. SQL> GRANT SELECT ON EMPLOYEE TO Smith; ... ③ ... Granted.
① Peter 라는 사용자 계정으로 데이터베이스에 접속한다.
② CREATE TABLE 문을 사용하여 EMPLOYEE 테이블을 생성한다. 총 3개의 컬럼(ID, EMPLOYEE_NAME, ADDRESS)을 생성한다.
③ Smith라는 사용자가 Peter 사용자가 생성한 EMPLOYEE 테이블에 GRANT 명령을 실행하여 SELECT 특권을 부여한다.
이제 사용자 Smith는 Peter의 EMPLOYEE 테이블을 조회할 수 있다.
PUBLIC 사용자에게 특권을 부여할 수 있는데 존재하는 모든 사용자에게 특권을 부여한 것과 동일한 효과를 갖는다. 특권을 효율적으로 관리하기 위해 특권의 집합인 역할을 생성한다. 동일한 특권을 부여해야 할 사용자가 많은 경우 역할을 이용함으로써 GRANT 명령의 사용 횟수를 줄일 수 있다. 특권과 마찬가지로 역할도 PUBLIC 사용자에게 부여하면 모든 사용자에게 역할을 부여한 것과 동일한 효과를 갖는다.
Tibero에서 제공하는 특권은 크게 두 가지로 나뉜다.
스키마 객체 특권(Schema Object Privilege)
특정 객체에 대한 질의 및 갱신 특권이다.
데이터베이스에서 특정 작업을 수행할 수 있는 특권이다.
스키마 객체 특권은 스키마 객체인 테이블, 뷰, 시퀀스, 동의어 등에 접근하는 것을 제어하는 권한이다.
스키마 객체 특권은 GRANT 명령을 사용해 다른 사용자에게 부여할 수 있으며, 그 내용은 데이터 사전에 기록된다.
스키마 객체 특권은 다음과 같다.
다음은 WITH GRANT OPTION을 이용하여 스키마 객체 특권을 부여하는 예이다.
SQL> GRANT SELECT, UPDATE (EMPLOYEE_NAME, ADDRESS) ON EMPLOYEE
TO Smith WITH GRANT OPTION;
WITH GRANT OPTION을 이용하여 특권을 부여받았을 경우 특권을 부여받은 사용자가 부여받은 특권을 다른 사용자에게 부여할 수 있다.
사용자 Peter가 위의 GRANT 명령을 실행하기 위해서는 특권을 갖고 있어야 한다. 그 특권은 스키마 객체 EMPLOYEE에 대한 SELECT, UPDATE 특권과 WITH GRANT OPTION을 함께 사용할 수 있는 특권이다.
위의 명령이 실행되면 사용자 Smith는 EMPLOYEE에 대한 SELECT 및 UPDATE 특권을 갖게 된다. 이때 EMPLOYEE에 대한 UPDATE 특권은 컬럼 EMPLOYEE_NAME과 ADDRESS에 한한다. 사용자 Smith는 또한 EMPLOYEE에 대한 SELECT, UPDATE, WITH GRANT OPTION 특권을 다른 사용자에게 부여할 수 있는 특권도 갖게 된다.
마찬가지로 사용자 Susan과 John에게도 다음과 같은 특권을 할당한다.
SQL> GRANT ALL ON EMPLOYEE TO Susan WITH GRANT OPTION; Granted. SQL> GRANT SELECT, DELETE ON EMPLOYEE TO John WITH GRANT OPTION; Granted.
다른 사용자로부터 스키마 객체 특권을 회수하기 위해서는 REVOKE 명령을 사용해야 한다. 이 명령은 사용자의 스키마 객체 특권의 일부 또는 전체를 회수할 수 있다. DBA는 자신이 직접 부여하지 않는 특권에 대해서도 다른 사용자로부터 회수할 수 있다.
다음은 각각 Peter로부터 테이블 EMPLOYEE에 대한 DELETE 특권을 회수하고 John으로부터 모든 특권을 회수하는 예이다.
REVOKE DELETE ON EMPLOYEE FROM Peter; REVOKE ALL ON EMPLOYEE FROM John;
WITH GRANT OPTION과 함께 부여된 특권을 회수할 때에는 연속적으로 특권이 회수된다.
다음은 Peter로부터 부여받은 Peter.EMPLOYEE에 대한 특권을 사용자 Smith가 Susan에게 부여하는 예이다.
SQL> conn Smith/abcd Connected. SQL> GRANT ALL ON Peter.EMPLOYEE TO Susan; Granted.
사용자 Peter가 다음과 같이 Smith에게 부여한 테이블 EMPLOYEE의 특권을 회수하면 사용자 Smith가 Susan에게 부여한 같은 특권도 동시에 회수된다.
SQL> conn Peter/abcdef Connected SQL> REVOKE ALL ON EMPLOYEE FROM Smith;
데이터베이스를 관리하는 데 필요한 시스템 명령어를 사용하기 위해서는 시스템 특권을 부여받아야 한다. 시스템 특권은 기본적으로 SYS 사용자가 소유하고 있으며 다른 사용자에게 부여할 수 있다.
시스템 특권은 다음과 같다.
시스템 특권도 WITH ADMIN OPTION을 이용하여 다른 사용자에게 특권을 부여할 수 있다. 단, 특권을 부여할 때에는 해당 특권을 소유하고 있어야 한다.
다음은 시스템 특권을 가지고 있는 사용자 SYS가 Susan에게 WITH ADMIN OPTION과 함께 GRANT SELECT ANY TABLE 특권을 부여하는 예이다.
SQL> conn SYS/tibero Connected to Tibero. SQL> GRANT SELECT ANY TABLE TO Susan WITH ADMIN OPTION; Granted.
사용자 Susan은 SYS 사용자에게 부여 받은 시스템 특권을 다른 사용자에게 부여할 수 있는 권한이 생성된다. 즉, 다른 사용자에게 데이터베이스 내의 모든 테이블을 조회할 수 있는 특권을 부여할 수 있다는 의미이다.
WITH ADMIN OPTION과 함께 부여된 특권은 WITH GRANT OPTION과는 달리 연속적으로 회수되지 않는다.
다음은 사용자 Susan이 사용자 SYS로부터 부여받은 특권을 Peter에게 부여하는 예이다.
SQL> conn Susan/abcd Connected to Tibero. SQL> GRANT SELECT ANY TABLE TO Peter; Granted.
다음과 같이 Susan에게 부여한 시스템 특권을 회수하더라도 사용자 Susan이 Peter에게 부여한 시스템 특권은 그대로 유지된다.
SQL> conn SYS/tibero Connected to Tibero. SQL> REVOKE SELECT ANY TABLE FROM Susan;
Tibero에서는 특권의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있다. DBA나 일반 사용자 모두 사용할 수 있다.
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고한다.
다음은 부가적인 특권을 설정할 수 있는 파라미터에 대한 설명이다.
USE_TRUNCATE_PRIVILEGE
TRUNCATE 수행을 위해서 TRUNCATE ANY TABLE 시스템 특권 또는 TRUNCATE 스키마 객체 특권을 사용할 수 있다. 이 특권들을 사용하기 위해서는 USE_TRUNCATE_PRIVILEGE 파라미터를 'Y'로 설정해야 한다.
| 설정값 | 설명 |
|---|---|
| Y | TRUNCATE를 수행하기 위해서 자신의 스키마에 속한 테이블이 아닐 경우에는 TRUNCATE 특권이 부여되어야 한다. |
| N | TRUNCATE 수행을 위해 DROP ANY TABLE 시스템 특권이 부여되어 있어야 한다. |
GRANT ALL
GRANT ALL을 수행할 때 ALL 특권의 기준은 USE_TRUNCATE_PRIVILEGE 파라미터의 여부에 따라 다르다.
| 설정값 | 설명 |
|---|---|
| Y | GRANT ALL에 TRUNCATE 특권까지 포함된다. |
| N | GRANT ALL에 TRUNCATE 특권이 포함되지 않는다. |
REVOKE ALL
REVOKE ALL의 경우 시스템 특권과 스키마 객체 특권의 경우가 약간 다르게 동작한다. 시스템 특권의 경우에는 GRANT ALL과 마찬가지로 USE_TRUNCATE_PRIVILEGE 파라미터에 따라 취소되는 권한의 기준이 달라진다.
| 설정값 | 설명 |
|---|---|
| Y | REVOKE ALL 수행할 때 TRUNCATE ANY TABLE 특권까지 취소된다. |
| N | TRUNCATE ANY TABLE 특권은 취소되지 않는다. |
스키마 객체 특권의 경우에는 USE_TRUNCATE_PRIVILEGE 파라미터의 여부와 상관없이 TRUNCATE 스키마 객체 특권까지 취소된다.
데이터베이스 사용자의 패스워드 관리 정책을 지정할 수 있다.
예를 들어 사용자 1, 2, 3은 90일 후 패스워드 사용 기간이 만료되도록 설정하고 사용자 4, 5는 패스워드 사용 기간이 30일후 만료되며 한 번 사용한 패스워드는 재사용 못하도록 패스워드 사용 정책을 각각 다르게 설정할 필요가 있다고 가정하자.
이 경우 90일 후 패스워드 사용 기간이 만료되도록 설정한 프로파일과 30일 후 패스워드 사용 기간이 만료되며 한 번 사용한 패스워드는 재사용 못하도록 설정한 프로파일을 각각 생성하고 사용자 1, 2, 3은 첫 번째 프로파일을 사용하도록 지정하고 사용자 4, 5는 두 번째 프로파일을 사용하도록 지정하면 된다.
이처럼 프로파일은 사용자 패스워드 관리 정책을 다양하게 생성하고 각각의 사용자에게 특정 정책을 사용하도록 지정함으로써 사용자별로 그룹화된 패스워드 정책을 관리할 수 있는 기능을 제공한다.
다음은 프로파일을 생성하는 예이다.
SQL> CREATE PROFILE prof LIMIT
failed_login_attempts 3
password_lock_time 1/1440
password_life_time 90
password_reuse_time unlimited
password_reuse_max 10
password_grace_time 10
password_verify_function verify_function;
Profile 'PROF' created.
위 예제에서 보았듯이 프로파일을 생성, 변경할 때는 세부적인 파라미터를 지정할 수 있다.
각 파라미터에 대한 상세 설명은 SQL-참조 문서에 기술되어 있다. 참고로 각 파라미터의 기본값은 데이터베이스를 생성할 때 함께 생성된 DEFAULT 프로파일에 의해 결정되며 이 기본값들은 DBA_PROFILES 뷰를 통해 확인할 수 있다.
다음은 프로파일을 변경하는 예이다.
SQL> ALTER PROFILE prof LIMIT
password_lock_time 1
password_reuse_time 30;
Profile 'PROF' altered.
위의 SQL 문장이 실행되면 PROF이라는 프로파일의 패스워드가 오류 횟수를 초과하는 경우 계정 잠금 상태가 1일간 지속된다. 한 번 사용한 패스워드는 30개의 다른 패스워드를 사용한 이후에 다시 사용할 수 있다.
다음은 프로파일을 삭제하는 예이다.
SQL> DROP PROFILE prof CASCADE; Profile 'PROF' dropped.
삭제하려는 프로파일을 이미 사용자가 지정한 경우 반드시 cascade 옵션을 붙여야 한다. cascade 옵션을 사용하면 해당 프로파일을 지정한 모든 사용자의 프로파일 지정 정보를 일괄 삭제한다. 단, 사용자 정보는 삭제하지 않는다.
다음은 사용자 계정을 생성할 때 프로파일을 지정하는 예이다.
SQL> CREATE USER Peter IDENTIFIED BY abcd PROFILE prof; User 'PETER' created.
다음은 prof1 프로파일에서 Default 프로파일로 변경하는 예이다. Default 프로파일은 데이터베이스를 생성할 때 기본으로 함께 생성되는 프로파일이다.
SQL> ALTER USER Peter PROFILE default; User 'PETER' altered.
프로파일 관련 정보는 다음과 같이 확인할 수 있다.
SQL> select * from dba_profiles; PROFILE RESOURCE_NAME RESOURCE_TYPE LIMIT --------- ------------------------- ------------- --------------- DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD UNLIMITED DEFAULT PASSWORD_LIFE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL_VERIFY_FUNCTION DEFAULT PASSWORD_LOCK_TIME PASSWORD 1 DEFAULT PASSWORD_GRACE_TIME PASSWORD UNLIMITED DEFAULT LOGIN_PERIOD PASSWORD UNLIMITED 16 rows selected.
다음은 사용자별로 적용된 프로파일 정보를 조회하는 예이다. PETER라는 사용자에 T_PROF라는 프로파일이 할당된 상황을 확인할 수 있다.
SQL> select username, profile from dba_users; USERNAME PROFILE ---------- ---------- USER1 PETER T_PROF OUTLN SYSGIS SYSCAT SYS 6 rows selected.
Tibero에서는 Password를 설정할 때 보안성을 위해 Verify _function으로 Password 설정에 제한을 둘 수 있다.
다음은 Default Verify_function을 사용하는 경우 발생하는 에러에 대한 설명이다.
-20001: Password same as user.
유저이름과 비밀번호가 달라야한다.
-20002: Password length less than 4.
비밀번호 길이가 4 이상이어야 한다.
-20003: Password too simple.
비밀번호가 예상하기 쉬운 단어이면 안된다. Default에서 설정된 단어(welcome, database, account, 'user', 'password', 'tibero', 'computer', 'abcd')는 설정할 수 없다.
-20004: Password should contain at least one digit, one character and one punctuation.
비밀번호가 숫자, 문자, 특수문자가 적어도 1개씩 포함해야 한다.
-20005: Password should differ by at least 3characters.
바로 이전의 비밀번호와 적어도 3개 이상 달라야 한다.
사용자는 데이터베이스와 관련된 애플리케이션 프로그램을 실행하려면 해당 스키마 객체에 대한 적절한 특권을 부여 받아야 한다. 예를 들어 20개의 테이블에 30명의 사용자가 접근하는 경우라면 DBA는 '20개 테이블 X 30명의 사용자'로 계산된 총 600번의 특권을 부여하는 작업을 수행해야 한다.
특권은 시간을 필요로 하는 작업이다. 따라서 특권의 효율적인 관리를 위해 DBA가 부여할 특권을 모아놓은 역할을 미리 정의한다면 600번의 특권 부여 작업을 실행할 필요가 없고 특권의 관리가 훨씬 더 간편해진다.
역할(Role)은 여러 특권을 모아 놓은 것이며 하나의 단위로서 사용자에게 부여할 수 있다. 역할을 생성하거나 변경, 부여하기 위해서는 이에 맞는 특권이 필요하다.
다음은 역할을 생성하거나 변경, 특권을 부여하는 예이다.
SQL> conn SYS/tibero Connected to Tibero. SQL> GRANT CREATE ROLE, ALTER ANY ROLE, GRANT ANY ROLE TO Peter; Granted.
위의 예에서는 사용자 SYS로 접속하여 사용자 Peter에게 CREATE ROLE, ALTER ANY ROLE, GRANT ANY ROLE 특권을 부여하고 있다.
다음은 역할을 생성하는 예이다.
SQL> CREATE ROLE APP_USER; Role 'APP_USER' created. SQL> GRANT CREATE SESSION TO APP_USER; Granted. SQL> CREATE ROLE CLERK; Role 'CLERK' created. SQL> GRANT SELECT, INSERT ON Peter.EMPLOYEE TO CLERK; Granted. SQL> GRANT SELECT, INSERT ON Peter.TIME_CARDS TO CLERK; Granted. SQL> GRANT SELECT, INSERT ON Peter.DEPARTMENT TO CLERK; Granted.
다음은 본 예제를 기준으로 생성된 역할을 설명한다.
| 역할 | 설명 |
|---|---|
| APP_USER | CREATE ROLE 문을 사용하여 역할 APP_USER를 생성한다. 시스템 특권인 CREATE SESSION 문이 역할 APP_USER에 부여된다. APP_USER 역할을 부여받은 사용자는 데이터베이스에 접속할 수 있다. |
| CLERK | CREATE ROLE 문을 사용하여 CLERK 역할을 생성한다. 여러 개의 테이블에 스키마 객체 특권이 부여된다.
|
역할을 다른 역할에게 부여할 수 있다.
예를 들면 다음과 같이 역할 APP_USER를 역할 CLERK에 부여할 수 있다.
SQL> GRANT APP_USER TO CLERK; Granted.
위의 SQL 문장이 실행되면 역할 CLERK을 부여 받은 사용자에게 동시에 역할 APP_USER가 부여되고 역할 CLERK과 APP_USER에 양쪽에 포함된 모든 특권을 사용할 수 있게 된다.
역할을 부여 받은 사용자는 그 역할을 다른 사용자에게 다시 부여할 수 있다. 단, 역할을 부여하는 사용자가 그 역할을 다음과 같이 WITH ADMIN OPTION과 함께 부여 받아야 한다.
SQL> GRANT CLERK TO Susan WITH ADMIN OPTION; Granted. SQL> GRANT CLERK TO Peter; Granted.
위의 GRANT 명령이 실행되면, 사용자 Susan은 부여된 역할을 다시 다른 사용자에게 부여할 수 있으며 그 사용자로부터 역할을 회수할 수도 있다. 하지만 사용자 Peter는 CLERK 역할을 사용만 할 뿐 그 역할을 다시 다른 사용자에게 부여하거나 회수하지는 못 한다.
다른 사용자로부터 역할을 회수시키기 위해서는 REVOKE 명령을 사용해야 한다. DBA는 자신이 직접 부여하지 않은 역할에 대해서도 다른 사용자로부터 회수할 수 있다.
다음은 사용자 Peter와 역할 CLERK으로부터 역할 APP_USER를 회수하는 예이다.
REVOKE APP_USER FROM Peter; REVOKE APP_USER FROM CLERK;
위의 예에서는 회수 대상이 사용자든 역할이든 문법은 동일하다.
Tibero에서는 빈번하게 사용되는 시스템 특권을 모아 다음과 같은 역할로 미리 정의하고 있다.
사용자에게 부여한 역할은 한 세션 내에서 SET ROLE 명령을 사용함으로써 동적으로 활성화하거나 비활성화할 수 있다.
예를 들어 사용자가 CLERK, RESOURCE, APP_USER 역할을 가지고 있다면 다음과 같은 명령을 사용하여 이 중 필요한 역할만을 활성화할 수 있다.
SET ROLE CLERK, RESOURCE; /* CLERK, RESOURCE 역할을 활성화한다. */ SET ROLE ALL EXCEPT CLERK; /* CLERK를 제외한 모든 역할을 활성화한다. */ SET ROLE ALL; /* 모든 역할을 활성화한다. */ SET ROLE NONE; /* 모든 역할을 비활성화한다. */
역할의 활성화와 비활성화는 사용자의 특권을 효율적으로 제어하는 데에 매우 유용하다. 사용자에게 애플리케이션 프로그램을 실행할 때에만 특정한 특권을 부여하길 원한다면 SET ROLE 명령을 사용하여 프로그램의 시작과 동시에 그 특권이 포함된 역할을 사용할 수 있도록 활성화하고, 프로그램 종료 직전에 그 역할의 사용을 중지시키기 위해 비활성화한다.
사용자가 처음으로 세션에 접속할 때에 활성화 되는 역할을 그 사용자의 기본 역할이라고 한다. 새로 생성한 사용자는 처음에 기본 역할이 ALL로 설정된다. 즉, 사용자에게 부여하는 모든 역할이 기본적으로 활성화된다. 사용자의 기본 역할은 ALTER USER 문을 이용하여 바꿀 수 있으며, 그 형식은 SET ROLE 명령과 비슷하다.
예를 들면 다음과 같다.
ALTER USER Park DEFAULT ROLE CLERK, RESOURCE; ALTER USER Park DEFAULT ROLE ALL EXCEPT CLERK; ALTER USER Park DEFAULT ROLE ALL; ALTER USER Park DEFAULT ROLE NONE;
Tibero에서는 역할의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있다. DBA나 일반 사용자 모두 사용할 수 있다.
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고한다.
네트워크 접속 제어(NAC: Network Access Control)는 허가되지 않은 사용자나 보안 문제를 가진 사용자의 네트워크 접속을 차단하고 제어하는 네트워크 보안 기술이다. Tibero는 이러한 기술을 채택함으로써 기업 내 IT 자산을 보다 효과적으로 보호할 수 있다.
Tibero에서 제공하는 네트워크 접속 제어는 네트워크 보안의 범위에 따라 크게 두 가지로 나뉜다.
클라이언트 전체의 네트워크 접속을 차단하거나 허용한다.
클라이언트의 IP 주소에 따라 네트워크 접속을 차단하거나 허용한다.
전체 네트워크 접속 제어는 클라이언트 전체를 더는 TCP/IP 네트워크로 접속하지 못하게 하거나 또는 접속할 수 있도록 하는 방법이다.
다음은 클라이언트 전체의 네트워크 접속을 허용하는 방법으로 Tibero 서버를 처음 기동시킬 때와 같은 상태이다.
ALTER SYSTEM LISTENER REMOTE ON;
다음은 클라이언트 전체의 네트워크 접속을 차단하는 방법이다.
ALTER SYSTEM LISTENER REMOTE OFF;
위 명령을 실행하면 외부 클라이언트의 네트워크 접속은 차단되지만 로컬 호스트에서 접속하는 클라이언트의 네트워크 접속은 여전히 허용된다. 이때 로컬 호스트의 tbdsn.tbr 파일에서 IP 주소가 'localhost'라고 설정된 경우에만 해당되며, 이미 접속된 클라이언트는 계속 유지된다.
단, Windows에서 위 명령을 실행하면 로컬 호스트에서 로컬 호스트로 접속이 차단된다. 따라서 Windows에서 위 명령을 실행한 후 DB 서버에 접속하려면 special port로 접속해야 한다.
IP 주소 기반 네트워크 접속 제어는 초기화 파라미터에 설정된 IP 주소에 따라 클라이언트의 네트워크 접속을 허용하거나 차단하는 방법이다.
LSNR_INVITED_IP
이 방법은 특정한 IP 주소를 갖는 클라이언트의 네트워크 접속은 허용되지만 그 밖의 접속은 차단하는 경우에 사용한다.
하나의 IP 주소는 'IP 주소/서브넷 마스크의 bit 수'와 같은 형식으로 표현된다.
여러 개의 IP 주소를 설정하는 경우에는 각 IP 주소를 세미콜론(;)으로 구분하여 표기한다.
서브넷 마스크의 bit 수가 32인 경우에는 표기를 생략할 수 있다. 위의 예제에서 192.168.1.1은 192.168.1.1/32와 같은 의미이다.
예: 192.168.2.0/24
192.168.2.0/24는 서브넷 마스크의 bit 수가 24bits이므로, 255.255.255.0과 같은 서브넷 마스크를 의미한다. 따라서 192.168.2.xxx의 IP 주소를 갖는 모든 클라이언트의 네트워크 접속을 허용한다는 의미이다.
다음은 LSNR_INVITED_IP 초기화 파라미터를 이용하여
클라이언트의 네트워크 접속을 허용하는 방법이다.
<$TB_SID.tip>
LSNR_INVITED_IP=192.168.1.1;192.168.2.0/24;192.1.0.0/16
LSNR_INVITED_IP의 최대 길이는 255자이다. 256 이상의 IP 주소를 설정할 경우에는 LSNR_INVITED_IP_FILE을 사용한다.
LSNR_INVITED_IP_FILE
이 방법은 특정 파일에 접속을 허용하는 IP 주소 목록을 기재한 후 해당 파일의 절대 경로를 적어주면 그 파일을 읽어서 INVITED_IP를 설정한다.
하나의 IP 주소는 'IP 주소/서브넷 마스크의 bit 수'와 같은 형식으로 표현된다.
여러 개의 IP 주소를 설정하는 경우에는 한 라인에 1개의 IP 주소를 설정한다.
설정할 수 있는 파일의 최대 크기는 8M이다.
다음은 LSNR_INVITED_IP_FILE 초기화 파라미터를
이용하여 클라이언트의 네트워크 접속을 허용하는 방법이다.
</home/tibero/invited_ip.txt>
192.168.1.1 192.168.2.0/24 192.1.0.0/16
<$TB_SID.tip>
LSNR_INVITED_IP_FILE=/home/tibero/invited_ip.txt
LSNR_DENIED_IP
이 방법은 특정한 IP 주소를 갖는 클라이언트의 네트워크 접속은 차단되지만 그 밖의 접속은 허용하는 경우에 사용한다.
LSNR_INVITED_IP 초기화 파라미터의 설정 방법과 동일하다.
다음은 LSNR_DENIED_IP 초기화 파라미터를 이용하여
클라이언트의 네트워크 접속을 차단하는 방법이다.
<$TB_SID.tip>
LSNR_DENIED_IP=192.168.1.1;192.168.2.0/24;192.1.0.0/16
LSNR_DENIED_IP_FILE
이 방법은 특정 파일에 접속을 허용하지 않는 IP 주소 목록을 기재한 후 해당 파일의 절대 경로를 적어주면 그 파일을 읽어서 DENITED_IP를 설정한다.
LSNR_INVITED_IP_FILE 초기화 파라미터의 설정 방법과 동일하다.
LSNR_INVITED_IP와 LSND_DENIED_IP 파라미터는 다음과 같은 특징이 있다.
$TB_SID.tip 파일에
LSNR_INVITED_IP와
LSNR_DENIED_IP가 모두 설정되어 있는 경우
LSNR_DENIED_IP의 설정은 무시되며
LSNR_INVITED_IP만 적용된다. 즉,
LSNR_INVITED_IP에 설정된 IP 주소의 클라이언트를 제외하고는 모든 접속이
차단된다.
$TB_SID.tip 파일에
LSNR_INVITED_IP와
LSNR_DENIED_IP가 모두 설정되지 않은 경우 모든 클라이언트의 네트워크
접속이 허용된다.
루프백 주소(loopback address, 127.0.0.1)에서 접속하는 경우
LSNR_INVITED_IP 또는
LSNR_DENIED_IP의 설정과는 무관하게 항상 허용된다.
Tibero 서버를
운영하는 중에 서버를 다시 기동하지 않고 LSNR_INVITED_IP 또는
LSNR_DENIED_IP의 설정을 변경하려는 경우 우선 $TB_SID.tip 파일에
LSNR_INVITED_IP 또는
LSNR_DENIED_IP의 설정을 변경한 후 파일을 저장하고 다음의 명령을
실행한다.
alter system listener parameter reload;
위의 명령을 실행하면 $TB_SID.tip 파일에서
LSNR_INVITED_IP 또는
LSNR_DENIED_IP의 내용을 다시 읽어 변경된 내용을 실시간으로
적용한다.
해당 초기화 파라미터가 제대로 적용되었는지를 확인하기 위해서는 반드시 리스너의 트레이스 로그 파일의 내용을 확인해 볼 것을 권장한다.
감사(Auditing)는 데이터베이스 내에서 지정된 사용자의 동작을 기록하는 보안 기술이다. 관리자는 감사 기능을 통해 특정 동작 또는 특정 사용자에 대해 별도의 로그를 남김으로써 데이터베이스를 보다 효과적으로 보호할 수 있다.
감사 기능은 감사의 대상에 따라 두 종류로 구분된다.
스키마 객체에 대한 감사
지정된 스키마 객체에 수행되는 모든 동작을 기록할 수 있다.
시스템 특권에 대한 감사
지정된 시스템 특권을 사용하는 모든 동작을 기록할 수 있다.
감사 기록(Audit Trail)을 남기고 싶은 사용자 또는 역할을 지정할 수 있으며, 성공한 동작 또는 실패한 동작에 대해서만 감사 기록을 남기도록 지정할 수 있다. 또한 세션별로 한 번만 감사 기록을 남기거나 동작이 수행될 때마다 감사 기록을 남기도록 지정할 수 있다.
감사를 설정하거나 해제하려면 AUDIT 또는 NOAUDIT 명령을 사용한다.
다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체를 감사하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 한다.
다음은 스키마 객체에 대한 감사를 설정하는 예이다.
SQL> AUDIT delete ON t BY SESSION WHENEVER SUCCESSFUL;
Audited.
위의 SQL 문장이 성공하면 테이블 t에 수행되는 모든 delete 문이 성공하는 경우에만 감사 기록을 남긴다.
Directory 객체에 대한 감사와 객체에 걸리는 Lock에 대한 감사는 지원하지 않는다.
시스템 특권을 감사하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 한다.
다음은 시스템 특권에 대한 감사를 설정하는 예이다.
SQL> AUDIT create table BY tibero;
Audited.
위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성하려고 할 때 그것이 성공하든 실패하든 관계없이 감사 기록을 남긴다.
시스템 특권에 관한 자세한 내용은 “5.2. 특권”을 참고한다.
시스템 특권의 감사를 해제하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 한다. 다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체의 감사를 해제하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 한다.
다음은 이미 설정된 감사를 해제하는 예이다.
SQL> NOAUDIT create table BY tibero; Noaudited.
위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성할 때 더 이상 감사 기록을 남기지 않는다.
SYS 사용자를 감사의 대상으로 지정할 수 없다. SYS 사용자에 대한 감사는 “5.6.3. SYS 사용자에 대한 감사”를 참고한다.
감사 기록(Audit Trail)은 명령을 수행한 사용자, 명령이 수행된 스키마 객체, 수행 시각, 세션 ID 등의 기본 정보와 실행된 SQL 문장으로 이루어진다.
감사 기록은 $TB_SID.tip 파일에 설정된 AUDIT_TRAIL 파라미터에 따라 데이터베이스 내부 또는 OS 파일에 저장할 수 있다. OS 파일에 감사 기록을 저장하는 경우 파일의 위치와 최대 크기를 각각 $TB_SID.tip 파일의 AUDIT_FILE_DEST 파라미터와 AUDIT_FILE_SIZE 파라미터로 설정할 수 있다.
다음은 감사 기록의 저장 위치를 지정하는 예이다.
<$TB_SID.tip>
AUDIT_TRAIL=DB_EXTENDED
위와 같이 설정하면 감사 기록에 포함되는 기본 정보뿐만 아니라 사용자가 실행한 SQL문장까지 데이터베이스에 저장된다.
<$TB_SID.tip>
AUDIT_TRAIL=OS
AUDIT_FILE_DEST=/home/tibero/audit/audit_trail.log
AUDIT_FILE_SIZE=10M
위와 같이 설정하면 "/home/tibero/audit/audit_trail.log"에 최대
10MB의 크기로 감사 기록이 저장된다.
다음은 저장된 감사 기록의 항목에 대한 설명이다.
| 항목 | 설명 |
|---|---|
| SERIAL_NO | 특정 세션을 식별할 수 있는 보조 키의 개념이다. 동시에 Active할 수 있는 세션의 개수는 한정적이며 그런 Active한 세션을 식별하는 것이 Session ID이다. Session ID는 세션을 식별하는데 한계가 있다. 예를 들어 1번 세션이 수행하다가 모든 수행을 마치고 Close된 다음 다시 Open되어 수행한다고 했을 때 단순히 Session ID만 가지고는 1번 세션이 수행한 두 개의 작업을 식별할 수 없게 된다. 즉, 1번 세션이 Close하기 전에 수행한 세션과 다시 Open하여 수행한 이후 세션을 식별할 수 없다. 따라서 이를 위해 부가적인 정보가 필요한데 그것이 Serial Number(SERIAL_NO)이다. 이 숫자는 세션이 다시 열리거나 재사용될 때 증가되어 Session ID와 붙여서 특정 세션을 식별할 수 있게 된다. |
| AUD_NO | 세션이 열린 다음 기록된 Audit 엔트리의 순차적인 번호이다. |
| STMT_ID | Audit을 남기게 한 Statement를 파싱하여 나온 Physical Plan의 내부적인 PPID이다. |
| CLIENT_ID | Tibero에 접속하여 명령을 수행하도록 한 클라이언트의 이름이다(Client Name으로 명명하는 것이 더 정확할 수도 있다). |
| PRIV_NO | 해당 Statement를 수행하는 데에 필요한 Privilege 번호이다. 내부적으로 음수는 System privileges(SELECT_ANY_TABLE 등의 ANY 시리즈), 양수는 Object Privilege(select on t1에서 select)를 의미한다. |
| ACTION | 해당 Statement가 결국 성공했는지 여부를 나타내는 컬럼이다.
|
| USGMT_ID | 현재 트랜잭션을 위한 Undo를 기록한 Undo Segment ID이다. |
| SLOTNO | Undo Segment에 위치한 Slot들 중 어떤 Slot 인지를 식별할 수 있는 값이다. 트랜잭션이 시작하면 우선 Undo segment에서 Slot 하나를 할당받아야 한다. 따라서 Undo Segment와 Slot Number를 이용하여 현재 Active한 트랜잭션들을 식별할 수 있다. |
| WRAPNO | SERIAL_NO가 세션을 위한 부가적인 정보였다면 WRAPNO는 트랜잭션을 위한 부가적인 정보이다. 트랜잭션이 커밋되고, 또 다른 트랜잭션이 해당 Slot을 재사용하게 되면 이 값이 증가하게 된다. 따라서 3개의 정보(USGMT_ID, SLOTNO, WRAPNO)를 이용하면 과거에 수행되었던 모든 트랜잭션을 포함하여 하나의 트랜잭션을 식별할 수 있게 된다. |
AUDIT_TRAIL이 OS일 경우 로그의 형태로 Audit를 남기고, DB 또는 DB_EXTENDED일 경우에는 SYS._DD_AUD 테이블에 Insert를 하여 View 형태로 보여준다.
1. $TB_SID.tip 파일 설정에 관한 자세한 내용은 "Tibero 참조 안내서"를 참고한다.
2. SYS 사용자에 대한 감사 기록은 데이터베이스에 저장되지 않는다. SYS 사용자에 대한 감사는 “5.6.3. SYS 사용자에 대한 감사”를 참고한다.
감사 기록은 OS 파일 또는 데이터베이스에 저장된다. OS 파일에 저장하도록 설정한 경우 일반 텍스트 파일의 형태로 저장되므로 쉽게 내용을 열람할 수 있다. 데이터베이스에 저장하도록 설정한 경우에는 다음의 정적 뷰를 통해 감사 기록을 조회할 수 있다.
| 정적 뷰 | 설명 |
|---|---|
| DBA_AUDIT_TRAIL | 데이터베이스에 저장된 모든 감사 기록을 조회하는 뷰이다. |
| USER_AUDIT_TRAIL | 데이터베이스에 저장된 현재 사용자의 감사 기록을 조회하는 뷰이다. |
1. 정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고한다.
2. 정적 뷰에서 제공하는 정보는 제한적으로 지원한다.
SYS 사용자의 명령은 보안 상의 이유로 다른 사용자의 명령과는 다른 방식으로 감사된다. SYS 사용자는 기본적으로 감사의 대상에서 제외되기 때문에 AUDIT 또는 NOAUDIT 명령을 사용해 감사를 설정 또는 해제할 수 없다.
SYS 사용자의 명령을 감사하기 위해서는 $TB_SID.tip 파일의 AUDIT_SYS_OPERATIONS 파라미터를 'Y'로 설정해야 한다. SYS 사용자의 명령을 감사하도록 설정하면 수행한 모든 동작이 OS 파일에 기록되며 보안 상의 이유로 데이터베이스에는 기록되지 않는다.
다음은 SYS 사용자의 동작을 감사하도록 설정한 예이다.
<$TB_SID.tip>
AUDIT_SYS_OPERATIONS=Y
AUDIT_FILE_DEST=/home/tibero/audit/audit_trail.log
AUDIT_FILE_SIZE=10M
위와 같이 설정하면 SYS 사용자가 수행한 모든 동작이 "/home/tibero/audit/audit_trail.log"에 최대
10MB의 크기로 저장된다.