Microsoft Defender for Storage: Hədəfli on-demand malware scanning və Avqust təhlükəsizlik dəyişiklikləri

Microsoft Defender for Cloud-un rəsmi Avqust 2026 release notes-u dörd əsas dəyişiklik göstərir: 6 avqustda Defender for Storage on-demand malware scanning üçün targeted scanning public preview-a çıxıb; eyni tarixdə AWS/GCP CIEM overprovisioned identity assessments-dən “unused actions” məlumatının çıxarılması ilə breaking change edilib; 17 avqustda classic Defender for SQL API-lərinin retirement-i elan olunub; 21 avqustda vulnerability CVE detail-lərinin Azure Resource Graph-da necə əldə olunması dəyişib.

Bu məqalənin əsas mövzusu Defender for Storage yeniliyidir. Əvvəl on-demand scan bütün storage account üzrə mövcud blob və file-ləri skan edə bilirdisə, Avqust public preview-i REST API request body-də filter verməklə skanı bir konkret blob/fayl, bir container/file share və ya path prefix-ə uyğun obyektlər ilə məhdudlaşdırmağa imkan verir. Filter verilmədikdə əvvəlki davranış saxlanılır və bütün storage account skan edilir.

Bu kiçik görünən API dəyişiklik əslində SecOps workflow-ları üçün əhəmiyyətlidir. Incident response komandası bir təhlükəli fayl şübhəsinə görə çoxterabaytlıq storage account-u yenidən skan etmək əvəzinə yalnız əlaqəli object və ya container-i yoxlaya bilər. Eyni yanaşma əvvəllər scan olunmamış legacy data, failed scan retry, false-negative investigation və compliance verification üçün istifadə edilə bilər. Microsoft məhz security-event response, targeted investigation, failed-scan retry, compliance, recurring scan və security baseline yaradılmasını on-demand scanning-in əsas ssenariləri arasında göstərir.

Scanning Microsoft Defender Antivirus-un aktual malware definitions bazasından istifadə edir və əlavə scanning VM/agent infrastrukturu tələb etməyən cloud-native modeldir. On-demand scanning mövcud saxlanılmış data üzərində işlədiyi üçün Defender aktivləşdirilməmişdən əvvəl upload edilmiş data-nı və ya yeni threat intelligence səbəbindən yenidən yoxlanması lazım olan obyektləri əhatə etmək üçün əlverişlidir.

Əsas Texniki Dəyişikliklər və Düzəlişlər

Targeted scanning-in əsas primitive-i filters object-idir. Filter daxilində blobs və/və ya files verilə bilər. Object path üçün value, matching behavior üçün isə Exact və ya Prefix istifadə olunur; match verilməzsə default Exact-dır. Blob path formatı container/blob-path, Azure Files formatı isə share/path şəklindədir. Matching case-sensitive-dir.

Filter semantikasında mühüm operational detail var. Yalnız blob filter-i verilsə file share-lər scan edilmir; yalnız file filter-i verilsə blob-lar scan edilmir. Heç bir object filter-ə uyğun gəlməzsə əməliyyat failure yox, uğurlu şəkildə zero scanned items ilə tamamlanır. Filter tamamilə buraxılarsa storage account-dakı bütün uyğun blobs və files scan edilir. Buna görə avtomatlaşdırmada “HTTP success” scan scope-un həqiqətən tapıldığını sübut etmir; totalBlobsScanned / totalFilesScanned kimi result metrics də validation gate olmalıdır.

On-demand scan başlamazdan əvvəl Defender for Storage və on-upload malware scanning subscription və ya individual storage-account səviyyəsində aktiv olmalıdır. Built-in Security Admin rolu scan idarə edə bilər. Least-privilege custom role modelində Microsoft üç əsas action göstərir: Microsoft.Security/defenderForStorageSettings/startMalwareScan/action, Microsoft.Security/defenderForStorageSettings/malwareScans/read və Microsoft.Security/defenderForStorageSettings/malwareScans/cancelMalwareScan/action. Bu, SecOps automation identity-ni geniş Owner/Contributor səlahiyyətindən ayırmaq üçün əhəmiyyətli control-dur.

