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

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

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

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

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

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

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

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

何が問われるか

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

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

管理の選択肢

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

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

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

既存の 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 も同じ仕組みで扱うかで、上の表から選びます。普段は使わない予備のアカウント(緊急用アカウント)は、日常の共有アカウントとは分けて、保管の場所と使ったときの見直しを決めます。考え方は緊急用アカウント(ブレークグラス)とはにまとめています。