【徹底比較】特権ID管理製品の選定ポイント｜方式ごとの長所・短所とは？｜ブログ

Privileged ID management products

近年の新型コロナウィルスの猛威により、企業にはテレワークが強く推奨されるようになりました。多くの企業が社外から社内環境にリモート接続できるよう、構成変更やツールの導入/検討を行ってきたと思います。

一方で情報漏えいに関わるニュースが頻繁に報道されており、テレワークを推進したい反面、セキュリティ事件・事故をどのように対策すればよいのか分からないと不安を抱えている方もいるのではないでしょうか。

本記事では、多くのセキュリティ事件・事故のきっかけとなるIDやパスワードの漏えいを防ぐのに有効な対策である「特権ID管理」に焦点を当て、特権ID管理を無理なく運用するために欠かせない「特権ID管理製品」の方式の差異や、それぞれの長所短所を踏まえた製品選定のポイントについて解説します。

多数ある特権ID管理製品の方式としてはどういったものがあるのでしょうか。またその方式の差異によってどのような影響が生じるのか見ていきたいと思います。

特権ID管理製品の方式ごとの大きな違い

一般的なユーザのIDよりも強力な権限を有する特権IDの管理は、より厳格な管理が必要になるため、効率的に運用可能な「特権ID管理製品」の活用が有効です。

すでに国内では、さまざまな特権ID管理製品が販売されていますが、どのような違いがあるのでしょうか。まずは方式の違いについて解説します。

特権ID管理製品の方式は、大きく２種類に分類することができます。
ゲートウェイ方式とエージェント方式(クライアント・エージェントやサーバ・エージェント方式)です。それぞれの方式は、特権ID管理製品の特徴である「アクセス制御」と「ログ管理」が制御される場所が異なるため、特権ID管理製品としての長所短所が生じます。

ゲートウェイ方式とエージェント方式の大きな差異としては、大きく２つあります。

アクセス制御のためのエージェントの有無

ゲートウェイ方式では「アクセス制御」をゲートウェイで行っているため、エージェントのインストールは不要です。

一方、エージェント方式では「アクセス制御」は個々のクライアント/サーバ側にエージェントソフトウェアのインストールが必須となります。

ログ管理のログ保存先の差異

ゲートウェイ方式は「ログ管理」をゲートウェイで行っているため、ゲートウェイ上にログが保存されます。

エージェント方式では「アクセス制御」を個々のクライアント/サーバで行っている関係上、ログは個々の端末上に保存されます。そのため「ログ管理」を行うためには個々のログを別コンポーネントに連携して収集する必要があります。

図1 方式の差異

環境・規模による特権ID管理製品の違い

次に、システムを導入する環境や管理クライアント/サーバの台数によって、それぞれの方式にどのような差異が生じるかを見ていきます。ポイントとしては２つあります。

導入環境による違い

ゲートウェイ方式は前述の通りネットワーク構成変更が必要なものの既存環境への影響を最小限にして適用可能です。またエージェントレスであるため、検証も最小限にすることができます。

エージェント方式も前述の通りネットワーク構成変更が必要ですが、それに加えてクライアント/サーバにエージェントを導入するため、エージェントと他のソフトウェアとの競合などの影響確認や検証が必要になります。

※新規環境では、どちらの方式においても一定の検証は必要なものの、構成などを構築当初から導入を想定した設計にすることや事前検証を行うことで導入の負荷は軽減できます。

管理クライアント/サーバ台数による違い

ゲートウェイ方式は間にゲートウェイサーバを配置するため、クライアント数やサーバ数の増減についてはゲートウェイのスケールアップ/アウト/インで柔軟に性能要件に対応可能です。

エージェント方式はエージェントの台数が増えるとその分導入・運用・保守の負担が増えます。負荷を緩和するにはエージェントをインストールする対象やアクセス管理対象を限定するなどの検討が必要です。また性能についても個々のクライアント/サーバに対してスケールアップ/アウト/インする必要があります。

図５環境・規模による差異

特権ID管理製品の方式ごとの影響

導入・運用・保守への影響

システムを組み込むということは、必ず「システムの導入」や、それらシステムの「運用・保守をする」という業務が発生します。そこで、それぞれの方式の差異が特権ID管理製品の導入・運用・保守に対してどのような影響を与えるかを見ていきます。

