Azure Blob Storage SFTPのEntra IDアクセスがGA｜影響範囲と管理者対応

Azure Blob Storage SFTPをローカルユーザーで運用している場合、最初に行うべきことは、SFTPを有効にしたストレージアカウントと利用者の棚卸し、監査ログの有効化、人や取引先が使う接続からのMicrosoft Entra ID移行検証です。

今回の一般提供開始によって、既存のローカルユーザーが自動的に削除されたり、接続方式が強制的に切り替わったりするわけではありません。しかし、Microsoft Entra IDベースのアクセスを利用すれば、SFTPにもAzure RBAC、Azure ABAC、POSIX形式のACL、MFA、条件付きアクセス、外部IDを適用できます。長期間使われるパスワードやSSH秘密鍵に依存した運用を減らし、入社・異動・退職に伴うアクセス管理を一元化できる点が大きな変化です。(TECHCOMMUNITY.MICROSOFT.COM)

一方で、Microsoft Entra IDのパスワードをSFTPクライアントへ直接入力する方式ではありません。Microsoft Entra IDで認証した後、有効期間65分のOpenSSH証明書を取得し、その証明書と秘密鍵を使って接続します。マネージドIDやホームディレクトリには対応していないため、特に自動処理を移行する際は事前検証が必要です。(Microsoft Learn)

Azure Blob Storage SFTPのMicrosoft Entra IDアクセスGAとは

「Microsoft Entra ID access for Azure Blob Storage SFTP reaches general availability」は、Azure Blob StorageのSFTP接続において、Microsoft Entra IDのユーザーやサービスプリンシパルを認証・認可に利用できるようになったことを示す更新です。

Azure Updatesの当該情報は2026年7月7日に公開または実質更新され、一般提供済みの機能として案内されました。更新カード上の提供時期は2026年6月で、Azure Storage Blogにも2026年6月23日付で一般提供開始の追記があります。そのため、7月7日から既存環境へ強制的な変更が入るというより、6月に一般提供となった機能がAzure Updatesで正式に周知されたものと捉えるのが適切です。(Microsoft Azure)

従来、Azure Blob Storage SFTPの認証は、ストレージアカウント内に作成するローカルユーザーが中心でした。利用者ごとにパスワードまたはSSH公開鍵を登録し、ストレージアカウント単位で資格情報や権限を管理する必要があります。

Microsoft Entra IDアクセスでは、既存のユーザー、グループ、サービスプリンシパルを利用できます。SFTPのファイル操作も、Blob Storageで使用しているAzure RBAC、Azure ABAC、ACLの権限モデルに基づいて認可されます。SFTPだけが独立した権限体系になるのではなく、REST API、SDK、Azure CLIなどと同じID管理方針へ近づけられることが重要です。(Microsoft Learn)

一般提供版で改善された点

一般提供に合わせて、次の点も改善されています。

Storage Blob Data OwnerロールとAzure ABACを組み合わせた際の不整合が修正され、タイムアウト問題が解消された
サブオペレーションへの対応が追加され、より細かなアクセス制御が可能になった

プレビュー版から利用している環境では、単に「一般提供になったため対応不要」と判断せず、ABAC条件やカスタム権限を含むファイル操作を再テストする必要があります。特に、所有者変更、ACL変更、上書き、削除、名前変更などは、読み取りと書き込みだけのテストでは問題を発見できません。(TECHCOMMUNITY.MICROSOFT.COM)

Microsoft Entra IDでSFTPへ接続する仕組み

Microsoft Entra IDベースのSFTP接続は、次の流れで行われます。

Azure CLI、Azure PowerShell、SDKなどからMicrosoft Entra IDへサインインする
RSA公開鍵を渡し、OpenSSH証明書を取得する
OpenSSH証明書に対応したSFTPクライアントまたはSDKから接続する

接続の流れを簡略化すると、次のようになります。

Microsoft Entra ID認証 → OpenSSH証明書取得 → SFTP接続 → RBAC・ABAC・ACLによる認可

