要約

  • Google Cloud の2024年の UniSuper インシデントは、クラウド制御の説明責任を可視化した。プロバイダ側の事象が大手金融サービス顧客に影響を与え、通常の顧客管理によるリージョン冗長化では十分に説明できない形で混乱を引き起こしたからである。
  • 公開記録は、データ窃取ではなく、プライベートクラウドの削除と復旧の問題に焦点を当てている。この区別は重要である。なぜなら、説明責任の証拠は、敵対者の特定ではなく、管理上の安全策、バックアップの独立性、復旧の証拠、加入者向けコミュニケーションに関わるからである。
  • UniSuper の復旧は、障害が発生した環境外のバックアップと復旧能力に依存していた。したがって、本事例は、クラウド購入者が、主要テナント環境を削除、停止、失効、または無効化する可能性のある同一のコントロールプレーンからの分離を証明できるかどうかを問うものである。
  • 防御可能なクラウド継続性レビューでは、プロバイダ制御、顧客アーキテクチャ、独立したバックアップ、復旧順序、加入者向けコミュニケーション、および規制当局向けのオペレーショナルリスク証拠を区別すべきである。

クラウドテナントはリージョン障害に耐性があっても、コントロールプレーンの削除に対して無防備であり得る

Google Cloud と UniSuper のインシデントが重要なのは、多くの購入者がクラウドの回復力について考える通常の枠組みを横断するからである。クラウドアーキテクチャの議論は、リージョン、ゾーン、レプリケーション、ストレージの永続性、災害復旧、サービスレベル目標から始まることが多い。これらの管理策は不可欠である。しかし、障害がリソース層より上で発生した場合、それらは不完全でもある。リージョンディスク障害、ネットワーク分断、データセンター停止は、プロバイダ側の管理アクションが顧客環境を削除または無効化する場合とは異なる。前者の問題群はインフラの冗長性を試す。後者は、削除防止策、ID 権限、アカウントライフサイクル管理、コントロールプレーンから独立したバックアップを試す。

Google Cloud の公式公開説明（https://cloud.google.com/blog/products/infrastructure/details-of-google-cloud-gcve-incident）では、Google Cloud VMware Engine を使用する1社の顧客に影響を与えた最近のインシデントが説明された。同説明によれば、混乱はサイバー攻撃によるものではなく、Google Cloud 全体のサービス障害でもなかった。プロビジョニング中の不注意な誤設定が UniSuper のプライベートクラウドサブスクリプションの削除を引き起こし、復旧作業が必要になったとされている。UniSuper と Google Cloud は、顧客向け共同声明（https://www.unisuper.com.au/news-and-insights/a-joint-statement-from-unisuper-and-google-cloud）も発表し、UniSuper は加入者向けの障害情報更新ページ（https://www.unisuper.com.au/contact-us/outage-update）を維持した。これらの情報源が、本事例の公開された背骨である。

説明責任の問題は、非公開の根本原因の詳細すべてが見えているかどうかではない。公開記録から、管理クラスを特定するのに十分な情報が見えることである。ある顧客が、単に機能へのアクセスを失っただけではない。大手金融サービス事業者が、プロバイダ側の事象がプライベートクラウド環境に影響を与えた後に混乱を経験した。これにより、レビューの焦点は、一般的な稼働時間から、削除を可能にした管理条件、それを検出できる者、停止できる者、そこから復旧できる者、復旧が不完全な間それを加入者に説明できる者へと移る。

この違いは重要である。なぜなら、クラウド購入者はしばしば、プロバイダ管理サービスを運用負荷の軽減とみなすからである。確かに一部の負荷は軽減される。顧客はもはやすべてのハードウェア障害、ハイパーバイザーパッチ、施設イベント、キャパシティ運用を所有しない。しかし、購入者は異なる証拠問題を引き受ける。すなわち、プロバイダのコントロールプレーンに関する最も重要な事実は、顧客の通常の監視の内側からは見えない可能性がある。プロバイダ側の管理プロセスがテナントに影響を与え得る場合、顧客のローカルな回復力設計は、プロバイダ側の条件を生き延びる証拠とバックアップを含まなければならない。

このインシデントは、「バックアップ」という言葉が粗すぎる理由も示している。同じ環境に保存され、同じサブスクリプションに支配され、同じライフサイクル管理に曝され、同じ削除パスに依存するバックアップは、この障害クラスに対して十分に独立していない可能性がある。主要なプライベートクラウド環境が削除されても、論理的かつ管理的に分離されていることで生き残るバックアップは、異なる説明責任上の価値を持つ。UniSuper を巡る公開記録は、読者を繰り返しその分離問題に立ち返らせる。つまり、主要なプライベートクラウド環境が削除または利用不可になった後でも、復旧用素材が利用可能であったことを証明する証拠は何か、という問題である。

