Удостоверяющий Центр RSA Keon Certificate Authority, Общее ... 6.5 White...

Удостоверяющий Центр RSA Keon Certificate Authority, Общее описание технологии

ii

Удостоверяющий Центр RSA Keon Certificate Authority,

Общее описание

03 марта 2003 г.

© Компания ДЕМОС, 2003

Россия, Москва, Овчинниковская наб. 6/1

Департамент Информационных Систем

Tел.: +7 (095) 956-6080 Факс: +7 (095) 956-5042 www.demos.su www.keon.ru

Copyright Демос, 2003. Ни одна часть документа не может быть воспроизведена или распространена в каких-либо формах и какими-либо методами, а также сохранена в базе данных или в поисковой

системе без предварительного письменного разрешения

http://www.demos.su/

http://www.keon.ru/

Общее описание технологии RSA Keon Advanced PKI

iii

Copyright Демос, 2003. Ни одна часть документа не может быть воспроизведена или распространена в каких-либо формах и какими-либо методами, а также сохранена в базе данных или в поисковой системе без предварительного письменного разрешения....................ii I. Введение..........................................................................................................................................4

II. Структуры Удостоверяющих Центров .................................................................................4

Архитектура Удостоверяющих Центров .........................................................................................4

Иерархическая модель.........................................................................................................................4

Сетевая (Peer-to-Peer) модель.............................................................................................................5

Гибридная модель................................................................................................................................5

III. Удостоверяющий Центр RSA Кеоn CA .................................................................................6

Сервер Администрирования ...............................................................................................................7

АРМ операций с сертификатами ......................................................................................................7

Проверка сертификата – Список Отозванных Сертификатов (Certificate Revocation List (CRL)).8 Проверка сертификата – Протокол проверки статуса сертификата в режиме он-лайн (Online Certificate Status Protocol (OCSP))........................................................................................................8

Проверка сертификата – Проверка статуса сертификата в режиме реального времени.............9

АРМ управления Удостоверяющим центром. ...................................................................................9

АРМ Конфигурирования системы. .....................................................................................................9

АРМ Сервера администрирования. ....................................................................................................9

Сервер регистрации пользователей (Enrollment Server) ..................................................................10

Сервер защищенных каталогов ........................................................................................................10

Сервер регистрации событий (Logging Server) ................................................................................10

Встроенная защита от сбоев ..........................................................................................................11

Центр регистрации (Registration Authority) RSA Keon ....................................................................11

Модуль восстановления ключей (Key Recovery Module)...................................................................12

RSA Keon WebSentry ..........................................................................................................................12

IV. Удостоверяющий Центр RSA Кеоn CA - Масштабируемость .......................................13

Дополнительная информация .....................................................................................................14

RSA Keon Certificate Authority - общее описание технологии

4

I. Введение RSA Keon Certificate Authority (CA) – ведущее на рынке решение по выпуску и управлению цифровыми сертификатами. Оно представляет собой полномасштабную систему, основанную на технологии PKI1 (Public Key Infrastructure – Инфраструктура Открытых Ключей) предоставляющую все элементы, необходимые для обеспечения схемы информационной безопасности – жесткую аутентификацию пользователя, конфиденциальность данных, сохранение их целостности и неотказуемость от факта обмена информацией.

II. Структуры Удостоверяющих Центров

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

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

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

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

1 Здесь и далее мы будем использовать аббревиатуры CA и PKI, руководствуясь теми же соображениями, по которым общепринятым сокращением термина “Интернет-Протокол” стала аббревиатура “IP”

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

Необходимо также определить архитектуру PKI. Если в создаваемой PKI предполагается использование более одного удостоверяющего центра, администратор должен решить - какую модель взаимодействия CA он будет применять – иерархическую, сетевую, или гибридную.

Иерархическая модель

В этой модели каждый последующий уровень Удостоверяющих центров подчинен предыдущему, который, в конечном итоге, подчинен главному (те. Первому) CA. Такой CA называется “корневым”, или “root”. Каждый CA, кроме корневого, имеет сертификат, подписанный CA, которому он непосредственно подчинен. Сертификат корневого


Гибридная модель

5

CA выпущен и подписан им самим, и называется “самоподписанным”. Такая архитектура PKI имеет фиксированную цепочку доверия и оптимальна с точки зрения безопасности Инфраструктуры открытых ключей. Она в минимальной степени зависит от человеческого фактора.

Сетевая (Peer-to-Peer) модель

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

Гибридная модель представляет собой комбинацию иерархической и сетевой архитектур CA.

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

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


6

III. Удостоверяющий Центр RSA Кеоn CA

