Постквантовая аутентификация для игровых серверов: руководство по миграции на ML-DSA с кодом и данными производительности

Опубликовано 31 июля 2026 г.

Коротко о главном

Мигрируйте игровые серверы на постквантовую аутентификацию ML-DSA: полный пошаговый план, примеры кода, производительность и рекомендации.

Криптографические подписи, аутентифицирующие TLS-соединения вашего игрового сервера, находятся в одном алгоритмическом прорыве от возможности подделки. RSA-2048 и ECDSA-P256 — алгоритмы сертификатов, защищающие данные игроков между вашим CDN и исходным сервером, — падут перед алгоритмом Шора на достаточно мощном квантовом компьютере. Не теоретически. По временной шкале, которую Microsoft, Google и правительство США активно планируют уже в 2026 году.

Cloudflare только что запустил постквантовую аутентификацию для соединений с источниками, используя ML-DSA (Module-Lattice-Based Digital Signature Algorithm), стандартизированный как FIPS 204. Это первое промышленное развёртывание PQ-аутентификации в масштабе — на сети, обрабатывающей примерно 20% веб-трафика. Если ваш игровой бэкенд находится за любым уровнем, завершающим TLS, эта миграция затронет вашу инфраструктуру. И чем раньше вы начнёте, тем менее болезненным будет переход.

Этот пост — ваше руководство: что ломается, как это обнаружить, как исправить с помощью реальных команд и кода, и как предотвратить превращение вашего игрового бэкенда в слабое звено.

Почему игровые серверы особенно уязвимы

Игровые бэкенды — это не типичные веб-сервисы. Они поддерживают постоянные соединения для синхронизации состояния в реальном времени, хранят месяцы или годы данных о прогрессе игроков и обрабатывают критически важные операции, такие как управление инвентарём и обработка платежей. Модель угроз для постквантовых атак на игровые серверы конкретна:

Учётные данные игроков и токены сессий, передаваемые между вашим CDN-прокси и исходным API
Данные внутриигровой экономики — балансы виртуальной валюты, инвентари предметов, истории торговли, имеющие реальную стоимость на вторичных рынках
Платёжные вебхуки, если ваш бэкенд обрабатывает покупки на стороне сервера
Сигналы античита, которые, будучи раскрытыми, позволяют злоумышленникам провести реверс-инжиниринг ваших эвристик обнаружения

Атака, от которой мы защищаемся, — это не пассивный сбор данных. Это активная подмена: злоумышленник, обладающий квантовыми возможностями, подделывает учётные данные аутентификации вашего CDN и внедряет вредоносные полезные нагрузки непосредственно в ваш игровой API. Это принципиально иная угроза, чем «собери сейчас, расшифруй потом».

Мы описали, что происходит, когда архитектура безопасности бэкенда выходит из строя под давлением — постквантовая аутентификация — это следующая эволюция той же оборонительной позиции. Вопрос не в том, столкнётся ли ваша игра с изощрёнными атаками, а в том, выдержит ли ваша инфраструктура эти атаки.

Шифрование против аутентификации: что на самом деле ломается

Существует критическое различие, которое постоянно путают: постквантовое шифрование и постквантовая аутентификация — это разные проблемы с разными временными рамками и решениями.

Постквантовое шифрование (уже развёрнуто)

Обмен ключами TLS 1.3 с использованием гибридных алгоритмов, таких как X25519Kyber768, уже широко распространён. Cloudflare включил PQ-шифрование как для соединений посетитель-CDN, так и для соединений CDN-источник в 2022–2023 годах. Это защищает данные в пути от атак «собери сейчас, расшифруй потом».

Постквантовая аутентификация (новый рубеж)

Аутентификация — это то, где сейчас находится реальный риск. Когда ваш исходный сервер предъявляет TLS-сертификат, подписанный с помощью RSA-2048 или ECDSA-P256, квантовый компьютер, работающий по алгоритму Шора, может подделать эту подпись в реальном времени. Это позволяет проводить атаки «человек посередине» — не пассивную запись, а активное перехватывание и манипулирование вашим игровым трафиком.

Вот как разбиваются два соединения в типичной игровой архитектуре:

┌─────────────┐    Соединение 1    ┌─────────────┐    Соединение 2    ┌─────────────┐
│  Игровой     │ ════════════════► │    CDN /    │ ════════════════► │   Источник  │
│  клиент      │                    │   Прокси    │                    │  (Ваш API)  │
│  (Игрок)     │                    │             │                    │             │
└─────────────┘                    └─────────────┘                    └─────────────┘
                                    │                                      │
                              PQ-шифрование ✓                       PQ-шифрование ✓
                              PQ-аутентификация                    PQ-аутентификация
                              (через MTC, 2027)                    (ML-DSA, СЕЙЧАС)
                                    │
                              Классические
                              сертификаты
                              аутентификации здесь
                              — текущее слабое
                              звено

Соединение 2 — от вашего CDN или обратного прокси к вашему источнику — это то, где PQ-аутентификация может быть развёрнута прямо сейчас. Это соединение переносит действия игроков, обновления инвентаря, запросы на подбор игроков и платёжные вебхуки. Если злоумышленник подделает аутентификацию на этом соединении, он завладеет вашим бэкендом.

Почему соединение 2 идёт первым

Соединение CDN-источник имеет структурные преимущества, которые делают PQ-аутентификацию практичной на годы раньше, чем в публичном интернете:

Контролируемый TLS-клиент: CDN управляет пулом соединений и поведением рукопожатия, амортизируя накладные расходы PQ на тысячи запросов
Существующие доверительные отношения: у вас уже есть отношения с вашим CDN — нет зависимости от публичной инфраструктуры центров сертификации
Собственный PKI: вы можете запускать собственные центры сертификации, избегая ограничений WebPKI и требований Certificate Transparency
Повторное использование соединений: CDN поддерживают постоянные соединения с источниками, что означает, что PQ-рукопожатия происходят нечасто по сравнению с общим объёмом запросов

Вот почему Cloudflare может развернуть ML-DSA-аутентификацию для соединений с источниками сегодня, в то время как публичный интернет ждёт Merkle Tree Certificates (целевой срок — 2027).

ML-DSA: алгоритм, лежащий в основе PQ-аутентификации

ML-DSA, стандартизированный как NIST FIPS 204, основан на сложности решёточных задач — математических структур, которые, как считается, устойчивы как к классическим, так и к квантовым атакам. Это основной алгоритм, развёртываемый для постквантовых цифровых подписей по всей индустрии.

Наборы параметров и уровни безопасности

Набор параметров	Уровень безопасности	Открытый ключ	Подпись	Накладные расходы рукопожатия
ML-DSA-44	NIST Cat 2 (~AES-128)	1 312 Б	2 420 Б	~4,5 КБ дополнительно
ML-DSA-65	NIST Cat 3 (~AES-192)	1 952 Б	3 293 Б	~6,5 КБ дополнительно
ML-DSA-87	NIST Cat 5 (~AES-256)	2 592 Б	4 595 Б	~9 КБ дополнительно

Для сравнения, подпись ECDSA-P256 имеет размер 64 байта с открытым ключом 64 байта. Подписи ML-DSA-44 примерно в 37 раз больше. Это основной компромисс, и именно это число заставляет разработчиков нервничать.

ML-DSA-44 — правильный выбор для игровых бэкендов. Он обеспечивает безопасность NIST Category 2 — комфортные запасы против известных квантовых и классических атак — и при этом является наиболее производительным вариантом. Больший размер подписи управляем, поскольку пулы соединений делают рукопожатия нечастыми по сравнению с общим трафиком.

Формат seed FIPS 204: компактное хранение ключей

Закрытые ключи ML-DSA поддерживают формат seed — 32-байтовое случайное значение, из которого детерминированно выводится полный закрытый ключ:

Seed (32 байта) ──► Детерминированное расширение ──► Полный закрытый ключ (2 560 байт для ML-DSA-44)

Это практическое преимущество для инфраструктуры игрового бэкенда. Вместо хранения 2 560-байтовых закрытых ключей в вашем менеджере секретов или переменных окружения вы храните 32 байта и выводите полный ключ по запросу. Ротация ключей сводится к генерации и распространению нового seed — операционно гораздо проще, чем управление традиционными RSA-ключами.

Руководство по миграции: пошагово

Шаг 1: Аудит текущей конфигурации TLS

Прежде чем что-то трогать, поймите, что у вас работает. Проверьте текущую цепочку сертификатов вашего исходного сервера и алгоритмы подписей:

# Проверьте сертификат, который предъявляет ваш источник
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"

# Проверьте поддерживаемые версии TLS и наборы шифров
nmap --script ssl-enum-ciphers -p 443 your-game-api.example.com

