Kurumsal Web Sitesi Güvenliği İçin Hangi Önlemler Alınmalıdır?

Kurumsal Web Sitesi Güvenliği Nasıl Planlanmalıdır?

Kurumsal web sitesi güvenliği, iş hedefleriyle uyumlu, risk temelli ve katmanlı bir program olarak planlanmalıdır. Security by Design, güvenlik gereksinimlerinin proje başlangıcından itibaren tasarım ve geliştirme kararlarına katılmasıdır; Secure by Default ise sistemin ilk yapılandırmada gereksiz erişimleri kapalı ve koruyucu ayarları etkin sunmasını amaçlar. Güvenlik, sonradan eklenen bir ürün değil, yönetilen bir süreçtir.

Web sitesi güvenliğinden kimler sorumludur?

Sorumluluk yalnızca geliştiriciye veya IT ekibine bırakılamaz. Yönetim risk kabulünü ve bütçeyi, hukuk ile veri koruma ekipleri yükümlülükleri, içerik ve pazarlama ekipleri üçüncü taraf araçları, hizmet sağlayıcılar ise sözleşmedeki teknik kontrolleri yönetir. Alan adı, DNS, barındırma, CDN, yönetim paneli ve kurumsal e-posta hesaplarının sahipliği kurumda kalmalı; erişim onayları ve görev değişiklikleri kayıt altına alınmalıdır.

• Korunacak sistemleri, verileri ve iş süreçlerini açıkça tanımlayın.
• Her güvenlik kontrolü için sorumlu ve onay makamı belirleyin.
• Teknik kabul kriterlerini proje planına ve sözleşmeye ekleyin.
• Ayrıcalıklı hesapların sahipliğini ve kullanım kayıtlarını koruyun.
• Riskleri geliştirme, yayın ve bakım boyunca yeniden değerlendirin.

Güvenlik bir ürün değil, bir süreçtir. - Bruce Schneier

Risk Analizi ve Tehdit Modellemesi Nasıl Yapılmalıdır?

Risk analizi, kurumun hangi varlıkları koruduğunu, bunlara kimlerin eriştiğini, olası tehditleri ve gerçekleşme hâlinde oluşabilecek iş etkisini belirleyerek yapılmalıdır. Veri envanteri; iletişim formlarından müşteri kayıtlarına, yönetici oturumlarından entegrasyon anahtarlarına kadar bilgi akışını göstermelidir. Böylece güvenlik bütçesi, düşük etkili varsayımlar yerine kurumun gerçek saldırı yüzeyine ve veri hassasiyetine yönlendirilebilir.

Tehdit modellemesinde hangi sorular sorulmalıdır?

Tehdit modellemesi, sistemin bileşenlerini ve güven sınırlarını inceleyerek bir saldırganın hangi yolları kullanabileceğini öngörür. Kullanıcı rolleri, veri giriş noktaları, API bağlantıları, dosya yüklemeleri, yönetim işlevleri ve üçüncü taraf scriptleri bu incelemeye dâhil edilmelidir. Her risk için olasılık, etki, mevcut kontrol, kalan risk ve iyileştirme sahibi kaydedilmelidir. Model, mimari veya iş süreci değiştikçe güncellenmelidir.

• İşlenen verileri türüne, hassasiyetine ve saklama süresine göre sınıflandırın.
• Formlar, API’ler, paneller ve entegrasyonlar üzerinden saldırı yüzeyini çıkarın.
• Kullanıcı, yönetici, tedarikçi ve saldırgan senaryolarını ayrı değerlendirin.
• Riskleri iş kesintisi, itibar, hukuk ve veri etkileriyle önceliklendirin.
• Kabul edilen riskleri gerekçesi ve onaylayanı ile belgelendirin.

Güvenli Mimari ve Ortam Ayrımı Nasıl Kurulmalıdır?

Güvenli yazılım mimarisi; en az ayrıcalık, görevler ayrılığı, güvenli varsayılanlar, katmanlı savunma ve izlenebilirlik ilkelerine dayanmalıdır. İnternet üzerinden erişilen uygulama, yönetim işlevleri, veri tabanı ve dosya depolama bileşenleri gereksiz doğrudan erişime açılmamalıdır. Bir katmanın aşılması durumunda diğer kontrollerin riski sınırlandırabilmesi için ağ, uygulama, kimlik ve veri seviyelerinde birbirini tamamlayan önlemler kurulmalıdır.

