Oracle Cloud Infrastructureドキュメント

Oracle Cloud Infrastructure 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資格証明があります(「ユーザーの資格証明」を参照)。
グループ
特定のセットのリソースまたはコンパートメントに対して同じタイプのアクセスがすべて必要なユーザーの集まり。
動的グループ
定義したルールに一致するリソース(コンピュート・インスタンスなど)を含む特殊なタイプのグループ(一致するリソースが作成または削除されると、メンバーシップは動的に変更される場合があります)。 これらのインスタンスは、主体のアクターとして機能し、動的グループに対して記述するポリシーに従ってサービスを呼び出すことができます。
コンパートメント
関連リソースの集まり。 コンパートメントは、クラウド・リソースを整理し隔離するためのOracle Cloud Infrastructureの基本コンポーネントです。 使用と課金の測定、アクセス(ポリシーの使用による)、および分離(あるプロジェクトまたはビジネス・ユニットのリソースを別のプロジェクトやユニットから分離する)の目的でリソースを明確に分離するために使用します。 一般的なアプローチは、組織の主要部分ごとにコンパートメントを作成することです。 詳細は、「あなたのテナンシを設定」を参照してください。
テナンシ
allof組織のOracle Cloud Infrastructureリソースを含むルート・コンパートメント。 オラクルは自動的に会社のテナンシを作成します。 テナンシの中には、IAMエンティティ(ユーザー、グループ、コンパートメント、およびいくつかのポリシー、また、テナンシ内のコンパートメントにポリシーを入れることもできます)があります。 作成するコンパートメントには、他のタイプのクラウド・リソース(インスタンス、仮想ネットワーク、ブロック・ストレージ・ボリュームなど)を配置します。
ポリシー
どのリソースに誰がアクセスできるかを指定するドキュメント。 アクセスはグループとコンパートメントのレベルで許可されます。つまり、グループに特定のコンパートメント内の特定のタイプのアクセス、またはテナンシ自体にポリシーを与えることができます。 グループにテナンシへのアクセス権を付与すると、そのグループは自動的にテナンシ内のすべてのコンパートメントに同じタイプのアクセス権を取得します。 詳細は、「シナリオの例」および「ポリシーの仕組み」を参照してください。 ポリシーという言葉は、人々によってさまざまな方法で使用されています: ポリシー言語で書かれた個々のステートメントを意味します。単一の名前付き"ポリシー"文書(Oracle Cloud ID (OCID)が割り当てられている)内のステートメントの集合を意味します。組織がリソースへのアクセスを制御するために使用するポリシー全体を意味します。
ホーム・リージョン
IAMリソースが存在するリージョン。 すべてのIAMリソースはグローバルであり、すべてのリージョンで使用できますが、マスター定義セットは単一のリージョン、ホーム・リージョンにあります。 ホーム・リージョンのIAMリソースを変更する必要があります。 変更は自動的にすべてのリージョンに反映されます。 詳細は、「リージョンの管理」を参照してください。
フェデレーション
管理者がアイデンティティ・プロバイダとサービス・プロバイダ間で構成する関係。 Oracle Cloud Infrastructureをidプロバイダとともにフェデレートすると、そのidプロバイダのユーザーとグループを管理します。 Oracle Cloud Infrastructure IAMサービスで認可を管理します。 Oracle Cloud Infrastructureのテナンシは、デフォルトでOracle Identity Cloud Serviceでフェデレートされます。

アクセスを制御できるサービス

Oracle Cloud Infrastructure内のすべてのservicesへのアクセスを制御するポリシーを記述することができます。

管理者グループとポリシー

会社がOracleアカウントとアイデンティティ・ドメインにサインアップすると、Oracleはそのアカウントの「デフォルト管理者」を設定します。 この人物は会社の最初のIAMユーザーになり、最初は追加の管理者を設定する責任があります。 テナンシには「管理者」というグループがあり、デフォルト管理者は自動的にこのグループに属します。 このグループは削除できません。また、少なくとも1人のユーザーが常に存在する必要があります。

テナンシには、管理者グループにOracle Cloud Infrastructure API操作のすべて、およびテナンシ内のすべてのクラウド・リソースへのアクセス権を与えるポリシーも自動的に付与されます。 このポリシーは変更も削除もできません。 Administratorsグループに入れた他のユーザーは、すべてのサービスにフル・アクセスできます。 これは、グループ、ポリシー、コンパートメントなどのIAMリソースを作成および管理できることを意味します。 また、仮想クラウド・ネットワーク(VCN)、インスタンス、ブロック・ストレージ・ボリューム、および今後利用可能になるその他の新しいタイプのOracle Cloud Infrastructureリソースなどのクラウド・リソースを作成および管理できます。