Удостоверяющий Центр RSA Keon CA выпускает, управляет и проверяет цифровые сертификаты. Он представляет собой пакет программного обеспечения, который включает в себя четыре основные компоненты: • Сервер безопасного администрирования

(secure administration server), • Сервер регистрации пользователей (enrollment

server), • Сервер защищенных каталогов (directory

server), и • Сервер регистрации событий (logging server)

Keon CA является также мощным средством для подписывания сертификатов пользователей и системных событий, а также выполняет функцию интегрированного репозитария для хранения сертификатов, данных о системных событиях и информации о статусе сертификатов. Keon CА может публиковать списки в любой LDAP-совместимый каталог или внешнюю базу данных для хранения сертификатов, и имеет встроенный респондер, поддерживающий стандартный протокол онлайновой проверки статуса сертификатов (Online Certificate Status Protocol – OCSP).

С помощью решения Keon CA можно создать Удостоверяющий центр практически любого масштаба, или объединить существующие Удостоверяющие центры других производителей в

новую, более крупную инфраструктуру. Интерфейсы пользователей и администраторов просты и носят интуитивный характер, что позволяет значительно сократить время ввода в эксплуатацию. Так как RSA Keon CA основан на открытых стандартах, он совместим с подавляющим большинством индустриальных систем и приложений. RSA Keon CA может создавать и поддерживать сертификаты и их расширения, основанные на стандарте X.509. С декабря 2002 года KEON CA поставляется с поддержкой CSP разработанного компанией CryptoPro и имеющего сертификат ФАПСИ. Keon CA теперь при формировании ключей для цифровой подписи, генерации запросов на сертификаты, кросс-сертификации, а так же формирования списков отозванных сертификатов использует отечественные алгоритмы ГОСТ Р34.10, Р34.11, 28147-89.

Центральные компоненты Keon CA, - Сервер безопасного администрирования, Сервер регистрации пользователей, Сервер каталогов, и Сервер регистрации событий. Эти четыре сервера могут быть установлены и обычно устанавливаются на один компьютер. Сервер администрирования предназначен для администрирования самой инфраструктуры открытых ключей. Через Сервер регистрации пользователи запрашивают сертификаты. Данные о запросах на выдачу сертификатов, выданные сертификаты и списки контроля доступа (Access Control Lists - ACL) сохраняются в Службе Безопасных Каталогов (Secure Directory). Сервер регистрации событий


7

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

Удостоверяющий центр RSA Keon CA поддерживает все три модели PKI описанные выше. Кроме того, он позволяет изменять уже созданную инфраструктуру. Например, если в уже созданной иерархической модели необходимо вывести один CA из подчинения вышестоящему и перевести его в на горизонтальный уровень доверия (сетевая модель), этот CA должен просто подписать свой собственный сертификат – это выведет его из иерархии подчинения и придаст статус самоподписанного CA. Такая ситуация типична, например, при выделении части предприятия в самостоятельную компанию в рамках холдинга.

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

Сервер Администрирования

Для администрирования этого Сервера, администраторы PKI могут использовать любой Web-браузер, соединенный с Сервером по протоколу HTTPS. Таким способом администратор получает доступ к управлению основными функциями Удостоверяющего центра RSA Keon CA. Административный интерфейс разделен на четыре

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

АРМ операций с сертификатами

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

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

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


8

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

Проверка сертификата – Список Отозванных Сертификатов (Certificate Revocation List (CRL))

Удостоверяющий центр RSA Keon CA может использовать несколько способов проверки статуса сертификатов. Наиболее широко распространен метод проверки статуса сертификата по Списку Отозванных Сертификатов (CRL). Согласно такому подходу, списки отозванных сертификатов публикуются с определенной периодичностью. Приложение (например, Web-сервер), которому предъявлен сертификат, проверяет сначала, нет ли его в списке отозванных. Если сертификат находится в этом списке, запрос пользователя отклоняется. Если же сертификата в этом списке нет, приложение предполагает, что он действителен и предоставляет пользователю соответствующий доступ. Также Keon CA может публиковать только изменения в списках отозванных сертификатов (delta-CRL) и списков отозванных удостоверяющих центров (ARL).

Несмотря на то, что проверка статуса сертификата по CRL является наиболее распространенным способом, он имеет существенные недостатки. Так как всегда существует временной интервал между

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

Проверка сертификата – Протокол проверки статуса сертификата в режиме он-лайн (Online Certificate Status Protocol (OCSP))

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

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


9

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

Проверка сертификата – Проверка статуса сертификата в режиме реального времени.

