Oracle 보안 데이터 시스템 구조 전체 접촉 (5)

◆ Oracle 서버 실 용 루틴 의 안전성
다음은 Oracle 서버 가 불법 사용자 에 게 사용 되 지 않도록 보호 하 는 몇 가지 제안 입 니 다.
(1) $ORACLE 확보HOME / bin 디 렉 터 리 에 있 는 모든 프로그램의 소유 권 은 Oracle 소프트웨어 소유자 에 게 있 습 니 다.
(2) 모든 사용자 에 게 실 용적 인 편리 (sqiplus, sqiforms, exp, imp 등) 711 권한 을 부여 하여 서버 의 모든 사용자 가 Oracle 서버 에 접근 할 수 있 도록 합 니 다.
(3) 모든 DBA 에 게 실 용적 인 루틴 (예 를 들 어 SQL * DBA) 700 권한 을 줍 니 다.Oracle 서버 와 유 닉 스 그룹 은 로 컬 서 비 스 를 방문 할 때 운영 체제 에서 Oracle 서버 의 역할 을 유 닉 스 그룹 에 투사 하 는 방식 으로 유 닉 스 관리 서버 의 안전성 을 사용 할 수 있 습 니 다. 이러한 방법 은 로 컬 방문 에 적응 할 수 있 습 니 다.
유 닉 스에 서 Oracle 서버 역할 을 지정 하 는 형식 은 다음 과 같 습 니 다.
ora_sid_role[_dla]
그 중 sid 는 Oracle 데이터베이스 의 Oacle 입 니 다.sid;
role 은 Oracle 서버 의 역할 이름 입 니 다.
d (선택 가능) 는 이 캐릭터 가 결 성 된 값 임 을 나타 낸다.a (선택 가능) 는 이 캐릭터 가 WITH ADMIN 옵션 을 가지 고 있다 는 것 을 의미 합 니 다. 이 캐릭터 를 다른 캐릭터 에 게 만 부여 할 수 있 고 다른 사용자 가 아 닙 니 다.
다음은 / etc / group 파일 에 설 정 된 예 입 니 다.

ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root

