VPC-SC のドライランモードで、既存リソースでも安全に境界内に移動できます

VPC-SC のドライランモードで、既存リソースでも安全に境界内に移動できます

2026.01.18

はじめに

こんにちは、すらぼです。
今回は、VPC-SC のドライランモードについて使用方法や実際の動作を確認してみます。

VPC-SC はセキュリティレベルを引き上げてくれる便利な機能ですが、通信が遮断されてしまうため、既存のリソースに適用する際は注意が必要です。
このようなケースでは「ドライランモード」を利用することで安全にリソースを VPC-SC 境界内に移動できます。

VPC-SC の基本的な設定方法に関しては、以下のブログをご参照ください。

https://dev.classmethod.jp/articles/access-context-manager-vpc-service-controls-ip-api/

ドライランモードを使った VPC-SC の設定方法

以下のような手順で確認していきます。

  1. ドライランモードで境界を設定する
  2. エラーログの出力を確認
  3. エラーを解消してみる
  4. 本番環境に適用する
  5. 追加の設定をドライランモードで試してみる
  6. 適用中の設定を直接変更したとき

ドライランモードで境界を設定する

VPC-SC の画面から「新しい境界」をクリックします。

CleanShot 2026-01-18 at 21.37.39@2x.png

境界のタイプ「標準」、適用モードは「テストを実行」を選択し、「続行」をクリックします。
この設定により、ドライランモードでの適用となります。
※この画面ではわかりやすさのためにタイトルを dry-run-test としていますが、このタイトルのまま本番適用が可能な名称の利用を推奨します。

CleanShot 2026-01-18 at 21.38.57@2x.png

境界内に配置するプロジェクトとVPCを選択します。

CleanShot 2026-01-18 at 21.43.48@2x.png

「制限付きサービス」では、保護するAPIを選択します。ここでは、Cloud Storage API を選択しています。

CleanShot 2026-01-18 at 21.45.45@2x.png

VPC 内のアクセス可能なサービスは、「すべてのサービス」から変更せず進みます。

CleanShot 2026-01-18 at 21.47.16@2x.png

「アクセスレベル」「上り(内向き)ポリシー」「下り(外向き)ポリシー」は、動作確認のため現時点では何も設定せず、このまま作成します。

エラーログの出力を確認

この状態で、違反したリクエストでエラーが出ることを確認します。

今回は Storage API を保護しているので、保護したプロジェクトを選択した状態で以下のコマンドを実行してみます。

gcloud storage ls

リクエストは成功するはずですが、対象のプロジェクトのログには以下のようなログが出力されていることが確認できます。

{
    protoPayload: {
        @type: "type.googleapis.com/google.cloud.audit.AuditLog",
        methodName: "google.storage.buckets.list",
        status: {
            message: "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: ............",
        }
    }
    .....
}

上記のようなエラーログが出力されている場合、この VPC-SC を適用すると利用できなくなる通信が存在することがわかります。

エラーを解消してみる

VPC-SC 外からのアクセスを許可して、上記のエラーが出ないようにしてみます。

Access Context Manager の画面から、「アクセスレベルを作成」します。

CleanShot 2026-01-18 at 22.04.27@2x.png

今回は、「IPサブネットワーク」から自身のパブリックIPを入力して自分のローカル端末からのリクエストを許可するように設定してみます。

CleanShot 2026-01-18 at 22.05.47@2x.png

次に、先ほどドライラン状態で作成した VPC-SC を編集します。

CleanShot 2026-01-18 at 22.13.07.png

「上り(内向き)ポリシー」で、以下のように設定します。

  • FROM
    • ソース: アクセスレベル
    • アクセスレベル: 先ほど Access Context Manager で作成したアクセスレベルを選択
  • TO
    • リソース: すべてのプロジェクト
    • オペレーションまたは IAM ロール: すべてのオペレーション

CleanShot 2026-01-18 at 22.11.09.png

この状態で保存し、ローカルマシンから再度コマンドを実行すると、エラーが出力されなくなります。

本番環境に適用する

動作確認ができ、エラーが出ないことを確認できたら、この設定をそのまま自動適用モード(enforce mode)に移行することができます。

ドライランモードで設定した VPC-SC の詳細画面から、「構成を適用」ボタンをクリックします。

