Kurumsal Web Sitesinde Veri Güvenliği: Şifreleme ve Güvenli Veri Yönetimi Rehberi

Kurumsal bir web sitesinde veri güvenliği, formdan gelen bir teklif talebinden yönetim paneli şifresine kadar sitenin taşıdığı her bilginin teknik olarak korunması demektir. Bu rehberde HTTPS, parola saklama, veritabanı şifreleme, yedekleme ve erişim yetkilerini sahada uyguladığım sırayla anlatıyorum. Hukuki uyum tarafına girmiyorum; odağım tamamen teknik katman.

Kurumsal web sitesinde veri güvenliği nedir?

Veri güvenliği, bir web sitesinin topladığı, sakladığı ve aktardığı bilgilerin yetkisiz kişilerce okunmasını, değiştirilmesini ya da silinmesini engelleyen teknik önlemlerin bütünüdür. Kurumsal sitede bu; aktarımda şifreleme, parolaların güvenli saklanması, yedekleme ve rol bazlı erişim olmak üzere dört ana ayağa dayanır.

Güvenlik ekipleri bu hedefleri genellikle üç kelimeyle özetler: gizlilik, bütünlük ve erişilebilirlik. Gizlilik, bilgiyi yalnızca yetkili kişinin görmesidir. Bütünlük, verinin yolda ya da diskte fark edilmeden değişmemesidir. Erişilebilirlik ise sitenin ve verinin ihtiyaç anında ayakta olmasıdır.

Ben projelerde bu üçlüyü soyut bir kavram olarak bırakmıyorum. Örneğin gizlilik için TLS ve alan şifrelemesine, bütünlük için dosya değişiklik takibine, erişilebilirlik için test edilmiş yedeklere bakıyorum. Böylece her ilke somut bir kontrol maddesine dönüşüyor.

Kurumsal siteler neden hedef olur, küçük firmayız diye güvende miyiz?

Hayır, küçük olmak koruma sağlamaz. Saldırıların büyük kısmı belirli bir firmayı seçmez; otomatik tarayıcılar internetteki tüm adresleri bilinen açıklar için tek tek dener. Eski sürümde kalan bir eklenti, varsayılan bir yönetici adı ya da açık kalmış bir yedek dosyası bu tarayıcılar için yeterli bir davettir.

Kurumsal sitenin taşıdığı veri de sanıldığından değerlidir. İletişim formları isim, telefon ve e-posta toplar. Teklif formları firma bilgisi ve bütçe içerir. Yönetim paneli ise sitenin tamamının anahtarıdır. Üstelik saldırganlar ele geçirdikleri siteyi çoğu zaman spam sayfası barındırmak ya da başka sitelere saldırmak için kullanır; bu da marka itibarına ve arama görünürlüğüne doğrudan zarar verir.

Sahada gördüğüm en yaygın tablo şudur: siteyi biri yıllar önce kurmuş, ajansla bağ kopmuş ve kimse güncellemeleri takip etmiyor. Bu nedenle ilk işim her zaman bir envanter çıkarmaktır: hangi yazılım, hangi sürüm, kimin erişimi var.

HTTPS ve TLS verileri nasıl korur?

HTTPS, tarayıcı ile sunucu arasındaki trafiği TLS protokolüyle şifreler. Böylece aynı kablosuz ağdaki biri ya da aradaki bir cihaz, form ile gönderilen bilgiyi okuyamaz ve sayfaya kod ekleyemez. Ayrıca sertifika, ziyaretçinin gerçekten sizin sunucunuza bağlandığını doğrular.

Google, HTTPS kullanımını 2014'ten beri bir sıralama sinyali olarak açıkladı ve Search Central belgelerinde siteyi HTTPS ile güvenceye almayı öneriyor. Yani güvenlik ile SEO burada aynı yöne bakıyor. Chrome ise şifresiz sayfaları adres çubuğunda "Güvenli değil" diye işaretliyor.

Yine de sertifikanın varlığı tek başına yeterli değildir. Sunucu eski protokollere hâlâ izin veriyorsa ya da sayfa içinde HTTP ile yüklenen dosyalar varsa koruma zayıflar. Sertifikalar artık Let's Encrypt gibi ücretsiz ve otomatik yenilenen seçeneklerle kolayca alınabiliyor; dolayısıyla asıl emeği yapılandırmaya harcamalısınız.

