目標

• クラウド・リソースを保護するためのコンテキスト・ベースの制限について説明します。
• 許可および拒否されたアクセスのトラフィック・ソースを識別するためのネットワーク・ゾーンの定義
• クラウド・リソースにアクセスするためのコンテキストを定義するルールを作成します
• コンテキスト・ルールをテストおよびモニターする方法を理解する

次の図は、チュートリアル「 クラウド・アプリケーションへのエンドツーエンド・セキュリティーの適用」で使用されるソリューション・アーキテクチャーを示しています。 Kubernetes Service クラスター、 Container Registry、 Key Protect、および Object Storage の周囲に破線と青色の線が付いた追加ボックスは、コンテキスト・ルールとして実装されたコンテキスト・ベースの制限を示します。 Secrets Manager も保護されている可能性がありますが、これはオプションのサービスであり、このチュートリアルでは使用されません。

開始前に

このチュートリアルでは、以下が必要です。

• IBM Cloud CLI
• コンテナー・イメージをプッシュおよびプルする docker クライアント。

これらのツールをダウンロードしてインストールする方法については、 チュートリアルガイド「ソリューションの始め方」 をご覧ください。

これらのツールのインストールを回避するには、xml-ph-0000@deepl.internalコンソールから Cloud ShellIBM Cloud コンソールから

セットアップ

後のステップ「 Terraform を使用したコンテキスト・ベースの制限の構成」では、チュートリアル「 クラウド・アプリケーションへのエンドツーエンドのセキュリティーの適用」で使用するリソースの上に、追加のセキュリティー層として CBR オブジェクトをデプロイします。

1. コンパニオン GitHub リポジトリーで説明されているように、 Schematics によって管理される Terraform を使用してリソースをデプロイします。

2. The IBM Cloud Activity Tracker Event Routing must be configured to route auditing events to a IBM Cloud Logs target instance. アカウントで現在構成されていない場合は、IBMLogs ターゲットの構成 で説明するように監査イベントをルーティングします。

概要: コンテキスト・ベースの制約事項

コンテキスト・ベースの制限(CBRs) は、ネットワーク・ロケーションとアクセス要求のタイプに基づいて IBM Cloud リソースのアクセス制限を定義して適用する機能を提供します。 IAMポリシーとコンテキストベースの制限の両方がアクセスを強制するため、コンテキストベースの制限は、侵害されたり誤って管理された認証情報に対しても保護を提供します。

ルールは、サービス名とタイプ、および追加属性によって識別されるリソースへのアクセスを管理します。 これらには、リージョン、リソース・グループ、およびその他のサービス固有のプロパティーを含めることができます。 ルール内の属性はほとんどオプションであるため、すべての Key Protect インスタンスを一緒に管理することも、識別された Key Protect インスタンス内の特定の鍵リングのみをターゲットにすることもできます。

制限のコンテキストは、ネットワーク・ゾーンとサービス・エンドポイントで構成されます。 特定の IP アドレスまたは範囲に基づいて、あるいは 1 つ以上の VPC またはクラウド・サービスから発信されるトラフィックを構成することによって、ゾーンを定義することができます。 これにより、サンプルの Key Protect インスタンスへのアクセスが許可されるのは、特定の Object Storage インスタンス、既知の IP アドレス範囲、およびプライベート・エンドポイントのみです。

ネットワーク・ゾーンは、複数のルールの定義に使用できます。 ルールには、無効、レポート専用、または有効のいずれかの適用モードがあります。

現時点では、すべてのクラウド・サービスがレポート専用モードをサポートしているわけではありません。 さらに、これらのサービスは、有効になっている場合、CBR 関連のログ・エントリーを生成しません。 詳しくは、個々のサービスの資料を確認してください。

ゾーンとルールの作成

コンテキスト・ベースの制限の影響を評価するために、 Container Registry内の名前空間へのアクセスを管理するルールを作成します。 最初にその名前空間を作成し、次に VPC をトラフィック・ソースとして識別するネットワーク・ゾーンを作成します。

