Storage Account をファイアウォールとサービスエンドポイントで保護する

仮想ネットワーク サービスエンドポイントと Storage ファイアウォールを組み合わせ、Storage Account へのアクセスを特定のサブネットからのみに制限します。拒否と許可の挙動を Cloud Shell と VM の両方から実際に確認します。

中級55Azure 実環境

ラボ概要

Storage Account は作成した直後の状態では、認証情報(アクセスキーや SAS)さえ正しければ、インターネット上のどこからでもデータにアクセスできます。つまり既定では「認証」という 1 枚のレイヤーだけで守られている状態です。キーや SAS が漏えいした場合に備えて、そもそも到達できるネットワーク経路を絞っておくことが、実務でもセキュリティ試験でも重視される多層防御の考え方です。

このラボでは、仮想ネットワークのサブネットに Microsoft.Storage サービスエンドポイントを有効化し、Storage Account のファイアウォールで「既定は拒否、この VNet のサブネットからだけ許可」という構成を作ります。設定して終わりではなく、同じ SAS URL に対して VNet の外(Cloud Shell)からは 403 で拒否され、VNet 内の VM からは 200 で成功する、という挙動の違いを自分の手で確かめます。

ネットワーク規則は AZ-500 の「ストレージのセキュリティ構成」、AZ-104 の「ストレージ アカウントの構成」の両方で出題される定番トピックです。設定画面の暗記ではなく、実際の HTTP ステータスコードの変化として理解しておくと、試験問題の選択肢を確信を持って切れるようになります。

学習目標

  • Storage Account のファイアウォール(ネットワーク規則)と既定アクション(Allow/Deny)の意味を説明できる
  • サブネットで仮想ネットワーク サービスエンドポイント(Microsoft.Storage)を有効化できる
  • 「既定拒否 + 特定サブネットのみ許可」の構成を az CLI で実装できる
  • 有効な SAS を持っていてもネットワーク層で拒否されることを実際に確認できる
  • 認証(キー・SAS)とネットワーク制御が独立した防御レイヤーであることを理解する

前提

  • Azure ポータルにサンドボックス アカウントでサインイン済みであること
  • リソースはすべて japaneast(東日本) リージョンに作成します
  • 作業は割り当て済みのリソースグループ 1 つの中だけで行います(新しいリソースグループは作成しません)
  • 手順は主に Cloud Shell(Bash / az CLI)を使用します。ポータルの操作は最小限です

ラボの構成

  1. 1リソースグループの確認と Cloud Shell の準備
  2. 2仮想ネットワークとサブネットの作成
  3. 3サブネットで Microsoft.Storage サービスエンドポイントを有効化
  4. 4Storage Account の作成とテストデータの配置
  5. 5検証用 VM の作成
  6. 6ファイアウォールの構成(既定を拒否に変更)
  7. 7VNet からのアクセスを許可するルールの追加
  8. 8動作確認
  9. 9完了チェックリスト
  10. 10後片付け

詳細な手順は、ラボ開始後に画面内のガイドとして表示されます。

構成図

参考リソース