目標

• アカウント間でリソースを共有する利点を理解する
• アカウント間でリソースを共有するためのさまざまな手法について説明します。

リソース共有の概要

複数のアプリケーションがアクセスし、同じリソースまたはその一部を使用することは珍しくありません。 一例として、アプリケーションと計算環境が同じ企業ネットワーク上で稼働する必要がある場合が挙げられます。 もう 1 つのシナリオは、セキュリティー・ログが中央ストレージに収集されることです。 マイクロサービス・アーキテクチャーでは、外部リソースにアクセスして使用するようにサービスを構成する必要があります。 さらに、共有リソースはアクセスを許可する必要があり、共有リソース間のネットワークはそのようなコラボレーションをサポートするように構成されますが、それ以上は構成されません。

リソース共有の典型的なユース・ケースには、以下のものがあります。

• セキュリティー関連インフラストラクチャーの一元管理。 専用アカウントからセキュリティーをモニターし、セキュリティー・ログを 1 つの場所に集約します。 セントラル鍵管理システム (KMS) 内のすべての暗号鍵を管理します。
• ネットワーク・アドレスとサブネットの調整。 アプリケーションと計算環境は、同じネットワークに適合する必要があり、アドレス範囲とドメイン・ネームの共有を必要とします。
• 災害復旧のためのリソースの一元管理( IBM Cloud Backup for Classic などのバックアップ・サービスを含む)。 アプリケーションとそのサービスは高可用性を実現するように設計されている場合がありますが、最悪の場合には、中央で編成された追加のリソースをフォールバックすることができます。 これには、世界中で使用可能な複数のリソース・コピーを保持することも含まれます。例えば、 複製された Object Storage バケット に保管されます。
• より高額なサービスを共有することでコストを制御 (可能な場合)。 すべての開発プロジェクトが、すべてのサービスを専用インスタンスとしてデプロイする必要があるわけではありません。 多くの場合、アカウント内またはアカウント間でサービス・インスタンスを共有するだけで十分です。 実稼働環境の場合でも、コスト/価値要因と技術的な実現可能性によっては、サービス・インスタンスが共有されることがあります。 これは、 プライベート・カタログを使用してアカウント内の使用可能なサービスを制限し、パブリック・カタログ を制限してから、制限されたサービスのインスタンスを一元的に提供することによって編成できます。
• 企業レベルまたはビジネス単位でのリソースの一元管理。 これは、ブランド設定や一元管理されたテンプレート、基本イメージ (仮想マシン、コンテナー) などに必要な資産である可能性があります。 ここでも、プライベート・カタログと Container Registry は標準的なサービスです。
• 不足しているリソースをより多くのユーザーが使用できるようにします。 場合によっては、リソース・タイプは限られた数量でしか使用できないことがあります。 共有することで、より多くのアプリケーションがメリットを得ることができます。 これには速度制限が必要な場合があります。

セキュリティー・リソースの共有

多くの場合、セキュリティーは企業レベルで管理され、企業全体のルールが適用されます。 したがって、制約も中央で管理されます。 これは、ワークロードをクラウド環境に移行する場合にも当てはまります。 リソース共有は、セキュリティーを一元的に管理するとともに、コンプライアンスを評価して適用することを基盤としています。

上記の図は、以下のシナリオを示しています。

1. アカウント A および 勘定科目 B の Object Storage および Databases for MongoDB のインスタンスは、 Key Protectの メイン・アカウント で管理される暗号鍵を使用します。
2. 「メイン・アカウント」 の Security and Compliance Center は、3 つのアカウントすべてのリソースを管理します (上記の黒線を参照)。
3. アカウントAとアカウントB の IBM Cloud Activity Tracker Event Routingのインスタンスは、メインアカウントのIBM Cloud Logsに監査ログを送信する（上の青い線を参照）。 IBM Cloud Logsは、分析および企業要件を満たすために監査ログを永続化するように設定される。

共有は、 IBM Cloud Enterprise 環境 のアカウント間で行うことも、正式なエンタープライズ組織なしで行うこともできます。

ネットワーク・リソースの共有

エンタープライズ・コンテキストでのクラウド・ネイティブ・アプリの設計と開発には、多くの場合、アドレス範囲とサブネット、ドメイン名、トラフィックのルーティングなどのネットワーク・リソースに関する調整が伴います。 さまざまなアカウントとそれらのアプリケーションおよび計算環境をネットワークとその構造に適合させる必要があります。 これには、ネットワーク・リソースの共有が必要です。

1. 3 つのアカウント間で VPC 環境とクラシック・インフラストラクチャーを相互接続するには、 Transit Gateway サービスを使用します。
2. 各アカウントには、プライベート・ドメイン・ネームを管理するための DNS Services インスタンスがあります。 インスタンスは、DNS ゾーンを共有するために接続されます。

リソース共有の実装

概要に記載されているように、1 つの (クラウド) アカウント以外のサービスにアクセスするのが一般的な手法です。 統合のレベルに応じて、サービス・アクセスを許可して認証を実装する方法は異なります。 これらの使用可能なオプションについて、以下で説明します。

サービス間許可 (Service-to-service authorization)

あるサービスが別のサービスにアクセスするためのより緊密な統合アプローチは、 サービス間許可(s2s 許可)を確立する ことです。 ソース・サービスにターゲット・サービスへのアクセスを許可する IBM Cloud Identity and Access Management (IAM) ポリシーを作成します。 認証はアクセスを要求するソース・サービスを識別することによって行われるため、パスワードまたは API キーの形式の資格情報は必要ありません。 IAM ポリシーが作成されるため、認証と許可の両方が自動的に処理されます。

アカウント間の許可

