Системы управления базами данных

ЛЕКЦИЯ 5

ХАРАКТЕРИСТИКИ БЕЗОПАСНОСТИ ДЛЯ РАЗЛИЧНЫХ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ

План лекции

1. Характеристики безопасности для различных информационных объектов

1.1. Операционные системы

1.2. Системы управления базами данных

1.3. Виртуальные частные сети

1.4. Виртуальные локальные сети

2. Обеспечение информационной безопасности в общемировых сетях

2.1. Спецификации Internet-сообщества IPsec

2.1.1. Архитектура средств безопасности IP-уровня

2.1.2. Контексты безопасности и управление ключами

2.1.3. Обеспечение аутентичности IP-пакетов

2.1.4. Обеспечение конфиденциальности сетевого трафика

2.2. Роль поставщика Internet-услуг в реагировании на нарушения безопасности

2.3. Меры по защите Internet-сообщества

2.3.1. Обеспечение безопасности маршрутизаторов

2.3.2. Особенности использования управляющих протоколов

2.3.3. Безопасное размещение сетевого оборудования потребителя

2.3.4. Защита системной инфраструктуры

2.3.5. Работа с Web-серверами

Характеристики безопасности для различных

Информационных объектов

Операционные системы

Операционные системы (ОС) - классический объект оценки по требованиям безопасности еще со времен «Оранжевой книги». Более того, до сих пор остается весьма распространенным мнение о том, что это важнейшее, едва ли не единственное защитное средство. С современных позиций ОС можно рассматривать как комбинацию сервисов идентификации и аутентификации, управления доступом и протоколирования/аудита. Кроме того, операционные системы обеспечивают базовые, инфраструктурные свойства безопасности, в том числе разделение доменов и посредничество при обращениях.

Рассмотрим вариант, соответствующий четвертому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники.

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

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

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

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

• генерация криптографических ключей. Симметричные криптографические ключи должны генерироваться в соответствии с согласованным с алгоритмом, реализуемым аппаратным или программным генератором случайных чисел и/или схемой генерации ключей, которая основана на криптографии с открытым ключом, использует программный и/или аппаратный генератор случайных чисел. и удовлетворяя ГОСТ Р 34.10-2001 в части генерации простых чисел, ГОСТ Р 34.10-2001 для реализации процедуры выработки и проверки электронной цифровой подписи, ГОСТ 28147-89 для реализации процедур зашифрования и расшифрования данных, а также требованиям самого проекта и документации разработчика;

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

• уничтожение криптографических ключей. Удалять ключи и другие критичные параметры необходимо немедленно, полностью и таким образом, чтобы поверх ключа/критичной области памяти записывались три или более различных шаблонов;

• криптографические операции. Операции зашифрования/расшифрования данных должны выполняться в соответствии с алгоритмом криптографического преобразования по ГОСТ 28147-89 или другим аттестованным алгоритмом, а операции вычисления цифровой подписи - в соответствии с алгоритмом выработки и проверки электронной цифровой подписи по ГОСТ Р 34.10-2001 или другим аттестованным алгоритмом;

• генерация случайных чисел. Генерация случайных чисел должна выполняться множеством независимых аппаратных и/или программных датчиков, выходы которых объединяются с использованием хэш-функции по ГОСТ Р 34.11 -94. Датчики случайных/псевдослучайных чисел необходимо защитить от нарушения алгоритмов (режимов) их функционирования;

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

• отделение домена функций безопасности. Поддерживается криптографический домен, отделенный от остальных функций безопасности, защищенный от вмешательства и искажения недоверенными субъектами;

• тестирование криптографического модуля. Для проверки правильности функционирования криптографического модуля необходимо реализовывать возможность его тестирования путем выполнения набора встроенных тестов при начальном запуске, по запросу администратора по криптографии и периодически. Тесты должны обеспечивать проверку и документирование статистических характеристик генераторов случайных/псевдослучайных чисел и отображение результатов тестирования. Предписывается выполнение тестов обнаружения ошибок в ключе при начальном запуске и по запросу администратора по криптографии, а также немедленное (сразу после генерации ключа) самотестирование каждого участвующего в генерации ключей компонента. Сгенерированный ключ не должен использоваться, если самотестирование какого-либо компонента завершилось неудачей;

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

Системы управления базами данных

Системы управления базами данных (СУБД), как и операционные системы, содержат комбинацию сервисов безопасности, однако, в отличие от ОС, не являются самодостаточными. СУБД используют механизмы и функции ОС. Такая двухуровневость ведет к появлению специфических угроз и требует привлечения соответствующих средств противодействия. Например, базы данных располагаются в файлах или на дисках, управляемых ОС; следовательно, к объектам БД можно обратиться как штатными средствами СУБД, так и с помощью механизмов ОС, получив доступ к файлу или устройству. Подобные возможности должны учитываться в профиле защиты для СУБД.

Здесь вводится понятие аутентификационного пакета, который предоставляет для СУБД механизм подтверждения подлинности заявляемого идентификатора пользователя. Для этого необходим хотя бы один из двух механизмов: внешний (аутентификация средствами ОС) или внутренний (аутентификация средствами СУБД).

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

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

В распределенной среде управление доступом и изоляция могут поддерживаться не только средствами базовой ОС, но и архитектурно, путем разнесения компонентов СУБД по узлам сети и использования межсетевых экранов.

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

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