Yedek Şifreleme ve Anahtar Yönetimi Rehberi

Yedek Şifreleme ve Anahtar Yönetimi Neden Bu Kadar Kritik?

Birçok ekip yedek almayı çözdüğünü düşünüyor: günlük cPanel yedekleri, haftalık VPS snapshot’ları, arada bir manuel indirilmiş SQL dosyaları… Sonra güvenlik veya KVKK/GDPR denetimi geldiğinde şu soru soruluyor: “Bu yedekler şifreli mi, anahtarları kim yönetiyor, saklama süresi ne kadar ve biri taşınabilir diski çalarsa ne olur?” İşte asıl sınav o anda başlıyor.

Bugün hem siber saldırılar hem de regülasyon baskısı arttı. Ransomware grupları artık sadece canlı sistemi değil, yedekleri de hedef alıyor. KVKK ve GDPR ise yedekler dahil tüm kopyalar için “gizlilik, bütünlük, erişilebilirlik” ve “hesap verebilirlik” istiyor. Yani yedek almıyor olmak kadar, plansız, şifresiz ve kontrolsüz yedek almak da ciddi risk.

Bu rehberde DCHost ekibi olarak, hosting ve VPS ortamlarında uygulanabilir bir yedek şifreleme ve anahtar yönetimi mimarisi nasıl kurulur, object storage bu işte nasıl konumlanır ve tüm bunlar KVKK/GDPR ile nasıl uyumlu hale getirilir; adım adım, gerçekçi örneklerle anlatacağız. Amacımız sizi karmaşık standart metinlerine boğmak değil; pazartesi sabahı gerçekten uygulayabileceğiniz, test edilebilir bir mimari bırakmak.

Temel Kavramlar: Şifreleme, Anahtar ve Object Storage

Simetrik ve asimetrik şifreleme: Yedek tarafında hangisi mantıklı?

Yedek şifreleme dünyasında çoğu senaryoda simetrik şifreleme kullanılır. Tek bir gizli anahtar ile hem şifreler hem çözeriz (örneğin AES-256-GCM). Bunun sebebi:

• Performansının yüksek olması (büyük yedek dosyaları için kritik)
• Çoğu yedekleme aracının bunun etrafında tasarlanmış olması

Asimetrik şifreleme (örneğin RSA veya elliptic curve tabanlı algoritmalar) ise yedek tarafında genelde anahtar sarma (key wrapping) için kullanılır. Örnek akış:

• Yedek aracı rastgele bir simetrik anahtar üretir.
• Yedeği bu anahtarla şifreler.
• Simetrik anahtarı da kamu anahtarı ile şifreleyip yanında saklar.

Böylece gerçek gizli anahtarı (özel anahtar) daha dar bir çevrede, daha sıkı kontrollü bir ortamda tutabilir, erişimi sınırlayabilirsiniz. Bu yaklaşım özellikle çok kiracılı (multi-tenant) SaaS yedeklerinde ve anahtar rotasyonu yapmak istediğiniz durumlarda hayat kurtarır.

Aktarımda ve depoda şifreleme

KVKK/GDPR uyumlu bir mimaride iki ayrı katmanı aynı anda düşünmeniz gerekir:

• Aktarımda şifreleme (in transit): Yedeği object storage’a, uzak bir VPS’e veya DCHost altyapısındaki başka bir sunucuya gönderirken her zaman TLS kullanmalısınız. SFTP, HTTPS, TLS destekli rsync, TLS destekli veritabanı bağlantıları gibi.
• Depoda şifreleme (at rest): Yedek dosyası disk veya object storage üzerinde saklanırken şifreli olmalı. Burada iki yol var:

1. İstemci tarafı şifreleme: Yedek daha sunucudan çıkmadan, backup aracı tarafından şifrelenir. Object storage sadece “anlamsız veri bloklarını” görür. Gerçek güvenlik buradan gelir.
2. Sunucu/depoma taraflı şifreleme: Object storage veya disk katmanı kendi içinde şifreleme uygular. Bu, kaybolan fiziksel diskler ve bazı riskler için iyidir ama tek başına yeterli kabul edilmemelidir.

