# 데이터 아카이빙 및 보안 고려

#### GNSS 데이터 아카이빙 개요

GNSS 데이터를 처리한 뒤에는 이를 안전하게 저장하고, 필요 시 신속하게 다시 꺼낼 수 있도록 체계적인 아카이빙(archiving) 절차가 필수적이다. GNSS 데이터는 원시 관측 데이터(예: RINEX 형식)에서부터 보정·해석이 가해진 결과 데이터까지 다양하게 존재한다. 이러한 데이터는 용량이 방대할 뿐 아니라 재활용 가치가 높으므로, 보관 중에도 무결성과 접근 통제가 엄밀히 이뤄져야 한다.

GNSS 데이터가 아카이빙되는 주요 이유는 다음과 같다.

* **장기간 추적 및 분석**: 시간에 따른 위성 신호 품질 및 지상국 상태 등을 장기 추적하기 위해, 과거의 원시 데이터가 필요하다.
* **추가 후처리**: 새로운 알고리즘이 개발되면 과거 데이터를 재처리하여 추가적 정보(예: 정밀궤도 결정, 전리권·대류권 모델링 개선 등)를 얻을 수 있다.
* **재현성(reproducibility) 보장**: 학술 연구나 기술 검증에서는 이미 발표된 결과를 다시 재현하기 위해 해당 시점의 원시 데이터가 필수적이다.
* **안전 및 감사(audit)**: GNSS 기반 위치 정보에 대한 이력 추적 및 보안상 감사 기록이 필요한 경우, 모든 데이터를 일정 기간 이상 보관해야 한다.

#### 데이터 백업 전략

GNSS 데이터의 특성상 단순히 보관하는 것만으로 끝나지 않는다. 전 세계 다양한 관측소에서 실시간으로 수집되는 데이터는 시시각각 새로운 파일이 생성되고, 이미 저장된 데이터는 해당 기간의 다른 파일들과 함께 재가공될 수 있다. 이때 적절한 백업 전략이 필수적이다.

* **주기적 백업**: 하루 단위, 주 단위, 월 단위 등으로 구분하여 서로 다른 스토리지 장치나 원격지 서버에 중복으로 데이터를 백업한다.
* **증분 백업 및 누적 백업**: GNSS 데이터는 시계열적으로 증가하므로, 하루 단위 데이터만 새롭게 저장하는 증분 백업(incremental backup)과, 주·월 단위로 전체 데이터의 누적 백업(cumulative backup)을 병행한다.
* **여러 지점 분산 저장**: 지리적으로 떨어진 물리적 장소에 백업을 함으로써, 자연재해·화재·보안 사고 등으로부터 데이터를 보호한다.

#### 장기 보존 방안

GNSS 데이터는 일반적으로 단순 보관 기간이 수년, 길게는 수십 년 이상이 될 수 있다. 이때 스토리지 미디어의 교체 주기, 파일 포맷의 호환성, 메타데이터 관리 등을 종합적으로 고려해야 한다.

* **아카이빙 미디어 선정**: HDD, SSD, 광학 디스크(예: Blu-ray), 테이프 라이브러리 등 다양한 저장 매체 중 필요한 용량·비용·안정성을 고려해 결정한다.
* **파일 형식 표준화**: RINEX 등이 국제 표준으로 널리 쓰이지만, 향후 분석 도구 또는 운영체제 환경이 바뀔 가능성을 고려하여 별도 메타 정보를 함께 보관한다.
* **메타데이터 관리**: 파일 제목·작성 날짜·관측소 위치·사용 장비 등 필수 메타 정보를 함께 저장하고, 데이터베이스에 색인(index)을 구축해 둔다.

#### 보안 취약점 진단

데이터 아카이빙 과정에서 발생할 수 있는 보안 취약점은 크게 외부 공격과 내부 유출로 나눌 수 있다. GNSS 데이터 자체가 민감 정보가 아닐 수도 있지만, 특정 군사용 또는 민감한 산업 데이터가 포함된 경우에는 고도화된 보안 체계를 갖춰야 한다.

* **네트워크 침투 공격**: 외부에서 원격 접근을 통한 데이터 탈취, 변조를 시도할 수 있다.
* **내부 권한 남용**: 내부 사용자가 무단으로 데이터에 접근하거나, 권한을 초과하여 데이터를 추출·변경할 수 있다.
* **악성 코드 감염**: 백업 서버 혹은 스토리지 시스템이 악성 코드에 감염되면, 대량의 데이터가 손실 또는 암호화될 수 있다(예: 랜섬웨어).

#### 데이터 암호화 기법

민감한 GNSS 데이터를 안전하게 보관하기 위해서는 데이터 암호화 기법을 적용하는 것이 좋다. 예를 들어 대량의 GNSS 원시 파일을 보관할 때 다음과 같은 암호화를 고려할 수 있다.

* **대칭 키 암호화**: 하나의 비밀 키 $\mathbf{k}$를 사용해 데이터를 암호화·복호화한다. 예를 들어,

  $$
  \mathbf{C} = E(\mathbf{k}, \mathbf{P})
  $$

  여기서 $\mathbf{P}$는 평문(plain text) 데이터를, $\mathbf{C}$는 암호문(cipher text)을 나타낸다. 대칭 키 방식은 처리 속도가 빠르지만, 키 관리가 까다로울 수 있다.
* **비대칭 키 암호화**: 공개 키 $\mathbf{K}*{\text{pub}}$와 개인 키 $\mathbf{K}*{\text{priv}}$ 한 쌍으로 데이터를 암호화·복호화한다.

  $$
  \mathbf{C} = E(\mathbf{K}*{\text{pub}}, \mathbf{P}), \quad \mathbf{P} = D(\mathbf{K}*{\text{priv}}, \mathbf{C})
  $$

  대칭 키와 달리 키 분배가 상대적으로 용이하지만, 처리 속도가 느린 단점이 있다.
* **하이브리드 암호화**: 대칭 키와 비대칭 키 기법을 결합하여, 암호화 수행 자체는 대칭 키 방식으로 하고(속도 확보), 그 대칭 키를 안전하게 배포하기 위한 용도로 비대칭 키를 사용하는 방식이다.

#### 접근 제어와 권한 설정

GNSS 데이터에 대한 접근은 엄격하게 통제되어야 하며, 사용자 혹은 시스템 역할(role)에 따라 다단계 권한 설정이 필요하다.

* **인증(authenticaton)**: 사용자나 시스템이 합법적인 접근 주체인지 확인한다. 예: ID/PW, 2FA(이중 인증), 인증서 기반 로그인 등.
* **인가(authorization)**: 인증 이후, 각 사용자별로 접근 권한을 부여한다. 예: 읽기 권한, 쓰기 권한, 수정 권한, 삭제 권한을 구분한다.
* **로그 및 감사 기록**: 누가 언제 어떤 데이터에 접근·수정·삭제했는지 상세 기록을 남긴다.

#### 무결성 검사와 검증 절차

GNSS 데이터가 장기간 보관될수록, 파일 손상이나 불법 변조가 발생할 가능성이 있다. 이를 방지하고, 만약 발생하더라도 조기에 식별하기 위해서는 정기적인 무결성 검사가 필요하다.

* **해시 함수 활용**: 예를 들어, 데이터 $\mathbf{d}$에 대해 해시 함수 $H(\mathbf{d})$를 계산해 보관해 둔다. 나중에 다시 $H(\mathbf{d})$를 계산해서 기존 값과 비교했을 때 다른 결과가 나오면 파일이 변조되었거나 손상된 것으로 간주할 수 있다.
* **디지털 서명**: 중요한 GNSS 결과 데이터에는 생성 시점에 디지털 서명을 부여하여, 누가 언제 이 결과를 만들었는지 추적이 가능하도록 한다.
* **버전 관리**: 동일 데이터에 변경 사항이 발생할 때마다 버전을 부여하여, 필요 시 이전 버전으로 되돌릴 수 있도록 한다.

#### 위변조 탐지와 증거 보존

데이터 변조나 삭제가 발생하면, GNSS 측정치 또는 분석 결과가 왜곡되어 이후 연구나 시스템 운용에 심각한 영향을 줄 수 있다. 이를 감지하고, 의도적인 파괴 행위에 대한 증거를 확보하기 위해 다음과 같은 방법을 활용한다.

* **침입 탐지 시스템(IDS)**: 실시간으로 네트워크 트래픽과 파일 변경 이력을 감시하여, 이상 징후가 감지되면 관리자에게 즉시 통지한다.
* **포렌식용 로그 보존**: 만약 사건이 발생했을 때 사후 분석이 가능하도록, 시스템 로그를 별도로 안전하게 보관한다.
* **데이터 중복 저장**: 해커나 내부자가 특정 파일을 훼손하더라도, 다른 위치에 안전하게 복제된 파일이 존재하도록 설계한다.

