Cloud və platform security

Cloud-da server-i heç kim oğurlamır. Attacker data center-ə girmir, firewall-u sındırmır, zero-day axtarmır. O, public bucket tapır, leak olmuş access key ilə login edir və ya hər şeyə icazəsi olan role-u istifadə edir. Cloud breach-lərinin əksəriyyəti provider-in səhvi deyil, müştərinin konfiqurasiyasıdır.

Bu fəsil platform-un özünü necə qorumaq haqqındadır: cloud account-lar, server-lər, container-lər, infrastructure kodu və istifadəçinin cibindəki mobil app.

Shared responsibility model

Provider bəzi şeyləri qoruyur, qalanı sizindir. Sərhəd service modelindən asılıdır, və incident-lərin çoxu komandanın sərhədin harada olduğunu səhv təsəvvür etməsindən başlayır.

Son iki sətrə diqqət edin. Hansı model olursa olsun, kimin nəyə access-i olduğu və data-nın necə qorunduğu həmişə sizin məsuliyyətinizdir. SaaS-da belə, admin account-unda MFA-nın olmaması sizin problemidir.

Cloud IAM yeni perimeter-dir

Fəsil 3-də zero trust-ın şəbəkə yerini identity ilə əvəz etdiyini gördük. Cloud-da bu nəzəriyyə deyil, faktdır: hər resource API arxasındadır, və API-yə çatmaq üçün yalnız credential lazımdır. Cloud IAM-ın səhvləri təkrarlanır:

• Wildcard policy-lər. "Action": "*" və ya "Resource": "*" olan policy "sonra daraldarıq" deyə yazılır və heç vaxt daraldılmır.
• Over-privileged role-lar. Bir bucket-dən oxuyan service-ə bütün storage üzərində admin verilir, çünki dəqiq permission-ları tapmaq vaxt aparır.
• Uzunömürlü access key-lər. İllərlə rotate olunmamış, developer laptop-larında, CI variable-larında və köhnə script-lərdə qalan key-lər. Workload identity (Fəsil 3) bunları əvəz etməlidir.
• Cross-account trust. Başqa account-a və ya vendor-a role assume etmək icazəsi, dəqiq şərtsiz. Vendor compromise olunanda siz də compromise olunursunuz.
• Root və break-glass account-lar. Gündəlik işdə istifadə olunur, MFA-sız və ya credential-ı paylaşılmış.

Least privilege-i praktikada tətbiq etmək üçün permission-ları təxminlə deyil, faktiki istifadə ilə yazın. Əksər provider-lərin access analyzer tool-ları son 90 gündə hansı permission-ların istifadə olunduğunu göstərir; istifadə olunmayanları silin. Policy dəyişikliklərini kod dəyişikliyi kimi review edin. Account-ları environment və komanda üzrə ayırın ki, bir account-un compromise olması blast radius-u məhdud saxlasın.

Misconfiguration: əsas breach səbəbi

Fəsil 4-də security misconfiguration-u application tərəfindən qısaca gördük. Cloud-da o, ən böyük risk kateqoriyasıdır, çünki bir klik və ya bir sətir config bütün data-nı internet-ə aça bilər.

• Public storage bucket-lər. Backup-lar, log-lar, müştəri export-ları "müvəqqəti" public edilir. Account səviyyəsində public access-i default olaraq bloklayın; istisna açıq qərar olsun.
• Açıq security group-lar və port-lar. 0.0.0.0/0-dan SSH, RDP və ya database port-una icazə. Scanner-lər bütün IPv4 address space-ini saatlar içində gəzir.
• Exposed management plane-lər. Orchestrator API-si, dashboard-lar, CI server-ləri, monitoring panel-ləri authentication-sız və ya default credential ilə public-dir.
• Cloud metadata endpoint. VM daxilindən çatılan bu endpoint instance-ın credential-larını qaytarır. Fəsil 4-dəki SSRF burada ən təhlükəli formasını alır: attacker application-ı metadata endpoint-ə yönəldir və cloud credential-larını oğurlayır. Session token tələb edən versiyanı (IMDSv2-style) məcburi edin, hop limit-i təyin edin və istifadə etməyən workload-larda endpoint-i söndürün.
• Default credential-lar. Database image-lərindəki admin/admin, router-lərdəki zavod password-ları, nümunə app-lərdə qalan test account-ları.

Bu səhvlərin hamısı detect edilə biləndir. Cloud security posture management (CSPM) tool-ları account-ları davamlı scan edir və public resource-ları, açıq port-ları, encryption-sız storage-i işarələyir. Problem detection deyil, tapıntılara kimin baxdığıdır.

Hardening və attack surface-in azaldılması

Hardening sistemi default vəziyyətdən minimum lazımi vəziyyətə gətirməkdir. Hər əlavə service, port, package və account attack surface-dir.

• Minimal base image-lər. Distroless və ya minimal image-lər shell, package manager və yüzlərlə lazımsız binary daşımır. Attacker-in istifadə edəcəyi tool-lar da yoxdur.
• İstifadə olunmayanı silin. Lazımsız service-ləri söndürün, port-ları bağlayın, nümunə konfiqurasiyaları və default account-ları silin.
• Patching cadence. Kritik vulnerability-lər üçün günlər, qalanları üçün həftələr. Cədvəl yazılı olsun və ölçülsün.
• Immutable infrastructure. Server-ləri SSH ilə patch etmək əvəzinə yeni image qurun və köhnəsini əvəz edin. Server-də əl ilə edilən dəyişiklik yoxdursa, attacker-in persistence-i də növbəti deploy-da silinir. Rollout strategiyaları Software Architecture kitabının 14-cü fəslində əhatə olunub.
• Benchmark-lar. CIS-style benchmark-lar OS, container runtime və cloud account-lar üçün hazır hardening checklist-ləridir. Sıfırdan yazmaq əvəzinə onlardan başlayın və istisnaları sənədləşdirin.

