Azure Storage アカウントをセキュリティで保護する

Azure Storageは、単一のストレージアカウント内でブロブ、ファイル、キュー、テーブルのためのスケーラブルで耐久性のあるクラウドストレージを提供します。 ストレージアカウントは機密度が非常に異なるデータを保持し、しばしば流出やランサムウェア攻撃の標的となるため、アカウント、そのデータ、アクセスする身元を保護するために意図的な対策を講じてください。

この記事では、Azure Storageアカウントを守るためのセキュリティ推奨事項を提供します。 これらの推奨事項はアカウント内のすべてのデータサービス(Blob、ファイル、キュー、テーブル)に適用されます。 各データサービスに特化した指針については、この記事の最後に記載された 関連セキュリティ記事 をご覧ください。

この記事のセキュリティに関する推奨事項では、ゼロ トラストの原則 ("明示的に確認する"、"最小限の特権アクセスを使用する"、"侵害を想定する") が実装されています。 包括的なゼロ トラスト ガイダンスについては、 ゼロ トラスト ガイダンス センターを参照してください。

サービス固有のセキュリティ

Azure Storageは、安全に展開する方法を形作るアーキテクチャの特徴を持っています。 アカウント作成時に行う選択—デプロイメントモデル、種類、冗長性、エンドポイント設定—は後で変更が難しく、アカウントを使用するすべてのワークロードのセキュリティ体制に影響を与えます。

ストレージアカウントアーキテクチャ

  • Azure Resource Managerのデプロイメントモデルを活用してください:Azure Resource Managerのデプロイメントモデルを使って新しいストレージアカウントを作成します。 Resource ManagerアカウントはAzureロールベースのアクセス制御(RBAC)、マネージドアイデンティティ、Microsoft Entra IDによるデータ認証、リソースロック、タグ、ポリシーをサポートしており、これらはクラシックデプロイメントモデルでは利用できません。 残っているクラシックアカウントを移行してください。 詳細については、「クラシックストレージアカウントをAzure Resource Managerに移行する」をご覧ください。

  • ワークロード、環境、感度ごとにストレージアカウントを別々に:開発、プリプロダクション、本番用に別々のアカウントを作成し、異なるセンシティシティ分類のデータごとに別々のアカウントを作成します。 ストレージアカウントは共有鍵の信頼境界であり、ポリシーの境界でもあります。1つのアカウント内でワークロードを混同すると侵害の半径が広がり、最小権限アクセスのモデル化が難しくなります。

  • 地域別分離のために地域ごとに1つのアカウントを使う:消費業務が稼働している地域にアカウントを配置することで、地域間のデータ移動を減らし、コンプライアンスの境界を簡素化します。 マルチリージョン設計では、リージョンアカウントとジオリデンダントストレージやオブジェクトレプリケーションを組み合わせて、単一のアカウントからすべてのリージョンをカバーするのではなく、 詳細については、「Azure Storage の冗長性」を参照してください。

Azure Storageの適切な使用

  • Azure Storageのアカウントキーを長期のアプリケーション認証情報として使わないでください:ストレージアカウントキーはアカウントの完全な制御権を持ち、スコープは設定できません。 アプリケーションは管理型IDでMicrosoft Entra IDを使用するか、Entra IDが使えない場合は短命なユーザー委任共有アクセス署名(SAS)トークンを使うべきです。 詳細については、「Azure Storage でデータへのアクセスを承認する」を参照してください。

  • Azure Storageを汎用シークレットストアとして使わないでください:シークレット、接続文字列、証明書はAzure Key Vaultに含まれており、ローテーション、アクセスポリシー、ハードウェアセキュリティモジュール(HSM)保護、監査トレイルを提供します。 詳細については、「 Azure Key Vault の概要」を参照してください。

ネットワークのセキュリティ

