Shadow Data (Gölge Veri) Nedir? Nasıl Bulunur?

Shadow Data (gölge veri), kurumun envanterinde durmayan hassas veri kopyalarıdır: bir veritabanının yedeği, dışa aktarılmış bir müşteri listesi, kapatılmış bir projeden kalan bir paylaşım klasörü. Hepsinin ortak yanı, üretim sistemi kadar hassas veri taşıyıp üretim sistemi kadar korunmamalarıdır.

Bir kurumun taşınmasını düşünün. Yeni ofise yerleşilir, dolaplar dizilir, arşiv düzenli tutulur. Ama taşınma sırasında bir yığın evrak “şimdilik dursun” diye kiralık bir depoya kaldırılır: personel dosyaları, eski müşteri sözleşmeleri, muhasebe klasörleri. O kutular birkaç haftalığına konulmuştu. Beş yıl sonra hâlâ oradadırlar; deponun anahtarı üç kişide, içinde ne olduğunun listesi hiç kimsede. İçerideki dosyalar ofistekilerle aynı derecede gizlidir, ama ofisin kilidi, kamerası ve düzeni orada yoktur.

Bu yazı boyunca o depoyu takip edeceğiz. Konu BT Danışmanlık hizmetimizin risk tespiti koluna girer ve gölge BT (Shadow IT) ailesinin bir üyesidir: kardeşleri gölge yapay zekâ ve gölge yönetici gibi, buradaki tehlike de bir şeyin var olması değil, kurumun onu görmüyor olmasıdır.

Shadow Data (Gölge Veri) Nedir?

Gölge veri, korunan üretim sisteminin dışında yaşayan hassas veri kopyasıdır. Kurumun asıl veritabanı erişim denetimiyle, şifrelemeyle ve yedekleme düzeniyle korunur; gölge veri ise o veritabanından bir kez çıkmış ve bu korumaların hiçbirini yanında götürmemiş bir kopyadır.

Aradaki fark, deponun ofisten farkıyla aynıdır. Ofiste kim hangi dolaba girer bellidir, kapı akşam kilitlenir, bir evrak kaybolsa fark edilir. Depodaki kutuda ise aynı bilgi vardır ama bu düzenin hiçbiri yoktur: onu kimin göreceği, ne zaman imha edileceği, hatta orada olduğu bile kayıtlı değildir. Veri aynı veridir; değişen tek şey, onu koruyan çerçevenin geride kalmasıdır.

Bu yüzden gölge verinin en sık aldığı biçimler, bir sistemden “bir kereliğine” çıkarılmış olanlardır: bir raporlama için alınmış veritabanı yedeği, bir sunum için dışa aktarılmış müşteri listesi, bir taşıma sırasında bir köşeye kopyalanmış paylaşım klasörü. Üçü de meşru bir işten doğar ve iş bitince geride kalır.

Aynı Veri, İki Ayrı Koruma Seviyesi

Gölge verinin neden ayrı bir sorun olduğunu bir cümlede toplayabiliriz: saldırı yüzeyi envanterden büyüktür. Kurum envanterindeki sistemleri sayar, onları korur ve onlar üzerinden risk hesaplar. Ama saldırgan envantere bakmaz; en iyi korunan veritabanını değil, aynı veriyi taşıyan en zayıf kopyayı hedefler. Bir masaüstünde duran bir müşteri listesi, kurumsal veritabanına girmekten çok daha kolaydır ve içindeki veri aynıdır.

Bir kopyanın ne kadar tehlikeli olduğunu da o kopyanın durduğu yerin izinleri belirler. Herkese açık bir paylaşım klasöründe duran bir müşteri listesi, aynı verinin bir üyesinin masaüstünde durmasından çok daha risklidir; kimin okuyabildiği sorusu gölge verinin ağırlığını doğrudan değiştirir. Dosya izinlerinin nasıl yanlış kurulup kimseye görünmeden yetki taşıdığını Shadow Admin (gölge yönetici) yazımızda ele aldık; iki sorun sık sık aynı klasörde buluşur.

KVKK tarafı da tam burada devreye girer, çünkü kopya da kişisel veridir. Bir müşteri listesinin dışa aktarılmış hâli, canlı veritabanındaki kaydıyla aynı sorumluluğu taşır. Bu sorumluluğun teknik karşılığını KVKK teknik uyum yazımızda ele alıyoruz; buradaki bağ şu: kurum, varlığından haberdar olmadığı bir kopyadan da sorumludur.

Gölge Veri Nasıl Doğar? “Geçici” Diye Açılan Kayıt