TLS yapılandırmasında nelere dikkat etmelisiniz?

İlk kural eski protokolleri kapatmaktır. TLS 1.0 ve 1.1 artık güvenli kabul edilmiyor; sunucunuz yalnızca TLS 1.2 ve TLS 1.3 kabul etmeli. TLS 1.3, RFC 8446 belgesinin tanımladığı güncel sürümdür ve zayıf şifre takımlarını tamamen dışarıda bırakır.

Kendi kontrol listemde şu maddeler var:

• TLS 1.0 ve 1.1 kapalı, TLS 1.2 ve 1.3 açık.
• Tüm HTTP adresleri tek adımda 301 ile HTTPS'e gidiyor.
• HSTS başlığı etkin, böylece tarayıcı siteye bir daha şifresiz bağlanmıyor.
• Sayfada karışık içerik (HTTP ile çağrılan görsel veya betik) yok.
• Sertifika yenilemesi otomatik ve bitiş tarihi için uyarı kurulu.

Yönlendirme zincirlerini yönlendirme denetleyici ile hızlıca görebilirsiniz. Sunucu ayarları için ise Mozilla'nın SSL yapılandırma üreticisi Apache ve Nginx için hazır, güncel şablonlar veriyor. Ben yeni sunucu kurarken genellikle "intermediate" profilinden başlıyorum.

Parolaları veritabanında nasıl saklamalısınız?

Parolaları asla düz metin ya da geri çözülebilir biçimde saklamamalısınız. Doğru yöntem, parolayı yavaş ve tek yönlü bir özetleme (hash) algoritmasından geçirip yalnızca sonucu saklamaktır. Giriş anında kullanıcının yazdığı parolayı aynı işlemden geçirir ve sonuçları karşılaştırırsınız.

Burada "yavaş" kelimesi kritik. MD5 veya SHA-1 gibi hızlı özetler, saldırganın saniyede milyarlarca tahmin denemesine izin verir. Bu nedenle OWASP parola saklama rehberi Argon2id, scrypt, bcrypt ve PBKDF2 gibi bilerek yavaşlatılmış algoritmaları öneriyor. Rehberin önerdiği ilk tercih Argon2id; asgari ayar olarak 19 MiB bellek, 2 tekrar ve 1 paralellik veriyor.

Ayrıca her parolaya benzersiz bir tuz (salt) eklemelisiniz. Modern kütüphaneler bunu kendiliğinden yapar. Örneğin PHP'de password_hash fonksiyonu tuzu otomatik üretir ve özetin içine gömer. Yani sizin ayrı bir tuz sütunu tutmanız gerekmez; yeter ki kendi özetleme yönteminizi icat etmeye kalkmayın.

Hash ile şifreleme arasındaki fark nedir?

İnsanlar bu iki kavramı sık karıştırıyor, oysa amaçları farklı. Hash tek yönlüdür: sonuçtan orijinal veriye geri dönemezsiniz. Şifreleme ise iki yönlüdür: doğru anahtara sahip olan, veriyi yeniden okunur hâle getirebilir.

Kısacası, veri güvenliği planında ileride okumanız gerekmeyen bilgiyi hash ile, okumanız gereken bilgiyi şifreleme ile korursunuz. Parola ilk gruba, müşterinin telefon numarası ikinci gruba girer.

Bir de kodlama ile karıştırmayın. Base64 gibi kodlamalar veriyi yalnızca başka bir biçimde yazar; anahtar gerektirmez ve herkes geri çevirebilir. Dolayısıyla veritabanında Base64 ile saklanan bir telefon numarası, açık metinle aynı derecede korumasızdır. Denetimlerde bu hatayı hâlâ görüyorum.

Veritabanındaki hassas alanları nasıl şifrelersiniz?

İki katman düşünmelisiniz. Birincisi disk düzeyinde şifrelemedir: sunucu diski ya da veritabanı dosyaları şifreli durur. Bu katman, fiziksel diskin çalınması gibi senaryolarda işe yarar. Ancak veritabanına uygulama üzerinden erişen bir saldırgana karşı koruma sağlamaz, çünkü veri çalışma anında zaten çözülmüş hâldedir.

