ノート:

タグ・ベースのOracle Cloud Infrastructure Identity and Access Managementポリシーの詳細

イントロダクション

Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)ポリシーは、堅牢でセキュアなクラウド環境の基盤です。OCIリソースへのアクセスを制御する強力で柔軟なメカニズムを提供し、認可されたユーザーとサービスのみが指定されたリソースに対して特定のアクションを実行できるようにします。

OCI IAMポリシーの中核は、人間が読める構文で記述された宣言文のセットで、誰が何にアクセスできるか、どの条件でアクセスできるかを指定します。これらのポリシーにより、組織は最小権限の原則を適用でき、ユーザーおよびサービスにタスクの実行に必要な権限のみを付与でき、それ以上何も付与できません。これにより、運用効率を維持しながらセキュリティ・リスクを最小限に抑えることができます。

OCI IAMポリシーは、コンパートメント、テナンシ、特定のリソースなど、OCI階層の様々なレベルで適用されるため、複雑な組織構造に高度に適応できます。OCIのポリシー継承と区分化により、管理者は特定のセキュリティおよび運用要件に合せたきめ細かい制御を確立できます。OCIポリシーの詳細は、ポリシーの開始を参照してください。

このチュートリアルでは、ポリシー最適化の重要性、最適な結果を達成するためのポリシーの微調整のベストプラクティス、およびポリシー最適化を最大限に活用できるシナリオのハイライトについて説明します。

目的

前提条件

ポリシーのコンポーネントと構文の判別

OCI IAMポリシーを効果的にチューニングするには、その構造と主要コンポーネントを理解することが不可欠です。OCIのポリシーでは、誰が(プリンシパル)、何を(アクション)、どこで(スコープ)するかを指定することで、権限を定義します。これについて説明します。

OCI IAMポリシーの主要コンポーネント

ボーナス・ヒント: OCI IAMポリシーでのSet-Intersectの概念の理解

OCI IAMポリシーのset-intersectは、2つの値セット間に重複がある場合にのみアクセス権を付与するために使用されます。これにより、ポリシー内の特定のユーザーまたはグループをハードコーディングするのではなく、グループ・メンバーシップ、リソース・タグまたはその他の属性に基づいて権限が動的に付与されます。

大規模向けのOCI IAMポリシー・モデル

OCI IAMポリシーは、OCI上のワークロードを保護する基本的な要素の1つです。大規模なワークロードをお客様向けに拡張してサポートすることは非常に重要です。そのため、OCIのポリシー制限内で、あらゆるサイズのワークロードに対応できる少数のポリシーを必要とするポリシー・モデルを作成しました。次に、スケーラブルなポリシー・モデルを採用する理由をいくつか示します。詳細は、アイデンティティ・ドメインのあるIAMの制限を参照してください。

OCI IAMポリシーのチューニングは、OCIのポリシー制限内に留まりながら、セキュアでスケーラブルかつ効率的なクラウド環境を維持するための重要なタスクです。このプロセスが不可欠な理由は次のとおりです。

ポリシー管理でのタグ付けの役割

タグ付けは、リソースに対するきめ細かな制御を可能にすることでポリシー管理を大幅に強化するOCIの強力な機能です。タグは、キーと値のペアとして表されるメタデータ・ラベルで、リソースにアタッチできます。アクセス制御は、特に複数のチームやプロジェクトを持つ複雑なクラウド環境で、大規模な編成、管理および実施に役立ちます。詳細は、タグ付けの概要に関する項を参照してください

タグ付けによってポリシー管理がどのように強化されるか

  1. リソース識別を簡素化:タグは、プロジェクト、環境、所有者、部門などの属性に基づいてリソースを分類する統一された方法を提供します。これにより、リソースの特定のサブセットにポリシーを適用するプロセスが簡略化されます。

    例: Project: ProjectXでリソースをタグ付けすると、ターゲット・アクセス・ポリシーが有効になります。

    Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'

  2. 動的ポリシー強制の有効化:リソース属性の変更に適応するタグに基づくポリシー。たとえば、新しいインスタンスにEnvironment: Productionというタグが付けられている場合、本番環境に定義されたポリシーが自動的に継承されます。

    サンプル・ポリシー:

    Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'

  3. マルチプロジェクトおよびマルチチーム・ガバナンスを合理化:タグは、リソースを特定のチームまたはプロジェクトに関連付けることで、アクセスを分離するのに役立ちます。これにより、複数のグループ間で権限を管理する際の複雑さが軽減されます。

  4. 自動化の促進:タグによって、リソースの作成、監視およびライフサイクル管理のワークフローを自動化できます。たとえば、コスト・トラッキング・スクリプトは、CostCenter: Marketingというタグが付いたすべてのリソースを取得して、詳細な経費精算書を生成できます。

  5. コスト管理およびレポートの改善:タグにより、特定のプロジェクト、部門または環境に対する詳細なコスト属性が可能になります。これにより、組織は支出を追跡し、予算をより効果的に最適化できます。

