양자내성 전환의 첫 단계는 TLS 자산 인벤토리다

NIST는 2024년 FIPS 203, 204, 205를 최종화했고 이후 전환 지침과 추가 표준화가 계속 진행되고 있다. 그러나 대부분의 조직에서 즉시 해야 할 일은 모든 TLS 연결을 새 알고리즘으로 교체하는 것이 아니다. 어떤 시스템이 RSA, ECDSA, (EC)DH, 특정 인증서 체인과 라이브러리에 의존하는지 파악하고 교체 가능한 구조를 만드는 것이다.

표준·브라우저·클라우드·규제 요구는 계속 바뀔 수 있다. 실제 마이그레이션 일정과 승인 알고리즘은 게시·적용 시점의 NIST, IETF, 공급자, 관할 규정 문서를 다시 확인해야 한다. 금융·장기보관 환경의 우선순위 사례는 금융권 PQC 마이그레이션 전략, 신원·mTLS 관점은 제로 트러스트와 PQC와 함께 보면 범위를 구체화하기 쉽다.

암호 인벤토리의 범위

TLS 엔드포인트만 스캔하면 내부 서명과 저장 데이터 키를 놓친다. 다음 범주를 포함한다.

• 외부·내부 TLS 서버와 클라이언트
• API 게이트웨이, 로드밸런서, CDN, 서비스 메시
• 사설 PKI, 인증기관, 등록·갱신 자동화
• VPN, SSH, 원격관리, 무선 인증
• 코드·펌웨어·컨테이너·문서 서명
• 이메일, 파일전송, 메시징, 데이터베이스 암호화
• HSM, KMS, 스마트카드, TPM, 보안 토큰
• 애플리케이션 암호 라이브러리와 정적 링크 바이너리
• SaaS·결제·ID 공급자와 하위 처리자
• 장기 보관 백업과 아카이브

최소 인벤토리 스키마

asset_id: api-gateway-prod-seoul
owner: platform-security
business_service: customer-api
crypto_use: tls-server-key-establishment
endpoint: api.example.com:443
protocols: [TLS1.2, TLS1.3]
certificate:
  issuer: enterprise-ca-2
  public_key_algorithm: ECDSA-P256
  signature_algorithm: ecdsa-with-SHA256
  expires_at: 2026-11-20
key_management:
  location: cloud-kms
  exportable: false
library_or_service: managed-load-balancer
client_dependencies:
  - mobile-app-min-version-7
  - partner-a
sensitivity:
  confidentiality_years: 10
  authenticity_years: 3
change_constraints:
  - partner-cert-pinning
  - legacy-device-support
vendor_pqc_status: unknown
last_verified_at: 2026-06-19

중요한 것은 알고리즘 이름만 아니라 소유자, 데이터 수명, 클라이언트 의존성, 키 위치, 공급자 지원 상태다.

자동 검색과 수동 확인을 결합한다

자동 검색

• 네트워크 TLS·SSH·VPN 엔드포인트 스캔
• 인증서 투명성·내부 CA 발급 목록
• 클라우드 인증서·로드밸런서·KMS 인벤토리
• 저장소의 암호 API·라이브러리·알고리즘 문자열 검색
• 컨테이너·바이너리의 라이브러리와 버전 분석
• HSM·KMS 키 메타데이터와 사용 로그
• 구성관리·서비스 메시·프록시 설정 수집

수동 확인

• 공급자 계약과 제품 로드맵
• 인증서 고정, 하드코딩, 임베디드 기기 제약
• 장기 오프라인 검증·아카이브 서명 요구
• 규제·고객의 승인 알고리즘 조건
• 복구·재서명·키 교체 절차

스캔에서 보이지 않는 클라이언트 측 암호, 정적 링크, 펌웨어, 외부 SaaS를 찾기 위해 시스템 소유자 인터뷰가 필요하다.

우선순위는 데이터 수명과 교체 시간을 함께 본다

“Harvest now, decrypt later” 위험은 현재 수집된 암호문이 미래에도 가치가 있을 때 커진다. 다음 질문으로 우선순위를 정한다.

1. 데이터가 몇 년 동안 기밀이어야 하는가.
2. 서명·신원의 진위가 몇 년 동안 검증돼야 하는가.
3. 시스템 교체와 인증에 몇 년이 걸리는가.
4. 인터넷 또는 공급망에 얼마나 노출되는가.
5. 암호 알고리즘과 라이브러리를 교체할 수 있는가.
6. 공급자와 클라이언트가 언제 호환될 수 있는가.

장기 비밀 데이터와 수명이 긴 장비는 먼저 준비해야 한다. 단기 공개 콘텐츠의 TLS보다 의료·정부·산업 설계 아카이브나 펌웨어 서명 체인이 더 높은 우선순위일 수 있다.

암호 민첩성을 먼저 개선한다

