14. 데이타베이스 & 트랜잭션 모니터

• 트랜잭션 모니터
  • X/Open DTP : 문서
  • Unisys Open/OLTP 또는 IMC TUXEDO
    • 일반
      • 특성
      • 호환성
      • 문서
      • 트랜잭션 무결성
    • 책임추적성
      • 사용자 식별 / 인가
      • 감사 증적
    • 접근 통제
      • 객체 재사용
    • 안전한 데이타 교환
      • 통신상대방 인증
      • 무결성
      • 기밀성
      • 데이타 발신지 인증
      • 송 / 수신 부인 방지
    • 가용성
      • 부하 분산 (Load Balancing)
      • 서비스 중복성 (Redundancy)
      • 마스터 중복성 (Redundancy)
      • WSH (Workstation Handler) 중복성 (Redundancy)
  • Oracle 7에 대한 OLTP 인터페이스
  • HIT (Host Integration Toolkit) 1.0
    • 일반
      • 설치
      • 트랜잭션 무결성
    • 책임추적성
      • 사용자 식별 / 인가
      • 감사 증적
    • 접근 통제
      • 유닉스 로그인 보안
      • 파일 시스템
      • 객체 재사용
    • 안전한 데이타 교환
      • 통신 상대방 인증
      • 무결성
      • 기밀성
      • 송 / 수신 부인 방지
    • 가용성
      • 서비스 중복성 (Redundancy)
• 데이타베이스
  • (관계형) 데이타베이스를 위한 일반적 지침
    • 일반
    • TCSEC 평가된 데이타베이스
    • 트랜잭션 무결성
    • 책임추적성
      • 사용자 식별 / 인가
      • 감사 증적
    • 접근 통제
      • 유닉스 로그인 보안
      • 파일 시스템
      • 뷰 및 저장 프로시져 (stored procedures)
      • 객체 재사용
    • 통신 / 안전한 데이타 교환
      • 통신 상대방 인증
      • 무결성
      • 기밀성
      • 데이타 발신지 인증
      • 송 / 수신 부인 방지
    • 가용성
      • 백업
      • 자원 남용 방지
      • 복제
      • 중복성 (Redundancy)
  • Sybase: 4.9.x , System 10, System 11
  • Microsoft SQL server
    • 일반
    • 책임추적성
      • 식별 / 인가
        • 개요
        • 추천
      • 감사 증적
    • 접근 통제
      • 뷰 및 저장 프로시져 (stored procedures)
      • 파일시스템
      • 객체 사용허가
      • 객체 재사용
    • 통신 / 안전한 데이타 교환
      • 통신 상대방 인증
      • 기밀성
    • 가용성
      • 백업 / 복구
        • 복구
        • 일관성 검사
      • 조직
      • 중복성
        • 모니터링
        • 복제
        • 미러링
    • SQL Server V6.0
  • Oracle 7.1 또는 그 이후
    • 일반
      • 위험
      • 문서
    • 책임추적성
      • 식별 / 인가
      • 감사 증적
    • 접근 통제
      • 임의적 접근 통제
      • 안전한 시스템 시동
    • 안전한 데이타 교환 / 통신
      • 통신 상대방 인증
      • 데이타 무결성
      • 데이타 기밀성
      • 송 / 수신 부인 방지
      • 접근 통제
    • 가용성
      • 자원 남용 방지
      • 백업 및 복원
      • 중복성 : 복제

트랜잭션 모니터

X/Open DTP

X/Open DTP (Distributed Transaction Processing, 분산 트랜잭션 프로세싱) 표준은 USLs TUXEDO을 기반으로 하며 OLTP (Online Transaction Processing, 온라인 트랜잭션 프로세싱)를 위한 표준이다. 트랜잭션 프로세싱은 다중 사용자와, 다중 데이타베이스 또는 다른 공유자원들간의 상호작용을 정의하고 조율하는 응용프로그래밍 시스템이다. DTP는 다중 자원들과 네트웍에 연결된 시스템들을 포함하도록 확장된 트랜잭션 프로세싱이다. 온라인 트랜잭션 프로세싱은 DTP에서 개별 트랜잭션들의 로깅과 실행을 담당하는 부분이다.

DTP는 이기종 환경의 많은 시스템들간에 (어쩌면 트랜잭션 지향적인) 어플리케이션이 분산될 수 있게 해주는 미들웨어로 설명될 수 있다.
DTP는 3개의 모듈로 구성된다:

1. AP = Application, 어플리케이션
2. TM = Transaction Manager, 트랜잭션 관리자
3. RM = Resource Manager, 자원 관리자 (종종 데이타베이스에는 프론트 엔드). RM은 이단계 commit (2PC, two phase commit)을 할 수 있어야 하고 XA 프로토콜을 지원해야 한다.

DTP 표준에는 다음 프로토콜들이 정의되어 있다:

• XAPTMI = AP to TM 프로토콜
• XA = RM to TM 프로토콜. TM이 항상 연결을 시작하지만, RM은 자신을 TM에 등록/철회할 수 있다. XA는 동기식이거나 (선택적으로) 비동기식일 수 있다. XA는 xa_start(), xa_commit(), xa_complete(), xa_recover(), xa_rollback() 같은 기능들을 통해 2PC를 가능하게 한다.
• AP의 서버 부분은 SQL 이나 다른 프로토콜을 통해 RM과 이야기 한다.
• TMS = Transaction Management System, 트랜잭션 관리 시스템은 분산 데이타베이스 상에 2PC를 구현하는데 필요하다.
• TX = 글로벌 트랜잭션을 정의하고 관리하기 위한 AP to TM 프로토콜. 연쇄(chained) 또는 비연쇄(unchained) 트랜잭션을 지원한다. e.g. tx_begin(), tx_commit(), tx_rollback().
• TxRPC = AP to CRM 프로토콜, DCE RPC에 기반함.
• XA+ = TM to CRM 프로토콜. XA를 기반으로 하며, RM이 TM과 통신을 시작하는 데 필요한 verb들을 정의한다. 표준이 될 수 없고, 논쟁이 되며, TP 작업그룹의 1993년 회의에서 부결되었다. USL이 원하지 않는다.

XATMI는 Tuxedo's ATMI의 부분집합이다. - 트랜잭션, 인가, 대기열(queuing)이나 전달(forwarding) 기능이 없다. XATMI는 버퍼 타입 X_OCTET (Tuxedo CARRAY와 동위), X_C_TYPE (Tuxedo VIEW와 동위) 그리고 X_COMMON (X_C_TYPE과 비슷하나 COBOL과 C 모두에 쓰임)을 정의한다.Tuxedo FML 버퍼 타입은 표준의 일부가 아니다.

TxRPC는 개조된 RPC이다: 트랜잭션을 지원하기 위해, 제약과 새로운 기능들 (transactional RPC)이 추가되었다. 두가지 유형이 있다: 하난는 전적인 DCE 구현과 다른 하나는 오직 IDL 만 (DCE 런타임이 없음). Transarc's Encina 는 TxRPC를 사용한다.

그밖의 메모:

저장 메시지 (Stored messages): 요청 메시지가 나중에 처리되기 위해 안정적인 저장공간에 쓰여지는 기관. 보다 고도의 복구성(recoverability)과 신뢰성(reliability)을 제공하며 (각 요청이 정확히 한번 수행되도록 보장됨) 보다 "메인프레임 적"이다. 네 가지 대기열(queue) 유형이 존재한다: 요청, 응답, 실패 및 에러 대기열. TMS_QM가 저장 메시지를 위한 TM 서버이며, TMQUEUE는 대기열을 관리하는 서버, 그리고 TMQFORWARD는 요청을 다른 서비스로 전달할 수 있게 해준다.

CPI-C 는 LU6.2에 대한 X/Open 인터페이스이다.

Peer-to-peer: AP들 간의 반이중(half duplex) 통신을 가능하게 한다.

OSI TP: OSI 프로토콜과 서비스들에게 트랜잭션 의미체계(semantics)를 제공한다.

XAP: OSI 프로토콜 스택의 프리젠테이션 계층에 있는 서비스들로의 연결을 위한 API. X.400, FTAM, 디렉토리 서비스, 네트웍 관리,VPT같은 OSI 어플리케이션의 이식성(portability)을 제공한다.

XAP-TP OSI TP 서비스 구성요소와 프리젠테이션 계층에 대한 인터페이스. XAP 프로토콜의 확장이다.

문서

• X/Open CAE Specification: "Distributed Transaction Processing: The XA Specification". (ISBN 1 872630 24 3, 1991)
• TX Specification (preliminary): ISBN 1 872630 650
• XATMI Snapshot specification: ISBN 1 872630 804

Unisys Open/OLTP 4.2.2 = IMC TUXEDO 4.2.2 (for UNIX/NT/PC)

Open/OLTP는 Unisys에서 X/Open DTP 표준을 구현한 것이다. IML은 유닉스과 PC 버전 Open/OLTP의 실제 개발자이다, 따라서 Open/OLTP = IML Tuxedo.
Illustration:

LU6.2(syncpoint level 2)에 대한 인터페이스가 존재하지 않으므로 IMS 호스트들과의 글로벌 트랜잭션은 확실히 아직 불가능하다.

일반

특성

• Open/OLTP는 유닉스& MVS 메인프레임 그리고 윈도우 NT에서 돌아간다. 도스/윈도우 PC들은 Tuxedo/WS (from IMC) 또는 TDWIN (Transactional Desktop for Windows, from Unisys)라는훨씬 줄어든 OLTP 클라이언트를 가질 수 있다. Tuxedo/WS 는 유닉스 시스템 상의 WSH에 연결하여 OLTP 서비스에 접속한다 (V4.2 또는 그 이후). 매킨토시들도 PLTP에 접속할 수 있다.
• 마스터 BBS 서버는 PC 클라이언트가 될 수 없다.
• Tuxedo에서, TM은 프로세스가 아니다. 어떤 서비스와 서버들이 어디에서 사용 가능한 지에 대한 정보를 가지고 있는 분산 게시판 (distributed bulletin board)으로부터 TM의 기능이 달성된다. 마스터 OLTP 서버는 게시판의 배포 및 유지에 대한 책임이 있다 (BBL - Bulletin Board Liaison을 통해).
• 세 가지 통신 모드를 사용할 수 있다: 동기식 tpcall(), 비동기식 tpacall() 그리고 대화식 tpsend() 모드.
• 다중 노드(Multi-node) 구성은 물리적으로 떨어진 시스템들에 대해 서비스 호출이 일어나야 하는 경우에만 요구된다.
• 환경 변수 TMCMPLIMIT가 설정되어 있으면 시스템과 어플리케이션 메시지들이 압축될 수 있다. 추천. 아래 기밀성 절을 참고한다.

호환성

• Open/OLTP는 USL의 Tuxedo와 100% 호환되어야 한다.
• The DTP X/OPEN 표준은 Tuxedo에 있는 기능들 중 (매우 유용한) FML 필드같은 몇 가지를 가지고 있지 않다.
• Tuxedo 는 CARRAY (X_OCTET과 동위), VIEW (X_C_TYPE과 동위) 버퍼 타입을 정의한다. X_COMMON 버퍼(VIEW 와 비슷하지만 COBOL과 C에 모두 사용)는 사용할 수 없다. Tuxedo에서 사용가능한 FML 버퍼 타입은 DTP 표준에 포함되지 않는다.
• 지원되는 데이타베이스: Oracle 7, Informix, Sybase 10 (확실), Sybase 11 (계획?). 모름: MS-SQL Server V6

문서

원래의 USL Tuxedo 문서를 참조한다. 저자는 Unisys에서 나온"U6000 Series TransIT Open/OLTP Transaction Manager - Administration Guide", November 1994 (버전 4.2.1) 를 쓴다 .

트랜잭션 무결성