ストレージアカウントはデフォルトでインターネット経由でアクセス可能です。 ネットワークの攻撃面を減らすことは、不正アクセス、データ流出、偵察からアカウントを守るために最も効果的な変更です。

  • ストレージアカウントへのパブリックネットワークアクセスを無効にする:クライアントが完全にAzure上にあるかPrivate Link経由でアクセス可能な場合は、アカウントのパブリックネットワークアクセスを無効に設定し、プライベートエンドポイントからのリクエストのみが受け入れられるようにしてください。 詳細については、Azure Storage ファイアウォールおよび仮想ネットワークの構成に関する記事を参照してください。

  • 仮想ネットワークからのアクセスにはプライベートエンドポイントを使う:プライベートエンドポイントは仮想ネットワークからストレージアカウントにプライベートIPアドレスを割り当て、Microsoftバックボーン経由でトラフィックをルーティングします。 無効化されたパブリックネットワークアクセスと組み合わせることで、プライベートエンドポイントはインターネットへの露出を排除します。 詳細については、「Azure Storage のプライベート エンドポイントを使用する」を参照してください。

  • プライベートエンドポイントが実用的でない場合、ストレージファイアウォールでパブリックアクセスを制限する:クライアントがパブリックネットワーク経由でアカウントにアクセスする必要がある場合は、ファイアウォールのデフォルトアクションを 「拒否 」に設定し、アクセスが必要な特定のIP範囲、仮想ネットワークサブネット(サービスエンドポイント経由)、またはリソースインスタンスのみを許可します。 詳細については、Azure Storage ファイアウォールおよび仮想ネットワークの構成に関する記事を参照してください。

    • 信頼された Microsoft サービスがアカウントにアクセスする必要があるときに許可する: 既定で拒否するファイアウォール ルールは、他の Azure サービス（たとえば、Azure Backup、Log Analytics、Microsoft Defender for Storage）からの要求に加えて、Azure portal および診断パイプラインからの要求もブロックします。 信頼されるサービスリストに「Allow Azure services」を追加して、このストレージアカウント例外にアクセスするようにしましょう。そうすれば、信頼しているファーストパーティサービスがパブリックインターネットに開かずにアカウントにアクセスできます。 詳細については、「信頼されたAzure サービスへのアクセスを参照してください。

    • 信頼できるサービスではなく、特定のリソースインスタンスへのアクセスを広く許可する:一般的な「Allow Microsoft サービス」例外よりも、名前付きのAzureリソースとその管理IDを許可するリソースインスタンスルールを優先してください。 リソースインスタンスルールは信頼表面積を小さくします。 詳細については、「 Azure リソース インスタンスからのアクセスを許可する」を参照してください。

  • ストレージアカウントをネットワークセキュリティ境界と関連付ける:ネットワークセキュリティ境界は、プラットフォームとサービスリソース間の論理的境界を定義し、デフォルトで境界外のトラフィックをブロックすることで、アカウントごとのファイアウォールルールを超えた深い防御を提供します。 詳細については、Azure StorageのNetwork security perimeterをご覧ください。

  • TLSの最低バージョン1.2以降を強制する:ストレージアカウントの最低TLSバージョンを設定し、古い廃止バージョンの交渉を拒否するクライアントを拒否します。 詳細については、「 ストレージアカウントの最小必要バージョンのトランスポート層セキュリティ(TLS)の設定」をご覧ください。

  • Secure Transfer (HTTPS)を要求する: Secure transfer required プロパティを有効にして、HTTP上でのすべてのリクエストを拒否します。 この要件はRESTエンドポイントだけでなく、SMBによるAzure Filesへのアクセスにも適用されます。 詳細については、「 ストレージアカウントのセキュアトランスファーの要求」をご覧ください。

    • 古いSMBクライアントやレガシーツールのようにHTTPを必要とするシナリオもあります。 その場合は、制御されたネットワークセグメント内でクライアントを隔離し、できるだけ早くHTTPから移行してください。

  • テナント間オブジェクトの複製およびコピー操作を制限する:ストレージアカウントを、同じテナント内のソースアカウントからのみ、または許可リストされたソースアカウントからのみコピーおよびオブジェクトレプリケーション操作を許可するように設定します。 この構成により、データプレーン権限を持つユーザーによるテナント境界を越えたデータ移動を防ぎます。 詳細については、「コピー操作の許可範囲」および「Microsoft Entraテナント間でのオブジェクト複製の防止」をご覧ください。

  • Azure StorageのアウトバウンドルールにはVNetサービスタグを使う:仮想ネットワークからAzure Storageへのアウトバウンドトラフィックを制限する場合は、IP範囲をハードコーディングせず、Storageサービスタグ(または地域固有のバリエーション)を使いましょう。 MicrosoftはIP分野の進化に合わせてサービスタグを維持しています。 詳細については、「Azure サービス タグの概要」を参照してください。

  • 受信ルーティングにMicrosoftグローバルネットワークを優先する:ストレージアカウントのネットワークルーティングの優先順位をMicrosoftネットワークルーティングに設定し、受信トラフィックがクライアントに最も近いMicrosoftバックボーンのプレゼンスポイントに入り、Microsoftネットワーク上でエンドツーエンドに留まるようにします。 インターネットルーティングはMicrosoftネットワークから早期に退出し、公共のインターネット経路への露出を増加させます。 詳細については、「Azure Storage に対してネットワークのルーティング優先設定を構成する」を参照してください。

