高度なポリシーの機能

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

条件

ポリシー・ステートメントの一部として、アクセスを付与するために満たす必要のある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'

時間枠に基づいたリソースへのアクセスの制限

ポリシーで時間ベースの変数を使用すると、ポリシーで付与されるアクセス権を特定の時間枠のみに制限できます。この機能によって、リソースに対するアクションを特定の時間に制限できます。たとえば、指定した日付までのアクセスのみを許可するポリシーを作成できます。このようなポリシーは、会社が契約社員を採用し、その契約終了日を過ぎた後はアクセスを許可しない場合に役立ちます。または、営業時間中(月曜日から金曜日の午前9:00から午後5:00など)にのみリソースへのアクセスを許可できます。この制限により、悪意のあるアクターが、気づかれない可能性が高い状態で変更を行うリスクを軽減できます。

時間に基づいてアクセスの範囲を設定するために使用できる変数は:

  • request.utc-timestamp
  • request.utc-timestamp.month-of-year
  • request.utc-timestamp.day-of-month
  • request.utc-timestamp.day-of-week
  • request.utc-timestamp.time-of-day

これらの変数の使用方法は、後続の項で詳しく説明します。

時間ベース変数で作業するための情報

時間変数は、ISO 8601フォーマット(YYYY-MM-DDThh:mm:ssZ)を使用して指定する必要があります。このフォーマットの例は:

  • 秒付きの日時: '2020-04-01T15:00:00Z'
  • 分付きの日時: '2020-04-01T05:00Z'
  • 日付のみ: '2020-04-01Z'
  • 時間のみ: '05:00:00'

時間は秒単位まで指定できますが、リクエストのタイムスタンプとIAMサービスによってリクエストが評価される時間との間には5分の時間差を許容する必要があります。この時間差はいくつかの要因によって引き起こされる可能性があるため、時間ベースのポリシーを計画して実装するときには、この潜在的な差異に注意してください。

指定する時間は、協定世界時(UTC)として評価されます。つまり、ポリシーが評価されるタイム・ゾーンの正しいUTC時間を計算する必要があります。たとえば、変数の値として太平洋標準時の午前9:00を指定するには、「17:00:00」と入力します。ロケールがサマータイムに参加している場合、時間変更が有効になる特定の時間を参照しているポリシーはすべて更新する必要があります。

各時間ベース変数の詳細

各変数の使用方法は、次の項で説明します:

request.utc-timestamp

説明: リクエストが認可のために受信された時間。特定の日時タイムスタンプの前または後にのみアクセスを許可するポリシーを記述できます。タイムスタンプは、ISO 8601フォーマット(YYYY-MM-DDThh:mm:ssZ)に準拠し、協定世界時(UTC)である必要があります。

サポートされる演算子: before | after

許可される値: ISO 8601フォーマット(YYYY-MM-DDThh:mm:ssZ)の協定世界時(UTC)タイムスタンプ

値の例:
  • '2020-04-01T00:00:00Z'
  • '2020-04-01T00:00Z'

ポリシーの例: グループContractorsが特定の日付までinstance-familyリソースにアクセスできるようにします:

Allow group Contractors to manage instance-family in tenancy where request.utc-timestamp before '2022-01-01T00:00Z'

ポリシーによってグループContractorsに付与されたアクセス権は、2022年1月1日午前12:00 (UTC)に期限切れになります。

request.utc-timestamp.month-of-year

説明: リクエストが認可のために受信された該当年の月。特定の月の間のみアクセスを許可するポリシーを記述できます。

サポートされる演算子: = | != | in

許可される値: 数値の月(ISO 8601に一致)

値の例: '1'、'2'、'3'、... '12'

ポリシーの例: グループSummerInternsが6月、7月、8月の間のみinstance-familyリソースにアクセスできるようにします:

Allow group SummerInterns to manage instance-family in tenancy where ANY {request.utc-timestamp.month-of-year in ('6', '7', '8')}

ポリシーによってグループSummerInternsに付与されたアクセス権は、該当年の6月、7月、8月の間のみ有効です。

request.utc-timestamp.day-of-month

説明: リクエストが認可のために受信された該当月の日。該当月の特定の日のみアクセスを許可するポリシーを記述できます。1日の期間はUTCに基づいて計算されることに注意してください。たとえば、米国フロリダ州マイアミにいる場合に、「1」と入力して月の最初の日を示すとします。2月について、ポリシーは、2月1日の午前12:00時から午後11:59 (UTC)まで有効になりますが、これはマイアミでは1月31日の午後7:00から2月1日の午後6:59までに相当します。

サポートされる演算子: = | != | in

許可される値: 月の数値の日

値の例: '1'、'2'、'3'、... '31'

ポリシーの例: グループComplianceAuditorsが月の最初の日のみall-resourcesを読み取ることができるようにします。

Allow group ComplianceAuditors to read all-resources in tenancy where request.utc-timestamp.day-of-month = '1'

ポリシーによってグループComplianceAuditorsに付与されたアクセス権は、各月の最初の日のみ有効です(1日はUTC時間で定義されます)。

request.utc-timestamp.day-of-week

説明: リクエストが認可のために受信された曜日。特定の曜日のみアクセスを許可するポリシーを記述できます。1日の期間はUTCに基づいて計算されることに注意してください。たとえば、米国フロリダ州マイアミにいる場合に、「monday」と入力するとします。ポリシーは、月曜日の午前12:00時から午後11:59 (UTC)まで有効になりますが、これはマイアミでは日曜日の午後7:00 (EST)から月曜日の午後6:59までに相当します。

サポートされる演算子: = | != | in

許可される値: 英語の曜日名

値の例: 'Monday'、'Tuesday'、'Wednesday'など

ポリシーの例: グループWorkWeekが会社の週作業日の間のみinstance-familyを管理できるようにします。

Allow group WorkWeek to manage instance-family where ANY {request.utc-timestamp.day-of-week in ('monday', 'tuesday', 'wednesday', 'thursday', 'friday')}

ポリシーによってグループWorkWeekに付与されたアクセス権は、指定された日のみ有効です(1日はUTC時間で定義されます)。

request.utc-timestamp.time-of-day

説明: リクエストが認可のために受信された時刻。1日の特定の時間範囲のみアクセスを許可するポリシーを記述できます。時刻はUTCに基づいて計算されることに注意してください。サマータイムを実施しているタイム・ゾーンにいる場合は、時間が変更されたときにポリシーを更新する必要があります。

サポートされる演算子: between

許可される値: ISO 8601フォーマット(hh:mm:ssZ)のUTC時間間隔

値の例: '01:00:00Z' AND '2:01:00Z'

ポリシーの例: グループDayShiftが太平洋標準時(PST)の午前9:00と午後5:00の間にインスタンスおよび関連リソースを管理できるようにします。

時間はUTCに変換されることに注意してください:

Allow group DayShift to manage instance-family where request.utc-timestamp.time-of-day between '17:00:00Z' and '01:00:00Z'

グループNightShiftが午後5:00と午前9:00 (PST)の間にインスタンスおよび関連リソースを管理できるようにします。

Allow group NightShift to manage instance-family where request.utc-timestamp.time-of-day between '01:00:00Z' and '17:00:00Z'

これらの両方の例では、現在の時間が計算されてテストされ、指定された範囲内にあるかどうかが確認されます(どの日の時間であるかは無視されます)。