ポリシーの開始
開始するには、まずポリシーを開始するかどうか、またどのように開始するかを決定し、ポリシーに関する一般的な質問をよく理解してください。
IAMポリシーを初めて使用する場合、このトピックで続行方法のガイダンスを提供します。
概念実証を行う場合
インフラストラクチャ・リソースを使用して概念実証プロジェクトを作成します。
Oracle Cloud Infrastructureを試用する場合、またはインフラストラクチャ・リソースを使用して概念実証のプロジェクトを行う場合、すべての処理の完全なアクセス権を持つ管理者は多く必要ない可能性があります。その場合は、必要な新しいユーザーを作成して管理者グループに追加するだけです。ユーザーは、任意の種類のリソースですべての操作を実行できます。また、テナンシ(ルート・コンパートメント)に直接すべてのリソースを作成できます。まだコンパートメントを作成する必要はありません。また、テナント管理ポリシー以外の他のポリシーを作成する必要もありません。このポリシーはテナンシに自動的に付属し、変更できません。
新しいユーザーを管理者グループに追加することを忘れないでください。新規作成の後で見落としがちです。
概念実証フェーズを行った場合
概念実証フェーズ後のリソースへのアクセスを制限します。
概念実証フェーズを行った後に、リソースへのアクセスを制限する場合は、最初に次の手順を実行します。
- 基本的なIAMコンポーネントをよく理解していることを確認し、シナリオ例を参照してください: シナリオ例
- リソースをコンパートメントに編成する方法を考慮してください: テナンシを設定するためのベスト・プラクティスについて学習
- ポリシーの仕組みの基本事項について学習します:ポリシーの仕組み
- 一般的なポリシーを確認します:共通ポリシー
- 詳細は、次の項を参照してください
ポリシーの詳細
ポリシーの詳細
それらすべて(IAM自体を含む)。ポリシー・リファレンスで、各サービスのポリシーを記述するための特定の詳細を確認できます。
はい。すべてのユーザーは、明示的なポリシーなしで自動的にこれらの操作を実行できます。
- 自分のコンソール・パスワードを変更またはリセットします。
- 独自のAPI署名キーおよびその他の資格証明を管理します。
すべてのリソースを単一のコンパートメントに配置し、ポリシーを使用してアクセスを制御することもできますが、使用および請求をコンパートメント別に測定するメリットや、コンパートメント・レベルで単純なポリシー管理を実施するメリット、さらにプロジェクトまたはビジネス・ユニット間でリソースを明確に分離するメリットがなくなります。
はい。ただし、最初に知る必要があることがいくつかあります。
- エンタープライズ企業には通常、同様の権限を必要とする複数のユーザーがいるため、ポリシーは個々のユーザーではなく、ユーザーのグループにアクセスを付与するように設計されています。ユーザーは、グループに所属してアクセスを取得します。
- ポリシーはアクセスを許可するように設計されており、ポリシーの書込み時に明示的な「拒否」はありません。
特定のユーザーにアクセス権を付与する必要がある場合は、変数でユーザーのOCIDを指定する条件をポリシーに追加できます。この構成では、ポリシーで付与するアクセスを、条件内で指定したユーザーのみに制限します。例:
allow any-group to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'ポリシーでの条件および変数の使用の詳細は、条件を参照してください。
特定のユーザーのアクセスを制限する必要がある場合は、次のことが可能です。
- 対象となる特定のグループからユーザーを削除します
- IAMからユーザーを完全に削除します(ユーザーをすべてのグループから最初に削除する必要があります)
最初に、ユーザーがどのグループにも属していないことを確認します。その場合のみ、ユーザーを削除できます。
コンパートメントの削除を参照してください。
どのステートメントがどのグループに適用されるかを確認するには、すべてのポリシーで個々のステートメントを確認する必要があります。現在、この情報を簡単に取得する方法はありません。
特定のコンパートメントに適用されるかどうかを確認するには、テナンシのすべてのポリシーの個々のステートメントを参照する必要があります。また、コンパートメント自体のポリシーも参照する必要があります。兄弟コンパートメントのポリシーは、対象のコンパートメントを参照できないため、これらのポリシーを確認する必要はありません。
ポリシーの理解
IAMでは、ポリシーを使用してリソースへのアクセスを制限します。
デフォルトでは、ポリシーはテナンシ・レベルで存在し、アイデンティティ・ドメインに適用できます。特定のリソースへのアクセスを制限するなど、スコープが小さいポリシーを作成することもできます。ポリシーの仕組みを参照してください。
シナリオ例
様々なIAMコンポーネントの連携方法を示す例。
このシナリオの目的は、様々なIAMコンポーネントの連携方法、およびポリシーの基本機能を示すことです。
このシナリオで、Acme社には、Project AとProject BというインフラストラクチャのOracle Cloud Infrastructureリソースを使用するチームが2つあります。現実的には、会社にさらに多くのチームがある可能性があります。
Acme社では両方のチームに1つの仮想クラウド・ネットワーク(VCN)の使用を計画しており、ネットワーク管理者がVCNを管理する必要があるとします。
また、Acme社では、Project AチームとProject Bチームがそれぞれ独自のインスタンス・セットとブロック・ストレージ・ボリュームを持つことを望んでいます。Project AチームおよびProject Bチームが相互のインスタンスを使用できないようにします。これら2つのチームがネットワーク管理者によって設定されたVCNに関する変更も許可できないようにします。Acme社では、各チームにそのチームのリソースの管理者を任せることを望んでいます。Project Aチームの管理者は、Project Aクラウド・リソースを使用できるユーザーとその方法を決定できます。プロジェクトBチームも同じです。
Acme社でのOracle Cloud Infrastructureの開始
Acme社は、Oracle Cloud Infrastructureを使用するためにサインアップし、Wenpeiという従業員がデフォルトの管理者になることをOracleに伝えます。レスポンスとして、Oracleは次の処理を実行します。
- Acme社のテナンシを作成します(次の図を参照)。
- テナンシにWenpeiのIAMユーザー・アカウントを作成します。
- テナンシに管理者グループを作成し、そのグループにWenpeiを配置します。
- テナンシのすべてのリソースを管理するための管理者グループ・アクセスを付与するAcme社のテナンシのポリシーを作成します。そのポリシーは次のとおりです。
Allow group Administrators to manage all-resources in tenancy
デフォルト管理者は、いくつかのグループおよび別の管理者を作成します
次にWenpeiは、複数のグループとユーザーを作成します(次の図を参照)。次の処理を実行します。
- NetworkAdmins、A-AdminsおよびB-Adminsというグループを作成します(後の2つは、社内のProject AおよびProject B用です)
- Alexという名前のユーザーを作成し、管理者グループに入れます。
- 新しいグループを空のままにします。
グループの作成方法を学習するには、グループの管理を参照してください。ユーザーを作成してグループに配置する方法を学習するには、ユーザーの管理を参照してください。
デフォルト管理者は、コンパートメントとポリシーをいくつか作成します
次にWenpeiは、リソースをグループ化するためのコンパートメントを作成します(次の図を参照)。次の処理を実行します。
- Networksというコンパートメントを作成します。Acme社のVCN、サブネット、サイト間VPNおよびネットワーキングの他のコンポーネントへのアクセスを制御します。
- Project-Aというコンパートメントを作成します。Project Aチームのクラウド・リソースを整理し、それらに対するアクセスを制御します。
- Project-Bというコンパートメントを作成します。Project Bチームのクラウド・リソースを整理し、それらに対するアクセスを制御します。
コンパートメントの管理方法を学習するには、コンパートメントの管理を参照してください。
次にWenpeiは、各コンパートメントの管理者に必要なアクセス・レベルを付与するポリシーを作成します。テナンシにポリシーをアタッチします。これは、テナンシ内のポリシーを管理するためのアクセス権を持つユーザーのみが、後でポリシーを更新または削除できることを意味します。このシナリオでは、これは管理者グループのみです。ポリシーには次のステートメントが含まれます。
- Networksコンパートメントのネットワークおよびインスタンスを管理するためのグループ・アクセス権をNetworkAdminsに付与します(ネットワークを簡単にテストするため)
- A-AdminsおよびB-Adminsグループの両方に、Networksコンパートメント内のネットワークを使用するためのアクセス権を付与します(ネットワークにインスタンスを作成できるようにします)。
- Project-Aコンパートメント内のすべてのリソースを管理するためのグループ・アクセス権をA-Adminsに付与します。
- Project-Bコンパートメント内のすべてのリソースを管理するためのグループ・アクセス権をB-Adminsに付与します。
ポリシーの外観は次のとおりです(複数のステートメントが含まれていることに注意してください)。
Allow group NetworkAdmins to manage virtual-network-family in compartment Networks
Allow group NetworkAdmins to manage instance-family in compartment Networks
Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks
Allow group A-Admins to manage all-resources in compartment Project-A
Allow group B-Admins to manage all-resources in compartment Project-B
動詞(manage, use)とリソース(virtual-network-family, instance-family, all-resources)の違いに注意してください。これらの詳細は、動詞およびリソース・タイプを参照してください。ポリシーの作成方法を学習するには、ポリシーの作成を参照してください。
A-AdminsおよびB-Adminsは、コンパートメントNetworksでvirtual-network-familyを使用できます。ただし、そのコンパートメントにインスタンスを作成することはできません。Project-AまたはProject-Bのコンパートメントにのみインスタンスを作成できます。なお、コンパートメントは物理グループではなく論理グループであるため、同じVCNに構成されているリソースは別のコンパートメントに属することができます。
Acme社では、Project-AおよびProject-Bコンパートメントの管理者がこれらのコンパートメントのリソースを使用できるユーザーを決定することを望んでいます。そのため、Wenpeiは、さらに2つのグループ(A-UsersとB-Users)を作成します。次に、これらのグループに対してユーザーを追加および削除するために必要なアクセス権をコンパートメント管理者に付与する、6つのステートメントを追加します。
Allow group A-Admins to use users in tenancy where target.group.name='A-Users'
Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'
Allow group B-Admins to use users in tenancy where target.group.name='B-Users'
Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'
Allow group A-Admins,B-Admins to inspect users in tenancy
Allow group A-Admins,B-Admins to inspect groups in tenancyこのポリシーでは、プロジェクト管理者が新規ユーザーを作成したり、ユーザーの資格証明を管理することはできません。A-UsersグループやB-Usersグループに割り当てることができる既存ユーザーを決定できます。最後の2つのステートメントは、A-AdminsおよびB-Adminsがすべてのユーザーおよびグループをリストし、どのユーザーがどのグループに属しているかを確認するために必要です。
| 項目 | 説明 |
|---|---|
 |
テナンシにアタッチされているポリシー:
|
管理者が新規ユーザーを作成します
この時点で、Alexは管理者グループに属し、新しいユーザーを作成するためのアクセス権があります。そのため、Leslie、JorgeおよびCheriという名前のユーザーをプロビジョニングし、NetworkAdmins、A-AdminsおよびB-Adminisグループにそれぞれ配置します。Alexは、Project AとProject Bの管理者によって最終的にA-UsersおよびB-Usersグループに配置される他のユーザーも作成します。
| 項目 | 説明 |
|---|---|
|
テナンシにアタッチされているポリシー:
|
ネットワーク管理者がネットワークを設定します
Leslie(NetworkAdminsグループ)は、Networksコンパートメント内のvirtual-network-familyおよびinstance-familyを管理するためのアクセス権を持ちます。そのコンパートメントに単一のサブネットを持つ仮想クラウド・ネットワーク(VCN)を作成します。また、VCN用のインターネット・ゲートウェイを設定し、VCNのルート表を更新して、そのゲートウェイを経由するトラフィックを許可します。VCNのオンプレミス・ネットワークへの接続をテストするには、VCNのサブネットのインスタンスを起動します。起動リクエストの一部として、インスタンスを配置するコンパートメントを指定する必要があります。唯一アクセス権を持つNetworksコンパートメントを指定します。次に、オンプレミス・ネットワークからSSHを介してインスタンスにログインし、オンプレミス・ネットワークからVCNへの接続を確認します。
Leslieはテスト・インスタンスを終了し、JorgeとCheriに、VCNが稼働していて試行できることを知らせます。使用するコンパートメントがProject-AおよびProject-Bという名前であることを伝えます。クラウド・ネットワークの設定の詳細は、ネットワーキングを参照してください。ネットワークへのインスタンスの起動の詳細は、コンピュートを参照してください。
コンパートメント管理者がコンパートメントを設定します
JorgeとCheriは、それぞれのコンパートメントを設定する必要があります。各管理者は、次の処理を実行する必要があります。
- 自分のコンパートメント内のインスタンスを起動します
- ユーザーを自分のユーザー・グループ(A-Usersなど)に配置します
- これらのユーザーに付与するアクセスのタイプを決定し、それに応じてポリシーをコンパートメントにアタッチします
JorgeとCheriは、VCNのサブネットにインスタンスを起動し、それぞれのチームのコンパートメントに配置します。インスタンスにブロック・ボリュームを作成し、アタッチします。コンパートメント管理者のみが、各チームのコンパートメントで、インスタンスを起動/終了したり、ブロック・ボリュームをアタッチ/デタッチしたりできます。
ネットワーク・トポロジおよびコンパートメントのアクセスの概念が異なります
VCNのネットワーク・トポロジと、コンパートメントが提供するアクセス制御との違いを理解することが重要です。Jorgeが起動したインスタンスは、ネットワーク・トポロジの観点からVCNに配置されます。ただし、アクセスの観点からは、VCNが配置されるNetworksコンパートメントではなく、Project-Aコンパートメントにあります。Leslie(Networks管理者)は、Jorgeのインスタンスを終了または再起動したり、Project-Aコンパートメントに新しいインスタンスを起動したりできません。しかし、Leslieはインスタンスのネットワークを制御するため、トラフィックのルーティング先を制御します。インスタンスの起動時にJorgeがProject-AコンパートメントではなくNetworksコンパートメントを指定した場合、リクエストが拒否されます。CheriおよびProject-Bコンパートメントの場合も同様です。
ただし、管理者グループのWenpeiおよびAlexは、テナンシのすべてのリソースを管理するためのアクセス権を持っているため、コンパートメント内のリソースにアクセスできることにも注意してください。コンパートメントは、親コンパートメント(テナンシ)にアタッチされたポリシーを継承するため、管理者アクセスはテナンシ内のすべてのコンパートメントにも適用されます。
次に、Jorgeは、Alexによって作成された複数のユーザーをA-Usersグループに配置します。Cheriは、B-Usersに対して同様の処理を行います。
次に、JorgeはProject-Aコンパートメントで必要とするアクセス・レベルをユーザーに付与するポリシーを書き込みます。
Allow group A-Users to use instance-family in compartment Project-A
Allow group A-Users to use volume-family in compartment Project-A
Allow group A-Users to inspect virtual-network-family in compartment Networks
これにより、コンパートメント管理者がすでにコンパートメントで起動している既存のインスタンス(アタッチされたブロック・ボリュームを含む)を使用し、それらを停止/起動/再起動できます。A-Usersによる任意のボリュームの作成/削除またはアタッチ/デタッチを行うことはできません。この機能を提供するには、manage volume-familyをポリシーに含める必要があります。
Jorgeは、このポリシーをProject-Aコンパートメントにアタッチします。コンパートメント内のポリシーを管理できるユーザーは、このポリシーを変更または削除できるようになりました。現在は、A-Adminsグループ(およびテナンシ全体のすべての操作を実行できる管理者グループ)のみです。
Cheriは、Jorgeのポリシーと同様に、Project-Bコンパートメントに独自のポリシーを作成してアタッチします。
Allow group B-Users to use instance-family in compartment Project-B
Allow group B-Users to use volume-family in compartment Project-B
Allow group B-Users to inspect virtual-network-family in compartment Networks
これで、A-UsersとB-Usersはそれぞれ、Project-AとProject-Bコンパートメントの既存のインスタンスとアタッチされたボリュームを使用できます。レイアウトは次のようになります。
| 項目 | 説明 |
|---|---|
|
テナンシにアタッチされているポリシー:
|
 |
