사용자 관리와 데이터베이스 보안
Tibero의 데이터베이스 보안을 위한 사용자 계정과 사용자의 특권(Privilege)및 역할(Role) 등 을 효율적으로 관리하고 데이터베이스 사용을 감시(Audit)하기 위한 방법을 설명합니다.
사용자 관리
Tibero 내부의 데이터에 접근하기 위해서는 사용자 계정(Account)이 필요합니다. 각 계정은 패스워드(Pass word)를 통해 보안이 유지됩니다. 패스워드는 사용자 계정을 생성할 때 설정하며, 생성된 이후에 변경할 수 있습니다. Tibero는 패스워드를 데이터 사전(Data Dictionary)에 암호화된 형태로 저장합니다.
Tibero에서 하나의 사용자 계정은 하나의 스키마를 가지며 스키마의 이름은 사용자의 이름과 같습니다.
참고
스키마(Schema)는 테이블, 뷰, 인덱스 등의 스키마 객체(Schema object)의 묶음입니다.
특정 스키마에 속한 스키마 객체를 나타내려면 다음과 같이 입력합니다.
사용자 계정.스키마 객체다음은 tibero라는 사용자 계정으로 접속하여 SYS 사용자의 SYSTEM_PRIVILEGES에 접근하는 예입니다.
$ tbsql tibero/tmax
tbSQL 7
TmaxData Corporation Copyright (c) 2008-. All rights reserved.
Connected to Tibero.
SQL> SELECT * FROM SYS.SYSTEM_PRIVILEGES;
...다음은 스키마 객체 앞에 특정한 사용자 계정을 명시하지 않았을 경우의 예입니다.
사용자 계정이 생략되면 스키마 객체에 접근할 때 다음과 같은 과정을 거친다.
사용자 자신이 소유한 스키마 객체 중에 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에 접속하는 방법은 다음과 같습니다.
SYS 사용자는 DBA의 역할이 부여된 만큼 될 수 있으면 다른 사용자 계정을 사용할 것을 권장합니다.
사용자 생성
사용자를 생성할 때에는 데이터베이스 보안 정책에 따라 적당한 특권을 가진 사용자 계정을 생성합니다. 사용자를 생성하는 방법은 다음과 같습니다.
① CREATE USER 문을 사용하여 Steve라는 사용자를 생성합니다.
② 사용자 Steve의 패스워드를 dsjeoj134로 설정합니다. CREATE USER 문을 사용할 때에는 반드시 패스 워드를 설정해야 합니다. 만약 패스워드에 특수문자를 사용할 경우 "dsjeoj134!"와 같이 큰따옴표로 묶어야 합니다.
③ 디폴트 테이블 스페이스를 USR로 설정합니다.
다음은 데이터베이스 보안 정책에 따른 사용자를 동일한 방법으로 여러 사용자를 생성하는 예입니다.
위와 같이 테이블 스페이스를 지정하지 않으면 자동으로 시스템 테이블 스페이스를 사용하게 됩니다. 새로 생성된 사용자는 아무런 특권을 가지지 않으며 데이터베이스에 접속할 수 없습니다. 데이터베이스에 접속하 기 위해서는 CREATE SESSION 시스템 특권이나 이를 포함하는 역할을 부여 받아야 합니다.
다음은 생성된 사용자에게 특권을 할당하는 예입니다. 자세한 내용은 “특권”을 참고합니다.
사용자 변경
사용자에게 설정된 패스워드, 테이블 스페이스 등을 변경하는 방법은 다음과 같습니다.
① ALTER USER 문을 사용하여 Peter라는 사용자의 정보를 변경합니다.
② 사용자 Peter의 패스워드를 abcdef로 변경합니다.
③ 테이블 스페이스를 SYSTEM 테이블 스페이스로 변경합니다.
사용자 제거
사용자를 제거하는 방법은 다음과 같습니다.
DROP USER user_name
DROP USER 문을 통해 user_name에 설정된 사용자를 제거
CASCADE
DROP USER 문의 옵션 중 하나인 CASCADE는 사용자를 제거하기 전에 그 사용자의 모든 스키마 객체를 제거
CASCADE 옵션을 사용하지 않으면 해당 사용자가 아무런 스키마 객체를 가지고 있지 않을 경우에만 사용자를 제거할 수 있음
제거된 사용자의 스키마 객체를 참조하는 뷰나 동의어, 프시저, 함수는 모두 INVALID 상태가 됨
나중에 동일한 이름의 다른 사용자가 만들어지면 새로운 사용자는 그 이름을 가졌던 이전 사용자로부터 아무것도 상속받지 못함
다음은 John 이라는 사용자를 제거하는 예입니다.
사용자 정보 조회
Tibero에서는 사용자의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다. DBA나 일반 사 용자 모두 사용할 수 있습니다.
ALL_USERS
데이터베이스의 모든 사용자의 기본적인 정보를 조회하는 뷰
DBA_USERS
데이터베이스의 모든 사용자의 자세한 정보를 조회하는 뷰
USER_USERS
현재 사용자의 정보를 조회하는 뷰
참고
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고합니다.
사용자 계정 잠금 및 해제
데이터베이스 사용자가 계정에 접속할 수 없도록 계정을 잠금 상태로 설정하거나 잠금 상태를 해제할 수 있습니다.
계정 잠금 상태에서 해당 계정에 접속을 시도하면 다음과 같은 오류 코드와 함께 접속이 중단됩니다.
계정 잠금을 해제하려면 다음의 SQL을 수행합니다.
프로파일 설정에 따라 패스워드 사용 기한이 만료되거나 패스워드 오류 횟수 초과 등으로 계정 잠금 상태 가 된 경우에도 동일한 방법으로 잠금을 해제할 수 있습니다.
운영체제(OS) 인증을 사용한 사용자 생성
사용자 생성은 보안 정책에 따라 데이터베이스 보안 정책을 따르는 사용자 생성과 운영체제(OS) 인증 정 책을 따르는 사용자 생성으로 구분됩니다.
운영체제(OS) 인증을 사용하는 사용자 계정은 다음과 같이 생성할 수 있습니다.
① CREATE USER 문을 사용하여 OS 사용자인 Steve라는 사용자를 생성하는데 OS 인증 정책 사용자를 알리는 OSA$ prefix를 붙여 생성합니다. 해당 값은 OS_AUTH_PREFIX에서 변경할 수 있으며, 기본값은 OSA$입니다.
② OS 인증을 사용하는 사용자 OSA$Steve의 패스워드는 데이터베이스에서 별도로 관리하지 않습니다. 즉, OS의 사용자 Steve가 존재하는 경우 host에서 인증을 완료한 것으로 가정하여 데이터베이스에서 별도로 확인하지 않습니다(OS의 보안이 취약한 경우에는 사용을 권하지 않습니다).
OS 인증 사용자 생성 이후 로컬에서 접속하는 방법은 다음과 같습니다.
참고
원격에서 OS 인증 사용자 접속은 보안상의 문제로 지원하지 않습니다.
특권
사용자가 데이터베이스의 특정 스키마 객체에 접근하려면 특권(Privilege)을 부여 받아야 합니다. 특권을 부 여받으면 허용된 스키마 객체에 SQL 문장 등을 실행할 수 있습니다.
다음은 사용자에게 특권을 부여하는 예입니다.
① Peter라는 사용자 계정으로 데이터베이스에 접속합니다.
② CREATE TABLE 문을 사용하여 EMPLOYEE 테이블을 생성합니다. 총 3개의 컬럼(ID, EMPLOYEE_NAME, ADDRESS)을 생성합니다.
③ Smith라는 사용자가 Peter 사용자가 생성한 EMPLOYEE 테이블에 GRANT 명령을 실행하여 SELECT 특권을 부여합니다.
이제 사용자 Smith는 Peter의 EMPLOYEE 테이블을 조회할 수 있습니다. PUBLIC 사용자에게 특권을 부여할 수 있는데 존재하는 모든 사용자에게 특권을 부여한 것과 동일한 효과를 갖습니다다. 특권을 효율적으로 관리하기 위해 특권의 집합인 역할을 생성합니다. 동일한 특권을 부여해야 할 사용자가 많은 경우 역할을 이용함 으로써 GRANT 명령의 사용 횟수를 줄일 수 있습니다. 특권과 마찬가지로 역할도 PUBLIC 사용자에게 부여하 면 모든 사용자에게 역할을 부여한 것과 동일한 효과를 갖습니다다.
Tibero에서 제공하는 특권은 크게 두 가지로 나뉩니다.
스키마 객체 특권(Schema Object Privilege) 특정 객체에 대한 질의 및 갱신 특권입니다.
시스템 특권(System Privilege) 데이터베이스에서 특정 작업을 수행할 수 있는 특권입니다.
스키마 객체 특권
스키마 객체 특권은 스키마 객체인 테이블, 뷰, 시퀀스, 동의어 등에 접근하는 것을 제어하는 권한입니다.
스키마 객체 특권은 GRANT 명령을 사용해 다른 사용자에게 부여할 수 있으며, 그 내용은 데이터 사전에 기록됩니다.
SELECT
테이블을 조회하는 권한
INSERT
테이블에 로우를 삽입하는 권한
UPDATE
테이블에 로우를 갱신하는 권한
DELETE
테이블에 로우를 삭제하는 권한
ALTER
스키마 객체의 특성을 변경하는 권한
INDEX
테이블에 인덱스를 생성하는 권한
REFERENCES
테이블을 참조하는 제약조건을 생성하는 권한
TRUNCATE
테이블에 TRUNCATE를 수행할 수 있는 권한
이 권한을 사용하려면 USE_TRUNCATE_PRIVILEGE 파라미터를 'Y'로 설정해야
스키마 객체 특권 부여
다음은 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과 Park에게도 다음과 같은 특권을 할당합니다.
스키마 객체 특권 회수
다른 사용자로부터 스키마 객체 특권을 회수하기 위해서는 REVOKE 명령을 사용해야 합니다. 이 명령은 사 용자의 스키마 객체 특권의 일부 또는 전체를 회수할 수 있습니다. DBA는 자신이 직접 부여하지 않는 특권에 대해서도 다른 사용자로부터 회수할 수 있습니다.
다음은 각각 Peter로부터 테이블 EMPLOYEE에 대한 DELETE 특권을 회수하고 John으로부터 모든 특권 을 회수하는 예입니다.
WITH GRANT OPTION과 함께 부여된 특권을 회수할 때에는 연속적으로 특권이 회수됩니다.
다음은 Peter로부터 부여받은 Peter.EMPLOYEE에 대한 특권을 사용자 Smith가 Susan에게 부여하는 예 입니다.
사용자 Peter가 다음과 같이 Smith에게 부여한 테이블 EMPLOYEE의 특권을 회수하면 사용자 Smith가 Susan에게 부여한 같은 특권도 동시에 회수됩니다.
시스템 특권
데이터베이스를 관리하는 데 필요한 시스템 명령어를 사용하기 위해서는 시스템 특권을 부여 받아야 합니다. 시스템 특권은 기본적으로 SYS 사용자가 소유하고 있으며 다른 사용자에게 부여할 수 있습니다.
시스템 특권은 다음과 같습니다.
ALTER SYSTEM
ALTER SYSTEM 문을 실행할 수 있는 권한
CREATE SESSION
데이터베이스에 세션을 생성할 수 있는 권한
즉, 로그인이 가능합니다는 것을 의미
CREATE USER
사용자를 생성하는 권한
ALTER USER
사용자의 정보를 변경하는 권한
DROP USER
사용자를 제거하는 권한
CREATE TABLESPACE
테이블 스페이스를 생성하는 권한
ALTER TABLESPACE
테이블 스페이스를 변경하는 권한
DROP TABLESPACE
테이블 스페이스를 제거하는 권한
SELECT ANY DICTIONARY
DICTIONARY를 조회할 수 있는 권한
이 권한을 할당 받 으면 SYS, SYSCAT, SYSGIS 소유의 객체들을 조회할 수 있음
CREATE TABLE
자신의 스키마에 테이블을 생성하는 권한
CREATE ANY TABLE
임의의 스키마에 테이블을 생성하는 권한
ALTER ANY TABLE
임의의 스키마에 속한 테이블을 변경하는 권한
DROP ANY TABLE
임의의 스키마에 속한 테이블을 제거하는 권한
COMMENT ANY TABLE
임의의 스키마에 속한 테이블에 주석을 추가하는 권한
SELECT ANY TABLE
임의의 스키마에 속한 테이블, 뷰, 실체화 뷰를 조회할 수 있는 권한
INSERT ANY TABLE
임의의 스키마에 속한 테이블 또는 동의어 테이블에 로우를 삽 입하는 권한
UPDATE ANY TABLE
임의의 스키마에 속한 테이블 또는 동의어 테이블의 로우를 갱 신하는 권한
DELETE ANY TABLE
임의의 스키마에 속한 테이블에 로우를 제거하는 권한
TRUNCATE ANY TABLE
임의의 스키마에 속한 테이블에 TRUNCATE를 수행할 수 있음
이 권한을 사용하기 위해서는 USE_TRUNCATE_PRIVILEGE 파라미터를 'Y'로 설정해야 함
CREATE ANY INDEX
임의의 스키마에 속한 테이블 또는 실제 객체 위에 인덱스를 생성하는 권한
ALTER ANY INDEX
임의의 스키마에 속한 테이블의 인덱스를 수정하는 권한
DROP ANY INDEX
임의의 스키마에 속한 인덱스를 삭제하는 권한
CREATE SYNONYM
자신의 스키마에 동의어를 생성하는 권한
CREATE ANY SYNONYM
임의의 스키마에 동의어를 생성하는 권한
DROP ANY SYNONYM
임의의 스키마에 속한 동의어를 제거하는 권한
SYSDBA
SHUTDOWN, ALTER DATABASE, CREATE DATABASE, ARCHIVELOG, RECOVERY 같은 명령을 할 수 있는 권한
CREATE PUBLIC SYNONYM
PUBLIC 스키마에 동의어를 생성하는 권한
DROP PUBLIC SYNONYM
PUBLIC 스키마에 속한 동의어를 제거하는 권한
CREATE VIEW
자신의 스키마에 뷰를 생성하는 권한
CREATE ANY VIEW
임의의 스키마에 뷰를 생성하는 권한
DROP ANY VIEW
임의의 스키마에 속한 뷰를 제거하는 권한
CREATE MATERIALIZED VIEW
자신의 스키마에 실체화 뷰를 생성하는 권한
CREATE ANY MATERIALIZED VIEW
임의의 스키마에 실체화 뷰를 생성하는 권한
ALTER ANY MATERIALIZED VIEW
임의의 스키마에 속한 실체화 뷰를 변경하는 권한
DROP ANY MATERIALIZED VIEW
임의의 스키마에 속한 실체화 뷰를 제거하는 권한
CREATE SEQUENCE
자신의 스키마에 시퀀스를 생성하는 권한
CREATE ANY SEQUENCE
임의의 스키마에 시퀀스를 생성하는 권한
ALTER ANY SEQUENCE
임의의 스키마에 속한 시퀀스를 변경하는 권한
DROP ANY SEQUENCE
임의의 스키마에 속한 시퀀스를 제거하는 권한
SELECT ANY SEQUENCE
임의의 스키마에 속한 시퀀스에서 시퀀스 값을 얻어오는 권한
CREATE ROLE
역할을 생성하는 권한
DROP ANY ROLE
임의의 역할을 제거하는 권한
GRANT ANY ROLE
역할을 부여하는 권한
ALTER ANY ROLE
임의의 역할을 변경하는 권한
ALTER DATABASE
데이터베이스를 변경하는 권한
CREATE PROCEDURE
자신의 스키마에 PSM을 생성하는 권한
CREATE ANY PROCEDURE
임의의 스키마에 PSM을 생성하는 권한
ALTER ANY PROCEDURE
임의의 스키마에 속한 PSM을 변경하는 권한
DROP ANY PROCEDURE
임의의 스키마에 속한 PSM을 제거하는 권한
EXECUTE ANY PROCEDURE
임의의 스키마에 속한 PSM을 실행하는 권한
CREATE TRIGGER
자신의 스키마에 속한 트리거를 생성하는 권한
CREATE ANY TRIGGER
임의의 스키마에 속한 트리거를 생성하는 권한
ALTER ANY TRIGGER
임의의 스키마에 속한 트리거를 변경하는 권한
DROP ANY TRIGGER
임의의 스키마에 속한 트리거를 제거하는 권한
GRANT ANY OBJECT PRIVILEGE
모든 스키마 객체에 대한 특권을 가지는 권한
GRANT ANY PRIVILEGE
모든 특권을 전부 부여할 수 있는 권한
REFRESH ANY CACHE GROUP
임의의 스키마에 속한 캐시 그룹을 비울 수 있는 권한
시스템 특권 부여
시스템 특권도 WITH ADMIN OPTION을 이용하여 다른 사용자에게 특권을 부여할 수 있습니다. 단, 특권을 부여할 때에는 해당 특권을 소유하고 있어야 합니다.
다음은 시스템 특권을 가지고 있는 사용자 SYS가 Susan에게 WITH ADMIN OPTION과 함께 GRANT SELECT ANY TABLE 특권을 부여하는 예입니다.
사용자 Susan은 SYS 사용자에게 부여 받은 시스템 특권을 다른 사용자에게 부여할 수 있는 권한이 생성 됩니다. 즉, 다른 사용자에게 데이터베이스 내의 모든 테이블을 조회할 수 있는 특권을 부여할 수 있습니다는 의미입니다.
시스템 특권 회수
WITH ADMIN OPTION과 함께 부여된 특권은 WITH GRANT OPTION과는 달리 연속적으로 회수되지 않습니다.
다음은 사용자 Susan이 사용자 SYS로부터 부여받은 특권을 Peter에게 부여하는 예입니다.
다음과 같이 Susan에게 부여한 시스템 특권을 회수하더라도 사용자 Susan이 Peter에게 부여한 시스템 특권은 그대로 유지됩니다.
특권 정보 조회
Tibero에서는 특권의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다. DBA나 일반 사용자 모두 사용할 수 있습니다.
DBA_SYS_PRIVS
사용자에게 부여된 모든 특권의 정보를 조회하는 뷰
USER_SYS_PRIVS
현재 사용자에게 부여된 특권의 정보를 조회하는 뷰
DBA_TBL_PRIVS
데이터베이스 내의 모든 스키마 객체 특권의 정보를 조회하는 뷰
USER_TBL_PRIVS
현재 사용자가 소유한 모든 스키마 객체 특권의 정보를 조회하는 뷰
ALL_TBL_PRIVS
현재 사용자가 소유한 모든 스키마 객체 특권과 모든 사용자가 사용할 수 있도록 공개한 모든 스키마 객체 특권의 정보를 조회하는 뷰
DBA_COL_PRIVS
데이터베이스 내의 모든 스키마 객체 특권 중 스키마 객체의 특정 컬럼 에 부여된 특권의 정보를 조회하는 뷰
USER_COL_PRIVS
현재 사용자가 소유한 스키마 객체 특권 중 스키마 객체의 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
ALL_COL_PRIVS
현재 사용자가 소유한 스키마 객체 특권 또는 모든 사용자가 사용할 수 있도록 공개한 모든 스키마 객체 특권 중 스키마 객체의 특정 컬럼에 부 여된 특권의 정보를 조회하는 뷰
USER_COL_PRIVS_MADE
현재 사용자 소유한 객체 중 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
ALL_COL_PRIVS_MADE
현재 사용자가 만든 특권 중 스키마 객체의 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
USER_COL_PRIVS_RECD
현재 사용자에게 부여된 모든 스키마 객체 특권 중 스키마 객체의 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
ALL_COL_PRIVS_RECD
현재 사용자 또는 PUBLIC 사용자에게 부여된 모든 스키마 객체 특권 중 스키마 객체의 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
참고
정적 뷰에 대한 자세한 내용은 "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의 경우 USE_TRUNCATE_PRIVILEGE 파라미터의 여부와 상관없이 TRUNCATE 특권이 취소됨
프로파일
데이터베이스 사용자의 패스워드 관리 정책을 지정할 수 있습니다.
예를 들어 사용자 1, 2, 3은 90일 후 패스워드 사용 기간이 만료되도록 설정하고, 사용자 4, 5는 패스워드 사용 기간이 30일후 만료되며 한 번 사용한 패스워드는 재사용 못하도록 패스워드 사용 정책을 각각 다르 게 설정할 필요가 있습니다고 가정합니다. 이 경우 90일 후 패스워드 사용 기간이 만료되도록 설정한 프로파일 과 30일 후 패스워드 사용 기간이 만료되며 한 번 사용한 패스워드는 재사용 못하도록 설정한 프로파일을 각각 생성하고 사용자 1, 2, 3은 첫 번째 프로파일을 사용하도록 지정하고 사용자 4, 5는 두 번째 프로파일 을 사용하도록 지정합니다.
이처럼 프로파일은 사용자 패스워드 관리 정책을 다양하게 생성하고 각각의 사용자에게 특정 정책을 사 용하도록 지정함으로써 사용자별로 그룹화된 패스워드 정책을 관리할 수 있는 기능을 제공합니다.
프로파일 생성, 변경, 제거
다음은 프로파일을 생성하는 예입니다.
프로파일 파라미터 종류
위 예제에서 보았듯이 프로파일을 생성, 변경할 때는 세부적인 파라미터를 지정할 수 있습니다.
각 파라미터에 대한 상세 설명은 "Tibero SQL 참조 안내서"에 기술되어 있습니다. 참고로 각 파라미터의 기본 값은 데이터베이스를 생성할 때 함께 생성된 DEFAULT 프로파일에 의해 결정되며, 이 기본값들은 DBA_PROFILES 뷰를 통해 확인할 수 있습니다.
다음은 프로파일을 변경하는 예입니다.
위의 SQL 문장이 실행되면 PROF이라는 프로파일의 패스워드가 오류 횟수를 초과하는 경우 계정 잠금 상태가 1일간 지속됩니다. 또한 한 번 사용한 패스워드는 30일 동안 동일한 패스워드로 다시 변경할 수 없습니다.
다음은 프로파일을 삭제하는 예입니다.
삭제하려는 프로파일을 이미 사용자가 지정한 경우 반드시 cascade 옵션을 붙여야 합니다. casade 옵션을 사용하면 해당 프로파일을 지정한 모든 사용자의 프로파일 지정 정보를 일괄 삭제합니다. 단, 사용자 정보는 삭제하지 않습니다.
프로파일 지정
다음은 사용자 계정을 생성할 때 프로파일을 지정하는 예입니다.
다음은 prof1 프로파일에서 Default 프로파일로 변경하는 예입니다. Default 프로파일은 데이터베이스를 생성할 때 기본으로 함께 생성되는 프로파일입니다.
프로파일 정보 조회
프로파일 관련 정보는 다음과 같이 확인할 수 있습니다.
다음은 사용자별로 적용된 프로파일 정보를 조회하는 예입니다. PETER라는 사용자에 T_PROF라는 프로 파일이 할당된 상황을 확인할 수 있습니다.
PASSWORD_VERIFY_FUNCTION
Tibero에서는 Password를 설정할 때 보안성을 위해 PASSWORD_VERIFY_FUNCTION으로 Password 설정에 제한을 둘 수 있습니다.
다음은 Tibero에서 기본 제공하는 PASSWORD_VERIFY_FUNCTION과 그 유효 조건에 대한 설명입니다.
VERIFY_FUNCTION
비밀번호 길이가 4 이상이어야 함
비밀번호가 숫자, 문자, 특수문자를 적어도 1개씩 포함해야 함
사용자 이름과 비밀번호가 달라야 함
비밀번호가 예상하기 쉬운 단어이면 안됨
미리 설정되어 있는 단어('welcome', 'database', 'account', 'user', 'password', 'tibero', 'computer', 'abcd')는 설정할 수 없음
바로 이전의 비밀번호와 적어도 3개 이상 달라야 함
VERIFY_FUNCTION2
비밀번호 길이가 8 이상이어야 함
비밀번호가 숫자, 문자를 적어도 1개씩 포함해야 함
비밀번호가 사용자 이름을 포함할 수 없음
비밀번호가 사용자 이름을 역순으로 하여 포함할 수 없음
비밀번호가 DB 이름을 포함할 수 없음
비밀번호가 예상하기 쉬운 단어를 포함해서는 안됨
미리 설정되어 있는 단어('welcome', 'database', 'account', 'user', 'password', 'tibero', 'computer', 'abcd')를 포함할 수 없음
바로 이전의 비밀번호와 적어도 3개 이상 달라야 함
NULL_VERIFY_FUNCTION
비밀번호에 제약을 두지 않음
역할
사용자는 데이터베이스와 관련된 애플리케이션 프로그램을 실행하려면 해당 스키마 객체에 대한 적절한 특권을 부여 받아야 합니다. 예를 들어 20개의 테이블에 30명의 사용자가 접근하는 경우라면 DBA는 "20개 테이블 * 30명의 사용자"로 계산된 총 600번의 특권을 부여하는 작업을 수행해야 합니다.
특권은 시간을 필요로 하는 작업입니다. 따라서 특권의 효율적인 관리를 위해 DBA가 부여할 특권을 모아놓 은 역할을 미리 정의합니다면 600번의 특권 부여 작업을 실행할 필요가 없고 특권의 관리가 훨씬 더 간편해 진다.
역할(Role)은 여러 특권을 모아 놓은 것이며 하나의 단위로서 사용자에게 부여할 수 있습니다. 역할을 생성하 거나 변경, 부여하기 위해서는 이에 맞는 특권이 필요합니다.
역할 생성, 부여, 회수
다음은 역할을 생성하거나 변경, 특권을 부여하는 예입니다. 사용자 SYS로 접속하여 사용자 Peter에게 CREATE ROLE, ALTER ANY ROLE, GRANT ANY ROLE 특권을 부여하고 있습니다.
역할 생성
다음은 역할을 생성하는 예입니다.
다음은 본 예제를 기준으로 생성된 역할에 대한 설명입니다.
APP_USER
CREATE ROLE 문을 사용하여 역할 APP_USER를 생성
시스템 특권인 CREATE SESSION 문이 역할 APP_USER에 부여됨
APP_USER 역할을 부여받은 사용자는 데이터베이스에 접속할 수 있음
CLERK
CREATE ROLE 문을 사용하여 CLERK 역할을 생성합니다.여러 개의 테이블에 스키마 객체 특권이 부여됨
Peter 스키마에 속한 EMPLOYEE 테이블에 SELECT, INSERT를 할 수 있음
Peter 스키마에 속한 TIME_CARDS 테이블에 SELECT, INSERT를 할 수 있음
Peter 스키마에 속한 DEPARTMENT 테이블에 SELECT, INSERT를 할 수 있음
역할 부여
역할을 다른 역할에게 부여할 수 있습니다.
예를 들면 다음과 같이 역할 APP_USER를 역할 CLERK에 부여할 수 있습니다.
위의 SQL 문장이 실행되면 역할 CLERK을 부여 받은 사용자에게 동시에 역할 APP_USER가 부여되고 역할 CLERK과 APP_USER에 양쪽에 포함된 모든 특권을 사용할 수 있게 됩니다.
역할을 부여 받은 사용자는 그 역할을 다른 사용자에게 다시 부여할 수 있습니다. 단, 역할을 부여하는 사용자 가 그 역할을 다음과 같이 WITH ADMIN OPTION과 함께 부여 받아야 합니다.
위의 GRANT 명령이 실행되면, 사용자 Susan은 부여된 역할을 다시 다른 사용자에게 부여할 수 있으며 그 사용자로부터 역할을 회수할 수도 있습니다. 하지만 사용자 Peter는 CLERK 역할을 사용만 할 뿐 그 역할을 다시 다른 사용자에게 부여하거나 회수하지는 못 합니다.
역할 회수
다른 사용자로부터 역할을 회수시키기 위해서는 REVOKE 명령을 사용해야 합니다. DBA는 자신이 직접 부 여하지 않은 역할에 대해서도 다른 사용자로부터 회수할 수 있습니다.
다음은 사용자 Peter와 역할 CLERK으로부터 역할 APP_USER를 회수하는 예입니다.
위의 예에서는 회수 대상이 사용자든 역할이든 문법은 동일합니다.
미리 정의된 역할
Tibero에서는 빈번하게 사용되는 시스템 특권을 모아 다음과 같은 역할로 미리 정의하고 있습니다.
CONNECT
CREATE SESSION
단순히 데이터베이스에 접속만 할 수 있는 특권
이 특권은 모든 사용자에게 필요한 특권
RESOURCE
CREATE PROCEDURE CREATE SEQUENCE CREATE TABLE CREATE TRIGGER
자신의 스키마에 기본적인 스키마 객체를 생성하는 특권
이 특권은 애플리케이션 프로그램 개발자에게 필요한 기본적인 특권
DBA
-
DBA에게 필요한 시스템 특권을 포함하고 있는 특권
이 역할을 부여 받은 DBA는 시스템 특권을 임의로 다른 사용자에게 부여할 수 있음
모든 시스템 특권이 WITH ADMIN OPTION으로 부여됨
HS_ADMIN_ROLE
-
Heterogeneous Service를 이용하는 DBA에게 필요한 시스템 특권을 포함하고 있는 특권
기본 역할
사용자에게 부여한 역할은 한 세션 내에서 SET ROLE 명령을 사용함으로써 동적으로 활성화하거나 비활 성화할 수 있습니다. 예를 들어 사용자가 CLERK, RESOURCE, APP_USER 역할을 가지고 있다면 다음과 같은 명령을 사용하여 이 중 필요한 역할만을 활성화할 수 있습니다.
역할의 활성화와 비활성화는 사용자의 특권을 효율적으로 제어하는 데에 매우 유용합니다. 사용자에게 애 플리케이션 프로그램을 실행할 때에만 특정한 특권을 부여하길 원합니다면 SET ROLE 명령을 사용하여 프 로그램의 시작과 동시에 그 특권이 포함된 역할을 사용할 수 있도록 활성화하고, 프로그램 종료 직전에 그 역할의 사용을 중지시키기 위해 비활성화합니다.
사용자가 처음으로 세션에 접속할 때에 활성화 되는 역할을 그 사용자의 기본 역할이라고 합니다. 새로 생성 한 사용자는 처음에 기본 역할이 ALL로 설정됩니다. 즉, 사용자에게 부여하는 모든 역할이 기본적으로 활성 화됩니다. 사용자의 기본 역할은 ALTER USER 문을 이용하여 바꿀 수 있으며, 그 형식은 SET ROLE 명령 과 비슷합니다.
예를 들면 다음과 같습니다.
역할 정보 조회
Tibero에서는 역할의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다.
DBA나 일반 사용 자 모두 사용할 수 있습니다.
DBA_ROLES
Tibero 내의 모든 역할의 정보를 조회하는 뷰
DBA_ROLE_PRIVS
사용자나 다른 역할에 부여된 모든 역할의 정보를 조회하는 뷰.
USER_ROLE_PRIVS
현재 사용자나 PUBLIC 사용자에 부여된 역할의 정보를 조회하는 뷰
ROLE_SYS_PRIVS
현재 사용자가 접근할 수 있는 역할에 부여된 시스템 특권 정보를 조회하는 뷰
ROLE_TAB_PRIVS
현재 사용자가 접근할 수 있는 역할들에 부여된 스키마 객체 특권들을 조회 하는 뷰
ROLE_ROLE_PRIVS
현재 사용자가 접근할 수 있는 역할들에 부여된 다른 역할들의 정보를 조회 하는 뷰
참고
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고합니다.
네트워크 접속 제어
네트워크 접속 제어(NAC: Network Access Control)는 허가되지 않은 사용자나 보안 문제를 가진 사용자 의 네트워크 접속을 차단하고 제어하는 네트워크 보안 기술입니다. Tibero는 이러한 기술을 채택함으로써 기업 내 IT 자산을 보다 효과적으로 보호할 수 있습니다.
Tibero에서 제공하는 네트워크 접속 제어는 네트워크 보안의 범위에 따라 크게 두 가지로 나뉩니다.
전체 네트워크 접속 제어 클라이언트 전체의 네트워크 접속을 차단하거나 허용합니다.
IP 주소 기반 네트워크 접속 제어 리스너 또는 클라이언트의 IP 주소에 따라 네트워크 접속을 차단하거나 허용합니다.
전체 네트워크 접속 제어
전체 네트워크 접속 제어는 클라이언트 전체를 더는 TCP/IP 네트워크로 접속하지 못하게 하거나 또는 접 속할 수 있도록 하는 방법입니다.
다음은 클라이언트 전체의 네트워크 접속을 허용하는 방법으로 Tibero 서버를 처음 기동시킬 때와 같은 상태입니다.
다음은 클라이언트 전체의 네트워크 접속을 차단하는 방법입니다.
위 명령을 실행하면 외부 클라이언트의 네트워크 접속은 차단되지만 로컬 호스트에서 접속하는 클라이언 트의 네트워크 접속은 여전히 허용됩니다. 단, 로컬 호스트의 tbdsn.tbr 파일에서 IP가 'localhost'라고 설정 된 경우에만 해당됩니다. 그리고 이미 접속된 클라이언트는 계속 유지됩니다.
IP 주소 기반 네트워크 접속 제어
리스너의 IP를 통한 접속 제어
초기화 파라미터에 설정된 IP 주소에 따라 리스너가 사용할 IP 주소를 설정해 해당 주소로만 네트워크 접 속을 허용하는 방법입니다.
LISTENER_IP
이 방법은 특정 IP 주소로 접속하는 클라이언트의 네트워크 접속만 허용할 때 사용합니다.
리스너가 사용할 IP를 지정합니다.
위 파라미터 설정 시 ssl 및 special port도 이 주소로 바인딩 됩니다.
운영 중 변경 및 삭제할 수 없습니다.
참고
IPv6를 사용하는 경우에는 위 초기화 파라미터 대신 LISTENER_IP_6를 사용해야 합니다.
EXTRA_LISTENER_IPS
이 방법은 LISTENER_IP 외 추가로 접속을 허용할 IP 주소를 추가할 때 사용합니다.
LISTENER_IP로 지정된 기본 IP 주소 외에 리스너가 사용할 추가 IP 주소입니다. 따라서 LISTENER_IP가 설정된 경우에만 유효합니다.
IPv4 형식만 지원합니다.
운영 중 추가 및 삭제가 가능합니다(아래 "동적 리스너 IP 추가 및 삭제" 참고).
위 파라미터 설정 시 입력한 IP 주소에 대해 기본 default port 및 추가 등록한 모든 extra port의 접속 이 허용됩니다. 이는 동적 추가시에도 마찬가지입니다.
여러 개의 IP 주소를 설정하는 경우에는 각 IP 주소를 세미콜론(;)으로 구분하여 표기합니다.
<<$TB_SID.tip>>
참고
해당 초기화 파라미터가 제대로 적용되었는지를 확인하기 위해서는 반드시 리스너의 트레이스 로그 파일의 내용을 확인해 볼 것을 권장합니다.
참고
Windows 운영체제에서 EXTRA_LISTENER_IPS 기능은 추후 지원 예정입니다.
주의
VIP 기능을 사용 중이더라도 자동으로 해당 ip가 EXTRA_LISTENER_IPS로 추가되지 않습니다. 따라 서 부팅 및 failover 시 항상 동적으로 추가해 주어야 합니다.
동적 리스너 IP 추가 및 삭제
LISTENER_IP 이외의 데이터베이스의 IP를 추가하고 싶은 경우 다음과 같은 설정을 통해 추가 가능하다.
추가한 리스너 IP를 삭제하는 경우 다음과 같은 명령어를 통해 삭제합니다.
클라이언트의 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는 서브넷 마스크의 bit 수가 24bits이므로, 255.255.255.0과 같은 서브넷 마스크를 의미합니다. 따라서 192.168.2.xxx의 IP 주소를 갖는 모든 클라이언트의 네트워크 접속을 허용합니다는 의미입니다.
다음은 LSNR_INVITED_IP 초기화 파라미터를 이용하여 클라이언트의 네트워크 접속을 허용하는 방법입니다.
<<$TB_SID.tip>>
LSNR_INVITED_IP의 최대 길이는 255자입니다. 256 이상의 IP 주소를 설정할 경우에는 LSNR_INVIT ED_IP_FILE을 사용합니다.
LSNR_INVITED_IP_FILE
이 방법은 특정 파일에 접속을 서용하는 IP 주소 목록을 기재한 후 해당 파일의 절대 경로를 적어주면 그 파일을 읽어서 INVITED_IP를 설정합니다.
하나의 IP 주소는 'IP 주소**/서브넷 마스크의 bit 수'**와 같은 형식으로 표현됩니다.
여러 개의 IP 주소를 설정하는 경우에는 한 라인에 1개의 IP 주소를 설정합니다.
설정할 수 있는 파일의 최대 크기는 8MB입니다.
다음은 LSNR_INVITED_IP_FILE 초기화 파라미터를 이용하여 클라이언트의 네트워크 접속을 허용 하는 방법입니다.
<</home/tibero/invited_ip.txt>>
<<$TB_SID.tip>>
LSNR_DENIED_IP
이 방법은 특정한 IP 주소를 갖는 클라이언트의 네트워크 접속은 차단되지만 그 밖의 접속은 허용하는 경우에 사용합니다.
LSNR_INVITED_IP 초기화 파라미터의 설정 방법과 동일합니다.
다음은 LSNR_DENIED_IP 초기화 파라미터를 이용하여 클라이언트의 네트워크 접속을 차단하는 방법입니다.
<<$TB_SID.tip>>
LSNR_DENIED_IP_FILE
이 방법은 특정 파일에 접속을 허용하지 않는 IP 주소 목록을 기재한 후 해당 파일의 절대 경로를 적어 주면 그 파일을 읽어서 DENIED_IP를 설정합니다.
LSNR_INVITED_IP_FILE 초기화 파라미터의 설정 방법과 동일합니다.
LSNR_INVITED_IP와 LSND_DENIED_IP 파라미터는 다음과 같은 특징이 있습니다.
$TB_SID.tip 파일에 LSNR_INVITED_IP와 LSNR_DENIED_IP가 모두 설정되어 있는 경우 LSNR_ DENITED_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의 설정을 변경한 후 파일을 저장하고 다음의 명령을 실행합니다.
위의 명령을 실행하면 $TB_SID.tip 파일에서 LSNR_INVITED_IP 또는 LSNR_DENIED_IP의 내용을 다시 읽어 변경된 내용을 실시간으로 적용합니다.
참고
해당 초기화 파라미터가 제대로 적용되었는지를 확인하기 위해서는 반드시 리스너의 트레이스 로그 파일의 내용을 확인해 볼 것을 권장합니다.
동적 리스너 포트 추가 및 삭제
LISTENER_PORT 이외의 데이터베이스의 접속 포트를 추가하고 싶은 경우 다음과 같은 설정을 통해 추 가 가능합니다.
추가한 리스너 포트를 삭제하는 경우 다음과 같은 명령어를 통해 삭제합니다.
EXTRA_LISTENER_PORTS 파라미터를 설정하는 경우 끝부분에 세미콜론(;) 구분자를 넣어야 합니다.
<<$TB_SID.tip>>
참고
Windows 운영체제에서 동적 리스너 포트 추가 및 삭제는 추후 지원 예정입니다.
감사
감사(Auditing)는 데이터베이스 내에서 지정된 사용자의 동작을 기록하는 보안 기술입니다. 관리자는 감사 기능을 통해 특정 동작 또는 특정 사용자에 대해 별도의 로그를 남김으로써 데이터베이스를 보다 효과적 으로 보호할 수 있습니다.
감사 기능은 감사의 대상에 따라 두 종류로 구분됩니다.
스키마 객체에 대한 감사 지정된 스키마 객체에 수행되는 모든 동작을 기록할 수 있습니다.
시스템 특권에 대한 감사 지정된 시스템 특권을 사용하는 모든 동작을 기록할 수 있습니다.
감사 기록(Audit Trail)을 남기고 싶은 사용자 또는 역할을 지정할 수 있으며, 성공한 동작 또는 실패한 동 작에 대해서만 감사 기록을 남기도록 지정할 수 있습니다. 또한 세션 별로 한 번만 감사 기록을 남기거나 동작 이 수행될 때마다 감사 기록을 남기도록 지정할 수 있습니다.
감사 설정과 해제
감사를 설정하거나 해제하려면 AUDIT 또는 NOAUDIT 명령어을 사용합니다.
스키마 객체에 대한 감사
다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체를 감사하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 합니다.
다음은 스키마 객체에 대한 감사를 설정하는 예입니다.
위의 SQL 문장이 성공하면 테이블 t에 수행되는 모든 delete 문이 성공하는 경우에만 감사 기록을 남긴다.
시스템 특권에 대한 감사
시스템 특권을 감사하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다. 다음은 시스템 특권에 대한 감사를 설정하는 예입니다.
위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성하려고 할 때 그것이 성공하든 실패하든 관계 없이 감사 기록을 남긴다.
참고
시스템 특권에 관한 자세한 내용은 “특권”을 참고합니다.
감사 해제
시스템 특권의 감사를 해제하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다. 다른 사용자 가 소유한 스키마의 객체 또는 디렉터리 객체의 감사를 해제하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 합니다.
다음은 이미 설정된 감사를 해제하는 예입니다.
위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성할 때 더 이상 감사 기록을 남기지 않습니다.
참고
SYS 사용자를 감사의 대상으로 지정할 수 없습니다. SYS 사용자에 대한 감사는 “SYS 사용자에 대한 감사”를 참고합니다.
감사 기록
감사 기록(Audit Trail)은 명령을 수행한 사용자, 명령이 수행된 스키마 객체, 수행 시각, 세션 ID 등의 기본 정보와 실행된 SQL 문장으로 이루어진다.
감사 기록 저장
감사 기록은 $TB_SID.tip 파일에 설정된 AUDIT_TRAIL 파라미터에 따라 데이터베이스 내부 또는 OS 파 일에 저장할 수 있습니다. OS 파일에 감사 기록을 저장하는 경우 파일의 위치와 최대 크기를 각각 $TB_SID.tip 파일의 AUDIT_FILE_DEST 파라미터와 AUDIT_FILE_SIZE 파라미터로 설정할 수 있습니다.
다음은 감사 기록의 저장 위치를 지정하는 예입니다.
<<$TB_SID.tip>>
위와 같이 설정하면 감사 기록에 포함되는 기본 정보뿐만 아니라 사용자가 실행한 SQL문장까지 데이터 베이스에 저장됩니다.
<<$TB_SID.tip>>
위와 같이 설정하면 "/home/tibero/audit/audit.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가 결국 성공했는지 여부를 나타내는 컬럼
S : 성공을 의미
F : 실패를 의미
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 형태로 보여줍니다.
참고
$TB_SID.tip 파일 설정에 관한 자세한 내용은 "Tibero 참조 안내서"를 참고합니다.
SYS 사용자에 대한 감사 기록은 데이터베이스에 저장되지 않습니다. 자세한 내용은 “SYS 사용자에 대한 감사”를 참고합니다.
감사 기록 조회
감사 기록은 OS 파일 또는 데이터베이스에 저장됩니다. OS 파일에 저장하도록 설정한 경우 일반 텍스트 파 일의 형태로 저장되므로 쉽게 내용을 열람할 수 있습니다. 데이터베이스에 저장하도록 설정한 경우에는 다음 의 정적 뷰를 통해 감사 기록을 조회할 수 있습니다.
DBA_AUDIT_TRAIL
데이터베이스에 저장된 모든 감사 기록을 조회하는 뷰
USER_AUDIT_TRAIL
데이터베이스에 저장된 현재 사용자의 감사 기록을 조회하는 뷰
참고
정적 뷰에 대한 자세한 내용은 "Tibero 참조 안내서"를 참고합니다.
SYS 사용자에 대한 감사
SYS 사용자의 명령은 보안 상의 이유로 다른 사용자의 명령과는 다른 방식으로 감사됩니다. SYS 사용자는 기본적으로 감사의 대상에서 제외되기 때문에 AUDIT 또는 NOAUDIT 명령을 사용해 감사를 설정 또는 해 제할 수 없습니다.
SYS 사용자의 명령을 감사하기 위해서는 $TB_SID.tip 파일의 AUDIT_SYS_OPERATIONS 파라미터를 'Y'로 설정해야 합니다. SYS 사용자의 명령을 감사하도록 설정하면 수행한 모든 동작이 OS 파일에 기록되 며 보안 상의 이유로 데이터베이스에는 기록되지 않습니다.
다음은 SYS 사용자의 동작을 감사하도록 설정한 예입니다.
<<$TB_SID.tip>>
위와 같이 설정하면 SYS 사용자가 수행한 모든 동작이 "/home/tibero/audit/audit_trail.log"에 최대 10MB의 크기로 저장됩니다.
Fine-Grained Auditing
Fine-Grained Auditing(FGA)는 일반적인 감사(Auditing)보다 상세한 감사를 하려는 기능입니다. AUDIT_TRAIL 파라미터를 설정하지 않아도 DBMS_FGA 패키지를 이용하여 감사를 할 수 있으며, 특정 스키마의 컬럼 또는 데이터에 대한 감사를 가능하게 합니다.
감사 기록
DBMS_FGA 패키지를 사용하여 사용자가 감사할 조건(policy)을 등록합니다. 사용자가 등록한 조건이 맞을 때 SYS.FGA_LOG$ 테이블에 기록이 됩니다.
다음은 policy를 등록 후 감사 기록이 저장되고 확인하는 예입니다.
위의 예제는 DBMS_FGA 패키지의 ADD_POLICY 프러시저를 사용하여 policy를 등록합니다. 등록 된 policy 의 이름은 FGA_POLICY이며, TIBERO.T 테이블 C1 컬럼이 SELECT 문으로 조회될 때 감사합니다. C1 컬 럼을 조회한 뒤 SYS.FGA_LOG$에 감사 기록이 저장이 됩니다.
참고
Policy 등록과 제거 및 활성화, 비활성화에 대한 자세한 내용은 "Tibero tbPSM 참조 안내서"의 "제13장 DBMS_FGA"를 참고합니다.
감사 기록 조회에 대한 자세한 내용은 “감사 기록”을 참고합니다.
Last updated