Влизайки в пълна сила на 10 декември 2024 г., Законодателният акт за киберустойчивост на ЕС (CRA) е регламент (EU 2024/2847), който определя задължителни изисквания за киберсигурност за всички продукти с цифрови елементи, продавани на пазарите в ЕС. Задълженията за докладване започват на 11 септември 2026 г., а пълното прилагане влиза в сила на 11 декември 2027 г. CRA носи нови изисквания за екипите, работещи с контейнери и Kubernetes, относно начина, по който облачно-нативните (cloud native) приложения се разработват, разпространяват и поддържат през целия им жизнен цикъл.
Обхват на CRA в облачно-нативните среди
CRA обхваща всички контейнерни изображения (container images), Kubernetes оператори и Helm чартове с търговска поддръжка, които са достъпни за клиенти в ЕС, независимо от това къде се намира разпространяващата организация. Регламентът определя своя обхват като „продукти с цифрови елементи“, достъпни на пазарите в ЕС, а това включва голяма част от облачно-нативния стек.
Елементите в обхвата на CRA включват публично разпространявани контейнерни изображения, търговски Kubernetes оператори, Helm чартове с търговска поддръжка и софтуер с отворен код с търговски гръб. Проектите с отворен код също могат да бъдат засегнати, особено тези с търговска поддръжка или договори за поддръжка. Като част от регламента се изисква верига за съответствие по цялата облачно-нативна верига за доставки.
Важни изисквания на CRA за екипи, работещи с контейнери
CRA въвежда изисквания, които пряко засягат начина, по който екипите изграждат и управляват контейнерна инфраструктура. Тези категории включват:
Сигурност по проектиране и по подразбиране (Security by design and default) – Защитени базови изображения, минимални повърхности за атака и сигурни настройки по подразбиране като нормативни изисквания.
Управление на уязвимости – Данни за списък на софтуерните компоненти (SBOM), непрекъснат мониторинг и 24-часово докладване към ENISA при експлоатирани уязвимости.
Дългосрочна сигурност (5+ години) – Текущи актуализации за сигурност, пайплайни за повторно изграждане и съвместими с по-стари версии корекции за сигурност през целия жизнен цикъл на продукта.
Този закон изисква базовите изображения да бъдат защитени, като се премахнат ненужните компоненти и се приложат сигурни конфигурации, преди продуктите да бъдат налични на пазара. Регламентът кодифицира това, за което мнозина в облачно-нативната общност отдавна се борят – минималните повърхности за атака и сигурните настройки по подразбиране вече са нормативни изисквания, а не просто препоръки.
Според CRA организациите трябва да поддържат данни за списъка на софтуерните компоненти (SBOM), непрекъснато да наблюдават за уязвимости и да ги отстраняват в определените срокове. Съгласно член 14, активно експлоатираните уязвимости изискват ранно предупреждение до Агенцията на Европейския съюз за киберсигурност (запазваща съкращението от предишното име на агенцията European Network and Information Security Agency – ENISA) в рамките на 24 часа от узнаването, последвано от пълно уведомяване в рамките на 72 часа. Това сигнализира, че процесите за откриване и реагиране на incident response в организациите трябва да работят в голям мащаб в рамките на клъстерите.
Спазвайки член 13 от CRA, продуктите изискват корекции за сигурност за минимум пет години от датата на предлагане на пазара или през целия очакван жизнен цикъл на продукта, ако този период е по-кратък. За контейнерните екипи това означава проследяване на контейнерните версии, внедрени в клиентските среди, поддържане на пайплайни за повторно изграждане за по-стари изображения и осигуряване на съвместимост с по-стари версии – всичко това, докато се коригират проблеми със сигурността, открити години след пускането на продукта.
CRA и внедряванията на Kubernetes
Средите на Kubernetes са засегнати от CRA, тъй като много производствени внедрявания включват множество контейнерни изображения от различни източници, всяко с вариращи практики за сигурност и механизми за актуализация. Това включва приложения, контейнери, sidecars, агенти за мониторинг и оператори.
Освен това, при внедряване на контролери или оператори от трети страни, екипите наследяват потенциални задължения по CRA. Изискванията за веригата за доставки в регламента определят, че е от изключителна важност да се разбере състоянието на сигурността и механизмите за актуализация на зависимостите.
Подготовка за съответствие с CRA
Препоръчва се екипите да се подготвят за съответствие с CRA, като приемат практики в екосистемата на Cloud Native Computing Foundation (CNCF), които съответстват на изискванията на CRA. следните четири области предоставят практическа начална точка:
Минимални контейнери – Започнете от сигурни базови изображения, които нямат наследени уязвимости, след което защитете приложението, като премахнете ненужния софтуер и намалите цялостната повърхност за атака.
Списък на софтуерните компоненти (SBOM), допълнен със списък на компонентите по време на изпълнение (RBOM) – Преминете отвъд статичния инвентар. Интегрирането на автоматизирано генериране на SBOM и RBOM в CI/CD пайплайните ще помогне за разграничаване на инсталираните компоненти от тези, които наистина се изпълняват по време на работа.
Стратегии за разпространение на изображения – Прегледайте как актуализациите за сигурност достигат до потребителите, кои версии са внедрени и къде, и как регистрите налагат политики в различните среди.
Видимост на веригата за доставки – Идентифицирайте кой поддържа изображенията, от които зависите, как изглежда техният ритъм на актуализации за сигурност и дали може да са необходими алтернативни стратегии за критични зависимости.
CRA и бъдещето на облачно-нативната сигурност
CRA представлява нормативна промяна към приоритезиране на софтуерната сигурност като фундаментално изискване за продукта, а не просто като добра практика. За облачно-нативната екосистема това създава предизвикателства около операционализирането на практиките за сигурност в голям мащаб, но също така потвърждава доказани подходи, разработени от общността около минималните контейнери, сигурността на веригата за доставки и автоматизираното управление на уязвимости.
Организациите, разпространяващи контейнеризирани продукти на пазарите в ЕС, имат време да се адаптират, но архитектурните и оперативните модели, необходими за съответствие, често изискват време за ефективно внедряване. Започването на планирането отсега по отношение на сигурността на контейнерите, генерирането на SBOM и процесите за реагиране на уязвимости помага на екипите да вземат информирани решения при изграждането и развитието на своите облачно-нативни платформи.