唯一の管理者の不在

この状態なら読む

次のような会社を対象にします。

• クラウドやSaaSの管理者が実質1人しかいない
• 管理者IDや復旧方法をその人しか知らない
• MFAがその人のスマートフォンだけに結び付いている
• 契約名義、請求情報、ドメイン、DNS、バックアップ等の管理情報が個人へ集中している
• その人が退職、長期不在、入院、連絡不能になると管理できなくなる
• すでに管理者本人と連絡が取れず困っている

管理者が複数いて通常の退職手順で処理できる場合は、通常の退職日手順の方が適しています。

このページの目的は、最高権限を全員へ配ることではなく、一人の記憶・端末・電話番号だけを会社の唯一の復旧経路にしないことです。

日常管理と緊急復旧を分ける

属人化をなくすために、全員を管理者にする必要はありません。

少なくとも次を分けます。

「管理者パスワードを複数人で共有する」は、この4つを混ぜるため、同じ解決策とは扱いません。

1人しかいないものを探す

サービスごとに次を確認します。

• 管理者は何人いるか
• 会社管理の管理者IDがあるか
• MFAは誰のどの端末に依存しているか
• 復旧用メールアドレスや電話番号は誰のものか
• 管理者が使えない場合の公式復旧手段は何か
• 契約名義、請求先、更新時期を会社で確認できるか
• ドメインやDNSの管理者は誰か
• バックアップ設定を誰が変更できるか
• 外部業者だけが管理者になっていないか

1つでも「その人しか分からない」なら引継ぎ対象です。

管理者がいるうちに行うこと

会社管理の別管理者を用意できるか確認する

製品が複数管理者を認めている場合は、必要な役割へ別の会社管理IDを追加できるか確認します。

目標は次です。

• 利用者ごとのIDがある
• 誰にどの管理権限があるか確認できる
• 一人が不在でも別の会社管理者が必要な変更を実施できる

日常的に最高権限が不要な人へ「念のため」で最高権限を配る必要はありません。製品が役割を分けられる場合は、通常業務の権限と緊急時の復旧権限を分けます。

公式の緊急復旧経路を確認する

一部のサービスには、通常の管理者が利用できない場合へ備えた緊急アクセスや管理者復旧の仕組みがあります。

Microsoft Entra IDでは、通常の管理アカウントを利用できない場合の管理者ロックアウト対策として、複数の緊急アクセス用管理者アカウントを用意することを推奨しています。

これはMicrosoft Entra ID固有の実装例です。他製品に同じ名称や仕様があるとは限りません。

利用中のサービスでは、公式資料や管理画面で次を確認します。

• 別の管理者を追加できるか
• 緊急用管理者の仕組みがあるか
• 組織所有を証明して管理権を回復する方法があるか
• MFA端末喪失時の正規復旧手段があるか
• サポート経由の復旧手続きがあるか

MFAを1台の私物スマホだけに依存させない

管理者IDを複数にしても、認証手段が1人の私物スマートフォンだけなら復旧経路は依然として1本です。

サービスの仕様に応じて次を確認します。

• 管理者ごとに別のMFAを登録できるか
• 会社管理の認証手段を使えるか
• セキュリティキー等を使えるか
• 復旧コード等がある場合、誰がどこで管理するか
• 端末紛失時の公式復旧方法は何か

MFAを弱くすることではなく、強い認証を維持しながら単一の個人端末依存を外すことが目的です。

契約・請求・ドメインも別に引き継ぐ

管理画面へ入れても、契約主体が分からなければ復旧で困ります。

少なくとも次を会社の記録として残します。

• サービス名
• 契約名義
• 契約番号等の識別情報
• 請求先
• 更新時期
• サポート窓口
• 管理ドメイン
• DNSやレジストラの管理場所
• 自社側責任者

秘密情報そのものを誰でも見られる一覧へ書く必要はありません。どこで会社として管理しているかを記録します。

「パスワードを紙に書く」とは別の設計にする

緊急時に必要な情報を安全な場所へ保管すること自体は、製品や運用によって選択肢になり得ます。

ただし、次の状態を属人化解消とは扱いません。

• 共有フォルダへ平文パスワードを置く
• チャットへ管理者パスワードを投稿する
• 誰でも見られる紙へ書く
• 個人のメモ帳だけへ復旧コードを残す
• 退職者のパスワードをそのまま使い続ける

必要なのは秘密を広く共有することではなく、権限主体、保管場所、利用条件、更新責任者を会社として管理することです。

管理手順も引き継ぐ

