MENU

Azure BlobのSAS URLで403 AuthenticationFailedが出る原因と切り分け方

Azure

Azure Blob StorageのSAS URLへアクセスした際に403 AuthenticationFailedが返る場合、有効期限だけを延長して試し続けるのは非効率です。

最初に確認すべきなのは、HTTPステータスの「403」ではなく、レスポンスに含まれるエラーコードとエラー詳細です。その内容から、次の順で切り分けます。

  1. stとseによる開始時刻・有効期限の問題
  2. ストレージアカウントキーや文字コードによる署名不一致
  3. svなどのSAS書式不正
  4. Service SASとAccount SASのスコープ不一致
  5. 権限、ネットワーク制限、Shared Key拒否ポリシー

特にKeyBasedAuthenticationNotPermittedが返っている場合、SASの期限を変更しても直りません。Microsoft Entra ID認証やUser Delegation SASへの切り替えが必要です。

目次

403だけで判断せず、エラーコードと詳細を確認する

Azure Blob Storageの403エラーには、AuthenticationFailed、AuthorizationPermissionMismatch、AuthorizationFailureなど、原因を絞り込むための詳細なエラーコードが付随します。まずは認証、権限、ネットワークのどこで拒否されているかを分けることが重要です。([Microsoft Learn][1])

ブラウザに表示される画面だけでは詳細が分からない場合は、開発者ツールのネットワークタブやcurlでレスポンスヘッダーと本文を確認します。

Windowsでは、次のようにcurl.exeを実行できます。

curl.exe -i -sS "<SAS URL>"

レスポンス本文では、主に次の項目を確認します。

<Error>
  <Code>AuthenticationFailed</Code>
  <Message>...</Message>
  <AuthenticationErrorDetail>...</AuthenticationErrorDetail>
</Error>

確認するポイントは次の3つです。

  • <Code>の値
  • <AuthenticationErrorDetail>の内容
  • レスポンスヘッダーのx-ms-error-code

SAS URLはアクセス権を含む機密情報です。実際のURLを問い合わせ票、チャット、ソースコード、スクリーンショットへそのまま貼り付けないようにしてください。少なくともsigを含むクエリ文字列全体を伏せたうえで共有します。

エラー内容から原因を判断する早見表

Microsoftのトラブルシューティングでは、同じ403でも、認証情報、権限、ネットワーク、ポリシーなど複数の原因があると整理されています。([Microsoft Learn][1])

エラーコード・詳細主な原因最初に行うこと
AuthenticationFailedで時刻に関する詳細SASの期限切れ、開始時刻が未来、時刻ずれstとseを確認してSASを再生成する
AuthenticationFailedでMAC署名不一致キー違い、キー再生成、URLの改変、エンコード不正アカウント名、使用キー、URLの受け渡し方法を確認する
AuthenticationFailedでsv形式不正SASの手作業作成、書式不正、バージョン値の異常SDKまたはStorage Explorerで作り直す
AuthenticationFailedでリソースレベル不一致Service SASをアカウントレベル操作へ使用操作に合ったSASの種類とスコープへ変更する
AuthorizationPermissionMismatchspに必要な権限がない読み取り、書き込み、削除、一覧などの権限を確認する
AuthorizationServiceMismatchBlob以外のサービス向けSASを使用ssなどの対象サービスを確認する
AuthorizationFailureファイアウォール、IP、仮想ネットワーク制限ストレージアカウントのネットワーク設定を確認する
KeyBasedAuthenticationNotPermittedShared Key認証が無効Entra ID認証またはUser Delegation SASへ切り替える

期限と時刻の問題を切り分ける

SASの時刻に関係する主なパラメーターは次の2つです。

パラメーター意味
stSASの利用開始時刻
seSASの有効期限

確認する順序は次のとおりです。

seが現在時刻より後になっているか

seが過去であれば、そのSASは期限切れです。将来の有効期限を指定して、新しいSASを生成します。

