Yeni Web Siteleri İçin 20 Hosting Güvenlik Ayarı

Yeni Web Siteniz İçin Güvenlik Neden İlk Günden Başlamalı?

Yeni bir web sitesi açarken tasarım, hız ve SEO kadar güvenlik ayarlarını da planlamak gerekir. Güvenliği ertelemek; hesapların ele geçirilmesi, zararlı yazılım bulaşması ve hizmet kesintisi risklerini artırabilir. Tarayıcıların “Güvenli değil” uyarısı ise tek başına zararlı yazılım göstergesi değildir; HTTPS kullanılmamasıyla da ilişkili olabilir. İlk günden doğru hosting güvenlik ayarlarını yapmak bu riskleri azaltır, ancak tüm güvenlik sorunlarını önlemez.

Basit bir güvenlik kontrol listesi, kurulum sırasında önemli adımların atlanmasını önlemeye yardımcı olur. Bu yazıda yeni açılan bir web sitesi için ilk günden ele alınması gereken 20 hosting güvenlik kontrolünü listeleyeceğiz. Paylaşımlı hosting, VPS veya dedicated sunucu kullanırken uygulanabilecek işlemler, erişim yetkilerinize ve yönetim paketine bağlıdır. Hesap ve uygulama kontrollerini kendi yetkilerinizle yürütün; sunucu düzeyindeki adımlarda yönetim sizde değilse sağlayıcıyla kapsamı netleştirin. Amacımız, her ayarı her ortamda doğrudan uygulamak değil, sorumlusu belirlenmiş ve kontrol edilebilir bir güvenlik listesi oluşturmaktır.

Eğer henüz alan adınızı aldıktan sonra temel DNS ve SSL adımlarını atmadıysanız, bu yazıyla birlikte yeni alan adı için 30 günlük DNS, SSL ve e‑posta kontrol listemizi de paralel okumanızı kesinlikle öneririm.

1. Katman: Kimlik ve Erişim Güvenliği

1. Hosting ve Müşteri Paneline İki Aşamalı Doğrulama (2FA) Kurun

Yeni açılan her sitenin en kritik zayıf noktalarından biri, hosting ve müşteri paneli girişleridir. Buralara erişimi ele geçiren biri, sitenizi, DNS kayıtlarınızı, e‑posta hesaplarınızı ve hatta faturalarınızı bile yönetebilir.

İlk günden yapmanız gereken:

• DCHost müşteri panelinizde ve hosting kontrol panelinizde iki aşamalı doğrulama (2FA) seçeneklerini kontrol edin; sunuluyorsa her ikisinde de etkinleştirin.
• Google Authenticator, Authy veya benzeri bir uygulama ile zaman bazlı kod üretimini tercih edin; SMS mümkünse yedek yöntem olsun.
• Yedek kurtarma kodlarını güvenli bir yerde (şifre yöneticiniz, offline not) saklayın.

Bu adım, yalnızca şifreyi ele geçiren bir saldırganın hesaba giriş yapmasını zorlaştırır; tüm hesap ele geçirme yöntemlerini engellemez.

2. Tüm Hesaplar İçin Benzersiz ve Güçlü Şifre Politikası

Yeni site kurulumlarında her yerde aynı veya benzer şifrelerin kullanılması, bir hesabın ele geçirilmesinin diğer hesapları da tehlikeye atmasına yol açabilir. Özellikle “alan adı paneli + hosting paneli + WordPress admin” gibi kritik girişlerin aynı şifreyi paylaşması ciddi risk.

Dikkat etmeniz gerekenler:

• Registrar, DCHost, panel, CMS ve veri tabanı hesapları için uzun, benzersiz parolalar kullanın; hizmetin izin verdiği uzunlukta rastgele değerler üretin.
• Parolaları güvenilir bir şifre yöneticisinde saklayın; yöneticinin ana hesabını ve cihaz erişimini de koruyun.
• Destekleniyorsa 2FA kullanın, kurtarma kodlarını güvenle saklayın ve hesap kurtarma yolunu doğrulayın.
• Geçici çalışanlar için ayrı yetkiler tanımlayın; iş bitince hesaplarla birlikte ilgili oturum, anahtar ve token erişimlerini iptal edin.

