게임 서버를 위한 Post-Quantum Authentication: ML-DSA 마이그레이션 런북 (코드 및 성능 데이터 포함)

게임 서버의 TLS 연결을 인증하는 암호화 서명은 단 하나의 알고리즘 돌파구만 넘으면 위조될 수 있습니다. RSA-2048과 ECDSA-P256 — CDN과 오리진 서버 간 플레이어 데이터를 보호하는 인증서 알고리즘 — 은 충분히 강력한 양자 컴퓨터에서 쇼어 알고리즘(Shor's algorithm)에 무너집니다. 이론상이 아닙니다. 마이크로소프트, 구글, 미국 정부가 모두 2026년을 기준으로 적극적으로 계획하고 있는 일정입니다.

Cloudflare는 방금 ML-DSA(Module-Lattice-Based Digital Signature Algorithm, FIPS 204로 표준화)를 사용한 오리진 연결용 포스트퀀텀 인증을 출시했습니다. 이는 대규모로 PQ 인증을 최초로 프로덕션 배포한 사례입니다 — 웹 트래픽의 약 20%를 처리하는 네트워크에서 말이죠. 게임 백엔드가 TLS 종단 레이어 뒤에 있다면 이 마이그레이션이 여러분의 인프라에 영향을 미칩니다. 그리고 일찍 시작할수록 전환 과정이 덜 고통스럽습니다.

이 글은 여러분의 런북(runbook)입니다: 무엇이 깨지고, 어떻게 감지하며, 실제 명령어와 코드로 어떻게 복구하고, 게임 백엔드가 약점이 되는 것을 어떻게 방지할지 다룹니다.

게임 서버가 특히 취약한 이유

게임 백엔드는 일반 웹 서비스가 아닙니다. 실시간 상태 동기화를 위해 지속적인 연결을 유지하고, 수개월 또는 수년간의 플레이어 진행 데이터를 저장하며, 인벤토리 관리 및 결제 처리와 같은 민감한 작업을 처리합니다. 게임 서버에 대한 포스트퀀텀 공격의 위협 모델은 구체적입니다:

• 플레이어 자격 증명 및 세션 토큰이 CDN 프록시와 오리진 API 사이를 흐름
• 게임 내 경제 데이터 — 가상 화폐 잔액, 아이템 인벤토리, 2차 시장에서 실제 돈이 오가는 거래 내역
• 결제 웹훅 — 백엔드가 서버 측에서 구매를 처리하는 경우
• 안티 치트 신호 — 노출되면 공격자가 탐지 휴리스틱을 역공학할 수 있음

우리가 방어하려는 공격은 수동적 데이터 수집이 아닙니다. 능동적 사칭입니다: 양자 능력을 갖춘 공격자가 CDN의 인증 자격 증명을 위조하고 게임 API에 직접 악성 페이로드를 주입하는 것입니다. 이는 "수확 후 나중에 복호화" 공격과 근본적으로 다른 위협입니다.

백엔드 보안 아키텍처가 압박을 받을 때 어떤 일이 발생하는지 문서화했습니다 — 포스트퀀텀 인증은 동일한 방어 태세의 다음 진화입니다. 문제는 여러분의 게임이 정교한 공격에 직면할지 여부가 아니라, 인프라가 그 공격을 견딜 수 있을지입니다.

암호화 vs. 인증: 실제로 무엇이 깨지는가

자주 혼동되는 중요한 차이가 있습니다: 포스트퀀텀 암호화와 포스트퀀텀 인증은 서로 다른 일정과 해결책을 가진 별개의 문제입니다.

포스트퀀텀 암호화 (이미 배포됨)

X25519Kyber768과 같은 하이브리드 알고리즘을 사용한 TLS 1.3 키 교환은 이미 널리 배포되었습니다. Cloudflare는 2022~2023년에 방문자-CDN 및 CDN-오리진 연결 모두에 대해 PQ 암호화를 활성화했습니다. 이는 전송 중인 데이터를 수확-후-나중-복호화 공격으로부터 보호합니다.

포스트퀀텀 인증 (새로운 개척지)

인증이야말로 현재 진정한 위험이 있는 곳입니다. 오리진 서버가 RSA-2048 또는 ECDSA-P256으로 서명된 TLS 인증서를 제시할 때, 쇼어 알고리즘을 실행하는 양자 컴퓨터는 해당 서명을 실시간으로 위조할 수 있습니다. 이는 중간자 공격을 가능하게 합니다 — 수동적 기록이 아닌, 게임 트래픽의 능동적 가로채기 및 조작입니다.

일반적인 게임 아키텍처에서 두 연결이 어떻게 구성되는지 살펴보겠습니다:

┌─────────────┐    Connection 1     ┌─────────────┐    Connection 2     ┌─────────────┐
│  Game Client │ ════════════════► │    CDN /    │ ════════════════► │   Origin    │
│  (Player)    │                    │   Proxy     │                    │  (Your API) │
└─────────────┘                    └─────────────┘                    └─────────────┘
                                    │                                      │
                              PQ encryption ✓                        PQ encryption ✓
                              PQ auth (via MTC, 2027)              PQ auth (ML-DSA, NOW)
                                    │
                              Classical auth
                              certificates here
                              are the current
                              weak link

Connection 2 — CDN 또는 리버스 프록시에서 오리진으로의 연결 — 이 지금 PQ 인증을 배포할 수 있는 곳입니다. 이 연결은 플레이어 액션, 인벤토리 업데이트, 매치메이킹 요청, 결제 웹훅을 전달합니다. 공격자가 이 연결에서 인증을 위조하면 백엔드를 장악하게 됩니다.

Connection 2가 먼저인 이유

CDN-오리진 연결은 공개 웹보다 몇 년 일찍 PQ 인증을 실용적으로 만드는 구조적 이점이 있습니다:

• 제어된 TLS 클라이언트: CDN은 연결 풀링과 핸드셰이크 동작을 제어하여 수천 개의 요청에 PQ 오버헤드를 분산시킵니다
• 기존 신뢰 관계: 이미 CDN과 계정 관계가 있습니다 — 공개 Certificate Authority 생태계에 의존하지 않습니다
• 사용자 정의 PKI: 자체 Certificate Authority를 실행할 수 있어 WebPKI 및 Certificate Transparency 요구 사항의 제약을 피할 수 있습니다
• 연결 재사용: CDN은 오리진에 지속적인 연결을 유지하므로, PQ 핸드셰이크는 전체 요청 볼륨에 비해 드물게 발생합니다

이것이 Cloudflare가 공개 인터넷이 Merkle Tree Certificates(2027년 목표)를 기다리는 동안 오늘 오리진 연결에 ML-DSA 인증을 제공할 수 있는 이유입니다.

ML-DSA: PQ 인증을 구동하는 알고리즘

ML-DSA는 NIST FIPS 204로 표준화되었으며, 격자 문제의 어려움에 기반합니다 — 고전적 및 양자 공격 모두에 저항하는 것으로 믿어지는 수학적 구조입니다. 이는 업계 전반에서 포스트퀀텀 디지털 서명을 위해 배포되는 주요 알고리즘입니다.

파라미터 세트 및 보안 수준

파라미터 세트	보안 수준	공개 키	서명	핸드셰이크 오버헤드
ML-DSA-44	NIST Cat 2 (~AES-128)	1,312 B	2,420 B	~4.5 KB 추가
ML-DSA-65	NIST Cat 3 (~AES-192)	1,952 B	3,293 B	~6.5 KB 추가
ML-DSA-87	NIST Cat 5 (~AES-256)	2,592 B	4,595 B	~9 KB 추가

비교하자면, ECDSA-P256 서명은 64바이트에 공개 키 64바이트입니다. ML-DSA-44 서명은 약 37배 더 큽니다. 이것이 주요 트레이드오프이며, 개발자들을 불안하게 만드는 숫자입니다.

ML-DSA-44는 게임 백엔드에 적합한 선택입니다. NIST Category 2 보안을 제공하며 — 알려진 양자 및 고전적 공격에 대해 충분한 마진 — 가장 성능이 좋은 옵션입니다. 더 큰 서명 크기는 연결 풀링 덕분에 핸드셰이크가 전체 트래픽에 비해 드물게 발생하므로 관리 가능합니다.

FIPS 204 시드 형식: 컴팩트한 키 저장소

ML-DSA 개인 키는 시드 형식을 지원합니다 — 전체 개인 키가 결정론적으로 파생되는 32바이트 난수 값:

Seed (32 bytes) ──► Deterministic Expand ──► Full Private Key (2,560 bytes for ML-DSA-44)

이는 게임 백엔드 인프라에 실용적인 이점입니다. 시크릿 매니저나 환경 변수에 2,560바이트 개인 키를 저장하는 대신 32바이트를 저장하고 필요할 때 전체 키를 파생합니다. 키 순환은 새 시드를 생성하고 배포하는 문제가 됩니다 — 전통적인 RSA 키 자료를 관리하는 것보다 운영적으로 훨씬 간단합니다.

마이그레이션 런북: 단계별 가이드

1단계: 현재 TLS 구성 감사

무언가를 건드리기 전에 현재 상태를 이해하세요. 오리진 서버의 현재 인증서 체인과 서명 알고리즘을 확인하세요:

# Inspect the certificate your origin is presenting
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"

# Check supported TLS versions and cipher suites
nmap --script ssl-enum-ciphers -p 443 your-game-api.example.com

# If using mTLS, check what client certificate your CDN presents
# (capture during a test request with tcpdump or equivalent)
tcpdump -i eth0 -w tls_handshake.pcap port 443 -c 50

이 기준선을 문서화하세요. 롤백과 마이그레이션이 아무것도 깨뜨리지 않았다는 확인에 필요합니다. 기록할 사항:

• 현재 서명 알고리즘 (RSA-SHA256, ECDSA-SHA256 등)
• 인증서 체인 깊이 및 모든 만료 날짜
• mTLS가 이미 사용 중인지 여부
• 지원되는 TLS 버전 (이미 TLS 1.3만 사용 중이어야 함)

2단계: ML-DSA 인증서 체인 생성

OpenSSL 3.0+용 Open Quantum Safe (OQS) provider가 필요합니다:

# Install OQS provider
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

# Enable in openssl.cnf — add to [provider_sect]:
# oqsprovider = oqsprovider_sect
# oqsprovider_sect = oqsprovider

# Generate ML-DSA-44 root CA (10-year validity)
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"

# Generate origin server certificate signing request
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-server.key -out mldsa44-server.csr \
  -nodes -subj "/CN=your-game-api.example.com"

# Sign server cert with PQ CA (1-year validity for rotation hygiene)
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")

# Generate client certificate for mTLS (your CDN's identity)
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

# Verify the chain
openssl verify -CAfile mldsa44-ca.crt mldsa44-server.crt
openssl verify -CAfile mldsa44-ca.crt mldsa44-client.crt

키 관리 참고: 가능하면 전체 2,560바이트 개인 키 대신 32바이트 시드를 저장하세요. 이렇게 하면 시크릿 순환이 간소화되고 시크릿 매니저 및 환경 변수에서 공격 표면이 줄어듭니다.

3단계: 오리진 서버에 PQ mTLS 구성

Nginx 구성:

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

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

    # Client verification (mTLS) — only trust PQ CA
    ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # TLS 1.3 only — no downgrade to older versions
    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++ 사용자 정의 게임 서버 (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;
    }

    // Enforce TLS 1.3 minimum — no version downgrade possible
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

    // Load ML-DSA-44 server certificate
    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;
    }

    // Load ML-DSA-44 private key
    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;
    }

    // Verify key matches certificate
    if (SSL_CTX_check_private_key(ctx) != 1) {
        fprintf(stderr, "Key/cert mismatch\n");
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Load PQ CA for client certificate verification
    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;
    }

    // Require and verify client certificates
    SSL_CTX_set_verify(ctx,
        SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
        nullptr);

    return ctx;
}

