Ключевое слово в защите информации
ключевое слово
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

17 Страницы«<910111213>»
Опции
К последнему сообщению К первому непрочитанному
Offline Юрий  
#101 Оставлено : 12 декабря 2014 г. 11:07:32(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Sergey M. Murugov Перейти к цитате
Автор: turik Перейти к цитате
Автор: Sergey M. Murugov Перейти к цитате

Искуственность заключается в том, что практической нужды иметь бусы на шее из сертификатов различного назначения нет ни какой, это искуственно созданное явление, тянущееся из 1-ФЗ, что называется неприятное "наследие прошлого". Простая аналогия - паспорт один с образцом моей подписи, почему в электричестве нужно для каждного отдельного бизнес процесса придумывать новую подпись идентифицирующую одного и того же субъекта. Важное : сертификат - это просто идентификатор + инструмент для аутентификации. Авторизация - это прерогатива прикладной системы, а не глобальной PKI РФ. Для целей авторизации придумано полно прикладных специализированных инструментов, инфраструктур и протоколов, не к чему и даже вредно все валить внутрь идентификатора.

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

Дело в том, что паспорт - это почти единственный универсальный документ удостоверяющий личность во всех правоотношениях. Всё остальное - пропуск, права ... это суррогаты накрученные поверх паспорта (ни права ни пропуск вам не дадут пока вы не покажите паспорт). Если вспомнить пропуск, то его смысл несколько глубже - это уже система авторизации, т.е. через всякие штампики и записи, определяется роль субъекта по доступу к различным объектам предприятия, почему эти самолетики не рисовать бы сразу на пустых страницах паспорта? Себе такой вопрос не задавали? А потому что в данном случае нормативно отделены мухи от котлет, есть требования к форме удостоверения личности (идентификатору)паспорту и есть требования к системе авторизации, т.е. виду и способу заполнения пропуска. Так что отдельное существование паспорта и пропуска вполне себе оправданное. Буквальная аналогия этого есть и вокруг PKI - это сертификаты открытого ключа и атрибутные сертификаты, более подробно можно почитать в вики про инфраструктуру управления привилегиями, там тоже есть пример про пропуск между прочим.
Хотелки всяких прикладных ИС получать сертификат в определённом месте - это по идее только до поры до времени пока не заработает единое пространство обращения квалифицированных сертификатов-подписей.

Насчет пропуска. Пропуск на заводе применялся исключительно только потому, что охране крайне затруднительно каждый раз искать по паспорту данного гражданина в списках работника завода. В случае же с ИС поиск по единственному сертификату будет происходить практически мгновенно. Так что городить огород с дополнительными сертификатами в случае с пропусками тоже нет смысла.
С уважением,
Юрий Строжевский
Offline Sergey M. Murugov  
#102 Оставлено : 12 декабря 2014 г. 11:32:19(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Если я вас правильно понял, то вы предлагаете для каждой ИС выпускать свой собственный сертификат открытого ключа. Если это то что вы написали, то я с вами не соглашусь. Посудите сами, много практичнее и дешевле выпускать пропуска и иные вторичные документы когда процедура идентификации уже выполнена ранее кем то кому можно доверять. Сама по себе процедура идентификации это очень сложная процедура. Поэтому в бумажном мире все разделили на части, пропуск вторичен и его выдача опирается на уже пройденную идентификацию паспортным столом МВД. Не вижу причин почему от этого принципа надо отказываться в электричестве. А вы предлагаете, для выпуска пропуска заново проходить процедуру идентификации - это просто неоправданно экономически.
Offline Юрий  
#103 Оставлено : 12 декабря 2014 г. 11:40:07(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Sergey M. Murugov Перейти к цитате
Если я вас правильно понял, то вы предлагаете для каждой ИС выпускать свой собственный сертификат открытого ключа. Если это то что вы написали, то я с вами не соглашусь. Посудите сами, много практичнее и дешевле выпускать пропуска и иные вторичные документы когда процедура идентификации уже выполнена ранее кем то кому можно доверять. Сама по себе процедура идентификации это очень сложная процедура. Поэтому в бумажном мире все разделили на части, пропуск вторичен и его выдача опирается на уже пройденную идентификацию паспортным столом МВД. Не вижу причин почему от этого принципа надо отказываться в электричестве. А вы предлагаете, для выпуска пропуска заново проходить процедуру идентификации - это просто неоправданно экономически.

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

Отредактировано пользователем 12 декабря 2014 г. 11:40:47(UTC)  | Причина: Не указана

С уважением,
Юрий Строжевский
Offline Sergey M. Murugov  
#104 Оставлено : 12 декабря 2014 г. 11:43:19(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Автор: Юрий Перейти к цитате
... В свою очередь публичный ключ владельца сертификата может быть использован по абсолютно произвольному поводу: подпись файлов, шифрование файлов и даже (!) авторизации на сайте. Говорить, что сертификат должен быть использован только для идентификации это всё-равно как говорить, что паспорт гражданина нужен только для сличения фотографии с оригиналом. У паспорта множество другой информации и применений. Точно так же как и для сертификата.

Не совсем верное утверждение. Например в ЕС, в Казахстане, Беларуси и т.д. разнесены в стороны задачи шифрования-доступа и задачи ЭЦП (неотрекаемости). Объяснений тому множество, самое пожалуй наглядное - это то что требования к ключам шифрования и ЭЦП различны, например, для шифрования правилом хорошего тона является рекавери ключей (у Keon RSA даже есть специально для этого продукт самостоятельный), а вот делать копии ключей ЭЦП моветон.
Offline Sergey M. Murugov  
#105 Оставлено : 12 декабря 2014 г. 11:44:18(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Автор: Юрий Перейти к цитате
Автор: Sergey M. Murugov Перейти к цитате
Если я вас правильно понял, то вы предлагаете для каждой ИС выпускать свой собственный сертификат открытого ключа. Если это то что вы написали, то я с вами не соглашусь. Посудите сами, много практичнее и дешевле выпускать пропуска и иные вторичные документы когда процедура идентификации уже выполнена ранее кем то кому можно доверять. Сама по себе процедура идентификации это очень сложная процедура. Поэтому в бумажном мире все разделили на части, пропуск вторичен и его выдача опирается на уже пройденную идентификацию паспортным столом МВД. Не вижу причин почему от этого принципа надо отказываться в электричестве. А вы предлагаете, для выпуска пропуска заново проходить процедуру идентификации - это просто неоправданно экономически.

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


Извините, значит вас не понял, в таком случае я совершенно с вами согласен.
Offline Alexey I  
#106 Оставлено : 12 декабря 2014 г. 11:48:40(UTC)
Alexey I

Статус: Активный участник

Группы: Участники
Зарегистрирован: 29.04.2009(UTC)
Сообщений: 125
Мужчина

Сказал «Спасибо»: 3 раз
Поблагодарили: 28 раз в 20 постах
Автор: Юрий Перейти к цитате
Как видно, все мало-мальские доводы в пользу большого количества УЦ сводятся к "мы лучше обслуживаем клиентов на местах". Отлично, но вот только зачем именно УЦ должен обслуживать клиентов на местах? С этим справится команда центра регистрации.

Поищите в проекте об изменениях в 63-ФЗ
Цитата:
6. Аккредитованный удостоверяющий центр не вправе наделять третьих лиц полномочиями по созданию квалифицированных сертификатов ключей проверки электронной подписи от имени аккредитованного удостоверяющего центра.

Третьи (доверенные) лица смогут только вручать сертификаты УЦ, т.е. запросы на изготовление - на строне третьих лиц, проверка запросов и создание СКП - в УЦ. У многих поменяется схема работы.

Автор: x020 Перейти к цитате
Где имеено идет ссылка на то, что OID больше не будет?

