Webアクセス管理

ウェブアクセス管理WAM[1]は、ウェブリソースへのアクセスを制御し、認証管理、ポリシーベースの承認、監査およびレポートサービス(オプション)、およびシングルサインオンの利便性を提供するアイデンティティ管理の一種です

認証管理とは、ユーザー(またはアプリケーション)のIDを特定するプロセスです。これは通常、ユーザー名とパスワードの入力を求めることで行われます。その他の認証方法としては、アクセストークン(ワンタイムパスワードを生成する)やデジタル証明書などがあります。

ユーザー(またはプロセス)のIDが確認されると、ポリシーベースの認可が機能します。Webリソースには、例えば「社内従業員のみにこのリソースへのアクセスを許可する」や「管理者グループのメンバーのみにこのリソースへのアクセスを許可する」といった、1つ以上のポリシーを付与できます。要求されたリソースはポリシーの検索に使用され、その後、ポリシーはユーザーのIDと照合されます。ユーザーがポリシー評価に合格した場合、リソースへのアクセスが許可されます。不合格の場合、アクセスは拒否されます。

認証または承認ポリシーの決定が行われた後、次のような結果を監査目的で記録できます。

  • ユーザーの最終ログイン時刻を確認する
  • 保護されたリソースへのアクセスの試みを特定する
  • 管理アクションのログ記録

エンドユーザーにとってのメリットとして、Webアクセス管理製品はこれらのセキュリティを統合し(これはIT部門や管理スタッフにとってよりメリットとなります)、シングルサインオン(ユーザーがWebリソースに一度ログインするだけで、関連するすべてのリソースに自動的にログインできるプロセス)を提供できます。ユーザーは、1日を通して複数のWebサイト(それぞれ異なるユーザー名とパスワードを使用している可能性があります)に認証を試みることになり、不便を感じることがあります。Webアクセス管理製品は最初の認証を記録し、他のすべての保護されたリソースへの認証用の一時的なトークンとして機能するCookieをユーザーに提供することで、ユーザーのログインを一度だけで済みます。

歴史

Web アクセス管理製品は 1990 年代後半に登場し、当時はシングル サインオンと呼ばれていました。最初の製品としては、Hewlett-Packard のHP IceWall SSO、CA Technologies SiteMinder、Oblix Access Manager、Magnaquest Technologies Limited のIAM (Identity and Access Management)、Novell iChain の 5 つがありました。これらの製品は機能的にはシンプルでしたが、当時の重要な問題を解決していました。それは、ユーザーに複数回のログインを強いることなく、複数のドメイン間でユーザーの認証情報を共有する方法でした。この課題は、Cookie がドメイン固有であるため、ユーザーをある Web サイトから別の Web サイトにシームレスに転送する簡単な方法がなかったことに起因していました。製品には、ユーザーの認証に加えて、ユーザーがアクセスできるリソース (Web ページ) を制御する機能も追加されたため、新しい用語が Web アクセス管理と呼ばれるようになりました。

アーキテクチャ

Web アクセス管理アーキテクチャには、プラグイン (または Web エージェント)、プロキシ、トークン化の 3 種類のアーキテクチャがあります。

プラグインは、すべてのWebサーバー/アプリケーションサーバーにインストールされ、これらのサーバーに登録され、Webページへのリクエストごとに呼び出されるプログラムです。プラグインはリクエストを傍受し、外部のポリシーサーバーと通信してポリシーを決定します。プラグイン(またはエージェント)ベースのアーキテクチャの利点の一つは、特定のWebサーバー固有のニーズに合わせて高度にカスタマイズできることです。欠点の一つは、あらゆるプラットフォーム上のあらゆるWebサーバー(場合によってはあらゆるサーバーのバージョン)に異なるプラグインが必要になることです。さらに、テクノロジーの進化に伴い、エージェントのアップグレードは分散化され、進化するホストソフトウェアとの互換性が確保される必要があります。

プロキシベースのアーキテクチャは、すべてのWebリクエストがプロキシサーバーを経由してバックエンドのWebサーバー/アプリケーションサーバーにルーティングされる点で異なります。ベンダー固有のアプリケーションプログラミングインターフェース(API)ではなく、共通の標準プロトコルであるHTTPが使用されるため、Webサーバーとのより汎用的な統合が可能になります。欠点の一つは、プロキシサーバーを実行するために追加のハードウェアが必要になることです。

トークナイゼーションは、ユーザーがバックエンドのWebサーバー/アプリケーションサーバーに直接アクセスできるトークンを受け取るという点で異なります。このアーキテクチャでは、認証はWebアクセス管理ツールを介して行われますが、すべてのデータはWebアクセス管理ツールを経由せずに送信されます。これにより、プロキシベースのアーキテクチャによって発生するネットワークのボトルネックが解消されます。欠点の一つは、バックエンドのWebサーバー/アプリケーションサーバーがトークンを受け入れる必要があることです。そうでなければ、Webアクセス管理ツールは共通の標準プロトコルを使用するように設計する必要があります。

CA SiteMinder(現CA Single Sign-On)などのソリューションは、標準ベースのフェデレーション機能を備えながら、エージェントベースとプロキシベースの両方のオプションを提供しています。P2 SecurityのmaXecurityはプロキシアプローチを採用しています。NetIQ Access Managerは、プロキシとJ2EEエージェントアプローチの両方を組み合わせたハイブリッドソリューションを提供しています。TELEGRID SMRTeはトークン化アプローチを採用しています。

費用

多くの場合、年間メンテナンス費用は購入価格をはるかに上回ります。例えば、ポリシーサーバーを使用する場合(プラグインベースとプロキシベースの両方のアーキテクチャ)、Webアクセス管理インフラストラクチャの実行に必要なワークロードを処理するには、ハイエンドのハードウェアが必要です。

集中管理は、基盤となるウェブアプリケーションのポリシー権限を専任で管理するスタッフを雇用し、トレーニングする必要があるため、隠れた追加コストとなります。最後の隠れたコストは、規制遵守に関係します。ウェブアクセス管理はファイアウォールと概念が似ているため(アプリケーション層ファイアウォールに近い)、特にサーベンス・オクスリー法の対象となる上場企業(医療保険の携行性と責任に関する法律、PCI、CPNIの対象となる企業も含む)では、主要な監査要件に対応できなければなりません。大企業は、これらのウェブアクセス管理インフラストラクチャが多くの社内および社外アプリケーションの適用ポイントとなるため、監査に膨大な時間と費用を費やしています。

参考文献

  1. ^ 「ガートナー社、WAMにOracleを選定」『ファイナンシャル・デイリー』第3巻第154号、2010年1月8日。

外部参照

  • Web アクセス管理、Gartner IT 用語集
  • Magnaquest Technologies - アイデンティティおよびアクセス管理
Retrieved from "https://en.wikipedia.org/w/index.php?title=Web_access_management&oldid=1326383933"