セキュリティーをチューニングして、性能と機能のバランスをとることができます。
このバランスをとるために、一般的なセキュリティー、
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) の役割に関連付けることができますか?
これらの疑問は、セキュリティー・インフラストラクチャーを設計するときの考慮事項です。
プロシージャー
- 一般セキュリティーのチューニングに対する以下の推奨事項を考慮します。
- 以下のステップを考慮して、
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 の一致を使用します。
結果
パフォーマンス、機能、およびセキュリティーの間には、常にトレードオフがあります。一般に、セキュリティーにより、要求の処理時間が長くなりますが、
それは当然の理由です。
使用している環境に、すべてのセキュリティー機能が必要であるとは限りません。
セキュリティーのチューニングを行う場合、変更した結果パフォーマンス
が向上しているかどうか確認するために、変更を行う前にベンチマークを作成します。
次の作業
大規模なデプロイメントでは、パフォーマンスが非常に重要です。
異なる機能を組み合わせてベンチマーク測定を実行すると、
使用している環境における最高のパフォーマンスと有利な構成との関係を判別するのに役立ちます。環境内で変化があった場合は、その変更による影響を判別するために、ベンチマークを引き続き実行します。