Цитата:
"21. Операторы государственных и муниципальных информационных систем, а также информационных систем, использование которых предусмотрено нормативными правовыми актами, или информационных систем общего пользования не вправе требовать наличия в квалифицированном сертификате информации, ограничивающей его применение в иных информационных системах.";

Странно конечно звучит - получается, что требовать ограничений для "своей" ИС можно. Т.е. для использования с в ИС "Финансы" владелец ИС может потребовать - "СКП должен иметь расширение с OID 1.2.3.4" - но это не ограничение, а разрешение, причем не ограничивающее использование СКП дл других ИС - такая схема и сейчас работает и не мешает, например Росреестру, требовать определенных OID.
И ещё ограничения могут быть указаны самим пользователем (учитывая квалификацию пользователей - сомнительно)
Цитата:
"2. При обращении в аккредитованный удостоверяющий центр заявитель указывает на ограничения использования квалифицированного сертификата (если такие ограничения им устанавливаются) и представляет..."

Сейчас на практике применяется схема, когда OID указывает на сферы применения (а не ограничение) использования СКП в конкретной ИС (или нескольких).
Как реализовать ограничение, если пользователю сертификат нужен только для какой-то одной ИС (например только для СЭД, или СЭД + медстатистика)?
Пользователь должен в заявке указать ограничения, что в других ИС этот СКП не должен применяться и перечислить все OID иных ИС?

Автор: Zloy Strelok Перейти к цитате
Получается аккредитованные уц будут подчиненными головному? и свои корневые будут получать в головном?

Имхо, останется также, как сейчас - кросс сертификат.
Тут другой важный момент:
Цитата:
"После получения свидетельства об аккредитации аккредитованный удостоверяющий центр обязан осуществить присоединение информационной системы, обеспечивающей реализацию функций аккредитованного удостоверяющего центра, к информационно- технологической и коммуникационной инфраструктуре в порядке, установление которого предусмотрено частью 4 статьи 19 Федерального закона от 27 июля 2010 года № 210-ФЗ "Об организации предоставления государственных и муниципальных услуг" (далее соответственно - инфраструктура, присоединение аккредитованного удостоверяющего центра к инфраструктуре). После присоединения аккредитованного удостоверяющего центра к инфраструктуре уполномоченный федеральный орган выдает аккредитованному удостоверяющему центру квалифицированный сертификат, созданный с использованием средств головного удостоверяющего центра.

Обратите внимание - УЦ недостаточно будет зарегистрироваться на госуслугах как юрлицу, нужно будет регистрироовать ИС в ЕСИА, это совсем другой процесс и сейчас он совсем не простой. Сервисов интеграции средств УЦ (ЦР или АРМ админа) и ЕСИА, насколько я знаю, на сегодняшний день нет. Возможно КриптоПро, Инфотекс, совместно с МКС и другими разработчиками (Ланит и т.д.), что-то разработают для этого, иначе каждому УЦ придется серьезно потратиться на внедрение таких сервисов.

Отредактировано пользователем 12 декабря 2014 г. 11:51:41(UTC)  | Причина: Не указана

Offline Юрий  
#107 Оставлено : 12 декабря 2014 г. 11:49:53(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Sergey M. Murugov Перейти к цитате
Автор: Юрий Перейти к цитате
... В свою очередь публичный ключ владельца сертификата может быть использован по абсолютно произвольному поводу: подпись файлов, шифрование файлов и даже (!) авторизации на сайте. Говорить, что сертификат должен быть использован только для идентификации это всё-равно как говорить, что паспорт гражданина нужен только для сличения фотографии с оригиналом. У паспорта множество другой информации и применений. Точно так же как и для сертификата.

Не совсем верное утверждение. Например в ЕС, в Казахстане, Беларуси и т.д. разнесены в стороны задачи шифрования-доступа и задачи ЭЦП (неотрекаемости). Объяснений тому множество, самое пожалуй наглядное - это то что требования к ключам шифрования и ЭЦП различны, например, для шифрования правилом хорошего тона является рекавери ключей (у Keon RSA даже есть специально для этого продукт самостоятельный), а вот делать копии ключей ЭЦП моветон.