OpenSSH証明書の有効期間は65分です。期限切れ後に新しい接続や処理を開始する場合は、証明書を再取得する必要があります。また、証明書にはRSA鍵が必要で、ECDSA証明書はサポートされていません。(Microsoft Learn)

ローカルユーザー方式との違い

比較項目	ローカルユーザー	Microsoft Entra ID
IDの管理場所	ストレージアカウントごと	Microsoft Entra IDで一元管理
認証方法	Azure生成パスワード、SSH公開鍵	Entra認証後に取得するOpenSSH証明書
資格情報の期間	パスワードや鍵を長期間利用しやすい	OpenSSH証明書は65分
権限管理	コンテナー権限とACL	Azure RBAC、Azure ABAC、ACL
MFA・条件付きアクセス	Entraの制御対象外	Entra認証時に適用可能
退職・異動時の対応	各ストレージアカウントで対応	IDやグループを中心に管理可能
外部ユーザー	個別にローカルユーザーを作成	Microsoft Entra External Identitiesを利用可能
自動処理	パスワードまたはSSH鍵	サービスプリンシパルを利用可能
マネージドID	対象外	SFTP接続では未対応
ホームディレクトリ	設定可能	未対応
クライアント要件	一般的な鍵認証対応クライアント	OpenSSH証明書対応クライアント

ローカルユーザーはAzure RBACやAzure ABACと連携しません。たとえば、ある利用者のMicrosoft Entra IDには読み取り権限しかなくても、同じ人物が削除権限を持つローカルユーザーでSFTP接続すれば、削除操作を実行できる可能性があります。Microsoft Entra IDへ移行した後もローカルユーザーを残す場合、この別経路を見落とさないことが重要です。(Microsoft Learn)

何が保護対象になり、何が変わらないのか

今回の一般提供は、Azure Blob Storage全体のセキュリティ設定を自動的に変更するものではありません。保護範囲を正しく切り分ける必要があります。

項目	Microsoft Entra ID化による影響
SFTP接続者の本人確認	Entraのユーザーまたはサービスプリンシパルで認証できる
SFTPによるファイル操作	Azure RBAC、Azure ABAC、ACLで認可できる
MFA・条件付きアクセス	OpenSSH証明書を取得するためのEntra認証に適用できる
利用者の追加・削除	EntraのIDライフサイクルと連動させやすくなる
取引先・委託先のアクセス	External Identitiesによるゲスト管理が可能になる
既存のローカルユーザー	自動削除・自動無効化されない
ストレージのパブリック公開	自動的には制限されない
ファイアウォール・Private Endpoint	別途設定が必要
SFTP以外のShared Key、SAS、匿名アクセス	別のアクセス経路として個別管理が必要
暗号化、バックアップ、レプリケーション	今回の機能だけでは変更されない

保護対象はBlobデータへのSFTPアクセス

Microsoft Entra IDアクセスの対象は、SFTP経由でBlobデータを読み取り、作成、更新、削除するデータプレーン操作です。

Azure Blob Storage SFTPを利用するには、階層型名前空間が有効なストレージアカウントが必要です。権限は、ストレージアカウントやコンテナーを対象としたAzure RBACに加え、ディレクトリやファイル単位のACLで細かく制御できます。(Microsoft Learn)

ネットワーク公開範囲は別途対策が必要

Microsoft Entra IDを導入しても、SFTPエンドポイントへのネットワーク到達性は自動的に狭まりません。SFTPではTCPポート22を使用し、パブリックアクセスを制限するには、ストレージアカウントのファイアウォール、仮想ネットワーク、Private Endpointなどを設定する必要があります。(Microsoft Learn)

Private Endpointを作成しただけでは、パブリックなBlobエンドポイントが利用可能な状態で残ることがあります。ネットワーク設定を「選択した仮想ネットワークとIPアドレスから有効」にするなど、パブリックアクセス側の設定も確認してください。(Microsoft Learn)

管理ロールとデータアクセスロールは異なる

AzureのOwner、Contributor、Storage Account Contributorなどは、ストレージアカウントを管理するためのロールです。これらのロールだけでは、Microsoft Entra IDを使ったBlobデータへのアクセス権は付与されません。

