Разное

Центр сертификации ключей: Что такое центры сертификации и иерархии доверия?

22.10.1996

Содержание

Что такое центры сертификации и иерархии доверия?

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

Сертификат SSL — это популярный тип цифрового сертификата, который привязывает информацию о владельце веб-сервера (и веб-сайта) к ключу шифрования. Эти ключи используются в ючу шифрования. Эти ключи используются в протоколе SSL/TLS для создания безопасной сессии между браузером и веб-сервером, на котором расположен SSL-сертификат. Чтобы браузер мог доверять SSL-сертификату и выполнял сессию SSL/TLS без предупреждений безопасности, SSL-сертификат должен содержать доменное имя веб-сайта, использующего этот сертификат, должен быть выдан надежным центром сертификации и быть действующим.

По данным аналитического сайта Netcraft (www.netcraft.com), в августе 2012 года на общедоступных веб-сайтах использовались почти 2,5 млн SSL-сертификатов. Есть вероятность, что на самом деле их на 50% больше, но реальное число на общедоступных веб-сайтах Netcraft определить не в состоянии. Это делает SSL одной из самых распространенных технологий безопасности, применяемых в настоящее время.

Как при таком обилии SSL-сертификатов определить, какому центру сертификации можно доверять?

Браузеры, операционные системы и мобильные устройства используют авторизованные программы «членства» центров сертификации, и каждый центр сертификации должен выполнить подробные условия, чтобы быть стать участником такой программы. После принятия центра сертификации в программу он получает возможность выдавать SSL-сертификаты, которым будут доверять браузеры и, соответственно, люди и устройства, использующие этот сертификат. Существует относительно небольшое количество авторизованных центров сертификации, от частных до правительственных, и, как правило, чем дольше работает центр, тем больше браузеров и устройств доверяют его сертификатам. Чтобы сертификаты обеспечивали прозрачное доверие, они должны иметь хорошую совместимость с более старыми браузерами и особенно с более старыми мобильными устройствами — это называется универсальностью и является одной из важнейших характеристик, которые центр сертификации может предложить своим клиентам.

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

Более подробная информация о разных классах SSL-сертификатов содержится в статье: Классы сертификатов и примеры их использования.

PKI и иерархии доверия

Браузеры и устройства доверяют центру сертификации, принимая  корневой сертификат  в свое хранилище — специальную базу данных об утвержденных центрах сертификации, которая предустановлена в браузерах и на устройствах. Windows поддерживает свое хранилище корневых сертификатов, так же поступают Apple и Mozilla (для своего браузера Firefox). Многие операторы мобильной связи также имеют собственное хранилище.

Хранилище Apple OSX доверенных корневых сертификатов

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

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

Центры сертификации не должны выдавать цифровые сертификаты напрямую из корневого сертификата, передаваемого операторам, а только через один или несколько промежуточных центров сертификации (ICA). Центры сертификации обязаны выполнять рекомендации по безопасности чтобы свести к минимуму уязвимость корневого центра сертификации для хакерских атак. GlobalSign — один из немногих центров сертификации, которые всегда (с 1996 года) использовали ICA.

Что входит в работу центра сертификации?

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

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

Сертификаты и открытые ключи — Win32 apps

  • Статья
  • Чтение занимает 5 мин

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

  • Пара открытых и закрытых ключей
  • Запрос сертификата
  • Центр сертификации
  • Сертификат
  • Список отзыва сертификатов
  • Открытый ключ, используемый для шифрования
  • Открытый ключ, используемый для проверки подписи
  • Роль служб сертификатов Майкрософт

Пара открытых и закрытых ключей

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

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

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

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

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

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

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

Центр сертификации

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

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

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

Сертификат

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

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

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

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

Открытый ключ, используемый для шифрования

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

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

Обратите внимание, что основная часть перечисленных здесь действий обрабатывается программным обеспечением, а не непосредственно пользователем.

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

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

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

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

Роль служб сертификатов Майкрософт

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

 

 

Что такое центр сертификации (ЦС)?

Что такое центр сертификации (ЦС)?

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

Цифровой сертификат обеспечивает:
Аутентификацияслужа в качестве учетных данных для проверки личности объекта, которому он выдан.
Шифрование, для безопасной связи через незащищенные сети, такие как Интернет.
Целостность документов подписанный с сертификатом, чтобы они не могли быть изменены третьей стороной в пути.

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

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

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

Что такое цепочка доверия?

In SSL /TLS, S/MIME, подпись кодаи другие применения Сертификаты X.509иерархия сертификатов используется для проверки действительности издателя сертификата. Эта иерархия известна как цепь доверия, В цепочке доверия сертификаты выпускаются и подписываются сертификатами, которые находятся выше в иерархии.

A цепь доверия состоит из нескольких частей:

1. доверять якорь, который является исходным центром сертификации (CA).
2. По крайней мере, один промежуточный сертификат, служащая «изоляцией» между CA и сертификатом конечного объекта.
3. сертификат конечного объекта, который используется для проверки личности объекта, такого как веб-сайт, бизнес или лицо.

