Рис. 24.1. Использование Message Digest
24.4.2 Конфигурирование аутентификационной информации для сценария 1
Предположим, что компания XYZ имеет важный сервер с IP-адресом 130.15.20.2. В рамках работ по безопасности администратор сервера нумерует хосты клиентов и присваивает секретные ключи аутентификации каждому клиентскому IP-адресу.
Серверу нужно хранить информацию о безопасности. Для этого можно воспользоваться таблицей (например, 24.1). В ней индексируются все присвоенные клиентским хостам номера, называемые индексами параметров безопасности (Security Parameters Index — SPI). Если сервер имеет несколько IP-адресов, таблица индексируется и по адресам точек назначения.
Таблица 24.1 Информация безопасности в точке назначения 130.15.20.2
SPI (для хоста клиента) IP-адрес источника Ключ аутентификации клиента Метод аутентификации клиента 301 130.15.24.4 X'2E-41-43-11-5A-5A-74-53-E3-01-88-55-10-15-CD-23 MD5
302 130.15.60.10 X35-14-4F-21-2B-2C-12-34-82-22-98-44-C0-1C-33-56 MD5 … … … …
Конечно, каждый клиент должен быть конфигурирован с SPI и секретным ключом, используемым при доступе к серверу. Таблица 24.2 показывает конфигурационные данные второго клиента. Клиент нуждается в отдельных вхождениях для каждой точки назначения, к которой будет обращаться.
Таблица 24.2 Информация безопасности в источнике 130.15.60.10
IP-адрес назначения SPI IP-адрес источника Ключ аутентификации клиента Метод аутентификации клиента
130.15.20.2 302 130.15.60.10 X'35-14-4F-21-2B-2C-12-34-82-22-98-44-C0-1С-33-56 MD5 130.15.65.4 … … … …
Что происходит, когда клиентский хост хочет послать аутентифицированную датаграмму серверу?
■ Клиент выбирает IP-адрес точки назначения из своей таблицы.
■ Для вычисления резюме датаграммы используется ключ аутентификации.
■ Номер SPI и резюме сообщения помещаются в заголовок Authentication
■ Датаграмма отсылается.
При получении сервером датаграммы выполняются следующие действия:
■ Сервер использует SPI из заголовка Authentication, чтобы найти в таблице запись для клиента.
■ IP-адрес источника сообщения сравнивается с адресом источника в таблице.
■ По ключу аутентификации из таблицы вычисляется резюме сообщения.
■ Результат сравнивается со значением из заголовка Authentication.
24.4.3 Односторонняя безопасность
На данный момент выполнена только половина работы. Мы установили аутентификацию только для одного направления обмена данными. Аутентифицируются только датаграммы, отправляемые от клиента на сервер.
Такой метод называется односторонней ассоциацией безопасности (Security Association). Для идентификации используемого элемента таблицы важно обеспечить ассоциацию комбинации IP-адреса назначения и SPI как в источнике, так и в точке назначения, т.е. ассоциация безопасности связана с точкой назначения и с SPI.
Для аутентификации потока данных от сервера к клиенту необходим отдельный набор элементов таблицы, определяющих ключи аутентификации для ассоциации безопасности и для обратного направления обмена. Поэтому каждый хост должен:
■ Иметь таблицу безопасности, когда он является источником датаграммы
■ Иметь таблицу безопасности, когда он является получателем датаграммы
На рис. 24.2 показаны пары ассоциаций безопасности.
Рис. 24.2. Пары ассоциаций безопасности
24.4.4 Количество ключей аутентификации
Сколько ключей аутентификации нужно для работы сервера с клиентами? Может показаться, что серверу достаточно иметь один ключ MD5, с помощью которого он может сказать: "Я тот самый сервер".
Однако этот ключ будут знать все клиенты. Один из них сможет фальсифицировать IP-адрес и замаскироваться под сервер. Для предотвращения такого варианта каждому клиентскому хосту следует присвоить отдельные ключи аутентификации. Общее количество ключей можно сократить, если использовать одинаковые ключи аутентификации для взаимодействий сервер-клиент и клиент-сервер.
24.4.5 Сценарий 2
В сценарии 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
SPI IP-адрес источника Клиентский ключ аутентификации Клиентский метод аутентификации Клиентский ключ шифрования Клиентский метод шифрования 301 130.15.24.4 … MD5 Нет Нет
2 130.15.60.10 ..xxx.. MD5 Нет Нет 72 130.15.60.10 ..JJJ.. MD5 #$ВВ7&% CBC-DES … … … … … …
Таблицы 24.3 и 24.4 включают параметры безопасности для однонаправленных ассоциаций безопасности с источником, находящимся в клиенте 130.15.60.10, и точкой назначения на сервере 130.15.20.2. Отдельный набор параметров должен быть определен для обратного направления — от сервера-источника к клиенту-приемнику. Здесь снова разработчики конкретной системы должны решить, использовать ли те же самые ключи в обоих направлениях или присвоить различные ключи для трафиков клиент-сервер и сервер-клиент.
Таблица 24.4 Информация безопасности об источнике в 130.15.60.10
IP-адрес назначения Роль или идентификатор пользователя SPI IP-адрес источника Клиентский ключ аутентификации Клиентский метод аутентификации Клиентский ключ шифрования Клиентский метод шифрования
130.15.20.2 Хост 2 130.15.60.10 ..xxx.. MD5 Нет Нет 130.15.20.2 Администратор 72 130.15.60.10 ..JJJ.. MD5 #$ВВ7&% CBC-DES 130.15.65.4 Хост … … … MD5 … … … … … … … … … …
24.4.6 Сценарий 3