取締役会にとっての教訓は直接的である。ワークロードが複数のゾーンにあると言うクラウドの回復力に関する説明は、プロバイダ側のテナント削除が環境全体を無効化できるかどうかに答えない。データがバックアップされていると言う説明は、それらのバックアップが影響を受ける管理境界の外にあるかどうかに答えない。プロバイダがサービスを復旧したと言う説明は、加入者がどのくらい影響を受けたか、どのような手動の回避策が必要だったか、どのような調整が後続したか、再発防止のためにどのような管理策が変更されたかには答えない。説明責任には、単なるインフラ図ではなく、コントロールプレーンマップが必要である。

プロバイダ制御と顧客アーキテクチャは異なる証拠レーンである

この公開事例は、二つの別個の証拠レーンで読むべきである。第一のレーンはプロバイダ制御である。Google Cloud は、管理対象サービス、内部プロビジョニングプロセス、削除防止策、復旧サポート、およびプロバイダ側障害の公開説明を管理していた。第二のレーンは顧客アーキテクチャである。UniSuper は、事業継続性の期待、加入者コミュニケーション、バックアップ戦略、運用上の依存関係、および重要なワークロードに管理対象プライベートクラウドサービスを使用するという決定を管理していた。両方のレーンが重要である。これらを一つの非難物語にまとめてしまうと、より弱い説明になる。

Google Cloud VMware Engine は、顧客が Google Cloud インフラ上で VMware ワークロードを実行できるようにする管理対象サービスである。概要ドキュメント（https://cloud.google.com/vmware-engine/docs/concepts/overview）はサービスコンセプトを説明している。プライベートクラウドドキュメント（https://cloud.google.com/vmware-engine/docs/concepts/private-clouds）は顧客が使用するプライベートクラウドオブジェクトについて説明している。ロケーションドキュメント（https://cloud.google.com/vmware-engine/docs/concepts/locations）とネットワーキングドキュメント（https://cloud.google.com/vmware-engine/docs/concepts/networking）は、このサービスが単なる計算容量ではない理由を示している。それは、配置、接続性、管理、運用境界を伴う環境である。これらのドキュメントはインシデント調査結果ではない。インシデント記録で公に議論された種類のオブジェクトについて説明している。

その区別が重要なのは、プライベートクラウドサービスがオブジェクトストレージや単一の仮想マシンとは異なる説明責任プロファイルを持つからである。顧客はその周囲に複数のワークロード、ネットワークパス、ID 依存関係、運用プロセスを構築する可能性がある。プライベートクラウド環境が削除または利用不可になると、影響は単一のアプリケーションクラッシュよりも広範になり得る。復旧には、管理アクセスの回復、コアインフラの復元、データ検証、依存アプリケーションの再起動、トランザクションの調整、加入者サービスの再開、残余の制限の説明という順序付けが必要になる場合がある。

プロバイダ制御が関与するのは、このインシデントが顧客による誤ったボタンクリックとして説明されたわけではないからである。Google Cloud の公開説明は、重要な開始事象をプロバイダのプロビジョニングと削除の動作に位置付けた。これは、通常の責任共有の用語が注意深く適用されなければならないことを意味する。責任共有は視認性の共有を意味しない。プロバイダは混乱を引き起こした事象を管理している可能性がある。顧客は独立した復旧証拠が存在するかどうかを管理している可能性がある。顧客は公的信用への影響を被る可能性がある。プロバイダは、なぜ安全策が失敗したのかを正確に説明できる唯一の当事者である可能性がある。

顧客アーキテクチャが関与するのは、顧客の継続性設計の準備ができていなければ、プロバイダがインフラだけから顧客のビジネスコンテキストを復旧できないからである。アーキテクチャは、重要なワークロード、復旧時間の期待値、復旧ポイントの期待値、データ依存性、ID 依存性、ネットワーク依存性、手動の運用手順を特定しなければならない。主要サービスに影響を与えるのと同じ条件によって消去されないバックアップコピーと復旧手順を保存しなければならない。どのレイヤーが故障したかに関心がない加入者やスタッフのためのコミュニケーションを準備しなければならない。彼らが関心を持つのは、アカウントにアクセスできるか、フォームを提出できるか、意思決定できるか、記録を信頼できるかである。

したがって、このインシデントはプロバイダと顧客の証拠の関係を試すものである。Google Cloud は、顧客に固有の非公開記録を誇張しない形でプロバイダ側の障害を説明しなければならなかった。UniSuper は、技術的な復旧を曖昧な保証に変えない形で、加入者への影響を説明しなければならなかった。共同声明が重要だったのは、共有された公開説明を提供したからであるが、共同声明は依然として証拠ファイルの一部に過ぎない。完全なレビューには、内部ログ、プロビジョニング記録、削除防止策、バックアップ復旧テスト、事業継続性の決定、加入者連絡記録、インシデント後の管理策変更が含まれるであろう。

