6. 보안적합성 검사

오늘의 질문

제품이 "안전하다"고 주장하는 것과 국가가 검증한 제품은 다르다. CTF에서는 "내가 깰 수 있는가?"를 고민하지만, 공공기관 납품에서는 "내 구현이 맞다는 것을 누가 보증하는가?"가 중요하다. 국가·공공기관에 납품되는 IT 제품은 반드시 국가 보안 검증 체계를 통과해야 한다

 

하나의 검증 체계를 사용하는 제품

국가 보안 검증 대상은 총 34종이다. 대표적으로 방화벽(FW), VPN, 스위치·라우터, 안티바이러스, DB 접근통제, IP카메라, 양자키분배(QKD) 등이 있으며 모두 동일한 검증 체계를 적용받는다.   

 

비슷하지만 다른 세 가지

1. 보안기능 확인서 : IT 제품의 보안기능이 국가 요구사항을 만족하는지 시험하는 제도이며 이번 강의의 핵심이다.

2. KCMVP : 암호모듈이 국가 기준에 맞게 구현되었는지 검증하는 제도이며 검증필 암호모듈만 제품에 사용할 수 있다.

3. CC 인증 : 제품 전체의 보안성을 평가하는 국제 인증(ISO/IEC 15408)이며 국내 영상정보처리기기에는 적용되지 않는다.

핵심 : VSFT는 제품의 보안기능, KCMVP는 암호모듈, CC 인증은 제품 전체 보안성을 평가하는 제도이다.

 

도입의 벽

국가·공공기관은 "안전하다"는 주장만으로 제품을 도입하지 않는다. 반드시 객관적인 검증 절차를 통과해야 하며, 실제 현장에서는 "사용할 수 있는가?"보다 "도입 요건을 통과했는가?"가 더 중요하다.

 

한 제품에는 세 가지 검증이 존재한다.

운용 환경은 보안적합성 검증, 제품 보안기능은 보안기능 시험제도(VSFT), 암호 구현은 KCMVP를 통해 검증한다. 즉, 잘 만든 제품과 국가가 검증한 제품은 다르며 이를 증명하는 것이 검증 제도이다.

 

보안적합성 검증이란

국가·공공기관이 IT 제품을 도입하기 전에 안전성을 검증하는 제도로 운영기관은 국가정보원이다. 도입 전에 검증을 실시하고, 발견된 취약점을 보완한 후 공공기관에 도입된다.

관련 법령 : 국가정보원법 제4조, 사이버안보업무규정 제9조, 전자정부법 제56조, 시행령 제69조

 

최근 편입 사례(2024.4.1)

2024년 4월 1일부터 영상정보처리기기(IP카메라) 가 보안적합성 검증 대상에 포함되었다. TCP/IP 기반 카메라는 검증 대상이며, SDI와 아날로그 카메라는 대상이 아니다. 현재 적용 기준은 영상정보처리기기 보안요구사항 V3.0이다.

 

국가용 보안요구사항

국가용 보안요구사항은 보안기능 시험과 국내 CC 인증에서 공통으로 사용하는 시험 기준이다. 공통 보안요구사항 2종과 제품별 보안요구사항 34종으로 구성된다. 제품군에는 침입차단(FW), 침입방지(IPS), 구간보안(VPN), 전송자료보안, 보안관리, 가상화, 엔드포인트보안, 네트워크장비, 양자암호통신, 영상정보처리기기가 포함된다. 2021년 29종에서 2024년 영상정보처리기기가 추가되어 현재 총 34종이다.

 

공통보안요구사항

모든 제품은 공통적으로 ① 식별 및 인증 ② 보안관리 ③ 데이터 보호 ④ 자체보호 ⑤ 업데이트 보호 ⑥ 안전한 세션관리 ⑦ 감사기록 ⑧ 암호지원 ⑨ 취약성 대응을 만족해야 한다. 영상정보처리기기는 여기에 영상 보안이 추가된다. 또한 제품 종류와 관계없이 패스워드 9자리 이상, 인증 실패 5회 잠금, 유휴시간 10분 기준이 동일하게 적용된다.

 

보안기능 시험제도(VSFT)

보안기능 시험에는 네 개의 기관이 참여한다. 국가정보원은 정책 수립과 시험기관 승인을 담당하고, 국가보안기술연구소는 시험 결과 검증과 확인서 승인을 담당한다. TTA 는 실제 보안기능 시험을 수행하고 확인서를 발급하며, 제조업체 는 시험 신청, 문서 제출, 취약점 개선을 담당한다. 제조업체는 TTA에 신청한 후 NSR 승인을 거쳐 보안기능 확인서를 발급받는다.

 

기관별 역할

NIS : 검증 정책 수립, 시험기관 지정 및 승인, 확인서 관리
NSR : 시험 가이드 제공, 시험 결과 검증, 확인서 발급 승인
TTA : 보안기능 시험 수행, 보안기능 확인서 발급
제조업체 : 시험 신청, 제출문서 작성, 취약점 개선

 

보안기능 시험 절차

모든 제품은 1. 시험 신청 → 2. 접수 및 계약 → 3. 시험 계획 → 4. 실제 시험 → 5. 결과 검토 → 6. 보안기능 확인서 발급 → 7. 공공기관 도입 순으로 진행된다. 시험은 문서만 검토하는 것이 아니라 실제 제품을 동작시켜 시험하며, 부적합 판정을 받으면 취약점을 수정한 후 다시 시험을 진행한다.

 

보안기능 확인서

보안기능 확인서는 시험 기준을 만족한 제품에 대해 검증기관의 승인 후 시험기관이 발급하는 증서이다. 발급 시점까지 알려진 취약점이 제거되었음을 의미하지만, 발급 이후 발생하는 새로운 취약점까지 보장하는 것은 아니다. 공공기관은 이 확인서를 확인한 후 제품을 도입한다. 일반 제품의 유효기간은 5년, 신기술 제품은 2년이다.

 

제출문서 5종

시험 신청 시 모든 문서는 한국어로 작성해야 한다. 제출문서는 1. 제품설명서 2. 보안기능 구현명세서 3. 운용설명서 4. 시험결과서 5. 취약점 개선내역서이다.

백도어 규칙 : 구현명세서에 없는 인터페이스나 계정이 발견되면 백도어로 간주하며 즉시 보안기능 확인서 발급이 거부된다.

 

 

KCMVP란

KCMVP는 국가에서 사용하는 암호모듈의 안전성을 검증하는 제도이다. 암호 알고리즘뿐만 아니라 암호모듈이 안전하게 구현되었는지까지 시험한다. 국가·공공기관에 납품하는 제품은 검증필 암호모듈을 사용해야 한다.

핵심 : KCMVP는 암호 알고리즘이 아니라 암호모듈 전체를 검증하는 제도이다.

 

암호모듈이란

암호모듈은 암호 기능을 수행하는 소프트웨어 또는 하드웨어이다. 단순히 AES 같은 알고리즘만 의미하는 것이 아니라 암호화, 복호화, 키 생성, 키 저장, 키 파기 등을 수행하는 전체 구성을 의미한다.

암호모듈에는 다음 기능이 포함된다.

• 암호화
• 복호화
• 전자서명
• 해시
• 난수 생성
• 암호키 생성 및 관리

 

KCMVP 검증 대상

KCMVP는 다음과 같은 암호 기능을 검증한다.

• 암호 알고리즘 구현
• 난수발생기
• 암호키 생성
• 암호키 저장
• 암호키 파기
• 자체시험

즉, 키를 만들고, 저장하고, 사용하는 모든 과정을 검증한다.

 

암호 알고리즘 종류

암호 알고리즘은 크게 세 가지로 구분된다.

대칭키 암호

암호화와 복호화에 같은 키를 사용한다.

대표 알고리즘

• AES
• ARIA
• SEED

속도가 빠르며 대용량 데이터 암호화에 사용된다.

 

공개키 암호

암호화와 복호화에 서로 다른 키를 사용한다.

대표 알고리즘

• RSA
• ECC

키 교환과 전자서명에 사용된다.

 

해시 알고리즘

원본 데이터를 일정한 길이의 값으로 변환한다.

대표 알고리즘

• SHA-256
• SHA-384
• SHA-512

복호화가 불가능한 일방향 함수이다.

 

국내 대표 알고리즘

국가에서는 다음 알고리즘을 많이 사용한다.

ARIA

국내 표준 블록암호 알고리즘이다.

AES와 동일하게

• 128bit
• 192bit
• 256bit

키 길이를 지원한다.

 

SEED

128bit 블록암호 알고리즘이다.

전자정부 시스템에서 많이 사용된다.

 

