Chapter 13 — Identityが死んでもRecoveryを始められるか

Backupは、まだ利用できる状態にあります。

組織はRecoveryを始める準備ができています。

しかし、通常の管理者identityや、いつも使っている管理経路は、まだ信頼できる状態にあると言い切れません。

このとき、目の前の問題は、もはやBackupコピーそのものではありません。

問題は、こうなります。

「Recoveryを始めるための管理経路そのものを、どう確保するか。」

この章では、この問いについて考えていきます。

13.1 Recoveryを始めるための経路が必要になる

Chapter 12では、Recoveryが依存要素の問題であること、そして依存要素は「利用できない」場合と「まだ信頼できない」場合という、少なくとも2つの異なる理由でRecoveryを妨げ得ることを見ました。

このうち、identityや管理経路そのものが対象になったとき、特有の問題が生じます。Recoveryを進めるには、対象によって管理権限や管理経路が必要になる場合があります。その管理経路が利用できない、またはまだ信頼できない場合には、通常の経路からRecoveryを開始できないことがあります。

この本では、この「Recoveryを始めるための経路」を、bootstrap pathと呼ぶことがあります。

ただし、これは本書がこの考え方を説明するために使っている呼び方であり、NISTやCISA、NCSCが定めた標準用語ではありません。

Recovery設計では、通常のidentityや管理経路が利用できない、またはまだ信頼できない状態から、Recoveryを開始できる経路を用意しておくことが望ましいと考えられます。

13.2 通常の管理経路が利用できない場合

一つ目の状況は、通常の管理経路そのものが利用できなくなる場合です。

例えば、identityの仕組み自体に障害が起きている、あるいはその仕組みが機能していないために、いつも使っている管理経路にアクセスできなくなることがあります。この場合、Recoveryを始めようにも、まずその入り口に立つことができません。

13.3 通常の管理経路をまだ信頼できない場合

二つ目の状況は、通常の管理経路自体は動いているものの、それをまだ信頼できない場合です。

管理経路や、それを使ってアクセスしてくる主体が、侵害を受けていないと確認できていない状態では、たとえ技術的にログインできたとしても、それをそのままRecoveryに使ってよいとは言えません。

「利用できない」ことと、「まだ信頼できない」ことは、別の問題です。 Chapter 12で見た区別は、ここでもそのまま当てはまります。この本では、この二つの状況に対して、それぞれ別の技術的解決策を割り当てるところまでは扱いません。どちらの状況であっても、通常経路をそのまま使えないという点では共通しており、次に見る考え方が関係してきます。

13.4 Emergency Access / out-of-band recovery access

通常の管理経路が利用できない、またはまだ信頼できない場合に備えて、通常とは別の経路（out-of-band）を通じた、緊急時専用のRecovery Access、すなわちEmergency Accessを用意しておくことで、recoverabilityを維持できる場合があります。

ここでの「通常とは別の経路」とは、単に「いつもの経路ではない経路」という意味であり、それが具体的にオフライン環境を指すのか、物理的に分離されたネットワークを指すのか、別の認証基盤を指すのかまでは、この本では特定しません。組織によって、実際に取り得る形はさまざまです。

Chapter 10では、Emergency Access自体が強い権限を持つため、独立した統制が必要であることを確認しました。本章では、その考え方をRecovery開始時の問題へと進めます。

ここで、はっきりさせておきたいことがあります。

Emergency Accessは、万能な管理者アカウントではありません。

Emergency Accessは、次のようなものではありません。

• 常に無制限の権限を持つ、恒久的なスーパー管理者アカウント
• あらゆる制御を無視できる、普遍的なバイパス手段
• それ一つでRecoveryのすべての依存要素を解決する魔法の手段
• それが使えることが、環境全体の信頼性を証明するもの

Emergency Accessは、あくまでRecoveryを開始し得る、一つの可能な手段にすぎません。それが存在すること自体が、Recoveryの成功を意味するわけではない点に注意してください。

13.5 Emergency Access自身も依存要素を持つ

Emergency Accessは、それ自体が万能ではないだけでなく、それ自体もいくつかの依存要素の上に成り立っています。

Recovery architectureは、通常のidentity、credentials、keys、documentation、administrative toolingが利用できない、または信頼できない場合に、Recoveryを実際に開始できるかどうかを確認しておく必要があります。

つまり、Emergency Accessを使ってRecoveryを始めようとしても、それに必要なcredentialやcryptographic material、手順に関する情報が用意されていなければ、結局Recoveryを始められない場合があります。

