Bir Güncellemeyle Başlayan Telaş: Giriş
Hiç beklenmedik bir anda, durup dururken, paneldeki o ufak uyarı ışığı yanar ya… Geçen haftalardan birinde bir müşterim aradı ve şöyle dedi: “Sitede çerez bildirimini hallettik ama verilerin nerede tutulduğunu soruyorlar, logları ne kadar saklıyoruz bilmiyorum, silme isteği gelirse ne yapacağız?” O an fark ettim; teknik olarak site yağ gibi akıyor ama KVKK ve GDPR uyumlu hosting tarafında birkaç taş yerli yerinde değil. O gün elimdeki kahve soğudu, çünkü bu işler sadece bir ayar kutucuğunu işaretlemekle bitmiyor.
Sanki bir ev taşıyormuşsunuz da kolilerin üstüne ne yazdığınızı bilmiyorsunuz gibi bir his. Verinin hangi odada olduğundan, anahtarların kimde kaldığına kadar her şey önemli. Bu yazıda seninle, verinin nerede yaşadığını anlamaktan, logların nasıl düzenli saklanacağına; silme ve yedek süreçlerini insana yakışır şekilde yönetmekten, pratik bir yol haritası çıkarmaya kadar adım adım gideceğiz. Kısaca, “Siten çalışıyor, peki haklar ve sorumluluklar da çalışıyor mu?” sorusuna birlikte cevap arayacağız.
Hazırsan, teknik terimlerin arasına kaybolmadan, günlük hayattan benzetmelerle ilerleyelim. Bir dükkân sahibinin, kapıyı açmadan önce ışıkları kontrol etmesi gibi; biz de veriyi nerede tuttuğumuza, neyi ne kadar süre sakladığımıza ve biri kapıyı kapatmamızı istediğinde gerçekten kapatabildiğimize bakacağız.
KVKK ve GDPR Uyumunu Hosting Dünyasına Çevirmek
Bir adım geri çekilip konuya geniş açıdan bakalım. KVKK ve GDPR aslında şunu söylüyor: “Kişisel veriler emanet, ona iyi bak.” Hosting tarafında bu emanet bazen bir veritabanı tablosu, bazen bir erişim logu, bazen de e-posta sunucusunda duran bir gönderim kaydı oluyor. Kimin ne yaptığını, ne kadar tuttuğunu ve ne zaman sildiğini bilmek bu işin kalbi. Eğer bir işletme sahibiysen çoğu zaman “veri sorumlusu” sensin, hosting sağlayıcın da büyük ihtimalle “veri işleyen” rolünde. Bu ayrımı büyütmeden, günlük dille şöyle düşün: dükkanın sahibi sensin, alarm sistemi ise üçüncü taraf.
Burada seni yoracak şey, farklı parçalardan oluşan bir yapbozu birleştirmek. Site dosyaları bir yerde, veritabanı başka bir yerde, CDN üzerinden görseller dünyayı dolaşıyor. Uyum süreci, bu parçaların hepsine “neredesin, neden buradasın ve ne kadar kalacaksın” diye sormaktan geçiyor. Bunu yaparken bir veri işleme sözleşmesi ile kim ne yapar, nerede yapar, ne kadar saklar, nasıl siler gibi başlıkları yazıya dökmek iyi geliyor. Bir de marka sözünden daha güvenilir şey loglardır; neyi ne zaman yaptığını hatırlatır ve tutarlılık sağlar.
Mesela şöyle düşün: Siten bir kafe olsun. Veriler ise müşteri siparişleri, güvenlik kamerası görüntüleri ve kasadaki fişler. Hepsi kafenin içinde, bazıları ise dışarıya kurye olarak çıkıyor. Sipariş fişini sonsuza kadar saklamazsın, kamera görüntüsünü öylece açıkta bırakmazsın, müşterinin “benim bilgilerimi kaldırır mısın?” talebini de ciddiye alırsın. Hosting tarafında da aynı nezaket ve düzen gerekiyor.
Veri Yerelleştirme: Verinin Ev Adresi
“Veriyi nerede tutuyorsun?” sorusu genelde basit görünür ama arkasında koca bir harita var. Sunucun Türkiye’deyse işin bir kısmı kolay; yerel mevzuat ile senkron kalmak daha rahat. Avrupa hedefliyorsan, veriyi Avrupa Birliği sınırlarında tutmak akıllıca. Bazen de küresel performans için içerik dağıtım ağı kullanırsın; işte burada, görsellerin ve bazı statik dosyaların farklı ülkelerde kısa süreli kopyalarının oluşabileceğini bilmek iyi olur. Önemli olan, bu akışı bilmek ve yazılı hale getirmek.
Veri yerelleştirme sadece “sunucu konumu” değil. Yedeklerin nerede durduğu, felaket kurtarma için yansıttığın kopyaların hangi bölgede saklandığı ve yönetim araçlarının kullandığı bulut depolarının nerede çalıştığı da resmin parçası. Bir müşterim, performansı artırmak için veritabanı yedeğini farklı bir sağlayıcıda tutuyordu; fark etmeden veriyi AB dışına çıkarmış. Bu yüzden, verinin haritasını bir defa çıkarmak ve güncel tutmak çok önemli. Nerede başlıyor, nerede dolaşıyor, nerede uyuyor, hepsini yaz.
“Peki ya içerik dağıtım ağı?” diye sorarsan, bu araçlar doğru ayarlandığında sorun değil. Kişisel veri içeren dosyaları CDN üzerinden servis etmek yerine uygulama seviyesinde kontrol etmek, herkese açık statik varlıkları ise gönül rahatlığıyla dağıtmak mümkün. Kopyaların ömrünü kısa tutmak, bölge seçimi yapmak ve kontrol panellerindeki bölgesel ayarları dikkatle işaretlemek yeterli. Daha teknik güvenlik kenarlarını güçlendirmek için istersen şu rehbere de göz at: HTTP güvenlik başlıklarını ne zaman, nasıl uygulamalısın?
Loglama: Kanıt, Tanıklık ve Mahremiyetin İnce Dengesi
Loglar, sistemin günlükleri. Bir yandan güvenliği kanıtlar, sorun olduğunda yol gösterir; diğer yandan da kişisel veri barındırabilir. IP adresi, kullanıcı ajanı, oturum kimlikleri, hatta başarısız giriş denemeleri… Hepsi birer ipucu. İpucunun gereğinden fazla tutulması ise mahremiyet için risk. Bu yüzden loglama iki ayaklı bir yürüyüş gibi; güvenlik için yeterince, mahremiyet için gerektiği kadar.
Ben çoğu projede şu akışı seviyorum: Uygulama logları, erişim logları ve sunucu güvenlik logları ayrı dosyalarda, döngüsel olarak döndürülür. Belirli bir süre boyunca ayrıntılı, sonrasında özet formda tutulur. Hassas kimlikler maskeleme ile görünmez hale getirilir, yetkisi olmayan kimse göremez. Bir erişim ihlali şüphesi olduğunda geriye bakabileceğin kadar, gereksiz kalabalığa dönüşmeyecek kadar süre saklarsın. Ne kadar süre dersen, işin doğası belirler; destek taleplerinin ortalama süresi, yasal yükümlülükler ve güvenlik ihtiyaçları bir arada düşünülür.
“Logu çok tutayım, ilerde lazım olur” demek kulağa mantıklı gelse de aslında başı derde sokabilir. Gereksiz yığın, hem aranması zor bir tarlaya dönüşür hem de veri ihlali olursa daha çok bilgi açığa çıkar. Logları merkezileştiriyorsan erişimi sıkı tut, kimin neyi ne zaman gördüğü belli olsun. Harici depoya taşıyorsan, bulunduğu bölge ve şifreleme ayarlarını iki kere kontrol et. İstersen güvenlik tarafını daha derin güçlendirmek için şuradaki pratik yaklaşım işine yarar: VPS sunucu güvenliği için pratik ve ölçeklenebilir öneriler.
Silme Politikaları: Bir Bilgiyi Gerçekten Nasıl Uğurlarsın?
Bir gün posta kutuna şu mesaj düşebilir: “Beni sisteminizden siler misiniz?” İşte burada silme bir butona basmak değil, bir yolculuğu yönetmek. Canlı veritabanından kaydı kaldırırsın, ilişkili dosyaları temizlersin, loglarda yer alıyorsa gerekli maskeleme veya kısmi silmeyi yaparsın. Sonra asıl sık sorulan bölüme gelirsin: “Peki ya yedekler?” İşin kilidi burada. Yedeklerin, olağan döngüsüyle üzerine yazılarak temizlendiği bir düzen kurmak şart.
Ben yedek tarafında “silme isteği geldiğinde geçmişe büyüteçle dalmayalım” diye plan yapmayı seviyorum. Yani yasal ve operasyonel süre kadar yedek tutulur, bu sürenin sonunda otomatik döngü onları zaten temizler. Böylece silme talebi geldiğinde canlı sistemde hemen gereğini yapar, yedeklerin de doğal yaşam döngüsünü bozmadan süreleri dolunca uçup gitmesine izin verirsin. Kritik nokta şu: Bu plan yazılı olmalı, ekipçe bilinmeli ve test edilmeli. Bir silme senaryosunu prova etmeden kimse sahneye çıkmamalı.
Elbette, felaket kurtarma senaryoları için ekstra kopya tutuyorsan, aynı politikanın orada da çalıştığından emin ol. Yedekleri farklı bölgede tutuyorsan konumunu kayda geçir ve sürelerle birlikte raporla. Geri yükleme testi yaptığında, silinmiş bir kişinin verisinin “kazara” geri gelmediğini kontrol et. Bu çabanın ödülü çok büyük; hem düzenin oturur hem de bir denetimde “biz böyle yapıyoruz” dediğinde elindeki kanıtlarla içini rahat tutarsın. Yedek dünyasını planlamak için şuradaki yol arkadaşım hep işe yarıyor: 3-2-1 yedekleme stratejisini pratik şekilde kurma rehberi.
Güvenlik, Şeffaflık ve Anlaşılır Notlar
Uyumun bel kemiği üç kelime: güvenlik, şeffaflık ve anlaşılır olmak. Güvenlik dediğimiz; veriyi yolda ve depoda şifrelemek, girişleri korumak, panelleri iki aşamalı doğrulamayla saklamak. Şeffaflık ise “ne yapıyoruz”u insan dilinde anlatmak. Gizlilik politikasında veri yerini, saklama sürelerini ve silme akışını kısa ve net cümlelerle yazmak kadar rahatlatıcı az şey var. Müşteriye “verin şurada, şu kadar kalır, isterseniz şöyle sileriz” diyebilmek, güvenin en samimi halidir.
Teknik cephede minik ama etkili dokunuşlar da çok şey değiştirir. Sunucuya en güncel protokollerle bağlanmak, veritabanı erişimlerini kısıtlı IP’lerle sınırlamak, panellerde yaygın açıkları kapatan güvenlik başlıklarını etkinleştirmek bunlardan bazıları. Akışın temiz olduğundan emin olmak için istersen şu rehber de güzel bir tamamlayıcı dursun: DDoS saldırılarına karşı pratik korunma yöntemleri. Ayrıca e-posta tarafında da gönderim kimliğini sağlam tutmak için SPF, DKIM, DMARC ve rDNS ayarlarını temizlemek uyum tabloğunu tamamlar.
Şeffaflık tarafında ise bir önerim var: Kendine küçük bir “veri haritası” ve “saklama planı” dökümanı hazırla. Dosyalar nerede, loglar nerede, yedekler nerede; her biri için ne kadar, neden tutuluyor. Her değişiklikte güncelle. Kulağa sıkıcı geliyor ama üç ay sonra kapını çalan bir denetimde veya bir müşteri sorusunda bu döküman, en sıcak kahve kadar iyi geliyor.
Gündelik Bir Senaryo: Butiğin E-Ticareti
Diyelim ki küçük bir butiğin var ve e-ticarete adım attın. Sunucun Türkiye’de, siteye Avrupa’dan da ziyaretçiler geliyor. İlk iş, verinin konumunu netleştiriyorsun; canlı veritabanı İstanbul’da, statik içerikler bir CDN ile dağıtılıyor ama kişisel veri içeren dosyaları CDN’e vermiyorsun. Yedekler ise Ankara’daki bir depoda şifreli halde. Bu planı not ediyorsun. Uygulama loglarında IP ve kullanıcı ajanını tutuyorsun ama oturum kimliklerini maskelemeyi tercih ediyorsun. Bir olay olduğunda geriye bakabileceğin kadar süre saklıyorsun, fazlasını değil.
Gizlilik politikasında herkesin anlayacağı cümlelerle yazıyorsun: “Sipariş verisi Türkiye’de saklanır, kargo bilgileri zorunlu süre kadar tutulur, destek bittiğinde gereksiz kayıtlar silinir.” Bir müşteri “sil” dediğinde önce canlıdan kaldırıyorsun, sonra yedeklerin doğal döngüsünün bu kaydı belirli bir süre sonra tamamen sileceğini ekliyorsun. E-posta tarafını sağlamlaştırmak için kimlik doğrulamalarını düzenliyor, yönetici hesaplarına iki aşamalı doğrulama ekliyorsun. İşte bu kadar. Parlak laflar yok, anlaşılır ve uygulanabilir bir düzen var.
Eğer altyapıyı daha performanslı bir zemine taşımak istersen, bu taşımayı da dikkatle yapmak iyi olur. Taşıma sırasında verinin nereden nereye gittiğini, geçici kopyaların nerede oluştuğunu, DNS değişikliklerinin etkisini planlıyorsun. Bu süreçte yol arkadaşına ihtiyaç duyarsan, şuradaki sakin rehber işini kolaylaştırır: Paylaşımlı hosting’ten VPS’e geçiş için sıcak bir kontrol listesi.
Sözleşmeler, Notlar ve Ufak Dayanaklar
Şimdi işin mutfağındaki evraklara gelelim. Hosting sağlayıcınla aranda bir veri işleme sözleşmesi olması çok rahatlatır; verinin nerede, nasıl işlendiğini yazıya döker. İçerideki ekip için de kısa bir “gizlilik ve güvenlik notu” hazırlamak büyük fark yaratır. Kim hangi loga erişebilir, ne kadar süre saklarız, silme talebi geldiğinde kim ne yapar; hepsi belli olmalı. Bunu bir kez yazarsın, sonra her büyük değişiklikte güncellersin. Zamanla, bu notlar bir projeyi taşımaktan çok daha fazlasını yapar; kültür oluşturur.
Bazı kaynaklar elinin altında dursun istersen, resmi sayfaları işaretlemek iyi gelir. KVKK hakkında bilgilere resmi kurumun internet sitesinden ulaşabilirsin. Avrupa tarafında genel çerçeveyi anlamak için GDPR hakkında net bir özet işini görür. Spesifik aktarım senaryolarını anlamaya çalışıyorsan, Avrupa Komisyonu sayfalarındaki standart sözleşme metinlerine dair bilgilere göz atmak da faydalı olur. Hepsini tek seferde ezberlemeye çalışma; ihtiyacın oldukça dönüp bakacağın küçük yer imleri gibi düşün.
Teknik yığın büyüdükçe, küçük güvenlik başlıkları büyük sonuçlar doğuruyor. HTTP katmanındaki ince ayarlar, DDoS önlemleri, e-posta kimlik doğrulamaları… Hepsi birer tuğla. Tuğlaları sağlam dizdiğinde duvar kendi kendini taşıyor. Artık bir sorun çıktığında “bunu neden yaşadık” demek yerine “bunu nasıl öğrendiğimize sevindim” diyebiliyorsun. İşin güzelliği burada.
Kapanış: Düzen Küçük Adımlarla Kurulur
Bugün birlikte şunu yaptık: Verinin ev adresini netleştirdik, logların ne kadar ve nasıl tutulacağını konuştuk, silme isteği geldiğinde paniğe kapılmadan nasıl bir rota izleyeceğini planladık. Hepsi birbiriyle konuşan küçük parçalar. Bu parçaları bir kez yerine oturttuğunda, hem KVKK ve GDPR uyumun güçleniyor hem de iç huzurun. Çünkü artık neyin nerede yaşadığını, ne zaman yolcu edilmesi gerektiğini ve kimin anahtar taşıdığını biliyorsun.
Pratik bir öneriyle bitireyim. Önümüzdeki hafta yarım saatini ayır ve bir “veri haritası” taslağı çıkar. Canlı veri, loglar, yedekler ve paylaşılan araçlar… Yanına da saklama sürelerini yaz. Sonra, yılda bir kez bunu güncelle. Kulağa küçük geliyor ama etkisi büyük. Ben de aynı yolu izliyorum; işler büyüdükçe en çok bu küçük notların yardımı dokunuyor. Umarım bu yazı sana yol açmıştır. Aklına takılan bir şey olursa sor; bir sonraki yazıda yeniden buluşuruz.