# Если используется mTLS, проверьте, какой клиентский сертификат предъявляет ваш CDN
# (захватите во время тестового запроса с помощью tcpdump или аналогов)
tcpdump -i eth0 -w tls_handshake.pcap port 443 -c 50

Задокументируйте этот базовый уровень. Он понадобится для отката и для подтверждения того, что миграция ничего не сломала. Запишите:

Текущий алгоритм подписи (RSA-SHA256, ECDSA-SHA256 и т.д.)
Глубину цепочки сертификатов и все даты истечения
Используется ли уже mTLS
Поддерживаемые версии TLS (вы уже должны быть только на TLS 1.3)

Шаг 2: Генерация цепочек сертификатов ML-DSA

Вам понадобится провайдер Open Quantum Safe (OQS) для OpenSSL 3.0+:

# Установка 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

# Включите в openssl.cnf — добавьте в [provider_sect]:
# oqsprovider = oqsprovider_sect
# oqsprovider_sect = oqsprovider

# Генерация корневого CA ML-DSA-44 (срок действия 10 лет)
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"

# Генерация запроса на подпись сертификата исходного сервера
openssl req -new -newkey mldsa44 \
  -keyout mldsa44-server.key -out mldsa44-server.csr \
  -nodes -subj "/CN=your-game-api.example.com"

# Подписание серверного сертификата PQ CA (срок действия 1 год для гигиены ротации)
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 (идентификация вашего CDN)
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

# Проверка цепочки
openssl verify -CAfile mldsa44-ca.crt mldsa44-server.crt
openssl verify -CAfile mldsa44-ca.crt mldsa44-client.crt

Примечание по управлению ключами: где возможно, храните 32-байтовый seed вместо полного 2 560-байтового закрытого ключа. Это упрощает ротацию секретов и уменьшает поверхность атаки в менеджерах секретов и переменных окружения.

Шаг 3: Настройка исходного сервера для PQ mTLS

Конфигурация Nginx:

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

    # Серверный сертификат ML-DSA-44
    ssl_certificate     /etc/ssl/pq/mldsa44-server.crt;
    ssl_certificate_key /etc/ssl/pq/mldsa44-server.key;

    # Проверка клиента (mTLS) — доверять только PQ CA
    ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # Только TLS 1.3 — без понижения до старых версий
    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;
    }

    // Принудительное использование TLS 1.3 — понижение версии невозможно
    SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);

    // Загрузка серверного сертификата ML-DSA-44
    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
    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;
    }

    // Проверка соответствия ключа сертификату
    if (SSL_CTX_check_private_key(ctx) != 1) {
        fprintf(stderr, "Key/cert mismatch\n");
        SSL_CTX_free(ctx);
        return nullptr;
    }

    // Загрузка PQ CA для проверки клиентских сертификатов
    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;
    }

    // Требовать и проверять клиентские сертификаты
    SSL_CTX_set_verify(ctx,
        SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,
        nullptr);

    return ctx;
}

// Использование в цикле accept вашего игрового сервера:
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) {
        // Рукопожатие не удалось — вероятно, проблема с клиентским сертификатом
        ERR_print_errors_fp(stderr);
        SSL_free(ssl);
        close(client_fd);
        return;
    }

    // Проверка, что клиентский сертификат действительно был предъявлен
    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;
    }

    // Клиент аутентифицирован через ML-DSA mTLS — продолжаем
    X509_free(client_cert);
    // ... обработка игрового протокола ...
}

Шаг 4: Обновление хранилища доверенных сертификатов вашего CDN/прокси

Если вы используете Cloudflare, загрузите ваш ML-DSA CA-сертификат в Custom Origin Trust Store и настройте Authenticated Origin Pulls с вашим ML-DSA клиентским сертификатом:

Загрузите mldsa44-ca.crt в пользовательское хранилище доверенных сертификатов вашего CDN
Загрузите mldsa44-client.crt и mldsa44-client.key для аутентифицированных обращений к источнику
Установите режим SSL в Full (strict), чтобы принудительно проверять сертификаты с использованием вашего пользовательского хранилища

Если вы используете собственную прокси-инфраструктуру, вам потребуется распространить PQ CA-сертификат на все узлы прокси, настроить клиентские сертификаты для каждого и настроить мониторинг истечения срока действия сертификатов. Управление этим вручную в нескольких регионах и масштабируемых группах — это то, где операционная сложность нарастает; автоматизированное распространение и ротация сертификатов становятся необходимыми.

