Quantum-Safe DevOps: Mevcut CI/CD Pipeline’larınızı Kriptografik Borçtan Koruyun
Modern devops pratiklerinde güvenlik genellikle pipeline’a bir SAST/DAST aracı sıkıştırmak, image’ları Trivy ile taramak ve artifact’leri RSA-2048 ile imzalamaktan ibaret sanılıyor. Oysa kapıda sessizce büyüyen devasa bir problem var: Kriptografik borç. Kuantum bilgisayarlar pratik ölçeğe ulaştığında, bugün asimetrik cryptography temelleri üzerine inşa ettiğimiz tüm pipeline security mimarisi domino taşı gibi devrilecek. Daha da kötüsü, tehdit “o gün” başlamayacak; Harvest Now, Decrypt Later (HNDL) saldırıları sebebiyle bugünden depolanan imzalar ve şifreli trafik yarın aleyhimize delil olarak kullanılacak. Bu yazıda teorik fizik tartışmalarına girmeden, doğrudan production hatlarında uygulayabileceğiniz quantum-safe dönüşüm stratejilerini ve pratik konfigürasyonları masaya yatırıyoruz.
Neden Şimdi? Moska Teoremi ve CI/CD Gerçekliği
Kuantum tehdidini konuşurken çoğu mühendisin düştüğü hata, “Q-Day gelene kadar en az 8-10 yılımız var” rehavetine kapılmaktır. Kriptograf Michele Mosca’nın denklemi durumu çok net özetler: X + Y > Z ise sisteminiz zaten risk altındadır. Burada X verinizin gizli kalması gereken süre, Y sistemlerinizi kuantum dirençli hale getirme süreniz, Z ise kuantum bilgisayarların RSA/ECC’yi kıracağı tahmini tarihtir.
Bir bankanın veya fintech girişiminin CI/CD pipeline’ında build edilen artifact’lerin, firmware imajlarının veya Git commit’lerinin imza geçerlilik ömrü bazen 10-15 yılı bulur. Eğer bugün artifact imzalarken ML-DSA (CRYSTALS-Dilithium) veya stateful hash-based imzalara geçiş yapmazsanız, 2030’da geçmişe dönük supply chain doğrulamalarınızın hiçbir matematiksel güvencesi kalmayacaktır.
1. Git İletişimi: OpenSSH Hibrit Anahtar Değişimine Geçiş
Git runner’larınız repository’lere SSH üzerinden bağlanıyorsa, aradaki trafik bugün kaydedilip gelecekte çözülebilir. OpenSSH 9.0 ve üzeri sürümler, varsayılan olarak Streamlined NTRU Prime ve X25519 hibrit algoritmasını (sntrup761x25519-sha512@openssh.com) destekliyor. Bu hibrit yapı şu anlama gelir: Klasik X25519 kırılsa bile kuantum-dirençli katman sizi korur; yeni algoritmada bilinmeyen bir açık çıksa bile klasik katman güvence sağlar.
CI/CD runner’larınızın ve Git sunucularınızın (GitLab, self-hosted Gitea vs.) SSH konfigürasyonunu zorunlu olarak hibrit moda geçirmek için /etc/ssh/ssh_config (veya sunucu tarafında sshd_config) dosyasında KexAlgorithms direktifini güncelleyin:
# /etc/ssh/sshd_config veya CI Runner ~/.ssh/config
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org
# Host key olarak klasik Ed25519 kullanmaya devam etseniz bile,
# oturum anahtarı değişimi (KEX) kuantum dirençli hale gelir.
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512
Runner üzerinde bağlantının hibrit algoritma kullanıp kullanmadığını doğrulamak için şu komutla debug çıktısını inceleyin:
ssh -vvv git@gitlab.internal.corp 2>&1 | grep "kex: algorithm:"
# Çıktıda şunu görmelisiniz:
# debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
2. Artifact İmzalama: Cosign ve Post-Quantum Algoritmalar
Yıllardır Cosign ile container imzalıyoruz. Peki o imzalar neye güveniyor? ECDSA P-256 veya RSA-4096. Shor algoritması çalışan bir kuantum bilgisayar karşısında P-256’nın ömrü birkaç saniyedir. NIST, Ağustos 2024’te resmi FIPS standartlarını yayımladı: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) ve FIPS 205 (SLH-DSA).
Şu an üretim ortamlarında saf PQC (Post-Quantum Cryptography) kullanmak imza boyutları nedeniyle (RSA’in 256 baytına karşılık Dilithium-3’ün ~3.3 KB boyutu) overhead yaratabilir. Bu yüzden ara çözüm Hibrit İmzalar veya liboqs entegrasyonudur. Sigstore ekosistemi PQC desteğini deneysel olarak sürdürürken, build pipeline’ınızda OpenSSL 3.x ve oqsprovider kullanarak kendi post-quantum PKI altyapınızı ayağa kaldırabilirsiniz.
Runner container’ı içerisinde ML-DSA-65 (Dilithium3) tabanlı bir keypair üretip artifact imzalamak için örnek bir yaklaşım:
# liboqs ve oqsprovider kurulu bir base image üzerinde:
# 1. Post-Quantum Private Key üret (FIPS 204 / ML-DSA-65)
openssl req -x509 -new -newkey mldsa65 \
-keyout pqc_private.key \
-out pqc_cert.crt \
-nodes -subj "/CN=CI-PQC-Signer/O=KertenKerem" \
-provider oqsprovider -provider default
# 2. Release artifact'ının (örneğin binary veya tarball) SHA-256 hash'ini al
sha256sum release-v1.4.0.tar.gz | awk '{print $1}' > artifact.digest
# 3. Hash'i ML-DSA anahtarıyla imzala
openssl dgst -sign pqc_private.key \
-provider oqsprovider -provider default \
-out artifact.sig artifact.digest
# 4. Doğrulama testi (Deployment aşamasında çalışacak kod)
openssl dgst -verify <(openssl x509 -in pqc_cert.crt -pubkey -noout -provider oqsprovider) \
-signature artifact.sig \
-provider oqsprovider -provider default \
artifact.digest
Bu akışın klasik Cosign akışına göre tek farkı, kullanılan matematiksel yapının lattice-based (örgü tabanlı) olmasıdır. Bir imzayı production cluster’ında Admission Controller seviyesinde doğrulamak istiyorsanız, gatekeeper veya Kyverno pod’larınızın da liboqs kütüphanesini tanıyan OpenSSL/BoringSSL runtime’larına sahip olması gerektiğini unutmayın.
3. Kriptografik Envanter: CBOM (Cryptographic Bill of Materials)
SBOM (Software Bill of Materials) çıkarmayı öğrendik; peki uygulamanızın hangi şifreleme kütüphanelerine, hangi anahtar uzunluklarına ve hangi TLS versiyonlarına bağımlı olduğunu biliyor musunuz? Kodunuz doğrudan crypto/tls çağırıyor olabilir ama üçüncü parti bir Go paketi derleme anında RSA-1024’e hardcode edilmiş eski bir algoritma kullanıyor olabilir.
CycloneDX standardı, CBOM konseptiyle kriptografik varlıkların taranmasını ve listelenmesini destekler. CI aşamasına ekleyeceğiniz bir CBOM adımı, kuantum göçü (migration) başladığında envanter çıkarmak için harcayacağınız ayları kurtarır.
# Syft ile projenin kriptografik bağımlılıklarını içeren SBOM JSON çıktısı üretme
syft dir:. -o cyclonedx-json=bom.json
# bom.json içerisindeki zayıf kriptografik bağımlılıkları CI aşamasında filtreleme
jq '.components[] | select(.name | test("crypto|tls|ssl|ssh")) | {name: .name, version: .version}' bom.json
Eğer pipeline’ınızda kurumsal bir tarama yapıyorsanız, IBM CBOM Toolkit veya benzeri statik analiz araçlarını derleme öncesi kancalara (pre-commit / CI gate) entegre ederek kod tabanında crypto.GenerateKey(rsa.Reader, 2048) gibi çağrıları CI seviyesinde hata verdirerek engelleyebilirsiniz:
# semgrep ile CI pipeline'ında kuantum-zayıf anahtar kullanımını fail etme örneği
semgrep --config=p/crypto \
--lang=go \
--pattern='rsa.GenerateKey($R, 2048)' \
--error \
./src
4. HashiCorp Vault ve Transit Secret Motoru
Pipeline içerisinde hassas environment variable’ları şifrelemek (envelope encryption) için yaygın olarak HashiCorp Vault Transit Engine kullanılır. Mevcut transit engine konfigürasyonunuz büyük olasılıkla aes256-gcm96 ile data encryption, anahtar değişimi için ise ECDSA/RSA kullanıyordur. AES-256, kuantum bilgisayarlar karşısında güvenlidir (Grover algoritması anahtar arama uzayını 2^128’e düşürür ki bu hâlâ pratikte kırılamaz bir seviyedir). Buradaki asıl problem, Vault client ile server arasındaki mTLS oturumu ve transit key’lerin wrap edilme yöntemidir.
Vault mTLS iletişimini güvenceye almak için, reverse proxy ve ingress seviyesinde TLS 1.3 zorunlu tutulmalı ve desteklenen cipher suite’ler sınırlandırılmalıdır:
# NGINX veya Cloud Ingress TLS 1.3 konfigürasyonu
ssl_protocols TLSv1.3;
# Kuantum sonrası anahtar değişimini destekleyen hibrit gruplar (X25519MLKEM768)
# Envoy / Nginx son sürümlerinde BoringSSL desteği ile aktifleştirilebilir
ssl_ecdh_curve X25519MLKEM768:x25519:secp384r1;
Cloudflare ve Google Chrome’un halihazırda üretimde kullandığı X25519MLKEM768 hibrit anahtar değişim mekanizması, pipeline runner’larınız ile internal API’larınız arasındaki veri trafiğini HNDL saldırılarına karşı bugünden korur.
DevOps Mühendisleri İçin Aksiyon Planı
Kriptografik dönüşüm, son gün yapabileceğiniz bir “hotfix” değildir. Bugün almanız gereken aksiyonlar şunlardır:
1. SSH Altyapısını Denetleyin: Tüm CI runner ve bastion host’larda OpenSSH 9.0+ sürümüne geçin ve hibrit KEX algoritmalarını zorunlu kılın.
2. CBOM Üretin: Build süreçlerinize SBOM yanında kriptografik varlık taramalarını ekleyin; kütüphanelerinizdeki sert kodlanmış asimetrik anahtar boyutlarını tespit edin.
3. AES-128’i Terk Edin: Simetrik şifrelemede taban çizgisi olarak her yerde AES-256 ve ChaCha20-Poly1305 kullanın.
4. Kriptografik Esneklik (Crypto-Agility) Kazanın: Kod içinde algoritma isimlerini string parametre olarak geçmeyin; anahtar yönetimini soyutlayan provider katmanları kullanın ki NIST FIPS 204/205 kütüphaneleri genel paket yöneticilerine tam girdiğinde sadece config değiştirerek göç edebilin.
Kuantum çağı geldiğinde pipeline’ları baştan yazmak zorunda kalmamak için mimarideki kriptografik borcu bugünden amorti etmeye başlayın.