タグ・ガバナンス: タグ管理の制御

ポリシー管理の一貫性、信頼性、およびセキュリティを維持するには、タグの作成と変更を厳密に制御する必要があります。ガバナンスにより、タグが正しく適用され、組織標準に準拠することが保証されます。タグ管理を特定の個人またはグループのセットに制限することは、組織のクラウド環境内で制御、一貫性およびセキュリティを維持する重要な要素です。

リアル・ライフ・ユース・ケース向けのタグ・ベースのOCI IAMポリシー

前述のすべてを学習したので、実際のユース・ケースで、ユーザー原則とインスタンス原則のOCI IAMポリシーのチューニングに取り組んでみましょう。しかし、その前に、ユースケースに関係なくすべての顧客が必要とする一般的なポリシーがいくつかあります。

ユーザー・プリンシパルのOCI IAMポリシーのスケーリング

OCI IAMポリシー・モデル:このポリシー・モデルでは、属性ベースのアクセス制御とも呼ばれる、データ(ここではタグ)によって通知される、より管理しやすい少数のポリシーを記述することが目的です。アクセス制御用にターゲット・リソースまたはターゲット・リソース・コンパートメントに割り当てられているタグを権限タグと呼びます。

権限タグ:テナンシ内のすべての動詞(アクション)とリソース・タイプの組合せに対して権限タグを定義します。ターゲット・リソースのユーザーのグループに割り当てる必要がある一意の権限を定義します。リストは一度設定および完了していません。少数の許可タグから開始します。ポリシー・モデルに対するハンドルを取得したら、権限タグをさらに追加できます。このチュートリアルでは、permission tag namespaceをmgmtとして作成します。また、gnameという名前の1つのタグ・キーを使用して、タグ・ネームスペースを作成します(このinfosecをコールします)。

  1. 4つのリソース・タイプを持つ次のコンパートメント構造について、それらのリソースに対する管理権限および使用権限を割り当てるには、権限タグを作成します。

    権限タグ

  2. ターゲットに割り当てる必要があるすべての権限(ほとんどの場合コンパートメント)について、グループを作成します。リソース(コンパートメントのデフォルト・タグを使用)およびリソース・コンパートメントに権限タグを割り当てます。タグ値は、ターゲット・リソースに対する指定された権限を持つグループです。

    権限タグ・グループ

  3. 権限タグを定義したら、ポリシーを記述できます。最終的には、テナンシで定義された権限タグごとに1つのポリシーのみが必要になります。指定された権限に対して同じポリシーがテナンシ全体で動作します。

    権限タグ・ポリシー

  4. より多くのワークロードをオンボーディングする際、管理するリソース・タイプがさらに多い場合は、それらの権限タグに対する権限タグおよびポリシーを追加する必要がある場合があります。それ以外の場合は、既存の権限タグを、アクセス権を持つユーザー・グループを持つ新しいワークロードに割り当てます。新しいワークロードに対して新しいポリシーを記述する必要はありません。

このアプローチは、OCI IAMグループおよびポリシーを定義する基盤となる、ここで説明するすべての例で一貫性を保ちます。

例1: すべてのアプリケーションのコンパートメント

ステップ1: 顧客のビジネス概要を包括的に理解する

CompanyAは、クライアント向けに複数のクラウドネイティブ・アプリケーションを開発およびデプロイする、成長するテクノロジー企業です。各アプリケーションは、厳格なセキュリティとコンプライアンス要件を備えた特定の顧客セグメントに適合します。CompanyAは、分離、スケーラビリティおよび効率的なアクセス制御を確保するために、構造化された区分化アプローチを使用してOCIリソースを編成します。

ステップ2: ワークロードのコンパートメント構造の設計

説明されているように、CompanyAは、OCI IAMポリシーをスケーリングするためのOCI IAMポリシー・モデルに従います。リソースの分離を維持するために、アプリケーション用に個別のコンパートメントが作成されています。

ユース・ケース1

ノート: mgmtおよびinfosecタグ・ネームスペースを管理できるのは管理者のみです。

ステップ3: タイプVerb+Resourceの組合せの次の権限タグの設計

OCIでグループを作成します。

  1. グループを作成する権限を持つ管理アカウントでOCI IAMドメインにログインします。

    OCIホーム

  2. 「アイデンティティとセキュリティ」に移動して、「アイデンティティ」の「ドメイン」をクリックします。

    ドメイン

  3. コンパートメントを選択し、グループを作成するドメインをクリックします。

    ドメインの選択

  4. 「グループ」をクリックします。

    グループ

  5. 権限タグに基づいてグループを定義します。(オプション)ユーザーをこれらのグループに追加します。

    グループの作成

ノート:権限とターゲットの一意の組合せに対してグループを作成する必要があります。同じ機能グループのユーザー(NetworkAdmin)が、すべてのターゲットでネットワークを管理するためのアクセス権を持っている必要がある場合、すべてのターゲットでアクセスを管理するには1つのグループのみが必要です。

次に、これらのタグの権限タグとOCI IAMグループを示します。前述のステップに従って、定義された各権限タグのグループを作成します。

  1. ルート・コンパートメント:ルート・コンパートメントは、最上位の管理レイヤーとして機能します。ここで、管理者グループが権限タグでタグ付けされます。次のタグがあります。

    • 管理者:テナンシ管理全体を管理するためのmanageall権限。
    • UseAdministrators:テナンシ全体のリソースにアクセスするためのuseall権限。
    • 監査者:テナンシ全体を監視するためのリソースへの読取り専用アクセス権を持つreadall権限。

  2. アプリケーションごとのコンパートメント・モデル: CompanyAには、複数のクラウドベースのアプリケーションがあります。アプリケーションごとに個別の親コンパートメントを作成します。このモデルが、親コンパートメントとしてアプリケーション1 (App1)およびアプリケーション2 (App2)にどのように適用されるかを確認します。

    • アプリケーション1 (App1): OCIでホストされる顧客向けアプリケーション。

      • ネットワーク・コンパートメント: VCN、サブネットなど、すべてのネットワーク関連リソースのコンパートメント。ここで、権限タグとそれぞれのOCI IAMグループを作成します。
        • App1NetworkAdmin: managenetwork App1のネットワーク・リソースを管理するエンジニア用のリソース権限タグ。
        • App1NetworkUser: usenetwork App1のネットワーク構成へのアクセスを制限する必要がある開発者向けのリソース権限タグ。
        • App1NetworkReader: readnetwork App1のネットワーク設定を検証する監査者のリソース権限タグ。
      • コンピュート・コンパートメント:コンピュート・インスタンスのコンパートメント。ここで、権限タグとそれぞれのOCI IAMグループを作成します。
        • App1ComputeAdmin: managecompute App1バックエンドのコンピュート・インスタンスをプロビジョニングおよびスケーリングするシステム管理者用のリソース権限タグ。
        • App1ComputeUser: usecompute App1のバックエンド・サービスをデプロイおよびテストする開発者向けのリソース権限タグ。
        • App1ComputeReader: readcompute App1のコンピュート・リソース使用率を監視する監査者用のリソース権限タグ。
      • データ・コンパートメント:データベースおよびストレージ関連リソースのコンパートメント。ここで、権限タグとそれぞれのOCI IAMグループを作成します。
        • App1DataAdmin: App1のOracle Autonomous DatabasesおよびOCI Object Storageを管理するデータベース管理者用のmanagedbリソース権限タグ。
        • App1DataUser: usedb App1に関する分析のためにデータセットにアクセスするデータ・サイエンティストのリソース権限タグ。
        • App1DataReader: readdb App1のデータベース構成を確認する監査者のリソース権限タグ。

    • アプリケーション2 (App2): CompanyAの業務のための内部エンタープライズ・リソース・プランニング(ERP)システム。

      ノート:ここでも、同じコンパートメント構造のアプローチに従い、親App2コンパートメントの下にネットワーク・コンパートメント、コンピュート・コンパートメントおよびデータ・コンパートメントを作成します。冗長性を回避するために、App2の権限タグとOCI IAMグループをノートにとります。

      • ネットワーク・コンパートメント:

        • App2NetworkAdmin: managenetworkリソース権限タグ。
        • App2NetworkUser: usenetworkリソース権限タグ。
        • App2NetworkReader: readnetworkリソース権限タグ。

      • コンピュート・コンパートメント:

        • App2ComputeAdmin: managecomputeリソース権限タグ。
        • App2ComputeUser: usecomputeリソース権限タグ。
        • App2ComputeReader: readcomputeリソース権限タグ。

      • データ・コンパートメント:

        • App2DataAdmin: managedbリソース権限タグ。
        • App2DataUser: usedbリソース権限タグ。
        • App2DataReader: readdbリソース権限タグ。

