ネットワーク タグとサービス アカウントを使用する VPC ファイアウォール ルールを移行する

Virtual Private Cloud（VPC）ネットワーク全体で管理を一元化し、セキュリティ ポリシーを一貫して適用するには、ネットワーク タグとソース サービス アカウントを使用する VPC ファイアウォール ルールをグローバル ネットワーク ファイアウォール ポリシーに移行します。これにより、緩すぎる許可ルールを特定して対処することで、攻撃対象領域を減らし、ファイアウォールの構成を最適化し、セキュリティ境界を強化できます。

このドキュメントは、ネットワーク セキュリティ ポリシーを構成して管理するネットワーク管理者、セキュリティ エンジニア、セキュリティ アーキテクトを対象としています。

ネットワーク タグまたはサービス アカウントを使用しないルールを移行するには、 ネットワーク タグとサービス アカウントを使用しない VPC ファイアウォール ルールを移行するをご覧ください。

この移行を完了するには、次のタスクを行います。

  1. 環境を評価します。
  2. 既存のネットワーク タグとサービス アカウントを一覧表示します。
  3. それぞれのネットワーク タグとソース サービス アカウントにセキュアタグを作成します。
  4. 作成したセキュアタグにネットワーク タグとサービス アカウントをマッピングします。
  5. セキュアタグを仮想マシン（VM）インスタンスにバインドします。
  6. VPC ファイアウォール ルールをグローバル ネットワーク ファイアウォール ポリシーに移行します。
  7. 新しいネットワーク ファイアウォール ポリシーを確認します。
  8. 移行後のタスクを完了します。

始める前に

  1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Cloud de Confiance project.

  3. Enable the Compute Engine API.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the API

  4. Google Cloud CLI をインストールします。

  5. フェデレーション ID（連携 ID）を使用するように gcloud CLI を構成します。

    詳細については、連携 ID を使用して gcloud CLI にログインするをご覧ください。

  6. gcloud CLI を初期化するには、次のコマンドを実行します: 

    gcloud init
  7. Compute セキュリティ管理者ロール（roles/compute.securityAdmin）があることを確認します。

環境を評価する

VPC ファイアウォール ルールをグローバル ネットワーク ファイアウォール ポリシーに移行する前に、既存の環境と Identity and Access Management（IAM）のロールと権限を評価します。

  1. VPC ネットワーク内の VPC ファイアウォール ルールの数を確認します。
  2. 各 VPC ファイアウォール ルールに関連付けられている優先度をメモします。
  3. グローバル ネットワーク ファイアウォール ポリシーの作成、関連付け、変更、表示に必要な IAM ロールと権限があることを確認します。

  4. セキュアタグの定義の作成、更新、削除に必要な IAM ロールと権限があることを確認します 。

    次の表に、セキュアタグの作成と管理に必要なロールの概要を示します。

    ロール名 実行されるタスク
    タグ管理者ロール（roles/resourcemanager.tagAdmin） タグの定義を作成、更新、削除します。詳細については、タグを管理するをご覧ください。
    タグ閲覧者ロール（roles/resourcemanager.tagViewer） リソースに適用されているタグの定義とタグを表示します。
    タグユーザー ロール（roles/resourcemanager.tagUser） リソースに適用されているタグを追加または削除します。

既存のネットワーク タグとサービス アカウントを一覧表示する

VPC ファイアウォール ルールでネットワーク タグまたはサービス アカウントが使用されているかどうかを判断し、JSON ファイルを作成して、既存のネットワーク タグとサービス アカウントの詳細を保存します。

ネットワーク内のネットワーク タグとサービス アカウントをマッピング用の JSON ファイルにエクスポートするには、gcloud beta compute firewall-rules migrate コマンドを --export-tag-mappingフラグとともに使用します。

gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --export-tag-mapping \
    --tag-mapping-file=TAG_MAPPING_FILE

次のように置き換えます。

  • NETWORK_NAME: 移行する VPC ファイアウォール ルールを含む VPC ネットワークの名前。
  • TAG_MAPPING_FILE: マッピング用の JSON ファイルの名前。

VPC ファイアウォール ルールにサービス アカウントのみが含まれている場合、生成された JSON ファイルにはサービス アカウントのみが含まれます。同様に、VPC ファイアウォール ルールにネットワーク タグのみが含まれている場合、生成された JSON ファイルにはネットワーク タグのみが含まれます。サービス アカウントには接頭辞 sa が付加され、ネットワーク タグには接頭辞が付加されません。

たとえば、次の生成された JSON ファイルには、ネットワーク タグ sql-server とサービス アカウント example@example.com が含まれています。

{"sql-server": null, "sa:example@example.com": null}

セキュアタグを作成する

マッピング ファイルに記述したネットワーク タグとソース サービス アカウントに基づいて、ネットワークで対応するセキュアタグを作成する必要があります。

新しいセキュアタグは、ネットワーク タグとサービス アカウントの代わりとして機能し、移行後も元のネットワーク構成を保持します。

タグ管理者ロールを持つプリンシパルとして、ネットワーク タグとサービス アカウントごとに、対応するセキュアタグの Key-Value ペアを作成します。

ネットワーク タグとサービス アカウントごとにセキュアタグのキーと値を作成するには、 gcloud resource-manager tags keys create コマンドと gcloud resource-manager tags values create コマンドを使用します。

gcloud resource-manager tags keys create TAG_KEY \
    --parent=organizations/ORGANIZATION_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=PROJECT_ID/NETWORK_NAME

gcloud resource-manager tags values create TAG_VALUE \
    --parent=ORGANIZATION_ID/TAG_KEY

次のように置き換えます。

  • TAG_KEY: セキュアタグキーの名前。
  • ORGANIZATION_ID: 組織の ID。
  • PROJECT_ID: プロジェクトの ID。
  • NETWORK_NAME: VPC ネットワークの名前。
  • TAG_VALUE: セキュアタグキーに割り当てる値。

たとえば、ネットワーク タグ を含む VPC ファイアウォール ルールがある場合は、対応するセキュアタグの sql-server:productionの Key-Value ペアを作成します。sql-server

gcloud resource-manager tags keys create sql-server \
    --parent=organizations/123456 \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=test-project/test-network

gcloud resource-manager tags values create production \
    --parent=123456/sql-server

ネットワーク タグとサービス アカウントをセキュアタグにマッピングする

VPC ファイアウォール ルールで使用される各ネットワーク タグとサービス アカウントに IAM 管理のセキュアタグを作成したら、マッピング用の JSON ファイルで、対応するネットワーク タグとサービス アカウントにセキュアタグをマッピングする必要があります。

JSON ファイルを編集して、ネットワーク タグとサービス アカウントを対応するセキュアタグにマッピングします。

{"sql-server": "tagValues/yyyyy", "sa:example@example.com": "tagValues/zzzzz"}

たとえば、次の JSON ファイルは、ネットワーク タグ sql-server をキー sql-server のセキュアタグ値に、サービス アカウント example@example.com をキー example@example.com のセキュアタグ値にマッピングしています。

{"sql-server": "tagValues/production", "sa:example@example.com": "tagValues/example"}

セキュアタグを VM にバインドする

タグマッピングの JSON ファイルに基づいて、既存のネットワーク タグが接続されている VM に新しく作成されたセキュアタグをバインドします。

  1. タグ管理者ロールを持つプリンシパルが次の操作を行います。

    1. リソースにセキュアタグを接続するために必要な権限 を確認します。 Cloud de Confiance by S3NS
    2. セキュアタグを使用して VM にセキュアタグをバインドするプリンシパル にタグユーザーのロールを割り当てます。

  2. タグユーザー ロールを持つプリンシパルとして、セキュアタグを VM インスタンス にバインドします。gcloud beta compute firewall-rules migrate コマンド と --bind-tags-to-instances フラグを使用します。

    gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --bind-tags-to-instances \
    --tag-mapping-file=TAG_MAPPING_FILE

    次のように置き換えます。

    • NETWORK_NAME: VPC ネットワークの名前。
    • TAG_MAPPING_FILE: マッピング用の JSON ファイルの名前。

VPC ファイアウォール ルールをグローバル ネットワーク ファイアウォール ポリシーに移行する

VPC ファイアウォール ルールをグローバル ネットワーク ファイアウォール ポリシーに移行するには、gcloud beta compute firewall-rules migrate コマンドを使用します。

gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --target-firewall-policy=POLICY_NAME \
    --tag-mapping-file=TAG_MAPPING_FILE

次のように置き換えます。

  • NETWORK_NAME: 移行する VPC ファイアウォール ルールを含む VPC ネットワークの名前。
  • POLICY_NAME: 移行中に作成するグローバル ネットワーク ファイアウォール ポリシーの名前。
  • TAG_MAPPING_FILE: マッピング用の JSON ファイルの名前。

移行からファイアウォール ルールを除外する

特定のファイアウォール ルールを移行から除外するには、gcloud beta compute firewall-rules migrate コマンドを --exclusion-patterns-file フラグとともに使用します。

gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --target-firewall-policy=POLICY_NAME \
    --exclusion-patterns-file=EXCLUSION_PATTERNS_FILE

次のように置き換えます。

  • NETWORK_NAME: 移行する VPC ファイアウォール ルールを含む VPC ネットワークの名前。
  • POLICY_NAME: 移行中に作成するグローバル ネットワーク ファイアウォール ポリシーの名前。

  • EXCLUSION_PATTERNS_FILE: 移行から除外する VPC ファイアウォールの命名パターンを定義する正規表現を含むファイルの名前。ファイルのフルパスを指定してください。指定したパターンに一致するファイアウォール ルールはスキップされます。

    除外パターンを定義する際は、次の点を考慮してください。

    • 各正規表現は 1 行に 1 つずつ記述し、単一のファイアウォール命名パターンを表す必要があります。
    • 正規表現には、先頭または末尾に空白文字が含まれていません。

除外されたファイアウォール ルールを表示する

除外されたファイアウォール ルールの命名パターンに基づいて、移行ツールは Google Kubernetes Engine（GKE）ファイアウォール ルールなど、一部のファイアウォール ルールを移行しません。除外されたファイアウォール ルールの命名パターンのリストをエクスポートするには、--export-exclusion-patterns フラグと --exclusion-patterns-file フラグを指定して gcloud beta compute firewall-rules migrate コマンドを使用します。

gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --target-firewall-policy=POLICY_NAME \
    --exclusion-patterns-file=EXCLUSION_PATTERNS_FILE \
    --export-exclusion-patterns

次のように置き換えます。

  • NETWORK_NAME: 移行する VPC ファイアウォール ルールを含む VPC ネットワークの名前。
  • POLICY_NAME: 移行中に作成するグローバル ネットワーク ファイアウォール ポリシーの名前。

  • EXCLUSION_PATTERNS_FILE: 次の除外されたファイアウォール ルールの命名パターンがエクスポートされるファイルのパス。

    gke-(.+)-ipv6-all
gke-(.+)-(.+)-((master)|(vms)|(all)|(inkubelet)|(exkubelet)|(mcsd))
k8s-fw-(l7-)?(.+)
k8s-(.+)-((node)|(http)|(node-http))-hc
(.+)-hc
k8s2-(.+)-(.+)-(.+)-(.+)(-fw)?
k8s2-(.+)-l4-shared-hc-fw
gke((gw)|(mcg))1-l7-(.+)-(.+)

特定のパターンに一致する除外されたファイアウォール ルールを移行するには、 エクスポートされたリストからパターンを削除し、--exclusion-patterns-file フラグを指定して gcloud beta compute firewall-rules migrate コマンドを実行します。

評価順序を維持しながら移行を強制する

移行中に、除外されたファイアウォール ルールの評価順序が、ユーザー指定のファイアウォール ルールの評価順序の間にある場合、移行は失敗します。これは、除外されたファイアウォール ルールが移行されず、移行ツールが新しいネットワーク ファイアウォール ポリシーでユーザー定義ルールの元の評価順序を保持できないためです。

たとえば、ファイアウォール ルールの優先度が次のようになっている場合、移行は失敗します。

  • 優先度 100 のユーザー指定ルール
  • 優先度 200 の除外ルール
  • 優先度 300 のユーザー指定ルール

移行ツールで、除外されたファイアウォール ルールを無視して、元の評価順序を維持しながらユーザー指定のルールを移行するには、--force フラグを指定して gcloud beta compute firewall-rules migrate コマンドを使用します。

gcloud beta compute firewall-rules migrate \
    --source-network=NETWORK_NAME \
    --target-firewall-policy=POLICY_NAME \
    --force

次のように置き換えます。

  • NETWORK_NAME: 移行する VPC ファイアウォール ルールを含む VPC ネットワークの名前。
  • POLICY_NAME: 移行中に作成するグローバル ネットワーク ファイアウォール ポリシーの名前。

新しいグローバル ネットワーク ファイアウォール ポリシーを確認する

新しく作成したポリシーを VPC ネットワークに関連付ける前に、ポリシーを確認して移行プロセスが正確に完了していることを確認することをおすすめします。

以下を確認してください。

  • ファイアウォール ポリシー ルールの構成が正しく、次のルール コンポーネントが各ルールに正しく移行されている。

    • 相対的な優先度
    • トラフィックの方向
    • 一致したときのアクション
    • ログの設定
    • ターゲット パラメータ
    • 送信元パラメータ（上り（内向き）ルール用）
    • 宛先パラメータ（下り（外向き）ルール用）
    • プロトコルとポートの制約

  • セキュアタグが正しい VM に接続されているかどうかを確認します。これを確認するには、gcloud resource-manager tags bindings list コマンドを使用します。

    gcloud resource-manager tags bindings list \
    --location=ZONE_ID \
    --parent=//compute.googleapis.com/projects/PROJECT_ID/zones/ZONE_ID/instances/INSTANCE_NAME \
    --effective

    次のように置き換えます。

    • ZONE_ID: VM のゾーン。
    • PROJECT_ID: プロジェクトの ID。
    • INSTANCE_NAME: VM の名前。

移行後のタスク

新しいグローバル ネットワーク ファイアウォール ポリシーを有効にして使用するには、移行後のタスクを完了します。詳細については、移行後のタスクをご覧ください。

次のステップ