セキュリティーをチューニングして、性能と機能のバランスをとることができます。
このバランスをとるために、一般的なセキュリティー、
Common Secure Interoperability バージョン 2 (CSIv2)、Lightweight Directory Access
Protocol (LDAP) 認証、Web 認証、および許可のチューニングについての考慮事項に従います。
このタスクについて
パフォーマンスにおいては、一般に、機能とスピードが相反する関係にあります。
通常、機能が多く、それに含まれる処理が多いほど、
パフォーマンスは遅くなります。自分の環境にはどのタイプのセキュリティーが必要であり、何を使用不可にできるかを検討してください。
例えば、ご使用のアプリケーション・サーバーが Virtual Private Network
(VPN) で稼働している場合は、
Secure Sockets Layer (SSL) を使用不可にすることができるかどうかを検討します。
多くのユーザーが存在する場合、ユーザーをグループにマップし、Java 2 Platform
Enterprise Edition (J2EE) の役割に関連付けることができますか?
これらの疑問は、セキュリティー・インフラストラクチャーを設計するときの考慮事項です。
プロシージャー
- 一般セキュリティーのチューニングに対する以下の推奨事項を考慮します。
- サーバーにどのコードが配置されているかが正確にわかっており、
プロセス・リソースを保護する必要がない場合は、Java 2 セキュリティー・マネージャーを
使用不可にすることを検討します。
これを行う際には、ローカル・リソースがある程度危険にさらされることに留意してください。
- デプロイメント・マネージャーとノード・エージェントを
再始動して新規のセキュリティー・ポリシーを変更する前に、
新しいセキュリティー設定をすべてのノードに伝搬することを検討してください。
複数のサーバー全体のセキュリティー構成に一貫性がないと、
アクセス否認エラーが発生します。
したがって、
管理セキュリティーを使用可能にしたり使用不可にしたりする場合は、
新規のセキュリティー設定を伝搬する必要があります。
構成変更は、一般に、構成の同期を使用して伝搬されます。
自動同期が使用可能になっている場合は、自動同期のインターバルが来るのを待つことも、その前に強制的に同期を行うこともできます。
手動で同期する場合には、すべてのノードを同期する必要があります。
セルが構成状態にあり、セキュリティー・ポリシーが、
セキュリティーを使用可能にしたノードと使用不可にしたノードで混在している場合
は、syncNode ユーティリティーを使用して、新規の設定が伝搬されていないノードを
同期化することができます。
分散環境でセキュリティーを使用可能にすることの詳細については、
レルムのセキュリティーの使用可能化
を参照してください。
- 環境が十分セキュアであると思われる場合は、
キャッシュとトークン・タイムアウトを増やすことを検討します。これらの値を増やすと、
再認証を行う回数が減ることになります。
このアクションを実行すると、以降の要求が、すでに作成済みのクレデンシャルを
再使用できるようになります。トークン・タイムアウトを大きくすることの欠点は、
トークンをハッキングされる危険にさらし、ハッカーに、トークンの有効期限が切れる前に
システムに侵入する時間を多く与えてしまう点にあります。
セキュリティー・キャッシュ・プロパティーを使用して、1 次および
2 次の hashtable キャッシュの初期サイズを決定できます。
これは、再ハッシュの頻度とハッシュ・アルゴリズムの配布に影響します。
これらのプロパティーのリストについては、
セキュリティー・キャッシュ・プロパティー
を参照してください。
- 管理コネクターを、Simple Object Access Protocol (SOAP) から
Remote Method Invocation (RMI) に変更することを検討します。
これは、SOAP が完全にステートレスであるのに対して、RMI はステートフル接続を使用するためです。
ベンチマークを実行して、環境内でパフォーマンスが向上しているかどうかを判別してください。
- wsadmin スクリプトを使用して、すべてのユーザーやグループ
のアクセス ID を入力し、アプリケーションの始動を高速化します。アプリケーションに多数のユーザーやグループが
含まれている場合、または、アプリケーションを頻繁に停止したり始動したりする場合は、
このアクションを行ってください。WebSphere Application Server は、ユーザーとグループの名前を、
許可テーブル内にある固有のアクセス ID にマップします。
アクセス ID の正確なフォーマットは、リポジトリーによって異なります。
アクセス ID は、アプリケーション・デプロイメントの間、およびその後にのみ決定できます。
アセンブル時に作成された許可テーブルには、適切なアクセス ID がありません。
アクセス ID を更新する方法について詳しくは、
AdminApp オブジェクトのコマンド
を参照してください。
オブジェクト・リクエスト・ブローカー (ORB) のチューニングを検討します。
これは、セキュリティーが使用可能であるかないかにかかわらず、ORB がエンタープライズ Bean
パフォーマンスに影響を与えるものであるためです。
ORB チューニング・ガイドラインのトピックを参照してください。
- SSL を使用している場合は、項目
セッション管理設定
で説明されているように、SSL セッション・トラッキング・メカニズム・オプションを使用可能にします。
場合によっては、
非制限 Java Cryptography Extension (JCE) ポリシー・ファイルを使用すると、パフォーマンスが改善されます。
項目、Web サービス・セキュリティーのチューニングを参照してください。
- 単一のマシンで、ワークロードを 1 つの Java 仮想マシン (JVM) ではなく
複数の JVM に分散させると、許可決定の競合が少なくなるため、
セキュリティーのパフォーマンスが向上します。
- 以下のステップを考慮して、
Common Secure Interoperability バージョン 2 (CSIv2) プロトコルをチューニングします。
- 以下のステップを考慮して、
Lightweight Directory Access Protocol (LDAP) 認証をチューニングします。
- 管理コンソールで、「セキュリティー」>「管理、アプリケーション、およびインフラストラクチャーの保護」とクリックします。
- 「ユーザー・アカウント・リポジトリー」の下で、
「使用可能なレルム定義」ドロップダウン・リストをクリックして、
「スタンドアロン LDAP レジストリー」を選択し、さらに「構成」をクリックします。
- 大/小文字の区別が重要でない場合は、
スタンドアロン LDAP レジストリー構成の「許可検査で大/小文字を区別しない」オプションを選択します。
- 「接続の再利用」オプションを選択します。
- ご使用のの LDAP サーバーがサポートするキャッシュ機能を使用します。
- IBM Tivoli Directory Server を使用している場合は、
IBM Tivoli Directory Server または SecureWay のいずれかのディレクトリー・タイプを選択します。
IBM Tivoli Directory Server は、
新規グループ・メンバーシップ属性を使用してグループ・メンバーシップ検索を改善するようにプログラミングされているため、
パフォーマンスが向上します。ただし、IBM Tivoli Directory Server を使用するには、
許可が大/小文字を区別しない必要があります。
- iPlanet Directory ユーザーの場合、iPlanet Directory Server
(Sun ONE とも呼ばれる) または Netscape をディレクトリーとして選択してください。iPlanet
Directory Server ディレクトリーを使用すると、グループ・メンバーシップ検索のパフォーマンスを向上させる
ことができます。ただし、グループ・メカニズムに使用されるのは、役割のみです。
- 以下のステップを考慮して、Web 認証をチューニングします。
- 環境が十分セキュアであると思われる場合は、キャッシュとトークン・タイムアウトの値を増やします。Web 認証情報は、これらのキャッシュに保管されており、認証情報がキャッシュ内にある限り、認証のためにログイン・モジュールが呼び出されることはありません。
これにより、以後の要求で、すでに作成されたクレデンシャルを再使用することができます。
トークン・タイムアウトを大きくすることの欠点は、
トークンを盗まれる危険にさらし、ハッカーに、トークンの有効期限が切れる前に
システムをハッキングする時間を多く与えてしまう点にあります。
これらのプロパティーのリストについては、
セキュリティー・キャッシュ・プロパティー
を参照してください。
- シングル・サインオン (SSO) を使用可能にします。SSO を構成するには、
「セキュリティー」>「管理、アプリケーション、およびインフラストラクチャーの保護」をクリックします。
「Web セキュリティー」の下の「シングル・サインオン (SSO)」をクリックします。
SSO は、
「認証メカニズムおよび有効期限」パネルで、
認証メカニズムとして「LTPA」を構成する場合に限り使用可能です。
「認証メカニズムおよび有効期限」パネル上で、
認証メカニズムとして Simple WebSphere Authentication Mechanism (SWAM) を選択することができますが、
SWAM はバージョン 6.1で使用すべきではなく、
SSO をサポートしません。
SSO を選択すると、同じ SSO ドメイン内の複数のアプリケーション・サーバーへの要求を行う場合に、
1 つのアプリケーション・サーバーに対する単一認証で十分です。
SSO が望ましくない状況がいくつかあり、そのような状況では SSO を使用しません。
- この機能が必要でない場合は、シングル・サインオン (SSO) パネルで
「Web インバウンド・セキュリティー属性の伝搬」オプションを使用不可または使用可能にします。
場合によっては、この機能を使用可能にすると、パフォーマンスが向上します。
通常、この向上が見られるのは、
大量のユーザー・レジストリー呼び出しがパフォーマンスを
低下させているような高ボリュームのケースです。
また、場合によっては、この機能を使用不可にすると、パフォーマンスを向上することができます。
通常、この向上が見られるのは、
ユーザー・レジストリー呼び出しが大量のリソースを使用していない場合です。
- 以下のステップを考慮して、許可をチューニングします。
- ユーザーをユーザー・レジストリー内のグループにマッピングします。
Java 2 Platform, Enterprise Edition (J2EE) 役割とグループを関連付けます。この関連付けにより、
ユーザー数が増加するにつれてパフォーマンスが大きく向上します。
- エンタープライズ Bean に method-permission を慎重に割り当てます。例えば、アスタリスク (*) を使用して、
method-name エレメント内のすべてのメソッドを示します。
エンタープライズ Bean 内のすべてのメソッドが同じアクセス権を必要とする場合は、method-name に
アスタリスク (*) を使用して、すべてのメソッドを指定します。
このように指定すると、デプロイメント記述子のサイズを小さくして、
デプロイメント記述子のロードに必要なメモリーを削減することができます。
さらに、エンタープライズ Bean メソッドの method-permission の一致を検索する時間も短縮されます。
- サーブレットに security-constraint を慎重に割り当てます。例えば、URL パターン *.jsp を使用して、すべての JavaServer Pages (JSP) ファイルに同じ認証データ制約を適用することができます。
指定された URL の場合、デプロイメント記述子における完全一致が、
最長のパスの一致より優先されます。セキュリティー制約内で指定された URL に対して、
完全一致も、最長のパスの一致もない場合は、
拡張子 *.jsp、*.do、*.html の一致を使用します。
- Java 2 セキュリティーを使用する場合は、
新しいチューニング・パラメーターを使用します。 新しいチューニング・パラメーターは、
パフォーマンスを大幅に改善し、読み取り専用サブジェクト という新しい概念を取り入れています。この概念を採用することにより、コンテナー管理の認証データ・エイリアスを使用する場合に J2C 認証サブジェクトの新規キャッシュを
使用できるようになります。J2C 認証サブジェクトを作成後に変更する必要がない場合は、
次の新規チューニング・パラメーターを使用して Java 2 セキュリティーのパフォーマンスを
改善することができます。
- com.ibm.websphere.security.auth.j2c.cacheReadOnlyAuthDataSubjects=true
- com.ibm.websphere.security.auth.j2c.readOnlyAuthDataSubjectCacheSize=50
(これは、キャッシュのハッシュ・テーブルに含まれるサブジェクトの最大数です。キャッシュが
このサイズに達すると、エントリーの一部が消去されます。役割ベースのセキュリティーと Java 2 セキュリティーを同時に使用する場合にパフォーマンスを改善するためには、このサイズを固有サブジェクトの数 (ユーザー・プリンシパルの固有性に基づくキャッシュ + 認証データ・エイリアス + 管理対象接続ファクトリー・インスタンス) と同じにする必要があります。)
- 新しいチューニング・パラメーターを使用して、
セキュリティー属性伝搬のパフォーマンスを改善します。 新しい
チューニング・パラメーターは、管理コンソールのカスタム・プロパティーによって、
セキュリティー属性伝搬の余分なオーバーヘッドを減らすように設定できます。
- com.ibm.CSI.disablePropagationCallerList=true
- com.ibm.CSI.propagateFirstCallerOnly=true (最初の呼び出し元のみを追跡する場合に
使用します)。
結果
パフォーマンス、機能、およびセキュリティーの間には、常にトレードオフがあります。一般に、セキュリティーにより、要求の処理時間が長くなりますが、
それは当然の理由です。
使用している環境に、すべてのセキュリティー機能が必要であるとは限りません。
セキュリティーのチューニングを行う場合、変更した結果パフォーマンス
が向上しているかどうか確認するために、変更を行う前にベンチマークを作成します。
次の作業
大規模なデプロイメントでは、パフォーマンスが非常に重要です。
異なる機能を組み合わせてベンチマーク測定を実行すると、
使用している環境における最高のパフォーマンスと有利な構成との関係を判別するのに役立ちます。環境内で変化があった場合は、その変更による影響を判別するために、ベンチマークを引き続き実行します。