1. GİRİŞ

Public Key Infrastructure (PKI), dijital dünyada kimlik doğrulama, veri bütünlüğü ve gizlilik sağlamak için kullanılan merkezi bir güven modelidir. PKI; asimetrik kriptografi, sertifika otoriteleri (CA), sertifika yönetimi ve anahtar yaşam döngüsü uygulamalarını bir araya getirir. İnternet servisleri, kurumsal VPN'ler, e‑imza, belge doğrulama ve cihaz kimliklendirme gibi kritik alanlarda PKI temel rol oynar.

Bu neden bugün önemli?

• Dijital dönüşüm ve bulut hizmetlerinin yaygınlaşması, güvenilir kimlik ve iletişim kanalları gerektirir.
• Tedarik zinciri saldırıları ve sahte sertifika olayları, PKI süreçlerinin doğru tasarımının önemini artırdı.
• IoT cihazlarının kimliklendirilmesi, mobil uygulama güvenliği ve mikroservis tabanlı iç iletişim PKI ile güvence altına alınır.

Kimler için önemli?

• Güvenlik mimarları ve platform mühendisleri
• Operasyon ekipleri (SRE/DevOps) ve PKI yöneticileri
• Uygulama geliştiriciler ve entegratörler
• Uyumluluk ve risk yönetimi profesyonelleri

2. KAVRAMSAL TEMELLER

2.1 PKI nedir — tanım

PKI, açık anahtar kriptografisini (public/private key) güvenilir bir biçimde kullanabilmek için gerekli organizasyonel yapıyı, süreçleri ve teknik araçları ifade eder. Temel öğeler: Certificate Authority (CA), Registration Authority (RA), sertifika deposu (CRL/OCSP), Certificate Policy (CP) ve anahtar yönetim süreçleri.

2.2 Temel bileşenler

• Root CA: En üst yetkili sertifika otoritesi; root private key yüksek güvenlikle korunur (genellikle HSM içinde).
• Intermediate CA: Root'un imzasıyla yetkilendirilmiş ara CA'lar; operasyonel iş yükünü ve riskleri sınırlandırır.
• Registration Authority (RA): Sertifika taleplerini doğrulayan organizasyonel rol veya hizmet.
• Certificate Revocation List (CRL) / OCSP: İptal edilmiş sertifikaların yayınlandığı mekanizmalar.
• Certificate Policy (CP) / Certification Practice Statement (CPS): Sertifika oluşturma, doğrulama ve iptal süreçlerinin kurumsal kuralları.

2.3 Terminoloji

• CSR (Certificate Signing Request): Sertifika talep verisi, public key ile birlikte kimlik bilgilerini içerir.
• KEK/DEK: PKI bağlamında anahtar korumada kullanılan terimler; genelde KMS/HSM entegrasyonu gerektirir.
• Key usage / Extended key usage: Sertifika içinde belirtilen kullanım kısıtları (digitalSignature, keyEncipherment, serverAuth vb.).

3. NASIL ÇALIŞIR?

3.1 Sistem mimarisi — CA hiyerarşisi

Güvenli PKI mimarisi genellikle root CA — intermediate CA — issuing CA şeklinde katmanlı bir yapı önerir. Root CA offline tutulur; intermediate CA'lar çevrimiçi operasyonu yönetir. Bu yaklaşım root private key'in riskini minimize eder. Sertifika istekleri (CSR) RA tarafından doğrulanır, issuing CA sertifikayı oluşturur ve yayınlar.

3.2 Sertifika yaşam döngüsü

1. Key pair oluşturma: Cihaz/uygulama kendi private/public anahtarını üretir veya bir KMS/HSM tarafından üretilir.
2. CSR gönderimi: Public key ve kimlik bilgileri CA'ya iletilir.
3. Doğrulama: RA kimlik doğrulaması (domain kontrolü, organizasyon doğrulaması vb.).
4. İmzalanma: CA imzası ile sertifika verilir; validity (geçerlilik süresi) belirlenir.
5. Yenileme / Rotation: Süre sonunda veya risk durumunda anahtar/ser­tifika yenilenir.
6. İptal (revoke): Compromise veya misconfiguration halinde CRL/OCSP üzerinden sertifika iptal edilir.

3.3 Anahtar yönetimi ve HSM entegrasyonu

