ポリシーの仕組み

たとえば、管理者がユーザーとその資格証明を管理するHelpDeskというグループを作成するとします。これを可能にするポリシーを示します。

Allow group HelpDesk to manage users in tenancy

ユーザーはテナンシ(ルート・コンパートメント)に存在するため、ポリシーではtenancyという語のみを示し、先頭にcompartmentという語は示されていません。

次に、Project-Aというコンパートメントと、コンパートメント内のすべてのOracle Cloud Infrastructureリソースを管理するA-Adminsというグループがあるとします。これを可能にするポリシーの例を示します。

Allow group A-Admins to manage all-resources in compartment Project-A

前述のポリシーには、そのコンパートメントのポリシーを書き込む機能が含まれています。つまり、A-Adminsはコンパートメントのリソースへのアクセスを制御できます。詳細は、ポリシー・アタッチメントを参照してください。

Project-Aコンパートメント内のコンピュート・インスタンスおよびブロック・ストレージ・ボリューム(ボリュームとそのバックアップの両方)の起動および管理のみにA-Adminsのアクセスを制限し、ネットワーク自体はNetworksコンパートメントに配置している場合、ポリシーは次のようになります。

Allow group A-Admins to manage instance-family in compartment Project-A

Allow group A-Admins to manage volume-family in compartment Project-A

Allow group A-Admins to use virtual-network-family in compartment Networks

virtual-network-familyリソース・タイプを使用した3番目のステートメントでは、クラウド・ネットワークが関係するため、インスタンスの起動プロセスが有効になります。特に、起動プロセスは新しいVNICを作成し、それをインスタンスが存在するサブネットにアタッチします。

その他の例については、共通ポリシーを参照してください。

通常は、グループまたはコンパートメントをポリシーに名前で指定します。ただし、OCIDを使用することもできます。OCIDの前に必ずidを追加してください。例:

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

カンマで区切られた複数のグループを指定できます。

Allow group A-Admins, B-Admins to manage instance-family in compartment Projects-A-and-B

Oracleでは、ポリシーで使用できる動詞を定義します。次に、アクセスの低い順に動詞の概要を示します。

動詞は、特定の一般的なアクセスのタイプ(たとえば、inspectを指定すると、リソースをリストして取得できます)を提供します。次に、そのアクセスのタイプをポリシー内の特定のリソース・タイプと結合する場合(Allow group XYZ to inspect compartments in the tenancyなど)、そのグループに特定のセットの権限およびAPI操作(ListCompartments、GetCompartmentなど)のアクセス権限を付与します。詳細な例は、動詞とリソース・タイプの組合せの詳細を参照してください。各サービスには、動詞とリソース・タイプの各組合せでカバーされるAPI操作のリストの詳細が示されます。

特定のリソース・タイプに対するいくつかの特別な例外や微妙な違い。

ユーザー: manage usersとmanage groupsの両方へのアクセス権によって、ユーザーおよびグループの作成および削除、グループに対するユーザーの追加/削除など、ユーザーおよびグループに対してあらゆる操作を実行できます。ユーザーとグループの作成および削除のためのアクセス権なしでグループのユーザーを追加/削除するには、use usersとuse groupsの両方のみが必要です。共通ポリシーを参照してください。

ポリシー:ポリシーの更新は新規ポリシーの作成と同様であるため、ポリシーを更新する機能は、use policiesではなくmanage policiesでのみ使用可能です(既存のポリシー・ステートメントは上書きできます)。また、inspect policiesを使用すると、ポリシーの全コンテンツを取得できます。

オブジェクト・ストレージ・オブジェクト:inspect objectsによって、バケット内のすべてのオブジェクトをリストし、特定のオブジェクトに対してヘッド操作を実行できます。また、read objectsでは、オブジェクト自体をダウンロードできます。

Load Balancerリソース:inspect load-balancersによって、ロード・バランサや関連コンポーネント(バックエンド・セットなど)に関するすべての情報を取得できます。

ネットワーキング・リソース:

Oracleは、ポリシーで使用できるリソース・タイプも定義します。最初に、個別のタイプがあります。個々のタイプは特定のタイプのリソースを表します。たとえば、vcnsリソース・タイプは、仮想クラウド・ネットワーク(VCN)専用です。

ポリシーの書込みを簡単にするために、頻繁に管理される複数の個別のリソース・タイプを含むファミリ・タイプがあります。たとえば、virtual-network-familyタイプは、VCNの管理に関連する様々なタイプを統合します(vcns、subnets、route-tables、security-listsなど)。個々のリソース・タイプのみにアクセスできるより詳細なポリシーを作成する必要がある場合は、実行できます。しかし、より幅広いリソースにアクセスできるようにポリシーを簡単に作成することもできます。

別の例として、ブロック・ボリュームにはvolumes、volume-attachmentsおよびvolume-backupsがあります。ボリュームのバックアップを作成するのみのアクセス権を付与する必要がある場合は、ポリシーにvolume-backupsリソース・タイプを指定できます。ただし、すべてのブロック・ボリューム・リソースに幅広いアクセス権限を付与する必要がある場合は、volume-familyというファミリ・タイプを指定できます。ファミリ・リソース・タイプの完全なリストは、リソース・タイプを参照してください。

アクセス権が付与される条件を指定する機能など、ポリシーをより細かくするには、他の方法もあります。詳細は、高度なポリシーの機能を参照してください。

