CSAジャパン 諸角 昌宏
特権的なアクセス権限は、ユーザーに異なる役割が割り当てられるあらゆる環境でセキュアに管理する必要がある。適切なコントロールが講じられていない場合に、組織は内部での不正利用や外部からの脅威に曝される。このような状況において、PAM（特権アクセス管理、Privileged access management）の重要性が高まっている。
本ブログでは、PAMの現在の位置づけを整理した上で、CSA本部が「クラウドファースト時代における特権アクセス管理、Managing Privileged Access In a Cloud-First World」として公開した資料に基づいて、クラウドファースト環境における特権アクセス管理のベストプラクティスについて解説する。
PAMとは？
まず、PAMの定義を明確にしたい。PAMというと、どうしても製品のイメージが強い。また、PAMの日本語訳である「特権アクセス管理」という言葉から考えられるのは、管理者が使用する特権アカウントをいかにセキュアにするか、つまり、特権を付与されているアイデンティティとアクセス管理を行う製品というイメージになる。しかしながら、WikipediaでPAMを検索すると、「Privileged access management（略称:PAM、別名:特権アクセス管理）は、組織内の特権アカウントの制御、監視、保護に焦点を当てたサイバーセキュリティ上重要なアイデンティティ管理である」としている。ここで「アイデンティティ管理」という部分については上記の特権アカウントの管理ということになるが、「組織内の特権アカウントの制御、監視、保護に焦点」を当てるという部分があり、単なる認証/認可だけではなく特権アクセスのセキュリティ統制を含んでいるといえる。そうすると、PAMを製品として捉えるのではなく、特権アクセスを付与・利用・監視・記録・不要になった場合の無効化を総合的に行うための統制モデルと考える必要がある。
また、Gartnerは、PAMが必要な機能としてJust-In-Time（JIT）や Zero Standing Privileges（ZSP）という用語を使っており、特権というのは常設されるべきでなく、必要な瞬間に付与し必要無くなったら直ちに削除するということを要件としている。
また、PAMと関連する用語としてIAM 、IGA、CIEMがあるが、これらとPAMとの違いは、IAM 、IGA、CIEMが「誰にどの権限を持たせるか」を管理するのに対して、PAMは「その権限をいつ、どのように使わせるか」を管理すると考える必要がある。 以上のことから考えて、PAMは、特権アクセスに対して、最小特権、時間制限、制御および監視を適用するセキュリティ統制であると考えるのが妥当である。その上で、PAM製品はその概念を技術的に実装する手段という位置づけになる。
PAMの背景
「クラウドファースト時代における特権アクセス管理」において、特権アカウントは侵害において常に最も標的とされ最も深刻な被害をもたらす攻撃経路であると記述している。その理由として以下の点が挙げられている。
- ガートナー社の調査によれば、インシデントの50％以上が、アイデンティティ、アクセス、特権の管理不備に起因している。
- ベライゾン社のData Breach Investigations Report（DBIR）によると、データセキュリティインシデントの80％が、侵害または悪用されたクレデンシャル（特権・非特権を含む）に関連していることが統計で示されている。
このように、特権アカウントあるいは特権を持っていることがデータ侵害に大きく影響していることがわかる。では、特権というものが厳密に管理されていればデータ侵害は起こらないのだろうか？理論的には以下の4つの前提がすべて満たされれば外部攻撃によるデータ侵害は極めて成立しにくいと言える（ここでは、外部からのデータ侵害に絞って考える）。
- アカウント侵害ができない
- 権限昇格が不可能である
- 過剰権限が存在しない
- 認可・設計・設定・運用が正しい
しかしながら、現実のシステムではこの前提がほぼ崩れることになる。その理由は、設計・運用が「常に」維持できるものではなく、システム・人間・環境が「時間とともに変化する」からだということができる。変化により「正しかった設計」が「不正確」になってしまう。緊急対応での一時設定、トラブル回避の例外措置、手作業の微調整などにより、設定が意図せずドリフトする。業務優先のショートカット、「今回はいいだろう」という対応、引き継ぎ漏れ・理解不足などにより人間は必ず逸脱を引き起こしてしまう。また、使われていないアカウント、放置されたAPIキー、シャドーアカウントなどにより、存在を認識していないものは管理できないという可視性の問題も起こる。 このような設計・運用が「常に」維持できないという問題は、監査で確認することが求められているが、それをさらに確実にしていくには、自動化と継続的なモニタリングが必要であり、特権アカウントや特権アクセスが慎重に管理され、状況が認識されることが必要になる。これを支援するのがPAMの役割と考える。また、最小特権および時間制限という観点から、PAMは、ユーザーに業務に必要な最小限のアクセス権のみを、必要な期間のみ与えるための機能を提供することが必要になる。
効果的なPAMによるコントロール
PAMによるコントロールとして以下の点が必要となる。
- 最小特権（Least Privilege）
最小特権の原則をデフォルトで強制する。人/非人間の双方に、必要な権限のみを付与し、それ以上の権限は付与すべきではない。 - 必要な期間のみ（Just In Time、JIT）
特権は恒常的に付与せず、永続的な特権アカウントからジャストインタイム（JIT）や時間制限付きアクセスモードへ移行する。 - ポリシー駆動（Policy-based Control）
特権アクセスは事前定義されたポリシーに基づいて制御する。裁量ではなく、ポリシーに基づいて制御する。 - 自動化（Automation）
特権の付与・剥奪・管理プロセスは自動化する。未使用または期限切れのアカウントには自動失効機能を適用する。 - 継続的モニタリング（Continuous Monitoring）
特権アクセスの利用状況は継続的に監視・記録する。継続的にモニタリングし、新たに作成された特権アカウント、役割の変更、または予期せぬ特権の昇格を検出する。
「特権は恒常的に付与しない」は可能か？
ここでは、「クラウドファースト時代における特権アクセス管理」には記述されていないが、PAMによるコントロールを整理する中で気になった点として「特権は恒常的に付与しない」ということが可能なのかという点について考察してみる。
特権を恒常的に付与しないことは、攻撃に可能な時間と影響範囲を最小化できるため重要である。恒常的な特権付与は、アカウント侵害時に即座に高権限を悪用されるリスクを内包するため、攻撃可能時間が無限になり、また特権取得を明確な監査イベントとして管理することができない。半面、特権を恒常的に付与せずJITとした場合、セキュリティが向上する代わりに、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時の障害対応において時間がかかってしまう（JITの承認者がすぐに対応できないなど）ことになる。
PAM運用においては、特権付与の承認レベルに応じて以下のようなモデルが一般的に用いられる。
- 事前承認JIT
これは、特権の付与にあたって承認が必要となる。流れとしては、申請→承認→JIT付与→作業→自動失効となる。この場合、特権が必要な場合には常に事前承認が必要となるため、統制の観点では最強となる。したがって、高リスクの作業を必要とする場合に適している。ただし、緊急性が求められる場合には対応できないことが発生する可能性がある。 - 無承認JIT（自己承認/ポリシー自動）
これは、承認者が存在しない、別の言い方をすると自己承認JITというものである。流れとしては、本人要求→ポリシー判定→即JIT→作業→自動失効となる。この場合、承認者は存在しない。ガバナンスの観点では弱くなるが、ログが生成されるので監視・監査は可能である。したがって、これは低～中のリスクの作業に対して日常運用で用いることが考えられる。 - 事後承認（先に付与、後でレビュー）
これは、まず特権を付与し、使用した後でレビューする方式となる。流れとしては、JIT即時付与→作業→自動失効→後日レビュー（理由・操作内容）となる。承認なしで作業が行われるため、緊急対応や夜間対応の時に用いることが考えられる。
これらの機能をうまく運用することで、セキュリティの向上、緊急時の障害対応などを「特権を恒常的に付与しない」形で実現できる。ただし、運用方針をしっかり定めておくことが重要となる。
さて、上記の機能を使って「特権を恒常的に付与しない」運用をPAMを使って実現できるのであるが、常時特権を持ったアカウント（root等）は必要ないということにはならない。それは、非常事態として、PAMも認証基盤も壊れてしまった場合に最後に「必ず入れる道」を残す必要があるからである。いわゆる「Break-glass」である（注：Break-glassという考え方自体は「クラウドファースト時代における特権アクセス管理」に直接記載されているものではなく、実運用上一般的に用いられている設計パターンとして用いている）。認証基盤、PAM、管理プレーンなどが壊れた場合や緊急対応を必要とする重大インシデントへの対応などではどうしても「最後の管理者」が必要となる。そうすると、基本はPAMを使った「特権を恒常的に付与しない」運用を行い、緊急のためにBreak-glassで対応するという運用が必要となる。しかし、Break-glassを前提すべきではなく、あくまで基本はPAMを使った「特権を恒常的に付与しない」運用にすべきである。つまり、Break-glass は「存在させるが、通常は使わない」前提で設計する必要がある。
もう一つ、特権というか権限を常時付与することが求められることとして、部門/業務等で日常的に必要な権限の付与がある。これには、業務で必要となる権限、機械的に付与される権限などがあり、「必要な時だけ権限を付与」ということがそもそも成り立たない。しかしながら、この部門/業務等で常時付与される権限は、侵害の起点となることが多く、権限昇格やラテラルムーブメントを引き起こすことにもなりうる。これを考えると、PAMは「全体の権限を統合管理する基盤」ではなく、あくまで管理者権限、IAMの高権限ロールを対象にしていて、情報システムそのものを破壊できるような高権限を管理することを目的とし、部門/業務等で日常的に必要な権限はIAM/IGAの範囲と考えるのが妥当である。まとめると、PAMは「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる。
クラウドファースト環境における特権アクセス管理のベストプラクティス10選
「クラウドファースト時代における特権アクセス管理」では、クラウド環境における特権アクセス管理のベストプラクティスとして以下の10項目を挙げている。ここでは、その概要を説明する。
- ジャストインタイムアクセス（JIT）およびジャストイナフアクセス（JEA）を活用し、常時付与された特権を排除する
- 永続的な管理者権限を廃止し、「必要な作業に必要な期間だけ最小権限」を動的に付与してアタックサーフェスを削減する。
- 攻撃者は「常時存在する管理者権限」を狙うことが多いため、これを排除することで侵害リスクが大きく減少する。
- 自動化による特権アクセスの検出とインベントリ
- シャドーアカウントを含むすべての特権アカウントを自動発見・棚卸しし、見えない特権（シャドー特権）を可視化し排除する。
- クラウドでは「誰も把握していない管理権限」が必ず増えるため、これを可視化し排除することが重要である。
- きめ細かなアクセス制御と役割分担の導入
- RBAC/PBACにより職務の分離と最小特権を徹底し、単一アカウントへの過剰集中を防止する。
- 「管理者」という大雑把な権限をやめ、職務単位で分解し権限付与する。これにより、1アカウントを侵害することで全ての権限を持ってしまうという構造を壊すことができる。
- 権限付与、使用状況、および特権アクセス管理の行動パターンを分析する
- 特権の使われ方を継続的に分析し、異常行動・過剰権限・リスク傾向を早期検知する。
- 単にログを取るだけでなく、普段と違う操作、異常な時間帯、権限の使われ方の変化などを行動として分析する。クラウドでは、特に正規アカウントを使った侵害が起こるため、正規アカウントによる異常操作を見つける必要がある。
- 包括的な特権セッションのモニタリングおよび監査の有効化
- すべての特権操作を記録・可視化し、フォレンジック・説明責任・規制対応を可能にする。
- インシデント後に、誰が何をしたかを説明できるようにし、統制や復旧をスムーズに行えるようにする。
- すべての重要な資産とアイデンティティにPAMを拡張する
- サーバーだけでなく、SaaS、業務アプリ、クラウド管理プレーンまでPAM対象に含める。
- PAMの対象をSaaS管理プレーン、業務アプリ、クラウド管理APIまで広げることで、SaaSや業務アプリ側の侵害を防ぐ。
- 非人間アイデンティティとワークロードアクセスをセキュアにする
- サービスアカウント、API、ボット、AIエージェントにもJIT・最小特権・監査を適用する。
- 人ではなく、サービスアカウントやAIエージェントにも適用することでセキュアにする。
- セキュアなリモートおよびサードパーティアクセス
- ベンダーや外部委託先のアクセスも一時的・監査可能を前提として制御する。
- ベンダーや委託先に対しても、永続IDを渡さず時間限定や操作記録付きでアクセスさせるようにすることでセキュアにする。
- PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合する
- PAMをDevOps、CI/CDのInfrastructure-as-Code（IaC）ワークフローに統合し、コード経由の特権漏洩や設定ミスを防止する。
- CI/CD、Terraform などの中の特権もPAM管理下に置くことで、コード内シークレットの問題を解決する。
- 強固なガバナンスとコンプライアンスの確立
- PAMログと統制をSOX／PCI DSS／NIST等の証跡として活用し、監査対応を自動化する。
- PAMログを、そのまま監査証跡、規制対応、経営報告に使えるようにする。これにより、PAMを経営統制のインフラとする。
まとめ
本ブログでは、PAMの定義、PAMの守備範囲について説明した。また、現代のデータ侵害の起点となる特権の扱いとして、「「特権は恒常的に付与しない」は可能か」という点について、PAMの機能を中心に考察した。さらに、クラウドファースト環境における特権アクセス管理のベストプラクティスについてその概要を説明した。
PAMは今後、必須の機能となるが、「全体の権限を統合管理する基盤」ではなく「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる点は理解しておく必要がある。
以上