バックアップは、それが生き残ることを意図された障害から独立していなければならない

UniSuper インシデントからの最も永続的な教訓は、バックアップの独立性である。多くの組織は、バックアップがあると言う。しかし、主要環境をダウンさせた管理上の障害からバックアップが独立していることを証明できる組織はより少ない。独立性にはいくつかの次元がある。バックアップは、主要環境の削除がコピーを消去しないほど十分に論理的に分離されているべきである。同じアカウントライフサイクルイベントが復旧権限を無効にしないほど十分に管理的に分離されているべきである。インシデント中に到達可能であり続けるほど十分に地理的および運用的に分離されているべきである。復旧が即興にならないほど十分に頻繁にテストされているべきである。

Google Cloud のストレージ永続性と可用性に関するドキュメント（https://cloud.google.com/storage/docs/availability-durability）は、異なるサービス層のストレージ回復力の概念を説明している。一方、ソフトデリートに関するドキュメント（https://cloud.google.com/storage/docs/soft-delete）と保持管理に関するドキュメント（https://cloud.google.com/storage/docs/bucket-lock）は、ストレージの文脈における一部の削除および保持の失敗から保護できる管理策を説明している。これらは UniSuper プライベートクラウドインシデントに関する直接的な調査結果ではない。これらが有用なのは、永続性、保持、削除ウィンドウ、データの生存とサービス継続性の違いという、より広範なクラウド管理の語彙を示しているからである。

その語彙は正確に使用されなければならない。永続的ストレージは、回復可能なビジネスサービスと同じではない。保持されたオブジェクトは、機能するアプリケーションと同じではない。レプリカが同じ管理アクションによって削除される可能性がある場合、複製されたコピーは独立したバックアップと同じではない。組織が ID、ネットワーク、アプリケーション設定、運用手順を復旧できない場合、バックアップは十分ではない。UniSuper の事例が重要なのは、復旧の事実に公の注目が集まったからであるが、説明責任上の問いは、復旧を可能にした分離の種類と、その分離が将来のクラウド設計でどのようにテストされるべきかということである。

Google Cloud アーキテクチャフレームワークの信頼性に関する資料（https://cloud.google.com/architecture/framework/reliability）と運用上の卓越性に関する資料（https://cloud.google.com/architecture/framework/operational-excellence）は、回復力を事後的な謝罪ではなく、設計された運用慣行として位置付けているため、ここで役立つ。災害復旧ガイダンス（https://cloud.google.com/architecture/disaster-recovery）とシナリオ計画ガイダンス（https://cloud.google.com/architecture/dr-scenarios-planning-guide）は、顧客に計画のための語彙を提供する。これらの情報源は、UniSuper がインシデント前に何を設定したかを証明するものではない。これらは、クラウド購入者が今、より高い規律をもって問うべきことを示している。

金融サービス事業者は、このインシデント後にいくつかのバックアップに関する質問に答えられるべきである。どのワークロードが影響を受けたプライベートクラウドに依存していたか？どのデータセットが影響を受けた環境の外にバックアップされていたか？主要クラウドテナントが利用不能の場合に、誰がそれらを復旧するための資格情報と権限を持っていたか？バックアップは不変、保持、テスト、文書化されていたか？復旧パスは同じコントロールプレーンなしで実行できたか？インシデント前の最後の正常な復旧テストはいつだったか？どの復旧ステップがプロバイダのサポートに依存していたか？どのステップが UniSuper のスタッフまたは第三者に依存していたか？どの加入者サービスが最初に優先され、なぜか？

プロバイダは、異なるが関連する一連の質問に答えられるべきである。プライベートクラウドサブスクリプションにはどのような削除または失効の安全策が存在したか？この特定のケースではどの安全策が失敗したか、または迂回されたか？プロバイダ側のプロビジョニングの誤設定がどのように削除につながる可能性があるか？再発を防ぐために現在どのような追加の管理策が導入されているか？顧客の被害が可視化される前に、プロバイダはどのように偶発的な削除を検出するか？プライベートインフラの詳細を暴露せずに、そのような事象の後にどのような顧客可視の証拠が提供できるか？公開ブログはその回答を開始できるが、完全な管理ファイルは正式なインシデント後ガバナンスに属する。

加入者コミュニケーションは復旧証拠の一部である

UniSuper の影響を受けたオーディエンスは、狭いエンジニアリングチームではなかった。それは、アクセス、信頼、タイムリーなコミュニケーションを必要とする加入者を持つ年金基金であった。このため、加入者コミュニケーションは説明責任記録の一部となる。クラウドプロバイダは復旧のメカニズムに焦点を当てるかもしれない。金融サービス顧客は、運用継続性と信頼に焦点を当てなければならない。加入者は、完全なプライベートクラウドアーキテクチャの講義を必要としない。彼らが知る必要があるのは、データが安全かどうか、トランザクションと口座記録が無傷かどうか、どのサービスが利用不可か、サービスがいつ復旧すると予想されるか、そして取るべき、または取るべきでないアクションである。

