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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4.11 отображает нашу логическую инфраструктуру. Для примера архитектуры на рис. 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). Хотя мы и упростили действительное подтверждение установления связи, которое происходит между браузером и различными серверами, нами было представлено основное описание потока данных. Теперь проверим данные, к которым происходит доступ, на предмет соответствия нашим политикам безопасности.

1. К информации каталога поставщика невозможно получить доступ напрямую из интернет-зоны. Мы сконфигурировали наш граничный брандмауэр между прокси-зонами и зонами доступа к данным на разрешение соединения с сервером каталогов LDAP (SSL, порт 636) только серверу Tivoli Access Manager. Так как пользователю необходима безопасная передача его удостоверения личности, то между пользователем и прокси-серверами, прокси-серверами и Tivoli Access Manager, Tivoli Access Manager и сервером каталогов нам будет требоваться шифрование протокола SSL. Наши таблицы политик для потоков данных говорят о необходимости применения взаимной аутентификации для LDAP SSL из прокси-зоны в зону доступа к данным. Вы выполним это, используя для SSL (сервер-сервер) сертификаты X.509 сервера.
2. Доступ к Web-контенту портала может быть осуществлен из интернет-зоны с использованием простой аутентификации. Мы также должны применить шифрование протокола SSL, так как наши данные считаются конфиденциальными; однако мы можем действовать согласно политике безопасности, применяя SSL только между прокси-серверами и пользователем. Согласно таблице потоков данных наш граничный брандмауэр между прокси-зонами и зонами доступа к данным должен разрешать только HTTP к определенным хостам. Мы разрешим только соединения по порту 80 от хостов прокси-зоны 1 к нашим трем Web-хостам в зоне доступа к данным 1.

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

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

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

4.4 Заключение

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

• компоненты инфраструктуры;
• использование множества сетевых зон;
• политики доступа к данным и потоков данных;
• анализ потоков данных с целью убедиться в исполнении политики.

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

1. Интернет-зона.
2. Прокси-зона.
3. Зона доступа к данным.
4. Интранет-зона.

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

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

Сеть (IP)

• Маршрутизаторы с фильтрацией.
• Брандмауэры (усовершенствованная фильтрация).
• Последние программные патчи на всех активных устройствах.
• NAT (преобразование сетевых адресов).
• Обнаружение вторжений.
• Все упомянутое ранее между каждыми из сегментированных сетевых зон.
• IPSec, или SOCKS, или оба для внешнего доступа к любому хосту ниже прокси-зоны.

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

• Выделенные хосты внешней DNS с защищенной ОС и последними программными патчами.
• Резервные прокси-серверы с защищенной ОС и последними программными патчами.
• Выделенные хосты-ретрансляторы SMTP с защищенной ОС и последними программными патчами.
• Только прокси-серверы и основные серверы (хосты прокси-зоны) доступны с использованием внешнего IP-адреса.
• Прокси-серверы и серверы доступа к данным с двойной привязкой.
• Обнаружение вторжений (особенно обнаружение DoS-атак и обнаружение подделки хоста).
• Шифрование (SSL).
• Резервирование.
• Сканирование контента и сканирование на предмет наличия вирусов.

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

• Последние программные патчи.
• Сканирование на предмет наличия вирусов.
• Обнаружение вторжений.
• Пересылающие HTTP-прокси.