要約
- Akamai の 2021 年 6 月 17 日の更新によると、Prolexic Routed 3.0 サービスのインシデントがルーテッド DDoS 緩和サービスを使用する一部の顧客に影響を与え、アラートは東部時間午前 8 時 47 分に開始され、顧客トラフィックは復旧時まで自動または手動で再ルーティングされました。
- 責任のある問題は委任された緩和です。顧客は DDoS 攻撃を生き残るためにトラフィックをスクラビングサービスに送信しますが、緩和プロバイダー内の検証またはルーティング状態が失敗すると、そのルートは事業継続の依存関係になります。
- Akamai は、インシデントはシステムアップデートやサイバー攻撃によるものではなく、誤って超過したルーティングテーブルの値が原因であると述べました。これにより、分析は運用ルート検証、キャパシティ/状態制御、再ルーティング、および顧客復旧に絞られます。
- ThousandEyes の外部測定記録は重要です。それは顧客への影響のばらつきとバックアップ計画の価値を示したからです。ルーテッド緩和インシデントは、防御パスが損なわれたときに顧客がトラフィックを安全にバイパスまたは戻せるかどうかで判断されるべきです。
- 耐久性のある修復証拠は、ルートテーブルのガードレール、事前検証されたバイパス、顧客通知、自動再ルーティング範囲、手動サポート能力、トラフィック戻しの安全性、および緩和パスが吸収するはずの攻撃よりも大きな障害にならないことの証明をカバーする必要があります。
委任された緩和が継続性の管理主体を変える
Akamai の公開更新、Akamai provides Prolexic DDoS service impact updateは、コアインシデント記録です。同社は Prolexic Routed 3.0 が一部の顧客に影響を与えるサービスインシデントを経験したと述べました。アラートは東部時間午前 8 時 47 分に開始され、影響を受けた顧客トラフィックは Akamai チームによって自動または手動でルーティングされ、サービスは東部時間午後 12 時 47 分に復旧しました。また、インシデントはシステムアップデートやサイバー攻撃によるものではなく、問題は誤って超過したルーティングテーブルの値であると述べました。
その声明は説明責任の問題を明確にします。重要なのは Akamai が攻撃されていたかどうかではありません。重要なのは、保護サービスが顧客トラフィックの経路をどのように制御し、顧客が障害時にその経路からどのように脱出できるかです。DDoS 緩和は単なる追加のセキュリティ機能ではありません。ルーテッドモデルでは、顧客のライブネットワークトポロジの一部になる可能性があります。
Akamai の Prolexic 資料は、このサービスをインフラストラクチャ向け DDoS 保護として説明しています。Prolexic 製品ページ、Prolexic 製品概要ページ、およびProlexic 製品概要 PDFは防御目的を説明しています。つまり、悪意のあるトラフィックを吸収、検査、緩和してから顧客のオリジンに到達させます。後期/現在の製品言語は 2021 年のインシデント所見として扱うべきではありませんが、依存関係を生み出すサービスモデルを明確にします。
依存関係は誤解されやすいです。顧客は DDoS 緩和をサービスの前に配置された盾と考えがちです。ルーテッド設計は盾以上のものです。それはトラフィックが顧客に到達する方法を変えます。トラフィックがスクラビングセンターを介してアナウンスまたはリダイレクトされる場合、ルート状態、GRE トンネル、直接接続、リターンパス、およびプロバイダー運用が可用性の一部になります。保護パスが失敗すると、顧客はすでに設計、承認、テスト、理解されているバイパスパスを必要とする可能性があります。
「バイパス」という言葉は中心です。バイパスは保護サービスが損なわれた後のパニック的な即興ではありません。それは、攻撃トラフィックに再び直面するリスクとバランスを取りながら、トラフィックを安全なパスに戻すための事前計画された方法です。顧客は攻撃中に軽率に保護を解除したくありません。しかし緩和プロバイダーの障害時には、顧客は失敗した防御パスを継続するか、バックアップルートを介してオリジンを露出させるかを選択する必要があるかもしれません。その決定はインシデント前に設計されていなければなりません。
ルーテッド保護はルート検証を顧客ケアに変える
Akamai のサービス記述資料が重要なのは、ルーテッド緩和がネットワーク制御メカニズムに依存していることを示しているからです。Akamai サービス記述 PDFは Prolexic Routed を BGP がトラフィックを Akamai のスクラビングセンターに誘導するものとして説明しています。Akamai のブログProlexic and Equinix Cloud Exchangeは相互接続を通じて DDoS 防御を顧客オリジンに近づけることについて議論しています。これらの資料は障害の事後解析ではありませんが、ルーティング制御がサービスである理由を説明しています。
BGP 自体はRFC 4271で定義されています。GRE は、緩和アーキテクチャでトラフィックリターンやトンネル設計の一部としてよく使用され、RFC 2784で定義されています。これらの標準は Akamai が 2021 年に何を間違えたか正しかったかを述べているわけではありません。技術的な語彙を明確にします。ルートアナウンスメント、トラフィックパス、トンネル、リターンメカニズムは背景詳細ではなく、製品表面です。
プロバイダーのルーティングテーブル値が超過された場合、顧客はそれが自分のトラフィックにとって何を意味するかを知る必要があります。影響を受けた状態が新しいルートプログラミングをブロックしましたか？ リターントラフィックに影響を与えましたか？ 特定の顧客、特定のプレフィックス、特定の地域、特定のルーティング関係のみに影響しましたか？ Akamai の公開声明は簡潔だったため、責任ある分析は詳細を invent すべきではありません。しかしその簡潔さ自体が修復の問いを設定します。ルーテッド緩和制御が顧客可用性に影響を与える形で状態値を超過するのを防ぐガードレールは何か？
この文脈でのルート検証は顧客ケアです。単なる内部ネットワークエンジニアリングチェックではありません。プロバイダーの検証は顧客の収益、公開ポータル、API、銀行アクセス、SaaS アプリケーション、緊急対応サービスを保護します。検証の失敗は顧客運用チームに作業を移行させます。彼らは待機、再ルーティング、バイパス、ユーザーへの連絡、サポートへのエスカレーションを決定しなければなりません。
RFC 7454、BGP Operations and Securityは、ルートポリシー、フィルタリング、運用衛生に関する一般的な運用セキュリティ期待を提供します。MANRSnetwork operator actionsおよび CISA のSecuring Internet Routingは、ルート規律に関する公開およびコミュニティフレーミングを提供します。これらはインシデント特定の所見ではなく一般的な参照です。ルーテッド緩和サービスがプロバイダーのルート規律を直接顧客の継続性に組み込むため、重要です。
タイポグラフィノート
外部測定は異なる影響を示す
ThousandEyes のAkamai Prolexic Routed outage analysisは、プロバイダーの外部から見るため価値があります。到達可能性の違い、ピアリング関連の動作、顧客のばらつきを観察しました。ThousandEyes は後にこのイベントをSeven outages that shook up 2021に含め、準備されたバックアップ計画を持つ一部の組織が影響を軽減できたことを強調しました。これこそが説明責任の教訓です。ルーテッド緩和の障害はプロバイダーの障害だけでなく、顧客のバイパス準備とプロバイダー支援の再ルーティングのテストです。
影響のばらつきの存在は被害者非難になるべきではありません。顧客は DDoS 緩和を購入するのは、自分で安全に処理できない問題を専門プロバイダーに吸収してもらいたいからです。サービスパスが失敗した場合、プロバイダーはルート安全性、ステータス通知、自動再ルーティング、サポート能力、事後修復に引き続き責任を負います。同時に、ミッションクリティカルな公開サービスを持つ顧客は、保護パスが障害から免れないため、テスト済みのバイパスとフォールバック設計を必要とします。
二次的なレポートには、SecurityWeek のAkamai blames outage on DDoS protection serviceや iTnews のAkamai routing error caused widespread outagesがあり、公開サービスに影響を与える目に見える混乱を説明しています。そのようなレポートは範囲を示すことができますが、すべての組織に均一な期間や同一の復旧姿勢を主張するために使用すべきではありません。ルーテッド緩和は、プレフィックス、ルーティングパートナー、バイパス計画、アプリケーション設計、通信速度に応じて顧客に異なる影響を与えます。
測定証拠はまた、公開ルート可視性が必要である理由を示しています。顧客のウェブサイトや API は、オリジンサーバーが正常でも利用できない場合があります。ユーザーはアプリケーションがダウンしていると見ます。顧客は明らかなオリジンの問題を見ないかもしれません。プロバイダーは再ルーティングしているかもしれません。外部プローブはトラフィックがどこで失敗するか戻るかを示すことができます。その可視性がなければ、対応者は間違ったレイヤーをデバッグする時間を無駄にします。
プロバイダーにとって、教訓は公開事後通信には測定を意味のあるものにするための十分なルーティングと顧客影響構造を含めるべきであることです。公開声明が「サービスインシデント」とだけ言う場合、顧客は自分のランブックを変更すべきかどうかを判断できません。どのサービスが影響を受けたか、どのタイプのルーティング状態が失敗したか、トラフィックがどのように再ルーティングされたか、どの自動制御が機能したか、どの手動制御が必要だったか、どの再発防止策が変更されたかを示せば、顧客は自分のアーキテクチャを改善できます。
バイパスは共有設計であり、土壇場の決定ではない
適切なバイパス計画にはいくつかの要素があります。顧客はどのプレフィックスとサービスが保護されているかを知っています。顧客は常時オンとオンデマンドモードで何が起こるかを知っています。プロバイダーと顧客は誰がトラフィック変更を承認できるかを知っています。アップストリームは代替アナウンスが許可されているかどうかを知っています。DNS、TLS、ファイアウォール、オリジンアクセス制御、アプリケーション制限が変更されたトラフィックパスの準備ができています。サポートチームはどのビジネスサービスが最優先かを知っています。エンドユーザー向けの通信テンプレートが準備されています。
その設計がなければ、バイパスは新たなリスクを生み出す可能性があります。スクラビングサービスを迂回してトラフィックを送信すると、サービスが吸収するはずだった攻撃にオリジンがさらされる可能性があります。失敗した緩和パス内にトラフィックを残すと、障害が長引く可能性があります。より具体的なプレフィックスをアナウンスすると、ルートポリシーの副作用が生じる可能性があります。DNS を変更すると遅すぎるかキャッシュ依存になる可能性があります。オリジン制限を無効にするとセキュリティ上の露出が生じる可能性があります。これらのトレードオフは、公開サービスがすでに利用できないときに冷静に決定することはできません。
NIST SP 800-61 Revision 2、Computer Security Incident Handling Guideは一般的なガイダンスですが、そのインシデントライフサイクルは関連性があります。準備、検出、封じ込め、根絶、復旧、教訓。ルーテッド緩和では、準備にはトラフィックを安全に移動する方法を知ることが含まれます。復旧には、サージ、リーク、セキュリティギャップを引き起こさずに通常の保護ルーティングを復元することが含まれます。
顧客バイパスの問題は経済的でもあります。中小企業は独自のネットワークエンジニアリングスタッフを持っていないかもしれません。彼らはプロバイダーとマネージドホストに完全に依存しているかもしれません。ルーテッド緩和が失敗した場合、どのプレフィックスがアナウンスされているか、誰が変更を承認できるか、バイパスが存在するかどうかを知らないかもしれません。そのような顧客に保護を販売するプロバイダーは、エンタープライズグレードのアーキテクチャ図だけでなく、実用的なランブック言語を提供する必要があります。
大企業は異なる問題に直面します。彼らは洗練されたネットワークと複数のプロバイダーを持っているかもしれませんが、ガバナンスが遅い場合があります。緊急再ルーティングにセキュリティ、ネットワーク、法務、ビジネス、経営陣の承認が必要な場合、バイパスは紙の上に存在しても使用できない可能性があります。したがってプロバイダーのインシデント通信は顧客が迅速で証拠に基づいた決定を下すのに役立つべきです。
自動再ルーティングにはカバレッジの証明が必要
Akamai の更新は、影響を受けた顧客トラフィックが Akamai チームによって自動または手動でルーティングされたと述べました。このフレーズは2つの復旧モードを特定するため重要です。自動再ルーティングは事前構築されたフェイルオーバーロジックを示唆します。手動再ルーティングは自動パスがカバーしなかった、完了しなかった、または顧客固有の処理が必要な場合の人間の介入を示唆します。説明責任の問いは、これらのカテゴリがインシデント後にどのように変化したかです。
自動再ルーティングは現実的なプロバイダー側の障害に対してテストされるべきです。計画された演習や顧客要求による移行中に再ルーティングが機能することを証明するだけでは十分ではありません。プロバイダー自身のルーティング状態が損なわれているとき、アラート量が多いとき、多くの顧客が同時に助けを必要としているとき、ステータス通信がプレッシャーにさらされているときに機能する必要があります。DDoS 緩和プロバイダーの復旧システムは、サービス自体が共有インフラであるため、マルチカスタマー同時影響向けに設計されていなければなりません。
手動サポート能力は、すべての顧客が最初に並べるわけではないため重要です。プロバイダーは優れたエンジニアを持っていても、多くの顧客が同時に電話すると待ち行列に直面する可能性があります。公開修復記録は、手動ルーティング手順が削減されたか、より多くの顧客が自動再ルーティングを取得したか、サポートランブックが変更されたか、通知がより正確になったかを説明する必要があります。Akamai は、障害時にすべての顧客が最寄りのスクラビングセンターへの自動再ルーティングを確保すると述べました。その約束は修復マーカーですが、顧客は後日完了の証拠を必要とします。
トラフィック戻しも復旧の一部です。プロバイダーパスが修正された後、顧客を保護に戻すことは、ルート収束、キャッシュ動作、ファイアウォール状態、トンネル状態、攻撃トラフィックが管理されていない場合、リスクを生み出す可能性があります。サービスは技術的に復元されても、不注意な戻しパスは断続的な障害を引き起こす可能性があります。したがってインシデント記録には障害の開始時刻と停止時刻だけでなく、トラフィックがどのように安定した保護状態に戻されたかも含めるべきです。
Akamai の 2021 年 Form 10-K、SEC 提出書類は、より広範なビジネスリスクの文脈を提供します。Akamai は顧客がパフォーマンス、セキュリティ、可用性に使用するサービスを販売しています。この提出書類は Prolexic インシデントを決定するものではありません。セキュリティと配信インフラにおけるプロバイダーの障害が顧客のガバナンス問題になる可能性があることを示しています。ベンダーの役割が継続性である場合、ベンダー自身の継続性制御は製品の一部です。
ステータス通知は依存関係と決定ポイントを特定すべき
ルーテッド緩和インシデント中、顧客は一般的な可用性通知以上のものを必要とします。影響を受けたサービスが Prolexic Routed か別の Akamai 機能か、問題がすべての顧客に影響するか一部か、攻撃緩和がまだアクティブか、バイパスが推奨されるかリスクがあるか、自動再ルーティングが行われているか、アプリケーションに到達できない場合に顧客が取るべきアクションを知る必要があります。
一般の人はインシデント初期の不確実性をある程度許容できます。使用できないのは、顧客にルート変更の推測を残すあいまいな安心感です。ステータス通知は進化すべきです。最初に影響を受けたサービスと症状を特定し、次にルートまたはスクラビング依存関係を特定し、トラフィックが自動または手動で再ルーティングされているかどうかを述べ、顧客エスカレーションのガイダンスを提供し、事後ノートを公開して何が変わったかを説明します。その進行により二次的な害が軽減されます。
Prolexic インシデントは、プロバイダーステータスと顧客ランブックが交差するケースです。顧客の保護サービスがダウンしている場合、プロバイダーの再ルーティングを待つか独自のフォールバックを起動するかを決定しなければなりません。プロバイダーはサービス側の障害の最良のビューを持っています。顧客はビジネス優先度とローカルアプリケーション影響の最良のビューを持っています。適切なステータス通知により、これらのビューが迅速に一致します。
コミュニケーションはまた過度に広範な主張を避けるべきです。Akamai はインシデントがシステムアップデートやサイバー攻撃ではないと述べました。その事実は、顧客が侵害対応ではなく運用ルーティング復旧に集中できるため重要でした。しかし顧客は依然として自分のサービスが影響を受けたかどうか、攻撃トラフィックが存在したかどうか、データの整合性や機密性が関与したかどうかを知る必要がありました。可用性インシデントは、顧客が少なすぎず多すぎず行動できるように正確に範囲設定されるべきです。
重要な公開サービスにとって、ステータス通知には社会的機能があります。銀行、政府ポータル、医療インターフェース、通信サービスは自分のユーザーに通知する必要があるかもしれません。アップストリーム緩和プロバイダーの説明が具体的でタイムリーであれば、ダウンストリーム組織は正確に通信できます。遅れたりあいまいな場合、ダウンストリーム通知もあいまいになります。コスト移転は、金銭的に移転する前に不確実性を通じて移動することがよくあります。
スクラビングサービスには障害ドメインの透明性が必要
DDoS スクラビングは意図的に抽象化されています。顧客はすべての攻撃シグネチャ、グローバルキャパシティプール、ピアリング関係、トンネル、緩和ルールを管理したくありません。プロバイダーサービスを購入するのは、プロバイダーが専門的な防御を大規模に運用できるからです。しかし抽象化は継続性に影響を与える障害ドメインを隠すべきではありません。顧客はプロバイダーパスのどの部分が失敗し、どのように対応できるかを理解する必要があります。
製品ドキュメントはこれを管理された用語で記述できます。常時オンとオンデマンドルーティング、BGP アナウンス責任、トンネルリターンパス、直接接続オプション、最大ルート規模、顧客プレフィックス衛生への依存、緊急バイパス手順、サポート連絡先を説明できます。トラフィックが最寄りのスクラビングセンターに自動再ルーティングされた場合に何が変わるかを説明できます。アクティブな攻撃中に危険な顧客アクションを説明できます。これには機密の緩和方法を明らかにする必要はありません。
障害ドメインの透明性は、セキュリティと可用性がトレードオフする場合に特に重要です。顧客は DDoS 耐性を最大化するがプロバイダー依存度を高める厳格な保護パスを選択するかもしれません。別の顧客はより速いバイパスと引き換えにオリジンの露出をより受け入れるかもしれません。これらはビジネス上の決定です。プロバイダーの証拠に基づいて情報を得るべきであり、障害中に発見されるべきではありません。
したがって 2021 年のインシデントは調達の教訓として使用されるべきです。ルーテッド DDoS 緩和の購入者は尋ねるべきです。スクラビングサービス自体にルーティング障害が発生したらどうなるか？ すべての保護プレフィックスに対して自動再ルーティングが有効か？ バイパスはどのように承認されるか？ どのくらいの頻度でテストされるか？ 顧客はルート状態を確認できるか？ どのようなステータス詳細が提供されるか？ トラフィックはどのくらい早く通常の保護に戻るか？ 保護パスが障害パスである場合、どのような契約上のコミットメントが適用されるか？
プロバイダーは強力な制御があればこれらの質問を歓迎すべきです。それらは痛みを伴うインシデントを明確な顧客設計に変換します。また、テストされたバイパス計画を持つ顧客はより良い情報を持って電話し、より安全な決定を下すため、次のイベント時の対応負担を軽減します。
残存する未知数と説明責任の問い
公開記録は Akamai が特定したルーティングテーブル値のすべての詳細を明らかにしていません。ダウンタイム、自動再ルーティング、手動介入、バイパス準備の顧客別マップを提供していません。すべての顧客が後日最寄りのスクラビングセンターへの自動再ルーティングを持っていたことを独立して検証していません。顧客、プロバイダー、アップストリームネットワーク間のすべての契約上の割り当てを示していません。これらの未知数は見えるままにすべきです。
既知のことは説明責任を定義するのに十分です。Akamai は Prolexic Routed 3.0 サービスを運営していました。サービスはルーテッドトラフィックパスを使用して顧客を DDoS 攻撃から保護しました。Akamai はルーティングテーブル値が誤って超過され、影響を受けた顧客が自動または手動でルーティングされたと述べました。外部測定は顧客への影響が異なり、バックアップ計画が重要であることを示しました。顧客とユーザーは保護依存関係が利用できなくなった結果を負いました。
説明責任の問いは、ルーテッド緩和がインシデント後により安全になったかどうかです。Akamai はルート状態制限が顧客障害にならないように検証を追加しましたか？ 自動再ルーティングは約束通りすべての顧客をカバーしましたか？ 顧客バイパス文書はより明確になりましたか？ ステータス通知は決定ポイントをより迅速に特定しましたか？ トラフィック戻し手順は改善されましたか？ 顧客はテスト証拠やアーキテクチャガイダンスを受け取りましたか？ サービスはプロバイダー側の障害条件下での手動介入を削減しましたか？
答えは証拠によって判断されるべきです。サービスが復旧したというプロバイダーの声明は始まりです。インシデント後の修復記録、顧客ランブック、テスト済みバイパスパス、その後のサービス動作が証明です。DDoS 緩和は敵対的な圧力下での継続性として販売されるため、プロバイダー自身のルート継続性は高い基準で保持されなければなりません。
最終的な教訓は、ルーテッド DDoS 緩和が悪いということではありません。委任された保護が委任された依存関係を生み出すということです。顧客は保護パスを必要としますが、防御システムが損なわれた場合に保護パスの周りの安全なルートも必要です。Akamai の Prolexic インシデントはその設計要件を可視化しました。説明責任の基準は、その可視性が一時的な障害の記憶ではなく、持続可能な顧客制御になったかどうかです。
プロバイダー側の容量制御には顧客に見える意味が必要
Akamai のフレーズ「ルーティングテーブル値」は必然的にコンパクトです。内部アーキテクチャを公開しておらず、会社の声明を超えて拡張すべきではありません。しかしコンパクトなフレーズでもガバナンス上の結果があります。顧客はプロバイダー側のルート状態が顧客向けの制限になり得ることを理解する必要があります。サービスを中断する方法で値が超過される可能性がある場合、その値の周りの検証は顧客の回復力モデルの一部です。
公開修復の問いは値のリテラル名ではありません。制御クラスです。値は監視されていましたか？ 顧客影響の前にアラートがありましたか？ 制限は成長と障害条件下でテストされましたか？ 安全でないルートプログラミングを防ぐガードレールがありましたか？ 値に近づいたときにフォールバックがありましたか？ 条件が別のスクラビングセンター、地域、顧客グループで再発する可能性がありましたか？ これらの質問は簡潔な声明を実用的な説明責任チェックリストに変えます。
顧客は機密実装を要求することなくこの情報を求めることができます。プロバイダーはルート状態のしきい値が監視されていること、リリースやルート変更が制限に対してテストされていること、自動再ルーティングが定義されたシナリオをカバーしていること、ランブックが手動例外をカバーしていること、顧客通知が決定ポイントを特定することを述べることができます。また、適切な機密性の下でエンタープライズ顧客により深い保証を提供することもできます。ポイントはシステムの公開露出ではなく、顧客に関連する保証です。
容量制御はまた DDoS 緊急事態の形状に対してテストされるべきです。攻撃トラフィックは突然のルートと緩和の変更を引き起こす可能性があります。顧客はストレス下でオンデマンド保護を起動するかもしれません。プロバイダーはスクラビングセンター間でトラフィックをシフトするかもしれません。穏やかなメンテナンスウィンドウ中に機能する同じ制御が、同時の顧客イベント中には異なる動作をするかもしれません。敵対的なトラフィック向けに構築されたサービスは、通常の運用だけでなく敵対的な条件下でルート状態を検証する必要があります。
Prolexic インシデントは、保護プロバイダーの内部制限がサービスを聞いたことのないエンドユーザーに感じられることを示しました。銀行や公開ポータルにアクセスしようとする人はサイトがダウンしていると見ます。顧客はサプライヤーインシデントを見ます。プロバイダーは内部ルーティング状態の問題を見ます。説明責任はこれらのビュー間を翻訳して、制限を制御する当事者が公開症状を軽減したことを証明する必要があります。
顧客は保護サービスをバイパスリスクで分類すべき
すべての保護サービスが同じようにバイパスすべきではありません。公開マーケティングサイト、支払い API、オンラインバンキングログイン、医療ポータル、SaaS コントロールプレーン、政府サービスは、DDoS 保護が削除された場合に異なる露出を持ちます。すべての保護プレフィックスを等しく扱うバイパスランブックは粗すぎます。顧客は保護サービスを、失敗した緩和パスに留まるリスクと保護を離れるリスクで分類すべきです。
リスクの低い情報サイトの場合、オリジンが通常のトラフィックを吸収できるならバイパスは迅速に許容されるかもしれません。リスクの高いトランザクションシステムの場合、バイパスにはアップストリームレート制限、オリジンアクセス変更、または地域トラフィックシェーピングが必要かもしれません。すでに攻撃下にあるサービスの場合、別の緩和パスが準備されていなければバイパスは危険かもしれません。規制対象サービスの場合、決定にはビジネス承認と公開通知が必要かもしれません。この分類はプロバイダーの障害前に行われるべきであり、その最中に行われるべきではありません。
プロバイダーはバイパス決定木を提供することで支援できます。その木は、顧客がアクティブな攻撃下にあるか、代替緩和が存在するか、DNS または BGP 変更がより速いか、オリジン容量が十分か、ファイアウォールルールが直接アクセスを許可するか、サポートが安全な戻しを支援できるかを尋ねることができます。そのようなガイダンスは顧客エンジニアリングの代わりにはなりません。時間的プレッシャーの下で顧客エンジニアリングを可能にします。
顧客はまた保護への復帰をテストすべきです。フェイルオーバーをテストしてフェイルバックを忘れることは一般的です。プロバイダーインシデントが解決した後、トラフィックはセッションを中断せず、ルート安定性を失わず、オリジンを露出させず、攻撃トラフィックを再導入せずにスクラビングサービスに戻らなければなりません。フェイルバックがリハーサルされていない場合、組織は保護の復旧を遅らせたり、第二の障害を引き起こしたりする可能性があります。完全なランブックはバイパスと復帰を一つのライフサイクルとしてカバーします。
したがって Prolexic 記録は影響を受けなかった顧客にも有用です。ルーテッド DDoS 緩和を使用する組織は、自分のバイパス分類が最新かどうかを尋ねることができます。机上訓練を実施できます。Akamai または別のプロバイダーがルーテッド緩和障害を報告し、自動再ルーティングが一部のプレフィックスでは機能するがすべてではない、公開ユーザーが失敗している、攻撃は見えない、最初の15分間に何をするか？ その答えは保護依存関係が管理されているかどうかを明らかにします。
マルチプロバイダー緩和はリスクを減らし複雑性を増す可能性がある
一部の顧客はルーテッド緩和インシデントに対応して複数の DDoS プロバイダーを検討します。それは単一プロバイダー依存を減らすことができますが、ルートポリシーの複雑性を導入することもあります。複数のプロバイダーは異なるプレフィックスアナウンスメント、トンネル、DNS 戦略、オリジン制限、ヘルスチェック、契約、サポート連絡先を必要とするかもしれません。適切に設計されていないマルチプロバイダー計画は、解決すべきだった同じ混乱を生み出す可能性があります。
正しい質問は単に「ベンダー数は？」ではありません。「どの障害ドメインが分離されているか？」です。2つのプロバイダーが同じアップストリームパス、同じ DNS 制御、同じオリジンボトルネック、同じ内部承認プロセスに依存している場合、実際の回復力の向上はベンダー数が示唆するよりも小さいかもしれません。顧客がストレス下で2番目のプロバイダーを運用できない場合、2番目のプロバイダーは継続性ではなく文書になるかもしれません。
プロバイダー多様性はまた攻撃処理を変えます。DDoS イベントは敵対的です。攻撃中に緩和プロバイダーを切り替えると、オリジンアドレスが露出し、フィルタリングコンテキストがリセットされ、ルール変換が必要になる可能性があります。顧客はどのプロバイダーが権限を持つか、トラフィックがどのようにシフトするか、誰がアップストリームと調整するか、テレメトリがどのように比較されるかを知っている必要があります。これらの詳細は即興するには重要すぎます。
それでも、設計されテストされていれば多様性は役立ちます。顧客はセカンダリスクラビングパス、機密性の低いトラフィック向けのクラウドベースフォールバック、または緊急 DNS 戦略を維持することができます。サービスを重要度で分割し、異なる緩和モデルを割り当てることができます。バイパス中のプロバイダー支援を契約することができます。Akamai のインシデントからの教訓は、すべての顧客が2つの完全なプロバイダーを必要とするということではありません。すべての顧客が意識的に選択された障害ドメイン戦略を必要とするということです。
ベンダーは、ルーテッドサービスがどのように失敗するか、顧客がどのように離脱して戻ることができるか、どの顧客所有コンポーネントが前提条件であるかについて透明性を持つことで、その戦略を支援できます。ベンダーがバイパスの議論に抵抗する場合、顧客に単一のパスを絶対的に信頼するよう求めます。Prolexic イベントは、単一の保護パスへの絶対的信頼が回復力計画ではないことを示しました。
保護契約には障害協力を含めるべき
DDoS 緩和契約は多くの場合、攻撃容量、応答時間、サービス可用性、サポート、価格に焦点を当てます。Prolexic インシデントは追加の質問を示唆します。契約は緩和ルートが損なわれた場合のプロバイダーの責任を定義していますか？ 利用可能な場合の自動再ルーティングを要求していますか？ 手動再ルーティングの優先順位を指定していますか？ プレフィックスデータ、トンネル設定、緊急連絡先、バイパス承認に関する顧客の義務を特定していますか？ インシデント後の証拠を含んでいますか？
契約条件はすべての運用問題を解決できませんが、準備を強制できます。契約が現在の緊急連絡先を要求する場合、両当事者はそれらを維持する理由があります。定期的なフェイルオーバーテストを要求する場合、バイパスが理論的になる可能性は低くなります。アクション可能な情報を含むステータス更新を要求する場合、顧客はダウンストリーム通信を計画できます。インシデント後のレビューを要求する場合、修復コミットメントは忘れられにくくなります。
契約はまたデータとテレメトリに対処すべきです。ルーテッド緩和障害中、顧客はトラフィックがいつ失敗したか、いつ再ルーティングされたか、どの地域またはプレフィックスが影響を受けたか、通常の保護がいつ再開されたかを示すログまたはレポートを必要とします。その証拠がなければ、顧客はイベントを自分のユーザー、監査人、規制当局に説明できません。プロバイダーテレメトリは顧客の説明責任の一部です。
公開向け重要なサービスの場合、契約協力には公開通信を含めるべきです。銀行、政府機関、医療サービスは、アップストリーム緩和プロバイダーが損なわれていることをユーザーに伝える必要があるかもしれません。プロバイダーの表現は誤情報を防ぐのに役立ちます。また、イベントがデータ侵害ではなく可用性とルーティングの問題であることを確認できます（それがサポートされる場合）。明確なサプライヤー言語は顧客の負担を軽減します。
広範な教訓は、委任された緩和は関係であり、ブラックボックスではないということです。プロバイダーは専門的な防御を制御します。顧客はサービスのミッションを所有します。プロバイダー側の障害時、これらの責任は交差します。適切な契約、ランブック、ステータス通知、テストにより、その交差は予測可能になります。それらがなければ、ベンダー環境内のルーティングテーブル値が明確な決定権のない公開障害になる可能性があります。
リターンパス証拠は緩和保証の一部であるべき
ルーテッド緩和には2つの公開面があります。スクラビングサービスへのパスと顧客への戻りのパスです。購入者は最初のものに焦点を当てることが多いのは、理解しやすいからです。攻撃トラフィックはプロバイダーの防御ネットワークに入り、プロバイダーがフィルタリングし、クリーントラフィックがオリジンに到達します。戻り側も同様に重要です。トンネル、直接接続、ルートプリファレンス、ファイアウォールルール、オリジン制限はすべて、保護されたユーザーが実際にサービスを受信するかどうかを決定します。
Prolexic インシデントはリターンパス証拠を保証の一部にします。プロバイダーがトラフィックを自動または手動で再ルーティングする場合、顧客はリターンパスが有効か、トンネルが健全か、オリジン許可リストがまだ一致しているか、フェイルバックが保護を維持するかを知る必要があります。ルーテッドサービスはプロバイダーレベルで技術的に復元されても、顧客側に不一致がある場合があります。その不一致は継続的なプロバイダー障害、顧客の設定ミス、または部分的な復旧問題のように見える可能性があります。
したがって顧客はオンボーディング時にルートおよびリターンパスのテストケースを要求すべきです。最初のテストは通常の保護運用を証明すべきです。2番目はプロバイダー側の再ルーティングを証明すべきです。3番目は顧客承認のバイパスを証明すべきです。4番目は保護への安全な復帰を証明すべきです。5番目は通信を証明すべきです。誰がアラートを受信するか、何を言うか、どのような行動が期待されるか。制御された演習でトラフィックを一度も移動したことのない計画は、信頼できるバイパス計画ではありません。
Akamai の声明（トラフィックが自動または手動でルーティングされた）は有用な出発点を提供しますが、顧客はローカルな証拠を必要とします。自分の保護プレフィックスは自動再ルーティングに参加しましたか？ アプリケーションは手動サポートを必要としましたか？ ログはルート変更がいつ発生したかを示していますか？ プロバイダーステータスが復旧と言ったときにユーザーは復旧しましたか？ 顧客はオリジン制御を変更する必要がありましたか？ これらの質問は公開記録を超えて推測することなく、プロバイダーインシデントをアクション可能にします。
リターンパス保証は小規模組織にも重要です。大企業は BGP、GRE、ファイアウォール状態を検査できるネットワークチームを持つかもしれません。小規模な顧客はサイトがダウンしていることだけを知っているかもしれません。プロバイダーのダッシュボード、平易な言語のステータス、アカウントチームのランブックがそのギャップを埋めることができます。プロバイダーが高度なネットワークスタッフのいない組織に高度な緩和を販売する場合、復旧状態を理解できるようにすべきです。
説明責任の基準は、保護が安全に離脱および再入できるという証拠です。DDoS 緩和は、障害決定がどちらにしてもセキュリティ結果を持つため、異例です。失敗したパスに留まるとサービスが拒否される可能性があります。パスを離れるとオリジンが露出する可能性があります。検証なしに戻りすぎたり早すぎたりするとリスクが再導入される可能性があります。だからこそルーテッド緩和保証には、トラフィック進入、トラフィック戻し、バイパス、フェイルバックの証明を1つの制御ファミリーとして含めるべきです。
顧客通信は障害と攻撃を区別すべき
DDoS 保護の顧客は、緩和サービス近くの可用性問題は攻撃であると合理的に想定するかもしれません。Akamai の更新は Prolexic Routed インシデントがサイバー攻撃によるものではないと述べました。その区別は運用上価値があります。顧客が障害が攻撃によるものと信じる場合、バイパスを避け、制御を強化し、危機通信を起動し、セキュリティリーダーシップにエスカレートするかもしれません。プロバイダーが内部ルーティングサービス問題を確認できる場合、顧客の決定パスが変わります。
プロバイダーは証拠がサポートする場合、その区別を迅速に行うべきです。「調査中」は初期に適切です。一度判明すれば、「これはサービスのルーティング問題であり、お客様のオリジンに対する攻撃トラフィックは観測されていません」または「攻撃ステータスは引き続きレビュー中です」は顧客により良い行動基盤を提供します。通信はまた、顧客がルート変更を控えるべきか、バイパスを準備すべきか、手動再ルーティングのためにサポートに連絡すべきかを述べるべきです。
ここでステータス通知は共有制御文書になります。プロバイダーはサービス状態を知っています。顧客はビジネス重要度を知っています。両者には共通言語が必要です。プロバイダーの通知が技術的すぎると、ビジネスチームは行動しないかもしれません。あまりにあいまいだと、ネットワークチームは推測するかもしれません。適切な通知は、影響を受けた製品、顧客症状、既知の原因カテゴリ、推奨アクション、次の更新時間を特定します。
ダウンストリームユーザーはその明確さから利益を得ます。銀行、SaaS 企業、公共機関は、ユーザーに侵害やアプリケーション欠陥を暗示するのではなく、アップストリームの DDoS 緩和プロバイダーが可用性問題を経験していることを伝えることができます。正確な表現は噂、サポート負荷、不必要なセキュリティパニックを減らします。また、プロバイダーが証拠によってサポートされていない害の非難を回避しつつ、制御するサービス依存関係を所有するのに役立ちます。