# 보안 및 접근 관리(기초)

#### 개요

GNSS(Global Navigation Satellite System)를 운영하고 유지보수하는 과정에서 가장 중요한 고려사항 중 하나는 안전한 시스템 운용이다. GNSS 수신기부터 지상 관제국, 위성 간 링크에 이르기까지 보안 위협은 다양한 경로로 침투할 수 있다. 이때 “보안 및 접근 관리”는 이러한 모든 위협 요소에 대해 사전에 대비하고, 침해 가능성을 줄이며, 유사 시 피해를 최소화하기 위한 일련의 정책·절차·도구를 말한다.

GNSS 시스템에서의 보안은 크게 아래와 같은 구성 요소를 고려해야 한다.

* 무단 접근 방지
* 데이터 위·변조 방지
* 인증 및 권한 부여
* 시스템 무결성 확보
* 재난·재해 대응

이 장(보안 및 접근 관리(기초))에서는 GNSS 운영 및 유지보수 시 요구되는 보안체계와 접근 권한의 기본적인 관리 방안에 대해 다룬다.

#### 물리적 보안

GNSS 운영 환경은 일반적인 IT 환경과 달리 지상국(관제시설), 위성, 중계 링크, 수신기 등 다양한 물리적 구성 요소로 이루어진다. 각 물리적 요소가 보안의 사각지대가 되지 않도록 주의해야 하며, 특히 지상국과 중계 링크는 직접적인 통신·데이터 전송이 이루어지는 핵심 지점이다.

* **지상국(관제시설) 보안** 출입 통제, 감시 카메라, 보안 요원 배치, 및 이중 잠금 장치 등을 통해 무단으로 접근할 수 없도록 설계한다.
* **위성 통신 링크 보안** 우주 환경에서의 통신 채널은 외부 간섭에 취약하다. 고출력 재밍(jamming) 공격 또는 스푸핑(spoofing) 공격이 발생하지 않도록 **암호화 통신 기법**과 **안정된 링크 모니터링 체계**가 요구된다.
* **수신기 단말 보안** 수신기는 일반적으로 이동체나 고정된 인프라에 부착되지만, 그 설치 환경이 상대적으로 열악할 수 있다. 보안 기능을 내장하거나(보안 칩셋, 하드웨어 기반 암호 모듈) 펌웨어 무결성을 유지하여 악의적 펌웨어 변조를 예방해야 한다.

#### 접근 제어 개요

GNSS 시스템 운영에는 다양한 이해관계자(운영자, 유지보수 업체, 연구기관 등)가 접근할 수 있다. 이때 각 사용자의 역할과 권한(Role & Privilege)을 명확히 정의하고, 최소 권한 원칙(Principle of Least Privilege)에 따라 \*\*인증(Authentication)\*\*과 \*\*인가(Authorization)\*\*를 수행해야 한다.

* **인증**: 사용자가 누구인지 확인하는 절차. 예) ID/암호, 2차 인증, 생체인증 등
* **인가**: 인증된 사용자가 어떤 자원과 기능을 사용할 수 있는지 결정하는 절차.

GNSS 시스템에서는 **중앙 집중형 접근 관리**가 많이 사용된다. 예를 들어, 지상 관제국의 서버에 접근할 때 사용자 정보를 일관되게 관리하고, 로그를 중앙 서버에 기록하여 추적 가능하도록 한다.

#### 인증 및 키 관리 기초

보안 통신은 대체로 암호화 키를 기반으로 한다. GNSS 운영에서 여러 사용자 간 민감한 정보를 교환하거나, 시스템 내부에서 명령·제어 메시지를 전송할 때, 기밀성을 유지하기 위해 암호화가 필수적이다.

1. **대칭 키 암호(Symmetric Encryption)**
   * 하나의 키로 암호화와 복호화를 함께 수행
   * 알고리즘 예: AES, SEED 등
   * 키 분배가 어렵고, 사용자 수가 늘어날수록 키 관리가 복잡해진다.
