Google は2026年10月6日、Chromeの公式ブログで、国別ドメイン(ccTLD)の.gh・.sl・.asで起きたドメインの乗っ取りについて公表しました。運営側が侵害され、権威DNS が書き換えられ、Googleを含む複数の組織のドメインについて、HTTPS証明書が不正に取得されたという内容です。
.jpや.comは、発表が挙げる対象に入っていません。一方で、同じ手口は自社ドメインにも起こりえます。Googleが勧める対策と、日本のJPRSなどの公式資料をもとに、情シスの確認事項を整理します。
何が起きたか(Googleの発表)
Googleのブログ(2026年10月6日付)の内容は次のとおりです。
項目
発表に書かれていること
対象の国別ドメイン
.gh(ガーナ)、.sl(シエラレオネ)、.as(米領サモア)
起きたこと
第三者が運営する国別ドメインが侵害され、攻撃者が権威DNSのレコードを書き換え、複数のGoogleのドメインと他組織のドメインについて、不正なHTTPS証明書を取得した
気づいた時期
発表の前の週(原文は「Last week」)
Googleのシステム
侵害は受けていない
認証 局(CA)証明書を出した認証局が不適切な対応をしたと考える理由はない
Chromeの利用者
必要な操作はない
Googleのブログ記事の冒頭(題、日付、要約文) 出典: Google Security Blog (引用) 発表の説明を、自分の言葉で日本語にします。権威DNSとは、そのドメインの名前と接続先の対応を、最終的に答えるDNSサーバーのことです。ここを書き換えられると、本物のドメイン名のまま、攻撃者の用意したサーバーへ利用者を向けられます。
HTTPS証明書は、認証局が「このドメインの持ち主からの申請だ」と確認して発行します。確認にはDNSを使う方法もあるため、DNSを握った攻撃者が証明書を取れてしまう、というのが一般的な仕組みです。Googleは、この攻撃の性質から、.gh、.sl、.asで終わるすべてのドメインが危険にさらされたと書いています。
During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations.
出典: Google「Chrome's Response to Recent ccTLD Registry Hijacks」
Chromeはどう対応したか
Googleは、通常のインシデント対応 として、Googleのドメインの不正な証明書をCRLSetsでブロックしたと書いています。あわせて、証明書を出した認証局と連携し、Chrome以外のクライアントを守るために失効させました。
CRLSetsは、Chromiumの公式ページで「Chromeが緊急時に証明書を素早くブロックする主な手段」と説明されています。Chromeは、企業向けの設定で有効にしない限り、OCSPやCRLのオンライン確認を通常は行わないとも書かれています。
その後、Certificate Transparency(CT)ログのデータから、同じ攻撃の影響を受けたとみられる別の組織(有名な世界的ブランドや広く使われるオンラインサービスを含む)が見つかり、それらの証明書もChromeでブロックしました。可能な範囲で、影響を受けた組織に連絡したとも書いています。
分かっていないことも整理します。次の点は、Googleの発表に書かれていません。
攻撃者が誰か
不正な証明書の件数
対象になったGoogleのドメイン名
影響を受けた他組織の名前
侵害された運営者の名前と、侵害の経路
日本での影響やサービスの提供についても、発表には書かれていません。
影響する会社・しない会社
影響の範囲は、Googleの発表が挙げた国別ドメインで決まります。
影響する: .gh、.sl、.asのドメインを自社や取引先のサービスで使っている会社。Googleは、これらで終わるすべてのドメインが危険にさらされたと書いています。
影響する: 保有ドメインの一覧に、使っていない国別ドメインや取得しただけのドメインがある会社。Googleは、CTの監視に、駐車中のドメインや地域別の国別ドメインも含めるよう求めています。
影響しない(発表の範囲では): .jpや.comだけを使っている会社。これらが今回の対象という記載はありません。ただし、同じ手口への備えは別に必要です。
影響しない(Chromeの利用者として): Googleは、Chromeの利用者に必要な操作はないと書いています。
自社ドメインを守る5つの確認
Googleは、ブラウザー側の対応に頼らず、ドメインの持ち主が自分で守るよう求めています。ここからは、Googleの発表と各公式資料の内容に沿って、情シスが確認できることを並べます。(5)は編集部の整理です。
(1) 登録事業者・DNSの管理画面の多要素認証
JPRSの注意喚起は、ドメイン名の乗っ取りの主な手段として「DNSサーバーを狙い、不正な応答を返すようにする」ことと「ドメイン名の管理権限を奪い、登録情報を書き換える」ことを挙げています。
管理サービスのパスワード が安易で、不正ログインから登録情報やDNS情報が書き換えられた事例があるとも書かれています。対策として、推測されにくいパスワード、二要素認証など強い認証の利用を検討するよう書いています。
JPRSは、組織としてドメイン名の管理を担当する部門と、管理の手順を決めることも求めています。登録情報の変更通知メールを一元的に確認し、Whoisで登録状態を定期的に確かめることも、意図しない変更を早く見つける方法として書いています。
(2) レジストリロック
JPRSのレジストリロックサービスは、JPドメイン名の登録情報(登録者の氏名、組織名、ネームサーバー設定など)が意図せず書き換えられないよう、情報をロックして、次の申請の受付を制限します。
登録情報変更
ドメイン名移転
ドメイン名廃止
指定事業者変更
JPRSのページには、サービスはJPRSから指定事業者に提供され、提供の方法と範囲は事業者ごとに違うこと、取り扱わない事業者もあることが書かれています。使えるかどうかは、ドメインの管理指定事業者に確認してください。.comなどJP以外のドメインについては、このページには書かれていません。
(3) CAAで証明書を出してよい認証局を絞る
CAA(Certification Authority Authorization)は、ドメインの持ち主が、そのドメインの証明書を発行してよい認証局をDNSで宣言する仕組みです。RFC 8659は、認証局が意図しない誤発行のリスクを減らすための追加の制御を実装できるようにするものと説明しています。
Googleの発表は、CAAの限界も書いています。DNSの乗っ取りが続いている間の発行は防げません。しかし、DNSの管理を取り戻したあとの守りになり、一部の経路の攻撃は防げます。認証局は、完了したドメイン管理の確認の結果を保存して再利用できます。発行先のアカウントや確認方法を絞った厳しいCAAを戻しておくと、乗っ取りが終わったあと、攻撃者が保存済みの確認を使って新しい証明書を作ることを防げます。
(4) CTログで自社ドメインの証明書発行を見張る
Googleは、Chromeが標準で信頼する証明書は公開のCTログに記録されるため、CTログの監視で、自社ドメインに証明書が発行されたときほぼリアルタイムに気づけると書いています。監視は、駐車中のドメインや地域別の国別ドメインを含む、持っているすべてのドメインを対象にするよう求めています。
RFC 9162も、CTの目的を、証明書の存在を公開のログに記録し、誰でも認証局の活動を監査し、疑わしい証明書の発行に気づけるようにすることと説明しています。
(5) 海外の国別ドメイン(.io、.aiなど)の確認(編集部の整理)
ここは公式資料の記載ではなく、上の内容から導いた編集部の整理です。.ioや.aiなど、海外の国別ドメインを自社で持っている場合は、次を確認します。
登録事業者と管理画面のアカウントを誰が持っているか
管理画面の認証が多要素か
そのドメインが、CAAとCT監視の対象に入っているか
今回の件は、運営側(レジストリ側)が侵害された例です。持ち主の管理画面を堅くしても、運営側の侵害は防げません。だからこそ、CAAとCT監視で、起きたことに早く気づける形にしておく意味があります。
情シスが今日やること
自社と関連会社が持つドメインを一覧にします。使っていない国別ドメインや駐車中のドメインも入れます。.gh、.sl、.asのドメインがないかを確かめます。
登録事業者とDNSの管理画面にログインし、多要素認証を有効にします。管理担当の部門、連絡先メール、変更通知の宛先も更新します。
事業者に、JPドメイン名のレジストリロックを使えるか問い合わせます。使えない場合の代替も聞きます。
CAAレコードを確認します。証明書を出してよい認証局を絞り、使える場合は発行先のアカウントも絞ります。設定を変えると自動更新が止まることがあるため、先に使っている認証局を調べてください。証明書の更新の自動化はSSL/TLS証明書の有効期間が47日に 2029年までの日程と今やる準備 も参考になります。
自社の全ドメインについて、CTログの監視を入れます。.gh、.sl、.asのドメインを持っているなら、最近の発行記録に身に覚えのない証明書がないかを見ます。
DNSの書き換えへの備えとしては、DNSSECのルート鍵が10月11日に切り替わる、社内DNSで確認すること も、社内DNSの確認に使えます。
今後の見通し
Googleは、証明書の有効期間やドメイン管理の確認の再利用を短くするなどの長期の改善を、Chrome Root Programと新しいChrome Quantum-resistant Root Programを通じて進めると書いています。具体的な日程は、この発表には書かれていません。
