Oyun Sunucuları için Kuantum Sonrası Kimlik Doğrulama: ML-DSA Geçiş Runbook'u - Kod ve Performans Verileriyle

Oyun sunucunuzun TLS bağlantılarını doğrulayan kriptografik imzalar, bir algoritma kırılmasından uzakta. RSA-2048 ve ECDSA-P256 — CDN'niz ile origin sunucunuz arasında oyuncu verilerini koruyan sertifika algoritmaları — yeterince güçlü bir kuantum bilgisayarda Shor algoritmasına yenik düşer. Teorik değil. Microsoft, Google ve ABD hükümetinin 2026'da aktif olarak planladığı bir zaman çizelgesinde.

Cloudflare, ML-DSA (Module-Lattice-Based Digital Signature Algorithm) kullanarak origin bağlantıları için kuantum sonrası kimlik doğrulamayı yeni yayınladı; FIPS 204 olarak standartlaştırıldı. Bu, PQ kimlik doğrulamanın ölçekteki ilk üretim dağıtımı — web trafiğinin yaklaşık %20'sini işleyen bir ağda. Oyun backend'iniz herhangi bir TLS sonlandırma katmanının arkasındaysa, bu geçiş altyapınıza dokunacak. Ne kadar erken başlarsanız, geçiş o kadar az acılı olur.

Bu yazı sizin runbook'unuz: neyin bozulduğu, nasıl tespit edileceği, gerçek komutlar ve kodlarla nasıl düzeltileceği ve oyun backend'inizin zayıf halka olmasının nasıl önleneceği.

Oyun Sunucuları Neden Benzersiz Şekilde Savunmasız

Oyun backend'leri tipik web servisleri değildir. Gerçek zamanlı durum senkronizasyonu için kalıcı bağlantılar sürdürür, aylarca veya yıllarca oyuncu ilerleme verilerini depolar ve envanter yönetimi ile ödeme işleme gibi hassas işlemleri yönetir. Oyun sunucularına yönelik kuantum sonrası saldırıların tehdit modeli somuttur:

• Oyuncu kimlik bilgileri ve oturum token'ları CDN proxy'niz ile origin API'niz arasında akan
• Oyun içi ekonomi verileri — sanal para bakiyeleri, öğe envanterleri, ikincil piyasalarda gerçek para değeri olan ticaret geçmişleri
• Ödeme webhook'ları backend'iniz işlemleri sunucu tarafında işliyorsa
• Anti-cheat sinyalleri — bir kez açığa çıktığında saldırganların tespit sezgisellerinizi tersine mühendislikle çözmesine izin verir

Korunduğumuz saldırı pasif veri toplama değil. Aktif kimlik taklidi: kuantum yetenekli bir saldırganın CDN'nizin kimlik doğrulama bilgilerini sahtelemesi ve doğrudan oyun API'nize kötü amaçlı yükler enjekte etmesi. Bu, "şimdi topla, sonra çöz" saldırısından temelde farklı bir tehdittir.

Backend güvenlik mimarisi baskı altında başarısız olduğunda ne olduğunu belgeledik — kuantum sonrası kimlik doğrulama, aynı savunma duruşunun bir sonraki evrimidir. Sorun, oyununuzun karmaşık saldırılarla karşılaşıp karşılaşmayacağı değil, altyapınızın bunlardan sağ çıkıp çıkmayacağıdır.

Şifreleme ve Kimlik Doğrulama: Aslında Ne Bozuluyor

Sürekli karıştırılan kritik bir ayrım var: kuantum sonrası şifreleme ve kuantum sonrası kimlik doğrulama, farklı zaman çizelgeleri ve çözümleri olan ayrı problemlerdir.

Kuantum sonrası şifreleme (zaten dağıtıldı)

X25519Kyber768 gibi hibrit algoritmalar kullanan TLS 1.3 anahtar değişimi zaten yaygın olarak dağıtıldı. Cloudflare, 2022–2023'te hem ziyaretçiden CDN'ye hem de CDN'den origin'e bağlantılar için PQ şifrelemeyi etkinleştirdi. Bu, verileri iletim sırasında şimdi-topla/sonra-çöz saldırılarına karşı korur.

Kuantum sonrası kimlik doğrulama (yeni sınır)

Gerçek risk şimdi burada. Origin sunucunuz RSA-2048 veya ECDSA-P256 ile imzalanmış bir TLS sertifikası sunduğunda, Shor algoritmasını çalıştıran bir kuantum bilgisayar bu imzayı gerçek zamanlı olarak sahteleme yapabilir. Bu, ortadaki adam saldırılarına olanak tanır — pasif kayıt değil, oyun trafiğinizin aktif olarak ele geçirilmesi ve manipülasyonu.

Tipik bir oyun mimarisinde iki bağlantının nasıl ayrıştığı aşağıda:

┌─────────────┐    Bağlantı 1     ┌─────────────┐    Bağlantı 2     ┌─────────────┐
│  Oyun İstemci│ ════════════════► │    CDN /    │ ════════════════► │   Origin    │
│  (Oyuncu)    │                    │   Proxy     │                    │  (API'niz)  │
└─────────────┘                    └─────────────┘                    └─────────────┘
                                    │                                      │
                              PQ şifreleme ✓                        PQ şifreleme ✓
                              PQ kimlik doğrulama (MTC ile, 2027)  PQ kimlik doğrulama (ML-DSA, ŞİMDİ)
                                    │
                              Klasik kimlik doğrulama
                              sertifikaları burada
                              mevcut zayıf halka

Bağlantı 2 — CDN'nizden veya ters proxy'nizden origin'inize — şu anda PQ kimlik doğrulamanın dağıtılabileceği bağlantıdır. Bu bağlantı oyuncu eylemlerini, envanter güncellemelerini, eşleştirme isteklerini ve ödeme webhook'larını taşır. Bir saldırgan bu bağlantıdaki kimlik doğrulamayı sahtelerse, backend'inizi ele geçirir.

Neden Önce Bağlantı 2

CDN'den origin'e bağlantı, PQ kimlik doğrulamayı genel web'den yıllar önce pratik kılan yapısal avantajlara sahiptir:

• Kontrollü TLS istemcisi: CDN, bağlantı havuzlamayı ve el sıkışma davranışını kontrol eder, PQ yükünü binlerce istek arasında amorti eder
• Mevcut güven ilişkisi: CDN'nizle zaten bir hesap ilişkiniz var — genel Sertifika Otoritesi ekosistemine bağımlılık yok
• Özel PKI: Kendi sertifika otoritelerinizi çalıştırabilir, WebPKI ve Sertifika Şeffaflığı gereksinimlerinin kısıtlamalarından kaçınabilirsiniz
• Bağlantı tekrar kullanımı: CDN'ler origin'e kalıcı bağlantılar sürdürür, bu da PQ el sıkışmalarının toplam istek hacmine göre nadiren gerçekleşmesi anlamına gelir

Bu nedenle Cloudflare, genel İnternet Merkle Ağacı Sertifikalarını (hedef 2027) beklerken, bugün origin bağlantıları için ML-DSA kimlik doğrulamasını kullanıma sunabilir.

ML-DSA: PQ Kimlik Doğrulamayı Güçlendiren Algoritma

NIST FIPS 204 olarak standartlaştırılan ML-DSA, kafes problemlerinin zorluğuna dayanır — hem klasik hem de kuantum saldırılarına dirençli olduğuna inanılan matematiksel yapılar. Endüstri genelinde kuantum sonrası dijital imzalar için dağıtılan birincil algoritmadır.

Parametre setleri ve güvenlik seviyeleri

Parametre Seti	Güvenlik Seviyesi	Genel Anahtar	İmza	El Sıkışma Yükü
ML-DSA-44	NIST Cat 2 (~AES-128)	1.312 B	2.420 B	~4.5 KB ek
ML-DSA-65	NIST Cat 3 (~AES-192)	1.952 B	3.293 B	~6.5 KB ek
ML-DSA-87	NIST Cat 5 (~AES-256)	2.592 B	4.595 B	~9 KB ek

Karşılaştırma için, bir ECDSA-P256 imzası 64 bayt ve 64 bayt genel anahtardır. ML-DSA-44 imzaları yaklaşık 37 kat daha büyüktür. Bu ana ödünleşimdir ve geliştiricileri endişelendiren sayıdır.

ML-DSA-44, oyun backend'leri için doğru seçimdir. NIST Kategori 2 güvenliği sağlar — bilinen kuantum ve klasik saldırılara karşı rahat marjlar — ve en yüksek performanslı seçenektir. Daha büyük imza boyutu, bağlantı havuzlaması sayesinde el sıkışmaların toplam trafiğe göre seyrek olması nedeniyle yönetilebilir.

FIPS 204 tohum formatı: kompakt anahtar depolama

ML-DSA özel anahtarları bir tohum formatını destekler — tam özel anahtarın deterministik olarak türetildiği 32 baytlık rastgele bir değer:

Tohum (32 bayt) ──► Deterministik Genişletme ──► Tam Özel Anahtar (ML-DSA-44 için 2.560 bayt)

Bu, oyun backend altyapısı için pratik bir kazanımdır. Gizli yöneticinizde veya ortam değişkenlerinizde 2.560 baytlık özel anahtarlar depolamak yerine, 32 bayt depolayıp tam anahtarı ihtiyaç duyulduğunda türetirsiniz. Anahtar rotasyonu, yeni bir tohum oluşturma ve dağıtma meselesi haline gelir — geleneksel RSA anahtar malzemesini yönetmekten operasyonel olarak çok daha basittir.

Geçiş Runbook'u: Adım Adım

Adım 1: Mevcut TLS yapılandırmanızı denetleyin

Herhangi bir şeye dokunmadan önce, ne çalıştırdığınızı anlayın. Origin sunucunuzun mevcut sertifika zincirini ve imza algoritmalarını kontrol edin:

# Origin'inizin sunduğu sertifikayı inceleyin
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -text -noout | grep -A2 "Signature Algorithm"

# Desteklenen TLS sürümlerini ve şifre takımlarını kontrol edin
nmap --script ssl-enum-ciphers -p 443 your-game-api.example.com

# mTLS kullanılıyorsa, CDN'nizin hangi istemci sertifikasını sunduğunu kontrol edin
# (tcpdump veya benzeri ile bir test isteği sırasında yakalayın)
tcpdump -i eth0 -w tls_handshake.pcap port 443 -c 50

Bu temel durumu belgeleyin. Geri alma ve geçişinizin hiçbir şeyi bozmadığını doğrulamak için buna ihtiyacınız olacak. Kaydedin:

• Mevcut imza algoritması (RSA-SHA256, ECDSA-SHA256 vb.)
• Sertifika zinciri derinliği ve tüm son kullanma tarihleri
• mTLS'nin zaten kullanılıp kullanılmadığı
• Desteklenen TLS sürümleri (zaten yalnızca TLS 1.3'te olmalısınız)

Adım 2: ML-DSA sertifika zincirleri oluşturun

OpenSSL 3.0+ için Open Quantum Safe (OQS) sağlayıcısına ihtiyacınız olacak:

# OQS sağlayıcısını yükleyin
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
make -j$(nproc) && sudo make install

# openssl.cnf'de etkinleştirin — [provider_sect] ekleyin:
# oqsprovider = oqsprovider_sect
# oqsprovider_sect = oqsprovider

# ML-DSA-44 kök CA oluşturun (10 yıl geçerlilik)
openssl req -x509 -new -newkey mldsa44 \
  -keyout mldsa44-ca.key -out mldsa44-ca.crt \
  -days 3650 -nodes \
  -subj "/CN=Game Backend PQ Root CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

# Origin sunucu sertifika imzalama isteği oluşturun
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-server.key -out mldsa44-server.csr \
  -nodes -subj "/CN=your-game-api.example.com"

# Sunucu sertifikasını PQ CA ile imzalayın (döngü hijyeni için 1 yıl geçerlilik)
openssl x509 -req -in mldsa44-server.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-server.crt \
  -days 365 \
  -extfile <(echo "subjectAltName=DNS:your-game-api.example.com")

# mTLS için istemci sertifikası oluşturun (CDN'nizin kimliği)
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-client.key -out mldsa44-client.csr \
  -nodes -subj "/CN=CDN Proxy Client"

openssl x509 -req -in mldsa44-client.csr \
  -CA mldsa44-ca.crt -CAkey mldsa44-ca.key \
  -CAcreateserial -out mldsa44-client.crt -days 365

# Zinciri doğrulayın
openssl verify -CAfile mldsa44-ca.crt mldsa44-server.crt
openssl verify -CAfile mldsa44-ca.crt mldsa44-client.crt

Anahtar yönetimi notu: Mümkün olduğunda tam 2.560 baytlık özel anahtar yerine 32 baytlık tohumu saklayın. Bu, gizli döngüyü basitleştirir ve gizli yöneticilerinizde ve ortam değişkenlerinizdeki saldırı yüzeyinizi azaltır.

Adım 3: Origin sunucunuzu PQ mTLS için yapılandırın

Nginx yapılandırması:

server {
    listen 443 ssl;
    server_name your-game-api.example.com;

    # ML-DSA-44 sunucu sertifikası
    ssl_certificate     /etc/ssl/pq/mldsa44-server.crt;
    ssl_certificate_key /etc/ssl/pq/mldsa44-server.key;

    # İstemci doğrulama (mTLS) — yalnızca PQ CA'ya güven
    ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # Yalnızca TLS 1.3 — eski sürümlere düşürme yok
    ssl_protocols TLSv1.3;

    location /api/ {
        proxy_pass http://game_backend_upstream;
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_set_header X-Client-Verified $ssl_client_verify;
    }
}

C++ ile özel oyun sunucusu (OpenSSL 3.0 + OQS):

#include <openssl/ssl.h>
#include <openssl/err.h>

SSL_CTX* create_pq_mtls_context() {
    SSL_CTX* ctx = SSL_CTX_new(TLS_server_method());
    if (!ctx) {
        ERR_print_errors_fp(stderr);
        return nullptr;
    }

    // TLS 1.3 minimum zorunlu — sürüm düşürme mümkün değil
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

    // ML-DSA-44 sunucu sertifikasını yükle
    if (SSL_CTX_use_certificate_file(ctx,
            "/etc/ssl/pq/mldsa44-server.crt",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // ML-DSA-44 özel anahtarını yükle
    if (SSL_CTX_use_PrivateKey_file(ctx,
            "/etc/ssl/pq/mldsa44-server.key",
            SSL_FILETYPE_PEM) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Anahtarın sertifikayla eşleştiğini doğrula
    if (SSL_CTX_check_private_key(ctx) != 1) {
        fprintf(stderr, "Key/cert mismatch\n");
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // İstemci sertifikası doğrulama için PQ CA'yı yükle
    if (SSL_CTX_load_verify_locations(ctx,
            "/etc/ssl/pq/mldsa44-ca.crt", nullptr) != 1) {
        ERR_print_errors_fp(stderr);
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // İstemci sertifikalarını zorunlu kıl ve doğrula
    SSL_CTX_set_verify(ctx,
        SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
        nullptr);

    return ctx;
}

// Oyun sunucunuzun accept döngüsünde kullanım:
void handle_connection(int client_fd, SSL_CTX* ctx) {
    SSL* ssl = SSL_new(ctx);
    SSL_set_fd(ssl, client_fd);

    if (SSL_accept(ssl) <= 0) {
        // El sıkışma başarısız — muhtemelen istemci sertifika sorunu
        ERR_print_errors_fp(stderr);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // İstemci sertifikasının gerçekten sunulduğunu doğrula
    X509* client_cert = SSL_get_peer_certificate(ssl);
    if (!client_cert) {
        fprintf(stderr, "No client certificate — rejecting\n");
        SSL_shutdown(ssl);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // İstemci ML-DSA mTLS ile doğrulandı — devam et
    X509_free(client_cert);
    // ... oyun protokolünü işle ...
}

Adım 4: CDN/proxy güven deponuzu güncelleyin

Cloudflare kullanıyorsanız, ML-DSA CA sertifikanızı Özel Origin Güven Deposuna yükleyin ve ML-DSA istemci sertifikanızla Kimliği Doğrulanmış Origin Çekme'yi yapılandırın:

1. mldsa44-ca.crt dosyasını CDN'nizin özel güven deposuna yükleyin
2. Kimliği doğrulanmış origin çekmeleri için mldsa44-client.crt ve mldsa44-client.key'i yükleyin
3. SSL modunu Full (strict) olarak ayarlayarak özel güven deponuza karşı sertifika doğrulamasını zorunlu kılın

Kendi proxy altyapınızı çalıştırıyorsanız, PQ CA sertifikasını tüm proxy düğümlerine dağıtmanız, her biri için istemci sertifikaları yapılandırmanız ve sertifika son kullanma tarihi için izleme kurmanız gerekecektir. Bunu birden fazla bölge ve ölçeklendirme grubu arasında manuel olarak yönetmek, operasyonel karmaşıklığın arttığı yerdir — otomatik sertifika dağıtımı ve rotasyonu hayati hale gelir.

Adım 5: PQ el sıkışmasını test edin

# ML-DSA mTLS el sıkışmasının başarılı olduğunu doğrulayın
openssl s_client -connect your-game-api.example.com:443 \
  -servername your-game-api.example.com \
  -cert mldsa44-client.crt \
  -key mldsa44-client.key \
  -CAfile mldsa44-ca.crt \
  </dev/null 2>&1 | grep -E "(Verify return|Protocol|Cipher)"

# Beklenen çıktı:
#   Verify return code: 0 (ok)
#   Protocol  : TLSv1.3
#   Cipher    : TLS_AES_256_GCM_SHA384

# Yük altında el sıkışma gecikmesini ölçün
# (lansman günü koşullarını simüle etmek için bağlantı hızını ayarlayın)
wrk -t4 -c100 -d30s --latency \
  --script=pq_mtls_test.lua \
  https://your-game-api.example.com/api/health

Test sırasında izlenecekler:

• El sıkışma gecikmesi: ECDSA-P256'ya kıyasla yeni bağlantı başına 0,5–2 ms ek bekleyin
• CPU kullanımı: ML-DSA imza doğrulaması, ECDSA doğrulamasından yaklaşık 2–3 kat daha yavaştır
• Hata oranları: Geçiş sırasında sertifika doğrulama başarısızlıklarına dikkat edin
• Bağlantı havuzu kullanımı: Bağlantıların yeniden kullanıldığını doğrulayın (el sıkışma maliyetini amorti etme)

Adım 6: Klasik geri dönüşleri kaldırın

Kuantum güvenliğini asıl sağlayan adım budur. Origin'iniz herhangi bir klasik (RSA/ECDSA) kimlik doğrulamayı kabul ediyorsa, kuantum yetenekli bir saldırgan bu kimlik bilgilerini sahteleme yapabilir ve PQ korumalarınızı tamamen atlayabilir.

Düşürme saldırısı senaryosu:

Saldırgan CDN ↔ Origin el sıkışmasını ele geçirir
    │
    ├── Görüşmeyi klasik RSA kimlik doğrulamasına zorlar
    ├── Shor algoritmasıyla RSA imzasını sahteler
    └── Origin sunucunuza CDN'yi taklit eder ✓

Klasik geri dönüşler varsa PQ sertifikalarınız işe yaramaz.

Çözüm: origin sunucunuz, CDN'den origin'e bağlantı için yalnızca ML-DSA sertifikalarına güvenmelidir.

# YANLIŞ: Karma güven deposu — klasik sertifikalar hala kabul ediliyor
ssl_client_certificate /etc/ssl/mixed-ca-bundle.crt;

# DOĞRU: Yalnızca PQ güven deposu — klasik sahtecilikler reddedilir
ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;

Kritik uyarı: Klasik güveni yalnızca tüm CDN bağlantılarının PQ kimlik doğrulama kullandığını doğruladıktan sonra kaldırın. Erken kaldırma, origin bağlantınızı bozar. Çift yığın yapılandırmasını (Adım 3–5) en az iki hafta çalıştırın, hiçbir bağlantının klasik kimlik doğrulamaya düşmediğini izleyin, ardından klasik güveni kaldırın.

Performans Etkisi: Oyun Backend'leri için Gerçek Rakamlar

Yerinde endişe: ML-DSA imzaları büyüktür. İşte bunun pratikte anlamı.

El sıkışma seviyesinde yük

Metrik	ECDSA-P256	ML-DSA-44	Fark
Sunucu sertifikası boyutu	~500 B	~1.700 B	+%240
İmza boyutu	64 B	2.420 B	+%3.681
Toplam el sıkışma baytı	~1.5 KB	~6 KB	+%300
El sıkışma gecikmesi (p50)	~1 ms	~2.5 ms	+%150
El sıkışma başına CPU doğrulama	~0.05 ms	~0.12 ms	+%140

Bu neden oyun backend'inizi mahvetmez

CDN'den origin'e bağlantılar bağlantı havuzlaması kullanır. Tek bir TLS bağlantısı, geri dönüştürülmeden önce binlerce HTTP isteğini işler. 1,5 ms'lik ek el sıkışma gecikmesi, örneğin 10.000 istekte amorti edilir — bu, istek başına 0,00015 ms'dir. Neredeyse bedava.

Performans etkisi iki senaryoda yoğunlaşır:

1. Soğuk başlangıç / bağlantı kurulumu ani artışları: Oyun lansmanları, sezonluk etkinlikler, viral anlar — origin'iniz saniyede binlerce yeni TLS bağlantısı işlediğinde. Origin'iniz şu anda saniyede 50.000 ECDSA el sıkışması işliyorsa, eşdeğer donanımda saniyede ~20.000–25.000 ML-DSA-44 el sıkışması bekleyin. Kapasiteyi buna göre planlayın.

2. Kısa ömürlü bağlantılar: Mimariniz istek başına yeni bir TLS bağlantısı oluşturuyorsa (lütfen yapmayın), her istek tam el sıkışma maliyetini öder. PQ kimlik doğrulamaya geçmeden önce bunu bağlantı havuzlaması ve kalıcı bağlantılarla düzeltin.

Bant genişliği etkisi

Yeni bağlantı başına ~4.5 KB ek el sıkışma verisi, HTTP/2 veya HTTP/3 çoğullamalı bağlantılar için ihmal edilebilir. Uzun ömürlü bağlantılara sahip WebSocket tabanlı oyun protokolleri için el sıkışma, bağlantı ömrü boyunca bir kez gerçekleşir — bant genişliği bütçeleri için önemsizdir.

PQ Oyun Backend Geçişi için En İyi Uygulamalar

1. Önce PQ şifrelemeyi etkinleştirin, ardından kimlik doğrulamayı. Origin bağlantılarınız için kuantum sonrası anahtar değişimini (X25519Kyber768) henüz açmadıysanız, sertifikalara geçmeden önce bunu yapın. Bu bir yapılandırma değişikliğidir — yeni sertifika yok — ve hemen şimdi-topla/sonra-çöz saldırılarına karşı korur.

2. ML-DSA-44 dağıtın, ML-DSA-87 değil. Sınıflandırılmış askeri sistemleri korumuyorsanız, ML-DSA-44, NIST Kategori 2'de rahat güvenlik marjları sağlar. ML-DSA-87, tehdit modelinizin neredeyse kesinlikle gerektirmediği marjinal güvenlik faydası için el sıkışma yükünüzü kabaca ikiye katlar.

3. Geçiş sırasında çift yığın çalıştırın — ardından klasikleri acımasızca öldürün. Hem klasik hem de PQ sertifikalarını paralel olarak dağıtın. En az iki hafta izleyin. Sıfır klasik geri dönüş bağlantısı olduğunu doğrulayın. Ardından klasik güveni tamamen kaldırın. Klasik geri dönüşleri yerinde bırakmak, PQ geçişinde yapılan en yaygın hatadır — pahalı yeni sertifikalarınızı güvenlik tiyatrosuna dönüştürür.

4. Anahtar rotasyonunu ilk günden otomatikleştirin. ML-DSA'nın 32 baytlık tohum formatı bunu pratik kılar. Sertifika rotasyonunu dağıtım boru hattınıza ekleyin. Üç ayda bir döndürün — kripto zayıfladığı için değil, operasyonel anahtar hijyeni (sızdırılmış kimlik bilgileri, ayrılan mühendisler, güvenliği ihlal edilmiş CI/CD) gerçek zafiyetiniz olduğu için.

5. Bağlantı değişim oranınızı profilleme. Origin sunucularınızda ss -s veya eşdeğerini çalıştırarak yoğun ve düşük saatlerde saniyede yeni bağlantı sayısını hesaplayın. El sıkışma yükü deltasıyla (~1.5ms CPU, ~4.5KB bant genişliği) çarpın. Bu, geçiş için somut bir kapasite planlama sayısı verir.

Bunun Oyun Backend'iniz İçin Anlamı

Kuantum sonrası zaman çizelgesi artık akademik değil. NIST, ML-DSA'yı standartlaştırdı. Büyük altyapı sağlayıcıları onu üretimde dağıtıyor. Hükümet zorunlulukları benimsemeyi hızlandırıyor. Soru, oyun backend'inizin PQ kimlik doğrulamaya ihtiyacı olup olmadığı değil — geçişe ne zaman başlayacağınızdır.

Kendi origin altyapılarını yöneten ekipler için iş gerçek ama sınırlıdır: yeni sertifika zincirleri oluşturun, sunucu yapılandırmalarını güncelleyin, güven depolarını değiştirin, test edin ve klasik geri dönüşleri kaldırın. Her adım birkaç saatlik iştir. Toplamda, TLS konusunda rahat olan bir backend mühendisi için bir ila iki haftalık bir projedir.

Bu haftaları kriptografik altyapı yerine oyun geliştirmeye harcamayı tercih ediyorsanız, horizOn TLS sonlandırma, mTLS ve sertifika yönetimini backend platformunun bir parçası olarak halleder — böylece PQ geçişi çok haftalık bir altyapı projesi yerine bir yapılandırma değişikliği olarak çalışırken siz özellikler gönderebilirsiniz.

Bugün başlayın. Adım 1'deki denetim komutlarını üretim origin'inizde çalıştırın. Sertifikalarınızın hangi imza algoritmasını kullandığını kontrol edin. RSA veya ECDSA ise, PQ kimlik doğrulama geçişini 2026–2027 yol haritanıza ekleyin. Oyuncularınızın verilerini hedef alan kuantum bilgisayarlar, hazır olmanızı beklemeyecek.

---

Kaynak: Origin'lere kuantum sonrası kimlik doğrulama artık destekleniyor