Identity and Access Managementに関するFAQ

FAQのトピック

全般

Oracle Cloud Infrastructure Identity and Access Management（OCI IAM）とは何ですか。

OCI IAMは、強力で適応性の高い認証、ユーザー・ライフサイクル管理（LCM）、エンタープライズ・アプリケーションへのシングル・サインオン（SSO）など、エンタープライズクラスのID・アクセス管理機能を提供するOCIのネイティブなサービスです。OCI IAMは、アイデンティティ・ドメインとしてOCIに導入されます。提供されているドメインを使用して、Oracle Cloud Services（ネットワーク、コンピュート、ストレージなど）とOracle SaaSアプリケーションへのアクセスを管理できます。お客様は、オラクル以外のアプリケーションへの従業員のアクセスの管理、顧客向けアプリケーションへの消費者のアクセスの有効化、カスタム開発アプリケーションへのIAMの埋込みなど、他のユース・ケースに対応するために、アイデンティティ・ドメインのアップグレードまたは追加作成を選択できます。

アイデンティティ・ドメインとは何ですか。

各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を実現できます。

従業員と非従業員を1つのアイデンティティ・ドメインに混在させることはできますか。

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

アイデンティティ・ドメインにアクセスできるのは誰ですか。

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

OCI IAMは、高可用性やディザスタ・リカバリを提供していますか。

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

Oracle Identity and Access Managementの重要な用語と概念を教えてください。

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

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

Oracle Cloud InfrastructureのID・アクセス管理に対するアプローチでユニークな点は何ですか。

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

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

Oracle Cloud Infrastructureは多要素認証をどのようにサポートしていますか。

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

デバッグと監査の目的で、ユーザー、グループ、コンパートメント、ポリシーの変更が記録されていますか。

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

OCI IAMを使い始めるにはどうすればよいですか。

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

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

Oracle Cloud Infrastructureユーザーによるパスワードのリセット方法を教えてください。

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 Cloud Infrastructureコンソール・ユーザーは何ができますか。

ユーザーとは、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リソース、およびコンパートメント内の他のすべてのクラウド・インフラストラクチャ・リソースを作成および管理できる完全な権限が付与されています。この管理者グループにユーザーを追加できます。

特徴

OCI IAMは、パスワードの有効期限の要件にどのように対応しますか。

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

ユーザー認証情報をコンピューティング・インスタンスに埋め込まずにそのインスタンスを実行するにはどうすればよいですか。

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

連携

Oracle Cloud InfrastructureのID連携とは何ですか。

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コンソールにアクセスできます。

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

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

Oracle Cloud Infrastructureユーザーがコンソール内で実行でき、連携ユーザーは実行できないアクションは何ですか。

連携ユーザーは、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 Cloud Infrastructureコンソールへのアクセス権限を付与できる連携ユーザーは何人ですか。

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

サポートしているIDプロバイダは何ですか。

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

多要素認証

多要素認証（MFA）の内容と、その重要性について教えてください。

従来、アカウントは単純なユーザー名とパスワードで保護されていました。しかし、パスワードは覚えにくく、ネットワーク・スニッフィング、フィッシング、ブルート・フォース攻撃など、一般的なサイバー攻撃の手法で比較的容易に取得することができます。もし他人に認証情報を盗まれた場合、盗んだ人間は本人になりすまし、すべてのアカウントやリソースにアクセスすることができます。

多要素認証（MFA）は、アプリケーションの利用者が本人であることの保証を強化することで、アカウント乗っ取りのリスクを低減するセキュリティ機能として普及しています。MFAは、ユーザーに複数の認証ファクターの提供を求めます。認証ファクターには、知っているもの（パスワードや暗証番号など）、持っているもの（セキュリティ・トークンや携帯電話など）、本人自身（指紋や顔スキャンなどの生体情報など）の3つのカテゴリーがあります。MFAが有効であれば、たとえ攻撃者がパスワードを取得できたとしても、MFAが要求する追加の証拠を提出しなければ、本人として認証されることはありません。これにより、不正なアクセスを防ぎ、機密情報の漏洩や不適切な行為の防止を図ることができます。また、MFAを有効にすることは、規制遵守の要件や、National Institute of Standards and Technology（NIST）が提供するような業界標準への準拠にも役立ちます。

MFAの利用対象者

オラクルは、すべてのユーザーに対してMFAを有効にすることを推奨しています。最低でも、OCIリソースの作成や管理といった管理者権限を持つユーザーに対しては、MFAを有効にする必要があります。また、機密情報をホストするアプリケーションやリスクの高いアクションを許可するアプリケーションへのアクセスには、MFAを義務付ける必要があります。

管理者がMFAを有効にした場合のエンド・ユーザーのエクスペリエンスについてご説明ください。

