Article 21(2)(d) -- вопрос к поставщику. Self-хостинг -- ответ, который снимает бремя.

Коротко о главном. NIS2 Article 21(2)(d) превращает риски цепочки поставок в вопрос уровня совета директоров, а не сноску в договоре о закупках. Директива не обязывает переходить на self-хостинг. Однако она спрашивает, что находится в вашем пути передачи данных и что произойдёт с вами, когда один из этих поставщиков переживёт неудачный вторник. Self-hosted-инфраструктура устраняет три из четырёх уровней большинства SaaS-путей данных. Не все четыре — и делать вид, что это так, является тем маркетинговым ходом, который ставит директора по информационной безопасности в неловкое положение перед аудитором.

• Текст директивы и руководство ENISA на понятном языке.
• Четырёхуровневый SaaS-путь данных, который большинство команд забывает нарисовать.
• Что модель двух инструментов Rediacc убирает из вашего реестра поставщиков, а что оставляет.
• Шесть контрольных вопросов для любого поставщика, заявляющего о готовности к NIS2.

В июле 2020 года Blackbaud выплатил выкуп и сообщил об этом миру позднее. Они уведомили более 13 000 организаций-клиентов постфактум, получили коллективные иски в семи юрисдикциях и в итоге выплатили $49,5 млн в урегулирование претензий генеральных прокуроров штатов и $3 млн в виде штрафа SEC за вводящие в заблуждение раскрытия. У каждой из этих 13 000 организаций было Соглашение об обработке данных (DPA) с Blackbaud. Большинство из них изучали отчёт SOC 2 Blackbaud. Многие включили Blackbaud в реестр рисков поставщиков с уровнем критичности, датой продления и ответственным лицом.

Ни одна из этих мер не остановила каскадного распространения. Данные находились на стороне Blackbaud. Когда была взломана их среда резервного копирования, все организации-клиенты оказались под угрозой одновременно.

NIS2 Article 21(2)(d) задаёт более сложный вопрос, чем “проводили ли вы аудит поставщика”. Он спрашивает, что находится в пути передачи данных и что происходит с вами, когда этот поставщик переживает неудачный вторник. Ответ для большинства команд звучит так: “Мы — это они, и мы не осознавали этого.”

Этот материал предназначен для директоров по информационной безопасности и руководителей закупок, пересматривающих DPA в 2026 году. Это анализ Article 21(2)(d) с позиции пути данных, а не с позиции сертификаций. Он также честно говорит о том, чего self-hosted-инфраструктура не решает, поскольку именно раздел о пробелах будет интересовать аудитора — и именно его пропустит маркетинговая брошюра.

Что в действительности обязывает Article 21(2)(d)

Английский текст директивы гласит:

“Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use […] and shall include at least the following: […] (d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”

Официального перевода директивы на русский язык не существует; приведённый английский текст является аутентичным источником.

Для покупателя в этом тексте важны два момента.

Во-первых, обязательство возлагается на вас, а не на поставщика. Сертификаты поставщика, его SOC 2, его ISO 27001 — это исходные данные для вашей оценки риска. Они не являются её заменой. Если ваш поставщик имеет безупречную позицию в области соответствия и всё равно подвергается взлому, вопрос регулятора будет касаться вашего управления рисками поставщиков, а не их.

Во-вторых, обязательство шире договора. Руководство ENISA по внедрению 2024 года, Приложение IV к Имплементирующему регламенту Комиссии (EU) 2024/2690, излагает ожидаемую практику: вести реестр ИКТ-поставщиков, классифицировать их по критичности, оценивать каждого по рискам для ваших операций и обрабатываемых ими данных, а также обновлять оценку с установленной периодичностью. Приложение IV прямо указывает, что “поставщики поставщиков” также входят в область применения — именно здесь большинство команд обнаруживает, что их реестр поставщиков на самом деле не реестр, а список договоров с наклейкой.

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

Четырёхуровневый SaaS-путь данных, который большинство команд забывает нарисовать

Сядьте с руководителем отдела закупок и разберите, что происходит, когда продукт поставщика резервного копирования записывает одну запись. Честный путь данных выглядит так, сверху вниз:

1. Приложение поставщика. Код, который принимает ваши данные, принимает решения о маршрутизации и применяет бизнес-логику. Работает на инфраструктуре поставщика. Обслуживается, патчится и контролируется поставщиком.
2. Облако поставщика. Регион гипермасштабируемого облака или собственный центр обработки данных поставщика, где работает приложение. Тома хранения, сеть, IAM. Зачастую это гипермасштабируемый провайдер, с которым у поставщика есть соглашение о субобработке.
3. Хранение ключей поставщика. Ключи шифрования, защищающие данные в покое в облаке поставщика. В большинстве SaaS-схем ключи хранит поставщик. “Ключи под управлением клиента” иногда доступны как опция более высокого уровня; в таких схемах ключи всё равно находятся в KMS гипермасштабируемого провайдера, к которому может обращаться IAM поставщика.
4. Субобработчики поставщика. Сторонние сервисы, используемые поставщиком (CDN, наблюдаемость, биллинг, инструменты поддержки клиентов), которые могут передавать или хранить ваши данные или метаданные, производные от них.

Каждый из этих четырёх уровней является записью в вашем реестре поставщиков согласно Article 21(2)(d). У каждого своя история инцидентов, свой радиус поражения при взломе, своя поверхность переговоров по договору. Когда вы продлеваете договор с SaaS-поставщиком, вы неявно продлеваете все четыре, поскольку договор с SaaS-поставщиком — единственный, который вы можете согласовывать.

Инцидент с Blackbaud был взломом уровня 2 (облако поставщика), который распространился через уровень 1 (приложение поставщика) и был виден каждому клиенту из-за уровня 3 (хранение ключей поставщика — в их случае серверные ключи без разделения по арендаторам в затронутой базе данных). Субобработчики Blackbaud не были вектором взлома, но клиенты узнали о трёх из них, которых не перечислили.

Blackbaud, хранение ключей в стиле Druva и каскадный паттерн

Три детали из материалов SEC Blackbaud имеют значение для анализа с точки зрения NIS2.

Во-первых, Blackbaud хранил ключи шифрования данных клиентов, включая среду резервного копирования, которая была целью взлома. Ключи под управлением клиента не предлагались. В судебных разбирательствах SEC после инцидента это было квалифицировано как пробел в контроле, а не нарушение, поскольку договоры Blackbaud это допускали. Позиция NIS2 в отношении той же схемы, в рамках Article 21(2)(d), жёстче, поскольку клиент не может осмысленно оценить риск контроля, в который у него нет видимости.

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

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

В случае современного SaaS-резервного копирования в стиле Druva архитектура лучше в ряде мест (разделение ключей по арендаторам более распространено, BYOK доступен на более высоких уровнях), но четырёхуровневый путь данных тот же. Приложение поставщика, облако поставщика (обычно AWS), хранение ключей (иногда поставщик, иногда BYOK в KMS клиента, иногда гибрид), субобработчики. Взлом на любом уровне одновременно затрагивает каждого клиента, поскольку данные каждого клиента находятся на одной стороне границы.

Это структурный аргумент. Это не атака на Druva. Druva работает более строго, чем Blackbaud. Аргумент состоит в том, что структура любого SaaS-продукта резервного копирования делает взломы уровней 2 и 3 обязательством по статье 21(2)(d), которое клиент не может осмысленно выполнить.

Self-хостинг устраняет три из четырёх уровней

Rediacc построен иначе. Полная архитектура задокументирована на странице архитектуры, но форма, релевантная для цепочки поставок, — это два бинарных файла, взаимодействующих по SSH:

• rdc работает на рабочей станции оператора. Он читает плоский JSON-файл конфигурации (в ~/.config/rediacc/), подключается к собственным машинам оператора по SSH и отправляет команды.
• renet работает на собственном сервере оператора с привилегиями root и управляет LUKS2-зашифрованными образами дисков, изолированными демонами Docker и обратным прокси.

Оператор никогда не входит в инфраструктуру Rediacc-как-компании для выполнения резервного копирования, восстановления или форка. В пути данных нет облака Rediacc-как-компании. Учётные данные LUKS2 репозитория хранятся в локальном файле конфигурации оператора (режим 0600), никогда на сервере, никогда не передаются в Rediacc. Путь данных выглядит следующим образом:

1. Рабочая станция оператора. Запускает rdc. Хранит учётные данные LUKS2.
2. Собственный сервер оператора. Запускает renet. Хранит LUKS2-зашифрованные репозитории.
3. Собственная цель резервного копирования оператора. Любое хранилище, совместимое с rclone (S3, B2, OneDrive, локальный MinIO). Принимает зашифрованные тома.

Уровня 4 нет. Rediacc-как-компания не является субобработчиком ни для одного оператора, который не подключил экспериментальный облачный адаптер. Для операторов с self-хостингом отношения с Rediacc-как-компанией — это лицензия на программное обеспечение, а не соглашение об обработке данных.

Это аргумент пути данных, и именно с него следует начинать в разговоре о реестре поставщиков. SaaS-конкурент может предложить ключи под управлением клиента (и большинство современных это делают). SaaS-конкурент не может предложить “мы не являемся субобработчиком”.

Вторая позиция, после того как аргумент пути данных принят, — хранение ключей. В Rediacc учётные данные LUKS2 находятся в файле конфигурации оператора, и точка. Нет депонирования ключей, нет службы восстановления, которую Rediacc-как-компания может запустить, если оператор потеряет учётные данные. Это также рекомендованная архитектура для хранилища конфигурации с нулевым разглашением, где ключ шифрования формируется на стороне клиента из расширения PRF аппаратного ключа, а сервер хранит непрозрачные блобы. Сервер не может читать SSH-ключи, учётные данные LUKS2, IP-адреса или любую конфигурацию в открытом виде. Ротация токена доступа не даёт серверу ретроактивного доступа на чтение.

Для Article 21(2)(h) (шифрование) это важно. Для Article 21(2)(d) (цепочка поставок) это важнее, поскольку устраняет последний путь логического доступа Rediacc-как-компании к данным оператора.

Что self-хостинг не устраняет

Self-хостинг изменяет список поставщиков, но не удаляет его. Три вещи, о которых аудитор всё равно спросит:

1. У вас по-прежнему есть поставщики, просто другие. Поставщик оборудования (Hetzner, Hostinger, OVH, ваш колокейшн, собственное железо). Гипервизор (KVM, VMware). Операционная система (Debian, Ubuntu, RHEL). Реестр контейнеров (Docker Hub, GHCR, ваш приватный реестр). Базовые образы, которые тянут ваши сервисы. Каждый из них — запись в реестре согласно Article 21(2)(d). Self-хостинг изменяет список поставщиков, но не удаляет его.

2. У Rediacc пока нет ISO 27001, SOC 2 или BSI C5. Они есть в дорожной карте, но не в руках. Для команды закупок, использующей сертификаты как заградительный механизм, это реальное препятствие. Защищаемый контраргумент — тот, что приводился на протяжении всего материала: аргумент пути данных означает, что большая часть того, что подтверждают эти сертификаты (средства контроля безопасности облака поставщика, управление доступом персонала поставщика, управление субобработчиками поставщика), не входит в область применения, поскольку Rediacc-как-компания не находится в пути данных. Этот аргумент необходимо приводить тщательно и обоснованно, а не как замену сертификатам там, где именно они нужны покупателю.

3. Уровень GRC по-прежнему ваш. Rediacc предоставляет оператору журнал аудита с цепочкой хешей из 70+ событий (rdc audit verify проверяет цепочку от начала до конца). Он не предоставляет реестр поставщиков, систему контроля или рабочий процесс сбора доказательств. Это по-прежнему приходит из Drata, Vanta, OneTrust или одного из европейских участников. Сопровождающий материал о реальной стоимости подробно рассматривает структуру затрат этой взаимодополняемости.

DPA, который больше не нужно согласовывать

Для наглядности приведём строку реестра “до и после” из реального разговора о закупках, анонимизированного. Покупатель — немецкая производственная компания с 280 сотрудниками, классифицированная как “важная организация” по Приложению II. Их исходная запись в реестре поставщиков для резервного копирования выглядела следующим образом:

После перехода на Rediacc на Hetzner:

Две записи в реестре вместо одной. Запись критического уровня — для IaaS-провайдера, у которого покупатель уже имел DPA и проверенный план выхода, поскольку IaaS — это отношения, которые большинство команд умеет выстраивать. Запись Rediacc некритическая, поскольку это лицензия на ПО, а не обработчик данных.

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

Контрольный список для закупок

Для любого поставщика, заявляющего о готовности к NIS2 в цикле продаж 2026 года, шесть вопросов:

1. Где находится ключ шифрования наших данных в покое? Если ответ “в нашем HSM” или “в KMS нашего клиента, к которому мы можем обращаться через IAM”, — поставщик находится в вашей цепочке хранения ключей. Если “в вашем локальном файле конфигурации, никогда в нашей инфраструктуре” — нет.

2. Кто в вашей компании технически может читать наши данные, игнорируя юридические условия? Не “кто уполномочен”, а “кто мог бы, если бы захотел и журнал аудита был отключён”. Если ответ не равен нулю, это ваша популяция для оценки инсайдерских рисков.

3. Тестируется ли восстановление на реальном производственном клоне или на синтетических тестовых данных? Article 21(2)(c) и (e) в совокупности требуют, чтобы резервное копирование действительно восстанавливалось. Поставщик, который проверяет только синтетические данные, не проверяет восстановление — он проверяет целостность файла резервной копии. (Подробнее см. в сопровождающем материале о непрерывной оценке эффективности.)

4. Фиксирует ли ваш журнал аудита вид субъекта — человек или агент — за каждым действием? Активность ИИ-агентов является наиболее быстро растущей категорией журнала аудита. Журнал аудита 2026 года, который не различает человека и агента, будет выглядеть как пробел к 2027 году.

5. Перечислите каждого субобработчика, имеющего логический доступ к нашим данным, включая метаданные. “Логический доступ” — правильная формулировка. “Логический доступ, включая метаданные” — лучше, поскольку доступ только к метаданным — это то, что обычно имеют субобработчики биллинга, наблюдаемости и поддержки клиентов, и этого достаточно для утечки конфиденциальной структуры, даже когда полезная нагрузка зашифрована.

6. Каков ваш план выхода, если вас приобретёт покупатель из-за пределов ЕС в 2027 году? Система адекватности GDPR, Cloud Act и FISA 702 — все это движущиеся цели. Заявление поставщика о размещении данных сегодня не является гарантией через три года. Вопрос покупателя — что произойдёт с путём данных, если сменится владелец поставщика.

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

Что это означает для следующего цикла продления

Если вы готовитесь к продлению резервного копирования или аварийного восстановления в следующие двенадцать месяцев и Article 21(2)(d) включён в карту показателей закупок, три конкретных шага:

1. Нарисуйте четырёхуровневый путь данных вашего текущего поставщика на белой доске. Если вы не можете назвать третьего субобработчика по цепочке, у вас есть проблема полноты реестра, которая существовала до NIS2, и продление — правильный момент для её устранения.
2. Прогоните шесть вопросов контрольного списка выше против действующего поставщика. Отправьте ответы вашему DPO и аудитору и спросите, приняты ли пробелы. Если пробелы включают уровень 3 (хранение ключей) или уровень 4 (субобработчики, которых вы не перечислили), это рычаг давления.
3. Посмотрите, как будет выглядеть альтернативный реестр поставщиков с self-hosted плоскостью управления. Сравнивайте записи в реестре, а не стоимость лицензий. Стоимость лицензий схожа в пределах фактора двух; записи в реестре имеют разные формы. (Сопровождающий материал о структурных затратах на стек NIS2 рассматривает, что сокращается, а что остаётся.)

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

Публичное сопоставление возможностей Rediacc со статьями NIS2 см. в NIS2 и DORA. Для более широкой системы соответствия см. Обзор соответствия, Суверенитет данных и On-Premise.