Follow

Sertifika Yaşam Döngüsünü Otomatikleştirmek: ACME, Vault ve Pratik Kontroller

🎧 Bu yazıyı dinleyebilirsiniz

Bir kurumun en sık gözden kaçırdığı opsiyonlardan biri sertifika yönetimi oluyor. Ben de uzun yıllarda birkaç kere “sertifika süresi doldu, hizmet kapandı” paniği yaşadım; o anlarda öğrendiğim en önemli şey, sertifikaları güvencesiz bir dosya kutusunda veya bir yöneticinin takvim hatırlatıcısına bırakmanın büyük risk olduğuydu. Aşağıda sertifika yaşam döngüsünü (envanter, otomasyon, izleme, acil durum planı) pratik adımlarla anlatıyorum.

Neden sertifika yönetimi kritik?

Sertifikalar —HTTPS, mTLS, kod imzalama, e-posta S/MIME— hizmetin gizliliğini ve bütünlüğünü sağlar. Bir sertifikanın beklenmedik şekilde süresi dolduğunda bağlı servislerin tamamı etkilenebilir; kullanıcılar hata sayfaları, uygulamalar bağlantı hataları görür. Ayrıca ele geçirilmiş ya da yanlış yapılandırılmış özel anahtarlar ciddi güvenlik zafiyetleri oluşturur. Bu yüzden sadece “yenileme” değil; envanter, takvim değil gerçek otomasyon ve reversibility (geri alma) planı gerekir.

Hızlı envanter ve risk haritası

İlk iş olarak elinizde ne olduğunu doğru listeleyin. Hem dış (internet-facing) hem iç (intranet, IoT, servis hesapları) sertifikaları toplayın. Basit komutlarla hızlıca özet alabilirsiniz:

# Linux: uzaktan kontrol için
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null | openssl x509 -noout -dates

# Sunucudaki sertifikaların hızlı listesi (Windows PowerShell)
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint

# Tek bir dosyadaki sertifika bitiş tarihini göster
openssl x509 -in /etc/ssl/certs/example.crt -noout -enddate

Bu çıktıların CSV/JSON’a dökülmesiyle kritik sertifikaları, sahibini ve bitiş tarihlerini gösteren basit bir envanter oluşturabilirsiniz. Kriter örneği: 30 gün içinde süresi dolacak, wildcard sertifikalar, root/CA’larla ilişkili özel anahtarlar.

Otomasyon seçenekleri: ACME, Vault, HSM

Otomasyona karar verirken üç yaygın yaklaşım var; her biri farklı seviyede kontrol ve güvenlik sağlar.

  • ACME (Let’s Encrypt, acme.sh, Certbot): İnternet’e açık servisler için hızlı ve ücretsiz. Certbot veya acme.sh ile Nginx/Apache otomasyonu kolayca kuruluyor.
  • HashiCorp Vault PKI: İç sertifikalar, kısa ömürlü sertifikalar ve dinamik istemci sertifikaları için uygundur. Vault, merkezi güvenlik, raf ömrü (TTL) ve görevlendirilmiş revocation mekanizmaları sağlar.
  • HSM / Cloud KMS: Özel anahtarların donanım veya cloud KMS içinde tutulması gerekiyorsa entegrasyon şart. Anahtar asla düz dosyada olmamalı.

Basit ACME yenileme örneği (certbot):

# Sertifika alma
sudo certbot --nginx -d example.com -d www.example.com

# Yenileme testi
sudo certbot renew --dry-run

# Cron / systemd timer genelde otomatik yenileme sağlar

Vault ile kısa örnek (konsept):

# Vault PKI üzerinden sertifika isteme (Vault yapılandırması sonrası)
vault write pki/issue/example-dot-com common_name="app.example.com" ttl="72h"

İzleme ve doğrulama — otomasyon yeterli değil

Otomasyon kurulduktan sonra doğrulama katmanı olmazsa eksik kalır. İzleme şu başlıkları içermeli:

  • Sertifika bitiş takibi (30/14/7/1 gün alarmları).
  • Gerçek servis üzerinden doğrulama (TLS handshake testi, OCSP stapling kontrolü).
  • Yenileme sonrasında canary testi: trafik küçük bir kesimde yenilenmiş sertifikayla doğrulanmalı.

Örnek izleme komutu (basit):

# OpenSSL ile OCSP / expiry kontrolü
openssl s_client -connect app.example.com:443 -servername app.example.com -status

Acil durum: iptal (revoke) ve yedekleme planı

Bir anahtar ele geçirilmişse hızlıca iptal ve yeni sertifika çıkarma kabiliyeti hayati. Planınızda şunlar olmalı:

  • Revocation prosedürü ve sorumlular: kim iptal eder, kim yeni sertifika dağıtır.
  • Yedek anahtar veya alternatif CA yol haritası (özellikle dış bağımlılıklar için SLA gözden geçirilmeli).
  • Rollback planı: Yeni sertifika sorun yaratırsa eski duruma dönüş adımları (DNS veya yük dengeleyici ayarlarıyla hızla switch yapılabilecek şekilde tasarlayın).

Pratik öneriler — benim uyguladıklarım

  • Wildcard sertifikaları minimumda tutun; mümkünse servis bazlı kısa ömürlü sertifikalara geçin. Benzer hizmetlerde wildcard yüzünden geniş çaplı yeniden başlatmalar yaşamıştık.
  • Her yeni sertifika dağıtımında küçük bir “canary” havuzu belirleyin. 5 sunucuda test edilmeden prod trafiğe vermem.
  • Yedekleme: Özel anahtarlar için offsite şifreli yedek + audit logging. Anahtar taşınması gerektiğinde HSM/KMS tercih edin.
  • İzleme entegrasyonu: Prometheus + blackbox_exporter ile SSL expiry zamanlarını metric olarak alın, Grafana’da paneller oluşturun.
  • Dökümantasyon: Sertifikanın hangi sırada yenileneceği, DNS doğrulama adımları, sorumlu kişi ve rollback adımları açıkça yazılı olsun.

Başlarken kısa yol haritası

1) 1 hafta içinde tam envanter çıkartın. 2) Kritik dış servisler için ACME otomasyonunu kurun ve dry-run yapın. 3) İç PKI gerekiyorsa Vault POC başlatın. 4) İzleme ve canary testlerini devreye alın. 5) Revocation/rollback prosedürünü tatbikatla doğrulayın.

Benim deneyimim: bir kez haftasonu döndüğümde müşteri portalının kapalı olduğunu gördüm; sebep basitti: wildcard sertifika süresi dolmuştu ve yenileme tek bir kişinin e-posta hatırlatıcısına bağlıydı. O günden sonra otomasyonla beraber izleme ve acil durum talimatı olmadan bir adım bile atmamaya karar verdim.

Sertifika yönetimi sıkıcı gözüken ama operasyonel açıdan düşük maliyetle büyük riskleri azaltan bir alandır. Küçük bir POC ile başlayın; otomasyonun işe yaradığını gördükçe kapsamı genişletmek en azından benim için hep işe yaradı. Şimdi envanterle başlayın — en azından bir komut çalıştırın ve hangi sertifikaların 30 gün içinde biteceğini görün.

Comments
Join the Discussion and Share Your Opinion
Add a Comment

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


Newsletter
Join Design Community
Get the latest updates, creative tips, and exclusive resources straight to your inbox. Let’s explore the future of design and innovation together.