機械翻訳について
  1. ユーザー・ガイド
  2. Identity and Access Management
  3. ポリシーの管理

ポリシーの管理

ポリシーは、1つ以上のポリシー・ステートメントの名前付きセットです。 ポリシー・ステートメントは、リソースにアクセスするための権限をユーザーに付与します。

アクセス・ポリシーを設計する場合は、次のポリシー特性に注意してください:

  • ポリシーは、ポリシーをアタッチするコンパートメントとそのコンパートメントのすべてのサブコンパートメントに適用されます。 テナンシを含む特定のコンパートメントで付与された権限は、そのコンパートメントのすべてのサブコンパートメントに継承されます。

  • 1人のユーザーが複数のグループのメンバーになることができます。 グループは複数のポリシーの対象にできます。 1つのポリシーには、最大50個のポリシー・ステートメントを含めることができます。

  • 一部のユーザーが名前付きリソースへのフル・アクセスを必要とし、他のユーザーはリソースのみを使用する必要がある場合は、複数のグループおよび複数のポリシーを作成する必要があります。 テナンシには、最大100個のポリシーを設定できます。

  • サブコンパートメント内のリソースへのフル・アクセス権を持つユーザーには、そのコンパートメントおよび親コンパートメント内の関連リソースへの表示または使用アクセスも必要です。 たとえば、コンパートメントにインスタンスを作成するアクセス権を持つユーザーは、タグ・ネームスペースを使用して定義済のタグをインスタンスに適用したり、別のコンパートメント内のイメージを読み取るためのアクセスが必要になる場合もあります。

概念の詳細は、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ポリシー・ステートメントの記述

1つのポリシーには、最大50個のポリシー・ステートメントを含めることができます。 テナンシには、最大100個のポリシーを設定できます。 ポリシーで許可するものを決定し、この項の情報を使用して必要なステートメントを記述します。

ポリシー・ステートメントに名前を付ける予定のグループおよびコンパートメントが存在することを確認します。 使用する各グループおよびコンパートメントの名前またはOCIDに注意してください。

ノート:

OCIDのかわりにポリシー・ステートメントに名前を使用すると、グループまたはコンパートメントの名前がその後変更されても、ポリシーは引き続き有効になります。 内部的には、名前ではなくOCIDが使用されます。 ただし、管理者はグループまたはコンパートメントの名前が変更されるかどうかを理解するのがより難しい場合があります。

タグを使用してポリシーを複数のグループまたは複数のコンパートメントに適用する場合は、タグが存在することを確認してください。 タグ・ネームスペースの名前、キーの名前およびポリシー・ステートメントで使用する値を書き留めます。

概念および参照情報および一般的な文の例については、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ポリシー・ステートメントの構文

ポリシー・ステートメントは、リソースにアクセスする権限をユーザーまたはコンピュート・インスタンスに付与します。 ユーザーまたはインスタンスはポリシーのサブジェクトとも呼ばれ、権限は動詞とも呼ばれます。 リソース・タイプおよびコンパートメントは、サブジェクトにアクセス権が付与される可能性のあるリソースのセットを定義します。 このリソースのセットは、ターゲットとも呼ばれます。 条件を使用して、ターゲットに対して実行できるサブジェクト、ターゲットおよび操作を絞り込むことができます。

ポリシー・ステートメントの構文は次のとおりです:

allow subject to permissions [resource_type] in compartment [ where conditions ]

キーワードallow、toおよびinは必須であり、大文字と小文字は区別されません。

subject

1つ以上のユーザー・グループ(group)またはany-user、または1つ以上の動的グループ(dynamic-group)。 複数のユーザー・グループまたは動的グループを指定するには、リスト内の2つのグループ名またはOCIDsの間にカンマを使用します。 グループ名とグループOCIDの両方を指定することはできません。 キーワードany-userを指定して、すべてのユーザーに権限を付与できます。

  • group group_name[,group_name …]

  • group id group_ocid[,group_ocid …]

  • any-user

permissions

  • inspect, read, use、またはmanageのいずれか。 これらの権限アグリゲータが付与するアクセス権の詳細は、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」にある"Policy Syntax"の"Verb"を参照してください。

  • 次の形式の1つ以上の特定の権限(INSTANCE_UPDATEなど): 

    { PERMISSION_1[, PERMISSION_2]... }

    このオプションを使用する場合は、resource_typeを指定しないでください。 リソース・タイプは権限に含まれます。

権限アグリゲータと1つ以上の特定の権限を同じリソースに付与するには、2つのポリシー・ステートメントを使用します。

resource_type

次のいずれかを表す単一のキーワード:

  • 単一のリソース・タイプ(instancesやvolumesなど)。

  • リソース・タイプのファミリ。 たとえば、instance-familyリソース・タイプ・ファミリには、次のリソース・タイプが含まれます:

    • app-catalog-listing

    • console-histories

    • instances

    • instance-console-connection

    • instance-images

  • all-resources

4つのアクセス権アグリゲータ・キーワードの1つではなく特定のアクセス権を一覧表示する場合は、resource_typeを指定しないでください。 リソース・タイプは権限に含まれます。

リソース・タイプのリストについては、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」にある"Policy Syntax"の"Resource Types"の表を参照してください。

compartment

単一のコンパートメント名またはOCIDまたはtenancy。

  • compartment compartment_name

  • compartment id compartment_OCID

  • tenancy

複数のコンパートメントでアクセス権を付与するには、複数の文を使用します。

condition

定義済の変数の後に演算子と値が続きます。 「条件の使用」を参照してください。

条件の使用

ポリシー・ステートメントで条件を指定して、アクセス権を付与されるユーザーのセット、アクセス権を付与されるリソースのセット、およびリソースで実行できる操作を絞り込むことができます。 条件は、指定した値を持つ事前定義された変数です。 ANDおよびOR関係で条件のリストを指定できます。 アクセスを許可するには、条件句全体がtrueと評価される必要があります。 予期しないfalseと評価される可能性がある条件の詳細は、「適用できない条件」を参照してください。

条件句の構文は次のとおりです:

where condition
where all|any {condition[, condition]...}

conditionの構文は次のとおりです: 

variable op 'value'
variable

表2-1を参照してください。

op
value

valueには、完全に指定された文字列を指定することも、*ワイルドカードを使用することもできます。 valueが完全に指定された文字列の場合は、値を一重引用符で囲みます。 *を使用する場合は、値をスラッシュ(/)で囲みます: 

'BU1-ProdX'
/*Prod*/
/*ProdX/
/BU1-Prod*/

条件値は大文字と小文字が区別されません。 たとえば、値がBucketAの条件は、そのようなバケットが存在する場合、同じコンパートメント内のバケットbucketAにも適用されます。

次の表で、requestで始まる変数は、実行されているリクエストを参照: ユーザーが「コンピュートWeb UI」オプションをクリックしたか、OCI CLIコマンドを入力しました。 targetで始まる変数は、ユーザーがコマンド内でクリックまたは名前を付けたリソースを参照します。

表2-1 条件でサポートされている事前定義変数

変数 説明

request.groups.id

リクエスト元ユーザーが属するグループのリスト。

request.operation

試行中の操作の名前。

request.permission

操作の実行に必要な権限の名前。

target.compartment.id

ターゲット・リソースを含むコンパートメントのOCID。 ターゲット・リソースを含むコンパートメントは、ポリシー・ステートメントのin句で指定されたコンパートメントの子コンパートメントである可能性があります。

target.compartment.name

ターゲット・リソースを含むコンパートメントの名前。 ターゲット・リソースを含むコンパートメントは、ポリシー・ステートメントのin句で指定されたコンパートメントの子コンパートメントである可能性があります。

target.user.id

ターゲット・ユーザーのOCID。 リクエストされた権限でユーザーを作成する場合、このOCIDは使用できません。

target.user.name

ターゲット・ユーザーの名前。

target.group.id

ターゲット・グループのOCID。 リクエストされた権限でグループを作成する場合、このOCIDは使用できません。

target.group.name

ターゲット・グループの名前。

target.group.member

リクエスト元のユーザーがターゲット・グループに属している場合はtrue。

target.policy.id

ターゲット・ポリシーのOCID。 リクエストされた権限でポリシーを作成する場合、このOCIDは使用できません。

target.policy.name

ターゲット・ポリシーの名前。

target.tag-namespace.id

リスト、更新または削除するためにユーザーがリクエストしているタグ・ネームスペースのOCID。

target.tag-namespace.name

ユーザーが作成または更新をリクエストしているタグ・ネームスペースの名前。 複数の名前を区切るにはカンマを使用します

request.principal.group.tag

「条件での定義済タグの使用」を参照してください。

target.resource.tag

「条件での定義済タグの使用」を参照してください。

target.resource.compartment.tag

「条件での定義済タグの使用」を参照してください。

例: request.permissionを使用した権限の指定

オブジェクトを作成する権限ではなく、オブジェクトを削除する権限を付与するには、manageアクセス権を付与し、アクセス権の作成と検査のみが付与されることを示す条件を指定できます: 

allow group ObjectWriters to manage objects in compartment ABC 
where any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}

例: target.compartment.nameおよびワイルドカードを使用したコンパートメントの指定

次の例では、コンパートメントXYZを除き、Xで始まる名前を持つコンパートメント内のvirtual-network-familyのすべてのリソースを管理する権限をユーザーに付与します: 

allow group NetworkAdmins to manage virtual-network-family in tenancy 
where all {target.compartment.name=/X*/,target.compartment.name!='XYZ'}

例: ネストされた条件

次のポリシーにより、グループBucketAdminsのユーザーは、コンパートメントABCのBucketAの保持ルールの読取り、更新または管理を行うことができます:

allow group BucketAdmins to manage buckets in compartment ABC 
where all {target.bucket.name='BucketA', 
any {request.permission='BUCKET_UPDATE', request.permission='BUCKET_READ',
RETENTION_RULE_MANAGE}}

ポリシーは特定の名前付きバケット用であるため、ユーザーはバケットのリストの取得を許可しません。 ユーザーがバケットのリストを取得できるようにするには、次の個別の文を追加します: 

allow group BucketAdmins to inspect buckets in compartment ABC

「適用できない条件」を参照してください。

例: 定義済タグの適用

次の例では、グループBucketAdminsおよびObjectWritersのユーザーがStorageTagsタグ・ネームスペースにタグを適用できます:

allow group BucketAdmins,ObjectWriters to use tag-namespaces in tenancy 
where target.tag-namespace.name='StorageTags'

例: メンバーである任意のグループの編集

次の例では、すべてのユーザーがメンバーである任意のグループを編集できます:

allow any-user to use groups in tenancy where target.group.member='true'

適用できない条件

条件が残りのポリシー・ステートメントに適用されない場合、その条件はfalseに評価され、アクセスは付与されません。

条件は、リクエストで使用できない情報をテストしている場合、適用できません。 たとえば、次のポリシー・ステートメントは、リソースusersへのuseアクセス権を付与しますが、リクエスト・ユーザーは、use権限に含まれている場合でも、ユーザーのリストまたは更新を許可しません: 

allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'

ユーザーのリストまたはユーザーの更新リクエストには、グループに関する情報が含まれていません。 リスト・ユーザーおよび更新ユーザーのリクエストには、target.group.nameの値がありません。 テストは失敗し、ユーザーをリストまたは更新するリクエストは拒否されます。

この例を修正するには、where句を削除し、inspectまたはreadアクセスのみを許可できます。

条件での定義済タグの使用

特定の条件では、ユーザー、コンパートメントまたはリソースに適用された定義済タグの値が評価されます。 これらの条件では、事前定義された変数をタグ変数と呼ぶことができます。

タグ変数とともに条件を使用すると、次のことができます:

  • 複数のユーザー・グループ、コンパートメントまたはリソースに適用される単一のポリシー・ステートメントを記述します。

  • ポリシー・ステートメントを変更せずに付与される権限を変更します。 かわりに、アクセスを許可または取り消すには、別のリソースにタグを適用するか、リソースからタグを削除します。

