Alan adı güvenlik kontrol listesi

Alan adı, web sitenizin yalnızca adresi değil; e-posta, müşteri girişi, API ve marka güveninin ortak yönlendirme noktasıdır. Sunucunuz sağlam olsa bile registrar hesabı ele geçirilir veya nameserver değiştirilirse trafik saldırganın altyapısına yöneltilebilir. Bu yüzden güvenliği tek bir “kilit” ayarı değil, hesap, DNS, yenileme, izleme ve müdahale katmanları olarak ele almak gerekir.

1. Önce sahipliği ve envanteri netleştirin

Kurumlarda en yaygın zayıflıklardan biri alan adının eski bir çalışanın kişisel hesabında kalmasıdır. Hangi domainin hangi registrar, registry, DNS sağlayıcısı ve fatura hesabıyla yönetildiğini yazılı envantere alın. Kayıt sahibinin tüzel kişi olması gereken durumlarda bilgilerin doğruluğunu kontrol edin. Teknik, idari ve fatura sorumlularını ayrı ayrı belirleyin; fakat gereksiz kişiye tam yetki vermeyin.

Envanterde en az domain, uzantı, registrar, hesap kimliği, sona erme tarihi, otomatik yenileme durumu, nameserver'lar, DNSSEC durumu ve iş sahibi bulunmalıdır. AuthInfo kodu veya parolayı düz metin tabloya yazmayın. Gizli bilgiler kurumsal parola kasasında tutulmalı, erişimler kayıt altına alınmalı ve işten ayrılma sürecinde iptal edilmelidir.

2. Registrar hesabını güçlendirin

• Registrar için başka yerde kullanılmayan, uzun ve rastgele bir parola üretin.
• Sağlayıcı destekliyorsa donanım güvenlik anahtarı veya geçiş anahtarı; değilse TOTP tabanlı çok faktörlü doğrulama kullanın.
• SMS'i tek koruma olarak görmeyin; numara taşıma ve sosyal mühendislik risklerini hesaba katın.
• Kurtarma kodlarını çevrim dışı veya erişimi sınırlı kurumsal kasada saklayın.
• Kurtarma e-postasını da aynı veya daha yüksek güvenlik düzeyiyle koruyun.
• Başarılı/başarısız giriş, parola, iletişim ve DNS değişikliği bildirimlerini açın.
• Paylaşılan tek yönetici hesabı yerine adlandırılmış kullanıcı ve rol desteği varsa onu kullanın.

Kimlik avı saldırıları gerçek registrar arayüzünü taklit edebilir. Bildirim e-postasındaki bağlantıya basmak yerine sağlayıcının adresini parola yöneticinizden veya kayıtlı yer iminden açın. Parola yöneticisinin alan adı eşleştirmemesi, sahte sayfa için erken uyarı olabilir. Destek ekibi sizden parola, tek kullanımlık kod veya kurtarma kodunun tamamını isterse işlemi durdurup resmî kanaldan yeniden doğrulayın.

3. Registrar kilidi ile registry kilidini karıştırmayın

Standart transfer kilidi RDAP'ta çoğu zaman clientTransferProhibited olarak görünür ve yetkisiz registrar transferini zorlaştırır. Panelde “domain lock” adıyla sunulabilir. Günlük yönetim sırasında açık tutulmalı, meşru transferden hemen önce kontrollü olarak kaldırılmalı ve işlemden sonra yeniden etkinleştirilmelidir.

Registry lock ise her uzantı veya sağlayıcıda bulunmayan, daha güçlü ve çoğu zaman ek doğrulama gerektiren bir hizmettir. Transferin yanında nameserver veya kayıt sahibi gibi kritik değişiklikleri registry düzeyinde kısıtlayabilir. Banka, büyük e-ticaret, kamu hizmeti veya yüksek trafikli marka gibi bir alan adının ele geçirilme etkisi çok büyükse registrarınızdan registry lock koşullarını sorun. Hiçbir kilit, zayıf hesap kurtarma sürecini veya içeriden gelen yetki kötüye kullanımını tek başına çözmez.