一部のAPI操作では、複数のリソース・タイプにアクセスする必要があります。たとえば、LaunchInstanceでは、インスタンスを作成し、クラウド・ネットワークを使用する機能が必要です。CreateVolumeBackup操作では、ボリュームとボリューム・バックアップの両方にアクセスする必要があります。つまり、各リソース・タイプにアクセスできるように別々のステートメントが用意されています(例は、ボリューム・バックアップ管理者によるバックアップのみの管理を参照してください)。これらの個々のステートメントは、同じポリシー内である必要はありません。また、ユーザーは、異なるグループから必要なアクセス権を取得できます。たとえば、Georgeは、volumesリソース・タイプに必要なアクセス・レベルを付与するグループと、volume-backupsリソース・タイプに必要なアクセス権を付与する別のグループに配置できます。個々のステートメントをまとめると、ポリシー・セット全体の場所に関係なく、GeorgeにCreateVolumeBackupへのアクセス権が与えられます。

ポリシーの基本機能は継承という概念です。コンパートメントは親コンパートメントからポリシーを継承します。最も単純な例は、テナンシに自動的に付属する管理者グループです(管理者グループおよびポリシーを参照)。管理者グループがテナンシ内の操作を実行できるようにする組込みポリシーがあります。

Allow group Administrators to manage all-resources in tenancy

ポリシー継承のため、管理者グループはテナンシのどのコンパートメントでもすべての操作を実行できます。

さらに、CompartmentA、CompartmentBおよびComparmentCの3つのコンパートメント・レベルを持つテナンシを考えてみます。次に例を示します。

CompartmentAのリソースに適用されるポリシーは、CompartmentBおよびCompartmentCのリソースにも適用されます。したがって、次のポリシーでは:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA

グループNetworkAdminsがCompartmentA、CompartmentBおよびCompartmentCのVCNを管理できます。

ポリシーの別の基本機能として、アタッチメントの概念があります。ポリシーを作成する場合、それをコンパートメント(またはルート・コンパートメントであるテナンシ)にアタッチする必要があります。アタッチされた先の対象によって、だれが次に変更または削除できるか、が制御されます。これをテナンシにアタッチする場合(つまり、ポリシーがルート・コンパートメント内にある場合)、テナンシのポリシーを管理するアクセス権を持つユーザーは、ポリシーを変更または削除できます。通常は、管理者グループまたはユーザーが作成して幅広いアクセス権を付与する類似グループです。子コンパートメントへのアクセス権のみを持つユーザーは、そのポリシーを変更または削除できません。

かわりに子コンパートメントにポリシーをアタッチすると、そのコンパートメント内のポリシーを管理するアクセス権を持つユーザーはポリシーを変更または削除できます。実際的な観点から、これは、テナンシに存在するポリシーを管理するためのより広範囲のアクセス権を付与する必要がないため、コンパートメント管理者(コンパートメントのmanage all-resourcesへのアクセス権を持つグループ)に自身のコンパートメントのポリシーを管理するアクセス権を付与すると容易であることを意味します。この種類のコンパートメント管理者設計を使用する例は、シナリオ例を参照してください。(ポリシー継承により、テナンシ内のポリシーを管理するアクセス権を持つユーザーは、自動的にテナンシ内のコンパートメントのポリシーを管理できることに注意してください。)

ポリシーをアタッチするプロセスは簡単です(コンパートメントまたはテナンシにアタッチするかに関係なく)。コンソールを使用していて、ポリシーをIAMに追加する場合、ポリシー作成時に必要なコンパートメントにいることを確認してください。APIを使用している場合は、ポリシーを作成するリクエストの一部として、必要なコンパートメント(テナンシまたは他のコンパートメント)のOCIDを指定します。

ポリシーをコンパートメントにアタッチする場合、そのコンパートメントにいる必要があり、かつ適用先のコンパートメントをステートメントで直接示している必要があります。コンパートメントにいない場合、ポリシーを別のコンパートメントにアタッチしようとするとエラーが表示されます。ポリシーの作成中にアタッチメントが発生します。つまり、ポリシーは1つのコンパートメントにのみアタッチできます。コンパートメントへのポリシーのアタッチ方法を学習するには、ポリシーを作成するにはを参照してください。

前の項で説明したように、ポリシー・ステートメントでは、アクセス権が付与されているコンパートメント(またはテナンシ)を指定する必要があります。ポリシーを作成する場所によって、ポリシーを更新できるユーザーが決まります。ポリシーをコンパートメントまたはその親にアタッチする場合、コンパートメント名を指定するだけです。ポリシーを階層のさらに上にアタッチする場合、パスを指定する必要があります。パスの書式は、パスの各コンパートメント名(またはOCID)で、コロンで区切られます。

<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>

たとえば、ここに示す3つのレベルのコンパートメント階層があるとします。

NetworkAdminsがCompartmentC内のVCNを管理できるようにするポリシーを作成する必要があるとします。このポリシーをCompartmentCまたはその親CompartmentBにアタッチする場合は、次のポリシー・ステートメントを記述します。

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentC

ただし、このポリシーをCompartmentAにアタッチする場合(CompartmentAの管理者のみが変更できるようにするため)、パスを指定する次のポリシー・ステートメントを記述します。

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC

このポリシーをテナンシにアタッチするには、CompartmentAからCompartmentCへのパスを指定する次のポリシー・ステートメントを記述します。

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

動詞またはリソース・タイプの定義が将来変更される可能性があります。たとえば、virtual-network-familyリソース・タイプが変更され、ネットワーキングに追加されている新しい種類のリソースが含まれるとします。デフォルトでは、ポリシーはサービス定義の変更で自動的に最新に保たれるため、virtual-network-familyにアクセスできるポリシーには、新しく追加されたリソースへのアクセスが自動的に含まれます。

IAMポリシーの概要には、各サービスの特定のresource-typeの詳細と、verbとresource-typeの組合せによって、どのAPI操作にアクセスできるかが含まれます。