Transit Şifrelemede

Transit Şifrelemede

1) Kontrolün tanımı ve sınırları

Transit şifreleme, tüm ağ iletim yolu boyunca (tarayıcı sunucu, hizmet hizmet, aracı aracı, veritabanı uygulama, veri merkezi ve veri merkezi) verilerin korunmasıdır, böylece kanala yapılan pasif müdahale ve aktif saldırılar içeriği açığa çıkarmaz ve tespit edilmeden değiştirilmesine izin vermez.

Kapsadığımız: genel ve özel API'ler (HTTP/HTTPS, gRPC), akış ve brokerler (Kafka, NATS, RabbitMQ), WebSocket, ağ üzerindeki veritabanları ve önbellekler, kümeler içindeki hizmet trafiği, VPN/veri merkezleri ve bulutlar, DNS istekleri, mobil/IoT istemcileri.

Tam olarak kapsamadığımız şeyler: uç noktalara yapılan saldırılar (ana bilgisayar/tarayıcı uzlaşması), uygulama güvenlik açıkları, günlüklerden/dökümlerden kaynaklanan sızıntılar. Bu, ayrı kontrollerle (A&A, hakların en aza indirilmesi, dinlenme sırasında şifreleme, güvenli kayıt) çözülür.

2) Tehdit modeli ve hedefleri

Riskler: Traffic interception/spoofing (MITM), protokol downgrade/cipher suite, sahte sertifikalar/CA, anahtar sızıntısı, SNI/metadata saldırıları, karışık içerik, dengeleyiciler üzerinde TLS yanlış terimleme, güvensiz servis bağlantıları.

1. Gizlilik + kriptografik kimlik doğrulama ile bütünlük.

2. Düşürmeye muhalefet (sıkı politika ve yapılandırma).

3. Tarafların tanımlanması (gerekirse sunucu - karşılıklı).

4. Yönetilen sertifika/anahtar yaşam döngüsü ve denetim.

5. Güvenlik değiş tokuşları olmadan performans profili.

3) Temel ilkeler

TLS varsayılan olarak her yerdedir. Dış ve iç trafik - şifrele.
Modern versiyonları. TLS 1. Standart olarak 3; TLS 1. 2 - sadece katı politikalar altında. 1'i devre dışı bırak. 0/1. 1.
PFS ile AEAD şifre süitleri. AES-GCM veya ChaCha20-Poly1305; (EC) DHE aracılığıyla PFS.
Eğriler/Anahtar Muayene X25519 (tercihen) veya secp256r1 (P-256). RSA anahtarları ≥2048, ECDSA'dan daha iyi (P-256).
Güvenin az olduğu mTLS. Servisler arası kanallar, yönetici API'leri, brokerler, veritabanları - karşılıklı kimlik doğrulama yoluyla.
Web için HSTS. Kamu alanları için zorunlu HTTPS + ön yüklemesi.
"Encrypt-and-encrypt-again" bilinçli olarak. Çevre üzerinde TLS sonlandırma + arka uçlara yeniden şifreleme veya uçtan uca geçiş - tehdit modeline göre seçin.
Kripto çeviklik. Sıfır kesinti süresi ile eğrileri/süitleri/versiyonları değiştirme yeteneği.

4) Protokol yığını ve komut dosyaları

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: HTTP/2 için h2, HTTP/3 için h3; H2c inhibe eder (TLS olmadan).
HTTP/3/QUIC: gecikmeyi, gömülü 0-RTT ve bileşik geçişi azaltır; Seçici olarak izin 0-RTT (riski tekrarlayın).
gRPC: h2/h3 üzerinde; Zorunlu TLS, isteğe bağlı mTLS + RPC başına yetkilendirme.
WebSocket: wss ://only; Proxy/dengeleyicilerde - alanın doğru yükseltilmesi ve TLS sabitlenmesi.

4. 2 Servisler arası trafik ve servis ağları

Sidecar modeli (Istio/Linkerd, vb.). Otomatik mTLS, izin politikaları, sertifika rotasyonu.
SPIFFE/SPIRE. Merkezi olmayan hizmet kimlikleri (SPIFFE ID), SVID sertifikaları, kısa TTL'ler.
TLS parametreleri merkezileştirilmiştir. Hizmet kodundaki yapılandırma tutarsızlıklarını en aza indirin.