4. DNS değişikliklerini kontrollü yönetin

DNS sağlayıcısı hesabı, registrar kadar kritiktir. Mümkünse DNS yönetimini ayrı bir kurumsal hesapta, rol tabanlı yetkiler ve çok faktörlü doğrulamayla koruyun. Üretim kaydını değiştirecek kullanıcı sayısını sınırlayın; okuma ve faturalama rollerini ayırın. Kritik değişikliklerde ikinci kişi onayı ve bakım kaydı uygulayın.

A, AAAA, CNAME, MX, TXT, CAA ve NS kayıtlarının beklenen değerlerini sürüm kontrollü bir envanterde tutun. Değişiklikten önce bölge dışa aktarımı alın. Yetkili nameserver cevaplarını farklı ağlardan ölçün; DNS Yayılımı aracını gözlem için kullanabilirsiniz. Araç sonuçları belirli çözümleyicilerden örnek verir ve dünyadaki bütün kullanıcıların durumunu garanti etmez.

5. DNSSEC'i doğru planlayın

DNSSEC, DNS yanıtlarının yetkili kaynaktan geldiğini kriptografik olarak doğrulamaya yardımcı olur. Alan adı ile üst bölge arasında DS kaydı, DNS sağlayıcısında ise buna karşılık gelen anahtarlar bulunur. Etkinleştirmek sahte DNS cevabı riskinin bir bölümünü azaltır; registrar hesabının ele geçirilmesini, kötü niyetli içeriği veya web uygulaması açığını önlemez.

En büyük operasyonel risk, nameserver ya da DNS sağlayıcısı değişirken eski DS kaydının üst bölgede kalmasıdır. Anahtar eşleşmezse doğrulayan çözümleyiciler alan adını hatalı kabul edip SERVFAIL döndürebilir. Geçiş planını sağlayıcı belgelerine göre yapın, DS değerini iki kaynaktan doğrulayın ve değişiklik sonrasında DNSSEC zincirini test edin. Emin değilseniz üretimde deneme-yanılma yapmadan deneyimli bir DNS yöneticisinden destek alın.

6. Alan adına bağlı e-postayı savunun

Registrar ve DNS hesaplarının parola sıfırlaması çoğu zaman e-postaya dayanır; bu nedenle posta hesabı aynı güvenlik zincirindedir. Yönetici kutularında güçlü MFA, oturum uyarıları, yönlendirme kuralı denetimi ve ayrı kurtarma kanalı kullanın. E-posta Güvenliği aracında MX, SPF ve DMARC durumunu kontrol edin; DKIM imzalarını posta sağlayıcınızın yönetim paneli ve test ile doğrulayın.

SPF göndermeye yetkili sistemleri listeler, DKIM mesajın imzalanmasını sağlar, DMARC ise alan adınızı kullanan başarısız iletiler için politika ve raporlama çerçevesi sunar. Bu üçlü registrar hesabını korumaz; marka adına sahte e-posta gönderimini azaltmaya yardımcı olan ayrı bir katmandır. DMARC'ı doğrudan katı politikaya geçirmek yerine meşru göndericileri envantere alıp raporları izleyerek kademeli uygulayın.

7. Web ve sertifika katmanını unutmayın

CAA kaydı, hangi sertifika yetkililerinin alan adınız için sertifika düzenleyebileceğini sınırlandırmaya yardımcı olabilir. Hatalı CAA meşru yenilemeyi engelleyebileceğinden yalnızca kullandığınız sertifika hizmetlerini doğruladıktan sonra yayınlayın. Sertifika süresi, yönlendirme ve protokol durumunu SSL Kontrolü ile; güvenlik başlıklarını HTTP Güvenliği aracıyla gözden geçirin.

Web hizmetiniz güvenlik açığı bildirimlerini kabul ediyorsa IETF RFC 9116'ya uygun /.well-known/security.txt dosyası, araştırmacının doğru irtibatı bulmasını kolaylaştırabilir. Bu dosya bir güvenlik duvarı değildir; yayımlanan iletişim adresinin izlenmesi ve gelen raporlar için müdahale süreci gerekir.