Легко увидеть цепочку доверия для себя, изучив HTTPS сертификат сайта. Когда ты проверка SSL /TLS сертификат в веб-браузере, вы найдете разбивку цепочки доверия этого цифрового сертификата, включая якорь доверия, любые промежуточные сертификаты и сертификат конечного объекта. Эти различные точки проверки подкрепляются действительностью предыдущего уровня или «ссылки», возвращающейся к доверительной привязке.

В приведенном ниже примере показана цепочка доверия от веб-сайта SSL. com, ведущая от сертификата веб-сайта конечного объекта обратно к корневому ЦС через один промежуточный сертификат:

Что такое якорь доверия?

Корень центр сертификации (CA) служит доверять якорь в цепочке доверия. Достоверность этого якоря доверия жизненно важна для целостности цепи в целом. Если CA публично доверенный (например, SSL.com), корневые сертификаты ЦС включаются крупными производителями программного обеспечения в свои браузеры и операционные системы. Это включение гарантирует, что сертификаты в цепочке доверия, ведущей обратно к любому из корневых сертификатов CA, будут доверять программному обеспечению.

Ниже вы можете увидеть якорь доверия с веб-сайта SSL.com (SSL.com EV Root Certification Authority RSA R2):

Что такое промежуточный сертификат?

Корневой ЦС или доверенный якорь могут подписывать и выдавать промежуточные сертификаты, Промежуточные сертификаты (также известные как промежуточный, подчиненный или выдающие CA) обеспечивают гибкую структуру для присвоения действительности якоря доверия дополнительным промежуточным и конечным сертификатам в цепочке. В этом смысле промежуточные сертификаты выполняют административную функцию; каждое промежуточное звено может использоваться для определенной цели — например, для выдачи SSL /TLS или сертификаты подписи кода — и даже могут быть использованы для совещаться доверие корневого центра сертификации к другим организациям.

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

В примере, показанном ниже, SSL.com EV SSL Intermediate CA RSA R3 является единственным промежуточным сертификатом в цепочке доверия веб-сайта SSL. com. Как следует из названия сертификата, он используется только для выдачи EV SSL /TLS сертификаты:

Что такое сертификат конечного объекта?

Игровой автомат сертификат конечного объекта является последним звеном в цепи доверия. Сертификат конечного объекта (иногда известный как листовой сертификат or сертификат абонента), служит для передачи доверия корневому центру сертификации через посредников в цепочке такой организации, как веб-сайт, компания, Правительствоили отдельное лицо.

Сертификат конечного объекта отличается от якоря доверия или промежуточного сертификата тем, что он не может выдавать дополнительные сертификаты. В каком-то смысле это последнее звено цепи. В приведенном ниже примере показан SSL /TLS сертификат с сайта SSL.com:

Почему цепочка доверия имеет значение?

Цепочка доверия обеспечивает безопасность, масштабируемость и соответствие стандартам для ЦС. Он также обеспечивает конфиденциальность, доверие и безопасность для тех, кто полагается на сертификаты конечных объектов, таких как операторы веб-сайтов и пользователи.

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

 

 

 

создание ЭЦП для централизованных учетных систем

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

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

Использование ЭЦП регулируется Федеральным законом от 06.04.2011 №63-ФЗ «Об электронной подписи» (далее – Закон №63-ФЗ). В соответствии с Законом №63-ФЗ электронная подпись может быть простой и усиленной. В свою очередь усиленная электронная подпись может быть:

  • усиленной неквалифицированной электронной подписью;
  • усиленной квалифицированной
    электронной подписью.

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

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

Для организации внутреннего документооборота между централизованной бухгалтерией и обслуживаемыми ею учреждениями возможно применение простой ЭЦП и усиленной неквалифицированной ЭЦП (далее – неквалифицированная ЭЦП). Выпуск и управление простыми и неквалифицированными ЭЦП возможен путем создания центра сертификации на уровне централизованной бухгалтерии (далее – локальный удостоверяющий центр). Такой удостоверяющий центр не подлежит аккредитации в соответствии с Законом №63-ФЗ.

Несмотря на отсутствие необходимости аккредитации, локальный удостоверяющий центр должен выполнять функции и обязанности, определенные ст. 13 Закона №63-ФЗ, а именно: 

Функции

Обязанности

Создание сертификатов ключей проверки электронных подписей и выдача таких сертификатов заявителям при условии идентификации заявителя

 

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

 

Определение сроков действия сертификатов ключей проверки электронных подписей

 

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

 

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

 

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

 

Выдача по обращению заявителя средства электронной подписи, содержащие ключ электронной подписи и ключ проверки электронной подписи

 

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

 

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

 

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

 

Определение порядка ведения реестра сертификатов, не являющихся квалифицированными, и порядок доступа к нему, а также обеспечение доступа лиц к информации, содержащейся в реестре сертификатов, в том числе с использованием информационно-телекоммуникационной сети «Интернет»

 

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

 

Создание по обращениям заявителей ключи электронных подписей и ключи проверки электронных подписей

 

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

 

Проверка уникальность ключей проверки электронных подписей в реестре сертификатов

 

Х

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

 

Х

Осуществление иной связанной с использованием электронной подписи деятельность.

 

Х


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

Но при этом следует учитывать, что удостоверяющий центр в соответствии с законодательством Российской Федерации несет ответственность за вред, причиненный третьим лицам в результате:

  • неисполнения или ненадлежащего исполнения обязательств, вытекающих из договора оказания услуг удостоверяющим центром;
  • неисполнения или ненадлежащего исполнения обязанностей, предусмотренных Законом №63-ФЗ.

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

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

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

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

  • создание электронной подписи;
  • проверка электронной подписи;
  • создание ключа электронной подписи и ключа проверки электронной подписи.

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

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

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

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

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

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

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

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

 

 

Основы криптографии — тест 12

Главная / Безопасность / Основы криптографии / Тест 12

Упражнение 1:

Номер 1

Для чего предназначен центр сертификации ключей?

Ответ:

&nbsp(1) для регистрации абонентов&nbsp

&nbsp(2) для изготовления сертификатов открытых ключей&nbsp

&nbsp(3) для выделения специальных каналов связи абонентам&nbsp

&nbsp(4) для хранения изготовленных сертификатов&nbsp

&nbsp(5) для поддержания в актуальном состоянии справочника действующих сертификатов&nbsp

&nbsp(6) для выпуска списка досрочно отозванных сертификатов&nbsp


Номер 2

Как называется структура в составе большой сети связи, занимающаяся генерированием ключей, их хранением и архивированием, заменой или изъятием из обращения старых и ненужных ключей?

Ответ:

&nbsp(1) устройство распределения ключей&nbsp

&nbsp(2) центр закрытого шифрования&nbsp

&nbsp(3) центр распределения ключей&nbsp

&nbsp(4) центр открытого шифрования&nbsp


Номер 3

Каким свойствами должен обладать сертификат открытого ключа?

Ответ:

&nbsp(1) каждый пользователь центра сертификации, имеющий доступ к открытому ключу центра, может извлечь открытый ключ, включенный в сертификат&nbsp

&nbsp(2) ни одна сторона, помимо центра сертификации, не может изменить сертификат так, чтобы это не было обнаружено&nbsp

&nbsp(3) любой пользователь системы может изменить сертификат&nbsp

&nbsp(4) каждый пользователь центра сертификации, имеющий доступ к открытому ключу центра, может изменить открытый ключ, включенный в сертификат&nbsp


Упражнение 2:

Номер 1

На чем основана безопасность алгоритма RSA для формирования цифровой подписи?

Ответ:

&nbsp(1) на трудности возведения целых чисел в степень по модулю&nbsp

&nbsp(2) на трудности вычисления дискретных логарифмов&nbsp

&nbsp(3) на трудности деления больших целых чисел&nbsp

&nbsp(4) на трудности решения задачи факторизации&nbsp


Номер 2

На чем основана безопасность алгоритма Эль-Гамаля для формирования цифровой подписи?

Ответ:

&nbsp(1) на трудности возведения целых чисел в степень по модулю&nbsp

&nbsp(2) на трудности вычисления дискретных логарифмов&nbsp

&nbsp(3) на трудности деления больших целых чисел&nbsp

&nbsp(4) на трудности решения задачи факторизации&nbsp


Номер 3

Подписи, созданные с использованием стандарта ГОСТ Р3410-94, являются рандомизированными, так как …

Ответ:

&nbsp(1) для одинаковых сообщений с использованием разных закрытых ключей каждый раз будут создаваться разные подписи&nbsp

&nbsp(2) для одинаковых сообщений с использованием одного и того же закрытого ключа каждый раз будут создаваться разные подписи&nbsp

&nbsp(3) для разных сообщений с использованием разных закрытых ключей каждый раз будут создаваться разные подписи&nbsp

&nbsp(4) для разных сообщений с использованием одного и того же закрытого ключа каждый раз будут создаваться разные подписи&nbsp


Упражнение 3:

Номер 1

На чем основана безопасность алгоритма для формирования цифровой подписи по стандарту ГОСТ Р3410-94?

Ответ:

&nbsp(1) на трудности возведения целых чисел в степень по модулю&nbsp

&nbsp(2) на трудности вычисления дискретных логарифмов&nbsp

&nbsp(3) на трудности деления больших целых чисел&nbsp

&nbsp(4) на трудности решения задачи факторизации&nbsp


Номер 2

Каков российский стандарт на алгоритм формирования электронной цифровой подписи?

Ответ:

&nbsp(1) ГОСТ 28147-89&nbsp