定義済タグを作成および適用する方法の詳細は、「リソース・タグ管理」を参照してください。

タグ変数を使用する条件の一般的な構文は、他の条件変数を使用する条件の構文と同じです:

variable op 'value'

これら3つの各パーツの値は、タグ専用です。

variable

タグ条件変数には、タグ・ネームスペースの名前および変数名にキーの名前が含まれます:

base_variable_name.tag_namespace_name.tag_key_name
op

=, !=, in、またはnot inのいずれか。

inおよびnot in操作は、タグに対して可能な値のセットのメンバーを参照します。

value

valueは、定義されたタグの値です。 値は単一値または値リストです。

次のタグ変数がサポートされています:

request.principal.group.tag

この変数は、1つの文の複数のグループへのアクセス権を付与される可能性があります。 次の文では、タグOperations>Project>ABCでタグ付けされたグループのメンバーであるユーザーが、コンパートメントProdXのインスタンス・リソースを管理できます: 

allow any-user to manage instance-family in compartment ProdX 
where request.principal.group.tag.Operations.Project='ABC'

前述の文の'ABC'を'*'または/*/,に置換すると、Operationsの値でタグ付けされたグループのメンバーであるユーザー>ProjectがコンパートメントProdXのインスタンス・リソースを管理できます。

target.resource.compartment.tag

この変数は、1つの文で複数のコンパートメントへのアクセス権を付与される可能性があります。 次の文では、グループNetAdminsのユーザーは、タグ操作>プロジェクト>ABCまたはタグ操作>パーソネル>テストでタグ付けされた任意のコンパートメントのネットワーク・リソースを使用できます: 

allow group NetAdmins to use virtual-network-family in tenancy where
any { target.resource.compartment.tag.Operations.Project='ABC', 
target.resource.compartment.tag.Operations.Personnel='Test' }

前述の文でanyをallに置換した場合、NetAdminsグループのユーザーは、タグOperations>Project>ABCおよびtag Operations>Personnel>Testの両方のタグが付けられた任意のコンパートメントのネットワーク・リソースを使用できます。

次の文を使用すると、グループNetAdminsのユーザーは、タグ操作>人事>開発またはタグ操作>人事>テストのいずれかのタグが付けられた任意のコンパートメントのネットワーク・リソースを使用できます:

allow group NetAdmins to use virtual-network-family in tenancy where
target.resource.compartment.tag.Operations.Personnel in ('Development', 'Test')

target.resource.tag

この変数は、指定されたタイプの1つ以上のリソースへのアクセス権を付与します。 次の文では、グループXadminは、タグOperations>Project>XYZでタグ付けされたコンパートメントProdX内の任意のインスタンスを使用できます。 

allow group Xadmins to use instances in compartment ProdX 
where target.resource.tag.Operations.Project = 'XYZ'

テナンシのリソースにアクセスするためのポリシーの記述

始める前に

他のテナンシからのテナンシ・アクセスを許可するポリシーを記述して、テナンシ間でリソースを共有できます。 両方のテナンシの管理者は、どのリソースにアクセスして共有できるかを明示的に示す特別なポリシー・ステートメントを作成する必要があります。 これらの特別な文では、次の特殊動詞を使用します:

  • 裏書: このポリシー・ステートメントは、ソース・テナンシ内のグループが他のテナンシで実行できる作業について説明します。 別のテナンシ・リソースを操作する必要があるユーザーのグループを含むテナンシのendorse文を記述します。
  • 許可: このポリシー・ステートメントは、他のテナンシのグループが宛先テナンシで実行できる作業について説明します。 リソースにアクセスする権限を付与するテナンシのadmit文を記述します。 admit文は、宛先テナンシのリソース・アクセスを必要とするソース・テナンシのユーザーのグループを識別します。

  • 定義: このポリシー・ステートメントは、ソース・テナンシ OCID、ソース・グループ OCIDおよび宛先テナンシ OCIDの別名を割り当てるために使用されます。 admitポリシー・ステートメントで使用する「ソース・テナンシ」別名および「ソース・グループ」別名を定義します。 endorseポリシー・ステートメントで使用する「宛先テナンシ」別名を定義します。

    endorse文またはadmit文と同じポリシー・エンティティにdefine文を含める必要があります。

endorse文とadmit文は連携して動作します。 endorse文はソース・テナンシに存在し、admit文は宛先テナンシに存在します。 アクセスを指定する対応する文がない場合、特定のendorseまたはadmit文はアクセス権を付与しません。 両方のテナンシがアクセスに同意し、アクセスを許可するポリシーを持っている必要があります。

ソース・テナンシでは、次の構文を使用してdefineおよびendorseポリシー・ステートメントを記述します: 

define tenancy destination-tenancy-alias as tenancy_ocid
endorse group group-name to verb resource in tenancy destination-tenancy-alias

宛先テナンシでは、次の構文を使用して、2つのdefineポリシー・ステートメントおよびadmitポリシー・ステートメントを記述します: 

define tenancy source-tenancy-alias as tenancy_ocid
define group source-group-alias as group_ocid
admit group source-group-alias of tenancy source-tenancy-alias to verb resource in compartment/tenancy

概念および参照情報および一般的な文の例については、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」の「ポリシーの仕組み」を参照してください。

ソース・テナンシのポリシー・ステートメント

ソース・テナンシの管理者は、宛先テナンシのリソースを管理するためにテナンシのグループをエンドースするポリシー・ステートメントを作成します。

次の例に示すように、ソース・テナンシに対して広範なポリシー・ステートメントを記述できます。

  • StorageAdminsなどの特定のグループを承認して、テナンシ内のすべてのオブジェクト・ストレージ・リソースに対して何でも行うには: 

    endorse group StorageAdmins to manage object-family in any-tenancy

  • DNSAdminsなどの特定のグループを承認して、テナンシ内のすべてのDNSリソースに対して何でも行うには: 

    endorse group DNSAdmins to manage dns in any-tenancy

ソース・テナンシ・グループのアクセス範囲を減らすポリシーを記述できます。 このタイプのポリシーの場合、ソース・テナンシの管理者は、宛先テナンシOCIDの別名を定義し、ポリシー・ステートメントでその別名を参照する必要があります。たとえば:

  • StorageAdminsなどの特定のグループをエンドースして、DestinationTenancyなどの特定のテナンシのオブジェクト・ストレージ・リソースを管理するには、次のポリシー・ステートメントを使用します: 

    define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
endorse group StorageAdmins to manage object-family in tenancy DestinationTenancy

  • DNSAdminsなどの特定のグループを承認して、DestinationTenancyなどの特定のテナンシのDNSリソースを管理するには、次のポリシー・ステートメントを使用します: 

    define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
endorse group DNSAdmins to manage dns in tenancy DestinationTenancy

宛先テナンシには、ソース・テナンシ・グループが宛先テナンシおよびそのリソースにアクセスできるようにするポリシーも必要です。 宛先テナンシでこの対応するポリシーがない場合、ソース・テナンシ・グループは宛先テナンシまたはそのリソースにアクセスできません。

ポリシー・ステートメントの記述の詳細は、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」のポリシーの仕組みを参照してください。

宛先テナンシ・ポリシー・ステートメント

宛先テナンシの管理者は、ソース・テナンシのグループが宛先テナンシとそのリソースにアクセスできるようにするポリシー・ステートメントを作成します。

次の例に示すように、宛先テナンシに対して広範なポリシー・ステートメントを記述できます。

  • ソース・テナンシ内の特定のグループ(StorageAdminsなど)が宛先テナンシ内のすべてのオブジェクト・ストレージ・リソースに対して何でも実行できるようにするには: 

    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group StorageAdmins as ocid1.group.oc1..<unique_ID>
admit group StorageAdmins of tenancy SourceTenancy to manage object-family in tenancy
  • ソース・テナンシ内の特定のグループ(DNSAdminsなど)が宛先テナンシ内のすべてのDNSリソースに対して何でも実行できるようにするには:
    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group DNSAdmins as ocid1.group.oc1..<unique_ID>
admit group DNSAdmins of tenancy SourceTenancy to manage dns in tenancy

ソース・テナンシ・グループのアクセス範囲を宛先テナンシ・リソースに減らすポリシーを記述できます。 これらのタイプのポリシーの場合、宛先テナンシの管理者は、ソース・テナンシOCIDおよびソース・グループOCIDの別名を定義してから、ポリシー・ステートメントで次のような別名を参照する必要があります:

  • StorageAdminsなどのソース・テナンシ内の特定のグループに、SharedBucketsなどの特定のコンパートメント内のオブジェクト・ストレージ・リソースの管理を許可するには、次のポリシー・ステートメントを使用します: 

    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group StorageAdmins as ocid1.group.oc1..<unique_ID>
admit group StorageAdmins of tenancy SourceTenancy to manage object-family in compartment SharedBuckets
  • DNSAdminsなどのソース・テナンシ内の特定のグループが、SharedZomesなどの特定のコンパートメント内のDNSリソースを管理できるようにするには、次のポリシー・ステートメントを使用します:
    define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
define group DNSAdmins as ocid1.group.oc1..<unique_ID>
admit group DNSAdmins of tenancy SourceTenancy to manage dns in compartment SharedZones

ソース・テナンシには、ソース・テナンシ・グループの宛先テナンシおよびそのリソースへのアクセスをエンドースするポリシーも必要です。 ソース・テナンシでこの対応するポリシーがない場合、ソース・テナンシ・グループは宛先テナンシまたはそのリソースにアクセスできません。

ポリシー・ステートメントの記述の詳細は、「Oracle Private Cloud Applianceコンセプト・ガイド」の「Identity and Access Management概要」のポリシーの仕組みを参照してください。

ポリシーの作成

始める前に

ポリシーには少なくとも1つのポリシー・ステートメントが必要です。 空のポリシーを作成し、後でステートメントを追加することはできません。 ポリシーで許可するものを決定し、「ポリシー・ステートメントの記述」を参照して必要な文を設計してください。

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 「ポリシーの作成」をクリックします。

  3. 「ポリシーの作成」ダイアログで、次の情報を入力します:

    • 名前: ポリシー名。 ポリシー名には次の特性があります:

      • テナンシ内で一意である必要があります。

      • 大文字と小文字は区別されません。

      • 後で変更できません。

      • 100文字以下にしてください。

      • スペースは使用できません。 文字、数字、ハイフン、ピリオドまたはアンダースコアのみを含めることができます。

    • 摘要: ポリシーの説明。 この説明は400文字以下にしてください。

    • コンパートメントに作成: このポリシーをアタッチするコンパートメントを選択します。 ポリシーはこのコンパートメントと、このコンパートメントのすべての子コンパートメントに適用されます。

    • 計算書: ポリシー・ステートメントを入力します。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

      2つ目のポリシー・ステートメントを追加するには、+「別のステートメント」ボタンをクリックします。 最大50個の文を入力できます。 複数のポリシー・ステートメントを作成する場合は、ステートメントの横にあるXボタンをクリックしてそのステートメントを削除できます。

    • タグ付け: (オプション) リソース作成時のタグの追加の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグを追加します。 タグは後で適用することもできます。

  4. 「ポリシーの作成」ボタンをクリックします。

    新しいポリシーの詳細ページが表示されます。 ページの「リソース」セクションに、ポリシー・ステートメントが表示されます。

OCI CLIの使用

  1. ポリシーをアタッチするコンパートメントのOCIDを取得します。 ポリシーはこのコンパートメントと、このコンパートメントのすべての子コンパートメントに適用されます。 

    $ oci iam compartment list --compartment-id-in-subtree true

  2. --statementsオプションの引数を作成します。

    --statementsオプション引数の値は、JSON形式のポリシー・ステートメントの配列です。 この引数は、コマンド行またはファイルで文字列として指定できます。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

  3. (オプション) 「リソース作成時のタグの追加」の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグの引数を作成します。 タグは後で適用することもできます。

  4. ポリシーcreateコマンドを実行します。

    構文:

    oci iam policy create -c compartment_OCID --name text --description "text" \
{ --statements '["statement","statement"]' | --statements file://policy.json }

    compartment_OCIDは、このポリシーをアタッチするコンパートメントです。 名前および説明の値の特性については、「コンピュートWeb UI」プロシージャを参照してください。 定義済タグおよびフリー・フォーム・タグを追加するには、「リソース作成時のタグの追加」を参照してください。

    このコマンドは、policy getコマンドと同じ出力を返します。

ポリシーの更新

「コンピュートWeb UI」を使用したポリシーの説明またはタグの変更

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 変更するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 変更するポリシーについて、ポリシーのアクション・メニューをクリックし、編集オプションをクリックします。

  4. 説明またはタグを更新します。

    タグを変更するには、「既存のリソースへのタグの適用」を参照してください。

  5. Save Changesボタンをクリックします。

「コンピュートWeb UI」を使用したポリシー・ステートメントの変更

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 変更するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 変更するポリシーの名前をクリックします。

  4. ポリシーの詳細ページで、リソース・セクションまでスクロールします。

  5. 文リストで、ポリシー・ステートメントの構成ボタンをクリックします。

  6. policy_nameポリシー・ダイアログのステートメントの編集で、ポリシー・ステートメントを変更または追加します。

    ポリシー・ステートメントを変更するには、「ポリシー・ステートメントの記述」を参照してください。

    ポリシー・ステートメントを追加するには、別のステートメント・ボタンをクリックします。 最大50個の文を入力できます。

    複数のポリシー・ステートメントが存在する場合は、ステートメントの横にあるXボタンをクリックしてそのステートメントを削除できます。

  7. 「送信」ボタンをクリックします。

OCI CLIの使用

  1. ポリシーOCIDを取得します。

    $ oci iam policy list --compartment-id compartment_OCID

  2. (オプション)ポリシー・ステートメントを変更または追加するには、--statementsオプションの引数を作成します。

    --statementsオプション引数の値は、JSON形式のポリシー・ステートメントの配列です。 この引数は、コマンド行またはファイルで文字列として指定できます。 ポリシー・ステートメントの記述方法の詳細は、「ポリシー・ステートメントの記述」を参照してください。

    --statementsオプションに指定した引数は、ポリシー内の既存の文を置き換えます。 既存のポリシーから保持するステートメントを必ず含めてください。 policy getコマンドを使用して、現在のポリシー・ステートメントを表示およびコピーします。

    --forceオプションを指定しない場合、ポリシー内の既存の文が表示され、置換の確認を求められます。

  3. (オプション) 「リソース作成時のタグの追加」の説明に従って、このポリシーの定義済タグまたはフリー・フォーム・タグの引数を作成します。

  4. ポリシー更新コマンドを実行します。

    構文:

    oci iam policy update --policy-id policy_OCID [ --description desc ] \
[ --defined-tags tags ] [ --freeform-tags tags ] \
[ --statements policy_statements --version-date "" ]

    --statementsを指定する場合は、--version-date ""を含める必要があります。

    このコマンドは、policy getコマンドと同じ出力を返します。

ポリシーの削除

「コンピュートWeb UI」の使用

  1. ナビゲーション・メニューで、アイデンティティをクリックし、ポリシーをクリックします。

  2. 削除するポリシーがリストに表示されない場合は、ポリシー・リストの上にあるコンパートメント・ドロップ・ダウン・メニューから適切なコンパートメントを選択します。

  3. 削除するポリシーについて、アクション・メニューをクリックし、削除オプションをクリックします。

  4. 確認ダイアログで、「削除」ボタンをクリックします。

OCI CLIの使用

  1. ポリシーOCIDを取得します。

    $ oci iam policy list --compartment-id compartment_OCID

  2. ポリシー削除コマンドを実行します。

    構文:

    oci iam policy delete --policy-id policy_OCID

    このコマンドは、policy getコマンドと同じ出力を返します。