---
title: "Cloudflare GeoKey Manager post-quantum tasarımla closed beta'da"
description: "Cloudflare GeoKey Manager, ML-KEM-768 ve X25519 tabanlı hybrid HPKE ile closed beta'da."
image: "https://sezer.in/wp-content/uploads/2026/11/generatedHeaderImage-1793376907936.jpg"
url: "https://sezer.in/haberler/geokey-manager-post-quantum-closed-beta/"
date: "2026-11-02T19:26:07+03:00"
updated: "2026-11-02T19:26:07+03:00"
author: "Sezer Şanlıkan"
lang: "tr"
source: "https://sezer.in/haberler/geokey-manager-post-quantum-closed-beta/"
---

# Cloudflare GeoKey Manager post-quantum tasarımla closed beta'da

Cloudflare, GeoKey Manager servisinin post-quantum olarak yeniden kurulan sürümünü 23 Ekim'de Data Localization Suite müşterilerine closed beta olarak açtı. Yeni tasarım 2022'den beri kullanılan attribute-based encryption yerine ML-KEM-768 ile X25519'u birleştiren hybrid bir HPKE yapısına geçiyor. Genel kullanım 2027'nin ilk çeyreğinde planlanıyor.

## GeoKey Manager nedir, ne işe yarar?

GeoKey Manager, Cloudflare'in şifre çözme anahtarlarının hangi coğrafi bölgedeki sunucularda kullanılabileceğini sınırlayan anahtar yönetim servisidir. Data Localization Suite kapsamında sunulur ve TLS gibi trafiklerde plaintext'in yalnızca seçilen bölgede işlenmesini isteyen, veri egemenliği kuralına tabi kurumlar tarafından tercih edilir.

## ML-KEM nedir, ne işe yarar?

ML-KEM, NIST'in standartlaştırdığı lattice tabanlı post-quantum key encapsulation mechanism'dir. Quantum bilgisayarlara dayanıklı anahtar değişimi için tasarlanmıştır. Geçiş döneminde genellikle X25519 gibi klasik algoritmalarla hybrid biçimde kullanılır; böylece bir katman kırılsa bile diğeri korumayı sürdürür.

## GeoKey Manager neden yeniden yazıldı?

Veri egemenliği kuralı olan müşteriler için iki tehdit aynı anahtarda buluşuyor. Birincisi plaintext'in bölge dışında işlenmesi. İkincisi harvest-now, decrypt-later: bugün kaydedilen trafiğin ileride quantum bilgisayarla çözülmesi.

Eski GeoKey Manager ciphertext-policy attribute-based encryption kullanıyordu. Cloudflare iki gerekçeyle bunu bıraktı. Production'a hazır bir post-quantum ABE yok. Müşteriler de bu şemanın ifade edebildiği kadar çok bölgeye ihtiyaç duymuyor. Yani esnek ama ağır bir yapının yerine daha dar ve denetlenebilir bir hiyerarşi geldi.

## Yeni anahtar hiyerarşisi

Koruma katmanı RFC 9180'de tanımlı HPKE üzerine kurulu. KEM tarafında ML-KEM-768 ile X25519 birlikte çalışıyor, ardından HKDF-SHA-256 ve AES-256-GCM geliyor.

- Regional root key: bölge başına bir tane, 256-bit simetrik secret.
- Application key pair: root'tan tek bir servis (Tunnel, Gateway gibi) ve tek bir epoch için türetiliyor.
- Müşterinin private key'i bu çiftin public tarafıyla wrap ediliyor.

Hybrid seçimin pratik anlamı şu: ML-KEM'de ileride bir zayıflık bulunsa bile X25519 katmanı ayakta kalıyor. Wrapped key'ler Quicksilver ile her yere çoğaltılıyor. Root key'ler ise ayrı bir yoldan, provisioning servisi üzerinden gidip Vault'ta duruyor. Quicksilver trust boundary dışında kalıyor, çünkü elinde hiç açık anahtar yok.

## Fail-closed davranışını iş yüküne göre planlayın

Tasarımın asıl bedeli burada. Servis bağlamı, bölge ya da epoch kontrolünden biri tutmazsa istek reddediliyor. Edge'de anahtar eksik ya da bozuksa servis hiç başlamıyor. Root key'ler kernel keyring'de, diskte değil; sunucu yeniden başlarsa anahtarlar siliniyor ve yeniden authentication gerekiyor.

Beta'ya katılan bir ekip için ilk iş, hangi trafiğin GeoKey Manager'a bağlı olduğunu çıkarmak. Ardından her iş yükü için şu soruyu yanıtlayın: bölgesel anahtar dağıtımı aksarsa servis durmalı mı, yoksa kesinti kabul edilemez mi? Cloudflare'in yanıtı net: durur. Bu, regülasyon gereği plaintext'in bölge dışına çıkmaması gereken veride doğru tercih. Ama aynı kuralı her servise uygulamak, bir provisioning hatasını bölge çapında kesintiye çevirebilir. Mark Tehrani'nin sorduğu da tam olarak bu.

Beta sürecinde Cloudflare'e sormanız gerekenler:

- Kullandığınız ürünler için bölge kapsamı ve ürüne özgü istisnalar neler?
- Regional membership günde birkaç kez yenileniyor; bu yenilemede bir edge sunucu bölgeden çıkarsa trafik nasıl yönleniyor?
- Provisioning tarafında bir arıza olursa hangi sinyalle haberdar olursunuz?

## Soft ve hard rotation arasındaki seçim

Epoch, rotation ile ilerleyen anahtar kuşağı demek. Soft rotation yeni epoch açıyor, önceki birkaç epoch kullanılabilir kalıyor. Kesinti olmadan geçiş bu yolla yapılıyor. Hard rotation etkilenen anahtarları yeni epoch altında yeniden wrap ediyor ve eskisine erişimi kesiyor.

Rutin rotation için soft yeterli. Bir anahtarın sızdığından şüpheleniyorsanız hard rotation gerekiyor ve geçişte erişim kaybı ihtimalini runbook'a yazmanız lazım. Kaç eski epoch'un açık kaldığı duyuruda belirtilmemiş; bu sayıyı beta'da netleştirin.

## Kendi altyapınıza taşınabilecek desen

Cloudflare kullanmasanız da bu mimaride işe yarar bir kalıp var. Bir sunucu root key almadan önce üç kapıdan geçiyor: TPM ile donanım kimliği, Zinc envanterinde bu kimliğin hangi veri merkezine ait olduğu ve provisioning servisinin hangi root'ları vereceğine dair kararı. Secret'ı yalnızca kimliği ve konumu doğrulanmış makineye vermek, kendi Vault kurulumunuzda da uygulanabilir bir ilke.

Kernel keyring tercihi de not edilmeli. Disk imajı çalınsa ya da yedekten geri yüklense bile anahtar orada değil. Linux host'larınızda keyring içeriğine şu komutla bakabilirsiniz:

```
keyctl show
```

Bedeli, her reboot'ta yeniden authentication. Bunu otomatik yapan bir provisioning akışı kurmadan bu deseni production'a almayın.