test

Sun GlassFish Enterprise Server v3 管理ガイド

第 11 章 システムセキュリティーの管理

ここでは、次のテーマを取り上げます。

これらのタスクの多くを 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。

セキュリティーの設定に関するその他の手順は、第 12 章ユーザーセキュリティーの管理および第 13 章メッセージセキュリティーの管理で説明します。

アプリケーションのセキュリティーについては、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 5 章「Securing Applications」で説明します。

Enterprise Server のシステムセキュリティーについて

セキュリティーとはデータを保護すること、つまり、記憶領域のデータまたは搬送中のデータに対する許可されていないアクセスや損傷を防ぐための方法です。Enterprise Server は Java セキュリティーモデルをベースに構築され、アプリケーションが安全に動作できるサンドボックスを使用するため、システムやユーザーにリスクが及ぶ可能性がありません。「システムセキュリティー」は、Enterprise Server 環境内のすべてのアプリケーションに影響します。

システムセキュリティーには次のような機能があります。

認証

「認証」とは、あるエンティティー (ユーザー、アプリケーション、またはコンポーネント) が、別のエンティティーが主張している本人であることを確認する方法です。エンティティーは、セキュリティー「資格」を使用して自らを認証します。資格には、ユーザー名、パスワード、デジタル証明書などが含まれます。通常、サーバーまたはアプリケーションはクライアントに自身を認証するように要求します。また、クライアントがサーバーに自身を認証するように要求する場合もあります。双方向で認証する場合は、これを「相互認証」と呼びます。

エンティティーが保護対象リソースにアクセスを試行する場合、Enterprise Server はそのリソースに対して設定されている認証メカニズムを使用してアクセスを認可するかどうかを決定します。たとえば、ユーザーが Web ブラウザでユーザー名およびパスワードを入力でき、アプリケーションがその資格を確認する場合、そのユーザーは認証されます。それ以降のセッションで、ユーザーはこの認証済みのセキュリティー ID に関連付けられます。

認証のタイプ

アプリケーションは、使用する認証のタイプを配備記述子内で指定します。Enterprise Server では、次のタイプの認証がサポートされます。

BASIC

サーバーに組み込まれているログインダイアログボックスを使用します。通信プロトコルは HTTP です (SSL を指定可能)。SSL を使用しなければ、ユーザー証明書は暗号化されません

FORM

アプリケーションが独自仕様のカスタムログインおよびエラーページを提供します。通信プロトコルは HTTP です (SSL を指定可能)。SSL を使用しなければ、ユーザー証明書は暗号化されません。

CLIENT-CERT

サーバーは公開鍵証明書を使用してクライアントを認証します。通信プロトコルは HTTPS (HTTP over SSL) です。ユーザー認定された暗号化は SSL です。

DIGEST

サーバーは、ユーザー名とパスワードに基づいてユーザーを認証します。認証はパスワードを暗号化された形式で送信することによって実行され、この暗号化形式は BASIC 認証で使用される単純な Base64 エンコーディングよりも安全です。通信プロトコルは HTTPS です。

パスワード

パスワードは、Enterprise Server のコンポーネントおよびデータへの許可されていないアクセスを防ぐもっとも重要な手段です。Enterprise Server でパスワードを使用する方法については、「パスワードの管理」を参照してください。

マスターパスワードとキーストア

「マスターパスワード」は、全体で共有されるパスワードで、システムでもっとも重要なデータです。これを認証に使用したり、ネットワークを介して送信したりすることは決してありません。マスターパスワードは要求されたときに手動で入力するか、ファイルに隠蔽化することができます。

マスターパスワードは、セキュリティー保護されたキーストアのパスワードです。新しいアプリケーションサーバードメインが作成されると、新しい自己署名付き証明書が生成されて、関連キーストアに格納されます。このキーストアは、マスターパスワード (デフォルトのパスワードは changeit) を使用してロックされます。マスターパスワードが変更済みで、デフォルト以外の値に設定されている場合は、マスターパスワードの入力を要求されます。正しいマスターパスワードを入力したあと、ドメインが起動します。

管理用パスワード

管理パスワードは、管理コンソールおよび asadmin ユーティリティーの呼び出しに使用されます。通常、このパスワードはインストール時に設定されますが、変更可能です。手順については、「管理パスワードを変更する」を参照してください。

符号化されたパスワード

符号化されたパスワードを含むファイルは、ファイルシステムのアクセス権を使用して保護する必要があります。これらのファイルには次のものが含まれます。

手順については、「パスワードをファイルから設定する」を参照してください。

