GoDaddy は中小企業向けホスティングの侵害をロングテール説明責任の記録に変えた

概要

• GoDaddy のホスティング侵害の記録がロングテールの説明責任のケースとなるのは、直接の顧客基盤に、ドメイン、ホスティング、メール、証明書、サポート、セキュリティ専門知識においてプロバイダーに依存する多くの小規模事業者が含まれていたからである。
• 公開記録には、GoDaddy の2023年のウェブサイトリダイレクト問題に関する声明、GoDaddy と SEC に提出された過去のインシデントに関する開示書類、2025年の FTC の苦情および命令案、さらにマネージド WordPress と共有ホスティングの影響に関するセキュリティ業界の報道が含まれる。
• 説明責任の核心的な問いは、影響を受けたサイトがクリーンアップされ、認証情報がローテーションされ、顧客通知が実用的であり、反復する侵入経路が遮断され、小規模事業者が単独で不正行為の証拠を再構築する必要がないことを、GoDaddy が証明できたかどうかである。
• 責任は分散していたが非対称であった。GoDaddy はホスティングシステム、セキュリティプログラム、ログ、セグメンテーション、検知、顧客通知、修復の証拠を管理していた。顧客は自身のサイトコンテンツ、ローカル認証情報、コミュニケーション、フォローアップを管理していたが、技術的な影響力を欠いていることが多かった。
• 永続的な教訓は、マスマーケット向けホスティングのセキュリティは、川下の証拠によって判断されるべきだということである。顧客が、自身のウェブサイト、訪問者、評判、ビジネス記録が信頼に足る状態に回復したかどうか判断できない場合、プロバイダーの内部的な修復は不完全である。

共有ホスティングの侵害はプロバイダー内部に留まらない

GoDaddy の公開インシデント記録における特異なリスクは、ホスティング侵害がプロバイダーの環境を離れ、一般の訪問者に有毒化されたウェブサイトとして直面する可能性があることだ。従来型の企業侵害では、攻撃者は一つの組織からデータを盗むかもしれない。マスマーケット向けホスティングの事象では、影響を受ける表面には、顧客が商品販売、予約受付、専門サービスの説明、メニュー公開、フォーム設置、あるいは他サービスへのルーティングに使用する数千もの小規模ウェブサイトが含まれうる。プロバイダーはプラットフォームを所有しているが、顧客は公共との関係を所有している。

GoDaddy の2023年2月のウェブサイトリダイレクト問題に関する声明は、権限のない第三者が同社の cPanel 共有ホスティング環境内のサーバーにアクセスし、顧客のウェブサイトを断続的にリダイレクトさせるマルウェアをインストールしたと述べた。また、この活動は洗練された脅威アクターグループによる複数年にわたるキャンペーンの一部であるとも説明した。この表現は重要である。なぜなら、この出来事を単なる一日の停止を超えたものと位置づけるからだ。顧客は、誰かがパターンを認識する前に、自身のサイトが悪用インフラとして機能していなかったかを問わなければならなかった。

同社の2022 Form 10-Kは、このインシデントを正式な投資家リスクの文脈に位置づけた。GoDaddy はまた、マネージド WordPress セキュリティインシデントに関する2021年の開示資料も提出していた。これら二つの記録は併せて読むべきである。これらはすべての顧客が同じ被害に直面したことを証明するものではない。これらは繰り返される説明責任の問題を示している。すなわち、プロバイダーが多くの小規模事業者のためにホスティングを一元化すると、侵害は、アーキテクチャを選択しておらず、プラットフォームを調査できず、どのような証拠を要求すべきかを知らないかもしれない顧客に影響を及ぼしうるということだ。

ウェブサイトの侵害はまた、通常のインフラインシデントにはない公共の信頼という側面を持つ。リダイレクトは、訪問者が正当なビジネスとやり取りしていると信じている間に、その訪問者を詐欺、マルウェア、詐欺コンテンツ、または混乱を招くページへと誘導しうる。小さな会計事務所、教会、歯科医院、レストラン、非営利団体、修理工場、地元の小売店は、自社サイトが攻撃経路の一部になったことにすら気づかないかもしれない。サイト所有者は、顧客が苦情を言い、検索結果が悪化し、ブラウザ警告が表示され、支払いフローが中断された後に初めて問題を発見する可能性がある。

これが、このケースがリスクと説明責任のシリーズに属する理由である。プロバイダーの侵害は顧客の風評被害事象となり、顧客の風評被害事象は訪問者の安全問題となり、訪問者の安全問題は証明の問題となった。すなわち、何が、いつ、どのページに、どの認証情報に、どの顧客に対して起こり、どのように修正されたのか、という問題である。

小規模事業者は簡便性を買い、複雑性を背負った

