Форум

[QUOTE]Екатерина_2014 пишет:
Согласна. Просто отмазываются. Браузер не влияет. У меня Яндекс. Если работает система-работает в любом браузере.[/QUOTE]Если Вы входите по логину-паролю, то согласен, должно быть без разницы, скорее дело в самой ГИС. И все же пара советов. Если заполняете данные организации самый первый раз, то нужно войти по сертификату и принять соглашение.
Если входите по сертификату, то воздержитесь от Гугл Хрома, в зависимости от плагина, используемого на сайте, на некоторые сайты вообще не пускает - блокирует плагин. Про плагин Госуслуг точно не помню, но фактически, можете не заморачиваться с установкой плагинов на Гугл - большинство отечественных плагинов не работают на версиях Хрома выше 38-39. Прочие браузеры на основе Хромиума пугают в будущем тоже блокировать, но пока что пускают.
С мозиллой (в зависимости от версии) бывают приколы с блокировкой сертификатов серверов, но с Госуслугами и ГИС ЖКХ пока ни разу не было.
Если заходите под Интернет Эксплорером с Windows 7, то все же лучше его обновить до 11 версии и поставить свежий накопительный пакет (один из немногих примеров когда обновление действительно помогает) либо сменить браузер. Например, когда мы регистрировались, не смогли заполнить данные организации под необновленным ie (была стандартная версия из Windows 7). Зашли с Opera 12.18 (что попалось под руку, не реклама браузера) и все прекрасно заполнилось и сохранилось.

[QUOTE]skad888 пишет:
у вас, наверно, пятерка была в школе по сочинениям  :)[/QUOTE]
[QUOTE]Sergey_P пишет:
скорее по системному анализу, и не в школе. %)[/QUOTE]Одно другому не мешает, как ни странно. :)
[QUOTE]Programmer пишет:
Так что могли бы раскошелиться на периодически простаивающие сервера хотя бы ради нашего удобства работы в ГИС.[/QUOTE]Согласен, но наверно кому-то удобнее раскошеливаться на зарплату программистов субподрядчика, перетаскивающих форму ввода в другой раздел сайта или добавляющих еще одно необязательное поле в форматы обмена после очередной "светлой" идеи. Может у субподрядчика родственники работают или мало ли что еще. И вообще, хорошо если на программистов. (Смайлик: мотание головой вправо-влево с заклееным ртом.) Конечно, было бы любопытно посмотреть на сметы проекта и на реальное их исполнение - на что конкретно уходят эти мульёны, но полагаю официальные источники нам это не прояснят.
[QUOTE]Programmer пишет:
Думаю, что нет, не стоит. Когда - то ГИСовцы говорили нам: "Будете работать шаблонами - упадет в ГИС сервер". А с интеграцией, значит, не упадет? Сомнительно. Поток данных при интеграции будет меньше, но не на много.[/QUOTE]Соглашусь, в том плане, что сервера скорее всего те же, так что кардинального различия ждать не приходится. Про "упадет в ГИС сервер" не совсем понял, что же имелось в виду. Куда оно еще может упасть? Приходящие на ум варианты как раз подходят под эмоциональность темы.
Поток при интеграции может быть и будет не намного меньше, но его структура совсем другая - в шаблонах Эксель много служебной информации, абсолютно не нужной при обработке либо уже известной ГИС (автор, организация, сведения о стилях ячеек, шрифтах, формулах, зависимостях и тд), при этом вытащить ту самую нужную из XLSX не просто (формат сам по себе сжатый) и порой невозможно без считывания служебной информации. В SOAP служебная информация другого рода - ЭЦП, данные организации, минимально необходимые стили, то есть все что нужно для обработки и в удобном для обработки виде (сжатие не предусмотрено или я что-то пропустил?). Это нам неудобно его конструировать, а серверу удобнее получать вот так и если ЭЦП, например, не такая, не по тем параметрам алгоритма, то выдать ошибку. Подробно пока не смотрел есть ли там пакетная загрузка. По одной записи ответ наверняка придет быстрее, чем по шаблону с 300 записями. Ну или сразу будет сбой отправки. Ещё есть небольшая вероятность что "затык" принципиально в том, что все грузят шаблонами (например, жутко неэффективный алгоритм обработки шаблонов) и если все перейдут на интеграцию все внезапно исправится. Но это прояснится только если все перейдут, от перехода одной организации ситуация не изменится. Поэтому много не ожидаю, но и получить "сбой отправки" сразу же будет определенным шагом вперед по сравнению с ожиданием обработки шаблона часами, а то и днями.
[QUOTE]Programmer пишет:
Своими мыслями поделюсь с Вами в личке.[/QUOTE]Окей, поломаем голову вместе.
[QUOTE]IrinRa пишет:
а где слезы, истерики..тема то эмоции![/QUOTE]Может быть, это выглядит сдержанно, но эмоции присутсвуют! Но сообщения и так длинные выходят, эмоции под сокращение попали. :)
[quote:1tl5z5iy]Разница огромна. XLS - лицензионный формат Майкрософт, XLSX - открытый формат[/quote:1tl5z5iy]
Поспешу Вас обрадовать! Частенько получается разархивировать и те же XLS файлы. Например, когда они упакованы в RAR и отправлены по почте, архиватор бывает глючит и открывает их сам вместо запуска Экселя. И что мы там видим? [quote:1tl5z5iy]<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/theme" Target="theme1.xml"/></Relationships>[/quote:1tl5z5iy]Сейчас перепроверил на подручных XLS файлах, так просто разархивировался только 1 файл из 10 попыток и архиватор в нем видит только theme, rels, [ContentTypes] без собственно данных, но при этом Office 2010 при открытии не предупреждает что формат не соответствует расширению, то есть это самый что ни на есть XLS, а не переименованный XLSX. Получается, что формат самого контейнера архива в XLS немного отличается от поддерживаемых архиватором форматов, но это тоже архив. Это подтверждается еще и антивирусами - например, при проверке документов Касперским мелькают в том числе и внутренности архива внутри документа. Фундаментально получается то же самое - XML в архиве. А Вы правда думали, что в Майкрософт что-то внезапно изобрели и формат XLSX такой уж новый? Да даже если на формат опубликовано подробнейшее описание, достать без потерь данные оттуда сложнее чем из архива в котором просто лежит текстовый файл с разделителями или DBF файл. Поясню мысль, подробнейшее описание поможет вам создать файл XLSX который откроется в Экселе, но в обратную сторону это не верно, потому что Майкрософт может как-либо сжульничать, сохранить не по стандарту и на все претензии сказать в нашей программе все прекрасно открывается, ищите изъян в вашем стороннем софте. То есть выходит XLS черный тяжелый ящик, XLSX ящик полегче, но с сюрпризом.

