Oracle Cloud Infrastructureドキュメント

ポリシーの仕組み

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

ポリシーの概要

「ポリシー」は、会社が持っているOracle Cloud Infrastructureリソースに誰がアクセスできるかを指定するドキュメントです。 ポリシーでは、特定のコンパートメント内の特定のタイプのリソースで、特定の方法でのみグループを作業できます。 ユーザー、グループまたはコンパートメントに精通していない場合は、「Oracle Cloud Infrastructure Identity and Access Managementの概要」を参照してください。

一般的に、組織のIAM管理者が従う必要があるプロセスは次のとおりです:

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

管理者がこれらのステップを完了すると、ユーザーはコンソールにアクセスして、ワンタイム・パスワードを変更し、ポリシーに記載されている特定のクラウド・リソースを操作できます。

ポリシーの基本

リソースの管理を管理するために、会社は少なくとも1つのポリシーを持っています。 各ポリシーは、この基本構文に従った1つ以上のpolicystatementsで構成されています:

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

ステートメントは常にAllowという単語で始まることに注意してください。 ポリシーのみallowアクセス。彼らはそれを否定することはできません。 代わりに暗黙の拒否があります。つまり、デフォルトではユーザーは何もできず、ポリシーを通じてアクセスを許可する必要があります。 (このルールには1つの例外があります; 「ユーザーは管理者がポリシーを作成することなく何かを行うことができますか?」を参照してください)

組織内の管理者は、テナンシ内のグループとコンパートメントを定義します。 Oracleは、ポリシーで使用できる可能な動詞とリソース・タイプを定義します(「動詞」Resource-Typesを参照)。

場合によっては、このポリシーをテナンシに適用し、テナンシ内のコンパートメントを適用することは望ましくありません。 その場合は、ポリシー・ステートメントの終わりを次のように変更します:

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

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

いくつのポリシーを持つことができるかについては、「サービス制限」を参照してください。

いくつかの例

たとえば、管理者がユーザーとその資格証明を管理するジョブを持つHelpDeskというグループを作成したとします。 これを可能にするポリシーは次のとおりです:

Allow group HelpDesk to manage users in tenancy

ユーザーがテナンシ(ルート・コンパートメント)に常駐しているため、ポリシーの前にcompartmentという単語は表示されず、単にtenancyという単語が表示されます。

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

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

上記のポリシーには、ポリシー「そのコンパートメントのための」を記述する機能が含まれていることに注意してください。これは、A-Adminsがコンパートメント・リソースへのアクセスを制御できることを意味します。 詳細は、「ポリシー・アタッチメント」を参照してください。

A-AdminsアクセスをProject-Aコンパートメントのコンピュート・インスタンスの起動と管理のみに制限し、ストレージ・ボリューム(ボリュームとそのバックアップの両方)をブロックするが、ネットワーク自体がネットワーク・コンパートメントに存在する場合、ポリシーは代わりに次のとおりです:

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は、使用可能な動詞をポリシーで定義します。 ここでは、最小限のアクセス権から最も多くのものへの動詞の要約を示します:

動詞 対象となるアクセスのタイプ ターゲット・ユーザー
検査 そのリソースの一部である可能性のある機密情報やユーザー指定のメタデータにアクセスすることなく、リソースをリストする機能。
重要:ポリシーをリストする操作には、ポリシーそのものの内容が含まれ、ネットワーキング・リソース・タイプのリスト操作では、すべての情報(セキュリティ・リストやルート表の内容など)が返されます。
第三者審査員
read inspectと、ユーザー指定のメタデータと実際のリソース自体を取得する機能が含まれています。 内部監査員
use readと既存のリソースを処理する機能(リソース・タイプによってアクションが異なる)が含まれています。 更新操作が作成操作(例えば、UpdatePolicyUpdateSecurityListなど)と同じ有効な影響を及ぼすリソース・タイプを除き、リソースを更新する機能を含みます。この場合、更新機能はmanage verbでのみ使用できます。 一般に、この動詞には、そのタイプのリソースを作成または削除する機能は含まれていません。 リソースの日常的エンドユーザー
manage リソースのすべてのアクセス許可が含まれます。 管理者

動詞は特定の一般的なタイプのアクセスを提供します(例えば、inspectはリソースのリストと取得を可能にします)。 そのタイプのアクセスをポリシー内の特定のリソース・タイプ(たとえばAllow group XYZ to inspect compartments in the tenancy)に参加させると、そのグループに特定の権限セットおよびAPI操作(たとえば、ListCompartmentsGetCompartment)へのアクセス権が与えられます。 その他の例については、「動詞+リソース・タイプの組み合わせの詳細」を参照してください。 「ポリシー・リファレンス」には、各サービスの同様の表が含まれており、verbとresource-typeの組み合わせごとにどのAPI操作が適用されるかを正確に示すリストを提供します。

特定のリソース・タイプには、特別な例外やニュアンスがあります。

ユーザー: manage usersmanage groupsの両方にアクセスすると、ユーザーやグループの作成と削除、グループからのユーザーの追加/削除など、ユーザーやグループの作業を行うことができます。 ユーザーとグループの作成と削除にアクセスすることなくグループからユーザーを追加/削除するには、use usersuse groupsの両方のみが必要です。 「共通ポリシー」を参照してください。

ポリシー: ポリシーの更新機能は、ポリシーの更新が新しいポリシーの作成と似ているため(既存のポリシー・ステートメントを上書きすることができるため)、manage policiesではなくuse policiesでのみ使用できます。 さらに、inspect policies を使用すると、ポリシーの全内容を取得できます。

オブジェクト・ストレージ・オブジェクト: inspect objectsを使用すると、バケット内のすべてのオブジェクトをリストし、特定のオブジェクトのHEAD操作を実行できます。 これと比較して、read objectsではオブジェクト自体をダウンロードできます。

ロード・バランシングのリソース: inspect load-balancersを使用すると、ロード・バランサと関連コンポーネント(バックエンド・セットなど)に関するall情報を取得できます。

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

inspect動詞は、クラウド・ネットワーク・コンポーネントに関する一般的な情報(セキュリティ・リストの名前やOCID、ルート表など)を返すだけではないことに注意してください。 また、コンポーネントの内容も含まれます(たとえば、セキュリティ・リストの実際のルール、ルート表のルートなど)。

また、以下のタイプの能力は、manage verbでは使用できず、use verbでは使用できません:

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

重要

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

Resource-Types

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

ポリシー書込みを容易にするために、しばしば一緒に管理される複数の個別リソース・タイプを含むfamilyタイプがあります。 たとえば、virtual-network-familyタイプは、VCNの管理に関連するさまざまなタイプ(たとえば、vcnssubnetsroute-tablessecurity-listsなど)をまとめています。 個々のリソース・タイプにのみアクセスできる、より詳細なポリシーを記述する必要がある場合は、可能です。 しかし、より幅広いリソースにアクセスできるポリシーを簡単に作成することもできます。

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

重要

サービスが新しい個別のリソース・タイプを導入する場合、通常、そのサービスのファミリ・タイプに含まれます。
たとえば、ネットワーキングによって新しい個別のリソース・タイプが導入される場合、virtual-network-familyリソース・タイプの定義に自動的に含められます。 リソース・タイプの定義の将来の変更については、「ポリシーとサービスの更新」を参照してください。

アクセスを許可する条件を指定するなど、ポリシーを細かくする他の方法もあります。 詳細は、「高度なポリシー機能」を参照してください。

複数のリソース・タイプが必要なアクセス

一部のAPI操作では、複数のリソース・タイプにアクセスする必要があります。 たとえば、LaunchInstanceでは、インスタンスを作成してクラウド・ネットワークで作業する必要があります。 CreateVolumeBackup操作では、ボリュームとボリュームの両方のバックアップにアクセスする必要があります。 これは、それぞれのリソース・タイプにアクセスするために別々のステートメントを持つことを意味します(たとえば、「ボリューム・バックアップ管理者にバックアップのみを管理させる」を参照)。 これらの個々のステートメントは、同じポリシーにある必要はありません。 そして、ユーザーは異なるグループに所属することから必要なアクセス権を得ることができます。 たとえば、volumesリソース・タイプとvolume-backupsリソース・タイプに必要なアクセス権を与える別のグループに、必要なレベルのアクセス権を与える1つのグループにGeorgeを含めることができます。 個々のステートメントの合計は、ポリシー全体の中のロケーションに関係なく、CreateVolumeBackupにアクセスできるようになります。

ポリシー継承

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

Allow group Administrators to manage all-resources in tenancy

管理者グループは、ポリシー継承のために、テナンシ内のいずれのコンパートメントでも何でも行うことができます。

詳細は、3レベルのコンパートメントでテナンシを検討してください: CompartmentA、CompartmentB、ComparmentCの各例を次に示します:

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

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

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

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

ポリシー・アタッチメント

ポリシーのもう一つの基本的な特徴は、attachmentの概念です。 ポリシーを作成するときは、そのポリシーをコンパートメント(またはルート・コンパートメントであるテナンシ)に割り当てる必要があります。 それをアタッチするところで、誰がそれを修正したり削除したりすることができるかを制御します。 これをテナンシにアタッチする場合(つまり、ポリシー「にある」がルート・コンパートメント)は、テナンシ内のポリシーを管理するためのアクセス権を持つユーザー全員がそれを変更または削除できます。 通常、これは管理者グループまたはそれに類似したグループで、幅広くアクセスできます。 子コンパートメントのみにアクセスできるユーザーは、そのポリシーを変更または削除することはできません。

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

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

コンパートメントにポリシーをアタッチするときは、そのコンパートメントに入っていなければなりません。どのコンパートメントに適用するかは、文に直接明記する必要があります。 コンパートメントにいない場合は、別のコンパートメントにポリシーをアタッチしようとするとエラーが発生します。 ポリシー作成時にアタッチメントが行われるため、ポリシーを1つのコンパートメントにのみアタッチできることに注意してください。 コンパートメントにポリシーを付加する方法については、「ポリシーを作成するには」を参照してください。

ポリシーおよびコンパートメント階層

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

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

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

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

NetworkAdminが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操作にアクセスするかが含まれています。