マスマーケット向けホスティングは、シンプルな約束を売っている。すなわち、顧客はデータセンターを運営したり、セキュリティチームを雇ったり、ウェブインフラのあらゆる層を理解したりすることなく、オンライン化できるというものだ。この約束には真の価値がある。それによって小規模組織はデジタル経済に参加できる。説明責任の問題は、インシデント発生時に複雑性が戻ってきたときに現れる。顧客は突然、マルウェア、DNS、cPanel、WordPress の認証情報、データベースアクセス、ファイルの完全性、リダイレクト、検索評判、顧客通知、インシデント証拠を理解しなければならなくなる。

GoDaddy に対する措置を発表した FTC の2025年のプレスリリースは、同社がウェブサイトホスティングサービスに関して合理的なデータセキュリティ対策を実施していなかったと主張しており、FTC の訴状は、資産管理、パッチ適用、ログ記録、監視、セグメンテーション、多要素認証に関する弱点が疑われると述べている。提案された決定および命令は、セキュリティプログラムと評価の義務を定めている。これらの法的文書は、顧客固有のフォレンジックレポートではない。しかしながら、これらはガバナンス上の問いを先鋭化させる。すなわち、難しい部分をアウトソーシングした小規模顧客は、どのレベルのプラットフォームセキュリティを合理的に期待できるのか、という問いである。

顧客の依存範囲は、ウェブホスティングだけよりも広範であることが多かった。GoDaddy の顧客は、ドメイン、DNS、ホスティング、メール、SSL 証明書、オンラインストアツール、WordPress 管理、セキュリティアドオン、サポートについてこのプロバイダーを利用する可能性がある。したがって、ホスティング環境の一部での侵害は、複数のビジネス機能にわたって不確実性を生み出しうる。ウェブサイトがリダイレクトされた場合、所有者はドメイン設定が変更されたのか疑問に思うかもしれない。WordPress の認証情報が露出した場合、所有者は管理者アカウントが再利用されたのか疑問に思うかもしれない。データベースアクセスが関与した場合、所有者は顧客記録が閲覧されたのか疑問に思うかもしれない。マルウェアが出現した場合、所有者は検索エンジンがサイトをペナルティ対象とするかを疑問に思うかもしれない。

プロバイダーはこれらの問いの一部に、顧客が保有していないログやプラットフォーム証拠によってのみ回答できる。この非対称性がインシデント対応を形作るべきである。小規模事業者は、外部から共有ホスティングの侵入経路を合理的に再構築することはできない。必要なのは、明確な通知、影響を受けた具体的な資産、クリーンアップ手順、認証情報ローテーションの要件、マルウェア除去の証拠、そして一般的なサポートスクリプトに押しやられることなく顧客固有の質問をできる手段である。

これがこのケースのロングテールの特徴である。各顧客はプラットフォームの視点からは小さく見えるかもしれない。集合的には、これらの顧客は大きな公共の信頼表面を形成している。プロバイダーによる一行のアップデートは形式的には真実でありながら、何千もの顧客が自身の訪問者に対してサイトが安全かどうか説明できないままにさせうる。

ウェブサイトリダイレクトは顧客を意図せざる害の発信者に変える

リダイレクトの悪用は、ユーザーとの接触時に信頼を乗っ取るため、特に説明責任に富む。訪問者は、おなじみのアドレスを入力したり、検索結果を辿ったり、請求書のリンクをクリックしたり、QR コードをスキャンしたり、保存されたブックマークを使ったりする。ブラウザは正当な顧客ドメインから開始するが、ユーザーは顧客が意図していない場所にたどり着く可能性がある。被害者の信頼は、見えないホスティングプラットフォームではなく、小規模事業者に寄せられている。

GoDaddy 自身のドメイン転送に関する製品ドキュメントは、インシデントの証拠ではないが、ウェブルーティングがなぜ重要かを説明する助けになる。通常のサイト所有者は、ドメインが人々をどこかに誘導できることを理解している。侵害の間、攻撃者はその直感的信頼を悪用しうる。リダイレクトは断続的であったり、ユーザーエージェントによって標的化されたり、検索結果からのみトリガーされたり、実際の訪問者に影響を与えつつもサイト所有者からは隠されたりする。これにより、単に自分のホームページを開いて何も異常を見つけられない顧客にとって、検出が困難になる。

2023年の声明後のセキュリティ報道は、この顧客向けの被害を強調した。Cybersecurity Dive は、GoDaddy がソースコードの窃取と複数年にわたるキャンペーンを開示したと報じた。Sophos は、攻撃者がマルウェアを使って顧客のウェブサイトを毒したという同社の認めを分析した。The Hacker News は、ホスティングサービスに影響を与えた複数年にわたるセキュリティ侵害について述べた。これらの記事は、プロバイダーの声明を顧客のリスクの物語に翻訳するのに役立つ。すなわち、ウェブサイト所有者は、自分たちが観察できなかったキャンペーンに不本意ながら参加させられていたかもしれないのだ。

