日立 IDシステムズ

日立

ドキュメンテーション Best Practices for Managing Privileged Passwords
certification

製品情報

特権パスワード管理のベストプラクティス

Hitachi ID SystemsHitachi






Lifecycle

特権パスワード管理のベストプラクティス























© 2011 Hitachi ID Systems, Inc. All rights reserved.




はじめに

本書は、特権パスワード管理システムに関連したビジネス上の問題について記述しています。その後、パスワード管理、特権アカウントのパスワード管理、特権パスワードを安全に格納する方法、パスワード開示、特権ログインセッションの実行方法等を行うためのポリシー定義、施行ついて説明していきます。

特権アカウントは、管理者用アカウント、サービスプログラムを実行させるアカウント、他のシステムに接続するために使われる埋め込まれたアカウントを含みます。

日立 ID 特権アクセス・マネージャーは、多数のシステムに跨る特権アカウントへのアクセスに関するポリシーの定義、施行を可能にしたセキュリティ製品です。この製品により、企業は、特権アカウントにアクセスできるユーザーとプログラムの指定、いつアクセスの許可するか、どのようにアクセス有効、無効にするかなどの条件をコントロールすることができます。全てのアクセスは作業履歴に残され、監査報告の対象となります。

本書の大半は、一般的なもので、他社の特権パスワード管理システムにも該当します。日立 ID 特権アクセス・マネージャーに限定した内容は、その旨を記述しています。：

文書内でベストプラクティス例は以下のfigureマークで表示されているので参照ください。

リスクマネージメント

基本的なリスク

企業は日々のITオペレ－ションにおいて、従来にないレベルのセキュリティ問題に直面しています。例えば多数のシステ厶管理者が、数千もの機器に跨った特権アカウントのパスワードを共有しているかもしれません。このような場合、システ厶管理者の誰かが退職した後もパスワードは変更されず、同じパスワードを引き続き使用していることが多々あります。このため元職員や元契約社員によってのシステムへの不正侵入、データ改変などの攻撃を受けるリスクを高めてしまいます。

管理者用アカウントに関するその他のセキュリティ問題：

特権アカウントのアクセス権を複数の管理者で共用している場合、変更を行った管理者を特定する事は不可能です。このようなアカウンタビリティに欠ける状況は、内部統制要件から逸脱してしまう可能性があります。

企業の中には重要なパスワードを定期的に変更し、パスワードを書き留めて金庫に保管、管理している場合もあります。このような方法は安全なように思われますが、様々なビジネスリスクを引き起こす可能性があります。：

ITシステム管理者が使用する特権アカウントに加え、他のアプリケーションに接続する為に 使われる特権アカウントがあります。例えば、多くのウェブアプリケーションは、データベースや ディレクトリ、またはウェブサービスに接続する際にログインIDとパスワードを必要とします。 これらのアカウントは、それぞれ独自のセキュリティリスクを持っている可能性があります。：

迅速な処理を行い、フォールトトレランス（耐故障性）を高めるために、アプリケーションは複数のサーバーに複製されていることがあります。その場合、ログインIDとパスワードのコピーを複数のアプリケーションサーバーがプレーンテキストで格納していることになります。このため、バックエンドシステムと複数のフロントエンドシステム間で毎回変更を調整しなくてはならないため、パスワードの変更が非常に難しくなります。

最後に、バックグランドプロセスが起動しているWindowsシステムも、ログインIDとパスワードによって実行されます。サービスアカウント、スケジュールされたタスク、ウェブコンテンツへの匿名アクセス等が含まれます。多くのアプリケーションは、上記のサービスに特権が与えられた時のみに実行可能になります。この状況も、以下のビジネスリスクを発生させます：

上記の各ケースにおいて、リスクは、次のように要約することができます：

特権パスワードを安全に格納する方法

特権パスワード管理システムは、上記で説明した基本的なリスクの回避に役立ちます。：