パスワードエイリアス

パスワードをドメイン構成ファイルに平文で保存するのを避けるために、パスワードのエイリアスを作成できます。この処理は、パスワードの「暗号化」とも呼ばれます。詳細は、「パスワードエイリアスの管理」を参照してください。

シングルサインオン

「シングルサインオン」によって、1 つのアプリケーションにログインしたユーザーは、同じ認証情報が必要なほかのアプリケーションに暗黙的にログインするようになります。シングルサインオンはグループに基づいています。配備記述子が同じグループを定義し、かつ同じ認証方法 (BASIC、FORM、または CLIENT-CERT) を使用するすべての Web アプリケーションは、シングルサインオンを共有します。

Enterprise Server では、仮想サーバーのシングルサインオンがデフォルトで有効に設定されます。これにより、同じ仮想サーバー内の複数のアプリケーションが、ユーザーの認証状態を共有できます。

承認

「承認」は、アクセス制御とも呼ばれ、データにアクセスする許可または操作を実行する許可を、ユーザーに与えるための手段です。ユーザーが承認されたあと、ユーザーの承認のレベルにより、その所有者が実行できる操作の範囲が決定されます。ユーザーの承認は、ユーザーのロールに基づきます。

ロール

「ロール」は、ユーザーがアクセスできるアプリケーションおよび各アプリケーションの部分、およびこれらのユーザーまたはグループがアプリケーションで実行できる操作の内容を定義します。たとえば、人事アプリケーションの場合、すべての社員は電話番号とメールアドレスの情報を表示できますが、給与情報にアクセスできるのは管理職だけです。このアプリケーションでは、employee と manager の少なくとも 2 つのロールを定義しています。manager ロールのユーザーだけが、給与情報の表示を許可されています。

ロールはアプリケーション内での役割を定義するのに対し、グループはある方法で関連付けられているユーザーの集まりに過ぎません。この点で、ロールとグループは異なります。たとえば、人事アプリケーションで、full-time、part-time、および on-leave といったグループがあるとします。これらのグループのユーザーは、すべて社員 (employee ロール) です。これに加え、各ユーザーには追加の雇用レベルを定義する各自の役職が指定されます。

ロールは、アプリケーションの配備記述子内で定義されます。アプリケーションの開発者または配備担当者は、各アプリケーションの配備記述子で、ロールを 1 つまたは複数のグループにマッピングします。アプリケーションがパッケージ化されて配備される場合、次の図に例示されているように、アプリケーションはユーザーまたはグループとロールとの間のマッピングを指定します。

図 11–1 ロールマッピング

図は、ユーザーをグループに割り当てる方法、ユーザーやグループをロールに割り当てる方法、およびアプリケーションがグループやロールを使用する方法を示しています。

Java Authorization Contract for Containers

JACC (Java Authorization Contract for Containers) は Java EE 仕様の一部で、プラグイン可能な承認プロバイダ用のインタフェースを定義します。これにより、認証を行うためにサードパーティー製のプラグインモジュールを設定できます。デフォルトで、Enterprise Server は JACC 仕様に準拠する単純なファイルベースの承認エンジンを提供します。サードパーティー製の JACC プロバイダを追加指定することもできます。

JACC プロバイダは JAAS (Java Authentication and Authorization Service) の API を使用します。JAAS によって、サービスが認証およびユーザーに対するアクセス制御を行うことが可能になります。JAAS は、標準 PAM (Pluggable Authentication Module) フレームワークの Java テクノロジバージョンを実装しています。

JSR 196 により、別のレイヤーでプラグインを開発できます。AuthConfigProvider や AuthConfigFactory などの、新しい認証メカニズムを設定する方法を変更するプラグインを定義できます。また、ServerAuthModule や ClientAuthModule などの、新しい認証メカニズムを定義することもできます。

監査

「監査」は、セキュリティー対策の効果を評価するために、セキュリティーに関するイベントを取得するための手段です。Enterprise Server は、監査モジュールを使用して、すべての認証と承認の決定に関する監査証跡を取得します。Enterprise Server は、デフォルトの監査モジュールのほか、監査モジュールのカスタマイズ機能も提供します。

管理の手順については、「監査モジュールの管理」を参照してください。

ファイアウォール

「ファイアウォール」は、2 つ以上のネットワーク間のデータフローを制御し、ネットワーク間のリンクを管理します。ファイアウォールは、ハードウェア要素およびソフトウェア要素で構成できます。Enterprise Server では、主に次のようなガイドラインが適しています。

証明書と SSL

ここでは、次のテーマを取り上げます。

