Ana sayfa/Egemenlik
Bölge sabitleme bir arayüz filtresi değil, sunucu tarafında zorunlu bir kontroldür. Bu sayfa o kontrolün nasıl işlediğini, hangi hukuki çerçeveye oturduğunu ve bugün ne kadarının yazılmış olduğunu anlatır.
Bu metin açıklayıcıdır, hukuki metin değildir. Bağlayıcı metinler /yasal/ altında toplanır.
İcra
Bir kısıt yalnızca arayüzde duruyorsa, kısıt değildir: doğrudan API'ye istek atan biri onu atlar. Bu yüzden bölge sabiti pod yaratma yolunun içindedir.
Organizasyonun bölge tercihi ilk kurulumda belirlenir (örneğin AB + TR). Bu bir kullanıcı ayarı değil, organizasyonun kaydına yazılan bir kısıttır.
Arama region_group ve country_codes ile süzülür. Bu adım kolaylık içindir; güvenlik sınırı değildir ve tek başına bir garanti sayılmaz.
Sabitin dışındaki bir teklife pod isteği geldiğinde istek reddedilir: 400 · invalid_argument · region_pin_violation. Konsoldan mı, CLI'den mi, ham curl ile mi geldiği fark etmez.
Her pod, bölge sabiti bilgisini kendi gövdesinde taşır: sabitlenmiş mi, hangi bölgeye, hangi notla. Denetim sorusuna ekran görüntüsüyle değil, kayıtla cevap verilir.
# Organizasyon sabiti: eu_tr # İstek: sabitin dışında bir teklif (örnek) POST /v1/pods { "offer_id": "provider-us-west-4090" } 400 Bad Request { "error": { "code": "invalid_argument", "reason": "region_pin_violation", "message": "Bu teklif organizasyonun bölge sabitinin dışında.", "details": { "pin": "eu_tr", "offer_country": "US" } } } # Konsol bu sebebi görünce KVKK/GDPR # açıklamasıyla birlikte gösterir.
Bölgeler
Hedeflenen bölge listesi aşağıdadır. Faz 0'da arz üçüncü taraf sağlayıcıların API'lerinden gelir; kendi host ağımız Faz 1'de devreye girer. Yani bugün bir bölgeyi seçebilmen, o bölgede o an makine bulunduğu anlamına gelmez — havuzun gerçek durumu konsolda görünür.
Bölge grubu API'de tek parametredir; aynı kısıt konsolda, CLI'de ve ham HTTP isteğinde aynı şekilde uygulanır.
Hukuki çerçeve
Aşağıdakiler mevzuatın ürüne yansıması; birer taahhüt metni değil, tasarım kararlarının gerekçesidir.
Türkiye'deki kişisel verinin yurt dışına aktarımı kurallı bir iştir. TR bölge sabiti, iş yükünün ve kalıcı diskin Türkiye'de kalması için vardır; kimlik verisi de kendi altyapımızda, ABD merkezli bir kimlik hizmetinde değil tutulur.
AB bölge sabitinde veri AB içinde işlenir. Veri işleyen sıfatıyla yükümlülüklerimiz — talimatla işleme, alt işleyici şeffaflığı, ihlal bildirimi, silme ve taşıma hakkı — sözleşme metnine bağlanacak.
Altyapı sağlayıcısı olarak modeli biz sağlamıyoruz; hesaplama kaynağı sunuyoruz. Yükümlülüğün büyük kısmı model sağlayıcı ve dağıtıcıdadır, ama hangi bölgede hangi iş yükünün koştuğunun kaydı senin dosyanın parçasıdır — o kaydı üretiyoruz.
DPA ve alt işleyiciler
DPA, veri sorumlusu (müşteri) ile veri işleyen (Kaldera) arasındaki sınırı yazar: neyi hangi talimatla işleriz, ne kadar saklarız, ihlalde kaç saat içinde haber veririz, sözleşme bitince veriyi nasıl iade eder ya da imha ederiz. Şirket kurulup metin hukukçuyla tamamlanınca yasal metinler altında yayımlanacak ve kurumsal müşteriyle imzalanacak.
Alt işleyici, bizim adımıza veriye dokunan üçüncü taraftır: kontrol düzleminin barındığı sağlayıcı, ödeme kuruluşu, e-posta servisi ve iş yükünün koştuğu GPU sağlayıcıları. Kural şu olacak: liste kamuya açık tutulur, değişiklikten önce haber verilir, itiraz hakkın sözleşmede yazılı olur. Bugün yayımlanmış bir liste yok — çünkü henüz imzalanmış bir sözleşme de yok.
Planlanan yığın teknik planda açıkça yazılıdır: kontrol düzlemi AB'de barındırılacak, kimlik kendi veritabanımızda tutulacak, arz tarafında AB tüzel kişilikli sağlayıcılara öncelik verilecek. Bunlar yığın kararlarıdır; imzalanmış tedarikçi sözleşmesi değildir.
Yapısal fark
ABD CLOUD Act, ABD hukukuna tabi bir hizmet sağlayıcının elinde bulundurduğu veriye ilişkin talep alabilmesini düzenler. Buradaki belirleyici unsur verinin fiziksel olarak hangi ülkede durduğu değil, veriyi elinde bulunduran tüzel kişinin hangi hukuka tabi olduğudur. Bu yüzden "sunucu Frankfurt'ta" cümlesi tek başına bir cevap değildir; sorunun tamamı şudur: bu veriye erişebilen şirket kimin hukukuna tabi?
Kaldera'nın hedeflediği yapı bu soruya AB ve Türkiye tüzel kişilikleriyle cevap vermek üzerine kurulu. Dürüst olmak gerekirse bugünkü tablo şu:
Karşılaştırma yaparken yalnız yapısal ve herkesin doğrulayabileceği farkları anlatırız: bir sağlayıcının tüzel kişiliğinin nerede olduğu, verinin hangi bölgede işlendiği, bölge kısıtının sunucu tarafında mı yoksa yalnız arayüzde mi uygulandığı. Rakip hakkında doğrulanamayan olumsuz iddia bu sitede yer almaz.
Veri taşıma ve silme
Kilitlenme bir iş modeli değil. Verini alman ve silmen, açman kadar az adım olsun diye tasarlandı.
Kalıcı diskler S3 uyumlu, standart araçlarla okunabilir biçimde tutulur; checkpoint'lerini ve çıktılarını özel bir biçime çevirmeden dışarı alırsın. Fatura kalemleri de API'den okunur — muhaseben ekran görüntüsüne mahkûm değil.
Pod'u sonlandırırken ?delete_volume=1 dersen kalıcı disk de silinir. Hesap kapatmada tüm iş yükü verisinin silinmesi ve saklama sürelerinin yazılı olması DPA'nın konusu olacak.
Bütçe tavanı ya da bakiye nedeniyle duraklayan pod'un diski ne kadar süre ücretsiz saklanır? Taslak politika 7 gün ücretsiz, sonrasında depolama ücreti ve 30 gün sonunda bildirimle silme yönünde — ama karar kesinleşmedi, o yüzden burada "kesin" diye yazmıyoruz.
Bu sayfa açıklayıcı bir metindir; hukuki bağlayıcılığı yoktur. Bağlayıcı metinler — kullanım şartları, gizlilik ve KVKK aydınlatması, mesafeli satış — yasal bölümde yayımlanır ve çelişki hâlinde onlar geçerlidir.
Karar senin
Verinin sınırı sunucu tarafında korunur; faturanın sınırını da sen koyarsın. Çalışmayan saniyeye para yok, sert bütçe tavanı, saniye bazlı fatura.