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

Сценарий 3. Компания XYZ соединила по Интернету свои производственные подразделения с удаленным главным офисом. Она хочет скрыть все свои коммуникации от остального мира.

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

Технология Message Digest (резюме сообщения) подойдет для сценария 1 — аутентифицировать отправителя и определить изменения в данных. Рассмотрим, как работает этот механизм (см. рис. 24.1):

■ Источник и назначение знают секретный ключ.

■ Источник выполняет вычисление, используя данные и секретный ключ.

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

■ В точке назначения выполняются те же самые вычисления и сравниваются результаты.

Рис. 24.1. Использование Message Digest

Предположим, что компания XYZ имеет важный сервер с IP-адресом 130.15.20.2. В рамках работ по безопасности администратор сервера нумерует хосты клиентов и присваивает секретные ключи аутентификации каждому клиентскому IP-адресу.

Серверу нужно хранить информацию о безопасности. Для этого можно воспользоваться таблицей (например, 24.1). В ней индексируются все присвоенные клиентским хостам номера, называемые индексами параметров безопасности (Security Parameters Index — SPI). Если сервер имеет несколько IP-адресов, таблица индексируется и по адресам точек назначения.

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

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

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

Что происходит, когда клиентский хост хочет послать аутентифицированную датаграмму серверу?

■ Клиент выбирает IP-адрес точки назначения из своей таблицы.

■ Для вычисления резюме датаграммы используется ключ аутентификации.

■ Номер SPI и резюме сообщения помещаются в заголовок Authentication

■ Датаграмма отсылается.

При получении сервером датаграммы выполняются следующие действия:

■ Сервер использует SPI из заголовка Authentication, чтобы найти в таблице запись для клиента.

■ IP-адрес источника сообщения сравнивается с адресом источника в таблице.

■ По ключу аутентификации из таблицы вычисляется резюме сообщения.

■ Результат сравнивается со значением из заголовка Authentication.

На данный момент выполнена только половина работы. Мы установили аутентификацию только для одного направления обмена данными. Аутентифицируются только датаграммы, отправляемые от клиента на сервер.

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

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