パスワード変更は、バックエンドシステムとそれを使うプログラム（フロントエンドシステム）間で調和して行われます。

特権パスワード管理自動後の新たなリスク

特権パスワード管理システム導入後の基本的なリスクは本書で説明していますが、今後起こりうる新たなリスクも考慮しなければなりません。：

特権パスワード管理システムの保護

サーバーインフラストラクチャー

このセクションでは、どのように特権パスワード管理システムを構成し、どのように高可用性、高拡張性をサポートしていくのか説明します。

サーバーの台数と配置

特権パスワード管理システムは、基本的に２台以上の、出来れば物理的に異なる場所に設置されたサーバーに導入する必要があります。このような配置によりコンポーネントの障害によるシステム障害を防止します。 note

複数のサーバーでは、ほぼリアルタイムでのデータの複製を行うべきです。サーバー数が増えると、複製のためのトラフィック量も増加します。サーバーは物理的に異なる場所に設置されているため、複製トラフィックはWAN回線上に転送されます。最低2台のサーバーが必要ですが、逆にサーバーが多すぎる場合はシステム全体のパフォーマンスを著しく低下させることになります。このため複製した特権パスワード管理用サーバーの設置は3台以下とすることを推奨します。 note

次の課題は、ネットワーク上でのサーバーの設置場所です。全く同一のネットワークトポロジーは 存在しないため、ここでは一般的なガイダンスを示します。：

データベースの種類と配置

上記の説明は、他社の特権パスワード管理システムにも該当しますが、この後の記述は日立 ID 特権アクセス・マネージャー に限定した内容です：

ファイアウォールの使用

特権パスワード管理システムは、機密情報の開示を制御する機能を持っています。 このとき、使用する場合はどのようにファイアウォールが管理システムのセキュリティー強化の為に、ファイアウォールを使用するべきか、また使い場合どのようにファイアウォールを構成すべきかの課題が残ります。

エンドユーザーと特権パスワード管理システム間にファイアウォールを設置するのが一般的な方法です。 ユーザーインターフェイスをポートTCP/IP 443上のHTTPSで使用する場合、インバウンドコネクションをポート443のみに制限するのが直接的な方法です。

さらに、アプリケーションレベルのファイアウォール（リバースウェブプロキシとして構成）は：

特権パスワード管理システムとパスワード管理対象機器間において、ファイアウォールを使用することも可能です。各ターゲットシステムは異なったプロトコルを使用することもあるため、特権パスワード管理システムが開始した接続は許可し、その他のシステムが開始した接続はブロックするようにファイアウォールを構成する事も可能です。

最後に、特権パスワード管理システムとその内部のデータベース間にファイアウォールを設置することは、以下の理由で推奨しません：

複数の日立 ID 特権アクセス・マネージャーサーバーを保護する理想的なファイアウォールの設定は、図４　[link]を参照して下さい。

[ppm-firewall-1]
Figure: ppm-firewall-1
図４：　日立 ID 特権アクセス・マネージャーサーバーをファイアウォールで保護する方法

仮想サーバー　対　物理サーバー

以下の説明は、日立 ID 特権アクセス・マネージャー限定の内容です：

ネットワークとストレージへのインパクト

日立 ID 特権アクセス・マネージャーが一つのパスワードをランダム化する度に、データベースレコード（現在のパスワード値、パスワード履歴、ログイベント等）は、Microsoft SQL サーバーで５．１キロバイト、Oracle データベースは3.1キロバイトの容量を使います。

１つのパスワード変更に約６キロバイトを必要とするので、企業が５千の特権パスワード管理を希望し、毎日パスワードの変更を行い、３年間パスワードの保管データを保持する場合、以下の容量を持つデータベースが必要となります：

ワークフローリクエスト、システム構成等の予期しないオーバーヘッド（安全性を高めるため、要件の倍の容量を推奨）が生じることを仮定して、使用するデータベースの種類を問わず、60ギガバイトのディスクで上記のシステムを設定することをお勧めします。