3. SSH Erişiminde Şifreyi Kapatın, Anahtar Tabanlı Giriş Kullanın (VPS/Dedicated)

Eğer sitenizi paylaşımlı hosting yerine VPS veya dedicated sunucu üzerinde barındırıyorsanız, SSH erişimi kritik önem taşır. İnternete açık ve yalnızca kullanıcı adı/şifre ile korunan SSH erişimi, otomatik parola denemelerinin hedefi olabilir.

İlk günden şu adımları planlayın:

• SSH için anahtar tabanlı doğrulama (public/private key) kurun. Root dışı bir yönetici hesabıyla anahtarlı girişi ve gerektiğinde yönetici yetkisi almayı ayrı bir oturumda doğrulayın. Mevcut oturumu açık tutup konsol/kurtarma erişiminizi kontrol ettikten sonra parola ile SSH girişini kapatın.
• PermitRootLogin değerini no yaparak doğrudan root girişini kapatın.
• SSH portunu değiştirmek tek başına güvenlik çözümü değildir, ama log gürültüsünü azaltır.
• Mümkünse sadece belirli IP’lerden SSH erişimine izin verin.

Bu konuyu daha derinlemesine kurmak isterseniz, VPS’te SSH güvenliği ve FIDO2 anahtarları hakkında hazırladığımız rehbere mutlaka göz atın.

4. Kontrol Paneli (cPanel/Plesk/DirectAdmin) Kullanıcılarını Ayrıştırın

Tek bir hosting hesabı altında birden fazla sitenin aynı kullanıcı ile barındırılması, siteler arasındaki izolasyonu zayıflatabilir. Özellikle ajans ve freelancer’lar için bu, bir sitenin ele geçirilmesi durumunda diğer sitelerin de etkilenmesi riskini artırır.

Yapmanız gerekenler:

• Mümkünse her proje için ayrı bir hosting hesabı veya en azından ayrı kullanıcı/hesap açın.
• FTP/SFTP kullanıcılarını site bazlı tanımlayın, tüm dosya sistemine erişen tek kullanıcı kullanmayın.
• Geçici erişim vereceğiniz kişiler için ayrı kullanıcı açıp iş bitince silin.

Bu konuyu cPanel özelinde daha teknik görmek isterseniz, “cPanel’de Addon Domain mi Ayrı Hesap mı?” yazımız tam bu ikilemi detaylı inceliyor.

2. Katman: Ağ ve Sunucu Yüzeyi Güvenliği

5. Güvenlik Duvarı (Firewall) Kurallarını İlk Günden Daraltın

Sunucunuz ister paylaşımlı, ister VPS, ister dedicated olsun; prensip aynı: Açık olması gerekmeyen hiçbir port açık kalmamalı. Paylaşımlı hostingde sunucu güvenlik duvarını sağlayıcı yönetir; VPS/dedicated hizmetlerde sorumluluk yönetim paketine göre değişir.

Önerilen temel yaklaşım:

• Önce hizmetleri ve gereken erişimi belirleyin. Yalnız web hizmeti sunuluyorsa gerekli HTTP/HTTPS trafiğini açın; HTTP/3 gerekiyorsa ilgili UDP portunu da hesaba katın. E-posta veya DNS gibi hizmetlerin portları ayrıca gerekir.
• Yönetim erişimini uygun IP/VPN kapsamıyla sınırlandırmadan önce izinleri ve konsol/kurtarma yolunu test edin. IPv4 ve IPv6 kurallarını birlikte değerlendirin.
• Panel yönetim portlarını ve phpMyAdmin gibi web arayüzlerini uygun ağ, URL veya sanal sunucu katmanında kısıtlayın; gereken müşteri/ziyaretçi işlevlerini engellemeyin.
• Gereksiz servisleri kapatın ve dış ağdan gerçek erişimi doğrulayın.