İkinci katman uygulama düzeyinde alan şifrelemesidir. Burada kimlik numarası, banka bilgisi ya da özel belge gibi en hassas alanları, veritabanına yazmadan önce uygulama içinde şifrelersiniz. Böylece biri veritabanı dökümünü ele geçirse bile bu alanlar okunamaz.

Benim pratik önerim şudur: önce hangi veriyi gerçekten tuttuğunuzu listeleyin. Çoğu kurumsal sitede alan şifrelemesi gerektiren veri çok azdır. Hatta en iyi koruma, gereksiz veriyi hiç toplamamaktır. İhtiyaç duymadığınız kimlik numarasını formdan kaldırmak, onu şifrelemekten her zaman daha güvenlidir.

Algoritma seçiminde de sade kalın. Uygulama düzeyinde şifreleme için AES-256-GCM gibi hem gizliliği hem de bütünlüğü sağlayan modlar yaygın ve güvenilir bir tercihtir. Ancak algoritmayı kendiniz uygulamaya çalışmayın; dilinizin olgun kriptografi kütüphanesini kullanın. Örneğin PHP tarafında sodium eklentisi, Node.js tarafında yerleşik crypto modülü bu iş için yeterlidir. Kısacası, iyi test edilmiş hazır araç, kendi yazdığınız akıllıca görünen çözümden her zaman daha güvenlidir.

Şifreleme anahtarlarını nerede tutmalısınız?

Şifrelemenin gücü anahtarın güvenliği kadardır. Anahtarı veritabanının yanındaki bir tabloda ya da kaynak kodun içinde tutarsanız, saldırgan ikisini birlikte alır ve şifreleme anlamsızlaşır. Sahada en sık gördüğüm hata budur.

Daha sağlıklı seçenekler şunlardır:

1. Anahtarı web kök dizininin dışında, yalnızca uygulama kullanıcısının okuyabildiği bir ortam değişkeninde ya da yapılandırma dosyasında tutmak.
2. Bulut sağlayıcının anahtar yönetim hizmetini (KMS) kullanmak.
3. Anahtarı sürüm kontrol sistemine (Git) asla göndermemek.
4. Anahtarı belirli aralıklarla döndürmek ve eski veriyi yeni anahtarla yeniden şifrelemek.

Ayrıca API anahtarları ve veritabanı şifreleri de aynı disiplini ister. Örneğin bir ödeme sağlayıcısının gizli anahtarı yanlışlıkla herkese açık bir depoya gönderilirse, otomatik tarayıcılar onu çok kısa sürede bulabilir. Bu yüzden depoda gizli bilgi tarayan araçları devreye almanızı öneririm.

Form verilerini güvenli şekilde nasıl toplarsınız?

Form, kurumsal sitenin en çok veri toplayan noktasıdır; dolayısıyla en çok da saldırı alan yerdir. İlk kural, her girdiyi sunucu tarafında doğrulamaktır. Tarayıcıdaki doğrulama kullanıcı deneyimi içindir, güvenlik için değil; çünkü saldırgan tarayıcıyı hiç kullanmadan doğrudan istek gönderebilir.

İkinci kural, veritabanı sorgularında hazırlanmış ifadeler (prepared statements) kullanmaktır. Böylece kullanıcının yazdığı metin hiçbir zaman sorgunun parçası olarak çalışmaz ve SQL enjeksiyonu kapısı kapanır. Üçüncü kural, form gönderimlerine CSRF koruması ve makul bir hız sınırı eklemektir.

Form verisini e-postayla iletiyorsanız dikkatli olun. Hassas içeriği düz e-posta gövdesine koymak yerine, bildirimde yalnızca "yeni talep geldi" demek ve ayrıntıyı giriş gerektiren panelde göstermek daha güvenlidir. Form tasarımının dönüşüm tarafını randevu, teklif ve demo formu tasarımı yazısında ayrıca anlattım.

OWASP Top 10 nedir ve kurumsal site için ne anlatır?

OWASP Top 10, web uygulamalarındaki en kritik güvenlik risklerini listeleyen ve dünya genelinde referans kabul edilen bir belgedir. Güncel sürüm olan OWASP Top 10:2025 listesinin ilk sırasında bozuk erişim kontrolü, ikinci sırasında hatalı güvenlik yapılandırması yer alıyor.

