Компоненты и уровни безопасности

IPsec

IPSec является совокупностью протоколов IETF (главным RFC стал RFC 2401, но существует еще множество RFC, относящихся к IPSec). Oсновными протоколами, составляющими IPSec, являются:

Протоколы IPSec обеспечивают безопасность передачи чувствительной информации по незащищенным IP-сетям. IPSec действует на сетевом уровне, защищая и проверяя подлинность IP-пакетов, проходящих между участвующими в обмене равноправными устройствами. В необходимости наличия клиента IPSec подобен SOCKS, однако он не требует прокси-сервера. Сетевые шлюзы IPSec используются как промежуточные сетевые прокси. Как правило, они реализуются в сетевых маршрутизаторах, так как это, по существу, прокси сетевого уровня. Как результат, IPSec обычно более эффективен, чем SOCKS, так как он работает только на трех нижних уровнях модели OSI (физическом, канальном и сетевом). Наибольшую популярность IPSec получил как средство реализации VPN-доступа (VPN – виртуальная частная сеть) из незащищенных сетей (таких, как Интернет) в доверенную, защищенную сеть.

4.1.2 Образцы брандмауэров

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

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

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

Firewall-1 компании Check Point

Изделие Firewall-1 компании Check Point является брандмауэром, популярность которого основана на собственном опыте команды создателей этого курса с сайтами клиентов. Модуль управления позволяет составлять правила для определения конфигурации брандмауэра. После установки конфигурация по умолчанию не позволяет ничему проходить через брандмауэр в любом из направлений. Для разрешения прохождения трафика необходимо определить правила.

Стандартные свойства Firewall-1 включают контроль состояния и трансляцию адресов (NAT). Check Point имеет в своем распоряжении интегрированные изделия для обеспечения таких технических средств, как виртуальная частная сеть (VPN).

За дополнительной информацией обращайтесь к книге Check Point Firewall-1 on AIX: A cookbook for Stand-Alone and High Availability, SG24-5492 или посетите Web-сайт компании Check Point:

http://www.checkpoint.com

Cisco PIX

Брандмауэр Cisco PIX является узкоспециализированным устройством в семействе брандмауэров компании Cisco. Cisco PIX является примером брандмауэра, который при конфигурации по умолчанию использует концепцию безопасных и небезопасных сторон. Это означает, что одна сторона брандмауэра является по умолчанию доверенной [к примеру, демилитаризованная зона (DMZ)] и весь трафик со стороны доверенной и более безопасной стороны может проходить через брандмауэр. По умолчанию весь трафик с другой стороны запрещен до определения особых правил, разрешающих его прохождение. За дополнительной информацией обратитесь к Web-сайту компании Cisco:

http://www.cisco.com

Raptor Firewall

Raptor Firewall является брандмауэром от компании Axent Technologies, дочерней компании Symantec. К особенностям относятся консоль управления Raptor Management Console (RMC) для легкого управления локальными и удаленными брандмауэрами, поддержка VPN на основе стандартов (IPSec и IKE) для соединения с удаленными офисами и пользователями, интегрированные в брандмауэр блокираторы контента для фильтрации групп WWW и Internet Usenet. За дополнительной информацией обратитесь к Web-сайту, посвященному изделиям компании Symantec:

http://www.symantec.com

IBM SecureWay Firewall

Эта технология создания брандмауэров впервые была разработана в процессе научно-исследовательской работы в компании IBM в 1985 г. и защищала ресурсы IBM и глобальных корпораций на протяжении более 10 лет. IBM SecureWay Firewall включает фильтрацию, прокси, шлюз канального уровня и поддержку VPN на основе стандарта IPSec. Более подробную информацию см. в справочниках: A Secure Way to Protect Your Network: IBM Secure Way Firewall for AIX Version 4.1, SG24-5855 и Redhat Linux Integration Guide for IBM eServers xSeries and Netfinity, SG24-5853, либо посетите Web-сайт, посвященный изделиям компании IBM:

http://www.tivoli.com/products/index/firewall

TIS Firewall Toolkit (FWTK)

Компания Trusted Information Systems, Inc. (TIS) разработала инструментарий TIS Internet Firewall Toolkit (FWTK), набор программного обеспечения для построения и эксплуатации брандмауэров сетевых комплексов. Данный набор свободно доступен под лицензией некоммерческого применения и является популярным решением для Linux.

За дополнительной информацией обратитесь по адресу:

http://www.fwtk.org/

TIS слилась с Network Associates в феврале 1998 г. Дополнительную информацию об их коммерческих продуктах можно получить по адресу:

http://www.tis.com/ или http://www.nai.com/

4.1.3 Маршрутизаторы, коммутаторы и концентраторы

