Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
│ 제이버 · 이머드라 사고가 말해주는 KMS의 필요성
지난 10월, 대만과 인도에서 잇따라 공개된 두 건의 보안 사고가 글로벌 보안 업계를 흔들었입니다. 대만의 클라우드 플랫폼 기업 제이버(Zeabur)는 두 차례 침해사고 끝에 서비스 종료를 선언했고, 인도의 인증기관 이머드라(eMudhra)는 중간 인증기관(Intermediate CA) 개인키 8개가 누구나 계산해 낼 수 있는 상태였다는 사실이 드러나며 공개 TLS 인증서 사업에서 물러나기로 했습니다.
한 곳은 만들어 둔 키를 지키지 못했고, 다른 한 곳은 처음부터 안전한 키를 만들지 못했습니다. 경로는 달랐지만 결론은 같습니다. 암호 키 관리의 실패는 곧 사업의 실패로 이어집니다.
방화벽 뒤에 방치된 '열쇠'
금융 거래, 클라우드 서비스, 소프트웨어 배포, 자동차 OTA(Over-The-Air) 업데이트에 이르기까지 오늘날 디지털 서비스의 신뢰는 암호 키(Cryptographic Key) 위에 서 있습니다. 데이터를 암호화하는 것도, 서버와 사용자의 신원을 증명하는 것도, 소프트웨어가 변조되지 않았음을 보증하는 것도 결국 암호 키입니다.
그런데도 많은 기업이 방화벽, 침입탐지시스템, 보안관제에는 아낌없이 투자하면서 정작 그 보안 체계의 근간인 암호 키를 어떻게 만들고, 어디에 두고, 언제 바꾸고, 언제 없앨지는 개별 담당자의 손에 맡겨 둡니다. 암호 키는 비밀번호 하나와 무게가 다릅니다. 클라우드 관리자 키가 새면 인프라 전체가, 소프트웨어 서명키가 새면 고객사의 공급망이, CA 개인키가 새면 인증체계 전체가 흔들립니다. 평문으로 저장된 키, 만료 없이 방치된 키, 충분한 무작위성 없이 생성된 키가 하나라도 있다면 그 위에 쌓은 보안 투자는 사상누각이 됩니다.
제이버: 평문 관리자 토큰이 부른 폐업
2022년 설립된 제이버는 개발자가 서버 설정 없이 애플리케이션을 배포할 수 있게 해 주는 PaaS(Platform as a Service)로 빠르게 성장했습니다. 그러나 2026년 8월 첫 침해사고에 이어 10월 14일 두 번째 침해사고를 겪었고, 사흘 뒤인 10월 17일 서비스 종료를 발표했습니다.
10월 19일 공개된 회사의 예비 조사 보고서는 사고 원인을 한 문장으로 요약한 것입니다. 장기간 유효한 관리자 인증정보가 평문으로 저장돼 있었고, 이를 공개 인터넷에서 그대로 사용할 수 있었다는 것입니다. 2024년 1월 생성된 공유 클러스터 관리자 토큰에는 만료 기한이 없었고, 이 토큰과 AWS 접근키는 비공개 설정 저장소에 평문으로 보관돼 있었습니다. 해당 토큰은 생성 이후 한 번도 교체되지 않았으며 8월 1차 사고 뒤 진행된 키 교체에서도 빠졌습니다. 출처가 확인되지 않은 오래된 GCP 키는 서버 초기화 설정에 평문으로 적힌 root 비밀번호를 읽는 데 쓰였고, 공격자는 이를 통해 GCP 전용 서버 101대에 최고관리자 권한으로 접속했습니다.
가장 뼈아픈 장면은 사고 대응 과정에서 나왔습니다. 10월 15일 공격자가 백업 접근키를 탈취하자 회사는 15시 40분에 새 키를 발급했지만, 이 키는 불과 20분 뒤인 16시 정기 백업에 그대로 담겼습니다. 공격자는 같은 날 20시 30분에 새 키를 사용했습니다. 운영 시스템의 키를 교체하더라도 백업·설정 파일·로그에 키가 남아 있다면 교체는 의미가 없다는 사실을 보여준 것입니다.
피해 규모도 컸습니다. 9개 리전의 공유 클러스터와 GCP 전용 서버 101대가 영향을 받았고, 플랫폼 데이터베이스에서 환경 변수 3,218,965건과 계정 321,810개의 정보가 노출됐습니다. 운영 환경의 시크릿 약 53개도 공격자 손에 들어갔습니다. 창업자는 시스템의 복잡성과 함께 두 차례 사고가 드러낸 보안·운영상 약점을 들어 사업 정리를 결정했다고 밝혔습니다. 제이버는 신규 판매를 즉시 중단했고, 12월 1일부터 서버 갱신을 막은 뒤 12월 31일 모든 전용 서버와 공유 클러스터 운영을 종료한입니다. 보안 사고가 데이터 유출을 넘어 회사의 존폐로 이어진 사례입니다.
이머드라: HSM을 쓰고도 막지 못한 '약한 키'
두 번째 사례는 인도의 PKI 기업 이머드라입니다. CA는 웹사이트와 소프트웨어의 신원을 보증하는 인증서를 발급하는 기관이고, CA 개인키는 그 신뢰를 떠받치는 가장 중요한 자산입니다.
10월 17일 한 보안 연구자는 이머드라의 중간 인증기관 8개(TLS용 6개, 코드서명용 2개)의 개인키를 복구했다며 모질라에 이를 제보했습니다. 원인은 2025년 4월 30일 진행된 키 생성 의식(Key Ceremony)이었습니다. P-384 타원곡선 개인키는 약 384비트의 무작위성을 가져야 하지만, 실제 사용된 개인키는 4, 56, 66과 같은 작은 정수에 불과했습니다. 공개키만 보고도 손쉽게 대입해 찾아낼 수 있는 값입니다. 연구자는 복구한 키로 실제 서명을 생성해 이를 입증했습니다.
주목할 점은 이머드라가 FIPS 140-2 Level 3 인증 HSM에서 키를 생성했다는 사실입니다. 회사 발표에 따르면 키 래핑·언래핑 단계의 스크립트 결함으로 정상적인 강한 키 옆에 약한 키 쌍이 하나 더 만들어졌고, 승인된 테스트 편차와 여러 지점의 인적 오류가 겹치면서 이 약한 키가 인증서 서명 요청(CSR)에 쓰였습니다. 이 결함은 약 18개월 동안, 두 차례의 독립 감사를 거치면서도 발견되지 않았습니다. HSM이라는 금고를 갖췄지만 무엇을 금고에 넣는지 검증하는 절차가 없었던 셈입니다.
대응은 빨랐습니다. 모질라는 제보 후 3시간이 채 안 돼 해당 인증서를 차단했고, 이머드라는 이튿날 8개 중간 인증서를 모두 폐기했습니다. 구글, 마이크로소프트, 애플도 차단 조치에 나섰고 모질라는 상위 루트 인증서까지 신뢰 목록에서 제거했습니다. 이머드라는 문제의 중간 인증기관에서 최종 사용자 인증서가 한 건도 발급되지 않았고 8개 중 7개는 실제 운영에 쓰이지도 않았다고 밝혔습니다. 그럼에도 루트 단위의 신뢰가 철회되면서 회사는 영향받는 가입자 인증서를 약 3만 건으로 추산했고, 결국 공개 TLS 인증서 사업의 단계적 종료를 발표하고 KPMG를 외부 검토기관으로 선임했습니다.
이 사례는 키 유출이 반드시 해킹에서 시작되는 것은 아니라는 점을 보여준 것입니다. 키를 만드는 절차에 결함이 있고 그 결과를 검증하지 않는다면, 최고 등급의 보안 하드웨어도 사고를 막지 못한 것입니다.
두 사고가 남긴 교훈: 생성부터 폐기까지
제이버는 키를 보관·갱신·폐기하는 단계에서, 이머드라는 키를 생성·검증하는 단계에서 무너졌습니다. 두 사고를 키 라이프사이클에 대입해 보면 기업이 갖춰야 할 관리 요건이 분명해진 것입니다.
| 단계 | 관리 요건 | 사고에서 드러난 문제 |
|---|---|---|
| 키 생성 | 암호학적으로 안전한 키 생성과 생성 결과에 대한 독립적 검증 | eMudhra: 작은 정수에 불과한 개인키가 생성돼 18개월간 사용 (두 차례 외부 감사도 통과) |
| 키 보관 | HSM 등 보안 영역 내 보관, 설정·코드·저장소의 평문 저장 금지 | Zeabur: 관리자 토큰·클라우드 키를 설정 저장소에, root 비밀번호를 서버 초기화 설정에 평문 보관 |
| 키 사용 | 사용 주체별 인증과 최소 권한, 관리 인터페이스 접근 제한 | Zeabur: 만료 없는 관리자 토큰을 공개 인터넷에서 그대로 사용 가능 |
| 키 갱신 | 유효기간 설정과 주기적 교체, 사고 시 전수 교체 | Zeabur: 2024년 1월 생성 토큰이 1차 사고 이후에도 교체 대상에서 누락 |
| 키 폐기 | 사용 종료·노출 의심 키의 즉시 폐기 | Zeabur: 오래된 GCP 키가 유효한 채 남아 서버 침투 경로로 악용 |
| 키 감사 | 키 생성 절차와 사용 이력의 추적·기록 | eMudhra: 키 생성 스크립트 결함과 절차 편차를 장기간 발견하지 못함 |
| 백업·복구 | 백업 내 키 암호화, 백업 접근 권한 분리 | Zeabur: 사고 대응 중 새로 발급한 키가 20분 만에 백업에 남겨져 다시 악용 |
일곱 가지 요건 가운데 어느 하나도 특별한 기술이 아닙니다. 문제는 수십, 수백 개 시스템에 흩어진 키를 담당자의 기억과 수작업으로 관리하는 한 이 요건이 일관되게 지켜질 수 없다는 데 있습니다. 제이버의 관리자 토큰이 교체 대상에서 빠진 것도, 새 키가 백업에 다시 담긴 것도 결국 키의 위치와 상태를 한곳에서 파악하지 못했기 때문입니다.
HSM은 금고, KMS는 금고를 운영하는 체계
해법은 HSM(Hardware Security Module) 기반의 중앙집중형 KMS(Key Management System)입니다. HSM은 키를 안전하게 생성·보관하고 암호 연산을 수행하는 전용 하드웨어로, 키가 서버 파일이나 설정 저장소에 평문으로 노출되는 위험을 원천적으로 줄입니다. 그러나 이머드라 사례가 보여주듯 금고만으로는 충분하지 않습니다. 어떤 키가 어디에서 어떤 정책으로 쓰이는지, 누가 언제 접근했는지, 언제 교체하고 폐기해야 하는지를 관리하는 운영 체계, 즉 KMS가 함께 있어야 합니다.
상호운용성도 중요합니다. 기업 환경에는 서로 다른 제조사의 서버, 스토리지, 데이터베이스, 클라우드가 섞여 있습니다. OASIS의 KMIP(Key Management Interoperability Protocol)는 이들 사이에서 키를 표준 방식으로 관리·교환하기 위한 국제 표준으로, 특정 제품에 종속되지 않는 키 관리 환경을 구축하는 기반이 된 것입니다.
MDS인텔리전스가 자체 개발한 NeoKeyManager(NKM)는 이러한 요구에 맞춘 HSM 기반 암호 키 라이프사이클 관리 솔루션입니다. KMIP 표준을 기반으로 차기 규격인 KMIP 3.0까지 반영했으며, 키의 생성·보관·배포·갱신·폐기 전 과정을 중앙에서 정책 기반으로 관리합니다. 국내 금융기관과 공공기관, 자동차 OEM과 Tier 1 협력사에 구축돼 금융 거래 키, 시스템 인증키, 차량 소프트웨어 서명키 등을 관리하고 있습니다.
특히 자동차 산업은 SDV(Software Defined Vehicle)와 OTA 업데이트 확산으로 ECU 인증키, 소프트웨어 서명키, 차량 통신 암호 키가 빠르게 늘고 있습니다. OEM과 협력사가 키를 주고받는 공급망 구조에서는 한 곳의 관리 실패가 수백만 대의 차량으로 번질 수 있어 중앙집중형 KMS의 필요성이 더욱 큽니다.
암호 키 관리는 선택이 아닌 기반 인프라
기업의 보안 수준은 더 이상 어떤 보안 장비를 도입했느냐로 판단되지 않습니다. 핵심 데이터와 시스템을 지키는 암호 키가 얼마나 안전하게 생성되고, 보관되고, 사용되고, 폐기되는지가 곧 보안 경쟁력입니다. 제이버와 이머드라는 각자의 방식으로 그 대가를 치렀습니다. 암호 키 관리를 특정 담당자의 업무나 개별 시스템의 부가 기능으로 두어서는 안 됩니다. 방화벽처럼, 아니 그보다 먼저 갖춰야 할 기반 인프라로 다뤄야 할 때입니다.
📧 nkm_biz@mdsit.co.kr ✍️ 문의남기기
───
참고자료