[QUOTE]Дамир пишет:

Страна большая. Ночью по Москве работа тоже идет.[/QUOTE]Речь не о том что работа идет, а скорее о величине этой работы. Простая прикидка: в стране 11 часовых поясов, 11 (поясов)+8(длина рабочего дня)+1(обед)=20 часов. То есть без учета что кто-то работает вечером после полуночи своего пояса (сколько таких?) получается "условный простой" 4 часа в сутки. Мысленно смоделируем поточнее, с учетом распределения населения - максимальная нагрузка естественно будет от европейской части страны (далее - "Москва"), где много населения, много домов и много организаций. По сравнению с этим нагрузка от Сибири и Дальнего Востока не так уж велика. Выходит, что по такой модели "часы пик" - с 8 утра до полудня московского времени (4 часа), следующие часов 6 нагрузка медленно спадает за счет отключения Сибири и Дальнего Востока (начиная с Владивостока), потом спад посильнее - 5 часов "условный простой" и вечерняя работа "Москвы" (1 час на отключение Калининграда и 4 часа из нашего расчета), потом снова начинает подключаться Дальний Восток - но это Магадан с редким населением, Камчатка и где-то там еще пустой часовой пояс, так что этот этап занимает 2 часа (но полагаю в эти часы отключающиеся в "Москве" все же перекрывают подключение Магадана и Камчатки). Именно эти часы (в Москве уже 23 часа), тут рекомендовали для работы - нагрузка минимальна, эначит модель подтверждается действительностью. Далее подключается Владивосток (8 утра во Владивостоке это час ночи в Москве) и следующие 7 часов постепенно добавляются остальные часовые пояса, включая "Москву" и нагрузка выходит на пик. Итого примерная нагрузка - 4 часа пиковая (условно 100%), 6 выше среднего (условно 75%, среднее между 50 и 100), 10 ниже среднего (условно 30%, среднее между 50 и 10), 4 практически минимальная (условно 10%). Берем интеграл нагрузки, полагая единицу нагрузки в 1% = 4*100+6*75+10*30+4*10=1190 ед. Делим на 24 часа = 49,58 ед/час (то есть 49,58% средней загрузки серверов). Другими словами, если ориентировать количество серверов на пиковую нагрузку, то в среднем за сутки чуть более половины серверов будет простаивать. Конечно, модель очень приблизительная, но дает примерное представление о порядке величины простоя - половина времени плюс минус десяток процентов. Причем это не только в ГИС ЖКХ, подобная ситуация должна быть в любой отечественной ФГИС. И не так-то просто понять чем загрузить простаивающие сервера. В случае же ориентирования на 50-60% от пиковой нагрузки простой значительно сокращается, но это имеет смысл только если в часы пик формируется очередь заданий на обработку в период минимальной нагрузки.
[QUOTE]Дамир пишет:

Интеграция через ДБФ-ники была бы наиболее дешевой и быстрой.[/QUOTE]Я тоже склоняюсь к этому варианту. Конечно, там тоже не без косяков при открытии в Экселе (в некоторых файлах Эксель обязательно пытается поменять число и месяц в дате местами - почему-то считает, что заполнено в зарубежном формате и необходимо преобразовать в отечественный), но dbf это вполне определенный открытый формат, в то время как xlsx - "черный ящик", с которого научились выцарапывать часть данных. В этом плане XLSX и XLS невелика разница. Следующий по удобности загрузки после dbf (по моему мнению) вариант - SQL файлы, тупо инструкции insert into xx values (yy), но их просматривать не очень удобно, хотя и реализуемо в том же Экселе, если указать запятые как разделитель и апостроф как ограничитель строк.
Почему продвигали SOAP тоже понятно - все ФГИС в той или иной мере соединены со СМЭВ, та же ГИС ЖКХ от банков данные по СМЭВ принимает. Так что просто было лениво/некогда добавлять еще что-то другое. Лично я ничего не имею против SOAP в целом, но в каком виде он используется в СМЭВ - это просто ужасно. Особенно часть про ЭЦП по ГОСТу, при том что в самом ГОСТе не регламентируется часть параметров, в том числе порядок байтов в результате и одну и ту же хэш-сумму, а значит и ЭЦП можно вычислить минимум 2 способами, не нарушая ГОСТ (еще часть параметров указаны в контейнере закрытого ключа и/или сертификате, но не порядок байтов). Я уже не говорю про нормализацию c14n, выбор части сообщения для подписания и что сообщение еще докучи может быть зашифрованным по ГОСТу. А еще может быть сбой проверки сертификата своего или сертификата сервиса.   dash2 Если бы Минкомсвязь централизовано выложила в бесплатный доступ решение этих технических задач, не связанных с самим заполнением данных, и одинаковых практически у всех и, естественно, уже решенных для шин СМЭВ... интеграцию можно было бы сделать силами Junior программистов и опытных пользователей.  qws
Примерная идея как это сделать: в описании сервисов обязательно есть примеры запросов XML, сделать шаблон XML вручную при смене версии сервиса (скопировать подходящий пример, заменив значения на что-то вроде $VALUE1$, $VALUE2$ и тд), потом несложным VBS скриптом $VALUE1$ заменить на свои данные (взятые из того же Экселя). Вопрос в реализации дальнейших шагов: подписания (шифрования), совмещения в SOAP и отправки, а еще требования сохранить отправленное для истории и обработать ответ. То есть фактически многим нужна только "платформа" с возможностью настройки и примеры настройки под конкретные задачи (указание номера сервисов и имени файла шаблона), нет необходимости в отдельных программистах для интеграции - опытные пользователи вполне справятся с копированием шаблона и запуском скрипта. На настоящий момент такие "платформы" продаются (и даже с российской БД по требованиям импортозамещения), но продают тоже умные люди, которые будут настаивать, что настроить смогут только они и предлагать кучу дополнительных возможностей за дополнительную же плату. Сейчас сам ломаю голову - может попробовать купить голую "платформу" и потихоньку "допилить" или все же подождать пока форматы утрясутся.
Вопрос про канал связи тоже не слишком актуален - теоретически, приложив ручки, также можно обеспечить шифрование канала практически любым имеющимся у вас криптопровайдером ГОСТ (для КриптоПро есть специальная версия бесплатной программы Stunnel на сайте КриптоПро), другое дело, что на региональных узлах СМЭВ стоит VipNet и операторы РСМЭВ будут убеждать купить именно его плюс еще один сертификат КП ЭП (иначе им тоже придется приложить ручки).
Остается бюрократический вопрос про получение доступов, регистрацию ИС, прохождение тестирований и тд и тп. В целом, можно набраться терпения и интегрироваться, но вопрос стоит ли игра свеч и будет ли по интеграции работать лучше чем сейчас через сайт.