Маршрутизаторы (routers), коммутаторы (switches) и концентраторы (hubs) объединены в общую группу, так как все они являются сетевыми аппаратными устройствами, выполняющими свои функции на четырех нижних уровнях модели OSI: физическом, канальном, сетевом и транспортном. Маршрутизаторы и коммутаторы являются активными устройствами, а концентраторы, как правило, являются пассивными устройствами, не обеспечивающими никаких функций безопасности.

Активные сетевые устройства, такие, как коммутаторы и маршрутизаторы, разрабатывались с такими основными целями, как производительность, скорость и удобство. Как результат, функции безопасности у них отчасти слишком просты, за исключением этих функций у устройств из верхних строк прайс-листов. В дополнение к недостатку в усовершенствованных функциях безопасности они часто имеют ограниченные возможности фильтрации для общих протоколов, использующих многочисленные порты (таких, как FTP). Конфигурация списков доступа фильтрации может быть слишком громоздкой и склонной к ошибкам, что противоречит правилу безопасности, которое гласит: "поддерживай небольшой размер и простоту". Коммутаторы и маршрутизаторы зачастую даже имеют встроенные пароли "черного хода", позволяющие хорошо осведомленному злоумышленнику запросто изменить конфигурацию устройства. Коммутаторы и маршрутизаторы обычно конфигурируются с использованием отправки паролей открытым текстом (в незашифрованном виде) по сети. Эти пароли могут быть перехвачены или даже отгаданы и повторно использованы. Коммутаторы и маршрутизаторы могут быть применены для обеспечения дополнительной фильтрации и предупреждения об опасности, но на них никогда не надо надеяться как на основные и надежные средства обеспечения безопасности бизнеса.

Маршрутизаторы

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

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

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

Коммутаторы и концентраторы

Коммутаторы и концентраторы предоставляют виртуальную Ethernet-шину и по большому счету полностью заменили Ethernet, использующий архитектуру физической шины из коаксиального кабеля. Времена просверливания ответвлений в коаксиальном кабеле "толстого Ethernet", к счастью, давно позади. Как упоминалось ранее, преимуществом коммутационной технологии для безопасности является тот факт, что все пакеты в сегменте не передаются на все подключенные к коммутатору устройства. Это значительно уменьшает количество пакетов, которые могут быть "увидены" сниффером, подключенным к одному из портов коммутатора. Исключением из этого правила являются используемые некоторыми протоколами широковещательные пакеты (когда пакеты передаются по всем портам коммутатора).

NAT

Первоначально трансляция сетевых адресов [Network Address Translation (NAT)] была представлена в документе RFC 1918 комитета IETF как кратковременное решение проблемы исчерпания IP-адресов. Для обеспечения в Интернете взаимодействия "любого с любым" все IP-адреса официально задаются Комитетом по цифровым адресам в Интернете [организацией Internet Assigned Numbers Authority (IANA)]. Достичь этого становится все более и более затруднительным, так как количество доступных диапазонов адресов сейчас жестко ограничено. Также в прошлом многие организации использовали локально заданные IP-адреса, не предполагая необходимости в подключении к Интернету. NAT определена в документе RFC 1631.

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

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

Важно заметить, что с использованием NAT преобразовываются только пакеты TCP и UDP. Протокол управляющих сообщений [Internet Control Message Protocol (ICMP)] используется для сообщений и не будет работать в NAT-среде. К примеру, ping является сервисом ICMP, и, когда вы из среды, не использующей NAT, "пингуете" хост в NAT-среде, вы не получите обратного ответа, так как IP-адрес не будет разрешен.

Существует другая функция маршрутизации, относящаяся к NAT и называемая трансляцией адресов портов [Port Address Translation (PAT)]. Она позволяет представить отдельный порт хоста с одной стороны маршрутизатора как другой порт и IPадрес с другой стороны маршрутизатора. Наиболее часто PAT реализуется как часть брандмауэра сеансового уровня, а не сетевого маршрутизатора.

VLAN

Виртуальные ЛВС (VLAN) относятся к довольно современным (с 1998 г.) возможностям, имеющимся в доступных коммутаторах высокого класса. Основной их целью является обеспечение гибкости в разделении коммутаторов по множеству широковещательных доменов ЛВС и облегчения охвата широковещательного домена множеством коммутаторов. VLAN часто используются для улучшения сетевой производительности путем совместной группировки систем, что основывается на интенсивных в широковещательном плане протоколах, таких, как NetBIOS и IPX. Сконфигурированные должным образом виртуальные ЛВС могут быть полезны в обеспечении безопасности, когда они используются для разделения и изоляции и могут устранить потребность в большом количестве меньших выделенных коммутаторов. Также они имеют преимущество, заключающееся в отсутствии ограничения границами отдельного коммутатора, что позволяет при выборе критерия группировки для систем не ограничиваться физическим расположением. Другим важным преимуществом является способность создавать множество подсетей, имея относительно небольшое количество физических сетевых устройств для мониторинга и обслуживания.

При неправильной конфигурации сети VLAN представляют собой некоторый риск для безопасности, чего не случается при использовании для определения границ безопасности выделенных коммутаторов. Хотя определенные на коммутаторе подсети и рассматриваются как "виртуальные", они нуждаются в маршрутизаторе для отправки и приема трафика из других подсетей. Если ваш проект безопасности нуждается в функциях брандмауэра между двумя подсетями, можно выполнить соединение между ними с использованием отдельных (внешних) маршрутизаторов и брандмауэров. Однако большинство коммутаторов высокого класса, такие, как Cisco Catalyst, способны как минимум обеспечивать элементы управления доступом в виде пакетной фильтрации между подсетями на одном и том же коммутаторе. Так как сети VLAN физически объединены на одном и том же коммутаторе, существует риск, что некоторые конфигурации могут позволить фальшивым пакетам попасть из одной VLAN в другую и обойти элементы управления маршрутизатора и брандмауэра между двумя подсетями.

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

Чтобы понять потенциальную уязвимость в безопасности сетей VLAN, вам необходимо понимать основы их работы. По существу, "заголовок тега" вставляется в Еthernet-фрейм сразу за MAC-адресом источника. Тег используется для идентификации того, к какой из VLAN принадлежит фрейм, и позволяет VLAN покрывать множество "магистральных" коммутаторов. Подробности "фреймового тегирования" VLAN расписаны в документе IEEE 802.1q и могут быть найдены по адресу:

http://standards.ieee.org/reading/ieee/std/lanman/802.1Q-1998.pdf

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

4.1.4 Прокси-серверы

Прикладные прокси

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

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

Прокси могут работать в различных направлениях, хотя обычно они предназначаются для работы в отдельном направлении потока данных между клиентом и сервером. Чтобы понять смысл терминологии прокси, помните о том, что в качестве точки отсчета используется внутренняя сеть.

Обратные прокси

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

Прямые прокси

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

Эти высокоуровневые описания двух типов прокси-серверов достаточны для проектирования потоков данных инфраструктуры. Более подробное описание того, как работают прокси и какие расширенные функции они могут предоставлять, можно найти в лекции 5, "Прокси-серверы".

4.1.5 Системы обнаружения вторжений

Существует несколько разновидностей методов, или "систем", обнаружения вторжений. Система обнаружения вторжений [intrusion detection system (IDS)] является системой, специально разработанной и реализованной для обнаружения вторжений. Любая IDS попадает в одну из следующих четырех основных категорий:

Пример программы-монитора активности для обнаружения неудачных попыток входа в систему на сервере Sametime можно найти в справочнике IBM Working with the Sametime Community Server Toolkit, SG24-6667, стр. 63-84. Этот простой пример может быть применим в качестве основы для создания своей собственной элементарной IDS хоста для Lotus Sametime. Однако отметьте, что он не содержит никаких алгоритмов для обнаружения каких-либо закономерностей неудавшихся входов в систему. Так как эти закономерности, или сигнатуры, отображающие атаки, могут быть достаточно сложными и даже изменяющимися по мере изобретения новых методов атак, мы не рекомендуем вам пытаться создавать собственную IDS. Список как общедоступных IDS (с открытым источником), так и коммерческих IDS, появляющихся достаточно своевременно, можно найти на сайте Purdue University COAST (Computer Operations, Audit, and Security Technology):

http://www.cerias.purdue.edu/coast/ids/ids-body.html#systems

Размещение IDS варьируется в зависимости от используемого типа, хотя для IDS на уровне сети и сканеров контента как наиболее соответствующее стремятся выбрать расположение в пределах или около периметров или границ сети. Системы NIDS, как правило, не располагают в сегментах ЛВС по причине большого объема пакетов данных, которые необходимо проверить. Стандартом "передового опыта" для большинства серверов стали расположенные на хосте системы IDS и сканеры контента, а для каждой рабочей станции широко распространенной практикой стало применение ограниченных сканеров контента (таких, как вирус-сканеры). Также на рабочих станциях быстро стало нормой применение "персональных брандмауэров", позволяющих как администратору, так и конечному пользователю блокировать следящие cookies Web-сайта, всплывающие окна и проводить блокировку входящих и исходящих портов/приложений.

4.1.6 Системы управления подлинностью и управления доступом на предприятии

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

Торговая марка IBM Tivoli предоставляет весь набор продуктов управления проверкой подлинности вместе с программой Tivoli Access Manager, обеспечивающей аспекты управления доступом и авторизацией. За дополнительной информацией относительно IBM Tivoli Access Manager и других продуктов Tivoli обратитесь, пожалуйста, к следующим публикациям IBM:

4.1.7 Серверы приложений

Термин "сервер" охватывает широкий спектр типов хостов и служб. С интеграцией основных сетевых служб, таких, как DNS или DHCP, в "сетевые устройства" концепция сервера как физической хост-машины за последние несколько лет изменилась. С точки зрения архитектуры мы должны касаться как внутренней безопасности, защищающей наши основные доступные серверы, так и дополнительной безопасности, которую мы должны предусмотреть путем их размещения внутри общей архитектуры, в связке с другими мероприятиями защитного характера, являющимися внешними для самого сервера.

Основные серверы инфраструктуры

Основными серверами инфраструктуры являются:

Все они подробно описаны в последующих разделах.

DNS

Целью вашей службы имен доменов [domain name service (DNS)] является трансляция имен хостов в IP-адреса и поддержка возможности выполнять обратный поиск, значающий транслирование IP-адресов в имена хостов. Второй функцией является обеспечение других доменов услугой обмена почтой, или MX- записями, регистрирующими хосты, принимающие SMTP-почту для вашего домена.

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

Как минимум внешняя DNS будет обеспечивать трансляцию имен и адресов для самого сервера имен (запись NS) и по меньшей мере одной записи MX. В конце концов, если вы не хотите регистрировать публичный хост обмена почтой, то вам, возможно, не понадобится публичный DNS-хост. На практике большинство организаций будут иметь по меньшей мере два подключенных к Интернету сервера имен, главный и вспомогательный. Типично также иметь по меньшей мере два зарегистрированных хоста обмена почтой. Помимо этих двух минимальных типов хостов, внешний или "публичный" DNS должен также регистрировать все хосты, к которым может быть осуществлен прямой доступ из Интернета, такие, как Web-серверы, FTP-серверы и прокси-серверы. Главной идеей внешней DNS является разглашение минимального количества информации людям, соединяющимся с сервисами, которые вы сделали доступными для пользователей Интернета.

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

Внешние DNS-хосты не должны иметь "двойной привязки", так как весь доступ к ним должен осуществляться посредством публичного интернет-адреса хоста. Исключением будет обеспечение администраторов средствами для соединения с хостом внешней DNS из внутренней сети. Это может быть выполнено путем использования второго сетевого соединения с хостом DNS, которое не будет доступно из Интернета, но может быть доступно только с указанных внутренних IP-адресов.

Хосты-ретрансляторы SMTP

Хосты-ретрансляторы SMTP являются выделенными серверами, используемыми для обработки всех SMTP-сообщений из Интернета, адресованными получателям в ваших внутренних доменах. Ваши хосты-ретрансляторы SMTP не должны выполнять никаких функций или служб, отличных от SMTP, и может быть использовано множество SMTP-серверов (таких, как UNIX sendmail и Domino). Сегодня популярно множество различных архитектур ретрансляции SMTP, а количество реализованных хостов-ретрансляторов варьируется в зависимости от размера организации. Передовым опытом является наличие по меньшей мере двух хостов-ретрансляторов SMTP для обеспечения дублирования. Зачастую в организациях желают назначить один или более хостов-ретрансляторов в качестве привилегированных ретрансляторов "входящих" сообщений и один или более хостов-ретрансляторов в качестве назначенных ретрансляторами "исходящих" сообщений. Хосты-ретрансляторы могут выполнять как "входящие", так и "исходящие" функции для дублирования, а заодно и для обеспечения некоторого баланса нагрузки. Для увеличения емкости число хостов-ретрансляторов может быть расширено в горизонтальном направлении. На рис. 4.3 показана типичная реализация хоста-ретранслятора SMTP, обеспечивающего входящее и исходящее дублирование и изолирующего ретрансляторы SMTP от внутренней сети.

В этом примере элементы внешней DNS имеют две записи обмена почтой MX (mail exchanger), и они перевешивают в пользу smtp1 как предпочтительного выбора для приема почты от имени домена acme.com. Если хост smtp1 не работает или недоступен, то внешние системы доставят сообщение smtp2. Для исходящих сообщений мы конфигурируем во внутренней сети почтовые серверы для отправки всех сообщений, адресованных за пределы внутренней сети, к виртуальному хосту-ретранслятору, называемому relay.acme.com. После этого во внутренней DNS мы определяем записи MX для виртуального хоста relay.acme.com, ссылающиеся на оба действительных хоста-ретранслятора, а в качестве предпочтительного маршрута при взвешивании вариантов решения предпочтение отдаем smtp2. Мы обращаемся к нему как к виртуальному хосту, потому что нет записи хоста (А). Заметьте, что записи "А" были для хостов smtp1 и smtp2. Эта схема обеспечивает выходную избыточность и обход отказа; если smtp2 не работает или недоступен, внутренние почтовые серверы доставят исходящие сообщения к smtp1. Важно заметить, что элементы внутренней DNS должны превращаться в сетевые адреса адаптеров хостов-ретрансляторов, доступных во внутренней сети. Подобным же образом элементы внешней DNS должны превращаться в адреса сетевых адаптеров, доступных извне.

За детальной информацией о передовом опыте предотвращения спама (незатребованной электронной почты) и эксплуатации хостов-ретрансляторов мы рекомендуем обратиться к справочнику Lotus Domino 6 spam Survival Guide for IBM e-Server, SG24-6930.

Серверы FTP

FTP-серверы являются серверами, предназначенными для получения из Интернета файлов с использованием протокола передачи файлов File Transport Protocol (FTP). Обычно они выступают только в роли репозиториев (хранилищ), хотя в зависимости от бизнес-потребностей организации они могут разрешать определенным пользователям возможность загрузки файлов из Интернета. Как правило, FTP-серверы необходимы для обмена файлами, которые являются слишком большими для отправки в виде приложений к сообщениям SMTP. Определение "большие" будет широко различаться в зависимости от ограничений размера сообщений, устанавливаемых участвующими в процессе хостами-ретрансляторами SMTP организации. Вы должны убедиться в том, что применяемые внешними пользователями учетные записи сильно ограничены, ограниченным должен быть и анонимный FTP (или ограниченным даже для другого выделенного хоста). Если ваш FTP-сервер поддерживает пассивный режим и вы приняли решение разрешить его, убедитесь, что диапазон номеров IP-портов данных ограничен до относительно небольшого конечного диапазона, а все остальные порты заблокированы брандмауэром.

SSL

Основой целью протокола защищенных сокетов [Secure Sockets Layer (SSL)] является обеспечение конфиденциальности и достоверности между двумя взаимодействующими приложениями. Протокол состоит из двух уровней. На самом нижнем уровне, на уровень выше некоторого надежного транспортного протокола, работает протокол записи SSL. Протокол записи SSL (SSL record protocol) используется для инкапсуляции различных протоколов более высокого уровня. Один из таких инкапсулированных протоколов, протокол подтверждения связи (рукопожатия) SSL (SSL handshaking protocol), позволяет проводить взаимную идентификацию сервера и клиента и согласовывать алгоритм шифрования и криптографические ключи еще до того момента, как протокол прикладного уровня передал или получил первый байт данных. Уникальным преимуществом SSL является его независимость от протокола прикладного уровня. Протокол более высокого уровня может явно работать поверх протокола SSL. Сеанс SSL всегда начинается с обмена "рукопожатиями" SSL. В процессе данного "рукопожатия" выполняются следующие шаги:

4.2 Модель архитектуры безопасности

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

В этом разделе мы опишем модель архитектуры безопасности, которая основана (хотя и неточно) на глобальной модели Web-архитектуры компании IBM. Модель имеет три высокоуровневых понятия, к которым мы обратимся в нескольких последующих разделах:

4.2.1 DMZ-модель: ретроспектива

Важным понятием относительно потоков данных является понятие множества сетевых зон. Если обратиться к прошлому, мы увидим инфраструктуры, характеризуемые использованием DMZ, или демилитаризованной зоны (demilitarized zone). Термин DMZ был использован для идентификации демилитаризованной зоны по 38-й параллели, установленной по окончанию корейской войны в 1953 г. как разделительный буфер между вооруженными силами Севера и Юга Кореи. Он стал более широко использоваться в последующих вооруженных конфликтах и вырос до значения "область между двумя противниками, которую обе стороны согласились не оккупировать". Как этот термин пришел в жаргон компьютерной безопасности, можно только догадываться.

Частое использование термина "DMZ" в контексте ИT-безопасности привело к большой неразберихе, так как существует как минимум две различные и к тому же одинаково популярные интерпретации того, что обозначает этот термин.

По одной интерпретации DMZ является областью между граничным маршрутизатором и системой брандмауэров. Это похоже на аналогию военной "ничьей земли", так как в этой части сети не существует никаких хостов (рис. 4.4).

По другой интерпретации DMZ является "экранированной (скрытой, защищенной) подсетью" сети, которая не находится внутри частной сети и в то же время не является частью Интернета (рис. 4.5). В скрытой подсети, как следует из ее названия, для сокрытия ее от двух других сетей применяются IP-фильтры. В зависимости от размещения скрытой подсети DMZ она может быть предназначена для разрешения входящих сеансов по доступу к предложенным сервисам с обеспечением некоторой защиты путем изоляции внешне доступных серверов в DMZ от внутренних серверов. Вторая интерпретация возникла, вероятно, тогда, когда все большее количество организаций начало применять некоторые основные функции брандмауэров (такие, как IP-фильтрация и фильтрация по порту) на своих граничных маршрутизаторах. Имея сейчас некоторые основные функции брандмауэров еще до того места, где первоначально была область DMZ, эта часть сети стала эффективно скрытой подсетью, и люди начали размещать там ограниченное количество хост-систем и служб.

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