Object storage nedir, yedekte neden bu kadar işimize yarar?

Object storage, klasik dosya sistemlerinden farklı olarak veriyi nesneler (objects) halinde saklayan, çoğu zaman S3 uyumlu API’lerle eriştiğimiz depolama türüdür. Yedekleme için avantajları:

• Pratikte sınırsız ölçeklenebilirlik
• Versiyonlama, lifecycle policy, immutable (değiştirilemez) yedek gibi özellikler
• Coğrafi replikasyon ve felaket senaryolarına uygunluk

DCHost tarafında da, hem cPanel hem de VPS yedeklerini S3 uyumlu object storage’a taşıyan müşterilerde ciddi esneklik kazanıldığını görüyoruz. Bu konuda detaylı pratikler için object storage’a otomatik yedek alma ve rclone/restic ile entegrasyon yazımızı incelemenizi öneririz.

Hosting ve VPS Ortamlarında Yedek Şifreleme Mimarileri

Paylaşımlı hosting (cPanel) projelerinde gerçekçi yaklaşım

Paylaşımlı hosting kullanan küçük işletmeler ve ajanslar genellikle şu yapıya sahip:

• cPanel üzerinden düzenli dosya + veritabanı yedekleri
• Panelin kendi yedekleme sistemi (örneğin haftalık tam yedek)
• Ek olarak manuel indirilmiş .zip ve .sql dosyaları

Burada en sık gördüğümüz hata şu: “Yedekler bende, güvendeyim.” Oysa masaüstüne indirilen o .zip dosyaları çoğu zaman şifresiz ve şirket içindeki birçok kişinin erişimine açık. KVKK gözünden bakarsak; bu, kontrolsüz bir kişisel veri kopyası demek.

cPanel senaryosu için önerdiğimiz pratik mimari:

1. cPanel’in otomatik yedeklerini aktif bırakın. Bunlar genellikle DCHost altyapısında izole ve erişim kontrollü tutulur.
2. Ek olarak, panelden aldığınız tam yedekleri veya sadece veritabanı + wp-content gibi kritik klasörleri şifreli bir arşiv haline getirin (örneğin AES-256 ile şifrelenmiş .tar.gz).
3. Bu şifreli arşivi SFTP veya S3 uyumlu endpoint üzerinden harici bir object storage kovasına gönderin.
4. Şifreleme parolasını veya anahtarını, site dosyalarının içinde değil, ayrı bir güvenli ortamda (şifre yöneticisi, ayrı bir secrets deposu) saklayın.

WordPress kullanan projelerde bu yapıyı, WordPress yedekleme stratejileri yazısındaki metodlarla rahatça birleştirebilirsiniz.

VPS ve dedicated sunucularda ajan tabanlı şifreli yedekler

VPS veya dedicated sunucuda kendi yedek altyapınızı kuruyorsanız, en ideal yöntemlerden biri ajan tabanlı, istemci tarafı şifreleme yapan araçlar kullanmaktır. Genel mimari şöyle olur:

• Sunucu üzerinde yedekleme ajanı çalışır (cron veya systemd timer ile tetiklenir).
• Ajan, dosya sistemi ve veritabanlarından tutarlı yedek alır (örneğin LVM snapshot veya veritabanı konsistent dump’ları ile).
• Yedeği sunucuda şifreler ve sadece şifreli akışı uzak object storage’a veya başka bir VPS’e gönderir.

Bu modelin artıları:

• Object storage veya uzak sunucu ele geçirilse bile verinin anlamlı hale gelmesi için anahtara ihtiyaç var.
• Veriye erişim seviyelerini “yedeklere erişim” ve “anahtarlara erişim” olarak ayırabilirsiniz.
• Ransomware saldırganı storage tarafındaki yedekleri görse bile, şifre çözme anahtarına ulaşamıyorsa veriyi kullanamaz.

Burada kritik nokta, anahtarların nerede tutulduğu. Bu konuya aşağıdaki “Anahtar Yönetimi” bölümünde detaylı döneceğiz, ama şimdiden söyleyelim: Şifreyi cron scriptine düz metin yazmak, uzun vadede başınızı mutlaka ağrıtır.

Object storage üzerinde şifreleme seçenekleri

Object storage sağlayıcıları genellikle birkaç farklı şifreleme modu sunar. İsimler değişse de mantık benzerdir:

• Depolama taraflı şifreleme (provider-managed): Sağlayıcı veriyi disk katmanında şifreler; anahtarlar altyapı tarafından yönetilir.
• Müşteri yönetimli anahtarlar: Yine depolama taraflıdır ama anahtarların oluşturulması, rotasyonu ve erişim kontrolü sizin politikalarınıza göre yönetilir.
• İstemci taraflı şifreleme: Yedeği uygulama veya yedek yazılımı şifreler; object storage şifreli blob’tan başka bir şey bilmez.

KVKK/GDPR ve güçlü bir tehdit modelinde, asıl güvenlik katmanınızı istemci tarafı şifreleme üzerine kurmanızı öneriyoruz. Depolama taraflı şifreleme ise buna ek, ikinci bir savunma hattı olarak düşünülmeli. Özellikle fidye yazılımlara dayanıklı mimarilerde, S3 Object Lock ile immutable yedek ve 3‑2‑1 kuralını uygulayan yedekleme stratejileri neredeyse zorunlu hale geliyor.

Anahtar Yönetimi: Güvenliğin İnce Beli

Anahtarları nerede saklamalısınız?

Şu cümleyi çok ciddiye almak gerekiyor: Şifreleme, anahtar kadar güçlüdür. Yedekleriniz AES‑256 ile şifreli olabilir; ama anahtar “backup.sh” dosyasının içinde düz metin duruyorsa, gerçekte fazla bir şey kazanmamışsınız demektir.

Pratikte kullanılan birkaç yaklaşım:

• Şifre yöneticisi + offline kayıt: Ana parolalar (örneğin yedek kasasının master anahtarı) güvenilir bir şifre yöneticisinde, ayrıca offline olarak (kağıt, metal kart, güvenli kasada) saklanır.
• Sunucu üzerindeki çalışma anahtarları: Otomatik yedekler için gereken parolalar, sadece root’un okuyabildiği bir konfigürasyon dosyasında veya systemd üzerinden environment secret olarak tutulur.
• Secrets yönetim araçları: Orta/büyük yapılarda ayrı bir secrets deposu (örneğin KMS benzeri bir sistem) kullanmanız gerekir. Bu konuda fikir edinmek için VPS’te .env ve gizli anahtar yönetimi yazımızı mutlaka okuyun.

Kritik prensip: Yedek dosyası ile anahtarı asla aynı yerde tutmayın. Yedek object storage’ta ise, anahtar şirketteki başka bir güvenli sistemde olmalı; mümkünse farklı güvenlik domain’lerinde.

Erişim yetkileri, rotasyon ve loglama

Anahtar yönetiminde ihmal edilen üç konu var: kim, neye, ne zaman erişiyor; anahtarlar ne sıklıkta değişiyor; ve bu işlemler nasıl loglanıyor.

• En az ayrıcalık (least privilege): Yedek şifreleme anahtarına erişmesi gereken kişi ve sistemler listesi olabildiğince kısa olmalı. Geliştirici, müşteri temsilcisi veya stajyerin bu anahtara ihtiyacı yok.
• Rol bazlı erişim (RBAC): “Yedekleri okuma” ve “anahtarları yönetme” yetkilerini farklı roller altında ayırın.
• Rotasyon: Kullandığınız algoritmaya göre, yılda en az bir kez anahtar değişikliği (key rotation) planlayın. Anahtar sızıntısı şüphesinde ise anında rotasyon yapabiliyor olmanız lazım.
• Loglama: Anahtar erişim denemeleri, başarısız girişimler, rotasyon ve silme olayları mutlaka loglanmalı; loglar da manipüle edilemeyecek şekilde saklanmalı.