SHA-256

대표적인 해시 알고리즘으로 무결성 검증에 사용한다.

파일 변조 여부를 확인할 때 사용된다.

 

보안강도

보안 요구사항에서는 112bit 이상의 보안강도를 요구한다.

대표 예시는 다음과 같다.

• AES-128 → 128bit
• ARIA-128 → 128bit
• SEED → 128bit
• RSA-2048 → 약 112bit
• SHA-256 → 256bit 해시

따라서 RSA는 2048bit 이상을 사용해야 한다.

 

TLS란

TLS는 네트워크에서 데이터를 암호화하여 안전하게 전송하는 프로토콜이다.

HTTPS는 HTTP 위에서 TLS를 사용하는 통신이다.

공공기관 요구사항에서는

TLS 1.2 이상만 허용한다.

 

 

TLS Handshake

TLS 연결 과정은 다음과 같다.

1. Client Hello

2. Server Hello

3. 인증서 전달

4. 키 교환

5. 암호화 통신 시작

이 과정을 TLS Handshake라고 한다.

 

허용되는 TLS 구성

다음 구성은 PASS 대상이다.

• TLS 1.2 이상
• TLS 1.3
• RSA 2048 이상
• SHA-256 인증서
• AEAD 방식
• ARIA
• SEED Cipher Suite

 

금지되는 TLS 구성

다음 구성은 FAIL 대상이다.

• SSL 2.0
• SSL 3.0
• TLS 1.0
• TLS 1.1
• RC4
• 3DES(TDES)
• MD5
• RSA 2048 미만
• ECB 모드

핵심 : 시험에서는 TLS 1.2 이상 + RSA 2048 이상을 반드시 만족해야 한다.

 

암호키 생성

암호키는 안전한 난수발생기로 생성해야 한다.

KEK 생성 시 사용하는 기준은 다음과 같다.

• PBKDF2
• SHA-256
• Salt 128bit 이상
• 반복횟수 1,000회 이상

예제 프로젝트에서는 100,000회를 사용한다.

 

암호키 저장

암호키는 평문으로 저장하면 안 된다.

데이터를 암호화하는 DEK는 KEK로 암호화하여 저장한다.

즉,

데이터 → DEK로 암호화 → DEK를 KEK로 암호화하여 저장

하는 구조이다.

이를 DEK → KEK 구조라고 한다.

 

암호키 파기

암호키는 사용이 끝나면 반드시 삭제해야 한다.

단순히 변수만 삭제하는 것이 아니라 메모리를 0으로 여러 번 덮어써 흔적까지 제거해야 한다.

예제 프로젝트에서는 3회 덮어쓰기를 수행한다.

 

자체시험

암호모듈은 실행될 때 스스로 정상 동작 여부를 검사한다.

점검 항목은 다음과 같다.

• 암호모듈
• TLS
• 인증서
• 하드웨어
• 서버 연결

오류가 발생하면 Fail Closed 방식으로 안전하게 종료한다.

 

무결성 검증

실행파일과 설정파일의 SHA-256 해시값을 기준과 비교하여 변조 여부를 검사한다.

검사는

• 프로그램 실행 시
• 실행 중 주기적으로

수행된다.

예제 프로젝트에서는 24시간마다 자동 검사를 수행한다.

 

코드로 보는 조항 1 - 올바른 알고리즘을 사용한다

암호기능은 검증된 알고리즘만 사용해야 한다. 대칭키 암호는 AES, ARIA, SEED를 사용하고, 공개키 암호는 RSA 2048bit 이상 또는 ECC를 사용한다. 해시 알고리즘은 SHA-256 이상을 사용하며, MD5나 SHA-1과 같은 취약한 알고리즘은 사용할 수 없다. 암호모듈은 KCMVP 검증필 모듈을 사용해야 한다.

핵심 : 검증된 알고리즘과 KCMVP 암호모듈만 사용해야 한다.

 

코드로 보는 조항 2 - 안전한 통신을 사용한다

클라이언트와 서버의 모든 통신은 TLS 1.2 이상을 사용해야 한다. SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1은 허용되지 않는다. RSA는 2048bit 이상을 사용하고, 금지된 Cipher Suite나 ECB 모드는 사용할 수 없다. 서버 인증서는 SHA-256 이상을 사용해야 한다.

핵심 : TLS 1.2 이상과 안전한 Cipher Suite를 사용해야 한다.

 