Ну, если один программист делает одну кнопочку, другой другую, потом пытаются все совместить без единого плана, то порядка и не будет. Еще хуже если план внезапно меняется - мешается в кучу сделанное по старому плану, сделаное по новому и не сделанное вообще.
Мне почему-то кажется, что дело не только в толковости программистов, а и в том, что жмутся сделать нормальное наспределение нагрузки по серверам. Вообще раз плюнуть сделать несколько серверов обслуживающих веб-интерфейс и еще один (хорошо пусть 2-3 про запас), который будет считать сколько клиентов на каждом и перенаправлять новые соединения на свободные сервера. То есть после входа попадаете на общий координирующий, он перекидывает на свободный сервер (с минимальным числом пользователей), с которым дальше и работаете. Учитывая, что входов не так уж много (сколько там организаций в ГИС зарегано?), а перекидывание занимает доли секунды, справится даже не слишком мощный сервак.
Ещё можно не загружать данные параллельно, а ставить загрузки данных в очередь и показывать текущий номер вашей загрузки в очереди или текущее сумарное количество записей в предыдущих файлах в очереди до вашей загрузки. Это позволило бы еще и отслеживать нагрузку именно загрузок на серваки и тоже ее перераспределять. Самое простое - сервак, закончивший обработку одного файла, берет из очереди следующий не взятый в обработку. Составив простую пропорцию (класс пятый наверно?) можно вычислить количество необходимых серваков. Сравните, скажем с загрузкой видео - если нужно скачать 50 видео примерно одного размера: логичнее скачивать по одному по очереди, а не все разом. Но похоже кого-то жаба задушит если количество серваков для мгновенной обработки файлов в "часы пик" будут простаивать ночью. Это идеи навскидку, лежат на поверхности, программисты не могут их не понимать.
А ещё я не понимаю, почему вообще подгрузка идет файлами Эксель, с них как бы под патриотичными вариантами Linux сложно что-либо достать (не буду врать, я не пробовал, но формат Экселя закрытый и ммм, непростой). А если вдруг серваки с Windows, то неудивительно, что все так работает.. Может там очередное чудесное обновление пришло и ставится (обновления то по новой схеме каждую неделю практически), пока мы за данные переживаем.

[quote:3t9na56b]Как-то вы все свалили в одну кучу))[/quote:3t9na56b]Так оно и есть, непонятно где границу провести))
[quote:3t9na56b]Смотрите, во-первых, нужен ключ КЭП (квалифицированной электронной подписи), это отдельный вид ключа.
Во-вторых, под этим ключом в ЕСИА вы сами даете права доступа своим сотрудникам.[/quote:3t9na56b]Признаю, написал не строго по определениям) Но и Вы ведь в определениях путаетесь)) Зачем Вы очередной раз рассказываете про регистрацию и ответственность (я писал выше что вопрос про будущее и не про руководителя), да еще и выводите отдельный вид ключа (полагаю, что сейчас уже мало УЦ выдающих неквалифицированные сертификаты ГОСТ). Мы конечно друг друга поняли, но расставим точки над i, терминология про ГОСТ-2001 такая: 1) есть контейнер закрытого ключа в котором хранится закрытый ключ, 2) есть собственно сам закрытый ключ (вообще это произвольный набор байтов, главное чтобы для него существовал парный набор байтов - открытый ключ), 3) есть носитель (флешка или токен), где хранится контейнер закрытого ключа, 4) есть открытый ключ (он же ключ проверки ЭП пользователя), соответствующий (парный) закрытому ключу, 5) есть сертификат, выданный аккредитованным центром, в нем указан открытый ключ и он заверен ЭП УЦ, 6) есть криптопровайдер - программа или "железка", выполняющая криптографические операции, 7) есть электронная (цифровая) подпись - ЭП - зашифрованная закрытым ключом хэш-сумма подписывемых данных плюс сертификат(ы) плюс дополнительные данные (отметка времени подписания, например). То есть для каждого документа цифровая подпись разная. Если выпустить несколько сертификатов с одним и тем же открытым ключом, при проверке подписи будет использоваться сертификат включенный в саму конкретную подпись конкретного документа. Возможен еще вариант когда сертификат не включается в цифровую подпись.
Слово квалифицированный в первую очередь относится к сертификату (полностью - квалифицированный сертификат ключа проверки ЭП пользователя), а именно такой сертификат должен дополнительно содержать определенный набор сведений для идентификации подписавшего, о средствах криптографии УЦ и владельца подписи (В позапрошлом году меняли неквалифицированный сертификат на квалифицированный сертификат - так было почти все 1 в 1, добавились снилс и сведения о версии криптопро нашей и криптопро УЦ). Цифровая подпись наверняка будет квалифицированной, только если содержит в составе квалифицированный сертификат. Если на один открытый ключ выпущено 2 сертификата - неквалифицированный и квалифицированный, а в цифровую ни один из них не включен, то в зависимости от того, какой сертификат доступен проверяющему она может пройти проверку как квалифицированная или не пройти. Поэтому не рекомендется выпускать второй сертификат на тот же открытый ключ и рекомендуется включать сертификат в подпись. Ключ (ни открытый, ни закрытый, ни даже токен) не бывает квалифицированным, это разговор "по-простому". Ключ КЭП ничем не отличается от ключа не-КЭП, отличается именно сертификат КЭП от сертификата не-КЭП. Токен бывает сертифицированным (при наличии заключения ФСБ и ФСТЭК), а ЭП усиленной (если в ней указано удостоверенное время подписи).
Точно так же как по-простому говорим "вход по ЭЦП". На сайт мы входим конечно же по сертификату, при этом мы посылаем серверу сертификат плюс часть служебной информации для установления соединения шифруется закрытым ключом, сервер проверяет сертификат, извлекает из сертификата открытый ключ и расшифровывает служебную информацию. Если сертификат прошел проверку и служебная информация верна - нас допускают. Простыми словами все так же говорим "вход по ЭЦП".Извините за отступление, но договориться о терминологии тоже важно. Честно, меня самого медленно убивает такая терминология когда все корректно пишу.