CleanShot 2026-01-18 at 22.18.09@2x.png

CleanShot 2026-01-18 at 22.18.09@2x.png

これを承認すると、以下のように「自動適用モード」にそのままドライランモードで使用していた設定が複製されます。

CleanShot 2026-01-18 at 22.22.19@2x.png

なお、この操作を行ってもドライランモードで使用していた設定は消えず、 有効化された VPC-SC に対応するドライラン設定として利用し続けることができます。 (詳細は後述)

適用後の動作確認

この状態で以下のコマンドを再度、Cloud Shell(許可なし) と自身のローカル端末(許可済み)でそれぞれ実行してみます。

gcloud storage ls

Cloud Shell で実行した場合は、以下のようなエラーが表示され、コマンド実行に失敗します。

$ gcloud storage ls
ERROR: (gcloud.storage.ls) HTTPError 403: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxxxxxx.

ローカルで実行した場合は、以下のように正常にリクエストが返ってきます。

$ gcloud storage ls
gs://xxxxxxxxx/
gs://yyyyyyyzzzzzzz/

追加の設定をドライランモードで試してみる

ここまでの手順を踏むことで、VPC-SC が稼働状態とドライランモードの2つのリソースが存在する状態になります。
これにより、継続的に「ドライラン→本番適用」のフローが行える状態になります。

試しに、ドライランモードで Compute Engine のAPIを追加で保護してみます。

CleanShot 2026-01-18 at 22.56.50@2x.png

この状態で以下のコマンドを Cloud Shell から実行すると、コマンドは成功しますがエラーログが出力されます。(まだドライランのため、エラーにはなりません)

$ gcloud compute disks list
Listed 0 items.
{
  "protoPayload": {
    "status": {
      "message": "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxxxxx",
    },
    "serviceName": "compute.googleapis.com",
    "methodName": "compute.v1.DisksService.AggregatedList",
    "metadata": {
      "dryRun": true,
      "ingressViolations": [
        {
          "source": "projects/0000000000",
          "servicePerimeter": "accessPolicies/9999999999/servicePerimeters/dryruntest",
          "targetResource": "projects/1111111111",
          "targetResourcePermissions": [
            "vpcsc.permissions.unavailable"
          ]
        }
      ]
    }
  }
}

そして、この状態から再度「構成を適用」をクリックします。

CleanShot 2026-01-18 at 23.02.19@2x.png

この状態で、Cloud Shell 上からコマンドを実行すると以下のようになります。

$ gcloud compute instances list
WARNING: Some requests did not succeed.
 - Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Listed 0 items.

WARNING にしかなっていませんが、compute コマンドの仕様でありきちんとブロックされています。

ドライランモードで追加設定の動作を確認し、実際に適用することができました。

適用中の設定を直接変更したとき

ここまでの説明から、ドライランモードを常に経由できるのが理想ですが、本番運用側を編集するようなケースもあるかもしれません。
その時は、 ドライラン側に変更がない場合に限り、適用中の VPC-SC 設定の変更がドライランの VPC-SC へ自動で反映 されます。

試しに、 先ほど本番に反映した Compute Engine API を「適用済みの VPC-SC から」削除してみます。

CleanShot 2026-01-18 at 23.22.40@2x.png

すると、ドライランモードにも変更は継承され、 Cloud Storage API のみに減っています。

CleanShot 2026-01-18 at 23.24.37@2x.png

ただし、この継承は先述の通り ドライラン側に変更がない場合に限ります。 ドライラン側に差分がある場合は、この自動継承は行われず、適用中の VPC-SC とドライランの VPC-SC とで差分が生まれることになるため、十分に注意してください。

終わりに

VPC-SC のドライランモードを使った設定の適用方法について確認してみました。ドライラン経由で VPC-SC を作ることで、ブラウザコンソール上からでも「開発環境・本番環境」のような構成を取れるところが非常に便利だと感じました。
複雑な要件には IaC 化が必須の機能ですが、シンプルな条件であればブラウザ上からでも一定の運用ができそうです。

VPC-SC の運用の助けになれば幸いです。以上、すらぼでした!

参考リンク

この記事をシェアする

FacebookHatena blogX

関連記事