NIST SP 800-34
더 많은 작업
NIST SP 800-34(Contingency Planning Guide for Federal Information Systems)는 미국 국립표준기술연구소(NIST)가 정보시스템의 장애·재해·비상 상황에 대비하여 업무 영향 분석, 복구 전략, 비상계획 수립, 시험 및 유지관리 절차를 제시한 정보시스템 비상계획 지침이다.
NIST SP 800-34는 정보시스템이 자연재해, 설비 고장, 정전, 사이버 공격, 인적 오류 등으로 중단되었을 때 조직의 핵심 업무를 지원하는 시스템과 서비스를 복구하기 위한 계획 수립 방법을 설명한다.
정보시스템 비상계획(Information System Contingency Planning)은 장애 발생 이후의 복구 절차뿐 아니라 장애 예방, 업무 영향 분석, 복구 목표 설정, 대체 시설 확보, 백업, 복구 훈련 및 계획 유지관리를 포함한다.
NIST SP 800-34는 미국 연방정부의 정보시스템을 주요 대상으로 개발되었으나, 민간기업과 다른 조직에서도 업무 연속성 및 재해 복구 체계를 설계하는 참고자료로 활용할 수 있다.[1]
| 항목 | 내용 |
|---|---|
| 문서 번호 | NIST SP 800-34 |
| 정식 명칭 | Contingency Planning Guide for Federal Information Systems |
| 한국어 명칭 | 연방 정보시스템을 위한 비상계획 지침 |
| 발행기관 | 미국 국립표준기술연구소(NIST) |
| 최초 발행 | 2002년 6월 |
| 현행 개정판 | Revision 1 |
| Rev. 1 발행 | 2010년 5월 |
| 최종 수정 | 2010년 11월 11일 |
| 주요 분야 | 정보시스템 비상계획, 업무 영향 분석, 재해 복구, 업무 연속성 |
| 주요 대상 | 정보시스템 소유자, 시스템 관리자, 비상계획 담당자, 보안 담당자, 조직 관리자 |
| 관련 표준 | NIST SP 800-53, NIST SP 800-37, FIPS 199 |
| 공식 페이지 | NIST CSRC |
| 원문 |
2026년 10월 25일 기준 NIST CSRC에 게시된 현행 최종 발행본은 SP 800-34 Revision 1의 2010년 11월 수정본이다. 별도의 Revision 2 최종 발행본은 확인되지 않는다.[2]
정보시스템의 장애는 조직의 업무 수행에 직접적인 영향을 미친다.
시스템 장애가 발생하더라도 모든 업무가 동일한 수준의 영향을 받는 것은 아니다. 일부 시스템은 수 시간의 중단을 허용할 수 있지만, 다른 시스템은 짧은 중단만으로도 조직의 핵심 기능이 마비될 수 있다.
NIST SP 800-34는 이러한 차이를 고려하여 다음 사항을 결정하도록 안내한다.
- 어떤 업무와 정보시스템이 중요한가?
- 시스템 중단이 조직에 어떤 영향을 미치는가?
- 업무 중단을 최대 얼마 동안 허용할 수 있는가?
- 각 시스템을 언제까지 복구해야 하는가?
- 어느 시점의 데이터까지 복원해야 하는가?
- 복구에 필요한 인력, 시설, 장비 및 데이터는 무엇인가?
- 복구 과정에서 어떤 시스템을 먼저 가동해야 하는가?
- 복구 절차가 실제로 작동하는지 어떻게 검증할 것인가?
이러한 질문에 대한 답을 업무 영향 분석과 복구 전략으로 구체화하고, 실제 장애 상황에서 실행할 수 있는 절차로 문서화하는 것이 지침의 핵심이다.
정보시스템 비상계획은 조직의 업무 연속성 관리체계와 밀접하게 연관된다.
다만 정보시스템 비상계획, 업무 연속성 계획, 재해 복구 계획, 사고 대응 계획은 서로 동일한 개념이 아니다.
NIST SP 800-34 Rev. 1은 비상 상황에 대응하는 8가지 계획 유형을 구분하고, 각 계획의 목적과 적용 범위 및 상호 관계를 설명한다.[1]
업무 연속성 계획(Business Continuity Plan, BCP)은 중대한 업무 중단 상황에서 조직의 업무 프로세스를 지속하기 위한 계획이다.
정보시스템뿐 아니라 인력, 시설, 업무 절차, 외부 공급업체 등 업무 수행에 필요한 자원을 포괄한다.
정보시스템이 중단되더라도 수작업이나 대체 업무 절차를 통해 핵심 업무를 유지하는 방안이 포함될 수 있다.
운영 연속성 계획(Continuity of Operations Plan, COOP)은 조직의 필수 기능을 비상 상황에서도 지속하기 위한 계획이다.
특히 미국 연방정부에서는 기관의 필수 기능을 유지하고 대체 시설이나 대체 운영체계로 업무를 이전하는 절차와 관련된다.
COOP는 개별 정보시스템의 기술적 복구보다 조직의 필수 기능 유지에 초점을 둔다.
위기 커뮤니케이션 계획(Crisis Communications Plan)은 비상 상황에서 조직 내부와 외부 이해관계자에게 정보를 전달하기 위한 계획이다.
- 직원 및 관리자에게 상황 전파.
- 고객과 이용자에게 서비스 중단 안내.
- 언론 및 대외기관 대응.
- 대외 발표 책임자 지정.
- 상황별 의사소통 절차와 승인체계 마련.
핵심 기반시설 보호 계획(Critical Infrastructure Protection Plan, CIP)은 핵심 기반시설의 보호와 복원력을 다루는 계획이다.
정보통신, 전력, 교통 등 조직과 사회의 필수 기능을 지원하는 기반시설의 위험을 고려한다.
사이버 사고 대응 계획(Cyber Incident Response Plan, CIRP)은 사이버 공격으로 발생한 보안사고를 탐지하고 대응하기 위한 계획이다.
- 보안사고 식별 및 분석.
- 침해 범위 확인.
- 피해 확산 방지.
- 악성코드 및 공격자 활동 대응.
- 침해된 시스템과 데이터의 복구.
- 사고 보고 및 후속 조치.
사이버 사고가 정보시스템의 장기 중단으로 이어지면 CIRP와 정보시스템 비상계획이 함께 실행될 수 있다.
재해 복구 계획(Disaster Recovery Plan, DRP)은 대규모 장애나 재해로 주 시설을 사용할 수 없을 때 정보시스템과 기반시설을 대체 장소에서 복구하기 위한 계획이다.
NIST SP 800-34 Rev. 1에서 DRP는 주로 시설 이전이 필요한 대규모 정보시스템 장애에 대응한다.
따라서 모든 정보시스템 장애에 반드시 DRP가 발동되는 것은 아니다.
정보시스템 비상계획(Information System Contingency Plan, ISCP)은 개별 정보시스템의 장애 평가와 복구 절차를 정의한다.
ISCP는 시스템이 원래 장소에 있든 대체 장소에 있든 적용할 수 있다.
반면 DRP는 주 시설을 사용할 수 없어 다른 장소로 운영을 이전하는 상황에 초점을 둔다.
예를 들어 데이터센터 화재로 대체 데이터센터를 가동해야 한다면 DRP를 통해 시설 이전을 수행하고, 각 시스템의 구체적인 복구는 해당 ISCP에 따라 진행할 수 있다.
시설 이용자 비상계획(Occupant Emergency Plan, OEP)은 화재, 폭발, 화학물질 누출 등 사람의 생명과 안전에 영향을 미치는 사건에 대응하기 위한 계획이다.
- 대피 및 피난.
- 응급 구조와 인명 보호.
- 시설 내 비상 통보.
- 비상 대피 장소 지정.
- 시설 이용자의 안전 확인.
OEP는 시스템 복구보다 인명 안전을 우선하며, 다른 복구 계획보다 먼저 발동될 수 있다.
| 계획 | 주요 목적 | 적용 범위 |
|---|---|---|
| BCP | 핵심 업무 프로세스 지속 | 업무, 인력, 시설, 정보시스템 등 |
| COOP | 조직의 필수 기능 유지 | 조직 차원의 필수 업무와 운영체계 |
| Crisis Communications Plan | 위기 상황의 정보 전달 | 내부 직원, 고객, 언론, 외부기관 |
| CIP | 핵심 기반시설 보호 | 주요 기반시설 및 필수 서비스 |
| CIRP | 사이버 공격 대응 | 보안사고와 침해된 시스템 |
| DRP | 재해 발생 시 정보시스템 이전 및 복구 | 대체 시설과 IT 기반시설 |
| ISCP | 개별 정보시스템 복구 | 특정 정보시스템 |
| OEP | 인명 및 시설 안전 | 시설 이용자와 물리적 시설 |
각 계획은 별도로 작성할 수도 있고 조직의 특성에 따라 통합할 수도 있다.
다만 계획의 적용 범위, 발동 조건, 책임자 및 상호 연계 절차를 명확히 해야 한다.
NIST SP 800-34 Rev. 1은 정보시스템 비상계획을 개발하고 유지하기 위한 7단계 절차를 제시한다.[1]
| 단계 | 영문 명칭 | 주요 활동 |
|---|---|---|
| 1 | Develop the Contingency Planning Policy | 비상계획 정책 수립 |
| 2 | Conduct the Business Impact Analysis | 업무 영향 분석 수행 |
| 3 | Identify Preventive Controls | 예방 통제 식별 |
| 4 | Create Contingency Strategies | 비상 대응 및 복구 전략 수립 |
| 5 | Develop an Information System Contingency Plan | 정보시스템 비상계획 작성 |
| 6 | Ensure Plan Testing, Training, and Exercises | 계획 시험·교육·훈련 |
| 7 | Ensure Plan Maintenance | 계획 유지관리 |
이 7단계는 비상계획을 수립하고 운영하기 위한 절차이며, NIST SP 800-37의 위험관리 프레임워크(RMF) 7단계와는 다른 체계이다.
조직은 비상계획 수립과 운영을 위한 정책을 마련해야 한다.
정책에는 다음 사항을 포함할 수 있다.
- 비상계획의 목적과 적용 범위.
- 비상계획 담당 조직 및 책임자.
- 계획 수립과 운영에 필요한 자원.
- 담당자의 역할과 책임.
- 교육 및 훈련 요구사항.
- 계획 시험 및 검토 주기.
- 계획 유지관리 절차.
- 데이터 백업 주기와 보관 요구사항.
정책은 조직의 관리자가 승인하고 관련 담당자에게 전달해야 한다.
비상계획의 수립과 실행에는 여러 부서의 협력이 필요하므로 조직 차원의 책임과 권한을 명확히 하는 것이 중요하다.
업무 영향 분석(Business Impact Analysis, BIA)은 정보시스템의 중단이 조직의 업무에 미치는 영향을 분석하는 활동이다.
BIA는 시스템의 중요도와 복구 우선순위를 결정하고, 복구 전략을 수립하기 위한 근거를 제공한다.
NIST SP 800-34 Rev. 1은 정보시스템을 대상으로 다음 세 가지 주요 활동을 제시한다.
- 업무 프로세스와 복구 중요도 결정.
- 복구에 필요한 자원 식별.
- 시스템 자원의 복구 우선순위 결정.
BIA의 세부 내용은 별도 절에서 설명한다.
예방 통제(Preventive Controls)는 장애 발생 가능성을 낮추거나 장애의 영향을 줄이기 위한 보호조치이다.
대표적인 예시는 다음과 같다.
- 무정전 전원 장치(UPS).
- 비상 발전기.
- 화재 감지 및 소화 설비.
- 누수 감지 장치.
- 적절한 냉각 및 공조 설비.
- 시스템 구성요소의 이중화.
- 데이터 백업 및 원격지 보관.
- 시설 및 장비의 정기 점검.
예방 통제는 장애 발생 이후의 복구 부담을 줄일 수 있지만, 모든 장애를 방지할 수 있는 것은 아니다.
따라서 예방 통제와 복구 전략을 함께 마련해야 한다.
비상 전략(Contingency Strategies)은 장애 발생 시 정보시스템을 복구하기 위한 기술적·관리적 수단을 결정하는 과정이다.
주요 고려사항은 다음과 같다.
- 업무 영향 분석에서 도출한 복구 목표.
- 데이터 백업과 복제 방식.
- 대체 처리시설의 유형.
- 대체 장비의 확보 방법.
- 네트워크와 통신 서비스의 복구.
- 복구에 필요한 인력과 외부 공급업체.
- 복구 비용과 유지관리 비용.
- 대체 시설과 시스템의 보안 요구사항.
복구 전략은 업무 영향 분석 결과를 바탕으로 결정해야 한다.
예를 들어 수 시간 이내 복구가 필요한 시스템과 며칠 동안 중단할 수 있는 시스템에 동일한 복구 전략을 적용할 필요는 없다.
정보시스템 비상계획(ISCP)은 실제 장애 상황에서 담당자가 수행할 절차를 문서화한 것이다.
계획에는 시스템 정보, 담당자, 발동 조건, 복구 순서, 필요한 자원, 구체적인 복구 절차 및 정상 운영 전환 방법을 포함한다.
단순한 정책 선언이나 복구 목표의 나열만으로는 충분하지 않다.
실제 장애 상황에서 담당자가 절차를 따라 시스템을 복구할 수 있도록 구체적인 실행 정보를 제공해야 한다.
비상계획을 작성한 이후에는 실제로 실행 가능한지 검증해야 한다.
NIST SP 800-34는 시험·교육·훈련(Testing, Training, and Exercises, TT&E)을 통해 계획의 효과성과 담당자의 준비 상태를 확인하도록 안내한다.
- 시험(Test): 시스템, 구성요소 및 복구 기능이 예상대로 작동하는지 확인.
- 교육(Training): 담당자가 역할과 복구 절차를 이해하도록 교육.
- 훈련(Exercise): 가상의 장애 상황에서 조직과 담당자가 계획을 실행하는 과정을 검증.
시험과 훈련에서 발견한 문제는 계획과 복구 전략에 반영해야 한다.
정보시스템과 조직의 환경은 지속적으로 변경된다.
시스템 구성, 담당자, 외부 공급업체 또는 업무 중요도가 달라지면 기존 비상계획이 더 이상 적절하지 않을 수 있다.
따라서 계획을 정기적으로 검토하고 중요한 변경사항이 발생하면 갱신해야 한다.
주요 유지관리 대상은 다음과 같다.
- 시스템 구성 및 자산 목록.
- 담당자와 비상연락망.
- 복구 우선순위.
- 백업 및 복구 절차.
- 대체 시설과 공급업체 계약.
- 시스템 간 의존관계.
- 시험 및 훈련 결과.
- 복구 목표와 업무 영향 분석 결과.
업무 영향 분석(BIA)은 NIST SP 800-34의 핵심 절차 중 하나이다.
BIA는 정보시스템 중단이 조직의 업무에 미치는 영향을 파악하고, 복구 목표와 우선순위를 설정하는 데 사용된다.
하나의 정보시스템은 여러 업무 프로세스를 지원할 수 있다.
예를 들어 조직의 데이터베이스 시스템이 다음 업무를 동시에 지원할 수 있다.
- 고객 서비스.
- 주문 처리.
- 회계 및 정산.
- 내부 보고.
- 외부기관과의 정보 교환.
각 업무는 시스템 중단에 따른 영향과 허용 가능한 중단 시간이 다를 수 있다.
따라서 시스템 자체의 기술적 중요도뿐 아니라 해당 시스템이 지원하는 업무의 중요도를 함께 분석해야 한다.
시스템 중단에 따른 영향은 여러 측면에서 평가할 수 있다.
- 업무 수행 불능.
- 재무적 손실.
- 고객 서비스 중단.
- 법률 및 규제 요구사항 위반.
- 조직의 평판 손상.
- 다른 시스템이나 외부기관에 미치는 영향.
영향은 중단 시간이 길어짐에 따라 증가할 수 있다.
BIA에서는 업무 담당자, 시스템 소유자, 관리자 및 관련 외부기관과 협력하여 이러한 영향을 분석한다.
최대 허용 중단 시간(Maximum Tolerable Downtime, MTD)은 업무 프로세스의 중단을 조직이 허용할 수 있는 최대 시간을 의미한다.
MTD는 단순히 서버가 중단되어도 되는 시간이 아니다.
정보시스템의 복구와 업무 프로세스의 재개에 필요한 시간을 함께 고려한다.
예를 들어 어떤 업무의 MTD가 24시간이라면, 시스템 복구뿐 아니라 업무 재개에 필요한 활동까지 고려하여 24시간 안에 업무를 정상화할 수 있어야 한다.
MTD를 초과하면 조직이 수용할 수 없는 수준의 업무 영향이 발생할 수 있다.
복구 시간 목표(Recovery Time Objective, RTO)는 시스템 자원을 복구해야 하는 목표 시간을 의미한다.
RTO는 시스템 복구 전략을 결정하는 주요 기준이다.
일반적으로 RTO는 해당 시스템이 지원하는 업무의 MTD보다 짧게 설정해야 한다.
시스템이 복구된 이후에도 데이터 검증, 누락 거래 처리, 업무 재개 준비 등에 시간이 필요할 수 있기 때문이다.
복구 시점 목표(Recovery Point Objective, RPO)는 장애 발생 이후 데이터를 복원해야 하는 과거의 시점을 의미한다.
RPO는 시간으로 표현되는 허용 가능한 데이터 손실 범위와 관련된다.
예를 들어 RPO가 4시간이면 장애 발생 시점을 기준으로 최대 4시간 전의 데이터 상태까지 복구하는 것을 허용하는 목표로 이해할 수 있다.
RPO는 데이터 백업 주기와 복제 방식에 영향을 미친다.
RTO와 RPO는 서로 다른 목표이다.
- RTO: 시스템을 얼마나 빨리 복구해야 하는가?
- RPO: 어느 시점의 데이터까지 복구해야 하는가?
| 지표 | 영문 | 의미 | 주요 활용 |
|---|---|---|---|
| MTD | Maximum Tolerable Downtime | 업무가 중단되어도 허용할 수 있는 최대 시간 | 업무 연속성 요구사항과 복구 목표의 상한 결정 |
| RTO | Recovery Time Objective | 시스템 자원을 복구해야 하는 목표 시간 | 복구 전략, 대체 시설, 복구 자동화 수준 결정 |
| RPO | Recovery Point Objective | 복구해야 하는 데이터의 목표 시점 | 백업 주기와 데이터 복제 방식 결정 |
예를 들어 특정 업무의 MTD가 24시간이고 시스템 복구 이후 업무를 재개하는 데 4시간이 필요하다면, 시스템 RTO는 이러한 추가 시간을 고려하여 설정해야 한다.
RPO는 업무 중단 시간의 일부가 아니라 데이터 복구 시점을 나타내므로 MTD와 직접 합산하지 않는다.
NIST SP 800-34 Rev. 1은 BIA를 통해 MTD, RTO, RPO와 시스템 자원의 복구 우선순위를 결정하도록 안내한다.[1]
복구에 필요한 자원은 서버나 저장장치에 한정되지 않는다.
- 운영체제와 애플리케이션.
- 데이터베이스.
- 네트워크 장비와 통신회선.
- 인증 및 접근통제 시스템.
- 저장장치와 백업 데이터.
- 전력 및 공조 설비.
- 시스템 관리자와 운영 인력.
- 외부 서비스 제공업체.
- 운영 매뉴얼과 중요 기록.
복구 순서는 이러한 자원의 의존관계를 고려하여 결정해야 한다.
예를 들어 애플리케이션이 데이터베이스와 인증 서비스를 필요로 한다면, 애플리케이션 자체보다 해당 기반 서비스를 먼저 복구해야 할 수 있다.
복구 전략은 BIA에서 결정한 목표를 충족하기 위한 구체적인 기술과 운영 방법을 선정하는 과정이다.
NIST SP 800-34는 데이터 백업, 대체 시설, 장비 교체, 통신 서비스 복구 등 다양한 전략을 설명한다.[1]
데이터 백업은 시스템 장애나 데이터 손상 이후 정보를 복원하기 위한 핵심 수단이다.
NIST SP 800-34는 전체 백업, 증분 백업, 차등 백업 등의 방법을 설명한다.
| 방식 | 영문 | 특징 |
|---|---|---|
| 전체 백업 | Full Backup | 선택한 모든 데이터를 백업 |
| 증분 백업 | Incremental Backup | 마지막 백업 이후 변경된 데이터만 백업 |
| 차등 백업 | Differential Backup | 마지막 전체 백업 이후 변경된 데이터를 백업 |
전체 백업은 복구 절차가 상대적으로 단순하지만 백업 시간과 저장공간이 많이 필요하다.
증분 백업은 백업에 필요한 데이터량을 줄일 수 있지만 복원 과정에서 여러 백업 세트가 필요할 수 있다.
차등 백업은 마지막 전체 백업 이후의 변경사항을 누적하여 저장한다.
백업 방식은 RPO, RTO, 저장 용량, 데이터 변경량 및 복원 성능을 고려하여 결정한다.
백업 정책에는 다음 사항을 정의할 수 있다.
- 백업 대상.
- 백업 주기.
- 백업 데이터의 보존 기간.
- 저장매체와 저장 위치.
- 원격지 백업 보관 방법.
- 백업 데이터 접근 권한.
- 백업 데이터의 기밀성 및 무결성 보호.
- 백업 매체의 관리 및 교체.
- 백업 복원 시험 절차.
백업 작업이 정상적으로 완료되었다는 기록만으로 실제 복구 가능성이 보장되는 것은 아니다.
조직은 백업 데이터를 실제로 복원하고 복구 목표를 충족하는지 검증해야 한다.
원격 데이터 복제는 주 시스템의 데이터를 다른 장소에 전달하여 장애 시 복구에 활용하는 방법이다.
NIST SP 800-34는 전자 볼팅(Electronic Vaulting), 원격 저널링(Remote Journaling), 데이터 미러링 등의 기술을 설명한다.
| 기술 | 주요 특징 |
|---|---|
| 전자 볼팅 | 백업 데이터를 통신망을 통해 원격지로 전송 |
| 원격 저널링 | 데이터베이스 등의 변경 기록을 원격지로 전달 |
| 데이터 미러링 | 저장장치나 시스템의 데이터를 다른 위치에 복제 |
원격 복제는 RPO를 줄이는 데 도움이 될 수 있다.
그러나 데이터 삭제나 손상도 복제될 수 있으므로 시점별 복구가 가능한 백업과 구분해야 한다.
대체 복구 사이트(Alternate Recovery Site)는 주 시설을 사용할 수 없을 때 정보시스템을 복구하거나 운영하기 위한 장소이다.
NIST SP 800-34는 준비 수준에 따라 콜드 사이트, 웜 사이트, 핫 사이트를 구분하고 모바일 사이트와 미러 사이트 등의 변형을 설명한다.[1]
콜드 사이트(Cold Site)는 정보시스템을 설치할 수 있는 공간과 기본 시설을 갖춘 대체 장소이다.
일반적으로 전력, 통신 연결 및 환경 제어를 위한 기반시설이 마련되어 있지만 실제 시스템 장비는 충분히 설치되어 있지 않다.
- 초기 및 유지 비용이 상대적으로 낮음.
- 장비 조달과 설치에 시간이 필요함.
- 비교적 긴 복구 시간을 허용하는 시스템에 적합할 수 있음.
웜 사이트(Warm Site)는 일부 시스템 장비와 기반시설을 미리 준비한 대체 장소이다.
- 서버, 통신장비 및 소프트웨어 일부를 사전에 설치.
- 복구 시 추가 설정이나 데이터 복원이 필요할 수 있음.
- 비용과 복구 준비 수준이 콜드 사이트와 핫 사이트의 중간에 해당.
핫 사이트(Hot Site)는 정보시스템을 신속하게 가동할 수 있도록 장비와 기반시설을 갖춘 대체 장소이다.
- 필요한 시스템 장비와 지원 인프라를 사전에 확보.
- 복구에 필요한 준비 시간이 상대적으로 짧음.
- 유지관리 비용이 높음.
핫 사이트를 확보했다고 해서 자동으로 무중단 운영이 보장되는 것은 아니다.
실제 복구 시간은 데이터 동기화 상태, 네트워크 구성, 시스템 설정 및 전환 절차 등에 따라 달라진다.
미러 사이트(Mirrored Site)는 주 사이트와 기술적으로 동일한 구성을 갖추고 데이터를 자동으로 실시간 미러링하는 대체 시설이다.
높은 수준의 가용성을 확보하는 데 활용할 수 있지만 구축과 운영에 많은 비용이 필요하다.
미러 사이트 역시 공통 장애 원인, 데이터 손상 및 복제 오류 등을 고려해야 한다.
모바일 사이트(Mobile Site)는 필요한 통신 및 시스템 장비를 갖춘 이동식 시설이다.
장애가 발생한 장소나 지정된 위치로 이동하여 복구 환경을 제공할 수 있다.
다만 이동 시간 외에도 장비 설치, 통신 연결 및 시스템 구성 시간이 필요하다.
| 유형 | 준비 수준 | 복구 준비 시간 | 일반적인 비용 수준 |
|---|---|---|---|
| 콜드 사이트 | 기본 시설 중심 | 김 | 낮음 |
| 웜 사이트 | 일부 장비 및 시스템 준비 | 중간 | 중간 |
| 핫 사이트 | 운영에 필요한 장비와 기반시설 준비 | 짧음 | 높음 |
| 미러 사이트 | 주 사이트와 동일한 구성 및 실시간 데이터 미러링 | 매우 짧음 | 매우 높음 |
| 모바일 사이트 | 이동식 시설과 지정된 장비 준비 | 이동·설치 조건에 따라 달라짐 | 구성에 따라 달라짐 |
NIST SP 800-34는 각 사이트 유형의 준비 수준과 비용을 비교하지만, 모든 조직에 적용되는 고정된 RTO 값을 지정하지는 않는다.
대체 사이트는 BIA에서 도출한 복구 목표와 비용을 고려하여 선정해야 한다.
대체 사이트는 다음과 같은 방법으로 확보할 수 있다.
- 조직이 직접 소유하거나 운영하는 전용 시설.
- 다른 조직과의 상호 지원 협약.
- 상업적으로 임대하거나 계약한 복구 시설.
상호 지원 협약(Reciprocal Agreement)을 활용하는 경우에는 양측의 시스템 호환성과 복구 자원 확보 가능성을 검토해야 한다.
상업적 복구 시설을 이용하는 경우에는 동일한 시설을 여러 고객이 공유할 수 있다는 점도 고려해야 한다.
광역 재해로 여러 고객이 동시에 복구를 요청하면 자원이 부족해질 수 있으므로 계약상 우선순위와 서비스 제공 조건을 확인해야 한다.
NIST SP 800-34 Rev. 1은 ISCP의 실행 절차를 크게 세 단계로 구분한다.
- 발동 및 통지(Activation and Notification).
- 복구(Recovery).
- 재구성 및 정상화(Reconstitution).
계획 문서에는 이 세 단계 외에도 시스템 개요, 담당자, 승인 정보 및 부록을 포함한다.[1]
지원 정보(Supporting Information)는 계획을 실행하기 위한 기본 정보를 제공한다.
주요 내용은 다음과 같다.
- 시스템 명칭과 목적.
- 시스템 구성 및 운영 환경.
- 계획의 적용 범위.
- 계획의 가정과 전제조건.
- 담당 조직과 역할.
- 복구에 필요한 주요 자원.
- 관련 시스템 및 외부기관과의 관계.
발동 및 통지(Activation and Notification)는 시스템 장애를 확인하고 비상계획의 실행 여부를 결정하는 단계이다.
주요 활동은 다음과 같다.
- 장애 발생 사실 확인.
- 인명 및 시설 안전 관련 조치.
- 장애 범위와 영향 평가.
- 비상계획 발동 조건 확인.
- 계획 발동 승인.
- 복구 담당자에게 통지.
- 관련 조직 및 외부기관에 상황 전달.
계획에는 누가 비상계획을 발동할 권한을 가지는지 명확하게 정의해야 한다.
또한 연락 대상과 연락 순서를 미리 정해야 한다.
복구(Recovery) 단계에서는 사전에 정의한 전략과 절차에 따라 시스템을 복구한다.
주요 활동은 다음과 같다.
- 복구 인력과 자원 확보.
- 복구 환경 준비.
- 네트워크 및 기반 서비스 복구.
- 시스템 장비와 운영체제 복구.
- 데이터 복원.
- 애플리케이션 복구.
- 시스템 간 연결 확인.
- 복구 진행 상황 보고.
복구 순서는 BIA에서 정한 우선순위와 시스템 의존관계를 반영해야 한다.
재구성 및 정상화(Reconstitution)는 복구된 시스템을 검증하고 정상 운영체계로 전환하는 단계이다.
주요 활동은 다음과 같다.
- 복구된 데이터의 검증.
- 시스템 기능 시험.
- 보안 기능 및 설정 확인.
- 업무 담당자의 서비스 검증.
- 정상 운영 재개 승인.
- 사용자와 관련 조직에 복구 완료 통지.
- 임시 복구 환경의 정리.
- 복구 활동 기록 및 사후 분석.
- 비상계획 종료.
대체 시설에서 운영하던 시스템을 주 시설로 복귀시키는 경우에는 복귀 절차와 데이터 동기화도 고려해야 한다.
복구가 완료되었다는 기술적 판단과 실제 업무를 정상적으로 수행할 수 있다는 판단은 구분해야 한다.
NIST SP 800-34는 비상계획의 실효성을 확보하기 위해 정기적인 시험·교육·훈련을 수행하도록 안내한다.
시험(Test)은 시스템이나 구성요소의 복구 기능이 예상대로 작동하는지 확인하는 활동이다.
대표적인 시험 대상은 다음과 같다.
- 백업 데이터 복원.
- 대체 장비에서의 시스템 기동.
- 대체 사이트로의 시스템 전환.
- 네트워크 연결 복구.
- 데이터베이스 복구.
- 복구된 시스템의 기능 검증.
시험에서는 성공 여부뿐 아니라 실제 소요 시간을 측정할 수 있다.
측정 결과를 RTO와 비교하면 복구 전략이 목표를 충족하는지 판단하는 데 도움이 된다.
교육(Training)은 비상계획 담당자가 자신의 역할과 책임을 이해하도록 하는 활동이다.
교육 대상에는 시스템 관리자뿐 아니라 비상계획 책임자, 업무 담당자, 시설 관리자 및 관련 외부업체 인력이 포함될 수 있다.
훈련(Exercise)은 가상의 장애 상황을 설정하여 계획과 조직의 대응체계를 검증하는 활동이다.
주요 방식은 다음과 같다.
- 토의 기반 훈련: 가상의 상황을 제시하고 담당자가 대응 절차를 검토.
- 기능 훈련: 특정 복구 기능이나 담당 조직의 대응 활동을 실제로 수행.
- 복구 절차 실행: 대체 환경에서 시스템 복구와 업무 재개 과정을 검증.
훈련은 담당자 간 의사소통, 의사결정, 역할 분담 및 복구 절차의 문제를 발견하는 데 활용된다.
시험과 훈련이 끝나면 결과를 분석하고 개선사항을 도출해야 한다.
- 복구 목표 충족 여부.
- 계획에 정의되지 않은 절차.
- 연락 및 보고체계의 문제.
- 복구에 필요한 자원의 부족.
- 기술적 장애와 설정 오류.
- 외부 공급업체와의 협조 문제.
- 복구 담당자의 교육 필요사항.
발견된 문제는 개선조치로 관리하고 비상계획에 반영해야 한다.
비상계획은 최초 작성 이후에도 지속적으로 관리해야 한다.
특히 시스템과 조직의 변경사항이 계획에 반영되지 않으면 실제 장애 상황에서 계획을 실행하기 어려울 수 있다.
다음과 같은 변경이 발생하면 비상계획에 미치는 영향을 검토해야 한다.
- 시스템 신규 도입 또는 폐기.
- 서버와 저장장치 교체.
- 네트워크 구성 변경.
- 데이터베이스 및 애플리케이션 변경.
- 업무 프로세스 변경.
- 복구 담당자 변경.
- 외부 공급업체 변경.
- 대체 사이트 변경.
- 복구 목표 변경.
중요한 변경은 BIA와 복구 전략의 재검토가 필요할 수 있다.
비상계획에는 시스템 구성도, 담당자 연락처, 복구 절차 및 중요 자원 정보 등이 포함될 수 있다.
따라서 계획 문서 자체도 적절하게 보호해야 한다.
- 문서 접근 권한 관리.
- 개정 이력 기록.
- 승인된 최신본 관리.
- 재해 상황에서도 접근할 수 있는 사본 확보.
- 오래된 계획 문서의 관리.
- 복구 담당자에게 최신 계획 배포.
비상계획이 장애가 발생한 시스템 내부에만 보관되어 있다면 실제 장애 상황에서 접근할 수 없을 수 있다.
따라서 계획의 가용성과 기밀성을 함께 고려해야 한다.
NIST SP 800-34 Rev. 1은 정보시스템의 유형에 따라 복구 전략과 절차가 달라질 수 있음을 설명한다.
주요 대상은 클라이언트·서버 시스템, 통신 시스템, 메인프레임 시스템 등이다.
클라이언트·서버 환경에서는 여러 구성요소 사이의 의존관계를 고려해야 한다.
- 애플리케이션 서버.
- 데이터베이스 서버.
- 인증 서버.
- 저장장치.
- 네트워크 장비.
- 사용자 단말.
복구 절차에서는 각 구성요소의 복구 순서와 연결 상태를 확인해야 한다.
통신 시스템은 조직의 다른 정보시스템이 정상적으로 작동하기 위한 기반을 제공한다.
통신 장애는 여러 업무시스템에 동시에 영향을 미칠 수 있다.
따라서 대체 통신회선, 네트워크 장비 확보, 통신사업자와의 협력 및 복구 절차를 고려해야 한다.
메인프레임 시스템은 대규모 업무처리와 중앙 집중식 정보처리에 활용된다.
복구 계획에서는 장비의 특수성, 대체 처리시설, 데이터 복원, 운영 소프트웨어 및 관련 인력의 확보 가능성을 고려해야 한다.
SP 800-34 Rev. 1은 2010년에 발행된 지침이므로 현대적인 클라우드 및 컨테이너 환경의 모든 기술적 특성을 직접 다루지는 않는다.
다만 BIA, RTO, RPO, 복구 우선순위, 대체 자원 확보, 복구 시험 등의 기본 원칙은 이러한 환경에도 적용할 수 있다.
예를 들어 클라우드 환경에서는 다음 사항을 추가로 검토할 수 있다.
- 클라우드 서비스 제공자와 이용자의 복구 책임.
- 가용 영역 및 리전 장애에 대한 대응.
- 데이터 백업과 복제 위치.
- 클라우드 계정 및 인증 서비스의 가용성.
- 암호키와 비밀정보의 복구.
- 서비스 복구에 필요한 네트워크 및 DNS 설정.
- 클라우드 제공자의 장애 복구 목표와 조직의 RTO 사이의 차이.
이는 SP 800-34의 일반 원칙을 현대적인 시스템 환경에 적용할 때 고려할 수 있는 사항으로, 2010년 원문에 모든 항목이 직접 규정되어 있다는 의미는 아니다.
NIST SP 800-34는 정보시스템 비상계획을 수립하고 유지하기 위한 절차와 구현 지침을 제공한다.
반면 NIST SP 800-53은 정보시스템과 조직의 보안 및 개인정보 보호 통제 카탈로그를 제공한다.
SP 800-53의 비상계획(Contingency Planning, CP) 통제군은 비상계획과 관련된 주요 통제를 정의한다.[3]
| 통제 | 영문 명칭 | 주요 내용 |
|---|---|---|
| CP-2 | Contingency Plan | 비상계획 수립 및 관리 |
| CP-3 | Contingency Training | 비상계획 관련 교육 |
| CP-4 | Contingency Plan Testing | 비상계획 시험 |
| CP-6 | Alternate Storage Site | 대체 저장시설 |
| CP-7 | Alternate Processing Site | 대체 처리시설 |
| CP-8 | Telecommunications Services | 통신 서비스의 비상 대응 |
| CP-9 | System Backup | 시스템 백업 |
| CP-10 | System Recovery and Reconstitution | 시스템 복구 및 재구성 |
두 문서는 상호 보완적으로 활용할 수 있다.
- SP 800-53: 어떤 비상계획 관련 통제를 구현해야 하는지 정의.
- SP 800-34: 비상계획을 어떻게 수립하고 복구 전략을 어떻게 개발할지 설명.
- SP 800-53A: 선정된 통제가 적절하게 구현되고 작동하는지 평가하는 절차 제공.
SP 800-34를 참고하여 비상계획을 수립했다고 해서 SP 800-53의 모든 관련 통제를 자동으로 충족하는 것은 아니다.
실제 통제 충족 여부는 적용 요구사항과 구현 상태를 기준으로 평가해야 한다.
NIST SP 800-34는 정보시스템 비상계획을 시스템 개발 생명주기(System Development Life Cycle, SDLC)와 위험관리 활동에 통합하도록 안내한다.
비상계획은 시스템 운영 이후에만 수행하는 활동이 아니다.
시스템의 설계와 개발 단계부터 가용성 요구사항과 복구 전략을 고려해야 한다.
| 시스템 생명주기 단계 | 비상계획 관련 활동 |
|---|---|
| 착수 | 업무 영향 분석과 비상계획 요구사항 식별 |
| 개발 및 획득 | 복구 전략과 필요한 시스템 기능 검토 |
| 구현 및 평가 | 비상계획 작성과 복구 기능 검증 |
| 운영 및 유지보수 | 시험·교육·훈련과 계획 유지관리 |
| 폐기 | 시스템 폐기 및 전환 과정에서 필요한 업무 연속성 확보 |
NIST SP 800-37은 정보시스템과 조직의 위험관리 프레임워크(RMF)를 정의한다.[4]
SP 800-34 Rev. 1의 본문에는 당시의 RMF 절차가 반영되어 있다.
현재 SP 800-37 Rev. 2의 RMF는 준비, 분류, 선정, 구현, 평가, 인가, 모니터링의 7단계로 구성된다.
따라서 SP 800-34에 제시된 비상계획 7단계와 현행 RMF 7단계를 혼동해서는 안 된다.
FIPS 199는 정보 및 정보시스템의 기밀성, 무결성, 가용성에 대한 잠재적 영향을 낮음(Low), 중간(Moderate), 높음(High)으로 분류하는 기준을 제공한다.[5]
SP 800-34는 특히 가용성에 대한 영향 수준을 BIA의 기초 자료로 활용한다.
| 영향 수준 | 의미 | 비상계획 고려사항 |
|---|---|---|
| 낮음 | 시스템 중단이 제한적인 부정적 영향을 미치는 수준 | 상대적으로 긴 복구 시간과 단순한 복구 전략을 허용할 수 있음 |
| 중간 | 시스템 중단이 심각한 부정적 영향을 미치는 수준 | 업무 영향에 적합한 복구 자원과 절차 확보 필요 |
| 높음 | 시스템 중단이 중대하거나 치명적인 영향을 미치는 수준 | 높은 가용성과 신속한 복구를 위한 강화된 전략 검토 |
다만 FIPS 199의 영향 수준만으로 RTO와 RPO가 자동으로 결정되지는 않는다.
구체적인 복구 목표는 업무 영향 분석을 통해 결정해야 한다.
| 문서 | 주요 목적 | SP 800-34와의 차이 |
|---|---|---|
| NIST SP 800-34 | 정보시스템 비상계획 수립 | 업무 영향 분석과 복구 전략, 비상계획의 개발·시험·유지관리 |
| NIST SP 800-37 | 위험관리 프레임워크 | 조직과 정보시스템의 보안·개인정보 보호 위험관리 절차 |
| NIST SP 800-53 | 보안 및 개인정보 보호 통제 | 비상계획을 포함한 다양한 보안 통제의 요구사항 |
| NIST SP 800-61 | 사이버보안 사고 대응 | 사이버보안 사고의 준비·탐지·대응 및 복구 활동 |
| NIST SP 800-184 | 사이버보안 사건 복구 | 사이버보안 사건 이후의 복구 계획과 실행에 관한 지침 |
사고 대응은 사이버보안 사고를 식별하고 피해를 제한하며 침해 원인을 제거하는 활동에 초점을 둔다.
정보시스템 비상계획은 사고의 원인과 관계없이 시스템과 업무의 복구를 준비하는 활동이다.
예를 들어 랜섬웨어 공격이 발생하면 사고 대응 절차에 따라 공격자의 활동을 차단하고 침해 범위를 분석할 수 있다.
동시에 정보시스템 비상계획에 따라 백업 데이터와 대체 환경을 활용하여 업무를 복구할 수 있다.
두 활동은 서로 다른 목적을 가지지만 실제 사건에서는 함께 수행될 수 있다.
재해 복구는 정보시스템 비상계획의 중요한 구성요소이지만, SP 800-34의 범위는 재해 복구보다 넓다.
SP 800-34는 장애 발생 이후의 복구뿐 아니라 장애 예방, BIA, 복구 전략, 교육, 시험 및 유지관리까지 다룬다.
NIST SP 800-34 Rev. 1의 본문은 다음과 같이 구성된다.
| 구분 | 영문 제목 | 주요 내용 |
|---|---|---|
| 제1장 | Introduction | 지침의 목적, 범위 및 배경 |
| 제2장 | Background | 비상계획의 기본 개념과 관련 계획의 관계 |
| 제3장 | Information System Contingency Planning Process | 비상계획 수립의 7단계 절차 |
| 제4장 | Information System Contingency Plan Development | 정보시스템 비상계획의 구체적인 구성과 개발 |
| 제5장 | Technical Contingency Planning Considerations | 시스템 유형별 기술적 고려사항 |
본문 외에도 비상계획과 업무 영향 분석을 위한 서식, 관련 참고자료 및 부록을 제공한다.
NIST CSRC의 공식 발행 페이지에서는 다음과 같은 보충 자료를 제공한다.[2]
- 업무 영향 분석(BIA) 서식.
- 낮은 영향 수준 정보시스템의 비상계획 서식.
- 중간 영향 수준 정보시스템의 비상계획 서식.
- 높은 영향 수준 정보시스템의 비상계획 서식.
이러한 서식은 조직이 비상계획을 작성할 때 참고할 수 있는 자료이다.
서식을 작성하는 것만으로 계획의 실행 가능성이 보장되는 것은 아니므로 시스템 환경과 실제 복구 요구사항에 맞게 내용을 구체화해야 한다.
| 시기 | 판본 | 주요 내용 |
|---|---|---|
| 2002년 6월 | 최초 발행 | Contingency Planning Guide for Information Technology Systems 발행 |
| 2010년 5월 | Revision 1 | Contingency Planning Guide for Federal Information Systems로 개정 |
| 2010년 11월 11일 | Revision 1 수정본 | 기존 Rev. 1의 수정사항 반영 |
최초 발행본은 2002년 6월에 발표되었으며, 2010년 5월 31일 철회되고 Revision 1로 대체되었다.[6]
Revision 1에서는 정보시스템 비상계획과 조직의 업무 연속성, 위험관리 및 시스템 개발 생명주기의 관계를 보다 체계적으로 설명하였다.
2010년 11월 11일에는 Revision 1의 수정본이 발표되었다.
2026년 10월 25일 기준 NIST CSRC에서 확인되는 최종 발행본은 이 수정본이다.
NIST SP 800-34를 활용할 때는 다음 사항을 구분해야 한다.
- 업무 연속성 계획과 정보시스템 비상계획.
- 재해 복구 계획과 개별 시스템의 복구 절차.
- 최대 허용 중단 시간(MTD)과 복구 시간 목표(RTO).
- 복구 시간 목표(RTO)와 복구 시점 목표(RPO).
- 예방 통제와 복구 전략.
- 백업 데이터의 존재와 실제 복원 가능성.
- 대체 시설의 확보와 실제 운영 전환 가능성.
- 기술적 시스템 복구와 업무 프로세스의 정상화.
- 계획 문서의 작성과 시험·훈련을 통한 실효성 검증.
비상계획은 단순한 문서 작성 활동이 아니라 조직이 장애 상황에서 정보시스템과 핵심 업무를 복구할 수 있도록 준비하는 지속적인 관리 활동이다.
특히 BIA를 통해 복구 목표를 설정하고, 목표에 맞는 복구 전략을 선정하며, 실제 시험으로 그 효과를 검증하는 과정이 중요하다.
또한 SP 800-34 Rev. 1은 2010년에 발행된 문서이므로, 현재의 클라우드 환경과 사이버보안 위협에 적용할 때는 관련 최신 NIST 지침과 조직의 기술 환경을 함께 고려해야 한다.
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 Marianne Swanson 외, Contingency Planning Guide for Federal Information Systems, NIST SP 800-34 Revision 1, 2010-05, 2010-11-11 수정.
- ↑ 2.0 2.1 NIST Computer Security Resource Center, SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, 확인: 2026-10-25.
- ↑ Joint Task Force, Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Revision 5, 2020-09, 2020-12-10 수정.
- ↑ Joint Task Force, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, NIST SP 800-37 Revision 2, 2018-12.
- ↑ NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, 2004-02.
- ↑ NIST Computer Security Resource Center, SP 800-34, Contingency Planning Guide for Information Technology Systems, 확인: 2026-10-25.