証拠に関する問いは具体的だ。どのサイトがリダイレクトされたか？どの時間枠でか？どの訪問者が影響を受けたか？どんな転送先が使われたか？フォームは改変されたか？ファイルは修正されたか？顧客の認証情報やデータベースはアクセスされたか？ブラウザや検索エンジンの警告はトリガーされたか？マルウェアは影響を受けたすべての場所から除去されたか？キャッシュされたページやコンテンツ配信経路は関与したか？同じサイトがクリーンアップ後に再感染したか？顧客は自社のユーザーに警告するのに十分な情報を受け取ったか？

回答は単に「マルウェアは除去された」だけではありえない。除去は必要だが、説明責任には訪問者向けの証拠も必要だ。予約ページが悪意あるサイトにリダイレクトされた歯科医院は、患者に通知する必要があるかもしれない。決済フローが影響を受けた小売店は、支払いや詐欺のシグナルを見直す必要があるかもしれない。非営利団体はドナーを安心させる必要があるかもしれない。専門サービス企業は、クライアントポータルが関与したかどうかを確認する必要があるかもしれない。これらの判断には具体性が求められる。

リダイレクトの悪用は、技術的修正後も検索評判と顧客信頼を損なう。検索エンジンは警告シグナルをキャッシュするかもしれない。訪問者はそのサイトを避けるかもしれない。顧客は事業者を非難するかもしれない。プロバイダーの内部的な修復は、その川下の害を自動的に修復するわけではない。したがって、真摯なインシデント対応には、サーチコンソールのレビュー、マルウェアスキャン、ブラウザ警告への異議申し立て、顧客コミュニケーション、評判回復に関するガイダンスが含まれるべきである。

マネージド WordPress が認証情報の範囲を中心問題にした

2021年のマネージド WordPress インシデントは、GoDaddy の記録において認証情報を中心に据えた。SEC に提出された開示資料によると、権限のない第三者が侵害されたパスワードを使用して、同社のレガシーコードベースにあるマネージド WordPress のプロビジョニングシステムにアクセスし、露出した顧客情報と認証情報のカテゴリを述べている。マネージドホスティングはしばしばプロバイダーの認証情報と顧客の認証情報の境界を曖昧にするため、この詳細は重要である。

非管理環境では、顧客はどの管理者アカウントがサイトを制御しているか、どのデータベースユーザーが存在するか、どの FTP または SSH 認証情報をローテーションする必要があるかを知っているかもしれない。管理環境では、プロバイダーが一部の認証情報を作成、保存、ローテーション、または仲介するかもしれない。顧客は利便性の恩恵を受けるが、侵害後の証明負担はより複雑になる。どの認証情報が露出したのか？どれが自動的にリセットされたのか？どれに顧客のアクションが必要だったのか？どれが環境をまたいで再利用されていたのか？どのサービスアカウント、API キー、データベースパスワード、SSL プライベートキーが影響を受けたのか？

WP Tavern のマネージド WordPress のデータ侵害に関するレポートと、RiskRecon の影響を受けたかどうかの確認方法に関する顧客向けガイダンスは、認証情報のカテゴリがいかに迅速に実践的な対応ステップになるかを示している。顧客は、WordPress の管理パスワード、SFTP またはデータベースパスワード、SSL 証明書、アカウント認証情報をリセットする必要があるかどうかを知る必要があった。また、プロバイダーが実施した認証情報リセットが、自身のローカルリスクを完全にカバーしているかどうかも知る必要があった。

ここで顧客通知の質が測定可能になる。有用な通知は、単に認証情報が露出した可能性があると述べるべきではない。どの認証情報が、どのサービスで、どの期間に、何がプロバイダーによってリセットされ、何が顧客に残っているのか、使用に関するどのような証拠が存在するのか、どのようなフォローアップ監視が推奨されるのかを述べるべきである。また、アクティブな顧客と非アクティブな顧客を区別すべきである。というのも、非アクティブなサイトでも、古い認証情報やドメインが到達可能なままであれば、依然として悪用されうるからだ。

認証情報のローテーションはコストなしではない。サイト、統合、プラグイン、バックアップ、自動デプロイメント、アナリティクス、メール配信、サードパーティサービスを壊す可能性がある。だからこそ、小規模顧客は指示が正確でなければ行動を遅らせるかもしれない。プラットフォームを管理するプロバイダーは、可能な場合にはリセットを自動化し、顧客のアクションが必要な場合には明確な指示を提供し、残余リスクを正直に説明することで、この負担を軽減すべきである。

より広範な説明責任の教訓は、管理された利便性は管理された責任を生み出すということである。プロバイダーがホスティングを容易にするために認証情報を保存または仲介するのであれば、信頼が損なわれたときに認証情報の回復も容易にしなければならない。顧客は、自分のウェブサイトを動かしている秘密が何かを理解するためだけに、一夜にしてインシデントレスポンダーにならなければならないようではいけない。

繰り返される侵入の申し立てが説明責任の枠組みを変えた

単一のインシデントは、検出、封じ込め、または修復の失敗として扱われうる。繰り返されるパターンは異なる疑問を提起する。プロバイダーは学習したのか、と。FTC の訴状におけるセキュリティプログラムの欠陥と複数のインシデントに関する申し立ては、その理由から重要である。これらは GoDaddy の記録を侵害の再録からガバナンスのケースへと変える。

CISA のSecure by Designガイダンスは、テクノロジーサプライヤーに対し、事後対応的なアドバイスだけでなく、製品と運用の選択を通じて顧客のセキュリティ負担を軽減するよう求めているため、関連性がある。CISA の安全な構成ベースラインもまた、再現可能でレビュー可能な構成が重要であるという考え方を強化する。これらは一般的な情報源であり、GoDaddy に固有の所見ではない。これらは、大規模ホスティングプロバイダーが実証できるべき種類の管理システムに対するベンチマークを提供する。

繰り返されるホスティングインシデントの後の説明責任の問いは、いかなるプロバイダーも完全なセキュリティを保証できるかどうかではない。できるプロバイダーはいない。問われるのは、GoDaddy が、資産のインベントリ作成、システムのパッチ適用、環境のセグメント化、不審な活動の監視、特権アクセスの保護、ログの保存、過去の侵害からの学習が可能なセキュリティプログラムを持っていたかどうかである。これらは通常の管理策だが、マスマーケット向けホスティング環境では、その欠如や弱点が、独立した可視性をほとんど持たない顧客に影響を与える。

繰り返し侵入の分析は注意深くあるべきだ。公開文書は部外者にすべての技術的詳細を提供するわけではない。いくつかの主張は法的申し立てのままである。一部の修復は開示の前または後に行われたかもしれない。しかし、顧客、規制当局、投資家は、インシデント対応が持続的な変化をもたらしたかどうかを問う権利がある。同じような広範な顧客被害が再来するならば、プロバイダーの学習の証拠が説明責任の一部となる。

適切な証拠には、攻撃者の活動のタイムラインだけでなく、管理策の改善のタイムラインが含まれるだろう。影響を受けたシステムはいつ発見されたか？どのようなインベントリのギャップが見つかったか？監視はどう変わったか？セグメンテーションはどう変わったか？特権アクセスはどう変わったか？パッチ適用プロセスはどう変わったか？顧客通知プロセスはどう変わったか？これらの変更をどのような独立した評価が確認したか？FTC の提案された命令は、その種のプログラム的な説明責任を指し示しているが、顧客は依然として平易な言葉での運用上の証明を必要としている。

インシデント処理には顧客サイトを証拠として含めるべき

NIST のコンピュータセキュリティインシデント対応ガイドは、準備、検出、分析、封じ込め、根絶、回復、インシデント後の活動を中心にインシデント対応を枠づけている。ホスティング侵害では、これらの段階はプロバイダーのインフラだけでなく、顧客サイトにも適用されなければならない。サイトは同時に被害者であり、証拠物であり、配信メカニズムでもありうる。

影響を受けた顧客向けの証拠パッケージは、使用可能なほど具体的であるべきだ。影響を受けたドメインまたはホスティングアカウント、疑われる侵害の期間、観測された悪意ある挙動、変更されたファイルや設定、リセットされた認証情報、除去されたマルウェア、レビューされたログ、推奨される顧客のフォローアップを特定するべきである。また、プロバイダーが知り得ないことも説明すべきである。訪問者レベルの影響が再構築できないなら、そう言うべきだ。ログが不完全だったなら、そう言うべきだ。特定の訪問者がリダイレクトされたかどうかをプロバイダーが判断できないなら、そう言うべきだ。

NIST のエンタープライズパッチ管理計画ガイドは、共有ホスティングのインシデントがしばしば侵入対応と同様にパッチガバナンスも含むため、有用である。顧客は、ホスティングプラットフォーム、コントロールパネル、プラグイン、管理システム、サポートインフラにおける既知の脆弱性が、露出度と悪用可能性に応じて優先順位付けされているという確信が必要である。しかし繰り返すが、顧客はプロバイダーのパッチ状態を外部から検証することはできない。プロバイダーはプログラム設計とインシデント報告を通じて証拠を提供しなければならない。

