内製か、オンプレミスか、SaaSか――「最強アカウント」を保護する「特権アクセス保護」（PAM）導入時の考慮ポイント：ゼロトラスト時代の特権IDの守り方（終）

古くて新しい「特権アクセス保護」（PAM）について技術的内容を分かりやすく解説する連載。最終回は、PAMを導入する際に考慮すべきことなどについて解説する。

[金子和孝，CyberArk Software]

　早いもので、本連載も最終回の第3回となりました。本連載「ゼロトラスト時代の特権IDの守り方」では、古くて新しいPAMについて技術的内容を解説してきました。「そもそもPAMって何？」という方や、導入を検討し始めた方には最適の内容になっています。今回は導入に向けて考慮すべきことを解説します。

特権アクセス管理（PAM）の導入に当たって

　まずは、導入する狙い、目的を明確にすることが大切です。本連載では、PAMにあまりなじみがない方を対象としているので、新規で導入するケースを前提とします。PAMを導入すると、どんな効果を期待できるかをザックリ整理しました。

表1　PAM成熟度レベルとそれに応じた機能特徴

	PAM成熟度レベル	費用	要素	具体的な機能	期待できる効果
1.	低	小	認証情報の保護と管理	自動定期パスワード更新、アクセス制御など	セキュリティガバナンスの強化、パスワード盗難対策など
2.	中	中	特権セッションの分離と記録	ゲートウェイ経由接続、自動接続、作業録画など	感染被害拡大の遮断、IT監査対応、内部不正抑止など
3.	高	大	特権の不正利用の検知と対処	不正アクセス検知、バックドアアカウント作成検知など	内部不正検知、アクセス経路一元化など

　もちろん、上記以外にも特徴的な機能を持っているツールもあるので、あくまでも参考としてください。詳しくは、専門家と議論することをお勧めします。

成功のための重要な原則（内製か、オンプレミスか、SaaSか）

　ここでは、先に述べた期待できる効果を軸にPAMの導入形態（内製、オンプレミス、SaaS）について、解説します。

内製

　認証情報の一元管理は台帳で管理することで、簡単に実現できると思います。パスワードの定期更新も、手作業やスクリプトを作りこんで頑張って運用することもできるでしょう。しかし、この方法だと保護する対象が多くなると、運用に限界が来ることはすぐに分かると思います。

　次に、特権セッションの分離と記録についてですが、踏み台サーバを建てて、そこを経由してターゲットシステムにつながる仕組みを作れば、特権セッションは、ユーザー端末から踏み台サーバにつながって、そこから踏み台サーバからターゲットシステムにつながるように、セッションを分離できます。加えて、アクセスしたログを取っていれば、「誰がいつアクセスしたか」を追跡できる材料は持つことができるでしょう。しかし、例えばターゲットシステムにリモートデスクトップでつながった後の、その作業内容を録画することは、内製だけではとてもハードルが高いといえます。

　不正利用検知については相当工夫しないと内製では無理に近いのではないでしょうか。ターゲットシステムにアクセスしたことは、アクセスログをsyslogの仕組みを使ってログ監視システムに送って解析すればできないことはないと思いますが、何をもって不正と判断するのか、特権IDのように共有されて使われるものについては、内製だけでは相当難しいのではないでしょうか。

　筆者の想定ではおそらくここまで内製で構築している組織はないと思います。あったとしても、何かしらのツールを導入しているでしょうし、経営の観点でも、人材不足といわれるサイバーセキュリティ人材を潤沢に確保するのは至難の業だと思いますので、1000人以上の規模の企業ではツールを導入することを前提として検討するのがよいでしょう。

　ツールを導入する場合、大きく2つのタイプがあります。オンプレミスとSaaSです。それぞれの基礎的な特徴について解説します。機能については、専業メーカーが作るツールなので、前述の表1の機能が満たせるのが望ましいですが、予算や要件に応じて取捨選択するとよいでしょう。

オンプレミス

　オンプレミスタイプのツールを導入する場合、セキュリティの観点では何といってもプライベートでクローズな環境でPAMが構築できることが大きな違いの一つだと思います。ただし、プライベートな環境が、必ずしも安全性が高いことを意味しているわけではないので、注意してください。

　その他のオンプレミスタイプの特徴は、メンテナンスについてのコントロール、すなわち、ソフトウェアのバージョンの固定だったり、サービスメンテナンスの時間帯を自由に決めることができることだったりします。半面、導入した後にメンテナンスの手間がかかることも事実です。機能面については、製品によってオンプレミスタイプでしか実装されていない細かな機能もあるので、適宜専門家に確認するとよいでしょう。

SaaS

　近年のトレンドを見ると、今後SaaSタイプのPAMが主流になると予想されます。パブリック空間に認証情報を扱うPAMを構築するよりも、ビジネス的なメリットの方が大きいと判断して導入することが多いようです。

　オンプレミスタイプと比較すると、資産を持たないまま、予算を抑えながらスモールスタートできて、導入完了までが早いことなどから受け入れられています。ただし、考慮しておかなければいけないこともあるので、代表的なものを3点ほど紹介したいと思います。

　第1に、メンテナンスはSaaS提供事業者に従うことになります。事前に知ることはできますが、サービスメンテナンスの時間は調整できないのが一般的です。バージョンアップによってユーザーインタフェースや操作方法が多少変わる場合があることを受け入れる必要があります。

　第2に、サービス提供のインフラや可用性の構成を自由にデザインできません。「Amazon Web Services」（AWS）にするか、「Microsoft Azure」にするか、「Google Cloud Platform」（GCP）にするかは、当然ですがユーザーでは決められません。サービスが稼働するデータセンターも選べません。提供されているリージョン以外を指定することも、冗長構成についても自由に決められないので、導入前にデータセンターの場所や、稼働率といったSLA（Service Level Agreement）を確認しておくことをお勧めします。

　第3に、SaaSタイプは必ずと言ってもいいほどサブスクリプションでの契約となり、買い切りはできません。最低契約期間や、サブスクリプションに含まれるサービス内容を確認しておくとよいでしょう。

表2　オンプレミスタイプとSaaSタイプの違い

特徴	オンプレミスタイプ	SaaSタイプ	補足
サービスメンテナンス	企業のポリシーによる	サービス提供事業者による	SaaSタイプについては、ユーザーの通常業務時間外であることが何かを確認した方がよい
バージョンアップ	ユーザー主導	サービス提供事業者主導	どちらの場合も、バージョンアップに伴って想定外の問題が発生する可能性があることを想定しておくとよい
インフラ／可用性構成	ユーザー主導	サービス提供事業者主導	どちらの場合も、何がダウンしたら、どんな影響があるのかを把握しておくとよい
主な販売形態	買い切り／サブスクリプション	サブスクリプション	財務的な観点で、最近はサブスクリプションが主流

　ここまで解説した特徴を押さえつつ、専門家に相談しながら導入に向けたロードマップを策定することが、PAMの持つセキュリティ価値を最大化して企業全体の安全性を高めることにつながります。

プロジェクトからプログラムへ

　導入に向けたロードマップとはどんなものなのでしょうか。一般的に新しいシステムを導入したら、運用するだけのようなイメージを持たれるかもしれませんが、PAMの場合継続的に導入が続くイメージを持った方が、現実的だと思います。なぜなら、PAMで管理、保護されるのはターゲットマシンが持つ、最高権限のアカウントがほとんどです。これら全てを、一度にPAMの管理下に置くことは無理があるので、優先順位を決めて徐々に展開していく手法が最も多く採用されています。

　多くの場合、サーバ、データベース、ネットワーク、SaaSなど、幅広い領域のターゲットシステムをカバーすることが求められます。それらに関連するステークホルダーも必然的に多岐にわたって多くなりがちです。短期集中的なプロジェクトというよりも、長期継続的なプログラムと捉えて付き合うことが大切です。

　下図は、ロードマップ策定のサンプルですが、一般的なプロジェクトよりも時間軸が長いことが分かると思います。

高度な特権アクセス管理＆運用

　参考までに、少し高度なPAMの機能を紹介します。それはアプリケーション開発の中で必要とされる特権の保護です。アプリケーションを通して他のシステムに接続にするのはよくあることですが、接続の際には、わずかな例外を除いて必ず認証の仕組みを経てから、接続されることを許されています。ここで問題になるのが、コードに直接書き込まれた認証情報です。

　そもそも、コードが盗まれないような対策を講じていると思いますが、コードに認証情報をそのまま書いていては、コードの流出によって侵入を許すきっかけを与えてしまいかねません。コードが盗まれて、そのコードに平文で埋め込まれているIDとパスワードを利用してインシデントとなった事例が日本でも報告されています（参考）。

　これらの問題を解決する機能を提供しているPAMもあります。開発者はコードに平文で認証情報を書く代わりに、PAMが持つVaultに問い合わせるような関数を書いて抽象化できるのです。この機能は、プログラミング言語で書かれるコードの他にも、スクリプトやコンテナを利用して開発するアプリケーションにも応用できるようになっています。

　今後、人以外にも、モノが使う認証情報の保護が求められる場面が多く見られると予想されています。

「最強アカウント」を保護するために

　最後に、3回の連載にお付き合いいただきまして、ありがとうございました。本連載が、日本ではあまり知られていないPAMについて少しでも知るきっかけになったでしょうか。

　「特権」という言葉がITの世界ではあまり使われることがないので、分かりにくい印象を持たれていると思いますが、中身は意外に単純です。Administratorやrootのような共有されるアカウントで、一番高い権限を持つ「最強アカウント」が特権です。これらを厳重に保護することが。サイバー攻撃から被害を最小限にするために効果的な対策です。そのために、主に以下のような機能を提供するのが特権アクセス保護（PAM）です。

• 全ての装置の認証情報を厳重に一元管理および保護して、コンプライアンス漏れをなくす
• アクセスの際に、ユーザーに認証情報を知らせないので、認証情報の漏えいをなくせる
• アクセス経路を一元化できるので、検知できない侵入経路をなくせる
• 認証情報を自動で定期更新するので、認証情報が盗まれても被害を低減できる
• 接続セッションを録画するので、監査証跡に利用できる
• 不正なアクセスを検知するので、攻撃の即時検知とその対応を迅速化できる

　本連載が少しでも読者の所属する企業、組織のセキュリティリテラシーの向上にお役に立てたら幸いです。