Компоненты и уровни безопасности
Рекомендуемые функции брандмауэров (границы зон)
- SOCKS V5.
- Простота администрирования, технического обслуживания, резервного копирования и восстановления.
- Легко модернизируемые компоненты.
- Возможность обеспечения фильтрации с учетом состояния.
В интересах нашего логического проектирования мы будем рассматривать функции брандмауэра как отдельную службу, которая предоставляет различные типы фильтров: мониторинг контента и сканирование на предмет наличия вирусов, обнаружение вторжения, мониторинг и ведение журналов системы (протоколирование). С функциональной точки зрения зачастую достаточным является логическое представление (рис. 4.6).
Раз мы смогли составить логическую схему, далее нам надо построить физическую схему. Архитектор нуждается в преобразовании чертежей вертикальной проекции проекта в конструкторские чертежи или модели, нуждаемся в этом и мы. Пожалуйста, примите к сведению, что конструирование сетей выходит за рамки этого курса. Однако чтобы показать, что может понадобиться для реализации логического брандмауэра, на рис. 4.7 мы отобразим один из возможных физических наборов компонентов, который сможет предоставить услуги брандмауэра.
В этом примере мы имеем как само устройство брандмауэр, так и маршрутизатор с пакетной фильтрацией. В этом случае брандмауэр Cisco PIX обеспечивает функции, которые отдельно наши маршрутизаторы не в состоянии обеспечить, такие, как пакетная фильтрация с учетом состояния, инспектирование протоколов и приложений, VPN, поточная защита от вторжений и безопасность передачи мультимедийных и голосовых данных. Снова подчеркнем, что это не курс о конструировании сетей и мы рекомендуем определенные изделия. Помните о том, что различные производители сетевого оборудования будут использовать разные подходы к проектированию и включению различных функций в свои блоки и устройства. Начиная отсюда в этой лекции мы будем использовать только логические представления.
Основные службы инфраструктуры, доступные в публичной сети (Интернете), обычно требуют наличия выделенных, защищенных хостов. Мы классифицируем высокоуровневые основные функции следующим образом:
- HTTP, прокси;
- DNS;
- службы почтовой ретрансляции SMTP.
На данный момент мы определили четыре типа зон безопасности и различные типы функций брандмауэров, которые мы можем реализовать на границах зон. На последней стадии создания модели надо определить критерий, который мы будем использовать для определения того, в какую из зон должна быть помещена конкретная система, и функции брандмауэров, которые нам необходимо предусмотреть для потоков данных между зонами. Мы сможем выполнить это путем определения наших политик для потоков данных, содержащих информацию о том, как мы должны защищать данные различной классификации, которые пересекают границу двух зон.
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.
Классификация данных и модели доступа
Мы коротко обсудили классификацию данных в "Основы ИТ-безопасности" . Ключевая часть нашей модели межзонного взаимодействия зависима от использования трех различных классификаций данных, связанных с различными типами аутентификации пользователей.
Общественный доступ к данным
Первая модель доступа к данным существует для данных, которые идентифицированы как публичные, или общественные. В эту категорию попадает значительная часть данных. Большинство данных на ваших внешних сайтах не требует никакой формальной аутентификации или шифрования в связи с "публичной" классификацией данных. Это не означает, что нам необходимо разрешить анонимный доступ; тем не менее без аутентификации мы не имеем средств для проверки личности пользователя. Возможно, мы захотим отметить IP-адрес, с которого подключился клиент, но это произойдет только в интересах слежения. Для каждого из приложений должны быть обозначены пути доступа к данным. Элементы управления доступом к данным единообразны с использующимися во второй и третьей моделях доступа к данным, за исключением того, что аутентификация не требуется и шифрование не используется.
Простая аутентификация
Вторая модель предусматривает наличие метода аутентификации пользователя приложением с применением однофакторной аутентификации. Если клиент находится в интранет-сети, то шифрование не потребуется. Если клиент находится в любой другой зоне, с помощью протокола SSL шифруются все последующие транзакции сеанса. Эта возможность востребована приложениями, которые обрабатывают чувствительные данные. В дополнение к простой аутентификации и шифрованию предусматривается последующий доступ к данным приложения через прокси-серверы и элементы управления доступом прикладного уровня.
Строгая аутентификация, шифрованные данные
Третья, наиболее безопасная модель предусматривает наличие метода аутентификации пользователя приложением с дальнейшим шифрованием всех последующих транзакций сеанса с применением протокола Secure Sockets Layer (SSL). Эта возможность востребована приложениями, которые обрабатывают чувствительные или внутренние конфиденциальные данные заказчика в Интернете. В дополнение к строгой аутентификации и шифрованию предусматривается последующий доступ к данным приложения через прокси-серверы и элементы управления доступом прикладного уровня. Вне зависимости от расположения зоны все конфиденциальные данные будут сохраняться на диске с использованием шифрования с наивысшей поддерживаемой приложением устойчивостью ключа.
Если мы рассматриваем соединения "клиент-сервер" и "сервер-сервер" как два типа соединений, то эти соединения могут быть инициированы в одной зоне с адресом назначения в другой зоне, а нами определено четыре типа зон мы можем разложить различные перемещения потоков данных на простые таблицы. Поскольку наши политики налагают ограничения на то, каким зонам разрешено прямое соединение друг с другом, то нет необходимости определения таблиц для каждого возможного перемещения. Нам необходимо только определить разрешенные соединения протоколов между зонами, которым мы позволили иметь прямую соединяемость. К примеру, наша политика не разрешает прямое соединение между хостом в Интернете и хостом в интранет-зоне, в связи с чем нам не нужна таблица политики в этом случае. Таблицы в следующем разделе представляют наши рекомендации на основе передового опыта с принятием в расчет типов показанных приложений (протоколов). В политиках для потоков данных вашей собственной организации вы можете на свой выбор иметь большее либо меньшее количество протоколов.