Удостоверяющий центр RSA Keon CA дает возможность проверять сертификаты не только в он-лайновом режиме, но и в режиме реального времени. Реализация OCSP-респондера, осуществленная компанией RSA Security, позволяет запрашивать каталоги сертификатов, хранящиеся в Удостоверяющем центре напрямую, получая точную информацию о реальном статусе сертификата на момент запроса. Таким образом, пользователь лишается доступа к защищенному ресурсу сразу, как только его сертификат отозван.

АРМ управления Удостоверяющим центром.

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

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

Далее администратор устанавливает - с какими внешними или внутренними CA данный Центр будет находиться в доверительных отношениях. Здесь же администратор может определить уровень данного CA в общей иерархии – будет ли он корневым или займет подчиненное положение.

АРМ Конфигурирования системы.

Автоматизированное рабочее место конфигурирования системы предназначено для создания списков контроля доступа (Access Control Lists) и опций протоколирования системных событий (logging). Администратор определяет – какие именно действия и события должны протоколироваться. Здесь же устанавливаются режимы доступа к файлам и каталогам CA. Генерация ACL может производиться либо с помощью графического интерфейса который использует стандартный генератор правил для заполнения полей по ключевым словам, либо непосредственно с командной строки. После ввода эти правила будут определять условные или безусловные права доступа отдельных сертификатов или групп.

АРМ Сервера администрирования.

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

В CA Keon CA применен “ролевой” подход к администрированию PKI, позволяющий делегировать полномочия. Хорошим примером этого является то, что за процесс проверки и одобрения запроса пользователя на выдачу


10

сертификата отвечает группа администраторов, которой запрещен доступ к АРМ конфигурирования. Критически важную роль играет администратор всей Инфраструктуры открытых ключей – он отвечает за выпуск сертификатов для самих CA, других администраторов, в то время как у других администраторов таких прав нет.

Сервер регистрации пользователей (Enrollment Server)

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

Пользователь, который хочет стать клиентом CA, должен соединиться с Сервером регистрации с помощью web-браузера по протоколу HTTPS. Сервер регистрации предлагает пользователю заполнить и отослать специальный бланк, где он должен ввести данные о себе требуемые для рассмотрения запроса администратором CA. Во время заполнения бланка, на компьютере, либо смарт-карте либо смарт-токене генерится пара –секретный/открытый ключ. Открытый ключ передается Серверу регистрации для подписания Удостоверяющим центром в случае одобрения администратором. Следует отметить, что секретный ключ пользователя сохраняется на компьютере, смарт-карте или токене пользователя и никогда не передается по линиям связи. Полученный Удостоверяющим центром запрос пользователя обрабатывается администратором на сервере администрирования. В случае одобрения, пользователь получает автоматически сгенерированное почтовое сообщение, в котором указывается URL по которому пользователь может получить свой уже подписанный сертификат.

Сервер защищенных каталогов

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

На Сервере каталогов также располагается модуль, подписывающий сертификаты (signing engine). Правила доступа к нему определяются для каждого подсоединенного CA отдельно. Такой подход дает возможность адаптировать политику использования сертификатов к реальным бизнесс-процессам и облегчает масштабирование PKI.

Немаловажной особенностью Сервера каталогов является то, что он поддерживает так называемые Аппаратные модули ключевого хранения (Hardware Security Module - HSM). Взаимодействие между Сервером каталогов и HSM полностью интегрировано в Сервер каталогов. Обычно модули HSM используются для усиления защиты секретных ключей CA и как аппаратные ускорители процесса подписи сертификатов.

Сервер регистрации событий (Logging Server)

Все три сервера посылают информацию о произошедших событиях на Сервер регистрации. Какие события подлежат регистрации определяет администратор. Например, от Сервера администрирования может потребоваться чтобы он делал запись о каждом случае отзыва сертификата, а Сервер каталогов - о лице сделавшем запись в базу данных и о времени этой записи. Правила ведения журналов событий должны отражать требования организации к аудиту. Также предусмотрена возможность проверки аудитором целостности журналов и подписей в них. Аудитор является особым видом администратора Keon CA.


11

Он получает доступ к проверке и управлению журналами из административной консоли.

Встроенная защита от сбоев

Keon CA позволяет администраторам создать резервную копию Keon CA (только для систем Solaris 7 и 8), на которую возможно переключение при сбое в работе основной копии. Это позволяет продукту Keon CA быть частью системы от сбоев. При неисправности основной машины активизируется запасная копия, находящаяся в режиме ожидания.

Центр регистрации (Registration Authority) RSA Keon

Центр регистрации (ЦР) - опциональный модуль Удостоверяющего центра Keon CA. Он предназначен для обработки запросов на выдачу сертификатов и последующей выдачи сертификатов пользователям. ЦР можно представить себе как локальный или географически удаленный “вынос” Удостоверяющего центра. Он может быть необходим по целому ряду причин: - например, организация имеет один CA, но хочет обеспечить широкий географический охват пользователей. – политика безопасности организации, либо условия лицензии на деятельность CA требуют, чтобы оборудование и персонал CA находились в помещениях с повышенным уровнем защиты, куда доступ пользователям запрещен.