アイデンティティとアクセス管理

ストレージアカウントは2つの認証モデルをサポートしています:Microsoft Entra ID(アイデンティティベースで監査可能、可撤回可能)とShared Key(完全なアカウントアクセスを持つ対称シークレット)です。 可能な限りワークロードをMicrosoft Entra IDに移し、共有キーをレガシーのフォールバックとして扱いましょう。

  • Microsoft Entra IDを使ってデータへのアクセスを承認する:Microsoft Entra ID認証はOAuth 2.0トークンを使用し、条件付きアクセス、マネージドアイデンティティ、RBAC監査トレイルと統合されます。 データプレーンアクセスにおいては、共有キーよりもあらゆる面で優れています。 詳細については、「Azure Storage でデータへのアクセスを承認する」を参照してください。

  • 共有鍵の認可を拒否する: allowSharedKeyAccess プロパティを false に設定し、アカウントキーで署名されたリクエストを拒否します。 Microsoft Entra IDのみが受け入れられ、該当する場合はユーザー委任SASリクエストのみが受け入れられます。 詳細については、Azure Storage アカウントでの共有キー承認の防止を参照してください。

  • RBACロールを最小の合理的な範囲で割り当てる:可能であれば、組み込みのストレージデータプレーンロール(例: ストレージブロブデータリーダー、 ストレージキューデータコントリビューター)をコンテナ、シェア、キュー、テーブルレベルで割り当て、アカウントやサブスクリプションレベルでではなく。 詳細については、「Azure role-based access controlを使ったブロブへのアクセスを許可する」をご覧ください。

    • データプレーンアクセスをさらに制限するためにABAC条件を追加:Azure属性ベースのアクセス制御(ABAC)は、役割割り当てに条件を付けることができます。例えば、特定のインデックスタグや特定のパスプレフィックスのブロブへのアクセスを制限できます。 詳細については、「Azure role assignments with ABAC conditionsを使ってブロブへのアクセスを許可する」をご覧ください。

  • SASが必要な場合はサービスやアカウントSASの代わりにユーザー委任SASを使用してください:ユーザー委任SASはアカウントキーではなくMicrosoft Entraの認証情報で署名されるため、ユーザー委任キーを取り消すと即座に発行されたすべてのSASが無効になります。 アカウントキーで署名されたサービスおよびアカウントSASトークンは個別に取り消すことはできません。 詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。

    • すべてのSASを最低権限と最短寿命に設定:特定の操作のみを許可(例: read は付与し、 writeは付与しない)。保存されたアクセスポリシーに裏付けられていないサービスSASは有効期限を1時間以内に設定します。 詳細については、 SAS使用時のベストプラクティスをご覧ください。

    • アカウントでSASの有効期限ポリシーを設定する:アカウントから発行されたSASトークンの有効期間の上限を設定します。 違反はログに記録されるため、コードベース内の長く使われているSASを見つけて修正できます。 詳細については、共有アクセス署名の有効期限ポリシーの作成に関する記事を参照してください。

    • SASトークンはHTTPSのみに制限する:SASを発行する場合は、SAS署名にHTTPSのみを許可して、クリア中のトークン露出を防ぎましょう。 詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。

  • アカウントキーを使わなければならない場合は、保護し、順番に切り替えてください:Azure Key Vaultにアカウントキーを保存し、設定に埋め込むのではなく実行時に取得し、定められたリズムでローテーションしてください。 ロールオーバー時に両方のキーを使うことでダウンタイムを避けるためのローテーション手順を文書化しましょう。 詳細については、「ストレージ アカウントのアクセス キーの管理」を参照してください。

  • Microsoft Entra Privileged Identity Management (PIM) を使用して、特権ストレージ ロールを Just-In-Time で割り当てます: ストレージに対する管理プレーンの変更を許可するロール（Storage Account Contributor や Owner など）については、常時割り当てではなく、承認と多要素認証を伴う PIM でのアクティブ化を必須にします。 詳細については、「Microsoft Entra Privileged Identity Management とは」を参照してください。

データ保護

