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

«Всегда прав» или «Cам виноват»?

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

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

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

Проблема эта стала проблемой национальной безопасности.

Сегодня практически нет банков, клиенты которых не пострадали бы от действий хакеров, атакующих системы дистанционного банковского обслуживания (ДБО). «Доходы» преступных хакерских групп составляют, по оценкам экспертов, 25-30 млн. долларов в месяц для каждой группы. Это те деньги, которые теряют вкладчики банков, так как все риски банки перекладывают на них. По имеющимся данным, потери клиентов российских банков составляют более 2,5 млрд. евро. Обратите внимание - не банки потеряли, а клиенты. Это значит, что во всех случаях "успешных" хакерских атак банки объяснили своим пострадавшим клиентам, что банк не при чем, а виноваты они сами. Но как же так? Разве клиент виноват, что банк перепутал его с преступником и отдал преступнику деньги, которые честный гражданин доверил банку?

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

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

Усеченные решения банки применяют, исходя из неверной логики - если создание доверенной среды дорого, то можно заменить ее паллиативами. Это не так. Если известные решения слишком дорогие - значит, нужно искать более дешевые, а не имитировать безопасность.

Но пока что дело обстоит не так, и в качестве иллюстрации этого тезиса рассмотрим договор на ДБО банка с клиентом.

Что думает банк?

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

Для анализа договора начнем с общих положений, связанных с понятием «безопасность» вообще. Известно, что понятие «безопасность» неразрывно связано с обеспечением доверия, которое, в свою очередь, связано с возможностью проверки.

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

п.3.3. «Стороны признают, что программные средства, обеспечивающие изготовление конфиденциальных и открытых ключей ЭЦП, а также формирование и проверку ЭЦП, предоставляемые Клиенту, выполнены в соответствии с требованиями ГОСТ Р 34.10-94 «Информационная технология. Криптографическая защита информации. Процедуры выборки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма», и ГОСТ Р 34.11-94 «Информационная технология. Криптографическая защита информации. Функция хэширования»». Ну как клиент может это проверить? Этим занимается ФСБ, и процедура эта сложная и длительная, многие особенности которой клиент, не являющийся профессионалом в информационной безопасности, просто не поймет. Выходит, нужно просто верить.

В пункте 1.1.13. типового договора вводится определение корректности ЭЦП, а именно: "«Корректная ЭЦП» - ЭЦП, дающая положительный результат ее проверки средствами Системы, а в спорных ситуациях - программными средствами, указанными в п.п. 8.7.4.-8.7.5 настоящего Договора, с использованием действующего на момент подписания открытого ключа ЭЦП Стороны". Это определение выглядит совершенно нейтральным, и используется очень нескоро, только в п.п. 3.4. - 3.6., и уже здесь закладываются основы позиции «Сам виноват». Вот эти формулировки.

3.4. Клиент признает, что получение Банком электронных документов, заверенных корректной ЭЦП Клиента, юридически эквивалентно получению документов на бумажном носителе, подписанных уполномоченными лицами и заверенных оттиском печати Клиента.

3.5. Банк признает, что получение Клиентом электронных документов, заверенных корректной ЭЦП Банка, юридически эквивалентно получению документов на бумажном носителе, подписанных уполномоченным лицом и заверенных оттиском штампа Банка.

Из п.3.6. «Стороны признают, что:

-после заверения электронного документа ЭЦП любое изменение, добавление или удаление символов документа делает ЭЦП некорректной, т.е. проверка подписи с открытым ключом ЭЦП Стороны, подписавшей электронный документ, дает отрицательный результат;

-создание корректной ЭЦП электронного документа возможно исключительно с использованием конфиденциального ключа ЭЦП;

-по содержанию электронных документов, подписанных ЭЦП, и открытых ключей ЭЦП невозможно определить конфиденциальные ключи ЭЦП»

Так должно быть, и в этом нет сомнений. Для этого и придумана электронная подпись. Но откуда клиент может знать, что предлагаемое ему конкретное средство реализации электронной подписи все делает правильно? Вопрос тот же - доверять или проверять? Проверить эти утверждения клиент не может, значит, нужно верить, и, видимо, не только этому, но и всему остальному в договоре. А как иначе? Здесь верим, а здесь не верим?

