УСПД со СКЗИ: когда нужна защищённая передача данных в АСКУЭ

Коротко. Требование о криптографической защите не появляется само — его формулирует конкретная сторона, и отсутствие строчки в техническом задании не означает, что вопроса не возникнет на согласовании. Почему так устроено и что говорит нормативка — в материале про требования 522-ФЗ и 890-ПП. Здесь — практическая часть: выяснять нужно у трёх сторон, у той, что принимает данные, у службы информационной безопасности заказчика и у проектировщика. Делать это следует до закупки: криптомодуль устанавливается на производстве, и дооснастить им поставленное устройство нельзя.

В каких ситуациях вопрос СКЗИ нужно поднимать заранее

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

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

Что меняется в архитектуре

Защищённый обмен — свойство связи между средним и верхним уровнями АСКУЭ, а не характеристика одного устройства. Поэтому проверять приходится не только спецификацию.

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

Ни один из этих вопросов не решается выбором модели. Их решают регламенты и распределение ответственности между владельцем системы, эксплуатирующей организацией и получателем данных. Отдельная тема — требования к обращению с самим средством криптозащиты после монтажа: учёт, контроль состояния, периодическое обновление ключевой информации. Они не зависят от проекта и разобраны на карточке УМ-40 SMART СКЗИ, но заложить под них ответственное лицо и регламент нужно на том же этапе. Если всё это не проговорить заранее, проект проходит монтаж, но может не пройти приёмку обмена данными — и это самый неприятный момент для обнаружения, потому что к нему всё уже смонтировано.

У кого выяснить требование до закупки

Сторон три, и спрашивать их нужно в определённом порядке.

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

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

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

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

О чём договориться с принимающей стороной заранее

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

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

Что решается до закупки и не решается после

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

Состав криптомодуля, документы, подтверждающие корректность встраивания, и эксплуатационные требования разобраны на карточке УМ-40 SMART СКЗИ — там же перечень того, что заказчик берёт на себя после монтажа.

Частые вопросы

Кто формулирует требование о криптографической защите данных учёта?

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

Что делать, если в техническом задании про криптозащиту ничего не сказано?

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

На каком этапе менять решение уже поздно?

После закупки оборудования. Криптомодуль устанавливается на производстве, дооснастить поставленное устройство невозможно, поэтому появившееся позже требование закрывается только заменой оборудования среднего уровня. До формирования спецификации решение меняется без последствий для проекта.

Чем встроенный модуль отличается от внешнего криптошлюза с точки зрения проекта?

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

Об авторе

Сергей Носонов — технический директор АО «Связь инжиниринг М». Отвечает за техническую политику по линейке устройств сбора и передачи данных УМ-31 и УМ-40 SMART и за инженерные решения проектов автоматизированного учёта энергоресурсов.