// Usage in your game server's accept loop:
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) {
        // Handshake failed — likely client cert issue
        ERR_print_errors_fp(stderr);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Verify client certificate was actually presented
    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;
    }

    // Client authenticated via ML-DSA mTLS — proceed
    X509_free(client_cert);
    // ... handle game protocol ...
}

4단계: CDN/프록시 신뢰 저장소 업데이트

Cloudflare를 사용하는 경우 Custom Origin Trust Store에 ML-DSA CA 인증서를 업로드하고 ML-DSA 클라이언트 인증서로 Authenticated Origin Pulls를 구성하세요:

1. mldsa44-ca.crt를 CDN의 사용자 정의 신뢰 저장소에 업로드
2. 인증된 오리진 풀을 위해 mldsa44-client.crt 및 mldsa44-client.key 업로드
3. SSL 모드를 **Full (strict)**로 설정하여 사용자 정의 신뢰 저장소에 대해 인증서 검증을 강제

자체 프록시 인프라를 운영하는 경우 모든 프록시 노드에 PQ CA 인증서를 배포하고, 각 노드에 클라이언트 인증서를 구성하며, 인증서 만료 모니터링을 설정해야 합니다. 여러 리전과 스케일링 그룹에서 수동으로 관리하면 운영 복잡성이 기하급수적으로 증가합니다 — 자동화된 인증서 배포 및 순환이 필수적입니다.

