USB-токены в ДБО: несколько ключец ЭЦП на один токен

[Ravilich]

Очень многие наши клиенты, на которых зарегистрировано несколько юридических лиц, просят записать все свои ЭЦП по этим организациям на один USB-токен, чтобы им не путаться в них. Понятно, что повышается риск мошеннических переводов, учитывая, что некоторые и не выниманию свои токены из USB-портов, причем риск увода денег с нескольких расчётных счетов.
Есть какие-нибудь рекомендательные письма ЦБ или другие нормативно-правовые акты, которые бы запрещали использование нескольких ЭЦП на одном токене? Клиенты ругаются и возмущаются, требуя юридическое обоснование нашего отказа.
Заранее спасибо!

[malotavr]

> Понятно, что повышается риск мошеннических переводов

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

Поэтому запрет "один ключ - один токен" действительно не обоснован.
Нормативными документами это тоже не регламентировано.

[Dmitry leviev]

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

[malotavr]

А вот давайте не будем вводить людей в заблуждение?

Ваше обоснование - один ключ на один токен может быть связано с поэкземплярным учетом согласно 152 инструкции ФАПСИ, когда токен является СКЗИ или средством ЭП.

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

этом случае вы Каждому клиенту должны выдать кол-во токенов с уникальными номерами равному ко-во подписей в карточке образцов (115-Т никто не отменял).

Может быть, 115-ФЗ? Так он тоже ничего подобного не требует.

[Dolphina12]

> Понятно, что повышается риск мошеннических переводов

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

Можно не соглашусь с поправкой?
Я своих учу все-таки один ключ-один токен. Но при этом поясняю, что один комп-один токен в момент работы с Клиент-Банком. Т е установили первый токен, зашли-подписали первой подписью, вынули токен, вставили второй токен, опять зашли-подписали второй. При этом даже если мошенник захочет подложить платежку при использовании двух носителей и 2-х подписей, то бух может при втором входе обнаружить "сюрприз". В реальной жизни я такую ситуацию видела. После первой подписи клиент перелогинился со второй подписью и увидел подложную платежку. Платежка, конечно, никуда не ушла.

[malotavr]

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

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

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

[Sat_Kelman]

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

У нас сделанно именно так, если на Клиента несколько организаций, то ключ один, но подцеплен ко всем его организациям. А вот если идет первая-вторая подпись, то тут ключи разные. Но у нас Клиенты сами выбирают количество подписей, если будет платежки делать один человек, то явно вторая подпись не нужна.

[!Сергуня]

У нас сделанно именно так, если на Клиента несколько организаций,

В банках, вообще-то, несколько другой принцип понятия "Клиент".
А именно - "Одна организация = Один клиент".

Т.е. в вашем случае имеем - "несколько организаций -> несколько клиентов".

[malotavr]

В банках, вообще-то, несколько другой принцип понятия "Клиент".
А именно - "Одна организация = Один клиент".

Т.е. в вашем случае имеем - "несколько организаций -> несколько клиентов".

Не надо говорить за все банки
В крупных корпоративных банках - да. В небольших региональных банках все немножко по-другому.

[!Сергуня]

Не надо говорить за все банки
В крупных корпоративных банках - да. В небольших региональных банках все немножко по-другому.

А что - в РФ банковское законодательство писано отдельно для крупных корпоративных банков и отдельно для небольших региональных?

Может и ФЗ-115 для каждой категории банков отдельно написан?

ЗЫ Налоговики вон утверждают, что если гендир обоих сторон по сделке является одним и тем же лицом, то эта сделка ничтожна...
А там и до подозрений в отмывании этому гендиру недалеко.

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

Не так ли?

[malotavr]

А что - в РФ банковское законодательство писано отдельно для крупных корпоративных банков и отдельно для небольших региональных?
Может и ФЗ-115 для каждой категории банков отдельно написан?

"Вы таки да?" (с)

Не имею привычки отвечать на риторические вопросы. Знаете норму закона, запрещающую ЕИО двух организаций иметь один закрытый ключ для двух разных ЭП - будьте любезны предъявить. Не знаете (а вы не знаете, так как таковой не существует в природе) - тут и сказочке конец. Вы вообще в курсе, что в соответствии с законодательством РФ лицо имеет право использовать для создания ЭП один ключ с одним квалифицированным сертификатом, и эта ЭП обязана признаваться равнозначной собственноручной подписи всеми его контрагентами?

ЗЫ Налоговики вон утверждают, что если гендир обоих сторон по сделке является одним и тем же лицом, то эта сделка ничтожна...
А там и до подозрений в отмывании этому гендиру недалеко.

Мало ли кто что сдуру ляпнул, тем более, что вопросы признания недействительности сделок, равно как и вопросы противодействия легализации преступных доходов, не входят в компетенцию налоговых органов. А закрытый перечень оснований для признания сделку недействительной приведен в статьях 168-179 ГК РФ, и совмещение в одном лице функций ЕИО обоих контрагентов к таковым ни разу не относится.

Не так ли?

Не так.

[Dmitry leviev]