権限を複数化しても、「何をどこで変更するか」を1人しか知らなければ業務は止まります。

最低限、次を記録します。

• 利用者を追加・削除する場所
• 管理者を確認する場所
• MFAを管理する場所
• 契約・請求を確認する場所
• バックアップを確認する場所
• サポートへの問い合わせ方法
• ドメインやDNSを管理する場所
• 障害時に最初に確認する場所

手順書には秘密そのものを書かず、安全な保管場所から取得する方法を示す構成も考えられます。

本人がすでに不在の場合

1. 会社側に残っている権限を探す

• 別の管理者ID
• 請求管理者
• 契約管理者
• サービス所有者
• ドメイン管理者
• 外部業者の管理者
• ログイン済み会社端末

「本当に誰も管理できないのか」を確認します。

ログイン済み端末が見つかっても、その状態を無期限の管理方法にはせず、正規の管理権回復へ使える情報を確認します。

2. 会社所有を確認できる情報を集める

• 契約書
• 請求書
• 会社名義のメール
• ドメイン所有情報
• 支払い記録
• 顧客番号等

サービス提供者へ正規の復旧依頼をするときに、組織としての関係を確認する材料になる場合があります。

3. 公式の復旧手段へ戻る

利用サービスの公式サポートや管理者復旧手順を使います。

• 管理者ロックアウト時の手順
• MFA端末喪失時の手順
• 組織所有者変更の手順
• サポート問い合わせ
• ドメイン所有確認

製品ごとに手順が違うため、別製品の復旧方法を流用しません。

4. 本人になりすます方法を前提にしない

本人のパスワードを推測したり、本人になりすまして個人の復旧情報を変更したりする方法を前提にしません。

会社側に残る正規権限、契約情報、サービス提供者の公式復旧経路へ戻ります。

回復後に再発防止を行う

管理権限を取り戻した後は、通常業務を再開して終わりにしません。

1. 現在の管理者一覧を確認する
2. 不要な管理者を外す
3. 必要な会社管理者または緊急復旧経路を複数化する
4. MFAと復旧先を確認する
5. 契約・請求主体を会社側で確認できるようにする
6. 公式復旧方法を記録する
7. 別の担当者が手順を確認する
8. 定期棚卸しへ登録する

定期棚卸しで属人化を見つける

半年や年1回等、自社で運用できる周期で次を確認します。

管理者の人数ではなく、復旧可能性を見ます。

「二人いる」だけでも不十分な場合がある

管理者が2人いても、次のような場合は同じ単一点を共有しています。

• 2人とも同じ共通IDを使っている
• MFAが同じ1台の端末にしかない
• 復旧先が退職予定者の個人メールだけ
• 契約情報を1人しか知らない
• 緊急時の手順を誰も確認したことがない

人数ではなく、独立した正規の復旧経路が会社として存在するかを確認します。

復旧手段は定期的に確認する

緊急用アカウントや手順を作っても、長期間使わなければ利用不能になっている可能性があります。

サービス仕様と自社ルールに合わせて次を確認します。

• アカウントが有効か
• 認証手段が利用できるか
• 保管場所へ権限者が到達できるか
• 連絡先や契約情報が古くないか
• 手順書の担当者や画面が変わっていないか

本番環境へ不要な変更を加えることではなく、復旧経路が現実に使える状態かを確認します。

最小の改善手順

まだ唯一の管理者が在籍している場合:

1. 管理サービスを一覧にする
2. 各サービスの管理者・MFA・復旧先を確認する
3. 別の会社管理者または公式緊急復旧経路を用意する
4. 契約・請求・ドメイン情報を会社の記録へ残す
5. 別担当者が確認できる手順を残す
6. 不在時の担当を決める
7. 定期棚卸しへ登録する

すでに不在の場合:

1. 会社側に残る管理権限を確認する
2. 契約・請求・ドメイン等の会社所有情報を集める
3. 製品の公式管理者復旧手順を確認する
4. 必要なら正規サポートへ組織として問い合わせる
5. 回復後に管理者・MFA・復旧経路を再設計する

この状態を目標にする

次を会社として説明できる状態を目標にします。

• 誰が通常管理者か
• 通常管理者が使えない場合にどの正規経路で復旧するか
• MFAや復旧先は何に依存しているか
• 契約・請求主体は誰か
• ドメインや重要サービスをどこで管理しているか
• 秘密情報をどこで安全に管理しているか
• 別の担当者が復旧手順をたどれるか

目標は管理者権限を広く配ることではありません。一人がいなくなっても、会社が正規の方法で管理を継続・回復できる状態を作ることです。