Veri ikametini (data residency) ayarla ve doğrula

Moonborn organizasyon sınırında bölgeseldir. Bir organizasyon bir bölgeye aittir; organizasyon içindeki her çalışma alanı, persona, sohbet transkripti, denetim kaydı ve vektör (embedding) o bölgede kalır. Bölge kayıtta seçilir ve kilitlenir (ADR 0011) — sonradan değiştirilemez. Bölgeler arası okuma veritabanı sınırında engellenir, politika kontrolünde değil.

Bu rehber bölgeni doğrular, bölgeler arası erişimin ne anlama geldiğini netleştirir, GDPR / HIPAA gibi uyumluluk gereksinimlerini bölgeye eşler ve iş ihtiyacın değiştiğinde — örn. AB müşterisi eklemen gerekirse — temiz bir geçiş akışını gösterir.

Bu rehberi bitirdiğinde

• Organizasyonunun hangi bölgede olduğunu API ve arayüzden doğrulayabileceksin.
• Bölgeler arası okumanın fiziksel olarak nasıl engellendiğini bileceksin.
• GDPR, HIPAA gibi gereksinimleri doğru bölgeye eşleyebileceksin.
• Bölge değiştirmen gerektiğinde dışa aktar → yeni organizasyon → içe aktar akışını izleyebileceksin.
• "Bölge uçuş sırasında (in-flight) değişmez" kuralının arkasındaki tasarım kararını anlayacaksın (ADR 0011).

Ön koşul: Bir Moonborn hesabı + API anahtarı. Geçiş akışını planlıyorsan SSO / SCIM kurulumunu da gözden geçir (SSO + SAML kurulumu, SCIM hazırlama).

1. Organizasyon bölgeni doğrula

const org = await client.organizations.getCurrent();
console.log(org.region); // 'us' | 'eu'
console.log(org.regionLockedAt); // ISO zaman damgası

Arayüzde: Settings → Organization → Region.

2. Bölgeler arası okuma engellemesi nasıl çalışır

Bölgeler arası erişim politika kontrolünde değil, veritabanı sınırında engellenir. Bu önemli bir ayrımdır:

Kod yolu bir IF bloğu ile bölgeyi kontrol eder.
Hata, yanlış yapılandırma veya bypass mümkün.

Pratik sonuç: bir AB bölgesi API anahtarı doğru RBAC ile bile ABD verisini sorgulayamaz — yapısal olarak erişemez.

# AB anahtarıyla ABD bölgesinin API temel URL'ine istek
curl https://api.us.moonborn.co/v1/personas/per_us_... \
  -H "Authorization: Bearer sk_live_eu_..."
 
# 403 cross_region_blocked

3. Uyumluluk → bölge eşlemesi

İki bölgede de müşteri varsa

Eğer aynı şirket hem AB GDPR koruması altındaki kullanıcılara hem de ABD HIPAA gerektiren kullanıcılara hizmet edecekse, bölge başına bir organizasyon açmak en temiz yoldur:

org_acme_eu   → çalışma alanları, AB persona'ları, AB denetim kaydı
org_acme_us   → çalışma alanları, ABD persona'ları, ABD denetim kaydı (HIPAA BAA)

Faturalama kökleri ayrı, denetim kayıtları ayrı, fiziksel veritabanı ayrıdır. SSO / SCIM iki organizasyona da bağlanır — IdP grupları her iki tarafa ayrı rol atayabilir.

4. Bölge geçişi

Bölge değişimi uçuş sırasında (in-flight) desteklenmez. AB müşterisi eklemek için AB organizasyonu açar, ABD organizasyonundaki ilgili veriyi dışa aktarıp içe aktarırsın.

Geçiş akışı

1. Eski organizasyonda dışa aktarma başlat
2. Hedef bölgede yeni organizasyon aç
3. Dışa aktarımı yeni organizasyona içe aktar
4. SSO / SCIM uç noktalarını yeni organizasyona yönlendir
5. Eski organizasyonu hizmetten al (audit saklama süresi sonunda)

// 1. Dışa aktarım (eski ABD organizasyonunda)
const exportJob = await client.privacy.exports.create({
  orgId: oldOrg.id,
  scope: 'org',
});
// hazır olana kadar yokla, sonra arşivi indir
 
// 2. Yeni AB organizasyonuna kaydol (arayüzden veya API'den)
const newOrg = await client.organizations.create({ region: 'eu' });
 
// 3. İçe aktarım (yeni AB organizasyonunda)
await client.privacy.exports.import({
  orgId: newOrg.id,
  archive: exportArchive,
});
 
// 4. SSO / SCIM uç noktalarını güncelle
await client.config.setItem({
  key: 'identity.sso.saml.idp_metadata_url',
  value: '...',
  scope: 'org',
  scopeId: newOrg.id,
});

Uçuş sırasında geçiş neden yok (ADR 0011)

Bir organizasyonu "yarı ABD, yarı AB" yapmaya çalışmak iki şeyi kırar:

1. Tutarlılık akıl yürütmesi (consistency reasoning) — iki bölge arasında işlemler (transactions), replikasyon gecikmesi (replication lag), çakışma çözümleme (conflict resolution) gereksinimi çıkar. Veritabanı sınırının (database boundary) sertliği kaybolur.
2. "Bölge organizasyonun bir özelliğidir" değişmezi (invariant) — kod tabanı boyunca bölgeyi yalnızca kayıt-anı veri olarak kullanan binlerce sorgu vardır; bu değişmezi kaybetmek çalışma zamanı riski demektir.

ADR 0011 bu nedenle uçuş sırasında geçiş yerine kontrollü dışa-aktar-içe-aktar akışını zorunlu kılar.

5. Doğrulama sonrası eski organizasyonu kapat

Yeni organizasyon canlıyken eski organizasyonu hemen hizmetten alma — denetim kaydı saklama süresi (Pro / Team 1, Enterprise 7 yıl) eski tarafa hâlâ uygulanır. Pratik adımlar:

1. Yeni organizasyonda bir hafta boyunca tüm trafiği gözle (drift zarfı, denetim kaydı, webhook gönderimlerinin normal akışta olduğunu doğrula).
2. Eski organizasyonda SSO / SCIM uç noktalarını kapat — yeni kullanıcı hazırlama (provisioning) tamamen yeni tarafa gider.
3. Eski organizasyonu salt-okunur moda al (status: 'archived'); yeni veri yazımı durur, mevcut veri okunabilir kalır.
4. Denetim saklama süresi dolduğunda eski organizasyon tamamen silinir veya dışa aktarımını çevrimdışı arşivlersin.

Plan gereksinimi

• ABD / AB seçimi: her plan (varsayılan ABD, kayıtta arayüzden değiştirilebilir).
• Bölge kilitleme zorunluluğu: her plan.
• AB ikameti sözleşmesel garantiler (DPA, işleyici sözleşmeleri): Enterprise.

İlgili