エンカレッジ・テクノロジ通信 連動コラム

第9回:まとめ:失敗しない特権アカウント管理ツールの選定のポイント

2017年4月より連載してまいりましたコラム「毎月5分で学ぶ特権アカウント管理のAtoZ」も今回が最終回です。本連載コラムでは、特権アカウントとそのリスク、対策のポイント、広がる適用領域など、様々な観点について説明をしてまいりました。
最終回となる今回は、「失敗しない特権アカウント管理ツールの選定方法」と題して、特権アカウント管理ツールの選定方法について解説します。

ポイント1 現状のアセスメントから必要な要件を定める


1つ目のポイントは、「特権アカウント」に関する現状の管理方法の実態とそのリスクの内容の把握、それを解決するための対策立案といったアセスメントを行い、その結果から製品としての要件を定めることです。このアプローチは、特権アカウント管理製品に限ったものではありませんが、一般的な業務アプリケーションと異なり、製品によって提供される機能がそれぞれ異なり、比較しづらいことから、特に要件を明確にしておく必要が高いと言えます。

表1. 特権アカウント管理の現状アセスメント例
現状 対処が必要なリスク 講じるべき対策
・システムの運用管理は主に外部ベンダーによる定期訪問+緊急時のリモートアクセスにて実施している。

・特権アカウントは、3か月に一度、パスワード変更をしている。ベンダーが作業を行う際は、セキュリティ担当者がログイン手続きを行うようにし、パスワードを教えることはない。

・ベンダーがリモートでアクセスする際には、作業者にIDとパスワードを通知、作業終了後も定期変更までパスワードを変更することはしていない。

・社内システム部員が特権アカウントを使用してサーバーへアクセスする場合が時々発生するが、その際にもID/パスワードを通知している。

・特権アカウントを使用する場合には、インターネットに直接運用ル―ムで作業を行うが、インターネット接続セグメントからも実際にはアクセス可能。緊急時には、直接インターネット接続セグメントからアクセスする場合がある。
・ベンダーのリモートアクセスおよび社員によるアクセスおいて、パスワードを通知することにより、その第三者への漏えい、なりすましのアクセスのリスクが存在する。

・悪意のある外部者からの攻撃を受けた場合に、特権アカウントの認証情報を奪われ、重要システムに不正アクセスされる恐れがある。
・ベンダーのリモートアクセス時であっても、認証を代行し、パスワードを通知しない対策。

・特権アカウントを使用の都度、パスワード変更する仕組み。

・インターネット接続セグメントから重要サーバーに特権アカウントで接続する場合でも、直接メール送受信を行うような端末上で特権アカウントのパスワードを使用しない仕組み。

・特権アカウントの使用状況(正常・不正)が把握できるようなログ収集と点検の仕組み。
・作業中可能な限り社員による立ち会いを実施しているが、人員不足もあり徹底できていない。

・緊急時のリモートアクセスについては、立ち合い自体が存在しない。

・ベンダーおよび社員による操作内容の記録は、OS標準の監査機能でログとして取得しているものの、そのログを分析することは実施していない。
・特権アカウントを使用した作業に対する監視が徹底できておらず、立ち合いのない時間に、権限の濫用を許してしまう。

・リモートアクセス時においては、監視の仕組みそのものが存在せず、不正な操作を抑制することができない。

・問題発生時に、その検証、原因究明を行うためログを分析する必要があるが、その分析手法が確立されていないため、相当な時間を要する可能性がある。
・リモートアクセス時を含め、操作内容を監視・記録する仕組み。

・リスクの高い禁止操作に対して、リアルタイムにアラートが送られるような仕組み。

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

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

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


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

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

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

ポイント3 比較すべき3大機能ポイントとは?

3つ目のポイントは、機能要件の中でも、特に理解の齟齬が生じやすく、「こんなはずではなかった」とトラブルの原因になる機能要素となります。弊社の多くのお客様に対するご提案活動の経験上、以下の3点について、注意が必要です。

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