Listenin tamamı şöyle:

1. A01: Bozuk erişim kontrolü.
2. A02: Hatalı güvenlik yapılandırması.
3. A03: Yazılım tedarik zinciri hataları.
4. A04: Kriptografik hatalar.
5. A05: Enjeksiyon.
6. A06: Güvensiz tasarım.
7. A07: Kimlik doğrulama hataları.
8. A08: Yazılım veya veri bütünlüğü hataları.
9. A09: Güvenlik kaydı ve uyarı hataları.
10. A10: İstisnai durumların yanlış ele alınması.

Kurumsal site sahibi için veri güvenliği dersi nettir: risklerin çoğu egzotik saldırılardan değil, yetki ve yapılandırma hatalarından doğuyor. Yani iyi bir güvenlik programı pahalı ürünlerle değil, düzenli kontrol ve disiplinle başlar.

Erişim yetkilerini nasıl kurgulamalısınız?

Temel ilke en az yetkidir: her kişi ve her sistem, işini yapmaya yetecek kadar erişime sahip olmalı, fazlasına değil. Blog yazarı eklenti kuramamalı; muhasebe ekibi tema dosyalarını görmemeli; uygulamanın veritabanı kullanıcısı tablo silme yetkisine sahip olmamalı.

Sahada uyguladığım adımlar şunlar:

• Her kişiye ayrı hesap açın; ortak "admin" hesabı kullanmayın.
• Rolleri tanımlayın ve yetkiyi kişiye değil role verin.
• İşten ayrılan kişinin hesabını aynı gün kapatın.
• Üç ayda bir tüm hesapları gözden geçirin.
• Sunucu erişiminde parola yerine SSH anahtarı kullanın.

Ayrıca erişim kontrolünü yalnızca menüde gizleyerek yapmayın. Bir sayfanın bağlantısını arayüzden kaldırmak, o adrese doğrudan gidildiğinde yetki kontrolü yapıldığı anlamına gelmez. OWASP listesinin birinci sırası tam olarak bu tür hatalardan oluşuyor.

Yönetim paneli için iki adımlı doğrulama şart mı?

Evet, bugün yönetim paneli için iki adımlı doğrulamayı (2FA) zorunlu görüyorum. Parolalar sızıntılarda ele geçebilir, başka sitelerde tekrar kullanılmış olabilir ya da oltalama ile çalınabilir. İkinci adım, parola bilinse bile girişi engeller.

Tercihim zamana dayalı tek kullanımlık kod (TOTP) üreten uygulamalardır. SMS ile gelen kod hiç yoktan iyidir; ancak SIM kartı ele geçirme saldırılarına açıktır. Donanım anahtarı ise en güçlü seçenektir ve kritik hesaplar için değerlendirilebilir.

Panele ek koruma olarak şunları da öneririm: giriş denemelerine hız sınırı koymak, art arda hatalı denemede geçici kilit uygulamak ve varsayılan giriş adresini tek başına güvenlik önlemi saymamak. Adresi değiştirmek botları biraz azaltır; yine de gerçek koruma 2FA ve güçlü paroladan gelir. Güçlü ve rastgele parola üretmek için şifre oluşturucu aracını kullanabilirsiniz.

Yedekleme stratejisi nasıl olmalı?

Yedekleme, veri güvenliği zincirinde diğer tüm önlemler başarısız olduğunda sizi kurtaran son hattır. Fidye yazılımı, hatalı güncelleme ya da yanlışlıkla silinen bir tablo; hepsinin çaresi temiz ve güncel bir yedektir. Ben burada yaygın kabul gören 3-2-1 kuralını temel alıyorum.

3-2-1 kuralı şöyle işler: verinin en az üç kopyası olur, bu kopyalar iki farklı ortamda durur ve en az biri sunucudan farklı bir konumda (off-site) bekler. Böylece sunucunun tamamen kaybı bile veriyi götürmez.

