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ドキュメントの「ポリシーを使ってみる」および「一般的なポリシー」を参照してください。

IAMのdenyポリシー

OCI Identity and Access Managementのdenyポリシーに関するよくある質問

これらのFAQでは、Oracle Cloud Infrastructure（OCI）のIdentity and Access Managementのdenyポリシーについてご紹介します。denyポリシーを活用することで、ポリシー管理権限を持つお客様は特定のアクションを明示的にブロックできるため、OCIテナンシのセキュリティ強化とアクセス制御の簡素化に役立ちます。詳細は、OCI Identity and Access Managementのドキュメントを参照してください。

IAM Denyの利用開始について

OCIでIAM Deny機能を有効にするにはどうすればよいですか?

IAM Denyは、テナンシ管理者による明示的な有効化が必要なオプトイン機能です。OCIコンソールでポリシー、アクション、ポリシーの設定の順に進み、有効化します。一般ユーザーやポリシー作成者はこの機能を有効化できません。一度有効化すると、IAMフレームワークの永続的な機能となり、UIから無効化することはできません。ただし、denyポリシーの作成権限を持つテナンシ管理者は、デフォルトの管理者グループを除く全ユーザーに対し、新たなdenyポリシーの作成や変更をブロックするルートレベルのdenyポリシーを設定することで、IAM Denyの利用を制御できます。たとえば、Deny any-user to manage policies in tenancy where target.policy.type='DENY'というように記述します。

IAM Denyが有効化されると

  • OCIは、安全な利用のためにルートコンパートメントにデフォルトのdenyポリシーを自動的に設定します。
  • デフォルトの管理者グループとIAM Denyを有効化したテナンシ管理者のみが、denyポリシーの設定および管理権限を保持します。
  • テナンシ管理者は、バンキング、インベストメント、コンプライアンスなどの各コンパートメントにおける管理者グループなど、認可されたユーザーに対してdenyポリシーを作成できるよう、デフォルトのdenyポリシーを編集することができます。

OCI Identity and Access Managementのdeny文とは何ですか？

OCI Identity and Access Managementのdeny文を使うと、OCIテナンシ内で特定のアクションを明示的にブロックする拒否ポリシーを記述できます。これとallow文と組み合わせることで、きめ細かなアクセス制御を実現できます。たとえば、Deny any-user to inspect all-resources in tenancy where request.service='streaming'のように設定することで、テナンシ全体でOCI Streamingサービスへのすべてのアクセスを防ぐ一方、それ以外のアクセス権限はallow文により柔軟に許可できます。

IAMのdenyポリシーにはどのような制限がありますか？

IAMのdenyポリシーは、allowポリシーと同じ上限が適用されます。1つのテナンシでは最大100個のIAMポリシー・オブジェクトを作成でき、各オブジェクトには最大50個のポリシー文（denyまたはallow）を含められます。ただし、テナンシ内のすべてのポリシー・オブジェクトに含まれるポリシー文の合計数は100件までに制限されます。

IAMのdenyポリシーでサポートされるメタ動詞は何ですか？それらは新しいものですか、それとも既存のものですか？

IAMのdenyポリシーで使用するメタ動詞（meta-verbs）は、既存のmanage、use、read、inspectです。新しいメタ動詞は導入されません。allow文は権限を加算的に付与します（たとえばmanageには、下位の権限がすべて含まれます）。一方、deny文は減算的で、指定した権限と、階層内でそれより上位の権限だけをブロックします。

たとえば、ポリシーDeny group DevOps to manage instance in compartment Prodは、manage権限だけをブロックするため、DevOpsはuse、read、inspectのアクションを実行できます。しかしinspectをdenyすると、inspectは最下位（ベースレベル）の権限なので、すべての権限がブロックされます。

ポリシー作成と管理

OCI Consoleではdenyポリシーはどこに書きますか？

denyポリシーは、allowポリシーと同じOCI Consoleの画面で作成します。Identity & Security→Policiesに移動し、コンパートメントを選択して、ポリシー・エディタでallowと同様にdenyキーワードを追加します。deny専用の別画面は不要です。

denyポリシー専用のポリシー・オブジェクトはありますか？

いいえ。denyポリシーはallowポリシーと同じポリシー・オブジェクトを使用します。どちらも同じポリシー・オブジェクト内で管理できるため、管理が簡単になります。

1つのIAMポリシー・オブジェクトにdeny文とallow文を同時に含められますか？