Кроме того, в этих формулировках положительные результаты проверки ЭЦП отождествляются с подлинностью и юридической значимостью документа. Известно, что это не так. Юридическое значение имеет волеизъявление клиента, а не его подпись. Подпись может подтверждать волеизъявление, но для этого должны быть обеспечены соответствующие условиях - например, собственноручность подписи. Если подпись клиента ставит хакер - является ли это отражением волеизъявления клиента? Думаю, нет.

Рассмотрим теперь другие положения типового договора. Нумерация пунктов используется та же, что в договоре.

Из п. 3.6. - «каждая Сторона несет полную ответственность за обеспечение безопасности и сохранность своих конфиденциальных ключей ЭЦП, а также за действия своего персонала». Это правильный пункт. Не ясно только одно - как именно клиент может обеспечить сохранность своих ключей? Как показал проведенный опрос ряда клиентов, никто не предполагает в качестве мер по выполнению данного пункта ничего другого, кроме как прятать носитель ключей от окружающих. Но ключи-то обычно воруют не из носителей, а из Интернета, и часто атака хакеров вообще никак не связана с АРМ клиента. Без организации доверенной среды с двух сторон никакие меры не могут обеспечить сохранности в тайне ключей! Как клиент может нести ответственность за то, на что он не может повлиять? И вообще - а в чем состоит ответственность? Неужели в том, что у клиента заберут все его деньги? Интересно, много ли найдется желающих получить услугу на таких условиях?

Развивая эту тему, в п. 3.7. договора декларируется, что: «Клиент полностью несет все риски, связанные с подключением его вычислительных средств к сети Интернет. Клиент самостоятельно обеспечивает защиту собственных вычислительных средств и криптографических ключей от несанкционированного доступа и вирусных атак из сети Интернет».

Но разве риски ДБО связаны (существенно) еще с чем-то, кроме подключения к сети Интернет и несанкционированного доступа? Разве это не «Сам виноват»? Кажется, здесь у клиента единственный выход - не подключаться к Интернету. Правда, неясно, зачем тогда ДБО вообще?

Для тех, кто сразу не понял, мысль о виновности клиента во всем продолжается и в п.6.5., где среди разумных ограничений на действия клиента есть и указание на то, что «Банк не несет ответственности за ущерб, возникший вследствие (...) утраты (...) уполномоченными лицами Клиента собственного конфиденциального ключа ЭЦП, (...), вне зависимости от причин (...)». Очень много вопросов вызывает этот пункт. Одна из основных на сегодняшний момент причин утраты ключей - «успешная» атака хакеров, причем атака не на АРМ клиента, а на сеть (Интернет) и/или информационную систему Банка. Украли у Банка (например, подменив ключ проверки подписи), а ответственность несет клиент?

Несмотря на все эти очевидные неувязки, Банк все-таки старается "дожать" клиента, в п.3.6. требует безоговорочного признания: «Стороны признают, что:

-используемая Сторонами в соответствии с настоящим Договором система защиты информации, которая реализует заверение ЭЦП и шифрование электронных документов, достаточна для обеспечения конфиденциальности, а также подтверждения авторства и контроля целостности электронных документов».

Позвольте, если обе стороны признают (как следует из договора), что предоставленной Банком системы защиты достаточно, то что еще требуется от клиента? Клиент доволен и счастлив - его права надежно защищены Банком!

Конечно, мало иметь такие "хорошие" средства, важно еще и правильно их эксплуатировать. Именно поэтому в пункте 4.1.1 Банк обязуется предоставить клиенту некоторый документ с названием «Требования по обеспечению безопасности в процессе эксплуатации АРМ «Клиент»», а Клиент обязуется этот документ соблюдать. Посмотрим эти «Требования...».

В них указывается, что « ... СКЗИ «NNN» удовлетворяет требованиям к стойкости СКЗИ класса КС1, а при использовании на ПЭВМ сертифицированного средства защиты от НСД ПАК «Аккорд-АМДЗ» - класса КС2.

Необходимый уровень защищенности АРМ «Клиент» (соответствие классу КС1 или классу КС2) определяется Клиентом самостоятельно.

