Доклады, выступления, видео и электронные публикации
ДБО - как сделать это безопасным. Часть II
Конкретные ответы на реальные вопросы
Проникновение информационных технологий в нашу жизнь вызывает пристальный интерес к защите информационного взаимодействия. Зачастую это интерес «академический», подогреваемый прессой и мифами о том, что «вот дадут мне электронную подпись, и будет мне счастье». Возможно, пока это не опасно. Действительно, для значительного числа государственных услуг, предоставляемых в электронном виде, вполне достаточно простой идентификации гражданина. Например, на основе сертификата ключа подписи, или на любой другой основе. С точки зрения значительного количества граждан, не представляет особого интереса и защита персональных данных. Известно же, что все они «уже давно украдены». Так что если интерес к защите в этих областях и есть, то его уж точно можно считать не оформившимся в личный, частный интерес. А значит, общественное мнение не возражает против того, чтобы защищались эти коммуникации формально.
Иное дело - ДБО. Суммы потерь огромны, деньги теряют граждане, компании и предприятия, банки. Здесь интерес к защите становится конкретным, личным, почти интимным. Вопрос стал не праздным. А на реальные вопросы и ответ должен быть конкретным.
В предыдущей статье[1] мы обосновали выводы о том, что:
- невозможно обеспечить безопасность ДБО без создания доверенной среды у клиента, создание доверенной среды у клиента является необходимым условием безопасного информационного взаимодействия;
- доверенную среду на компьютере клиента при этом вовсе не обязательно поддерживать постоянно, достаточно обеспечить доверенность только на период сеанса связи - создать доверенный сеанс связи, ДСС;
- создание ДСС может быть обеспечено разными средствами, но для целей ДБО целесообразно использовать недорогое малогабаритное устройство, которое удобнее всего подключать к компьютеру через порт USB;
При этом должны выполняться требования по безопасности, а именно:
- защита от перехвата паролей;
- защита от перехвата портов;
- неизвлекаемость ключей;
- защита от перехвата управления;
- безопасное обновление.
Кроме этого, мы выделили необходимые требования по функциональности, основные из которых:
- достаточность функций для любой архитектуры системы;
- мультиплатформенность решения;
- поддержка любой периферии;
- независимость от провайдеров сети.
Более всего этим требованиям удовлетворяет средство электронной подписи СЭП «МАРШ!-ДСС», однако и у него есть недостатки - в частности, не выполняется важнейшее требование независимости от конфигурации сети. Таким образом, становится объяснимым, почему «МАРШ!» получил большое распространение в корпоративных системах, но мало используется в рознице - действительно, настройка сетевых параметров в ряде случаев может стать препятствием.
Архитектура
Как
же избавиться от этого недостатка? Для этого рассмотрим условную структурную
схему МАРШ!а - рис.1. Рис. 1. Структурная схема МАРШ! Основными
его элементами являются микроконтроллер, память и криптографический блок,
включая физический датчик случайных чисел.
К компьютеру он подключается через интерфейс USB, как показано на рис.2. Рис. 2. Подключение МАРШ! к ПК Естественно,
в этом случае для организации телекоммуникаций используются каналы,
поддерживаемые компьютером. Рис. 3. Организация телекоммуникации Так
как при загрузке с МАРШ!а использовать настройки, размещенные в компьютере,
нельзя по причине их недоступности в ряде случаев и по соображениям
безопасности, то такая архитектура приводит к необходимости хоть раз, но
настроить МАРШ!. Как отмечалось, это не всем по силам, и, кроме того, лишает
МАРШ! преимущества мобильности - связаться можно будет только с тех
компьютеров, для которых заранее осуществлены настройки. Нужно
отметить, что такая схема вполне пригодна для корпоративных систем, например,
медицинских информационных систем (МИС), где и компьютеры, и настройки
одинаковы. В том же случае, если компьютеры разнообразны и подключены к
Интернету с помощью всего многообразия возможных способов, хочется найти более
«легкий» для пользователя вариант. Очевидный
вариант видится в том, чтобы не использовать все возможные для компьютера
варианты, а ограничиться одним или несколькими провайдерами, и эти возможности
коммуникаций придать непосредственно МАРШ!у. Тогда вариант взаимодействия будет
такой: Рис. 4. Использование
коммуникаций в МАРШ! Конечно,
это намного упрощает ОС МАРШ!а, полностью снимает проблему настроек, но делает
сложнее само устройство, так как к нему нужно добавить модем. В
этом случае структура МАРШ!а будет дополнена модемом и будет выглядеть так: Рис. 5. Архитектура МАРШ! «М!&M» (МАРШ! и модем) Такое
устройство может использоваться на любом компьютере, не требует настроек (one-click), его
функций достаточно для любой архитектуры системы, оно независимо от провайдеров
сети, и является мультиплатформенным, так как может загружать код ОС и ФПО для
компьютеров любой архитектуры, включая x86, Mac или компьютеры с
гарвардской архитектурой. При
такой архитектуре наиболее простым способом обеспечивается и выполнение
требований по безопасности. Действительно, доверенность среды обеспечивает
защиту от перехвата паролей, портов и защиту от перехвата управления,
криптографический блок обеспечит неизвлекаемость ключей и контроль целостности
при проведении обновлений ПО. В состав резидентного ПО входит операционная система,
браузер, модуль интеграции, библиотека электронной подписи, VPN, криптоядро,
вспомогательные библиотеки для надежной работы с памятью, транспортной системой
массторадж, файловой системой. Операционная система - Linux Браузер - Mozzila FireFox Модуль интеграции - встраивается как плагин браузера и
предназначается для инициирования выполнения операций с ЭП. Библиотека ЭП - это средство, позволяющее применять ЭП не
битовых строк, а документов в формате XML. VPN - может быть любым. Есть положительный опыт работы со
всеми распространенными VPN. Криптоядро - может быть любым. Есть положительный опыт работы
со всеми распространенными криптоядрами. Для интеграции с
банковской частью ДБО, построенной на основе WEB-сервисов, со стороны серверной
части достаточно установить физический или виртуальный сервер доверенного
сеанса связи - сервер ДСС. Его задача - поддержка VPN со стороны канала
(клиента) и поддержка WEB-сервиса со стороны центра. Кроме того, на стороне
сервера ДСС устанавливаются средства санации, проводящие контроль корректности
XSD-схем полученных файлов и удаление из них несанкционированных (исполняемых)
операций. Таким образом может быть сформирован XML-файл известной структуры,
который будет подписан ЭП на стороне клиента и передан в центр с соблюдением
требований безопасности. Имеющийся опыт интеграции показывает, что на этом этапе при
правильно разработанной системе трудностей не возникает. При интеграции с системой, построенной не на WEB-сервисной
технологии, система может быть дополнена типовым Агентом Интеграции (АИ),
выпускаемым серийно. В этом случае интеграция заключается в описании и
настройках сервисов на АИ. Режимы работы
"Папуасскими
бусами" из флешек, токенов, "таблеток" touch memory, модемов и других идентификаторов и USB-устройств сегодня может похвастаться едва
ли не каждый. Нужно ли это? За
счет описанной архитектуры, возможностей микроконтроллера и криптоблока
интегрированный с модемом МАРШ! может реализовывать функции: а)
модема б)
токена в)
защищенного ключевого носителя (неизвлекаемость ключа - ЗКН) г)
специального загрузочного носителя (СЗН) д)
технологической среды хранения доверенной ОС и ФПО. Все
эти функции доступны в доверенном режиме (при загрузке с МАРШ!а). Однако
несложно предусмотреть, чтобы некоторые функции были доступны и при
использовании компьютера в недоверенном режиме. Например, при необходимости
можно использовать описанный МАРШ! просто как модем, можно использовать как
токен и как ЗКН. Конечно, при этом необходимый уровень защиты не будет
достигаться, но возможность такого доступа позволит не тратить деньги на другие
устройства, уже присутствующие в МАРШ!е. Таким
образом, будем выделять два режима функционирования МАРШ! - обычный, при
котором доступны первые три функции, и доверенный, в котором доступны все
функции устройства. Ориентировочный
срок начала поставки изделий на рынок - сентябрь этого года. Токены, защищенные ключевые носители, электронные замки, модули
доверенной загрузки, средства разграничения доступа, VPN, межсетевые экраны,
и прочая, прочая, прочая - позволяют обеспечить достаточный уровень
защищенности только в комплексе. Однако, требования регуляторов выглядят так,
что если есть хотя бы одна функция, связанная с безопасностью, изделие
нуждается в сертификации. И вот сертификат есть - ура! Изделие сертифицировано!
И кто потом, за исключением горстки специалистов, поймет, что это изделие
обеспечивает не безопасность, а приемлемое выполнение только одной (или
нескольких) функций?! Защита подменяется имитацией защиты. Имитация. Проблема
эпохи. Не решает проблему и подключение к недоверенному компьютеру
устройства ЭП, подписывающего и отображающего платежку. Да, если это устройство
простейшее, его можно исследовать, состояние его зафиксировать и считать
доверенным. Но проблема в том, что функциональность его будет слишком узкой (в
силу простоты). Значит, использовать его будет неудобно. А если
функциональность сделать близкой к привычной, которую предоставляют компьютеры
- то тогда и все проблемы компьютеров перенесутся на это устройство. И снова о
доверенности придется забыть. Нужное нам устройство должно быть полнофункциональным с одной
стороны, и простейшим в применении - вот такая дихотомия. [1] Конявский Автор: Конявский В. А. Дата публикации: 01.01.2012 Библиографическая ссылка: Конявский В. А. ДБО – как сделать это безопасным. Часть II // Information Security/Информационная безопасность. М., 2012. № 3 (июнь). С. 8–9.Почему не работают другие подходы
В. А. ДБО - как сделать
это безопасным // Information Security/Информационная безопасность. М., 2012. № 2. С. 32-33.
Обратная связь
Отправьте нам сообщение или закажите обратный звонок.