ポイントとしては３つあります。

ポイント① 構成変更の範囲の差異

ゲートウェイ方式では通信を集約し、ゲートウェイから本番サーバへの経路を確保する必要があるためネットワークの構成変更が必要になります。

エージェント方式では一見ネットワークの構成変更が不要と考えがちですが個々のエージェントが取得したログを一箇所に収集する必要があるため、こちらもネットワーク構成変更が必要になります。また特権ID管理製品の「申請・承認」、「特権ID/パスワード払出」機能を利用する場合も、クライアントと本番サーバ間に別途配置した特権ID管理サーバとの通信のやり取りが発生するためネットワーク構成変更が必要になります。

※どちらの方式も既存のシステムに組み込む場合はネットワークの構成変更が必ず発生することにご留意ください。

ポイント②導入負荷の差異
ゲートウェイ方式ではエージェントが不要であるため、既存環境への影響を少くして導入することが可能です。段階的な導入(スモールスタート)を行う場合、ゲートウェイ方式ではまずは通信の集約による「ログ管理」機能を導入し、次に「アクセス制御」機能、システムが安定したら「ID管理」機能を追加するといったように、想定した適応範囲を変更せずに機能を段階的に適応することが可能です。

エージェント方式はエージェントのインストールが必要になるため、管理クライアント/サーバが増えると相関的に導入負荷が増加します。段階的な導入(スモールスタート)を行う場合、個々の端末のエージェントによる「アクセス制御」と「ログ取得」を利用しているため、機能の段階的導入はエージェント数に応じて負荷が大きくなります。一方で初期は適応範囲を小さくし、徐々に拡大していくような適用範囲の段階的な拡大が可能です。

※どちらの方式も最終的に実現できることは同じですが、初期で検討する事項や段階的に実施できるもの（機能か範囲か）に大きな差異があります。

ポイント③ 運用・保守負荷の差異
ゲートウェイ方式はゲートウェイの構成がシンプルであるため、特権ID管理製品の日々の運用や障害発生時の保守も範囲を限定して行うことが可能です。ゲートウェイが単一障害点になるという懸念もありますが、一般的な冗長構成を取ることで容易に対応可能です。製品のアップデートについてはゲートウェイに限定した対応が可能で、個別クライアント/サーバの対応が不要です。

エージェント方式はエージェントのアップデートの運用や端末依存の障害に対する保守が、管理するクライアント/サーバの台数によって相関的に負荷が増加します。

※これら負荷を軽減させるためには、エージェント管理用の別ツールの導入や、対象範囲を絞って運用・保守するなどの検討が必要になります。またエージェントは単一障害点にはなりませんが、エージェントを導入するクライアント/サーバが増えると考慮する障害点が増えるという懸念点があります。こちらも冗長構成を検討することで対応可能ですが、障害点すべてを冗長化するとコストが増加するため、冗長化する範囲については慎重に検討する必要があります。

図３導入・運用・保守の差異

アクセス制御機能への影響

次に、特権ID管理製品として重要な「アクセス制御」の機能の観点で長所短所を見ていきたいと思います。

ゲートウェイ方式では、「アクセス制御」は必ずゲートウェイを通る必要があるため、本番環境へのアクセス経路が複数ある場合に注意が必要です。アクセス経路の例として下記のようなゲートウェイを通らない通信も忘れてはいけません。

コンソールへの直接アクセス：本番サーバに直接アクセスする場合等
多段アクセス：本番サーバから別サーバへアクセスする場合等
クラウドの管理ページへのアクセス：クラウドのWebページに直接アクセスする場合等

このようなゲートウェイを通過しない通信に対する「アクセス制御」は、特権ID管理製品の「特権ID/パスワード払出」機能をもつ製品を導入することで対応可能です。

エージェント方式では、エージェントで各クライアント/サーバの「アクセス制御」を行えるため、本番サーバへのアクセス経路に関わらず「アクセス制御」が可能です。そのためゲートウェイ方式で記載した、コンソールへの直接アクセス、多段アクセス、クラウドの管理コンソールへのアクセスに対して影響なく使用可能です。

ログ管理機能への影響

ゲートウェイ方式のログはゲートウェイで一元的に取得・保管されるため「ログ管理」は容易に実施可能です。ログについては基本的にゲートウェイ通過時のみ動画/テキストのログを取得することに留意が必要です。
ゲートウェイを通過しない通信に対する「ログ管理」は、統合ログ管理製品と連携できる製品を導入することで対応可能です。