SFTPでBlobデータへアクセスさせる場合は、用途に応じて次のデータアクセスロールを割り当てます。

ロール	主な用途
Storage Blob Data Reader	ファイルの参照やダウンロードのみ
Storage Blob Data Contributor	読み取り、書き込み、削除
Storage Blob Data Owner	所有権やPOSIX ACLの管理を含む操作

ロールはサブスクリプション全体ではなく、可能な限りコンテナーなど狭いスコープへ割り当てます。なお、ロール割り当ての反映には時間がかかることがあり、公式ドキュメントでは最大30分かかる可能性が示されています。設定直後の認可エラーを、誤った権限設計と即断しないことも大切です。(Microsoft Learn)

対応が必要な環境を判断する

対応の緊急度は、SFTPの有効・無効だけでなく、「誰が、どのクライアントから、どのような処理を行っているか」で判断します。

現在の利用状況	推奨対応	優先度
SFTPを有効にしていない	即時変更は不要。今後の標準方式としてEntra IDを検討	低
社員がローカルユーザーで接続	Entraユーザーまたはグループへの移行を優先	高
取引先ごとにローカルユーザーを作成	External Identitiesを使った移行を検証	高
プレビュー版のEntra IDアクセスを利用中	ABAC、ACL、所有権変更を含めて回帰テスト	高
バッチ処理が固定パスワードを利用	サービスプリンシパルと証明書更新処理を検証	高
バッチ処理がマネージドIDを前提としている	SFTPでは利用不可。サービスプリンシパルまたはREST／SDK方式を検討	高
古いSFTPクライアントを利用	OpenSSH証明書への対応状況を確認	中
ホームディレクトリに依存したスクリプト	接続後に`cd`する構成へ変更	中
Entra ID移行済みだがローカルユーザーも残存	不要なローカルユーザーを無効化・削除	高
Entra ID移行済みだが診断ログ未設定	ログ収集を最優先で設定	高

特に優先度が高いのは、社員や取引先に長期利用のパスワード、共有SSH秘密鍵を配布している環境です。人が利用する接続はMFAや条件付きアクセスの効果を得やすく、Microsoft Entra IDへ移行するメリットが明確です。

一方、24時間稼働するバッチ処理は、65分で期限切れになるOpenSSH証明書の更新処理が必要です。接続を長時間維持する処理、頻繁に再接続する処理、障害時に人手で再実行している処理は、移行前に証明書取得失敗時の再試行と監視を実装する必要があります。(Microsoft Learn)

管理者が実施すべき設定と移行手順

SFTP利用状況を棚卸しする

最初に、次の情報を一覧化します。

SFTPが有効なストレージアカウント
ストレージアカウントの用途と管理部門
登録されているローカルユーザー
パスワード認証とSSH鍵認証のどちらを使っているか
利用者が社員、外部ユーザー、自動処理のどれに該当するか
使用中のSFTPクライアントとバージョン
接続元IPアドレス、ネットワーク、Private Endpointの有無
接続先コンテナー、ディレクトリ、必要なファイル操作
Azure Monitorの診断設定とログ保存期間

「ローカルユーザー名だけを見ても利用者が分からない」「SSH鍵の所有者が分からない」という状態は、それ自体が優先的に解消すべきリスクです。

IDを用途別に設計する

人と自動処理でIDを分けます。

利用者	推奨するID
社内の一般利用者	Microsoft Entraユーザーとセキュリティグループ
管理者	専用管理グループ。必要に応じてPIMを利用
取引先・委託先	Microsoft Entra External Identitiesのゲストユーザー
バッチや連携システム	専用サービスプリンシパル
Azure上のワークロード	SFTPではマネージドID未対応。接続方式を含めて再検討

権限を個人へ直接付与すると、利用者が増えるほど棚卸しが難しくなります。社員や取引先は、業務や接続先ごとのセキュリティグループにまとめ、グループへRBACやACLを設定する方法が適しています。

最小権限でRBACとACLを設定する

