Kriptoqrafiya və data protection

Kriptoqrafiya nadir hallarda riyaziyyat səviyyəsində sınır. AES-i heç kim sındırmır. Sınan onun ətrafındakı hər şeydir: kodda unudulmuş key, söndürülmüş certificate check-i, password üçün seçilmiş sürətli hash, log-a düşmüş kart nömrəsi. OWASP bu kateqoriyanı "Cryptographic Failures" adlandırır və nəticəsi demək olar ki, həmişə eynidir: sensitive data exposure, sonra isə data breach. Bu fəsil alqoritmlərdən çox onların düzgün istifadəsi haqqındadır.

Kriptoqrafiya nə verir, nə vermir

Düzgün istifadə olunanda kriptoqrafiya üç xassə verir:

• Confidentiality: key-i olmayan data-nı oxuya bilmir.
• Integrity: data dəyişdirilibsə, bu aşkar olunur.
• Authenticity: data-nın kimdən gəldiyini sübut etmək olur.

Vermədikləri də eyni dərəcədə vacibdir. Encryption authorization deyil: application data-nı decrypt edib istənilən istifadəçiyə qaytarırsa, disk-in encrypt olunması heç nəyi qorumur. Encryption key-in özündən güclü deyil: key ciphertext-in yanında saxlanırsa, sadəcə əlavə addım yaratmısınız. Və kriptoqrafiya compromise olunmuş endpoint-i qoruya bilmir: attacker server-dədirsə, o da decrypt olunmuş data-nı görür.

Symmetric və asymmetric

Symmetric encryption eyni key ilə encrypt və decrypt edir. Sürətlidir və böyük həcmli data üçün istifadə olunan budur. Problem key-in paylanmasıdır: hər iki tərəf eyni secret-i bilməlidir.

Asymmetric encryption key cütündən istifadə edir: public key ilə encrypt olunanı yalnız private key açır, private key ilə sign olunanı isə hər kəs public key ilə verify edə bilir. Yavaşdır, buna görə də praktikada iki iş görür: key exchange və digital signature. TLS məhz belə işləyir: asymmetric kriptoqrafiya ilə razılaşdırılmış session key, sonra symmetric encryption ilə trafik.

Authenticated encryption

Müasir symmetric encryption authenticated olmalıdır: ciphertext həm gizlədilir, həm də dəyişdirilməyə qarşı qorunur. Default seçimlər AES-GCM və ChaCha20-Poly1305-dir. Bunlar decrypt zamanı manipulyasiya olunmuş ciphertext-i rədd edir.

Tipik uğursuzluqlar:

• ECB mode. Eyni plaintext block-ları eyni ciphertext block-larına çevrilir; data-nın strukturu görünür qalır.
• Authentication olmadan CBC və ya CTR. Attacker ciphertext-i dəyişə bilir və padding oracle kimi attack-lər mümkün olur.
• Nonce reuse. AES-GCM-də eyni key ilə eyni nonce-un iki dəfə istifadəsi həm confidentiality-ni, həm də integrity-ni məhv edir. Nonce-u random yaradın və ya library-yə buraxın.

Bu detalları özünüz idarə etməməlisiniz. Fəsil 4-də deyildiyi kimi, safe default-ları olan high-level library seçin; düzgün API sizə mode və nonce seçimi buraxmır.

Hash, MAC, signature, password hash

Bu dörd alət tez-tez qarışdırılır, halbuki fərqli suallara cavab verir:

Adi hash-i heç vaxt authentication üçün istifadə etməyin: key olmadığı üçün attacker data-nı dəyişib hash-i yenidən hesablaya bilər. Webhook-ları və daxili mesajları MAC ilə, release artifact-lərini və token-ləri signature ilə qoruyun. MAC və signature yoxlamasını constant-time müqayisə ilə edin. Password-lər üçün Fəsil 3-dəki qayda qüvvədədir: yavaş, salt-lı, məqsədli password hash; heç vaxt MD5, SHA-1 və ya hətta SHA-256 təkbaşına.

Randomness

Key-lər, nonce-lar, session ID-ləri, password reset token-ləri və API key-lər təxmin edilməz olmalıdır. Onları yalnız CSPRNG ilə, yəni əməliyyat sisteminin kriptoqrafik random mənbəyi ilə yaradın. Dillərin standart "random" funksiyaları adətən statistik generator-dur: ardıcıllıq bir neçə çıxışdan sonra proqnozlaşdırıla bilir. Vaxt damğasından, user ID-dən və ya counter-dən törədilmiş token random deyil.

Key management

Real uğursuzluqların əksəriyyəti burada baş verir. Alqoritm düzgün seçilir, key isə config faylında, environment variable-da, ya da ən pisi, encrypt etdiyi data ilə eyni database-də qalır.

• Key-ləri data-dan ayırın. Key-lər KMS və ya HSM-də yaşayır; application onlara identity vasitəsilə, audit log ilə access edir. Database backup-ı oğurlanırsa, key-lər onunla birlikdə getmir.
• Envelope encryption. Hər obyekt və ya record qrupu öz data key-i ilə encrypt olunur; data key-in özü isə KMS-dəki master key ilə encrypt olunub data-nın yanında saxlanır. Master key KMS-i heç vaxt tərk etmir, böyük data isə KMS-ə göndərilmir.
• Rotation. Key-lər cədvəl üzrə və hər şübhəli incident-dən sonra rotate olunur. Rotation-u əvvəlcədən dizayn edin: ciphertext hansı key versiyası ilə encrypt olunduğunu daşımalıdır, əks halda köhnə data-nı oxumaq üçün köhnə key-i əbədi saxlamalı olursunuz.
• Bir key, bir məqsəd. Encryption key-i signing üçün, production key-i test üçün istifadə olunmur.
• Key-in məhv edilməsi silmədir. Data key-ini məhv etmək onunla encrypt olunmuş bütün data-nı oxunmaz edir. Bu, backup-lardakı data-nı silməyin praktik yoludur.

