우주_보안모델_해설서_및_사례집.md

# 우주 보안모델 해설서 및 사례집.pdf

> Converted: 2026-04-02 01:24
> OCR Engine: PaddleOCR (Korean + GPU)


---
<!-- Page 1 -->
우주
해설
및
적용사례집
2025
12
과학기술정보통신부
한국인터넷진흥원
KIsA
Ministry of Science and ICT

---
<!-- Page 2 -->
1 	 배경 및 목적 .....................................................................6
2 	 범위 및 구성 .....................................................................8
3 	 우주 보안 컴플라이언스 및 가이드라인 .....................................9

가. 컴플라이언스 ............................................................... 10

나. 가이드라인 .................................................................. 15
1 	 우주 보안모델 ................................................................. 26

가. GSaaS 아키텍처 ........................................................... 30

나. 우주 공급망 아키텍처 ...................................................... 31
2	 우주 보안 체크리스트 ........................................................ 32


## 제1장    ◆ 개요


## 제2장    ◆ 우주 보안모델

CONTENTS

---
<!-- Page 3 -->
1 	 A우주기업 아키텍처 구성요소 ............................................ 204
2 	 A우주기업 보안취약점 점검 절차 ........................................ 206
3 	 A우주기업 주요 보안 요구사항 ........................................... 207
4 	 보안모델 적용을 통한 기대효과 .......................................... 212
1 	 접근통제(AC)................................................................... 38
2 	 식별 및 인증(IA)............................................................... 69
3 	 시스템 및 통신 보안(SC) .................................................... 78
4 	 시스템 및 정보 무결성(SI) .................................................. 99
5 	 시스템/서비스 운영관리(SO)............................................. 111
6 	 사고 대응(IR) ................................................................ 138
7 	 인원 보안(PS) ............................................................... 150
8 	 물리보안(PE) ................................................................ 157
9 	 위험평가 및 보안 평가(RA) ............................................... 168
10 	보안 거버넌스(SG).......................................................... 175
11 	비상 계획(CP)................................................................ 187
12 	공급망 관리(SM)............................................................ 193

## 제4장    ◆ 우주 보안모델 적용 사례


## 제3장    ◆ 우주 보안모델 해설


---
<!-- Page 4 -->


---
<!-- Page 5 -->
개요

## 1. 배경 및 목적


## 2. 범위 및 구성


## 3. 우주 보안 컴플라이언스 및 가이드라인

제 1 장

---
<!-- Page 6 -->
6 | 우주 보안 모델 해설 및 적용사례집
민간 우주기업이 우주산업을 직접 이끌어 우주 생태계가 조성되는 뉴스페이스 시대가 도래함에
따라 소형위성 대량 생산, 위성 발사 비용 급감, 위성 데이터 서비스의 활성화 등으로 우주
생태계가 다변화되고 있다.
이에 따라 세계 각국의 정부와 민간기업에서는 우주산업 시대의 유리한 고지를 선점하기 위해
부단한 노력을 기울이고 있는 중이며, 우주 강국 미국은 우주 내 서비스, 조립 및 생산에 대한 국가
전략을 마련하여, 글로벌 우주 시장의 주도권을 지속 확보하고자 노력하고 있다. 유럽연합에서도
전략적 자주성 확보, 우주 안전 및 방위 역량 강화, 산업 경쟁력 지원 등을 핵심축으로 우주 산업
전략을 마련하고 거버넌스와 대규모 투자로 이를 실행하는 중이다. 일본에서는 우주전략기금을
운영하여, 민간 기업, 대학, 연구기관 등을 대상으로 우주 분야 기술 개발 및 사업화를 장기적으로
지원하려고 계획하고 있다. 국내 역시 이러한 글로벌 흐름에 발맞춰 정부차원의 민간주도
우주산업 생태계조성을 위한 지원 강화 계획을 마련하여 민간 우주기업 생태계 조성을 위한
노력을 기울이고 있다.
우주 산업의 성장으로 통신, 방송, 물류, 금융, 해양, 기상 등 다양한 산업에서 위성 데이터와
서비스 활용도가 높아짐에 따라, 기업 경쟁력과 사용자 신뢰성을 유지하기 위해 우주보안의
필요성이 대두 되었다. 우주 인프라에 대한 사이버 공격이나 재밍 등은 단 한 번의 사고로도
막대한 경제적, 사회적 손실을 초래할 수 있기 때문이다.

## 제1장

개요
제1절
배경 및 목적

---
<!-- Page 7 -->

## 제1장 개 요  | 7

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
또한, 우주 산업에 참여하는 공급업체와 파트너가 매우 다양하여 위성 및 지상국 인프라에
대해 다양한 보안 위협이 발생할 수 있다. 즉, 위성 설계/개발, 준비/조립, 발사, 운영, 폐기에
이르는 위성 생애주기 전 과정이 공급망 체계로 구성되어 있으며, 각 단계에서 부품/소프트웨어
위변조, 정보 유출, 사이버 공격 등의 많은 보안 위협이 현실화되고 있는 실정이다. 이는 우주
자산이 고가치로 평가되어 사이버보안 위협 목표가 되기에 충분하기 때문이며 국내 기업의 경쟁력
확보를 위해 우주 공급망 보안도 중요한 요소로 부각되고 있다. 따라서 우주기업은 단위 시스템을
보호하는 수준을 넘어, 위성, 지상국, 사용자 영역의 우주 환경 전반과 우주 공급망 전 단계에서
우주보안 체계를 구축해야 한다.
본 문서는 우주 보안모델(GSaaS1 우주 공급망)에서 기술한 우주보안 체크리스트를 설명하고
각 항목별로 구체적인 보안대책을 제시한다. 이를 통해 우주기업 보안담당자가 해당 우주기업의
보안현황을 점검하여, 도출된 보안문제점을 조치하기 위한 방안을 수립하고 우주 보안모델을 보다
잘 적용할 수 있도록 지원하는데 있다.
1 ‌GSaaS(Ground Station as a Service) : 클라우드 기반의 지상국 서비스로 클라우드를 활용한 Ground Segment를 이용
하여 데이터를 수신하고 명령을 전송하는 기술

---
<!-- Page 8 -->
8 | 우주 보안 모델 해설 및 적용사례집
제2절
범위 및 구성
본 문서는 우주 보안모델(GSaaS, 우주 공급망)에서 제시한 우주 보안 체크리스트 12개 분야,
53개 항목에 대한 구체적인 해설 및 보호대책을 기술한다.
본 문서는 네 부분으로 구성되어 있다.

## 1장에서는 우주 보안모델 해설서 개발 배경을 소개하고 범위와 구성, 그리고 우주 보안

컴플라이언스 및 가이드라인을 소개한다.

## 2장에서는 우주 보안모델(GSaaS, 우주 공급망) 보고서에서 제시한 GSaaS, 우주 공급망

아키텍처를 소개하고 우주보안 체크리스트를 설명한다.

## 3장에서는 우주보안 체크리스트 12개 분야, 53개 항목별로 목적, 확인사항, 보호대책을

제시한다.

## 4장에서는 보안 취약점 점검을 수행한 우주기업 3곳 중 1곳에 대해 우주 보안 취약점 점검 및

조치 사례를 설명하고 보안컨설팅 성과를 도출한다.

---
<!-- Page 9 -->

## 제1장 개 요  | 9

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제3절
우주 보안 컴플라이언스 및 가이드라인
최근 전 세계적으로 우주 산업은 국가 중심의 사업 구조를 벗어나 민간 기업 주도의 New
Space 시대로 빠르게 전환되고 있다. 지상국 서비스, 위성 발사 서비스, 위성 관리 서비스,
발사체 개발 등 다양한 영역에서 민간의 참여가 확대되면서 산업 성장 기회가 열리고 있으나, 우주
시스템을 겨냥한 사이버 공격도 지속해서 증가하고 있다. 특히 지상 인프라, 우주 부문, 사용자
단말이 모두 연결되어 있어 한 요소의 침해가 전체 서비스로 이어질 위험이 높다.
우주 자산을 대상으로 한 보안 위협이 고도화됨에 따라 각국 정부와 국제기관은 우주 분야에
적용되는 규제와 보안 요구사항을 강화하고 있다. 우주기업에게 보안 준수는 단순 관리 문제가
아니라 사업 참여 조건이 되고 있다. 예를 들어, 국제 규제, 공급망 계약, 사고 보고의무 등은
기업이 글로벌 시장에서 경쟁하고 고객·정부 기관과 협력하기 위해 반드시 충족해야 한다. 이에
따라 계약 기반의 보안책임, 표준 준수에 대한 증빙 요구 등 법적·계약적 준수의 중요성이 더욱
강조되고 있다.
이와 같은 상황 속에서 미국, 유럽, 한국을 포함한 주요 국가들은 아래와 같이 우주 분야에 대한
보안 규제를 시행하고, 표준을 배포하고 있다.
표 1
우주 보안 컴플라이언스 및 가이드라인
구분
문서명
주요 내용
컴플라이언스
EU NIS2 Directive
 우주를 포함한 필수 서비스 사업자의 사이버 위험관리와 사고
보고의무를 강화하는 EU 법적 규제 프레임워크로, 조직적·관리적
보안통제를 요구
CMMC2
(사이버보안 성숙도
모델 인증)
 미 국방부 공급망 기업의 보안 성숙도 수준을 인증하기 위한
모델로, 관리적 통제·문서화·공급망 보안 기준을 제시
가이드라인
NIST IR 84013
 위성 지상국의 TT&C4 보호를 위한 기술 보안 지침으로, 사이버보안
프레임워크 기반 식별·보호·탐지·대응·복구 통제를 제시
NIST IR 82705
 상업 위성 운영 전 주기에 걸친 위험 기반 보안 관리 원칙을
제시하며, 운영·개발·배치 단계별 위협 대응 방법을 설명
ENISA6 Space
Threat Landscape
 우주 시스템을 대상으로 하는 위협 행위자·공격 시나리오·자산
분석을 제공하여 위협 기반 보안 설계를 지원

---
<!-- Page 10 -->
10 | 우주 보안 모델 해설 및 적용사례집
구분
문서명
주요 내용
가이드라인
민간 우주 시스템
사이버보안 대책
가이드라인
 일본 민간 우주기업이 표준 모델과 위협 시나리오를 기반으로
시스템의 위헙을 식별하고, 보안 대책을 체계적으로 수립하도록
지원
미국은 NIST 8401, NIST 8270 등의 보고서를 통해 위성·지상국 보안 요구사항을 제시하고,
국방부와 계약하는 기업에게 높은 보안 수준을 요구하는 CMMC 인증 체계를 갖추고 있다.
유럽연합(EU)은 NIS2 Directive를 통해 우주 산업을 필수 서비스로 포함하여 법적 규제 체계를
강화했다. 또한, 유럽사이버보안청(ENISA)은 Space Threat Landscape 보고서를 통해 우주
시스템 특화 위협을 정의하고 보안 통제를 권고하며, 일본은 민간 우주 시스템 사이버보안 대책
가이드라인을 통해 민간 우주기업이 보안 거버넌스를 갖추고 우주시스템 특유의 기술적 대책을
수립할 수 있도록 지원한다.
이처럼 민간 기업들이 지상국과 위성 인프라를 제공하는 역할을 맡게 되면서, 보안 체계 마련 및
규정 준수의 중요성이 더욱 커지고 있다.
가. 컴플라이언스
(1) EU NIS2 Directive
NIS2 Directive (Directive (EU) 2022/2555)는 기존 NIS 지침을 개정 및 확대한
유럽연합(EU)의 사이버보안 지침이다. 이 지침의 핵심 목표는 EU 회원국 전반에 걸쳐 네트워크
및 정보시스템에 기반한 필수 서비스들의 복구 능력과 사고 대응 능력을 높은 공통 수준으로
향상시키는 것이다.
2 ‌CMMC (Cybersecurity Maturity Model Certification) : 사이버보안 성숙도 모델 인증
3 ‌NIST IR 8401 (Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and
Control)
4 ‌TT&C (추적 · 원격측정 및 지령, Telemetry And Command) : 위성 통신에서 위성의 추적(궤도 위치 정보의 파악), 원격
측정(위성의 감시) 및 위성에 대한 지령(위성 상태의 변경 제어)을 실행하는 것. 또는 그것들을 실행하는 지상의 국(출처 :
정보통신용어사전)
5 ‌NIST IR 8270 (Introduction to Cybersecurity for Commercial Satellite Operations)
6 ‌ENISA (European Union Agency for Cybersecurity) : 유럽사이버보안청

---
<!-- Page 11 -->

## 제1장 개 요  | 11

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
NIS2는 기존의 에너지, 교통, 금융, 보건, 디지털 인프라 등 전통적 핵심 인프라 영역에 더해
우주 부문을 포함하여 적용 범위를 크게 확장했다. 지침은 “우주 기반 서비스 제공자, 지상 인프라
운영자, 위성 관제 및 지상국 운영자, 우주 관련 서비스 및 공급망 참여자” 등을 적용 대상으로
명시하고 있다. 이는 우주 기반 서비스 제공을 지원하는 지상 기반 인프라 운영자를 포함할 수
있으며, GSaaS 제공사의 주 활동 영역인 지상국 운영 또한 해당 인프라에 해당될 수 있다. 모든
우주기업이 자동 적용되지는 않고, 기업 규모(직원 수, 매출 등) 또는 사업의 “중요성/영향력”에
따라 해당될 수 있다.
NIS2에 따라 이들 기관은 사이버 위험 관리 조치 이행 및 단계별 침해사고 보고 등 의무를
준수해야 한다.
NIS2 Directive의 문서 구성은 아래와 같다.
표 2
NIS2 Directive 문서 구성
장
내용
세부 내용
1
일반 조항
제2조 적용범위
제3조 필수적이고 중요한 기관
2
조정된 사이버보안체계
제7조 국가사이버 보안전략
3
유럽연합 및 국제적 차원의 협력
제14조 협력단
제15조 컴퓨터보안사고대응팀연계망
4
사이버보안 위험 관리 조치 및
보고의무
제20조 관리체계
제21조 사이버보안 위험 관리 조치
제23조 보고의무
5
관할권 및 등록
제26조 관할 및 영토성
6
정보 공유
제30조 관련 정보의 자발적 통지
7
감독 및 집행
제32조 필수기관과 관련된 감독 및 집행조치
제36조 벌칙
8
위임입법 및 시행법
제38조 위임권의 행사
9
종결조항
제41조 이행

---
<!-- Page 12 -->
12 | 우주 보안 모델 해설 및 적용사례집
NIS2는 적용 대상 기관에 대해 다음과 같은 구체적인 의무를 부과한다
•경영진 책임 강화
NIS2 Directive는 적용 대상 기관의 경영진이 사이버보안 위험 관리 조치를 승인하고 이행을
감독해야 할 법적 책임을 명시한다. 경영진은 서비스 운영에 미치는 보안 위험을 이해하고 평가할
수 있도록 정기 교육을 이수해야 하며, 최소 연 1회 이상 보안정책을 검토·갱신해야 한다. 기관
내에는 보안책임을 경영진에게 직접 보고하는 담당자를 지정해야 하며 경영진은 정기적인 보고를
통해 보안 상태를 확인해야 한다.
•위험 기반 사이버보안 조치 이행 의무
기관은 서비스 제공에 사용되는 네트워크 및 정보시스템의 위험을 관리하고 사고 영향을
최소화하기 위한 기술적·운영적·조직적 조치를 의무적으로 수행해야 한다. 유럽연합
집행위원회는 이를 구체화하기 위해 이행규정을 채택하고 있으며, 기관의 위험 관리 체계 확립 및
지속적 모니터링·로깅·권한 관리 강화 등을 요구한다.
표 3
NIS2 이행규정 구성
이행규정 본문
NIS2 Directive에 따라 발간된 공식 EU 이행규정
부속서에 포함된 기술적·방법론적 요구사항을 적용하고 해석하는 기준을 설명
부속서

## 1. 네트워크 및 정보시스템 보안 정책


## 2. 위험관리 정책


## 3. 사고 대응


## 4. 비즈니스 연속성 및 위기관리


## 5. 공급망 보안 정책


## 6. 네트워크 및 정보 시스템 획득, 개발 및 유지보수에 대한 보안


## 7. 사이버보안 위험관리 조치의 효과를 평가하기 위한 정책 및 절차


## 8. 기본 사이버 위생 관행 및 보안 교육


## 9. 암호화


## 10. 인적 보안


## 11. 접근통제


## 12. 자산 관리


---
<!-- Page 13 -->

## 제1장 개 요  | 13

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
•중대한 사이버 사고 보고의무
기관은 서비스 운영에 중대한 영향을 미치는 사이버 사고가 발생할 경우 컴퓨터 보안사고
대응팀(CSIRT7) 또는 관할 당국에 즉시 보고해야 한다. 보고는 단계별로 24시간 내 초기
보고, 72시간 내 사고 보고 및 초기 영향평가 제출, 1개월 내 최종 보고서를 제출해야 한다.
중대 사고 기준에는 직접 피해 50만 유로 또는 매출 5% 초과, 국민 생명·안전 영향, 광범위한
사회적 피해 등이 포함된다.
•공급망 보안 관리 의무
기관은 공급망을 포함한 외부 서비스 및 제품의 보안 위험을 관리할 책임이 있다. 이를 위해
공급망 보안정책을 수립하고, 공급업체의 보안 관행을 평가할 기준을 마련해야 한다. 계약에는
사고 통보 의무, 감사 권한, 직원 검증 및 교육 요구사항 등이 포함되어야 하며, 공급망 위험 관리
계획은 연 1회 이상 또는 사고 발생 시 업데이트 되어야한다.
(2) CMMC
CMMC(사이버보안 성숙도 모델 인증)는 미국 국방부(DoD8)가 국방 산업 공급망 전반의 보안
수준을 검증하기 위해 도입한 사이버보안 인증 체계이다. CMMC의 주된 목적은 계약업체 및
하도급업체가 DoD와의 계약 이행 과정에서 처리, 저장 또는 전송하는 연방계약정보(FCI9)와
통제된 비기밀 정보(CUI10)를 보호했음을 확인하는 것이다. 이를 통해 공급망 기업 전반에 걸쳐
높은 수준의 사이버보안을 달성하기 위한 것이다.
•‌연방계약정보(FCI): 기업이 정부로부터 제공받거나 계약 수행 중 생성한 정보 중 일반에
공개될 수 없는 정보
•‌통제된 비기밀 정보(CUI): 법령, 정책, 정부 지침 등에 따라 접근과 배포가 제한되며,
공개되면 국가·공공·기술·산업적 측면에서 위험이 발생할 수 있어 보호가 필요한 민감 정보.
(정부가 직접 보유한 정보뿐 아니라 정부 프로젝트를 수행하는 민간 기업이 생성·관리하는
정보도 포함)
7 ‌CSIRT (Computer Security Incident Response Team) : 컴퓨터 보안사고 대응 팀
8 DoD (United States Department of Defense) : 미국 국방부
9 FCI (Federal Contracting Information) : 연방계약정보
10 CUI (Controlled Unclassified Information) : 통제된 비기밀 정보

---
<!-- Page 14 -->
14 | 우주 보안 모델 해설 및 적용사례집
CMMC는 보안 요구사항의 구현 여부를 평가하고 검증하기 위한 인증 프레임워크로
설계되었으며, 처리되는 정보의 중요도에 따라 요구되는 보안 수준을 3단계로 차등 적용한다.
국방부는 향후 계약 과정에서 CMMC 인증을 입찰 자격 요건으로 단계적으로 적용할 계획이다.
CMMC 인증은 국방부와 신규 계약 또는 하도급 계약을 체결하며 연방계약정보(FCI) 또는
통제된 비기밀 정보(CUI)를 처리하는 모든 공급망 참여 기관에 요구된다. 국방부는 입찰 공고 및
계약 문서에 요구되는 CMMC 인증 레벨을 명시하며, 해당 레벨 충족은 계약 수주를 위한 필수
조건이다. 따라서 요구 레벨은 기업이 처리하는 정보의 민감도와 사업 중요도에 따라 레벨1,
레벨2, 레벨3 중 하나로 지정된다.
연방계약정보(FCI)를 처리하는 기업은 CMMC 레벨1의 15개 기본 보안 요구사항을 준수해야
한다. 통제된 비기밀 정보(CUI)를 다루는 기업은 CMMC 레벨2의 NIST SP 800-17111 기반
110개 보안 요구사항을 이행해야 한다. 더 높은 수준의 국가·군수 전략 자산과 관련된 조직은
레벨3의 134개의 보안 요구사항을 충족해야 한다.
표 4
CMMC 레벨 구분
구분
목적
요구사항
설명
레벨 1
연방계약정보 (FCI) 보호
15개
최소 보호 조치 및 기본 사이버 위생 유지
레벨 2
통제된 비기밀 정보
(CUI) 보호
110개
핵심 레벨, NIST SP 800-171 기반 보안 통제
레벨 3
APT 대응
134개
지능형 지속적 위협(APT) 방어 수준 요구
CMMC는 보안 통제 구현에 대한 평가와 인증 절차를 통해 검증되며, 법적 구속력을 갖는다.
요구된 CMMC 레벨을 충족하거나 인증 상태를 지속하지 못할 경우, 기업은 계약 수주 및 옵션
행사, 계약 기간 연장 등이 제한될 수 있다.
레벨 2는 통제된 비기밀 정보(CUI)의 민감도에 따라 ‘1차: 자체 평가’와 ‘2차: 제3자
평가기관(C3PAO12) 평가’로 나뉘어, 위험도에 따라 상이한 인증 수준을 요구한다. 요구 레벨별
평가 방식은 아래와 같다.
11 ‌NIST SP 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations) :
비연방시스템 환경에서 통제된 비기밀 정보(CUI)를 보호하기 위해 제시된 110개 기술·관리 통제로 구성된 보안 지침
12 ‌C3PAO (CMMC Third-Party Assessment Organization) : 인증받은 제3자 평가기관

---
<!-- Page 15 -->

## 제1장 개 요  | 15

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
표 5
CMMC 요구 레벨별 평가 방식
레벨
평가 방식
주기
설명
레벨 1
자체 평가 +
준수 확인 제출
매년
 연방계약정보(FCI) 처리 조직
 기본 보호 수준으로 문서화·운영 여부 확인
레벨 2
(1차)
자체 평가
3년
 통제된 비기밀 정보(CUI) 처리 기업 (중위험군)
 위험도 중간 수준 통제된 비기밀 정보(CUI) 취급, Self-
Assessment 허용
레벨 2
(2차)
제3자 인증 평가
3년
 국방부 지정 처리 기업
 민감한 통제된 비기밀 정보(CUI) 취급 시 C3PAO 공식 인증
요구
레벨 3
국방부 직접 평가
3년
 고위험·고가치 정보 처리 조직
 APT 방어 수준 요구, 정부 주관 심사
한국의 위성·지상국·발사체·부품·소프트웨어 기업이 미국 우주산업 공급망에 참여하기
위해서는 CMMC 인증이 사실상 필수 조건이다. 특히 부품 및 소프트웨어 납품, 위성 운영 지원,
데이터 처리를 수행하는 기업의 경우 통제된 비기밀 정보(CUI) 취급 가능성이 커 레벨 2 이상의
인증이 필요할 수 있다.
나. 가이드라인
(1) NIST IR 8401 (Satellite Ground Segment Security)
NIST IR 8401은 미국 국립표준기술연구소(NIST)가 발간한 보고서로, 지상국 운영에 NIST
사이버보안 프레임워크(CSF)를 적용하기 위한 지침을 제공한다. 이는 법적 강제성을 가진
규정이나 인증 기준이 아니라, 위험 기반 접근을 지원하는 자율적 보안 프레임워크로서 우주산업
이해관계자가 사이버 위험을 관리할 수 있도록 돕는 것을 목적으로 한다.
보고서의 범위는 상업용 우주 운영의 지상국 영역에 한정되며, 특히 임무 운영 센터(Mission
Operations Center, MOC)와 탑재체 제어 센터(Payload Control Center, PCC)가 수행하는
명령 송신, 원격 측정 데이터 수신, 상태 모니터링 기능 등을 포함한다. 지상국 중심의 실무적
위험관리 지침을 제공하기 위한 목적이므로, 우주 비행체 및 사용자 단말은 범위에 포함되지
않는다.

---
<!-- Page 16 -->
16 | 우주 보안 모델 해설 및 적용사례집
IR 8401은 지상국의 임무 운영및 명령·제어(Command & Control) 기능이 사이버 공격에
노출될 경우, 우주 시스템 전체뿐 아니라 국가 안보와 경제 활동에 심각한 영향을 초래할 수
있다고 강조한다. 이에 따라 지상국에서 발생 가능한 위험을 체계적으로 관리하고, 운영 환경과
이해관계자 간 협업 과정을 기반으로 보안 역량을 강화하는 것이 필수적임을 제시한다.
NIST Cybersecurity Framework(CSF)는 미국 국립표준기술연구소가 산업 전반의
사이버보안 역량 강화를 위해 제시한 위험 기반 보안 프레임워크로, 조직이 사이버보안 위험을
식별·관리·감소하기 위한 체계적 접근 방법을 제공한다. NIST CSF 1.1은 식별(Identify),
보호(Protect), 탐지(Detect), 대응(Respond), 복구(Recover)의 다섯 가지 핵심 기능으로
구성되며, 이는 조직이 전 주기에 걸쳐 보안을 수행할 수 있는 구조를 제공한다.
그림 1
NIST CSF

---
<!-- Page 17 -->

## 제1장 개 요  | 17

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
표 6
NIST CSF 목표
기능
목표
식별
(Identify)
시스템, 자산, 데이터 및 역량에 대한 사이버보안 위험을 관리하기 위해 조직의 이해를 구축
보호
(Protect)
중요 인프라 서비스의 제공을 보장하기 위해 적절한 보호 조치를 개발하고 구현
탐지
(Detect)
사이버보안 이벤트의 발생을 식별하기 위해 적절한 활동을 개발하고 구현
대응
(Respond)
탐지된 사이버보안 사고에 대해 조치하기 위해 적절한 활동을 개발하고 구현
복구
(Recover)
회복 탄력성을 유지하고 사이버보안 이벤트로 인해 손상된 역량 또는 서비스를 복원하기 위해
적절한 활동을 개발하고 구현
NIST IR 8401은 CSF의 다섯 가지 핵심 기능인 식별, 보호, 탐지, 대응, 복구를 지상국 환경에
적용하기 위한 실무 지침으로 구성한다. NIST IR 8401은 일반적인 CSF 설명에 그치지 않고,
각 기능별 요구사항을 지상국 운영 특성을 반영한 세부 활동을 매핑하여 구체적인 운영 지침을
제시한다.
표 7
NIST CSF와 지상국 영역 적용성
CSF 구분
항목 개수
지상국 영역 적용
식별
(Identify)
29개
지상국 영역 전반의 위험을 체계적으로 파악하기 위한 단계로, 지상국의
환경과 자산(하드웨어, 소프트웨어, 인력), 거버넌스 구조 및 공급망을
대상으로 위험을 식별하고 우선순위를 설정하는 데 중점
보호
(Protect)
39개
지상국 영역의 핵심 기능이 침해되거나 중단되는 것을 예방하기 위해 명령
송신 및 원격 측정 수신 시스템에 대한 접근 통제, 데이터 보호, 유지보수 절차,
보호 기술의 구현 등을 포함
탐지
(Detect)
18개
이상 징후 모니터링 활동을 다루며 네트워크뿐만 아니라 우주선과의 통신
채널(TT&C)을 통합적으로 모니터링하여 공격 및 이상 징후를 적시에
발견하는 것이 핵심
대응
(Respond)
16개
사고의 확산과 영향을 최소화하기 위해 이해관계자(MOC, PCC 등)와의 정보
공유, 사고 분석, 완화 조치 및 대응 계획의 지속적 개선을 강조
복구
(Recover)
6개
침해사고 이후 정상 운영 상태를 신속히 회복하는 것을 목표로, 복구 계획
실행, 이해관계자와의 복구 현황 소통, 사고 대응 경험을 반영한 복구 계획
업데이트를 포함

---
<!-- Page 18 -->
18 | 우주 보안 모델 해설 및 적용사례집
보고서는 이러한 CSF 기반 프로파일 구조를 지상국 보안의 고정된 최소 기준이 아니라,
조직별 임무 중요도·자산 구성·운영 방식에 맞게 조정하거나 확장할 수 있는 형태의 실무 지침을
제시한다.
우주 기업은 NIS2 제21조의 사이버 위험 관리 조치나 CMMC 레벨 2·3의 기술적 통제
요구사항을 실제 운영 환경에 적용할 때, 단순한 정책 수준의 요구사항만으로는 보안 통제를
구체적으로 구현하기 어렵다. NIST IR 8401은 지상국 환경에 특화된 실질적·기술적 구현 기준을
제공함으로써, 이러한 규제 요구사항을 실무적으로 충족할 수 있는 보안 지침으로 활용될 수 있다.
(2) NIST IR 8270 (Commercial Satellite Operations Security)
NIST IR 8270은 미국 국립표준기술연구소(NIST)가 발간한 우주 시스템 사이버보안
지침으로, NIST Cybersecurity Framework(CSF)를 기반으로 우주 미션 운영 환경에서 위험을
식별·평가·관리하기 위한 체계적인 접근 방법을 제시한다. 본 보고서는 법적 강제력을 가지는
규정이나 인증 기준이 아닌 권고이며, 우주시스템 보호 전략을 수립할 수 있도록 지원하는 것을
목적으로 한다.
IR 8270은 우주 시스템의 기술 구조와 운영 특성을 반영한 실무 중심의 보안 프레임워크 적용
방식을 제시하여, 산업·정부·방위·연구기관의 미션 보안 요구사항을 충족할 수 있는 관리 기준을
제공한다.
본 문서는 우주 시스템의 전반적인 운영 환경에서 발생 가능한 사이버보안 위험을 다루며, 위성
플랫폼과 지상 제어 인프라 간 상호작용을 포함한 전체 시스템 관점의 보안 관리를 제시한다. 분석
대상은 우주 시스템 전체를 기반으로 하며, 단순한 개별 구성요소 보호가 아니라 시스템 간 연계,
운용 절차, 데이터 흐름 관점의 위험 관리를 중심으로 다룬다.
•우주 비행체 수명주기 단계
우주 비행체는 설계 및 개발, 조립, 발사 전, 발사, 궤도 점검, 운영, 그리고 폐기에 이르는
다양한 수명 주기 단계를 거치며, 각 단계는 시스템에 고유한 사이버보안 위험을 가진다. 각
단계별 주요 활동과 핵심적인 보안 고려 사항은 다음과 같이 요약할 수 있다.

---
<!-- Page 19 -->

## 제1장 개 요  | 19

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
그림 2
우주 비행체 생명주기
표 8
우주 비행체 생명주기 별 보안 고려사항
단계
주요 활동
핵심 보안 고려사항
설계 및 개발
시스템 요구사항 정의, SW/지상국
인터페이스 설계
공급망 검증, 설계 위변조 방지, 취약점 사전
제거(보안 내재화)
조립
하드웨어 제작, 센서·페이로드 통합, 품질검증
HW·FW 위변조 방지, 인증된 구성요소 사용,
조립 과정 보안
발사 전
초기 구성, 테스트, 지상국 연동
구성 무결성 검증, 접근 통제, 데이터 로딩
보호
궤도 점검
초기 명령 수행, 궤도 안정화
명령 채널 보안, 통신 암호화, 재전송
공격·간섭 방지
운영
임무 수행, 소프트웨어 업데이트
원격제어 보호, 펌웨어 업데이트 검증,
지상국·링크 보호, 이상행위 모니터링
폐기
임무 종료, 데이터 삭제 및 처리
데이터 영구삭제, 오용 방지, 궤도 파편
리스크 최소화
NIST IR 8270은 이 단계들이 모두 중요하지만, 특히 탐지, 정보 처리, 데이터 획득 및 통신이
이루어지는 운영 단계에 중점을 두어 CSF 적용 방안을 설명한다. 우주 환경의 특성상 발사 후에는
하드웨어 변경이 불가능하거나 제한되므로, 설계 단계에서부터 보안 통제를 통합하고, 장기적인
사이버 위협에 대응할 유연성을 확보하는 것이 중요하다.

---
<!-- Page 20 -->
20 | 우주 보안 모델 해설 및 적용사례집
•CSF 프로파일 기반 위험관리 지침
NIST IR 8270은 상업용 우주 기업이 사이버보안 위험 관리를 시작하고 지속적으로 개선할
수 있도록 NIST 사이버보안 프레임워크(CSF)를 기반으로 하는 방법론을 제시한다. CSF는 식별,
보호, 탐지, 대응, 복구의 5가지 기능으로 구성되어 있다.
보고서는 조직이 CSF를 활용하여 현재 보안 수준을 반영한 ‘현재 프로파일’과 달성하고자
하는 목표 보안 수준을 정의하는 ‘목표 프로파일’을 설정하고, 두 프로파일 간의 보안 수준 격차를
분석하여 실행 계획을 수립하는 7단계 접근법을 제시한다.
표 9
NIST CSF 7단계 접근법
NIST CSF
실천 7단계
사례
(저궤도 소형위성 플랫폼)
산출물 / 목적
1단계: 범위 및
우선순위 설정
소형 위성 플랫폼 및 탑재체, 내부 통신,
명령·제어 채널을 보안 범위로 확정
보안 프로그램 범위 및 우선순위 정의,
현재/목표 프로파일 설정 기반 확보
2단계: 방향 설정
중요 자산(통신·자세제어)을 식별하고
재밍, 스푸핑, 명령 탈취 위협을 정의
임무·규제·운영 요구사항 반영, 위협
모델 및 보호기준 설정
3단계: 현재
프로파일 생성
현행 CSF 하위범주(예: PR.AC-1,
PR.DS-1) 이행 현황 문서화
현 상태의 보안 능력 및 통제 수준 평가
4단계: 위험 평가
수행
외부 위협 정보를 활용하여 심각도·발생
가능성 기반 위험 우선순위 산정
보안 위험 식별 및 영향분석, 자원 배분
우선순위 설정
5단계: 목표
프로파일 생성
필요 보안 결과 달성을 위한 CSF 하위범주
목록 정의 (예: PR.AC-3, ID.RA-1)
목표 보안 수준 정의 및 요구 통제 도출
6단계: Gap 분석 및
우선순위 지정
현재 vs 목표 간 차이(Gap) 도출 및 통제
필요 영역 정의
개선 과제 및 실행계획 수립
7단계: 실행 계획
실시
인증 기반 통신(PR.AC-7) 적용, C2 링크
공격 대응 자율 안전모드 구축(PR.IP-9)
지속적 개선 기반 사이버보안 프로그램
운영
우주 기업은 NIST CSF 기반 보안 통제를 위성 운영 환경에 적용할 때 적용 대상
(우주·지상·사용자 등)과 우주 비행체 생명주기별로 상이한 요구사항을 고려해야 한다. 그러나
정책 수준의 지침만으로는 복잡한 운영 환경에 맞는 보안 관리 전략을 수립하기 어렵다. NIST IR
8270은 CSF 프로파일 개발을 위한 7단계 접근법과 사례를 제공하여, 조직이 현재 프로파일과
목표 프로파일의 Gap을 정의하고 실행 계획을 수립하도록 지원한다. 이를 통해 우주 산업은 NIS2
제21조의 사이버 위험 관리 조치나 미국 CMMC 레벨 2·3과 같은 규제 준수 체계를 기술적으로
구현하는 데 활용할 수 있다.

---
<!-- Page 21 -->

## 제1장 개 요  | 21

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
(3) ENISA Space Threat Landscape
유럽사이버보안청(ENISA)는 상업용 위성 산업에 영향을 미치는 최신 사이버 위협 환경을
체계적으로 식별·평가하고, 산업이 적용 가능한 현실적인 보안 통제 및 완화 전략을 제시하기 위해
본 보고서를 발간하였다. 보고서는 최근 발생한 주요 위성 기반 사이버 공격 사례를 분석하여 우주
시스템의 침해가 사회·경제·국가 안보 전반에 미칠 수 있는 광범위한 영향을 강조한다.
또한 EU의 NIS2 Directive가 2025년 1월부터 우주 분야를 필수 서비스로 분류하여 강화된
보안 요구사항 준수를 요구함에 따라, 본 보고서는 산업계가 규제 대응과 운영 복원력 향상을
달성할 수 있도록 위협 기반 보안 기준과 정책 설계 참고자료를 제공하는 것을 주요 목적으로
한다.
본 보고서는 상업용 위성 시스템의 전체 생명주기 전반에서 고려해야 하는 사이버 위협과
취약성을 다루며, 이를 구성하는 자산과 관련 행위자를 분석 범위로 정의한다. 유럽사이버
보안청(ENISA)은 위성 운영 구조를 설명하기 위해 우주·지상·사용자·인적자산의 네 개 부문으로
자산을 분류한다.
표 10
유럽사이버보안청(ENISA) 자산분류
영역
설명
지상 영역
(Ground Segment)
위성 통신 중계, TT&C, 통제 센터, 생산·운송·발사 인프라 등 지상 기반 운영
자산
우주 영역
(Space Segment)
궤도상의 버스(BUS) 플랫폼 및 임무 수행을 위한 탑재체(Payload)로 구성된
실제 위성 자산
사용자 영역
(User Segment)
소비자 및 기관이 서비스를 이용하기 위한 단말 장치(예: VSAT, 위성전화,
GPS 수신기, 항공기 시스템 등)
인적자산 영역
(Human Resources)
개발·운영·지원 인력과 공급망 참여자를 포함한 인적 자산 요소
유럽사이버보안청(ENISA)은 위성 시스템의 사이버 공격을 수행할 수 있는 행위자를 다음과
같은 범주로 정의하며, 이들 각각은 위성 생태계 자산 전반에 걸쳐 각각 다른 공격 목표와 방법을
보유한다.

---
<!-- Page 22 -->
22 | 우주 보안 모델 해설 및 적용사례집
표 11
유럽사이버보안청(ENISA) 위협 행위자군
위협 행위자군
동기 및 특징
위협 대상 자산 / 가능 행위 예시
국가 연계 행위자
전략적 정보 수집, 군사·정치적
이익, 통신 감청 또는 교란
위성 Bus / Payload, 통신 링크, 지상국 인프라 /
명령 제어 탈취, 감청, 위성 교란
사이버 범죄자
금전적 이익, 데이터 유출, 서비스
방해
지상국, 통신, 데이터 서비스 / 데이터 탈취,
랜섬웨어, 서비스 거부
고용된 해커
고객 의뢰 작업, 외주 공격, 공격
서비스 제공
위성 및 Ground 인프라 / 위성 지상국 침투, 위성
제어권 탈취, 악성 신호 송출, DoS
내부자
내부 정보 접근, 권한 오남용, 복수
동기
제조·조립 시설, 지상국 / 하드웨어 변조, 악성 코드
삽입, 권한 남용
해커티비스트 /
시민운동자
정치적·이념적 목적, 사회적
메시지
통신 위성, 데이터 서비스 / 서비스 방해, 방송
간섭, 정보 공개
본 보고서는 상업용 위성 생태계에 영향을 미치는 실제 공격 벡터와 그로 인한 잠재적
영향, 그리고 이를 최소화하기 위한 통합적 보안 전략을 제시한다. 이 보고서는 위성 시스템이
공급망·통신·운영·인적 요소 등 전체에 걸쳐 상호 연결된 구조이기 때문에 공격이 전체로 확산될
수 있음을 강조한다.
(4) 민간우주시스템의 사이버보안대책 가이드라인
민간우주시스템의 사이버보안대책 가이드라인은 민간 우주기업의 위성 및 지상 시스템 전반에
공통적으로 고려해야 할 사이버보안 사항을 정리한 가이드라인이다. 민간 우주 시스템을 구성하는
주요 요소와 연계된 구조를 기준으로 보안 범위와 대책을 제시한다.
본 가이드라인은 민간 우주 시스템 구성 요소를 기능 단위로 구조화한 표준 모델을 제시한다.
이는 특정 사업자의 모델에 국한되지 않고 민간 우주 산업 전반에 공통으로 존재하는 요소를
정리한 것이다. 가이드라인에서 제시하는 표준 모델의 구성과 주요 보안 관점은 다음과 같다.

---
<!-- Page 23 -->

## 제1장 개 요  | 23

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
표 12
민간우주시스템 가이드라인 표준 모델 구성
구분
주요 구성 요소
보안 관점
우주 영역
위성 본체, 탑재체
물리적 접근 제한, 원격 명령 무결성, 장기 운용
안정성
지상 영역
위성 운용 시스템, 지상국,
네트워크 인프라
접근통제, 운영 연속성, 내부·외부 침해 대응
사용자 영역
위성 통신 시스템, 데이터 이용
시스템
데이터 기밀성·무결성, 서비스 신뢰성
인적·조직적 요소
개발·제조, 운영 조직,
외주·공급망
절차 관리, 내부자 위협, 공급망 리스크
우주 시스템 구성 요소 간의 관계를 정의한 표준 모델을 기반으로, 사이버 공격이 어느 지점에서
시작되어 어떤 경로로 확산되고, 최종적으로 어떤 영향을 미치는지 설명하는 위협 시나리오를
제시한다. 예를 들어, 지상 시스템 침해를 시작으로 위성 명령 체계에 영향을 미치거나, 통신
시스템 교란이 서비스 중단으로 확산되는 등, 하나의 침해가 시스템 전반으로 전파되는 과정을
표준 모델을 통해 설명한다.
위협 시나리오에서 도출된 위험에 대응하기 위한 보안 대책은 조직·거버넌스 중심의 관리
체계를 다루는 공통적 보안 대책과 우주 임무의 특수성을 반영한 우주 시스템 보안 대책으로
나누어 제시한다.
공통적 보안 대책은 위성 소유자, 개발·제조 사업자, 운용 사업자 등 민간 우주 시스템에
관여하는 모든 조직이 기본적으로 갖추어야 할 조직·거버넌스 중심의 관리 체계를 의미한다. 우주
시스템 보안 대책은 위성의 수명 주기와 시스템 구조를 고려하여, 위성 본체, 지상 운용 시스템,
통신·데이터 이용 시스템, 개발·제조 시스템 등 서브시스템 별로 중점 관리가 필요한 기술적
통제를 정리한 것이다.

---
<!-- Page 24 -->
24 | 우주 보안 모델 해설 및 적용사례집
표 13
민간우주시스템 가이드라인 보안 대책
구분
보안 대책 내용
공통적 보안
대책
 경영진 주도의 사이버보안 리스크 관리 체계 구축 및 조직 차원의 책임·의사결정 구조 정립
 NIST CSF, ISO/IEC 2700115 등 기존 정보보호 관리체계 및 사이버보안 프레임워크의 활용
 클라우드 서비스 이용 시 법령 및 임무 중요도에 따라 적절한 클라우드 인증 서비스 선택
 재택근무 등 원격 근무 환경에 대한 보안 통제 및 운영 기준 마련
 내부 부정행위의 예방·조기 발견을 목표로 관련 기존 기준을 참고해 대응 방안을 검토
 관련 법령에 따른 외부 사고 보고 대상, 절차 및 연락 체계 정비
우주 시스템
보안 대책
 우주 관련 법령에서 요구하는 데이터 보호 및 안전 관리 조치 준수
 위성 본체에 대한 통신 보호, 명령 무결성 확보, 재밍 대응 및 공급망 보안 강화
 지상 운용 시스템의 물리적·기술적 보호, 운영 연속성 확보 및 취약점 관리
 위성 통신 및 데이터 이용 시스템의 기밀성·무결성·가용성 확보를 위한 기술적 통제
본 가이드라인은 민간 우주 시스템의 구성과 운용 방식에 따라 각 조직이 스스로 보안 위험을
식별하고 적절한 대책을 선택하여 적용할 수 있는 기준을 제공한다. 민간 우주 기업은 본
가이드라인의 표준 모델과 시나리오를 참조하여, 자사 환경에 최적화된 보안 우선순위를 설정하고
실용적인 대책을 구축할 수 있다.
15 ‌국제 표준화 기구(ISO)에서 제정한 정보보호 관리체계에 대한 요구사항을 규정한 국제 표준. 정보 보호 분야에서 가장 권
위 있는 국제 인증 표준

---
<!-- Page 25 -->

## 제1장 개 요  | 25

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
우주 보안모델

## 1. 우주 보안모델


## 2. 우주 보안 체크리스트

제 2 장

---
<!-- Page 26 -->
26 | 우주 보안 모델 해설 및 적용사례집
본 장에서는 우주 보안모델과 GSaaS 아키텍처, 우주 공급망 아키텍처를 소개하고 우주보안
체크리스트를 설명한다.
제1절
우주 보안모델
우주 아키텍처는 다음 그림과 같이 우주 영역, 지상국 영역, 위성 활용 서비스 영역으로
구성된다.

## 제2장

우주 보안모델

---
<!-- Page 27 -->

## 제2장 우주 보안 모델  | 27

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
그림 3
우주 아키텍처
우주 아키텍처는 고도 범위에 따라 다양한 위성이 위치한 우주 영역과 위성으로부터 페이로드
데이터(payload data)를 송수신하고, 위성을 제어하기 위한 시스템으로 구성된 지상국 영역,
그리고 위성에 기반한 서비스를 제공하는 위성 활용 서비스 영역으로 구분된다.
■ 우주 영역
우주 영역은 우주 공간에 위치하는 자산으로 구성되며, 대표적인 자산으로 인공위성(이하
‘위성’이라 함)이 있다. 위성은 위성의 전반적인 구동을 수행하는 본체와 위성의 임무를 수행하는
탑재체로 구분되며, 세부 구성요소를 표현한 아키텍처는 아래 그림과 같다.

---
<!-- Page 28 -->
28 | 우주 보안 모델 해설 및 적용사례집
그림 4
위성 아키텍처
본체는 열제어 시스템, 전력공급 시스템, 위성제어 시스템, 궤도제어 시스템, 위성내부 버스,
명령 및 데이터처리시스템, 통신시스템 등으로 구성되고, 탑재체는 위성 본체에 탑재되어 위성에
부여된 임무를 수행하게 된다. 탑재체의 임무에 따라 위성의 역할이 결정되며, 페이로드, 페이로드
데이터처리시스템 및 통신시스템으로 구성되어 있다.
■ 지상국 영역
지상국 영역은 위성을 운영 및 제어하기 위한 위성운영 영역과 페이로드에서 데이터를 수신하고
수신한 데이터를 서비스하기 위한 페이로드 데이터 이용 영역으로 구분된다. 지상국 영역의 세부
구성요소를 제시하는 아키텍처는 아래 그림과 같다.

---
<!-- Page 29 -->

## 제2장 우주 보안 모델  | 29

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
그림 5
지상국 아키텍처
위성운영 영역은 위성상태 모니터링 시스템, 궤도제어시스템, 미션제어 및 운영지원 시스템,
위성제어 시스템, 긴급대응 및 위기관리 시스템 등으로 구성되고, 페이로드 데이터 이용 영역은
데이터 수신 및 처리 시스템, DB 분석 및 시각화 시스템, 페이로드 데이터 서비스 시스템,
실험계획 및 제어시스템, 관측요청 접수 시스템 등으로 구성되어 있다.
■ 위성 활용 서비스 영역
위성 활용 서비스 영역은 위치정보를 제공해 주는 위성항법 서비스와 통신 및 방송을
중계해주는 위성방송통신 서비스로 구분된다. 위성항법서비스는 위성으로부터 위치정보를
수신하여 지상교통 및 항공교통에서의 차량 운행에 사용되는 서비스이고, 위성통신서비스는
위성안테나와 통신위성의 서비스를 활용하여 지상의 인터넷 서비스를 사용할 수 있도록 지원해
주는 서비스이며, 위성방송서비스는 지상 방송국의 방송서비스를 위성을 활용하여 중계하는 방송
서비스이다.

---
<!-- Page 30 -->
30 | 우주 보안 모델 해설 및 적용사례집
본 보고서에서는 우주보안모델(GSaaS, 우주 공급망)에서 제시한 GSaaS 아키텍처와 우주
공급망 아키텍처를 소개한다.
가. GSaaS 아키텍처
GSaaS는 위성과 통신하고 제어하는 지상국 기능을 클라우드를 활용하여 제공하는 서비스로,
위성과 통신하는 안테나 영역과 위성 서비스를 위한 데이터 처리를 수행하는 지상국 영역, 위성
서비스를 제공하는 위성 운영사 영역을 범위로 한다.
그림 6
GSaaS 아키텍처
안테나를 통해 위성과 신호를 송수신하며, 지상국은 원활한 통신을 위해 위성의 상태를
모니터링하고 제어한다. 클라우드 환경에서는 데이터의 저장과 서비스 운영을 지원하고, 위성과의
통신을 위한 안테나 예약 기능을 제공한다. 위성 운영사는 GSaaS에 접속하여 수집된 데이터를
분석 및 가공하고, 처리된 데이터를 활용하여 사용자에게 다양한 위성 서비스를 제공한다.

---
<!-- Page 31 -->

## 제2장 우주 보안 모델  | 31

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
나. 우주 공급망 아키텍처
위성의 생애 주기(설계/개발, 준비/조립, 발사, 궤도진입 확인, 운영, 위성 해체)를 기반으로
위성/발사체 제조사, 지상국 운영사, 위성 운영사로 구성되어 있다.
그림 7
우주 공급망 아키텍처
위성/발사체 제조사는 탑재체를 포함한 위성 본체와 발사체를 제작하고, 탑재되는
소프트웨어를 개발하는 역할을 수행하며, 위성 운용의 기초가 되는 하드웨어와 소프트웨어
자산을 공급하는 영역이다. 지상국 운영사는 위성과 지상 간 통신을 관리하고, 위성 운용에 필요한
시스템과 소프트웨어를 운용하여, 위성이 임무를 안정적으로 수행할 수 있는 환경을 제공하고
운영을 지원하는 영역이다. 위성 운영사는 위성으로부터 수신한 탑재체 데이터를 목적에 따라
분석 및 처리하고, 이를 활용하여 위성 활용 서비스를 제공하는 영역이다.

---
<!-- Page 32 -->
32 | 우주 보안 모델 해설 및 적용사례집
제2절
우주 보안 체크리스트
우주기업 보안담당자가 기업의 현재 보안상황을 진단하고 우주보안 대책을 수립할 수 있도록
우주보안 체크리스트를 개발하였다. 우주 보안 체크리스트는 CMMC16 2단계 통제항목을
기준으로 한국형 위험관리체계인 K-RMF17, 유럽연합 보안 Directive인 NIS218, 국내 정보보호
관리체계(ISMS19)를 반영하여 작성하였다. 다음 표는 우주보안 체크리스트 12개 분야 53개
항목이다.
표 14
우주보안 체크리스트
분야
보안항목
보안항목 설명
AC-01
접근통제 정책
• 시스템 접근권한을 부여한 기기, 사용자 및 프로세스에 한하여
접근을 허용해야 한다
AC-02
최소권한
• 사용자에게 부여된 과업 및 직책을 수행하는데 필요한 최소한의
권한을 부여한다.
AC-03
특수 권한 사용
• 특수 권한 사용자가 실행할 수 있는 기능에 대한 시스템 접속을
제한하고 특수 권한으로 실행되는 기능들을 감사해야 한다.
AC-04
정보흐름 통제
• 시스템 내부 및 시스템 간 정보 흐름을 통제해야 한다.
AC-05
직무 분리
• 개인의 직무를 분리하고 이에 따라 시스템의 접근권한을 부여해야
한다.
접근통제
(AC)
AC-06
로그인 시도 실패• 일정 기간 동안 연속으로 유효하지 않은 로그인 시도를 제한하고
최대 허용 횟수를 초과하면 자동으로 계정을 잠궈야 한다
AC-07
세션 잠금 및 종료
• 일정 기간 동안 세션 사용이 없거나 사용자에 의한 세션 잠금
요청이 있을 경우 해당 세션을 잠그고,세션 종료 조건 발생 시
자동으로 세션을 종료해야 한다
AC-08
원격 접근통제
• 승인된 업무 및 사용자에 대해서만 원격접속을 허용하고 원격접속
세션을 암호화 및 모니터링해야 한다.
16 ‌CMMC : Cybersecurity Maturity Model Certification
17 ‌K-RMF : Korea - Risk Management Framework
18 ‌NIS : network and information systems
19 ‌ISMS : Information Security Management System

---
<!-- Page 33 -->

## 제2장 우주 보안 모델  | 33

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
분야
보안항목
보안항목 설명
AC-09
무선 접속
• 시스템에 무선접속시 승인받은 사용자/기기 인증을 수행하고
통신세션을 암호화해야 한다.
AC-10
모바일기기 연결
통제
• 승인된 모바일 장치에 대해서만 시스템의 연결을 허용하고 모바일
장치에서 정보를 암호화해야 한다.
AC-11
외부 연결 통제
• 외부 시스템과 조직 내부시스템에 대한 연결 및 사용을 확인하고
통제해야 한다
AC-12
공공 정보 통제
• 공개적으로 접근 가능한 시스템에 정보를 게시하기 전에 해당
내용을 검토하여 중요정보가 게시되지 않도록 한다.
식별 및 인증
(IA)
IA-01
식별 및 인증
• 시스템 사용자, 프로세스 및 장치를 식별하고 인증해야 한다.
IA-02
다중 인증
• 특수 권한 계정으로 네트워크에 접속할 경우에는 다중 인증을
사용하고 재전송 공격 방지 인증 메커니즘을 적용해야 한다.
SC-01
경계 보호
• 조직 시스템의 외부 경계와 주요 내부 경계에서의 통신(송수신
정보)을 모니터링, 제어 및 보호해야 한다
SC-02
보안공학 원칙
적용 및 기능 분리
• 보안 아키텍처는 심층 방어 원칙을 기반으로 설계하고, 시스템의
관리 기능과 사용자 기능을 명확히 분리하여 운영하여야 하며,
시스템 개발 과정에서는 보안공학 원칙을 적용하여야 한다.
SC-03
저장 및 전송 정보
보안
• 저장 및 전송되는 정보의 기밀성 및 무결성을 보호해야 한다.
시스템 및
통신 보안(SC)
SC-04
통신 보안
• 기본적으로 모든 트래픽을 거부하고, 필요한 트래픽만 예외적으로
허용하는 방식으로 운용하고, 로컬 및 원격연결을 동시에 하지
못하도록 통제하며 통신세션 종료 이후 또는 일정 기간동안 작업이
없을 경우 통신 세션과 관련된 연결을 종료해야 한다.
SC-05
암호화
• 중요 정보는 암호화하고 암호화를 위한 암호키를 설정하고
관리해야 한다.
SC-06
협업 컴퓨팅 장치
• 협업 컴퓨팅 장치의 원격 활성화를 금지하고 장치가 사용 중일 때는
물리적으로 나타나는 표시를 통해 사용자가 장치가 사용 중임을
인식할 수 있어야 한다.
SC-07
모바일 코드 및
VoIP 통제
• 시스템 내 모바일 코드 및 VoIP의 사용을 모니터링·통제해야 한다.

---
<!-- Page 34 -->
34 | 우주 보안 모델 해설 및 적용사례집
분야
보안항목
보안항목 설명
SI-01
취약점 점검 및
결함교정
• 시스템과 애플리케이션의 취약점을 주기적으로 검사하고, 해당
시스템에 영향을 미치는 신규 취약점이 확인될 때마다 검사하여
시스템의 결함을 식별, 조치, 보고해야 한다
시스템 및
정보무결성
(SI)
SI-02
악성코드 방지
• 악성코드 식별 및 제거를 위해 시스템에 악성코드 방지솔루션을
설치하고 파일 다운로드시 실시간으로 검사해야 한다.
SI-03
보안 경보, 권고
• 시스템 보안 경고와 권고를 모니터링하고 이에 대한 대책을
수립해야 한다
SI-04
시스템 및 통신
트래픽 모니터링
• 시스템의 무단 사용을 모니터링하고 송ㆍ수신되는 네트워크
트래픽을 주기적으로 모니터링해야 한다.
SO-01
유지보수 통제
• 시스템 유지관리에 사용되는 도구, 기술, 메커니즘 및 인력을
통제해야 한다
- 원격 유지보수 시스템 외부 반출 전 정보소거
- 유지보수용 저장매체 악성코드 검사
- 원격 유지보수시 사전승인, 강화된 인증, 유지보수 활동 기록,
업무 종료시세션 종료
- 유지보수 인력 관리 감독
시스템/서비스
운영 관리
(SO)
SO-02
시스템  감사 및
감사기록 분석,
보고
• 불법적이거나 승인되지 않은 시스템 활동을 모니터링, 분석, 조사
및 보고하기 위한 시스템 감사 로그 및 기록을 생성 및 보관해야
하고 부적절하거나 비정상적 활동을 분석 및 보고해야 한다. 또한
감사 정보를 보호하고 감사 로깅 오류시 경고한다.
SO-03
시간동기화
• 감사기록을 위한 타임스템프생성을 위해 내부 시스템(NTP서버)
시간을 사용해야 한다.
SO-04
휴대용 저장장치
(저장매체 등)
보안
• 중요정보가 저장된 저장매체 및 휴대용 PC는 물리적으로 안전하게
보관하고 기밀성, 무결성을 보호하기 위해 통제해야 한다.
- 저장매체 이동시 암호화 등으로 보호
- 폐기 또는 재사용을 위해 반출되기 전에 정보소거하거나파기
- 매체 백업 정보의 기밀성 보호
SO-05
형상관리
• 시스템 구축 및 운영의 통제기준이 되는 최신화된 형상관리
기준선(Baseline)을 식별하고 시스템 정보기술 제품들의 보안
환경설정을 수립 및 문서화해야 한다.
SO-06
시스템 및
애플리케이션
보안 요구사항
정의
• 사업 기획 단계에서 시스템 및 서비스에 대한 정보보안 요구사항을
정의해야 하며, 안전한 코딩 방안을 포함하여야 한다

---
<!-- Page 35 -->

## 제2장 우주 보안 모델  | 35

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
분야
보안항목
보안항목 설명
SO-07
시스템/
애플리케이션
변경관리
• 시스템 및 애플리케이션의 변경 사항을 검토, 승인/거부하고
변경내역을 기록해야 하며 변경 전에 변경에 대한 잠재적인 보안
영향을 분석해야 한다.
SO-08 개발 시험 및 평가
• 사전 정의된 보안 요구사항에 따라 정보시스템이 도입 또는
구현되었는지를 검토하기 위하여 법적 요구사항 준수, 최신
보안취약점 점검, 안전한 코딩 구현 등의 검토 기준과 절차를
수립·이행하고, 발견된 문제점에 대한 개선조치를 수행하여야
한다.
SO-09
기능최소화 및
사용자설치
소프트웨어 통제
• 필수 기능만 제공하도록 시스템을 설정하고 사용자가 설치한
소프트웨어를 통제하고 모니터링한다.
사고 대응
(IR)
IR-01
사고 처리 및
테스트
• 사고대응 준비, 사고 탐지, 사고 조사/분석, 피해 시스템의 분리 및
차단, 피해 시스템 복구를 포함한 사고 처리 대응 체계를 구축하고
주기적으로 사고대응 테스트를 실시해야 한다
IR-02
사고 보고
• 사고를 인지한 인원이 지정한 시간 내에 사고대응 부서에 신고하고
사고대응 부서는 사고를 관련 기관에게 통지해야 한다.
인원보안
(PS)
PS-01
인원보안
• 직원 고용시 배경검사를 시행하고 보직 변경/퇴직 시 시스템 접근
권한을 검토/변경/삭제해야 하며 기업의 보안 정책 위반시 징계
절차를 수립해야 한다.
PS-02
보안인식
교육·훈련
• 직무별 전문성을 확보할 수 있도록 인식제고 활동 및 교육훈련
계획을 수립 및 시행해야 한다.
물리보안
(PE)
PE-01
물리적 접근통제• 시스템이 설치·운영되고 있는 시설의 출입을 통제하고
모니터링하며 물리적 접근 이력을 주기적으로 검토해야 한다.
PE-02
대체 근무장소
보안
• 시설에 대한 물리적 접근을 모니터링하고 대체 근무장소에서 중요
정보에 대한 안전조치를 시행한다
PE-03
보호설비 운영
• 보호구역에 위치한 정보시스템의 중요도 및 특성에 따라
온도·습도 조절, 화재감지, 소화설비, 누수감지, UPS, 비상발전기,
이중전원선 등의 보호설비를 갖추고 운영절차를 수립·운영하여야
한다.
위험 평가 및
보안평가(RA))
RA-01
위험 평가
• 시스템 운영 및 관련 정보의 처리, 저장 또는 전송으로 인해
발생하는 조직 운영(임무, 기능, 이미지 또는 평판 포함), 조직 자산
및 개인에 대한 위험을 주기적으로 평가해야 한다.
RA-02
보안 통제
모니터링 및
효과성 평가
• 보안 위험관리 조치를 승인하고 지속적으로 보안 통제를
모니터링하여 보안통제의 지속적인 효과를 보장해야 한다.

---
<!-- Page 36 -->
36 | 우주 보안 모델 해설 및 적용사례집
분야
보안항목
보안항목 설명
SG-01
보안 정책 수립
• 우주보안 정책 및 지침을 수립하여 경영진의 승인을 받고
주기적으로 검토 및 개정하여야 한다.
보안 거버넌스
(SG)
SG-02 보안 역할 및 책임
정의
• 우주보안 관련 책임자와 담당자의 역할 및 책임을 명확히 정의하고,
조직 변화에 따라 이를 지속적으로 유지·관리해야 한다.
SG-03
자산관리
• 우주 관련 자산을 식별하고 목록화하며, 변동 사항을 반영하여 최신
상태로 관리해야 한다.
SG-04
법적요구사항
준수
• 조직이 준수하여야 할 우주보안 관련 법적 요구사항을 주기적으로
파악하여 규정에 반영하고, 준수 여부를 지속적으로 검토하여야
한다.
비상계획
(CP)
CP-01
비상계획 수립
• 우주 시스템의 운영 연속성을 위협할 수 있는 보안 위협 유형을
식별해야 하며, 비상시 복구 절차, 복구 조직, 비상연락체계 등
비상계획을 수립하고 주기적으로 점검해야 한다.
CP-02
백업 및 이중화
관리
• 조직의 중요정보를 식별하고 주기적으로 백업하고 중요 네트워크,
시스템은 이중화한다.
공급망관리
(SM)
SM-01
공급망 보호
• 협력사로 인해 발생할 수 있는 보안 위협을 방지하기 위해 공급망
보안 정책을 수립하여 협력사 선정을 위한 기준과 계약서를
마련하고, 협력사 명부를 작성 및 최신화해야 한다
SM-02
인수 전 평가
• 시스템/구성요소/서비스의 선정/인수/업데이트 전에 보안취약점
점검 및 조치하고 인수 테스트를 통해 구성요소의 위조를 검사해야
한다
SM-03
모든 출처 정보
사용
• 시스템/구성요소/서비스 (잠재적) 공급업체를 대상으로 모든 출처
정보(all-source intelligence) 분석을 수행해야 한다.
SM-04
변조/위조 방지
및 탐지
• 시스템/구성요소/서비스의 변조 및 위조를 방지하기 위하여
주기적으로 점검해야 한다

---
<!-- Page 37 -->

## 제2장 우주 보안 모델  | 37

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
우주 보안모델
해설

## 1. 접근통제(AC)


## 2. 식별 및 인증(IA)


## 3. 시스템 및 통신 보안(SC)


## 4. 시스템 및 정보 무결성(SI)


## 5. 시스템/서비스 운영관리(SO)


## 6. 사고 대응(IR)


## 7. 인원 보안(PS)


## 8. 물리보안(PE)


## 9. 위험 평가 및 보안평가(RA)


## 10. 보안 거버넌스(SG)


## 11. 비상계획(CP)


## 12. 공급망 관리(SM)

제 3 장

---
<!-- Page 38 -->
38 | 우주 보안 모델 해설 및 적용사례집
본 장에서는 우주보안 체크리스트 항목별로 중점적으로 확인해야 하는 보안사항을 구체적으로
설명하고 관련 기준을 제시한다.
제1절
접근통제(AC)
AC-01
접근통제 정책
항목 내용
시스템 접근권한을 부여한 기기, 사용자 및 프로세스에 한하여 접근을 허용해야
한다.
목적
시스템 자원에 대한 비인가 접근을 원천적으로 차단하고, 승인된 주체(기기,
사용자, 프로세스)만이 허용된 범위 내에서 접속하기 위함이다.
주요 확인사항
y 위성 및 궤도 제어시스템 등 우주시스템에 대한 접근 권한 부여, 승인, 변경
및 회수 절차를 포함한 접근통제 정책을 수립하고, 조직 및 기술환경 변화를
반영하여 정기적으로 검토 및 개정하고 있는가?
y 우주 시스템 접근 시 인가된 사용자, 인가된 사용자를 대신하여 동작하는
프로세스, 인가된 장치(다른 시스템 포함)가 고유하게 식별 및 관리되고 있는가?
y 서버, 네트워크시스템, 보안시스템 등 정보시스템별 운영체제(OS)에 접근이
허용되는 사용자, 기기, 프로세스, 접근 가능 위치, 접근 수단 등을 정의하여
통제하고 있는가?

## 제3장

우주 보안모델 해설

---
<!-- Page 39 -->

## 제3장 우주 보안모델 해설  | 39

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
세부 설명
⊙ ‌위성 및 궤도 제어시스템 등 우주시스템에 대한 접근 권한 부여, 승인, 변경 및 회수 절차를 포함한
접근통제 정책을 수립하고, 조직 및 기술환경 변화를 반영하여 정기적으로 검토 및 개정해야 한다.
▶ ‌우주시스템에 대한 접근 권한의 신청, 승인, 부여, 변경, 폐기 절차를 포함한 접근통제 정책을
수립해야 하며, 모든 승인 기록은 문서(전자결재 등)로 보관해야 함
▶ ‌임직원 퇴사 및 보직 변경 시 접근통제 정책의 검토 및 변경을 위해 인사 시스템과 연동하거나
인사 관련 부서와 정기적인 인사발령 현황 공유 체계를 구축하여 퇴사자 발생 즉시(당일 이내)
계정 삭제 또는 잠금 처리
▶ ‌보직 변경 시에는 기존 권한을 회수한 후 새로운 직무에 필요한 권한만 다시 부여
▶ ‌최소 연 1회(또는 반기별) 모든 시스템의 권한 보유 현황을 추출하여, 현재 직무와 권한이
일치하는지 전수 검토하고 불필요한 권한을 정리하여 그 결과를 보안 책임자에게 보고해야 함
⊙ ‌우주 시스템 접근 시 인가된 사용자, 인가된 사용자를 대신하여 동작하는 프로세스, 인가된
장치(다른 시스템 포함)의 목록을 유지·관리한다.
▶ ‌사용자 공용 계정 사용을 금지하고, 모든 계정은 특정 개인과 1:1로 매칭되도록 고유한
식별자(ID) 부여
▶ ‌시스템 간 API 연동, 배치 작업 등을 위해 사용되는 프로세스 계정은 일반 사용자 계정과
분리하여 관리하고, 해당 계정의 목적, 호출 주체, 유효 기간을 명시하여 관리
▶ ‌시스템에 접속하는 모든 단말기(엔지니어 PC, 서버, 모바일 기기 등)와 외부 시스템(협력사
시스템 등)의 고유 식별정보(MAC주소, IP등)을 식별하여 접속허용 단말 목록으로 작성하고 관리
▶ ‌단말기의 신규 도입, 교체, 폐기 시 자산 관리 대장과 접근허용 단말 목록에 이를 반영하여 최신
상태를 유지
⊙ ‌서버, 네트워크시스템, 보안시스템 등 정보시스템에 접근이 허용되는 사용자, 기기, 프로세스, 접근
가능 위치, 접근 수단 등을 정의하여 통제해야 한다.
▶ ‌정보시스템 접근은 사전에 지정된 IP 또는 또는 점프 서버(Jump Server)의 IP에서만 가능하도록
ACL(Access Control List) 설정
▶ ‌사설 IP주소를 할당하는 경우 국제표준에 따른 사설 IP 주소 대역 사용
사설 IP주소 대역
• A Class : 10.0.0.1 ~ 10.255.255.255
• B Class : 172.16.0.1 ~ 172.31.255.255
• C Class : 192.168.0.1 ~ 192.168.255.255

---
<!-- Page 40 -->
40 | 우주 보안 모델 해설 및 적용사례집
▶ ‌Telnet 등 평문 프로토콜 사용을 금지하고 SSH20, SFTP21, VPN22(IPSEC, TLS) 등 보안
프로토콜만 사용
• ‌특히 관리자 권한 접속이나 외부망 접속 시 반드시 OTP23, 인증서 등 2단계 인증(MFA24) 적용
▶ ‌디폴트 계정(admin, root 등) 및 패스워드는 사용을 중지하거나 변경해서 사용
관련 기준
⊙ ‌CMMC
• ‌3.1.1 (승인된 접근통제[CUI 데이터]) : 시스템 접근을 권한이 있는 사용자, 권한이 있는 사용자를 대신하여
동작하는 프로세스 및 장치(다른 시스템 포함)로 제한한다.
⊙ ‌K-RMF
• ‌AC-2 (접근통제 시행) : 접근통제정책 시행을 통해 정보와 시스템 자원에 대한 논리적 접근을 인가해야
한다.
⊙ ‌NIS2
• ‌11.1. 관련 기관은 비즈니스 요구사항뿐 아니라 네트워크 및 정보시스템 보안 요구사항을 기반으로 하여,
자신의 네트워크 및 정보시스템에 대한 접근을 위한 논리적 및 물리적 접근통제 정책을 수립, 문화화 및
이행하여야한다.
• ‌11.1.2. 11.1.1에서 언급된 정책은 다음을 수행하여야 한다.
(a) ‌직원, 방문자, 공급업체 및 서비스 제공자와 같은 외부 기관을 포함하여 사람에 의한 접근을 다루어야
한다.
(b) 네트워크 및 정보시스템에 의한 접근을 다루어야 한다.
(c) 적절하게 인증된 사용자에게만 접근이 허용되도록 보장하여야 한다.
⊙
‌
ISMS-P
• ‌2.6.2 정보시스템 접근 :서버, 네트워크시스템 등 정보시스템에 접근을 허용하는 사용자, 접근제한 방식,
안전한 접근수단 등을 정의하여 통제하여야 한다.
20	 ‌SSH(Secure Shell) : 통신 구간을 암호화 하여 원격 컴퓨터에 안전하게 접속하고 명령어 실행 및 파일 및 데이터를 전송
하는 암호화 통신 프로토콜
21	 ‌SFTP(Secure File Transfer Protocol) : 파일을 안전하게 주고받기 위해 SSH 프로토콜 기반으로 암호화 및 인증을 제공
하여 안전하게 파일을 전송하는 프로토콜
22	 ‌VPN(Virtual Private Network) : 가상사설망을 뜻하며 공중망(인터넷)을 통해 암호화된 터널을 만들어 특정 조직/인원만
이 접근 가능한 가상의 사설 네트워크를 만드는 서비스 체계
23	 ‌OTP(One-Time Password) : 로그인 할 때마다 그 세션에서만 사용할 수 있는 일회성 패스워드를 생성하는 보안 시스템
24	 ‌MFA(Multi-Factor Authentication) : 최소 두 가지 이상의 인증 요소를 이용하여 본인 여부를 인증하는 것

---
<!-- Page 41 -->

## 제3장 우주 보안모델 해설  | 41

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
AC-02
최소권한
항목 내용
사용자에게 부여된 과업 및 직책을 수행하는 데 필요한 최소한의 권한을
부여한다.
목적
우주 기업이 다루는 핵심 임무 데이터나 중요정보를 보호하기 위해 모든 직원이나
시스템 프로세스에 임무 수행에 꼭 필요한 최소 권한만 부여하여, 직원의 단순
실수나 낮은 권한의 계정 탈취로 인한 시스템 피해 확산 및 중요 데이터 유출을
예방하기 위함이다.
주요 확인사항
y 위성 본체 및 지상국 시스템 등 우주시스템에 접근하는 모든 사용자, 프로세스,
장치에 대해 최소 권한 원칙을 적용하는 절차를 수립하고 있는가?
y 위성 운영 시스템 등 핵심 시스템에 접근하는 사용자, 프로세스, 장치에 접근권한
부여 시 관리 책임자의 승인을 받고 있는가?
y 부여된 접근 권한이 적절한지 정기적으로 검토하고 있는가?
세부 설명
⊙ ‌위성 본체 및 지상국 시스템 등 우주시스템에 접근하는 모든 사용자, 프로세스, 장치에 대해 최소
권한 원칙을 적용하는 절차를 수립해야 한다.
▶ ‌직무별 접근 권한 분류 체계를 수립하고 최소한의 권한만을 부여해야 함
• 업무 분석을 통해 직무별로 필요한 접근권한을 정의
• ‌중요 시스템 및 애플리케이션, 장치에 대한 접근 권한은 ‘알 필요(Need-to-Know)’ 원칙에 따라
최소한으로 부여
⊙ ‌위성 운영 시스템 등 핵심 시스템에 접근하는 사용자, 프로그램, 장치에 접근권한 부여 시 관리
책임자의 승인을 득해야 한다.
▶ ‌권한 부여 또는 변경 시 관리 책임자의 승인 절차 등을 통하여 해당 권한 부여의 적절성 검토 시행
▶ ‌미션 크리티컬 권한이 부여된 계정(예: 위성 제어 서버의 운영 통제 계정)은 최소한의 인원에게만
부여하고, 이들에 대해서는 일반 사용자 계정보다 엄격한 기준 적용
▶ ‌지상국 유지보수 등 외부 협력업체 담당자에게 임시 권한 부여 시, 필요 시에만 생성하고 업무
종료 후 즉시 삭제 또는 정지하는 절차 적용
⊙ ‌부여된 접근 권한이 적절한지 정기적으로 검토해야 한다.
▶ ‌부여된 접근 권한을 정기적으로 검토하고, 검토 이력 보관
▶ ‌정기검토 외에도 업무 변경, 퇴직 등 인사이동 발생 시 지체 없이 접근 권한을 변경 또는
말소(계정 삭제/비활성화 포함)

---
<!-- Page 42 -->
42 | 우주 보안 모델 해설 및 적용사례집
▶ ‌검토 결과 권한 과다 부여 등 문제점이 발견된 경우, 원인 분석 및 보완 대책 마련 등이 포함된
조치 절차 수립 및 이행
관련 기준
⊙ ‌CMMC
• ‌3.1.5 (최소권한) : 특정 보안 기능 및 권한이 있는 계정을 포함하여 최소 권한의 원칙을 적용한다.
⊙ ‌K-RMF
• ‌AC-6 (최소권한) : 사용자에게 부여된 과업 및 직책을 수행하는데 필요한 최소한의 권한을 부여한다.
⊙ ‌NIS2
• ‌11.2.1. 관련 기관은 11.1.에서 언급된 접근통제 정책에 따라 네트워크 및 정보시스템에 대한 접근 권한을
제공, 수정, 제거 및 문서화해야 한다.
• ‌11.2.2. 관련 기관은 다음을 수행하여야 한다.
(a) ‌알 필요(Need-to-know), 최소 권한 및 직무 분리 원칙에 기반하여 접근 권한을 할당하고 철회하여야
한다.
(b) 고용의 종료 또는 변경 시 접근 권한이 그에 따라 수정되도록 보장하여야 한다.
(c) 네트워크 및 정보시스템에 대한 접근이 관련자에 의해 승인되도록 보장하여야 한다.
(d) ‌접근권한이 방문자, 공급업체 및 서비스 제공자와 같은 제3자의 접근을 적절하게 다루어야 하며, 특히
범위와 기간 측면에서 접근 권한을 제한함으로써 이를 수행하여야 한다.
(e) 부여된 접근권한의 대장(register)을 유지하여야 한다.
(f) 접근권한 관리에 로깅을 적용하여야 한다.
⊙
‌
ISMS-P
• ‌2.5.1 사용자 계정 관리 : 정보시스템과 개인정보 및 중요정보에 대한 비인가 접근을 통제하고 업무 목적에
따른 접근권한을 최소한으로 부여할 수 있도록 사용자 등록·해지 및 접근권한 부여·변경·말소 절차를
수립·이행하고, 사용자 등록 및 권한부여 시 사용자에게 보안책임이 있음을 규정화하고 인식시켜야 한다.

---
<!-- Page 43 -->

## 제3장 우주 보안모델 해설  | 43

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
AC-03
특수 권한 사용
항목 내용
특수 권한 사용자가 실행할 수 있는 주요 시스템 작업 및 기능25에 대한 시스템
접속을 제한하고 특수 권한으로 실행되는 기능을 감사해야 한다.
목적
특수 권한을 가진 계정의 오용 및 도용으로 인한 시스템의 치명적인 피해를 막고,
모든 관리 활동에 대한 책임 추적성을 확보하기 위함이다.
주요 확인사항
•‌특수 권한 사용자가 실행할 수 있는 주요 시스템 작업 및 기능의 유형을
정의하고, 시스템 접근을 해당 정의된 유형으로만 제한하는 정책 및 절차를
수립하고 있는가?
•‌시스템 내 특권 기능에 대한 접근 및 실행이 인가된 특수 권한 사용자에게만
허용하고, 비 보안 기능 접근은 일반 권한 계정만 허용되도록 통제하고 있는가?
•‌특수 권한으로 실행 시도 또는 실행되는 모든 활동에 대한 감사 기록을
저장하고, 이를 주기적으로 검토하고 있는가?
세부 설명
⊙ ‌특수 권한 사용자가 실행할 수 있는 주요 시스템 작업 및 기능의 유형을 정의하고, 시스템 접근을
해당 정의된 유형으로만 제한하는 정책 및 절차를 수립해야 한다.
▶ ‌특수 권한(Admin, Root 등)이 필요한 주요 시스템 작업 및 기능(예: 위성 제어 명령 발송, 시스템
환경 설정 변경, 사용자 권한 부여/회수 등)의 유형과 범위를 명확히 정의한 정책을 수립하고
공식적으로 승인을 득해야 함
특수 권한(예시)
• 관리자 권한(Root, Administrator, admin, sys, system, sa 등 최상위 권한)
• 배치프로그램 실행을 위하여 부여된 권한
• 보안시스템 관리자 권한
• 계정 생성 및 접근권한을 설정할 수 있는 권한 등
▶ ‌정의된 유형의 작업에 대해서만 특수 권한 계정의 접근 허용 및 특수 권한 계정의 생성, 부여,
사용 및 회수 절차 수립
25	 ‌작업 및 기능 : 사용자가 시스템에 특정 요청을 보내 수행할 수 있는 작업(예: 생성, 조회, 수정, 삭제 등의 데이터 처리 작
업) 및 작업을 처리하는 기능

---
<!-- Page 44 -->
44 | 우주 보안 모델 해설 및 적용사례집
특수 권한 관리 강화 방안(예시)
•‌최소한의 인원에게만 부여될 수 있도록 공식적인 권한 신청 및 승인 절차를 수립하되 일반 사용자
계정·권한 발급 절차보다 엄격한 기준 적용 (ex) 임원 또는 보안책임자 필수적 승인 등)
•‌관리자 권한의 경우 예외조치 최소화, 이상 행위에 대한 모니터링 강화 등 관리 강화
•‌퇴직 및 직무 변경 시 관리자 권한은 즉시 회수하도록 해야 하며 정기적인 검토를 통해 불필요한
관리자 계정을 삭제할 수 있도록 관리
•‌관리자가 사용하는 단말은 IP 및 MAC 주소를 통해 접근제어 적용
⊙ ‌시스템 내 특권 기능에 대한 접근 및 실행이 인가된 특수 권한 사용자에게만 허용하고, 비 보안 기능
접근은 일반 권한 계정만 허용되도록 통제해야 한다.
▶ ‌위성 제어 서버나 임무 시스템의 특권 기능은 인가된 특수 권한 사용자에게만 접근이 허용되도록
접근 통제 리스트(ACL) 또는 특권 접근 관리(PAM) 시스템 등을 활용하여 기술적 통제 적용
사용자 계정 권한별 차등 부여 시 고려사항(예시)
•‌불필요하거나 과도하게 중요정보에 접근하지못하도록 권한 세분화
•‌우주시스템, IT정보 시스템에 대한 접근 권한은 업무 수행 목적에 따라 최소한의 범위로 업무
담당자에게 차등 부여
•‌권한 부여 또는 변경 시 승인 절차 등을 통하여 적절성 검토 수행 등
▶ ‌특권 접근 관리(PAM) 시스템 적용할 수 없을 시 계정별 실행 프로그램 화이트리스팅 적용
▶ ‌[Windows 환경] AppLocker 또는 그룹 정책 개체(GPO)를 사용하여, 특수 권한 계정
프로필에서는 시스템 관리(MMC, PowerShell 등)에 필요한 파일 외의 모든 실행 파일(EXE,
DLL 등)의 실행 차단 적용
▶ ‌[Linux 환경] SELinux나 AppArmor와 같은 MAC(Mandatory Access Control) 도구를
사용하여, 특수 권한 계정의 접근 권한을 시스템 관리 관련 경로 및 파일로만 한정하고, 일반
사용자 애플리케이션 경로(예: /usr/bin/firefox)에 대한 접근 및 실행 권한 거부 적용
⊙ ‌특수 권한으로 실행 시도 또는 실행되는 모든 활동에 대한 감사 기록을 저장하고, 이를 주기적으로
검토해야 한다.
▶ ‌특수 권한 계정으로 실행 시도되거나 실제로 실행된 모든 활동 (로그인/로그아웃, 시스템 설정
변경, 파일 접근, 핵심 명령어 실행 등)에 대해 감사로그 저장 설정
▶ ‌저장된 감사 기록은 위·변조 및 훼손으로부터 안전하게 보호되어야 하며, 우주기업의 보안정책에
따라 보존 기간동안 유지
▶ ‌특수 권한 사용 기록을 정의된 주기에 따라 검토하고, 이상 행위나 정책 위반 징후가 발견되면
신속히 보고 및 조치하는 절차 이행

---
<!-- Page 45 -->

## 제3장 우주 보안모델 해설  | 45

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ ‌CMMC
• ‌3.1.2 (거래 및 기능통제) : 권한이 있는 사용자가 실행할 수 있는 거래 및 기능의 유형에 대한 시스템
접속을 제한한다.
• ‌3.1.6 (권한이 없는 계정 사용) : 비보안 기능(nonsecurity functions)에 접근할 때 권한이 없는 계정이나
역할을 사용한다.
• ‌3.1.7 (특권 기능) : 권한이 없는 사용자가 특권 기능(privileged functions)을 실행하는 것을 방지하고,
이러한 기능의 실행을 감사 로그에 기록해야 한다.
⊙ ‌K-RMF
• ‌AC-6-2 (최소권한 : 특별권한이 없는 사용자의 특별권한 기능 실행 금지) : 특별권한이 없는 사용자가 보안
기능을 비활성화, 우회 및 변경하는 등의 특별권한이 필요한 기능의 실행을 금지해야 한다.
• ‌AC-6-6 (최소권한 : 특별권한 계정의 일반용도 사용통제) : 조직이 지정한 보안 기능 또는 보안 관련
정보의 접근권한을 가진 사용자가 보안과 관련 없는 일반 기능에 접근하는 것을 통제하며, 일반 기능에
접근할 때에는 일반 사용자 계정을 사용해야 한다.
• ‌AC-6-10 (최소권한 : 특별권한 수준의 소프트웨어 실행) : 조직이 지정한 소프트웨어가 실행하는
사용자보다 높은 권한으로 실행되는 것을 금지해야 한다.
⊙ ‌NIS2
• ‌11.3 (특수 권한 계정 및 시스템 관리 계정) : (b) 설치, 구성, 관리 또는 유지보수와 같이 오직 시스템 관리
운영에만 사용되도록 특정 계정을 설정해야 한다.
• ‌(c) 시스템 관리 권한을 가능한 가장 높은 수준으로 개별화하고 제한해야 한다.
• ‌(d) 시스템 관리 계정이 오직 시스템 관리 시스템에 접속하기 위해서만 사용되도록 규정해야 한다
⊙
‌
ISMS-P
• ‌2.5.5. 특수계정 및 권한관리 : 정보시스템 관리, 개인정보 및 중요정보 관리 등 특수 목적을 위하여
사용하는 계정 및 권한은 최소한으로 부여하고 별도로 식별하여 통제하여야 한다.

---
<!-- Page 46 -->
46 | 우주 보안 모델 해설 및 적용사례집
AC-04
정보흐름 통제
항목 내용
시스템 내부 및 시스템 간 정보흐름을 통제해야 한다.
(중요정보의 인터넷 평문전송, 조직간 정보전송 통제 등)
목적
정보가 시스템 내부나 외부로 이동하는 경로를 엄격하게 관리하여 조직의 중요
정보를 보호하기 위함이다.
주요 확인사항
y 중요 정보가 오가는 흐름을 통제하기 위한 정책과 절차를 수립되어 있는가?
y ‌중요 정보를 주고받는 시스템, 사람, 장치 등 정해진 출발 지점과 도착 지점이
명확하게 식별 및 관리되고 있는가?
y ‌중요 정보 흐름 통제 변경 시 관리 책임자의 승인을 득하고 주기적으로 변경
내용을 검토하고 있는가?
세부 설명
⊙ ‌중요 정보가 오가는 흐름을 통제하기 위한 정책과 절차를 수립해야 한다.
▶ ‌흐름 통제 정책은 정보의 특성, 신원 및 권한, 상황적 조건 및 경로를 기반하여 경계 보호
장치(예: 게이트웨이, 라우터, 방화벽 등)에서 흐름을 통제하도록 설정
• ‌데이터 특성 : 허가된 파일형식만 전송 허용
• ‌신원 및 권한 : 특정 직무나 역할을 수행하는 인가된 사용자 및 프로세스만이 정보 전송 허용
• ‌상황적 조건 : 특정 시간대 또는 특정 위치(승인받은 IP 또는 장치)만 정보 전송 허용
▶ ‌중요 정보를 외부 기관/기업에 전송 또는 인터넷을 통해 전송될 경우, 반드시 구간 암호화(예:
TLS(Transport Layer Security) 1.2 이상(신규시스템은 1.3 이상 권고) 또는 IPsec VPN,
SFTP 등)를 적용하도록 정책 수립
▶ ‌중요 정보를 전송하는 데 사용되는 암호화 통신 프로토콜(예: HTTPS, SFTP) 외 안전하지 않은
모든 프로토콜(예: FTP, Telnet 등 보안 취약 프로토콜)은 방화벽(Firewall) 및 라우터(Router)
ACL에서 차단 적용
▶ ‌수립한 통제 정책은 방화벽 등 보안 장비에 적용하고, 위성 제어망 등 핵심 영역은 일방향
전송장치 또는 방화벽 등을 이용해 논리적 분리 적용
⊙ ‌중요 정보를 주고받는 시스템, 사람, 장치 등 정해진 출발 지점과 도착 지점 식별 및 관리해야 한다.
▶ ‌중요 정보 흐름에 대해 출발 시스템(IP), 도착 시스템(IP), 통신 목적, 통신 주기, 통제 책임자,
적용되는 보안 통제 방법 등 중요 정보 흐름 현황을 파악하여 문서화

---
<!-- Page 47 -->

## 제3장 우주 보안모델 해설  | 47

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌파악한 중요 정보 흐름은 관리자 승인을 득하고, 주기적으로 검토하여 최신화 유지
⊙ ‌중요 정보 흐름 통제 변경 시 관리 책임자의 승인을 득하고 주기적으로 변경 내용을 검토해야 한다.
▶ ‌중요 정보 흐름 통제 정책(예: 중요 정보 흐름에 대한 방화벽 차단/허용 정책 등) 변경 시 관리
책임자의 승인 후 변경
▶ ‌중요 시스템 도입/변경 시 중요 정보 흐름 현황 및 통제 정책의 일치 여부 점검
관련 기준
⊙ ‌CMMC
• ‌3.1.3 (CUI 흐름통제) : 승인된 권한에 따라 CUI 흐름을 통제한다.
⊙ ‌K-RMF
• ‌AC-3 (정보흐름 통제) : 조직이 지정한 정보흐름 통제정책을 적용하여 시스템 경계범위 내부에서의
정보흐름을 통제해야 한다.
⊙ ‌ISMS-P
• ‌1.2.2 현황 및 흐름분석 : 관리체계 전 영역에 대한 정보서비스 및 개인정보 처리 현황을 분석하고 업무
절차와 흐름을 파악하여 문서화하며, 이를 주기적으로 검토하여 최신성을 유지하여야 한다.

---
<!-- Page 48 -->
48 | 우주 보안 모델 해설 및 적용사례집
AC-05
직무 분리
항목 내용
개인의 직무를 분리하고 이에 따라 시스템의 접근권한을 부여해야 한다.
목적
권한 오·남용으로 인한 잠재적인 피해를 예방하기 위하여 주요 직무에 대한
책임과 권한을 분리하여 적용함으로써, 독단적인 권한 행사나 실수로 인한 시스템
피해를 방지하기 위함이다.
주요 확인사항
y ‌권한 오·남용 등으로 인한 잠재적인 피해 예방을 위해 직무 분리 기준에 대한
정책 및 절차를 수립하여 적용하고 있는가?
y ‌시스템의 관리, 운영, 보안 등 핵심 직무에 대해 권한 집중에 따른 보안 위험을
분석하고, 상호 검토가 가능하도록 책임과 권한을 체계적으로 분리하여
운영하고 있는가?
y ‌직무 분리가 어려운 경우 직무자 간 상호 검토, 상위관리자 정기 모니터링 및
변경사항 승인, 책임추적성 확보 방안 등의 보완통제를 마련하고 있는가?
세부 설명
⊙ ‌권한 오·남용 등으로 인한 잠재적인 피해 예방을 위하여 직무 분리 기준에 대한 정책 및 절차를
수립하여 적용해야 한다.
▶ ‌직무 분리는 우주기업의 사이버보안 정책 또는 인사규정에 포함되어야 하며, 예외 상황을
허가하는 절차에는 최종 승인자(예: 보안 책임자 또는 임무 관리자)가 공식적으로 지정되어야 함
▶ ‌예시: 위성 관제 담당자와 그 명령을 위성으로 전송하는 최종 승인자는 동일한 사람으로
지정하면 안되며, 직원 개개인이 아니라 관제 운용, IT 보안, 위성 시스템 개발 등 업무 역할(Job
Role)을 기준으로 작성
⊙ ‌시스템의 관리, 운영, 보안 등 핵심 직무에 대해 권한 집중에 따른 보안 위험을 분석하고, 상호
검토가 가능하도록 책임과 권한을 체계적으로 분리하여 운영해야 한다.
▶ ‌개인이 단독으로 실행할 경우 시스템 운영에 치명적인 영향을 미치거나 중요 정보를 유출/변조/
삭제할 수 있는 핵심 직무를 정의
▶ ‌식별된 핵심 직무의 권한이 한 개인에게 집중되었을 때 발생할 수 있는 보안 위협(예: 개발자가
직접 운영 DB 수정 시 로그 삭제 가능성 등)을 분석
▶ ‌분석한 위험을 바탕으로 겸직 금지가 필요한 직무를 식별하고, 이에 대한 직무 분리 기준을
수립하여 문서화
▶ ‌정의된 직무분리 기준에 따라 시스템 접근 권한을 할당

---
<!-- Page 49 -->

## 제3장 우주 보안모델 해설  | 49

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
직무 분리 기준(예시)
y ‌위성 및 지상국 시스템 개발과 위성 운영 직무 분리
y ‌위성 제어 명령 발송 권한자와 원격 상태감시 담당자 직무 분리
y ‌우주시스템 보안업무와 우주시스템(예: 위성제어시스템, 탑재체제어시스템 등) 운영직무 분리
⊙ ‌직무 분리가 어려운 경우 직무자 간 상호 검토, 상위관리자 정기 모니터링 및 변경사항 승인,
책임추적성 확보 방안 등의 보완통제를 마련해야 한다.
▶ ‌위성 관제에 사용되는 암호키를 생성하고 관리하는 담당자는 해당 키를 사용하여 실제 암호화
통신을 수행하거나 위성을 제어하는 위성시스템 관리 권한을 가질수 없도록 직무 분리
▶ ‌직무 분리가 적용되지 않은 직무 수행자가 수행하는 모든 중요 활동에 대해 상세한 감사
로그(활동을 한 사람, 시간, 내용, 시스템 위치가 모두 포함)를 별도의 로그서버 또는 임의
위변조가 되지 않는 저장장치에 저장
▶ ‌직무 분리 예외가 적용된 직원의 시스템 활동(로그)에 대해 상위 관리자가 주기적인 검토 시행
관련 기준
⊙ ‌CMMC
• ‌3.1.4 (직무분리 : 공모 없이 악의적인 활동의 위험을 줄이기 위해 개인의 직무를 분리한다.
⊙ ‌K-RMF
• ‌AC-5 (직무분리)
① 조직이 지정한 개인의 직무를 분리해야 한다.
② 개인의 직무분리 결과를 작성 및 유지해야 한다.
③ 직무 분리 결과에 따라 시스템의 접근권한을 부여한다.
⊙ ‌NIS2
• ‌1.2. 역할, 책임 및 권한 1.2.5 상충하는 직무(Conficting Duties)와 상충하는 책임 영역은
분리(segregated)되어야 한다.
⊙ ‌ISMS-P
• ‌2.2.2. 직무분리 : 권한 오·남용 등으로 인한 잠재적인 피해 예방을 위하여 직무 분리 기준을 수립하고
적용하여야 한다. 다만 불가피하게 직무 분리가 어려운 경우 별도의 보완대책을 마련하여 이행하여야 한다.

---
<!-- Page 50 -->
50 | 우주 보안 모델 해설 및 적용사례집
AC-06
로그인 시도 실패
항목 내용
일정 기간 동안 연속으로 유효하지 않은 로그인 시도를 제한하고 최대 허용
횟수를 초과하면 자동으로 계정을 잠궈야 한다.
목적
시스템에 무단으로 침입하거나 비밀번호를 추측하려는 자동화된 공격(무작위
대입 공격)으로부터 사용자 계정을 보호하기 위함이다.
주요 확인사항
y ‌연속된 로그인 시도의 최대 허용 횟수, 허용 횟수 초과 시 계정을 자동으로
잠금처리 하거나 접속 시도 지연과 같은 조치를 정의한 정책이 수립되어
있는가?
y ‌계정 잠금 발생 시, 일정기간 동안 잠금 상태로 유지되는지, 또는 인가된
관리자가 수동으로 해제할 때까지 유지되는지 명확히 정의하고, 이에 따라
시스템이 작동하는가?
y ‌불법 로그인 시도가 발생했을 때 사용자에게 경고 메시지를 표시하고, 로그인
실패 이력을 기록 및 감사하며, 관리자에게 이상 징후 알림을 보고하는 체계가
수립되어 있는가?
세부 설명
⊙ ‌연속된 로그인 시도의 최대 허용 횟수, 허용 횟수 초과 시 계정을 자동으로 잠금처리 하거나 접속
시도 지연과 같은 조치를 정의한 정책을 수립해야 한다.
▶ ‌위성제어시스템, 관제 명령 서버 등 핵심 임무 시스템은 로그인 실패 허용 횟수를 가장 엄격하게
적용
▶ ‌일반적인 이메일, 파일 서버 등의 업무 지원 시스템은 핵심 임무 시스템보다 로그인 실패 허용
횟수를 완화하여 적용하거나, 시스템 중요도에 따라 차등 설정
로그인 시도 최대 허용 횟수(예시)
y ‌K-RMF AC-07 (로그인 시도) 서버 연속 3회, 사용자 계정 연속 5회 연속 잘못 입력 시 최소 15분
~ 1시간 계정 잠금
y ‌CMMC AC.-3.1.8 (로그인 시도 실패) 중요 데이터를 처리하는 업무용 컴퓨터에 비밀번호를 3번
연속 잘못 입력 시 30분 계정 잠금

---
<!-- Page 51 -->

## 제3장 우주 보안모델 해설  | 51

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
로그인 실패횟수 제한(Windows OS 예시)
계정 잠금 임계값 (5회) 설정 예시
① 시작 → 실행 → secpol.msc입력 및 실행 → 계정 정책 → 계정 잠금 정책
② “계정 잠금 임계 값” 설정 (아래 그림 예시에서는 5회로 설정)
⊙ ‌계정 잠금 발생 시, 일정 기간 동안 잠금 상태로 유지되는지, 또는 인가된 관리자가 수동으로 해제할
때까지 유지되는지를 명확히 정의하고, 이에 따라 시스템이 작동해야 한다.
▶ ‌정책으로 정한 최대 횟수를 초과하면, 해당 계정은 시스템에서 자동으로 접근이 차단(계정
잠금)되도록 기술적 설정 적용
▶ ‌비밀번호 추측 공격을 지연시키기 위해 실패 횟수가 증가할수록 다음 시도까지의 대기 시간을
점진적으로 증가 시키는 알고리즘을 적용하는 것을 계정 잠금 정책과 병행 적용 고려
• ‌예시 : 최소 5초간 로그인 프롬프트 지연 또는 10초간 로그인 프롬프트 지연
▶ ‌모바일 기기는 분실/도난되어 무단 접근 시도가 발생할 경우를 대비하여, 로그인 실패 횟수(예:
5회, 10회)를 초과하면 해당 장치에 저장된 조직의 정보가 외부로 유출되기 전에 완전 삭제 설정
고려
⊙ ‌불법 로그인 시도가 발생했을 때 사용자에게 경고 메시지를 표시하고, 로그인 실패 이력을 기록 및
감사하며, 관리자에게 이상 징후 알림을 보고하는 체계를 수립해야 한다.
▶ ‌계정 잠금 발생, 또는 특정 IP 주소에서 반복적인 실패 시도가 감지되었을 경우, 이를 불법 로그인
시도로 간주하고 보안 관리자 또는 보안 관제 센터(SOC)에 즉시 실시간 알림(SMS/이메일)을
전송하는 절차 적용

---
<!-- Page 52 -->
52 | 우주 보안 모델 해설 및 적용사례집
불법적 인증시도 (예시)
y 반복 로그인 시도로 인한 계정잠금 시 실시간 알림
y 국외 IP주소 등 등록되지 않은 IP주소에서의 접속 시 차단 및 알림
y 주말, 야간 접속 등 근무시간 외 접속 시 문자 알림
y 관리자 등 특수권한 로그인 시 알림 등
관련 기준
⊙ ‌CMMC
• ‌3.1.8 (실패한 로그온 시도) : 실패한 로그온 시도를 제한한다.
⊙ K-RMF
• ‌AC-7 (로그인 시도 실패)
① ‌일정기간 동안 조직이 지정한 횟수의 연속으로 유효하지 않은 로그인 시도를 제한해야 한다.
② ‌로그인 실패가 최대 허용 횟수를 초과하면 자동으로 다음 중 하나의 조치를 시행해야 한다.

가. 일정 기간동안 계정을 잠금

나. 관리자가 해제할 때 까지 계정을 잠금

다. 조직이 지정한 지연 알고리즘에 따라 로그인 시도 제한

라. 기타 조직이 지정한 방법
• ‌AC-7-1 (로그인 시도 실패 | 모바일 기기 정보 삭제)
‌조직이 지정한 모바일 기기]에서 [조직이 지정한 횟수]의 연속적인 로그인 실패가 발생할 경우 [조직이
지정한 삭제기술 및 요구사항]에 따라 해당 모바일 기기의 정보를 완전삭제해야 한다.
⊙ ISMS-P
• ‌2.5.3. 사용자 인증 : 정보시스템과 개인정보 및 중요정보에 대한 사용자의 접근은 안전한 인증절차와
필요에 따라 강화된 인증방식을 적용하여야 한다. 또한 로그인 횟수 제한, 불법 로그인 시도 경고 등
비인가자 접근 통제방안을 수립·이행하여야 한다.

---
<!-- Page 53 -->

## 제3장 우주 보안모델 해설  | 53

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
AC-07
세션 잠금 및 종료
항목 내용
일정 기간 동안 세션 사용이 없거나 사용자에 의한 세션 잠금 요청이 있을 경우
해당 세션을 잠그고, 세션 종료 조건 발생 시 자동으로 세션을 종료해야 한다.
목적
자리를 비운 사용자 세션을 통해 통제된 중요 정보가 비인가자에게 노출되는 것을
방지하기 위함이다.
주요 확인사항
y ‌시스템이 조직이 지정한 비활성 기간 초과 또는 사용자 요청 시 세션을
자동으로 잠그고, 암호가 적용된 화면보호기 등의 보호 조치를 적용하여
화면정보가 노출되지 않도록 하는가?
y ‌세션 잠금 해제 시, 사용자가 암호나 다중 인증 등의 식별 및 인증 절차를 거쳐
본인임을 재확인하도록 강제하는가?
y ‌운영 연속성을 위해 세션 잠금 규칙 적용이 비효율적이거나 불가능한
시스템(예: 상시 관제 대시보드)을 식별하고, 해당 시스템에 대한 세션 잠금
예외 처리 기준 및 공식 승인 절차를 수립하여 현황을 관리하고 있는가?
세부 설명
⊙ ‌시스템이 조직이 지정한 비활성 기간 초과 또는 사용자 요청 시 세션을 자동으로 잠그고, 암호가
적용된 화면보호기 등의 보호 조치를 적용하여 화면 정보가 노출되지 않도록 적용해야 한다.
▶ ‌일반 업무용 단말기는 비활성 시간을 10분 경과 시 자동으로 암호가 적용된 화면보호기가
적용되도록 설명
※ ‌위성 궤도 감시, 통신 상태 모니터링 등 중단없는 화면 노출이 필요한 시스템은 자동 세션 및
화면보호기 적용을 예외 할 수 있음
▶ ‌잠금/잠금해제 시, 화면에 표시된 위성 명령 로그나 기밀 문서 등의 모든 화면 내용이 비치거나
노출되지 않도록 하여 외부인의 훔쳐보기(Shoulder Surfing)를 방지

---
<!-- Page 54 -->
54 | 우주 보안 모델 해설 및 적용사례집
세션 타임아웃 설정(JSP 예)
web.xml 파일에서 <session-config> 태그를 사용하여 타임아웃을 지정하는 방법 (분단위) 또는
weblogic.xml에서 <session-descriptor> 태그를 사용하여 지정하는 방법 (초단위)
▷<session-descriptor>를 이용해서 600초 타임아웃을 지정하는 예시
⊙ ‌세션 잠금 해제 시, 사용자가 암호나 다중 인증 등의 식별 및 인증 절차를 거쳐 본인임을 재확인하는
절차를 적용해야 한다.
▶ ‌잠금 해제 시에는 반드시 비밀번호 입력 등 사용자 본인임을 확인하는 인증 절차를 거치도록
시스템을 설정하여, 잠금 해제하는 사람이 인가된 사용자임을 확인하도록 설정
※ ‌긴급한 위성 제어 상황이 발생 할 수 있는 환경(예: 위성 관제실 등) 에서는 인증 절차로
인해 대응이 늦어질 수 있기에, 잠금해제 시 인증절차를 간소화 하거나 물리적 보안통제로
대체(관제실을 보호구역으로 지정 및 보호구역 출입자 통제 적용 등)할 수 있음.(NIST SP 800-
100 정보보안 핸드북 참조)
⊙ ‌운영 연속성을 위해 세션 잠금 규칙 적용이 비효율적이거나 불가능한 시스템(예: 상시 관제
대시보드)을 식별하고, 해당 시스템에 대한 세션 잠금 예외 처리 기준 및 공식 승인 절차를 수립하여
현황을 관리해야 한다.
▶ ‌24시간 실시간 위성 모니터링 대시보드, 네트워크 관제/보안 관제 시스템(NOC/SOC) 등 상시
화면 표시가 임무 수행에 필수적이어서 자동 잠금 규칙을 적용할 수 없는 시스템을 공식적으로
식별
▶ ‌식별된 예외 시스템은 보안 책임자 또는 임무 관리자의 공식적인 문서 승인을 거쳐 예외 시스템
목록에 등록하고 현황을 관리

---
<!-- Page 55 -->

## 제3장 우주 보안모델 해설  | 55

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ ‌CMMC
• ‌3.1.10 (세션 잠금) : 비활성 기간 후 데이터에 대한 액세스 및 보기를 방지하려면 패턴 숨김 디스플레이와
함께 세션 잠금을 사용한다.
• ‌3.1.11 (세션 종료) : 정의된 조건이 충족되면 사용자 세션을 자동으로 종료한다.
⊙ ‌K-RMF
• ‌AC-11 (세션 잠금)
① ‌조직이 지정한 기간 동안 세션 사용이 없거나 사용자에 의한 세션 잠금 요청이 있을 경우 해당 세션을
잠가야 한다.
② ‌사용자가 설정된 식별/인증 절차를 통하여 재접속을 할 때까지 세션 잠금을 유지해야 한다.
• ‌AC-12 (세션 종료) : 세션 종료 요청이 있거나 조직이 지정한 세션 종료
• ‌AC-12-1 (세션 종료 | 사용자 통신세션 종료 및 메시지 표시)
① ‌사용자가 인증이 필요한 조직이 지정한 정보 자원에 접근한 이후 사용자 요청에 따라 로그아웃을 할 수
있는 기능을 제공해야 한다.
② 사용자에게 통신 세션이 안전하게 종료되었다는 메시지를 표시해야 한다.
⊙ ‌ISMS-P
• ‌2.6.2 정보시스템 접근 : 서버, 네트워크시스템 등 정보시스템에 접근을 허용하는 사용자, 접근제한 방식,
안전한 접근수단 등을 정의하여 통제하여야 한다.
• ‌2.6.3 응용프로그램 접근 : 사용자별 업무 및 접근 정보의 중요도 등에 따라 응용프로그램 접근권한을
제한하고, 불필요한 정보 또는 중요정보 노출을 최소화할 수 있도록 기준을 수립하여 적용하여야 한다.

---
<!-- Page 56 -->
56 | 우주 보안 모델 해설 및 적용사례집
AC-08
원격 접근통제
항목 내용
승인된 업무 및 사용자에 대해서만 원격접속을 허용하고 원격접속 세션을 암호화
및 모니터링해야 한다.
목적
승인되지 않은 원격접속을 통한 데이터 유출이나 시스템 무단 변경을 방지하여
주요 시스템 및 데이터를 보호하고, 모든 원격 통신을 감시하여 보안 사고를
조기에 탐지하기 위함이다.
주요 확인사항
y ‌원격 접근을 통제하기 위한 공식적인 정책 및 절차를 수립하고 관리하고 있는가?
y ‌원격 접속에 사용되는 단말(PC/노트북)의 보안 상태를 확인하고, 원격 접속 시
다중 인증 등 강력한 사용자 인증 및 암호화 통신을 사용하는가?
y ‌원격 접근 시도 및 수행 내역을 모니터링하고 주기적으로 원격 접속로그를
검토하고 있는가?
세부 설명
⊙ ‌원격 접근을 통제하기 위한 공식적인 정책 및 절차를 수립하고 관리해야 한다.
▶ ‌원격 접속이 필요한 업무, 사용자, 접속 시간 등을 지정하고, 사전 신청 및 책임자 승인, 접속
모니터링 및 사후관리의 3단계 절차를 문서화하여 보안 정책 및 절차에 반영
▶ ‌위성 및 탑재체 제어시스템, 위성 관제 네트워크 등 위성 및 탑재체 운영에 높은 영향을 미치는
고위험 자산은 원격 접근을 원칙적으로 차단하고, 불가피할 경우에만 특정 시간대나 지정된 IP
주소에서만 접근 허용하는 정책 적용
▶ ‌원격 실행이 허용되는 특수 권한 명령(예: 시스템 구성 변경, 서비스 재시작, 위성 제어 명령
등)을 식별하여 목록화하고, 식별된 특수 권한 명령에 대해서는 사전 승인된 사용자만이
원격해서 실행하거나 접근할 수 있도록 해야 함

---
<!-- Page 57 -->

## 제3장 우주 보안모델 해설  | 57

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌원격 접속에 사용되는 단말(PC/노트북)의 보안 상태를 확인하고, 원격 접속 시 다중 인증 등 강력한
사용자 인증 및 암호화 통신을 사용해야 한다.
▶ ‌접속 단말(노트북 등)이 최신 보안 패치, 백신, 개인 방화벽 등 조직의 최소 보안 통제 기준을
만족하는지 점검하고, 기준 미충족 장치의 접속 제한
▶ ‌원격으로 접속하는 모든 사용자에게 다중 인증(최소 2가지 이상의 인증 수단) 적용
▶ ‌모든 원격 접속은 VPN과 같은 암호화 기술(TLS, IPSEC) 적용
⊙ ‌원격 접속 시도 및 수행내역을 모니터링하고 주기적으로 원격 접속로그를 검토해야 한다.
▶ ‌비인가된 자의 원격 접속 시도, 허용되지 않은 시간대 원격 접속 시도, 짧은 시간내 반복되는
로그인 실패 등 원격 접속시 이상행위 탐지 및 대응
▶ ‌원격 접속 중인 모든 활동 내역 (접근 시간, 사용한 명령어, 접속 대상 시스템)에 대한 로그를
저장하고 주기적으로 로그 검토 수행
관련 기준
⊙ ‌CMMC
• ‌AC.L2-3.1.12 (원격 접근 통제) : 원격 접근 세션을 모니터링하고 통제해야 한다.
• ‌AC.L2-3.1.13 (원격 접근 기밀성) : 원격 접근 세션의 기밀성을 보호하기 위해 암호화 메커니즘을
적용해야 한다.
• ‌AC.L2-3.1.14 (원격접속 라우팅) : 관리되는 네트워크 접근통제지점(managed access control
points)을 통해 원격 접근 경로를 구성해야 한다.
• ‌AC.L2-3.1.15 (권한이 있는 원격 접속) : 권한이 있는 명령의 원격 실행과 보안 관련 정보에 대한 원격
접속을 승인한다.
⊙ ‌K-RMF
• ‌AC-15 (원격접속)
① ‌시스템에서 허용하는 원격접속 유형을 식별하고, 원격접속에 대한 사용 제한사항, 환경 설정 및 연결
요구사항, 구현 지침 등을 수립하고 유지·관리해야 한다.
② 시스템에 원격접속을 허용하기 전에 인가해야 한다.
• ‌AC-15-1 (원격접속 | 원격접속 모니터링 및 통제) : 원격접속을 모니터링하고 통제해야 한다.
• ‌AC-15-2 (원격접속 | 암호화를 통한 기밀성과 무결성 보호) : 원격접속 세션의 기밀성과 무결성을
보호하기 위해 암호화 메커니즘을 구현해야 한다.
• ‌AC-15-3 (원격접속 | 접근통제 지점 관리) : 조직이 지정한 개수의 관리되는 네트워크 접근통제지점을
통해서 원격접속 경로를 구성해야 한다.
• ‌AC-15-6 (원격접속 | 연결종료 / 접속 비활성화) : 조직이 지정한 기간 내에 시스템과 연결된 원격접속을
종료하거나 비활성화할 수 있는 기능을 제공해야 한다.
⊙ ‌ISMS-P
• ‌2.6.6 원격접근 통제 : 보호구역 이외 장소에서의 정보시스템 관리는 원칙적으로 금지하고,
재택근무·장애대응·원격협업 등 불가피한 사유로 허용하는 경우 책임자 승인, 접근 단말 지정, 접근
허용범위 및 기간 설정, 강화된 인증, 구간 암호화, 접속단말 보안(백신, 패치 등) 등을 수립·이행해야 한다.

---
<!-- Page 58 -->
58 | 우주 보안 모델 해설 및 적용사례집
AC-09
무선 접속
항목 내용
시스템에 무선접속 시 승인받은 사용자/기기 인증을 수행하고 통신세션을
암호화해야 한다.
목적
비인가된 사용자가 무선 경로를 통해 위성제어시스템에 접근하는 것을 방지하고,
무선 통신 구간에서 전송되는 정보의 기밀성 및 무결성을 보호하기 위함이다.
주요 확인사항
y ‌무선 접속을 위한 사용 제한사항, 환경 설정, 무선 접속 정책이 수립되어
있는가?
y ‌무선 네트워크 접속시 인증을 수행하고 통신 세션을 암호화하는 등 보호대책을
수립 및 이행하고 있는가?
y ‌허가받지 않은 무선 AP 탐지 및 차단 등 비인가 무선 네트워크 방지 대책을
수립하고 있는가?
y ‌시스템 내 내장된 무선 네트워크 기능을 사용하지 않는 경우, 배포 및 설치 전에
비활성화하고 있는가?
세부 설명
⊙ ‌무선 접속을 위한 사용 제한사항, 환경 설정, 무선 접속 정책을 수립해야 한다.
▶ ‌중요정보를 처리하는 지상국이나 관제 구역 내에서 무선 네트워크를 사용해야 하는 경우, 반드시
무선 AP 설치 및 사용에 대한 공식 승인 절차 수립 및 이행
▶ ‌무선네트워크 장치(AP 등) 목록을 관리하고 인가된 임직원 및 승인된 장치만이 무선 네트워크를
사용할 수 있도록 사용 신청 및 해지 절차를 수립
▶ ‌방문객용 Wi-Fi와 관제망 또는 업무망과는 VLAN(Virtual Local Area Network) 또는 방화벽
등을 사용하여 논리적으로 완벽하게 분리하고, 방문객 망에서는 내부 자산에 접근할 수 없도록
하는 무선 접속 정책 수립
⊙ ‌무선 네트워크 접속시 인증을 수행하고 통신 세션을 암호화하는 등 보호대책을 수립 및 이행해야
한다.
▶ ‌WPA3/WPA2-Enterprise를 적용하여 높은 수준의 암호화 및 사용자 인증 적용
▶ ‌무선 네트워크에 접속을 허용하는 특정 IP 또는 특정 단말 MAC 주소를 등록하거나 무선 AP에
접근가능한 IP 대역을 제한하여(ACL 설정) 비인가 무선 네트워크 접속 차단

---
<!-- Page 59 -->

## 제3장 우주 보안모델 해설  | 59

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
무선 네트워크 허용 단말 MAC 주소 등록 화면 예시
▶ ‌무선 네트워크 이름(SSID, Service Set Identifier) 숨김 기능을 설정하여 무선 네트워크의 무단
접근 방지
▶ ‌무선 AP 관리자 페이지 접근에 대한 IP를 제한하여 무선 AP 보안 강화
⊙ ‌허가받지 않은 무선 AP 탐지 및 차단 등 비인가 무선 네트워크 대책을 수립해야 한다.
▶ ‌비인가 무선 네트워크(예: 직원이 무단으로 설치한 비인가 AP(Rogue AP) 또는 애드혹
네트워크(Ad-hoc 네트워크)에 대한 탐지 및 차단, 비인가된 단말의 무선 접속을 탐지 및
차단하기 위해 무선침입방지시스템(WIPS, Wireless Intrusion Prevention System)을 설치/
운영
WIPS(무선 침입방지시스템) 개념도

---
<!-- Page 60 -->
60 | 우주 보안 모델 해설 및 적용사례집
▶ ‌무선침입방지시스템(WIPS) 구축이 어려운 경우, 보안 담당자가 주기적으로 비인가 AP 설치
여부 점검 필요
⊙ ‌시스템 내 내장된 무선 네트워크 기능을 사용하지 않는 경우, 배포 및 설치 전에 비활성화해야 한다.
▶ ‌서버, 워크스테이션, 네트워크 장비, 프린터 등 시스템 구성요소에 내장된 Bluetooth나 Wi-Fi
등의 무선 통신 기능을 사용하지 않을 경우, 해당 장치의 배포 및 설치 전에 해당 기능 비활성화
설정
관련 기준
⊙ ‌CMMC
• ‌AC.L2-3.1.17 무선 접속 보호 : 인증 및 암호화를 사용하여 무선접속을 보호한다
• ‌AC.L2-3.1.16 무선 접속 승인 : 이러한 연결을 허용하기 전에 무선 접속을 승인한다
⊙ ‌K-RMF
• ‌AC-16 무선접속
1. ‌무선접속을 위한 사용 제한사항, 환경설정 및 연결 요구사항, 구현지침을 수립하고 유지·관리해야 한다.

## 2. 시스템에 무선접속을 허용하기 전에 인가해야 한다.

• ‌AC-16-1 무선접속 | 인증 및 암호화
[사용자 인증 그리고/또는 기기 인증]과 데이터 암호화를 통하여 무선접속을 보호해야 한다.
⊙
‌
ISMS-P
• ‌2.6.5 무선 네트워크 접근 : 무선 네트워크를 사용하는 경우 사용자 인증, 송수신 데이터 암호화, AP
통제 등 무선 네트워크 보호대책을 적용하여야 한다. 또한 AD Hoc 접속, 비인가 AP 사용 등 비인가 무선
네트워크 접속으로부터 보호대책을 수립·이행하여야 한다.

---
<!-- Page 61 -->

## 제3장 우주 보안모델 해설  | 61

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
AC-10
모바일 기기 연결 통제
항목 내용
승인된 모바일 기기에 대해서만 시스템의 연결을 허용하고 모바일 기기에서
정보를 암호화해야 한다.
목적
모바일 기기를 통한 지상국 및 위성 제어시스템 비인가 접근을 방지하고 모바일
기기나 휴대용 저장장치에 저장되는 중요 정보를 암호화하여 기밀성을 확보하기
위함이다.
주요 확인사항
y ‌업무상 사용하는 모바일 기기(노트북, 가상PC, 태블릿 등)의 허용 기준, 업무
범위, 승인 절차, 기기 보안 설정 등에 대한 정책 및 절차를 수립하고, 허가된
모바일 기기만 내부 정보시스템 접속을 허용하는가?
y ‌업무용 모바일 기기를 통해 중요정보가 유출되는 것을 방지하기 위해 자료공유
프로그램 사용 금지, 무선망 이용 통제 등의 정책을 수립 및 이행하고 있는가?
y ‌업무용 모바일 기기의 분실이나 도난에 대비하고 저장된 중요정보를 보호하기
위해 안전한 암호화 메커니즘을 적용하고 있는가?
y ‌업무용 모바일 기기에 대한 접근통제 대책의 적절성에 대하여 주기적으로
점검하고 있는가?
세부 설명
⊙ ‌업무상 사용하는 모바일 기기(노트북, 가상PC, 태블릿 등)의 허용 기준, 업무 범위, 승인 절차,
모바일 기기 보안 설정 등에 대한 정책 및 절차를 수립하고, 허가된 모바일 기기만 내부 정보시스템
접속을 허용해야 한다.
▶ ‌업무용 모바일 기기 보안정책 및 절차 수립 시 아래의 내용이 고려되어야 함
• ‌업무용 모바일 기기 허용기준 정의
• ‌업무용 모바일 기기를 이용해 처리할 업무 범위 정의(예: 위성체 및 탑재체 모니터링/제어 업무를
제외한 일상 행정처리 업무 등)
• ‌업무용 모바일 기기 사용 시 승인 절차 및 방법
• ‌업무망 연결 시 인증 방안 : 기기 인증서 기반 인증, MAC 인증 등
• ‌백신 설치, 보안프로그램 설치 등 업무용 단말기 사용에 따른 보안 설정 정책
• ‌업무용 단말기 사용에 따른 보안 설정 정책 및 오·남용 모니터링 대책 등
⊙ ‌업무용 모바일 기기를 통해 중요정보가 유출되는 것을 방지하기 위해 자료공유 프로그램 사용 금지,
무선망 이용 통제 등의 정책을 수립 및 이행해야 한다.
▶ ‌업무용 모바일 기기는 사용 장치 등록, 안전한 사용, 사용 종료 후 저장매체 완전삭제까지 사용의
전 단계를 포괄하는 정보유출 방지 정책을 적용

---
<!-- Page 62 -->
62 | 우주 보안 모델 해설 및 적용사례집
업무용 모바일 기기 정보유출 방지 정책(예시)
y ‌우주 시스템 및 네트워크에 연결되는 모든 모바일 기기는 고유 식별자(예: MAC주소, 일련번호
등)를 기반으로 보안 부서의 사용승인을 득한 후 업무용 모바일 기기 관리대장에 등록하는 절차
마련
y ‌P2P 프로그램, 상용 웹메일, 웹하드, 메신저, SNS 서비스 등을 통하여 고의·부주의로 인한
개인정보 및 중요정보의 유·노출 방지하기 위한 보안기준 마련
y ‌WPA3/WPA2-Enterprise 등 보안 프로토콜이 적용된 무선망 이용 등
y ‌업무용 사용이 종료된 장치의 저장매체에 대한 자료 완전삭제 절차 마련
⊙ ‌업무용 모바일 기기의 분실이나 도난에 대비하고 저장된 중요정보를 보호하기 위해 안전한 암호화
메커니즘을 적용해야 한다.
▶ ‌업무용 모바일 기기의 분실도난 시 비인가자에 의한 중요 정보 유출을 원천 차단하기 위해, 기기
접근통제(화면 잠금) 및 데이터 암호화 설정뿐만 아니라 MDM 등을 활용한 원격 제어 기능을
포함한 기술적 보호조치 적용
업무용 모바일 기기 분실·도난 대책(예시)
y ‌비밀번호, 패턴, PIN, 지문, 홍채 등을 사용하여 화면 잠금 설정
y ‌디바이스 암호화 기능 등을 사용하여 애플리케이션, 데이터 등 암호화
y ‌모바일 기기 제조사 또는 이동통신사에서 제공하는 기능을 이용한 원격 잠금, 원격 데이터
삭제(킬스위치 서비스 등)
y ‌중요정보를 처리하는 모바일 기기는 MDM(Mobile Device Management) 등 모바일 단말 관리
프로그램을 설치하여 원격 잠금, 원격 데이터 삭제, 접속통제 등
⊙ ‌업무용 모바일 기기에 대한 접근통제 대책의 적절성에 대해 주기적으로 점검해야 한다.
▶ ‌업무용 단말기 신청·승인, 등록·해제, 기기인증 이력 점검
▶ ‌모바일 기기에 대한 접근 통제 및 보안 설정(암호화 여부, OS 패치 등)이 적절하게 유지되고
있는지 주기적 점검

---
<!-- Page 63 -->

## 제3장 우주 보안모델 해설  | 63

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ ‌CMMC
• ‌3.1.18 (모바일 기기 연결) : 모바일 기기 연결을 통제하여야 한다.
• ‌3.1.19 (모바일에서 중요정보 암호화) : 모바일 기기 및 모바일 컴퓨팅 플랫폼에 저장된 CUI를
암호화하여야 한다.
• ‌3.1.21 (휴대용 저장장치 사용) : 외부 시스템에서는 휴대용 저장장치(portable storage devices)의
사용을 제한한다.
⊙ K-RMF
• ‌AC-17 (모바일 기기 접근통제)
① ‌조직에서 통제하는 모바일 기기에 대한 사용 제한사항, 환경설정 및 연결 요구사항, 구현지침을
수립하고 유지·관리해야 한다.
② 인가받은 모바일 기기에 대해서만 시스템의 연결을 허용해야 한다.
• ‌AC-17-2 (모바일 기기 접근통제 | 모바일 기기 암호화 기술) : 조직이 지정한 모바일 기기의 기밀성과
무결성 보호를 위해 전체 장치 암호화 또는 컨테이너 암호화 기술을 사용해야 한다.
• ‌AC-18 (인가범위 외 시스템 사용) : 인가범위 외 시스템을 운영하는 기관과 협약을 맺고, 조직의 시스템
접속을 인가받은 사용자가 다음 사항을 수행할 수 있게 해야 한다.
① 인가범위 외 시스템을 사용하여 조직의 시스템으로 접근
② 인가범위 외 시스템을 사용하여 정보를 처리ㆍ저장ㆍ전송
• ‌AC-18-2 (인가범위 외 시스템 사용 | 휴대용 저장매체) : 인가받은 사용자가 인가범위 외 시스템에서
조직이 관리하는 휴대용 저장매체를 사용하는 것을 [제한 또는 금지]해야 한다.
⊙ ISMS-P
• ‌2.10.6 업무용 단말기기 보안 : PC, 모바일 기기 등 단말기기를 업무 목적으로 네트워크에 연결할 경우
기기 인증 및 승인, 접근 범위, 기기 보안설정 등의 접근통제 대책을 수립하고 주기적으로 점검하여야 한다.

---
<!-- Page 64 -->
64 | 우주 보안 모델 해설 및 적용사례집
26	 ‌작업 및 기능 : 사용자가 시스템에 특정 요청을 보내 수행할 수 있는 작업(예: 생성, 조회, 수정, 삭제 등의 데이터 처리 작
업) 및 작업을 처리하는 기능
AC-11
외부 연결 통제
항목 내용
외부 시스템과26 조직 내부시스템에 대한 연결 및 사용을 확인하고 통제해야
한다.
목적
외부 시스템과의 연결 경로를 식별·인가하고 사용을 통제·모니터링함으로써,
조직 시스템 경계를 보호하고 중요정보에 대한 비인가 접근 및 유출을 방지하기
위함이다.
주요 확인사항
y ‌시스템에 연결이 허용된 외부 시스템 및 해당 연결 사용을 식별하고 현황을
관리하고 있는가?
y ‌외부 시스템과의 연결을 승인된 방식(예: VPN, 인증서, 특정 IP 주소 접근
등)으로만 허용하는 메커니즘을 적용하고 있는가?
y ‌외부 시스템과의 연결 및 사용 현황을 지속적으로 모니터링하고 통제하고
있는가?
세부 설명
⊙ ‌시스템에 연결이 허용된 외부 시스템 목록 및 해당 연결 사용을 식별하고 현황을 관리해야 한다.
▶ ‌우주기업 보안 관리 영역 밖에 있는 모든 시스템을 “인가범위 외 시스템”으로 정의하고, 이
시스템이 조직 시스템에 접근하기 위한 최소한의 보안 요건(예: 조직의 시스템에 원격 접속 시
다중 인증 적용, 원격 접속 시 암호화 통신(VPN 등) 적용 등) 정의
▶ ‌중요정보를 처리, 저장, 전송하는 모든 외부 시스템(협력업체 서버, 클라우드 서비스, 원격
유지보수 장비 등)을 식별
• ‌식별 사항: 내부 시스템명, 접속목적, 외부 조직명, 외부 시스템명, 접속 사용자, 접속 허용 기간,
연결 방식(VPN, 전용회선 등) 등
접속 허용 외부 시스템 관리대장 예시
▶ ‌식별된 외부 연결 목록은 주기적으로 검토 및 업데이트 수행

---
<!-- Page 65 -->

## 제3장 우주 보안모델 해설  | 65

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌외부 시스템과의 연결을 승인된 방식(예: VPN, 인증서, 특정 IP 주소 접근 등)으로만 허용하는
메커니즘을 적용해야 한다.
▶ ‌외부 연결은 반드시 암호화 통신(VPN 등)을 적용하고 암호화 통신이 어려울 경우 전송 데이터
암호화를 적용해야 하며, 접속 시 다중 인증(MFA)를 적용. 또한, IP 주소 기반 통제(ACL) 또는
클라이언트 인증서 기반 인증을 병행 적용하는것을 고려
※ ‌IP 주소 기반 통제(ACL)는 고정 IP를 사용하는 환경(지사, 협력사 사무실 등)에 적합하며,
클라이언트 인증서 기반 인증은 이동이 잦은 환경(재택근무, 출장 등)에 적합
⊙ ‌외부 시스템과의 연결 및 사용 현황을 지속적으로 모니터링하고 통제해야 한다.
▶ ‌VPN 게이트웨이, 경계 방화벽 등 외부 연결이 발생하는 모든 지점에서 접속 시도, 연결
성공/실패, 데이터 전송량에 대한 상세한 감사 로그를 안전한 방법(별도 로그 수집서버 등)으로
저장하고, 이를 모니터링
▶ ‌모니터링 중 이상행위(예: 접속 허용기간 외 접속 시도, 단시간 내 과다 접속 시도(예: 10회
이상/1초) 등) 발견 시 해당 출발지 IP 차단 적용
• ‌윈도우 시스템에서 접속시도 및 연결 성공/실패 감사 설정 예시
- ‌윈도우 시스템에서 관리자 권한으로 로그인하여 secpol.msc 실행 후 로컬정책 → 감사정책
성공,실패 설정
윈도우 시스템의 감사로그 설정 화면 예시
▶ ‌보안 관리자는 주기적으로 외부 시스템 접속 관련 로그를 검토 수행

---
<!-- Page 66 -->
66 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ ‌CMMC
• ‌3.1.20 (외부 연결 중요 데이터) : 외부 시스템 대한 연결과 사용을 확인하고 제어/제한한다.
• ‌3.5.3 (다중 인증)
[c] 특수 권한 계정에 대한 네트워크 접근 시 다중 인증 구현
[d] 비특권 계정에 대한 네트워크 접근 시 다중 인증 구현
[예시] 내부 네트워크에 대한 VPN 접속 시 다중 인증(MFA) 활성화
⊙ ‌K-RMF
• ‌AC-18 (인가범위 외 시스템 사용) : 인가범위 외 시스템을 운영하는 기관과 협약을 맺고, 조직의 시스템
접속을 인가받은 사용자가 다음 사항을 수행할 수 있게 해야 한다.
① 인가범위 외 시스템을 사용하여 조직의 시스템으로 접근
② 인가범위 외 시스템을 사용하여 정보를 처리ㆍ저장ㆍ전송
⊙ ‌ISMS-P
• ‌2.6.1 네트워크 접근 : 네트워크에 대한 비인가 접근을 통제하기 위하여 IP관리, 단말인증 등 관리절차를
수립·이행하고, 업무목적 및 중요도에 따라 네트워크 분리(DMZ, 서버팜, DB존, 개발존 등)와 접근통제를
적용하여야 한다.

---
<!-- Page 67 -->

## 제3장 우주 보안모델 해설  | 67

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
AC-12
공공 정보 통제
항목 내용
공개적으로 접근 가능한 시스템에 정보를 게시하기 전에 해당 내용을 검토하여
중요정보가 게시되지 않도록 한다.
목적
공개 시스템(예: 웹사이트, 공개 포털)을 통해 중요정보 또는 기타 비공개
정보(Nonpublic Information)가 외부로 유출되거나 비인가자에게 노출되는
것을 방지하기 위함이다
주요 확인사항
y ‌공개적으로 접근 가능한 시스템에 정보를 게시하는 운영 주체(홍보 또는 사업
담당부서)는 콘텐츠를 게시하기 전, 중요정보가 포함되어 있지 않은지 확인하는
검토 및 승인 절차 수립 및 이행하고 있는가?
y ‌공개시스템에 정보를 게시하는 담당자가 지정되어 있으며, 해당 담당자에게
비공개 정보 통제에 대한 교육이 시행되고 있는가?
y ‌이미 게시된 콘텐츠에 중요정보가 포함되어 있는지 정기적으로 검토하고,
발견 시 즉시 삭제 및 수정 등 부적절한 게시를 해결하기 위한 절차가 마련되어
있는가?
세부 설명
⊙ ‌공개적으로 접근 가능한 시스템에 정보를 게시하는 운영 주체(홍보 또는 사업 담당부서)는 콘텐츠를
게시하기 전, 중요정보가 포함되어 있지 않은지 확인하는 검토 및 승인 절차 수립 및 이행해야 한다.
▶ ‌공개적으로 접근 가능한 시스템에 콘텐츠를 게시하기 전에, 해당 내용에 중요정보 및 비공개
정보가 포함되어 있지 않은지를 확인하는 검토 절차 수립 및 이행
• ‌데이터, 수치 내용의 정확성 검증
• ‌중요정보 및 비공개 정보 포함 여부 식별 : 영업비밀, IP가 포함된 네트워크 구성도 등 공개시
문제가 될 수 있는 요소 식별
• ‌법적인 이슈 발생 가능 여부 검토
▶ ‌게시 정보의 보안성 검토 절차는 게시 검토 및 승인 절차에 포함되어야 함
⊙ ‌공개시스템에 정보를 게시하는 담당자가 지정되어 있어야 하며, 공개시스템 정보 게시 담당자에게
비공개 정보 통제에 대한 교육을 시행해야 한다.
▶ ‌공개시스템에 정보를 게시하거나 처리할 담당자를 지정하고 이를 직무 기술서 또는 업무
분장표에 반영
▶ ‌정보를 게시 운영 부서 책임자는 정보 게시 담당자에게 공개적으로 접근 가능한 공개시스템에
중요정보 및 비공개 정보가 포함되지 않도록 하는 절차 및 정책에 대한 교육 시행

---
<!-- Page 68 -->
68 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌이미 게시된 콘텐츠에 중요정보가 포함되어 있는지 정기적으로 검토하고, 발견 시 즉시 삭제 및 수정
등 부적절한 게시를 해결하기 위한 절차를 마련해야 한다.
▶ ‌주기적으로 공개시스템의 게시물을 검토하여 중요정보를 포함하고 있지 않은지 확인
▶ ‌게시물에서 중요정보 또는 비공개 정보 노출을 발견한 즉시 정보 게시 담당자 및 책임자에게 노출
사실을 보고하고 해당 게시물 삭제
관련 기준
⊙ ‌CMMC
• ‌3.1.22 (공공 정보 통제 중요정보) 공개적으로 접근 가능한 시스템에 게시되거나 처리되는 중요정보를
통제하여야 한다.
⊙ ‌K-RMF
• ‌AC-20 (정보공개)
① 공개적으로 접근 가능한 시스템에 정보를 게시할 담당자를 지정해야 한다.
② ‌정보를 게시할 담당자를 교육하여 공개적으로 접근 가능한 정보에 비공개 정보가 포함되지 않게 해야
한다.
③ ‌공개적으로 접근 가능한 시스템에 정보를 게시하기 전에 해당 내용을 검토하여 비공개 정보가 포함되지
않게 해야 한다.
④ ‌공개적으로 접근 가능한 시스템에 비공개 정보가 게시되었는지 조직이 지정한 주기에 따라 검토하고,
비공개 정보 발견 시 삭제해야 한다.

---
<!-- Page 69 -->

## 제3장 우주 보안모델 해설  | 69

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제2절
식별 및 인증(IA)
IA-01
식별 및 인증
항목 내용
시스템 사용자, 프로세스 및 장치를 식별하고 인증해야 한다.
목적
시스템 사용자, 프로세스 및 장치를 식별하고 지상국 시스템(탑재체 데이터
이용 영역·위성운영 영역)에 접근하는 사용자·장치의 비밀번호·키·토큰 등
인증수단을 안전하게 보호함으로써 무단 접근과 인증정보 탈취로 인한 시스템
침해를 예방하기 위함이다.
주요 확인사항
y ‌사용자·프로세스·장치를 식별하고, 사용자 계정 및 장치에 대해
생성·변경·폐기 절차 등 계정 관리 정책을 수립하고 있는가?
y ‌시스템 접근 및 명령 수행 시 사용자, 프로세스, 장치에 대해 인증 절차를
적용하고, 인증 실패 시 계정 존재 여부나 인증 정보가 노출되지 않도록
통제하고 있는가?
y ‌비밀번호 관리기준 및 작성규칙을 수립·이행하고 저장·전송 시 안전하게
보호하는가?
세부 설명
⊙ ‌사용자·프로세스·장치를 식별하고, 사용자 계정 및 장치에 대해 생성·변경·폐기 절차 등 계정 관리
정책을 수립한다.
▶ ‌사용자 계정은 사용자별로 유일하게 구분할 수 있도록 식별자를 할당하고 추측 가능한 식별자
사용을 제한
• ‌계정 발급 시 1인 1계정 발급을 원칙으로 하여 모든 사용자에게 고유 사용자 ID를 부여하고, 중복
불가 원칙 적용
• ‌계정 공유 및 공용 계정 사용 제한
- ‌업무상 불가피하게 공용 계정을 사용하는 경우 그 사유와 타당성을 검토하여 책임자의 승인을
받고 책임추적성을 보장할 추가 통제방안 적용
• ‌시스템이 사용하는 운영계정은 일반 사용자의 접근 제한
• ‌시스템 설치 후 제조사의 기본계정 및 시험계정은 제거 또는 추측이 어려운 계정으로 변경하여
사용(디폴트 패스워드 변경 포함)
• ‌관리자 및 특수권한 계정은 쉽게 추측 가능한 식별자(root, admin, administrator 등)의 사용을
제한

---
<!-- Page 70 -->
70 | 우주 보안 모델 해설 및 적용사례집
▶ ‌사용자를 대신하여 동작하는 프로세스, 서비스, 배치 작업 등에 대해 개별 프로세스 계정 또는
식별자를 정의하여 식별
• ‌자동화 작업, 스케줄러, 백엔드 서비스, 위성 명령 중계 프로세스 등은 사용자 계정과 분리된
프로세스 계정 사용
• ‌프로세스 계정은 수행 기능, 실행 대상 시스템, 계정 소유자 및 관리 책임자 등을 기준으로
식별하여 관리
- 사용자 계정을 이용한 자동 실행, 스크립트 내 계정 하드코딩 등은 원칙적으로 금지
▶ ‌핵심 시스템에 접속하거나 연결되는 모든 장치를 식별해야 함
• ‌서버, 워크스테이션, 네트워크 장비, 명령 전송 장치 등 시스템에 접속하거나 연결되는 장치는
사전에 식별·등록된 장치만 접근을 허용
• ‌MAC 주소, 일련번호, 고정 IP 주소 등을 기준으로 장치 식별
- ‌동일한 식별 정보를 복수 장치에 재사용하지 않도록 관리하며, 식별 정보 변경 시 장치 등록
정보를 최신 상태로 유지
- 식별되지 않거나 등록되지 않은 장치의 네트워크 접속 및 시스템 연결을 제한
▶ ‌식별자(계정 및 장치) 관리를 위해 생성(등록)-변경-폐기 절차 수립·운영
• ‌사용자 계정 생성-변경-폐기 절차
- ‌계정 생성: 인사 발령 또는 직무 할당에 따라 계정 신청서를 접수하고, 관리자 승인 후 계정
발급
- ‌계정 변경: 직무 변경으로 인한 권한 조정 필요 시, 기존 권한을 회수하고 최소 권한 원칙에
따라 권한 재설정
- ‌계정 폐기: 퇴사 또는 계약 종료 시 즉시 계정 삭제
• ‌장치 등록-변경-폐기 절차
- ‌장치 등록: 신규 장치 도입 시 보안 담당자의 승인을 거쳐 인가된 장치 목록에 고유 식별 정보를
등록한 후 네트워크 접속을 허용함
- ‌등록 식별값: 장치 인증서, MAC 주소, 일련번호, 고정 IP 등
- ‌장치 변경: 하드웨어 부품 교체나 OS 재설치 등 식별자가 변경되는 경우, 인증서를 재발급하고
장치 목록 업데이트
- ‌장치 폐기: 장치 반납 또는 폐기 시 인증서를 폐기하고, 장치 목록 및 네트워크 접근 제어
목록(ACL)에서 해당 식별자를 즉시 삭제
• ‌계정 및 장치의 생성부터 폐기까지의 모든 이력(신청서, 승인 기록, 등록 로그)을 조직이 정의한
기간동안 보관

---
<!-- Page 71 -->

## 제3장 우주 보안모델 해설  | 71

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌사용자, 프로세스 및 장치 식별자에 대해 식별자 재사용을 제한하는 기준 수립·운영
• ‌사용자 계정 식별자는 계정 폐기 후 정의된 기간(예: 1년)동안 재사용 금지
• ‌식별자 재사용 제한 기준은 보안정책에 반영
▶ ‌사용자, 프로세스 및 장치 식별자에 대해 미사용 상태를 관리하고, 사용되지 않는 식별자의 접근
차단
• ‌사용자 계정은 정의된 기간 동안 사용되지 않는 경우 로그인 및 시스템 접근이 불가능하도록
비활성화
• ‌자동화 프로세스 계정 및 장치 식별자는 업무 목적이 종료되었거나 더 이상 사용되지 않는 경우
해당 식별자를 통한 접근 차단
• ‌퇴사, 계약 종료, 장치 반납 등 업무 목적이 사라진 경우, 해당 식별자의 시스템 접근을 즉시 차단
⊙ ‌비밀번호 관리 기준 및 작성규칙을 수립·이행하고 저장·전송 시 안전하게 보호해야 한다.
▶ ‌사용자가 안전한 비밀번호를 사용할 수 있도록 다음과 같이 비밀번호 관리기준 수립
• ‌시스템 도입 시 설정된 초기 또는 임시 비밀번호의 변경 후 사용
• ‌비밀번호 처리(입력, 변경) 시 마스킹 처리
• ‌종이, 파일, 모바일 기기 등에 비밀번호 기록·저장을 제한하고, 부득이하게 기록·저장하여야 하는
경우 암호화 등의 보호대책 적용
• ‌보안사고 발생 또는 비밀번호의 노출 징후가 의심될 경우 지체 없이 비밀번호 변경
• ‌비밀번호 분실 등에 따른 재설정 시 본인확인 절차 수행
• ‌관리자 비밀번호는 비밀등급에 준하여 관리 등
• ‌비밀번호 작성규칙 예시(불가피한 경우 제외하고는 시스템적으로 강제)
▶ ‌비밀번호는 추측하기 어렵도록 작성 규칙을 수립·이행
비밀번호 작성규칙 예시
y ‌문자, 숫자의 조합 및 구성에 따라 최소 8자리 이상(알파벳 대소문자, 특수문자, 숫자 등 두 종류
이상의 문자를 이용) 또는 10자리 이상(하나의 문자종류로 구성)의 길이로 구성
y ‌동일한 문자 반복, 키보드 상에서 나란히 있는 문자열, 일련번호, 연속적인 숫자, 사전에 있는 단어,
생일, 전화번호 등 추측하기 쉬운 개인정보 및 계정명과 비슷한 비밀번호 사용 제한
y ‌비밀번호는 주기적으로 변경(90일 또는 위험 기반 정책 적용)
y ‌비밀번호 변경 시, 최근 사용한 비밀번호의 재사용을 제한(최근 3~5회 재사용 금지)

---
<!-- Page 72 -->
72 | 우주 보안 모델 해설 및 적용사례집
▶ ‌시스템에서 사용하는 비밀번호 기반 인증수단은 저장 및 전송 전 구간에서 암호학적으로
보호하여 관리
• ‌사용자 비밀번호는 평문 또는 복호화 가능한 형태 암호화 하여 저장하면 안되며 해시
알고리즘으로 일방향 암호화하여 저장
• ‌시스템, 응용프로그램, 데이터베이스의 비밀번호는 평문 또는 복호화 가능한 암호 알고리즘으로
암호화하여 저장하는 것을 금지
• ‌사용자 인증 과정에서 비밀번호가 암호화되지 않은 상태로 전송되지 않도록 통제
• ‌인증 요청, 로그인, API 호출 등 비밀번호가 포함되는 모든 전송 구간에 대해 암호화된 통신
채널(TLS 등)을 적용
관련 기준
⊙ ‌CMMC
• ‌IA L2-3.5.1 식별 : 시스템 사용자, 사용자를 대신하여 동작하는 프로세스 및 장치를 식별한다.
• ‌IA L2-3.5.2 인증 : 조직 시스템에 대한 액세스를 허용하기 위한 전제 조건으로 사용자, 프로세스 또는
장치의 신원을 인증한다,
• ‌IA L2-3.5.5 식별자 재사용 : 정의된 기간 동안 식별자 재사용을 방지한다,
• ‌IA L2-3.5.6 식별자 처리 : 정의된 기간 동안 활동이 없으면 식별자를 비활성화한다,
• ‌IA L2-3.5.7 비밀번호 복잡성 : 새로운 비밀번호를 생성할 때 최소한의 비밀번호 복잡성과 문자 변경을
적용한다.
• ‌IA L2-3.5.8 비밀번호 재사용 : 지정된 세대 동안 비밀번호 재사용을 금지한다,
• ‌IA L2-3.5.9 임시 비밀번호 : 시스템 로그온 시 임시 비밀번호를 사용하도록 허용하고 즉시 영구
비밀번호로 변경한다.
• ‌IA L2-3.5.10 암호로 보호된 비밀번호 : 암호화로 보호된 비밀번호만 저장하고 전송한다.
• ‌IA L2-3.5.11 모호한 피드백 : 인증 정보에 대한 피드백은 모호하게 해야한다.
⊙ ‌K-RMF
• ‌IA-1-1 장치 식별 및 인증 : 특별권한 계정으로 조직이 지정한 경로를 통해 접근하는 경우 조직이 지정한
다중 인증을 구현해야 한다.
• ‌IIA-3 식별자 관리 : 다음의 방법으로 시스템 식별자를 관리해야 한다.
1. ‌개인, 그룹, 역할 또는 장치 식별자 할당은 조직이 지정한 직책으로부터 승인을 받아야 한다.

## 2. 개인, 그룹, 역할 또는 장치에 적용할 식별자를 선택해야 한다.


## 3. 개인, 그룹, 역할 또는 장치에 식별자를 할당해야 한다.


## 4. 한 번 사용된 식별자는 일정 기간동안 재사용을 방지해야 한다.

• ‌IIA-4-1- 패스워드 기반 인증 :

## 1. 패스워드 사용 시 조직이 지정한 패스워드 복잡성 규칙을 만족하도록 해야 한다.

2. ‌새로운 패스워드로 변경 시 기존의 패스워드에서 조직이 지정한 문자열의 수 만큼 변경해야 한다.

## 3. 암호기술로 보호되는 패스워드만 저장 및 전송 가능하다.


---
<!-- Page 73 -->

## 제3장 우주 보안모델 해설  | 73

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
4. ‌패스워드를 조직이 지정한 최소 사용기간 이내에는 변경할 수 없으며, 조직이 지정한 최대 사용기간
이내에 변경해야 한다.
5. ‌이전 패스워드 재사용은 조직이 지정한 새로운 패스워드 생성횟수가 되기 이전까지 금지한다.
• ‌IA-5 인증수단 피드백 : 인증과정 중에 피드백을 통해 인증정보가 비인가자에게 노출되는 것을 방지해야
한다.
⊙ ‌NIS2
• ‌11.5 식별 : 관련 기관은 네트워크 및 정보 시스템과 그 사용자들의 신원 전체 생명주기를 관리해야 한다.
• ‌11.6 인증 : 관련 기관은 접근 제한 및 접근통제 정책에 기반하여 안전한 인증 절차와 기술을 구현해야
한다.
⊙ ‌ISMS-P
• ‌2.5.1 사용자 계정 관리 : 정보시스템과 개인정보 및 중요정보에 대한 비인가 접근을 통제하고 업무 목적에
따른접근권한을 최소한으로 부여할 수 있도록 사용자 등록·해지 및 접근권한 부여·변경·말소 절차를
수립·이행하고, 사용자 등록 및 권한부여 시 사용자에게 보안책임이 있음을규정화하고 인식시켜야 한다.
• ‌2.5.2. 사용자 식별 : 사용자 계정은 사용자별로 유일하게 구분할 수 있도록 식별자를 할당하고 추측 가능한
식별자 사용을 제한하여야 하며, 동일한 식별자를 공유하여 사용하는 경우 그 사유와 타당성을 검토하여
책임자의 승인 및 책임추적성 확보 등 보완대책을 수립·이행하여야 한다.
• ‌2.5.3 사용자 인증 :　정보시스템과 개인정보 및 중요정보에 대한 사용자의 접근은 안전한 인증절차와
필요에　따라 강화된 인증방식을 적용하여야 한다. 또한 로그인 횟수 제한, 불법 로그인 시도 경고　등
비인가자 접근 통제방안을 수립·이행하여야 한다.
• ‌2.5.4 비밀번호 관리 :　법적 요구사항, 외부 위협요인 등을 고려하여 정보시스템 사용자 및 고객, 회원 등
정보주체(이용자)가 사용하는 비밀번호 관리절차를 수립·이행하여야 한다.

---
<!-- Page 74 -->
74 | 우주 보안 모델 해설 및 적용사례집
IA-02
다중 인증
항목 내용
특수권한 계정으로 네트워크에 접속할 경우에는 다중 인증을 사용하고 재전송
공격 방지 인증 매커니즘을 적용해야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에 접근하는
사용자·장치·서비스가 실제 승인된 주체임을 다단계로 검증하여, 단일
인증수단의 탈취·재생·위조를 통한 무단 접근을 방지하기 위함이다.
주요 확인사항
y ‌시스템 접근 시 접근 유형 및 계정 권한 수준에 따라 다중 인증이 사용되는가?
y ‌특수권한 계정 및 일반계정의 네트워크 접근 시 재전송 공격(Replay Attack)을
차단하기 위한 인증기법을 적용하는가?
세부 설명
⊙ ‌시스템 접근 시 접근 유형 및 계정 권한 수준에 따라 다중 인증을 사용한다.
▶ ‌시스템 접근 유형은 다음과 같이 정의할 수 있음
• ‌로컬 접근(Local Access): 네트워크를 사용하지 않고 직접 연결(서버 콘솔, 직접 로그인 등)을
통해 시스템에 접근하는 경우
• ‌네트워크 접근(Network Access): 네트워크 연결을 통해 시스템에 접근하는 경우
• ‌원격 접근(Remote Access): 외부 네트워크를 통해 네트워크에 접근하는 경우(VPN, 원격 관리
접속 등)
▶ ‌특수권한 계정은 접근 방식(로컬·네트워크)과 관계없이 반드시 다중 인증 적용
• ‌특수권한 계정은 관리자 계정이나 위성 명령 생성·승인·전송 관련 계정을 의미
• ‌다중 인증은 비밀번호 외에 서로 다른 두 가지 이상의 추가 인증 수단을 결합하여 인증하는
방식으로 비밀번호와 OTP 또는 생체정보를 조합하는 방식이 일반적
• ‌운영환경에 직접 영향을 미치는 관리자 계정, 외부 네트워크를 통해 원격 접근이 허용된 관리자
계정 등의 고위험 계정은 보안키(U2F/FIDO2), 스마트카드, OTP 토큰 등 더 강한 인증요소 적용
필요
▶ ‌일반 사용자 계정이라도 네트워크를 통해 시스템에 접근하는 경우 다중 인증 적용
▶ ‌다음과 같이 다중 인증요소로 활용 가능한 사용자 인증 수단을 2가지 이상 결합하여 사용

---
<!-- Page 75 -->

## 제3장 우주 보안모델 해설  | 75

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
사용자 인증 수단 예시
구분
인증 수단
비고
지식 기반
비밀번호
y ‌안전한 비밀번호 작성 규칙 적용 및 변경 주기 고려
y ‌비밀번호 도용, 무작위 대입 공격 등에 대한 대응 필요
y ‌시스템 설치 시 제품 등에서 제공하는 디폴트 계정 및
비밀번호는 사용 정지 또는 변경 필요
소유 기반
인증서(PKI)
y ‌개인키의 안전한 보관 필요 (안전한 보안매체에 보관 권고)
OTP
y ‌OTP 토큰, 모바일 OTP 등 다양한 방식 존재
기타
y ‌스마트카드 방식
y ‌물리적 보안토큰 방식 등
생체 기반
지문, 홍채, 얼굴 등
y ‌생체인식정보의 안전한 관리 필요
출처 : ISMS-P 인증기준 안내서(KISA)
▶ ‌다중 인증 방식 구현은 환경과 업무 필요성에 따라 달라질 수 있음
• ‌위성 탑재 소프트웨어처럼 인증 기능 변경이 제한되는 시스템의 경우, 물리적 접근통제(전용 공간
운영 등), 접근 가능한 사용자 및 단말 제한 등 추가적인 보안 통제 적용
• ‌모바일 기기를 통해 핵심 시스템에 접근하는 경우 반드시 다중 인증 적용 필요
• ‌사용자 인증의 보완통제로 사용할 수 있는 수단은 예는 다음과 같음(ISMS-P 인증기준 안내서
예시)
사용자 인증 수단 예시
구분
인증 수단
비고
기타 방식
(사용자
인증의
보완통제로
적용 가능)
IP 주소
y ‌정 IP 주소에서만 해당 ID로 접속 가능
MAC 주소
y ‌단말기의 MAC 주소를 기반으로 등록된 단말기에서만
접속 가능
장치 일련번호
y ‌특정 PC 또는 특정 디바이스(스마트폰 등)에서만 접속
가능
기타
y ‌위치정보를 기반으로 접속 가능
출처 : ISMS-P 인증기준 안내서(KISA)

---
<!-- Page 76 -->
76 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌특수권한 계정 및 일반 계정의 네트워크 접근 시 재전송 공격(Replay Attack)을 차단하기 위한
인증기법을 적용한다.
▶ ‌재전송 공격 방지 인증은 특수 권한 계정 및 사용자 계정과 API, 자동화 서비스, 시스템 간 연동
계정도 적용해야 함
▶ ‌인증 정보는 제한된 시간 내에서만 유효해야 함
• ‌시간 기반 일회용 비밀번호(TOTP, Time-based One-Time Password)로 30초/60초 주기로
변경되는 인증값 사용 가능
• ‌커버로스(Kerberos) 등 티켓 기반 인증 메커니즘 적용 가능
- ‌분산 컴퓨팅 환경에서 대칭키 암호를 이용하여 사용자 인증을 제공하는 중앙 집중형 인증 방식.
- ‌클라이언트의 요청에 따라 인증 서버는 클라이언트의 패스워드를 기초로 티켓 증명
티켓(TGT:Ticket-Granting Ticket)과 세션 키를 클라이언트에게 제공하고, 클라이언트는
애플리케이션 서버에 접근 시 일정 기간 내 사용자 인증용으로 티켓 증명 티켓(TGT)을
사용하고, 커버로스(Kerberos)는 개방 네트워크상에서 인증과 통신의 암호화를 시행하여,
보안성을 확보함
▶ ‌인증 요청은 재사용이 불가능해야 함
• ‌동일한 인증 요청 또는 서명 값이 재사용될 경우 인증이 거부되고 인증 토큰은 1회 사용 후
폐기되도록 설정
• ‌API 및 자동화 서비스 인증 시 요청마다 변경되는 난수(Nonce)를 포함하는 방식 사용 가능
▶ ‌인증 정보는 세션 및 통신 보호 구간 내에서 관리되어야 함
• ‌인증 토큰은 로그인 세션과 연계하여 관리되며, 세션 종료 시 함께 무효화되어야 함
• ‌인증 과정 중 세션 정보가 변경되거나 비정상 상태로 판단되는 경우 인증을 실패 처리해야 함
• ‌인증 정보는 반드시 TLS 등 암호화된 통신 구간에서만 전송되어야 함

---
<!-- Page 77 -->

## 제3장 우주 보안모델 해설  | 77

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ ‌CMMC
• ‌IA L2-3.5.3 다중 인증 : 권한이 있는 계정에 대한 로컬 및 네트워크 접속과 권한이 없는 계정에 대한
네트워크 접속에는 다중 인증을 사용한다.
• ‌IA L2-3.5.4 재생 방지 인증 : 권한이 있는 계정과 권한이 없는 계정에 대한 네트워크 접속에 대해 재생
방지 인증 매커니즘을 선택한다.
⊙ K-RMF
• ‌IA-1-5 2채널 인증 : 조직이 지정한 조건시, 조직이 지정한 2채널 인증 기술을 구현해야 한다.
• ‌IA-1-6 다중 인증-재전송 공격 방지 : 재전송 공격에 내성이 있는 인증 매터니즘을 적용하여 조직이
지정한 계정유형에 접근해야 한다.
⊙ NIS2
• ‌11.7 다중 인증 : 관련 기관은 사용자가 네트워크 및 정보 시스템에 접근할 때, 다중 인증 요소(MFA) 또는
지속적 인증 메커니즘(continuous authentication)을 통해 인증되도록 보장해야 한다.
⊙ ISMS-P
• ‌2.5.3 사용자 인증 :　정보시스템과 개인정보 및 중요정보에 대한 사용자의 접근은 안전한 인증절차와
필요에　따라 강화된 인증방식을 적용하여야 한다. 또한 로그인 횟수 제한, 불법 로그인 시도 경고　등
비인가자 접근 통제방안을 수립·이행하여야 한다.

---
<!-- Page 78 -->
78 | 우주 보안 모델 해설 및 적용사례집
제3절
시스템 및 통신 보안(SC)
SC-01
경계 보호
항목 내용
조직 시스템의 외부 경계와 주요 내부 경계에서의 통신(송수신 정보)을 모니터링,
제어 및 보호해야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)의 외부·내부 경계에서
비인가 통신을 차단하고, 정상적인 운용 통신만 허용되도록 경계 보호 기능을
적용하여 침해 위협을 선제적으로 방지하기 위함이다.
주요
확인사항
y ‌네트워크의 특성 및 중요도에 따라 네트워크 망을 분리하여 적용하는가?
y ‌공개 서비스 및 외부 연동을 위한 DMZ를 구축하여 운영하는가?
y ‌인터넷을 통해 들어오는 통신(원격 접속 등)을 암호화하고, 트래픽을
모니터링하는가?
세부 설명
⊙ ‌네트워크의 특성 및 중요도에 따라 네트워크 망을 분리하여 적용해야 한다.
▶ ‌서비스 유형, 사용자 그룹, 정보자산 중요도 등을 기준으로 네트워크 영역을 물리적 또는
논리적으로 분리하고, 영역 간 접근을 통제해야 함
• ‌물리적 망분리: 통신망, 장치 등을 물리적으로 이원화하여 2대의 PC 구성 등으로 분리하는 방식
• ‌논리적 망분리: 물리적으로 하나의 통신망, 장치 등을 사용하지만 VDI 같은 가상화 등의
방법으로 네트워크 영역을 분리하는 방식
- ‌논리적 망분리는 주로 방화벽 또는 스위치 허브의 ACL을 이용하여 기본 차단(deny-all) 후
승인된 통신만 허용하는 방식으로 운영
▶ ‌위험 평가 결과를 반영하여 시스템을 여러 네트워크 구간으로 세분화하고, 외부 또는 제3자
환경과 내부 시스템이 직접 연계되지 않도록 구성

---
<!-- Page 79 -->

## 제3장 우주 보안모델 해설  | 79

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
네트워크 분리 구성 예시
네트워크 영역
적용 예시
DMZ
(Demilitarized Zone)
y ‌외부 서비스를 위한 웹서버, 메일서버 등 공개서버는 DMZ에 위치
y ‌DMZ를 경유하지 않고 인터넷에서 내부시스템으로 직접 연결되는 것을
차단
운영 영역
y ‌실제 운영되는 서버, 보안장비, 네트워크 장비 등은 일반 업무용
네트워크 영역과 분리
개발 영역
y ‌개발업무(개발서버, 테스트서버 등)에 사용되는 네트워크는 운영
네트워크와 분리
외부자 영역
y ‌외부 인력이 사용하는 네트워크 영역(외주용역, 민원실, 교육장 등)은
내부 업무용 네트워크와 분리
기타
y ‌업무망의 경우 업무 특성·중요도에 따라 네트워크 대역 분리 기준을
수립하여 운영
y ‌클라우드 서비스를 이용하는 경우 클라우드 환경 특성을 반영한
접근통제 기준 수립·이행
출처 : ISMS-P 인증기준 안내서(KISA)
⊙ ‌공개 서비스 및 외부 연동을 위한 DMZ를 구축하여 운영해야 한다.
DMZ(Demilitarized Zone) 영역은 인터넷망 구간과 내부망 사이에 위치한 중간 지점 또는
인터넷망 구간 사이에 위치한 중간 지점으로서 인터넷망 구간에서 직접 접근이 가능한 영역
출처 : 개인정보 안전성 확보조치 기준 안내서
DMZ 구간의 예시
▶ ‌외부 네트워크에 공개되는 시스템 구성요소(웹 서버, 메일 서버, VPN 게이트웨이 등)를 내부
네트워크와 물리적 또는 논리적으로 분리된 DMZ 영역에 배치

---
<!-- Page 80 -->
80 | 우주 보안 모델 해설 및 적용사례집
▶ ‌DMZ를 경유하지 않고 인터넷에서 내부 시스템으로의 직접 연결되는 것을 차단
⊙ ‌인터넷을 통해 들어오는 통신(원격 접속 등)을 암호화하고, 트래픽을 모니터링해야 한다.
▶ ‌인터넷 등 비신뢰 구간을 경유하는 원격 접속은 암호화 통신을 적용하여 기밀성과 무결성 확보
▶ ‌외부 경계 및 주요 내부 경계를 통과하는 인바운드·아웃바운드 트래픽을 상시 모니터링하여 이상
징후를 탐지
▶ ‌외부로 노출된 전송 경로가 물리적으로 보호되지 않는 경우, 전송 데이터에 암호화를 적용하여
정보 유출을 방지
관련 기준
⊙ ‌CMMC
• ‌SC.L.2-3.13.1 경계 보호 : 조직 시스템의 외부 경계와 주요 내부 경계에서 통신(즉, 조직 시스템에서
전송하거나 수신하는 정보)을 모니터링, 제어 및 보호한다.
• ‌SC.L.2-3.13.5 공공 접근 시스템 분리 : 내부 네트워크와 물리적 또는 논리적으로 분리되어 공개적으로
접근 가능한 시스템 구성 요소에 대한 하위 네트워크를 구현한다.
⊙ ‌K-RMF
• ‌SC-8 경계 보호 : 1. 시스템 외부관리 인터페이스 및 시스템의 주요 내부 관리 인터페이스에서 통신을
모니터링하고 통제해야 한다.
2. ‌외부 네트워크와 조직의 내부 네트워크는 물리적 또는 논리적으로 분리된 서브 네트워크를 통해
연결되어야 한다.
3. ‌내부에서 외부 네트워크로 접속할 경우, 조직의 보안 아키텍처에 따라 구성된 경계 보호기기로 구성된
관리 인터페이스를 통해야 한다.
⊙ ‌NIS2
• ‌6.7 네트워크 보안
• ‌6.8 네트워크 분리/세분화
⊙ ‌ISMS-P
• ‌2.6.1 네트워크 접근 : 네트워크에 대한 비인가 접근을 통제하기 위하여 IP관리, 단말인증 등 관리절차를
수립·이행하고, 업무목적 및 중요도에 따라 네트워크 분리(DMZ, 서버팜, DB존, 개발존 등)와 접근통제를
적용하여야 한다.

---
<!-- Page 81 -->

## 제3장 우주 보안모델 해설  | 81

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SC-02
보안공학 원칙 적용 및 기능 분리
항목 내용
보안 아키텍처는 심층 방어 원칙을 기반으로 설계하고, 시스템의 관리 기능과
사용자 기능을 명확히 분리하여 운영하여야 하며, 시스템 개발 과정에서는
보안공학 원칙을 적용하여야 한다.
목적
우주 시스템(탑재체 데이터 이용 영역·위성운영 영역)의 설계·구축·운영
단계에서 보안공학 원칙을 적용해, 단일 계정 또는 단일 구성 요소가 전체
시스템을 제어하거나, 보안사고가 시스템 전체로 확산되는 것을 방지하며,
안정적으로 위성 명령·운영 데이터를 처리할 수 있는 안전한 구조를 확보하기
위함이다.
주요
확인사항
y ‌우주 시스템 설계·개발 단계에서 보안공학 원칙(심층 방어·최소 권한·기능
분리·표면적 최소화)을 구조적으로 반영하고 있는가?
y ‌운영 기능(명령 생성·승인·전송)과 관리 기능(설정 변경·계정 관리·패치
적용)이 분리되어 단일 계정·단일 권한으로 시스템 전체가 제어되지 않도록
설계되어 있는가?
y ‌시스템 개발·변경·배포·운영 전 과정에서 보안 요구사항 검토·승인 절차가
반영되고 보안 내재화(Secure by Design)가 지속적으로 유지되고 있는가?
세부 설명
⊙ ‌우주 시스템 설계·개발 단계에서 보안공학 원칙(심층 방어·최소 권한·기능 분리·표면적 최소화)을
구조적으로 반영해야 한다.
▶ ‌보안공학(Security Engineering) : 시스템을 설계·개발·배포·운영하는 전 생명주기(SDLC)에
걸쳐 보안을 내재화하는 접근법
• ‌보안 기능을 “나중에 적용하는” 방식이 아니라, 초기 설계 단계부터 보안 요구사항을
내재화(Secure by Design) 하여 공격·오류·오남용이 발생해도 시스템이 전체적으로 붕괴하지
않도록 만듦
• ‌보안공학의 핵심 구성 요소는 아래 표와 같음

---
<!-- Page 82 -->
82 | 우주 보안 모델 해설 및 적용사례집
보안공학의 핵심 구성 요소
구성 요소
설명
심층 방어
(Defense in Depth)
여러 계층의 보안 통제로 공격이 한 단계 뚫려도 다음 단계가 보호
최소 권한
(Least Privileage)
계정·서비스·프로세스에 필요한 최소 권한만 부여
기능 분리
(Separation of Duties)
운영·관리·개발·감사 기능을 분리하여 단일 실패 지점(SPoF) 제거
공격 표면 최소화
(Attack Surface
Reduction)
불필요한 기능·서비스·포트 제거로 공격 기회를 최소화
책임추적성(Traceability)
누가 어떤 작업을 수행했는지 명확하게 추적 가능하도록 기록
구조적 무결성
(Structural Integrity)
시스템 한 부분의 오류나 침해가 전체에 영향을 주지 않도록 설계
▶ ‌공격자의 공격을 여러 단계에서 방어할 수 있도록 심층 방어 설계
• ‌네트워크 계층에서는 네트워크의 특성 및 중요도에 따라 망을 분리하여 구성, 망 간 데이터
흐름을 식별 및 모니터링해야 함
• ‌애플리케이션 계층(탑재체 제어 애플리케이션, 위성 제어 애플리케이션 등)에서는 사용자 인증,
입력값 검증 등의 기능을 구현해야 함
• ‌데이터 계층에서는 데이터의 무결성 검증, 데이터 암호화를 통한 기밀성을 확보해야 함
▶ ‌서비스·프로세스·계정에는 목적 수행에 필요한 최소 권한만 부여
▶ ‌우주 애플리케이션은 필요 기능만 제공하는 최소 기능 원칙 적용
• ‌사용하지 않는 서비스·포트·API 비활성화
• ‌default 계정 제거
• ‌테스트·디버그 인터페이스 비활성화
⊙ ‌운영 기능(명령 생성·승인·전송)과 시스템 관리 기능(설정 변경·계정 관리·패치 적용)을 분리해야
한다.
▶ ‌시스템 관리 기능은 데이터베이스, 네트워크 구성요소, 워크스테이션, 서버 등을 관리하는 데
필요한 기능을 포함하며, 일반적으로 특수 권한이 요구됨
▶ ‌운영 기능은 운영자가 일상적인 업무 수행을 위해 사용하는 기능(예: 명령 생성 및 송신, 탑재체
데이터 조회 등)을 의미하며, 시스템 설정이나 보안 정책을 변경할 수 있는 권한과는 엄격히 구분
▶ ‌단일 계정·단일 권한으로 시스템 전체가 제어되지 않도록 설계

---
<!-- Page 83 -->

## 제3장 우주 보안모델 해설  | 83

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌일반 사용자가 시스템 관리 기능을 수행하는 것을 차단하고, 시스템 관리자 또한 일반
업무(이메일, 웹 브라우징 등)를 수행할 때는 관리자 계정이 아닌 표준 사용자 계정을 사용
▶ ‌운영 기능과 시스템 관리 기능의 분리는 물리적 또는 논리적으로 구현
• ‌서로 다른 컴퓨터 사용, 가상화 기술 활용 등
⊙ ‌시스템 개발·변경·배포·운영 전 과정에서 보안 요구사항 검토·승인 절차가 반영되어 보안
내재화(Secure by Design)가 지속적으로 유지되어야 한다.
▶ ‌우주 시스템을 신규로 도입·개발 또는 변경하는 경우 우주 관련 컴플라이언스 요구사항, 최신
취약점 등을 포함한 보안 요구사항을 명확히 정의하고 설계 단계에서부터 반영
• ‌우주 관련 컴플라이언스 요구사항 : 접근 권한, 접근통제, 암호화, 접속기록 등
• ‌상위 기관 및 내부 규정에 따른 보안 요구사항
• ‌정보보호 관련 기술적 요구사항 : 인증, 개발보안 등
• ‌최신 보안취약점 등
▶ ‌정보시스템의 안전한 구현을 위한 코딩 표준을 마련하고 적용해야 함
• ‌알려진 기술적 보안 취약점으로 인한 위협을 최소화하기 위하여 안전한 코딩 표준 및 규약 마련
• ‌Java, PHP, ASP, 웹, 모바일 등 관련된 개발 언어 및 환경을 모두 포함
• ‌안전한 코딩 표준 및 규약에 대하여 개발자 대상 교육 수행
▶ ‌정보시스템 인수 전 인수기준 적합성 여부를 확인하기 위한 시험 수행
• ‌정보시스템이 사전에 정의한 보안 요구사항을 만족하여 개발·변경 및 도입되었는지 확인하기
위한 인수기준 및 절차 수립
• ‌정보시스템을 인수하기 전 사전 정의한 인수기준과의 적합성 여부를 테스트 등을 통하여 확인한
후 인수 여부를 결정
• ‌시스템 보안 설정, 불필요한 디폴트 계정 제거 여부, 최신 보안취약점 패치 여부 등 확인 필요
• ‌개발·변경 및 구현된 기능이 사전에 정의된 보안 요구사항을 충족하는지 시험 수행
▶ ‌신규 도입·개발 및 변경된 시스템을 운영환경으로 안전하게 이관하기 위한 통제 절차 수립 및
이행
• ‌이관 담당자를 지정하고, 시험 결과의 적정성을 최종 확인 후 책임자 승인 하에 운영환경 이관을
실시해야 함
• ‌운영환경으로의 이관 실패나 장애 발생에 대비하여 이전 버전 보관 및 복구 방안을 사전에
마련해야 함
• ‌운영환경에는 서비스 실행에 불필요한 파일(소스코드, 개발도구, 테스트 데이터, 백업본 등)이
존재하지 않도록 제거해야 함
• ‌우주 시스템의 취약점 예방 및 보안사고 대응을 위한 지속적인 보안 모니터링 및 유지관리

---
<!-- Page 84 -->
84 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ ‌CMMC
• ‌SC.L.2-3.13.2 보안 공학 : 조직 시스템 내에서 효과적인 정보 보안을 증진하는 아키텍처 설계,
소프트웨어 개발 기술 및 시스템 엔지니어링 원칙을 채택한다.
• ‌SC.L.2-3.13.3 역할 분리 : 사용자 기능과 시스템 관리 기능을 분리한다.
⊙ ‌K-RMF
• ‌SA-3-3 개발방법/기술/관행 : 개발자는 다음 사항을 포함하여 시스템 개발 수명주기 사용을 입증해야
한다.

## 1. 최신 시스템/보안 공학 방법


## 2. 소프트웨어 개발 방법


## 3. 시험평가/검증 기법


## 4. 품질 통제 절차

• ‌PA-T-1 심층 방어 : 다음과 같은 심층 방어 접근방식을 사용하여 보안 아키텍처를 설계해야 한다.

## 1. 조직이 지정한 보안 보호조치를 조직이 지정한 위치 및 아키텍처 계층에 할당해야 한다.


## 2. 할당된 보호조치가 조정·통합되고, 상호 강화하는 방식으로 구현되도록 보장해야 한다.

• ‌SC-1 기능 분리 : 시스템 관리기능과 사용자 기능(사용자 인터페이스 포함)을 분리해야 한다.

---
<!-- Page 85 -->

## 제3장 우주 보안모델 해설  | 85

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SC-03
저장 및 전송 정보보안
항목 내용
저장 및 전송되는 정보의 기밀성 및 무결성을 보호해야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에서
처리·저장·전송되는 명령, 텔레메트리, 운영로그, 구성정보 등 중요 정보의
기밀성과 무결성을 보호하여, 위성 운영 과정에서 정보 위변조·탈취·오류로 인한
운용 실패를 예방하기 위함이다.
주요
확인사항
y ‌지상국 시스템에서 저장되는 중요 정보(명령·로그·구성정보 등)가 암호화 또는
동등한 보호조치로 안전하게 보호되고 있는가?
y ‌uplink/downlink 및 내부 전송 구간의 중요 정보가 전송 중 암호화되어
있으며, 무결성 검증을 통해 변조되지 않도록 보호되고 있는가?
y ‌공유 리소스(메모리, 버퍼, 임시 저장공간 등)에서 정보가 비인가
사용자·프로세스에 의해 노출되지 않도록 통제하고 있는가?
세부 설명
⊙ ‌지상국 시스템에서 저장되는 중요 정보(명령·로그·구성정보 등)를 암호화 또는 동등한 보호조치로
안전하게 보호한다.
▶ ‌명령·로그·구성정보 등 중요 정보 저장 시 암호화 또는 보호조치 적용
• ‌명령 데이터, 운영 로그, 설정 파일, 인증 정보 등 중요 정보는 AES-256, ARIA-256 등 검증된
암호 알고리즘 적용
- 데이터베이스, 스토리지, 백업 데이터에도 동일한 보호 수준 적용
• ‌필요 시 파일 단위 암호화와 디스크 단위 암호화 병행 적용 가능
▶ ‌암호화에 사용되는 키는 안전한 장소에 보관하고 암호키 관리 절차를 수립하고 이행
▶ ‌저장된 정보의 무결성이 훼손되지 않도록 보호해야 함
• ‌중요 설정 파일 및 명령 파일은 디지털 서명(AEAD/GCM Tag, HMAC 등)처럼 변조 여부를
확인할 수 있는 무결성 검증 수단을 적용
• ‌로그 데이터는 위·변조 여부를 확인할 수 있도록 보호 조치(append-only, WORM 등)가 적용
▶ ‌중요 정보가 저장된 영역은 허가된 계정만 접근 가능하도록 통제
• ‌개발·시험 환경에서 운영 데이터에 접근하지 않도록 분리
• ‌저장소 접근 로그는 기록·점검이 가능하도록 관리

---
<!-- Page 86 -->
86 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌uplink/downlink 및 내부 전송 구간의 중요 정보가 전송 중 암호화되어 있으며, 무결성 검증을 통해
변조되지 않도록 보호한다.
▶ ‌외부와 연동되는 통신 구간(uplink, downlink 등)은 데이터를 암호화하여 전송해야 함
• ‌명령 전송 구간에서는 인증, 암호화, 무결성 검증 적용이 필수적
- CCSDS 암호화 알고리즘 권고 기준(Blue Book) 참고
출처 : CCSDS Cryptographic Algorithms, 352.0-B-2(CCSDS)
CCSDS 암호화 알고리즘 권고 기준
• ‌CCSDS 권고에 따르면, 위성, 지상국, 통신 구간을 포함한 우주 시스템 전반에 적용되는 암호
알고리즘의 경우 AES-256을 사용해야 함
- 기존 운영 중인 레거시 시스템의 경우 AES-128까지는 허용
▶ ‌송수신되는 데이터는 무결성 검증을 통해 누락 또는 변조 여부를 확인하고, 누락·변조된 데이터
탐지 시 자동 차단
▶ ‌전송 경로는 업무 목적에 맞게 최소화하여 구성해야 함
• ‌불필요한 중계 구간이나 우회 경로 제거
• ‌운영 구간과 인터넷 구간은 명확히 분리된 구조로 설계
• ‌외부 네트워크에서 운영망으로 직접 접근 차단
⊙ ‌공유 리소스(메모리, 버퍼, 임시 저장공간 등)에서 정보가 비인가 사용자·프로세스에 의해 노출되지
않도록 통제한다.
▶ ‌메모리, 버퍼 등은 사용 종료 후 초기화하고 이전 세션 정보가 재사용되지 않도록 처리

---
<!-- Page 87 -->

## 제3장 우주 보안모델 해설  | 87

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌임시 파일(temp), 큐(queue), 버퍼 등은 접근권한을 제한하고, 자동 삭제 정책 적용
▶ ‌공유 저장소(NFS, NAS)는 허가된 사용자만 접근할 수 있도록 통제
▶ ‌운영 기능과 관리 기능은 동일한 메모리 영역을 공유하지 않도록 OS 권한 분리, 컨테이너 격리,
VM(Virtual Machine) 기반 격리 적용
▶ ‌오류 발생 시 생성되는 덤프 파일 등은 민감 정보 포함 여부를 확인하여 관리
• ‌필요 시 암호화하여 저장하며, 최소 보존 기간과 접근통제를 적용
관련 기준
⊙
‌
CMMC
• ‌C.L.2-3.13.4 공유 리소스 통제 : 공유 시스템 리소스를 통해 승인되지 않고 의도치 않은 정보 전송을
방지한다.
• ‌SC.L.2-3.13.8 전송 중인 데이터 : 별도의 물리적 보호 장치가 없는 한, 전송중에 중요정보가 무단으로
공개되는 것을 방지하기 위해 암호화 매커니즘을 구현한다.
• ‌SC.L.2-3.13.16 저장(휴면 상태의) 데이터 : 저장(휴면 상태) 중요정보의 기밀성을 보호한다.
⊙ ‌K-RMF
• ‌SC-5 공유 시스템 자원 내 정보 : 공유 시스템 자원을 통한 무단 및 의도하지 않은 정보전송을 방지해야
한다.
• ‌SC-9 전송 정보의 기밀성 및 무결성 : 전송되는 정보의 기밀성 및 무결성을 보호해야 한다.
• ‌SC-10 저장된 정보의 보호 : 저장된 정보의 기밀성과 무결성을 보호해야 한다.
⊙ ‌ISMS-P
• ‌2.7.1 암호정책 적용 : 개인정보 및 주요정보 보호를 위하여 법적 요구사항을 반영한 암호화 대상, 암호
강도, 암호사용 정책을 수립하고 개인정보 및 주요정보의 저장·전송·전달 시 암호화를 적용하여야 한다.
• ‌2.10.5 전송정보 보안 ：다른 조직에 개인정보 및 중요정보를 전송할 경우 안전한 전송 정책을 수립하고
조직 간 합의를 통하여 관리 책임, 전송방법, 개인정보 및 중요정보 보호를 위한 기술적 보호조치 등을
협약하고 이행하여야 한다.

---
<!-- Page 88 -->
88 | 우주 보안 모델 해설 및 적용사례집
SC-04
통신 보안
항목 내용
기본적으로 모든 트래픽을 거부하고, 필요한 트래픽만 예외적으로 허용하는
방식으로 운용하고, 로컬 및 원격연결을 동시에 하지 못하도록 통제하며 통신세션
종료 이후 또는 일정 기간동안 작업이 없을 경우 통신 세션과 관련된 연결을
종료해야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에서 이루어지는
로컬·원격 접속 및 통신 세션이 비인가 접근·우회 연결·세션 탈취 없이 안전하게
설정·유지·종료되도록 통신 경로와 세션 관리 보안 기능을 적용하여 위성 운영
안정성을 확보하기 위함이다.
주요
확인사항
y ‌지상국 시스템의 로컬·원격 접속 시 기본 차단(Default Deny) 정책을
적용하고, 필요한 통신만 예외적으로 허용하도록 네트워크 통제가 적용되고
있는가?
y ‌통신 세션 설정 시 인증·무결성 검증·보호 채널(TLS/VPN 등)이 적용되어 세션
탈취·위조·우회 연결을 방지하고 있는가?
y ‌일정 시간 동안 활동이 없거나 세션 종료 조건 충족 시, 세션이 자동으로
종료(Session Timeout)되도록 설정하고, 종료 후 남은 연결·세션 정보를
안전하게 삭제하고 있는가?
세부 설명
⊙ ‌지상국 시스템의 로컬·원격 접속 시 기본 차단(Default Deny) 정책을 적용하고, 필요한 통신만
예외적으로 허용하도록 네트워크 통제를 적용한다.
▶ ‌네트워크 통신은 모두 기본 차단(Default Deny)하고, 업무상 필요성이 명확한 통신만 정책에
따라 예외적으로 허용
• ‌업무상 필요에 따라 예외적으로 허용하는 통신은 반드시 출발지(Source IP/대역),
목적지(Destination IP/대역), 서비스 포트 및 프로토콜(Service/Port/Protocol), 통신 방향을
최소한의 범위로 정의
▶ ‌허용되는 통신의 포트, 프로토콜, 경로를 명확히 정의하고, 사전에 승인된 통신을 허용
목록(Allow List)으로 관리
• ‌방화벽·ACL로 명령 경로, 텔레메트리(telemetry) 경로 등 필요 트래픽만 허용
• ‌P2P, 메신저 등 업무와 무관하고 위험한 서비스와 연관된 포트 및 프로토콜은 정책으로 차단
▶ ‌시스템 간 통신 경로는 임의 변경이 불가능하도록 고정된 경로만 허용하고, 정책에 정의되지 않은
우회 경로를 통한 통신은 차단

---
<!-- Page 89 -->

## 제3장 우주 보안모델 해설  | 89

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌NAT(Network Address Translation), 포트 포워딩 등 외부에서 내부 시스템으로 직접 연결되는
구조는 원칙적으로 제한
• ‌공용 인터넷 회선 또는 공용 Wi-Fi를 통한 운영 목적의 시스템 접속 제한
▶ ‌원격 접속 단말이 조직 시스템에 연결된 상태에서 동시에 외부 네트워크와 통신하지 못하도록
분할 터널링27 차단
• ‌원격 접속 시 인터넷과 운영망을 동시에 사용하여 내부 통신이 노출되거나 우회되는 위험을 방지
▶ ‌VPN 접속 시 단말의 모든 통신 트래픽이 조직 네트워크를 경유하도록 구성하여, 외부
네트워크를 통한 우회 통신이 발생하지 않도록 통제
⊙ ‌통신 세션 설정 시 인증·무결성 검증·보호 채널(TLS/VPN 등)이 적용되어 세션 탈취·위조·우회
연결을 방지한다.
▶ ‌통신 세션은 사전에 승인된 사용자 또는 시스템 간에만 수립되도록 구성하고, 인증되지 않은
대상과의 세션 생성은 차단
• ‌외부 연동 및 시스템 간 통신 구간에서는 서버와 클라이언트가 상호 인증 절차를 거쳐 서로의
신원을 확인
• ‌서버 인증서뿐 아니라 필요 시 클라이언트 인증서(mTLS) 또는 장치 인증을 적용하여 일방향
인증에 따른 위·변조 위험을 방지
• ‌통신에 사용하는 인증서는 조직이 신뢰하는 인증기관(CA)에서 발급한 유효한 인증서만 사용
▶ ‌통신 세션이 유지되는 동안 인증 상태가 우회되거나 변조되지 않도록 보호된 통신 채널을 적용
• ‌통신 구간에는 TLS, IPsec, 전용 VPN 등 암호화와 무결성 검증이 함께 제공되는 세션 기반 통신
방식을 적용
• ‌세션 내에서 전송되는 데이터는 메시지 인증 코드(MAC) 또는 디지털 서명 등을 통해 위·변조
여부를 확인
• ‌세션 탈취 및 중간자 공격에 취약한 평문 또는 불완전한 프로토콜을 사용 제한
▶ ‌세션 수립 과정에서는 난수, 시퀀스 값 등 재전송 방지 요소를 포함하여 이전 인증 정보 재사용
방지
▶ ‌세션ID는 생성·사용·폐기의 과정에 따라 안전하게 관리해야 함
27	 ‌분할 터널링(Split Tunneling): 운영 단말이 VPN(운영망)에 연결된 상태에서 동시에 외부 인터넷에 접속할 수 있는 구조
를 말하며, 외부 공격자가 운영망으로 직접 침투할 가능성을 높이는 위험 요소로 분류됨.

---
<!-- Page 90 -->
90 | 우주 보안 모델 해설 및 적용사례집
세션ID 관리 지침
단계
내용
세션ID 생성
y ‌세션ID는 안전한 서버에서 생성해서 사용
y ‌세션ID는 최소 128비트의 길이로 생성되어야 하며, 안전한 난수
알고리즘을 적용하여 예측 불가능한 값 사용
세션ID 사용
y ‌URL Rewrite 기능을 사용하는 경우 세션ID가 URL에 노출될 수
있으므로, 사용하지 않도록 설계
세션ID 폐기
y ‌로그인 성공 시 로그인 전에 할당받은 세션ID는 파기하고 새로운 값으로
재할당하여 세션ID 고정 공격에 대응하도록 시큐어코딩 규칙을 정의
y ‌장기간 접속되어 있는 경우 세션ID의 노출위험이 커지므로, 일정시간
주기적으로 세션ID를 재할당 하도록 설계
출처 : 소프트웨어 개발보안 가이드라인(KISA)
⊙ ‌일정 시간 동안 활동이 없거나 세션 종료 조건 충족 시, 세션이 자동으로 종료(Session
Timeout)되도록 설정하고, 종료 후 남은 연결·세션 정보를 안전하게 삭제한다.
▶ ‌통신 세션이 종료되었거나 일정 시간 동안 활동이 없는 경우, 해당 세션과 연관된 네트워크
연결이 자동으로 종료되도록 세션 종료 조건과 시간 기준을 정의하고 적용
• ‌중요 기능의 경우 2~5분, 위험도가 낮은 경우에는 15~30분으로 설정(출처 : 소프트웨어
개발보안 가이드(KISA))
• ‌사용자 계정뿐만 아니라 장치 세션(콘솔·SSH)도 세션 종료 정책 적용
▶ ‌세션 종료 시 세션 키 파기, 토큰 폐기, 임시 버퍼 삭제를 수행
▶ ‌세션 종료 이후에도 네트워크 연결이나 논리적 세션이 남아있지 않도록 연결 종료가 정상적으로
수행되었는지 확인
관련 기준
⊙ ‌CMMC
• ‌SC.L.2-3.13.6 예외에 의한 네트워크 통신 : 기본적으로 네트워크 통신 트래픽을 거부하고 예외적으로
네트워크 통신 트래픽을 허용한다.(즉, 모두 거부하고 예외적으로 허용)
• ‌SC.L.2-3.13.7 분할 터널링 : 원격 장치가 조직 시스템과 원격이 아닌 연결을 동시에 설정하고 다른
연결을 통해 외부 네트워크의 리소스와 통신하는 것을 방지한다.(예: 분할 터널링)
• ‌SC.L.2-3.13.9 연결 종료 : 통신 세션과 관련된 네트워크 연결을 세션 종료 시 또는 정해진 시간 동안
활동이 없을 경우 종료된다.
• ‌SC.L.2-3.13.15 통신 인증성 : 통신 세션의 인증성을 보호한다.

---
<!-- Page 91 -->

## 제3장 우주 보안모델 해설  | 91

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌K-RMF
• ‌SC-8-3 기본 거부/예외적 허용 : 관리 인터페이스에서 기본적으로 모든 트래픽을 거부하고, SC-8-4
분할 터널링 방지, SC-11 네트워크 연결 해제, SC-20 세션 인증
⊙ ‌NIS2
• ‌6.7 네트워크 보안
⊙ ‌ISMS-P
• ‌2.6.1 네트워크 접근 : 네트워크에 대한 비인가 접근을 통제하기 위하여 IP관리, 단말인증 등 관리절차를
수립·이행하고, 업무목적 및 중요도에 따라 네트워크 분리(DMZ, 서버팜, DB존, 개발존 등)와 접근통제를
적용하여야 한다.
• ‌2.6.2 정보시스템 접근 :　암호키의 안전한 생성·이용·보관·배포·파기를 위한 관리 절차를 수립·이행하고,
필요 시　복구방안을 마련하여야 한다.

---
<!-- Page 92 -->
92 | 우주 보안 모델 해설 및 적용사례집
SC-05
암호화
항목 내용
중요 정보는 암호화하고 암호화를 위한 암호키를 설정하고 관리해야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에서
처리·저장·전송되는 명령, 텔레메트리, 구성정보, 인증정보 등 중요 데이터의
기밀성과 무결성을 보장하기 위해, 안전한 암호 알고리즘을 적용하고 암호키를
안전하게 생성·보관·관리하여 위성 운영 과정에서 정보 노출, 변조, 탈취로 인한
사고를 예방하기 위함이다.
주요
확인사항
y ‌명령·운영로그·구성정보 등 중요 정보에 안전한 암호 알고리즘과 암호화
기술을 적용하여 저장·전송 데이터의 기밀성·무결성을 보호하고 있는가?
y ‌암호키의 준비·운영·정지·폐기의 단계가 안전하게 관리되고 있으며, 키 접근을
최소화하여 오남용을 방지하고 있는가?
세부 설명
⊙ ‌명령·운영로그·구성정보 등 중요 정보에 안전한 암호 알고리즘과 암호화 기술을 적용하여
저장·전송 데이터의 기밀성·무결성을 보호한다.
▶ ‌국내외 암호 연구 관련 기관에서 사용을 권장하는 안전한 암호 알고리즘
구분
미국(NIST)
일본(CRYPTEC)
유럽(ECRYPT)
국내
일방향 암호
알고리즘
SHA-
224/256/384/512
SHA-256/384/512
SHA-
224/256/384/512
Whirlpool
SHA-224/256/384/512
대칭키 암호
알고리즘
AES-128/192/256
AES-128/192/256
Camellia-128/192/256
AES-128/192/256
Camellia-128/192/256
Serpent-128/192/256
SEED, HIGHT ARIA-
128/192/256
LEA-128/192/256
공개키 암호
알고리즘
(메시지
암·복호화)
RSA
RSAES-OAEP
RSAES-OAEP
RASES
키 길이 2048-bits 이상
출처 : 개인정보의 기술적 관리적 보호조치 기준 해설서KISA)
※ ‌처리속도 등 기술발전에 따라 사용 권고 암호 알고리즘은 달라질 수 있으므로, 암호화 적용 시
국내외 암호 관련 연구기관에서 제시하는 최신 정보 확인 필요

---
<!-- Page 93 -->

## 제3장 우주 보안모델 해설  | 93

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌단시간내 암호 해독이 가능하여 보안강도가 낮은 것으로 판명된 암호 알고리즘(TDEA(TDES),
MD5, SHA-1 등)을 사용하여서는 안 됨
▶ ‌CCSDS의 암호 알고리즘 권고 기준 참고(CCSDS CRYPTOGRAPHIC ALGORITHMS,
352.0-B-2)
• ‌CCSDS 권고에 따르면, 위성, 지상국, 통신 구간을 포함한 우주 시스템 전반에 적용되는 암호
알고리즘의 경우 AES-256을 사용해야 함
- 기존 운영 중인 레거시 시스템의 경우 AES-128까지는 허용
• ‌메시지 무결성 및 송신자 인증을 위한 메시지 인증 코드(HMAC) 적용 시에는, 기본 해시
알고리즘으로 SHA-256을 사용
- SHA-1 알고리즘은 신규 시스템 구축·도입에 사용 금지
• ‌공개키 기반의 전자서명 인증이 요구되는 경우에는 RSA-4096 이상 사용 권고
⊙ ‌암호키의 준비·운영·정지·폐기의 단계가 안전하게 관리되고 있으며 키 접근을 최소화하여 오남용을
방지한다.
▶ ‌암호 키의 안전한 사용과 관리를 위해 암호키 생명주기(준비·운영·정지·폐기) 단계별 암호 키
관리 절차를 수립·시행해야 함
▶ ‌준비 단계: 암호 키가 사용되기 이전의 단계
• ‌암호 키 생성
- ‌암호 키 생성에 필요한 난수는 안전한 난수발생기(RNG, Random Number Generator)를
이용하여 생성
- ‌비대칭키 알고리즘 키 생성 방식: 디지털 서명을 위한 키 쌍 생성, 키 설정을 위한 키 쌍 생성
- ‌대칭키 알고리즘 방식: 미리 공유된 키, 비밀번호, 다수의 암호 키를 이용한 키 생성 등
• ‌암호 키 분배
- ‌대칭키 알고리즘 키 분배 방식: 수동적 키 분배, 자동화된 키 전송 등
- ‌비대칭키 알고리즘의 키 분배 방식
- ‌기타 키 자료 생성 및 분배 방식: 영역 파라미터, 초기값, 공유된 비밀, RNG 시드, 다른 공개 및
비밀정보, 중간값, 난수, 비밀번호 등
▶ ‌운영 단계: 암호 키가 암호 알고리즘 및 연산에 사용되는 단계
• ‌암호 키의 유효기간 동안 사용되는 키 자료들은 필요에 따라 장비 모듈에 보관하거나 별도의 저장
매체에 보관하여 저장해야 함
• ‌암호 키는 하드웨어 손상 또는 소프트웨어 오류 등의 사유로 손상될 가능성이 있으므로 가용성
보장을 위해서는 키 백업 및 키 복구 등이 가능해야 함

---
<!-- Page 94 -->
94 | 우주 보안 모델 해설 및 적용사례집
• ‌암호 키가 노출되거나 노출의 위협이 있는 경우 그리고 암호키 유효기간의 만료가 가까워지는
경우에는 암호 키를 다른 암호키로 안전하게 변경해야 함
▶ ‌정지 단계: 암호 키가 더 이상 사용되지 않지만, 암호 키에 대한 접근은 가능한 단계
• ‌암호 키는 수정이 불가한 상태이거나 새로운 보관 키를 이용하여 주기적으로 암호화
• ‌운영 데이터와 분리되어 보관하며, 암호 정보의 사본들은 물리적으로 분리된 곳에 보관
• ‌암호 키는 응용프로그램의 소스 프로그램 내에 평문으로 저장 금지
• ‌암호화되는 중요한 정보에 대한 보관키는 백업되어야 하며, 사본은 다른 곳에 보관 등 모든 개인
키나 대칭 키의 복사본이 더 이상 필요하지 않다면 즉시 파기하여야 함
• ‌암호 키 손상 시 유효기간 내에 키 자료를 제거하고, 보안 도메인에 속해 있는 실체의 권한을
삭제하여 말소된 실체의 키 자료의 사용을 방지해야 함
▶ ‌폐기 단계: 암호 키가 더 이상 사용될 수 없는 단계(폐기 또는 사고 상태)
• ‌일반적으로 폐기 단계의 키 자료에 대한 모든 기록은 삭제(다만, 일부기관에서는 감사를 목적으로
특정 키 속성 유지가 필요할 수도 있음)
• ‌폐기 상태의 암호 키와 사고 상태의 암호 키들의 특성에 대한 기록 유지 등
▶ ‌암호키 접근권한은 최소한으로 부여하며 접근 로그 및 사용 이력을 기록해야 함
관련 기준
⊙
‌
CMMC
• ‌SC.L.2-3.13.10 키 관리 : 조직 시스템에 사용되는 암호화를 위한 암호화 키를 설정하고 관리한다.
• ‌SC.L.2-3.13.11 중요 정보 암호화 : 중요 정보의 기밀성을 보호하기 위해 FIPS 검증 암호화를 사용한다.
⊙ ‌K-RMF
• ‌CR-2 암호키 설정 및 관리 : 조직이 지정한 암호키 생성, 분배, 저장, 접근, 폐기 관리 정책에 따라
시스템에 적용되는 암호기술에 필요한 암호키를 설정하고 관리해야 한다.
• ‌CR-1 암호기술을 통한 보호 : 적용 가능한 법령, 정책, 규정 및 지침에 따라 조직이 지정한 암호기술(장비,
제품, 알고리즘 등)을 구현해야 한다.
⊙ ‌NIS2
• ‌9.1 암호정책 수립 , 9.2 암호 알고리즘·프로토콜 관리, 9.3 키 관리
⊙ ‌ISMS-P
• ‌2.7.2 암호키 관리 : 암호키의 안전한 생성·이용·보관·배포·파기를 위한 관리 절차를 수립·이행하고, 필요
시 복구방안을 마련하여야 한다.

---
<!-- Page 95 -->

## 제3장 우주 보안모델 해설  | 95

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SC-06
협업 컴퓨팅 장치
항목 내용
협업 컴퓨팅 장치의 원격 활성화를 금지하고 장치가 사용 중일 때는 물리적으로
나타나는 표시를 통해 사용자가 장치가 사용 중임을 인식할 수 있어야 한다.
목적
협업 컴퓨팅 장치(마이크·카메라·화상회의 장비 등)를 사용자가 인지하지
못한 상태에서 원격으로 활성화하거나 녹음·촬영하는 위협을 방지하고,
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에서 운영 중인 민감한
정보(명령·운영 절차·모니터링 화면 등)가 유출되지 않도록 보호하기 위함이다.
주요
확인사항
y ‌우주기업 내 협업 컴퓨팅 장치(음성·영상·화상 회의 등 협업을 위한 장치)를
식별하고 관리하는가?
y ‌협업 컴퓨팅 장치가 원격에서 임의로 활성화되지 않도록 통제하고 있는가?
y ‌협업 컴퓨팅 장치 사용 시 사용자에게 장치 활성화 상태가 명확히 인지되며,
오디오·영상 정보가 무단으로 저장·전송되지 않도록 통제하고 있는가?
세부 설명
⊙ ‌우주기업 내 협업 컴퓨팅 장치(음성·영상·화상 회의 등 협업을 위한 장치)를 식별하고 관리한다.
▶ ‌음성·영상·화상 회의 등 협업 목적을 위해 사용자 주변 환경의 정보를 수집하거나 전송할 수 있는
장치를 식별하고 관리해야 함
협업 컴퓨팅 장치(Collaborative Computing Devices) (예시)
- 화상회의 장비(Camera, Conference System)
- 마이크(Microphone, Speakerphone)
- 스피커·오디오 회의 장비
- 원격 회의용 터미널 (예: Zoom Room, Teams Room 장비)
- 기기 내장 웹캠·마이크 기능이 활성화된 단말기(Notebook, Tablet 포함)
- 원격 화면 공유 장치, 스마트 TV 회의 기능
※ ‌우주·지상국 운영환경에서는 관제실 웹캠, 회의용 카메라, 오디오 수집 장치, 원격 협업 단말
등이 협업 컴퓨팅 장치로 식별될 수 있음
▶ ‌협업 컴퓨팅 장치는 원격 활성화 또는 무단 사용 시 위성 관제 화면, 운영 절차, 명령 수행 상황이
외부로 노출될 수 있으므로 자산 목록 또는 장비 관리 목록에 등록하여 통제 정책 적용
⊙ ‌협업 컴퓨팅 장치가 원격에서 임의로 활성화되지 않도록 통제한다.
▶ ‌카메라·마이크 등의 협업 장치는 사용자가 직접 조작하지 않는 한 자동으로 활성화되지 않도록
설정

---
<!-- Page 96 -->
96 | 우주 보안 모델 해설 및 적용사례집
▶ ‌운영체제 또는 응용프로그램의 원격 제어 기능을 통해 카메라·마이크가 원격에서 활성화되지
않도록 원격 제어 기능(원격 녹음·원격 촬영) 비활성화
▶ ‌지상국·관제 환경에서는 협업 컴퓨팅 장치를 기본 비활성화 상태로 유지하고, 필요 시에만 사용
⊙ ‌협업 컴퓨팅 장치 사용 시 사용자에게 장치 활성화 상태가 명확히 인지되며, 오디오·영상 정보가
무단으로 저장·전송되지 않도록 통제한다.
▶ ‌협업 컴퓨팅 장치가 활성화되면 장치 자체의 LED 표시등 점등, 화면 팝업 등 시각적·물리적인
표시를 통해 사용자에게 장치가 사용중임을 알려야 함
• ‌노트북·외장 웹캠 등 물리적 차단 수단이 제공되는 장치는 해당 기능 사용을 권장
▶ ‌운영망 또는 관제 환경에서는 협업 장치의 화면 공유, 녹화, 녹음 기능을 업무 목적에 맞게 제한
▶ ‌관제 화면, 명령 인터페이스, 운영 절차 등 민감 정보가 협업 장치를 통해 외부로 전송되지 않도록
기능을 통제
▶ ‌협업 장치 사용 시 생성되는 오디오·영상 데이터가 불필요하게 저장되지 않도록 설정하거나,
필요 시 보호 조치를 적용
▶ ‌외부 협업 장치(USB 웹캠, 외장 마이크 등)는 관리자 승인 하에 연결되도록 통제
관련 기준
⊙
‌
CMMC
• ‌SC.L.2-3.13.12 협업 장치 통제 : 협업 컴퓨팅 장치의 원격 활성화를 금지하고 장치 옆에 있는 사용자에게
사용 중인 장치를 표시한다.
⊙ K-RMF
• ‌SC-13 협업 컴퓨팅 장치 : 1. 조직이 지정한 예외사항에서만 협업 컴퓨팅 장치의 원격
활성화를 허용하고, 이외에는 협업 컴퓨팅 장치의 원격 활성화를 허용하지 않아야 한다.

## 2. 장치가 사용 중일 때는 물리적으로 나타나는 표시를 통해 사용자가 장치가 사용 중임을 인식할 수 있어야

한다.

---
<!-- Page 97 -->

## 제3장 우주 보안모델 해설  | 97

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SC-07
모바일 코드 및 VoIP 통제
항목 내용
시스템 내 모바일 코드 및 VoIP의 사용을 모니터링·통제하여야 한다.
목적
지상국 시스템(탑재체 데이터 이용 영역·위성운영 영역)에서 모바일 코드와
VoIP 기능의 사용을 모니터링·통제하여, 악성코드 실행, 원격제어, 도·감청,
비인가 음성 통신 등 보안 위협으로부터 운영 환경을 보호하기 위함이다.
주요
확인사항
y ‌모바일 코드의 실행을 통제하고, 의심·비인가 모바일 코드 실행 여부를
모니터링하고 있는가?
y ‌VoIP 기능의 사용을 제한·통제하고, 음성 통신이 비인가 경로로 송수신되지
않도록 보안 설정·모니터링 체계를 운영하고 있는가?
세부 설명
⊙ ‌모바일 코드의 사용 및 실행을 통제하고, 의심·비인가 모바일 코드 실행 여부를 모니터링한다.
▶ ‌모바일 코드(Mobile Code) : 시스템에 사전 설치되지 않았더라도 네트워크 등을 통해 전달되어
사용자 단말이나 서버에서 자동 또는 사용자 동작에 의해 실행될 수 있는 실행 코드로서, Java,
JavaScript, ActiveX, 매크로, 스크립트 등과 같이 시스템 동작에 영향을 미칠 수 있는 코드
▶ ‌시스템 내 모바일 코드가 임의로 실행되지 않도록 실행 환경을 통제
• ‌지상국 운영망 및 관제 환경에서는 업무에 불필요한 스크립트 실행 환경(ActiveX, Java
Runtime 등)을 비활성화
• ‌웹브라우저 및 응용프로그램에서는 스크립트 실행 정책을 강화하고, 화이트리스트 도메인만
스크립트 실행을 허용
• ‌외부에서 다운로드되거나 사용자에 의해 생성된 스크립트·매크로는 기본 차단 원칙(Default
Deny) 적용
▶ ‌허용 가능한 모바일 코드 유형과 기술을 사전에 정의하고, 그 외 모바일 코드 사용은 원칙적으로 금지
• ‌업무상 예외가 필요한 경우 승인 이력과 사용 범위를 명확히 관리
▶ ‌모바일 코드는 검증된 경우에 한해 제한적으로 실행되도록 관리
• ‌서명된 코드(Signature Code) 또는 내부 검증 절차를 거친 스크립트만 실행을 허용
• ‌운영 자동화 목적의 스크립트는 사전 승인, 코드 서명, 변경 이력 관리 등 관리 절차 하에 사용
▶ ‌비인가 모바일 코드 실행 여부를 지속적으로 모니터링해야 함
• ‌엔드포인트 보안 솔루션 등을 통해 비인가 스크립트 실행, 원격 다운로드 스크립트, 메모리 기반
악성 코드 등을 탐지
• ‌PowerShell/WSH/파이썬 등 스크립트 실행 이력은 기록·보관하고, 이상 행위 발생 시
관리자에게 즉시 알림

---
<!-- Page 98 -->
98 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌VoIP 기능의 사용을 제한·통제하고, 음성 통신이 비인가 경로로 송수신되지 않도록 보안
설정·모니터링 체계를 운영한다.
▶ ‌지상국 운영망 및 관제 환경에서는 VoIP 사용을 원칙적으로 금지
• ‌업무상 불가피한 경우에 한해 사전 승인된 장비·계정·환경에서만 VoIP 사용을 허용
• ‌공개 메신저 기반 음성 통신 기능(Softphone, 영상통화 앱 등)은 운영 환경에서 사용하지 않도록 통제
▶ ‌VoIP 관련 네트워크 트래픽은 보안 정책에 따라 제어해야 함
• ‌운영망과 외부 네트워크 간 음성 트래픽 송수신을 차단하고, 포트 포워딩 및 NAT 설정을 차단할
수 있음
• ‌SIP, RTP, RTCP 등 VoIP 관련 프로토콜은 기본 차단하고, 승인된 내부 전용 구간에서만
제한적으로 허용
• ‌허용된 VoIP 환경에서는 TLS, SRTP 등 암호화된 음성 통신 채널을 적용
• ‌인증되지 않은 장비 또는 계정의 VoIP 세션 등록 및 통신 시도를 차단
▶ ‌VoIP 사용 현황 및 이상 행위를 지속적으로 모니터링
• ‌비인가 VoIP 프로토콜 사용, 비정상 음성 통신 발생 여부를 탐지하고, 이상 징후 발생 시
관리자에게 알림
• ‌VoIP 관련 애플리케이션 설치, 실행 이력 및 통신 로그를 기록·관리
관련 기준
⊙ CMMC
• ‌SC.L.2-3.13.13 모바일 코드 : 모바일 코드 사용을 제어하고 모니터링한다.
• ‌SC.L.2-3.13.14 인터넷 프로토콜을 통한 음성 : VoIP 기술의 사용을 제어하고 모니터링한다.
⊙ K-RMF
• ‌SC-15 모바일 코드
1 .  시스템에서 허용 및 금지할 모바일 코드와 모바일 코드 기술을 정의해야 한다.

## 2. 허용할 모바일 코드와 모바일 코드 기술의 사용 제한 사항과 구현 가이드를 수립해야 한다.


## 3. 시스템 내 모바일 코드의 사용을 인가, 모니터링 통제해야 한다.

• ‌SC-16 VoIP

## 1. VoIP 기술의 사용 제한사항 및 구현 가이드를 수립해야 한다.


## 2. 시스템 내 VoIP의 사용을 인가, 모니터링, 통제 하여야 한다.

⊙ ISMS-P
• ‌2.10.6 업무용 단말기 보안 : PC, 모바일 기기 등 단말기기를 업무 목적으로 네트워크에 연결할 경우 기기
인증 및 승인, 접근 범위, 기기 보안설정 등의 접근통제 대책을 수립하고 주기적으로 점검하여야 한다.

---
<!-- Page 99 -->

## 제3장 우주 보안모델 해설  | 99

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제4절
시스템 및 정보 무결성(SI)
SI-01
취약점 점검 및 결함 교정
항목 내용
시스템과 애플리케이션의 취약점을 주기적으로 검사하고, 해당 시스템에 영향을
미치는 신규 취약점이 확인될 때마다 검사하여 시스템의 결함을 식별, 조치,
보고해야 한다.
목적
시스템 및 애플리케이션의 취약점을 주기적으로 점검하고, 결함을
식별·조치하여 사고를 예방하고 무결성과 가용성을 확보하기 위함이다.
주요
확인사항
y ‌시스템과 애플리케이션의 취약점을 주기적으로 검사하고, 신규 취약점 정보
공표 시, 즉시 점검을 수행하는가?
y ‌식별된 취약점은 위험 평가 결과를 반영하여 우선순위를 결정하고, 우선순위에
따라 조치하고 있는가?
y 시스템 결함 식별 활동을 주기적으로 수행하고 있는가?
세부 설명
⊙ ‌시스템과 애플리케이션의 취약점을 주기적으로 검사하고, 신규 취약점 정보가 공표되면, 즉시
점검을 수행해야 한다.
▶ ‌우주 기업은 우주 시스템 및 애플리케이션 등 자산의 중요도와 위험 수준을 고려하여 취약점 점검
주기를 정의(예: 반기, 분기, 연 1회 등)
▶ ‌정의된 점검 주기에 맞춰 우주 시스템 및 애플리케이션을 대상으로 취약점 점검 수행
• ‌라우터, 스위치 등 네트워크 시스템 구성요소 및 설정 취약점
• ‌서버 OS 보안 설정 취약점
• ‌방화벽 등 보안 시스템 취약점
• ‌애플리케이션 취약점
• ‌웹 서비스 취약점
• ‌스마트 기기 및 모바일 서비스(모바일 앱 등) 취약점 등
▶ ‌취약점 점검 주기와 관계없이 시스템 및 애플리케이션에 영향을 미치는 신규 취약점 정보 수집 시
즉시 점검을 수행해야 함

---
<!-- Page 100 -->
100 | 우주 보안 모델 해설 및 적용사례집
• ‌우주 기업의 보안 담당자는 한국인터넷진흥원(KISA) 보호나라, 국가사이버안보센터(NCSC),
NIST NVD 등 국내외 보안 기관 및 사용 중인 솔루션 제조사의 공식 홈페이지를 통해 주기적으로
취약점 정보를 수집해야 함
• ‌수집한 정보를 자산 현황과 대조하여 영향 범위를 파악하고, 해당 시스템을 대상으로 보안 점검을
수행
▶ ‌우주 기업의 보안 담당자, 시스템 관리자, IT 운영자 등 지정된 인력은 취약점 점검 시 이력
관리를 위해 점검일시, 점검 대상, 점검방법, 점검 내용 및 결과, 발견사항, 조치사항 등이 포함된
보고서를 작성해야 함
⊙ ‌식별된 취약점은 위험 평가 결과를 반영하여 우선순위를 결정하고, 우선순위에 따라 조치해야 한다.
▶ ‌보안 담당자 및 시스템 운영자는 위험 평가 결과로 정해진 우선순위에 따라 패치 적용, 설정 변경,
취약한 소스코드 수정 등 조치 수행
▶ ‌불가피하게 조치할 수 없는 취약점에 대해서는 그 사유를 명확하게 확인하고, 이에 따른 위험성,
보완대책 등을 책임자에게 보고해야 함
⊙ ‌시스템 결함 식별 활동을 주기적으로 수행해야 한다.
▶ ‌시스템 결함 식별 활동은 새로운 결함을 파악하여 보고하고, 조치하는 과정까지를 의미함
▶ ‌시스템 결함 및 취약점 식별을 위해 공급업체 정보, 소프트웨어 정보, 버전 정보, 현재 배포
상태(예: 어떤 시스템에 어떤 소프트웨어가 설치되어 있는지)를 포함한 정확한 자산목록을
보유해야 함
▶ ‌소프트웨어나 펌웨어 공급업체 알림 및 업데이트 정보를 주기적으로 검토하고, 결함을 식별해야
함
▶ ‌우주 기업의 보안 담당자, 시스템 관리자, IT 운영자 등 지정된 인력은 공개된 소프트웨어 및
펌웨어 결함을 식별하여 조치를 수행하고, 그 결과를 보안 담당자 및 관리 책임자에게 보고해야
함
▶ ‌결함 조치 이력 관리를 위해 조치 일시, 조치 대상, 조치 방법, 조치 내용 및 결과, 발견된 결함
사항, 조치 내역 등이 포함된 보고서 작성
▶ ‌우주 기업은 시스템에서 발견된 결함을 조치하기 위해 CWE, CVE와 같은 가용자원을 활용할 수
있음
▶ ‌우주 기업은 식별된 결함이 시스템에 미치는 영향을 분석하고, 시스템 중요도에 따라 주기적으로
업데이트를 수행해야 함

---
<!-- Page 101 -->

## 제3장 우주 보안모델 해설  | 101

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ CMMC
• ‌SI.L2-3.14.1 결함 교정[CUI데이터] : 적절한 시기에 시스템 결함을 파악하고 보고하고 수정한다.
• ‌RA.L2-3.11.2 취약점 스캔 : 조직의 시스템과 애플리케이션의 취약점을 주기적으로 검사하고, 해당
시스템과 애플리케이션에 영향을 미치는 새로운 취약점이 확인될 때마다 검사한다.
• ‌RA.L2-3.11.3 취약성 개선 : 위험성 평가에 따라 취약성을 해결한다.
⊙ K-RMF
• ‌SI-1 결함 교정

## 1. 시스템의 결함을 식별하여 보고 및 교정해야 한다.

2. ‌결함 교정과 관련된 업데이트(소프트웨어, 펌웨어)를 설치하기 전에 효과성 및 잠재적 부작용을
확인하기 위해 테스트해야 한다.

## 3. 보안 관련 소프트웨어 및 펌웨어의 업데이트를 [조직이 지정한 기한] 이내에 설치해야 한다.


## 4. 결함 교정을 조직의 형상관리 절차에 반영해야 한다.

• ‌PA-7 취약점 점검
1. ‌[조직이 지정한 주기 또는 프로세스에 따라 임의로] 시스템 및 응용프로그램의 취약점을 점검해야 한다.
그리고 시스템 및 프로그램들에 영향을 줄 수 있는 새로운 취약점을 식별(보고)하면 점검을 실시해야
한다.
2. ‌다음과 같은 표준을 사용하여 도구 간의 상호운용성을 높이고, 취약점 관리 절차의 일부를 자동화하는
취약점 점검 도구 및 기술을 사용해야 한다.

가. 플랫폼 관련 정보, 소프트웨어 결함, 취약한 환경설정 등에 대한 목록(Enumeration)

나. 체크리스트와 시험 절차의 서식/형식 정의

다. 취약점 영향도 판단

## 3. 보안통제항목 평가 결과와 취약점 점검 보고서를 분석해야 한다.

4. [조직이 지정한 대응시간] 내 조직의 위험판단에 따라 취약점을 해결해야 한다.
5. ‌다른 시스템에 있는 유사한 취약점(예 : 조직적인 약점이나 결점들)을 제거·완화할 수 있도록 취약점
점검 절차와 보안통제항목 평가에서 획득한 정보를 [조직이 지정한 직책]과 공유해야 한다.
6. ‌새로운 취약점을 점검(식별)하기 위해 업데이트 능력을 갖춘 취약점 점검 도구를 사용해야 한다.
⊙ NIS2
• ‌6.6 패치관리 : 변경·취약점·위험 관리 등 기존 관리 체계와 연계된 공식적인 패치 관리 절차를 수립하고
시행해야 한다.
• ‌6.10 취약점 관리 및 공개 : 네트워크 및 정보 시스템의 기술적 취약점에 관한 정보를 입수하고, 이러한
취약점에 대한 노출 정도를 평가하며, 취약점 관리를 위해 적절한 조치를 취해야 한다.
⊙ ISMS-P
• ‌2.11.2 취약점 점검 및 조치 : 정보시스템의 취약점이 노출되어 있는지를 확인하기 위하여 정기적으로
취약점 점검을 수행하고, 발견된 취약점에 대해서는 신속하게 조치하여야 한다. 또한 최신 보안취약점의
발생 여부를 지속적으로 파악하고, 정보시스템에 미치는 영향을 분석하여 조치하여야 한다.

---
<!-- Page 102 -->
102 | 우주 보안 모델 해설 및 적용사례집
SI-02
악성코드 방지
항목 내용
악성코드 식별 및 제거를 위해 시스템에 악성코드 방지 솔루션을 설치하고 파일
다운로드 시 실시간으로 검사해야 한다.
목적
바이러스, 웜, 랜섬웨어 등의 악성코드 유입 및 확산을 예방하여 정보시스템의
무결성 및 가용성을 확보하기 위함이다.
주요
확인사항
y ‌악성코드 방지 솔루션 적용이 필요한 우주 시스템을 식별하고 있는가?
y ‌악성코드 검사 주기를 정의하고, 주기에 따라 검사를 수행하며, 외부 파일
다운로드 및 실행 시 실시간 검사를 수행하는가?
y ‌악성코드 방지 솔루션의 신규 버전이 출시될 때마다 업데이트하고 있는가?
세부 설명
⊙ ‌악성코드 방지 솔루션 적용이 필요한 우주 시스템을 식별해야 한다.
▶ ‌악성코드란 사용자 컴퓨터에 악의적인 영향을 끼칠 수 있는 모든 소프트웨어의 총칭으로, 감염
방법, 목적, 행위에 따라 바이러스, 웜, 트로이 목마 등을 의미
• ‌바이러스(virus): 정상적인 파일이나 시스템 영역에 침입하여 그곳에 자신의 코드를 삽입하거나
설치하는 프로그램
• ‌웜(worm): 바이러스처럼 다른 파일을 감염시키는 것이 아닌 자기 자신을 레지스트리에
등록하거나 복사본을 생성하여 전파하는 등의 독자적으로 실행되는 악성코드
• ‌트로이 목마(trojan horse): 정상적인 소프트웨어의 형태를 띠지만 악의적인 행위를 포함하고
있는 악성코드
• ‌스파이웨어(spyware): 사용자의 PC에서 사전 동의 없이 설치되어 컴퓨터의 정보와 개인 정보를
수집하는 악성코드
• ‌랜섬웨어(ransomware): 사용자의 문서와 사진 등을 암호화 시켜 일정 시간 안에 일정 금액을
지불하면 암호를 풀어주는 방식으로 사용자에게 금전적인 요구를 하는 악성코드
▶ ‌노트북, 컴퓨터, 모바일 기기, 서버, 워크스테이션 등 악성코드 유입 경로가 존재하는 모든
정보자산을 악성코드 방지 솔루션 적용 대상으로 식별하여 문서화하고, 주기적으로 최신화해야
함
• ‌악성코드 방지 솔루션이란 컴퓨터나 네트워크 시스템에 침입하는 바이러스, 웜, 트로이 목마,
랜섬웨어 등 악성 소프트웨어를 실시간으로 탐지하고 차단, 제거하는 솔루션을 의미
⊙ ‌악성코드 검사 주기를 정의하고, 주기에 따라 검사를 수행하며, 외부 파일 다운로드 및 실행 시
실시간 검사를 수행한다.

---
<!-- Page 103 -->

## 제3장 우주 보안모델 해설  | 103

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌백신 소프트웨어 등 보안프로그램을 통해 최신 악성코드 예방 및 탐지 활동을 주기적으로
수행해야 함
▶ ‌악성코드로부터 우주 시스템을 보호하기 위하여 다음과 같은 내용을 포함한 보호대책을
수립·이행해야 함
• ‌불분명한 이메일 및 파일 열람 금지
• ‌허가받지 않은 프로그램 다운로드 및 설치 금지
• ‌정보시스템, 업무용 컴퓨터에 P2P, 웹 하드 등과 같은 비인가 프로그램 설치 금지
▶ ‌파일 다운로드 또는 실행 시 실시간 검사를 수행해야 함
⊙ ‌악성코드 방지 솔루션의 새로운 버전이 출시될 때마다 업데이트해야 한다.
▶ ‌백신 소프트웨어 등 보안프로그램은 최신 상태로 유지하고, 필요 시 긴급 보안 업데이트를
수행해야 함
▶ ‌백신 업데이트 주기 준수 : 자동 업데이트 또는 일 1회 이상 업데이트
▶ ‌악성 프로그램 관련 경보가 발령되거나 긴급 업데이트 공지가 있는 경우 이에 따른 업데이트를
수행해야 함
▶ ‌백신 중앙관리시스템을 이용하여 백신 프로그램을 관리하는 경우 관리서버에 대한 접근통제,
배포 파일에 대한 무결성 검증 등 보호대책 마련
관련 기준
⊙ CMMC
• ‌SI.L2-3.14.2 악성 코드 보안 [CUI DATA] : 조직 시스템 내의 지정된 위치에서 악성코드로부터 보호를
제공한다.
• ‌SI.L2-3.14.5 시스템 및 파일 스캐닝 [CUI DATA] : 조직 시스템에 대한 주기적 검사를 수행하고, 외부
소스에서 파일을 다운로드하거나 열거나 실행할 때 실시간으로 파일을 검사한다.
• ‌SI.L2-3.14.4 악성코드 보안 업데이트 [CUI DATA] : 새로운 릴리스가 출시되면 악성코드 보호 솔루션을
업데이트 한다.
⊙ K-RMF
• ‌SI-2 악성코드 방지

## 1. 악성코드 식별 및 제거를 위해 시스템의 입출력 지점에서 악성코드 방지 메커니즘을 사용해야 한다.

2. ‌악성코드 방지 메커니즘의 새로운 버전이 출시되면 조직의 형상관리 정책 및 절차에 부합하게
업데이트를 수행해야 한다.

## 3. 악성코드 방지 메커니즘을 다음과 같이 설정해야 한다.


가. ‌[조직이 지정한 주기]마다 악성코드 점검을 수행하고 외부 파일(새롭게 획득한 파일)을 열거나
다운로드 또는 실행할 때 [단말 또는 네트워크 입출력 지점]에서 실시간 점검을 수행해야 한다.

---
<!-- Page 104 -->
104 | 우주 보안 모델 해설 및 적용사례집

나. ‌악성코드 탐지 시 [①악성코드 차단 ②악성코드 격리 ③관리자에게 경보 전송 ④기타 정의한 조치]
중 하나 이상을 수행해야 한다.
4. ‌악성코드 탐지 및 제거 중에 오탐을 식별하고 그로 인해 시스템의 가용성에 미치는 잠재적인 영향성을
중점에 두고 다루어야 한다.
• ‌SI-2-1 자동 업데이트 : 악성코드 방지 메커니즘을 자동으로 업데이트해야 한다.
⊙ NIS2
• ‌6.9 악성코드 및 무단 소프트웨어 방어 : 악성 코드 및 승인되지 않은 소프트웨어의 위협으로부터
네트워크와 정보 시스템을 안전하게 보호해야 한다.
⊙ ISMS-P
• ‌2.11.2 취약점 점검 및 조치 : 정보시스템의 취약점이 노출되어 있는지를 확인하기 위하여 정기적으로
취약점 점검을 수행하고, 발견된 취약점에 대해서는 신속하게 조치하여야 한다. 또한 최신 보안취약점의
발생 여부를 지속적으로 파악하고, 정보시스템에 미치는 영향을 분석하여 조치하여야 한다.
• ‌2.10.9 악성코드 통제 : 바이러스·웜·트로이목마·랜섬웨어 등의 악성코드로부터 개인정보 및 중요정보,
정보시스템 및 업무용 단말기 등을 보호하기 위하여 악성코드 예방·탐지·대응 등의 보호대책을 수립·
이행하여야 한다.

---
<!-- Page 105 -->

## 제3장 우주 보안모델 해설  | 105

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SI-03
보안 경보, 권고
항목 내용
시스템 보안 경고와 권고를 모니터링하고 이에 대한 대책을 수립해야 한다.
목적
시스템 보안 경보 및 권고를 지속적으로 모니터링하고, 관련 위험도를 평가하여
도출된 대응조치를 이행함으로써 시스템의 무결성과 가용성을 유지하기
위함이다.
주요
확인사항
y ‌시스템 보안 경보와 권고사항을 지속적으로 모니터링하고 있는가?
y ‌수집된 시스템 보안 경보 및 권고사항이 시스템에 미치는 영향을 분석하여
대책을 수립·이행하고 있는가?
세부 설명
⊙ ‌시스템 보안 경보와 권고사항을 지속적으로 모니터링해야 한다.
▶ ‌소프트웨어 공급업체, 구독 서비스, 관련 산업 정보 공유 및 분석 센터 등을 통해 보안 경보 및
권고를 수집해야 함
▶ ‌우주 기업은 국가사이버안보센터(NCSS), 한국인터넷진흥원(KISA) 등 신뢰할 수 있는 전문
기관으로부터 보안 경보, 권고, 지침을 수신하고 검토해야 함
보안 경보 및 권고사항 수신 방법 (예시)
y ‌이메일 알림 구독
y ‌RSS28 피드 구독
y ‌관련 회의 참석 등
출처 : CMMC Assessment Guide Level 2SI.L2-3.14.3
▶ ‌신뢰할 수 있는 국내외 보안 경보 및 권고를 제공하는 기관은 다음 표와 같음
28	 ‌RSS(Really Simple Syndication/Rich Site Summary): 뉴스나 블로그 등 콘텐츠 업데이트가 잦은 웹사이트의 업데이
트된 정보를 쉽게 확인하고 이용할 수 있는 데이터형식

---
<!-- Page 106 -->
106 | 우주 보안 모델 해설 및 적용사례집
국내외 보안 관련 정보 제공 기관
기관명
설명
한국인터넷진흥원 KrCERT/
CC
y ‌국내외 최신 보안 취약점 정보(보안 공지), 사이버 위협 동향,
악성코드 분석 정보, 긴급 보안 권고 및 경보를 실시간으로 제공
국가사이버안보센터
y ‌국가 차원의 사이버 위협 분석 및 평가 정보, 주요 기관을 대상으로
하는 특정 공격 및 방어 지침을 제공
과학기술정보통신부
y ‌정보보호 정책 및 법규 관련 지침, 정보보호 취약점 분석 및 평가
관련 가이드라인 등을 발표
CISA29
y ‌전 세계적인 사이버 위협 경고 및 기술 권고, 주요 취약점에 대한
긴급 지시(Directives), 악성코드 분석 및 대응 가이드를 발표
NIST30
y ‌NVD (National Vulnerability Database) 관리를 통해 모든
CVE(Common Vulnerabilities and Exposures) 목록 및 표준
CVSS 심각도 점수를 제공
⊙ ‌수집된 시스템 보안 경보 및 권고사항이 시스템에 미치는 영향을 분석하여 대책을 수립하고,
이행해야 한다.
▶ ‌보안 담당자는 외부 전문 기관으로부터 수집한 시스템 보안 경보 및 권고사항이 우주 시스템에
미치는 영향을 분석해야 함
▶ ‌취약점 및 위협 대응을 위해 필요한 경우, 수집한 보안 경보 및 권고사항을 지침 또는 정책에
반영해야 함
▶ ‌수집한 시스템 보안 경보 및 권고사항은 관련 시스템 운영자 및 임직원을 대상으로 보안 공지,
조치 지침 등의 형태로 전파해야 함
▶ ‌보안 담당자는 보안 경보 및 권고사항과 관련된 위험을 평가하고, 필요한 조치를 수행해야 함
• ‌보안 패치 적용(소프트웨어/펌웨어 버전 업데이트)
• ‌보안 설정 강화 (예: 불필요한 포트 비활성화, 암호화 강화 등)
• ‌내부 보안 지침 및 절차 업데이트
• ‌협력사 등에 위험 정보 전달 등
29	 ‌CISA(Cybersecurity and Infrastructure Security Agency): 사이버보안 및 인프라 보안국
30	 NIST(National Institute of Standards and Technology): 미국 국립표준기술 연구소

---
<!-- Page 107 -->

## 제3장 우주 보안모델 해설  | 107

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ CMMC
• ‌SI.L2-3.14.3 보안 경고 및 권고 : 시스템 보안 경고와 권고를 모니터링하고 이에 대한 조치를 취한다.
⊙ K-RMF
• ‌SI-4 보안 경보, 권고, 지침 :

## 1. 지속적으로 [외부 조직]으로부터 시스템과 관련된 보안경보, 권고사항, 지침을 수집해야 한다.


## 2. 필요 시 조직 내부의 보안경보, 권고, 지침을 생산해야 한다.


## 3. 보안경보, 권고, 지침을 [조직이 지정한 직책, 부서, 또는 외부 조직]에 전파해야 한다.

4. ‌정해진 기한 내에 보안 관련 지침을 준수해야 하며, 이행하지 못한 정도를 지침 발행 부대(서)에 해당
보고(통보)해야 한다.

---
<!-- Page 108 -->
108 | 우주 보안 모델 해설 및 적용사례집
SI-04
시스템 및 통신 트래픽 모니터링
항목 내용
시스템의 무단 사용을 모니터링하고 송·수신되는 네트워크 트래픽을 주기적으로
모니터링해야 한다.
목적
정보시스템 및 네트워크의 비정상적인 트래픽을 실시간 또는 주기적으로
탐지·분석하여 시스템의 기밀성·무결성·가용성을 보장하기 위함이다.
주요
확인사항
y ‌시스템의 무단 사용을 모니터링하고 송·수신되는 네트워크 트래픽을
모니터링하는 정책/절차가 정의되어 있는가?
y ‌시스템 공격 및 잠재적 공격 징후를 탐지하기 위해 인바운드 및 아웃바운드
통신 트래픽을 포함한 네트워크 모니터링을 수행하고 있는가?
y ‌시스템 및 통신 트래픽 모니터링 결과를 분석하고 대응하고 있는가?
세부 설명
⊙ ‌시스템의 무단 사용을 모니터링하고 송·수신되는 네트워크 트래픽을 모니터링하는 정책 및 절차가
정의해야 한다.
▶ ‌네트워크 트래픽 모니터링 정책 및 절차에는 아래의 내용이 포함되어야 함
• ‌모니터링 대상(예: 인바운드 트래픽, 아웃바운드 트래픽 등)
• ‌모니터링 장치(예: 방화벽, IDS/IPS, VPN 등 보안 솔루션) 및 기술
• ‌이상징후 탐지 기준
• ‌탐지 시 대응 절차
• ‌모니터링 로그 및 기록 관리 절차
⊙ ‌시스템 공격 및 잠재적 공격 징후를 탐지하기 위해 인바운드 및 아웃바운드 통신 트래픽을 포함한
네트워크 모니터링을 수행해야 한다.
▶ ‌모니터링 장비는 내부 및 외부 시스템 경계에 배치되어 인바운드 트래픽, 아웃바운드 트래픽을
포함한 모든 통신 내역을 모니터링 해야 함
모니터링 대상 (예시)
y ‌아웃바운드 및 인바운드 네트워크, 시스템, 애플리케이션 트래픽
y ‌시스템, 서버, 네트워크 장비, 모니터링 시스템, 주요 애플리케이션 등에 대한 접근
y ‌보안 도구 로그(예: 안티바이러스, 침입 탐지 시스템(IDS), 침입 방지 시스템(IPS), 웹 필터,
방화벽, 데이터 유출 방지 등)
y ‌네트워크 장비 로그

---
<!-- Page 109 -->

## 제3장 우주 보안모델 해설  | 109

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌아래와 같은 내용을 모니터링 해야 함
공격 및 잠재적 공격 징후 등 이상행위 (예시)
y ‌내부 트래픽 중 악성코드의 존재를 나타내는 것
y ‌비업무 시간에 탐지된 비정상적 활동
y ‌외부로 유출되는 비정상적인 크기/개수의 파일
y ‌외부 시스템과의 통신 흔적
y ‌악성코드 활동 또는 알려진 IP주소나 네트워크 도메인(예: 봇넷 명령 및 제어 서버 연관)에서
발생하는 트래픽
y ‌알려진 공격 특성(예: 서비스 거부 공격, 버퍼 오버플로우)
y ‌병목 현상 및 과부하(예: 네트워크 대기열, 지연, 지터)
y ‌시스템 또는 정보에 대한 무단 접근(실제 또는 시도)
y ‌비즈니스 애플리케이션, 시스템, 네트워크에 대한 무단 스캔
y ‌보호 자원(예: DNS 서버, 웹 포털, 파일 시스템)에 대한 성공 및 실패한 접근 시도
⊙ ‌시스템 및 통신 트래픽 모니터링 결과를 분석하고 대응해야 한다.
▶ ‌시스템 및 통신 트래픽 모니터링 분석 결과를 기록하고 문서화해야 함
▶ ‌시스템 및 통신 트래픽 분석 결과는 정기적으로 검토하여 이상행위 및 공격징후 탐지의 누락 방지
▶ ‌이상행위 및 공격징후 대응 결과를 기록하고 문서화
▶ ‌탐지·대응한 이상행위 및 공격 정보를 관련 조직 및 인원에게 공유하여 동일 사고 예방 필요
관련 기준
⊙ CMMC
• ‌SI.L2-3.14.6 공격에 대한 통신 모니터링 : 인바운드 및 아웃바운드 통신 트래픽을 포함한 조직 시스템을
모니터링하여 공격과 잠재적 공격 지표를 탐지한다.
• ‌SI.L2-3.14.7 무단 사용 식별 : 조직 시스템의 무단 사용을 식별한다.
⊙ K-RMF
• ‌SI-3-4 내외부 통신 트래픽 : 비정상/비인가 활동 또는 조건에서 송ㆍ수신되는 트래픽을 [조직이 지정한
주기]마다 모니터링해야 한다.
• ‌SI-3 시스템 모니터링 :

## 1. 다음을 수행하기 위해서 시스템을 모니터링 해야 한다.


가. [조직의 모니터링 목표]를 세워서 공격과 잠재적 공격 징후를 탐지

나. 비인가 로컬, 네트워크, 원격연결을 탐지
2. [조직이 지정한 기술과 방식]을 사용하여 인가되지 않은 시스템 사용을 식별해야 한다.

## 3. 다음에 따라 모니터링 장치를 배치해야 한다.


---
<!-- Page 110 -->
110 | 우주 보안 모델 해설 및 적용사례집

가. 조직이 지정한 필수 정보를 수집하기 위해 시스템 내 전략적으로

나. 조직에서 관심 갖는 특정 거래(전송) 유형을 추적하기 위해 시스템 내부에 일시적으로 배치

## 4. 침입탐지 도구에서 얻은 정보를 비인가 접속, 변경, 삭제로부터 보호해야 한다.

5. ‌첩보 및 믿을 수 있는 정보 출처에 근거하여 조직의 운영, 자산, 개인 및 기타 조직 또는 국가에 위험을 줄
수 있는 경우 시스템 모니터링 활동 수준을 상향시켜야 한다.

## 6. 모니터링 활동이 관련 법령(규정) 따르는지 법적 자문을 구해야 한다.

7. [시스템 모니터링 정보]를 [필요시 또는 일정 주기]마다 [조직이 지정한 직책]에게 제공해야 한다.
⊙ NIS2
• ‌3.2 모니터링 및 로깅 : 이벤트를 탐지하고 그에 따라 대응하여 영향을 완화하기 위해, 자신의 네트워크와
정보 시스템상의 활동을 모니터링하고 기록(log)하는 절차를 수립하고 도구를 사용해야 한다.
⊙ ISMS-P
• ‌2.11.3 이상행위 분석 및 모니터링 : 내·외부에 의한 침해시도, 개인정보유출 시도, 부정행위 등을
신속하게 탐지·대응할 수 있도록 네트워크 및 데이터 흐름 등을 수집하여 분석하며, 모니터링 및 점검
결과에 따른 사후조치는 적시에 이루어져야 한다.

---
<!-- Page 111 -->

## 제3장 우주 보안모델 해설  | 111

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제5절
시스템/서비스 운영관리(SO)
SO-01
유지보수 통제
항목 내용
시스템 유지관리에 사용되는 도구, 기술, 메커니즘 및 인력을 통제해야 한다.
- ‌원격 유지보수 시 사전승인, 강화된 인증, 유지보수 활동 기록, 업무 종료 시
세션 종료
- 유지보수 인력 관리 감독
- 유지보수용 저장매체 악성코드 검사
- 원격 유지보수 시스템 외부 반출 전 정보 소거
목적
시스템 유지보수에 필요한 인력, 도구 및 원격 접근을 통제·관리하여,
정보자산의 기밀성과 무결성을 보호하고 안정적인 시스템 운영을 보장하기
위함이다.
주요
확인사항
y ‌시스템의 안정적인 운영을 위해 유지보수를 수행하고, 유지보수에 필요한
도구, 기술, 솔루션, 인력을 통제하는가?
y ‌유지보수를 위한 매체를 시스템에 사용하기 전 악성코드를 검사하고, 외부
반출 전 정보 소거 절차를 수행하는가?
y ‌유지보수를 위해 외부에서 원격 접속 시, 다중인증을 적용하고, 업무 종료 시
자동으로 세션을 종료하는가?
세부 설명
⊙ ‌시스템의 안정적인 운영을 위해 유지보수를 수행하고, 유지보수에 필요한 도구, 기술, 솔루션,
인력을 통제해야 한다.
▶ ‌유지보수 작업이 필요한 경우에 작업신청 및 수행 절차를 수립하고 이행
• ‌작업 절차 : 작업 신청, 승인, 작업 기록 작성 등
• ‌작업 기록 : 작업 일시, 작업목적 및 내용, 작업업체 및 담당자명, 검토자 및 승인자 등
• ‌통제 방안 : 작업 수행을 출입 절차, 작업내역에 대한 책임추적성 확보 및 모니터링 방안 등
▶ ‌유지보수 도구는 최신 상태를 유지하고, 악성코드 감염 여부를 검사 후 사용해야 함
▶ ‌유지보수 기술(절차)는 사전에 승인을 받아야 하며, 승인된 기술(절차)에 따라 수행
▶ ‌유지보수 업무는 사전에 승인된 인원만 수행하고, 관리자의 감독하에 작업을 수행해야 함

---
<!-- Page 112 -->
112 | 우주 보안 모델 해설 및 적용사례집
▶ ‌유지보수 작업을 위해 협력업체 직원에게 부여하는 특수 권한은 필요시에만 생성하고, 업무 종료
후에는 즉시 삭제 또는 정지
▶ ‌외부 인력이 유지보수를 수행하는 경우 비밀유지 계약 체결
⊙ ‌유지보수를 위한 매체를 시스템에 사용하기 전 악성코드를 검사하고, 외부 반출 전 정보 소거 절차를
수행해야 한다.
▶ ‌유지보수를 위한 매체 반·출입 통제 절차를 다음 사항을 포함하여 수립하고 이행해야 함
• 매체 반입 신청
• 관리자 사전 승인
• 반·출입 관리대장 작성
• 반·출입 매체 대상 악성코드 검사
• 반·출입 내역 주기적 검토
▶ ‌외부에서 유지보수를 위해 반입한 저장매체 사용 전 악성코드 검사 수행
• 보조 저장매체 자동실행 방지 적용
• 보조 저장매체 사용 전 클린 PC를 통해 악성코드 검사 수행
▶ ‌매체를 외부로 반출하기 전 중요정보가 복구되지 않도록 덮어쓰기 등의 방법으로 정보 소거
⊙ ‌유지보수를 위해 외부에서 원격 접속 시, 다중인증을 적용하고, 업무 종료 즉시 세션을 종료해야 한다.
▶ ‌원격 유지보수 작업 전 원격 접속 신청 및 승인
▶ ‌외부에서 유지보수를 위해 원격 접속 시 다중인증, 통신 암호화 등 안전한 접속 수단을 통해 접속
▶ ‌원격 유지보수 업무는 승인된 기간동안만 한시적으로 수행하고 작업 종료 시 즉시 세션을
종료해야 함
관련 기준
⊙ CMMC
• ‌MA.L2-3.7.1 유지 보수 수행 : 조직 시스템에 대한 유지 관리를 수행한다.
• ‌MA.L2-3.7.2 시스템 유지보수 통제 : 시스템 유지관리에 사용되는 도구, 기술, 메커니즘 및 인력에 대한
통제를 제공한다.
• ‌MA.L2-3.7.3 장비 CUI 정보 소거(SANITIZATION) : 현장 외부 유지관리를 위해 제거한 장비는 CUI가
없는지 정보 소거해야 한다.
• ‌MA.L2-3.7.4 매체 검사 : 조직 시스템에서 미디어를 사용하기 전에 진단 및 테스트 프로그램이 포함된
미디어를 검사하여 악성코드가 있는지 확인한다.
• ‌MA.L2-3.7.5 비지역 유지보수 : 외부 네트워크 연결을 통해 비로컬 유지관리 세션을 설정하려면 다중
인증을 요구하고 비로컬 유지관리가 완료되면 해당 연결을 종료한다.

---
<!-- Page 113 -->

## 제3장 우주 보안모델 해설  | 113

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌MA.L2-3.7.6 유지 보수 인력 : 필요한 접근 권한이 없는 유지관리 인력의 유지관리 활동을 감독한다.
⊙ K-RMF
• ‌MA-1 유지보수 통제 :
1. ‌제조사/판매사 및 조직의 요구에 맞게 시스템 구성요소의 유지보수와 정비 일정을 정하고, 수행하며,
기록 및 유지하고, 검토해야 한다.

## 2. 모든 유지보수 활동을 승인 및 모니터링해야 한다.

3. ‌유지보수를 위해 시스템 또는 시스템 구성요소가 시설에서 반출될 때 [조직에서 지정한 직책]에게
승인을 받아야 한다.

## 4. 유지보수 활동을 위해 시설에서 반출이 필요한 경우 관련 매체에 대한 정보소거를 수행해야 한다.

5. ‌잠재적으로 영향을 받는 모든 보안통제항목들을 확인하여 해당 항목들이 유지보수 이후에도 정상적으로
적용이 되는지 검증해야 한다.
6. [조직이 지정한 유지보수 관련 정보]를 조직의 유지보수 기록에 포함해야 한다
• ‌MA-4-2 대등한 보안수준 또는 정보소거 : 원격 유지보수 수행 시 다음 중 하나를 만족해야 한다.
1. ‌유지보수 대상 시스템의 보안수준과 대등한 보안수준을 구현하고 있는 시스템을 통해 원격 유지보수를
수행해야 한다.
2. ‌원격 유지보수가 필요한 시스템 구성요소를 시스템에서 제거하고, 시설에서 반출되기 전에 정보소거를
시행해야 한다. 이후, 유지보수가 완료된 구성요소는 시스템에 연결하기 이전에 정보소거 및 악성코드
검사를 실시해야 한다.
• ‌MA-3-2 저장매체 점검 : 유지보수 도구가 포함된 저장매체를 시스템에 연결 및 사용하기 전에 악성코드
검사를 실시해야 한다.
• ‌MA-4 원격 유지보수 :

## 1. 원격 유지보수 활동을 승인하고 모니터링해야 한다.

2. ‌원격 유지보수 활동은 조직 정책에서 승인하는 범위 내에서 사전 계획이 문서화된 경우에만 허용해야 한다.

## 3. 원격 유지보수 활동을 위한 세션 수립 시 강화된 인증방식을 사용해야 한다.


## 4. 원격 유지보수 활동을 기록하고 유지해야 한다.


## 5. 원격 유지보수 활동 종료 시 세션 및 네트워크 연결을 종료해야 한다.

• ‌MA-5 유지보수 인원보안 : 원격 유지보수 수행 시 다음을 통해 원격 유지보수 세션을 보호해야 한다.
1. [조직이 지정한 재전송 공격에 대응할 수 있는 인증수단]를 적용해야 한다.

## 2. 다음 중 하나 이상의 방법을 통해 원격 유지보수 세션을 다른 네트워크 세션과 분리해야 한다.


가. 통신 경로를 물리적으로 분리

나. 암호화를 기반으로 통신 경로를 논리적으로 분리
⊙ ‌ISMS-P
• ‌2.10.7 보조저장매체 관리 : 보조저장매체를 통하여 개인정보 또는 중요정보의 유출이 발생하거나
악성코드가 감염되지 않도록 관리 절차를 수립·이행하고, 개인정보 또는 중요정보가 포함된 보조저장
매체는 안전한 장소에 보관하여야 한다.
• ‌2.6.6 원격접근 통제 : 보호구역 이외 장소에서의 정보시스템 관리 및 개인정보 처리는 원칙적으로
금지하고, 재택근무·장애대응·원격협업 등 불가피한 사유로 원격접근을 허용하는 경우 책임자 승인,
접근 단말 지정, 접근 허용범위 및 기간 설정, 강화된 인증, 구간 암호화, 접속단말 보안 (백신, 패치 등) 등
보호대책을 수립·이행하여야 한다.

---
<!-- Page 114 -->
114 | 우주 보안 모델 해설 및 적용사례집
SO-02
시스템 감사 및 감사기록 분석, 보고
항목 내용
불법적이거나 승인되지 않은 시스템 활동을 모니터링, 분석 조사 및 보고하기
위한 시스템 감사 로그 및 기록을 생성 및 보관해야 하고 부적절하거나 비정상적
활동을 분석 및 보고해야 한다. 또한 감사 정보를 보호하고 감사 로깅 오류 시
경고한다.
목적
시스템 감사로그를 생성하여 무단 접근 및 비정상 활동을 탐지·조사하고
책임추적성과 무결성을 확보하기 위함이다.
주요
확인사항
y ‌불법적이거나 비인가 행위를 식별하고, 사용자를 추적할 수 있도록 감사
로그를 생성하고 보관하고 있는가?
y ‌감사 로깅 오류 또는 실패 시 경고하는 기능을 적용하고 있는가?
y ‌감사 로그를 비인가 접근, 수정·삭제로부터 보호하고, 감사 로깅 기능 관리
권한을 일부 사용자로 제한하는가?
y ‌기록된 이벤트를 주기적으로 검토하여 업데이트 하고있는가?
y ‌의심스러운 활동에 신속히 대응할 수 있도록 모든 시스템 로그를 통합하여
분석하고, 보고하고 있는가?
세부 설명
⊙ ‌불법적이거나 비인가 행위를 식별하고, 사용자를 추적할 수 있도록 감사 로그를 생성하고 보관해야
한다.
▶ ‌시스템에 대한 로그관리 절차를 수립하고 필요한 로그를 생성하여 보관해야 함
▶ ‌이상행위 판단을 위한 정보시스템, 보안시스템, 응용프로그램, 네트워크 장비 등의 로그를
생성하고 보관해야 함
주요 로그유형 (예시)
y ‌시스템 이벤트 로그 : 운영체제 구성요소에 의하여 발생하는 로그(시스템 시작, 종료, 상태, 에러
코드 등)
y ‌네트워크 이벤트 로그 : IP주소 할당, 주요 구간 트래픽 로그
y ‌보안시스템 로그 : 관리자 접속, 보안정책(룰셋) 등록·변경·삭제 등
y ‌보안관련 감사 로그 : 사용자 접속기록, 인증 성공/실패 로그, 파일 접근, 계정
y ‌기타 정보보호 관련 로그

---
<!-- Page 115 -->

## 제3장 우주 보안모델 해설  | 115

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ 감사 로깅 오류 또는 실패 시 경고하는 기능을 적용해야 한다.
▶ ‌감사 로그 및 감사 로그 설정을 임의로 수정·삭제하지 못하도록 일부 제한된 인원에게만 감사
로깅 기능 관리 권한을 부여하고, 주기적으로 권한 부여 현황 검토
▶ ‌실시간 경보가 필요한 이벤트의 감사 로깅 실패 시, 이메일, SMS, 관제 대시보드 팝업 알림 등을
통해 관련 시스템 관리자에게 알려야 함
감사 로깅 실패 유형 (예시)
y ‌소프트웨어 또는 하드웨어 오류 : 서버 중단, 로깅 서비스 프로세스 강제 종료 등
y ‌로그 수집 설정 오류
y ‌감사 로그 저장 용량 초과 등
▶ ‌관련 시스템 관리자는 감사 로깅 실패를 인지한 즉시 로그 수집을 재개하고, 중단 원인을
파악해야 함
⊙ ‌감사 로그를 비인가 접근, 수정·삭제로부터 보호하고, 감사 로깅 기능 관리 권한을 일부 사용자로
제한한다.
▶ 시스템 감사 로그는 위·변조되지 않도록 안전하게 보관해야 함
감사 로그의 안전한 보관 방법 (예시)
y ‌감사 로그 백업을 수행하여 별도의 보조저장매체나 별도의 저장장치, 오브젝트, 스토리지 등에
보관
y ‌감사 로그에 대한 위·변조를 방지하기 위해 CD-ROM, DVD-R, WORM(Write Once Read
Many) 등과 같은 덮어쓰기 방지 매체 사용
y ‌감사 로그를 수정 가능한 매체(하드디스크, 자기 테이프 등)에 백업하는 경우에는 무결성 보장을
위해 위·변조 여부를 확인할 수 있는 정보(MAC값, 전자서명값 등)를 별도의 장치에 보관·관리 등
⊙ ‌기록된 이벤트를 주기적으로 검토하여 업데이트해야 한다.
▶ ‌조직은 시스템 이벤트 로그(시스템 시작, 종료, 상태, 에러 코드 등), 네트워크 이벤트
로그(IP주소 할당, 주요 구간 트래픽 로그 등) 등 기록된 이벤트를 주기적으로 검토하여
업데이트해야 함
▶ ‌신규 보안 위협 또는 신규 이벤트가 식별된 경우 이벤트 유형을 업데이트 해야 함

---
<!-- Page 116 -->
116 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌의심스러운 활동에 신속히 대응할 수 있도록 모든 시스템 로그를 통합하여 분석하고, 보고해야 한다.
▶ ‌의심스러운 활동을 조사하고 대응하기 위해 로그 검토 대상, 주기, 기준 및 방법, 담당자 및
책임자 등이 포함된 감사 로그 검토, 분석 및 보고 절차 를 정의해야 함
▶ ‌조직은 감사 로그 상관 분석을 위해 SIEM 또는 중앙 로그 서버에 시스템에서 발생하는 모든
로그를 실시간으로 수집
▶ ‌로그 상관 분석 시, 시간 오차가 있으면 분석의 신뢰도가 떨어지므로 모든 시스템을 대상으로
NTP 서버를 사용해 시간 동기화 설정
▶ ‌내·외부에 의한 침해시도, 정보유출 시도, 부정행위 등 이상행위를 탐지할 수 있도록 주요
정보시스템, 응용프로그램, 네트워크, 보안시스템 등에서 발생한 네트워크 트래픽, 데이터 흐름,
이벤트 로그 등을 수집하여 분석 및 모니터링을 수행해야 함
▶ ‌조직의 규모 및 시스템의 중요도가 높은 경우 24시간 실시간 모니터링을 고려해야 함
▶ ‌필요한 감사기록만 필터링하여 추출하는 기능과 요구되는 양식으로 보고서를 생성할 수 있는
기능 제공
관련 기준
⊙ CMMC
• ‌AU.L2-3.3.1 시스템 감사 : 불법적이거나 승인되지 않은 시스템 활동을 모니터링, 분석, 조사 및
보고하는데 필요한 범위 내에서 시스템 감사 로그 및 기록을 생성하고 보관한다.
• ‌AU.L2-3.3.2 사용자 책임 추적성 : 개별 시스템 사용자의 작업을 해당 사용자에게 고유하게 추적할 수
있도록 하여 해당 사용자가 자신의 작업에 대한 책임을 질 수 있도록 한다.
• ‌AU.L2-3.3.3 이벤트 검토 : 기록된 이벤트를 검토하고 업데이트 한다.
• ‌AU.L2-3.3.5 감사 상관관계 : 불법적, 무단적, 의심스럽거나 비정상적인 활동에 대한 조사와 대응을 위해
감사 기록 검토, 분석 및 보고 프로세스를 연관시켜야 한다.
• ‌AU.L2-3.3.6 감소 및 보고 : 주문형 분석 및 보고를 지원하기 위해 감사 기록을 줄이고 보고서를 생성한다.
• ‌AU.L2-3.3.4 감사 실패 경고 : 감사 로깅 프로세스에 오류가 발생할 경우 경고한다.
• ‌AU.L2-3.3.8 감사 보안 : 감사 정보와 감사 로깅 도구를 무단 접근, 수정 및 삭제로부터 보호한다.
• ‌AU.L2-3.3.9 감사 관리 : 감사 로깅 기능 관리를 권한이 있는 일부 사용자로 제한한다.
⊙ K-RMF
• ‌SI-6-7 소프트웨어, 펌웨어, 정보의 무결성 | 중요 이벤트 대비 감사 : 무결성 손상 발견 시 이벤트를
감사하는 역량을 갖추어야 하고 다음 조치 중 하나 이상을 시행해야 한다.

## 1. 감사기록 생성


## 2. 현재 사용자에게 알림

3. [조직이 지정한 직책]에게 알림
4. [조직이 지정한 기타 조치]
• ‌AU-10 감사 생성 :

---
<!-- Page 117 -->

## 제3장 우주 보안모델 해설  | 117

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
1. ‌[조직이 지정한 시스템 구성요소]가 ‘AU-1 1번 항목’에서 정의한 감사 가능한 이벤트들을 감사기록으로
생성하는 기능을 제공해야 한다.
2. [조직이 지정한 직책]이 감사할 이벤트를 선정할 수 있는 기능을 제공해야 한다.
3. ‌‘AU-1 4번 항목’에서 지정한 해당 시스템에서 감사하는 이벤트들의 감사기록은 AU-4에서 정의한
감사기록 내용(발생일시, 사건유형, 신원 등)을 포함하여 생성해야 한다.
• ‌AU-1-1 감사 이벤트 | 검토 및 이벤트 : [조직이 지정한 주기]마다 감사 이벤트를 검토 및 업데이트해야
한다.
• ‌AU-8-4 감사기록 검토·분석·보고 | 분석 통합 : 부적절하거나 비정상적 활동을 식별하기 위한 능력을
더욱 향상시키기 위해 감사기록의 분석과[(하나 이상 선택) 취약점 스캐닝 정보, 성능 데이터, 시스템
모니터링 정보, [조직이 지정한 다른 출처로부터 수집된 데이터(정보)] ]에 대한 분석을 통합해야 한다.
• ‌AU-9 감사기록 필터링 및 보고서 생성 : 필요한 감사기록만 필터링하여 추출하는 기능과 요구되는
양식으로 보고서를 생성할 수 있는 기능을 제공해야 한다.
• ‌AU-2-2 감사 처리 장애 시 대응 | 실시간 경보 : [실시간 경보가 필요한 이벤트]의 감사 장애 시, [조직이
지정한 기간] 내 [조직이 지정한 직책]에게 알려야 한다.
• ‌AU-6 감사정보 보호 : 감사정보 및 감사 도구를 비인가 접근, 수정 및 삭제로부터 보호해야 한다.
• ‌AU-6-4 특별권한 사용자 중 최소 인원만 접근인가 : [조직이 지정한 특수 권한 사용자 중 일부 인원]만
감사 기능 관리에 대한 접근을 인가한다.
⊙ NIS2
• ‌3.2 모니터링 및 로깅 : 이벤트를 탐지하고 그에 따라 대응하여 영향을 완화하기 위해, 자신의 네트워크와
정보 시스템상의 활동을 모니터링하고 기록(log)하는 절차를 수립하고 도구를 사용해야 한다.
⊙ ISMS-P
• ‌2.9.4 로그 및 접속기록 관리 : 서버, 응용프로그램, 보안시스템, 네트워크시스템 등 정보시스템에 대한
사용자 접속기록, 시스템로그, 권한부여 내역 등의 로그유형, 보존기간, 보존방법 등을 정하고 위·변조,
도난, 분실되지 않도록 안전하게 보존·관리하여야 한다.

---
<!-- Page 118 -->
118 | 우주 보안 모델 해설 및 적용사례집
SO-03
시간동기화
항목 내용
감사기록을 위한 타임스태프 생성을 위해 내부 시스템(NTP서버) 시간을
사용해야 한다.
목적
내부 기준 시간(NTP 서버)을 활용하여 시스템 간 시간을 일관되게 유지하고,
감사기록의 정확성과 신뢰성을 확보하기 위함이다.
주요
확인사항
y ‌정보시스템의 시각을 표준시각(NTP 등)으로 동기화하고 있는가?
y ‌시간 동기화가 정상적으로 이루어지고 있는지 주기적으로 점검하고 있는가?
세부 설명
⊙ ‌정보시스템의 시각을 표준시각(NTP 등)으로 동기화해야 한다.
NTP(Network Time Protocol) 등의 방법을 활용하여 시스템 간 시간 동기화 적용
인터넷 동기화 설정 방법

‌Step 1) 제어판 > 시계 및 국가 > 날짜 및 시간 > 인터넷 시간 > 설정 변경 > 인터넷 시간 서버와
동기화

Step 2) 신뢰할 수 있는 NTP 서버(예: time.windows.com) 입력 후 적용
▶ ‌내부 NTP 서버 설정 방법

Step 1) 시간 동기화 정보 확인 (Client)

CMD > w32tm /dumpreg /subkey:parameters

---
<!-- Page 119 -->

## 제3장 우주 보안모델 해설  | 119

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
시간 동기화 정보 확인(Client)
Step 2) 내부 NTP 서버로 시간 동기화 설정 (Client)
(설정) ‌CMD > w32tm /config /syncfromflags:manual /manualpeerlist:{NTP서버 IP or 도메인}
/update
(적용 확인) CMD > w32tm /dumpreg /subkey:parameters
내부 NTP 서버로 시간동기화 설정(Client)
※ ‌Client에서 동기화 설정 후 ‘SpecialPollInterval’ ‘MaxPosPhaseCorrection’ 설정에 따라
주기적으로 자동으로 동기화가 적용되지만 NTP Server에서 다음 명령어로 즉시 적용 가능함.
CMD > w32tm /resync
동기화 명령 성공 확인
Step 1) 동기화 시간차 확인
CMD > w32tm /stripchart /dataonly /computer:{NTP서버 IP or 도메인}
동기화 시간차 확인
출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가방법 상세가이드(KISA)

---
<!-- Page 120 -->
120 | 우주 보안 모델 해설 및 적용사례집
▶ ‌시간 정확성이 요구되는 모든 정보시스템은 빠짐없이 동기화 적용(출입통제시스템, CCTV
저장장치 등)
⊙ ‌시간 동기화가 정상적으로 이루어지고 있는지 주기적으로 점검해야 한다.
▶ ‌시간 동기화 오류 발생 여부, OS 재설치 또는 설정변경 등에 따른 시간동기화 적용 누락 여부
점검 필요
관련 기준
⊙ CMMC
• ‌AU.L2-3.3.7 공인된 시간 출처 : 감사 기록에 대한 타임스태프를 생성하기 위해 내부 시스템을 공인된
출처와 비교하고 동기화하는 시스템 기능을 제공한다.
⊙ K-RMF
• ‌AU-5 타임스탬프(TIME STAMPS) :

## 1. 감사기록을 위한 타임스템프 생성을 위해 내부 시스템(NTP서버) 시간을 사용해야 한다.

2. ‌감사기록을 위한 타임스탬프는 한국표준시(KST)로 표시할 수 있고 [조직이 지정한 시간 측정단위]에
맞는 것으로 하여 기록해야 한다.
⊙ ISMS-P
• ‌2.9.6 시간 동기화 : 로그 및 접속기록의 정확성을 보장하고 신뢰성 있는 로그분석을 위하여 관련
정보시스템의 시각을 표준시각으로 동기화하고 주기적으로 관리하여야 한다.

---
<!-- Page 121 -->

## 제3장 우주 보안모델 해설  | 121

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SO-04
휴대용 저장장치(저장매체 등) 보안
항목 내용
중요정보가 저장된 저장매체 및 휴대용 PC는 물리적으로 안전하게 보관하고
기밀성, 무결성을 보호하기 위해 통제해야 한다.
- 저장매체 이동 시 암호화 등으로 보호
- 폐기 또는 재사용을 위해 반출되기 전에 정보소거 하거나 파기
- 매체 백업 정보의 기밀성 보호
목적
중요정보가 저장된 저장매체에 대한 접근, 사용, 이동, 폐기를 통제하여 정보의
기밀성과 무결성을 보장하기 위함이다.
주요
확인사항
y ‌중요정보가 담긴 저장매체는 중요정보를 표시하고, 배포제한 사항을 명시하여
안전하게 보관하고 있는가?
y ‌중요정보를 저장한 저장매체를 외부 반출 시 중요정보를 암호화하고,
책임추적성을 유지하는가?
y ‌소유자를 식별할 수 없거나 승인되지 않은 휴대용 저장매체 사용을 통제하고,
중요정보가 저장된 저장매체는 승인된 최소 인원만 접근하도록 하고 있는가?
y ‌중요시스템에서의 이동식 저장매체 사용을 통제하고 있는가?
y ‌저장매체 폐기 또는 재사용을 위한 외부 방출 전 중요정보를 완전히
파기하는가?
y ‌중요정보를 포함한 백업 정보는 암호화를 적용하고 있는가?
세부 설명
⊙ ‌중요정보가 담긴 저장매체에 중요정보를 표시하고, 배포 제한사항을 명시하여 안전하게 보관해야
한다.
▶ ‌중요정보가 저장된 모든 저장매체는 중요정보 포함 여부를 육안으로 식별할 수 있는 표식과 배포
제한사항을 명시해야 함
• ‌중요정보 표식 부착(예: 대외비, 기밀정보 등)
• ‌배포 제한사항(예: 협력사 배포 금지 등)
▶ ‌중요정보가 포함된 저장매체(이동형 하드디스크, USB메모리 등)는 금고 등 잠금장치가 있는
물리적으로 안전한 장소에 보관
⊙ ‌중요정보를 저장한 저장매체를 외부 반출 시 중요정보를 암호화하고, 책임추적성을 유지해야 한다.
▶ ‌중요정보를 포함한 저장매체를 통제구역 외부로 반출하는 경우 검증된 암호화 알고리즘을
사용하여 중요정보를 암호화해야 함

---
<!-- Page 122 -->
122 | 우주 보안 모델 해설 및 적용사례집
▶ ‌중요정보가 포함된 저장매체를 통제구역 외부로 반출하는 경우 관리대장을 작성하고, 책임자의
사전 승인을 득해야 함
• ‌반출 목적 및 사유, 매체 정보(종류, 시리얼 번호 등), 반출입 일자, 운송 일시, 발송인, 수신인,
운송 방법 등을 포함한 관리대장 작성
• ‌작업이 종료된 후, 저장매체의 상태(파손 여부 등) 점검
▶ ‌중요정보가 포함된 저장매체의 책임추적성을 유지하기 위해 매체의 운송 활동은 사전에 승인된
인원으로 제한해야 함
▶ ‌운송 중 분실, 파손, 변조를 방지하고 탐지하기 위해 수신 확인 절차를 거쳐 배송 상태 모니터링
• ‌발송자 사전 공지 및 수신자 수령 확인
• ‌인수인계 확인서 작성
▶ ‌개봉 여부를 육안으로 확인할 수 있는 봉인 스티커 등을 사용하여 변조 여부 관리
⊙ ‌소유자를 식별할 수 없거나, 승인되지 않은 휴대용 저장매체 사용을 통제하고, 중요정보가 저장된
저장매체는 승인된 최소 인원만 접근하도록 해야 한다.
▶ ‌모든 휴대용 저장매체는 특정 개인 또는 부서에 할당되어야 하며, 매체 관리 대장에 소유자
정보가 기록되어야 함
• ‌자산번호 : USB-001 / 소유자 : 홍길동 / 용도 : 기술자료 백업 등
▶ ‌소유자를 식별할 수 없는 저장매체의 사용은 원칙적으로 금지
▶ ‌개인 소유의 저장매체 등 승인되지 않은 장치의 시스템 접속을 금지하고, 승인되지 않은 비인가
저장매체의 접속 차단
• ‌매체 제어 솔루션을 통한 매체의 읽기/쓰기 기능 차단
• ‌특정 시리얼 번호가 등록된 매체만 인식되도록 설정 등
▶ ‌업무상 휴대용 저장매체의 사용이 필요한 경우, 사용 목적, 기간, 대상 시스템을 명시하여 보안
담당자의 승인을 득해야 함
▶ ‌휴대용 저장매체를 시스템에 연결하기 전 최신 백신을 통한 악성코드 점검을 수행해야 함
⊙ ‌중요시스템에서의 이동식 저장매체 사용을 통제해야 한다.
▶ ‌중요 서버나 워크 스테이션의 미사용 USB 포트는 포트락 등의 물리적 잠금 장치를 통해 비인가
접근을 차단해야 함

---
<!-- Page 123 -->

## 제3장 우주 보안모델 해설  | 123

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
포트락이 설치된 USB 포트
⊙ ‌저장매체 폐기 또는 재사용을 위한 외부 방출 전 중요정보를 완전히 파기해야 한다.
▶ ‌자체적으로 저장매체(이동형 하드디스크, USB메모리 등)를 폐기할 경우 다음 내용이 포함된
관리대장을 통해 폐기 이력을 남기고, 폐기확인 증거자료를 함께 보관해야 함
• ‌폐기 일자
• ‌폐기 담당자 및 확인자 성명
• ‌폐기 방법(소각, 파쇄, 덮어쓰기 등)
• ‌폐기확인 증적자료(사진 등)
▶ ‌외부업체를 통해 저장매체 폐기 시, 정보 유출 방지를 위한 보안서약서를 징구하고, 폐기현장에
동행하여 직접 실사하거나 현장 동행이 어려울 경우 폐기 확인서 및 동영상, 사진 등의 폐기 확인
증적을 제출받도록 해야 함
▶ ‌매체를 폐기하기 전 조직을 식별하거나, 소유자, 시스템 또는 네트워크를 표시하는 라벨과 표식
제거
▶ ‌중요정보가 복구 및 재생되지 않도록 안전한 방법으로 파기

---
<!-- Page 124 -->
124 | 우주 보안 모델 해설 및 적용사례집
안전한 파기방법(예)
y ‌완전파괴 : 중요정보가 저장된 하드디스크 등을 파쇄기로 파기하거나 용해, 또는 소각장,
소각로에서 태워서 파기 등
y ‌전용 소자장비 이용 시 : 디가우저(Degausser)를 이용하여 하드디스크 등에 저장된 중요정보
삭제 등
y ‌데이터가 복원되지 않도록 초기화 또는 덮어쓰기 수행 시 : 중요정보가 저장된 하드디스크에
대하여 완전포맷(3회 이상 권고), 데이터 영역에 무작위 값, 0, 1 등으로 덮어쓰기(3회 이상 권고),
해당 드라이브를 안전한 알고리즘 및 키 길이로 암호화 저장 후 삭제하고 암호화에 사용된 키 완전
폐기 및 무작위 값 덮어쓰기 등의 방법 이용
⊙ ‌중요정보를 포함한 백업 정보는 암호화를 적용해야 한다.
▶ ‌중요정보가 포함된 백업 매체(외부 하드디스크, USB, CD, NAS(Network Attacked Storage),
클라우드 백업 등)를 식별하고, 백업된 중요정보의 기밀성을 보호하기 위해 암호화 적용
• ‌암호화 기능을 제공하는 보안 저장매체 이용(보안USB 등)
• ‌해당 정보를 암호화한 후 휴대용 저장매체에 저장 등
안전한 암호 알고리즘 (예시)
구분
알고리즘 명칭
대칭키 암호 알고리즘
SEED, ARIA-128/192/256, AES-128/192/256,
HIGHT, LEA 등
공개키 암호 알고리즘
RSAES-OAEP 등
일방향 암호 알고리즘
SHA-256/384/512 등
▶ ‌암호화를 적용할 수 없는 경우, 백업 데이터가 저장된 매체를 금고, 잠금장치가 있는 안전한
장소에 보관
관련 기준
⊙ CMMC
• ‌MP.L2-3.8.1 매체 보안 : CUI가 담긴 시스템 미디어(종이 및 디지털)를 보호(즉, 물리적으로 제어하고
안전하게 보관)한다.
• ‌MP.L2-3.8.2 매체 접근 : 시스템 미디어의 CUI에 대한 액세스를 권한이 있는 사용자로 제한한다.
• ‌MP.L2-3.8.4 매체 표시 : 필요한 CUI 표시 및 배포 제한 사항을 사용하여 미디어에 표시해야 한다.
• ‌MP.L2-3.8.5 매체 책임추적성 : CUI가 포함된 미디어에 대한 접근을 통제하고 통제 구역 밖으로 미디어를
운송하는 동안 미디어에 대한 책임을 유지해야 한다.

---
<!-- Page 125 -->

## 제3장 우주 보안모델 해설  | 125

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌MP.L2-3.8.6 휴대용 저장장치 암호화 : 달리 대체 물리적 보안 장치로 보호되지 않는 한, 전송 중에
디지털 미디어에 저장된 CUI의 기밀성을 보호하기 위해 암호화 메커니즘을 구현한다.
• ‌MP.L2-3.8.3 매체 폐기 [CUI 데이터] : 폐기 또는 재사용을 위해 방출하기 전에 CUI가 포함된 시스템
미디어를 정보소거하거나 파기한다.
• ‌MP.L2-3.8.7 이동식 매체 : 시스템 구성 요소에서 이동식 미디어 사용을 제어한다.
• ‌MP.L2-3.8.8 공유 매체 : 해당 장치에 식별 가능한 소유자가 없는 경우 휴대용 저장 장치의 사용을
금지한다.
• ‌MP.L2-3.8.9 백업 보안 : 저장 위치에 있는 백업 CUI의 기밀성을 보호한다.
⊙ K-RMF
• ‌MP-3 매체 보관 : 조직에서 지정한 매체]를 [조직에서 지정한 보관 기준]에 따라 물리적으로 안전하게
보관해야 한다.
• ‌MP-1 매체 접근 : [조직이 지정한 매체]에 대한 접근을 [조직이 지정한 직책]에게만 허용해야 한다.
• ‌MP-2 매체 표시 : [조직에서 지정한 매체]에 [조직에서 지정한 보안 표시]를 삽입해야 한다.
• ‌MP-4 매체 이동 :
1. ‌[조직에서 지정한 매체]를 [조직에서 지정한 통제 구역] 외부로 이동 시 [조직에서 지정한 보안
보호조치]를 사용하여 보호해야 한다.
2. [조직에서 지정한 통제 구역] 외부로 이동 시 매체에 대한 책임을 유지해야 한다.

## 3. 매체 이동과 관련된 활동을 기록 및 유지해야 한다.


## 4. 매체 이동과 관련된 활동을 인가된 인원으로만 제한해야 한다.

• ‌MP-4-2 암호화를 통한 보호 : 디지털 매체를 [조직에서 지정한 통제 구역] 외부로 이동 시 매체내 저장된
정보의 기밀성과 무결성을 보호하기 위해 암호화 기술을 적용해야 한다.
• ‌MP-6 매체 정보소거 :
1. ‌[조직에서 지정한 정보소거 요구 상황] 시 [조직에서 지정한 매체]를 [조직에서 지정한 방법 및 절차 ]를
사용하여 정보를 소거해야 한다.
2. ‌매체에 저장(기록)된 정보의 유형과 비밀등급에 따라 강도와 무결성이 충족되는 정보소거 방법을
사용해야 한다.
• ‌MP-5 매체 사용 :
1. ‌[조직에서 지정한 시스템 또는 시스템 구성요소]에서 [조직에서 지정한 매체]의 사용을 금지하거나
[조직에서 지정한 보안 보호조치]를 활용하여 사용을 제한해야 한다.

## 2. 시스템에서 인가되지 않은 휴대용 저장매체의 사용을 금지해야 한다.

⊙ NIS2
• ‌12.3 이동식 매체 정책 : 이동식 저장 매체 관리에 관한 정책을 수립·시행·적용하고, 이를 해당 기관의 직원
및 이동식 저장 매체를 기관의 사업장이나 해당 매체가 기관의 네트워크 및 정보 시스템에 연결되는 기타
장소에서 취급하는 협력업체 직원에게 전달해야 한다
⊙ ISMS-P
• ‌2.10.7 보조저장매체 관리 : 보조저장매체를 통하여 개인정보 또는 중요정보의 유출이 발생하거나
악성코드가 감염되지 않도록 관리 절차를 수립·이행하고, 개인정보 또는 중요정보가 포함된 보조저장
매체는 안전한 장소에 보관하여야 한다.

---
<!-- Page 126 -->
126 | 우주 보안 모델 해설 및 적용사례집
SO-05
형상관리
항목 내용
시스템 구축 및 운영의 통제기준이 되는 최신화된 형상관리 기준선(Baseline)을
식별하고 시스템 정보기술 제품들의 보안 환경설정을 수립 및 문서화해야 한다.
목적
시스템 수명 전반에 걸쳐 형상관리 기준선을 확립하고, 안전한 보안 구성 설정을
적용하여 정보자산의 무결성을 유지하기 위함이다.
주요
확인사항
y ‌하드웨어, 소프트웨어, 펌웨어 및 문서를 포함한 모든 구성요소에 대한
기준선을 구성하고, 문서화하고 있는가?
y ‌시스템에 적용되는 정보기술 제품에 대한 보안 환경설정을 수립하고 시행하고
있는가?
세부 설명
⊙ ‌하드웨어, 소프트웨어, 펌웨어 및 문서를 포함한 모든 구성요소에 대한 기준선을 구성하고,
문서화해야 한다.
▶ ‌조직은 시스템의 안정성과 무결성을 유지하기 위해 시스템과 시스템 내 모든 구성요소에 대한
사양을 문서화하여 검토해야 함
▶ ‌수립한 기준선 구성에는 시스템 통신 및 연결을 포함하여 시스템과 시스템 구성요소에 대한 설정
등 기타 사양을 포함해야 함
▶ ‌시스템 또는 구성요소 변경 시 기존 기준선 구성을 검토하고 변경된 내용을 업데이트
⊙ ‌시스템에 적용되는 정보기술 제품에 대한 보안 환경설정을 수립하고 시행해야 한다.
▶ ‌보안 환경설정은 시스템 기능에 영향을 미치는 하드웨어, 소프트웨어, 펌웨어 구성요소에서
변경될 수 있는 설정 값으로, 다음의 설정 값이 포함됨
• ‌레지스트리 설정값
• ‌계정, 파일, 디렉터리 권한 설정값
• ‌네트워크 관련 설정값
▶ ‌운영 요구사항을 준수하는 보안 환경설정을 수립하고 문서화해야 함
▶ ‌보안 환경설정을 운영체제(OS), 애플리케이션 등 모든 우주 시스템에 적용 필요
▶ ‌보안 환경설정이 임의로 변경되거나, 취약점이 발생하지 않도록 주기적으로 모니터링하고
관리해야 함

---
<!-- Page 127 -->

## 제3장 우주 보안모델 해설  | 127

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ CMMC
• ‌CM.L2-3.4.1 시스템 기준 설정 : 각 시스템 개발 수명 주기 전반에 걸쳐 조직 시스템의 기준 구성과
인벤토리(하드웨어, 소프트웨어, 펌웨어 및 문서 포함)를 수립하고 유지 관리한다.
• ‌CM.L2-3.4.2 보안 구성 시행 : 조직 시스템에 사용되는 정보 기술 제품에 대한 보안 구성 설정을 수립하고
시행한다.
⊙ K-RMF
• ‌CM-1 형상관리 기준선 : 시스템 구축 및 운영의 통제기준이 되는 최신화된 형상관리 기준선(Baseline)을
식별하여 문서화해야 한다.
• ‌CM-3 형상 설정
1. ‌시스템의 정보기술 제품들이 운영 요구사항을 충족하면서 가장 엄격하게 [조직이 지정한 보안 환경설정
항목]을 적용하도록 보안 환경설정을 수립 및 문서화해야 한다.

## 2. 보안 환경설정을 적용해야 한다.

3. ‌[조직이 지정한 운영 요구사항]에 따라 [조직이 지정한 시스템 구성요소]에 적용되는 보안 환경설정과
다른 사항을 식별, 문서화하고 승인해야 한다.

## 4. 정책 및 절차에 따라 보안 환경설정을 모니터링하고 통제해야 한다.


---
<!-- Page 128 -->
128 | 우주 보안 모델 해설 및 적용사례집
SO-06
시스템 및 애플리케이션 보안 요구사항 정의
항목 내용
사업 기획 단계에서 시스템 및 서비스에 대한 정보보안 요구사항을 정의해야
하며, 안전한 코딩 방안을 포함하여야 한다.
목적
시스템 도입 및 애플리케이션 개발 단계에서 필요한 정보보안 요구사항을 사전에
정의하고 안전한 개발·코딩 기법을 적용함으로써, 초기 기획부터 운영까지 전
과정에서 보안 취약점을 예방하고 안전한 시스템을 구축하기 위함이다.
주요
확인사항
y ‌사업 기획 단계에서 시스템 및 애플리케이션에 대한 정보보안 요구사항을
정의하고 있는가?
y ‌정보시스템의 안전한 구현을 위한 코딩 표준을 수립하여 적용하고 있는가?
세부 설명
⊙ ‌사업 기획 단계에서 시스템 및 애플리케이션에 대한 정보보안 요구사항을 정의해야 한다.
▶ ‌사업 기획 단계에서 시스템 및 서비스 보호를 위해 필요한 정보보안 요구사항(법적 준거성,
기술적 보안 규격 등)을 결정하고, 문서화
▶ ‌시스템 및 애플리케이션을 신규로 도입하는 경우 법적 요구사항, 최신 취약점 등을 포함한 보안
요구사항을 명확히 정의하고 반영해야 함
• ‌상위 기관 및 내부 규정에 따른 정보보호 요구사항
• ‌정보보호 관련 기술적 요구사항 : 인증, 접근통제, 암호화, 로깅 등
• ‌최신 보안취약점 등
▶ ‌보안 요구사항에는 다음과 같은 내용이 포함되어야 함
• ‌사용자 인증 방법
• ‌접근권한 통제 방법
• ‌로깅 방법
• ‌암호화 대상 및 방법
▶ ‌정보보호 측면의 요구사항을 제안요청서(RFP)에 반영하여 업체 또는 제품 선정 기준으로 활용
⊙ ‌정보시스템의 안전한 구현을 위한 코딩 표준을 수립하여 적용해야 한다.
▶ ‌시큐어 코딩이란 소프트웨어 개발 과정에서 발생할 수 있는 보안 취약점을 최소화하기 위해, 설계
및 구현 단계에서부터 보안 요구사항을 반영하고 안전하게 코딩하는 기법을 의미함
▶ ‌다양한 개발 언어(Java, PHP, ASP, 웹, 모바일 등) 및 환경을 고려하여 알려진 보안 취약점을
예방할 수 있는 안전한 코딩 표준(Secure Coding Standard) 및 보안 가이드 마련

---
<!-- Page 129 -->

## 제3장 우주 보안모델 해설  | 129

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌우주 기업의 개발자 및 관련 인원이 수립된 코딩 표준을 숙지하고 올바르게 적용할 수 있도록
소프트웨어 개발 보안 관련 교육을 주기적으로 실시
▶ ‌개발 완료 후에는 정적 분석 도구 또는 동적 분석 도구를 활용하여 안전한 코딩 표준 준수 여부와
보안 약점 존재 여부 점검
• ‌시스템이 안전한 코딩표준에 따라 구현하는지 소스코드 검증(소스코드 검증 도구 활용 등)
• ‌코딩이 완료된 프로그램은 운영환경과 동일한 환경에서 취약점 점검도구 또는 모의진단을 통한
취약점 노출 여부 점검
관련 기준
⊙ K-RMF
• ‌SA-1 자원 할당

## 1. 사업(임무) 계획단계에서 시스템 및 서비스에 대한 정보보안 요구사항을 결정해야 한다.


## 2. 소요기획단계에서 시스템 및 서비스를 보호하기 위해 필요한 자원을 결정, 할당하고 문서화해야 한다.


## 3. 예산편성 및 제안요청 관련문서에 ‘정보보안’항목을 별도로 기술해야 한다.

⊙ NIS2
• ‌6.1 ICT 서비스·제품 도입 시 보안 : 네트워크 및 정보 시스템의 보안에 중요한 구성 요소를 위한 ICT
서비스 또는 ICT 제품의 취득으로부터 발생하는 위험을 관리하기 위한 절차를 수립하고 시행해야 하며,
이는 제2.1항에 따라 수행된 위험 평가를 기반으로 공급업체 또는 서비스 제공자의 전체 생애 주기에 걸쳐
적용되어야 한다.
• ‌6.2 보안 개발 생명주기 : 네트워크 및 정보 시스템(소프트웨어 포함)을 개발하기 전에, 관련 기관은
네트워크 및 정보 시스템의 안전한 개발을 위한 규칙을 수립하고, 이를 내부적으로 네트워크 및 정보
시스템을 개발할 때나 외부에 개발을 위탁할 때 적용해야 한다. 이러한 규칙은 명세, 설계, 개발, 구현 및
테스트를 포함한 모든 개발 단계에 적용되어야 한다.
⊙ ISMS-P
• ‌2.8.1 보안 요구사항 정의 : 정보시스템의 도입·개발·변경 시 정보보호 및 개인정보보호 관련 법적
요구사항, 최신 보안취약점, 안전한 코딩방법 등 보안 요구사항을 정의하고 적용하여야 한다.

---
<!-- Page 130 -->
130 | 우주 보안 모델 해설 및 적용사례집
SO-07
시스템/애플리케이션 변경관리
항목 내용
시스템 및 애플리케이션의 변경 사항을 검토, 승인/거부하고 변경내역을
기록해야 하며 변경 전에 변경에 대한 잠재적인 보안 영향을 분석해야 한다.
목적
시스템 및 애플리케이션 변경 시 사전 영향 분석과 승인 절차를 통해 시스템의
무결성을 보장하고 안정적인 운영을 유지하기 위함이다.
주요
확인사항
y ‌시스템 변경 사항을 검토하여 승인/거부하고, 변경 사항을 기록 및
문서화하는가?
y ‌애플리케이션 변경 사항을 검토하여 승인/거부하고, 변경 사항을 기록 및
문서화하고 있는가?
y ‌승인된 변경 사항을 시스템에 적용하기 전 보안 영향을 분석하고, 안정성을
사전에 검증하고 있는가?
y ‌시스템 변경과 관련된 물리적/논리적 접근 제한을 정의하고, 승인된 인원만
변경을 수행하도록 통제하고 있는가?
세부 설명
⊙ ‌시스템 변경 사항을 검토하여 승인/거부하고, 변경 사항을 기록 및 문서화한다.
▶ ‌정보시스템 관련 자산(하드웨어, 운영체제, 상용 소프트웨어 패키지 등) 변경에 관한 절차를
수립·이행
• ‌운영체제 업그레이드, 상용 소프트웨어 설치, 운영 중인 응용프로그램 기능 개선, 네트워크 구성
변경, CPU·메모리·저장장치 증설 등 정보시스템 관련 자산 변경이 필요한 경우 변경을 위한
절차 수립 및 이행
▶ ‌시스템 변경 사항은 운영환경에 반영하기 전 검토하여 승인, 거부함
▶ ‌시스템의 무결성을 보장하고, 안정적인 운영을 유지하기 위해 변경사항을 기록해야 함
• ‌변경 일자
• ‌변경된 항목(하드웨어, 소프트웨어, 설정 등)
• ‌변경 범위(적용 시스템, 구성 요소 등)
• ‌변경 목적 및 필요성 등
▶ ‌변경 사항관리를 위해 변경 일자, 개정 사유, 작성자, 승인자 등 개정 이력을 기록하여 관리
▶ ‌변경·구현·이관 일자, 변경 요청사유, 담당자 등을 포함하여 변경사항을 기록해야 함
⊙ ‌애플리케이션 변경 사항을 검토하여 승인/거부하고, 변경 사항을 기록 및 문서화한다.

---
<!-- Page 131 -->

## 제3장 우주 보안모델 해설  | 131

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌애플리케이션 변경은 소스코드의 무결성 보장과 배포 안정성을 위해 형상 관리 및 자동화
도구(Git, Jenkins 등)를 활용하여 수행함
▶ ‌변경 사항이 정보보안(기밀성, 무결성, 가용성) 및 기존 시스템에 미치는 위험 분석
▶ ‌소스코드 취약점 점검 및 요구사항 준수 여부 검토
▶ ‌변경 사항을 검토하여 운영 환경 반영 여부 결정
▶ ‌변경 요청부터 운영환경 반영까지의 모든 과정을 기록하고 관리함
⊙ ‌승인된 변경 사항을 시스템에 적용하기 전 보안 영향을 분석하고, 안정성을 사전에 검증해야 한다.
▶ ‌정보시스템 관련 자산 변경 수행 전 성능 및 보안에 미치는 영향을 분석해야 함
▶ ‌정보시스템 관련 정보자산 변경이 필요한 경우 변경에 따른 보안, 성능, 업무 등에 미치는 영향을
분석해야 함(방화벽 등 보안시스템 정책 변경 필요성, 정책 변경 시 문제점 및 영향도 등)
▶ ‌변경에 따른 영향을 최소화할 수 있도록 변경을 이행해야 함
▶ ‌변경 실패에 따른 복구방안을 사전에 고려해야 함
⊙ ‌시스템 변경과 관련된 물리적/논리적 접근 제한을 정의하고, 승인된 인원만 변경을 수행하도록
통제해야 한다.
▶ ‌하드웨어, 소프트웨어, 펌웨어를 포함한 구성요소별 접근권한 정의
▶ ‌서버실 등 주요 구역에 대한 물리적 출입통제 적용(예: 키 카드 등)
▶ ‌시스템 구성요소, 소프트웨어 라이브러리 및 관련 정보를 변경할 수 있는 권한을 직무에 따라
명확히 정의하고 승인된 인원에게만 최소한으로 부여
▶ ‌승인된 인원에게만 변경 권한을 부여하고, 관련 데이터에 대한 접근을 통제해야 함
관련 기준
⊙ CMMC
• ‌CM.L2-3.4.3 시스템 변경 관리 : 조직 시스템의 변경 사항을 추적, 검토, 승인 또는 거부하고 기록한다.
• ‌CM.L2-3.4.4. 보안 영향 분석 : 구현에 앞서 변경 사항의 보안 영향을 분석한다.
• ‌CM.L2-3.4.5 변경에 대한 접근 제한 : 조직 시스템의 변경과 관련된 물리적, 논리적 액세스 제한을 정의,
문서화, 승인하고 시행한다.
⊙ K-RMF
• ‌CM-2 형상 변경 통제

## 1. 시스템 변경 소요가 발생하면 형상변경을 위해 통제할 사항을 결정하고 문서화해야 한다.

2. ‌시스템에 대해 1번에서 통제된 형상변경을 검토하고 보안 영향분석을 통해 해당 변경을 승인 또는
불승인해야 한다.

## 3. 시스템과 관련해서 결정된 변경사항을 문서화해야 한다.


---
<!-- Page 132 -->
132 | 우주 보안 모델 해설 및 적용사례집

## 4. 승인된 형상 변경사항을 적용해야 한다.

5. [조직이 지정한 주기]마다 시스템에 대한 형상 변경사항을 기록해서 보존해야 한다.

## 6. 시스템의 형상변경과 관련된 활동을 모니터링하고 검토해야 한다.

7. ‌[ 조직이 지정한 주기] 마다 또는 [ 조직이 지정한 형상 변경 조건]  충족 시 소집되는
형상관리통제부서(위원회 등)를 통해 형상변경 활동을 관리하고 조율해야 한다.
• ‌SA-7 개발자(업체)의 형상관리 : 조직은 시스템/구성요소/서비스 개발자(업체)에게 다음사항을 요구해야
한다.

## 1. 개발수명주기 여러 단계에서 (설계, 개발, 구현, 운영, 도태 중 하나 이상) 형상관리를 수행


## 2. 무결성을 보장하기 위해 [조직이 지정한 형상 항목]의 변경사항을 기록/유지, 관리, 통제


## 3. 변경사항은 조직이 승인한 사항만 구현


## 4. 변경사항과 이로 인해 예상되는 보안영향을 기록 및 유지


## 5. 보안결함 및 결함 조치내역을 추적하고, [조직이 지정한 인원]에게 그 결과를 보고

• ‌CM-5 보안 영향성 분석 : 시스템 형상변경을 적용하기 전에 변경에 대한 잠재적인 보안 영향성을
분석해야 한다.
• ‌CM-6 변경 제한

## 1. 시스템 변경과 관련된 (물리적, 논리적) 제한사항을 정의하고 문서화 하여야 한다.


## 2. 시스템의 물리적, 논리적 변경과 관련된 제한사항을 승인 받은 후 시행해야 한다.

⊙ ‌NIS2
• ‌6.3 구성 관리 : 하드웨어, 소프트웨어, 서비스 및 네트워크의 보안 설정을 포함한 구성 사항을 수립하고,
문서화하며, 구현하고, 모니터링하기 위한 적절한 조치를 취해야 한다.
• ‌6.4 변경 관리·유지보수 : 네트워크 및 정보 시스템의 변경을 관리하기 위해 변경 관리 절차를 적용해야
한다. 해당되는 경우, 이러한 절차는 변경 관리에 관한 기관의 일반 정책과 일관성을 유지해야 한다.
⊙ ‌ISMS-P
• ‌2.9.1 변경관리 : 정보시스템 관련 자산의 모든 변경내역을 관리할 수 있도록 절차를 수립·이행하고, 변경
전 시스템의 성능 및 보안에 미치는 영향을 분석하여야 한다.

---
<!-- Page 133 -->

## 제3장 우주 보안모델 해설  | 133

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SO-08
개발 시험 및 평가
항목 내용
사전 정의된 보안 요구사항에 따라 정보시스템이 도입 또는 구현되었는지를
검토하기 위하여 법적 요구사항 준수, 최신 보안취약점 점검, 안전한 코딩 구현
등의 검토 기준과 절차를 수립·이행하고, 발견된 문제점에 대한 개선조치를
수행하여야 한다.
목적
사전에 정의된 보안 요구사항의 구현 여부를 검증하고 잠재적 기술적 취약점을
사전에 식별함으로써 시스템의 안정성과 무결성을 확보하기 위함이다.
주요
확인사항
y ‌분석 및 설계 단계에서 정의한 보안 요구사항이 정보시스템의 도입, 개발, 변경
시 제대로 반영되었는지 확인하는 절차를 운영하고 있는가?
y ‌정보시스템이 안전한 코딩 기준 등에 따라 안전하게 개발되었는지를 확인하기
위한 취약점 점검이 수행되고 있는가?
y ‌시험 및 취약점 점검 과정에서 발견된 문제점이 신속하게 개선될 수 있도록
개선계획 수립, 이행점검 등의 절차를 이행하고 있는가?
세부 설명
⊙ ‌분석 및 설계 단계에서 정의한 보안 요구사항이 정보시스템의 도입, 개발, 변경 시 제대로
반영되었는지 확인하는 절차를 운영해야 한다.
▶ ‌정보시스템 보안 요구사항 적용 여부를 확인하기 위한 시험 수행
• ‌정보시스템이 사전에 정의한 보안 요구사항을 만족하여 개발·변경 및 도입되었는지 확인하기
위한 절차 수립
• ‌정보시스템을 도입하기 전 사전 정의한 보안 요구사항 적용 여부를 테스트 등을 통하여 확인한 후
도입 여부 결정
• ‌시스템 보안 설정, 불필요한 디폴트 계정 제거 여부, 최신 보안취약점 패치 여부 등을 확인해야 함
▶ ‌개발·변경 및 구현된 기능이 사전에 정의된 보안 요구사항을 충족하는지 시험을 수행
• ‌시험 계획서, 체크리스트, 시험 결과서 등에 반영
⊙ ‌정보시스템이 안전한 코딩 기준 등에 따라 안전하게 개발되었는지를 확인하기 위한 취약점 점검을
수행해야 한다.
▶ ‌코딩 완료 후 안전한 코딩 표준 및 규약 준수 여부를 점검하고 기술적 보안취약점이 존재하는지
점검을 수행해야 함
▶ ‌시스템이 안전한 코딩표준에 따라 구현하였는지 소스코드 검증(소스코드 검증도구 활용 등)

---
<!-- Page 134 -->
134 | 우주 보안 모델 해설 및 적용사례집
▶ ‌코딩이 완료된 프로그램은 운영환경과 동일한 환경에서 취약점 점검도구 또는 모의진단을 통한
취약점 노출 여부 점검
⊙ ‌시험 및 취약점 점검 과정에서 발견된 문제점이 신속하게 개선될 수 있도록 개선계획 수립, 이행점검
등의 절차를 이행해야 한다.
▶ ‌발견된 문제점은 시스템 오픈 전에 개선될 수 있도록 개선계획 수립, 내부 보고, 이행점검 등의
절차를 수립하고 이행해야 함
▶ ‌불가피한 사유로 시스템 오픈 전에 개선이 어려울 경우에는 이에 따른 영향도를 평가하고, 보완
대책 마련, 내부 보고 등 위험을 줄일 수 있는 방안 수립
관련 기준
⊙ K-RMF
• ‌SA-8 개발자(업체)의 보안 시험 및 평가 : 개발자(업체)에게 다음을 요구해야 한다.

## 1. 보안 시험평가 계획을 작성하고 구현

2. ‌[조직이 지정한 수준 및 범위]내에서 [단위 시험평가, 통합 시험평가, 시스템 시험평가, 회귀 시험평가 중
하나 이상]을 수행

## 3. 보안 시험평가 계획의 실행 및 보안 시험평가 결과를 기록 및 유지


## 4. 결함 조치 프로세스를 수립


## 5. 보안 시험평가 간 식별된 결함을 수정

⊙ NIS2
• ‌6.5 보안테스트 : 기업은 보안 테스트를 위한 정책과 절차를 수립하고, 시행하며, 적용해야 한다.
⊙ ISMS-P
• ‌2.8.2 보안 요구사항 검토 및 시험 : 사전 정의된 보안 요구사항에 따라 정보시스템이 도입 또는
구현되었는지를 검토하기 위하여 법적 요구사항 준수, 최신 보안취약점 점검, 안전한 코딩 구현, 개인정보
영향평가 등의 검토 기준과 절차를 수립·이행하고, 발견된 문제점에 대한 개선조치를 수행하여야 한다.

---
<!-- Page 135 -->

## 제3장 우주 보안모델 해설  | 135

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
SO-09
기능 최소화 및 사용자 설치 소프트웨어 통제
항목 내용
필수 기능만 제공하도록 시스템을 설정하고 사용자가 설치한 소프트웨어를
통제하고 모니터링한다.
목적
시스템에서 불필요한 기능을 제거하고, 사용자의 임의 소프트웨어 설치를
통제·모니터링하여 보안 위험을 최소화하기 위함이다.
주요
확인사항
y ‌시스템이 필수적인 기능만 제공하도록 구성하고, 불필요한 서비스 및 기능을
비활성화하여 운영하고 있는가?
y ‌비인가 소프트웨어를 차단하는 블랙리스트 또는 승인된 소프트웨어만
허용하는 화이트리스트 정책을 적용하여 무단 소프트웨어 사용을 통제하고,
설치 소프트웨어 현황을 주기적으로 점검하고 있는가?
세부 설명
⊙ ‌시스템이 필수적인 기능만 제공하도록 구성하고, 불필요한 서비스 및 기능을 비활성화하여 운영해야
한다.
▶ ‌우주 기업은 시스템별(서버, PC 등) 운영 목적에 따른 서비스 및 최소 기능 정의하고, 필수적인
소프트웨어, OS, 네트워크 프로토콜 목록을 문서화하여 관리해야 함
▶ ‌불필요한 서비스 및 기능을 비활성화해야 함(예: DHCP Client, Print Spooler 등)
Windows 기준 불필요한 서비스 비활성화 설정 (예시)
Step 1) ‌시작 > 모든 앱 Windows Tools > 서비스 > 해당 서비스 선택 > 속성
(시작 > 모든 앱 > Windows Tools > 실행 > “services.msc” 입력> 해당 서비스 선택> 속성에서도
설정 가능)
Step 2) 불필요한 서비스 -> 중지 / 시작 유형 -> 사용 안 함
출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가방법 상세가이드(KISA)

---
<!-- Page 136 -->
136 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌비인가 소프트웨어를 차단하는 블랙리스트 정책 또는 승인된 소프트웨어만 허용하는 화이트리스트
정책을 적용하여 무단 소프트웨어 사용을 통제하고, 설치 소프트웨어 현황을 주기적으로 점검해야
한다.
▶ ‌비인가 소프트웨어 실행을 차단하는 블랙리스트 정책 또는 인가된 소프트웨어만 실행을
허용하는 화이트리스트 정책을 선택하여 무단 소프트웨어 사용을 통제해야 함
• ‌블랙리스트 정책 : 차단 목록에 명시된 비인가 소프트웨어를 제외한 모든 소프트웨어의 실행 허용
• ‌화이트리스트 정책 : 승인된 소프트웨어 목록에 포함된 항목 외 모든 소프트웨어 실행 차단
▶ ‌블랙리스트 정책을 통한 무단 소프트웨어 설치 통제
• ‌P2P 프로그램, 웹하드, 개인용 클라우드뿐만 아니라 원격접속시스템, 비인가 네트워크 우회
프로그램, 업무 외 소프트웨어(메신저, SNS, 게임, 주식 등)에 대한 설치 금치 정책 수립 및 공지
• ‌업무상 예외가 필요할 경우 관리자 승인을 득한 후 사용 및 불필요 시 즉시 삭제
• ‌설치 여부를 정기적으로 점검하여 지속적으로 개선
▶ ‌화이트리스트 백신을 통한 무단 소프트웨어 설치 통제
• ‌승인된 소프트웨어 식별
• ‌승인된 소프트웨어의 파일명, 해시값, 디지털 서명 등을 추출·목록화
• ‌화이트리스트 정책에 적용하여 목록에 등록되지 않은 비인가 소프트웨어 설치 차단 및 통제
▶ ‌블랙리스트 정책 적용 시, 비인가 소프트웨어를 식별하여 목록화하고, 차단해야 할 소프트웨어의
프로세스명, 해시값, 디지털 서명 등을 바탕으로 관리하고, 목록을 주기적으로 업데이트해야 함
▶ ‌화이트리스트 정책 적용 시, 승인된 소프트웨어를 식별하여 목록화하고, 디지털 서명 및
해시값을 기반으로 승인된 프로그램만 실행되도록 통제
▶ ‌설치 소프트웨어 현황을 주기적으로 점검 필요
관련 기준
⊙ CMMC
• ‌CM.L2-3.4.6 최소 기능성 : 최소 기능성 원칙을 적용하여 조직 시스템을 필수적인 기능만 제공하도록
구성한다.
• ‌CM.L2-3.4.7 비필수 기능 : 필수적이지 않은 프로그램, 기능, 포트, 프로토콜 및 서비스의 사용을 제한,
비활성화 또는 방지한다.
• ‌CM.L2-3.4.9 사용자가 설치한 소프트웨어 : 사용자가 설치한 소프트웨어를 제어하고 모니터링한다.
• ‌CM.L2-3.4.8 애플리케이션 실행 정책 : 허가되지 않은 소프트웨어 사용을 차단하려면
거부·예외(블랙리스트) 정책을 적용하고, 허가된 소프트웨어 실행을 허용하려면 모두 거부하고 예외적으로
허용(화이트리스트) 정책을 적용한다.
⊙ K-RMF

---
<!-- Page 137 -->

## 제3장 우주 보안모델 해설  | 137

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌CM-7 기능 최소화

## 1. 필수 기능만 제공하도록 시스템을 설정해야 한다.

2. [조직이 지정한 기능, 포트, 프로토콜, 소프트웨어, 서비스]의 사용을 금지하거나 제한해야 한다.
• ‌CM-7-1 정기 검토
1. ‌[조직이 지정한 주기 또는 필요 시]마다 불필요하거나 안전하지 않은 기능, 포트, 프로토콜, 소프트웨어,
서비스를 검토해야 한다.

## 2. 불필요하거나 안전하지 않은 기능, 포트, 프로토콜, 소프트웨어, 서비스를 비활성화해야 한다.

• ‌CM-10 사용자 설치 소프트웨어

## 1. 사용자의 소프트웨어 설치에 관한 정책을 수립해야 한다.

2. [조직이 지정한 방법]을 사용하여 위에서 수립한 소프트웨어 설치 정책을 시행해야 한다.
3. [조직이 지정한 주기]마다 정책을 준수하는지 확인해야 한다.
• ‌CM-7-4 블랙리스트 및 화이트리스트

## 1. 다음 중 하나 이상의 방식을 이용하여 소프트웨어 설치 및 운용을 제한 또는 승인하여야 한다.


가. 화이트리스트(인가된 소프트웨어 목록) 기반 설치 및 운용 승인

나. 블랙리스트(비인가 소프트웨어 목록) 기반 설치 및 운용 제한

## 2. 인가 및 비인가 소프트웨어 목록을 [조직이 지정한 주기]마다 검토하고 업데이트해야 한다.


---
<!-- Page 138 -->
138 | 우주 보안 모델 해설 및 적용사례집
제6절
사고 대응(IR)
IR-01
사고 처리 및 테스트
항목 내용
사고대응 준비, 사고탐지, 사고 조사/분석, 피해 시스템의 분리 및 차단, 피해
시스템 복구를 포함한 사고처리 대응 체계를 구축하고 주기적으로 사고대응
테스트를 실시해야 한다.
목적
중요 우주 시스템에 대한 보안사고 발생 시 피해를 최소화하고 신속하게
복구하기 위해, 사고 탐지부터 복구에 이르는 전 과정에 대한 체계적인 대응
역량을 구축하고 그 실효성을 검증하기 위함이다.
주요
확인사항
y ‌시스템에서 발생하는 의심스러운 이벤트를 사전에 정의된 기준에 따라 사고
여부, 유형 및 심각도를 평가하여 분류하고 있는가?
y ‌우주기업의 특성을 반영하여 사고 탐지/대응/복구를 포함하는 사고 대응
체계를 수립하고 있는가?
y ‌사고 대응 완료 후 사후 검토를 수행하고, 그 결과를 체계에 반영하고 있는가?
y ‌사고 대응 모의 훈련을 정기적으로 실시하고, 그 결과를 체계 및 절차 개선에
반영하는가?
세부 설명
⊙ ‌시스템에서 발생하는 의심스러운 이벤트를 사전에 정의된 기준에 따라 사고 여부, 유형 및 심각도를
평가하여 분류해야 한다.
▶ ‌한국인터넷진흥원에서 발간한 정보통신분야 침해사고 대응 안내서에서 정의한 보안 사고 유형은
아래와 같음
보안 사고 유형 (예시)
y ‌바이러스, 트로이목마, 웜 등 악성코드에 의한 시스템 침해 및 공격
y ‌비인가된 시스템 또는 파일 접근으로 인한 정보 유출 또는 훼손 행위
y ‌네트워크 또는 정보시스템의 정상적인 서비스를 마비 또는 파괴하는 공격
y ‌네트워크 정보 수집을 포함한 비인가된 네트워크 정보 접근 행위
y ‌네트워크 서비스의 취약점을 이용하여 서비스를 무단으로 이용하는 행위
출처 : 정보통신분야 침해사고 대응 안내서(KISA)

---
<!-- Page 139 -->

## 제3장 우주 보안모델 해설  | 139

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌사고 판단 기준은 지상 구간과 우주 구간을 고려하여 설정하고, 사고로 판단된 이벤트는 유형 및
심각도에 따라 분류해야 함
• ‌지상 구간(Ground Segment)과 우주 구간(Space Segment)에 미치는 잠재적 영향을 반영하여
사고 판단 기준을 수립
- ‌핵심 시스템의 경우, 중요도 및 민감도를 기준으로 탐지 임계값을 설정하고, 오탐 허용 범위를
포함하여 문서화
- ‌임계값 초과 또는 근접 시 수행해야 할 통지 및 신고 절차를 정의
• ‌중대한 사고 판단기준 예시 :
- ‌NIS2에서 정의한 데이터 센터 서비스 제공자의 중대한 사고 판단 기준은 아래 표와 같음
데이터 센터 서비스 제공자의 중대한 사고 기준
사고 유형
정량적 기준

## 1. 서비스 이용 불가

발생

## 2. 가용성 제한

1시간 초과 지속

## 3. 물리적 접근 침해

데이터 센터에 대한 물리적 접근이 침해된 경우
▶ ‌이벤트 평가 및 분류를 위한 로그 분석 절차 수립
• ‌임무 운영 센터(MOC, Mission Operations Center), 탑재체 제어 센터(PCC, Payload
Control Center), 지상국, 보안 장비에서 생성되는 로그를 식별·수집
• ‌로그 상관관계 분석으로 분산된 이벤트 간 연관성 분석
- ‌새로운 정보 확인 또는 이전에 확보된 정보 분석이 완료된 경우, 해당 이벤트를 재평가 및
재분류
- ‌반복 발생 이벤트가 존재하는지 주기적으로 평가
⊙ ‌우주기업의 특성을 반영하여 사고 탐지/대응/복구를 포함하는 보안 사고 대응 체계를 수립해야
한다.
▶ ‌보안 사고 대응 체계 내 역할과 책임을 정의해야 함
• ‌사고 대응팀을 구성하고 사고 대응 관련 주요 역할(초기 탐지 담당, 사고 보고 접수 담당,
이해관계자 소통 담당자 등)을 문서로 정의
• ‌비상 연락 대상·연락 수단·대체 연락 경로를 포함한 비상 연락망을 구축하고 최신 상태로 유지
▶ ‌보안 사고 대응 절차는 사고 탐지/대응/복구로 구성하고, 아래 내용을 포함
• ‌사고는 시스템 및 네트워크 사용자 또는 관리자에 의해 탐지될 수 있으며, 침입탐지 시스템,

---
<!-- Page 140 -->
140 | 우주 보안 모델 해설 및 적용사례집
방화벽과 같은 보안 장비에서 세부 기록 확인 가능
• ‌사고 탐지 시 영향 범위를 신속히 평가하고, 지상 구간 및 우주 구간으로 확산 가능성 판단
- ‌방화벽, 네트워크 접근제어(NAC)으로 사고가 발생한 구간과 타 구간 간의 트래픽을
차단하거나, 탑재체로 전달되는 명령 링크의 송신 권한을 일시로 제한하는 조치 등을 통해 사고
확산 방지 가능
출처 : 정보통신분야 침해사고 대응 안내서(KISA)
• ‌정책, 기술, 법, 업무 등의 사고와 관련된 요인들을 고려하여 사고 대응 전략 수립
- ‌예시 : 침해당한 컴퓨터가 얼마나 중요하고 위험한지, 침해당하거나 도난당한 정보가 얼마나
민감한 것인지, 공격자에 의해 침해된 비인가 접근의 수준은 어느 정도인지, 형사소송 또는
민사소송을 할 필요가 있는지 등
사고유형에 따른 대응 전략 예시
사고 유형
대응 전략
예상 결과
DoS 공격 (TFN
DDoS, Flooding)
라우터 재설정으로 트래픽 흐름
제어
공격 효과 완화, 서비스 영향 최소화
비인가 사용 (업무용
컴퓨터 오용)
증거물 포렌식 이미지 확보 및 조사,
용의자 면담
범인 식별, 징계 위한 증거 확보,
조직 정책 위반 여부 검토
파괴 행위 (웹사이트
손상)
웹사이트 모니터링, 온라인 상태
조사, 복구 작업
웹사이트 복구, 필요 시 수사기관
참여로 범인 식별
정보 도난 (고객정보
유출)
관련 시스템 이미지 확보, 도난
신고, 법적 대응 준비
상세 조사 시작, 수사기관 참여,
민사소송 가능, 일정 기간 시스템
오프라인 유지
컴퓨터 침입 (버퍼
오버플로우, 원격 접속)
공격자 활동 감시, 비인가 접속
봉쇄, 보안 재설정 및 복구
취약점 식별·패치, 시스템 복구, 범인
식별 여부 결정
출처 : 정보통신분야 침해사고 대응 안내서(KISA)

---
<!-- Page 141 -->

## 제3장 우주 보안모델 해설  | 141

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌사고로 인해 중단된 서비스를 정상 운영 상태로 복구하기 위한 절차를 수립·유지해야 함
• ‌시스템 복구는 임의 백업이나 출처가 불분명한 이미지 사용을 금지하고, 형상 관리가 적용된
사전에 승인된 복구 기준본으로 수행
• ‌복구 완료 후에는 시스템 재설정, 기능 점검 및 보안성 검증을 수행하여 정상 동작 확인
- 주요 기능, 보안 설정, 연계 시스템 동작 여부를 점검하여 서비스 재개 가능 여부 판단
• ‌사고 대응 과정에서 적용한 임시 보안 조치, 우회 설정, 예외 권한은 복구 완료 후 즉시 해제하고,
정상 운영 환경으로 전환해야 함
⊙ ‌사고 대응 완료 후 원인 분석 및 재발방지 대책을 포함하는 사후 검토를 수행하고, 그 결과를 사고
대응 체계에 반영한다.
▶ ‌사고 대응 완료 후에는 사고의 재발 방지 및 대응 체계 개선을 위해 공식적인 사후 검토 활동을
의무적으로 수행
• ‌사후 검토 수행 시점, 책임 조직, 참여 인력을 사전에 정의
• ‌사후 검토는 사고 종료 이후 일정 기간 내 수행
• ‌사고 당시 수집된 로그, 이벤트 정보, 대응 기록을 기반으로 분석 수행하며, 사고의 근본 원인을
식별
• ‌식별된 취약점은 패치 및 업데이트 적용
▶ ‌사후 검토를 통해 도출된 개선 사항을 바탕으로 사고 대응 체계 및 예방 통제를 개선하는 계획을
수립하고 그 결과를 체계에 반영
• ‌사후 검토를 통해 도출된 개선 사항은 사고 대응 절차, 복구 계획, 테스트 시나리오에 통합 및
업데이트되어야 함
⊙ ‌사고 대응 모의 훈련을 정기적으로 실시하고, 그 결과를 체계 및 절차 개선에 반영한다.
▶ ‌조직의 사고 대응 역량을 검증하기 위하여 연 1회이상 모의 훈련 실시
▶ ‌핵심 시스템이나 환경에 중대한 변화(시스템 교체, 임무 투입, 대규모 업데이트)가 발생한 경우
추가 훈련 실시
• ‌운영 환경과 유사한 테스트 환경 또는 격리된 시뮬레이션 환경 등 실제 지상국 운영에 영향을
주지 않는 환경에서 수행해야 함
• ‌훈련은 사고 대응팀뿐만 아니라 임무 운영센터, 탑재체 제어 센터, 관제 인력, IT 운영 인력,
경영진 등 사고 대응 역할이 부여된 모든 인력이 참여
▶ ‌훈련 과정에서 얻은 교훈과 발견된 계획의 결함을 사고 대응 절차 및 복구 계획에 반영

---
<!-- Page 142 -->
142 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ CMMC
• ‌R.L2-3.6.1 사고 처리 : 준비, 탐지, 분석, 격리, 복구 및 사용자 대응 활동을 포함하는 조직 시스템에 대한
운영적 사고 처리 역량을 구축한다.
• ‌IR.L2-3.6.3 사고 대응 테스트 : 조직의 사고 대응 역량을 테스트한다.
⊙ K-RMF
• ‌IR-4 사고대응 테스트 : 시스템에 대한 사고대응 능력을 [조직이 지정한 주기]마다 [조직이 지정한
테스트]를 실시하고 그 결과를 기록 및 유지해야 한다.
• ‌IR-5 사고처리 :
1. ‌사고대응 준비, 사고 탐지, 사고 조사/분석, 피해 시스템의 분리 및 차단, 피해 시스템 복구를 포함하여
사고를 처리하기 위한 능력을 갖춰야 한다.

## 2. 사고처리 활동을 비상계획과 연계해야 한다.

3. ‌진행 중인 사고처리 간 얻은 교훈을 사고대응 절차, 교육훈련 및 평가에 적절하게 반영 및 이행해야 한다.
⊙ NIS2
• ‌3.1 사고 대응 정책 : 관련 기관은 사건을 적시에 탐지, 분석, 격리, 대응, 복구, 문서화 및 보고하기 위한
역할, 책임, 절차를 규정하는 사고 처리 정책을 수립하고 시행해야 한다.
• ‌3.4 이벤트 평가 및 분류 : 관련 기관은 의심되는 사건을 평가하여 그것이 실제 사고인지 여부를 판단하고,
사고일 경우 그 성격과 심각성을 결정해야 한다.
• ‌3.5 사고 대응 절차 : 관련 기관은 문서화된 절차에 따라 사고에 신속하게 대응해야 한다.
• ‌3.6 사후 검토 : 관련 기관은 필요할 경우 사고 복구 후 사후 검토를 수행해야 한다.
⊙ ISMS-P
• ‌2.11.1 사고 예방 및 대응체계 구축 : 침해사고 및 개인정보 유출 등을 예방하고 사고 발생 시 신속하고
효과적으로 대응할 수 있도록 내·외부 침해시도의 탐지·대응·분석 및 공유를 위한 체계와 절차를 수립하고,
관련 외부기관 및 전문가들과 협조체계를 구축하여야 한다.
• ‌2.11.4 사고 대응 훈련 및 개선 : 침해사고 및 개인정보 유출사고 대응 절차를 임직원과 이해관계자가
숙지하도록 시나리오에 따른 모의훈련을 연 1회 이상 실시하고 훈련결과를 반영하여 대응체계를
개선하여야 한다.

---
<!-- Page 143 -->

## 제3장 우주 보안모델 해설  | 143

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
IR-02
사고 보고
항목 내용
사고를 인지한 인원이 지정한 시간 내에 사고대응 부서에 신고하고 사고대응
부서는 사고를 관련 기관에게 통지해야 한다.
목적
보안 사고 발생 시 신속한 내부 보고와 대외 통지를 통해 적절한 기술적·관리적
조치를 조기에 시행하고, 조직 차원의 사고 대응의 일관성을 확보하기 위함이다.
주요
확인사항
y ‌사고 인지 인원이 내부 담당자에게 보고하는 절차 및 사고 보고 체계가
수립·운영되고 있는가?
y ‌사고의 유형 및 심각도에 따라 관련 법령에 근거하여 신고(관계기관) 절차를
수립·이행하는가?
y ‌사고대응 부서가 사고 발생 사실을 관련 이해관계자에게 적시에 통지하는
절차를 마련하고 있는가?
세부 설명
⊙ ‌사고 인지 인원이 내부 담당자에게 보고하는 절차 및 사고 보고 체계를 수립·운영해야 한다.
▶ ‌사고 인지 시 지체 없이 보고가 가능하도록 주된 보고 경로 (예: 정보보호 부서의 사고 핫라인,
24/7 보안 관제 전화번호 등) 및 장애 발생 시 활용 가능한 대체 보고 경로(예: 담당자 전화번호,
이메일 등) 확보
▶ ‌비상연락망을 구축하고 분기 1회 이상 점검하여 최신 상태로 유지
• ‌비상연락망은 직책 기준으로 작성하고, 각 대상자별로 휴대전화(주 연락 수단)와 이메일·사내
메신저 등 대체 수단을 함께 관리
• ‌비상 상황에서의 연락 우선순위와 에스컬레이션 절차(1차 책임자 미응답 시 대리 또는 상위
책임자로 전환)를 정의
▶ ‌사고를 인지한 모든 인원은 지정된 시간 내 사고 대응 부서(또는 담당자)에게 보고해야 하며,
아래 항목이 포함되어야 함
• ‌사고 인지 시 즉각 수행해야 할 조치
- ‌예) 문제 발생 시 즉시 모든 관련 세부사항 기록, 화면에 표시되는 메시지 기록, 즉시 지정된
책임자에게 보고 등
• ‌사고 보고 항목 구성
- ‌현재 시간과 날짜, 사고보고 내용과 출처, 사건이 일어난 일시, 피해 시스템 명칭/IP, 관련
하드웨어/소프트웨어의 목록
- ‌예: MOC/PCC 시스템의 비정상 유무, 명령 링크 관련 오류 여부, 관제 데이터의 무결성 침해
징후 등 임무 연속성 관련 정보

---
<!-- Page 144 -->
144 | 우주 보안 모델 해설 및 적용사례집
▶ ‌우주기업은 모든 관련 인원에게 사고 보고 절차 및 중요성에 대해 분기마다 교육해야 함
⊙ ‌사고의 유형 및 심각도에 따라 관련 법령에 근거하여 신고(관계기관) 절차를 수립·이행해야 한다.
▶ ‌사고 대응 부서는 사고의 유형 및 심각도 평가 결과를 바탕으로 관련 법령 및 규제 (예:
정보통신망법, NIS2 등) 상의 외부 신고 의무를 확인해야 함
[정보통신망법 제48조의3]
정보통신서비스 제공자는 침해사고의 발생을 알게 된 때부터 24시간 이내에 아래 내용을
과학기술정보통신부장관 또는 한국인터넷진흥원에 신고

## 1. 침해사고의 발생 일시, 원인 및 피해내용


## 2. 침해사고에 대한 조치사항 등 대응 현황


## 3. 침해사고 대응업무를 담당하는 부서 및 연락처

▶ ‌보안사고 신고 접수처
• ‌전화: ☎ 118 (인터넷침해대응센터, 24시간 운영)
• ‌온라인: 보호나라 & KrCERT 홈페이지 → ‘침해사고 신고’ 메뉴
• ‌이메일: certgen@krcert.or.kr
• ‌방문/우편: 서울특별시 송파구 중대로 135, IT벤처타워 서관 5층 종합상황실
▶ ‌신고 기관을 사전에 식별하고, 해당 기관별 공식 신고 절차를 수립하여 이행해야 함
• ‌우주기업에 적용되는 법적/계약적 사고 신고 의무(신고 대상 기관, 신고 기한)을 파악하여
목록으로 관리
• ‌사고 심각도와 법적 요건에 따라 외부 신고 여부를 판단할 수 있는 기준을 마련
• ‌외부 신고 책임자를 지정하고, 최종 신고 전 경영진 및 법무팀의 승인을 거쳐야 함
• ‌신고 시 제출해야 할 필수 정보 양식을 사전에 준비하고, 공개 범위를 명확히 함
• ‌법정 신고 기한을 준수하여 관계 기관에 신고를 수행하고, 신고 일시, 신고 내용, 접수 결과 등을
증적으로 기록·관리하여 사후 검토에 활용
⊙ ‌사고대응 부서가 사고 발생 사실을 관련 이해관계자에게 적시에 통지하는 절차를 마련해야 한다.
▶ ‌사고 통지 대상, 통지 시점, 통지 수단(이메일, 유선, 메신저 등)과, 통지 책임자를 사전에 지정
• ‌통지가 필요한 내부 및 외부 이해관계자를 식별하고 최신 연락망을 유지
- 내부: 경영진, 사고로 인해 직접적인 영향을 받는 주요 시스템 운영·책임자
- 외부: 협력업체 직원, 탑재체 운영자, 장치 공급업체, 고객 등 계약 상 통지 의무가 있는 대상

---
<!-- Page 145 -->

## 제3장 우주 보안모델 해설  | 145

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌통지 내용에는 다음 사항을 포함해야 함
- 사고 유형과 발생 시점
- MOC/PCC 등 주요 시스템 영향 범위 및 데이터 무결성 영향 여부
- 서비스 영향 최소화를 위해 이해관계자가 즉시 수행해야 할 조치
- 사고 대응 전담 조직의 상시 연락 창구
▶ ‌사고가 위성 운영 또는 탑재체 서비스에 영향을 미칠 경우, 사전 합의된 절차에 따라 PCC 및
탑재체 소유자에게 지체 없이 통보
관련 외부 법령
[NIS2 Directive / NIS2 COMMISSION IMPLEMENTING REGULATION]
‌NIS2 지침은 유럽연합 전역에서 높은 공동 사이버보안 수준을 달성하기 위해 제정된 법령으로, 기업이
유럽연합(EU) 시장에 진출하거나 해당 시장의 고객에게 서비스를 제공할 경우, EU의 NIS2 지침(Directive
(EU) 2022/2555)의 규제 대상이 된다.

## I. 사고 보고 원칙


## 1. 보고 시점

‌사고 발생 통지 기한은 지침의 규정에 따라 중대 사고가 발생했다는 ‘인식 시점’을 기준으로 정해진 기한
내에 보고해야 한다.
• ‌인식 시점의 정의: 의심스러운 이벤트에 대한 초기 평가 후, 중대 사고가 발생했다는 합리적인 확실성을
갖게 된 시점
보고 유형
보고 기한
보고 내용
조항
1단계:
조기 경고
부당한 지체 없이, 반드시
24시간 이내
해당 사건이 불법적이거나 악의적 행위로
의심되는지, 또는 대외적인 영향을 줄 수
있는지를 표시
Article
23(4)(a)
2단계:
사고 통지
부당한 지체 없이, 반드시
72시간 이내
조기 경고 정보 갱신, 심각성과 영향을 포함한
초기 평가 및 가능한 경우 침해 지표(IoC) 제시
Article
23(4)(b)
3단계:
중간 보고
CSIRT 또는 관할 당국의
요청 시
관련 상태 변화에 대한 업데이트
Article
23(4)(c)
4단계:
최종 보고
72시간 내 통지 제출 후
1개월 이내
상세한 사건 설명, 위협 유형/근본 원인,
적용/진행 중인 완화 조치, 대외적인 영향(해당
시) 포함
Article
23(4)(d)

---
<!-- Page 146 -->
146 | 우주 보안 모델 해설 및 적용사례집

## 2. 중대한 사고 판단 시점 및 기준 (General Significance Criteria)

보고 의무가 발생하는 ‘중대한 사고(Significant Incident)’의 판단 기준은 아래와 같다.
구분
중대 사고 발생 기준
정량적 기준
조항
재정적 손실
해당 엔티티에 직접적인 손실을
일으키거나 일으킬 수 있는 경우
EUR 500,000 또는 직전
연도 총 매출액의 5% 중 낮은
금액을 초과
Article
3(1)(a)
기밀 유출
해당 엔티티의 영업 비밀 유출을
일으키거나 일으킬 수 있는 경우
영업 비밀 유출 여부
Article
3(1)(b)
인명 피해
자연인의 사망 또는 건강에 상당한 손상을
일으키거나 일으킬수 있는 경우
사망 또는 상당한 손상
Article
3(1)(c, d)
운영 중단
성공적이고 악의적인 것으로 의심되는
네트워크 및 정보 시스템에 대한 무단
접근이 심각한 운영 중단을 일으킬 수 있는
경우
무단 접근 및 심각한 운영 중단
가능성
Article
3(1)(e)

## 3. 보고 주체 및 대상

• ‌보고 주체: NIS2의 적용을 받는 관련 엔티티
• ‌보고 대상: 사고 통지와 관련하여 CSIRTs 또는 해당되는 관련 당국 과 통신 계획을 수립해야 한다.

## 4. 위반 시 제재

제재 내용
구분
금액/범위
조항
중대한 사고 통지 지연 또는
누락 시
필수
기관
최대 연간 매출의 2% 또는 EUR 10,000,000
중 높은 금액 (회원국별 상한 조정 가능)
Article
34(4)
중요
기관
최대 연간 매출의 1.4% 또는 EUR 7,000,000
중 높은 금액 (회원국별 상한 조정 가능)
Article
34(5)
※ NIS2는 우주 산업 부문을 필수 기관으로 지정하고 있음

## II. GSaaS (Ground Segment as a Service) 우주 기업의 사고 대응

‌클라우드 서비스, 데이터 센터, 또는 관리 서비스를 제공하는 GSaaS 형태일 경우, 다음의 기준을 충족하면
중대 사고로 간주된다.

---
<!-- Page 147 -->

## 제3장 우주 보안모델 해설  | 147

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
서비스 유형
사고 유형
(중대성 기준)
정량적 기준
(기간 및 범위)
출처 조항
클라우드 컴퓨팅
서비스 제공자
(Cloud
Computing)

## 1. 서비스 이용 불가

30분 초과
Article 7(a)

## 2. 가용성 제한

EU 내 사용자 중 5% 초과 또는 1백만 명
중 작은 수에게 1시간 초과 동안 영향
Article 7(b)

## 3. 악성 데이터 침해

악의적인 행위의 결과로 데이터의 무결성,
기밀성 또는 진정성이 침해된 경우
Article 7(c)
데이터 센터 서비스
제공자
(Data Centre)

## 1. 서비스 이용 불가

발생
Article 8(a)

## 2. 가용성 제한

1시간 초과 지속
Article 8(b)

## 3. 물리적 접근 침해

데이터 센터에 대한 물리적 접근이 침해된
경우
Article 8(d)
관리 서비스 제공자
(MSP/MSSP)

## 1. 서비스 이용 불가

30분 초과
Article 10(a)

## 2. 가용성 제한

EU 내 사용자 중 5% 초과 또는 1백만 명
중 작은 수에게 1시간 초과 동안 영향
Article 10(b)

## III. 우주 공급망 관련 기업 (위성/발사체 제조사)

‌우주 공급망의 위성/발사체 제조사로서 EU의 다른 엔티티(예: 위성 운영사)에 ICT 제품이나 서비스를
공급하는 공급망 기업일 경우, 사고 보고 의무는 다음과 같이 구분된다.

## 1. 제조사 자체의 중대 사고

‌제조사 자체의 네트워크 및 정보 시스템에 발생한 사고가 위에 명시된 일반 기준 (I-1) 중 하나를 충족하는
경우, 중대 사고로 간주하여 NIS2 보고 의무를 이행해야 한다.

## 2. 공급망 관점에서의 통지 의무 (Supply Chain)

‌제조사(공급업체/서비스 제공업체)가 고객인 관련 엔티티(Relevant Entity)에게 제공하는 제품이나
서비스와 관련된 사고 발생 시, 계약상의 통지 의무를 준수해야 한다.
구분
통지 대상
통지 기한 및 의무
계약상 의무
서비스/제품을 구매한
관련 고객
공급업체 및 서비스 제공업체는 고객의 네트워크 및 정보 시스템
보안에 위험을 초래하는 인시던트를 지체 없이 (without undue
delay) 통지할 의무를 계약서에 명시해야 함
[DFARS 252.204‑7012]
‌DFARS(DOD Federal Acquisition Regulation Supplement)는 미국 국방부(DoD) 조달 계약자가 반드시
따라야하는 법적 효력을 가진 규정으로, 사이버 보안 요구사항과 계약 조건을 명확히 규정한다. DFARS
252.204-7012, 7019, 7020 등에서는 계약자의 NIST SP 800-171 준수 의무를 명시하고 있다. NIST SP
800-171은 비연방 시스템에서 CUI(Controlled Unclassified Information)를 보호하기 위한 기술적 보안
지침으로 DFARS로 인해 강제되는 기준이 된다.
‌CMMC는 NIST SP 800-171의 110개 보안 통제 구현 여부를 검증하기 위한 평가·인증 프레임워크로,
DoD는 향후 계약 과정에서 CMMC 인증을 입찰 자격 요건으로 적용할 계획이다. 즉, 미국 방위산업 공급망에
참여하기 위해 CMMC 인증을 준비하는 기업(하청업체 포함)은 DFARS에서 규정한 사고보고 의무 역시 함께
준수해야 한다.

---
<!-- Page 148 -->
148 | 우주 보안 모델 해설 및 적용사례집

## 1. 보고 시점 및 대상

• ‌보고 시점: 사이버 사고 발견 후 72시간 이내
• ‌보고 대상: DC3 DCISE(미국방부 산하 사이버 사고 대응 기관)을 통해 온라인 보고
• ‌보존 의무: 사고 관련 시스템 이미지 및 네트워크 데이터 90일간 보존
※ ‌사이버 사고를 미국방부에 보고하려면 반드시 DoD 승인 Medium Assurance Certificate 인증서를
보유해야 함
- ‌사이버 사고 보고 시스템에 안전하게 접근하고, 사고 정보를 암호화된 방식으로 제출하기 위한 디지털
신원 인증 수단
- ‌DoD에서 승인한 외부 인증기관(ECA: External Certification Authority)에서 발급

## 2. 보고 대상 판단 기준

DFARS 252.204‑7012에서 규정하는 보고 대상 판단 기준은 다음과 같다.
구분
보고 대상 판단 기준
조항
기밀 유출
보호되고 있는 방위 정보의 무단 접근, 유출, 변경, 파괴, 손실, 복사 등이
발생하거나 발생 가능성이 있는 경우
(c)(1)
운영 중단
계약자가 수행하는 Operationally Critical Support(정부가 지정한 군사
작전 수행에 필수적인 물자 또는 서비스)에 영향을 미치는 사이버 사고
(c)(1)
시스템 침해
보호 대상 국방 정보를 처리, 저장 또는 전송하는 시스템에 대한 침해 또는
손상
(c)(1)
악성코드 발견
사이버 사고와 관련된 악성 소프트웨어를 발견하고 격리한 경우
(d)

## 3. 위반 시 제재

‌DFARS 조항 자체는 특정 처벌을 명시하지 않으며, 계약기관이 상황에 따라 적절한 조치를 결정한다.
계약기관은 조항을 위반할 경우 아래의 제재를 적용할 수 있다.
구분
제재 조치
계약적 제재
계약 불이행 시 지급금 보류
사업 시스템/계약자 구매 시스템 승인 거부
향후 계약 발주 거부
향후 계약 옵션 행사 거부
과거 성과 평가 부정적 기록
작업 중단 명령(Stop Work Order) 발행
시정 요구 통지(Cure Notice) 발행
이유 제출 요청(Show Cause Notice) 통지
계약 해지 절차 고려
계약자가 비응답(Non-Responsive)으로 판단
시정조치 요청(Corrective Action Request, CAR) 발행
행정·사법적
제재
계약 참가 자격 정지 및 입찰 제한
민사 책임 또는 손해배상 청구
형사 책임 추궁 또는 형사 처벌

---
<!-- Page 149 -->

## 제3장 우주 보안모델 해설  | 149

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ CMMC
• ‌IR.L2-3.6.2 사고 보고 : 조직 내부 및 외부의 지정된 담당자 및/또는 당국에 사건을 추적, 문서화하고
보고한다.
⊙ K-RMF
• ‌IR-7 사고 보고 :
1. ‌사고를 인지한 인원에게 [조직이 지정한 시간] 내에 해당 기관의 사고대응 부서에 보고(신고)하도록
요구해야 한다.

## 2. 사고대응 부서가 사고를 [조직이 지정한 기관]에게 보고(신고)하도록 요구해야 한다.

⊙ NIS2
• ‌3.3 이벤트 보고 : 관련 기관은 직원 및 고객이 의심스러운 사건을 신고할 수 있는 절차를 마련해야 한다.
⊙ ISMS-P
• ‌2.11.1 사고 예방 및 대응체계 구축 : 보안사고 및 개인정보 유출 등을 예방하고 사고 발생 시 신속하고
효과적으로 대응할 수 있도록 내·외부 침해시도의 탐지·대응·분석 및 공유를 위한 체계와 절차를 수립하고,
관련 외부기관 및 전문가들과 협조체계를 구축하여야 한다.

---
<!-- Page 150 -->
150 | 우주 보안 모델 해설 및 적용사례집
제7절
인원 보안(PS)
PS-01
인원보안
항목 내용
직원 고용 시 배경 검사를 시행하고, 보직 변경 또는 퇴직 시 시스템 접근 권한을
검토·변경·삭제해야 하며, 기업의 보안정책 위반 시 징계 절차를 수립해야 한다.
목적
인력 변동 과정에서 발생할 수 있는 내부자 위협을 통제하고, 신뢰할 수 없는
인력이 민감 시스템에 접근하는 것을 방지함으로써 내부 정보 유출과 무단 접근
위험을 최소화하기 위함이다.
주요
확인사항
y ‌직원 채용 시 중요 정보에 접근하는 인력에 대해 직무의 위험 수준을 고려하여
채용 전 배경 확인 절차를 수립·이행하는가?
y ‌퇴직·전보·직무 변경 시 정보보안 책임을 명확히 하고, 접근 권한 회수 및 자산
반납 절차를 이행하는가?
y ‌임직원 및 협력업체 직원의 보안 정책을 위반에 대해 징계 기준 및 후속 조치
절차를 수립·운영하는가?
세부 설명
⊙ ‌직원 채용 시 중요 정보에 접근하는 인력에 대해 직무의 위험 수준을 고려하여 채용 전 배경 확인
절차를 수립·이행한다.
▶ ‌우주기업은 주요 시스템에 대한 접근 권한을 부여하기 전에 배경 검사를 수행
• ‌우주 자산의 높은 가치를 고려할 때, 우주기업은 임무 운영 센터 및 탑재체 통제 센터 인력에 대해
정기적인 배경 검사를 고려
▶ ‌배경 검사는 관련 개인정보 보호, 고용 관련 법률을 고려하여 수행되어야 하며, 다음 사항을
포함할 수 있음
• ‌적절한 추천서(업무 및 개인 추천서 등)의 확보
• ‌지원자의 이력서 완전성 및 정확성 검증
• ‌주장하는 학력 및 전문 자격 확인
• ‌독립적인 신원 확인(예: 여권 또는 권한있는 기관에서 발급한 문서)
▶ ‌배경 검사의 대상, 범위 및 절차는 직무의 위험도를 고려하여 차등 적용하며, 검사 결과는 권한
부여의 기초 자료로 활용해야 함

---
<!-- Page 151 -->

## 제3장 우주 보안모델 해설  | 151

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌특정 정보보안 업무에 채용할 경우, 후보자가 해당 보안 역할 수행에 필요한 역량을 갖추었는지,
특히 해당 역할이 조직에 중대한 경우 신뢰할 만한 인물인지 확인해야 함
⊙ ‌퇴직·전보·직무 변경 시 정보보안 책임을 명확히 하고, 접근 권한 회수 및 자산 반납 절차를
이행한다.
▶ ‌퇴직, 전보 또는 직무 변경 이후에도 유효해야 하는 정보보안책임과 의무를 정의해야 함
• ‌기밀정보, 지적재산권, 비밀유지 계약에 포함된 책임 등
• ‌퇴직 이후에도 유효한 책임과 의무를 개인의 고용 조건, 계약서 또는 협약에 명시해야 함
• ‌퇴직, 전보 또는 직무 변경하는 개인이 가진 보안 역할 및 책임을 파악하여 다른 개인에게
인계해야 함
• ‌변경사항 및 운영 절차를 관련 인력, 기타 이해관계자(예: 고객, 공급업체)에게 전달해야 함
▶ ‌퇴직, 전보 또는 직무 변경 발생으로 인하여 정보 및 관련 자산에 접근할 필요가 없는 경우,
접근권한을 신속히 수정·제거해야 함
• ‌퇴직, 전보 또는 직무 변경 인력에 대해 직무상 반드시 필요한 최소 권한만 남기고, 특히 지상
구간내의 중요 시스템과 해당 인력의 단말 간에 정보 흐름을 논리적으로 격리하여 무단 데이터
접근을 신속히 차단
- ‌예: 중요 임무 데이터 접근 권한을 읽기 권한으로 즉시 강등하거나, 해당 PC와 MOC/PCC
내부망과의 통신 차단
• ‌물리적 및 논리적 접근 권한은 제거·회수·교체 등을 통해 신속하게 조정해야 함
- 예: 열쇠, 인증 정보, ID 카드 등을 제거·회수·교체
▶ ‌퇴직, 전보 또는 직무 변경 시 소유하고 있는 조직의 모든 자산을 회수하는 절차를 수립해야 함
• ‌직원 및 기타 이해당사자가 조직의 장치를 구매하거나 개인 장치를 사용하는 경우, 해당 장치에서
관련 정보가 모두 식별되어 조직으로 안전하게 이전되고 장치에서는 안전하게 삭제해야 함
• ‌퇴직 예정인 직원이 퇴직 시까지 우주 임무 기밀 정보 등 관련 정보를 무단 복사하지 못하도록
데이터 유출 방지(DLP) 보호 조치를 적용하여 통제해야 함
• ‌반환 대상인 모든 정보 및 기타 관련 자산을 명확히 식별하고 문서화해야 함
- ‌예: 사용자 단말기, 휴대용 저장장치, 정보시스템 및 물리적 문서 보관소용 인증
하드웨어(기계식 열쇠, 물리적 토큰, 스마트 카드), 정보의 물리적 복사본
▶ ‌인사 변동 발생 시, 기존의 접근권한을 삭제하고 변동된 업무에 맞는 접근권한 및 인증 정보를
할당
⊙ ‌임직원 및 협력업체 직원의 보안 정책을 위반에 대해 징계 기준 및 후속 조치 절차를 수립·운영해야
한다.

---
<!-- Page 152 -->
152 | 우주 보안 모델 해설 및 적용사례집
▶ ‌임직원 및 협력업체 직원이 법적 의무 또는 내부 보안 정책을 위반한 경우에 적용할 수 있는 징계
기준 및 절차를 공식적으로 수립하고 문서화해야 함
▶ ‌보안 정책 위반이 실제로 발생했음을 확인한 뒤 징계 절차를 시작해야 하며, 다음과 같은 요소를
고려하여 단계적인 대응을 제공해야 함
• ‌위반의 성격(누가, 무엇을, 언제, 어떻게)과 우주 임무의 연속성 및 안전성 영향을 포함한 위반의
심각성 및 그 결과
• ‌위반이 의도적(악의적)이었는지, 아니면 비의도적(실수)이었는지
• ‌해당 위반이 최초 위반인지, 반복 위반인지
• ‌위반자가 적절한 교육을 받았는지 여부
▶ ‌징계 결정 후에는 인사 조치 절차와 연계하여 시스템 접근 권한 변경/취소, 자산 회수 등 필요한
후속 조치를 지체 없이 이행해야 함
▶ ‌징계 기준 및 절차를 모든 임직원에게 연 1회이상 인지시키고, 징계 결정 및 관련 후속 조치
이력은 기록으로 유지·관리해야 함
▶ ‌정보보안에 대한 책임과 의무를 충실히 이행한 경우, 정보보안을 장려하고 긍정적 행동을
촉진하기 위해 보상 방안을 고려할 수 있음
관련 기준
⊙ CMMC
• ‌PS.L2-3.9.1 개인 검사 : CUI가 포함된 조직 시스템에 대한 액세스를 승인하기 전에 개인을 선별한다.
• ‌PS.L2-3.9.2 인사 조치 : 해고 및 전근과 같은 인사 조치 중 및 이후에 CUI가 포함된 조직 시스템이
보호되도록 보장한다.
⊙ K-RMF
• ‌PS-2 신원조사 :

## 1. 시스템 접근권한 부여 전 해당 인원을 대상으로 신원조사를 실시해야 한다.

2. [필요한 경우와 조직이 지정한 주기]마다 해당 인원의 신원조사를 다시 실시해야 한다.”
• ‌PS-4 보직변경 :

## 1. 보직변경 후에도 시스템/시설에 대한 논리적/물리적 접근인가를 유지할지 검토해야 한다.

2. [조직이 지정한 시간] 내에 [보직변경 시 수행할 조치]를 수행해야 한다.

## 3. 보직변경으로 인한 운영 요구사항의 변화에 따라 접근인가를 수정해야 한다.

4. [조직이 지정한 시간] 내에 [조직이 지정한 직책]에게 위 사항을 보고(통보)해야 한다.
⊙ NIS2
• ‌10.1 인적 보안 : 관련 기관은 직원 및 직접 공급업체·서비스 제공업체가 기관의 보안 정책에 따라 자신의
책임을 이해하고 성실히 이행하도록 보장하여야 한다.

---
<!-- Page 153 -->

## 제3장 우주 보안모델 해설  | 153

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌10.2 배경 확인 : 관련 기관은 필요 시 역할·책임·권한에 따라 직원 및 직접 공급업체·서비스 제공업체의
배경을 검증할 수 있도록 하여야 한다.
• ‌10.3 고용 종료 또는 직무 변경 절차 : 관련 기관은 직원의 퇴직 또는 직무 변경 이후에도 유효한 네트워크
및 정보시스템 보안 책임과 의무가 계약상 정의되고 준수되도록 하여야 한다.
• ‌10.4 징계 절차 : 관련 기관은 네트워크 및 정보시스템 보안 정책 위반에 대한 징계 절차를
수립·전파·유지하여야 하며, 해당 절차는 관련 법령·계약·업무 요건을 고려하여야 한다.
• ‌12. 5 고용 종료 시 자산 반납·삭제 : 관련 기관은 직원 퇴직 시 보관 자산을 반납·삭제·회수하고 이를
문서화하며, 불가능한 경우 해당 자산의 네트워크·정보시스템 접근을 차단하여야 한다.
⊙ ISMS-P
• ‌2.2.5 퇴직 및 직무변경 관리 : 퇴직 및 직무변경 시 인사·정보보호·개인정보보호·IT 등 관련 부서별
이행하여야 할 자산반납, 계정 및 접근권한 회수·조정, 결과확인 등의 절차를 수립·관리하여야 한다.

---
<!-- Page 154 -->
154 | 우주 보안 모델 해설 및 적용사례집
PS-02
보안인식 교육 훈련
항목 내용
직무별 전문성을 확보할 수 있도록 인식 제고 활동 및 교육훈련 계획을
수립·시행해야 한다.
목적
모든 구성원이 자신의 직무와 관련된 보안 위험과 책임을 명확히 이해하여 보안
사고를 예방하고, 직무별로 요구되는 전문적인 보안 대응 역량을 강화하기
위함이다.
주요
확인사항
y ‌모든 구성원에게 보안 위험을 인식시키기 위한 인식 제고 활동 및 주요
직무자를 위한 전문 보안 교육을 시행하고 있는가?
세부 설명
⊙ ‌모든 구성원에게 보안 위험을 인식시키기 위한 인식 제고 활동 및 주요 직무자를 위한 전문 보안
교육을 시행해야 한다.
▶ ‌교육 목표, 내용, 방법, 이수 기준, 평가 기준 등을 명확히 규정한 공식 교육 계획을 체계적으로
수립하고 경영진의 승인을 받아야 함
• ‌교육 유형: 임직원 인식 제고 교육, 주요 직무자(특권 사용자) 전문 교육, 수탁자 교육 등
• ‌교육 계획: 교육 목적, 교육 대상, 교육 내용, 교육 방법, 교육 일정, 교육 시간 등(사업규모,
개인정보 보유 수, 업무 성격, 교육 대상, 교육 유형 등에 따라 차등화)
• ‌교육 승인: 교육 계획을 검토, 승인하여 계획에 따라 이행될 수 있도록 예산 배정 지원 등 필요한
행정적 조치를 완료해야 함
▶ ‌모든 임직원과 협력업체 직원을 대상으로 연간 교육 계획에 따라 연 1회 이상 정기적으로
인식제고 활동을 시행해야 함
• ‌대상 범위: 정보자산에 직·간접적으로 접근하는 임직원, 임시직원, 협력업체 직원 등 모든 인력
- 특히 위성 탑재체·지상국 통제 시스템 등 우주 임무 관련 인력을 필수로 포함해야 함
• ‌교육 내용: 임직원 및 관련 협력업체 직원이 자신의 책임과 그 책임을 수행하는 방법을
인지하도록 하는 것을 목표로 하며, 아래의 내용을 포함
- 조직 전반에 걸친 경영진의 보안에 대한 의지
- ‌정보보안 정책, 표준 법률, 계약 및 협약을 포함한 적용가능한 보안 규칙 및 의무에 대한 이해와
준수 필요성
- 본인의 행위로 인해 발생할 수 있는 보안사고에 대한 책임
- ‌임직원 및 협력업체 직원이 준수해야 하는 기본적인 정보보안 절차(예: 보안사고 보고 절차 및
기본통제(비밀번호 보안 등))

---
<!-- Page 155 -->

## 제3장 우주 보안모델 해설  | 155

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
- ‌추가 정보 및 조언을 얻을 수 있는 연락처 및 자원, 추가 정보 보안 인식 자료
• ‌불참자 및 추가 교육:
- ‌출장, 휴가, 업무 등으로 인하여 교육에 참석하지 못한 인력에 대한 추가 교육 방법을 마련하여
시행해야 함 (예: 불참자 대상 추가교육, 전달 교육, 온라인 교육 등)
- ‌내부 규정 및 절차의 중대한 변경, 조직 내·외부 보안사고 발생, 관련 법규 변경 등 발생 시
이에 대한 추가 교육을 수행해야 함 (다만 사안이 중요하지 않을 경우에는 게시판 공지, 이메일
안내, 책자 배포 등으로 대체)
▶ ‌주요 직무자가 자신의 직무와 책임에 따른 보안 지식을 습득할 수 있도록 역할에 맞는 보안
교육을 시행해야 함
• ‌관련 직무자: IT 직무자, 정보보호 최고책임자, 정보보호 직무자, MOC/PCC 시스템 관리자 등
• ‌교육 내용: 역할과 책임에 부합하는 맞춤형 전문 교육을 시행해야 하며, 명령 링크 관련 민감 정보
보호 등 직무별 전문 지식을 포함해야 함
• ‌교육 과정은 콘퍼런스·세미나·워크숍 참가, 교육 전문기관 위탁 교육, 외부 전문가 초빙을 통한
내부 교육 등을 활용할 수 있음
▶ ‌내부자 위협 대응 교육을 시행해야 함
• ‌모든 임직원 및 관리자에게 내부자 위협 징후 식별, 비인가 행위 기준 등을 위한 교육을 제공해야
함
• ‌내부자 위협 징후 식별 절차 예시
- ‌징후 정의 및 목록화: 비정상적인 접근 시도, 불필요한 민감 정보 조회, 반복적인 보안 정책
위반, 업무 시간과 맞지 않는 시스템 활동 등
- ‌모니터링: 시스템 로그, 명령 링크 사용 기록, 관제 데이터 분석, SOAR 등 자동화 도구 활용
- ‌식별 시 보고: 이상 징후 발견 시 보안 담당자 또는 관리자에게 즉시 보고, 관련 로그 기록 및
초기 대응 조치 문서화
- ‌후속 조치: 필요 시 권한 제한, 포렌식 조사, 추가 모니터링 및 예방 교육 강화
- ‌정기 검토: 절차와 징후 목록을 주기적으로 검토·업데이트
▶ ‌교육 시행에 대한 기록을 남기고 교육 효과와 적정성을 평가하여 다음 교육 계획에 반영해야 함
• ‌교육시행 후 교육 공지, 교육자료, 출석부 등과 같은 기록을 남기고, 미리 마련된 평가기준에 따라
설문 또는 테스트 등을 통하여 교육 내용의 적절성과 효과성 평가
• ‌교육평가 결과 내용에서 도출된 개선점에 대한 대책을 마련하고 차기 교육 계획 수립 시 반영

---
<!-- Page 156 -->
156 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ CMMC
• ‌AT.L2-3.2.1 역할 기반 위험 인식 : 조직 시스템의 관리자, 시스템 관리자 및 사용자에게 해당 활동과
관련된 보안 위험과 해당 시스템의 보안과 관련된 정책, 표준 및 절차를 알려야 한다.
• ‌AT.L2-3.2.2 역할 기반 교육 : 직원들이 할당된 정보 보안 관련 업무와 책임을 수행할 수 있도록 교육을
받도록 한다.
• ‌AT.L2-3.2.3 내부 위협 인식 : 내부 위협의 잠재적 지표를 인식하고 보고하는 방법에 대한 보안 인식
교육을 제공한다.
⊙ K-RMF
• ‌AT-1 보안인식 교육·훈련 : 다음에 해당되는 경우 시스템 사용자에게 보안인식 향상을 위한 교육을
시행해야 한다.

## 1. 시스템 신규사용자 등록 시


## 2. 시스템 변경 시

3. [재교육 주기] 도래 시
• ‌AT-1-2 보안인식 교육·훈련 | 내부자 위협 : 보안인식 향상을 위한 교육에 내부자 위협 징후를 식별하고
보고하는 내용을 포함해야 한다.
• ‌AT-2 직책 기반 보안 교육·훈련 : 다음에 해당되는 경우 업무 관련자에게 직무수행에 필요한 보안교육을
시행해야 한다.

## 1. 시스템에 대한 접근 권한을 승인받은 인원의 최초 직무수행 전


## 2. 시스템 변경 시

3. [재교육 주기] 도래 시
⊙ NIS2
• ‌8.1 사이버 인식 제고 : 관련 기관은 임직원 및 경영진, 직접 공급업체·서비스 제공업체가 보안 위험을
인지하고 사이버보안의 중요성을 이해하며 사이버 위생 관행을 준수하도록 하여야 한다.
• ‌8.2 보안 교육 훈련 : 관련 기관은 보안 관련 역량이 필요한 직무를 수행하는 직원들을 식별하고,
정기적으로 네트워크 및 정보시스템 보안 교육을 실시하여야 한다.
⊙ ISMS-P
• ‌2.2.4 인식제고 및 교육훈련 : 임직원 및 관련 협력업체 직원이 조직의 관리체계와 정책을 이해하고
직무별 전문성을 확보할 수 있도록 연간 인식제고 활동 및 교육훈련 계획을 수립·운영하고, 그 결과에 따른
효과성을 평가하여 다음 계획에 반영하여야 한다.

---
<!-- Page 157 -->

## 제3장 우주 보안모델 해설  | 157

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제8절
물리보안(PE)
PE-01
물리적 접근통제
항목 내용
시스템이 설치·운영되고 있는 시설의 출입을 통제하고 모니터링하며 물리적
접근 이력을 주기적으로 검토해야 한다.
목적
주요 우주 시스템 및 정보 자산이 위치한 시설에 대한 비인가 접근을 엄격히
통제하고 접근 활동의 책임성을 보장하여 물리적 보안 환경 및 자산 무결성을
확보하기 위함이다.
주요
확인사항
y ‌인가된 사용자만 시설 출입을 허용하고, 접근 기록을 유지하며 모니터링
시스템을 운영하는가?
y ‌시스템이 설치·운영되는 물리적 시설 및 인프라가 무단 접근·침입으로부터
보호되고 지속적으로 모니터링되는가?
y ‌방문객은 반드시 직원과 동행하며, 모든 접근 이력을 보존하고 방문객 활동을
모니터링하는가?
y ‌물리적 접근 통제 장치를 목록화하여 관리하고, 장치에 대한 접근을
제한하는가?
세부 설명
⊙ ‌인가된 사용자만 시설 출입을 허용하고, 접근 기록을 유지하며 모니터링 시스템을 운영해야 한다.
▶ ‌우주기업의 시스템·장치·운영 환경에 대한 물리적 접근은 반드시 승인된 인원에게만 허용해야
함
• ‌물리적·환경적 위협으로부터 주요 정보, 문서, 주요 설비 및 시스템 등을 보호하기 위하여
통제구역, 제한구역, 접견구역 등 물리적 보호구역 지정기준을 마련해야 함
• ‌우주기업의 주요 정보를 저장·처리·전송하는 시스템 및 장치가 위치한 곳을 통제구역으로
지정해야 함

---
<!-- Page 158 -->
158 | 우주 보안 모델 해설 및 적용사례집
물리적 보호구역(예시)
y ‌통제구역 : 출입자격이 최소인원으로 유지되며 출입을 위하여 직원 카드와 같은 출입증 이외의
추가 절차가 필요한 곳(예: 전산실, 장비실, 관제실, 연구실 등)
y ‌제한구역 : 비인가 접근을 방지하기 위하여 별도의 출입통제 장치 및 감시시스템이 설치된 장소로
출입 시 직원카드와 같은 출입증이 필요한 장소(예: 부서별 사무실 등)
y ‌접견구역 : 외부인이 별다른 출입증 없이 출입이 가능한 구역(예: 접견장소 등)
출처 : ISMS-P 인증기준 안내서(KISA)
- 통제구역은 통제구역임을 표시하여 비인가자의 출입 시도를 원천적으로 차단
• ‌보호 구역에는 물리적 접근 권한을 가진 인원만이 출입할 수 있도록 내·외부자 출입통제 절차를
마련하고, 출입 가능한 인원 현황을 관리
- ‌출입절차 : 출입신청, 책임자 승인, 출입권한 부여 및 회수, 출입내역 기록, 출입기록 정기적
검토 등
- ‌출입통제 장치 설치 : 비밀번호 기반, ID카드 기반, 생체정보 기반 등
- ‌출입통제 절차 수립·운영 : 출입자 등록·삭제, 출입권한 관리, 방문자 관리, 출입대장 관리
▶ ‌물리적 접근 기록은 모든 접근 행위에 대해 작성·유지되어야 함
• ‌수기 기록 방식: 직원·방문객의 출입 및 퇴실 서명을 통해 기록해야 함
• ‌자동 기록 방식: 배지·카드 리더기 및 스마트카드 시스템 등을 활용해야 함
• ‌혼합 기록 방식: 수기 기록과 자동 기록을 병행하여 운영할 수 있음
• ‌로그는 모든 물리적 접근 지점을 포함해야 함
- ‌건물 출입구 기록
- ‌내부 통제구역(서버실, 장비실 등)의 접근 기록
- ‌시스템이 위치한 물리 영역에 대한 접근 기록
▶ ‌물리적 접근 로그를 정기적으로 검토·관리하고 감사 목적을 위해 활용되어야 함
• ‌로그 관리 상태를 주기적으로 점검하고, 감사 증빙으로 활용 가능하도록 유지
- ‌로그가 최신 상태로 유지
- ‌방문객 기록이 누락 없이 관리되는지 검증
- ‌감사 요구 시 제출 가능한 형태로 보관
- ‌보안 사고 대응 시 출입 기록을 기반으로 사실 조사

---
<!-- Page 159 -->

## 제3장 우주 보안모델 해설  | 159

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌시스템이 설치·운영되는 물리적 시설 및 인프라가 무단 접근·침입으로부터 보호되고 지속적으로
모니터링해야 한다.
▶ ‌물리적 시설은 승인되지 않은 접근·손상·침입으로부터 보호되고, 지속적인 감시 체계를
기반으로 안전하게 관리되어야 함
• ‌주요 물리적 진입 지점(출입구·창문·비상문 등)에는 잠금 장치를 설치하고 인가되지 않은 접근을
차단해야 함
• ‌보안 카메라(CCTV), 침입 탐지 센서, 알람, 경비 인력 등을 활용하여 시설 상태를 지속적으로
감시해야 함
• ‌출입 기록과 모니터링 로그를 정기적으로 검토하고 기록을 안전하게 저장해야 함
▶ ‌전력·네트워크·통신 라인을 포함한 지원 인프라는 서비스 중단·변조·도청·무단 접근을 예방하기
위해 보호 및 상시 모니터링 체계를 적용하여 운영되어야 함
• ‌전력선, 네트워크 케이블, 통신 라인 등 주요 인프라 구간은 외부 접근으로부터 보호되어야 하며,
케이블은 덕트·트레이 등 물리적 보호 장치를 적용해야 함
• ‌배선실은 잠금 장치로 보호하고 사용하지 않는 포트·잭·패널은 반드시 차단하여 악의적 연결을
방지해야 함
• ‌전력 및 네트워크 인프라의 변조·절단·도청 시도를 탐지할 수 있도록 센서 및 알람 시스템을
활용해야 함
• ‌지원 인프라에 대한 접근 이력 및 상태 모니터링 결과를 기록하고 이상 발생 시 즉시 대응해야 함
⊙ ‌방문객은 반드시 직원과 동행하며, 모든 접근 이력을 보존하고 방문객 활동을 모니터링해야 한다.
▶ ‌방문객은 시설 내에서 혼자 이동할 수 없으며, 항상 직원이 동행해야 하며, 동행하지 않은
방문객은 제지해야 함
▶ ‌방문객 식별 및 출입 통제 절차를 운영해야 함
• ‌방문객은 반드시 식별 가능한 출입증을 착용해야 함
▶ ‌방문객 출입 기록을 반드시 작성해야 하며, 안내 데스크에서 출입·퇴실을 기록해야 함
▶ ‌무단 방문객이나 규정 위반 발생 시 즉시 물리적 보안 관련 부서에 보고하고, 사건 발생 후 개선
조치를 수행하여 재발을 방지해야 함
⊙ ‌물리적 접근 통제 장치를 목록화하여 관리하고, 장치에 대한 접근을 제한한다.
▶ ‌모든 물리적 접근 장치를 목록화하여 최신 상태로 유지해야 함
• ‌열쇠, 자물쇠, 카드리더기, 출입증 등 포함해야 하며, 장치별 일련번호나 고유 식별 정보를
기록해야 함

---
<!-- Page 160 -->
160 | 우주 보안 모델 해설 및 적용사례집
• ‌신규 장치 발급 시, 지체없이 목록에 반영하며 퇴직·이직 시에도 회수 내역을 반영해야 함
▶ ‌물리적 접근 장치는 잠금 장치가 있는 장소에 보관하며, 장치 분실·도난 시 즉시 보고 및
대응해야 함
▶ ‌물리적 접근 장치는 정기적으로 유지·보수해야 함
• ‌자물쇠 교체, 카드 시스템 업데이트
• ‌장치 이상 발생 시 즉시 교체·수리
관련 기준
⊙ CMMC
• ‌PE.L2-3.10.1 물리적 접근 제한[CUI 데이터] : 조직 시스템, 장치 및 해당 운영 환경에 대한 물리적
접근을 승인된 개인으로 제한한다.
• ‌PE.L2-3.10.2 시설 모니터링 : 조직 시스템의 물리적 시설과 지원 인프라를 보호하고 모니터링한다.
• ‌PE.L2-3.10.3 방문객 안내 [CUI 데이터] : 방문객을 안내하고 방문객 활동을 모니터링한다.
• ‌PE.L2-3.10.4 물리적 접근 로그[CUI 데이터] : 물리적 접근에 대한 감사 기록을 유지 관리한다.
• ‌PE.L2-3.10.5 물리적 접근 관리[CUI 데이터] : 물리적 접근 장치를 제어하고 관리한다.
⊙ K-RMF
• ‌PE-1-3 물리적 접근인가 | 안내자 동행 없이 출입 가능한 인원 : 다음 중 하나라도 해당하지 않은 인원은
시스템이 설치·운영되고 있는 시설에서 인솔 없이 출입할 수 없도록 해야 한다.

## 1. 시스템에서 처리되는 모든 정보에 대한 비밀 취급 인가를 보유한 인원


## 2. 시스템에서 처리되는 모든 정보에 대한 접근 권한을 보유한 인원


## 3. 시스템에서 처리되는 모든 정보에 대한 접근 필요성이 인정되는 인원

4. [조직이 지정한 자격 증명]을 보유한 인원
• ‌PE-2 물리적 접근통제 :
1. ‌[조직이 지정한 시스템이 설치·운영되고 있는 시설의 출입구]에 다음 각 호의 방식으로 출입을 통제해야
한다.

가. 시설 출입 전 접근인가를 확인해야 한다. 한다.

나. ‌[조직이 지정한 물리적 접근통제 시스템/장치 그리고/또는 경계근무자]을 통해 출입을 통제해야
한다.
2. ‌[조직이 지정한 시스템이 설치·운영되고 있는 시설의 출입구]에 대한 물리적 접근에 관한 이력을
유지해야 한다.

## 3. 공개적으로 허가된 시설일 경우 [조직이 지정한 보안 보호조치]를 통해 출입을 허용할 수 있다.

4. ‌[조직이 지정한 방문자 인솔 및 모니터링이 요구되는 상황]에는 방문자를 인솔하고 활동을 모니터링해야
한다.

## 5. 시설 출입과 관련된 자재(예 : 열쇠, 패스워드 등)들을 안전하게 보호해야 한다.

6. ‌시설의 [조직이 지정한 물리적 접근통제 장치] 목록을 [조직이 지정한 주기]마다 검토하고 최신화해야
한다.

---
<!-- Page 161 -->

## 제3장 우주 보안모델 해설  | 161

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
7. ‌열쇠 분실, 패스워드 노출, 업무관련자 전출 및 퇴직, [조직이 지정한 주기] 도래 등이 발생되면 열쇠 또는
패스워드를 변경해야 한다.
• PE-3 물리적 접근 모니터링 :
1. ‌시스템이 설치·운영되고 있는 시설에서 발생할 수 있는 물리적 보안사고를 식별하고, 대응하기 위해
시설에 대한 물리적 접근을 모니터링해야 한다.

## 2. 물리적 접근 이력을 [조직이 지정한 주기 또는 사고 발생 시] 검토, 확인해야 한다.


## 3. 검토 및 조사결과를 조직의 사고대응 역량과 통합하여 대응하여야 한다.

⊙ ISMS-P
• ‌2.4.2 출입통제 : 보호구역은 인가된 사람만이 출입하도록 통제하고 책임추적성을 확보할 수 있도록 출입
및 접근 이력을 주기적으로 검토하여야 한다.
• ‌ 2.4.3 정보시스템 보호 : 정보시스템은 환경적 위협과 유해요소, 비인가 접근 가능성을 감소시킬 수 있도록
중요도와 특성을 고려하여 배치하고, 통신 및 전력 케이블이 손상을 입지 않도록 보호하여야 한다.
• ‌2.4.4 보호설비 운영 : 보호구역에 위치한 정보시스템의 중요도 및 특성에 따라 온도·습도 조절, 화재감지,
소화설비, 누수감지, UPS, 비상발전기, 이중전원선 등의 보호설비를 갖추고 운영절차를 수립·운영하여야
한다.
• ‌2.4.5 보호구역 내 작업 : 보호구역 내에서의 비인가행위 및 권한 오·남용 등을 방지하기 위한 작업 절차를
수립·이행하고, 작업 기록을 주기적으로 검토하여야 한다.

---
<!-- Page 162 -->
162 | 우주 보안 모델 해설 및 적용사례집
PE-02
대체 근무장소 보안
항목 내용
대체 근무장소(재택, 출장지, 원격 사무실 등)에서 중요 정보에 대한 안전조치를
시행한다.
목적
대체 근무 환경에서도 중요 정보의 기밀성을 유지하고, 원격 접속으로 인한 보안
위험을 최소화하기 위함이다.
주요
확인사항
y ‌대체 근무 환경에서 사용되는 보안 통제 기준을 정의하고, 근무 환경의 특성에
따라 통제를 구분하여 운영하는가?
y ‌대체 근무 환경에서 사용되는 업무용 단말에 보안 통제를 적용하는가?
y ‌대체 근무 환경에서 내부 시스템에 접근하는 경우, 안전한 원격 접속 방식을
사용하는가?
세부 설명
⊙ ‌대체 근무 환경에서 사용되는 보안 통제 기준을 정의하고, 근무 환경의 특성에 따라 통제를 구분하여
운영해야 한다.
▶ ‌대체 근무 환경은 업무 수행 위치 및 관리 수준에 따라 구분해야 함
• ‌재택 근무: 임직원의 개인 주거지에서 기관 지급 단말을 사용하여 업무를 수행하는 환경
• ‌출장지·공공장소: 호텔, 공항 등 불특정 다수가 이용하는 외부 환경
• ‌원격 사무실: 회사가 지정하거나 계약을 통해 관리하는 외부 업무 공간
▶ ‌모든 대체 근무 환경(재택, 출장지, 원격사무실)에 공통 적용되는 기본 보안 통제를 정의해야 함
• ‌사용자 인증 및 접근 통제
• ‌단말 보안 및 데이터 보호
• ‌원격 접속 및 통신 보호
• ‌보안 로그 및 접속 이력 관리
▶ ‌근무 환경별로 물리적 통제 가능 수준과 네트워크 위험 수준을 고려하여 보안 요구사항을 다르게
적용
▶ ‌대체 근무 환경별 보안 통제 기준은 원격근무 보안 지침 또는 정보보호 정책에 문서화하여
관리해야 함
⊙ ‌대체 근무 환경에서 사용되는 업무용 단말에 보안 통제를 적용해야 한다.
▶ ‌단말 유형에 따른 보안 통제 기준을 구분
• ‌기관 지급 단말(업무용 노트북·모바일)

---
<!-- Page 163 -->

## 제3장 우주 보안모델 해설  | 163

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
- ‌운영체제(OS) 및 주요 소프트웨어에 대해 자동 업데이트 및 최신 보안 패치를 강제해야 함
- 내부 정보는 DRM을 이용해서 암호화해야 함
- 관리자 권한은 보안·IT 담당자에 한해 제한적으로 부여해야 함
- 보안 설정 변경 이력 및 단말 상태를 중앙에서 관리·점검해야 함
• ‌개인 소유 단말(BYOD, Bring Your Own Device)
- ‌중요 정보의 로컬 저장을 제한하고, 웹 기반 업무 시스템 또는 가상 환경(VDI 등)으로 접근을
제한해야 함
- ‌내부 핵심 시스템에 대한 직접 접근은 허용하지 않거나, 접근 범위를 최소화해야 함
- ‌조직이 허용한 최소 보안 요건(OS 버전, 패치 수준, 암호화 여부 등)을 충족하지 못할 경우
업무 접근을 제한해야 함
• ‌외부 단말
- ‌원칙적으로 내부 시스템 접근을 금지하거나, 단기·한시적 접근만 허용해야 함
- ‌접근이 필요한 경우 별도의 외부 전용 구간 또는 제한된 계정으로만 접속하도록 구성해야 함
▶ ‌주요 업무(예: 위성 운용, 고객 제공 정보 등)의 경우, 기관 지급 단말에서만 접근을 허용해야
하며 원격 접속 시 다중 인증(MFA)을 필수 적용
⊙ ‌대체 근무 환경에서 내부 시스템에 접근하는 경우, 안전한 원격 접속 방식을 사용해야 한다.
▶ ‌원격 접속은 조직이 승인한 공식 접속 경로로만 허용
• ‌내부 시스템 접근은 VPN, VDI 등 중앙 통제 가능한 방식만 허용
▶ ‌승인되지 않은 원격 접속 시도를 탐지·차단할 수 있도록 비인가 IP, 비정상 접속 시도에 대한
차단 규칙을 설정해야 함
▶ ‌원격에서 내부 시스템 접속 시에는 다중 인증을 필수 적용
▶ ‌출장지·공공장소 등 신뢰할 수 없는 네트워크 환경에서 내부 시스템에 접속하는 경우, VDI를
이용하는 등 안전한 원격 접속 수단을 사용
▶ ‌원격 단말이 내부망과 외부망 사이의 우회 경로(브릿지)가 되는 것을 방지하기 위해, 원격 접속
시 내부망과 외부 인터넷이 동시에 연결되지 않도록 구성

---
<!-- Page 164 -->
164 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ CMMC
• ‌PE.L2-3.10.6 대체 작업 현장 : 대체 작업 현장에서 CUI에 대한 안전 조치를 시행한다.
⊙ K-RMF
• ‌PE-15 대체 근무장소 :

## 1. 대체 근무장소 에 대하여 [조직이 지정한 보안통제항목]을 적용해야 한다.


## 2. 대체 근무장소 에 대한 보안통제항목 평가는 실질적이고 실현 가능하게 해야 한다.

3. ‌보안사고 또는 문제가 발생하였을 때, [조직이 지정한 인원 또는 직책]과 통신할 수 있는 수단을 제공해야
한다.

---
<!-- Page 165 -->

## 제3장 우주 보안모델 해설  | 165

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
PE-03
보호설비 운영
항목 내용
보호구역에 위치한 정보시스템의 중요도 및 특성에 따라 온도·습도 조절,
화재감지, 소화설비, 누수감지, UPS, 비상발전기, 이중전원선 등의 보호설비를
갖추고 운영절차를 수립·운영하여야 한다.
목적
보호구역 내 중요 우주 시스템 및 인프라의 물리적 안전성과 가용성을 보장하기
위해 환경적 위협 및 재난에 대비한 보호설비를 구축하고 체계적으로 운영하기
위함이다.
주요
확인사항
y ‌보호설비(이중전원선, UPS, 비상발전기 등)의 운영 및 유지보수에 필요한 점검
기준과 절차를 수립하여 주기적으로 점검하는가?
y ‌시스템 운영에 필요한 환경적 요구사항(온도, 습도, 화재, 누수 등)의 통제
기준을 정의하고, 이를 유지하기 위한 감지·경보 시스템을 운영하는가?
세부 설명
⊙ ‌보호설비(이중전원선, UPS, 비상발전기 등)의 운영 및 유지보수에 필요한 점검 기준과 절차를
수립하여 주기적으로 점검한다.
▶ ‌보호구역에 위치한 정보시스템의 중요도 및 특성에 따라 온·습도 조절, 화재감지, 소화설비,
누수감지, 무정전 전원공급장치(UPS), 비상발전기, 이중전원선 등의 보호설비를 갖추고
운영절차를 수립·운영해야 함
▶ ‌외부 집적 정보통신시설에 위탁 운영하는 경우, 물리적 보호에 필요한 요구사항을 계약서에
명시하고 운영 상태를 주기적으로 검토해야 함
• ‌정보보호 관련 법규 준수, 화재, 전력 이상 등 재해·재난 대비, 출입통제, 자산 반출입 통제,
영상감시 등 물리적 보안통제 적용 및 사고 발생 시 손해 배상에 관한 사항 등
• ‌집적정보통신시설의 책임보험 가입 여부(미가입 시 2천만원 이하의 과태료 부과)
▶ ‌시스템의 전원 장치 및 전원 케이블이 손상 및 파괴되지 않도록 보호해야 함
• ‌물리적으로 조직이 지정한 거리만큼 떨어진 곳에 배치하고 이중화된 전원 케이블을 설치해야 함
• ‌중요 시스템 구성요소에 자동 전압제어 기능을 사용해야 함
▶ ‌상시전원의 정지 또는 장애 발생 시 시스템을 안전하게 정지하거나 전력 전환이 완료될 때까지
단기간 전력을 공급할 수 있도록 무정전 전원공급장치(UPS)를 설치·운용
• ‌상시전원 장기 중단에 대비하여, 조직의 운영 환경에 적합한 방식으로 시스템의 최소 운영능력을
유지할 수 있는 비상 전원 수단을 확보
- 임대 시설의 비상 전원 체계, 비상발전기, 외부 데이터센터(IDC)의 전원 이중화 설비 등

---
<!-- Page 166 -->
166 | 우주 보안 모델 해설 및 적용사례집
• ‌비상 전원 설비를 직접 운용하는 경우, 조직이 지정한 주기에 따라 점검을 수행하고 식별된
결함은 기간 내 시정 조치
⊙ ‌시스템 운영에 필요한 환경적 요구사항(온도, 습도, 화재, 누수 등)의 통제 기준을 정의하고, 이를
유지하기 위한 감지·경보 시스템을 운영한다.
▶ ‌시스템이 설치·운영되고 있는 시설의 온도와 습도를 조직이 지정한 수준으로 유지하고, 지정한
주기마다 모니터링해야 함
• ‌시설의 온도와 습도는 시스템별 운용환경 요구사항에 맞춰 조정
- ‌예: 서버 10~32℃, 20~80%, 저장장치 16~32℃, 20~80%, 네트워크장비 5~40℃,
10~85% 등
▶ ‌시스템 주장비가 설치, 운영되는 시설 또는 장소에 자동 온·습도 조절 장치와 부적합한 온도 및
습도 변화를 감지 및 경보하는 장치를 설치해야 함
▶ ‌독립적인 에너지원을 공급받는 화재 진압 및 감지 시스템을 시설 내에 설치하고 운영해야 함
• ‌정전 또는 비상 탈출에 대비하여 시설 내 비상구 및 대피경로 등에 비상조명을 설치 및 운영해야
함
• ‌시스템 필수 기능을 유지하는데 필요한 시설 내 모든 구역에 비상조명을 설치하고 운영해야 함
▶ ‌화재발생 시 긴급 대응을 위해 화재 감지 시스템과 화재 진압시스템을 구축하여 운영해야 함
• ‌시설에 상시 근무자가 없을 경우 자동 화재 진압시스템을 설치 및 운용해야 함
▶ ‌누수로 인한 시스템 손상 방지를 위해 시스템에 설치된 시설에 급수 일괄차단 또는 분리 차단
밸브를 제공해야 함
▶ ‌시스템 주변에 습기(물)이 감지되면 자동으로 지정된 직책(지휘통제실 당직자 등)에게 경보해야
함
관련 기준
⊙ K-RMF
• ‌PE-7 전력 장비 및 케이블 : 시스템의 전원 장비 및 전원 케이블이 손상 및 파괴되지 않게 보호해야 한다.
• ‌PE-10 비상 전원 : 상시전원의 정지/장애 발생 시, 시스템을 안전하게 정지하거나 비상발전기로 전환하는
동안 단기간 전력을 공급할 수 있는 무정전 전원공급장치(UPS)를 설치, 운용해야 한다.
• ‌PE-11 비상조명 : 정전 또는 비상 탈출에 대비하여 시설 내 비상구 및 대피경로 등에 비상조명을 설치 및
운영해야 한다.
• ‌PE-12 화재 예방 : 독립적인 에너지원을 공급받는 화재 진압 및 감지 시스템을 시설 내 설치, 운영해야
한다.
• ‌PE-13 온도/습도 통제 :

---
<!-- Page 167 -->

## 제3장 우주 보안모델 해설  | 167

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례

## 1. 시스템이 설치·운영되고 있는 시설의 온도와 습도를 [조직이 지정한 수준]으로 유지해야 한다.


## 2. 시설의 온도와 습도를 [조직이 지정한 주기]마다 모니터링 해야 한다

⊙ ‌ISMS-P
• ‌2.4.4 보호설비 운영 : 보호구역에 위치한 정보시스템의 중요도 및 특성에 따라 온도·습도 조절, 화재감지,
소화설비, 누수감지, UPS, 비상발전기, 이중전원선 등의 보호설비를 갖추고 운영절차를 수립·운영하여야
한다.

---
<!-- Page 168 -->
168 | 우주 보안 모델 해설 및 적용사례집
제9절
위험평가 및 보안 평가(RA)
RA-01
위험 평가
항목 내용
시스템 운영 및 정보의 처리·저장·전송으로 인해 발생하는 조직 운영(임무, 기능,
이미지, 평판 포함), 자산, 개인에 대한 위험을 주기적으로 평가해야 한다.
목적
중요 우주 시스템 운영 및 정보 처리로 인해 발생하는 조직의 임무, 자산, 평판
등에 대한 위험을 식별 및 평가하고 관리하여 보안 대응 역량을 확보하기
위함이다.
주요
확인사항
y ‌우주기업은 위험관리체계를 마련하여 위험관리 방안을 수립하고 있는가?
y ‌우주기업은 조직운영·자산·개인에 대한 위험을 주기적으로 평가·처리하고
있는가?
세부 설명
⊙ ‌우주기업은 위험관리체계를 마련하여 위험관리 방안을 수립한다.
▶ ‌위험관리 방안 및 절차(수행 인력, 기간, 대상, 방법, 예산 등)를 구체화한 위험관리 계획을
수립해야 함
• ‌수행인력 : 위험관리 전문가, 정보보호 전문가, 법률 전문가, IT 실무 책임자, 현업부서
• ‌실무 책임자, 외부 전문컨설턴트 등 참여(이해관계자의 참여 필요)
• ‌기간 : 최소 연 1회 이상 수행될 수 있도록 일정 수립
• ‌대상 : 우주기업의 모든 서비스 및 자산(우주, 지상, 사용자 부문) 포함
• ‌방법 : 조직의 특성을 반영한 위험평가 방법론 정의
• ‌예산 : 위험 식별 및 평가 시행을 위한 예산 계획을 매년 수립하고 정보보호 최고책임자 등 경영진
승인
▶ ‌우주기업의 특성을 반영하여 관리적, 기술적, 물리적, 법적 분야 등 다양한 측면에서 발생할 수
있는 위험을 식별하고 평가하는 절차를 수립
• ‌위험평가 방법 선정 : 베이스라인 접근법, 상세위험 분석법, 복합 접근법, 위협 및 시나리오 기반 등
•
‌
비즈니스 및 조직의 특성 반영 : 조직의 비전 및 미션, 비즈니스 목표, 서비스 유형, 컴플라이언스 등
• ‌다양한 관점 고려 : 해킹, 내부자 유출, 협력업체 직원 관리·감독 소홀, 개인정보 관련 법규 위반 등
• ‌최신 취약점 및 위협동향 고려

---
<!-- Page 169 -->

## 제3장 우주 보안모델 해설  | 169

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌우주기업은 조직운영·자산·개인에 대한 위험을 주기적으로 평가하고 처리한다.
▶ ‌시스템 운영 및 정보 처리로 인해 발생하는 조직 운영, 자산 및 개인에 대한 위험을 정기적으로
평가해야 함
• ‌평가 요소 및 범위: 위험 평가 시 위협, 취약점, 발생 가능성, 영향도를 고려하여 평가해야 함
- ‌자산의 취약점과 시스템에 대한 내부 및 외부 위협을 식별하고 문서화하며, 잠재적인 사업적
영향 및 발생 가능성을 식별해야 함
• ‌시스템의 취약점 변경, 위협 실현 가능성 변경, 시스템 의존도 증가 등 실질적인 변경이
발생하거나 중대한 사고 발생 시 위험을 재평가해야 함
▶ ‌위험평가 결과를 바탕으로 위험 조치 계획을 수립, 이행하고 그 효과를 관리해야 함
• ‌식별된 위협, 취약점, 발생 가능성 및 영향을 사용하여 위험을 결정하고, 그 결과를 경영진에게
보고해야 함
• ‌수용 가능한 목표 위험 수준을 정하고, 그 수준을 초과하는 위험을 식별 및 문서화해야 함
- ‌각종 위험이 조직에 미치는 영향(발생가능성, 심각도 등)을 고려하여 위험도 산정기준 마련
- ‌위험도 산정기준에 따라 식별된 위험에 대하여 위험도 산정
- ‌수용 가능한 목표 위험수준(DoA, Degree of Assurance)을 정보보호 최고책임자, 개인정보
보호책임자 등 경영진의 의사결정에 의하여 결정
- ‌수용 가능한 목표 위험수준을 초과하는 위험을 식별하고 문서화
• ‌위험 조치 계획 수립 및 승인: 식별된 위험에 대한 관리 전략(감소, 회피, 전가, 수용 등)을
수립하고, 위험 조치를 위한 적절한 보호대책을 선정해야 함
위험 관리 전략
위험 관리 예시
위험 감소
지상국 시스템에 대한 비인가 명령 위험을 줄이기 위하여, 위성 명령 전송 및 핵심
접근 통제 지점(MOC/PCC)에 다중 인증(MFA)을 강제하고 접근 권한을 직무별로
세분화하여 적용
위험 회피
지상국 시스템의 인터넷 직접 노출에 따른 해킹 위험이 통제 불가능하다고
판단하여, 관제망과 외부망을 물리적으로 분리하고, 외부망 연결이 필요한 경우에
한해 망간 자료 전송 시스템을 통한 일방향 통신만을 허용하도록 시스템 설계
위험 전가
사이버 공격으로 인한 위성 운용 중단 또는 중대한 탑재체 데이터 유출 시 발생하는
임무 손실 및 복구 비용에 대한 재정적 위험을 줄이기 위하여 사이버 보험에
가입하거나, 협력업체와의 계약 시 사고 발생에 따른 손해배상 책임을 명확히 전가
위험 수용
노후화된 지상국 시스템 장치의 교체 비용이 과도하여 당장 해결이 불가하거나,
통제가 불가능한 외부 협력사의 공통 인프라 사용이 불가피한 경우, 측정된 잔여
위험을 경영진에게 보고하고 공식적인 수용 승인을 받아 운영(단, 수용 이후에도
지속적인 모니터링을 조건으로 함)

---
<!-- Page 170 -->
170 | 우주 보안 모델 해설 및 적용사례집
• ‌위험 조치 계획에 따라 보호대책의 우선순위, 일정, 담당자, 예산 등을 포함한 이행 계획을
수립하고 경영진의 승인을 받아야 함
- ‌위험의 심각성 및 시급성, 구현의 용이성, 예산 할당, 자원의 가용성, 선후행 관계 등을
고려하여 우선순위 결정
- ‌일정, 담당부서 및 담당자, 예산 등의 항목을 포함한 보호대책 이행계획을 수립하여 경영진에게
보고 및 승인
▶ ‌선택된 위험 조치의 책임자와 이행 시점을 명확히 지정하고 문서화해야 함
• ‌책임자 지정: 위험 조치를 수행할 담당자를 명확히 지정하고 지정된 책임자는 역할과 권한을
문서화해야 함
• ‌이행 시점 정의: 위험 조치가 언제 실행되어야 하는지 구체적으로 명시해야 함
- ‌긴급 상황, 정기 점검, 운영 변경 등 상황별 이행 시점을 구분하여 정의해야 함
▶ ‌위험 조치 내역을 기록하고 잔여 위험 수용 사유를 문서화해야 함
• ‌위험 조치 기록: 선택된 조치의 내용과 범위를 문서화하고, 조치가 적용된 자산과 시스템을
명확히 표시해야 함
• ‌잔여 위험을 수용하는 이유(비용·효과성·기술적 한계 등 수용에 대한 객관적 근거 포함)를 명확히
기술해야 함
• ‌문서의 검토 가능성 확보: 문서화된 내용은 경영진과 감사자가 쉽게 이해할 수 있도록 작성해야
함
- ‌후속 점검 및 개선 활동에 활용할 수 있도록 체계적으로 보관하고 관리해야 함
▶ ‌위험을 조치하거나 잔여 위험을 수용할 때, 관련 기관은 주요 고려사항을 반드시 반영해야 함
• ‌효과성 및 비용 고려: 기대되는 효과 대비 구현 비용을 반드시 고려해야 하며, 비용 대비 효과가
낮은 경우 대체 방안을 검토해야 함
• ‌기존 보안 조치 효과성 검토: 사이버보안 위험 조치의 효과성 평가 결과를 반드시 고려하여, 기존
보안조치의 효과성을 검토하고 개선 필요 여부를 반영해야 함
• ‌사업 및 자산 중요도 반영: 자산 중요도와 사업 영향 분석 결과를 반드시 고려해야 함
- ‌자산의 중요도와 분류 수준에 따라 조치 강도를 결정하고, 핵심 기능에 영향을 주는 위험은
우선적으로 처리해야 함
▶ ‌위험 평가 결과와 위험 조치 계획은 정기적으로 검토·갱신하여 최신 상태를 유지해야 함
• ‌최소한 매년 1회 이상 검토해야 하며, 정기적인 위험 평가를 통해 계획의 최신 상태를 유지하고
연간 보고서에 반영해야 함
• ‌운영·위험·사고에 중대한 변화가 발생할 경우 즉시 갱신해야 함

---
<!-- Page 171 -->

## 제3장 우주 보안모델 해설  | 171

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
- ‌새로운 위협이나 취약점 발견 시 즉시 반영해야 함
- ‌사고 발생 후 후속 조치와 교훈을 계획에 포함해야 함
• ‌검토·갱신 결과와 변경 내역을 기록하고 관리하며, 경영진과 감사자가 확인할 수 있도록
보고해야 함
관련 기준
⊙ CMMC
• ‌RA.L2-3.11.1 위험 평가 : 조직 시스템 운영 및 관련 CUI 처리, 저장 또는 전송으로 인해 발생하는 조직
운영(임무, 기능, 이미지 또는 평판 포함), 조직 자산 및 개인에 대한 위험을 주기적으로 평가한다.
• ‌CA.L2-3.12.1 보안 통제 평가 : 조직 시스템의 보안 통제를 주기적으로 평가하여 통제가 효과적으로
적용되는지 확인한다.
⊙ K-RMF
• ‌PA-8-1 보안 시험 및 평가 | 위협 모델링 및 취약점 분석 : 개발 중에 위협 모델링 및 취약점 분석을
수행하고, 이후 다음 정보를 이용(포함)하여 보안 시험평가를 수행해야 한다.
1. [보안 영향성과 관련된 정보, 운영환경, 알려지거나 가정된 위협, 허용 가능한 위험수준]
2. [조직이 지정한 도구 및 방법]
3. [조직이 지정한 분석 수준과 범위]
4. [조직이 지정한 허용 기준] 충족 여부를 판단할 수 있는 관련 문서
⊙ NIS2
• ‌2.1 위험관리 프레임워크 : 관련 기관은 네트워크·정보시스템 보안 위험을 관리하기 위해 위험관리체계를
수립·유지하고, 위험평가 및 처리계획을 문서화·시행하며 경영진이 승인하도록 하여야 한다.
⊙ ISMS-P
• ‌1.2.3 위험 평가 : 조직의 대내외 환경분석을 통해 유형별 위협정보를 수집하고 조직에 적합한 위험 평가
방법을 선정하여 관리체계 전 영역에 대하여 연 1회 이상 위험을 평가하며, 수용할 수 있는 위험은 경영진의
승인을 받아 관리하여야 한다.
• ‌1.4.2 관리체계 점검 : 관리체계가 내부 정책 및 법적 요구사항에 따라 효과적으로 운영되고 있는지
독립성과 전문성이 확보된 인력을 구성하여 연 1회 이상 점검하고, 발견된 문제점을 경영진에게 보고하여야
한다.

---
<!-- Page 172 -->
172 | 우주 보안 모델 해설 및 적용사례집
RA-02
보안통제 모니터링 및 효과성 평가
항목 내용
지속적으로 보안통제를 모니터링하여 보안통제의 지속적 효과를 보장해야 한다.
목적
보안통제의 지속적인 효과성을 보장하기 위해 보안 통제를 모니터링하고
주기적으로 평가하여 조직의 전반적인 보안 수준을 유지하기 위함이다.
주요
확인사항
y ‌보안통제의 효과성을 평가하기 위한 체계(절차, 책임, 기준 등)를
수립·정의하고 있는가?
y ‌보안통제의 효과성을 평가하고 통제를 주기적으로 검토·갱신하고 있는가?
세부 설명
⊙ ‌보안통제의 효과성을 평가하기 위한 체계(절차, 책임, 기준 등)를 수립하고 정의해야 한다.
▶ ‌우주기업의 보안통제가 계획대로 이행되고 유지되는지를 평가하기 위한 공식적인 정책 및
절차를 수립하고 유지해야 함
▶ ‌다음 사항을 포함하여 효과성 평가 체계를 명확히 정의해야 함
• ‌평가 대상이 되는 주요 보안통제 및 위험관리 조치
• ‌효과성 판단을 위한 평가 기준
• ‌평가 방법론 및 수행 방식
• ‌평가 주기 및 수시 평가 수행 조건
• ‌평가 수행 및 결과 관리에 대한 책임과 역할
▶ ‌효과성 평가 결과를 객관적으로 판단하기 위해 관리체계 관점의 핵심성과지표(KPI,
보안성과지표)를 도출하고 활용해야 함
재발방지 및 개선조치 관련 보안성과지표(예시)
y ‌보안 정책·지침 위반율(외부 전송규정 위반율, 보안우회 시도율 등)
y ‌보안 예외 승인 건수
y ‌보안 프로그램 설치율
y ‌악성프로그램 감염률
y ‌자가점검 수행률 등
출처 : ISMS-P 인증기준 안내서(KISA)
▶ ‌효과성을 모니터링하고 측정할 책임자를 명확히 지정해야 함

---
<!-- Page 173 -->

## 제3장 우주 보안모델 해설  | 173

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌보안통제의 효과성을 평가하고 통제를 주기적으로 검토·갱신해야 한다.
▶ ‌보안통제의 효과성은 주기적으로(연 1회 이상) 평가해야 함
• ‌다음과 같은 경우에는 정기 평가와 별도로 보안통제를 검토·재평가
- 새로운 위협 또는 취약점이 식별된 경우
- 시스템 구성, 운영 환경, 업무 범위에 중대한 변경이 발생한 경우
- 중요 보안 사고 또는 통제 실패가 발생한 경우
▶ ‌효과성 평가 및 검토 결과를 바탕으로 식별된 취약점에 대해 재발방지 및 개선조치를
수립·이행해야 함
• ‌점검 결과 발견된 문제점에 대해서는 조치계획을 수립·이행하고, 조치 완료 여부에 대하여 추가
확인
• ‌식별된 관리체계상의 문제점 및 결함사항에 대한 근본 원인 분석
• ‌근본원인 분석결과를 바탕으로 발견된 문제점의 재발방지 및 개선을 위한 대책의 수립·이행
재발방지 대책(예시)
y ‌정보보호 정책·지침·절차 개정
y ‌임직원 및 협력업체 직원에 대한 교육 강화 또는 개선
y ‌이상행위 등에 대한 모니터링 강화
y ‌정보보호 관련 검토·승인 절차 개선
y ‌내부점검 체크리스트 또는 방식 개선 등
출처 : ISMS-P 인증기준 안내서(KISA)
• ‌수립된 재발방지 대책에 대하여 관련자들에게 공유 및 교육 실시
• ‌보안통제의 효과성 평가 결과 및 개선 계획은 경영진에게 보고되어야 하며, 이는 경영진이 허용
가능한 위험을 결정하는데 활용
▶ ‌개선 활동의 이력 및 결과를 문서화하고 관리해야 함
• ‌검토 및 갱신 활동의 결과로 변경된 모든 정책, 절차, 시스템 보안 계획 등 관련 문서를 최신
상태로 유지해야 함
• ‌통제 검토 및 갱신에 대한 변경 내역을 기록하고 관리하며, 이를 감사자가 확인할 수 있도록
체계적으로 보관해야 함

---
<!-- Page 174 -->
174 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ CMMC
• ‌CA.L2-3.12.3 보안 통제 모니터링 : 지속적으로 보안 통제를 모니터링하여 통제의 지속적인 효과를
보장한다.
⊙ NIS2
‌7.1 보안조치 효과성 평가 정책 : 관련 기관은 사이버보안 위험관리 조치의 이행·유지 여부를 평가하기
위한 정책과 절차를 수립·시행하여야 한다.
‌7.2 보안조치 효과성 평가 절차 : 관련 기관은 위험평가 결과와 과거 주요 사고를 반영하여 정책·절차를
수립하고 필요한 사항을 결정하여야 한다.
‌7.3 보안조치 효과성 평가 결과 검토 : 관련 기관은 정책·절차를 정기적으로 검토·갱신하고, 주요 사고나
운영·위험의 중대한 변경 시 이를 반영하여야 한다.
⊙ ISMS-P
• ‌1.4.3 관리체계 개선 : 법적 요구사항 준수검토 및 관리체계 점검을 통해 식별된 관리체계상의 문제점에
대한 원인을 분석하고 재발방지 대책을 수립·이행하여야 하며, 경영진은 개선 결과의 정확성과 효과성
여부를 확인하여야 한다.

---
<!-- Page 175 -->

## 제3장 우주 보안모델 해설  | 175

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제10절
보안 거버넌스(SG)
SG-01
보안 정책 수립
항목 내용
우주보안 정책 및 지침을 수립하고 최고 경영진의 승인을 받은 뒤, 조직 환경
변화와 위협에 따라 주기적으로 검토·개정해야 한다.
목적
우주기업의 보안 목표 달성을 위한 정보보호 정책을 수립하고, 경영진의
공식적인 승인 및 주기적인 검토를 통해 정책의 실효성과 최신성을 확보하기
위함이다.
주요
확인사항
y ‌우주기업의 모든 보안 활동을 포괄하는 최상위 정책 및 절차를 수립하고,
경영진의 공식 승인을 득하고 전직원에게 전파하는가?
y ‌보안 정책을 조직 환경 변화와 위협을 고려하여 정기적으로 검토·갱신하고
있는가?
y ‌시스템 보안 요구사항 이행을 관리하기 위해 운영 개선 계획과 시스템 보안
계획을 수립·이행하는가?
y ‌적용되는 법령 및 보안 정책에 따라 보안 고지사항을 제공하는가?
세부 설명
⊙ ‌우주기업의 모든 보안 활동을 포괄하는 최상위 정책 및 절차를 수립하고, 경영진의 공식 승인 하에
수립하고 전직원에게 전파해야 한다.
▶ ‌우주기업이 수행하는 정보보호 활동의 근거를 포함하는 정보보호 정책을 다음 내용을 포함하여
수립
• ‌우주기업의 정보보호를 위한 역할·책임 및 대상·범위
• ‌우주기업이 수행하는 관리적·기술적·물리적 정보보호 활동의 근거
▶ ‌정보보호 정책을 구체적으로 시행하기 위하여 필요한 세부 방법, 절차, 주기, 수행주체 등을
규정하는 지침, 절차, 매뉴얼, 가이드 등의 하위 실행 문서를 우주기업의 특성에 맞게 수립

---
<!-- Page 176 -->
176 | 우주 보안 모델 해설 및 적용사례집
하위 실행 문서(예시)
보호대상 관점
수행주체 관점
y ‌서버보안 지침
y ‌네트워크보안 지침
y ‌데이터베이스보안 지침
y ‌애플리케이션보안 지침
y ‌웹서비스 보안 지침
y ‌클라우드 보안 지침
y ‌임직원 보안 지침
y ‌개발자 보안 지침
y ‌운영자 보안 지침 등
출처 : ISMS-P 인증기준 안내서(KISA)
▶ ‌승인된 정책 및 절차는 모든 관련 임직원 및 이해관계자에게 전달하고 인지시켜야 함
• ‌정책 및 시행문서는 제·개정사항이 발생하면 즉시 공표하고 최신본을 유지
• ‌관련 임직원들이 용이하게 참고할 수 있는 형태(전자게시판, 책자, 교육자료, 매뉴얼 등)로 제공
⊙ ‌보안 정책 및 관련 계획을 조직 환경 변화와 위협을 고려하여 정기적으로 검토·갱신해야 한다.
▶ ‌수립된 보안 정책 및 관련 계획의 유효성 유지를 위해 정기적인 타당성 검토 절차를 수립하고
이행해야 함
• ‌정보보호 관련 정책 및 시행문서에 대한 정기적인 타당성 검토 절차를 수립하고 이행해야 함
정기 타당성 검토 절차에 포함되어야 할 사항(예시)
y ‌검토 주기 및 시기 : 연 1회 이상 검토 필요
y ‌관련 조직별 역할 및 책임
y ‌담당 부서 및 담당자
y ‌검토 방법
y ‌후속조치 절차 : 정책 및 시행문서 제·개정이 필요한 경우 관련 절차, 내부 협의 및 보고 절차 등
출처 : ISMS-P 인증기준 안내서(KISA)
• ‌정책 검토 시 법령 및 규제, 상위 조직 정책과의 연계성 등을 분석해야 함
- ‌위험 평가 및 관리체계 점검 결과, 새로운 위협 및 취약점을 필수적으로 반영해야 함
- ‌문서 간 일관성(활동 주기, 수준, 방법 등) 유지 여부를 검토해야 함
▶ ‌중대한 사고 또는 운영이나 위험에 중대한 변경이 발생할 경우 정책을 검토하고 갱신해야 함
• ‌정보보호 관련 법규 제/개정사항(예정 사항 포함) 발생 시 정책에 미치는 영향을 검토해야 함
• ‌비즈니스 환경의 변화(신규 사업 진출 등), 중대한 보안사고 발생 등 환경 변화 발생 시 영향을
검토하고 필요시 제/개정해야 함

---
<!-- Page 177 -->

## 제3장 우주 보안모델 해설  | 177

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌정보보호 정책·시행문서 제·개정 시 최고경영자 또는 최고경영자로부터 권한을 위임받은 자의
승인을 득해야 함
• ‌정책서와 시행문서를 제·개정하는 경우 이해관계자와 해당 내용을 충분히 협의·검토
• ‌정책서 및 시행문서 변경으로 인한 조직 업무 및 서비스 영향도, 법적 준거성 등을 고려
• ‌회의록 등 검토 사항에 대한 기록을 남기고 정책·지침 등에 관련 사항 반영
• ‌검토가 완료된 정책서 및 시행문서를 경영진에게 보고하고 승인
▶ ‌문서 내에 문서버전, 일자, 개정 사유, 작성자, 승인자 등 개정이력을 기록하여 관리
⊙ ‌시스템 보안 요구사항 이행을 관리하기 위해 운영 개선 계획과 시스템 보안 계획을 수립·이행해야
한다.
▶ ‌조직 시스템의 취약점을 개선하기 위한 운영 개선 계획(POA, Plan of Action)을 개발하고
이행해야 함
• ‌보안 평가, 위험 분석 등을 통해 시스템의 결함 및 취약점을 명확히 식별해야 함
▶ ‌식별된 문제를 해결하기 위한 운영 개선 계획을 개발하고 이행해야 함
• ‌운영 개선 계획은 결함을 시정하고 취약점을 줄이거나 제거하는 구체적인 방안을 포함해야 함
• ‌운영 개선 계획은 책임 소유자 지정, 명확한 실행 단계, 각 단계별 완료 목표 날짜를 필수로
포함해야 함
• ‌마일스톤 달성 및 개선 완료에 따라 운영 개선 계획을 지속적으로 최신 상태로 유지해야 함
▶ ‌시스템 보안 계획을 수립, 문서화하고 주기적으로 갱신해야 함
• ‌시스템 보안 계획은 주요 정보를 취급하는 각 시스템에 대해 보안 요구사항 이행 방법을 설명하는
핵심 문서여야 함
- ‌시스템 보안 계획은 시스템의 보안 요구사항과 통제를 연계하여 기술해야 함
- ‌시스템 보안 계획은 시스템의 필수 구성 정보를 명시
- ‌시스템 경계 및 운영 환경을 설명하고 문서화
- ‌식별된 보안 요구사항의 구현 방법을 구체적으로 설명
- ‌다른 시스템과의 연결 상태 및 관계를 설명하고 문서화
- ‌적용 대상에서 제외 및 승인된 보안 요구사항을 식별하고 문서화
• ‌시스템 보안 계획을 최소 연 1회 이상 검토하고 갱신
⊙ ‌적용되는 법령 및 보안 정책에 따라 보안 고지사항을 제공해야 한다
▶ ‌조직은 정보 시스템 접근 시 사용자에게 보안 및 사용에 관한 법적 고지 사항을 명확히 제시해야
함

---
<!-- Page 178 -->
178 | 우주 보안 모델 해설 및 적용사례집
• ‌시스템에 저장되거나 접근을 제공하는 보호 대상 정보의 특성과 관련된 모든 법적 및 규제적
요구사항을 식별하고, 고지 내용이 해당 요구사항에 일관되게 부합하도록 작성해야 함
• ‌법적 고지사항에는 무단 사용 금지, 업무 목적 외 사용 제한, 시스템 이용 행위에 대한 모니터링
및 기록, 위반 시 법적 책임에 대한 안내 등이 포함될 수 있음
▶ ‌사용자에게 정보 시스템 사용은 감시(모니터링) 및 기록의 대상이 될 수 있음을 반드시 알리고
아래 사항들을 명시해야 함
• ‌비인가된 시스템 사용은 엄격히 금지되며, 민사 및 형사상의 처벌 대상이 될 수 있음
• ‌시스템을 사용하는 것은 감시 및 기록에 동의하는 것으로 간주됨
• ‌위성 운용 정보, 고객 정보 등 특정 보호 조치가 요구되는 민감 정보가 포함된 경우, 해당 사실을
명확히 고지
▶ ‌고지 사항은 사용자가 시스템에 접속하기 전, 누락 없이 인지할 수 있는 방식으로 표시되어야 함
• ‌고지 사항은 시스템 배너 형태로 구현하는 것이 일반적이며, 포스터나 인쇄물 등의 대체 수단도
활용할 수 있음
• ‌경고 배너나 메시지는 사용자가 시스템에 로그인하기 전에 표시되어야 함
• ‌위험 평가를 통해 최초 로그인 이후 특정 애플리케이션이나 중요 자원에 접근할 때 2차 고지
사항이 필요한지 검토해야 함
▶ ‌사용자가 고지 내용을 확인했음을 입증하기 위해 시스템 사용 전 동의 버튼을 클릭하도록 요구할
수 있으며, 이 동의 기록은 향후 보안 위반 발생 시 법적 증거로 활용될 수 있음
관련 기준
⊙ CMMC
• ‌3.12.2 운영 계획 : 조직 시스템의 결함을 바로잡고 취약성을 줄이거나 없애기 위한 행동 계획을 개발하고
실행한다.
• ‌3.12.4 시스템 보안 계획 : 시스템 경계, 시스템 운영 환경, 보안 요구 사항 구현 방법, 다른 시스템과의
관계 또는 연결을 설명하는 시스템 보안 계획을 개발, 문서화하고 주기적으로 업데이트한다.
• ‌3.1.9 개인정보 보호 및 보안 고지 : 해당 CUI 규칙에 따라 개인정보 보호 및 보안 고지사항을 제공한다.
⊙ K-RMF
• ‌PA-1 정책 및 절차 :

## 1. 모든 보안통제항목 패밀리에 대해 다음 사항을 개발하고 유지 및 배포해야 한다.


가. ‌보안통제항목 패밀리의 목적, 범위, 직책, 지휘관심 제고, 협조사항, 준수사항을 포함하는 정책

나. 보안통제항목 패밀리 정책과 관련된 보안통제항목의 구현을 돕는 절차

## 2. 수립된 정책 및 절차에 대하여 다음사항을 시행한다.


가. [조직이 지정한 주기 또는 상황]마다 각 보안통제항목 패밀리 정책을 검토 및 개정

나. [조직이 지정한 주기 또는 상황]마다 각 보안통제항목의 구현을 돕는 절차를 검토 및 개정

---
<!-- Page 179 -->

## 제3장 우주 보안모델 해설  | 179

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ NIS2
• ‌1.1 네트워크 및 정보시스템 보안 정책 : 관련 기관은 네트워크·정보시스템 보안 위험관리체계를
수립·유지하고, 위험평가·처리계획을 시행하며 경영진이 승인하도록 하여야 한다.
⊙ ISMS-P
• ‌2.1.1 정책의 유지관리 : 정보보호 및 개인정보보호 관련 정책과 시행문서는 법령 및 규제, 상위 조직
및 관련 기관 정책과의 연계성, 조직의 대내외 환경변화 등에 따라 주기적으로 검토하여 필요한 경우
제∙개정하고 그 내역을 이력관리하여야 한다.

---
<!-- Page 180 -->
180 | 우주 보안 모델 해설 및 적용사례집
SG-02
보안 역할 및 책임 정의
항목 내용
우주보안 관련 책임자 및 담당자의 역할·책임을 정의하고, 조직 변화에 따라
이를 지속적으로 유지·관리해야 한다.
목적
우주기업의 보안 목표 달성을 위해 우주 시스템 관련 책임과 의무를 명확히
정의하고, 조직 운영 및 인력 변화에 따라 책임성을 지속적으로 확보하기
위함이다.
주요
확인사항
y ‌정보보호 업무를 총괄하는 정보보호 최고책임자를 공식적으로 지정하였는가?
y ‌우주보안 관련 책임자 및 담당자의 역할과 책임을 할당하고, 환경 변화를
고려하여 정기적으로 검토·갱신하는가?
세부 설명
⊙ ‌정보보호 업무를 총괄하는 정보보호 최고책임자를 공식적으로 지정해야 한다.
▶ ‌정보보호 최고책임자는 인사 발령 등 공식 절차를 통해 지정하고, 정보보호 정책 또는 내부
규정에 해당 직위와 책임을 명시해야 함
▶ ‌조직의 규모와 특성에 따라 최고경영자, 임원, 또는 정보보호 관련 부서의 장이 정보보호
최고책임자를 겸직할 수 있음
▶ ‌정보보호 최고책임자 지정 시에는 「정보통신망법 시행령 제36조의7」에 따른 법적 요건을
충족하도록 검토해야 함
정보보호 최고책임자 지정요건(정보통신망법 시행령 제36조의7 제1항)
구분 (정보통신서비스 제공자)
정보보호 최고책임자 지정 요건
1
y ‌자본금 1억원 이하인 자
y ‌소기업
y ‌중기업으로서 전기통신사업자, ISMS-P 인증 의무자,
개인정보 처리방침 공개 의무자, 통신판매업자가 아닌 자
y ‌사업주 또는 대표자
2
y ‌직전 사업연도 말 기준 자산총액 5조원 이상인 자
y ‌법 제47조제2항에 따른 ISMS-P 인증 의무자 중 직전
사업연도 말 기준 자산총액 5천억원 이상인 자
y ‌이사(상법 제401조의2 제1항 제3호
및 제408조의2 집행임원 포함
※ 겸직 제한 요건 준수 필요
3
y ‌위 1호, 2호에 해당하지 않는 자
y ‌사업주 또는 대표자
y ‌이사(상법 제401조의2 제1항 제3호
및 제408조의2 집행임원 포함)
y ‌정보보호 관련 업무 총괄 부서의 장

---
<!-- Page 181 -->

## 제3장 우주 보안모델 해설  | 181

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌우주보안 관련 책임자 및 담당자의 역할과 책임을 할당하고, 환경 변화를 고려하여 정기적으로
검토하고 갱신해야 한다.
▶ ‌보안 관련 책임자와 담당자의 역할 및 책임을 공식적인 절차(인사발령, 직무기술서 공지 등)을
통해 정의해야 함
• ‌정보보호 최고책임자: 정보보호 관리체계 총괄, 정책 수립·이행 관리
• ‌정보보호 관리자 및 담당자: 보안 통제 운영, 점검, 사고 대응 수행
• ‌부서별 정보보호 책임자: 부서 내 보안 준수 및 현업 통제 이행 책임
▶ ‌보안 관련 책임자와 담당자의 활동을 평가할 수 있는 체계(핵심성과지표(KPI, Key Performance
Indicator), 목표관리(MBO, Management By Objectives), 인사평가 등)를 수립하고
주기적으로 평가해야 함
▶ ‌역할, 책임 및 권한은 연 1회 이상 검토하고 필요에 따라 갱신해야 하며, 중대한 사고 또는
운영이나 위험에 중대한 변경이 발생할 때도 갱신해야 함
• ‌보직 변경 후에도 시스템 또는 시설에 대한 논리적 및 물리적 접근 인가를 유지할지 검토하고,
운영 요구사항의 변화에 따라 접근 인가를 수정해야 함
• ‌조직 내 인원의 전출 시 시스템 접근을 비활성화하도록 요구하고, 해당 인원과 관련된 모든 인가,
인증 및 자격 증명을 반납, 해지 및 취소하도록 요구해야 함
관련 기준
⊙ NIS2
• ‌1.2 역할, 책임 및 권한 : 네트워크 및 정보시스템 보안에 관한 책임과 권한을 규정하고 이를 역할에
배정하며, 기관의 필요에 따라 적절히 할당하고, 경영진에게 이를 전달하여야 한다.
⊙ ISMS-P
• ‌2.1.2 조직의 유지관리 : 조직의 각 구성원에게 정보보호와 개인정보보호 관련 역할 및 책임을 할당하고,
그 활동을 평가할 수 있는 체계와 조직 및 조직의 구성원 간 상호 의사소통할 수 있는 체계를 수립하여
운영하여야 한다.

---
<!-- Page 182 -->
182 | 우주 보안 모델 해설 및 적용사례집
SG-03
자산 관리
항목 내용
우주 관련 자산을 식별하고 목록화하며, 변동 사항을 반영하여 최신 상태로
관리해야 한다.
목적
주요 우주 관련 유·무형의 자산을 식별, 목록화하고 중요도에 따라 분류하며,
자산의 변경 내역을 관리하여 자산의 무결성 및 보안 태세를 유지하기 위함이다.
주요
확인사항
y ‌우주 관련 자산을 식별하고 자산목록에 등록하며, 변동
사항(추가·변경·폐기)을 반영하여 최신 상태로 유지·관리하는가?
y ‌자산의 중요도 및 특성에 따라 분류 기준을 적용하고, 자산별 책임자를
지정하며, 이에 따라 적정한 보호대책이 수립·이행되고 있는가?
세부 설명
⊙ ‌우주 관련 자산을 식별하고 자산목록에 등록하며, 변동 사항(추가·변경·폐기)을 반영하여 최신
상태로 유지·관리해야 한다.
▶ ‌조직의 네트워크 및 정보시스템 범위 내에 있는 모든 자산(정보 포함)의 완전하고 정확하며
최신성을 유지하는 목록을 개발하고 유지해야 함
• ‌자산 목록은 자산을 식별·관리하고 보안 통제를 적용할 수 있도록 자산의 종류, 용도, 위치(또는
논리적 위치), 담당 부서 또는 책임자를 식별해야 함
• ‌자산 목록에는 다음과 같은 유형의 자산을 포함해야 함
- 물리적 자산: 서버, 네트워크 장비, 위성 운용 장치, 개발·운영용 단말 등
- 소프트웨어 및 정보 자산: 운영체제, 애플리케이션, 데이터베이스 등
- 클라우드 자산: 클라우드 상에서 생성·운영되는 가상 서버, 저장소, 네트워크 구성요소 등
• ‌자산 목록에는 하드웨어 특성(제조사, 모델, 위치 등), 소프트웨어 및 라이선스 정보, 시스템 및
구성요소 소유자 등 책임자 식별에 필요한 정보를 포함해야 함
▶ ‌자산 목록은 정기적으로 검토하고 업데이트해야 함
• ‌시스템 구성요소의 설치, 제거 및 시스템 업데이트 시 시스템 구성요소 목록을 최신화해야 함
• ‌자산 목록에 대한 변경사항은 추적 가능한 방식으로 기록하고, 변경 이력을 문서화해야 함
⊙ ‌자산의 중요도 및 특성에 따라 분류 기준을 적용하고, 자산별 책임자를 지정하며, 이에 따라 적정한
보호대책을 수립·이행해야 한다.
▶ ‌조직이 소유·관리하거나 운영에 활용하는 네트워크, 정보시스템, 위성 운용 환경,
개발·시험·운영 목적의 시스템 및 시스템 내에서 처리·저장되는 정보자산을 포함하여 자산을
식별·분류해야 함

---
<!-- Page 183 -->

## 제3장 우주 보안모델 해설  | 183

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌모든 자산을 기밀성, 무결성, 가용성 요구 수준을 정의하고 해당 수준에 맞는 보호 조치가
적용되도록 분류 기준을 수립해야 함
• ‌자산의 가용성 요구사항을 비즈니스 연속성 및 재해 복구 계획에 설정된 복구 목표와 일치시켜야 함
▶ ‌정보자산의 중요도 및 특성에 따라 자산별 취급 절차(생성·도입, 저장, 이용, 파기) 및 접근통제,
암호화 등의 적절한 보호대책을 선정하고 이행
• ‌임직원이 정보자산별 보안등급(기밀, 대외비, 일반 등)을 식별할 수 있도록 표시
- (전자)문서 : 문서 표지 또는 워터마킹 등을 통하여 표시
- 서버 등 하드웨어 자산 : 자산번호 또는 바코드 표시 등을 통한 보안등급 확인
• ‌정보자산 보안등급별로 취급절차(생성·도입, 저장, 이용, 파기 등) 및 보안통제 기준 수립·이행
보안등급별 취급 절차 (예시)
y ‌기밀 자산: 승인된 시스템에서만 생성·저장, 암호화 저장 및 전송, 파기 시 완전 삭제
y ‌일반 자산: 업무 시스템 내 저장 허용, 내부 공유 가능, 파기 시 논리적 삭제
▶ ‌우주기업 내 보안 정책에 따라 자산(정보 포함)의 적절한 취급을 위한 정책을 수립, 이행 및
적용하고, 자산을 사용하거나 취급하는 모든 인원에게 정책을 전파해야 함
• ‌취급 정책은 자산의 안전한 사용, 안전한 보관, 안전한 운송, 그리고 복구 불가능한 삭제 및
파기에 대한 절차를 제공해야 함
▶ ‌식별된 정보자산에 대하여 책임자 및 관리자를 지정하여 책임소재를 명확히 정의해야 함
• ‌정보자산 책임자 및 담당자의 인사이동 발생 시 정보자산 목록의 책임자 및 담당자를 갱신
▶ ‌자산의 분류 수준을 정기적으로 검토하고, 필요한 경우 업데이트해야 함
▶ ‌자산 취급 정책은 중대한 사고 또는 운영이나 위험에 중대한 변경이 발생할 시 추가로 검토하고
갱신해야 함
관련 기준
⊙ K-RMF
• ‌PA-2 시스템목록 : 시스템을 목록화하여 문서화 및 유지·관리해야 한다.
⊙ NIS2
• ‌12.1 자산 분류 : 관련 기관은 네트워크 및 정보시스템 범위에 포함되는 모든 자산(정보 포함)에 대해
필요한 보호 수준에 따른 분류 등급을 설정하여야 한다.
• ‌12.2 자산 취급 : 자산 처리 정책을 수립·시행하고, 모든 사용자·취급자에게 전파해야 한다.
• ‌12.4 자산 목록 : 자산 목록을 최신으로 정확하게 관리하고, 변경 내역을 추적 가능하게 기록해야 한다.
⊙ ISMS-P
• ‌2.1.3 정보자산 관리 : 정보자산의 용도와 중요도에 따른 취급 절차 및 보호대책을 수립·이행하고, 자산별
책임소재를 명확히 정의하여 관리하여야 한다.

---
<!-- Page 184 -->
184 | 우주 보안 모델 해설 및 적용사례집
SG-04
법적 요구사항 준수
항목 내용
우주보안 관련 법적·규제적 요구사항을 식별하여 내부 규정에 반영하고, 준수
여부를 지속적으로 검토해야 한다.
목적
우주기업이 준수해야 하는 모든 법적/규제적 요구사항을 식별하고 내부 규정에
반영하며, 지속적인 준수 검토를 통해 법적 책임과 보안 체계의 적절성을
유지하기 위함이다.
주요
확인사항
y ‌적용되는 모든 법적 요구사항을 식별하여 내부 정책 및 지침에 반영하고 조직
환경 변화에 따라 최신성을 유지하는가?
y ‌수립된 정책 및 법적 요구사항에 대한 준수 여부를 독립적인 인력이
주기적으로 검토하고 그 결과를 경영진에게 보고하는가?
세부 해설
⊙ ‌적용되는 모든 법적 요구사항을 식별하여 내부 정책 및 지침에 반영하고 조직 환경 변화에 따라
최신성을 유지해야 한다.
▶ ‌조직이 준수해야 할 모든 법적 요구사항을 목록화하고 최신 상태를 유지해야 함
• ‌국내 법규 식별 (예시)
법령
설명
개인정보보호법
개인정보의 수집·이용·보관·파기에 관한 안전조치를 요구하는 국내
최고 상위 개인정보 보호 법령
정보통신망법
정보통신서비스 제공자가 준수해야 하는 보안조치 및 보안사고 신고
의무를 규정
전파법
지상국 운용 및 위성과의 통신에 필요한 주파수 할당·사용 기준을
규정하고 전파 간섭 방지 요구
우주개발진흥법
위성, 지상국 등 우주개발사업의 등록·신고 절차 및 안전관리 기준을
규정
클라우드컴퓨팅 발전 및
이용자 보호에 관한 법률
클라우드 서비스 제공 및 이용 환경의 안정성 확보 및 보호 의무 규정.
클라우드 사업자 준수 대상 법률

---
<!-- Page 185 -->

## 제3장 우주 보안모델 해설  | 185

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌글로벌 법규 식별 (예시)
법령
설명
NIS2 Directive
필수·중요 서비스 기업에 대한 네트워크·정보보호 의무, 사고보고
의무를 강화한 EU 보안 규제
CRA
디지털 요소가 포함된 하드웨어·소프트웨어 제품의 제조사에게 사이버
보안 책임을 부여해 제품 생애주기 전체에서 보안을 보장하는 유럽연합
규정
▶ ‌식별된 법규 변화가 조직에 미치는 영향을 분석하고 문서화해야 함
• ‌법규 제/개정 사항이 조직의 서비스, 정보 시스템, 개인정보 처리에 미치는 기술적/관리적 영향을
분석해야 함
• ‌법적 요구사항 변경 사항, 영향 분석 결과, 그리고 이에 따른 내부 정책 변경 필요성을 공식적으로
문서화해야 함
• ‌분석 결과에 따라 내부 정보보호 정책, 개인정보처리방침, 보안 지침, 내부 통제 체크리스트 등에
해당 법규의 요구사항을 반영하여 최신성을 유지해야 함
▶ ‌식별된 관련 법규의 제정 및 개정 현황을 지속적으로 모니터링하고 주기적으로(최소 연 1회)
검토하고 업데이트해야 함
• ‌검토 시 법적 요구사항 및 규제 준수 현황, 위험 평가 결과, 새로운 위협 및 취약점 발견 등을
반영해야 함
• ‌정보보호 관련 정책 및 시행문서의 변경사항(버전, 개정 사유, 작성자, 승인자 등)에 관한 이력을
기록·관리해야 함
⊙ ‌수립된 정책 및 법적 요구사항에 대한 준수 여부를 독립적인 인력이 주기적으로 검토하고 그 결과를
경영진에게 보고해야 한다.
▶ ‌우주기업의 정보보호 정책, 관련 지침 및 내부 기준에 대한 준수 여부를 정기적으로 검토해야 함
• ‌법적 요구사항의 준수 여부를 연 1회 이상 정기적으로 검토하는 절차를 수립하고 이행해야 함
• ‌준수 여부 모니터링은 정기적으로 수행되며, 중대한 사고 또는 운영이나 위험에 중대한 변경이
발생할 때 추가 모니터링을 수행해야 함
▶ ‌감사를 수행하는 인원은 검토 대상의 운영 인력과 분리되어야 하며 적절한 감사 전문성을 갖춘
인력에 의해 수행되어야 함
• ‌조직 규모로 인해 독립성 확보가 어려운 경우, 공정성을 보장하기 위한 대체 조치(예: 외부 전문
기관 감사, 교차 감사)를 마련하여 이행해야 함

---
<!-- Page 186 -->
186 | 우주 보안 모델 해설 및 적용사례집
• ‌감사는 정기적으로 수행되며, 중대한 사고 또는 운영이나 위험에 중대한 변경이 발생할 때는
추가적으로 감사를 수행해야 함
▶ ‌감사 결과는 경영진에게 보고하고 시정 조치를 이행해야 함
• ‌보고에는 발견된 문제점, 취약점, 잠재적 위험을 포함해야 함
• ‌감사 결과 식별된 문제점에 대해 시정 조치를 취해야 함
- ‌시정 조치가 불가능하거나 현실적이지 않은 경우, 조직의 위험 수용 기준에 따라 잔존 위험을
경영진이 공식적으로 수용해야 함
• ‌법적 요구사항 준수 검토 및 관리체계 점검을 통해 식별된 문제점에 대한 근본 원인을 분석하고,
재발 방지 대책을 수립 및 이행해야 함
• ‌재발 방지 및 개선 조치의 정확성과 효과성 확인을 위한 기준과 절차를 마련하고, 측정 결과를
경영진에게 보고해야 함
관련 기준
⊙ NIS2
• ‌2.2 컴플라이언스 모니터링 : 보안 정책 준수 여부를 정기적으로 점검하고, 그 결과를 경영진에 보고해야
한다.
• ‌2.3 정보 및 네트워크 보안에 대한 독립적 검토 : 보안 관리 방식과 실행을 인력·프로세스·기술 측면에서
독립적으로 점검해야 한다.
⊙ ISMS-P
• ‌1.4.1 법적 요구사항 준수 검토 : 조직이 준수하여야 할 정보보호 및 개인정보보호 관련 법적 요구사항을
주기적으로 파악하여 규정에 반영하고, 준수 여부를 지속적으로 검토하여야 한다.

---
<!-- Page 187 -->

## 제3장 우주 보안모델 해설  | 187

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제11절
비상 계획(CP)
CP-01
비상계획 수립
항목 내용
우주 시스템의 운영 연속성을 위협할 수 있는 보안 위협 유형을 식별해야 하며,
비상시 복구 절차, 복구 조직, 비상연락체계 등 비상계획을 수립하고 주기적으로
점검해야한다.
목적
우주 시스템의 운영 연속성을 위협하는 재난 및 사고 유형을 식별하고, 비상계획
및 복구 절차를 수립하여 시스템의 신속한 복구 및 임무 지속성을 확보하기
위함이다.
주요
확인사항
y ‌우주기업은 재해 유형을 식별하고 피해 규모 및 영향을 분석하여 핵심
서비스와 시스템을 식별했는가?
y ‌우주기업은 재해·재난 발생 시 핵심 서비스와 시스템의 연속성을 보장하는가?
세부 설명
⊙ ‌우주기업은 재해 유형을 식별하고 피해 규모 및 영향을 분석하여 핵심 서비스와 시스템을 식별해야
한다.
▶ ‌자연재해, 해킹, 통신장애 등 조직의 핵심 서비스(업무) 연속성을 위협할 수 있는 IT 재해 유형
식별해야 함
서비스 중단을 초래할 수 있는 재해 유형(예시)
y ‌자연재해 : 화재, 홍수, 지진, 태풍 등
y ‌외부요인 : 해킹, 통신장애, 정전 등
y ‌내부요인 : 시스템 결함, 기계적 오류, 사용자 실수, 의도적·악의적 운영, 핵심 운영자 근무
이탈(사망, 병가, 휴가, 이직 등), 환경설정 오류 등
출처 : ISMS-P 인증기준 안내서(KISA)
▶ ‌재해 유형별 조직의 핵심 서비스(업무) 중단 시 피해규모 및 영향을 분석하여 핵심 서비스 및
시스템을 식별해야 함
• ‌재무적 측면(매출 감소, 계약 위약금 지급 등)과 법적 정성적 측면(손해배상 소송, 대외 이미지
하락, 경쟁력 손상 등)을 고려하여 핵심 서비스 식별
• ‌위성 제어, 임무 운영(MOC), 탑재체 제어(PCC), 데이터 수신·처리 등 임무 지속에 필수적인
기능을 핵심 서비스로 정의할 수 있음

---
<!-- Page 188 -->
188 | 우주 보안 모델 해설 및 적용사례집
• ‌핵심 서비스가 중단될 경우 우주 영역과 지상국 영역에 미치는 영향을 기준으로 중요도 구분
▶ ‌핵심 서비스 및 시스템의 중요도 및 특성을 반영하여 복구 목표시간(RTO: Recovery Time
Objective)과 데이터가 복구되어야 하는 목표시점(RPO: Recovery Point Objective)을 정의
⊙ ‌우주기업은 재해·재난 발생 시 핵심 서비스와 시스템의 연속성을 보장해야 한다.
▶ ‌재해 발생 시 사전 정의한 서비스 및 시스템 복구 목표시간 및 복구 목표시점을 달성하기 위해
업무연속성 관리 체계 수립
▶ ‌업무연속성 관리 체계에는 다음의 내용을 포함해야 함
구분
설명
비상연락망 및 역할
재해·재난 발생 시 신속한 의사결정과 대응을 위해 비상 대응
조직을 구성하고, 서비스 운영·시스템 복구·대외 소통 등 역할을
사전에 구분
핵심 서비스 및 시스템 식별
위성 운영, 지상국 운용, 데이터 처리 등 중단 시 영향이 큰 핵심
서비스와 시스템을 식별하고 우선순위 설정
연속성 운영 시나리오
시설 장애, 인력 가용성 저하, 시스템 침해 등 다양한 재해·재난
상황을 고려한 서비스 지속 및 대체 운영 방안 마련
가용 자원 관리
재해 상황에서도 활용 가능한 인력, 장비, 시스템, 외부 지원 자원
현황을 파악하고 필요 시 즉시 활용할 수 있도록 관리
인력 및 운영 대체 방안
핵심 인력 부재 또는 운영 제한 상황에서도 주요 서비스가 유지될 수
있도록 교대 인력, 원격 운영, 외부 지원 활용 방안을 마련
내부·외부 소통 체계
재해 발생 시 직원, 협력사, 고객, 관계기관과의 원활한 정보 공유를
위해 연락 체계와 공지 절차를 사전 정비
복구 절차
재해 종료 후 시스템 복구, 데이터 정합성 확인, 서비스 정상화
절차를 수립하여 운영 혼선 최소화
▶ ‌우주기업은 업무 영향 분석(Business Impact Analysis, BIA)을 수행하여 사업 운영에 심각한
장애가 발생할 경우 잠재적 영향을 평가할 수 있음
▶ ‌복구 계획은 정기적으로 검토·갱신되어야 하며, 중대한 사고 발생이나 운영·위험의 중대한
변화가 있을 경우에도 검토·갱신 필요

---
<!-- Page 189 -->

## 제3장 우주 보안모델 해설  | 189

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ K-RMF
• ‌CP-1 비상계획 :

## 1. 시스템에 대한 비상계획을 다음의 내용을 포함하여 수립해야 한다.


가. 필수 임무와 관련 비상시 요구사항 식별

나. 복구목표, 복구 우선순위, 절차 제공

다. 비상 시 역할, 책임, 관련자(유지보수업체 포함) 연락처

라. 시스템 중단, 손상, 장애 시 필수 기능을 유지하기 위한 대책

마. 기 계획·구현된 보안 보호조치의 성능저하 없이 시스템 정상 복구

바. [조직이 지정한 직책]이 검토 및 승인

## 2. 비상계획 사본을 [조직이 지정한 관련 인원 및 관계 부서]에 전파해야 한다.


## 3. 사고처리 활동과 비상계획 활동을 조율해야 한다.


## 4. 시스템 비상계획을 [조직이 지정한 주기]마다 검토해야 한다.

5. ‌시스템의 구성, 기능 및 운영개념 등이 변경되는 경우, 기존의 비상계획을 재검토하고 필요시 갱신해야
한다.

## 6. 비상계획 변경사항을 2번에서 [조직이 지정한 관련 인원 및 관계 부서]에 알려야 한다.


## 7. 비상계획을 무단 공개 및 수정으로부터 보호해야 한다.

⊙ NIS2
• ‌4.1 비즈니스 연속성 및 재해복구 계획 : 관련 기관은 사고 발생 시 적용할 수 있도록 업무연속성 및
재해복구 계획을 수립·유지하여야 한다.
• ‌4.3 위기관리 : 위기관리 절차를 수립하고, 위기 대응 체계, 의사소통 절차, 책임·역할 분담, 복구 계획,
사후 평가 등을 포함해야 한다.
⊙ ISMS-P
• ‌2.12.1 재해, 재난 대비 안전조치 : 자연재해, 통신·전력 장애, 해킹 등 조직의 핵심 서비스 및 시스템의
운영 연속성을 위협할 수 있는 재해 유형을 식별하고 유형별 예상 피해규모 및 영향을 분석하여야 한다.
또한 복구 목표시간, 복구 목표시점을 정의하고 복구 전략 및 대책, 비상시 복구 조직, 비상연락체계, 복구
절차 등 재해 복구체계를 구축하여야 한다.
• ‌2.12.2 재해 복구 시험 및 개선 : 재해 복구 전략 및 대책의 적정성을 정기적으로 시험하여 시험결과,
정보시스템 환경변화, 법규 등에 따른 변화를 반영하여 복구전략 및 대책을 보완하여야 한다.

---
<!-- Page 190 -->
190 | 우주 보안 모델 해설 및 적용사례집
CP-02
백업 및 이중화 관리
항목 내용
조직의 중요정보를 식별하고 주기적으로 백업하며 중요 네트워크, 시스템은
이중화한다.
목적
우주기업의 중요 정보 및 핵심 시스템의 가용성과 무결성을 보장하기 위해
복구 목표를 고려한 백업 및 이중화 체계를 수립하고 운영 연속성을 확보하기
위함이다.
주요
확인사항
y ‌중요 데이터·시스템을 복구 목표에 따라 주기적으로 백업하며, 백업본의
기밀성·무결성·가용성을 고려하여 안전하게 관리하는가?
y ‌백업 및 이중화 시스템을 정기적으로 테스트하고, 그 결과를 반영하여 계획 및
절차를 지속적으로 개선하는가?
세부 설명
⊙ ‌중요 데이터·시스템을 복구 목표에 따라 주기적으로 백업하며, 백업본의 기밀성·무결성·가용성을
고려하여 안전하게 관리해야 한다.
▶ ‌백업 대상 및 목표를 포함한 백업 계획을 수립해야 함
• ‌백업 방법 및 절차, 백업담당자 및 책임자 지정을 포함한 백업 및 복구 절차를 수립하고 이행해야 함
- 백업대상 선정기준 수립
- 백업담당자 및 책임자 지정
- 백업대상별 백업 주기 및 보존기한 정의
- 백업방법 및 절차 : 백업시스템 활용, 매뉴얼 방식 등
- 백업매체 관리(예 : 라벨링, 보관장소, 접근통제 등)
- ‌백업 복구 절차 : 주요 정보시스템의 경우 IT 재해 복구 측면에서 백업정보의 완전성, 정확성
등을 점검하기 위하여 정기적인 복구 테스트 수행 필요
- 백업관리대장 관리
주요 백업 대상(예시)
y ‌중요정보(기밀정보, 탑재체정보 등)
y ‌중요 데이터베이스
y ‌각종 로그(정보시스템 감사로그, 이벤트 로그, 보안시스템 이벤트 로그 등)
y ‌환경설정 파일 등
출처 : ISMS-P 인증기준 안내서(KISA)

---
<!-- Page 191 -->

## 제3장 우주 보안모델 해설  | 191

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌백업 대상별 복구 목표시간(RTO) 및 복구 목표시점(RPO)을 고려하여 백업 주기 및 보존기한을
정의해야 함
▶ ‌백업 정보의 완전성과 보안을 확보해야 함
• ‌구성 데이터 및 클라우드 컴퓨팅 서비스 환경에 저장된 데이터를 포함하여 백업 복사본이
완전하고 정확한지 확인해야 함
• ‌백업 정보의 기밀성 보호를 위해 암호화 메커니즘을 적용하는 등의 조치를 해야 함
• ‌백업 복사본에 대해 자산 분류 수준에 따라 적절한 물리적 및 논리적 접근통제를 적용해야 함
• ‌백업된 정보의 신뢰성 및 무결성 유지 여부를 정기적으로 확인해야 함
▶ ‌중요정보가 저장된 백업매체의 경우 재해·재난에 대처할 수 있도록 백업매체를 물리적으로
떨어진 장소에 소산해야 함
• ‌중요정보가 저장된 백업매체는 운영 중인 정보시스템 또는 백업시스템이 위치한 장소로부터
물리적으로 거리가 있는 곳에 소산 보관하고 관리대장으로 소산 이력을 관리
- 소산일자(반출, 반입 등)
- 소산 백업매체 및 백업정보 내용
• ‌소산이 적절히 이루어지고 있는지 여부에 대하여 주기적으로 점검하고, 소산장소에 대한
보안대책을 마련해야 함
- 화재, 홍수와 같은 자연재해에 대한 대책(예 : 내화금고, 방염처리 등)
- 소산장소 및 매체에 대한 접근통제 등
⊙ ‌백업 및 이중화 시스템을 정기적으로 테스트하고, 그 결과를 반영하여 계획 및 절차를 지속적으로
개선해야 한다.
▶ ‌복구 절차 및 복구 가능성을 정기적으로 테스트해야 함
• ‌백업 복사본 및 이중화의 복구 가능성을 정기적으로 테스트하여 복구 조건에서 신뢰할 수 있는지
확인해야 함
• ‌복구 테스트를 실시하여 백업된 정보의 완전성과 정확성, 복구 절차의 적절성을 확인해야 함
• ‌테스트 시나리오를 수립하고, 백업 정보의 샘플을 사용하여 기능의 정상 복구 및 작동 여부를
확인해야 함
▶ ‌테스트 결과를 반영하여 계획을 지속적으로 개선해야 함
• ‌재해 복구 시험 계획을 수립하고 이에 따라 정기적인 시험을 실시해야 함
• ‌테스트 결과를 문서화하고, 문제점 발견 시 개선 계획을 수립하고 이행해야 함
• ‌시험 결과, 정보시스템 환경 변화, 법규 등에 따른 변화를 반영할 수 있도록 복구 전략 및 대책을
정기적으로 검토하고 보완해야 함

---
<!-- Page 192 -->
192 | 우주 보안 모델 해설 및 적용사례집
관련 기준
⊙ K-RMF
• ‌CP-8 시스템 백업 :
1. ‌시스템 내 사용자가 관리하는 정보를 [RTO(복구목표시간)/RPO(복구목표시점)를 고려한 주기]마다
백업해야 한다.
2. ‌시스템 내 시스템 수준의 정보를 [RTO(복구목표시간)/RPO(복구목표시점)를 고려한 주기]마다
백업해야 한다.
3. ‌시스템 문서(보안 관련 문서 포함)를 [RTO(복구목표시간)/RPO(복구목표시점)를 고려한 주기]마다
백업해야 한다.

## 4. 저장되어 있는 백업 정보의 기밀성·무결성·가용성을 보호해야 한다.

⊙ NIS2
• ‌4.2 백업 및 이중화 관리 : 데이터의 백업 사본을 유지하고, 시설·네트워크 및 정보시스템·인력 등 충분한
가용 자원을 제공하여 적절한 수준의 백업 체계를 확보하여야 한다.
⊙ ISMS-P
• ‌2.9.3 백업 및 복구관리 : 정보시스템의 가용성과 데이터 무결성을 유지하기 위하여 백업 대상, 주기,
방법, 보관장소, 보관기간, 소산 등의 절차를 수립·이행하여야 한다. 아울러 사고 발생 시 적시에 복구할 수
있도록 관리하여야 한다.

---
<!-- Page 193 -->

## 제3장 우주 보안모델 해설  | 193

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제12절
공급망 관리(SM)
SM-01
공급망 보호
항목 내용
협력사로 인해 발생할 수 있는 보안 위협을 방지하기 위해 공급망 보안 정책을
수립하여 협력사 선정을 위한 기준과 계약서를 마련하고, 협력사 명부를 작성 및
최신화해야 한다.
목적
우주 시스템 공급망의 잠재적 위험을 식별 및 완화하기 위해 포괄적인 보안 정책
및 협력사 관리 체계를 수립하고 유지하기 위함이다.
주요
확인사항
y ‌공급망 보안 정책을 수립하고, 협력사 계약 시 협력사가 이행해야 할
기술적·관리적 보안 요건을 명시하는가?
y ‌협력사 목록을 최신으로 유지하고, 이들의 보안 통제 이행 여부를 주기적으로
점검하는가?
세부 설명
⊙ ‌공급망 보안 정책을 수립하고, 협력사 계약 시 협력사가 이행해야 할 기술적·관리적 보안 요건을
명시해야 한다.
▶ ‌공급망 보안 정책을 수립하고 이행해야 함
• ‌공급망 보안 정책은 하드웨어 및 소프트웨어 공급업체에서 제공하는 네트워크 및 정보 시스템,
소프트웨어의 취약점을 제거 및 개선하는 내용을 포함해야 함
• ‌정책 수립 시 우주기업의 공급망 내 역할을 식별하고 이를 협력사에게 명확히 전달해야 함
• ‌시스템, 구성요소 또는 서비스를 구매하기 위해 조직의 구매 및 보안 규정을 준수해야 함
▶ ‌협력사 선정 시 선정을 위한 객관적 기준을 정의하고 적용해야 함
• ‌공급업체 및 서비스 제공업체 선정 및 계약 시 준수해야 하는 보안 기준을 공급망 보안 정책에
포함해야 함
• ‌보안 기준에는 다음 사항을 포함해야 함
- 공급업체의 개발보안 절차를 포함한 사이버 보안 수준 평가 방법 및 절차
- 서비스의 전반적인 사이버 복원력 및 제품의 보안 수준
- 적용 가능한 경우, 특정 공급업체 종속을 피하기 위한 대체원 존재 여부 확인
▶ ‌협력사 계약 시 필수적인 보안 요구사항을 계약서에 반영해야 함

---
<!-- Page 194 -->
194 | 우주 보안 모델 해설 및 적용사례집
• ‌계약서에는 최소한 다음 보안 요구사항을 명시해야 함
- 공급업체 직원이 갖추어야 하는 보안 인식 및 역량(보안 교육 수료 등)
- 공급업체의 침해사고 발생 시 지체 없이 조직에 통지해야 하는 의무
- 공급업체가 공급한 하드웨어 및 소프트웨어의 취약점을 조치할 의무
- 하도급 관련 요구사항 및 하도급 업체에 대한 사이버 보안 요구사항
- 감사 권한 또는 감사 보고서를 받을 권한
- 계약 종료 시 공급업체가 사업 수행 중 취득한 정보의 회수 및 폐기에 대한 의무
⊙ ‌협력사 목록을 최신으로 유지하고, 이들의 보안 통제 이행 여부를 주기적으로 점검하고 개선해야
한다.
▶ ‌조직은 주요 협력사(공급업체) 목록을 작성하고, 변경 사항을 반영하여 최신 상태로 유지
• ‌협력사 목록에는 담당 부서, 담당자 연락처, 제공받는 제품·서비스·업무 범위를 포함
▶ ‌공급망 보안 정책 및 관리 절차가 실제로 이행되고 있는지를 정기적으로 점검
• ‌협력사의 보안 관리 수준, 사고 이력, 주요 보안 변화 사항을 주기적으로 확인하고 필요 시 개선을
요구
• ‌다음과 같은 경우에는 협력사 보안 관리 현황을 재검토하고 추가 조치를 수행
- 협력사의 운영 환경 또는 제공 서비스에 중대한 변경이 발생한 경우
- 협력사와 관련된 보안 사고 또는 보안 이슈가 발생한 경우.
▶ ‌협력사 점검 결과를 바탕으로 공급망 위험을 분석하고, 필요한 보완 조치를 이행
• ‌협력사의 시스템, 제품, 서비스 변경으로 인해 발생할 수 있는 보안 위험을 평가
• ‌협력사 보안 이슈가 확인된 경우, 계약 조건 변경, 개선 계획 요구, 추가 점검 등 조치 시행

---
<!-- Page 195 -->

## 제3장 우주 보안모델 해설  | 195

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
관련 기준
⊙ K-RMF
• ‌SM-1 공급망 보호 : 종합적인 정보보호 전략의 일환으로, 공급망 위협으로부터 시스템을 보호하기 위해
[조직이 지정한 보안 보호조치]를 수행해야 한다.
• ‌SM-1-1 공급망 보호 | 획득 전략/도구/방법 : 공급업체로부터 시스템/구성요소/서비스를 구매하기 위해
[조직이 지정한 획득 전략, 계약 도구, 조달 방법]을 사용해야 한다.
• ‌SM-3 구성요소 위조 방지 :
1. ‌위조된(정품이 아닌) 구성요소가 시스템에 유입되는 것을 탐지하고 예방하는 수단을 포함하는 위조 방지
정책 및 절차를 개발하고 구현해야 한다.

## 2. 위조된 시스템 구성요소를 [조직이 지정한 기관 또는 직책]에게 보고(통보)해야 한다.

⊙ NIS2
• ‌5.1 공급망 보안 정책 : 공급망 보안 정책을 마련·운영하고, 조직의 역할을 공급업체·서비스 제공업체에
명확히 알린다.
• ‌5.2 공급업체·서비스 제공자 디렉토리 : 직접 공급업체 및 서비스 제공업체의 등록부를 유지·관리하고 최신
상태로 갱신하고 관리해야 한다.

---
<!-- Page 196 -->
196 | 우주 보안 모델 해설 및 적용사례집
SM-02
인수 전 평가
항목 내용
시스템/구성요소/서비스의 선정/인수/업데이트 전에 보안취약점 점검 및
조치하고 인수 테스트를 통해 구성요소의 위조를 검사해야 한다.
목적
시스템·구성요소·서비스 도입 및 변경 과정에서 보안 취약점이 사전에
식별·조치되었는지를 검증하여, 취약한 상태의 자산이 운영 환경에 유입되는
것을 방지하기 위함이다.
주요
확인사항
y ‌우주기업은 시스템·구성요소·서비스 선정·인수·업데이트 전에 취약점 점검의
수행 및 조치를 요구하는가?
y ‌우주기업은 인수테스트를 통해 구성요소의 위조를 검사하고 있는가?
세부 설명
⊙ ‌우주기업은 시스템·구성요소·서비스 선정·인수·업데이트 전에 취약점 점검의 수행 및 조치를
요구해야 한다.
▶ ‌우주기업은 시스템, 구성요소 또는 서비스를 선정·도입·업데이트하기 전에 취약점 점검을 수행
• ‌점검 대상에는 직접 구매한 하드웨어·소프트웨어뿐만 아니라, 클라우드 서비스(IaaS, SaaS 등),
외부 개발 소프트웨어, 외주 개발 결과물 등도 포함
• ‌취약점 점검 결과는 문서로 남기고, 인수 또는 도입 여부에 대한 승인 근거로 활용
▶ ‌취약점이 식별된 경우, 조치를 전제로 한 인수·도입 기준 적용
• ‌인수 전에 반드시 조치해야 하는 취약점과 조건부 인수가 가능한 항목을 구분하는 기준을 마련
• ‌취약점 조치가 필요한 경우, 공급업체 또는 개발자에게 패치·설정 변경·업데이트 등을 요구
⊙ ‌우주기업은 인수테스트를 통해 구성요소의 위조를 검사해야 한다.
▶ ‌공급업체가 제공한 하드웨어, 소프트웨어, 펌웨어, 라이브러리가 사전에 합의된 사양 및
산출물과 일치하는지 확인
▶ ‌해시값, 서명 정보, 버전 정보, SBOM 등을 활용해 구성요소의 변경·위조 여부를 점검
▶ ‌취약점 점검 결과에 따라 공급업체에게 요구한 취약점 조치가 실제로 이행되었는지 조치 여부를
확인
• ‌패치 적용, 설정 변경, 보안 기능 보완 등이 실제 시스템에 반영되었는지 점검
• ‌조건부 인수의 경우, 잔여 조치 항목과 기한을 명확히 하고 관리 대상으로 지정
▶ ‌정합성 또는 무결성에 이상이 확인된 경우, 원인 분석 및 시정 조치 전까지 인수를 제한하고, 필요
시 공급업체에 소명 자료 또는 재제공을 요구

---
<!-- Page 197 -->

## 제3장 우주 보안모델 해설  | 197

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
▶ ‌인수 테스트 결과와 잔존 위험은 담당 부서 또는 승인 권한자가 확인
• ‌잔존 위험을 수용하는 경우, 그 판단 근거를 기록
• ‌모든 조치 및 승인 절차가 완료된 이후에만 운영 부서로 최종 인수인계를 수행
관련 기준
⊙ K-RMF
• ‌SM-1-4 공급망 보호 | 선정/인수/업데이트 전 평가 : 시스템/구성요소/서비스의 선정/인수/업데이트
전에 보안평가를 수행해야 한다.
• ‌SM-1-12 공급망 보호 | 약점 또는 결함을 처리하는 프로세스 : 공급망 요소를 대상으로 한 평가 중 식별된
약점, 결함을 처리하는 프로세스를 수립해야 한다.

---
<!-- Page 198 -->
198 | 우주 보안 모델 해설 및 적용사례집
SM-03
모든 출처 정보 사용
항목 내용
시스템/구성요소/서비스의 (잠재적) 공급업체를 대상으로 모든 출처 정보 (all-
source intelligence) 분석을 수행해야 한다.
목적
SBOM을 통해 소프트웨어 구성 요소의 투명성을 확보하고, 신규 취약점 및
공급망 위험을 지속적으로 식별하고 추적·관리하기 위함이다.
주요
확인사항
y ‌우주기업은 시스템/구성요소/서비스를 공급받을 시 소프트웨어 구성 요소
목록(SBOM)을 요구하는가?
y ‌소프트웨어 구성 요소 목록(SBOM)을 활용하여 구성 요소 투명성을 확보하고
지속적으로 관리하는가?
세부 설명
⊙ ‌우주기업은 시스템/구성요소/서비스를 공급받을 시 소프트웨어 구성 요소 목록(SBOM, Software
Bill of Materials) 제출을 요구해야 한다.
▶ ‌시스템·구성요소·서비스 도입 시 공급업체로부터 SBOM 제출을 요구하도록 정책에 명시
▶ ‌SBOM 제출 요구 사항을 계약 조건 또는 발주 문서에 포함
▶ ‌SBOM에는 최소한 다음 정보가 포함되도록 요구
• ‌오픈소스 및 상용 소프트웨어 구성 요소 식별 정보
• ‌구성 요소 명칭, 버전, 라이선스 정보
• ‌의존성 관계(직접·간접 포함 여부)
▶ ‌SBOM 형식은 표준 포맷(SPDX, CycloneDX 등) 중 하나를 사용하도록 요구
▶ ‌신규 도입, 주요 업데이트, 버전 변경 시 SBOM 재제출 요구
▶ ‌SBOM 미제출 또는 불완전 제출 시 도입 보류 또는 보완 요구 절차 정의
⊙ ‌우주기업은 소프트웨어 구성요소 목록(SBOM)을 활용하여 구성 요소 투명성을 확보하고,
지속적으로 관리한다.
▶ ‌제출받은 SBOM을 활용하여 시스템 내 소프트웨어 구성요소 현황 식별·관리
▶ ‌SBOM 정보를 기준으로 사용 중인 구성요소와 실제 설치 상태의 일치 여부를 검증
▶ ‌SBOM에 포함된 구성요소에 대해 보안취약점(CVE, Common Vulnerabilities and
Exposures)을 주기적으로 점검
▶ ‌신규 취약점 공개 시 다음 사항 수행 필요
• ‌해당 취약점이 조직 시스템에 영향을 미치는지 SBOM 기반으로 식별

---
<!-- Page 199 -->

## 제3장 우주 보안모델 해설  | 199

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌영향이 있는 경우 공급업체 조치 여부 및 대응 일정 확인
▶ ‌공급업체의 취약점 조치 미수행 또는 지연 시 추가 대응(패치 요구, 대체 검토 등) 수행
▶ ‌비인가되거나 출처가 불분명한 소프트웨어 구성 요소가 시스템에 포함되지 않도록 관리
▶ ‌SBOM 및 관련 검토 결과를 문서화하여 관리하고, 필요 시 감사·점검 자료로 활용
관련 기준
⊙ K-RMF
• ‌SM-1-5 공급망 보호 | 모든 출처 정보 (all-source intelligence)의 사용 : 시스템/구성요소/서비스의
(잠재적) 공급업체를 대상으로 모든 출처 정보(all-source intelligence) 분석을 수행해야 한다.
⊙ NIS2
• ‌5.2 공급업체·서비스 제공자 디렉토리 : 직접 공급업체 및 서비스 제공업체의 등록부를 유지·관리하고 최신
상태로 갱신하고 관리해야 한다.

---
<!-- Page 200 -->
200 | 우주 보안 모델 해설 및 적용사례집
SM-04
변조/위조 방지 및 탐지
항목 내용
시스템/구성요소/서비스의 변조 및 위조를 방지하기 위하여 주기적으로
점검해야 한다.
목적
공급업체의 개발·배포 과정과 인수·운영 단계에서 무결성을 검증하여 공급망을
통해 발생할 수 있는 위·변조 위험을 식별하고 차단하기 위함이다.
주요
확인사항
y ‌우주기업은 시스템·구성요소·서비스 공급 시, 공급업체의 개발·배포 과정에
위·변조 방지 절차가 포함되어 있는지를 확인하는가?
y ‌우주기업은 인수 및 운영 과정에서 시스템·구성요소·서비스의 무결성을
검증하기 위한 점검 절차를 운영하는가?
세부 설명
⊙ ‌우주기업은 시스템·구성요소·서비스 공급 시, 공급업체의 개발·배포 과정에 위·변조 방지 절차가
포함되어 있는지를 확인한다.
▶ ‌공급업체가 소프트웨어를 개발할 때 형상관리 체계를 운영하는지 확인
• ‌소스코드 변경 이력과 변경 이유가 기록되고 승인되는지 점검
• ‌빌드 및 배포 산출물의 변경 이력이 추적되는지 확인
▶ ‌소프트웨어 배포 전 무결성을 검증하는 절차가 정의·운영되는지 확인
• ‌전자서명, 해시(Hash) 값 생성·검증 같은 무결성 확인 방법이 사용되는지를 확인
• ‌무결성 검증 결과가 문서로 기록되고 보관되는지를 확인
▶ ‌위·변조 발생 시 탐지·보고·대응 절차가 마련되어 있는지 점검
• ‌변조 의심 발견 시 보고체계, 대응조치, 영향범위 평가 절차가 정의되어 있는지 확인
⊙ ‌우주기업은 인수 및 운영 과정에서 시스템·구성요소·서비스의 무결성을 검증하기 위한 점검 절차를
운영한다.
▶ ‌무결성 검증을 위해 공급업체로부터 해시값 또는 전자서명 정보를 받도록 요구
• ‌도입 전 SBOM 또는 릴리즈 정보와 함께 해시값/서명 정보를 제공받도록 계약서 또는 발주서에
반영
• ‌해시값/서명 정보는 릴리즈된 소프트웨어·구성요소의 무결성을 주기적으로 검증하는 기준으로
활용
▶ ‌인수 테스트 또는 운영 중 무결성 점검 절차를 운영
• ‌인수 테스트 단계에서 제공받은 해시값과 실제 설치된 파일의 해시값을 비교 검증

---
<!-- Page 201 -->

## 제3장 우주 보안모델 해설  | 201

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
• ‌주요 업데이트, 패치 적용 시에도 무결성 검증을 수행
• ‌무결성 불일치가 확인된 경우에는 배포 중단, 공급업체 확인 및 수정 요구, 또는 대체 방안 마련
같은 대응 절차를 시행
▶ ‌무결성 검증 결과와 대응 현황을 기록·관리
• ‌무결성 점검 결과는 운영 기록에 남기고, 정상/비정상 여부를 명확히 구분하여 보관
• ‌점검 결과를 바탕으로 위험 판단 및 재발 방지 대책을 수립
관련 기준
⊙ K-RMF
• ‌SM-2-1 변조 방지와 탐지 | 시스템개발 수명주기 단계별 변조 방지 : 시스템개발 수명주기의 여러 단계에
걸쳐 변조 방지 기술과 기법을 적용해야 한다.
• ‌SM-2-2 변조 방지와 탐지 | 시스템, 구성요소 또는 장비의 점검 : 변조를 방지하기 위해 [조직이 지정한
시스템, 구성요소, 장비, 또는 무작위]를 [조직이 지정한 주기 또는 필요한 상황]에 점검해야 한다.
• ‌SM-3-2 구성요소 위조 방지 | 구성요소 서비스 및 수리 간 형상 통제 : [조직이 지정한 구성요소]의 입고
전 형상과 출고 후 형상을 동일하게 유지해야 한다.

---
<!-- Page 202 -->
[오]

---
<!-- Page 203 -->

## 제3장 우주 보안모델 해설  | 203

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
우주 보안모델
적용 사례

## 1. A우주기업 아키텍처 구성요소


## 2. A우주기업 보안취약점 점검 절차


## 3. A우주기업 주요 보안 요구사항


## 4. 보안모델 적용을 통한 기대효과

제 4 장

---
<!-- Page 204 -->
204 | 우주 보안 모델 해설 및 적용사례집
본 장에서는 민간 우주기업을 대상으로한 우주 보안모델 적용 사례를 설명한다. 최근 민간
우주산업이 급성장하고 GSaaS 서비스를 이용하는 소규모 우주기업이 증가되는 반면, 사이버보안
위협은 증가되고 있음에 따라 GSaaS를 제공하는 A우주기업의 보안 취약점 점검을 진행하고
보안대책을 제시하여 보안 수준을 향상시키는데 도움이 되고자 하였다.
제1절
A우주기업 아키텍처 구성요소
점검 대상인 A우주기업은 우주 소프트웨어를 개발 및 공급하는 전문기업으로, 자체 보유하고
있는 위성 안테나와 웹기반의 지상국 플랫폼을 통해 미션 예약 및 운영 서비스를 제공한다.
가. GSaaS 구성요소
A우주기업에서는 GSaaS 아키텍처의 구성요소로 위성 안테나, 예약 및 스케쥴링 시스템,
DB서버가 식별되었으며, 이외 주요 인프라로 미션 운영센터가 식별되었다.

## 제4장

우주 보안모델 적용 사례

---
<!-- Page 205 -->

## 제4장 우주 보안모델 적용 사례  | 205

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
나. 우주 공급망 구성요소
A우주기업은 자체개발을 통해 GSaaS를 제공하고 있으며, 우주 공급망 아키텍처의
코드DB(코드 저장소)가 식별되었고, 이외 주요 인프라로 소프트웨어 개발 PC가 식별되었다.

---
<!-- Page 206 -->
206 | 우주 보안 모델 해설 및 적용사례집
제2절
A우주기업 보안취약점 점검 절차
A우주기업은 자체개발한 GSaaS서비스를 통해 고객사의 민간 인공위성의 미션 예약 및 운영을
서비스하고 있으며, 다음과 같은 절차로 GSaaS와 소프트웨어 공급망 관점에서 관리/물리 영역,
기술 영역의 보안 취약점 점검을 수행하였다.
그림 8
A우주기업 보안 취약점 점검 절차
우주기업 보안환경 조사 단계에서는 우주기업 현황을 분석하고 우주시스템 관련 자산을
파악하였다. 보안취약점 점검 계획을 수립 후 보안점검 단계에서는 우주보안 체크리스트
기반으로 우주보안 수준을 점검하고 서버, 네트워크, 웹 보안 취약점 진단과 공급망 보안 진단을
수행하였다. 보안점검 결과 파악된 보안취약점에 대한 보호대책을 수립하고 향후 수행해야 할
이행과제를 제시하였다.

---
<!-- Page 207 -->

## 제4장 우주 보안모델 적용 사례  | 207

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
제3절
A우주기업 주요 보안 요구사항
우주보안 체크리스트를 기준으로 A우주기업의 GSaaS와 S/W공급망 보안취약점을 점검한
결과 대부분의 영역에서 취약점이 발견되었으며, 발견된 취약점으로 인한 위협 및 보안 요구사항,
이행 조치 사항은 다음과 같다.
가. A우주기업 GSaaS영역 주요 위협 및 보안 요구사항
•AC-08 원격 접근 통제
보안 위협
필요에 의해 외부에서 내부로 접근 시 VPN을 통해 접근하나 외부 단말에
대한 보안 요구사항 감사 및 감시통제가 없어 내부에 네트워크에 접속한
PC에 침해 발생 시 내부로 위협 전파 가능
보안 요구사항
VPN을 통해 외부자 단말이 내부 네트워크 접근 시 단말 보안 현황 점검 및
미흡 시 거부
이행조치
외부 접속 단말에 대해 보안 요구사항 수립, 접속 단말에 대한 보안 강제화는
중/장기 과제로 별도 솔루션 구축 계획 수립 예정
•SC-01 경계보호
보안 위협
웹기반의 GSaaS를 서비스하고 있으나 DMZ영역의 미구축, 망분리 미흡
등으로 인해 IT시스템에 대한 무단 접근이나, 서비스 거부 등의 위협 확인
보안 요구사항
웹서비스를 위한 DMZ영역 구축 및 WAF도입, 네트워크 리디자인, IDS/
IPS구축, 보안 관제 도입
이행조치
업무 인프라(CCTV, VoIP)망에 대한 QoS설정을 통해 해당 서비스로 인한
서비스 거부 위협에 대한 조치를 완료 하였으며, 내부 네트워크에 DMZ영역
구축, 주요 인프라에 대한 망분리, IDS/IPS구축 및 보안 관제 계획은
중/장기 과제로 이행 예정

---
<!-- Page 208 -->
208 | 우주 보안 모델 해설 및 적용사례집
•SC-04 통신보안
보안 위협
방화벽을 사용해 네트워크 트래픽을 통제하고 있으나 일부 과도하게 허용된
정책으로 인해 IT시스템에 대한 무단 접근 및 악성코드 감염 위협 확인
보안 요구사항
방화벽 정책 강화, IDS/IPS구축, 보안 관제 도입
이행조치
위험IP, 도메인 차단, 과도하게 허용된 정책 제거 등 방화벽 정책 강화,
IDS/IPS구축 및 보안 관제 계획은 중/장기 과제로 이행 예정
•SC-06 협업 컴퓨팅 장치
보안 위협
회의실 등 공용공간에서 외부자가 접근 가능한 공용PC에서 내부로
원격접속이 가능하여 IT시스템에 대한 무단 접근 위협 확인
보안 요구사항
공용PC에 대한 접근 통제 강화 및 외부자용 네트워크 분리
이행조치
방화벽 정책 강화로 공용PC 등 외부자 네트워크의 내부 네트워크 접근 차단
•SI-01 취약점 점검 및 결함 교정
보안 위협
취약점 점검 부재로 외부 침입 및 내부 유출 등 보안 위협을 유발하는 취약점
미식별
보안 요구사항
주기적인 보안 취약점 점검
이행조치
본 사업을 통해 취약점 점검 및 조치 계획 수립
•SI-02 악성코드 방지
보안 위협
일부 시스템에 백신설치 누락으로 악성코드 감염 위협 확이
보안 요구사항
내부 전 자산에 백신 설치
이행조치
백신 설치 누락 자산 확인 및 조치 완료

---
<!-- Page 209 -->

## 제4장 우주 보안모델 적용 사례  | 209

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
•PS-02 보안인식 교육 훈련
보안 위협
내부 임직원의 보안인식 교육 훈련 부재로 피싱 등 사회공학적 공격이나
랜섬웨어 등의 공격에 노출
보안 요구사항
주기적인 보안식 제고 교육 및 훈현 시행
이행조치
본 사업을 통해 내부 임직원의 보안 인식이 향상되었으며, 주기적으로
보안인식 제고 교육 및 악성메일 훈련 등 계획 수립 예정
•PE-01 물리적 접근통제
보안 위협
주요 설비에 대해 출입이력 검토 절차가 부재하여 비인가자의 주요 설비
출입 발생 위협 확인
보안 요구사항
서버실 등 주요설비에 대한 출입이력 검토 절차 수립 및 주기적 수행
이행조치
서버실 등 주요설비에 대한 출입이력 검토 절차 수립 및 주기적 수행

- ‌이행조치: 주요 설비를 식별하였으며 검토 절차 수립 중
•SG-01 보안 정책 수립
보안 위협
보안 정책 및 지침에 대해 주기적인 검토 및 개정이 부재하고, 전파되지 않아
내부 임직원의 보안에 대한 인식 부족
보안 요구사항
주기적인 보안 정책 및 지침 검토, 재·개정 및 전파
이행조치
정책, 지침 확인 및 검토, 재·개정 계획 수립 중
•SG-02 보안 역할 및 책임 정의
보안 위협
보안 담당자의 역할 및 책임에 대한 검토 부재
보안 요구사항
주기적인 보안 정책 및 지침 검토, 재·개정 및 전파
이행조치
정책, 지침 확인 및 검토, 재·개정 계획 수립 중

---
<!-- Page 210 -->
210 | 우주 보안 모델 해설 및 적용사례집
•SG-03 자산 관리
보안 위협
우주 관련 주요 자산에 대한 자산평가 부재로 주요 보호대상 자산 미식별
보안 요구사항
우주 관련 자산에 대한 주기적인 자산 현행화 및 자산 평가
이행조치
우주 관련 자산 식별 및 평가 계획 수립 중
•SG-04 법적 요구사항 준수
보안 위협
GSaaS를 서비스하는 과정에서 발생할 수 있는 준거성 검토 부재
보안 요구사항
개인정보 등 웹서비스에서 발생할 수 있는 준거성 검토 및 규정 반영
이행조치
GSaaS에서 발생할 수 있는 법적 준거성 검토 중
나. A우주기업 우주 공급망 영역 주요 위협 및 보안 요구사항
•SO-08 개발 시험 및 평가
보안 위협
GSaaS소프트웨어의 소스코드 보안취약점 점검 및 침투테스트 수행 결과
다수의 보안 취약점이 발견
보안 요구사항
소스코드 검사 도구 도입 및 활용, 주기적인 침투 테스트 수행
이행조치
소스코드 보안취약점 점검 및 침투테스트 결과에 대한 취약점 조치 완료,
주기적인 소프트웨어 보안 취약점 점검 계획 수립 및 소스코드 검사도구
도입은 중/장기 과제로 계획 수립 예정
•SO-09 기능 최소화 및 사용자 설치 소프트웨어 통제
보안 위협
소프트웨어 개발 시 협업을 위해 상용 메신저를 사용하며 별도 소프트웨어
설치에 대한 통제가 미흡하여, 내부 정보 유출 및 악성코드 위협 확인
보안 요구사항
협업이 필요한 업무 부서는 내부에 별도 구축된 협업도구 사용, 소프트웨어
설치에 대한 정책 수립 및 감사
이행조치
외부 상용 메신저에 대한 보안 정책 수립 및 협업 필요 시 내부 그룹웨어
메신저 사용 장려, 보안 인식교육을 통해 비인가 소프트웨어 설치 위험 교육,
외부 상용 메일/메신저 차단은 중/장기 과제로 별도 솔루션 구축 계획 수립
예정

---
<!-- Page 211 -->

## 제4장 우주 보안모델 적용 사례  | 211

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
•SM-02 인수전 평가
보안 위협
소프트웨어 개발 시 오픈소스 라이브러리 사용에 대한 별도 정책이
부재하였고, 특히 GSaaS소프트웨어 개발에 사용되는 오픈소스
라이브러리에서 알려진 취약점이 발견되어 해당 취약점을 이용한
IT시스템이나 애플리케이션의 논리적 손상이 발생할 수 있는 위협 확인
보안 요구사항
개발 프로세스 SDLC 전영역에서 보안 적용, SBOM검사도구 도입 및 활용
이행조치
SBOM검사도구를 사용하여 오픈소스 취약점 조치, 개발 프로세스 보안
적용 및 SBOM검사도구 도입은 중/장기 과제로 구축 계획 수립 예정

---
<!-- Page 212 -->
212 | 우주 보안 모델 해설 및 적용사례집
제4절
보안모델 적용을 통한 기대효과
민간 우주기업을 대상으로 보안취약점을 진단하고 보안대책을 적용한 후 기대효과는 다음과
같다.

---
<!-- Page 213 -->

## 제4장 우주 보안모델 적용 사례  | 213

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
■ 용어
⊙ ‌공격 벡터 (attack vector) : 공격자가 컴퓨터나 네트워크에 침입하기 위해 사용하는 진입
경로와 방법
⊙ ‌공급망(supply chain) : 원재료의 조달에서부터 완제품의 최종 소비에 이르기까지, 재화와
서비스 및 정보의 흐름이 이루어지는 연결망
⊙ ‌다중 인증(MFA) : 최소 두 가지 이상의 인증 요소를 이용하여 본인 여부를 인증하는 것
⊙ ‌방화벽 : 내부 네트워크(또는 시스템)를 보호하기 위해 외부에서 들어오는 트래픽을 사전에
정의한 보안 정책에 따라 허용하거나 차단하는 보안 시스템
⊙ ‌사이버보안 프레임워크(CSF) : 사이버보안 관련 위험을 관리하기 위한 표준, 지침, 모범
사례로 구성된 프레임워크
⊙ ‌서비스 거부 : 시스템 리소스에 대한 허가된 액세스의 방지 또는 중단 또는 시스템 동작 및
기능의 지연
⊙ ‌식별(Identification) : 사람이나 객체의 유일성을 확인하는 절차, 또는 사용자 식별
부호(ID). 식별, 신원 증명, 신원 확인 등의 뜻으로, 패스워드와 함께 다수의 사용자가
이용하는 컴퓨터 시스템이나 통신망에서 정당한 사용자임을 인중받는 절차의 필수요소
⊙ ‌악성코드 : 시스템 또는 사용자에 대한 정보 수집, 시스템 데이터 파괴, 시스템 침입을 위한
발판 마련, 시스템 데이터 및 보고서 위조, 시스템 운영 및 유지 보수 담당자에게 시간을
낭비하는 목적으로 작성된 프로그램 또는 코드
용어 및 약어

---
<!-- Page 214 -->
214 | 우주 보안 모델 해설 및 적용사례집
⊙ ‌암호화 : 암호 키(특정의 비트열)를 사용하여 정보를 암호문으로 변환하는 것
⊙ ‌위협 : 보안을 위반하여 해를 입힐 수 있는 상황, 능력, 행동 또는 이벤트가 있을 때 존재하는
보안 위반 가능성
⊙ ‌인증(Authentication) : 다중 사용자 컴퓨터 시스템 또는 망 운용 시스템에서 시스템이 단말
작동 개시(log-on) 정보를 확인하는 보안 절차
⊙ ‌전자서명 : 서명자의 신원과 서명 사실을 확인하기 위하여 전자문서에 첨부되거나
논리적으로 결합된 전자 형태의 정보. 전자서명은 네트워크를 통해 전달되는 디지털 메시지
또는 문서에 대한 진위성(authenticity), 무결성(integrity), 부인 방지(non-repudiation)
특성을 제공
⊙ ‌접근통제 : 미리 수립된 규칙과 요청자에 관련된 특정 권한 또는 인가에 기초하여 운영자가
자원, 시설, 서비스 또는 정보에 대한 접근을 제한할 수 있는 절차
⊙ ‌중간자 공격 : 통신하고 있는 두 당사자 사이에 끼어들어 당사자들이 교환하는 공개정보를
자기 것과 바꾸어버림으로써 들키지 않고 도청을 하거나 통신내용을 바꾸는 수법
⊙ ‌최소권한 : 사용자 또는 프로세서는 특정 임무를 수행하는 데 필요한 최소한의 제한적인
권한만을 할당받아야 하고 이들 권한은 특정 임무를 수행하는 동안에만 할당되어야 한다는
정보 보호 원칙
⊙ ‌취약점 : 시스템, 소프트웨어 또는 구성요소에 존재하여 공격자가 악용할 수 있는 보안상의
약점
⊙ ‌키 관리 : 보안 정책에 의해 키(key)의 생성, 등록, 인가, 등록 취소, 분배, 설치, 저장, 압축,
폐지, 유도 및 파괴를 감독하는 것
⊙ ‌탑재체(Payload) : 위성의 내부에 위치해 있으면서 부여된 임무를 실제적으로 수행하는
위성의 한 부분
⊙ ‌프로토콜 : 시스템들 간의 어떤 종류의 연관성(예를 들어, 통신)을 구현하고 제어하기 위한
일련의 규약들(즉, 포맷들 및 절차들)
⊙ ‌CMMC : 조직의 사이버보안 성숙도를 평가하기 위한 인증 체계
⊙ ‌GSaaS : 위성통신에 요구되는 안테나와 지상국 인프라를 빌려서 사용하는 서비스
⊙ ‌ISMS-P : 정보보호 및 개인정보보호 관리체계에 대한 국내 인증 제도
⊙ ‌SBOM : SW 구축에 사용되는 다양한 구성요소의 세부 사항과 공급망 관계를 포함하는
공식적인 기록

---
<!-- Page 215 -->
10능
0
ACL
Access
Control
List
제장개요
0
AEAD
Authenticated
Encryption
With
Associated
Data
API
Application
Programming
Interface
0
CCsDs
Consultative
Committee
for
Space
Data
Systems
0
CMMC
Cybersecurity
Maturity
Model
Certification
0
CSF
Cyber
Security
Frameworks
0
CU
Controlled
Unclassified
Information
0
CVE
Common
Vulnerabilities
and
Exposures
0
Cvss
Common
Vulnerability
Scoring
System
이
CWE
-
Commor
Weakness
Enumeration
이
DFARS
:Defense
Federal
Acquisitior
Regulation
Supplement
이
DLP
Data
Loss
Preventior
Dos
Denial
이
Service

## 제3장우주보안모텔해설

0
DRM
Digital
Rights
Management
0
FCI
Federal
Contract
Information
0
GCM
Galois/Counter
Mode
0
GSaas
Ground
Statior
as
Service
HMAC: Hash
based
Message
Authentication
Code
Hypertext
Secure
코부웅보금우국호
이
HTTPS
Transfer
Protocol
O IDS
Intrusion
Detection
System
OP:
nternet
Protocol
O Ips
Intrusion
Prevention
System
O IPsec
Internet
Protocol
Security
0
ISMS-P:
Information
Security
Management
System
Personal
information

## 제4장

우주
적용
사례
1215

---
<!-- Page 216 -->
O JSP
Java
Server
Page
OKP
Key
Performance
Indicator
O K-RMF
Korea
Risk
Management
Framework
오
MDM
Mobile
Device
Management
요
MFA
:Multi-
Factor
Authentication
O MITM
Attack
Man-In-
The-
-Middle
Attack
O Moc: Mission
Operations
Center
이
mTLS
:mutua
Transport
Layer
Security
이
NAC
:
Network
Access
Control
이
NIS2
Network
and [
Information
Security
Directive 2
O NIST
National
Institute
Standards
and
Technology
이
이
NVD
:
National
Vulnerability
Database
OTP
One
Time
Password
P2P
:
Peer-
-to--
-Peer
PAM
Privileged
Access
Management
요
Pcc
Payload
Control
Center
0
RPO
:
Recovery
Point
Objective
있
RTCP
RTP
Control
Protocol
RTO
Recovery
Time
Objective
0
RTP
Real--time
Transport
Protocol
0
SBOM
Software
Bill
이
Materials
0
SDLC
System
Development
Life
Cycle
요
SFTP : Secure
File
Transfer
Protocol
0
SIEM
Security
Information
and
Event
Management
SIP
Session
Initiation
Protocol
216
우주보안모델해설및적용사례집

---
<!-- Page 217 -->

## 제4장 우주 보안모델 적용 사례  | 217

제
1
장
개
요
제
2
장
우
주
보
안
모
델
제
3
장
우
주
보
안
모
델
해
설
제
4
장
우
주
보
안
모
델
적
용
사
례
⊙ ‌SSID : Service Set Identifier
⊙ ‌SSH : Secure Shell
⊙ ‌TCP : Transmission Control Protocol
⊙ ‌TLS : Transport Layer Security
⊙ ‌UPS : Uninterruptible Power Supply
⊙ ‌VLAN : Virtual Local Area Network
⊙ ‌VoIp : Voice over Internet Protocol
⊙ ‌VPN : Virtual Private Network
⊙ ‌WIPS : Wireless Intrusion Prevention System
⊙ ‌XML : eXtensible Markup Language

---
<!-- Page 218 -->
우주 보안모델 해설 및 적용사례집
인   쇄  |  2025 년 12 월
발   행  |  2025 년 12 월
발행처  |  한국인터넷진흥원
(58324) 전라남도 나주시 진흥길 9