Центр регистрации Keon RA имеет ту же архитектуру и выполняет те же функции , что и CA, за тем лишь исключением, что он не может подписывать сертификаты пользователей. Запросы на выдачу сертификатов, полученные Центром регистрации, передаются на подпись Удостоверяющему центру. Одобренные сертификаты выдаются пользователю либо Удостоверяющим, либо его Регистрационным центром. Основным местом хранения сертификатов остается база данных CA, хотя копия выданного через ЦР сертификата может находиться и у него самого. Один Удостоверяющий центр может обслуживать несколько Центров регистрации, но каждый ЦР обрабатывает запросы только для единственного CA.

Архитектура Центра регистрации

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

Центр регистрации Keon RA позволяет построить Инфраструктуру открытых ключей, отражающую реальную структуру организации


12

Модуль восстановления ключей (Key Recovery Module)

Одно из распространенных применений PKI в рамках одной организации - шифрование (в том числе и групповое) данных на жестких дисках рабочих станций или корпоративных файловых серверах. Для этого пользователю нужна специально сгенерированная пара - секретный/открытый ключ, предназначенная для шифрования данных (в поле сертификата Key Usage установлено – dataEncipherment в отличие от шифрования при передаче по каналам связи - keyEncipherment).

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

Необходимость иметь возможность восстановления секретного ключа шифрования становится еще более актуальной, если принять во внимание, что законодательством ряда стран2, к организациям здравоохранения и финансовым институтам, например, предъявляются жесткие требования к длительности хранения и минимальному времени восстановления определенных данных. В этой ситуации необходимо с одной стороны выполнить требования законодательства, а с другой – обеспечить адекватный уровень защищенности. Модуль восстановления ключей (RSA Key recovery module – KRM) и создан для решения этой задачи.

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

2 Речь идет о западном законодательстве - нам не известно о существовании такого закона в Российской Федерации

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

Надо отметить, что наиболее безопасный способ сохранить ключи шифрования – это хранить их не на сервере, а в аппаратных средствах. В решении RSA Security для создания и хранения архива ключей шифрования применяются аппаратные модули nCipher. В модуле KRM ключи шифрования хранятся в зашифрованном виде, так что даже в случае компроментации средств защиты операционной системы, не создаст угрозу ключевой базе данных.

RSA Keon WebSentry

Обычно, для контроля доступа к своему Web–сайту или к определенным его областям, организации используют схему аутентификации основанную на IP-адресе, имени пользователя и его пароле. Мягко говоря, такая схема обеспечения безопасности, едва ли может считаться адекватной. IP-спуффинг и перехват паролей – весьма распространенные средства получения доступа к чужой информации. Плагин RSA Keon WebSentry расширяет возможности Web-сервера использовать сертификаты в качестве средства усиления аутентификации и является опциональной компонентой Удостоверяющего центра RSA Keon CA. WebSentry проверяет действительность сертификата пользователя каждый раз, когда он пытается получить доступ к Web-ресурсам. Такой подход является бескомпромисной схемой аутентификации пользователя. Наряду с этим, применение списков контроля доступа (ACL) однозначно определит - к каким ресурсам пользователь может быть допущен, а к каким - нет. Тщательно продуманная схема регистрации


13

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

IV. Удостоверяющий Центр RSA Кеоn CA - Масштабируемость

Одно из основных требований к Инфраструктуре открытых ключей - это ее способность поддерживать обширную базу данных пользователей без ущерба для производительности. Удостоверяющий центр RSA Keon CA прошел испытания в Центре iForce Ready Center Корпорации SUN Microsystem и показал способность обрабатывать более восьми миллионов сертификатов без сколь-нибудь заметного снижения производительности.

Общее описание технологии RSA Keon Advanced PKI Контакты

14

Дополнительная информация В случае необходимости в дополнительной информации, мы с удовольствием ответим на Ваш запрос. Наш контактный адрес:

Дегтярев Владимир Юрьевич Сахаров Василий Петрович ООО “Компания “Демос” 113035, Овчинниковская наб. 6/1., Москва, Россия,

Teл. : (095) 956-6080, 956-6289 Факс: (095) 956-5042, 953-5016 E-mail: [email protected]

mailto:[email protected]

Удостоверяющий Центр RSA Keon Certificate Authority, Общее ... 6.5 White...

Documents

Transcript of Удостоверяющий Центр RSA Keon Certificate Authority, Общее ... 6.5 White...