Küçük İşletmeler İçin Web Hosting Güvenlik Kontrol Listesi

Küçük işletmeler için web hosting güvenliği neden ayrı bir kontrol listesi ister?

Küçük bir işletmenin web sitesi çoğu zaman şirketin tek dijital vitrini, hatta satış kanalının kalbidir. Buna rağmen güvenlik tarafı genellikle ancak bir sorun yaşandıktan sonra gündeme gelir. DCHost tarafında gördüğümüz ortak tablo şu: Site yayında, e-posta çalışıyor, panel girişi yapılıyor; ama panel, FTP, veritabanı ve yedekler için sistematik bir güvenlik kontrol listesi neredeyse hiç yok.

Bir güvenlik denetimi yaptığımızda en sık şunlarla karşılaşıyoruz: Aynı parolanın hem panele hem FTP’ye hem de veritabanına verilmesi, FTP’nin hâlâ şifresiz çalışması, veritabanı kullanıcılarının gereğinden fazla yetkili olması ve yedeklerin ya hiç test edilmemesi ya da aynı sunucuda şifresiz tutulması. Bunların her biri tek başına kritik bir risk, birlikteyse iş kesintisi + veri kaybı + itibar zararı üçlüsüne davetiye çıkarıyor.

Bu yazıda, DCHost ekibinin sahada en çok gördüğü açıkları temel alarak uygulanabilir bir web hosting güvenlik kontrol listesi çıkaracağız. Odakta dört başlık var: kontrol paneli, FTP/SFTP, veritabanı ve yedekler. Her bölümün sonunda, küçük işletme ölçeğinde yapılması gereken minimum ayarları net maddeler halinde bulacaksınız. Yeni site açıyorsanız, ayrıca şu rehberi de yan sekmede tutmanız faydalı olur: yeni açılan web siteleri için hosting güvenlik check-list’i.

1. Kontrol paneli güvenlik kontrol listesi

cPanel, DirectAdmin, Plesk veya benzeri bir kontrol paneli kullanıyorsanız, tüm web sitenizin kalbine giden ana kapıyı yönetiyorsunuz demektir. cPanel kullanıyorsanız şu yazımızı ayrıca detaylı inceleyebilirsiniz: cPanel hesap güvenliği sertleştirme rehberi. Burada ise panel türünden bağımsız, her küçük işletmenin uygulaması gereken temel maddeleri toplayalım.

1.1. Parola ve giriş güvenliği

• Güçlü, benzersiz parola kullanın: Panel parolanız; e-posta, sosyal medya, muhasebe yazılımı gibi hiçbir yerde kullanılmamalı. En az 12 karakter, büyük/küçük harf, rakam ve sembol içeren bir kombinasyon seçin.
• Parola yöneticisi kullanın: Parolaları hafızada tutmaya çalışmak genelde “kolay ama zayıf” parolalarla sonuçlanır. Kurumsal bir parola yöneticisi ile panel, FTP, veritabanı ve yönetim panelleri için ayrı güçlü parolalar kullanmak çok daha güvenli.
• İki faktörlü doğrulama (2FA) zorunlu olsun: Paneliniz destekliyorsa (cPanel, Plesk vb.) 2FA’yı mutlaka açın. Telefon uygulaması (TOTP) ile çalışan çözümler, SMS’e göre daha güvenlidir.
• Giriş URL’lerini gizlemeye çalışmayın, güçlendirin: “URL’yi bilen girer” mantığı güvenlik değildir. Asıl kritik olan, güçlü parola + 2FA + IP sınırlaması kombinasyonudur.

1.2. IP kısıtlama ve yetki paylaşımı

• Aynı hesabı ekipçe paylaşmayın: Ajansınız, yazılımcınız veya içerik yöneticiniz varsa, her birine ayrı kullanıcı tanımlayın. Mümkünse sadece ihtiyaç duydukları özelliklere yetki verin.
• IP tabanlı erişim kısıtı düşünün: Özellikle yönetim paneline (cPanel/DirectAdmin/Plesk) erişimi ofis sabit IP’leri ile sınırlamak büyük fark yaratır. Eğer sabit IP’niz yoksa, en azından yaygın saldırı IP bloklarını engelleyen bir WAF/Firewall katmanınız olsun.
• Eski erişimleri temizleyin: Ajans değişmiş, geliştirici ayrılmış veya proje kapanmış olabilir. Panel kullanıcılarını 6 ayda bir gözden geçirip gereksiz olanları silin.

