24.2 Безопасность
В главе 3 мы уже отмечали три атрибута безопасности:
Аутентификация Проверка подлинности пользователя, клиентского процесса или серверного приложения Целостность Проверка отсутствия изменений в данных Конфиденциальность Предотвращение несанкционированного доступа к информацииВ той же главе представлены несколько механизмов реализации указанных атрибутов. В следующем разделе мы рассмотрим адаптацию этих механизмов для обеспечения безопасности на уровне IP..
24.3 Стратегия безопасности
Интеграция безопасности в IP стала одной из наиболее сложных работ, выполненных IETF. Аутентификация, целостность данных и конфиденциальность стали насущными и необходимыми. Стратегия безопасности предполагает:
■ Содействие совместной работе, начинающейся с уже известных и реализованных механизмов для аутентификации, целостности данных и конфиденциальности.
■ Разработку основ безопасности, позволяющих перейти на новые механизмы безопасности.
В качестве исходных были выбраны следующие механизмы:
■ MD5 для аутентификации и целостности данных (в настоящее время проявились проблемы с MD5 при реализации высокоскоростных коммуникаций, поскольку требуется большой объем вычислений).
■ Симметричное шифрование в режиме Cipher Block Chaining американского стандарта Data Encryption Standard (CBC-DES) для обеспечения конфиденциальности.
Для распространения информации используется шифрование общедоступными ключами.
24.4 Сценарии обеспечения безопасности
Существует множество способов использования различных вариантов безопасности (они описаны ниже), но сначала мы познакомимся с несколькими сценариями для разъяснения причин выбора некоторых вариантов.
Сценарий 1. Компания XYZ хочет обезопасить свои внешние коммуникации клиент/сервер. Ей нужно устранить возможность фальсификации своих данных при подделке исходного IP-адреса или изменения данных при пересылке.
Сценарий 2. Администратор компании XYZ копирует очень важные файлы между хостами. Эту операцию должен выполнять только этот администратор и никто другой. Кроме того, важно предотвратить "подглядывание", т.е. захват и несанкционированное использование данных из файлов.
Сценарий 3. Компания XYZ соединила по Интернету свои производственные подразделения с удаленным главным офисом. Она хочет скрыть все свои коммуникации от остального мира.
Для простоты можно считать, что каждый клиентский или серверный хост имеет единственный IP-адрес и один интерфейс. Однако механизмы безопасности должны работать и для систем с несколькими интерфейсами и несколькими IP-адресами.
24.4.1 Сценарий 1
Технология Message Digest (резюме сообщения) подойдет для сценария 1 — аутентифицировать отправителя и определить изменения в данных. Рассмотрим, как работает этот механизм (см. рис. 24.1):
■ Источник и назначение знают секретный ключ.
■ Источник выполняет вычисление, используя данные и секретный ключ.
■ Источник отправляет в сообщении результат вместе с данными.
■ В точке назначения выполняются те же самые вычисления и сравниваются результаты.
Рис. 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 показывает конфигурационные данные второго клиента. Клиент нуждается в отдельных вхождениях для каждой точки назначения, к которой будет обращаться.