したがって、UniSuper の障害更新ページ（https://www.unisuper.com.au/contact-us/outage-update）は、広報の残滓ではなく証拠である。これは、顧客が影響を受けた人々に対して影響と復旧をどのようにフレーム化したかを示している。共同声明（https://www.unisuper.com.au/news-and-insights/a-joint-statement-from-unisuper-and-google-cloud）も証拠である。なぜなら、プロバイダと顧客が公開説明においてどのように連携したかを示しているからである。これらのページはすべての非公開の復旧ステップを証明できないが、影響を受けた加入者に何が伝えられたかを示している。

コミュニケーションに関する説明責任の基準には四つの部分がある。第一に、噂や不確実性を減らすのに十分な迅速さでなければならない。第二に、行動を導くのに十分具体的でなければならない。第三に、技術的な専門用語の背後に隠れることなく、不確実性を保持しなければならない。第四に、復旧の主張を加入者に関連する結果に結びつけなければならない。「システムを復旧中」は、「加入者は口座残高にアクセスし、フォームを提出し、サポートを受け、記録に依存できるようになった」と同じではない。金融サービスのインシデントは、サーバーが起動した時点で完全に復旧したわけではない。加入者向け機能、調整、管理策、信頼が許容可能な状態に回復した時点で復旧したのである。

コミュニケーションはプロバイダも保護する。Google Cloud と UniSuper が公開声明を共有することで、各当事者が事象の異なるバージョンを提示するリスクが減少する。しかし、連携は曖昧さになってはならない。共同声明は依然として、プロバイダ側の障害、顧客側の復旧設計、加入者への影響、将来の管理策変更を区別すべきである。公開説明がサイバー攻撃ではなかったと述べていれば、それは誤った侵害の物語を防ぐ助けとなる。バックアップが復旧を支えたと述べていれば、データ損失がケースを定義しなかった理由を説明する助けとなる。プロバイダが管理策を変更したと述べていれば、修復を示す助けとなる。各主張は、適切な証拠レーンの中に位置すべきである。

同じ原則が規制当局、監査人、取締役会にも適用される。取締役会資料は、単にメディア記事とプロバイダのノートを添付するべきではない。インシデントを管理策に翻訳すべきである。すなわち、削除防止策、バックアップの独立性、復旧テスト、コミュニケーションのタイミング、加入者サービスの優先順位、サードパーティ依存性、残余リスクである。また、公開記録が不完全な箇所を特定すべきである。例えば、公開情報源は、削除のための正確な内部承認フロー、正確なバックアップトポロジ、影響を受けた正確なアプリケーションリスト、復旧の詳細なコストを開示しない可能性がある。成熟したレビューはこれらの事実を捏造しない。それらが必要な内部証拠であることを記録する。

これが、UniSuper インシデントがクラウド説明責任シリーズに属する理由である。このインシデントは、顧客が深刻な継続性管理策を持っている場合でも、プロバイダに高度に依存し得ることを示している。また、プロバイダ側の障害を、自身の継続性設計に対する責任を放棄することなく説明する顧客の能力に、加入者の信頼が依存することを示している。加入者はクラウドプロバイダと直接契約しない。加入者はファンドに依存している。これはプロバイダを免責しない。それは説明責任の連鎖を明確にする。

金融サービスの継続性は証明の基準を引き上げる

UniSuper は、オペレーショナルリスク、情報セキュリティ、継続性、アウトソーシング、加入者の信頼が任意のガバナンストピックではないセクターで事業を展開している。オーストラリア健全性規制庁（APRA）の情報セキュリティ基準ページ（https://www.apra.gov.au/cps-234-information-security）とオペレーショナルリスク基準ページ（https://www.apra.gov.au/cps-230-operational-risk-management）は、規制対象事業体に対する情報セキュリティとオペレーショナルリスクに関する規制上の文言を示しているため、有用な文脈である。これらはインシデント調査結果ではない。重要な業務、サードパーティ依存性、情報セキュリティ管理策は証拠をもって統治されるべきであるという期待を提供している。

この関連性はオーストラリアに限定されない。すべての法域のクラウド購入者が同様の管理パターンに直面する。重要なサービスがマネージドプロバイダに依存している。プロバイダはインフラと管理ツールを制御する。顧客は事業継続性、データガバナンス、顧客コミュニケーション、ベンダーリスクを管理する。規制当局は、顧客がその依存関係を管理できるかどうかを問う。公衆は、依存関係が失敗したときに顧客が信頼を維持できるかどうかを問う。プロバイダは顧客に運命共有の保証を信頼するよう求める。インシデントは、それらの言葉が証拠によって裏付けられているかどうかを試す。