はい。1つのポリシー・オブジェクトにdeny文とallow文を組み合わせて記載できるため、柔軟なアクセス制御が可能です。

たとえば、次のように1つのポリシーにallow文とdeny文を含められます。

Deny group Interns to use instance in compartment Finance
Allow group Admins to manage all-resources in compartment Finance

これらのポリシーにより、AdminsはFinanceコンパートメント内のすべてのリソースを管理できます。一方で、Internsはインスタンスに対する書き込み操作を一切できないようになり、アクセス制御を簡素化できます。

ポリシーを管理できるユーザーにdenyポリシーを書かせないにはどうすればよいですか？

ポリシーを管理できるユーザーがdenyポリシーを書けないようにするには、ルート・レベルでdenyポリシーを作成し、denyポリシー作成をブロックします。

例: Deny group PolicyAdmins to manage policies in tenancy where target.policy.type='DENY'

このポリシーにより、PolicyAdminsはdenyポリシーを作成または変更できなくなりますが、allowポリシーの管理は引き続き可能です。デフォルトの管理者グループは対象外のため、必要に応じてdenyポリシーを書くことができます。

IAMのdenyポリシーでOCIサービス全体をブロックするにはどうすればよいですか？

OCIサービス全体をブロックするには、ルート・コンパートメントにdenyポリシーを作成し、request.service.nameのような条件を使って、そのサービスのリソースまたはアクションを対象にします。

たとえば、OCI Streamingサービスをテナンシ全体でブロックする場合、

Deny any-user to inspect all-resources in tenancy where request.service.name='streaming'

このポリシーはOCI Streamingサービスへのすべてのアクセスを防ぎます。これは医療などの業界でコンプライアンス対応として有用です。ルート・コンパートメントにポリシーを配置することで、すべてのコンパートメントに適用され、ポリシーの乱立を抑えられます。

特定リージョンでグループによるリソース管理を拒否するにはどうすればよいですか？

特定リージョンでグループがリソースを管理できないようにするには、request.region conditionを使ったdenyポリシーを使用します。

たとえば、特定リージョンでグループが読み取り専用以外のアクションを実行できないようにしたい場合は、次のようなdenyポリシーを書けます。

Deny group RegionalAdmins to use all-resources in tenancy where request.region='sa-saopaulo-1'

このポリシーは、RegionalAdminsグループがサンパウロ・リージョンのリソースをuseすることをブロックしますが、read、inspectの権限は許可します。これは、地域のデータ・レジデンシー法へのコンプライアンス対応が必要な金融機関などに適しています。

特定コンパートメント内のコンピュート・インスタンスへのグループのアクセスを拒否するにはどうすればよいですか？

特定コンパートメント内のコンピュート・インスタンスへのグループのアクセスを拒否するには、次を使用します。

Deny group DevTeam to inspect instance in compartment ProjectX

このポリシーは、ProjectXコンパートメント内のコンピュート・インスタンスに対するすべての権限（inspect、read、use、manage）をブロックします。たとえば、テクノロジー企業が開発チームによる本番インスタンスへのアクセスを防ぎ、開発環境と本番環境を分離してセキュリティを強化する目的で利用できます。

特定コンパートメント内のオブジェクト・ストレージをグループに管理させないにはどうすればよいですか？

特定コンパートメント内のオブジェクト・ストレージ・リソースをグループが管理できないようにするには、次を使用します。

Deny group StorageUsers to inspect object-family in compartment DataLake

このポリシーは、DataLakeコンパートメント内のオブジェクト・ストレージ・リソースに対するすべての権限（inspect、read、use、manage）をブロックします。たとえば、医療機関はこれを適用して、StorageUsersが機密な患者データにアクセスできないようにし、プライバシー規制へのコンプライアンス対応を支援できます。

子コンパートメントでポリシーを管理できるユーザーにタスクを委任しつつ、特定リソースの変更やdenyポリシー作成は許可しないにはどうすればよいですか？

子コンパートメントでポリシーを管理できるユーザーに安全にタスクを委任するには、次のようにします。

  • allowポリシーを使い、指定したコンパートメントやリソースに対して必要な権限だけを付与します。
  • 子コンパートメントでポリシーを管理できるユーザーが、影響の大きいポリシーを作れないように、denyポリシーの作成者を制限します。
  • denyポリシーを使って、機微なリソースへのアクセスをブロックします。

たとえば、子コンパートメントでポリシーをmanageできるユーザーに対して、特定コンパートメント内のコンピュート・リソースはmanageさせつつ、ネットワーク変更とdenyポリシー作成は制限するには、次のポリシーを使用します。

