Kart verisi ve şifreler taşınmaz. Test verisi maskeleme, süreli erişim, sayım-örneklem-toplam doğrulaması, yazılı geri dönüş planı ve kopyaların imhası.
Veri migrasyonu, kişisel verinin en savunmasız olduğu andır: veri iki sistem arasında hareket ederken, test ortamlarında kopyalanırken ve geçici yetkiler açılırken. Bu yazıda risk noktalarını, test verisi maskelemeyi, doğrulama yöntemlerini ve geri dönüş planını anlatıyoruz.
Migrasyon projelerinde konuşulan konu genelde "veri eksiksiz taşındı mı" oluyor. Bu önemli ama tek soru değil. İkinci soru şu: taşınırken kimler gördü, nereye kopyalandı ve o kopyalar ne oldu? Projeler bittikten sonra unutulan test veritabanları, en yaygın veri sızıntısı kaynaklarından biri.
Neyi koruyoruz
| Veri türü | Örnek | Risk |
|---|---|---|
| Kişisel veri | Ad, adres, telefon, e-posta | KVKK yükümlülüğü, itibar |
| Özel nitelikli veri | Sağlık, biyometrik (varsa) | Daha ağır koruma yükümlülüğü |
| Ödeme verisi | Kart bilgisi, işlem kayıtları | Taşınmamalı; sağlayıcıda kalmalı |
| Kimlik doğrulama | Şifre özetleri, oturum jetonları | Taşınmamalı; yenilenmeli |
| Ticari veri | Fiyat listeleri, marj, bayi koşulları | Rekabet zararı |
Üçüncü ve dördüncü satırlar kural niteliğinde: kart bilgisi ve şifreler migrasyonda taşınmaz. Kart verisi ödeme sağlayıcısında kalır; şifreler ise yeni sistemde sıfırlanır ve kullanıcılardan yenileme istenir. Bu, güvenlik gereği olduğu kadar operasyonel bir zorunluluk — nitekim platform geçişlerinde şifrelerin taşınmadığını WooCommerce–Shopify geçişi yazımızda da ele almıştık.
KVKK yükümlülükleri işletmenizin durumuna göre değişir; migrasyon planınızı hukuk danışmanınızla birlikte değerlendirin. Buradaki içerik teknik bir çerçevedir, hukuki görüş değildir.
Risk noktaları
- Aktarım sırasında. Veri dosya olarak taşınıyorsa şifrelenmeli; e-posta ekiyle ya da paylaşımlı bulut klasörüyle gönderilen veritabanı yedeği en sık yapılan hata.
- Test ortamında. Geliştirme ve test ortamlarına alınan gerçek müşteri verisi, üretim ortamıyla aynı korumaya sahip olmuyor.
- Geçici yetkilerde. Proje için açılan erişimler proje bitince kapatılmıyor.
- Yedeklerde. Geçiş öncesi alınan yedekler, saklama süresi belirlenmeden yıllarca duruyor.
- Tedarikçilerde. Migrasyonu yapan ajans ya da danışmanda kalan veri kopyaları.
Bu beşinin ortak özelliği: hiçbiri teknik olarak zor değil, hepsi planlanmadığı için oluyor.
Test verisi maskeleme
Geliştirme ve test aşamasında gerçek kişisel veriye ihtiyaç yok; ihtiyaç olan şey gerçekçi veri. Maskeleme yaklaşımları:
| Alan | Yaklaşım |
|---|---|
| Ad soyad | Sahte ama tutarlı isimlerle değiştir |
| E-posta | Sabit bir test alan adına yönlendir |
| Telefon | Format korunarak rastgeleleştir |
| Adres | İl/ilçe korunsun, açık adres değiştirilsin |
| TC kimlik / vergi no | Tamamen kaldır ya da geçersiz değerle değiştir |
| Sipariş tutarı, tarih | Genelde korunabilir (analiz için gerekli) |
Önemli detay: maskeleme tutarlı olmalı. Aynı müşteri kaydı farklı tablolarda aynı sahte değerle görünmeli, yoksa test sırasında ilişkiler bozuluyor ve maskelenmiş veri işe yaramaz hale geliyor.
Maskelemenin bir yan faydası da var: test ortamına gerçek veri almadığınızda, o ortamın güvenliği için harcamanız gereken efor da düşüyor.
Erişim kontrolü ve izlenebilirlik
- En az yetki. Migrasyonu yapan kişi tüm veritabanına değil, ihtiyacı olan tablolara erişmeli.
- İsimli hesaplar. Paylaşılan ortak hesap yerine kişiye özel hesaplar; kim ne yaptı görülebilmeli.
- Süreli erişim. Yetkiler proje süresiyle sınırlı açılmalı, bitiş tarihi baştan belirlenmeli.
- Kayıt. Kimin hangi veriyi ne zaman dışa aktardığı loglanmalı.
- Kapanış kontrolü. Proje bitiminde açılan tüm erişimlerin kapatıldığı bir listeyle doğrulanmalı.
Doğrulama: veri eksiksiz mi
Güvenlik kadar bütünlük de doğrulanmalı. Üç aşamalı kontrol:
- Sayım. Kaynak ve hedefteki kayıt sayıları tablo bazında eşit mi? Fark varsa nedeni açıklanabilir olmalı (ör. silinmiş kayıtların taşınmaması).
- Örneklem. Rastgele seçilen kayıtlar alan alan karşılaştırılmalı. Özellikle tarih formatları, ondalık ayraçları ve Türkçe karakterler — en sık bozulan üç şey.
- Toplam kontrolü. Sayısal alanların toplamı (ör. toplam sipariş tutarı) iki tarafta eşleşmeli. Kayıt sayısı tutup toplam tutmuyorsa, veri taşınmış ama bozulmuş demektir.
Üçüncü kontrol en çok atlanan ve en çok hata yakalayan adım.
Geri dönüş planı
Her migrasyonun bir geri dönüş planı olmalı ve bu plan yazılı olmalı. İçermesi gerekenler:
- Geçiş öncesi alınan tam yedeğin yeri ve geri yükleme süresi
- Hangi durumda geri dönüleceğine dair eşik (ör. kritik akış çalışmıyorsa)
- Kararı kimin vereceği
- Geçiş sonrası oluşan yeni verinin ne olacağı — bu en zor kısım, çünkü geri dönerken aradaki siparişler kaybolabiliyor
Geri dönüş penceresini kısa tutmak bu sorunu küçültüyor: geçişten sonraki ilk saatlerde karar verilirse aradaki veri az olur.
Geçiş sonrası: kopyaların imhası
Projenin en çok unutulan adımı. Kapanışta yapılacaklar:
- Test ve geliştirme ortamlarındaki veri kopyalarını silin.
- Aktarım için kullanılan dosyaları (ve varsa bulut klasörlerini) kaldırın.
- Tedarikçide kalan kopyalar için imha teyidi alın.
- Geçiş yedekleri için saklama süresi belirleyin ve takvime bağlayın.
- Eski sistemi ne zaman kapatacağınızı ve verisini ne kadar saklayacağınızı yazın.
Kontrol listesi
- Hangi veri türlerinin taşınacağı ve taşınmayacağı yazılı mı?
- Kart verisi ve şifreler taşıma kapsamı dışında mı?
- Test ortamındaki veri maskelendi mi ve maskeleme tutarlı mı?
- Erişimler isimli, süreli ve en az yetki ilkesine göre mi açıldı?
- Aktarım şifreli bir kanaldan mı yapılıyor?
- Sayım, örneklem ve toplam kontrolü yapıldı mı?
- Yazılı geri dönüş planı ve karar sahibi belli mi?
- Kapanışta kopyaların imhası listelendi mi?
Sık yapılan hatalar
- Test ortamına gerçek veri almak. En yaygın ve en kolay önlenebilir risk.
- Yedeği paylaşımlı klasöre koymak. Şifresiz, süresiz ve izlenemez.
- Proje yetkilerini kapatmamak. Aylar sonra hâlâ açık erişimler bulunuyor.
- Yalnızca kayıt sayısını doğrulamak. Sayı tutup içerik bozulabiliyor.
- Geri dönüş planını yazmamak. Kriz anında sözlü plan işlemiyor.
Sonuç
Veri migrasyonunda güvenlik, ek bir aşama değil planın parçası: neyin taşınmayacağına karar vermek, test ortamına gerçek veri almamak, erişimleri süreli açmak ve kapanışta kopyaları imha etmek. Bu dördü yapıldığında geriye kalan iş, veri bütünlüğünü doğrulamaktan ibaret.
Platform geçişinin SEO ve teknik tarafı için WooCommerce'ten Shopify'a geçiş, sistemler arası kalıcı veri akışı için ERP entegrasyonu yazımıza bakabilirsiniz.
Commerslab olarak veri migrasyonlarını maskeleme, doğrulama ve imha adımları dahil yürütüyoruz. Veri migrasyonu hizmetimizi inceleyin veya geçiş planınız için bize yazın.