ノート:ターゲット(ターゲットはリソースまたはコンパートメント)に権限タグを適用して、App1およびApp2のターゲットに対する特定の権限をどのグループに付与するかを指定します。

ステップ4: これらの権限タグに対するOCI IAMポリシーの記述

CompanyAのポリシーは、ここで説明するのと同じアプローチを使用して作成します: より少なく- グループのOCI IAMポリシーのスケーリング。このためには、gnameという名前のタグ・キーを1つ持つタグ・ネームスペースを作成します(このinfosecをコールします)。

  1. ポリシーを作成する権限を持つ管理アカウントでOCI IAMドメインにログインします。

    OCIホーム

  2. 「アイデンティティとセキュリティ」に移動して、「アイデンティティ」の「ポリシー」をクリックします。

    ポリシー

  3. ルート「コンパートメント」を選択して、「ポリシーの作成」をクリックします。

    ポリシーの作成

  4. ポリシーに「名前」、「説明」と入力し、ポリシー・ステートメントも追加します。「作成」をクリックします。

    • すべてのリソース・ポリシー:

      Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall)
Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall)
Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)

      ポリシー・ステートメント

      ノート:次のすべてのポリシーを定義し、それぞれのポリシー・ステートメントを追加するには、同じ手順に従います。

    • Cloudguardポリシー:

      Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm)
Allow any-user to use cloud-guard-family in tenancy where
sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm)
Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)

    • ネットワークポリシー:

      Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork)
Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork)
Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)

    • コンピュート・ポリシー:

      Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute)
Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute)
Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)

    • データベース・ポリシー:

      Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb)
Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb)
Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)

例2: すべての顧客/テナントのコンパートメント

ステップ1: 顧客のビジネス概要を包括的に理解する

CompanyBソリューションは、クラウド・インフラストラクチャ、データ管理およびアナリティクスでテナントベースのSaaSアプリケーションを提供する、主要な独立系ソフトウェア・ベンダー(ISV)です。CompanyBは、様々な業界の複数のクライアントにサービスを提供し、シームレスでセキュアかつスケーラブルなソリューションを提供します。その成功は、適切に設計されたコンパートメント構造を持つOCIを使用して、セキュリティとコンプライアンスの要件に準拠しながらリソースを効率的に管理することにあります。

ステップ2: ワークロードのコンパートメント構造の設計

CompanyBは、顧客のワークロードを分離し、専用のサブ・コンパートメントを作成しました。また、ネットワーク・コンパートメント、共有ストレージおよびデータベース・コンパートメントもあります。CompanyBでも、OCI IAMポリシーをスケーリングするためのOCI IAMポリシー・モデルに従います。

ユース・ケース2

ステップ3: タイプVerb+Resourceの組合せの次の権限タグの設計

