Veri yurt dışındaki sunucuda durabilir mi: ilk soru sunucuya değil kayda sorulur

Yurt dışı sunucu sorusunun hukuki adı kişisel verinin yurt dışına aktarımıdır; ilgili hüküm makinenin adresini değil, bir kişiye bağlanan kaydı konu alır. Cevabın ilk yarısı hukuk metninde değil kayıt tasarımında duruyor; toplanmayan bir alanın gideceği ülke yoktur. SsangYong showroom kioskunda kimlik adımı bulunmuyor; ziyaretçiye ait kayıt hiç oluşmadığı için envanterin o satırı boş kalıyor.

Sorunun hukuki adı aktarımdır; hükmün öznesi sunucu değil bir kişiye bağlanan kayıttır

Soru masada hemen her zaman aynı biçimde kurulur: sunucumuz nerede olmalı. Kanun’un yurt dışına aktarım hükmü ise makinenin adresini değil, kişisel verinin aktarılmasını düzenliyor. Kurum’un konuya ayırdığı sayfa da aynı dili konuşuyor; sayfanın hiçbir yerinde sunucudan, barındırmadan ya da verinin nerede saklandığından söz eden bir cümle geçmiyor. Bir makineyi başka bir ülkede çalıştırmanın o hükmün karşısında ne anlama geldiğini bu yazı söylemiyor; soruyu adlandırıyor, cevabını kaynağa ve hukukçunuza bırakıyor.

Yazılım ekibinin bu noktada yapabileceği bir iş var, ama o iş cevap vermek değil. Ekip, sorunun ön koşulunun sağlanıp sağlanmadığını gösterebilir: ortada bir kişiye bağlanan kayıt var mı, yok mu. Yoksa sorunun konusu da yok demektir. Varsa soru gerçektir ve bir sonraki bölümün konusuna dönüşür. Bu, hukuki bir değerlendirme değil olgusal bir tespittir; ekranın kodu okunarak, veri modeline bakılarak yapılır.

Karşıt örnekler portföyümüzde yan yana duruyor. Bir mağaza ekranında ziyaretçiden hiçbir şey alınmıyor; ekranın gösterdiği şey markanın kendi ürün bilgisi. Bir sağlık platformunda ise hasta kendi tahlil değerini giriyor, hekim yorumunu yazıyor; orada kayıt hizmetin kendisi. Aynı soruyu iki sisteme birden sorarsanız birinden boş bir satır, ötekinden dolu bir envanter çıkar. Soru aynı, cevabın uzunluğu farklı.

Bu hat yeni değil. İşletmenin kendi çalışanı için kayıt tutulurken de aynı yerden geçiyor ve o tarafını çalışan takibinde yazılımın nerede durduğunu anlattığımız yazıda ayrıca yazmıştık.

Kaydınız bir kişiye bağlanıyorsa bu bölüm hiçbir şeyi çözmez. Yaptığı tek şey soruyu doğru adıyla masaya koymak ve olduğu gibi devretmektir.

Rejim sırayla okunur: önce yeterlilik kararı, yoksa uygun güvence, o da yoksa arızi hâl

Okur bu noktada net bir evet ya da hayır bekler. Rejim öyle kurulmamış. Sıralı bir okuma istiyor ve hangi sıradaki sorunun size düştüğünü bilmeden sağlayıcınızla pazarlığa bile oturamazsınız, çünkü ondan isteyeceğiniz belge sıraya göre değişiyor.

Sıra şöyle işliyor. Önce aktarımın yapılacağı ülkenin, Kurul tarafından yeterli korumanın bulunduğu ülke olarak ilan edilmiş olup olmadığına bakılıyor. İlan varsa okuma orada bitiyor. Yoksa sıradaki soru geliyor: taraflar arasında uygun bir güvence var mı. Güvencenin biçimleri sayılı ve kaynakta adlarıyla duruyor: standart sözleşme, Kurul’un onayladığı bağlayıcı şirket kuralları, yeterli korumayı yazılı olarak taahhüt eden bir metin ve buna eklenen Kurul izni, kamu kurumları arasında yapılan bir anlaşma ve yine izin. O da yoksa geriye Kanun ve Yönetmelik’te “sınırlayıcı biçimde” sayılan arızi hâller kalıyor. İbare kaynağın kendi ibaresi ve bir şey söylüyor: bu hâller genişletilerek okunacak bir liste değil.

Hangi ülkelerin ilanı aldığını burada yazmıyoruz. Böyle bir liste zamanla değişir ve doğrulanmamış bir liste okuru sağlayıcı toplantısına yanlış bir kesinlikle sokar. Listeyi Kurul’un kendi ilanından okuyun; rejimin tamamı da Kurum’un yurt dışına aktarım sayfasında duruyor.

Bir ayrım burada sık karışıyor ve karıştığında yanlış merciye yazı yazılıyor. Standart sözleşme metinlerini kabul eden merci Kurul’dur. Siz o metni yurt dışındaki sağlayıcınızla imzaladığınızda ise karşınızdaki merci Kurum olur. İkisi ayrı mercilerdir. Karar tarihi, karar numarası ve imzalanan metnin nasıl bildirileceği gibi ayrıntılar aynı kaynakta yazılı; onları buradan değil oradan okuyun. Bu yazının işi rejimi tarif etmek, sizin durumunuzu sınıflandırmak değil.

Yazılım ekibinin bu sıraya katkısı dolaylı ama gerçek. Güvence yoluna girdiğinizde sağlayıcınızla konuşacağınız şey soyut bir güvenlik vaadi değil, hangi kaydın hangi alanlarla gittiğidir; o konuşmayı mümkün kılan şey envanterdir. Envanter yoksa konuşma sağlayıcının tanıtım metniyle sınırlı kalır ve sizin tarafınızdan sınanamaz. Sıranın neresinde olursanız olun elinizde duran liste aynı listedir.

Sıranın pratik faydası şu: sağlayıcıdan ne isteyeceğinizi belirliyor. İlan zaten varsa sağlayıcıdan ek bir belge istemezsiniz. İlan yoksa imzalanabilir bir güvence metni istersiniz. Güvence de kurulamıyorsa konu bir yazılım kararı olmaktan çıkmış, tamamen hukukçunuzun masasına geçmiştir.

Sunucu tek bir yer değildir: isteğin hangi parçası sınırı geçiyor

Sağlayıcı sözleşmesinde tek bir makine adresi yazar ve o adres çoğu zaman konuyu kapattığı sanılan cevabı üretir: sunucumuz Türkiye’de. Cevap o tek makine için doğru olabilir, isteğin tamamı için nadiren doğrudur. Bir web formunun tek bir gönderiminde birbirinden bağımsız birkaç adım çalışır ve her adım kendi adresine uğrar. Envanteri kapatan şey bu adımların listesidir.

Kendi teklif formumuzun kodu bu satırları görünür kılıyor. Bot doğrulamasının meydan okuması kendi sunucumuzda üretiliyor: rastgele bir tuz ve rastgele bir sayı seçiliyor, özeti alınıyor, kendi anahtarımızla imzalanıyor; tarayıcı sayıyı kendisi arıyor. Bu adımda dışarıya hiçbir istek çıkmıyor. Çözüm geri geldiğinde karşılaştırma da aynı sunucuda yapılıyor ve çözüm tek kullanımlık; kullanıldığına dair işaret, internete kapalı özel bir dizine yazılıyor. Dizin yoksa ya da yazılamıyorsa istek reddediliyor, sessizce geçirilmiyor. Envanterde bu satır boş kalıyor, çünkü satırın gideceği bir dış adres yok.

Yüklenen dosya da internete kapalı özel bir dizinde duruyor. Form kodu, hedef dizinin web kökü içinde olup olmadığına bakıyor; içindeyse o dizini internete kapatan bir sunucu kuralı arıyor ve bulamazsa çalışmayı reddediyor. Dizin ve dosya yalnız uygulama hesabının okuyabileceği izinle yazılıyor. Sıklık sayacı da aynı mantıkla, sembolik bağlantı izlemeyen bir dizinde tutuluyor ve depo yazılamadığında form duruyor. Form kaydı ise bir veritabanına hiç yazılmıyor; alanlar tek nüsha olarak bir e-posta gövdesine giriyor. Envanterin bu satırı “posta kutusunun barındığı yer” diye açılır ve o yer ayrıca sorulur; o yerin neresi olduğunu sizin envanteriniz yazar.

Buradan çıkan biçim genel. Envanteriniz doğrulama, dosya ve bildirim satırlarını ayrı ayrı taşımalı, çünkü aynı istekte çalışan bu adımlar farklı adreslere uğrayabiliyor. Portföyümüzdeki sağlık platformunun hasta uygulamasında bildirimi teslim eden servis dışarıda duruyor; telefonun neden ayrı bir yüzey olarak sayıldığını mobil uygulama ile mobil siteyi karşılaştırdığımız yazıda yazmıştık.

Aynı ayrım kendi yazmadığınız parçalar için de geçerli. Bir istek kendi kodunuzdan çıkıp bir dış servise uğradığında, o servis kimin makinesinde koşuyorsa satır oraya yazılır. Bu satırın var olup olmadığını sözleşme metninden değil koddan okursunuz: istek nereye gidiyor, cevabı kim üretiyor, hangi alan gövdeye giriyor. Envanteri çıkaran ekip bu yüzden mimari şemayla yetinmez, çağrıların kendisini de gözden geçirir.