credential、key、secretは、それぞれ異なる概念です。 ここでも、これらを同一のものとして扱うことはできません。Chapter 9で見た、それぞれを個別に保護するという考え方は、この章でも変わりません。

ここでは、Emergency Access自体がこうした要素に依存し得るという点だけを確認するにとどめ、それぞれの保護方法を改めて設計することはしません。

13.6 Emergency Access自身を統制する

Emergency Accessは、それ自体が強力な特権を持つ仕組みであるため、独自の統制が必要です。

Chapter 10で確認したとおり、Emergency Accessにはbounded lifecycle（期限が区切られた運用）と、independent control（独立した統制）が必要になります。用意しただけで放置してよいものではありません。

ここで一つ、注意しておきたいことがあります。この「独立した統制」という考え方を、特定の技術的な実装要件へ安易に広げるべきではありません。例えば、次のような要件が普遍的に必要だとまでは、この本では述べません。

• 通常のidentityとは別の、独立したIdentity Providerを必ず用意すること
• Emergency Accessは常にオフラインで保管しなければならないこと
• 通常のシステムと決して連携（federate）してはならないこと
• 通常とは異なる認証基盤やネットワークを必ず使うこと

これらは、状況によっては有効な設計上の選択肢になり得ますが、この本の根拠となっている情報が直接支持しているのは、あくまで「期限が区切られていること」と「独立して統制されていること」という、より一般的な考え方までです。

また、Emergency Accessの利用状況についても、何らかの形で把握・確認できることが、独立した統制の一部として求められると考えられます。ただし、具体的にどのように記録・監視するかについては、この章では扱いません。

13.7 次のRecovery Planへ接続する

ここまで、Recoveryを始めるための経路そのものについて考えてきました。

大切なのは、依存要素の存在が、Recoveryを始める順序を自動的に一つに決めるわけではないという点です。「Identityを必ず最初に復旧しなければならない」といった固定的なルールは、この本では支持していません。DNSやNetwork、Storageなどとの間に、普遍的な復旧順序があるわけでもありません。

また、Recoveryを始めるための経路自体が、他の依存要素に依存している場合、ある要素を戻すために別の要素が必要で、その別の要素を戻すために最初の要素が必要になる、といった循環的な問題が生じることもあります。この章では、identityや管理経路に関するこの種の循環的な問題が存在し得るということを確認するにとどめます。

Emergency Accessのような仕組みを使って実際にRecoveryを始められる状態になった後、具体的にどのような順序でRecoveryを進めていくかについては、後の章で改めて扱います。

13.8 まとめ

この章では、通常の管理経路が利用できない、またはまだ信頼できない状態から、どのようにRecoveryを始められるかという問題を整理しました。

重要なのは、次の点です。

• Recoveryを進めるには、対象によって管理権限や管理経路が必要になる場合があり、その経路自体が使えなければ、Recoveryを開始できないことがある。
• 通常の管理経路が「利用できない」ことと「まだ信頼できない」ことは、別の問題である。
• Emergency Access（out-of-band recovery access）は、recoverabilityを維持し得る一つの手段だが、万能な管理者アカウントではない。
• Emergency Access自体も、credentials、keys、documentation、administrative toolingといった依存要素の上に成り立っている。
• Emergency Accessには、期限が区切られた運用（bounded lifecycle）と、独立した統制（independent control）が必要である。
• Emergency Accessが存在することは、それだけでRecoveryの成功や、環境の信頼性を保証しない。

この章で確認する代表的な観点

ここまでの内容を、簡単な表として整理します。

この表は、状況ごとに何を考える必要があるかを整理したものであり、特定の実装方式を推奨するものではありません。

Chapter 13を読み終えた時点で考えてみてください

自分が担当しているシステムについて、次の質問に答えられるでしょうか。

1. 通常の管理経路が「利用できない」ことと「信頼できない」ことは、なぜ別の問題なのでしょうか。
2. Emergency Accessは、なぜ単なる万能管理者アカウントとして考えてはいけないのでしょうか。
3. Recoveryを始めるための経路自体が、credentialsやkeysなどに依存している場合、どのような問題が起こり得るでしょうか。
4. なぜ本書では、Emergency Accessの具体的な実装方式を一つに固定しないのでしょうか。
5. Emergency Accessが存在することと、実際のIncidentで使えることはなぜ同じではないのでしょうか。

すべて答えられなくても問題ありません。

むしろ、答えに詰まった点があれば、それがこの章で確認しておくべきポイントです。