2. **비대칭 키 암호(Asymmetric Encryption)**
   * 공개 키(public key)로 암호화, 개인 키(private key)로 복호화 수행
   * 알고리즘 예: RSA, ECC 등
   * 키 분배는 상대적으로 용이하지만, 연산 속도가 느리고 처리 부담이 크다.

GNSS 운영에서는 지상국-위성 간 정보 교환이나 인증 토큰 전송 등에 비대칭 키 암호 기법이 자주 활용되며, 실제 데이터 전송 시에는 연산 효율이 좋은 대칭 키 암호를 사용하는 하이브리드(Hybrid) 방식을 쓴다.

예를 들어, 하이브리드 방식에서 암호화 세션을 구성할 때 다음과 같은 순서가 가능하다.

$$
\begin{aligned} &\text{1) 지상국이 임의의 세션 키 } k\_s \text{ 를 생성} \ &\text{2) 지상국은 } k\_s \text{ 를 수신 측의 공개 키 } k\_{\text{pub}} \text{로 암호화하여 전송} \ &\text{3) 수신 측은 자신의 개인 키 } k\_{\text{prv}} \text{로 복호화하여 } k\_s \text{ 획득} \ &\text{4) 지상국과 수신 측은 } k\_s \text{를 이용해 대칭 암호로 데이터를 교환} \end{aligned}
$$

이처럼 접근 제어와 함께 강력한 암호 기법을 도입해야 GNSS 시스템 전반의 안전성이 보장될 수 있다.

#### 인증 토큰과 권한 부여 모델

다수의 운영자가 동시에 GNSS 자원에 접근하는 시나리오를 가정해 보자. 사용자별로 접근할 수 있는 GNSS 구성 요소나 기능 모듈이 다를 수 있기 때문에, 별도의 인증 토큰(Access Token)을 발급하고 이에 따라 권한을 부여하는 방법이 일반적이다.

* **토큰 기반 인증(Token-Based Authentication)** 사용자 로그인 후 특정 시간 동안 유효한 토큰이 발급되고, 시스템 접근 시 토큰을 사용하여 인증·인가를 수행한다.
* **권한 부여 모델**
  * **RBAC(Role-Based Access Control)**: 역할(Role)에 따라 권한을 부여
  * **ABAC(Attribute-Based Access Control)**: 사용자 속성(Attribute)에 따라 권한을 설정
  * **위치 기반 접근 제어(Location-Based Access Control)**: GPS 등 위치정보를 결합하여 특정 구역 내 접근만 허용

이러한 토큰 및 권한 부여 모델은 분산된 GNSS 관리 환경에서 중앙관리 서버의 부하를 줄이고, 빠르게 권한을 확인하여 접근을 결정하는 데 유리하다.

#### 감사(Audit) 및 로그 관리

GNSS 운영 환경에서 발생하는 각종 시스템 이벤트, 사용자 접근 및 명령 내역은 **감사(Audit) 및 로그**를 통해 추적 가능해야 한다. 이를 통해 잠재적 보안 위협이나 이상 징후를 조기에 발견하고, 문제가 발생했을 때 원인을 파악할 수 있다.

* **로그 수집 및 저장**
  * 지상국(관제시설), 위성 통신 링크 모듈, 수신기 등에서 발생하는 이벤트를 중앙 서버로 전송
  * 로그의 기밀성·무결성을 확보하기 위해 실시간 암호화 전송을 적용하거나 서명 기반 무결성 검증을 도입할 수 있다.
  * 로그의 보관 주기는 법적·정책적 요구사항을 충족해야 하며, 특정 기간이 지나면 안전하게 폐기한다.
* **로그 분석 및 보안 모니터링**
  * 실시간 모니터링 도구를 통해 로그를 시각화하고, 비정상 접근이나 임계 자원 사용량 급증 등의 패턴을 탐지한다.
  * \*\*침입 탐지 시스템(IDS)\*\*나 **이상 징후 탐지(Anomaly Detection)** 모델을 접목해 자동 분석 기능을 강화할 수 있다.