Gölge veri neredeyse hiçbir zaman kötü niyetle doğmaz; geçici olduğu düşünülen bir işten doğar. Bir yedek birkaç güne silinecektir, bir dışa aktarım sunum bitince çöpe gidecektir, bir paylaşım klasörü proje kapanınca kaldırılacaktır. Sonra iş biter, kararı veren kişi başka bir işe geçer ve geçici olan kalıcı olur.

Buradaki mekanizma, deponun kendisinden daha sinsidir ve analojinin koptuğu yer de burasıdır. Depoya bir kutu kaldırdığınızda o kutu ofisten çıkar: bir yerdedir, iki yerde değil. Veriyi kopyaladığınızda ise asıl kayıt yerinde kalır, siz yalnızca bir ikinci nüsha yaratmış olursunuz. Yani veriyi taşımadınız, çoğalttınız; ve çoğu zaman bunu yaptığınızı gösteren bir iz bile kalmaz. Bir kutuyu kaldırdığınızı hatırlarsınız, bir tabloyu dışa aktardığınızı çoğu zaman hatırlamazsınız.

Bunun sahadaki en tanıdık işareti, adında “geçici” yazan klasörlerdir. Bir sonraki bölümde göreceğimiz taramada, Gecici adlı bir klasörde dört buçuk yıllık bir veritabanı yedeği çıktı: adı geçiciydi, ömrü kalıcı. Bu tek dosya, gölge verinin bütün hikâyesini anlatır.

Kopya Nereden Doğar? En Sık Görülen Kaynaklar

Kopyanın nereden geldiğini bilmek, onu önlemenin ilk adımıdır ve birkaç kaynak ötekilerden daha sık görülür.

• Raporlama ve analiz. Bir tabloyu Excel’e ya da bir BI aracına dışa aktarmak en yaygın kaynaktır; rapor hazırlanır, dosya masaüstünde ya da bir paylaşımda kalır.
• Test ve geliştirme. Bir sistemi gerçekçi denemek için canlı verinin bir kopyası test ortamına alınır. Test biter, kopya kalır ve genellikle test ortamı canlı ortamdan daha az korunur.
• Göç ve taşıma. Eski bir sistemden yenisine geçilirken verinin tam bir yedeği alınır. Geçiş tamamlanır, “her ihtimale karşı” tutulan yedek yıllarca durur.
• Kişisel kolaylık. Bir çalışan evden çalışmak ya da bir işi hızlandırmak için veriyi kendine e-postayla gönderir veya bir USB belleğe kopyalar. Bu kopya kurumun hiçbir kaydına düşmez.
• Kapatılan proje. Proje biter, ekip dağılır, ama paylaşım klasörü ve içindeki veri olduğu yerde kalır.

Beşinin de ortak yanı, kopyanın meşru bir ihtiyaçtan doğmasıdır. Bu yüzden çözüm kopyayı yasaklamak değildir: yasak ihtiyacı ortadan kaldırmaz, yalnızca kaydını ortadan kaldırır. Önlemin nereye konacağını son bölümde ele alıyoruz.

Sahada: Dosya Sunucusunda Ne Çıkar?

Şimdi bunu lafta bırakmayıp bir dosya sunucusunda arayalım. Aşağıdaki ölçüm, laboratuvar ortamındaki bir Windows Server sunucusunda yapıldı. Sunucuya, gerçek bir kurumda görülene benzer biçimde dağılmış veri kopyaları yerleştirdim: bir müşteri listesi dışa aktarımı, bir maaş yedeği, bir CRM veritabanı yedeği ve bir kullanıcının masaüstündeki iletişim listesi. Bir de güncel, yerinde bir bordro dosyası koydum; taramanın onu ayırt edip etmediğini görmek için.

Beklenti, Ölçüm, Sonuç

Bu noktada sahada verilen standart cevap şudur: “asıl veritabanı korunuyor, o hâlde veri güvende.” Bu cevap veritabanı için doğru, ama sorduğu soru eksik. Sunucuyu isim, uzantı ve içerik desenleriyle taradım; hangi dosyanın kişisel veri taşıdığını ve ne kadar eski olduğunu birlikte çıkardım.

Dosya                                            Yas     Icerik
\IK\Eski_Projeler\personel_maaslar_yedek.xlsx    4.8 yil
\Kullanicilar\ayse\Masaustu\iletisim_listesi.csv 0 yil   e-posta
\Muhasebe\bordro_subat.xlsx                      0 yil
\Muhasebe\musteri_listesi_export_2023.csv        3.2 yil TC,IBAN
\Ortak\Gecici\crm_veritabani_yedek_2022.bak      4.5 yil

