近年の新型コロナウィルスの猛威により、企業にはテレワークが強く推奨されるようになりました。多くの企業が社外から社内環境にリモート接続できるよう、構成変更やツールの導入/検討を行ってきたと思います。
一方で情報漏えいに関わるニュースが頻繁に報道されており、テレワークを推進したい反面、セキュリティ事件・事故をどのように対策すればよいのか分からないと不安を抱えている方もいるのではないでしょうか。
本記事では多くのセキュリティ事件・事故のきっかけとなるIDやパスワードの漏洩を防ぐためセキュリティ対策である「特権ID管理」に焦点を当て、特権ID管理における「方式」の差異や、それぞれの長所短所を踏まえた特権ID製品の選定ポイントについて解説します。
管理者アカウントやルートアカウントが脅威にさらされている？
情報処理推進機構（IPA）が毎年発表している「情報セキュリティ10大脅威 2020」によると、組織に対する脅威トップ10項目の内、実に６項目がIDやパスワード等のクレデンシャル漏えいによる不正アクセスの脅威に絡んでいるものでした。
図１ [情報セキュリティ10大脅威 2020：組織編]を元にNRIセキュアが作成
これらから読み取れることとして、多くの事件・事故は、IDやパスワードの漏えいをきっかけとしてシステムに不正アクセスされ、重要情報の搾取、システムのマルウェアの感染等の脅威に晒されているということです。
では企業で管理しているIDやパスワード、特に特別な権限を所持したルートユーザや管理者権限を持つ「特権ID」はどのように管理すればよいのでしょうか。１つのアイディアとしてはこうした特別な権限を有したIDを管理するために、特権ID管理製品を導入することです。
特権IDとは
そもそも特権IDとはなんでしょうか。
特権IDとは通常のユーザよりも特別な権限を有しているIDを指すものであり、サーバの設定変更やユーザ権限の管理を行えるIDが該当します。一般的に管理者権限アカウント、スーパーユーザ、ルートユーザ等と呼ばれているものです。
最近はクラウド環境の利用も増えてきたため、クラウド上の特別な権限を有したIDも特権IDといえます。これらの特権IDは強力な権限が割り当てられていることが多く、また複数のユーザで使い回されるケースが多く散見されます。この場合、「誰が」「いつ」「どこに」特権IDを使用したのか、「何を」操作したのかが曖昧になり、悪意のある操作によって設定の変更、機密情報の持ち出しなどが行われる可能性があります。
特権ID管理製品ではこうした悪意のある操作や不正行為を防ぐための機能として「誰が」「いつ」「どこに」を制御する「アクセス制御」機能を擁し、また「何を」操作したのかを証明するための機能として「ログ管理」機能が備わっています。
※他にも「ID管理」、「申請・承認」、「特権ID/パスワード払出」等の機能を保有していることが多いです。
特権IDやリスクについての説明はこちらでも確認ください
【比較】特権ID管理製品の方式ごとの差異
多数ある特権ID管理製品の方式としてはどういったものがあるのでしょうか。またその方式の差異によってどのような影響が生じるのか見ていきたいと思います。
方式はどのように違うのか？
まずは特権ID管理製品の方式はどのような種類があるのでしょうか。
現在では方式が入り混じり複雑化してきていますが大きく２種類に分類することができます。
ゲートウェイ方式とエージェント方式(クライアント・エージェントやサーバ・エージェント方式)です。それぞれの方式は、特権ID管理製品の特徴である「アクセス制御」と「ログ管理」が制御される場所が異なるため、特権ID管理製品としての長所短所が生じます。
ゲートウェイ方式とエージェント方式の大きな差異としては、大きく２つあります。
- アクセス制御のためのエージェントの有無
・ゲートウェイ方式では「アクセス制御」をゲートウェイで行っているため、エージェントのインストールは不要です。
・エージェント方式では「アクセス制御」は個々のクライアント/サーバ側にエー
ジェントソフトウェアのインストールが必須です。 - ログ管理のログ保存先の差異
・ゲートウェイ方式は「ログ管理」をゲートウェイで行っているため、ゲートウェイ上にログが保存されます。
・エージェント方式では「アクセス制御」を個々のクライアント/サーバで行っている関係上、ログは個々の端末上に保存されます。そのため「ログ管理」を行うためには個々のログを別コンポーネントに連携して収集する必要があります。
図２ 方式の差異
導入・運用・保守への影響は？
システムを組み込むということは、必ずそのシステムを導入する方や運用・保守を実施する方が存在します。そこで、それぞれの方式の差異が特権ID管理製品の導入・運用・保守においてどのように影響するか見て行きます。ポイントとしては３つあります。
- 構成変更の範囲の差異
・ゲートウェイ方式では通信を集約し、ゲートウェイから本番サーバへの経路を確保する必要があるためネットワークの構成変更が必要になります。
・エージェント方式では一見ネットワークの構成変更が不要と考えがちですが個々のエージェントが取得したログを一箇所に収集する必要があるため、こちらもネットワーク構成変更が必要になります。また特権ID管理製品の「申請・承認」、「特権ID/パスワード払出」機能を利用する場合も、クライアントと本番サーバ間に別途配置した特権ID管理サーバとの通信のやり取りが発生するためネットワーク構成変更が必要になります。
※どちらの方式も既存のシステムに組み込む場合はネットワークの構成変更が必ず発生することにご留意ください。 - 導入負荷の差異
・ゲートウェイ方式ではエージェントが不要であるため、既存環境への影響を少くして導入することが可能です。段階的な導入(スモールスタート)を行う場合、ゲートウェイ方式ではまずは通信の集約による「ログ管理」機能を導入し、次に「アクセス制御」機能、システムが安定したら「ID管理」機能を追加するといったように、想定した適応範囲を変更せずに機能を段階的に適応することが可能です。
・エージェント方式はエージェントのインストールが必要になるため、管理クライアント/サーバが増えると相関的に導入負荷が増加します。段階的な導入(スモールスタート)を行う場合、個々の端末のエージェントによる「アクセス制御」と「ログ取得」を利用しているため、機能の段階的導入はエージェント数に応じて負荷が大きくなります。一方で初期は適応範囲を小さくし、徐々に拡大していくような適用範囲の段階的な拡大が可能です。
※どちらの方式も最終的に実現できることは同じですが、初期で検討する事項や段階的に実
施できるもの（機能か範囲か）に大きな差異があります。 - 運用・保守負荷の差異
・ゲートウェイ方式はゲートウェイの構成がシンプルであるため、特権ID管理製品の日々の運用や障害発生時の保守も範囲を限定して行うことが可能です。ゲートウェイが単一障害点になるという懸念もありますが、一般的な冗長構成を取ることで容易に対応可能です。製品のアップデートについてはゲートウェイに限定した対応が可能で、個別クライアント/サーバの対応が不要です。
・エージェント方式はエージェントのアップデートの運用や端末依存の障害に対する保守が、管理するクライアント/サーバの台数によって相関的に負荷が増加します。
※これら負荷を軽減させるためには、エージェント管理用の別ツールの導入や、対象範囲を絞って運用・保守するなどの検討が必要になります。またエージェントは単一障害点にはなりませんが、エージェントを導入するクライアント/サーバが増えると考慮する障害点が増えるという懸念点があります。こちらも冗長構成を検討することで対応可能ですが、障害点すべてを冗長化するとコストが増加するため、冗長化する範囲については慎重に検討する必要があります。
図３ 導入・運用・保守の差異
アクセス制御・ログ管理の機能にどう影響する？
ここまでは方式の差異による導入・運用・保守にどのように影響があるのかを理解いただけたかと思います。次に、特権ID管理製品として重要な「アクセス制御」・「ログ管理」の機能の観点で長所短所を見ていきたいと思います。
ポイントとしては2つあります。
- アクセス制御の範囲
・ゲートウェイ方式では、「アクセス制御」は必ずゲートウェイを通る必要があるため、本番環境へのアクセス経路が複数ある場合に注意が必要です。アクセス経路が複数ある例として下記のようなゲートウェイを通らない通信が該当します。
コンソールへの直接アクセス：本番サーバに直接アクセスしたい場合等
多段アクセス：本番サーバから別サーバへアクセスしたい場合等
クラウドの管理コンソールへのアクセス：クラウドのWebページに直接アクセスしたい場合等
このような通信に対する「アクセス制御」は特権ID管理製品の「特権ID/パスワード払出」機能を利用することで対応可能です。
・エージェント方式では、エージェントで各クライアント/サーバの「アクセス制御」を行えるため、本番サーバへのアクセス経路に関わらず「アクセス制御」が可能です。そのためゲートウェイ方式で記載した、コンソールへの直接アクセス、多段アクセス、クラウドの管理コンソールへのアクセスに対して影響なく使用可能です。 - ログ管理先及びログの詳細
・ゲートウェイ方式のログはゲートウェイで一元的に取得・保管されるため「ログ管理」は容易に実施可能です。ログについては基本的にゲートウェイ通過時のみ動画/テキストのログを取得することに留意が必要です。
※ゲートウェイを通過しない通信に対する「ログ管理」は、統合ログ管理製品と連携できる製品を導入することで対応可能です。
・エージェント方式のログは個々のクライアント/サーバに保存されるため、保存されたログを別コンポーネントに収集する必要があります。一方で個々のクライアント/サーバのエージェントがログを取得するため、ユーザの操作に対してきめ細かいログ取得が可能です。
図４ 特権ID管理製品のアクセス制御・ログ管理機能の差異
環境・規模によってどう違う？
方式の差異による特権ID管理製品の「アクセス制御」・「ログ管理」機能の長所短所を説明しました。次に、システムを導入する環境や管理クライアント/サーバの台数によってどのような差異が生じるかを見ていきます。
ポイントとしては２つあります。
- 導入環境 (既存/新規）
・ゲートウェイ方式は前述の通りネットワーク構成変更が必要なものの既存環境への影響を最小限にして適用可能です。またエージェントレスであるため、検証も最小限にすることができます。
・エージェント方式も前述の通りネットワーク構成変更が必要ですが、それに加えてクライアント/サーバにエージェントを導入するため、エージェントと他のソフトウェアとの競合などの影響確認や検証が必要になります。
※新規環境では、どちらの方式においても一定の検証は必要なものの、構成などを構築当初から導入を想定した設計にすることや事前検証を行うことで導入の負荷は軽減できます。 - 管理クライアント/サーバ台数
・ゲートウェイ方式は間にゲートウェイサーバを配置するため、クライアント数やサーバ数の増減についてはゲートウェイのスケールアップ/アウト/インで柔軟に性能要件に対応可能です。
・エージェント方式はエージェントの台数が増えるとその分導入・運用・保守の負担が増えます。負荷を緩和するにはエージェントをインストールする対象やアクセス管理対象を限定するなどの検討が必要です。また性能についても個々のクライアント/サーバに対してスケールアップ/アウト/インする必要があります。
図５ 環境・規模による差異
特権ID管理製品の最新の傾向
ここまでで特権ID管理製品の方式について、様々な観点で差異を見てきました。
どの方式もそれぞれ長所短所がありますが、やはり企業の担当者の一番の悩みである導入・運用・保守のコストや管理対象台数の増減を考慮するとゲートウェイ方式に優位性があると考えます。
では、次に特権ID管理製品がそれぞれの方式の短所に対してどのように改善してきたのかを含め最近の傾向を見ていきたいと思います。
傾向１ ゲートウェイ方式は進化している
まずゲートウェイ方式はどのように短所に対して改善しているのでしょうか。
整理した中でも一部記載していますが、ゲートウェイ方式を検討される多くの方が持たれる懸念点として４つあります。
- ① ゲートウェイが単一障害点になる
② コンソールへの直接アクセス管理が不可
③ 多段アクセス制御が不可
④ クラウドの管理コンソールへのアクセス管理が不可
ゲートウェイ方式の場合必ず間に設置したゲートウェイを通過しなくてはならないため、単一障害点の懸念や、ゲートウェイを通過しない通信の「アクセス制御」といった懸念がでてくるのかと思います。またこのような懸念を持たれる背景として昨今のパブリッククラウド、プライベートクラウドの台頭や、ハイブリットクラウドなど様々な環境にサーバを分散配置している場合の「アクセス制御」に不安を覚えている方が増えているのではないでしょうか。
図６ ゲートウェイ方式の懸念点
まず、①の単一障害点への懸念点ですが、これは一般的によくある分散配置、冗長化構成を取ることで対応が可能です。ゲートウェイ方式は構成がシンプルであり「アクセス制御」や「ログ管理」を一元管理しているため、障害点に対する冗長化構成もシンプルに検討することが可能です。
次に、②～④のゲートウェイを通過しない「アクセス制御」への懸念点ですが、ゲートウェイ方式は「特権ID/パスワード払出」機能を利用します。「特権ID/パスワード払出」機能はゲートウェイ側で特権ID及びパスワードの払い出しを行う機能のことで、一時的に払い出された特権IDとパスワードをユーザに通知することでゲートウェイを通過しないサーバやクラウド環境への「アクセス制御」を行うことが可能です。
図７ ゲートウェイ方式の懸念点に対する対応
傾向２ エージェント方式のゲートウェイ化が進んでいる
次にエージェント方式の最近の傾向をみていきたいと思います。
以前はゲートウェイ方式、エージェント方式と明確に区別できていたのですが、最近では方式の短所を補うために別の方式を混ぜ込んだハイブリット方式というのもでてきています。
例えばエージェント方式では導入・運用・保守の負荷を下げるため、クライアントと本番サーバ間に踏み台サーバを配置し、その踏み台サーバにエージェントをインストールする方式で提供するベンダーもあります。
一見ゲートウェイ方式と同じように見えますが、根本としてはエージェントのインストールが必須の方式です。ゲートウェイ型エージェント方式は本記事で整理した長所短所の中の導入の負荷を緩和することが可能ですが、他の項目については大きな変化はありません。むしろ踏み台サーバの管理やネットワーク構成が複雑化して逆に管理コストが増える懸念があることに注意が必要です。
図８ エージェント方式のゲートウェイ化
最後に
ここまでで特権ID管理製品の方式について、様々な観点でどのような影響があるのかを見てきました。どの方式もそれぞれ長所短所があり、検討するポイントが多岐にわたります。
一方で短所についても方式変更や機能の追加、別製品との組み合わせを検討することである程度解消・緩和することができます。どの方式が皆様の管理しているシステムに最もフィットするかは、既存システムの構成や、実現したいこと、コスト感で異なります。是非今回整理したポイントを踏まえて、皆様が管理しているシステムに特権ID管理製品を導入する際の一つの指標にしていただければと思います。
SecureCube Access Checkについて
NRIセキュアでは、特権IDに対するアクセス制御とログ監査、申請・承認、証跡確認を短期間・低コストで実現できる特権ID管理ソリューション「SecureCube Access Check」（セキュアキューブ・アクセスチェック）を提供しています。
情報セキュリティ専門企業として、今回整理したデファクトスタンダードになりつつあるゲートウェイ方式を15年以上前から製品に取り込み、時代の流れから生じた方式の短所に対しても積極的に機能の拡充を行い克服しています。
特権ID管理製品を検討しており決め手にかけている方、懸念点がある方、さらに詳しく説明を聞きたいという方は、お気軽にNRIセキュアまでお問い合わせください。
SecureCube Access Checkの特長
・特権ID管理に必要なすべての機能をオールインワンソリューションで提供
・導入・運用・保守が容易なゲートウェイ方式で提供しエージェントの配布が不要
・小規模から大規模環境へも柔軟に対応可能
・監査業務を効率化する監査支援機能の提供
＜詳しくはこちら＞
特権ID管理のオールインワンソリューション「SecureCube Access Check」
