Приложение Е (рекомендуемое). Рабочий пример: профиль защиты для системы управления базой данных

Приложение Е
(рекомендуемое)

Рабочий пример: профиль защиты для системы управления базой данных

Е.1 Введение

В настоящем приложении поясняется применение руководства, содержащегося в разделах 7 - 13, посредством рабочего примера применительно к системе управления базами данных (СУБД). В данном примере предполагается использование СУБД в коммерческих условиях, когда существует потребность в защите конфиденциальности, целостности и доступности информации, содержащейся в базе данных, на основе дискреционного принципа управления доступом.

Е.2 Среда безопасности объекта оценки

Е.2.1 Предположения безопасности

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

Например, могут быть сделаны следующие предположения:

Предположение А1. Объект оценки (СУБД) работает под управлением операционной системы, которая установлена и функционирует в безопасном режиме, то есть в соответствии с эксплуатационной документацией данного продукта ИТ.

Предположение А2. Ресурсы ОО и операционной системы, под управлением которой он работает, защищены от несанкционированного физического доступа.

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

Главная задача разработчика ПЗ заключается в том, чтобы определить границы среды безопасности как непосредственно ОО, так и операционной системы, под управлением которой работает ОО. В дальнейшем в ПЗ определяются цели и требования к операционной системе (как части ИТ-среды).

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

Е.2.2 Угрозы

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

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

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

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

Угроза Т1. Нарушитель получает доступ к базе данных в результате маскировки под уполномоченного пользователя или в результате анонимного доступа.

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

В формулировке угроз определены источник угрозы, активы ИТ, подверженные нападению, и форма нападения.

Источник угрозы - это уполномоченный пользователь базы данных в Т2, но мог бы быть и неуполномоченный или уполномоченный пользователь базы данных в Т1.

Активы ИТ, подверженные нападению (в формулировке обеих угроз), - это информация, содержащаяся в объектах базы данных, к которым осуществляется доступ.

Форма нападения выражена в виде маскировки под законного пользователя или "анонимного доступа" в Т1 и "обращается к информации" в Т2.

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

Угроза Т3. Уполномоченный пользователь базы данных использует общие ресурсы базы данных так, чтобы поставить под угрозу доступность базы данных для других уполномоченных пользователей.

Следует отметить, что в угрозе Т3, как и в угрозах Т1 и Т2, актив ИТ, подверженный риску, - это информация, содержащаяся в базе данных.

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

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

Угроза ТЕ1. База данных не может быть надежно защищена объектом оценки от пользователей с большими полномочиями, которые злоупотребляют предоставленными им привилегиями.

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

Е.2.3 Политика безопасности организации

В качестве ПБОр для СУБД может быть, например, выбрана:

Политика безопасности Р1. Права доступа к определенным объектам базы данных определяются:

a) владельцем объекта;

b) результатом проверки подлинности субъекта, осуществляющего доступ;

c) правами доступа к объекту, предоставленными субъекту;

d) привилегиями, которыми обладает субъект.

Е.3 Цели безопасности

Е.3.1 Цели безопасности для объекта оценки

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

Цель О1. Объект оценки должен обеспечивать идентификацию пользователей ОО.

Цель О2. Объект оценки должен обеспечить конечным пользователям возможности управления и ограничения доступа путем определения владельцев объектов БД и ответственных за эти объекты в соответствии с выбранной политикой безопасности Р1.

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

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

Е.3.2 Цели безопасности для среды

Анализ угрозы ТЕ1 показывает необходимость формулировки цели безопасности для среды, связанной с проблемой привилегированных пользователей.

Данную цель безопасности можно сформулировать следующим образом:

Цель OЕ1. Лица, ответственные за эксплуатацию ОО, должны обеспечить проведение соответствующих процедурных и кадровых мероприятий, гарантирующих то, что только доверенным лицам назначены привилегии, позволяющие им:

a) модифицировать данные журнала аудита и настройки аудита;

b) модифицировать атрибуты безопасности пользователей (включая разрешения на использование привилегий пользователя).

Далее приводится пример цели безопасности для среды, которая (цель) является требованием по использованию операционной системы, под управлением которой работает ОО:

Цель OЕ2. Лица, ответственные за эксплуатацию ОО, должны обеспечить, чтобы данные аутентификации для каждой учетной записи пользователя операционной системы содержались в тайне и были недоступны лицам, не уполномоченным использовать данную учетную запись.

Цель OЕ2 определяет потребность (выраженную в предположениях безопасности А1, А2, A3) в том, чтобы файлы базы данных были соответствующим образом защищены операционной системой. Если данные проверки подлинности (учетные записи) не защищены надлежащим образом, то нарушитель сможет обойти функции управления доступом.

Е.4 Требования безопасности информационных технологий

Е.4.1 Функциональные требования безопасности

