HSM 공급업체를 선택하는 방법

다양한 HSM 공급업체를 분석할 때는 해당 공급업체의 포트폴리오와 구현 중 지원을 고려하는 것이 좋습니다. 우선, 공급업체가 다양한 HSM 솔루션을 제공하고 모든 종류의 애플리케이션을 지원하는지 확인해야 합니다. 광범위한 범용 및 결제 애플리케이션을 통해 다양한 배포 모델(온프레미스, 클라우드 및 하이브리드)에서 펌웨어 및 소프트웨어 옵션의 모든 조합을 지원할 수 있습니다. 이를 통해 회사의 필요에 맞는 솔루션을 선택할 수 있습니다.

알고 계셨나요?
ABI Research의 최신 하드웨어 보안 모듈 OEM 경쟁력 평가에서 Utimaco가 HSM 시장의 '최고 구현업체'로 선정되었습니다. Utimaco 포트폴리오는 가장 포괄적이고 다양한 솔루션을 제공하며 모든 유형의 애플리케이션, 모든 가격대(엔트리 레벨부터 최고급까지), 다양한 폼 팩터에 서비스를 제공합니다. 보고서에 따르면, '이는 다양한(그리고 여러) 펌웨어 스택과 소프트웨어 옵션을 추가할 수 있고 클라우드 지원 API(애플리케이션 프로그램 인터페이스)를 포함하는 통일된 기본 하드웨어 플랫폼을 구축하는 기반에서 작업해왔기 때문에 가능한 일'이라고 합니다.

다음 사항을 고려하세요:

• 성능 - 각 유형의 HSM에 대한 성능 요소를 살펴보되, 특히 사용 사례(암호화/복호화/키 생성/서명, 대칭, 비대칭, EC 등)에 초점을 맞추세요. 실제 성능 수치에 대해 문의하세요(예: 네트워크 연결형 HSM의 경우 네트워크 구성에 대해 문의하거나 임베디드 카드의 경우 PCIe 버스 이후에 출시된 표준에 대해 문의하세요).
• 확장성 - 애플리케이션과 관련하여 확장성 측면에서 제한적인 요소는 무엇인가요? HSM에 정해진 수의 키를 저장해야 하나요? 다른 HSM을 어떻게 추가할 수 있나요? 이것이 얼마나 쉬울까요?
• 중복성 - 하나의 HSM이 중단되면 어떻게 되나요? 이것이 운영에 얼마나 영향을 미칠까요? 서비스 손실 없이 얼마나 쉽게 교체할 수 있나요?
• 백업 - 백업 및 복원 프로세스는 어떻게 수행되나요? 이러한 프로세스를 구현하는 데 조직이 얼마나 많은 노력을 기울여야 하나요? 복구 불가능한 데이터 손실을 피할 수 있나요?
• API 지원 - API는 애플리케이션-호스트 환경에 대한 연결입니다. 다음은 지원되는 API에 관한 질문을 처리하기 위한 몇 가지 힌트입니다:

1. Microsoft MS CSP/CNG: Microsoft "표준" API는 Windows를 사용할 때 HSM에 연결하는 가장 쉬운 방법입니다;

2. JCE: "표준" Java 개발자.

3. PKCS#11: "업계 표준"이지만 알려진 보안 문제 및 공급업체 독점 확장 프로그램과 같은 몇 가지 함정이 있습니다. 주의: 공급업체 독점 확장 또는 메커니즘은 사용 사례별 API 확장이며 PKCS#11 표준의 일부가 아닙니다. 따라서 공급업체를 변경할 때 비용이 증가할 수 있습니다.

4. REST API: REST는 대표 상태 전송의 약자입니다. 개발자는 OpenAPI 기반 REST 암호화 API(RCAPI)를 사용하여 보안 TLS 1.3 프로토콜을 통해 간단한 HTTP 기반 인터페이스를 통해 HSM과 통신할 수 있습니다. 이를 통해 서비스 아키텍처가 있는 애플리케이션에서 일반적으로 사용하는 것과 동일한 인터페이스를 통해 암호화 작업을 원활하게 통합할 수 있습니다.

사용 사례 및 운영 체제와 호환되는 API를 선택합니다. Microsoft OS를 사용하는 경우 CNG를 선택합니다. PKCS#11을 지원하는 애플리케이션을 사용하는 경우 PKCS#11을 선택합니다. 통합에 대한 안내 또는 사용 방법 가이드를 요청하세요.