Deny group ProjectAdmins to manage network-family in compartment ProjectX Deny group ProjectAdmins to manage policies in compartment ProjectXwhere target.policy.type='DENY'

Allow group ProjectAdmins to manage instance-family in compartment ProjectX

これらのポリシーにより、ProjectAdminsはProjectX内のインスタンスをmanageできる一方で、ネットワークの変更はブロックされ、denyポリシーも書けなくなります。これにより、安全な委任を支援できます。たとえば金融機関では、サブ管理者にコンピュート・リソースの管理を許可しつつ、ネットワーク構成とポリシー管理は厳格にコントロールするなどの目的で、この方法を利用できます。

安全性と復旧メカニズム

denyポリシーはallowポリシーより先に評価されますか？

はい。OCI Identity and Access Managementはdeny優先の評価モデルを採用しており、コンパートメント階層においてdenyポリシーがallowポリシーより先に評価されます。リクエストがdenyポリシーに一致した場合、allowポリシーがあってもアクセスはブロックされます。デフォルトの管理者グループはロックアウトを防ぐため、denyポリシーの適用対象外です。

たとえば、Prodコンパートメントに次のポリシーがある場合:

Deny group Devs to manage instance-family in compartment Prod
Allow group Devs to manage all-resources in compartment Prod

denyポリシーによりDevsはインスタンスをmanageできませんが、デフォルトの管理者は引き続きインスタンスをmanageできます。

ポリシーをmanageできるユーザーが、テナンシ内のすべてのユーザーをロックアウトするdenyポリシーを書いた場合はどうなりますか？

デフォルトの管理者グループはdenyポリシーの適用対象外のため、ログインしてポリシーを表示・編集し、ロックアウトを解消できます。この保護により、テナンシ全体の停止を防ぐのに役立ちます。

例: Denyany-user to inspect all-resources in tenancyを適用した場合でも、デフォルトの管理者グループのユーザーはログインでき、ポリシー・エディタにアクセスして当該ポリシーを削除または調整できます。

テナンシ全体のdenyポリシーで全ユーザーがロックアウトされた場合、どう復旧しますか？

Deny any-user to inspect all-resources in tenancyのようなテナンシ全体のdenyポリシーは、すべてのユーザーのアクセスをブロックし、障害を引き起こす可能性があります。復旧するには次の手順を実行します。

1. デフォルトの管理者グループ（denyポリシーの適用対象外）のメンバーとしてログインします。
2. OCI ConsoleでIdentity & Security→Policiesに移動します。
3. ルート・コンパートメントで問題のポリシーを見つけます。
4. ポリシーを編集または削除します（たとえばDeny any-user to inspect all-resources in tenancyを、Deny group Interns to inspect all-resources in tenancyに変更します）。
5. 代わりに、次のOCIコマンドライン・インタフェースを使用します。: oci iam policy update --policy-id --statements '["Deny group Interns to inspect all-resources in tenancy"]

たとえば、子コンパートメントでポリシーをmanageできるユーザーが誤ってDeny any-user to inspect all-resources in tenancyを適用した場合でも、デフォルトの管理者グループのユーザーがログインして、対象をGuestsグループのみにするよう変更でき、将来のロックアウトを防げます。このような問題を避けるため、ポリシーは十分にテストし、denyポリシーを作成できるユーザーを制限してください。

権限への影響

「manage」権限をdenyするとどうなりますか？

manageをdenyすると、manage権限だけがブロックされ、use、read、inspectはそのまま残ります。

例: Deny group DevOps to manage instance in compartment Productionは、DevOpsがインスタンスをmanageすることを防ぎますが、use、read、inspectは可能です。

「use」権限をdenyするとどうなりますか？

useをdenyすると、useとmanageの権限がブロックされますが、readとinspectは引き続き許可されます。

例: Deny group Testers to use bucket in compartment QAは、Testersがバケットをuseまたはmanageすることを防ぎますが、readまたはinspectは可能です。

「read」権限をdenyするとどうなりますか？

readをdenyすると、read、use、manageの権限がブロックされますが、inspectは引き続き許可されます。

例: Deny group Auditors to read logs in compartment Loggingは、Auditorsがログをread、use、manageすることを防ぎますが、inspectは可能です。

「inspect」権限をdenyするとどうなりますか？

inspectをdenyすると、inspectは最下位（ベースレベル）の権限であるため、すべての権限（inspect、read、use、manage）がブロックされます。