管理の手順については、「JSSE 証明書の管理 」を参照してください。

証明書

「証明書」 (または、デジタル証明書) は、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 2 つのエンティティー間の安全で機密保護された通信を可能にします。証明書にはさまざまな種類があります。

証明書は「公開鍵暗号化」に基づき、意図した受信者だけが情報を解読できるように、デジタルの鍵 (非常に長い数値) のペアを使用して暗号化または符号化します。そして受信者は、情報を「復号化」して解読します。「鍵のペア」には公開鍵と非公開鍵が含まれます。所有者は公開鍵を配布して、だれでも利用できるようにします。しかし、所有者は非公開鍵を決して配布せず、常時秘密にしておきます。鍵は数学的に関連付けられているので、一方の鍵で暗号化されたデータは、そのペアのもう一方の鍵でしか復号化することができません。

証明書は、「証明書発行局」(CA) と呼ばれる、信頼できるサードパーティーが発行します。CA はパスポートセンターに似ています。CA は、証明書の所有者の身元を確認したあと、偽造や改ざんができないように証明書に署名します。CA が証明書に署名したあと、所有者は ID の証明としてこれを提出することで、暗号化され、機密保護された通信を確立できます。もっとも重要な点は、証明書によって所有者の公開鍵が所有者の ID と結び付けられることです。

公開鍵のほかに、通常、証明書には次のような情報が含まれています。

証明書は、X.509 形式の技術仕様で管理されます。certificate レルムのユーザー ID を検証するために、 certificate 認証サービスは X.509 証明書の共通名フィールドを主体名として使用して、X.509 証明書を検証します。

証明書チェーン

「証明書チェーン」とは、最後がルート CA 証明書で終わる、継続的な CA によって発行される一連の証明書です。

Web ブラウザは、ブラウザが自動的に信頼する一連の「ルート」CA 証明書で事前に設定されます。別の場所で発行されたすべての証明書は、有効性を検証するために「証明書チェーン」を備えている必要があります。

証明書が最初に生成される場合、それは「自己署名付き」証明書です。自己署名付き証明書とは、発行者 (署名者) が被認証者 (公開鍵が証明書で認証されているエンティティー) と同じものです。所有者は、証明書の署名要求 (CSR) を CA に送信するとき、その応答をインポートし、自己署名付き証明書が証明書のチェーンによって置き換えられます。チェーンの元の部分には、被認証者の公開鍵を認証する CA によって発行された証明書 (応答) があります。このチェーンの次の証明書は、CA の公開鍵を認証するものです。通常、これは自己署名付き証明書 (つまり、自らの公開鍵を認証する CA からの証明書) およびチェーンの最後の証明書です。

CA が証明書のチェーンに戻ることができる場合もあります。この場合、チェーンの元の証明書は同じ (キーエントリの公開鍵を認証する、CA によって署名された証明書) ですが、チェーン 2 番目の証明書が、CSR の送信先の CA の公開鍵を認証する、異なる CA によって署名された証明書です。そして、チェーンのその次の証明書は 2 番目の鍵を認証する証明書というように、自己署名付き「ルート」証明書に到達するまで続きます。こうして、チェーンの最初以降の各証明書は、チェーンの前にある証明書の署名者の公開鍵を認証します。

証明書ファイル

Enterprise Server のインストール中に、証明書が内部テストに適した JSSE (Java Secure Socket Extension) 形式で生成されます。デフォルトでは、Enterprise Server は証明書情報を domain-dir/config ディレクトリの証明書データベースに格納します。

キーストアファイル

key3.db ファイルには、非公開鍵を含む Enterprise Server の証明書が格納されます。キーストアファイルはパスワードで保護されています。

各キーストアエントリには一意のエイリアスがあります。インストール後の Enterprise Server のキーストアには、s1as のエイリアスを持つ 1 つのエントリが含まれています。

トラストストアファイル

cert8.db ファイルには、ほかのエンティティーの公開鍵を含む、Enterprise Server の信頼できる証明書が格納されます。信頼できる証明書では、サーバーは証明書の公開鍵が証明書の所有者に属していることを確認しています。通常、信頼できる証明書には CA の証明書も含まれています。

デフォルトでは、Enterprise Server は、サンプルアプリケーションで開発目的のために動作するキーストアおよびトラストストアを使用して設定されています。

Secure Sockets Layer