Можно выбрать следующие функциональные требования безопасности, непосредственно удовлетворяющие описанные выше цели безопасности для ОО:

а) цель O1, требующая идентификации пользователей объектом оценки (аутентификация предписана операционной системе), может быть удовлетворена ФТБ, определенными в компонентах FIA_UIE.1 "Выбор момента времени идентификации" и FIA_USB.1 "Связи пользователь-субъект";

b) цель безопасности O2, требующая управления доступом к объектам базы данных, может быть удовлетворена ФТБ, определенными в компонентах FDP_ACC.1 "Ограниченное управление доступом" и FDP_ACF.1 "Управление доступом, основанное на атрибутах безопасности";

c) цель безопасности O3, требующая ограничений на использование общих ресурсов, может быть удовлетворена ФТБ, определенными в компонентах FRU_RSA.1 "Максимальные квоты" и FTA_MCS.1 "Базовое ограничение на параллельные сеансы".

Аналогично (путем выбора соответствующих компонентов из ИСО/МЭК 15408-2 для определения требуемых ФТБ) следует удовлетворять и другие цели безопасности, включенные в ПЗ (например, для определения требований аудита следует выбрать компонент FAU_GEN.1 "Генерация данных аудита").

Сформировав начальный набор ФТБ, оставшиеся ФТБ следует выбирать так, чтобы удовлетворить зависимости, установленные в ИСО/МЭК 15408-2, или определить другие сопутствующие функциональные возможности.

Например:

a) компонент FMT_MSA.3 "Инициализация статичных атрибутов" необходим (как зависимость для компонента FDP_ACF.1) для спецификации функции управления доступа по умолчанию для вновь созданного объекта базы данных;

b) компонент FMT_MSA.1 "Управление атрибутами безопасности" необходим для определения функций контроля за модификацией объектов или назначением атрибутов безопасности пользователей и атрибутов безопасности объектов. Может потребоваться операция итерации для определения контроля за атрибутами пользователей и атрибутами объектов отдельно, так как последние могут быть изменены владельцами объектов, а первые - только администратором;

c) компонент FDP_RIP.1 "Ограниченная защита остаточной информации" нужен, чтобы определить функциональные возможности повторного использования объекта в поддержку политики контроля доступа к базе данных;

d) компонент FAU_SAR.1 "Просмотр аудита" может быть выбран для того, чтобы определить, кто может просматривать данные аудита (например, уполномоченные пользователи могут иметь возможность читать записи аудита, касающиеся объектов, по отношению к которым пользователи являются владельцами, в то время как только уполномоченный администратор может иметь возможность просматривать весь журнал аудита).

Далее необходимо принять решение об уровне аудита событий: минимальный, базовый или детализированный.

Подходящий уровень выбирается, исходя из целей безопасности для ОО. При этом требование аудита не должно быть необоснованно завышено.

Е.4.2 Требования доверия к безопасности объекта оценки

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

Е.4.3 Требования безопасности для ИТ-среды

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

Е.5 Обоснование профиля защиты

Е.5.1 Обоснование целей безопасности

Демонстрация соответствия целей безопасности идентифицированным угрозам может быть выполнена:

a) в виде таблицы, показывающей, какие цели безопасности каким угрозам соответствуют (например, угрозе Т3 соответствует цель О3), при этом необходимо обеспечить соответствие каждой цели безопасности, по крайней мере, одной угрозе;

b) в виде обоснования того, что цели безопасности противостоят угрозам. Ниже приведен пример обоснования целей безопасности.

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

Е.5.2 Обоснование функциональных требований безопасности

Демонстрацию соответствия ФТБ целям безопасности для ОО можно представить:

a) в виде таблицы, показывающей, какие ФТБ какие цели безопасности удовлетворяют (например, компоненты FRU_RSA.1 и FTP_MCS.1 соответствуют цели безопасности О3), при этом необходимо обеспечить соответствие каждого ФТБ, по крайней мере, одной цели безопасности;

b) в виде обоснования соответствия ФТБ целям безопасности.

Ниже приведен пример обоснования ФТБ.

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

Анализ зависимостей компонентов ФТБ также можно представить в виде таблицы.

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

Ниже приведен пример демонстрации взаимной поддержки требований безопасности:

a) компонент FDP_RIP.1 поддерживает компоненты FDP_ACC.1 и FDP_ACF.1, предотвращая обход ФБО, соответствующих данным компонентам, при многократном использовании объектов хранения данных и доступе к этим объектам различных субъектов;

b) компонент FMT_MSA.1 поддерживает компоненты FRU_RSA.1 и FTA_MCS.1, ограничивая возможности уполномоченного администратора изменять квоты пользователей по использованию ресурсов ОО;

c) компонент FAU_STG.1 "Защищенное хранение журнала аудита" поддерживает компонент FAU_GEN.1, защищая целостность журнала аудита.

Е.5.3 Обоснование требований доверия к безопасности

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