ただし、URL内のseだけを手作業で書き換えてはいけません。SASの署名はSASパラメーターを基に作られているため、期限だけを変更すると署名との整合性が失われます。必ずSASそのものを再生成します。([Microsoft Learn][2])

stよりseが後になっているか

次のような設定ではSASが成立しません。

st=2026-09-12T10:00:00Z
se=2026-09-12T09:00:00Z

有効期限であるseは、開始時刻のstより後である必要があります。

日付だけでなく、時刻、タイムゾーン、URLデコード後の値まで確認してください。

即時利用するSASでstが未来になっていないか

SASを作成した直後に使用する場合、開始時刻を現在時刻ぴったりにすると、SASを生成した端末とAzure側の時刻差によって「まだ有効ではない」と判定されることがあります。

即時利用するSASでは、原則として次のいずれかにします。

  • 開始時刻を指定しない
  • 開始時刻に余裕を持たせる
  • 有効期限を極端に短くしない

Microsoftのトラブルシューティングでも、即時利用するSASでは開始時刻を設定しない方法が案内されています。端末間の時刻差により、期限前でも無効または期限切れのように見える場合があります。([Microsoft Learn][1])

時刻表示の基準をそろえる

Azure Portal、アプリケーション、ログ、ローカル端末で表示タイムゾーンが異なると、まだ有効なつもりでも実際には期限切れになっていることがあります。

切り分け時は次の時刻を記録します。

  • SASを生成した時刻
  • stの値
  • seの値
  • 403が発生した時刻
  • SASを生成した端末の現在時刻

各時刻を同じ基準へそろえて比較すると、タイムゾーンの読み違いを発見しやすくなります。

Stored Access Policyも確認する

Service SASをStored Access Policyに関連付けている場合、URL上のseだけでは有効期間が決まりません。

ポリシー側で次の変更が行われていると、SAS URLに記載された期限より早く無効になることがあります。

  • ポリシーの有効期限を短縮した
  • 権限を削除した
  • ポリシーそのものを削除した

Stored Access Policyを更新した直後には、反映まで一時的に403になる可能性もあります。([Microsoft Learn][1])

MAC署名不一致を切り分ける

エラー詳細がMAC署名の不一致を示している場合、Azure側で計算した署名と、SAS URLに含まれるsigが一致していません。

主な確認項目は次のとおりです。

正しいストレージアカウントキーを使っているか

Service SASとAccount SASは、ストレージアカウントキーを使って署名されます。別のストレージアカウントのキーで生成したSASは使用できません。([Microsoft Learn][2])

次の組み合わせが一致しているか確認します。

  • URLのストレージアカウント名
  • SAS生成時に指定したストレージアカウント名
  • SAS生成時に使用したPrimary KeyまたはSecondary Key
  • 接続文字列に含まれるアカウント名とキー

例えば、アカウントAのキーで生成したSASを、アカウントBのBlob URLへ付け替えても認証は成功しません。

キーが再生成されていないか

ストレージアカウントキーを再生成すると、そのキーで以前に署名したSASが使用できなくなることがあります。

次のような運用では注意が必要です。

  1. Primary KeyでSASを発行する
  2. Primary Keyを再生成する
  3. 過去に発行したSASを引き続き使用する
  4. MAC署名不一致で403になる

キーをローテーションした場合は、どちらのキーでSASを生成していたか確認し、新しいキーまたは別の認証方式でSASを再発行します。([Microsoft Learn][1])

URLのコピーやエンコードで値が変わっていないか

SAS URLには、&、%、+など、受け渡し時に変換されやすい文字が含まれることがあります。

次のような経路ではURLが改変されていないか確認します。

  • HTMLへ埋め込んだときに&が&amp;になった
  • メールやチャットでURLが途中改行された
  • システムの文字数制限で末尾が切れた
  • sig内の記号がURLデコード後に別の文字へ変わった
  • アプリケーションがクエリ文字列を再エンコードした
  • URL全体を引用符で囲まず、シェルが&を制御文字として扱った

