このトピックは、Secure Sockets Layer (SSL) プロトコル、および暗号サービス・システムの SSL が z/OS 上で動作する方法について理解していることを前提に書かれています。WebSphere Application Server 内の複数のコンポーネントは SSL を使用することで、データを信頼できるものにし、プライバシーを保護します。これらのコンポーネントには、組み込みの HTTP トランスポート、オブジェクト・リクエスト・ブローカー (ORB) (ク ライアントおよびサーバー)、およびセキュア Lightweight Directory Access Protocol (LDAP) クライアントが含まれています。SSL の構成は、 WebSphere Application Server を使用するクライアントとサーバー間では異なります。ネットワークで、通信を保護し、 ユーザー認証を実施することでセキュリティーを追加する場合は、SSL セキュリティーを使用できます。
SSL は、WebSphere Application Server for z/OS が提供す るセキュリティーの不可欠な部分です。これは 管理セキュリティー を使用可能にした場 合に活動化されます。 管理セキュリティー を使用可能にすると、SSL は、管理コマンド、管理コンソール、および WebSphere Application Server プロセス間の通信を保護するために、管理サブシステムにより常に使用されます。
このトピックでは、SSL プロトコルおよび SSL が z/OS 上で動作する方法について 概要を説明します。SSL プロトコルについては、以下の Web サイトを参照してください。http://home.netscape.com/eng/ssl3/ssl-toc.html
暗号サービス・システム SSL について詳しくは、 以下の Web サイトを参照してください。z/OS System Secure Sockets Layer Programming
SSL は、暗号化テクノロジーを使用して通信リンク上にセキュリティーを提供します。これにより、ネットワーク内のメッセージ保全性を確認します。 通信は、送り手と受け手の間で暗号化されるので、第三者がメッセージを改ざんすることはできません。 また、SSL は、機密性 (メッセージ内容が読み取られないことを確認する)、再生検出、および順不同検出も提供しています。
認証用に WebSphere Application Server for z/OS にデジタル証明書が指定された場合、 暗号化解除された証明書は、使用可能なユーザー・リポジトリー内の有効なユーザー ID にマップされます。 Web アプリケーションには多数のクライアントがあるため、クライアント認証の管理が負荷になります。 ローカルのオペレーション・システムが WebSphere Application Server for z/OS 上の使用可能なユー ザー・リポジトリーの場合、SAF 証明書名フィルターによりクライアント証明書を、保管せずに MVS ユーザー ID にマップできるようになります。 証明書名フィルター を使用すると、MVS ユーザー ID の作成および各ユーザーごとのクライアント証明書の管理における 管理オーバーヘッドを発生させることなく、多数のユーザーがサーバーにアクセスすることを許可できます。
SSL はデフォルトでは使用不可であり、SSL サポートはオプショナルです。 セキュリティーがオンの状態で WebSphere Application Server for z/OS を実行している場合には、 管理コンソールで SSL が必要です。
段階 | 説明 |
---|---|
ネゴシエーション | クライアントがサーバーを検出したら、クライアントとサーバーは、通信のセキュリティー・タイプをネゴシエーションします。 SSL が使用される場合には、クライアントは、特別な SSL ポートに接続するよう指示されます。 |
ハンドシェーク | クライアントが SSL ポートに接続すると、SSL ハンドシェークが起こります。成功すれば、暗号化通信が開始します。
クライアントは、サーバーのデジタル証明書を検査することによって、サーバーを認証します。
クライアント証明書がハンドシェーク時に使用される場合は、クライアントのデジタル証明書を検査することによって、サーバーはクライアントを認証します。 |
継続中の通信 | SSL ハンドシェーク時に、クライアントとサーバーは、通信を暗号化するために使用する暗号仕様をネゴシエーションします。 |
最初のクライアント要求 | クライアント識別の判別は、選択されたクライアント認証メカニズムによって異なります。次のいずれかになります。
|
RALTER PROGRAM * ADDMEM('hlq.SGSKLOAD' //NOPADCHK) UACC(READ)
SETROPTS WHEN(PROGRAM) REFRESH
クライアントについては、鍵リングを作成し、サーバーの証明書を出した認証局からの CA 証明書をその鍵リングに付加する必要があります。 z/OS クライアントでは、RACF を使用して、クライアント鍵リングを作成し、その鍵リングに CA 証明書を付加する必要があります。 クライアントでサーバーを認証する場合は、サーバー (実際には、コントローラー・ユーザー ID) は、 認証局によって作成された、署名付き証明書を所有している必要があります。 サーバーは、その識別を証明するために、署名された証明書をクライアントに渡します。クライアントは、サーバーの証明書を出したのと同じ認証局からの CA 証明書を所有していなければなりません。 クライアントは、CA 証明書を使用して、サーバーの証明書が本物かどうかを検査します。 証明書が検査された後、クライアントはメッセージが別のサーバーからではなく、本当にそのサーバーから届いていることを確信できます。 サーバーがクライアントを認証する場合は、クライアントがその識別を証明するためにサーバーに渡す、クライアント証明書がないことに注意してください。 SSL 基本認証スキームでは、サーバーは、クライアントのユーザー ID とパスワードを調べることによって、クライアントを認証します。
デーモンの MVS ユーザー ID の鍵リングの作成の詳細については、 デーモン Secure Sockets Layer が使用する鍵リングのセットアップ を参照してください。