Закон 48/2023 в Молдове: что кибербезопасность стала обязанностью, а не пожеланием

Молдова ввела первый обязательный национальный режим кибербезопасности по модели NIS2. Разбираем, кого он касается, что именно требует, как устроена трёхуровневая отчётность об инцидентах и почему без пентеста закрыть часть обязательств невозможно.

Долгое время кибербезопасность в молдавских компаниях была требованием, которое приходило извне — от заказчика, от зарубежного партнёра, от банка-корреспондента. Закон № 48/2023 меняет саму природу этого требования: он вводит национальный обязательный режим, построенный по европейской модели NIS2, с designated-организациями, минимальным набором мер и обязанностью сообщать об инцидентах. Ниже — практический разбор: кого он затрагивает, что придётся сделать и как это доказать.

Что это за закон и почему он появился

Закон № 48/2023 о кибербезопасности устанавливает юридическую и институциональную рамку домена в Республике Молдова. Ключевое слово здесь — «рамка»: документ не описывает конкретные технические средства, он задаёт категории мер, распределяет организации по уровню критичности и определяет, кто и как надзирает за исполнением. Технические детали — точные сроки, формы уведомлений, пороги размеров — выносятся в подзаконные акты, и это нормальная практика: закон должен переживать смену технологий, а не устаревать вместе с ними.

Главная новость для рынка — выравнивание по директиве NIS2. Это та же логика деления на существенные (essential) и важные (important) организации, те же категории мер управления рисками, та же ступенчатая модель отчётности об инцидентах. Для компаний, которые уже работают с партнёрами из ЕС, это хорошая новость: усилия не удваиваются. Программа соответствия, построенная под европейский рынок, в значительной степени закрывает и национальные требования. Обратное утверждение тоже верно — и для экспортёров оно полезнее, потому что молдавский бизнес чаще оказывается поставщиком для европейского заказчика, чем наоборот.

Примечание: выравнивание по NIS2 означает, что один и тот же комплект политик, процедур и технических доказательств можно предъявлять и молдавскому регулятору, и европейскому заказчику. Это редкий случай, когда регуляторное давление совпадает с коммерческим интересом.

Кого закон затрагивает

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

Как и в NIS2, попадание под действие зависит от сектора и размера организации. Разница между существенными и важными организациями проявляется прежде всего в интенсивности надзора: за первыми наблюдают проактивно — плановые проверки, запросы доказательств, регулярный диалог; вторые попадают в поле зрения главным образом как реакция на инцидент или на поступивший сигнал. Это различие важно для планирования бюджета: существенная организация обязана держать доказательную базу постоянно, важная — уметь быстро её собрать.

Но есть третий маршрут, о котором вспоминают позже всего. Даже если вы не designated-организация, обязательства по цепочке поставок протягивают требования к вам через контракт. Ваш заказчик — банк, энергокомпания, оператор цифровой инфраструктуры — обязан управлять рисками своих прямых поставщиков. Значит, ваш IT-подряд, хостинг, разработка ПО, техподдержка и обслуживание инфраструктуры становятся объектом его требований. Для многих молдавских компаний закон приходит именно по этой дороге — задолго до того, как придёт напрямую.

Восемь обязательств, которые надо закрыть

Список мер выглядит знакомо для любого, кто читал NIS2, и это не случайно. Разберём его по существу, а не по названиям.

• Политики анализа рисков и безопасности информационных систем. Не абстрактный документ, а описание того, какие активы поддерживают вашу услугу, какие угрозы для них реалистичны и что вы с этим делаете.
• Управление инцидентами: обнаружение, обработка, ступенчатое уведомление компетентного органа. Здесь критично, что процедура должна работать в часах, а не в неделях.
• Непрерывность деятельности: резервные копии, восстановление после катастрофы, управление кризисами. Резервные копии, которые никогда не проверяли восстановлением, — это не мера, а допущение.
• Безопасность цепочки поставок, включая требования к прямым поставщикам.
• Безопасность при закупке, разработке и сопровождении систем, с управлением уязвимостями.
• Политики оценки эффективности мер — то есть тестирование, а не документирование.
• Кибергигиена и обучение персонала.
• Криптография, контроль доступа, многофакторная аутентификация и защищённые коммуникации.

Обратите внимание на асимметрию: шесть пунктов из восьми можно закрыть бумагой и настройками, а два — шестой и пятый — принципиально не закрываются документами. О них ниже.

Отчётность об инцидентах: три ступени

Модель, перенятая из NIS2, делит уведомление на три момента. Сначала — очень быстрое раннее предупреждение: сигнал о том, что инцидент произошёл и потенциально серьёзен. Затем — уведомление с первичной оценкой в течение первых дней: что именно затронуто, каков предполагаемый масштаб, что уже сделано. И наконец — финальный отчёт после закрытия инцидента: полная картина, первопричина, принятые меры, уроки.

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