Hər storage account üçün eyni anda yalnız bir on-demand scan işləyə bilər. Scan cancellation da bütün lifecycle boyunca mümkün deyil: əməliyyat yalnız ilkin mərhələlərdə dayandırıla bilər; WaitingForCompletion mərhələsinə və ya daha sonrakı vəziyyətə çatdıqdan sonra cancellation dəstəklənmir. Bu məhdudiyyət orchestration layer-də concurrency lock, retry/backoff və idempotency strategiyasını vacib edir.

Scanning prosesi zamanı sistem uyğun blobs/files siyahısını müəyyənləşdirir və onları paralel scanning-ə göndərir. Object-lər scanning zamanı tətbiqlər üçün əlçatan qalır; portal və API scan olunan/skipped object sayı, data volume, malicious object count, status və duration barədə məlumat verir. Böyük object sayı və data həcmi olduqda scan bir neçə dəqiqədən bir neçə saata qədər çəkə bilər.

Result consumption üçün dörd əsas kanal mövcuddur: Blob index tags, Defender for Cloud security alerts, Event Grid və Log Analytics. Default blob tags scan result-u No threats found, Malicious, Error və ya Not scanned kimi, həmçinin scan timestamp-i saxlayır. Lakin Microsoft blob index tags-in tamper-resistant olmadığını açıq bildirir; tag dəyişmə səlahiyyəti olan istifadəçi onları dəyişə bilər. Buna görə yüksək assurance tələb edən workflow-da tag tək security decision source olmamalıdır.

Malicious file aşkarlananda Defender for Cloud security alert yarada bilər və bu alert incident investigation və workflow automation üçün istifadə oluna bilər. Event Grid daha aşağı latency-li event-driven remediation üçün Function App, webhook, Event Hubs və Service Bus consumer-larına nəticə çatdıra bilər. Log Analytics aktivdirsə nəticələr StorageMalwareScanningResults cədvəlində saxlanılır ki, bu da audit, historical investigation və compliance reporting üçün daha məqsədəuyğundur.

Automated remediation layer-də Microsoft soft delete, ABAC vasitəsilə unscanned/malicious content access-in bloklanması, Logic Apps və Functions ilə quarantine/move/delete və clean file-ların downstream storage-a ötürülməsi kimi pattern-ləri dəstəkləyir. Bu, scanning-i passive detector-dan enforcement pipeline-a çevirmək üçün vacibdir.

Avqust ayının Defender üçün digər dəyişiklikləri də workload owner-lar üçün nəzərə alınmalıdır. 21 avqustdan etibarən vulnerability assessment üzrə geniş CVE məlumatının Azure Resource Graph-da microsoft.security/cvedetails resource type-dan alınması nəzərdə tutulur. Köhnə query və API-lər detailed CVE property-ləri assessment record daxilindən gözləyirsə, nəticə artıq gözlənilən detalları qaytarmaya bilər; Microsoft bunun səbəbini query performance, scalability və böyük dataset support-un yaxşılaşdırılması kimi göstərir.

17 avqust elanına əsasən classic Defender for SQL Vulnerability Assessment və Advanced Threat Protection API-ləri 16 avqust 2027 tarixində retire ediləcək. Bu API-lərdən istifadə edən automation, IaC və scripts supported configuration model-ə həmin tarixdən əvvəl miqrasiya etməlidir. Bu, dərhal service outage deyil, lakin 12 aylıq engineering backlog-a daxil edilməli deprecation signal-dır.

6 avqust CIEM dəyişiklikində isə Defender for Cloud AWS və GCP overprovisioned identity recommendations daxilində unused actions siyahısını artıq təqdim etmir. Microsoft bu dəyişikliyi recommendation generation performance/scalability ilə əsaslandırır; həmin siyahıya bağlı workflow-lar isə artıq işləməyəcək. Permission usage analizi tələb olunan mühitlərdə AWS və Google Cloud-un native IAM activity/usage insight-larından istifadə etmək lazımdır.

Praktiki Tətbiq və Konfiqurasiya Nümunələri

Portal üzrə bütün storage account-u scan etmək üçün storage account-a keçib Security + networking → Microsoft Defender for Cloud → On-demand malware scanning bölməsi açılır. Portal əvvəlcə storage capacity/data volume əsasında estimated cost göstərir; sonra Scan storage account for malware əməliyyatı başladılır. Progress səhifəsində status, scanned objects, GB scanned, detected threats və duration izlənə bilir. Microsoft sənədlərinə görə portal statusu təxminən hər 20–30 saniyədən bir yeniləyir.

Targeted filtering isə əsasən REST API üzərindən həyata keçirilir. Endpoint modeli belədir:

POST https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/providers/Microsoft.Security/defenderForStorageSettings/current/startMalwareScan?api-version=2024-10-01-preview
Authorization: Bearer <ENTRA_TOKEN>
Content-Type: application/json

Bu endpoint Microsoft-un on-demand scanning üçün sənədləşdirdiyi management-plane request modelidir.

Məsələn, yalnız bir şübhəli blob-u yoxlamaq üçün:

{
  "properties": {
    "filters": {
      "blobs":
    }
  }
}

Bu halda incoming container-dir, qalan hissə isə blob path-dir. Exact yalnız həmin object-i scan edir. Microsoft eyni formatı single-blob targeted scan üçün sənədləşdirir.

SOC müəyyən upload batch-in komprometasiya olunduğunu düşünürsə prefix scan daha uyğun ola bilər:

{
  "properties": {
    "filters": {
      "blobs":
    }
  }
}

Bu pattern göstərilən prefix-lə başlayan object-ləri scope-a daxil edir və bütün account-u yenidən scan etmək ehtiyacını azalda bilər.

Azure Files üçün eyni model files altında işləyir:

{
  "properties": {
    "filters": {
      "files":
    }
  }
}

File path-də birinci hissə share name-dir. Matching case-sensitive olduğu üçün automation source-dan path canonicalization edərkən case-i dəyişməməlidir.

Scan başladıqdan sonra son scan statusu aşağıdakı management endpoint-i ilə yoxlanıla bilər:

GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/providers/Microsoft.Security/defenderForStorageSettings/current/malwareScans/latest?api-version=2024-10-01-preview
Authorization: Bearer <ENTRA_TOKEN>

Response scan statusundan əlavə scanned və malicious blob/file count-ları, skipped və failed item-lər, scanned GB kimi summary metric-lər qaytara bilər. Bu metric-lər pipeline-da “scan API call succeeded” ilə “expected objects were actually scanned” arasındakı fərqi bağlamaq üçün istifadə edilməlidir.

Incident-response automation üçün Azure CLI-dan bearer token götürüb REST call etmək mümkündür. Məsələn, konseptual shell flow belə qurula bilər:

TOKEN=$(az account get-access-token \
  --resource https://management.azure.com/ \
  --query accessToken \
  --output tsv)

curl -X POST \
  "https://management.azure.com/subscriptions/$SUB_ID/resourceGroups/$RG/providers/Microsoft.Storage/storageAccounts/$STORAGE/providers/Microsoft.Security/defenderForStorageSettings/current/startMalwareScan?api-version=2024-10-01-preview" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data @scan-filter.json

Bu automation identity-sinə yalnız scan start/read/cancel actions vermək broad Contributor səlahiyyətindən daha yaxşı least-privilege posture yaradır. Required Defender permissions Microsoft tərəfindən ayrıca sənədləşdirilib.

Biznes və Təhlükəsizlik Baxımından Üstünlükləri

Ən aydın biznes faydası scan blast radius və xərcin azaldılmasıdır. On-demand scanning usage-based per-GB modelidir və on-upload scanning-dən fərqli olaraq monthly cap yoxdur. Microsoft-a görə filtered scan istifadə edilərkən xərc storage account-un ümumi capacity-sinə deyil, faktiki scan olunan data həcminə əsaslanır. Buna görə 40 TB account-da yalnız 500 MB şübhəli upload batch-i araşdırılırsa bütün 40 TB-nin security revalidation-ı iqtisadi baxımdan məntiqli olmaya bilər; targeted scanning daha optimallaşdırılmış incident-response primitive verir.

Əlavə dependent-service xərcləri də nəzərə alınmalıdır: malware scanning storage read əməliyyatları, blob indexing və Event Grid events kimi əlavə consumption yarada bilər. Microsoft portalda on-demand scan başlamazdan əvvəl cost estimate göstərir və risk-based frequency, event/alert-driven automation və targeted filters istifadə etməyi cost-control best practice kimi tövsiyə edir.

Security baxımından əsas üstünlük time-to-investigate göstəricisinin azalması potensialıdır. SOC analyst alert-dən konkret object path əldə edirsə, full-account sweep əvəzinə həmin object-i, onun incident prefix-ini və ya associated container-i scan edə bilər. Bu, həm response cycle-ı daha fokuslu edir, həm də əvvəllər failed olmuş tək object-i yenidən yoxlamağa imkan verir.

Targeted scan təkbaşına quarantine mexanizmi deyil. Scan zamanı data normal şəkildə əlçatan qala bilər və result kanallarından biri olan blob tag tamper-resistant deyil. Güclü architecture scan result-u Event Grid, Defender alert və ya Log Analytics kimi daha authoritative channel-dan götürüb ABAC, soft delete, Logic App və ya Function-based remediation ilə tamamlamalıdır.

Operational governance baxımından isə August Defender dəyişiklikləri bir mesaj verir: security data contracts statik deyil. CVE detail resource modelinin dəyişməsi, CIEM field removal və Defender for SQL API retirement automation-ların release-note-driven lifecycle management tələb etdiyini göstərir. Security platform komandası ARG/KQL query-ləri, API dependencies və SOC parsers üçün regression testing tətbiq etməsə, cloud security platformasında yeni update özü observability blind spot yarada bilər. Bu, Avqust release notes-da təsvir edilən breaking/deprecation dəyişikliklərindən çıxan engineering nəticəsidir.

Tətbiq Ssenariləri

Birinci use case ransomware və ya malware incident-dir. Defender və ya başqa SIEM incoming/client-883/archive.zip obyektini şübhəli göstərir; SOAR playbook həmin blob-u Exact filter ilə scan edir, malicious nəticə alarsa Event Grid/Logic App workflow vasitəsilə quarantine və ya deletion prosesini işə salır. Bu model scanning + automated remediation imkanlarının birləşməsinə uyğundur.

İkinci use case software supply-chain ingestion-dır. Vendor tərəfindən hər gecə vendor-feed/YYYY/MM/DD/ prefix-inə fayllar göndərilir. Risk trigger yarandıqda yalnız həmin day’s prefix on-demand rescan edilə bilər; full storage account sweep tələb olunmur. Prefix filtering bu scope modelini birbaşa dəstəkləyir.

Üçüncü ssenari compliance və legacy baseline-dır. Defender for Storage yeni aktivləşdirilmiş account-da bütün mövcud data üçün ilkin baseline scan aparıla, sonrakı exceptional investigation-larda isə yalnız riskli container və ya file share hədəflənə bilər. Microsoft həm baseline creation, həm compliance, həm də targeted investigation-i on-demand scanning use case-i kimi göstərir.

Dördüncü ssenari failed-scan retry-dir. Əgər böyük account-da yalnız bir neçə object əvvəlki scan zamanı error alıbsa, bütün account-u təkrar scan etmək əvəzinə həmin object-ləri individual filter-lərlə yenidən yoxlamaq daha aşağı cost və daha qısa operational cycle verə bilər. Microsoft targeted rescan-ı failed on-upload/on-demand scan retry üçün birbaşa use case kimi göstərir.

Yekun

Avqust 2026 Defender for Storage yeniliyinin strateji dəyəri malware engine-in özünün dəyişməsindən çox scan scope-un security orchestration primitive-ə çevrilməsidir. SecOps artıq “account scan et / etmə” kimi ikili seçimlə məhdudlaşmır; object, container, share və prefix səviyyəsində risk-based scanning tətbiq edə bilər. Bu, incident response latency-si, FinOps və automation precision baxımından ciddi irəliləyişdir. Eyni zamanda August release-dəki CVE data model change, CIEM breaking change və SQL API retirement security engineering komandalarına API/query dependency-lərini ayrıca change-management rejimində idarə etməyin vacibliyini göstərir.