В этой простой DMZ-модели мы имеем общедоступные серверы в DMZ и серверы, находящиеся во внутренней, частной сети. Разделение серверов приложений в основном происходит по двум соответствующим категориям: общие и частные.

Трехзонная модель была вполне достаточной до тех пор, пока количество доступных извне служб или приложений было довольно ограниченным. Этими службами обычно были Web-приложения (HTTP) и, возможно, передача файлов (FTP), часто использовавшие хост-бастион (жертву). В настоящее время мы видим бизнес-потребность в дополнительных службах, таких, как мгновенный обмен сообщениями, виртуальные конференции, совместные Web-пространства рабочих групп, экстранет- и интранет-порталы, доступ удаленных служащих и т. д. по нарастающей. Трехзонная модель с DMZ посередине ограничивает гибкость, необходимую нам для совершенствования уровней защиты множества служб.

4.2.2 Четырехзонная модель

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

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

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

Примечание. На некоторых платформах теоретически возможно обеспечить некоторый уровень разделения сервисов на отдельном хосте путем запуска служб под различными учетными записями, не имеющими привилегий администратора (root). Мы говорим, что разделение в пределах одного хоста является "теоретически" возможным, так как в реальности сложно сконфигурировать все должным образом, что подразумевает склонность к наличию ошибок, которые могут вести к непреднамеренным уязвимостям. К примеру, в UNIX-системах можно изолировать демонов (фоновые процессы или службы); однако, если конфигурация не выполнена должным образом, атакующий может быть способен взломать "chroot jail"Принудительная смена корневого каталога для приложения; выполняется в UNIX-системах командой chroot. и воздействовать на другие части системы. Простой поиск в Google по словам на тему "chroot breaking out" выдаст ссылки на огромное количество статей наподобие приведенной ниже:

http://www/bpfh.net/simes/computing/chroot-break.html

Мы не рекомендуем использовать разделение сервисов на отдельном хосте как метод сетевой безопасности, так как изоляция сервиса не может быть гарантирована.

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

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

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

Определение зон и рекомендации для политик

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

После того как мы определили четыре типа зон, наша модель производит впечатление достаточно простой, но еще далеко не законченной. Далее нам необходимо описать элементы управления, которые мы будем использовать для соединения и/или изоляции систем в различных зонах.

4.2.3 Границы зоны

Зоны безопасности должны быть разделены границами зон. Перед тем как мы идентифицируем необходимые функции каждой отдельной границы, опишем основные цели и принципы границы зоны. Функциями границы зоны являются:

Границы зон с точки зрения проекта сети состоят из брандмауэров. Вспомнили дословное определение брандмауэра как физического барьера для предотвращения распространения огня? Мы можем применить эту метафору при использовании сетевых брандмауэров для блокировки или ограничения возможности со стороны злоумышленника "распространять" влияние на другие зоны. Вспомните также, что существует несколько различных типов брандмауэров. Мы будем определять размещенные по всей архитектуре брандмауэры по тем функциям, которые необходимы на конкретной границе. К примеру, маршрутизатор с возможностью IP-фильтрации технически является брандмауэром, по крайней мере в самом точном значении определения. Допустим, что это тип брандмауэра очень низкого уровня. Но, возможно, нам необходимы как функции IP-фильтрации, так и функции прокси прикладного уровня. Для создания такого типа брандмауэра нам необходимы два устройства, расположенных последовательно.

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

Одним из установленных ранее принципов является то, что по умолчанию мы должны запретить весь трафик, за исключением необходимого. Это явление рассматривается в области ИT-безопасности как передовой опыт, но зачастую возникают сомнения насчет его осуществления. Сомнения возникают на почве способности точно идентифицировать все адреса, порты и протоколы заблаговременно, после чего сконфигурировать различные фильтры для разрешения только того, что было идентифицировано. В дополнение к этому некоторые протоколы и приложения несовместимы с определенными функциями брандмауэров; например использование протокола IPSec с NAT-брандмауэром сильно зависит от протокола IPSec и конкретного NAT-устройства. Мы считаем, что в большинстве организаций решение на использование приложений принимается бизнес-департаментами, а не ИT-департаментом. Для идентификации потенциальных зависимостей приложений, которые могут иметь проблемы в совместимости при доступе к приложению через различные технологии защиты брандмауэрами, необходимо поднимать вопросы ИT-безопасности еще на стадии планирования новых приложений. На ответственность администраторов ИT-безопасности возлагается минимизация потенциальной незащищенности в области безопасности и ограничение общего риска для владельцев бизнес-приложений и для организации.

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

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