管理者が初めてMFAを有効にした場合、ユーザーは次回のサインイン時にMFAへの登録を求められます。初回登録後、ユーザーは次回以降のサインイン・プロセスの都度、MFAを要求されます。管理者が信頼できるデバイスを有効にすると、ユーザーは「このデバイスを信頼する」を選択できるようになり、ユーザーが同じデバイスを再度使用する場合、MFAの要件がなくなります。

ユーザーは、以下のガイダンスを参照して詳細を確認することができます。

MFAが必須であることは状況を選ばず変わらないのでしょうか。

いいえ。MFAは、すべての状況において厳密には必須とは限りません。例えば、公開されたウェブサイトへのアクセスを許可する場合、通常、認証は必要ないでしょう。購入時にサインインしてもらい、請求先や配送先がわかるようにしたい場合は、ユーザー名とパスワードだけで十分かもしれません。しかし、その同じユーザーが支払い方法や配送先を変更したい場合、またはアプリケーションが組織に影響を与える可能性のあるアクションを許可する場合、MFAが推奨されます。

オラクルは、すべてのクラウドおよびアプリケーション管理者のMFAを有効にすることを強く推奨しています。最終的には、組織内部のセキュリティ・ポリシーとリスク評価に基づいて、MFAの適用の可否を評価する必要があります。しかし、MFAは常に必須であることが基本で、MFAを任意に設定するアプリケーションについては、役員の承認を必要とするポリシーを推奨します。

利用可能なMFAファクターを教えてください。コストについて教えてください。

利用可能なファクターとコストを十分に理解するためには、まず自分が持つOCIテナントのタイプを把握することが重要です。テナントにIDドメイン付きのOCI Identity and Access Management（IAM）があるか、IDドメインなしのOCI IAMがあるかを判断するには、 こちらのドキュメントをご確認ください。

  • テナントにIDドメインを持つOCI IAMがある場合、すべてのIDドメイン・タイプが追加コストなしでMFAに対応しています。無料タイプのアイデンティティ・ドメインでは、認証ファクターとしてSMSを使用することはできませんが、他のファクターでは使用可能です。詳細については、アイデンティティ・ドメインのあるOCI IAMに関するMFAドキュメントをご確認ください。
  • テナントにIDドメインを持たないOCI IAMがある場合、MFAには2つのオプションがあります。
    • OCI IAMサービスによるユーザーの直接サインインのためのMFAを有効にします。このオプションは、特定の認証ファクターを追加コストなしで提供するものです。詳細については、アイデンティティ・ドメインのないOCI IAMに関するMFAドキュメントをご確認ください。
    • Oracle Identity Cloud Service（IDCS）を活用して、ユーザーをOCIで認証する。このオプションでは、より多くのMFA機能と認証の選択肢が提供されます。
  • IDCSで認証する場合、2つのライセンス・タイプがあります。
    • IDCS Foundation (Free Tier) は、無償で、こちらに記載されている通りの限定された認証ファクターで、OCIコンソールへのアクセスに対してのみMFAをサポートします。その他のアプリケーションを保護する場合は、IDCS Standardへのアップグレードが必要です。
    • IDCS Standardは、あらゆる保護対象のサービスや アプリケーションに対する幅広いMFAオプションを追加費用なしでサポートします。詳細については、Identity Cloud Service (IDCS)に関するMFAドキュメントをご確認ください。

MFAの実装方法の詳細を確認する方法を教えてください。

MFAを実装するための具体的な手順は、お客様がお持ちのOCIテナントがどのタイプであるかにより異なります。テナントにIDドメイン付きのOCI IAMがあるか、IDドメインなしのOCI IAMがあるかを判断するには、 こちらのドキュメントをご確認ください。

  • テナントにIDドメインを持つOCI IAMがある場合は、OCI IAMの保護のベスト・プラクティスをご参照ください。
  • テナントにIDドメインを持たないOCI IAMがある場合、MFAには2つのオプションがあります。
    • IDドメインなしでOCI IAM経由の直接ユーザー・サインインの MFAを有効にするには、IDドメインのないOCI IAMのMFAの管理をご参照ください。
    • IDドメインなしでOCI IAMにフェデレートされているIDCSユーザーに対してMFAを有効にするには、IDCSのMFAを構成をご参照ください。
  • OCI テナントなしでアプリケーションの認証にIDCSを使用している場合、IDCSのMFAを構成をご参照ください。

MFAを実装しない場合に、どのようなことが起こるかをご説明ください。

MFAを実装しない場合、ターゲットを絞ったアカウントの乗っ取り攻撃が成功するリスクが高まります。しかしMFAを使えば、テナントや他の認証プロセスは引き続き通常通りに動作します。