5단계: PQ 핸드셰이크 테스트

# Verify ML-DSA mTLS handshake succeeds
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)"

# Expected output:
#   Verify return code: 0 (ok)
#   Protocol  : TLSv1.3
#   Cipher    : TLS_AES_256_GCM_SHA384

# Measure handshake latency under load
# (adjust connection rate to simulate launch-day conditions)
wrk -t4 -c100 -d30s --latency \
  --script=pq_mtls_test.lua \
  https://your-game-api.example.com/api/health

테스트 중 모니터링할 사항:

• 핸드셰이크 지연 시간: ECDSA-P256 대비 새 연결당 0.5~2ms 추가 예상
• CPU 사용률: ML-DSA 서명 검증은 ECDSA 검증보다 약 2~3배 느림
• 오류율: 전환 중 인증서 검증 실패를 주시
• 연결 풀 활용도: 연결이 재사용되고 있는지 확인 (핸드셰이크 비용 분산)

6단계: 고전적 폴백 제거

이 단계가 실제로 양자 보안을 제공하는 단계입니다. 오리진이 어떤 고전적(RSA/ECDSA) 인증도 수락한다면, 양자 능력을 갖춘 공격자가 해당 자격 증명을 위조하고 PQ 보호를 우회할 수 있습니다.

다운그레이드 공격 시나리오:

Attacker intercepts CDN ↔ Origin handshake
    │
    ├── Forces negotiation to classical RSA authentication
    ├── Forges RSA signature using Shor's algorithm
    └── Impersonates CDN to your origin server ✓

Your PQ certificates are worthless if classical fallbacks exist.

해결책: 오리진 서버는 CDN-오리진 연결에 대해 ML-DSA 인증서만 신뢰해야 합니다.

# WRONG: Mixed trust store — classical certs still accepted
ssl_client_certificate /etc/ssl/mixed-ca-bundle.crt;

# RIGHT: PQ-only trust store — classical forgeries rejected
ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;

중요 경고: 모든 CDN 연결이 PQ 인증을 사용하고 있음을 확인한 후에만 고전적 신뢰를 제거하세요. 조기 제거는 오리진 연결을 끊습니다. 최소 2주 동안 듀얼 스택 구성(3~5단계)을 실행하여 연결이 고전적 인증으로 폴백되지 않음을 모니터링한 후 고전적 신뢰를 제거하세요.

성능 영향: 게임 백엔드의 실제 수치

타당한 우려: ML-DSA 서명은 큽니다. 실제로 의미하는 바는 다음과 같습니다.

핸드셰이크 수준 오버헤드

메트릭	ECDSA-P256	ML-DSA-44	차이
서버 인증서 크기	~500 B	~1,700 B	+240%
서명 크기	64 B	2,420 B	+3,681%
총 핸드셰이크 바이트	~1.5 KB	~6 KB	+300%
핸드셰이크 지연 시간 (p50)	~1 ms	~2.5 ms	+150%
핸드셰이크 검증당 CPU	~0.05 ms	~0.12 ms	+140%

게임 백엔드에 치명적이지 않은 이유

CDN-오리진 연결은 연결 풀링을 사용합니다. 단일 TLS 연결이 재활용되기 전에 수천 개의 HTTP 요청을 처리합니다. 1.5ms의 추가 핸드셰이크 지연 시간은 예를 들어 10,000개의 요청에 분산됩니다 — 요청당 0.00015ms입니다. 사실상 무료입니다.

성능 영향은 두 가지 시나리오에 집중됩니다:

1. 콜드 스타트 / 연결 설정 급증: 게임 출시, 시즌 이벤트, 바이럴 순간 — 오리진이 초당 수천 개의 새 TLS 연결을 처리할 때입니다. 현재 오리진이 초당 50,000개의 ECDSA 핸드셰이크를 처리한다면, 동일한 하드웨어에서 초당 약 20,000~25,000개의 ML-DSA-44 핸드셰이크를 예상하세요. 그에 따라 용량을 계획하세요.

2. 짧은 수명의 연결: 아키텍처가 요청당 새 TLS 연결을 생성하는 경우(하지 마세요), 모든 요청이 전체 핸드셰이크 비용을 지불합니다. PQ 인증으로 마이그레이션하기 전에 연결 풀링과 지속적인 연결로 이 문제를 해결하세요.

