HTTP-01 ve DNS-01: Orkestre ACME için risk çerçevesi

Geniş bir altyapıda Let's Encrypt veya diğer ACME tabanlı Sertifika Otoritelerini (CA) koordine ederken, mühendisler eninde sonunda temel bir seçimle karşı karşıya kalır: HTTP-01 veya DNS-01 doğrulaması. Her iki yöntem de bir domain üzerindeki kontrolü kanıtlasa da farklı erişim modelleri gerektirir, farklı güvenlik sınırları oluşturur ve oldukça farklı risk profilleri taşır.

Bu yazıda, özellikle kurumsal veya çok kiracılı ortamlarda sertifikaları otomatikleştirirken bu riskleri nasıl çerçeveleyeceğimizi detaylandırıyoruz.

DNS-01'in Cazibesi (ve Tehlikesi)

DNS-01 doğrulaması, domain kontrolünü kanıtlamak için geçici bir TXT kaydı oluşturmayı içerir. Birincil avantajı, web sunucusunun genel internetten 80 numaralı port üzerinden erişilebilir olmasını gerektirmemesidir. Ayrıca, wildcard (joker) sertifikalar (örneğin, *.example.com) yayınlamayı destekleyen tek ACME doğrulama türüdür.

Ancak, bu kolaylığın ciddi bir güvenlik bedeli vardır.

"Krallığın Anahtarları" Problemi

DNS-01'i otomatikleştirmek için, ACME istemcinizin DNS bölgelerinizi (zones) değiştirebilecek API kimlik bilgilerine ihtiyacı vardır. Birçok bulut sağlayıcısında (Route53 veya Cloudflare gibi), bir API jetonunu (token) yalnızca _acme-challenge TXT kayıtlarını yazacak şekilde kısıtlamak karmaşık veya imkansızdır.

Eğer ACME istemcisi çalıştıran bir uç sunucu (edge server) ele geçirilirse, saldırgan bu DNS API anahtarlarını çalabilir. Bir anda, ele geçirilen basit bir web sunucusu tam bir DNS gaspına dönüşebilir ve saldırganların trafiği kötü amaçlı noktalara yönlendirmesine veya e-postaları ele geçirmesine olanak tanır.

Orkestre Edilmiş HTTP-01'in Avantajları

HTTP-01 doğrulaması, doğrulanan domain için yanıt veren web sunucusundaki belirli bir yola (/.well-known/acme-challenge/) bir jeton yerleştirerek kontrolü kanıtlar.

Dar Kapsam Sayesinde Güvenlik

HTTP-01 doğrulaması, doğası gereği yalnızca doğrulanan ana bilgisayar adıyla (hostname) sınırlıdır. Bir saldırgan api.example.com barındıran sunucuyu ele geçirirse, yalnızca api.example.com'u etkileyebilir. fatura.example.com için sertifika çıkarma veya DNS kayıtlarını değiştirme yetkisi kazanamaz.

Kurumsal Çıkış Modelleri ve Port 80

HTTP-01'e yönelik yaygın bir itiraz, 80 numaralı portun genel internete açık olması gerekliliğidir. Ancak modern sertifika yaşam döngüsü yönetim platformları (Certinite gibi) bunu zarif bir şekilde çözer:

1. Yalnızca Dışa Dönük Ajanlar: Sunucuda çalışan ajan, kontrol düzlemine yalnızca dışa dönük (outbound) bir erişime ihtiyaç duyar.
2. Minimum İçe Dönük Risk: Genel CA'nın doğrulama dosyasını okumak için 80 portuna ulaşması gerekse de, bir yönetim portu açmıyorsunuz. Sadece web sunucunuza HTTP trafiğine izin veriyorsunuz—ki bu zaten sunucunun birincil görevidir. Tüm doğrulama istekleri kesin bir şekilde /.well-known/acme-challenge/ yoluna yönlendirilebilir.

Doğru Seçimi Yapmak

Certinite olarak, çoğu kurumsal dağıtım için varsayılan olarak orkestre edilmiş HTTP-01'i savunuyoruz. Kontrol düzlemini uç noktadan ayırarak, güçlü DNS API anahtarlarını tüm altyapınıza yaymaktan kurtulursunuz.

Ne zaman DNS-01 kullanılmalı:

• Kesinlikle wildcard (joker) sertifikalara ihtiyacınız varsa.
• Uç noktalar tamamen iç ağdaysa ve belirli bir yolda bile genel bir CA tarafından erişilemiyorsa.
• En önemlisi: Otomasyon süreci tarafından kullanılan DNS API jetonlarının kapsamını kesin bir şekilde kısıtlama yeteneğine sahipseniz.

Ne zaman HTTP-01 kullanılmalı:

• Standart, tam nitelikli alan adlarını (FQDN'ler) otomatikleştiriyorsanız.
• Olası bir sunucu ihlalinin etki alanını kesin olarak sınırlamak istiyorsanız.
• DNS API kimlik bilgilerini birden fazla ortamda yönetmek, döndürmek (rotate) ve güvence altına almak istemiyorsanız.

Platform ekipleri, her doğrulama yönteminin farklı risk profillerini anlayarak, hem güvenilir hem de yapısal olarak güvenli bir sertifika otomasyonu tasarlayabilir.