Identity and Access Managementに関するFAQ

各OCI IAMアイデンティティ・ドメインは、さまざまなIAMユース・ケースへの対応に使用できる自己完結型のID・アクセス管理ソリューションです。たとえば、OCI IAMアイデンティティ・ドメインを使用して、多数のクラウドおよびオンプレミス・アプリケーションにわたる従業員のアクセスを管理し、セキュアな認証、資格の簡単な管理、エンドユーザーのシームレスなSSOを実現できます。また、アイデンティティ・ドメインを構築して、ビジネス・パートナーのサプライチェーンまたは注文システムへのアクセスを有効にすることもできます。アイデンティティ・ドメインを使用して、消費者向けアプリケーションのIAMを有効にして、消費者ユーザーが自己登録、ソーシャル・ログオンまたは使用条件の同意を実行できるようにすることもできます。アイデンティティ・ドメインは、多数のIAMユース・ケースおよびシナリオに対応する包括的なIdentity-as-a Service（IDaaS）ソリューションです。

• 無料アイデンティティ・ドメイン: 各OCIテナンシには、OCIリソース（ネットワーク、コンピュート、ストレージなど）へのアクセスを管理するための無料枠のデフォルトOCI IAMアイデンティティ・ドメインが含まれています。OCIリソースへのアクセスの管理のみを目的としている場合は、提供されているデフォルトのドメインを使用できます。このドメインは、Oracle Cloudリソースへのアクセスを管理するための堅牢なIAM機能セットを提供します。セキュリティ・モデルやチームに応じて、OCI管理者用にこのドメインを予約するように選択することもできます。
• Oracle Appsアイデンティティ・ドメイン: 多数のOracle Cloudアプリケーション（HCM、CRM、ERP、業種別アプリなど）に、Oracle Appsドメインを介したOCI IAMの使用が含まれている場合があります。これらのドメインは、登録されたOracle Applicationsで使用するために含まれており、Oracle CloudおよびSaaSサービスへのアクセスを管理するための堅牢なIAM機能を提供します。お客様は、すべての従業員をこのドメインに追加して、Oracle Cloudアプリケーション・サービスへのSSOを有効にすることを選択できます。また、このドメインを使用してOCIリソースの一部またはすべてへのアクセスを管理できます。
• Oracle Appsプレミアム・アイデンティティ・ドメイン: SaaSで提供されていない可能性があるOracle Applications（オンプレミスまたはOCIでホストされているかどうかに関係なく、Oracle E-Business Suite、Oracle Databasesなど）のアクセスを管理するために、Oracle Appsドメインを包括的なエンタープライズ機能で拡張することを希望する場合は、Oracle Appsプレミアム・ドメインを選べば、オラクル対象製品で使用するためにハイブリッド・クラウド環境にわたって導入可能なOCI IAMのフル機能セットが提供されます。これは低コストのフル機能サービスですが、オラクル対象製品での使用に制限されています。
• 外部アイデンティティ・ドメイン: 外部アイデンティティ・ドメインは、小売サイトにアクセスする消費者、市民のアクセスを可能にする政府、ビジネス・パートナーへのアクセスを許可する企業など、非従業員に対してOCI IAMのフル機能セットを提供します。対象となるアプリケーションの制限はありません。ただし、通常、アプリケーション・ゲートウェイやプロビジョニング・ブリッジなど、非従業員のシナリオでは有用ではない一部のエンタープライズ機能は含まれていません。外部ドメインには、ソーシャル・ログオン、自己登録、使用条件の同意、プロファイルまたはパスワード管理のサポートが含まれます。
• プレミアム・アイデンティティ・ドメイン: プレミアム・アイデンティティ・ドメインは、OCI IAMのフル機能セットを提供し、対象となるアプリケーションの制限はありません。プレミアム・ドメインを使用して、クラウドおよびオンプレミス・アプリケーションにわたる従業員のアクセスを管理し、セキュアな認証、資格の簡単な管理、エンドユーザーのシームレスなSSOを実現できます。