#### 규정 준수와 표준

GNSS 데이터는 활용 분야에 따라 다양한 법적·기술적 규제 혹은 국제 표준을 충족해야 할 수 있다. 특히 공공안전, 군사, 항공 등 민감 분야에서 사용되는 데이터는 더 엄격한 준수 요건이 부과된다.

* **국가별 보관 기간 규정**: 특정 국가에서는 주요 데이터(위치 정보 등)에 대해 최소 몇 년 이상 보관하도록 법령으로 정해놓는 경우가 있다. 이때 GNSS 데이터 역시 해당 범주에 포함될 수 있다.
* 개인정보 보호 규정: GNSS 데이터가 개인 위치 정보와 연결되는 경우, 개인정보 보호법 혹은 GDPR 등 국제 규정을 준수해야 한다.
  * 예: 위치 식별이 가능한 원시 데이터를 일정 기간 이후 익명화(또는 가명화) 처리하여 개인 식별이 불가능하도록 해야 한다.
* **ISO 27000 시리즈**: 정보 보안 경영 시스템(ISMS)을 수립하기 위해 ISO/IEC 27000 계열 표준을 참고할 수 있다. GNSS 데이터 아카이빙 환경에서도 자산 식별, 위험 평가, 통제 방안 등이 표준 가이드라인에 부합하도록 설계해야 한다.
* **기관별 표준**: 예를 들어, IGS(International GNSS Service) 표준에 맞추어 관측 파일을 구조화하고 전송 규약을 준수함으로써, 국제 데이터 교환과 재활용성을 높일 수 있다.

#### 보안 정책 수립 및 운영

GNSS 데이터 아카이빙이 안정적으로 이뤄지려면, 명확한 보안 정책이 제정·시행되어야 한다. 이는 단순한 기술적 보호 조치를 넘어, 조직 전체 수준의 보안 문화와 운영 절차를 포함한다.

* **정책 문서화**: 아카이빙 대상 데이터의 종류, 보관 기간, 암호화 방식, 백업 주기, 접근 권한, 감사 기록 방법 등을 명시한 문서를 작성하고 주기적으로 업데이트한다.
* **역할 기반 접근 통제(RBAC)**: 모든 사용자에게 동일한 권한을 부여하는 것이 아니라, 직무나 프로젝트별로 필요한 최소 권한만을 부여한다.
* **보안 교육 및 훈련**: 담당자들에게 정기적으로 보안 교육을 실시하고, 모의 해킹이나 내부 유출 시나리오를 통해 실제 상황에 대비한다.
* **점검 및 감찰**: 정해진 주기(분기별·반기별 등)로 아카이빙 시스템에 대한 보안 점검을 시행하고, 필요 시 외부 전문 기관의 감사를 활용한다.

#### 데이터 거버넌스 및 감사 체계

데이터 거버넌스(governance)는 조직 내 데이터가 생성·보관·사용되는 전 과정을 체계적으로 관리하는 것을 의미한다. GNSS 데이터의 특성상 다양한 부서나 외부 기관이 관여할 수 있으므로, 명확한 거버넌스 모델이 필요하다.

* **소유권(ownership) 명확화**: 어떤 부서(또는 기관)가 해당 데이터의 ‘소유자’로서 책임을 지는지 사전에 결정한다. 소유자는 데이터 품질과 무결성, 접근 정책 등 종합적인 관리를 총괄한다.
* 데이터 수명 주기 관리: 데이터를 생성(수집) -> 활용(처리) -> 보관(아카이빙) -> 폐기(또는 장기 보관)의 전 단계에 걸쳐 정책을 설정한다.
  * 예: GNSS 원시 데이터는 10년 보관 후, 일부 필드만 추출하여 요약 데이터셋을 만들어 추가 10년 보관한 뒤 폐기 등.
* 감사 체계 구축: 외부 감사나 규제 기관의 요청 시, 특정 기간의 GNSS 데이터 이력 및 보안 관리 실태를 투명하게 제시할 수 있어야 한다.
  * 예: 이벤트 로그, 접근 기록, 변경 내역 등을 별도의 데이터베이스에 저장하고 암호적 무결성 검사를 적용한다.

#### 분산 아카이빙과 고가용성

