Azure FilesでSMBとNFSを安全に使うなら、これからは「ストレージアカウント全体で暗号化を一括制御する」発想だけでは不十分です。2026年4月14日時点の更新では、Azure FilesのSMBとNFSに対して、転送中暗号化をプロトコル別に制御できるようになりました。結論として、標準構成ではSMB/NFSとも暗号化を要求し、例外が必要なレガシー接続だけを別ストレージアカウントに分離して扱うのが現実的です。この記事では、Azure FilesのSMB/NFSハードニングを、過剰にすべてを暗号化するだけの設計ではなく、業務影響とセキュリティ要件を両立する実務ガイドとして整理します。
Azure FilesのSMB/NFS転送中暗号化は何が変わったのか
MicrosoftのAzure Updatesでは、Azure FilesがSMBとNFSの転送中暗号化設定をストレージアカウントレベルで個別に構成できるようになったことが、一般提供として案内されています。これにより、SMBには暗号化を必須にし、NFSは移行期間だけ柔軟に扱う、といったプロトコル別のセキュリティポリシーを組みやすくなりました。(マイクロソフトAzure)
重要なのは、「暗号化を有効にするかどうか」だけではありません。今回の更新で見るべきポイントは、Azure Filesのセキュリティ設計を次のように切り分けられるようになったことです。
| 設計対象 | これまで起きやすかった課題 | 今回の更新後に取りやすい設計 |
|---|---|---|
| SMB | 古いクライアント対応のために全体設定を緩めがち | SMBだけ転送中暗号化を要求し、SMBバージョンや認証方式も合わせて強化する |
| NFS | TLS対応クライアントと非対応クライアントが混在しやすい | NFSだけ段階的に暗号化を要求し、AZNFS導入状況に合わせて移行する |
| REST/API | ファイル共有のSMB/NFS設定と混同しやすい | Secure transfer requiredはREST/HTTPSの制御として別に管理する |
| レガシー接続 | 例外のために全体のセキュリティを下げがち | 例外ワークロードを別ストレージアカウントに隔離する |
Azure Filesでは、1つのファイル共有でSMBとNFSの両方を同時にサポートすることはできません。ただし、同じストレージアカウント内にSMB共有とNFS共有を作成することは可能です。プロトコル別制御の価値は、まさにこの「同じアカウントに複数プロトコルの共有が存在する」設計で大きくなります。(Microsoft Learn)
まず押さえるべき設定の役割
Azure Filesのハードニングでは、似た名前の設定を混同しないことが重要です。特に、Secure transfer requiredと、SMB/NFSそれぞれのRequire Encryption in Transitは役割が異なります。
Require Encryption in Transit for SMB
SMB向けには、Require Encryption in Transit for SMBという専用設定が提供されています。この設定により、Azure FilesのSMBアクセスで転送中暗号化を要求するかどうかを、NFSやRESTとは独立して制御できます。Microsoft Learnでは、新しいストレージアカウントをAzure portalで作成した場合、このSMB向け設定は既定で有効になり、SMB 3.xの暗号化に対応しないマウントは拒否されると説明されています。一方、Azure PowerShell、Azure CLI、FileREST APIで作成した場合は、後方互換性のためNot selectedになる点に注意が必要です。(Microsoft Learn)
既存ストレージアカウントでは、最初はNot selectedとして表示されます。この状態では、従来のSecure transfer required設定がSMB暗号化の挙動を引き続き制御します。ただし、一度Require Encryption in Transit for SMBを明示的に構成すると、その値がSMBアクセスに優先されます。(Microsoft Learn)
Require Encryption in Transit for NFS
NFS向けには、Require Encryption in Transit for NFSが提供されています。NFSの転送中暗号化は、SSD Azure file sharesをサポートするすべてのリージョンで一般提供となっており、SMBと同様にプロトコル単位で暗号化要求を制御できます。NFSでは、Azure portal、Azure PowerShell、Azure CLIから設定でき、転送中暗号化を有効にする追加コストはありません。(Microsoft Learn)
NFSで特に重要なのは、サーバー側の設定だけでは完結しない点です。Azure FilesのNFSv4.1で転送中暗号化を使う場合、クライアント側ではAZNFS mount helperがStunnelを利用してTLS接続を構成します。つまり、NFS暗号化を必須化する前に、LinuxクライアントへAZNFSを展開し、マウント手順を検証しておく必要があります。(Microsoft Learn)
Secure transfer required
Secure transfer requiredは、現在の設計ではREST/HTTPSトラフィックの制御として理解する必要があります。Microsoft Learnでは、Azure FilesでSMBとNFSの暗号化要件をそれぞれのプロトコル別設定で制御できるようになり、Require encryption in transitが有効な場合、Secure transfer requiredはAzure file sharesのREST/HTTPSトラフィックに適用されると説明されています。(Microsoft Learn)
ここを誤解すると、次のような事故につながります。
| 誤解 | 起こり得る問題 | 正しい考え方 |
|---|---|---|
| Secure transfer requiredを有効にすればSMB/NFSも常に意図通り守られる | 既存アカウントや明示設定後の挙動を読み違える | SMB/NFSは専用のRequire Encryption in Transit設定を確認する |
| SMBを緩めるためにストレージアカウント全体の安全な転送を無効化する | REST/API側の安全性まで下がる可能性がある | SMBだけの例外として設計し、REST/HTTPSは別に守る |
| NFS暗号化を有効にすればクライアントはそのまま接続できる | AZNFS未導入のLinuxクライアントでマウント失敗が起きる | クライアント準備を先に済ませてから必須化する |
推奨する基本方針は「既定は強く、例外は狭く」
Azure FilesのSMB/NFSハードニングで最も避けたいのは、例外のために全体を緩めることです。レガシーOSや古いアプリケーションが1つあるだけで、同じストレージアカウント上の他の共有まで弱い設定に巻き込む設計は、運用が進むほどリスクになります。
実務では、次の順で設計すると判断しやすくなります。
| ワークロード | SMB暗号化 | NFS暗号化 | 推奨設計 |
|---|---|---|---|
| Windowsクライアント中心の一般的なファイル共有 | 有効 | 未使用なら対象外 | SMB 3.x対応を前提に暗号化必須。可能ならKerberos認証も検討 |
| Linux/HPC系のNFS共有 | 未使用なら対象外 | 有効 | AZNFSを標準化し、TLSマウントを運用手順に組み込む |
| SMBとNFSが同じストレージアカウントに混在 | 有効 | 有効 | 原則は両方有効。例外がある場合は共有単位ではなくアカウント分離を検討 |
| 古いOSやレガシーアプリが必要 | 条件付きで無効 | 条件付きで無効 | 本番標準とは別ストレージアカウントに隔離し、移行期限を決める |
| 移行・検証中 | 段階的に有効化 | 段階的に有効化 | Not selectedの意味を確認し、接続元ごとにテストしてから明示設定する |
「暗号化しない選択肢」を完全に排除するのではなく、使うなら範囲・理由・期限を明確にします。たとえば、古いWindows Serverや古いLinuxディストリビューションを一時的に維持する必要がある場合は、標準ストレージアカウントの設定を緩めるのではなく、例外専用アカウントへ分けるべきです。
SMBハードニングで確認すべきポイント
SMBでは、転送中暗号化だけでなく、SMBバージョン、認証方式、Kerberosチケット暗号化、SMBチャネル暗号化アルゴリズムを合わせて見直します。Azure Filesでは、SMB 3.1.1、SMB 3.0、SMB 2.1などのプロトコルバージョン、NTLMv2とKerberos、AES-256-GCMやAES-128-GCMなどのチャネル暗号化設定を制御できます。(Microsoft Learn)
特に注意したいのは、最大セキュリティ設定をいきなり適用すると接続できないクライアントが出ることです。たとえば、AES-256-GCMはWindows Server 2022やWindows 11以降のクライアントで考えるべき選択肢であり、古いクライアントを含む環境でこれだけに絞ると接続失敗の原因になります。(Microsoft Learn)
SMBの実務チェックリストは次のとおりです。
| 確認項目 | 推奨判断 | 失敗しやすいポイント |
|---|---|---|
| SMBクライアントのOS | Windows 11/Windows Server 2022以降か、古い端末が残るかを棚卸しする | クライアントOSを確認せずにAES-256-GCMのみへ制限する |
| SMBバージョン | 可能ならSMB 3.x中心にする | SMB 2.1が必要な理由を放置する |
| 認証方式 | Kerberosを使える構成なら優先的に検討する | ストレージアカウントキー利用を前提にし続ける |
| 例外対応 | 別ストレージアカウントへ分離する | 標準アカウントを例外に合わせて弱める |
| 変更タイミング | 業務時間外に段階適用し、ロールバック手順を用意する | 設定変更後のマウント失敗を想定していない |
SMB 2.1についても注意が必要です。Azure Filesでは、暗号化が無効な場合にSMB 2.1や暗号化なしのSMB 3.xを許可できますが、SMB 2.1接続はAzure file shareと同じAzureリージョン内に制限され、オンプレミスや別リージョンからのSMB 2.1アクセスはできません。(Microsoft Learn)
NFSハードニングで確認すべきポイント
NFSでは、SMBよりも「クライアント側の準備」が重要です。Require Encryption in Transit for NFSを有効にしても、Linuxクライアント側でTLSマウントの仕組みが整っていなければ、業務システムから見ると単にマウントできない障害になります。
Microsoft Learnでは、NFSの転送中暗号化にAZNFS mount helperを利用し、AZNFSがStunnelを設定してローカルのNFS要求をTLSでAzure Files NFSサーバーへ転送する構成が説明されています。対応ディストリビューションにはUbuntu、Red Hat、Rocky、SUSE、Oracle Linux、AlmaLinux、Azure Linuxなどが含まれます。(Microsoft Learn)
NFSでの安全な進め方は次のとおりです。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 棚卸し | NFS共有、接続元Linux、OSバージョン、マウントオプションを確認 | どのクライアントがTLS対応できるか分かっている |
| 準備 | 対象クライアントにAZNFSを導入 | aznfswatchdogが稼働している |
| 検証 | 検証共有をTLSでマウント | 再起動後も自動マウントできる |
| 切替 | Require Encryption in Transit for NFSを有効化 | 業務アプリが通常どおり読み書きできる |
| 運用 | 監視、手順書、例外管理を整備 | 新規クライアント追加時も同じ手順で展開できる |
NFSでは、性能検証も忘れてはいけません。暗号化そのものより、Stunnelプロセス、クライアントCPU、マウント数、アプリケーションのI/Oパターンが影響する場合があります。大量の小さなファイルを扱うワークロードや、HPCに近い使い方では、移行前後でレイテンシとスループットを比較しておくと安全です。
設定変更の実務手順
本番環境では、いきなり有効化するのではなく、接続元とプロトコルを分けて段階的に進めます。
現在の利用状況を整理する
最初に、ストレージアカウントごとに次の情報を表にします。
| 項目 | 確認内容 |
|---|---|
| ストレージアカウント名 | 対象アカウントとリソースグループ |
| ファイル共有 | SMB共有かNFS共有か |
| 接続元 | VM、オンプレミス、AKS、アプリケーションサーバーなど |
| OS/クライアント | Windows、Linuxディストリビューション、バージョン |
| 認証方式 | Kerberos、ストレージアカウントキー、その他 |
| 暗号化要件 | 必須、移行中、例外 |
| 例外期限 | いつまでに標準設定へ戻すか |
この棚卸しをせずに設定だけ変更すると、「どのサーバーがどの共有に接続していたか分からない」という切り戻し困難な状態になります。
SMBの転送中暗号化を有効化する
SMBのRequire Encryption in Transitは、Azure portalのFile share settings > Securityから設定できます。Azure PowerShellやAzure CLIで設定する場合、Microsoft Learnでは次のようなコマンドが案内されています。(Microsoft Learn)
Update-AzStorageFileServiceProperty `
-ResourceGroupName <resource-group> `
-StorageAccountName <storage-account-name> `
-SmbEncryptionInTransitRequired $trueaz storage account file-service-properties update \
--require-smb-encryption-in-transit \
--smb-eit true \
-n <storage-account-name> \
-g <resource-group>無効化も可能ですが、本番標準として安易にfalseへ戻すのは避けるべきです。必要な場合は、対象クライアント、理由、期限、代替策を変更申請に残します。
NFSの転送中暗号化を有効化する
NFSもAzure portal、Azure PowerShell、Azure CLIから設定できます。Microsoft Learnでは、次のコマンド例が案内されています。(Microsoft Learn)
Update-AzStorageFileServiceProperty `
-ResourceGroupName <resource-group> `
-StorageAccountName <storage-account-name> `
-NfsEncryptionInTransitRequired $trueaz storage account file-service-properties update \
--nfs-eit \
--require-nfs-encryption-in-transit true \
-n <storage-account-name> \
-g <resource-group>NFSでは、設定変更より前にAZNFSの導入確認を行います。たとえば、クライアントで次のような確認を行い、マウントヘルパーが正しく動く状態にしてから本番共有へ適用します。
systemctl is-active --quiet aznfswatchdog && echo "AZNFS mount helper is installed"「すべて暗号化」ではなく「分離して守る」設計にする
セキュリティ設計でありがちな失敗は、すべてのワークロードに同じ設定を押し付けることです。理想としては、すべてのSMB/NFSアクセスで転送中暗号化を要求するのが望ましい一方、現実には古いOS、商用パッケージ、移行途中のNFSクライアントが残ることがあります。
その場合でも、標準環境を弱める必要はありません。次のように分離します。
| 分離単位 | 使う場面 | メリット |
|---|---|---|
| ストレージアカウント分離 | レガシークライアントが残る | 例外が標準共有へ波及しにくい |
| サブスクリプション/リソースグループ分離 | 監査対象や運用チームが異なる | 権限、ポリシー、監視を分けやすい |
| ネットワーク分離 | 非暗号化や暫定構成を限定的に許可する | Private Endpoint、NSG、ルート制御と組み合わせやすい |
| 期限付き例外 | 移行期間だけ緩和する | 恒久的なセキュリティ負債を防げる |
特に、非暗号化接続を許可する可能性がある場合は、Private Endpointやネットワーク制限を併用し、接続元を明確に限定します。ただし、ネットワーク制限は暗号化の代替ではありません。盗聴や中間者攻撃への対策としては、あくまで転送中暗号化を標準にするべきです。
新規作成時と既存環境で注意点が違う
今回の更新で、管理者が最も見落としやすいのは「作成方法によって初期状態が異なる」点です。
Azure portalで新しいストレージアカウントを作成した場合、SMBとNFSのRequire Encryption in Transitは既定で有効になります。一方、Azure PowerShell、Azure CLI、FileREST APIで作成した場合は、後方互換性のためNot selectedとして作成されます。(Microsoft Learn)
つまり、IaCやスクリプトで大量にストレージアカウントを作成している環境では、「ポータルで作ったから安全だった」という前提が通用しません。Terraform、Bicep、ARMテンプレート、社内CLIラッパーを使っている場合は、SMB/NFSの転送中暗号化設定を明示的に管理項目へ追加する必要があります。
既存環境では、Not selectedがすぐに危険という意味ではありません。既存ストレージアカウントでは、明示設定するまでSecure transfer requiredがSMB/NFSの暗号化挙動を制御し続けるため、更新直後に一斉障害が起きる設計にはなっていません。ただし、将来の監査や運用の明確さを考えると、Not selectedのまま放置せず、SMB/NFSそれぞれの方針を明示するのが望ましいです。
セキュリティアーキテクト向けの設計パターン
Azure Filesのプロトコル別ハードニングは、次の3パターンで考えると実装しやすくなります。
標準セキュアパターン
新規の一般業務システムでは、SMB/NFSとも転送中暗号化を要求します。SMBではSMB 3.xを前提にし、認証は可能な限りKerberosを利用します。NFSではAZNFSを標準導入し、Linuxサーバー構築手順にTLSマウントを組み込みます。
このパターンは、社内標準、監査対象、機密データ、グローバル拠点からの接続を含む環境に向いています。
移行中パターン
オンプレミスのファイルサーバーからAzure Filesへ移行する場合、最初からすべてのクライアントを暗号化必須にできないことがあります。この場合は、検証用ストレージアカウントでクライアント互換性を確認し、問題のない共有から順にSMB/NFSのRequire Encryption in Transitを明示的に有効化します。
移行中パターンでは、Not selectedを「未決定の状態」として扱い、移行完了日までに有効または例外へ分類します。
例外隔離パターン
古いOSや更新できないアプリケーションが残る場合は、標準ストレージアカウントから切り離します。例外アカウントでは、アクセス元ネットワーク、権限、監視、データ分類を厳しく制限し、いつ廃止するかを明確にします。
ここで大切なのは、例外を「セキュリティ設定」ではなく「リスク管理対象」として扱うことです。設定を緩めるだけで終わると、半年後には誰も理由を説明できない恒久例外になります。
導入後に確認すべき運用チェック
設定を有効にしたら完了ではありません。Azure Filesのハードニングは、継続的に確認することで意味を持ちます。
| チェック項目 | 確認頻度 | 見るべきポイント |
|---|---|---|
| SMB/NFS暗号化設定 | 月次または変更時 | Not selectedや意図しないfalseが残っていないか |
| 接続失敗ログ | 変更直後と週次 | SMBバージョン不一致、NFS TLS未対応が発生していないか |
| 例外アカウント | 月次 | 期限切れ例外が残っていないか |
| クライアントOS | 四半期 | サポート切れOSや古いLinuxが残っていないか |
| IaCテンプレート | リリース時 | 新規アカウント作成時に設定が明示されているか |
| 手順書 | 変更時 | SMB/NFSそれぞれのマウント手順が最新か |
監査対応では、「暗号化が有効です」と説明するだけでは不十分です。どのプロトコルで、どのストレージアカウントに、どの例外があり、誰が承認しているのかまで説明できる状態にしておきます。
Azure Filesハードニングで次にやるべきこと
今回のAzure Files更新は、単なる暗号化オプションの追加ではなく、SMBとNFSを別々に守るための設計変更です。ストレージ管理者やセキュリティアーキテクトは、まず既存ストレージアカウントのSMB/NFS利用状況を棚卸しし、Require Encryption in Transit for SMBとRequire Encryption in Transit for NFSの状態を確認してください。
次に、標準構成では暗号化を要求し、レガシー要件は別ストレージアカウントへ隔離します。NFSではAZNFS導入、SMBではクライアントOSと暗号化アルゴリズムの互換性確認が欠かせません。最後に、IaCや運用手順へ設定を明文化すれば、Azure Filesのセキュリティは「一律に強くする」段階から、「プロトコルごとに正しく強くする」段階へ進められます。
コメント