Информация. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. В. Ф. Шаньгининформационная безопасность компьютерных систем
 Скачать 5.69 Mb.
|
|
13.3. Управление доступом по схеме однократного входа с авторизацией Single Sign-On (SSO) Большинство пользователей информационных средств и систем используют компьютеры для доступа к ряду сервисов, будь это несколько локальных приложений или сложные прило жения, которые включают одну или более удаленных систем, к которым машина пользователя подсоединяется через сеть. В це лях обеспечения безопасности многие приложения требуют про ведения аутентификации пользователя, прежде чем ему дадут доступ к сервисам и данным, предоставляемым приложением. Конечные пользователи обычно воспринимают такие требо вания системы безопасности как дополнительную нагрузку, ко торая заставляет поддерживать и помнить многочисленные вход ные идентификаторы и пароли и использовать их каждый день по несколько раз, чтобы иметь возможность выполнять свою обычную работу. Довольно обычна ситуация, когда один пользо ватель имеет 5 и более таких пользовательских accounts, все на различных платформах, с различными правилами для длин па ролей, а также с различной частотой их замены. Пользователь должен либо заучивать их, либо записывать, подвергая тем са мым безопасность серьезному риску, так как их и могут найти неавторизованные пользователи. С увеличением числа требующих запоминания паролей, воз растает вероятность того, что эти пароли будут забываться, а это потребует от администраторов дополнительных усилий по их восстановлению. Эту проблему часто называют «проблемой мно гих входов». Ее позволяет решить схема однократного входа с ав торизацией SSO (Single Sign-On). Управление доступом по схеме SSO дает возможность поль зователям корпоративной сети при их входе в сеть пройти одну аутентификацию, предъявив только один раз пароль (или иной требуемый аутентификатор), и затем без дополнительной аутен тификации получить доступ ко всем авторизованным сетевым ресурсам, которые нужны для выполнения их работы. Такими сетевыми ресурсами могут быть принтеры, приложения, файлы и другие данные, размещаемые по всему предприятию на серве рах различных типов, работающих на базе различных ОС. Управление доступом по схеме SSO позволяет повысить произ водительность труда пользователей сети, уменьшить стоимость сетевых операций и улучшить сетевую безопасность. С функционированием схемы SSO непосредственно связаны процессы аутентификации и авторизации. С помощью аутенти фикации система проверяет подлинность пользователя, в то вре мя как авторизация определяет, что именно разрешается делать пользователю (обычно основываясь на его роли в организации). Большинство подходов SSO централизованно осуществляют ау тентификацию пользователя. Авторизацию обычно выполняют на ресурсах целевых объектов, хотя некоторые продвинутые SSO-решения централизованно осуществляют и авторизацию, при этом используются продукты централизованного админист рирования безопасности, которые осуществляют администриро вание полномочий пользователей. Схему SSO поддерживают такие средства, как протокол LDAP (Lightweight Directory Access Protocol), протокол SSL (Secure Sockets Layer), система Kerberos и инфраструктура управ ления открытыми ключами РКІ (Public Key Infrastructure), а так же средства интеграции сервисов каталогов и безопасности. Эти средства и технологии образуют вместе фундамент для примене ния схемы SSO при обработке данных системами, использующи ми различные комбинации клиентов, серверов, сервисов и при ложений. Существующие решения схемы SSO простираются от про стых средств до SSO-сервисов на базе сетевых ОС NOS (Network Operating System), многофункциональных приложений и SSO уровня предприятия [9]. Простые средства SSO включают кэш паролей Windows и кэш паролей, встроенный в продукты, подобные Internet Explorer и другие пакеты. NOS-based SSO-сервисы дают возможность пользователю вхо дить в такие сетевые ОС, как Windows NT/2000/XP, NetWare или Solaris, и таким образом получать доступ ко многим или ко всем приложениям, работающим на базе NOS. Продукты SSO уровня предприятия, такие как IBM's Global Sign-On и др., обычно применяют комбинированные подходы к sign-on, основанные на использовании клиентов и proxy, техно логии и стандарты кратной аутентификации, включая ввод ID пользователя и пароля. 1 3 .3 .1 . Простая система однократного входа SSO Простое SSO-решение состоит в том, чтобы просто автомати зировать процесс предъявления пароля. Для многих из продуктов SSO информация входа (т. е. имя пользователя и пароль) и любые необходимые записи хранятся в специальном сервере аутентифи кации. Используя клиентское ПО, пользователь предъявляет сер веру аутентификации пароль, и этот сервер сообщает клиентско му ПО, к каким ресурсам может получить доступ пользователь (рис. 13.6). Клиентское ПО представляет пользователю допусти мые опции. Когда пользователь выберет ресурс, клиентское ПО использует мандат входа и scripts, предоставленные сервером ау тентификации, чтобы установить от имени пользователя соедине ние с соответствующим ресурсом целевого объекта (сервера, хос та, домена или приложения). 11 <5> < £ > Пользователь гФ"** Ресурс А Ѳ-* Ресурс В L©-* Ресурс С Сервер аутентификации Рис. 13.6. Простое SSO-решение — автоматизация входа При автоматизации процедуры входа выполняются следую щие шаги. 1. Пользователь предъявляет серверу аутентификации па роль, используя специальное клиентское ПО на своем персо нальном компьютере. 2. Сервер аутентификации проверяет, к каким ресурсам мо жет получить доступ этот пользователь и отправляет эту инфор мацию обратно на клиентское SSO-приложение совместно с не обходимым мандатом входа и scripts для соединения с каждым разрешенным ресурсом. 3. Клиентское SSO-приложение представляет пользователю доступные ресурсы и входит от имени пользователя в выбранные приложения. Автоматизация процедуры входа позволяет получить простую схему SSO, но при этом еще больше децентрализуется админист рирование безопасностью. Ряд поставщиков предлагает дополни тельные средства централизованного администрирования безо пасностью. Эти средства используют агентов в целевых системах и обеспечивают основанное на ролях (role-based) централизован ное администрирование учетных записей пользователей и ин формации об их полномочиях. В некоторых случаях тги средства администрирования полностью отделены от схемы SSO; в дру гих — интегрированы с SSO. Первоначальной целью SSO было сокращение числа исполь зуемых многоразовых паролей для получения пользователями доступа к сетевым ресурсам. При формировании современного решения SSO применяются также такие средства аутентифика ции пользователя, как токены, цифровые сертификаты РКІ, смарт-карты и биометрические устройства. Более совершенный подход к аутентификации обычно основан на использовании то кенов. Наиболее известной системой аутентификации является Kerberos. Продвинутые SSO-решения предоставляют больше контроля над полномочиями пользователя, поддерживаемыми обычно на прикладном уровне. В продуктах SSO могут быть также поддер жаны нетокенные механизмы аутентификации, основанные на сертификатах РКІ (в частности, RSA ClearTrust поддерживает РКІ). 1 3 .3 .2 . SSO-продукты уровня предприятия SSO-продукты уровня предприятия проектируются для боль ших компаний с гетерогенной распределенной компьютерной средой, состоящей из многих систем и приложений. Характерным представителем SSO-продуктов уровня пред приятия является продукт IBM Global Sign-On for Multiplatforms (далее называемый GSO). Продукт GSO представляет безопас ное, простое решение, позволяющее получать доступ к сетевым компьютерным ресурсам, используя однократный вход в систе му. GSO освобождает пользователя от необходимости вводить различные идентификаторы и пароли для всех его целевых объ ектов, которые включают ОС, программные средства коллектив ного пользования, БД или приложения другого вида [9]. Было бы идеально, если бы GSO мог действовать как универ сальный безопасный, надежный механизм аутентификации для любого целевого объекта. К сожалению, такое решение унифи цированной аутентификации создать невозможно, потому что большинство продуктов, которым требуется сервис аутентифика ции, выполняют процедуру аутентификации различными спосо бами. Чтобы сделать реальностью такой идеальный подход, по ставщики должны модифицировать свои продукты таким обра зом, чтобы обеспечить выполнение требований общего стандарта X/Open Single Sign-On (XSSO). Поэтому GSO придерживается реального подхода, основан ного на том факте, что продукты поставщиков не поддерживают доверенную внешнюю аутентификацию. Для аутентификации эти продукты чаще всего требуют идентификатор ID и пароль каждого пользователя. GSO осуществляет безопасное хранение пользовательских идентификаторов IDs и паролей, а также обес печение ими целевых объектов, когда пользователю нужно предъявить пароль при входе. Это освобождает пользователя от необходимости помнить и вводить IDs и пароль каждый день для каждого целевого объекта. Ячейка GSO содержит, по крайней мере, сервер GSO и одну рабочую станцию пользователя, называемую также клиентом GSO. В ячейке GSO может быть более одного сервера GSO и мно жество клиентов (рис. 13.7). Сервер GSO Рис. 13.7. Базовые компоненты GSO Пользователь взаимодействует со своей рабочей станцией и некоторыми целевыми объектами (приложениями), которые мо гут выполняться на этой рабочей станции или на каком-либо другом компьютере, например сервере департамента или серве рах приложений. Перед тем как начать работу, пользователь должен войти в свою рабочую станцию. Он предъявляет пароль именно GSO, а не приложению или другим серверам. GSO выполняет аутенти фикацию, основанную на идентификаторе ID и пароле пользова теля (иногда поддерживаемых смарт-картой или считывателем отпечатков пальцев). Сервер GSO включается в процесс аутенти фикации, для того чтобы проверить пароль пользователя и из влечь его мандат (credentials). Затем GSO вводит пользователя в целевые объекты (прило жения или серверы), с которыми этот пользователь должен ра ботать. GSO использует для входа пользователя методы, предос тавляемые целевыми объектами. В большинстве случаев GSO имитирует вход пользователя, передавая целевому объекту ID и пароль пользователя, как будто вводит их сам пользователь. Важное различие, очевидно, состоит в том, что теперь пользова телю не нужно запоминать эти идентификаторы ID и пароли, поскольку заботу о них принимает на себя GSO. GSO является клиент/серверным приложением. В дополне ние к серверу GSO существует программа клиента (сегмент про граммного кода), выполняемая на рабочей станции пользовате ля, которая взаимодействует с сервером GSO [9]. SSO-продукты уровня предприятия обладают следующими достоинствами: • допускают использование многих целевых платформ со своими собственными механизмами аутентификации; • безопасно хранят в БД учетную информацию пользовате лей (такую как идентификатор ID, пароль и некоторую до полнительную информацию) на каждую целевую платфор му и каждого пользователя; • радикально уменьшают долю забываемых паролей, по скольку пароли пользователей хранятся безопасно и на дежно; • используют методы и средства безопасной аутентификации и коммуникации; чувствительная пользовательская инфор мация хранится и передается по сети только в зашифро ванном виде. Недостатками SSO-продуктов уровня предприятия является их относительно большая стоимость и высокие требования к квалификации обслуживающего персонала. 13.4. Протокол Kerberos Протокол Kerberos используется в системах клиент—сервер для аутентификации и обмена ключевой информацией, предна значенной для установления защищенного канала связи между абонентами, работающими как в локальной сети, так и глобаль ных сетях. Данный протокол встроен в качестве основного про токола аутентификации в Microsoft Windows 2000 и в UNIX BSD. Kerberos обеспечивает аутентификацию в открытых сетях, т. е. при работе Kerberos подразумевается, что злоумышленники могут производить следующие действия: • выдавать себя за одну из легитимных сторон сетевого со единения; • иметь физический доступ к одному из участвующих в со единении компьютеров; • перехватывать любые пакеты, модифицировать их и (или) передавать повторно. Соответственно, обеспечение безопасности в Kerberos по строено таким образом, чтобы нейтрализовать любые потенци альные проблемы, которые могут возникнуть из-за указанных действий злоумышленников. Kerberos разработан для сетей TCP/IP и построен на основе доверия участников протокола к третьей (доверенной) стороне. Служба Kerberos, работающая в сети, действует как доверенный посредник, обеспечивая надежную аутентификацию в сети с по следующей авторизацией доступа клиента (клиентского прило жения) к ресурсам сети. Защищенность установленных в рамках сессии Kerberos соединений обуславливается применением сим метричных алгоритмов шифрования. Служба Kerberos разделяет отдельный секретный ключ с каждым субъектом сети, и знание такого секретного ключа равносильно доказательству подлинно сти субъекта сети. Основу Kerberos составляет протокол аутентификации и рас пределения ключей Нидхэма — Шредера с третьей доверенной стороной [9]. Рассмотрим эту версию протокола. В протоколе Kerberos (версия 5) участвуют две взаимодействующие стороны и доверенный сервер KS, выполняющий роль Центра распределе ния ключей. Вызывающий (исходный) объект обозначается через А, а вы зываемый (объект назначения) — через В. Участники сеанса А и В имеют уникальные идентификаторы Id, и Ids соответственно. Стороны А и В, каждая по отдельности, разделяют свой секрет ный ключ с сервером KS. Пусть сторона А хочет получить сеансовый ключ для инфор мационного обмена со стороной В. Сторона А инициирует фазу распределения ключей, посылая по сети серверу KS идентификаторы Id, и Idg: ^ K S : I d „ I d 5. (1) Сервер KS генерирует сообщение с временной отметкой Т, сроком действия L, случайным сеансовым ключом К и иденти фикатором Id,,. Он шифрует это сообщение секретным ключом, который разделяет со стороной В. Затем сервер KS берет временную отметку Т, срок дейст вия L, сеансовый ключ К, идентификатор Ids стороны В и шиф рует все это секретным ключом, который разделяет со сторо ной А. Оба эти зашифрованные сообщения он отправляет сто роне А: KS -> А: Е а ( Т; L, К, Id,), Ев (Т, L, К, Id,). (2) Сторона А расшифровывает сообщение своим секретным ключом, проверяет отметку времени Т, чтобы убедиться, что это сообщение не является повторением предыдущей процедуры распределения ключей. Затем сторона А генерирует сообщение со своим идентификатором Id, и отметкой времени Т, шифрует его сеансовым ключом К и отправляет стороне В. Кроме того, А отправляет для В сообщение от KS, зашифрованное ключом стороны В: А -+ В: Ек (Id* 7), Ев ( Т, L, К, Id,). (3) Только сторона В может расшифровать сообщение (3). Сто рона В получает отметку времени Т, срок действия L, сеансовый ключ К и идентификатор Id,. Затем сторона В расшифровывает сеансовым ключом К вторую часть сообщения (3). Совпадение значений Г и Id, в двух частях сообщения подтверждают под линность А по отношению к В. Для взаимного подтверждения подлинности сторона В созда ет сообщение, состоящее из отметки времени Т плюс 1, шифру ет его ключом К и отправляет стороне А: В ^ А : ЕК{Т+ 1). (4) Если после расшифрования сообщения (4) сторона А получа ет ожидаемый результат, она знает, что на другом конце линии связи находится действительно В. Этот протокол успешно работает при условии, что часы каж дого участника синхронизированы с часами сервера K.S. Следует отметить, что в этом протоколе необходим обмен с KS для полу чения сеансового ключа каждый раз, когда А желает установить связь с В. Протокол обеспечивает надежное соединение объек тов А и В при условии, что ни один из ключей не скомпромети рован и сервер KS защищен. Система Kerberos имеет структуру типа клиент—сервер и со стоит из клиентских частей С, установленных на всех рабочих станциях пользователей и серверах сети, и сервера Kerberos KS, располагающегося на каком-либо (не обязательно выделенном) компьютере (см. рис. 13.8). Клиентами могут быть пользователи, а также независимые программы, выполняющие такие действия, как загрузка удаленных файлов, отправка сообщений, доступ к БД, доступ к принтерам, получение привилегий у администрато ра и т. п. Сервер Kerberos KS, можно разделить на две части: сервер аутентификации AS (Authentication Server) и сервер службы вы дачи мандатов TGS (Ticket Granting Service). Физически эти сер веры могут быть совмещены. Информационными ресурсами, не обходимыми клиентам С, управляет сервер информационных ресурсов RS. Предполагается, что серверы службы Kerberos на дежно защищены от физического доступа злоумышленников. Сетевые службы, требующие проверки подлинности, и кли енты, которые хотят использовать эти службы, регистрируют в Kerberos свои секретные ключи. Kerberos хранит БД о клиентах и их секретных ключах. Наличие в этой БД секретных ключей каждого пользователя и ресурсов сети, поддерживающих этот протокол, позволяет создавать зашифрованные сообщения, на правляемые клиенту или серверу; успешное расшифрование этих сообщений и является гарантией прохождения аутентифи кации всеми участниками протокола. Kerberos также создает сеансовые ключи (session key), которые выдаются клиенту и серверу (или двум клиентам) и никому больше. Сеансовый ключ используется для шифрования сооб щений, которыми обмениваются две стороны, и уничтожается после окончания сеанса. Область действия системы Kerberos распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в БД сервера Kerberos. Укрупненно процесс идентификации и аутентификации пользователя в системе Kerberos версии 5 можно описать сле дующим образом (рис. 13.8). 1 KS I Обозначения: I ! KS — сервер системы Kerberos I AS — сервер аутентификации TGS — сервер службы выделения мандатов RS — сервер информационных ресурсов С — клиент системы Kerberos Рис. 13.8. Схема работы протокола Kerberos Клиент С, желая получить доступ к ресурсу сети, направляет запрос серверу аутентификации AS. Сервер AS идентифицирует пользователя с помощью его имени и пароля и высылает клиен ту мандат (ticket) на доступ к серверу службы выделения манда тов TGS (Ticket-Granting Service). Для использования конкретного целевого сервера информа ционных ресурсов RS клиент С запрашивает у TGS мандат на обращение к целевому серверу RS. Если все в порядке, TGS раз решает использование необходимых ресурсов сети и посылает соответствующий мандат клиенту С. Основные шаги работы системы Kerberos (см. рис. 13.10): 1. С AS — запрос клиента С к серверу AS разрешить обра титься к службе TGS. 2. AS С — разрешение (мандат) от сервера AS клиенту С обратиться к службе TGS. 3. С TGS — запрос клиента С к службе TGS на получение допуска (мандата) к серверу ресурсов RS. 4. TGS -> С — разрешение (мандат) от службы TGS клиен ту С для обращения к серверу ресурсов RS. 5. С -> RS — запрос информационного ресурса (услуги) у сервера RS. 6. RS -> С — подтверждение подлинности сервера RS и пре доставление информационного ресурса (услуги) клиенту С. Данная модель взаимодействия клиента с серверами может функционировать только при условии обеспечения конфиденци альности и целостности передаваемой управляющей информа ции. Без строгого обеспечения информационной безопасности клиент С не может отправлять серверам AS, TGS и RS свои за просы и получать разрешения на доступ к обслуживанию в сети. Чтобы избежать возможности перехвата и несанкциониро ванного использования информации, Kerberos применяет при передаче любой управляющей информации в сети систему мно гократного шифрования с использованием комплекса секретных ключей (секретный ключ клиента, секретный ключ сервера, сек ретные сеансовые ключи пары клиент—сервер). Kerberos может использовать различные симметричные алгоритмы шифрования и хэш-функции. На сегодняшний день протокол Kerberos является широко распространенным средством аутентификации. Kerberos может использоваться в сочетании с различными криптографическими схемами, включая шифрование с открытым ключом. 13.5. Инфраструктура управления открытыми ключами РКІ Исторически в задачи любого центра управления информа ционной безопасностью всегда входил набор задач по управле нию ключами, используемыми различными средствами защиты информации (СЗИ). В этот набор входят выдача, обновление, отмена и распространение ключей. В случае использования симметричной криптографии задача распространения секретных ключей представляла наиболее труд ную проблему, поскольку: • для N пользователей необходимо распространить в защи щенном режиме N ( N - 1)/2 ключей, что обременительно при N порядка нескольких сотен; • система распространения ключей сложна (много ключей и закрытый канал распространения), что приводит к появле нию уязвимых мест. Асимметричная криптография позволяет обойти эту пробле му, предложив к использованию только N секретных ключей. При этом у каждого пользователя только один секретный ключ и один открытый, полученный по специальному алгоритму из секретного. Из открытого ключа практически невозможно получить сек ретный, поэтому открытый ключ можно распространять откры тым способом всем участникам взаимодействия. На основании своего закрытого ключа и открытого ключа своего партнера по взаимодействию любой участник может выполнять любые крип тографические операции: электронно-цифровую подпись, расчет разделяемого секрета, защиту конфиденциальности и целостно сти сообщения. В результате решаются две главные проблемы симметричной криптографии: • перегруженность количеством ключей — их теперь всего N\ • сложность распространения — их можно распространять открыто. Однако у этой технологии есть один недостаток — подвер женность атаке man-in-the-middle (человек-в-середине), когда атакующий злоумышленник расположен между участниками взаимодействия. В этом случае появляется риск подмены переда ваемых открытых ключей. Инфраструктура управления открытыми ключами РКІ (Pub lic Key Infrastructure) позволяет преодолеть этот недостаток и обеспечить эффективную защиту от атаки man-in-the-middle. 1 3 .5 .1 . Принципы ф ункционирования Р КІ Инфраструктура открытых ключей РКІ предназначена для надежного функционирования КИС и позволяет как внутрен ним, так и внешним пользователям безопасно обмениваться ин формацией с помощью цепочки доверительных отношений. Ин фраструктура открытых ключей основывается на цифровых сер тификатах, которые действуют подобно электронным паспортам, связывающим индивидуальный секретный ключ пользователя с его открытым ключом. Защита от атаки man-in-the-middle При осуществлении атаки man-in-the-middle атакующий мо жет незаметно заменить передаваемые по открытому каналу от крытые ключи законных участников взаимодействия на свой от крытый ключ, создать разделяемые секреты с каждым из закон ных участников и затем перехватывать и расшифровывать все их сообщения. Поясним на примере (рис. 13.9) действия атакующего и спо соб защиты от этой атаки. Предположим, что пользователь 1 и пользователь 2 решили установить защищенное соединение, рассчитав общий для них разделяемый секрет по схеме Диф- фи — Хеллмана. Однако в момент передачи по открытому кана лу открытых ключей А",0 и К° пользователей 1 и 2 злоумышлен ник @ перехватил эти ключи, не дав им дойти до адресатов. Соз дав свои закрытый и открытый ключи, злоумышленник @ передает свой открытый ключ К@ пользователям 1 и 2, незамет но подменив своим ключом К@ их подлинные открытые ключи и К 2 В результате пользователи 1 и 2 создадут разделяемые секреты не между собою, а между 1 •<-» @ и 2 <-> @, поскольку они будут использовать свои закрытые ключи и A'f и открытый ключ К® злоумышленника @. Рис. 13.9. Осуществление атаки man-in-the-middle Когда пользователь 1 будет отправлять пользователю 2 за шифрованную информацию, злоумышленник @ может ее пере хватить и расшифровать (у него с пользователем 1 свой разде ляемый секрет Кт). Затем злоумышленник @ зашифрует инфор мацию (возможно, измененную) заново, используя второй разделяемый секрет Кт, рассчитанный им и пользователем 2. В результате пользователь 2 будет получать, расшифровывать и использовать информацию, отправленную злоумышленником @, полагая, что он имеет защищенный канал с пользователем 1. Эта простая, но результативная атака является расплатой за изящное решение задачи распределения ключей, предложенное асимметричной криптографией. Проблема подмены открытых ключей успешно решается пу тем использования сертификатов открытых ключей. Сертификаты открытых ключей Сертификаты открытых ключей играют важную роль в крип тографии открытых ключей. Их основное назначение — сделать доступным и достоверным открытый ключ пользователя. В основу формирования сертификатов открытых ключей по ложены принципы строгой аутентификации, рекомендованные стандартом Х.509 и базирующиеся на свойствах криптосистем с открытым ключом. Криптосистемы с открытым ключом предполагают наличие у пользователя парных ключей — секретного и открытого (обще доступного). Каждый пользователь идентифицируется с помо щью своего секретного ключа. С помощью парного открытого ключа любой другой пользователь имеет возможность опреде лить, является ли его партнер по связи подлинным владельцем секретного ключа. Процедура, позволяющая каждому пользователю устанавли вать однозначное и достоверное соответствие между открытым ключом и его владельцем, обеспечивается с помощью механизма сертификации открытых ключей. Степень достоверности факта установления подлинности (аутентификации) пользователя зависит от надежности хранения секретного ключа и надежности источника поставки открытых ключей пользователей. Чтобы пользователь мог доверять про цессу аутентификации, он должен извлекать открытый ключ другого пользователя из надежного источника, которому он до веряет. Таким источником согласно стандарту Х.509 является Центр сертификации СА ( Certification Authority). Его называют также Удостоверяющий центр — УЦ; последний термин исполь зуется, в частности, в отечественном «Законе об ЭЦП» [62]. Центр сертификации СА является доверенной третьей сторо ной, обеспечивающей аутентификацию открытых ключей, содер жащихся в сертификатах. СА имеет собственную пару ключей (открытый/секретный), где секретный ключ СА используется для подписывания сертификатов, а открытый ключ СА публику ется и используется пользователями для проверки подлинности открытого ключа, содержащегося в сертификате. Сертификация открытого ключа — это подтверждение под линности открытого ключа и хранимой совместно с ним слу жебной информацией, в частности о принадлежности ключа. Сертификация ключа выполняется путем вычисления ЭЦП сер тифицируемого ключа и служебной информации с помощью специального секретного ключа-сертификата, доступного толь ко СА. Иными словами, сертификация открытого ключа — это подписывание открытого ключа электронной подписью, вычис ленной на секретном ключе СА. Открытый ключ совместно с сертифицирующей его ЭЦП часто называют сертификатом открытого ключа или просто сер тификатом. СА формирует сертификат открытого ключа пользователя путем заверения цифровой подписью СА определенного набора данных. В соответствии с форматом Х.509 в этот набор данных вклю чаются: • период действия открытого ключа, состоящий из двух дат: начала и конца периода; • номер и серия ключа; • уникальное имя пользователя; • информация об открытом ключе пользователя: идентифи катор алгоритма, для которого предназначен данный ключ, и собственно открытый ключ; • ЭЦП и информация, используемая при проведении проце дуры проверки ЭЦП (например, идентификатор алгоритма генерации ЭЦП); • уникальное имя сертификационного центра. Таким образом, цифровой сертификат содержит три главные составляющие: • информацию о пользователе — владельце сертификата; • открытый ключ пользователя; • сертифицирующую ЭЦП двух предыдущих составляющих, вычисленную на секретном ключе СА. Сертификат открытого ключа обладает следующими свойст вами: • каждый пользователь, имеющий доступ к открытому ключу СА, может извлечь открытый ключ, включенный в серти фикат; • ни одна сторона, помимо СА, не может изменить сертифи кат так, чтобы это не было обнаружено (сертификаты нель зя подделать). Так как сертификаты не могут быть подделаны, то их можно опубликовать, поместив в общедоступный справочник не пред принимая специальных усилий по защите этих сертификатов. Создание сертификата открытого ключа начинается с созда ния пары ключей (открытый/секретный). Процедура генерации ключей может осуществляться двумя способами. 1. СА создает пару ключей. Открытый ключ заносится в сер тификат, а парный ему секретный ключ передается пользовате лю с обеспечением аутентификации пользователя и конфиден циальности передачи ключа. 2. Пользователь сам создает пару ключей. Секретный ключ сохраняется у пользователя, а открытый ключ передается по за щищенному каналу в СА. Каждый пользователь может быть владельцем одного или не скольких сертификатов, сформированных сертификационным центром СА пользователя. Пользователь может владеть сертифи катами, полученными из нескольких разных сертификационных центров. На практике часто возникает потребность аутентифициро вать пользователя, который получает сертификаты в другом сер тификационном центре. Принципы распределенного админист рирования рассматриваются ниже. Базовые модели сертификации Концепция инфраструктуры открытых ключей РКІ подразу мевает, что все сертификаты конкретной РКІ (своя РКІ может быть у любой организации или организационной единицы) ор ганизованы в определенную структуру. В РКІ различают четыре типа сертификатов. 1. Сертификат конечного пользователя (описанный выше). 2. Сертификат СА. Должен быть доступен для проверки ЭЦП сертификата конечного пользователя и подписан секрет ным ключом СА верхнего уровня, причем эта ЭЦП также долж на проверяться, для чего должен быть доступен сертификат СА верхнего уровня, и т. д. 3. Самоподписанный сертификат. Является корневым для всей РКІ и доверенным по определению — в результате проверки це почки сертификатов СА выяснится, что один из них подписан корневым секретным ключом, после чего процесс проверки ЭЦП сертификатов заканчивается. 4. Кросс-сертификат. Позволяет расширить действие кон кретной РКІ путем взаимоподписания корневых сертификатов двух разных РКІ. Существуют три базовые модели сертификации: • иерархическая модель, основанная на иерархической цепи сертификатов; • модель кросс-сертификации (подразумевает взаимную сер тификацию); • сетевая (гибридная) модель, включающая элементы иерар хической и взаимной сертификации [9]. Обобщенные схемы иерархической и сетевой архитектуры систем управления сертификатами приведены на рис. 13.10. Иерархическая структура Сетевая структура Доверенный Центр сертификации (СА) ----- ► Выпуск сертификата Удостоверяющий Центр сертификации (СА) ^ ^ Кросс-сертификация □ Пользователь Рис. 13.10. Иерархическая и сетевая архитектуры систем управления сертификатами В иерархической модели СА расположены в иерархическом подчинении доверенному (корневому) СА, предоставляющему сертификаты другим СА. Достоинства иерархической архитектуры системы управле ния сертификатами: • аналогична существующим федеральным и ведомственным организационно-управляющим структурам и может стро иться с учетом этого; • определяет простой алгоритм поиска, построения и вери фикации цепочек сертификатов для всех взаимодействую щих сторон; • для обеспечения взаимодействия двух пользователей одно му из них достаточно предоставить другому свою цепочку сертификатов, что уменьшает проблемы, связанные с их взаимодействием. Недостаток иерархической архитектуры: для обеспечения взаимодействия всех конечных пользователей должен быть толь ко один корневой доверенный СА. В модели кросс-сертификации независимые СА, не находя щиеся на одной ветви иерархии, взаимно сертифицируют друг друга в сети СА. Кросс-сертификация является предметом дву стороннего соглашения между СА. Следует отметить, что модель кросс-сертификации является частным случаем сетевой архи тектуры системы управления сертификатами. Достоинства сетевой архитектуры системы управления сер тификатами: • гибкость, что способствует установлению непосредствен ных доверенных взаимоотношений, существующих в со временном бизнесе; • отношения доверия в системе: конечный пользователь дол жен доверять, по крайней мере, только центру, издавшему его сертификат; • возможность непосредственной кросс-сертификации раз личных удостоверяющих СА, пользователи которых часто взаимодействуют между собой, что сокращает процесс ве рификации цепочек. Недостатки сетевой архитектуры управления сертификатами: • сложность алгоритма поиска и построения цепочек серти фикатов для всех взаимодействующих сторон; • невозможность предоставления пользователем цепочки, которая обеспечивает проверку его сертификата всеми ос тальными пользователями. Вероятно, в недалеком будущем на самом высоком уровне иерархии сертификации должен оказаться государственный но тариус, который обеспечит связь цепочек доверия разных орга низаций. 1 3 .5 .2 . Л о ги ч ес ка я структура и компоненты Р КІ Инфраструктура открытых ключей РКІ (Public Key Infra structure) — это набор агентов и правил, предназначенных для управления ключами, политикой безопасности и собственно об меном защищенными сообщениями [9, 50]. Основные задачи РКІ: • поддержка жизненного цикла цифровых ключей и серти фикатов (т. е. генерация ключей, создание и подпись сер тификатов, их распределение и пр.); • регистрация фактов компрометации и публикация «чер ных» списков отозванных сертификатов; • поддержка процессов идентификации и аутентификации пользователей таким образом, чтобы сократить, по воз можности, время допуска каждого пользователя в систему; • реализация механизма интеграции (основанного на РКІ) существующих приложений и всех компонентов подсисте мы безопасности; • предоставление возможности использования единственного «токена» безопасности, единообразного для всех пользова телей и приложений, содержащего все необходимые ключе вые компоненты и сертификаты. Токен безопасности — это индивидуальное средство безопас ности, определяющее все права и окружение пользователя в сис теме, например смарт-карта. Приложение, требующее систему управления ключами, должно взаимодействовать с системой РКІ в ряде точек (передача сертификата на подпись, получение сертификата и «черного» списка при установлении взаимодействия и т. п.). Очевидно, что это взаимодействие с чуждой по отношению к данному приложе нию системой может осуществляться только при условии полной поддержки международных стандартов, которым удовлетворяет большинство современных РКІ-систем (например, Baltimore, Entrust, Verisign). Для предоставления удаленного доступа мобильным пользо вателям центр управления должен допускать подключение ком пьютеров, IP-адрес которых ему заранее неизвестен. Участники информационного обмена опознаются по их криптографическим сертификатам. Так как криптографический сертификат пользо вателя является электронным паспортом, он, как и любой пас порт, должен соответствовать определенным стандартам. В крип тографии это стандарт Х.509. На рис. 13.11 приведена логическая структура и основные компоненты инфраструктуры управления открытыми ключа ми РКІ. Каталог сертификатов Рис. 13.11. Структура РКІ Компоненты этой структуры имеют следующее назначение. Каталог сертификатов — общедоступное хранилище серти фикатов пользователей. Доступ к сертификатам производится обычно по стандартизованному протоколу доступа к каталогам LDAP (Lightweight Directory Access Protocol). Центр регистрации RA (Registration Authority) — организаци онная единица, назначение которой — регистрация пользовате лей системы. Пользователь — владелец какого-либо сертификата (такой пользователь подлежит регистрации) или любой пользователь, за прашивающий сертификат, хранящийся в каталоге сертификатов. Центр сертификации СА (Certification Authority) — организа ционная единица, назначение которой — сертификация откры тых ключей пользователей (здесь из открытого ключа получается сертификат формата Х.509) и их опубликование в каталоге сер тификатов. Общая схема работы СА выглядит следующим образом: • СА генерирует собственные ключи и формирует сертифи каты СА, предназначенные для проверки сертификатов пользователей; • пользователи формируют запросы на сертификацию и дос тавляют их СА тем или иным способом; • СА на основе запросов пользователей формирует сертифи каты пользователей; • СА формирует и периодически обновляет списки отменен ных сертификатов CRL (Certificate Revocation List); • сертификаты пользователей, сертификаты СА и списки от мены CRL публикуются СА (рассылаются пользователям либо помещаются в общедоступный справочник). Инфраструктуру открытых ключей РКІ поддерживает ряд ОС, приложений и стандартов. В свою очередь инфраструктура открытых ключей РКІ может интегрировать перечисленные функциональные области. В ре зультате можно создавать комплексную систему информацион ной безопасности путем интеграции инфраструктуры открытых ключей в ИС компании и использования единых стандартов и сертификатов открытых ключей. Часть 4 ТЕХНОЛОГИИ ОБНАРУЖЕНИЯ ВТОРЖЕНИЙ Еще несколько лет назад можно было надежно обеспечить безопасность ИС, используя такие традиционные средства защи ты как идентификация и аутентификация, разграничение досту па, шифрование и т. п. Однако с появлением и развитием откры тых компьютерных сетей ситуация резко изменилась. Количество уязвимостей сетевых ОС, прикладных программ и возможных атак на КИС постоянно растет. Системы анализа защищенности и системы обнаружения компьютерных атак являются важными элементами системы безопасности сетей любого современного предприятия. Сегодня уже никого не надо убеждать в необходимости по строения антивирусной защиты любой достаточно ответствен ной ИС. По оценкам западных аналитиков, ежегодный общеми ровой ущерб от вторжений вирусов, сетевых червей, троянских коней и прочих вредоносных программ составляет миллиарды долларов. Ежедневно в мире появляются от 2 до 10 новых виру сов. В условиях, когда компьютерные системы становятся осно вой бизнеса, а БД главным капиталом многих компаний, анти вирусная защита прочно встает рядом с вопросами информаци онной и экономической безопасности организации. Эффективность защиты КИС зависит от принятия правиль ных решений, которые поддерживают защиту, адаптирующуюся к изменяющимся условиям сетевого окружения. Решение про блем безопасности КИС требует применения адаптивного меха низма, работающего в реальном режиме времени и обладающего высокой чувствительностью к изменениям в информационной инфраструктуре. |