4. 3 Komisyoncular/Akış/Kuyruklar

Kafka/NATS/RabbitMQ: kliyent↔broker ve broker↔broker için TLS; Mümkünse mTLS.
TLS üzerinden SASL: mTLS mümkün değilse, belirteçlerle/girişlerle kimlik doğrulama, ancak kanalı şifreler.
ACL ve konu yetkilendirmesi. Şifreleme ≠ erişim kontrolü.

4. 4 Veritabanları ve önbellekler

PostgreSQL/MySQL/SQL Server: TLS, CN/SAN doğrulama, CA pin/root'u etkinleştirin.
Redis/Memcached: stunnel/TLS turp kullanın; üründe düz trafiğin yasaklanması.

4. 5 Ağ/tüneller

Veri merkezleri/bulutlar arasında: IPsec (IKEv2) veya WireGuard (modern bir ilkel küme).
Yönetici erişimi: Modern KEH/şifreleri ile SSH; Şifre yok, sadece anahtar/SSO.

4. 6 DNS ve yardımcı protokoller

DNS over HTTPS (DoH )/DNS over TLS (DoT) istemciler için ve mümkünse küme içinde.
Karışık içeriği devre dışı bırak. Http ://sayfalarında hiçbir şey https ://.

5) Sertifikalar, PKI ve Anahtar Yönetimi

PKI modeli: dış etki alanları için - genel CA; Dahili trafik için - kendi CA veya SPIRE-CA.
Otomasyon: Kubernetes için ACME/Cert-manager, kısa TTL, otomatik rotasyon.
CRL и OCSP zımbalama. Cephelerde zımbalamayı açın; Zincirleri düzenli olarak güncelleyin.
Sabitleme - dikkatle. Mobil/masaüstü istemcilerinde - acil yuvarlanma mekanizmasına sahip CA/SPKI'yi sabitleyin.
Anahtar depolama: HSM/KMS/gizli depolardaki özel anahtarlar; Minimum maruz kalma; Ağaç kesme yasağı.

6) Yapılandırmalar: uygulama profilleri

• Sürümler: TLS 1. 3 (gerekli), TLS 1. 2 (geri dönüş).

• TLS 1. 3: 'TLS _ AES _ 128 _ GCM _ SHA256', 'TLS _ AES _ 256 _ GCM _ SHA384', 'TLS _ CHACHA20 _ POLY1305 _ SHA256'.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AES128-GCM-SHA256' (gerekirse + seçenek AES256/CHACHA20).
• Eğriler: X25519, secp256r1.
• Sertifikalar: ECDSA tarafından tercih edilen, RSA-fallback.
• Güvenli başlıklar: 'Strict-Transport-Security', 'X-Content-Type-Options', 'X-Frame-Options' (duruma göre), 'Referrer-Policy'.
• Çerezler: 'Güvenli', 'HttpOnly', 'SameSite' (Lax/Strict by design).

• Müşteri sertifikası gereklidir.
• Kısa TTL istemci SVID (saat/gün), otomatik rotasyon.
• Politikalar: kimin kime bağlanabileceği (niyet tabanlı/ağ yetkilendirmesi yoluyla çalışma).

7) Performans ve güvenilirlik

Donanım hızlandırma: AES-NI/ARMv8 Kripto, tercih AES-NI olmadan CPU üzerinde ChaCha20-Poly1305.
Oturum devam ediyor: TLS 1. 3 bilet; Ömrü düşünün (parfüm ve güvenlik arasındaki denge).
0-RTT: sadece idempotent sorgular için; Tekrarlamaya karşı koruma (sunucu anti-replay mekanizmaları).
Dengeleyiciler/proxy'ler: açıkça geçiş vs sonlandırmayı seçin; Sonlandırmada - arka uca yeniden şifrele.
Gözlemlenebilirlik: ALPN el sıkışma/hata/müzakere metrikleri, TLS yüzdesi 1. 3, sertifika sona ermesi, OCSP durumu.

8) Test ve doğrulama