GNSS 데이터는 여러 기관 및 지역에서 생성되고 교환될 수 있기 때문에, 분산(distributed) 아카이빙 구조가 중요한 역할을 한다. 이를 통해 각 노드(node)나 서버가 독립적으로 동작하면서도, 전체 시스템으로는 일관적이고 중복된 백업을 유지할 수 있다.

* 분산 저장소 설계
  * 상호 연결된 여러 스토리지 노드에 GNSS 데이터를 분산 저장한다.
  * 특정 노드가 장애를 일으켜도 다른 노드에서 데이터 접근이 가능하도록 중복성을 확보한다.
* 레이턴시(latency) 고려
  * GNSS 데이터는 크기가 커서 전송에 시간이 많이 걸릴 수 있다.
  * 전 세계적으로 분산된 사용자가 데이터를 빠르게 조회할 수 있도록, 지리적으로 가까운 노드에 데이터 사본(replica)을 두는 방안을 검토한다.
* 자동 페일오버(failover)
  * 특정 노드나 서버에 장애가 발생했을 때, 자동으로 다른 노드가 서비스를 이어받도록 구성한다.
  * 고가용성(High Availability) 클러스터나 로드 밸런싱 기법을 적용하여, GNSS 데이터 서비스가 중단 없이 지속되도록 한다.

#### 성능 모니터링과 확장성

GNSS 데이터의 아카이빙은 시간이 지남에 따라 매우 거대한 규모가 될 수 있다. 따라서 아카이빙 시스템의 처리 성능과 확장성을 지속적으로 모니터링하고 개선해야 한다.

* I/O(입출력) 최적화
  * 대용량 파일 입출력 시, 디스크나 네트워크 대역폭이 병목이 될 수 있다.
  * RAID 구성, SSD 사용, 네트워크 트렁킹(trunking) 등으로 I/O 병목을 완화하고, 백업·복구 속도를 높인다.
* 캐싱 및 계층적 스토리지
  * 자주 액세스되는 데이터(최근 관측 자료 등)는 빠른 계층(예: SSD)에 보관하고, 오래된 데이터는 느린 계층(테이프 라이브러리 등)으로 옮긴다.
  * 이를 통해 비용 효율적이면서도 성능을 유지한다.
* 로드 밸런싱
  * 아카이빙 요청(업로드·다운로드)이 집중되는 시간대나 요일에는, 부하가 특정 노드에 몰리는 것을 막기 위해 부하를 분산한다.
  * 클라이언트 요청을 여러 서버에 고르게 배분해 전체 처리량(throughput)을 높인다.

#### 계층적 접근 구조 설계

GNSS 데이터는 기관·사용자별로 이용 목적이 상이하고, 그 민감도와 활용도 또한 다르다. 따라서 보안 관점에서 계층적 접근 구조(Hierarchical Access Structure)를 설계해 두는 것이 바람직하다.

* 데이터 계층 구분
  * 예: 공개데이터공개 데이터 → 내부용데이터내부용 데이터 → 민감/기밀데이터민감/기밀 데이터 처럼 중요도에 따라 구분한다.
  * 각 계층에 따라 암호화 수준, 접근 권한, 백업 주기 등을 다르게 설정한다.
* 분할된 권한 부여
  * 단일 관리자에게 모든 권한을 몰아주지 않고, 필요 시 복수의 관리자(또는 승인자)의 동의가 있어야만 접근이 가능하도록 한다.
  * 민감 데이터에 대해서는 멀티시그(multi-signature)나 다중 인증 방식(2 of 3, 3 of 5 등)을 적용한다.
* 접근 이력 분석
  * 계층적으로 접근이 구분되어 있는 데이터에 대해, 누가 어느 계층의 데이터에 접근했는지 정기적으로 분석한다.
  * 비정상적 접근 시도가 감지되면 즉시 경보를 발생시키고, 추가 모니터링을 실시한다.

#### 재해 복구와 비즈니스 연속성

GNSS 데이터는 측위, 항법, 타이밍 등 다양한 서비스의 기반 데이터로 활용될 수 있다. 따라서 외부 재해나 내부 시스템 장애로 인해 데이터가 소실·변조되는 상황에 대비해야 한다.

* 재해 복구(DR) 계획
  * 자연재해(지진, 홍수 등), 전력 공급 중단, 화재, 테러 등 돌발 상황에 대응하기 위한 절차를 마련한다.
  * 원격지에 데이터 백업 센터나 클라우드 기반 DR센터를 확보하여, 주 센터가 마비되어도 빠른 복구가 가능하도록 한다.