Внимание: самое частое нарушение сроков происходит не потому, что компания медленно пишет отчёт, а потому, что она поздно обнаруживает инцидент. Логирование, централизация событий и понятный маршрут эскалации — это не «зрелость», а условие выполнения требования.

Где в законе живёт тестирование на проникновение

Закон, как и NIS2, не требует пентест напрямую — он требует политик оценки эффективности мер управления рисками и управления уязвимостями, не навязывая конкретный метод. Формально это оставляет пространство для манёвра. Практически же обе эти обязанности невозможно продемонстрировать документами: нужна независимая техническая проверка. Оценка эффективности требует подтверждения, что защита выдерживает; управление уязвимостями требует знать о своих уязвимостях раньше, чем их найдёт кто-то другой.

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

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

Пересечение с NIS2, GDPR и отраслевыми режимами

Один из самых частых вопросов — как соотносятся между собой эти рамки. Закон 48/2023 — это национальное выравнивание по NIS2, поэтому требования перекрываются почти полностью: те же категории мер, та же логика сущностей, та же модель отчётности. GDPR — отдельная рамка, касающаяся защиты персональных данных, но она пересекается с кибербезопасностью в технических мерах: статья 32 требует регулярного тестирования эффективности этих мер. А для финансового сектора добавляется собственный слой — операционная устойчивость и тестирование на основе угроз (TLPT), которое по глубине заметно превосходит обычный пентест.

Практический вывод для компании, которая считает бюджет: одна кампания тестирования может дать доказательства сразу для нескольких рамок. Отчёт, оформленный правильно — с явным периметром, методологией, оценкой риска по находкам и подтверждением устранения, — читается и регулятором по кибербезопасности, и аудитором по персональным данным, и банковским надзором. Гораздо дешевле один раз выстроить качественный процесс, чем трижды собирать разрозненные артефакты под каждую проверку.

С чего начать, если до сих пор не делали ничего

Начинать с написания политик — самая распространённая и самая дорогая ошибка. Месяцы уходят на документы, а интерфейс администрирования всё это время остаётся доступен из интернета. Правильная последовательность обратная: сначала техническая картина, потом документация поверх неё.

1. Инвентаризация и периметр. Определите, какие системы поддерживают услугу, которую вы предоставляете, и кто имеет к ним доступ — включая подрядчиков и удалённых сотрудников.
2. Внешняя техническая проверка. Внешний пентест в начале программы даёт список реальных приоритетов и немедленно снижает наиболее очевидный риск — открытые наружу сервисы.
3. Управление уязвимостями как процесс. Не разовый скан, а цикл: обнаружение, приоритизация по эксплуатируемости и критичности актива, устранение, повторная проверка.
4. Процедура инцидентов. Роли, каналы, шаблоны уведомлений, репетиция хотя бы в виде tabletop-упражнения.
5. Требования к поставщикам. Пропишите в договорах то, что вы сами обязаны обеспечить: уведомление об инцидентах, доступ к отчётности, право на проверку.
6. Обучение и гигиена. MFA, управление привилегированными учётными записями, защищённые коммуникации, регулярные учения по фишингу.

Отдельно стоит продумать, как вы будете доказывать выполнение. Проверяющий орган не читает ваши мысли и не оценивает намерения — он смотрит на артефакты. Отчёт о пентесте с датой, периметром, методологией и подтверждённым повторным тестом весит в разы больше, чем страница описания «применяемых мер». То же касается цепочки поставок: анкета, заполненная поставщиком собственноручно, — это его заявление о себе, а не ваше доказательство. Независимый отчёт об интеграции поставщика с вашими системами — уже доказательство.

Важно: обязанность по цепочке поставок не передаётся поставщику вместе с договором. Ответственность остаётся на вас — вы обязаны уметь показать, что оценивали риск и что требования были предъявлены и проверены. Формулировка «это зона ответственности подрядчика» перед регулятором не работает.

Что это значит на практике

Закон 48/2023 не создаёт принципиально новую техническую реальность — он делает обязательным то, что зрелые организации и так делали добровольно, и подводит под это юридическую рамку с надзором и отчётностью. Наибольшее давление ощутят не столько designated-организации, сколько их поставщики: требования придут по контрактам, часто быстрее и жёстче, чем от регулятора. Для молдавского бизнеса, ориентированного на экспорт услуг в ЕС, это скорее возможность, чем издержка: соответствие NIS2-совместимой рамке становится коммерческим аргументом, а не только статьёй расходов. И самое прагматичное наблюдение — из восьми обязательств два не закрываются бумагой, а именно они определяют, выдержит ли организация реальный инцидент, а не проверку. Начинать разумно с технической картины: инвентарь, периметр, внешняя проверка. Документация ложится поверх ясной технической картины гораздо легче, чем наоборот.