[quote:3t9na56b]Это развод, похоже :) обычной подписи достаточно.[/quote:3t9na56b]Посмотрите выше, "обычная" как раз и окажется незаметно "квалифицированной" ;) Потому что сертификат: 1) ГОСТ-2001, 2)на организацию, 3) содержит снилс директора, 4) содержит версию вашего криптопровайдера.
[quote:3t9na56b]Всё делается с логином-паролем. Подпись нужна только для одного - принятия Пользовательского соглашения организации.[/quote:3t9na56b]В самой ГИС ЖКХ - действительно так, по крайней мере пока, почему я и спрашиваю что дальше будет. А вот в ЕСИА помнится выскакивало при некоторых операциях (кажется при включении сотрудника в группу) сообщение "необходимо войти с помощью цифровых средств" - например, я с правами Администратора в ЕСИА, но у меня нет ЭЦП и меня частенько припечатывает этим сообщением, когда я забываю что под своим аккаунтом, приходится перезаходить с ЭП руководителя.

[quote:30zkukrc]Вообще ЭЦП нужна для подтверждения подлинности документов aka подпись. А ваши сотрудники просто вносят туда информацию.[/quote:30zkukrc] Логично. Но если посмотреть так, то появляется еще больше вопросов. В таком случае мне несколько непонятно, где граница между "документом" и информацией. Если мы что-то вносим, то наверно и несем за это какую-то ответственность? Хотя бы ответственность, что не взяли данные с потолка и у нас на руках есть документ (тут конечно обсуждали историю про ретивый горгаз, но хочется верить в лучшее). Ту же информацию о домах и помещениях разве не берем из [B]документов[/B]? Пока, как я понимаю, сведения из Росреестра идут с подписью и это как бы заверяет введенную информацию.
Но оставим разграничение информации и документов, возьмем ежемесячную информацию о начислениях и поступлении денег на лицевой счет, эти данные никто другой не заверит. В схожих условиях банки отправляют информацию о принятии платежа в ГИС ЖКХ через СМЭВ, там нельзя отправить [B]в принципе[/B] без подписи ИС. Некоторые коллеги тоже используют схему интеграции и подпись ИС. А еще есть постановление правительства, что логин и пароль Гослуслуг считается как простая электронная подпись (ПЭП). На ГИС ЖКХ это тоже распространяется? То есть одни подпишут информацию полноценной ЭЦП ИС, а другие подгрузят из Экселя, обойдутся неявной ПЭП и все это будет считаться равносильным? Определенная логика конечно просматривается, но вроде как говорили постановление о ПЭП не будет действовать вечно и были планы выдавать в ЦО гражданам ЭЦП бесплатно вместо логина-пароля. Тогда наверно и ГИС ЖКХ должно будет перейти с ПЭП на ЭЦП? Или нет, будем входить на ЕСИА по ЭЦП, а информацию все также не подписывать явным образом? Непонятно, можно повернуть и так и этак.

[quote:3vsw1t28]Получается обратная логика - если пользователь, что то заносит - у него есть ЭЦП и каких то дополнительных ЭЦП не надо.[/quote:3vsw1t28]Что то вы меня совсем запутали суперпользователями и суперскими админами ;) Как бы про регистрацию мне ясно, в конце прошлого года проходили. Переформулирую вопрос более развернуто.
Сейчас у нас - 1 эцп(эцп организации, права суперского админа, но не уполномоченного лица) у руководителя, 1 эцп у начальника отдела, ответственного за организацию заполнения (эцп физического лица с дополнительно указанной организацией, делали такую эцп для другой отчетности, но раз есть решили использовать, наделили правами админа с назначением прав другим и уполномоченного лица) и еще 1-2 сотрудника без эцп подключили. сотрудники "за 50", на первый взгляд электронной почтой пользуются, номер мобильного наизусть называют, документы под рукой, но пока регистрировал их, думал сойду с ума, не знаю чего они в ближайшем ЦО (центре обслуживания) сказали, но вместо того чтобы просто подтвердить учетку, которую я им зарегистрировал до стандартного уровня, им в ЦО зарегистрировали вторую (уже сразу подтвержденную), сказали первую удалить и толком не объяснили куда пароль от второй скинули, зато даже записали на бумажке что вместо логина использовать снилс. С одной стороны, хочется высказать ЦО, что я думаю об их услуге (во второй учетке почта и телефон еще не подтверждены и восстановить пароль можно только опять же в ЦО), с другой стороны, формально к работе ЦО не придерешься, дело в непонимании регистрирующегося куда ему пароль скинули, с третьей, ну как-то несерьезно за ручку водить в ЦО. Сейчас эти сотрудники чего-то заполняют, а значит и без ЭЦП у них что-то получается (честно, мне даже страшно пойти глянуть). Далее, как я понимаю, ожидается, что граждане будут приходить по поводу начислений, которые увидят в ГИС ЖКХ, видимо придется подключать еще сотрудниц, которые квитуют/разруливают начисления непосредственно общаясь с гражданами. И среди них тоже есть пара "бабулек", чую они не зарегистрированы и повторение истории приближается.

