Светлана Конявская, 15/02/24
У правильных требований есть одно неудобное свойство: они становятся мантрами, практически утрачивая для исполнителей живой и объективно стоящий за ними смысл. Наверняка у каждого из вас хоть один человек да спросил, можно ли теперь, когда пандемия ковида объявлена завершенной, больше не мыть руки. К сожалению или к счастью, оснований для отмены требований по защите информации нет, такие вопросы ни у кого не возникают, но выполняются требования иногда в отрыве от всякого здравого смысла. Примеров можно привести много, но в соответствии с темой номера разберем лишь один на материале защиты КИИ.
Автор: Светлана Конявская-Счастная, АО “ОКБ САПР”
В соответствии с требованиями 187-ФЗ [1] и связанных с ним подзаконных актов при взаимодействии с использованием сетей связи общего доступа каждый узел должен быть защищен СКЗИ высокого класса.
Это означает, что платформа СЗИ для КИИ должна иметь следующие возможности:
- создавать и поддерживать доверенную вычислительную среду;
- обеспечивать работу с неизвлекаемым ключом в автоматическом режиме (включая автоматический старт работы);
- обеспечивать возможность установки различных СКЗИ при соблюдении условий сертификации на высокие классы;
- обеспечивать работу с различными каналами связи по различным протоколам, при необходимости – параллельно;
- обеспечивать коммутацию с различным оборудованием объекта КИИ без модификации последнего.
Об этих задачах и путях их решения уже написано немало [2], и в этот раз остановимся на одном, на первый взгляд самоочевидном, требовании регулятора к СКЗИ высокого класса – неизвлекаемом ключе. Казалось бы, эта тема должна быть раскрыта в современных СКЗИ в полной мере, однако в ней есть важные для применения в КИИ особенности.
Неизвлекаемость откуда?
"Неизвлекаемость" – свойство, описывающее связь ключа с некоторым его физическим хранилищем.
Это очевидно. Но не всегда это понимание заставляет задаться следующим вопросом: откуда именно не извлекается этот ключ? Было бы странно, если бы ответ на этот вопрос не имел значения, он безусловно важен и не должен быть всегда одинаковым.
Неизвлекаемые ключи, как правило, неизвлекаемы из токена, который, как правило, является USB-устройством или, реже, смарт-картой.
По умолчанию, видя фразу "неизвлекаемый ключ", большинство специалистов представляет себе именно это.
Однако, вообще говоря, это не единственный вариант.
Более того, главная задача токена вообще не обеспечение неизвлекаемости, а обеспечение отчуждаемости ключа. Токен предназначен для того, чтобы ключ пользователя был отчуждаем от СВТ, на котором пользователь осуществляет те или иные операции с ключом. Это нужно для того, чтобы связать ключ с пользователем, а не с СВТ, поскольку это ключ пользователя. Концепция отчуждения критичных для безопасности данных распространяется не только на криптографические ключи. В защиту информации она вошла с идеей отчуждения данных и/а (см. рис.).
Итак, "токен" – это в целом про отчуждаемость, а не про неизвлекаемость.
Тем не менее среди токенов есть такие, в которых реализована (так или иначе) функция "неизвлекаемый ключ". Здесь не будем останавливаться на том, что не все эти реализации одинаковы, что дает почву для многочисленных разоблачительных статей в Интернете о том, как тот или иной специалист извлек "неизвлекаемое" и скопировал "некопируемое". Это крайне важно, но не в контексте КИИ, так как в КИИ задача работы с ключом вообще крайне редко связана с ключами пользователя. А значит, отчуждаемость ключевого носителя в них не требуется.
Всегда ли отчуждаемость одинаково полезна?
Обмениваются по сети разнообразными данными и сигналами технические средства объектов КИИ. Как правило, у этих технических средств совсем нет пользователей (но есть, например, администраторы, администраторы нештатного режима или аналогичные). Более того, взаимодействующие в составе объектов КИИ технические средства не только сами по себе разнообразны, но и располагаться могут весьма нетривиальным для обычных информационных систем образом: не только на стационарных, но и на мобильных и даже подвижных объектах, а если и на стационарных, то где-нибудь внутри трубы на дне моря. В этих обстоятельствах задача отчуждения ключей (а также подключения токена или иного участия пользователя в старте СКЗИ) становится совершенно нереалистичной. Очевидно, что в таких случаях (доступ невозможен) токен должен быть подключен раз и навсегда.
В тех же случаях, когда физический доступ к месту подключения токена возможен, возникает другая задача – этот физический доступ исключить, чтобы избежать компрометации ключей.
Это утверждение звучит на первый взгляд радикально и сомнительно. Однако, по существу, отчуждаемость ключа – если это ключ СВТ, а не пользователя – прямо противоречит его неизвлекаемости. Ключ становится извлекаемым – просто целиком, вместе с носителем.
Конечно, в определенном смысле, может быть хуже – если ключ на отчуждаемом носителе можно забрать из системы, а затем еще и получить к нему доступ. Однако подмена ключевой информации или даже просто ее утрата – это крайне нежелательные для КИИ сценарии, так как они нарушают ее функционирование.
Таким образом, при организации криптографической защиты сетевого взаимодействия объектов КИИ отчуждаемость ключа не только избыточна, но и вредна: с одной стороны, она делает возможными сценарии атак с подменой или иными вариантами компрометации ключа за счет отчуждаемости его носителя, а с другой – подключенное к порту USB-устройство резко снижает надежность решения – при вибрации, ударах, нагревании и прочих особенностях реальных условий, в которых работают технические средства на объектах КИИ.
Но есть ли другой выход, ведь, читая документы на СКЗИ высоких классов сертификации для защиты канала, мы видим, что "требование неизвлекаемости ключа выполняется применением токена..."? Это добросовестное выполнение требования, однако токен с неизвлекаемым ключом – это инструмент решения совсем другой задачи, существенно отличающейся от защиты сетевого взаимодействия объектов КИИ.
В КИИ ключи связаны не с пользователями, а с взаимодействующими техническими средствами – это означает, что не извлекаться они должны из резидентного компонента безопасности этого технического средства. И в этом же техническом средстве должно исполняться СКЗИ (иначе оно не сможет работать с неизвлекаемым ключом), а значит, должна быть создана и поддерживаться среда функционирования криптографии (СФК) для соответствующего класса СКЗИ.
И как тогда?
Таким образом, выход в том, чтобы модуль работы с неизвлекаемым ключом в СЗИ для КИИ был реализован как часть резидентного компонента безопасности (РКБ), размещенного непосредственно на плате компьютера, а не как отчуждаемый персональный носитель ключа.
Совершенно невозможно рассматривать вариант реализации такого РКБ в составе уже существующего и тем более функционирующего оборудования КИИ. Очевидно, что это должен быть отдельный специализированный микрокомпьютер, который, как мы помним из перечня требований в начале, легко и без ущерба для сертификации коммутируется с разнообразным оборудованием.
Каждый такой микрокомпьютер будет точкой сбора информационных и/или управляющих сигналов от объектов КИИ, их шифрования для передачи по каналам связи, а также приема зашифрованных сигналов из каналов связи и их расшифровкой.
Учитывая, что сигналами обмениваются технические средства, расположенные в стойках ЦОД, локомотивах, банкоматах, трубопроводах и беспилотниках, стартовать СКЗИ должно в автоматическом режиме питания, об этом уже упоминалось выше, но стоит акцентировать более выражено. Даже в тех случаях, когда с техническим средством работает человек (например, это не трубопровод, а локомотив) и технически возможно провести идентификацию и аутентификацию пользователя и подключить ключевой носитель с ключами именно этого пользователя, а не другого – все это совершенно неуместно, так как не отвечает задаче защиты сетевого взаимодействия технических средств: именно они, а не пользователи должны быть аутентифицированы защитными механизмами, именно их ключи, а не ключи пользователей должны использоваться для криптографических преобразований.
Выводы получаются тривиальными, что не снижает их важности; выполнение требований не должно противоречить здравому смыслу; должно быть не формальным, для галочки, а реальным, по существу, в соответствии с особенностями конкретной системы.
А это означает, что использовать нужно специальные инструменты, предназначенные в данном случае именно для КИИ.
Решения для криптографической защиты сетевого взаимодействия в КИИ, построенные именно таким образом, существуют, применяются в реальных КИИ и известны на рынке. А поскольку это статья не рекламная – sapienti sat.
- Федеральный закон 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации".
- Конявская С.В. Построение защиты объектов КИИ: использовать неподходящее или делать самому? // Information Security/Информационная безопасность. 2023. № 2. С. 19; Конявский В.А., Конявская С.В. Повышение защищенности автоматизированных систем управления технологическими процессами // Information Security/Информационная безопасность. 2023. № 1. С. 40–41; Конявская С.В. Защита банкомата согласно закону о КИИ: как избежать уязвимости традиционной архитектуры // Расчеты и операционная работа в коммерческом банке. М., 2020. № 1. С. 13–25; и др.