* **감사 기록 처리**
  * 보안 감사(Audit)를 주기적으로 실시하여 로그 기록의 신뢰성을 점검한다.
  * 로그에 기록된 운영자 계정, 접근 시간, 수행된 명령 내역을 바탕으로 **역추적**이 가능하도록 구성한다.
  * 감사 결과는 운영 보안 정책 개선이나 사용자 권한 재조정을 위한 근거자료로 활용할 수 있다.

#### 접근 통제 정책 수립

GNSS 시스템은 각 부품 간 상호 연계가 복잡하므로, 접근 통제를 위한 정책이 체계적으로 마련되어야 한다. 특히, 운용자 그룹별로 필요한 기능이 다르기에 세부 권한 설정이 중요하다.

* **최소 권한 원칙 준수**
  * 각 사용자에게 업무 수행에 필수적인 권한만 부여
  * 시스템 접근 권한을 부여하기 전, 세부적인 역할(Roles)과 업무 범위를 확인
* **중앙 집중 관리와 위임(Delegation)**
  * 기초 권한 및 그룹 관리는 중앙 서버(예: LDAP, Active Directory 등)에서 일괄 관리
  * 일부 현장 운영자가 제한된 범위 안에서 권한을 재할당(Delegation)할 수 있도록 정책화
* **세션 타임아웃(Timeout)과 재인증(Reauthentication)**
  * 안전하지 않은 세션 방치를 막기 위해 일정 시간 이상 사용이 없으면 자동 로그아웃
  * 중요한 명령(예: 위성 제어 명령) 수행 시 재인증 과정을 거치도록 하여 내부 위협 방지

#### 계정 관리 전략

운영자 계정을 안전하게 운영하기 위해서는 계정 생성, 삭제, 비밀번호 정책, 접근 이력 관리 등 전 과정에 엄격한 통제가 적용되어야 한다.

* **계정 라이프사이클(Lifecycle) 관리**
  * 신규 운영자 입사 시 계정 생성, 조직 이동 또는 퇴사 시 계정 삭제·권한 철회
  * 외부 협력사(하청) 직원 계정은 일정 기간이 지나면 자동으로 접근이 종료되도록 설정
* **비밀번호 정책 강화**
  * 8자리 이상, 대·소문자/숫자/특수문자 조합 등 복잡성 요구
  * 주기적 변경, 최근 사용 이력 제한 등을 통해 반복 재사용 금지
  * 가능하면 OTP(One-Time Password), 스마트카드, 생체인증 등 다중요소 인증(MFA) 도입
* **계정 공유 금지**
  * 여러 운영자가 하나의 계정을 공유할 경우 추적과 감사가 어려워진다.
  * 시스템 수준에서 다중 로그인 시도를 감지하여 경고하거나 차단 가능하도록 설정

#### 침해 사고 대응(기초)

실시간 방어와 사후 대응 체계를 구축함으로써, GNSS 운영 환경에서 발생할 수 있는 다양한 보안 사고에 효과적으로 대처할 수 있다.

1. **침해 징후 확인**
   * 로그 및 모니터링 시스템에서 비정상적인 접근, 과도한 명령 시도, 통신 패킷 이상 등을 빠르게 파악
   * IDS(침입 탐지 시스템)나 IPS(침입 방지 시스템) 등을 통해 사전에 차단
2. **사고 대응 프로세스**
   * **초기대응**: 문제가 발생한 계정을 즉시 차단하거나 공격받는 시스템을 네트워크에서 분리
   * **원인분석**: 로그·감사 기록을 근거로 사고 원인, 공격 경로, 취약점 조사
   * **복구방안 수립**: 해당 취약점 패치, 구성 수정, 운영 정책 재검토 등