Tek makinenin adresi doğru olabilir ve envanteri yine kapatmaz. Kapatan şey, isteğin uğradığı her servisin ayrı bir satır olarak yazılmasıdır.

Yurt dışı sunucu sorusunun çıkıp çıkmaması kaydın türüne bağlı

Envanteri çıkarmanın en hızlı yolu, kayıtları tek torbada görmeyi bırakmak. Aynı sistemde bazı satırlar bu rejimin sorusunu hiç doğurmuyor, bazıları doğuruyor, bazıları da dış bir servise çıktığı için kendi başına bir satır oluyor. Aşağıdaki tablo portföyümüzden ve kendi teklif formumuzun kodundan alınan kayıt türlerini yan yana koyuyor. Sütunlar sırayla şunu soruyor: kayıt bir kişiye bağlanıyor mu, sunucu yurt dışındaysa hangi soru doğar, o soruyu kim cevaplar. Son sütun tabloyu kullanışlı yapan sütun; bir satırın cevabı “kimse” ise o satır hukukçunuza hiç gitmez.

Tablonun kiosk satırları aynı cihazda duruyor ve ayrı şeyler söylüyor. Biri içeriğin kişisel veri olmadığını, öteki kullanım kaydının hiç oluşmadığını. Tek satıra indirilirse karşı desen kaybolur: bir sistemde soru yalnız içerik masum olduğu için değil, ölçüm kaydı hiç tutulmadığı için de doğmayabilir.

Tabloyu kendi sisteminiz için doldurmanın yolu aynı. Kayıt tiplerini adlandırın, her birinin yanına bir kişiye bağlanıp bağlanmadığını yazın, bağlananlar için makinenin ülkesini arayın, dış servise çıkan parçaları ayrı satır yapın. Boş çıkan satırları da listede tutun. Boş satır, o kaydın hiç oluşmadığının yazılı kanıtıdır ve hukukçunuzun sormasına gerek kalmadan cevabı verir.

Kioskta aktarılacak veri yok, bu yüzden rejimin ilk sorusu bile sorulmaz

Rejimin ilk sorusu, ortada aktarılacak bir kişisel veri bulunduğunu varsayar. Bazı sistemlerde o varsayım hiç kurulmuyor ve bunun mimari bir sebebi var.

KGM SsangYong showroom kiosku bu durumun portföyümüzdeki en net yüzü. Araç gamı ve donanım paketi bilgisi mağazanın dokunmatik ekranında duruyor. Ekranın önünde kimlik adımı yok. İndirme adımı yok, hesap açma adımı yok, kişisel veri toplayan bir alan yok. Ziyaretçiye ait bir kayıt hiç oluşmuyor. Envanterde bu sistemin ziyaretçi satırı boş kalıyor ve boş satır bir eksiklik değil, ekran kurulurken verilmiş bir tasarım kararının sonucu.

Akışın yönü de bunu doğruluyor. Cihaza dışarıdan yalnız içerik güncellemesi iniyor: yeni model, değişen donanım listesi. Cihazdan dışarıya ziyaretçiye ait bir şey çıkmıyor. Sunucu yurt dışında olsa bile bu yönde taşınan şey markanın kendi kataloğu; rejimin sorduğu türden bir kayıt değil.

Karar kâğıttan gelen bir alışkanlığın yerine geçti. Basılı katalog ziyaretçiden bir şey istemez, ekran onun işini devralırken aynı sadeliği koruyabilir ya da koruyamaz. Hangi eşiğin korunduğunu basılı kataloğu ve menüyü yazılıma taşıma yazımızda ayrıca açtık. Aynı tercihin bir de ölçüm tarafı var: ziyaretçiye ait kayıt oluşmadığında elinizde ölçecek bir şey de kalmıyor ve bu bedeli satış öncesi hangi adımların self servise açılabileceğini tarttığımız yazıda yazmıştık. Bu yazı açısından anlamı şu: aynı karar hem ölçüm listesinde hem envanterde görünüyor.

Bu cevap bir tek ekleme kadar kırılgan. Aynı ekrana bir iletişim formu koyduğunuz an ziyaretçiye ait kayıt oluşur ve bu bölümün cevabı biter. Soru o anda bir sonraki bölümün sorusuna dönüşür ve envanterin boş satırı dolar.

Kayıt hizmetin kendisiyse soru gerçektir ve yazılım ekibinin işi envanterdir

Bazı işletmelerde kaydı hiç oluşturmamak bir seçenek değil, çünkü kayıt hizmetin kendisi.

