10g（10.1.3.4.0）
B50832-01
 目次 |
 索引 |
| Oracle Containers for J2EE
セキュリティ・ガイド
10g（10.1.3.4.0） B50832-01 |
|
この章では、次の項目に沿ってセキュリティの概要について説明します。
この2つはセキュリティの基本的なカテゴリであり、個別に構成することができますが、多くの場合は相互に関連しています。通常、アプリケーション・レベルのセキュリティによって、データにアクセスできるユーザーおよびそのユーザーが実行を許可されているタスクが決まります。トランスポート・レベルのセキュリティによって、データが転送されたときにデータのセキュリティが決まります。
アプリケーション・レベルの構成にはトランスポート・レベルの指定を含めることができます。たとえば、トランスポート・レベルの機能であるSecure Sockets Layer（後述）を必要とするアプリケーション・レベルの制約を指定することができます。トランスポート・レベルのセキュリティには、データへのアクセスを適切なユーザーに限定する認証を伴うこともあります。たとえば、クライアント証明書がトランスポート・レベル機能の一部として要求されることがあります。
アプリケーション・レベルのセキュリティによって、アプリケーションまたはそのデータにアクセスできるユーザー、およびそのユーザーが実行できるタスクが決まります。ここでは、次のような主な機能について説明します。
認証は、「誰がサービスにアクセスしようとしているか」という質問に対処します。システムやアプリケーションで最も重要なことは、アプリケーションにアクセスしようとしているエンティティまたはコール元のアイデンティティがセキュアな方法で識別されることを保証することです。多層アプリケーションでのエンティティまたはコール元には、ユーザー、ビジネス・アプリケーション、ホストあるいは別のエンティティのかわりに機能する（ふりをする）エンティティなどがあります。
ユーザー名やパスワードなどの認証情報は、XMLファイル、データベース、ディレクトリ・サービスなどのユーザー・リポジトリに格納されます。サブジェクトが、ログインなどによってJ2EEアプリケーションへのアクセスを試行すると、セキュリティ・プロバイダにより、ユーザー・リポジトリ内でサブジェクトが検索され、サブジェクトのアイデンティティが検証されます。セキュリティ・プロバイダは、認証や認可など、個別のセキュリティ・サービスの実装を提供するモジュールです。Oracle Internet Directoryは、ユーザー・リポジトリの一例です。
各J2EEアプリケーションでは、そのアプリケーションにアクセスできるユーザーが決定されますが、ユーザー・リポジトリを使用してユーザーのアイデンティティを認証するのはセキュリティ・プロバイダです。
認可は、「どのコンポーネントが提供するどのリソースに誰がタスクを実行できるか」という質問に対処します。J2EEアプリケーションでは、リソースは通常、Webアプリケーションの場合はURLパターンに関連して、EJBの場合はメソッド呼出しの権限に関連して、表現されます。認可はロール単位ベースで行われ、アプリケーションに定義されているロールそれぞれに適切なパーミッションが割り当てられます。
ここでは、認可のタイプ、つまりアクセス制御および関連項目について説明します。
機能モデルとロールベース・モデルは相互に補い合い、多くの場合、一緒に使用されます。
機能モデルは、認可情報を編成する手段です。Java 2セキュリティ・モデルでは、機能モデルを使用してアクセス権を制御します。機能モデルを使用すると、アクセス制御情報がリソースに関連付けられ、認可が、Amyという名前のユーザーなど、エンティティに関連付けられます（エンティティは、「プリンシパルとサブジェクト」で定義するように、プリンシパルと呼ばれています）。
アクセス制御リスト（ACL）は、ディレクトリやファイルなど、保護されたターゲット・リソースに関連付けられます。このリストには、各ユーザーが特定のリソースに対して持っているアクセス権に関する情報が格納されています。たとえば、ファイル・システムの各ファイルがACLを保持する場合があります。ACLに指定された機能（権限）は特定のユーザーに関連付けられるため、ACLが関連付けられているファイルに対してどのユーザーがどの権限を持っているかが指定されます。
ユーザーAmyがログインし、正常に認証された場合、Amyのパーミッションが取得され、付与され、Amyはパーミッションで許可されるアクションを自由に実行できます。File1からの読取りやFile2への書込みなどです。
機能モデルとアクセス制御は、同じ情報を異なる視点から見たものです。機能はリソースにアクセスを試行するユーザーに関連付けられますが、アクセス制御リストはユーザーがアクセスを試行するリソースに関連付けられます。
図1-1は、File1を読み取り、File2に書き込むパーミッションを持つユーザーAmy、およびFile1を実行し、File2を読み取るパーミッションを持つユーザーBrianを示しています。アクセス制御リストはFile1とFile2という視点から作成され、各ファイルに対してどのユーザーがアクセス権を持っているか、ユーザーが持っているパーミッションは何であるかを指定します。機能モデルはAmyとBrianという視点から作成され、ユーザーがアクセスできるのはどのファイルか、各ファイルに対するパーミッションの種類は何かをユーザーごとに指定します。
基本的に、ロールとは認可レベルを定義する職務または役職のことです。1つのロールに複数のユーザーおよび複数のパーミッションを持たせることができます。ロールは、各アプリケーションで様々なオブジェクトおよび機能へのアクセス権を示すために使用されるアイデンティティです。ユーザーは、これらの適切なリソース・セットへのアクセス権を得るため、ロールを取得します。
ロールベースのアクセス制御はJAASの機能であり、これにより、ユーザーにパーミッションを直接割り当てることで生じる管理上の問題が単純化されます。複数のユーザーにパーミッションを直接割り当てる操作は、管理タスクの大半を占める可能性があります。複数のユーザーが特定のパーミッションへのアクセスを必要としなくなった場合は、そのパーミッションを各ユーザーから個別に削除する必要があります。
パーミッションをユーザーに直接割り当てるかわりに、ロールに割り当て、ユーザーをそのロールのメンバーにすることで各ユーザーにパーミッションを付与します。1人のユーザーに複数のロールを付与できます。図1-2に、ロールベースのアクセス制御の例を示します。
ユーザーの職責が（昇進などによって）変わる場合は、アクセス制御リスト内に多数存在する、そのユーザーのエントリを更新するかわりに、そのユーザーに異なるロールを割り当てることで認可情報を簡単に更新できます。
たとえば、複数のユーザーが/home/userディレクトリ内のファイルsalariesに対する書込み権限を必要としなくなった場合は、その権限をHRロールから削除します。HRロールのメンバー全員の権限が自動的に更新されます。
また、あるロールを別のロールに付与してロール階層を形成することもでき、管理者はこれを社内のセキュリティ・ポリシー・モデルを作成するためのツールとして使用できます。
これまでに説明した認証と認可の機能からは独立した、データを転送するときに保護する機能です。ここでは、ネットワークやインターネットを経由して転送されるデータが第三者によってインターセプト、読取り、または変更ができないようにする機能の概要を説明します。OC4Jでは、Secure Sockets Layer経由のHTTPプロトコルを使用して安全な通信がサポートされます。
この項の内容は次のとおりです。
Secure Sockets Layer（SSL）は、暗号化、認証およびデータ整合性により機密性を提供する業界標準のPoint-to-Pointプロトコルです。SSLは多数のプロトコルで使用されますが、OC4Jでは、HTTPブラウザ・プロトコルや、Oracle HTTP ServerとOC4Jプロセス間のApache JServ Protocolリンクに使用される場合に最も重要です。
便宜上、このマニュアルでは、SSL上で実行するHTTPを説明する際の短縮名としてHTTPSを使用します。https:というURL接頭辞はありますが、HTTPSというプロトコルは存在しません。
サーバーがSSL通信を構成するかどうかは、クライアントがSSL通信を構成するかどうかと無関係です。このドキュメントでは、第15章「OC4JとのSSL通信」でOC4JエンドでのSSLの有効化、およびOracle Application Server環境におけるOracle HTTP ServerとOC4J間のSSL通信について説明します。第16章「クライアント接続用Oracleセキュリティ」では、SSL機能をクライアントHTTPS接続に提供するHTTPSのOC4J実装について説明します。
SSL通信を使用した場合、次のいずれの認証シナリオも可能です。
サーバーでSSL認証を構成することは、クライアントでSSL認証を構成することと無関係です。
アプリケーションは、認証および認可情報をネットワークで送信する必要があります。デジタル証明はX.509バージョン3規格で指定されたもので、プリンシパルの認証および認可情報の設定データが含まれています。証明書の内容は次のとおりです。
各証明書には、トラスト・ポイントによるデジタル署名が添付されます。証明書に署名するトラスト・ポイントは、VeriSign社などの認証局（CA）、法人または個人のいずれかです。
企業や個人など、2つのエンティティ間で行われるSSL通信の場合、サーバーには公開鍵とそれに関連付けられた秘密鍵があります。それぞれの鍵は番号で、エンティティの秘密鍵はそのエンティティが機密として保管し、エンティティの公開鍵はセキュアな通信を必要とする第三者に公開されます。交換されるデータのセキュリティは、秘密鍵の機密を保つことと複雑な暗号化アルゴリズムにより保証されます。この方式は、データの暗号化と復号化に異なる鍵が使用されるため、非対称型暗号化と呼ばれます。
非対称型暗号化は複雑なため、パフォーマンスに負荷がかかります。それに比べて大幅に高速な方式が対称型暗号化で、この方式ではデータの暗号化と復号化に同じ鍵が使用されます。ただし、対称型暗号化には、送信側と受信側の両方が同じ鍵を知っており、その鍵のやり取りを第三者に不正傍受されると通信がセキュアでなくなるという弱点があります。
通常、SSLでは非対称型暗号化（公開鍵と秘密鍵）および対称型暗号化を組み合せて通信を保護します。公開鍵の交換は、通信に関わる当事者の相互認証に使用されます。これにより、通信の当事者は、セッションでこれ以降のデータの暗号化と復号化に使用する対称鍵の作成時に安全に協働できます。クライアントとサーバー間でSSLセッションを作成する基本的な例を次に示します。
SSLでは、サーバーの公開鍵はX.509証明書と呼ばれるデータ構造を使用してクライアントに送信されます。この証明書は認証局により作成され、公開鍵、証明書の所有者情報および必要な場合は所有者のなんらかのデジタル権利が含まれています。証明書には、それを作成したCAが自身のデジタル証明の公開鍵を使用してデジタル形式で署名します。
SSLでは、CAの署名が受信側プロセスによりチェックされ、CA署名の承認済リストに含まれていることが確認されます。このチェックは、証明連鎖の分析により実行される場合があります。この処理が発生するのは、受信側プロセスの承認済リストに署名したCAの公開鍵が含まれていない場合です。その場合、受信側プロセスでは、CAの証明書の署名者が承認済リストに含まれているかどうか、署名者の署名者が承認済リストに含まれているかどうかなどがチェックされます。この証明書、証明書の署名者、証明書の署名者の署名者という連鎖は、証明連鎖と呼ばれます。連鎖に含まれる最上位の証明書（オリジナルの署名者）は、証明連鎖のルート証明書と呼ばれます。
ルート証明書は、通常は受信側プロセスの承認済リストに含まれています。承認済リストに含まれている証明書は、信頼できる証明書とみなされます。ルート証明書には、CAが署名するか、自己署名できます。自己署名は、ルート証明書を検証するデジタル署名が、上位CAの秘密鍵ではなく、証明書に含まれる公開鍵に対応する秘密鍵を介して暗号化されることを意味します。（CA自体の証明書は常に自己署名であることに注意してください。）
証明書は、公開鍵および関連する署名のコンテナとして機能します。単一の証明書ファイルには、連鎖全体の範囲内で1つ以上の証明書を含めることができます。通常、秘密鍵は意図しない公開を防ぐために別個に保管されますが、アプリケーション間での移植性を考慮して証明書ファイルの別個のセクションに組み込むことができます。
キーストアは、すべてのトラステッド・ユーザーの証明書など、プログラムで使用される証明書の格納に使用されます。OC4Jなどのエンティティは、そのキーストアを介して第三者の認証や、第三者に対する自己認証を行うことができます。キーストアのパスワードは不明瞭化されます。Oracle HTTP Serverには、これと同じ用途を持つWalletと呼ばれるものがあります。Sun社のSSL実装にはトラストストアという表記が導入されています。これは、クライアントがSSLハンドシェイク中に暗黙的に受け入れる、信頼できる認証局が含まれたキーストア・ファイルです。
Javaでは、キーストアはjava.security.KeyStoreインスタンスで、Sun社のJDKに付属のkeytoolユーティリティを使用して作成および操作できます。このオブジェクトの基礎となっているのは、物理的にはファイルです。
|
 Copyright © 2003, 2008 Oracle Corporation. All Rights Reserved. |
|