WebLogic Platform 8.1 のセキュリティ
|
 |
 |
|
以下の節では、WebLogic Platform セキュリティの管理に関連する作業について次の項目の概要を説明します。
この節では、以前のリリースの WebLogic Platform からセキュリティ コンフィグレーションをアップグレードする際の考慮事項と、WebLogic Platform ドキュメントでのセキュリティ アップグレードに関する参照先を示します。WebLogic Platform ドキュメントのアップグレードに関連するトピックの詳細なリストについては、『WebLogic Platform 8.1 へのアップグレード』を参照してください。
注意 : 互換性セキュリティは WebLogic Platform ではサポートされていません。ドメインに WebLogic Server しか含まれていない場合は、互換性セキュリティを使用することができます。ただし、そのドメインに WebLogic Portal または WebLogic Integration コンポーネントを追加すると、互換性セキュリティはサポートされなくなります。
WebLogic Server 7.0 から 8.1 へアップグレードするときには、セキュリティ システムに以下の変更があるため注意してください。
config.xml ファイルに格納されるようになります。既存のセキュリティ コンフィグレーション データは、WebLogic Server 8.1 サーバを最初にブートしたときに config.xml ファイルに書き込まれます。WebLogic Server 8.1 セキュリティへのアップグレードの詳細については、『WebLogic Server 8.1 へのアップグレード』の「WebLogic Server 7.0 からバージョン 8.1 へのアップグレード」の「セキュリティ」を参照してください。
WebLogic Platform 8.1 では、WebLogic Integration で使用されるセキュリティ モデルが大きく変わっています。バージョン 7.0 では、WebLogic Integration で互換性セキュリティが使用されていましたが、WebLogic Platform ではサポートされなくなりました。バージョン 8.1 では、WebLogic Server 7.0 で導入された新しいセキュリティ モデルが使用されます。
以前のリリースの WebLogic Integration からのセキュリティ コンフィグレーションのアップグレードに関連する以下のトピックについては、『WebLogic Integration 8.1 へのアップグレード』を参照してください。
WebLogic Platform 8.1 では、WebLogic Portal で使用されるセキュリティ モデルが大きく変わっています。バージョン 7.0 では、WebLogic Portal で互換性セキュリティが使用されていましたが、WebLogic Platform ではサポートされなくなりました。バージョン 8.1 では、WebLogic Server 7.0 で導入された新しいセキュリティ モデルが使用されます。
以前のリリースの WebLogic Portal からのセキュリティ コンフィグレーションのアップグレードに関連する以下のトピックについては、『WebLogic Portal 8.1 へのアップグレード』を参照してください。
7.0 から 8.1 にアップグレードする際、セキュリティに関するアップグレードの要件はありません。ただし、新しいセキュリティ ツールや機能が以下のようにいくつかあります。
@common:security アノテーション : このアノテーションにより、ロールの制約が自動的に EJB コンフィグレーション ファイルに書き込まれるため、手間がかかる手動プロセスを省略できます。このアノテーションは、Java ページ フローを除く、すべての Java 派生ファイル (Web サービス、ビジネス プロセス定義、拡張可能 Java コントロールなど) で利用できます。 詳細については、WebLogic Workshop ヘルプの「ロールベースのセキュリティの概要」を参照してください。
詳細については、WebLogic Workshop ヘルプの「プリンシパルおよびロールとプリンシパル間のマッピングを作成する」を参照してください。
コンフィグレーション ウィザードを使用して新しいドメインを作成する場合、ドメインの管理ユーザ名とパスワードを指定するプロンプトが表示されます。ドメインのユーザ、グループ、ロールを定義することにより、アプリケーション リソースに追加のセキュリティを指定することもできます。コンフィグレーション ウィザードでのセキュリティのコンフィグレーションに関する詳細については、『コンフィグレーション ウィザードの使い方』の「セキュリティのコンフィグレーション」を参照してください。
WebLogic Platform セキュリティの最も優れた特徴の 1 つは、堅牢に保護されたデプロイメントをサポートする柔軟性です。セキュリティ コンフィグレーションを計画する際には、その実装を管理者が行うのか、プログラムによって行うのか、または両者を組み合わせるのかを選択する必要があります。
管理者は通常、管理コンソールを使用してさまざまなリソースのセキュリティを確保します。たとえば、組織のセキュリティ要件が変更になった場合、管理者は、開発者に複数のデプロイメント記述子の修正を要求する代わりに、すべてのセキュリティ コンフィグレーションを集中管理のグラフィカル ユーザ インタフェースから変更することができます。ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーはすべて、管理コンソールを使用して定義、修正、管理できます。その結果、新しいセキュリティ要件に基づいて変更を行う際の手順は、より効率的になります。
この手法を使用すると、WebLogic Platform のすべてのタイプのリソースに対するセキュリティをコンフィグレーションできます。このようなことから、このドキュメントで WebLogic Platform リソースのセキュリティを確保するために推奨する内容は、特に管理コンソールのユーザを対象にしています。
開発者は通常、ロールをプログラムによって定義し、適用します。ロールは、デプロイメント記述子に関連付けられています。管理者は、後からいつでもロールおよびセキュリティ ポリシーを追加できます。EJB や Web アプリケーションなどのリソースに、そのデプロイメント記述子内でセキュリティを指定することの最大のメリットは、この手法がこのようなタイプのアプリケーションに宣言型セキュリティを追加するための広く知られた標準の方法であることです。また、この手法については、多くの組織でよく知られている可能性があります。この手法を使用する場合、セキュリティ ロールおよびポリシーは、web.xml、weblogic.xml、ejb-jar.xml、および weblogic-ejb-jar.xml デプロイメント記述子内に指定されます。
最適な管理者モデルを選択する際には、誰が組織内のセキュリティ管理責任者となるかを熟慮してください。アプリケーション コンポーネントに最も精通しているのはそれを構築する開発者ですが、開発者はそのコンポーネントが実行されるデプロイメント環境に詳しいとは限りません。また、セキュリティ ポリシーが変更されたときには、アプリケーションの構築、テスト、およびデプロイを再度行うよりも、管理者がセキュリティを再コンフィグレーションする方がより簡単です。
WebLogic Server Administratio Console でコンフィグレーションしたセキュリティ設定は、デフォルトですべてのプラットフォーム コンポーネントに伝播されます。たとえば、WebLogic Server Administration Console で追加したユーザおよびグループは、デフォルトで WebLogic Integration、WebLogic Portal、および WebLogic Workshop のアプリケーションとリソースのユーザになります。逆に、WebLogic Integration または WebLogic Portal 管理コンソールで追加したユーザは、デフォルトで WebLogic Server のユーザになります。
WebLogic Integration および WebLogic Portal の管理コンソールの目的は、これらのコンポーネント専用のエンティティをコンフィグレーションおよび管理することです。WebLogic Portal および WebLogic Integration リソースのセキュリティ コンフィグレーションは、これらのコンポーネント用の管理コンソールでのみ表示可能です。
表 2-1 は、WebLogic Platform の管理コンソールを使用して保護できるリソースの一覧を示しています。
|
|
|
|
|
|
|
|
注意 : WebLogic Workshop を使用して開発したアプリケーションのセキュリティ ポリシーを定義する際には、WebLogic Platform の任意の管理コンソールを使用できます。ただし、開発モード サーバの Weblogic Workshop からアプリケーションを再デプロイする場合は、定義したセキュリティ ポリシーはそのアプリケーションのデプロイメント記述子で指定されたポリシーにリセットされます。この現象はプロダクション モードのサーバでは発生しません。
WebLogic Platform コンポーネントのアプリケーションは、1 つのドメイン内の他のサーバ上にコンフィグレーションすることがあります。たとえば、WebLogic Potal アプリケーションを WebLogic Integration、Workshop、EJB のアプリケーションから独立して管理することがあります。WebLogic Portal アプリケーションを専用のサーバでコンフィグレーションすることによって、顧客の要求にすばやく対応しながら、アプリケーションとの通信を継続できます。
アプリケーションが複数のドメインに分散している場合、それらのドメイン間に信頼関係を確立する必要があります。信頼関係が確立されると、1 つのドメインのプリンシパルが、他のドメインでもプリンシパルとして受け入れられます。信頼関係を確立するには、1 つのドメイン内の SecurityConfigurationMBean の Credential 属性 (config.xml ファイルを参照) が、他のドメインの SecurityConfigurationMBean の Credential 属性と一致していなければなりません。Credential 属性が設定されていない場合、管理サーバを最初に起動したときに管理サーバによってこの属性が設定されていないことが検出され、ランダムな資格が作成されます。この資格は、そのドメインで作成されたプリンシパルへの署名に使われます。同じドメイン内の他のサーバによって管理サーバから資格が取り出され、その結果、ドメイン内で信頼関係が確立されます (信頼関係を確立する必要があるのは、複数のドメインが関係している場合のみです。複数のサーバが同じドメイン内で稼動している場合は必要ありません)。詳細については、『WebLogic Security の管理』の「WebLogic ドメインのセキュリティのコンフィグレーション」の「WebLogic Server ドメイン間の信頼関係の有効化」を参照してください。
クラスタ環境で WebLogic Platform アプリケーションをコンフィグレーションする場合、クラスタ内のサーバはすべて同一でなければなりません。つまり、ある WebLogic Platform コンポーネント用のサーバを、他の WebLogic Platform コンポーネント用のサーバと別にデプロイする場合、最初のコンポーネントを 1 つのクラスタにデプロイし、別のコンポーネントを別のクラスタにデプロイする必要があります。たとえば、1 つのクラスタに WebLogic Integration アプリケーションをデプロイし、別のクラスタに WebLogic Portal アプリケーションをデプロイすることは可能です。ただし、クラスタ化されたドメインでは、セキュリティ設定がドメイン全体に同じように適用されます。クラスタ間の違いは、アプリケーションのデプロイメントの方法だけです。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
WebLogic Platform では、デフォルトのセキュリティ コンフィグレーションを柔軟にカスタマイズすることができます。セキュリティ コンフィグレーションは、以下のような方法でカスタマイズできます。
詳細については、『WebLogic Security の管理』の「デフォルト セキュリティ コンフィグレーションのカスタマイズ」および「セキュリティ プロバイダのコンフィグレーション」を参照してください。
マシン障害などの問題に備えて、ユーザ情報のアーカイブを保持しておくことを強くお勧めします。以下の節では、ユーザ情報のバックアップについて説明します。
組み込み LDAP サーバにユーザ情報を格納している場合、WebLogic Platform では、アーカイブまたは別の組み込み LDAP サーバに対して以下の操作を実行できる組み込みツールを使用できます。
外部 LDAP サーバを使用している場合は、格納されているユーザ情報のバックアップ用としてサーバに付属しているツールを使用する必要があります。また、WebLogic Platform によって格納されたシステムとユーザのプロファイルのバックアップには、RDBMS に付属のツールを使用することができます。
デジタル証明書は、インターネットなどのネットワーク上でプリンシパルとオブジェクトを固有のエンティティとして識別するために使用される電子ドキュメントです。デジタル証明書は、ユーザまたはオブジェクトの ID を、認証局として知られる信頼できるサードパーティによって確認されたものとして、特定の公開鍵に安全にバインドします。公開鍵とプライベート キーの組み合わせにより、デジタル証明書のオーナーの固有の ID が決まります。
プライベート キー、デジタル証明書、および信頼できる認証局 (Certificate Authority : CA) 証明書を取得した後は、それらを格納し、WebLogic Server がそれらを使用して ID を検索および確認できるようにする必要があります。プライベート キー、プライベート キーに関連付けられた証明書、および信頼できる CA 証明書は、キーストアに格納されます。キーストアは、WebLogic Server Administration Console を使用して、またはコマンドラインからの指定でコンフィグレーションできます。WebLogic Server Administration Console の [キーストア & SSL] ページにある [キーストア コンフィグレーション] セクションを使用して、WebLogic Server の ID と信頼キーストアを作成します。
注意 : WebLogic Platform では、デジタル証明書のアーカイブおよびリストア用のツールが提供されていないため、システム障害の場合のために証明書のバックアップ コピーを必ず保持しておく必要があります。
WebLogic Integration には、トレーディング パートナのプロファイルをエクスポートおよびインポートできるユーティリティが用意されています。これについては、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックで説明されています。
BEA dev2dev Web サイトの以下の URL に、WebLogic Platform 8.1 で役立つその他の資料があります。
http://www.beasys.co.jp/dev2dev/products/wlplatform81/index.html
WebLogic セキュリティ サービスは、ユーザ、グループ、およびセキュリティ ロールを 1 つのセキュリティ レルムからエクスポートし、同一または新しいドメインの別のセキュリティ レルムにインポートする機能をサポートしています。1 つのセキュリティ プロバイダに関連付けられたセキュリティ データを個別に移行することも、各セキュリティ プロバイダに関連付けられたすべてのセキュリティ データ (セキュリティ レルム全体のセキュリティ データ) を一度に移行することもできます。セキュリティ データは、WebLogic Server Administration Console または weblogic.Admin ユーティリティを使用して移行できます。
セキュリティ データの移行は、以下のような場合に役立ちます。
セキュリティ データを同一または別のドメインの別のセキュリティ レルムに移行する場合は、以下のことに注意してください。
詳細については、『WebLogic Security の管理』の「セキュリティ データの移行」を参照してください。weblogic.Admin ユーティリティを使用してセキュリティ情報を別のセキュリティ レルムに移行する方法については、『WebLogic Security の管理』の「セキュリティ データの移行」の「weblogic.Admin ユーティリティの使い方」を参照してください。
この節では、WebLogic Platform アプリケーションを実行するプロダクション環境のセキュリティに関する考慮事項を説明します。また、ここでは、WebLogic Server、WebLogic Integration、WebLogic Portal、および WebLogic Workshop のドキュメントの中から、プロダクション環境のセキュリティに役立つドキュメントへのリンクも紹介します。
WebLogic Server ドキュメント『プロダクション環境のセキュリティ』には、WebLogic Platform プロダクション環境を保護するための基本的なヒントがいくつか記載されています。特に、このドキュメントからは、以下の重要なリソースの保護に関して、一般的なアドバイスと詳細なアドバイスが得られます。
基本的なアプリケーション環境のセキュリティに加えて、以下のような WebLogic Platform 固有のリソースのセキュリティも確保することをお勧めします。
プロダクション環境でのこのような WebLogic Platform リソースおよびその他の WebLogic Platform リソースのセキュリティに関する詳細については、以下のドキュメントを参照してください。
|
|
|
|
|
|
|
|
アプリケーションを管理サーバにデプロイしたり、管理サーバを直接インターネットで公開したりするのは避けてください。プロダクション システムを設定するときには、1 つの管理サーバと 1 つまたは複数の管理対象サーバで構成されたドメインにアプリケーションをデプロイすることをお勧めします。このタイプのドメイン コンフィグレーションは、WebLogic Server クラスタの組み込みのフェイルオーバおよびロード バランス機能によって可能になるより高い可用性とパフォーマンスを必要とするプロダクション環境に適しています。
アプリケーションを管理対象サーバにデプロイすることにより、アプリケーションとそのユーザはプロダクション環境インフラストラクチャから分離され、より高いセキュリティが実現します。また、管理サーバ、および管理サーバにデプロイされたすべてのコンポーネントがエンタープライズ外部から使用できないようにすることも重要です。
注意 : WebLogic Server Administration Console で定義されたオプションのデフォルト設定には、潜在的なセキュリティ リスクがあります。それは、[匿名 Admin のルックアップを有効化] オプションで、このオプションはデフォルトで選択されています。アプリケーションを保護するために、プロダクション モードに入るときにこのオプションの選択を解除することをお勧めします。コンソールでこのオプションを探すには、[ドメインのセキュリティ設定｜コンフィグレーション] の順に選択し、[全般] タブを選択します。[匿名 Admin のルックアップを有効化] の隣にあるボックスのチェックマークをはずします。ただし、この機能を無効にすると、意図的であるかどうかに関係なく管理 MBeanHome インタフェースの匿名ルックアップを実行するアプリケーションが正しく動作しない場合があることに注意してください。
監査とは、業務要求およびそのような要求の結果に関する情報を収集、保存、および配布して否認を防止する処理です。つまり、監査を行うと、コンピュータのアクティビティを電子的に追跡することができます。WebLogic Server セキュリティのアーキテクチャでは、監査サービスの提供には監査プロバイダが使用されます。
監査プロバイダがコンフィグレーションされている場合、WebLogic セキュリティ フレームワークにより、セキュリティに関する操作 (認証や認可など) の実行前後に監査プロバイダが呼び出されます。特定のイベントを監査するかどうかは、監査プロバイダ自体が決定します。この決定は、特定の監査基準または監査重大度のレベル、またはその両方に基づいて実行することができます。
セキュリティ レルム内では WebLogic 監査プロバイダまたはカスタム監査プロバイダを使用できます。監査プロバイダはセキュリティ レルム単位でコンフィグレーションされますが、各サーバは監査データをサーバ ディレクトリにある各自のログ ファイルに書き込みます。デフォルトで、WebLogic 監査プロバイダによって記録されるすべての監査情報は、以下のファイルに保存されます。
WL_HOME¥yourdomain¥yourserver¥DefaultAuditRecorder.log.
ただし、カスタム監査プロバイダを作成することにより、LDAP サーバ、データベース、単純なファイルなどのさまざまな出力リポジトリのいずれかに監査情報を含むレコードを送ることができます。
監査プロバイダのコンフィグレーションと監査の有効化の詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」の「WebLogic 監査プロバイダのコンフィグレーション」を参照してください。
|
|
|