Yedeği de veri gibi korumalısınız. Şifrelenmemiş bir veritabanı yedeğini herkesin erişebildiği bir klasörde bırakmak, siteyi korumak için harcanan tüm emeği boşa çıkarır. Örneğin web kök dizininde unutulmuş "yedek.zip" ya da ".sql" dosyaları, otomatik tarayıcıların ilk baktığı yerlerdendir. Bu nedenle yedekleri web dizininin dışında ve şifreli tutun, eski kopyaları da planlı şekilde silin.

Yedeğin gerçekten çalıştığını nasıl test edersiniz?

Hiç denemediğiniz bir yedek, yedek değil umuttur. Sahada en acı verici anlardan biri, kriz anında yedeğin bozuk, eksik ya da aylar önce durmuş olduğunu fark etmektir. Bu yüzden geri yükleme testini takvime bağlarım.

Pratik yöntem şudur: yedeği ayrı bir test ortamına geri yükleyin, siteyi açın ve birkaç kritik işlemi deneyin. Form çalışıyor mu, panele girebiliyor musunuz, son eklenen içerik orada mı? Ayrıca yedek dosyasının boyutunu ve tarihini izleyen basit bir uyarı kurun; boyut birden küçülürse bir şeyler ters gidiyor demektir.

İki ölçüyü de önceden belirleyin: en fazla ne kadar veri kaybını kabul edebilirsiniz ve site en fazla ne kadar süre kapalı kalabilir? Günlük yedek alıyorsanız en kötü durumda bir günlük veri kaybedersiniz. Teklif formu yoğun çalışan bir site için bu fazla olabilir; dolayısıyla veritabanı yedeğini daha sık almak mantıklı hâle gelir.

Güncellemeler ve eklentiler neden en zayıf halka?

Kurumsal sitelerin büyük kısmı bir içerik yönetim sistemi, tema ve onlarca eklenti üzerine kuruludur. Bu parçaların her biri başka bir ekibin yazdığı koddur. OWASP'ın yeni listesinde yazılım tedarik zinciri hatalarının üçüncü sıraya girmesi de bu gerçeği yansıtıyor.

Benim kurallarım basit. Kullanılmayan eklentiyi devre dışı bırakmakla yetinmeyin, silin. Uzun süredir güncelleme almayan eklentinin alternatifini arayın. Güvenlik güncellemelerini bekletmeyin; ancak büyük sürüm geçişlerini önce test ortamında deneyin. Ayrıca sunucudaki PHP gibi çalışma ortamı sürümlerinin destek süresini takip edin.

Güncelliğin arama tarafına etkisini web sitesini güncel tutmanın SEO etkisi yazısında ele aldım. Güvenlik açısından ise mesele daha keskin: yamalanmamış bilinen bir açık, otomatik saldırıların doğrudan hedefidir.

Güvenlik başlıkları ve sunucu ayarları neleri engeller?

HTTP güvenlik başlıkları, tarayıcıya sitenizin nasıl davranması gerektiğini söyleyen kısa talimatlardır ve birçok saldırıyı ucuza engeller. Hatalı güvenlik yapılandırmasının listede ikinci sıraya çıkması, bu alanın ne kadar ihmal edildiğini gösteriyor.

Öncelik verdiğim başlıklar şunlar:

• Strict-Transport-Security: tarayıcıyı yalnızca HTTPS kullanmaya zorlar.
• Content-Security-Policy: hangi kaynaklardan betik yüklenebileceğini sınırlar, XSS riskini düşürür.
• X-Content-Type-Options: tarayıcının dosya türünü tahmin etmesini engeller.
• Referrer-Policy: başka sitelere hangi adres bilgisinin gideceğini sınırlar.
• Frame koruması: sitenin başka sayfalarda gizlice çerçeve içinde açılmasını önler.

Sunucu tarafında ise dizin listelemeyi kapatın, hata mesajlarında sürüm ve dosya yolu göstermeyin ve kullanılmayan servisleri durdurun. Ayrıca DNS kayıtlarınızı DNS sorgulama aracıyla kontrol edip unutulmuş alt alan adlarını temizleyin.

Kayıt tutma ve izleme olmadan saldırıyı fark edebilir misiniz?

Çoğu zaman hayır. Kayıt tutmayan bir site, saldırıya uğradığını ancak sonuçlar ortaya çıktığında anlar: arama sonuçlarında spam sayfalar, müşteriden gelen şüpheli e-posta şikâyeti ya da hosting firmasının kapatma bildirimi. OWASP listesindeki kayıt ve uyarı hataları maddesi tam da bunu anlatıyor.