encrypt(record):
  data_key           = kms.generate_data_key(master_key_id)
  ciphertext         = aead_encrypt(data_key.plaintext, record)
  store(ciphertext, data_key.encrypted, master_key_id, key_version)
  wipe(data_key.plaintext)

Data in transit

Şəbəkədən keçən hər şey TLS ilə encrypt olunur, istisnasız:

• TLS 1.2 minimum, TLS 1.3 üstünlük. SSL və TLS 1.0/1.1 söndürülür, zəif cipher suite-lər bağlanır.
• HTTPS hər yerdə, HSTS ilə, browser-in HTTP-yə downgrade olmaması üçün. Plain HTTP yalnız HTTPS-ə redirect edir.
• Certificate validation heç vaxt söndürülmür. "Test üçün müvəqqəti" verify=false production-a çatır və man-in-the-middle-a qapı açır. Daxili CA lazımdırsa, onu trust store-a əlavə edin.
• Daxili trafik də encrypt olunur. Fəsil 3-dəki zero trust prinsipinə uyğun olaraq service-lərarası trafik "içəri" olduğu üçün etibarlı deyil. mTLS hər iki tərəfi authenticate edir və workload identity verir. Onun platforma səviyyəsində necə qurulduğu Fəsil 8-dədir.
• Certificate-lərin vaxtı avtomatik yenilənir. Expire olmuş certificate-in yaratdığı outage, insanları validation-u söndürməyə sövq edən ən çox rast gəlinən səbəbdir.

Data at rest

Data at rest encryption-un fərqli səviyyələri fərqli təhdidlərdən qoruyur:

Disk encryption baseline-dır və demək olar ki, pulsuzdur. Ən sensitive field-lər, məsələn, identity sənəd nömrələri, sağlamlıq data-sı, bank rekvizitləri isə application səviyyəsində encrypt olunmalıdır, belə ki, database dump-ı tək başına faydasız olsun. Trade-off: encrypt olunmuş field üzərində axtarış və sort çətinləşir; bunun üçün ayrıca keyed hash index lazımdır.

Sensitive data handling

Ən yaxşı qorunan data sizdə olmayan data-dır.

• Classification. Data-nı səviyyələrə bölün, məsələn, public, internal, confidential, restricted. Control-lar səviyyəyə uyğun seçilir; hər şeyə eyni yanaşma ya baha, ya da zəif olur.
• Minimisation. Lazım olmayan field-i toplamayın. Kart nömrəsi lazımdırsa, payment provider-in token-i ilə kifayətlənin. Doğum tarixi əvəzinə "18 yaşdan yuxarı" flag-i kifayət edə bilər.
• Log-lara yazmayın. Password-lər, token-lər, kart nömrələri, tam request body-ləri log-a düşmür. Log pipeline-ında masking tətbiq edin; log-lar adətən production data-dan daha geniş access-ə malikdir.
• Masking və tokenisation. UI və support tool-ları yalnız son dörd rəqəmi göstərir. Tokenisation sensitive dəyəri ayrıca vault-da saxlayır, qalan sistemlər isə mənasız token ilə işləyir.
• Retention və deletion. Hər data növünün saxlanma müddəti olsun və müddəti bitəndə avtomatik silinsin, backup-lar da daxil olmaqla. Saxlamadığınız data breach-də sızmır.
• API cavabları. Ən çox rast gəlinən exposure encryption ilə bağlı deyil: endpoint bütün obyekti serialize edir və client-ə lazım olmayan field-lər, məsələn, password_hash, daxili flag-lər, başqa istifadəçilərin data-sı cavaba düşür. Fəsil 7 bunu ətraflı əhatə edir.

Ümumi cryptographic failure-lar

Code review və audit zamanı bunları axtarın:

• Password-lər üçün MD5, SHA-1 və ya salt-sız sürətli hash.
• Kodda, image-də və ya repository-də hard-coded key-lər.
• Söndürülmüş certificate validation və ya hər certificate-i qəbul edən custom trust manager.
• Homegrown kriptoqrafiya: XOR "encryption", öz protokolunuz, base64-ün encryption kimi təqdim olunması.
• Deprecated alqoritmlər və protokollar: DES, 3DES, RC4, SSL, TLS 1.0, qısa RSA key-ləri.
• Unauthenticated encryption, ECB mode, sabit və ya təkrar istifadə olunan nonce/IV.
• Qeyri-kriptoqrafik random ilə yaradılmış token və key-lər.
• Rotate edilə bilməyən key-lər, çünki key versiyası heç yerdə saxlanmır.

Tapşırıqlar

1. Sisteminizdəki ən sensitive üç data növünü seçin. Hər biri üçün yazın: harada saxlanılır, hansı səviyyədə encrypt olunur, key harada yaşayır və key-ə kim access edə bilər?
2. Codebase-də verify=false, InsecureSkipVerify, MD5, SHA1, ECB və standart random funksiyalarını axtarın. Hər tapıntını təsnif edin: real risk və ya təhlükəsiz istifadə.
3. Bir encryption key-i rotate etməyi bu gün sınayın, staging-də. Köhnə data oxunurmu? Neçə addım əl ilə edildi və prosesi kim bilirdi?