特権アクセス管理(PAM)の作り方。管理者権限を金庫に入れて必要なときだけ貸し出す

インシデント調査の報告書を読んでいると、同じ一文に何度も出会います。攻撃者は正規のアカウントでログインしていた、というものです。MITRE ATT&CKが「Valid Accounts」(T1078)を独立したテクニックとして扱っているのは、盗まれた正規の資格情報が初期侵入、永続化、権限昇格、防御回避という複数の段階で同時に使えてしまうからです。そして、その資格情報がドメイン管理者やrootのものであれば、攻撃者は侵入した瞬間から管理者として振る舞えます。

多くの組織では、運用担当者の日常アカウントに管理者権限が付いたままになっています。理由は単純で、その方が仕事が速いからです。ところがこの「常時保有」は、端末がマルウェアに感染した瞬間、あるいは担当者がフィッシングに引っかかった瞬間に、そのまま組織全体の管理権限の喪失に変わります。

特権アクセス管理(PAM: Privileged Access Management)は、この構図を「権限を人に固定して持たせる」から「権限を金庫に預け、必要なときだけ期限付きで貸し出す」に変える運用の仕組みです。この記事では、何を金庫に入れるのか、どう貸し出すのか、貸し出した記録をどう残すのかを、Windows、Linux、クラウドそれぞれの具体策とあわせて設計手順の形で整理します。

特権アカウントとして棚卸しすべき対象#

PAMの設計は、守る対象の定義から始まります。NISTの用語集は特権アカウントを、一般利用者には許されない操作を実行できる権限が与えられたアカウントとして定義しています。この定義に従うと、対象は人が使う管理者IDだけにとどまりません。実務で棚卸しの漏れが起きやすいのは次の7種類です。

CIS Critical Security Controlsも、この棚卸しを出発点に置いています。Control 5「Account Management」のセーフガード5.1はすべてのアカウントの台帳の整備を、5.5はサービスアカウントの台帳の整備を、5.4は管理者権限を専用の管理者アカウントに限定することを求めています。台帳と専用アカウント化が別々のセーフガードとして並んでいる点は、実務の順序をそのまま示しています。まず数えて、次に分ける、という順です。

権限そのものをどこまで絞るかという一般論は別の記事で扱っています。ここでは絞りきれない管理権限をどう預けるかに焦点を当てます。

あわせて読みたい

最小権限の原則（Least Privilege）。なぜ権限を絞ることが最強の防御の一つなのか

常時保有が侵害を連鎖させる仕組み#

「管理者権限を普段から持っていると危ない」という説明は、機構まで降りると納得しやすくなります。危険の一つは、権限を使った端末に再利用できる認証材料が残ることにあります。有効なセッションやアクセストークンがそのまま使われる経路もあるため、材料の抽出だけが問題というわけではありません。

Windowsドメインの場合、管理者アカウントでサーバや端末にログオンすると、その端末のメモリ上に認証に使える材料が残ります。攻撃者がその端末で管理者権限を取ると、材料を抜き出して別のサーバへの認証に流用できます。MITRE ATT&CKはこれをPass the Hash(T1550.002)として整理しており、平文パスワードを知らなくてもハッシュ値だけで認証を通せる点が特徴です。つまり、ドメイン管理者が一般利用者の端末で一度作業しただけで、その端末の侵害がドメイン全体の侵害に変わり得ます。

Kerberos環境ではもう一つの経路があります。SPNが設定されたアカウントに対しては、認証済みの一般ドメインユーザーであればサービスチケットを要求できます。応答に含まれるサービス側の部分が、当該アカウントのパスワードから導かれる長期鍵で暗号化されているため、攻撃者はこれを持ち帰り、オフラインでパスワードの推測を試みられます。MITRE ATT&CKのKerberoasting(T1558.003)がこれにあたり、弱いパスワードの高権限サービスアカウントがあると、一般利用者の権限しかない攻撃者でも特権を得る糸口になります。

あわせて読みたい

Kerberoastingとは何か。サービスアカウントの弱いパスワードが狙われる仕組みと対策

