At Rest şifrələmə

At Rest şifrələmə

1) Nə üçün lazımdır və nəyi müdafiə edirik

Tərifi. At rest şifrələmə - fiziki daşıyıcıya və ya «xam» anbara icazəsiz girişin məzmunu açıqlamaması üçün daşıyıcıya (disklər, snapshotlar, backup, obyektlər, log, yaddaş dampaları) yazılan məlumatların qorunmasıdır.

• Blok/fayl cildləri, obyekt anbarları, verilənlər bazaları, növbələr/keyvelyu, cache damps, log/treys, ehtiyat nüsxələr, ixrac/idxal, VM/konteyner şəkilləri, nüvə/proses damps, nasos/swap.
• Multi-icarə ssenariləri: müştərilər/layihələr/mühit arasında izolyasiya.

Tamamilə əhatə etmədiyimiz şey: yaddaş seanslarının oğurlanması, canlı prosesə hücumlar, tətbiqin zəiflikləri, mühasibat məlumatlarının pozulması. Bunun üçün «uçuşda» şifrələmə, ciddi autentifikasiya/avtorizasiya, hüquqların minimallaşdırılması və monitorinqi tələb olunur (bax: «Autentifikasiya və avtorizasiya», «İmza və sorğuların yoxlanılması»).

2) Təhdidlər modeli və nəzarət məqsədləri

• Media itkisi/oğurluğu (disk, lent, USB, developer cihazı).
• Backup/snapshot/loglara icazəsiz giriş.
• Platforma/hipervizor/storage-nod səviyyəsində imtiyazlardan sui-istifadə.
• Konfiqurasiya səhvləri zamanı kirayəçilərin kəsişməsi.
• Artefaktlara və şəkillərə daxil olan «qarışıq» müvəqqəti fayllar və dampalar.

1. Mediada məlumatların məxfiliyi.

2. Kirayəçilərin/mühitlərin kriptoqrafik izolyasiyası.

3. Açarların idarə edilməsi (yaradılması, saxlanması, rotasiyası, geri çağırılması).

4. Audit (açarı kim və nə zaman istifadə etmişdir).

5. Hadisə zamanı istismar risklərinin minimuma endirilməsi.

3) Arxitekturanın əsas prinsipləri

Hər şeyi default olaraq şifrələyin. Opt-out risk səviyyəsində istisnasız qadağandır.
Açar iyerarxiyası (envelope encryption). Root/KEK → DEK (data encryption keys) → obyektlər/fayllar/səhifələr DB.
KMS/HSM etimad mənbəyi kimi. KMS/HSM-də KEK-in yaradılması və saxlanması, açarların sarılması/yerləşdirilməsi əməliyyatları eyni yerdə həyata keçirilir.
Per-tenant/per-dataset açarları. Qranulyarlıq izolyasiya və rotasiya tələblərinə uyğundur.
Vəzifələrin ayrılması. Platforma komandaları ≠ kirayəçi açar sahibləri; minimum imtiyazlar (PoLP).
Crypto-agility. Alqoritmləri/açar uzunluqlarını təhlükəsiz miqrasiya etmək imkanı.
Bir hadisə deyil, bir proses kimi rotasiya. Açarlar və məlumatlar «sürüşmə» əvəzetməsini dəstəkləməlidir.

4) Alqoritmlər və şifrləmə rejimləri

Obyektlər/fayllar/qeydlər üçün: AES-256-GCM və ya AES-256-SIV (Autentification ilə AEAD).
Blok cihazları/cildləri üçün: AES-XTS-256/512 (blokların yerdəyişməsindən qorunma; AEAD deyil - bütövlük vacib olduğu yerlərdə MAC ilə fayl formatları üzərində istifadə edin).

• TDE (Transparent Data Encryption) движка: Oracle TDE, SQL Server TDE, MySQL/InnoDB TDE и пр.
• Sahə/kiçik kriptoqrafiya (FPE/determinated şifrələmə) - şifrələnmiş sahələrdə axtarış/joyn imkanları üçün; ehtiyatla tətbiq edin.
• Açarların yaradılması və saxlanması: KEK - KMS/HSM-də; DEK - tətbiqlərin yaddaşında qısamüddətli, saxlama zamanı - yalnız sarılmış formada.

5) Açar iyerarxiyası və KMS/HSM

1. Root key (statut, HSM/KMS). HSM/KMS perimetri ayrılmır.

2. KEK (Key Encryption Key). Layihə/mühit/kirayəçi. DEK həyat dövrünü idarə edir.

3. DEK (Data Encryption Key). Obyekt/fayl/cədvəl/seqment. Qısa ömürlü, dayanmadan rotasiya.

