# 管理者用アカウント(特権 ID)の管理

管理者用アカウント(特権 ID)は、サービスの設定や他の人の権限を変えられる強い権限の ID です。個人に分けられる権限は分け、残る共有の管理者アカウントは誰が使ったかを残せる形にします。

更新日: 2026-09-18

管理者用アカウントの管理で決めることは 3 つです。誰に管理者の権限を持たせるか、共有のまま残る管理者アカウントを誰にどう使わせるか、そして使った記録をどう残すかです。

## 管理者用アカウントとは何か

管理者用アカウント(特権 ID)とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サービスの設定を変える、他の人のアカウントや権限を変える、契約や支払いを変える、といった操作ができます。サーバーの管理者だけでなく、クラウドや SaaS(インターネット経由で使う業務ソフト)の管理者アカウント、ドメインや決済の管理画面の ID も含みます。定義と範囲は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)にまとめています。

## なぜ複数人で共有されがちか

共有される理由は、アカウントの作りと使い方の 2 つに分けて考えられます。

作りの理由は、人数分のアカウントを作れないことです。管理者アカウントを 1 つしか作れないサービスがあり、使う人が複数いれば共有になります(例は[特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id)に挙げています)。ID 管理サービスとつなげない管理画面も同じです。ID 管理サービスとは、Okta や Microsoft Entra ID のことです。社員のアカウントをまとめて管理し、一度のログインで複数のサービスに入れるようにします。個人の ID ではログインできないため、管理画面の ID とパスワードを複数人で使うことになります。ドメインや決済の管理画面をつなげられるかは、サービスごとに公式ヘルプで確認します。

使い方の理由の例は当番制です。夜間や休日の対応を交代で受け持つ運用では、その時間の担当者が同じ管理者アカウントで入ります。この運用は珍しくないでしょう。退職時のパスワード変更や、誰が操作したか残らないといった共有アカウント一般の問題は、[共有アカウントの管理](/guides/shared-accounts)で扱っています。管理者用アカウントにもそのまま当てはまります。

## 何が問われるか

管理者用アカウントで問われるのは、誰が・いつ・何をしたかを出せるかです。金融庁の「金融分野におけるサイバーセキュリティに関するガイドライン」は、2.3.1「認証・アクセス管理」に基本的な対応事項を並べています。そこでは、特権アカウント(管理者用アカウント)の利用を厳格に制限し、管理すること(使える人と場面を絞り、使い方を決めておくこと)を求めています。同じ 2.3.1 の別の項目で、アクセスした人を特定できるようにし、処理内容を記録して操作した人と対応づけることも求めています。金融機関向けの文書ですが、管理者用アカウントに何を求めるかの整理として読めます。政府機関向けの「政府機関等の対策基準策定のためのガイドライン」(令和 7 年度版)にも、クラウドサービスの利用の基準(要機密情報を扱う場合の基準)があります。管理者権限を利用者に持たせる場合に、アクセス管理と操作の確実な記録を求めています。

上場企業の内部統制報告(J-SOX)では、IT 全般統制(会計の数字を作るシステムを支える土台の管理)に関わります。金融庁の「財務報告に係る内部統制の評価及び監査の基準・実施基準」は、IT 全般統制の例に「内外からのアクセス管理などシステムの安全性の確保」を挙げています。実施基準に特権 ID という語はありません。管理者用アカウントの扱いは、このアクセス管理の中で確かめられると読めます。

## 管理の選択肢

共有のまま残る管理者アカウントを複数人で使う方法は、4 つに分けられます。

| 方法 | できること | 残る限界 | 向く場面 |
| --- | --- | --- | --- |
| 台帳と貸出の記録 | 誰がいつ借りたかを台帳に書く | 返した後も、借りた人はパスワードを知っている | 使う人が数人 |
| ID 管理サービスが代わりに入力 | パスワードを見せずに使わせ、誰がいつ入ったかをサインインの記録に残す | 対象は ID 管理サービスにアカウントのある人 | 使う人が全員 ID 管理サービスにアカウントを持つ |
| 特権 ID 管理(PAM)の製品 | 利用の申請と承認、権限の付与、操作の記録を 1 つの仕組みで行う | サーバー中心か、ブラウザーで使う管理画面も含むかは製品ごとに確認する | 使う前に申請と承認を置く |
| パスワードを見せずに使わせる仕組み(アクセス管理ツール) | 担当者に代わってパスワードを入力し、本人確認した人ごとに利用を記録する | 対象アプリと端末の条件は製品ごとに確認する | ID 管理サービスにアカウントのない人も使う |

