特権ID管理は、Excelなどによる台帳管理やマニュアル管理をしているケースも少なくありませんが、近年は管理すべきシステムの種類や数が増大したり、サイバー攻撃の脅威が増していることから、特権ID管理ツールを検討する企業が増加しています。

後悔のない選定には、自社の特権アカウントの現状の整理や、ツールに求める要件を明確にする必要があります。

そこで、本コラムでは特権ID管理製品の選定で押さえるべき3つのポイントや重要な機能について解説します。

ポイント①特権アカウント管理の現状を把握して必要な要件を定める

1つ目のポイントは、「特権アカウント」に関する現状の整理です。

管理方法の現状と対処が必要なリスクの把握、そして、それを解決するための対策についてアセスメントし、その結果から製品としての要件を定めることです。

このアプローチは特権ID管理製品に限ったものではありませんが、一般的な業務アプリケーションと異なり、製品によって提供される機能がそれぞれ異なり、比較しづらいことから、特に要件を明確にしておく必要が高いと言えます。

表1：特権アカウント管理の現状アセスメント例

	現状	リスク	対策
ID・パスワード管理	特権アカウントは3か月に一度、パスワード変更をしている。	悪意のある外部者からの攻撃を受けた場合、特権アカウントの認証情報を奪われ、重要システムに不正アクセスされる恐れがある。	特権アカウントを使用の都度、パスワード変更する仕組み。
アクセス管理	システムの運用管理は主に外部ベンダーによる定期訪問＋緊急時のリモートアクセスにて実施している。 ベンダーが作業を行う際は、セキュリティ担当者がログイン手続きを行うようにし、パスワードを教えることはない。 ベンダーがリモートでアクセスする際には、作業者にIDとパスワードを通知、作業終了後も定期変更までパスワードを変更することはしていない。 特権アカウントを使用する場合、インターネットに直接運用ル―ムで作業を行うが、インターネット接続セグメントからも実際にはアクセス可能。緊急時には、直接インターネット接続セグメントからアクセスする場合がある。	パスワードを通知することにより、その第三者への漏えい、なりすましのアクセスのリスクが存在する。	ベンダーのリモートアクセス時であっても認証を代行し、パスワードを通知しない対策。 インターネット接続セグメントから重要サーバーに特権アカウントで接続する場合でも、直接メール送受信を行うような端末上で特権アカウントのパスワードを使用しない仕組み。
作業点検・監査	作業中可能な限り社員による立ち会いを実施しているが、人員不足もあり徹底できていない。 緊急時のリモートアクセスについては、立ち合い自体が存在しない。 ベンダーおよび社員による操作内容の記録は、OS標準の監査機能でログとして取得しているものの、そのログを分析することは実施していない。	立ち合いのない時間に権限の濫用を許してしまう。 リモートアクセス時においては監視の仕組みそのものが存在せず、不正な操作を抑制することができない。 問題発生時に検証、原因究明を行うためログを分析する必要があるが、その分析手法が確立されていないため、相当な時間を要する可能性がある。	特権アカウントの使用状況（正常・不正）が把握できるようなログ収集と点検の仕組み。 リモートアクセス時を含め、操作内容を監視・記録する仕組み。 リスクの高い禁止操作に対して、リアルタイムにアラートが送られるような仕組み。

また、選定にあたっては、システム運用の形態・運用方法、対象システムの性質、プラットフォームの種類なども把握して、要件に含めておく必要があります。

表2：特権ID管理製品の選定に関する環境・運用要因

運用環境	物理セキュリティなどより基本的な対策がどの程度実施できているか？運用者はインターネット接続環境からのアクセスがあるか？
外部委託先のアクセス	委託先の技術者などが外部からアクセスする経路が用意されているか？その経路に対するアクセス管理は対策の必要があるか？
クラウド・外部データセンター	クラウドや外部データセンターに設置しているシステムについての取り扱い
プラットフォーム	管理対象サーバーのOSの種類やバージョン、OS以外の特権アカウントの管理の必要性など