Root ve critical CA private key'leri HSM içinde saklanmalı; KMS entegrasyonları ile uygulama anahtarları güvenle korunmalıdır. Anahtar üretim, backup, export ve destruction politikaları açıkça tanımlanmalıdır. HSM'ler FIPS 140‑2/3 uyumluluğu için tercih edilir.

3.4 Sertifika doğrulama — CRL ve OCSP

Sertifika iptal bilgisi CRL (periyodik liste) veya OCSP (real‑time responder) ile yayınlanır. Yüksek performans gerektiren servislerde OCSP stapling ve OCSP caching uygulanmalı; offline ya da izole ortamlarda CRL kullanımı planlanmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 TLS/HTTPS

Web sunucuları genellikle CA tarafından imzalanmış sertifikalarla TLS terminasyonunu gerçekleştirir. Modern uygulamalarda otomasyon (ACME/Let's Encrypt, cert‑manager) ile sertifika yaşam döngüsü otomatikleştirilir. Ancak ACME otomasyonunda domain kontrolü ve rate limit politikalarına dikkat edilmelidir.

4.2 Email S/MIME ve dijital imza

Kurumsal e‑posta doğrulama ve e‑imza için S/MIME sertifikaları PKI altyapısıyla sağlanır. E‑imza düzenleyici gereksinimleri (qualified eSignatures) ülkeden ülkeye farklılık gösterir; bu uygulamalarda attest ve audit gereksinimleri önemlidir.

4.3 VPN, client authentication ve mTLS

Çoğu kurumsal VPN, client sertifika tabanlı kimlik doğrulama kullanır. Mikroservisler arası güvenli iletişim için mTLS kullanımı giderek yaygınlaşıyor; burada sertifika dağıtımı, yenileme ve revocation otomasyonu kritik bir operasyonel gereksinimdir.

4.4 IoT cihaz kimliklendirme

Milyonlarca cihaza sertifika temini ve yaşam döngüsü zorludur. Cihaz üretim süreçlerinde secure element, device provisioning ve enrollment süreçlerinin PKI ile entegrasyonu gerekir. Device identity kompromize olursa fleet düzeyinde revoke planı uygulanmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Standardize edilmiş kimlik doğrulama ve güven iletişimi sağlar.
• Anahtar compromise durumunda revoke ile hızlı müdahale imkânı verir.
• HSM entegrasyonu ile root of trust oluşturur ve regülasyon uyumunu kolaylaştırır.

Sınırlamalar

• Operasyonel karmaşıklık ve yönetim maliyeti yüksektir.
• Yanlış konfigürasyon veya CA ihlali tüm ekosisteme güven sorunları yaratabilir.
• Offline veya air‑gapped ortamlar için sertifika dağıtımı zordur.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Tasarım ve operasyon

• Root CA'yı offline tutun; intermediate CA'larla operasyonu yönetin.
• HSM veya KMS kullanarak private key'leri koruyun; FIPS 140 uyumluluğunu değerlendirin.
• Sertifika yaşam döngüsünü otomatikleştirin: CSR generation, issuance, renew ve revocation süreçleri CI/CD tarzı otomasyon ile yönetilsin.
• Certificate Policy (CP) ve Certification Practice Statement (CPS) dokümanlarını oluşturun ve yayınlayın.

7.2 Güvenlik ve göndergeler

• Key usage ve EKU (Extended Key Usage) kısıtlarını sertifikalarda açıkça belirtin.
• OCSP stapling, short‑lived certs ve OCSP caching ile revocation kontrolünü optimize edin.
• Sertifika ve anahtar erişimlerini RBAC/ABAC ile sınırlandırın; audit log'larını merkezi SIEM'e gönderin.

7.3 IoT ve büyük ölçek

• Device provisioning için secure enrollment ve supply‑chain güvenliğini uygulayın.
• Cihaz seviyesinde attestation (TPM/secure element) ve fleet revocation planları geliştirin.
• Ephemeral credential kullanımını değerlendirerek compromise blast radius'u azaltın.

8. SIK YAPILAN HATALAR

• Root CA anahtarını çevrimiçi tutmak — kritik hata.
• Sertifika validity sürelerinin çok uzun tutulması — compromise riskini artırır.
• Revocation mekanizmalarını uygulamamak veya OCSP/CRL kontrollerini atlamak.
• Otomasyon eksikliği: manual sertifika yönetimi hatalara ve gecikmelere yol açar.

9. GELECEK TRENDLER

9.1 Short‑lived ve automated certificates

Short‑lived (dakika/saat bazlı) sertifikalar ve otomatik issuance (ACME, cert‑manager) yaygınlaşacak; bu yaklaşım compromise etkisini azaltır fakat güçlü otomasyon gerektirir.

9.2 Decentralized identity ve DPKI (Distributed PKI)

Blockchain ve DID (Decentralized Identifiers) çalışmalarının PKI alanına etkisi araştırılıyor; merkeziyetçi CA modellerine alternatifler gündeme gelebilir ancak kurumsal kabul zaman alacaktır.

9.3 Post‑quantum PKI hazırlığı

Asimetrik kriptografinin kuantum tehditlerine karşı dayanıklılığı için hibrid imzalama ve PQC entegrasyonları PKI ekosisteminde planlanmalı. Root/Intermediate CA key rotation stratejileri PQC'yi kapsayacak şekilde revize edilecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Root CA neden offline tutulmalı?

   Root CA private key'in çevrimiçi olması, ana root'un kompromize olmasına ve tüm PKI ekosisteminin güveninin çökmesine neden olur. Offline root, intermediate'ların imzalanması için kontrollü ortamda kullanılır.

2. 2. OCSP mi CRL mi tercih etmeliyim?

   OCSP gerçek zamanlı doğrulama sağlar ve daha düşük bant genişliği kullanır; ancak responder availability gerektirir. CRL offline ve air‑gapped ortamlarda tercih edilebilir. Genelde OCSP + CRL kombinasyonu pratikte kullanılır.

3. 3. Sertifika süresini ne kadar tutmalıyım?

   Kısa süreler (günler/aylar) compromise riskini azaltır; modern uygulamalar için 90 gün veya daha kısa süreler önerilir. Uygulama ihtiyacına göre balance kurun.

4. 4. HSM kullanmalı mıyım?

   Regülasyon veya yüksek güvenlik gereksinimi varsa evet. HSM, private key'lerin fiziksel ve mantıksal olarak korunmasını sağlar.

5. 5. ACME sertifika otomasyonu güvenli midir?

   ACME güvenlidir ancak domain kontrolü ve erişim kontrolü mekanizmalarının (HTTP challenge, DNS challenge) doğru yapılandırılması gerekir. Otomasyon yetkilerini ve rate limitleri gözetin.

6. 6. mTLS uygulamak zor mu?

   Mikroservis ortamlarında mTLS, sertifika dağıtımı ve yenileme otomasyonu gerektirir; service mesh veya cert‑manager gibi araçlarla bu süreçler kolaylaştırılabilir.

7. 7. IoT cihazları için PKI en iyi uygulaması nedir?

   Device provisioning, secure element/TPM, secure enrollment, attestation ve fleet revocation planı temel taşlardır. Üretim hattında anahtar injection yerine üretim sonrası secure provisioning önerilir.

8. 8. PKI ihlali durumunda hızlı müdahale nasıl olmalı?

   Incident playbook: ilgili sertifikaların revoke edilmesi, OCSP/CRL güncellemesi, affected services'in rotation ve reissuance planı, müşteri bildirimi ve regülatif raporlama adımlarını içermelidir.

Anahtar Kavramlar

• Root CA: En üst seviye sertifika otoritesi.
• Intermediate CA: Operasyonel sertifika issuer'ları.
• CSR: Sertifika imzalama talep verisi.
• OCSP / CRL: Sertifika iptal mekanizmaları.
• HSM: Anahtarların donanım tabanlı koruması.

Öğrenme Yol Haritası

1. 0–1 ay: Asimetrik/simetrik kriptografi temel kavramları, X.509 sertifika formatı ve TLS çalışma mantığını öğrenin.
2. 1–3 ay: OpenSSL ile CSR/sertifika işlemleri yapın, küçük bir offline CA/Intermediate CA kurup test edin.
3. 3–6 ay: HSM/KMS entegrasyonu, OCSP/CRL mekanizmaları ve sertifika otomasyonu (ACME, cert‑manager) konularında uygulama geliştirin.
4. 6–12 ay: IoT provisioning, attestation, post‑quantum hazırlığı ve DPKI/Decentralized ID konularına odaklanın.