DigiCertの顧客は、パスワードを変更するだけでは解決できない情報漏えいのリスクに直面しています。身分証明書類が流出したためです。
世界有数の認証局であるDigiCertは、権限のない第三者が社内の業務用アーカイブシステムにアクセスし、顧客の連絡先情報や本人確認書類が流出したことを認めました。原因は2025年2月に実施したインフラ移行です。この作業で社内システムが誤ってインターネットに公開され、16カ月以上そのままになっていました。
同社によると、認証局サービス、顧客のログイン認証情報、発行済みの証明書に影響はありません。ただし、流出した顧客情報は、標的型フィッシングやなりすましに悪用される可能性があります。
社内アーカイブがWebに公開された経緯
公開状態は2025年2月4日に始まりました。DigiCertが社内の業務用アーカイブを、VPNで制限されたネットワークセグメントから別のアベイラビリティゾーンに移した際、システムが外部からアクセス可能になってしまいました。サーバー移行に伴い、他のアプリケーション向けのセルフ登録機能も誤って公開されました。
外部ユーザーは、従業員には通常求められる多要素認証(MFA)なしでアカウントを登録できました。これらのアカウントにはアプリケーションのロールが割り当てられていませんでしたが、権限設定の不備により、アーカイブされた顧客ファイルへの読み取り専用アクセスが既定で付与されていました。
DigiCertは2026年6月18日に社外のアカウントを確認し、Webアプリケーションファイアウォールの背後にシステムを置いて、外部からの新規登録を遮断しました。当初、担当者はアプリケーションが割り当てられていないアカウントではデータにアクセスできないと判断していました。
6月21日には、マネージド型のセキュリティ研究プログラムを通じて報告が寄せられました。DigiCertは7月2日に認可の修正を適用し、10月19日にアーカイブデータへの不正アクセスを確認しました。
「このインシデントは、当初、データアクセスの事案ではなくアカウント作成の問題として扱われていました」と、DigiCertはMozillaのBugzillaに提出したインシデント報告で認めています。
| インシデントの経過 | 記録された日付 | 主な運用上の詳細 |
|---|---|---|
| 公開状態の開始 | 2025年2月4日 | サーバーをVPNセグメントから外部のアベイラビリティゾーンに移動。 |
| 不正アクセス | 2026年6月27日~7月2日 | 読み取り専用データへの不正アクセスが確認された期間。 |
| 不具合の修正 | 2026年7月2日 | 外部アクセスを遮断する認可パッチを適用。 |
| 情報漏えいの確認 | 2026年10月19日 | 調査により不正なデータアクセスを確認し、報告対象のインシデントと判断。 |
流出した身分証明書類が残す長期的なリスク
流出した記録の大半は、一般的な業務上の連絡先データでした。
- 氏名
- 企業のメールアドレス
- 電話番号
- 事業所の住所
しかし、ごく一部の顧客ファイルには、証明書の審査時に提出された本人確認書類が含まれていました。運転免許証、パスポート、公共料金の請求書などです。
クラウドアーキテクトのFabian Bader氏はXに投稿し、漏えい通知について次のように皮肉りました。「@digicert、データ漏えいが『限定的』で、私の個人情報すべてと、証明書のために提出した可能性のある本人確認書類だけで済んだことに感謝します」
DigiCertによると、このアカウントでは記録の変更、審査の承認、証明書の発行はできませんでした。
顧客とセキュリティチームが確認すべきこと
影響を受けた顧客は、既知のサポート窓口からDigiCertに連絡し、どの記録や書類が対象になったかを確認してください。組織は、関係する従業員や顧客担当者を特定し、流出した情報に応じて対応を調整する必要があります。
身分証明書類の再提出、証明書変更の承認、アカウント情報の提供を求める予期しない依頼には注意してください。そうした依頼は、別の手段で独自に確認することが重要です。これらは悪用の可能性に備えた予防策であり、今回の開示で、その後の詐欺被害が発生したと確認されたわけではありません。
政府発行の身分証明書が流出した場合は、発行機関に相談し、被害の届け出や再発行の要否を確認してください。再発行で書類番号は変わるかもしれませんが、すでに流出したコピーを回収することはできず、書類に記載されたすべての個人情報が変わるわけでもありません。
セキュリティチームにとって、今回のインシデントは社内アーカイブを点検する具体的な観点も示しています。
|
確認する領域 |
検証すべき内容 |
|---|---|
| アプリケーションの権限 | 承認済みのロールを持たないアカウントが、記録やファイルを取得できないこと。 |
| 登録機能 | 社内システムが、不要な一般向けサインアップ機能を引き継いでいないこと。 |
| インフラの変更 | 移行時のレビューに、外部からの到達性とアプリケーションのアクセス制御が含まれていること。 |
| モニタリング | 予期しないアカウント作成や、通常と異なる量のファイルアクセスが調査のトリガーになること。 |
| データ保持 | 身分証明書類に、文書化された保持期間と削除プロセスがあること。 |
新規作成したアカウントや、ロールを割り当てていないアカウントで権限をテストしてください。ファイルのエンドポイントへの直接リクエストも含める必要があります。制限されたインターフェースがあっても、その背後の記録が保護されているとは限らないためです。
Zeaburの情報漏えいと顧客向け対応ガイダンスも同様に、影響を受けたシステム全体で復旧を検証する必要性を強調しています。アーカイブの公開問題を収束させる前に、どのアカウントがどの記録にアクセスできたかを特定し、関連ログを保全し、修正後の制御が不正アクセスを確実に拒否することを確認してください。
関連記事:情報漏えいへの対応は、どの情報が流出したかによって変わります。 mSecureのインシデントでは、顧客が優先して保護すべきアカウントと保存済み認証情報を解説しています。
翻訳元: https://www.esecurityplanet.com/threats/news-digicert-breach-customer-data-id-documents/