「SSL」(Secure Sockets Layer) とは、インターネットの通信およびトランザクションのセキュリティー保護でもっとも普及している標準仕様です。セキュリティー保護された Web アプリケーションは HTTPS (HTTP over SSL) を使用します。HTTPS プロトコルは証明書を使用して、サーバーとクライアント間のセキュリティー保護された機密通信を保証します。SSL 接続では、クライアントとサーバーの両方が送信の前にデータを暗号化します。データは受信時に復号化されます。

クライアントの Web ブラウザがセキュリティー保護されたサイトに接続するときに、次のように「SSL ハンドシェーク」が行われます。

  1. ブラウザはネットワークを介してセキュアなセッションを要求するメッセージを送信します。通常は、http ではなく https で始まる URL を要求します。

  2. サーバーは、公開鍵を含む証明書を送信することで応答します。

  3. ブラウザは、サーバーの証明書が有効であること、またサーバーの証明書が証明書をブラウザのデータベースに持つ信頼されている CA によって署名されていることを検証します。さらに、CA の証明書の有効期限が切れていないことも検証します。

  4. 証明書が有効な場合、ブラウザは 1 回かぎりの一意の「セッション鍵」を生成し、サーバーの公開鍵でそれを暗号化します。そして、ブラウザは暗号化されたセッション鍵をサーバーに送信し、両方でコピーを持てるようにします。

  5. サーバーは、非公開鍵を使用してメッセージを復号化し、セッション鍵を復元します。

ハンドシェークの後、クライアントは Web サイトの ID を検証し、クライアントと Web サーバーだけがセッション鍵のコピーを持ちます。これ以降、クライアントとサーバーはセッション鍵を使用して互いにすべての通信を暗号化します。こうすると、通信は確実にセキュアになります。

SSL 標準の最新バージョンは TLS (Transport Layer Security) と呼ばれています。Enterprise Server は、SSL 3.0 および TLS 1.0 の暗号化プロトコルをサポートしています。

SSL を使用するには、セキュリティー保護された接続を受け付ける外部インタフェースまたは IP アドレスごとに、Enterprise Server が証明書を所持しておく必要があります。ほとんどの Web サーバーの HTTPS サービスは、証明書がインストールされるまで実行されません。HTTP リスナーに SSL を適用する手順については、「SSL の HTTP リスナーを構成する」を参照してください。

暗号化方式

「暗号化方式」とは、暗号化と復号化に使用される暗号化アルゴリズムです。SSL および TLS プロトコルは、サーバーとクライアントでお互いを認証するために使用される多くの暗号化方式のサポート、証明書の送信、およびセッション鍵の確立を行います。

安全度は、暗号化方式によって異なります。クライアントとサーバーは異なる暗号化方式群をサポートできます。クライアントとサーバーは安全な接続のために、双方で通信に使用可能なもっとも強力な暗号化方式を使用します。したがって、通常はすべての暗号化方式を有効にすれば十分です。

名前ベースの仮想ホスト

セキュアなアプリケーションに名前ベースの仮想ホストを使用すると、問題が発生する場合があります。これは、SSL プロトコル自体の設計上の制約です。クライアントブラウザがサーバーの証明書を受け付ける SSL ハンドシェークは、HTTP 要求がアクセスされる前に行われる必要があります。その結果、認証より前に仮想ホスト名を含む要求情報を特定できないので、複数の証明書を単一の IP アドレスに割り当てできません。

単一の IP すべての仮想ホストが同じ証明書に対して認証を必要とする場合、複数の仮想ホストを追加しても、サーバーの通常の SSL 動作を妨害する可能性はありません。ただし、証明書 (主に正式な CA の署名済みの証明書が該当) に表示されているドメイン名がある場合、ほとんどのブラウザがサーバーのドメイン名をこのドメイン名と比較することに注意してください。ドメイン名が一致しない場合、これらのブラウザは警告を表示します。一般的には、アドレスベースの仮想ホストだけが本稼働環境の SSL で広く使用されています。

システムセキュリティー管理用ツール

Enterprise Server には、次のシステムセキュリティー管理用ツールがあります。

管理コンソール

管理コンソール は、サーバー全体のセキュリティーを設定するための、ブラウザベースのユーティリティーです。証明書、ユーザー、グループ、およびレルムの管理や、システム全体に関するその他のセキュリティータスクの実行に使用します。管理コンソール の概要については、「管理コンソール」を参照してください。

asadmin ユーティリティー

asadmin コマンド行ユーティリティーでは、管理コンソール と同じ多数のタスク 実行できます。管理コンソール では実行できない操作を、asadmin ユーティリティーで実行できる場合もあります。asadmin の概要については、「asadmin ユーティリティー」を参照してください。

keytool ユーティリティー

keytool Java 2 Platform, Standard Edition (J2SE) コマンド行ユーティリティーは、デジタル証明書および鍵のペアを管理するために使用します。詳細は、「JSSE 証明書の管理 」を参照してください。

policytool ユーティリティー

policytool J2SE グラフィカルユーティリティーは、システム全体の Java セキュリティーポリシーを管理するために使用します。管理者が policytool を使用することはほとんどありません。

keytool、policytool、およびその他の Java セキュリティーツールの使用方法については、http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security の『Java 2 SDK Tools and Utilities』を参照してください。

パスワードの管理

パスワードの管理には複数の方法があります。各管理者には、パスワードを秘密にして定期的に変更するように指示します。ユーザーにコマンドを入力させず、asadmin のサブコマンドがパスワードを格納したファイルにアクセスできるように、これらのファイルを設定することができます。domain.xml ファイルで重要なパスワードが表示されないように、エイリアスを設定してパスワードを暗号化することができます。

ここでは、次のテーマを取り上げます。

Procedureマスターパスワードを変更する

マスターパスワードは、ドメインで使用される暗号化ストア (NSS cert8.db トラストストアまたは Java JKS キーストア) へのアクセスを許可します。このパスワードは、UNIX ユーザーに結び付けられません。この全体で共有されるパスワードは、システムでもっとも重要なデータです。マスターパスワードを認証に使用したり、ネットワークを介して送信したりすることは決してありません。

パスワードを要求されたときに手動で入力するか、パスワードファイルに隠蔽化することができます。パスワードファイルがない場合は、マスターパスワードの入力を要求されます。パスワードファイルがある場合に、入力を必要とするようにアクセスを変更する場合は、ファイルを削除します。デフォルトのマスターパスワードは changeit です。

change-master-password サブコマンドをローカルモードで使用して、マスターパスワードを変更します。

マスターパスワードを変更すると、マスターパスワードキーストアにパスワードが再保存されます。これは、Java JCEKS タイプのキーストアです。

始める前に

ドメインが停止していない場合、このサブコマンドは機能しません。

  1. パスワードを変更するドメインを停止します。

    「ドメインの停止」を参照してください。

  2. change-master-password(1) サブコマンドを使用して、ドメインのマスターパスワードを変更します。

    旧パスワードと新しいパスワードの入力を要求されます。依存しているすべての項目が再暗号化されます。

  3. ドメインを起動します。

    「ドメインの起動」を参照してください。

例 11–1 マスターパスワードの変更

change-master-password サブコマンドは対話形式で動作し、旧マスターパスワードと新しいマスターパスワードの入力を要求します。この例では、domain44ps のマスターパスワードを変更します。


asadmin> change-master-password domain44ps

login(1) サブコマンドを使用してすでにドメインにログインしている場合は、新しいマスターパスワードの入力を要求されます。


Please enter the new master password>
Please enter the new master password again>

ドメインにログインしていない場合は、旧マスターパスワードと新しいマスターパスワードの両方の入力を要求されます。


Please enter the master password again>
Please enter the new master password>
Please enter the new master password again>

次のような情報が表示されます。

Master password changed for domain44ps
参照

コマンド行に asadmin help change-master-password と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure管理パスワードを変更する

管理パスワードを変更するには、リモートモードで change-admin-password サブコマンドを使用します。デフォルトの管理パスワードは admin です。確認のために、旧パスワードと新しいパスワードの入力を要求されます。

注 –

ZIP インストール中に、パスワードが設定されていないデフォルトの admin ユーザーを受け入れている場合は、このユーザーにパスワードを追加できます。パスワードが設定されていない admin というユーザーしか存在しない場合は、ログイン情報を要求されません。その他の状況ではログインが必要です。

管理パスワードの暗号化は強く推奨されています。

始める前に

パスワードのエイリアスを作成する (暗号化する) 前に管理パスワードを変更する場合は、set サブコマンドを使用できます。次に例を示します。


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=
new_pwd

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. change-admin-password(1) サブコマンドを使用して、管理パスワードを変更します。

  3. 要求に従って、旧管理パスワードと新しい管理パスワードを入力します。

例 11–2 管理パスワードの変更

この例では、ユーザー anonymous の管理パスワードを、adminadmin から newadmin に変更します。


asadmin> change-admin-password --user anonymous

旧管理パスワードと新しい管理パスワードの入力を要求されます。


Enter admin password>adminadmin
Enter new admin password>newadmin
Enter new admin password again>newadmin

次のような情報が表示されます。