Tahlil.com tam olarak böyle çalışıyor. Hasta kendi tahlil değerlerini giriyor, hekim yorumunu yazıp onaylıyor. Bu adımları çıkarırsanız geriye hizmet kalmıyor. Dolayısıyla yurt dışı sunucu sorusu burada gerçekten doğuyor ve mimari bir kaçış yolu sunmuyor. Yazılım ekibinin işi kaydı eksiksiz göstermek.

Gösterilecek şeyin adı envanter: hangi kayıt tutuluyor, hangi alanlarla, hangi sistem ya da servis üzerinden geçiyor, hangi ülkedeki makineye yazılıyor. Tek sayfa, sabit sütunlar. Hukukçunuz kanaatini bu sayfanın üstünde kuruyor ve sayfa eksikse kanaat de eksik kuruluyor. Envanterin işi ikna etmek değil, sormayı kolaylaştırmak.

Envanteri kısaltan şey mimari bir karar. Tahlil.com’da kayıt tek bir kayıt deposunda duruyor; hastanın girdiği değer de hekimin yazdığı yorum da aynı yere düşüyor. Kaç ayrı yüzeyden girilirse girilsin envanterde tek adres yazıyor. Yüzey başına ikinci bir veri modeli kurulsaydı aynı kayıt tipi envanterde birden çok satıra bölünür, her satır ayrı ayrı sorgulanır ve hukukçunun okuyacağı liste uzardı. Kayıt deposu kararı bu yüzden hukuki bir karar gibi görünmese de hukuki bir sorunun uzunluğunu belirliyor.

Envanterin baştan dolu gelen bir satırı da var. Bildirim hedefli olduğu için dış bir servisten geçiyor ve o servis, hastanın kaydıyla eşlenen bir cihaz anahtarını tutuyor. Bu satırın kendi soruları var: servisin makinesi nerede duruyor ve anahtarla birlikte hangi içerik gidiyor. İçerik sorusunun cevabı yazılım ekibinden gelir, çünkü bildirimin yükü koddadır. Anahtarın bir kişiye bağlanıp bağlanmadığını ise hukukçunuz değerlendirir.

Envanter bir kez çıkarılıp dosyalanan bir belge değil. Sisteme yeni bir alan eklendiğinde, yeni bir dış servis bağlandığında ya da bir yüzey daha açıldığında listenin ilgili satırı değişir. Değişmiyorsa liste sistemi değil, sistemin bir zamanki hâlini anlatıyor demektir.

Bu bölüm de hukuki bir kanaat vermiyor; yaptığı iş, hukukçunun soracağı listeyi o sormadan önce çıkarmak. Kayıt zorunluysa mimari cevap kaydı ortadan kaldırmak olamaz; olabileceği tek şey kaydı sayılabilir hâle getirmektir.

Kararı sunucu seçerken değil kaydı tasarlarken verirsiniz

Yurt dışı sunucu kararı genelde bir sağlayıcı seçim toplantısında konuşulur. O toplantı kararın verildiği yer değil, sonuçlarının sayıldığı yerdir. Asıl karar çok daha önce, kayıt tasarlanırken verilmiştir ve tek bir soruyla verilir: bu alan gerçekten gerekli mi.

Uçlar aynı portföyde duruyor. Mağaza ekranında ziyaretçiye ait hiçbir alan toplanmıyor, bu yüzden hiçbir alanın ülkesi sorulmuyor. Sağlık platformunda kayıt hizmetin kendisi, bu yüzden her alanın ülkesi soruluyor. Aradaki fark bir sağlayıcı sözleşmesiyle değil, ilk veri modeli çizilirken açıldı.

Bu, yazılımın sonradan düzeltilmesi kolay olmayan yanlarından biri. Bir alanı toplamaya başladıktan sonra toplamamayı seçmek formdan bir kutu silmekle bitmez; geçmiş kayıtları da kapsar. Kararların neden koddan önce verildiğini mimarinin önce geldiğini anlattığımız yazıda ayrıca yazdık.

Pratik sıra şu: önce kayıt listesi, sonra alan listesi, sonra hangi alanın bir kişiye bağlandığı, en sonda makinenin ülkesi. Bu sırayla çalışan bir ekip hukukçuya gittiğinde soru zaten daralmıştır. Ters sırayla çalışan bir ekip ise sağlayıcıyı seçtikten sonra hangi alanı neden topladığını araştırır ve o araştırmanın maliyeti sözleşme imzalandıktan sonra çıkar.

Hangi kaydın toplanmak zorunda olduğuna koddan önce karar verilir; bu kararların nasıl verildiğini sistem mimarisi sayfasında görebilirsiniz.