例: Deny group Viewers to inspect instance in compartment Publicは、Viewersによるインスタンスへのアクセスを完全にブロックします。

高度なユースケースとトラブルシューティング

denyポリシーが意図どおりに動作しているかを監視するにはどうすればよいですか？

OCI監査ログ（audit logs）を確認し、denyポリシーによってブロックされたアクションを追跡します。たとえば、Deny any-user to inspect cloud-shell in tenancyのようなポリシーが問題を引き起こす場合は、Deny group Interns to inspect cloud-shell in tenancyのように対象を絞るよう調整します。また、ポリシー変更に対するアラートを設定し、先回りして把握できるようにします。

例: Deny group Drivers to manage instance-family in compartment Fleetが正当な作業までブロックしてしまう場合に備え、ログを監視して調整します。

denyポリシーで避けるべきよくあるミスは何ですか？

OCIのdeny優先モデルでは、allowポリシーよりもdenyポリシーが優先されるため、ポリシーの範囲が広すぎると業務影響が出る可能性があります。よくあるミスには、テナンシ全体またはコンパートメント全体のロックアウトを適用してしまうこと、またはタグベースの条件を広範に指定しすぎることがあります。

たとえばDeny any-user to inspect all-resources in tenancyのようなポリシーは、すべてのアクセスをブロックしてテナンシ全体のロックアウトを引き起こす可能性があります。代わりに、次のように対象を絞ったポリシーを使用します。

Deny group Interns to inspect all-resources in compartment Public

これにより、Internsグループだけのアクセスを制限でき、意図しない影響を避けられます。たとえばテクノロジー企業では、この方法でゲストアクセスを制限しつつ、他のユーザーの機能を維持できます。問題を防ぐため、ポリシーはサンドボックス環境で十分にテストし、シンプルに保ち、denyポリシーを作成できるユーザーを制限してください。

クロステナンシのユースケースでdeny文はサポートされていますか？

はい。deny文はクロステナンシのシナリオをサポートしています。endorse/admitのペアは両方が満たされる必要があるのに対し、1つのdeny endorse文またはdeny admit文だけでクロステナンシのリクエストをブロックできます。

たとえば、次のソース・テナンシの例では以下のとおりです。

Endorse group Devs to use object-family in tenancy PartnerTenancy Deny endorse group Devs to manage object-family in tenancy PartnerTenancy

これにより、DevsはPartnerTenancy内のオブジェクト・ストレージをuseできますが、管理（manage）アクションはブロックされます。パートナー企業はこの仕組みを使って、データ共有を可能にしつつ、リソースに対するコントロールを維持できます。

OCI Zero Trust Packet RoutingとIAMのdenyポリシーはどのように連携しますか？

OCI Zero Trust Packet RoutingはOpen Systems Interconnection(OSI)モデルのレイヤー4（ネットワーク・レベル）で動作し、IAMのdenyポリシーはレイヤー7（アプリケーション・レベル）でアクセスを強制します。そのため、OCI Zero Trust Packet Routingが通信を許可していても、IAMのdenyポリシーでアクションをブロックできます。

（例：

  • OCI Zero Trust Packet Routingポリシー: Allow dynamic-group FrontEnd in VCN web:vcn to connect to backend:server-instance in VCN vcn:serverは、ネットワーク通信を許可します。
  • IAMポリシー Deny dynamic-group FrontEnd to manage instance-family in compartment ProjectAは、OCI Zero Trust Packet Routingで許可されていてもインスタンス管理をブロックします。

OCI Zero Trust Packet RoutingとIAMポリシーは順番に評価され、最終的なゲートキーパーはIAMです。

システム定義ポリシーはdenyポリシーとどのように連携しますか？

標準のシステム・ポリシーは、重要なサービスが機能し続けることを保証するため、常にユーザー定義のdenyポリシーよりも優先されます（たとえば、Allow any-user to read domains in tenancy where target.domain.id='request.domain.id）。

例: Deny group Users to read domains in tenancyのようなdenyポリシーがあっても、ドメインへのアクセスを許可する標準のシステム・ポリシーはブロックされません。

denyポリシーはallowポリシーと異なる方法で評価されますか？

OCI Identity and Access Managementはdeny優先の評価モデルを採用しており、コンパートメント階層においてdenyポリシーがallowポリシーより先に評価されます。リクエストがdenyポリシーに一致した場合、allowポリシーがあってもアクセスはブロックされます。システム定義ポリシーはユーザー定義のdenyを上書きする場合があります（質問27参照）。デフォルトの管理者グループはdenyポリシーの適用対象外のため、ロックアウト時でもポリシーを管理できます。