まず、コンテナー単位で必要なデータアクセスロールを割り当てます。そのうえで、同じコンテナー内の特定ディレクトリだけにアクセスさせたい場合はACLを使用します。

たとえば、取引先Aにpartner-a/inboxへのアップロードだけを許可し、他の取引先のディレクトリを参照させたくない場合は、次のように設計します。

取引先A用のEntraグループを作成する
対象コンテナーに必要最小限のデータアクセスロールを割り当てる
partner-a/inboxまでの親ディレクトリに移動用の実行権限を設定する
対象ディレクトリに必要な読み取り・書き込み権限を設定する
削除が不要であれば削除権限を与えない
ACL変更が不要であればStorage Blob Data Ownerを与えない

所有権やACLを変更する必要がない利用者へ、安易にStorage Blob Data Ownerを付与しないことが重要です。

条件付きアクセスとMFAを設計する

人が利用するSFTP接続では、OpenSSH証明書を取得するためのMicrosoft Entra ID認証に、MFAや条件付きアクセスを適用できます。たとえば、次のようなポリシーが候補になります。

MFAを必須にする
許可された国や接続元に制限する
管理対象デバイスからの利用を求める
リスクの高いサインインをブロックする
外部ユーザーに追加の認証要件を設定する

ただし、条件付きアクセスはSFTPのファイル操作ごとに対話型認証を行うものではありません。OpenSSH証明書を取得する前のEntra認証で評価されるため、発行済み証明書と既存セッションの扱いを踏まえて運用してください。OpenSSH証明書は65分で期限切れになります。(TECHCOMMUNITY.MICROSOFT.COM)

対応クライアントで接続テストを行う

Azure CLIを利用する場合、基本的な検証手順は次のようになります。

az login

ssh-keygen -t rsa

az sftp cert \
  --public-key-file ~/.ssh/id_rsa.pub \
  --file ~/.ssh/my_cert.pub

az sftp connect \
  --storage-account <storage-account-name> \
  --certificate-file ~/.ssh/my_cert.pub

生成したRSA秘密鍵は、アクセス権を限定した安全な場所に保存します。サービスプリンシパルを使う場合も、クライアントシークレットをスクリプトやコマンド履歴へ直接残さない設計が必要です。(Microsoft Learn)

GUIクライアントでは、OpenSSH証明書への対応状況を確認します。WinSCPはバージョン6.0からユーザー認証用OpenSSH証明書に対応しています。古いバージョンを利用している環境では、アップグレードまたは別クライアントへの変更が必要です。(Microsoft Learn)

実際のファイル操作を一通り検証する

接続成功だけで移行可と判断してはいけません。業務で使う操作を一通り確認します。

コンテナーとディレクトリの一覧表示
ファイルのアップロードとダウンロード
同名ファイルの上書き
ディレクトリの作成
ファイルやディレクトリの削除
名前変更や移動
大容量ファイルの転送
ACLや所有者の変更
接続切断後の再接続
証明書期限切れ後の再取得
条件付きアクセスでブロックされた場合の動作

読み取りと新規アップロードだけ成功しても、上書き、削除、名前変更で権限不足になることがあります。権限テストは実際の業務手順を基準にしてください。

ローカルユーザーを段階的に廃止する

移行時は、短期間だけ旧方式と新方式を並行稼働させると安全です。

Entra ID用の権限と条件付きアクセスを設定する
対象利用者がEntra ID方式で接続する
業務上必要なファイル操作を検証する
監査ログに想定した情報が記録されるか確認する
クライアント設定と手順書を更新する
ローカルユーザーを無効化または削除する
不要になったパスワードや秘密鍵を破棄する

ローカルユーザーを無期限に残すと、MFAや条件付きアクセスを回避できる旧経路が残ります。ロールバック期間を事前に決め、移行完了条件を満たしたら削除してください。

監査と検知はどう変わるか

Microsoft Entra IDアクセスを採用すると、「誰が認証したか」と「Blobデータに何をしたか」を、複数のログから追いやすくなります。ただし、Microsoft Entra IDへ切り替えただけでログが自動保存されるわけではありません。

監査では、次の3種類を組み合わせます。