Google Cloud の責任共有と運命共有に関する資料（https://cloud.google.com/docs/security/shared-responsibility-shared-fate）は、もう一つの文脈レイヤーを提供する。責任共有はしばしば、誰が何をセキュアにするかの表と誤解される。運命共有は、顧客の結果におけるプロバイダの支援を強調することによってさらに踏み込む。UniSuper インシデントは、その語彙にとって厳しい事例である。なぜなら、開始された障害はプロバイダ側と公的に説明され、一方で復旧は顧客側のバックアップと復旧設計に依存したからである。運命共有が何か運用上の意味を持つならば、それは、プロバイダが単に職務の分割を指摘するのではなく、顧客の復旧、コミュニケーション、学習、再発防止を支援することを意味するはずである。

金融サービスの継続性は、復旧証拠の許容基準も変える。小さな内部ツールは曖昧な復旧ストーリーを許容するかもしれない。加入者にサービスを提供するファンドは、より強力な記録を必要とする。加入者データが無傷であったかどうか、給付計算やトランザクションが影響を受けたかどうか、サービスウィンドウが逃されたかどうか、カスタマーサポートが圧倒されたかどうか、代替サービスチャネルが機能したかどうか、監査証跡が完全なままであったかどうか、復旧後に調整が必要であったかどうかを示す必要がある。これらは顧客側の証拠質問であるが、それらはプロバイダ側のクラウド事象のために生じる。

公開記録は、規制違反、法的損害賠償の配分、最終的な過失割合を確定するものではない。本稿はこれらの主張を一切行わない。この記録は、深刻な運用上の依存関係と可視的なプロバイダ-顧客の復旧を確定する。これは、取締役会レベルの説明責任レビューを正当化するのに十分である。レビューが慎重であるべき理由は、まさにこのインシデントが公になったからである。公の注目は組織を過度に単純化された教訓へと追いやる可能性がある。すなわち、クラウドを使うな、もっとクラウドを使え、マルチクラウドを使え、バックアップを信頼せよ、などである。より良い教訓はより正確である。すなわち、環境を削除または無効化できるコントロールプレーンを知り、その境界の外に復旧用素材を保持し、プロバイダ側の障害の仮定の下で復旧をテストし、加入者コミュニケーションを継続性計画の一部とせよ、である。

マルチクラウドの教訓もまた、しばしば誇張される。複数のプロバイダを使用することは、アーキテクチャが真に分離可能であり、データガバナンスが健全であり、復旧パスがテストされており、スタッフがストレス下で両方の環境を運用できる場合には、回復力を向上させることができる。また、複雑さ、コスト、アイデンティティの拡散、監視のギャップ、不明確な所有権を追加する可能性もある。UniSuper の事例は、普遍的なマルチクラウドの義務を証明するものではない。これは、バックアップの独立性と回復可能性を、それが生き残ることを意図された特定の障害に対して評価しなければならないことを証明している。

より良い証拠は削除防止と復旧証明を示すであろう

UniSuper インシデント後のより強力な証拠設計は、四つのファイルを連携させることであろう。第一のファイルはプロバイダ管理ファイルである。プロビジョニング記録、削除防止策、例外処理、監視、内部承認、管理策変更、再発が阻止されたことの証拠である。第二のファイルは顧客アーキテクチャファイルである。ワークロードインベントリ、依存関係マップ、バックアップトポロジ、復旧時間目標、復旧ポイント目標、ID およびネットワーク依存性、テストされた復旧手順である。第三のファイルは復旧ファイルである。タイムスタンプ、復旧順序、データ検証、加入者サービス復旧、バックログ解消、調整、残りの例外である。第四のファイルはコミュニケーションファイルである。加入者への更新、規制当局への更新、取締役会報告、サポートスクリプト、公開声明である。

これらのファイルは、あまりにも早く単一の物語に統合されるべきではない。プロバイダが修正されたプロビジョニング管理の強力な証拠を持つ一方で、顧客はまだ未解決の調整タスクを抱えている可能性がある。顧客はサービスを復旧する一方で、プロバイダの根本原因レビューは未完了のままである可能性がある。加入者は、すべてのインシデント後保証作業が完了する前にアクセスを回復するかもしれない。各声明は、自身のレーンにおいて真であり得る。一つの真の声明が別のレーンの完了を示唆するために使用される場合に、説明責任は失敗する。