顧客側の記録も保存されるべきである。サイト所有者は、プロバイダーの通知、サポートチケット、マルウェアスキャン結果、認証情報ローテーション記録、バックアップ、クリーンアップの請求書、顧客の苦情、サーチコンソール警告、ブラウザ警告、訪問者への連絡を保持すべきである。この記録は、保険、支払い紛争、規制対応、顧客信頼、または社内の教訓のために必要とされるかもしれない。

多くの顧客は、ガイダンスなしにこれを行うことを知らないだろう。したがって、プロバイダーの通知には保存チェックリストを含めるべきである。それには、何をスクリーンショットすべきか、何をエクスポートすべきか、バックアップ前に何を削除すべきでないか、いつ認証情報をローテーションすべきか、DNS 設定をどのように確認すべきか、不審な管理者ユーザーをどこで探すべきか、支払いやフォームのプラグインをどのようにレビューすべきか、リダイレクトがなくなったことをどのように確認すべきか、が含まれるべきである。目標は、不当に責任を顧客に転嫁することではない。顧客自身の証拠を使えるようにすることである。

プロバイダーはまた、顧客を技術的な曖昧さの中に埋没させることを避けるべきである。小規模事業者はウェブシェルに関する論文を必要としない。必要なのは、サイトが影響を受けたかどうか、何が起こったか、何がなされたか、何が不確かなままか、どのようなアクションを取らなければならないかについての直接的な声明である。平易な言葉は一つの管理策である。

悪用インフラが被害者の地図を変える

ホスティング侵害は、多くの侵害通知が捉えるよりも広範な被害者の地図を作り出す。直接の顧客はウェブサイト所有者かもしれない。間接的な被害者には、サイト訪問者、詐欺にリダイレクトされたユーザー、支払い顧客、フォームが傍受された人々、検索ユーザー、スパムや風評被害の影響を受けた他のサイト、悪意あるトラフィックをブロックしなければならないインターネットプラットフォームが含まれうる。侵害された事業者はまた、ブラウザ、検索エンジン、メールプロバイダー、決済処理業者の目には悪用の発信源と映るかもしれない。

これが、GoDaddy のケースが不正利用連絡経済と交差する理由である。小規模なウェブサイトはセキュリティチームを持たないかもしれないが、それでもキャンペーンのノードになる可能性がある。そうなった場合、不正利用の苦情はホスティングの連絡先、ドメインの連絡先、レジストラのチャネル、ブラウザの報告、プラットフォームの執行システムを通じて流れるかもしれない。これらのチャネルが機能しなければ、訪問者や防御側は問題を修正できる人物にたどり着くのに苦労する。

GoDaddy のビジネスモデルは、これを特に重要にする。同社はホスティングプロバイダーであるだけでなく、ドメイン登録や中小企業のウェブプレゼンスにも広く関連付けられている。顧客は一つの企業をインターネットへの玄関口として利用するかもしれない。その集中は通常時のサポートを簡素化しうるが、同時に不正利用処理への期待も集中させる。顧客のサイトが訪問者をリダイレクトしている場合、ドメイン、ホスティング、ウェブサイトツールを販売したのと同じブランドが、被害者が説明責任を期待する場所であるかもしれない。

マスホスティング侵害のたびに、悪用インフラに関する問いは直接問われるべきである。影響を受けたサイトは訪問者を悪意ある目的地に送ったか？フィッシングやマルウェアのページが関与したか？リダイレクトは影響を受けたすべてのアカウントから除去されたか？削除前に悪意あるファイルは分析のために保存されたか？ブラウザや検索の警告は対処されたか？不正利用報告チャネルは監視されたか？顧客は訪問者の苦情への対応方法を知らされたか？

プロバイダーがすべての訪問者の結果を知ることはできないかもしれない。もしそう述べるなら、それは許容できる。許容できないのは、顧客サイトのクリーンアップを純粋に内部の衛生問題として扱うことだ。いったん正当なサイトが配信経路として利用されれば、公に向けた害はプラットフォーム運用を超えて広がる。証拠はその害に従うべきである。

顧客にとっての教訓は、少なくとも最低限の悪用の可視性を維持することである。セキュリティ報告をどこで受け取るか、サイトの完全性をどのように検証するか、認証情報をどのようにリセットするか、インシデント発生時にプロバイダーにどのように連絡するか、訪問者とどのようにコミュニケーションを取るかを知っておくべきだ。小規模サイトは24時間体制のセキュリティオペレーションセンターを必要としない。必要なのは、ウェブサイトが他者へのリスクとなったときに行動できる、指名された責任者である。

顧客通知は安心と行動を分離すべき