• Bütün sarma/yerləşdirmə əməliyyatları - KMS API audit vasitəsilə.
• Siyasətçilər: Açarı kim «istifadə edə» bilər ≠ açarı kim «idarə edə» bilər.
• Açarların geoayrılması: regionlararası üçün pin-to-region + dual-control.
• Yüksək riskli əməliyyatlar üçün «iki nöqtəli» model (iki operator) mümkündür.
• Güclü səviyyədə izolyasiya üçün - kirayəçi üçün ayrı-ayrı key-rings.

6) Rotasiya, geri çağırma və uyğunluq

DEK rotasiyası: şəffaf və davamlı (obyektlər/səhifələr səviyyəsində rolling re-encryption).
KEK-in rotasiyası: dövri (məsələn, hər 6-12 ayda bir) + kompromasiya şübhəsi olduqda dərhal geri çağırış.
Giriş geri çağırılması: KMS siyasəti vasitəsilə; unwrap əməliyyatlarının bloklanması = verilənlərin ani «kriptovalyutası».
Audit jurnalları: açarları kim, nə vaxt, hansı hüquqlarla istifadə etdi; ayrıca saxlamaq və şifrələmək.
Standartlar: Sənaye tələblərinə (məsələn, GDPR/PCI tolerantları/yerli tənzimləyicilər) diqqət yetiririk, sertifikatlı kriptovalyutalardan istifadə edirik (məsələn, sertifikatlaşdırma səviyyələrinə uyğunluq).

7) Saxlama növlərinə görə nümunələr

7. 1 Blok/fayl cildləri və VM/konteynerlər

Tam disk şifrələmə (XTS) + KMS vasitəsilə açarların idarə edilməsi (montaj zamanı cildin başlanğıcı).
swap, crash-damps, tmp-direktoriyaları, konteyner overlay qatları, şəkillər/AMI qoruyun.
Şəkillər/snapshotlar - həmişə ayrı DEK ilə şifrələnmiş formada.

7. 2 Obyekt saxlama

Envelope encryption: obyektdə unikal DEK; başlıqlar/meta məlumat - PII sızması olmadan.
Kirayəçilər və ətraf mühit üzrə KMS açarına giriş nəzarəti.
Server-sayd şifrələmə (SSE öz KMS ilə) və ya müştəri-sayd (CSE) - etibarlı model ilə seçin.

7. 3 Verilənlər bazası

Mövcud olan TDE-ni daxil edin; DB açarları plugin/ekstenşn vasitəsilə KMS-ə bağlanır.
Xüsusi həssas sahələr üçün - DB-yə girməzdən əvvəl tətbiqi şifrləmə (AEAD).
Redo/tranzaksiya qeydləri, arxiv qeydləri, dampalar - ayrı-ayrılıqda şifrələmək, açarlar - ayrı-ayrılıqda şifrələmək.

7. 4 Log/treys/metrika

Log formatı - default məlumatsız (dezinfeksiya).
Log arxivləri - fərdi açarlar və qısa TTL saxlama.
Log oxu - A&A və audit ilə proxy xidməti vasitəsilə.

7. 5 Ehtiyat və oflayn daşıyıcılar

Həmişə lent/bulud qeyd əvvəl müştəri tərəfində şifrələmək.
Açarları ayrıca saxlayın (out-of-band), ayrı nəzarət ilə escrow.
Fövqəladə hallar üçün - master-access bərpa etmək üçün sirr ayrılması (məsələn, m-of-n).

8) Multi-tenant

Kirayəçi üçün açar: KEK-per-tenant + DEK-per-dataset.
Siyasətlə təcrid: KMS ad məkanları, IAM sərhədləri, fərdi IDP rolları.
Müştərinin istəyi ilə silinir: «kriptovalyutası» - kirayəçinin KEK-ni geri çağırmaq və DEK-i məhv etmək.
Müştəri üçün hesabat: uyğunluq artefaktları, açar giriş qeydləri, rotasiyanın təsdiqi.

9) Performans və əməliyyat

Aparat sürətləndirmələri (AES-NI/x86, ARMv8 Crypto Extensions).
Qaynar yolların profilləşdirilməsi: I/O sərhədlərində şifrələyirik, ehtiyac olmadan ikiqat şifrələmədən qaçırıq.
KMS seans hovuzları, yaddaşda bükülmüş DEK-lərin keşi (TTL və damperlərdən qorunma ilə).
SLO/metriklər: unwrap gecikmə, «şifrələnmiş» obyektlərin payı, KMS səhvləri, arxa şifrələmə sürəti.

10) Tətbiq prosesi (reference runbook)