公開記事は、機密性の高い非公開素材を開示する必要はない。存在すべき証拠の構造を示す必要がある。削除防止策が失敗した場合、修復は安全策のクラスとそれがどのように変更されたかを特定すべきである。バックアップが復旧を可能にした場合、レビューはバックアップを十分に独立させたものを特定すべきである。加入者サービスが段階的に復旧した場合、レビューはどのサービスが最初に戻り、なぜかを特定すべきである。データ損失が発生しなかった場合、レビューはその主張を裏付ける検証を特定すべきである。インシデントがサイバー攻撃ではなかった場合、レビューはそれでも、偶発的な管理上の削除が敵対者による停止と同じ重大性をもって統治されているかどうかを検討すべきである。

公開クラウドアーキテクチャガイダンスの役割は、次のインシデントの前に購入者に語彙を与えることである。信頼性フレームワークの資料、災害復旧計画、ストレージ保持管理、プライベートクラウドドキュメント、運命共有の文言はすべて、購入者がより良い質問をするのを助ける。しかし、ガイダンスは実装の証拠ではない。取締役会は、クラウドのベストプラクティスを列挙したスライドを受け入れるべきではない。ただし、それらのプラクティスがどこで実装され、テストされ、所有され、レビューされているかが示されていない限りは。UniSuper インシデントは、アーキテクチャを証拠システムではなく図表として扱うことのコストを示している。

同じ教訓がベンダーリスク管理にも当てはまる。デューデリジェンスは、プロバイダが認証、成熟したセキュリティプログラム、公開された信頼性のコミットメントを持っているかどうかだけを問うべきではない。管理対象環境の偶発的な削除をどのように防止するか、プロバイダ側のコントロールプレーン異常をどのように検出するか、顧客にどのように通知するか、プロバイダと顧客のチームがどのように復旧を調整するか、そして事後にどのような証拠が利用可能かを問うべきである。重要な金融サービスワークロードについては、回答は規制当局のレビューと加入者コミュニケーションを裏付けるのに十分具体的であるべきである。

これは抑制された結論である。なぜなら、公開記録には境界があるからである。我々は、すべての内部ログ、契約条項、復旧ステップ、規制当局とのコミュニケーションを持っているわけではない。我々は、説明責任の枠組みを特定するのに十分な公開証拠を持っている。すなわち、プロバイダ側のコントロールプレーンの障害、顧客の継続性依存、独立した復旧素材、加入者向けコミュニケーション、検証可能な削除および復旧管理の必要性である。この枠組みは、大まかなクラウドリスクのスローガンよりも有用である。

削除防止は管理上の安全制御である

UniSuper の事例は、削除防止が単なる管理上の利便性ではなく、安全制御として扱われるべき理由も示している。成熟したクラウド環境では、削除権限は、通常のビジネス管理策が反応できるよりも速く運用面を除去できるため、強力である。リスクは悪意のある削除に限定されない。誤ったプロビジョニング、期限切れのコミットメント、不正確なライフサイクル設定、誤ったアカウントマッピング、自動化の欠陥、不完全な情報の下で取られたサポートアクションが含まれる。重要なテナント環境の偶発的な削除を防止する管理策は、アクセス制御、変更承認、特権アクションのログ記録、災害復旧と同じガバナンスの会話に属する。

その枠組みは、購入者が問うべき質問を変える。プロバイダがバックアップを持っているかどうか、またはプラットフォームが一般的に信頼できるかどうかを尋ねるだけでは不十分である。購入者は、重要な環境の削除が独立した確認を必要とするかどうか、削除要求が遅延可能または可逆的かどうか、プロバイダが開始する削除が顧客が開始する削除とは異なる承認パスを持つかどうか、期限切れのサービスオブジェクトが環境の除去に連鎖する可能性があるかどうか、環境を回復不能にする可能性のある管理状態について顧客が事前通知を受け取るかどうかを尋ねるべきである。これらの管理策の一部は、技術的に困難であるか、サービス固有であるかもしれない。だからこそ、それらは明示的である必要がある。

プロバイダは検出管理も必要とする。防止は決して完璧ではない。削除または破壊的な管理上の移行は、顧客がユーザーからの苦情を通じて問題を発見する前に、信頼性の高いアラート、内部エスカレーション、顧客向け調査を生成すべきである。アラートは、重要なオブジェクト、例えばプライベートクラウド環境、サービスサブスクリプション、バックアップリポジトリ、ID バインディング、ネットワーク接続、管理プレーンに結び付けられるべきである。プロバイダが削除が伝播した後にサービスが利用不可であることしか検出できない場合、管理策は遅すぎる。不可逆的な影響の前に管理アクションを検出できれば、顧客はビジネスインシデントを回避する機会を得る。

