IAMの主な概念は次のとおりです。

• コンパートメント - クラウド・リソースの論理コンテナ。アカウント内の管理者は、1つ以上のコンパートメントを作成し、アカウント内のリソースを整理および管理できます。以下のコンパートメントを使用できます。
• ルート・コンパートメント - アカウント内で最上位のコンパートメント。アカウントがプロビジョニングされると、ルート・コンパートメントが自動的に作成されます。
• ユーザー - 認証可能なエンティティ。ユーザーは、個人アカウントまたはマシン・アカウントのいずれかになります。各ユーザーのアカウントには、一意の名前とグローバルに一意の識別子が含まれています。ユーザーには、Webコンソールにアクセスするためのパスワードと、APIを介してサービスにアクセスするためのキーを付与できます。
• グループ - 一連のユーザー。グループは、アクセス管理を簡素化するために使用されます。たとえば、ソフトウェア開発者は「developers」グループのメンバーとしてグループ化することができ、コードの読み取り、書き込み、変更を行うことができます。1人のユーザーが複数のグループのメンバーになることもできます。
• ポリシー - 組織が保有しているOracle Cloud Infrastructureリソースにアクセスできるユーザーとその方法を指定したドキュメント。ポリシーは、ポリシー・ステートメントで構成されます。ポリシー・コーパスは、複数のポリシーで構成されます。

Oracle Cloud Infrastructure IAMを使用すると、すべてのOracle Cloud Infrastructureサービスの認証と承認に一元的なモデルを活用できます。Oracle IAMを使用すると、1人が1つのプロジェクトで作業しているケースから、多くのグループが同時に多くのプロジェクトで作業している大規模な組織にいたるまで、あらゆる規模の組織が1つのアカウント内でアクセス権限を簡単に管理できるようになります。リソースの管理と承認をアカウント・レベルまたはコンパートメント・レベルで実行でき、監査と請求も一元化できます。

Oracle IAMは、セキュリティの最小特権の原則を実施できるよう、ゼロから構築されています。デフォルトでは、新規ユーザーはリソースに対していかなるアクションも実行できないようになっています。管理者は、各ユーザーに対して適切なアクセス権限のみを付与できます。

Oracle Cloud Infrastructureは、Identity and Access Managementを介してネイティブに多要素認証（MFA）をサポートしています。さらに、連携ユーザーは、Oracle Identity Cloud ServiceまたはサポートされているMFA対応の任意のサードパーティIDプロバイダを介して、MFAで認証できます。

はい。監査とコンプライアンスに関するエンタープライズの要件に対応するため、すべての変更は記録され、追加料金なしで利用できます。

デフォルトで、Oracle IAMは追加料金なしで有効化されています。アカウントの最初のユーザーがデフォルトの管理者です。以降のすべてのユーザーはIAMサービスを介して作成され、これらのユーザーに指定されたクラウド・リソースを操作するための権限を明示的に付与します。

Oracle IAMには、コンソール、REST API、またはSDKを使用してアクセスすることができます。

Oracle Cloud Infrastructureのパスワードをリセットするには、まずアカウントにメール・アドレスが関連付けられていることを確認する必要があります。Oracle Cloud Infrastructureアカウントのユーザー・プロファイル・ページにアクセスし、自分だけがアクセスできるメール・アドレスを追加します。そのアドレスをアカウントに登録しようとしていることを確認するメールが届きます。その後、メール・アカウントを使用してパスワードをリセットできます（テナント管理者によってメール・アカウントが無効にされていない場合に限ります）。

コンパートメントは、インフラストラクチャ・リソース（コンピュート、ストレージ、ネットワークなど）をホストするために使用されるアカウント内の安全な論理コンテナであり、これらのリソースのアクセス管理ポリシー・セットと一緒に使用されます。コンパートメントを使用すると、クラウド・リソースを論理的に整理して、さまざまな用途に対応できます。

コンパートメントの一般的な使用方法について、以下に説明します。

• ソフトウェア開発環境を分離して、管理を簡素化します。たとえば、開発環境、テスト環境、および本番環境に別々のコンパートメントを配置したり、Blue/Green Deploymentをサポートするために別々のコンパートメントを配置したりできます。
• 権限管理を簡素化します。たとえば、ネットワーク・リソース（VCN、サブネット、インターネット・ゲートウェイなど）に個別のコンパートメントを作成し、ネットワーク管理者のみがそのコンパートメントにアクセスできるようにします。
• 各ビジネス・ユニットのクラウド・リソース使用量に対して適切な請求を行うために、各ビジネス・ユニットの使用量を個別に計測できます。
• 特定のユーザー・セットに表示されるリソース・セットを最小限に抑えます。たとえば、財務チーム向けに、特定の従業員のみに表示される個別のコンパートメントを配置することができます。

はい。コンパートメントは、可用性ドメインの物理構造とは異なるリソースの論理グループです。個々のコンパートメントには、可用性ドメイン全体のリソースを含めることができます。

すべてのポリシーは、ルート・コンパートメントまたは子コンパートメントのいずれかのコンパートメントにアタッチされます。各ポリシーは、以下の基本構文に準拠した1つ以上のポリシー・ステートメントで構成されます。

Allow group to in compartment

ポリシー・ステートメントを使用すると、コンパートメントを使用して権限管理を簡素化できます。たとえば、HRAdministratorsグループにHRCompartmentコンパートメントのすべてのリソースの管理を許可するポリシーを作成できます。

はい。コンパートメントを削除できます。

はい。コンパートメント・ツリー全体とツリーに含まれるリソースを他の親コンパートメントに移動することができます。

はい。リソースをコンパートメント間で移動できます。

はい、コンパートメントをネストすることで、コンパートメントの階層を作成できます。階層化またはネストされたコンパートメントを使用することで、システム管理者はリソースを整理でき、ポリシーによる完全な可視性と制御を保ちつつ、下位レベルの管理者に同様の作業権限を付与することができます。

最大で6階層までコンパートメントをネストできます。

はい。上位コンパートメントのポリシーはサブ・コンパートメントに継承されます。

はい。My Servicesでコンパートメントごとにコストと使用状況を追跡できます。

各アカウントに対して、Oracle Cloud Infrastructureはルート・コンパートメントと呼ばれる最上位のコンパートメントを自動的に作成します。ファイル・システムのルート・フォルダと同様、ルート・コンパートメントは子コンパートメントとまったく同じように動作しますが、ルート・コンパートメントには複数の特別な特性が備わっています。

• 権限は階層化されているため、ルート・コンパートメントのグループ権限はすべての子コンパートメントに適用されます。たとえば、NetworkAdminsグループのルート・コンパートメントにVirtual Cloud Networks（VCN）を管理する権限が与えられている場合、そのグループではすべてのコンパートメントでVCNを管理できます。
• 現在、すべてのユーザーとグループはルート・コンパートメント内に作成されています。ポリシーを使用して、特定の子コンパートメントへのアクセスのみを許可することができます。

注意：現在、追加のコンパートメントはルート・コンパートメント内にのみ作成でき、他のコンパートメント内には作成できません。

一般的に、リソースはルート・コンパートメントではないコンパートメントに作成する必要があります。コンパートメントとリソースの作成を開始する前に、コンパートメント階層を設計することをお勧めします。現在、リソースをコンパートメント間で移動できず、コンパートメントを編集または削除することもできません。

ユーザーとは、Oracle IAMに対する認証に成功し、アカウント内のクラウド・リソースを使用または管理できる十分な権限が付与されている人のことを指します。管理者は、アカウント内に1人以上のユーザーを作成し、ユーザーをグループに割り当てて特定のコンパートメント内のリソースに対する権限を付与することができます。

アカウントには、1人のユーザー（デフォルトの管理者）と、デフォルトの管理者ユーザーをメンバーとする1つのグループ（Administrators）がプロビジョニングされます。このグループ（Administrators）は、アカウントにフルアクセスできます。この特別なユーザー（デフォルトの管理者）は、追加のユーザーを作成するか、他のユーザーに新しいユーザーを作成する権限を付与する必要があります。

デフォルトでは、新規ユーザーにアカウント内のリソースやサービスを使用する権限がありません。すべての権限を明示的に付与する必要があります。このアプローチにより、特定のユーザーに必要なアクセス権限のみを各ユーザーに許可する、セキュリティの最小特権の原則を遵守することができます。ユーザーを既存のグループに明示的に追加するか、ユーザーに新規グループを作成してから、ポリシーを通じてそのグループに適切な権限を割り当てる必要があります。

現在、ユーザー・アクセスを無効にすることはできません。ただし、パスワードをリセットしたり、キーを削除したりすることはできます。

REST APIおよびSDKを使用して、パスワードのリセット、キーの変更、またはユーザーおよびグループのメンバーシップの編集を自動化できます。

グループとは、アカウント内の特定のリソースを使用または管理するために同様のアクセス権限を必要とするユーザーのコレクションです。ユーザーは複数のグループに所属できます。権限は加算されていきます。たとえば、あるグループのメンバーシップでユーザーがコンピュート・インスタンスの使用を許可され、別のグループのメンバーシップでそのユーザーがブロック・ボリュームの管理を許可されている場合、そのユーザーはインスタンスとブロック・ボリュームの両方を管理できます。

管理者は、特定のコンパートメントまたはアカウントに対して、必要なアクセス権限を付与されたグループ（個々のユーザーではない）を指定するポリシーを作成します。その後、管理者はユーザーを適切なグループに追加します。

はい。アカウントには1人のデフォルト管理者が、ルート・コンパートメント内の管理者グループにプロビジョニングされます。このグループには、ユーザー、グループ、ポリシー、コンパートメントを含むアカウント内のすべてのOracle Cloud Infrastructureリソース、およびコンパートメント内の他のすべてのクラウド・インフラストラクチャ・リソースを作成および管理できる完全な権限が付与されています。この管理者グループにユーザーを追加できます。

ポリシーは、ユーザーのグループに特定の権限を付与する説明的なポリシー・ステートメントで構成されるドキュメントです。ポリシーは、SQLのようなわかりやすい構文で記述されています。ポリシーの例を以下に示します。