Asgari izleme düzeni şöyle olmalı: sistem başarılı ve başarısız panel girişlerini, yetki değişikliklerini ve dosya değişikliklerini kaydeder; kritik olaylarda da birine bildirim gönderir. Kayıtları da sunucunun dışında saklamak gerekir; aksi hâlde siteyi ele geçiren kişi izlerini silebilir.

Arama tarafında ise Google Search Console güvenlik sorunları raporu, Google'ın sitenizde zararlı içerik tespit etmesi hâlinde size haber verir. Bu rapor tek başına izleme sistemi değildir; ancak ücretsiz ve değerli bir erken uyarı katmanıdır.

Barındırma ve e-posta altyapısı güvenliği nasıl etkiler?

Sitenin kodu ne kadar temiz olursa olsun, üzerinde çalıştığı sunucu zayıfsa risk devam eder. Paylaşımlı barındırmada aynı sunucudaki başka bir sitenin açığı, yapılandırmaya göre sizi de etkileyebilir. Bu nedenle kurumsal projelerde izole hesap yapısı ve düzenli işletim sistemi güncellemesi sunan altyapıyı tercih ederim.

Barındırma seçerken sorduğum sorular şunlar: sunucu yazılımları kim tarafından ve ne sıklıkla güncelleniyor, yedekler nerede duruyor, sitelerin birbirinden izolasyonu nasıl sağlanıyor ve bir olay anında kime ulaşılıyor?

E-posta da aynı zincirin parçası. Alan adınızla gönderilen sahte e-postalar, müşterilerinizi oltalama saldırısına açık bırakır. SPF, DKIM ve DMARC kayıtları bu riski ciddi ölçüde azaltır. Konunun ayrıntısını kurumsal e-posta altyapısı yazısında anlattım.

Site taşıma sırasında veri güvenliği nasıl sağlanır?

Site yenileme, güvenlik açısından en riskli dönemlerden biridir. Eski ve yeni sistem bir süre yan yana çalışır, ekip veritabanı dökümlerini farklı ortamlara taşır ve geçici erişimler açar. Hepsi unutulmaya çok müsait.

Benim taşıma sırasında uyguladığım kurallar şunlar: veritabanı dökümünü şifreli kanalla aktarırım, işi biten dökümü silerim, test ortamını parolayla korur ve arama motorlarına kapatırım, geçici hesapları taşıma biter bitmez kapatırım. Ayrıca test ortamında gerçek müşteri verisi yerine anonimleştirilmiş veri kullanmayı tercih ederim.

Yönlendirme ve sıralama korumasının teknik tarafı için site taşıma kontrol listesi yazısına bakabilirsiniz. Güvenlik tarafında ise altın kural şudur: taşıma bittiğinde eski sunucudaki veriyi de planlı şekilde temizleyin.

Üçüncü taraf betikler veri güvenliğini nasıl etkiler?

Kurumsal sitelerde sayfaya eklenen her dış betik, sizin sunucunuzda olmayan ama sizin ziyaretçinizin tarayıcısında çalışan koddur. Analitik etiketleri, canlı destek balonları, harita gömmeleri ve reklam pikselleri bu gruba girer. Ancak bu betiklerden biri ele geçerse, form alanlarına yazılan bilgiyi okuyabilir.

Bu nedenle veri güvenliği açısından betik envanterini ayrı bir iş kalemi olarak görüyorum. Hangi betik hangi sayfada çalışıyor, kim ekledi, hâlâ gerekli mi? Kullanılmayan etiketi kaldırmak hem riski hem de sayfa yükünü azaltır.

Ayrıca Content-Security-Policy ile yalnızca izin verdiğiniz alan adlarından betik yüklenmesine izin verebilirsiniz. Sabit sürümlü dış dosyalarda alt kaynak bütünlüğü (SRI) özelliğiyle dosyanın değişmediğini de doğrulayabilirsiniz. Üstelik ödeme ve form sayfalarında dış betik sayısını en aza indirmek, bu sayfaları hem daha güvenli hem de daha hızlı yapar.

