1.4.4 Эцп

Подпись — это результат хеш-функции от текста платежки, "зашифрованной" на закрытом ключе клиента. Банк, получая платежку, проверяет хеш от текста полученной платежки, потом "расшифровывает" подпись открытым ключом клиента и сверяет результат. Если хеши совпали, значит, это действительно платежка от клиента, и текст платежки достоверен. Решаются задачи целостности, идентификации клиента и, кроме того, сам клиент потом не может отказаться от этой платежки, так как она подписана верным ключом. Дело в том, что между банком и клиентом подписывается договор, согласно которому все платежки с верной ЭЦП банк должен отправлять. Поэтому, если кто-то украдет ключ пользователя, подпишет платежку, то банк обязан исполнить ее, выполняя денежный перевод. ПО, работающее с ЭЦП по ГОСТу, называется "Система  Криптографической Защиты Информации" (СКЗИ). Такое ПО проходит проверку ФСБ, и на него выдаются соответствующие сертификаты. Алгоритм подписи — ГОСТ Р 34.10 2001. При этом алгоритм хеш-функции — ГОСТ Р 34.11-94. Разбирать и взламывать криптографию никому не надо, ведь ключ можно украсть или использовать прямо на месте.

1.4.5 Usb-Token

USB-Token - USB-устройство, внешне похожего на флеш-накпитель. Внутри прошит секретный ключ и микросхема, которая принимает на вход данные, подписывает их по ГОСТу внутри себя (с помощью ключа) и на выход выдает уже подпись. Это достаточно надежно, ведь тогда ключ нельзя скопировать и украсть. Но, к сожалению, можно просто подменить входные данные или вообще поставить жертве R-Admin, а можно и туннелировать трафик USB. Последнее время на рынке появились более надежные Token’ы с одноразовыми паролями, но массового внедрения пока нет, да и слабые места в виде перехвата ввода пароля и использование его для подложной платежки также возможны. Защита клиента должна включать в себя целый комплекс мер: сегментация физическая, логическая, удаление ненужного функционала, ограничение доступа в интернет, ключевая политика, парольная политика, патч-менеджмент, антивирусная защита.

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