Практика построения PUBLIC KEY INFRASTRUCTURE, PKI

 

С. А. Петренко,

руководитель направления

«Безопасность компьютерных

систем» ООО «Конфидент»

s.petrenko@confident.spb.ru

 

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

 

В настоящее время для создания эффективной подсистемы идентификации, аутентификации и авторизации целесообразно использовать индустриальные решения на основе перспективных международных стандартов и технологий, например, на основе инфраструктуры с открытыми ключами (Public Key Infrastucture, PKI). Инфраструктура PKI предназначена для создания, распространения и управления ключевой информацией с использованием технологии, основанной на обмене цифровыми сертификатами открытых ключей с единым центром сертификации. По прогнозам аналитиков, цифровые сертификаты как способ электронной идентификации получат широкое распространение в российских корпоративных информационных системах в течение ближайших двух-пяти лет. Понятно, что со временем создание и распространение цифровых сертификатов станет одним из самых важных процессов защиты корпоративных информационных ресурсов, организации безопасного электронного документооборота и защищенного обмена сообщениями в отечественных компаниях. На практике инфраструктура PKI, как правило, включает в себя следующие основные компоненты:

• центр сертификации ключей;

• пользовательский клиент PKI;

• криптопровайдер.

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

Возможные требования к корпоративной системе PKI

Требования к структуре PKI

• модульный принцип построения системы;

• возможность расширения функциональных возможностей системы путем подключения дополнительных модулей; эффективная работа системы при подключении не менее 10 000 клиентов;

• возможность внешнего хранения секретных ключей;

• наличие стандартизированного интерфейса для взаимодействия между компонентами системы;

• выполнение функций создания и проверки электронно-цифровой подписи;

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

• возможность осуществления резервного копирования глобального хранилища сертификатов.

Требования к функциональным модулям системы PKI

Модуль центра сертификации должен состоять из следующих компонентов:

• серверная часть;

• администратор центра сертификации;

• глобальное хранилище сертификатов.

Серверная часть центра сертификации должна реализовывать следующие функции:

• прием, проверку подлинности запросов на электронный сертификат от клиентов системы;

• прием, проверку подлинности запросов на отзыв электронного сертификата от клиентов системы;

• прием произвольных сообщений от клиентов системы;

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

• получение клиентами системы электронных сертификатов, списков отозванных сертификатов из глобального хранилища сертификатов;

• резервное копирование глобального хранилища сертификатов;

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

• сохранение конфигурации системы и информации при внезапных отказах оборудования.

Администратор центра сертификации должен реализовывать следующие функции:

• регистрацию клиентов системы;

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

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

• генерацию секретного ключа центра сертификации и формирование соответствующего сертификата центра сертификации, содержащего его открытый ключ;

• формирование подтверждений о получении сообщений от клиентов системы;

• формирование сообщений о статусе запросов на сертификат для клиентов системы;

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

• отзыв сертификатов клиентов системы по истечении срока их действия;

• публикацию сформированных сертификатов и списков отозванных сертификатов в глобальном хранилище сертификатов;

• удаление информации из глобального хранилища сертификатов;

• изменение конфигурации серверной части центра сертификации;

• сохранение конфигурации серверной части центра сертификации;

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

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

Глобальное хранилище сертификатов должно соответствовать следующим требованиям:

• обеспечение целостности хранимых данных;

• возможность одновременного доступа к хранилищу нескольких клиентов;

• защита хранилища от несанкционированного доступа.

Требования к модулю клиента системы PKI

Модуль клиента системы управления сертификатами должен состоять из следующих компонентов:

• ПО работы с ключевой информацией;

• ключевой информации (контейнера) пользователя;

• локального хранилища сертификатов.

Модуль работы с ключевой информацией должен реализовывать следующие функции:

• генерацию новых ключей пользователя;

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

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

• прием, проверку подлинности и обработку сообщений от администратора центра сертификации;

• доступ к глобальному хранилищу сертификатов для поиска и/или репликации информации;

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

• проверку подлинности электронных сертификатов;

• получение информации, содержащейся в электронном сертификате;

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

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

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

 

Требования к модулю криптопровайдера

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

• соответствовать принятым в мировой практике стандартам для криптопровайдеров;

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

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

Требования к документации системы PKI

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

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

Решения RSA Security

Актуальность PKI очевидна для организации защиты информации, передаваемой как в глобальной сети Интернет, так и внутри предприятия. Организация защиты информации обычно предполагает использование принципа «круговой обороны», когда пользователям требуется подтвердить свои полномочия перед получением доступа к конфиденциальным информационным ресурсам компании. Это обеспечивает некоторую защиту против злоумышленников, которые смогли проникнуть внутрь контролируемого периметра и могут нанести определенный ущерб, например с помощью программного обеспечения подобного «Sniffer», которое может перехватить соединения внутри сети и создать копии перехваченной информации, например email сообщений между внутренними пользователями или служебных сообщений между приложениями. Например, выполняемые транзакции к конфиденциальным базам данных компании могут быть «прослушаны» и скопированы. Для нейтрализации такого рода атак можно использовать различные решения, например решения RSA Keon. В этих решениях центральным элементом является сервер безопасности, обеспечивающий выполнение следующих сервисов.

• Аутентификация. Сервер безопасности проверяет данные, вводимые пользователем при входе в систему (такие, как пароли и PIN-коды) для установления подлинности пользователя. В случае успешного завершения процесса аутентификации пользователь получает доступ к системе.

• Авторизация. Сервер безопасности содержит записи (управляемые администратором защиты), которые определяют (для каждого пользователя), к каким серверам приложений пользователь имеет доступ. (Такие серверы приложений контролируются агентами RSA Keon; этот сервис недоступен в решениях без агентов.)

• Проверка подлинности цифровых сертификатов. Сервер безопасности поддерживает и периодически распространяет на все рабочие столы RSA Keon сертификаты предприятий и организаций, которым можно доверять. Такой набор сертификатов называется таблицей Авторитетных сертифицирующих сторон (Issuing Authority – IA). Рабочий стол использует сертификаты CA для проверки подлинности всех сертификатов, выданных соответствующей CA.

• Управление правами доступа . Сервер безопасности отслеживает все выданные смарт-карты и виртуальные карты; он также хранит виртуальные карты, передает данные, содержащиеся в них, пользователям посредством рабочего стола RSA Keon.

• Регистрация событий . Серверу безопасности передается информация о всех событиях в домене RSA Keon, таким образом вся информация о зарегистрированных событиях сосредоточена в одном месте.

Вся функциональность сервера безопасности делится между рядом подсистем.

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

• Подсистема авторизации . Подсистема авторизации взаимодействует с агентами RSA Keon (в конфигурациях, поддерживающих безопасный доступ к приложениям) для проверки прав доступа по записям, содержащим информацию о том, к каким приложениям и данным имеет доступ конкретный пользователь. Подсистема создает и посылает на рабочий стол сертификат атрибутов привилегий (Privilege Attribute Certificate – PAC), который идентифицирует пользователя, определяет доступные приложения, данные и период (обычно небольшой), в течение которого сертификат действителен. Рабочий стол предоставляет сертификат агенту, который запрашивает сервер безопасности для проверки его правильности. (Агент RSA Keon непосредственно запрашивает информацию о правах доступа пользователя.)

• Подсистема событий . Подсистема событий объединяет всю обработку событий в компонентах RSA Keon в одну подсистему. Расширяемый дизайн позволяет добавлять специфичные пути перенаправления событий, средства просмотра событий, триггеры и запросы на уведомления.

• Подсистема хранения данных. База данных хранит информацию, которая связывает пользователей с их сертификатами, группами и, где возможно, правами доступа. Она также хранит информацию, зарегистрированную подсистемой событий. Хотя необходима только одна копия базы данных, данная подсистема предусматривает репликацию данных на один или несколько дублирующих серверов безопасности, выполняющихся на других машинах. Каждый экземпляр базы данных – точная ее копия, и любые сервисы, работающие на дублирующем сервере, могут производить запись в нее. Процесс дублирования базы данных обрабатывает распространение данных как от первичной базы данных, так и от копий. Хотя база данных является распределенной, с соответствующими преимуществами в плане отказоустойчивости и распределения загрузки, системные процессы RSA Keon и администраторы могут рассматривать данную подсистему как одиночный источник данных.

Краткое описание RSA Keon Certificate Authority

RSA Keon CA позволяет создавать, управлять и подтверждать подлинность цифровых сертификатов. Это программное обеспечение включает инструменты администрирования, регистрации, сервисы проверки и доступа, а также сервер SCEP (Simple Certificate Enrollment Protocol), который автоматически вносит в реестр выпущенные сертификаты. RSA Keon CA также содержит мощный модуль для осуществления цифровой подписи сертификатов конечных пользователей и системных событий, а также встроенное хранилище цифровых сертификатов, системной информации и информации о статусах сертификатов. С помощью программного обеспечения RSA Keon CA компании могут определять и самостоятельно регулировать собственные процедуры безопасности, степень доверительности отношений, формат сертификатов и правила, описывающие их жизненный цикл, что служит основой корпоративных политик безопасности. Функциональная схема взаимодействия основных компонентов Keon CA приведена на рис. 3.

 

RSA Keon Registration Authority

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

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

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

Масштабируемость

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

Специальная проверка статуса в реальном времени

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

При использовании RSA Keon real-time OCSP нет никакого временного разрыва , благодаря которому пользователь может получить доступ к системе уже после того, как его сертификат был отозван – тем самым устраняется угроза нарушения безопасности через использование недействительных сертификатов. Программное обеспечение RSA Keon также полностью поддерживает промышленные стандарты схемы отзыва сертификатов.

Cовместимость как сохранение инвестиций

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

Заключение

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

 

"Защита информации. Кофидент", №6, 2002