SSL Private Key (Özel Anahtar) Güvenliği

Bir SSL sertifikası kurduğunuzda aslında iki ayrı dosyayla çalışırsınız: herkese açık olan sertifika (public sertifika) ve sizden başka kimsenin görmemesi gereken özel anahtar (private key). Sertifikanın tarayıcıya sunulan, doğrulanabilen, "bu site gerçekten clou.tr" diyen kısmı herkesin görmesi için vardır. Özel anahtar ise madalyonun gizli yüzüdür: TLS el sıkışması sırasında sunucunun kimliğini matematiksel olarak ispatlayan, şifrelenmiş trafiği çözebilen ve dijital imza atabilen tek parçadır. Bu dosya sızarsa, saldırgan sizin adınıza HTTPS trafiği imzalayabilir, kullanıcılarınızı kandırabilir ve ortadaki adam (MITM) saldırılarıyla şifreli iletişimi çözebilir.

Bu yüzden özel anahtar güvenliği, SSL kurulumunun en çok ihmal edilen ama en kritik parçasıdır. Çoğu güvenlik olayı sertifikanın kendisinden değil, özel anahtarın yanlış izinlerle bırakılmasından, bir yedekleme klasöründe düz metin olarak durmasından ya da yanlışlıkla bir Git deposuna commit edilmesinden kaynaklanır. Bu rehberde özel anahtarın neden asla paylaşılmaması gerektiğini, sunucuda doğru dosya izni ve sahipliğin (600 ve root) nasıl ayarlandığını, anahtarı parola ile nasıl koruyacağınızı, güvenli yedekleme stratejilerini ve en önemlisi anahtar sızdığında sertifikayı hemen iptal edip yeniden üretme adımlarını kıdemli bir sistem yöneticisinin bakış açısıyla anlatacağız.

Private Key Nedir ve TLS'te Ne İşe Yarar?#

Özel anahtar, asimetrik şifrelemenin (public-key cryptography) size ait yarısıdır. Bir SSL/TLS sertifikası oluştururken önce bir anahtar çifti üretirsiniz: birbirine matematiksel olarak bağlı bir özel anahtar (.key) ve bir açık anahtar. Açık anahtar sertifika imzalama isteğinin (CSR) içine gömülür, sertifika otoritesi (CA) bunu imzalar ve size sertifikayı (.crt / .pem) verir. Özel anahtar ise hiçbir zaman sunucudan çıkmaz — CSR'yi imzalarken bile CA'ya gönderilmez.

TLS el sıkışması sırasında istemci (tarayıcı) sunucudan bir imza ister. Sunucu bu imzayı yalnızca özel anahtarla üretebilir; tarayıcı ise sertifikanın içindeki açık anahtarla bunu doğrular. Yani "bu sunucu gerçekten bu sertifikanın sahibi mi?" sorusunun cevabı tamamen özel anahtarın gizliliğine bağlıdır. SSL sertifikasının bütününü ve doğrulama sürecini daha ayrıntılı görmek isterseniz SSL sertifikası nedir rehberimize göz atabilirsiniz.

Tipik bir RSA veya ECDSA özel anahtarını üretme komutu şöyledir:

# 2048-bit RSA anahtar + CSR birlikte
openssl req -new -newkey rsa:2048 -nodes \
  -keyout ornek.com.key \
  -out ornek.com.csr

# Daha modern ve hızlı ECDSA (P-256) anahtar
openssl ecparam -genkey -name prime256v1 | \
  openssl ec -out ornek.com.key

Buradaki -nodes ("no DES") parametresine dikkat edin: anahtarı parolasız üretir. Otomatik ortamlarda pratik olsa da, aşağıda göreceğimiz gibi parola koruması ek bir güvenlik katmanıdır.

Özel Anahtar Neden Asla Paylaşılmaz?#

Özel anahtar, sunucunuzun dijital kimliğidir. Onu paylaşmak, ev anahtarınızın bir kopyasını tanımadığınız birine vermek gibidir; üstelik bu kopya sınırsız sayıda çoğaltılabilir ve geri alınamaz. Bir kez bir e-postaya eklendiğinde, bir destek biletine yapıştırıldığında veya bir sohbet uygulamasına atıldığında o anahtarın artık "gizli" olduğunu varsayamazsınız. Güvenlik dünyasında altın kural nettir: özel anahtarı gören her sistem, o anahtarı ele geçirmiş sayılır.

Anahtarın sızması durumunda saldırganın neler yapabileceğini somutlaştıralım:

• Kimlik taklidi: Sitenizin sertifikasını kendi sunucusunda kullanıp, DNS zehirleme veya ağ araya girme ile kullanıcılarınızı sahte bir "geçerli sertifikalı" siteye yönlendirebilir. Tarayıcı yeşil kilidi gösterir çünkü sertifika ve anahtar gerçekten eşleşir.
• Trafik çözme: Eğer forward secrecy (PFS) sağlamayan eski bir şifre paketi (örneğin RSA key exchange) kullanılıyorsa, saldırgan daha önce kaydettiği şifreli trafiği geçmişe dönük olarak çözebilir.
• Sahte imza: Anahtarla imzalanan her şey — kod imzalama senaryolarında yazılım, API isteklerinde token — güvenilir kabul edilir.

Bu yüzden hosting sağlayıcınız, iş ortağınız ya da bir "teknik destek" kimseye özel anahtarı asla göndermeyin. Meşru hiçbir sertifika otoritesi veya barındırma firması sizden özel anahtarınızı istemez. Bir CDN veya yük dengeleyiciye sertifika yüklerken bile, mümkünse anahtarı o platformda yeniden üretmeyi tercih edin. Anahtarınızın nerede bulunduğunu her zaman bilmelisiniz; kaç kopyası olduğunu sayabilmelisiniz.

Aşağıdaki tablo, hangi dosyaların paylaşılabilir hangilerinin gizli olduğunu netleştirir:

Sunucuda Dosya İzinleri ve Sahiplik: 600 ve root Kuralı#

Özel anahtar sunucuda düz bir dosya olarak durur, dolayısıyla ilk savunma hattınız işletim sisteminin dosya izinleridir. Kural basit: anahtar dosyasını yalnızca root okuyabilmeli, başka hiçbir kullanıcı erişememelidir. Bu, 600 (yalnızca sahip okuma+yazma) izni ve root:root sahipliği demektir. Dizin de en fazla 700 olmalı ki listeleme bile yapılamasın.

# Anahtar dizini ve dosya izinlerini sıkılaştır
chown root:root /etc/ssl/private/ornek.com.key
chmod 600 /etc/ssl/private/ornek.com.key
chmod 700 /etc/ssl/private

# Kontrol et
ls -l /etc/ssl/private/ornek.com.key
# -rw------- 1 root root 1704 Jul 10 09:12 ornek.com.key

Buradaki en sık yapılan hata, anahtarı 644 (herkes okuyabilir) bırakmaktır. 644 demek, sunucudaki www-data, nobody ya da ele geçirilmiş herhangi bir uygulama kullanıcısının anahtarı okuyabilmesi demektir. Bir PHP açığı ya da yanlış yapılandırılmış bir dosya yöneticisi, tek satırlık bir okuma ile anahtarınızı dışarı sızdırabilir. Web sunucusu (Nginx/Apache) anahtarı okumaya yalnızca master process başlangıçta root olarak çalıştığı için ihtiyaç duyar; worker'lar düşük yetkiyle çalışır ve anahtarı belleğe zaten yüklemiştir. Yani 644 vermenize gerek yoktur.

Nginx ve Apache tarafında yapılandırma anahtarı yalnızca yolla referans alır, içeriğini kopyalamaz:

server {
    listen 443 ssl;
    server_name ornek.com;

    ssl_certificate     /etc/ssl/certs/ornek.com.crt;
    ssl_certificate_key /etc/ssl/private/ornek.com.key;  # 600, root:root
    ssl_protocols       TLSv1.2 TLSv1.3;
}

Anahtar dosyalarının doğru izinlere sahip olup olmadığını periyodik denetlemek için basit bir tarama yazabilirsiniz:

# 600'den gevşek izinli tüm anahtarları bul
find /etc/ssl /etc/letsencrypt /etc/nginx -name '*.key' \
  -perm /077 -exec ls -l {} \;

Bu komut, grup veya diğerlerine (o77) herhangi bir izin veren tüm .key dosyalarını listeler; çıktı boş gelmelidir. Sunucunuza SSH ile bağlanıp bu tür denetimleri yaparken güvenli bir oturum hijyeni izlemek de önemlidir; bu konuda SSH bağlantısı ve güvenliği rehberimiz kapsamlı bir başvuru kaynağıdır. Paylaşımlı hosting kullanıyorsanız izin yönetimi zaten sağlayıcı tarafından ele alınır; kök erişimi sizde olan bir VDS veya sanal sunucu yönetiyorsanız bu denetim tamamen sizin sorumluluğunuzdadır.

Anahtarı Parola ile Koruma (Passphrase)#

Dosya izinleri diskteki anahtarı korur, ancak disk çalınırsa ya da bir yedek dosyası sızarsa düz metin anahtar savunmasız kalır. İşte bu yüzden anahtarı bir parola (passphrase) ile şifrelemek ikinci bir katman ekler: anahtar diskte AES ile şifrelenmiş durur ve yalnızca doğru parola girildiğinde açılır. Böylece anahtar dosyası tek başına çalınsa bile parola olmadan işe yaramaz.

Mevcut bir parolasız anahtarı şifrelemek ya da tersini yapmak kolaydır:

# Parolasız anahtara parola ekle (AES-256 ile şifrele)
openssl rsa -aes256 -in ornek.com.key -out ornek.com.secure.key

# Parolayı kaldır (otomasyon için gerektiğinde)
openssl rsa -in ornek.com.secure.key -out ornek.com.key

Parola korumasının bilinen bir dezavantajı vardır: şifreli anahtar kullanan bir web sunucusu her yeniden başlatıldığında parolanın girilmesi gerekir. Bu, sunucu otomatik yeniden başladığında (örneğin gece bir güncelleme sonrası) hizmetin parola beklerken takılıp kalması anlamına gelir. Üretim ortamlarında bu ikilemi genelde şöyle çözeriz:

Pek çok üretim sunucusu, otomatik başlatmayı bozmamak için parolasız anahtarı sıkı izinlerle (600, root, şifreli diskte) kullanmayı tercih eder ve gerçek koruma katmanını disk şifreleme ile sağlar. Eğer parolalı anahtar kullanacaksanız, parolayı bir sır yönetim sistemine (HashiCorp Vault, AWS Secrets Manager, systemd credential) koyup başlatma anında enjekte etmek en temiz çözümdür. Anahtar parolasını asla anahtarın yanındaki bir .txt dosyasına yazmayın — bu, kilidi kapının altına koymakla eşdeğerdir.

Güvenli Yedekleme Stratejisi#

Özel anahtarı kaybetmek de sızdırmak kadar can sıkıcıdır: anahtar giderse sertifikayı da baştan üretmeniz gerekir. Bu yüzden anahtarın güvenli bir yedeğine ihtiyacınız var — ama bu yedek, anahtarın kendisi kadar korunmalıdır. Anahtar yedeğini asla şifrelenmemiş bir bulut klasörüne, ortak bir dosya sunucusuna ya da bir e-postaya koymayın. Yedeğin altın kuralı: yedek de en az orijinal kadar gizlidir.

Doğru yaklaşım, anahtarı yedeklemeden önce güçlü bir simetrik şifre ile şifrelemektir. GnuPG bu iş için ideal ve yaygındır:

# Anahtarı simetrik (parola tabanlı) AES-256 ile şifrele
gpg --symmetric --cipher-algo AES256 \
    --output ornek.com.key.gpg \
    ornek.com.key

# Geri açmak gerektiğinde
gpg --decrypt ornek.com.key.gpg > ornek.com.key

Bu .gpg dosyasını artık güvenle bir yedekleme sistemine, şifreli bir USB'ye ya da bir sır kasasına koyabilirsiniz; içindekini parola olmadan kimse açamaz. Yedekleme rutininizi otomatikleştirmek istiyorsanız, düzenli ve şifreli yedekler için yedekleme çözümümüz bu tür kritik dosyalar için tasarlanmıştır.

Yedekleme hijyeni için birkaç pratik kural:

• 3-2-1 kuralı: En az 3 kopya, 2 farklı ortam, 1 tanesi konum dışı — ama hepsi şifreli.
• Git'ten uzak tutun: Anahtar dosyalarını .gitignore içine ekleyin; yanlışlıkla commit edilirse Git geçmişinden temizlemek zordur ve dosya artık sızmış sayılır.
• Erişim kaydı tutun: Yedeği kimin, ne zaman açtığını takip edin.
• Rotasyon planlayın: Sertifikayı her yenilediğinizde genellikle yeni bir anahtar üretin; eski yedekleri sertifika süresi dolunca imha edin.

Aşağıdaki .gitignore örneği, anahtarların yanlışlıkla depoya girmesini engeller:

# Asla commit edilmemesi gerekenler
*.key
*.pem
*.pfx
*.p12
.env
secrets/

Anahtar Sızarsa Ne Yapmalı: İptal ve Yeniden Üretme#

Ne kadar dikkatli olursanız olun, sızıntı ihtimali sıfır değildir: bir yedek yanlış yere kopyalanmış, bir sunucu ele geçirilmiş ya da anahtar bir depoya commit edilmiş olabilir. Bu durumda panik yerine net bir müdahale planı devreye girmeli. Sızmış bir özel anahtar için tek doğru yanıt vardır: sertifikayı hemen iptal edin (revoke) ve yeni bir anahtar çiftiyle sıfırdan yeniden üretin. Sadece anahtarı silmek yetmez, çünkü saldırganda zaten bir kopyası olabilir ve mevcut sertifika hâlâ geçerlidir.

Adım adım müdahale şu sıradadır:

1. Yeni anahtar üretin. Sızan anahtarı asla yeniden kullanmayın. Temiz bir anahtar ve yeni bir CSR oluşturun.
2. Sertifikayı yeniden düzenletin (reissue). CA panelinizden aynı domain için yeni CSR ile sertifikayı yeniden üretin.
3. Eski sertifikayı iptal edin (revoke). CA'ya iptal talebi gönderin; sebep olarak "key compromise" seçin.
4. Yeni sertifika ve anahtarı sunucuya kurun, doğru izinlerle (600, root).
5. Sızan anahtarın tüm kopyalarını imha edin — yedekler, log'lar, Git geçmişi dahil.
6. Olayı kayıt altına alın ve sızıntının kök nedenini kapatın.

Yeni anahtar ve CSR üretmek:

# Temiz, yeni bir anahtar + CSR
openssl req -new -newkey rsa:2048 -nodes \
  -keyout yeni.ornek.com.key \
  -out yeni.ornek.com.csr \
  -subj "/CN=ornek.com/O=Ornek A.S./C=TR"

Let's Encrypt kullanıyorsanız iptal işlemi certbot ile tek komuttur:

# Sertifikayı "key compromise" gerekçesiyle iptal et
certbot revoke \
  --cert-path /etc/letsencrypt/live/ornek.com/cert.pem \
  --reason keycompromise

# Ardından temiz bir anahtarla yeniden al
certbot certonly --nginx -d ornek.com -d www.ornek.com \
  --key-type ecdsa --force-renewal

İptalin neden şart olduğunu anlamak önemli: sertifikanın geçerlilik süresi dolana kadar tarayıcılar onu geçerli kabul etmeye devam eder. Modern tarayıcılar OCSP ve CRL üzerinden iptal durumunu kontrol edebildiği için, sertifikayı revoke etmek saldırganın elindeki kopyayı işe yaramaz hale getiren tek mekanizmadır. Eğer anahtar bir kod deposuna commit edildiyse, dosyayı silmek yetmez; sızıntı gerçekleşmiş sayılır ve iptal-yeniden üretme döngüsü mutlaka çalıştırılmalıdır.

Bu tür bir olayda web sitenizin bütünlüğünü de kontrol etmek isteyebilirsiniz. Sunucunuz ele geçirildiyse yalnızca anahtar değil, tüm sistem güven dışıdır; böyle durumlarda temiz bir sunucuya site taşıma ve önüne bir WAF ile DDoS koruma katmanı koymak akıllıca olur. Uygulama katmanındaki açığı kapatmadan yeni anahtar üretmek, aynı kapıyı tekrar açık bırakmak demektir.

Anahtar Saklama İçin İleri Seviye Uygulamalar#

Temel izin, parola ve yedek disiplinini oturttuktan sonra, kritik altyapılarda anahtarı diskten tamamen soyutlayan çözümlere geçebilirsiniz. Buradaki fikir, anahtarın hiçbir zaman düz metin olarak dosya sisteminde bulunmamasıdır. En yaygın üç yaklaşım şunlardır: sır yöneticileri, donanım güvenlik modülleri (HSM) ve şifreli diskler.

Sır yöneticileri (secret managers): HashiCorp Vault, AWS/GCP Secrets Manager veya systemd'nin LoadCredentialEncrypted özelliği, anahtarı şifreli olarak saklar ve yalnızca servis başlarken belleğe enjekte eder. Böylece diskte hiçbir zaman açık anahtar bulunmaz. systemd örneği:

# /etc/systemd/system/nginx.service.d/creds.conf benzeri mantık
[Service]
LoadCredentialEncrypted=ssl-key:/etc/creds/ornek.com.key.cred
# Anahtar belleğe /run/credentials/... altında açılır, diske yazılmaz

Donanım güvenlik modülleri (HSM) ve TPM: Anahtarı üreten ve saklayan özel bir donanım çipidir; anahtar donanımdan hiçbir zaman dışarı çıkmaz, imzalama işlemi çip içinde yapılır. Bu, en yüksek koruma seviyesidir ve bankacılık, ödeme, e-devlet gibi ortamlarda tercih edilir.

Şifreli disk (LUKS): Sunucunun tüm veri bölümünü şifreleyerek fiziksel disk çalınması senaryosunu kapatır. Anahtar hâlâ dosya olarak durur ama disk kapalıyken tamamen okunamaz.

Ayrıca anahtar ömrünü kısaltmak da bir güvenlik stratejisidir. Let's Encrypt gibi kısa ömürlü (90 gün) sertifikalarla, her yenilemede yeni anahtar üreterek olası bir sızıntının etki penceresini daraltırsınız. Otomatik yenileme sağlayan hosting altyapımızda bu döngü sizin için yönetilir; ister WordPress hosting ister web hosting tarafında olun, ücretsiz SSL ve otomatik yenileme standart gelir. Anahtar rotasyonunu, izleme ve sızıntı denetimini bir arada kurgulayan bir sunucu yönetimi hizmeti de bu operasyonel yükü sırtınızdan alır.

Sıkça Sorulan Sorular#

Private key ile public key arasındaki fark nedir?#

İkisi birbirine matematiksel olarak bağlı bir anahtar çiftinin parçalarıdır ama rolleri zıttır. Açık anahtar (public key) sertifikanın içinde herkese dağıtılır ve trafiği doğrulamak/şifrelemek için kullanılır; özel anahtar (private key) ise yalnızca sizde durur, imza atmaya ve şifreli veriyi çözmeye yarar. Basitçe söylersek açık anahtar kilit, özel anahtar ise o kilidi açan tek gizli anahtardır. Bu yüzden açık anahtarı istediğiniz kadar paylaşabilir, özel anahtarı ise asla dışarı çıkarmamanız gerekir.

Özel anahtar dosyamın izinleri ne olmalı?#

Standart ve güvenli değer 600 yani yalnızca sahibinin (genellikle root) okuyup yazabildiği izindir; dosyanın sahibi root:root, bulunduğu dizin ise 700 olmalıdır. Bu ayar, sunucudaki web uygulaması kullanıcısı da dahil hiçbir düşük yetkili hesabın anahtarı okuyamamasını sağlar. chmod 600 dosya.key ve chown root:root dosya.key komutlarıyla bunu ayarlayabilirsiniz. 644 gibi herkesin okuyabildiği bir izin, bir uygulama açığı durumunda anahtarın doğrudan sızması demektir ve kesinlikle kaçınılmalıdır.

Özel anahtarımı hosting sağlayıcıma göndermem gerekir mi?#