Command change-admin-password executed successfully.
参照

コマンド行に asadmin help change-admin-password と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードをファイルから設定する

コマンド行にパスワードを入力する代わりに、passwords.txt などのファイルからコマンドのパスワードにアクセスできます。asadmin ユーティリティーの --passwordfile オプションは、パスワードを含むファイルの名前を受け取ります。ファイル内のパスワードのエントリには、パスワード名の前に AS_ADMIN_ というプレフィックス (大文字) を付ける必要があります。

次のタイプのパスワードも指定できます。 


AS_ADMIN_MASTERPASSWORD
AS_ADMIN_USERPASSWORD
AS_ADMIN_ALIASPASSWORD

  1. パスワードファイルを編集します。

    たとえば、ドメイン管理サーバー (DAS) のパスワードを指定するには、パスワードファイルに次のようなエントリを追加します。adminadmin は管理者パスワードです。

    AS_ADMIN_PASSWORD=adminadmin

  2. パスワードファイルを保存します。

    これで、asadmin サブコマンドにパスワードファイルを指定できるようになりました。この例では、passwords.txt がパスワードを含むファイルです。


    asadmin>delete-jdbc-resource --user admin --password passwords.txt jdbc/DerbyPool
注意事項

AS_ADMIN_PASSWORD がグローバル環境にエクスポートされている場合、--passwordfile オプションを指定すると、--passwordfile オプションの使用に関する警告が表示されます。この警告が生成されないようにするには、AS_ADMIN_PASSWORD を設定解除します。

パスワードエイリアスの管理

パスワードエイリアスは、パスワード自体が構成ファイルに現れないように、パスワードに間接的にアクセスするために使用します。

ここでは、次のテーマを取り上げます。

Procedureパスワードエイリアスを作成する

パスワードのエイリアスをドメインのキーストアに作成するには、リモートモードで create-password-alias サブコマンドを使用します。エイリアス名に対応するパスワードは、ドメイン構成ファイルに暗号化された形式で保存されます。create-password-alias サブコマンドの形式には、ユーザーにすべての情報を要求するセキュリティー保護された対話形式と、パスワードがコマンド行で伝達されるスクリプトに適した形式があります。

set(1) サブコマンドを使用して、構成ファイル中のパスワードを削除および置換することもできます。次に例を示します。


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.
admin-password='${ALIAS=jms-password}'

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. 構成ファイルが保存されているディレクトリに移動します。

    デフォルトでは、構成ファイルは domain-dir /config に保存されています。

  3. create-password-alias(1) サブコマンドを使用して、パスワードエイリアスを作成します。

  4. 要求に応じて、エイリアスのパスワードを入力します。

  5. エイリアスをパスワードファイルに追加します。

    パスワードファイル (たとえば、passwords.txt) に、AS_ADMIN_PASSWORD=${ALIAS=admin-password-alias} という行を追加します。admin-password-alias は新しいパスワードエイリアスです。

  6. Enterprise Server ドメインを停止します。

    「ドメインの停止」を参照してください。

  7. エイリアスを含むファイルを指定して、ドメインを起動します。

    次に例を示します。


    asadmin start-domain --user admin --passwordfile /path-to/passwords.txt domain1
例 11–3 パスワードエイリアスの作成

この例では、admin ユーザーの新しい jms-password エイリアスを作成します。


asadmin> create-password-alias --user admin jms-password

エイリアスのパスワードを入力するように要求されます。


Please enter the alias password>secret-password
Please enter the alias password again>secret-password
Command create-password-alias executed successfully.
参照

コマンド行に asadmin help create-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを一覧表示する

既存のパスワードエイリアスを一覧表示するには、リモートモードで list-password-aliases サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-password-aliases(1) サブコマンドを使用して、パスワードエイリアスを一覧表示します。

例 11–4 パスワードエイリアスの一覧表示

この例では、既存のパスワードエイリアスを一覧表示します。


asadmin> list-password aliases
jmspassword-alias
Command list-password-aliases executed successfully
参照

コマンド行に asadmin help list-password-aliases と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを削除する

既存のパスワードエイリアスを削除するには、リモートモードで delete-password-alias サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-password-aliases(1) サブコマンドを使用して、エイリアスをすべて表示します。

  3. list-password-aliases(1) サブコマンドを使用して、パスワードエイリアスを削除します。

例 11–5 パスワードエイリアスの削除

この例では、パスワードエイリアス jmspassword-alias を削除します。


asadmin> delete-password-alias jmspassword-alias
Command list-password-aliases executed successfully
参照