* RTO(Recovery Time Objective) & RPO(Recovery Point Objective)
  * RTO는 장애 발생 시, 서비스를 정상화하기까지 허용 가능한 최대 시간이다.
  * RPO는 데이터 손실 허용 범위로, 장애 발생 직전까지의 데이터 복원 가능 시점을 의미한다.
  * GNSS 데이터의 용도나 중요도에 따라, RTO와 RPO를 적절히 설정해 두어야 한다.
* 정기적인 DR 훈련
  * 재해 상황을 가정한 모의 훈련을 주기적으로 실시해, 백업 및 복구 체계가 실제로 작동하는지 검증한다.
  * 문제점이 발견되면 즉시 절차와 시스템을 개선한다.

#### 클라우드 기반 아카이빙

최근에는 물리적 장비 및 시설에 대한 투자 부담을 줄이고, 확장성·유연성·가용성을 향상시키기 위해 클라우드 환경에서 GNSS 데이터 아카이빙을 구성하는 사례가 늘고 있다.

* IaaS(Infra as a Service) 활용
  * 클라우드 사업자가 제공하는 가상 서버와 스토리지에 GNSS 데이터를 저장한다.
  * 확장(Scale-out)이 용이하고, 사용한 만큼 비용을 지불하는 종량제(pay-as-you-go) 모델을 적용할 수 있다.
* PaaS / SaaS 적용
  * 데이터베이스나 빅데이터 분석 도구를 클라우드 기반 서비스로 사용하고, GNSS 데이터를 적재하여 실시간 또는 배치(batch) 처리를 수행한다.
  * 예: 대용량 로그 분석이나 머신러닝 기반 모델 학습을 빠르게 수행할 수 있다.
* 보안 요구사항 검토
  * 클라우드 서비스 사업자(CSP)가 제공하는 보안 기능(SSE-S3, KMS 등)을 적극 활용하되, 책임공유모델(Shared Responsibility Model)을 이해하고 고객 측에서 관리해야 할 보안 영역을 명확히 구분한다.
  * 민감 데이터에 대한 암호화를 클라우드의 기본 기능에만 의존할 것인지, 별도의 HSM(Hardware Security Module)을 사용할 것인지 결정한다.

#### 블록체인 기반 무결성 검증

GNSS 데이터가 다수의 이해 관계자(관측소, 연구 기관, 정부 기관 등) 간에 공유되는 경우, 블록체인 기술을 적용해 데이터 무결성을 보장할 수 있다.

* 데이터 해시 등록
  * 원시 GNSS 데이터(또는 일정 기간마다 축적된 데이터셋)의 해시값을 블록체인에 기록해 두면, 훗날 해당 데이터의 조작 여부를 독립적으로 검증할 수 있다.
  * 예: 특정 시점의 RINEX 파일에 대해 $H(\mathbf{d})$를 계산하고, 이를 블록에 포함시켜 분산 노드들이 합의(Consortium Blockchain, Public Blockchain 등)한다.
* 스마트 컨트랙트 활용
  * 자동화된 승인 절차나 데이터 접근 조건을 스마트 컨트랙트로 작성해, 임의로 수정·삭제하기 어렵도록 시스템화한다.
  * 예: “관측소 A가 업로드한 데이터는 B, C 기관이 서명해야만 공식 아카이브로 인정된다.” 같은 정책을 블록체인에서 자동 처리한다.
* 네트워크 오버헤드
  * 블록체인에 실제 GNSS 데이터를 전부 저장하기는 비효율적이므로, 일반적으로 원본 데이터는 별도 스토리지에 두고, 블록체인에는 해시·메타데이터·승인 내역만 저장한다.
  * 트랜잭션 비용과 처리 속도를 고려해, 사설(Private) 또는 컨소시엄(Consortium) 블록체인을 적용하는 경우가 많다.

#### 인증서 기반 분산 검증

GNSS 데이터가 각기 다른 지리적 위치에서 생성·수집·가공되는 경우, 데이터 출처의 신뢰성과 전송 과정에서의 안전성을 보장해야 한다.

