WebSEAL セキュリティー・ポリシー

この章では、WebSEAL セキュリティー・ポリシーの構成およびカスタマイズ方法について説明します。

この章で扱うトピックは以下のとおりです。

v 『WebSEAL 固有の ACL ポリシー』

v 113 ページの『スリー・ストライク・ログイン・ポリシー』

v 115 ページの『パスワード・ストレングス・ポリシー』

v 118 ページの『認証ストレングス POP ポリシー (ステップアップ)』

v 123 ページの『ネットワーク・ベースの認証 POP ポリシー』

v 126 ページの『保護品質 POP ポリシー』

v 126ページの『非認証ユーザーの取り扱い (HTTP/HTTPS)』

WebSEAL 固有の ACL ポリシー

保護オブジェクト・スペース内の /WebSEAL コンテナーには、以下のようなセキュリティーの考慮事項が適用されます。

v WebSEAL オブジェクトは、オブジェクト・スペースの WebSEAL 領域に対する

ACL 継承のチェーンを開始します。

v 他の ACL を明示的に適用しない場合、このオブジェクトは、Web スペース全体のセキュリティー・ポリシーを定義します (継承によって)。

v このポイントの下にあるいずれのオブジェクトにアクセスするにも、横断 (T) 許可を使用する必要があります。

Tivoli Access Manager ACL ポリシーについての詳細は、「IBM Tivoli Access

Manager Base 管理者ガイド」を参照してください。

/WebSEAL/<host>

このサブディレクトリー・エントリーは、特定の WebSEAL サーバー・インスタンス用の Web スペースの始めを表します。次のようなセキュリティーの考慮事項がこのオブジェクトに適用されます。

v このポイントの下にあるいずれのオブジェクトにアクセスするにも、横断 (T) 許可を使用する必要があります。

v 他の ACL を明示的に適用しない場合、このオブジェクトは、このマシンのオブジェクト・スペース全体のセキュリティー・ポリシーを定義することになります (継承によって)。

/WebSEAL/<host>/<file>

このサブディレクトリー・エントリーは、HTTP アクセスの際に検査されるリソース・オブジェクトを表します。検査される許可は、要求された操作によって異なります。

WebSEAL ACL 許可

以下の表は、オブジェクト・スペースの WebSEAL 領域に適用される ACL 許可について説明しています。

操作説明

r 読み取り Web オブジェクトを表示します。

x 実行 CGI プログラムを実行します。

d 削除 Web スペースから Web オブジェクトを除去します。

m 変更 HTTP オブジェクトを PUT します。 (HTTP オブジェクトを

WebSEAL オブジェクト・スペースに入れ、公表する。)

l リストポリシー・サーバーが Web スペースのディレクトリーのリストを自動的に作成する際に必要になります。

この許可は、デフォルトの index.html ページがない場合に、クライアントがディレクトリー内容のリストを見られるかどうかも制御します。

g 代行クライアントの代わりに処置をとるよう、 WebSEAL サーバーにトラストを割り当て、junction された WebSEAL サーバーにその要求を渡します。

デフォルトの /WebSEAL ACL ポリシー

デフォルトの WebSEAL ACL である default-webseal の主要エントリーには、以下のものがあります。

Group iv-admin Tcmdbsvarxl

Group webseal-servers Tgmdbsrxl User sec_master Tcmdbsvarxl

Any-other Trx

Unauthenticated T

このデフォルト ACL は、インストール時に、オブジェクト・スペース内の

/WebSEAL コンテナー・オブジェクトに付加されます。

webseal-servers グループには、セキュア・ドメイン内の個々の WebSEAL サーバーについて 1 つずつエントリーが含まれています。デフォルトの許可では、サーバーはブラウザー要求に応答することができます。

横断のアクセス許可があれば、Web Portal Manager 内で表示される Web スペースを拡張することができます。リスト許可を使用すると、Web Portal Manager で Web スペースの内容を表示することができます。

ACL 名に使用できる文字

ACL 名を作成するために使用できる有効文字は、以下のとおりです。

v A 〜 Z

v a 〜 z

v 下線 (_)

v ハイフン (-)

v 円記号 (¥)

v 2 バイト文字セットの任意の文字

ACL 名の作成方法についての詳細は、「IBM Tivoli Access Manager Base 管理者ガイド」を参照してください。

スリー・ストライク・ログイン・ポリシー

スリー・ストライク・ログイン・ポリシーは、LDAP ベースの Tivoli Access

Manager がインストールされているシステムで使用できます。このポリシーを使用

すると、ログイン試行の失敗が許される最大回数 (n) と、ペナルティー・ロックアウト時間 (x) を指定することができます。つまり、″n″ 回ログインの試行に失敗したユーザーを、″x″ 秒間ロックアウトする (すなわちアカウントを使用不可にする) ようにできます。