Начнем сначала:
1. Ключ выдает Банк на носителе типа токен. Токен имеет систему разграничения прав доступа для пользователя и администратора безопасности.
Согласно требований сертификата на СКЗИ, только при обеспечении тайны ключей шифрования и подписи сертификат действителен. В этом случае на одном токене не может содержаться ключевой информации более чем одного пользователя. (ru и e-token так работают по документам). Про iBank2 не говорим - там отдельная тема.
2. 115-Т в рамках 115-ФЗ дает требование по идентификации каждого кто распоряжается счетом, следовательно смотря на документы по эксплуатации СКЗИ нам надо каждому пользователю дать СКЗИ, т.к. они должны самостоятельно хранить в личных сейфах ключевые документы.
Вот такая логика.
Если нужно более подробно, то плиз в студию тип и модификацию СКЗИ /средства ЭП, а также метод управления ключевой информацией.

[malotavr]

Дмитрий, притормозите полет фантазии.

Начнем сначала:

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

115-Т в рамках 115-ФЗ дает требование по идентификации каждого кто распоряжается счетом, следовательно смотря на документы по эксплуатации СКЗИ нам надо каждому пользователю дать СКЗИ

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

[!Сергуня]

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

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

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

[malotavr]

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

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

Физически уничтожать ключевой носитель ради уничтожения ключа? Мсье знает толк в извращениях На нормальном ключевом носителе (особенно для сертифицированных СКЗИ) для этого достаточно удалить ключевой контейнер.

Но вообще-то закрытую часть ключа подписи и не требуется уничтожать: после устаревания или отзыва сертификата она перестает быть чувствительной информацией.

[!Сергуня]

Но вообще-то закрытую часть ключа подписи и не требуется уничтожать: после устаревания или отзыва сертификата она перестает быть чувствительной информацией.

Да, наверное так и есть. А если ключ скомпрометирован, надо его уничтожать? А если железно известно, что скомпрометирован только один из ключей на носителе - можно ли считать, что с остальными ключами на энтом же носителе все в порядке?

На нормальном ключевом носителе (особенно для сертифицированных СКЗИ) для этого достаточно удалить ключевой контейнер.

А на ненормальном носителе (на который можно сделать запись только один раз) - что достаточно сделать? Кинуть носитель под танк - этого достаточно будет?

[malotavr]

Да, наверное так и есть. А если ключ скомпрометирован, надо его уничтожать? А если железно известно, что скомпрометирован только один из ключей на носителе - можно ли считать, что с остальными ключами на энтом же носителе все в порядке?

Не только на этом, но и на всех остальных, использовавшихся на этом компьютере примерно в это же время

А на ненормальном носителе (на который можно сделать запись только один раз) - что достаточно сделать? Кинуть носитель под танк - этого достаточно будет?

Еще раз: ключи ЭП (в отличие от ключей шифрования) уничтожать вообще без надобности. Для этого существует отзыв сертификата.

[spirtuoso]

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

[Berckut]

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

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

[spirtuoso]

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

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

[Berckut]

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

Почему? Какая вам разница, куда клиент клиент ключи записал. Не вы их записали, не вам и учитывать.
Я регистриру только выданный сертификат на носителе электронная посылка и выданную смарт-карту.

[spirtuoso]

Почему? Какая вам разница, куда клиент клиент ключи записал. Не вы их записали, не вам и учитывать.
Я регистриру только выданный сертификат на носителе электронная посылка и выданную смарт-карту.

Хорошо. Допустим, на токене клиента есть ключи, выпущенные на разные физические лица - как в таком случае?

[Berckut]

Хорошо. Допустим, на токене клиента есть ключи, выпущенные на разные физические лица - как в таком случае?

Ключи на токен записываете вы или клиент?

[spirtuoso]

Ключи на токен записываете вы или клиент?

разумеется клиент, мы только токен отдаем.

[Berckut]

разумеется клиент, мы только токен отдаем.

Тогда зачем заносить в журнал факт записи на носитель ключа и расписываться за это, если в реальности вы этого не делали?

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

[ads-h]

Хорошо. Допустим, на токене клиента есть ключи, выпущенные на разные физические лица - как в таком случае?

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

[eaa88]

Токен iBank2key содержит не только ключи, но и СКЗИ (Криптомодуль С23), с помощью которого эти ключи создаются. Вот интересно, если Банк выдал одному юридическому лицу токен, а в итоге использует его несколько ЮЛ, то по сути ведь это незаконная деятельность по распространению СКЗИ!

[malotavr]

Токен iBank2key содержит не только ключи, но и СКЗИ (Криптомодуль С23), с помощью которого эти ключи создаются. Вот интересно, если Банк выдал одному юридическому лицу токен, а в итоге использует его несколько ЮЛ, то по сути ведь это незаконная деятельность по распространению СКЗИ!

"Шарик, по квитанции — корова рыжая одна! Да, брали мы ее одну по квитанции, сдавать будем одну, чтобы не нарушать отчетностей!" (c)

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

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

[eaa88]

"Шарик, по квитанции — корова рыжая одна! Да, брали мы ее одну по квитанции, сдавать будем одну, чтобы не нарушать отчетностей!" (c)

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

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

СКЗИ тоже подлежит поэкземплярному учету. И токен - это не только носитель (ключевой документ), но и криптографическое средство. Получается ЮЛ № 1 мы передали СКЗИ, ЮЛ № 1 передало СКЗИ ЮЛ № 2. Ведь эта передача между ЮЛ № 1 и № 2 не совсем законна? На это ведь лицензия ФСБ нужна?

[spirtuoso]

Да, с этим понимание у меня сложилось. А вот надо ли как-то учитывать в пресловутом журнале (приложение №1 к приказу 152) факт использования токеном других юрлиц? Или отметили первого (кому выдано по акту), и все?