Об аккредитации удостоверяющих центров. Удостоверяющие центры Проверка мер по хранению документированной информации

12.01.2024 | Кафе

МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРИКАЗ

23.11.2011 №320

Об аккредитации удостоверяющих центров

Во исполнение пункта 3 части 4 статьи 8 Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» (Собрание законодательства Российской Федерации, 2011, № 15, ст. 2036; № 27, ст. 3880)

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

необходимые для осуществления предусматриваемой Федеральным законом об электронной подписи деятельности лицензии и иные разрешительные документы.

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

V. Проведение выездной проверки

16. Предметом выездной проверки являются содержащиеся в документах УЦ сведения, а также соответствие их работников и технических средств УЦ, оказываемых УЦ услуг требованиям, установленным Федеральным законом об электронной подписи.

17. Выездная проверка (как плановая, так и внеплановая) проводится по месту нахождения аккредитованного УЦ, и (или) по месту фактического осуществления деятельности УЦ.

18. Выездная проверка проводится в случае, если при документарной проверке не представляется возможным удостовериться в полноте и достоверности сведений, содержащихся в документах УЦ, указанных в пункте 14 настоящего Порядка, подтверждающих его соответствие требованиям Федерального закона об электронной подписи или проверить выполнение УЦ требований предписания уполномоченного органа.

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

20. Руководитель, иное должностное лицо или уполномоченный представитель УЦ, обязаны предоставить должностным лицам уполномоченного органа, проводящим выездную проверку, возможность ознакомиться с документами, связанными с целями, задачами и предметом выездной проверки, а также обеспечить доступ проводящих выездную проверку должностных лиц и участвующих в выездной проверке экспертов, представителей экспертных организаций на территорию, в используемые УЦ при осуществлении деятельности здания, строения, сооружения, помещения, к используемым УЦ техническим средствам и программному обеспечению.

21. Уполномоченный орган вправе привлекать к проведению выездной проверки аккредитованных УЦ экспертов, экспертные организации, не состоящие в гражданско-правовых и трудовых отношениях с юридическим лицом, индивидуальным предпринимателем, в отношении которых проводится проверка, и не являющиеся аффилированными лицами проверяемых лиц. К проведению выездной проверки аккредитованных УЦ могут также привлекаться сотрудники иных органов государственной власти в пределах их компетенции.

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

VI. Итоги проведения проверки

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

В акте проверки указываются:

1) дата, время и место составления акта проверки;

2) наименование уполномоченного органа;

3) дата и номер приказа руководителя уполномоченного органа;

4) фамилии, имена, отчества (при наличии) и должности должностного лица или должностных лиц, проводивших проверку;

5) наименование проверяемого аккредитованного УЦ, а также фамилия, имя, отчество и должность руководителя, иного должностного лица или уполномоченного представителя юридического лица, присутствовавших при проведении проверки;

6) дата, время, продолжительность и место (места) проведения проверки;=

7) сведения о результатах проверки, в том числе о выявленных нарушениях обязательных требований и требований, установленных муниципальными правовыми актами, об их характере и о лицах, допустивших указанные нарушения;

8) сведения об ознакомлении или отказе в ознакомлении с актом проверки руководителя, иного должностного лица или уполномоченного представителя юридического лица, индивидуального предпринимателя, его уполномоченного представителя, присутствовавших при проведении проверки, о наличии их подписей или об отказе от совершения подписи, а также сведения о внесении в журнал учета проверок записи о проведенной проверке либо о невозможности внесения такой записи в связи с отсутствием у юридического лица, индивидуального предпринимателя указанного журнала;

9) подписи должностного лица или должностных лиц, проводивших проверку.

23. Акт проверки оформляется непосредственно после ее завершения в двух экземплярах, один из которых с копиями приложений вручается руководителю, иному должностному лицу или уполномоченному представителю УЦ под расписку об ознакомлении либо об отказе в ознакомлении с актом проверки.

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

24. В случае выявления несоблюдения аккредитованными УЦ требований Федерального закона об электронной подписи уполномоченный орган по окончании проведения проверки выдает УЦ предписание об устранении нарушений в установленный срок и приостанавливает действие аккредитации УЦ на данный срок с внесением информации об этом в перечень аккредитованных удостоверяющих центров, аккредитация которых приостановлена.

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

В соответствии с подпунктом 1 части 2 статьи 8 Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» (Собрание законодательства Российской Федерации, 2011, № 15, ст. 2036; № 27, ст. 3880).

В соответствии с пунктом 5 статьи 12 Федерального закона от 26 декабря 2008 г. № 294-ФЗ «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля» (Собрание законодательства Российской Федерации, 2008, № 52, ст. 6249; 2009, № 18, ст. 2140; № 29, ст. 3601; № 48, ст. 5711; № 52, ст. 6441; 2010, № 17, ст. 1988; № 18, ст. 21424 3 31, ст. 4160, ст. 4193, ст. 4196; № 32, ст. 4298; 2011, № 1, ст. 20; № 17, ст. 2310, № 23, ст. 3263; № 27, ст. 3880; № 30, ст. 4590; № 48, ст. 6728).

* Собрание законодательства Российской Федерации, 2011, N 15, ст. 2036; N 27, ст. 3880.

Однозначно показывать, что ЭП создана .

9. При проверке ЭП средства ЭП должны:

Показывать информацию о внесении изменений в подписанный ЭП электронный документ ;

Указывать на лицо, с использованием ключа ЭП которого подписаны электронные документы .

13. Средства ЭП класса КС1 противостоят атакам, при создании способов, подготовке и проведении которых используются следующие возможности:

13.1. Самостоятельное осуществление создания способов атак, подготовки и проведения атак.

13.2. Действия на различных этапах жизненного цикла средства ЭП

13.3. Проведение атаки только извне пространства, в пределах которого осуществляется контроль за пребыванием и действиями лиц и (или) транспортных средств (далее - контролируемая зона).

13.4. Проведение на этапах разработки, производства, хранения, транспортировки средств ЭП и этапе ввода в эксплуатацию средств ЭП (пусконаладочные работы) следующих атак:

Внесение несанкционированных изменений в средство ЭП и (или) в компоненты СФ, в том числе с использованием вредоносных программ;

Внесение несанкционированных изменений в документацию на средство ЭП и на компоненты СФ.

13.5. Проведение атак на следующие объекты:

Документацию на средство ЭП и на компоненты СФ;

Защищаемые электронные документы;

Ключевую, аутентифицирующую и парольную информацию средства ЭП;

Средство ЭП и его программные и аппаратные компоненты;

Аппаратные средства, входящие в СФ, включая микросхемы с записанным микрокодом BIOS, осуществляющей инициализацию этих средств (далее - аппаратные компоненты СФ);

Программные компоненты СФ;

Данные, передаваемые по каналам связи;

Помещения, в которых находится совокупность программных и технических элементов систем обработки данных, способных функционировать самостоятельно или в составе других систем (далее - СВТ), на которых реализованы средства ЭП и СФ;

Иные объекты атак, которые при необходимости указываются в ТЗ на разработку (модернизацию) средства ЭП с учетом используемых в информационной системе информационных технологий, аппаратных средств (далее - АС) и программного обеспечения (далее - ПО).

13.6. Получение следующей информации:

Общих сведений об информационной системе, в которой используется средство ЭП (назначение, состав, оператор, объекты, в которых размещены ресурсы информационной системы);

Сведений об информационных технологиях, базах данных, АС, ПО, используемых в информационной системе совместно со средством ЭП;

Сведений о физических мерах защиты объектов, в которых размещены средства ЭП;

Сведений о мерах по обеспечению контролируемой зоны объектов информационной системы, в которой используется средство ЭП;

Сведений о мерах по разграничению доступа в помещения, в которых находятся СВТ, на которых реализованы средства ЭП и СФ;

Общих сведений о защищаемой информации, используемой в процессе эксплуатации средства ЭП;

Всех возможных данных, передаваемых в открытом виде по каналам связи, не защищенным от несанкционированного доступа (далее - НСД) к информации организационно-техническими мерами;

Сведений о линиях связи, по которым передается защищаемая средством ЭП информация;

Сведений обо всех проявляющихся в каналах связи, не защищенных от НСД к информации организационно-техническими мерами, нарушениях правил эксплуатации средства ЭП и СФ;

Сведений обо всех проявляющихся в каналах связи, не защищенных от НСД к информации организационно-техническими мерами, неисправностях и сбоях аппаратных компонентов средства ЭП и СФ;

Сведений, получаемых в результате анализа любых сигналов от аппаратных компонентов средства ЭП и СФ, которые может перехватить нарушитель.

13.7. Использование:

Находящихся в свободном доступе или используемых за пределами контролируемой зоны АС и ПО, включая аппаратные и программные компоненты средства ЭП и СФ;

Специально разработанных АС и ПО.

13.8. Использование в качестве среды переноса от субъекта к объекту (от объекта к субъекту) атаки действий, осуществляемых при подготовке и (или) проведении атаки (далее - канал атаки):

Не защищенных от НСД к информации организационно-техническими мерами каналов связи (как вне контролируемой зоны, так и в ее пределах), по которым передается защищаемая средством ЭП информация;

Каналов распространения сигналов, сопровождающих функционирование средства ЭП и СФ.

13.9. Проведение атаки из информационно-телекоммуникационных сетей, доступ к которым не ограничен определенным кругом лиц.

13.10. Использование АС и ПО из состава средств информационной системы, используемых на местах эксплуатации средства ЭП (далее - штатные средства) и находящихся за пределами контролируемой зоны.

14. Средства ЭП класса КС2 противостоят атакам, при создании способов, подготовке и проведении которых используются возможности, перечисленные в настоящих Требований, и следующие дополнительные возможности:

14.1. Проведение атаки при нахождении как вне пределов, так и в пределах контролируемой зоны.

14.2. Использование штатных средств, ограниченное мерами, реализованными в информационной системе, в которой используется средство ЭП, и направленными на предотвращение и пресечение несанкционированных действий.

15. Средства ЭП класса КСЗ противостоят атакам, при создании способов, подготовке и проведении которых используются возможности, перечисленные в , , настоящих Требований, и следующие дополнительные возможности:

15.1. Доступ к СВТ, на которых реализованы средство ЭП и СФ.

15.2. Возможность располагать аппаратными компонентами средства ЭП и СФ в объеме, зависящем от мер, направленных на предотвращение и пресечение несанкционированных действий, реализованных в информационной системе, в которой используется средство ЭП.

16. Средства ЭП класса КВ1 противостоят атакам, при создании способов, подготовке и проведении которых используются возможности, перечисленные в , , , , настоящих Требований, и следующие дополнительные возможности:

16.1. Создание способов атак, подготовка и проведение атак с привлечением специалистов, имеющих опыт разработки и анализа средств ЭП, включая специалистов в области анализа сигналов, сопровождающих функционирование средства ЭП и СФ.

16.2. Проведение лабораторных исследований средства ЭП, используемого вне контролируемой зоны, в объеме, зависящем от мер, направленных на предотвращение и пресечение несанкционированных действий, реализованных в информационной системе, в которой используется средство ЭП.

17. Средства ЭП класса КВ2 противостоят атакам, при создании способов, подготовке и проведении которых используются возможности, перечисленные в , , , , , , настоящих Требований, и следующие дополнительные возможности:

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

17.2. Постановка работ по созданию способов и средств атак в научно-исследовательских центрах, специализирующихся в области разработки и анализа средств ЭП и СФ.

17.3. Возможность располагать исходными текстами входящего в СФ прикладного ПО.

