skysilver Опубликовано 15 Октября 2012 Жалоба Поделиться Опубликовано 15 Октября 2012 Доброго времени суток!Возвращаюсь к проблеме, возникающей в ходе первичной инициализации клиента. Злополучная ошибка 58! ))Слишком уж часто она стала меня преследовать в последнее время. Надо как-то решать вопрос. Помогайте, коллеги.Вводная следующая.Имеем ViPNet Administrator 3.2(9.11881) KC3 (Windows XP SP3). Работает без нареканий, ничего подозрительного за ним не замечал. Два ПАКа Coordinator HW1000G2 в кластере (версию точно не помню, при необходимости уточню) работают круглые сутки, проблем с ними нет. Ну и многострадальные клиенты ViPNet Client 3.1(1.6238) KC3. Большинство клиентов - удаленные пользователи.На клиентских машинах повсеместно ОС Windows 7 Pro x32 (бывают и х64), установленные с нуля. На каждом сетевом узле регистрируется по два пользователя с правом подписи, полномочия у всех минимальные. Каждому присваивается свой ruToken32 S. При копировании dst-файлов из УКЦ в качестве контейнера ключей шифрования, сертификата и закрытого ключа сертификата указывается токен, авторизация соответственно "Устройство". Контейнеры на токене создаются без ошибок, dst-файлы копируются как положено. Сам клиент устанавливается без проблем (на всякий случай добавлен в исключения антивируса). А вот инициализация заканчивается ошибкой.Если теми же токенами и dst-файлами проинициализировать ViPNet Client 3.2(9.11495), то все гладко и превосходно. Также выявил интересный момент - если при копировании дистрибутивов из УКЦ не использовать токены и использовать авторизацию по паролю, то инициализация пролетает без ошибок и все работает корректно.Вроде бы, вот оно решение! Но, увы нам оно не подходит. Версия 3.2 не подходит категорически, т.к. не сертифицирована ни ФСТЭК, ни ФСБ. Тем более, что дистрибутива клиента 3.2 на класс КС3 в природе нет (так сказали в тех. поддержке). А использовать авторизацию по паролю и, главное, хранить ключи шифрования и закрытый ключ подписи в каталоге на HDD не позволяет модель угроз и политика безопасности. ((Как быть, коллеги? Куда копать? Проблема катастрофически актуальная.P.S.: в тех. поддержку обращался, тикет завели, внятного ничего не сказали. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 15 Октября 2012 Жалоба Поделиться Опубликовано 15 Октября 2012 Доброго времени суток!Возвращаюсь к проблеме, возникающей в ходе первичной инициализации клиента. Злополучная ошибка 58! ))Слишком уж часто она стала меня преследовать в последнее время. Надо как-то решать вопрос. Помогайте, коллеги.Вводная следующая.Имеем ViPNet Administrator 3.2(9.11881) KC3 (Windows XP SP3). Работает без нареканий, ничего подозрительного за ним не замечал. Два ПАКа Coordinator HW1000G2 в кластере (версию точно не помню, при необходимости уточню) работают круглые сутки, проблем с ними нет. Ну и многострадальные клиенты ViPNet Client 3.1(1.6238) KC3. Большинство клиентов - удаленные пользователи.На клиентских машинах повсеместно ОС Windows 7 Pro x32 (бывают и х64), установленные с нуля. На каждом сетевом узле регистрируется по два пользователя с правом подписи, полномочия у всех минимальные. Каждому присваивается свой ruToken32 S. При копировании dst-файлов из УКЦ в качестве контейнера ключей шифрования, сертификата и закрытого ключа сертификата указывается токен, авторизация соответственно "Устройство". Контейнеры на токене создаются без ошибок, dst-файлы копируются как положено. Сам клиент устанавливается без проблем (на всякий случай добавлен в исключения антивируса). А вот инициализация заканчивается ошибкой.Если теми же токенами и dst-файлами проинициализировать ViPNet Client 3.2(9.11495), то все гладко и превосходно. Также выявил интересный момент - если при копировании дистрибутивов из УКЦ не использовать токены и использовать авторизацию по паролю, то инициализация пролетает без ошибок и все работает корректно.Вроде бы, вот оно решение! Но, увы нам оно не подходит. Версия 3.2 не подходит категорически, т.к. не сертифицирована ни ФСТЭК, ни ФСБ. Тем более, что дистрибутива клиента 3.2 на класс КС3 в природе нет (так сказали в тех. поддержке). А использовать авторизацию по паролю и, главное, хранить ключи шифрования и закрытый ключ подписи в каталоге на HDD не позволяет модель угроз и политика безопасности. ((Как быть, коллеги? Куда копать? Проблема катастрофически актуальная.P.S.: в тех. поддержку обращался, тикет завели, внятного ничего не сказали.А кто мешает создавать DST файлы с закрытым ключём ЭП и личными ключами?! А после инициализации ключи перенести на токен. Правда, для этого потребуется временное повышение полномочий, так как с минимальными полномочиями пользователь этого сделать не сможет. В качестве альтернативы можно просто сделать им временный пароль администратора сетевого узла, который следует менять сразу после инициализации. Регламент безопасности это не возбраняет. Хотя, стоит перечитать его ещё разок. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
skysilver Опубликовано 15 Октября 2012 Автор Жалоба Поделиться Опубликовано 15 Октября 2012 А кто мешает создавать DST файлы с закрытым ключём ЭП и личными ключами?! А после инициализации ключи перенести на токен. Правда, для этого потребуется временное повышение полномочий, так как с минимальными полномочиями пользователь этого сделать не сможет. В качестве альтернативы можно просто сделать им временный пароль администратора сетевого узла, который следует менять сразу после инициализации. Регламент безопасности это не возбраняет. Хотя, стоит перечитать его ещё разок.Я прорабатывал такой сценарий. Результат, увы не самый оптимистичный. После переноса ключевой информации пользователей на их персональные токены до перезагрузки ОС клиент работает корректно, а пользователи сменяются между собой без проблем. Но вот после перезагрузки не удается авторизоваться в клиенте - ошибка "Не найден ключевой диск". Если в окне авторизации вручную указывать каталог ключей пользователя, то снова "Не найден ключевой диск". Причем по-умолчанию в качестве каталога ключей пользователя почему-то стоит папка System32. Откуда он ее вообще взял такую? ))В целом же хочется избежать ручного переноса ключей на токен на каждом клиенте, потому что удаленные пользователи не будут с этим заморачиваться и будут хранить все ключи на HDD, а авторизоваться по паролю. Им так проще. А с учетом того, что они и орг. мероприятия толком не выполняют, и режим в здании не могут обеспечить, то это дело принимает совсем печальный оборот. А мне удаленно это никак не проконтролировать. Кататься самому тоже не вариант - целая область как никак. А ФСБ при первой проверке такое предписание накатает, что мало не покажется.Я, ведь, не хочу ничего сверхъестественного от ViPNet`a. Только его штатные функции, все согласно документации. Только вот продукт свои заявленные функции почему-то не выполняет.Какие будут соображения, коллеги? Как выходить из ситуации? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 16 Октября 2012 Жалоба Поделиться Опубликовано 16 Октября 2012 Я прорабатывал такой сценарий. Результат, увы не самый оптимистичный. После переноса ключевой информации пользователей на их персональные токены до перезагрузки ОС клиент работает корректно, а пользователи сменяются между собой без проблем. Но вот после перезагрузки не удается авторизоваться в клиенте - ошибка "Не найден ключевой диск". Если в окне авторизации вручную указывать каталог ключей пользователя, то снова "Не найден ключевой диск". Причем по-умолчанию в качестве каталога ключей пользователя почему-то стоит папка System32. Откуда он ее вообще взял такую? ))В целом же хочется избежать ручного переноса ключей на токен на каждом клиенте, потому что удаленные пользователи не будут с этим заморачиваться и будут хранить все ключи на HDD, а авторизоваться по паролю. Им так проще. А с учетом того, что они и орг. мероприятия толком не выполняют, и режим в здании не могут обеспечить, то это дело принимает совсем печальный оборот. А мне удаленно это никак не проконтролировать. Кататься самому тоже не вариант - целая область как никак. А ФСБ при первой проверке такое предписание накатает, что мало не покажется.Я, ведь, не хочу ничего сверхъестественного от ViPNet`a. Только его штатные функции, все согласно документации. Только вот продукт свои заявленные функции почему-то не выполняет.Какие будут соображения, коллеги? Как выходить из ситуации?К сожалению, сертифицированные версии выходят довольно сырые, со многим приходится мириться. Давайте попробуем разобраться. Что у Вас ещё на компьютере стоит? Какое-то средство защиты от НСД? Или что-то подобное? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
skysilver Опубликовано 16 Октября 2012 Автор Жалоба Поделиться Опубликовано 16 Октября 2012 К сожалению, сертифицированные версии выходят довольно сырые, со многим приходится мириться. Давайте попробуем разобраться. Что у Вас ещё на компьютере стоит? Какое-то средство защиты от НСД? Или что-то подобное?Рабочий АРМ на базе ОС Windows 7 Pro x32, MS Office 2010 Pro, Adobe Acrobat 8.0, системные драйвера устройств и драйвера ruToken (v.2.85.00.0453). Из прикладного и системного ПО больше нет ничего.По СЗИ имеем следующее - Антивирус Касперского 6.0 WS (либо Dr. Web Enterprise Suite 6.0), СЗИ от НСД "Secret Net 6.5 К" (автономный вариант), ПАК "Соболь 3.0" (PCI-E) в совместном режиме с Secret Net. Все СЗИ настроены на авторизацию по устройству. Пользователь вводит только PIN от токена. Касательно антивируса - встроенный компонент МЭ отключен на этапе установки. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 16 Октября 2012 Жалоба Поделиться Опубликовано 16 Октября 2012 Рабочий АРМ на базе ОС Windows 7 Pro x32, MS Office 2010 Pro, Adobe Acrobat 8.0, системные драйвера устройств и драйвера ruToken (v.2.85.00.0453). Из прикладного и системного ПО больше нет ничего.По СЗИ имеем следующее - Антивирус Касперского 6.0 WS (либо Dr. Web Enterprise Suite 6.0), СЗИ от НСД "Secret Net 6.5 К" (автономный вариант), ПАК "Соболь 3.0" (PCI-E) в совместном режиме с Secret Net. Все СЗИ настроены на авторизацию по устройству. Пользователь вводит только PIN от токена. Касательно антивируса - встроенный компонент МЭ отключен на этапе установки.Теоретически возможен конфликт с SecretNet, хотя с ним VipNet не сращивал ни разу. Работал, в основном, с СЗИ от НСД "Аура". Там проблемы иногда бывали следующего характера: из-за того, что Аура постоянно мониторила токен, чтобы по его отключению заблокировать компьютер, то доступа к токену иногда випнет не получал. Проблема решалась выниманием и вставкой токена. Может, попробовать данную функцию на "чистом" компьютере, чтобы иключить глюки vipnet?! Может, здесь тоже происходит какая-нибудь блокировка СЗИ?! Какая именно сложно сказать. Обычно в журнале СЗИ по таким проблемам бывает полезная информация.Кстати, и подобная ситуация была. В некоторых инсталляциях при установке КриптоПро драйвер RuTokenа падал при входе в систему и не давал авторизоваться по токену (естественно, в связке с СЗИ от НСД). Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
AnTonN(c) Опубликовано 16 Октября 2012 Жалоба Поделиться Опубликовано 16 Октября 2012 Попробуй следующее: первичка пользователей с сохранением на диск, меняешь пароль первого пользователя и переносишь на токен. Должно все заработать. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Stratos Опубликовано 17 Октября 2012 Жалоба Поделиться Опубликовано 17 Октября 2012 Номер обращение в техподдержку скиньте. Можно в личку. Попытаемся разобраться, кто там "невнятное" ответил. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
skysilver Опубликовано 17 Октября 2012 Автор Жалоба Поделиться Опубликовано 17 Октября 2012 Номер обращение в техподдержку скиньте. Можно в личку. Попытаемся разобраться, кто там "невнятное" ответил.Запрос № 001-00-131736. Сегодня получил от них еще одно сообщение. Проблему признали. Как говорят, виноват целиком и полностью ViPNet Client. Путей решения проблемы не предложили вообще никаких. Если, конечно, не считать решением обещание сертифицированного по КС3 клиента в январе 2013. )) Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 17 Октября 2012 Жалоба Поделиться Опубликовано 17 Октября 2012 Запрос № 001-00-131736. Сегодня получил от них еще одно сообщение. Проблему признали. Как говорят, виноват целиком и полностью ViPNet Client. Путей решения проблемы не предложили вообще никаких. Если, конечно, не считать решением обещание сертифицированного по КС3 клиента в январе 2013. ))Естественно. Доработки в сертифицированный продукт нельзя вносить без пересертификации. Поэтому патчи не котируются. Хотя некоторые лицензиаты, которые внедряют VipNet, думают иначе. Сам жду сертифицированного клиента КС2 к началу следующего года, а то эта сертифицированная версия неудачной получилась. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
skysilver Опубликовано 17 Октября 2012 Автор Жалоба Поделиться Опубликовано 17 Октября 2012 Попробуй следующее: первичка пользователей с сохранением на диск, меняешь пароль первого пользователя и переносишь на токен. Должно все заработать.Сегодня на двух компах откатал сценарий с "ручным" переносом ключей и контейнеров на токен под правами администратора сетевого узла.В УКЦ изначально создал DST-файлы без использования токенов. При таком раскладе первичная инициализация прошла успешно. Проверил авторизацию пользователей по паролю - все хорошо, в т.ч. после перезагрузки. Затем перенес ключи шифрования и контейнер закрытого ключа с сертификатом одного пользователя на токен, проверил авторизацию после перезагрузки - ошибок нет. Повторил все тоже самое для второго пользователя, перезагрузился, авторизовался успешно. В итоге получил рабочую станцию. Ошибка, описанная мною в посте №3, в этот раз не возникла, т. к. на токенах не было никаких контейнеров от предыдущей неудачной инициализации.Т.е. по сути сам ViPNet Client не конфликтует с установленными СЗИ и с токенами работает корректно. А вот мастер первичной инициализации не может отработать до конца при использовании токенов.Проблема по-прежнему актуальна. Большинство пользователей удаленные и из разных организаций. Первичную инициализацию они проводят самостоятельно. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.