いいえ。OCI IAMでは、ライセンスの関係でこれらは個別のユーザー・グループとみなされます。ただし、同じOCI IAMサービスを使用して、従業員と非従業員（パートナー、関連会社、消費者など）に対応できる2つ以上のドメインを管理できます。複数のドメインを使用して同じアプリケーションにアクセスできますが、非従業員のルールとセキュリティ・ポリシーは、通常、従業員に適用されるものとは異なります。各ドメインには、それぞれのユーザー・グループに固有の独自の設定、構成、セキュリティ・ポリシーのセットがあります。これは、さまざまなユーザー・グループに典型的な、広く異なる要件に対応するように設計されているためです。

各OCIテナンシには、すべてのOCIリソースへのフル・アクセスを提供する管理者グループが含まれています。OCI管理者グループのすべてのメンバーがOCI IAMアイデンティティ・ドメインを管理するためにフル・アクセスできることを理解することが重要です。オラクルでは、このグループを慎重に使用することを推奨しています。管理権限は、管理者ロールを介して各ドメイン内で付与できます。これにより、ユーザーのグループ間で職務を分離できます。詳細については、「管理者ロールの理解」を参照してください。

各OCIリージョンには、複数の可用性ドメイン（AD）またはフォルト・ドメイン（FD）（単一のADリージョン）があります。ADとFDは同様の機能を提供しますが、FDはADよりも物理的に緊密です。アイデンティティ・ドメインは、高可用性を提供する各リージョンの冗長インストール（ADまたはFDにわたって2つ）を使用して導入されます。また、OCI IAMアイデンティティ・ドメインは、高パフォーマンスのデータ・レプリケーションを活用するアクティブまたはパッシブ・アプローチを介して、リージョン間のディザスタ・リカバリ（DR）も提供します。これにより、万が一OCIリージョン全体が使用できなくなった場合に、アイデンティティ・ドメインに対して信頼性の高いデータ・リカバリが行われます。このDRの提供は、アプリケーションに対して透過的な単一のURLを介しています。

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

• アカウントまたはテナンシ - OCIにサインアップすると、オラクルによって企業のテナンシが作成されます。これは、クラウド・リソースを作成、編成、管理できるOCI内の分離されたパーティションです。OCIアカウントとも呼ばれます。
• コンパートメント - OCIアカウント内にあるOracle Cloudリソースの論理コンテナ。管理者は、1つ以上のコンパートメントを作成し、OCIアカウント内のリソースを整理および管理できます。たとえば、コンパートメントを使用して、さまざまなタイプの管理者（ネットワーク、コンピュート、ストレージなど）間で職務の分離を適用できます
• ルート・コンパートメント - OCIアカウント内で最上位のコンパートメント。アカウントがプロビジョニングされると、ルート・コンパートメントが自動的に作成されます。
• アイデンティティ・ドメイン - アイデンティティ・ドメインは、OCIのユーザー・グループ、および関連する構成とセキュリティ設定を示します。各アカウントには、お客様がOCIリソースへのアクセスを管理できるデフォルトのアイデンティティ・ドメインが含まれています。お客様は、特定のニーズに基づいて追加のアイデンティティ・ドメインを作成することを選択できます。アイデンティティ・ドメインはコンパートメント内に作成され、ドメインを管理するためのアクセスはコンパートメントの権限に関連付けられます。OCIアクセス・ポリシーを記述して、特定のコンパートメントまたはドメインのユーザーが他のコンパートメントのリソースにアクセスできるようにします。
• ユーザー - 認証可能なエンティティ。ユーザーは、個人アカウントまたはマシン・アカウントのいずれかになります。各ユーザーのアカウントには、一意の名前とグローバルに一意の識別子が含まれています。ユーザーには、Webコンソールにアクセスするためのパスワードと、APIを介してサービスにアクセスするためのキーを付与できます。
• グループ - 一連のユーザー。グループは、アクセス管理を簡素化するために使用されます。たとえば、ソフトウェア開発者は「developers」グループのメンバーとしてグループ化することができ、コードの読取りまたは変更を行うことができます。1人のユーザーが複数のグループのメンバーになることもできます。
• ポリシー - どのOCIリソースにどのユーザーがアクセスできるか、どの権限を付与するかを指定したドキュメント。ポリシーは、自然言語構文を利用するポリシー・ステートメントで構成されています。