18. Средства ЭП класса КА1 противостоят атакам, при создании способов, подготовке и проведении которых используются возможности, перечисленные в , , , , , , , настоящих Требований, и следующие дополнительные возможности:

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

18.2. Возможность располагать всей документацией на аппаратные и программные компоненты СФ.

18.3. Возможность располагать всеми аппаратными компонентами средства ЭП и СФ.

19. В случае реализации в средстве ЭП функции проверки ЭП электронного документа с использованием сертификата ключа проверки ЭП эта реализация должна исключить возможность проверки ЭП электронного документа без проверки ЭП в сертификате ключа проверки ЭП или без наличия положительного результата проверки ЭП в сертификате ключа проверки ЭП.

20. При разработке средств ЭП должны использоваться криптографические алгоритмы, утвержденные в качестве государственных стандартов или имеющие положительное заключение ФСБ России по результатам их экспертных криптографических исследований .

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

22. В средстве ЭП должны быть реализованы только заданные в ТЗ на разработку (модернизацию) средства ЭП алгоритмы функционирования средства ЭП.

23. Программный компонент средства ЭП (в случае наличия программного компонента средства ЭП) должен удовлетворять следующим требованиям:

Объектный (загрузочный) код программного компонента средства ЭП должен соответствовать его исходному тексту;

В программном компоненте средства ЭП должны использоваться при реализации только описанные в документации функции программной среды, в которой функционирует средство ЭП;

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

Значения входных и внутренних параметров, а также значения параметров настроек программного компонента средства ЭП не должны негативно влиять на его функционирование.

24. В случае планирования размещения средств ЭП в помещениях, в которых присутствует речевая акустическая и визуальная информация, содержащая сведения, составляющие государственную тайну, и (или) установлены АС и системы приема, передачи, обработки, хранения и отображения информации, содержащей сведения, составляющие государственную тайну, АС иностранного производства, входящие в состав средств ЭП, должны быть подвергнуты проверкам по выявлению устройств, предназначенных для негласного получения информации.

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

Решение о проведении проверок АС иностранного производства, входящих в состав средств ЭП классов КС1, КС2, КС3, КВ1 и КВ2, принимается организацией, обеспечивающей эксплуатацию данных средств ЭП;

Проверки АС иностранного производства, входящих в состав средств ЭП класса КА1, проводятся в обязательном порядке.

25. Средство ЭП должно проводить аутентификацию субъектов доступа (лиц, процессов) к этому средству, при этом:

При осуществлении доступа к средству ЭП аутентификация субъекта доступа должна проводиться до начала выполнения первого функционального модуля средства ЭП;

Механизмы аутентификации должны блокировать доступ этих субъектов к функциям средства ЭП при отрицательном результате аутентификации.

26. Средство ЭП должно проводить аутентификацию лиц, осуществляющих локальный доступ к средству ЭП.

27. Необходимость проведения средством ЭП аутентификации процессов, осуществляющих локальный или удаленный (сетевой) доступ к средству ЭП, указывается в ТЗ на разработку (модернизацию) средства ЭП.

28. Для любого входящего в средство ЭП механизма аутентификации должен быть реализован механизм ограничения количества следующих подряд попыток аутентификации одного субъекта доступа, число которых не должно быть больше 10. При превышении числа следующих подряд попыток аутентификации одного субъекта доступа установленного предельного значения доступ этого субъекта к средству ЭП должен блокироваться на заданный в ТЗ на разработку (модернизацию) средства ЭП промежуток времени.

29. В средстве ЭП должен быть реализован механизм (процедура) контроля целостности средства ЭП и СФ.

Контроль целостности может осуществляться:

В начале работы со средством ЭП до перехода СВТ, в котором реализовано средство ЭП, в рабочее состояние (например, до загрузки операционной системы СВТ);

В ходе регламентных проверок средства ЭП на местах эксплуатации (регламентный контроль);

В автоматическом режиме в процессе функционирования средства ЭП (динамический контроль).

Контроль целостности должен проводиться в начале работы со средством ЭП.

Механизм регламентного контроля целостности должен входить в состав средств ЭП.

30. Для средств ЭП классов КС1 и КС2 необходимость предъявления требований к управлению доступом и очистке памяти, а также их содержание указываются в ТЗ на разработку (модернизацию) средства ЭП.

31. В состав средств ЭП классов КС3, КВ1, КВ2 и КА1 или СФ должны входить компоненты, обеспечивающие:

Управление доступом субъектов к различным компонентам и (или) целевым функциям средства ЭП и СФ на основе параметров, заданных администратором или производителем средства ЭП (требования к указанному компоненту определяются и обосновываются организацией, проводящей исследования средства ЭП с целью оценки соответствия средства ЭП настоящим Требованиям);

Очистку оперативной и внешней памяти, используемой средством ЭП для хранения защищаемой информации, при освобождении (перераспределении) памяти путем записи маскирующей информации (случайной или псевдослучайной последовательности символов) в память.

32. В состав средств ЭП классов КВ2 и КА1 или СФ должны входить компоненты, обеспечивающие экстренное стирание защищаемой информации ограниченного доступа. Требования к реализации и надежности стирания задаются в ТЗ на разработку (модернизацию) средства ЭП.

33. Для средств ЭП классов КС1 и КС2 необходимость предъявления требований к регистрации событий и их содержание указываются в ТЗ на разработку (модернизацию) средства ЭП.

34. В состав средств ЭП классов КС3, КВ1, КВ2 и КА1 должен входить модуль, производящий фиксацию в электронном журнале регистрации событий в средстве ЭП и СФ, связанных с выполнением средством ЭП своих целевых функций.

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

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

36. Срок действия ключа проверки ЭП не должен превышать срок действия ключа ЭП более чем на 15 лет.

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

38. Криптографические протоколы, обеспечивающие операции с ключевой информацией средства ЭП, должны быть реализованы непосредственно в средстве ЭП.

39. Исследования средств ЭП с целью оценки соответствия средств ЭП настоящим Требованиям должны проводиться с использованием разрабатываемых ФСБ России числовых значений параметров и характеристик реализуемых в средствах ЭП механизмов защиты и аппаратных и программных компонентов СФ .

______________________________

*(3) Реализуется в том числе с использованием аппаратных и программных средств, совместно с которыми штатно функционируют средства ЭП и которые способны повлиять на выполнение предъявляемых к средствам ЭП требований, в совокупности представляющих среду функционирования средств ЭП (далее - СФ).

*(4) Необходимый класс разрабатываемого (модернизируемого) средства ЭП определяется заказчиком (разработчиком) средства ЭП путем определения возможностей осуществлять создание способов атак, подготовку и проведение атак на основе настоящих Требований и указывается в ТЗ на разработку (модернизацию) средства ЭП.

*(5) К этапам жизненного цикла средства ЭП относятся разработка (модернизация) указанных средств, их производство, хранение, транспортировка, ввод в эксплуатацию (пусконаладочные работы), эксплуатация.

*(6) Границей контролируемой зоны могут быть: периметр охраняемой территории предприятия (учреждения), ограждающие конструкции охраняемого здания, охраняемой части здания, выделенного помещения.

*(7) Подпункт 25 пункта 9 Положения о Федеральной службе безопасности Российской Федерации, утвержденного Указом Президента Российской Федерации от 11 августа 2003 г. N 960 (Собрание законодательства Российской Федерации, 2003, N 33, ст. 3254; 2004, N 28, ст. 2883; 2005, N 36, ст. 3665; N 49, ст. 5200; 2006, N 25, ст. 2699; N 31 (ч. I), ст. 3463; 2007, N 1 (ч. I), ст. 205; N 49, ст. 6133; N 53, ст. 6554; 2008, N 36, ст. 4087; N 43, ст. 4921; N 47, ст. 5431; 2010, N 17, ст. 2054; N 20, ст. 2435; 2011, N 2, ст. 267; N 9, ст. 1222) (далее - Положение о ФСБ России).

*(8) Подпункт 47 пункта 9 Положения о ФСБ России.

23. Требования к идентификации и аутентификации:

23.1. Идентификация и аутентификация включают в себя распознавание пользователя средств УЦ, члена группы администраторов средств УЦ или процесса и проверку их подлинности. Механизм аутентификации должен блокировать доступ этих субъектов к функциям УЦ при отрицательном результате аутентификации.

23.2. В средствах УЦ для любой реализованной процедуры аутентификации должен быть применен механизм ограничения количества следующих подряд попыток аутентификации одного субъекта доступа, число которых не должно быть больше трех. При превышении числа следующих подряд попыток аутентификации одного субъекта доступа установленного предельного значения доступ этого субъекта доступа к средствам УЦ должен быть заблокирован на промежуток времени, который указывается в ТЗ на разработку (модернизацию) средств УЦ.

23.3. Требования для средств УЦ класса КС1:

Описание процедуры регистрации пользователей средств УЦ (внесения данных в реестр пользователей средств УЦ) должно содержаться в эксплуатационной документации на средства УЦ;

Для всех лиц, осуществляющих доступ к средствам УЦ, должна проводиться аутентификация. При этом допускается ограничиться использованием для аутентификации только символьного периодически изменяющегося пароля из не менее чем 8 символов при мощности алфавита не менее 36 символов. Период изменения пароля не должен быть больше 6 месяцев.

23.4. Требования для средств УЦ класса КС2:

Необходимость предъявления пользователем средств УЦ при его регистрации документов, удостоверяющих личность, должна быть отражена в эксплуатационной документации на средства УЦ;

Для всех пользователей средств УЦ допускается использование механизмов удаленной аутентификации. Специальные характеристики механизмов удаленной аутентификации должны быть подтверждены в рамках проведения проверки соответствия средств УЦ и объектов информатизации, использующих данные средства, настоящим Требованиям;

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

23.5. Требования для средств УЦ класса КСЗ:

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

23.6. Требования для средств УЦ класса KB1:

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

23.7. Требования для средств УЦ класса КВ2 совпадают с требованиями для средств УЦ класса KB1.

23.8. Требования для средств УЦ класса КА1:

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

24. Требования к защите данных, поступающих (экспортируемых) в (из) УЦ:

24.1. Средства УЦ должны обеспечивать доверенный ввод самоподписанного сертификата ключа проверки ЭП.

24.2. Требования для средств УЦ класса КС1:

Средства УЦ должны обеспечивать передачу данных, содержащих информацию ограниченного доступа, поступающих в УЦ и экспортируемых из УЦ, способом, защищенным от НСД;

В средствах УЦ должна быть реализована процедура защиты от навязывания ложных сообщений ;

Требования к процедуре защиты от навязывания ложных сообщений указываются в ТЗ на разработку (модернизацию) средств УЦ.

24.3. Требования для средств УЦ класса КС2:

Средства УЦ должны обеспечивать защиту первоначального запроса на сертификат ключа проверки ЭП;

Средства УЦ должны принимать критичную для функционирования УЦ информацию, только если она подписана ЭП.

24.4. Требования для средств УЦ класса КС3:

В средствах УЦ должен быть реализован механизм защиты от навязывания ложных сообщений на основе использования средств ЭП, получивших подтверждение соответствия требованиям к средствам ЭП.

24.5. Требования для средств УЦ класса KB1:

В средствах УЦ должен быть реализован механизм защиты данных при передаче их между физически разделенными компонентами на основе использования СКЗИ.

24.6. Требования для средств УЦ классов КВ2 и КА1 совпадают с требованиями для средств УЦ класса KB1.

25. Требования к регистрации событий:

25.1. Базовая ОС средств УЦ должна поддерживать ведение журнала аудита системных событий.

25.2. Требования для средств УЦ класса КС1:

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

Список регистрируемых событий должен содержаться в эксплуатационной документации на средства УЦ.

