2.9.1 변경관리
1. ISMS 원본
인증기준
정보시스템 관련 자산의 모든 변경내역을 관리할 수 있도록 절차를 수립·이행하고, 변경으로 인한 성능·보안에 미치는 영향을 사전에 분석하여야 한다.
주요 확인사항 (KISA 안내서)
- 정보시스템 변경에 대한 절차(변경 유형·승인 권한·영향분석) 를 수립·이행하고 있는가?
- 변경 수행 전 성능·보안 영향을 분석하고 있는가?
- 변경내역을 기록·관리하고 관련자에게 공유하고 있는가?
관련 법규
- 개인정보 보호법 제29조 (안전조치의무) — 간접
핵심 통제 (KISA 안내서)
- 변경 요청 → 승인 → 테스트 → 이관 단계 분리
- 변경 영향분석 (성능·보안·연관 시스템)
- 개발-운영 환경 분리 + 이관 통제 (2.8.3 / 2.8.6 연계)
- 긴급변경(emergency change) 별도 절차 — 사후 승인
- 변경 이력 기록 (형상관리)
결함사례 (KISA 안내서)
- 사례 1: 변경 승인 없이 운영 반영
- 사례 2: 개발자가 직접 운영 이관 — 단계 간 SoD 위반
- 사례 3: 테스트 수행 증적 없음
- 사례 4: 긴급변경 사후 승인 누락
2. ITGC 매핑
| 항목 | 값 |
|---|---|
| 분류 | 직접 (1-direct) |
| ITGC 영역 | PC (Program Changes) |
| 부영역 | — |
| 보조 영역 | PD (2.8.3 개발-운영 분리, 2.8.6 이관), APD (이관 권한), 2.9.4 (변경 로그) |
3. IT감사에서는 이렇게
3-A. 한국 비금융 ITGC 실무 표준 (실제 검증 범위)
2.9.1은 ITGC PC의 심장이다. 핵심 질문: "운영 시스템에 들어간 모든 변경이 승인·테스트·적절한 이관을 거쳤는가, 그리고 변경할 권한과 이관할 권한이 분리되어 있는가."
통제 구조는 4단계 — 요청 → 승인 → 테스트 → 이관(migration). 급소는 단계 간 SoD: 개발자(변경 작성) ≠ 이관자(운영 반영).
| ISMS 요구 | ITGC 테스트 절차 | 모집단 | 샘플 |
|---|---|---|---|
| 1. 변경 승인 | 변경 모집단에서 샘플 추출 → 변경요청·승인 증적 확인 | 기간 내 운영 반영 변경 전수 | 샘플링 |
| 2. 테스트 | 샘플 변경의 UAT·테스트 결과 증적 | (위 샘플) | 샘플링 |
| 3. 이관 SoD | 운영 이관 권한 보유자가 개발자와 분리되었나 | 이관 권한 보유 계정 | 전수 |
| 4. 긴급변경 | 긴급변경 목록 → 사후 승인·정당성 증적 | 긴급변경 전수 | 전수 또는 샘플 |
| 5. 모집단 완전성 | 변경관리 대장 ↔ 실제 운영 반영(이관 로그·소스 timestamp) 대조 | — | 완전성 확인 |
모집단 완전성이 PC의 급소: 변경관리 대장에 안 올라온 변경(우회 이관)이 있으면 샘플링 자체가 무의미하다. 그래서 운영 반영 시점(바이너리·소스 timestamp, 이관 로그) ↔ 변경 대장을 역대조해서 completeness를 확보한다. 대장에 없는 이관 = 비인가 변경(결함).
2.6.4와의 연결: DB data fix도 PC 변경이다. 애플리케이션 변경 + DB 직접변경(data fix) 둘 다 이 모집단에 들어온다. ([[2.6.4-데이터베이스-접근]] 교차점 참조 — "변경할 수 있냐(권한)는 APD, 실제 변경한 것의 확인은 PC")
자동 배포(CI/CD·GitOps) 환경: 파이프라인 승인 게이트·PR 머지 승인이 변경 승인 증적이다. 머지 권한 = 이관 권한이므로, 그게 개발자 본인과 분리되는지(또는 리뷰어 승인 강제)가 SoD 검증 포인트.
3-B. ISMS-P가 추가로 요구하지만 ITGC 실무 범위 밖
| ISMS 요구 | 절차 | 어디 영역 |
|---|---|---|
| 변경 코드 품질·보안 취약점 | 정적분석·코드리뷰 | 보안 진단 (ITGC 영역 X) |
| 형상관리 도구 운영 상세 | 도구 설정·운영 | 운영 영역 |
| 변경에 따른 개인정보 영향 | 개인정보 영향평가(PIA) | 개인정보 영역 (3장) |
4. Q&A
Q1. 변경 모집단 완전성, 어떻게 확보하나?
A. 변경관리 대장만 믿으면 안 된다.
- 대장은 "신고된 변경"이지 "실제 일어난 변경"이 아니다
- 운영 이관 로그·소스 timestamp·배포 이력과 역대조 → 대장에 없는 이관 = 비인가 변경
- 이 completeness 확보 없이 샘플링하면, 통제를 우회한 변경은 영영 모집단에 안 들어와서 못 잡는다
Q2. CI/CD·GitOps면 변경관리 증적이 뭔가?
A. PR 승인·파이프라인 승인 게이트가 승인 증적.
- PR 리뷰 승인 = 변경 승인, 머지 = 이관
- 검증 포인트: 머지(이관) 권한이 작성자 본인 단독으로 가능한가, 아니면 리뷰어 승인이 강제되는가 (branch protection)
- 자동화돼 있어도 SoD는 사라지지 않는다 — 승인 게이트의 권한 설정을 본다
Q3. 긴급변경(emergency change)은?
A. 사전 승인이 불가능하니 사후 승인 절차가 통제.
- 긴급변경 전수 추출 → 사후 승인 증적·정당성 확인
- 긴급변경 비율이 과다하면 정규 절차 우회 신호 — 그 자체가 통제 약화 징후
- 정상 변경을 "긴급"으로 분류해 테스트·승인을 건너뛰는 패턴이 흔한 결함
관련 인증기준
- 2.8.3 시험과 운영 환경 분리 (개발-운영 SoD의 물리적 토대)
- 2.8.6 운영환경 이관 (이관 단계 통제)
- 2.6.4 데이터베이스 접근 (DB data fix = PC 변경)
- 2.9.4 로그 및 접속기록 관리 (변경·이관 로그)
관련 법규 / 표준
- COBIT 2019 BAI06 (Managed IT Changes), BAI07 (이관·인수)
- ITIL Change Management
- ISO 27002 8.32 (Change Management)