Так что, мой вопрос не про сейчас, а скорее про будущее - не светит ли после ввода всех частей ГИС ЖКХ подписывать каждую мелочь? В других федеральных ГИС видел, никакие документы там не подгрузить без ЭЦП. Мне кажется странно, что в ГИС ЖКХ этого всё ещё не требуют, опасаюсь что будут в ближайшем будущем (ну или не таком уж ближайшем). Может ли кто подтвердить или развеять опасения? Говорили ли идеологи ГИС про это что-нибудь?

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

[quote:2llww2g1]при входе выскакивает только запрос на разрешение действий. Все инструкции как это подключить есть в ПДФ.[/quote:2llww2g1]Спасибо. По оформлению окна похоже, что у меня другая версия Windows. Собственно, именно по этой инструкции я и делал, плюс по инструкции для сайта налоговой, однако у меня запрос на разрешение действий не появляется. Разрешение появляется до входа на ЕСИА или после? Если ДО, то видимо просто у меня безопасность выставлена ниже (может быть именно настройка "Доступ к данным за пределами домена: Включить"). Главное, как я понял сообщения про ФСБ у Вас не показывается?
[quote:2llww2g1]А в Яндексе все равно ругается на шифрование.[/quote:2llww2g1]Да было что-то такое... Opera 12.17 обновил до 12.18 и настроил чтобы представлялась Яндекс.Браузером :D В ИнтернетЭксплорере после всех манипуляций с сертификатами и обновлений Windows доверяет Яндексу, какой именно сертификат это исправил навскидку не вспомню, ругается только на SilverLight.
[quote:2llww2g1]Понял, что победить это - дело принципа.Интересно,что на это скажет техподдержка?[/quote:2llww2g1]Да, принципа, обидно что у кого-то работает, а я чем хуже? :D Плюс чтоб меньше нажимать при входе. Плюс безопасность - об этом ниже. Техподдержка.. Это смотря чья техподдержка.. В нашей организации я и есть техподдержка и безопасность. В техподдержку ГИС ЖКХ я конечно напишу, но что-то подозреваю они пришлют ссылку на инструкцию. Планирую, если не выйдет, дозвонится до них темной субботней ночью, даром что ли про круглосуточную и без выходных работу спамят каждую неделю.
[quote:2llww2g1]Тем более,все эти криптопровайдеры и прочее не бесплатно.[/quote:2llww2g1]Согласен, если используете только ГИС, так оно и есть. Но иногда это наоборот экономит деньги и время - например, ряд документов в электронном виде в случае подписи ЭЦП (то же заявление на изменения в ЕГРЮЛ) не нужно заверять нотариально и отправлять обычной почтой.

[SIZE=85px][COLOR=greenpt]Отправлено спустя 23 минуты 26 секунды:[/COLOR][/SIZE]
[quote:2llww2g1]Если системой предоставлена возможность передачи данных без шифрования, то стоит ли ломать мозг над этим.[/quote:2llww2g1]Тут наверно нужно уточнить, про [B][U]без шифрования[/U][/B] никто не говорит - шифрование есть, просто не по российскому алгоритму и относительно хлипкое - 128 бит (замечу, что у текущих криптопровайдеров ГОСТ 256 и 512 бит в зависимости от режима). И к этому весьма рискованно относиться легкомысленно, наверно просто не представляете насколько хрупкое доверие в Интернете.
Вкратце.. Если ключ сервера подберут, то теоретически проблемы могут быть гораздо серьезнее, например, станет возможно подменить сайт. Маловероятно конечно, что подделают такую махину как ГИС, но наверно достаточно подделать вход и несколько часто используемых страниц. Сайты социальных сетей так подменяют сплошь и рядом, в том числе есть вирусы специально изменяющие файл hosts или данные ответа DNS. В этом случае только отсутствие сертификата помогает отличить подделку от каприза владельцев социальной сети, решивших в очередной поменять кнопки справа и кнопки слева.
В случае подмены ГИС/ЕСИА Вам может грозить, не только то что Вы собственными руками отправите пароль на Госуслуги совершенно посторонним людям и тем самым дадите им доступ ко всем персональным и служебным данным. Если из-за этого через Ваш аккаунт утекут персональные данные клиентов, думаете, что сможете свалить ответственность на ГИС? Если от Вашего имени удалят данные в ГИС которые Вы внесли, кому выпишут штраф? Или еще замечательнее с тем же результатом - внесете данные на совершенно левый сайт-подделку, там бодро отработают ваш шаблон в [B][U]свою[/U][/B] базу, покажут Вам что все окей, а в ГИС будет пустая страничка. Так как к ГИС в этом случае нет подключения от злоумышленников, то служба безопасности ГИС и ухом не поведет, а Вам будет [B][U]очень[/U][/B] сложно оправдаться. Да даже если и поведет и отзовет скомпрометированный сертификат, после установки корневых сертификатов УЦ, обновляете ли вы списки отзыва регулярно или оставляете это на усмотрение браузера?
В общем, некоторая степень паранойи в этом вопросе не помешает - или у Вас нет завистников, конкурентов, недоброжелателей? Фактически, наиболее безопасно передавать данные не через Интернет, а интегрировавшись по каналу VipNet. Но, наверно все согласятся, что это необоснованно дорого вообще и в особенности из-за системы в которую данные вносят чтобы не было штрафов, а не по реальной потребности. Настолько дорого и долго, что в сравнении КриптоПро и ЭЦП уже кажутся почти что бесплатными и мгновенно изготовлямыми. Поэтому, разумный компромисс - правильная настройка криптопровайдера, который [B][U]уже[/U][/B] купили (без ЭЦП руководителя организацию не зарегистрируешь -да, раньше органы госвласти могли регистрироваться через Минкомсвязь, сейчас эту форму заявки удалили - всё по ЭЦП). А чтобы меньше ломать голову - как раз есть форум для обмена опытом.

[quote:2g9yxsn3]Сообщение системы безопасности ГИС ЖКХ
Ваш браузер не поддерживает протокол HTTPS с шифрованием по ГОСТ Р 34.10-2001. Для обеспечения поддержки криптографических стандартов ГОСТ установите один из сертифицированных ФСБ России криптопровайдеров. Затем, добавьте сертификат УЦ ГУЦв список доверенных корневых центров сертификации в соответствии с эксплуатационной документацией на используемый криптопровайдер. После чего, при помощи поддерживаемого установленным криптопровайдером браузера, Вы сможете получить доступ к порталу ГИС ЖКХ по защищенному каналу связи.
Вы можете продолжить работу с ГИС ЖКХ, используя несертифицированные ФСБ России средства криптографической защиты информации.
Я согласен продолжить работу по незащищенным каналам связи[/quote:2g9yxsn3]
[quote:2g9yxsn3]После согласия можно продолжать, но что-то мне это не нравится[/quote:2g9yxsn3]
Сообщение по несоответсвие шифрования ГОСТу кто-нибудь "победил"? Пока ставим галочку и работаем, НО.. На сайт налоговой по приему заявлений о изменении ЕГРЮЛ с того же компьютера заходит по ГОСТу, при этом спрашивает сертификат пользователя. В налоговую заходит с Интернет Эксплорера, с КриптоПро Фокса тоже доходит до запроса сертификата, с OpenSSL подключается и тоже просит сертификаты.
Дальше не проверял так как надо сертификат в криптофокс импортировать или в формат OpenSSL ключи и сертификат переводить - это отдельная песня, так как КриптоПро штатными средствами в совместимые форматы не сохраняет. Точнее сохраняет, но так "замечательно" что OpenSSL не может прочитать файл, в обратную сторону тоже самое. Другая российская компания сделала утилиту для экспорта ключа и сертификата, но с определенной версии КриптоПро утилита тоже не работает, так что остается метод почти хакерский - извлечение из закрытого контейнера.
Вернемся к ГИС. Пробовал с разных браузеров (и ИЕ как в инструкции и прочие), прописывал в доверенные узлы (gosuslugi.ru и cо * и c esia и c dom, и http и https), ставил сертификат ГУЦ (уже кстати установлен был), обновил Windows и ИЕ до последней версии (и патч к ней), включил по инструкции в ИЕ все ActiveX, TLS, доступ к данным за пределами домена, отключил блокирование всплывающих окон и кукисов. Пробовал входить по паролю, пробовал входить по ЭЦП - все тоже сообщение. Windows 7, КриптоПро 3.6 R3. Конкретно R3 в инструкции нет, на других компьютерах есть и R2 (на налоговую с R2 не заходит) и R4, результат тот же.

