ポリシーの仕組み

このトピックでは、ポリシーの仕組みおよび基本機能について説明します。

ポリシーの概要

ポリシーとは、会社が所有するOracle Cloud Infrastructureリソースに誰がアクセスできるか、およびその方法を指定するドキュメントです。ポリシーによって、特定のコンパートメント内の特定のタイプのリソースを特定の方法でグループで使用できます。ユーザー、グループまたはコンパートメントをよく知らない場合は、Identity and Access Managementの概要を参照してください。

通常、組織のIAM管理者が従う必要のあるプロセスは次のとおりです。

  1. 組織のクラウド・リソースを保持するために、ユーザー、グループおよび1つ以上のコンパートメントを定義します。
  2. それぞれがポリシー言語で記述された1つ以上のポリシーを作成します。共通ポリシーを参照してください。
  3. 使用する必要があるコンパートメントとリソースに応じて適切なグループにユーザーを配置します。
  4. コンソールにアクセスしてコンパートメントを使用するために必要な1回かぎりのパスワードをユーザーに提供します。詳細は、ユーザー資格証明を参照してください。

管理者がこれらのステップを完了した後、ユーザーは、コンソールにアクセスして、1回かぎりのパスワードを変更し、ポリシーに記載されている特定のクラウド・リソースを使用できます。

ポリシーの基本

リソースの制御を行うために、会社には少なくとも1つのポリシーがあります。各ポリシーは、この基本構文に従う1つ以上のポリシー・ステートメントで構成されています。

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>

ステートメントは常にAllowという単語で始まります。ポリシーではアクセスのみが許可され、拒否することはできません。かわりに、暗黙的な拒否(デフォルトでは、ユーザーは何も実行できず、ポリシーを介してアクセス権を付与される必要がある)があります。(このルールには1つの例外があります。ユーザーは管理者がポリシーに書き込まずに処理を実行できますか。を参照してください)

組織の管理者がテナンシのグループとコンパートメントを定義します。Oracleでは、ポリシーで使用できる動詞およびリソース・タイプを定義しています(動詞およびリソース・タイプを参照)。

テナンシ内のコンパートメントではなく、テナンシにポリシーを適用する必要がある場合があります。その場合は、次のようにポリシー・ステートメントの終わりを変更します。

Allow group <group_name> to <verb> <resource-type> in tenancy

構文の詳細は、ポリシー構文を参照してください。

使用できるポリシーの数の詳細は、サービス制限を参照してください。

一部の例

たとえば、管理者がユーザーとその資格証明を管理する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 リソースに含まれる可能性がある機密情報またはユーザー指定メタデータにはアクセスせずに、リソースをリストできる権限。重要: ポリシーをリストする操作ではポリシー自体の内容が対象となり、ネットワーキング・リソース・タイプのリスト操作ではすべての情報(セキュリティ・リストおよびルート表の内容など)が返されます。 サードパーティ監査者
read inspectに加えて、ユーザー指定のメタデータと実際のリソース自体を取得する機能が含まれます。 内部監査者
use readに、既存のリソースを操作する機能を追加します(アクションはリソース・タイプによって異なります)。リソースの更新機能が含まれますが、「更新」操作が「作成」操作と同じ効果的な影響を及ぼすリソース・タイプ(UpdatePolicyUpdateSecurityListなど)は除きます。この場合、「更新」機能はmanage動詞でのみ使用できます。一般に、この動詞には、そのタイプのリソースを作成または削除する機能はありません。 リソースの日常的なエンド・ユーザー
manage リソースのすべての権限が含まれます。 管理者

動詞は、特定の一般的なアクセスのタイプ(たとえば、inspectを指定すると、リソースをリストして取得できます)を提供します。次に、そのアクセスのタイプをポリシー内の特定のリソース・タイプと結合する場合(たとえばAllow group XYZ to inspect compartments in the tenancy)、そのグループに特定のセットの権限とAPI操作(ListCompartmentsGetCompartmentなど)のアクセス権を付与えます。詳細な例は、動詞とリソース・タイプの組合せの詳細を参照してください。ポリシー・リファレンスには各サービスについて同様の表が含まれ、動詞とリソース・タイプの各組合せについてどのAPI操作が対象かが正確にリストされて提供されます。

特定のリソース・タイプには、いくつかの特別な例外や微妙な違いがあります。

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

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

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

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

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

inspect動詞では、クラウド・ネットワークのコンポーネント(セキュリティ・リストまたはルート表の名前とOCIDなど)に関する一般情報が戻されるだけではありません。コンポーネントのコンテンツ(たとえば、セキュリティ・リスト内の実際のルール、ルート表内のルートなど)も含まれます。

また、次のタイプの機能はmanage動詞でのみ使用でき、use動詞では使用できません。

  • internet-gatewaysの更新(有効化/無効化)
  • security-listsの更新
  • route-tablesの更新
  • dhcp-optionsの更新
  • 仮想クラウド・ネットワーク(VCN)への動的ルーティング・ゲートウェイ(DRG)のアタッチ
  • DRGと顧客構内機器(CPE)間のIPSec接続の作成
  • ピアVCN
重要

各VCNには、ネットワークの動作に直接影響する様々なコンポーネント(ルート表、セキュリティ・リスト、DHCPオプション、インターネット・ゲートウェイなど)があります。これらのコンポーネントのいずれかを作成する場合、そのコンポーネントとVCNの間の関係を確立します。つまり、コンポーネントを作成してVCN自体を管理することがポリシーで許可されている必要があります。ただし、(ルート・ルールやセキュリティ・リスト・ルールなどを変更するため)そのコンポーネントを更新する機能は、コンポーネントを変更してネットワークの動作に直接影響する場合でも、VCN自体を管理する権限を必要としません。これは、ユーザーに最低限の権限を付与する柔軟性を提供するためであり、ユーザーがネットワークの他のコンポーネントを管理できるように、VCNに過度のアクセス権を付与する必要はありません。特定のタイプのコンポーネントを更新する機能をユーザーに提供することで、ネットワークの動作の制御を暗黙的に信頼することになるので注意してください。

リソース・タイプ

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

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

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

重要

サービスが個々のリソース・タイプを新しく導入する場合、それらは通常、そのサービスのファミリ・タイプに含まれます。たとえば、ネットワーキングが新しい個別のリソース・タイプを導入した場合、それはvirtual-network-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の階層

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つのレベルのコンパートメント階層があるとします。

イメージはCompartmentAを示します。CompartmentB、CompartmentCの階層

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にアクセスできるポリシーには、新しく追加されたリソースへのアクセスが自動的に含まれます。

重要

サービスが既存のリソース・タイプの新しい権限を導入する場合、既存のリソース・タイプのポリシー・ステートメントを更新して、新しい権限を有効にする必要があります。詳細は、このリソース・タイプの新しい権限は伝播されませんを参照してください。

各サービスのポリシーの作成

ポリシー・リファレンスには、各サービスの特定のリソース・タイプの詳細と、動詞とリソース・タイプの組合せによってどのAPI操作へのアクセスが提供されるかが含まれます。