정보시스템 수명 주기
더 많은 작업
- System Life Cycle; 시스템 수명 주기, 시스템 생명주기
- 시스템이 구상되어 요구사항 정의, 설계, 구현, 통합, 검증, 배포, 운영, 폐기에 이르기까지 거치는 전체 과정과, 각 단계에 보안 활동을 처음부터 끝까지 넣는 관리 방식
정보시스템 수명 주기는 소프트웨어 하나가 아니라 하드웨어, 소프트웨어, 데이터, 사람, 절차, 시설을 묶은 시스템 전체의 일생을 다룬다. 기준이 되는 국제 표준은 시스템 공학 프로세스를 정의한 ISO/IEC/IEEE 15288(시스템 수명 주기 프로세스)이고, 미국 NIST는 이 표준의 프로세스마다 보안 관점의 목적과 활동을 붙여 SP 800-160 Vol.1 Rev.1(신뢰할 수 있는 안전한 시스템 공학, 2022년 11월)으로 정리했다.
핵심 생각은 단순하다. 보안 요구사항은 다른 공학 요구사항과 같은 무게로 처음부터 정의하고 관리해야 하며, 다 만든 뒤에 덧붙일 수 없다. 나중에 붙인 보안은 비용이 크고 구멍이 남는다. 그래서 CISSP 출제 개요 3.10은 수명 주기의 각 단계를 하나씩 나열하고, 각 단계에서 보안 담당자가 무엇을 해야 하는지 묻는다.
SP 800-160 Vol.1 Rev.1은 ISO/IEC/IEEE 15288을 따라 수명 주기 프로세스를 네 묶음으로 나눈다.
| 묶음 | 포함 프로세스(예) | 보안 관점 |
|---|---|---|
| 합의 프로세스(Agreement) | 획득(acquisition), 공급(supply) | 계약·조달에 보안 요구를 넣는다. 공급망 위험 관리와 이어진다. |
| 조직 프로젝트 지원 프로세스(Organizational Project-Enabling) | 수명 주기 모델 관리, 기반 시설 관리, 포트폴리오 관리, 인적 자원 관리, 품질 관리, 지식 관리 | 개발 환경·인력·품질 체계에 보안을 넣는다. |
| 기술 관리 프로세스(Technical Management) | 프로젝트 계획, 평가와 통제, 의사결정 관리, 위험 관리, 형상 관리, 정보 관리, 측정, 품질 보증 | 보안 위험과 보안 형상 기준선을 관리한다. |
| 기술 프로세스(Technical) | 사업·임무 분석부터 폐기까지 14개 | 아래 단계별 표의 대상이다. |
SP 800-160의 기술 프로세스는 사업·임무 분석(Business or Mission Analysis), 이해관계자 요구 및 요구사항 정의, 시스템 요구사항 정의, 시스템 아키텍처 정의, 설계 정의, 시스템 분석, 구현, 통합, 검증, 전환, 확인, 운영, 유지보수, 폐기의 14개이다. CISSP 개요는 이것을 9개 항목으로 묶어 제시한다.
| 단계(CISSP 3.10) | 대응 프로세스(SP 800-160) | 주요 보안 활동 | 산출물(예) |
|---|---|---|---|
| 이해관계자 요구와 요구사항(Stakeholder needs and requirements) | 사업·임무 분석, 이해관계자 요구 및 요구사항 정의 | 보호해야 할 자산과 손실 시 영향을 식별하고, 이해관계자의 보호 요구(protection needs)를 끌어낸다. 법·규제·계약 의무를 확인한다. | 보호 요구, 이해관계자 보안 요구사항, 운영 개념 |
| 요구사항 분석(Requirements analysis) | 시스템 요구사항 정의, 시스템 분석 | 보호 요구를 검증 가능한 시스템 보안 요구사항으로 바꾸고, 기능·성능 요구와의 충돌을 조정한다. 위협 모델링과 오용 사례로 빠진 요구를 찾는다. | 보안 요구사항 명세, 추적성 매트릭스 |
| 아키텍처 설계(Architectural design) | 시스템 아키텍처 정의, 설계 정의 | 보안 설계 원칙(최소 권한, 심층 방어, 실패 시 안전 등)을 적용해 보안 경계, 신뢰 영역, 보안 기능 배치를 정한다. 설계 대안을 위험 기준으로 비교한다. | 보안 아키텍처, 인터페이스 정의, 설계 검토 결과 |
| 개발·구현(Development/implementation) | 구현 | 시큐어 코딩, 검증된 구성 요소·라이브러리 사용, 하드웨어·소프트웨어 출처 확인, 개발 환경 보호를 수행한다. | 코드, 구성 요소, 보안 구성 문서 |
| 통합(Integration) | 통합 | 구성 요소를 합칠 때 인터페이스와 신뢰 관계가 설계대로인지 확인하고, 통합 과정에서 생기는 새로운 공격 경로를 점검한다. | 통합 시험 결과, 인터페이스 보안 확인 |
| 검증과 확인(Verification and validation) | 검증, 확인 | 보안 요구사항 충족 여부를 시험·분석·검사로 입증하고(검증), 실제 운영 환경에서 이해관계자의 보호 요구를 만족하는지 확인한다(확인). 취약점 평가와 모의 침투도 이 단계에 들어간다. | 시험 보고서, 보증 근거(assurance evidence) |
| 전환·배포(Transition/deployment) | 전환 | 안전한 설치와 초기 구성, 운영자·사용자 보안 교육, 시설 변경, 운영 승인(인가)에 필요한 근거를 갖춘다. | 배포 계획, 운영 인가, 보안 구성 기준선 |
| 운영과 유지보수(Operations and maintenance/sustainment) | 운영, 유지보수 | 지속적 모니터링, 패치·변경 관리, 사고 대응, 주기적 재평가로 보안 상태를 유지한다. 유지보수 작업이 보안 기능을 약화하지 않는지 확인한다. | 모니터링 기록, 변경 기록, 재평가 결과 |
| 폐기(Retirement/disposal) | 폐기 | 데이터를 이관하거나 완전 삭제하고, 키·자격 증명·계정을 폐기하며, 매체를 데이터 잔존이 없도록 처리한다. 대체 시스템으로 넘어가는 동안의 보안 공백도 관리한다. | 폐기 기록, 매체 삭제 확인서 |
같은 시스템이라도 각 프로세스는 한 번만 실행되는 것이 아니다. SP 800-160은 프로세스를 순서대로 한 번씩 거치는 방식에 묶지 않으며, 반복형·점진형 개발에서도 같은 프로세스가 여러 번 겹쳐 수행된다고 본다. 예를 들어 운영 중 변경이 생기면 요구사항 분석, 설계, 검증이 다시 일어난다.
검증(verification)과 확인(validation)은 우리말로도 영어로도 헷갈리기 쉬워 시험에 자주 나온다. 둘 다 객관적 증거로 무언가를 입증한다는 점은 같지만 기준이 다르다.
| 구분 | 검증(Verification) | 확인(Validation) |
|---|---|---|
| 질문 | 제대로 만들었는가(built right) | 맞는 것을 만들었는가(right system) |
| SP 800-160 정의 | 객관적 증거를 통해 명시된 요구사항이 충족되었음을 확인하는 것 | 객관적 증거를 통해 특정한 의도된 용도나 적용을 위한 요구사항이 충족되었음을 확인하는 것 |
| 비교 대상 | 요구사항 명세, 설계 기술서 | 이해관계자의 요구, 실제 운영 환경 |
| 주요 방법 | 검사, 분석, 시연, 시험(단위·통합·시스템 시험), 코드 검토 | 인수 시험, 운영 환경 시범 운영, 사용자 평가 |
| 놓치는 것 | 요구사항 자체가 틀렸으면 통과해도 쓸모없다 | 세부 명세 위반을 놓칠 수 있다 |
보안으로 옮기면, 검증은 "명세에 적힌 암호화·접근통제·로그 기능이 명세대로 동작하는가"를, 확인은 "그 보안 기능들로 실제로 이해관계자가 걱정한 손실이 막히는가"를 본다. 요구사항 단계에서 보호 요구를 잘못 잡으면 검증은 모두 통과하고도 확인에서 실패한다. 관련 개념은 확인과 검증, V 모델 문서도 참고한다.
| 구분 | 시스템 수명 주기(SLC) | 소프트웨어 개발 수명 주기(SDLC) |
|---|---|---|
| 대상 | 하드웨어, 소프트웨어, 데이터, 사람, 절차, 시설을 포함한 시스템 전체 | 소프트웨어 제품 |
| 범위 | 구상부터 운영·유지보수·폐기까지 | 주로 요구사항부터 배포·유지보수까지(조직에 따라 폐기 포함) |
| 기준 표준 | ISO/IEC/IEEE 15288, NIST SP 800-160 Vol.1 | ISO/IEC/IEEE 12207, NIST SP 800-218(SSDF) 등 |
| CISSP 영역 | 3.10(보안 아키텍처 및 엔지니어링) | 8.1(소프트웨어 개발 보안) |
소프트웨어 개발 생명주기는 시스템 수명 주기 안에서 소프트웨어 구성 요소를 만드는 부분 과정으로 보면 된다. Secure SDLC가 소프트웨어에 보안을 넣는 방법이라면, 시스템 수명 주기 관리는 그 소프트웨어를 품은 시스템 전체, 특히 운영과 폐기까지 보안 책임을 이어 가는 방법이다. NIST의 위험 관리 프레임워크(SP 800-37)도 준비, 분류, 선택, 구현, 평가, 인가, 모니터링 단계를 수명 주기 각 시점에 맞물리게 설계되어 있다.
- 보안은 수명 주기 가장 처음(이해관계자 요구 정의)부터 넣는다. "언제 보안을 고려해야 하는가"를 물으면 요구사항·착수 단계를 고른다. 흔한 오답: 테스트 단계, 배포 직전.
- 검증은 "명세대로 만들었나(built right)", 확인은 "맞는 것을 만들었나(right system)"이다. 인수 시험·운영 환경 평가는 확인 쪽이다.
- 운영 중 변경도 수명 주기 활동이다. 변경이 생기면 변경 관리를 거쳐 보안 영향 분석과 재검증을 한다.
- 폐기 단계의 핵심은 데이터 이관·완전 삭제, 키와 계정 폐기, 매체 처리 기록이다. 폐기를 빠뜨리면 데이터 잔존과 잊힌 계정이 남는다.
- 시스템 수명 주기는 SDLC보다 넓다. 시설·사람·절차·폐기까지 포함한다.