2.6.4 데이터베이스 접근
1. ISMS 원본
인증기준
데이터베이스에 대한 접근은 인가된 사용자만 허용하고, 불필요한 접근을 통제하여야 한다.
주요 확인사항 (KISA 안내서)
- 데이터베이스에 대한 접근(직접접근 포함)을 통제하기 위한 정책·절차를 수립·이행하고 있는가?
- 응용프로그램과 데이터베이스 간 연결 계정(서비스 계정)을 안전하게 관리하고 있는가?
- 데이터베이스에 대한 직접접근을 제한하고, 필요 시 승인·모니터링하고 있는가?
- 데이터베이스 접근에 대한 로그를 기록·모니터링하고 있는가?
관련 법규
- 개인정보 보호법 제29조 (안전조치의무)
- 개인정보의 안전성 확보조치 기준 제5조 (접근권한의 관리), 제6조 (접근통제)
핵심 통제 (KISA 안내서)
- DB 접근 가능 사용자·IP 제한
- 직접접근(SQL*Plus·SSMS·pgAdmin 등) 원칙적 금지, 필요 시 승인·기록
- 응용프로그램-DB 연결 계정(서비스 계정) 비밀번호 관리 — 하드코딩 금지, 주기적 변경
- DBA 계정 최소 인원 제한, 공용 DBA 계정 금지
- DB 접근·변경 로그 기록·보존·정기 검토
결함사례 (KISA 안내서)
- 사례 1: DBA가 운영 DB에 제한 없이 직접접근 — 승인·모니터링 절차 X
- 사례 2: 응용프로그램-DB 연결 계정 비밀번호가 소스코드·설정파일에 평문 저장
- 사례 3: DB 접근 로그 미기록 또는 보존 기간 미달
- 사례 4: 퇴직·전보 DBA의 DB 계정 미회수
2. ITGC 매핑
| 항목 | 값 |
|---|---|
| 분류 | 직접 (1-direct) |
| ITGC 영역 | APD (Access to Programs and Data) |
| 부영역 | — |
| 보조 영역 | PC (직접 변경 → 변경관리 연계), 2.5.1 (계정 라이프사이클), 2.9.4 (로그) |
3. IT감사에서는 이렇게
3-A. 한국 비금융 ITGC 실무 표준 (실제 검증 범위)
2.6.4는 ITGC APD에서 독립 검증 절차가 있는 영역이다. 2.6.2/2.6.3이 "다른 인증기준 커버"였다면, DB 직접접근은 애플리케이션 우회 데이터 변조 리스크가 있어서 별도로 본다.
핵심 질문: "누군가 앱을 거치지 않고 운영 DB를 직접 수정할 수 있는가? 있다면 그 경로에 통제가 있는가?"
| ISMS 요구 | ITGC 테스트 절차 | 모집단 | 샘플 |
|---|---|---|---|
| 1. DB 직접접근 제한 | in-scope DB별 직접접근 가능 계정·IP 식별 → DBA 외 직접접근 가능자 존재 여부 | DB 사용자 마스터 전수 | 전수 추출 → 예외 분석 |
| 2. DBA 계정 적정성 | DBA 계정(sa·sys·sysadmin 등) 보유자 리스트 → 직무 적정성, 인원 과다 여부 | DBA 계정 전수 | 전수 (소수) |
| 3. 직접변경 건 승인 (→ PC 2.9.1) | 변경 건 승인 테스트는 PC 영역 — 직접변경 로그 샘플 → 변경관리 승인·ticket 확인. 2.6.4는 경로·권한까지(1·2행), 변경 건은 PC로 | 기간 내 직접 변경 로그 | 샘플링 (PC에서) |
| 4. 서비스 계정 관리 | 비밀번호 설정값(복잡도·변경주기) 캡쳐 + 하드코딩·평문 저장 여부 | in-scope 앱 연결 계정 | 설정 캡쳐 (금융: 수동 확인통제 수행 증적 추가) |
직접 변경과 변경관리(PC)의 교차점:
- 변경할 수 있냐(권한)는 APD, 실제 변경한 것의 확인은 PC.
- APD (2.6.4): 모집단 = 권한 가진 계정 리스트(DB 사용자 마스터). 질문 = "애초에 직접 실행할 수 있는 권한·경로가 통제되나"
- PC (2.9.1): 모집단 = 실제 발생한 변경 로그. 질문 = "변경내역이 승인·검토 됐나". 일반적으로 data fix는 Program Changes 영역 — 변경에 대한 테스트는 PC 통제
- 실무: DBA 직접 변경 로그에서 샘플 추출 → 변경관리 대장의 승인 건과 대조. 샘플 중 승인 없는 건 = 비인가 변경(결함)
3-B. ISMS-P가 추가로 요구하지만 ITGC 실무 범위 밖
| ISMS 요구 | 절차 | 어디 영역 |
|---|---|---|
| 개인정보 DB 암호화 | DB 암호화 적용 현황 점검 | 개인정보 영역 (3장) / 암호화 (2.7.1) |
| DB 접근 로그 장기 보존·정기 검토 | 로그 보존 기간·검토 절차 | 2.9.4 로그 관리 (CO 영역) |
| DB 취약점 점검 (패치·설정) | DB 버전·패치·보안 설정 | 보안 진단 (ITGC 영역 X) |
4. Q&A
Q1. DB 직접접근 "원칙적 금지"인데, 실무에서 완전 차단 가능한가?
A. 불가능. 운영 DB에 DBA 직접접근은 반드시 발생한다.
- 긴급 데이터 보정, 배치 오류 복구, 성능 튜닝 — DBA 직접 SQL 실행이 불가피
- 통제 포인트는 "금지"가 아니라 "승인 → 실행 → 기록 → 사후 검토" 사이클
- ITGC 검증: 직접 변경 로그에서 샘플 추출 → 승인 ticket 연계 확인. 승인 없는 건이 결함 (변경 건 테스트는 PC 2.9.1)
- 직접접근 경로 자체를 차단한 회사 = jump server 경유 + DB 접근제어 솔루션(Chakra Max·DBSafer 등). 이 경우 솔루션 로그가 증적
Q2. 서비스 계정(앱-DB 연결) 비밀번호, ITGC에서 어디까지 보나?
A. 비밀번호 설정값 캡쳐 + 평문 저장 여부.
- 증적 = DB 연결 계정 비밀번호 설정(복잡도·변경주기) 화면 캡쳐
- 소스코드·설정파일에 DB 비밀번호 평문 저장 여부 확인
- Vault·KMS 등 비밀번호 관리 솔루션 사용 여부 확인
- 금융권은 설정값만이 아니라 사람이 주기적으로 확인하는 수동 통제(점검표·확인자 서명 등)가 추가로 들어감 — 설정 적정성 + 그 수동 통제의 수행 증적까지 본다
- 깊이 있는 코드 리뷰는 ITGC 범위 X — 보안 진단·소스코드 점검 영역
Q3. DB가 직접변경 로그를 안 남기면 모집단(표 3행)을 어떻게 만드나?
A. native DB 로그에 의존하지 않는다. 앞단 증적으로 모집단을 만든다.
- 1차 모집단: DB접근제어 솔루션(Chakra Max·DBSafer·Petra 등) 세션·쿼리 로그. 이게 있으면 표 3행을 솔루션 로그로 수행
- 솔루션도 없으면: 직접변경 모집단을 만들 수 없다 → 탐지통제 부재. 이때는 예방통제(접근 제한 등) 확인
- 결함 판단 갈래:
- 직접접근 경로가 막혀있음 → 탐지 로그 없어도 예방통제로 보완 (잔여리스크 낮음)
- 직접접근이 열려있는데 로그·솔루션 둘 다 없음 → 결함 (KISA 결함사례 3번)
- 감사인은 "로그를 남기는 기술을 사용해라"고 지정하지 않는다. ITGC는 통제 존재·운영을 평가하지 구현 수단을 강제하지 않는다
관련 인증기준
- 2.5.1 사용자 계정 관리 (DB 계정 라이프사이클 — 퇴직자 회수)
- 2.5.5 특수 계정 및 권한 관리 (DBA·sa·sys 등)
- 2.6.3 응용프로그램 접근 (앱 경유 접근과의 구분)
- 2.7.1 암호정책 적용 (DB 암호화)
- 2.9.1 변경관리 (직접 변경 건 ticket 연계)
- 2.9.4 로그 및 접속기록 관리 (DB 접근·변경 로그)
관련 법규 / 표준
- 개인정보의 안전성 확보조치 기준 제7조 (개인정보의 암호화)
- 전자금융감독규정 제13조 (접근통제) — 금융권 DB 접근 추가 요구
- CIS Benchmarks (Oracle·MSSQL·PostgreSQL 등 DB별 hardening)
- ISO 27002 8.3 (Privileged Access Management)