ポイント②特権ID管理製品のアーキテクチャーの違いとメリット・デメリットを理解する

2点目のポイントは、特権ID管理製品のアーキテクチャーの違いとそれに伴うメリット・デメリットです。特権ID管理製品は、管理対象のサーバーに常駐プログラムを導入する必要のあるエージェント型とプログラム導入が必要ないエージェントレス型に大別されますが、エージェントレス型はさらに、ゲートウェイ型、リモートエージェント型、エンドポイント型に分類されます。

方式ごとにメリット・デメリットがあるだけではなく、方式によっては必要な要件を満たせないものがあるため留意が必要です。

例えば、管理対象サーバーにプログラムの導入を必要としないエージェントレス型は、システムの影響範囲が少ないというメリットがありますが、ゲートウェイ型ではネットワーク制御によるアクセス管理になるため、特権アカウントのパスワードを定期変更するような機能は実現できないといった例が挙げられます。

表3：特権ID管理製品の主なアーキテクチャとそのメリット・デメリット

大部類	小分類	メリット	デメリット
エージェント型	エージェント型	プログラムによって特権アカウント管理の2つの主要技術要素を網羅的に実現 リモート操作、直接コンソールから行う作業などあらゆるアクセス手段に対応	サーバー内に常駐型プログラムをインストールする必要があり、他のプログラムとの相性やキャパシティプランへの影響などを検討・確認する必要がある 管理対象のサーバー台数が多いと、導入・維持管理の負担が大きい
エージェントレス型	ゲートウェイ型	操作端末、サーバーの両方に専用プログラムをインストールする必要がない 導入は比較的容易	ゲートウェイサーバーを介さないアクセスや直接コンソール作業には、効果を発揮できない IDとパスワード管理には対応できない
	リモートエージェント型	操作端末、サーバーの両方に専用プログラムをインストールする必要がない サーバーで集中的にID/パスワードの管理が可能 導入は比較的容易	証跡管理は独自に記録するのではなく、サーバーからの情報を収集する
	エンドポイント型	操作端末、サーバーの両方に専用プログラムをインストールする必要がない リモートエージェント型と組み合わせることで共有ID貸出をより安全に提供可能	直接コンソールから行う作業には効果を発揮できない エンドポイント(端末)が多数存在する場合などには導入に手間がかかる

ポイント③比較すべき特権アカウント管理システムの4大機能要素

3つ目のポイントは、機能要件の中でも特に理解の齟齬が生じやすく、「こんなはずではなかった」とトラブルの原因になる機能要素となります。製品選定の際には以下の4つの機能要素について注意が必要です。

(1)どのようなシステムの特権アカウントを管理できるか？

特権アカウント管理システムの基本的機能要件であり、最も重要な要件です。従来特権アカウントと言えば、オンプレミスの基幹系システムが管理対象の主体でした。そのためWindows、Linux、UNIXなどのオペレーティングシステムの管理者アカウントを管理する要件が主体だったこともあり、ツールによってはこれらのシステムの管理がメインとなっている場合があります。

しかし現在、システム環境は大きく変化し、システムの一部または多くをクラウドに移行、SaaSシステムも組み合わせた構成で利用されています。

特権ID管理製品を選定する際、どのようなシステムを管理できるかを考慮する点は非常に重要ですが、現状利用しているシステムだけではなく、SaaSなど将来利用を予定しているシステムも管理対象にできるかどうかが重要です。一度導入したツールは短期間で見直すことが難しいからです。

(2)ワークフローに求める機能は十分か？

特権アカウントの貸出プロセスを担うワークフロー機能は、特権ID管理製品の重要機能であり、ほとんどの製品が機能としては保有しています。

しかしながら、企業が求めるワークフローの機能は、組織・体制、職務分掌規定や実際のシステム運用の実態によってさまざまであり、単純な申請・承認だけのワークフローでは要件を満たせない場合が存在します。

例えば、以下のような要件は比較的よくある内容です。

