特権アクセス保護／特権ID管理の本質、歴史、ID管理基盤／IDaaS（ID as a Service）との違い：ゼロトラスト時代の特権IDの守り方（2）

古くて新しい「特権アクセス保護」について技術的内容を分かりやすく解説する連載。今回は、特権アクセス保護（PAM）の歴史と本質、具体的にどのように機能するのか、ID管理基盤／IDaaS（ID as a Service）との違いなどについて解説する。

[金子和孝，CyberArk Software]

　古くて新しい「特権アクセス保護」（PAM：Privilege Access Management）について技術的内容を分かりやすく解説する本連載「ゼロトラスト時代の特権IDの守り方」。連載初回の前回では、そもそも「特権」とは何か、特権の持つ特徴リスク、抱える課題などについて整理しました。

　今回は、PAMの歴史と本質、具体的にどのように機能するのか、ID管理基盤／IDaaS（ID as a Service）との違いなどを解説します。

特権アクセス管理とは

　多くの読者の方にはあまり聞きなじみがないかもしれませんが、海外では特権アクセス管理のことを「PAM」（Privilege Access Management）といいます。ベンダーによっては、「PIM」（Privileged Identity Management：特権ID管理）とすることもありますが、本質的には同じ問題を解決するソフトウェアです。

　主な機能としては、管理者が使う特権アカウントの認証情報の保管と保護、それらをセキュアに払い出すことです。

特権アクセス管理の変遷

　初期のPAMでは、認証情報をしっかりと保護する管理的な機能に力点が置かれていました。ユーザーがパスワードといった認証情報を持つ必要をなくし、利用する都度、管理しているPAMに聞きにいって、取得するイメージです。

　この仕組みの中で、認証情報を保護するコンポーネントを「Vault（ボルト）」といいます。日本語では「金庫」「金庫室」「保管室」といった意味で、サイバーセキュリティの文脈では、「非常に重要な情報が保管される場所」といったニュアンスです。

　PAMの製品を提供するベンダーが異なっても、一般的にこの用語は使われることが多いので、知っておいて損はないと思います。「この単語自体を初めて聞いた」といった方もいるかもしれませんが、私たちがよく使うMacやWindowsのPCにもVaultといった単語を含む機能が入っているので、これからはこの用語は、ますます一般的になってくると思っています。

　話を元に戻します。このVaultに認証情報を集約することで、ユーザーの端末にパスワードを保管させる必要がなくなりました。必要があれば、Vaultに問い合わせてもらいにいきます。この際に、誰でも簡単に問い合わせて取り出せると、Vaultに集約して保管する意味がなくなってしまうので、そこは厳重にガードする仕組みを設けます。

　具体的にはVaultにアクセスできるネットワークを制限したり、曜日や時間を制限したり、多要素認証を使ったり、読み、書き、削除などの認可権限を組み合わせてロール設定して、アクセス制限を細かく設定したりなどです。また認証情報を定期的に更新する機能も盛り込まれていました。つまり、認証情報の厳格な保管と管理に力点が置かれていました。これを「第1世代」と呼ぶことにします。

　次に、認証情報を取得してWindowsやLinuxのターゲット機器に接続するセッション管理機能も加えられました。ユーザーはターゲット機器にリモートアクセスしたいとき、認証情報をVaultに取りにいきます。認証情報はユーザーに見られることなく、WindowsのリモートデスクトップやLinux機器やネットワーク機器にSSH接続するためのアプリケーションに渡され、特権IDを使って接続されます。その接続中の操作内容は録画、記録され、接続が終わればそのタイミングも把握できるようになりました。これは、内部不正の防止や抑制に効果があります。これが、「第2世代」のPAMです。

　これらの仕組みは、比較的シンプルです。ベンダーによって違いはありますが、エージェントを入れる方法と、エージェントを入れない代わりにターゲット機器にアクセスできるゲートウェイを建てて、ゲートウェイ経由で接続を一元化させる方法のいずれかです。世界的にはゲートウェイ型の仕組みが主流のようですが、ユースケースよって向き不向きがあると思うので、必要に応じて専門家のアドバイスをもらうのがよいと思います。

　下図はゲートウェイ型のイメージ図です。図だけ見ると、ユーザーは一度ゲートウェイに入って、そこからまたリモート接続するようにも見えてしまいますが、ユーザーはゲートウェイの存在を意識しません。PAMの機能で自動的にターゲット機器まで接続してくれるので、ユーザー体験としても、従来の接続体験とあまり差を感じないと思います。

　PAMの進化はここで終わりません。海外の先進的なベンダーでは、PAMを使わない、直接アクセスの接続を疑わしい不正アクセスと見なし、それを検知し、アラームを発報し、自動是正措置をとる製品もあります。危険コマンドを識別してリスクスコアを算出し、スコアによってはアクセスセッションの一時停止や強制切断をして、被害を防ぐ措置がとれるものもあります。SIEM（Security Information and Event Management）と連携して、SOC（Security Operation Center）サービスに組み込むことも可能になっています。

　これらの機能は主に人が使う特権IDに関する機能ですが、近年はコンテナアプリケーションやコードに特権の認証情報を埋め込んで使っていることが、攻撃者から狙われる対象になっており、人以外のモノが使う認証情報の管理もPAMの対象範囲になっています。

　関連する話題として、つい最近では、PCI DSS（Payment Card Industry Data Security Standard）のセキュリティ基準が4.0に改定され、コードやスクリプトへの認証情報の埋め込みが禁止され（PCI DSS version 4.0 March 2022 8.6.2）、モノが使った認証情報の記録を取っておくこと（PCI DSS version 4.0 March 2022 10.4.1.1）が要件となりました。このような用途のユースケースもカバーしているPAM製品もあります。

　このような進化の変遷を経てきたPAMですが、実はオンプレミスでの提供が主でした、しかしながら、近年ではクラウドシフトの流れもあり、SaaS型の形態でも提供されるようになり、より幅広い選択肢が持てるようになっています。PAMを導入するに当たり考慮するポイントについては、次回解説します。

コンプライアンスにおけるPAM

　先に紹介した機能の中から、コンプライアンスの観点での恩恵があることについても触れておきます。

　まずは、PAMの仕組みによって、特権IDを使う際のアクセスログを取得できるようになります。すなわち特権IDについて、いつ、誰が（どのアプリが）、どの認証情報にアクセスしたのかといった記録を残すことが可能になったのです。加えて、ベンダーにより違いはありますが、ゲートウェイまたは、エージェントの仕組みを通じて操作内容を録画、記録できるので、どんな操作があったのかの証跡を残すことができます。

　このような機能はIT監査にとって非常に有用な機能です。それだけではなく、パスワード管理における統制もITセキュリティガバナンスの上では、重要なポイントです。例えば、パスワードを知っているユーザーが退職後も使える状況を放置しておくことは、セキュリティの観点でもコンプライアンスの観点でもよろしくありません。PAMでは、任意の複雑性を定義した、定期的なパスワード変更も自動化してくれます。手作業による抜けや漏れをなくし、セキュリティ基準の高いコンプライアンスに準拠した環境を作り上げることができます。

　これらの機能はITガバナンスの側面でも非常に有用な機能として、IT監査が高度化、義務化している海外では、いち早く導入が加速されるきっかけとなりました。監査というと、日本ではJ-SOX法が上場企業に適用されていることもあり、すぐに思い浮かぶと思いますが、その中にあるフレームワークでは、承認を受けた上でシステムを変更する体制や内部統制を持つ必要がある旨が規定されています。この申請→承認のワークフローについても、PAMの基本機能として提供されています。まだそのような仕組みを持っていない組織は、まずは手運用でもいいので、手当てをしておくことをお勧めします。

特権アクセス管理とID管理基盤

　最後に、最近よく見掛けるキーワードの一つ「ID管理基盤」との違いについて解説します。ここでの、ID管理基盤はIDaaSのことです。さまざまなWebアプリケーションを使うためのアカウントを一元管理してくれるプラットフォームを意味します。

　ざっくり説明すると、一般ユーザーを含む全ユーザーが利用するさまざまなWebアプリケーションを一元化されたポータルからアクセスでき、使えるアプリケーションのユーザーIDの認可や認証を管理者がコントロールし、利便性とセキュリティを向上させる製品といったところです。これ対して特権アクセス管理（PAM）はその中でも管理者が使う特権IDに焦点を当てており、PAMの利用形態がWebアプリケーションなら、IDaaSで管理されるアプリケーションの一つと見ることもできます。

　従って、どちらかがどちらかを代替することは、（今のところ）ありません。片方だけ導入していれば、安心というわけでもありません。今後は、PAMとIDaaSの両方を利用するユースケースが増えると思います。主なユースケースとしては、PAMとIDaaSを連携させて、多要素認証やシングルサインを利用するケースです。これによってユーザーの利便性を高めたり、高度な認証方式を使ってセキュリティを高めたりすることができるようになります。

　次に需要がありそうなユースケースは、一般ユーザー、特権ユーザーを含む全ユーザーのIDの一元管理です。ユーザーの入社、異動、退社に伴いPAMの利用権限を自動的に付与、削除できて権限を与え過ぎたユーザーが存在するケースが少なくなる効果があります。

---

　本記事を読んで「PAMとは、どういった課題を、どうやって解決するのか」が、そして「何がうれしいのか」を大枠でイメージできるようになっていたらうれしいです。次回は、ベンダー製品を導入するに当たって考慮した方がいいことや、海外での先行事例を通じたベストプラクティスをお話しします。引き続き、よろしくお願いします。