2026.10.21 セキュリティ

特権ID管理とは：貸出・操作記録・パスワード変更の仕組みと監査で問われる要件

特権ID管理とは、LinuxのrootやWindowsのAdministrator、データベースの管理者、クラウドのグローバル管理者のように、システム全体を変更できるIDを「誰に・いつ・何のために」使わせたかまで統制する仕組みです。この記事では、特権IDと一般IDの違い、PAM・PIMとの用語の関係、貸出・操作記録・パスワード自動変更・棚卸しの4機能を説明します。あわせて、IPAの内部不正防止ガイドラインやAWS・Microsoftの公式ドキュメントが求める対策と、専用ツールを入れるべき組織・見送ってよい組織の線引きまで整理します。

まとめ：特権ID管理で押さえる貸出・操作記録・パスワード変更と監査の要点

特権ID管理の目的は、管理者権限を「常に持っている状態」をなくし、使うたびに申請・承認を通し、操作の記録を本人以外が確認できるようにすることです。中身は、申請と期限付きの貸出、操作記録、パスワードの自動変更、定期棚卸しの4つに分かれます。

監査で問われるのは、共有IDで操作者を特定できない状態、承認の記録がない貸出、管理者本人がログを消せる構成の3点が中心です。IPAのガイドラインも、権限の分散と作業報告の相互確認、特権を使った操作のログ記録を求めています。

実現方式を決める基準は、管理対象となる環境です。管理対象がMicrosoft 365やAzure、AWSに収まるなら、Entra IDのPrivileged Identity ManagementやAWSの標準機能で足ります。オンプレミスのサーバーやネットワーク機器、外部の保守ベンダーが絡むなら、専用ツールか自社システムへの組み込みを検討します。

特権IDの定義・一般IDとの差＝root・Administrator・クラウド管理者の範囲

特権IDに当たるアカウント＝OS・DB・ネットワーク機器・クラウドの管理者

特権IDは、OSの設定変更、ユーザーの作成と削除、データの全件参照、サービスの起動と停止ができるIDの総称です。代表は次のとおりです。

OSの管理者：Linuxのroot、WindowsのAdministratorやDomain Adminsのメンバー
データベースの管理者：OracleのSYS・SYSTEM、PostgreSQLのスーパーユーザー、SQL Serverのsa
ネットワーク機器・ストレージの管理者アカウント
クラウドの管理者：AWSアカウントのルートユーザー、Microsoft Entra IDのグローバル管理者
人が使わないID：バッチやアプリが使うサービスアカウント、APIキー

見落とされやすいのは最後の2つです。クラウドの管理者ロールは画面からいつでも付け外しでき、サービスアカウントは担当者が異動しても残り続けます。

一般IDとの違いは権限の広さと共有されやすさ、操作者の特定しにくさ

一般IDは1人に1つ発行され、退職時に削除すれば管理が完結します。特権IDはそうはいきません。rootやAdministratorは機器ごとに1つしかなく、複数の管理者や保守ベンダーで同じパスワードを共有する運用になりがちです。

共有された時点で、ログに残るのは「rootが操作した」という事実だけになり、どの担当者が操作したかを後から特定できません。情報漏えいやデータ削除が起きたとき、原因の調査も、関与していない担当者の潔白の証明もできない状態です。特権ID管理は、この「共有」と「匿名化」を断ち切るために置く仕組みと捉えると整理しやすくなります。

特権ID管理・PAM・PIMの用語の違いとIDガバナンス（IGA）との分担

用語はベンダーごとに揺れますが、実務では次の分担で読めば混乱しません。

用語	主に扱う対象	代表的な機能
PIM（特権ID管理）	誰が特権を持てるか	特権ロールの付与・期限・承認
PAM（特権アクセス管理）	特権をどう使ったか	パスワード金庫・セッション記録
IGA（IDガバナンス）	全従業員のID全体	入社・異動・退職の自動処理

日本語の「特権ID管理」は、PIMとPAMの両方を含む意味で使われることがほとんどです。一般ID全体の発行・回収や認証方式は認証・ID管理の全体像（MFA・SSO・IDaaSの違い）で扱っているので、本記事は強い権限を持つIDの統制に絞ります。

特権ID管理の4機能＝申請・貸出、操作記録、パスワード自動変更、棚卸し

申請・承認と期限付き貸出で常時付与をなくすジャストインタイムの考え方