Firewall kavramına daha temelden bakmak isterseniz, güvenlik duvarı nedir ve neden önemlidir yazımızı da ayrıca okuyabilirsiniz.

6. Fail2ban veya Benzeri Brute‑Force Koruması Kullanın (VPS/Dedicated)

SSH, FTP, SMTP ve web paneli giriş ekranları otomatik botların tekrarlayan giriş denemelerine hedef olabilir. Bu denemeleri sınırlamak için başarısız girişleri takip edip kaynak IP’yi geçici olarak engelleyen bir araç kullanılabilir.

VPS veya dedicated sunucularda:

• fail2ban gibi bir araç kurun; korumak istediğiniz SSH, FTP, mail ve web paneli hizmetleri için uygun filtreleri ve engelleme kurallarını (jail) etkinleştirip doğru log veya journal kaynağını izlediklerini doğrulayın.
• Belirli sayıda hatalı girişten sonra IP’yi belirli süreyle veya kalıcı olarak engelleyin.
• Ban kurallarını çok agresif ayarlamayın; yanlış şifre giren kendi kullanıcılarınız kilitlenmesin.

7. Sistem, Panel ve Uygulama Güncellemelerini Planlayın

Bilinen ama yamalanmamış güvenlik açıkları, saldırganların yararlanabileceği risklerdir. Sıfır gün (0‑day) açıkları da risk oluştursa da mevcut güvenlik güncellemelerini uygulamak, giderilmiş açıkların istismar edilmesini önlemek için gereklidir.

İşletim sistemi ve panel güncellemelerini sunucuyu yöneten taraf yürütmelidir; paylaşımlı hosting veya yönetilen sunucuda kapsamı sağlayıcınızla netleştirin. CMS, eklenti, tema ve uygulama bağımlılıklarının güncellemeleri için de ayrıca sorumlu belirleyin; sunucu güncellemeleri bunların yerine geçmez.

• Sunucu yönetimi sizdeyse Linux dağıtımınızın desteklediği otomatik güvenlik güncelleme mekanizmasını yapılandırın (örneğin Debian/Ubuntu için unattended‑upgrades). Başarısız güncellemeleri ve yeniden başlatma gereksinimlerini takip edin.
• cPanel/Plesk gibi panellerde desteklenen güncelleme kanalını kullanın; otomatik küçük sürüm güncellemelerini uyumluluk ve bakım planınıza göre etkinleştirin.
• CMS, eklenti, tema ve uygulama bağımlılıklarının güvenlik duyurularını izleyin; yamaları geciktirmeden değerlendirin ve uygulayın. Kullanılmayan bileşenleri kaldırın, desteği biten sürümlerden geçiş planlayın.
• Otomasyonu yedekleme ve hata bildirimleriyle birlikte kurun. Özellikle büyük sürüm geçişlerini (örneğin PHP major upgrade) önce staging ortamında deneyin; değişiklik sonrası temel işlevleri kontrol edin ve geri dönüş planı bulundurun.

PHP tarafındaki yükseltmeler için detaylı bir rehber arıyorsanız, PHP 8.x yükseltme kontrol listemiz işinizi oldukça kolaylaştırır.

8. Sunucu Zamanını ve NTP Senkronizasyonunu Doğru Kurun

Güvenlik tarafında log analizi, sertifika geçerliliği, token süreleri gibi birçok mekanizma doğru sistem saatine bağlıdır. Saat birkaç dakika bile geride veya ilerideyse, beklenmedik hatalarla karşılaşabilirsiniz.

Sistem saatini ve NTP hizmetini değiştirmek sunucu yönetim yetkisi gerektirir. Paylaşımlı hostingde veya yönetimi sağlayıcıda olan sunucuda saat hatalarını sağlayıcıya bildirin; uygulamanızın saat dilimini ise sunduğu ayarlardan seçin. Sunucu yönetimi sizdeyse ilk yapılandırmada:

• Sunucunun desteklediği NTP zaman eşitleme hizmetini etkinleştirin ve eşitlemenin çalıştığını doğrulayın.
• Saat dilimini ihtiyacınıza göre seçin (ör. Europe/Istanbul veya UTC); saat dilimi seçimi, sistem saatinin eşitlenmesinden ayrı bir ayardır.
• Logların hangi saat dilimini kullandığını kaydedin; farklı sistemlerin kayıtlarını karşılaştırırken zamanları ortak bir temele dönüştürün.

3. Katman: HTTPS, Tarayıcı Güvenliği ve WAF

9. SSL/TLS Sertifikasını Kurun ve HTTP → HTTPS Zorlamasını Yapın

Yeni sitenizi yayına almadan önce HTTPS’i yapılandırın. HTTP üzerinden iletilen bilgiler aktarım sırasında okunabilir veya değiştirilebilir; HTTPS bu aktarımı korumaya yardımcı olur. Tarayıcı uyarılarını gidermek ve kullanıcı güvenini desteklemek için sertifikayı ve yönlendirmeleri doğrulayın. HTTPS, uygulama açıklarını gidermez ve tek başına SEO başarısı sağlamaz.

İlk günden şu adımları tamamlayın:

• DCHost panelinizin sunduğu sertifika seçeneklerini kontrol edin; destekleniyorsa ücretsiz Let’s Encrypt veya sahip olduğunuz kurumsal SSL sertifikanızı kurun. Sertifikanın kullanılan alan adlarını kapsadığını ve yenileme sürecinin yapılandırıldığını doğrulayın.
• HTTPS’in çalıştığını doğruladıktan sonra herkese açık sayfalarda HTTP’den HTTPS’e uygun kalıcı yönlendirmeler yapılandırın; yolları ve gerekli sorgu parametrelerini koruyun. API ve uygulama isteklerinin davranışını, proxy kaynaklı yönlendirme döngülerini ve sertifika doğrulama yollarını kontrol edin; tüm isteklere koşulsuz 301 uygulamayın.
• Mixed content (HTTP üzerinden yüklenen resim, JS, CSS) hatalarını kontrol edin.

SSL kavramına giriş ve sertifika türleri hakkında fikrinizi netleştirmek için SSL sertifikası nedir ve nasıl güvence sağlar yazımız iyi bir başlangıç olacaktır.

10. HTTP Güvenlik Başlıklarını (Security Headers) Uygulayın

HTTPS tek başına yeterli değil. Tarayıcıların XSS, clickjacking ve içerik manipülasyonu gibi saldırılara karşı daha akıllı davranması için HTTP güvenlik başlıklarını doğru şekilde ayarlamanız gerekiyor.

Başlıkları uygulama, web sunucusu veya kullandığınız aracı katman üzerinden, yetkiniz olan yerde yapılandırın. Paylaşımlı hostingde izin verilen yöntemleri sağlayıcıdan öğrenin. Aynı başlığın farklı katmanlarda çelişkili biçimde üretilmediğini ve önemli sayfaların gerçek yanıtlarında bulunduğunu kontrol edin. Özellikle şunlara dikkat edin:

• HSTS (HTTP Strict Transport Security): Tarayıcıya, öğrendiği politika süresince sitenize HTTPS ile bağlanmasını söyler. Önce HTTPS’in, sertifika kapsamının ve yenilemenin düzgün çalıştığını doğrulayın. Kısa bir politika süresiyle başlayın; alt alan adları da hazır olmadan onları kapsamayın ve preload’a geçmeyin. Sertifika hataları erişimi engelleyebilir; başlığı kaldırmak tarayıcıdaki mevcut politikayı hemen silmez.
• Content-Security-Policy (CSP): Script, stil ve resim gibi kaynakların nereden yüklenebileceğini sınırlar. Önce Content-Security-Policy-Report-Only ile meşru kaynakları ve kritik işlevleri değerlendirin; rapor toplamak istiyorsanız raporlama uç noktasını da yapılandırın. Bu aşama ihlalleri engellemez. Giriş, form ve ödeme gibi akışları test ettikten sonra zorlayıcı politikaya geçin.
• X-Frame-Options veya CSP’nin frame-ancestors yönergesi: Sitenizin hangi sayfalarda iframe ile gömülebileceğini kısıtlar.
• X-Content-Type-Options: nosniff değeri ve doğru Content-Type yanıtlarıyla içerik türünün yanlış yorumlanması riskini azaltır.

