"Общие критерии", часть 2. Функциональные требования безопасности

Классы функциональных требований, играющие инфраструктурную роль

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

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

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

К управлению атрибутами безопасности ( семейство FMT_MSA) предъявляется больше требований. Во-первых, оно должно быть доступно только определенным ролям. Во-вторых, необходимо контролировать безопасность присваиваемых значений. В-третьих, при создании объектов должна существовать возможность задания значений, отличных от подразумеваемых.

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

FMT_REV (отмена) предусматривает возможность отмены (отзыва) атрибутов безопасности пользователей, субъектов и объектов.

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

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

Шесть семейств простой структуры содержит и класс FTA (доступ к объекту оценки), куда вошли требования управления сеансами работы пользователей (помимо идентификации и аутентификации).

Семейство FTA_LSA определяет требования по ограничению атрибутов безопасности сеанса, которые может выбирать пользователь.

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

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

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

Еще три однокомпонентных семейства содержат некоторые подробности открытия сеанса.

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

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

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

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

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

На этом мы завершаем рассмотрение функциональных требований безопасности.