EUベースの組織事例

各種機能の詳細は有益ですが、環境の実装例を示すと役立ちます。次の例では、サブSCユーザーの概念を紹介します。

サブSCユーザーには、次の特性があります。
  • 組織または条約によって顧客エンティティに直接関連し、顧客エンティティとの政府関係または商業関係があります。
  • EU内に完全に含まれており、少なくとも顧客エンティティ自体と同じデータ保護および主権要件の対象となります。
  • これらは、単に顧客自体の組織グループではなく、独自のエンティティです。これは、政府部門でも、商用企業エンティティの子会社でもかまいません。データ保護および分類に関する要件のスーパーセットがある場合がありますが、顧客エンティティ自体の最小要件を下回ることはできません。たとえば、顧客がコンパートメントとリソースのセットを単独で保守し、サブSCユーザーにアクセス権を提供した場合、顧客はサブSCユーザーの特定の法的フレームワークに従って、サブSCユーザーがデプロイしたリソースに対する制御を維持します。
このケース・スタディでは、仮想的な状況を使用して、顧客が一連のクラウド・サービスを子会社組織またはサブSCユーザーに提供することを希望しています。これには、サブSCユーザーが、顧客自体が提供するグローバル・サービスと対話する独自のサービスをホストする機能も含まれます。顧客は、コスト、テナンシ全体のコンパートメントの割当て、およびテナンシの管理のためのグローバル・グループの作成に関してテナンシを制御します。ただし、各サブSCには独自の環境があり、コンパートメント・スペースによって定義され、ユーザー・ベースによって完全に制御され、アイデンティティ・ドメインを介して提供されます。各サブSCの子コンパートメントまたはルート・コンパートメント内で、追加のコンパートメントを作成し、リソースをデプロイできます。

サブSCコンパートメントは各サブSCユーザーに排他的であり、他のサブSCユーザーはコンパートメント構造、リソースまたは他のサブSCユーザーのアクティビティを参照できません。監査ログおよびその他の監査およびコンプライアンス・アクティビティは顧客レベルで行われますが、個々のルート・コンパートメントによってフィルタされ、可視性のためにアイデンティティ・メンバーシップに基づいて制限される各アイデンティティ・ドメインで可視化されます。これにより、顧客と個々のサブSCユーザーは、コスト、コンプライアンスおよび脅威の検出を個別に監査できます。作成されたリソースは、顧客(独自のコンパートメント用)と各サブSCユーザーの両方が判断し、EU Sovereign CloudのOCIコンパートメント割当て制限および予算機能によって制限できます。

サンプル・セキュリティ・モデル

この例のセキュリティ・モデルを次の図に示します。


iam-security-model.pngの説明が続きます
図iam-security-model.pngの説明

iam-security-model-oracle.zip

ここでは、お客様はテナンシを確立し、各サブSCメンバーが使用するコンパートメントのセット(ディビジョン・コンパートメント)とベース・コンパートメントのセットの両方を構築します。各サブSCユーザーがテナンシ内のリソースを使用するようにサインアップすると、サブSCユーザー用に作成された特定の上位レベルのコンパートメントの周りにアイデンティティ・ドメインが作成されます。サブSCユーザーは、自分のユーザー・ベースを個々のアイデンティティ・ドメインにフェデレートし、顧客によって割り当てられたものとは無関係に権限を割り当てることができます。これらのドメインは準独立エンティティとして動作し、共同契約に基づいて定義された関係を持つことができます。

データ保護のユースケース

サブSCユーザーには、EU Sovereign Cloudを使用してデータ保護を開始するための複数の非独占オプションがあります。まず、前述の既存のデータ保護モデルを使用します。サブSCアイデンティティ・ドメインは、テナンシ全体にわたって一時的です。つまり、アイデンティティ・ドメインはテナンシ全体のリソースであるため、テナンシ全体に対して確立されたポリシーに基づいて、両方のリージョンでアクセス・オプションを使用できます。

コンパートメントもこのモデルに従います。これにより、各サブSCユーザーは、2つのデータ・リージョン間で独自のコンパートメント内に作成された個々のリソースを使用して、レプリケーション・ターゲットまたはソースとして機能し、データ・レプリケーションを実行できます。これにより、サブSCによってデプロイされた個々のアプリケーションの機能、およびアクティブ/アクティブで動作できないアプリケーションのRTO/RPO許容度に応じて、データ保護のアクティブ/アクティブ/アクティブ/パッシブ・モデルを使用できます。データ保護は独立しており、他のサブSCユーザーの視点から分離されます。お客様は、レプリケーションが存在するという事実に基づいてベースライン・サービスを提供するが、データ自体を監視することはできないことを監視できます。バックアップまたはスナップショット・サービス(あるいはその両方)は、サブSCユーザー(ブロック・ストレージおよびオブジェクト・ストレージの場合)が使用でき、他のサブSCユーザーがアクセスできない各サブSCユーザーのアイデンティティ・ドメイン/コンパートメントにローカライズされます。

または、各サブSCユーザーは、データ保護ターゲットとしてサードパーティーまたはローカル(サブSC環境の物理境界内)リソースを使用することもできます。これは、サブSCユーザーの制御内でコンパートメントへのプライベートFastConnectまたはCPE VPN接続を確立することで実現されます。各接続ポイントは、サブSCユーザー自体のアイデンティティ・ドメイン/コンパートメント構造内に排他的に存在するため、データ接続は、他のサブSCユーザーと顧客から完全に分離されます。このモデルでは、個々のサブSCユーザーのニーズに応じて、顧客の制御外にあるサード・パーティ、サブSC環境の物理的範囲内にあるローカル・データ・リポジトリまたはその組合せにデータを保護および抽出できます。


security_structure_overview.pngの説明が続きます
図security_structure_overview.pngの説明

security_structure_overview-oracle.zip