"Security by design" - одна з тих фраз, яку зараз вставляють куди завгодно, і саме тому вона майже втратила зміст. Здебільшого нею позначають щось абстрактне: "ми думаємо про безпеку заздалегідь", без конкретики. Але в тексті CRA це не гасло і не побажання. Це перший пункт Annex I, і сформульований він так, що в ньому немає жодної лазівки.
Що там насправді написано
Annex I, Part I, пункт (1) CRA звучить так:
"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks."
Цифри за цим реченням не абстрактні. Коли Комісія пропонувала CRA, її власна оцінка була такою: щорічні втрати бізнесу в ЄС від data breaches складали щонайменше €10 млрд, а від атак типу disruption - щонайменше €65 млрд. Одна з широко цитованих оцінок називає глобальну вартість кіберзлочинності в €5.5 трильйона щороку. Саме такі цифри й пояснюють, навіщо цей закон взагалі існує.
Тобто: продукт з цифровими елементами має бути спроєктований, розроблений і вироблений так, щоб забезпечувати відповідний рівень кібербезпеки з урахуванням ризиків.
Звучить абстрактно, поки не подивишся на решту пункту (2). Там ідуть конкретні вимоги: захист від відомих вразливостей, secure-by-default конфігурація, механізми оновлень, захист від несанкціонованого доступу, і так далі, аж до пункту (m). Весь цей список починається зі слів "on the basis of the cybersecurity risk assessment... and where applicable", тобто "де застосовно". Це нормальне юридичне формулювання: якщо вимога не стосується вашого продукту, ви обґрунтовуєте це і пропускаєте.
У пункту (1) такого застереження немає. Жодного "where applicable". Це єдина вимога у всій Part I, яка застосовується завжди, без винятків, незалежно від типу продукту чи класу ризику. Ви не можете сказати регулятору "а в нашому випадку це не застосовується": вона не про технічну деталь. Вона про сам підхід до розробки.
Одне уточнення одразу: Annex I юридично набуває чинності 11 грудня 2027 року - до цієї дати він ухвалений, але ще не застосовується. Раніше (з 11 вересня 2026) діє лише звітування про вразливості за Article 14. Сьогодні ніхто формально не зобов'язаний виконувати пункт (1). Але саме тому цей принцип варто закладати вже зараз: архітектурні рішення, які визначають, чи пройде продукт Annex I у 2027-му, приймаються на роки раніше за сам дедлайн. Чекати грудня 2027-го, щоб почати думати про це - означає почати запізно.
Чим це відрізняється від "додати безпеку в кінці"
Класичний підхід, який досі домінує в hardware-індустрії: спочатку роблять продукт, який працює, а безпеку додають пізніше, як шар поверх готової архітектури. Іноді це шифрування даних, яке причепили в останній момент. Іноді це пароль, який додали, бо клієнт поскаржився. Це підхід "патч замість фундаменту".
Security by design перевертає це. Питання не "як нам захистити те, що ми вже побудували", а "які загрози існують для цього продукту, і як архітектура має виглядати, щоб їх врахувати з першого дня". Різниця не косметична. Закладіть безпеку в архітектуру з початку, і вона впливає на вибір чипа, на структуру прошивки, на те, як організований процес оновлень. Додайте її в кінці, і ви обмежені тим, що дозволяє вже готове залізо і код. Деякі речі неможливо виправити без переробки з нуля.
Найяскравіший публічний приклад того, скільки насправді коштує "неможливо виправити без переробки з нуля", - злом Jeep Cherokee в 2015 році. Дослідники Charlie Miller і Chris Valasek, разом з журналістом Wired Andy Greenberg, віддалено, з відстані близько 16 км, перехопили керування трансмісією й гальмами Jeep Cherokee, поки Гринберг їхав на ньому по хайвею зі швидкістю 110 км/год. Точкою входу була Uconnect - інфотейнмент-система зі стільниковим зв'язком, додана для зручності (навігація, музика) і жодного разу не спроєктована з реальною ізоляцією від CAN-шини - внутрішньої мережі автомобіля, яка також передає команди на кермо й гальма. Щойно дослідники отримали виконання коду на чипі інфотейнменту, між цим чипом і безпеко-критичними системами машини фактично нічого не стояло. Fiat Chrysler відкликала 1.4 мільйона автомобілів. Виправлення не було звичайним патчем для багу: довелося переосмислити, як розважальна система взагалі має право "розмовляти" з рештою машини. Це рішення про мережеву сегментацію, яке приймається на етапі архітектури. Впроваджувати його вже після того, як 1.4 мільйона машин на дорозі - це не оновлення, це відкликання.
Annex I(1) саме тому охоплює весь цикл - "designed, developed and produced" - а не лише фінальний продукт. Регулятора цікавить не тільки кінцевий результат. Його цікавить, чи ризики враховувались на кожному етапі.
Як це виглядає на практиці для embedded/IoT
Принцип абстрактний, поки не подивитись на конкретні реалізації. Ось що security by design означає технічно для пристрою:
Secure boot - пристрій перевіряє цифровий підпис прошивки до її запуску, а не довіряє коду, який опинився в пам'яті. CRA ніде не називає secure boot по імені, але це стандартна інженерна реалізація вимоги 2(f): захист цілісності коду й конфігурації від несанкціонованих модифікацій. Рішення закладається на рівні вибору мікроконтролера. Софтверним патчем пізніше це не додати.
SBOM (Software Bill of Materials) - структурований список усіх програмних компонентів у продукті. Не засіб захисту сам собою, радше видимість: ви не можете керувати ризиком компонента, про існування якого не знаєте, і не можете відреагувати на новий CVE в бібліотеці, про яку забули, що вона взагалі там є.
Secure OTA-оновлення - механізм оновлення прошивки "по повітрю", який сам захищений від підміни. Небезпечний канал оновлення обходить весь інший захист пристрою.
Мережева сегментація - які підсистеми мають право "говорити" одна з одною, і через який шлюз. CRA прямо називає це в пункті 2(j): "обмежувати поверхню атаки, включно із зовнішніми інтерфейсами". Це саме те рішення, яке інженери Uconnect прийняли неправильно: фіча для зручності опинилась в тій самій логічній мережі, що й безпеко-критичні системи керування, без жодної примусової межі між ними. Сегментація непомітна, коли працює, і катастрофічна, коли її нема, тому це має бути свідоме архітектурне рішення, а не те, що виводиться постфактум із того, що дозволяє існуюча розводка.
Кожен з цих чотирьох елементів - не окрема "фіча безпеки", яку можна вимкнути чи ввімкнути. Це інженерні рішення, які випливають з того самого принципу: ризики закладаються в архітектуру на етапі проєктування, а не виправляються постфактум.
Типова помилка виробників
Найпоширеніша помилка: до security by design ставляться як до чекліста. Команда бере список вимог CRA, проходить пункт за пунктом і на кожному питає "чи є в нас це?" замість "чи потрібно нам це, враховуючи реальні загрози для цього продукту?"
Це небезпечно в обидва боки. З одного боку, можна витратити ресурси на захист від загрози, яка для вашого продукту нерелевантна. З іншого, і це гірше, можна "закрити" пункт чекліста поверхневим рішенням, яке не витримає реальної атаки, і все одно пройти self-assessment. Команда, що робила Uconnect, цілком могла закрити компонентний чекліст: шифроване сховище тут, поле автентифікації там, і все одно випустити те, що випустила, бо реальна прогалина була архітектурною: жоден пункт чекліста не питав, чи має інфотейнмент-система взагалі мати доступ до CAN-шини.
Annex I(1) написаний як вимога "based on the risks", тобто ризик-орієнтований підхід, а не список галочок. Регулятор очікує, що ви спочатку оціните ризики (Article 13(2)), а вже потім вирішите, які заходи з пункту (2) до вас застосовні і в якому обсязі. Чекліст-мислення пропускає цей крок і одразу стрибає до виконання пунктів. Від цього й захищає пункт (1).
FAQ
Security by design - це те саме, що security by default? Ні, хоч терміни й пов'язані. Security by design - про процес розробки, як продукт проєктується. Security by default - вимога з Annex I(2)(b): продукт постачається з безпечними налаштуваннями "з коробки", без потреби щось додатково вмикати. Друге - один із проявів першого.
Це стосується тільки апаратної частини, чи софту теж? Обох. Annex I(1) охоплює "products with digital elements": hardware, firmware, софтверні компоненти, і те, як вони взаємодіють.
Чи є щось подібне поза CRA? Так. NIST і ETSI EN 303 645 (стандарт для споживчого IoT) містять схожі формулювання про вбудовану безпеку з етапу проєктування. CRA робить цей принцип юридично обов'язковим на рівні ЄС для широкого кола продуктів, а не рекомендацією найкращої практики.
З чого почати, якщо в нас продукт вже в розробці, а не на етапі проєктування? Почніть з оцінки ризиків (те, що вимагає Article 13(2)) для поточної архітектури, а не з чекліста вимог. Це покаже, які прогалини найкритичніші, і дозволить розставити пріоритети, навіть якщо частину архітектурних рішень вже не змінити без переробки.
Чи означає закладання цього з першого дня, що весь проєкт сповільниться? Не якщо це відбувається там, де має, на етапі архітектури й threat modeling, до написання коду, а не як паралельний потік роботи, що конкурує з розробкою фіч. Сфокусована оцінка ризиків за Article 13(2) для типового підключеного пристрою зазвичай займає дні, не місяці, а на виході - короткий список архітектурних рішень (межі мереж, що потребує secure element, як виглядає шлях оновлення), які потім просто стають частиною специфікації, під яку всі й будують. Затримку створює саме пропуск цього кроку, а не його виконання: команди, які його пропускають, зазвичай приймають ті самі рішення все одно, тільки пізніше, в гірших умовах, коли залізо вже зафіксоване.
Якщо частину прошивки віддано на аутсорс, хто відповідає за виконання цієї вимоги? Виробник, який виводить продукт на ринок ЄС, згідно з Article 13. Відповідальність не переходить на субпідрядника лише тому, що код писав він. На практиці це означає, що рішення security by design мають бути прописані й перевірені саме в момент залучення аутсорс-партнера, а не вважатись чимось, що вирішиться саме собою десь по дорозі. Команда розробки прошивки, яка розглядає безпеку як частину архітектурної розмови з першої специфікації, а не як шар, що додається, коли логіка продукту вже готова, - це і є різниця між успадкуванням відповідності пункту (1) і успадкуванням переробки з нуля.
Якщо ваш продукт іде на ринок ЄС, а прошивка ще на етапі архітектури - зараз найдешевший момент закласти security by design правильно. Platanor проєктує архітектуру безпеки для IoT та hardware-продуктів під CRA і RED. Напишіть нам: platanor.com/contact.