グループを作成するには、例1ステップ3を参照してください。次で定義されているすべての権限タグのグループを作成する必要があります。

  1. ルート・コンパートメント- 集中ガバナンス:ルート・コンポーネントは、OCIテナンシ全体のすべてのリソースおよびアクティビティを監督するための中央レイヤーとして機能します。ここで、管理者グループが権限タグでタグ付けされます。次のタグがあります。

    • 管理者:テナンシ管理全体を管理するためのmanageall権限。
    • UseAdministrators:テナンシ全体のリソースにアクセスするためのuseall権限。
    • 監査者:テナンシ全体を監視するためのリソースへの読取り専用アクセス権を持つreadall権限。

  2. ネットワーク・コンパートメント- 操作のバックボーン:ネットワーク・コンパートメントはCompanyBのクラウド・ネットワーキング・インフラストラクチャをサポートし、すべてのリソース間の接続を可能にします。これには、Virtual Cloud Network (VCNs)、サブネット、ゲートウェイおよびロード・バランサが含まれます。権限タグとそのそれぞれのOCI IAMグループを定義します。

    • NetworkAdmin: managenetwork CompanyBのネットワーク・リソースを管理するエンジニア用のリソース権限タグ。
    • NetworkUser: usenetwork CompanyBのネットワーク構成へのアクセスを制限する必要がある開発者向けのリソース権限タグ。
    • NetworkReader: readnetwork CompanyBのネットワーク設定を検証する監査者のリソース権限タグ。

  3. テナント・コンパートメント- 顧客ワークロードごとに分離されたコンパートメント:テナント・コンパートメントは、クライアント(テナント)ごとにリソースとワークロードを分離するように構造化されています。これにより、CompanyBは、運用効率を維持しながらセキュアでプライベートなサービスを提供します。

    • テナント1コンパートメント:テナント1は、アプリケーション開発およびロギング・サービスにCompanyBを使用する主要なエンタープライズ・クライアントを表します。権限タグとそれぞれのOCI IAMグループは、次のとおりです:

      • t1devadmin:テナント1の開発チームに対するmanageappdevリソース権限には、カスタム・アプリケーションに対する管理権限、構成およびデプロイ権限があります。
      • t1devuser:アプリケーション・リソースをモニターおよび調整するためのuseappdevリソース権限。テナント1の開発者は、これらのリソースを日々の開発およびテストに使用します。
      • t1logsadminおよびt1devuser: managelogsおよびuselogsのロールをロギングおよびモニタリングするためのリソース権限により、管理者がロギング・サービスを構成し、開発者がログにアクセスしてアプリケーションをデバッグおよび最適化するようにできます。
      • t1devadminおよびt1devuser:テナント1のmanagecspmおよびusecspmリソース権限は、セキュリティ状態にも焦点を当てており、セキュリティ・リスクを監視および修正する機能があります。

    • Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like t2devadmin, t2devuser, t3devadmin, t3devuser, t2logsadmin and t3logsadmin ensuring that each tenant operates in a fully isolated environment.このアプローチにより、CompanyBは、特定のテナントのニーズに対応しながら、一貫したガバナンスを維持できます。

    • 共有コンパートメント- すべてのテナントの集中リソース:共有コンパートメントには、複数のテナントが利用するが、プライバシとセキュリティのために論理的に分離されたままであるデータベースやオブジェクト・ストレージなどのリソースが含まれます。

      • データベース・コンパートメント:
        • dbadmin: CompanyBのデータベース管理者に対するmanagedbリソース権限は、プロビジョニング、スケーリング、パッチ適用など、すべてのテナントが使用する共有データベースを処理します。
        • dbuser:テナント固有のユーザーに対するusedbリソース権限は、それぞれのデータベース・スキーマまたはサービスにアクセスします。
        • dbreader:監査者に対するreaddbリソース権限には、データベース構成がセキュリティ・ポリシーに準拠していることを確認するための読取り専用アクセス権があります。
      • ストレージ・コンパートメント: OCI Object Storageは、テナントごとに専用のバケットを使用して一元的に管理されます:
        • osadmin:共有オブジェクト・ストレージ・リソースの管理を担当するmanageobjectリソース権限。
        • osuser: useobjectテナント固有のストレージ・リソース権限(t1osur、t2osur、t3osurなど)は、テナントがそれぞれのバケットにのみアクセスするようにします。
        • osreader:コンプライアンス・チームのreadobjectリソース権限は、ストレージ構成および使用パターンを確認します。

ステップ4: これらの権限タグに対するOCI IAMポリシーの記述

ポリシーを作成するには、例1のステップ4を参照してください。次のポリシーを作成する必要があります。

例3: 大規模なエンタープライズ・コンパートメント構造

ステップ1: 顧客のビジネス概要を包括的に理解する

革新的なソフトウェア・ソリューションを専門とする多国籍企業であるCompanyC Solutionsは、ミッションクリティカルなワークロードをOCIに移行することを決定しました。同社は、財務やヘルスケアなどの規制の厳しい業界で事業を展開しており、セキュリティ、コンプライアンス、スケーラビリティが最も重要です。

ステップ2: ワークロードのコンパートメント構造の設計

次に、OCI IAMポリシーをスケーリングするためのOCI IAMポリシー・モデルに従ったCompanyCのコンパートメント構造を確認します。

ユース・ケース3

ステップ3: タイプVerb+Resourceの組合せの次の権限タグの設計