エージェント方式のログは個々のクライアント/サーバに保存されるため、保存されたログを別コンポーネントに収集する必要があります。一方で個々のクライアント/サーバのエージェントがログを取得するため、ユーザの操作に対してきめ細かいログ取得が可能です。

図４特権ID管理製品のアクセス制御・ログ管理機能の差異

特権ID管理製品の最新の傾向

ここまでで特権ID管理製品の方式について、様々な観点で差異を見てきました。
どの方式もそれぞれ長所短所がありますが、やはり企業の担当者の一番の悩みである導入・運用・保守のコストや管理対象台数の増減を考慮するとゲートウェイ方式に優位性があると考えます。

では、次に特権ID管理製品がそれぞれの方式の短所に対してどのように改善してきたのかを含め最近の傾向を見ていきたいと思います。

傾向１ゲートウェイ方式は進化している

まずゲートウェイ方式はどのように短所に対して改善しているのでしょうか。
整理した中でも一部記載していますが、ゲートウェイ方式を検討される多くの方が持たれる懸念点として４つあります。

① ゲートウェイが単一障害点になる
② コンソールへの直接アクセス管理が不可
③ 多段アクセス制御が不可
④ クラウドの管理コンソールへのアクセス管理が不可

ゲートウェイ方式の場合必ず間に設置したゲートウェイを通過しなくてはならないため、単一障害点の懸念や、ゲートウェイを通過しない通信の「アクセス制御」といった懸念がでてくるのかと思います。またこのような懸念を持たれる背景として昨今のパブリッククラウド、プライベートクラウドの台頭や、ハイブリットクラウドなど様々な環境にサーバを分散配置している場合の「アクセス制御」に不安を覚えている方が増えているのではないでしょうか。

図5 ゲートウェイ方式の懸念点

まず、①の単一障害点への懸念点ですが、これは一般的によくある分散配置、冗長化構成を取ることで対応が可能です。ゲートウェイ方式は構成がシンプルであり「アクセス制御」や「ログ管理」を一元管理しているため、障害点に対する冗長化構成もシンプルに検討することが可能です。

次に、②～④のゲートウェイを通過しない「アクセス制御」への懸念点ですが、ゲートウェイ方式は「特権ID/パスワード払出」機能を利用します。「特権ID/パスワード払出」機能はゲートウェイ側で特権ID及びパスワードの払い出しを行う機能のことで、一時的に払い出された特権IDとパスワードをユーザに通知することでゲートウェイを通過しないサーバやクラウド環境への「アクセス制御」を行うことが可能です。

図6 ゲートウェイ方式の懸念点に対する対応

傾向２エージェント方式のゲートウェイ化が進んでいる

次にエージェント方式の最近の傾向をみていきたいと思います。
以前はゲートウェイ方式、エージェント方式と明確に区別できていたのですが、最近では方式の短所を補うために別の方式を混ぜ込んだハイブリット方式というのもでてきています。

例えばエージェント方式では導入・運用・保守の負荷を下げるため、クライアントと本番サーバ間に踏み台サーバを配置し、その踏み台サーバにエージェントをインストールする方式で提供するベンダーもあります。

一見ゲートウェイ方式と同じように見えますが、根本としてはエージェントのインストールが必須の方式です。ゲートウェイ型エージェント方式は本記事で整理した長所短所の中の導入の負荷を緩和することが可能ですが、他の項目については大きな変化はありません。むしろ踏み台サーバの管理やネットワーク構成が複雑化して逆に管理コストが増える懸念があることに注意が必要です。

図7 エージェント方式のゲートウェイ化

最後に

ここまでで特権ID管理製品の方式について、様々な観点でどのような影響があるのかを見てきました。どの方式もそれぞれ長所短所があり、検討するポイントが多岐にわたります。

一方で短所についても方式変更や機能の追加、別製品との組み合わせを検討することである程度解消・緩和することができます。どの方式が皆様の管理しているシステムに最もフィットするかは、既存システムの構成や、実現したいこと、コスト感で異なります。是非今回整理したポイントを踏まえて、皆様が管理しているシステムに特権ID管理製品を導入する際の一つの指標にしていただければと思います。