변경 관리
더 많은 작업
- Change Management; 변경 관리, 변경 통제(change control)
- 정보시스템·애플리케이션·인프라에 대한 변경을 요청, 분석, 승인, 시험, 구현, 검토의 정해진 절차로 통제해 무단 변경과 위험한 변경을 막는 관리 프로세스
운영 중인 시스템에서 일어나는 장애와 보안 사고 가운데 상당수는 누군가 무엇을 바꾼 직후에 생긴다. 방화벽 규칙 하나를 열어 둔 채 잊거나, 검증하지 않은 패치가 서비스를 멈추거나, 개발자가 운영 서버에서 설정을 직접 고치는 식이다. 변경 관리는 이런 일을 막기 위해 모든 변경을 기록하고, 영향을 미리 분석하고, 권한 있는 사람이 승인하게 하며, 실패하면 되돌릴 수 있게 하는 절차이다. 보안 관점에서는 무결성(허가된 변경만 일어난다)과 가용성(변경 때문에 서비스가 멈추지 않는다)을 함께 지키는 통제이고, 감사 관점에서는 "누가 언제 무엇을 왜 바꿨는가"를 증명하는 책임 추적성(accountability) 수단이다.
CISSP에서는 보안 운영(7.9 변경 관리 프로세스를 이해하고 참여한다)과 소프트웨어 개발 보안(8.1 SDLC의 변경 관리, 8.3 변경 사항 감사와 기록) 두 영역에 걸쳐 나온다. 보안 담당자는 변경을 직접 승인하는 사람이라기보다 변경의 보안 영향을 평가하는 참여자로 그려진다.
- 무단 변경(unauthorized change)을 막고, 일어났다면 탐지한다.
- 변경이 기존 보안 통제를 약하게 만들지 않는지 사전에 분석한다(보안 영향 분석, security impact analysis).
- 변경 실패에 따른 장애를 줄이고, 실패하면 빨리 원상 복구한다.
- 승인된 보안 기준선(baseline configuration)을 최신 상태로 유지한다.
- 감사·규제 대응에 필요한 기록을 남긴다.
| 단계 | 하는 일 | 보안 관점의 확인 사항 |
|---|---|---|
| 1. 변경 요청 (Request for Change, RFC) | 요청자가 변경 내용, 사유, 대상 시스템, 일정, 담당자를 적어 제출한다. | 요청이 정식 경로로 들어왔는지, 요청자가 권한이 있는지 |
| 2. 영향·위험 분석 | 변경이 기능·성능·보안·다른 시스템에 미칠 영향을 분석하고 위험 등급을 매긴다. | 열리는 포트, 권한 변화, 데이터 흐름 변화, 규제 영향 |
| 3. 승인 | 위험 수준에 따라 담당 관리자 또는 변경 관리 위원회(CAB, Change Advisory Board / CCB, Configuration Control Board)가 승인·반려한다. | 요청자와 승인자의 직무 분리 |
| 4. 시험 | 운영과 분리된 시험 환경에서 변경을 검증하고 회귀 시험을 한다. | 보안 통제가 그대로 동작하는지, 취약점이 새로 생기지 않았는지 |
| 5. 구현 | 정해진 변경 시간대(maintenance window)에 승인된 내용만 적용한다. | 승인 범위를 벗어난 추가 변경 금지 |
| 6. 검토·문서화 | 결과를 확인하고 변경 기록, 기준선, 구성 정보를 갱신한다. 실패하면 롤백하고 원인을 분석한다. | 구현 후 보안 영향 재확인, 기록 보존 |
NIST SP 800-128은 보안 영향 분석을 가능하면 승인·구현 전에 하고, 구현과 시험 뒤에 다시 확인해 변경이 승인한 대로 적용되었는지와 예상하지 못한 영향이 있는지 보라고 한다. NIST SP 800-53의 형상 관리(CM) 통제군에서는 CM-3(형상 변경 통제), CM-4(영향 분석), CM-5(변경에 대한 접근 제한)가 이 절차에 해당한다.
ITIL 등 IT 서비스 관리(ITSM) 실무에서는 변경을 위험과 긴급성에 따라 세 가지로 나눈다.
| 유형 | 설명 | 승인 방식 | 예 |
|---|---|---|---|
| 표준 변경 (standard change) | 위험이 낮고 절차가 정해진, 자주 반복되는 변경 | 사전 승인(pre-approved). 건마다 위원회를 거치지 않는다. | 백신 패턴 갱신, 계정 생성·삭제, 고장 난 부품 교체 |
| 일반 변경 (normal change) | 표준도 긴급도 아닌 일반적인 변경 | 위험도에 따라 관리자 또는 변경 관리 위원회 승인 | 새 기능 배포, 방화벽 정책 추가, 서버 증설 |
| 긴급 변경 (emergency change) | 장애 복구나 심각한 취약점 대응처럼 즉시 해야 하는 변경 | 소수의 긴급 승인권자(ECAB 등)가 빠르게 승인하고, 사후에 정식 검토·문서화 | 실제 공격 중인 취약점의 긴급 패치 |
- 긴급 변경도 절차를 건너뛰는 것이 아니라 빠른 절차를 밟는 것이다. NIST SP 800-128은 예정에 없던 변경에 대해 신속 검토·승인 요건과, 절차 밖에서 이루어진 변경을 사후에 분석·시험·승인하는 요건을 두라고 한다.
- NIST SP 800-128은 공급사 보안 패치, 백신 시그니처 갱신, 계정 생성·삭제, 결함 있는 부품 교체 등을 사전 승인 변경이나 형상 통제 대상 밖으로 둘 수 있는 예로 든다.
| 구분 | 변경 관리 (Change Management) | 형상 관리 (Configuration Management) |
|---|---|---|
| 관심사 | 변경이라는 행위를 어떻게 통제할 것인가 | 시스템이 지금 어떤 상태(구성 항목, 버전, 설정)인가 |
| 주요 산출물 | 변경 요청서, 영향 분석, 승인 기록, 변경 일정 | 기준선(baseline), 구성 항목(CI) 목록, 구성 관리 데이터베이스(CMDB) |
| 관계 | 승인된 변경이 적용되면 기준선을 갱신한다 | 기준선과 실제 상태를 비교해 무단 변경을 찾아낸다 |
두 프로세스는 짝을 이룬다. 변경 관리만 있고 형상 관리가 없으면 무엇이 바뀌었는지 확인할 기준이 없고, 형상 관리만 있으면 기준선이 왜 바뀌었는지 설명할 수 없다. 형상 모니터링 도구가 기준선과 다른 설정을 발견하면, 대응하는 승인된 변경 요청이 있는지 확인하고 없으면 보안 사고로 다룬다.
CISSP 8.3은 소프트웨어 보안의 효과를 평가하는 수단으로 변경 사항 감사와 기록(auditing and logging of changes)을 든다.
모든 변경 요청에는 실패했을 때 원래 상태로 돌아가는 방법(롤백 또는 백아웃 계획, rollback/back-out plan)을 적어야 한다.
- 변경 전 설정·데이터를 백업하고, 이전 기준선과 이전 배포 버전을 보관한다.
- 롤백 판단 기준(어떤 지표가 얼마나 나빠지면 되돌릴지)과 판단 권한자를 미리 정한다.
- 롤백 절차 자체도 시험 환경에서 검증한다.
- 데이터베이스 스키마 변경처럼 되돌리기 어려운 변경은 단계적 배포, 기능 플래그, 블루·그린 배포 같은 방법으로 위험을 줄인다.
- 변경 관리의 일차 목적은 무단·검증되지 않은 변경 방지이다. 보안 담당자는 변경의 보안 영향 분석에 참여한다.
- 순서를 기억한다: 요청 → 영향 분석 → 승인 → 시험 → 구현 → 검토·문서화. "가장 먼저"는 정식 변경 요청 제출이다.
- 긴급 변경도 기록하고 사후 검토·승인을 받는다. 흔한 오답: 긴급하니 기록을 생략한다.
- 개발자가 운영 시스템에 직접 변경을 반영하는 것은 직무 분리 위반이다. 요청자, 승인자, 구현자를 분리한다.
- 형상 관리는 "무엇이 어떤 상태인가", 변경 관리는 "어떻게 바꾸는가"를 다룬다. 기준선과 실제 상태가 다르면 무단 변경을 의심한다.
- 모든 변경에는 롤백 계획이 있어야 한다.