Hayır, meşru hiçbir hosting firması veya sertifika otoritesi sizden özel anahtarınızı istemez. Sertifika kurulumu için sağlayıcının ihtiyaç duyduğu şey sertifika dosyası ve gerekirse zincir (chain) dosyasıdır; özel anahtar sunucuda kalır. Eğer bir destek talebinde sizden özel anahtar isteniyorsa bu ciddi bir uyarı işaretidir. Anahtarı bir e-postaya veya destek biletine yapıştırdıysanız, onu sızmış kabul edip sertifikayı iptal edip yeniden üretmeniz gerekir.

Anahtarımın sızdığını nasıl anlarım ve hemen ne yapmalıyım?#

Anahtarın bir Git deposuna commit edilmesi, bir yedeğin yetkisiz bir yere kopyalanması, sunucunun ele geçirilmesi ya da anahtarın bir mesajda paylaşılması sızıntı sayılır; kesin kanıt beklemeyin, şüphe bile müdahaleyi tetiklemeli. Yapmanız gereken sırayla şudur: yeni bir anahtar ve CSR üretin, sertifikayı yeniden düzenletin, eski sertifikayı "key compromise" gerekçesiyle iptal edin ve sızan anahtarın tüm kopyalarını imha edin. Ardından sızıntıya yol açan kök nedeni (açık, yanlış izin, hatalı yedek) mutlaka kapatın, aksi halde yeni anahtar da aynı yoldan sızabilir.

Özel anahtarı parola ile korumak zorunda mıyım?#

Zorunlu değil ama önerilir; parola (passphrase), disk veya yedek sızsa bile anahtarın parolasız açılmasını engelleyen ikinci bir katmandır. Dezavantajı, web sunucusunun her yeniden başlatılmasında parolanın girilmesi gerekmesidir; bu da otomatik başlatmayı zorlaştırır. Üretim ortamlarında yaygın çözüm, ya parolasız anahtarı çok sıkı izinler ve şifreli diskle kullanmak ya da parolayı bir sır yönetim sistemine koyup başlatma anında otomatik enjekte etmektir. Parolayı asla anahtar dosyasının yanındaki düz bir metin dosyasında saklamayın.

Sertifikayı yenilerken aynı anahtarı tekrar kullanabilir miyim?#

Teknik olarak çoğu CA aynı CSR ve anahtarla yenilemeye izin verir, ancak güvenlik açısından her yenilemede yeni bir anahtar üretmek daha iyidir. Yeni anahtar üretmek, olası ama fark edilmemiş bir sızıntının etki süresini kısaltır ve anahtar rotasyonu ilkesine uyar. Eğer mevcut anahtarın herhangi bir şekilde sızmış olma ihtimali varsa, yeniden kullanmak kesinlikle yanlıştır ve eski sertifikanın iptal edilmesi gerekir. Kısa ömürlü sertifikalarla otomatik yenileme kullanıyorsanız, her döngüde yeni anahtar üretecek şekilde yapılandırmak en temiz yaklaşımdır.

Kapanış#

Özel anahtar, SSL'in kalbidir: sertifika herkese açık kimliğiniz, özel anahtar ise o kimliği ispatlayan tek gizli parçadır. Onu korumanın formülü aslında sade — kimseyle paylaşmayın, sunucuda 600 izin ve root sahiplik verin, gerekiyorsa parola ile şifreleyin, yedeğini yalnızca şifreli tutun ve en ufak bir sızıntı şüphesinde sertifikayı hemen iptal edip yeni bir anahtarla yeniden üretin. Bu birkaç disiplin, HTTPS'inizi süsten çıkarıp gerçek bir güven katmanına dönüştürür.

Clou.TR olarak sunduğumuz web hosting ve WordPress hosting paketlerinde ücretsiz SSL, otomatik yenileme ve doğru izinlerle kurulmuş anahtar yönetimi standart olarak gelir; kök erişimli sanal sunucu ve VDS çözümlerimizde ise anahtar güvenliğini uçtan uca siz kurgulayabilir, dilerseniz sunucu yönetimi hizmetimizle operasyonel yükü bize devredebilirsiniz. Sitenizi bir WAF ve DDoS koruma katmanıyla güçlendirip düzenli yedekleme ile tamamladığınızda, özel anahtarınız da altyapınızın geri kalanı kadar güvende olur. Güvenli bir SSL kurulumu için bugün ilk adımı atın.