1.3. Panel güncellemeleri, loglar ve bildirimler

• Panel versiyonunu güncel tutun: Eğer kendi VPS veya dedicated sunucunuzda panel kullanıyorsanız, güncellemeleri ertelemeyin. Panel tarafındaki kritik bir zafiyet tüm müşteri sitelerini etkileyebilir.
• Giriş loglarını düzenli kontrol edin: Panelinize kim, hangi IP’den, hangi saatte girmiş görebiliyor musunuz? Olağan dışı IP veya saatleri fark etmek için en azından haftalık kısa bir kontrol rutin edinin.
• Mail bildirimlerini kapatmayın: Şüpheli giriş uyarıları, kota aşımı, otomatik yedek hataları gibi e-postalar çoğu zaman “spam” diye klasöre gömülür. Bu bildirimleri alan bir operasyon mail adresi belirleyin ve gerçekten takip edin.

1.4. Küçük işletmeler için minimum panel güvenlik paketi

Aşağıdaki maddeler, küçük bir işletmenin panelinde mutlaka işaretli olması gerekenlerdir:

• Panel parolası benzersiz ve güçlü, yılda en az 1 kere değiştiriliyor.
• 2FA aktif ve en az iki yönetici için tanımlı.
• Panel erişim kullanıcı bazlı; ajans veya geliştirici ile “tek parola” paylaşılmıyor.
• Panel güncellemeleri otomatik veya düzenli olarak kontrol ediliyor.
• Şüpheli giriş ve yedek hatası uyarıları aktif, bir operasyon mailine düşüyor.

2. FTP/SFTP ve dosya erişimi kontrol listesi

Bugün hâlâ en çok gördüğümüz risklerden biri, klasik FTP kullanımının bırakılmamış olması. Klasik FTP, parolanızı ve dosya trafiğinizi şifrelemeden iletir. Yani aynı ağdaki bir saldırgan, teknik olarak kullanıcı adınızı ve parolanızı okuyabilir. Bu yüzden daha önce detaylı olarak anlattığımız gibi, FTP yerine SFTP kullanmanın zamanı çoktan geldi.

2.1. Protokol seçimi: FTP kapalı, SFTP/FTPS açık

• FTP’yi tamamen kapatın: Mümkünse sunucunuzda FTP servisini devre dışı bırakın. paylaşımlı hosting kullanıyorsanız, en azından FTP hesabı oluşturmayın ve var olanları silin.
• SFTP veya FTPS kullanın: SFTP (SSH üzerinden dosya transferi) veya FTPS (TLS ile şifrelenmiş FTP) kullanarak dosya trafiğini şifreleyin. SFTP genellikle daha modern ve güvenli bir tercih.
• İstemci tarafını güncelleyin: Ekipteki herkesin kullandığı FTP programının (FileZilla vb.) güncel olduğundan emin olun; eski sürümlerde güvenlik açıkları olabilir.

2.2. Kullanıcı, klasör ve izin mimarisi

• Her kişi için ayrı SFTP hesabı: “Tek FTP hesabı + herkes biliyor” senaryosu en riskli modellerden biridir. Geliştirici, ajans ve içerik yöneticisi için ayrı hesap açın.
• Klasör kısıtlaması yapın (chroot/jail): Mümkünse her SFTP kullanıcısını sadece kendi site dizinine veya ilgili alt klasöre kısıtlayın. Böylece yanlışlıkla başka bir sitenin dosyalarına müdahale edilmez.
• Salt okunur hesaplar: Sık sık sadece log çekmesi veya yedek alması gereken biri varsa, yazma yetkisi olmayan salt okunur hesap açmak daha güvenli.

2.3. Dosya izinleri ve sahiplik

Yanlış dosya izinleri, paylaşımlı hosting veya çok siteli VPS yapılarında en sık gördüğümüz açıklar arasında. Detay için şu rehbere mutlaka göz atın: Linux dosya izinleri 644, 755, 777 için güvenli ayarlar. Özet kontrol listesi şöyle:

• PHP dosyaları için 644: Çoğu durumda dosyalar 644 (sahip: okuma/yazma, grup/diğer: okuma) olmalı. 666 veya 777 gibi herkese yazma izni veren modlar risklidir.
• Klasörler için 755: Standart olarak klasörler 755 olmalı. 777 klasörler, zararlı scriptlerin kendini her yere yazmasını kolaylaştırır.
• Sahiplik (owner) kontrolü: Dosyalar web sunucusu kullanıcısına değil, ilgili hosting hesabının kullanıcısına ait olmalı. Aksi durumda başka siteler üzerinden dosyalarınıza erişim kolaylaşabilir.

2.4. Küçük işletmeler için minimum FTP/SFTP güvenlik paketi

• FTP tamamen kapalı, sadece SFTP (veya FTPS) kullanılıyor.
• Her ekip üyesi için ayrı SFTP hesabı var; ortak parola paylaşımı yok.
• Her SFTP hesabı sadece ilgili site dizinine erişebiliyor.
• Dosya izinleri genel olarak 644, klasörler 755; 777 kullanımına gerek yok.
• Eski ve kullanılmayan SFTP/FTP hesapları düzenli olarak siliniyor.

3. Veritabanı güvenliği kontrol listesi

WordPress, WooCommerce, özel yazılım veya SaaS fark etmeksizin neredeyse tüm modern siteler veritabanı kullanıyor. Veritabanı çökmesi veya ele geçirilmesi, sadece sitenin kapanması değil, müşteri verilerinizin sızması anlamına da gelebilir. Bu da KVKK/GDPR gibi mevzuatlar açısından ciddi sonuçlar doğurabilir.

3.1. Kullanıcı ve şema (veritabanı) ayrımı

• Her uygulama için ayrı veritabanı ve kullanıcı: Aynı panelde birden fazla site varsa, her site için ayrı veritabanı ve kullanıcı oluşturun. Tek kullanıcıyla tüm veritabanlarına erişim, saldırgan için hayatı çok kolaylaştırır.
• Minimum yetki prensibi: Veritabanı kullanıcısına genelde “SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX” gibi temel yetkiler yeterlidir. Sunucu seviyesinde yönetici yetkileri (SUPER vb.) uygulama kullanıcılarında olmamalı.
• Uygulama ile root parolasını paylaşmayın: “root” veya tam yetkili bir hesabı doğrudan web uygulamasına (config.php, .env vb.) yazmak büyük hatadır.

3.2. Uzak erişim, firewall ve şifreleme

• Uzak veritabanı bağlantılarını sınırlayın: Zorunlu olmadıkça veritabanını internetten erişilebilir yapmayın. Eğer uygulama ve veritabanı farklı sunuculardaysa, aradaki erişimi sadece gerekli IP bloklarına açın.
• Firewall kuralı koyun: VPS veya dedicated kullanıyorsanız, veritabanı portunu (MySQL/MariaDB için 3306 gibi) sadece uygulama sunucusunun IP’sine açın.
• Şifreli bağlantı (TLS) değerlendirin: Özellikle veritabanına internet üzerinden veya farklı veri merkezlerinden bağlanıyorsanız TLS ile şifrelendirilmiş bağlantı kullanmayı değerlendirin.

3.3. Uygulama tarafı: .env, prepared statement ve loglar

• .env ve config dosyaları korunmalı: Uygulama yapılandırma dosyalarında veritabanı parolaları düz metin olarak durur. Bu dosyaların web root’tan doğrudan indirilememesi ve yedeklerde de şifreli tutulması kritik. Ayrı bir rehberde detaylandırdığımız gibi, gizli bilgiler için güvenli saklama yaklaşımları kullanmak çok önemlidir: VPS üzerinde gizli bilgi yönetimi rehberi.
• SQL injection’a karşı prepared statement: Geliştirici ekibiniz, veritabanı sorgularında prepared statement (hazırlanmış ifade) kullanmalı. Bu, özellikle form ve arama alanlarından gelen verilerin güvenli işlenmesi için şart.
• Hata mesajlarını sınırlayın: Canlı ortamda ayrıntılı SQL hata mesajlarını ziyaretçiye göstermeyin. Detaylı loglar sadece sunucu loglarında ve geliştirici tarafında görülebilmeli.

3.4. Veritabanı yedekleri ve test geri yükleme

• Düzenli otomatik yedek: Veritabanı günlük veya en azından haftalık otomatik yedeklenmeli. Yoğun sipariş alan e-ticaret siteleri için sıklık daha fazla olmalı.
• Yedekleri test edin: “Yedeğimiz var” demek, en son geri yükleme testinin tarihini bilmeden aslında pek bir şey ifade etmez. Belirli aralıklarla boş bir ortamda yedeği geri yükleyip test edin.
• Yedekler şifreli olsun: Özellikle veritabanı yedekleri müşteri verisi içeriyorsa mutlaka şifrelenmiş şekilde saklanmalı.

3.5. Küçük işletmeler için minimum veritabanı güvenlik paketi

• Her site için ayrı veritabanı ve kullanıcı kullanılıyor.
• Veritabanı kullanıcılarında minimum yetki prensibi uygulanıyor.
• Veritabanı portu internete açık değil veya belirli IP’lerle sınırlandırılmış.
• .env/config dosyaları web üzerinden erişilemiyor; yedeklerde şifreli.
• Veritabanı yedekleri düzenli alınıyor ve yılda en az 1-2 kez geri yükleme testi yapılıyor.

4. Yedekleme ve felaket kurtarma kontrol listesi

Güvenlik tarafında her şeyi çok iyi yapıyor olsanız bile, insan hatası, eklenti güncellemesi, veri merkezi sorunu veya yazılım hatası yüzünden veri kaybı yaşanabilir. Bu yüzden güvenli hosting stratejisinin kritik bölümü her zaman yedekleme ve felaket kurtarma mimarisidir.

Daha önce ayrıntılı anlattığımız üzere, 3-2-1 yedekleme stratejisi küçük işletmeler için en pratik ve etkili çerçevelerden biri. Kısaca: 3 kopya, 2 farklı ortam, 1 tanesi farklı lokasyonda olacak şekilde yedek planlamak.

4.1. Ne sıklıkta, neyi yedeklemelisiniz?

• Veritabanı yedeği: Sipariş, form başvurusu veya üyelik alan sitelerde en kritik kısım veritabanıdır. E-ticaret için en az saatlik veya 4 saatlik; kurumsal siteler için günlük yeterli olabilir.
• Dosya yedeği: Uygulama dosyaları, yüklenen görseller ve belgeler de düzenli yedeklenmeli. Değişim sıklığına göre günlük veya haftalık planlanabilir.
• Konfigürasyon ve panel ayarları: DNS, SSL, e-posta, cron job gibi ayarlarınızı da içeren panel yedekleri, bir kesinti sonrası çok zaman kazandırır.

4.2. Yedeklerin saklandığı yer ve şifreleme

• Aynı sunucuda tek yedeğe güvenmeyin: Sunucuda tutulan yedekler disk arızası veya fidye yazılımı saldırısı durumunda işe yaramayabilir. Mutlaka uzak bir lokasyonda ikinci bir kopyanız olsun.
• Yedekleri şifreleyin: Özellikle müşteri verisi içeren yedeklerin, şifreli arşivler veya yedek yazılımlarının dahili şifreleme özelliği ile korunması gerekir. Detay için şu rehbere de bakabilirsiniz: yedek şifreleme ve anahtar yönetimi rehberi.
• Erişim yetkilerini sınırlayın: Yedek depolama alanına (S3 benzeri obje depolama, uzak FTP/SFTP, başka bir sunucu vb.) sadece yetkili birkaç kişi erişebilmeli.

4.3. Geri dönüş (restore) senaryoları ve RPO/RTO

Yedek planlarken iki kritik kavram vardır: RPO (Recovery Point Objective) ve RTO (Recovery Time Objective). Bunları daha geniş açıdan RPO/RTO ve yedekleme stratejisi rehberimizde anlatıyoruz, ama küçük işletme açısından özetleyelim:

• RPO (Ne kadar veri kaybına katlanırım?): Günde 1 kez yedek alıyorsanız, en kötü senaryoda 24 saatlik veri kaybını göze alıyorsunuz demektir. Sipariş hacminiz yüksekse bu süreyi düşürmeniz gerekir.
• RTO (Site ne kadar süre kapalı kalabilir?): Yedeği geri yükleyip sistemi ayağa kaldırmanız kaç saat sürebilir? Bu süreyi test etmeden bilmek zordur, mutlaka deneme restore yapmalısınız.

4.4. Küçük işletmeler için minimum yedekleme ve kurtarma paketi