Со стороны Банка уровень защиты банковской части системы обеспечивается по классу КС2. Клиентам рекомендуется обеспечивать тот же уровень для защиты АРМ «Клиент»».

Вот эти рекомендации нужно рассмотреть особо. Как клиент может определить самостоятельно необходимый уровень защищенности? Клиент не знает используемой Банком классификации ("Что такое КС1? Это лучше, чем КС2 или хуже"?), и не обязан ее знать. Как же он может выбрать достаточный класс защиты?

Начнем с того, от какого нарушителя мы защищаемся. Кого мы опасаемся? Уборщицы? Случайно заглянувших посетителей? Или имеющих высшее специальное образование, обученных и владеющих специальными приемами хакеров? Если мы хотим защититься от хакеров, то уровень защищенности должен быть КС3, и не ниже. Известно, что зачастую хакеры используют недокументированные возможности программного обеспечения - не исключено, что требуемый уровень защиты должен быть поднят и выше. Конечно, Банк может себе позволить использовать средства по классу КС2 - у него (Банка) строгий пропускной режим, служба охраны, давняя культура защиты информации, за счет средств защиты от НСД обеспечивается доверенная среда функционирования криптографии и так далее - но ведь у клиента, в общем случае, ничего этого нет! Как же можно в принципе допускать использование клиентом низких классов защиты, да еще и номинировать их как достаточные для обеспечения конфиденциальности?

Очевидно, что Банк понимает необходимость доверенной среды и опасности, связанные с ее отсутствием, но четких требований не предъявляет. Почему предлагается самостоятельный выбор там, где выбора, по сути, нет? Чтобы «Сам виноват»?

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

Продемонстрированный здесь Банком подход не помогает клиенту сделать осознанный выбор, а только дезориентирует его, объективно играя на руку тем, кому должен противостоять.

Замечательное требование содержится и в п.8.12., а именно: «Отсутствие на клиентском рабочем месте Системы признаков отправки электронного документа, принятого Банком с корректной ЭЦП данного Клиента, не является основанием для отказа Клиента от авторства данного документа». Источник этого требования понятен. Так, в условиях отсутствия доверенной среды клиент потенциально может злоупотребить своими возможностями, послать подписанную платежку, а потом удалить ее следы из базы. Приведенный пункт предупреждает такое поведение со стороны клиента. Однако одновременно эта формулировка еще раз информирует нас: «Сам виноват». Если ключи утрачены - даже не по вине Клиента, и платежки действительно отправил не он, а хакер - виноват Клиент.

В составе п. 4.1.1. «Требования по обеспечению безопасности в процессе эксплуатации АРМ «Клиент»» имеется еще одна отсылка к смежным документам, а именно: «Эксплуатация АРМ «Клиент» и обеспечение его безопасности организационными и техническими мерами должны осуществляться в соответствии с Правилами пользования СКЗИ «NNN» (xxxx.NNNNNN.4012.009.31)».

При этом отдельно подчеркивается, что: «При организации доступа в Банк по сети Интернет хранение и использование носителей ключей VPN сети (ИЗК) должно производиться аналогично порядку, предусмотренному в Правилах пользования для ключей шифрования СКЗИ «NNN»».

Рассмотрим некоторые требования, приведенные в этих правилах.

Начать правильно будет с того, что код .4012. относится не к программной реализации СКЗИ, а к программно-аппаратной. Вместе с тем клиентам выдается программное средство, что недвусмысленно отмечается в п.4.1.1., где СКЗИ в явном виде перечислено в подразделе «Программное обеспечение». Но это ладно, просто неаккуратность и незнание ГОСТ. Простительно. Хуже другое.

Требования перечислены мелким шрифтом через один интервал примерно на 6-ти страницах, и многие из них невыполнимы. Чего, например, стоят рекомендации: «Уничтожение ключевых носителей, ..., осуществляется путем расплющивания молотком на наковальне»? Или рекомендация: «не использовать в помещении, ..., радиотелефоны и другую радиоаппаратуру»? Вот, например, как формулируется одно из требований организационно-техническим мерам защиты от НСД: «ОС должна быть настроена только для работы с СКЗИ. Все неиспользуемые ресурсы системы необходимо отключить (протоколы, сервисы и т.п.)». Таким образом, СКЗИ не предусматривает использования в сети Интернет, но предлагается Банком именно для этой цели!