TLS profilini tara. Desteklenen sürümlerin/süitlerin/eğrilerin ve HSTS/OCSP'nin düzenli kontrolleri.
Negatif testler: düşürme yasağı, zayıf davaların reddi, SNI/geçerli zincir sertifikası olmayan bağlantıların başarısız olması.
Kanal pentest: MITM simülasyonları, mobil istemcilerde sabitleme kontrolleri 0-RTT tekrar oynatma girişimleri.
Kaos testleri: sertifikanın sona ermesi/iptali, OCSP/CA'nın kullanılamaması.

9) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

TLS etkin, ancak ana bilgisayar doğrulaması yok. Her zaman CN/SAN'ı kontrol ediyoruz, 'InsecureSkipVerify'ı yasaklıyoruz.
Karışık içerik. Https sayfalarındaki http kaynaklarını engelleyin, CSP kullanın.
Zayıf/modası geçmiş sürümler ve takımlar. TLS 1'i devre dışı bırak. 0/1. 1, CBC/RC4/3DES.
İçe dönük yeniden şifreleme eksikliği. Dengeleyiciden uygulamaya giden düz trafik bir risktir.
Uzun ömürlü sertifikalar. Kısa TTL'ler ve otomatik güncellemeler yapın.
Proxy arkasında kötü SNI/ALPN. TLS geçiş/sonlandırma ile SNI/ALPN iletimini düzeltin.

10) Mini tarifler (yapılandırma parçaları)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) Politikalar ve uyum

Minimum gereksinimler: TLS 1. 3 Mümkün olan yerlerde; TLS 1. 2 - sınırlı sayıda süit ile.
Düzenleme: PCI DSS/finans sektörü - zayıf sürümlerin/paketlerin yasaklanması; zorunlu rotasyon ve denetim.
Sıfır Güven yaklaşımı: iş yükü başına kimlikler, sürekli doğrulama ve hizmet düzeyi politikaları.

12) Operasyon ve SLO

SLO: % ≥99 başarılı el sıkışmaları, TLS 1'de % ≥95 trafik. 3, %0 karışık içerik.
Uyarılar: Sertifikaların sona ermesi (<14 gün), el sıkışma hatalarında artış, TLS 1 payında düşüş. 3, OCSP zımbalama hataları.
Prosedürler: CA/root'un acil olarak değiştirilmesi, tehlikeye atılan anahtarın iptal edilmesi, 0-RTT devre dışı bırakılması.

13) Kontrol listeleri

• TLS 1 devre dışı. 0/1. 1 ve zayıf süitler, AEAD ve PFS dahil.
• ALPN yapılandırılmış (h2/h3); H2C'nin yasaklanması.
• HSTS etkin (ortak alanlar için), karışık içerik yok.
• Sertifikalar otomatik olarak güncellenir, OCSP zımbalama çalışır.
• Dahili kanallar mTLS (veya WireGuard/IPsec eşdeğeri) ile korunmaktadır.
• İstemciler/SDK üzerinde doğrulanmış ana bilgisayar/zincir doğrulaması.

• TLS/ALPN/hata ve son kullanma sürümlerini izleyin.
• Kripto-çeviklik planı (yeni süitlere/eğrilere çeviri).
• Periyodik kanal pentestleri ve yapılandırma yorumları.

14) SSS

S: TLS sadece çevre üzerinde yeterli mi?
Oh hayır. İç trafik de şifrelenmelidir (mTLS/tüneller/kafes), özellikle bulutlarda ve çoklu kiralama sırasında.

S: Bir 0-RTT ihtiyacınız var mı?
C: Idempotent istekleri için noktasal olarak etkinleştirin, aksi takdirde yeniden oynatma riski nedeniyle devre dışı bırakın.

S: Veriler arası merkez için ne seçilir? IPsec mi WireGuard mı?
C: WireGuard daha basit ve daha hızlı, IPsec olgun ve yaygın olarak destekleniyor. Her ikisi de doğru yapılandırıldığında geçerlidir.

S: "Hareket halindeyken" webhook'ları nasıl koruyorsunuz?
A: Modern bir profil + gönderen sertifikası doğrulaması (mTLS ise) + yük imzası ve zaman damgası doğrulaması ile HTTPS (bkz. Webhook Teslimat Garantileri, İmza İsteği ve Doğrulama).

• "Dinlenme Şifreleme"
• "Kimlik Doğrulama ve Yetkilendirme"
• "İstekleri İmzala ve Doğrula"
• "S2S Kimlik Doğrulama"
• "Anahtar Yönetimi ve Rotasyon"