Microsoft SQLサーバー、Oracle データベースのExpressエディションは、2ギガバイト以下のデータベースに限られる為、プロダクション環境ではExpressエディション（テスト、ＱＡ等にのみ 適しています）ではなく、StandardまたはEnterpriseエディション導入の必要性が非常に高くなります。

同様に、日立 ID 特権アクセス・マネージャーが変更したパスワードをサーバー間で複製する為にに、1パスワード毎に1キロバイト弱の通信が行われます。上記の企業例に当てはめますと、パスワード変更に伴い複製の為に使われる通信量は1日に約5メガバイトと推定することが出来ます。しかしワークフローリクエスト、ログイン監査記録、アクセスの開示等の複製が必要になる場合は5メガバイト以上必要になり、複製に使われる通信量は1日に約100メガバイトとなります。

上記の帯域幅は、サーバー間の複製のみに使用された場合です。更に日立 ID 特権アクセス・マネージャーとターゲットシステム間（パスワードをランダム化するため）やエンドユーザーと日立 ID 特権アクセス・マネージャー間（特権アクセスの要求と取得のため）で帯域幅は使用されます。：

ネットワークへの総合的なインパクトは、上記の概算基準（予測された特権パスワードシステムのワークロードによって変化します）を基に、システムに予想される負荷を掛け合わせることで推定できます。

サーバー規模

上記のディスカッションは、日立 ID 特権アクセス・マネージャーとデータベースをどこに配置するかを決める際に 有効ですが、各サーバーのハードウェアをどのように構成するかという課題が残ります。 以下では、2010年1月においてのコンポーネントの費用を基に、コストとパフォーマンスのバランスを保つ適切な構成方法を説明していきます：

上記のように構成された1台のサーバーは、少なくとも10万個のパスワードをターゲットシステム上で常時管理することが可能であり、同時におよそ100人のインタラクティブ性のあるユーザーセッションの サービスを行うことができます。日立 ID 特権アクセス・マネージャーウェブユーザインタフェースへのユーザーセッションは、通常最低約２分とすると、８時間業務日の間、このサーバーは24,000回の特権アクセスを処理できることになります。

導入の際、データベースのレプリカと日立 ID 特権アクセス・マネージャーソフトウェアを搭載した最低2台のサーバーを設置する必要があります。各サーバーはそれぞれ別の場所にインストールします。

バーチャルマシンは、物理サーバーと同様なディスク、I/O, CPU, メモリ容量で構成します。

ロードバランシング（負荷分散）と複製

次の課題は、２台以上の特権パスワード管理システム用サーバーを設置し、それぞれ常時アクティブである場合、両サーバーへのアクセスを可能にするには、どのようにロードバランシングの設定を行えばよいかです。

次のような様々な方法でロードバランシングを実現させることが可能です：

[ppm-load-balance-1]
Figure: ppm-load-balance-1
図５：１つのＤＮＳ名を複数のＩＰアドレスに対応させてロードバランシングを行う

[ppm-load-balance-2]
Figure: ppm-load-balance-2
図６：　リバースウェブプロキシを使用してロードバランシングを行う

[ppm-load-balance-3]
Figure: ppm-load-balance-3
図７：　異なったＩＰアドレスにルーティングしてロードバランシングを行う

上記のどの方法も実現可能ですが、DNSの使用をお勧めします。使用するDNSサーバーのソフトウェアによりますが、特別のインフラストラクチャを必要としないこと、それぞれのDNSクエリから返却されたサーバーのＩＰアドレスがユーザーに最も近いサーバーとして選択されるように設定することが可能であるからです。

例をあげて詳しく説明していきます：

どの負荷分散技術を使うかに関らず、クライアントとPPMサーバ間でのセッションは“固定”される必要があります。。すなわちセッション中は、常時同じPPMサーバーの使用が不可欠です。これにより複数のPPMサーバー間でセッションデータの複製を行う必要がなくなるため非常に重要になります。 note

