Azure Blob Storage を保護する

Azure Blob Storageは大量の非構造化オブジェクトデータをコンテナに保存します。 しばしば流出、ランサムウェア、公衆への曝露事件の標的となります。 この記事では、blobコンテナ、blobs、およびAzure Data Lake Storageの階層的名前空間に関するセキュリティ推奨事項を提供します。

注

この記事では、Azure Blob Storageに特有のセキュリティ実践について解説します。 アカウントレベルのセキュリティガイダンスについては、「Secure your Azure Storage account」をご覧ください。

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

  • Azure Front Door でカスタム ドメイン、静的 Web サイト、および一般公開される BLOB コンテンツを配信する: Azure Front Door でマネージド証明書を使用して TLS を終端し、WAF を有効にして、ストレージ アカウントのパブリック ネットワーク アクセスを制限し、Azure Front Door のみがオリジンにアクセスできるようにします。 Azure Storage独自のカスタムドメイン機能はマネージドTLS証明書をサポートしていませんが、Front Doorは匿名コンテナアクセスにはないWAF保護、レート制限、ログ機能を追加しています。 詳細については、「Use Azure Front Door with Azure Storage blobs」をご覧ください。

  • 使用していないときは静的ウェブサイトエンドポイントを無効にする:静的ウェブサイト機能が有効になっている間、$webコンテナは公開的に読み取れたままであり、たとえallowBlobPublicAccessfalseされていてもです。 不要なアカウントのウェブサイト静的機能を無効にしてください。 詳細については、「Azure Storage での静的 Web サイト ホスティング」を参照してください。

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

匿名公開アクセス

  • ストレージアカウントで匿名のパブリック読み取りを無効にする: allowBlobPublicAccess プロパティを false に設定し、コンテナレベルの設定に関わらずアカウント内のどのコンテナもパブリックになれないようにします。 詳細については、「概要: BLOB データの匿名読み取りアクセスの修復」を参照してください。

  • 既存の匿名アクセスの監査と修復:「 Remediate annonymous read access to blob data」 のガイダンスを用いて、公開アクセスを許可するコンテナを見つけ、プライベートアクセスや明示的なSASベースの共有に変換してください。

ブロブレベルのSASおよびABAC

  • ブロブアクセスにおいてサービスSASよりユーザー委任SASを優先する:ユーザー委任共有アクセス署名(SAS)はMicrosoft Entra認証で署名されます。 ユーザー委任キーを取り消すと、そこから発行されたすべてのSASが即座に無効になり、サービスやアカウントSASにはない取り消しパスが提供されます。 詳細については、「ユーザー委任 SAS を作成する」を参照してください。

  • サービスSASをストレージアクセスポリシーで取り消し可能にする:サービスSASを使用する必要がある場合は、コンテナ上のストアアクセスポリシーと関連付けてください。 その後、ポリシーを修正または削除して、参照するすべてのSASを取り消すことができます。 ポリシーがなければ、サービスのSASはアカウントキーをローテーションすることでのみ取り消され、これはアカウント内の他のすべてのSASに影響します。 詳細については、「保存されているアクセス ポリシーの定義」を参照してください。

  • ABAC経由でアクセスを条件付けるためにブロブインデックスタグを使う:ブロブインデックスタグと属性ベースのアクセス制御(ABAC)条件を組み合わせて、特定のタグ値を持つブロブ(例えば Classification=Public)に読み取りのみアクセスを許可します。 このアプローチにより、単一の役割割り当てで多くの発信者に対応し、機密タグ付きデータへのアクセスを許可しません。 詳細は「 ABAC条件を使ったブロブへのアクセスを許可する」をご覧ください。

データ保護

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

  • サーバーに平文で表示してはならないブロブデータにはクライアント側暗号化を使いましょう。アップロード前にクライアントのブロブコンテンツを暗号化してください。 SDKは鍵管理のためにAzure Key VaultやManaged HSMと連携します。 サービス側のCMKと組み合わせてレイヤー保護を行ってください。 詳細については、 ブロブのクライアント側暗号化を参照してください。

不変性とWORM

  • 規制対象データに対して時間ベースの保持ポリシーを設定する:コンテナレベルまたはバージョンレベルの時間ベースの保持を適用し、一定期間のブロブの変更や削除を防ぎます。 バージョンレベルの不変性はより細かい制御を提供し、個々のバージョンで有効化または拡張が可能です。 詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。

  • 法的または調査上の必要性による無期限の保留に法的保留を用いましょう:法的保留は、認可ユーザーが明確に保留を解除するまで削除を防ぎ、固定期間はありません。 詳細については、「不変ストレージを使用してビジネスに不可欠な BLOB データを保存する」を参照してください。

  • 保持ポリシーをロックして変更不能にする:適切な権限を持つユーザーは、解除された保持ポリシーを短縮または削除できます。 このポリシーをロックすると、保持期間は一方通行のコミットメントとなります。 契約期間を検証した後にのみロックしてください。 詳細については、「 コンテナの不変性ポリシーの設定」を参照してください。

オブジェクトの複製およびコピー操作

  • オブジェクトのレプリケーションを管理するソースアカウントに制限する:先アカウントの許可されたソースアカウントリストを設定し、既知で信頼できるソースアカウントのみがデータをプッシュできるようにします。 詳細については、「 オブジェクト レプリケーションの構成」を参照してください。

  • テナント間のオブジェクト レプリケーションを防止する: ソース アカウントと宛先アカウントが別々の Microsoft Entra テナントに属するレプリケーション ポリシーを禁止します。 この制限により、認可されたユーザーが外部テナントへのレプリケーション設定をできません。 詳細については、「 Microsoft Entra テナント間でのオブジェクト レプリケーションの防止」を参照してください。

  • コピー操作の許容範囲を制限する:同じテナントまたは同じサブスクリプション内の送信元アカウントからのみコピー操作を許可するように設定します。 この設定は、プライベートアカウントから攻撃者が管理するアカウントへのコピーという共通の流出経路をブロックします。 詳細はコピー 操作の許可範囲を参照してください。

バックアップと回復

  • 書き込み・削除時に前バージョンを保持するためにブロブバージョン管理を有効にする:バージョン管理を有効にすると、書き込みや削除操作ごとに新しいバージョンが作成され、前の状態が保持されます。 バージョンをアドレス指定して復元することができます。 詳細については、「BLOB のバージョン管理」を参照してください。

  • ブロブとコンテナのソフト削除を有効にする:ソフトデリットは削除されたブロブやコンテナを一定の保持期間保持し、その期間中に復元できます。 コンテナレベルとブロブレベルのソフト削除を別々に設定し、両方を有効にしてください。 詳細は、 ブロブの場合はソフトデリット 、 コンテナについてはソフトデリットをご覧ください。

  • ブロックブロブアカウントのポイントインタイム復元を有効にする:ポイントインタイム復元はバージョン設定とソフト削除を組み合わせて、ブロックブロブの範囲を特定の過去のタイムスタンプに復元します。 この機能はランサムウェアの復旧に役立ちます。 ポイントインタイム リストアを使用するには、バージョン管理、BLOB の論理的な削除、変更フィードを有効にする必要があります。 詳細については、「ブロック BLOB のポイントインタイム リストア」を参照してください。

  • 監査およびフォレンジックのために変更フィードを有効にする:変更フィードは、アカウント内のブロブの変更をすべて順序付けられ変更できないログです。 ポイントインタイム復元を可能にするだけでなく、調査のための耐久性ある監査記録を提供します。 詳細については、Azure Blob Storage での Change フィードのサポートに関する記事を参照してください。

Azure Data Lake Storage

Data Lake Storageは階層的な名前空間とPOSIXに似たアクセス制御リスト(ACL)をBlob Storageに追加します。 ACLとRBACは連携して動作し、RBACを通じて粗いアクセスを許可し、ACLでファイルシステム内で精錬します。

  • 粗粒度アクセスにはRBAC、細粒度アクセスにはACLを使いましょう:コンテナレベルやアカウントレベルで組み込みのブロブRBACロールを割り当て、広範なアクセスを許可します。 次に、ディレクトリやファイルにACLを使ってコンテナ内のアクセスを制限します。 コンテナ全体でユーザーが必要とする権限をACLだけに使わないでください。 RBACは評価と監査の効率が高まります。 詳細については、「 Azure Data Lake Storage のアクセス制御モデル」を参照してください。

  • 新しい子項目の権限を継承するためにディレクトリにデフォルトのACLを適用する:デフォルトのACLはACL設定後に作成されたファイルやディレクトリに適用されます。 個々のファイルのACL管理を避けるために、ディレクトリレベルで設定してください。 詳細については、Azure Data Lake Storageのアクセス制御リストをご覧ください。

  • アカウント作成時に階層的な名前空間を有効にする:既存のアカウントで階層的な名前空間を有効にするには移行が必要です。 もしワークロードがData Lake Storageのセマンティクスを使っていると分かっているなら、後から移行するのではなく、最初に有効にしてください。 詳細については、Azure Data Lake Storage hierarchical namespace をご覧ください。

ログ記録と監視

  • 匿名アクセスを無効にした後の匿名アクセスヒットにアラートを出す:allowBlobPublicAccessをfalseに設定したら、ストレージログをAuthenticationType == "Anonymous"に絞り込み、ヒットがあればアラートを発します。 これらのヒットはクライアントの設定ミスか、プロービングの試みのいずれかを示しています。 詳細については、「Azure Storage を監視する」を参照してください。

  • ストレージマルウェアスキャンの判定を有効化し、Defender行動を起こす:マルウェアスキャンを有効にする際は、MalwareScanningResultの判定に対して自動応答(ブロブ削除、隔離タグ、下流ワークフロー抑制)を設定し、特定された悪意のあるブロブが消費者に提供されないようにします。 詳細については、Defender for Storageの「マルウェアスキャンへの対応」結果をご覧ください。

  • 分類ドリフトのためのブロブインデックスタグ変異を追跡する:ブロブインデックスタグを使ってABACアクセス条件を駆動すると、タグの変更がブロブを読むことができる人たちが直接変わります。 機密性の高いコンテナーに対する SetBlobTags 操作をログに記録し、アラートを生成します。 詳細については、「Azure Blob Storage のデータを blob index tags で管理および検索する」をご覧ください。

次のステップ

  • 最終更新: