Şifreleme Kavramları

Üst düzey akış

• Bulutunuzda OpenAI’ın hiç görmediği bir ana anahtarı siz kontrol edersiniz

• Ana anahtarınız, OpenAI tarafından kullanılan veri şifreleme anahtarlarını (DEK’ler) şifrelemek için kullanılır

• OpenAI, bekleyen verilerinizi şifrelemek için DEK’leri kullanır. Bir DEK, ana anahtarınız tarafından şifrelenerek verilerinizle birlikte depolanan bir eDEK (şifrelenmiş DEK) oluşturur

• Verileri okumak için OpenAI eDEK’i alır, DEK’e çözmesi için KMS’nizden istekte bulunur ve ardından verilerinizin şifresini çözer

EKM şifrelemesi nasıl çalışır?

Ayrıntılı bilgi için lütfen makalemize bakın: OpenAI Enterprise Key Management (EKM) Genel Bakış

OpenAI DEK’lerimi depolar mı?

Hayır - KMS’niz tarafından oluşturulan şifrelenmiş DEK’leri (eDEK’ler) depolarız. Verilerin şifresini çözmek için KMS’nizden eDEK’i tekrar DEK’e çözmesini isteriz.

OpenAI DEK’lerimi önbelleğe alır mı?

Evet - yalnızca bellekte. Bunun nedeni, her veri şifreleme/şifre çözme isteğinde KMS’nize gitmemek için performansı artırmaktır. DEK’ler hiçbir zaman depolamaya yazılmaz.

Bulut İzinleri

OpenAI KMS’im üzerinde hangi izinlere sahip olacak?

Yalnızca ayarladığınız politika aracılığıyla bize verdiğiniz izinlere. En azından Encrypt/Decrypt işlemlerine ihtiyacımız var. Ayrıca, üretim amaçlı mevcut anahtarları yeniden kullanmak yerine OpenAI için bulut KMS’nizde yeni bir anahtar oluşturun.

OpenAI KMS’ime erişim izinlerini ne zaman alır?

Tüm bu adımlar atılmış olmalıdır: 1. OpenAI’ın kimliğini tanıdınız (bulut sağlayıcısına bağlı olarak güven politikası, iş yükü kimliği vb. yoluyla), 2. KMS’ye erişim için bir politika oluşturdunuz ve 3. OpenAI’ın kimliğine bu politikaya erişim izni verdiniz. Bu adımların tümünü atmadan yalnızca KMS’yi oluşturursanız, OpenAI erişim elde etmez.

Ana anahtarımı bulutumda depolamak zorunda mıyım?

Hayır - ana anahtarınızı nasıl yöneteceğiniz size kalmış. Bulut tarafından yönetilen bir çözümünüz olabilir veya anahtarınızın ayrı tutulduğu harici bir çözüm kullanabilirsiniz. OpenAI’ın yalnızca KMS’nizde encrypt/decrypt işlemlerini çağırması gerekir - ana anahtarın şifreleme/şifre çözmeyi gerçekte nasıl gerçekleştirdiği, bizim için görünmez olan bir uygulama ayrıntısıdır.

Anahtar Yaşam Döngüsü

DEK/eDEK Rotasyonu (OpenAI tarafından kontrol edilir)

DEK’ler/eDEK’ler ne sıklıkla döndürülür?

Şifreleme yolunda her 24 saatte bir (bir DEK/eDEK anahtar çifti istenirken)

Şifre çözme anahtarı yolu için her 1 saatte bir (DEK -> eDEK)

DEK değiştiğinde bir şey yapmam gerekir mi?

Hayır - DEK/eDEK rotasyonu OpenAI içinde yapılır. Ana anahtarınız geçerli kaldığı sürece, ana anahtarınızla şifrelenmiş tüm eDEK’ler DEK’e çözülebilir ve bu DEK daha sonra verilerinizin şifresini çözmek için kullanılır.

Ana Anahtar Rotasyonu ve İptali (Sizin tarafınızdan kontrol edilir)

Anahtar rotasyonu ve anahtar iptali ne sıklıkla gerçekleşir?

Bu, ana anahtarınız üzerinde görünürlüğü olmadığı için OpenAI tarafından değil sizin tarafınızdan belirlenir.

Anahtar rotasyonu ile anahtar iptali arasındaki fark nedir?

Anahtar iptali, eski anahtarlar kullanılarak şifrelenmiş verilere erişimi kaldırır. Anahtar rotasyonu ise verileri yeni bir anahtarla şifreler ancak eski verilere okuma erişimini korur.

Ana anahtarımı iptal edersem ne olur?

Bir anahtar iptal edilirse veya izinler kaldırılırsa, önbelleğe alınmış anahtarların süresi dolduğunda çalışma alanı sonunda işlevsiz hale gelir. Bu noktada OpenAI artık depolanan verilerin şifresini çözemez veya yeni verileri şifreleyemez. Fiilen veriler “parçalanmış” olur.

İptal ne kadar hızlı yürürlüğe girer?

OpenAI, performans ve dayanıklılık için DEK’leri bellekte önbelleğe alır. İptal, önbelleğe alınmış anahtarların süresi dolup yeniden doğrulama başarısız olduğunda genellikle bir saat içinde etkili olur.

İptal güvenli şekilde test edilebilir mi?

Mevcut verileri kalıcı olarak erişilemez hale getireceği için bir üretim çalışma alanında iptalin test edilmesi önerilmez. Ancak müşteriler, doğru davranışı doğrulamak ve güven varsayımlarını sınamak için bir sandbox ortamında iptali test edebilir (ve etmelidir).

Bir anahtar kalıcı olarak iptal edilirse, yeni bir anahtar eklenerek çalışma alanı kurtarılabilir mi?

Hayır. Anahtar bir kez kaybedildiğinde, tasarım gereği veriler geri getirilemez. Tek çözüm yeni bir çalışma alanı oluşturmaktır.

Bir çalışma alanı anahtar değişiklikleri nedeniyle erişilemez hale gelirse ne yapmalıyız?

Beklenen çözüm, yeni bir çalışma alanı oluşturmaktır. KMS’yi güncellemek mevcut verileri kurtarmayacaktır.

CMEK kullanmayı bırakmaya karar verirsek geri dönüş planı nedir?

Şu anda bir geri dönüş planı yoktur. Bir çalışma alanı CMEK ile oluşturulduktan sonra, ilişkili tüm veriler müşteri tarafından yönetilen anahtarlarla şifrelenir ve bu anahtarlar olmadan erişilemez. CMEK kullanımını bırakmanın tek yolu yeni bir çalışma alanı oluşturmaktır — mevcut şifrelenmiş veriler kalıcı olarak erişilemez kalacaktır.

Ana anahtarımı döndürdüğümde ne olur?

Şifreleme için yeni kriptografik materyal oluşturulacaktır; böylece yeni şifreleme istekleri yeni anahtarı kullanacaktır. Ancak, KMS tanımlayıcısı (ARN veya anahtar adı) aynı kalır ve eski verilerin şifresi hâlâ çözülebilir. Birçok bulut sağlayıcısı otomatik anahtar rotasyonu sunar (AWS, GCP, Azure).

OpenAI, ana anahtarımı döndürdüğümde eski verileri yeniden şifreler mi?

Hayır. Yeni kriptografik materyal yalnızca yeni verileri şifrelemek için kullanılacaktır.

Bir anahtar rotasyonu veya anahtar iptalinin etkili olması ne kadar sürer?

1 saat. Bunun nedeni DEK/eDEK’lerin bellekte önbelleğe alınması ve bu girdileri KMS’nizle saatlik olarak yeniden doğrulamamızdır.

KMS Tanımlayıcısını Değiştirme

KMS tanımlayıcısını değiştirmek anahtar iptali mi yoksa anahtar rotasyonu mu?

Anahtar iptali. Bir anahtar, başka bir anahtar tarafından şifrelenmiş verilerin şifresini çözemez.

OpenAI, bir ChatGPT çalışma alanı için KMS tanımlayıcımı değiştirmeme yardımcı olabilir mi?

Anahtarınızı iptal etme niyetinde olduğunuzu doğrularsanız, bunu bir ChatGPT çalışma alanı için yapmanıza yardımcı olabiliriz. KMS ARN güncellendiğinde eski verilerin erişilemez kalacağını unutmayın; bu nedenle değişiklikten sonra erişilemeyen ve erişilebilen verilerin bir karışımına sahip olursunuz.

OpenAI, bir API projesi için KMS tanımlayıcımı değiştirmeme yardımcı olabilir mi?

API kullanıyorsanız, API projeleri arşivlemeyi ve yeni projeler oluşturmayı kolaylaştırır; bu nedenle lütfen verilerine zaten erişilemeyen projeyi arşivleyin, OpenAI ile yeni bir EKM yapılandırması kaydedin ve yeni KMS anahtarıyla yeni bir API projesi oluşturun.

KMS tanımlayıcımı düzenli olarak kendim değiştirmek istersem ne olur?

Bu önerilmez çünkü muhtemelen anahtarınızı düzenli olarak iptal etmek istemezsiniz. Ancak, KMS anahtar takma adını destekleyen bir bulut sağlayıcısı kullanıyorsanız bunu yine de yapabilirsiniz (AWS örneği). Bu KMS anahtar takma adını OpenAI ile kaydedebilir ve ardından bulut sağlayıcınızda, bir anahtar iptali gerçekleştirmek için takma adın işaret ettiği temel KMS tanımlayıcısını istediğiniz zaman değiştirebilirsiniz.

Beta ve GA Davranışı

Üretimde şifreleme betasını kullanırken bilinen riskler veya sistem düzeyinde değişiklikler var mı?

