Постквантовий перехід уже вийшов за межі урядових документів і наукових статей: для великого бізнесу це стає довгостроковою програмою змін. У подкасті IBM Security Intelligence віцепрезидентка з продуктової безпеки Suja Viswesan та глобальний керівник Cybersecurity Services Mark Hughes детально розбирають, що означає «crypto agility» на практиці і як будувати до неї системну дорожню карту.
Йдеться не лише про впровадження нових алгоритмів шифрування. Це зміна того, як організація в принципі поводиться з криптографією — від архітектури застосунків до роботи з постачальниками і власним кодом.
Чому «старих практик» уже недостатньо
Кібербезпека сьогодні одночасно переживає дві хвилі: стрімкий розвиток ШІ та поступовий вихід квантових обчислень на «криптографічно релевантний» рівень. За словами Марка Г’юза, у фундаментальних речах кіберзахисту мало що змінюється — але змінюється темп.
Він формулює це так: є «великий цунамі» з фронтирних моделей ШІ, впровадження самого ШІ у бізнес‑процеси, а поряд — квантова загроза до асиметричної криптографії. Базові принципи керування ризиками, інвентаризації активів, захисту ідентичностей залишаються, але «одна річ усе-таки змінюється — ми маємо пришвидшитися. Нам треба робити багато знайомих речей, просто робити їх набагато швидше».
Причина — складність сучасних ІТ‑екосистем. Криптографія пронизує апаратне забезпечення, програму, мережі та інтеграції з партнерами. Переписати все в останній момент, коли квантові машини стануть достатньо потужними, практично нереально. Власне, тому концепція Q‑Day як «однієї дати» поступається місцем розумінню багаторічного процесу.
Старт із прозорості: чому discovery важливіший за алгоритми
Ключова відправна точка у постквантовій трансформації — банальне, але складне запитання: де у вас живе криптографія?
Марка Г’юза це формулює прямо: «Просто дійти до точки discovery — це дуже важливий крок у всьому цьому. Це взагалі не про якісь складні алгоритми. Це про те, щоб почати з питання: що у вас уже є і що ви знаєте про сьогоднішній стан?»
Йдеться не лише про сертифікати TLS на периметрі. Потрібно бачити:
- які алгоритми зашиті у ваші застосунки й бібліотеки;
- як працює PKI всередині організації;
- де й як зберігаються ключі;
- як взаємодіють між собою різні системи, включно з продуктами постачальників.
Коли цього огляду немає, будь-який подальший «перехід на PQC» ризикує звестися до точкових латок і непередбачених збоїв на стику систем. Г’юз окремо підкреслює вимір ланцюга постачання: навіть якщо у вас усе модернізовано, але ваші партнери змінюють криптографію, а ви — ні (або навпаки), на вас чекають проблеми з сумісністю.
Саме тому, за його оцінкою, зволікання з discovery створює загрозу опинитися у ситуації, коли «інші вже змінюються довкола вас, а ви ще не встигли навіть нормально розібратися з власними артефактами».
Від «проєкту» до циклу: п’ять етапів трансформації
Suja Viswesan наголошує: ставитися до постквантового переходу як до чергового великого ІТ‑проєкту — помилка. «Це не “project project”. Це трансформація», — підкреслює вона.
Вона описує безперервний цикл із п’яти кроків, який має стати новою нормою:
-
Strategize – спочатку стратегія
Потрібно врахувати одразу кілька площин: апаратне забезпечення, програму, мережі, а також постачальників. Якщо якийсь ключовий вендор не планує бути постквантово готовим, це для вас вже міграційний сценарій, а не косметичне оновлення. Сюди ж входить планування апаратних оновлень і політик щодо сертифікатів. -
Assess – оцінювання й discovery
Це той самий етап прозорості, про який говорить Г’юз. Виявити всі сертифікати, алгоритми, ключі, залежності в коді й продукти третіх сторін. Без оцінки немає адекватних пріоритетів. -
Modernize – модернізація
На основі стратегії та карти активів формується план модернізації: де, як і в якій послідовності оновлювати криптографію, як змінювати процеси керування ідентичностями, як вплітати нові алгоритми у вже існуючі протоколи. -
Govern – управління
Трансформація має бути керованою: потрібні правила, які не дають системі «з’їхати» назад до ручних практик чи розрізнених рішень у командах. Візвесан говорить про необхідність «управляти й стежити, щоб усе не відхилялося від курсу». -
Remediate – виправлення, коли настане день
Коли алгоритми, стандарти та рекомендації остаточно формалізуються, організація має бути в стані швидко й контрольовано переформатовувати свою криптографію. «Коли альґоритми будуть доступні, ви маєте бути готові бути agile і remediate. І цикл продовжується», — пояснює вона.
Цей цикл не має «кінцевої дати». Візвесан прямо говорить, що це коло, яке постійно обертається: strategize – assess – modernize – govern – remediate – і знову спочатку.
Crypto agility як ціль: криптографія за моделлю оновлення ПЗ
Фінальна мета цього циклу — стан, який співрозмовники називають crypto agility. Suja Viswesan дає просте, але показове визначення: «Crypto agility — це здатність змінювати вашу криптографію так само легко, як оновлення програмного забезпечення».
Сьогодні більшість організацій живуть в іншій реальності. Зміна алгоритмів, ключових розмірів або схем PKI часто тягне за собою роки робіт, численні зміни в коді, регресії, непередбачені простої та складні узгодження з партнерами.
У crypto‑agile‑стані все має працювати інакше: «Ми хочемо бути в ситуації, коли ви просто оновлюєте її, як оновлюєте софт, замість того, щоб щоразу робити гігантську трансформацію», — підсумовує вона.
Г’юз додає: трансформаційна мапа — це не лише про вибір нових криптоартефактів на заміну старим. Це про перехід до режиму, де постійна зміна криптографії — штатна операція, а не надзвичайна подія.
Для багатьох ІТ‑керівників ця перспектива виглядає незвичною і навіть дискомфортною: «Це не “зробив і забув”. Це тривалий, постійний процес crypto agility… Дехто сприймає це непросто, бо це про постійну зміну». Водночас він бачить у цьому й «велику можливість» — відмовитися від статичності, яка дедалі гірше узгоджується з реальністю ШІ та квантових обчислень.
Архітектура майбутнього: відв’язати криптографію від застосунків
Щоб crypto agility стала реальною, її потрібно закладати в архітектуру ще на стадії проєктування. Тут Suja Viswesan окреслює кілька принципових вимог до майбутніх систем.
По‑перше, архітектура має одразу проєктуватися з урахуванням майбутньої зміни криптографії: «Коли ви архітектурите, переконайтесь, що закладаєте це в архітектуру».
По‑друге, критично важливе розділення застосунків і криптографії. Вона радить «відокремлювати криптографію від застосунку, щоб вона не була вшита безпосередньо в нього». Криптографія має виступати як сервіс, до якого застосунок звертається, коли потрібно — аналогія з тим, як клієнт сьогодні звертається до мовної моделі, а не вбудовує її код усередину себе.
По‑третє, потрібна автоматизація життєвого циклу. Якщо строк дії сертифіката спливає, система не має «раптово» дізнаватись про це через падіння сервісів. Оновлення, ротація, заміна — мають бути автоматизованими, а не реактивними.
І нарешті, необхідні чіткі правила управління. Візвесан говорить про «чисте управління», коли зміни відбуваються систематично, а не як відповідь на локальні інциденти чи зовнішні вимоги.
Усе це разом і створює той самий фундамент, на якому криптографія зможе змінюватися за потреби, не руйнуючи всю конструкцію.
IBM як «лабораторія crypto agility»: власний шлях і уроки
У розмові прозвучав і важливий момент: великі постачальники технологій проходять цей шлях паралельно зі своїми клієнтами. Suja Viswesan наводить приклад самої IBM: компанія «просканувала тисячі репозиторіїв, мільйони рядків коду, вибудовуючи cryptographic bill of materials».
Ця криптографічна специфікація коду дає змогу точно знати, які алгоритми і бібліотеки де використані, як вони пов’язані з продуктами і сервісами. IBM, за її словами, «у тій самій подорожі — ми і вендор, і організація, що сама проходить трансформацію, і вчимося в процесі, а потім ділимося цим із клієнтами».
Фактично великі гравці стають полігоном для відпрацювання практик crypto agility на складних, об’ємних кодових базах — із усіма типовими проблемами, які мають і великі замовники: історичний техборг, старі алгоритми, залежності, вимоги до безперервності сервісів.
Час стартувати раніше, а не бігти швидше
Наприкінці розмови співрозмовники повертаються до питання таймінгу. Сьогодні, за оцінкою Візвесан, приблизно третина ринку «принаймні почала цю подорож» і перебуває на ранніх етапах — стратегування і discovery. Вона вважає цього замало, з огляду на масштаб завдання і темпи зростання цифрових ідентичностей.
Окремо вона зауважує, що кількість небудь «не‑людських» ідентичностей — сертифікатів, сервісних акаунтів, машин‑обліковок — зростає експоненційно. Це множить точки, де застосовується криптографія, і прискорює потребу в автоматизації.
Її висновок лаконічний: «Для мене переможцями стануть не ті, хто рухається найшвидше, а ті, хто починає раніше». Запізнілий старт означає роботу в умовах дедлайнів, регуляторного тиску, вимог великих партнерів і високих витрат. Ранній — дозволяє розподілити трансформацію в часі й перетворити crypto agility на природне продовження еволюції ІТ‑ландшафту, а не на антикризовий захід.
Висновок: crypto agility як новий стандарт безпеки
Постквантова криптографія — лише один шар майбутньої безпеки. Над ним лежить питання того, наскільки організація здатна системно й безболісно змінювати свою криптографію разом із розвитком загроз та алгоритмів.
Звідси й зсув парадигми: від точкових міграцій до безперервного циклу strategize–assess–modernize–govern–remediate. В основі цього циклу — прозора інвентаризація, архітектури, в яких криптографія є сервісом, а не «вшитим» модулем, автоматизовані життєві цикли сертифікатів та кероване управління.
Це «серйозна річ» і «справжня трансформація, — підкреслює Марк Г’юз, — не лише у сенсі великого проєкту, а як зміна того, як ви працюєте». І саме crypto agility стає мірилом того, наскільки організація готова до епохи, де криптографія перестає бути чимось статичним і раз і назавжди заданим.