Доклады, выступления, видео и электронные публикации

ДБО - как сделать это безопасным. Часть II

Конкретные ответы на реальные вопросы

Проникновение информационных технологий в нашу жизнь вызывает пристальный интерес к защите информационного взаимодействия. Зачастую это интерес «академический», подогреваемый прессой и мифами о том, что «вот дадут мне электронную подпись, и будет мне счастье». Возможно, пока это не опасно. Действительно, для значительного числа государственных услуг, предоставляемых в электронном виде, вполне достаточно простой идентификации гражданина. Например, на основе сертификата ключа подписи, или на любой другой основе. С точки зрения значительного количества граждан, не представляет особого интереса и защита персональных данных. Известно же, что все они «уже давно украдены». Так что если интерес к защите в этих областях и есть, то его уж точно можно считать не оформившимся в личный, частный интерес. А значит, общественное мнение не возражает против того, чтобы защищались эти коммуникации формально.

Иное дело - ДБО. Суммы потерь огромны, деньги теряют граждане, компании и предприятия, банки. Здесь интерес к защите становится конкретным, личным, почти интимным. Вопрос стал не праздным. А на реальные вопросы и ответ должен быть конкретным.

В предыдущей статье[1] мы обосновали выводы о том, что:

  • невозможно обеспечить безопасность ДБО без создания доверенной среды у клиента, создание доверенной среды у клиента является необходимым условием безопасного информационного взаимодействия;
  • доверенную среду на компьютере клиента при этом вовсе не обязательно поддерживать постоянно, достаточно обеспечить доверенность только на период сеанса связи - создать доверенный сеанс связи, ДСС;
  • создание ДСС может быть обеспечено разными средствами, но для целей ДБО целесообразно использовать недорогое малогабаритное устройство, которое удобнее всего подключать к компьютеру через порт USB;

При этом должны выполняться требования по безопасности, а именно:

  • защита от перехвата паролей;
  • защита от перехвата портов;
  • неизвлекаемость ключей;
  • защита от перехвата управления;
  • безопасное обновление.

Кроме этого, мы выделили необходимые требования по функциональности, основные из которых:

  • достаточность функций для любой архитектуры системы;
  • мультиплатформенность решения;
  • поддержка любой периферии;
  • независимость от провайдеров сети.

Более всего этим требованиям удовлетворяет средство электронной подписи СЭП «МАРШ!-ДСС», однако и у него есть недостатки - в частности, не выполняется важнейшее требование независимости от конфигурации сети. Таким образом, становится объяснимым, почему «МАРШ!» получил большое распространение в корпоративных системах, но мало используется в рознице - действительно, настройка сетевых параметров в ряде случаев может стать препятствием.

Архитектура

Как же избавиться от этого недостатка? Для этого рассмотрим условную структурную схему МАРШ!а - рис.1.

7.png

Рис. 1. Структурная схема МАРШ!

Основными его элементами являются микроконтроллер, память и криптографический блок, включая физический датчик случайных чисел. К компьютеру он подключается через интерфейс USB, как показано на рис.2.

3.png

Рис. 2. Подключение МАРШ! к ПК

Естественно, в этом случае для организации телекоммуникаций используются каналы, поддерживаемые компьютером.

4.png

Рис. 3. Организация телекоммуникации

Так как при загрузке с МАРШ!а использовать настройки, размещенные в компьютере, нельзя по причине их недоступности в ряде случаев и по соображениям безопасности, то такая архитектура приводит к необходимости хоть раз, но настроить МАРШ!. Как отмечалось, это не всем по силам, и, кроме того, лишает МАРШ! преимущества мобильности - связаться можно будет только с тех компьютеров, для которых заранее осуществлены настройки.

Нужно отметить, что такая схема вполне пригодна для корпоративных систем, например, медицинских информационных систем (МИС), где и компьютеры, и настройки одинаковы. В том же случае, если компьютеры разнообразны и подключены к Интернету с помощью всего многообразия возможных способов, хочется найти более «легкий» для пользователя вариант.

Очевидный вариант видится в том, чтобы не использовать все возможные для компьютера варианты, а ограничиться одним или несколькими провайдерами, и эти возможности коммуникаций придать непосредственно МАРШ!у. Тогда вариант взаимодействия будет такой:

6.png

Рис. 4. Использование коммуникаций в МАРШ!

Конечно, это намного упрощает ОС МАРШ!а, полностью снимает проблему настроек, но делает сложнее само устройство, так как к нему нужно добавить модем.

В этом случае структура МАРШ!а будет дополнена модемом и будет выглядеть так:

8.png

Рис. 5. Архитектура МАРШ! «М!&M» (МАРШ! и модем)