대역폭 영향

새 연결당 약 4.5KB의 추가 핸드셰이크 데이터는 HTTP/2 또는 HTTP/3 멀티플렉싱 연결에서 무시할 수 있습니다. 긴 수명 연결을 가진 WebSocket 기반 게임 프로토콜의 경우 핸드셰이크는 연결 수명당 한 번 발생합니다 — 대역폭 예산에 영향을 미치지 않습니다.

PQ 게임 백엔드 마이그레이션 모범 사례

1. PQ 암호화를 먼저 활성화하고 인증은 그 다음에. 오리진 연결에 대해 포스트퀀텀 키 교환(X25519Kyber768)을 아직 켜지 않았다면 인증서를 다루기 전에 먼저 하세요. 구성 변경만으로 가능하며(새 인증서 불필요), 즉시 수확-후-나중-복호화 공격으로부터 보호합니다.

2. ML-DSA-44를 배포하고 ML-DSA-87은 피하세요. 군사용 기밀 시스템을 보호하는 것이 아니라면 ML-DSA-44는 NIST Category 2에서 충분한 보안 마진을 제공합니다. ML-DSA-87은 핸드셰이크 오버헤드를 약 두 배로 늘리며, 거의 확실히 위협 모델에 필요하지 않은 미미한 보안 이점을 제공합니다.

3. 전환 중 듀얼 스택을 실행하고, 그런 다음 고전적 방식을 무자비하게 제거하세요. 고전적 및 PQ 인증서를 병렬로 배포합니다. 최소 2주 동안 모니터링합니다. 고전적 폴백 연결이 0임을 확인합니다. 그런 다음 고전적 신뢰를 완전히 제거합니다. 고전적 폴백을 남겨두는 것은 PQ 마이그레이션에서 가장 흔한 실수입니다 — 값비싼 새 인증서를 보안 쇼로 만듭니다.

4. 첫날부터 키 순환을 자동화하세요. ML-DSA의 32바이트 시드 형식이 이를 실용적으로 만듭니다. 배포 파이프라인에 인증서 순환을 구축하세요. 분기별로 순환하세요 — 암호화가 약해져서가 아니라, 운영상의 키 위생(유출된 자격 증명, 퇴사한 엔지니어, 손상된 CI/CD)이 실제 취약점이기 때문입니다.

5. 연결 변동률(churn rate)을 프로파일링하세요. 오리진 서버에서 ss -s 또는 동등한 명령어를 실행하여 피크 및 비피크 시간대의 초당 새 연결 수를 계산하세요. 핸드셰이크 오버헤드 델타(~1.5ms CPU, ~4.5KB 대역폭)를 곱하세요. 이렇게 하면 마이그레이션에 대한 구체적인 용량 계획 수치가 제공됩니다.

게임 백엔드에 대한 의미

포스트퀀텀 일정은 더 이상 학문적이지 않습니다. NIST는 ML-DSA를 표준화했습니다. 주요 인프라 제공업체는 프로덕션에 배포하고 있습니다. 정부 명령이 채택을 가속화하고 있습니다. 문제는 게임 백엔드에 PQ 인증이 필요한지 여부가 아니라, 마이그레이션을 언제 시작할지입니다.

자체 오리진 인프라를 관리하는 팀의 경우 작업은 실질적이지만 범위가 제한적입니다: 새 인증서 체인 생성, 서버 구성 업데이트, 신뢰 저장소 수정, 테스트, 고전적 폴백 제거. 각 단계는 몇 시간 작업입니다. 총합하면 TLS에 익숙한 백엔드 엔지니어에게 1~2주 프로젝트입니다.

이 몇 주를 게임플레이에 쓰고 싶다면, horizOn은 백엔드 플랫폼의 일부로 TLS 종단, mTLS 및 인증서 관리를 처리합니다 — PQ 마이그레이션이 몇 주 인프라 프로젝트 대신 구성 변경으로 실행되도록 하여 기능을 출시할 수 있습니다.

지금 시작하세요. 프로덕션 오리진에 대해 1단계의 감사 명령어를 실행하세요. 인증서가 사용하는 서명 알고리즘을 확인하세요. RSA 또는 ECDSA라면 2026~2027년 로드맵에 PQ 인증 마이그레이션을 추가하세요. 플레이어 데이터를 노리는 양자 컴퓨터는 여러분이 준비할 때까지 기다리지 않습니다.

---

출처: 포스트퀀텀 오리진 인증이 이제 지원됩니다