Yapay zeka tabanlı sohbet eklentilerinde de aynı soruyu sorun: ziyaretçinin yazdığı metin nereye gidiyor ve ne kadar saklanıyor? Sağlayıcının belgelerini okumadan bu tür bir aracı iletişim sayfasına koymamanızı öneririm.

Veri güvenliği bütçesi ve sorumluluğu kimde olmalı?

Sahada en sık gördüğüm boşluk teknik değil, sahipliktir. Site ajans tarafından kurulduysa ajans ayrılınca kimse sorumluluk almıyor; bilgi işlem ekibi ise web sitesini pazarlamanın işi sayıyor. Sonuçta güncellemeler aylarca bekliyor.

Benim önerim, veri güvenliği için tek bir sorumlu kişi belirlemenizdir. Bu kişinin her şeyi kendisi yapması gerekmez; ancak güncellemelerin, yedeklerin ve hesap gözden geçirmelerinin takvime bağlanmasından o sorumlu olur. Böylece iş, "birinin yaptığını sanıyordum" boşluğuna düşmez.

Bütçe tarafında ise tek seferlik kurulum ile süregelen bakımı ayırmanız gerekir. Sertifika, yedek alanı ve izleme gibi kalemler düzenli maliyet doğurur. Yine de bu maliyetler, ele geçirilmiş bir siteyi temizlemenin, kaybolan güveni geri kazanmanın ve arama sonuçlarındaki hasarı onarmanın yanında genellikle küçük kalır. Bu karşılaştırma saha tecrübesine dayanır, her durum için garanti değildir.

Hukuki uyum ile teknik güvenlik arasındaki çizgi nerede?

KVKK ve GDPR gibi düzenlemeler, kişisel veriyi hangi amaçla toplayacağınızı, kimi bilgilendireceğinizi ve ne kadar süre saklayacağınızı belirler. Bu yazıda anlattığım konular ise o kuralların teknik karşılığıdır: şifreleme, erişim kontrolü, yedek ve kayıt.

İki taraf birbirini tamamlar ama birbirinin yerine geçmez. Aydınlatma metni eksiksiz olsa bile şifresiz bir veritabanı yedeği açıkta duruyorsa sorun çözülmüş sayılmaz. Tersi de geçerli: teknik olarak kusursuz bir altyapı, hukuki yükümlülükleri tek başına karşılamaz.

Bu nedenle hukuki metinleri bir hukukçuyla, teknik uygulamayı ise yazılım ve altyapı ekibiyle birlikte ele almanızı öneririm. Benim sorumluluk aldığım kısım teknik katmandır; hukuki yorum yapmıyorum.

Veri güvenliği için hangi kontrol listesiyle başlamalısınız?

Her şeyi aynı anda yapmak zorunda değilsiniz. Önerdiğim sıra, en az emekle en büyük riski kapatan adımlardan başlar. Bu sıra saha tecrübesine dayanır; her site için garanti bir reçete değildir.

1. Tüm yazılımların, eklentilerin ve sunucu bileşenlerinin envanterini çıkarın ve güncelleyin.
2. Yönetim paneli hesaplarını gözden geçirin, ortak hesapları kapatın ve 2FA'yı zorunlu yapın.
3. HTTPS, HSTS ve TLS sürüm ayarlarını doğrulayın.
4. Otomatik, şifreli ve sunucu dışında duran yedeği kurun ve bir kez geri yükleyerek test edin.
5. Formlarda sunucu tarafı doğrulama, hazırlanmış ifadeler ve hız sınırı olduğunu kontrol edin.
6. Parola saklama yöntemini ve şifreleme anahtarlarının yerini denetleyin.
7. Güvenlik başlıklarını ekleyin, kayıt ve uyarı düzenini kurun.

Yeni bir site kuruyorsanız bu maddeleri baştan mimariye yerleştirmek çok daha ucuzdur. Web tasarım projelerimde güvenlik kontrollerini teslim listesinin parçası olarak ele alıyorum. Teknik SEO ile ortak noktaları merak ediyorsanız teknik SEO ipuçları yazısı iyi bir başlangıç olur; arama görünürlüğünün tamamı için de SEO danışmanlığı sayfama göz atabilirsiniz.