* 전송 계층 암호화(TLS/SSL)
  * 각 관측소 또는 데이터 수집 장비에서 중앙 서버(또는 다른 노드)로 전송할 때, TLS/SSL 프로토콜을 적용해 전송 중 도청이나 변조를 방지한다.
  * 서버 인증서와 클라이언트 인증서를 상호 검증(mTLS)하여, 양방향에서 신뢰할 수 있는 상대인지 확인한다.
* PKI(Public Key Infrastructure) 활용
  * 관측소마다 고유의 인증서를 발급받아, 데이터 생성 시 해당 서명을 첨부하면 누가 언제 이 데이터를 생성했는지 추적 가능하다.
  * 중앙 인증기관(CA) 혹은 하위 CA를 구성해, 각 조직 또는 장비별 인증서 수명과 폐기(Revocation) 관리 등을 체계적으로 수행한다.
* 위변조 추적
  * 각 데이터 파일이나 패킷에 전자 서명(또는 전자 봉투)을 적용해, 전송 과정 중 위변조가 발생했을 때 수신 단계에서 즉시 감지할 수 있다.
  * 파일 무결성 검사를 위해, $H(\mathbf{d})$를 서명하고(개인 키 사용), 검증 시 공개 키로 서명을 푼 뒤 해시를 비교한다.

#### 운영자동화(Ops) 관점의 보안 통합

오늘날 대규모 GNSS 데이터 운영환경에서는 DevOps, DataOps 등 자동화 프로세스가 적극 적용되고 있다. 이때 보안 항목도 자동화된 파이프라인에 통합(DevSecOps)되어야 한다.

* 코드 기반 인프라
  * 아카이빙 시스템 구성(서버, 스토리지, 네트워크 설정 등)을 코드(예: Terraform, Ansible)로 관리하면서, 보안 설정(방화벽 정책, 접근 권한 등) 역시 버전 관리한다.
  * 변경 사항이 있을 때마다 CI/CD 파이프라인에서 자동으로 테스트 및 검증이 이뤄진다.
* 보안 스캐닝 툴 통합
  * 아카이빙 시스템에서 사용되는 소프트웨어나 라이브러리에 대한 취약점 스캐너(예: Snyk, OSSIndex 등)를 자동화 파이프라인에 포함한다.
  * 새로운 취약점이 발견되면 즉시 알림을 받고 패치 과정을 실행한다.
* 재현 가능한 배포
  * 동일한 버전의 인프라와 보안 설정을 다른 환경(테스트, 스테이징, 운영 등)에도 빠르고 정확하게 복제할 수 있어야 한다.
  * 이를 통해 보안 정책이 누락되지 않고 전파되며, 장애나 해킹 발생 시 빠른 복구와 재배포가 가능하다.

#### 물리적 보안

GNSS 데이터가 저장되는 서버실, 데이터센터, 관측소 등 물리적 환경도 보안 설계의 중요한 축이다. 사이버 보안만으로는 내부 침입, 기기 도난, 인프라 파괴 등을 방어할 수 없으며, 물리적 보안을 철저히 해야 한다.

* **출입 통제**
  * 서버룸이나 데이터 아카이빙 시설에 대한 출입 통제 장치를 마련한다. 예: 생체인식(지문·홍채), 출입카드, CCTV.
  * 내부 직원이라 해도 담당 업무 범위를 벗어난 구역에는 접근하지 못하도록 구역별 접근 권한을 설정한다.
* **주변 환경 위험 평가**
  * 데이터센터 인근 지역의 자연재해(지진, 홍수, 산불 등) 위험도를 분석하고, 이에 맞춰 건물 설계나 재해 대응 전략을 마련한다.
  * 전력 공급 안정성(UPS, 발전기 등), 냉각 시스템, 소방 설비도 정상 동작을 보장받기 위해 주기적으로 점검한다.
* **장비 보안**
  * 서버·스토리지 장비에 대한 물리적 잠금 장치를 설치하고, 중요한 인터페이스(USB 포트 등)에 대한 사용을 제한한다.
  * 네트워크 케이블, 스위치, 라우터 등의 장비도 임의로 조작되지 않도록 잠금 랙(lockable rack)에 배치하거나 봉인(seal) 장치를 사용한다.

#### 양자 컴퓨팅 대비 암호화

미래에는 양자 컴퓨터가 현재의 공개 키 암호화 기법을 빠르게 해킹할 수 있게 될 것이라는 전망이 있다. GNSS 데이터가 장기간 보관되면서 장래에 해독될 위험을 고려하려면, 양자 내성(quantum-resistant) 암호 알고리즘에 대한 대비가 필요하다.

* **양자 안전 알고리즘(Post-Quantum Cryptography, PQC)**
  * 대표적으로 격 기반(Lattice-based), 해시 기반(Hash-based), 다변수(multivariate) 기반, 부정원형 코드(Code-based) 등이 연구되고 있다.
  * 예: 격 기반 암호에서 핵심 아이디어는 매우 큰 차원의 격을 기반으로 $\mathbf{A}\mathbf{x} \equiv \mathbf{b} \pmod{q}$ 문제를 해결하기가 어렵다는 점에 기반한다.
* **하이브리드 암호 스위트**
  * 기존 RSA, ECC 등 전통적인 비대칭 키 기법과 양자 안전 기법을 함께 사용하는 방안이다.
  * 점진적으로 PQC 알고리즘을 도입하되, 아직 충분히 검증된 표준이 아니므로 기존 알고리즘과 병행해 신뢰도를 높인다.
* **장기 보관 데이터 위험**
  * 지금 암호화한 GNSS 데이터가 수십 년 후, 양자 컴퓨팅 환경에서 해독될 수 있다는 점을 염두에 두어야 한다.
  * 민감도가 높은 데이터라면, 향후 PQC로 재암호화(또는 재보안처리)하는 전략을 미리 수립한다.

#### APT(Advanced Persistent Threat) 대응

GNSS 데이터가 국가 기간망, 군사, 항공 등 고가치 인프라와 연관되어 있을 경우, APT 공격에 대비해야 한다. APT는 특정 조직이나 국가가 오랜 기간에 걸쳐 지속적으로 침투와 정보를 수집하는 공격 유형을 의미한다.

* **위협 인텔리전스 활용**
  * 글로벌 보안 전문 업체나 CERT/CSIRT를 통해 최신 위협 정보를 공유받고, 해당 공격 기법·도구가 GNSS 아카이빙 시스템에 적용될 수 있는지 점검한다.
  * 의심스러운 활동이 감지되면, 실시간으로 보안팀과 협업해 대응한다.
* **다단계 보안**
  * 네트워크 구간별로 세분화(segmentation)해, 공격자가 한 번 침투하더라도 전체 시스템을 장악하기 어렵도록 한다.
  * 중요한 GNSS 데이터 서버 주변에는 또 다른 방화벽, IDS/IPS, NAC(Network Access Control) 등을 배치해 2차·3차 방어선을 구축한다.
* **이상 징후 모니터링**
  * 머신러닝 기반 UEBA(User and Entity Behavior Analytics) 기법을 적용하여, 평소와 다른 사용자 혹은 시스템 행위(예: 대량 데이터 다운로드, 비정상 시간대 접근)를 탐지하고 차단한다.
  * 내부 사용자 계정이 해킹되었을 가능성까지 고려해, 권한 상승(elevation)이나 데이터 접근 패턴 변화를 추적한다.

#### 컨테이너 기반 아카이빙 운영

최근에는 컨테이너 기술(Docker, Kubernetes 등)을 활용하여 GNSS 데이터 수집·처리·저장을 마이크로서비스로 분할하고, 이를 유연하게 확장·관리하는 방식도 주목받고 있다.

* **컨테이너 보안**
  * 이미지 스캐닝: 컨테이너 이미지를 배포하기 전, 취약한 라이브러리나 악성 코드가 포함되지 않았는지 검사한다.
  * 런타임 보안: 컨테이너 실행 중 비정상 동작(루트 권한 획득, 이상 네트워크 연결 시도 등)을 감지해 격리·차단한다.
* **오토스케일링과 자원 최적화**
  * GNSS 데이터 수집량이 일시적으로 증가할 때, 자동으로 컨테이너 인스턴스를 늘려 처리를 분산시킨다.
  * 필요하지 않을 때는 다시 줄여서 비용을 절감한다.
  * 이러한 탄력성은 디스크 I/O나 네트워크 트래픽, CPU 사용량 등을 종합적으로 고려해 설정할 수 있다.
* **멀티클라우드 및 하이브리드 클라우드**
  * 한 클라우드 서비스에만 의존하지 않고, 여러 CSP를 조합해 구성하거나 온프레미스 데이터센터와 병행 운영하는 경우도 많다.
  * 이때 컨테이너 오케스트레이션 도구(Kubernetes 등)가 워크로드 이식을 단순화해 준다.