Bu beş satırda bakılacak üç şey var:

1. Icerik sütunu, kopyanın ne taşıdığını söyler. musteri_listesi_export_2023.csv satırında TC,IBAN yazıyor: yani korunan veritabanının dışında, üç yıllık bir Excel dosyasında aynı kişisel veri duruyor. Bu tek satır, “veritabanı güvende” cevabının neden eksik olduğunu gösterir.
2. Yas sütunu, “geçici”nin ne kadar kalıcı olduğunu söyler. crm_veritabani_yedek_2022.bak dosyası Gecici adlı bir klasörde ama dört buçuk yıllık. Adı geçiciydi, kimse silmedi.
3. Güncel dosya elendi. bordro_subat.xlsx ismiyle desene takıldı ama içeriğinde kişisel veri kalıbı çıkmadı ve tazeydi; tarama isimle eşleşeni körü körüne suçlamıyor, içerik ve yaşla eliyor.

Asıl öğretici nokta, “sunucuda eski dosyalar var” değil. Asıl nokta, bu dosyaların envanterde olmamasıdır: kurum veritabanını sayar ve korur, ama bu dört kopyanın hiçbiri o listede yoktur. Onları korumak bir yana, var olduklarını bilen bile yok. Saldırı yüzeyi tam da bu yüzden envanterden büyüktür.

Nasıl Tespit Edilir? Veriyi Değil, Kopyalarını Aramak

Gölge veriyi bulmanın yolu, aradığınız şeyi değiştirmekten geçer. Korunan veritabanını denetlemek onu bulmaz, çünkü sorun zaten orada değildir. Onu kopyaların izini süren bir tarama bulur ve bu taramanın üç ayrı süzgeci vardır.

Birincisi isimdir: yedek, backup, export, kopya gibi kelimeler ve musteri, personel, maas gibi hassas içeriğe işaret eden adlar. İkincisi uzantıdır: veri taşıyan biçimler, yani .bak, .sql, .csv, .xlsx, .pst gibi. Üçüncüsü ve en belirleyicisi içeriktir: dosyanın içinde TC kimlik numarası (\d{11}), IBAN (TR ile başlayan) ya da e-posta kalıbı var mı? PowerShell ile bu üçünü birlikte uygulayan bir tarama şöyle kurulur:

$riskIsim = 'yedek|backup|export|musteri|personel|maas|liste|crm|kopya'
$riskUzanti = '\.(bak|sql|csv|xlsx|xls|mdb|accdb|pst)$'
Get-ChildItem 'C:\DosyaSunucusu' -Recurse -File | ForEach-Object {
  if ($_.Name -notmatch $riskIsim -and $_.Name -notmatch $riskUzanti) { return }
  $icerik = Get-Content $_.FullName -Raw -ErrorAction SilentlyContinue
  $bulgu = @()
  if ($icerik -match '\b\d{11}\b')   { $bulgu += 'TC' }
  if ($icerik -match 'TR\d{2}\d{4}') { $bulgu += 'IBAN' }
  if ($icerik -match '@\w+\.\w+')    { $bulgu += 'e-posta' }
  [PSCustomObject]@{
    Dosya  = $_.FullName
    Yas    = [int]((Get-Date) - $_.LastWriteTime).TotalDays
    Icerik = $bulgu -join ','
  }
} | Sort-Object Yas -Descending | Format-Table -AutoSize

Bu tarama, benim sahada kullandığım basit hâlidir; onu bir standart diye değil, kendi denetiminizi kurarken başlangıç noktası diye alın. Büyük ve çok sunuculu ortamlarda bu işi ölçekleyen ticari veri keşfi (data discovery) ve veri sınıflandırma araçları var ve yerleri var. Ama tespitin özü bir üründe değil, sorunun kendisinde: veritabanına değil, ondan çıkmış kopyalara bakmak. Bir araç almadan önce, elinizdeki sunucuda bu soruyu sorabildiğinizi bilmek işe yarar.

Gerçek bir .xlsx dosyasının ikili olduğunu, yani içeriğinin düz metin gibi okunamayacağını da eklemek gerekir: canlıda içerik taraması bu biçimlerden metni çıkaran bir adım ister. Lab’da bu ayrıntıyı sadeleştirdim; buradaki amaç aracın kendisi değil, hangi soruyu sorduğunuzun değişmesidir.

Nasıl Önlenir? Her Kopyaya Bir Son Kullanma Tarihi