• OS/하드웨어 지원 - 여기에는 고려해야 할 여러 가지 문제가 있습니다. 첫 번째는 다음과 같습니다: 임베디드 카드(PCIe-Driver)가 지원하는 운영 체제는 무엇인가요? 또 다른 문제입니다: 네트워크 연결 HSM이 지원하는 운영 체제는 무엇인가요? 또한: 관리 도구(예: GUI/커맨드 라인)가 지원하는 OS는 무엇인가요?
• 관리 - HSM을 원격으로 관리할 수 있나요? 어떤 기능을 원격으로 활성화하고 제어할 수 있나요?
• 프로그래밍 가능성 - 대부분의 개발은 API의 다른 쪽 끝에서 이루어지지만, 때로는 유연성이나 속도를 높이고 API를 지정하기 위해 디바이스에서 실행되는 애플리케이션을 작성할 수 있는 기능이 유용할 수 있습니다.
• 물리적 보안 - 스스로에게 질문해 보세요: 솔루션이 직접적인 물리적 공격에 얼마나 견딜 수 있어야 할까요? 어떤 이유로든 이 기능이 특히 중요하다고 판단되면 '수동적인 변조 방지 및 증거'가 아닌 '능동적인 변조 감지 및 대응'을 고려할 수 있습니다. 또는 FIPS 140-2(또는 2026년 9월 21일에 이전 버전을 완전히 대체할 예정인 FIPS 140-3)와 관련하여 FIPS 140-2 레벨 4 물리적을 찾거나 기존의 FIPS 140-2 레벨 3을 고수할 수도 있습니다.
• 알고리즘 - 선택한 API(기본 요소, 작동 모드 및 매개 변수(예: 커브, 키 크기)를 통해 HSM이 사용하려는 암호화 알고리즘을 지원하나요?
• 포스트 퀀텀 암호화(PQC) - HSM이 이미 포스트 퀀텀 암호화 알고리즘을 지원하나요? 모든 PQC 알고리즘이 필요한 사용 사례를 지원하나요? 공급업체가 PQC 마이그레이션을 지원하나요?
• 인증 옵션 - 비밀번호, 쿼럼, N-팩터, 스마트 카드 등. 최소한 키를 사용하여 작업을 허용하기 전에 구성 가능한 쿼럼 크기 또는 비밀번호로 인증된 사용자를 필요로 하는 것을 찾아야 합니다.
• 정책 옵션 - HSM에서 키를 내보낼 수 있는지(래핑 또는 암호화되지 않은 상태로), 키는 서명/암호화/복호화/...에만 사용할 수 있는지, 서명에는 인증이 필요하지만 확인에는 필요하지 않은지 등을 제어하는 등 정책을 정의할 수 있어야 할 수 있습니다.
• 감사 기능 - HSM과 유사한 작업(생성된 키, Y 키로 서명된 것)과 연결 문제 또는 충돌 처리를 모두 포함합니다. 로그를 모니터링 시스템에 얼마나 쉽게 통합할 수 있나요(syslog/snmp/기타 네트워크에서 액세스할 수 있거나 적어도 독점적이지 않은 출력)?

하드웨어 보안 모듈은 온프레미스, 호스팅 또는 클라우드에서 서비스로 운영할 수 있습니다.

온프레미스 배포는 다음과 같은 옵션을 제공합니다:

• 네트워크 연결 HSM: 대규모 배포, 특히 여러 애플리케이션/서버/클라이언트가 HSM 서비스를 활용해야 하는 경우에 적합합니다.
• 임베디드 HSM(PCIe 카드): 네트워크 연결 HSM에 비해 더 비용 효율적인 솔루션입니다. 이러한 유형의 솔루션은 여러 애플리케이션을 동시에 실행하기 위해 더 높은 처리 능력이 필요하다는 점에 유의할 필요가 있습니다.
• 확장 가능한 컨테이너형 HSM: 진정한 멀티테넌트 솔루션(예: 독립적인 클라이언트 계정을 운영하는 클라우드 플랫폼)의 경우, 컨테이너당 배포, 정책, 펌웨어 등 독립적인 HSM을 실행할 수 있습니다. 하나의 단일 펌웨어 또는 정책 엔진으로 운영되는 취약한 멀티테넌트 솔루션은 사용하지 않는 것이 좋습니다.

호스팅 또는 서비스형 솔루션

• 호스팅 또는 서비스형 솔루션은 클라우드에서 물리적으로 독립적인 HSM을 제공합니다: 이 솔루션은 무단 물리적 액세스에 대해 최고 수준의 물리적 보호 기능을 제공하며 테넌트당 FIPS 140-2, 레벨 4를 이상적으로 준수합니다. 그러나 이러한 솔루션의 확장성은 로컬에 배포된 물리적 서버 수준에서만 가능합니다.
• 전체 또는 부분적으로 관리되는 공유 HSM을 제공하는 서비스형 솔루션. 키 관리와 같은 관리 기능은 서비스 솔루션의 일부가 될 수도 있고 고객이 온프레미스 또는 다른 클라우드에서 수행할 수도 있습니다.
• 서비스형 솔루션은 컨테이너화된 HSM에서 테넌트를 제공하며, 테넌트별로 FIPS 140-2 레벨 3을 보호합니다. 이러한 컨테이너는 테넌트별로 개별 정책과 펌웨어를 제공하며 클라우드의 확장성 이점을 제공합니다. 클라우드 서비스 공급자(CSP)의 인프라 외부에 있으며 암호화 요구 사항에 대한 고객의 완전한 제어권을 유지합니다

• CSP의 HSM-클러스터 사용: 클라우드 플랫폼의 서비스(AWS, Azure, Google Cloud 포함)의 혜택을 누릴 수 있습니다. 키에 대한 제어가 제한됩니다.
  
   

  

• 인증 - 잘못된 해석이 가장 많이 발생하는 분야 중 하나입니다. FIPS 140-2 레벨 3 인증 제품을 구입하는 경우 소위 FIPS 모드로 전환해야 합니다. FIPS 모드는 API 수준 제한, 알고리즘 제한(키 길이, 사용량, 키 속성 등)을 의미합니다. 스스로 질문해 보세요: 실제로 어떤 수준이 필요한가요? 규제상의 이유로 무엇이 필요한가요?
• FIPS 140 -3 - FIPS 140-3은 2026년 9월 21일에 이전 버전(FIPS 140-2)을 완전히 대체할 예정입니다. 실제로 2022년 4월 1일부터 모든 신규 제출물은 FIPS 140-3의 요구 사항을 충족해야 합니다. 암호화 모듈 검증 프로그램(CMVP)을 통해 검증된 이 업데이트된 표준은 연방 부처 및 기관의 암호화 보안에 대한 보다 강력하고 현대적인 접근 방식을 보장합니다.
• 공통 기준 - 제품 평가는 보증을 제공하는 측면에서 더 다양할 수 있습니다: 보안 목표 읽기! 현재로서는 제대로 된 HSM 보호 프로필 세트가 하나밖에 없으므로 최소한 보안 문제 정의(위협 및 가정)를 읽어야 평가가 무엇을 제공하는지 알 수 있습니다.
• 기타 인증 스키마 - PCI-HSM, DK 승인 또는 NITES(싱가포르 CC 승인)와 같이 관련 업계에 종사하는 경우 이러한 스키마가 유용할 것입니다. 인증 외에도 관련 산업 분야 또는 정부 기관에 대한 구체적인 참조 자료를 요청하세요.

ISO 인증 소프트웨어 개발 라이프사이클에 대한 이야기에만 의존하지 마세요.

Utimaco는 PCI-HSM과 FIPS 140-2 또는 3을 모두 준수하는 HSM 솔루션을 제공할 수 있습니다(또는 필요하지 않은 경우 전혀 제공하지 않을 수도 있음).

• 공급업체는 어떤 지원을 제공하나요? 다양한 유형의 옵션만 고려하지 말고 평판과 몇 가지 테스트에 대해 물어보세요!
• 공급업체는 어떤 종류의 통합 서비스를 제공하나요? 복잡한 요구사항이 있는 경우 구성/프로그래밍 프로세스에 공급업체를 참여시키는 것이 좋습니다.
• 로드맵은 어떻게 되어 있나요? 향후 몇 년 내에 발생할 것으로 예상되는 문제가 있나요?
• 원산지는 어디인가요(설계 및 제조)?

기존/수명이 다한 HSM을 교체할 때 독점 솔루션은 연결된 모든 애플리케이션을 변경해야 할 수 있습니다. 가장 바람직한 솔루션은 애플리케이션에 구애받지 않고 암호화에 민첩하게 대응할 수 있는 HSM을 선택하는 것입니다:

• 관련 키 및 키 블록 호스팅
• 주요 키 관리 시스템에 연결합니다
• 문서화된 애플리케이션 기록을 통해 일반적인 산업 등급의 앱에 연결합니다

그 결과, 서비스 주기에 따라 많은 시간이나 인력을 투자하지 않고도 빠르게 교체할 수 있습니다.

• 비용 - 단위당 비용은 어떻게 되나요? 지원 및 유지보수 비용은 어떻게 되나요? 단가에는 무엇이 포함되나요? API 단위로 비용을 지불하나요?
• 리드 타임 -현실적으로 생각하세요! HSM이 당장 필요하다고 생각한다면 HSM의 복잡성을 과소평가하고 있는 것일 수 있습니다. HSM은 대량 생산되는 것이 아니므로 품질을 보장하기 위해 일정 시간이 필요합니다.

Utimaco의 HSM에 대해 자세히 알아보려면 제품 페이지를 확인하거나 문의하세요.