Azure Storageは、Microsoft管理キーですべてのデータをデフォルトで暗号化しています。 このセクションの推奨事項は、顧客のコントロール、偶発的または悪意ある改変からの保護、そして移動中および静止中のデータの露出を減らします。

  • 顧客管理鍵(CMK)を静止時の暗号化に設定する:Azure Key VaultまたはManaged HSMで管理している鍵をアカウントの暗号化鍵として使用してください。 CMKはMicrosoft管理キーとは独立して暗号化鍵をローテーション、監査、取り消すことができます。 顧客の鍵管理を義務付けるコンプライアンス要件をサポートします。 詳細については、「Azure Storage 暗号化のカスタマー マネージド キー」を参照してください。

  • 防御深層によるインフラ暗号化を有効にする:インフラ暗号化は、一次暗号化層の上にサービス管理される第二の暗号化層を適用します。 アカウント作成時に必ず有効にしなければなりません。 詳細については、「 データの二重暗号化のためのインフラストラクチャ暗号化を有効にする」をご覧ください。

  • 暗号化スコープを使って特定のコンテナやブロブごとに暗号化を分離する:暗号化スコープは、単一のアカウント内でコンテナレベルまたはブロブレベルの細かさで異なる鍵や鍵ローテーションポリシーを適用できます。 この機能は、アカウントを共有しつつもテナントごとのキー制御が必要なマルチテナントワークロードに便利です。 詳細は「Blob Storageの暗号化スコープ」を参照してください。

  • すべての転送中のデータに対してAzure Storage暗号化を有効にする:Secure transfer required = enabled(ネットワークセキュリティ参照)と最低限のTLSバージョン1.2以降を組み合わせること。 これらは連携して、アカウントが暗号化されていない接続と弱い暗号化の両方を拒否するようにしています。

  • 最も機密性の高いデータにはクライアント側暗号化を用いましょう:サーバー上に平文が表示されてはならないデータについては、アップロード前にクライアント側で暗号化してください。 クライアント側暗号化はサービス側暗号化を補完し、CMKと組み合わせてレイヤー保護に利用できます。 サービスごとのSDKサポートやパターンについては 、「関連セキュリティ記事」をご覧ください。

  • ストレージアカウントをリソースロックで保護する: CanNotDelete や ReadOnly Lockを適用して、アカウント自体の誤ったまたは悪意のある削除や再設定を防ぎます。 ロックはアカウントリソースに適用され、その中のデータには適用されないため、ソフト削除や不可変性を補完するものであり、置き換えるものではありません。 詳細については、「Azure Resource Manager のロックをストレージ アカウントに適用する」を参照してください。

データサービス固有のデータ保護機能(ブロブの不変性やWORMポリシー、ブロブ暗号化スコープ)については、 関連セキュリティ記事の対応するサブ記事を参照してください。

ログ記録と監視

ストレージアカウントは、認証情報の盗難、流出の試み、誤設定の頻繁な標的となっています。 攻撃を迅速に検知し対応するためには、継続的なログ記録と脅威検出が必要です。

  • Microsoft Defender for Storageを有効にする:Defender for Storageは脅威検出、アップロード時のブロブスキャン、機密データ検出を提供します。 異常なアクセスパターン、既知の悪意のあるIPやTor出口、異常な認証活動を検出します。 サブスクリプションレベルかストレージアカウントレベルで有効にしてください。 詳細については、「Microsoft Defender for Storageの概要」をご覧ください。

    • 信頼できないコンテンツを受け入れるアカウントでブロブアップロードのマルウェアスキャンを有効にする:マルウェアスキャンはアップロードされたブロブを検査し、悪意のあるコンテンツをマークまたは削除してから、下流の消費者に提供されます。 詳細は「Defenderのストレージ用マルウェアスキャン」をご覧ください。

    • 機密データ脅威検出を有効にする:機密データ発見はアカウント内のデータを分類し、機密情報を含むコンテナへのアラートを優先します。 詳細については、「Defender for Storageにおける機密データ発見」をご覧ください。

  • 診断設定をLog Analyticsワークスペースに送信する:アカウントおよび各データサービス(Blob、ファイル、キュー、テーブル)で診断設定を設定し、StorageRead、StorageWrite、StorageDeleteログおよびすべてのメトリクスをLog Analyticsに送信します。 コンプライアンス義務で定められた期間だけログを保持してください。 詳細については、「Azure Storage を監視する」を参照してください。

  • 各リクエストの認可方法を監査する:ストレージログは、各リクエストがMicrosoft Entra ID、Shared Key、SAS、または匿名で承認されたかを記録します。 ログを定期的に照会し、予期せぬ認可方法、特に無効化後の共有鍵使用や無効化後の匿名アクセスなどを検出してください。 詳細については、「Azure Storageに対するリクエスト監視」をご覧ください。

  • 高信号のセキュリティイベントに対するアラート:鍵の再生、ファイアウォールルールの変更、パブリックネットワークアクセスの変更、無効化すべきアカウントでの共有鍵使用、Defender for Storageのアラートなどのイベントに対して、Azure Monitorアラートを設定しましょう。 詳しくは、「Azure Monitor でのログ アラート」を参照してください。

  • ログを中央SIEMに転送する:エンタープライズ規模の対応では、Log AnalyticsからストレージログをMicrosoft Sentinelや他のSIEMに転送し、ストレージイベントがアイデンティティ、ネットワーク、エンドポイントの信号と相関するようにします。 詳細については、「Connect Azure Storage to Microsoft Sentinel」をご覧ください。