&nbsp(2) ГОСТ Р3410-94&nbsp

&nbsp(3) ГОСТ Р3410-2001&nbsp

&nbsp(4) ГОСТ 3411-94&nbsp

&nbsp(5) MD5&nbsp

&nbsp(6) SHA-1&nbsp

&nbsp(7) DSS&nbsp


Номер 3

В основу стандарта ГОСТ Р3410-94 положен

Ответ:

&nbsp(1) асимметричный алгоритм шифрования, основанный на сложности вычисления дискретных логарифмов&nbsp

&nbsp(2) асимметричный алгоритм шифрования, основанный на элиптических кривых&nbsp

&nbsp(3) алгоритм выработки имитовставки&nbsp

&nbsp(4) симметричный алгоритм шифрования&nbsp


Упражнение 4:

Номер 1

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3 Найдите открытый ключ абонента Петрова и вычислите его цифровую подпись для Х = 3, k = 9, m = 5

Ответ:

&nbsp(1) Y=11, a=14, b=3&nbsp

&nbsp(2) Y=10, a=14, b=3&nbsp

&nbsp(3) Y=11, a=13, b=3&nbsp

&nbsp(4) Y=10, a=13, b=3&nbsp


Номер 2

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3 Найдите открытый ключ абонента Петрова и вычислите его цифровую подпись для Х = 5, k = 9, m = 7

Ответ:

&nbsp(1) Y=4, a=14, b=9&nbsp

&nbsp(2) Y=4, a=13, b=9&nbsp

&nbsp(3) Y=5, a=14, b=9&nbsp

&nbsp(4) Y=5, a=13, b=9&nbsp


Номер 3

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3 Найдите открытый ключ абонента Петрова и вычислите его цифровую подпись для Х = 3, k = 7, m = 11

Ответ:

&nbsp(1) Y=10, a=11, b=6&nbsp

&nbsp(2) Y=11, a=12, b=6&nbsp

&nbsp(3) Y=10, a=12, b=6&nbsp

&nbsp(4) Y=11, a=11, b=6&nbsp


Упражнение 5:

Номер 1

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3 Найдите открытый ключ абонента Петрова для Х = 11 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp7&nbsp


Номер 2

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3 Найдите открытый ключ абонента Петрова для Х = 13 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp12&nbsp


Номер 3

Абоненты некоторой сети применяют цифровую подпись по алгоритму Эль-Гамаля с общими параметрами Р = 17, А = 3.  Найдите открытый ключ абонента Петрова для Х = 15. В качестве ответа укажите числовое значение Y.

Ответ:

&nbsp6&nbsp


Упражнение 6:

Номер 1

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 23, q = 11, a = 9 Найдите открытый ключ абонента Петрова для Х = 10 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp18&nbsp


Номер 2

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 23, q = 11, a = 13 Найдите открытый ключ абонента Петрова для Х = 10 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp16&nbsp


Номер 3

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 47, q = 23, a = 17 Найдите открытый ключ абонента Петрова для Х = 8 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp4&nbsp


Упражнение 7:

Номер 1

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 47, q = 23, a = 37 Найдите открытый ключ абонента Петрова для Х = 8 В качестве ответа укажите числовое значение Y

Ответ:

&nbsp27&nbsp


Номер 2

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 47, q = 23, a = 2 Найдите открытый ключ абонента Петрова и вычислите его цифровую подпись для Х = 8, k = 7, h = 10

Ответ:

&nbsp(1) Y = 20, r = 11, s = 20&nbsp

&nbsp(2) Y = 21, r = 11, s = 20&nbsp

&nbsp(3) Y = 20, r = 11, s = 21&nbsp

&nbsp(4) Y = 21, r = 11, s = 21 &nbsp


Номер 3

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 47, q = 23, a = 3 Найдите открытый ключ абонента Петрова и вычислите его цифровую подпись для Х = 8, k = 7, h = 10

Ответ:

&nbsp(1) Y = 28, r = 11, s = 13&nbsp

&nbsp(2) Y = 28, r = 13, s = 11&nbsp

&nbsp(3) Y = 28, r = 2, s = 17&nbsp

&nbsp(4) Y = 28, r = 2, s = 11&nbsp


Упражнение 8:

Номер 1

Абоненты некоторой сети применяют цифровую подпись по стандарту ГОСТ Р3410-94 с общими параметрами p = 47, q = 23, a = 7.  Найдите открытый ключ абонента. Петрова и вычислите его цифровую подпись для Х = 8, k = 7, h = 10.

Ответ:

&nbsp(1) 16, r = 21, s = 16&nbsp

&nbsp(2) 16, r = 21, s = 6&nbsp

&nbsp(3) 16, r = 9, s = 6&nbsp

&nbsp(4) 16, r = 9, s = 4&nbsp


Номер 2

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

Ответ:

&nbsp(1) подпись воспроизводится многими лицами, а ее подлинность может быть удостоверена только одним лицом&nbsp

&nbsp(2) подпись воспроизводится только одним лицом, а подлинность ее может быть удостоверена многими&nbsp

&nbsp(3) подпись неразрывно связывается с данным сообщением и не может быть перенесена на другой документ&nbsp

&nbsp(4) подпись не связывается с конкретным сообщением и может быть перенесена на другой документ&nbsp


Номер 3

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

Ответ:

&nbsp(1) после того, как документ подписан, его можно изменять&nbsp

&nbsp(2) подпись неразрывно связывается с данным сообщением и не может быть перенесена на другой документ&nbsp

&nbsp(3) подпись не связывается с конкретным сообщением и может быть перенесена на другой документ&nbsp

&nbsp(4) после того, как документ подписан, его невозможно изменить&nbsp


Номер 4

Отметьте верные утверждения относительно электронной цифровой подписи:

Ответ:

&nbsp(1) подпись воспроизводится многими лицами, а ее подлинность может быть удостоверена только одним лицом&nbsp

&nbsp(2) От поставленной подписи невозможно отказаться, то есть лицо, подписавшее документ, не сможет потом утверждать, что не ставило подпись&nbsp

&nbsp(3) подпись не связывается с конкретным сообщением и может быть перенесена на другой документ&nbsp

&nbsp(4) подпись неразрывно связывается с данным сообщением и не может быть перенесена на другой документ&nbsp


Главная / Безопасность / Основы криптографии / Тест 12

Частный центр сертификации – AWS Certificate Manager – Amazon Web Services (AWS)

ACM Private CA – это сервис для создания частного центра сертификации с высокой доступностью, не требующий предварительных инвестиций и текущих расходов на обслуживание при эксплуатации. AWS Certificate Manager (ACM) Private Certificate Authority (CA) – это сервис для создания частного ЦС, который предоставляет расширенные возможности ACM в сфере управления как публичными, так и частными сертификатами.  ACM Private CA обеспечивает повышенную гибкость для разработчиков, предоставляя API для создания и развертывания частных сертификатов программными средствами. Дополнительно предоставляется возможность создавать частные сертификаты для приложений, требующих специальных настроек жизненного цикла сертификата или имен ресурсов. Частный ЦС ACM является безопасным управляемым сервисом частного ЦС с оплатой по факту использования. С его помощью можно создавать частные сертификаты для подключенных ресурсов и управлять ими.

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

 

AWS Summit 2018 в Сан‑Франциско – AWS Certificate Manager Private Certificate Authority

Преимущества

Безопасный управляемый частный центр сертификации

Частный ЦС ACM предоставляет простой и безопасный способ создания частного центра сертификации и его использования для выпуска частных сертификатов и управления ими. Защита частного ЦС ACM обеспечивается управляемыми AWS аппаратными модулями безопасности (HSM). Эти модули HSM соответствуют стандартам безопасности FIPS 140‑2 и обеспечивают безопасное хранение ключей частного ЦС. Администраторы Private CA могут управлять доступом к сервису с помощью политик AWS Identity and Access Management (IAM). Вы можете предоставить доступ к ЦС с помощью AWS Resource Access Manager (RAM) специально для выдачи сертификатов, поручив администрирование ЦС администраторам. ACM Private CA обеспечивает наглядное представление всех операций, связанных с частными сертификатами, и дает возможность создавать отчеты. Аудит использования частного ЦС можно проводить с помощью сервиса для ведения журналов и мониторинга AWS CloudTrail. Частный ЦС ACM также автоматически публикует и обновляет списки отозванных сертификатов (CRL) в Amazon S3, чтобы предотвратить использование отозванных сертификатов. К примеру, приложение IoT, прежде чем принимать данные от того или иного датчика, может проверить, действителен ли частный сертификат этого датчика.

Централизованное управление центрами сертификации

Вы можете создавать частные ЦС ACM и управлять ими с помощью одного аккаунта, а затем предоставлять доступ к ним другим аккаунтам AWS, которые должны выдавать сертификаты. С помощью AWS Resource Access Manager – сервиса AWS, который дает возможность предоставлять доступ к ресурсам AWS любому аккаунту AWS или всем пользователям в организации AWS, – клиенты могут определять общие хранилища ресурсов, содержащие ЦС, доступ к которым предоставляется определенным наборам аккаунтов или организаций. Отчет об аудите ЦС содержит сведения обо всех сертификатах, выданных из этого ЦС. Каждый аккаунт, которому предоставлен доступ к ЦС, может либо создавать и выдавать сертификаты с помощью AWS Certificate Manager, либо вызывать ЦС напрямую для подписания запросов на подписание сертификатов (CSR).

Полные иерархии ЦС

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

Гибкие возможности для разработчиков

ACM Private CA дает возможность быстро создавать и развертывать сертификаты с помощью нескольких вызовов API, команд CLI или шаблонов AWS CloudFormation. При использовании ACM Private CA администраторы ЦС могут делегировать выдачу частных сертификатов разработчикам, разрешив им запрашивать сертификаты у частных ЦС, доступных соответствующим аккаунтам AWS. С помощью этого сервиса также можно автоматизировать создание сертификатов в тех случаях, когда требуется много краткосрочных сертификатов. Например, можно автоматически создавать и развертывать сертификаты для идентификации новых инстансов EC2 и контейнеров в средах с автомасштабированием или для аутентификации оповещений о событиях, отправленных из функций AWS Lambda.

Гибкость настройки частных сертификатов

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

Оплата по факту использования

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

Возможности

Центр сертификации, управляемый AWS

Частный ЦС ACM – это управляемый сервис, который автоматизирует трудоемкие административные задачи, такие как выделение оборудования, исправление программного обеспечения, обеспечение высокой доступности и резервное копирование. Частный ЦС ACM обеспечивает безопасность, настройку и мониторинг высокодоступного частного ЦС, а также управление им. В частном ЦС ACM есть возможность выбора из нескольких алгоритмов формирования ключей ЦС и размеров ключей, включая RSA 2048 или 4096 и ECDSA P256 или P384. ACM также упрощает экспорт и развертывание частных сертификатов в любом месте с использованием автоматизации на основе API.

Интегрированные средства управления жизненным циклом сертификатов

С помощью ACM Private CA можно делегировать сервису ACM управление сертификатами, которые используются в интегрированных с ACM сервисах, таких как Elastic Load Balancing и API Gateway. Создавать и развертывать частные сертификаты можно с помощью простых действий в Консоли управления AWS или вызовов API AWS. ACM может автоматизировать обновление и развертывание таких сертификатов. Частный ЦС ACM также предоставляет API, с помощью которых можно автоматизировать создание и обновление частных сертификатов для локальных ресурсов, инстансов EC2 и устройств IoT. Частный ЦС ACM обеспечивает гибкость самостоятельного управления частными сертификатами без использования возможностей сервиса ACM.

Безопасный корневой ЦС и управление иерархией ЦС

Иерархия частных ЦС ACM обеспечивает высокую безопасность и возможность ограничения доступа для наиболее доверенных корневых ЦС на верхнем уровне цепи доверия, в то же время предоставляя больше прав доступа и возможность пакетной выдачи сертификатов подчиненным ЦС на более низких уровнях цепи. Можно контролировать, какие пользователи могут создавать новые ЦС или ограничивать доступ к существующим ЦС с помощью политик AWS Identity and Access Management (IAM). Все частные ЦС ACM в иерархии обеспечивают защиту закрытых ключей ЦС в соответствии со стандартом FIPS 140-2 для оборудования.

Безопасное хранилище для ключей ЦС на базе аппаратных модулей HSM

Ключи, используемые центром сертификации для подписи сертификатов, строго конфиденциальны. Частный ЦС ACM обеспечивает безопасность ключей ЦС с помощью управляемых AWS аппаратных модулей безопасности, также известных как HSM. Эти модули HSM соответствуют стандартам безопасности FIPS 140‑2, что помогает защитить частный ЦС клиента от компрометации ключей. Подробные сведения о стандарте FIPS 140-2 для оборудования указаны в документации частного ЦС.

Интеграция с IAM

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

Отзыв сертификата с помощью CRL и OCSP

При установлении зашифрованного TLS-соединения инфраструктура отзыва информирует адрес о том, что сертификату не следует доверять. Клиенты частного ЦС могут выбрать протокол Online Certificate Status Protocol (OCSP), списки отзыва сертификатов (CRL) или оба варианта для информирования об отзыве своих частных сертификатов.

Доступ к ЦС из нескольких аккаунтов

Совместный доступ к ЦС во всей организации или из нескольких аккаунтов AWS помогает сократить расходы и избежать необходимости создания дубликатов ЦС для всех аккаунтов AWS и управления ими. С помощью AWS Resource Access Manager (RAM) можно создавать общие хранилища ресурсов, которые включают частные ЦС ACM и связаны с набором аккаунтов или сервисом AWS Organizations. При этом соответствующие аккаунты смогут выдавать частные сертификаты из общего ЦС. Частные сертификаты, выдаваемые из общего ЦС при помощи AWS Certificate Manager, создаются в локальной среде аккаунта, отправившего запрос, а ACM обеспечивает полное управление жизненным циклом и продление срока действия сертификатов.

Настройка

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

Аудит и ведение журналов

Частный ЦС ACM предоставляет вам и вашим аудиторам возможность просмотра всех операций, связанных с частными ЦС. В целях аудита можно создавать отчеты, которые включают статус всех сертификатов, выпущенных ЦС. Частный ЦС ACM интегрирован с AWS CloudTrail. CloudTrail фиксирует вызовы API, выполненные в консоли частного ЦС ACM, интерфейсе командной строки или программном коде, и сохраняет файлы журналов в соответствующую корзину S3. Используя информацию, собранную сервисом CloudTrail, можно определить, какой запрос был совершен, с какого IP‑адреса он поступил, когда это произошло и т.  д.

Автоматизация на основе API

Для автоматизации управления сертификатами можно написать код на любом языке программирования, используя API ACM Private CA и API ACM. Пакеты SDK AWS упрощают аутентификацию и эффективно интегрируются с используемой средой разработки. Вы также можете писать скрипты или отдельные команды для взаимодействия с сервисом при помощи инструментов командной строки.

Помощь в соответствии требованиям

Упрощая использование SSL/TLS, AWS Certificate Manager помогает организациям обеспечить соответствие нормативным требованиям и другим стандартам в отношении шифрования данных при передаче. Подробную информацию о соответствии требованиям см. в разделе Соответствие облака AWS нормативным требованиям.

Увеличение времени безотказной работы

AWS Certificate Manager помогает справиться с проблемами обслуживания сертификатов SSL/TLS, включая продление их срока действия. Вам больше не придется беспокоиться о просроченных сертификатах.

Избранный клиент

Arctic Wolf Networks (AWN) – ведущий в отрасли поставщик SOC (операционного центра защиты) как услуги, предлагающий в круглосуточном режиме и без выходных мониторинг, управляемое обнаружение угроз и реагирование на них для локальных и облачных приложений и инфраструктуры. Мы используем частный центр сертификации (ЦС) ACM для выдачи сертификатов, чтобы обеспечить безопасные подключения от наших датчиков к нашей специальной платформе операционного центра защиты, работающей в AWS. Частный ЦС ACM надежен и безопасен, мы можем интегрировать его в свою инфраструктуру с помощью привычных API AWS.

Майкл Харт, директор по разработке инфраструктуры, Artic Wolf

Примеры использования

Протокол TLS для сервисов AWS

Благодаря AWS Certificate Manager можно быстро запросить сертификат и выполнить его развертывание с помощью таких интегрированных с ACM ресурсов AWS, как балансировщики нагрузки сервиса Elastic Load Balancing, базы раздачи Amazon CloudFront или API в Amazon API Gateway. После этого можно поручить сервису AWS Certificate Manager обновление сертификатов. Частные сертификаты используются для идентификации и защиты соединений между подключенными ресурсами (например, серверами, мобильными устройствами, устройствами IoT, приложениями) в частных сетях.

ACM поддерживает запрос сертификатов из AWS Private CA и управляет жизненным циклом ваших частных сертификатов, как связывая их с ресурсами AWS, так и экспортируя для использования вне AWS. Подробную информацию см. в Начало работы с AWS Certificate Manager.

Протокол TLS для Kubernetes

Контейнеры и приложения Kubernetes используют цифровые сертификаты для обеспечения безопасной аутентификации и шифрования по протоколу TLS. cert-manager – это дополнение к Kubernetes, которое управляет сертификатами TLS. Оно запрашивает сертификаты, распределяет их по контейнерам Kubernetes и автоматизирует их обновление сертификатов. cert-manager гарантирует актуальность и подлинность сертификатов и предлагает обновление до истечения срока действия.

AWS Private CA поддерживает подключаемый модуль с открытым исходным кодом для cert-manager и предлагает более безопасный центр сертификации для контейнеров Kubernetes. Клиенты, использующие cert-manager для управления жизненным циклом сертификатов приложений, с помощью этого решения могут обеспечить более высокий уровень безопасности. В отличие от центра сертификации cert-manager по умолчанию, хранящего ключи в виде открытого текста в памяти сервера. Клиенты с нормативными требованиями к контролю доступа и проверке операций в ЦС, могут использовать это решение, чтобы сделать лучше возможности проверки и обеспечить соответствие требованиям. Вы можете использовать подключаемый модуль AWS Private CA Issuer с сервисом Amazon Elastic Kubernetes, самостоятельно управляемым Kubernetes на AWS и локальным Kubernetes. Подробную информацию см. в документации Private CA для настройки с Kubernetes. 

Подробнее о том, как начать работу

Начало работы с AWS Certificate Manager

Подробнее 

Зарегистрировать бесплатный аккаунт

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

Регистрация 

Начните разработку в консоли

Начните разработку с использованием AWS Certificate Manager в Консоли AWS.

Войти 

Вход в Консоль

Подробнее об AWS

  • Что такое AWS?
  • Что такое облачные вычисления?
  • Инклюзивность, многообразие и равенство AWS
  • Что такое DevOps?
  • Что такое контейнер?
  • Что такое озеро данных?
  • Безопасность облака AWS
  • Новые возможности
  • Блоги
  • Пресс‑релизы

Ресурсы для работы с AWS

  • Начало работы
  • Обучение и сертификация
  • Портфолио решений AWS
  • Центр архитектурных решений
  • Вопросы и ответы по продуктам и техническим темам
  • Отчеты аналитиков
  • Партнерская сеть AWS