Bu başlıkların ne işe yaradığını ve nasıl ayarlanacağını adım adım görmek için, mutlaka HTTP güvenlik başlıkları rehberimize göz atın.

11. Yönetim Panellerini IP Kısıtlama veya mTLS ile Koruyun

WordPress admin, Laravel Nova, özel admin panelleriniz, phpMyAdmin gibi arayüzler internete “dümdüz” açık kaldığında, brute‑force ve otomatik taramaların doğal hedefi oluyor. Bunu engellemenin en etkili yollarından biri, erişimi kısıtlı bir IP veya istemci sertifikasına bağlamak.

Nginx/Apache yapılandırması ve mTLS, ilgili sunucu veya TLS sonlandırma katmanında yönetim yetkisi gerektirir. Paylaşımlı hostingde yalnızca panelin ya da izin verilen dizin ayarlarının desteklediği kısıtlamaları uygulayın; mTLS ve sunucu düzeyi kurallar için sağlayıcıya danışın. Yönetilen VPS/dedicated hizmetlerde de işlemi kimin yapacağını netleştirin. Seçenekleriniz:

• Nginx/Apache ile yöneticiye özel yollara (ör. /wp-admin) yalnızca belirli IP aralıklarından erişim izni verin. WordPress’te varsayılan /wp-login.php yolunu veya özelleştirilmiş gerçek giriş yolunu ayrıca değerlendirin; yönetim dizinini kısıtlamak giriş ekranını tek başına korumaz.
• Ziyaretçilerin ihtiyaç duyduğu uçları yöneticiye özel yollardan ayırın. WordPress’te /wp-admin/admin-ajax.php herkese açık sayfalarda da kullanılabilir; gerekli istekleri genel dizin engeline takmayın. Üyelik veya müşteri girişi varsa yalnızca yönetici IP’lerine izin vermenin bu kullanıcıları engelleyip engellemediğini değerlendirin.
• Daha ileri seviye için, yönetici erişiminde tarayıcıya istemci sertifikası zorunlu kılan mTLS kurabilirsiniz. Ziyaretçi uçlarını sertifika zorunluluğunun dışında tutacak kapsamı tasarlayın.
• Kurtarma erişimini koruyun; kuralları devreye alırken izin verilen ve verilmeyen ağlardan yönetici girişini, ziyaretçi formlarını, AJAX işlevlerini ve varsa müşteri girişini test edin.

Bu yapıyı pratik örneklerle görmek isterseniz, yönetim panellerini mTLS ile koruma rehberimizi inceleyebilirsiniz.

12. WAF (Web Application Firewall) ile Uygulama Katmanını Filtreleyin

Ağ güvenlik duvarları IP adresi ve port gibi ölçütlerle trafiği filtrelerken, WAF HTTP isteğinin içeriğini (URL, parametreler, body) inceleyerek kurallarına uyan SQL injection, XSS gibi saldırı girişimlerini engellemeye yardımcı olur. Yeni açılan sitelerde özellikle form sayfaları ve login ekranları için ciddi bir koruma katmanı sağlar.

ModSecurity ve OWASP CRS’nin kurulumu sunucu yönetim yetkisi ve uyumlu web sunucusu desteği gerektirir. Paylaşımlı hostingde panelde sunulan WAF kontrollerini kullanın; kural seti, log erişimi ve istisna talepleri için sağlayıcınıza danışın. Yönetilen sunucuda sorumluluğu teyit edin. Sunucuya kurulum yapamıyorsanız, gereksinimlerinize uygun harici bir WAF katmanı da tasarım seçeneğidir. Yetkiniz ve altyapınız uygunsa:

• Sunucu tarafında ModSecurity + OWASP CRS kural setini önce izleme modunda veya erişimi kısıtlı test ortamında değerlendirin; izleme modu saldırıları engellemez.
• Meşru giriş, form ve ödeme akışlarını kontrol edip yanlış pozitifler için dar kapsamlı istisnalar tanımlayın. Ardından engelleme moduna geçin ve logları düzenli takip edin.
• Saldırı girişimi görülen uçlar (login, arama, form vb.) için daha sıkı kuralları meşru kullanıcı etkisini kontrol ederek uygulayın.

WAF yapılandırmasının incelikleriyle ilgileniyorsanız, ModSecurity ve OWASP CRS ile WAF rehberi kararlarınızı netleştirmenize yardımcı olur.

4. Katman: Uygulama, Dosya İzinleri ve Yedekleme

13. Dosya ve Dizin İzinlerini Sertleştirin

Yazılabilir dizinlerin gereğinden geniş yetkilerle bırakılması, bir güvenlik açığının etkisini artırabilir. Özellikle 777 gibi izinler, saldırgan için davetiye anlamına geliyor.

İlk günden şu prensipleri uygulayın:

• 644 dosya ve 755 dizin izinleri yaygın örneklerdir; sahiplik, grup ve gerekli erişimi değerlendirmeden topluca uygulamayın. Parola/anahtar dosyalarında daha dar okuma yetkisi gerekir.
• uploads, cache ve oturum gibi gerekli yolları minimum yetkiyle yazılabilir bırakın. Güncelleme tasarımı elveriyorsa uygulama kodunu dağıtım kullanıcısına yazılabilir, PHP kullanıcısına salt okunur tutun; tüm kodu sırf PHP çalıştırıyor diye aynı kullanıcıya vermeyin.
• Dizindeki execute biti arama/geçiş yetkisidir; bunu kaldırmak PHP handler çalıştırmasını hedefli biçimde engellemez. Yüklemeleri mümkünse web kökü dışında veya ayrı kısıtlı dosya hizmetinde tutun; web erişimi varsa bu yolların script handler’a gitmesini ve yüklenen yapılandırmalarla kural değiştirilmesini engelleyin. Dosya türü, boyut, yetki ve gerçek sunucu davranışını test edin.
• Hassas dosyaların yalnız gereken hesaplarca okunmasını ve HTTP üzerinden indirilememesini ayrı ayrı sağlayın. Dizin listelemesini kapatmak bilinen dosya URL’sine erişimi engellemez.

WordPress kullanıyorsanız, dosya izinleri, XML-RPC, wp-config gibi konuları derli toplu görmek için WordPress güvenlik sertleştirme kontrol listemiz harika bir tamamlayıcıdır.

14. Varsayılan Admin Adını Değiştirin, Destekleniyorsa Yönetim Yolunu Özelleştirin

“admin”, “administrator”, “root” gibi kullanıcı adları ve herkesin bildiği yollar (ör. /wp-admin, /administrator) brute‑force saldırılar için hazır hedeflerdir. Bu adları ve yolları değiştirmek bazı otomatik denemeleri azaltabilir; ancak güçlü kimlik doğrulama ve erişim kısıtlamalarının yerini tutmaz.

Öneriler:

• Yeni kurulumda mümkünse “admin” yerine farklı, tahmin etmesi zor bir yönetici kullanıcı adı seçin.
• Uygulama izin veriyorsa yönetim paneli URL yolunu özelleştirin.

15. Otomatik Yedekleme ve 3‑2‑1 Stratejisini İlk Günden Kurun

Güvenlik sadece saldırıyı engellemek değil, başınıza bir şey geldiğinde geri dönebilmektir. Bunun temel araçlarından biri doğru kurgulanmış bir yedekleme stratejisidir. Yaygın bir model, 3‑2‑1 kuralıdır:

• 3 kopya (1 canlı, 2 yedek)
• 2 farklı ortamda (örn. sunucu diski + harici depolama)
• 1 tanesi farklı lokasyonda (farklı veri merkezi veya offsite depolama)

DCHost planının ve yedekleme aracının gerçek kapsamını doğrulayın. Dosya, veri tabanı, harici medya ve gerekli yapılandırmayı tutarlı biçimde yedekleyin; sıklık ve saklamayı kabul edilebilir veri kaybı, olay tespit süresi ve geri dönüş hedefiyle belirleyin. Bağımsız offsite kopyaları, silme yetkilerini ve kurtarma/şifre çözme anahtarlarını koruyun. 3‑2‑1 yedekleme stratejisi rehberimiz bir başlangıç çerçevesidir; üç kopya bulunması tek başına geri yüklenebilirlik veya değişmezlik kanıtı değildir.

16. Yedekten Geri Dönüş Testini Ertelemeden Yapın

Yedek almak tek başına yeterli değil; o yedekten geri dönebiliyor musunuz? sorusunun cevabı en az yedekleme kadar önemli. Geri yükleme testi yapılmazsa, eksik veya bozuk bir yedek ancak gerçek bir sorun yaşandığında fark edilebilir.

Yeni site için öneri:

• İlk yedek alındıktan sonra test amaçlı bir geri yükleme (restore) senaryosu çalıştırın.
• Canlı verilerin üzerine yazmadan, ayrı ve erişimi kısıtlı bir test/staging alanına geri yükleyip sitenin çalıştığını doğrulayın. Test kopyasından gerçek e‑posta, ödeme veya diğer dış işlemlerin tetiklenmesini önleyin.
• Bu testi yılda en az bir kez ve önemli uygulama ya da yedekleme değişikliklerinden sonra tekrar edin; kritik veya sık değişen siteler için daha sık test planlayın.

5. Katman: DNS, Alan Adı ve E‑posta Güvenliği

17. DNS Yönetim Yetkilerini Sınırlayın ve Kayıtları Sade Tutun

DNS yönetimi, yeni bir site yayına alınırken güvenlik açısından da ele alınmalıdır. DNS yönetim erişiminin ele geçirilmesi, kayıtların değiştirilerek ziyaretçilerin veya e‑postaların başka sunuculara yönlendirilmesine yol açabilir.

Dikkat etmeniz gerekenler:

• DNS yönetim paneline erişimi çok sınırlı tutun, mümkünse sadece bir‑iki kişi.
• Gereksiz wildcard (*.domain.com) kayıtlarından kaçının.
• MX, SPF, DKIM ve DMARC kayıtlarınızı net ve güncel tutun.

18. Alan Adınızı Kilitleyin, DNSSEC ve Registrar Lock Kullanın

Alan adı güvenliği yalnızca ödeme ve yenilemeden ibaret değildir. Alan adının kontrolünü kaybetmek, hosting güvenli olsa bile sitenize ve e‑posta hizmetlerinize erişimi tehlikeye atabilir. Bu yüzden domain güvenliğini de ilk günden sağlamlaştırmak şart.

Yapmanız gerekenler:

• Alan adınız için destekleniyorsa Registrar Lock (transfer kilidi) özelliğini etkinleştirin; bu kilit DNS hesabı güvenliğinin yerine geçmez.
• DNSSEC için yetkili DNS sağlayıcınızın imzalama desteğini ve registrar üzerinden üst bölgeye DS kaydı ekleme imkânını doğrulayın. DNS bölgesini imzaladıktan sonra sağlayıcının verdiği DS bilgisini registrar üzerinden yayımlayın veya otomatik sürecin bunu yaptığını kontrol edin. DS kaydının etkin DNSKEY ile eşleştiğini ve güven zincirinin doğrulandığını denetleyin.
• İmzalama tek başına üst bölgeden güven zinciri kurmaz. Hatalı veya eski DS kaydı, doğrulama yapan çözümleyicilerde alan adının çözümlenmesini bozabilir. DNS sağlayıcısı veya anahtar değiştirirken DS geçişini koordine edin; DNSSEC’i kapatmadan önce üst bölgedeki DS kaydının kaldırılması ve önbellek sürelerini sağlayıcılarla planlayın.
• Domain hesabınızda da destekleniyorsa 2FA kullanın.

Alan adı güvenliği başlığını daha geniş görmek isterseniz, alan adı güvenliği rehberimizde registrar lock, DNSSEC ve WHOIS gizliliğini detaylı anlattık.

19. SPF, DKIM, DMARC ile E‑posta Kimlik Doğrulamasını Kurun

Yeni sitenizden gönderilen e‑postaların spam klasörüne düşmemesi kadar önemli bir konu daha var: alan adınızın sahte e‑postalarda kötüye kullanılması riskini azaltmak. Bunun temeli de SPF, DKIM ve DMARC kayıtlarının doğru ayarlanmasına dayanıyor.

İlk günden şunları yapın:

• Alan adınız için tüm e‑posta göndericilerini kapsayan bir SPF kaydı tanımlayın.
• Kullandığınız e‑posta altyapısı için DKIM imzasını aktif edin.
• DMARC ile, görünen From alan adıyla hizalı en az bir başarılı SPF veya DKIM doğrulaması bulunmayan iletiler için alıcıya uygulanmasını istediğiniz politikayı bildirin. Önce raporlama ile meşru gönderimleri değerlendirin; karantina veya ret politikasını ancak bu değerlendirmeye göre uygulayın. Posta listelerine katılan kullanıcıları olan genel amaçlı alan adlarında ret politikası önerilmez. Ret politikası kullanacaksanız geçerli DKIM imzalarını sağlayın; yalnızca SPF’ye güvenmeyin. Alıcının nihai kararı diğer kontrollerine de bağlıdır.

Bu ayarların pratik örneklerini ve tipik hataları görmek için, SPF, DKIM, DMARC ve rDNS rehberimize göz atabilirsiniz.

20. E‑posta Hesaplarında Güçlü Şifre ve Destekleniyorsa 2FA Kullanın

Bir saldırı, e‑posta hesabının ele geçirilmesiyle başlayabilir. E‑posta ile parola sıfırlama linkleri alınabiliyor, panel erişimleri açılabiliyor. Bu nedenle yeni bir site açarken, alan adınıza bağlı e‑posta hesaplarının güvenliğini de unutmayın.

Öneriler:

• Tüm kritik e‑posta hesaplarında uzun ve benzersiz şifreler kullanın.
• Kullandığınız e‑posta hizmeti destekliyorsa 2FA aktif edin. Webmail’deki 2FA’nın tüm posta istemcisi bağlantılarını da koruduğunu varsaymayın; IMAP/SMTP erişiminin ve varsa uygulama parolalarının nasıl korunduğunu hizmet belgelerinden doğrulayın, kullanılmayan erişimleri kapatın.
• Paylaşılan posta kutularında (örn. info@, destek@), hizmet destekliyorsa ortak şifre yerine kişisel hesaplara erişim yetkisi verin. Yetkili kişileri kayıt altına alın ve ihtiyaç sona erdiğinde erişimlerini kaldırın. Ortak şifre kullanılıyorsa, erişimi kaldırılacak biri şifreyi biliyorsa veya sızıntı şüphesi varsa şifreyi değiştirin.

Özet: Güvenliği Sonraya Bırakmak Maliyeti Artırabilir

Yeni bir web sitesi açarken bu kadar çok başlıkla uğraşmak ilk bakışta yorucu görünebilir. Ancak güvenliği ilk günden ele almamak, ileride yaşanabilecek bir saldırı veya veri sızıntısının zaman, itibar ve para açısından maliyetini artırabilir. Bu yazıda paylaştığımız 20 maddelik hosting güvenlik check‑list’i, aslında günlük iş akışınıza oturduğunda son derece yönetilebilir bir çerçeve sunuyor.

DCHost planını değerlendirirken hangi güvenlik, yönetim, yedek ve izleme işlerinin dahil olduğunu, hangilerinin size kaldığını doğrulayın. Colocation veya ek güvenlik desteği gerekiyorsa hizmetin varlığını ve kapsamını ayrıca teyit edin. Her madde için sorumluyu, uygulanabilirliği ve kontrol sonucunu kaydedin. Listeyi düzenli bakımda ve önemli uygulama, altyapı, DNS ya da e-posta değişikliklerinden sonra yeniden değerlendirin; güvenlik güncellemelerini bu genel incelemeyi beklemeden takip edin.