Container-lər və orchestration

Container isolation sərhədi verir, amma default-lar zəifdir.

• Root kimi işlətməyin. Image-də non-root user təyin edin; privilege escalation-u söndürün. Root container-dən host-a çıxış bir kernel bug-ı qədər uzaqdır.
• Read-only filesystem. Application yazmalı olduğu yerləri açıq mount etsin; qalan hər şey read-only olsun. Attacker tool yükləyə bilmir.
• Privileged mode və host mount-lar yoxdur. Host-un socket-ini və ya filesystem-ini container-ə mount etmək host-u verməkdir.
• Image scanning və signing. Hər image build zamanı scan olunur, sign olunur, və cluster yalnız signed image-ləri qəbul edir. Bu, Fəsil 4-dəki supply chain zəncirinin son halqasıdır.
• Secret-lər image-də deyil. Image layer-ləri silinmiş faylları da saxlayır. Environment variable-lar crash dump-larında, debug endpoint-lərində və process listing-lərində görünür. Secret-ləri runtime-da mount edin; idarəetmə və KMS Fəsil 6-dadır.
• Network policy-lər. Default olaraq cluster-də hər pod hər pod ilə danışa bilir. Default deny tətbiq edin və yalnız lazımi axınlara icazə verin. Bu, lateral movement-ə qarşı micro-segmentation-dur.

Infrastructure as code security control kimi

Infrastructure kodda təsvir olunanda security onunla birlikdə review oluna bilər. Console-da edilən dəyişikliyi heç kim review etmir.

• Review. Hər infrastructure dəyişikliyi pull request-dən keçir; plan output-u diff-də görünür.
• Policy-as-code. "Public bucket yoxdur", "encryption məcburidir", "0.0.0.0/0-dan SSH yoxdur" kimi qaydalar kod kimi yazılır və CI-də avtomatik yoxlanır. Uyğun gəlməyən dəyişiklik merge olunmur.
• Drift detection. Faktiki infrastructure-u kodla müqayisə edin. Əl ilə edilən dəyişiklik ya kodla geri yazılır, ya da incident kimi araşdırılır.
• State fayllarını qoruyun. IaC state-i çox vaxt secret-lər və resource ID-ləri saxlayır. Ona production credential-ı kimi yanaşın.

Cloud logging və görünürlük

Fəsil 5 log etmədiyinizi detect edə bilməyəcəyinizi deyirdi. Cloud-da ən vacib log control-plane audit log-udur: kim hansı API call-u, haradan, hansı nəticə ilə etdi.

• Bütün account-larda və region-larda audit logging-i aktiv edin, istifadə etmədiyiniz region-lar daxil. Attacker-lər məhz baxmadığınız region-da resource yaradır.
• Log-ları ayrıca, yalnız security komandasının access-i olan account-a göndərin. Production account-unda admin olan attacker log-ları silə bilməməlidir.
• Storage və network üçün data-plane log-larını kritik resource-larda aktiv edin.
• Alert-lər: audit logging-in söndürülməsi, yeni access key yaradılması, policy-yə wildcard əlavə edilməsi, root login, gözlənilməz region-da activity.

Mobil application security

Mobil app attacker-in cihazında işləyir. O, binary-ni decompile edə, trafiki proxy-dən keçirə, yaddaşı oxuya və istənilən request-i dəyişə bilər. Buna görə əsas qayda sadədir: app-ə etibar etməyin.

• Server-side enforcement. Hər authorization, validation və biznes qaydası server-də yoxlanır. App-dəki gizli düymə və ya client-side limit heç nəyi qorumur. API-nin özü qorunmalıdır (Fəsil 7).
• Binary-də secret yoxdur. API key, signing key, admin endpoint-i binary-yə yazılırsa, artıq public-dir. Obfuscation bunu yalnız ləngidir.
• Secure local storage. Token-ləri platform-un keystore-unda saxlayın, plain preferences və ya fayllarda deyil. Lazım olmayan data-nı cihazda saxlamayın.
• Certificate pinning trade-off-ları. Pinning man-in-the-middle-ı çətinləşdirir, amma certificate rotation-u riskli edir: səhv idarə olunan pin bütün istifadəçiləri app-dən kəsə bilər. Pinləyirsinizsə, backup pin və yeniləmə planı saxlayın. Pinning server-side check-lərin əvəzi deyil.
• Köhnə versiyalar. İstifadəçilər app-i yeniləmir. Minimum dəstəklənən versiyanı məcbur etmək imkanınız olsun, əks halda köhnə API-lər əbədi açıq qalır.

Tapşırıqlar

1. Cloud account-unuzda * action və ya resource olan bütün policy-ləri tapın. Hər biri üçün faktiki istifadə olunan permission-ları müəyyən edin və daraldılmış versiyanı yazın.
2. Son 90 gündə istifadə olunmamış access key-ləri və role-ları sadalayın. Onları silmək üçün nə mane olur?
3. Production-dakı bir container image-ini götürün. Root kimi işləyirmi? Shell varmı? İçində neçə məlum vulnerability var? Hardening-dən sonra eyni sualları yenidən cavablandırın.