もう一つの問題は、技術ではなく責任追跡の側にあります。rootや共有のAdministratorのように、複数人が同じ資格情報を使う運用では、ログに残るのは「rootが実行した」という事実だけで、誰が実行したのかは残りません。IPAの「組織における内部不正防止ガイドライン」は、内部不正への対策を組織の管理面と技術面の双方から整理しており、アクセス権限の管理と記録の取得を対策の柱として扱っています。行為が個人に結びつく形で記録されることは、事後の追跡だけでなく抑止としても働きます。共有アカウントは、その両方を同時に失わせます。

因果を一文でまとめると次のようになります。常時保有は、侵害された1台に高権限の認証材料を置き続けることと同義であり、共有アカウントは、その材料が使われたときに誰の行為かを判別できなくします。PAMは、この2つを「保有させない」ことと「個人に紐づけて貸し出す」ことで同時に断ちます。

PAMを構成する6つの仕組み#

製品カタログを読む前に、PAMという言葉が指す機能の内訳を押さえておくと、自組織にどれが必要かを判断できます。

1. 資格情報の保管(ボールト)。管理者パスワードやSSH秘密鍵、APIキーを人の手元から引き上げ、暗号化された保管庫に集約します。人はパスワードを知らない状態が理想形です。
2. 払い出しと自動ローテーション。利用申請に応じて一時的にパスワードを開示し、返却または期限到来のタイミングで自動的に変更します。使い終わった資格情報が生き続けないことが要点です。
3. ジャストインタイム(JIT)昇格。権限を恒久的に割り当てず、必要な時間だけ有効化します。Microsoft Entra Privileged Identity Managementの「対象(eligible)」割り当てはこの考え方の実装で、利用者は役割を持っていても、有効化するまで権限が働きません。
4. セッションの仲介と記録。管理対象に直接つながせず、踏み台(ゲートウェイ)経由に限定し、操作を記録します。RDPやSSHの操作記録は、事後調査と抑止の両方に効きます。
5. 承認ワークフロー。高リスクの権限については、申請に対する承認者の許可を条件にします。承認は形式ではなく、承認者が拒否できる情報(対象システム、作業内容、時間帯)を伴って初めて機能します。
6. 監査証跡。誰がいつ何の権限を借り、何をしたかを、改ざんされにくい形で残します。NIST SP 800-53 Rev.5のAC-6(9)「Log Use of Privileged Functions」は、特権機能の使用をログに記録することを制御項目として明示しています。

この6つは独立ではなく、順番に効いてきます。保管がなければ払い出しの起点が作れず、払い出しがあってもローテーションがなければ開示されたパスワードが残り続け、記録がなければ承認の妥当性を後から検証できません。NIST SP 800-53 Rev.5では、関連する制御がAC-2(アカウント管理)、AC-5(職務分離)、AC-6(最小権限)とその強化項目、AU-2(イベントのログ記録)、AU-12(監査レコードの生成)、IA-5(認証子の管理)に分かれて置かれています。制御番号を追うと、PAM製品が1つの箱でまとめて提供しているものが、本来は別々の統制の集合だと分かります。

最小権限の強化項目には、非セキュリティ機能には非特権アカウントを使うAC-6(2)、特権アカウントの割り当てを限定するAC-6(5)、利用者権限を定期的に見直すAC-6(7)、特権機能の使用を記録するAC-6(9)が含まれます。PAMの要件を自組織の統制項目に落とすときの下敷きになります。

導入の順序#

一度にすべてを金庫に入れようとすると、業務が止まるか、例外だらけになって形骸化します。順序を決めて段階的に進める方が確実です。

Windows環境で先に効く手当て#

Active Directory環境では、製品導入の前にやれることが多く残っています。

第一にローカル管理者パスワードのランダム化です。全端末のAdministratorパスワードが同一だと、1台の侵害が全台の侵害に直結します。Windows LAPSは、ローカル管理者アカウントのパスワードを端末ごとに自動生成してローテーションし、Active DirectoryまたはMicrosoft Entra IDに保管する仕組みです。保管された値の読み取り権限はアクセス制御で委任でき、必要な担当者だけが取り出せます。人がパスワードを知らないまま運用できるという点で、ボールトと払い出しの一部を製品なしで近似できます。ただしWindows LAPSが持つのは生成と保管とローテーションと読み取りの委任までで、申請と承認を伴うチェックアウトや、セッションの仲介と記録は提供しません。保管先は端末の参加形態で決まり、Active DirectoryとMicrosoft Entra IDの両方へ同時に保管することはできません。なお、これは旧来のMicrosoft LAPSとは別の実装です。

