階層型セキュリティ ポリシーを構成する

このページでは、組織、フォルダ、プロジェクトを保護するために階層型セキュリティ ポリシーを構成する方法について説明します。階層型セキュリティ ポリシーを構成する前に、階層型セキュリティ ポリシーの概要の情報をよく理解しておいてください。

階層型セキュリティ ポリシーの IAM 権限を設定する

次の操作を行うには、ターゲット リソース階層ノードまたはポリシー自体（すでに存在する場合）に対する Identity and Access Management（IAM）ロールの Compute 組織セキュリティ ポリシー管理者のロール（roles/compute.orgSecurityPolicyAdmin）が必要です。

  • 新しい階層型セキュリティ ポリシーを作成する
  • ルールを追加、更新、削除して階層型セキュリティ ポリシーを変更する
  • 階層型セキュリティ ポリシーを削除する

次の操作では、ターゲット リソース階層ノードに対する IAM の Compute 組織リソース管理者ロール（roles/compute.orgSecurityResourceAdmin）に加えて、ターゲット リソース階層ノードまたはポリシー自体に対する Compute 組織セキュリティ ポリシー管理者ロール（roles/compute.orgSecurityPolicyAdmin）または Compute 組織セキュリティ ポリシー ユーザー ロール（roles/compute.orgSecurityPolicyUser）が必要です。

  • 階層型セキュリティ ポリシーをリソース階層ノードに関連付ける

最後に、次の表に、リストされているロールのいずれかを持っている場合に実行できるその他の操作の一覧を示します。

操作 ロール
バックエンド リソースに対して有効なすべての Google Cloud Armor ルールを表示する
organizationSecurityPolicy の対象となる有効なバックエンド リソースを表示する

階層型セキュリティ ポリシーを構成する

以降のセクションでは、階層型セキュリティ ポリシーの作成方法、リソース階層ノードへの関連付け方法、ノード間の移動方法、削除方法、保護されたリソースに適用されるすべての Google Cloud Armor セキュリティ ポリシー ルールの表示方法について説明します。

階層型セキュリティ ポリシーを作成する

階層型セキュリティ ポリシーは、gcloud beta compute org-security-policies create コマンドを使用して作成します。階層型セキュリティ ポリシーは、--organization または --folder フラグと、対応する ORGANIZATION_ID または FOLDER_ID を使用して、組織またはフォルダの下に作成します。次の例を使用して、階層型セキュリティ ポリシーを作成します。POLICY_NAME は、新しいセキュリティ ポリシーに付ける名前に置き換えます。

  • 組織レベルの階層型セキュリティ ポリシーを作成する

    gcloud beta compute org-security-policies create \
    --organization=ORGANIZATION_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

  • フォルダレベルの階層型セキュリティ ポリシーを作成する

    gcloud beta compute org-security-policies create \ 
    --folder=FOLDER_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

既存のセキュリティ ポリシーをリソース階層ノードに関連付ける

既存のセキュリティ ポリシーがある場合は、gcloud beta compute org-security-policies associations create コマンドを使用して、リソース階層ノードに関連付けることができます。次のように置き換えます。

  • POLICY_ID: セキュリティ ポリシーの ID
  • POLICY_NAME: セキュリティ ポリシーの名前
  • ORGANIZATION_ID: 組織の ID
  • FOLDER_ID: フォルダの ID

  • PROJECT_ID: プロジェクトの ID

  • 階層型セキュリティ ポリシーを組織に関連付けます。

    gcloud beta compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --organization=ORGANIZATION_ID \
    --name=ASSOCIATION_NAME

  • 階層型セキュリティ ポリシーをフォルダに関連付けます。

    gcloud beta compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --folder=FOLDER_ID \
    --name=ASSOCIATION_NAME

  • 階層型セキュリティ ポリシーをプロジェクトに関連付けます。

    gcloud beta compute org-security-policies associations create \
  --security-policy=POLICY_ID \
  --project-number=PROJECT_ID \
  --name=ASSOCIATION_NAME

階層型セキュリティ ポリシーからプロジェクトを除外する

また、フォルダレベルの階層型セキュリティ ポリシーからプロジェクトを除外したり、組織レベルの階層型セキュリティ ポリシーからプロジェクトとフォルダの両方を除外したりすることもできます。

  • 階層型セキュリティ ポリシーからプロジェクトを除外するには、--excluded-projects フラグを指定して beta compute org-security-policies associations create コマンドを使用します。

    次のコマンド例では、セキュリティ ポリシー example-policy を組織 10000001 に関連付け、ID 2000000002 のプロジェクトを除外します。

    gcloud beta compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-projects="projects/2000000002" \
    --organization=10000001

  • 組織レベルの階層型セキュリティ ポリシーからフォルダを除外するには、--excluded-folders フラグを指定して beta compute org-security-policies associations create コマンドを使用します。

    次のコマンド例では、セキュリティ ポリシー example-policy を組織 10000001 に関連付け、ID 3000000003 でフォルダを除外します。

    gcloud beta compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-folders="folders/3000000003" \
    --organization=10000001

階層型セキュリティ ポリシーを移動する

階層型セキュリティ ポリシーの親を変更するには、gcloud beta compute org-security-policies move を使用して、階層型セキュリティ ポリシーを別の親リソース階層ノードに移動します。ソースを最初のフラグとして指定し、宛先を 2 番目のフラグとして指定します。階層型セキュリティ ポリシーを移動すると、関連付けられているリソースではなく、所有権が変更されます。階層型セキュリティ ポリシーを所有できるのは組織とフォルダのみであるため、プロジェクトの下に移動することはできません。

次の例では、階層型セキュリティ ポリシーを組織 ORGANIZATION_ID からフォルダ FOLDER_ID に移動します。

gcloud beta compute org-security-policies move policy-1 \
    --organization ORGANIZATION_ID \
    --folder FOLDER_ID

階層型セキュリティ ポリシーを削除する

階層型セキュリティ ポリシーを削除する前に、ポリシーとリソース階層ノードのすべての関連付けを削除する必要があります。次の例では、beta compute org-security-policies associations delete コマンドを使用して、名前が POLICY_NAME の階層型セキュリティ ポリシーと組織 ORGANIZATION_ID の間の ASSOCIATION_NAME という名前の関連付けを削除します。

gcloud beta compute org-security-policies associations delete ASSOCIATION_NAME \
    --security-policy=POLICY_NAME \
    --organization=ORGANIZATION_ID

セキュリティ ポリシーに関連付けられているのがこれだけではない場合は、関連付けごとに前の手順を繰り返します。階層型セキュリティ ポリシーに関連付けがない場合は、次の例のように compute org-security-policies delete コマンドを使用して削除できます。

gcloud beta compute org-security-policies delete POLICY_NAME \
    --organization=ORGANIZATION_ID

保護されたリソースに対して有効なすべての Google Cloud Armor ルールを表示する

保護されたリソースに適用されるすべての Google Cloud Armor セキュリティ ポリシー ルールを表示するには、gcloud beta compute backend-services get-effective-security-policies コマンドを使用します。次の例では、RESOURCE_NAME を確認する保護されたリソースの名前に置き換えます。

gcloud beta compute backend-services get-effective-security-policies PROTECTED_RESOURCE

ユースケース

以降のセクションでは、階層型セキュリティ ポリシーのユースケースについて説明します。

一連の IP アドレスから組織内のすべてのアプリケーション ロードバランサへのトラフィックを拒否する

階層型セキュリティ ポリシーを使用すると、組織のネットワーク全体へのアクセスが許可されていない IP アドレスのリストを管理したり、特定の地域や国からのトラフィックを拒否したりできます。これにより、会社固有のセキュリティ上の懸念に対処したり、コンプライアンスを維持したりできます。次の手順は、IP アドレス範囲 192.0.2.0/24 からのトラフィックを拒否する組織レベルの階層型セキュリティ ポリシーを作成する方法を示しています。

  1. ID 1000000001 の組織に接続された org-level-deny-ip-policy という名前の階層型セキュリティ ポリシーを作成します。

     gcloud beta compute org-security-policies create \
     --organization=1000000001 \
     --type=CLOUD_ARMOR \
     --description= "this is an org policy to deny a set of IP addresses for all resources" \
     --short-name=org-level-deny-ip-policy

  2. 優先度 1000 で、IP アドレス範囲 192.0.2.0/24 の一致条件と deny アクションを含むルールを追加します。

     gcloud beta compute org-security-policies rules create 1000 \
     --action=deny \
     --security-policy=org-level-deny-ip-policy \
     --organization=1000000001 \
     --description "Deny traffic from 192.0.2.0/24" \
     --src-ip-ranges "192.0.2.0/24"

  3. 最後に、セキュリティ ポリシーを組織に関連付け、192.0.2.0/24 IP アドレスからのリクエストを組織内のすべてのサービスに対して拒否します。

     gcloud beta compute org-security-policies associations create \
     --security-policy=org-level-deny-ip-policy \
     --organization=ORGANIZATION_ID

組織内の特定のプロジェクトへのアクセス権を特定の送信元 IP アドレスに付与する

組織内の特定のプロジェクトへのアクセス権を 1 つまたは複数の IP アドレスに付与できます。これは、信頼できるアップストリーム プロキシがあり、一部のプロジェクトのルール評価から除外する場合に便利です。次の Cloud CDN ベースの例では、フォルダレベルの階層型セキュリティ ポリシーを使用して、IP アドレス範囲 192.0.2.0/24 に、組織 10000001 の project-1、project-2、project-3 という名前のプロジェクトへのアクセス権を付与します。

  1. 次のコマンドを使用して、project-1、project-2、project-3 を ID が 20000002 のフォルダに移動します。

    gcloud projects move project-1 --folder=20000002
gcloud projects move project-2 --folder=20000002
gcloud projects move project-3 --folder=20000002

  2. 次のコマンドを使用して、org-level-proxy-filtering という名前のセキュリティ ポリシーを作成します。

     gcloud beta compute org-security-policies create \
     --folder=20000002 \
     --type=CLOUD_ARMOR \
     --short-name=org-level-proxy-filtering

  3. IP アドレス範囲 192.0.2.0/24 の一致条件と goto_next ルール アクションを使用して、優先度 1000 のルールを追加します。リクエストがこの条件と一致すると、Google Cloud Armor はこのセキュリティ ポリシー内のルールの評価を停止します。

     gcloud beta compute org-security-policies rules create 1000 \
     --action=goto_next \
     --security-policy=org-level-proxy-filtering \
     --organization=10000001 \
     --src-ip-ranges="192.0.2.0/24"

  4. 省略可: 192.0.2.0/24 以外のリクエストに対してこれらのプロジェクトにセキュリティ ポリシー ルールを適用する場合は、1000 よりも優先度の低いルールを追加します。この手順は後で行うこともできます。

  5. 次のコマンドを使用して、手順 1 でプロジェクトを移動した ID 20000002 のフォルダにポリシーを関連付けます。

     gcloud beta compute org-security-policies associations create \
     --security-policy=org-level-proxy-filtering \
     --folder=20000002

次のステップ