Шаг 5: Тестирование PQ-рукопожатия

# Проверка успешного ML-DSA mTLS рукопожатия
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)"

# Ожидаемый вывод:
#   Verify return code: 0 (ok)
#   Protocol  : TLSv1.3
#   Cipher    : TLS_AES_256_GCM_SHA384

# Измерение задержки рукопожатия под нагрузкой
# (настройте скорость соединений, чтобы имитировать условия запуска)
wrk -t4 -c100 -d30s --latency \
  --script=pq_mtls_test.lua \
  https://your-game-api.example.com/api/health

Что отслеживать во время тестирования:

Задержка рукопожатия: Ожидайте дополнительные 0,5–2 мс на каждое новое соединение по сравнению с ECDSA-P256
Загрузка CPU: Проверка подписи ML-DSA примерно в 2–3 раза медленнее, чем проверка ECDSA
Уровень ошибок: Следите за ошибками проверки сертификатов во время перехода
Использование пула соединений: Убедитесь, что соединения используются повторно (амортизация стоимости рукопожатия)

Шаг 6: Удаление классических запасных вариантов

Это шаг, который на самом деле обеспечивает квантовую безопасность. Если ваш источник принимает любую классическую (RSA/ECDSA) аутентификацию, злоумышленник, обладающий квантовыми возможностями, сможет подделать эти учётные данные и обойти вашу PQ-защиту.

Сценарий атаки понижения версии:

Злоумышленник перехватывает рукопожатие CDN ↔ Источник
    │
    ├── Принуждает к переговорам с классической RSA-аутентификацией
    ├── Подделывает RSA-подпись с помощью алгоритма Шора
    └── Выдаёт себя за CDN перед вашим исходным сервером ✓

Ваши PQ-сертификаты бесполезны, если существуют классические запасные варианты.

Исправление: ваш исходный сервер должен доверять только ML-DSA-сертификатам для соединения CDN-источник.

# НЕПРАВИЛЬНО: смешанное хранилище — классические сертификаты всё ещё принимаются
ssl_client_certificate /etc/ssl/mixed-ca-bundle.crt;

# ПРАВИЛЬНО: хранилище только PQ — классические подделки отклоняются
ssl_client_certificate /etc/ssl/pq/mldsa44-ca.crt;

Критическое предупреждение: Удаляйте классическое доверие только после того, как убедитесь, что все соединения CDN используют PQ-аутентификацию. Преждевременное удаление нарушит связность вашего источника. Запустите двухстековую конфигурацию (шаги 3–5) как минимум на две недели, отслеживая, что ни одно соединение не возвращается к классической аутентификации, прежде чем удалять классическое доверие.

Влияние на производительность: реальные цифры для игровых бэкендов

Обоснованное беспокойство: подписи ML-DSA велики. Вот что это означает на практике.

Накладные расходы на уровне рукопожатия

Метрика	ECDSA-P256	ML-DSA-44	Дельта
Размер серверного сертификата	~500 Б	~1 700 Б	+240%
Размер подписи	64 Б	2 420 Б	+3 681%
Общий размер рукопожатия	~1,5 КБ	~6 КБ	+300%
Задержка рукопожатия (p50)	~1 мс	~2,5 мс	+150%
CPU на проверку рукопожатия	~0,05 мс	~0,12 мс	+140%

Почему это не разрушит ваш игровой бэкенд

Соединения CDN-источник используют пулинг соединений. Одно TLS-соединение обрабатывает тысячи HTTP-запросов, прежде чем быть переиспользованным. Дополнительная задержка рукопожатия в 1,5 мс амортизируется на, скажем, 10 000 запросов — это 0,00015 мс на запрос. Практически бесплатно.

Влияние на производительность концентрируется в двух сценариях:

Холодный старт / всплески установки соединений: Запуски игр, сезонные события, вирусные моменты — когда ваш источник обрабатывает тысячи новых TLS-соединений в секунду. Если ваш источник в настоящее время обрабатывает 50 000 рукопожатий ECDSA/сек, ожидайте примерно 20 000–25 000 рукопожатий ML-DSA-44/сек на эквивалентном оборудовании. Планируйте ёмкость соответствующим образом.
Короткоживущие соединения: Если ваша архитектура создаёт новое TLS-соединение на каждый запрос (пожалуйста, не делайте так), каждый запрос оплачивает полную стоимость рукопожатия. Исправьте это с помощью пулинга соединений и постоянных соединений перед миграцией на PQ-аутентификацию.

Влияние на пропускную способность

Дополнительные ~4,5 КБ данных рукопожатия на каждое новое соединение незначительны для мультиплексированных соединений HTTP/2 или HTTP/3. Для игровых протоколов на основе WebSocket с долгоживущими соединениями рукопожатие происходит один раз за время жизни соединения — не имеет значения для бюджетов пропускной способности.

Лучшие практики для миграции игровых бэкендов на PQ

Сначала включите PQ-шифрование, затем аутентификацию. Если вы ещё не включили постквантовый обмен ключами (X25519Kyber768) для ваших соединений с источником, сделайте это, прежде чем браться за сертификаты. Это изменение конфигурации — никаких новых сертификатов — и оно немедленно защищает от атак «собери сейчас, расшифруй потом».
Развёртывайте ML-DSA-44, а не ML-DSA-87. Если только вы не защищаете засекреченные военные системы, ML-DSA-44 обеспечивает комфортные запасы безопасности на уровне NIST Category 2. ML-DSA-87 примерно удваивает накладные расходы на рукопожатие ради незначительного повышения безопасности, которое ваша модель угроз почти наверняка не требует.
Запускайте двухстековую конфигурацию во время перехода — затем безжалостно удаляйте классику. Разверните параллельно как классические, так и PQ-сертификаты. Наблюдайте минимум две недели. Убедитесь, что нет ни одного классического соединения. Затем полностью удалите классическое доверие. Оставление классических запасных вариантов — самая распространённая ошибка при миграции на PQ; это превращает ваши дорогие новые сертификаты в театр безопасности.
Автоматизируйте ротацию ключей с первого дня. 32-байтовый формат seed ML-DSA делает это практичным. Встройте ротацию сертификатов в ваш конвейер развёртывания. Ротируйте ежеквартально — не потому, что криптоослабляется, а потому что операционная гигиена ключей (скомпрометированные учётные данные, ушедшие инженеры, скомпрометированный CI/CD) — это ваша реальная уязвимость.
Профилируйте скорость смены соединений. Запустите ss -s или его аналог на ваших исходных серверах, чтобы подсчитать количество новых соединений в секунду в пиковые и непиковые периоды. Умножьте на дельту накладных расходов на рукопожатие (~1,5 мс CPU, ~4,5 КБ пропускной способности). Это даст вам конкретную цифру для планирования ёмкости при миграции.

Что это означает для вашего игрового бэкенда

Временная шкала постквантовой эры больше не является академической. NIST стандартизировал ML-DSA. Крупные поставщики инфраструктуры развёртывают его в промышленной эксплуатации. Государственные мандаты ускоряют внедрение. Вопрос не в том, нужна ли вашему игровому бэкенду PQ-аутентификация — а в том, когда вы начнёте миграцию.

Для команд, управляющих собственной инфраструктурой источника, работа реальна, но ограничена: сгенерировать новые цепочки сертификатов, обновить конфигурации серверов, изменить хранилища доверенных сертификатов, протестировать и удалить классические запасные варианты. Каждый шаг — это несколько часов работы. В совокупности это проект на одну-две недели для инженера бэкенда, который хорошо знаком с TLS.

Если вы предпочтёте потратить эти недели на геймплей, а не на криптографическую инфраструктуру, horizOn обрабатывает завершение TLS, mTLS и управление сертификатами как часть своей платформы бэкенда — позволяя вам выпускать функции, пока миграция на PQ выполняется как изменение конфигурации, а не как многонедельный инфраструктурный проект.

Начните сегодня. Выполните команды аудита из Шага 1 на вашем промышленном источнике. Проверьте, какой алгоритм подписи используют ваши сертификаты. Если это RSA или ECDSA, добавьте миграцию на PQ-аутентификацию в ваш план на 2026–2027 годы. Квантовые компьютеры, нацеленные на данные ваших игроков, не будут ждать, пока вы будете готовы.

Источник: Постквантовая аутентификация для источников теперь поддерживается

Управление инфраструктурой игровых серверов: Runbook по масштабированию для запуска контента с нулевым временем простоя

Предыдущая запись Управление инфраструктурой игровых серверов: Runbook по масштабированию для запуска контента с нулевым временем простоя