コマンド行に asadmin help delete-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedureパスワードエイリアスを更新する

既存のパスワードエイリアスのパスワードを変更するには、リモートモードで update-password-alias サブコマンドを使用します。update-password-alias サブコマンドでは、セキュリティー保護された対話形式 (ユーザーがすべての情報の入力を求められる) と、スクリプトの処理しやすい形式 (パスワードがコマンド行で伝達される) の両方を使用できます。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. update-password-alias(1) サブコマンドを使用して、エイリアスを更新します。

  3. 要求に応じて、パスワードを入力します。

例 11–6 パスワードエイリアスの更新

この例では、jmspassword-alias エイリアスのパスワードを更新します。


asadmin> update-password-allias /home/password.txt jsmpassword-alias

エイリアスの新しいパスワードを入力するように要求されます。


Please enter the alias password>new-secret-password
Please enter the alias password again>new-secret-password
Command update-password-alias executed successfully
参照

コマンド行に asadmin help update-password-alias と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

監査モジュールの管理

ここでは、次のテーマを取り上げます。

Procedure監査モジュールを作成する

監査機能を実装するアドオンコンポーネントの監査モジュールを作成するには、リモートモードで create-audit-module サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. create-audit-module(1) サブコマンドを使用して、監査モジュールを作成します。

    このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

例 11–7 監査モジュールの作成

この例では、sampleAuditModule という名前の監査モジュールを作成します。


asadmin> create-audit-module 
--classname com.sun.appserv.auditmodule --property defaultuser=
admin:Password=admin sampleAuditModule
Command create-audit-module executed successfully.
参照

コマンド行に asadmin help create-audit-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure監査モジュールを一覧表示する

次のいずれか対象の監査モジュールを一覧表示するには、リモートモードで list-audit-modules サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-audit-modules(1) サブコマンドを使用して、監査モジュールを一覧表示します。

例 11–8 監査モジュールの一覧表示

この例では、localhost 上の監査モジュールを一覧表示します。


asadmin> list-audit-modules
audit-module : default
audit-module : sampleAuditModule
Command list-audit-modules executed successfully.
参照

コマンド行に asadmin help list-audit-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Procedure監査モジュールを削除する

既存の監査モジュールを削除するには、リモートモードで delete-audit-module サブコマンドを使用します。

  1. サーバーが実行されていることを確認します。

    リモートサブコマンドには、実行中のサーバーが必要です。

  2. list-audit-modules(1) サブコマンドを使用して、監査モジュールを一覧表示します。

  3. delete-audit-module(1) サブコマンドを使用して、監査モジュールを削除します。

例 11–9 監査モジュールの削除

この例では、sampleAuditModule を削除します。


asadmin> delete-audit-module sampleAuditModule
Command delete-audit-module executed successfully.

JSSE 証明書の管理

開発者プロファイルでは、Enterprise Server v3 はサーバー側で JSSE 形式を使用して証明書とキーストアを管理します。すべてのプロファイルで、クライアント側 (アプリケーションクライアントまたはスタンドアロン) は JSSE 形式を使用します。

J2SE SDK には JSSE (Java Secure Socket Extension) デジタル証明書を設定および操作することができる keytool ユーティリティーが付属しています。公開鍵と非公開鍵のペアおよび関連する証明書を管理し、通信しているピアの公開鍵を (証明書の形式で) キャッシュすることができます。

ここでは、次のテーマを取り上げます。

Procedurekeytool による証明書の生成

デフォルトでは、keytool ユーティリティーは実行元のディレクトリにキーストアファイルを作成します。

始める前に

keytool ユーティリティーを実行するには、シェル環境を設定して、J2SE の /bin ディレクトリがパスに含まれるようにする必要があります。そうでない場合は、ユーティリティーのフルパスをコマンド行に指定する必要があります。

  1. キーストアファイルおよびトラストストアファイルが格納されているディレクトリに移動します。

    証明書の生成は常に、キーストアファイルとトラストストアファイルが格納されているディレクトリ内で行います。デフォルトは、domain-dir/config です。

  2. 次のコマンド形式を使用して、キーストアファイル keystore.jks に証明書を生成します。


    keytool -genkey -alias keyAlias-keyalg RSA
 -keypass changeit
 -storepass changeit