8. Yenilemeyi bir güvenlik kontrolü sayın

Alan adını saldırgan çalmadan da kaybedebilirsiniz: süresi unutulursa web, e-posta ve marka trafiği kesilebilir. Otomatik yenilemeyi açın, fakat yalnızca buna güvenmeyin. Ödeme kartının son kullanma tarihi, harcama limiti veya fatura hesabındaki değişiklik işlemi bozabilir. Bitiş tarihlerini en az iki bağımsız takvim veya izleme sisteminde takip edin ve kritik alan adlarını son günü beklemeden yenileyin.

Alan Hattı RDAP sorgusu ve Domain Sağlık Raporu tarih ve teknik sinyalleri kontrol etmenize yardımcı olur. RDAP'taki tarih veya otomatik alarm, registrar hesabındaki resmî yenileme kaydının yerine geçmez. Bildirimlerin ulaşması için kayıt iletişim bilgilerini güncel tutun.

9. İzleme ve olay müdahale planı kurun

Nameserver, DS, registrar, kayıt sahibi iletişimi ve kritik DNS kayıtlarındaki değişiklikler için alarm üretin. Bildirim e-postasını saldırganın ele geçirebileceği tek posta kutusuna bağlamayın. Aylık kontrolün yanında her yetki değişikliği, çalışan ayrılışı, registrar transferi ve DNS taşıması sonrasında olağanüstü denetim yapın.

Şüpheli bir değişiklikte önce kanıtları saklayın: zaman, RDAP çıktısı, DNS cevapları, registrar bildirimi ve giriş günlükleri. Etkilenen hesabın oturumlarını sonlandırın, parolayı temiz bir cihazdan değiştirin, MFA'yı yeniden kaydedin ve registrarın güvenlik/abuse kanalına acil durum kaydı açın. Yetkisiz transfer şüphesinde hem eski hem yeni registrar ile iletişim kurun. DNS'i aceleyle ileri geri değiştirmek yerine yetkili ekiple tek bir geri dönüş planı uygulayın.

Aylık uygulanabilir kontrol listesi

• Registrar, DNS ve e-posta hesaplarında MFA ile kurtarma kanallarını test edin.
• Alan adının transfer kilidini ve beklenen registrar bilgisini doğrulayın.
• Sona erme tarihi, otomatik yenileme ve ödeme yöntemini kontrol edin.
• NS, DS, A/AAAA, MX, SPF, DKIM, DMARC ve CAA değişikliklerini envanterle karşılaştırın.
• Yetkili kullanıcı listesini inceleyin; gereksiz veya eski hesapları kaldırın.
• Registrar ve DNS sağlayıcısının güvenlik bildirimlerini gözden geçirin.
• Web sertifikası, HTTPS yönlendirmesi ve kritik güvenlik başlıklarını test edin.
• Olay müdahale kişilerini ve sağlayıcı destek kanallarını erişilebilir tutun.
• Yedek DNS bölgesinin güncel ve güvenli konumda olduğunu doğrulayın.
• Kritik değişikliklerin ikinci kişi tarafından onaylandığını belgeleyin.

Araçların ve kontrollerin sınırları

Dışarıdan yapılan tarama, hesabınızdaki MFA'nın gerçekten etkin olduğunu veya destek ekibinin kimlik doğrulama kalitesini ölçemez. RDAP gizlilik nedeniyle kayıt sahibi ayrıntılarını göstermeyebilir. DNSSEC açık görünse bile anahtar yenileme süreçleri zayıf olabilir. Benzer şekilde güvenlik başlıklarının varlığı web uygulamasının hatasız olduğunu kanıtlamaz. Bu liste temel bir operasyon çerçevesidir; yüksek riskli sistemlerde tehdit modeli, erişim denetimi, günlük toplama ve bağımsız güvenlik değerlendirmesiyle tamamlanmalıdır.

Editoryal not: Güvenlik riski kuruma, uzantıya ve sağlayıcıya göre değişir. Bu rehber genel bir başlangıç çerçevesidir; olay anında ilgili sağlayıcının resmî güvenlik kanallarını kullanın.