DigiCert가 고객 신원 서류를 보관한 내부 아카이브의 무단 접근을 확인했습니다. 인증서를 관리하는 담당자라면 먼저 구분할 점이 있습니다. 회사 설명에 따르면 이번에 일부 자료가 읽힌 곳은 고객 제출 정보를 보관하는 서류 아카이브입니다. 인증서를 발급하고 관리하는 시스템은 영향을 받지 않았습니다.[1]
DigiCert는 인증기관(CA) 서비스와 CertCentral, DigiCert ONE이 영향을 받지 않았다고 밝혔습니다. 고객 로그인 자격증명과 이미 발급된 인증서도 안전하며, 인증서의 유효성과 신뢰가 유지된다고 설명했습니다. 회사가 보고한 영향 인증서는 0건입니다. 이 사건만을 이유로 활성 인증서를 일괄 재발급하거나 교체할 필요는 없다는 것이 DigiCert의 공식 입장입니다.[1]
관리자가 먼저 확인할 내용
인증서 교체 판단과 개인정보 대응을 나눠서 보세요. DigiCert는 활성 인증서와 서비스의 계속 이용에 고객 조치가 필요하지 않다고 밝혔습니다. 다만 아카이브 일부에 대한 무단 읽기는 확인됐으므로, 등록 담당자의 통지 메일을 확인하고 어떤 정보가 대상인지 살펴보는 일은 별개입니다. 대부분은 업무 연락처이며, 소수 고객 계정에는 여권·운전면허·공과금 고지서 같은 서류가 포함됐습니다.[1]
인증서가 아니라 어떤 자료에 접근했나요?
회사가 설명한 접근 대상은 고객 담당자의 업무 연락처와 일부 신원 확인 서류를 보관한 아카이브입니다.[1]
대부분의 정보는 이름, 업무용 이메일 주소, 전화번호, 업무용 주소였습니다. 소수 고객 계정에는 고객이 제출한 운전면허증, 여권, 공과금 고지서 또는 이름과 주소가 적힌 다른 서류가 포함됐습니다. 이를 모든 고객의 신분증 유출로 볼 근거는 없습니다. 회사는 전체 아카이브 중 작은 비율이 영향을 받았다고 설명했지만, 사람·조직·서류의 총수는 공개하지 않았습니다.[1]
아카이브는 제출 자료를 보관하는 곳이고, CA 시스템은 인증서 발급과 검증을 처리하는 곳입니다. 같은 회사가 운영한다고 해서 같은 권한과 같은 네트워크를 쓰는 것은 아닙니다. DigiCert는 CA 시스템이 별도의 보안 네트워크 구간에서 운영되며 이번 외부 접근의 영향을 받지 않았다고 밝혔습니다.[1]
| 확인 항목 | 고객 자료 아카이브 | CA·인증서 운영 |
|---|---|---|
| 회사 확인 결과 | 일부 자료 무단 읽기 확인 | 영향 없음 |
| 대상 정보·기능 | 업무 연락처, 소수 계정의 신원 서류 | 검증, 발급, 수정, 폐기 |
| 고객의 판단 | 통지와 대상 정보 확인 | 이 사건만으로 활성 인증서 재발급 불필요 |
위 구분은 DigiCert의 전체 사고 보고를 기준으로 합니다.[1]
읽기 전용이었다면 개인정보도 안전한가요?
아닙니다. 자료를 바꾸지 못했다는 사실과 개인정보를 읽었다는 사실은 별개입니다.
DigiCert에 따르면 해당 접근은 읽기 전용이었고, 기록을 수정하거나 검증을 승인하거나 인증서를 발급할 권한은 없었습니다. CA와 검증 활동 로그에서도 해당 계정과 연결된 검증·발급·폐기 활동이 발견되지 않았다고 설명했습니다. 이는 인증서 운영에 대한 영향이 없다는 회사 판단의 근거입니다.[1]
그러나 신원 서류와 연락처는 수정되지 않아도 노출 자체를 살펴봐야 하는 정보입니다. 따라서 인증서가 유효하다는 안내를 개인정보 피해 우려도 없다는 뜻으로 받아들이면 안 됩니다. 반대로 개인정보 아카이브에서 사고가 났다는 이유만으로 인증서 신뢰 체계까지 손상됐다고 확대해서도 안 됩니다.
2026년 11월 6일 17:47 KST까지 재확인한 공개 자료에서 확인되지 않은 부분도 남아 있습니다. 공격자 신원, 한국 고객 포함 여부, 자료의 암시장 유통 여부, 추가 악용 여부는 확인되지 않았습니다. 공개된 근거가 없다는 이유로 “악용은 없었다”고 단정할 수는 없습니다. 전체 피해 규모 역시 숫자로 제시할 근거가 없습니다.[1][2]
내부 아카이브가 왜 인터넷에서 열렸나요?
회사 보고에 따르면 네트워크 이전, 의도하지 않은 셀프 가입 기능, 부족한 자료 접근 권한 검사가 겹쳤습니다.[1]
시작은 2025년 2월 4일의 인프라 이전입니다. 원래 VPN을 통해서만 접근하도록 운영하던 업무 시스템을 다른 가용 영역으로 옮기는 과정에서 인터넷으로 접근할 수 있게 됐습니다. 회사는 이를 보안 변경이 아닌 인프라 변경으로 처리해, 외부에 무엇이 열리는지 충분한 보안 검토가 이뤄지지 않았다고 설명했습니다.[1]
해당 시스템의 계정 관리 기능에는 다른 용도로 쓰던 셀프 가입 기능이 들어 있었습니다. 이 기능이 내부 업무 시스템에도 의도치 않게 제공됐고, 외부에서 만든 계정은 직원에게 요구하는 다중요소 인증(MFA)의 적용을 받지 않았습니다. 이용할 애플리케이션이 지정되지 않은 계정인데도 아카이브 자료를 읽을 수 있었습니다.[1]
초기 판단도 문제를 늦췄습니다. 내부 검토에서는 애플리케이션이 배정되지 않았으니 자료 접근도 없을 것으로 잘못 판단했습니다. 새 계정 생성과 비정상적인 요청량을 살피는 알림도 충분하지 않았습니다. 회사는 처음에 이를 자료 접근 사고가 아닌 계정 생성 문제로 다뤘다고 인정했습니다.[1]
확인한 공개 자료에서 이 사건에 부여된 CVE 번호는 확인되지 않았습니다. 특정 제품의 보안 패치 번호로 다루는 사건이 아니라, 내부 업무 시스템의 외부 노출과 자료 접근 권한 문제로 설명돼 있습니다.[1][2]
실제 접근과 사고 보고는 언제 이뤄졌나요?
자료 접근 기간은 2026년 6월 27일부터 7월 2일까지이며, 회사가 무단 접근을 보고 대상 사건으로 확정한 날은 10월 19일입니다. 외부 노출 시작일과 실제 자료 접근 기간은 구분해야 합니다.[1]
2025년 2월 4일에는 네트워크 이전으로 외부 접근이 가능해졌습니다. 2026년 6월 18일에는 비직원 계정이 발견됐고, 회사는 웹 애플리케이션 방화벽(WAF)으로 외부 경로의 신규 가입을 차단했습니다. 6월 21일에는 관리형 보안 연구 프로그램을 통해 외부 계정 생성 가능성이 보고됐습니다.[1]
7월 2일에는 권한 제한 패치가 적용돼 애플리케이션이 배정되지 않은 계정의 자료 접근이 차단됐습니다. 이후 조사에서 실제 자료 접근 기간도 이날 종료된 것으로 확인됐습니다. 7월 9일에는 승인된 외부 접속 지점을 제외하고 업무 시스템에 VPN을 통해서만 접근하도록 제한했습니다.[1]
10월 12일에는 아카이브 무단 접근 가능성을 의심해 추가 조사를 시작했고, 10월 19일에 보고 대상 사건으로 확정했습니다. 이후 보고·공개 시점은 회사 기록과 게시물 생성 시각을 나눠 읽어야 합니다.[1]
- 2026년 10/20(회사 기록): 예비 보고 제출. 다만 Bugzilla 댓글 0의 실제 생성 시각은 2026년 10월 21일 03:10:16 UTC이며, 한국 시각으로는 10월 21일 12:10:16입니다.[1]
- 2026년 11/02 08:59:22 KST: 전체 사고 보고가 담긴 댓글 2 생성. UTC 기준으로는 11월 1일 23:59:22입니다.[1]
- 2026년 11/05 15:52:04 KST: CyberSIXT 언론 보도 게시. 예비 보고나 전체 사고 보고의 공개와는 다른 시점이며, 이를 최초 공개라고 단정하지 않습니다.[2]
- 2026년 11/06 08:25:22 KST: 댓글 4에서 예상치 못한 계정 생성과 권한 변경 알림에 관한 조치 항목 13의 완료를 보고했습니다.[1]
외부에 접근 가능한 업무 시스템 원본 서버가 남아 있지 않은지 내부 감사로 확인하는 조치 항목 12는 제공된 전체 보고에서 진행 중으로 표시돼 있습니다. 2026년 11월 6일 17:47 KST 확인 기준, 해당 항목의 최종 완료는 확인되지 않았습니다. 조치 항목 13의 완료 댓글을 전체 개선 작업 완료로 읽어서는 안 됩니다.[1]
통지 메일을 받았다면 무엇부터 확인하나요?
통지에서 해당 조직의 대상 정보와 서류 항목을 확인하고, 보안·개인정보 담당자에게 공유하는 것이 우선입니다.
먼저 인증서 구매·갱신을 맡는 담당자뿐 아니라 DigiCert에 등록된 연락 담당자의 받은편지함과 스팸함도 확인하세요. 통지를 받았다면 업무 연락처에 관한 안내인지, 신원 확인 서류에 관한 안내인지 구분해 읽어야 합니다. 과거 검증 과정에서 어떤 담당자가 어떤 자료를 제출했는지도 내부 기록으로 확인해 두면 문의 내용을 정리하는 데 도움이 됩니다.
Cybersecurity News는 고객 통지 메일에 신원 서류를 검토하고, 검토가 끝나면 영향받은 사람에게 알리겠다는 내용이 담겼다고 보도했습니다. 이는 메일 내용을 다룬 2차 보도입니다. 고객 통지 메일 전문의 공식 공개 URL은 확인 안 됨 상태이므로, 모든 고객에게 같은 문구와 일정이 적용된다고 볼 수는 없습니다.[3]
실제 받은 통지에 추가 안내가 예정돼 있다면 그 후속 연락을 확인하세요. 대상이 모호하다면 메일에 답하기에 앞서 평소 사용하던 공식 고객 포털이나 지원 창구에서 통지의 진위와 영향 범위를 문의하는 편이 안전합니다. 문의할 때도 필요하지 않은 신원 서류 사본을 새로 첨부하지 않도록 주의하세요.
메일을 못 받았다면 아무 조치도 필요 없나요?
메일이 없다는 사실만으로 피해가 없다고 확정할 수는 없지만, 이 사건만으로 인증서를 교체할 필요도 없다는 것이 회사 설명입니다.[1]
조직에서는 등록 담당자가 바뀌었는지, 공용 메일함으로 안내가 갔는지부터 살펴보세요. 통지를 찾지 못했는데 과거 신원 서류 제출 여부가 걱정된다면 공식 포털이나 지원 창구에 확인하면 됩니다. 공개되지 않은 전체 피해자 수나 국가별 범위를 추정해 조직의 포함 여부를 판단하지 않는 것이 좋습니다.
“긴급 재발급”이나 “즉시 결제”를 요구하는 이메일은 이번 사건에 대한 회사 설명과 맞는지 교차 확인하세요. 메일 속 링크만 따라가기보다 기존에 이용하던 공식 경로로 접속해 확인하는 방식입니다. 인증서 개인키를 외부 유출 조회 사이트에 올려 확인하려 해서는 안 됩니다. 개인키 업로드는 이번 통지 확인에 필요한 절차가 아닙니다.
비밀번호 초기화 대상도 구분해야 합니다. DigiCert가 10월 17일 완료했다고 기록한 것은 해당 내부 업무 시스템 이용자의 비밀번호 재설정입니다. 이를 전체 CertCentral 고객의 비밀번호가 유출됐다거나 전 고객이 반드시 변경해야 한다는 안내로 바꿔 해석할 근거는 없습니다.[1]
서버 관리자는 이번 사고에서 무엇을 점검하면 좋을까요?
내부 시스템의 네트워크 위치와 실제 자료 접근 권한을 따로 확인하는 것이 핵심입니다.
DigiCert는 내부 시스템의 권한 관리를 네트워크 위치에 맡겨서는 안 된다는 교훈을 보고서에 적었습니다. VPN 안에 있다는 전제만으로 자료 접근을 허용하면, 이전이나 네트워크 변경 때 보호 조건이 달라질 수 있습니다. 계정이 존재한다는 사실과 특정 자료를 읽을 권한이 있다는 사실도 별도로 검사해야 합니다.[1]
조직 내부에서는 시스템 이전 시 외부 접근 가능 여부를 다시 검토하는지, 불필요한 가입 기능이 남아 있는지, 업무가 배정되지 않은 계정이 자료를 읽을 수 있는지 살펴볼 수 있습니다. 새 계정과 권한 변경, 평소와 다른 자료 조회량에 대한 알림도 점검 대상입니다. 이는 일반적인 내부 운영 점검 제안이며, DigiCert가 고객에게 부과한 공식 의무는 아닙니다.
관리자는 두 가지를 나눠 판단하면 됩니다. 인증서는 회사 설명에 따라 계속 운영하되, 개인정보 통지는 별도로 확인합니다. 인증서를 교체하지 않는다는 판단이 서류 노출을 가볍게 본다는 뜻은 아닙니다. 반대로 서류 통지를 받았다는 이유로 서비스 전체의 인증서를 급히 바꿀 근거가 생기는 것도 아닙니다.[1]
관련 읽을거리: APT CVE-2026-109518, Ubuntu 22.04·24.04 수정 버전, OpenSSH 10.6p2, musl 환경의 비밀번호 인증 우회를 차단한다, Ubuntu nginx USN-8955-2 패치 가이드: 20.04·18.04 ESM 버전 확인부터 업데이트까지에서 다룬 패치 적용과 이번 사건의 인증서 재발급 여부는 별도로 판단해야 합니다. 다른 소프트웨어의 보안 업데이트 필요성을 이번 회사 안내로 대신 판단해서는 안 됩니다.
자료 확인: 2026년 11월 6일 17:47 KST. 회사 보고와 후속 댓글을 우선 대조했습니다. CyberSIXT 원문은 직접 접속 시 403 응답으로, 해당 URL의 공개 텍스트 중계본을 통해 본문과 게시 시각을 확인했습니다.