3. **보고 체계 확립**
   * 상급 기관 또는 주무 기관에 사고 내용을 신속히 보고하고, 공유된 가이드라인(법규, 기술 표준)에 따라 조치
   * 동일·유사 공격 재발을 막기 위해 보안 공지(Security Bulletin) 발행

#### 취약성 평가와 모의 해킹

GNSS 시스템은 전통적인 IT 인프라와는 달리, 지상국과 우주 자산(위성) 간 상호작용이 많으며 대규모 네트워크 트래픽을 수반한다. 따라서 \*\*취약성 평가(Vulnerability Assessment)\*\*와 \*\*모의 해킹(Penetration Test)\*\*은 GNSS 특성을 고려해 전문적으로 수행돼야 한다.

* **평가 대상 선정**
  * 지상국 통신 장비, 위성 접속 게이트웨이, 데이터 센터, GNSS 네트워크 내부 라우터 등
  * 클라이언트(수신기 측) 보안성 검토
* **평가 방법**
  1. **자동화 스캐너**: 알려진 취약점(예: CVE)에 대해 빠른 진단
  2. **수동 분석**: 전문가가 프로토콜, 암호화 구현, 네트워크 아키텍처를 심층 점검
  3. **물리적 보안 점검**: 지상국 시설, 케이블 배선, 출입 제한 구역 실제 방문 점검
* **모의 해킹 절차**
  1. **사전 준비**: 범위 정의, 테스트 시나리오 확립, 사후 보고 계획 수립
  2. **공격 단계**: 사회공학 기법, 네트워크 취약점 공격, 무선 주파수 간섭 시도 등
  3. **결과 보고**: 발견된 취약점 및 공격 가능 경로, 개선 방안 제시

GNSS 운영 환경에서 취약성 평가와 모의 해킹을 정기적으로 수행하면, 잠재적 위험 요소를 사전에 파악하고 대응력을 높이는 데 큰 도움을 준다.

#### 보안 아키텍처 수립

GNSS 운영 환경에서 보안 아키텍처를 수립한다는 것은 시스템 전반에 걸쳐 발생할 수 있는 위협을 식별하고, 이에 대응하기 위한 보호 대책을 유기적으로 배치하는 과정을 의미한다. 이를 위해 각 구성 요소(위성, 지상국, 통신 링크, 사용자 단말)에서 필요한 보안 요구사항을 도출하고, 상호 작용 방식에 대한 **종합적인 설계**가 필요하다.

* **구역(segment) 분리** 물리적·논리적 망 분리를 통해 핵심 자산(예: 관제 서버)과 일반 자산(예: 사용자용 웹 포털)을 격리한다. VLAN, 방화벽, 게이트웨이 장비 등을 활용해 **네트워크 구역**을 나누고, 구역 간 접근 정책을 엄격히 설정한다.
* **트러스트 바운더리(Trust Boundary) 설정** 서로 다른 신뢰 수준을 가진 시스템 간 데이터를 주고받을 때, 경계 지점에서 보안장치를 추가해 무단 접근이나 정보 유출을 방지한다. 예를 들어, 지상국과 외부 인터넷이 연결되는 구간은 가장 취약한 구역 중 하나이므로 IDS/IPS, 웹 방화벽 등 다중 보안 계층을 배치한다.
* **암호화 계층 설계** GNSS 운영에서 전송되는 주요 데이터(제어 명령, 모니터링 메시지 등)에 대해 계층별로 적절한 암호화를 적용해야 한다.
  * 링크 계층 보안: 위성-지상국 간 무선 신호 구간을 보호
  * 애플리케이션 계층 보안: 명령·제어 메시지를 별도 프로토콜(TLS 등)로 보호
* **권한 관리 매트릭스** 사용자 및 시스템 컴포넌트 간 권한 관계를 체계적으로 정의하기 위해 **매트릭스(Matrix) 기반 접근**을 활용할 수 있다. 예를 들어, 아래와 같은 권한 할당 행렬을 생각해 보자.