証拠が重要なのは、管理策が書面上は強力に見えることがあるからである。ポリシーは重要な削除が制限されていると述べるかもしれない。ワークフローはレビューが必要であると述べるかもしれない。ダッシュボードは成功したバックアップを示すかもしれない。しかし、取締役会レベルの質問は、それらの管理策が正確な障害パスに対して有効であったかどうかである。プロバイダのプロビジョニングシステムは、空白、期限切れ、または不正確なパラメータを環境を除去する権限として扱ったのか？安全策は、削除前に顧客 ID、サブスクリプション状態、プライベートクラウドオブジェクト、依存関係マップをチェックしたのか？プロバイダは一時停止または検疫状態を持っていたのか？顧客は警告を受け取ったのか？ログは連鎖を再構築するのに十分な詳細を保存したのか？

顧客は、この規律を内部的にも反映すべきである。クラウドの管理アクションをビジネス影響によって分類すべきである。どのプロバイダ側の変更が内部レビューを必要とするか、どの連絡先が緊急復旧を承認する権限を持つか、どのバックアップが管理上の到達範囲外にあるか、どの管理資格情報がプロバイダ側の障害のために保持されるかを知っておくべきである。管理サービスが、プロバイダが常にすべての復旧キーを保持することを意味すると想定すべきではない。顧客は、プロバイダの復旧を可能にするために自身の証拠パッケージを必要とするかもしれない。

削除管理のレンズは、このインシデントが通常の災害復旧に矮小化されるべきでない理由も明確にする。災害復旧はしばしば、インフラ損失、リージョン損失、アプリケーション障害を中心に枠組み化される。プロバイダ側の削除は異なるシナリオである。なぜなら、顧客は通常復旧を実行する環境そのものを失う可能性があるからである。影響を受けた環境にログインすることから始まる復旧計画は失敗する可能性がある。影響を受けた環境に保存されたバックアップカタログは到達不能かもしれない。同じ ID システムの背後に保存されたドキュメントは利用不可かもしれない。実践的な質問は、復旧指示、資格情報、連絡先、バックアップインベントリ、検証ステップが、故障した管理境界の外で生き残るかどうかである。

復旧リハーサルはプロバイダ側の障害の仮定を含めるべきである

クラウド復旧テストはしばしば、馴染みのあるシナリオをリハーサルする。アプリケーションがクラッシュする、ゾーンが故障する、データベースが復元される、リージョンが利用不能になる、デプロイメントがロールバックされる。これらのテストは価値があるが、UniSuper インシデントは、より不快な演習の必要性を示している。すなわち、プロバイダのコントロールプレーンが主要な管理環境を、顧客が単独では修正できない方法で利用不能にしたという演習である。そのシナリオでは、復旧は技術的であるだけではない。それは、プロバイダのエンジニア、顧客の運用担当者、経営幹部、サポートチーム、コミュニケーションスタッフ、そして場合によっては規制当局の間の調整問題である。

現実的なリハーサルは、通常のアクセスの喪失から始めるべきである。影響を受けたクラウド環境が利用不能な場合、顧客はドキュメント、バックアップマニフェスト、連絡先リスト、アーキテクチャ図に到達できるか？どのデータセットとアプリケーションが重要かを証明できるか？どのプロバイダサポートチャネルがプライベートクラウド削除をエスカレーションする権限を持つかを知っているか？緊急連絡先は最新か？トレードオフが生じた場合に復旧の選択を承認できる者の記録があるか？これらの質問は管理的に聞こえるが、復旧速度を決定する。

次にリハーサルは復旧順序をテストすべきである。すべてのワークロードが同時に戻るわけではない。ID、ネットワーク接続性、管理ツール、ストレージ、アプリケーションサーバー、データベース、ユーザーポータル、レポート機能、サポートシステムは、順番に戻る必要があるかもしれない。金融サービス事業者は、どの加入者向け機能が最も時間的制約が厳しいか、どの内部機能が待つことができるかを定義すべきである。また、検証ゲートも定義すべきである。サービスは、インフラが稼働しているというだけで復旧が宣言されるべきではない。データ整合性、トランザクション状態、加入者アクセス、監査ログ記録、サポートの準備状況はすべてチェックを必要とする。

リハーサルはコミュニケーションのタイミングを含めるべきである。プロバイダ側の障害の間、顧客は当初、原因がサイバー、運用、プロバイダ、顧客、または第三者であるかを知らないかもしれない。優れたコミュニケーション計画は、沈黙なしに不確実性を許容する。サービスが利用不可であること、組織がプロバイダと調査中であること、加入者記録が保護されていること、推測されるべきでない原因について推測しないこと、次回の更新が指定された時刻に届くことを伝えることができる。証拠が改善するにつれて、メッセージはより具体的になり得る。最悪のパターンは、自信過剰な初期メッセージの後に、加入者がすでに信頼を失った後に修正が入ることである。