スリー・ストライク・ログイン・ポリシーは、コンピューターのパスワードがアタックされる (ディクショナリーへのアタックを含む) のを防ぐために使用されます。

このポリシーでは、失敗したログインの試行を再度行えるようになるための一定の時間を定めることができます。たとえば、このポリシーでは、ログインの試行に 3 回失敗したら 180 秒間のペナルティーを科すことができます。この種のログイン・

ポリシーでは、コンピューターを使用してランダムなログインが 1 秒間に何回も試行されるのを防ぐことができます。

スリー・ストライク・ログイン・ポリシーでは、次の 2 つの pdadmin policy コマンド設定が協力して働く必要があります。

v ログイン試行の失敗が許される最大回数 policy set max-login-failures

v 設定されているログイン試行の失敗が許される回数を超えた場合のペナルティー policy set disable-time-interval

ペナルティーの設定には、アカウントがロックアウトされる時間間隔の指定あるいはアカウントを完全に使用不可にする設定があります。

ログイン・ポリシー (たとえば、試行が 3 回失敗した場合のポリシー) が設定されている場合は、特定のロックアウト時間のペナルティーが科され、4 回目の試行の際には、それが正しいか間違っているかに関係なく、パスワード・ポリシーによって、アカウントが一時的に使用できなくなっていることを示すエラー・ページが表示されます。

時間間隔は、秒単位で指定されます。推奨される最小時間間隔は 60 秒です。

disable-time-interval ポリシーが ″disable″ に設定されていると、ユーザーはアカウントからロックアウトされ、このユーザーの LDAP account valid 属性は ″no″

に設定されます。アドミニストレーターは、Web Portal Manager を使用してアカウントを再び使用可能にします。

注: disable-time-interval を ″disable″ に設定すると、アドミニストレーターがアカウントを手動で再び使用可能にしなければならないため、管理オーバーヘッドが増えます。アカウントが再び使用可能にされても、更新された account

valid 情報が即時に利用できない場合があります。この状態は、複製 LDAP サ

ーバーを含む LDAP 環境とともに WebSEAL を使用している場合に、発生す

る可能性があります。この場合、更新された情報は、更新を実行する時間間隔を指定する LDAP 構成設定値に従い、LDAP レプリカに伝搬されます。

ロード・バランシングが施された WebSEAL サーバーでのアカウント・ロック・ポリシー

スリー・ストライク・ログイン・ポリシーは、指定した回数のログインが試行された後でアカウントがロックされるようにするためのものです。このポリシーが意図したとおりに働くのは、WebSEAL サーバーを 1 つだけ含む構成の場合です。ロード・バランシング・メカニズムが適用された複数のフロントエンド WebSEAL サーバーを含む構成の場合は、このポリシーの効果は、各 WebSEAL サーバーがログイン失敗の回数についてそれぞれ独自のローカル・カウントを維持しているという事実により影響を受けます。

たとえば、max-login-failures が 3 回に設定されているときに、クライアントによる最初の 3 回の試行が失敗した場合、このサーバーではそのクライアントのアカウントはロックされます。しかし、このクライアントがさらにログイン試行を続行した場合、ロード・バランシング・メカニズムは、第 1 のサーバーへの接続が失敗したことを検出し、他の使用可能な複製 WebSEAL サーバーに要求をリダイレクトします。したがって、クライアントには、さらに 3 回ログインを試行する機会が与えられることになります。

各 WebSEAL サーバーでそれぞれ試行回数 ″n″ が設定され、複製フロントエンド

WebSEAL サーバー数が ″m″ であるとすれば、1 つのサーバーで ″n″ 回の試行後

に初回のアカウント・ロックが発生することが保証されます。さらに、構成済みのすべてのサーバーで合計試行回数が ″n″ x ″m″ になるまでログインできることも保証されます。しかし、″n″ 回の試行の後で再び認証が失敗した場合、その原因が特定サーバー上のロックにあるのか、それとも、残りの複製サーバーで不正なログイン試行を続けたことにあるのかは分かりません。

″n″ x ″m″ の計算は、完全なロックアウトが生じるまでの、連続的なログイン試行の合計回数についての固定した最大上限数を表します。この数は、統計上「パスワード破り」に必要とされている試行回数よりはるかに少ないと見ることができます。

ビジネス・セキュリティー・ソリューションがスリー・ストライク・ログイン・ポリシーを必要としている場合は、ロード・バランシングが適用された複数フロント

エンド WebSEAL から成る構成がこのポリシーに与える影響をよく理解しておいて

ください。

コマンド構文

以下の pdadmin コマンドは、LDAP レジストリーで使用する場合にのみ適してい