■ Иметь таблицу безопасности, когда он является источником датаграммы

■ Иметь таблицу безопасности, когда он является получателем датаграммы

На рис. 24.2 показаны пары ассоциаций безопасности.

Рис. 24.2. Пары ассоциаций безопасности

Сколько ключей аутентификации нужно для работы сервера с клиентами? Может показаться, что серверу достаточно иметь один ключ MD5, с помощью которого он может сказать: "Я тот самый сервер".

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

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

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

Рис. 24.3. Несколько ассоциаций безопасности для клиента и сервера

Рассмотрим таблицы ассоциаций безопасности с добавленными в них дополнительными элементами для администратора и ключами шифрования. В таблице 24.3 приведена информация о приемнике на сервере, а в таблице 24.4 — об источнике у клиента. Появились отдельные новые SP1 для исходных пользователей 130.15.60.10 и для администратора, находящегося по тому же адресу.

Таблица 24.3 Информация безопасности об источнике в 130.15.20.2

Таблицы 24.3 и 24.4 включают параметры безопасности для однонаправленных ассоциаций безопасности с источником, находящимся в клиенте 130.15.60.10, и точкой назначения на сервере 130.15.20.2. Отдельный набор параметров должен быть определен для обратного направления — от сервера-источника к клиенту-приемнику. Здесь снова разработчики конкретной системы должны решить, использовать ли те же самые ключи в обоих направлениях или присвоить различные ключи для трафиков клиент-сервер и сервер-клиент.

Таблица 24.4 Информация безопасности об источнике в 130.15.60.10

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

Рис. 24.4. Трафик в туннеле между двумя сетями

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

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

■ Между хостами

■ Между маршрутизаторами

■ Между хостом и маршрутизатором

■ Между маршрутизатором и хостом

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