25.3. Требования для средств УЦ класса КС2 совпадают с требованиями для средств УЦ класса КС1.

25.4. Требования для средств УЦ класса КС3:

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

25.5. Требования для средств УЦ класса КВ1 совпадают с требованиями для средств УЦ класса КС3.

25.6. Требования для средств УЦ класса КВ2:

Должны быть приняты меры обнаружения несанкционированных изменений каждой записи в журнале аудита.

25.7. Требования для средств УЦ класса КА1:

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

26. Требования по надежности и устойчивости функционирования средств УЦ:

26.1. Должны быть определены требования по надежности и устойчивости функционирования средств УЦ и указаны в ТЗ на разработку (модернизацию) средств УЦ.

26.2. Требования для средств УЦ класса КС1:

Проводится расчет вероятности сбоев и неисправностей АС УЦ, приводящих к невыполнению УЦ своих функций.

26.3. Требования для средств УЦ класса КС2:

Должно осуществляться тестирование устойчивости функционирования средств УЦ.

26.4. Требования для средств УЦ класса КС3:

Должны быть определены требования по времени восстановления средств УЦ после сбоя и указаны в ТЗ на разработку (модернизацию) средств УЦ;

Меры и средства повышения надежности и устойчивости функционирования средств УЦ должны содержать механизмы квотирования ресурсов средств УЦ.

26.5. Требования для средств УЦ класса KB1:

Вероятность сбоев и неисправностей АС УЦ, приводящих к невыполнению УЦ своих функций, в течение суток не должна превышать аналогичной вероятности для используемых СКЗИ.

26.6. Требования для средств УЦ классов КВ2 и КА1 совпадают с требованиями для средств УЦ класса КВ1.

27. Требования к ключевой информации:

27.1. Порядок создания, использования, хранения и уничтожения ключевой информации определяется в соответствии с требованиями эксплуатационной документации на средства ЭП и иные СКЗИ, используемые средствами УЦ.

27.2. Срок действия ключа ЭП средства ЭП, используемого средствами УЦ, должен соответствовать требованиям, установленным к средствам ЭП.

27.3. Требования для средств УЦ класса КС1:

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

Ключи ЭП, используемые для подписи сертификатов ключей проверки ЭП и списков уникальных номеров сертификатов ключей проверки ЭП, действие которых на определенный момент было прекращено УЦ до истечения срока их действия (далее - список аннулированных сертификатов), не должны использоваться ни для каких иных целей;

Сроки действия всех ключей должны быть указаны в эксплуатационной документации на средства УЦ.

27.4. Требования для средств УЦ классов КС2 и КС3 совпадают с требованиями для средств УЦ класса КС1.

27.5. Требования для средств УЦ класса KB1:

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

27.6. Требования для средств УЦ класса КВ2:

Ключ ЭП, используемый для подписи сертификатов ключей проверки ЭП и списков аннулированных сертификатов, должен генерироваться, храниться, использоваться и уничтожаться в средстве ЭП. Допускается использование только средств ЭП, получивших подтверждение соответствия требованиям, предъявляемым к средствам ЭП в соответствии с Федеральным законом;

27.7. Требования для средств УЦ класса КА1:

28. Требования к резервному копированию и восстановлению работоспособности средств УЦ:

28.1. Средства УЦ должны реализовывать функции резервного копирования и восстановления на случай повреждения АС и (или) информации, обрабатываемой средствами УЦ. В ходе резервного копирования должна быть исключена возможность копирования криптографических ключей.

28.2. Требования для средств УЦ класса КС1:

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

28.3. Требования для средств УЦ классов КС2 и КС3 совпадают с требованиями для средств УЦ класса КС1.

28.4. Требования для средств УЦ класса KB1:

Должны быть приняты меры обнаружения несанкционированных изменений сохраненных данных;

Должны быть определены требования по времени восстановления и указаны в ТЗ на разработку (модернизацию) средств УЦ и в эксплуатационной документации на средства УЦ.

28.5. Требования для средств УЦ класса КВ2:

Сохраняемая при резервном копировании защищаемая информация должна сохраняться только в зашифрованном виде.

28.6. Требования для средств УЦ класса КА1 совпадают с требованиями для средств УЦ класса КВ2.

29. Требования к созданию и аннулированию сертификатов ключей проверки ЭП:

29.1. Протоколы создания и аннулирования сертификатов ключей проверки ЭП должны быть описаны в эксплуатационной документации на средства УЦ.

29.2. Создаваемые УЦ сертификаты ключей проверки ЭП и списки аннулированных сертификатов должны соответствовать международным рекомендациям ITU-T Х.509 (далее - рекомендации Х.509). Все поля и дополнения, включаемые в сертификат ключей проверки ЭП и список аннулированных сертификатов, должны быть заполнены в соответствии с рекомендациями Х.509. При использовании альтернативных форматов сертификатов ключей проверки ЭП должны быть определены требования к протоколам создания и аннулирования сертификатов ключей проверки ЭП и указаны в ТЗ на разработку (модернизацию) средств УЦ.

29.3. Средства УЦ должны реализовывать протокол аннулирования сертификата ключа проверки ЭП с использованием списков аннулированных сертификатов.

29.4. Допускается реализация протоколов аннулирования без использования списков аннулированных сертификатов, требования к которым должны быть указаны в ТЗ на разработку (модернизацию) средств УЦ.

29.5. Требования для средств УЦ класса КС1:

В средствах УЦ должна быть реализована функция изготовления сертификата ключа проверки ЭП на бумажном носителе. Порядок выдачи сертификата ключа проверки ЭП на бумажном носителе, а также процедура контроля соответствия сертификата ключа проверки ЭП в электронном виде и на бумажном носителе должны быть указаны в эксплуатационной документации на средства УЦ;

В средствах УЦ в отношении владельца сертификата ключа проверки ЭП должны быть реализованы механизмы проверки уникальности ключа проверки ЭП и обладания соответствующим ключом ЭП.

29.6. Требования для средств УЦ класса КС2 совпадают с требованиями для средств УЦ класса КС1.

29.7. Требования для средств УЦ класса КС3:

Погрешность значений времени в сертификатах ключей проверки ЭП и списках аннулированных сертификатов не должна превышать 10 минут.

29.8. Требования для средств УЦ класса KB1:

Погрешность значений времени в сертификатах ключей проверки ЭП и списках аннулированных сертификатов не должна превышать 5 минут.

29.9. Требования для средств УЦ классов КВ2 и КА1 совпадают с требованиями для средств УЦ класса KB1.

30. Требования к структуре сертификата ключа проверки ЭП и списка аннулированных сертификатов:

30.1. Требования для средств УЦ класса КС1:

Допустимые структуры сертификата ключа проверки ЭП и списка аннулированных сертификатов должны быть перечислены в эксплуатационной документации на средства УЦ;

В средствах УЦ должен быть реализован механизм контроля соответствия создаваемых сертификатов ключей проверки ЭП и списков аннулированных сертификатов заданной структуре;

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

30.2. Требования для средств УЦ классов КС2 и КСЗ совпадают с требованиями для средств УЦ класса КС1.

30.3. Требования для средств УЦ класса KB1:

В средствах УЦ должен быть реализован механизм задания системным администратором набора допустимых дополнений сертификата ключа проверки ЭП и списка аннулированных сертификатов.

30.4. Требования для средств УЦ классов КВ2 и КА1 совпадают с требованиями для средств УЦ класса KB1.

31. Требования к реестру сертификатов ключей проверки ЭП и обеспечению доступа к нему:

31.1. Требования для средств УЦ класса КС1:

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

31.2. Требования для средств УЦ класса КС2 совпадают с требованиями для средств УЦ класса КС1.

31.3. Требования для средств УЦ класса КС3:

В средствах УЦ должен быть реализован механизм поиска сертификатов ключей проверки ЭП и списков аннулированных сертификатов в реестре сертификатов ключей проверки ЭП по различным их атрибутам;

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

31.4. Требования для средств УЦ классов KB1, КВ2 и КА1 совпадают с требованиями для средств УЦ класса КС3.

32. Требования к проверке ЭП в сертификате ключа проверки ЭП:

32.1. Должен быть определен механизм проверки подписи в сертификате ключа проверки ЭП по запросу участника электронного взаимодействия и указан в эксплуатационной документации на средства УЦ.

32.2. В средствах УЦ должен быть реализован механизм проверки подлинности ЭП УЦ в выдаваемых им сертификатах ключей проверки ЭП.

32.3. Проверка ЭП в сертификате ключа проверки ЭП осуществляется в соответствии с рекомендациями Х.509, включая обязательную проверку всех критических дополнений.

32.4. Если, исходя из особенностей эксплуатации средств УЦ, допускается использование альтернативных форматов сертификата ключа проверки ЭП, должен быть определен механизм проверки подписи в сертификате ключа проверки ЭП и указан в ТЗ на разработку (модернизацию) средств УЦ.

33. Для ограничения возможностей по построению каналов атак на средства УЦ с использованием каналов связи должны применяться средства межсетевого экранирования.

34. Должны быть определены требования по защите средств УЦ от компьютерных вирусов и компьютерных атак и указаны в ТЗ на разработку (модернизацию) средств УЦ.

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

36. Исследования средств УЦ с целью подтверждения соответствия средств УЦ настоящим Требованиям должны проводиться с использованием разрабатываемых ФСБ России числовых значений параметров и характеристик механизмов защиты, реализуемых в средствах УЦ .

______________________________

*(3) Необходимый класс разрабатываемых (модернизируемых) средств УЦ определяется заказчиком (разработчиком) средств УЦ путем определения возможностей осуществлять создание способов атак, подготовку и проведение атак на основе настоящих Требований и указывается в тактико-техническом задании или техническом задании на проведение опытно-конструкторской работы или составной части опытно-конструкторской работы по разработке (модернизации) средств УЦ (далее - ТЗ на разработку (модернизацию) средств УЦ).

*(4) Программная среда, которая допускает существование в ней только фиксированного набора субъектов (программ, процессов).

*(5) Лица, являющиеся членами группы администраторов средств УЦ и заведомо не являющиеся нарушителями.

*(6) Навязывание ложного сообщения представляет собой действие, воспринимаемое участниками электронного взаимодействия или средствами УЦ как передача истинного сообщения способом, защищенным от НСД.

*(7) ITU-T Recommendation Х.509. Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks. 2008. http://www.itu.int/rec/T-REC-X.509-200811-i.

*(8) Подпункт 47 пункта 9 Положения о Федеральной службе безопасности Российской Федерации, утвержденного Указом Президента Российской Федерации от 11 августа 2003 г. N 960 (Собрание законодательства Российской Федерации, 2003, N 33, ст. 3254; 2004, N 28, ст. 2883; 2005, N 36, ст. 3665; N 49, ст. 5200; 2006, N 25, ст. 2699; N 31 (ч. I), ст. 3463; 2007, N 1 (ч. I), ст. 205; N 49, ст. 6133; N 53, ст. 6554; 2008, N 36, ст. 4087; N 43, ст. 4921; N 47, ст. 5431; 2010, N 17, ст. 2054; N 20, ст. 2435; 2011, N 2, ст. 267; N 9, ст. 1222).

Приказ ФСБ РФ от 27 декабря 2011 г. N 796 "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра"

Настоящий приказ вступает в силу по истечении 10 дней после дня его официального опубликования

Обзор документа

Утверждены Требования к средствам электронной подписи.

Они предназначены для заказчиков и разработчиков создаваемых (модернизируемых) средств при их взаимодействии между собой, с организациями, проводящими криптографические, инженерно-криптографические и специальные исследования средств, ФСБ России, подтверждающей соответствие средств требованиям.

Требования распространяются на средства, предназначенные для использования в РФ, в ее учреждениях за рубежом и в находящихся там же обособленных подразделениях юрлиц, образованных в соответствии с законодательством нашей страны.

Для целей применения Положения о разработке, производстве, реализации и эксплуатации шифровальных (криптографических) средств защиты информации (Положение ПКЗ-2005) средства рассматриваются как объекты защиты данных с ограниченным доступом, не содержащих гостайну.

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

Также утверждены Требования к средствам удостоверяющего центра.

Они предназначены для вышеуказанных категорий лиц, работающих с данными средствами.

Требования распространяются на средства, предназначенные для использования в России.

Для целей применения названного Положения средства рассматриваются аналогичным образом.

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

выдача электронных подписей;
предоставление открытых ключей (сертификатов) ЭЦП любым заинтересованным лицам;
приостановка действия ЭЦП, в случае их компрометации;
удостоверение правильности подписи электронных документов;
разбор конфликтных ситуаций.

Для получения ЭЦП необходимо обратиться в Удостоверяющий центр, или его представительство.

Удостоверяющие центры в России

«ИнфоТеКС Интернет Траст»
УЦ Верховного Суда
УЦ Госдумы
УЦ Генпрокуратуры
УЦ Следственного комитета

Хроника

2019

Как поправки в закон об электронной подписи изменили систему УЦ

Госдума приняла в третьем чтении законопроект, вносящий поправки в федеральный закон об электронной подписи. Рассказываем о главных изменениях .

Порядок выдачи

Электронные цифровые подписи юридическим лицам будут выдавать удостоверяющие центры ФНС , а кредитным организациям - УЦ Центробанка. Должностные лица госорганов и органов местного самоуправления и подведомственных им учреждений, а также нотариусы смогут получить ключи только в удостоверяющих центрах Федерального казначейства. Физические лица будут получать ключи в аккредитованных коммерческих удостоверяющих центрах.

Подпись юридического лица

В правоотношениях юридических лиц будут использоваться подписи:

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

Облачная подпись

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

Аккредитации удостоверяющих центров

Для получения аккредитации УЦ размер капитала должен составлять не менее 1 миллиарда рублей либо 500 миллионов при наличии филиалов не менее чем в трех четвертях субъектов РФ.
УЦ должен иметь не менее 100 миллионов рублей страхового обеспечения.
Аккредитация будет предоставляться на 3 года.

Идентификация заявителя

Появились установленные способы идентификации заявителя на получение сертификата, в том числе посредством предоставления сведений из единой биометрической системы.

Доверенная третья сторона

В законе появится новое понятие - доверенная третья сторона. Она будет проверять действительность ЭП, соответствие сертификатов и полномочия участников электронного взаимодействия, а также осуществлять документальное подтверждение результатов такой проверки.

Госдума вводит госмонополию на выдачу электронной подписи для юрлиц

8 ноября 2019 года стало известно, что Государственная Дума приняла в первом чтении законопроект о внесении поправок в Закон «Об электронной подписи ». Документ был разработан рядом сенаторов и депутатов и предполагает серьезную реформу удостоверяющих центров электронной подписи.

Действующий с 2011 г. Закон «Об электронной подписи» вводит три вида подписей: простую, усиленную и квалифицированную. Простой подписью является любая технология, об использовании которой договорились стороны. Усиленной подписью является подпись, выданная удостоверяющим центром.

Квалифицированная подпись – это подпись, выданная аккредитованным удостоверяющим центром. Аккредитацией занимается Минкомсвязи . Такого рода подпись признается аналогом собственноручной.

Принятый в первом чтении законопроект увеличивает минимальный размер чистых активов аккредитованного удостоверяющего центра с 7 млн руб. до 1 млрд руб., а минимальный размер финансового обеспечения – с 30 млн руб. до 200 млн руб. Если у удостоверяющего центра есть филиалы в как минимум двух третях российских регионов, то минимальный размер чистых активов может быть сокращен до 500 млн руб.

Срок аккредитации удостоверяющих центров сокращается с пяти до трех лет. За нарушения в работе удостоверяющих центров технического характера вводится административная ответственность. А за умышленные действия сотрудников удостоверяющих центров, помимо административной, вводится еще и уголовная ответственность.

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

2017

Минкомсвязь внесла в Правительство законопроект о проверке полномочий лица, использующего электронную подпись

12 сентября 2017 года директор Правового департамента Министерства связи и массовых коммуникаций Российской Федерации Роман Кузнецов рассказал о деятельности министерства по созданию единого пространства доверия электронной подписи и планах по регулированию этой сферы.

«Минэкономразвития России отмечает нецелесообразность принятия предлагаемого регулирования в связи со значительным объемом бюджетных расходов, наличием административных и иных рисков, способных негативно повлиять на развитие рынка по созданию и выдаче квалифицированных сертификатов, ключей проверки электронной подписи, а также смежных отраслей экономики», - говорится в заключении, подписанном заместителем министра экономического развития Саввой Шиповым.

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

Эксперты выступают против госмонополии на выдачу квалифицированной электронной подписи

Подключить планируется УЦ «Тензор », «КриптоСтандарт », «

Удостоверяющие центры, попавшие в список на одобрение, смогут использовать инфраструктуру системы межведомственного электронного взаимодействия (СМЭВ) для получения информации от государственных органов, уточнил CNews Никита Баранов, руководитель проекта «Услуги Удостоверяющего центра» компании «СКБ Контур».

По его словам, это решение очень существенно отразится на практике работы УЦ.

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

«Для примера, физическому лицу надо предоставить как минимум паспорт, СНИЛС и свидетельство ИНН, а для юридического лица список дополняется выпиской ЕГРЮЛ, свидетельством ОГРН и учредительными документами, - объясняет Баранов. - От корректности действий УЦ зависит дальнейший юридический статус всех документов подписанных ЭП, а это могут быть договоры на очень большие суммы. Поэтому УЦ обязан удостовериться, что все предоставленные документы являются оригиналами, создать копии всех предоставленных документов и организовать их хранение».

Для пользователя это создает проблемы со сбором документов, для УЦ - с их проверкой и хранением, добавляет Баранов: «Все это с учетом большой территориальной распределенности».

«Подключение к СМЭВ поможет, во-первых, в том, что часть документов мы сможем собирать в электронном виде непосредственно в соответствующем ведомстве. Во-вторых, мы сможем в режиме он-лайн проверять действительность данных с подтверждением госорганов. А, в-третьих, нам не придется делать и хранить копии документов», - говорит он.

Все это, по мнению представителя «СКБ Контур», «приведет к существенному ускорению и повешению надежности процедуры выпуска и, одновременно к повышению удобства пользователей».

Процесс подключения УЦ к СМЭВ, по оценке Никиты Баранова, может занять около полугода: «Необходима техническая реализация - создание, тестирование и запуск в эксплуатацию модулей, которые отправляют запросы и получают ответы (например, проверка паспорта в ФМС)» .

2012: Приказ ФСБ о требованиях к средствам электронной подписи и УЦ

17 февраля 2012 г., был опубликован приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении требований к средствам электронной подписи и требований к средствам удостоверяющего центра». Ранее появился приказ от 27 декабря 2011 г. № 795 «Об утверждении требований к форме квалифицированного сертификата ключа проверки электронной подписи».

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

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

По сравнению с сертификатами ЭЦП изменился способ представления полномочий владельца сертификата. В сертификат ЭЦП по заявлению владельца могли включаться любые сведения, подтверждаемые соответствующими документами, а в квалифицированный сертификат нестандартные реквизиты (например, регистрационный номер страхователя) могут включаться только в том случае, если требования к их назначению и расположению в сертификате определены в документах, предоставляемых для подтверждения соответствия средств удостоверяющего центра требованиям ФСБ

Первые УЦ для получения ЭП гражданами открылись в Москве

Первые удостоверяющие центры, в которых граждане могут получить электронную подпись, открылись в Москве в апреле 2011 года. Для этого потребуется личное присутствие и паспорт гражданина. Подпись, представляющую собой зашифрованную информацию в виде файла, в присутствии заявителя запишут на сертифицированный электронный носитель (электронную карту или флеш-накопитель). Сама подпись бесплатна, но стоимость носителя придется оплатить. В Минкомсвязи предполагают, что получение квалифицированной электронной подписи обойдётся гражданину примерно в 300 руб. Как подчеркнул директор правового департамента министерства Андрей Тихомиров, получение электронной подписи – дело сугубо добровольное. Он также добавил, что гражданин несет ответственность за сохранность электронной подписи, напомнив, что в случае утери или кражи подпись можно заблокировать и затем восстановить через те же удостоверяющие центры.

Приложение 3

к Положению о Сети доверенных

удостоверяющих центров системы

«Электронная Торговая Площадка»

Требования

к удостоверяющим центрам при аккредитации

в системе «Электронная Торговая Площадка»

ГУП «Агентство по государственному заказу ,

инвестиционной деятельности и межрегиональным связям

Республики Татарстан »

1. Перечень сокращений

АРМ Автоматизированное рабочее место

БД База данных

ИС Информационная система

ПО Программное обеспечение

СКП Сертификат ключа подписи

СОС Список отозванных сертификатов

СУБД Система управления базой данных

УЦ Удостоверяющий центр

ФЗ Федеральный закон

ЭД Электронный документ

ЭЦП Электронно-цифровая подпись

OCSP Online Certificate Status Protocol – Служба проверки статуса сертификата ключа подписи в режиме реального времени

2. Термины и определения

В настоящем Документе применяют следующие термины с соответствующими определениями.

Система – система юридически значимого электронного документооборота «Электронная Торговая Площадка», предназначенная для проведения открытых аукционов в электронной форме и отвечающая требованиям, установленным законодательством Российской Федерации.

Организатор Системы – Государственное унитарное предприятие «Агентство по государственному заказу, инвестиционной деятельности и межрегиональным связям Республики Татарстан».

Удостоверяющий центр (УЦ) – уполномоченная организация, предоставляющая пользователям Системы услуги, связанные с использованием ЭЦП, в соответствие с Федеральным законом от 01.01.01 г. "Об электронной цифровой подписи".

Доверенный удостоверяющий центр (ДУЦ) – удостоверяющий центр, аккредитованный в Сети ДУЦ.

Сеть доверенных удостоверяющих центров (Сеть ДУЦ) – сеть доверенных удостоверяющих центров системы «Электронная Торговая Площадка».

Организатор сети доверенных удостоверяющих центров Системы (Организатор Сети ДУЦ) – Закрытое акционерное общество «ТаксНет».

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

Валидный сертификат – сертификат, положительно прошедший все операции проверки.

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

Закрытый (секретный) ключ ЭЦП – уникальная последовательность данных, известная владельцу сертификата ключа подписи и предназначенная для создания в электронных документах электронной цифровой подписи с использованием средств электронной цифровой подписи

Ключевой носитель – информационный носитель, на который записаны криптографические ключи.

Компрометация ключа – констатация обстоятельств, при которых возможно использование секретного ключа третьими лицами.

Криптопровайдер – средство электронной цифровой подписи.

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

Претендент – удостоверяющий центр, подвергаемый испытанию по настоящей методике для включения в Сеть ДУЦ.

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

Статус сертификата – составное понятие, отражающее каждый этап проверки валидности сертификата. Например, просрочен – не просрочен, отозван – не отозван и т. д.

Шифрование (зашифрование данных) – процесс преобразования открытых данных в зашифрованные при помощи шифра (ГОСТ).

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

Электронный документ – это документ, в котором информация представлена в электронно-цифровой форме. Документ (документированная информация) – зафиксированная на материальном носителе путем документирования информация с реквизитами, позволяющими определить такую информацию.

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

3. Нормативные документы

1. Федеральный Закон от 01.01.2001 № 1‑ФЗ «Об электронной цифровой подписи».

2. Федеральный Закон от 01.01.2001 № 128‑ФЗ «О лицензировании отдельных видов деятельности ».

3. Федеральный Закон от 01.01.2001 № 149‑ФЗ «Об информации, информационных технологиях и о защите информации».

4. Федеральный Закон от 01.01.2001 № 184‑ФЗ «О техническом регулировании».

5. ГОСТ 28147‑89 «Алгоритм шифрования».

6. ГОСТ Р 34.10‑94, ГОСТ Р 34.10‑2001 «Информационная технология криптографическая защита информации процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма».

7. ГОСТ Р 34.11-94 «Информационная технология криптографическая защита информации Функция хэширования».

8. ГОСТ Р 50922‑96 «Защита информации. Основные термины и определения. Государственные стандарты и другие документы Госстандарта России».

9. ГОСТ Р «Делопроизводство и архивное дело. Термины и определения».

10. ГОСТ Р 51275‑99 «Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения».

11. ГОСТ Р ИСО/МЭК «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий».

5) компьютеры рабочих мест сотрудников Претендента;

6) устройства печати на бумажных носителях (принтеры).

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

· Наличие перечня используемых технических средств обеспечения работы программного комплекса Претендента, с указанием конфигураций и мест размещения этого оборудования.

· Наличие действующих лицензий и сертификатов на технические средства, выданных ФСБ и/или ФСТЭК РФ и/или МинСвязи.

6.3.3. Проверка программных и программно-аппаратных средств защиты информации

Для обеспечения защиты информации Претендент должен располагать необходимыми программными и программно-аппаратными средствами

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

1) средства криптографической защиты информации;

2) межсетевой экран для обеспечения защиты информации при сетевом взаимодействии ЦС с удаленным ЦР;

3) программно-аппаратные комплексы защиты от несанкционированного доступа типа «Электронный замок».

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

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

· Наличие действующей лицензии и сертификатов соответствия на программные и программно-аппаратные средства обеспечения защиты информации, выданной ФСТЭК и/или ФСБ России, в соответствии с действующим законодательством Российской Федерации.

Средства криптографической защиты информации, эксплуатируемые на всех компонентах программного комплекса УЦ Претендента, должны быть сертифицированы по классу «КС2» в соответствии с действующим законодательством Российской Федерации

Проверка требования и результат

· Наличие установленных, сконфигурированных и настроенных средств криптографической защиты информации, эксплуатируемых на всех компонентах программного комплекса УЦ Претендента.

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

· Наличие персонала технической службы Претендента, ответственного за эксплуатацию средств криптографической защиты информации.

· Наличие сертификатов ФСБ РФ на используемые СКЗИ по классу «КС2», выданных в соответствии с действующим законодательством Российской Федерации.

6.3.4. Проверка программно-аппаратного комплекса резервного копирования Претендента

Для обеспечения бесперебойной и отказоустойчивой работы программного комплекса обеспечения реализации целевых функций Претендента должно быть обеспечено резервное копирование

Проверка требования и результат

· Наличие установленных, сконфигурированных и настроенных средств резервного копирования.

· Наличие заверенного руководителем Претендента перечня данных УЦ Претендента, подлежащих резервному копированию. Перечень должен включать:

1) сертификат ключа подписи уполномоченного лица Претендента в электронном виде (сертификат центра сертификации ЦС);

2) базу данных центра сертификации ЦС;

3) базу данных ЦР;

4) журналы аудита компонент программного комплекса Претендента;

5) реестр выданных сертификатов ключей подписи;

6) список отозванных сертификатов (СОС);

7) данные, определенные самим Претендентом.

· Наличие заверенного руководителем Претендента регламента проведения резервного копирования данных с указанием периодов резервного копирования, типов резервируемых данных, носителей для резервных данных и схемы ротации носителей резервных данных.

· В регламенте должно быть указано, что для всех позиций выполняется еженедельно (или чаще) полное резервное копирование и для позиций 2 – 6 ежедневное разностное резервное копирование. Для резервного копирования должно использоваться не менее двух носителей.

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

· Наличие перечня используемых средств резервного копирования.

6.4. Результаты проверки по разделу 6

Обязательные требования из раздела 6 должны быть выполнены для получения Претендентом аккредитации в Сети ДУЦ.

7. Проверка безопасности обрабатываемых в УЦ данных

7.1. Проверка инженерно-технических мер защиты информации

7.1.1. Проверка мер по размещению технических средств Претендента

Серверы ЦС и ЦР, серверы баз данных, серверы средств резервного копирования и телекоммуникационное оборудование должны размещаться в выделенном помещении

Проверка требования и результат

· Наличие схемы размещения серверов, на которой должно быть обозначено серверное оборудованное помещение Претендента. В этом помещении размещены: серверы ЦС и ЦР, серверы баз данных, серверы средств резервного копирования и телекоммуникационное оборудование. Допускается использовать IT-сейф, вместо выделенного помещения.

· Наличие в серверном помещении Претендента исправного, работающего оборудования системы контроля доступа электромеханического или механического типа (Рекомендуемое требование ).

Серверы ЦС и ЦР, серверы баз данных, средства резервного копирования и телекоммуникационное оборудование должны быть подключены к источникам бесперебойного питания

Проверка требования и результат

· Наличие схемы подключения серверов ЦС и ЦР, серверов баз данных, средств резервного копирования и телекоммуникационного оборудования к источникам бесперебойного питания.

· Наличие в серверном помещении исправного и работающего оборудования источников бесперебойного питания.

7.1.2. Проверка мер по хранению документированной информации

Документальный фонд Претендента, должен храниться в соответствии с действующим законодательством Российской Федерации по делопроизводству и архивному делу

Проверка требования и результат

· Наличие журнала учета хранения документов Претендента, оформленного в соответствии с действующим законодательством Российской Федерации по делопроизводству и архивному делу (Рекомендуемое требование ).

· Наличие приказа руководителя Претендента на создание архивохранилища и документального фонда.

· Наличие приказа руководителя Претендента на назначение ответственного персонала по работе с архивным фондом.

7.1.3. Проверка мер по уничтожению документированной информации

Выделение к уничтожению и уничтожение документов, не подлежащих архивному хранению, должно осуществляться в соответствии с приказом по уничтожению документов и в соответствии с действующим законодательством Российской Федерации по делопроизводству и архивному делу (Рекомендуемое требование )

Проверка требования и результат

· Наличие приказа руководителя Претендента о перечне документов, подлежащих уничтожению.

· Наличие журнала и/или актов уничтожения документов, содержащих подписи ответственного за архивное хранение персонала, даты и реквизиты уничтоженных документов.

7.2. Проверка программно-аппаратных мер защиты информации

7.2.1. Серверные помещения и технические средства, расположенные в них, должны пройти проверку на отсутствие в них электронных устройств перехвата информации (закладок) (Рекомендуемое требование)

Проверка требования и результат

· Наличие отчетов испытаний помещений и технических средств, расположенных в них, об успешной проверке на отсутствие электронных устройств перехвата информации (закладок), проведенных независимой экспертной организацией

7.2.2. Проверка мер по организации доступа к программным средствам Претендента

Серверы ЦС и ЦР должны быть оснащены программно-аппаратными комплексами защиты от несанкционированного доступа, сертифицированными ФСТЭК, ФСБ (Рекомендуемое требование )

Проверка требования и результат

· Наличие на серверах ЦС и ЦР Претендента исправного установленного и работающего программно-аппаратного комплекса защиты от несанкционированного доступа.

Рабочие места сотрудников Претендента, на которых эксплуатируются программные приложения «АРМ администратора ЦР» и «АРМ разбора конфликтных ситуаций», должны быть оснащены программно-аппаратными комплексами защиты от несанкционированного доступа, сертифицированными ФСТЭК, ФСБ.

Проверка требования и результат

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

· Наличие на рабочих местах сотрудников Претендента, на которых эксплуатируются программные приложения «АРМ администратора ЦР» и «АРМ разбора конфликтных ситуаций», исправного установленного и работающего программно-аппаратного комплекса защиты от несанкционированного доступа.

· Наличие сертификатов ФСТЭК, ФСБ для программно-аппаратного комплекса защиты от несанкционированного доступа.

Доступ системных администраторов системного программного обеспечения серверов ЦС и ЦР для выполнения регламентных работ должен осуществляться в присутствии сотрудников службы безопасности УЦ, отвечающих за эксплуатацию соответствующего прикладного программного обеспечения (ЦС и/или ЦР) (Рекомендуемое требование ).

Проверка требования и результат

· Наличие журнала учета доступа системных администраторов к системному программному обеспечению серверов ЦС и ЦР для выполнения регламентных работ, содержащего записи о содержании этих работ и датах проведения этих работ, заверенные подписями сотрудников службы безопасности Претендента, отвечающих за эксплуатацию соответствующего прикладного программного обеспечения (ЦС и/или ЦР)

7.2.3. Проверка мер по контролю целостности программного обеспечения

Программное обеспечение, эксплуатируемое Претендентом, должно проходить контроль целостности

Проверка требования и результат

· Наличие перечня программных модулей, подлежащих контролю целостности (примерный список размещен в Приложении 2), выпущенного в качестве внутреннего документа Претендента, утвержденный руководителем Претендента.

· В перечне указывается, что контроль целостности программных модулей основан на аппаратном контроле целостности программных модулей УЦ и общесистемного программного обеспечения до загрузки операционной системы и должен обеспечиваться с помощью программно-аппаратного комплекса защиты «Электронный замок».

7.2.4. Проверка мер по контролю целостности технических средств

Претендент должен обеспечивать контроль целостности технических средств (Рекомендуемое требование)

Проверка требования и результат

· Наличие специальных мест, меток и печатей для опечатывания корпусов устройств, препятствующих их неконтролируемому вскрытию.

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

· Наличие журнала учета контроля целостности печатей, в котором должны быть записи о проверке печатей, заверенные подписями ответственных сотрудников, и должны проводиться в начале каждой рабочей смены.

7.2.5. Проверка мер по защите внешних сетевых соединений

Конфиденциальная информация в процессе обмена документами в электронной форме должна защищаться

Проверка требования и результат

· Наличие сертификатов ФСБ на программно-технические средства шифрования информации и цифровой подписи требованиям к СКЗИ класса КС1 и/или КС2.

· Наличие сертификатов соответствия ФСБ или ФСТЭК на программно-технические средства построения защищённого сетевого взаимодействия (VPN, SSL и т. д.) (Рекомендуемое требование).

Защита программно-технических средств обеспечения деятельности Претендента от несанкционированного доступа по внешним сетевым соединениям должна обеспечиваться с применением межсетевого экрана

Проверка требования и результат

· Наличие на программно-технических средствах обеспечения деятельности Претендента, установленных, сконфигурированных и работающих программно-технических средств межсетевого экрана, обеспечивающего класс защиты не ниже 4-го.

7.2.6. Проверка мер по защите информации

Информация, поступающая Претенденту, должна быть защищена

Проверка требования и результат

· Наличие перечня информации (Приложение 4), которая должна быть защищена, оформленного в виде документа, заверенного руководителем организации.

· Наличие приказа руководителя Претендента на назначение ответственного персонала по защите информации (Рекомендуемое требование).

7.3. Результаты проверки по разделу 7

Все обязательные требования из раздела 7 должны быть удовлетворены для получения Претендентом аккредитации в Системе.

8. Проверка технологической совместимости

8.1. Проверка сертификатов ключей подписей уполномоченного лица УЦ Претендента

Претендент должен предоставить сертификат ключа подписи уполномоченного лица удостоверяющего центра, соответствующий требованиям к сертификатам ключей подписей уполномоченного лица

Сертификат X509:

Серийный номер: dc022b4c58082bcb3293819

Алгоритм подписи:

Параметры алгоритма:

Поставщик:

OU=Администрация

Действителен с: 18.08.2005 17:44

Действителен до: 16.12.2010 13:44

CN=Доверенный Удостоверяющий Центр

OU=Администрация

Алгоритм открытого ключа:

Параметры алгоритма:

Открытый ключ: UnusedBits = 0

Расширения сертификатов: 5

Основные ограничения

Тип субъекта=ЦС

Ограничение на длину пути=0

Имя точки распространения:

Полное имя:

Использование ключа

Идентификатор ключа центра сертификации

Идентификатор ключа субъекта

Алгоритм подписи:

ObjectId алгоритма: 1.2.643.2.2.3 ГОСТ Р 34.11/34.10-2001

Параметры алгоритма:

Подпись: НеиспользБит=0

0000 c8 d0 59 a0a 33 c6 40 cb

0010 9e a7 a4 deb0 36 1a 48 cc 53 03

0020 3c b8 ea b5 9ee acad b2 96 3e 87

0b 4bbd 8b 18 b6 4c 1a b2 d4 92 4a 19

Корневой сертификат: субъект совпадает с поставщиком

Хеш сертификата (md5): ae 97 a9 8bd1 fb c5f d4 f1 5c 74

Проверка требования и результат

· Сертификат содержит расширение «Основные ограничения», соответствующее требованиям п. 1.2.4, Приложения 3.

· Сертификат содержит расширение «Использование ключа», соответствующее требованиям п. 1.2.5, Приложения 3.

· Сертификат содержит действительную цифровую подпись. Текстовый файл содержит строку «Подпись соответствует открытому ключу».

8.2. Проверка запросов на кросс-сертификат

Претендент должен предоставить запрос на кросс-сертификат, соответствующий требованиям к запросам на кросс-сертификат

Проверка проводиться путём анализа текстового файла, содержащего данные запроса.

Пример текстового файла, содержащего данные сертификата:

Запрос сертификата PKCS10:

CN=Доверенный Удостоверяющий Центр

OU=Администрация

Алгоритм открытого ключа:

ObjectId алгоритма: 1.2.643.2.2.19 ГОСТ Р 34.10-2001

Параметры алгоритма:

Открытый ключ: UnusedBits = 0

0d fe e2 3c 1c f1 1c 1bf6 7d 4d

0d 53 a9 b9 2f d4dc f4 3e af 57 a9 06

0020 b6 4c 64 3d a9 78 be f4 29 e2 c7bf 59

0030 fbd 53 e7 5d 2a dad 8c 32 c0

Запрос атрибутов: 1

Атрибуты 1:

Атрибут: 1.2.840.113549.1.9.14 (Расширения сертификатов)

Значение:

Неизвестный тип атрибута

Расширения сертификатов: 5

2.5.29.19: Флаги = 1(критический), Длина = 4

Основные ограничения

Тип субъекта=ЦС

Ограничение на длину пути=0

2.5.29.31: Флаги = 0, Длина = a2

Точки распространения списков отзыва (CRL)

Точка распределения списка отзыва (CRL)

Имя точки распространения:

Полное имя:

URL=file://certserver/certsrv/trustca. crl

URL=http://www. *****/certsrv/trustca. crl

2.5.29.15: Флаги = 1(Критический), Длина = 4

Использование ключа

Цифровая подпись, Неотрекаемость, Шифрование ключей, Шифрование данных, Подписывание сертификатов, Автономное подписание списка отзыва (CRL), Подписание списка отзыва (CRL)(f6)

2.5.29.35: Флаги = 0, Длина = 18

Идентификатор ключа=4f ab fd f6 8f cc 70 e5 2b 98 e1 a5 7c f0 b8 0b b1 e1 78 d5

2.5.29.14: Флаги = 0, Длина = 16

Идентификатор ключа субъекта

4f ab fd f6 8f cc 70 e5 2b 98 e1 a5 7c f0 b8 0b b1 e1 78 d5

Алгоритм подписи:

ObjectId алгоритма: 1.2.643.2.2.3 ГОСТ Р 34.11/34.10-2001

Параметры алгоритма:

Подпись: НеиспользБит=0

0b6 cda2 f0 e3 c4 fdce f7 06

0eed6 98 d8 4e 7c e6 fd 08 d5 e4 89

0d2 43 ec e9 a5b 32 a1 7e 7a 52 e9 18

0030 d9 eb 4bfb d9 8c 07 4e df 5c 98 c3 5a

Подпись соответствует открытому ключу

Проверка требования и результат

· Состав запроса должен соответствовать требованиям п. 2, Приложения 3.

· Запрос содержит поле «Алгоритм подписи», соответствующее требованиям п. 1.1.3, Приложения 3.

· Запрос содержит поле «Субъект», соответствующее требованиям п. 2.1, Приложения 3.

· Запрос содержит поле «Алгоритм открытого ключа», соответствующее требованиям п. 2.2, Приложения 3.

· Запрос содержит поле «Открытый ключ», соответствующее требованиям п. 2.3, Приложения 3.

· Запрос содержит поле «Запрос атрибутов», соответствующее требованиям п. 2.4, Приложения 3.

· Запрос содержит расширение «Основные ограничения», соответствующее требованиям п. 2.4.1, Приложения 3.

· Запрос содержит расширение «Идентификатор ключа субъекта», соответствующее требованиям п. 2.4.2, Приложения 3.

· Запрос содержит расширение «Использование ключа», соответствующее требованиям п. 2.4.3, Приложения 3.

· Запрос содержит действительную цифровую подпись. Текстовый файл содержит строку «Подпись соответствует открытому ключу».

· Значения полей «Алгоритм подписи», «Субъект», «Алгоритм открытого ключа», «Открытый ключ», указанные в запросе, должны соответствовать значениям этих полей, указанным в сертификате.

8.3. Проверка совместимости сертификатов ключей подписи, изданных УЦ Претендента, с программными средствами, используемыми в Системе

Претендент должен предоставить сертификат ключа подписи, изданный УЦ Претендента с закрытым ключом, соответствующий требованиям к сертификатам ключей подписей пользователя Системы.

Сертификат должен являться сертификатом, соответствующим международным рекомендациям X.509, версии 3 и соответствовать требованиям, предъявляемым к сертификатам

Проверка проводиться путём анализа текстового файла, содержащего данные сертификата.

Пример текстового файла, содержащего данные сертификата:

Сертификат X509:

Серийный номер: 1d196bfd2

Алгоритм подписи:

Параметры алгоритма:

Поставщик:

CN=Доверенный Удостоверяющий Центр

OU=Администрация

Действителен с: 31.01.2006 12:11

Действителен по: 31.01.2007 12:21

CN=Тестовый Пользователь Доверенного Удостоверяющего Центра

OU=Должность Тестового Пользователя

O=Организация Тестового Пользователя

Алгоритм открытого ключа:

ObjectId алгоритма: 1.2.643.2.2.20 ГОСТ Р 34.10-94

Параметры алгоритма:

Открытый ключ: UnusedBits = 0

09e 48 9f f3 bdc ec 5f fe 96

0a6 6b 9f f4 45 5e 65 0f df d5 de c4 e9 29

0020 4b 83 7a e0 99 e5 90 3e c5 4e dbe 10 77

0030 9ef 2e 97 c0 fb 93 eecc df 67

0f4 96 f3 4fe 73 7b 43 9f 7c be 48

0f 1c d3f1c8 f5 ab d1 64 4b 3f

0d cb a9 4e 97 a9 47 6a 12 ec 7f 31 7b bd 7f

0070 1e 8f 14 c7 f6 8c 2bd8 7d 4d 1c 1d 1c

Расширения сертификатов: 6

2.5.29.15: Флаги = 1(Критический), Длина = 4

Использование ключа

Цифровая подпись, Неотрекаемость, Шифрование ключей, Шифрование данных (f0)

2.5.29.14: Флаги = 0, Длина = 16

Идентификатор ключа субъекта

c9 6c d5 8c eb 3c 1eda d1 43 c7 92 1e 7d

2.5.29.37: Флаги = 0, Длина = c

Улучшенный ключ

Защищенная электронная почта (1.3.6.1.5.5.7.3.4)

2.5.29.35: Флаги = 0, Длина = 18

Идентификатор ключа центра сертификатов

Идентификатор ключа=91c 5f 91 9ed bb c9 d4 c8 8a c3 13 b4 df 5b

2.5.29.31: Флаги = 0, Длина = 5a

Точки распространения списков отзыва (CRL)

Точка распределения списка отзыва (CRL)

Имя точки распространения:

Полное имя:

URL=file://certserver/certsrv/trustca. crl

URL=http://www. *****/certsrv/trustca. crl

1.3.6.1.5.5.7.1.1: Флаги = 0, Длина = 72

Доступ к информации о центрах сертификации

Доступ к сведениям центра сертификации

Метод доступа=Поставщик центра сертификации (1.3.6.1.5.5.7.48.2)

Дополнительное имя:

URL=http://www. *****/certsrv/trustca. crt

Алгоритм подписи:

ObjectId алгоритма: 1.2.643.2.2.4 ГОСТ Р 34.11/34.10-94

Параметры алгоритма:

Подпись: НеиспользБит=0

0ea 5f b3 38 6a d5e4d4 e9 a3

0010 f8e8 9f 77 c8 ec 4e 87 7f 87 ffc

0020 c0 a9 73 f8 9ac0 3f cc 71 cb b6 77 b1 d6

0c7 be 70 e4 28 9c bf ec 98 b3 26 af 04 bc 15

Не корневой сертификат

Хеш сертификата (md5): 50 e2 adc5 fa 41 ad 5ee

Хеш сертификата (sha1): 0d befa 9f fb d1e 51 ce 0ee1 f2 44 4c

Проверка требования и результат

· Сертификат является сертификатом, соответствующим международным рекомендациям X.509, версии 3. Текстовый файл содержит строку «Сертификат X509». Поле «Версия» содержит значение, соответствующее требованиям п. 1.1.1, Приложения 3.

· Сертификат содержит поле «Серийный номер сертификата», соответствующее требованиям п. 1.1.2, Приложения 3.

· Сертификат содержит поле «Алгоритм подписи», соответствующее требованиям п. 1.1.3, Приложения 3.

· Сертификат содержит поле «Поставщик», соответствующее требованиям п. 1.1.4, Приложения 3.

· Сертификат содержит поле «Субъект», соответствующее требованиям п. 1.1.5, Приложения 3.

· Сертификат содержит поля «Действителен с» и «Действителен до», соответствующие требованиям п. п. 1.1.6-1.1.8, Приложения 3.

· Сертификат содержит поле «Алгоритм открытого ключа», соответствующее требованиям п. 1.1.9, Приложения 3.

· Сертификат содержит поле «Открытый ключ», соответствующее требованиям п. 1.1.10, Приложения 3.

· Поля «Алгоритм подписи» и «Алгоритм открытого ключа» соответствуют требованиям п. 1.1.11, Приложения 3.

· Сертификат содержит расширение «Идентификатор ключа субъекта», соответствующее требованиям п. 1.2.1, Приложения 3.

· Сертификат содержит расширение «Доступ к информации о центрах сертификации», соответствующее требованиям п. 1.2.2, Приложения 3.