コマンドで確認するときは、SAS URL全体を引用符で囲みます。

curl.exe -i -sS "https://example.blob.core.windows.net/container/file.txt?<SAS>"

署名文字列を手作業で修復するのではなく、元の生成処理を見直してSASを再生成する方が確実です。

sv不正やSASの書式ミスを切り分ける

svは、SASで使用するストレージサービスのバージョンを表すパラメーターです。

次のような場合は、SASの書式不正を疑います。

  • svが空になっている
  • 日付形式が崩れている
  • 独自プログラムでクエリ文字列を連結している
  • URLエンコードを複数回行っている
  • 必要なパラメーターが欠落している
  • パラメーター名の大文字・小文字や綴りを誤っている

手作業でSASを組み立てている場合は、一度その処理を外し、次のいずれかで生成し直します。

  • Azure Storageの公式SDK
  • Azure Storage Explorer
  • Azure Portal
  • Azure CLI
  • Azure PowerShell

Microsoftも、署名文字列の作成ミスを避けるため、公式SDKやStorage Explorerなどの利用を案内しています。([Microsoft Learn][1])

パラメーターを個別に直さない

例えば、次のような修正は避けます。

svの値だけを新しい日付へ変更する
seだけを延長する
srをbからcへ書き換える
spへwを追加する

これらの値は署名の計算に関係します。クエリパラメーターを変更する場合は、変更後の条件でSAS全体を再生成してください。

Service SASとAccount SASのスコープを確認する

Azure Storageには、主に次の3種類のSASがあります。

SASの種類署名に使う認証情報主な用途
User Delegation SASMicrosoft Entraの資格情報から取得した委任キーBlobへの限定アクセス
Service SASストレージアカウントキー特定サービス内のBlobやコンテナーへのアクセス
Account SASストレージアカウントキー複数サービスやサービスレベル操作を含むアクセス

Service SASは、Blob、Queue、File、Tableなど、特定のストレージサービス内のリソースへ権限を委任するものです。Account SASは、サービスレベル操作や複数サービスにまたがる権限を付与できます。([Microsoft Learn][2])

操作とSASの種類が合っているか

例えば、次の組み合わせを確認します。

実行したい操作確認するスコープ
特定BlobのダウンロードBlobを対象にしたService SASまたはUser Delegation SAS
コンテナー内のBlob一覧取得コンテナーを対象にしたSASと一覧権限
Blobのアップロード対象リソースと書き込み・作成権限
ストレージアカウント内のコンテナー一覧取得Account SASのサービス・リソース種別、またはEntra ID認証
Blob以外のStorageサービスへアクセスssなどで対象サービスが許可されているか

特定Blob向けのService SASを、ストレージアカウント全体の操作へ流用すると、リソースレベルの不一致として拒否されることがあります。([Microsoft Learn][1])

URLのリソースを後から変更していないか

SASを生成した後に、URLのコンテナー名やBlob名だけを書き換えても利用できるとは限りません。

次の値が、SAS生成時の対象と一致しているか確認します。

  • ストレージアカウント
  • コンテナー
  • Blob名
  • リソース種別
  • ストレージサービス
  • 実行するHTTPメソッドと操作内容

対象リソースが変わる場合は、そのリソースを対象として新しいSASを生成します。

AuthorizationPermissionMismatchならspを確認する

AuthenticationFailedではなくAuthorizationPermissionMismatchが返っている場合、SAS自体の署名は認識されていても、実行しようとした操作に必要な権限が不足している可能性があります。

spパラメーターには、SASへ付与された権限が含まれます。

代表的な権限は次のとおりです。

記号主な意味
r読み取り
w書き込み
d削除
l一覧
c作成
a追加

例えば、読み取り専用のSASでアップロードや削除を行うことはできません。また、操作によっては複数の権限が必要になる場合があります。