Geliştirme, test ve canlı ortamları neden ayrılmalıdır?

Geliştirme, test ve canlı ortamların ayrılması; gerçek verilerin kontrolsüz kullanılmasını, test araçlarının yayında kalmasını ve bir ortamın ele geçirilmesinin diğerlerine yayılmasını önlemeye yardımcı olur. Her ortamın ayrı hesapları, erişim kuralları ve gizli değerleri bulunmalıdır. API anahtarları, parolalar ve sertifika anahtarları kaynak kodda tutulmamalı; erişimi denetlenen gizli değer yönetim sistemlerinde saklanmalı ve gerektiğinde güvenle yenilenmelidir.

• Canlı veri tabanını yalnızca gerekli servislerden erişilebilir hâle getirin.
• Geliştirme ve test verilerini anonimleştirin veya yapay veri kullanın.
• Her ortam için farklı kimlik bilgileri ve erişim politikaları oluşturun.
• Gizli değerleri sürüm kontrolünden ve istemci kodundan uzak tutun.
• Dağıtım yetkileri ile kod onay yetkilerini mümkün olduğunca ayırın.

Kimlik Doğrulama ve Yetkilendirme Nasıl Korunmalıdır?

Kimlik doğrulama, kullanıcının iddia ettiği kişi olduğunu doğrular; yetkilendirme ise doğrulanmış kullanıcının hangi kaynaklara ve işlemlere erişebileceğini belirler. Bu iki kontrol ayrı tasarlanmalı ve her hassas istekte sunucu tarafında uygulanmalıdır. Yönetim paneli, barındırma, DNS ve kod deposu gibi ayrıcalıklı hesaplarda çok faktörlü kimlik doğrulama kullanılmalı; ortak yönetici hesaplarından ve gereksiz geniş yetkilerden kaçınılmalıdır.

Hesap ve oturum güvenliği hangi kontrolleri gerektirir?

Parola politikası tek başına hesap güvenliği sağlamaz. Benzersiz parolaları destekleyen güvenli saklama yöntemleri, kaba kuvvet saldırılarına karşı hız sınırlama, güvenli hesap kurtarma ve şüpheli giriş bildirimleri birlikte değerlendirilmelidir. Rol tabanlı erişim kontrolü, kullanıcıya yalnızca görevi için gereken yetkileri vermelidir. Oturumlar tahmin edilemeyen belirteçlerle yönetilmeli, süreleri riske göre sınırlandırılmalı ve yetki değişikliğinde geçersiz kılınmalıdır.

• Ayrıcalıklı ve uzaktan erişilen hesaplarda çok faktörlü doğrulama uygulayın.
• Her yönetici için kişisel ve izlenebilir bir hesap oluşturun.
• Başarısız girişleri sınırlayın, kaydedin ve anormal davranışta alarm üretin.
• Hesap kurtarma sürecinde kimliği bağımsız kontrollerle doğrulayın.
• Rol ve erişim yetkilerini düzenli olarak yeniden inceleyin.

Güvenli Kodlama, Form ve API Kontrolleri Nelerdir?

Güvenli kod geliştirme; tüm dış girdilerin güvenilmez kabul edilmesini, sunucu tarafında doğrulanmasını ve kullanılacağı bağlama göre güvenli işlenmesini gerektirir. SQL injection riskine karşı parametreli sorgular, Cross-Site Scripting saldırılarına karşı bağlama uygun çıktı kodlama, Cross-Site Request Forgery riskine karşı oturumla ilişkilendirilmiş CSRF kontrolleri uygulanmalıdır. OWASP kaynakları yaygın riskleri anlamaya yardımcı olur; ancak projeye özel tehdit modelinin veya incelemenin yerini tutmaz.

Form, API ve dosya yüklemeleri nasıl korunur?

Formlar ve API’ler; kimlik, yetki, istek boyutu, veri türü, hız sınırı ve hata yanıtları bakımından sunucuda denetlenmelidir. Cross-Origin Resource Sharing yapılandırması erişim kontrolünün yerine geçmez. Dosya yüklemelerinde yalnızca uzantıya güvenilmemeli; içerik türü ve imza doğrulanmalı, adlar yeniden üretilmeli, boyut sınırlandırılmalı ve dosyalar mümkünse web kökü dışında saklanmalıdır. Zararlı içerik taraması da risk düzeyine göre eklenmelidir.