Вызывает восхищение рекомендация о необходимости: «организовать затирание (по окончании работы СКЗИ) временных файлов и файлов подкачки, формируемых или модифицируемых в процессе работы СКЗИ». Какой, интересно, бухгалтер сможет это «организовать» и какими силами и средствами? Однако, в документе имеется рекомендация и по этому поводу, а именно: «Если это не выполнимо, то ОС должна использоваться в однопользовательском режиме и на жесткий диск должны распространяться требования, предъявляемые к ключевым носителям». Поясняю из вышеприведенного - жесткие диски нужно хранить в сейфе, а в конце концов расплющить с помощью молотка и наковальни!

Жаль, что я не прочитал этого раньше. Можно было бы неплохо заработать на молотках и наковальнях!

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

Интересно, есть ли в Банке молоток и наковальня? Задавать вопрос о выборе подхода к клиенту «Всегда прав» или «Сам виноват» уже не стоит.

А что думают юристы? (дура лекс)

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

Так, например, в договоре, который мы исследовали выше, в разделе «Порядок разрешения споров» указывается, что если согласие не будет достигнуто после проведения технической экспертизы, то споры разрешаются в Арбитражном суде.

Свою позицию по рассматриваемому поводу еще более десяти лет назад сформулировал Пленум Высшего арбитражного суда Российской Федерации в Постановлении от 19 апреля 1999 года №5 «О некоторых вопросах практики рассмотрения споров, связанных с заключением, исполнением и расторжением договоров банковского счета». Так как Банк, работая с деньгами клиента, должен выполнять распоряжения клиента о перечислении и выдаче средств со счета, то должен быть определен порядок проверки полномочий лиц, которые от имени клиента могут распоряжаться счетом. Пленум четко определил, что: «Проверка полномочий лиц, которым предоставлено право распоряжаться счетом, производится банком в порядке, предусмотренном банковскими правилами и договором с клиентом». И далее: «Если иное не установлено законом или договором, банк несет ответственность за последствия исполнения поручений, выданных неуполномоченными лицами, и в тех случаях, когда с использованием предусмотренных банковскими правилами и договором процедур банк не мог установить факта выдачи распоряжения неуполномоченными лицами» (выделено мною - В.К.).

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

Что делать?

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

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

Таким образом, целесообразно предложить решение, при котором компьютер пользователя может находиться в двух состояниях - неконтролируемом и доверенном. При этом доверенное состояние - это небольшой по времени периодически повторяемый эпизод, а основное время компьютер пользователя может находиться в неконтролируемом состоянии. Это нетривиальная задача.

Надежно эта задача может быть решена применением новой технологии доверенного сеанса связи (ДСС).

Доверенный сеанс связи - период работы компьютера, в рамках которого обеспечивается доверенная загрузка ОС, организуется защищённое соединение, а также поддерживаются достаточные условия работы с ЭП. Примером практической реализации концепции доверенного сеанса связи является средство обеспечения доверенного сеанса «МАРШ!» - СОДС "МАРШ!", изготавливаемый в виде специализированного USB-устройства.

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

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

Доверенный сеанс связи. На старт, внимание, МАРШ!

На старт

Парадигма доверенных вычислительных систем (вычислений, программного обеспе-чения, информационного взаимодействия) сформировалась далеко не единовременно. Первые ее «воплощения» были предложены, насколько мне известно, в 90-х годах прошлого столетия. Задача тогда формулировалась как задача создания функционально-замкнуой среды (ФЗС), и была предложена (опять таки предположительно) А. Малютиным и А. Петровым.

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

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

Впервые в полном объеме решение задачи обеспечивалось СЗИ НСД «Аккорд» и СПО «Аккорд-1.х», что и послужило толчком к развитию аппаратных средств защиты от НСД.

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

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

Внимание

Авторами следующего шага можно с высокой степенью уверенности назвать А. Петрова и А. Щербакова. Именно им принадлежит пальма первенства в формулировании концепции изолированной программной среды - ИПС. Ориентированная на многозадачные среды, концепция предполагала создание условий, при которых защищенная специальным образом операционная среда исключала взаимовлияние одновременно выполняемых задач. И в этом состояла изолированность исполняемых проверенных программ в проверенной ОС с проверенными данными.