Принципиального отличий в операциях шифрования и формирования подписи нет: математически они практически идентичны. Ограничения могут быть только искусственными. Изначально публичный ключ может быть применён везде.
С уважением,
Юрий Строжевский
Offline Юрий  
#108 Оставлено : 12 декабря 2014 г. 11:53:37(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Alexey I Перейти к цитате

Цитата:
6. Аккредитованный удостоверяющий центр не вправе наделять третьих лиц полномочиями по созданию квалифицированных сертификатов ключей проверки электронной подписи от имени аккредитованного удостоверяющего центра.

Третьи (доверенные) лица смогут только вручать сертификаты УЦ, т.е. запросы на изготовление - на строне третьих лиц, проверка запросов и создание СКП - в УЦ. У многих поменяется схема работы.

Я говорил о центрах регистрации. В их обязанности входит только получение начальных данных от клиента и выдача сертификата. И да, я собственно и говорил о том, что текущие коммерческие УЦ будут трансформироваться в простые центры регистрации. Или умрут.

С уважением,
Юрий Строжевский
Offline Юрий  
#109 Оставлено : 12 декабря 2014 г. 12:02:19(UTC)
Юрий

Статус: Активный участник

Группы: Участники
Зарегистрирован: 22.01.2008(UTC)
Сообщений: 675
Мужчина
Российская Федерация
Откуда: Йошкар-Ола

Сказал «Спасибо»: 3 раз
Поблагодарили: 95 раз в 68 постах
Автор: Alexey I Перейти к цитате
Тут другой важный момент:
Цитата:
"После получения свидетельства об аккредитации аккредитованный удостоверяющий центр обязан осуществить присоединение информационной системы, обеспечивающей реализацию функций аккредитованного удостоверяющего центра, к информационно- технологической и коммуникационной инфраструктуре в порядке, установление которого предусмотрено частью 4 статьи 19 Федерального закона от 27 июля 2010 года № 210-ФЗ "Об организации предоставления государственных и муниципальных услуг" (далее соответственно - инфраструктура, присоединение аккредитованного удостоверяющего центра к инфраструктуре). После присоединения аккредитованного удостоверяющего центра к инфраструктуре уполномоченный федеральный орган выдает аккредитованному удостоверяющему центру квалифицированный сертификат, созданный с использованием средств головного удостоверяющего центра.

Обратите внимание - УЦ недостаточно будет зарегистрироваться на госуслугах как юрлицу, нужно будет регистрироовать ИС в ЕСИА, это совсем другой процесс и сейчас он совсем не простой. Сервисов интеграции средств УЦ (ЦР или АРМ админа) и ЕСИА, насколько я знаю, на сегодняшний день нет. Возможно КриптоПро, Инфотекс, совместно с МКС и другими разработчиками (Ланит и т.д.), что-то разработают для этого, иначе каждому УЦ придется серьезно потратиться на внедрение таких сервисов.

И всё-таки наиболее важный момент в приведённом отрывке законопроекта в том, что фактически УЦ запрещают использовать самоподписанные сертификаты. Все сертификаты будут выдаваться одним головным УЦ. Как уж именно эти теперь уже подчинённые УЦ будут взаимодействовать с основным - проблемы мелкие и решаемые.
С уважением,
Юрий Строжевский
Offline Sergey M. Murugov  
#110 Оставлено : 12 декабря 2014 г. 12:24:55(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Автор: Alexey I Перейти к цитате
Как реализовать ограничение, если пользователю сертификат нужен только для какой-то одной ИС (например только для СЭД, или СЭД + медстатистика)?
Пользователь должен в заявке указать ограничения, что в других ИС этот СКП не должен применяться и перечислить все OID иных ИС?

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

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (5)
17 Страницы«<910111213>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.