中心になるのが、必要なときだけ権限を貸し出すジャストインタイム（JIT）の考え方です。Microsoft Entra IDのPrivileged Identity Management（PIM）の公式解説では、ロールを「有資格」として割り当てておき、使う時点で理由の入力、多要素認証、承認者の承認を経て一定時間だけ有効にする流れが説明されています。

同じページが挙げる主な機能は、期限付きの割り当て、有効化時の承認と多要素認証の強制、有効化の通知、アクセスレビュー、監査履歴のダウンロードです。ツールが何であれ、貸出には「申請理由・承認者・有効期限」の3つの記録が残る形にします。この考え方はゼロトラストの7原則と最小特権の原則を、管理者権限の運用に落とし込んだものに当たります。

操作記録（セッション録画・コマンドログ）で操作者を後から特定する仕組み

貸出の記録だけでは、借りた人が何をしたかは分かりません。専用ツールの多くは、管理者の接続を中継サーバー（ゲートウェイ）経由に限定し、画面の録画や入力コマンドを保存します。

記録は、操作した本人が削除・改ざんできない場所に置くことが条件です。サーバー内のログファイルだけでは、rootを持つ人がそのまま消せてしまいます。保存先を別アカウントのストレージやログ管理基盤に分け、閲覧権限を監査担当側に持たせる構成にします。

パスワード自動変更と金庫化で共有パスワードを人に渡さない運用

パスワード管理の機能は、特権IDのパスワードを金庫（ボールト）に預け、利用者には見せずにログインさせるものです。貸出が終わるとパスワードを自動で変更するため、一度借りた人が後から同じパスワードで入ることもできません。

手作業で運用する場合でも、「使用のたびに変更する」「変更後の値は封印して2人以上でしか開けない」の2点は守れます。定期変更の頻度を議論するより、使用後に必ず変える運用のほうが、共有パスワードが外に出たときの被害を確実に狭められます。

定期棚卸しとアクセスレビューで退職者・異動者の残存権限を消す手順

棚卸しは、特権を持つIDの一覧と、本来持つべき人の一覧を突き合わせる作業です。手順は次の順で進めます。

OS・DB・ネットワーク機器・クラウドごとに、管理者権限を持つIDを全件抽出する
各IDに所有者（責任者）を1人ずつ割り当て、所有者のいないIDを洗い出す
人事異動・退職・委託契約の終了と照合し、不要なIDを停止または削除する
結果を記録し、次回は人事異動の時期に合わせて同じ作業を繰り返す

一般IDの棚卸しまで含めて自動化したい場合は、ID管理システム比較（人事連携・棚卸しで選ぶ機能要件）で扱うIDガバナンス製品の領域になります。

監査で問われる特権ID管理の要件＝IPA内部不正防止GLとクラウドの公式指針

IPA内部不正防止ガイドライン（6）システム管理者の権限管理の4つの対策

国内の監査や内部統制の点検で参照されやすいのが、IPAの組織における内部不正防止ガイドラインです。2022年4月改訂の第5版で、10の観点・33項目の対策が整理されています。

特権IDに直接当たるのは項目「（6）システム管理者の権限管理」で、対策のポイントとして次の4点が挙がっています（PDF版42〜43ページ、2026年10月時点で確認）。

規範意識などの適性を満たす人をシステム管理者に任命し、複数人を任命して相互に監視する
1人の管理者に権限が集中しないよう権限を分散する
作業内容と作業日時を記した作業報告を残し、別の管理者が確認する
特権を必要とする操作以外では特権を使わず、特権の使用をログに記録する

管理者が1人しかいない組織については、操作履歴をシステム管理者以外の人が確認する代替策が脚注で示されています。少人数だから対策不要、という扱いにはなっていません。

AWSのルートユーザー管理に見るクラウド特権IDの具体的な守り方

クラウドで最も強い特権IDは、AWSアカウントのルートユーザーです。AWSのルートユーザーのベストプラクティスは、特権ID管理の原則をそのまま具体化した内容になっています。

ルートユーザーのアクセスキーは作成しない
多要素認証を必ず設定し、デバイスは複数登録する（最大8台）
パスワードとMFAデバイスを別々のグループが持ち、サインインに2人を要する状態にする
連絡先には個人ではなくグループのメールアドレスを使う
CloudTrailでルートユーザーの利用を記録し、GuardDutyなどで検知する