ログ	確認する内容
Microsoft Entraサインインログ	利用者、サービスプリンシパル、接続元、認証結果、MFA、条件付きアクセス
Azure Blob Storageリソースログ	読み取り、書き込み、削除、対象URI、接続元IP、認可結果
Azure Activity Log	ロール割り当て、ネットワーク、診断設定など管理プレーンの変更

サービスプリンシパルを使う自動処理では、Microsoft Entra管理センターのサービスプリンシパルサインインも確認します。条件付きアクセスを適用している場合は、ポリシーの評価結果も調査できます。(Microsoft Learn)

診断設定がなければStorageBlobLogsは保存されない

Azure Blob Storageのリソースログは自動生成されますが、診断設定で保存先へルーティングするまで収集・保存されません。監査や検知に使う場合は、Blobサービスの次のカテゴリをLog Analyticsワークスペースなどへ送信します。

StorageRead
StorageWrite
StorageDelete

これらのログは、Log AnalyticsではStorageBlobLogsテーブルに格納されます。(Microsoft Learn)

まずは、ストレージアカウントの「ログ」画面から次のようなクエリを実行し、エラーの傾向を確認できます。

StorageBlobLogs
| where TimeGenerated > ago(24h)
| where StatusText !contains "Success"
| summarize Failures = count()
    by OperationName, CallerIpAddress, StatusText
| order by Failures desc

Microsoftの公式ドキュメントでも、StorageBlobLogsを利用してエラーや操作数を集計するクエリ例が示されています。(Microsoft Learn)

最初に作成したい検知ルール

検知対象	主なログ	判断例
サインイン失敗の急増	Entraサインインログ	同じユーザー、アプリ、IPから短時間に複数回失敗
条件付きアクセスによるブロック	Entraサインインログ	想定外の国、端末、接続元からの試行
認可エラーの急増	StorageBlobLogs	特定の操作や接続元で失敗件数が増加
想定外の削除操作	StorageBlobLogs	通常削除しないIDや時間帯からの削除
大量の読み取り・ダウンロード	StorageBlobLogs、メトリック	通常値を大きく上回る読み取りや送信量
サービスプリンシパルの認証失敗	サービスプリンシパルサインイン	証明書やシークレットの期限切れ、ポリシーブロック
権限やネットワークの変更	Azure Activity Log	ロール追加、診断設定削除、パブリックアクセス変更

固定件数だけでアラートを作ると、定期バッチの一時的な失敗でも大量に通知されます。最初の1〜2週間は通常時の件数、時間帯、接続元IP、操作の種類を記録し、その実績を基準にしきい値を決めると運用しやすくなります。

実機ログのフィールドを確認してから検知条件を固定する

Azure Blob Storageのログには、操作名、ステータス、接続元IP、URI、認証方式、認可結果、プリンシパルIDなどを記録できるスキーマがあります。一方、公式スキーマのprotocolフィールドは、例としてHTTP、HTTPS、SMB、NFSを挙げており、SFTPの値は明示されていません。(Microsoft Learn)

そのため、最初からProtocol == "SFTP"のような条件に依存したアラートを作るのは避けたほうが安全です。テスト用のSFTP接続で読み取り、書き込み、削除を実行し、実際に記録されるOperationName、AuthenticationType、ID関連フィールドを確認してから検知ルールを確定してください。

移行時に失敗しやすいポイント

Entra IDのパスワードで直接接続しようとする

Microsoft Entra IDアクセスは、一般的なWebアプリのようにSFTPクライアントへEntraのパスワードを入力する方式ではありません。事前にOpenSSH証明書を取得する必要があります。既存の運用手順や利用者向けマニュアルをそのまま流用すると、接続できません。(Microsoft Learn)

管理ロールだけを割り当てる

Contributorを付与したため接続できるはずだと判断するのは典型的な誤りです。Blobデータへアクセスするには、Storage Blob Data ReaderやStorage Blob Data Contributorなど、データアクセス用ロールが必要です。(Microsoft Learn)

65分の証明書期限を自動処理で考慮しない

