Кибербезопасность в условиях электронного банкинга. Практическое пособие

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

Все еще хуже, если злоумышленником является сам бухгалтер (надеемся, что не доведем никого до греха).

Итак, если бухгалтер задумал провести нелегальный платеж, что его может остановить? Теоретически его должна сдержать неотказуемость от ЭП на его ключе.

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

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

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

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

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

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

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

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

Ключи СКЗИ, защищающего канал, хранятся в токене.

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

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

Именно таких случаев касается п. 31 Требований к средствам электронной подписи [31]: «В состав средств ЭП классов КС3 должны входить компоненты, обеспечивающие:…управление доступом субъектов к различным компонентам и (или) целевым функциям средства ЭП и СФ на основе параметров, заданных администратором или производителем средства ЭП…». Предотвратить эту атаку может только применение комплексной системы защиты, включающей взаимную аутентификацию клиентского СВТ и сервера. Это не рядовая функция, зачастую относительно сервера аутентифицируется только пользователь.

Все эти леденящие кровь сценарии невозможны, если токен просто различает СВТ, к которым его подключают.

Итак, защищенный ключевой носитель должен:

1) быть персональным отчуждаемым устройством;

2) быть специализированным именно для хранения ключей устройством (т. е. обеспечивать возможность защищенного хранения криптографических ключей с применением интерфейсов работы со смарт-картой (CCID или PKCS#11));

3) предоставлять доступ к ключам только легальному пользователю после успешной аутентификации в устройстве;

4) предоставлять легальному пользователю доступ к ключам только на тех СВТ, на которых данному пользователю разрешено работать с данным ключевым носителем.

«Идеальный токен»

Функции токена с функцией ограничения числа разрешенных компьютеров объединяет в себе «Идеальный токен» – токен с несколько измененной архитектурой: она включает в себя блок идентификации компьютера, до прохождения проверки которым недоступен в том числе и блок идентификации/аутентификации пользователя (рис. 69).

Рис. 69. «Идеальный токен»