PQC 전환을 특정 알고리즘 이름을 코드에 추가하는 작업으로 만들면 다음 전환에서도 같은 문제가 반복된다.

• 알고리즘과 파라미터를 코드에 하드코딩하지 않는다.
• 인증서·키·신뢰 저장소를 중앙에서 교체할 수 있게 한다.
• 프로토콜·라이브러리 버전을 인벤토리와 연결한다.
• 이중 인증서·하이브리드 모드 등 전환 기능을 설정으로 제어한다.
• 클라이언트 호환성 텔레메트리와 실패 롤백을 준비한다.
• 키·인증서 회전 훈련을 정기적으로 수행한다.
• 공급자 교체와 데이터 반출 가능성을 계약에서 확인한다.

파일럿 설계

파일럿은 비핵심 내부 연결부터 시작할 수 있지만 실제 제약을 대표해야 한다.

1. 관리 가능한 서버·클라이언트 쌍을 선택한다.
2. 현재 지연, CPU, 패킷 크기, 오류율을 기준선으로 측정한다.
3. 공급자와 라이브러리가 지원하는 표준·하이브리드 방식을 확인한다.
4. 인증서 체인, 로드밸런서, 관측 도구, 중간 장비 호환성을 시험한다.
5. 오래된 클라이언트와 MTU·프록시·방화벽 영향을 확인한다.
6. 실패 시 기존 방식으로 되돌리는 조건을 정의한다.
7. 결과를 인벤토리의 제약·공급자 상태에 반영한다.

실험적 알고리즘이나 비표준 조합을 운영에 적용하기 전에 승인 상태와 상호운용성을 확인한다. “하이브리드”라는 이름만으로 자동 안전을 보장하지 않으며 구성과 결합 방식에 대한 공식 지침이 필요하다.

공급자 질문 목록

• 제품이 사용하는 공개키 알고리즘과 라이브러리를 공개할 수 있는가.
• FIPS 203/204/205 또는 관련 표준 지원 계획은 무엇인가.
• 하이브리드 키 교환·서명 지원 범위와 기본 활성 시점은 언제인가.
• 기존 하드웨어·라이선스로 가능한가, 교체가 필요한가.
• 인증·검증 상태와 상호운용 테스트 결과가 있는가.
• 키·인증서·서명 데이터를 내보내거나 재발급할 수 있는가.
• 지원 종료 제품의 전환 경로는 무엇인가.
• 장애 시 롤백과 긴급 패치 절차는 무엇인가.

“로드맵에 있음”이라는 답은 날짜, 버전, 제약, 계약 책임으로 구체화해야 한다.

탐지와 진행 지표

• 암호 자산 중 소유자·알고리즘·키 위치 확인 비율
• 외부 노출 TLS 엔드포인트와 내부 엔드포인트의 발견 차이
• 만료 임박 인증서와 수동 갱신 비율
• 하드코딩·인증서 고정·정적 링크로 교체가 어려운 시스템 수
• 장기 기밀 데이터가 양자 취약 키 교환에 의존하는 범위
• 공급자 PQC 상태가 unknown인 핵심 서비스 수
• 파일럿의 핸드셰이크 실패·지연·패킷 크기 변화
• 키 회전·인증서 교체 훈련 성공률

인벤토리는 한 번 만든 스프레드시트가 아니라 인증서 발급, 클라우드 자산, 배포 파이프라인과 동기화해야 한다.

90일 실행 체크리스트

• 암호 인벤토리의 스키마와 중앙 소유자를 정한다.
• 외부 TLS, 클라우드 인증서, KMS부터 자동 수집한다.
• 코드 서명, VPN, SSH, HSM, SaaS 범위로 확장한다.
• 데이터 기밀·진위 수명과 시스템 교체 시간을 기록한다.
• 소유자 없는 자산과 알고리즘 미확인 항목을 줄인다.
• 핵심 공급자에게 표준 지원·교체 계획을 요청한다.
• 비핵심이지만 대표성이 있는 파일럿을 선정한다.
• 키·인증서 회전과 롤백 절차를 시험한다.

참고 기준

• NIST Post-Quantum Cryptography Project
• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism
• FIPS 204: Module-Lattice-Based Digital Signature Standard
• FIPS 205: Stateless Hash-Based Digital Signature Standard
• CISA Quantum-Readiness: Migration to Post-Quantum Cryptography
• NIST SP 800-227: Recommendations for Key-Encapsulation Mechanisms
• NIST Considerations for Achieving Cryptographic Agility

결론

양자내성 전환에서 가장 큰 초기 위험은 알고리즘을 늦게 고르는 것이 아니라 현재 암호 사용처와 교체 제약을 모르는 것이다. 데이터 수명, 키 위치, 클라이언트, 공급자를 포함한 인벤토리를 만들고 암호 민첩성을 높이면 표준과 제품 지원이 성숙할 때 안전하게 이동할 수 있다.