Anahtarı kaybederseniz ne olur?

Bu sorunun yanıtı rahatsız edici ama net: Anahtarı kaybederseniz, yedeğiniz yok demektir. Şifreleme, tek yönlü bir bilet gibidir. Bu yüzden mimariyi kurarken şu dengeyi iyi oturtmanız gerekir:

• Bir yandan anahtarı korumak (yetkisiz kişilere kaptırmamak)
• Diğer yandan felaket anında, yetkili ekibin anahtara ulaşabilmesini sağlamak

Pratik öneriler:

• Kritik master parolalar için iki kişili onay (two‑man rule) uygulayın; örneğin, iki ayrı yönetici ayrı ayrı parçalara sahip olsun (shamir secret sharing gibi yöntemler).
• Felaket kurtarma runbook’unuza “anahtara nasıl erişileceği”ni, kimlerin onayı gerekeceğini ve bu adımların nasıl loglanacağını yazın. Bu konuda felaket kurtarma planı hazırlama rehberi size iyi bir çerçeve sunacaktır.

KVKK/GDPR Uyumlu Yedekleme Tasarımı

Yedeklerde kişisel veri ve maskeleme

Birçok ekip KVKK/GDPR uyum çalışmalarını canlı veritabanı, loglar ve analitik araçlar üzerinde yapıyor; ancak yedekleri unutuyor. Oysa regülasyonlar açısından yedekler de kişisel veri içeriyorsa aynı yükümlülüklere tabi. Örneğin:

• Müşteri ad/soyad, adres, IBAN, telefon, e‑posta
• IP adresleri, çerez ID’leri, kullanıcı davranış kayıtları
• Hassas kategorideki veriler (sağlık, sendika, dini inanç vb.)

Mümkünse, yedeklerinizde maskeleme veya pseudonymization düşünün. Örneğin test/staging ortamına yedek geri yüklerken, gerçek kullanıcı verilerini maskelenmiş dataset ile değiştirmek hem güvenliği hem de KVKK uyumunu ciddi biçimde güçlendirir. Log tarafında IP maskeleme gibi yöntemler için log anonimleştirme ve IP maskeleme rehberimize göz atabilirsiniz.

Silme talepleri, immutable yedekler ve çelişkiyi yönetmek

GDPR’nin ünlü “unutulma hakkı” ve KVKK’nin ilgili hakları, yedekler açısından kafa karıştırıcı olabilir. Bir kullanıcı verisinin silinmesini istediğinde, peki ya yedeklerdeki kopyalar?

Avrupa’daki rehber dokümanlar ve uygulamalar genellikle şu yaklaşımı benimsiyor:

• Aktif sistemlerden veri mümkün olduğunca kısa sürede silinir veya anonimleştirilir.
• Yedeklerdeki kopyalar tek tek aranıp silinmeyebilir; bunun yerine sınırlı saklama süreleri ve erişim kısıtları ile yönetilir.
• Felaket durumunda yedekten geri yükleme yapılırsa, ilgili kullanıcının talebini tekrar uygulayacak süreçler hazır olmalıdır.

Immutable (değiştirilemez) yedek kullandığınızda bu konu daha da kritiktir. Strateji olarak:

• Immutable sürelerini risk ve regülasyon dengesine göre mümkün olduğunca kısa tutun.
• Bu süre dolduktan sonra, yedeklerin geri döndürülemez biçimde silindiğini veya anonimleştirildiğini garanti edecek politikalar kurun.

Saklama süreleri, maliyet ve sorumluluk dengesi