Как и ранее, концепция была технически поддержана следующей версией СЗИ НСД «Аккорд» и СПО разграничения доступа «Аккорд-2.х».

Именно тогда развитие СВТ достигло уровня, при котором многие из компонентов компьютера сами по себе стали представлять собой независимые вычислительные системы - вплоть до собственного микропрограммного обеспечения. Стало понятно, что не только программы, ОС и данные должны быть проверенными. Необходимо быть уверенными и в «невредоносности» аппаратных средств.

А вот в этом убедиться уже просто невозможно.

Как можно проверить всю аппаратуру, все микропрограммы, во всех сочетаниях и вариантах?! Потребность в защищенности вновь вступила в противоречие со сложностью анализа. Сложность должна была быть многократно снижена - иначе декларирование защищенности становилось всего лишь ритуальными плясками при фактическом наличии «Синдрома Мюнгхаузена» - имитации бурной деятельности по вытягиванию себя за волосы из болота.

Решение было найдено очень несложное - вынести ключевые операции по обеспечению безопасности в изолированную АППАРАТНУЮ среду, сложность которой позволяет проверить и её, и микропрограммы управления, причем технологически выполненную так, чтобы целостность СЗИ не нарушалась. Такое решение получило название резидентный компонент безопасности - РКБ [1], а уточненная концепция ИПС стала называться доверенной вычислительной средой - ДВС, в англоязычной литературе впоследствии обозначаемой TPM - Trusted Platform Module.

Поддержанная возможностями нового варианта СЗИ «Аккорд», эта концепция сегодня является основной. Достаточно сказать, что условие доверенности является необходимым при использовании ЭЦП - а можно ли представить себе современные системы без этих технологий?

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

Ищем выход.

МАРШ!

На этот раз выход совсем прост. Он основывается на разумном предположении, что далеко не все время гражданин взаимодействует с банком. Есть у него и другие дела. Стало быть, можно снизить накал борьбы - и от дорогих мер по созданию ДВС «навсегда» попытаться обеспечить доверенный сеанс связи (ДСС) только на время связи. Закончится сеанс - перезагрузись, получи доступ ко всем, даже непроверенным ресурсам, и работай как обычно, довольствуясь антивирусом. Нужна связь с банком - загрузись с помощью создания средств ДСС, и на протяжении сеанса и сам будешь в безопасности, и другим не навредишь. Конечно, не все ресурсы компьютера будут при этом доступны, но вряд ли стоит переписываться с подружкой, когда посылаешь платежку.

Не правда ли, напоминает ФЗС, но только на новом уровне?!

Значит, уже сейчас можно предсказать, как будет развиваться парадигма безопасности дальше.

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

Что такое СОДС

Конструкция

Конструктивно клиентская часть средства обеспечения доверенного сеанса связи (СОДС) выполнено в виде USB-устройства, и выглядит точно так же, как обычная "флешка". Тем не менее, Клиент СОДС похож на флешку только внешне. На самом деле это активное микропроцессорное устройство, со многоконтурной криптографической подсистемой, проверенной защищенной операционной системой "Linux", браузером, специальной подсистемой управления к памяти и многим другим.

Клиент СОДС как аппаратный модуль доверенной загрузки

Основная задача СОДС - создание доверенной среды функционирования криптографии. Для этого в специальном разделе памяти Клиента СОДС размещается все необходимое для этого программное обеспечение. Важнейшей особенностью является обеспечиваемая СОДС возможность подписи документов в формате XML

Клиент СОДС подготавливается к эксплуатации как загрузочное устройство. При начале доверенного сеанса связи пользователь загружается с Клиента СОДС, обеспечивая тем самым доверенную среду. Далее стартует браузер и все сопутствующее программное обеспечение, необходимое для работы. В браузере в доверенном сеансе обеспечивается защищенный обмен информацией, с соблюдением всех требований 63-ФЗ.

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

Клиент СОДС как память с аппаратным управлением доступом

С точки зрения управления доступом Клиент СОДС представляет собой память, разделенную на несколько разделов. Как правило, это не менее одного раздела Read Only (RO), не менее одного раздела ReadWriteHidden (RWH), используются также разделы AddOnly (AO) и разделы с общим доступом RW. Разделение на разделы осуществляется при производстве, и пользователем изменено быть не может.

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

Аппаратные ресурсы Клиента СОДС

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

Резидентные программные средства Клиента СОДС

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

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

Браузер - Mozilla Firefox

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

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

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

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

Интеграция СОДС в функциональные подсистемы на базе WEB-сервисов

Для интеграции с функциональной подсистемой, построенной на основе WEB-сервисов, со стороны серверной части достаточно установить физический или виртуальный сервер доверенного сеанса связи - сервер ДСС. Его задача - поддержка VPN со стороны канала (клиента) и поддержка WEB-сервиса со стороны центра. Имеющийся опыт интеграции показывает, что на этом этапе при правильно разработанной системе трудностей не возникает.

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

В настоящий момент СОДС выпускается в нескольких вариантах исполнения и применяется для организации защищённой работы пользователей с рядом государственных и других доверенных ИС.

Нам возражают

1. Клиенту неудобно перезагружаться

На улице холодно, машина остыла, пока заведешь, пока машина нагреется - все проклянешь. Зачем только вчера вечером заглушил мотор?! Конечно, мотор у машины можно и не выключать. Если трудно завестись. Если машина плохая. "У меня была такая машина. Я ее продал" . Теперь с этим у меня проблем нет.

Чтобы перезагрузиться, нужно выключить компьютер и дождаться завершения выключения (20 секунд), вставить Клиент СОДС (3 секунды), включить компьютер и дождаться завершения загрузки (55 секунд). Полторы минуты передышки - не слишком большая цена за безопасность. Хотя иногда нежелание выключать машину понятно.

2. Дорого

Объем ВВП в стране - порядка 40 триллионов, предприятий - порядка 1,3 миллиона, разделив одно на другое получим 30 миллионов. Думаю, в этих условиях найти несколько тысяч рублей - не проблема. Безопасность дороже. Еще дороже деньги, которые заработал и должен уберечь от негодяев.

3. Будет работать не везде и не на всех компьютерах

У нас в стране довольно много мест, где еще и электричества нет. В этих местах ДБО работать не будет точно. Но это не только наша забота. Там кто-то должен сначала проложить дороги, поставить столбы, протянуть провода, установить счетчики и так далее. То есть раньше нас по этой дороге должны пройти дорожники, энергетики, связисты. Конечно, должен быть интернет. Раньше ДБО не заработает. И так далее. И вот если инфраструктура готова, то можно с уверенностью сказать, что на 85-95 % компьютеров, подключенных к интернету, предлагаемое решение заработает сразу, такие исследования мы проводили. Из оставшихся большая часть заработает после дополнительных настроек, которые мы можем провести удаленно, как один из сервисов. Конечно, будет незначительное количество "маргинальных" систем, собранных их "трофейных" запчастей и подключенных к нестандартным каналам связи, которые могут и не заработать. Не думаю, что эта ситуация серьезно повлияет на общую картину.

4. Невозможно получить весь привычный объем сервисов

Использовать ICQ в процессе передачи платежных документов необязательно. Можно и потерпеть. И музыку не стоит слушать, и фильмы смотреть, и по сайтам с картинками перемещаться. Потерпите. Отправите платежку - и уже сразу можно.

5. Это же нужно стыковать с бухгалтерскими системами

Состыкуем. Нам же надо это продать - а это хорошая мотивация. Вопросы защищенной контролируемой выгрузки с использованием Клиента СОДС уже решены, а это главное.

Выводы

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

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

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

Решение по обеспечению безопасного ДБО есть, это СОДС.

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

Банк, первым реализовавший такой подход, получит огромные конкурентные преимущества.

СПИСОК ЛИТЕРАТУРЫ:

1. Конявский В. А. Управление защитой информации на базе СЗИ НСД «АККОРД». М., 1999. - 325 с.

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

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

Библиографическая ссылка: Конявский В. А. «Всегда прав» или «Cам виноват»? // Защита информации. Инсайд. СПб, 2011. № 5. С. 70–77.


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