Читать онлайн «Инфраструктуры открытых ключей». Страница 91

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

Применение смарт-карт и управление их жизненным циклом также связано с использованием специального клиентского программного обеспечения и установки дополнительных драйверов. Поставщики смарт-карт могут использовать обычные стандарты типа CAPI (Cryptographic Application Programmer Interface) [112] и PKCS#11 [202]. Следует учитывать, что интеграция с системами более сильной аутентификации требует дополнительных финансовых затрат и затрат времени.

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

Важным аспектом PKI, который часто упускается из виду, является удобство работы пользователя. Пользователь должен иметь простое и понятное средство формирования запросов на выдачу, обновление и аннулирование сертификатов. Большинство поставщиков PKI предлагают некоторый интерфейс пользователя, но, как правило, он является приложением, базирующимся на клиентском программном обеспечении, и не всегда приспособлен для работы на разных компьютерных платформах ( PC, UNIX, Mac ) или разных версиях.

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

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

Как известно (см. лекцию 6), помимо формата X.509 существуют и альтернативные форматы сертификатов. Неудивительно, что имеются сторонники каждого формата. Так, например, сторонники формата SPKI утверждают, что сертификаты SPKI позволяют фиксировать роли и права авторизации, не раскрывая идентичность субъектов. Сторонники формата PGP или Open PGP считают важным преимуществом большую гибкость сертификатов PGP по сравнению с сертификатами открытых ключей X.509 v3 и, следовательно, большую пригодность для установления отношений доверия между субъектами. Однако пока большинство поставщиков PKI поддерживают только сертификаты X.509.

В будущем, возможно, получат распространение форматы сертификатов, основанные на языке разметки XML (eXtensible Markup Language) [66], который все чаще применяется в качестве формата для обмена информацией между разными приложениями в Интернете [44]. Новые форматы сертификатов, определенные техническим комитетом по сервисам безопасности OASIS в спецификации языка Security Assertion Markup Language (SAML) [95], вероятно, будут использоваться сообществом разработчиков бизнес-приложений на базе XML. Такие форматы могут заменить сертификаты X.509 на уровне XML -приложений, но, скорее всего, будут сосуществовать вместе с ними на другом уровне, для того чтобы осуществлялось взаимодействие с другими действующими инфраструктурами. Среда для такого взаимодействия может базироваться на спецификации управления ключами XML Key Management Specification [129], чтобы, как определено Консорциумом World Wide Web Consortium (W3C), скрывать от XML -приложения детали базовой PKI стандарта X.509.

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

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

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

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

Одна из проблем, связанных с сервисами каталога, заключается в отсутствии единого стандарта на эти услуги. Некоторые сегменты рынка адаптировали стандарты каталога X.500, но одновременно существует и разрабатывается большое количество стандартов, имеющих отношение к репозиторию. Например, известный упрощенный протокол доступа к каталогу LDAP, разработанный организацией IETF, с точки зрения технической перспективы находится в прямой конкуренции с протоколом DAP, базирующимся на стандарте X.500. Имеется еще ряд нерешенных проблем обмена информацией и взаимодействия "клиент-сервер" и "сервер-сервер". Рабочая группа LDAPext организации IETF разрабатывает ряд стандартов, таких как механизмы управления доступа и модели контроля доступа, в стадии разработки находится протокол LDUP [87], который, вероятно, будет конкурировать со своим двойником - протоколом DISP (Directory Information Shadowing Protocol) стандарта X.500. Кроме того, распространение информации PKI выполняется и другими способами (см. лекцию 12).

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

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