RM이 이단계 commit (2PC) XA 프로토콜을 구현하고, 클라이언트가 ATMI 2PC 기능 호출 (e.g. tpcommit()) 을 올바르게 사용하며 RM을 제어하는 서비스가 XA 2PC 기능 호출들 (e.g. xa_precom(), xa_commit() )을 올바르게 사용한다면 트랜잭션 무결성이 보장된다. 클라이언트와 서비스는 각기 그들의 트랜잭션들을 중단하고 나서 롤백이 발생할 것을 확신할 수 있다.

XA가 사용하는 2PC 프로토콜은 2PC의 두번째 단계에서 트랜잭션 로그(TLOG)의 사용을 필요로 한다. TM은 현재 분산 트랜잭션의 복구를 위해 TLOG 를 사용한다. OLTP 서버마다 하나의 TLOG가 있다. TLOG는 raw device 나 파일에 쓰여질 수 있다.

책임추적성

사용자 식별 / 인가

안전한 데이타 교환: 통신 상대방 인증 절도 참고한다.

• 유닉스 로그인 보안: The OLTP 서버는 전용 사용자 아래서 시작되어야 한다, e.g. tuxedo 또는 tm4-2-2. 가능하면 이 계정은 잠겨져야 한다. 이 사용자의 홈 디렉토리는 (e.g. $APPDIR) 모든 OLTP 서버와 서비스 구성 파일들 (e.g. UBBCONFIG)이 있는 곳이어야 한다.
• ULOG와 TLOG파일의 사용허가가 rw----------이 되도록 보장하기 위해, 이 사용자에 대한 umask는 077로 설정한다.

감사 증적

• 모든 로그 파일들은 사용허가 0600을 가져야 하고 주기적으로 모니터, 보관 및 가지치기 (불필요한 것을 없애고 간결하게) 해야 한다.
• 모든 로그파일들을 /var 같은 별도의 파티션에 보관할 것을 제안한다.
• The UNIX system logs should ensure a record of attempts to access the UNIX accountsOLTP operation and administration (e.g. via syslogd).
• OLTP 서버 프로세스는 서버 에러를 (ASCII) ULOG 파일 (각 서버 시스템에 존재) 에 쓴다. 어플리케이션들은 userlog() 함수를 사용하여 이 로그에 쓸 수 있다. ULOG 는 매일 생성된다. ULOG 경로는 UBBCONFIG 에 있는 SERVERS/ULOGPFX 에 지정된다.
• 서버는 또한 호출된 서비스를 ULOG에 로그할 수도 있다 (UBBCONFIG option CLOPT -r, man txrpt 참조). 이것은 다양한 서비스 호출의 동기화를 알기 위한 감사 증적에 도움이 될 수 있다.
• 서비스들은 디폴트로 stdout 와 stderr 파일에 쓴다. 이들을 사용한다면, 서비스 이름을 표시하도록 파일 이름을 변경해야 한다 (SERVERS UBBCONFIG파일에 있는 CLOPT 변수로 지정할 수 있다).
• 각 어플리케이션마다 특별한 감사 로그를 둘 것을 제안한다: 각 응용 서버는 클라이언트로부터의 각 호출에 대해 두 개의 항목을 로그에 쓸 것이다. E.g. 클라이언트가 서비스를 호출할 때, 서비스는 다음을 로그에 기록한다: 사용자, 날짜, 시간, 클라이언트 IP 주소, 함수, 함수 매개변수. 서비스가 클라이언트의 요청 작업을 완수했을 때, 클라이언트에게 리턴된 정보를 상세하게 로그에 또 다른 항목으로 남긴다. (서비스가 클라이언트 IP 주소를 얻는 것이 가능한가?)

접근 통제

• 게시판 (Bulletin Board) 보호: PERM 변수는 IPC 공유 세그먼트를 생성할 때 사용되는 사용허가를 규정한다. 소유주에 대해서만 읽기/쓰기 사용허가를 권고한다. ipcs 명령어는 모든 공유 세그먼트와 그 사용허가를 보여준다. UBBCONFIG 파일은 다음과 같이 구성되어야 한다:

*RESOURCES

PERM 0600 [게시판 & 요청 대기열: IPC 사용허가]
SYSTEM_ACCESS FASTPATH [Unisys에서 PROTECTED는 생산환경에서 쓸 수 없다고 말한다]

*MACHINES

PERM as RESOURCES/PERM

*SERVICES

RQPERM as RESOURCES/PERM
RPPERM as RESOURCES/PERM
SYSTEM_ACCESS as RESOURCES/SYSTEM_ACCESS

