10 WebLogic Serverセキュリティの理解

WebLogic Serverには、アプリケーション用に一意でセキュアな基盤を提供するセキュリティ・アーキテクチャが含まれています。WebLogic Serverのセキュリティ機能を利用することで、エンタープライズでは、Web上で使用可能なアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ・インフラストラクチャによるメリットが得られます。

この章の内容は次のとおりです。

ノート:

WebLogic Serverをロック・ダウンするための重要なタスクの完全なチェックリスト(セキュアなドメインの構成やWebLogic Serverで使用されるネットワーク、ファイルおよびデータベースの保護のために推奨される特定のタスクを含む)は、『Oracle WebLogic Server本番環境の保護』を参照してください。

WebLogic ServerでのJSR 375セキュリティAPIのサポート

WebLogic Server 14.1.1.0.0では、JSR 375 Java EEセキュリティAPI 1.0 (Java EE 8の新しいセキュリティ機能)が完全にサポートされています。

Java EEセキュリティAPIでは、移植可能な認証メカニズム(HttpAuthenticationMechanismやIdentityStoreなど)と、SecurityContextインタフェースを使用するプログラムによるセキュリティのためのアクセス・ポイントが定義されます。これらの移植可能なプラグイン認証とアイデンティティ・ストア・インタフェースは、コンテナ提供の実装よりもメリットがあります。これは、アプリケーションによって、標準の移植可能な方法で認証プロセスとその認証で使用されるアイデンティティ・ストアを制御できるためです。外部で構成せずに、アプリケーションにセキュリティ構成をバンドルすると、アプリケーションのライフサイクルを管理しやすくなります(特に、コンテナに分散されているマイクロサービスの場合)。これらのAPIの組込み実装を使用するか、カスタム実装を定義できます。

WebLogic Serverでは、これらの認証メカニズムがWebコンテナでサポートされます。SecurityContextインタフェースはServletおよびEJBコンテナでサポートされます。WebLogic Serverでは、グループ・プリンシパル名が同じ名前のロールにマップされるセキュリティAPIの要件もデフォルトでサポートされます。

Java EEセキュリティAPI 1.0 (JSR 375)は、https://www.jcp.org/en/jsr/detail?id=375?id=375の仕様で定義されています。

WebLogic ServerでのJava EEセキュリティAPI (JSR 375)の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJava EEセキュリティAPIに関する項を参照してください。

WebLogic Serverセキュリティ・サービスの概要

WebLogic Serverには、インターネットを介して使用できるアプリケーション用に一意でセキュアな基盤を提供するセキュリティ・アーキテクチャが含まれています。WebLogic Serverのセキュリティ機能を利用することで、エンタープライズでは、公開して使用可能なアプリケーションの作成というセキュリティ課題に対処できるように設計された、包括的で柔軟性の高いセキュリティ・インフラストラクチャによるメリットが得られます。

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)、JASPIC (Java Authentication Service Provider Interface for Containers)、Java EEセキュリティAPI (JSR 375)などの標準のJava EEセキュリティ技術をサポートしています。

• Security Assertion Markup Language (SAML) 1.1および2.0のサポートを含む、Webサービス・セキュリティの基盤。

• Webサイト、Webアプリケーション、デスクトップ・クライアントでのシングル・サインオン(SSO)にWebLogic Serverを参加させることが可能です

• 証明書のルックアップ、検証、失効だけでなく、証明書レジストリも含む公開キー管理のためのフレームワーク。

WebLogic Serverセキュリティ・サービスのアーキテクチャ

WebLogic Serverのセキュリティ・サービスには、メインフレームからWebブラウザまでWebLogic Serverがホストするアプリケーションのエンドツーエンドのセキュリティを提供する包括的かつ標準ベースの設計、エンタープライズのビジネス・ルールをセキュリティ・ポリシーにマッピングできるアプリケーション・セキュリティの簡単なカスタマイズ、Java EEおよびアプリケーション定義のリソースにセキュリティ・ポリシーを適用するための一貫性のあるモデルなどがあります。

この節では、WebLogicセキュリティ・サービスのアーキテクチャについて説明します。このアーキテクチャには、次の主要コンポーネントが含まれます。

WebLogicセキュリティ・フレームワーク

図10-1では、WebLogicセキュリティ・フレームワークの概観を示します。フレームワークは、weblogic.security.serviceパッケージのインタフェース、クラス、および例外で構成されます。

図10-1 WebLogicセキュリティ・サービスのアーキテクチャ

「図10-1 WebLogicセキュリティ・サービスのアーキテクチャ」の説明