例: Deny group Users to manage instance-family in compartment ProdがAllow group Users to manage all-resources in compartment Prodと併存している場合、denyポリシーによってインスタンス管理はブロックされます。

IAM DenyはOracleのアイデンティティ・ドメイン管理ロール（たとえばidentity domain administrator、security administrator、user manager）を上書きしますか？

現行リリースでは、IAM DenyポリシーはOracle Identity Cloud Serviceの管理ロール（たとえばidentity domain administrator、security administrator、user manager）を上書きしません。これは制約です。次のリリースでは、一貫したアクセス制御のために、IAM DenyがOracle Identity Cloud Serviceの管理ロールより優先されます。

IAM Denyを使って、新しいOCI Private Service Access経由でのみサービスにアクセスさせるにはどうすればよいですか？

OCI Private Service Accessは、パブリック・インターネット経由ではなく、プライベートなネットワーク経路でオラクルのサービスにアクセスできるようにします。OCI Private Service Accessは、コンプライアンス、パフォーマンス、セキュリティの理由から、ワークロードとオラクルのサービス間をプライベート接続にしたいお客様向けに設計されています。

OCI Private Service Accessを使ってサービス（たとえばOCI Object StorageやOCI Streaming）に安全にアクセスしている場合、すべてのアクセスがOCI Private Service Access経由でなければならないことを強制したい場合があります。IAM Denyを使うと、allowポリシーが存在していても、サービスに対するOCI Private Service Access以外のトラフィックを明示的にブロックできます。

たとえば、OCI Object StorageへのアクセスをOCI Private Service Access経由のみにするには、次を使用します。

Deny any-user to access object-family in tenancy where any {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

このポリシーにより、トラフィックがOCI Private Service Accessエンドポイント経由でルーティングされていない限り、ユーザーはOCI Object Storageにアクセスできません。機密データ向けにOCI Private Service Access構成を設定していて、意図しないパブリック経路からのアクセスリスクを排除したい場合に特に有用です。

OCI Identity and Access ManagementのdenyポリシーとOracle Security Zonesの違いは何ですか？また、どのような場合に使うべきですか？

OCIは、安全でない操作を防ぐことでテナンシを保護するために、IAMのdenyポリシーとOracle Security Zonesを提供しています。どちらもセキュリティを強化しますが、仕組みと柔軟性が異なります。

  • 共通点: IAMのdenyポリシーとOracle Security Zonesはいずれも、特定の操作をブロックしてリソースを保護し、OCIテナンシにおけるセキュリティのベストプラクティスを強制します。
  • 主な違い
    • IAMのdenyポリシー: ユーザーの識別情報、リソース・タイプ、IPアドレス、タグなどの条件に基づいて操作をブロックするカスタム・ポリシーを作成します。これらのポリシーはガードレールとして機能し、次のリリースからはすべてのIAMポリシーに優先するようになります。たとえば、environment:productionのような特定のタグが付いた重要なリソースについて、特定のユーザー・グループによる削除をブロックできます。
    • Oracle Security Zones: コンパートメントまたはテナンシ全体に、事前定義されたセキュリティルールを適用します。有効化すると、パブリック・サブネットを防ぐ、暗号化を無効化させないといった制限を、OCIサービスの一定範囲に対して自動的に強制します。ポリシーを書く必要はなく、ルールは組み込みで、リソース設定を自動的にチェックします。
  • 使い分け
    • 定義した条件に基づいて特定のユーザーや操作をブロックするなど、カスタムで狙いを絞った制限にはIAMのdenyポリシーを使用します。
    • 最小限の設定でベストプラクティスを強制する、自動かつ既製のセキュリティルールにはOracle Security Zonesを使用します。
    • より強固な保護のために両方を組み合わせます。広範なベースラインのガードレールとしてOracle Security Zonesを有効化し、特定要件に合わせた制御としてIAMのdenyポリシーを追加します。

OCI Identity and Access Managementのdenyポリシーに関する問い合わせ

追加のサポートが必要な場合は、OCI Identity and Access Managementのドキュメントを参照するか、OCI担当者までお問い合わせください。

グループ

グループとは何ですか。

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

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

複数の管理者を設定できますか。

はい。アカウントには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を使えば、テナントや他の認証プロセスは引き続き通常通りに動作します。