Обязательные функции брандмауэров

Рекомендуемые функции брандмауэров (границы зон)

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

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

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

Основные службы инфраструктуры, доступные в публичной сети (Интернете), обычно требуют наличия выделенных, защищенных хостов. Мы классифицируем высокоуровневые основные функции следующим образом:

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

4.2.4 Межзонное взаимодействие: политики для потоков данных

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

Фактически политики для потоков данных являются неотъемлемой частью нашей политики безопасности. Мы не хотим подрывать или игнорировать бизнес-цели путем предоставления ошибочных соединений после разделения ресурсов по отдельным зонам. Нам необходимы специальные элементы управления безопасностью для обеспечения взаимодействия между различными зонами. Некоторые из требуемых элементов управления предусмотрены брандмауэрами границ зон, в то время как другие элементы управления должны быть обеспечены хостами, приложениями хостов или ими обоими.

Сначала мы опишем критерий, используемый нами для категоризации политик для потоков данных. Так что же мы понимаем под политиками для потоков данных? Просто мы подразумеваем, что у нас есть политики, или правила, для обеспечения взаимодействия клиента из "зоны x" с сервером в "зоне y". Это предполагает, что клиенту из зоны x разрешено соединиться с сервером в зоне y при выполнении как минимум одного набора критериев. Помните о том, что потоки данных определены как однонаправленные. Требования к потоку данных в одном направлении могут отличаться от требований для потока данных в противоположном направлении. Наши политики для потоков данных зависят от направления.

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

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

В качестве заключительного момента относительно рис. 4.8: брандмауэры и изображенные соединения не означают, что одна зона не может взаимодействовать с другой несмежной зоной. К примеру, рабочей станции в интранет-зоне может быть разрешено в нашей модели "прямое" соединение с интернет-зоной (или прокси-зоной). Однако это показывает, что такой тип соединения будет нуждаться в пересечении множества маршрутизаторов-брандмауэров.

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

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

4.2.5 Модели доступа к данным

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

Элементы аутентификации

Далее следуют несколько дополнительных терминов, которые необходимы для рассмотрения типов элементов аутентификации.

Аутентификация "клиент-сервер"

Мы определяем этот тип аутентификации как аутентификацию пользователя (индивидуума) на сервере либо как аутентификацию приложения или службы на сервере. Аутентификация может состоять из диалогового метода типа "вызов-ответ" ( challenge-response ) либо клиент может предоставлять серверу мандат в форме сертификата или другой поддающейся проверке метки. Сертификат может быть сертификатом пользователя Х.509 или сертификатом Notes. Примером "поддающейся проверке лексемы" может быть метка LTPA в cookie сеанса HTTP. Процесс аутентификации проверяет личность пользователя. Отметьте, что эта аутентификация может предоставлять, а может и не предоставлять пользователю средства для проверки подлинности или достоверности сервера.

Аутентификация "сервер-сервер"

Этот тип аутентификации является средством, с помощью которого один сервер может проверить подлинность другого сервера. При этом используется некоторая форма сертификата типа Х.509 или Notes. В этой модели не существует парольного метода типа "вызов-ответ" ( challenge-response ). Отметьте, что этот тип аутентификации может быть как однонаправленным, так и двунаправленным. При двунаправленной аутентификации каждый из серверов проверяет подлинность другого сервера.

Безопасность канала

Когда мы говорим о безопасности канала, то подразумеваем, что процесс передачи информации в рамках сеанса между клиентом и сервером или между двумя серверами является зашифрованным. Как правило, это обозначает, что требуется применение протокола SSL, хотя у нас есть и альтернатива для обеспечения безопасности соединений типа "клиент Notes – сервер Domino" и "сервер Domino – сервер Domino" в виде использования шифрования портов Domino.

Классификация данных и модели доступа

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

Общественный доступ к данным

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

Простая аутентификация

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

Строгая аутентификация, шифрованные данные

Третья, наиболее безопасная модель предусматривает наличие метода аутентификации пользователя приложением с дальнейшим шифрованием всех последующих транзакций сеанса с применением протокола Secure Sockets Layer (SSL). Эта возможность востребована приложениями, которые обрабатывают чувствительные или внутренние конфиденциальные данные заказчика в Интернете. В дополнение к строгой аутентификации и шифрованию предусматривается последующий доступ к данным приложения через прокси-серверы и элементы управления доступом прикладного уровня. Вне зависимости от расположения зоны все конфиденциальные данные будут сохраняться на диске с использованием шифрования с наивысшей поддерживаемой приложением устойчивостью ключа.

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

