 |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
Иерархия технологий защищенного канала
|
|
Защищенный канал можно построить с помощью системных средств, реализованных на разных уровнях модели OSI (рис. 24.27).
Рис. 24.27. Протоколы, формирующие защищенный канал на разных уровнях модели OSI
Если защита данных осуществляется средствами верхних уровней (прикладного, представления или сеансового), то такой способ защиты не зависит от технологий транспортировки данных (IP или IPX, Ethernet или ATM), что можно считать несомненным достоинством. В то же время приложения при этом становятся зависимыми от конкретного протокола защищенного канала, так как в них должны быть встроены явные вызовы функций этого протокола.
Защищенный канал, реализованный на самом высоком (прикладном) уровне, защищает только вполне определенную сетевую службу, например файловую, гипертекстовую или почтовую. Так, протокол S/MIME защищает исключительно сообщения электронной почты. При таком подходе для каждой службы необходимо разрабатывать собственную защищенную версию протокола.
Популярный протокол SSL [82] (Secure Socket Layer — слой защищенных сокетов) работает на уровне представления и создает защищенный канал, используя следующие технологии безопасности:
□ взаимная аутентификация приложений на обоих концах защищенного канала выполняется путем обмена сертификатами (стандарт Х.509);
□ для контроля целостности передаваемых данных используются дайджесты;
□ секретность обеспечивается шифрацией со средствами симметричных ключей сеанса.
Протокол SSL разработан компанией Netscape Communications для защиты данных, передаваемых между веб-сервером и веб-браузером, но он может быть использован и любыми другими приложениями. Работа протокола защищенного канала на уровне представления делает его более универсальным средством, чем протокол безопасности прикладного уровня. Однако для того чтобы приложение смогло воспользоваться протоколом уровня представления, в него по-прежнему приходится вносить исправления, хотя и не столь существенные, как в случае протокола прикладного уровня. Модификация приложения в данном случае сводится к встраиванию явных обращений к API соответствующего протокола безопасности.
Средства защищенного канала становятся прозрачными для приложений в тех случаях, когда безопасность обеспечивается на сетевом и канальном уровнях. Однако здесь мы сталкиваемся с другой проблемой — зависимостью сервиса защищенного канала от протокола нижнего уровня. Например, протокол РРТР, не являясь протоколом канального уровня, защищает кадры протокола РРР канального уровня, упаковывая их в IP-пакеты. При этом не имеет никакого значения, пакет какого протокола, в свою очередь, упакован в данном РРР-кадре: IP, IPX, SNA или NetBIOS. С одной стороны, это делает сервис РРТР достаточно универсальным, так как клиент сервиса защищенного канала может задействовать любые протоколы в своей сети. С другой стороны, такая схема предъявляет жесткие требования к типу протокола канального уровня, используемому на участке доступа клиента к защищенному каналу — для протокола РРТР таким протоколом может быть только РРР. Хотя протокол РРР очень распространен в линиях доступа, сегодня конкуренцию ему составляют протоколы Gigabit Ethernet и Fast Ethernet, которые все чаще работают не только в локальных, но и глобальных сетях.
Работающий на сетевом уровне протокол IPSec является компромиссным вариантом. С одной стороны, он прозрачен для приложений, с другой — может работать практически во всех сетях, так как основан на широко распространенном протоколе IP и использует любую технологию канального уровня (РРР, Ethernet, ATM и т. д.).
Дата публикования: 2014-10-25; Прочитано: 923 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!
