障害時に誰もログインできない：緊急アクセス権限の備え方

深夜に障害が起きました。設定を戻せば復旧できそうですが、作業に必要な権限は承認制です。ところが承認者もログインできません。承認を受けるための仕組みそのものが、今回の障害で止まっているからです。

これは「安全のために承認を増やすか、復旧のために省くか」という二択では解けません。普段の作業に使う一時的な権限と、通常のアクセス経路が壊れたときの復旧手段を、同じ仕組みで管理してよいかという問題です。強い権限を常に全員へ配る必要はありません。一方で、すべてを同じ承認経路に閉じ込めると、最後の復旧手段まで一緒に失います。

「緊急」という名前だけでは、管理方法を決められない

米国NISTのSP 800-53 Rev.5は、一時・緊急アカウントの自動削除や無効化を、組織が定める期間で行う統制を示しています。しかし同じ文書は、ネットワークが使えないときなどに使う最後の手段のアカウントを区別し、通常の自動失効の対象と混同しないよう説明しています。NIST、AC-2の解説とAC-2(2)

ここを読み落とすと、「緊急権限は全部、短時間で消せば安全」という誤った運用につながります。短時間だけ必要な作業権限を残さないことと、障害時の入口をあらかじめ維持することは、異なる目的を持ちます。なお、NISTは統制のカタログであり、この運用による事故削減率や最適な有効時間を測定した実験ではありません。

本稿が提案する管理上の区分は、まず通常の認証と承認が使える場面、次にその前提が壊れている場面です。前者なら対象作業に必要な範囲へ一時的に昇格し、終了時に戻す設計を検討します。後者には、壊れた経路へ依存しない復旧用の入口が必要になる場合があります。「急いでいる」という本人の申告だけで、後者へ飛ばさないことが大切です。

消してはいけない入口もある

Microsoft Entra IDの公式資料は、緊急アクセス用アカウントに対し、通常と異なる強い認証、監視、定期的な利用確認を求めています。また、復旧用の管理ロールは承認待ちの資格ではなく、常時有効な割当てとする設計を示しています。これはEntra固有の構成要件で、あらゆる製品へそのまま適用する指示ではありません。Microsoftの緊急アクセス管理

両資料は、同じ名前のアカウントに矛盾する指示を出しているようにも見えます。NISTが短期利用の緊急アカウントと最後の手段を分けているのに対し、Microsoftの説明は管理者が締め出された場合の入口です。名前をそろえるより、用途をそろえて読む必要があります。常時有効な復旧用権限も、日常作業の抜け道ではありません。利用の検知、資格情報の保護、利用後の確認と一体で設計します。

認証を弱くすれば独立性が得られるわけでもありません。通常と復旧用の双方が同じ端末、同じ通信経路、同じ保管先に依存していれば、その一つの障害で共倒れになる可能性があります。何から独立させる必要があるかは、想定する故障から逆向きに調べます。製品の最新の要件と組織の規程を確認し、必要な認証を一律に外す運用にはしません。

承認者が不在なのか、承認機能が壊れたのか

仮想の受注システムで考えてみます。夜間バッチが止まり、当番が設定変更を必要としています。認証も権限の申請も動いていて、通常の承認者が応答しないだけなら、事前に定めた代行者や当番の承認経路を使う設計が候補になります。毎回、復旧用の最上位権限を使う理由にはなりません。

ところが、認証設定の変更ミスで、代行者を含めた管理者全員が締め出されているとします。この場合、承認者の人数を増やしても解決しません。同じログイン機構を通るからです。必要なのは、あらかじめ用意して試験した別の復旧経路です。ここでは、通常権限の失効を厳格にすることだけでは不足します。

さらに、問題が一つの業務アプリに限られ、通常の管理経路が使えるなら、その範囲の権限で足りるかを先に判断します。影響の大きな最上位権限を使うほど、誤操作時の範囲も広がります。復旧用の入口があることと、あらゆる障害でそれを使うことは結び付けません。これは実績値ではなく、障害の位置で選択が逆転することを示す例です。