WebLogicセキュリティ・フレームワークの主な役割は、簡素化されたアプリケーション・プログラミング・インタフェース(API)を提供することです。APIは、セキュリティ・サービスを定義するセキュリティ開発者およびアプリケーション開発者によって使用されます。その状況で、WebLogicセキュリティ・フレームワークは、WebLogicコンテナ(WebおよびEJB)、リソース・コンテナ、セキュリティ・プロバイダの間の仲介役としても機能します。

WebLogicセキュリティ・フレームワークによるシングル・サインオン

SSO (シングル・サインオン)は、ユーザーが一度アプリケーション・コンポーネントにサインオンすれば、他の様々なアプリケーション・コンポーネントに(それらが独自の認証方式を使用している場合でも)アクセスできる機能です。SSOを使用すると、ユーザーはすべてのアプリケーション、Webサイト、メインフレーム・セッションに、1つのIDでセキュアにログインできます。Security Assertion Markup Language (SAML)およびWindows統合認証機能は、WebLogic ServerアプリケーションにおいてWebベースのSSO機能を提供します。

WebLogic WebサービスでのSAMLトークン・プロファイルのサポート

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>要素に含まれている属性を使用した確認に対するオプションの制約に従います。

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)

WebLogic Serverのセキュリティは、一連のSSPI (セキュリティ・サービス・プロバイダ・インタフェース)に基づいています。開発者およびサード・パーティ・ベンダーは、SSPIを使用してWebLogic Server環境向けのセキュリティ・プロバイダを開発できます。SSPIは、認証、IDアサーション、認可、監査、裁決、ロール・マッピング、資格証明マッピング、および証明書の検索と検証に利用可能です。

SSPIを使用すると、カスタム・セキュリティ・プロバイダでWebLogic Serverリソースを保護することができます。SSPIを使用してカスタム・セキュリティ・プロバイダを開発することも、サード・パーティ・ベンダーからカスタム・セキュリティ・プロバイダを購入することもできます。

カスタム・セキュリティ・プロバイダの開発の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

WebLogicセキュリティ・プロバイダ

セキュリティ・プロバイダは、WebLogic Serverのセキュリティ・レルムに「プラグイン」してアプリケーションにセキュリティ・サービスを提供するためのモジュールです。セキュリティ・プロバイダは、アプリケーションのかわりにWebLogicセキュリティ・フレームワークに働きかけを行います。

WebLogic Server製品に付属しているセキュリティ・プロバイダがセキュリティ要件を完全に満たしていない場合には、カスタム・セキュリティ・プロバイダで補足するか、あるいはカスタム・セキュリティ・プロバイダに置き換えることができます。カスタム・セキュリティ・プロバイダは次のようにして開発します。

• weblogic.security.spiパッケージから適切なセキュリティ・サービス・プロバイダ・インタフェース(SSPI)を実装してセキュリティ・プロバイダの実行時クラスを作成します。

• MBean定義ファイル(MDF)を作成し、WebLogic MBeanMakerユーティリティを使用してMBeanタイプを生成します。MBeanタイプは、セキュリティ・プロバイダの構成と管理に使用します。

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

WebLogic Serverセキュリティの管理

WebLogic Serverのセキュリティを管理する場合は、まず、セキュリティ・レルムの構成とセキュリティ・ポリシーの作成という2つのタスクに注目します。

セキュリティ・レルム

セキュリティ・レルムは、WebLogicリソースを保護する複数のメカニズムで構成されています。各セキュリティ・レルムは、構成済みのセキュリティ・プロバイダ、ユーザー、グループ、セキュリティ・ロール、およびセキュリティ・ポリシーで構成されます。そのレルムに定義されているWebLogicリソースにアクセスできるようにするには、セキュリティ・レルム内でユーザーを定義する必要があります。ユーザーがWebLogicリソースにアクセスしようとすると、WebLogic Serverはユーザーを認証し、セキュリティ・レルムで定義され、そのWebLogicリソースのセキュリティ・ポリシーで指定されているセキュリティ・ロールにユーザーをマップできるかどうかを判断してアクセスを認可します。

セキュリティ・ポリシー

セキュリティ・ポリシーは、「誰がこのWebLogicリソースにアクセスできますか」という質問に答えます。セキュリティ・ポリシーは、WebLogicリソースと、1つ以上のユーザー、グループまたはセキュリティ・ロールとの間の関連付けであり、WebLogicリソースを不正アクセスから保護します。セキュリティ・ポリシーを作成する際に、オプションで日付と時間の制約を定義できます。WebLogicリソースにセキュリティ・ポリシーが割り当てられている場合、それに保護が設定されます。