$$
\mathbf{M}*{\text{role-perm}} =  \begin{bmatrix} m*{11} & m\_{12} & \cdots & m\_{1p} \ m\_{21} & m\_{22} & \cdots & m\_{2p} \ \vdots & \vdots & \ddots & \vdots \ m\_{r1} & m\_{r2} & \cdots & m\_{rp} \end{bmatrix}
$$

위 행렬에서 mijm\_{ij}는 특정 역할(role) ii가 권한(permission) jj를 가졌는지 여부(1 또는 0)를 나타낸다. 이를 기반으로 실제 사용자에게 부여할 최종 권한을 결정한다.

#### 교육 및 보안 인식

GNSS 보안은 기술적 대책만으로 완벽히 달성하기 어렵다. 운영자, 관리자, 협력사 직원 등 **사람**이 참여하는 모든 프로세스에서 \*\*보안 인식(Awareness)\*\*이 높아져야 한다.

* **보안 교육**
  * 계정 관리, 암호 정책 준수, 출입 통제 절차 등 실무적 내용을 주기적으로 교육
  * 긴급 상황(침해 사고, 재밍·스푸핑 발견 등)에서의 대응 절차를 시나리오 기반으로 훈련
* **정책 공지 및 공유**
  * 최신 보안 정책 및 지침을 사내 포털, 이메일, 전용 게시판 등을 통해 빠르게 전달
  * 현장 운영자에게는 오프라인 문서 및 브리핑 세션을 통해 재교육
* **사회 공학 공격 예방**
  * 피싱, 스피어 피싱, 전화 사기 등의 공격 기법을 숙지하고 의심 사례를 즉시 보고하도록 안내
  * USB, 외장하드 등 이동식 매체 사용에 대한 위험성과 안전 수칙 고지

#### 표준 및 규정 준수

GNSS 운영을 담당하는 국가 기관이나 국제 기구에서는 특정 보안 규격, 표준, 준수사항을 요구하는 경우가 많다. 이는 GNSS 신뢰성을 국제적으로 보장하기 위한 최소 요건이 되기도 한다.

* **ISO/IEC 27001 시리즈** 정보보안 관리체계(ISMS) 도입 시 주로 참조되는 국제 표준이며, 조직의 보안 정책, 물리·논리적 통제, 운영 절차 등이 체계적으로 정립되어야 한다.
* **국가별 보안 지침**
  * 미국의 FIPS(Federal Information Processing Standards), NIST 가이드라인
  * 유럽의 ENISA(European Union Agency for Cybersecurity) 지침
  * 국내의 KISA 가이드라인, 국가보안기술연구소(NSR) 기준
* **제3자 심사와 인증**
  * 주요 GNSS 시설(관제국, 데이터 센터 등)에 대해 외부 기관 인증을 획득함으로써 안전성을 공식적으로 검증
  * 정기 심사를 통해 최신 보안 요구사항 반영 여부를 확인하고, 미흡 사항 개선

아래는 단순화된 형태의 GNSS 보안 아키텍처 개념도를 다이어그램으로 표현한 예시다.