어구 "ora test osoper d" 는 그룹의 이름 을 나타 낸다.어구 "NONE" 는 이 그룹의 비밀 번 호 를 표시 합 니 다.숫자 1 은 이 그룹의 ID 를 나타 낸다.다음은 이 팀 의 구성원 이다.앞의 두 줄 은 Oracle 서버 역할 의 예 로 test 를 sid, osoper 와 osdba 를 Oracle 서버 역할 의 이름 으로 사용 합 니 다.osoper 는 사용자 에 게 분 배 된 부족 한 역할 입 니 다. osdba 는 WITH ADMin 옵션 을 가지 고 있 습 니 다.이러한 데이터베이스 역할 을 하기 위해 서 는 데이터베이스 시스템 을 shutdown 하고 Oracle 데이터베이스 파라미터 파일 initORACLE 을 설정 해 야 합 니 다.SID. ora 중 osroles 매개 변 수 는 True 이 고 데이터 베 이 스 를 다시 시작 합 니 다.이 캐릭터 들 에 게 connect internal 권한 을 주 고 싶다 면, orapwd 를 실행 하여 이 캐릭터 들 에 게 비밀 번 호 를 설정 하 십시오.connect internal 을 시도 할 때 입력 한 비밀 번 호 는 캐릭터 에 대응 하 는 권한 을 표시 합 니 다.
◆ SQL * DBA 명령 의 안전성
SQL * PLUS 프로그램 이 없 으 면 SQL * DBA 를 사용 하여 SQL 검색 권한 과 관련 된 명령 을 Oracle 소프트웨어 소유자 와 DBA 그룹의 사용자 에 게 만 할당 할 수 있 습 니 다. 이 명령 들 은 특수 한 시스템 권한 을 부여 하기 때 문 입 니 다.
(1) startup
(2) shutdown
(3) connect internal
◆ 데이터베이스 파일 의 안전성
Oracle 소프트웨어 의 소유 자 는 이 데이터베이스 파일 ($ORACLE HOME / dbs / *. dbf) 에 이 파일 들 의 사용 권한 을 0600: 파일 의 소유 자 는 읽 고 쓸 수 있 으 며 같은 그룹의 사용자 와 쓸 수 있 는 권한 이 없습니다.
Oracle 소프트웨어 의 소유 자 는 데이터베이스 파일 을 포함 하 는 디 렉 터 리 를 가 져 야 합 니 다. 안전성 을 높이 기 위해 같은 그룹 과 다른 그룹 사용자 가 이 파일 에 대한 읽 을 수 있 는 권한 을 회수 하 는 것 을 권장 합 니 다.
◆ 네트워크 보안
네트워크 보안 을 처리 할 때 다음은 추가 로 고려 해 야 할 몇 가지 문제 이다.
(1) 인터넷 에서 비밀 번 호 를 사용 하 는 원 격 사용 자 는 암호 화 또는 암호 화 되 지 않 은 방식 으로 비밀 번 호 를 입력 할 수 있 습 니 다. 암호 화 되 지 않 은 방식 으로 비밀 번 호 를 입력 할 때 비밀 번 호 는 불법 사용자 에 의 해 차단 되 어 시스템 의 안전성 을 파괴 할 수 있 습 니 다.
(2) 네트워크 상의 DBA 권한 제 어 는 다음 두 가지 방식 으로 네트워크 상의 DBA 권한 을 제어 할 수 있 습 니 다.
A 원 격 DBA 접근 거부 로 설정 하기;
B. orapwd 를 통 해 DBA 에 특별한 비밀 번 호 를 설정 합 니 다.
◆ 보안 전략 수립
시스템 보안 정책
(1) 관리 하 다. 데이터베이스 사용자: 데이터베이스 사용 자 는 Oracle 데이터베이스 정 보 를 방문 하 는 경로 이기 때문에 데이터베이스 사용 자 를 관리 하 는 안전성 을 잘 유지 해 야 한다.데이터베이스 시스템 의 크기 와 데이터베이스 사용 자 를 관리 하 는 데 필요 한 작업량 에 따라 데이터베이스 보안 관리 자 는 create, alter, 또는 drop 데이터베이스 사용 자 를 가 진 특수 사용자 일 수도 있 고, 이러한 권한 을 가 진 사용자 일 수도 있다. 주의해 야 할 것 은 신뢰 할 만 한 사람 만 이 데이터베이스 사용 자 를 관리 할 수 있 는 권한 이 있어 야 한 다 는 것 이다.
(2) 사용자 신분 확인: 데이터베이스 사용 자 는 운영 체제, 네트워크 서비스 또는 데이터 베 이 스 를 통 해 신분 확인 을 할 수 있 고 호스트 운영 체 제 를 통 해 사용자 신분 인증 을 할 수 있 는 장점 은 다음 과 같다.
A. 사용 자 는 데이터 베 이 스 를 더욱 빠 르 고 편리 하 게 연결 할 수 있다.
B. 운영 체 제 를 통 해 사용자 의 신분 확인 을 집중 적 으로 제어 한다. 만약 에 운영 체제 가 데이터베이스 사용자 정보 와 일치 하면 Oracle 은 사용자 이름과 비밀 번 호 를 저장 하고 관리 할 필요 가 없다.
C 사용자 가 데이터베이스 에 들 어 가 는 것 과 운영 체제 감사 정보 가 일치 합 니 다.
(3) 운영 체제 안전성
A 데이터베이스 관리 하 다. 직원 은 create 와 delete 파일 의 운영 체제 권한 이 있어 야 합 니 다.
B. 일반 데이터베이스 사용 자 는 create 또는 delete 와 데이터베이스 관련 파일 의 운영 체제 권한 이 있어 서 는 안 됩 니 다.
C 만약 에 운영 체제 가 데이터베이스 사용자 에 게 역할 을 분배 할 수 있다 면 안전성 관리 자 는 운영 체제 계 정 보안 구역 을 수정 하 는 운영 체제 권한 이 있어 야 한다.
◆ 데이터 보안 정책
데이터 의 생 성 고려 는 데이터 의 중요성 에 기초 해 야 한다.데이터 가 중요 하지 않 으 면 데이터 보안 정책 을 조금 늦 출 수 있 습 니 다.그러나 데이터 가 중요 하 다 면 데이터 대상 방문 에 대한 효과 적 인 통 제 를 유지 하기 위해 신중 한 보안 전략 이 있어 야 한다.
◆ 사용자 보안 정책
(1) 일반 사용자 의 안전성
A 암호 의 안전성: 사용자 가 데이터 베 이 스 를 통 해 사용자 의 신분 을 확인 하 는 경우 암호 화 방식 으로 데이터 베 이 스 를 연결 하 는 것 을 권장 합 니 다.이런 방식 의 설정 방법 은 다음 과 같다.
클 라 이언 트 의 oracle. ini 파일 에 ora 설정encrypt_login 수 는 true 입 니 다.
서버 쪽 에 있 는 initORACLESID. ora 파일 에 dbling 설정encypt_login 인 자 는 true 입 니 다.
B 권한 관리: 사용자 가 많 고 응용 프로그램 과 데이터 대상 이 풍부 한 데이터베이스 에 대해 '역할' 이라는 메커니즘 이 가지 고 있 는 편리 성 을 충분히 이용 하여 권한 을 효과적으로 관리 해 야 한다.복잡 한 시스템 환경 에 대해 '역할' 은 권한 의 이 치 를 크게 간소화 할 수 있다.
(2) 단말 사용자 의 안전성
터미널 사용 자 를 대상 으로 보안 정책 을 제정 해 야 합 니 다.예 를 들 어 많은 사용자 가 있 는 대규모 데이터 베이스 에 대해 안전성 관리 자 는 사용자 그룹 을 이러한 사용자 그룹 으로 분류 하여 사용자 역할 을 만 들 고 필요 한 권한 과 응용 프로그램 역할 을 모든 사용자 역할 에 부여 하 며 사용자 에 게 해당 하 는 사용자 역할 을 분배 하도록 결정 할 수 있다.특수 한 응용 요 구 를 처리 할 때 안전성 관리자 도 특정한 권한 요 구 를 사용자 에 게 명확 하 게 부여 해 야 한다.터미널 사용자 에 게 '역할' 을 사용 하여 권한 관 리 를 할 수 있 습 니 다.
◆ 데이터베이스 관리자 보안 정책
(1) sys 와 system 사용자 의 연결 보호
데이터 베 이 스 를 만 든 후 관리 권한 이 있 는 sys 와 system 사용자 의 비밀 번 호 를 즉시 변경 하여 불법 사용자 가 데이터 베 이 스 를 방문 하 는 것 을 방지 합 니 다.sys 와 system 사용자 가 데이터베이스 에 연결 되면 사용 자 는 다양한 방식 으로 데이터 베 이 스 를 변경 할 수 있 는 강력 한 권한 을 가진다.
(2) 관리자 와 데이터베이스 의 연결 보호
데이터베이스 관리자 만 데이터베이스 에 관리 권한 으로 연결 할 수 있 을 것 입 니 다. sysdba 나 startup, shutdown, recover 또는 데이터베이스 대상 (예 를 들 어 create, drop, delete 등) 으로 제한 없 는 작업 을 할 수 있 습 니 다.
(3) 캐릭터 로 관리자 권한 관리
◆ 응용 프로그램 개발 자의 보안 정책
(1) 응용 프로그램 개발 자 와 그들의 권한 데이터베이스 응용 프로그램 개발 자 는 특수 권한 그룹 이 자신의 일 을 완성 해 야 하 는 유일한 데이터베이스 사용자 이다.개발 자 는 create table, create, procedure 등 시스템 권한 이 필요 합 니 다. 그러나 개발 자가 데이터 베 이 스 를 조작 하 는 것 을 제한 하기 위해 특정한 시스템 권한 만 개발 자 에 게 부여 해 야 합 니 다.
(2) 응용 프로그램 개발 자의 환경
A. 프로그램 개발 자 는 터미널 사용자 와 데이터베이스 자원 을 경쟁 해 서 는 안 됩 니 다.
B. 프로그램 개발 자 는 데이터베이스 의 다른 응용 제품 을 손상 시 킬 수 없습니다.
(3) free 와 controlled 응용 프로그램 개발 응용 프로그램 개발 자 는 두 가지 권한 이 있 습 니 다.
A free development
응용 프로그램 개발 자 는 table, index, procedure, package 등 새로운 모델 대상 을 만 들 수 있 습 니 다. 응용 프로그램 개발 자 는 다른 대상 에 독립 된 응용 프로그램 을 개발 할 수 있 습 니 다.
B controlled development
응용 프로그램 개발 자 는 새로운 모델 대상 을 만 들 수 없습니다.모든 필요 한 table, indes procedure 등 은 데이터베이스 관리자 에 의 해 만들어 집 니 다. 데이터베이스 관리자 가 데이터 공간. 의 사용 과 데이터 베 이 스 를 방문 하 는 경 로 를 완전히 제어 할 수 있 도록 보장 합 니 다.그러나 응용 프로그램 개발 자 들 도 이 두 가지 권한 의 혼합 이 필요 할 때 가 있다.
(4) 응용 프로그램 개발 자의 역할 과 권한 데이터베이스 보안 관리 자 는 전형 적 인 응용 프로그램 개발 자의 권한 요 구 를 관리 하기 위해 역할 을 만 들 수 있다.
A create 시스템 권한 은 응용 프로그램 개발 자 에 게 자주 부여 되 어 데이터 대상 을 만 들 수 있 습 니 다.
B 데이터 대상 역할 은 응용 프로그램 개발 자 에 게 사용 하 는 역할 을 거의 부여 하지 않 습 니 다.
(5) 응용 프로그램 개발 자의 공간 제한 을 강화 하여 데이터베이스 보안 관리자 로 서 모든 응용 프로그램 개발 자 에 게 다음 과 같은 제한 을 설정 해 야 합 니 다.
A 개발 자 는 table 또는 index 의 표 공간 을 만 들 수 있 습 니 다.
B. 모든 표 공간 에서 개발 자가 가 진 공간 점유 율 입 니 다.응용 프로그램 관리자 의 안전 은 많은 데이터베이스 응용 프로그램의 데이터베이스 시스템 에서 응용 프로그램 관리자 가 필요 할 수 있 습 니 다. 응용 프로그램 관리 자 는 다음 과 같은 임 무 를 맡아 야 합 니 다.
a) 모든 프로그램 에 캐릭터 를 만 들 고 모든 프로그램의 역할 을 관리 합 니 다.
b) 데이터베이스 응용 프로그램 이 사용 하 는 데이터 대상 을 만 들 고 관리 합 니 다.
c) 필요 하 다 면 응용 프로그램 코드 와 Oracle 의 저장 과정 과 패 키 지 를 유지 하고 업데이트 합 니 다.
나 는 이상 의 건의 가 있 으 면 Oracle 의 관리자 로 서 그의 본업 을 충분히 잘 할 수 있 을 것 이 라 고 믿는다.그러나 우리 가 아무리 노력 해도 이런 현실 에 직면 해 야 한다. 그것 은 바로 Oracle 은 다른 사람 이 개발 한 것 이 고 우 리 는 사용 하고 있다 는 것 이다.그래서 오 라 클 은 도대체 얼마나 구멍 이 있 는 지 - 나 는 이것 이 너 와 내 가 해결 할 수 있 는 것 이 아니 라 고 생각한다.그러나 Oracle 데이터 안전 을 논의 하 는 글 인 만큼 허점 이라는 부분도 쓸 필요 가 있다 고 생각 합 니 다. 이것 도 '안전' 이 없어 서 는 안 될 부분 이기 때 문 입 니 다.허허!
그래서...
틀림없이 나 는 더 이상 아래로 들 이유 가 없 을 것 이다. 왜냐하면 독자 들 은 이미 다른 효과 적 인 경로 에서 Oracle 의 빈틈 에 관 한 최신 정 보 를 얻 었 기 때문이다.나 는 더 이상 군말 하지 않 겠 다.
한 마디 로 "Oracle 데이터 안전 은 넓 고 심오 한 화제 이다. 인내심 이 없다 면 그 정 수 를 영원히 얻 지 못 할 것 이다."