Microsoft Defender for Storage は、Azure Storage の不審アクセス検知だけでなく、マルウェアスキャン、機密データを含むコンテナーへの脅威検知、自動修復までをまとめて扱う Microsoft Defender for Cloud のストレージ保護機能です。2026年6月末時点の公式情報で管理者が最初に確認すべきことは、Defender for Storage classic のまま運用していないか、マルウェアスキャンの上限と自動対応を設計しているか、サブスクリプション単位で新規ストレージアカウントまで保護できているかの3点です。
今回の更新ポイントは、単なる機能紹介ではありません。Azure Blob Storage、Azure Files、Azure Data Lake Storage をグローバルに運用する組織では、アップロードされたファイルの安全性、SAS トークンの悪用、機密データの持ち出し、検知後の隔離までを一連の運用として見直す必要があります。Microsoft Learn の「What is Microsoft Defender for Storage」と、2026年6月30日に更新されたマルウェア検出時の自動修復情報を踏まえ、影響範囲、設定変更、移行期限、管理者が確認すべきポイントを実務目線で整理します。(Microsoft Learn)
Azure の新機能・変更点：「What is Microsoft Defender for Storage」で確認すべきポイント
Microsoft Defender for Storage の位置付けは、従来の「ストレージアカウントに対する脅威検知」から、よりデータ保護寄りに広がっています。公式情報では、Defender for Storage が Azure Blob Storage、Azure Files、Azure Data Lake Storage のデータプレーンとコントロールプレーンのテレメトリを分析し、Microsoft Defender Threat Intelligence、Microsoft Defender Antivirus、Sensitive Data Discovery を使って脅威を検出すると説明されています。(Microsoft Learn)
管理者が押さえるべき要点は、次の通りです。
| 確認項目 | 重要ポイント | 実務での判断基準 |
|---|---|---|
| 保護対象 | Blob、Azure Files、Data Lake Storage を中心に保護 | ファイルアップロード、外部共有、分析基盤、ログ保管先を優先して確認する |
| 有効化スコープ | サブスクリプション単位、ストレージアカウント単位で有効化可能 | 原則はサブスクリプション単位。例外だけ個別除外または上書きする |
| 主要機能 | アクティビティ監視、機密データ脅威検出、マルウェアスキャン、自動対応 | 検知だけでなく「隔離・削除・通知」まで設計する |
| コスト管理 | 新プランは保護するストレージアカウント数を軸にし、マルウェアスキャンはスキャン容量課金 | 高頻度アップロード環境では月間上限、除外フィルター、ログ出力先を先に決める |
| classic からの移行 | 新機能は新しい Defender for Storage プランが前提 | classic のままではマルウェアスキャンや機密データ脅威検出を使えない場合がある |
特に重要なのは、Defender for Storage を「有効にするかどうか」だけで判断しないことです。2026年時点では、どのスコープで有効化し、どの機能をオンにし、どの結果をどこへ送信し、悪性ファイルをどう扱うかまでが設計対象になります。
Microsoft Defender for Storage とは
Microsoft Defender for Storage は、Microsoft Defender for Cloud の Defender プランの一つです。Azure Storage に対する不審な操作、悪性ファイルのアップロード、機密データへの怪しいアクセス、データ破壊や持ち出しの兆候を検出するために使います。
よくある誤解は、「ストレージアカウントのネットワーク制御や RBAC を設定していれば不要」というものです。ネットワーク制御や IAM はアクセスを制限する仕組みですが、Defender for Storage はアクセス後の異常行動や脅威の兆候を検出する役割を持ちます。たとえば、正規の資格情報が漏えいした場合、許可された経路からアクセスされるため、ファイアウォールだけでは検知が難しいケースがあります。
Defender for Storage がカバーする代表的なリスクは次の通りです。
| リスク | 具体例 | Defender for Storage で期待できること |
|---|---|---|
| 悪性ファイルの混入 | ユーザー投稿機能にランサムウェアや不正スクリプトがアップロードされる | マルウェアスキャンで検出し、アラートや自動修復につなげる |
| 機密データの持ち出し | 個人情報や契約書を含む Blob コンテナーへ不審なアクセスが発生する | 機密データの文脈を含めてアラートの優先度判断を支援する |
| SAS トークンの悪用 | 過度に広い権限や長すぎる有効期限の SAS が漏えいする | ID を持たないアクセス主体の不審な操作を検出する |
| データ破壊 | 大量削除、異常な変更、普段と違う操作パターンが発生する | アクティビティ監視により通常と異なる動きを検知する |
| 公開設定ミス | 匿名アクセス可能なコンテナーからデータが参照される | 公開状態や不審なアクセスを検知し、対応を促す |
Defender for Storage の強みは、エージェントレスで導入できる点です。サーバーにセンサーを入れるタイプのセキュリティ製品ではなく、Azure ネイティブのテレメトリや関連サービスを使って保護するため、既存アプリケーションへの変更を最小限に抑えやすい構成です。(Microsoft Learn)
2026年6月末時点で注目すべき更新ポイント
アクティビティ監視は「ログ収集の代替」ではなく脅威検知の基盤
Defender for Storage のアクティビティ監視は、保護対象のストレージアカウントに対するデータプレーンとコントロールプレーンの動きを継続的に分析します。公式情報では、Defender for Storage を有効化しても、セキュリティ上の利点を得るためにリソースログを別途オンにする必要はないと説明されています。(Microsoft Learn)
ただし、これは「監査ログが不要」という意味ではありません。セキュリティアラートの検知には Defender for Storage の仕組みが使えますが、内部監査、長期保存、独自の KQL 分析、証跡提出が必要な組織では、Log Analytics や SIEM への連携を別途設計する必要があります。
実務では次のように分けると判断しやすくなります。
| 目的 | 必要な設計 |
|---|---|
| 不審操作を検知したい | Defender for Storage のアクティビティ監視を有効化 |
| 悪性ファイルを検出したい | マルウェアスキャンを有効化 |
| すべてのスキャン結果を監査証跡として残したい | Log Analytics への出力を検討 |
| アラートを SOC で一元管理したい | Microsoft Sentinel や外部 SIEM への連携を検討 |
| 悪性ファイルを即時隔離したい | Soft delete、Event Grid、Logic Apps、Functions を組み合わせる |
マルウェアスキャンはオンアップロードとオンデマンドの使い分けが重要
Defender for Storage のマルウェアスキャンは、Microsoft Defender Antivirus を使ってストレージ内のコンテンツをスキャンする機能です。公式情報では、アップロード時に自動スキャンするオンアップロードスキャンと、既存の Blob やファイルを必要に応じて手動スキャンするオンデマンドスキャンが説明されています。(Microsoft Learn)
オンアップロードスキャンは、Web アプリケーション、顧客からのファイル受け取り、パートナー連携、社外共有用のアップロード領域に向いています。一方、オンデマンドスキャンは、既存データの棚卸し、監査前の確認、インシデント対応中の再確認、アーカイブ前の安全確認に向いています。
| スキャン方式 | 向いている場面 | 注意点 |
|---|---|---|
| オンアップロードスキャン | 新規アップロードを入口で検査したい場合 | 高頻度アップロードではコスト上限とスループットを確認する |
| オンデマンドスキャン | 既存データを任意のタイミングで検査したい場合 | 大量データを一括スキャンする前に対象範囲を絞る |
| Blob index tags | アプリケーションがスキャン結果を見て処理可否を判断したい場合 | 階層型名前空間が有効なストレージアカウントでは index tags に制約がある |
| Event Grid | 低遅延で自動処理したい場合 | Event Grid トピックのネットワーク構成と権限を確認する |
| Log Analytics | 監査・検索・レポート用途 | すべてのスキャン結果を保存する場合はログコストも考慮する |
マルウェアスキャンには制限もあります。公式情報では、50GB を超える Blob はスキャンできないエラー例が示されており、オンアップロードスキャンはストレージアカウントごとに処理容量の考慮が必要です。アップロード量が継続的に上限を超える場合、一部の Blob がスキャンされない可能性があります。(Microsoft Learn)
悪性 Blob の自動修復は運用設計に直結する
2026年6月30日に更新された公式情報では、マルウェア検出後の対応として、組み込みの自動修復、悪性ファイルの移動または削除、クリーンなファイルだけを別の場所へ移すワークフローが整理されています。Defender for Storage は、オンアップロードまたはオンデマンドのマルウェアスキャンで悪性 Blob を検出した場合、組み込み機能により soft delete を開始して安全に隔離し、調査や復旧のために回復可能な状態を保てます。(Microsoft Learn)
これは、運用上かなり重要な変更点です。従来のように「アラートを見て人が削除する」運用では、夜間や休日に悪性ファイルがダウンロードされるリスクが残ります。自動修復を使えば、検知後すぐにアクセスを止める設計に近づけられます。
ただし、すべての環境で即時削除が正解とは限りません。証跡保全やフォレンジックが必要な組織では、削除ではなく隔離用コンテナーや専用ストレージアカウントへ移動する設計が適しています。Microsoft Learn では、Event Grid、Function App、Logic App、Blob index tags、Defender for Cloud のセキュリティアラートを使った自動対応が案内されています。(Microsoft Learn)
| 対応方針 | 向いている組織 | 実装例 |
|---|---|---|
| 組み込み soft delete | まず悪性ファイルの利用を止めたい組織 | 悪性 Blob を soft delete し、保持期間内に調査 |
| 隔離用ストレージへ移動 | SOC や CSIRT が検体を調査する組織 | Event Grid と Function App で quarantine コンテナーへ移動 |
| 自動削除 | 調査より拡散防止を優先する一時領域 | Logic App または Function App で削除。ただし soft delete を有効化 |
| クリーンファイルだけ転送 | 外部アップロードを業務システムへ取り込む環境 | DMZ 用ストレージでスキャン後、問題ないファイルだけ本番領域へコピー |
| 未スキャンファイルをブロック | ファイル処理前に検査結果を必須にしたい環境 | ABAC やアプリ側チェックで scan result を確認 |
機密データ脅威検出は Purview との整合性が鍵
Sensitive data threat detection は、機密データを含むリソースへの不審アクセスや露出イベントを優先的に扱いやすくする機能です。公式情報では、この機能が新しい Defender for Storage プランの構成可能な機能であり、Microsoft Purview の機密情報の種類や秘密度ラベルと統合できると説明されています。(Microsoft Learn)
実務で重要なのは、Defender for Storage 側だけを見ないことです。すでに Microsoft Purview で秘密度ラベルや機密情報の種類を設計している組織では、Defender for Storage のアラートに反映される分類が、自社のデータ分類ルールと合っているか確認する必要があります。
たとえば、次のような運用が考えられます。
| データ分類 | 想定される検知後の扱い |
|---|---|
| 個人情報を含むコンテナー | 不審アクセスは高優先度で SOC に通知 |
| 契約書・見積書 | 外部 IP や Tor 経由のアクセスを重点監視 |
| 一般公開用ファイル | 機密データ検出の対象外または低優先度 |
| 開発・検証用データ | 誤検知と本番データ混入の両方を確認 |
| ログ保管領域 | 大量アクセスや不審な列挙操作を監視 |
Sensitive data threat detection は有効化すれば終わりではありません。アラートに表示される機密性の文脈を、SOC の優先度付け、チケット分類、インシデント対応手順に組み込むことで効果が出ます。
影響範囲：どの Azure 環境が確認対象になるか
Defender for Storage の影響範囲は、単一のストレージアカウントにとどまりません。サブスクリプション単位で有効化すると、既存および新規作成されるストレージアカウントが自動的に保護対象になります。特定のストレージアカウントを除外したり、個別設定で上書きしたりすることもできます。(Microsoft Learn)
特に確認すべき環境は次の通りです。
- 外部ユーザーや顧客がファイルをアップロードする Blob Storage
- Web アプリケーションや SaaS の添付ファイル保管先
- Azure Data Lake Storage Gen2 を使う分析基盤
- Azure Files を業務ファイル共有として使う環境
- Databricks、Synapse、ETL 処理などのデータパイプライン周辺
- 長期保管用のアーカイブ領域
- グローバル拠点や複数リージョンにまたがるサブスクリプション
- 過去に Defender for Storage classic を有効化したままのサブスクリプション
サポート対象にも注意が必要です。公式の前提条件では、Activity Monitoring、Sensitive Data Discovery、オンアップロードマルウェアスキャン、オンデマンドマルウェアスキャンごとにサポートされるストレージ種別が異なります。たとえば、Azure Blob Standard、Azure Blob Premium v2、Azure Data Lake Storage Gen2 は複数機能の対象ですが、NFS 3.0 や Azure Files の一部構成では機能制限があります。AWS S3 バケットは Defender for Storage で直接サポートされず、AWS GuardDuty の検出結果を Microsoft Sentinel で取り込む構成が案内されています。(Microsoft Learn)
グローバル企業では、リージョンやクラウド環境ごとの対応状況、データレジデンシー、運用チームの分掌も合わせて確認してください。マルウェアスキャンはストレージアカウントと同じ Azure リージョンで処理され、スキャン済みファイルはサービス側に保持されないと説明されています。(Microsoft Learn)
設定変更で確認すべき項目
Defender for Storage の設定変更では、「プランをオンにする」だけでは不十分です。少なくとも次の項目を確認してください。
| 設定項目 | 推奨される確認内容 | 失敗しやすいポイント |
|---|---|---|
| 有効化スコープ | サブスクリプション単位を基本にし、例外だけ個別設定 | 個別アカウントだけ有効化して新規作成分が漏れる |
| Azure Policy | 管理グループまたはサブスクリプションにポリシーを割り当てる | 旧 classic 用ポリシーが残り、新プランと競合する |
| マルウェアスキャン | オンアップロードを有効化するか、オンデマンドも使うか決める | 大量アップロード環境でコスト上限を設定しない |
| 月間スキャン上限 | 既定値、業務量、ピーク時アップロードを確認 | 上限到達後の未スキャンファイルを運用で見落とす |
| 除外フィルター | ログ、テンポラリ、再生成可能ファイルを除外するか検討 | 除外しすぎて本当に危険な領域までスキャン対象外にする |
| Blob index tags | アプリが結果を参照するか確認 | HNS 有効環境など制約を見落とす |
| Event Grid | 悪性・未スキャン・正常結果をどう処理するか決める | プライベートエンドポイント専用の Event Grid トピックに送れない |
| Log Analytics | 監査・証跡・レポート用途で必要か確認 | すべて保存してログコストが増える |
| Soft delete | 悪性 Blob の自動隔離に使うか決める | 保持期間や復旧手順を決めないまま有効化する |
公式情報では、Azure portal でサブスクリプション単位に有効化した場合、オンアップロードマルウェアスキャンと Sensitive data threat detection が含まれ、必要に応じて機能のオフ、スキャン容量上限、Blob index tags、悪性 Blob の soft delete、Event Grid、Log Analytics などを変更できるとされています。(Microsoft Learn)
コスト管理：月間上限と追加課金を先に設計する
Defender for Storage のコストで見落としやすいのは、プラン料金だけではありません。新しい Defender for Storage プランは、保護するストレージアカウント数を軸にした予測しやすい課金体系として説明されていますが、マルウェアスキャンはスキャンされたデータ量に応じて課金されます。また、高トランザクションのストレージアカウントでは追加料金が発生する可能性があります。(Microsoft Learn)
マルウェアスキャンには月間上限を設定できます。公式情報では、既定の上限はストレージアカウントごとに月間 10,000GB とされ、上限を超えるとその月の残りの Blob スキャンが停止します。上限到達には最大 20GB の誤差幅があると説明されています。(Microsoft Learn)
コスト設計では、次の順で見積もると実務に落とし込みやすくなります。
| 手順 | 確認内容 | 判断例 |
|---|---|---|
| アップロード量を把握 | 1日・1か月あたりの新規 Blob 量を確認 | 顧客アップロード領域は高め、ログ領域は除外を検討 |
| スキャン対象を分類 | 必須、任意、除外可能に分ける | 実行ファイル、圧縮ファイル、外部由来ファイルを優先 |
| 上限を設定 | ストレージアカウント単位またはサブスクリプション単位で設定 | 重要システムは高め、検証環境は低め |
| アラートを監視 | 75% 到達、上限到達の通知を運用に入れる | 上限到達時は未スキャンファイルの扱いを決める |
| 追加コストを確認 | Storage read、Blob index、Event Grid、Log Analytics を含める | 大量スキャン環境では PoC で実測する |
特に、外部から大量ファイルを受け取るサービスやデータ移行期間中は注意が必要です。スキャン上限に達すると、その月の残りは新しいアップロードがスキャンされない可能性があります。これはコスト抑制としては有効ですが、セキュリティ要件によっては業務リスクになります。
移行期限：Defender for Storage classic はどう扱うべきか
Defender for Storage classic を使っている環境では、移行確認が必須です。Microsoft Learn では、新しい Defender for Storage プランが 2023年3月28日に導入され、拡張されたアクティビティ監視、SAS トークンの悪用検知、機密データ脅威検出、マルウェアスキャン、予測しやすいストレージアカウント単位の価格、リソースレベルの細かな制御が新プランの利点として説明されています。(Microsoft Learn)
重要な日付は 2025年2月5日 です。公式情報では、この日以降、legacy per-transaction pricing plan である Defender for Storage classic は、多くのシナリオで新たに有効化できません。例外は、すでに per-transaction pricing が有効なサブスクリプションです。また、新プランへ切り替えると classic の per-transaction または per-storage account プランへ戻せないと説明されています。(Microsoft Learn)
2026年時点での実務上の捉え方は、次の通りです。
| 状況 | 管理者の対応 |
|---|---|
| 新規サブスクリプションで classic を使いたい | 原則として新規有効化はできない前提で新プランを設計する |
| 既存サブスクリプションで classic が有効 | すぐ停止するとは限らないが、新機能・新価格の利用には移行が必要 |
| 旧ポリシーで classic を強制している | 新プラン用ポリシーへ置き換え、競合や失敗を確認する |
| classic で除外設定を使っている | 新プラン移行時に除外が自動継承されない点を確認する |
| 移行後に戻したい | 原則戻せないため、事前にコスト・除外・機能設定を検証する |
特に注意したいのは、classic で除外していたストレージアカウントが、新プラン移行後に自動的には除外されない点です。公式情報でも、Defender for Storage classic の除外ストレージアカウントは、新プランへ移行しても自動的に除外されないと説明されています。(Microsoft Learn)
管理者が実施すべき確認手順
現在のプランと設定を棚卸しする
最初に、サブスクリプションごとの Defender for Storage の状態を確認します。Azure Resource Graph Explorer、PowerShell、Workbook を使い、現在のプラン、マルウェアスキャンの有効状態、スキャン上限、Sensitive Data Discovery の有効状態を一覧化します。Microsoft Learn では、プラン状態を確認する KQL クエリも案内されています。(Microsoft Learn)
実務では、次のような観点で棚卸ししてください。
securityresources
| where type == "microsoft.security/pricings"
| where name == "StorageAccounts"
| extend pricingTier = properties.pricingTier
| extend DefenderForStoragePlan = properties.subPlan
| extend MalwareScanningEnabled = properties.extensions[0].isEnabled
| extend MalwareScanningCapping = properties.extensions[0].additionalExtensionProperties["CapGBPerMonthPerStorageAccount"]
| extend SensitiveDataDiscoveryEnabled = properties.extensions[1].isEnabled
| project subscriptionId, pricingTier, DefenderForStoragePlan, MalwareScanningEnabled, MalwareScanningCapping, SensitiveDataDiscoveryEnabledこの結果を、サブスクリプション所有者、ストレージアカウント所有者、業務システム名、データ分類、リージョンと紐づけると、移行や設定変更の優先順位を決めやすくなります。
サブスクリプション単位で有効化し、例外を個別管理する
Microsoft は、Defender for Storage の有効化方法として Azure built-in policy を推奨しています。ポリシーを使うことで、既存および将来作成されるストレージアカウントに一貫した設定を適用しやすくなります。(Microsoft Learn)
ただし、すべてを一律設定にすると運用上の問題が出る場合があります。たとえば、ログ専用ストレージ、短命の検証用ストレージ、極端に高頻度な一時ファイル領域では、マルウェアスキャンの除外や低い上限が必要になることがあります。
おすすめの設計は次の通りです。
| レイヤー | 設計方針 |
|---|---|
| 管理グループ | 基本方針を Azure Policy で定義 |
| サブスクリプション | Defender for Storage を原則有効化 |
| ストレージアカウント | 業務要件に応じて上限、除外、Event Grid、Log Analytics を調整 |
| コンテナー・Blob | アプリ側でスキャン結果を確認する場合に index tags や ABAC を活用 |
| SOC 運用 | Defender for Cloud、Sentinel、チケットシステムへ連携 |
マルウェア検出後の処理を先に決める
Defender for Storage を導入しても、アラートを誰も見ない、または対応手順が決まっていない状態では効果が限定されます。マルウェア検出後は、少なくとも次の判断を事前に決めてください。
| 判断項目 | 選択肢 |
|---|---|
| 悪性ファイルの扱い | soft delete、隔離、削除、アクセスブロック |
| 調査担当 | SOC、CSIRT、クラウド運用、アプリ担当 |
| 通知先 | Defender for Cloud、Sentinel、Teams、ServiceNow、メール |
| 証跡 | Defender アラート、Event Grid、Log Analytics、チケット |
| 復旧 | soft delete からの復元、隔離領域からの再分析、誤検知申請 |
悪性ファイルの自動削除を行う場合でも、soft delete を有効化しておくと誤検知や調査に対応しやすくなります。公式情報でも、自動削除や移動の前提として soft delete を使う考え方が示されています。(Microsoft Learn)
アプリケーション側で「未スキャン」を扱えるようにする
実務で見落としやすいのが、スキャンが完了する前にアプリケーションがファイルを処理してしまう問題です。マルウェアスキャンは近リアルタイムですが、アップロード直後に短い時間差が発生する可能性があります。Microsoft Learn では、アプリケーションやデータフローがスキャン結果を意識し、スキャン完了後に適切な処理を行う設計が案内されています。(Microsoft Learn)
たとえば、ユーザーがアップロードした請求書 PDF を業務システムが自動処理する場合、次のような流れにします。
- ユーザーは DMZ 用ストレージアカウントへアップロードする
- Defender for Storage がオンアップロードスキャンを実行する
- Event Grid または Blob index tags で結果を確認する
No threats foundのファイルだけ本番処理用コンテナーへ移動するMaliciousまたはNot scannedは隔離・保留・通知の対象にする
この設計により、「スキャンはしているが、結果が出る前に処理してしまう」という穴を減らせます。
よくある失敗と回避策
classic のまま新機能を期待してしまう
Defender for Storage classic では、新しい Defender for Storage プランで提供されるマルウェアスキャンや Sensitive data threat detection などを利用できない、または制限される場合があります。classic 環境では、まず現在のプランを棚卸しし、新プランへの移行可否、コスト、除外設定、ポリシーを確認してください。
月間スキャン上限を設定せずに大量アップロードする
マルウェアスキャンはセキュリティ上有効ですが、スキャン容量に応じた課金が発生します。外部ファイル受け取り、画像・動画投稿、データ移行、バックアップ投入のような大量アップロードでは、想定外のコストや上限到達が起きやすくなります。まず小さな範囲で PoC を行い、実測値をもとに上限を決めるのが安全です。
除外フィルターを広く設定しすぎる
ログや一時ファイルを除外するのは合理的ですが、/uploads/ や .zip のような重要領域を安易に除外すると、攻撃者にとって都合のよい抜け道になります。除外は「再生成可能」「外部公開されない」「実行・配布されない」などの条件を満たす領域に限定してください。
Event Grid のネットワーク制約を見落とす
マルウェアスキャン結果を Event Grid に送って Function App で処理する場合、Event Grid トピックのネットワーク構成が重要です。公式情報では、Defender for Storage からのマルウェアスキャンイベントについて、プライベートエンドポイントのみを受け付ける Event Grid トピックでは受信できず、パブリック IP からのアクセスを許可する必要があると説明されています。(Microsoft Learn)
権限不足で設定や修復が失敗する
Defender for Storage の機能ごとに必要な権限は異なります。公式の前提条件では、アクティビティ監視、マルウェアスキャン、Sensitive-data threat detection について、サブスクリプションレベルとストレージアカウントレベルで必要な権限が整理されています。たとえば、マルウェアスキャンや Sensitive-data threat detection の構成には Subscription Owner または指定されたアクションセットが必要です。(Microsoft Learn)
セキュリティチームが設計し、クラウド基盤チームが実装し、アプリチームがストレージを所有している組織では、権限分掌の整理が導入の成否を分けます。
グローバル運用でのチェックリスト
グローバル環境では、単一リージョンや単一サブスクリプションの検証だけでは不十分です。次のチェックリストで抜け漏れを確認してください。
| 項目 | 確認内容 |
|---|---|
| サブスクリプション網羅性 | すべての本番・検証・共有基盤サブスクリプションを棚卸ししたか |
| classic 利用有無 | Defender for Storage classic が残っていないか |
| 新規作成対策 | Azure Policy で将来作成されるストレージも保護できるか |
| データ分類 | 機密データを含むコンテナーを把握しているか |
| リージョン | データ所在地とスキャン処理の要件を満たしているか |
| コスト | スキャン量、上限、追加サービス費用を見積もったか |
| 自動対応 | 悪性、未スキャン、エラーの処理を定義したか |
| SOC 連携 | Defender for Cloud、Sentinel、外部 SIEM、チケットへつながるか |
| 例外管理 | 除外ストレージアカウントと除外理由を記録しているか |
| テスト | アップロード、検知、通知、隔離、復旧まで通しで検証したか |
特に多国籍企業では、機密情報の分類ルールが国や部門で異なることがあります。Microsoft Purview の秘密度ラベルや SIT の設計と Defender for Storage の検知文脈をそろえておくと、SOC がアラートを見たときに「どの国の、どの種類のデータが、どの程度危険か」を判断しやすくなります。
まとめ：次に取るべきアクション
Microsoft Defender for Storage の更新ポイントは、Azure Storage の脅威検知を「有効化するだけ」から、「データの種類、マルウェアスキャン、コスト、検知後の自動修復まで設計する」段階へ進んでいることです。特に、2026年6月30日更新の自動修復情報では、悪性 Blob の soft delete、Event Grid、Logic Apps、Function Apps、クリーンファイルだけの転送など、検知後の実装パターンがより明確になっています。(Microsoft Learn)
管理者が今すぐ行うべきことは、次の順番です。
- Azure Resource Graph や Workbook で Defender for Storage の現状を棚卸しする
- Defender for Storage classic が残っていれば、新プラン移行の影響を確認する
- サブスクリプション単位の有効化を基本に、Azure Policy で新規アカウントも保護する
- マルウェアスキャンの月間上限、除外フィルター、Event Grid、Log Analytics を設計する
- 悪性ファイルの soft delete、隔離、削除、通知の運用を決める
- 機密データ脅威検出と Microsoft Purview の分類ルールを合わせる
- 本番適用前に、アップロードから検知、通知、隔離、復旧までテストする
Defender for Storage は、ストレージアカウントを守るための単独機能ではなく、Azure のデータ保護運用を強化するための基盤です。まずは classic の有無と高リスクなアップロード領域を確認し、重要なストレージから段階的に新プラン、マルウェアスキャン、自動修復を適用していくのが現実的です。
コメント