Day 40 (DB)

오라클의 사용자 보안영역은 8구역으로 나워진다. 보안구역은 크게 사용자가 사용하는 것에 대한 보안 구역과 사용자의 권한에 관한 보안구역이 있다. 사용자가 사용에 관한 보안구역은 인증방식, 계정잠금, 기본 테이블스페이스, 임시 테이블스페이스, 테이블스페이스 할당량이 있다. 인증방식은 계정을 구별하고 확인하는 두가지 방법이 passward인증과 OS인증 방식이다. 계정잠금은 사용자가 접속을 금지시키는 방식이다. 기본 테이블스페이스는 계정의 기본 테이블스페이스를 어떤 테이블스페이스로 할것인가에 대한 내용이다. 임시 테이블스페이스는 계정의 임시테이블스페이스를 어떤 테이블스페이스로 할것인가에 대한 내용이다. 테이블스페이스 할당량은 계정이 테이블스페이스에서 사용할 양을 정하는 것이다.

사용자의 권한에 관한 구역은 롤 권한, 직접권한, 자원제한이 있다. 롤은 유닉스의 그룹과 같이 권한을 관리하기 위한 묶음이다. 오라클에서의 권한은 previlige라고 하는데 유닉스에서는 permission이라고 한다. 자원제한은 다른사람의 사용에 영향을 주는 것을 막기위해 부여한다.

 

오라클의 스키마는 유저와 같은 의미이다. 왜냐하면 오라클에서의 유저명과 스키마 명은 동일하기 때문이다. 정확하게 말하면 스키마는 유저와 유저가 사용가능한 객체의 묶음을 총칭하는 말이다. 오라클은 소유개념이 있어 자신의 테이블에서는 모든 작업이 가능하지만 다른 테이블은 접근하지 못하고 접근하게 권한을 할당 받아야 한다. 다른 DB는 소유가 아닌 Access 개념이다.

 

데이터베이스는 오라클의 물리적 구조이다. 

 

스키마 객체

테이블 트리거 제약조건 인덱스 뷰 시퀀스 내장 프로그램 단위 동의어 사용자 정의 데이터 유형 데이터베이스링크

 

√사용자 생성 검토 점검 목록

 

사용자가 객체를 저장해야 하는 테이블 스페이스를 식별하는것은 반드시 문서화 되어있어야 한다.

보안 감사를 수행할때 준거성테스트와 실증 테스트를 수행한다. 준거성테스트는 문서로 보안사항을 확인하는 것이고, 실증테스트는 준거성 테스트의 오류를 검증할때 사용하며 실제로 비교 확인하는 것이다.

 

각 테이블의 할당량을 걸정하고 기본 테이블 스페이스 및 임시 테이블 스페이스를 할당한다. 그리고 사용자를 생성하고 사용자에게 권한 및 롤을 부여한다. 롤은 권한의 묶음이다. 오라클 보안모델은 소유에 대한 개념 때문에 take grant모델을 사용한다.

 

CREATE USER aaron // 생성할 계정명을 적는다.

IDENTIFIED BY soccer // 생성할 계정에 대해 Password인증을 사용할것인데 사용할 Password를 적는다.

DEFAULT TABLESPACE data // 기본 테이블 스페이스를 적는다.

TEMPORARY TABLESPACE temp // 임시 테이블스페이스를 적는다.

QUOTA 15M ON data // data 테이블스페이스는 15M까지 사용가능하다.

QUOTA 10M ON users // users 테이블스페이스는 10M까지 사용가능하다.

PASSWORD EXPIRE; // 비밀번호 만료에 대한 옵션이다.

 

IDENTIFIED EXTERNALLY // OS인증을 사용하며 오라클을 사용하는 OS의 계정과 동일하다면 sqlplus치고 엔터치면 바로 접속이 가능하다.

OS인증을 사용하면 password를 사용하지 않기 때문에 PASSWORD EXPIRE옵션을 사용하지 않는다.

 

ALTRE USER aaron

QUOTA 0 ON users; // users 테이블스페이스에 대한 aaron계정의 할당량을 없앤다. 이 경우 이전에 이미 할당받아 사용한 부분은 그대로 유지한다. 다만 추후 생성은 불가능 하다. = 오라클은 소급적용이 되지 않는다.

 

√권한관리

 

오라클 사용자 권한에는 두가지 종류가 있다. 시스템권한은 사용자가 데이터베이스에서 특정 작업을 수행하도록 부여하는 권한이다. 시스템권한은 관리자가 권한을 부여하고 권한 부여에 대한 대상이 없다.

객체권한은 사용자가 특정 객체를 엑세스 및 조작 할수있도록 한다. 객체권한은 객체 소유자가 권한을 부여하며 권한부여에 대한 대상이 있다.

만약 sys계정이 A의 객체를 B계정이 접속가능하도록 권한을 부여한다면, 시스템 상에서는 A가 권한을 준것으로 나온다.

 

100개 이상의 구분 시스템 권한이 있고, 권한중 ANY키워드를 가진 권한은 사용자가 임의의 스키마에 대한 권한을 가진다는 것을 의미한다. GRANT는 권한을 부여하는 것이고 REVOKE는 권한을 삭제하는 것이다.

시스템 권한의 예는 다음과 같다. (ANY권한은 실무에서 사용하면 안되므로 제외하고 적겠다.)

 

인덱스는 자신의 테이블에 만드는 것이므로 권한을 부여할 일이 없다.

CREATE TABLE 테이블 생성에 대한 권한을 준다.

CREATE SESSION 스키마에 접속이 가능하게 권한을 준다.

UNLIMITED TABLESPACE 모든 테이블스페이스를 마음대로 사용 가능하게 한다. QUOTA보다 우선적으로 적용된다.

 

GRANT 권한명 TO 계정명; // 계정에 권한을 부여하겠다는 의미이고 ','로 구분하여 여러 권한 및 여러 계정에 한번에 부여가 가능하다. 계정명에 PUBLIC을 사용하면 모든 계정에 권한 적용이 가능한데 이것은 더미 유저이다.

GRANT 권한명 TO 계정명 WITH ADMIN OPTION; // 권한에 대한 관리자 역할을 수행할 수 있게 한다. 해당 권한을 계정이 마음대로 부여하고 삭제가 가능하다.

 

SYSDBA는 SYSOPER보다 권한 범위가 훨씬 넓다. SYSDBA에서 SYSOPER PRIVILEGES WITH ADMIN OPTION을 사용하면 SYSDBA를 이용해 SYSOPER 권한을 줄수있다.

SYSDBA권한을 줄수있지만 사용이 불가능하다. 왜냐하면 접속시 계정이 SYS로 바뀌기 때문에 계정 비밀번호가 노출되지 않는다.

REVOKE 권한명 FROM 계정명; // 계정이 가진 권한을 삭제하는 명령어이며 권한명과 계정명에 들어가는 형식은 GRANT와 동일하다. 다만 계정으로부터 권한을 삭제하는것이기 때문에 TO가 아닌 FROM을 사용한다. PUBLIC으로 부여한 권한은 PUBLIC으로 권한을 삭제해야한다.

 

권한을 주는 사람을 GRANTER 권한을 받는 사람을 GRANTEE라고 한다. 만약 DBA가 A에게 시스템 권한 주고 A가 B에게 시스템 권한을 주었다고 하자. 이때 B가 A의 시스템 권한삭제가 가능한가? 가능하다. 왜냐하면 시스템권한을 누가 주었는지는 의미가 없기 때문이다. 중간에 A의 시스템 권한을 삭제가 가능한가? 가능하다. 왜냐하면B가 A의 시스템 권한 삭제가 가능한것과 같은 이유이다.

 

√객체권한

 

객체권한	테이블	뷰	시퀀스	프로시저
ALTER	√		√	√
DELETE	√	√
EXECUTE				√
INDEX	√
INSERT	√	√
REFERENCE	√
SELECT	√	√	√
UPDATE	√	√

 

뷰를 DELETE하는것은 단순뷰만 가능하고 복합뷰는 불가능하다.

객체권한을 부여하는 방법은 시스템 권한을 부여하는것과 유사하다.

GRANT EXECUTE ON 프로시저 TO 계정명 ; // 계정이 프로시저를 수행할수있게 권한을 부여한다.

GRANT UPDATE ON 대상 TO 계정 WITH GRANT OPTION; // 대상에 대한 권한을 가진 계정이 다른 계정에게 권한을 부여할수있는 권한을 준다. 권한을 삭제하는 것은 자신이 권한을 준 계정과 그 계정이 권한을 준 계정만 가능하다.

 REVOKE SELECT ON 대상 FROM 계정명; // 계정이 대상에 대해 SELECT할수있는 권한을 삭제한다. 

 

만약 A가 B에게 객체 권한 주고 B가 C에게 객체 권한을 주었다고 하자. 이때 C가 B의 객체 권한삭제가 가능한가? 불가능하다. 왜냐하면 객체 권한을 누가 주었는지가 확실하기 때문이다. A가 C의 권한을 삭제할수있는가? 불가능하다. 왜냐하면 C에게 권한을 준것은 B이기 때문이다. 대신 A가 B의 권한을 삭제하면 C의 권한도 같이 삭제가 된다.

 

권한 정보를 얻는것은 아래의 뷰들을 이용해 확인이 가능하다.

 

DBA_SYS_PRIVS : 사용자와 롤이 가지고 있는 시스템 권한을 확인한다.

