1. Обобщенная структура территориально распределенной корпоративной сети Типовые методы объединения отдельных сетей офисов в единую кспд
 Скачать 3.9 Mb.
|
|
Цепочка сертификатов. Понятие «Проверка подписи» подразумевает проверку соответствия подписи документу, который подписан этой подписью. Если подпись соответствует документу, документ считается подлинным и корректным. Для проверки подписи используется открытый ключ подписи автора подписи. Но для того, чтобы результат проверки можно было считать надежным, необходимо удостовериться, что сам открытый ключ подписи автора подписи, имеющийся у проверяющего, корректен. Для этого проводится проверка сертификата на этот ключ. Понятие «проверка сертификата» означает проверку подписи под этим сертификатом. Подпись под сертификатом проверяется на открытом ключе того, кто создал и подписал сертификат — т.е. на открытом ключе удостоверяющего центра. Т.е. для того, чтобы результат проверки подписи под документом можно было считать надежным, кроме собственно проверки подписи и проверки сертификата на ключ подписи необходимо удостовериться также и в корректности сертификата удостоверяющего центра. Таким образом, в процессе проверки подписи возникает цепочка сертификатов, каждый из которых проверяется на следующем. Такая цепочка сертификатов называется цепочкой доверия. 83 76. Типы сертификатов. Автоматическая подача заявок. Сертификат - подписанная доверенной стороной связь между идентичностью и еѐ открытым ключом (-ами). В PKI различают четыре типа сертификатов. Сертификат конечного пользователя. Сертификат СА (Certification authority - центра сертификации). Должен быть доступен для проверки ЭЦП сертификата конечного пользователя и подписан секретным ключом СА верхнего уровня, причем эта ЭЦП также должна проверяться, для чего должен быть доступен сертификат СА верхнего уровня, и т. д. Самоподписанный сертификат. Является корневым для всей PKI и доверенным по определению — в результате проверки цепочки сертификатов СА выяснится, что один из них подписан корневым секретным ключом, после чего процесс проверки ЭЦП сертификатов заканчивается. Кросс-сертификат. Позволяет расширить действие конкретной PKI путем взаимоподписания корневых сертификатов двух разных PKI. Новые возможности автоматической подачи заявок позволяют подавать заявки как для компьютеров, так и для пользователей. Член группы администраторов предприятия может задать типы сертификатов, которые следует выдавать автоматически. Администратор предприятия управляет автоматической подачей заявок, с помощью оснастки «Шаблоны сертификатов» определяя разрешения безопасности для шаблонов сертифиткатов. Затем клиент, работающий под управлением Windows XP; или семейства Windows Server 2003, обращается к шаблонам в службе каталогов Active Directory и, если ему разрешен доступ, подает заявку на эти сертификаты. В отличие от изолированных СА (Certificate Authority) СА уровня предприятия обычно настраиваются на автоматический выпуск сертификатов. При этом для заполнения нужных полей сертификата информация берется из Active Directory. Разумеется, сертификаты для более важных целей (например, смарт-карты) можно выпускать вручную – такой метод дает возможность более строго контролировать процесс сертификации. СА использует шаблоны сертификатов для автоматизации формирования сертификатов из запросов. Шаблоны сертификатов хранятся в Active Directory, поэтому, сконфигурировав шаблон на одном СА, вы будете иметь доступ к этому шаблону на любом другом СА в лесу. Это означает также и то, что, удалив шаблон, вы удалите его из Active Directory, и он не будет больше доступен нигде. Автоматический выпуск сертификатов настраивается как комбинация доменных политик и шаблонов сертификатов. В результате выпуск сертификатов может стать для пользователя абсолютно прозрачным. Кроме того, это снижает стоимость администрирования всей структуры PKI. 84 77. Аутентификация и авторизация с использованием сертификатов. Авториза ция (разрешение, уполномочивание) — предоставление определѐнному лицу или группе лиц прав на выполнение определѐнных действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. Аутентификация с применением цифровых сертификатов является альтернативой использованию паролей и представляется естественным решением в условиях, когда число пользователей сети (пусть и потенциальных) измеряется миллионами. В таких обстоятельствах процедура предварительной регистрации пользователей, связанная с назначением и хранением их паролей, становится крайне об- ременительной, опасной, а иногда и просто нереализуемой. При использовании сертификатов сеть, которая дает пользователю доступ к своим ресурсам, не хранит никакой информации о своих пользователях — они ее предоставляют сами в своих запросах в виде сертификатов, удостоверяющих личность пользователей. Сертификаты выдаются специальными уполномоченными организациями — центрами сертификации (Ceitificate Authority, CA). Поэтому задача хранения секретной информации (закрытых ключей) возлагается на самих пользователей, что делает это решение гораздо более масштабируемым, чем вариант с использова- нием централизованной базы паролей. Сертификат является аналогом пропуска и выдается по запросам специальными сертифицирующими центрами при выполнении определенных условий. Сертификат представляет собой электронную форму, в которой содержится следующая информация: открытый ключ владельца данного сертификата; сведения о владельце сертификата, такие, например, как имя, адрес электронной почты, наименование организации, в которой он работает, и т. п.; наименование сертифицирующей организации, выдавшей данный сертификат. Кроме того, сертификат содержит электронную подпись сертифицирующей организации — зашифрованные закрытым ключом этой организации данные, содержащиеся в сертификате. Когда пользователь хочет подтвердить свою личность, он предъявляет свой сертификат в двух формах — открытой (то есть такой, в которой он получил его в сертифицирующей организации) и зашифрованной с применением своего закрытого ключа (рисунок). Сторона, проводящая аутентификацию, берет из открытого сертификата открытый ключ пользователя и расшифровывает с помощью него зашифрованный сертификат. Совпадение результата с открытым сертификатом подтверждает факт, что предъявитель действительно является владельцем закрытого ключа, парного с указанным открытым. Рисунок – Аутентификация пользователей на основе сертификатов Затем с помощью известного открытого ключа указанной в сертификате организации проводится расшифровка подписи этой организации в сертификате. Если в результате получается тот же сертификат с тем же именем пользователя и его открытым ключом — значит, он действительно прошел регистрацию в сертификационном центре, является тем, за кого себя выдает, и указанный в сертификате открытый ключ действительно принадлежит ему. Сертификаты можно использовать не только для аутентификации, но и для предоставления избирательных прав доступа. Для этого в сертификат могут вводиться дополнительные поля, в которых указывается принадлежность его владельцев той или иной категории пользователей. Эта категория назначается сертифицирующей организацией в зависимости от условий, на которых выдается сертификат. Сертификат является не только удостоверением личности, но и удостоверением принадлежности открытого ключа. ЦИФРОВОЙ сертификат устанавливает и гарантирует соответствие между открытым ключом и его владельцем. Это предотвращает угрозу подмены открытого ключа. Если некоторому абоненту поступает открытый ключ в составе сертификата, то он может быть уверен, что этот открытый ключ гаран- тированно принадлежит отправителю, адрес и другие сведения о котором содержатся в этом сертификате. При использовании сертификатов отпадает необходимость хранить на серверах корпораций списки пользователей с их паролями, вместо этого достаточно иметь на сервере список имен и открытых ключей сертифицирующих организаций. Может также понадобиться некоторый механизм отображений категорий владельцев сертификатов на традиционные группы пользователей для того, чтобы можно было использовать в неизменном виде механизмы управления избирательным доступом большинства операционных систем или приложений. 85 78. Целостность, конфиденциальность данных. Цифровые подписи. Конфиденциальность (confidentiality) — гарантия того, что секретные данные будут доступны только тем пользователям, которым этот доступ разрешен (такие пользователи называются авторизованными). Доступность (availability) — гарантия того, что авторизованные пользователи всегда получат доступ к данным. Целостность (integrity) — гарантия сохранности данными правильных значений, которая обеспечивается запретом для неавторизованных пользователей каким-либо образом изменять, модифицировать, разрушать или создавать данные. Электро нная по дпись (ЭП), Электро нная цифровая по дпись (ЭЦП) — реквизит электронного документа, полученный в результате криптографического преобразования информации с использованием закрытого ключа подписи и позволяющий установить отсутствие искажения информации в электронном документе с момента формирования подписи и проверить принадлежность подписи владельцу сертификата ключа подписи. Электронная подпись предназначена для идентификации лица, подписавшего электронный документ, и является полноценной заменой (аналогом) собственноручной подписи в случаях, предусмотренных законом. Использование электронной подписи позволяет осуществить: Контроль целостности передаваемого документа: при любом случайном или преднамеренном изменении документа подпись станет недействительной, потому что вычислена она на основании исходного состояния документа и соответствует лишь ему. Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев. Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он не может отказаться от своей подписи под документом. Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он известен только владельцу, он может доказать своѐ авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесѐнные изменения», «метка времени» и т. д. 86 79. Структура пакетов в транспортном режиме аутентификации/шифрования Транспортный режим используется для защиты виртуальных соединений точка-точка. Эта защита осуществляется с использованием аутентификации, шифрования или обоих методов. При транспортном режиме AH IP-пакет модифицируется лишь слегка путем включения AH заголовка между IP заголовком и полем данных (TCP, UDP и т.д.) и перестановки кодов протокола. Перестановка кодов протокола необходима для восстановления исходного вида IP пакетов конечным получателем: после выполнения проверки получателем корректности IPsec заголовка, этот заголовок удаляется, а в поле код протокола IP заносится прежнее значение (TCP, UDP и т.д.). Когда к адресату приходит пакет, успешно прошедший процедуру аутентификации, заголовок AH удаляется, а содержимое поля протокол (=AH) в IP заголовке заменяется запомненным значением поля следующий заголовок. Таким образом, восстанавливается первоначальный вид IP дейтограммы, и пакет может быть передан ожидающему процессу. На рис. 3 показано преобразование форматов заголовков в транспортном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР- сегментом. Закрашенные области защищены аутентификационными данными АН. Поля TOS, TTL, флаги, указатель (фрагмента) и контрольная сумма заголовка не защищаются, так как их содержимое может изменяться в процессе транспортировки, а промежуточные узлы не владеют необходимыми ключами для дешифрования и повторного шифрования. Поля, не охватываемые защитой хэша, перед вычислением ICV заполняются нулями. Рис. 3. Преобразование форматов в транспортном режиме АН IPsec 87 80. Структура пакетов в туннельном режиме аутентификации/шифрования Режим туннеля реализует функциональность VPN, где IP пакет целиком инкапсулируются в другой пакет и в таком виде доставляются адресату. Также как и в транспортном режиме, пакет защищается контрольной суммой ICV, чтобы аутентифицировать отправителя и предотвратить модификацию пакета при транспортировке. Но в отличие от транспортного режима, здесь инкапсулируется весь IP пакет, а это позволяет адресам отправителя и получателя отличаться от адресов, содержащихся в пакете, что позволяет формировать туннель. На рис. 4 показано преобразование форматов заголовков в туннельном режиме IPsec. Слева на рисунке размешен формат исходной дейтограммы с инкапсулированным ТСР-сегментом. Закрашенные области защищены аутентификационными данными АН. Рис. 4. Преобразование форматов в туннельном режиме АН IPsec Когда пакет туннельного режима приходит адресату, он проходит ту же аутентификационную проверку, что и пакет AH-типа, после чего удаляются заголовки IP и AH и восстанавливается первоначальный формат пакета. Большинство реализаций рассматривает оконечную точку туннеля в качестве сетевого интерфейса. Реконструированный пакет может быть доставлен локальной машине или маршрутизован куда- либо еще (согласно IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его транспортировка уже не обеспечивается средствами безопасности IPsec. В то время как транспортный режим используется исключительно для обеспечения безопасной связи между двумя компьютерами, туннельный режим обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами, или отдельными VPN устройствами) для построения VPN (Virtual Private Network). Следует заметить, что в пакете IPsec нет специального поля "режим": которое бы позволяло разделить транспортный режим от туннельного, эту функцию выполняет поле следующий заголовок пакета AH. 88 Когда поле следующий заголовок соответствует IP, это означает, что пакет инкапсулирует всю IP- дейтограмму (туннельный режим), включая независимые адреса отправителя и получателя, которые позволяют реализовать маршрутизацию после туннеля. Любое другое значение поля (TCP, UDP, ICMP и т.д.) означает транспортный режим (безопасная транспортировка по схеме точка-точка). IP дейтограмма верхнего уровня имеет ту же структуру вне зависимости от режима, и промежуточные маршрутизаторы обрабатывают трафик, не анализируя внутреннее содержание IPsec/AH. Заметим, что ЭВМ, в отличие от сетевого шлюза, должна поддерживать как транспортный, так и туннельный режим, но при формировании соединения машина-машина формирование туннеля представляется избыточным. Кроме того, для сетевого шлюза (маршрутизатора, сетевого экрана и т.д.) необходимо поддерживать туннельный режим, в то же время поддержка транспортного режима представляется полезной лишь для случая, когда шлюз сам является конечным адресатом (например, в случае реализации процедур удаленного управления сетью). 89 81. Компоненты IPSec, протоколы согласования, аутентификации, шифрования 1 вариант: Перед началом безопасного обмена данными между двумя хостами должно быть установлено соглашение о способе обмена и защиты данных, которое принимается в процессе переговоров. Это соглашение называется сопоставлением безопасности SA (Security Associations)—безопасное соединение, представляющее собой виртуальный однонаправленный канал для передачи данных. Для двунаправленной связи требуется два SA. Как показано на рисунке 1, путем сопоставления безопасности два хоста принимают соглашение о способе обмена и защиты данных. Для создания соглашения между двумя компьютерами рабочая группа IETF ввела стандартный метод сопоставления безопасности и разрешения обмена ключами, сочетающий использование протокола ISAKMP (Internet Security Association and Key Management Protocol) и протокола создания ключей Oakley. ISAKMP централизует управление сопоставлением безопасности, сокращая время подключения. Oakley создает секретные ключи, используемые для защиты данных, и управляет ими. Для обеспечения успешной безопасной связи ISAKMP/Oakley выполняет две фазы согласования. В первой фазе, или главном режиме (main mode), хосты аутентифицируют друг друга. На этом этапе два компьютера устанавливают первое сопоставление безопасности, называемое согласованием безопасности ISAKMP. Создается общий секретный ключ (основной ключ) для сопоставления безопасности ISAKMP. Обмен ключами как таковыми никогда не выполняется; передаются только общие сведения, необходимые группе Диффи-Хелмана для создания общего секретного ключа. Служба Oakley на каждом из хостов создает основной ключ, используемый для защиты проверки подлинности. Хосты выполняют попытку проверить подлинность предоставленных сведений. Инициирующая сторона посылает отвечающей стороне предлагаемый список возможных уровней безопасности. Отвечающая сторона не может изменить предложение. В случае изменения предложения инициирующая сторона отклоняет сообщение отвечающей стороны. Отвечающая сторона либо отправляет ответ о принятии предложения, либо просто отбрасывает предложение и отправляет сообщение о том, что ни один из предложенных вариантов не был выбран. Затем процесс начинается сначала. Сообщения согласования автоматически повторяются пять раз. Если допускается небезопасная связь с компьютерами, не поддерживающими IPSec, через три секунды устанавливается мягкое сопоставление безопасности. Если отклик ISAKMP будет получен до окончания цикла, мягкое сопоставление безопасности будет удалено и начнется согласование стандартного сопоставления безопасности. Возможное число формируемых сопоставлений безопасности ограничено лишь ресурсами системы. Сопоставление безопасности ISAKMP используется для начала второго фазы согласования безопасности. Во второй фазе, быстром режиме (quick mode), хосты договариваются, какой протокол будет использоваться для цифровой подписи и/или шифрования IP-пакетов. От имени службы IPSec согласовывается пара сопоставлений безопасности IPSec. Обновление сведений о ключе или создание нового ключа выполняется службой Oakley в том случае, если включен режим PFS, или ограничено время жизни ключа или закончился срок действия сопоставления безопасности ISAKMP. Благодаря возможности использовать одно сопоставление безопасности ISAKMP для нескольких согласований сопоставления безопасности IPSec, процесс согласования безопасности выполняется очень быстро. Повторное согласование безопасности и проверка подлинности не требуются до тех пор, пока не закончится срок действия сопоставления безопасности ISAKMP. Число повторов определяется активной политикой IPSec. |