台帳は道具なしで始められますが、記録は自己申告になります。操作の記録をサービス側で出せるアカウントに向きます。ID 管理サービスが代わりに入力する機能は、Okta では SWA、Microsoft Entra ID では password-based SSO という名前で、預かったパスワードを権限のある人に代わりに入力します。Entra ID は、利用者ごとに EMS または P1/P2 の契約プランが前提です。特権 ID 管理の製品は、サーバーの管理者 ID も同じ仕組みで扱いたいときに向きます。アクセス管理ツールは、本人単位の記録が要るときに向きます。

4 つはどれか 1 つを選ぶものではなく、アカウントごとに組み合わせられます。特権 ID 管理(PAM)の中身は[特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam)にまとめています。パスワードマネージャーで共有する方法は[共有アカウントの管理](/guides/shared-accounts)で扱っています。

## 既存の ID 管理サービスとの関係

Okta や Microsoft Entra ID を使っている会社でも、上の選択肢は ID 管理サービスを置き換えるものではありません。社員一人ひとりの ID と、ID 管理サービスに認証を任せられるアプリへのログインは、これまでどおり ID 管理サービスが受け持ちます。入退社に合わせたアカウントの作成・削除も同じです。その外に残るのが、1 つしか作れない管理者アカウント、つなげない管理画面、ID 管理サービスにアカウントのない人(短期の担当者や社外の技術者)です。全員に個人アカウントを発行でき、対象のサービスがすべてつながるなら、ID 管理サービスだけで足ります。残るものがあるときに、残る分だけを上の表から選びます。

## 何から始めるか

管理者用アカウントの一覧を作るところから始めます。サービス名、管理者権限を持つ ID、1 つしか作れないものか、ID 管理サービスとつながるか、いま使っている人、緊急時にだけ使うものかを書き出します。誰に権限を持たせるかと、共有のまま残るものをどう扱うかは、この一覧を見て決めます。

次に、個人に権限を与えられるものは個人に分けます。Google Workspace の公式ヘルプは、特権管理者を少なくとも 2 人置くよう勧めています。1 人がパスワードを忘れても、もう 1 人が再設定できるためです。Microsoft 365 の公式ドキュメントは、グローバル管理者(Microsoft 365 の最上位の管理者)をできるだけ少なくするよう勧めています。作業に必要な最小の権限の種類を与えることも勧めています。同時に、グローバル管理者が締め出されたときにパスワードを戻せる管理者を置くことも勧めています。AWS は、ルートユーザーを日常の作業に使わず、ルートユーザーにしかできない作業に限るよう勧めています。個人の ID に必要な範囲の管理者権限を付けられるサービスでは、この形にすれば共有はなくなります。

最後に、それでも残る共有の管理者アカウントの扱いを決めます。使う人が全員 ID 管理サービスにいるか、本人単位の記録が要るか、サーバーの管理者 ID も同じ仕組みで扱うかで、上の表から選びます。普段は使わない予備のアカウント(緊急用アカウント)は、日常の共有アカウントとは分けて、保管の場所と使ったときの見直しを決めます。考え方は[緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account)にまとめています。


## このテーマの記事

- [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](/guides/privileged-access/aws-root-and-admin-accounts): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。
- [SaaS の管理者用アカウントを管理する方法の比較](/guides/privileged-access/comparison-of-privileged-account-methods): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。
- [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](/guides/privileged-access/google-workspace-microsoft-365-admins): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。
- [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](/guides/privileged-access/idp-and-remaining-shared-admins): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。
- [IT 全般統制(J-SOX)で管理者用アカウントについて問われること](/guides/privileged-access/itgc-and-privileged-ids): 実施基準は「内外からのアクセス管理」を IT 全般統制の例に挙げ、評価は記録の閲覧や質問で行われます。用意するのは、管理者用アカウントの一覧、権限の付与・変更・削除の記録、利用の記録、定期的な見直しの記録です。
- [ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか](/guides/privileged-access/non-saml-admin-consoles): まず公式ヘルプで、担当者ごとの ID を追加できるか、権限を分けられるかを確かめます。追加できるなら個人の ID にし、1 つしか作れないものは共有として貸出の記録、二段階認証の宛先、パスワードを変える場面を決めます。
- [管理者用アカウントの監査で示せるようにしておく記録](/guides/privileged-access/privileged-access-audit-records): 公的な資料が求めるのは、誰が・いつ・どのアカウントで・何をしたかがつながる記録と、権限の付与・削除と見直しの記録です。金融庁、内閣官房、IPA の 4 つの文書は、改ざんの防止と定期的な点検も共通して求めています。
- [緊急用アカウント(ブレークグラス)とは](/guides/privileged-access/what-is-break-glass-account): 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。
- [特権 ID 管理(PAM)とは](/guides/privileged-access/what-is-pam): 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。
- [特権 ID(管理者用アカウント)とは](/guides/privileged-access/what-is-privileged-id): 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。

## よくある質問

**管理者アカウントを 1 人だけが持つのは安全ですか**

その人がパスワードを忘れたり締め出されたりしたときに、戻せる人がいなくなります。Google Workspace は特権管理者を 2 人以上置くよう勧め、Microsoft 365 も戻せる人を置くよう勧めています。

**特権 ID の監査では何を出すよう求められますか**

金融庁のガイドラインは、特権アカウントの利用の制限と、アクセスした人を特定して操作内容と対応づけた記録を求めています。誰が・いつ・何をしたかを出せる状態が目安です。

**Okta や Entra ID があれば特権 ID の管理は済みますか**

全員に個人の ID を発行でき、対象のサービスがすべて ID 管理サービスとつながるなら足ります。1 つしか作れない管理者アカウントや、つなげない管理画面が残るときは、その分の管理方法を別に決めます。

**PAM の製品は SaaS の管理画面にも使えますか**

IPA のガイドラインでは、特権 ID 管理は特権の利用申請・権限付与・操作の記録を管理する技術です。サーバー中心か、ブラウザーで使う管理画面も対象かは、製品ごとに公式ドキュメントで確認します。

## 参考資料

- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf)
- [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」(令和 6 年 10 月 4 日)](https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf)
- [内閣官房 国家サイバー統括室「政府機関等の対策基準策定のためのガイドライン(令和 7 年度版)」](https://www.cyber.go.jp/pdf/policy/general/guider7_9.pdf)
- [金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」(2023 年 4 月 7 日改訂)](https://www.fsa.go.jp/singi/singi_kigyou/kijun/20230407_naibutousei_kansa.pdf)
- [Microsoft Learn「Sharing accounts and credentials - Microsoft Entra ID」](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts)
- [Microsoft Learn「About administrator roles in the Microsoft 365 admin center」](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles)
- [AWS Identity and Access Management ユーザーガイド「AWS account root user」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
- [Google Workspace 管理者ヘルプ「Pre-built administrator roles」](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles)

## Junify の場合

**人手で続けると** 管理者用アカウントを誰に持たせるかを申請と承認で回し、共有のまま残るものは使うたびに記録し、その記録を管理者以外が定期的に点検することになります。

**Junify なら** Junify は、管理コンソールのパスワードを、使う人が誰も知らない状態にする仕組みです。管理者が ID とパスワードを登録して担当者に割り当て、担当者は自分のスマホで本人確認をしてクリックするだけでログインします。誰が・いつ・どのコンソールに入ったかは一人ひとり残り、退職時は管理者が割り当てを外すだけです。Okta や Entra ID はそのままで、IP 制限も外しません。

Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

- [登録不要の体験デモを見る](https://www.junify.jp/bpo/try)
- [30 分デモを予約する](https://www.junify.jp/bpo/demo)