使用例

このシナリオの目的は、さまざまなIAMコンポーネントがどのように連携して動作するか、およびポリシーの基本機能を示すことです。

このシナリオでは、Acme社に、インフラストラクチャに対してOracle Cloud Infrastructure Resourceを使用するチームが2つあります: プロジェクトAとプロジェクトB。 現実には、会社はもっと多くを持っているかもしれません。

Acme Companyは、両方のチームに単一の仮想クラウド・ネットワーク(VCN)を使用する予定であり、ネットワーク管理者がVCNを管理することを望んでいます。

Acme社は、プロジェクトAチームとプロジェクトBチームを、eachにそれぞれインスタンスおよびブロック・ストレージ・ボリュームのセットがあります。 プロジェクトAチームおよびプロジェクトbチームは、他の各インスタンスを使用できません。 これらの2つのチームは、ネットワーク管理者が設定したVCNについて何も変更することを許可すべきではありません。 Acme Companyは、各チームにそのチーム・リソースの管理者が必要です。 プロジェクトAチームの管理者は、誰がプロジェクトAクラウド・リソースを使用できるのか、またその方法を決定できます。 プロジェクトBチームと同じです。

Acme CompanyがOracle Cloud Infrastructureで始まる

Acme CompanyはOracle Cloud Infrastructureを使用するようにサインアップし、Wenpeiという名前の従業員がデフォルト管理者であることをOracleに伝えます。 これに応じて、Oracleは次の内容を実施します:

  • Acme Companyのテナンシを作成します(次の図を参照)。
  • テンションでWenpeiのIAMユーザー・アカウントを作成します。
  • テナンシに管理者グループを作成し、そのグループにWenpeiを配置します。
  • 管理者グループにテナンシ内のすべてのリソースを管理するためのアクセス権を与えるAcme Companyテナンシにポリシーを作成します。 その方針は次のとおりです:
Allow group Administrators to manage all-resources in tenancy

このイメージは、初期グループ、ユーザー、およびポリシーによるテナンシを示しています。

デフォルトの管理者がいくつかのグループと別の管理者を作成

Wenpeiは次にいくつかのグループとユーザーを作成します(次の図を参照)。 :

  • NetworkAdminsA-Admins、およびB-Adminsという名前のグループを作成します(最後の2つは、会社内のプロジェクトAとプロジェクトBの2つです)
  • Alexというユーザーを作成し、管理者グループに配置します。
  • 新しいグループを空のままにします。

グループの作成方法については、「グループの操作」を参照してください。 ユーザーを作成してグループに入れる方法については、「ユーザーの操作」を参照してください。

このイメージは、ユーザーとグループをさらに追加して、前のイメージに基づいています。

デフォルトの管理者がいくつかのコンパートメントとポリシーを作成

Wenpeiは次に、リソースをグループ化するためのコンパートメントを作成します(次の図を参照)。 :

  • 「ネットワーク」というコンパートメントを作成して、Acme社のVCN、サブネット、IPSec VPN、およびその他のコンポーネントへのNetworkingからのアクセスを制御します。
  • Project-Aという名前のコンパートメントを作成して、Project Aのチーム・クラウド・リソースを整理し、それらのリソースへのアクセスを制御します。
  • Project-Bというコンパートメントを作成して、プロジェクトBのチーム・クラウド・リソースを編成し、それらのリソースへのアクセスを制御します。

コンパートメントを管理する方法については、「コンパートメントの操作」を参照してください。

Wenpeiは、各コンパートメントの管理者に必要なアクセス・レベルを与えるポリシーを作成します。 彼女はこのポリシーをテナンシに付加します。つまり、テナンシ内のポリシーを管理するためのアクセス権を持つユーザーだけが、ポリシーを後で更新または削除できます。 このシナリオでは、それはAdministratorsグループだけです。 このポリシーには以下の複数のステートメントが含まれます:

  • NetworkAdminsグループにアクセスして、ネットワーク・コンパートメントでネットワークとインスタンスを管理する(ネットワークのテストを容易にするため)
  • A-管理者およびb -管理グループは、ネットワーク・コンパートメント内のネットワークを使用するためにアクセス権を付与します(この場合、ネットワークにインスタンスを作成できます)。
  • A-Adminsグループにアクセスして、Project-Aコンパートメント内のすべてのリソースを管理します。
  • B-Adminsグループにアクセスして、Project-Bコンパートメント内のすべてのリソースを管理します。

そのポリシーは次のようになります(複数のステートメントがあることに注意してください):

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)の違いに注目してください。 それらの詳細については、「動詞」Resource-Types.Toを参照してください。ポリシーの作成方法については、「ポリシーを作成するには」を参照してください。

重要

A-管理者およびB-管理者は、コンパートメント・ネットワーク内で仮想ネットワーク・ファミリを「使用」できます。
ただし、そのコンパートメントにはインスタンスを作成できません。 プロジェクト-Aまたはプロジェクト-Bコンパートメントでのみインスタンスを作成できます。 コンパートメントは物理グループではなく論理グループであるため、同じVCNに稼働または存在するリソースは別のコンパートメントに属することができます。

Acme Companyは、Project-AおよびProject-Bコンパートメントの管理者が、どのユーザーがそれらのコンパートメント内のリソースを使用できるかを決定させたいと考えています。 Wenpeiはさらに2つのグループを作成: AユーザーとBユーザー。 次に、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

このポリシーによって、プロジェクト管理者createの新規ユーザーを管理したり、ユーザーの資格証明を管理したりできないことに注意してください。 既存のユーザーをAユーザーとBユーザーのグループに入れることができます。 最後の2つのステートメントは、A-AdminsとB-Adminsがすべてのユーザーとグループを一覧表示し、どのユーザーがどのグループにいるかを確認するために必要です。

このイメージは、コンパートメントとポリシー・ステートメントを追加することで前のイメージに基づいて作成されます。

管理者が新しいユーザーを作成

この時点で、AlexはAdministratorsグループに属しており、新しいユーザーの作成にアクセスできるようになりました。 そこで、Leslie、Jorge、Cheriという名前のユーザーをプロビジョニングし、それぞれNetworkAdmins、A-Admins、およびB-Adminsグループに配置します。 Alexは、プロジェクトAとプロジェクトBの管理者によって最終的にAユーザーとBユーザー・グループに入れられる他のユーザーも作成します。

このイメージは、新しいユーザーを追加してグループに入れることで、前のイメージに基づいています。

ネットワーク管理者がネットワークを設定

Leslie (NetworkAdminsグループ内)は、ネットワーク・コンパートメント内のvirtual-network-familyinstance-familyを管理するためのアクセス権を持っています。 彼女はそのコンパートメントに単一のサブネットを持つ仮想クラウド・ネットワーク(VCN)を作成します。 また、VCNのインターネット・ゲートウェイを設定し、そのゲートウェイ経由でトラフィックを許可するようにVCNルート表を更新します。 オンプレミス・ネットワークへのVCN接続をテストするために、VCNのサブネットでインスタンスを起動します。 起動リクエストの一環として、インスタンスがどのコンパートメントに存在するかを指定する必要があります。 彼女はアクセスできる唯一のネットワーク・コンパートメントを指定します。 その後、オンプレミス・ネットワークからSSH経由でインスタンスにログインして、オンプレミス・ネットワークからVCNへの接続を確認します。

Leslieはテスト・インスタンスを終了し、VCNが起動し、試用する準備ができていることをJorgeとCheriに知らせます。 彼女は彼らのコンパートメントがそれぞれProject-AとProject-Bという名前であることを知らせます。 クラウド・ネットワークの設定の詳細については、「Networkingの概要」を参照してください。 インスタンスをネットワークに起動する方法については、「Computeサービスの概要」を参照してください。

コンパートメント管理者がコンパートメントを設定

ホルヘとチェリは、それぞれのコンパートメントを設定する必要があります。 各管理者は次のことを行う必要があります:

  • 独自のコンパートメントでインスタンスを起動
  • ユーザーをユーザー・グループに入れる(例:A-Users)
  • これらのユーザーにアクセスするためのアクセスのタイプを決定し、それに応じてそのコンパートメントにポリシーをアタッチ

JorgeとCheriはともに、インスタンスをVCNのサブネットに、それぞれのチーム・コンパートメントに起動します。 ブロック・ボリュームを作成してインスタンスに付加します。 コンパートメント管理者だけがインスタンスを起動/終了したり、それぞれのチーム・コンパートメント内のブロック・ボリュームをアタッチ/デタッチできます。