顧客通知はしばしば送信されたかどうかで判断される。GoDaddy の記録はより良いテストを示唆する。その通知は顧客に行動を起こさせたか、と。有用な通知は、安心感、事実、必須のアクション、任意のアクション、未知の事項を分離する。それは、すべてをリセットしなければならないのか、コンサルタントを雇うべきか、訪問者に通知すべきか、待つべきかと顧客を迷わせる曖昧な表現を避ける。

通知の最初の部分は対象範囲であるべきだ。顧客は影響を受けたのか、それとも潜在的に影響を受けた可能性があるだけなのか？どの製品か？どのドメインか？どのホスティングアカウントか？どの期間か？どのデータまたは認証情報のカテゴリか？どのような悪意ある挙動か？責任を持って言えるならば、どのシステムが影響を受けなかったか？対象範囲は顧客に境界を与える。

第二の部分はプロバイダーのアクションであるべきだ。GoDaddy は何をしたのか？マルウェアを除去したか？パスワードをリセットしたか？データベース認証情報をローテーションしたか？証明書を交換したか？攻撃者のアクセスをブロックしたか？システムにパッチを適用したか？法執行機関に通知したか？フォレンジック企業を雇ったか？ログを保存したか？不審なアカウントを無効化したか？顧客は、作業を重複させたり、ギャップを残したりしないように、すでに処理されたことを知る必要がある。

第三の部分は顧客のアクションであるべきだ。アカウントパスワードを変更する。WordPress の管理者ユーザーを確認する。プラグインの認証情報をリセットする。支払いフォームをチェックする。DNS を確認する。ファイルをスキャンする。検索警告に注意する。必要なら訪問者に通知する。証拠を保存する。移行やクリーンアップのためにサポートに連絡する。各アクションには理由がなければならない。その背後にあるリスクを理解すれば、顧客は手順を完了する可能性が高くなる。

第四の部分は不確実性であるべきだ。訪問者レベルの影響は不明かもしれない。一部のログが不完全かもしれない。プロバイダーは認証情報の使用の証拠を持っていないが、それを否定できないかもしれない。特定のマルウェアファミリーは除去されたが、再感染は顧客のプラグイン次第かもしれない。不確実性を述べることは弱点ではない。それは誤った終結を防ぐ。

最後に、通知は顧客のニーズに合わせてタイミングを計るべきである。顧客が怒ったユーザーを通じてすでにリダイレクトを発見した後に届く通知は、準備を可能にする通知よりも弱い。内容が大幅に変更される通知は、バージョン履歴を保存すべきである。顧客は、行動した時点で自分が何を知っていたかを証明する必要があるかもしれない。

セキュリティプログラムは顧客の成果を通じて見える必要がある

FTC の2025年1月の発表が重要であるのは、GoDaddy の記録をセキュリティプログラムの説明責任に関する公開テストに変えたからである。この記録の価値は、規制当局が失敗を申し立てたことだけではない。その申し立ては、顧客が混乱として感じるであろう管理策の不在を描写している。すなわち、不完全な資産インベントリ、弱い監視、不十分なセグメンテーション、不適切なログ記録、遅れたパッチ適用、特権の弱点は、顧客サイトが訪問者をリダイレクトしたり、認証情報をリセットしなければならなかったりするときに、抽象的であり続けない。

成熟したホスティングセキュリティプログラムは、顧客の成果から読み取れるべきである。顧客はすべての内部セキュリティ図を必要とせず、多くの詳細は保護されたままでよい。しかし、何か問題が起きたときに、そのプログラムの効果を見られるべきである。影響を受けた資産は把握されていたか？不審な活動は迅速に検出されたか？侵入経路は境界づけられていたか？ログは影響を受けた顧客を特定するのに十分だったか？顧客通知は具体的だったか？認証情報はローテーションされたか、または顧客のアクションに明確に割り当てられたか？再感染は防止されたか？教訓は製品とサポートの変更に反映されたか？

これは一般的なポリシー準拠とは異なる基準である。プロバイダーは文書化されたセキュリティポリシーを持っていても、顧客に役立つ証拠を残さないかもしれない。プロバイダーはトレーニングを完了しても、顧客レベルのインシデントレポートが弱いままかもしれない。プロバイダーは評価者を雇っても、影響を受けた小規模事業者が何をすべきかを説明できないかもしれない。顧客に見えるテストは、セキュリティプログラムが顧客が使える決定、記録、修復手順を生み出しているかどうかである。

顧客成果のレンズは、共有ホスティングにおいて特に重要である。専有のエンタープライズ環境では、顧客はログ、契約上の監査権、指名されたアカウントマネージャー、そして独自のインシデントチームを持っているかもしれない。共有のマスマーケット向けホスティングでは、顧客はしばしば通知とヘルプページのパスだけを受け取る。つまり、プロバイダーの内部プログラムは証拠を外部に翻訳しなければならないということだ。プロバイダーがどのアカウントが影響を受けたか正確に知っていれば、顧客は曖昧な言葉を受け取るべきではない。プロバイダーが訪問者の影響を特定できなければ、顧客はその限界を知らされるべきだ。プロバイダーが一部の秘密をリセットし、他をリセットしなかった場合、その区分は明確であるべきだ。

独立した評価は役立つが、それが私的な安心材料になることを避けてのみである。同意命令による評価は、セキュリティプログラムが存在し機能しているかをテストするかもしれない。顧客は依然として製品レベルの透明性を必要とする。プロバイダーが監視を改善したと言う評価はあるレベルでは有用だ。サイトが影響を受けた顧客は、自身のサイトが今やクリーンかどうか、リダイレクト経路が除去されたかどうか、保存された認証情報が変更されたかどうか、古いマルウェアの痕跡が残っていないかどうかを知る必要がある。プログラムの証明と顧客の証明は合致しなければならない。

同じ論理が投資家向け開示にも当てはまる。公開企業の提出書類はインシデントとリスク要因を記述できる。それは、企業がサイバー脅威、法的手続き、修復コスト、風評リスクに直面していることを投資家に伝えることができる。それは価値がある。しかし投資家向け開示は顧客の修復ではない。投資家は GoDaddy にとっての企業リスクを理解したい。顧客は自身のサイトと訪問者にとっての運用リスクを理解したい。強力な説明責任システムは、それらが同一であると偽ることなく、両方に役立つべきである。

プロバイダーはまた、時間を異なって測る必要がある。内部的には、時計は不審な活動が検出されたとき、または対応チームが着手したときに開始されるかもしれない。顧客にとっては、時計は自身のウェブサイトが奇妙に振る舞い始めたとき、訪問者がリダイレクトされたとき、認証情報が露出したとき、検索エンジンがページにフラグを立てたとき、またはサポートが回答できないときに開始される。これらの時計がずれていれば、プロバイダーは迅速にコミュニケーションしたと信じるかもしれないが、顧客は遅い通知を経験する。有用なインシデント後レビューは両方の時計を比較すべきである。

顧客成果はまた、サポートがセキュリティの一部であるかどうかを明らかにする。セキュリティチームはマルウェアを根絶できる一方、サポートは依然として実用的なガイダンスなしに顧客を放置するかもしれない。法務チームは慎重な声明を作成できる一方、サイト所有者はまだ訪問者に通知すべきか知らないままかもしれない。製品チームはバックエンドサービスにパッチを当てられる一方、古いプラグイン、キャッシュされたページ、顧客が作成したアカウントは依然としてリスクをはらむ。説明責任にはこれらのチーム間の調整が必要である。なぜなら、顧客はプラットフォームを一つのプロバイダーとして経験するからだ。

GoDaddy および同様の企業にとって、長期の基準は顧客証拠プレイブックであるべきだ。主なインシデントタイプごとに、そのプレイブックは、影響を受けたアカウントを特定するために必要なデータ、提供すべき最小限の顧客固有の事実、必要な認証情報アクション、クリーンアップ証拠、訪問者リスクの文言、サポートエスカレーションパス、バージョン管理された公開更新、残余不明事項の声明を定義すべきである。そのプレイブックは、顧客がすでに怒っている間に起草されるのではなく、次のインシデントの前にテストされるべきである。

顧客にとっての基準は、ベンダー依存ファイルであるべきだ。それは手の込んだものである必要はない。ドメイン、ホスティングアカウント、事業責任者、技術連絡先、管理者ユーザー、DNS プロバイダー、バックアップ状況、支払いやフォームのプラグイン、インシデント連絡パス、顧客通知テンプレートをリストアップすべきだ。プロバイダーのインシデントが発生した場合、顧客は誰がログインできるかを発見する初日を費やすべきではない。その準備は、小規模組織が自分たちの手に保つことができる数少ない管理策の一つである。

最も重要な点は、セキュリティプログラムの説明責任は「管理策が改善された」と言うことで満たされないということだ。管理策は次の顧客の経験を変えなければならない。次の影響を受けた顧客は、より明確な通知を受け取り、より迅速に行動し、正しい認証情報をローテーションし、偽のサポートを避け、より良い証拠を保存し、より少ない推測で信頼を回復するべきだ。プログラムがそれらの成果を改善しなければ、それは公開の説明責任ではなく内部の書類仕事にとどまる。