1. Container Registryネームスペース に移動し、先に設定したネームスペースの名前をメモする。
2. IBM Cloud コンソールで、 「管理」 メニューをクリックし、 コンテキスト・ベースの制限 を選択します。 概要ページで、 「ネットワーク・ゾーンの作成」 をクリックします。
3. 名前に VPCzone と入力します。 「許可された VPC (Allowed VPC)」 の下で、 Kubernetes Service クラスターを含む VPC を選択します。 「次へ」 をクリックして確認し、ゾーンを 作成 します。
4. 次に、左側のナビゲーションで 「ルール」 をクリックし、 「作成」 をクリックして、ゾーンを使用するルールを作成します。
5. 「サービス」 セクションで Container Registry を選択し、 「次へ」 をクリックします。
6. 「API」 セクションの 「すべての サービス API」をそのままにして、 「次へ」 をクリックします。
7. 次に、 「リソース」 で 「特定のリソース」 を選択します。 属性として 「リソース・タイプ」 を選択し、値として namespace を指定します。 別の条件を追加し、Resource Name を NAMESPACE（ステップ1と同じ値）に設定する。 レビュー をクリックし、次に続行をクリックします。
8. 前に作成した VPCzone をリストから選択します。 次に、 「追加」 と 「続行」 を使用して、ダイアログの最後のステップに進みます。 「適用」 に 「レポートのみ」 のマークを付けます。 その後、ルールを作成します。

CBR ゾーンとルールは非同期的にデプロイされることに注意してください。 それらがアクティブになるまでには、最大で数分かかる場合があります (最終的には整合性が保たれます)。

ルールとその適用モードのテスト

1. 新しいブラウザ・タブで IBM Cloud Logsサービスを開き、クラウド・ログ・タブを選択して、監査イベントを受信しているインスタンス名をクリックします。

2. 別のブラウザー・タブで IBM Cloud Shell の新規セッションを開始します。

3. シェルで、以下のコマンドを実行します。 環境変数を、 Container Registryに使用するクラウド領域に設定します (例: us または de)。

   export REGION=us
   

   Container Registry名前空間に対して別の変数を設定する：

   export NAMESPACE=<YOUR_NAMESPACE>
   

   次に、 Container Registryにログインします。

   ibmcloud cr login
   

   次に、コンテナー・イメージをシェル環境にプルします。

   docker pull docker.io/library/hello-world:latest
   

   イメージを再タグ付けして、レジストリー名前空間にアップロードします。

   docker tag docker.io/library/hello-world $REGION.icr.io/$NAMESPACE/hello-world
   

   最後に、コンテナイメージをレジストリにプッシュします。

   docker push $REGION.icr.io/$NAMESPACE/hello-world
   

4. 監査ログを表示しているIBM Cloud Logsブラウザタブに切り替える。 レポートモードでは、判定結果に関係なく、ルールがマッチするとIBM Cloud Activity Tracker Event Routingにログエントリが書き込まれる。 ログ・レコードには、要求に関する詳細が含まれています。 以下の画像では、Container Registry名前空間へのアクセスを許可するルールがレポート・モードでマッチしています。

   

   前述のように、レポート・モードでは、一致するすべての要求によってログ項目が生成されます。 イベント詳細に、 「許可」 または 「拒否」 のいずれかの値を持つ属性 decision が表示されます。 上のスクリーン・ショットでは、 Deny です。

5. シェルを使用してブラウザー・タブに戻り、名前空間内のコンテナー・イメージをリストします。

   ibmcloud cr images --restrict $NAMESPACE
   

6. 3 番目のブラウザー・タブで、 「CBR ルール」 にナビゲートします。 先ほど作成したレジストリー関連ルールの横にあるドット・メニューをクリックし、 「編集」 を選択します。 「ルールの説明」(ステップ 3) に移動し、ルールを 「レポートのみ」 から 「有効」 に切り替えます。 「適用」 ボタンを押して、変更をアクティブにします。

7. IBM Cloud Shellを使用してブラウザー・タブに戻ります。 前と同じコマンドを発行して、イメージをリストします。

   ibmcloud cr images --restrict $NAMESPACE
   

   今回は、許可されていないことを示すエラー・メッセージが表示されます。

8. ログが表示されているブラウザー・タブで、以下のような新規レコードを見つける必要があります。

   

   規則が適用され、レジストリーにアクセスしようとした方法に基づいて、アクセスが拒否されました。 その理由は、ルールによって特定の VPC からのアクセスのみが許可されるためです。 Cloud Shell環境とそのIPアドレスは、requestData->environment フィールドのログに記録されているように、異なります。 したがって、要求は拒否されます。

IBM Cloud Logsのログを扱う場合、以下のようなクエリー文字列を使用すると、関連するログレコードを簡単に見つけることができます：

• レポート・モードの場合、 "context restriction" permit OR deny は、 「許可」 または 「拒否」 をレンダリングするアクセス権を持つログ行を返します。
• レポート・モードでは、 "context restriction" permit を使用して、許可されているアクセス権限のみを表示できます。 同様に、アクセスを拒否するには "context restriction" deny を使用します。
• 最後に、 enforced モードの場合、拒否されたアクセスに関連するログ行には、 context restriction rendered のような照会ストリングを使用します。

