高度なポリシーの機能

この項では、より詳細なアクセス権を付与できるポリシー言語機能について説明します。

条件

ポリシー・ステートメントの一部として、アクセスを付与するために満たす必要のある1つ以上の条件を指定できます。簡単な例は、グループ管理者によるグループ・メンバーシップの管理を参照してください。

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

変数には、リクエスト自体に関連する変数と、リクエストで処理されるリソースに関連する変数(ターゲットとも呼ばれる)の2種類があります。変数の名前の前にはrequestまたはtarget、その後にピリオドが付きます。たとえば、リクエストされているAPI操作を表すrequest.operationというリクエスト変数があります。この変数により、広範なポリシー・ステートメントを作成し、特定のAPI操作に基づいて条件を追加できます。例は、ユーザーによるオブジェクトのオブジェクト・ストレージ・バケットへの書込みを参照してください。

重要

条件の一致では、大文字と小文字は区別されません。このことは、大文字と小文字を区別する名前を許可するリソース・タイプの条件を記述するときに注意する必要があります。オブジェクト・ストレージ・サービスによって、「BucketA」という名前のバケットと「bucketA」という名前のバケットの両方を同じコンパートメントに作成できるとします。「BucketA」を指定する条件を記述すると、条件一致では大文字と小文字が区別されないため、「bucketA」にも適用されます。

拒否されたリクエストのリクエスト結果に適用できない変数

変数が受信リクエストに適用できない場合、条件は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'

前述のポリシーが指定されている場合、GroupAdminsがListUsersUpdateUserなどのユーザーの一般API操作(ユーザーの説明を変更できる)をコールしようとすると、これらのAPI操作がuse usersによってカバーされていても、リクエストは拒否されます。これは、use usersに対する前述のポリシー・ステートメントにはtarget.group.name変数も含まれているが、ListUsersまたはUpdateUserリクエストはグループの指定を必要としないためです。これらのリクエストにはtarget.group.nameがないため、リクエストは拒否されます。

特定のグループを含まない一般ユーザーAPI操作へのアクセス権も付与する場合は、付与するアクセス権のレベルを条件なしで付与する追加のステートメントが必要です。たとえば、ListUsersへのアクセス権を付与する場合は、次のステートメントを追加する必要があります。

Allow group GroupAdmins to inspect users in tenancy

あるいは、UpdateUserへのアクセス権を付与する場合、次の追加のステートメントが必要です(use動詞にはinspect動詞の機能が含まれているため、ListUsersも対象)。

Allow group GroupAdmins to use users in tenancy

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

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

タグ・ベースのアクセス制御

条件およびタグ変数セットを使用すると、リソースに適用されているタグに基づいてアクセスの範囲を指定するポリシーを記述できます。アクセスは、リクエストしているリソース(ポリシー内のグループまたは動的グループ)あるいはリクエストのターゲット(リソースまたはコンパートメント)に存在するタグに基づいて制御できます。タグ・ベースのアクセス制御では、コンパートメント、グループおよびリソースにまたがるアクセスを定義できるため、ポリシーの柔軟性を高めることができます。タグによってアクセスの範囲を指定するポリシーを記述する方法の詳細は、タグを使用したアクセスの管理を参照してください。

権限

権限は、ユーザーがリソースに対して操作を実行できるかどうかを制御する、アトミックな認可単位です。Oracleは、ポリシー言語でのすべての権限を定義します。特定の動詞およびリソース・タイプへのグループ・アクセスを付与するポリシーを記述する場合、実際にはそのグループに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操作と組み合せた条件を使用して、特定の動詞によって付与されるアクセスの範囲を減らすことができます。

たとえば、グループXYZをリスト、取得、作成または更新(つまり、説明の変更)でき、削除はできないとします。グループをリスト、取得、作成および更新するには、動詞およびリソース・タイプとして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操作ではなく権限を使用すると有益です。将来、前述の権限ベースのポリシーにリストされているいずれかの権限を必要とする新しいAPI操作が追加された場合、そのポリシーによって、XYZグループのその新しいAPI操作へのアクセスがすでに制御されています。

ただし、API操作に基づく条件指定することで、ユーザーの権限へのアクセスをさらにスコープ設定できることに注意してください。たとえば、GROUP_INSPECTへのアクセス権をユーザーに付与し、その後ListGroupsのみに絞り込むことができます。

Allow group XYZ to manage groups in tenancy

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

リクエスタのIPアドレスによるポリシーの範囲指定

この機能は現在、オブジェクト・ストレージ・サービスでのみサポートされています。

アクセスの範囲を、許可されたIPアドレスのセットのみに設定できます。たとえば、特定のパブリックIP範囲で発生したリクエストのみに特定のオブジェクト・ストレージ・バケットへのアクセスを許可するポリシーを記述したり、特定のVCNの特定のサブネットのみにサービス・ゲートウェイを介したリクエスト発行を許可することができます。

アクセスをIPアドレス・セットに制限するには、次のことを実行します:

  1. 許可されたIPアドレスを指定するネットワーク・ソース・オブジェクトを作成します。詳細は、ネットワーク・ソースの管理を参照してください。
  2. そのネットワーク・ソース・オブジェクトを使用するポリシーを条件内に記述します。

ポリシーでは次の変数を使用します:

request.networkSource.name='<network_source_name>'

例:

allow group GroupA to manage object-family in tenancy where request.networkSource.name='corpnet'

ポリシーの言語バージョン

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