Azure Files の SMB 共有をアプリケーションや VM から使っている環境では、ストレージアカウントキーや接続文字列をどこに保管するかが長年の悩みでした。2026年5月15日に公開・更新された公式情報では、「Managed Identity Support for Azure Files SMB」が一般提供（GA）として扱われ、Azure Files の SMB アクセスで Microsoft Entra のマネージド ID を使えるようになりました。結論として、アプリやサービスは静的なキーを持たずに Azure Files へ認証できるため、キー漏えいリスク、ローテーション作業、過剰権限を減らしやすくなります。Azure Updates でも当該項目は Launched / General Availability として掲載されています。(Microsoft Azure)
ただし、これは「スイッチを入れればすぐ安全になる」機能ではありません。実運用では、ストレージアカウント側の SMBOAuth 有効化、マネージド ID への RBAC 付与、クライアント側の認証準備、ACL 設計、既存のストレージアカウントキー依存の洗い出しが必要です。Microsoft Learn では、Windows / Linux VM が Microsoft Entra ID による ID ベース認証で SMB Azure file shares にアクセスでき、GA には AKS Workload Identity 対応、アプリケーション ID とエンドユーザー ID の同一ストレージアカウント上での共存、Azure portal からの有効化簡素化が含まれると説明されています。(Microsoft Learn)
Azure Files SMB のマネージド ID 対応で何が変わるのか
今回の変更の中心は、Azure Files そのものの容量や性能ではなく、SMB 共有にアクセスするアプリケーションの認証方式です。
従来、Azure Files をアプリケーションから SMB マウントする場合、ストレージアカウントキーを使う構成が多くありました。ストレージアカウントキーは扱いやすい一方で、漏えい時の影響範囲が広く、アプリ設定、Kubernetes Secret、CI/CD 変数、運用手順書などに散らばりやすい問題があります。
GA となったマネージド ID 対応では、Azure VM やアプリケーションに割り当てられた Microsoft Entra の ID を使って Azure Files SMB へアクセスできます。Microsoft のマネージド ID の説明では、アプリケーションは資格情報を管理せずに Microsoft Entra トークンを取得でき、アクセスキーやパスワードの代替として利用できるとされています。(Microsoft Learn)
| 確認項目 | 従来よくある構成 | GA 後にできること | 管理上のポイント |
|---|---|---|---|
| 認証情報 | ストレージアカウントキー、接続文字列、SAS などを保管 | マネージド ID で認証 | アプリ設定や Secret にキーを残さない |
| 権限管理 | キーを持つ主体が広い権限を持ちやすい | ID 単位で RBAC を付与 | 共有 ID の使い回しを避ける |
| 対象ワークロード | VM、AKS、CI/CD などでキーを配布 | Windows / Linux VM、AKS などで ID ベースの SMB アクセスを設計 | OS、AKS バージョン、CSI ドライバーを確認 |
| ユーザーとアプリの共存 | ユーザー用とアプリ用でストレージを分けることがある | 同じストレージアカウント上でアプリ ID とエンドユーザー ID を扱える | RBAC と ACL の整合性が重要 |
| 有効化方法 | 手動設定やキー管理が中心 | Azure portal、PowerShell、CLI で SMBOAuth を有効化 | IaC に反映して再現性を確保 |
Microsoft Entra の観点では「人」ではなく「ワークロード ID」の管理が重要になる
Microsoft Entra と聞くと、ユーザーのサインインや条件付きアクセスを思い浮かべる人が多いかもしれません。今回の Azure Files SMB 対応で重要なのは、ユーザー ID だけでなく、アプリケーションや VM、Pod などのワークロード IDをどう管理するかです。
マネージド ID は、人間のアカウントではなく、Azure リソースやアプリケーションに割り当てる ID です。アプリケーションはその ID で認証し、Azure Files へのアクセス権は Azure RBAC やファイル・ディレクトリレベルの権限で制御します。
実務では、次のように考えると整理しやすくなります。
| 対象 | ID 設計の例 | 注意点 |
|---|---|---|
| 単一 VM 上の業務アプリ | VM のシステム割り当てマネージド ID | VM 削除と同時に ID も消えるため、復旧設計に注意 |
| 複数 VM で同じ役割のアプリ | ユーザー割り当てマネージド ID | 複数リソースで共有できる分、権限範囲を広げすぎない |
| AKS のステートフルアプリ | Workload Identity と ServiceAccount の組み合わせ | Pod 単位の分離、AKS バージョン、プレビュー表記の確認が必要 |
| 管理者のメンテナンス作業 | エンドユーザー ID と Azure Files の RBAC / ACL | アプリ ID と人の権限を同じものとして扱わない |
Microsoft Learn では、システム割り当てマネージド ID はリソースのライフサイクルに紐づき、ユーザー割り当てマネージド ID は独立した Azure リソースとして作成され、複数リソースに割り当てられると説明されています。Azure Files の手順では、1 台の VM に両方を構成できるものの、最適な結果のためにはどちらか一方を使うことが推奨されています。(Microsoft Learn)
対象範囲：どの環境に影響するか
今回の更新で特に影響が大きいのは、Azure Files の SMB 共有をアプリケーションのファイル置き場として使っている環境です。たとえば、以下のようなケースでは優先的に確認する価値があります。
- Azure VM 上のアプリが Azure Files をドライブまたはパスとしてマウントしている
- AKS の Pod が Azure Files を永続ボリュームとして使っている
- WordPress、CMS、社内アプリ、バッチ処理、CI/CD パイプラインなどで共有ファイル領域が必要
- ストレージアカウントキーを App Service 設定、VM 上の設定ファイル、Kubernetes Secret、DevOps 変数などに保管している
- セキュリティ監査で「共有キーの使用」「キーのローテーション」「資格情報の保管場所」が課題になっている
一方で、今回の更新は Azure Files の SMB アクセスに関するものです。Azure Files の ID ベース認証の概要では、SMB では ID ベース認証を利用できる一方、NFS ファイル共有では現在 ID ベース認証をサポートしていないと説明されています。NFS ワークロードは、ネットワーク制御や別の認証・認可設計を前提に確認してください。(Microsoft Learn)
また、公式ブログ系の説明では、HDD と SSD の SMB 共有、各種課金モデルで利用できるとされています。ただし、リージョン、クライアント OS、AKS、CSI ドライバーなどのサポート状態は環境によって変わる可能性があるため、本番展開前に利用中の構成で公式ドキュメントを確認してください。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が確認すべき設定
ストレージアカウントで Managed Identity for SMB を有効化する
マネージド ID で SMB アクセスを行うには、対象のストレージアカウントで SMBOAuth プロパティを有効化します。Microsoft Learn では、新規ストレージアカウントでは Azure portal の Advanced タブで「Enable Managed Identity for SMB」を選択でき、既存アカウントでは Settings > Configuration の「Managed Identity for SMB」を Enabled にして保存できると説明されています。(Microsoft Learn)
Azure CLI で既存のストレージアカウントに対して有効化する例は次のとおりです。
az storage account update \
--resource-group <resource-group-name> \
--name <storage-account-name> \
--enable-smb-oauth truePowerShell では次のように設定できます。
Set-AzStorageAccount `
-ResourceGroupName "<resource-group-name>" `
-Name "<storage-account-name>" `
-EnableSmbOAuth $true新規構築なら、既存のキー依存を引きずらないように、マネージド ID 前提のストレージアカウントを分けて作る方が設計しやすい場合があります。既存アカウントに追加する場合は、既存のユーザーアクセス、バックアップ、運用ツール、ポータル操作、スクリプトがストレージアカウントキーに依存していないかを先に確認してください。
マネージド ID に適切な RBAC ロールを割り当てる
マネージド ID を有効化しただけでは、Azure Files へのアクセスは許可されません。Azure Files SMB のマネージド ID アクセスでは、対象のマネージド ID またはアプリケーション ID に Azure RBAC を付与します。
Microsoft Learn の手順では、Storage File Data SMB MI Admin ロールを対象 ID に割り当てる説明があります。このロールは、Azure Files のファイルやディレクトリに対してマネージド ID 用の管理者レベルのアクセスを与えるロールとして説明されています。(Microsoft Learn)
CLI の例は次のとおりです。
az role assignment create \
--role "Storage File Data SMB MI Admin" \
--assignee <managed-identity-client-id-or-object-id> \
--scope <storage-account-resource-id>注意したいのは、ロール名に「Admin」が含まれる点です。便利だからといって、複数アプリで同じユーザー割り当てマネージド ID を使い回すと、あるアプリの侵害が他の共有ファイル領域に波及する可能性があります。原則として、アプリケーション単位、環境単位、本番・検証単位で ID を分け、必要なスコープにだけ割り当てます。
共有レベルの権限と ACL を混同しない
Azure Files のアクセス制御では、Azure RBAC だけで完結するわけではありません。共有レベルの権限と、ディレクトリ・ファイルレベルの Windows ACL、いわゆる NTFS 権限の両方を考える必要があります。
Microsoft Learn では、共有レベルの RBAC は「高レベルのゲートキーパー」として機能し、Windows ACL はディレクトリやファイル単位の細かな操作を制御すると説明されています。両者に差がある場合、より制限の強い権限が適用されます。(Microsoft Learn)
たとえば、アプリ ID に共有レベルで書き込み権限があっても、対象フォルダーの ACL が読み取りのみであれば、実際には書き込みできません。逆に、ACL で書き込みを許可していても、共有レベルで読み取りしか許可されていなければ、書き込みはできません。
本番展開前には、最低でも次の権限表を作っておくとトラブルを減らせます。
| 対象 | 共有レベルの権限 | フォルダー / ファイル ACL | 確認方法 |
|---|---|---|---|
| アプリケーション ID | 必要なロールのみ | アプリが書き込むパスだけ許可 | テストデータの作成、更新、削除 |
| 運用管理者 | 管理作業に必要な範囲 | 管理対象フォルダーのみ | 障害対応手順で検証 |
| 開発者 | 原則、本番は読み取りまたはなし | デバッグ用領域に限定 | 一時的な昇格手順を用意 |
| CI/CD | デプロイに必要なパスのみ | 成果物配置先のみ | パイプライン実行で確認 |
共有レベルの既定権限をストレージアカウントに設定することもできますが、これはストレージアカウント内のファイル共有に広く影響します。Microsoft Learn でも、既定の共有レベル権限は初期値が None であり、すべての認証済みユーザーやグループに同じ権限を与える構成になり得ると説明されています。安易に広い既定権限を設定するのは避けるべきです。(Microsoft Learn)
クライアント側の認証準備を行う
Windows と Linux では、マネージド ID を使った SMB マウントの準備手順が異なります。Microsoft Learn では、対象クライアントはドメイン参加していないことが前提として説明されています。Windows 側では AzFilesSmbMIClient PowerShell モジュールを使い、Linux 側では azfilesauth 関連のパッケージを使って認証情報を準備します。(Microsoft Learn)
Windows の例です。
Install-Module AzFilesSmbMIClient
Import-Module AzFilesSmbMIClient
AzFilesSmbMIClient.exe refresh --uri https://<storage-account-name>.file.core.windows.net/ユーザー割り当てマネージド ID を使う場合は、クライアント ID を指定します。
AzFilesSmbMIClient.exe refresh `
--uri https://<storage-account-name>.file.core.windows.net/ `
--clientId <client-id>Linux の例です。
sudo azfilesauthmanager set https://<storage-account-name>.file.core.windows.net --system
sudo azfilesauthmanager listユーザー割り当てマネージド ID の場合は、クライアント ID を指定します。
sudo azfilesauthmanager set \
https://<storage-account-name>.file.core.windows.net \
--imds-client-id <client-id>Linux では、マウント後の認証情報更新も重要です。Microsoft Learn では、初回マウント後に azfilesrefresh サービスを開始し、起動時にも自動実行する手順が示されています。これを忘れると、検証時は成功しても、再起動後や一定時間後にアクセスが失敗する可能性があります。(Microsoft Learn)
sudo systemctl enable --now azfilesrefreshSMB のネットワーク要件も確認する
マネージド ID によって認証は改善されますが、SMB 接続のネットワーク要件は消えません。Azure Files の SMB は TCP 445 番ポートを使用します。Microsoft Learn では、多くの組織や ISP がアウトバウンドの 445 番ポートをブロックすることがあり、Azure 外部から直接マウントする場合は VPN や ExpressRoute、Private Endpoint などの設計が必要になる場合があると説明されています。(Microsoft Learn)
特にオンプレミス、別クラウド、リモートワーク端末から接続する場合は、認証設定より先にネットワーク到達性を確認してください。
AKS で使う場合の注意点
AKS で Azure Files を永続ボリュームとして使っている場合、今回の更新は大きな意味があります。ストレージアカウントキーを Kubernetes Secret に入れて配布する構成から、Workload Identity を使った ID ベースアクセスへ移行できる可能性があるためです。
ただし、ここは慎重に確認すべきポイントです。Azure Files 側の GA 更新では AKS Workload Identity 対応が含まれるとされていますが、AKS のドキュメントでは、Azure Files への Workload Identity ベース認証について、AKS 1.35.0 以降の Linux ノードでプレビューとして利用可能という記載があります。(Microsoft Learn)
そのため、本番採用前には次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| AKS バージョン | Workload Identity 対応に必要なバージョンを満たしているか |
| ノード OS | Linux ノード前提の記載があるため、Windows ノード利用時は要確認 |
| CSI ドライバー | Azure Files CSI driver のバージョンと機能対応 |
| ServiceAccount | Pod が使用する Kubernetes ServiceAccount が正しく定義されているか |
| Federated Identity Credential | Microsoft Entra のマネージド ID と ServiceAccount の対応付けができているか |
| RBAC | 対象マネージド ID に Storage File Data SMB MI Admin など必要な権限があるか |
| 本番利用可否 | プレビュー表記がある機能を自社の本番ポリシーで使えるか |
AKS では、ノード単位の ID よりも Pod 単位の ID 分離が重要です。複数アプリが同じノードで動くため、ノードの ID に広い権限を与えると、最小権限の原則から外れやすくなります。特に金融、医療、個人情報を扱う業務では、Pod 単位でアクセス先ファイル共有を分ける設計を優先してください。
移行時の実務手順
既存環境をいきなり切り替えるのは危険です。まずは、ストレージアカウントキーをどこで使っているかを洗い出し、段階的にマネージド ID へ寄せるのが現実的です。
| フェーズ | 作業内容 | 失敗しやすいポイント |
|---|---|---|
| 現状調査 | App Settings、VM 設定ファイル、Kubernetes Secret、CI/CD 変数、手順書を確認 | 古いスクリプトや一時運用でキーが残っている |
| 対象選定 | 影響の小さいファイル共有や検証環境を選ぶ | 本番共有から始めて切り戻しが難しくなる |
| ID 設計 | アプリごとにシステム割り当て / ユーザー割り当てを決める | 便利な共有 ID に権限を集めすぎる |
| ストレージ設定 | SMBOAuth を有効化する | 既存ツールがキー前提で動かなくなる |
| RBAC / ACL 設計 | マネージド ID に必要なロール、フォルダー ACL を設定 | 共有レベルと ACL の不一致でアクセス不可 |
| クライアント設定 | Windows / Linux / AKS の認証準備を行う | トークン更新サービスや起動時マウントを忘れる |
| 動作確認 | 読み取り、書き込み、削除、再起動後、スケールアウト時を確認 | 初回マウントだけ成功して長期運用で失敗 |
| キー削減 | アプリ設定からキーを削除し、必要に応じてキーをローテーション | 残存するキー依存ワークロードを見落とす |
移行後は、ストレージアカウントキーをすぐ無効化するのではなく、依存関係を確認してから段階的に進めます。Microsoft の Azure Storage ドキュメントでは、Shared Key authorization を無効化すると、正しい RBAC がない場合に Azure Files への要求が失敗したり、ポータルでファイル共有にアクセスできなくなる可能性があるため、移行や RBAC 設定を事前に行う必要があると説明されています。(Microsoft Learn)
開発者が確認すべきポイント
開発者にとって重要なのは、アプリケーションコードを大きく書き換える必要があるかどうかです。Azure Files は SMB を通じてネイティブなファイルシステム API を提供するため、アプリがマウント済みパスを通常のファイルとして扱っている場合、アプリ側のファイル I/O ロジックは大きく変えずに済むことがあります。(Microsoft Learn)
ただし、認証とマウントはアプリ起動前に完了している必要があります。次のような観点でアプリ側も見直してください。
| 確認項目 | 対応例 |
|---|---|
| 起動順序 | SMB マウント完了後にアプリを起動する |
| ヘルスチェック | 共有パスへの読み取り・書き込み確認を含める |
| エラー処理 | ファイル共有未接続時にアプリ全体が落ちないようにする |
| ログ | 認証失敗、マウント失敗、権限エラーを区別して記録する |
| 設定値 | ストレージアカウントキーや接続文字列を削除する |
| CI/CD | デプロイパイプラインでキーを注入していないか確認する |
特にコンテナー環境では、「Pod は起動したが Azure Files はマウントできていない」という状態が起きると、アプリの初期化処理やログ出力で障害が連鎖します。Readiness Probe や起動時チェックで、共有ディレクトリの存在確認だけでなく、必要であればテストファイルの作成・削除まで確認するのが実務的です。
よくある失敗と対処法
| 症状 | 主な原因 | 対処 |
|---|---|---|
SMBOAuth を有効にしたのにアクセスできない | マネージド ID に RBAC ロールがない、または反映待ち | ロール割り当てのスコープと対象 ID を確認し、反映後に再試行 |
| Windows VM で意図しない ID が使われる | システム割り当てとユーザー割り当ての両方がある | どちらか一方に整理する |
| Linux で再起動後にアクセスできない | 認証情報更新サービスが起動していない | azfilesrefresh を enable する |
| アプリが広すぎる権限を持つ | 共有マネージド ID を複数アプリで使い回している | アプリ単位・環境単位で ID を分ける |
| ACL を設定したのに書き込めない | 共有レベル RBAC の方が制限されている | RBAC と ACL の両方を確認する |
| Shared Key を無効化したらポータルやツールで失敗する | 既存の操作がキー認証に依存している | 無効化前に RBAC、運用ツール、バックアップを検証する |
| AKS で PV がマウントできない | Workload Identity、ServiceAccount、Federated Credential、CSI 設定の不一致 | AKS バージョン、マニフェスト、マネージド ID の関連付けを確認 |
| オンプレミスから接続できない | TCP 445 がブロックされている | VPN、ExpressRoute、Private Endpoint、Azure File Sync を検討 |
すぐ導入すべき環境、慎重に進めるべき環境
優先的に導入を検討したい環境
以下に当てはまる場合は、早めに検証環境で試す価値があります。
- ストレージアカウントキーをアプリ設定や Secret に保存している
- キーの棚卸しやローテーションが運用負荷になっている
- 複数の VM や Pod から同じ Azure Files SMB 共有にアクセスしている
- セキュリティ監査で最小権限や資格情報管理が課題になっている
- アプリケーション ID と管理者・開発者のユーザーアクセスを同じ共有上で整理したい
- AKS で Azure Files を永続ボリュームとして使っている
慎重に進めるべき環境
一方、次の環境では、先に設計確認が必要です。
- 既存の運用ツールやバックアップがストレージアカウントキー前提で動いている
- NFS 共有を使っている
- レガシー OS や古い SMB クライアントが残っている
- オンプレミスから TCP 445 の接続ができない
- AKS の Workload Identity 機能を本番で使えるか、社内ポリシー上の確認が必要
- ファイル共有内の ACL が複雑で、誰がどこにアクセスできるか把握できていない
この機能は、既存のアクセス制御の混乱を自動で直すものではありません。むしろ、マネージド ID に移行するタイミングで、不要な共有キー、広すぎる RBAC、古い ACL、使われていないマウント設定を整理することに価値があります。
まとめ：まずはキー依存の棚卸しから始める
Azure Files SMB のマネージド ID 対応 GA は、Microsoft Entra を使ったワークロード認証を Azure Files の実運用に広げる重要な更新です。アプリケーションや VM、AKS がストレージアカウントキーを持たずに SMB 共有へアクセスできるため、Zero Trust や最小権限の考え方に沿った構成へ移行しやすくなります。
次に取るべき行動は明確です。まず、Azure Files を使っているアプリ、VM、AKS、CI/CD、運用スクリプトを棚卸しし、ストレージアカウントキーを使っている箇所を一覧化してください。そのうえで、影響の小さいファイル共有を選び、SMBOAuth の有効化、マネージド ID の作成、RBAC 付与、クライアント設定、ACL 検証を小さく試します。
本番移行では、キーの削除や Shared Key の無効化を最後に行うのが安全です。認証方式を変えるだけでなく、どのアプリが、どの ID で、どの共有の、どのフォルダーにアクセスできるのかを文書化しておくことで、今回の GA を単なる新機能対応ではなく、Azure Files 全体のセキュリティ改善につなげられます。
コメント