Gölge veriyi tespit etmek, onu bir daha doğmayacak hâle getirmez. Kalıcı çözüm, kopyanın hiç envanter dışına düşmemesini sağlayan disiplindedir ve üç ayağı vardır.

Birincisi son kullanma tarihidir. En etkili önlem teknik değil usuldür: bir yedek, bir dışa aktarım ya da bir paylaşım oluşturulurken, aynı anda ne zaman silineceğinin de yazılması. Tarihi olmayan geçici kayıt, kalıcı kayıttır; ve bu tarih KVKK’nın da istediği şeydir, çünkü KVKK teknik uyum yazımızda ele aldığımız saklama ve imha yükümlülüğü tam olarak budur: amacı biten veri silinir.

İkincisi veri sınıflandırmadır. Her veri aynı hassasiyette değildir; hangi verinin nereye kopyalanabileceği, hangisinin hiç kopyalanamayacağı önceden belirlenirse, “bir kereliğine” alınan kopyaların çoğu baştan doğmaz. Bu, ISO 27001’in bilgi varlıklarının sınıflandırılmasını ayrı bir kontrol olarak saymasının da sebebidir.

Üçüncüsü düzenli tarama, yani yukarıdaki keşfin periyodik çalıştırılmasıdır. İzinler gibi kopyalar da bir kez temizlenmekle temiz kalmaz; her yeni proje, her yeni rapor yeni kopyalar doğurur. Meşru bir yedekleme düzeni ile envanter dışı kopya yığını arasındaki farkı da burada çizmek gerekir: planlı, kayıtlı ve süreli bir yedek veri yedekleme ve felaket kurtarma disiplininin parçasıdır; tarihi ve sahibi olmayan bir kopya ise gölge veridir. İkisini ayıran şey dosyanın kendisi değil, arkasındaki kayıttır.

DLP: Kopyanın Çıkışını Durduran Katman

Bu üç ayak elle yürütülür; onları teknolojiyle otomatikleştiren kontrol kategorisinin adı DLP’dir (Data Loss Prevention, veri sızıntısı önleme). DLP, verinin kurumdan çıktığı noktaları izler: bir e-posta eki, bir USB bellek, bir bulut yükleme, bir yazıcı. Sınıflandırılmış hassas bir verinin bu kapılardan geçmeye çalıştığını gördüğünde kural bazlı olarak durdurur, uyarır ya da kaydeder.

DLP ile tarama birbirini tamamlar, biri ötekinin yerine geçmez. Tarama zaten dağılmış kopyaların haritasını çıkarır; DLP yeni kopyaların çıkışını engeller. İkisi de aynı ön koşula bağlıdır: sınıflandırma. DLP, neyin hassas olduğunu bilmeden neyi durduracağını da bilemez; sınıflandırma yapılmadan hem tarama hem DLP yarı kör çalışır.

Bir sınırını baştan söylemek gerekir, çünkü DLP çoğu zaman sihirli değnek diye anlatılır: her sızıntıyı yakalamaz. Şifreli bir arşiv, ekran görüntüsü alınmış bir tablo ya da hiç sınıflandırılmamış bir kopya onu kolayca atlatır. DLP güçlü bir katmandır, ama sınıflandırma ve tarama disiplininin üstüne kurulur, onların yerine geçmez.

Nasıl çalıştığını, verinin üç hâlinde nerede durduğunu, policy’nin hangi sırayla yayılacağını ve meşru veri çıkışı olan kişilere nasıl yol açılacağını DLP rehberimizde ayrıntısıyla anlattık. Bu katmanı izleme döneminden başlayarak kurduğumuz işi DLP çözümü sayfamızda yazdık.

Sonuç: Gölge Veri Kopyaların İzini Sürmekle Bulunur

Shadow Data, yeni bir tehdit değil, eski bir alışkanlığın adıdır: veriyi bir kez kopyalayıp izini kaybetmek. Kurumlar korumayı üretim sistemine yığar, çünkü envanterde o vardır. Oysa aynı veri, ondan çıkmış onlarca kopyada da yaşar ve o kopyalarda korumanın hiçbiri yoktur.

Bu yüzden doğru soru “veritabanımız güvende mi?” değil, “bu verinin kaç kopyası, nerede, ne kadar korumasız duruyor?” sorusudur. İlkini bir güvenlik denetimi cevaplar; ikincisini yalnızca kopyaların izini süren bir tarama. Aradaki fark, düzenli bir ofis arşivi ile listesi kimsede olmayan bir kiralık depo arasındaki farktır: birini yönetirsiniz, ötekini yönetmek için önce orada olduğunu bilmeniz gerekir.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn