「困ったときに作業できるよう、全員を管理者にしている」。便利に見える設定ですが、そのIDが悪用されたときには、利用者を増やしたり、会社全体の設定を変えたりする権限まで使われるおそれがあります。管理者IDは、使う人と、できる操作を業務上必要な範囲に絞って管理します。
管理者IDとは、システムの設定や利用者の管理など、強い権限を使うためのIDです。前回は通常のユーザIDの発行から利用終了までを扱いました。今回は、その中でも影響の大きい管理者IDについて、担当、権限、環境、手続を確認します。
図1 全8基準を四つのまとまりで確認する
サーバーを社内に置いていない会社でも、利用中のクラウドには管理画面や管理権限があります。公式解説書のシステム責任者の説明にも、クラウドサービスが含まれます。自社で管理する範囲と提供事業者が管理する範囲を分け、自社側の担当と設定を確認しましょう。
公開されたキーが不正なソフトの配布につながった事例
生成AIの利用を仲介するソフトウェア「LiteLLM」の開発元は、2026年10月23日付の原因調査報告で、5月に公開された設定ファイルに内部サービスの管理用キーが含まれていたと説明しています。ファイルは削除されましたが、キーは失効されないまま残っていました。
攻撃者はこのキーを使い、ソースコード等を管理するGitHubの組織所有者に結び付くトークンを取得しました。その後、他の保守担当者のトークンも取得し、配布手順の変更と承認に悪用しました。10月21日には、不正な内容を含むLiteLLM 1.107.0が配布されています。
図2 LiteLLMの原因調査報告から整理した経路
ファイルを消すことと認証情報を失効させることは違う
この事例では、見える場所から設定ファイルを削除しても、キー自体は利用可能でした。また、所有者の強い権限が、保護された配布手順の変更にも使われています。自社では、認証情報を隠す作業だけで終わらせず、その情報で何ができるか、利用を止めたかまで確認する必要があります。
トークンやAPIキーは、システムが権限を利用する際の認証情報です。人の管理者IDと同一ではありませんが、公式解説書はこれらにも、目的・管理責任者の明確化、最小権限、不要時の無効化等を望ましい管理として示しています。本事例は、その関連性を考えるために紹介しています。
担当と保有者を把握する 4-1-2-1と4-1-2-5
4-1-2-1 管理する人と責任を負う人を決める
4-1-2-1では、すべてのサーバーとネットワーク機器について、システム管理者と責任者を定めます。自己評価では、システム管理台帳等を使って、担当が決まっていることと、その文書名を確認します。
システム管理者は、対象システムの管理業務を行い、管理者権限を持つ人です。システム責任者は、そのシステムのセキュリティ対策や運用に責任を持つ人です。機器を設定できる人がいることと、運用の責任者が決まっていることを分けて確認します。
| 確認する役割 | 架空の割当て例 |
| システム責任者 | 業務システムA／総務部長の佐藤花子／運用とセキュリティ対策に責任を持つ |
| システム管理者 | 業務システムA／情報システム担当の山田太郎／承認された管理作業を行う |
| 対象との対応 | システム名と管理対象を一覧にし、担当が空欄になっている機器やサービスを確認する |
組織の規模等によっては、同じ人が両方を兼任しても差し支えないと公式解説書に示されています。兼任時に、操作ログや変更履歴を確認したり、上長が承認・事後確認をしたりすることは、権限の乱用や誤操作を防ぐための望ましい方法です。
4-1-2-5 誰が管理者IDを持っているか分かる仕組みにする
4-1-2-5では、組織内の役員、従業員、派遣社員、受入出向者のうち、誰が管理者IDを持つかを把握する仕組みを整えます。ID管理台帳や管理システムが方法の例です。特定の有料製品を導入すること自体が要件ではありません。
実務では「山田さんが管理者」という名簿だけでなく、どのシステムの、どのIDを、どの用途で使うかまで対応させると、担当交代時の確認に使えます。台帳と実際の管理画面が食い違わないよう、IDの追加・変更・削除を一覧の更新につなげます。
例えば、一時的な設定作業のために発行したIDが、通常の担当者一覧に載らないまま残ることがあります。通常担当だけでなく、期間限定の担当や受入れ要員も対象にして、保有者を確認する仕組みを作ります。これは漏れを減らす実務上の例です。
使う人を限定する 4-1-2-2
4-1-2-2は、管理者権限を付与する役員、従業員、派遣社員、受入出向者を限定したうえで、管理者IDを共有しないこと、または、やむを得ず共有する場合に実際の利用者を特定できることを求めています。
まず、その人に管理作業が必要かを確認します。部署の全員が同じ仕事をしていても、全員が利用者の追加や通信設定の変更を行うとは限りません。普段の業務に必要な操作と、管理担当だけが行う操作を分けて考えます。
共有可能な人の名簿と実際に使った人の記録を分ける
システムの仕様で人数分のIDを作れない場合は、やむを得ない共有の例です。個人別に作れる場合は、同じ権限を持つ個別の管理者IDを用意する方法が考えられます。共有する場合も「担当は三人」と分かるだけでなく、誰が使ったかまで追える必要があります。
図3 共有管理者IDの利用者を特定する実務例
公式解説書は、作業日報などで利用実績を記録する方法を挙げています。例えば、対象ID、利用者、開始・終了時刻、作業内容を残し、操作記録と対応させます。複数人が同時に使って区別できない場合は、利用方法や記録の取り方を見直します。
共有の必要性がなくなった人については、利用者一覧の修正に加え、その人が引き続き使えないかを確認します。共有IDそのものを廃止するのか、利用者の変更に伴って認証情報等を変更するのかは、サービスの仕様と利用状況に合わせて決めます。
できる操作を必要最小限にする 4-1-2-3
4-1-2-3では、管理者IDごとに、その用途に必要な最小限の権限だけを付けます。管理者という名前の役割を選んで終わりにせず、どこまで操作できるかと、その操作が必要な理由を照らし合わせます。
図4 通常業務と管理作業で使う権限を分ける実務例
| 必要な仕事の例 | 権限を確認する視点 |
| 利用者の登録 | 登録作業に必要な範囲か。通信設定や別サービスの管理まで可能になっていないか |
| 通信機器の設定 | 担当機器と設定に限定できるか。関係のないシステムまで変更できないか |
| システムの保守 | 保守に必要な操作か。個人情報の内容まで閲覧する必要があるか |
公式解説書は、操作の種類や対象範囲を絞る方法に加え、権限を利用できる時間的な機会を限定する方法も示しています。通常操作は限られた権限で行い、管理作業時だけ管理者権限を使う方式は、その例です。
このため、全員に常時すべての権限を与える設定から、担当する作業に対応した権限へ見直すことが出発点になります。サービスごとに選択できる役割が異なるので、役割名だけで判断せず、できる操作を確認します。
人のIDに加え、自動処理用のAPIキーやサービスアカウントも、何の処理に使うか、誰が管理するかを整理すると、強すぎる権限を見つけやすくなります。これは公式解説書が示す関連する管理であり、認証情報そのものを台帳に平文で集めることを勧めるものではありません。
開発用の権限で本番を操作させない 4-1-2-4
開発環境は、システムを作ったり変更を試したりするための環境です。本番環境は、顧客や従業員が実際の業務で利用する環境です。試験のために広い操作が必要でも、その権限がそのまま本番で使えると、試験操作や誤操作が実際のサービスに影響するおそれがあります。
4-1-2-4では、開発環境を利用する役員、従業員、派遣社員、受入出向者が、開発環境の管理者権限で本番環境を操作できないようにします。担当者が注意するという約束に加え、IDや権限の設定として制限できているかを確かめます。
図5 開発用の権限が本番へ通らないようにする設定例
名前を分けただけで権限も分かれたとは限らない
開発用と本番用でID名を変えても、両方に同じ全体管理の権限が付いていれば、境界ができていない場合があります。所属グループや役割の設定を確認し、開発用の権限が本番への変更を許可していないかを調べます。
同じ人が開発作業と本番の保守を担当する場合も、本番で必要な作業は別に判断し、承認された本番用の権限で行う運用が考えられます。人を必ず別々にすることや、物理サーバーを必ず分けることを一律に定めた基準ではありません。
開発を行わない組織でも、公式ガイドのこの基準の対象外条件は「該当なし」です。独自に対象外と記入するのではなく、開発環境の有無や実際の利用状況を整理し、公式の自己評価方法に沿って適用状況を確認します。
不要な管理者IDを実際に止める 4-1-2-6
4-1-2-6では、管理者IDが不要になった場合に、速やかに削除又は無効化します。退職した場合や、一定期間使われなかった場合は、公式基準が挙げる例です。担当交代や一時作業の終了でも、そのIDが引き続き必要かを確認します。
ここでは、削除の手順書を用意しただけで終わりません。自己評価方法も、ID管理規程、台帳、管理システム等を確認し、不要になった管理者IDを実際に速やかに削除・無効化していることを確認する形です。
| 確認する場面 | 対応と記録の実務例 |
| 退職や担当交代 | 利用終了の時点と対象IDを把握し、削除又は無効化の日時、実施者、結果を残す |
| 一定期間未使用 | 利用目的と今後の予定を確認し、不要と判断したIDを速やかに削除又は無効化する |
| 期間限定の保守 | 作業が終わったことと、追加発行した管理者IDの利用終了を対応させる |
| 共有者の変更 | 共有者を見直し、不要になった人が使えない状態にする。ID全体が不要なら削除又は無効化する |
次の棚卸しまで不要なIDを残さない
この基準は、全組織に共通する24時間以内や90日未使用といった数値を定めていません。自社では利用終了の連絡先、実施担当、必要な時点を具体化します。予定された退職や保守終了なら、事前に申請と承認を済ませ、利用が不要になる時点に合わせて対応する運用が考えられます。
定期的な棚卸しは、止め忘れや不要なIDを見つけるために有効です。公式解説書も管理者IDの棚卸しや共有者の見直しを挙げています。ただし、不要と分かったIDを次の棚卸しまで残す理由にはなりません。
台帳の削除とシステム上の停止を一致させる
一覧の行を消しても、サービス側でログインできる状態が残れば、IDを停止したことにはなりません。実務では、対象システムの削除・無効化の状態と、実施記録を照合します。一般のユーザIDを継続する人でも、管理作業を終えた管理者IDが別にある場合は、そちらの必要性を確認します。
認証情報を保存したカード等の返還や、無効化したIDを他の利用者へ再発行しないことも、公式解説書が望ましい措置として挙げています。 自社の手順に採り入れる際は、必須基準と推奨される実施方法を分けて整理します。
申請承認と実行する権限を整える 4-1-2-7と4-1-2-8
4-1-2-7 付与と変更と削除を申請承認制にする
管理者IDを新しく付与するときだけでなく、変更・削除も申請・承認制にします。自己評価では、ID管理規程等で手続を確認し、その文書名を確認します。電子的なワークフローや管理ツールも利用できます。
申請には、対象システム、対象者、作業目的、必要な権限、利用期間等を示すと、必要性を判断しやすくなります。必要な理由、承認者、承認日を残すことや、本人以外の上司等が申請を確認することは、公式解説書が望ましい方法として示しています。
図6 申請承認の手続と実際に変更できる権限を両方確認する
4-1-2-8 IDの管理と機器の設定変更の両方を限定する
この基準には二つの確認対象があります。一つは、管理者IDの付与・変更・削除を実行する権限です。もう一つは、サーバーとネットワーク機器の設定内容を変更する権限です。どちらも業務上必要な役員、従業員、派遣社員、受入出向者に限定します。
申請書を承認する人と、管理画面で実際に変更できる人は、役割が異なります。規程では限定していても、設定上は全員が新しい管理者を作れるなら、実際の権限を見直す必要があります。ID管理規程と設定変更手順を、管理画面の状態につなげて確認します。
申請者・承認者・実施者を必ず別の三人にするという一律の人数要件はありません。組織に合う担当を決め、何を承認したかと、誰がその操作を実行できるかが分かる形にします。
8基準と確認資料を対応させる
次の表は、公式の自己評価方法と、運用を説明するための記録例を対応させたものです。特定の様式を八つ作るという意味ではありません。既存の台帳、規程、システム上の登録情報等を使い、どの基準をどこで確認できるかを整理します。
| 評価基準番号 | 確認する内容と資料の例 |
| 4-1-2-1 | 全サーバー・ネットワーク機器の管理者と責任者。システム管理台帳等と文書名 |
| 4-1-2-2 | 権限を与える人の限定と、非共有又はやむを得ない共有時の実利用者特定。規程・台帳・利用記録等 |
| 4-1-2-3 | IDの用途と最小権限の対応。ID管理台帳、管理システム、役割の設定等 |
| 4-1-2-4 | 開発用の管理者権限で本番を操作できないこと。環境別の権限やグループ設定等 |
| 4-1-2-5 | 誰が管理者IDを保有するか把握する仕組み。ID管理台帳やID管理システム等 |
| 4-1-2-6 | 不要なIDを実際に速やかに削除又は無効化していること。状態と実施記録等 |
| 4-1-2-7 | 付与・変更・削除の申請承認制。ID管理規程等と文書名、申請承認の記録例 |
| 4-1-2-8 | IDの管理権限と機器の設定変更権限の両方を限定。ID管理規程、設定変更手順、実際の権限等 |
今日確認するなら一つのシステムから
まず、よく使うシステムを一つ選び、責任者と管理者を確認します。管理者一覧を見て、その人が何の作業のために権限を持つかを説明できるか、共有IDなら実際の利用者を特定できるかを確認してください。
次に、権限の内容と開発・本番の区別を確認し、不要になったIDが実際に停止されているかを見ます。最後に、管理者を新しく追加する作業を例に、申請、承認、設定変更、一覧の更新がつながっているかを追います。
一つのシステムで確認方法が整理できたら、適用範囲の他のシステムへ広げます。確認しやすい一つだけを管理すればよいという意味ではありません。
次回はログイン時の本人確認
11月15日は、4-1-3「認証の強度・実装方法の決定」です。IDごとの認証や、多要素認証が求められる場面を、全4基準に沿って説明します。
連載の関連項目とご相談
第1回は連載目次、第13回は4-1-1「ユーザIDの管理手続」です。通常の利用者IDと管理者IDを対応させて読むと、人の入替え、権限の限定、利用終了の処理を一つの流れとして整理できます。認証の強度は第15回、アクセス権の付与は第19回でも扱います。
ライトハウスコンサルタントでは、★3を見据えた現状確認や、規程・台帳・記録の準備を支援しています。管理者一覧、権限設定、申請承認の手順を照らし合わせ、日々の運用で確認できる管理方法を整理するお手伝いをしています。
