총 4건
-
짧아지는 인증서 유효기간, 발급부터 서비스 적용까지 어떻게 관리할까?
짧아지는 인증서 유효기간, 발급부터 서비스 적용까지 | ADOST ADOST TECH INSIGHT · CERTIFICATE LIFECYCLE MANAGEMENT 짧아지는 인증서 유효기간,발급부터 서비스 적용까지 어떻게 관리할까? CLM의 역할부터 갱신·배포 자동화와 도입 검증까지 인증서 기반 신뢰와 수명주기 자동화를 표현한 AI 생성 개념 이미지. 실제 제품 화면이 아닙니다. 웹사이트와 모바일 서비스, 기업 내부의 API 통신에는 디지털 인증서가 사용됩니다. 인증서는 통신 상대방의 신원을 확인하고 안전한 연결을 구성하는 기반입니다. 그러나 인증서가 만료되거나 교체 작업이 제대로 반영되지 않으면 사용자 접속과 시스템 간 통신에 문제가 발생할 수 있습니다. 기업이 확인해야 할 것은 어디에 어떤 인증서가 사용되며, 누가 책임지고, 어떤 절차로 교체하는지입니다. 인증서 유효기간이 짧아지는 환경에서는 발급과 배포, 적용 확인을 반복 수행할 수 있는 운영 체계가 필요합니다. 공개 TLS 인증서의 최대 유효기간이 47일까지 줄어듭니다 CA/Browser Forum의 기준에 따라 공개 신뢰 TLS 서버 인증서의 최대 유효기간은 단계적으로 단축됩니다. 2026년 10월 현재 적용되는 상한은 200일이며, 이후 100일과 47일로 줄어듭니다. 발급 시점 기준의 최대 유효기간. 2029년 3월 15일부터는 도메인·IP 주소 검증 결과의 최대 재사용 기간도 10일로 줄어듭니다. 인증서의 유효기간과 별도의 기준으로, 발급 시 과거 검증 결과를 재사용할 수 있는 기간을 뜻합니다. 따라서 인증서를 교체하는 절차와 함께 발급에 필요한 검증 절차도 점검해야 합니다. CA/Browser Forum 공식 기준 교체 주기가 짧아질수록, 반복 작업의 완성도가 중요합니다. 신청·검증·발급·배포·적용 확인을 더 자주 수행해야 합니다. 여러 장비에 설치된 인증서는 각 위치의 교체 결과까지 추적해야 합니다. CLM은 인증서와 실제 사용 환경을 함께 관리합니다 CLM(Certificate Lifecycle Management, 인증서 수명주기 관리)은 인증서의 탐지, 발급, 배포, 갱신, 폐기와 관련 이력을 관리하는 체계입니다. 인증서 파일뿐 아니라 연결된 서비스와 설치 위치, 담당자, 적용 정책을 함께 파악해야 실제 운영에 활용할 수 있습니다. 관리 정보 운영에서 확인할 내용 인증서·서비스 어떤 도메인과 서비스에 사용하는가? 설치 위치 어느 서버·로드밸런서·클라우드 서비스에 적용되어 있는가? 유효기간·CA 언제 교체하며 어느 인증기관을 통해 발급하는가? 담당자·정책 갱신 승인과 장애 대응은 누가 맡으며 어떤 기준을 따르는가? 작업 상태 새 인증서의 발급, 배포, 적용 확인이 각각 완료되었는가? NIST도 인증서 인벤토리와 담당자 추적, 자동 발급·설치·갱신, 지속적인 상태 모니터링을 인증서 관리 아키텍처의 주요 요소로 제시합니다. NIST 참조 아키텍처 갱신에 성공했는데도 장애가 발생하는 이유 고객 포털을 로드밸런서 두 대로 운영하는 상황을 가정해 보겠습니다. 만료 전에 새 인증서를 발급받았지만 두 번째 장비의 배포 작업이 실패했다면, 해당 장비에는 기존 인증서가 남습니다. 기존 인증서가 만료된 뒤 이 장비로 연결되는 사용자에게 접속 오류가 발생할 수 있습니다. 인증서 발급이 완료된 상태와 서비스 교체가 완료된 상태를 구분해야 합니다. 각 장비의 설치 결과, 설정이 참조하는 인증서, 필요한 설정 재적용 여부, 실제 연결에서 제공되는 인증서와 체인을 확인해야 합니다. 발급 완료 CA에서 새로운 인증서를 받았습니다. 아직 대상 장비에 적용되지 않았을 수 있습니다. 서비스 적용 완료 모든 대상의 배포 결과와 실제 연결을 점검했습니다. 실패한 위치는 후속 조치로 연결합니다. 위 로드밸런서 사례는 운영 문제를 설명하기 위한 가상 예시입니다. 탐지부터 서비스 검증까지, 자동화 흐름을 연결합니다 CLM 운영 개념도. 실제 단계와 자동화 범위는 제품 및 연동 환경에 따라 달라집니다. 먼저 인증서를 탐지하고 서비스 담당자와 사용 위치를 연결합니다. 이후 발급기관, 승인 절차, 갱신 시점을 정책으로 정하고 발급·배포 작업을 수행합니다. 마지막에는 실제 연결 상태를 확인하고, 작업 결과를 다음 운영에 활용할 수 있도록 기록합니다. 갱신 시점은 인증서 수명과 검증·승인·배포에 걸리는 시간을 고려해 정해야 합니다. 자동화 설계에는 정상 흐름뿐 아니라 검증 실패, CA 연결 오류, 장비 접근 실패가 발생했을 때의 재시도와 담당자 통보 절차도 포함하는 것이 좋습니다. ACME와 기존 운영 도구는 어떻게 활용할까요? ACME(Automated Certificate Management Environment)는 인증서 발급과 도메인 검증 절차를 자동화하기 위한 표준 프로토콜입니다. 지원하는 CA와 클라이언트를 연결하면 반복적인 발급 작업을 자동화할 수 있습니다. IETF RFC 8555 DNS 기반 검증을 선택한다면 필요한 검증 레코드를 생성하는 과정까지 연계할 수 있습니다. 이때 DNS 변경 권한과 접근 정보의 보호 방법도 함께 설계해야 합니다. 기존 인증서 자동화 도구를 사용 중이라면, 역할을 유지하면서 중앙 현황 관리와 배포 결과 확인에 연계하는 방식도 검토할 수 있습니다. PKI·HSM·CLM은 역할을 나누어 연결합니다 구분 핵심 역할 설계 질문 PKI / CA 인증서 발급과 신뢰 체계 제공 어떤 CA와 발급 정책을 사용하는가? CLM 인증서 수명주기와 운영 절차 관리 발급·배포·갱신·검증을 어떻게 연결하는가? HSM 중요 개인키 보호와 암호 연산 어떤 키를 어디서 생성·보관·사용하는가? 개인키는 인증서와 구분해 다뤄야 합니다. 인증서는 공개될 수 있지만 개인키는 비밀로 보호해야 합니다. 자동화를 위해 모든 개인키를 중앙에 모아야 하는 것은 아닙니다. 대상 시스템이나 HSM에서 키를 생성하고 외부 반출 없이 사용하는 구성도 지원 범위에 따라 검토할 수 있습니다. NIST는 TLS 서버의 중요도와 위험을 평가해 개인키 보호 수준을 결정하도록 권고합니다. NIST 개인키 보호 및 운영 권고사항 도입 검증은 실제 운영 조건에서 진행해야 합니다 아래 항목은 초기 검증 계획의 예시입니다. 실제 사용하는 CA와 장비를 포함하고, 정상 작업과 실패 상황을 함께 점검하는 방식으로 범위를 정할 수 있습니다. 검증 항목 확인 방법 탐지 범위 기존 목록과 탐지 결과를 비교하고 누락 원인을 확인합니다. CA 연동 사용하는 CA에서 검증·발급·갱신이 완료되는지 확인합니다. 다중 장비 배포 동일 서비스의 모든 장비에 새 인증서가 반영되는지 확인합니다. 실패 대응 시험 환경에서 접근 오류 등을 발생시켜 알림·재시도·담당자 연결을 확인합니다. 긴급 교체 키 유출을 가정해 새 키·인증서 교체와 기존 인증서 폐기 절차를 확인합니다. 권한·감사 요청자·승인자·작업 계정의 권한과 변경 이력을 확인합니다. 인증서 폐기는 CA에 인증서의 유효성을 철회하도록 요청하는 작업으로, 서버에서 파일을 삭제하는 것과 구분됩니다. 키 유출이 의심되는 경우에는 새로운 키로 교체하는 절차도 필요합니다. 자동화 시스템의 연동 계정과 접근 정보 역시 필요한 권한 범위로 제한해 보호해야 합니다. 도입 전 함께 확인할 네 가지 ① 인증서와 설치 위치의 누락 여부② CA·서버·장비의 연동 범위③ 배포 후 정상 적용을 확인하는 방법④ 실패·긴급 교체 상황의 대응 절차 인증서 관리는 반복 가능한 운영 체계로 완성됩니다 CLM 도입은 인증서 현황과 담당자를 파악하는 데서 시작할 수 있습니다. 이후 업무 영향도가 높은 서비스를 선정해 발급부터 적용 확인까지 검증한 뒤 적용 범위를 넓히는 방식으로 추진할 수 있습니다. 성과는 관리 목록의 인증서 수와 함께 정해진 기한 내 갱신·배포 완료율, 배포 실패 건수, 담당자 미지정 인증서 수 등으로 확인할 수 있습니다. 인증서를 제때 교체하고 서비스의 정상 동작을 확인할 수 있는 운영 역량을 갖추는 것이 CLM의 실질적인 활용 방향입니다. 기업의 인증서 관리 자동화를 검토 중이신가요? ADOST와 함께 현재 인증서 운영 환경과 CLM 적용 범위를 검토해 보세요. 사용 중인 인증기관과 서버·클라우드 구성, 갱신·배포 절차를 바탕으로 필요한 구성을 논의할 수 있습니다. 문의하기 → 자료 및 기준CA/Browser Forum TLS Baseline Requirements v2.3.1(§4.2.1·§6.3.2), NIST SP 1800-16, IETF RFC 8555. 기준 확인일: 2026년 10월 6일. 대표 이미지: AI 생성 개념 이미지. 일정 및 운영 도식: 본 칼럼용 제작. 본문의 가상 사례와 검증 항목은 이해를 돕기 위한 예시이며, 기능과 연동 범위는 제품·버전 및 구축 환경에 따라 확인해야 합니다.
-
업무를 수행하는 AI Agent, 새로운 보안 관리가 필요한 이유
ADOST TECH INSIGHT · AGENTIC AI 업무를 수행하는 AI Agent,새로운 보안 관리가 필요한 이유 질문에 답하는 AI에서 스스로 업무를 수행하는 AI Agent로의 진화, 그리고 기업 환경에서 새롭게 요구되는 보안 전략. AI → GENERATIVE AI → AI AGENT 답변하는 AI를 넘어,업무를 수행하는 AI로 AI Agent는 목표를 이해하고 필요한 도구와 시스템을 활용해 여러 단계의 작업을 수행할 수 있습니다. AI 우리가 알고 있는 AI, 그리고 AI Agent ChatGPT를 비롯한 생성형 AI가 빠르게 확산되면서 문서 요약, 이메일 작성, 정보 검색, 코드 작성 등 다양한 업무에서 AI를 활용하는 모습이 익숙해졌습니다. 그런데 최근에는 AI Agent(인공지능 에이전트)라는 용어가 자주 등장합니다. AI Agent 역시 AI를 기반으로 하지만, 단순히 질문에 답하거나 콘텐츠를 생성하는 것에서 한 단계 더 나아갑니다. AI와 AI Agent의 가장 큰 차이는 무엇일까요? GENERATIVE AI 답변하고 생성하는 AI 사용자의 질문이나 입력을 바탕으로 답변, 문서, 이미지, 코드와 같은 결과물을 생성합니다. 사용자 요청 → AI → 답변·콘텐츠 생성 AI AGENT 목표를 받아 업무를 수행하는 AI 목표를 이해하고 필요한 작업을 판단하여, 허용된 도구와 시스템을 활용해 여러 단계를 수행합니다. 목표 → 판단 → 도구 사용 → 실행 → 결과 확인 예를 들어, “다음 주 고객 미팅 준비해줘”라고 한다면? 일반적인 생성형 AI는 미팅 준비 방법이나 체크리스트를 작성해 줄 수 있습니다. 반면 업무 시스템과 연결된 AI Agent라면, 부여된 권한 범위 안에서 일정과 관련 자료를 확인하고 필요한 정보를 정리하는 등 여러 작업을 이어서 수행할 수 있습니다. 01목표 이해무엇을 준비해야 하는지 파악 02작업 판단필요한 업무와 순서 결정 03도구 사용메일·문서·API 등 활용 04업무 수행허용된 범위에서 작업 실행 05결과 확인결과 확인 후 다음 작업 수행 ※ AI Agent의 자율성, 기능 및 실제 수행 범위는 구현 방식과 연결된 시스템, 부여된 권한에 따라 달라질 수 있습니다. WHY AGENTIC AI SECURITY? AI Agent가 실제 업무를 시작하면,보안의 대상도 달라집니다. AI Agent가 업무를 수행하려면 데이터베이스, API, 업무 시스템, 클라우드 자원 등 기업의 다양한 자원에 접근할 수 있습니다. 따라서 보안 관점에서는 단순한 AI 기능이 아니라 권한을 가진 디지털 행위 주체로 바라볼 필요가 있습니다. DATABASE데이터 조회·처리 API서비스 및 기능 호출 CLOUD클라우드 자원 접근 BUSINESS APP업무 시스템 사용 특히 Agent가 API Key, Token, Secret 등의 인증정보와 높은 권한을 사용한다면, 과도한 권한이나 탈취된 자격 증명, 비정상적인 행위에 대한 새로운 통제 체계가 필요해집니다. AI Agent도 하나의 Identity로 관리해야 합니다 기업은 지금까지 직원과 관리자 같은 Human Identity, 서버·애플리케이션·워크로드와 같은 Machine Identity를 관리해 왔습니다. AI Agent가 기업 시스템에 직접 접근해 업무를 수행하기 시작하면서 이제는 Agentic Identity도 중요한 보안 관리 대상으로 확장되고 있습니다. HUMANHuman Identity직원 · 관리자 · 개발자 → AGENTICAI Agent Identity판단하고 업무를 수행하는 디지털 행위 주체 → RESOURCETarget ResourcesDB · API · Cloud · SaaS 그렇다면 “AI Agent에게 어디까지 권한을 허용할 것인가?”가 중요한 보안 질문이 됩니다. AI Agent 보안에서 확인해야 할 네 가지 DISCOVER 에이전트 가시성 확보 어떤 AI Agent가 존재하고, 누가 소유하며, 어떤 자원에 접근하는지 식별합니다. LEAST PRIVILEGE 최소 권한 통제 업무에 필요한 범위와 시간 동안만 권한을 부여하고, 불필요한 상시 권한을 줄입니다. AUDIT 행위 감사 및 추적 어떤 사용자와 Agent가 어떤 자원에 접근하고 무엇을 수행했는지 추적할 수 있어야 합니다. LIFECYCLE & RESPONSE 수명주기와 이상행동 관리 Agent의 생성·사용·변경·중지를 관리하고, 비정상적인 행위가 확인되면 제한하거나 중지할 수 있어야 합니다. AI Agent 시대의 보안은 단순히 “AI를 안전하게 사용할 것인가?”를 넘어,“AI Agent에게 무엇을, 언제, 어디까지 허용할 것인가?”를 관리하는 문제로 확장되고 있습니다. 사람과 머신을 넘어, AI Agent까지 AI Agent가 기업의 실제 업무에 참여할수록 Agent의 식별, 권한, 접근, 행위 이력을 함께 관리하는 것이 중요해집니다. 조직 내 Agent를 발견하고, 필요한 범위에서만 권한을 부여하며, 업무가 끝난 후 권한을 회수하고, 수행한 행위를 감사할 수 있는 체계가 필요합니다. 에이전틱 AI 보안을 검토하고 계신가요? AI Agent Discovery, 최소 권한 접근, 권한 회수, 행위 감사 및 수명주기 관리 등 조직의 Agentic AI 운영 환경에 필요한 보안 체계를 함께 검토해 보세요. ADOST 문의하기 → 참고 자료Palo Alto Networks, IDIRA Identity Security Platform 자료 ※ AI Agent의 기능, 접근 방식 및 보안 통제 방법은 적용 솔루션과 구축 환경에 따라 달라질 수 있습니다.
-
디지털 자산 플랫폼의 키 보호와 거래 서명, 어떻게 설계할까?
디지털 자산 플랫폼의 HSM 키 보호 및 거래 서명 ADOST TECH INSIGHT · DIGITAL ASSETS 디지털 자산 플랫폼의 핵심,키 보호와 거래 서명은 어떻게 설계할까? MPC·멀티시그와 HSM의 관계부터 플랫폼 협업과 해외 구축 사례까지 이미지: Thales 제공 발표자료 디지털 자산 플랫폼과 커스터디(수탁) 서비스를 도입할 때 지갑 기능과 지원 자산만큼 중요한 것이 개인키의 통제권과 거래 서명 구조입니다. 스테이블코인 발행, 토큰화 자산, 디지털 자산 수탁은 업무마다 승인 절차와 거래량이 다릅니다. 따라서 플랫폼과 보안 장비의 기능을 따로 살피는 데서 그치지 않고, 실제 거래가 어떤 경로로 승인되고 서명되는지 함께 확인해야 합니다. MPC·멀티시그·HSM은 각각 무엇을 담당할까요? MPC는 여러 참여자가 키를 나누어 연산하는 방식이고, 멀티시그는 거래 성립에 여러 서명을 요구하는 방식입니다. HSM은 개인키 또는 구성에 따른 키 재료를 보호하고 암호 연산을 수행하는 하드웨어 신뢰 기반입니다. 세 기술은 선택지 하나로 묶이지 않습니다. 지갑의 구현 방식에 따라 함께 쓰일 수 있으며, 어디에서 키를 생성하고 누가 서명을 승인하며 어떤 연산이 HSM 안에서 수행되는지가 설계의 핵심입니다. MPC 키와 서명 연산을 여러 참여자에게 분산 멀티시그 정해진 수의 별도 서명으로 거래 승인 HSM 키 보호, 접근 통제와 하드웨어 기반 서명 연산 ※ MPC·멀티시그와 HSM의 결합 방식은 각 지갑 플랫폼의 기술 구조에 따라 다릅니다. 플랫폼과 HSM은 함께 검증해야 합니다 디지털 자산 프로젝트에는 지갑·수탁 플랫폼, 블록체인 네트워크, 구축사와 보안 담당자가 함께 참여합니다. 각 제품이 개별적으로 요구사항을 충족해도 실제 업무에서 안정적으로 동작하려면 연동 검증이 필요합니다. 예를 들어 서명 요청이 HSM에 도달하는 경로, 승인 정책의 적용 위치, 장애 전환 시 키 사용 방식, 거래가 집중될 때의 처리량과 응답 시간을 함께 살펴야 합니다. 함께 확인할 네 가지① 키의 생성·보관과 소유권 ② 승인 정책과 서명 경로③ 장애 전환·백업·복구 ④ 실제 거래 패턴에서의 성능 핫·웜·콜드 지갑은 거래 빈도와 승인 시간이 서로 다릅니다. 따라서 플랫폼 공급사와 HSM 전문 인력이 초기부터 함께 서명 흐름을 설계하고, 실제 업무에 가까운 조건에서 기능과 성능을 검증하는 과정이 중요합니다. 이미 연결된 디지털 자산·커스터디 생태계 Thales는 여러 디지털 자산 플랫폼 및 블록체인 기업과의 협업·연동 사례를 소개하고 있습니다. 플랫폼의 워크플로와 고객이 통제하는 HSM 기반 키 보호를 연결하는 방식은 사업자가 기존 플랫폼을 검토할 때 참고할 만합니다. Thales 제공 발표자료의 디지털 자산 생태계. 기업별 협업 범위는 각 솔루션에 따라 다릅니다. Fireblocks + ThalesFireblocks KeyLink를 통해 Fireblocks 플랫폼의 디지털 자산 서명 흐름과 고객 소유 Luna HSM을 연결하는 공동 솔루션입니다. 솔루션 보기 Dfns + ThalesDfns의 지갑·정책·거래 워크플로와 Luna HSM의 키 보호·서명 기능을 결합한 공동 솔루션입니다. 솔루션 보기 Kaleido + ThalesKaleido의 기업용 디지털 자산·블록체인 플랫폼은 Luna HSM을 연계해 블록체인 자산을 통제하는 개인키의 보관과 서명에 활용할 수 있습니다. 파트너 소개 보기 Ripple + ThalesRipple은 Thales의 디지털 자산 기술 생태계에 포함된 협력 기업입니다. 디지털 자산 서비스에서 필요한 키 보호와 거래 서명 구조는 적용 플랫폼과 업무 요건에 맞춰 함께 검토할 수 있습니다. 세부 구현 방식은 프로젝트별로 협의합니다. Taurus + ThalesTaurus의 디지털 자산 커스터디(수탁) 플랫폼과 Thales HSM을 결합해 키 보호와 거래 통제를 지원하는 공동 솔루션입니다. 솔루션 보기 ConsenSys Quorum + Thales지갑·수탁 플랫폼 협업과는 다른 블록체인 인프라 영역의 사례입니다. Thales는 Quorum의 블록체인 식별 키 보호에 Luna HSM을 활용하는 방안을 ConsenSys와 함께 소개했습니다. 공동 기술 소개 보기 이미지에는 여섯 기업이 함께 표시돼 있지만 협업의 형태와 확인 가능한 기술 자료는 서로 다릅니다. 실제 적용 범위는 선택한 제품·버전과 구축 환경에 따라 확인해야 합니다. 홍콩 SFC는 고객 가상자산의 98%를 콜드 스토리지에 보관하도록 하며, HSM 기반 방식을 예시로 듭니다. 키 생성·접근 통제·백업 요건은 적용 서비스에 맞춰 설계합니다. SFC 지침 원문 해외 구축 사례에서 보는 실제 적용 9 / 11 홍콩 인가 VATP 11곳 중 9곳이 Thales HSM 사용 Thales 제공 홍콩 시장 발표자료의 작성 당시 집계입니다. 현재 점유율 또는 홍콩 감독당국의 HSM 채택 통계는 아닙니다. 홍콩의 인가 가상자산 거래 플랫폼 HKVAX는 Luna HSM을 디지털 자산 수탁 구조에 통합했습니다. Thales가 공개한 사례에는 키 생성·보관·사용과 거래 서명, 핫·콜드 지갑의 분리, 역할별 접근 통제, 재해 복구 절차가 담겨 있습니다. 실제 플랫폼에 HSM을 적용할 때 보안과 운영을 함께 설계한 사례입니다. 또 다른 홍콩 사업자 HashKey Group의 공개 사례는 소프트웨어 지갑 중심 환경에서 하드웨어 기반 키 보호로 전환한 과정을 보여줍니다. 이 사례에 사용된 HSM 제품은 HKVAX의 Luna HSM과 구분해서 보아야 합니다. 두 사례는 디지털 자산 사업에서 키 보호가 플랫폼 통합과 운영 절차로 이어진다는 점을 보여줍니다. 공개 구축 사례 자세히 보기HKVAX의 Luna HSM 수탁 사례HashKey Group의 HSM 도입 사례 디지털 자산 보안 아키텍처는 플랫폼 선택 이후에 장비를 덧붙이는 방식보다, 플랫폼의 서명 구조와 키 통제 요건을 함께 정의하고 검증할 때 업무에 맞게 완성됩니다. 운영할 자산과 지갑 유형, 거래량, 복구 목표에 따라 적합한 구성도 달라집니다. 디지털 자산 플랫폼의 HSM 연동을 검토 중이신가요? ADOST는 지갑·수탁 플랫폼 업체와 함께 키 관리, 서명 경로, 백업·복구 및 성능 검증 범위를 검토할 수 있습니다. 적용하려는 플랫폼과 업무 요건에 맞춰 Luna HSM 구성 방안을 논의해 보세요. 도입 상담 및 문의하기 자료: Thales, Luna HSM for Digital Assets 발표 자료 및 Thales 공개 파트너·고객 사례. 홍콩 VATP 9/11 수치는 제공 발표자료 기준이며 작성 시점과 개별 채택 명단은 별도 확인되지 않았습니다. 각 기능·연동 방식은 제품과 구성에 따라 달라질 수 있습니다.
-
차세대 보안 인프라의 새로운 기준, Thales Luna 8 Network HSM
ADOST TECH INSIGHT · THALES HSM 보안 인프라의 새로운 기준, Thales Luna 8 Network HSM 양자 내성 암호(PQC), 고성능 암호 연산, 멀티 테넌시를 하나의 플랫폼에 통합한 하드웨어 기반 Root of Trust 차세대 Luna 8을 만나보세요 기업의 디지털 전환과 클라우드 확산, 양자 컴퓨팅의 발전으로 암호키와 민감 데이터를 보호하기 위한 보안 인프라의 중요성이 높아지고 있습니다.Thales Luna 8 Network HSM은 키 생성·저장·관리와 암호 연산을 보호된 하드웨어에서 수행하도록 설계된 차세대 네트워크 HSM입니다. 01. 차세대 Thales HSM 플랫폼 개요 및 등장 배경 디지털 전환과 클라우드 환경 확산에 따라 기업이 직면한 디지털 리스크가 고도화되고 있습니다. 특히 양자 컴퓨팅의 등장은 기존 암호 체계를 위협하며, '지금 수집 후 미래에 복호화(Harvest now, decrypt later)'와 같은 장기 데이터 위험에 대응할 강력한 암호 기반 신뢰를 요구합니다. 01 양자 리스크 대응 장기 데이터 위험 및 양자 위협에 대비한 PQC 기반 암호 체계 전환 필요. 02 컴플라이언스 준수 GDPR, eIDAS 2, HIPAA, PCI-DSS 등 규제 요건을 충족하도록 설계. 03 자동화 및 확장성 관리 업무 자동화 및 IT 인프라 도구 연동을 통한 손쉬운 배포와 확장 지원. Luna 8은 이러한 요구사항에 발맞추어 데이터 보안 및 컴플라이언스 목표를 달성할 수 있도록 지원하는 하드웨어 신뢰 루트(Root of Trust)를 제공합니다. 02. Luna 8 주요 제품 특징 Performance 향상된 성능 기존 알고리즘 연산 시 최대 10배 빠른 성능 PQC 알고리즘 연산 시 최대 100배 빠른 성능 QoS 지원을 통해 멀티 테넌트 환경에서도 예측 가능한 성능 제공 Scalability 비용 및 운영 효율성 멀티 테넌트 지원 및 향상된 키 저장 용량 모듈당 Luna HSM 인스턴스 15배 증가 어플라이언스당 최대 30개 HSM 인스턴스 구성 가능 Quantum-Safe 양자 보안 준비 양자 내성 알고리즘 및 양자 안전 신뢰 루트 기반 설계 QRNG를 포함한 양자 엔트로피 및 양자 안전 프로토콜 부채널 공격(Side-channel) 방어 메커니즘 탑재 Crypto Agility 미래 대응형 설계 새로운 알고리즘으로 손쉽게 업데이트 가능한 아키텍처 요구사항 변화에 따라 새로운 기능을 쉽게 추가 동일 하드웨어 내 안전한 컨테이너 기반 펌웨어 운영 ESG Environmental by Design Thales ESG 약속에 발맞추어, Luna 8은 이전 세대인 Luna 7 대비 트랜잭션당 20배(20x) 더 높은 에너지 효율성을 입증했습니다. 03. Thales 자체 설계 암호 프로세서 Luna 8의 기반이 되는 Thales 자체 설계 암호 프로세서는 디지털 신뢰와 혁신의 기초를 제공합니다. 격리된 암호화 엔진 멀티 테넌트 아키텍처를 위해 HSM당 220개의 격리된 암호 엔진 제공 보안 및 공급망 통제 공급망 및 보안 인증에 대한 통제력을 강화하고 최고 수준의 부채널 공격 방어 구현 고품질 엔트로피 고성능 사용 사례와 멀티 테넌시에 최적화된 고품질 엔트로피 소스 제공 암호 민첩성 유지 새로운 PQC 알고리즘에 대응하며 지속적으로 암호 민첩성을 보장 04. 기술 사양 지원 운영체제 Windows, Linux / 가상화: VMware, Hyper-V, Xen, KVM API 지원 PKCS#11, Java (JCA/JCE), Microsoft CAPI 및 CNG, OpenSSL, 관리용 API 양자 내성 암호 (PQC) ML-KEM (FIPS 203 키 캡슐화) 및 ML-DSA (FIPS 204 디지털 서명) Stateful Hash-Based Signatures: LMS 및 다중 레벨 HSS (RFC 8554 / NIST SP 800-208) 타원 곡선 암호 (ECC) FIPS NIST Prime 곡선 (P-192, P-224, P-256, P-384, P-521) 및 Brainpool (P192~P512) Koblitz 곡선 (secp256k1) - BIP32 HD 지갑 키 관리 Montgomery (X25519, X448) 및 Edwards (Ed25519, Ed448) 곡선 비대칭 및 대칭 암호 비대칭: RSA (최대 4096-bit) 표준 PKCS#1 v1.5, OAEP, PSS 대칭: AES (128, 192, 256-bit) - ECB, CBC, CBC-PAD, CTR, GCM, GMAC, Key Wrap, 512-bit AES-XTS / ARIA, SEED 레거시: Triple-DES (3DES) CBC/ECB (하위 호환 언랩/복호화 전용) 해시, KDF & 통신 SHA-2 및 SHA-3 (224~512-bit), HMACSHAKE-128, SHAKE-256 XOF키 유도: NIST SP 800-108 / 키 랩핑: NIST SP 800-38F3GPP 이동통신 보안: MILENAGE, TUAK, COMP 128 인증 프로필 난수 생성 (RNG) AIS 20/31 to DRG.4 준수 (HW 기반 True Noise Source + NIST 800-90A HMAC_DRBG) 보안 인증 FIPS 140-3 Level 3*Common Criteria EAL4+ (EN 419 221-5*)eIDAS 2 준수 QSCD 리스팅* 네트워크 4x 10G SFP+ (광케이블 또는 RJ45 Copper)IPv4, IPv6* / Port Bonding*1x 1G RJ45 (BMC 대역 외 관리 포트) 물리적 특성 및 전력 규격: 표준 1U 19인치 랙마운트 (443mm W x 557.6mm D x 43.5mm H)무게: 싱글 모듈 12kg / 듀얼 모듈 13.6kg소비 전력: 싱글 모듈 평균 ~135W (최대 ~225W) / 듀얼 모듈 평균 ~270W (최대 ~450W)이중화 핫스왑 전원 및 팬 (80 PLUS Platinum) * In process (진행 중인 인증 및 기능) 05. 사용 가능한 Luna Network HSM 모델 Luna 8 Network HSM은 성능, 키 저장 용량, 지원되는 컨테이너에 따라 3가지 모델로 제공됩니다. 각 보안 컨테이너는 격리된 Luna 8 인스턴스를 호스팅하며 최대 10개의 파티션을 지원합니다. Standard Performance Luna 100 컨테이너 수1 개 키 저장 용량128 MB Enterprise Performance Luna 150 컨테이너 수Up to 6 키 저장 용량1024 MB Maximum Performance Luna 190 컨테이너 수Up to 15 키 저장 용량4096 MB 06. 마이그레이션 및 가시성 보장 Luna 7과의 하위 호환성을 제공하여 리스크를 최소화하고 간단하게 마이그레이션할 수 있습니다. 연속성 보장 기존 Backup HSM 계속 사용 가능하며 Universal Client를 통해 변경 없이 동작. 모니터링 및 로깅 rsyslog, Kafka, Splunk, Prometheus, Grafana 및 BMC 대역 외 모니터링 연동. 안전한 백업 Luna Backup HSM과 호환되는 하드웨어 백업 솔루션 제공. 양자 안전 인프라 구축, 지금 시작하세요 Thales Luna 8 Network HSM으로 민감한 데이터와 핵심 애플리케이션을 안전하게 보호하세요. 도입 상담 및 문의하기