グループを作成するには、例1ステップ3を参照してください。次のすべての権限タグのグループを作成する必要があります。

  1. ルート・コンパートメント- 集中ガバナンス:ルート・コンポーネントは、OCIテナンシ全体のすべてのリソースおよびアクティビティを監督するための中央レイヤーとして機能します。ここで、管理者グループが権限タグでタグ付けされます。次のタグがあります。

    • 管理者:テナンシ管理全体を管理するためのmanageall権限。
    • UseAdministrators:テナンシ全体のリソースにアクセスするためのuseall権限。
    • 監査者:テナンシ全体を監視するためのリソースへの読取り専用アクセス権を持つreadall権限。

  2. PRODコンパートメント:業務およびエンドユーザーに直接影響を与えるミッションクリティカルな本番ワークロードをホストするためのコンパートメント。各アプリケーションには、リソースの分離と最適化された管理のための専用のサブコンパートメントがあります。権限タグとそのそれぞれのOCI IAMグループを定義します。

    • NetworkAdmin: managenetwork CompanyCのネットワーク・リソースを管理するエンジニア用のリソース権限タグ。
    • NetworkReader: readnetwork CompanyCのネットワーク設定を検証する監査者のリソース権限タグ。
    • ComputeAdmin: managecompute CompanyCのコンピュート・インスタンスをプロビジョニングおよびスケーリングするシステム管理者用のリソース権限タグ。
    • ComputeReader: readcompute CompanyCのコンピュート・リソース使用率を監視する監査者用のリソース権限タグ。
    • StorageReader:ストレージ管理チームがストレージ構成を管理するためのmanageobjectリソース権限。
    • StorageReader:コンプライアンス・チームのreadobjectリソース権限は、ストレージ構成および使用パターンを確認します。
    • SecurityAdmin: managecspm コンパートメントPRODのリソース権限は、セキュリティ・ポスチャにも焦点を当てており、セキュリティ・リスクを監視および修正する機能があります。

    次に、アプリケーション固有のサブ・コンパートメントの権限タグとそれぞれのOCI IAMグループを定義します。時間のために、3つの異なるアプリケーション・コンパートメントすべてに対する権限をマージおよび定義しました。

    • アプリケーション・コンパートメント:
      • PRApp1NetAdmin、PRApp2NetAdminおよびPRApp3NetAdmin: managenetworkリソース権限タグがApp1、App2およびApp3のネットワーク・リソースを管理するエンジニア用の管理OCI IAMグループ。
      • PRApp1NetUser、PRApp2NetUserおよびPRApp3NetUser: usenetworkリソース権限タグがApp1、App2およびApp3のネットワーク・リソースを管理するエンジニア用の管理OCI IAMグループ。
      • PRApp1ComputeAdmin、PRApp2ComputeAdminおよびPRApp3ComputeAdmin: managecomputeリソース権限タグがApp1、App2およびApp3のOCI Computeインスタンスを管理するエンジニア用のOCI IAMグループを管理します。
      • PRApp1ComputeUser、PRApp2ComputeUserおよびPRApp3ComputeUser: usecomputeリソース権限タグがApp1、App2およびApp3のOCIコンピュート・インスタンスを使用するエンジニアのOCI IAMグループを管理します。
      • PRApp1StorageAdmin、PRApp2StorageAdminおよびPRApp3StorageAdmin: manageobjectリソース権限タグがApp1、App2およびApp3のOCIオブジェクト・ストレージを管理するエンジニア用の管理OCI IAMグループ。
      • PRApp1StorageUser、PRApp2StorageUserおよびPRApp3StorageUser: OCI Object Storage for App1、App2およびApp3をそれぞれ使用しているエンジニアのuseobjectリソース権限タグを持つ管理OCI IAMグループ。

  3. NPRODコンパートメント: ステージング、開発および品質保証環境専用です。このコンパートメントは、一貫性を確保するためにPRODと同様に構造化されています。権限タグとそのそれぞれのOCI IAMグループを定義します。

    • NetworkAdmin: managenetwork CompanyCのネットワーク・リソースを管理するエンジニア用のリソース権限タグ。
    • NetworkReader: readnetwork CompanyCのネットワーク設定を検証する監査者のリソース権限タグ。
    • ComputeAdmin: managecompute CompanyCのOCIコンピュート・インスタンスをプロビジョニングおよびスケーリングするシステム管理者用のリソース権限タグ。
    • ComputeReader: readcompute CompanyCのOCI Computeリソース使用率を監視する監査者用のリソース権限タグ。
    • StorageReader:ストレージ管理チームがストレージ構成を管理するためのmanageobjectリソース権限。
    • StorageReader:コンプライアンス・チームのreadStorageリソース権限は、ストレージ構成および使用パターンを確認します。
    • SecurityAdmin: managecspm コンパートメントNPRODのリソース権限は、セキュリティ・ポスチャにも焦点を当てており、セキュリティ・リスクを監視および修正する機能があります。

    同様に、次に、アプリケーション固有のサブ・コンパートメントに対する権限タグとそれぞれのOCI IAMグループを定義します。

    • アプリケーション・コンパートメント:
      • NPApp1NetAdmin、NPApp2NetAdminおよびNPApp3NetAdmin: managenetworkリソース権限タグがApp1、App2およびApp3のネットワーク・リソースを管理するエンジニア用の管理OCI IAMグループ。
      • NPApp1NetUser、NPApp2NetUserおよびNPApp3NetUser: usenetworkリソース権限タグがApp1、App2およびApp3のネットワーク・リソースを管理するエンジニア用の管理OCI IAMグループ。
      • NPApp1ComputeAdmin、NPApp2ComputeAdminおよびNPApp3ComputeAdmin: managecomputeリソース権限タグがApp1、App2およびApp3のOCI Computeインスタンスを管理するエンジニア用のOCI IAMグループを管理します。
      • NPApp1ComputeUser、NPApp2ComputeUserおよびNPApp3ComputeUser: usecomputeリソース権限タグがApp1、App2およびApp3のOCIコンピュート・インスタンスを使用するエンジニアのOCI IAMグループを管理します。
      • NPApp1StorageAdmin、NPApp2StorageAdminおよびNPApp3StorageAdmin: manageobjectリソース権限タグがApp1、App2およびApp3のOCIオブジェクト・ストレージを管理するエンジニア用の管理OCI IAMグループ。
      • NPApp1StorageUser、NPApp2StorageUserおよびNPApp3StorageUser: OCI Object Storage for App1、App2およびApp3をそれぞれ使用しているエンジニアのuseobjectリソース権限タグを持つ管理OCI IAMグループ。

  4. 共有コンパートメント:共有コンパートメントは、ロギングやクラウド・ガードOCIサービスなどのモニタリング用のリソースをホストします。また、暗号化と復号化のための鍵も備えており、複数のテナントが利用しながら、プライバシーとセキュリティを維持するための論理的な分離を確保します。これらのサービスへのアクセスを必要とするアプリケーションからのすべての管理者が、これらのサービス用に作成されたOCI IAMグループに追加されます。権限タグとそのそれぞれのOCI IAMグループを定義しましょう。

    • Oracle Cloud Guardコンパートメント:

      • cspmAdmin: managecspmリソース権限タグを持つ管理OCI IAMグループで、PRODおよびNon PRODコンパートメントのOracle Cloud Guardを管理します。
      • cspmUser: usecspmリソース権限タグを持つOCI IAMグループ(PRODおよびNon PRODコンパートメントのOracle Cloud Guardを使用/監視するエンジニア用)。
      • cspmReader: Oracle Cloud Guard for PRODおよびNon PRODコンパートメントを読み取るエンジニア用のリソース権限タグがreadcspmのOCI IAMグループ。

    • OCIロギング・コンパートメント:

      • logsAdmin:管理者がPRODおよび非PRODコンパートメントのOCIロギングを管理するためのmanagelogsリソース権限タグを持つ管理OCI IAMグループ。
      • logsUser: uselogsリソース権限タグを持つOCI IAMグループ(PRODおよび非PRODコンパートメントのOCIロギングを使用/監視するエンジニア用)。
      • logsReader: PRODおよび非PRODコンパートメントのOCIロギングを読み取るエンジニアのreadlogsリソース権限タグを含むOCI IAMグループ。

    • キー・コンパートメント:

      • kmsAdmin: PRODおよび非PRODコンパートメントのキー・ボールトを管理するためのmanagekeysリソース権限タグを持つ管理OCI IAMグループ。
      • kmsUser: usekeysリソース権限タグを持つOCI IAMグループは、PRODおよびNon PRODコンパートメントのキー・ボールトを使用/監視するエンジニア用です。
      • kmsReader: PRODおよび非PRODコンパートメントのキー・ボールトを読み取るエンジニア用のreadkeysリソース権限タグを持つOCI IAMグループ。

  5. プレイグラウンド・コンパートメント:実験、開発およびテストのための柔軟で分離された環境。このコンパートメントは本番制約やコンプライアンス制約に関連付けられていないため、イノベーションに最適です。ここでは、非常に子コンパートメント用のOCI IAM管理グループは1つのみで、テスト要件に必要なすべてのOCIリソースに対する管理権限を付与します。

    • 開発コンパートメント:

      • DevAdmin: Dev Compartment内の新しい実装をテストするための開発管理者のmanagenetwork、managecompute、manageobject、managekeys、managelogsリソース権限がある管理OCI IAMグループ。

    • コンパートメントのテスト:

      • TestAdmin:テスト・コンパートメント内の新しい実装をテストするための開発管理者のmanagenetwork、managecompute、manageobject、managekeys、managelogsリソース権限がある管理OCI IAMグループ。

    • パフォーマンス・テスト・コンパートメント:

      • PerfTestAdmin:パフォーマンス・テスト・コンパートメント内の新しい実装をテストするための開発管理者のmanagenetwork、managecompute、manageobject、managekeys、managelogsリソース権限を持つ管理OCI IAMグループ。