特権パスワードをいつ、どのようにランダムマイズするか

特権パスワード管理システムの目的は、定期的に特権パスワードをスクランブル化することにより安全に管理することです。ユーザーまたはプロラムが実際にパスワードを必要とするまで現在のパスワード値は開示されず、パスワード開示の際には承認が必要となり、その記録が残ります。

次の問題点が挙げられます：　いつパスワードはランダムマイズされ、ランダムパスワードはどのように構成されるべきでしょうか。

アクセス開示の安全化

個人識別(Identification)，認証（Authentication）、認可（Authorization）

特権パスワード管理システムの役目は、特権パスワードのランダマイズ、その格納だけでなく、、ユーザー、アプリケーション、サービスを実行するインフラストラクチャへのパスワードの開示も行います。さもなければ、 パスワードが安全に格納された特権アカウントが使えなくなってしまいます。

パスワード開示は制御しなければなりません：

次は個人識別（Identification）認証(Authentication)プロセスのベストプラクティスを説明します。 note

アクセス開示メカニズム

特権パスワード管理システムは、通常、ITスタッフやプログラムによる特権アカウントへのアクセス制御をおこなうために構成されます。前章では、特権アカウントへのアクセスが必要なユーザーの認証と認可について説明しました。 残っている問題として、どのようにアクセス開示を行うかについては以下で説明して行きます。

アクセス開示を行う方法は、数種類あります。

並行開示（チェックイン／チェックアウト）

特権パスワード管理システムは、複数の特権アカウントへのアクセス開示を制御できますが、何人の管理者が同時に同じ特権アカウントへのアクセス権を取得できるかといったことも制御することもできます。：

以下のベストプラクティスを参考にしてください。：

並行制御を用いる場合、管理者の一人が特権アカウントへのアクセスをチェックアウトし、セッションをアクティブにしたまま、帰宅、昼食に出るなどで作業を止めた場合にリスクが発生します。最初にアクセスした管理者がセッションをアクティブにしたまま席を離れ、別の管理者が同じ時間内に同じシステムへのアクセスが必要となった場合、アクセス出来ません。このようなリスクを回避する為には、通常は1時間、最高4時間まで等の時間制限を行うことが重要になります。これにより、セッションがオープン中に不使用のために起こる、非管理期間を最小限にとどめることが可能です。

2番目に考慮する点は、特権アカウントのアクセス権を取得したユーザーにパスワードを表示する場合はどのように並行制御を施行するべきかということです。パスワードのチェックアウト時間が経過した後も、管理者がパスワードを持っていることになり、管理者セッションを確実に終了させるためには、以下を行うことが重要です。：

アクセス開示の報告

特権パスワード管理システムが基本機能の一つは、特権アカウントを共有する管理者のアカウンタビリティを確立することです。(a)　全てのアクセス開示を記録すること　(b)この開示についてリポートを作成すること　によって行われます。

特権セッションに関しての報告書は、次の2通りの方法で生成されます：

次の重要な課題は、アクセス開示に関してのレポート生成の権限を誰に許可するかです。 報告書は、誰がどのような変更を行ったではなく、単に誰がどこにアクセスしたかを記すものです。したがって、他のユーザーのアクティビティに関しての報告を行えるように、全てのＩＴユーザーにレポート生成の権限を許可するポリシーをデフォルトで設定しても良いかも知れません。ＩＴスタッフ間で管理者用セッションは”公の情報“であるため、このプロセスを透明化することでユーザーの正しい行いを奨励することにつながります。管理者がシステムの設定に関する問題を発見した場合、即座に誰が何のために変更を行ったのか調べることができるため、透明化されたポリシーはトラブルシューティングにも大変役立ちますnote。