第二に管理用の経路を分けることです。Microsoftは特権アクセスの保護に関する文書群で、管理作業を行う端末を一般業務の端末と分離する特権アクセスワークステーション(PAW)の考え方と、従来の階層モデル(Tierモデル)を置き換えるものとしてエンタープライズアクセスモデルを示しています。要点は、高権限の資格情報を、メールやWeb閲覧を行う端末に触れさせないことです。Pass the Hashの経路は「高権限で低信頼の端末にログオンする」ところで生まれるため、ここを断つと横展開の道筋が1つ消えます。

第三に、資格情報がメモリに残る条件を減らすことです。Active Directoryには保護されたユーザー(Protected Users)というセキュリティグループがあり、メンバーに対しては変更できない制限が自動で適用されます。ドメイン側ではNTLM認証が使えなくなり、KerberosのDESとRC4も使えなくなるため、対象アカウントはAESでの認証に対応している必要があります。制約なし委任と制約付き委任の両方が禁止され、TGTの有効期間は240分に固定されて延長できません。端末側ではWindows Digestや資格情報の委任が平文の資格情報を保持しなくなり、オフラインサインインも使えなくなります。管理者アカウントをこのグループに入れると、認証材料の再利用が難しくなります。ただし副作用で動かなくなる運用があるため、検証環境で確認してから段階的に適用します。

JPCERT/CCは「ログを活用したActive Directoryに対する攻撃の検知と対策」で、攻撃の各手法に対してどのイベントログのどの項目を見るべきかを整理しています。金庫に入れる作業と並行して、特権の使用が記録されているかを確認しておくと、後の点検が成立します。

あわせて読みたい

Active Directoryセキュリティの基礎。侵入後の横展開を止める防御設計

Linuxのsudoとsshで権限を貸し出す#

Linuxサーバでは、rootの共有パスワードをやめることが最初の一歩です。個人アカウントでログインし、必要な操作だけをsudo経由で実行する形にすると、操作の実行者が記録に残ります。

sudoの設計で効くのは、rootへの全面昇格を配らず、必要なコマンドだけを許可することです。sudoersでは利用者やグループごとに実行可能なコマンドを指定でき、実行の記録はビルド時の既定やsudoersの設定に応じてsyslogまたは専用のログファイルへ出ます。どのコマンドが実行されたかの記録と、操作の入出力そのものの記録は別で、後者を残すにはI/Oロギングの設定が要ります。いずれの記録も、ローカルに置いたままでは消される前提で、外部へ転送しておきます。ただし、許可したコマンドがシェルを起動できる(エディタからのシェル脱出や、任意コマンドを引数に取るユーティリティなど)場合、実質的にroot全面昇格と変わりません。許可リストを作るときは、そのコマンドから別のプログラムを起動できるかどうかを必ず確認します。

sshの側では次の3点が土台になります。

• パスワード認証を止め、公開鍵認証に寄せる。鍵にはパスフレーズを設定し、秘密鍵は管理用端末の外に出さない。
• rootでの直接ログインを禁止する。sshdの設定でrootログインを拒否し、昇格はsudoに一本化する。
• 台数が増えたら証明書ベースの認証に移行する。各サーバに公開鍵を配り続ける運用は、退職や異動のたびに全台から鍵を消す作業を生みます。認証局を立てて短期の証明書を発行すれば、有効期限が切れることで自動的にアクセスが消えます。期限付きの貸し出しという発想を、鍵配布の仕組み側で実現する方法です。

あわせて読みたい

SSHサーバのハードニングと鍵の運用

踏み台サーバを1台置き、そこを経由しないと管理対象に到達できないネットワーク構成にすると、セッションの仲介と記録を製品なしで近似できます。踏み台では入退室記録にあたるログ(誰がいつどこへ接続したか)を残し、踏み台自体を高リスク資産として扱います。踏み台が落ちると管理作業が全部止まるため、冗長化と、後述する緊急用の代替経路を必ず用意します。