日常の管理作業は、ルートユーザーではなく権限を絞った別のIDで行います。AWSで人ごとの管理者権限を期限付きで割り当てる設計は、AWS IAM Identity Centerの権限セット設計で具体的に解説しています。

監査で指摘されやすい不備＝共有ID・承認記録なし・本人が消せるログ

上記の基準と照らすと、指摘を受けやすい不備は次の3つに整理できます。

1つ目は、共有IDの放置です。保守ベンダーと社内で同じrootパスワードを使い、作業者を特定できない状態がこれに当たります。2つ目は、承認の証跡がない貸出です。チャットや口頭で依頼して実施しているため、後から理由を説明できません。

3つ目は、ログの置き場所です。操作ログを取っていても、同じ管理者がログを削除できる構成なら証跡として扱えません。IPAのガイドラインも、委託先に権限を付与する場合は契約上の措置と、付与期間を必要な時期に限ることを求めています。

特権ID管理の実現方式の比較＝クラウド標準機能・専用ツール・自社開発の分担

Entra IDのPIMやAWSの標準機能でまかなえる範囲とライセンス条件

管理対象がMicrosoft 365・Azure・AWSに収まるなら、追加の専用ツールなしで貸出・承認・記録までそろいます。比較すると次のとおりです。

方式	得意な対象	弱い対象
Entra ID PIM	Entra・Azure・M365の管理者ロール	オンプレのOS・DB・機器
AWS標準機能	AWSアカウント・EC2への接続	AWS以外のシステム
専用ツール（PAM製品）	オンプレ・複数クラウドの混在	導入費と中継サーバーの運用
自社開発・組み込み	自社業務システムの管理者画面	OS・機器レベルの統制

Entra IDのPIMは無料版では使えません。Microsoft Entra ID ガバナンスライセンスの基礎によると、Entra ID P2またはEntra ID Governanceのライセンスが要り、P2はMicrosoft 365 E5・E7に含まれます（2026年10月時点）。同じページの記載では、ライセンスが切れると期限付きのアクティブ割り当てが永続化し、有資格の割り当ては削除されるという挙動です。更新漏れが、そのまま常時付与の状態に戻る点は契約管理に組み込んでおきます。Entra ID自体の構成はMicrosoft Entra IDの機能と料金にまとめています。

オンプレミスのサーバー・DB・ネットワーク機器が残る環境の選択肢

オンプレミスのLinux・Windowsサーバー、データベース、ネットワーク機器が数十台以上残っている環境では、クラウドの標準機能が届きません。この場合は、中継サーバーで接続を一本化し、パスワード金庫とセッション録画を備えた専用ツールが候補になります。

AWS上のサーバーでも、接続方法による記録の違いに注意が必要です。AWS Systems ManagerのSession Managerのログ記録はS3やCloudWatch Logsに操作内容を残せますが、ポート転送やSSH経由で接続したセッションは記録できないと明記されています。SSHの抜け道を残したままでは、録画しているつもりで記録が欠けます。接続経路そのものを1本に絞る設計が前提です。

業務システムの管理者画面に特権ID管理を組み込む開発と実装の範囲

見落とされやすいのが、自社で作った業務システムの管理者アカウントです。顧客データの全件出力や権限変更ができる管理者画面は、OSのrootと同じ重さの特権IDに当たります。市販のPAM製品はOSや機器の接続を中継する作りのため、アプリケーション内部の管理者操作までは記録できないことが多くあります。

この領域での対応は、管理者権限の申請・承認画面、権限の有効期限、管理操作の監査ログを業務システム側に実装する方法です。Entra IDなどの認証基盤と連携し、管理者ロールの付与をグループの割り当てで制御する構成も取れます。既存システムへの組み込みや認証基盤との連携は、一創の認証基盤・ID管理システム開発でご相談いただけます。

特権ID管理ツールを入れるべき組織と見送る組織の判断基準と失敗パターン

専用ツールを導入すべき条件＝管理対象の台数・外部委託先・監査対象

次のいずれかに当てはまるなら、専用ツールの導入を前提に検討します。

オンプレミスのサーバー・DB・ネットワーク機器が合わせて30台を超える
保守ベンダーなど外部の作業者が、本番環境の管理者権限で作業している
J-SOXの対象システムやカード会員データを扱う環境があり、監査で操作証跡の提出を求められる