keystore keystore.jks

    keyAlias には任意の一意名を指定します。キーストアまたは非公開鍵のパスワードをデフォルト (changeit) から変更している場合は、changeit を新しいパスワードで置き換えてください。デフォルトのキーパスワードエイリアスは s1as です。

    名前、組織、およびその他の情報を尋ねるプロンプトが表示されます。

  3. 次のコマンド形式を使用して、生成された証明書を server.cer ファイル (または、必要に応じて client.cer) にエクスポートします。


    keytool -export -alias keyAlias-storepass changeit
 -file server.cer
 -keystore keystore.jks

  4. 認証局によって署名された証明書が必要な場合は、「keytool を使用して証明書に署名する」を参照してください。

  5. 次のコマンド形式を使用して、cacerts.jks トラストストアファイルを作成し、証明書をトラストストアに追加します。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit

    キーストアまたは非公開鍵のパスワードをデフォルト (changeit) から変更している場合は、新しいパスワードで置き換えてください。

    証明書に関する情報が表示され、証明書を信頼するかどうかを確認するプロンプトが表示されます。

  6. yes と入力し、続いて Enter キーを押します。

    次のような情報が表示されます。


    Certificate was added to keystore
[Saving cacerts.jks]

  7. 変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 11–10 RSA 鍵アルゴリズムを使用した JKS キーストアへの自己署名付き証明書の作成

RSA は RSA Data Security, Inc. によって開発された、公開鍵暗号化テクノロジです。


keytool  -genkey -noprompt -trustcacerts -keyalg RSA -alias ${cert.alias} 
-dname  ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} 
-storepass ${keystore.pass}
例 11–11 デフォルトの鍵アルゴリズムを使用した JKS キーストアへの自己署名付き証明書の作成


keytool -genkey -noprompt -trustcacerts -alias ${cert.alias} -dname  
${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass 
${keystore.pass}
例 11–12 JKS キーストア内の使用可能な証明書の表示


keytool -list -v  -keystore ${keystore.file} -storepass ${keystore.pass}
例 11–13 JKS キーストア内の証明書情報の表示


keytool -list -v  -alias ${cert.alias} -keystore ${keystore.file} 
-storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

Procedurekeytool を使用して証明書に署名する

証明書の作成後、所有者は証明書に署名して偽造を防止する必要があります。E コマースのサイト、または ID の認証が重要であるサイトは、既知の証明書発行局 (CA) から証明書を購入できます。

注 –

認証に心配がない場合 (たとえば、非公開の安全な通信だけが必要な場合) は、自己署名付き証明書を使用して、CA 証明書の取得に必要な時間と費用を節約することができます。

  1. CA の Web サイトの指示に従って、証明書の鍵のペアを生成します。

  2. 生成された証明書の鍵のペアをダウンロードします。

    キーストアファイルとトラストストアファイルが格納されているディレクトリに、証明書を保存します。デフォルトは、domain-dir/config です。

  3. 使用しているシェルで、証明書を含むディレクトリに変更します。

  4. 次のコマンド形式を使用して、証明書をローカルキーストアと、必要な場合はローカルトラストストアにインポートします。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit
-storepass changeit

    キーストアまたは非公開鍵のパスワードがデフォルト以外の値である場合は、デフォルトのパスワード (changeit) を新しいパスワードで置き換えてください。

  5. 変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。

例 11–14 RFC/テキスト形式の証明書の JKS キーストアへのインポート

証明書は、バイナリエンコーディングではなく、RFC (Internet Request for Comments) 1421 標準によって定義された印刷可能なエンコーディング形式を使って格納されることがしばしばあります。Base 64 エンコーディングとしても知られるこの証明書形式を使用すれば、電子メールなどの機構を使って証明書をほかのアプリケーションにエクスポートしやすくなります。


keytool -import -noprompt -trustcacerts -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}
例 11–15 JKS キーストアからの PKCS7 形式による証明書のエクスポート

「Public Key Cryptography Standards #7, Cryptographic Message Syntax Standard」によって定義された応答形式には、発行される証明書に加え、それをサポートする証明書チェーンも含まれます。


keytool -export -noprompt -alias ${cert.alias} -file ${cert.file} 
-keystore ${keystore.file} -storepass ${keystore.pass}
例 11–16 JKS キーストアからの RFC/テキスト形式による証明書のエクスポート


keytool -export -noprompt -rfc -alias ${cert.alias} -file 
${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

Procedurekeytool を使用して証明書を削除する

keytool -delete コマンドを使用して、既存の証明書を削除します。

  1. 次のコマンド形式を使用して、証明書を削除します。

    keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password
例 11–17 JKS キーストアからの証明書の削除


keytool -delete -noprompt -alias ${cert.alias}  -keystore ${keystore.file} 
-storepass ${keystore.pass}
参照

keytool の詳細は、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。