プロバイダも顧客向け復旧をリハーサルすべきである。管理サービスプロバイダは、優れた内部エンジニアリングを持ちながらも、サポートチャネル、インシデントコマンダー、アカウントチームが調整できなければ、顧客に対して失敗する可能性がある。プロバイダのリハーサルは、適切なエンジニアリングチームが影響を受けたプライベートクラウドを特定し、ログを保存し、破壊的な伝播を停止し、バックアップと復旧オプションを見つけ、顧客に正確に説明し、未解明のままのことを説明できるかどうかをテストすべきである。公開クラウド顧客は、インシデント中にプロバイダ内部の境界をナビゲートする必要があってはならない。

復旧後、リハーサル記録は実際のインシデント記録と比較されるべきである。どの仮定が間違っていたか？どの連絡パスが失敗したか？どのバックアップインベントリが古かったか？どの手動ステップが長すぎたか？どの加入者メッセージが不明瞭だったか？どのプロバイダ証拠が遅すぎたか？次のテストの前にどの管理策変更が必要か？これが、説明責任が物語管理ではなく改善になる場所である。

したがって、UniSuper インシデントは、クラウドサービス全般に対する警告ではない。不完全なシナリオ設計に対する警告である。クラウド環境はハードウェア損失に対して回復力がある一方で、依然として管理上の削除に曝される可能性がある。バックアップは存在しても、障害境界に近すぎる可能性がある。プロバイダはサービスを復旧しながらも、顧客に未回答の証拠質問を残す可能性がある。加入者向け組織は頻繁にコミュニケーションをとりながらも、後に依然としてより明確な証拠ファイルを必要とする可能性がある。責任ある教訓は、実際に発生した障害クラスに対して復旧を設計、テスト、文書化することである。

外部の管理基準は、公開分析を非公開監査に変えることなく、その証拠ファイルを定義するのに役立つ。NIST の緊急時計画ガイド（https://csrc.nist.gov/pubs/sp/800/34/r1/final）は、復旧計画をビジネス影響分析、戦略、計画策定、テスト、保守のライフサイクルとして扱っているため有用である。NIST SP 800-53 Revision 5（https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final）は、緊急時計画、アクセス制御、監査と説明責任、構成管理、インシデント対応、システム完全性のための管理策の語彙を提供しているため有用である。これらの情報源は、Google Cloud や UniSuper が何を実装したかを述べるものではない。これらは、削除防止策、復旧テスト、証拠保持、顧客コミュニケーションが、即興の対応タスクとしてではなく、管理策として評価されるべき理由を示している。

読者のための証拠ファイル

本稿では、Google Cloud と UniSuper のプライベートクラウド削除、リージョンバックアップ復旧、プロバイダ-顧客コミュニケーション、クラウド継続性の説明責任に関する証拠ファイルとして、以下の公開情報源を使用する。企業と顧客の声明は、それらの当事者が公に述べたことの証拠として扱われる。製品ドキュメントは、サービスとアーキテクチャの文脈に使用される。規制および標準の情報源は、管理策の語彙に使用され、インシデントに関する調査結果としては扱われない。

取締役会レビューの質問

取締役会レビューは、コントロールプレーンマップから始めるべきである。プロバイダ側のどの管理アクションが、プライベートクラウド環境を削除、停止、失効、無効化し得るか？それらのアクションを止める安全策は何か？どのような例外が存在するか？どのようなアラートが発火するか？どのような人間の承認が必要か？安全策が失敗した場合に利用可能な顧客可視の証拠は何か？回答は、一般的なクラウドポリシーからコピーするのではなく、管理サービスに固有であるべきである。

第二のレビューは、バックアップの独立性をテストすべきである。どの復旧用素材が影響を受けた環境の外にあるか？主要サブスクリプションが利用不能な場合に、どの資格情報と指示が依然として使用可能か？リージョン停止だけでなく、プロバイダ側の管理上の障害をシミュレートする復旧テストはどれか？どの加入者向け機能が最初に復旧されるか？どの記録が調整を必要とするか？どの規制当局または取締役会への通知がトリガーされるか？

第三のレビューはコミュニケーションに対処すべきである。誰が加入者に話すか、誰が規制当局に話すか、誰がプロバイダに話すか、誰が公開声明を承認するか？根本原因がまだ調査中の間、何を言うか？不確実性と信頼性はどのように分離されるか？データが保持され、サービスが復旧され、将来の再発が阻止されたという声明を裏付ける証拠は何か？

この特定の事例について、統治上の質問は依然として次の通りである。誰が、プライベートクラウドのプロビジョニング、アカウント削除の安全策、クロスリージョンバックアップの独立性、顧客コミュニケーション、サービス復旧の証拠、プロバイダ側の管理上の障害が回復可能な分離なしに重要なテナントを消去できないことの証明に対して、実際的な管理権限を持っていたか？完全な回答は、プロバイダの管理策、顧客の管理策、バックアップの分離、復旧の証拠、加入者への影響、残余の不確実性を特定すべきである。