Міграція до постквантової криптографії: як почати інвентаризацію до дедлайнів 2030/2031

Сигнал, який не варто відкладати

У червні 2026 року Executive Order 14409 задав для американських федеральних систем із високою цінністю і високим впливом конкретні дедлайни: перейти на постквантове узгодження ключів до 31 грудня 2030 року, а на постквантові цифрові підписи до 31 грудня 2031 року. Це не означає, що кожна українська команда має завтра міняти всі сертифікати. Але це означає, що ринок отримав чіткий сигнал: міграція з “колись потім” переїхала в планування.

Якщо коротко, постквантова криптографія — це не “квантове шифрування”. Це новіші методи шифрування й цифрових підписів, які готують до світу, де квантові комп’ютери зможуть ламати частину старих алгоритмів швидше, ніж звичайні комп’ютери.

Найкорисніший перший крок для звичайної інженерної команди — не купити “quantum-safe” продукт, а зробити інвентаризацію криптографії. Треба зрозуміти, де саме ваша система покладається на TLS, VPN, SSH, підписи коду, сертифікати, бібліотеки, апаратні ключі й довгоживучі дані. Без цієї карти будь-яка міграція буде більше схожа на гру в темній кімнаті.

Не всі криптографічні ризики однаково термінові

У постквантовій міграції є дві великі категорії, які легко змішати.

Перша — узгодження ключів і шифрування. Це те, як браузер, API, VPN або інший клієнт домовляються про ключ для зашифрованого з’єднання. Тут небезпека має довгий хвіст: трафік можна записати зараз, а спробувати розшифрувати пізніше. Якщо дані залишаються цінними роками, ризик “зібрати зараз, розшифрувати потім” уже має значення.

Друга — цифрові підписи. Це підписи пакетів, контейнерів, релізів, документів, сертифікатів і прошивок. Їхня задача — підтвердити, що об’єкт справжній і не змінений. Для підписів теж потрібна міграція, але пріоритет часто залежить від строку життя артефакту, ланцюга довіри й того, як довго підпис має залишатися перевірним.

Тому питання не “чи треба постквантова криптографія?”, а “де в нас шифрування, де підписи, де довгоживучі дані, і що має змінитися першим?”.

Перша інвентаризація за один робочий слот

Почніть не з алгоритмів, а з поверхні системи. Для першого проходу достатньо простого документа, який не містить секретів.

1. Web і API

Запишіть, де закінчується TLS: CDN, балансувальник навантаження, вхідний шлюз, origin-сервер, сервісна сітка, API gateway. Окремо позначте шлях від клієнта до краю мережі, від краю мережі до origin-сервера і внутрішні з’єднання між сервісами. Якщо постквантовий режим увімкнений лише на краю мережі, це ще не означає, що весь шлях готовий.

Перевірте, чи використовується TLS 1.3, які клієнти реально підключаються, чи є старі мобільні застосунки, вбудовані пристрої або корпоративні проксі, які можуть зламатися від нових налаштувань.

2. VPN, SSH і адмін-доступи

VPN і SSH часто живуть довше, ніж вебконфіги. Подивіться, які рішення використовують команди, підрядники, CI, bastion host для адмін-доступу й аварійні доступи. Важливо не вставляти ключі в інвентаризацію. Достатньо назви системи, відповідального, типу ключів, строку ротації й того, чи є план постачальника для постквантової криптографії.

3. Підпис коду, підпис пакетів і CI

Підписи коду часто непомітні, поки все працює. Знайдіть, де підписуються релізи, пакети, контейнерні образи, mobile builds, firmware, SBOM або attestations. Тут важливо розуміти, хто перевіряє підпис і як довго цей підпис має бути дійсним.

4. Сертифікати, PKI і hardware-залежності

Якщо у вас є внутрішня PKI, HSM, смарткартки, TPM або спеціальні апаратні модулі, внесіть їх у карту окремо. Саме такі місця часто стають вузьким горлом, бо їх не можна оновити так само швидко, як npm-пакет.

5. Дані з довгим строком цінності

Окремо позначте дані, які мають залишатися конфіденційними 5-10 років: персональні дані, медичні записи, фінансові документи, юридичні архіви, комерційні таємниці, резервні копії. Якщо такі дані ходять через мережу або лежать у backup-архівах, вони потрапляють у зону “зібрати зараз, розшифрувати потім”.