ステップ4: これらの権限タグに対するOCI IAMポリシーの記述

ポリシーを作成するには、例1のステップ4を参照してください。次のポリシーを作成する必要があります。

ノート:このようなシナリオでは、新しいワークロードをオンボーディングするたびに次のようになります。

詳細なアクセス制御のためのタグ・ベースの権限モデル

これまでのすべての例では、リソース・ファミリに対する管理権限、ユーザー権限または読取り権限の作成について説明しました。ただし、ほとんどの顧客は、最小限の権限モデルに従うために、きめ細かいアクセス制御を必要とします。チュートリアルの焦点は、ポリシー・モデルの理解です。そのため、単純なユースケースについて説明しました。ただし、4人のネットワーク担当者の例と、その4人のペルソナに対してきめ細かい権限タグとOCI IAMポリシーを設計する方法について考えてみます。

networkowner、networkadmin、networkoperatorおよびnetworkuserは、ネットワーク・コンパートメントの4つのタグとして定義します。これらのタグには、ネットワーク・コンパートメントへのアクセス権を持つグループ名を割り当てます。

Instance PrincipalsのOCI IAMポリシーのスケーリング

例1: OCIの共有ストレージおよびシークレットに対するマルチテナント・インスタンス・アクセス制御

ステップ1: 顧客のビジネス概要を包括的に理解する

