Статус: Сотрудник
Группы: Участники
Зарегистрирован: 12.08.2013(UTC) Сообщений: 834   Откуда: Москва Сказал «Спасибо»: 5 раз
Поблагодарили: 215 раз в 174 постах
|
Автор: two_oceans  На ИС областного уровня временами может достигаться поток сообщений в СМЭВ порядка 1500 сообщений в секунду, при этом требуется наложение на них ЭП-ОВ. До сих пор не было возможности (из-за низкой производительности режима PKCS11, полагаю) использовать токены для таких массовых операций и приходилось хранить ключи в реестре (что не очень согласуется с требованиями КС2 для ИС) или эмулировать диск в памяти (тоже не так безопасно) или использовать несколько копий контейнера на разных носителях (а то и разных серверах что финансово накладно). И даже так в "часы пик" запросы могут висеть неотправленными несколько минут пока до них дойдет очередь подписания. Для СМЭВ 3 ждать секунды нормально, но доводить до минут не хотелось бы. Вопрос: есть ли какое-то продвижение в плане производительности массового подписания ключами на токенах? Если в режиме ФКН, то вообще идеально.
Не знаю, например, какое-нибудь кэширование доступа к определенному контейнеру на токене минут на 15. Чтобы без лишних перечислений, переустановок защищенного канала к токену и т.д. просто передавать новые данные на вычисление подписи. Конечно, полагаю, есть предел аппаратных возможностей в случае режима ФКН, но и программную часть наверно можно "разогнать" (как со стороны криптопровайдера-драйвера, так и со стороны прикладного ПО)? Тут ответ состоит из двух частей. Во-первых, оптимизация самого вызывающего кода. Если для каждой подписи происходит перечисление контейнеров, затем открытие по короткому имени и закрытие после одной подписи, конечно, тормоза будут жуткие. 1) Если изначально получить полное имя контейнера (FQCN | UNIQUE) и по нему открывать, то большого влияния на работу перечисление оказывать не будет. 2) Закрывать контекст тоже не нужно. Если большой поток SignHash-ей не будет прерываться "паразитными" обращениями к токену, но они все будут подписываться под одним защищенным каналом. 3) Поскольку CSP - это библиотека, мы не можем блокировать на себя токен между CryptoAPI вызовами. Всегда должны учитывать, что другое приложение сбросить его состояние. У меня была мысль сделать "камикадзе-mode", в котором будут отключены все предварительные доведения до требуемого состояния (перевыборы приложения, переоткрытия папок), но пока не было мотивации. Может, теперь попробуем. Во-вторых, есть и физические ограничения от самого вычислителя в токене. Например, для Рутокен ЭЦП (в т.ч. и ФКН) в наших тестах предел - 3 подписи/секунду. Если не масштабировать задачу до "фермы" из токенов, каждая секунда трафика, где 1500 сообщений, будет обрабатываться 500 секунд (~8 минут). Самые быстрые токены, что у нас были в тестах, - Инфокрипт Токен++ (ФКН). У них время подписи - 6 оп/сек. Всего в два раза быстрее. Каких-то фантастических результатов тут, к сожалению, не достичь. Если нужна производительность и уровень защиты выше КС1, может, стоит рассмотреть "большой токен" - HSM? |
|