報告書の透明化において唯一の例外は、少人数の管理者チームが他の管理者に 知られたくない機密の変更を行う必要がある場合です。例えば、企業が大規模なレイオフの計画中で、 管理者数人がレイオフの対象になっている場合、この情報は機密扱いする必要があります。 このようなシナリオは稀ではありますが、管理者の行いに関してのポリシーの透明化をまず 基本とし、異例な状況が起こった時のみポリシーを変更するように設定することが 適切です。

他に考慮すべき点は、アクセス要求、特権アクセスセッション、生成済みのレポート等の 記録をどの位の期間保存するかです。ディスク等のハードウェアは比較的安価なため、少なくとも数年間のデータをオンラインで保管することが好ましいでしょう。note

最後に、ＩＴユーザーがレポート生成の許可をすることに加えて、ＩＴセキュリティ監査と 社内のリスク担当の幹部・役員にも同じレポートを生成できる権限を与えるべきです。実際にシステムに アクセスせずに、ＩＴスタッフが何を行っているかを見ることができるからです。 言い換えると、レポートを生成できる権限は、特権アカウントにアクセスできる権利が前提である必要はありません。

システムのモニタリングとメインテナンス

システムのモニターとメインテナンスを行うスタッフの割り当て

特権パスワード管理システムを有効に管理するためには、1/4から1人のFTE(Full Time Equivalent)要員が必要になります。システム管理をしていく役割として、プロジェクトコーディネーターとテクニカルシステムアドミニストレーターの２つのタスクを担う必要がありまず。

特権パスワード管理システムのプロジェクトコーディネーターとしての役割は以下を含みます：

プロジェクトコーディネーターは、基本的、適格なＩＴプロジェクトマネージメントの能力が必要となります。

特権パスワード管理システムのテクニカルアドミニストレーターの役割は以下を含みます：

テクニカルシステム管理者の技能は以下を含みます：

システムの健康状態をモニタリング

特権パスワード管理システムのプロダクションは、常時正しく機能しているかモニターする必要があります。

note

HP OpenViewまたはMicrosoft　Operations Manager等の一般的ななモニタリングシステムを利用して、プラットフォームのモニタリングを行うのが最も有効です。note

何らかの問題が起こった場合にメールの通知、またはトラブルチケットを発行するように特権パスワード管理システムを構成し、アプリケーションモニタリングを行うことが最も有効になります。note

セキュリティモニタリングは、ログデータのレポートを定期的に生成し、セキュリティーオフィサーに提供することが最も有効な手段です。note

ターゲットシステムとのインテグレーションの構成

システムの統合化が進むと同時に、特権パスワード管理システムの有用性も高まります。1,000台のシステムを対象に特権パスワード管理を行った時の効果を、100台の場合と比較すると明らかにより大きなセキュリティ上の恩恵を受ける事ができます。

統合化されたシステム数が増加すると、追加、維持、削除などを手動で行った場合、費用も同時に上昇します。数百以上もの統合が必要なシステムに拡張するためには、自動化が不可欠ですnote

インテグレーションの自動化とは、下記のタスクの自動化を図ることを意味します：

中～大企業の多くは、毎日ワークステーションとサーバーの追加、削除が行われます。したがって、 24時間毎に自動検出プロセスを実行することが適切です。

サーバー検索の技術的アプローチがいくつかあります。利用可能なインフラストラクチャにより、適切な方法を選んでください。：

上記で説明したメカニズムを用いてシステムを検出した後の次のステップは、ログインアカウントのリストを初期にそして定期的に生成し、どのアカウントが「特権」であるかを見極めることです。それらのアカウントは管理者レベルのグループに属し、数字によるＩＤを持ち、サービスまたはスケージュールされたタスクの実行に使用されています。

IDを列挙し、特権を与えるメカニズムはシステムにより異なります。例えば、UnixやLinuxでは、SSHスクリプトを使用してUIDが0のユーザーなのか、またはwheel, rootまたはadminのようなグループに属するのかをチェックすることができます。一方Windowsシステムに適するのは、グループメンバーシップ、Windows Service Managerの構成、スケジューラーの構成、そしてIISの構成を確認するＲＰＣ上で接続されたプログラムを使用することです。