セキュリティ・ポリシーは、定義済の任意のWebLogicリソース(EJBリソースやJNDIリソースなど)、またはWebLogicリソースの特定のインスタンス(Webアプリケーション内のEJBメソッドやサーブレット)の属性または操作に割り当てることができます。セキュリティ・ポリシーをWebLogicリソースのタイプに割り当てると、そのリソースのすべての新しいインスタンスがそのセキュリティ・ポリシーを継承します。個々のリソースまたは属性に割り当てられたセキュリティ・ポリシーは、WebLogicリソースのタイプに割り当てられたセキュリティ・ポリシーをオーバーライドします。

Coherenceのセキュリティ

Oracle CoherenceをOracle WebLogic Serverドメイン内にデプロイする場合は、Oracle Coherenceのアクセス・コントローラ、Oracle WebLogic Serverの認可、およびOracle Coherenceのアイデンティティ・トークンの3つの主要なセキュリティ機能を使用できます。

Coherenceは、WebLogic Serverのセキュリティ・コンポーネントおよびCoherence固有のセキュリティ・コンポーネントの両方を使用して保護されています。次のようなコンポーネントがあります。

• Coherenceクラスタ・メンバー間の認証用のSSL

• Extendクライアント(WebLogic Serverの外部にある)とCoherenceクラスタ間の認証用のSSL

• Coherenceサービスとキャッシュの認可用のWebLogic Serverのポリシーとロール

• ExtendクライアントとCoherenceクラスタ間のIDアサーション

Coherenceセキュリティの構成の詳細は、『Oracle Coherenceの保護』の「Oracle WebLogic ServerにおけるOracle Coherenceの保護」を参照してください。

WebLogic Serverの保護のためのロードマップ

WebLogic Serverのドキュメント・セットには、WebLogic Securityサービスの使用方法の理解に役立つ、いくつかの入門的なトピック、手順的なトピック、リファレンス的なトピックがサンプルとともに含まれています。

表10-1 WebLogic Serverの保護のためのロードマップ

主要なタスク	サブタスクと追加情報
セキュリティに関する基礎概念についてもっとよく知る	監査 認証 SAML (Security Assertion Markup Language) SSO (シングル・サインオン) 認可 IDと信頼 セキュア・ソケット・レイヤー(SSL) WebLogicセキュリティ・フレームワーク WebLogicセキュリティ・フレームワークによるシングル・サインオン WebLogic WebサービスでのSAMLトークンのサポート Security Service Provider Interfaces (SSPI) WebLogicセキュリティ・プロバイダ
WebLogic Serverセキュリティの管理	セキュリティ管理の概念 デフォルト・セキュリティ構成のカスタマイズ セキュリティ・データの移行 組込みLDAPサーバーの管理 RDBMSセキュリティ・ストアの管理 キーストアの構成 SSLの構成 クロス・ドメイン・セキュリティの構成 Oracle WebLogic Serverロールおよびポリシーによるリソースの保護 クラスタ・アーキテクチャのセキュリティ・オプションの確認 Coherenceのセキュリティの構成
ユーザー認証	LDAPサーバーで定義されたユーザーの認証 RDBMSシステムに対しての認証 Windows NTドメインに対しての認証 リモート・ユーザーの認証 SAMLの使用 シングル・サインオンの構成 Microsoftのクライアントに対するシングル・サインオンの構成 WebブラウザとHTTPクライアントでのシングル・サインオンの構成 Kerberosの使用 複数の認証プロバイダの使用 パスワード作成ルールの構成 ユーザーとグループの管理 JASPIC (Java Authentication SPI for Containers)の使用 Java EEセキュリティAPIの使用
SSLの構成	SSLの設定:主なステップ キーストアの構成 キーストアの作成: サンプル X.509証明書失効チェック
認可の構成	ロールおよびポリシーによるWebLogicリソースの保護 認可プロバイダの構成 複数の認可プロバイダの使用 JAAS認可の使用 ロール・マッピング・プロバイダの構成 JACC (Java Authorization Contract Containers)の使用
セキュリティ・レルムについてもっとよく知る	セキュリティ・レルムの概要 ユーザー グループ セキュリティ・ロール セキュリティ・ポリシー セキュリティ・プロバイダ
セキュリティを目的としたアプリケーションのプログラミング	WebLogicセキュリティ・サービスによるアプリケーションの開発 リソース・アダプタ・セキュリティの構成 WebLogic Webサービス・セキュリティのトピック
WebLogic Serverの本番環境をロック・ダウンするためのガイドライン	Oracle WebLogic Server本番環境の保護