OCI IAMを使用すると、すべてのOracle CloudおよびCloud Applicationサービスの認証と承認に一元的なモデルを活用できます。OCI IAMを使用すると、1人が1つのプロジェクトで作業しているケースから、多くのグループが同時に多くのプロジェクトで作業している大規模な組織にいたるまで、あらゆる規模の組織が1つのアカウント内でアクセス権限を簡単に管理できるようになります。リソースの管理と承認をアカウント・レベルまたはコンパートメント・レベルで実行でき、監査と請求も一元化できます。OCI IAMは、セキュリティの最小権限の原則を適用できるよう、ゼロから構築されています。デフォルトでは、新規ユーザーはリソースに対していかなるアクションも実行できないようになっています。管理者は、各ユーザーに対して適切なアクセス権限のみを付与できます。

また、OCIリソースの管理に加えて、OCI IAMはエンタープライズクラスのIDaaSソリューションを簡単に利用できるようになります。ボタンをクリックするだけで、従業員、パートナー、消費者のユース・ケースで多くのIAM要件に対応するために使用できる堅牢なIAMソリューションを導入できます。

OCI IAMは、プッシュまたはワンタイム・パスコード、FIDO2オーセンティケータのサポート、SMS、Eメール、電話などのオプションを提供するモバイルMFAアプリケーションを含む、多要素認証（MFA）を幅広くサポートしています。OCI IAMには、エンドユーザー・エクスペリエンスにハードルを設けることなくリスクを低減する、文脈を意識したアダプティブ・セキュリティも含まれています。アダプティブ・セキュリティは、ユーザーのデバイス、ネットワーク、場所、過去の行動を評価して、ユーザーのセッションのリスク・スコアを作成します。管理者は、特定のアプリケーションまたは特定のユーザー・グループごとに異なる可能性があるMFAポリシーを構成できます。

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

デフォルトで、OCI 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を管理できます。
• 現在、すべてのユーザーとグループはルート・コンパートメント内に作成されています。ポリシーを使用して、特定の子コンパートメントへのアクセスのみを許可することができます。

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

一般的に、リソースはルート・コンパートメントではないコンパートメントに作成する必要があります。コンパートメントとリソースの作成を開始する前に、コンパートメント階層を設計することをお勧めします。

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

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

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

管理者は、ユーザーを非アクティベーションまたはロックして、アクセスを一時的に無効にできます。また、ユーザー・パスワードをリセットしたり、キーを削除したりすることもできます。

はい。パスワード・ポリシーを使用すると、パスワードの有効期限を設定できます。また、REST APIおよびSDKを使用して、パスワードのリセット、キーの変更、ユーザーおよびグループのメンバーシップの編集を自動化することもできます。

ポリシーは、ユーザーのグループに特定の権限を付与する説明的なポリシー・ステートメントで構成されるドキュメントです。ポリシーは、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" or "where target.group_name != Administrators」

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

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

Allow Group InstanceAdmins to manage instances in tenancy

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

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

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

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

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

パスワード・ポリシーを使用すると、パスワードの有効期限を設定できます。デフォルトのパスワード・ポリシーでは、120日後にパスワードの期限が切れるように設定されます。このポリシーは構成可能で、ユーザーのサブセットに異なるポリシーを適用できます。

動的リソース・グループを使用して、一連のコンピューティング・リソースをグループに割り当てます。その後、ポリシーを使用してそのグループ権限を割り当てることができます。これにより、コンピューティング・インスタンスは、認証情報をスクリプトに埋め込むことなく、セキュアな方法で他のOCIリソースにアクセスできます。

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グループにマッピングすることもできます。

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

OCI IAMは、Oracle Access Manager、Microsoft Active Directory Federation Services（AD FS）、Oktaなどの一般的なソリューションを含む、SAML 2.0、Open ID Connect、またはOAuth準拠のアイデンティティ・プロバイダーをサポートしています。