Как заставить PKI работать. Опыт Минобороны США

страницы:   предыдущая   |   1    |   2    |   3  

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

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

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

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

СОС слишком "громоздки" для отдельного ПО

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

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

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

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

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

Масштаб инфраструктуры PKI Министерства обороны влечет за собой дополнительную проблему – большой размер СОС. Суммарный размер СОС всех УЦ Министерства обороны достигает 40 мегабайт. Когда каждое ПО в сети Министерства обороны каждый день скачивает такой объем данных, это неизбежно существенно сказывается на пропускной способности сети. Ни одно отдельно взятое ПО не имеет в качестве своих пользователей всех абонентов инфраструктуры PKI, поэтому каждое отдельное приложение нуждается лишь в подмножестве этой информации. Но поскольку корпоративная PKI заранее не знает, какое подмножество данных нужно для каждого из приложений, то всем ПО представляется общий список отозванных сертификатов.

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

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

Сертификаты проверяются онлайн

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

Непрекращающиеся проблемы при выполнении проверки сертификатов с использованием СОС вынудили МО начать работу по организации проверки статуса сертификатов с использованием "протокола определения статуса сертификата в реальном времени" (On-line Certificate Status Protocol, OCSP). Это означает, что программные приложения, вместо скачивания СОС, будут иметь возможность получать в реальном времени ответы на запросы о статусе конкретных сертификатов из глобальной системы проверки сертификатов. Хотя использование СОС в качестве авторитетного источника информации об отзыве сертификатов не решает вопросов, связанных с запаздыванием получения информации, - гибридный подход, предусматривающий совместное применение списков отозванных сертификатов и возможности определения статуса сертификата в реальном времени, дает возможность использовать списки гораздо более эффективно.

Убеждение – залог успешного финансирования

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

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

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

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

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

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

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

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

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

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

Наталья Храмцовская

Короткая ссылка на материал: //cnews.ru/link/a1735

страницы:   предыдущая   |   1    |   2    |   3