IAMセキュリティ構造

クラウド導入の主なメリットは、ビジネスを小さく始めて大きく拡張できることです。従来のインフラストラクチャと比較すると、自動化の使用によってリソースを数日ではなく数分でデプロイできるため、イノベーションを促進できます。適切に制御できないと、クラウド環境は複雑になりすぎてセキュリティ面でもコスト面でも管理できなくなり、組織をリスクにさらすことができます。

Oracle Cloud Infrastructure (OCI)に複数のクラウド・リソースを作成する前に、アイデンティティおよびアクセス管理(IAM)セキュリティ・モデルを設定することをお薦めします。セキュリティ・モデルの初期バージョンは、職務とリソースを分離することで組織の管理リスクを軽減し、将来の成長を成功に導く助けになります。

ノート: 複数のクラウド・リソースを追加する前に、テナンシ、コンパートメント構造などをカバーするIAMセキュリティ・モデルを定義してください。

OCIでは、次のリソースから始めるリソース分離が組み込まれています:

• テナンシ
• アイデンティティ・ドメイン
• コンパートメント構造
• IAMポリシー

組織およびテナンシ

OCIにサインアップすると、Oracleによってテナンシが自動的に作成されます。テナンシには、ユーザー、グループ、コンパートメント、一部のポリシー、その他のOCIリソースなどのIAMエンティティが含まれます。また、ポリシーおよびリソースをテナンシ内のコンパートメントに配置することもできます。詳細は、組織管理およびリソースへのアクセスの管理を参照してください

テナンシを最上位のセキュリティ境界とみなす

• テナンシは、OCIリソースをホストする最上位のコンテナであり、ルート・コンパートメントとも呼ばれます。
• OCIリソースのすべてのアクセス制御は、IAMポリシーによって決まります。テナンシは、IAMポリシーを割り当てることができる最上位レベルです。OCI組織管理ガバナンス・ルールは、子テナンシの許可されたリージョン、サービス割当ておよびタグを制御できますが、IAMポリシーを制御することはできません。クロステナンシIAMポリシーを作成することで、テナンシ間のアクセス権を付与できます。この場合、テナンシを付与および受け入れる管理者は、アクセスおよび共有できるリソースを明示的に示す特別なポリシー・ステートメントを作成する必要があります。

ノート:ルート・コンパートメントはIAMポリシー階層の最上位レベルであり、IAMポリシーはテナンシ間で継承することはできません。詳細は、ポリシーの仕組みおよびクロステナンシ・ポリシーを参照してください

複数のテナンシを活用して、限界を超えてビジネスを拡大

• 各OCIテナンシは、Oracleによって構成された一連のサービス制限を使用して作成されます。ユーザーはサービス制限の引上げをリクエストできますが、制限を直接制御することはできません。
• サービスの中断を回避するために、ユーザーは必要に応じてコンパートメントにサービス割当て制限を割り当てることで、使用量の分散を制御できます。
• ユーザーは、作成時に独自の制限セットが割り当てられている新しいテナンシを活用することで、ハード・サービス制限を超えてスケーリングできます。

組織管理を使用するとテナンシを組織に追加できます。また、テナンシはプライマリ有償サブスクリプションからクレジットを消費できます。その後、分離されたテナンシを作成して、新しいオーダーを予約せずにワークロードを構築できます。

テナンシのタイプは次のとおりです:

• 親テナンシ: プライマリ有料サブスクリプションに関連付けられ、各テナンシにわたる分析およびレポートが可能です。各組織が持てる親テナンシは1つのみです。通常、親テナンシは、開発者、財務およびIT運用がアクセスする必要がある管理目的で使用します。この場合、このテナンシ内のアプリケーションまたはサービスをホストしないことをお薦めします。
• 子テナンシ:自身のものでないサブスクリプションから消費するテナンシー。子テナンシをまったく新しいテナンシとして作成することも、既存のテナンシに親テナンシへの参加を薦めて同じ組織の一部にすることもできます。