クラウドのルートアカウントと期限付き権限#

クラウドでは、最上位アカウントの扱いが最初の分岐点になります。AWSのルートユーザーのように、契約と課金に紐づき、通常の権限設定では制限しきれない特別なアカウントは、日常運用で使わないことが前提です。単独のアカウントではルートユーザーの権限を縮小できませんが、AWS Organizationsに参加しているメンバーアカウントについては、ルートアクセスを一元管理する設定を有効にすることで、ルートユーザーのパスワードとアクセスキーと多要素認証を削除し、ルートでのサインインとパスワード復旧をできない状態にできます。AWSの「ルートユーザーのベストプラクティス」は、ルートユーザーを日常的なタスクに使わないこと、多要素認証を有効にすること、ルートユーザーのアクセスキーを作らないことを挙げています。実務では、多要素認証のデバイスとパスワードを物理的に施錠保管し、開封の記録を残す運用にすると、金庫の考え方と整合します。

日常の管理作業は、恒久的な権限を持たせず、役割を引き受ける方式に寄せます。利用者には最小限の権限だけを与え、作業時に管理用ロールを引き受けて、一定時間で自動的に権限が切れる構成にすると、資格情報が漏れても有効期間が限られます。NIST SP 800-207が示すゼロトラストの原則の1つは、リソースへのアクセスをセッション単位で許可するというものです。期限付きのロール引き受けは、この原則を権限管理の側で実装したものと読めます。

Microsoft Entra IDでは、Privileged Identity Managementで役割を「対象」として割り当て、利用時に有効化させる方式が使えます。有効化の際に理由の入力、承認、多要素認証、最大有効期間を条件として設定でき、有効化のたびに通知と監査ログが残ります。恒久的に割り当てられた管理者を減らし、必要なときだけ有効化する形に移すことで、常時保有のリスク面積が縮みます。

権限のドリフト、つまり付けたまま外されない権限の蓄積も、クラウドでは見えにくい問題です。対策は2つあります。1つは付与時に期限を必ず入れること、もう1つは実際に使われた権限と付与された権限の差分を定期的に確認することです。主要なクラウドには、一定期間使われていない権限や、最終利用日時を可視化する仕組みがあります。使われていない権限は、次の棚卸しで削る候補として扱います。

サービスアカウントを止めずにローテーションする#

PAMの導入でもっとも事故が起きやすいのがサービスアカウントです。人が使わないため影響範囲の把握が難しく、パスワードを変えた瞬間に夜間バッチが止まる、といった事態になりがちです。

安全に進める手順は次の通りです。まず、そのアカウントの資格情報がどこに書かれているかを全部特定します。設定ファイル、スケジューラの登録情報、アプリケーションの接続文字列、他システムの連携設定まで含めて洗います。次に、参照箇所を1つの秘密情報管理の仕組みに寄せ、アプリ側がファイル直書きではなく取得して使う形にします。この段階まで来て初めて、ローテーションが安全に自動化できます。

あわせて読みたい

シークレット管理の実務。APIキー・認証情報をハードコードせず、Vaultやマネージドサービスで守りローテーションする

クラウドのサービスアカウントについては、長期の鍵を作らない方向に寄せるのが本筋です。Google Cloudのサービスアカウントに関するドキュメントは、サービスアカウントキーは漏えいリスクを伴う長期の資格情報であり、可能な場合は他の認証手段を使うよう推奨しています。実行環境にアイデンティティを付与して短期のトークンを取得させる方式であれば、ローテーションという運用自体が不要になります。

どうしても長期の資格情報が必要な場合は、次の3点を決めておきます。ローテーションの周期、ローテーション時の切り替え方式(新旧の資格情報を一時的に併存させて切り替えるか、停止時間を取るか)、そして失敗時の切り戻し手順です。これを決めずに周期だけ決めると、1回目のローテーションで障害が起き、その後は例外扱いのまま放置されます。

緊急用アカウントの設計と開封の検知#

PAMを厳しくするほど、仕組みが壊れたときに誰も入れなくなるリスクが上がります。多要素認証の基盤が落ちる、条件付きアクセスの設定を誤る、ボールト自体が障害を起こすといった場合に備えて、緊急用(break-glass)アカウントを用意します。

Microsoftは緊急アクセス用アカウントの管理について、通常の運用担当者と紐づかないクラウド専用のアカウントを複数用意し、条件付きアクセスなどの一般ポリシーの対象から除外し、使用された場合に検知できるようにすることを推奨しています。設計の要点を整理すると次のようになります。

緊急用アカウントで最も多い失敗は、作ったまま一度も検証せず、いざというときにパスワードが期限切れだったり、保管場所を知る人が退職していたりするパターンです。Microsoftは少なくとも90日ごとの検証を挙げており、認証に使う機器の所在と、使用を許可された担当者の一覧の見直しも検証の対象に含めています。四半期ごとの定例作業に入れておくと、この種の劣化を防げます。開封検知については、ログイン成功だけでなく、封緘の物理的な確認(封筒の状態、金庫の入退室記録)も併せて点検対象にします。

製品を買わずに始める現実解と、その限界#

PAM製品は高額になりがちで、中小規模の組織ではすぐに導入できないことがあります。ただし、前述の6要素のうち相当部分は既存の機能で近似できます。

この表の右列が、製品を検討する判断材料になります。手作業で回している部分が増え、付け外し漏れや点検の遅延が実際に起きているなら、そこが投資対象です。逆に、対象システムが数台で担当者も少ないなら、踏み台とLAPSとsudoポリシーだけで実質的なリスク低減は得られます。

あわせて読みたい

入社から退職までアカウントを人事イベントに同期させる運用の作り方

製品なしで進める場合でも、ログの集約だけは先に整えることを勧めます。特権操作の記録が各機器の中にしか残っていない状態では、機器を侵害された時点で証拠も失われます。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

運用が形骸化する3つの兆候#

導入したPAMが1年後に機能しなくなるとき、原因はだいたい次の3つのどれかです。

1つ目は、記録が誰にも読まれないことです。セッション記録を取っていても、点検の担当者と頻度と観点が決まっていなければ、ディスクを消費するだけの資産になります。全件を見る必要はありません。承認なしの昇格、営業時間外の特権利用、普段と違う端末からの払い出しといった、少数の観点に絞って定期的に見る方が続きます。

2つ目は、例外が恒久化することです。導入直後は「このバッチだけは当面そのまま」という例外が必ず出ます。問題は、期限と解消の責任者を決めずに例外を認めることです。例外には有効期限を必ず付け、期限が来たら自動的に失効し、継続したければ再申請させる形にします。台帳に「例外の件数と平均経過日数」を書いておくと、増えていることに気づけます。

3つ目は、正面の手順が遅すぎることです。緊急対応で権限が必要なのに申請から30分かかるなら、運用担当者は日常アカウントに権限を戻すか、緊急用アカウントを平時に使い始めます。仕組みが迂回される原因は利用者の意識ではなく、手順の設計にあります。高リスクの操作にだけ承認を要求し、それ以外は自己申請で即時有効化にするなど、リスクに応じて摩擦を配分してください。

なお、権限の設定や認証の挙動を検証する作業は、自組織が管理し許可を得た環境に限って行ってください。他者の管理するシステムに対して権限昇格や認証の試行を行うと、不正アクセス禁止法などの法令に触れる可能性があります。検証時は対象範囲と実施期間を事前に文書化し、関係者の承認を得たうえで実施することを勧めます。

まとめ#

特権アクセス管理は、製品を入れることではなく、権限を人から切り離して仕組みに預ける運用への転換です。棚卸しで対象を数え、影響度で分類し、高リスクから金庫に入れ、恒久付与を期限付き昇格に置き換え、記録を読む担当と頻度を決める。この順序で進めれば、製品の有無にかかわらずリスクは確実に下がります。

技術面では、Windowsのローカル管理者パスワードのランダム化、管理経路の分離、Linuxのroot直接ログイン禁止とsudoの限定許可、クラウドのルートアカウントの封印と期限付きロール引き受けが、投資対効果の高い着手点です。運用面では、例外に期限を付けること、緊急用アカウントを検証し続けること、記録を少数の観点で定期的に見ることが、仕組みを生かし続ける条件になります。