• システム管理者は、ベアメタル・コンピュート・インスタンスを「終了」または「再起動」できる。
• ネットワーク管理者は、ネットワーク関連のすべてのインフラストラクチャ・リソースを完全に管理できる。
• IT管理者はユーザーを作成し、グループ・メンバーシップを編集できる。

ポリシーを使用すると、特定のコンパートメント内で特定のタイプのリソースを特定の方法で操作することをグループに許可できます。必要に応じて、ポリシーにポリシー・ステートメントを詳細に制限する条件句（「where ...」）を含めることができます。ポリシーは、次の構文に準拠しています。

Allow group to in compartment [where ]

たとえば、コンピュート・インスタンスを使用する権限を付与するポリシー・ステートメントは次のとおりです。

Allow group Developers to use instances in compartment ProjectA

• 「group_name」は、権限を付与されるグループの名前です。
• 「verbs」は、リソースに対して実行できるアクションです。例：inspect、read、use、manage
• 「resource-type」は、権限が付与されるクラウド・リソースです。リソース・タイプの例：instances、volumes、route-tables。
• 「compartment_name」は、リソースが整理されているコンパートメントの名前です。
• 「conditions」は、ポリシー・ステートメントの範囲を絞り込む詳細な仕様です。例：「where request.user.id=target.user.id」、「where target.group_name != Administrators」。

詳細については、Oracle Cloud Infrastructureドキュメントの「Oracle IAM」セクションを参照してください。

はい。ルート・コンパートメントで権限を付与しているポリシーによって、自動的にすべての子コンパートメントにも同じ権限が付与されます。たとえば、次のポリシーにより、「InstanceAdmins」グループのすべてのユーザーに、ルート・コンパートメントとすべての子コンパートメントのインスタンスを管理する権限が付与されます。

Allow Group InstanceAdmins to manage instances in tenancy

はい。各ポリシーはコンパートメントに「アタッチ」されます。アタッチするコンパートメントに応じて、ポリシーを変更または削除できるユーザーが制御されます。ルート・コンパートメントにポリシーをアタッチすると、ルート・コンパートメントのポリシーを管理するアクセス権限が付与されたユーザーは誰でもポリシーを変更または削除できるようになります。代わりにコンパートメントにポリシーをアタッチすると、そのコンパートメントのポリシーを管理するアクセス権限が付与されたユーザーは誰でもポリシーを変更または削除できるようになります。実際、この操作により、アカウント内に存在するポリシーの管理に対して広範なアクセス権限を付与することなく、コンパートメント管理者（コンパートメント内で「manage all-resources」アクセス権限が付与されたグループ）に自身のコンパートメントのポリシー管理に対するアクセス権限を簡単に付与できます。

ポリシーとポリシー・ステートメントの詳細については、Oracle Cloud Infrastructureドキュメントの「ポリシーを使ってみる」および「一般的なポリシー」を参照してください。

ID連携は、Oracle Cloud Infrastructureテナンシのユーザー管理をIDプロバイダ（IdP）と呼ばれる別のエンティティに委任するメカニズムです。このメカニズムは、新しいユーザー・セットを作成および維持せずに、既存のIDシステムを使用したい組織に有益です。連携には、Oracle Cloud InfrastructureとIdP（フェデレーション信頼）の間で、1回だけ構成する必要があります。

連携ユーザー（外部ID）とは、Oracle Cloud Infrastructureの外部（例：組織ディレクトリ内）で管理されているユーザーで、Oracle Cloud Infrastructureアカウントへのアクセス権限を付与するユーザーです。連携ユーザーは、Oracle Cloud Infrastructureアカウント内で作成および管理されているOracle Cloud Infrastructureユーザーとは異なります。

はい。連携ユーザーはOracle Cloud Infrastructureコンソールにアクセスできます。

はい。連携ユーザーはOracle Cloud Infrastructure SDKおよびCLIにアクセスできます。

連携ユーザーは、Oracle Cloud Infrastructureコンソールでパスワードを変更またはリセットできません。

ネイティブ・ユーザーの管理に使用しているのと同じOracle Cloud Infrastructureポリシーで、連携ユーザーを管理します。IDプロバイダのロールとグループをOracle Cloud Infrastructure内のグループにマッピングします。連携ユーザーがログインすると、Oracle Cloud Infrastructureコンソールは、ネイティブ・ユーザーと同様に、Oracle Cloud Infrastructureグループ・メンバーシップに基づいてポリシーを適用します。例については、ドキュメントを参照してください。

IDプロバイダ内の1つのロールまたはグループを複数のOracle Cloud Infrastructureグループにマッピングできます。また、IDプロバイダ内の複数のロールまたはグループを1つのOracle Cloud Infrastructureグループにマッピングすることもできます。

コンソールへのアクセス権限を付与できる連携ユーザーの数に制限はありません。

現在、Oracle Identity Cloud Service（IDCS）、Microsoft Active Directory Federation Services（AD FS）、Okta、およびその他のSAML 2.0準拠のIDプロバイダをサポートしています。