Hosting Uyumunda Veri Haritasıyla Başlamak
Çerez bildirimi hazırlamak, kişisel verilerin hosting altyapısında nasıl işlendiği sorusunu tek başına çözmez. Veritabanının konumu, logların içeriği, yedeklerin saklama süresi ve silme taleplerinin izlediği yol birlikte değerlendirilmelidir. KVKK ve GDPR açısından hosting seçimi, bu teknik akışları geçerli hukuki yükümlülüklerle eşleştirmeyi gerektirir; tek bir sunucu ayarı uyum garantisi vermez.
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
Hosting ortamında kişisel veri; müşteri tablosunda, erişim logunda, destek kaydında veya e-posta sunucusunda bulunabilir. İşlemenin amaç ve vasıtalarını belirleyen işletme çoğunlukla veri sorumlusudur; talimatları doğrultusunda hizmet sunan sağlayıcı ilgili faaliyet bakımından veri işleyen olabilir. Sağlayıcının kendi faturalama veya güvenlik faaliyetlerindeki rolü ayrıca değerlendirilir. KVKK ve GDPR farklı kapsam ve usullere sahiptir; hangi işlemenin hangi düzenlemeye tabi olduğu başta belirlenmelidir.
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
Sunucunun Türkiye’de veya Avrupa Ekonomik Alanı’nda bulunması, bazı aktarım ve gecikme sorunlarını azaltabilir; tek başına KVKK veya GDPR uyumu sağlamaz. GDPR genel bir “veri mutlaka AB’de kalır” kuralı getirmez; bölge dışına aktarımın uygun hukuki mekanizması ayrıca değerlendirilir. KVKK’nın 2024’te değişen 9. maddesi de yeterlilik, uygun güvenceler ve sınırlı arızi istisnalar içeren ayrı bir rejimdir. Düzenli yabancı bulut kullanımını yalnız açık rızaya veya bölge seçimine dayandırmadan ilgili aktarım şartlarını incele.
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ı. Örneğin, farklı sağlayıcıdaki bir yedek veya yurt dışından yönetici erişimi, ana sunucu yerinde kalsa bile ayrıca değerlendirilmesi gereken bir veri akışı oluşturabilir. 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.
CDN’de yalnız herkese açık statik dosyaları önbelleğe almak yararlı bir başlangıçtır; ancak IP adresleri, istek başlıkları ve sağlayıcının güvenlik logları da kişisel veri içerebilir. Bölge seçimi ve kısa TTL, aktarımın hukuki dayanağının yerine geçmez. Hangi uç noktaların ve alt işleyenlerin veriye eriştiğini, hangi alanların loglandığını ve ne zaman silindiğini sözleşme ve teknik ayarlarda doğrula. Kişiye özel yanıtları ortak önbelleğe alma. HTTP katmanını ayrıca güçlendirmek için HTTP güvenlik başlıklarını ne zaman, nasıl uygulamalısın? rehberine bakabilirsin.
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.
Uygulama, erişim ve güvenlik loglarını amaçlarına göre ayır; ayrıntılı ve özet kayıtlar için gerekçeli saklama süreleri belirle. Parola, erişim belirteci ve tam oturum kimliklerini kaydetme. Gerekli kimlik alanlarında maskeleme veya takma adlandırma riski azaltabilir, ancak veriyi kendiliğinden anonim yapmaz. Saklama süresini güvenlik ihtiyacı, destek süreçleri ve geçerli yasal yükümlülüklerle ilişkilendir; kişisel veri içeren özet kayıtları da bu plana dahil et.
“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?
Silme talebinde önce talep sahibini uygun biçimde doğrula, kapsamı belirle ve devam eden hukuki saklama yükümlülüklerini kontrol et. Silinmesi gereken kayıtları canlı veritabanı, ilişkili dosyalar, önbellekler ve ilgili diğer sistemlerde ele al. Bir kaydı yalnız arayüzden gizlemek veya erişilebilir bir kimliği maskelemek tam silme ya da anonimleştirme değildir. Uygulanan işlemleri ve hangi kopyaların hangi süreyle tutulduğunu talep kaydında belgele.
Yedeklerde tek kaydı güvenle ayıklamak mümkün değilse otomatik sona erme tek başına yeterli sayılmamalıdır. Uygulanacak mevzuata uygun, gerekçeli bir yedek saklama planı kur; silinmesi gereken veriyi olağan kullanımdan çıkar, erişimi sınırla ve son kopyanın imha tarihini belirle. Geri yüklemede silme kayıtlarını yeniden uygulayarak verinin üretimde tekrar görünmesini önle. Bu yaklaşımın ilgili talebi ve süreleri karşılayıp karşılamadığı ayrıca değerlendirilmelidir.
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 şu rehber yararlı bir başlangıç olabilir: 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 güncel ve güvenli protokollerle bağlanmak, veritabanı erişimlerini gerekli IP adresleriyle sınırlamak ve panellerin güvenlik güncellemelerini uygulamak bunlardan bazıları. Uygun HTTP güvenlik başlıkları ek koruma sağlayabilir; yazılımdaki açıkları gideren güncellemelerin yerine geçmez. 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ı alan adının kötüye kullanımını azaltmaya yardımcı olur; veri koruma yükümlülüklerini tek başına karşılamaz.
Ş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.
Bu örnekte gizlilik ve saklama planı; sipariş, fatura, destek ve pazarlama kayıtlarını ayrı ele alır. Bir silme talebinde artık gerekli olmayan veriler kaldırılırken, zorunlu olarak tutulması gereken kayıtlar amaç ve erişim sınırıyla korunur. Yedeklerin imha takvimi ve geri yükleme sonrası silme prosedürü de belgelenir. Yönetici hesaplarında iki aşamalı doğrulama ve e-posta kimlik doğrulaması bu süreci destekleyen güvenlik kontrolleridir.
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
Sağlayıcıyla işleme amaçlarını, talimatları, gizlilik yükümlülüklerini, alt işleyenleri, ihlal bildirimini, iade ve silmeyi kapsayan sorumlulukları yazılı belirle. GDPR kapsamında veri işleyen kullanıldığında 28. maddeye uygun bağlayıcı bir düzenleme gerekir; genel hizmet sözleşmesinin bunu gerçekten karşılayıp karşılamadığını kontrol et. Yurt dışı aktarım sözleşmeleri ayrı gereksinimler taşır. KVKK standart sözleşmesi kullanılıyorsa imza sonrası beş iş günlük bildirim yükümlülüğünü de süreç sahibine ata.
Aktarım konusunda KVKK’nın güncel yurt dışına aktarım açıklamasını ve standart sözleşme bildirim duyurusunu kullan. Diğer resmi kaynaklara KVKK’nın ana sitesinden ulaşabilirsin. GDPR için Avrupa Komisyonunun uluslararası aktarım kaynakları resmi bir başlangıçtır; ayrıca standart sözleşme maddeleri (SCC) sayfasına bakabilirsin. GDPR.eu özeti ise resmi mevzuat kaynağı değildir. Bölge ve sözleşme seçimlerini somut veri akışı için değerlendirmek, yalnız genel bir uyum ifadesine güvenmekten daha anlamlıdır.
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.
İlk adım olarak canlı veri, log, yedek ve üçüncü taraf hizmetlerini içeren bir veri haritası hazırla. Her kayıt kategorisine amaç, sorumlu kişi, hukuki gerekçe, erişim ve imha süresi ekle. Yeni bir sağlayıcı, ülke, entegrasyon veya işleme amacı devreye girdiğinde planı güncelle; düzenli gözden geçirme ve geri yükleme testleriyle uygulamanın belgeyle örtüştüğünü kontrol et.