• 実際の作業者とは異なるユーザーによる代理申請ができること
• 組織・職務分掌に従って、複数の承認者による多段承認ができること
• アクセス理由など、承認者が申請目的を判断するための自由コメントを記入できること
• 深夜・休日の緊急作業等における承認プロセスを省略した緊急作業用ワークフローの設定

「ワークフロー機能：あり」だけで評価をしてしまうと、実際に運用した際に求める詳細要件が満たせず、非常に不便な思いをしてしまう可能性があります。

(3)操作記録の取得に条件や制限事項はないか？

特権アカウントを使用したアクセスの内容を動画やテキストで記録する機能は、前述したリスク要因と照らし合わせると重要な要件になります。

しかし、操作記録の取得は選定候補製品のアーキテクチャーによって取得方法・システム構成が大きく異なります。取得のための前提条件が存在する場合もあるため、それらが許容可能なものか確認する必要があります。

以下は操作記録の取得の主な方式と注意点になります。

エージェント方式

記録を取得する対象のサーバーや端末に専用プログラムをインストールして操作記録を取得する方式です。この方式では管理対象がサーバーの場合、サーバーにプログラムが必要なのか、接続元の端末にプログラムをインストールする方法でも対応可能なのか、インストールする場所によってどのような制限が生じるのかを確認することが重要です。

一般的にはサーバーに追加プログラムをインストールする場合、既存システムへの影響などの懸念が大きく、端末側で対応したい要望が多い傾向にあります。そのため、端末側のプログラムでサーバー操作が解析可能な形で克明に記録できるのか（コマンド内容の分析、危険操作の特定など）、記録が残せない条件などはあるのかなどについて確認が必要です。

ゲートウェイ方式

操作元の端末とサーバーのネットワーク経路にゲートウェイサーバーを配置し、ゲートウェイサーバーを経由してやり取りされる操作を記録する方式です。この方式は、端末やサーバーに追加のプログラムを必要としない点で歓迎されがちですが、記録取得のための前提条件や必要なネットワーク設定等が存在する場合があるため確認が必要です。

• 特定ポートに対するプロキシ機能を応用している場合、該当するポートがプロキシ経由でないと通過できないようなネットワークの設定を行わないと、ゲートウェイを経由せずにアクセスできてしまい、結果として記録取得の対象にならないか？
• 製品導入後も既存のサーバーアクセスツール（ターミナルソフト、リモートアクセスツール）を使って作業可能か？

特に、従来から使用しているサーバーアクセスツールが使用できず、特権ID管理製品が提供するツールを使用しなければならない場合、作業者のユーザーエクスペリエンスが大きく変わることで作業効率が極端に低下する可能性もあるため必ず確認すべきポイントです。

中には、従来のツールは使用できても、その場合には操作記録が取得できない、操作記録を取得するには特権ID管理製品が提供または指定するアクセス方法を使用しなければならないといったケースも存在します。

(4)特権アカウントの不正使用を早期発見できるか？

特権ID管理製品がカバーすべき重要な要件の一つに、「特権アカウントの不正使用を早期に発見できること」が挙げられます。特権アカウント自体があらゆる権限を保有する以上、どのような手段を用いても不正使用を完全に防止することは困難だからです。例えば、特権アカウントを正規のプロセスで使用する際に別のアカウントを作成し、パスワードを設定すれば、そのアカウント自体は自由に使用できてしまいます。

特権ID管理製品として、製品が提供する管理機能・プロセスによって不正アクセスの予防的対策を実現するものの、その機能が破られて不正にアクセスされた場合の発見的手段を製品機能として持たない場合には、このリスク要因に対し別の手立てが必要です。

つまり、監査・点検レポートとして出力される内容が、特権ID管理製品を介して行われた正常なアクセスのみを対象にしており、特権ID管理製品を介さずにあとから作成されたIDを含めて不正に使用された形跡があるかどうかを確認できるようなレポートが存在するかは、確認すべき重要なポイントです。

以上、やや専門的な内容になりましたが、特権アカウント管理の課題を解決して、安全で安定的な情報システムの実現に参考になれば幸いです。