Такое устройство может использоваться на любом компьютере, не требует настроек (one-click), его функций достаточно для любой архитектуры системы, оно независимо от провайдеров сети, и является мультиплатформенным, так как может загружать код ОС и ФПО для компьютеров любой архитектуры, включая x86, Mac или компьютеры с гарвардской архитектурой.

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

В состав резидентного ПО входит операционная система, браузер, модуль интеграции, библиотека электронной подписи, VPN, криптоядро, вспомогательные библиотеки для надежной работы с памятью, транспортной системой массторадж, файловой системой.

Операционная система - Linux

Браузер - Mozzila FireFox

Модуль интеграции - встраивается как плагин браузера и предназначается для инициирования выполнения операций с ЭП.

Библиотека ЭП - это средство, позволяющее применять ЭП не битовых строк, а документов в формате XML.

VPN - может быть любым. Есть положительный опыт работы со всеми распространенными VPN.

Криптоядро - может быть любым. Есть положительный опыт работы со всеми распространенными криптоядрами.

Для интеграции с банковской частью ДБО, построенной на основе WEB-сервисов, со стороны серверной части достаточно установить физический или виртуальный сервер доверенного сеанса связи - сервер ДСС. Его задача - поддержка VPN со стороны канала (клиента) и поддержка WEB-сервиса со стороны центра. Кроме того, на стороне сервера ДСС устанавливаются средства санации, проводящие контроль корректности XSD-схем полученных файлов и удаление из них несанкционированных (исполняемых) операций. Таким образом может быть сформирован XML-файл известной структуры, который будет подписан ЭП на стороне клиента и передан в центр с соблюдением требований безопасности.

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

При интеграции с системой, построенной не на WEB-сервисной технологии, система может быть дополнена типовым Агентом Интеграции (АИ), выпускаемым серийно. В этом случае интеграция заключается в описании и настройках сервисов на АИ.

Режимы работы

"Папуасскими бусами" из флешек, токенов, "таблеток" touch memory, модемов и других идентификаторов и USB-устройств сегодня может похвастаться едва ли не каждый. Нужно ли это?

За счет описанной архитектуры, возможностей микроконтроллера и криптоблока интегрированный с модемом МАРШ! может реализовывать функции:

а) модема

б) токена

в) защищенного ключевого носителя (неизвлекаемость ключа - ЗКН)

г) специального загрузочного носителя (СЗН)

д) технологической среды хранения доверенной ОС и ФПО.

Все эти функции доступны в доверенном режиме (при загрузке с МАРШ!а). Однако несложно предусмотреть, чтобы некоторые функции были доступны и при использовании компьютера в недоверенном режиме. Например, при необходимости можно использовать описанный МАРШ! просто как модем, можно использовать как токен и как ЗКН. Конечно, при этом необходимый уровень защиты не будет достигаться, но возможность такого доступа позволит не тратить деньги на другие устройства, уже присутствующие в МАРШ!е.

Таким образом, будем выделять два режима функционирования МАРШ! - обычный, при котором доступны первые три функции, и доверенный, в котором доступны все функции устройства.

Ориентировочный срок начала поставки изделий на рынок - сентябрь этого года.

Почему не работают другие подходы

Токены, защищенные ключевые носители, электронные замки, модули доверенной загрузки, средства разграничения доступа, VPN, межсетевые экраны, и прочая, прочая, прочая - позволяют обеспечить достаточный уровень защищенности только в комплексе. Однако, требования регуляторов выглядят так, что если есть хотя бы одна функция, связанная с безопасностью, изделие нуждается в сертификации. И вот сертификат есть - ура! Изделие сертифицировано! И кто потом, за исключением горстки специалистов, поймет, что это изделие обеспечивает не безопасность, а приемлемое выполнение только одной (или нескольких) функций?! Защита подменяется имитацией защиты. Имитация. Проблема эпохи.

Не решает проблему и подключение к недоверенному компьютеру устройства ЭП, подписывающего и отображающего платежку. Да, если это устройство простейшее, его можно исследовать, состояние его зафиксировать и считать доверенным. Но проблема в том, что функциональность его будет слишком узкой (в силу простоты). Значит, использовать его будет неудобно. А если функциональность сделать близкой к привычной, которую предоставляют компьютеры - то тогда и все проблемы компьютеров перенесутся на это устройство. И снова о доверенности придется забыть.

Нужное нам устройство должно быть полнофункциональным с одной стороны, и простейшим в применении - вот такая дихотомия.


[1] Конявский
В. А.
ДБО - как сделать
это безопасным // Information Security/Информационная безопасность. М., 2012. № 2. С. 32-33.

Автор: Конявский В. А.

Дата публикации: 01.01.2012

Библиографическая ссылка: Конявский В. А. ДБО – как сделать это безопасным. Часть II // Information Security/Информационная безопасность. М., 2012. № 3 (июнь). С. 8–9.


Scientia potestas est
Кнопка связи