重要

ネットワーク・トポロジとコンパートメント・アクセスは異なる概念です

VCNのネットワーク・トポロジとコンパートメントが提供するアクセス制御の違いを理解することが重要です。 Jorgeが立ち上げたインスタンスは、ネットワーク・トポロジの観点からVCNに常駐しています。 しかし、アクセスの観点からは、VCNがあるネットワーク・コンパートメントではなく、Project-Aコンパートメントにあります。 Leslie (ネットワーク管理者)は、Jorgeインスタンスを終了したり再起動したり、Project-Aコンパートメントに新しいインスタンスを起動することはできません。 しかしLeslieはインスタンス・ネットワークを制御しているので、どのトラフィックがそれらにルーティングされるかを制御します。 インスタンスを起動するときにJorgeがProject-Aコンパートメントの代わりにNetworksコンパートメントを指定していた場合、そのリクエストは拒否されていました。 この話はCheriとProject-Bコンパートメントの場合も同様です。

しかし、Administratorsグループの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

これにより、コンパートメント管理者がすでにコンパートメントで起動している既存のインスタンス(ブロック・ボリューム付き)を使用して、stop/start/rebootを使用できます。 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ユーザーとBユーザーは、Project-AコンパートメントとProject-Bコンパートメントの既存のインスタンスとアタッチされたボリュームでそれぞれ作業できます。 レイアウトは次のようになります:

このイメージは、いくつかのコンパートメントのポリシー・ステートメントを追加することによって、前のイメージに基づいて構築されています。

ポリシーの基本機能と高度機能の詳細については、「ポリシーの仕組み」を参照してください。 組織で使用されるその他の一般的なポリシーの例については、「共通ポリシー」を参照してください。

コンソールのコンパートメント別にリソースを表示

コンソールでは、クラウド・リソース「コンパートメントごと」を表示します。 これは、コンソールにサインインした後で、作業するコンパートメントを選択することになります(ページの左側にアクセスできるコンパートメントのリストがあります)。 コンパートメントは他のコンパートメント内にネストできます。 ページが更新され、現在のリージョン内にあるコンパートメント・リソースが表示されます。 存在しない場合、またはコンパートメント内のリソースにアクセスできない場合は、メッセージが表示されます。

このようなエクスペリエンスは、ユーザー、グループ、動的グループおよびフェデレーション・プロバイダのリストを表示しているときで異なります。 それらは、個々のコンパートメントではなく、テナンシ自体(ルート・コンパートメント)に存在します。

ポリシーに関しては、ポリシー「アタッチされています」の場所に応じて、テナンシまたはコンパートメントのいずれかに配置できます。 それがアタッチされている場所は、それを変更または削除するアクセス権を持つユーザーを制御します。 詳細は、「ポリシー・アタッチメント」を参照してください。

IAMリソースの範囲

Oracle Cloud Infrastructureは、リージョンと可用性ドメインの概念を使用します(「リージョンと可用性ドメイン」を参照)。 一部のリソースはリージョン的に利用可能ですが、その他のリソースは特定の「可用性ドメイン」内でのみ利用可能です。 IAMリソース(ユーザー、グループ、ダイナミック・グループ、コンパートメント、タグ・ネームスペース、フェデレーション・プロバイダ、ポリシー)はすべてのリージョンでグローバルに使用できます。 「リージョンの管理」を参照してください。

リソース識別子

ほとんどのタイプのOracle Cloud Infrastructureリソースには、Oracle Cloud ID (OCID)という名前の一意のOracle割当て識別子があります。 OCID形式およびリソースを識別するその他の方法については、「リソース識別子」を参照してください。

Oracle Cloud Infrastructureにアクセスする方法

コンソール (ブラウザベースのインタフェース)またはREST APIを使用して、Oracle Cloud Infrastructureにアクセスできます。 コンソールおよびAPIの手順は、このガイドのトピックに含まれています。 使用可能なSDKのリストについては、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

コンソールにアクセスするには、「サポートされているブラウザ」を使用する必要があります。 このページの上部にあるコンソールリンクを使用して、サインイン・ページにアクセスできます。 クラウド・テナント、ユーザー名、およびパスワードを入力するよう求められます。

APIの使用に関する一般的な情報は、REST APIを参照してください。

IAMリソースの制限

適用可能な制限の一覧と制限の増加をリクエストする手順については、「サービス制限」を参照してください。