証明書を一度取得して固定ファイルとして配布すると、期限切れ後に処理が停止します。バッチ処理では、実行前の証明書取得、期限切れ時の再取得、Entra認証失敗時の再試行、アラート通知を一連の処理として設計してください。

マネージドIDが使えると思い込む

Blob StorageのREST APIやSDKではマネージドIDが推奨される場面がありますが、Microsoft Entra IDを使ったSFTP接続ではマネージドID認可がサポートされていません。Azure VM、Azure Functions、Azure Automationなどで既にマネージドIDを使っている場合でも、SFTP経路へそのまま転用できません。(Microsoft Learn)

自動処理を新規設計する場合は、「SFTPでなければならないか」も確認します。相手側がSFTPを要求していないなら、REST APIやAzure SDKとマネージドIDを使うほうが、資格情報管理を簡素化できる可能性があります。

ホームディレクトリに依存している

Microsoft Entra IDアクセスではホームディレクトリを設定できず、接続文字列にコンテナー名を含めることもできません。接続後はストレージアカウントのルートから対象コンテナーへ移動します。(Microsoft Learn)

既存スクリプトが、接続直後から特定のディレクトリにいることを前提としている場合は、明示的なcd処理を追加してください。

ECDSA鍵を使おうとする

Microsoft Entra IDベースのSFTPアクセスで使用する証明書はRSAのみがサポートされ、ECDSAには対応していません。社内の標準SSH鍵がECDSAの場合は、SFTP接続用にRSA鍵を準備する必要があります。(Microsoft Learn)

WinSCPで接続後に「Access denied」になる

WinSCPでは、ディレクトリ移動時のパス正規化処理により、接続自体は成功してもコンテナーを開く際にAccess deniedとなる場合があります。

公式ドキュメントでは、WinSCPの「Resolve Symbolic Links」を無効にする方法が回避策として案内されています。接続成功後にコンテナーへ移動できない場合は、RBACやACLだけでなくクライアント設定も確認してください。(Microsoft Learn)

Private Endpointを作っただけで安心する

Private Endpointを作成しても、パブリックネットワークアクセスを制限していなければ、パブリックなBlobサービスエンドポイントが引き続き利用できる場合があります。DNSがprivatelink.blob.core.windows.net側を正しく解決しているか、パブリックアクセスが意図どおり制限されているかを確認してください。(Microsoft Learn)

管理者が優先すべき対応

対応の順序は、次のように整理できます。

優先順位	対応内容	完了の判断基準
最優先	SFTP有効アカウントとローカルユーザーを棚卸し	利用者、用途、接続先、資格情報の所有者が分かる
最優先	Blobサービスの診断ログを有効化	StorageBlobLogsで試験操作を確認できる
高	社員1名でEntra ID接続を試行	MFAを含めて必要な操作が成功する
高	取引先1社で外部ID接続を試行	クライアント、権限、運用手順が成立する
高	RBAC・ABAC・ACLを最小権限で再設計	不要なコンテナーやディレクトリへアクセスできない
高	ネットワークアクセスを確認	許可した経路以外から接続できない
中	自動処理をサービスプリンシパルへ移行	証明書更新と障害通知が自動化されている
中	不要なローカルユーザーを削除	旧パスワードやSSH鍵で接続できない
継続	検知ルールと定期棚卸しを運用	認証失敗、認可エラー、異常操作を追跡できる

今回の一般提供に対して、すべての環境を一度に変更する必要はありません。まず、SFTPを有効にしているストレージアカウントを洗い出し、ログを取得できる状態にします。その後、影響の小さい社内利用者を1人選び、Microsoft Entra ID認証、OpenSSH証明書の取得、ファイル操作、監査ログまでを通して確認してください。

その検証結果を基に、社員、取引先、自動処理の順に移行方針を分けます。特に人が使う接続はMicrosoft Entra IDへの移行を優先し、自動処理は65分の証明書期限、マネージドID非対応、再試行設計を確認してから切り替えるのが現実的です。

この記事を書いた人

佐藤健司

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

Azure Blob Storage SFTPのEntra IDアクセスがGA｜影響範囲と管理者対応