코드로 보는 조항 3 - 인증 실패 5회 잠금

사용자가 로그인에 실패하면 실패 횟수를 증가시키고, 연속으로 5회 이상 실패하면 계정을 잠금 상태로 변경한다. 계정이 잠기면 감사기록에 잠금 이벤트를 저장한다. 검사기는 실제 로그인을 시도하여 기능을 확인하며, 5번 틀린 뒤 정상 비밀번호를 입력해도 로그인이 거부되면 정상적으로 동작한 것으로 판단한다.

핵심 : 인증 실패 5회 잠금은 구현뿐 아니라 실제 동작까지 검증한다.

 

코드로 보는 조항 4 - 감사기록과 암호키 삭제

감사기록은 관리자 권한으로도 삭제할 수 없도록 DB Trigger를 이용하여 DELETE를 차단한다. 모든 보안 이벤트는 영구적으로 보관되어야 한다. 암호키는 사용이 끝나면 메모리를 0으로 3회 덮어써 흔적까지 제거한다. 단순히 변수를 삭제하는 것만으로는 충분하지 않다.

핵심 : 감사기록은 삭제할 수 없어야 하며, 암호키는 메모리에서 완전히 제거해야 한다.

 

코드로 보는 조항 5 - 속지 않는 서버

로그인 실패 시에는 "인증 실패"만 반환하여 계정 존재 여부나 비밀번호 오류 여부를 구분해서 알려주지 않는다. 또한 X-Forwarded-For 헤더는 공격자가 조작할 수 있으므로 신뢰하지 않고 실제 네트워크 연결의 IP(request.client.host)만 사용한다.

핵심 : 클라이언트가 보내는 정보는 신뢰하지 않는다.

 

코드로 보는 조항 6 - 입구는 한 명씩만

관리자 접속용 IP는 단일 IP만 등록할 수 있다. 0.0.0.0, , any, CIDR 대역, 와일드카드(, ?) 등 모든 IP 허용 형태는 등록할 수 없다. 화이트리스트에 없는 IP가 접속하면 접근을 차단(403)하고 감사기록을 생성한다.

핵심 : 모든 IP 허용 설정을 금지하고 허용된 IP만 접속할 수 있다.

 

코드로 보는 조항 7 - 키를 지키는 계층

패스워드는 bcrypt를 이용한 일방향 해시로 저장하며 bcrypt가 Salt 생성과 Iteration을 내부적으로 처리한다. 복원할 필요가 없는 값은 해시만 저장한다. 패스프레이즈에서는 PBKDF2(HMAC-SHA256)를 이용하여 KEK를 생성하며 Salt는 128bit, Iteration은 100,000회를 사용하고 보안강도는 112bit 이상을 만족한다. 생성된 KEK는 DEK를 암호화하여 저장하는 데 사용된다. 즉, 키를 또 다른 키로 보호하는 구조이다.

핵심 : 패스워드는 bcrypt로 저장하고, KEK는 PBKDF2(SHA-256)로 생성하여 DEK를 보호한다.

 

코드로 보는 조항 8 - 부팅부터 의심한다

프로그램이 시작될 때 자체시험을 수행하여 카메라 하드웨어, 서버 연결, TLS 인증서, 암호모듈 동작을 자동으로 점검한다. 실행 중에는 현재 파일의 SHA-256 해시를 기준과 비교하여 무결성을 검사하며, 프로그램 실행 시와 24시간마다 자동으로 수행한다. 자체시험이나 무결성 검증에 실패하면 Fail Closed 방식으로 안전하게 종료한다.

핵심 : 시작할 때와 실행 중 모두 자체시험과 무결성 검증을 수행하며 실패 시 안전하게 종료한다.

 

검증 자동화 - 요구사항 검사는 어떻게 자동화되는가

검사기는 문서를 읽는 것이 아니라 실제 서버(IP카메라)에 접속하여 로그인, 공격 시도 등을 수행하면서 보안기능을 검사한다. HTTPS(8443)로 접속하여 실제 동작을 확인한 뒤 PASS/FAIL과 함께 해당 NIS 조항 번호를 출력한다. 총 38개의 세부 항목을 자동으로 판정하며 사람이 읽는 요구사항 문서를 기계가 검사하는 코드로 변환한 것이다.

 

Validator 검사 항목

