Oracle Cloud Infrastructureドキュメント

高度なポリシー機能

このセクションでは、より詳細なアクセスを許可するポリシー言語機能について説明します。

条件

ポリシー・ステートメントの一部として、アクセスを許可するために満たさなければならない1つ以上のconditionsを指定することができます。 簡単な例については、「グループ管理者にグループ・メンバーシップを管理させる」を参照してください。

各条件は、ポリシー・ステートメントの値を指定する1つ以上の定義済み変数で構成されます。 後で、誰かが問題のリソースへのアクセスをリクエストしたときに、ポリシーの条件が満たされると、それはtrueと評価され、リクエストは許可されます。 条件が満たされない場合は、falseと評価され、リクエストは許可されません。

変数には2つのタイプがあります: リクエスト自体に関連するもの、およびリクエストに応じて動作するリソースに関連するもの(targetとも呼ばれます)。 変数の名前には、requestまたはtargetのあとにピリオドが付加されます。 たとえば、リクエストされているAPI操作を表すためのrequest.operationというリクエスト変数があります。 この変数を使用すると、幅広いポリシー・ステートメントを作成できますが、特定のAPI操作に基づいて条件を追加できます。 例については、「ユーザーがObject Storageバケットにオブジェクトを書き込めるようにします」を参照してください。

リクエストに適用されない変数は、要求が拒否された結果

変数が着信リクエストに対して「適用できません」である場合、条件はfalseと評価され、リクエストは拒否されます。 たとえば、管理者以外のグループにユーザーを追加したり削除したりする基本的なポリシー・ステートメントを次に示します:

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

Allow group GroupAdmins to use groups in tenancy
where target.group.name != 'Administrators'

Given the above policy, if GroupAdmins tried to call a general API operation for users such as ListUsers or UpdateUser (which lets you change the user's description), the request would be declined, even though those API operations are covered by use users.This is because the above policy statement for use users also includes the target.group.name variable, but the ListUsers or UpdateUser request doesn't involve specifying a group. これらのリクエストにはtarget.group.nameがないため、リクエストは拒否されます。

特定のグループに関係しない一般ユーザーAPI操作にもアクセス権を付与する場合は、付与するアクセス・レベルを指定する追加のステートメント「条件なし」が必要です。 たとえば、ListUsersへのアクセスを許可する場合は、次の追加の文が必要です:

Allow group GroupAdmins to inspect users in tenancy

または、UpdateUserへのアクセスを許可する場合は、use verbにinspect verbの機能が含まれているため、この追加ステートメント(ListUsersも扱います)が必要です:

Allow group GroupAdmins to use users in tenancy

この一般的な概念は、グループ(例:ListGroupsおよびUpdateGroup)、およびターゲット変数を持つ他のリソース・タイプにも適用されます。

条件の構文の詳細については、「条件」を参照してください。 ポリシーで使用できるすべての変数のリストについては、「ポリシー・リファレンス」の表を参照してください。

権限

「アクセス許可」は、リソースに対する操作を実行するユーザーの能力を制御するアトミック認証単位です。 Oracleはポリシー言語のすべての権限を定義します。 特定のverbとリソース・タイプへのグループ・アクセス権を与えるポリシーを作成すると、実際にそのグループに1つ以上の事前定義されたアクセス権が与えられます。 動詞の目的は、一連のアクセスまたは特定の操作シナリオをカバーする複数の関連するアクセス許可を許可するプロセスを簡素化することです。 次のセクションでは、詳細と例を示します。

動詞との関係

パーミッションと動詞の関係を理解するために、例を見てみましょう。 グループにinspect volumesを許可するポリシー・ステートメントは、実際にグループにVOLUME_INSPECTというアクセス権(アクセス権は常にすべて大文字と下線で書かれています)にアクセスできるようにします。 一般的に、その権限により、ユーザーはブロック・ボリュームに関する情報を取得できます。

inspect> read> use> manageから行くにつれて、アクセスのレベルは一般に増加し、付与された許可は累積的です。 次の表は、volumesリソース・タイプの各動詞に含まれる許可を示しています。 inspectからreadへの追加のアクセス権は与えられないことに注意してください。

ボリュームを検査 ボリュームを読み込む ボリュームを使用 ボリュームを管理
VOLUME_INSPECT VOLUME_INSPECT

VOLUME_INSPECT

VOLUME_UPDATE

VOLUME_WRITE

VOLUME_INSPECT

VOLUME_UPDATE

VOLUME_WRITE

VOLUME_CREATE

VOLUME_DELETE

「ポリシー参照」は、指定されたリソース・タイプごとに各動詞が対象とするパーミッションをリストします。 たとえば、コア・サービスが対象とするブロック・ボリュームやその他のリソースについては、「動詞+リソース・タイプの組み合わせの詳細」の表を参照してください。 これらの各表の左の列には、それぞれの動詞が扱う権限がリストされています。 ポリシー参照の他のセクションには、他のサービスと同じ種類の情報が含まれています。

API操作との関係

各API操作では、呼び出し元が1つ以上のアクセス権にアクセスできる必要があります。 たとえば、ListVolumesまたはGetVolumeのいずれかを使用するには、単一のアクセス権にアクセスできる必要があります: VOLUME_INSPECT. インスタンスにボリュームをアタッチするには、volumesリソース・タイプに関連するものと、volume-attachmentsリソース・タイプに関連するもの、instancesリソース・タイプに関連するものがあります:

  • VOLUME_WRITE
  • VOLUME_ATTACHMENT_CREATE
  • INSTANCE_ATTACH_VOLUME

ポリシー参照には、各API操作に必要な権限が一覧表示されます。 たとえば、Core Services API操作については、「各API操作に必要なアクセス許可」の表を参照してください。

ユーザー・アクセスの理解

ポリシー言語は、ステートメントに必要な権限を記述することなく、動詞とリソース・タイプのみを含む簡単なステートメントを記述できるように設計されています。 ただし、セキュリティ・チームのメンバーまたは監査人が特定のユーザーの特定のアクセス許可を理解したい場合があります。 「ポリシー参照」の表には、各動詞と関連する権限が表示されます。 ユーザーが属しているグループとそれらのグループに適用可能なポリシーを確認し、許可されているアクセス許可のリストをコンパイルできます。 ただし、パーミッションのリストを持つことは完全な画像ではありません。 ポリシー・ステートメントの条件によって、個々のアクセス権を超えてユーザー・アクセスをスコープできます(次のセクションを参照)。 また、各ポリシー・ステートメントは特定のコンパートメントを指定し、そのコンパートメント内の特定のリソースのみへのアクセスをさらに制限する条件を持つことができます。

パーミッションまたはAPI操作によるスコープ・アクセス

ポリシー・ステートメントでは、アクセス権またはAPI操作と組み合わされたconditionsを使用して、特定の動詞によって許可されるアクセスの範囲を減らすことができます。

たとえば、グループXYZがグループの一覧表示、取得、作成、または更新(つまり、説明の変更)はできるが、削除はできないようにしたいとします。 グループのリスト作成、取得、作成、更新を行うには、verbとresource-typeとしてmanage groupsを指定したポリシーが必要です。 「動詞+リソース・タイプの組み合わせの詳細」の表によれば、適用される権限は次のとおりです:

  • GROUP_INSPECT
  • GROUP_UPDATE
  • GROUP_CREATE
  • GROUP_DELETE

必要な権限のみにアクセスを制限するには、条件許可したいパーミッションを明示を追加します:

Allow group XYZ to manage groups in tenancy

where any {request.permission='GROUP_INSPECT', request.permission='GROUP_CREATE', request.permission='GROUP_UPDATE'}

代替策として、「除くすべての権限を許可」 GROUP_DELETE:

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

ただし、この方法では、サービスが将来追加する可能性のある新しい権限は、グループXYZに自動的に付与されることに注意してください。 GROUP_DELETEだけが省略されます。

もう一つの方法は、条件「特定のAPI操作に基づいて」を書くことです。 「各API操作に必要なアクセス許可」の表に従って、ListGroupsGetGroupの両方にはGROUP_INSPECTパーミッションのみが必要です。 ここにポリシーがあります:

Allow group XYZ to manage groups in tenancy

where any {request.operation='ListGroups', request.operation='GetGroup', request.operation='CreateGroup', request.operation='UpdateGroup'}

条件でAPI操作の代わりにアクセス許可を使用すると便利です。 将来、上記の権限ベースのポリシーにリストされている権限の1つを必要とする新しいAPI操作が追加された場合、そのポリシーはすでにその新しいAPI操作に対するXYZグループのアクセスを制御します。

しかし、API操作に基づいて条件を指定することで、alsoによってユーザーのアクセス許可をさらに絞り込むことができます。 たとえば、ユーザーにGROUP_INSPECTへのアクセス権を与えることはできますが、その後はListGroupsにしかアクセスできません。

Allow group XYZ to manage groups in tenancy

where all {request.permission='GROUP_INSPECT', request.operation='ListGroups'}

ポリシー言語バージョン

「ポリシーとサービスの更新」で説明したように、デフォルトでは、サービスの変更に応じて、動詞とリソースの定義が変更されたときにポリシーが最新の状態に保たれます。 特定の日付の現在の定義に従ってアクセスを制限したい場合は、そのようにすることができます。 ポリシーを作成するときに、日付を指定することができます。その日付はバージョンとみなされます。 また、既存のポリシーのバージョンを更新することもできます。 詳細については、「ポリシーを作成するには」および「既存のポリシーのバージョン日付を更新するには」を参照してください。