特権アカウントの貸出プロセスを担うワークフロー機能は、特権アカウント管理製品の重要機能であり、ほとんどの製品が機能としては保有しています。しかしながら、企業が求めるワークフローの機能は、組織・体制、職務分掌規定や実際のシステム運用の実態などによってさまざまであり、単純な申請・承認だけのワークフローでは要件を満たせない場合が存在します。例えば、以下のような要件は、比較的よくある内容です。

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

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

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


特権アカウントを使用したアクセスの内容を動画やテキストで記録する機能は、前述したリスク要因と照らし合わせると重要な要件になります。しかしこの操作記録の取得については、選定候補製品のアーキテクチャーによって取得方法・システム構成が大きく異なり、取得のための前提条件が存在する場合もあるため、それらが許容可能なものかを確認する必要があります。以下は操作記録の取得の主な方式と注意点になります。

  • エージェント方式
    記録を取得する対象のサーバーや端末に専用プログラムをインストールして操作記録を取得する方式です。この場合、管理対象がサーバーの場合に、サーバーにプログラムが必要なのか、接続元である端末にプログラムをインストールする方法でも対応可能なのか、インストールする場所によってどのような制限が生じるのかを確認することが重要です。一般的には、サーバーに追加プログラムをインストールする場合、既存システムへの影響などの懸念が大きく、端末側で対応したい要望が多い傾向にありますが、端末側のプログラムで、サーバーに対しての克明な操作が解析可能な形で記録できるのか(コマンド内容の分析、危険操作の特定など)、記録が残せない条件などはあるのかなどについて、確認が必要です。
  • ゲートウェイ方式
    操作元の端末とサーバーのネットワーク経路にゲートウェイサーバーを配置し、ゲートウェイサーバーを経由してやり取りされる操作を記録する方式です。この方式は、端末やサーバーに追加のプログラムを必要としない点で、歓迎されがちですが、記録取得のための前提条件や必要なネットワーク設定等が存在する場合がありますので、確認が必要です。
    ■特定ポートに対するプロキシ機能を応用している場合には、該当するポートがプロキシ経由でないと通過できないようなネットワークの設定を行わないと、ゲートウェイを経由せずにアクセスできてしまい、結果として記録取得の対象にならないか?
    ■製品導入後も既存のサーバーアクセスツール(ターミナルソフト、リモートアクセスツール)を使って作業が可能かどうか。

特に、サーバーアクセスツールについては、従来から使用しているツールが使用できず、特権アカウント管理製品が提供するツールを使用しなければならない場合、作業者のユーザーエクスペリエンスが大きく変わることで、作業効率が極端に低下する可能性もあるため、必ず確認すべきポイントです。中には、従来のツールは使用できても、その場合には操作記録が取得できない、操作記録を取得する場合には、特権アカウント管理ツールが提供または指定するアクセス方法を使用しなければならないといったケースも存在します。

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


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

特権アカウント管理製品として、製品が提供する管理機能・プロセスによって不正アクセスの予防的対策を実現するものの、その機能が破られて不正にアクセスされた場合の発見的手段を製品機能として持たないといった場合には、このリスク要因に対し別の手立てが必要になってきます。
つまり、監査・点検レポートとして出力される内容が、特権アカウント管理製品を介して行われた正常なアクセスのみを対象にしており、特権アカウント管理製品を介さずにあとから作成されたIDを含めて不正に使用された形跡があるかどうかを確認できるようなレポートが存在するかといった点は、確認すべき重要なポイントと言えます。

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

2017年4月から掲載してまいりました連載コラム「特権アカウント管理のA to Z」は、以上で終了です。最後までご覧いただき、ありがとうございました。2018年は、また別のテーマでコラムを掲載していく予定です。今後とも是非、ご覧いただけますようお願いいたします。