С OpenSSL еще интереснее - если указываю подключение по ГОСТ 2001 (без разницы по встроенной реализации или через КриптоПро), то dom.gosuslugi.ru отклоняет соединение (ошибка 40), даже не спрашивая сертификата. Поискал в интернете, в числе множества возможных причин - отсутствие сертификата запрашиваемого шифрования на сервере (!). В связи с этим у меня сомнение, что с ГИС ЖКХ по адресу dom.gosuslugi.ru в принципе возможно работать по ГОСТ 2001. Или соединение должно установиться на ЕСИА и плавно переехать на ГИС ЖКХ? Отловить адрес с которого перенаправляет на сообщение о несоответствии шифрования тоже не получилось, прям хоть подключайся по старому модему на 33600, чтобы увидеть...

В итоге, вопрос: если кто избавился от сообщения, то расскажите пожалуйста что ещё сделали? спрашивает ли сертификат пользователя? по какому адресу в итоге работает закрытая часть? какой сертификат сервера при шифровании по ГОСТ 2001?
Или всё-таки это "особое ограничение пробной версии" - сообщение повесили, ничего не работает и на этом пока все? Как в анекдоте "как программисты дом строили". (Теперь-то мне ясно, что это dom.gosuslugi.ru).

Честно говоря, у меня похожий вопрос, только немного с другой стороны. ЭЦП руководителя у нас используется в бухгалтерской и статистической отчетности, так что продлеваем ежегодно, но при этом ограничиваем доступ к этой ЭЦП. Я рабитаю как "сисадмин" и у меня доступ есть, как начинается отчетная пора, ответственные за отчеты бегут ко мне - подписывай.
Поэтому вопрос по необходимости ЭЦП для других сотрудников. В ГИС ЖКХ они зарегистрировались, войдя в ЕСИА по паролю, начали заносить данные. Смотрю ГИС все допиливают, добавляют новые данные. Потом случайно не потребуется подписать какие-нибудь данные с помощью ЭЦП? Про это что-нибудь известно?

[QUOTE]portal-gkh пишет:
Пробовал такой "рецепт" много раз. Не помогает.....
[/QUOTE]
Жаль, видимо на грабли наложилось что-то ещё. Однако, ясно, что приглашением нового директора прицеплять нежелательно. Даже если перегистрация через ЭЦП не помогает с ГИС ЖКХ, возможно поможет в какой-нибудь другой ИС, их с каждым днем все больше.

Есть идея почему нового директора ГИС ЖКХ не считает "самым главным", может быть поможет без обращения в ТП. Столкнулся с подобным в ЕСИА при получении услуги "Установление ОКВЭД" (получить услугу от имени организации может только "самый главный" и руководителя ЕСИА таким не считало), но поскольку ГИС ЖКХ берет права пользователей из групп ЕСИА, очень похоже что те же грабли перекочевали в ГИС ЖКХ. Если все так, то техподдержка ГИС ЖКХ с этим ничего не сделает - это свойство ЕСИА.  2we
Так вот, хотя этого в большинстве руководств по регистрации не пишут, ЕСИА разделяет работников организации на руководителей и рядовых сотрудников. При [B]отправке приглашения[/B] физическому лицу с подтвержденной записью он добавляется в категорию [U]сотрудников[/U], а при [B]регистрации организации[/B] из кабинета физического лица по ЭЦП он добавляется в категорию [U]руководителей[/U]. Казалось бы какая разница между сотрудником-администратором и руководителем? Поэкспериментировал. Руководитель может отправлять заявки на гослуслуги, может [B]назначать права[/B] пользователям даже если [B]сам не включен[/B] в группу Администраторов ЕСИА.
Получается когда вы приглашаете нового директора, он не руководитель с точки зрения ЕСИА, а рядовой сотрудник! И соответственно ему тоже нужно назначать права от старого директора, как рядовому сотруднику. Даже если вы ему назначите все права, он останется сотрудником. Возможно с этим же связано, что техподдержка говорит о не принятом соглашении - сотрудники его принимают только для себя, а руководитель от имени всей организации. Но если он не руководитель с точки зрения системы, то от имени организации соглашение не принято!
В маленькой инструкции, где это разжевывается (выпросил у техподдержки портала госуслуг) есть и "рецепт" смены руководителя: 1) обновить данные на нового директора организации в ЕГРЮЛ, 2) получить ЭЦП на нового директора, 3) зайти в кабинет физического лица по эцп, 4) нажать добавить организацию, 5) предъявить ЭЦП, выйдет сообщение что организация уже есть, но данные нового директора проверятся по ЕГРЮЛ (что он указан как лицо имеющее право действовать без доверенности) и он добавится в категорию руководителей.
6) После этого (необязательно) можно отсоединить старого директора от организации. Если он продолжает работать, но не как руководитель, а как рядовой сотрудник, то отсоединить и пригласить снова. В случае ГИС ЖКХ, я бы проверил что новый получил статус "самого главного" (хотя бы по тем же незатененным галочкам прав в ГИС ЖКХ, может занять некоторое время) перед тем как удалять старого директора.