Классы функциональных требований, играющие инфраструктурную роль
Криптографические механизмы - обязательный элемент защищенных систем. Класс 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) предназначены для передачи критичных по безопасности данных между функциями безопасности с другими доверенными изделиями ИТ. Доверенный маршрут/канал должен быть логически отличим от других маршрутов (каналов), обеспечивать уверенную идентификацию взаимодействующих сторон, а также конфиденциальность и целостность передаваемых данных.
На этом мы завершаем рассмотрение функциональных требований безопасности.
<
