클라우드 방화벽도 이제 포스트 양자 암호 검증 대상임

방화벽 검증이 ‘양자 안전’까지 넘어감

• 클라우드 네이티브 방화벽(CNFW)이 포스트 양자 암호(PQC) 검증 대상으로 올라왔음

  • 시큐어아이큐랩이 NIST PQC 표준을 반영한 독립 검증 방법론을 공개함
  • AMTSO 테스트 ID는 AMTSO-LS1-TP195로 등록됐고, 최대 16개 벤더를 평가할 예정임
  • 테스트는 2026년 6월 시작, 개별·비교 보고서는 2026년 10월 말 공개 예정임

• 이번 포인트는 ‘PQC 지원함’ 체크박스가 아니라 실제 클라우드 운영에서 버티는지 보는 거임

  • TLS 세션, 인증서 처리, 키 교환, 세션 재사용, 쿠버네티스 정책 집행이 같이 유지돼야 함
  • 컨테이너 간 동서향 트래픽, API 기반 제어, 서비스 간 접근 통제까지 평가 범위에 들어감

TLS·쿠버네티스·AI 엔드포인트까지 한 번에 봄

• 암호 검증은 NIST 표준화 알고리듬 구현 여부를 중심으로 진행됨

  • 디지털 서명은 ML-DSA-65, ML-DSA-87을 봄
  • 키 설정은 ML-KEM-768, ML-KEM-1024를 봄
  • 무결성 검증은 SHA-384, SHA-512를 적용함

• TLS 계층 검증도 꽤 구체적임

  • TLS 1.2 암호군 22개, TLS 1.3 암호군 3개를 확인함
  • TLS 세션 재사용과 NIST FIPS 203·204·205 기준 적용도 평가함
  • 생성AI 추론 서비스처럼 API 호출이 많은 시스템에서는 핸드셰이크 비용과 지연 시간이 바로 체감 성능으로 튐

• 보안성 평가는 실제 공격 시나리오 기준으로 점수화함

  • MITRE ATT&CK Cloud Matrix, STRIDE, OWASP Cloud-Native Guidelines, CSA Cloud Controls Matrix를 기준으로 삼음
  • 공격을 차단하고 탐지하면 100%, 차단만 하면 75%, 탐지만 하면 25%, 둘 다 실패하면 0%임
  • 로그만 남기는 제품과 실제로 막는 제품을 같은 급으로 치지 않겠다는 얘기라 꽤 현실적임

생성AI와 MCP도 방화벽 평가 안으로 들어옴

• 이번 방법론에는 생성AI 워크로드 보안도 포함됨

  • 생성AI 추론 엔드포인트 보호가 평가 대상임
  • 모델 컨텍스트 프로토콜(MCP) 서버 보안도 들어감
  • MCP 접근 제어, 툴 호출 데이터 유출, 프롬프트 인젝션 하이재킹을 본다고 함

• 이게 흥미로운 이유는 방화벽의 역할이 IP·포트 차단을 넘어섰다는 점임

  • 생성AI 앱은 외부 도구 호출, 데이터 검색, API 실행, 에이전트 작업을 엮음
  • 그러면 보안 장비도 요청 맥락, 서비스 접근 권한, 데이터 유출 가능성을 같이 봐야 함

• 테스트 환경도 현실적인 클라우드 조합을 깔고 감

  • AWS, 애저(Azure), 구글 클라우드(GCP), 쿠버네티스에서 검증함
  • 쿠버네티스 배포 환경은 EKS, AKS, GKE가 포함됨
  • 서버리스, 생성AI 추론 엔드포인트, MCP 서버 보안도 같은 범위에서 다룸

조달·규제 일정이랑도 맞물림

• 미국 정부의 PQC 전환 일정과도 타이밍이 맞음

  • CISA는 2026년 1월 연방기관이 PQC 지원 기술만 조달해야 하는 제품 범주 목록을 발표함
  • 연방기관은 2026년 4월 말까지 포괄적인 PQC 전환 계획을 제출해야 했음
  • 신규 국가안보시스템 조달은 2027년 1월부터 CNSA 2.0 준수가 적용되고, 전체 NSS 준수는 2033년까지 요구됨

• 유럽 쪽도 DORA, NIS2 흐름에서 양자 취약 암호를 더 이상 ‘최신 수준’으로 보기 어려운 분위기임

  • 공공, 금융, 의료, 통신처럼 규제가 센 산업에서는 벤더 설명보다 독립 검증 근거가 중요해짐
  • 시큐어아이큐랩은 이번 검증이 벤더 의뢰 없이 자체 비용으로 수행되는 비의뢰 독립 평가라고 밝힘
  • 벤더가 비용을 내지 않고, 검증 과정에 영향도 못 주고, 결과 공개도 막을 수 없다는 구조임

---

기술 맥락

• 이번 선택의 핵심은 PQC를 암호 모듈이 아니라 클라우드 보안 아키텍처 문제로 본다는 점이에요. 클라우드에서는 트래픽이 API, 컨테이너, 서버리스, AI 엔드포인트를 계속 오가니까 알고리듬만 바꿔서는 실제 위험이 줄었다고 말하기 어렵거든요.

• CNFW를 따로 검증하는 이유도 여기에 있어요. 기존 방화벽은 VPC 경계에서 들어오고 나가는 트래픽을 보는 경우가 많았지만, CNFW는 쿠버네티스 내부 정책과 서비스 간 접근 제어까지 맡아요. 그래서 TLS와 정책 집행이 같이 깨지지 않는지가 중요해요.

• ML-KEM이나 ML-DSA 같은 표준 알고리듬을 넣는 건 출발점일 뿐이에요. 실제 운영에서는 짧은 TLS 세션이 폭주하거나 생성AI 추론 API 호출이 늘 때 핸드셰이크 비용, 세션 재사용, 지연 시간이 같이 튀기 때문에 성능 검증이 따라붙어야 해요.

• MCP 보안이 포함된 것도 꽤 의미 있어요. AI 에이전트가 내부 도구와 데이터를 호출하기 시작하면, 방화벽은 네트워크 주소만 보는 장비가 아니라 어떤 요청이 어떤 도구를 호출하고 어떤 데이터가 새는지까지 보는 통제 지점이 되거든요.