• Veri tabanı işlemlerinde parametreli sorgu veya güvenli ORM yöntemleri kullanın.
• Çıktıları HTML, URL ve JavaScript bağlamına uygun kodlayın.
• Durum değiştiren isteklerde uygun CSRF korumasını doğrulayın.
• API nesneleri için kullanıcı ve işlem bazında yetki kontrolü yapın.
• Dosya türünü, içeriğini, boyutunu ve depolama konumunu denetleyin.
• Hata mesajlarında sistem veya veri tabanı ayrıntılarını göstermeyin.

Veri, HTTPS, Güvenlik Başlıkları ve KVKK Nasıl Yönetilir?

Veri koruma, gereksiz veriyi toplamamakla başlamalı; erişim sınırlama, saklama süresi, güvenli silme ve uygun şifreleme kontrolleriyle sürdürülmelidir. Transport Layer Security kullanan HTTPS, tarayıcı ile sunucu arasındaki aktarımı korur; ancak uygulamadaki yetki hatalarını, zararlı kodu veya sunucu yanlış yapılandırmalarını ortadan kaldırmaz. Bu nedenle SSL sertifikası, bütün bir site güvenliği programının gerekli fakat tek başına yeterli olmayan bileşenidir.

Güvenlik başlıkları ve KVKK yükümlülükleri nasıl uygulanır?

HTTP Strict Transport Security tarayıcıyı sonraki bağlantılarda HTTPS kullanmaya yönlendirirken Content Security Policy, yüklenebilecek kaynakları sınırlandırarak belirli istemci tarafı tehditlerini azaltmaya yardımcı olur. Bu politikalar uygulamaya özel test edilmeli, kopyala-yapıştır ayarlar olarak görülmemelidir. Çerezlerde Secure, HttpOnly ve uygun SameSite tercihleri amaçla uyumlu belirlenmelidir. KVKK uyumu yalnızca aydınlatma metni veya çerez banner’ı değil, teknik ve idari tedbirlerin bütünüdür.

• Yalnızca açık iş amacı bulunan kişisel verileri toplayın.
• Aktarılan ve saklanan hassas veriler için uygun şifreleme belirleyin.
• HSTS ve Content Security Policy ayarlarını aşamalı olarak test edin.
• Oturum çerezlerinin kapsamını ve tarayıcı erişimini sınırlandırın.
• Saklama, silme, erişim ve ihlal süreçlerini kurum politikalarıyla eşleştirin.

Sunucu, CMS ve Bağımlılık Güvenliği Nasıl Sağlanır?

Sunucu güvenliği, yalnızca işletim sistemini güncellemekten ibaret değildir; gereksiz servislerin kapatılması, ağ erişiminin sınırlandırılması, güvenli yönetim kanalları, veri tabanı yetkileri, DNS ve bulut hesaplarının korunması birlikte ele alınmalıdır. Web Application Firewall belirli zararlı istekleri filtreleyebilir, CDN tabanlı DDoS koruması erişilebilirlik riskini azaltabilir; ancak bu katmanlar güvenli kodlama ve doğru yapılandırmanın alternatifi değildir.

WordPress, Laravel ve üçüncü taraf paketler nasıl yönetilir?

WordPress güvenliği eklenti ve tema seçimiyle; Laravel güvenliği ise framework, Composer paketleri, uygulama kodu ve dağıtım yapılandırmasıyla birlikte değerlendirilmelidir. Hiçbir platform adı tek başına güvenlik sonucu belirlemez. CMS, framework ve bağımlılıklar için envanter, güvenlik duyurusu takibi, kontrollü güncelleme, uyumluluk testi ve geri dönüş planı bulunmalıdır. Kullanılmayan bileşenler kaldırılmalı, terk edilmiş paketlerin yerine sürdürülen seçenekler değerlendirilmelidir.