Addım 0 - məlumatların inventarlaşdırılması. Bütün saxlama və sızma yollarını kataloq (tmp, damp, ixrac, analytics-bakets).
Addım 1 - əsas iyerarxiyanın dizaynı. KEK/DEK səviyyələrini, qranulyarlığını, regionlarını, rollarını müəyyənləşdiririk.
Addım 2 - rejimlərin/kitabxanaların seçimi. Təsdiq edilmiş alqoritmlər, kriptoblioteklər, versiya siyasətləri.
Addım 3 - KMS/HSM ilə inteqrasiya. Generation/sarma/audit, IAM siyasəti, geo-pinning.
Addım 4 - yazmaq üçün şifrələmə. Default aktiv, mövcud məlumatların background-reenkript vasitəsilə köçürülməsi.
Addım 5 - rotasiya və təcili ssenarilər. Qaydalar, testlər «key compromise», «KMS mövcud deyil».
Addım 6 - monitorinq və audit. Daşbordlar, alertlər, müntəzəm uyğunluq hesabatları.
Addım 7 - təlim və «secure coding». Mühəndislər üçün qaydalar, log/dampalara sirlərin çıxarılmasını qadağan edir.

11) Test və yoxlama

Kriptovalyuta testləri: AEAD düzgünlüyü (etiketlərin yoxlanılması), bayt dəyişdirildikdə imtinanın təsdiqi.
Failure-tests: KMS-in bağlanması, köhnəlmiş açar versiyaları, KEK-in məcburi geri çağırılması.
Red/Blue Tests: «xam» disk/snapshot/backup oxumaq üçün cəhd.
Uyğunluq testi: alqoritmlərin/açar uzunluqlarının miqrasiyası (crypto-agility).
Kitabxanaların sertifikatlaşdırılması: yalnız təsdiqlənmiş kriptovalyutalardan istifadə edin; versiyası qeyd.

12) Tez-tez səhvlər və onlardan necə qaçmaq olar

Mənasız ikiqat şifrələmə. Əlavə gecikmə və mürəkkəblik. Lazımi qranulyarlıq və izolyasiya verən bir təbəqəni saxlayın.
Məlumatların yanında açarların saxlanması. Açarlar - hər zaman ayrı, fərqli giriş modeli altında.
Unudulmuş artefaktlar. Şifrəsiz müvəqqəti fayllar, CSV ixracı, dəstək dampaları. CI/CD və Data Loss Prevention-a nəzarəti daxil edin.
Rotasiyanın olmaması. Rotasiyanı əl proseduru ilə deyil, pipeline/cron hissəsi edin.
Həssas məlumatları olan loqlar. Log formatı və avtomatik sanitizatorlar üçün müqavilə daxil edin.

13) Mini reseptlər (psevdokod)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) Çek vərəqləri

• Bütün növ anbarlarda default şifrələmə aktivdir.
• Açar iyerarxiyası təsvir olunur və həyata keçirilir; rolları və IAM siyasətçiləri xüsusi.
• KMS/HSM inteqrasiya, əsas əməliyyatların auditi daxildir.
• DEK/KEK rotasiyası avtomatlaşdırılmışdır; kompromasiya ssenariləri işlənib hazırlanmışdır.
• Backup, snapshot, log və damps - şifrələnmiş; açarları ayrıca saxlanılır.
• KMS səhvləri, AEAD etiketlərinin sapmaları, şifrələnməmiş artefaktların payı ilə bağlı qərəzlər.
• KMS əlçatmazlığı və açar geri çağırma testləri keçdi.

• Aylıq açar istifadəsi və giriş cəhdləri haqqında hesabat.
• Crypto-agility planı və alqoritmlərin ağrısız miqrasiyası üçün pəncərə.
• «xam» daşıyıcılardan məlumatların çıxarılması üçün dövri Red-team.

15) Suallar və cavablar (FAQ)

S: Tam diskli şifrələmə kifayət edirmi?
A: Fiziki risklər üçün - bəli, lakin kirayəçiləri təcrid etmək və çevik rotasiya üçün DEK-obyekt/dəst ilə envelope daha yaxşıdır.

S: KEK güzəştində nə etmək lazımdır?
A: Dərhal KEK-i KMS-ə geri çağırın, yenisini yenidən buraxın, bütün DEK-i rewrap edin, jurnalları yoxlayın və RCA-nı keçirin.

S: Axtardığınız sahələri necə şifrələmək olar?
A: Yalnız risklərin ciddi qiymətləndirilməsi ilə determinik sxemlər və ya FPE istifadə edin (pattern leki). Həssas sahələrin indeksləşdirilmiş açıq görünüşü tələb etməməsi üçün sorğuları dizayn etmək daha yaxşıdır.

S: Açarlar üçün ayrıca komanda lazımdırmı?
A: «Crypto/KMS-operator» ayrı hüquqlar və prosedurlar ilə rol kimi tövsiyə olunur.

• «Açarların idarə edilməsi və rotasiya»
• «S2S-autentifikasiya»
• «Sorğuların imzalanması və yoxlanılması»
• «OAuth2/OpenID Connect»
• «Webhook çatdırılma zəmanətləri»