確認時は「SAS URLが開けるか」だけではなく、実際に失敗した操作を特定します。

  • GETによるダウンロード
  • PUTによる新規アップロード
  • 既存Blobの上書き
  • DELETEによる削除
  • コンテナー内の一覧取得

Microsoftのトラブルシューティングでも、上書きなどの操作では複数の権限が必要になる場合があるため、spの確認が案内されています。([Microsoft Learn][1])

AuthorizationFailureならネットワーク制限を確認する

署名や期限が正しくても、ストレージアカウントのネットワーク設定によって403になることがあります。

主な確認項目は次のとおりです。

  • Public network accessが無効になっていないか
  • 接続元IPアドレスが許可されているか
  • 仮想ネットワークまたはサブネットが許可されているか
  • ストレージアカウントのファイアウォールで拒否されていないか
  • Private Endpoint経由で正しいプライベートIPへ名前解決されているか
  • SASのsipで許可したIPと実際の送信元IPが一致しているか

「社内ネットワークでは失敗するが、別回線では成功する」といった場合は、SASの期限よりネットワーク制限を優先して確認します。

Azure PortalからBlobを開く操作でも、ブラウザを実行している端末側のネットワークからアクセスする場合があります。管理画面へサインインできていることと、Blobのデータプレーンへ接続できることは分けて考える必要があります。([Microsoft Learn][1])

KeyBasedAuthenticationNotPermittedは期限では直らない

エラーコードがKeyBasedAuthenticationNotPermittedの場合、ストレージアカウントでShared Key認証が拒否されています。

Azure Portalでは、ストレージアカウントの構成にある「ストレージアカウントキーへのアクセスを許可」に相当する設定が無効になっている状態です。

この設定が無効な場合、次のSASは拒否されます。

  • ストレージアカウントキーで署名したService SAS
  • ストレージアカウントキーで署名したAccount SAS

一方、Microsoft Entra IDを基に署名するUser Delegation SASは、Blob Storageで利用できます。Microsoftは、可能な場合はUser Delegation SASを使用することを推奨しています。([Microsoft Learn][3])

対応方法

優先順位は次のとおりです。

  1. アプリケーションをMicrosoft Entra ID認証へ変更する
  2. SASが必要な場合はUser Delegation SASを使用する
  3. 実行主体へ必要最小限のAzure RBACロールを割り当てる
  4. Shared Keyを再び許可する必要があるか、組織のセキュリティ方針を確認する

期限の延長、stの削除、SASの再生成を繰り返しても、Service SASやAccount SASのままでは解決しません。

Shared Keyを再び有効にすればアクセスできる可能性はありますが、セキュリティポリシーとして意図的に無効化している環境もあります。障害対応だけを理由に設定を戻さず、Entra IDへの移行を先に検討します。

SAS URLの403を切り分ける実務手順

調査時は、次の順序で進めると原因を取り違えにくくなります。

失敗した操作を特定する

最初に、何をしようとして失敗したのかを記録します。

  • Blobの読み取り
  • Blobの作成
  • 既存Blobの上書き
  • Blobの削除
  • コンテナー内の一覧取得
  • コンテナー一覧の取得

同じSASでも、読み取りは成功し、書き込みだけが失敗することがあります。

エラーコードと詳細を取得する

403というステータスだけで判断せず、次を保存します。

  • エラーコード
  • エラー詳細
  • HTTPメソッド
  • アクセス先のホスト名
  • コンテナー名とBlob名
  • 発生時刻
  • Request ID
  • 接続元ネットワーク

SAS本体やストレージアカウントキーは保存・共有しないでください。

エラーコードで大分類する

AuthenticationFailed
  ├─ 時刻に関する詳細 → st、se、時刻ずれ
  ├─ MAC署名不一致 → アカウント、キー、キー再生成、エンコード
  ├─ sv形式不正 → SASの書式と生成方法
  └─ リソースレベル不一致 → SASの種類とスコープ

