Azure Storage Account の認証方式とネットワーク制御を分かりやすく整理する（AFD利用をも重ねて）

Posted at 2026-08-28

Azure Storage Account の認証方式とネットワーク制御を分かりやすく整理する

Azure Storage Account の設計や運用で特に混同されやすいのが、Anonymous Access、Shared Key、SAS、Microsoft Entra ID などの「認証方式」と、Private Endpoint や Firewall などの「ネットワーク制御」の違いです。

「Storage Account にアクセスできない」「どの設定を有効にすべきか分からない」といったトラブルの多くは、この2つを同じものとして捉えてしまうことが原因です。

本記事では、それぞれの役割と組み合わせによる動作を整理し、Azure Storage のアクセス制御を分かりやすく解説します。

1. 認証方式（誰がアクセスできるか）

Blob Storage へのアクセス権限を決める仕組みが認証・認可です。

Azure Storage 認証方式
│
├─ ① Anonymous Access（匿名アクセス）
├─ ② Shared Key Access（アカウントキー）
├─ ③ SAS Token（共有アクセス署名）
└─ ④ Microsoft Entra ID 認証

① Anonymous Access（匿名アクセス）

認証情報を一切必要とせず、URL を知っていれば誰でもアクセスできる方式です。

利用するには以下の両方が必要です。

Storage Account の「Allow Blob Anonymous Access」を有効化
コンテナーの Public Access Level を Blob または Container に設定

主に公開画像や静的コンテンツ配信などで利用されます。

② Shared Key Access（アカウントキー）

Storage Account 作成時に発行される Key1 / Key2 を利用する方式です。

接続文字列やアクセスキーを利用して認証を行います。

特徴は以下の通りです。

強力な権限を持つ
Storage Account 全体へのアクセスが可能
キー漏洩時の影響が大きい

近年はセキュリティ強化の観点から、可能な限り Entra ID ベースの認証へ移行することが推奨されています。

③ SAS Token（Shared Access Signature）

期限や権限を限定したアクセス許可を与える仕組みです。

SAS は大きく2種類あります。

Service SAS / Account SAS

Storage Account Key を利用して生成します。

Storage Account Key
       ↓
Service SAS / Account SAS

そのため、

Allow Shared Key Access = Disabled

の場合は利用できません。

User Delegation SAS

Microsoft Entra ID を利用して生成します。

Microsoft Entra ID
       ↓
User Delegation SAS

Storage Account Key に依存しないため、

Allow Shared Key Access = Disabled

の環境でも利用できます。

現在は SAS を利用する場合、User Delegation SAS が最も推奨される方式です。

④ Microsoft Entra ID 認証

ユーザー、サービスプリンシパル、マネージド ID に Azure RBAC を適用する方式です。

例：

Storage Blob Data Reader
Storage Blob Data Contributor
Storage Blob Data Owner

などのロールを付与してアクセス権を管理します。

現在 Microsoft が最も推奨している認証方式です。

2. ネットワーク制御（どこからアクセスできるか）

ここが最も重要なポイントです。

Private Endpoint や Firewall は認証方式ではありません。

ネットワーク制御は、

どの場所から接続できるか

を制御する仕組みです。

Public Endpoint

インターネット経由のアクセスを許可します。

必要に応じて、

IP 制限
VNet 制限
Firewall

を組み合わせてアクセス元を制御できます。

Private Endpoint

Storage Account にプライベート IP を割り当てます。

アクセス可能な経路は以下のような閉域ネットワークになります。

同一 VNet
VNet Peering
VPN
ExpressRoute

インターネットを経由せずに Storage Account にアクセスできます。

よくある誤解

よく、

Private Endpoint を利用すると匿名アクセスできなくなる

と誤解されます。

これは正しくありません。

Private Endpoint は認証方式ではなく、接続経路の制御だからです。

例えば以下の構成は成立します。

Private Endpoint + Anonymous Access

この場合、

Private Endpoint に到達可能なネットワークからであれば認証なしでアクセス可能

という動作になります。

つまり、

認証        ──> 誰がアクセスできるか
ネットワーク  ──> どこからアクセスできるか

の2つは独立したレイヤーとして考える必要があります。

3. アクセス可否マトリクス

※「○」はネットワーク到達性があり、適切な SAS または RBAC が設定されている前提です。

ネットワーク構成	認証方式	アクセス	備考
Public Endpoint	Anonymous Access	○	匿名アクセス有効時
Public Endpoint	SAS	○	有効な SAS が必要
Public Endpoint	Entra ID	○	適切な RBAC が必要
Private Endpoint	Anonymous Access	○	PE 到達環境のみ
Private Endpoint	SAS	○	PE 到達環境のみ
Private Endpoint	Entra ID	○	PE 到達環境のみ
任意	Anonymous 無効・認証なし	×	認証エラー
任意	Shared Key Disabled + Service SAS	×	利用不可
任意	Shared Key Disabled + Account SAS	×	利用不可
任意	Shared Key Disabled + User Delegation SAS	○	利用可能

Public Network Access の観点で見ると

特に誤解されやすい組み合わせを整理すると以下のようになります。

Public Network Access	Private Endpoint	認証方式	アクセス
Enabled	なし	Anonymous	○
Disabled	あり	Anonymous	○
Disabled	あり	User Delegation SAS	○
Disabled	あり	Entra ID	○
Disabled	なし	すべて	×

重要なのは、

Public Network Access = Disabled

であっても、

Private Endpoint + Anonymous Access

は成立するという点です。

4. 実務での注意点：Azure Front Door + Private Link 構成

近年のエンタープライズ環境でよく採用される構成です。

Internet
   │
   ▼
Azure Front Door Premium
   │
   ▼
Private Link
   │
   ▼
Azure Storage Account

この構成では Storage Account をインターネットから隠蔽しながら、Front Door 経由で世界中へコンテンツ配信できます。

注意すべき Front Door の制約

Azure Front Door にはオリジン認証としてマネージド ID を利用する機能があります。

しかし現時点では、

Private Link を有効化したオリジンに対する Managed Identity Origin Authentication はサポートされていません。

そのため、

AFD + Private Link + Managed Identity Origin Authentication

という構成は利用できません。

その結果どうなるのか

AFD + Private Link を採用する場合、Storage Account へのアクセス方式として別の認証手段を検討する必要があります。

代表的な選択肢は以下です。

パターン1：Anonymous Access

AFD ──> Private Link ──> Storage（Anonymous）

技術的には動作します。ただし企業システムでは匿名アクセスの利用は慎重に判断すべきです。

パターン2：SAS Token

AFD ──> Private Link ──> Storage（SAS）

より安全な構成として採用されることが多い方式です。

特に User Delegation SAS を利用すると、

Shared Key の無効化が可能
期限付きアクセス
最小権限運用

を実現できます。一般的にはこちらの方式が推奨されます。

5. User Delegation SAS を利用した推奨アーキテクチャ

より高いセキュリティを求める場合は、バックエンド API が User Delegation SAS を発行する方式が有効です。

[クライアント]
      │
      │ ① リクエスト
      ▼
[Web API / App Service]
      │
      │ Managed Identity
      ▼
[Microsoft Entra ID] (User Delegation Key 取得)
      │
      ▼
SAS URL 生成
      │
      ▼
[クライアントへ返却]
      │
      │ ② SAS URL でアクセス
      ▼
[Azure Front Door]
      │
      ▼
Private Link
      │
      ▼
[Storage Account]

処理の流れ

Web API が自身の Managed Identity で User Delegation Key を取得する
User Delegation SAS を生成する
Front Door のホスト名を含む SAS URL をクライアントへ返却する
クライアントは Front Door 経由でアクセスする
Storage Account が SAS を検証する

この方式であれば、以下の条件を同時に満たす堅牢な構成が実現可能です。

Shared Key Access の無効化
Public Network Access の無効化
Private Link による閉域接続
期限付きの最小権限アクセス

まとめ

Azure Storage のアクセス制御を理解する際は、次の3点を覚えておくと混乱しません。

① Private Endpoint は認証方式ではない
Private Endpoint は「どこから接続できるか」を制御する仕組みです。

② 認証とネットワーク制御は別レイヤー
「誰がアクセスできるか（認証）」と「どこからアクセスできるか（ネットワーク）」を分離して考えることが重要です。

③ AFD + Private Link では設計に注意
現時点では AFD の Managed Identity Origin Authentication を Private Link オリジンで利用できません。そのため User Delegation SAS などの代替手段を設計に組み込む必要があります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up