ノート:特に管理目的で使用される場合は、親テナンシ内のアプリケーションまたはサービスをホストしないことをお薦めします。詳細は、OCIブログ- 使用組織によるコストの一元管理を参照してください。

テナンシ構造に関する考慮事項

テナンシに関する次の情報を考慮してください:

• 請求およびコスト管理: 1つの取引約定を共有すると、コスト超過が少なくなり、連結請求が可能になります。
• 環境の分離: 厳密なリソース分離による高い運用自律性が必要な場合、テナンシを最上位レベルの境界として使用して環境を分離できます。各テナンシにはIAMリソースおよびルールの個別セットが付属しているため、セキュリティとガバナンスの設定は別々に管理されます。個別管理は、最高レベルの運用自律性をサポートします。
• 管理オーバーヘッド:複数のテナンシを使用すると、強力な分離レベルでの運用自律が可能になりますが、管理オーバーヘッドのコストが発生します。規制コンプライアンスのためになど、高レベルの分離が必要ない場合は、アイデンティティ・ドメインおよびコンパートメントの使用を検討してください。
• IAMリソース・レジデンシ:各テナントにはそれぞれのホーム・リージョンがあり、その中のデフォルトIAMアイデンティティ・ドメインにOracle Cloudアカウント情報およびアイデンティティ・リソースが含まれます。
  • デフォルト・ドメインは常に、テナントがサブスクライブされているすべてのリージョンにレプリケートされます。管理者が別のリージョンにサブスクライブすると、デフォルト・ドメインのみがそのリージョンにレプリケートされます。デフォルト・ドメインのホーム・リージョンはテナンシのホーム・リージョンであり、変更できません。
  • セカンダリ(デフォルト以外)・アイデンティティ・ドメインは各自のホーム・リージョンを持てますが、テナンシがサブスクライブされているリージョンのセット内に限定されます。また、セカンダリ・アイデンティティ・ドメインを、テナンシがサブスクライブされているリージョンのセット内のリージョンにレプリケートすることもできます。

テナンシの制限事項

テナンシには、次の制限事項を考慮します。

• ホーム・リージョンにはアカウント情報およびアイデンティティ・リソースが含まれており、テナンシのプロビジョニング後は変更できません。詳細は、ホーム・リージョンを参照してください。
• 子テナンシが作成された場合、そのテナンシはOracle Identity Cloud Service/OCI Identity Domainsに自動的にフェデレートされません。詳細は、新しい子テナンシの作成を参照してください。
• Pay As You GoまたはFree Tierサブスクリプションを使用するテナンシでは、新しい子テナンシを追加することはできません。詳細は、新しい子テナンシの作成を参照してください。
• 親子テナントは単一レベル構造であり、複数レベル階層をサポートしていません。

テナンシのユース・ケースの例

個別のテナンシを持つ次のユース・ケース例について考えてみます:

• 規制対象顧客の専用テナンシをホストするSaaSサービス・プロバイダ
• プライバシおよびデータ・セキュリティの法律に基づくIAMリソース・レジデンシ要件。
• 合併と買収(M&A)のために、個別のアイデンティティ管理および採用プロセスを使用して運用自律性を維持する必要がある企業。
• ハッカソンおよび概念実証(PoC)では、Free Tierおよびプロジェクトベースのテナンシで革新的なプロジェクトを開始してから、交渉済の価格表およびより優れたコスト可視性のために、幅広い組織に適用することができます。
• 本番環境と非本番環境の分離などの規制要件。

テナンシに関する重要な設計上の決定事項

次の情報に基づいて、設計に関する重要な決定を行います:

• 個別のテナンシと組織でOCIの導入を拡張するために受け入れられたユース・ケース
• テナント運用モデル(新しいテナンシ、テナンシの所有権、コストおよび予算管理をリクエストするプロセスなど

詳細は、組織管理およびテナンシの管理を参照してください。

パブリック・ドメイン名を持つ他のユーザーがOracle Cloudアカウントを作成できないようにする

強力なガバナンスを実施するために、企業によっては、ビジネス・グループ全体で新しいクラウド・アカウントの作成を一元管理する必要がある場合があります。

ドメイン管理を使用してパブリック・ドメイン名をOCIに登録できます。これにより、他のユーザーが新しいクラウド・アカウントを使用するために将来そのドメインを要求することがブロックされます。その検証済ドメインから企業の電子メール・アドレスを使用して新規ユーザー・サインアップの試行をリダイレクトできます。

たとえば、OCIを使用しているユーザーが電子メール・ドメインにcompanyA.comを使用してテナンシを作成しようとすると、試行は防止され、かわりにOCIに転送されます。

そのため、ドメイン管理を使用すると、テナンシを作成しているユーザーを把握し、テナンシに企業ポリシーを適用することで、大企業は自社の環境を制御しやすくなります。ドメインの所有権を安全に検証でき、支出とリソースの管理をより簡単に制御できます。

通常、これは、中央管理機能の一部として親テナンシでカバーされます。OCI提供のTXTレコードを追加して、ドメインの所有権を検証するには、パブリック・ドメイン管理者のサポートが必要です。このドメイン検証プロセスが完了するまでに最大72時間かかります。

ノート:他のユーザーがドメイン管理を使用して、検証済ドメインでOracle Cloudアカウントを作成できないようにできます。Oracle Notificationを使用して、誰かがドメインでアカウントを作成しようとした場合に通知します。

ノート:ドメインを共有する場合は、この機能を有効にすることで、他の事業部門が独自のアカウントを作成することをブロックする場合があります。この機能を有効にするには、中央管理チームを使用し、影響を受ける事業部門など、関連する利害関係者との適切なコミュニケーションを行うことをお薦めします。

テナンシ構造に関する重要な設計上の決定事項

詳細は、組織管理およびテナンシの管理を参照してください。

IAMアイデンティティ・ドメイン

アイデンティティ・ドメインとは、ユーザーとロールの管理、ユーザーのフェデレーションとプロビジョニング、シングル・サインオン(SSO)構成を介したアプリケーション統合の保護、およびSAML/OAuthベースのアイデンティティ・プロバイダ管理を行うためのコンテナです。このドメインは、OCIへのユーザー移入と、それに関連する構成およびセキュリティ設定(マルチファクタ認証(MFA)など)を表します。

複数のアイデンティティ・ドメイン(開発用に1つのドメイン、本番用に1つのドメインなど)を作成および管理できます。各ドメインには、アプリケーションとOCIサービスを保護するための、アイデンティティおよびセキュリティの様々な要件がある場合があります。

複数のアイデンティティ・ドメインを使用すると、いくつかのメリットがあります。別々のアイデンティティ・ドメインを持つと、あるアイデンティティ・ドメインで作業しているユーザーが別のアイデンティティ・ドメインでのユーザーの作業に影響を与えることがありません。

複数のアイデンティティ・ドメインを使用すると、各アイデンティティ・ドメインに対する管理統制の分離を維持するのに役立ちます。たとえば、セキュリティ標準によって開発用のユーザーIDを本番環境に含められない場合は、複数のアイデンティティ・ドメインが必要です。また、複数のドメインは、異なる管理者が様々な環境を制御する必要がある場合にも使用されます。

アイデンティティ・ドメインの設計に関する考慮事項

IAM構造を設計する際には、次の情報を考慮してください:

• 複数の環境とワークロードにわたってユーザーIDと管理者を分離する必要性。次に例を示します:
  • 開発環境と比較した本番
  • スタッフ向けワークロードと顧客向けワークロード
  • 契約者と比較した従業員
• 管理者は、サービス制限で許可されている数のセカンダリ・アイデンティティ・ドメインを作成できます。
• デフォルト・アイデンティティ・ドメインまたはセカンダリ・アイデンティティ・ドメインを別のドメイン・タイプにアップグレードできます。各アイデンティティ・ドメイン・タイプには、異なる機能およびオブジェクト制限が関連付けられています。

次の情報は、デフォルト・アイデンティティ・ドメインとセカンダリ・アイデンティティ・ドメインの主な相違点をまとめたものです。

アイデンティティ・ドメインのユース・ケースの例

個別のアイデンティティ・ドメインを持つ次のユース・ケース例について考えてみます:

• 一部のセキュリティ標準および業界の規制では、ユーザーを本番環境と開発環境で分離し、開発環境から本番環境にアクセスできないようにする必要があります。
• 顧客や契約者などの外部ユーザーを従業員のアイデンティティから分離します。

アイデンティティ・ドメインに関する推奨事項

ドメインを設定する際には、次の推奨事項に従ってください:

• ユーザー移入ごとに異なるアイデンティティ・ドメインを使用します。
• テナンシ・レベルの管理にはデフォルト・アイデンティティ・ドメインを使用します。環境固有の管理およびPlatform as a Service (PaaS)サービスには、ライフサイクル、ホーム・リージョン、レプリケーションなどのドメイン動作をより詳細に制御できるように、セカンダリ・アイデンティティ・ドメインを使用します。
• クラウドのみのシナリオにはFree/Oracle Apps Identity Domainから始めて、制限を引き上げたり、拡張的なユース・ケースをサポートしたりする場合にPremium/Oracle Apps Premiumにアップグレードします。次に例を示します:
  • オンプレミスまたはクラウドでホストされているOracleアプリケーションに対して認証します。
  • Active Directoryまたは他のIAMシステムとの双方向同期を使用します。
  • パスワードレス認証、FIDO2ハードウェア・トークン、アダプティブ・セキュリティ・ソリューションなど、最新のAuthN/AuthZ機能を使用します。
• 次のリソースを必要とする顧客向けおよび非従業員のユース・ケースでは、セカンダリ外部アイデンティティ・ドメインを作成します:
  • ソーシャル・ログイン、ユーザー・セルフサービス・パスワード、プロファイル管理、および使用条件への同意。
  • 数百万人のユーザーに対応できるように拡張するためのフル機能を備えたIdentity as a Service (IDaaS)。
  • OCIの資格管理へのアクセス権がありません。たとえば、OCIリソースへのアクセスの管理や、アプリケーション・カタログおよびActive Directoryの同期を使用するサードパーティ・アプリケーションにプロビジョニングするためのスタッフ向けIAM機能などです。

アイデンティティ・ドメインに関する主な設計上の決定事項

• IAM分離にセカンダリ・アイデンティティ・ドメインを追加する場合の許容可能なユース・ケースを承認します。
• IAMドメインのホーム・リージョンを決定します。これは作成後に変更できません。
• ブリッジによるLDAP/ADとの双方向同期、EBS AsserterおよびRADIUSプロキシなど、プレミアIAM機能が必須かどうかを決定します。
• ソーシャル・ログイン、ユーザー・セルフサービス・パスワード、プロファイル管理などの機能が必要な場合は、外部ユーザーIAMドメインの所有権および管理を決定します。

詳細は、IAMアイデンティティ・ドメイン・タイプを参照してください。

ファイングレーションIAMポリシーのコンパートメントとタグ付け構造

コンパートメントおよびタグを使用して、アクセス制御のためにリソースを編成および分離します。

IAMポリシーの基本

• IAMポリシーとは、会社が所有するOCIリソースにだれがどのようにアクセスできるかを指定するステートメントです。

• OCIはデフォルトではアクセス権を付与しないため、リソースの管理を開始するには、少なくとも1つのポリシーが必要です。各ポリシーは、次の基本構文に従う1つ以上のポリシー・ステートメントで構成されています。

  <conditions>の<location>で<subject>に<verb> <resource-type>を許可します

• 次の情報では、IAMポリシーの3つの主要グループについて説明します。

• OCIサービスとDynamic Groupのアクセスを変更すると、サービス停止が発生する可能性があるため、適切に処理されない場合は、カナリア・テナンシ/環境を使用してこれらの種類の変更をリリースし、本番環境への変更が中断されないようにすることをお薦めします。
• コンパートメントおよびタグを使用してリソースを編成することで、アクセス制御を付与できます。

コンパートメントおよびタグの設計に関する考慮事項

コンパートメントおよびタグを設定する際には、次の情報を考慮してください:

• コンパートメント:

  • コンパートメントはテナンシワイドであり、複数のリージョンにまたがります。コンパートメントを作成すると、そのコンパートメントは、テナンシがサブスクライブされているすべてのリージョンで使用可能になります。
  • 他のコンパートメント内にサブコンパートメントを作成して、レベル6までの深さの階層を作成できます。サブコンパートメントは、階層内でその上に位置するコンパートメントからアクセス権限を継承します。

  

  • コンパートメントは、アクセス制御の付与に必須の単位の1つです。条件節によってコンパートメントをさらに絞り込むことができます。

• タグ:タグベースのアクセス制御を使用して、コンパートメント、グループおよびリソース全体にわたるアクセス・ポリシーを定義できます。タグベースのアクセス制御を使用すると、IAMポリシーの重複を回避し、一貫性を確保し、管理オーバーヘッドを最小限に抑えることができます。

  注意:定義したタグ・キーでは大/小文字は区別されませんが、定義したタグ値では大/小文字が区別されます。たとえば、"Env"と"ENV"は同じタグ・キーです。"Dev"と"DEV"は異なるタグ値です。

• 条件付きIAMポリシー:

  • 条件一致では大文字と小文字が区別されず、タグ値では大文字と小文字が区別されます。また、一部のリソース・タイプでは大文字と小文字を区別するネーミングが許可されています。たとえば、次のステートメントについて考えてみます:

    Group Aのユーザーは、タグOperations.Project= 'sample'を持つコンパートメントのリソースにアクセスできます。また、このユーザーは、タグOperations.Project= 'Sample'を持つコンパートメントのリソースにもアクセスできます。

    >allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'sample'
    

  • タグベースのアクセス制御を導入する場合は、定義するタグの中に事前定義済の値を使用することを考慮してください。事前定義済の値の作業に関する項を参照してください。

  • ポリシー変数request.principal.compartment、request.principal.groupおよびtarget.resource.compartment.tagは、すべてのOCIサービスでサポートされています。ただし、ポリシー変数target.resource.tagは、すべてのサービスでサポートされるわけではありません。サポートされるサービスを参照してください。

    高度な条件付きIAMポリシー機能については、タグベースのアクセス制御および時間ベースのアクセス制御を参照してください。

コンパートメントおよびタグに関する推奨事項

コンパートメントおよびタグを設定する際には、次の推奨事項を使用してください:

• コンパートメントは、特定のカテゴリのリソースに対して作成および指定します。また、アクセス権が必要なユーザー・グループのみに対してリソースへのアクセスを許可するIAMポリシーを記述します。
• 本番ワークロードと非本番ワークロードを別々のコンパートメントに分けます。
• レイヤーをより組織的にするために、子コンパートメントを作成および使用してリソースを分離します。コンパートメント・レベルごとに個別のポリシーを記述します。
• 権限のあるユーザーのみがコンパートメントを別の親コンパートメントに移動し、リソースをコンパートメント間で移動できるようにします。この制限を適用するための適切なポリシーを記述します。
• コンパートメント・レベルの割当て制限を設定することで、コンパートメント内に作成できる各タイプのリソースの数を制限します。
• IAMポリシーでコンパートメントを指定することで、インスタンス・プリンシパルが管理できるリソースを制限します。
• ビジネス・ニーズに基づいてリソースを編成および識別するために、リソースにタグを割り当てます。
  • コンパートメントおよびタグ付けを使用して、アクセス管理を簡素化します。OCIコンパートメント設計を部門またはプロジェクト構造と連携させます。詳細は、コンパートメントの管理を参照してください。
  • タグベースのアクセス制御を導入した場合は、必ず、誰がタグを適用できるかを統制する適切な制御を設定してください。
  • ポリシーの適用後に、グループ、ユーザーまたはリソースにタグを適用すると、リソースへのアクセス権が付与される可能性があることに注意してください。
• コンパートメントはできるだけ少なくしてください。これにより、OCIコンソールでの参照の複雑さが軽減されます。
• ネットワークセキュリティと組み合わせてはいけません。コンパートメントが実際のワークロードに与える影響は限られています。

複数の環境

次の情報では、環境構造を設計するための環境分離計画のサンプルを示します。組織では、これらの戦略の組合せが必要になる場合があります。

ノート:ダイアグラムは参照アーキテクチャではありませんが、設計を考慮したユースケースの例を示します。

• タイプ0:この環境分離には、リソース共有は含まれません。これは、通常、リソース分離の最大レベルのテナンシ構造です。前述の戦略的ビジネス上の理由以外に、変更管理プロセスをサポートするためにこのタイプの環境が必要になる場合もあります。たとえば、クラウド・プラットフォーム・チームがテナンシレベルの変更をロールアウトするためのテスト環境やカナリア環境が必要になり、アプリケーション・チームに一度に大きな混乱が生じるのを防ぐことができます。
• タイプ1:この環境分離では、OCIサービス有効化ポリシーや緊急アクセス管理者など、ルート・コンパートメントで最小限のリソースを共有します。専用コンパートメントと追加のアイデンティティ・ドメインを使用すると、単一のテナンシ内に、独自のアイデンティティ・プロバイダ、アクセス・ポリシーおよびクラウド・リソースを持つ複数の高度に分離された環境を持つことができます。
• タイプ2:この環境分離では、コストと管理効率を向上させるために、アイデンティティ・ドメインや高速接続などの一部の選択的なキー・サービスが共有されます。通常は、UAT、SIT、DEVなど、非本番環境で使用されます。組織によっては、本番環境および本番前環境の演習も受け入れます。
• タイプ3:この環境分離では、セキュリティ・サービスやネットワーキング・サービスなど、すべてのコア・プラットフォーム・サービスが共有されます。通常は、一般的な制御ポリシーを使用して同様の性質のワークロードを管理するために使用されます。
• タイプ4:この環境分離は、ミドルウェア、OKE、DBなどのワークロード・インフラストラクチャを複数のアプリケーション・インスタンス間で共有します。

IAMのベスト・プラクティス

IAMのベスト・プラクティスに関する最新情報は、アイデンティティおよびアクセス管理のベスト・プラクティスを参照してください。ハイライト:

• 日常的なアクティビティには、デフォルト・ドメイン管理者グループや、アイデンティティ・ドメイン管理者ロールを持つユーザーは使用しないでください。かわりに、OCIで特定のリソースを管理するための個別の管理者を作成します。
• デフォルト・ドメイン管理者グループに属し、デフォルト・ドメイン内でアイデンティティ・ドメイン管理者ロールを持つユーザーを定期的にチェックします。これらの2つのグループに属するユーザーはスーパー管理者であり、OCIのすべてのリソースを管理できます。
• デフォルト・ドメインをスタータ・ドメインとして使用します。デフォルト・ドメインのユーザーのみがOCIのリソースにアクセスまたは管理できるだけでなく、セカンダリ・ドメインのユーザーもすべてのOCIリソースにアクセスおよび管理できます。
• アイデンティティ・セグメンテーション(消費者と従業員)、環境の分離(開発、テスト、本番)、データ・レジデンシ要件(特定の地理的リージョンへのドメインの作成)など、様々なユース・ケースのために他のセカンダリ・ドメインを作成します。
• 強力なデータ・レジデンシ要件に対処するにはセカンダリ・ドメインを使用することをお薦めします。セカンダリ・ドメインを使用すると、ドメインをレプリケートする地理的リージョンを選択できます。

詳細の参照

• Oracle Cloud Infrastructureでのアイデンティティおよびアクセス管理(IAM)のベスト・プラクティス

• リソースの分離とアクセス制御
• タグ付けを使用したOCIリソースのネーミング規則の実装