人数より先に、例外を使える条件を決める

職務分離を「いつでも二人が同時に画面を見れば成立する」と捉えると、夜間や広域障害の設計が行き詰まります。NISTのAC-5は、分離すべき職務とアクセス権限を定める統制です。一律の承認人数をすべての作業へ指定するものではありません。NISTの職務分離・最小権限

編集部からの提案は、例外を使える条件を平時に承認し、実行者と確認者の役割をその条件に合わせて置くことです。誰が緊急事態を宣言できるか、どの復旧操作まで認めるか、誰へ通知するか、通常経路が使えない事実をどう残すかを決めます。規程や契約が事前の複数人確認を要求する作業は、記事の提案を理由に省略できません。

一人で実行できる例外を認めるとしても、実行者が後から利用記録まで自由に消せる設計では、説明責任が弱くなります。利用の時刻、対象、実行内容を別に確かめられるようにし、事後の確認者が操作の必要性と範囲を照合できるようにします。ただし、事後確認は事前承認の完全な代替ではありません。取り返せない操作は、復旧のためであっても別の制約が必要です。

緊急利用の記録には、パスワードや秘密鍵そのものを貼り付ける必要はありません。残したいのは、なぜ通常経路を使えず、誰が何を行い、何が戻ったかです。監査のための資料が新たな資格情報の保管場所にならないよう、記録の内容と閲覧範囲も分けます。

通常の認証基盤が止まった状態から入口を追う

通常アカウントも緊急アカウントも同じ外部認証、同じ端末、同じ通信経路へ依存するなら、その共通障害では両方が使えない。緊急権限の強さではなく、最後の復旧入口までの依存を図の外に残していないかを見る。

独立した入口を設ける場合も、秘密の保管、利用した記録、利用後の失効と点検が要る。平常時の一時昇格とは、認証の復旧前に使えることが違う。製品の仕様にある緊急アクセス機能を置いただけでは完了とせず、依存先の停止を想定した到達確認で読む。

復旧した瞬間に、管理の仕事は終わらない

一時昇格なら、作業終了後の権限返却を確認します。最後の復旧用アカウントなら、使用後にアカウント自体を消すと、次の障害への備えを失うことがあります。製品の要件と手順に沿って資格情報の保護状態や利用履歴を点検し、復旧のために追加した通常アカウントの権限を回収します。この二つの後処理も同じではありません。

事後の問いは「承認欄が埋まったか」だけでは不足します。許可した範囲を超えなかったか、変更が残って次の障害を招かないか、利用通知が確認者へ届いたか、通常経路を回復できたかを見ます。復旧用の入口を日常的に使う事例が増えたなら、利用者の注意不足だけでなく、通常の申請や当番体制が機能しているかも直す対象です。

訓練では、単にログインできたという結果だけで終えません。「普段の認証経路が使えない」という前提でも、必要な保管物と担当者に届き、許された操作を実行し、通知と記録を確認できるかを試します。実環境に影響する試験の範囲は別途決める必要がありますが、手順書を読むだけでは見えない依存関係を探すことが目的です。

経営側が受け取る報告も、緊急アカウントの件数だけでは足りません。入口は維持できているか、通常経路の失敗を想定した試験を実施したか、想定外の利用が残っていないかを確認します。例外の存在を減らすことと、例外の無統制な利用を減らすことを区別すれば、必要な備えを数合わせで削除せずに済みます。

通常の経路が動くなら、対象と時間を絞った権限を使う。経路自体が壊れる可能性には、独立した復旧手段を用意する。そして、どちらにも利用の条件と説明できる記録を持たせる。緊急時の権限管理で選ぶべきなのは、厳しさか速さかではなく、何が壊れても必要な統制を続けられる構成です。