Comments 27
Специально купил себе RuToken ЭП 2.0 микро «на побаловаться».
Было очень интересно посмотреть, как он запустится под Linux.
К сожалению, для реальной работы этого оказалось недостаточно. После получения сертификата ЭП требуется установка приптопровайдера и дополнительных приложений, которые работают только под Windows.
P.S. Поэтому настроить можно, это действительно круто, но бесполезно по независящим от вас причинам.
P.P.S. И кстати, прости меня родной Аладдин, с Рутокеном я справился гораздо проще и быстрее.
Было очень интересно посмотреть, как он запустится под Linux.
Запустился по инструкции с первого раза и даже определяется на nalog.ru
К сожалению, для реальной работы этого оказалось недостаточно. После получения сертификата ЭП требуется установка приптопровайдера и дополнительных приложений, которые работают только под Windows.
P.S. Поэтому настроить можно, это действительно круто, но бесполезно по независящим от вас причинам.
P.P.S. И кстати, прости меня родной Аладдин, с Рутокеном я справился гораздо проще и быстрее.
Мы сейчас как раз активно работаем над тем, чтобы Рутокен ЭЦП 2.0 работал с личным кабинетом юр. лица в налоговой без криптопровайдера. Так что следите за нашими анонсами.
rsashka, с налоговой все взлетит, если пойти в кабинет ИП, а не Юрлица. Попробуйте, если будет такая возможность.
Ну а с юрлицами тоже все будет, но попозже.
Ну а с юрлицами тоже все будет, но попозже.
После такой аутентификации сервер уже знает какой пользователь на него зашёл и можно больше не делать никаких дополнительных окон для проверки, а сразу пускать пользователя в его личный кабинет.Не совсем понятно, откуда сервер будет знать, кто на него вошел? Понятно, что он получит сертификат из ключа, как предъявленный документ. Но ведь информация в сертификате еще должна как-то привязаться к аккаунту пользователя, нет? А что, если данные пользователя не зарегистрированы в системе? Авторегистрация? Как тогда определить права и роли автоматически?
И где двухфакторная авторизация? Пин-код ключа — это не фактор вроде.
Сервер получает информацию в сертификате, которая как вы правильно заметили должна быть привязана к аккаунту. Я в этой статье больше пишу про корпоративные порталы (смотрите статью на которую я ссылаюсь в начале). В корпоративных порталах авторегистрация редко предусмотрена, а права и роли задаются, например, при приеме на работе.
Можно сделать и вариант с авторегистрацией, если у вас все пользователи по умолчанию с одними правами. А повышать их уже по запросу. Тоже весьма типичный сценарий.
Что касается двухфакторности. Ключ к сертификату хранится на токене в неизвлекаемом виде, доступ к ключу можно получить только зная PIN-код. Выполнить вход под своей учеткой без токена не получится. Это первый фактор, так называемый фактор владения. А PIN-код — это второй фактор, фактор знания.
Можно сделать и вариант с авторегистрацией, если у вас все пользователи по умолчанию с одними правами. А повышать их уже по запросу. Тоже весьма типичный сценарий.
Что касается двухфакторности. Ключ к сертификату хранится на токене в неизвлекаемом виде, доступ к ключу можно получить только зная PIN-код. Выполнить вход под своей учеткой без токена не получится. Это первый фактор, так называемый фактор владения. А PIN-код — это второй фактор, фактор знания.
Спасибо, понял по сертификату.
По факторам получается, если хранить ключ в сейфе под кодовым замком, то получаем четырехфакторную идентификацию? (плюс код сейфа и сам сейф как фактор владения).
Только на стороне портала (сервера) идентификация всё равно однофакторная остаётся — по сертификату и всего. Мне казалось, многофактор — это когда сам сервер проверяет идентификацию по нескольким каналам, а не заворачивание идентификационных данных в кучу обёрток.
По факторам получается, если хранить ключ в сейфе под кодовым замком, то получаем четырехфакторную идентификацию? (плюс код сейфа и сам сейф как фактор владения).
Только на стороне портала (сервера) идентификация всё равно однофакторная остаётся — по сертификату и всего. Мне казалось, многофактор — это когда сам сервер проверяет идентификацию по нескольким каналам, а не заворачивание идентификационных данных в кучу обёрток.
Про многофакторную аутентификацию ведется масса холиваров, нередко замешанных на маркетинговом буллшите. Часто путают 2-факторную аутентификацию, 2-этапную верификацию, многоканальную аутентификацию и т.д.
С моей точки зрения в такой ситуации следует полагаться на авторитетные официальные источники. Например вот:
csrc.nist.gov/glossary/term/Multi_Factor-Authentication
С моей точки зрения в такой ситуации следует полагаться на авторитетные официальные источники. Например вот:
csrc.nist.gov/glossary/term/Multi_Factor-Authentication
Благодарю! Похоже, я тоже попался на эту удочку.
И хотя описанная в статье схема полностью соответствует букве стандартов, для оператора сервера существует ненулевой риск сваливания в однофактор (если пользователь отменит запрос пин-кода или сделает его легко подбираемым).
Описанная схема работы как раз и напоминает маркетинговый треш, когда вроде используется два фактора, но контролю поддаётся только один, и потому для безопасника это не выглядит как два фактора.
И хотя описанная в статье схема полностью соответствует букве стандартов, для оператора сервера существует ненулевой риск сваливания в однофактор (если пользователь отменит запрос пин-кода или сделает его легко подбираемым).
Описанная схема работы как раз и напоминает маркетинговый треш, когда вроде используется два фактора, но контролю поддаётся только один, и потому для безопасника это не выглядит как два фактора.
Отменить запрос PIN-кода нельзя. И легко подобрать тоже. Многие безопасники смешивают пароли и PIN-коды, а этого делать не стоит. PIN проверяется и блокируется аппаратно. Количество попыток сильно ограничено. Стандартно 10, но можно и 3 поставить. И перебрать даже PIN из 4 цифр за 10 попыток шансов совсем мало. А пользователю эти 4 цифры запомнить просто. Это не сложные пароли из 10 символов, где заставляют вставлять спец. символы, буквы в разных регистрах и так далее.
К сожалению, не могу согласиться.
Плюс к этому — более половины пользователей токенов не меняют заводские пины (личная практика). Если пин 4 цифры — его легко подсмотреть и запомнить хотя бы 3 цифры, а четвертую подобрать за 10 стандартных попыток. На самом деле пины растекаются очень интенсивно, даже от банковских карточек.
Вот на самом деле, почему не говорят, что банковская карточка использует двухфакторную аутентификацию? Ведь по сути у неё есть пин, а идентификатор клиента закодирован в чипе, 2 фактора на лицо.
PIN проверяется и блокируется аппаратно. Количество попыток сильно ограничено.Увы, сделать аппаратный дубликат возможно. Потом его заблокировать и сделать еще один и так пока не надоест. То есть количество попыток не ограничено, если выйти в аппаратную плоскость.
Плюс к этому — более половины пользователей токенов не меняют заводские пины (личная практика). Если пин 4 цифры — его легко подсмотреть и запомнить хотя бы 3 цифры, а четвертую подобрать за 10 стандартных попыток. На самом деле пины растекаются очень интенсивно, даже от банковских карточек.
Вот на самом деле, почему не говорят, что банковская карточка использует двухфакторную аутентификацию? Ведь по сути у неё есть пин, а идентификатор клиента закодирован в чипе, 2 фактора на лицо.
Сделать аппаратный дубликат защищенного токена у вас вряд ли получится. А если и получится, то цена вопроса будет в миллионах и не рублей. Это далеко не так просто, как вам кажется.
В PIN-коде можно и буквы использовать. Тогда за 10 попыток уже не получится. Плюс надо же еще токен украсть. А это не так просто и самое главное очень заметно. Если я, например, ваш пароль узнал, то заметить это только по логам входа получится. А отсутствие физической железки сразу видно.
Аутентификацию может использовать сервис. А не карточка. Не говорят — потому что наличие самой карты при оплате в интернете не проверяется. Цифры с карты это не сама карта. А вот в банкомате — полноценная двухфакторная аутентификация.
В PIN-коде можно и буквы использовать. Тогда за 10 попыток уже не получится. Плюс надо же еще токен украсть. А это не так просто и самое главное очень заметно. Если я, например, ваш пароль узнал, то заметить это только по логам входа получится. А отсутствие физической железки сразу видно.
Аутентификацию может использовать сервис. А не карточка. Не говорят — потому что наличие самой карты при оплате в интернете не проверяется. Цифры с карты это не сама карта. А вот в банкомате — полноценная двухфакторная аутентификация.
Сделать аппаратный дубликат защищенного токена у вас вряд ли получится. А если и получится, то цена вопроса будет в миллионах и не рублей. Это далеко не так просто, как вам кажется.Вот это совсем не так:
- Оборудование для самого жесткого вмешательства в аппаратную часть можно прикупить на али за пару килобаксов в комплексе.
- На сегодняшний день вроде нет чипов, интегрирующих АЛУ и ПЗУ на разных слоях одной микросхемы. А значит, извлечь и сделать дамп ПЗУ технически несложно.
- Сертификация ключей в любом органе (ФСБ, АНБ) подразумевает наличие алгоритмов восстановления ключа по обломкам его микросхем. А это то же самое, что создать дубликат ключа.
- Во всех стандартах NISTа попадание ключа в чужие руки расценивается как возможность появления дубликата и такой ключ должен быть максимально быстро заблокирован и при необходимости перевыпущен.
А вот в банкомате — полноценная двухфакторная аутентификация.Тоже не факт. Если пин проверяется чипом карты, то это просто однофакторная аутентификация в двух разных сервисах — карта и банк. Реализация зависит от возможностей банкомата.
И с рутокенами тоже не факт, что пин проверяет ключ, а не установленное на компьютер ПО производителя — пруф между строк
Ну раз уж мы решили разобраться глубоко, давайте разберемся.
Ошибаетесь. Более того технологий защиты у чипов предостаточно.
Опять же ошибаетесь. Восстановление ключа для ФСБ имеет смысл при шифровании, а не подписи. И добиваются этого обычно другими способами, а не восстановлением по обломкам.
Конечно, если ключ был украден или утерян он должен быть заблокирован. Для этого и нужен PKI. Но тут скорее защищаются от того, что PIN тоже был скомпрометирован каким-то способом.
В Рутокене PIN проверяет ключ. Даже в том случае, если используется хранение контейнеров КриптоПро на токене. В том пруфе на который вы ссылаетесь, человек путает 2 понятия — неизвлекаемость и неэкспортируемость.
На сегодняшний день вроде нет чипов, интегрирующих АЛУ и ПЗУ на разных слоях одной микросхемы.
Ошибаетесь. Более того технологий защиты у чипов предостаточно.
Сертификация ключей в любом органе (ФСБ, АНБ) подразумевает наличие алгоритмов восстановления ключа по обломкам его микросхем
Опять же ошибаетесь. Восстановление ключа для ФСБ имеет смысл при шифровании, а не подписи. И добиваются этого обычно другими способами, а не восстановлением по обломкам.
Конечно, если ключ был украден или утерян он должен быть заблокирован. Для этого и нужен PKI. Но тут скорее защищаются от того, что PIN тоже был скомпрометирован каким-то способом.
В Рутокене PIN проверяет ключ. Даже в том случае, если используется хранение контейнеров КриптоПро на токене. В том пруфе на который вы ссылаетесь, человек путает 2 понятия — неизвлекаемость и неэкспортируемость.
Ошибаетесь. Более того технологий защиты у чипов предостаточно.Можете привести маркировку чипа, у которого ПЗУ находится под/поверх АЛУ? Не рядом, не на другом конце чипа, а именно в другом слое. Гугл не находит. Находит только те, где в одной плоскости компоновка. Я бы рад ошибаться, но пока не вижу опровержений.
Восстановление ключа для ФСБ имеет смысл при шифровании, а не подписи.Не уверен, что мы можем оценивать и обсуждать мотивы подобных организаций.
В Рутокене PIN проверяет ключ. Даже в том случае, если используется хранение контейнеров КриптоПро на токене.В Рутокене ПЗУ в кристалле процессора сделано? Подкинуть дубль файловой системы невозможно?
В том пруфе на который вы ссылаетесь, человек путает 2 понятияДаже если так, пруф не о том, как извлечь ключ. Пруф о том, что если АЛУ ключа не защищает данные в ПЗУ, то вытянуть их можно от лёгкого до не очень сложного способами.
Но даже если защищает, а к ПЗУ есть доступ извне, программатором можно создать/восстановить дамп и АЛУ ничего не будет знать о том, сколько раз уже подбирался пин.
Эта тема не повод для спора. Я говорю, что большинство ключей можно скопировать. Вы говорите, что есть ключи, которые нельзя скопировать. Я отвечаю, что возможно на сегодняшний день так и есть, но через некоторое время и к таким ключам будут найдены подходы. Вы соглашаетесь, что нет ничего невозможного в будущем, на смену придут более защищенные ключи, которые в том будущем тоже будет тяжело скопировать. Остаемся при своих мнениях.
Этот спор упирается не в «можно или нельзя», а «сколько это будет стоить».
Можно сделать абсолютно все, но некоторые вещи можно сделать либо очень дорого, либо очень долго.
Можно сделать абсолютно все, но некоторые вещи можно сделать либо очень дорого, либо очень долго.
Еще года 4 назад активно занимался карточными технологиями.
Участвовал в семинарах Gemalto и NXP. В частности, посвященным аппаратной защите чипов карт от извлечения ключа разными методами. Однако, чипы предназначенные для карт (а токен это по сути чип карты+USB ридер), весьма надежно защищены от различных атак разных методов.
(про чипы для GSM карт, речь не идет. Они зачастую дешевле и проще в массе..)
И информацию (подробности) о защите (аппаратной и методов безопасного создания приложений карт) и методов взлома в Интернете, Вы особо найдете. Не надо думать что в Интернете есть все.
Тоже не факт. Если пин проверяется чипом карты, то это просто однофакторная аутентификация в двух разных сервисах — карта и банк. Реализация зависит от возможностей банкомата.
И да… Банкомат по стандартам НЕ работает с off-line PIN. Исключительно on-line PIN через EPP клавиатуру.
И да… Банкомат по стандартам НЕ работает с off-line PIN. Исключительно on-line PIN через EPP клавиатуру.Не все банкоматы одинаковы
Имел возможность наблюдать как вскрываются микросхемы и дампятся микрокоды из интегрированного в кристалл ПЗУ.
Вот даже на Хабре есть статья о препарировании карты Яндекса.
Кажется, ваша вера в защищенность банковских чипов идёт от риторики маркетологов, а не от знания технологий защиты. Верить маркетологам производителей на слово — крайне опасное поведение.
И информацию (подробности) о защите (аппаратной и методов безопасного создания приложений карт) и методов взлома в Интернете, Вы особо найдете. Не надо думать что в Интернете есть все.Резонно. Как можно найти в Интернет информацию о том, чего нет в природе в принципе?
Не все банкоматы одинаковы
Рассуждают люди о том, про что они слышали краем уха. А на это рассуждение мне дают ссылку как пруф. Ага… А ничего что я лет 15 занимаюсь платежными технологиями и как раз у меня стандарты под рукой.
Вот даже на Хабре есть статья о препарировании карты Яндекса.
Еще один дилетант статью опубликовал. "Я тут посмотрел на чип и внешне он выглядит как все остальные чипы. Значит он не защищен".
Мда..
Резонно. Как можно найти в Интернет информацию о том, чего нет в природе в принципе?
Даже комментировать ну буду. Смысл.
Вы действительно считаете, что информация выданную "под роспись" (тип хотя бы коммерческие секреты) всяк имеющий к ней доступ норовит выложить в свободный доступ в Интернете?
Интернет это помойка.
Давать в качестве пруфов такие статьи и особенно диалог в конфе (его немного смешно читать. Как рассуждения людей, которые что то слышали… но все равно нифига точно не знают).
Кажется, ваша вера в защищенность банковских чипов идёт от риторики маркетологов, а не от знания технологий защиты.
Специализированные семинары по безопасному программированию апплетов карт и способах защиты ведут не маркетологи, а инженеры компаний, которые непосредственно этим занимаются. К слову..
Михаил, предлагаю направить беседу в конструктивное русло. Опыта у нас с вами у каждого предостаточно. Судя по различиям в мнениях, опыт у нас разный. Хотелось бы прояснить ситуацию, а не видение этой ситуации с высоты двух разных опытов.
Вы говорите, что у вас есть под рукой Стандарт, который регламентирует использование в банкоматах только онлайн проверки ПИНа. Но это всего лишь рекомендации, а не закон, которому необходимо безоговорочно следовать. Поэтому, даже если этот Стандарт распространяется на РФ, банки не обязаны ему следовать. И холивар в пруфе как раз показывает, что некоторые банки плевать хотели на Стандарт, которого придерживались вы.
К слову, вы пока не обозначили, что это за Стандарт у вас под рукой, к чему относится, как называется и где используется. У меня если поискать, тоже найдётся с десяток разных стандартов под рукой, даже таких, которые будут противоречить друг другу. Поэтому хотелось бы знать номер, дату и орган принятия Стандарта, о котором вы говорите.
В если добавить к этому, что на этих курсах никто не дает подписку о том, что программировать будет «безопасно», можно предположить, что большинство апплетов в картах представляют собой опасные для пользователя программы, что с одной стороны заставляет производителей проводить обучающие курсы для разработчиков, а с другой ставят под удар пользователей электронного пластика.
Вы говорите, что у вас есть под рукой Стандарт, который регламентирует использование в банкоматах только онлайн проверки ПИНа. Но это всего лишь рекомендации, а не закон, которому необходимо безоговорочно следовать. Поэтому, даже если этот Стандарт распространяется на РФ, банки не обязаны ему следовать. И холивар в пруфе как раз показывает, что некоторые банки плевать хотели на Стандарт, которого придерживались вы.
К слову, вы пока не обозначили, что это за Стандарт у вас под рукой, к чему относится, как называется и где используется. У меня если поискать, тоже найдётся с десяток разных стандартов под рукой, даже таких, которые будут противоречить друг другу. Поэтому хотелось бы знать номер, дату и орган принятия Стандарта, о котором вы говорите.
Специализированные семинары по безопасному программированию апплетов карт и способах защиты ведут не маркетологи, а инженеры компаний, которые непосредственно этим занимаются.«Безопасное программирование» — термин вызывает смешанные чувства. Заставляет думать, что существует и «опасное программирование апплетов карт», раз на эту тему организовываются курсы и семинары.
В если добавить к этому, что на этих курсах никто не дает подписку о том, что программировать будет «безопасно», можно предположить, что большинство апплетов в картах представляют собой опасные для пользователя программы, что с одной стороны заставляет производителей проводить обучающие курсы для разработчиков, а с другой ставят под удар пользователей электронного пластика.
Вы говорите, что у вас есть под рукой Стандарт, который регламентирует использование в банкоматах только онлайн проверки ПИНа. Но это всего лишь рекомендации, а не закон, которому необходимо безоговорочно следовать.
- Сложно сказать является ли сертификационные тесты EMV(co) (обязательны для прохождения перед сертификацией в Visa & MC & МИР & UP) "законом". Но в них предусмотрен ТОЛЬКО on-line PIN.
- В правилах платежных систем прописано
использование только on-line PIN.
Если Вам нужна обязательно сылка в Интернет
(https://www.mastercard.us/en-us/issuers/products-and-solutions/grow-manage-your-business/payment-innovations/chip-emv.html "Online PIN only")
Банки сами софт ATM не пишут и не сертифицируют.
Предположение, что какой то банк, будет нарушать правила платежных систем, скрывая это при обязательной сертификации (которая нехило стоит) своего процессинга и нарываться на штрафные санкции ПС…
Ну разве, что он выпускает свою локальную ПС со своими локальными картами и делает там что угодно.
«Безопасное программирование» — термин вызывает смешанные чувства. Заставляет думать, что существует и «опасное программирование апплетов карт», раз на эту тему организовываются курсы и семинары.
Да. Существует "опасное" программирование.
Просто для иллюстрации (я не собираюсь все рекомендации описывать).
Нельзя использовать boolean флаги в критических местах. Рекомендуется
private static final short TRUE = (short) 0xA5A5;
private static final short FALSE = (short) 0x5A5A;
...
is_critical_apdu = TRUE;
Был продемонстрирован пример, когда манипуляций напряжения и освещения УФ апплет вел себя не так как задуманно.
Так что, не все так просто.
По правилам, апплеты платежных приложений проходят penetration тесты в сертфикационных лабораториях. И если написаны без учета многих подобных тонкостей, то не пройдут сертификацию по факту.
Стоимость и сертификации логики и прочих сертификаций просто не сравнима со стоимостью создания апплета.
Ничего не знаю, про Рутокен и прочее. Знаю только про платежные апплеты и требования сертификации ПС.
Сложно сказать является ли сертификационные тесты EMV(co) (обязательны для прохождения перед сертификацией в Visa & MC & МИР & UP) «законом». Но в них предусмотрен ТОЛЬКО on-line PIN.Я не смог найти в требованиях EMV положения о недопустимости оффлайн-пина. Возможно это как раз требования последних редакций, которые тяжело найти.
В правилах платежных систем прописаноНе считается. Это объявление о продаже тестовых карт, среди характеристик которых поддержка только онлайн-пина. Это не правило, это просто обрезанная версия карты для тестов и девелопмента.
использование только on-line PIN.
Если Вам нужна обязательно сылка в Интернет
(https://www.mastercard.us/en-us/issuers/products-and-solutions/grow-manage-your-business/payment-innovations/chip-emv.html «Online PIN only»)
Ну разве, что он выпускает свою локальную ПС со своими локальными картами и делает там что угодно.Это тоже аргумент не в вашу пользу. Если банк может выпустить свою карту с оффлайн пином, то предположение, что пин проверяется всегда онлайн уже будет неверным. Зачем продолжать настаивать на этом? С точки зрения держателя пластика — на любой карте банка у него лежат его деньги.
Был продемонстрирован пример, когда манипуляций напряжения и освещения УФ апплет вел себя не так как задуманно.Похоже, всё-таки инженеры вели семинары, а не маркетологи. Нам эти вещи еще в институте рассказывали, многое уже позабылось )
Так что, не все так просто.
Ничего не знаю, про Рутокен и прочее. Знаю только про платежные апплеты и требования сертификации ПС.Требования к апплетам продиктованы стремлением защиты финансовой транзакции. Апплеты не могут знать, кто их использует в данный момент. Как и банк не может быть уверен, что операцию совершает именно владелец денег.
Если операция была совершена неправомерно, ответственность несет тот оператор, который принял карту. Поэтому платежные шлюзы стараются защититься, обязывая свои банкоматы проверять пин онлайн. В интернет еще 3д секури придумали, дополнительный способ авторизации платежа, т.к. у онлайн шлюзов нет возможности проверить пин.
Тем не менее, не все операции проходят тщательную проверку. Мне приходилось пользоваться онлайн сервисами, которые кроме номера карты и срока ничего не просили, даже cvv. Причем это была карта, покрытая 3д секурой с ног до головы.
В любом случае проблемы платежей выходят за рамки этой статьи. Токены, хоть внешне и похожи на банковские карты, но задачи у них другие. И выполнять свою функцию им мешает слишком вольная трактовка понятия «двухфакторная аутентификация».
Например, если пишут «двухфакторная аутентификация на сайте», то логично предположить, что именно сайт проверяет 2 фактора. А если сайт проверяет только сертификат, а чтобы получить сертификат человеку нужно ввести пин в токен, то это скорее «двухэтапная», а не «двуфакторная» аутентификация.
Один из вариантов (например для REST Web API) настройки nginx — это что ни будь типа
server {
listen 443 ssl;
ssl_verify_depth 1;
ssl_certificate /etc/nginx/Server.crt;
ssl_certificate_key /etc/nginx/ServerKey.pem;
ssl_client_certificate /etc/nginx/CA.crt;
ssl_verify_client on;
location / {
proxy_set_header X-TLS-iDN $ssl_client_i_dn;
proxy_set_header X-TLS-sDN $ssl_client_s_dn;
}
}А уже сервис, принимающий запрос, понимает по атрибутам клиентского сертификата — кто конкретно пришел и какие у него права.
Чисто для иллюстрации пример (можно и другие извращения с $ssl_client_.. придумать)
Но вообще, USB токен для захода на сайт через браузер ИМХО не удобно. Уж лучше брелок с OTP паролем (как альтернатива SMS/Push), как второй фактор к обычному паролю (ну или самый дешевый вариант — OTP приложение под смартфон).
А вот для аутентификации программных клиентов — аппаратный токен — само то..
И да… Для безопасности бы, не помешало бы изменить ssl_session_timeout с 5m по умолчанию, на что то более разумное (меньшее значение)
Все хорошо пока есть Windows и когда можно использовать любую Linux. Подскажите пожалуйста как обстоят дела с Astra Linux и планируется ли сертификация ФСТЭК? Уж больно часто приходится работать с гос.заказчиками и им очень хочется ЭЦП)
C Astra Linux дела обстоят хорошо. Прошли очередной раунд тестирования на совместимость с Astra Linux Common Edition (версии 1.10,1.11,2.12) и Special Edition (версии 1.4,1.5).
Сертификат ФСТЭК на ПАК Рутокен есть и действует. Так что гос.заказчиков можно успокоить. Если есть какие-то сомнения, задавайте вопросы. Если надо будет потестировать какую-то конкретную конфигурацию — обращайтесь, рассмотрим.
Сертификат ФСТЭК на ПАК Рутокен есть и действует. Так что гос.заказчиков можно успокоить. Если есть какие-то сомнения, задавайте вопросы. Если надо будет потестировать какую-то конкретную конфигурацию — обращайтесь, рассмотрим.
Отлично. Про Common Edition я и не сомневаюсь, что работает, как раз интересно было про SE, но вы меня опередили ответом). А можно немного подробнее про Special Edition (1.5, либо 1.6). Для рутокена нужны драйвера — где можно взять сертифицированные? Или нужно делать отдельный запрос и осуществлять закупку? Просто как раз-таки стоит задача — Контроллер домена, авторизация, документооборот, ЭЦП…
Для Astra SE мы рекомендуем брать токены из семейства Рутокен ЭЦП 2.0. Это CCID устройства, поэтому драйверы есть в самой ОС (в Astra SE тоже есть и все успешно работает). Может понадобится библиотека PKCS11 — она доступна как на нашем сайте, так и поставляется вместе с сертифицированной версией токена на диске.
Sign up to leave a comment.
Двухфакторная аутентификация на сайте с использованием USB-токена. Теперь и для Linux