4.2.6 Политики для потоков данных

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

Разрешенные межзонные соединения были определены ранее в разделе 4.2.4, "Межзонное взаимодействие: политики для потоков данных". Сейчас мы перечислим наши политики в отношении соединений "данные приложения/порт" для следующих разрешенных межзонных соединений:

В табл. 4.1 – 4.9 мы использовали общие условные обозначения относительно каждой из сторон брандмауэра границы зоны:

Рис. 4.10 является примером того, как интерпретировать записи таблицы, используя строку приложения "FTP" из табл. 4.1.

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

4.3 Проверка результатов проектирования

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

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

В следующем разделе мы обратимся к первому из этих сценариев.

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

Далее мы используем пример обзора потоков данных приложения.

4.3.1 Пример потоков данных

В этом разделе мы опишем вымышленный проект инфраструктуры, который объединяет наши различные концепции безопасной архитектуры. Компания Acme разрабатывает Web-портал для внешних поставщиков. Одна часть содержимого портала обслуживается приложением Lotus Domino. Другой контент будет предоставлен сервером приложений WebSphere. Поставщикам будут выдаваться ID пользователя, а параметры удостоверения личности (пароли) будут сохраняться в каталоге LDAP. Для обеспечения элементами управления доступом к различным внутренним URL-адресам контента портала будет использоваться Tivoli Access Manager.

Согласно политикам классификации данных в Acme любые считающиеся "чувствительными" данные [доступ к которым выполняется из любой сети, отличной от внутренней (интранета)] должны обеспечиваться минимальным управлением доступом в виде простой аутентификации с шифрованием. Данные, считающиеся "конфиденциальными" [доступ к которым выполняется из любой сети, отличной от внутренней (интранета)], должны обеспечиваться минимальным управлением доступом в виде строгой аутентификации с шифрованием. Мы классифицировали информацию каталога поставщиков как "конфиденциальную", а контент портала как "чувствительный".

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

Первый из рассматриваемых нами потоков данных является потоком данных, требуемым поставщиком/пользователем для первоначального доступа к нашему серверу портала. Предполагая, что пытающийся получить доступ к порталу пользователь применяет URL-адрес, URL будет разрешен рабочей станцией пользователя с применением нашего публичного DNS-сервера. Мы направляем URL к публичному IP-адресу, соответствующему балансировщику IP-нагрузки в прокси-зоне 1. Номер 1 нашей схемы показывает путь запроса HTTP GET браузера, направленный к одному из двух прокси-серверов. Так как пользователь не был аутентифицирован (на основании непредусмотренного маркера LTPA), прокси в сопряжении с Tivoli Access Manager (номер 2) запрашивает удостоверение личности пользователя. Пользователь возвращает удостоверение личности ( ID и пароль пользователя, номер 3), который передается через прокси назад, к Tivoli Access Manager (номер 4). Tivoli Access Manager проверяет удостоверение личности по отношению к каталогу LDAP (номер 5), считает удостоверение личности действительным, после чего прокси-сервер создает маркер LTPA и пересылает его в запросе GET (номер 6) к серверу портала (номер 7). Сервер портала предоставляет контент с сервера приложений WebSphere и сервера Domino (номер 8). Хотя мы и упростили действительное подтверждение установления связи, которое происходит между браузером и различными серверами, нами было представлено основное описание потока данных. Теперь проверим данные, к которым происходит доступ, на предмет соответствия нашим политикам безопасности.

Второй из рассматриваемых нами потоков данных является потоком данных между внутренним администратором и нашими сервером контента Domino и сервером каталогов. Администратор (номер 9 на рис. 4.11) с рабочей станции интранета делает изменения в контенте Domino путем внесения изменений в контент на каскадном сервере Domino (номер 10). После этого модифицированные данные реплицируются с сервером контента Domino (номер 11). И снова проверим данные, к которым происходит доступ, на предмет соответствия нашим политикам безопасности:

Администратор использует строгую аутентификацию (Notes ID и пароль) для доступа к каскадному серверу; однако ваша политика для области "интранет-зона – зона доступа к данным" не требует шифровать этот поток. Репликация Domino между каскадным сервером и сервером контента соответствует политике безопасности для области "зона доступа к данным – зона доступа к данным", так как данные не являются конфиденциальными.

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

4.4 Заключение

В этой лекции мы рассмотрели несколько тем, которые обобщают архитектуру безопасности:

Мы представили модель многозональной архитектуры, которая основана на четырех типах сетевых зон:

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

Для применения в перспективе различных компонентов и концепций проектирования мы можем суммировать передовой опыт в области безопасной архитектуры, используя перечисленные далее компоненты или меры безопасности.

Сеть (IP)

Серверы приложений

Рабочие станции