Azure Blob Storage SFTPのMicrosoft Entra IDベースアクセスは、2026年7月7日時点で全リージョンの一般提供（GA）に到達しました。結論からいえば、既存のSFTP接続が突然使えなくなる更新ではありません。一方、従業員や取引先に長期間有効なパスワードやSSH鍵を配布している組織は、Microsoft Entra ID方式への移行を優先的に検討すべきです。(マイクロソフトAzure)
Microsoft Entra ID方式では、ユーザー、グループ、サービスプリンシパル、外部ゲストを既存のID管理に組み込み、Azure RBAC、ABAC、ACLでSFTP経由のBlobアクセスを制御できます。ただし、短時間有効なOpenSSH証明書への対応、権限設計の見直し、監査ログの有効化が必要です。この記事では、影響範囲、管理者が行う設定、監査・検知への影響、対応の優先順位を整理します。
Azure Blob Storage SFTP / Microsoft Entra IDのGAとは
Azure Blob Storageは、ストレージアカウントに対してネイティブなSFTPエンドポイントを提供しています。これまでは、ストレージアカウント内に作成する「ローカルユーザー」と、パスワードまたはSSH公開鍵を組み合わせる方式が中心でした。
今回一般提供されたMicrosoft Entra IDベースアクセスでは、次の流れで接続します。
- Azure CLI、Azure PowerShell、SDKなどでMicrosoft Entra IDに認証する
- RSA公開鍵を渡し、OpenSSH証明書を取得する
- 秘密鍵とOpenSSH証明書を使い、対応するSFTPクライアントから接続する
OpenSSH証明書の有効期間は65分です。SFTPクライアントにMicrosoft Entra IDのパスワードを直接入力する方式ではなく、先にMicrosoft Entra IDへ認証して短時間有効な証明書を取得する仕組みです。(Microsoft Learn)
従来方式との違い
| 項目 | ローカルユーザー方式 | Microsoft Entra ID方式 |
|---|---|---|
| IDの管理場所 | ストレージアカウントごと | Microsoft Entra IDで一元管理 |
| 認証方法 | パスワードまたはSSH鍵 | Entra ID認証後に取得するOpenSSH証明書と秘密鍵 |
| 証明情報の有効期間 | 管理者が更新するまで利用されることが多い | OpenSSH証明書は65分 |
| 利用できる主体 | ストレージアカウントのローカルユーザー | ユーザー、グループ、サービスプリンシパル、外部ゲスト |
| アクセス制御 | ローカルユーザー権限とACL | Azure RBAC、ABAC、ACL |
| 多要素認証 | パスワードと鍵を組み合わせるMFAは非対応 | Entra IDへのサインイン段階でMFAを利用可能 |
| クライアント要件 | 一般的なSFTPクライアント | OpenSSH証明書に対応したクライアント |
| ID削除時の対応 | ストレージアカウントごとに削除 | Entra IDのユーザーやグループから一元的に解除可能 |
従来のローカルユーザー方式も、引き続き公式ドキュメントで利用可能な認証方式として案内されています。今回のGAは、既存環境を自動的に移行する変更ではなく、Microsoft Entra ID方式を本番利用できる選択肢として追加するものです。(Microsoft Learn)
何が保護され、何は変わらないのか
Microsoft Entra IDベースアクセスで強化されるのは、主にSFTP経由でBlobデータへアクセスする際の「誰が」「何をできるか」という部分です。
| 対象 | 今回のGAによる影響 |
|---|---|
| SFTP利用者の本人確認 | Entra IDのユーザーやサービスプリンシパルで管理可能 |
| コンテナーやデータへの権限 | Azure RBAC、ABAC、ACLを利用可能 |
| 従業員の異動・退職 | グループやアカウントの変更をアクセス権に反映しやすい |
| 取引先のアクセス | Microsoft Entra External IDのゲストを利用可能 |
| バッチ処理 | サービスプリンシパルを利用可能 |
| ネットワーク公開範囲 | 自動では変更されない |
| ストレージアカウントの管理権限 | Blobデータへの権限とは別に管理が必要 |
| 既存ローカルユーザー | 自動削除・自動移行されない |
| REST APIやAzCopyなどの接続 | SFTPとは別の接続方式として引き続き利用可能 |
ID認証を導入してもネットワーク制限は必要
Microsoft Entra ID認証に切り替えても、SFTPエンドポイントのネットワーク公開範囲が自動的に狭まるわけではありません。必要に応じて、ストレージファイアウォール、仮想ネットワーク、プライベートエンドポイントなどで接続元を制限します。
Azure Blob StorageのSFTPはプラットフォームレベルのサービスであるため、SFTPを有効にしていないストレージアカウントでもポート22が応答する場合があります。未構成の場合は接続が切断されるため、ポートスキャンの結果だけでSFTPの有効・無効を判断するのは適切ではありません。Azureの構成情報を基に棚卸ししてください。(Microsoft Learn)
管理プレーンのロールだけではデータにアクセスできない
Azureの「所有者」「共同作成者」「閲覧者」「ストレージアカウント共同作成者」と、Blobデータ用のロールは別物です。
管理プレーンのロールだけを割り当てても、原則としてBlobデータへの読み書き権限は付与されません。SFTPでデータへアクセスさせるには、Storage Blob Data Readerなどのデータ用ロール、またはACLが必要です。
ただし、一部の管理ロールはストレージアカウントキーを取得できるため、データ用ロールだけでなく、キーへアクセスできる管理者の範囲も確認する必要があります。(Microsoft Learn)
自社に対応が必要か判断する基準
| 利用状況 | 優先度 | 判断 |
|---|---|---|
| Azure Blob StorageのSFTPを使用していない | 低 | 直ちに対応する必要はない |
| 従業員にローカルユーザーを発行している | 高 | Entra IDのユーザー・グループへの移行を検討 |
| 取引先ごとにパスワードやSSH鍵を発行している | 高 | 外部ゲストとグループによる管理を検討 |
| 長期利用のSSH秘密鍵でバッチ接続している | 高 | サービスプリンシパルと短時間証明書による接続を検証 |
| マネージドIDで接続したい | 要調査 | 現時点ではSFTPのEntra ID認証でマネージドIDは非対応 |
| SFTPクライアントを長期間更新していない | 高 | OpenSSH証明書への対応状況を確認 |
| ホームディレクトリ前提の接続設定がある | 高 | Entra ID方式ではホームディレクトリが非対応のため修正が必要 |
| 監査ログを保存していない | 高 | 移行前に診断設定を有効化 |
| プレビュー版を検証済み | 中～高 | GA版として権限、クライアント、ログを再テスト |
特に注意したいのは、無人バッチ処理です。サービスプリンシパルは利用できますが、マネージドIDは現時点で対応していません。また、Microsoft Entra ID方式はRSA証明書のみをサポートし、ECDSA証明書、ホームディレクトリ、接続文字列へのコンテナー名の追加には対応していません。(Microsoft Learn)
管理者が行う設定と移行手順
SFTP利用環境を棚卸しする
最初に、ストレージアカウントではなく「接続処理」を単位として棚卸しします。同じストレージアカウントでも、従業員、取引先、夜間バッチで移行方法が異なるためです。
最低限、次の項目を整理してください。
- SFTPを有効にしているストレージアカウント
- ローカルユーザー名と利用者
- パスワードまたはSSH鍵の利用状況
- 人が操作する接続か、無人バッチか
- 使用しているSFTPクライアントとバージョン
- 接続元IPアドレスやネットワーク
- アクセス対象のコンテナー、ディレクトリ、ファイル
- 必要な操作が読み取り、書き込み、削除のどこまでか
- 接続時間帯と証明書更新の方法
- 診断ログの保存先と保持期間
SFTPを利用するストレージアカウントには、階層型名前空間が必要です。また、一般用途v2またはPremiumブロックBlobアカウントなど、SFTPの前提条件を満たしている必要があります。(Microsoft Learn)
利用者ごとにEntra IDの主体を決める
| 利用者 | 推奨する主体 | 設計のポイント |
|---|---|---|
| 社内の担当者 | Entra IDセキュリティグループ | 個人へ直接権限を付与しない |
| 複数部署の利用者 | 用途別セキュリティグループ | 読み取り用と書き込み用を分ける |
| 取引先担当者 | 外部ゲストとセキュリティグループ | 契約終了時にゲストとグループ所属を見直す |
| 無人バッチ | サービスプリンシパル | 証明書取得処理と再接続処理を自動化する |
| Azure上のワークロード | サービスプリンシパルなど | マネージドID非対応を前提に設計する |
ACLには個人ユーザーを直接登録するのではなく、Microsoft Entra IDのセキュリティグループを登録する方法が推奨されています。グループを利用すれば、異動や退職時にディレクトリ階層全体のACLを書き換えず、グループのメンバー変更で対応できます。(Microsoft Learn)
Azure RBACとACLを最小権限で設計する
代表的なBlobデータ用ロールは次のとおりです。
| ロール | 主な権限 | 推奨する利用者 |
|---|---|---|
| Storage Blob Data Reader | 読み取り、一覧表示 | 参照専用の利用者 |
| Storage Blob Data Contributor | 読み取り、書き込み、削除 | ファイルを送受信する利用者 |
| Storage Blob Data Owner | 全データ操作、所有者変更、ACL変更 | データ管理者に限定 |
Storage Blob Data Ownerを一般利用者へ付与すると、ファイル操作だけでなく、所有者やACLの変更まで可能になります。通常のファイル送受信であれば、最初からOwnerを付与せず、ReaderまたはContributorから検討します。(Microsoft Learn)
ACLで広すぎるRBAC権限を狭めることはできない
権限設計で最も失敗しやすいのが、ストレージアカウント全体にStorage Blob Data Contributorを付与した後、ACLで特定ディレクトリだけに制限しようとする設計です。
Azure Storageでは、最初にAzure RBACとABACが評価され、そこでアクセスが許可されるとACLは評価されません。そのため、RBACで付与済みの権限をACLで拒否することはできません。
ディレクトリ単位で分離する場合は、次のいずれかを採用します。
- 上位スコープのRBACを付けず、ACLで必要なディレクトリだけを許可する
- コンテナースコープなど、可能な限り狭い範囲でRBACを割り当てる
- ABACの条件を利用し、属性に基づいて対象を絞る
- 読み取り用と書き込み用のグループを分ける
「広いRBAC権限を付与し、ACLで制限する」という考え方は避けてください。(Microsoft Learn)
OpenSSH証明書による接続をテストする
Azure CLIを利用する場合の基本的な流れは次のとおりです。
ssh-keygen -t rsa
az login
az sftp cert \
--public-key-file ~/.ssh/id_rsa.pub \
--file ~/.ssh/my_cert.pub取得した証明書と秘密鍵を使って接続します。
sftp \
-o PubkeyAcceptedKeyTypes="[email protected],rsa-sha2-256" \
-o IdentityFile="~/.ssh/id_rsa" \
-o CertificateFile="~/.ssh/my_cert.pub" \
<storage-account>.<user-name>@<storage-account>.blob.core.windows.netOpenSSH証明書は65分で期限切れになります。バッチ処理では、証明書ファイルを長期間使い回すのではなく、処理開始前や再接続前に新しい証明書を取得する設計が必要です。(Microsoft Learn)
接続テストでは、次の点も確認してください。
- Entra IDのUPNが
[email protected]の場合、接続ユーザー名ではドメイン部分を除く - サービスプリンシパルでは、ユーザー名の代わりにサービスプリンシパルIDを使う
- 接続文字列へコンテナー名を直接含めない
- 接続後に
cdで対象コンテナーへ移動する - ホームディレクトリを前提にしない
- WinSCPを利用する場合は、OpenSSH証明書対応バージョンを使用する
Microsoftのドキュメントでは、WinSCPのOpenSSH証明書対応はバージョン6.0以降と案内されています。古いクライアントや組み込み製品では対応していない可能性があるため、本番移行前の接続試験が欠かせません。(Microsoft Learn)
小さな範囲で移行してからローカルユーザーを廃止する
最初から全接続を切り替えるのではなく、重要度の低いコンテナーや一つの取引先を対象に試行します。
試行時には、少なくとも次の操作を確認します。
- コンテナーとディレクトリの一覧表示
- ファイルのダウンロード
- ファイルのアップロードと上書き
- ファイル名の変更
- ファイルの削除
- 権限がないディレクトリへのアクセス拒否
- 証明書失効後の再取得と再接続
- 想定外のIPアドレスからの接続拒否
- ログへのユーザー、IPアドレス、操作対象の記録
移行完了後は、不要になったローカルユーザーを削除し、配布済みのパスワードやSSH秘密鍵を回収・廃棄します。ローカルユーザーを残したままでは、Entra IDへ移行しても旧経路が認証手段として残るためです。
監査・検知への影響
Microsoft Entra ID方式へ移行すると、BlobアクセスログでRequesterObjectId、RequesterTenantId、RequesterUpn、RequesterAppIdなどの情報を利用しやすくなります。これにより、単なる接続元IPアドレスだけでなく、どのEntra IDユーザーやアプリケーションが操作したかを追跡できます。(Microsoft Learn)
ただし、Azure Storageのリソースログは自動的に長期保存されるわけではありません。ログを検索・保持するには、Blobサービスに診断設定を作成し、Log Analyticsワークスペース、Event Hubs、ストレージアカウントなどへ送信する必要があります。一般的にはStorageRead、StorageWrite、StorageDeleteを対象にします。(Microsoft Learn)
最初に実際のログ値を確認する
ProtocolやAuthenticationTypeに記録される値を推測してアラートを作るのではなく、試行接続後に実際の値を確認します。
StorageBlobLogs
| where TimeGenerated > ago(24h)
| summarize Requests = count()
by Protocol, AuthenticationType, Category
| order by Requests desc確認できた値を基に、SFTPかつMicrosoft Entra ID経由の操作だけを抽出する条件を作成します。
Entra ID主体による操作を確認する
StorageBlobLogs
| where TimeGenerated > ago(24h)
| where isnotempty(RequesterObjectId)
| project
TimeGenerated,
AccountName,
Category,
OperationName,
StatusCode,
StatusText,
CallerIpAddress,
RequesterUpn,
RequesterObjectId,
RequesterAppId,
RequesterTenantId,
ObjectKey,
Uri
| order by TimeGenerated descRequesterObjectIdが記録されていれば、同姓同名やUPN変更の影響を受けにくいオブジェクトIDを軸に調査できます。
失敗が集中しているIDやIPを検知する
StorageBlobLogs
| where TimeGenerated > ago(1h)
| where isnotempty(RequesterObjectId)
| where StatusCode !startswith "2"
| summarize
Attempts = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by AccountName,
RequesterObjectId,
RequesterUpn,
CallerIpAddress,
OperationName,
StatusCode,
StatusText
| where Attempts >= 5
| order by Attempts desc実運用では、次の事象を優先して検知します。
- 同じユーザーやサービスプリンシパルによる認証・認可エラーの急増
- 通常と異なるIPアドレスからの書き込みや削除
- 想定していないテナントIDによるアクセス
- 取引先の契約終了後に残っているアクセス
- 夜間バッチ以外の時間帯に行われた大量操作
- 移行期限後も残っている旧認証方式の利用
- 短時間に大量の削除や上書きが行われた操作
なお、Azure Storageの要求ログはベストエフォートで記録されます。ログだけを唯一の証跡と考えず、Entra IDのサインイン情報、Azureの構成変更履歴、業務システム側の転送記録も合わせて確認できる運用にします。(Microsoft Learn)
移行で失敗しやすいポイント
| 失敗例 | 問題 | 対応 |
|---|---|---|
| GAになったため自動移行されると思う | ローカルユーザーはそのまま残る | 接続単位で明示的に移行する |
| アカウント全体へContributorを付与する | 不要なコンテナーにも書き込み・削除できる | スコープを狭め、必要に応じてACLを使う |
| RBACをACLで拒否できると思う | RBACで許可されるとACLは評価されない | 上位のRBAC付与を見直す |
| バッチでマネージドIDを使おうとする | 現時点では非対応 | サービスプリンシパルを検討する |
| 証明書を固定ファイルとして保存する | 65分後に新規処理や再接続が失敗する | 処理前に証明書を再取得する |
| ECDSA鍵を使用する | Entra ID方式はRSA証明書のみ対応 | RSA鍵を用意する |
| 古いSFTPクライアントを使う | OpenSSH証明書に対応していない | 対応バージョンへ更新する |
| ホームディレクトリを設定する | Entra ID方式では非対応 | 接続後に対象コンテナーへ移動する |
| Entra ID認証だけで安全になったと考える | ネットワークの公開範囲は変わらない | ファイアウォールやプライベートエンドポイントを併用する |
| 移行後もローカルユーザーを残す | 旧パスワードやSSH鍵で接続できる | 検証後に不要なローカルユーザーを削除する |
| 診断設定を後回しにする | 移行時の失敗原因や不正操作を追跡できない | 試行開始前にログを有効化する |
管理者が優先すべき対応
今回のGAは、緊急のサービス停止に対応する更新ではありません。しかし、SFTPの資格情報を個別管理している組織にとっては、ID管理と監査を改善する重要な機会です。
優先順位は次のように整理できます。
最初に行うこと
- SFTPを有効にしているストレージアカウントを洗い出す
- ローカルユーザー、SSH鍵、パスワードの利用者を確認する
- Blobサービスの診断設定を有効にする
- 人の接続と無人バッチを分ける
- Microsoft Entra IDへ移行できないクライアントを特定する
次に行うこと
- 社内利用者と取引先をEntra IDセキュリティグループへ整理する
- バッチ処理用のサービスプリンシパルを設計する
- Reader、Contributor、Ownerの割り当てを最小化する
- RBAC、ABAC、ACLの評価順序を踏まえて権限を設計する
- 65分の証明書有効期間を前提に再取得処理を組み込む
本番切り替え時に行うこと
- 一部の接続から段階的に移行する
- 読み取り、書き込み、削除、拒否動作を検証する
- ログとアラートの実値を確認する
- 問題がなければ不要なローカルユーザーを削除する
- 取引先、グループ、サービスプリンシパルを定期的に棚卸しする
Azure Blob Storage SFTPを利用している場合、まず実施すべきなのは「すぐに全接続を変更すること」ではなく、ローカルユーザーと接続処理の棚卸しです。そのうえで、監査ログを確保し、一つの接続からMicrosoft Entra ID方式を試行してください。権限、クライアント、証明書更新、ネットワーク制限まで確認できれば、安全に本番移行を進められます。
コメント