この記事では、Microsoft.Storage で作成されたクラシック ファイル共有と Microsoft.FileShares で作成されたファイル共有を含む Azure Files のセキュリティ ガイダンスを提供します。 それは、共有、クライアント アクセス、データ保護、運用管理に関するリソースをカバーしています。
セキュリティ管理はリソース提供者とプロトコルに依存します。 サポート機能の比較については、Azure Files管理の概念を参照してください。
リソースの分離
ストレージアカウントを信頼境界として扱う: 同じストレージアカウント内で別々のクラシック ファイル共有を作成しても、ネットワーク ルール、SMB ID ソース、または暗号化キーの構成は分離されません。 これらのアカウントレベル設定の変更は、そのアカウント内のすべての共有に影響を与えます。 これらのコントロールを共有できる場合にのみ、クラシック共有をグループ化します。 Microsoft.FileSharesは、各共有に独立したネットワークおよびセキュリティ設定を提供することで、この共有アカウント レベルの境界を回避しています。
クライアントシステムの保護:書き込み権限を持つクライアントはファイルデータを変更または削除できます。 クライアントのオペレーティングシステムを常に最新の状態に保ち、ローカル管理アクセスを制限してください。 クライアント環境に適したエンドポイント保護を使用してください。 ネットワークの隔離や暗号化は、認可されたクライアントが破壊的な変更を行うのを防ぐものではありません。
ネットワークのセキュリティ
インバウンドアクセスとアウトバウンドフィルタリング
必要なクライアントへのインバウンドアクセスを制限する:両方のリソースプロバイダーはプライベートエンドポイントと仮想ネットワーク制限付きサービスエンドポイントをサポートしています。 NFS Azureファイル共有へのアクセスには、これらのパスのいずれかが必要です。 クラシックSMBおよびFileRESTクライアントもIPアドレスルールを持つパブリックエンドポイントを使用できます。 設定手順については、「Azure ファイル共有のためのネットワークエンドポイントの設定」を参照してください。
必要でない場合は公開アクセスを無効にする: パブリックエンドポイントは、プロトコルに適したネットワークアクセス制御、認証、暗号化を用いて安全に使用できます。 ワークロードで必要な場合で、セキュリティモデルが許可しているときは、サービスエンドポイントを通じた接続を含めてパブリックアクセスを有効にしてください。 プライベートエンドポイントを作成しても、公開アクセスが自動的に無効になるわけではありません。 従来の共有については、パブリック アクセスが無効になった後も有効な、信頼されたサービスまたはリソース インスタンスに対する例外がないか確認しましょう。 詳細は「 パブリックエンドポイントアクセスの制限」をご覧ください。
必要な時のみ信頼されたサービスのアクセスを有効にする: クラシック ファイル共有でのみ利用できる、信頼されたサービスの設定により、サポートされる Azure サービスはストレージ アカウントのネットワーク ルールをバイパスできます。 統合がこのアクセスを必要とする場合にのみ有効にしてください。 これらのサービスは、引き続きファイルデータにアクセスするための認可を受けている必要があります。
サービスエンドポイントトラフィックのオプションフィルタリング:クライアントがクラシックファイル共有にアクセスするためにサービスエンドポイントを使用する場合、サブネットにサービスエンドポイントポリシーを適用することも可能です。 このポリシーは、クライアントがサービス エンドポイントを通じてアクセスできるストレージ アカウントを制限しており、その場合、トラフィックは Azure Firewall やネットワーク仮想アプライアンスをバイパスします。 サービスエンドポイントトラフィックにのみ適用され、プライベートエンドポイントトラフィックやその他のアウトバウンドパスはフィルタリングしません。 宛先のネットワークルールや認可要件は引き続き適用されます。 Microsoft.FileSharesは現在、これらのポリシーをサポートしていません。 ポリシーを持つサブネット内のクライアントは、Microsoft.FileShares 共有にアクセスするためにプライベート エンドポイントを使用しなければなりません。 詳細については、 サービスエンドポイントポリシーをご覧ください。
ネットワークセキュリティ境界を使用する前にプロトコルサポートを確認してください:クラシックな共有では、境界サポートはプロトコルや認証方法によって異なります。 強制モードでは、ペリメーターがパブリックエンドポイントを通じた NFS アクセス（サービス エンドポイント トラフィックを含む）を拒否します。 プライベート エンドポイントのトラフィックは境界の適用対象外です。 境界を適用する前に、Azure BackupとAzure File Syncの制限を確認してください。 詳細については、Azure FilesのNetwork security perimeterをご覧ください。
SMBプロトコル強化
これらの推奨事項は、従来のSMBファイル共有にも適用されます。
SMBチャネル暗号化を義務付ける:暗号化されたSMB 3.x接続を使用します。 SMB 2.1はチャネル暗号化をサポートしていません。 FileRESTのHTTPS要件はSMB暗号化構成に代わるものではありません。 詳細については、 SMB暗号化およびセキュリティ設定をご覧ください。
クライアントに必要なプロトコル バージョンとアルゴリズムのみに制限します: ワークロードと互換性のある最も安全な SMB プロファイルを使いましょう。 SMB 3.1.1やAES-256-GCMを必須にする前に、クライアントのサポート状況を確認してください。互換性のないクライアントは接続できません。 SMBチャネル暗号化とKerberosチケット暗号化は別々の制御です。 詳細については、 SMBのセキュリティ設定をご覧ください。
SMB認証方法を制限する:アイデンティティベースのアクセスにはKerberosを使用。 SMB経由でストレージアカウントキー認証が必要なクライアントがいない場合は、テスト後にNTLMv2をSMB認証方法から除外してください。 この制御はSMBに適用されます。KeyベースのFileRESTアクセスを無効にするわけではありません。
該当する場合はAD DSの認証情報を維持する:AD DS認証では、ディレクトリポリシーに従ってストレージアカウントを表すディレクトリプリンパルのパスワードを管理してください。 ディレクトリのパスワードとストレージアカウントのKerberosキーを同期させるために、文書化されたローテーション手順に従ってください。 詳細については、「 AD DSのストレージアカウント識別パスワードを更新する」をご覧ください。
NFS 4.1ファイル共有
これらの推奨事項は、いずれのリソースプロバイダーでもNFSファイル共有に適用されます。 NFSはSMBのアイデンティティベースの認証ではなく、ネットワークベースの認証とPOSIX権限を使用します。
信頼できるネットワークへのアクセスを制限する:ワークロードに必要なサブネットとプライベート接続のみを許可します。 NFS はクライアントが提示するアイデンティティに依存しているため、どのシステムや管理者がそれらの接続を使用できるかを制御してください。
POSIX権限とクライアントIDの管理: クライアント間で一貫したユーザーIDとグループIDを使用しましょう。 ファイルおよびディレクトリの権限はアクセスが必要なユーザーやグループに限定します。 Azure RBACのAzureリソース管理権限はNFSファイルへのアクセスを許可しません。 詳細については、「 NFS認証およびネットワークアクセス」をご覧ください。
ワークロードに適合する部分でルートスカッシュを設定:ルートスカッシュはUID/GID 0からのリクエストを匿名のアイデンティティにマッピングします。 他のアイデンティティを制限したり、共有を読み取り専用にしたりしません。 両方のリソースプロバイダーの設定および設定手順については、NFS Azureファイル共有のルートスクワッシュを参照してください。
転送中の暗号化を必須にする: 両方のリソースプロバイダーはAZNFSマウントヘルパーを通じてTLSをサポートしています。 Microsoft.FileShares は既定で転送中の暗号化を必要とします。 クラシック シェアはストレージ アカウント レベルの NFS 暗号化設定を持っています。 デフォルトおよび構成と設定に関するリンクについては、NFS 暗号化を参照してください。
アイデンティティとアクセス管理
Azure Resource Management
管理アクセスに最小権限を適用:リソースの作成、設定、削除に必要な最小範囲でAzure RBAC権限を付与します。 クラシック共有では、アカウントレベルの権限がアカウント内のすべての共有に影響します。 Microsoft.FileShares リソースを個別に管理できます。 管理役割とデータアクセス権限は異なる目的を持ちます。 詳細については、「Azure コントロール プレーンとデータ プレーン」を参照してください。
常設管理アクセスを制限する: 特権 Azure ロールには、適切な場合は Microsoft Entra Privileged Identity Management を使用します。 組織の方針に従い、管理者によるアクティブ化には承認と多要素認証を必須にしてください。 詳細については、「 Privileged Identity Management」を参照してください。
SMBファイル共有のためのアイデンティティベースの認証
SMBアイデンティティベースのアクセスはクラシックファイル共有で利用可能です。 ストレージアカウントキーは、アカウント内のシェア全体に広範なデータアクセス権を与え、個々のユーザーを特定するものではありません。
クライアントでサポートされるアイデンティティ ソースを使用しましょう: Azure FilesはAD DS、Microsoft Entra Domain Services、Microsoft Entra Kerberosをサポートしています。 それぞれのクライアント要件と ID 要件は異なります。 サポートされているシナリオとセットアップ ガイドについては、Azure Files の ID ベース認証を参照してください。
サポートされたアプリケーションワークロードにマネージドIDを使う:マネージドIDはストレージアカウントキーを配布せずにSMBアクセスを提供します。 デプロイメントのコンピュート、クライアント、認証の前提条件を確認してください。 詳細については、「マネージド ID を使用して SMB 共有にアクセスする」をご覧ください。
必要に応じてアカウントキーを保護する:キーの取得や再生成の許可を制限する。 必要な鍵はAzure Key Vaultに保存し、漏えい後や認証情報ポリシーに従ってローテーションしてください。 キーを使い続けるクライアントや連携に合わせてローテーションを計画しましょう。 詳細については、「ストレージ アカウントのアクセス キーの管理」を参照してください。
共有レベルおよびNTFS権限
これらの権限は従来のSMBファイル共有にも適用されます。
必要な範囲で共有レベルのロールを割り当てる: 必要なアイデンティティにのみ読み取り、書き込み、または管理アクセスを付与します。 シェアレベルの役割割り当ては、同じストレージアカウント内の無関係なシェアへのアクセスを許可しません。 詳細については、「 共有レベルのアクセス許可を割り当てる」を参照してください。
ディレクトリ権限とファイルの権限を適用する:共有フォルダ内のアクセスを制御するために、共有のルートディレクトリを含むWindowsのACLを使用します。 継承を使って権限を管理しやすく保ちましょう。 共有レベルの権限とWindows ACLの両方が適用されます。 詳細については、「 ディレクトリ レベルおよびファイル レベルのアクセス許可を構成する」を参照してください。
権限管理の制限: 権限管理を担当するアイデンティティに特権ロールとACL変更権限を限定します。 アクセス要件が変わった際には、役割割り当てと引き継いだACLの両方を確認しましょう。
FileRESTアクセスとSAS
FileRESTのデータアクセスはクラシック共有で利用可能です。 Microsoft.FileSharesは現在FileRESTのデータアクセスをサポートしていません。
サポートされている管理データ アクセスには OAuth を使用してください: Microsoft Entra の ID (マネージド ID を含む) は、FileREST を通じてクラシック共有にアクセスできます。 このアクセス方式で使われる特権ロールはファイル権限やディレクトリ権限を回避できるため、そのアクセスが必要な場合にのみ付与してください。 詳細は Azure Files OAuth over REST をご覧ください。
SAS権限と寿命を制限する:サポートされているツールが共有アクセス署名(SAS)を必要とする場合は、その範囲、権限、有効期間を制限し、HTTPSを義務付けます。 SASを認証情報として保護しましょう。 SASトークンはSMBやNFS上のシェアをマウントするためには使われません。 詳細については、 共有アクセス署名を参照してください。
FileRESTにHTTPSを要求する:HTTPSはRESTリクエストを転送時に保護します。 SMBチャネル暗号化とNFS TLSトンネリングはHTTPS要件とは別です。 設定手順については 「セキュア転送を要求する」 を参照してください。
データ保護
静止時暗号化を理解する:両方のリソースプロバイダーはデフォルトでMicrosoft管理キーでファイルデータを暗号化しています。 保存データの暗号化は保存データを保護します。認可されたクライアントがファイルを読み取ったり変更したりするのを防ぐものではありません。
必要に応じてカスタマーマネージドキーを使う:Classic SharesはAzure Key VaultまたはManaged HSMでカスタマーマネージドキーをサポートします。 Microsoft.FileShares は現在、カスタマー マネージド キーをサポートしていません。 鍵ストアを保護し、鍵のローテーションを計画し、鍵アクセス権を失うことでデータが利用できなくなる可能性があることを理解しましょう。 詳細については、Azure FilesのCustomer-managed keys をご覧ください。
該当するクラシック展開のためのインフラ暗号化を評価する: コンプライアンスポリシーで必要に応じて、クラシック ストレージ アカウントに追加の暗号化レイヤーを適用できます。 このオプションはアカウント作成時に選択され、その後変更できません。 サポートされているアカウントタイプについては、 インフラストラクチャ暗号化を参照してください。
管理操作を保護するためにリソースロックを使う:適切なAzureリソースまたは親スコープにCanNotDeleteロックをかけることで、Azure Resource Managerを通じて削除を防ぐことができます。 ロックはクライアントがファイルデータを変更・削除することを防げません。 クラシック共有の場合、FileRestのデータプレーンAPIによる削除も防げません。 ロックの挙動や運用効果については、「Lock Azure resources」を参照してください。
バックアップと回復
回復ニーズに応じて共有スナップショットを取得:両方のリソースプロバイダーは、以前のファイルバージョンの復元のための共有スナップショットをサポートしています。 回復目標に合ったスケジュールと保持ポリシーを設定しましょう。 共有スナップショットは元の共有と関連付けられたままなので、その共有が永久に削除された場合は独立したバックアップを提供しません。 詳細は、「Azure Files のスナップショットを共有する」をご覧ください。
クラシック共有のソフト削除を有効にする:ソフト削除は設定された期間、削除された共有を保持します。 個々のファイルや個別に削除されたスナップショットを復元することはありません。 Microsoft.FileSharesは現在ソフト削除をサポートしていません。 詳細については、「Azure ファイル共有の誤削除を防ぐ」を参照してください。
そのプロトコルでサポートされているバックアップ ソリューションを選択してください: Azure Backup はクラシックな SMB 共有をサポートし、スナップショット バックアップとボールト バックアップのオプションがあります。 現在、どちらのリソースプロバイダーともNFS共有をサポートしていません。 NFSの場合は、プロトコルをサポートし、保持や分離の要件を満たすバックアップソリューションを選びましょう。 Azure Backupのカバレッジについては、Azureファイル共有バックアップのサポートを参照してください。
バックアップ管理とテスト復旧を分離する: リカバリーポイントを削除したり保持期間を変更できる人を制限します。 ファイル、権限、完全なワークロードのテスト復元。 本番環境の認証情報やソース共有が侵害された場合に復旧が可能かどうかを確認しましょう。
データ復旧とは別にインフラ障害への対策を計画する: 冗長性はインフラ障害への耐性を高めるだけでなく、データ変更も複製する。 不要な変更や削除に備えるバックアップを置き換えるものではありません。 利用可能な冗長性オプションはメディア階層やリソース提供者によって異なります。 詳細については、「Azure Files の冗長性」を参照してください。
ログ記録と監視
両方のリソース プロバイダーの管理変更を監査: Azure アクティビティ ログを使ってリソース削除、設定変更、ロール割り当てを監視します。 パブリック アクセスへの変更、ネットワーク ルール、暗号化要件、復旧管理を確認してください。 詳細については、「 Azure アクティビティ ログ」を参照してください。
サポートされるデータ アクセス ログの収集: 従来の SMB および FileREST アクセスの場合、ファイル サービスのリソース ログを使って呼び出し元、認可方法、失敗した要求、削除アクティビティを確認します。 保持ポリシーで必要なログは Log Analytics や他のサポートされている宛先で収集してください。 NFSやMicrosoft.FileSharesで同じリクエストログカバレッジを想定しないでください。 サポートされる操作やフィールドについては、Azure Filesのモニタリングデータ参照を参照してください。
アラートをクライアントおよびアイデンティティログと関連付ける:予期せぬキー使用、認証失敗、共有削除、セキュリティ設定の変更を調査します。 リクエストがAzure Filesに届く前に認証失敗が発生した場合は、クライアントログとディレクトリログを使用してください。 アラートを業務担当チームにルーティングします。
クラシック展開のためのDefender for Storageを評価する:Defender for Storageは、サポートされたストレージアカウントに対して脅威検出を提供します。 展開の機能やプロトコルのカバレッジを確認してください。アカウント保護は、すべてのファイル操作がマルウェア スキャンの対象になることを意味するわけではありません。 詳細については、Microsoft Defender for Storageをご覧ください。
コンプライアンスとガバナンス
リソース プロバイダーに一致するポリシーを適用: リソースの種類とプロパティがサポートされている場合は、Azure Policy を使用して組織の要件を監査または適用してください。 各定義の範囲と効果を確認してください。 Microsoft.Storage ストレージ アカウントを対象とするポリシーは、Microsoft.FileShares リソースを自動的には評価しません。 詳細については、Azure Policy の定義 を参照してください。
所有権およびデータ要件: リソースタグを使って、責任あるチーム、環境、データの分類を特定します。 クラシック共有の場合、アカウントレベルの制御はアカウント内のすべての共有に影響します。 例外を記録し、ワークロードの所有権が変わったときに確認しましょう。
デプロイの適合性を検証する: 選択したサービス、リージョン、プロトコル、保護機能が要件を満たしているか確認してください。 Microsoftのクラウドセキュリティベンチマークを使ってコントロール レビューを整理しましょう。 認証情報については、Azure Storage コンプライアンス オファリングをご覧ください。
Azure File Sync
Azure File SyncはクラシックなSMB 共有をサポートしています。 NFSやMicrosoft.FileSharesには対応していません。 クラウドシェアとWindows Serverエンドポイントの両方を安全にしてください。
サポートされている File Sync のデプロイにマネージド ID を使用する: ストレージ同期サービスおよび登録済みサーバーのマネージド ID の構成に従って、共有キーへの依存関係を取り除きます。 詳細については、「Azure File Syncで管理されたアイデンティティを使う」をご覧ください。
同期リソースとサーバーへの管理アクセスを制限する: 適切なスコープで必要な Storage Sync のロールを使用します。 ローカルファイル権限とサーバー管理を保護しましょう。サーバーエンドポイントを通じて行われた変更はクラウドシェアに同期されるからです。 詳細については、「Azure File Syncのデプロイメント計画」をご覧ください。