不正に生成されたIDを発見できるように、ターゲットシステムでの特権IDの列挙は頻繁に行う必要があります。一方、自動検出プロセスは実行回数を削減し、ネットワークへのインパクトを 最小限に抑えるため、頻度を低くする必要もあります。このような相反する要件においては、 1日1回、または週1回程度に行うことがリーズナブルです。note 。

その他問題となるのが、各ターゲットシステムに初めて接続する際に、いつターゲットシステムの自動検出を行いどのクレデンシャル（証明書）使用するかです。適切なオプションは：

特権パスワード管理システムは、パスワードの変更の際にインテグレーションしたシステムへの接続を試行するため、インフラストラクチャをモニタリングする装置として使用することができます。これによりターゲットシステムに接続できなかった場合に警告することができます。この場合、管理者にＥメールで連絡、またはヘルプデスクにトラブルチケットを発行する等により注意を促すことが出来ます。

ターゲットシステムが引き続き使用不可能の場合、通常のパスワードローテーションプロセスから自動的に 削除されます。これによりデータベースをクリーンな状態に保つことができます。システムが一定の時間を超過してもオフラインの状態の時、またはシステムがその後回復した時の為、過去のパスワードのデータは、各システムにおいて保持されている必要がありますnote 。

応答しないターゲットシステムを識別するために、定期的にレポートを生成する必要があります。 これにより、システム管理者は応答のないターゲットシステムのリストと、停止されたとわかっているシステムのリストを照らし合わせることができますnote 。

本番環境への移行

特権パスワード管理システムは、企業にとって非常にセンシティブなインフラストラクチャの一部です。 本番環境に移行する前に、まず最初にテスト環境での展開を行い、システム構成の検証を行うことが不可欠です。

プロダクションに移行した後は、段階的にシステムを使用することが適切ですnote

APIの考慮事項

APIは特権パスワード管理システムに、ひとつのアプリケーションが他に接続するときに、認証に用いるセキュリティパスワードを設定します。例えば、 電子商取引専用アプリケーションは、在庫のデータを読み取る為にデータベースサーバーにサインインする必要があります。このような場合は、通常ログインIDとパスワードを使用して認証を行います。

１つのアプリケーションが認証にパスワードを使用する場合のセキュリティ問題：

これらの問題を避けるために、埋め込まれたアカウント用のパスワードを定期的にスクランブル化するために特権パスワード管理システムを使用することができます。APIは、電子商取引専用アプリケーションの各インスタンスが、特権パスワード管理システムからデータベースに接続するのに必要な最新のパスワード値を取得できるようにします。これにより固定されたパスワード、またはプレーンテキストのパスワードを排除することが出来ますが、新たな課題を提起します：

上記に疑問点に対して、どのケースにも適応するような答えを出す事はできません。企業は独自のプライオリティーを持ち、各アプリケーションはそれぞれ制約を持っているため、上記への答えも当然変わってきます。 以下は、上記の質問に対する一般的な解決方法であり、全てに適する方法ではありません。note 。

まとめ

特権パスワード管理システムは、周知された、固定的かつ安全性の低いパスワードを使用するプロセスから、頻繁なパスワード更新、堅固な個人認証、きめ細かい認可ロジック、詳細な監査履歴を持つプロセスへの転換を可能にします。

このようなシステムの展開は、システムに大きく影響をあたえます。――機密性、統合性、可用性におけるシステム障害は、大惨事に発展する恐れがあります。そのため、堅固で、フォルトトレランス、安全性を考慮し他注意深い展開手段を取ることが求められます。

本書は、特権パスワード管理システムを安全で高い可用性で、安全に、拡張性が高く、効率的に管理できることを目的としたベストプラクティスを網羅的に説明したものです。