| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3の理解 12c (12.1.3) E56254-04 |
|
 前 |
 次 |
この章では、WebLogic Serverのセキュリティ・サービスおよびWebLogic Server 12.1.3の環境を保護する方法を紹介します。
この章の内容は次のとおりです。
WebLogic Serverでは、Java EE 6の次のセキュリティ機能がサポートされています。
Java Authorization Contract for Containers (JACC) 1.4
JACC仕様では、Java EEアプリケーション・サーバーと認可ポリシー・プロバイダとの間の規約を定義しています。すべてのJava EEコンテナが、この規約をサポートしています。
JACC仕様では、Java EE認可モデルを満たすjava.security.Permissionクラスが定義されます。この仕様では、これらの権限クラスのインスタンスに対する操作への、コンテナのアクセス決定のバインディングが定義されます。新しい権限クラスを使用して、ロールの定義および使用を含む、Java EEプラットフォームの認可要件に対処する、ポリシー・プロバイダのセマンティクスが定義されます。
Java Authentication Service Provider Interface for Containers (JASPIC) 1.0
JASPIC仕様では、メッセージ認証メカニズムを実装する認証プロバイダをクライアントまたはサーバーのメッセージ処理コンテナまたはランタイムに統合できる、サービス・プロバイダ・インタフェース(SPI)を定義しています。このインタフェースを介して統合された認証プロバイダは、呼出し側コンテナによって提供されたネットワーク・メッセージに対して操作を実行します。認証プロバイダは、受信コンテナがメッセージのソースを認証できるように、およびメッセージ送信者がメッセージの受信者を認証できるように、送信メッセージを変換します。認証プロバイダは受信メッセージを認証し、それを呼出し側コンテナに戻すと、メッセージ認証の結果としてIDが確立されます。
WebLogic Serverには、Webを介して使用できるアプリケーション用に一意でセキュアな基盤を提供するセキュリティ・アーキテクチャが含まれています。企業は、WebLogic Serverのセキュリティ機能を利用することで、Web上で使用できるアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ・インフラストラクチャのメリットを得ることができます。WebLogicセキュリティは、WebLogic Serverアプリケーションを保護するためにスタンドアロンで使用することも、最高レベルのセキュリティ管理ソリューションを表す企業全体のセキュリティ管理システムの一部として使用することもできます。
WebLogicセキュリティ・サービスの主な特徴は、次のとおりです。
包括的な標準ベースの設計。
メインフレームからWebブラウザまでを網羅する、WebLogic Serverをホストとしたアプリケーション向けのエンドツーエンド・セキュリティ。
レガシー・セキュリティ方式をWebLogic Serverセキュリティに統合することによって、企業の既存投資を活用できます。
融通性の高い統一されたシステムに組み込まれ、企業全体にわたるセキュリティ管理を容易化するセキュリティ・ツール。
企業のビジネス・ルールをセキュリティ・ポリシーにマッピングするため、ビジネス要件に対するアプリケーション・セキュリティのカスタマイズが容易です。
Java EEリソースおよびアプリケーション定義のリソースに、同じモデルに従ってセキュリティ・ポリシーを適用できます。
セキュリティ・ポリシーの容易な更新。このリリースでは、セキュリティ・ポリシーだけでなく、WebLogicリソースへのアクセスを制御する式の作成が、より容易に行えるようになっています。
カスタマイズされたセキュリティ・ソリューションへの適合が容易です。
モジュール化されたアーキテクチャなので、特定の企業の要件を満たすようにセキュリティ・インフラストラクチャを時間を追って変更できます。
遷移方式またはアップグレード・パスの一部として、複数のセキュリティ・プロバイダの構成をサポート。
セキュリティの詳細とアプリケーション・インフラストラクチャを分離することにより、要件の変化に合わせたセキュリティのデプロイ、管理、維持、および修正を容易化。
即時利用可能な実践的セキュリティ方式を提供する、デフォルトのWebLogicセキュリティ・プロバイダ。このリリースでは、その他の認証ストア(データベースなど)をサポートし、選択したセキュリティ・プロバイダによって使用されるデータ・ストアとして、外部RDBMSシステムを構成することができます。
カスタム・セキュリティ・プロバイダを使用したセキュリティ・スキームのカスタマイズ。
WebLogic Server管理コンソールを使用して、セキュリティ・ルール、セキュリティ・ポリシー、およびセキュリティ・プロバイダを統一して管理できます。
JAAS (Java Authentication and Authorization Service)、JSSE (Java Secure Socket Extension)、JCE (Java Cryptography Extension)、JACC (Java Authorization Contract for Containers)などの標準のJava EEセキュリティ技術をサポートしています。
SAML (Security Assertion Markup Language) 1.1および2.0のサポートを含む、Webサービス・セキュリティの基盤。
Webサイト、Webアプリケーション、デスクトップ・クライアントでのシングル・サインオン(SSO)へのWebLogic Serverの参加を可能にします。
証明書のルックアップ、検証、失効だけでなく、証明書レジストリも含む公開鍵管理のためのフレームワーク。
この節では、WebLogicセキュリティ・サービスのアーキテクチャについて説明します。アーキテクチャは、次の節で説明する5つの主要なコンポーネントで構成されています。
図10-1では、WebLogicセキュリティ・フレームワークの概観を示します。フレームワークは、weblogic.security.serviceパッケージのインタフェース、クラス、および例外で構成されます。
WebLogicセキュリティ・フレームワークの主な役割は、簡素化されたアプリケーション・プログラミング・インタフェース(API)を提供することです。APIは、セキュリティ・サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。そのコンテキスト内でWebLogicセキュリティ・フレームワークは、WebLogicコンテナ(WebおよびEJB)、リソース・コンテナ、セキュリティ・プロバイダの間の仲介役としても機能します。
SSO (シングル・サインオン)は、ユーザーが一度アプリケーション・コンポーネントにサインオンすれば、他の様々なアプリケーション・コンポーネントに(それらが独自の認証方式を使用している場合でも)アクセスできる機能です。シングル・サインオンを使用すると、ユーザーはすべてのアプリケーション、Webサイト、メインフレーム・セッションに、1つのIDでセキュアにログインできます。SAML (Security Assertion Markup Language)およびWindows統合認証機能は、WebLogic ServerアプリケーションにおいてWebベースのSSO (シングル・サインオン)機能を提供します。
WebLogic WebサービスとWebLogicセキュリティ・フレームワークは、SAML 1.1および2.0アサーションの生成、消費および検証をサポートします。SAMLアサーションを使用する場合は、WebサービスがSAMLアサーションとそれに付随する証明データをWebLogicセキュリティ・フレームワークに渡します。SAMLアサーションが有効で信頼されれば、フレームワークが認証されたサブジェクトと信頼性のあるプリンシパルをWebサービスに返します。WebLogic WebサービスとWebLogicセキュリティ・フレームワークでは、次のSAMLアサーションがサポートされます。
Sender-Vouches - サブジェクトとは異なるアサーション側がサブジェクトの検証を保証します。受信側がアサーション側との信頼関係を確立している必要があります。
Holder-of-Key -「holder-of-key」サブジェクト確認が指定されたSAMLトークンは、リクエスト・メッセージの整合性を確保するために、受信側で信頼されていない可能性のあるX.509証明書をサブジェクトで使用できるようにすることを目的としたものです。
理論的には、アサーション側によってX.509のパブリック証明書(または他のキー情報)がSAMLアサーションに挿入されます。(厳密には、アサーション・パーティによりキーがサブジェクトにバインドされます。)この組み込まれた証明書を保護するには、SAMLアサーション自体がアサーティング・エンティティによって署名されている必要があります。WebLogic Serverの場合、SAMLアサーションはWebサービス・クライアントによって署名され、署名にはWebサービス・クライアントの秘密鍵が使用されます。つまり、アサーションの署名はSAML権限の署名であり、アサーションに含まれる証明書やアサーションにより特定される証明書に基づくものではありません。
Bearer - アサーションのサブジェクトはアサーションのベアラーであり、アサーションの<SubjectConfirmationData>要素に含まれている属性を使用した確認に対するオプションの制約に従います。
WebLogic Serverのセキュリティは、一連のSSPI (セキュリティ・サービス・プロバイダ・インタフェース)に基づいています。開発者およびサード・パーティ・ベンダーは、SSPIを使用してWebLogic Server環境向けのセキュリティ・プロバイダを開発できます。SSPIは、認証、IDアサーション、認可、監査、裁決、ロール・マッピング、資格証明マッピング、および証明書の検索と検証に利用可能です。
SSPIを使用すると、カスタム・セキュリティ・プロバイダでWebLogic Serverリソースを保護することができます。SSPIを使用してカスタム・セキュリティ・プロバイダを開発することも、サード・パーティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することもできます。
カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
セキュリティ・プロバイダは、WebLogic Serverのセキュリティ・レルムに「プラグイン」してアプリケーションにセキュリティ・サービスを提供するためのモジュールです。セキュリティ・プロバイダは、アプリケーションのかわりにWebLogicセキュリティ・フレームワークに働きかけを行います。
WebLogic Server製品に付属しているセキュリティ・プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム・セキュリティ・プロバイダで補足するか、あるいはカスタム・セキュリティ・プロバイダに置き換えることができます。カスタム・セキュリティ・プロバイダは次のようにして開発します。
weblogic.security.spiパッケージから適切なセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してセキュリティ・プロバイダの実行時クラスを作成します。
MBean定義ファイル(MDF)を作成し、WebLogic MBeanMakerユーティリティを使用してMBeanタイプを生成します。MBeanタイプは、セキュリティ・プロバイダの構成と管理に使用します。
詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。
この節では、次のトピックを取り上げます。
セキュリティ・レルムは、WebLogicリソースを保護する複数のメカニズムで構成されています。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。ユーザーはセキュリティ・レルムで定義されていないと、そのセキュリティ・レルムに属するWebLogicリソースにアクセスできません。ユーザーが特定のWebLogicリソースにアクセスしようとした場合、WebLogic Serverは、関連するセキュリティ・レルムでそのユーザーに割り当てられているセキュリティ・ロールと、その特定のWebLogicリソースのセキュリティ・ポリシーをチェックして、ユーザーを認証および認可します。
セキュリティ・ポリシーはアクセス制御リスト(ACL)にかわるもので、「誰がWebLogicリソースにアクセスできるか」という問いに答えるものです。セキュリティ・ポリシーは、WebLogicリソースと、1つまたは複数のユーザー、グループ、またはセキュリティ・ロールとの間に関連付けを定義するときに作成されます。また、セキュリティ・ポリシーに日時制約を定義することもできます。WebLogicリソースにセキュリティ・ポリシーが割り当てられている場合、それに保護が設定されます。
セキュリティ・ポリシーは、定義済みの任意のWebLogicリソース(EJBリソースやJNDIリソースなど)、またはWebLogicリソースの特定のインスタンス(Webアプリケーション内のEJBメソッドやサーブレット)の属性または操作に割り当てることができます。セキュリティ・ポリシーをWebLogicリソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ・ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ・ポリシーは、WebLogicリソースのタイプに割り当てられたセキュリティ・ポリシーをオーバーライドします。
OPSS (Oracle Platform Security Services)を使用することで、エンタープライズ製品開発チーム、システム・インテグレータ(SI)、および独立系ソフトウェア・ベンダー(ISV)は、標準ベースで移植可能なエンタープライズ・レベルの統合セキュリティ・フレームワークに基づいて、Java Standard Edition (Java SE)アプリケーションおよびJava Enterprise Edition (Java EE)アプリケーションを開発できます。
OPSSでは、標準ベースのアプリケーション・プログラミング・インタフェース(API)の形式で抽象化レイヤーが提供されているため、開発者はセキュリティやID管理の実装についての詳細を意識する必要がありません。OPSSを使用すれば、開発者は、暗号鍵管理や、ユーザー・リポジトリおよびその他のID管理インフラストラクチャとの相互作用について詳しく理解する必要はありません。OPSSを使用することで、自社開発のアプリケーション、サード・パーティ製のアプリケーション、および統合アプリケーションはすべて、企業全体で同じ共通のセキュリティ、ID管理、および監査サービスを使用できるようになります。
OPSSはWebLogic Serverのコンポーネントではなく、スタンドアロンWebLogic Serverインストールでは使用できません。OPSSは、Oracle Fusion Middlewareインフラストラクチャ・ソフトウェアから使用可能であり、Oracle JRFテンプレートをベースにしている、またはそれによって拡張されているドメイン内のWebLogic Serverとともに使用できます。詳細は、Oracle Fusion Middlewareインフラストラクチャのインストールと構成を参照してください。Oracle JRFドメイン・テンプレートの詳細は、ドメイン・テンプレート・リファレンスのOracle JRFテンプレートに関する項を参照してください。
Coherenceは、WebLogic Serverのセキュリティ・コンポーネントおよびCoherence固有のセキュリティ・コンポーネントの両方を使用して保護されています。次のようなコンポーネントがあります。
Coherenceクラスタ・メンバー間の認証用のSSL
Extendクライアント(WebLogic Serverの外部にある)とCoherenceクラスタ間の認証用のSSL
Coherenceサービスとキャッシュの認可用のWebLogic Serverのポリシーとロール
ExtendクライアントとCoherenceクラスタ間のIDアサーション
Coherenceセキュリティの構成の詳細は、Oracle Coherenceセキュリティ・ガイドのWebLogic ServerでのCoherenceの保護に関する項を参照してください。
表10-1 WebLogic Serverの保護のためのロードマップ
| 主要なタスク | サブタスクと追加情報 |
|---|---|
|
セキュリティに関する基礎概念についてもっとよく知る |
|
|
WebLogic Serverセキュリティの管理 |
|
|
ユーザー認証 |
|
|
SSLの構成 |
|
|
認可の構成 |
|
|
セキュリティ・レルムについてもっとよく知る |
|
|
セキュリティを目的としたアプリケーションのプログラミング |
|
|
ベスト・プラクティス |
|
