Webアクセス管理(WAM)[1]は、Webリソースへのアクセスを制御し、認証管理、ポリシーベースの承認、監査およびレポートサービス(オプション)、およびシングルサインオンの利便性を提供するID管理の一種です。
認証管理は、ユーザー (またはアプリケーション) の ID を判別するプロセスです。これは通常、ユーザー名とパスワードの入力を求めることによって行われます。追加の認証方法としては、アクセス トークン(ワンタイム パスワードを生成する) やデジタル証明書も挙げられます。
ユーザー (またはプロセス) の ID が確認されると、ポリシー ベースの承認が実行されます。Web リソースには、たとえば「社内の従業員のみがこのリソースにアクセスできるようにする」や「管理者グループのメンバーのみがこのリソースにアクセスできるようにする」などのポリシーを 1 つ以上添付できます。要求されたリソースを使用してポリシーが検索され、その後、ポリシーがユーザーの ID に対して評価されます。ユーザーがポリシー評価に合格すると、リソースへのアクセスが許可されます。ユーザーが評価に合格しないと、アクセスは拒否されます。
認証または承認ポリシーの決定が行われた後、監査の目的で次のような結果を記録できます。
- ユーザーの最終ログイン時刻を確認する
- 保護されたリソースへのアクセスの試みを特定する
- 管理アクションのログ記録
エンド ユーザーにとってのメリットとして、Web アクセス管理製品はこのセキュリティを統合し (これは IT および管理スタッフにとってのメリットの方が大きい)、シングル サインオンを提供できます。シングル サインオンとは、ユーザーが Web リソースに 1 回ログインするだけで、関連するすべてのリソースに自動的にログインできるプロセスです。1 日を通して複数の Web サイトで認証を試みるとき (ユーザー名とパスワードが異なる可能性があります)、ユーザーは不便を感じることがあります。Web アクセス管理製品は最初の認証を記録し、他のすべての保護されたリソースへの認証用の一時的なトークンとして機能する Cookie をユーザーに提供できるため、ユーザーは 1 回ログインするだけで済みます。
歴史
Web アクセス管理製品は 1990 年代後半に登場し、当時はシングル サインオンと呼ばれていました。最初の製品のうち 5 つは、Hewlett-Packard HP IceWall SSO、CA Technologies SiteMinder、Oblix Access Manager、Magnaquest Technologies Limited IAM (Identity and Access Management)、Novell iChain でした。これらの製品は機能的にはシンプルでしたが、当時の重要な問題を解決しました。つまり、ユーザーに複数回のログインを強いることなく、複数のドメイン間でユーザー資格情報を共有する方法です。この課題は、Cookie がドメイン固有であるため、ユーザーをある Web サイトから別の Web サイトにシームレスに転送する簡単な方法がなかったことに起因していました。新しい用語は Web アクセス管理と呼ばれるようになりました。製品には、ユーザーの認証に加えて、ユーザーがアクセスできるリソース (Web ページ) を制御する機能も追加されたためです。
アーキテクチャ
Web アクセス管理アーキテクチャには、プラグイン (または Web エージェント)、プロキシ、トークン化の 3 種類のアーキテクチャがあります。
プラグインは、すべての Web/アプリケーション サーバーにインストールされ、それらのサーバーに登録され、Web ページが要求されるたびに呼び出されるプログラムです。プラグインは要求をインターセプトし、外部のポリシー サーバーと通信してポリシーを決定します。プラグイン (またはエージェント) ベースのアーキテクチャの利点の 1 つは、特定の Web サーバーの独自のニーズに合わせて高度にカスタマイズできることです。欠点の 1 つは、すべてのプラットフォームのすべての Web サーバー (およびすべてのサーバーのすべてのバージョン) に異なるプラグインが必要になることです。さらに、テクノロジの進化に伴い、エージェントのアップグレードは分散され、進化するホスト ソフトウェアと互換性がなければなりません。
プロキシベースのアーキテクチャは、すべての Web リクエストがプロキシ サーバーを経由してバックエンドの Web/アプリケーション サーバーにルーティングされるという点で異なります。ベンダー固有のアプリケーション プログラミング インターフェイス(API) の代わりに、共通の標準プロトコルである HTTP が使用されるため、Web サーバーとのより汎用的な統合が可能になります。欠点の 1 つは、プロキシ サーバーを実行するために通常追加のハードウェアが必要になることです。
トークン化は、ユーザーがバックエンドの Web/アプリケーション サーバーに直接アクセスするために使用できるトークンを受け取るという点で異なります。このアーキテクチャでは、認証は Web アクセス管理ツールを通じて行われますが、すべてのデータはその周りを流れます。これにより、プロキシベースのアーキテクチャによって発生するネットワークのボトルネックが解消されます。欠点の 1 つは、バックエンドの Web/アプリケーション サーバーがトークンを受け入れることができなければならないことです。そうでない場合は、Web アクセス管理ツールが共通の標準プロトコルを使用するように設計されている必要があります。
CA SiteMinder (現在は CA Single Sign-On と呼ばれています) などのソリューションは、標準ベースのフェデレーションを組み込んだエージェント ベースとプロキシ ベースの両方のオプションを提供します。P2 Security の maXecurity はプロキシ アプローチを採用しています。NetIQ Access Manager は、プロキシ アプローチと J2EE エージェント アプローチの両方で構成されるハイブリッド ソリューションを提供します。TELEGRID SMRTe はトークン化アプローチを採用しています。
費用
ほとんどの場合、年間メンテナンス コストは購入価格をはるかに上回ります。たとえば、ポリシー サーバーを使用する場合 (プラグイン アーキテクチャとプロキシ ベース アーキテクチャの両方)、Web アクセス管理インフラストラクチャを実行するために必要なワークロードを処理するには、ハイエンドのハードウェアが必要です。
集中管理は、顧客が基盤となる Web アプリケーションのポリシー権限を独占的に管理するスタッフを雇用してトレーニングする必要があるため、追加の隠れたコストとなります。最後の隠れたコストは、規制遵守に関係します。Web アクセス管理はファイアウォールと概念が似ているため(アプリケーション層ファイアウォールに近い)、特にサーベンス・オクスリー法の対象となる公開企業 (医療保険の携行性と責任に関する法律、PCI、または CPNIの対象となる企業は言うまでもありません)、主要な監査要件に対応できなければなりません。大企業は、これらの Web アクセス管理インフラストラクチャが多くの社内および社外アプリケーションの適用ポイントであるため、監査に膨大な時間と費用を費やしています。
参考文献
- ^ 「ガートナー社がWAMにOracleを指名」。The Financial Daily。第3巻、第154号。2010年1月8日。
外部参照
- Web アクセス管理、Gartner IT 用語集
- Magnaquest Technologies - アイデンティティとアクセス管理