AuthorizationPermissionMismatch
  └─ spと実行操作を確認

AuthorizationFailure
  └─ IP、ファイアウォール、VNet、Private Endpointを確認

KeyBasedAuthenticationNotPermitted
  └─ Entra IDまたはUser Delegation SASへ移行

公式ツールで最小構成のSASを再生成する

原因を絞り込むため、一度に多くの条件を付けないことが重要です。

例えば読み取り確認なら、次のような最小条件で生成します。

  • 対象は1つのBlobまたは1つのコンテナー
  • 権限は読み取りのみ
  • IP制限は一時的に外して比較する
  • 即時利用なら開始時刻を指定しない
  • 有効期限には調査可能な余裕を持たせる
  • HTTPSを使用する

最小構成で成功した後、IP制限や権限を1項目ずつ追加すると、どの条件で失敗したかを追跡しやすくなります。

同じクライアントとネットワークから再確認する

ネットワーク制限を切り分ける場合、SASを作り直しただけで接続元を変えてしまうと、何が原因だったか分からなくなります。

再確認時は、可能な限り次の条件を固定します。

  • 同じPCまたは実行環境
  • 同じネットワーク
  • 同じHTTPメソッド
  • 同じBlob
  • 同じアプリケーション

変更する項目を1つに限定することが、403調査では重要です。

よくある失敗と避け方

期限だけを何度も延長する

期限切れ以外のエラーに対してseを延長しても解決しません。

特に次のコードでは、別の確認が必要です。

  • AuthorizationPermissionMismatch
  • AuthorizationFailure
  • KeyBasedAuthenticationNotPermitted

URL内の日時だけを書き換える

stやseは署名の計算に関係するため、手作業で変更すると署名不一致になる可能性があります。

日時を変更したい場合は、SASを再生成します。

AuthenticationFailedを権限不足だと決めつける

認証失敗と権限不足は分けて考えます。

  • 認証情報や署名を検証できない場合はAuthenticationFailed
  • 認証後に操作権限が足りない場合はAuthorizationPermissionMismatch
  • ネットワーク制限ではAuthorizationFailureになる場合がある

まずエラーコードを確認し、該当する分岐だけを調査します。

Storage Explorerで成功したためSASも正しいと思い込む

Storage ExplorerがMicrosoft Entra IDで接続し、アプリケーションがService SASで接続している場合、認証方式が異なります。

Storage Explorerで成功しても、次の問題は残る可能性があります。

  • SASの期限切れ
  • SASの権限不足
  • SASの署名不一致
  • Shared Key認証の拒否
  • アプリケーションによるURL改変

比較するときは、どの認証方式で成功したのかも記録してください。

まとめ

Azure BlobのSAS URLで403が発生したら、最初にレスポンスのエラーコードと詳細を確認します。

AuthenticationFailedの場合は、次の順で調べると効率的です。

  1. stとseの前後関係、有効期限、時刻ずれ
  2. ストレージアカウントと署名キーの組み合わせ
  3. キー再生成の有無
  4. URLの欠落、変換、エンコード不正
  5. svなどのSAS書式
  6. Service SAS、Account SAS、User Delegation SASのスコープ

AuthorizationPermissionMismatchならsp、AuthorizationFailureならネットワーク設定を確認します。

KeyBasedAuthenticationNotPermittedの場合は、期限を延長しても解決しません。Service SASやAccount SASの再発行を繰り返すのではなく、Microsoft Entra ID認証またはUser Delegation SASへの切り替えを進めることが適切です。
[1]: https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/blobs/authentication/storage-troubleshoot-403-errors “Troubleshoot 403 errors in Azure Blob Storage – Azure | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview “Grant limited access to data with shared access signatures (SAS) – Azure Storage | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent “Prevent authorization with Shared Key – Azure Storage | Microsoft Learn”

Azure
SAS Azure Blob Storage HTTP 403 AuthenticationFailed

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次