• Veritabanı ve dosyalar için otomatik yedekleme aktif.
• Yedeklerin en az bir kopyası farklı bir lokasyonda (farklı sunucu/obje depolama) saklanıyor.
• Yedekler şifreli tutuluyor, erişim sadece yetkili kişilere açık.
• Yılda en az 1 kez felaket kurtarma provası yapılıyor; geri dönüş süresi ölçülüyor.
• Yedekleme raporları (başarılı/başarısız) e-posta ile takip ediliyor.

5. Küçük işletmeler için pratik günlük/aylık güvenlik rutini

Güvenlik kontrol listesini bir kere üzerinden geçmek önemli ama yeterli değil. Birçok olayda gördüğümüz ortak nokta şu: Kurulum başta düzgün yapılmış, ama 6–12 ay boyunca kimse dokunmamış. Sonra eski parolalar, güncellenmemiş eklentiler ve dolu diskler birikmiş sorunlara yol açıyor.

Küçük bir işletme için gerçekçi ve uygulanabilir bir rutin şöyle olabilir:

5.1. Haftalık yapılacaklar

• Panel giriş loglarında olağan dışı IP veya başarısız giriş var mı, kısaca göz atın.
• Otomatik yedeklerin gerçekten oluştuğunu ve son tarihlerinin mantıklı olduğunu kontrol edin.
• CMS (WordPress, Joomla, Drupal vb.) ve eklentiler için bekleyen kritik güvenlik güncellemesi var mı bakın.

5.2. Aylık yapılacaklar

• Eski SFTP/FTP hesaplarını ve panel kullanıcılarını gözden geçirip kullanılmayanları silin.
• Veritabanı ve dosya yedeklerinden en az birini test ortamına geri yükleyin.
• Disk kullanımını, inode durumunu ve logların büyüklüğünü kontrol edin; sunucuyu dolu diske sürüklemeyin.
• HTTP güvenlik başlıkları, SSL durumu ve HTTPS yönlendirmelerini gözden geçirmek için şu rehbere de uğrayın: HTTP güvenlik başlıkları rehberi.

5.3. Yılda birkaç kez yapılacaklar

• Tüm yönetici parolalarını (panel, SFTP, veritabanı yönetim aracı vb.) güncelleyin.
• Ajansınızla veya geliştiricinizle birlikte kapsamlı bir güvenlik gözden geçirmesi yapın.
• Felaket kurtarma provası yaparak, “sunucu tamamen kayboldu” varsayımıyla yeni bir sunucuda yedekten ayağa kaldırma sürecini test edin.

6. DCHost ile bu kontrol listesini hayata geçirmek

Yukarıdaki maddelerin hepsi küçük işletmeler için uygulanabilir, ama her birini tek tek takip etmek yorucu görünebilir. DCHost tarafında, hem paylaşımlı hosting hem de VPS/dedicated çözümlerimizde bu kontrol listesini hayata geçirmenizi kolaylaştırmak için şu pratikleri benimsiyoruz:

• Kontrol paneli seviyesinde 2FA, IP kısıtlama ve detaylı loglama imkânı sunuyoruz.
• SFTP’yi varsayılan, klasik FTP’yi ise mümkün olan her yerde devre dışı bırakılmış durumda tutmayı teşvik ediyoruz.
• Veritabanı kullanıcı ayrımı, firewall kuralları ve TLS ayarları için teknik ekibimizle birlikte planlama yapabiliyorsunuz.
• 3-2-1 prensibine uygun otomatik yedekleme ve uzak yedek seçenekleri sağlıyoruz; geri yükleme testlerinde ekibimizle birlikte senaryo çalışabiliyorsunuz.

Eğer bu yazıyı okurken kendi siteniz için “Şu madde bizde eksik kalmış” dediğiniz noktalar olduysa, bunu bir alarm değil, iyileştirme fırsatı olarak görmek en sağlıklı yaklaşım. Kontrol listesini bir doküman hâline getirip, şirket içinde basit bir sorumlu atayın ve tarihli olarak işaretlemeye başlayın. DCHost olarak, panel, FTP/SFTP, veritabanı ve yedek güvenliği konusunda yapısal bir plan çıkarmak isterseniz, destek taleplerinizde bu makaleye atıf yapmanız yeterli; ekibimiz sizinle işletmenize uygun somut bir yol haritası paylaşmaktan memnuniyet duyar.