新規ルールのモニターは、強制する前に 30 日間行うことをお勧めします。 レポート専用モードと有効モードの両方での コンテキスト・ベースの制限 について詳しくは、CBR の資料を参照してください。

さらに下のセクションで Terraform を使用して CBR オブジェクトのデプロイメントを準備するには、 「CBR ルール(CBR rules)」 が表示されているブラウザー・タブに移動します。 そこで、以前に作成したルールを削除します。そのためには、そのドット・メニューをクリックして 「削除」 を選択し、 「削除」 で確認します。 その後、 「ネットワーク・ゾーン」 をクリックし、以前に作成したゾーンを削除します。

クラウド・リソースのアクセス戦略を定義する

コンテキスト・ベースの制限 (CBRs) に対して適切なルール・セットをセットアップするには、クラウド・リソースのアクセス戦略を定義しておく必要があります。 すべてのリソースは、ID およびアクセス管理 (IAM) によって保護する必要があります。 つまり、ユーザーまたはサービス ID がリソースにアクセスする前に、認証および許可検査を実行する必要があります。 CBRs は、発信元基準およびその他の規則に基づいてネットワーク・アクセスを遮断することによって保護を強化しますが、適切な IAM 構成に置き換わるものではありません。 さらに、多くのサービスでは、ネットワーク・トラフィックをプライベート・エンドポイントに制限することがサポートされているため、既にアクセス・オプションが削減されています。

一部のルールは、ブラウザー・コンソールなどを使用してリソースを管理することに影響を与える可能性があります。 さらに、リソース、管理ダッシュボード、および API へのアクセスを拒否しないようにする必要があります。 したがって、要塞ホスト、企業ネットワーク、ゲートウェイ、および場合によっては Cloud Shellも考慮する必要があります。 さらに、一部のサービスでは、データ・プレーンの詳細な区別と CBR 構成のためのプレース・アクセスの制御がサポートされています (例: Kubernetes Service クラスターおよび管理 API)。

要約すると、以下の質問をする必要があります。

• すべてのリソースは IAM によって保護されていますか?
• リソースはどのようにアクセスされますか? 可能な場合は既にプライベート・エンドポイントに制限されていますか?
• データ・プレーンとコントロール・プレーンのアクセスを分離できますか?
• 使用量に関連するトラフィックと、管理作業に関連するトラフィックとは何ですか? 緊急事態はどのように処理されますか?
• 上記のトラフィックはどこから発生していますか?

レポート・モードを使用して、コンテキスト・ベースの制限に一致するアクティビティーを認識します。 ルール・ベースの意思決定で許可または拒否がレンダリングされますか? それは期待と一致しますか? アクティビティーについて学習し、CBR ルールを使用してそれらを正しく処理するには、少なくとも 1 カ月のレポート・モードでテスト・フェーズを行うことをお勧めします。 これにより、必要なネットワーク・ゾーンとコンテキスト・ルールのセットに対する反復的なアプローチが可能になります。

このチュートリアルでは、以下のネットワーク・ゾーンを定義します。

• Kubernetes Service クラスターのゾーン
• Object Storage のゾーン
• homezone として機能するホーム・ネットワーク (企業または要塞) のアドレスを持つ IP 範囲の場合

その後、以下のようにコンテキスト・ルールを定義します。

• ゾーンから Key Protect インスタンス にアクセスする場合:
  • Kubernetes Service クラスター
  • Object Storage
• ゾーンから Object Storage インスタンスとそのバケット へのアクセス:
  • Kubernetes Service クラスター
  • ホーム・ゾーン
• Container Registry へのアクセス用、およびゾーンからのコンテナー・イメージ を含む名前空間へのアクセス用:
  • Kubernetes Service クラスター
• ゾーンから Kubernetes Service クラスターとその管理 API にアクセスする場合:
  • ホーム・ゾーン

上記のすべてのゾーンおよびルールは、単一の Terraform コマンドを使用して、レポート専用モードまたは強制モードのいずれかでデプロイできます。 これらの規則は実動で使用するためのものではなく、レポート専用モードで使用量とトラフィックを調査するためのサンプルとして使用されることに注意してください。

資料には、 サービス参照としてサポートされるリソースのリスト があります。 CLI コマンド service-ref-targets または関連 API 関数 「使用可能なサービス参照ターゲットのリスト(List available service reference targets)」 を使用してリストを取得することもできます。