“Bu yedekleri kaç yıl tutmalıyız?” sorusu hem KVKK/GDPR hem de maliyet tarafında zorlayıcıdır. Çok kısa tutarsanız, eski bir veriye ihtiyacınız olduğunda eliniz boş kalabilir; çok uzun tutarsanız hem depolama maliyeti hem de veri sızıntısı riski artar.

Genel prensipler:

• Amaçla sınırlılık: Yedekleri, ilgili iş sürecinin gerektirdiği süre kadar saklayın; “belki lazım olur” diye sonsuza kadar tutmayın.
• Katmanlı saklama: Operasyonel (kısa vadeli), arşiv (orta vadeli) ve hukuki zorunluluk (uzun vadeli) katmanlarını ayırın.
• Yaşlandırma politikaları: Object storage üzerinde lifecycle policy ile eski yedekleri daha ucuz ama erişimi yavaş depolamaya taşıyın veya otomatik silin.

Bu konuyu daha detaylı tartmak isterseniz, yedek saklama süresi, KVKK/GDPR ve maliyet dengesi rehberimiz operasyonel kararları netleştirmenize yardımcı olacaktır.

Örnek Mimariler: Küçük İşletme, E‑Ticaret ve SaaS

Küçük işletme vitrini: Tek cPanel hesabı, basit ama sağlam mimari

Senaryo: Bir danışmanlık firmasının kurumsal web sitesi, tek bir DCHost paylaşımlı hosting hesabında barınıyor. Site WordPress, formlar üzerinden kişisel veri toplanıyor (ad, e‑posta, mesaj içeriği).

Önerilen yedek ve şifreleme mimarisi:

1. DCHost cPanel hesabında günlük otomatik yedekler aktif.
2. Haftada bir, panelden tam yedek alınarak sunucu üzerinde şifreli bir .tar.gz arşive dönüştürülüyor.
3. Bu arşiv, sadece bu iş için oluşturulmuş, erişimi kısıtlı bir kullanıcıyla SFTP üzerinden uzak bir DCHost VPS’e veya S3 uyumlu object storage’a gönderiliyor.
4. Şifreleme parolası şirket içi şifre yöneticisinde; sadece teknik sorumlu ve yönetici ortaklarda kayıtlı.
5. Ayda bir kez yedekten test geri yükleme yapılarak, hem şifre çözme hem de kurtarma adımları doğrulanıyor.

Bu yapı; küçük bir işletme için hem uygulanabilir, hem de KVKK denetiminde anlatabileceğiniz, dokümante edilebilir bir mimari sunar.

Orta ölçekli WooCommerce mağazası: Çok katmanlı yedek + immutable object storage

Senaryo: DCHost VPS üzerinde koşan yüksek trafikli bir WooCommerce mağazası. Müşteri verileri, sipariş geçmişi, kargo adresleri ve ödeme süreciyle ilgili loglar var.

Burada hem RPO/RTO hedefleri daha agresif, hem de hukuki risk daha yüksek. Önerilen yaklaşım:

• Seviye 1 – Sıcak yedek: Veritabanı için saatlik, dosya sistemi için 4 saatte bir incremental yedek; yedekler aynı veri merkezindeki hızlı depolamada, şifreli tutuluyor.
• Seviye 2 – Uzak şifreli yedek: Günlük tam yedekler, istemci tarafında şifrelenerek S3 uyumlu object storage’a gönderiliyor. Burada immutable (Object Lock) politikaları 7–14 gün arası ayarlanmış.
• Seviye 3 – Arşiv yedek: Haftalık veya aylık tam yedekler, daha uzun saklama süreli ve daha düşük maliyetli bir depolama sınıfına taşınıyor.

Anahtar yönetimi tarafında:

• Her ortam (staging, canlı) için ayrı şifreleme anahtarları.
• Yedek şifreleme anahtarlarına erişim sadece SRE/DevOps ekibinde.
• Rotasyon yılda en az bir; ayrıca anahtar sızıntısı şüphesi durumunda acil rotasyon planı.

