セキュリティーをチューニングして、性能と機能のバランスをとることができます。
このバランスをとるために、一般的なセキュリティー、
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 サービス・セキュリティーのチューニングを参照してください。
- 以下のステップを考慮して、
Common Secure Interoperability バージョン 2 (CSIv2) プロトコルをチューニングします。
- ユーザー ID とパスワードの代わりに、Secure Sockets Layer (SSL) クライアント証明書を使用して、
Java クライアントを認証することを検討します。
すでに SSL 接続は確立されているため、相互認証を使用しても、
ユーザー ID やパスワードを含むサービス・コンテキストを完全に除去する間に
追加されるオーバーヘッドはほとんどありません。
- あまりセキュリティーが重要でない大量のデータを
送信する場合は、暗号の強度を下げます。
暗号化を必要とするデータが多く、また、その暗号の強度が高いほど、
暗号化に要する時間は長くなります。データが機密でない場合は、128 ビットの暗号による無駄な処理をしないようにしてください。
- ダウンストリーム代行のために ID アサーションを使用する場合は、トラステッド・サーバー ID のリストにアスタリスク (*) のみを入れる (つまりすべてのサーバーをトラストする) ことを検討します。
このトラストを提供するために、サーバー間で SSL 相互認証を使用します。
SSL ハンドシェークにこの追加のステップを追加すると、
アップストリーム・サーバーを完全に認証してトラストされたリストをチェックするよりも、
パフォーマンスが良くなります。
アスタリスク (*) が使用されている場合は、ID トークンがトラストされます。SSL 接続は、
クライアント証明書認証を介してサーバーをトラストします。
- CSIv2 用にステートフル・セッションが使用可能であることを確認します。
これはデフォルトですが、
最初の要求時と、以降のトークンの有効期限が切れたときにのみ認証が必要になります。
- WebSphere Application Server バージョン 5 以上のサーバーとのみ通信を行う場合は、
アクティブ認証プロトコルを、CSI および SAS ではなく、CSI にします。
このアクションにより、クライアント・サイドとサーバー・サイドの両方における
各要求に対するインターセプター呼び出しが除去されます。
- 純粋な Java クライアントの場合、Object Request Broker
(ORB) コールバックに使用するサーバー・ソケットの作成を使用不可にできます。
WebSphere Application Server バージョン 5 以降を実行するサーバーと通信している場合に限りこのステップを実行してください。
- sas.client.props ファイルで、com.ibm.CSI.claimTransportAssocSSLTLSRequired=false および
com.ibm.CSI.claimTransportAssocSSLTLSSupported=false を追加します。
- sas.client.props ファイル内で both ではなく csiv2 にアクティブ・プロトコルを設定します。
プロトコル・プロパティーを com.ibm.CSI.protocol=csiv2 に変更します。
- 以下のステップを考慮して、
Lightweight Directory Access Protocol (LDAP) 認証をチューニングします。
- 管理コンソールで、
「セキュリティー」>「グローバル・セキュリティー」とクリックします。
- 「ユーザー・レジストリー」の下の「LDAP」をクリックします。
- 大/小文字の区別が重要でない場合は、
WebSphere Application Server 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 認証をチューニングします。
- 以下のステップを考慮して、許可をチューニングします。
- ユーザーをユーザー・レジストリー内のグループにマッピングします。
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 の一致を使用します。
結果
パフォーマンス、機能、およびセキュリティーの間には、常にトレードオフがあります。一般に、セキュリティーにより、要求の処理時間が長くなりますが、
それは当然の理由です。
使用している環境に、すべてのセキュリティー機能が必要であるとは限りません。
セキュリティーのチューニングを行う場合、変更した結果パフォーマンス
が向上しているかどうか確認するために、変更を行う前にベンチマークを作成します。
次の作業
大規模なデプロイメントでは、パフォーマンスが非常に重要です。
異なる機能を組み合わせてベンチマーク測定を実行すると、
使用している環境における最高のパフォーマンスと有利な構成との関係を判別するのに役立ちます。環境内で変化があった場合は、その変更による影響を判別するために、ベンチマークを引き続き実行します。