Разработчики на AWS

  • Центр разработчика
  • Пакеты SDK и инструментарий
  • . NET на AWS
  • Python на AWS
  • Java на AWS
  • PHP на AWS
  • JavaScript на AWS

Поддержка

  • Связаться с нами
  • Работа в AWS
  • Обратиться в службу поддержки
  • Центр знаний
  • AWS re:Post
  • Обзор AWS Support
  • Юридическая информация

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

Поддержка AWS для Internet Explorer заканчивается 07/31/2022. Поддерживаемые браузеры: Chrome, Firefox, Edge и Safari. Подробнее »

Что такое центр сертификации (ЦС)?

Что такое ЦС?

Что такое центр сертификации (ЦС)?

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

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

Как правило, заявитель на цифровой сертификат создает 9Пара ключей 0005 , состоящая из закрытого ключа и открытого ключа вместе с запросом подписи сертификата (CSR) . CSR — это закодированный текстовый файл, который включает открытый ключ и другую информацию, которая будет включена в сертификат (например, доменное имя, организацию, адрес электронной почты и т. д.). Генерация пары ключей и CSR обычно выполняется на сервере или рабочей станции, где будет установлен сертификат, а тип информации, включенной в CSR, зависит от уровня проверки и предполагаемого использования сертификата. В отличие от открытого ключа, закрытый ключ заявителя хранится в безопасности и никогда не должен показываться ЦС (или кому-либо еще).

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

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

Что такое цепочка доверия?

В SSL/TLS, S/MIME, подписи кода и других приложениях сертификатов X. 509 иерархия сертификатов используется для проверки действительности издателя сертификата. Эта иерархия известна как цепочка доверия . В цепочке доверия сертификаты выдаются и подписываются сертификатами, которые находятся выше в иерархии.

Цепочка доверия состоит из нескольких частей:

1. Якорь доверия , который является исходным центром сертификации (ЦС).
2. Как минимум один промежуточный сертификат , служащий «изоляцией» между ЦС и сертификатом конечного объекта.
3. Сертификат конечного объекта , который используется для проверки подлинности объекта, такого как веб-сайт, предприятие или физическое лицо.

Легко увидеть цепочку доверия, проверив сертификат веб-сайта HTTPS. Когда вы проверяете сертификат SSL/TLS в веб-браузере, вы обнаружите разбивку цепочки доверия этого цифрового сертификата, включая якорь доверия, любые промежуточные сертификаты и сертификат конечного объекта. Эти различные точки проверки подкрепляются достоверностью предыдущего уровня или «ссылки», восходящей к якорю доверия.

В приведенном ниже примере показана цепочка доверия от веб-сайта SSL.com, ведущая от сертификата конечного веб-сайта обратно к корневому ЦС через один промежуточный сертификат:

Что такое якорь доверия?

Корневой центр сертификации (ЦС) служит якорем доверия в цепочке доверия. Действительность этого якоря доверия жизненно важна для целостности цепочки в целом. Если ЦС является общедоступным доверенным (например, SSL.com), сертификаты корневого ЦС включаются крупными компаниями-разработчиками программного обеспечения в свои браузеры и программное обеспечение операционной системы. Это включение гарантирует, что сертификаты в цепочке доверия, ведущей к любому из корневых сертификатов ЦС, будут доверенными для программного обеспечения.

Ниже вы можете увидеть якорь доверия с веб-сайта SSL.com ( SSL.com EV Root Certification Authority RSA R2 ):

Что такое промежуточный сертификат?

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

Промежуточные сертификаты также обеспечивают буфер между сертификатом конечного объекта и корневым ЦС, защищая закрытый корневой ключ от компрометации. Для общедоступных доверенных центров сертификации (включая SSL.com) базовые требования форума CA/Browser фактически запрещают выдачу сертификатов конечного объекта непосредственно из корневого центра сертификации, который должен безопасно храниться в автономном режиме. Это означает, что цепочка доверия любого публично доверенного сертификата будет включать как минимум один промежуточный сертификат.

В приведенном ниже примере SSL.com EV SSL Intermediate CA RSA R3 — единственный промежуточный сертификат в цепочке доверия веб-сайта SSL.com. Как следует из названия сертификата, он используется только для выдачи сертификатов EV SSL/TLS:

Что такое сертификат конечного объекта?

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

Сертификат конечного объекта отличается от сертификата якоря доверия или промежуточного сертификата тем, что он не может выдавать дополнительные сертификаты. Это, в некотором смысле, последнее звено в цепи. В приведенном ниже примере показан сертификат конечного объекта SSL/TLS с веб-сайта SSL.com:

Почему важна цепочка доверия?

Цепочка доверия обеспечивает безопасность, масштабируемость и соответствие стандартам ЦС. Он также обеспечивает конфиденциальность, доверие и безопасность для тех, кто полагается на сертификаты конечного объекта, например для операторов веб-сайтов и пользователей.

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

 

 

 

Часто задаваемые вопросы