30台という数字は一次情報ではなく、手作業の棚卸しと貸出記録が回らなくなる目安として本記事が置いた基準です。外部委託先が入る場合は台数にかかわらず、作業者の特定と作業後のパスワード変更を手作業で続けるのは難しくなります。

ツール導入を見送ってよい場面＝クラウド中心で管理者が数名の組織

一方で、専用ツールが過剰になる組織もあります。サーバーをほぼ持たずMicrosoft 365とSaaSで業務を回し、管理者が3〜5人に収まる組織では、PAM製品の中継サーバーを運用する負担のほうが大きくなります。

この場合は、Entra IDのPIMで管理者ロールを有資格化し、グローバル管理者を常時付与の2人程度に絞るところから始めます。加えて、緊急用アカウントの封印と、四半期ごとの管理者一覧の棚卸しで十分です。製品を入れる前に、特権IDの一覧が作れていない状態を解消するほうが先です。

導入して失敗する典型＝緊急用IDの抜け道とサービスアカウントの放置

ツールを入れても統制が効かない失敗は、ほぼ次の2つに集約されます。

1つ目は、緊急用IDの抜け道です。障害対応のために中継サーバーを通らない直接ログインを残し、それが日常的に使われるようになるケースです。緊急用IDは封印し、使ったら必ず通知が飛び、事後に理由を記録する運用にします。

2つ目は、サービスアカウントの放置です。人のIDは貸出管理に載せても、バッチやアプリが使うIDとそのパスワード・APIキーは設定ファイルに書かれたまま、何年も変わらないことがあります。棚卸しの対象に人以外のIDを含めない限り、最も長く同じ認証情報が残る場所が統制の外に置かれます。

よくある質問

特権ID管理について、導入検討の段階でよく寄せられる質問をまとめました。

特権ID管理とPAMは同じ意味ですか？

日本語の「特権ID管理」は、PAM（特権アクセス管理）とPIM（特権ID管理）の両方を含む意味で使われることがほとんどです。厳密には、PIMは誰が特権を持てるかを期限と承認で管理し、PAMは特権の使い方をパスワード金庫や操作記録で統制するものと分けられます。製品選定ではこの区別が効いてきます。Entra IDのPIMは前者が中心で、オンプレミスサーバーのセッション録画は含みません。

特権IDのパスワードはどのくらいの頻度で変更すべきですか？

一律の日数を決めるより、使用のたびに変更する運用を基本にします。貸出が終わった時点での変更は、借りた人が後から同じパスワードで入ることを防ぐための対策です。専用ツールを使えば自動化でき、手作業なら作業完了報告とパスワード変更を同じ手順に含めます。人が使わないサービスアカウントは、変更時にアプリ側の設定も更新が必要なため、変更手順を事前に用意しておきます。

特権ID管理は中小企業でも必要ですか？

必要です。ただし専用ツールが必要とは限りません。IPAの内部不正防止ガイドラインは、管理者が1人しかいない場合でも、操作履歴を管理者以外の人が確認する代替策を求めています。中小企業では、管理者権限を持つIDの一覧を作る、共有パスワードをやめる、クラウドの管理者ロールを常時付与しない、の3つから始めれば、費用をかけずに監査で説明できる状態に近づけます。

クラウドだけの環境でも特権ID管理は必要ですか？

必要です。クラウドではAWSのルートユーザーやEntra IDのグローバル管理者が最も強い特権IDになり、画面から誰でも権限を付け外しできるぶん、放置するとオンプレミスより早く権限が増えます。AWSが公式に推奨しているのは、ルートユーザーのアクセスキーを作らないことや、パスワードとMFAを別の人が持つ運用です。Microsoft 365中心ならEntra IDのPIM、AWS中心ならIAM Identity Centerの権限セットで期限付きの付与を組みます。

保守ベンダーに特権IDを貸すときは何に注意すればよいですか？

作業者ごとに個別のIDを発行し、共有IDを渡さないことが第一です。そのうえで、作業ごとに申請と承認を通し、権限の有効期限を作業日に限定します。作業後に行うのは、パスワードの変更と、委託元による操作記録の確認です。IPAのガイドラインは、委託先の従業員に権限を付与する場合に契約上の措置が必要としており、異動や退職の報告義務を契約に入れておくとIDの削除漏れを防げます。