Beta ortamı işlevsel olarak GA ile eşdeğerdir ve herhangi bir taşıma adımı beklenmemektedir. Birincil risk, bazı uç durum özelliklerinin eksik kod yolları nedeniyle henüz şifrelenmiş içeriği desteklemeyebilmesidir. Bunlar nadirdir ve aktif olarak çözülmektedir. Bu olası sorunlardan bağımsız olarak veriler tamamen şifrelenmiş ve korunmuştur.

Betadan GA’ya geçişte herhangi bir taşıma adımı olacak mı?

Hayır. Şifreleme betasını kullanan çalışma alanları, kullanıcıdan herhangi bir işlem gerekmeksizin GA’da otomatik olarak desteklenecektir.

Ek Teknik Ayrıntılar

Zarf Şifreleme ve İzinler

EKM için OpenAI’a GenerateDataKey izinleri vermemiz gerekiyor mu?

Hayır. OpenAI, KMS anahtarınız üzerinde yalnızca Encrypt ve Decrypt izinlerine ihtiyaç duyar. GenerateDataKey izni EKM entegrasyonu için gerekli değildir.

OpenAI müşteri verileri için zarf şifreleme kullanıyor mu?

Evet. OpenAI bir zarf şifreleme modeli kullanır:

• Müşteri KMS’i: Anahtar Şifreleme Anahtarlarını (KEK’ler) yönetir. OpenAI KEK’leri asla görmez veya depolamaz.

• OpenAI Altyapısı: Veri Şifreleme Anahtarlarını (DEK’ler) oluşturur ve yönetir. Her DEK, depolanmadan önce KEK’inizle şifrelenir (sarmalanır).

• Veri Akışı:

  • Müşteri verileri bir DEK ile şifrelenir.

  • Bu DEK, KEK’inizle şifrelenerek bir eDEK üretir.

  • eDEK, şifrelenmiş verinin yanında depolanır.

  • Verilerin şifresini çözmek için OpenAI, KMS’nizden eDEK’in şifresini çözmesini ister, DEK’i alır ve içeriğin şifresini çözer.

OpenAI neden hem KEK’leri hem de DEK’leri KMS’nin yönetmesine izin vermek yerine bu modeli seçti?

İki yaygın zarf şifreleme yaklaşımı vardır:

KMS Tarafından Yönetilen KEK’ler ve DEK’ler:

Artıları: Daha basit uygulama, şifreleme altyapısını sürdürme gereği yoktur.

Eksileri: Her şifreleme/şifre çözme isteği KMS’ye gider; bu da gecikmeyi ve maliyeti artırır ve tek bir hata noktası oluşturur.

KMS Tarafından Yönetilen KEK’ler / OpenAI Tarafından Yönetilen DEK’ler (Yaklaşımımız):

Artıları: Belirgin ölçüde daha düşük gecikme ve maliyet, daha iyi ölçeklenebilirlik ve güvenilirlik, ayrıca kısmi KMS kesintileri sırasında çalışmaya devam etme (DEK önbellek TTL’sine kadar).

Eksileri: OpenAI tarafında biraz daha karmaşık uygulama.

Bu tasarım, operasyonel risk ve müşteri maliyetini en aza indirirken OpenAI’ın güçlü güvenlik garantileri sunmasına olanak tanır.

DEK’ler ne sıklıkla döndürülür?

Her DEK yaklaşık her 60 dakikada bir döndürülür. Bu, zamansal yalıtım sağlar — bir DEK bir şekilde ele geçirilse bile etki, o bir saatlik pencere içinde şifrelenen verilerle sınırlı olur.

KMS İstek Hacmi ve Gözlemlenebilirlik

Kullanıcı mesajlarının sayısından çok daha az KMS isteği görüyoruz. Bu sayıların eşleşmesi gerekir mi?

Hayır, doğrudan ilişkili olmayacaktır.

OpenAI, performans nedenleriyle DEK’leri bellekte önbelleğe aldığı için KMS çağrıları yalnızca bir DEK’in şifresinin çözülmesi gerektiğinde yapılır — her şifreleme veya şifre çözme işleminde değil. Sonuç olarak şunları beklemelisiniz:

• Kullanıcı etkileşimlerinden daha az KMS isteği.

• Önbelleğe alınmış DEK’lerin süresi dolduğunda (yaklaşık her saat başı) veya eski şifrelenmiş verilere erişilmesi gerektiğinde ara sıra sıçramalar.

• Bir kullanıcı uzun süren bir konuşmayı sürdürdüğünde ve eski DEK’lerin yüklenmesi gerektiğinde olduğu gibi geçmiş veriler alınırken ek çağrılar.

KMS isteklerinin tam sayısı önbellek durumuna, kullanıcı davranışına, veri erişim kalıplarına ve konuşma uzunluğuna bağlıdır; bu nedenle mesaj hacmiyle doğrudan ilişkili olmayacaktır.