• Sunucu, veri tabanı, DNS ve bulut yönetimini ayrıcalıklı erişimle sınırlandırın.
• Kullanılmayan servisleri, eklentileri, temaları ve paketleri kaldırın.
• Bağımlılık envanterini ve yayımlanan güvenlik bildirimlerini takip edin.
• Yamaları test ortamında doğrulayıp geri dönüş planıyla yayınlayın.
• Üçüncü taraf script ve entegrasyonların veri erişimini inceleyin.
• WAF ve DDoS kontrollerinin kapsamını düzenli olarak doğrulayın.

Test, Yedekleme ve Olay Müdahalesi Nasıl Planlanır?

Web sitesi güvenlik testi; kod incelemesi, yapılandırma kontrolü, bağımlılık analizi, otomatik tarama ve risk temelli manuel testleri birlikte içermelidir. Güvenlik açığı taraması bilinen zayıflıkları geniş ölçekte ve tekrarlanabilir biçimde arar; penetrasyon testi ise belirli kapsam içinde açıkların gerçekçi saldırı yollarıyla kullanılabilirliğini ve etkisini uzman değerlendirmesiyle inceler. Otomatik araç çıktıları yanlış sonuçlara karşı manuel olarak doğrulanmalıdır.

Yedekleme, izleme ve güvenlik olayı yönetimi nasıl işler?

Yedekler şifreli, erişimi sınırlı ve canlı sistemden mantıksal olarak ayrılmış konumlarda tutulmalıdır; güvenilirlikleri ancak düzenli geri yükleme testleriyle doğrulanabilir. Merkezi loglama; kimlik doğrulama, yetki değişikliği, yönetim işlemi ve kritik uygulama hatalarını anlamlı bağlamla kaydetmelidir. Olay müdahale planı; tespit, sınırlama, kanıt koruma, iletişim, gerekli bildirim, kurtarma ve kök neden analizinin sahiplerini önceden belirlemelidir.

• Tarama kapsamını tüm uygulama, API ve dışa açık varlıkları içerecek şekilde belirleyin.
• Kritik bulgular için sorumlu, hedef tarih ve yeniden test tanımlayın.
• Yedekleri canlı sistemden ayrı tutun ve geri yüklemeyi sınayın.
• Önemli logları merkezi ortamda koruyup anomali alarmları üretin.
• Olay iletişimi, kanıt koruma ve karar yetkilerini önceden belgeleyin.
• Müdahale sonrasında kök nedeni giderip kontrolleri güncelleyin.

Bakım Maliyeti ve Güvenlik Sağlayıcısı Nasıl Seçilir?

Yayın sonrasında güvenlik; yama yönetimi, bağımlılık takibi, erişim incelemeleri, sertifika ve alan adı kontrolleri, taramalar, log izleme ve olay hazırlığıyla sürekli yürütülmelidir. Maliyet; sistem kapsamı, veri hassasiyeti, kullanıcı ve rol yapısı, özel yazılım, entegrasyonlar, barındırma mimarisi, test derinliği, mevzuat ihtiyaçları, izleme sıklığı, destek seviyesi ve olay müdahalesi kapsamına göre değişir. Bu nedenle karşılaştırma yalnızca başlangıç bedeli üzerinden yapılmamalıdır.

Web güvenlik hizmeti teklifinde hangi teslimatlar aranmalıdır?

Web tasarım ajansı, yazılım ajansı veya siber güvenlik firması seçerken yalnızca “güvenli altyapı” ve “SSL dâhil” ifadeleri yeterli kabul edilmemelidir. Teklif; sorumluluk matrisi, güvenlik gereksinimleri, kod ve yapılandırma incelemeleri, test yöntemi, bulgu raporu, düzeltme doğrulaması, yedekleme, izleme ve bakım sürelerini açıklamalıdır. Doğru sağlayıcı seçimi, üstünlük iddiasından çok doğrulanabilir teslimatlara, uzmanlığa ve açık görev sahipliğine dayanır.

• Teklifte güvenlik kapsamını, hariç tutulan alanları ve sorumlulukları arayın.
• Test yöntemini, rapor biçimini ve yeniden test sürecini netleştirin.
• Yama, acil müdahale ve destek sürelerinin nasıl yönetileceğini sorun.
• Alan adı, kod, hesap, log ve veri sahipliğini sözleşmede koruyun.
• Tedarikçinin referanslarını, ekip yetkinliğini ve iletişim modelini değerlendirin.
• Sürekli iyileştirme ve periyodik risk değerlendirmesini bakım kapsamına ekleyin.