XYZ Cloud Solutionsは、OCIでホストされているドキュメント管理システム(DMS)を提供するSaaSプロバイダです。このプラットフォームは、複数の企業顧客にサービスを提供し、それぞれが共有インフラストラクチャを活用しながらデータを厳密に分離する必要があります。

顧客の要求:

ステップ2: ワークロードのコンパートメント構造の設計

ここでは、OCI IAMポリシーをスケーリングするためのOCI IAMポリシー・モデルに従ったXYZ Cloud Solutionsのコンパートメント構造について説明します。

インスタンス・ユースケース1

ステップ3: OCI IAMグループの作成

OCIマルチテナント環境でセキュアで分離されたアクセス管理を確保するために、次のポリシーが定義されます。

ノート:これらのグループおよびOCI IAMポリシーは、「共通OCI IAMポリシー」条項に記載のとおりすでに作成されています。

ステップ4: 定義済グループのOCI IAMポリシーの作成

テナント・リソース・アクセス・ポリシー:データの分離を維持するために、テナント・リソースは自身のシークレットおよびオブジェクト・ストレージにのみアクセスできる必要があります。

Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant

テナント・インスタンスの原則で新しいオブジェクトを作成する権限も必要な場合は、テナント名と同じ名前のバケット名を作成し、テナント名タグを使用してバケット名と比較できます。

Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name

例2: 共有OCIストレージ・モデルでのマルチサービス・データ・アクセスのファイングレイン・アクセス制御

ステップ1: 顧客のビジネス概要を包括的に理解する

XYZ Corpは、デジタル・トランスフォーメーション・ソリューションを専門とする急速に成長している企業です。グローバル・プレゼンスにより、XYZ Corpは複数のリージョンで事業を展開し、OCIを活用して重要なアプリケーションのホスティング、データの管理、チーム間のシームレスなコラボレーションを実現します。

顧客の要求:

ステップ2: ワークロードのコンパートメント構造の設計

ここでは、OCI IAMポリシーをスケーリングするためのOCI IAMポリシー・モデルに従ったXYZ Corpのコンパートメント構造について説明します。

インスタンス・ユースケース2

ステップ3: OCI IAMグループの作成

OCIマルチテナント環境でセキュアで分離されたアクセス管理を確保するために、次のポリシーが定義されます。

ノート: InfoSecおよびTerraform-RunnerグループとIAMポリシーは、「一般的なOCI IAMポリシー」の項の説明に従ってすでに作成されています。

ステップ4: 定義済グループのOCI IAMポリシーの作成

テナント・リソース・アクセス・ポリシー:データの分離を維持するために、テナント・リソースは自身のシークレットおよびオブジェクト・ストレージにのみアクセスできる必要があります。

Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}

Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}

Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}

Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}

承認

その他の学習リソース

docs.oracle.com/learnの他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。