> For the complete documentation index, see [llms.txt](https://docs.tibero.com/tibero-manuals/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tibero.com/tibero-manuals/7.2.6.manuals/administrator-guide/user-management-and-security.md). # 사용자 관리와 데이터베이스 보안 Tibero의 데이터베이스 보안을 위한 사용자 계정과 사용자의 특권(Privilege)및 역할(Role) 등 을 효율적으로 관리하고 데이터베이스 사용을 감시(Audit)하기 위한 방법을 설명합니다. ## **사용자 관리** Tibero 내부의 데이터에 접근하기 위해서는 사용자 계정(Account)이 필요합니다. 각 계정은 패스워드(Password)를 통해 보안이 유지됩니다. 패스워드는 사용자 계정을 생성할 때 설정하며, 생성된 이후에 변경할 수 있습니다. Tibero는 패스워드를 데이터 사전(Data Dictionary)에 암호화된 형태로 저장합니다. Tibero에서 하나의 사용자 계정은 하나의 스키마를 가지며 스키마의 이름은 사용자의 이름과 같습니다. {% hint style="info" %} **참고** 스키마(Schema)는 테이블, 뷰, 인덱스 등의 스키마 객체(Schema object)의 묶음입니다. {% endhint %} 특정 스키마에 속한 스키마 객체를 나타내려면 다음과 같이 입력합니다. ``` 사용자 계정.스키마 객체 ``` \ 다음은 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; ... ``` \ 다음은 스키마 객체 앞에 특정한 사용자 계정을 명시하지 않았을 경우의 예입니다. ``` SELECT * FROM V$DATABASE; ``` 사용자 계정이 생략되면 스키마 객체에 접근할 때 다음과 같은 과정을 거칩니다. 1. 사용자 자신이 소유한 스키마 객체 중에 V$DATABASE가 있는지 검색합니다. tibero라는 사용자 계정으로 접속했다고 가정하면 tibero.V$DATABASE를 검색합니다.
2. 사용자가 소유한 스키마 객체 중 V$DATABASE가 존재하지 않으면 PUBLIC 사용자가 소유한 동의어를 검색합니다. 즉, PUBLIC.V$DATABASE를 검색합니다. PUBLIC 사용자는 오직 동의어만을 소유할 수 있습니다. PUBLIC 사용자가 소유한 동의어를 검색할 때 스키마 객체 앞에 PUBLIC 사용자 계정을 명시할 수 없습니다. PUBLIC 사용자가 소유한 동의어 V$DATABASE를 찾는다고 가정하면 PUBLIC.V$DATABASE라고 입력할 수 없고 V$DATABASE만 입력해야 합니다.
3. PUBLIC.V$DATABASE라는 이름의 스키마 객체가 없거나 있어도 사용자가 PUBLIC.V$DATABASE 객체에 대한 특권이 없다면 에러를 반환합니다. ### 사용자 생성, 변경, 제거 사용자를 새로 생성하거나 변경, 제거하기 위해서는 DBA 특권을 가진 사용자로 Tibero에 접속합니다. Tibero에서는 기본적으로 SYS라는 사용자를 제공합니다. SYS 사용자는 Tibero를 설치하는 과정에서 생기는 계정으로 DBA 역할이 부여됩니다. SYS 사용자로 Tibero에 접속하는 방법은 다음과 같습니다. ``` $ tbsql SYS/tibero tbSQL 7 TmaxData Corporation Copyright (c) 2008-. 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 문을 사용할 때에는 반드시 패스워드를 설정해야 합니다. 만약 패스워드에 특수문자를 사용할 경우 "dsjeoj134!"와 같이 큰따옴표로 묶어야 합니다. ③ 디폴트 테이블 스페이스를 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. SQL> CREATE USER Park IDENTIFIED BY cccc; User 'PARK' created. ``` 위와 같이 테이블 스페이스를 지정하지 않으면 자동으로 시스템 테이블 스페이스를 사용하게 됩니다. 새로 생성된 사용자는 아무런 특권을 가지지 않으며 데이터베이스에 접속할 수 없습니다. 데이터베이스에 접속하기 위해서는 CREATE SESSION 시스템 특권이나 이를 포함하는 역할을 부여받아야 합니다.
다음은 생성된 사용자에게 특권을 할당하는 예입니다. 자세한 내용은 “[특권](#undefined-7)”을 참고합니다. ``` SQL> GRANT CONNECT TO Peter; Granted. SQL> GRANT CREATE TABLE TO Peter; Granted. SQL> GRANT RESOURCE TO John; Granted. SQL> GRANT CONNECT TO Smith; Granted. SQL> GRANT DBA TO Susan; Granted. SQL> GRANT RESOURCE TO Park; Granted. ``` #### **사용자 변경** 사용자에게 설정된 패스워드, 테이블 스페이스 등을 변경하는 방법은 다음과 같습니다. ``` ALTER USER Peter ... ① ... IDENTIFIED BY abcdef ... ② ... DEFAULT TABLESPACE SYSTEM; ... ③ ... ``` ① ALTER USER 문을 사용하여 Peter라는 사용자의 정보를 변경합니다. ② 사용자 Peter의 패스워드를 abcdef로 변경합니다. ③ 테이블 스페이스를 SYSTEM 테이블 스페이스로 변경합니다. #### **사용자 제거** 사용자를 제거하는 방법은 다음과 같습니다. ``` DROP USER user_name CASCADE; ```
항목설명
DROP USER user_nameDROP USER 문을 통해 user_name에 설정된 사용자를 제거
CASCADE
  • DROP USER 문의 옵션 중 하나인 CASCADE는 사용자를 제거하기 전에 그 사용자의 모든 스키마 객체를 제거
  • CASCADE 옵션을 사용하지 않으면 해당 사용자가 아무런 스키마 객체를 가지고 있지 않을 경우에만 사용자를 제거할 수 있음
  • 제거된 사용자의 스키마 객체를 참조하는 뷰나 동의어, 프로시저, 함수는 모두 INVALID 상태가 됨
  • 나중에 동일한 이름의 다른 사용자가 만들어지면 새로운 사용자는 그 이름을 가졌던 이전 사용자로부터 아무것도 상속받지 못함
다음은 John이라는 사용자를 제거하는 예입니다. ``` DROP USER John CASCADE; ``` ### 사용자 정보 조회 Tibero에서는 사용자의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다.
정적 뷰설명
ALL_USERS데이터베이스의 모든 사용자의 기본적인 정보를 조회하는 뷰
DBA_USERS데이터베이스의 모든 사용자의 자세한 정보를 조회하는 뷰
정적 뷰설명
USER_USERS현재 사용자의 정보를 조회하는 뷰
{% hint style="info" %} **참고** 정적 뷰에 대한 자세한 내용은 "[Tibero 참조 안내서](/tibero-manuals/7.2.6.manuals/reference-guide.md)"를 참고합니다. {% endhint %} ### 사용자 계정 잠금 및 해제 데이터베이스 사용자가 계정에 접속할 수 없도록 계정을 잠금 상태로 설정하거나 잠금 상태를 해제할 수 있습니다. ``` SQL> ALTER USER Peter ACCOUNT LOCK; User 'PETER' altered. ``` 계정 잠금 상태에서 해당 계정에 접속을 시도하면 다음과 같은 오류 코드와 함께 접속이 중단됩니다. ``` SQL> conn peter/abcdef; TBR-17006: Account is locked. No longer connected to server. ``` 계정 잠금을 해제하려면 다음의 SQL을 수행합니다. ``` SQL> ALTER USER Peter ACCOUNT UNLOCK; User 'PETER' altered. ``` 프로파일 설정에 따라 패스워드 사용 기한이 만료되거나 패스워드 오류 횟수 초과 등으로 계정 잠금 상태가 된 경우에도 동일한 방법으로 잠금을 해제할 수 있습니다. ### 운영체제(OS) 인증을 사용한 사용자 생성 사용자 생성은 보안 정책에 따라 데이터베이스 보안 정책을 따르는 사용자 생성과 운영체제(OS) 인증 정책을 따르는 사용자 생성으로 구분됩니다. 운영체제(OS) 인증을 사용하는 사용자 계정은 다음과 같이 생성할 수 있습니다. ``` SQL> CREATE USER OSA$Steve ... ① ... IDENTIFIED externally; ... ② ... ``` ① CREATE USER 문을 사용하여 OS 사용자인 Steve라는 사용자를 생성하는데 OS 인증 정책 사용자를 알리는 OSA$ prefix를 붙여 생성합니다. 해당 값은 OS\_AUTH\_PREFIX에서 변경할 수 있으며, 기본값은 OSA$입니다. ② OS 인증을 사용하는 사용자 OSA$Steve의 패스워드는 데이터베이스에서 별도로 관리하지 않습니다. 즉, OS의 사용자 Steve가 존재하는 경우 host에서 인증을 완료한 것으로 가정하여 데이터베이스에서 별도로 확인하지 않습니다(OS의 보안이 취약한 경우에는 사용을 권하지 않습니다). OS 인증 사용자 생성 이후 로컬에서 접속하는 방법은 다음과 같습니다. ``` $ tbsql / tbSQL 7 TmaxData Corporation Copyright (c) 2008-. All rights reserved. Connected to Tibero. SQL> ``` {% hint style="info" %} **참고** 원격에서 OS 인증 사용자 접속은 보안상의 문제로 지원하지 않습니다. {% endhint %} ## 특권 사용자가 데이터베이스의 특정 스키마 객체에 접근하려면 특권(Privilege)을 부여받아야 합니다. 특권을 부여받으면 허용된 스키마 객체에 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 테이블의 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을 이용하여 스키마 객체 특권을 부여하는 예입니다. ``` 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과 Park에게도 다음과 같은 특권을 할당합니다. ``` SQL> GRANT ALL ON EMPLOYEE TO Susan WITH GRANT OPTION; Granted. SQL> GRANT SELECT, DELETE ON EMPLOYEE TO Park WITH GRANT OPTION; Granted. ``` #### **스키마 객체 특권 회수** 다른 사용자로부터 스키마 객체 특권을 회수하기 위해서는 **REVOKE** 명령을 사용해야 합니다. 이 명령은 사용자의 스키마 객체 특권의 일부 또는 전체를 회수할 수 있습니다. DBA는 자신이 직접 부여하지 않는 특권에 대해서도 다른 사용자로부터 회수할 수 있습니다. 다음은 각각 Peter로부터 테이블 EMPLOYEE에 대한 DELETE 특권을 회수하고 John으로부터 모든 특권을 회수하는 예입니다. ``` REVOKE DELETE ON EMPLOYEE FROM Susan; conn sys/tibero REVOKE ALL ON Peter.EMPLOYEE FROM Park; ``` WITH GRANT OPTION과 함께 부여된 특권을 회수할 때에는 연속적으로 특권이 회수됩니다. 다음은 Peter로부터 부여받은 Peter.EMPLOYEE에 대한 특권을 사용자 Smith가 Susan에게 부여하는 예입니다. ``` SQL> conn Smith/aaaa Connected. SQL> GRANT ALL ON Peter.EMPLOYEE TO Susan; Granted. ``` 사용자 Peter가 다음과 같이 Smith에게 부여한 테이블 EMPLOYEE의 특권을 회수하면 사용자 Smith가 Susan에게 부여한 같은 특권도 동시에 회수됩니다. ``` SQL> conn Peter/abcdef Connected SQL> REVOKE ALL ON Peter.EMPLOYEE FROM Smith; ``` ### 시스템 특권 데이터베이스를 관리하는 데 필요한 시스템 명령어를 사용하려면 시스템 특권을 부여받아야 합니다. 시스템 특권은 기본적으로 SYS 사용자가 소유하고 있으며 다른 사용자에게 부여할 수 있습니다. 시스템 특권은 다음과 같습니다.
시스템 특권설명
ALTER SYSTEMALTER 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임의의 스키마에 속한 동의어를 제거하는 권한
SYSDBASHUTDOWN, ALTER DATABASE, CREATE DATABASE, ARCHIVELOG, RECOVERY 같은 명령을 할 수 있는 권한
CREATE PUBLIC SYNONYMPUBLIC 스키마에 동의어를 생성하는 권한
DROP PUBLIC SYNONYMPUBLIC 스키마에 속한 동의어를 제거하는 권한
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 특권을 부여하는 예입니다. ``` conn SYS/tibero Connected to Tibero. GRANT SELECT ANY TABLE TO Susan WITH ADMIN OPTION; Granted. ``` 사용자 Susan은 SYS 사용자에게 부여받은 시스템 특권을 다른 사용자에게 부여할 수 있는 권한이 생성됩니다. 즉, 다른 사용자에게 데이터베이스 내의 모든 테이블을 조회할 수 있는 특권을 부여할 수 있다는 의미입니다. #### **시스템 특권 회수** WITH ADMIN OPTION과 함께 부여된 특권은 WITH GRANT OPTION과는 달리 연속적으로 회수되지 않습니다. 다음은 사용자 Susan이 사용자 SYS로부터 부여받은 특권을 Peter에게 부여하는 예입니다. ``` SQL> conn Susan/bbbb Connected to Tibero. SQL> GRANT SELECT ANY TABLE TO Peter; Granted. ``` 다음과 같이 Susan에게 부여한 시스템 특권을 회수하더라도 사용자 Susan이 Peter에게 부여한 시스템 특권은 그대로 유지됩니다. ``` conn SYS/tibero Connected to Tibero. REVOKE SELECT ANY TABLE FROM Susan; ``` ### 특권 정보 조회 Tibero에서는 특권의 정보를 제공하기 위해 다음 표에 나열된 정적 뷰를 제공하고 있습니다.
정적 뷰설명
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 사용자에게 부여된 모든 스키마 객체 특권 중 스키마 객체의 특정 컬럼에 부여된 특권의 정보를 조회하는 뷰
{% hint style="info" %} **참고** 정적 뷰에 대한 자세한 내용은 "[Tibero 참조 안내서](/tibero-manuals/7.2.6.manuals/reference-guide.md)"를 참고합니다. {% endhint %} ### **부가적인 특권** 다음은 부가적인 특권을 설정할 수 있는 파라미터에 대한 설명입니다.
파라미터설명
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 ALLREVOKE ALL의 경우 USE_TRUNCATE_PRIVILEGE 파라미터의 여부와 상관없이 TRUNCATE 특권이 취소됨
## 프로파일 데이터베이스 사용자의 패스워드 관리 정책을 지정할 수 있습니다. 예를 들어 사용자 1, 2, 3은 90일 후 패스워드 사용 기간이 만료되도록 설정하고, 사용자 4, 5는 패스워드 사용 기간이 30일 후 만료되며 한 번 사용한 패스워드는 재사용하지 못하도록 설정할 수 있습니다. 이 경우 90일 후 패스워드 사용 기간이 만료되도록 설정한 프로파일과 30일 후 패스워드 사용 기간이 만료되며 한 번 사용한 패스워드는 재사용하지 못하도록 설정한 프로파일을 각각 생성합니다. 사용자 1, 2, 3은 첫 번째 프로파일을 사용하도록 지정하고, 사용자 4, 5는 두 번째 프로파일을 사용하도록 지정합니다. 이처럼 프로파일은 사용자 패스워드 관리 정책을 다양하게 생성하고 각각의 사용자에게 특정 정책을 사용하도록 지정함으로써 사용자별로 그룹화된 패스워드 정책을 관리할 수 있는 기능을 제공합니다. #### 프로파일 생성, 변경, 제거 다음은 프로파일을 생성하는 예입니다. ``` 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. ``` #### **프로파일 파라미터 종류** 위 예제에서 보았듯이 프로파일을 생성, 변경할 때는 세부적인 파라미터를 지정할 수 있습니다. 각 파라미터에 대한 상세 설명은 "Tibero SQL 참조 안내서"에 기술되어 있습니다. 참고로 각 파라미터의 기본값은 데이터베이스를 생성할 때 함께 생성된 DEFAULT 프로파일에 의해 결정되며, 이 기본값들은 **DBA\_PROFILES** 뷰를 통해 확인할 수 있습니다. 다음은 프로파일을 변경하는 예입니다. ``` 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 Jason IDENTIFIED BY 'Abcd123!' PROFILE prof; User 'JASON' 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 DEFAULT SESSIONS_PER_USER UNKNOWN UNLIMITED PROF FAILED_LOGIN_ATTEMPTS PASSWORD 3 PROF PASSWORD_LIFE_TIME PASSWORD 90 PROF PASSWORD_REUSE_TIME PASSWORD 30 PROF PASSWORD_REUSE_MAX PASSWORD 10 PROF PASSWORD_VERIFY_FUNCTION PASSWORD NULL_VERIFY_FUNCTION PROF PASSWORD_LOCK_TIME PASSWORD 1 PROF PASSWORD_GRACE_TIME PASSWORD 10 PROF LOGIN_PERIOD PASSWORD UNLIMITED PROF SESSIONS_PER_USER UNKNOWN UNLIMITED 18 rows selected. ``` 다음은 사용자별로 적용된 프로파일 정보를 조회하는 예입니다. PETER라는 사용자에 T\_PROF라는 프로파일이 할당된 상황을 확인할 수 있습니다. ``` SQL> select username, profile from dba_users; USERNAME PROFILE -------------- ---------- SYS DEFAULT SYSCAT DEFAULT SYSGIS DEFAULT OUTLN DEFAULT SYSBACKUP DEFAULT TIBERO DEFAULT TIBERO1 DEFAULT LBACSYS DEFAULT STEVE DEFAULT SMITH DEFAULT SUSAN DEFAULT OSAS$SAMPLER2 DEFAULT PETER PROF JASON DEFAULT 15 rows selected. ``` #### 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 특권을 부여하고 있습니다. ``` SQL> conn SYS/tibero Connected to Tibero. SQL> GRANT CREATE ROLE, ALTER ANY ROLE, GRANT ANY ROLE TO Peter; Granted. ``` #### **역할 생성** 다음은 역할을 생성하는 예입니다. ``` SQL> CREATE ROLE APP_USER; Role 'APP_USER' created. SQL> GRANT CREATE SESSION TO APP_USER; Granted. SQL> CREATE ROLE CLERK; Role 'CLERK' created. ``` 다음은 본 예제를 기준으로 생성된 역할에 대한 설명입니다.
역할설명
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> 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. SQL> GRANT CLERK TO Park; Granted. ``` 위의 GRANT 명령이 실행되면, 사용자 Susan은 부여된 역할을 다시 다른 사용자에게 부여할 수 있으며 그 사용자로부터 역할을 회수할 수도 있습니다. 하지만 사용자 Peter는 CLERK 역할을 사용만 할 뿐 그 역할을 다시 다른 사용자에게 부여하거나 회수하지는 못합니다. #### **역할 회수** 다른 사용자로부터 역할을 회수시키기 위해서는 **REVOKE** 명령을 사용해야 합니다. DBA는 자신이 직접 부여하지 않은 역할에 대해서도 다른 사용자로부터 회수할 수 있습니다. 다음은 사용자 Peter와 역할 CLERK으로부터 역할 APP\_USER를 회수하는 예입니다. ``` REVOKE CLERK FROM Peter; REVOKE APP_USER FROM CLERK; ``` 위의 예에서는 회수 대상이 사용자든 역할이든 문법은 동일합니다. ### 미리 정의된 역할 Tibero에서는 빈번하게 사용되는 시스템 특권을 모아 다음과 같은 역할로 미리 정의하고 있습니다.
역할포함된 특권설명
CONNECTCREATE SESSION
  • 단순히 데이터베이스에 접속만 할 수 있는 특권
  • 이 특권은 모든 사용자에게 필요한 특권
RESOURCECREATE 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 역할을 가지고 있다면 다음과 같은 명령을 사용하여 이 중 필요한 역할만을 활성화할 수 있습니다. ``` conn Susan/bbbb SET ROLE CLERK, DBA; /* CLERK, DBA 역할을 활성화한다. */ SET ROLE ALL EXCEPT CLERK; /* CLERK를 제외한 모든 역할을 활성화한다. */ SET ROLE ALL; /* 모든 역할을 활성화한다. */ SET ROLE NONE; /* 모든 역할을 비활성화한다. */ ``` 역할의 활성화와 비활성화는 사용자의 특권을 효율적으로 제어하는 데에 매우 유용합니다. 사용자에게 애플리케이션 프로그램을 실행할 때에만 특정한 특권을 부여하길 원한다면 **SET ROLE** 명령을 사용하여 프로그램의 시작과 동시에 그 특권이 포함된 역할을 사용할 수 있도록 활성화하고, 프로그램 종료 직전에 그 역할의 사용을 중지시키기 위해 비활성화합니다. 사용자가 처음으로 세션에 접속할 때에 활성화되는 역할을 그 사용자의 기본 역할이라고 합니다. 새로 생성한 사용자는 처음에 기본 역할이 ALL로 설정됩니다. 즉, 사용자에게 부여하는 모든 역할이 기본적으로 활성화됩니다. 사용자의 기본 역할은 ALTER USER 문을 이용하여 바꿀 수 있으며, 그 형식은 SET ROLE 명령과 비슷합니다. 예를 들면 다음과 같습니다. ``` conn SYS/tibero 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_ROLESTibero 내의 모든 역할의 정보를 조회하는 뷰
DBA_ROLE_PRIVS사용자나 다른 역할에 부여된 모든 역할의 정보를 조회하는 뷰
USER_ROLE_PRIVS현재 사용자나 PUBLIC 사용자에게 부여된 역할의 정보를 조회하는 뷰
ROLE_SYS_PRIVS현재 사용자가 접근할 수 있는 역할에 부여된 시스템 특권 정보를 조회하는 뷰
ROLE_TAB_PRIVS현재 사용자가 접근할 수 있는 역할에 부여된 스키마 객체 특권을 조회하는 뷰
ROLE_ROLE_PRIVS현재 사용자가 접근할 수 있는 역할에 부여된 다른 역할의 정보를 조회하는 뷰
{% hint style="info" %} **참고** 정적 뷰에 대한 자세한 내용은 "[Tibero 참조 안내서](/tibero-manuals/7.2.6.manuals/reference-guide.md)"를 참고합니다. {% endhint %} ## 네트워크 접속 제어 네트워크 접속 제어(NAC: Network Access Control)는 허가되지 않은 사용자나 보안 문제를 가진 사용자의 네트워크 접속을 차단하고 제어하는 네트워크 보안 기술입니다. Tibero는 이러한 기술을 채택함으로써 기업 내 IT 자산을 보다 효과적으로 보호할 수 있습니다. Tibero에서 제공하는 네트워크 접속 제어는 네트워크 보안의 범위에 따라 크게 두 가지로 나뉩니다. * **전체 네트워크 접속 제어**\ 클라이언트 전체의 네트워크 접속을 차단하거나 허용합니다.
* **IP 주소 기반 네트워크 접속 제어**\ 리스너 또는 클라이언트의 IP 주소에 따라 네트워크 접속을 차단하거나 허용합니다. ### 전체 네트워크 접속 제어 전체 네트워크 접속 제어는 클라이언트 전체를 더는 TCP/IP 네트워크로 접속하지 못하게 하거나 또는 접속할 수 있도록 하는 방법입니다. 다음은 클라이언트 전체의 네트워크 접속을 허용하는 방법으로 Tibero 서버를 처음 기동시킬 때와 같은 상태입니다. ``` ALTER SYSTEM LISTENER REMOTE ON; ``` 다음은 클라이언트 전체의 네트워크 접속을 차단하는 방법입니다. ``` ALTER SYSTEM LISTENER REMOTE OFF; ``` 위 명령을 실행하면 외부 클라이언트의 네트워크 접속은 차단되지만 로컬 호스트에서 접속하는 클라이언트의 네트워크 접속은 여전히 허용됩니다. 단, 로컬 호스트의 tbdsn.tbr 파일에서 IP가 'localhost'라고 설정된 경우에만 해당됩니다. 그리고 이미 접속된 클라이언트는 계속 유지됩니다. ### **IP** 주소 기반 네트워크 접속 제어 #### **리스너의 IP를 통한 접속 제어** 초기화 파라미터에 설정된 IP 주소에 따라 리스너가 사용할 IP 주소를 설정해 해당 주소로만 네트워크 접속을 허용하는 방법입니다. **LISTENER\_IP** * 이 방법은 특정 IP 주소로 접속하는 클라이언트의 네트워크 접속만 허용할 때 사용합니다. * 리스너가 사용할 IP를 지정합니다. * 위 파라미터 설정 시 ssl 및 special port도 이 주소로 바인딩됩니다. * 운영 중 변경 및 삭제할 수 없습니다. {% hint style="info" %} **참고** IPv6를 사용하는 경우에는 위 초기화 파라미터 대신 **LISTENER\_IP\_6**를 사용해야 합니다. {% endhint %} **EXTRA\_LISTENER\_IPS** * 이 방법은 LISTENER\_IP 외 추가로 접속을 허용할 IP 주소를 추가할 때 사용합니다. * LISTENER\_IP로 지정된 기본 IP 주소 외에 리스너가 사용할 추가 IP 주소입니다. 따라서 LISTENER\_IP가 설정된 경우에만 유효합니다. * IPv4 형식만 지원합니다. * 운영 중 추가 및 삭제가 가능합니다(아래 "[동적 리스너 IP 추가 및 삭제](#ip-1)" 참고). * 위 파라미터 설정 시 입력한 IP 주소에 대해 기본 default port 및 추가 등록한 모든 extra port의 접속이 허용됩니다. 이는 동적 추가 시에도 마찬가지입니다. * 여러 개의 IP 주소를 설정하는 경우에는 각 IP 주소를 세미콜론(**;**)으로 구분하여 표기합니다. <<$TB\_SID.tip>> ``` EXTRA_LISTENER_IPS=192.168.1.1;192.168.2.0; ``` {% hint style="info" %} **참고** 해당 초기화 파라미터가 제대로 적용되었는지를 확인하기 위해서는 반드시 리스너의 트레이스 로그 파일의 내용을 확인해 볼 것을 권장합니다. {% endhint %} {% hint style="info" %} **참고** Windows 운영체제에서 EXTRA\_LISTENER\_IPS 기능은 추후 지원 예정입니다. {% endhint %} {% hint style="warning" %} **주의** VIP 기능을 사용 중이더라도 자동으로 해당 IP가 EXTRA\_LISTENER\_IPS로 추가되지 않습니다. 따라서 부팅 및 failover 시 항상 동적으로 추가해 주어야 합니다. {% endhint %} **동적 리스너 IP 추가 및 삭제** LISTENER\_IP 이외의 데이터베이스 IP를 추가하려면 다음과 같이 설정합니다. ``` alter system listener add ip "192.168.3.0"; ``` 추가한 리스너 IP를 삭제하는 경우 다음과 같은 명령어를 통해 삭제합니다. ``` alter system listener delete ip "192.168.3.0"; ``` #### **클라이언트의 IP를 통한 접속 제어** 초기화 파라미터에 설정된 IP 주소에 따라 클라이언트의 네트워크 접속을 허용하거나 차단하는 방법입니다. **LSNR\_INVITED\_IP** * 이 방법은 특정한 IP 주소를 갖는 클라이언트의 네트워크 접속은 허용되지만 그 밖의 접속은 차단하는 경우에 사용합니다. * 하나의 IP 주소는 **'IP 주소/서브넷 마스크의 비트 수'**와 같은 형식으로 표현됩니다. * 여러 개의 IP 주소를 설정하는 경우에는 각 IP 주소를 세미콜론(**;**)으로 구분하여 표기합니다. * 서브넷 마스크의 비트 수가 32인 경우에는 표기를 생략할 수 있습니다. ``` 예: 192.168.1.1;192.168.2.0/24 ``` 위의 예제에서 192.168.1.1은 192.168.1.1/32와 같은 의미입니다. 192.168.2.0/24는 서브넷 마스크의 비트 수가 24비트이므로 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 주소/서브넷 마스크의 비트 수'**와 같은 형식으로 표현됩니다. * 여러 개의 IP 주소를 설정하는 경우에는 한 라인에 1개의 IP 주소를 설정합니다. * 설정할 수 있는 파일의 최대 크기는 8MB입니다. * 다음은 LSNR\_INVITED\_IP\_FILE 초기화 파라미터를 이용하여 클라이언트의 네트워크 접속을 허용하는 방법입니다. <\> ``` 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 주소 목록을 기재한 후 해당 파일의 절대 경로를 적어주면 파일을 읽어 DENIED\_IP를 설정합니다. * LSNR\_INVITED\_IP\_FILE 초기화 파라미터의 설정 방법과 동일합니다. * LSNR\_INVITED\_IP와 LSNR\_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의 내용을 다시 읽어 변경된 내용을 실시간으로 적용합니다. {% hint style="info" %} **참고** 해당 초기화 파라미터가 제대로 적용되었는지를 확인하기 위해서는 반드시 리스너의 트레이스 로그 파일의 내용을 확인해 볼 것을 권장합니다. {% endhint %} #### 동적 리스너 포트 추가 및 삭제 LISTENER\_PORT 이외의 데이터베이스 접속 포트를 추가하려면 다음과 같이 설정합니다. ``` alter system listener add port 8799; ``` 추가한 리스너 포트를 삭제하는 경우 다음과 같은 명령어를 통해 삭제합니다. ``` alter system listener delete port 8799; ``` EXTRA\_LISTENER\_PORTS 파라미터를 설정하는 경우 끝부분에 세미콜론(;) 구분자를 넣어야 합니다. <<$TB\_SID.tip>> ``` EXTRA_LISTENER_PORTS=8799;8800; ``` {% hint style="info" %} **참고** Windows 운영체제에서 동적 리스너 포트 추가 및 삭제는 추후 지원 예정입니다. {% endhint %} ## 감사 감사(Auditing)는 데이터베이스 내에서 지정된 사용자의 동작을 기록하는 보안 기술입니다. 관리자는 감사 기능을 통해 특정 동작 또는 특정 사용자에 대해 별도의 로그를 남김으로써 데이터베이스를 보다 효과적으로 보호할 수 있습니다. 감사 기능은 감사의 대상에 따라 두 종류로 구분됩니다. * **스키마 객체에 대한 감사**\ 지정된 스키마 객체에 수행되는 모든 동작을 기록할 수 있습니다.
* **시스템 특권에 대한 감사**\ 지정된 시스템 특권을 사용하는 모든 동작을 기록할 수 있습니다. 감사 기록(Audit Trail)을 남기고 싶은 사용자 또는 역할을 지정할 수 있으며, 성공한 동작 또는 실패한 동작에 대해서만 감사 기록을 남기도록 지정할 수 있습니다. 또한 세션 별로 한 번만 감사 기록을 남기거나 동작이 수행될 때마다 감사 기록을 남기도록 지정할 수 있습니다. ### 감사 설정과 해제 감사를 설정하거나 해제하려면 **AUDIT** 또는 **NOAUDIT** 명령어를 사용합니다. #### **스키마 객체에 대한 감사** 다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체를 감사하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 합니다. 다음은 스키마 객체에 대한 감사를 설정하는 예입니다. ``` SQL> AUDIT delete ON Peter.employee BY SESSION WHENEVER SUCCESSFUL; Audited. ``` 위의 SQL 문장이 성공하면 Peter 스키마의 employee 테이블에서 수행되는 모든 delete 문이 성공한 경우에만 감사 기록을 남깁니다. #### **시스템 특권에 대한 감사** 시스템 특권을 감사하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다. 다음은 시스템 특권에 대한 감사를 설정하는 예입니다. ``` SQL> AUDIT create table BY tibero; Audited. ``` 위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성하려고 할 때 성공 여부와 관계없이 감사 기록을 남깁니다. {% hint style="info" %} **참고** 시스템 특권에 관한 자세한 내용은 “[특권](#undefined-7)”을 참고합니다. {% endhint %} #### **감사 해제** 시스템 특권의 감사를 해제하기 위해서는 AUDIT SYSTEM 시스템 특권을 부여받아야 합니다. 다른 사용자가 소유한 스키마의 객체 또는 디렉터리 객체의 감사를 해제하기 위해서는 AUDIT ANY 시스템 특권을 부여받아야 합니다. 다음은 이미 설정된 감사를 해제하는 예입니다. ``` SQL> NOAUDIT create table BY tibero; Noaudited. ``` 위의 SQL 문장이 성공하면 tibero라는 사용자가 테이블을 생성할 때 더 이상 감사 기록을 남기지 않습니다. {% hint style="info" %} **참고** SYS 사용자를 감사의 대상으로 지정할 수 없습니다. SYS 사용자에 대한 감사는 “[SYS 사용자에 대한 감사](#sys)”를 참고합니다. {% endhint %} ### 감사 기록 감사 기록(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_FILE_SIZE=10M ``` 위와 같이 설정하면 "/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_IDAudit을 남기게 한 Statement를 파싱하여 나온 Physical Plan의 내부적인 PPID
CLIENT_IDTibero에 접속하여 명령을 수행하도록 한 클라이언트의 이름
(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인 경우 로그 형태로 감사 기록을 남깁니다. DB 또는 DB\_EXTENDED인 경우에는 SYS.\_DD\_AUD 테이블에 INSERT하여 뷰 형태로 표시합니다. {% hint style="info" %} **참고** 1. $TB\_SID.tip 파일 설정에 관한 자세한 내용은 "[Tibero 참조 안내서](/tibero-manuals/7.2.6.manuals/reference-guide.md)"를 참고합니다. 2. SYS 사용자에 대한 감사 기록은 데이터베이스에 저장되지 않습니다. 자세한 내용은 “[SYS 사용자에 대한 감사](#sys)”를 참고합니다. {% endhint %} #### **감사 기록 조회** 감사 기록은 OS 파일 또는 데이터베이스에 저장됩니다. OS 파일에 저장하도록 설정한 경우 일반 텍스트 파일의 형태로 저장되므로 쉽게 내용을 열람할 수 있습니다. 데이터베이스에 저장하도록 설정한 경우에는 다음의 정적 뷰를 통해 감사 기록을 조회할 수 있습니다.
정적 뷰설명
DBA_AUDIT_TRAIL데이터베이스에 저장된 모든 감사 기록을 조회하는 뷰
USER_AUDIT_TRAIL데이터베이스에 저장된 현재 사용자의 감사 기록을 조회하는 뷰
{% hint style="info" %} **참고** 정적 뷰에 대한 자세한 내용은 "[Tibero 참조 안내서](/tibero-manuals/7.2.6.manuals/reference-guide.md)"를 참고합니다. {% endhint %} ### **SYS** 사용자에 대한 감사 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의 크기로 저장됩니다. ### Fine-Grained Auditing Fine-Grained Auditing(FGA)는 일반적인 감사(Auditing)보다 상세한 감사를 하려는 기능입니다. AUDIT\_TRAIL 파라미터를 설정하지 않아도 DBMS\_FGA 패키지를 이용하여 감사를 할 수 있으며, 특정 스키마의 컬럼 또는 데이터에 대한 감사를 가능하게 합니다. #### **감사 기록** DBMS\_FGA 패키지를 사용하여 사용자가 감사할 조건(policy)을 등록합니다. 사용자가 등록한 조건이 맞을 때 SYS.FGA\_LOG$ 테이블에 기록이 됩니다. 다음은 policy를 등록 후 감사 기록이 저장되고 확인하는 예입니다. ``` BEGIN DBMS_FGA.ADD_POLICY( OBJECT_SCHEMA => 'TIBERO', OBJECT_NAME => 'T', POLICY_NAME => 'FGA_POLICY', AUDIT_CONDITION => NULL, AUDIT_COLUMN => 'C1' ); END; / SQL> SELECT C1 FROM T; C1 --------- 123 1 row selected. SQL> SELECT OBJ$SCHEMA, OBJ$NAME, POLICYNAME, LSQLTEXT FROM SYS.FGA_LOG$; OBJ$SCHEMA OBJ$NAME POLICYNAME LSQLTEXT ---------- -------- ---------- -------------------- TIBERO T FGA_POLICY SELECT C1 FROM T ``` 위의 예제는 DBMS\_FGA 패키지의 ADD\_POLICY 프로시저를 사용하여 policy를 등록합니다. 등록된 policy의 이름은 FGA\_POLICY이며, TIBERO.T 테이블의 C1 컬럼이 SELECT 문으로 조회될 때 감사합니다. C1 컬럼을 조회한 뒤 SYS.FGA\_LOG$에 감사 기록이 저장됩니다. {% hint style="info" %} **참고** 1. Policy 등록과 제거 및 활성화, 비활성화에 대한 자세한 내용은 "[Tibero tbPSM 참조 안내서](/tibero-manuals/7.2.6.manuals/tbpsm-reference-guide.md)"의 ["DBMS\_FGA](/tibero-manuals/7.2.6.manuals/tbpsm-reference-guide/dbms_fga.md)"를 참고합니다. 2. 감사 기록 조회에 대한 자세한 내용은 “[감사 기록](#undefined-37)”을 참고합니다. {% endhint %}