• SYSTEM_ACCESS 변수는 두 개의 값을 가질 수 있다 (V4.2나 그 이후), PROTECTED (Tuxedo 내부 테이블들을 위한 공유 메모리는 Tuxedo 라이브러리 외부의 코드에서는 접근할 수 없다) 또는 FASTPATH (내부 공유 메모리가 보호되지 못한다). Unisys는 FASTPATH를 사용해야 한다고 지적했지만, 이것은 아마 이들이 아직 4.1을 사용하고 있기 때문인 것 같다. (Unisys: 확인바람!). 최대의 보안을 위해서는, PROTECTED 가 더 좋을 것이다.
• 요청 대기열과 응답 대기열 사용허가는 RQPERM 와 RPPERM 변수에 의해 통제된다. 이들은 0600으로 설정되어야 한다 (위의 PERM 처럼). 이 매개변수들이 명시되지 않으면, PERM 값이 사용된다.
• 파일 시스템:$APPDIR 디렉토리 (e.g. ~tuxedo)에 대해 파일 및 디렉토리 사용 허가가 각기 설정되어야 한다. 즉
  chmod 700 ~$APPDIR
  chmod -R w-rwx,g-rwx ~$APPDIR/*
  chown -R tuxedo ~$APPDIR/*
• OLTP 이진(binary) 디렉토리 (e.g. $ROOTDIR ) 는 보통 root 에 소속되며 root 만 쓰기 가능하다.
  chmod 755 ~$ROOTDIR
  chmod -R w-rwx,g-rwx ~$ROOTDIR/*
  chown -R tuxedo ~$ROOTDIR/*

객체 재사용

비밀(covert) 데이타 전송을 위한 객체의 재사용은 유닉스 로그인, 파일시스템 및 공유 메모리를 위한 위의 수단들에 의해 방지되어야 한다.

안전한 데이타 교환

클라이언트는 ATMI 함수 tpchkauth() 를 사용하여 어플리케이션에서 요구되는 보안의 레벨을 확인할 수 있다. 그리곳 나서 클라이언트는 TPINIT 버퍼를 요구되는 보안 정보로 채우고 tpinit() 을 이용해 이를 서버로 보낸다.

통신 상대방 인증

OLTP는 표준으로 거의 보안을 제공하지 않지만, 어플리케이션이 엄격한 보안 기능성을 구현할 수 있는 공개 프레임웍을 제공한다. 세 가지 인증 기법이 제공된다: 서비스 기반, 클라이언트 기반 및 맞춤 (customised).

=> 서버 기반 접근 (OLTP "레벨 2" 보안)

• 서버에 대한 접근에는 패스워드가 필요하다. UBBCONFIG:에서 다음을 설정한다:
  *RESOURCES
  SECURITY APP_PW
  UBBCONFIG 가tmloadcf에 의해 처리될 때, 패스워드가 요구될 것이다. 이 서버에 연결하는 모든 클라이언트는 TPINIT 버퍼에서 이 패스워드를 제공해야 한ㄷ. 이 패스워드는 tdadmin -> passwd 또는 tmconfig에 의해 동적으로 변경될 수 있다.
• OLTP는 네트웍 상으로 패스워드(즉 TPINIT 버퍼 항목의 일부) 를 비트-마스크(bit-mask) 암호화 (즉 매우 약한 암호화) 하여 보낸다.

=> 클라이언트 기반 인증 (OLTP "레벨 3")

• 레벨 2 가 기능해야 한다.
• 초기 클라이언트 인증: 클라이언트는 서버 서비스에 접근이 허용되기 전에 먼저 인증 코드를 제공해야 한다. 인증 서버가 정의되어야 한다 (AUTHSVC). 등급 시스템들은 이 보안 기능을 구현하도록 권고한다. UBBCONFIG 파일을 다음과 같이 구성되어야 한다:
  *RESOURCES
  AUTHSVC auth_server [인증 서비스 이름, 최대 15 자]
  *SERVERS
  ,,auth_server" [인증 서버 프로그램 이름]
• 세션 인가: 초기 인증 이후, 전송되는 각 버퍼와 인증 키가 교환된다 (appkey). 이 (4 바이트) 세션 키는 각각의 통신중에 검사된다 (어플리케이션에는 투명). 대부분의 요즘 세션 키들은 길이가 최소 16 바이트로, 이 4바이트 키가 기밀 전송 보호에 충분한 지 의심스럽다.
• 디폴트 인증 서비스 AUTHSVR 가 제공된다. 이 서비스는 유닉스 스타일의 패스워드 파일을 가지고 사용자를 확인한다. AUTHSVR(5) man 페이지를 참고한다.TBD
• 등급 시스템들에 대해, 디폴트 인증 서버를 사용하지 말고 Kerberos나 NIS+ 같은 잘 알려진 시스템을 사용하도록 권고한다. 그러나, 세션 키가 취약한 4바이트로 남아있어, OLTP 인증 메카니즘은 잊어버리고 맞춤 솔루션을 구현하는게 바람직할지도 모른다.

=> 맞춤 (Customised) 인증 /인가

• tpinit() 다음에 몇 개의 특별한 tpcall() 을 사용하여 맞춤 인증을 구현할 수 있다.
• 일반적으로 알려진 세션 키를 사용하여 클라이언트에서 서버로 전달되는 매개변수들 중 하나 (또는 모두)를 암호화할 수 있다.
• 또다른 선택사항으로 표준 필드 인코딩/디코딩 루틴을 추가적인 암호화나 서명을 구현하는 특별한 루틴으로 대체할 수 있다. 그러나, 이것은 원래 인코딩/디코딩 루틴의 소스 코드에 대한 지식을 필요로 할 수도 있다.
• 어플리케이션은 새로운 통신 버퍼 타입을 정의함으로써 (tm_typesw[] 배열에 instance를 추가하여) 전송되는 데이타의 맞춤 인코딩/디코딩을 구현할 수 있다.

=> 프론트 엔드가 OLTP에 쓰여지고 AUTHSVC 서비스로서 설치된다면, NIS+나 Kerberos (따라서 DCE도) 같은 안전한 네이밍 서비스를 사용하여 인증할 수 있다. 특별한 인증 서비스들도 사용될 수 있다. (Unisys는 이미 Schweizerische Aussenministerium 를 위해 ZKM 인증 서버를 구현하였다).

무결성

OLTP 클라이언트와 서버 사이에 전송되는 데이타의 무결성은 TCP 소켓에 의해 보장된다. 추가적인 수단 (체크섬 같은)은 구현되지 않았다.

• 어플리케이션은 새로운 통신 버퍼 타입을 정의함으로써 (tm_typesw[] 배열에 instance를 추가하여) 추가적인 무결성 검사를 구현할 수 있다.
• 다중 노드: 다중 노드 구성 (tmboot)의 부팅동안, 구성 파일은 마스터로부터 모든 서버로 복사된다. 이것은 모든 서버들이 시스템 구성의 integral view를 가지도록 보장한다. 그러나, 이 기능은 시동 시간을 느려지게 한다.

기밀성

TPINIT 버퍼에 있는 패스워드 정보는 네트웍 상으로 보내지기 전에 비트 마스크(bit mask) 암호화된다. 이것은 민감한 어플리케이션에는 불충분하다, 그러므로 어플리케이션 패스워드와 인증 코드가 TPINIT 버퍼에 쓰여지기 전에 암호화되어야 한다. 암호화 메카니즘은 재생(playback)이 불가능하고 브루트 포스에 의해 쉽게 해독되지 않아야 한다. 시간 / 사용자이름 / IP주소 / 호스트 이름에 따른 유일한 세션 키를 발생시키는 공개 키 알고리듬이 권고된다.

환경 변수 TMCMPLIMIT으로 시스템 및 어플리케이션 메시지들이 압축될 수 있다 (Tuxedo 4.2.1 또는 이후). 저속 네트웍에서의 사용과 어플리케이션 시동 시간을 줄이는 데 특히 유용하다. 압축 강도는 로컬과 원격 메시지에 별도로 설정될 수 있다. 원격 압축을 설정함으로써, 로컬 압축이 없어도, 데이타는 네트웍 통신중에 명문(clear text)으로 나타나지 않는다. 이것은 우발적인 네트웍 스니퍼에 대해 매우 간단한 기밀성을 제공한다. 이 기능을 구현하려면, TMCMPLIMIT=0,MAXLONG 을 설정한다.

권고: 로컬과 원격 압축 모두 사용하라.

데이타 발신지 인증

"OLTP 레벨 3" 보안이 사용되면 데이타 발신지를 알 수 있다. TCP/IP는 인증 영역에서 명백한 취약점(IP spoofing)을 가지고 있다는 것에 주의한다.

송 / 수신 부인 방지

디지탈 서명은 OLTP에 정의되어 있지 않지만, 응용 레벨에서 구현될 수 있다.

가용성

부하 분산 (Load Balancing)

• OLTP 관리자가 UBBCONFIG 에서 SERVERS/LOAD 변수를 올바르게 정의하고 LDBAL=Y라면 정적 부하 분산이 가능하다. 각 서비스에는 가중치가 주어질 수 있고 OLTP는 이 가중치와 대기열 길이를 사용하여 어디에 요청을 대기시킬 것인지 결정할 수 있다.
• TMNETLOAD 는 원격 서비스에 비해 로컬 서비스를 편중(bias)할 수 있게 해준다.
• 대기열 정의도 역시 중요하다. 대기열은 다음과 같은 수 있다:
  MSSQ: multiple services, single queue 다중 서비스, 단일 대기열
  MSMQ: multiple services multiple queues 다중 서비스, 다중 대기열(각 서비스가 자신의 대기열을 가짐).
• MSSQ 환경에서, V4.2.1이나 이후에서는 MODEL=SHM 이면 실시간 부하 분산 (즉 게시판 통계에 따라) 이 사용된다.
• MSMQ 환경에서 MODEL=MP이면, 라운드 로빈(round-robin) 분산이 사용된다.
• 서버는 대기열에서 기다리고 있는 요청을 검사하여 자체적인 부하 분산 / 우선 순위 할당을 할 수 있다.

서비스 중복성 (Redundancy)

• OLTP는 서비스의 데이타에 의존적인 라우팅을 허용한다, 즉 여러 대의 서버가 하나의 특정한 서비스를 제공하는데, 클라이언트가 특정 서비스의 사용을 요청할 때, TM은 어떤 서버가 이 서비스를 제공하는지 확인하고, 데이타 내용에 따라 요청을 라우트한다. 라우팅 규틱은 매우 유연하다.
• 어플리케이션은 새로운 통신 버퍼 타입을 정의함으로써 (tm_typesw[] 배열에 instance를 추가하여) 맞춤 라우팅을 구현할 수 있다.
• 데이타 의존적 라우팅은 UBBCONFIG 에서 SERVICES/ROUTING 변수를 정의함으로써 가능하다.
• OLTP 노드가 (다중 노드 구성에서) 다운되면, 마스터 서버는 특정 시간 후 (UBBCONFIG 에 있는 SANITYUNITS*SANITYSCAN 매개변수 [1]에 의해 지정된) 이를 감지하여 게시판을 갱신한다. 다른 서버에서 복제 서비스가 제공되는 경우, 모든 새로운 요청들은 이 다른 서버들로 보내진다.

마스터 중복성 (Redundancy)

• 백업 마스터 OLTP가 사용될 수 있다. 즉 UBBCONFIG 는 다음과 같은 형태의 항목을 가질 수 있다:
  *RESOURCES
  MASTER master_machine_name,backup_machine_name
• 단일 노드 구성에서는 이것이 불가능하다, 따라서 중복성(여분)은 시스템 레벨에서 제공되어야 할 것이다.

WSH (Workstation Handler) 중복성

도스/윈도우 PC들은 OLTP 전체를 가지고 있지 않다. TDWIN (OLTP 클라이언트) 은 WSH 프로세스를 가지고 있는 유닉스 시스템에의 접근을 필요로 한다. OLTP 프로토콜에는 백업 WSH 서버를 지정하는 방법이 없다. 중복성을 제공하기 위해, 다음과 같이 할 수 있다:

• PC를 위한 WSH 서비스를 제공하는 유닉스 시스템은 반드시 높은 가용성을 가지고 있어야만 한다.
• PC들은 반드시 또다른 WSH 서버를 가리키는 백업 구성을 가지고 재부팅되도록 구성되어야만 한다.
• 클라이언트 응용 SW가 WSH 가용성을 테스트하고 자동으로 또다른 WSH 서버로 스위치하는 로직을 구현한다. 그러나 이것은 클라이언트 SW를 더 복잡하게 한다.

V4.2.2. 부터는 서버쪽에 타임 아웃이 있어서, PC 클라이언트가 동작하지 않고 있으면 서버는 특정 시간이 지난 후 이 PC로 열려 있는 연결을 닫는다.

Oracle 7 에 대한 OLTP 인터페이스

Oracle 7.0.12 은 XA 와 호환된다. XA 인터페이스는 요청(SQL)을 Oracle 서버로 전달할 수 있는 OLTP 서버(Oracle RM)에 OLTP 클라이언트가 접속핫 루 있게 해준다. Oracle RM 은 한 사용자 아래서 돌아가는데 (UBBCONFIG 에서 지정), 따라서 다중 OLTP 서버들은, 다른 사용자이름 하에서 DB 접근이 필요하다면 별도의 사용자들 아래서 돌아가야 한다.

• UBBCONFIG 에 정의된 OPENINFO 문자열 (Acc=P/USER/PASSWORD ) 은 사용자 계정과 패스워드를 명문 (cleartext) 으로 가지고 있을 수있다 !? 이 파일(UBBCONFIG)을 보호한다,가능하면 일단 TUXCONFIG(이진 동위파일) 을 발생하는데 한번 사용된 후, UBBCONFIG를 암호화하고 모든 명문(clear text) 복사본을 없앤다. UBBCONFIG는 생산환경 (production) 시스템에는 필요치 않다.
• OPENINFO 문자열 Logdir=은 XA 에러와 추적(tracing) 정보가 어디에 로그되는 지 지정하는 데 사용된다. 디폴트 로그 디렉토리는 $ORACLE_HOME/rdbms/log 이다. 디폴트 파일 이름은 xa_DBNAME_MMDDYY.trc 이다. Logdir 이 존재하고 쓰기 가능해야 한다.
• OPENINFO 문자열 SQLnet = 은 SQLnet V1이나 V2를 통한 로그인을 허용하는 데 사용된다. V2를 사용하도록 한다.

HIT (Host Integration Toolkit) 1.0

Unisys의 HIT 도구는 TM은 아니지만, Open/OLTP를 사용하기 때문에 여기에서 언급한다. HIT 는 telnet 이나 3270 을 통해 고전적 메인프레임 어플리케이션과 인터페이스한다. 이것은 단말 지향적 (terminal oriented) 정보를 트랜잭션으로 변환한다. 이 변환은 Open/OLTP 서버 상에서 일어난다. 클라이언트들은 보통 OLTP 를 통해 HIT 서버 서비스에 접속하지만, SThandler 프로토콜을 이용한 직접 연결도 가능하다 (여기에서 논의되지는 않지만).

일반

설치

• HIT는 SVR4 패키지 명령어를 사용하여 깔끔하게 설치/제거될 수 있다.
• "어플리케이션 관리자" 와 그룹 ST를 위한 계정이 설치 도중 생성된다.

트랜잭션 무결성

스크립트와 클라이언트 소프트웨어가 어떻게 작성되었는지에 따라 다르다. HIT 에는 트랜잭션 무결성을 내포되어있지 않다.

책임추적성

사용자 식별 / 인가

See the section 안전한 데이타 교환: 통신 상대방 인증.

감사 증적

• 모든 로그 파일들을 특별한 파티션 (즉$SPOOLDIR = /var/hit) 에 보관하고 주기적으로 아카이브 및 가지치기(prune) 할 것을 권고한다.
• HIT는 로깅, 디버깅 및 모니터링을 위해 다음 유틸리티들을 제공한다. ALARMserver 와 LOGserver 서비스를 추천한다.
  I. LOGserver
  이 서버는 트랜잭션이나 함수 스크립트에 LOG 문장이 포함되어 있으면 호출된다. LOGserver가 동작하고 있지 않으면, 모든 메시지들을 잃어버리게 된다. 메시지들은 $LOGLEVEL 이나 더 높은 우선순위를 가지고 있으면 $LOGPFX.mmddyy 에 로그된다. 메시지들이 너무 길게 대기열을 이루지 않도록 다중 서버가 권고된다.
  
  II. STATserver
  STATserver는 트랜잭션 핸들러와 서버로부터 통계 정보를 받는다. STATserver 가 동작하고 있지 않으면, 모든 통계를 잃게 된다. 메시지들은 $STATLEVEL이나 더 높은 우선순위를 가지고 있으면 $STATPFX.mmddyy 에 로그된다. 메시지들이 너무 길게 대기열을 이루지 않도록 다중 서버가 권고된다. 주의: 통계 파일들은 빠르게 커질 수 있다!!
  
  III. ALARMserver
  이 서버는 트랜잭션이나 함수 스크립트에 ALARM 문장이 포함되어 있으면 호출된다. ALARMserver가 동작하고 있지 않으면, 모든 메시지들을 잃게 된다. 메시지들은 $ALARMLEVEL 이나 더 높은 우선순위를 가지고 있으면 $ALARMPFX.mmddyy 에 로그되고 ALARM 장치에 표시된다 (e.g. 콘솔). 메시지들이 너무 길게 대기열을 이루지 않도록 다중 서버가 권고된다.
  
  IV. stmon
  서버와 트랜잭션 프로세스들이 활성화 되어 있는 동안 stmon 도구로 확인할 수 있다.
  
  V. tracing
  개발 및 디버깅 단계동안, tracing 이 유용할 수 있다. TRACE 가 0보다 크게 설정되어 있으면, 추적 정보가 TRLOGFILE로 보내진다.
  
  VI. Recv & send debugging
  $PROJDIR/envfile.app 에서, DEBUGFILE 을 사용하여 recv(), send() 와 ID 문장 로깅을 위한 파일 접두어를 지정할 수 있다.
  어플리케이션 감사 증적 로그: OLTP 절에 있는 지침 참조.

접근 통제

유닉스 로그인 보안

HIT를 운영할 때 다양한 유닉스 사용자가 필요하다:

1. "설치 사용자 Installation user": HIT 어플리케이션은 전용 사용자(들)로서 설치되어야 한다, e.g. hit1-0. 가능하면 이 계정은 잠겨져야 한다. 홈 디렉토리는 모든 HIT 이진파일들 (e.g. /opt/hit-1.0) 이 있는 곳이어야 한다.
2. "어플리케이션 관리자": 이 사용자는 OLTP 시스템 어플리케이션을 제어하며 ST 그룹에 속해야만 한다. 홈 디렉토리는 $PROJDIR이다.
3. "도메인 관리자": HIT 서버들은 특별한 사용자 (e.g. hit_domain) 아래서 돌아가는데, 이 사용자의 홈 디렉토리는 $DOMAINHOME으로, 서버 구성 파일들 (e.g. UBBCONFIG) 이 있는 곳이다. 이 사용자는 ST 그룹의 일원이어야만 하고 일차적으로 관리를 위한 것이다.
4. "HIT 사용자": 클라이언트 요청은 이 사용자 (e.g. hit_client) 아래서 돌아가며, 이의 홈 디렉토리는 $DOMAINHOME 이다. 가능하면 이 계정은 잠겨져야 한다. 이 사용자는 ST 그룹의 일원이어야만 한다.
   - 단순한 설치를 위해서는 위 사용자들 2,3 및 4 를 홈 디렉토리 $DOMAINHOME 인 하나의 사용자로 할 수도 있다.

HIT에 의해 생성된 파일들이 사용허가 rwx------를 가지도록 보장하기 위해 이 사용자들에 대한 umask 는 077 로 설정되어야만 한다. (TBD, 어쩌면 027 이 필요 rwxr-x--- ?)

파일 시스템

파일 및 디렉토리 사용허가가 어플리케이션과 서버 디렉토리들에 대해 각각 설정되어야만 한다.

chmod 750 $PROJDIR
chmod -R w-rwx,g-w $PROJDIR/* /etc/domainname.map /etc/stconfig
chown -R hit.ST $PROJDIR/* /etc/domainname.map /etc/stconfig
chmod 750 $DOMAINHOME
chmod -R w-rwx,g-w $DOMAINHOME/*
chown -R hit_domain.ST $DOMAINHOME/*

HIT에서만 사용하는 디렉토리에 $SPOOLDIR 이 설정되어 있다면, umask(위 참조)의 사용으로 로그를 보호해야 하고 디렉토리도 역시 보호되어야 한다:

chmod 770 $SPOOLDIR
chown hit.ST $SPOOLDIR

객체 재사용

위의 유닉스 로그인과 파일시스템을 위한 수단들에 의해 객체의 재사용이 방지되어야 한다. 공유 메모리도 또한 보호되어야만 한다 (OLTP 장 참조)

안전한 데이타 교환

통신 상대방 인증

HIT 서비스들은 inetd에서 시작되므로, tcp wrappers가 사용되고 DHCP가 사용되지 않는다면 IP주소에 의해 클라이언트 접근을 제한할 수 있다.

HIT 는 자체 인증 서버를 가지고 있으며 (AUTHserver), 이는 $DOMAINHOME에 있는 두 개의 (ASCII) 패스워드 파일을 사용하는데, 하나는 호스트 계정을 위한 것이고 (serv_passwd, stpasswd -s 로 관리) 하나는 클라이언트 접근을 위한 것이다 (trans_passwd, stpasswd -t 로 관리). 호스트 패스워드 파일은 telnet/3270을 통한 호스트 접속에 대한 계정과 패스워드를 나열한다.

AUTHserver 는 세가지 서비스를 제공한다:

1. AUTH 서비스는 트랜잭션 #1에서 SThandler에 의해 호출되고 trans_passwd 파일을 가지고 사용자이름/패스워드를 확인한다. 모든 것이 맞으면 OLTP TM과 약정이 맺어지고 뒤이은 트랜잭션들이 허용된다.
2. transPSW 서비스는 위의 AUTH 서비스가 호출된 이후에 호출된다. 이것은 패스워드 기한 (PASSREQ, MAXDAYS) 을 확인하고 추가 매개변수들 ${PSW[0-0]} 을 전달한다. 트랜잭션 스크립트로 다시 전달된다.
3. servPSW는 서버이름과 id 를 기준으로 serv_passwd로부터 $USER 와 $PASSWD 그리고 $PSW[0-9]를 읽어 이 값들을 리턴한다.

취약점:

• 각 통신을 인증하는 것이 아니라 초기 TPINIT 연결만 인증한다.
• 패스워드에 표준 유닉스 패스워드와 같은 플랫 파일을 쓴다 (분산 데이타베이스가 아닌).
• 표준 4바이트 세션 키를 사용하지 않는다.

무결성

• Telnet/3270 (따라서 소켓들) 만이 호스트로 전송되는 데이타의 무결성에 대한 유일한 보증자이다.
• OLTP 는 클라이언트들로의 데이타 전송에 대한 데이타 무결성을 보장한다 (TCP 소켓을 통해).

기밀성

• HIT와 호스트들 간에 전송되는 (telnet을 통해) 데이타 는 명문(clear text)으로 전송된다 - 사용자 이름과 패스워드까지도. 이것은 telnet / 3270 프로토콜 때문이다.
• HIT와 클라이언트들간에 전송되는 데이타는 OLTP 상으로 간다. 패스워드는 약하게 암호화 되지만, 사용자이름과 데이타는 안된다.

송 / 수신 부인 방지

전자 서명은 HIT나 OLTP에 정의되어 있지 않으나, 응용 레벨에서 구현될 수 있다.

가용성

서비스 중복성 (Redundancy)

HIT 는 OLTP에서 제공되는 것 외에 추가적인 중복성은 제공하지 않는다.

데이타베이스

(관계형) 데이타베이스에 대한 일반적인 지침

일반

• 알려진 벤더 보안 패치를 설치한다.
• 문서화: 각 데이타베이스에 대해 상세한 보안 토픽 정보를 어디서 구할 수 있는지 명시한다.
• 군사 보안에 인증된 데이타베이스를 사용하거나, 아니면 네트웍에 연결된 시스템에서는 데이타베이스를 설치하지 않는다.

TCSEC 평가된 데이타베이스

TCSEC 평가를 받은 데이타 베이스 사용을 고려한다. 다음 테이블에는 1996년 봄 NSA에 의해 평가된 데이타베이스들이 나열되어 있다. TCSEC 에 대한 보다 상세한 논의는 부록 C를 참고한다. C2는 대부분의 상용 시스템에서 지향하는 TCSEC 레벨이다.

시스템이 특정 레벨 (e.g. TCSEC C2) 로 평가를 받았다고 해도, 실제 생산환경에서 "안전한" 것으로 간주되려면 여전히 신중한 구성, 모니터링 및 조직 프로세스를 필요로 한다. C2라는 "라벨" 자체에 대해 너무 많은 중요성을 두지 말라. 이것은 종종 실제 내용 없이 판매 선전용으로 사용되는 경우가 많다. 이를테면 어떤 시스템이 "C2 감사" 를 제공할 수 있다 해도, 그것이 곧 그 감사 로그가 유용하다거나, 이 로그들에 대한 하이 레벨 분석 도구가 시스템에 포함?다거나, 누군가 실제로 그 로그들을 읽는다는 걸 뜻하지는 않는다는 말이다!

트랜잭션 무결성

• 데이타베이스 엔진들은 rollback/rollforward 복구 메카니즘으로 데이타 무결성을 보호한다. 어플리케이션이 begin transaction, rollback transaction 과 commit SQL 명령어를 올바르게 사용한다면 어플리케이션에 의해 처리되는 데이타 무결성이 보장된다.
• 이단계 commit 명령어들이 어플리케이션에서 올바르게 사용된다면 분산 데이타베이스의 무결성을 보장할 수 있다.
• 트리거 (triggers) 사용에 의해 관계 데이타베이스에서 참조 무결성이 강화된다 (Sybase, SQL Server, Oracle).

책임추적성

사용자 식별 / 인가

일반적인 규칙에 대해서는 "정책"장을 참고한다.

• 데이타베이스 관리자(sa)와 OS 시스템 관리자는 다른 패스워드를 사용하도록 한다.

감사 증적

• 비표준 설치에 대해 문서화한다.
• 보안 침해나 이상한 행위에 대해 로그를 주기적으로 모니터한다.
• 어플리케이션들은 누가 무엇을, 어떤 단말에서, 어떤 시스템에, 언제, 어떤 객체를 가지고 했는지, 그리고 성공했는지 아닌지에 대해 중앙화된 레코드를 보관해야 한다.

접근 통제

유닉스 로그인 보안

• 데이타베이스 엔진은 전용 사용자 (e.g. sybase) 아래서 시작되어야 한다. 가능하다면 이 계정은 잠겨져야 한다. 홈 디렉토리는 모든 데이타베이스 구성 파일들 (e.g. /opt/sybase) 이 있는 곳이어야 한다.
• 유닉스 서버 : 데이타베이스에 의해 생성되는 파일들(logs, dumps...)이 사용허가 rwx------를 가지도록 보장하기 위해 이 사용자(e.g. sybase)의 umask를 077로 설정해야 한다 (그룹 접근이 필요하면 umask 027 이 필요할 수도 있지만).

파일 시스템

• 유닉스 서버: 파일시스템이 사용되면, inode 번호를 뒤섞어 raw device를 직접 읽는 것을 보다 어렵게 한다(fsirand를 통해) (Suns).
• 파일/raw device 들의 소유권/사용허가를 각각 설정한다 - 오직 데이타베이스만이 이 장치/파일들을 읽거나 쓸 수 있어야 한다.
• 데이타베이스 관리 스크립트들은 데이타베이스 관리자들만 읽을 수 있어야 한다.
• 명문 (clear text) 패스워드를 가지고 있는 데이타베이스 관리 스크립트는 암호화 되어야 한다, [unix1] 참조.
• 유틸리티의 명령줄에는 패스워드를 사용하지 않는다, 이들은 프로세스 테이블 목록에서 보인다. 패스워드를 대화식으로 입력하거나 파일로부터 stdin을 전송(轉送, redirect)함으로써 이를 피할 수 있다.
• 데이타베이스 도구에 직접 접속할 필요가 있는 사용자들을 위해 (유닉스) 그룹을 생성한다 (e.g. sybase).
• 데이타베이스 홈 디렉토리 (모든 구성 파일과 이진파일들이 보관되는) 에 대해 파일 및 디렉토리 사용허가가 각기 설정되어야 한다. E.g. 유닉스 서버에서 사용자 ~sybase에 대해:
  chmod 750 ~sybase
  chmod -R g-w,o-rwx ~sybase/*
  chown -R sybase.sybase ~sybase

뷰 및 저장 프로시져 (stored procedures)

뷰 및 SP 들은 보안 메카니즘으로 이용할 수 있다. 어떤 사용자가 뷰나 저장 프로시져가 접근하는 객체에 대해 아무런 사용허가가 없더라도, 그 사용자는 뷰나 프로시져상에서 사용허가를 부여받을 수 있다. 뷰를 통해, 사용자들은 자기들이 볼 수 있는 데이타만 질의나 수정할 수 있다. 데이타베이스의 나머지 부분은 보이지도 않고, 접근할 수도 없다.

객체 재사용

어떤 주체에 의해 사용된 객체들은 다른 주체가 사용하기 전에 다시 초기화 되어야 한다.

Communication / 안전한 데이타 교환

통신 상대방 인증

• SQL 클라이언트들이 소켓/TLI/RPC/ 네임 파이프등을 통해 데이타베이스에 접근할 수 있다면, 접근을 제한하기 위해 취할 수 있는 조치는 무엇인가? 해당 SQL 클라이언트 소프트웨어를 가지는 시스템 중 하나라도 서버에 연결해서 데이타베이스 로그인 프롬프트를 받을 수 있는가?
• 가능하면, 사용자들이 ODBC, isql, dwb, Gupta SQL plus 등등과 같은 도구를 통해 데이타베이스에 직접 접근하지 못하게 해야 한다. 이를 위한 한 가지 방법은 이중 통과 (two-pass) 패스워드 암호화 체계 이다.

사용자는 어플리케이션을 이용해 어플리케이션 데이타베이스에 접근할 패스워드를 입력한다. 어플리케이션은 이 패스워드를 암호화하여 두번째 패스워드를 만든다. 이 두번째 패스워드가 데이타베이스 접근 루틴에서 사용되는 실제 패스워드이다. 데이타베이스는 오직 두번째 패스워드만을 알고, 사용자는 오직 첫번째 패스워드만을 알고 있다 - 따라서 사용자는 유효한 패스워드를 가지고 있지 않기에 데이타베이스에 (도구가 있더라도) 직접 접근할 수 없다. 어플리케이션이 사용하는 암호화 알고리듬이 알려지지 않도록 하는 것이 중요하다. 이 방법은 어떤 데이타베이스에도 사용될 수 있다.

무결성

사용되는 전송 프로토콜에 의해 보장된다 (e.g. TCP 소켓, 네임 파이프...).

기밀성

SQL 클라이언트와 데이타베이스 간의 네트웍 상에서 패스워드와 사용자 이름이 명문(clear text)으로 전달되는가?

데이타 발신지 인증

사용되는 전송 프로토콜 (e.g. TCP 소켓, 네임 파이프...) 더하기 초기 연결에서 사용되는 challenge response 방법에 의해 보장된다.

송 / 수신 부인 방지

전자 서명은 보통 데이타베이스에서 제공되지 않으며, 응용 레벨에서 구현될 수 있다.

가용성

백업

기본적으로는 모든 데이타베이스와 트랜잭션 로그의 전체 백업을 매일 받는 것이 좋을 것이다. 그러나 이것은 성능 (50GB 데이터베이스를 덤핑하는데 얼마나 걸리나 ...), 비용 (디스크 공간, 쥬크박스) 또는 시간상 (갱신, 검사, 백업하는데 밤시간으로 충분하지 않다) 의 이유로 거의 불가능한 일이다.

• 백업 및 복원 정책이 존재하고 주기적으로 테스트되어야 한다. 복원은 특히 테스트될 필요가 있다.
• 복구 시간을 명시하는 것이 백업 정책 선택의 첫번째 단계이다.
  • 데이타베이스와 트랜잭션 로그를 복원하는 것이 데이타베이스만 복원하는 것보다 오래 걸린다.
  • 최소 다운시간을 보장하기 위해 테이프보다는 디스크에 백업(데이타베이스 덤프)을 해야 할 것이다. 2GB의 데이타를 덤핑하는 데 30분밖에 안걸릴 수 있지만, 6GB Sybase 데이타베이스를 빠른 디스크로부터 (barracudas) 복원하는 데 8시간 (Clariion RAID는 5) 걸릴 수 있다, 테이프는 4 또는 5배 정도 더 걸릴 것이다......
• 백업을 디스크로 받을 때, 데이타나 트랜잭션 로그와 별개의 디스크에 저장한다.
• 온라인 백업이 가능한 데이타베이스를 사용한다, 즉 DB 가 동작중이어도 백업을 할 수 있다.
• 트랜잭션 로그는 보통 속도/공간의 이유로 데이타베이스보다 더 자주 백업된다. 트랜잭션 로그 백업은 마지막 데이타베이스 덤프 이후에 이루어진 변경들을 잡는다.
• 데이타베이스나 인덱스 생성 후, 또는 로그되지 않는 조작(dump transaction with no log 또는 with truncate_only, 빠른 대규모 복사)을 수행한 후에는 데이타베이스를 백업해야 한다. Sybase를 예로 들면, 그런 조작 이후에는 데이타베이스 덤프를 수행하지 않으면 트랜잭션의 덤프를 허용하지 않는다.
• 마스터 데이타베이스는 거의 변경되지 않으므로 (생산환경 DB에서, 아마 사용자나 디스크가 변경될 때만 변경), 백업은 활동적인 데이타베이스들보다 덜 자주 있을 수 있다.

자원 남용 방지

어떤 데이타베이스에서는 사용자당 할당량, CPU, 메모리 한계 등이 가능하다.

복제

어떤 데이타베이스들은 서버들간 데이타의 복제를 제공한다. 이 기능은 가용성을 개선하는 데 사용될 수 있다.

중복성 (Redundancy)

• 데이타베이스 데이타와 OS에 대해 별개의 디스크를 사용한다.
• 데이타베이스 데이타와 트랜잭션 로그에 대해 별개의 장치를 사용한다.
• 어떤 유형의 디스크나 데이타베이스 중복성 (RAID 또는 복제) 이 필요하다.
• 디스크 미러링을 사용하는 경우, 별도의 디스크로 미러한다 (그리고 가능하면 별도의 콘트롤러로).
• RAID 구성에 의해 가용성 뿐만 아니라 성능도 영향을 받는다. 미러링이 RAID 5보다 높은 중복성을 제공하지만, 디스크 공간을 더 차지하고 더 느릴 수도 있다.

Sybase

일반적인 데이타베이스 권고 도 참고한다.

4.9.x

4.9.x 는 Microsoft의 SQL V4와 매우 비슷하다 (왜냐면 MS 가 OS2 & NT 용 4.9 를 Sybase로부터 샀으므로!). 이 절이 완성될 때 까지 권고사항은 MS-SQL 절을 참고한다.

알려진 보안 문제

• 성공하거나 실패한 로그인 시도에 대한 로그가 보존되지 않는다.
• 소켓 보호가 없어 (소켓 모니터 monitor_socket.pl를 설치할 수 있다), SQL 클라이언트(isql, dwb) 를 가지고 있는 누구라도 DB에 연결하여 Sybase 로그인 프?프트를 받을 수 있다.
• 클라이언트/서버 로그인 프로세스를 "훔쳐보기 (sniff)" 가 쉽다.
• master..syslogins 테이블에 사용자 패스워드가 명문(clear text)으로 저장되어 sa 에게 보인다. 이것은 패스워드들이 디스크에도 명문으로 저장된다는 것을 뜻한다 - 따라서 누가 Sybase의 raw device에 대해 읽기 권한을 가지고 있으면, 다음 명령어로 패스워드를 아마 열거할 수 있을것이다:

dd if=/dev/rdsk/c?d?t?s? | strings | egrep "mastersa|masterMYUSERNAME"

• Sybases는 온라인 백업을 허용하지만, 파이프로나 압축은 지원되지 않는다. 이 문제(와 다른 개선점들) 는 3rd party 백업 유틸리티인 "dttools" 에서 다루어진다 (from Datatrack??). 큰 데이타베이스 (> 2GB) 에 권고.

System 10, System 11

• 로깅이 훨씬 자세해져서, 사용자 action 들이 문장(statement) 레벨까지 기록된다.
• 패스워드가 syslogins 테이블과 디스크상에 암호화된다.
• TBD

Microsoft SQL server

일반적 데이타베이스 권고사항 도 참고한다.

일반

• SQL server 4.12 에 기반하여 분석하였다.
• SQL server V6 은 Sybase 4.9를 기반으로하는 풍부한 기능의 DBMS로 보안 옵션들을 많이 가지고 있다.
• 도구: 데이타베이스와 시스템을 관리하는 데 유용한 GUI & 명령줄 유틸리티들이 많이 포함되어 있다. 이를테면 SQL Security Manager, SQLadmin, ISQL/w, isql, console, SQL monitor, SQL service manager, NETSQL, SQL object manager, SQL Tape Utility, NT Perfmeter, NT event log & alerts.
• 알려진 보안 문제점들:
  • "Sniff"가 쉽다: 클라이언트/서버 로그인 프로세스 (소켓 연결을 사용할 때) ?
  • 사용자 패스워드들은 syslogins 테이블에 cleartext 로 저장되어, sa 에게 보인다.
  • xp_cmdshell 확장 저장 프로시저 (stored procedure) 는 사용자가 어떤 파일 시스템 명령어라도 실행할 수 있게 한다. 디스크를 포맷하는 등의 멋진 일들을 상상해 보라! TBD: 어떻게 하면 이 기능이 제약될 수 있는가??
  • 패스워드 사용기한(aging) 메카니즘이 없다.
    

책임추적성

식별 / 인가

개요

사용자들의 계층은 sa (system administrator, 시스템 관리자), dbo (database administrator, 데이타베이스 관리자), doo (database object owner, 데이타베이스 객체 소유주) 그리고 사용자이다. sa 는 사용허가 (permission) 체계 밖에서 작업하는 최상위 사용자이다, 따라서 이 계정을 인가되지 않은 접근으로부터 지키는 것이 대단히 중요하다.

SQL 로그온은 standard 표준, integrated 통합 또는 mixed 혼합 모드로 구성될 수 있다.

1. Integrated 통합: SQL 서버가 NT 로그인 확인 시스템을 사용한다. NT 에 정의되어 SQL 서버에서 사용자 레벨 권한을 할당받은 사용자 계정은 추가적인 사용자이름이나 패스워드를 입력하지 않고 데이타베이스를 직접 접속할 수 있다. 트러스트된 연결만이 SQL 서버로 허용된다. Administratoe 권한을 가지는 NT 사용자들은 SQL 서버에 sa로 로그인 된다.
2. Standard 표준: SQL 서버는 운영체제에 독립적으로 자체 로그인 확인(즉 사용자 이름과 패스워드)을 수행한다. 이것이 디폴트이다.
3. 혼합: 로그인은 처음에는 통합 모드로 그다음에는 표준 모드로 처리된다. 이것은 모든 사용자들이 네임 파이프로 연결하는 것이 아닌 경우 또는 NT 도메인으로 로그온 하지 않는 경우에 유용하다.

사용자가 SQL 로그인을 하더라도, 자동으로 데이타베이스에 접속하는 것은 아니다. 데이타베이스 소유주가 사용자를 각 데이타베이스에 추가해야 한다 (sp_adduser).

도구: xp_loginconfig 현재 로그인 설정을 표시한다. xp_logininfo 는 계정들과 이들의 로그인 구성을 보여준다.

권고사항

• 통일된 사용자 관리와 인증을 제공하고 SQL 로그온 동안 패스워드가 네트웍을 건너다니지 않으므로, 통합 또는 혼합 모드가 좋다.
• 통합 및 혼합 모드에서는 디폴트 도메인이 설정되어야 한다 (설치되는 동안).
• SQL서버가 설치되자 마자, sa 패스워드를 변경해야 한다 (디폴트로 NULL로 되어있다), 이를테면 다음 SQL 명령어를 사용하여:

sp_password null,NEW_PASSWORD,sa

• 디폴트 로그인 은 사용되지 않아야 한다. 만일 하나가 필요하다면 매우 제한된 데이타 읽기와 쓰기 접근권을 가져야 한다.
• 방문자 (visitor)나 게스트 계정은 사용되지 않아야 한다. 디폴트로 pubs와 master 데이타베이스는 게스트 계정을 가지고 있다. 다음과 같이 하여 사용 불가능하도록 한다: sp_dropuser guest.
• 로그인 타임아웃: SQLadmin -> configure 에서, 로그인 시도가 취소되기 전까지 경과하는 시간을 설정할 수 있다. 일반적으로 00:01:00 (1 분) 정도의 설정이 권고된다.
• 통합되지 않은 사용자 로그온 (SQLadmin -> logins, 또는 sp_addlogin 을 통해):
  • 새로운 사용자들에게 마스터가 아닌 디폴트 데이타베이스를 할당한다.
  • 새로운 사용자들에게 패스워드를 부여하고 (절대 공백으로 남겨두지 않는다) 사용자에게 가능한한 빨리 이 임시 패스워드를 바꾸도록 일러준다.

감사 증적

SQL 서버를 설치할 때, 다음 옵션들이 권고된다:

• Error logging to: Windows NT event log = Yes (i.e. not to a text file)
• Autostart Server at boot time = Yes
• Autostart Monitor at boot time = Yes
• SQL performance monitor integration = Yes, direct response mode.
• Audit level = failed logins + successful logins (Setup -> security options).

NT 이벤트 로그는 어플리케이션, 날짜 및 우선순위에 따라 정렬될 수 있다. 주기적으로 이상한 행위에 대해 모니터되어야 한다. 관리자에게 심각한 상황을 알려주기 위해 NT 경고 alerts가 사용되어야 한다.

접근 통제

뷰 및 저장 프로시져 (stored procedures)

뷰 및 SP 들은 보안 메카니즘으로 이용할 수 있다. 어떤 사용자가 뷰나 저장 프로시져가 접근하는 객체에 대해 아무런 사용허가가 없더라도, 그 사용자는 뷰나 프로시져상에서 사용허가를 부여받을 수 있다. 뷰를 통해, 사용자들은 자기들이 볼 수 있는 데이타만 질의나 수정할 수 있다. 데이타베이스의 나머지 부분은 보이지도 않고, 접근할 수도 없다.

파일시스템

• NTFS 만 사용하고, 절대 FAT는 사용하지 않도록 한다.

객체 사용허가

sp_helpprotect를 사용하여 객체의 사용허가를 표시할 수 있다. 사용허가는 객체 와 문장 에 대해 설정될 수 있다.

• 아래 문장들을 위한 사용허가를 객체 사용허가 라고 한다(얘들은 항상 객체에 적용되니까).
  SELECT
  UPDATE
  INSERT
  DELETE
  EXECUTE
  객체 사용허가는 SQL Object Manager -> Object Permissions 를 사용하여, 또는 grant 와 revoke 를 가지고 설정할 수 있다.
• 문장 사용허가 는 데이타베이스에 종속되며 다음 문장들에게 적용된다:
  CREATE DATABASE
  CREATE DEFAULT
  CREATE PROCEDURE
  CREATE RULE
  CREATE TABLE
  CREATE VIEW
  DUMP DATABASE
  DUMP TRANSACTION
  문장 사용허가는 SQLadmin -> DB -> Manage -> Users -> permissions 에서, 또는 grant 와 revoke 를 가지고 설정할 수 있다.

객체 재사용

no relevant features.

통신 / 안전한 데이타 교환

통신 상대방 인증

SQL 서버는 소켓과 네임 파이프를 통해 클라이언트들과 통신할 수 있다. SQL 서버는 직접 NT 사용자 계정 데이타베이스를 사용할 수 있어 (통합 로그온), SQL 서버의 사용자 계정이 NT 와 별도로 관리될 필요가 없으므로, 네임 파이프를 쓰는 것이 더 좋다.

원격 서버 접근: 로컬 서버는 로그온할 필요 없이 원격 서버에 직접 접근할 수 있다 (sp_addserver,sp_configure 'remote access' 1). 원격 서버는 로컬 서버에 의해 효과적으로 제어된다. 다음과 같은 방법으로 로컬 사용자를 원격 사용자에 매핑할 수 있다:

• 모든 사용자들이 로컬 & 원격 서버에 동일한 ID를 보유한다.
• 모든 원격 사용자들이 하나의 로컬 ID로 매핑된다.
• 개별 사용자들이 원격 서버상의 서로 다른 ID들로 매핑될 수도 있다.

sp_addremotelogin, sp_helpremotelogin 명령들이 원격 사용자를 구성/검사하는 데 사용될 수 있다.

트러스트: 원격 서버는 로컬 서버를 트러스트할 수도 있고 (패스워드 교환이 필요 없음) 그 연결을 신뢰하지 못할 것으로 간주할 수도 있다. 트러스트는 동등한 보안 분류를 가지고 동일한 사람들이 관리하는 서버들간에 사용될 수 있다.

사용자 인가가 반드시 일어나도록 하려면, SQLadmin -> remotes -> manage -> remote logins -> set login ID -> manage -> remote login options 에서trusted 옵션을 FALSE 로 설정해야 한다. (또는 sp_remoteoption 을 이용).

기밀성

소켓은 그러지 못하는 반면, 네임 파이프를 통한 통신은 사용자/패스워드의 (약한) 암호화를 보장하므로, 네임 파이프가 더 낫다.

가용성

일반적인 데이타베이스 가용성 지침도 살펴본다.

백업 / 복원

일반적인 데이타베이스 가용성 지침도 살펴본다.

복구

Set the recovery interval 을 설정하여 데이타베이스 정지(crash) 후 복구하는 데 걸리는 최대 시간을 조정한다. 이것은 체크포인트간 시간을 설정하는 효과를 가진다.

일관성 검사

• 그래픽 유틸리티를 사용하여 데이타베이스를 생성/변경할 때, 데이타베이스를 재생성할 수 있는 데이타베이스 스크립트를 생성하도록 권고한다. SQL object manager -> scripts 윈도우에서는 선택된 개체에 대한 테이블, 뷰, 저장 프로시져, 트리거, 룰, 디폴트, 사용자 데이타유형 및 로그인을 위한 스크립트를 생성할 수 있다. 이것은 최소한의 문서화를 제공하고 다른 서버에 있는 객체의 재생성을 가능하게 한다.
• dbcc (database consistency checker, 데이타베이스 일관성 검사기) 는 테이블 (checkdb)과 데이타베이스 구조에 대한 불일치를 검사하는 데 사용되는 주 도구이다.
• dbcc newalloc은 데이타와 인덱스 페이지를 해당 확장 구조에 대해 검사한다. 이것은 checkalloc (백워드 호환을 위해 역시 존재하는) 을 대체하지만 에러를 발견해도 멈추지 않으며 더 상세한 보고서를 만든다. 권고사항: 가능한한 자주 돌리고, 특히 데이타베이스 백업 전에 돌린다.
• Lock은 활성 트랜잭션에서 사용중인 데이타에 다른 사용자가 간섭하는 것을 방지한다. SQL 서버는 여러가지 종류의 lock을 가지고 있다: 배타적 exclusive, 공유 shared 또는 요구 demand. sp_lock 명령어는 현재 lock들을 보여준다. SQL 서버는 deadlock과 livelock을 모두 탐지하고 풀 수 있다. [sql1], page 346 을 참고한다.

조직

• SQL 서버가 종료되어야 한다면, 사용자 데이타의 불필요한 유실을 막기 위해 모든 사용자들은 통지를 받아야 한다. 이를테면 Lan Manager를 통해 연결된 모든 사용자들에게 메시지를 보낼 수 있다.:

net send /users "SQL 은 30분 후 종료됩니다. 연결을 끊어주시기 바랍니다."

중복성 (Redundancy)

모니터링

• SQL 서버가 비정상적으로 정지되었을 때 재시작하려면 SQL monitor를 구성해야 한다. NT 이벤트 로그에 항목이 만들어질 것이다.
• 미러를 모니터해야 한다, Sybase는 원본에서 미러로 바꿀 때 통보하지 않는다. SQL 스크립트 WAITFOR MIRROREXIT 로 이를 할 수 있고, 아니면 이벤트 로그를 모니터할 수 있다.
• 트랜잭션 로그 공간을 감시: sp_apaceused, sp_helpdb 또는 dbcc sqlperf (logspace).

복제

V6 에서만 가능. TBD.

미러링

미러링은 디스크 고장시 연속적인 운영을 가능하게 한다. SQL 서버 미러링 뿐만 아니라, NT 서버는 파일시스템 레벨 미러링과 RAID 5도 제공한다. 미러링/RAID는 하드웨어 레벨에서도 구현될 수 있다. 미러링은 가용성 뿐 아니라 성능에도 영향을 준다.

• 최소 구성으로 트랜잭션 로그를 별도의 드라이브에서 미러링할 수 있다.
• 고급 구성으로 모든 사용자 데이타베이스, 마스터와 트랜잭션 로그를 여러 개의 콘트롤러 상에 있는 여러 개의 드라이브에서 미러링할 수 있다.
• 마스터가 미러링되면, 서버 시작줄에 미러 장치가 주어져야 한다. 이를테면 SQL Setup -> Options > Set server options -> continue -> parameter 에서 -rd:\sql\mirror\mastmir.dat 을 추가한다. 일차 장치가 고장나면 미러 장치가 사용된다.
• 연속 쓰기를 가능하게 한다: 원본에 먼저 쓰고 다음에 미러 디스크에 쓴다 (SQLadmin -> devices -> select device -> manage -> mirroring -> mirror). (실제로 확인?)

SQL Server V6.0

1995년 여름부터 새로운 버전이 사용가능하다 : SQL Server 6.0. 이전 버전보다 강화된 보안 기능을 제공한다 (V4.21):

• V6.0 은 복제를 지원하는데, 테이블과 객체들의 "snapshots" 뿐만 아니라 비동기 로그기반 트랜잭션 전달 모두 지원한다. 복제는 Publisher/Subscriber 메타포를 사용한다. 각 publication 는 비제한 (디폴트) 또는 제한 보안 상태를 가진다. 등급 의 published 데이타베이스에는 제한 상태를 써야 한다.
• 로깅과 경고는 NT 것과 완전히 통합된다. 로컬에 경고가 정의되어 있지 않으면, 이벤트는 다른 서버로 보내져 처리된다. 이것은 한 무리의 서버들을 중앙에서 모니터할 수 있게 해준다.
• OLE 가 지원되어, 관리/보안 스크립트에 Visual basic을 사용할 수 있게 해준다.
• 필드 레벨의 보안이 지원된다.
• 새로운 암호화 서비스가 클라이언트와 서버간 안전한 데이타 교환을 제공한다.

TBD: V6에 특정한 권고사항

Oracle 7.1 이나 그 이후

일반

• Oracle은 많은 보안이 갖추어져 있는 있는 복잡한 DBMS이다 (특히 V7.1 이나 그 이후). 그러나 백업 메카니즘은 미개하다.
• 등급 에는 Trusted Oracle 7.1 이나 그 이후를 추천한다. 여기에서는 논의되지 않는다.
• 등급 에는 Oracle 7.1 이나 그 이후를 사용한다 (& SQL*net 2.1) :
  • 7.0.12 보다 추가된 보안 기능을 가진다: 원격 연결을 위한 패스워드 암호화와 병렬 복구 (parallel recovery).
  • V7.1 보안 기능이 필요하면, 다음 매개변수가 설정되어야 한다: COMPATIBLE = 7.1.0
• 운영체제 인증은 V7.0 에서 처음 지원되었다.
• 데이타 & 참조 무결성을 보장하기 위해, Oracle은 트리거와 제약조건(constraints)을 제공한다.

위험

• V7.1 전에는, Oracle 서버들간 또는 서버와 클라이언트간 SQL*net 통신에서 사용자이름과 패스워드를 clear text로 네트웍을 통해 보냈다, 즉 침입자가 네트웍을 "sniff" 하여 이 패스워드들을 볼 수 있었다.
• orapwd와 SQLplus 같은 유틸리티들은 명령줄 상에서 패스워드를 받아들이는데, 이렇게 하면 많은 시스템들의 프로세스 테이블에서 보인다 (그리고 따라서 인가되지 않은 사용자들에게도). 관리자들은 이를 반드시 인지하고 있어야 한다!

문서

Oracle 제품과 함께 제공되는 "Oracle7 Server Documentation: Addendum Release 7.1", "Oracle7 Server Concepts Manual" 을 참고한다.

책임추적성

식별 / 인가

Oracle은 다음 중 하나에 의해 사용자 인증이 수행될 수 있게 한다:

1. OS (사용자 이름이 데이타베이스에 역시 있어야만 한다).
2. 또는 Oracle 자체. 이 경우 각 사용자에 대한 패스워드가 데이타베이스에 저장된다 (암호화된 형태로).

같은 데이타베이스 안에서 두 방법 모두 사용될 수 있다.

특권 사용자(Privileged user), V7.1 이전:

• INTERNAL: INTERNAL 로 연결하는 사용자만이 데이타베이스를 종료(shutdown)/시작(start)할 수 있다. 일반적으로 INTERNAL은 사용자가 사용하는 것 외에 추가 패스워드를 가지고 있다. 이 권한이 여러 관리자들에 의해 공유된다면 누가 INTERNAL 인지 (INTERNAL로 접속했는지) 알 수가 없다. 또한 안전한 원격 관리가 항상 가능한 것은 아니다.

특권 사용자(Privileged user), V7.1 과 이후:

• SYSOPER: STARTUP, SHUTDOWN, ALTER DATABASE, OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG 그리고 RECOVER 를 허용한다. 또 RESTRICTED SESSION 권한도 가지고 있다. 이 권한은 다음과 같이 사용자에게 부여된다: GRANT SYSOPER to user_name.
• SYSDBA: 모든 ADMIN OPTION 권한을 가지고 있다, SYSOPER, CREATE DATABASE 그리고 time-based recovery. 이 권한은 다음과 같이 사용자에게 부여된다: GRANT SYSDBA to user_name.

특권 사용자는 CONNECT user_name/server@my.domain AS SYSDBA 로 연결할 수 있다. 어떤 사용자들이 이 권한을 가지고 있는지 보려면, 뷰 V$PWFILE_USERS 를 이용한다.

• V7.0: OSOPER 및 OSDBA, CONNECT INTERNAL 과 관련, 위와 같은 권한을 허용하도록 한다. (TBD: 확실한가?)

감사 증적

• 감사는 통계 수집, 의심스러운 행위 감시 및 무슨일이 언제 일어났는지에 대해 믿을 수 있는 로그를 제공하는 데 사용될 수 있다.
• 감사가 enable 되어 있든 아니든 상관없이, 데이타베이스로의 특권 연결은 항상 감사된다.
• V7.0 에서, Oracle 에 INTERNAL 로 연결된 사용자들만이 서버를 시작 또는 정지할 수 있었다. V7.1 은 사용자들이 유일한 이름과 패스워드로 연결하도록 요구할 수도 있어, 사용자별 감사를 가능하게 한다 (OS 감사 증적에서).
• Oracle은 어떤 것을 감사할 수 있는가? 다음에 대한 성공/실패를 감사할 수 있다:
  1. 문장 Statements (DML & DLL): 선택된 사용자들 또는 모든 사용자들에 대해 설정될 수 있다.
     e.g. AUDIT CREATE TABLE
  2. 특권 Privileges: 강력한 시스템 특권을 감시하는 데 유용.
     e.g. AUDIT SELECT ANY TABLE
  3. 스키마 객체 Schema Objects: 모든사용자들로부터의 (DML)을 통한 특정한 객체로의 접근 시도에 적용 (e.g. 테이블, 뷰, 함수[function], 순번[sequence] 및 독립적 저장 프로시져[stand-alone stored procs]) .
     e.g. AUDIT SELECT ON my_table BY SESSION WHENEVER NOT SUCCESSFUL

  사용자 세션마다 감사하거나 (BY SESSION), 문장이 실행될 때마다 감사할 수 있다 (BY ACCESS).

• 감사 증적은 어디에 있나?: OS 감사 증적 (파일), 또는 각 데이타베이스 SYS 스키마의AUD$ 테이블. AUD$를 검사하는 데 몇 가지 미리 정의된 뷰들을 사용할 수 있다. TBD. 분산 데이타베이스에서, 감사는 로컬이다. 사이트들간 동기화가 없다.
  

접근 통제

임의적(Discretionary) 접근 통제

Oracle 은 스키마, 특권(권한), 역할, 뷰 및 테이블 보안을 통해 세밀한 접근 통제를 제공한다.

사용자의 접근 권한은 사용자의 보안 도메인내 설정에 의해 통제된다. 보안 도메인은 다음으로 구성된다:

• 인증 정보가 Oracle에 의해 유지되는지 아니면 OS에 의해 유지되는지.
• 사용자의 디폴트 및 임시 테이블 스페이스.
• 사용자가 접근할 수 있는 테이블 스페이스과 관련 할당량.
• 시스템 자원에 대한 사용자의 제한.

사용자에게 객체에 대한 접근을 제공하는 특권과 역할.

각 Oracle 데이타베이스는 스키마 schemas 목록을 가지고 있다. 각 스키마는 테이블, 뷰, 클러스터, 프로시져 및 패키지 같은 스키마 객체들의 집합이다. 각 데이타베이스는 또 유효한 사용자들의 목록을 가지고 있으며, 데이타베이스에 접근하려면 사용자는 자기의 신원을 확인받고 인가되어야 한다 (개인 패스워드를 통해). 데이타베이스 사용자가 생성될 때, 그 데이타베이스 내의 객체들에 대한 접근을 관장하는 해당 스키마 또한 생성된다. 사용자는 동일한 이름의 스키마를 가지고서만 연결할 수 있다.

특권 privilege 은 특정한 SQL 문장을 실행하거나 (시스템 특권) 특정 객체에 접근(객체 특권)할 수 있는 권한이다. 특권은 사용자에게 직접 또는 역할 (아래 참조) 에 부여될 수 있다. 시스템 특권은 SQL 명령어 GRANT/REVOKE 를 통해 또는 SQL*DBA를 이용하여 (Grant system privileges/Roles 대화상자) 부여된다. 시스템 특권 ADMIN OPTION 이나 GRANT ANY PRIVILEGE 를 가진 사용자들만이 데이타베이스의 사용자/역할(role) 에게/로부터 시스템 특권을 부여(grant) / 철회(revoke)할 수 있다.
객체 특권도 SQL 명령어 GRANT/REVOKE 를 통해 부여된다. 객체 특권은 스키마의 소유주에 의해, 또는 그 스키마에 대한 GRANT OPTION을 부여받은 사용자에 의해 부여/철회될 수 있다.

역할 (role) 은 특권들을 묶어 이름을 붙인 그룹으로 사용자들이나 다른 역할에게 속성으로 부여될 수 있다. 예를 들어, 어떤 어플리케이션은 다음과 같은 역할들로 쪼개질 수 있다: : db 관리자 [db Administrator] (전체 권한), db 운영자 [db Operator] (백업 권한), 어플리케이션 소유주 [Application Owner] (각 db 어플리케이션을 위한) 그리고 어플리케이션 사용자 [Application User].
역할은 다음과 같은 이점을 준다:

• 줄어든 특권 관리: 사용자에 종속되지 않음. 역할은 한 그룹의 멤버들에게 쉽게 속성으로 부여될 수 있다.
• 동적 특권 관리: 한 그룹의 사용자들에 대한 특권이 변경되어야 한다면, 역할만 변경하면 된다.
• 특권의 선택적 가용성: 특권은 필요에 따라 선택적으로 사용자에게 사용 가능해질 수 있다.
• 어플리케이션 인지: 어플리케이션은 데이타 딕셔너리에 질의하여 어떤 역할들이 존재하는지 볼 수 있다.
• 어플리케이션에 특정한 보안: 역할들은 패스워드로 보호될 수 있고, 어플리케이션들은 역할 패스워드를 알고 있으므로 이 역할들을 enable할 수 있다.

역할은 어플리케이션과 사용자 역할로 세분될 수 있다.

• 어플리케이션 역할은 특정 어플리케이션을 돌릴 수 있는 특권을 부여받은 역할이다. 종종, 어플리케이션은 각기 어플리케이션에의 다른 접근을 허용하는 여러 개의 역할을 가지게 된다. 어플리케이션 역할은 특정 사용자나 다른 역할들에게 부여될 수 있다.
• 한편 사용자 역할은, 어플리케이션 내에서 동일한 특권을 필요로 하는 한그룹의 사용자들을 위한 것이다.

데이타베이스 내에서 각 역할 이름은 유일해야 하며 사용자이름과 같아서는 안된다. 각 역할은 자체적으로 보안 도메인을 가지고 있다. 각 사용자는 자기의 보안 도메인과 관련된 특권에다가, 사용자에게 부여된 역할의 특권을 가진다 (현재 enable 되어 있는).
권고: 특권을 사용자가 아닌 특정 역할에 부여하도록 한다.

V7 에서 미리 정의되어 있는 역할: CONNECT, RESOURCE, DBA, EXP_FULL_DATABASE 그리고 IMP_FULL_DATABASE. 이 역할들은 수정될 수 있다.

각 데이타베이스는 PUBLIC 이라는 사용자 그룹 (모든 사용자가 속하는) 을 가지고 있다. PUBLIC의 멤버는 USER 와 ALL 로 시작하는 모든 데이타 딕셔너리를 볼 수 있다. PUBLIC 에게 특권 (시스템, 객체 특권 또는 역할) 이 부여될 수 있다. 제약조건: 테이블스페이스 할당량은 PUBLIC에게 할당될 수 없다. PUBLIC으로 생성될 수 있는 객체들은 오직 링크와 동의어(synonym) 들 뿐이다 (CREATE PUBLIC DATABASE LINK/SYNONYM).
권고: 모든 사용자들에게 정말 꼭 필요한 특권들만 PUBLIC에게 부여하도록 한다.

테이블 보안 은 두 가지 방법으로 제공된다:

• DML (데이타 처리어, Data Manipulation Language) 조작: DELETE, INSERT, SELECT 그리고 UPDATE 같은 것으로, 테이블의 데이타를 다루어야 할 필요가 있는 사용자/역할들에게만 부여되어야 한다. INSERT 와 UPDATE 특권은 특정 열에 대해 한정하여 부여될 수도 있다. 선택적 INSERT 는, 행을 삽입할 수 있지만, 특정 열에 대한 값만 넣을 수 있다 - 다른 모든 열들은 NULL 이나 그 열의 디폴트 값을 받는다.
• DDL (데이타 정의어, Data Definition Language) 조작: ALTER, INDEX 와 REFERENCES 같은 것은 사용자가 테이블에서 종속성을 변경하거나 생성할 수 있게 한다, 따라서 이들은 보수적으로 (신중하게) 부여 되어야 한다. 어떤 조작들에서는 (이를테면 테이블에서 트리거 생성), 사용자가 (ALTER TABLE) 객체 특권과 시스템 특권 (CREATE TRIGGER)을 필요로 한다. REFERENCE 특권은 열에 따라 부여될 수 있다. 이것은 보통 일차 또는 단일 키에 대해서만 필요하다.

뷰: 뷰를 사용하기 위해, 사용자는 뷰에 대한 권한만을 필요로 한다 (하부의 테이블/데이타에 대해서는 말고). 이것은 테이블내의 특정한 행/열들에만 접근을 제공함으로써 보안을 개선한다. 하부의 데이타/열에 대한 권한을 관리하는 것 보다는 뷰 접근을 관리하는 것이 더 쉬울 것이다 (그리고 에러도 더 적게 발생).
사용자가 CREATE (ANY) VIEW 및 하부 베이스 객체들에 대한 SELECT, INSERT, UPDATE/DELETE 를 가지고 있다면 뷰가 생성될 수 있다. 이 뷰에 대한 접근을 다른 사용자들에게 부여 하려면, GRANT OPTION 또는 ADMIN OPTION 이 필요하다.
권고: 접근 통제를 위해 뷰를 사용하도록 한다.

패키지: 프로시져들을 함께 묶는 데 사용될 수 있다. 역할/사용자는 어떤 패키지에 대해 EXECUTE 권한을 부여받을 수 있어, 그 패키지 내의 모든 프로시져들과 공개 변수들의 사용을 효과적으로 허용하게 된다 (사용자가 그 패키지에 의해 조작되는 데이타를 접근할 충분한 권한을 가지고 있다고 또한 가정할 때). 특정한 EXECUTE 권한이 패키지의 구조에 대해 속성으로 부여될 수는 없다.
시스템 특권 EXECUTE ANY PROCEDURE 는 사용자가 데이타베이스 내의 어떤 프로시져든지 실행할 수 있게 허용한다는 것에 주의한다.

안전한 시스템 시동

일반적인 데이타베이스 권고사항을 참고한다.

안전한 데이타 교환 / 통신

• SQL*net 은 Oracle 클라이언트가 Oracle 서버를 접속할 수 있게 해주는 네트웍 인터페이스이다. SQL*net은 모든 주요 통신 프로토콜 상에서의 통신을 지원한다 (SNA, TCP/IP, OSI....).
• Oracle 은 분산 데이타베이스를 지원하지만 (따라서 2단계 commit 도), 사이트들은 따로따로 관리된다 (즉 보안도). 각 사이트는 별개의 데이타 저장소이다. 원격 데이타베이스들에 있는 스키마들은 객체에 도메인 주소를 추가함으로써 접근할 수 있다 (e.g. mytable@mydatabase.myserver.ourdomain).

원격 링크
원격 데이타베이스들은 서로서로 링크를 통해 통신한다. 링크는 원격 데이타베이스로의 경로이며 두 개의 구성요소를 가지고 있다: 데이타베이스 문자열과 원격 계정 (사용자이름 & 패스워드). 두 가지 유형의 링크가 있다: Private 과 Public (PUBLIC 그룹을 위해 생성. 모든 사용자는 이 링므를 사용할 수 있으며, 접근을 제한할 수 있는 방법은 없다). 사용자가 링크를 통해 원격 데이타베이스에 접속할 때, 그 사용자는 로컬과 동일한 사용자이름/패스워드를 사용해서 또는 원격 데이타베이스에 접속하기 위한 "중앙 계정"을 사용해서 접속할 수 있다. 이를테면

CREATE PUBLIC DATABASE LINK remote_db_name
CONNECT TO remote_user_name IDENTIFIED BY remote_user_password
USING `some_db_string';

CONNECT TO 단계가 생략되면, 개인 계정이 사용된다.

• 중앙 계정 - 이점: 관리가 더 쉽다
• 중앙 계정 - 단점: 원격 데이타베이스에서 정확한 감사 증적이 불가능하다, 사용자이름 & 패스워드가 링크에 지정되어 있다, 중앙계정은 어떤 사용자가 필요로 하는 것보다 더 많은 특권을 가지고 있을 수 있고 로컬 데이타베이스의 어떤 사용자든지 원격 데이타베이스를 접근할 수 있다.
• 개인 계정 - 이점: 사용자 요구 사항에 맞추어질 수 있고, 링크에 사용자이름/패스워드가 지정되어 있지 않다, 원격 시스템에 대한 감사 증적이 보다 정확하다, 사용자는 양쪽 시스템에서 동일한 이름을 가진다.
• 개인 계정 - 단점: 관리하는 시간이 더 많이 걸린다 (계정 생성/동기화에)

권고: 등급 데이타베이스들에는 개인 링크를 사용하도록 한다.

통신 상대방 인증

• 안전한 패스워드 파일 사용은 안전하지 못한 네트웍 연결 상으로의 원격 데이타베이스 관리를 허용한다. Oracle은 TCP/IP 와 Decnet 을 안전한 연결로 생각하지 않는다.
• 특별한 OPS$ 사용자 로그온 계정을 이용하여 패스워드 없이 (V7.1 이전에는 디폴트로 허용) Oracle 서버에 원격 로그인을 할 수 있다. 이 기능을 등급 시스템에서는 사용되선 안된다. 등급 이나 에 사용될 때는, 동일한 보안 분류를 가지고 동일한 관리자들에 의해 관리되는 Oracle 서버들간에만 사용되어야 한다.
• V7.1 및 이후에서, SYS, INTERNAL 스키마에 접근하는 사용자들은 유일한 이름 & 패스워드를 가지고 연결해야만 하도록 지정할 수 있다. 등급 에 권고.
  1. REMOTE_LOGIN_PASSWORD_FILE 이 NONE (디폴트) 이면, 사용자는 OS에 의해 인증되어야만 한다. Oracle 패스워드 파일이 존재하더라도, 무시된다.
  2. REMOTE_LOGIN_PASSWORD_FILE 이 EXCLUSIVE 이면, Oracle은 외부에 저장된 패스워드 파일 (orapwd[2] 을 사용하여 생성) 을 사용하여 특권 사용자들을 식별/인증한다. 이것은 모든 특권 연결이 사용자이름에 따라 감사될 수 있게 하므로 더 큰 보안을 제공한다. EXCLUSIVE 패스워드 파일은 하나의 데이타베이스에만 사용될 수 있다. 추천.
  3. REMOTE_LOGIN_PASSWORD_FILE 이 SHARED 이면, 특권 사용자들은 사용자 SYS 로 올바른 패스워드를 가지고 연결해야 한다. EXCLUSIVE 만큼 안전하지는 않다. 수많은 데이타베이스들을 원격으로 관리해야 하는 관리자에게 유용하다.

데이타 무결성

SQL*net 에 사용되는 통신 프로토콜에 의존, e.g. TCP/IP, DECnet, SNA (LU6.2), Appletalk, OSI4, IPX, Named Pipes....

데이타 기밀성

• V7.1 에서는, 네트웍을 건너가는 패스워드의 암호화를 지정한다, 클라이언트에서 ORA_ENCRYPT_LOGIN = TRUE 로 설정하고 서버에서는 DBLINK_ENCRYPT_LOGIN = TRUE 를 설정한다.
• 가능하면 SQLnet 2.1 (Oracle 클라이언트) 을 사용한다. SQLnet 2.1 은 V7.1 서버에게 전송하기 전에 패스워드를 암호화한다.
• orapwd 유틸리티 자체는 명령줄에서 패스워드를 받는다는 점에서 보안 위험을 주는데, 왜냐하면 많은 시스템들에서 프로세스 테이블에 보이기 때문이다. 관리자들은 반드시 이를 숙지하고 있어야 한다!

송 / 수신 부인 방지

SQLnet 이나 얘가 사용하는 프로토콜에서나 지원하지 않는다.

접근 통제

표준 SQL 접근 통제.

가용성

자원 남용 방지

대형 다중사용자 시스템에서는, 사용자가 사용하는 시스템 자원에 제한을 두는 것이 중요하다. 그러나 자원의 감시는 보통 성능을 약간 저하시킨다. 또한 시스템 관리자의 시간도 여분으로 필요하다.

프로파일 은 사용자에게 할당될 수 있는 자원 한계치의 집합이다. 각각의 자원들은 세션당 (세션은 사용자가 데이타베이스에 연결할 때 생성된다).또는 SQL 호출당으로 (SQL 문장이 실행될 때마다) 관리될 수 있다. 한계치에 도달하면, 현재 문장은 중지되고 사용자는 rollback, 또는 commit 하거나 연결을 종료할 수 있다. 자원 한계는:

• CPU 시간은 호출당 제한할 수 있다 (1/100 초씩).
• 호출당 및 세션당 논리적 데이타 블록 읽기 (메모리와 디스크로부터 모두).
• 사용자당 동시 세션 수.
• 세션당 휴지시간 [idle time](분으로) (현재 트랜잭션은 롤백되고, 세션은 중단되며 자원은 시스템으로 반환된다).
• 세션당 소요되는 연결 시간 (분으로).
• 다중 쓰레드 (multithreaded) 서버에서는 SGA 공간의 양을 제한할 수 있다 (PGA의 private SQL 영역에 사용되는).

최소한의 서로 다른 프로파일들을 정의하고 이를 사용자들의 속성으로 부여한다. 프로파일이 많을 수록, 이를 관리하는 데 시간이 더 걸린다. 한계치를 산정하는 가장 좋은 방법은 활동중인 시스템의 통계를 관찰하는 것이다.

할당량: 디스크 공간 관리를 위해 사용자당 테이블 스페이스 할당량을 사용할 수 있따. 테이블 스페이스 할당량이 0 이면, 사용자는 새로운 공간을 쓸 수 없으나, 그가 점유한 기존 공간은 남아있다.

백업 및 복원

• 일반적인 데이타베이스 권고사항 도 참조한다.
• V7.1에서의 병렬 복구는 백업이 재장전되어야 할 때 다운시간을 줄일 수 있다.
• Oracle 은 온라인 백업이 불가능하다는 점에서는 원시적이다. 백업은 보통 두단계로 일어난다: 1). 데이타베이스 종료. 2). Oracle 이 사용하는 파일들의 OS 레벨 백업 수행.
• 온라인 데이타베이스 백업을 가능하게 하는 새로운 도구들이 나오고 있다 (1Q96). TBD.
• 다음 절차에 따라 유사 (quasi) 온라인 백업 (Oracle은 이것을 퍼지 백업이라고 부른다!) 이 가능하다:
  1. Oracle 은 온라인이며 활발하게 사용되고 있다.
  2. BEGIN BACKUP 옵션을 써서 ALTER TABLESPACE 을 실행한다. 체크포인트는 더이상 파일 헤더에 표시되지 않는다. 복구되는 동안, 이것은 Oracle 이 언제 마지막 체크포인트가 수행되었는지 알게 해주고 redo 로그에 따라 rollforward 할 수 있게 해준다.
  3. Oracle 파일들 (데이타 및 콘트롤) 에 대해 OS 백업을 한다.
  4. END BACKUP 옵션을 써서 ALTER TABLESPACE 을 실행한다. 파일 헤더는 현재 체크포인트로 갱신된다.
  5. 자동 복구가 가능하지만, 특별한 스크립트들을 작성해야 할 것이다.
• Import/Export 유틸리티들도 Oracle 로/로부터 데이타를 전송하는 데 사용될 수 있다. 이들이 온라인 백업을 할 수 있나??

권고사항:

1. 데이타베이스를 ARCHIVELOG 모드로 운영한다, 이는 다음을 제공한다:
   • 디스크 장애 후 보다 훌륭한 복구
   • 트랜잭션 무결성
   • 유사 "온라인 백업" 허용 (위 참조).
2. 가능하면, 백업하기 전에 Oracle을 종료한다.

중복성 (Redundancy)

일반적인 데이타베이스 권고사항 도 참조한다.
Oracle 은 미러링을 제공하지 않으며, OS, 디스크 또는 파일시스템 레벨에서 이루어져야 한다.

복제

복제는 성능과 (원격 질의를 줄임으로써) 가용성을 (마스터가 죽어도 복제된 복사본은 여전히 사용가능) 증대시킬 수 있다. 소스 서버는 마스터 데이타를 가지고 있으며 대상 (target) 서버는 마스터 데이타의 읽기전용 복사본 (스냅샷 이라고 하는) 을 가지고 있다. Oracle 은 한 서버에서 다른 서버로 데이타를 복제하기 위한 두 가지 방법을 제공한다:

• 비동기식: 테이블 변경사항은 주기적 간격으로 읽기 전용 테이블에 갱신된다.
• 동기식: 트리거를 사용하여 변경사항을 즉시 복제된 복사본에 적용할 수 있다.

스냅샷은 complete refresh (스냅샷의 모든 데이타가 마스터로부터 전송됨), 또는 fast refresh (변경된 행만 전송) 를 사용하여 refresh 될 수 있다. 단순 스냅샷 (즉 스냅샷의 각 행은 단일 원격 테이블의 한 행에 정확하게 대응하고, subquery, join 등은 불가능) 의 경우 fast refresh 는 스냅샷 로그 (즉 마스터 테이블의 변경된 행을 추적하는 마스터 데이타베이스의 테이블) 와 함께 사용해야만 가능하다.

[1] USL의 "Application Development & Administration, Tuxedo Release 4.2 ETP", 페이지 TA2-7 도 참조한다.
[2] orapwd 는 INTERNAL 이나 SYS 에 대한 패스워드를 명령줄에서 기다린다는 것에 유의한다. orapwd 이 돌아가고 있을 때 명령줄은 유닉스 시스템의 다른 사용자들에게도 보인다 (ps 를 통해).

         IT Security Cookbook, 21 July, 2000