test

Sun GlassFish Enterprise Server v3 管理ガイド

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』を参照してください。