· Сертификат содержит расширение «Точки распространения списков отзыва», соответствующее требованиям п. 1.2.3, Приложения 3.

· Сертификат содержит расширение «Использование ключа», с назначениями ключа: Цифровая подпись, Неотрекаемость, Шифрование ключей, Шифрование данных (f0).

· Сертификат содержит действительную цифровую подпись. При отображении сертификата операционной системой сообщения о недействительности подписи не появляются.

Проверка требования и результат

Установить СКП пользователей в программные средства. Произвести операции зашифровывания и подписания документа.

После зашифровывания сообщения должны расшифровываться, подпись должна проверяться.

8.4. Результаты проверки по разделу 8

Все обязательные требования из раздела 8 должны быть удовлетворены для получения Претендентом аккредитации в Сети ДУЦ.

Приложение 1

Примерный состав событий, регистрируемых программным комплексом обеспечения реализации целевых функций Претендента

ЦС должен регистрировать следующие основные события:

· установлено сетевое соединение с программной компонентой ЦР;

· издан СОС;

· принят запрос на сертификат ключа подписи;

· издан сертификат ключа подписи;

ЦР должен регистрировать следующие основные события:

· помещен запрос на регистрацию;

· принят запрос на регистрацию;

· отклонен запрос на регистрацию;

· помещен запрос на сертификат;

· принят запрос на сертификат;

· отклонен запрос на сертификат;

· установка сертификата подтверждена пользователем;

· помещен запрос на отзыв сертификата;

· принят запрос на отзыв сертификата;

· отклонен запрос на отзыв сертификата;

· помещен запрос на первый сертификат;

· запрошен список отозванных сертификатов;

· не выполнена внутренняя операция программной компоненты;

· установлено сетевое соединение с внешней программной компонентой;

· системные события общесистемного программного обеспечения.

Приложение 2

Примерный состав программных модулей,
подлежащих контролю целостности

· Программные модули средств электронной цифровой подписи.

· Программные модули ЦС.

· Программные модули ЦР.

· Программные модули АРМ Администратора ЦР.

Приложение 3

Требования к сертификатам ключей подписей и запросам на кросс-сертификат

Для включения в Сеть ДУЦ Претендент предоставляет в УЦ Организатора Сети ДУЦ следующие электронные документы:

· сертификат ключа подписи (СКП) уполномоченного лица (УЛ) УЦ;

· запрос на кросс-сертификат;

· закрытый ключ и СКП пользователя, изданный УЦ.

1. Требования к составу предоставляемого СКП

СКП представляет собой электронный сертификат, соответствующий международным рекомендациям X.509 версии 3, и содержит:

· стандартные поля сертификата версии 1;

· расширения сертификата;

· свойства сертификата;

· электронную цифровую подпись (ЭЦП) УЛ УЦ, выдавшего данный СКП.

1.1. Требования к составу и содержанию стандартных полей версии 1 сертификата

В состав стандартных полей версии 1 предоставляемого СКП входят следующие поля:

· поле «Версия»;

· поле «Серийный номер»;

· поле «Алгоритм подписи»;

· поле «Поставщик»;

· поле «Субъект»;

· поле «Действителен с »;

· поле «Действителен по »;

· поле «Открытый ключ».

1.1.1. Поле «Версия» должно содержать значение «3».

1.1.2. Поле «Серийный номер» должно содержать серийный номер СКП, уникальный в пределах серийных номеров всех сертификатов, выданных центром сертификации (ЦС) УЦ, издавшего предоставляемый СКП.

1.1.3. Поле «Алгоритм подписи» должно содержать OID алгоритма «1.2.643.2.2.3» (ГОСТ Р 34.11/34.10-2001) или «1.2.643.2.2.4» (ГОСТ Р 34.11/34.10-94).

1.1.4. Поле «Поставщик» должно содержать доменное имя УЦ, издателя сертификата. Доменное имя должно содержать компоненты доменного имени, определённые в международных рекомендациях X.501, и их значения.

1.1.5. Поле «Субъект» должно содержать доменное имя владельца предоставляемого сертификата. Доменное имя (DN) должно содержать следующие компоненты доменного имени:

· компонент «Общее имя» (CN, Common Name), содержащий фамилию, имя, отчество или псевдоним владельца сертификата;

· компонент «Неструктурированное Имя» или «ИНН» (UN, Unstructured Name, INN), содержащий ИНН организации (для юридических лиц) или владельца сертификата (для физических лиц);

· компонент «Неструктурированное Имя» (UN, Unstructured Name), содержащий КПП организации;

· компонент «Должность» (T, Title), содержащий должность владельца сертификата для юридических лиц;

· компонент «Подразделение» (OU, OrgUnit), содержащий подразделение организации владельца сертификата;

· компонент «Организация» (O, Organization), содержащий название организации владельца сертификата;

· компонент «Город» (L, Locality), содержащий название населённого пункта, в котором расположена организация владельца сертификата;

· компонент «Область/край» (S, State), содержащий название региона (при его наличии в почтовом адресе организации владельца сертификата);

· поле «Страна/регион» (С, Country), содержащее значение «RU»;

· поле «Электронная почта» (E, EMail), содержащее адрес электронной почты владельца сертификата.

1.1.6. Поле «Действителен с » должно содержать дату начала срока действия сертификата в формате UTC.

1.1.7. Поле «Действителен до » должно содержать дату истечения срока действия сертификата в формате UTC.

1.1.8. Срок действия сертификата должен уже наступить на момент предоставления СКП УЛ УЦ, а истечение срока действия должно наступить не ранее, чем через 12 месяцев с этого момента.

1.1.9. Поле «Алгоритм открытого ключа» должно содержать описание алгоритма открытого ключа; ГОСТ Р 34.11/34.10-2001 (OID 1.2.643.2.2.3) или ГОСТ Р 34.11/34.10-94 (OID 1.2.643.2.2.4).

1.1.10. Поле «Открытый ключ» должно содержать открытый ключ СКП, сформированный по алгоритму ГОСТ Р 34.11/34.10-2001 (OID 1.2.643.2.2.3) или по алгоритму ГОСТ Р 34.11/34.10-94 (OID 1.2.643.2.2.4).

1.1.11. Алгоритм подписи СКП (п. 1.1.3) должен соответствовать алгоритму формирования открытого ключа (п. 1.1.9).

1.2. Требования к составу и содержанию расширений сертификата

В состав расширений предоставляемого СКП должны входить следующие стандартные (по стандарту X.509) расширения:

· расширение «Идентификатор ключа субъекта»;

· расширение «Доступ к информации о центрах сертификации»;

· расширение «Точки распространения списков отзыва»;

· расширение «Основные ограничения»;

· расширение «Использование ключа».

1.2.1. Расширение «Идентификатор ключа субъекта» (OID 2.5.29.14) должно содержать значение идентификатора ключа субъекта.

1.2.2. Расширение «Доступ к информации о центрах сертификации» должно содержать описание адреса OCSP респондера (при его наличии) и (или) ссылку на ресурс, содержащий список издателей, составляющих путь сертификации для издателя СКП. Расширение должно быть указано как не критичное.

1.2.3. Расширение «Точки распространения списков отзыва» (OID 2.5.29.31) должно содержать:

· URL адрес действительной точки распространения списка отозванных сертификатов по протоколу «http»;

· URL адрес точки распространения списка отозванных сертификатов по протоколу «file».

Расширение должно быть указано как не критичное.

1.2.4. В СКП УЛ УЦ расширение «Основные ограничения» (OID 2.5.29.19) должно содержать поле «Тип субъекта» со значением «ЦС». Расширение должно быть указано как не критичное.

1.2.5. Расширение «Использование ключа» (OID 2.5.29.15) должно содержать следующие назначения ключа:

· цифровая подпись;

· неотрекаемость;

· шифрование ключей;

· шифрование данных;

· подписывание сертификатов *;

· автономное подписание списка отзыва *;

· подписывание списка отзыва (CRL)*.

Примечание * : только для СКП УЛ УЦ

Расширение должно быть указано как критичное.

1.2.6. В СКП пользователя расширение «Улучшенный ключ» (OID 2.5.29.37) должно содержать значение «Защищенная электронная почта» (1.3.6.1.5.5.7.3.4)

Расширение должно быть указано как не критичное.

Требования к ЭЦП сертификата

ЭЦП сертификата должна соответствовать открытому ключу сертификата.

2. Требования к составу запроса на кросс–сертификат уполномоченного лица УЦ

Запрос на кросс–сертификат УЛ кандидата на включение в Сеть ДУЦ должен содержать:

· поле «Субъект»;

· поле «Алгоритм открытого ключа»;

· поле «Открытый ключ»;

· поле «Запрос атрибутов».

2.1. Поле «Субъект» должно содержать доменное имя УЛ УЦ, владельца предоставляемого сертификата, соответствующее доменному имени указанному в СКП УЛ УЦ, как описано в п. 1.1.5.

2.2. Поле «Алгоритм открытого ключа» должно содержать OID алгоритма формирования открытого ключа СКП УЛ УЦ, со значением «1.2.643.2.2.3» (ГОСТ Р 34.11/34.10-2001) или «1.2.643.2.2.4» (ГОСТ Р 34.11/34.10-94).

2.3. Поле «Открытый ключ» должно содержать открытый ключ СКП сформированный по алгоритму ГОСТ Р 34.11/34.10-2001 (OID 1.2.643.2.2.3) или по алгоритму ГОСТ Р 34.11/34.10-94 (OID 1.2.643.2.2.4), соответствующий открытому ключу СКП УЛ УЦ.

2.4. Поле «Запрос атрибутов» должно содержать атрибут «Расширения сертификатов» (OID 1.3.6.1.4.1.311.2.1.14) со следующими расширениями:

· «Основные ограничения»;

· «Идентификатор ключа субъекта» (OID 2.5.29.14);

· «Использование ключа».

2.4.1. Расширение «Основные ограничения» (OID 2.5.29.19) должно содержать поле «Тип субъекта» со значением «ЦС» и поле «Ограничение на длину пути» co значением «1». Расширение должно быть указано как критичное.

2.4.2. Расширение «Идентификатор ключа субъекта» (OID 2.5.29.14) должно содержать значение идентификатора ключа субъекта, соответствующее значению идентификатора ключа субъекта, указанному в СКП УЛ УЦ (п. 1.2.1). Расширение должно быть указано как не критичное.

2.4.3. Расширение «Использование ключа» (OID 2.5.29.15) должно содержать назначения ключа, указанные в соответствующем расширении СКП УЛ УЦ (п. 1.2.5). Расширение должно быть указано как не критичное.

Приложение 4

Примерный перечень информации, подлежащей защите

Информация, передаваемая Претенденту, подлежащая защите:

1) заявление на регистрацию в электронной форме;

2) заявление на изготовление сертификата ключа подписи в электронной форме;

3) заявление на аннулирование (отзыв) сертификата ключа подписи в электронной форме;

4) заявление на приостановление действия сертификата ключа подписи в электронной форме;

5) заявление на возобновление действия сертификата ключа подписи в электронной форме;

6) пароль, передаваемый пользователем УЦ при аутентификации по паролю;

7) ключевая фраза пользователя УЦ.

Информация, передаваемая от Претендента, подлежащая защите:

1) пароль, передаваемый пользователю УЦ для аутентификации по паролю;

2) бланк копии сертификата ключа подписи для вывода на бумажный носитель;

3) список сертификатов ключей подписей пользователя УЦ и их статус;

4) список запросов на сертификаты ключей подписей пользователя УЦ и их статус;

5) список запросов на аннулирование (отзыв), приостановление и возобновление действия сертификатов ключей подписей пользователя УЦ и их статус.

Приложение 5

Просим рассмотреть Комплект заявительных документов (прилагается), подтверждающих выполнение требований к удостоверяющим центрам, в соответствии с «Положением о Сети Доверенных удостоверяющих центров системы “Электронная Торговая Площадка”».

Реквизиты Удостоверяющего центра

Приложение перечень (опись) предоставленных документов:

1. Название документа на _____ лист__.

2. Название документа на _____ лист__.

N. Название документа на _____ лист__.

Итого _________ листов.

Документы в электронном виде на ________________ (описание и количество носителей):

1. Название документа название файла .

2. Название документа название файла .

N. Название документа название файла .

Руководитель удостоверяющего

центра (наименование) _________________ (расшифровка подписи)

М. П. (подпись)

КонсультантПлюс: примечание.

Аккредитация удостоверяющих центров, полученная ими до 01.07.2020, действует до истечения срока, на который они были аккредитованы, но не более чем до 01.01.2022 (ФЗ от 27.12.2019 N 476-ФЗ).

Статья 16. Аккредитация удостоверяющего центра

1. Аккредитация удостоверяющих центров осуществляется уполномоченным федеральным органом в отношении удостоверяющих центров, являющихся юридическими лицами.

2. Аккредитация удостоверяющего центра осуществляется на добровольной основе. Аккредитация удостоверяющего центра осуществляется на срок пять лет, если более короткий срок не указан в заявлении удостоверяющего центра.

3. Аккредитация удостоверяющего центра осуществляется при условии выполнения им следующих требований:

1) стоимость чистых активов удостоверяющего центра составляет не менее чем семь миллионов рублей;

(см. текст в предыдущей редакции)

2) наличие финансового обеспечения ответственности за убытки, причиненные третьим лицам вследствие их доверия к информации, указанной в сертификате ключа проверки электронной подписи, выданном таким удостоверяющим центром, или информации, содержащейся в реестре сертификатов, который ведет такой удостоверяющий центр, в сумме не менее чем 30 миллионов рублей и 500 тысяч рублей за каждое место осуществления лицензируемого вида деятельности, указанное в лицензии федерального органа исполнительной власти в области обеспечения безопасности, выданной удостоверяющему центру в соответствии с пунктом 1 части 1 статьи 12 Федерального закона от 4 мая 2011 года N 99-ФЗ "О лицензировании отдельных видов деятельности", если количество таких мест превышает десять, но не более 100 миллионов рублей. Если количество мест осуществления указанного лицензируемого вида деятельности не превышает десять, финансовое обеспечение ответственности составляет 30 миллионов рублей;

(см. текст в предыдущей редакции)

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

(см. текст в предыдущей редакции)

4) наличие в штате удостоверяющего центра не менее двух работников, непосредственно осуществляющих деятельность по созданию и выдаче сертификатов ключей проверки электронных подписей, имеющих высшее образование в области информационных технологий или информационной безопасности либо высшее образование или среднее профессиональное образование с последующим получением дополнительного профессионального образования по вопросам использования электронной подписи;

(см. текст в предыдущей редакции)

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

3.1. Удостоверяющий центр наряду с указанными в части 3 настоящей статьи требованиями вправе также обеспечить свое соответствие установленным федеральным органом исполнительной власти в области обеспечения безопасности по согласованию с уполномоченным федеральным органом дополнительным требованиям к порядку реализации функций аккредитованного удостоверяющего центра и исполнения его обязанностей, а также к обеспечению информационной безопасности аккредитованного удостоверяющего центра в случаях, если необходимость соблюдения таких дополнительных требований в определенных отношениях предусмотрена федеральным законом.

4. Аккредитация удостоверяющего центра осуществляется на основании его заявления, подаваемого в уполномоченный федеральный орган. К заявлению прилагаются документы, подтверждающие соответствие удостоверяющего центра требованиям, установленным частью 3 настоящей статьи. Удостоверяющий центр вправе не представлять документ, подтверждающий соответствие имеющихся у него средств электронной подписи и средств удостоверяющего центра требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности, если такой документ или содержащиеся в нем сведения находятся в распоряжении федерального органа исполнительной власти в области обеспечения безопасности. В этом случае уполномоченный федеральный орган самостоятельно проверяет наличие документа, подтверждающего соответствие таких средств установленным требованиям, на основании информации, полученной от федерального органа исполнительной власти в области обеспечения безопасности, с использованием единой системы межведомственного электронного взаимодействия. Удостоверяющий центр вправе приложить документы, подтверждающие соответствие удостоверяющего центра требованиям, установленным частью 3.1 настоящей статьи.

(см. текст в предыдущей редакции)

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

(см. текст в предыдущей редакции)

6. Основанием для отказа в аккредитации удостоверяющего центра является его несоответствие требованиям, установленным частью 3 настоящей статьи, или наличие в представленных им документах недостоверной информации.

7. Аккредитованный удостоверяющий центр должен соблюдать требования, на соответствие которым он аккредитован, в течение всего срока его аккредитации. В случае возникновения обстоятельств, делающих невозможным соблюдение указанных требований, удостоверяющий центр немедленно должен уведомить об этом в письменной форме уполномоченный федеральный орган. Аккредитованный удостоверяющий центр при осуществлении своих функций и исполнении принятых обязательств должен соблюдать требования, установленные для удостоверяющих центров - , и настоящего Федерального закона. Уполномоченный федеральный орган вправе проводить проверки соблюдения аккредитованными удостоверяющими центрами требований настоящего Федерального закона и иных принимаемых в соответствии с настоящим Федеральным законом нормативных правовых актов, в том числе требований, на соответствие которым эти удостоверяющие центры были аккредитованы, в течение всего срока их аккредитации. В случае выявления несоблюдения аккредитованным удостоверяющим центром указанных требований уполномоченный федеральный орган обязан выдать этому удостоверяющему центру предписание об устранении нарушений в установленный срок и приостановить действие аккредитации на данный срок с внесением информации об этом в перечень, указанный в пункте 4 части 3 статьи 8 настоящего Федерального закона. Аккредитованный удостоверяющий центр уведомляет в письменной форме уполномоченный федеральный орган об устранении выявленных нарушений. Уполномоченный федеральный орган принимает решение о возобновлении действия аккредитации, при этом он вправе проверять фактическое устранение ранее выявленных нарушений и в случае их неустранения в установленный предписанием срок досрочно прекращает аккредитацию удостоверяющего центра.

(см. текст в предыдущей редакции)

7.1. Проверки соблюдения аккредитованными удостоверяющими центрами требований настоящего Федерального закона и иных принимаемых в соответствии с ним нормативных правовых актов проводятся один раз в три года в течение всего срока аккредитации, за исключением внеплановых проверок, проводимых в соответствии с законодательством Российской Федерации. Первая плановая проверка соблюдения аккредитованными удостоверяющими центрами указанных требований осуществляется не позднее одного года с даты аккредитации удостоверяющего центра, указанной в свидетельстве об аккредитации удостоверяющего центра.

7.2. Внеплановые проверки в рамках государственного контроля (надзора) и муниципального контроля осуществляются по основаниям, указанным в части 2 статьи 10 Федерального закона от 26 декабря 2008 года N 294-ФЗ "О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля", а также на основании мотивированных обращений о нарушениях требований настоящего Федерального закона и иных принимаемых в соответствии с ним нормативных правовых актов, допущенных аккредитованным удостоверяющим центром, которые поступили в уполномоченный федеральный орган от федеральных органов исполнительной власти, органов государственной власти субъектов Российской Федерации, иных государственных органов, органов местного самоуправления, Центрального банка Российской Федерации, органов государственных внебюджетных фондов, юридических и физических лиц.

8. На государственные органы, органы местного самоуправления, государственные и муниципальные учреждения, осуществляющие функции удостоверяющих центров, не распространяются требования, установленные пунктами 1 и 2 части 3 настоящей статьи.

9. Головной удостоверяющий центр, функции которого осуществляет уполномоченный федеральный орган, не подлежит аккредитации в соответствии с настоящим Федеральным законом.

Об аккредитации удостоверяющих центров. Удостоверяющие центры Проверка мер по хранению документированной информации

Обзор документа

Удостоверяющие центры в России

Хроника

2019

Как поправки в закон об электронной подписи изменили систему УЦ

Госдума вводит госмонополию на выдачу электронной подписи для юрлиц

2017

Минкомсвязь внесла в Правительство законопроект о проверке полномочий лица, использующего электронную подпись

Эксперты выступают против госмонополии на выдачу квалифицированной электронной подписи

2012: Приказ ФСБ о требованиях к средствам электронной подписи и УЦ

Первые УЦ для получения ЭП гражданами открылись в Москве

Требования

к удостоверяющим центрам при аккредитации

в системе «Электронная Торговая Площадка»

ГУП «Агентство по государственному заказу ,

инвестиционной деятельности и межрегиональным связям

Республики Татарстан »

1. Перечень сокращений

2. Термины и определения

3. Нормативные документы

6.3.3. Проверка программных и программно-аппаратных средств защиты информации

Для обеспечения защиты информации Претендент должен располагать необходимыми программными и программно-аппаратными средствами

6.3.4. Проверка программно-аппаратного комплекса резервного копирования Претендента

6.4. Результаты проверки по разделу 6

7. Проверка безопасности обрабатываемых в УЦ данных

7.1. Проверка инженерно-технических мер защиты информации

7.1.1. Проверка мер по размещению технических средств Претендента

Серверы ЦС и ЦР, серверы баз данных, серверы средств резервного копирования и телекоммуникационное оборудование должны размещаться в выделенном помещении

7.1.2. Проверка мер по хранению документированной информации

Документальный фонд Претендента, должен храниться в соответствии с действующим законодательством Российской Федерации по делопроизводству и архивному делу

7.1.3. Проверка мер по уничтожению документированной информации

7.2. Проверка программно-аппаратных мер защиты информации

7.2.2. Проверка мер по организации доступа к программным средствам Претендента

7.2.3. Проверка мер по контролю целостности программного обеспечения

Программное обеспечение, эксплуатируемое Претендентом, должно проходить контроль целостности

7.2.4. Проверка мер по контролю целостности технических средств

Претендент должен обеспечивать контроль целостности технических средств (Рекомендуемое требование)

7.2.5. Проверка мер по защите внешних сетевых соединений

Конфиденциальная информация в процессе обмена документами в электронной форме должна защищаться

7.2.6. Проверка мер по защите информации

Информация, поступающая Претенденту, должна быть защищена

7.3. Результаты проверки по разделу 7

8. Проверка технологической совместимости

8.1. Проверка сертификатов ключей подписей уполномоченного лица УЦ Претендента

8.2. Проверка запросов на кросс-сертификат

Претендент должен предоставить запрос на кросс-сертификат, соответствующий требованиям к запросам на кросс-сертификат

8.3. Проверка совместимости сертификатов ключей подписи, изданных УЦ Претендента, с программными средствами, используемыми в Системе

Сертификат должен являться сертификатом, соответствующим международным рекомендациям X.509, версии 3 и соответствовать требованиям, предъявляемым к сертификатам

8.4. Результаты проверки по разделу 8

Приложение 1

Приложение 2

Приложение 3

Приложение 4

Приложение 5

Формы и системы оплаты труда используемые строительно-монтажными организациями Виды и системы заработной платы в строительстве

Инженер по АСУ. Должностная инструкция. Инженер по автоматизированным системам управления производством Инженер автоматических систем управления

Увольнение в связи со смертью работника

Увольнение работников в связи с ликвидацией предприятия Ст 180 тк рф выплаты при увольнении

Рубрики