безопасность сетей и каналов передачи данных. Тема Проблемы информационной безопасности сетей Содержание темы
 Скачать 1.46 Mb.
|
|
Централизованный контроль удаленного доступа. Для управления удаленными соединениями небольшой локальной сети вполне достаточно одного сервера удаленного доступа. Однако если локальная сеть объединяет относительно большие сегменты и число удаленных пользователей существенно возрастает, то одного сервера удаленного доступа недостаточно. При использовании в одной локальной сети нескольких серверов удаленного доступа требуется централизованный контроль доступа к компьютерным ресурсам. Рассмотрим, как решается задача контроля доступа к сети удаленных пользователей в соответствии с обычной схемой, когда удаленные пользователи пытаются получить доступ к сетевым ресурсам, которые находятся под управлением нескольких разных ОС. Пользователь дозванивается до своего сервера удаленного доступа, и RAS выполняет для него процедуру аутентификации, например по протоколу CHAP. Пользователь логически входит в сеть и обращается к нужному серверу, где снова проходит аутентификацию и авторизацию, в результате чего получает или не получает разрешение на выполнение запрошенной операции. Нетрудно заметить, что такая схема неудобна пользователю, поскольку ему приходится несколько раз выполнять аутентификацию при входе в сеть на сервере удаленного доступа, а потом еще каждый раз при обращении к каждому ресурсному серверу сети. Пользователь вынужден запоминать несколько разных паролей. Кроме того, он должен знать порядок прохождения разных процедур аутентификации в разных ОС. Возникают также трудности с администрированием такой сети. Администратор должен заводить учетную информацию о каждом пользователе на каждом сервере. Эти разрозненные БД трудно поддерживать в корректном состоянии. При увольнении сотрудника сложно исключить его из всех списков. Возникают проблемы при назначении паролей, существенно затрудняется аудит. Отмеченные трудности преодолеваются при установке в сети централизованной службы аутентификации и авторизации. Для централизованного контроля доступа выделяется отдельный сервер, называемый сервером аутентификации. Этот сервер служит для проверки подлинности удаленных пользователей, определения их полномочий, а также фиксации и накопления регистрационной информации, связанной с удаленным доступом. Надежность защиты повышается, если сервер удаленного доступа запрашивает необходимую для аутентификации информацию непосредственно у сервера, на котором хранится общая БД системы защиты компьютерной сети. Однако в большинстве случаев серверы удаленного доступа нуждаются в посреднике для взаимодействия с центральной БД системы защиты, например со службой каталогов. Большинство сетевых ОС и служб каталогов сохраняют эталонные пароли пользователей с использованием одностороннего хэширования, что не позволяет серверам удаленного доступа, стандартно реализующим протоколы РАР и CHAP, извлечь открытый эталонный пароль для проверки ответа. Роль посредника во взаимодействии между серверами удаленного доступа и центральной БД системы защиты может быть возложена на сервер аутентификации. Централизованный контроль удаленного доступа к компьютерным ресурсам с помощью сервера аутентификации выполняется на основе специализированных протоколов. Эти протоколы позволяют объединять используемые серверы удаленного доступа и сервер аутентификации в одну подсистему, выполняющую все функции контроля удаленных соединений на основе взаимодействия с центральной БД системы защиты. Сервер аутентификации создает единую точку наблюдения и проверки всех удаленных пользователей и контролирует доступ к компьютерным ресурсам в соответствии с установленными правилами. К наиболее популярным протоколам централизованного контроля доступа к сети удаленных пользователей относятся протоколы TACACS (Terminal Access Controller Access Control System) и RADIUS (Remote Authentication DialIn User Service). Они предназначены в первую очередь для организаций, в центральной сети которых используется несколько серверов удаленного доступа. В этих системах администратор может управлять БД идентификаторов и паролей пользователей, предоставлять им привилегии доступа и вести учет обращений к системным ресурсам. Протоколы TACACS и RADIUS требуют применения отдельного сервера аутентификации, который для проверки подлинности пользователей и определения их полномочий может использовать не только собственную БД, но и взаимодействовать с современными службами каталогов, например с NDS (Novell Directory Services) и Microsoft Windows NT Directory Service. Серверы TACACS и RADIUS выступают в качестве посредников между серверами удаленного доступа, принимающими звонки от пользователей, с одной стороны, и сетевыми ресурсными серверами с другой. Реализации TACACS и RADIUS могут также служить посредниками для внешних систем аутентификации. Рассмотрим особенности централизованного контроля удаленного доступа на примере протокола TACACS (Рис. 47.).  Удаленные пользователи Рис. 47. Схема централизованного контроля удаленного доступа Система TACACS выполнена в архитектуре клиент-сервер. В компьютерной сети, включающей несколько серверов удаленного доступа, устанавливается один сервер аутентификации, который называют сервером TACACS (обычно это программа, работающая в среде универсальной ОС, чаще всего Unix). На сервере TACACS формируется центральная база учетной информации об удаленных пользователях, включающая их имена, пароли и полномочия. В полномочиях каждого пользователя задаются подсети, компьютеры и сервисы, с которыми он может работать, а также различные виды ограничений, например временные ограничения. На этом сервере ведется БД аудита, в которой накапливается регистрационная информация о каждом логическом входе, продолжительности сессии, а также времени использования ресурсов сети. Клиентами сервера TACACS являются серверы удаленного доступа, принимающие запросы на доступ к ресурсам сети от удаленных пользователей. В каждый такой сервер встроено ПО, реализующее стандартный протокол, по которому они взаимодействуют с сервером TACACS. Этот протокол также называется TACACS. Протокол TACACS стандартизует схему взаимодействия серверов удаленного доступа с сервером TACACS на основе задания возможных типов запросов, ответов и соединений. Определены запросы, с которыми клиенты могут обращаться к серверу TACACS. Сервер на каждый запрос должен ответить соответствующим сообщением. Протокол задает несколько типов соединений, каждое из которых определяется как последовательность пар запрос ответ, ориентированная на решение отдельной задачи. Определено три типа соединений: AUTH выполняется только аутентификация; LOGIN выполняется аутентификация и фиксируется логическое соединение с пользователем; SLIP выполняется аутентификация, фиксируется логическое соединение, подтверждается и адрес клиента. С помощью соединения AUTH серверы удаленного доступа перенаправляют серверу TACACS поток запросов на логическое подключение пользователей к сети в целом. Соединение LOGIN служит для перенаправления запросов серверу TACACS на логическое подключение пользователей к отдельным компьютерам локальной сети. При соединении AUTH сервер удаленного доступа посылает на сервер TACACS только одно сообщение пакет AUTH, на который сервер TACACS отвечает сообщением REPLY. Сервер TACACS на основании имеющихся у него данных проверяет пароль и возвращает ответ в виде пакета REPLY, где сообщает об успехе или неуспехе аутентификации. В соответствии с протоколом TACACS пароль передается между сервером удаленного доступа и сервером аутентификации в открытом виде. Поэтому протокол TACACS необходимо применять совместно с протоколом аутентификации по одноразовым паролям, например с протоколом S/Key. На основании полученных от сервера TACACS указаний сервер удаленного доступа выполняет процедуру аутентификации и разрешает или не разрешает удаленному пользователю логически войти в сеть. Сервер TACACS может выполнять аутентификацию и авторизацию удаленных пользователей различными способами: использовать встроенный механизм аутентификации той ОС, под управлением которой работает сервер; использовать централизованные справочные системы ОС; использовать системы аутентификации, основанные на одноразовых паролях, например систему SecurlD; передавать запросы другим системам аутентификации, например, системе Kerberos. Следует отметить, что недостатки протокола TACACS, связанные с открытой передачей пароля по сети, устранены компанией Cisco в версии, названной TACACS+. В соответствии с протоколом TACACS+ пароль для передачи по сети шифруется с помощью алгоритма MD5. TACACS+ предусматривает раздельное хранение БД аутентификационной, авторизационной и учетной информации, в том числе и на разных серверах. Улучшено взаимодействие с системой Kerberos. Другой распространенной системой централизованной аутентификации при удаленном доступе является система RADIUS. По своим функциональным возможностям протоколы TACACS и RADIUS практически эквивалентны и являются открытыми стандартами, однако протокол RADIUS стал более популярен среди производителей систем централизованного контроля удаленного доступа. Это связано с тем, что основанное на нем серверное ПО распространяется бесплатно. Кроме того, протокол RADIUS менее сложен в реализации. Вопрос 3. Управление доступом по схеме однократного входа с авторизацией Single SignOn (SSO). Большинство пользователей информационных средств и систем используют компьютеры для доступа к ряду сервисов будь это несколько локальных приложений или сложные приложения, которые включают одну или более удаленных систем, к которым машина пользователя подсоединяется через сеть. В целях обеспечения безопасности многие приложения требуют проведения аутентификации пользователя, прежде чем ему дадут доступ к сервисам и данным, предоставляемым приложением. Конечные пользователи обычно воспринимают такие требования системы безопасности как дополнительную нагрузку, которая заставляет поддерживать и помнить многочисленные входные идентификаторы и пароли и использовать их каждый день по несколько раз, чтобы иметь возможность выполнять свою обычную работу. Довольно обычна ситуация, когда один пользователь имеет 5 и более таких пользовательских accounts, все на различных платформах, с различными правилами для длин паролей, а также с различной частотой их замены. Пользователь должен либо заучивать их, либо записывать, подвергая тем самым безопасность серьезному риску, так как их и могут найти неавторизованные пользователи. С увеличением числа требующих запоминания паролей, возрастает вероятность того, что эти пароли будут забываться, а это потребует от администраторов дополнительных усилий по их восстановлению. Эту проблему часто называют «проблемой многих входов». Ее позволяет решить схема однократного входа с авторизацией SSO (Single Sign On). Управление доступом по схеме SSO дает возможность пользователям корпоративной сети при их входе в сеть пройти одну аутентификацию, предъявив только один раз пароль (или иной требуемый аутентификатор), и затем без дополнительной аутентификации получить доступ ко всем авторизованным сетевым ресурсам, которые нужны для выполнения их работы. Такими сетевыми ресурсами могут быть принтеры, приложения, файлы и другие данные, размещаемые по всему предприятию на серверах различных типов, работающих на базе различных ОС. Управление доступом по схеме SSO позволяет повысить производительность труда пользователей сети, уменьшить стоимость сетевых операций и улучшить сетевую безопасность. С функционированием схемы SSO непосредственно связаны процессы аутентификации и авторизации. С помощью аутентификации система проверяет подлинность пользователя, в то время как авторизация определяет, что именно разрешается делать пользователю (обычно основываясь на его роли в организации). Большинство подходов SSO централизованно осуществляют аутентификацию пользователя. Авторизацию обычно выполняют на ресурсах целевых объектов, хотя некоторые продвинутые SSO-решения централизованно осуществляют и авторизацию, при этом используются продукты централизованного администрирования безопасности, которые осуществляют администрирование полномочий пользователей. Схему SSO поддерживают такие средства, как протокол LDAP (Lightweight Directory Access Protocol), протокол SSL (Secure Sockets Layer), система Kerberos и инфраструктура управления открытыми ключами PKI (Public Key Infrastructure), а также средства интеграции сервисов каталогов и безопасности. Эти средства и технологии образуют вместе фундамент для применения схемы SSO при обработке данных системами, использующими различные комбинации клиентов, серверов, сервисов и приложений. Существующие решения схемы SSO простираются от простых средств до SSO-сервисов на базе сетевых ОС NOS (Network Operating System), многофункциональных приложений и SSO уровня предприятия. Простые средства SSO включают кэш паролей Windows и кэш паролей, встроенный в продукты, подобные Internet Explorer и другие пакеты. NOSbased SSO-сервисы дают возможность пользователю входить в такие сетевые ОС, как Windows NT/2000/XP, NetWare или Solaris, и таким образом получать доступ ко многим или ко всем приложениям, работающим на базе NOS. Продукты SSO уровня предприятия, такие как IBM's Global SignOn и др., обычно применяют комбинированные подходы к SignOn, основанные на использовании клиентов и proxy, технологии и стандарты кратной аутентификации, включая ввод ID пользователя и пароля. Простая система однократного входа SSO. Простое SSO решение состоит в том, чтобы просто автоматизировать процесс предъявления пароля. Для многих из продуктов SSO информация входа (т. е. имя пользователя и пароль) и любые необходимые записи хранятся в специальном сервере аутентификации. Используя клиентское ПО, пользователь предъявляет серверу аутентификации пароль, и этот сервер сообщает клиентскому ПО, к каким ресурсам может получить доступ пользователь (Рис. 48.).  Рис. 48. Простое SSO решение - автоматизация входа Клиентское ПО представляет пользователю допустимые опции. Когда пользователь выберет ресурс, клиентское ПО использует мандат входа и scripts, предоставленные сервером аутентификации, чтобы установить от имени пользователя соединение с соответствующим ресурсом целевого объекта (сервера, хоста, домена или приложения). Клиентское ПО представляет пользователю допустимые опции. Когда пользователь выберет ресурс, клиентское ПО использует мандат входа и scripts, предоставленные сервером аутентификации, чтобы установить от имени пользователя соединение с соответствующим ресурсом целевого объекта (сервера, хоста, домена или приложения). При автоматизации процедуры входа выполняются следующие шаги. 1. Пользователь предъявляет серверу аутентификации пароль, используя специальное клиентское ПО на своем персональном компьютере. 2. Сервер аутентификации проверяет, к каким ресурсам может получить доступ этот пользователь и отправляет эту информацию обратно на клиентское SSO-приложение совместно с необходимым мандатом входа и scripts для соединения с каждым разрешенным ресурсом. 3. Клиентское SSO-приложение представляет пользователю доступные ресурсы и входит от имени пользователя в выбранные приложения. Автоматизация процедуры входа позволяет получить простую схему SSO, но при этом еще больше децентрализуется администрирование безопасностью. Ряд поставщиков предлагает дополнительные средства централизованного администрирования безопасностью. Эти средства используют агентов в целевых системах и обеспечивают основанное на ролях (role-based) централизованное администрирование учетных записей пользователей и информации об их полномочиях. В некоторых случаях эти средства администрирования полностью отделены от схемы SSO; в других — интегрированы с SSO. Первоначальной целью SSO было сокращение числа используемых многоразовых паролей для получения пользователями доступа к сетевым ресурсам. При формировании современного решения SSO применяются также такие средства аутентификации пользователя, как токены, цифровые сертификаты PKI, смарткарты и биометрические устройства. Более совершенный подход к аутентификации обычно основан на использовании токенов. Наиболее известной системой аутентификации является Kerberos. Продвинутые SSO решения предоставляют больше контроля над полномочиями пользователя, поддерживаемыми обычно на прикладном уровне. В продуктах SSO могут быть также поддержаны нетокенные механизмы аутентификации, основанные на сертификатах PKI (в частности, RSA ClearTrust поддерживает PKI). SSO продукты уровня предприятия. SSO продукты уровня предприятия проектируются для больших компаний с гетерогенной распределенной компьютерной средой, состоящей из многих систем и приложений. Характерным представителем SSO продуктов уровня предприятия является продукт IBM Global SignOn for Multiplatforms (далее называемый GSO). Продукт GSO представляет безопасное, простое решение, позволяющее получать доступ к сетевым компьютерным ресурсам, используя однократный вход в систему. GSO освобождает пользователя от необходимости вводить различные идентификаторы и пароли для всех его целевых объектов, которые включают ОС, программные средства коллективного пользования, БД или приложения другого вида. Было бы идеально, если бы GSO мог действовать как универсальный безопасный, надежный механизм аутентификации для любого целевого объекта. К сожалению, такое решение унифицированной аутентификации создать невозможно, потому что большинство продуктов, которым требуется сервис аутентификации, выполняют процедуру аутентификации различными способами. Чтобы сделать реальностью такой идеальный подход, поставщики должны модифицировать свои продукты таким образом, чтобы обеспечить выполнение требований общего стандарта X/Open Single SignOn (XSSO). Поэтому GSO придерживается реального подхода, основанного на том факте, что продукты поставщиков не поддерживают доверенную внешнюю аутентификацию. Для аутентификации эти продукты чаще всего требуют идентификатор ID и пароль каждого пользователя. GSO осуществляет безопасное хранение пользовательских идентификаторов IDs и паролей, а также обеспечение ими целевых объектов, когда пользователю нужно предъявить пароль при входе. Это освобождает пользователя от необходимости помнить и вводить IDs и пароль каждый день для каждого целевого объекта. Ячейка GSO содержит, по крайней мере, сервер GSO и одну рабочую станцию пользователя, называемую также клиентом GSO. В ячейке GSO может быть более одного сервера GSO и множество клиентов (Рис. 49.).  Рис. 49. Базовые компоненты GSO Пользователь взаимодействует со своей рабочей станцией и некоторыми целевыми объектами (приложениями), которые могут выполняться на этой рабочей станции или на каком-либо другом компьютере, например сервере департамента или серверах приложений. Перед тем как начать работу, пользователь должен войти в свою рабочую станцию. Он предъявляет пароль именно GSO, а не приложению или другим серверам. GSO выполняет аутентификацию, основанную на идентификаторе ID и пароле пользователя (иногда поддерживаемых смарткартой или считывателем отпечатков пальцев). Сервер GSO включается в процесс аутентификации, для того чтобы проверить пароль пользователя и извлечь его мандат (credentials). Затем GSO вводит пользователя в целевые объекты (приложения или серверы), с которыми этот пользователь должен работать. GSO использует для входа пользователя методы, предоставляемые целевыми объектами. В большинстве случаев GSO имитирует вход пользователя, передавая целевому объекту ID и пароль пользователя, как будто вводит их сам пользователь. Важное различие, очевидно, состоит в том, что теперь пользователю не нужно запоминать эти идентификаторы ID и пароли, поскольку заботу о них принимает на себя GSO. GSO является клиент/серверным приложением. В дополнение к серверу GSO существует программа клиента (сегмент программного кода), выполняемая на рабочей станции пользователя, которая взаимодействует с сервером GSO. SSO-продукты уровня предприятия обладают следующими достоинствами: допускают использование многих целевых платформ со своими собственными механизмами аутентификации; безопасно хранят в БД учетную информацию пользователей (такую как идентификатор ID, пароль и некоторую дополнительную информацию) на каждую целевую платформу и каждого пользователя; радикально уменьшают долю забываемых паролей, поскольку пароли пользователей хранятся безопасно и надежно; используют методы и средства безопасной аутентификации и коммуникации; чувствительная пользовательская информация хранится и передается по сети только в зашифрованном виде. Недостатками SSO продуктов уровня предприятия является их относительно большая стоимость и высокие требования к квалификации обслуживающего персонала. Вопрос 4. Протокол Kerberos. Протокол Kerberos используется в системах клиент-сервер для аутентификации и обмена ключевой информацией, предназначенной для установления защищенного канала связи между абонентами, работающими как в локальной сети, так и глобальных сетях. Данный протокол встроен в качестве основного протокола аутентификации в Microsoft Windows 2000 и в UNIX BSD. Kerberos обеспечивает аутентификацию в открытых сетях, т.е. при работе Kerberos подразумевается, что злоумышленники могут производить следующие действия: выдавать себя за одну из легитимных сторон сетевого соединения; иметь физический доступ к одному из участвующих в соединении компьютеров; перехватывать любые пакеты, модифицировать их и (или) передавать повторно. Соответственно, обеспечение безопасности в Kerberos построено таким образом, чтобы нейтрализовать любые потенциальные проблемы, которые могут возникнуть из-за указанных действий злоумышленников. Kerberos разработан для сетей TCP/IP и построен на основе доверия участников протокола к третьей (доверенной) стороне. Служба Kerberos, работающая в сети, действует как доверенный посредник, обеспечивая надежную аутентификацию в сети с последующей авторизацией доступа клиента (клиентского приложения) к ресурсам сети. Защищенность установленных в рамках сессии Kerberos соединений обуславливается применением симметричных алгоритмов шифрования. Служба Kerberos разделяет отдельный секретный ключ с каждым субъектом сети, и знание такого секретного ключа равносильно доказательству подлинности субъекта сети. Основу Kerberos составляет протокол аутентификации и распределения ключей Нидхэма Шредера с третьей доверенной стороной. Рассмотрим эту версию протокола. В протоколе Kerberos (версия 5) участвуют две взаимодействующие стороны и доверенный сервер KS, выполняющий роль Центра распределения ключей. Вызывающий (исходный) объект обозначается через А, а вызываемый (объект назначения) через В. Участники сеанса А и В имеют уникальные идентификаторы IdA, и IdB соответственно. Стороны А и В, каждая по отдельности, разделяют свой секретный ключ с сервером KS. Пусть сторона А хочет получить сеансовый ключ для информационного обмена со стороной В. Сторона А инициирует фазу распределения ключей, посылая по сети серверу KS идентификаторы IdA, и IdB:  Сервер KS генерирует сообщение с временной отметкой Т, сроком действия L, случайным сеансовым ключом К и идентификатором IdA. Он шифрует это сообщение секретным ключом, который разделяет со стороной В. Затем сервер KS берет временную отметку Т, срок действия L, сеансовый ключ К, идентификатор IdBстороны В и шифрует все это секретным ключом, который разделяет со стороной А. Оба эти зашифрованные сообщения он отправляет стороне А:  Сторона А расшифровывает сообщение своим секретным ключом, проверяет отметку времени Т, чтобы убедиться, что это сообщение не является повторением предыдущей процедуры распределения ключей. Затем сторона А генерирует сообщение со своим идентификатором IdA и отметкой времени Т, шифрует его сеансовым ключом К и отправляет стороне В. Кроме того, А отправляет для В сообщение от KS, зашифрованное ключом стороны В:  Только сторона В может расшифровать сообщение (3). Сторона В получает отметку времени Т, срок действия L, сеансовый ключ К и идентификатор IdA. Затем сторона В расшифровывает сеансовым ключом К вторую часть сообщения (3). Совпадение значений Т и IdA в двух частях сообщения подтверждают подлинность А по отношению к В. Для взаимного подтверждения подлинности сторона В создает сообщение, состоящее из отметки времени T плюс 1, шифрует его ключом К и отправляет стороне А:  Если после расшифрования сообщения (4) сторона А получает ожидаемый результат, она знает, что на другом конце линии связи находится действительно В. Этот протокол успешно работает при условии, что часы каждого участника синхронизированы с часами сервера KS. Следует отметить, что в этом протоколе необходим обмен с KS для получения сеансового ключа каждый раз, когда А желает установить связь с B. Протокол обеспечивает надежное соединение объектов А и В при условии, что ни один из ключей не скомпрометирован и сервер KS защищен. Система Kerberos имеет структуру типа клиентсервер и состоит из клиентских частей C, установленных на всех рабочих станциях пользователей и серверах сети, и сервера Kerberos KS, располагающегося на каком-либо (не обязательно выделенном) компьютере (Рис. 50.).  Рис. 50. Схема работы протокола Kerberos Клиентами могут быть пользователи, а также независимые программы, выполняющие такие действия, как загрузка удаленных файлов, отправка сообщений, доступ к БД, доступ к принтерам, получение привилегий у администратора и т. п. Сервер Kerberos KS, можно разделить на две части: сервер аутентификации AS (Authentication Server) и сервер службы выдачи мандатов TGS (Ticket Granting Service). Физически эти серверы могут быть совмещены. Информационными ресурсами, необходимыми клиентам С, управляет сервер информационных ресурсов RS. Предполагается, что серверы службы Kerberos надежно защищены от физического доступа злоумышленников. Сетевые службы, требующие проверки подлинности, и клиенты, которые хотят использовать эти службы, регистрируют в Kerberos свои секретные ключи. Kerberos хранит БД о клиентах и их секретных ключах. Наличие в этой БД секретных ключей каждого пользователя и ресурсов сети, поддерживающих этот протокол, позволяет создавать зашифрованные сообщения, направляемые клиенту или серверу; успешное расшифрование этих сообщений и является гарантией прохождения аутентификации всеми участниками протокола. Kerberos также создает сеансовые ключи (session key), которые выдаются клиенту и серверу (или двум клиентам) и никому больше. Сеансовый ключ используется для шифрования сообщений, которыми обмениваются две стороны, и уничтожается после окончания сеанса. Область действия системы Kerberos распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в БД сервера Kerberos. Укрупнено процесс идентификации и аутентификации пользователя в системе Kerberos версии 5 можно описать следующим образом (Рис. 50). Клиент С, желая получить доступ к ресурсу сети, направляет запрос серверу аутентификации AS. Сервер AS идентифицирует пользователя с помощью его имени и пароля и высылает клиенту мандат (ticket) на доступ к серверу службы выделения мандатов TGS (TicketGranting Service). Для использования конкретного целевого сервера информационных ресурсов RS клиент С запрашивает у TGS мандат на обращение к целевому серверу RS. Если все в порядке, TGS разрешает использование необходимых ресурсов сети и посылает соответствующий мандат клиенту С. Основные шаги работы системы Kerberos (см. Рис. 50.): 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 может использоваться в сочетании с различными криптографическими схемами, включая шифрование с открытым ключом. Вопрос 5. Инфраструктура управления открытыми ключами PKI. Исторически в задачи любого центра управления информационной безопасностью всегда входил набор задач по управлению ключами, используемыми различными средствами защиты информации (СЗИ). В этот набор входят выдача, обновление, отмена и распространение ключей. В случае использования симметричной криптографии задача распространения секретных ключей представляла наиболее трудную проблему, поскольку: для N пользователей необходимо распространить в защищенном режиме N(N 1)/2 ключей, что обременительно при N порядка нескольких сотен; система распространения ключей сложна (много ключей и закрытый канал распространения), что приводит к появлению уязвимых мест. Асимметричная криптография позволяет обойти эту проблему, предложив к использованию только N секретных ключей. При этом у каждого пользователя только один секретный ключ и один открытый, полученный по специальному алгоритму из секретного. Из открытого ключа практически невозможно получить секретный, поэтому открытый ключ можно распространять открытым способом всем участникам взаимодействия. На основании своего закрытого ключа и открытого ключа своего партнера по взаимодействию любой участник может выполнять любые криптографические операции: электронно-цифровую подпись, расчет разделяемого секрета, защиту конфиденциальности и целостности сообщения. В результате решаются две главные проблемы симметричной криптографии: перегруженность количеством ключей их теперь всего N; сложность распространения их можно распространять открыто. Однако у этой технологии есть один недостаток подверженность атаке man-in-the-middle (человек-в-середине), когда атакующий злоумышленник расположен между участниками взаимодействия. В этом случае появляется риск подмены передаваемых открытых ключей. Инфраструктура управления открытыми ключами PKI (Public Key Infrastructure) позволяет преодолеть этот недостаток и обеспечить эффективную защиту от атаки man-in-the-middle. Принципы функционирования PKI. Инфраструктура открытых ключей PKI предназначена для надежного функционирования КИС и позволяет как внутренним, так и внешним пользователям безопасно обмениваться информацией с помощью цепочки доверительных отношений. Инфраструктура открытых ключей основывается на цифровых сертификатах, которые действуют подобно электронным паспортам, связывающим индивидуальный секретный ключ пользователя с его открытым ключом. Защита от атаки man-in-the-middle. При осуществлении атаки man-in-the-middle атакующий может незаметно заменить передаваемые по открытому каналу открытые ключи законных участников взаимодействия на свой открытый ключ, создать разделяемые секреты с каждым из законных участников и затем перехватывать и расшифровывать все их сообщения. Поясним на примере (Рис. 51.) действия атакующего и способ защиты от этой атаки. Предположим, что пользователь 1 и пользователь 2 решили установить защищенное соединение, рассчитав общий для них разделяемый секрет по схеме Диффи Хеллмана. Однако в момент передачи по открытому каналу открытых ключей K10и K20пользователей 1 и 2 злоумышленник @ перехватил эти ключи, не дав им дойти до адресатов. Создав свои закрытый и открытый ключи, злоумышленник @ передает свой открытый ключ K@ пользователям 1 и 2, незаметно подменив своим ключом K@0их подлинные открытые ключи K10и K20. В результате пользователи 1 и 2 создадут разделяемые секреты не между собою, а между 1 ↔ @ и 2 ↔@, поскольку они будут использовать свои закрытые ключи K1cи K2c и открытый ключ K@ злоумышленника @.  Рис. 51. Осуществление атаки man-in-the-middle Когда пользователь 1 будет отправлять пользователю 2 зашифрованную информацию, злоумышленник @ может ее перехватить и расшифровать (у него с пользователем 1 свой разделяемый секрет R@i). Затем злоумышленник @ зашифрует информацию (возможно, измененную) заново, используя второй разделяемый секрет К@2, рассчитанный им и пользователем 2. В результате пользователь 2 будет получать, расшифровывать и использовать информацию, отправленную злоумышленником @, полагая, что он имеет защищенный канал с пользователем 1. Эта простая, но результативная атака является расплатой за изящное решение задачи распределения ключей, предложенное асимметричной криптографией. Проблема подмены открытых ключей успешно решается путем использования сертификатов открытых ключей. Сертификаты открытых ключей. Сертификаты открытых ключей играют важную роль в криптографии открытых ключей. Их основное назначение сделать доступным и достоверным открытый ключ пользователя. В основу формирования сертификатов открытых ключей положены принципы строгой аутентификации, рекомендованные стандартом Х.509 и базирующиеся на свойствах криптосистем с открытым ключом. Криптосистемы с открытым ключом предполагают наличие у пользователя парных ключей секретного и открытого (общедоступного). Каждый пользователь идентифицируется с помощью своего секретного ключа. С помощью парного открытого ключа любой другой пользователь имеет возможность определить, является ли его партнер по связи подлинным владельцем секретного ключа. Процедура, позволяющая каждому пользователю устанавливать однозначное и достоверное соответствие между открытым ключом и его владельцем, обеспечивается с помощью механизма сертификации открытых ключей. Степень достоверности факта установления подлинности (аутентификации) пользователя зависит от надежности хранения секретного ключа и надежности источника поставки открытых ключей пользователей. Чтобы пользователь мог доверять процессу аутентификации, он должен извлекать открытый ключ другого пользователя из надежного источника, которому он доверяет. Таким источником согласно стандарту Х.509 является Центр сертификации СА (Certification Authority). Его называют также Удостоверяющий центр УЦ; последний термин используется, в частности, в отечественном «Законе об ЭЦП». Центр сертификации СА является доверенной третьей стороной, обеспечивающей аутентификацию открытых ключей, содержащихся в сертификатах. СА имеет собственную пару ключей (открытый/секретный), где секретный ключ СА используется для подписывания сертификатов, а открытый ключ СА публикуется и используется пользователями для проверки подлинности открытого ключа, содержащегося в сертификате. Сертификация открытого ключа это подтверждение подлинности открытого ключа и хранимой совместно с ним служебной информацией, в частности о принадлежности ключа. Сертификация ключа выполняется путем вычисления ЭЦП сертифицируемого ключа и служебной информации с помощью специального секретного ключа сертификата, доступного только СА. Иными словами, сертификация открытого ключа это подписывание открытого ключа электронной подписью, вычисленной на секретном ключе СА. Открытый ключ совместно с сертифицирующей его ЭЦП часто называют сертификатом открытого ключа или просто сертификатом. СА формирует сертификат открытого ключа пользователя путем заверения цифровой подписью СА определенного набора данных. В соответствии с форматом Х.509 в этот набор данных включаются: период действия открытого ключа, состоящий из двух дат: начала и конца периода; номер и серия ключа; уникальное имя пользователя; информация об открытом ключе пользователя: идентификатор алгоритма, для которого предназначен данный ключ, и собственно открытый ключ; ЭЦП и информация, используемая при проведении процедуры проверки ЭЦП (например, идентификатор алгоритма генерации ЭЦП); уникальное имя сертификационного центра. Таким образом, цифровой сертификат содержит три главные составляющие: информацию о пользователе владельце сертификата; открытый ключ пользователя; сертифицирующую ЭЦП двух предыдущих составляющих, вычисленную на секретном ключе СА. Сертификат открытого ключа обладает следующими свойствами: каждый пользователь, имеющий доступ к открытому ключу СА, может извлечь открытый ключ, включенный в сертификат; ни одна сторона, помимо СА, не может изменить сертификат так, чтобы это не было обнаружено (сертификаты нельзя подделать). Так как сертификаты не могут быть подделаны, то их можно опубликовать, поместив в общедоступный справочник не предпринимая специальных усилий по защите этих сертификатов. Создание сертификата открытого ключа начинается с создания пары ключей (открытый/секретный). Процедура генерации ключей может осуществляться двумя способами: 1. СА создает пару ключей. Открытый ключ заносится в сертификат, а парный ему секретный ключ передается пользователю с обеспечением аутентификации пользователя и конфиденциальности передачи ключа. 2. Пользователь сам создает пару ключей. Секретный ключ сохраняется у пользователя, а открытый ключ передается по защищенному каналу в СА. Каждый пользователь может быть владельцем одного или нескольких сертификатов, сформированных сертификационным центром СА пользователя. Пользователь может владеть сертификатами, полученными из нескольких разных сертификационных центров. На практике часто возникает потребность аутентифицировать пользователя, который получает сертификаты в другом сертификационном центре. Принципы распределенного администрирования рассматриваются ниже. Базовые модели сертификации. Концепция инфраструктуры открытых ключей PKI подразумевает, что все сертификаты конкретной PKI (своя PKI может быть у любой организации или организационной единицы) организованы в определенную структуру. В PKI различают четыре типа сертификатов. 1. Сертификат конечного пользователя (описанный выше). 2. Сертификат СА. Должен быть доступен для проверки ЭЦП сертификата конечного пользователя и подписан секретным ключом СА верхнего уровня, причем эта ЭЦП также должна проверяться, для чего должен быть доступен сертификат СА верхнего уровня, и т.д. 3. Самоподписанный сертификат. Является корневым идя всей PKI и доверенным по определению в результате проверки цепочки сертификатов СА выяснится, что один из них подписан корневым секретным ключом, после чего процесс проверки ЭЦП сертификатов заканчивается. 4. Кросссертификат. Позволяет расширить действие конкретной PKI путем взаимоподписания корневых сертификатов двух разных PKI. Существуют три базовые модели сертификации: иерархическая модель, основанная на иерархической цепи сертификатов; модель кросссертификации (подразумевает взаимную сертификацию); сетевая (гибридная) модель, включающая элементы иерархической и взаимной сертификации. Обобщенные схемы иерархической и сетевой архитектуры систем управления сертификатами приведены на Рис. 52.  Рис. 52. Иерархическая и сетевая архитектуры систем управления сертификатами В иерархической модели СА расположены в иерархическом подчинении доверенному (корневому) СА, предоставляющему сертификаты другим СА. Достоинства иерархической архитектуры системы управления сертификатами: аналогична существующим федеральным и ведомственным организационно-управляющим структурам и может строиться с учетом этого; определяет простой алгоритм поиска, построения и верификации цепочек сертификатов для всех взаимодействующих сторон; для обеспечения взаимодействия двух пользователей одному из них достаточно предоставить другому свою цепочку сертификатов, что уменьшает проблемы, связанные с их взаимодействием. Недостаток иерархической архитектуры: для обеспечения взаимодействия всех конечных пользователей должен быть только один корневой доверенный СА. В модели кросс-сертификации независимые СА, не находящиеся на одной ветви иерархии, взаимно сертифицируют друг друга в сети СА. Кросс-сертификация является предметом двустороннего соглашения между СА. Следует отметить, что модель кросс-сертификации является частным случаем сетевой архитектуры системы управления сертификатами. Достоинства сетевой архитектуры системы управления сертификатами: гибкость, что способствует установлению непосредственных доверенных взаимоотношений, существующих в современном бизнесе; отношения доверия в системе: конечный пользователь должен доверять, по крайней мере, только центру, издавшему его сертификат; возможность непосредственной кросс-сертификации различных удостоверяющих СА, пользователи которых часто взаимодействуют между собой, что сокращает процесс верификации цепочек. Недостатки сетевой архитектуры управления сертификатами: сложность алгоритма поиска и построения цепочек сертификатов для всех взаимодействующих сторон; невозможность предоставления пользователем цепочки, которая обеспечивает проверку его сертификата всеми остальными пользователями. Вероятно, в недалеком будущем на самом высоком уровне иерархии сертификации должен оказаться государственный нотариус, который обеспечит связь цепочек доверия разных организаций. Логическая структура и компоненты PKI. Инфраструктура открытых ключей PKI (Public Key Infrastructure) это набор агентов и правил, предназначенных для управления ключами, политикой безопасности и собственно обменом защищенными сообщениями. Основные задачи PKI: поддержка жизненного цикла цифровых ключей и сертификатов (т. е. генерация ключей, создание и подпись сертификатов, их распределение и пр.); регистрация фактов компрометации и публикация «черных» списков отозванных сертификатов; поддержка процессов идентификации и аутентификации пользователей таким образом, чтобы сократить, по возможности, время допуска каждого пользователя в систему; реализация механизма интеграции (основанного на PKI) существующих приложений и всех компонентов подсистемы безопасности; предоставление возможности использования единственного «токена» безопасности, единообразного для всех пользователей и приложений, содержащего все необходимые ключевые компоненты и сертификаты. Токен безопасности это индивидуальное средство безопасности, определяющее все права и окружение пользователя в системе, например смарткарта. Приложение, требующее систему управления ключами, должно взаимодействовать с системой PKI в ряде точек (передача сертификата на подпись, получение сертификата и «черного» списка при установлении взаимодействия и т. п.). Очевидно, что это взаимодействие с чуждой по отношению к данному приложению системой может осуществляться только при условии полной поддержки международных стандартов, которым удовлетворяет большинство современных HS-систем (например, Baltimore, Entrust, Verisign). Для предоставления удаленного доступа мобильным пользователям центр управления должен допускать подключение компьютеров, П>адрес которых ему заранее неизвестен. Участники информационного обмена опознаются по их криптографическим сертификатам. Так как криптографический сертификат пользователя является электронным паспортом, он, как и любой паспорт, должен соответствовать определенным стандартам. В криптографии это стандарт Х.509. На Рис. 53. приведена логическая структура и основные компоненты инфраструктуры управления открытыми ключами PKI.  Рис. 53. Структура PKI Компоненты этой структуры имеют следующее назначение. Каталог сертификатов общедоступное хранилище сертификатов пользователей. Доступ к сертификатам производится обычно по стандартизованному протоколу доступа к каталогам LDAP (Lightweight Directory Access Protocol). Центр регистрации RA (Registration Authority) организационная единица, назначение которой регистрация пользователей системы. Пользователь владелец какого-либо сертификата (такой пользователь подлежит регистрации) или любой пользователь, запрашивающий сертификат, хранящийся в каталоге сертификатов. Центр сертификации СА (Certification Authority) организационная единица, назначение которой сертификация открытых ключей пользователей (здесь из открытого ключа получается сертификат формата Х.509) и их опубликование в каталоге сертификатов. Общая схема работы СА выглядит следующим образом: СА генерирует собственные ключи и формирует сертификаты СА, предназначенные для проверки сертификатов пользователей; пользователи формируют запросы на сертификацию и доставляют их СА тем или иным способом; СА на основе запросов пользователей формирует сертификаты пользователей; СА формирует и периодически обновляет списки отмененных сертификатов CRL (Certificate Revocation List); сертификаты пользователей, сертификаты СА и списки отмены CRL публикуются СА (рассылаются пользователям либо помещаются в общедоступный справочник). Инфраструктуру открытых ключей PKI поддерживает ряд ОС, приложений и стандартов. В свою очередь инфраструктура открытых ключей PKI может интегрировать перечисленные функциональные области. В результате можно создавать комплексную систему информационной безопасности путем интеграции инфраструктуры открытых ключей в ИС компании и использования единых стандартов и сертификатов открытых ключей. |