IAM は、別の IBM Cloud アカウント内のソース・サービスと現在のアカウント内のターゲットとの間でサービス間許可を確立することをサポートします。 そのため、IAM 許可ポリシーを作成することで、アカウント間でリソースを共有できます。 このようなポリシーはさまざまな方法で作成できます。例えば、以下に示すように、 ブラウザー・コンソールで CLI を使用したり、Terraform コードを実行したりすることができます。

以下の例では、ソース・アカウント内の特定の Object Storage インスタンスに、現行アカウント内の特定の Key Protect インスタンスに対する リーダー 役割が付与されます。

以下に、 同じ IAM 許可ポリシーを持つリソースを作成するための Terraform コードを示します。

resource "ibm_iam_authorization_policy" "cross_account_policy" {
  source_service_account      = data.ibm_iam_account_settings.account_a_settings.account_id
  source_service_name         = "cloud-object-storage"
  source_resource_instance_id = data.ibm_resource_instance.cos_resource_instance.guid

  target_service_name         = "kms"
  target_resource_instance_id = data.ibm_resource_instance.kms_resource_instance.guid

  roles                       = ["Reader"]
  description                 = "read access on Key Protect in Main Account for Account A"
}

iam service-policy-create コマンドを使用した IBM Cloud CLI を使用して、同じ許可ポリシーを作成できます。

ibmcloud iam authorization-policy-create cloud-object-storage kms Reader --source-service-account source_account_id --source-service-instance-id cos_instance_id --target-service-instance-id kms_instance_id

コンソール、Terraform プロバイダー、および CLI はすべて、 IAM ポリシー管理 API を使用してポリシーを作成します。

次のステップとして、許可ポリシーを適用して、 Key Protect ルート鍵を使用する暗号化ストレージ・バケットを作成できます。 以下に、リソース ibm_cos_bucketを使用する Terraform コードを示します。 属性 key_protect は、ルート鍵の CRN を保持します。

resource "ibm_cos_bucket" "cos_bucket" {
  bucket_name          = "cos-bucket"
  resource_instance_id = data.ibm_resource_instance.cos_resource_instance.id
  region_location      = var.region
  key_protect          = data.ibm_kms_key.central_kms_root_key.id
  storage_class        = "smart"
}

GitHub リポジトリー cross-account-resource-sharingには、さらに多くの例があります。

サービス間の標準的な許可

Key Protect および Hyper Protect Crypto Services などの鍵管理サービス (KMS) への依存関係は、クラウド・ベースのソリューションでは標準的です。 KMS インスタンスは、お客様管理の暗号化のルート鍵を保持します。 ほとんどのサービスは、お客様が制御する暗号鍵をサポートします。 上記の例では、 cloud-object-storage (Object Storage) の代わりに、複数のアカウントで共有されている KMS インスタンスを他の多くのサービスで使用できます。

サービス間許可のためのその他の標準的な (ターゲット) サービス、およびリソース共有の候補には、以下のものがあります。

• Object Storage: いくつかのサービスでは、ストレージ・バケットにデータとログ・ファイルを保管する必要があります。 これには、アクセス・ログおよびモニター・データのアーカイブが含まれます。 その他のサービスは、データ分析を実行するためにバケットにアクセスする必要があります。 さらに、別のカテゴリーのサービスには、アクションの実行をトリガーするために変更通知をサブスクライブするためのアクセス権限が必要です。
• Event Notifications: イベントに関する情報をサブスクライバーにプッシュするには、サービス・インスタンスが Event Notifications インスタンスにアクセスする必要があります。
• Secrets Manager: このサービスは、他のサービス IAM API キー、SSL/TLS 証明書、およびその他のシークレットを保管し、提供します。 そのため、従属 (ソース) サービスは Secrets Managerにアクセスする必要があります。
• Cloud Internet Services (CIS): ドメイン・ネームおよびその他のネットワーク・データを管理するため、証明書の検証などに使用できます。
• IBM Cloud Logs Routing と IBM Cloud Activity Tracker Event Routing IBM Cloud Logsのようなターゲットへのサービスアクセスが必要。

上記のリストは完全ではないことに注意してください。

要約

リソースを共有する場合でも、異なるアカウントのリソースにアクセスするのは一般的な方法です。 ユーザーがリソース共有のメリットを得られるユース・ケースがいくつかあります。 これらについては概要で説明しています。 リソースにアクセスするためのユーザー ID とパスワードまたは API キーの組み合わせは、多くの場合、認証として機能します。 アクセスの範囲を一連の特権に限定することができます。例えば、読み取りアクセスのみを許可したり、他の一部の制限されたアクションを許可したりすることができます。 場合によっては、これらのタイプの資格情報は、アプリケーションや計算環境などのアクセス・リソースによって作成および管理できます (「サービス・バインディング」)。 資格情報を必要としない、さらに緊密な統合は、 IBM Cloud サービス間許可の概念です。 アクセスするリソース (ソース) とアクセスするリソース (ターゲット) は、それらのプロパティー (認証) によって識別され、アクセス・ロールが割り当てられます (許可)。 このような関係は、アカウント境界を越えて確立することもできます。 これにより、簡単に構成することができますが、アカウント間でのリソース共有は保護されます。

これらのサービスの一部のリソース共有をセットアップする方法のコード例は、 GitHub リポジトリー アカウント間リソース共有にあります。

関連リソース

以下の資料には、いくつかのクロスアカウント・シナリオの詳細が記載されています。

• IBM Cloud ユーザーの API キーは、複数のアカウントにわたってスコープを持つことができます

複数のアカウント間でのリソースの共有に関連するブログ投稿:

• IBM Cloud
• IBM Cloud CLI を使用するためのヒントとアドバイスでは、CLI から複数のアカウントを操作するために使用できる IBMCLOUD_HOME について説明します。