Як читати стандарти, а не рекламні обіцянки

NIST уже стандартизував основні постквантові алгоритми: ML-KEM для узгодження ключів, ML-DSA і SLH-DSA для цифрових підписів. Це не означає, що треба вручну вписувати назви алгоритмів у кожен сервіс. Але це означає, що при розмові з постачальником треба питати не “ви quantum-safe?”, а конкретніше:

• які стандартизовані NIST алгоритми підтримуються;
• чи використовується гібридне узгодження ключів;
• де саме працює постквантовий режим: клієнт-край мережі, край мережі-origin, внутрішній трафік;
• які клієнти або бібліотеки ще не підтримуються;
• як виглядає відкат, якщо частина трафіку ламається;
• як довго старі підписи й сертифікати залишатимуться перевірними.

Cloudflare у своїх матеріалах правильно підкреслює практичну сторону: готовність залежить не від одного перемикача, а від меж з’єднання, клієнтів, origin-серверів і внутрішніх систем. Це хороший спосіб мислити і поза Cloudflare.

Backlog на 30/90/180 днів

Не треба робити міграцію одним великим ривком. Краще скласти маленький список задач.

Перші 30 днів

Зберіть інвентаризацію криптографії без секретів. Призначте відповідального для кожного рядка. Розділіть шифрування, узгодження ключів і цифрові підписи. Позначте довгоживучі дані. Додайте питання про плани постачальників для CDN, VPN, хмарних сервісів, PKI, HSM і основних бібліотек.

До 90 днів

Виберіть одну перевірку з низьким ризиком. Наприклад, перевірити готовність постквантового режиму на краю мережі для частини тестового трафіку, або перевірити, які інструменти збірки й підпису вже мають план підтримки ML-DSA чи SLH-DSA. Додайте спостереження: затримку, помилки TLS, частку клієнтів, які не підтримують потрібні параметри.

До 180 днів

Перетворіть інвентаризацію на план міграції. Для кожної системи має бути статус: готово, заблоковано постачальником, заблоковано старими клієнтами, потребує тесту, потребує зміни архітектури. Окремо заплануйте криптографічну гнучкість: як міняти алгоритми, ключі й сертифікати без екстреного переписування всієї системи.

Типові помилки

Перша помилка — думати, що постквантова криптографія стосується лише державних систем США. Реально регуляторні сигнали швидко доходять до підрядників, SaaS, критичної інфраструктури й команд із довгоживучими даними.

Друга — змішувати шифрування і підписи в один пункт “криптографія”. Через це команда може витратити час на менш терміновий шлях і пропустити дані, які вже сьогодні можна збирати для майбутнього розшифрування.

Третя — довіряти загальним обіцянкам постачальника. Фраза “quantum-safe” нічого не доводить без деталей: які стандарти, на якій межі з’єднання, для яких клієнтів, з яким відкатом.

Четверта — зберігати інвентаризацію з секретами. У документі мають бути системи, відповідальний, тип криптографії, ризики й наступні дії. Приватні ключі, сертифікати, токени та конфіденційні дані там не потрібні.

Висновок

Постквантова міграція не починається з героїчної заміни всіх алгоритмів. Вона починається з видимості. Де у вас TLS? Де VPN і SSH? Де підписуються релізи? Які дані залишаються цінними роками? Хто відповідальний за кожен шматок?

Якщо команда відповіла на ці питання, вона вже не в темряві. Далі можна спокійно перевіряти стандартизовані NIST алгоритми, плани постачальників, пілотні зони й криптографічну гнучкість. Дедлайни 2030/2031 виглядають далекими, але інвентаризацію краще зробити зараз, поки це ще планова робота, а не аварійна міграція.

Джерела

• White House: Securing the Nation Against Advanced Cryptographic Attacks
• Cloudflare Blog: The post-quantum EO is an important milestone. Now it's time to get to work
• NIST CSRC: Post-Quantum Cryptography
• Cloudflare Docs: Post-quantum cryptography (PQC)
• NIST NCCoE: Crypto Agility Considerations for Migrating to Post-Quantum Cryptographic Algorithms