Jorgeによってアタッチおよび管理されるポリシー:
|
 |
Cheriによってアタッチおよび管理されるポリシー:
|
ポリシーの基本機能および拡張機能の詳細は、ポリシーの仕組みを参照してください。組織で使用できるその他の一般的なポリシーの例は、共通ポリシーを参照してください。
バックアップ管理者がバックアップのみを管理できるようにします。
アクセス・タイプ:ボリューム・バックアップのすべての操作を実行する機能。ボリューム自体の作成や管理はできません。これは、単一セットのボリューム・バックアップ管理者がすべてのコンパートメントのすべてのボリューム・バックアップを管理する場合に意味を持ちます。最初のステートメントは、バックアップされるボリュームに必要なアクセスを付与し、2番目のステートメントではバックアップの作成(およびバックアップの削除)が可能です。3番目のステートメントでは、ユーザー定義のバックアップ・ポリシーの作成と管理が可能です。4番目のステートメントでは、バックアップ・ポリシーの割当ておよび削除が可能です。
ポリシーを作成する場所:ポリシー継承を介してすべてのコンパートメントにアクセス権が容易に付与されるようにするため、テナンシ。特定のコンパートメント内のボリュームおよびバックアップのみにアクセス範囲を減らすには、テナンシのかわりにそのコンパートメントを指定します。
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancyグループがコンソールを使用する場合、次のポリシーによりユーザー・エクスペリエンスが向上します。
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancy最後の2つのステートメントは、ボリューム・バックアップを管理するために必要ありません。ただし、コンソールで特定のボリュームに関するすべての情報および使用可能なバックアップ・ポリシーを表示できます。
ポリシー・アタッチメント
ポリシー・アタッチメント
ポリシーの別の基本機能として、アタッチメントの概念があります。ポリシーを作成する場合、それをコンパートメント(またはルート・コンパートメントであるテナンシ)にアタッチする必要があります。アタッチされた先の対象によって、だれが次に変更または削除できるか、が制御されます。これをテナンシにアタッチする場合(つまり、ポリシーがルート・コンパートメント内にある場合)、テナンシのポリシーを管理するアクセス権を持つユーザーは、ポリシーを変更または削除できます。通常は、管理者グループまたはユーザーが作成して幅広いアクセス権を付与する類似グループです。子コンパートメントへのアクセス権のみを持つユーザーは、そのポリシーを変更または削除できません。
かわりに子コンパートメントにポリシーをアタッチすると、そのコンパートメント内のポリシーを管理するアクセス権を持つユーザーはポリシーを変更または削除できます。実際的な観点から、これは、テナンシに存在するポリシーを管理するためのより広範囲のアクセス権を付与する必要がないため、コンパートメント管理者(コンパートメントのmanage all-resourcesへのアクセス権を持つグループ)に自身のコンパートメントのポリシーを管理するアクセス権を付与すると容易であることを意味します。この種類のコンパートメント管理者設計を使用する例は、シナリオ例を参照してください。(ポリシー継承により、テナンシ内のポリシーを管理するアクセス権を持つユーザーは、自動的にテナンシ内のコンパートメントのポリシーを管理できることに注意してください。)
ポリシーをアタッチするプロセスは簡単です(コンパートメントまたはテナンシにアタッチするかに関係なく)。コンソールを使用していて、ポリシーをIAMに追加する場合、ポリシー作成時に必要なコンパートメントにいることを確認してください。APIを使用している場合は、ポリシーを作成するリクエストの一部として、必要なコンパートメント(テナンシまたは他のコンパートメント)のOCIDを指定します。
ポリシーをコンパートメントにアタッチする場合、そのコンパートメントにいる必要があり、かつ適用先のコンパートメントをステートメントで直接示している必要があります。コンパートメントにいない場合、ポリシーを別のコンパートメントにアタッチしようとするとエラーが表示されます。ポリシーの作成中にアタッチメントが発生します。つまり、ポリシーは1つのコンパートメントにのみアタッチできます。コンパートメントへのポリシーのアタッチ方法を学習するには、ポリシーの作成を参照してください。