SESSION_PRIVS : 현재 SESSION의 권한을 확인한다. 롤을 하게되면 세션마다 권한을 다르게 사용이 가능하기 때문이다.

DBA_TAB_PRIVS : 사용자와 롤이 가지고 있는 테이블에 대한 권한을 확인한다.

DBA_COL_PRIVS : 사용자와 롤이 가지고 있는 열에 대한 권한을 확인한다.

 

롤은 오브젝트 권한들의 묶음이다. 롤을 사용하게되면 동적으로 권한 관리가 가능하게되어 여러사람에게 동시에 권한을 부여하거나 삭제가 가능하다.

 

CREATA ROLE 롤이름

IDENTIFIED BY 비밀번호; // 롤을 생성한다. 비밀번호 생성도 가능하지만 특별한 상황외에는 사용하지 않는다.

오라클에서 롤을 생성할때 가이드라인을 제공하기 위해 롤을 미리 정의해놓았다.

롤 이름	설명
CONNECT, RESOURCE, DBA	접속이나 관리를 위한 권한
EXP_FULL_DATABASE	데이터베이스를 외부 파일로 저장
IMP_FULL_DATABASE	외부파일을 데이터베이스안에 저장
DELETE_CATALOG_ROLE	데이터 딕셔너리 테이블에 대한 DELETE 권한
EXECUTE_CATALOG_ROLEG	데이터 딕셔너리 테이블에 대한 EXECUTE 권한
SELECT_CATALOG_ROLE	데이터 딕셔너리 테이블에 대한 SELECT 권한

 

ALTER ROLE 롤이름

[NOT IDENTIFIED]; // 롤을 수정한다. NOT IDENTIFIED를 사용하면 롤에 있는 비밀번호를 삭제한다.

GRANT 롤이름 TO 계정; // 시스템 권한처럼 계정에게 롤을 사용할수있게 할당해준다.

GRANT 롤이름 TO 롤이름; // 롤을 롤에게 할당한다. 주의할점은 롤과 롤사이의 권한이ㄹ

 

ALTER USER 계정명 DEFAULT ROLE; // 권한은 DEFAULT권한만 사용한다. 나머지는 SET해서 사용해야한다.

ALTER USER 계정명 DEFAULT ROLE ALL; // 기본 롤만 사용한다.

ALTER USER 계정명 DEFAULT ROLE ALL EXCEPT 롤이름; // 기본롤을 사용하지만 적혀진 롤만 사용하지 않는다.

ALTER USER 계정명 DEFAULT ROLE ALL EXCEPT NONE; // 기본 롤 없이 사용한다.

 

SET ROLE 롤이름 IDENTIFIED BY 비밀번호; // 현재 롤을 활성화 하고 비밀번호가 있다면 적어줘야 한다. 이때 롤을 추가사용하고 싶다면 이전에 사용하고 있던 롤도 같이 적어줘야 한다. // 비밀번호도 순서를 맞춰야하나?

SET ROLE ALL EXCEPT 롤이름; // 특정 롤만 제외하고 활성화 시킨다.

 

REVOKE 롤이름 FROM 계정; // 계정이 가진 롤을 삭제한다. 시스템권한과 마찬가지로 PUBLIC으로 준 롤은 PUBLIC으로 삭제해야한다.

 

DROP ROLE 롤이름; // 롤을 제거한다. 롤을 제거하기 위해서는 ADMIN OPTION또는 DROP ANY ROLE 권한이 필요하다.

 

롤 생성 지침은 기업의 업무분석이 끝난 후에 수행해야 한다. 직책, 직위롤, 직무(업무)롤 그에 따른 권한 이런 구조로 생성해야한다.

 

롤에대한 정보는 아래와 같은 뷰를 통해 얻을 수 있다.

 

DBA_USERS : 모든 사용자의 목록을 출력한다.

DBA_ROLES : 모든 롤의 목록을 출력한다.

 

DBA_ROLE_PRIVS : 사용자와 롤이 가진 롤에 대한 권한을 확인한다.

DBA_SYS_PRIVS : 사용자와 롤이 가진 시스템에 대한 권한을 확인한다.

DBA_TAB_PRIVS : 사용자와 롤이 가진 테이블에 대한 권한을 확인한다.

 

ROLE_ROLE_PRIVS : 롤이 가진 롤에 대한 권한을 확인한다. DBA_ROLE_PRIVS에 부분집합이다.

ROLE_SYS_PRIVS :  롤이 가진 시스템에 대한 권한을 확인한다. DBA_SYS_PRIVS에 부분집합이다.

ROLE_TAB_PRIVS :  롤이 가진 테이블에 대한 권한을 확인한다. DBA_TAB_PRIVS에 부분집합이다.