{% @mermaid/diagram content="flowchart LR
A\[지상국 관제 서버] -->|권한 인증| B\[보안 게이트웨이]
B -->|암호화 채널| C\[위성 통신 링크]
C --> D\[위성]
D --> C
B -->|VPN or 전용선| E\[외부 연동 시스템]
A -->|내부망| F\[운영/분석 스태프]" %}

#### 운영 절차 수립

GNSS 운영 환경에서의 보안은 “무엇을, 어떻게, 언제” 수행해야 하는지 명확히 정의된 절차를 마련함으로써 체계적으로 달성할 수 있다. 주요 운영 절차는 다음과 같은 항목을 포함할 수 있다.

* **운영 준비 단계**
  * 운영인력, 장비, 네트워크 상태 등을 점검하고 시스템 무결성을 보장할 수 있는 사전 절차 수행
  * 배포 전 소프트웨어, 펌웨어 업데이트 상태 검사
  * 운영자 계정 점검, 임시 계정 사용 여부 파악
* **정기 운영 단계**
  * 통상적인 GNSS 관제 업무(위성 궤도·상태 모니터링, 데이터 분석 등) 진행 시 발생하는 모든 보안 관련 활동을 체크리스트로 관리
  * 시스템 및 네트워크 자원 사용량 모니터링, 접근 권한 검수, 보안 패치 적용 주기 점검
  * 현장 이슈(기상 악화, 임시 장애 등)에 따른 임시 조치 및 기록
* **장애 및 긴급상황 대응 단계**
  * 비정상 징후 탐지 시 사고 유형별로 즉시 시행해야 하는 대응 조치를 매뉴얼로 마련
  * 사고 처리 후 **사후 분석(Post-incident Review)** 단계에서 원인 규명, 추가 보안 강화 방안 도출
  * 대응 과정에서 수집된 로그, 이벤트 기록 등을 중앙 보안 담당 부서와 공유
* **관리 문서화**
  * 모든 운영 절차는 문서화하여(문서 버전 관리 포함) 변경 이력과 승인 과정을 투명하게 관리
  * 운영 매뉴얼, 보안 정책, 비상연락망 등의 문서를 주기적으로 업데이트

#### 비상계획(Disaster Recovery Plan)

GNSS 운영 중 예기치 못한 천재지변, 시스템 장애, 사이버 공격 등이 발생할 수 있으므로, **비상계획**(DRP, Disaster Recovery Plan)을 준비해야 한다. 이는 필수 운영 서비스를 빠르게 복구하고, 중단 시간(Downtime)을 최소화하기 위한 일련의 행동 지침이다.

* **재해 유형별 시나리오**
  * 자연재해(태풍, 지진, 화재 등), 인적 재해(운영 실수, 파업 등), 사이버 공격(랜섬웨어, DDoS 등) 등에 대해 각각 다른 복구 전략을 세운다.
  * 지상국 이원화(Hot Site, Warm Site), 데이터 백업 장소 분산, 중복 위성 채널 확보 등 물리적·논리적 대비책을 마련
* **복구 목표(RTO, RPO) 설정**
  * RTO(Recovery Time Objective): 시스템을 복구하는 데 걸리는 목표 시간
  * RPO(Recovery Point Objective): 데이터 유실 허용 기준 시점
  * GNSS 시스템은 위치정보의 실시간성이 중요하므로, 복구 목표를 엄격하게 설정해야 한다.
* **복구 절차 테스트**
  * 정기적으로 DR 시나리오에 따른 모의훈련(Penetration Test와는 별개)을 진행하여, 실제 재해 발생 시 대응이 가능한지 확인
  * 테스트 결과를 바탕으로 DR 계획의 문제점을 보완하고, 장비·소프트웨어·인력 자원을 지속적으로 확보

#### 지속적 보안 개선

GNSS 시스템은 운영 기간이 길수록 다양한 형태로 확장·변경될 가능성이 높다. 이 과정에서 신규 취약점이나 운영 상의 맹점이 발생할 수 있으므로, \*\*지속적인 보안 개선(Cybersecurity Continuous Improvement)\*\*이 필요하다.

* **형상관리(Configuration Management)**
  * 각 구성 요소(서버, 네트워크 장비, 위성 모듈 등)의 버전, 설정값 변경 이력 등을 기록·관리
  * 변경 시마다 보안 영향도를 평가하고, 문제가 없음을 확인한 뒤 프로덕션 환경에 반영
* **자동화된 보안 패치 적용**
  * 운영 체제, 애플리케이션, 펌웨어 등에 대한 패치가 발표되는 즉시 검토하고, 우선순위에 따라 자동화된 패치 프로세스를 적용
  * 패치 전 사전 테스트 환경(스테이징)에서 문제가 없는지 확인 후 실제 환경에 반영
* **취약점 공개 제도(Bug Bounty 등)**
  * 외부 보안 연구자나 화이트해커가 GNSS 시스템의 취약점을 발견했을 때, 공식 채널을 통해 제보하고 합당한 보상(Bug Bounty)을 제공
  * 이를 통해 무책임한 제보나 악용을 막고, 취약점 발견 및 조치 속도를 높인다.

#### 보안 전문인력 양성

GNSS의 특수성(항공우주, 전파, 네트워크, 소프트웨어 등)이 결합된 상황에서 보안을 책임지는 전문 인력 확보가 중요하다. 단순히 일반 IT 보안 지식만으로는 부족하며, GNSS 자체 프로토콜·표준에 대한 이해가 필요하다.

* **내부 양성 프로그램**
  * GNSS 이론, 위성 통신 기초, 암호학, 네트워크 보안, 운영 체제 보안 등을 포괄하는 사내 교육 커리큘럼 운영
  * 중급·고급 엔지니어를 대상으로 보안 인증(CISSP, CISA 등) 취득 비용 지원
* **외부 전문기관 협업**
  * 국가 연구소(항공우주연구원, 국방과학연구소 등) 또는 대학, 민간 보안 기업과 협력해 최신 기술 공유
  * 정기 세미나, 워크숍 참여를 통해 GNSS 보안 동향, 위협 트렌드 파악
* **지식 공유 문화 장려**
  * 조직 내부에 보안 위키(Wiki)나 지식 베이스를 마련해 이슈 사례, 해결 팁, 모범 사례 등을 공유
  * 사소한 보안 질문도 자유롭게 공유할 수 있는 분위기 조성 (예: 사내 포럼, 메일링 리스트)

#### Zero-Trust 접근 모델

전통적인 경계 기반 보안 모델(내부망은 신뢰, 외부망은 불신)과 달리, **Zero-Trust 접근 모델**은 내부·외부 구분 없이 모든 접근에 대해 신뢰 수준을 동적으로 평가한다. GNSS 운영 환경에서도 점차 지상국, 위성, 외부 연동 서비스, 원격 접속자 등 접근 경로가 복잡해지고 있어, Zero-Trust 개념이 유효하다.

* **항상 검증(Always Verify)** 시스템 간 트래픽이라 하더라도 암호화된 채널, 동적 권한 검증 등을 요구하며, “한 번 접속 승인 후 모든 서비스 이용 가능”과 같은 단일 신뢰 정책을 지양한다.
* **세분화(Segmentation)와 마이크로 퍼리미터(Micro-Perimeter)** 내부망을 여러 소규모 세그먼트로 쪼개서, 각 세그먼트 간 접근 시에도 반드시 인증·인가 과정을 거친다. GNSS 지상국 내부에서조차 위성 통신 서버, 데이터 분석 서버, 일반 관리 서버 간에 독립된 보안 경계를 설정할 수 있다.
* **상태 기반 의사결정(Context-Aware Access)** 단순히 사용자 계정 정보뿐 아니라, 위치 정보, 접속 기기의 무결성 상태, 시간대, 네트워크 환경 등 **컨텍스트**를 고려해 접근을 동적으로 허용·차단한다. 예를 들어, 지상국 관리자 계정이라도 이례적인 시간대나 알 수 없는 위치에서 접근을 시도하면, 추가 인증이나 접속 차단 조치를 취할 수 있다.

#### GNSS 데이터 신뢰성 검증

GNSS 환경에서 주고받는 데이터(위성 궤도 정보, 시간 동기화 정보, 상태 모니터링 데이터 등)가 위·변조 없이 전달되는지 검증하는 것은 매우 중요하다.

* **디지털 서명(Digital Signature)**
  * 지상국에서 송신하는 중요 데이터에 대해 개인 키를 사용해 서명하고, 수신 측은 해당 공개 키로 서명을 검증한다.
  * 서명 알고리즘에는 RSA, ECDSA, EdDSA 등이 사용될 수 있으며, 서명 검증 실패 시 데이터 위·변조 가능성을 의심해야 한다.
* **메시지 인증 코드(MAC)**
  * 전송 중 데이터가 변경되지 않았음을 확인하기 위해, 송신 시 대칭 키 기반의 MAC 값을 생성해 전송하고, 수신 시 동일한 키로 검증한다.
  * 예: HMAC-SHA256, CMAC-AES 등
* **해시(Hash) 기반 무결성 점검**
  * 시스템 내부 파일 무결성 검사를 위해 해시(예: SHA-256)를 사전에 저장해 두고, 일정 주기로 비교 검사한다.
  * 지상국 운영 소프트웨어, 위성 관리용 펌웨어 등 핵심 파일에 대해 위·변조가 발생하면 해시 값이 달라진다.

#### 위성통신 채널 보안

GNSS 시스템 특성상 위성과 지상국 간 무선 통신이 핵심 경로이므로, **채널 보안** 확보가 필수적이다.

* **재밍(jamming) 및 스푸핑(spoofing) 방어**
  * 재밍은 높은 출력의 전파로 GNSS 신호를 방해하는 공격 기법이며, 스푸핑은 거짓 GNSS 신호(위치·시간 정보를 변조한 신호)를 전송해 수신기를 속이는 기법이다.
  * 이를 방지하기 위해 **주파수 도약(frequency hopping)**, **스펙트럼 확산(spread spectrum)** 등 무선 물리 계층 보안 기술을 사용하거나, **암호화된 신호**(예: 군용 GPS의 M-code) 방식을 도입하기도 한다.
* **양자내성 암호(Quantum-Resistant Cryptography) 고려**
  * 양자 컴퓨터 기술 발전에 대비해, GNSS 시스템과 위성 간 통신 채널에서 양자컴퓨터 공격에도 안전한 암호 알고리즘 사용을 검토한다.
  * 예: Lattice-based, Code-based, Multivariate-based 등 PQC(Post-Quantum Cryptography) 알고리즘
* **무결성 확보를 위한 중복 경로(Diversity)**
  * 위성과 지상국 간 동일 주파수나 동일 링크만 사용하면 특정 대역 재밍에 취약해진다.
  * 이중·삼중 링크(주파수 대역 분산), 지상 중계국 다중화 등을 통해 한 경로가 공격을 받아도 다른 경로로 통신 가능하도록 설계한다.

#### GNSS 보안 거버넌스와 조직구조

조직 규모가 커질수록 GNSS 운영에서 보안 관련 의사결정과 업무 분장을 명확히 해야 한다. 이를 \*\*보안 거버넌스(Security Governance)\*\*라 하며, 일반적으로 다음과 같은 구조를 가진다.

* **보안 책임자(CISO, CSO 등)** GNSS 운영에 관련된 전반적인 보안 전략 및 목표를 수립하고, 예산 및 인력을 관리한다.
* **운영팀(Operations)**
  * 실제 GNSS 지상국, 위성 운영, 데이터 센터 관리 업무를 수행
  * 계정 관리, 보안 설정, 장비 점검 등 일상적 보안 과업 담당
* **보안팀(Security Team)**
  * 취약점 평가, 침해 사고 분석, 로그 모니터링, 규정 준수 등을 전문적으로 수행
  * 운영팀과 협력하여 사고 대응 프로세스를 주도하고, 필요한 기술·솔루션을 검토·도입
* **감사팀(Audit/Compliance)**
  * 보안 정책 준수 여부, 법적·규제적 요구사항 충족 여부를 감시·평가
  * 외부 심사 기관과 소통하며, 내부 감사 결과를 문서화·보고

조직 구조는 각 GNSS 운영 기관(정부, 민간 등)의 특성에 따라 달라질 수 있지만, 위와 같이 **전략→운영→기술지원→감사**의 흐름이 분명히 잡혀 있어야 한다.