Terraform を使用してコンテキスト・ベースの制限を構成する

プロジェクトのネットワーク・ゾーンとコンテキスト・ルールを手動で作成する代わりに、デプロイメントを自動化することをお勧めします。 コンテキスト・ベースの制限は、Infrastructure as Code (IaC)、つまり Terraform コード を使用してデプロイできます。 最初に、テスト用にレポート専用モードでルールを使用してゾーンとルールをデプロイできます。 その後、徹底的なテストの後、デプロイされた構成を更新して強制モードに切り替えます。

resource "ibm_cbr_zone" "cbr_zone_k8s" {
  account_id = data.ibm_iam_account_settings.team_iam_account_settings.account_id
  addresses {
    type = "serviceRef"
    ref {
      account_id       = data.ibm_iam_account_settings.team_iam_account_settings.account_id
      service_instance = data.ibm_container_vpc_cluster.cluster.id
      service_name     = "containers-kubernetes"
    }
  }
  description = "Zone with the Kubernetes cluster"
  name        = "cbr_zone_k8s"
}

resource "ibm_cbr_rule" "cbr_rule_cos_k8s" {
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_k8s.id
    }
  }
  contexts {
    attributes {
      name  = "networkZoneId"
      value = ibm_cbr_zone.cbr_zone_homezone.id
    }
  }

  description      = "restrict COS access, limit to cluster"
  enforcement_mode = var.cbr_enforcement_mode
  resources {
    attributes {
      name  = "accountId"
      value = data.ibm_iam_account_settings.team_iam_account_settings.account_id
    }
    attributes {
      name     = "serviceInstance"
      operator = "stringEquals"
      value    = var.cos.guid
    }
    attributes {
      name     = "serviceName"
      operator = "stringEquals"
      value    = "cloud-object-storage"
    }
  }
}

コンテキスト・ルールのテスト

コンテキスト・ベースの制限のセットがデプロイされている場合は、もう一度それらを検証してテストする必要があります。 CBR オブジェクトを検証するには、 コンテキスト・ベースの制約事項の概要 に進みます。 次に、新しい ゾーン および ルール を検査します。

テストは、 Container Registry、 Object Storage 、および Key Protect で実行し、前に実行したログをモニターして検証する必要があります。 ゾーンとルールには Container Registryへのアクセス制限が含まれているため、セクション 「ルールとその適用モードのテスト」 で実行したテストを繰り返すことができます。

Object Storageにアクセスするための新しいルールをテストするには、以下の手順を実行します。

1. ブラウザー・タブで、 Object Storage インスタンスのリスト に移動します。 チュートリアルのサービス名 (例: secure-file-storage-cos) をクリックします。
2. 2つ目のブラウザタブで、監査ログを含む既に使用されているIBM Cloud Logsダッシュボードにアクセスする。
3. Object Storage の概要が表示されているタブに戻り、 「バケット」 のリストでストレージ・バケットをクリックします。
4. 「アップロード」 を使用して、ファイルをバケットにインポートします。 設定を 「標準転送」 のままにし、 「ファイル (オブジェクト) のアップロード」 領域を使用してファイルを選択します。 「アップロード」 をクリックして終了します。
5. 監査ログのあるブラウザ・タブに戻ると、Context restriction matched while in report mode というタイトルのCBR関連ログ・レコードがあるはずです。 これは、ルールが report モードでデプロイされているためです。 一部のレコードを展開して、報告された デシジョン および isEnforced データを確認します。 ホーム・ゾーンに構成されている IP 範囲に応じて、 決定 は 「許可」 または 「拒否」 になります。 レポート・モードのため、 isEnforced の値は false にする必要があります。

さらにテストするために、ホーム・ゾーンの IP 範囲を変更することをお勧めします。 これは、 Schematics 設定の変数 homezone_iprange です。

リソースを削除する

リソースを削除するには、ブラウザーを使用して IBM Cloud Schematics ワークスペースの概要 にナビゲートします。 ワークスペースを選択し、次に 「アクション」 メニューでまず 「リソースの破棄」 を選択します。その後、 「ワークスペースの削除」 を使用します。

関連コンテンツ

• ブログ投稿 コンテキスト・ベースの制限によるゼロ・トラストへの移行(Zero Trust with Context-Based Restrictions)
• ブログ投稿 Introducing Context-Based Restrictions
• ゼロ・トラストとは何ですか?
• ユーザー、チーム、アプリケーションを編成するためのベスト・プラクティス