この章では、Oracle Virtual Assembly Builderのセキュリティについて説明します。内容は次のとおりです。
表3-1で説明するリソースは保護されます。
表3-1 リソース
リソース | 保護の方法 |
---|---|
ターゲット |
Oracle VMの場合、ターゲットは、Cloud Adminによって作成されます。Oracle Exalogicの場合、インストール時に1つのターゲットが暗黙的に構成され、インストール後に新しいターゲットは作成できません。 Oracle VMの場合、Cloud AdminがApplication Adminにターゲットを使用するための権限を付与します。Oracle Exalogicの場合、どのCloud Adminも構成済ターゲットを使用できますが、固有の資格証明情報を仮想化システムに指定する必要があります。 この違いの理由は、Oracle VMでは、Cloud AdminがOracle VM Managerに共有資格証明を指定するためです。Oracle Exalogicの場合、暗黙的に構成された1つのターゲットにのみターゲットURLが含まれます。 Cloud Adminのみがターゲットの構成情報を表示できます。 |
資格証明(パスワードおよび鍵) |
暗号化 |
デプロイヤのアセンブリ・アーカイブ |
「所有者」概念によって保護されます。詳細は、3.2.2項「アセンブリ・アーカイブ認可」を参照してください。 |
デプロイヤのアセンブリ・インスタンスとデプロイメント・プラン |
「所有者」概念によって保護されます。詳細は、3.2.2項「アセンブリ・アーカイブ認可」を参照してください。 |
Oracle Virtual Assembly Builder Deployerは、Oracle WebLogic Serverコンテナ内で実行されるアプリケーションとして構築されており、Oracle WebLogic Serverによって提供されるセキュリティ・インフラストラクチャを利用します。Oracle WebLogic Serverは、デフォルトでは組込みLDAPオーセンティケータで構成されていますが、外部企業LDAPを指すようにOracle WebLogic Serverを再構成できます。デプロイヤは、Cloud AdminとApplication Adminの2つのグループの一方、または両方に属するOracle WebLogic Serverユーザーに依存します。
Cloud AdminとApplication Adminのグループおよびロールの作成の詳細は、3.3項「ロールとグループ」を参照してください。
これらのグループでユーザーを保有すると、ユーザーをマップしてデプロイヤで必要なロール(Cloud AdminまたはApplication Admin)を保有することができます。デプロイヤのアクセス制御では、ユーザーがこれらのグループの一方または両方に属している必要があります。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の場合、ターゲットの作成、ターゲットの構成情報の表示などの機能を実行できるのはCloud Adminのみです。Oracle VMの場合、Cloud AdminがApplication Adminにターゲットを使用するための権限を付与します。
Oracle Exalogicの場合、どのCloud Adminも構成済ターゲットを使用できますが、固有の資格証明情報を仮想化システムに指定する必要があります。Oracle VMでは、Cloud AdminがOracle VM Managerに共有資格証明を提供します。
注意: Oracle WebLogic Server認証ストアからユーザーを削除する場合、以前に追加したすべてのターゲットからそのユーザーを削除して( デプロイヤのターゲットからユーザーを削除すると、デプロイヤからそのユーザーに関するキャッシュ済情報がすべて削除されます。これにより、キャッシュ済情報があるユーザーがOracle WebLogic Serverから削除され、同じ名前の別のユーザーがOracle WebLogic Serverに追加され、新しいユーザーが前のユーザーのデプロイヤ内のキャッシュ済情報をすべて継承するという状況が回避されます。 |
ユーザーがアセンブリ・アーカイブにアクセスしようとすると、デプロイヤがチェックを実行します。アクセス権を付与されるのは次のユーザーです。
OVAB_ADMINロールを持つユーザー。
アセンブリ・アーカイブの所有者。アセンブリ・アーカイブを最初にアップロードするユーザーが所有者になります。
addAssemblyUsers
コマンドを使用して、追加ユーザーを認可してアクセス・リストに追加できます。この操作を実行できるのは、OVAB_ADMINロールを持つユーザーか、アセンブリ・アーカイブの所有者のみです。
アセンブリ・アーカイブの所有者であるApplication Adminのみが、アセンブリ・ユーザーの追加/削除/説明を行ったり、アセンブリを削除したり、アセンブリ・アーカイブを更新することで、これを管理できます。アセンブリ・アクセス・リストにあるユーザーは、アセンブリ・インスタンスを表示、ダウンロード、登録、作成することでアセンブリを使用できます(ターゲットへのアクセス権もあると想定した場合)。
アセンブリ・インスタンスを作成したユーザーがその所有者です。Cloud Admins以外でアセンブリ・インスタンスを管理および使用できるのは、アセンブリ・インスタンスの所有者のみです。
uploadAssemblyResources
コマンドはセキュリティ・ポリシーによって制御されます。リソース・ファイルにはスクリプトが含まれる場合と含まれない場合があります。リスース・ファイルにスクリプトが含まれていない場合は、アセンブリ・アクセス・リスト上のユーザーがコマンドを実行できます。リソース・ファイルにスクリプトが含まれている場合は、悪意のある攻撃を防止するために、コマンドを実行できるのはCloud Adminユーザーのみになります。
リソース・ファイルにスクリプトが含まれる場合、サポートされるライフサイクル名は、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でユーザーを定義し、Cloud Admin
またはApplication Admin
ロールをそれらのユーザーに割り当てます。これらのロールは、指定されたユーザーが実行できる事柄を制御します。このステップは、Oracle WebLogic Server管理コンソールを使用して実行します。
Webサービスに対して残りの操作を実行します。Webサービス・コールにはOracle Virtual Assembly Builderユーザー資格証明が必要です。コールする必要があるデプロイヤWebサービス操作は、次のとおりです。
createTarget
- この操作は、Cloud Adminによってのみ実行できますが、接続情報と、バックエンド・タイプに応じてバックエンドのユーザー資格証明を定義します。Oracle VMの場合はここで資格証明を指定しますが、Oracle Exalogicの場合は個々のユーザーがaddTargetUser
ステップで各自の資格証明を指定します。
addTargetUser
- バックエンド・システムのセキュリティ・モデルにおける相違のため、バックエンド・タイプに応じて、これはCloud AdminコールまたはApplication Adminコールになります。
Oracle VMターゲットの場合、この操作はCloud Adminによってのみ実行でき、プールにアクセスできるユーザーの制御に使用されます。Cloud Adminによって指定される資格証明は一般ユーザーから保護する必要があるため、これはCloud Admin操作です。
Oracle Exalogicターゲットの場合、これはユーザー操作で、ユーザー資格証明の指定に使用されます(この場合、バックエンドで資格証明をチェックするため、Cloud Adminは特定のアクセス権を付与する必要がありません)。ユーザーの資格証明はCloud Adminを含め他のユーザーから保護する必要があるため、これはApplication Admin操作です。
uploadAssemblyArchive
- これは、アセンブリ・アーカイブをOracle Virtual Assembly Builder Deployerにアップロードするのに使用されるCloud Adminコールです(admin以外のユーザーはアセンブリ・アーカイブをアップロードできません)。
セキュリティの構成に関する手順は、第5.4.1項「ターゲットの構成」を参照してください。
Oracle Virtual Assembly Builderでは、セキュリティ・ロールおよびグループを定義します。組込みLDAPの場合は、製品インストーラがロールおよびグループを設定します。ユーザーはOracle WebLogic Serveコンソールからユーザーを作成してグループに追加します。
次のプロセスに従ってロールおよびグループを作成します。
外部LDAP用にOracle WebLogic Serverを構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の手順を使用します。
LDAPサーバーで「Cloud Admins」と「Application Admins」のグループを作成します。
LDAPサーバーで定義したユーザーをこれらのグループに追加します。
ロール式Grp(GroupName|GroupName|GroupName)
を使用して、グループをセキュリティ・ロールに入れます。
Oracle WebLogic Serverにおけるロールの計算および付与のプロセスは、ロール・マッピングと呼ばれます。アクセス決定は、サブジェクトがWebLogicリソースに対して特定の操作を実行する権限を持っているかどうかを判別する認可プロバイダのコンポーネントです。(『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のアクセス決定に関する項を参照してください)。
LDAPでApplication Admins
グループ帯域外を作成します。
LDAPでApplication Admin
ユーザー帯域外を作成します。このグループのメンバーをApplication Admin
グループに含めます。
LDAPでCloud Admins
グループ帯域外を作成します。
LDAPでCloud Admin
ユーザー帯域外を作成します。Cloud Admins
グループにユーザーを含めます。これにより、Cloud Admin
ロールがログイン時に割り当てられます。
web.xmlのauth-constraintとweblogic.xmlのCloud Admin
ロールに対するCloud Admins
グループのsecurity-role-assignmentごとに、Cloud Admin
ロールを作成します。