ГОСТ Р ИСО МЭК 15408-2 2007 (1027764), страница 41
Текст из файла (страница 41)
Примером списка механизмов может служить: "отсутствие аутентификации, механизм пароля, биометрия (сканирование сетчатки), механизм ключа шифрования".В FIA_UAU.5.2 автору ПЗ/ЗБ следует специфицировать правила, описывающие, как механизмы аутентификации обеспечивают аутентификацию и когда используется каждый из них. Этозначит, что для любой возможной ситуации необходимо указать совокупность механизмов, которые могли бы использоваться для аутентификации.
Пример такого правила: "Для аутентификациипользователей, имеющих особые права доступа, должны совместно использоваться механизм пароля и биометрия, причем аутентификация успешна при успешной аутентификации каждым механизмом; для аутентификации остальных пользователей должен использоваться только механизмпароля".Автор ПЗ/ЗБ может задать ограничения, в пределах которых уполномоченному администратору разрешено специфицировать конкретные правила. Пример правила: "аутентификация пользователя всегда должна производиться посредством аппаратного ключа; администратор можетспецифицировать дополнительные механизмы аутентификации, которые также необходимо использовать". Автор ПЗ/ЗБ может и не специфицировать ограничения, а оставить выбор механизмов аутентификации и их правил полностью на усмотрение уполномоченного администратора.G.4.7 FIA_UAU.6 Повторная аутентификацияG.4.7.1 Замечания по применению для пользователяВ компоненте FIA_UAU.6 рассматривается потенциальная потребность повторной аутентификации пользователей в определенные моменты времени.
Такая потребность может возникнутьпри обращении пользователя к ФБО с запросом о выполнении действий, критичных по безопасности, а также при запросах о повторной аутентификации, исходящих от сущностей, не связанных сФБО, например, от серверного приложения, которое запрашивает от ФБО повторную аутентификацию обслуживаемого клиента.189ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)G.4.7.2 ОперацииG.4.7.2.1 НазначениеВ FIA_UAU.6.1 автору ПЗ/ЗБ следует привести список условий, требующих повторной аутентификации.
Этот список может включать в себя завершение периода времени, выделенного пользователю, запрос пользователя с целью изменения действующих атрибутов безопасности или запрос пользователя к ФБО с целью выполнения некоторых критичных функций безопасности.Автор ПЗ/ЗБ может задать пределы, в которых следует допускать повторную аутентификацию, оставив их детализацию на усмотрение уполномоченного администратора. Пример подобного правила: "пользователь должен проходить повторную аутентификацию не реже одного раза всутки; администратор может потребовать более частую повторную аутентификацию, но не чащеодного раза в 10 мин".G.4.8 FIA_UAU.7 Аутентификация с защищенной обратной связьюG.4.8.1 Замечания по применению для пользователяВ компоненте FIA_UAU.7 рассматривается обратная связь с пользователем в процессе аутентификации. В некоторых системах обратная связь выражается в том, что пользователю сообщается количество набранных им символов, но сами символы скрываются, в других системах даже эта информация может считаться неприемлемой.Этот компонент содержит требование, чтобы аутентификационные данные не возвращалисьпользователю в первоначальном виде.
В рабочих станциях принято представлять набранные символы пароля условными знаками (например, звездочками).G.4.8.2 ОперацииG.4.8.2.1 НазначениеВ FIA_UAU.7.1 автору ПЗ/ЗБ следует определить вид обратной связи с пользователем припроведении аутентификации. Примером такого назначения может служить: "число набранных символов", другой тип обратной связи – "механизм аутентификации, через который не удалось осуществить аутентификацию".G.5 Идентификация пользователя (FIA_UID)G.5.1 Замечания для пользователяСемейство FIA_UID определяет условия, при которых от пользователей требуется собственная идентификация до выполнения при посредничестве ФБО каких-либо иных действий, требующих идентификации пользователя.G.5.2 FIA_UID.1 Выбор момента идентификацииG.5.2.1 Замечания по применению для пользователяКомпонент FIA_UID.1 устанавливает требования по идентификации пользователей. АвторПЗ/ЗБ может указать конкретные действия, которые могут быть выполнены до завершения идентификации.При использовании компонента упоминаемые в нем действия, которые допускается выполнять при посредничестве ФБО до идентификации, следует также привести и в компонентеFIA_UAU.1 «Выбор момента аутентификации».G.5.2.2 ОперацииG.5.2.2.1 НазначениеВ FIA_UID.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых припосредничестве ФБО от имени пользователя до его собственной идентификации.
Этот список неможет быть пустым. Если приемлемых действий нет, следует вместо этого компонента использо-190ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)вать компонент FIA_UID.2 «Идентификация до любого действия пользователя». Примером такихдействий может служить запрос о помощи при выполнении процедуры логического входа в систему.G.5.3 FIA_UID.2 Идентификация до любых действий пользователяG.5.3.1 Замечания по применению для пользователяКомпонент FIA_UID.2 содержит требование идентификации пользователей. До идентификации пользователя ФБО не допускают выполнение им никаких действий.G.6 Связывание пользователь-субъект (FIA_USB)G.6.1 Замечания для пользователяДля работы с ОО аутентифицированный пользователь обычно активизирует какой-либосубъект.
Тогда атрибуты безопасности этого пользователя ассоциируются (полностью или частично) с этим субъектом. Семейство FIA_USB определяет требования по созданию и сопровождениюассоциации атрибутов безопасности пользователя с субъектом, действующим от имени пользователя.G.6.2 FIA_USB.1 Связывание пользователь-субъектG.6.2.1 Замечания по применению для пользователяВыражение "действующий от имени", использовавшееся и ранее, требует некоторых пояснений. Установлено, что субъект действует от имени пользователя, создавшего субъект или активизировавшего его для решения некоторой задачи. Поэтому, когда субъект создается, то он действует от имени пользователя, инициировавшего его создание. Если пользователь предпочитаетанонимность, субъект также действует от его имени, но идентификатор этого пользователя неизвестен.
Особую категорию составляют субъекты, которые обслуживают нескольких пользователей(например, серверный процесс). Тогда "владельцем" этого субъекта считается пользователь, создавший его.G.6.2.2 ОперацииG.6.2.2.1 НазначениеВ FIA_USB.1 автору ПЗ/ЗБ следует специфицировать список атрибутов безопасности пользователя, которые должны быть связаны с субъектами.В FIA_USB.1.2 автору ПЗ/ЗБ следует специфицировать какие-либо правила, которые должны применяться по отношению к исходной ассоциации атрибутов с субъектами, или слово "нет".В FIA_USB.1.3 автору ПЗ/ЗБ следует специфицировать какие-либо правила, которые должны применяться при внесении изменений в атрибуты безопасности пользователей, связанные ссубъектами, действующими от имени пользователей, или слово "нет".191ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)Приложение H(обязательное)Управление безопасностью (FMT)Класс FMT предназначен для спецификации управления некоторыми аспектами ФБО: атрибутами безопасности, данными и отдельными функциями.
Могут быть также установлены различные роли управления и определено их взаимодействие, например распределение обязанностей.Если ОО состоит из нескольких физически разделенных частей, образующих распределенную систему, то проблемы синхронизации, относящиеся к распространению атрибутов безопасности, данных ФБО и модификации функций становятся очень сложными, особенно когда требуетсядублирование информации в различных частях ОО. Эти проблемы следует принять во вниманиепри выборе компонентов FMT_REV.1 «Отмена» и FMT_SAE.1 «Ограниченная по времени авторизация», поскольку при этом возможно нарушение нормального выполнения ФБО.
В такой ситуациирекомендуется воспользоваться компонентами семейства FPT_TRC «Согласованность данныхФБО при дублировании в пределах ОО».Декомпозиция класса FMT на составляющие его компоненты приведена на рисунке H.1.192ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)FMT_MOF Управление отдельнымифункциями ФБО11FMT_MSA Управление атрибутамибезопасности231FMT_MTD Управление данными ФБО23FMT_REV Отмена1FMT_SAE Срок действия атрибутабезопасности1FMT_SMF Спецификация функцийуправления112FMT_SMR Роли управлениябезопасностью3Рисунок H.1 – Декомпозиция класса FMT «Управление безопасностью»H.1 Управление отдельными функциями ФБО (FMT_MOF)H.1.1 Замечания для пользователяФункции управления из числа ФБО дают уполномоченным пользователям возможность устанавливать операции безопасности ОО и управлять ими.
Эти административные функции обычно подразделяются на несколько категорий.a) Функции управления, относящиеся к управлению доступом, учету пользователей и аутентификации, реализованные в ОО. Например, определение и обновление характеристик безопасности пользователей (таких, как уникальные идентификаторы, ассоциированные с именами пользователей, учетные данные пользователей, параметры входа в систему), определение и обновление средств управления аудитом системы (выбор событий аудита, управление журналами аудита,анализ журнала аудита и генерация отчетов аудита), определение и обновление атрибутов поли-193ГОСТ Р ИСО/МЭК 15408-2—…(проект, окончательная редакция)тики, назначенных пользователю (таких, как уровень допуска), определение системных метокуправления доступом, управление группами пользователей.b) Функции управления, относящиеся к контролю доступности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
