| Oracle® Fusion Middleware Oracle B2Bユーザーズ・ガイド 12c (12.2.1.2.0) E82782-02 |
|
 前へ |
 次へ |
この章では、OPSS、ロール、ユーザー、キーストア、セキュリティ・ポリシーなど、Oracle B2Bのセキュリティ機能について説明します。
この章の構成は、次のとおりです。
Oracle B2Bは、Oracle Platform Security Services (OPSS)フレームワークを使用してセキュリティを実装します。Oracle Platform Security Services(OPSS)は、サポート対象のプラットフォームまたはスタンドアロン・アプリケーションにデプロイされるアプリケーションの保護に使用可能なセキュリティ・プラットフォームです。OPSSには、Java SEおよびJava EEアプリケーション向けの、標準ベースで移植可能な、エンタープライズ級の統合セキュリティ・フレームワークが用意されています。
また、基盤となるセキュリティ・プラットフォームとして、WebLogic Server、Server Oriented Architecture (SOA)アプリケーション、Oracle WebCenter、Oracle Application Development Framework (ADF)アプリケーション、Oracle Entitlement ServerなどのOracle Fusion Middlewareにセキュリティを提供します。OPSSは、サード・パーティのアプリケーション・サーバーに移植できるため、OPSSを使用すれば1つのセキュリティ・フレームワークでOracle環境とサード・パーティ環境の両方に対応できます。これにより、アプリケーションの開発、管理およびメンテナンスに要する費用を削減できます。
OPSSでは、アプリケーション・プログラミング・インタフェース(API)として抽象レイヤーを提供しています。これにより、開発者は、セキュリティおよびアイデンティティ管理の実装の詳細に関与する必要がなくなります。OPSSを使用すれば、開発者は、暗号キーの管理、リポジトリ・インタフェースや他のアイデンティティ管理インフラストラクチャについて詳しく把握しておく必要がありません。社内開発アプリケーション、サード・パーティ・アプリケーションおよび統合アプリケーションでは、OPSSを使用することで、企業全体で統一された同一のセキュリティ・サービス、アイデンティティ管理サービスおよび監査サービスを利用できます。
OPSSは、ロールベースのアクセス制御(RBAC)、Java Enterprise Edition (Java EE)およびJava Authorization and Authentication Services (JAAS)の各標準に準拠しており、次の機能をサポートするセキュリティ・プラットフォームを提供します。
認証
IDアサーション
ファイングレインJAASパーミッションに基づいた認可
アプリケーション・ポリシーの指定と管理
資格証明ストア・フレームワークを使用したシステム資格証明のセキュアな格納とアクセス
キーストア・サービスを使用したキーと証明書のセキュアな格納とアクセス
監査中
ロール管理とロール・マッピング
ユーザーとロールのAPI
ID仮想化
セキュリティの構成と管理
SAMLとXACML
Oracle Security Developer Tools(暗号化ツールなど)
ポリシー管理API
Java Authorization for Containers (JAAC)
OPSSの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』のOracle Platform Security Servicesの概要に関する項を参照してください。
OPSSフレームワークを使用することで、Oracle B2Bではユーザーとグループ、資格証明、ID認証と認可、ポリシー、キーストアおよび監査のセキュリティ・オプションが提供されます。
詳細は、次の各項を参照してください。
Oracle Fusion Middleware Controlコンソールを使用して、Oracle B2Bのユーザーとグループを作成、編集、表示および変更できます。Fusion Middleware Controlコンソールには、次のURLからアクセスできます。
http://<hostname>:<port>/console
hostnameは、Oracle Weblogic Serverが実行されているコンピュータの名前で、ポート番号は、通常、7001です。
Fusion Middleware Controlにアクセスしてタスクを実行するには、適切なロールが必要です。Fusion Middleware Controlでは、Oracle WebLogic Serverセキュリティ・レルムとそのレルムで定義されたロールを使用します。ユーザーにそれらのロールのいずれかが付与されていないと、そのユーザーはFusion Middleware Controlにアクセスできません。
それぞれのロールでユーザーが持つアクセスのタイプを定義します。たとえば、ロールAdminを持つユーザーは完全な権限を持ちます。ロールMonitorを持つユーザーは、構成を表示する権限のみを持ちます。
ユーザーおよびグループの作成の詳細は、Oracle WebLogic Serverのロールとポリシーを使用したリソースの保護のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
資格証明には、ユーザー名、パスワードおよびチケットを格納できます。資格証明は暗号化できます。資格証明は、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。プリンシパルとは、ポリシー内の認可が付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。ほとんどの場合、アプリケーション・ロールを指定します。
Oracle B2Bは、OPSSの資格証明ストア・フレームワーク(CSF)を使用します。これは、アプリケーションで資格証明を安全に作成、読取り、更新および管理する際に使用できる一連のAPIです。資格証明ストアは、データベースやLDAPベースのリポジトリなどの外部システムにアクセスするためのユーザー名およびパスワードの格納に使用します。
資格証明の管理方法の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlでの資格証明の管理に関する項を参照してください。
Oracle B2Bは、OPSSのアイデンティティ・ガバナンス・フレームワーク(IGF)を使用して、すべてのユーザーおよびロールの認証と許可を実装します。これによって、古いユーザー/ロールAPIモデルが置き換えられます。
認証関連のエントリおよびユーザー・ロールの関連付けはすべて、OPSSポリシー・ストアに格納されます。OPSSポリシー・ストアはドメイン単位に管理されており、ドメインで実行される各アプリケーションは、ポリシー・ストア内で独自のスコープを持ちます。このスコープはアプリケーション・ストライプと呼ばれ、アプリケーションのすべてのポリシー・データはアプリケーション・ストライプで管理されます。
Oracle B2Bは、次の操作でIGFを使用します。
認証: LDAPユーザー・ストアに対してユーザーを認証します。
ユーザー詳細の取得: ユーザー名、部門、電話など、ユーザー・プロファイル/属性を取得します。
検索操作: ユーザー・ロールを検索します。
ロール操作: ロールを作成、削除および管理します。
Oracle B2Bは、リソースベースのモデルを使用して、認証と許可を管理します。リソースベースのモデルを使用することで、Oracle B2Bでは次のことが可能です。
管理者に、わかりやすくて管理可能なリソース定義およびポリシーが提供されます。
ポリシー、付与できるリソースおよびポリシーで付与されるリソースについて、ポリシー・ストアを詳細に問い合せることができます。
OPSS認証モデルを使用して認証を外部化するOracle製品全体に対して、単一の統一された認証管理コンソールが提供されます。
Oracle Identity Managementスイートの高度な認証ポリシー強制および管理機能を利用できます。
保護されるすべてのリソースは、リソースへの権限を付与する前に、リソース・カタログでリソース・タイプとともに定義する必要があります。各リソースは一意で、名前で表されます。リソース・タイプは、同じタイプのすべてのリソースを表すグループです。リソース・タイプは、一致するクラスとアクションのリストで定義されます。ただし、これによって認証の実行方法が変更されることはなく、認証に影響が及ぶこともありません。管理および監査の目的で、この方法をお薦めします。
リソース・カタログおよびOPSS認証モデルの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSポリシー・モデルに関する項を参照してください。
Oracle B2Bは、OPSSのサーバー認証プロバイダも使用します。これは、ユーザー名とパスワードの組合せまたはデジタル証明書に基づいて、ユーザーの資格証明またはシステム・プロセスを検証するコンポーネントです。認証プロバイダには、必要に応じ、ドメイン内の他のコンポーネントでサブジェクトを介してユーザー・アイデンティティ情報を使用できるようにする機能もあります。
認証プロバイダの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlでのサービス・プロバイダの構成に関する項を参照してください。
Fusion Middleware Controlでは、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、Oracle B2Bが実行されているWebLogicドメインで、システム・ポリシーおよびアプリケーション・ポリシーを管理できます。
Java 2ポリシーは、特定の場所からロードされた署名付きコードに付与されるパーミッションを指定します。
JAASポリシーは、オプションのプリンシパル・リストを指定できるようにすることで、Java 2の権限を拡張します。これにより、特定の場所からロードされた(場合によって署名付きの)コードが、指定のプリンシパルで表されるユーザーによって実行された場合にのみ、そのコードにパーミッションのセマンティックが付与されます。
アプリケーション・ポリシーは、Java 2ポリシーとJAASポリシーの集合です。Java 2ポリシーはJVM全体に適用されるのに対して、JAASポリシーは該当のアプリケーションにのみ適用されます。
ポリシー・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロール(管理ロールなど)には、アプリケーション固有のエンタープライズ・ユーザーおよびグループを指定できます。ポリシーでは、これらのグループまたはユーザーをプリンシパルとして使用できます。
ポリシー・ストアの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のポリシー・ストアの基本に関する項を参照してください。
Fusion Middleware Controlを使用して、Oracle B2Bに関するアプリケーション・ポリシー、アプリケーション・ロールおよびシステム・ポリシーを管理できます。
詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアプリケーション・ポリシーの管理に関する項、アプリケーション・ロールの管理に関する項およびシステム・ポリシーの管理に関する項を参照してください。
注意:
Oracle B2Bのアプリケーション・ポリシーおよびアプリケーション・ロールを構成する場合は、アプリケーション・ストライプとしてb2buiを選択してください。
Oracle B2Bでは、キーストア関連の操作で、Oracleキーストア・サービス(KSS)とともに、ファーム・キーストア・サービス(FKS)を主にサポートしています。
以前は、Oracle B2Bアプリケーションおよび他のJ2EEアプリケーションの、一元化されたキーストアはありませんでした。アプリケーションごとに独自のキーストアを作成および管理しており、システム・プロパティを使用して関連するキーストアを検索しました。キーストアのストレージに関する標準やガイドラインもなかったため、いくつものキーストア・ファイルがファイル・システム全体にちらばっていました。セキュリティ管理者が、アプリケーション全体にわたって鍵の強度やアルゴリズムなどの共通ポリシーを確認するのは困難でした。信頼管理の問題もありました。複数のトラストストアがあるということは、同じドメイン内のアプリケーションであっても、お互いを必ずしも信頼していないことを意味します。
KSSによって、関係するすべてのエンティティ(Java EEアプリケーション、WLS、OVD、システム・コンポーネント)がファーム全体で使用できる、単一のキーストアのストレージが提供されます。キーストアは単一のリポジトリに格納されるため、バックアップ、エクスポート/インポートおよび移行が簡単です。このキーストア・リポジトリへのアクセスは、標準のJDKキーストア・インタフェースを通じて行われるため、キーストアのタイプを切り替える際も、アプリケーションは多くの変更を必要としません。フレームワークは、一般的なトラストストアもサポートして、簡単な信頼管理を提供します。ステージング環境で証明書に署名する、ルートレベルの認証局があります。
KSSの主な機能は次のとおりです。
ドメイン全体の共通トラストストアを提供して、信頼を集中管理します。
ハードウェア・デバイス内でのセキュア・キーの生成および格納をサポートします。
コードベースの権限を使用して、キーと証明書へのセキュアなアクセスを提供します。
コードベースのセキュリティに加えて、さらにパスワードベースのセキュリティが必要な場合は、キー・パスワードおよびキーストア・パスワードをサポートします。
個々のストライプ(システムおよびアプリケーション)内でキーストアを管理します。
Fusion Middleware ControlおよびWeblogic Scripting Tool (WLST)を介して管理サポートを提供します。
キーストアに対してLDAPおよびデータベース・ベースのプロバイダをサポートします。
Oracle B2Bは、KSSを使用して、HTTP、FTP、AS2およびSMTP交換用の、次のようなトランスポート・プロトコルベースのセキュリティを提供します。
デジタル・エンベロープおよびデジタル証明書
デジタル署名(ホストおよびリモート取引パートナ用)
KSSとの統合(すべてのパスワードとセキュリティ資格証明の格納用)
SHTTP (Secure Sockets Layer (SSL)を使用)
暗号化キー・ストア・パスワード(ホスト取引パートナ用)
KSSフレームワークには、システム・レベルで使用できる1つのトラストストア・ファイル(trust.jks)があります。このファイルは、別のものが特に指定されないかぎり、デフォルトでは、すべてのアプリケーション(Oracle B2Bなど)で、信頼できる証明書を格納するために使用されます。たとえば、アプリケーションAは、そのコンテキストに格納されるファイルを指定してトラストストア(たとえば、app2.jks)として使用することも、共通のドメイン・レベルのトラストストア(trust.jks)を使用することもできます。
アプリケーション・ストライプおよびキーストアは、WLSTコマンドまたはFusion Middleware Controlコンソールを使用して管理されます。アプリケーション・ストライプ内のキーストアにアクセスするには、アプリケーション・ストライプ全体または特定のキーストアにおけるKeyStoreAccess権限が必要です。これは、WLSTまたはFusion Middleware Control (System-jazn-data.xml)を介して、認証ポリシー内に定義できます。
注意:
B2BのストライプはB2Bである必要があります。デフォルトでは、このストライプはKSSで使用できません。最初にストライプを作成してから、このストライプで対応するキーストアを作成する必要があります。
このストライプは、kss://<keystore-stripe>/<keystore-name>の形式で作成して使用してください。
B2Bストライプにおけるすべてのキーストロークは必要な使用権限とともに提供されるため、これを使用してください。B2Bの場合、URIは通常、kss://B2B/Acmeのような形式です。
別のストライプを使用する場合は、キーストアを作成する際に、図18-1および以降の説明で示すように、追加のステップを実行して、コード・ソース権限を指定する必要があります。
次の項目を指定する必要があります。
権限の付与: チェック・ボックスの選択
コード・ベースURL: $MW_HOME/soa/modules/oracle.soa.b2b_11.1.1/b2b.jar (b2b.jarの絶対パスまたは相対パス)
キーストアの場所がすでに存在する場合は、システム・ポリシーを構成して、システム・ポリシー内に必要な権限を設定する必要があります(OPSSでシステム・ポリシーの章を参照)。
詳細は、『Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスを使用したキーと証明書の管理に関する項を参照してください。別のストライプの使用については、同じドキュメントのキーストア・サービスを使用した開発に関する項を参照してください。
FKSでは、次のサービスが提供されます。
プロバイダ・タイプのサポート
キーストア・タイプのサポート
ガバナンス・ポリシーのサポート
証明書の有効期限のサポート
プロバイダ・タイプ
KSSでは、他のOPSSサービスと同様、プロバイダベースのアーキテクチャをサポートしています。デフォルトでは、これらのサービスの構成は、ファイルベースのプロバイダで使用できます。KSSでは、他のOPSSサービスでサポートされるように、LDAPベースのプロバイダもサポートしています。これらの構成パラメータは、$DOMAIN_HOME/config/fmwconfigにあるjps-config.xmlで設定する必要があります。
キーストア・タイプ
KSSで使用するキーストアのタイプを指定するパラメータは、jps-config.xmlファイルで設定する必要があります。これは、実行時プロバイダにとって必要です。
<property name=" kss.type" value=" KSS" />
ガバナンス・ポリシー
ガバナンス・ポリシーによって、KSSで使用できる証明書やキーなどのタイプが決定されます。たとえば、1024ビット以上のキーのみを許可する、MD5ハッシュ・アルゴリズムを許可しない、RSA署名アルゴリズムのみを許可する、またはキーの有効性を現在から2年以上にするというルールを、管理者は定義できます。
これらのパラメータはすべて、jps-config.xmlで次のように構成できます。
<property name=" kss.min.keysize" value=" 1024" /> <property name=" kss.disallowed.algorithms.hashing" value=" MD5" /> <property name=" kss.disallowed.algorithms.signing" value=" DSA" /> <property name=" kss.allowed.keyusage" value=" digsig,crlsign" />
証明書の有効期限
KSSには、証明書の有効期限のアラートを管理するポリシーを構成するためのメカニズムがあります。これはユーザー・メッセージング・サービス(UMS)と統合されており、通知およびアラートを提供します。
ポリシー: KSSによって管理者は、証明書の有効期限が切れる、指定の日数前に、アラートを送信する必要があることを構成できます。これは、jps-config.xmlで次のように構成できます。
<property name=" kss.daysbefore.cert.expiration" value=" 60" />
アラート: KSSによって管理者は、証明書の有効期限に関するアラートおよび通知を管理するチャネルを構成できます。デフォルトでは、警告メッセージをログ・ファイルに記録するようにチャネルが構成されています。管理者は、電子メールやSMSなどを通じて、さらにアラートを構成できます。Oracle B2Bでは、UMSでサポートされるアラート・メカニズムをサポートしています。KSSに対して複数のチャネルを構成でき、アラートの送信に使用するチャネルを複数指定できます。これは、jps-config.xmlで次のように構成できます。
<property name=" kss.channel.log" value=" /tmp/alert.log" /> <property name=" kss.channel.email" value=" admin@foo.com,smtp.foo.com" /> <property name=" kss.channel.cell" value=" 16505067000,mobilegateway.foo.com" /> <property name=" kss.alert.channel" value=" kss.channel.log, kss. channel.email" />
KSSを使用して、次のキーストア・サービス操作を実行できます。
キーストアの作成
キーストアの削除
キーストアの更新
キーストア・パスワードの変更
キー・パスワードの変更
キーストアのエクスポート
キーストアのインポート
キーストアの移行(移入)
キーストアの移行(移出)
証明書の検証
証明書のマージ
KSSキーストアの場合、次の命名規則に従います。
256文字を超える名前は使用しないでください。
キーストア名には、次のいずれの文字も使用しないでください。
| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ space tab
キーストア名には、ASCII以外の文字は使用しないでください。
また、ディレクトリ名およびファイル名に関するオペレーティング・システム固有のルールにも従ってください。
Oracle B2BのKSSキーストアは、Fusion Middleware ControlコンソールまたはWLSTコマンドを使用して設定できます。
Fusion Middleware Controlコンソールを使用したキーストアの設定
キーストアの設定の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlでのキーストアの管理に関する項を参照してください。
WLSTを使用したキーストアの設定
WLSTコマンドを使用してOracle B2Bのキーストアを設定するには、次の手順を実行します。
Oracle Weblogic Server (管理サーバーおよび管理対象サーバー)を起動します。
コンソール・ウィンドウで、次のコマンドを実行します。
cd $FMW_HOME/oracle_common/common/bin
./wlst.sh
このコマンドにより、WLST環境が設定されます。
connect("<Admin user>","<Admin user password>","t3://localhost:<Admin server port>")
このコマンドにより、オンライン・サーバーに接続されます。
svc = getOpssService(name='KeyStoreService')
このコマンドにより、すべてのキーストア・サービスが初期化され、取得されます。
svc.createKeyStore(appStripe='<StripeName>', name='<Keystorename>', password='<keystorePassword_Optional>', permission=true/false)
このコマンドにより、キーストアが作成されます。例:
svc.createKeyStore(appStripe='B2B', name='B2BKeyStore', password='weblogic1', permission=false)
svc.generateKeyPair(appStripe='<StripeName>', name='<Keystorename>', password='<keystorePassword_Optional>', dn='cn=www.abc.com', keysize='1024', alias='<keyAlias>', keypassword='<KeyPassword>')
このコマンドにより、秘密鍵/公開鍵のペアが、<StripeName>ストライプの<Keystorename>ストアに、キーの別名<keyAlias>で生成されます。
例:
svc.generateKeyPair(appStripe='B2B', name='B2BKeyStore', password='<keystorePassword_Optional>', dn='cn=www.abc.com', keysize='1024', alias='Acme', keypassword='<KeyPassword>')
注意:
b2b.jarのコード・ソースに対する権限は、ストライプB2Bの下のキーストアに対してのみ適用されます。デフォルトでは、Oracle B2Bには、Oracle B2Bにおけるすべてのストライプに対するコード・ソース権限がプロビジョニングされています。
Oracle B2Bコンソールでは、図18-2に示すように、ホスト取引パートナの「プロファイル」タブで、「パスワード」や場所/名前など、キーストア資格証明を指定できます。
JREにトラストストアが指定されている場合は、B2Bはそのトラストストアを使用してTLS接続を確立します。したがって、WLSとともにインストールされたデフォルトの.jksファイルを使用するか.WLS起動スクリプトの-Djavax.net.ssl.trustStoreパラメータで指定した.jksファイルを使用するかを選択できます。b2b.httpsTrustStoreサーバー・プロパティがtrueに設定されているか、Fusion Application環境で実行されている場合は、B2Bはデフォルトの.jksファイルを使用してhttpsデリバリ・チャネルを送信します。
注意:
キーストア資格証明が指定されない場合は、デフォルトのKSS Weblogicキーストアが使用されます。