WooCommerce için bu tür performans ve yedek planlamasına geniş bir yer ayırdığımız kapasite planlama rehberi de altyapı boyutlandırmasında işinize yarayacaktır.

KVKK hassas SaaS uygulaması: Müşteri başına mantıksal yedekler ve sıkı erişim

Senaryo: DCHost üzerinde barındırılan, çalışan verisi veya sağlık verisi gibi hassas kategoriler işleyen bir SaaS. Çok kiracılı (multi‑tenant) mimari kullanıyor.

Burada mimariyi biraz daha sıkılaştırmak gerekiyor:

• Mümkünse müşteri bazında mantıksal veri ayrımı (ayrı veritabanı veya şema) yaparak yedekleri de müşteri başına yönetilebilir hale getirmek.
• Yedekleri, uygulama sunucusu yerine ayrı bir “backup node” üzerinden almak; yedek şifreleme anahtarları sadece bu node’da mevcut olsun.
• Yedek metadata’sında, hangi yedeğin hangi müşteriye ait olduğu, hangi saklama politikasına tabi olduğu ve ne zaman silineceği gibi bilgiler bulunmalı.

Bu tür yapılarda; yedekleme, saklama ve silme politikalarını müşteri sözleşmelerine bağlamak, KVKK/GDPR tarafında büyük avantaj sağlar. SaaS uygulamaları için müşteri verisi yedekleme ve veri saklama politikaları başlıklı yazımızda bu senaryoyu daha detaylı ele alıyoruz.

DCHost ile Uygulanabilir Yol Haritası

Tüm bu başlıkları okuduktan sonra aklınızda muhtemelen şu sorular var: “Biz nereden başlayalım, mevcut yedeklerimizi nasıl güvenli hale getiririz, KVKK/GDPR tarafında neyi ne kadar yapmamız gerekiyor?” DCHost tarafında gördüğümüz en sağlıklı ilerleyiş şu adımlarla oluyor:

1. Mevcut durumu envanterleme: Nerede, hangi veriler var? Hangi yedekler alınıyor, nereye gidiyor, şifreli mi? Kimler erişebiliyor?
2. RPO/RTO hedeflerini netleştirme: Farklı sistemler için kabul edilebilir veri kaybı ve kesinti sürelerini belirleyin. Burada RPO/RTO odaklı yedekleme stratejisi rehberimiz size iyi bir çerçeve sunar.
3. Yedek şifreleme stratejisini seçme: Küçük siteler için basit şifreli arşiv + SFTP, daha büyük yapılar için istemci tarafı şifreleme + object storage + immutable politikalar.
4. Anahtar yönetimi politikasını yazılı hale getirme: Kim, hangi anahtara erişebilir? Rotasyon periyodu ne? Anahtar kaybı veya sızıntısında ne yapılacak?
5. Test ve dokümantasyon: En az ayda bir, rastgele bir yedeği alıp başka bir DCHost sunucusuna geri yükleyerek, hem şifre çözme hem de kurtarma adımlarını test edin; sonucunu dokümante edin.

DCHost olarak; paylaşımlı hosting, VPS, dedicated ve colocation projelerinde bu adımları müşterilerimizle birlikte kurguluyoruz. İhtiyacınıza göre:

• cPanel seviyesinde otomatik yedek ve geri yükleme senaryoları,
• VPS üzerinde şifreli yedek ajanlarının kurulumu ve object storage ile entegrasyonu,
• KVKK/GDPR uyumluluğu için veri saklama ve silme politikalarının teknik uygulanışı

gibi konularda birlikte çalışabiliriz. Mevcut altyapınızı gözden geçirmek veya yeni bir projeyi baştan doğru kurgulamak isterseniz, DCHost ekibiyle iletişime geçmeniz yeterli. En önemlisi, yedeklerinizi ve anahtarlarınızı ilk günden “denetlenebilir ve test edilmiş” bir mimariyle kurmak; çünkü gerçek felaket anında ikinci deneme şansınız olmayabiliyor.