コンプライアンスとガバナンス

ガバナンス制御により、安全な構成がデフォルトとなり、自動的にドリフトを検出します。 数個以上の保管資産に対しては、ポリシーベースの執行がベースラインの一貫性を保つ唯一の持続可能な方法です。

  • Azure Policyを適用してベースラインストレージセキュリティを強制する:デプロイ時に安全でない設定をブロックする組み込みポリシーを割り当て、既存アカウントを監査します。 高価値の組み込みには、セキュア転送の要求、最低TLS 1.2の要求、公共ネットワークアクセスの拒否、公共ブロブへのアクセスの拒否、インフラストラクチャ暗号化の要求、CMKの要求などがあります。 完全なリストについては、Azure Policy built-in definitions for Azure Storage および Azure Policy Regulatory Compliance controls for Azure Storage を参照してください。

  • Microsoftクラウドセキュリティベンチマーク(MCSB)を基準にしてください:ストレージ制御をMCSB v2ドメインと整合させ、サービス間で一貫したセキュリティ体制を確保しましょう。 詳細については、Microsoftクラウドセキュリティベンチマークの概要をご覧ください。

  • 所有者、データ分類、環境でストレージアカウントにタグ付けする:ガバナンスポリシー、コスト管理、インシデント対応はすべて一貫したタグ付けに依存しています。 タグはAzure Policyで適用し、作成時に省略されないようにしましょう。

  • 規制対象データを保存する前にコンプライアンスの内容を確認しましょう:Azure Storageは一般的な規制フレームワーク(HIPAA、PCI DSS、FedRAMP、ISO 27001など)の認証を取得しています。 派遣前に自分の業務量のカバーを確認してください。 詳細については、Azure Storage コンプライアンス オファリングをご覧ください。

バックアップと回復

地域横断冗長性と検証済みフェイルオーバー手順により、ストレージアカウント自体の地域的なレジリエンスが提供されます。 データサービス固有の削除保護(ブロブソフト削除、ブロブバージョン管理、変更フィード、ポイントインタイム復元、ファイル共有ソフト削除、スナップショット)については、 関連するセキュリティ記事の対応するサブ記事をご覧ください。

  • 復旧要件に合った適切な冗長性オプションを選択してください:ジオ冗長ストレージ(GRS/RA-GRS/GZRS/RA-GZRS)はペアリージョンにデータを複製し、顧客主導のフェイルオーバーをサポートしてリージョンのレジリエンスを実現します。 ゾーン冗長ストレージ(ZRS/GZRS)は、リージョン内のゾーンレベルの障害から保護します。 詳細については、「Azure Storage の冗長性」を参照してください。

  • ランサムウェア対策にジオ冗長性に頼らないでください:ジオ冗長レプリケーションはデータや破損、悪意ある削除をペアの領域にミラーリングします。 GRSを不変性ポリシー、ソフト削除、バージョン管理と組み合わせてランサムウェアや改ざん防止を図る。 詳細については、Azure Storageのデータ保護機能をご覧ください。

  • 顧客主導のフェイルオーバーとフェイルバックを実践する:RA-GRS またはRA-GZRSのアカウントについては、計画的なフェイルオーバー演習を実行し、必要になる前に回復手順を検証しましょう。 詳細については、「ディザスター リカバリーとストレージ アカウントのフェールオーバー」を参照してください。

各Azure Storageデータサービスに特有のセキュリティガイダンスについては、以下をご覧ください:

次のステップ

  • 最終更新: