1. 概要・要件
Azure Blob Storageに対して、以下の要件を満たすセキュアなアクセス構成を構築した際の備忘録である。
- ネットワーク要件: Storage Accountのパブリックネットワークアクセスを無効化（または特定の仮想ネットワークに限定）する。
-
アクセス要件:
- 認証なしでのファイル読み取り
- クライアント（本件はWebブラウザ）からの直接ファイルアップロード（SASトークンを利用）
- サーバー（App Service）からのファイル削除（SASトークンを利用）
対象リソースは以下の通りである。
- Azure Front Door
- App Service
- Storage Account
2. 発生した事象
変更前はパブリックアクセスを許可し、ADLS (Azure Data Lake Storage) のエンドポイントに対して直接通信を行っていた。
セキュリティ要件を満たすため、Front Door経由のカスタムドメインとプライベートリンク（Private Endpoint）を設定した。結果として認証なしの読み込みには成功したものの、SASトークンを利用した書き込みが 400 Bad Request で失敗する事象が発生した。
3. 原因
使用しているSDKと、Front Doorがルーティングするバックエンドのエンドポイント仕様のミスマッチが原因であった。
成功していた時の構成（パブリックアクセス時）:
アプリケーション側ではADLS用のSDK（DataLakeFileSystemClient）を使用し、ADLSエンドポイント（.dfs.core.windows.net）へ直接アクセスしていた。
失敗した時の構成（Front Door経由時）:
Front Doorのオリジン（配信元）ホストはBlobエンドポイントに設定されていた。そのため、クライアントがADLS用SDKの仕様でリクエストを送信した先がBlobエンドポイントとして処理され、パラメータの不整合が発生して 400 Bad Request (MissingRequiredHeader) で弾かれていた。
4. 解決策
アプリケーションのコードを、ADLS用SDKからBlob Storage用SDKへ置き換える。
変更内容:
DataLakeFileSystemClient 等の実装を廃止し、Blob Storage用のSDK（例: JavaScriptの場合は @azure/storage-blob）を使用してリクエストを行うようにアプリケーションを改修した。
理由:
構築したネットワークインフラ（Private EndpointやFront Door）がBlobエンドポイントを向いているためである。また、Microsoftの公式ドキュメントでも、Front DoorのバックエンドとしてBlobストレージを利用する構成がサポートされている。
5. 結果
アプリケーション側でBlob Storage用SDKを利用するように改修したことで、Front Door経由でのSASトークンを用いた書き込み・削除が正常に動作するようになった。これにより、Storage Accountのパブリックアクセスを完全に無効化し、セキュリティ要件を満たす構成を実現できた。