この章では、Oracle Virtual Assembly Builderのセキュリティについて説明します。内容は次のとおりです。
表3-1で説明するリソースは保護されます。
表3-1 リソース
リソース | 保護の方法 |
---|---|
ターゲット |
Oracle VMの場合、ターゲットは、CloudAdminによって作成されます。 Oracle VMの場合、CloudAdminがApplicationAdminsにターゲットを使用するための権限を付与します。Oracle VMでは、CloudAdminがOracle VM Managerに共有資格証明を提供します。 CloudAdminのみがターゲットの構成情報を表示できます。 |
資格証明(パスワードおよび鍵) |
暗号化 |
デプロイヤのアセンブリ・アーカイブ |
「所有者」概念によって保護されます。詳細は、第3.3.2項「アセンブリ・アーカイブ認可」を参照してください。 |
デプロイヤのアセンブリ・インスタンスとデプロイメント・プラン |
「所有者」概念によって保護されます。詳細は、第3.3.2項「アセンブリ・アーカイブ認可」を参照してください。 |
Oracle Virtual Assembly Builderでは、セキュリティ・ロールおよびグループを定義します。組込みLDAPの場合は、製品インストーラがロールおよびグループを設定します。ユーザーはOracle WebLogic Server管理コンソールでユーザーを作成してグループに追加します。
次のプロセスに従ってロールおよびグループを作成します。
『Oracle® Fusion Middleware Oracle WebLogic Serverの保護』の手順を使用して、外部LDAPサーバーでOracle WebLogic Serverを構成します。
"CloudAdmins"および"ApplicationAdmins"というグループは、インストール時に自動的に作成されます。LDAPサーバーで定義したユーザーをこれらのグループに追加します。
ロール式Grp(GroupName|GroupName|GroupName)
を使用して、グループをセキュリティ・ロールに入れます。
Oracle WebLogic Serverにおけるロールの計算および付与のプロセスは、ロール・マッピングと呼ばれます。アクセス決定は、サブジェクトがWebLogicリソースに対して特定の操作を実行する権限を持っているかどうかを判別する認可プロバイダによって実行される操作です。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のアクセス決定に関する項を参照してください。
ApplicationAdmins
グループはインストール時に自動的に作成されます。
LDAPでApplicationAdmin
ユーザー帯域外を作成します。このグループのメンバーをApplicationAdmins
グループに含めます。
CloudAdmins
グループはインストール時に自動的に作成されます。
LDAPでCloudAdmin
ユーザー帯域外を作成します。CloudAdmins
グループにユーザーを含めます。これにより、CloudAdmin
ロールがログイン時に割り当てられます。
web.xmlのauth-constraintとweblogic.xmlのCloudAdmin
ロールに対するCloudAdmins
グループのsecurity-role-assignmentごとに、CloudAdmin
ロールを作成します。
Oracle Virtual Assembly Builder Deployerは、Oracle WebLogic Serverコンテナ内で実行されるアプリケーションとして構築されており、Oracle WebLogic Serverによって提供されるセキュリティ・インフラストラクチャを利用します。Oracle WebLogic Serverは、デフォルトでは組込みLDAPオーセンティケータで構成されていますが、外部企業LDAPを指すようにOracle WebLogic Serverを再構成できます。デプロイヤは、CloudAdminsとApplicationAdminsの2つのグループの一方、または両方に属するOracle WebLogic Serverユーザーに依存します。
CloudAdminとApplicationAdminのグループおよびロールの作成の詳細は、3.2項「ロールとグループ」を参照してください。
これらのグループでユーザーを保有すると、ユーザーをマップしてデプロイヤで必要なロール(CloudAdminまたはApplicationAdmin)を保有することができます。デプロイヤのアクセス制御では、ユーザーがこれらのグループの一方または両方に属している必要があります。abctl
を使用してデプロイヤへの接続を設定するときに、これらのグループの一方または両方に追加されているOracle Weblogic Serverユーザーのユーザー名およびパスワードを指定する必要があります。
Oracle Virtual Assembly Builder Studioまたはabctl
のいずれかを使用してユーザーがデプロイヤ操作を試行すると、ユーザーは接続情報を使用して認証されます。認証されると、ユーザーのリクエストはWLSサーブレット・コンテナ内で実行されているデプロイヤのサーブレットに移動します。サーブレットでは、これらのロールのいずれかにユーザーが属することをチェックし、追加チェック(ユーザーが指定ターゲットへのアクセスを許可されているかどうか、ユーザーが指定アセンブリ・アーカイブへのアクセスを許可されているかどうかなど)を実行します。
Oracle Virtual Assembly Builder Deployerではアクセス・チェックにOracle WebLogic Server機能を使用しますが、Oracle Virtual Assembly Builder Deployerにはそのアイデンティティの管理に関するLDAP情報を表示できません。このような状況により、Oracle Virtual Assembly Builder構成がまだ所定の場所にあるそのユーザー名を参照している間に、Oracle WebLogic Serverからユーザーを削除する可能性があります。
注意: Oracle Virtual Assembly Builderリクエストが前述の認証およびアクセス・チェックを越えて移動してしまうと、ユーザー情報がWebLogic Server認証ストアから削除されても、リクエストは完了するまで続行します。 |
Oracle VMの場合、ターゲットの作成、ターゲットの構成情報の表示などの機能を実行できるのはCloudAdminのみです。Oracle VMの場合、CloudAdminがApplicationAdminsにターゲットを使用するための権限を付与します。
Oracle VMでは、CloudAdminがOracle VM Managerに共有資格証明を提供します。
注意: Oracle WebLogic Server認証ストアからユーザーを削除する場合、以前に追加したすべてのターゲットからそのユーザーを削除して( デプロイヤのターゲットからユーザーを削除すると、デプロイヤからそのユーザーに関するキャッシュ済情報がすべて削除されます。これにより、キャッシュ済情報があるユーザーがOracle WebLogic Serverから削除され、同じ名前の別のユーザーがOracle WebLogic Serverに追加され、新しいユーザーが前のユーザーのデプロイヤ内のキャッシュ済情報をすべて継承するという状況が回避されます。 |
ユーザーがアセンブリ・アーカイブにアクセスしようとすると、デプロイヤがチェックを実行します。アクセス権を付与されるのは次のユーザーです。
CloudAdminロールのユーザー。
アセンブリ・アーカイブの所有者。アセンブリ・アーカイブはアセンブリ・バージョンと1対1で対応しますが、アセンブリには複数のアセンブリ・バージョンが存在する場合があります。アセンブリの最初のアセンブリ・アーカイブ(バージョン1.0)をアップロードするユーザーがそのアセンブリを所有します。
追加のユーザーにはアセンブリへのアクセス権を付与できます。
addAssemblyUsers
コマンドを使用して、追加ユーザーを認可してアクセス・リストに追加できます。この操作を実行できるのは、CloudAdminロールのユーザーか、アセンブリ・アーカイブの所有者のみです。
アセンブリ・アーカイブの所有者であるApplicationAdminのみが、アセンブリ・ユーザーの追加/削除/説明を行ったり、アセンブリを削除したり、アセンブリ・アーカイブを更新することで、これを管理できます。アセンブリ・アクセス・リストにあるユーザーは、アセンブリ・インスタンスを表示、ダウンロード、登録、作成することでアセンブリを使用できます(ターゲットへのアクセス権もあると想定した場合)。
アセンブリ・インスタンスを作成したユーザーがその所有者です。CloudAdmins以外でアセンブリ・インスタンスを管理および使用できるのは、アセンブリ・インスタンスの所有者のみです。
uploadAssemblyResources
コマンドはセキュリティ・ポリシーによって制御されます。リソース・ファイルにはスクリプトが含まれる場合と含まれない場合があります。リスース・ファイルにスクリプトが含まれていない場合は、アセンブリ・アクセス・リスト上のユーザーがコマンドを実行できます。リスース・ファイルにスクリプトが含まれている場合は、悪意のある攻撃を防止するために、コマンドを実行できるのはCloudAdminユーザーのみになります。
リソース・ファイルにスクリプトが含まれる場合、サポートされるライフサイクル名は、pre-deploy
、post-deploy
、deployer-pre-app-config
、deployer-post-app-config
、deployer-pre-vm-start
、deployer-post-vm-start
、deployer-pre-vm-stop
、deployer-post-vm-stop
、pre-undeploy
、post-undeploy
になります。対応するスクリプト・フォルダ名を作成できます。
デプロイヤの認証および認可モデルを有効にするには、次の手順を実行します。
システム管理者は、LDAPでユーザーを定義し、CloudAdmin
またはApplicationAdmin
ロールをそれらのユーザーに割り当てます。これらのロールは、指定されたユーザーが実行できる事柄を制御します。このステップは、Oracle WebLogic Server管理コンソールを使用して実行します。
Webサービスに対して残りの操作を実行します。Webサービス・コールにはOracle Virtual Assembly Builderユーザー資格証明が必要です。コールする必要があるデプロイヤWebサービス操作は、次のとおりです。
createTarget
- この操作は、CloudAdminによってのみ実行できますが、接続情報と、バックエンド・タイプに応じてバックエンドのユーザー資格証明を定義します。Oracle VMの場合、ここで資格証明を指定します。
addTargetUser
- バックエンド・システムのセキュリティ・モデルにおける相違のため、バックエンド・タイプに応じて、これはCloudAdminコールまたはApplicationAdminコールになります。
Oracle VMターゲットの場合、この操作はCloudAdminによってのみ実行でき、プールにアクセスできるユーザーの制御に使用されます。CloudAdminによって指定される資格証明は一般ユーザーから保護する必要があるため、これはCloudAdmin操作です。
uploadAssemblyArchive
- このコールは、CloudAdminまたはApplicationAdminユーザーによって行われます。アーカイブをアップロードする最初のユーザーは、アーカイブの所有者です。アーカイブの所有者またはaddAssemblyUser
コマンドを使用して追加されたユーザーのみが、アーカイブの新しいバージョンをアップロードでき、アーカイブに基づいてアセンブリ・インスタンスを作成できます。
セキュリティの構成に関する手順は、第5.4.2項「ターゲットの構成」を参照してください。