Identity and Access Managementの概要
Oracle Cloud Infrastructure Identity and Access Management (IAM)では、クラウド・リソースにアクセスできるユーザーを制御できます。ユーザー・グループおよび特定のリソースに付与するアクセス権のタイプを制御できます。この項では、IAMのコンポーネントとシナリオ例の概要を説明し、それらがどのように動作するかを理解します。
このドキュメントでは、IAMを使用するためにアクセス権を持つ社内の管理者を含めて対象ユーザーとしています。
IAMコンポーネント
IAMでは、この項で説明するコンポーネントが使用されます。コンポーネントがどのように適合するかをより深く理解するには、シナリオ例を参照してください。
- リソース
- Oracle Cloud Infrastructureと対話する際に、企業の従業員が作成して使用するクラウド・オブジェクト。たとえば、コンピュート・インスタンス、ブロック・ストレージ・ボリューム、仮想クラウド・ネットワーク(VCN)、サブネット、ルート表などがあります。
- ユーザー
- 会社のOracle Cloud Infrastructureリソースを管理または使用する必要がある個々の従業員またはシステム。ユーザーには、インスタンスの起動、リモート・ディスクの管理、仮想クラウド・ネットワークの使用などが必要な場合があります。アプリケーションのエンド・ユーザーは、通常、IAMユーザーではありません。ユーザーには1つ以上のIAM資格証明があります(ユーザー資格証明を参照)。
- グループ
- 一連の特定のリソースまたはコンパートメントに同じアクセスのタイプが必要なすべてのユーザーの集合。
- 動的グループ
- 定義するルールに一致するリソース(コンピュート・インスタンスなど)を含む特別なタイプのグループ(このため、メンバーシップは、一致するリソースの作成または削除時に動的に変更される可能性があります)。これらのインスタンスは「プリンシパル」のアクターとして機能し、動的グループ向けに記述するポリシーに従ってサービスにAPIコールを行うことができます。
- ネットワーク・ソース
- テナンシ内のリソースへのアクセスが許可されたIPアドレスのグループ。IPアドレスは、パブリックIPアドレスか、テナンシ内のVCNからのIPアドレスです。ネットワーク・ソースの作成後、ネットワーク・ソース内のIPから発生したリクエストのみにアクセスを制限するポリシーを使用します。
- コンパートメント
- 関連するリソースの集まり。コンパートメントは、クラウド・リソースを編成および分離するためのOracle Cloud Infrastructureの基本コンポーネントです。使用と請求の測定、アクセス(ポリシーの使用による)、および分離(あるプロジェクトまたはビジネス・ユニットのリソースを別のプロジェクトまたはビジネス・ユニットと区別)のために、リソースを明確に区別するために使用できます。一般的な方法は、組織の主要部分ごとにコンパートメントを作成することです。詳細は、テナンシを設定するためのベスト・プラクティスについて学習を参照してください。
- テナンシ
- 組織のOracle Cloud Infrastructureリソースがすべて含まれるルート・コンパートメント。Oracleによって、会社のテナンシが自動的に作成されます。テナンシの中に、IAMエンティティ(ユーザー、グループ、コンパートメントおよびいくつかのポリシー)があります。また、テナンシ内のコンパートメントにポリシーを入れることもできます。作成するコンパートメント内に他のタイプのクラウド・リソース(インスタンス、仮想ネットワーク、ブロック・ストレージ・ボリュームなど)を配置します。
- ポリシー
- どのユーザーがどのリソースにアクセスできるか、およびその方法を指定するドキュメントです。アクセス権はグループ・レベルおよびコンパートメント・レベルで付与されるため、特定のコンパートメント内またはテナンシ自体への特定のアクセスのタイプをグループに付与するポリシーを記述できます。テナンシへのグループ・アクセス権を付与する場合、グループはテナンシ内のすべてのコンパートメントへの同じアクセスのタイプを自動的に取得します。詳細は、シナリオ例とポリシーの仕組みを参照してください。「ポリシー」の用法は様々です。ポリシー言語で記述された個々のステートメントを意味する場合、"policy"という名前の(Oracle Cloud ID (OCID)が割り当てられている)単一ドキュメント内のステートメントの集合を意味する場合、リソースへのアクセスを制御するために組織で使用されるポリシーの本文全体を意味する場合があります。
- ホーム・リージョン
- IAMリソースが存在するリージョン。すべてのIAMリソースはグローバルで、すべてのリージョンで使用できますが、定義のマスター・セットは、単一のリージョンであるホーム・リージョンにあります。ホーム・リージョン内のIAMリソースを変更する必要があります。変更は、すべてのリージョンに自動的に伝播されます。詳細は、リージョンの管理を参照してください。
- フェデレーション
- 管理者がアイデンティティ・プロバイダとサービス・プロバイダの間で構成する関係。Oracle Cloud Infrastructureをアイデンティティ・プロバイダとフェデレートする場合、アイデンティティ・プロバイダ内のユーザーとグループを管理します。Oracle Cloud InfrastructureのIAMサービスで認可を管理します。Oracle Cloud Infrastructureのテナンシは、デフォルトでOracle Identity Cloud Serviceとフェデレートされます。
アクセスを制御できるサービス
ポリシーを記述して、Oracle Cloud Infrastructure内のすべてのサービスへのアクセスを制御できます。
管理者グループおよびポリシー
会社がOracleアカウントおよびアイデンティティ・ドメインにサインアップすると、Oracleはアカウントのデフォルト管理者を設定します。このユーザーは、会社の最初のIAMユーザーとなり、管理者の追加設定を担当します。テナンシには管理者というグループが含まれ、デフォルト管理者はこのグループに自動的に所属します。このグループは削除できないため、常に少なくとも1人のユーザーが必要です。
また、テナンシには、管理者グループに対してすべてのOracle Cloud Infrastructure API操作およびテナンシ内のすべてのクラウド・リソースへのグループ・アクセス権を付与するポリシーも自動的に含まれます。このポリシーは変更も削除もできません。管理者グループにユーザーを配置した場合、そのユーザーはすべてのサービスに完全にアクセスできます。つまり、グループ、ポリシー、コンパートメントなどのIAMリソースの作成および管理が可能です。また、仮想クラウド・ネットワーク(VCN)、インスタンス、ブロック・ストレージ・ボリューム、および将来使用可能になるその他の新しいタイプのOracle Cloud Infrastructureリソースなどのクラウド・リソースを作成および管理できます。
シナリオ例
このシナリオの目的は、様々な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によってアタッチおよび管理されるポリシー:
|
ポリシーの基本機能および拡張機能の詳細は、ポリシーの仕組みを参照してください。組織で使用できるその他の一般的なポリシーの例は、共通ポリシーを参照してください。
コンソールでのコンパートメント別リソースの表示
コンソールで、クラウド・リソースをコンパートメント別に表示します。つまり、コンソールへのサインイン後、作業するコンパートメントを選択します(ページの左側にアクセス権のあるコンパートメントのリストがあります)。コンパートメントは他のコンパートメント内にネストできることに注意してください。ページが更新されて、現在のリージョン内のコンパートメントのリソースが表示されます。何も表示されない場合、またはそのコンパートメント内のリソースへのアクセス権がない場合は、メッセージが表示されます。
これは、ユーザー、グループ、動的グループおよびフェデレーション・プロバイダのリストを表示する場合で異なります。これらは個々のコンパートメント内ではなく、テナンシ自体(ルート・コンパートメント)に存在します。
ポリシーと同様に、これらは、ポリシーがアタッチされている場所に応じて、テナンシまたはコンパートメントのいずれかに配置できます。アタッチされている場所では、変更または削除するアクセス権があるユーザーを制御します。詳細は、ポリシー・アタッチメントを参照してください。
IAMリソースの範囲
Oracle Cloud Infrastructureは、リージョンとアベイラビリティ・ドメインの概念を使用します(リージョンおよび可用性ドメインを参照)。一部のリソースはリージョンで使用可能ですが、その他のリソースは特定の可用性ドメイン内でのみ使用可能です。IAMリソース(ユーザー、グループ、動的グループ、コンパートメント、タグ・ネームスペース、フェデレーション・プロバイダおよびポリシー)は、すべてのリージョンでグローバルに使用できます。リージョンの管理を参照してください。
イベントを使用した自動化の作成
イベント・タイプ、ルールおよびアクションを使用して、Oracle Cloud Infrastructureリソースに対する状態変更に基づいて自動化を作成できます。詳細は、イベントの概要を参照してください。
次のIAMリソースでイベントが発生します。
- 認証ポリシー
- 資格証明
- 動的グループ
- グループ
- アイデンティティ・プロバイダ
- 多要素認証のTOTPデバイス
- ポリシー
- ユーザー
リソース識別子
ほとんどのタイプのOracle Cloud Infrastructureリソースには、Oracle Cloud ID (OCID)と呼ばれるOracleによって割り当てられた一意の識別子があります。OCIDのフォーマットおよびリソースを識別するその他の方法の詳細は、リソース識別子を参照してください。
Oracle Cloud Infrastructureへのアクセス方法
Oracle Cloud Infrastructure (OCI)には、コンソール(ブラウザベースのインタフェース)、REST APIまたはOCI CLIを使用してアクセスできます。 コンソール、APIおよびCLIの使用手順は、このドキュメント全体のトピックに記載されています。使用可能なSDKのリストは、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
コンソールにアクセスするには、サポートされているブラウザを使用する必要があります。コンソールのサインイン・ページに移動するには、このページ上部のナビゲーション・メニューを開き、「インフラストラクチャ・コンソール」をクリックします。クラウド・テナント、ユーザー名およびパスワードの入力を求められます。
API使用についての一般情報は、REST APIを参照してください。
IAMリソースの制限
適用可能な制限のリストと制限の引上げをリクエストする手順は、サービス制限を参照してください。リソースまたはリソース・ファミリにコンパートメント固有の制限を設定するために、管理者は、コンパートメント割当てを使用できます。