それが進歩を評価する最も公正な方法でもある。目標は、マスマーケットのホストが機密の内部図を公開したり、顧客サイトが悪用されないことを保証したりするよう要求することではない。目標は、プロバイダー側のセキュリティを顧客の末端で現実のものにすることだ。小規模事業者が自身のウェブサイトが再び信頼できるかどうかを尋ねるとき、その答えは証拠に基づくべきである。すなわち、何が変わったか、何が除去されたか、どの認証情報がリセットされたか、どのログがレビューされたか、何が不確かなままか、そして顧客が依然として何をすべきか。それ以下ならば、ロングテールはリスクを抱えたままである。

したがって、公開記録はホスティング購入者とホスティングプロバイダーを同じ基準に向けて推進すべきである。サポートチケット、プレス声明、即時のクリーンアップ期間を超えて存続する証拠、という基準である。

その基準は控えめだが、それは修復されたインフラと、一般のサイト所有者にとっての回復された信頼の違いである。

それは、次のリダイレクトキャンペーンの前に測定されるべきであり、顧客が自ら最初に発見した後に説明されるべきではない。

最も小さな顧客にこそ最も明確な証明が必要

GoDaddy の最後の教訓は、証明は最も技術スタッフの少ない顧客にとって最もシンプルであるべきだということだ。大企業はレスポンダーを雇い、ベンダーに挑戦できる。小さな店舗は一人のオーナー、一つのウェブサイト、そして困惑した訪問者の列を持っているかもしれない。そのような顧客には、平易な終結通知が必要だ。影響を受けたかどうか、何が除去されたか、どの認証情報が変更されたか、顧客に残されているものは何か、再発する不正利用をどこに報告するか。明確な証明は単なる礼儀ではない。それはロングテールのホスティング被害に境界を設ける方法である。

説明責任のテストは川下の証明である

GoDaddy のホスティング侵害の記録に対する最終的な説明責任のテストは、川下の証明である。プロバイダーは、影響を受けたホスティングシステムがクリーンアップされ、アクセス経路が閉じられ、認証情報がリセットされ、顧客サイトが訪問者をリダイレクトしなくなり、同じパターンが再発しにくくなったことを証明できたか？顧客は、自身のサイト、訪問者、フォーム、認証情報、評判が信頼できる状態に回復したことを証明できたか？二つの証明は関連しているが、同じではない。

公開記録は、GoDaddy でホストされているすべてのサイトが侵害された、またはすべての顧客が同じように被害を受けたと扱うことを正当化しない。しかし、マスホスティングを高い責任を伴う領域として扱うことは正当化する。規模を持って小規模組織にサービスを提供するプロバイダーは、単にディスクスペースを貸しているのではない。プラットフォーム層を見ることができない事業者のために、公共の信頼を仲介しているのである。

GoDaddy にとって、より強固な説明責任への道は、顧客が使える証拠を通じて走る。すなわち、より明確な製品境界、より強力なセキュリティプログラムの透明性、実用的なインシデント通知、具体的な認証情報の指示、顧客レベルの修復証拠、平易な言語による保証を生み出す独立した評価、そして小規模事業者のサイトが不正利用の場となったことを認識するサポートフローである。

顧客にとっての教訓は、ウェブサイトを静的なパンフレットとして扱うのをやめることである。小規模事業のウェブサイトは、運用上の資産である。それはリード、支払い、予約リクエスト、健康に関する問い合わせ、アカウントリセット、評判のシグナルを収集するかもしれない。それには所有権、バックアップ、認証情報の規律、セキュリティ連絡先、そしてプロバイダーがすべての局地的な結果を説明できると想定しないインシデント計画が必要である。

規制当局と保険会社にとって、GoDaddy の記録は、プラットフォームのセキュリティがプロバイダーの内部的な復旧だけでは判断できない理由を示している。川下の害は多くの小規模な主体に散らばりうる。したがって、執行、ベンダーレビュー、保険の質問票は、プロバイダーがホスティング侵害後に顧客固有の証拠を生成できるかどうかを問うべきであり、セキュリティポリシーを持っているかどうかだけを問うべきではない。

より深い教訓は非対称性についてである。GoDaddy の顧客は簡便性を買った。侵害の間、彼らは複雑性を背負った。説明責任とは、プロバイダーがその複雑性の多くを、使用可能な証拠へと戻すことを意味する。小規模顧客は、自身のウェブサイトが訪問者に対して悪用されたかどうかを知るために、フォレンジック調査員になる必要があってはならない。プラットフォームの約束は、単にサイトをホストすることだけではない。それは、ホスティング層が失敗したときに信頼を回復可能にすることである。

その基準は控えめだが、それは修復されたインフラと、一般のサイト所有者にとっての回復された信頼の違いである。

それは、次のリダイレクトキャンペーンの前に測定されるべきであり、顧客が自ら最初に発見した後に説明されるべきではない。