Validator는 TLS 버전(TLS 1.2 이상), 암호 스위트(112bit 이상), 불필요한 포트 차단, 인증 실패 5회 잠금, 동일 계정 중복 로그인 차단, 유휴 세션 만료, 패스워드 정책, IP 범위 차단, 계정명 제한, 감사기록 생성 등을 검사한다. 세부 검사 입력을 포함하여 총 38개 항목을 자동으로 PASS/FAIL 판정하며, 각 결과에는 해당 NIS 조항 번호가 함께 표시된다.

 

심사의 벽 - 왜 어렵고 오래 걸리는가

1. 문서의 벽 : 제출문서 5종을 모두 한국어로 작성해야 하며, 구현명세서에는 모든 인터페이스와 계정을 기재해야 한다. 미기재 항목이 발견되면 백도어로 간주되어 확인서 발급이 거부된다.
2. 이력의 벽 : 신청일 기준 최근 3년간 공개 취약점(CVE 등)에 대한 개선 내역을 제출해야 한다.
3. 요구사항의 벽 : 공통 9대 분류와 제품별 요구사항을 구현, 문서, 시험과 1:1로 연결한 추적매트릭스를 작성해야 한다.
4. 시간의 벽 : 권장 시험기간은 공통 요구사항 35~40일, 제품 요구사항 5~10일이며 부적합 판정을 받으면 보완 후 다시 시험을 진행한다.
5. 유지의 벽 : 확인서 유효기간은 일반 제품 5년, 신기술 제품 2년이며 버전 변경 시 추가시험이나 동일성 확인시험을 받아야 한다.

핵심 : 어려운 이유는 관료주의 때문이 아니라 증명 가능한 보안을 요구하기 때문이다.

 

AI가 가속하는 것들

AI는 코드 주석 기반 추적매트릭스 자동 생성, 요구사항 해석과 체크리스트 작성, 구현명세서 초안 생성, 공개 취약점(CVE) 조사 자동화, 자동 검증기 생성 등을 지원한다. 실제 예제 프로젝트도 AI를 활용하여 요구사항 구현, 자동 검증기, 추적매트릭스, 검증 리포트를 단기간에 구축하였다. 하지만 검증필 모듈 사용 여부, 시험기관의 심사, 최종 책임은 AI가 대신할 수 없다. AI는 준비를 가속하고 보증은 제도가 수행한다.

 

방법론 - 조항 주석 하나로 도는 6단계 루프

1. 요구사항을 AI에 입력하여 체크리스트를 생성한다.
2. 모든 보안 기능 구현부에 # [NIS 조항번호] 주석을 작성한다.
3. AI와 함께 조항 단위로 구현하며 수치(5회, 5분, 9자리 등)를 프롬프트에 명시한다.
4. 코드의 NIS 주석을 스캔하여 추적매트릭스를 자동 생성하고 미구현 조항을 확인한다.
5. 요구사항의 시험 방법을 이용해 PASS/FAIL을 판정하는 자동 검증기를 생성한다.
6. 코드와 추적매트릭스를 기반으로 구현명세서, 검증 리포트, CVE 개선내역 초안을 생성한다.

루프는 검증기 전 항목 PASS와 추적매트릭스 미구현 항목 0개가 될 때까지 반복한다. 자동화의 핵심은 코드에 작성하는 NIS 조항 주석이다.

 

실전 - AI에게 이렇게 시킨다

AI에게는 조항 번호, 구체적인 수치, 원하는 산출물 형태를 함께 제시해야 한다.

1. "IP카메라 요구사항 2.2.1을 구현해줘. 인증 실패 5회 후 계정 잠금, 5분 후 자동 해제, 감사기록 생성, 구현부마다 [NIS 2.2.1] 주석을 달아줘."
2. "코드 전체에서 [NIS *] 주석을 스캔하여 조항-파일-함수 추적매트릭스를 만들고 미구현 조항을 표시해줘."
3. "TLS 1.0/1.1 차단, 인증 실패 5회 잠금 등을 검사하는 Validator를 만들고 조항 번호와 함께 PASS/FAIL을 출력해줘."

AI가 생성한 결과는 초안이므로 반드시 원문 요구사항과 비교하여 검수해야 한다. 검수 없는 자동화는 백도어 규칙을 통과할 수 없다. 핵심은 조항 번호, 구체적인 수치, 원하는 산출물 형태를 프롬프트에 함께 제시하는 것이다.