Приложение Ж. Идентификация и аутентификация (FIA) (справочное)

Приложение Ж
(справочное)

Идентификация и аутентификация (FIA)

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

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

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

Семейство FIA_UID предназначено для определения идентификатора пользователя.

Семейство FIA_UAU предназначено для верификации идентификатора пользователя.

Семейство FIA_AFL предназначено для определения ограничений на число повторных неуспешных попыток аутентификации.

Семейство FIA_ATD предназначено для определения атрибутов пользователей, применяемых при осуществлении ПБО.

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

Семейство FIA_SOS предназначено для генерации и верификации секретов, удовлетворяющих установленной метрике.

Декомпозиция класса FDP# на составляющие его компоненты приведена на рисунке Ж.1.

Ж.1 Отказы аутентификации (FIA_AFL)

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

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

FIA_AFL.1 Обработка отказов аутентификации

Замечания по применению для пользователя

Автор ПЗ/ЗБ может либо установить число неуспешных попыток аутентификации, либо доверить это разработчику ОО или уполномоченному пользователю. Неуспешные попытки аутентификации не просто накапливаются, но скорее будут связаны с каким-либо событием аутентификации. Таким событием может быть число неуспешных попыток с момента последнего сеанса, успешно открытого с данного терминала.

Идентификация и аутентификация

    | /----------------------------------\   /---\

    |-|  FIA_AFL Отказы аутентификации   |---| 1 |

    | |                                  |   \---/

    | \----------------------------------/

    | /----------------------------------\   /---\

    |-|   FIA_ATD Определение атрибутов  |---| 1 |

    | |             пользователя         |   \---/

    | \----------------------------------/

    |                                        /---\

    | /----------------------------------\ /-| 1 |

    |-|   FIA_SOS Спецификация секретов  | | \---/

    | |                                  |-| /---\

    | \----------------------------------/ \-| 2 |

    |                                        \---/

    |                                                 /---\  /---\

    |                                      /----------| 1 |--| 2 |

    |                                      |     /---\\---/  \---/

    |                                      |-----| 3 |

    |                                      |     \---//---\

    |                                      |----------| 4 |

    | /----------------------------------\ |     /---\\---/

    |-|      FIA_UAU Аутентификация      | |-----| 5 |

    | |          пользователя            |-|     \---//---\

    | \----------------------------------/ |----------| 6 |

    |                                      |     /---\\---/

    |                                      \-----| 7 |

    |                                            \---/

    | /----------------------------------\   /---\  /---\

    |-|FIA_UJD Идентификация пользователя|---| 1 |--| 2 |

    | |                                  |   \---/  \---/

    | \----------------------------------/

    | /----------------------------------\   /---\

    \-|        FIA_USB Связывание        |---| 1 |

      |       пользователь-субъект       |   \---/

      \----------------------------------/

   Рисунок Ж.1 - Декомпозиция класса "Идентификация и аутентификация"

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

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

Автор ПЗ/ЗБ может устанавливать иные действия для ФБО, относящиеся в том числе и к правилам деблокирования процесса открытия сеанса пользователя или подаче сигнала тревоги администратору. Примерами таких действий являются: до истечения установленного времени; пока уполномоченный администратор вновь не деблокирует терминал или учетные данные пользователя; до истечения времени, связанного с предыдущими неуспешными попытками (например, после каждой неуспешной попытки время блокирования удваивается).

Операции

Назначение

В FIA_AFL.1.1 автору ПЗ/ЗБ следует специфицировать задаваемое по умолчанию число неуспешных попыток аутентификации, при достижении или превышении которого будут инициироваться определенные действия. В ПЗ/ЗБ можно указать, что "это число выбирается уполномоченным администратором".

В FIA_AFL.1.1 автору ПЗ/ЗБ следует специфицировать события аутентификации. Примерами являются: число неуспешных попыток аутентификации для данного идентификатора пользователя с момента последней успешной попытки; число неуспешных попыток аутентификации для данного терминала с момента последней успешной попытки; число неуспешных попыток аутентификации за последние 10 мин. Необходимо указать по меньшей мере одно событие аутентификации.

В FIA_AFL.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае достижения или превышения предельного значения числа попыток. Такими действиями могут быть: блокирование учетных данных на 5 мин, блокирование терминала на увеличивающийся интервал времени (число секунд, равное 2", где n - число неуспешных попыток) или блокирование, с уведомлением администратора, учетных данных вплоть до его снятия администратором. В описании действий следует указать принимаемые меры и сроки их действия (или условия прекращения действия этих мер).

Ж.2 Определение атрибутов пользователя (FIA_ATD)

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

Замечания для пользователя

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

FIA_ATD.1 Определение атрибутов пользователя

Замечания по применению для пользователя

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

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

Операции

Назначение

В FIA_ATD.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, ассоциируемые с каждым отдельным пользователем. Примером может служить список, включающий в себя атрибуты "уровень допуска", "идентификатор группы", "права".

Ж.3 Спецификация секретов (FIA_SOS)

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

Секреты могут генерироваться вне ОО, например выбираться пользователями и вводиться в систему. При этом может быть использован компонент FIA_SOS.1 для обеспечения соответствия секретов, сгенерированных вне системы, конкретным условиям, таким как минимально допустимый размер, отсутствие в словаре и/или неприменение ранее.

Секреты могут генерироваться самим ОО. В этом случае требование, чтобы сгенерированные ОО секреты соответствовали специфицированной метрике, обеспечивается компонентом FIA_SOS.2.

Замечания для пользователя

Секреты, рассматриваемые в данном семействе, содержат аутентификационные данные, предъявляемые пользователем механизму аутентификации, основанному на сведениях, которыми располагает пользователь. Когда используются криптографические ключи, вместо этого семейства следует использовать семейства класса FCS.

FIA_SOS.1 Верификация секретов

Замечания по применению для пользователя

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

Операции

Назначение

В FIA_SOS.1.1 автору ПЗ/ЗБ следует предоставить определенную метрику качества. Эта метрика может быть специфицирована как собственно описание проверки качества или как ссылка на государственный стандарт, определяющий метрики качества, соответствие которым необходимо для секретов. К примерам метрик качества относятся описание допустимых символьных структур секретов и/или допустимых размеров секретов.

FIA_SOS.2 Генерация секретов ФБО

Компонент FIA_SOS.2 позволяет ФБО генерировать секреты для специальных функций, таких как аутентификация по паролю.

Замечания по применению для пользователя

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

Операции

Назначение

В FIA_SOS.2.1 автору ПЗ/ЗБ следует предоставить определенную метрику качества. Эта метрика может быть специфицирована как собственно описание проверки качества или как ссылка на государственный стандарт, определяющий метрики качества, соответствие которым необходимо для секретов. К примерам метрик качества относятся описание допустимых символьных структур секретов и/или допустимых размеров секретов.

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

Ж.4 Аутентификация пользователя (FIA_UAU)

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

FIA_UAU.1 Выбор момента аутентификации

Замечания по применению для пользователя

Компонент FIA_UAU.1 содержит требование, чтобы автор ПЗ/ЗБ определил список действий, которые выполняются при посредничестве ФБО и допускаются ФБО от имени пользователя до того, как будет произведена аутентификация пользователя. Эти действия, выполняемые при посредничестве ФБО, не следует относить к безопасности для пользователей, неверно идентифицировавших себя еще до аутентификации. Все прочие действия, выполняемые при посредничестве ФБО и не включенные в этот список, разрешаются пользователю только после завершения аутентификации.

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

Операции

Назначение

В FIA_UAU.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя, прежде чем завершится аутентификация пользователя. Этот список не может быть пустым. Если таких действий нет, следует вместо этого компонента использовать компонент FIA_UAU.2. Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

FIA_UAU.2 Аутентификация до любых действий пользователя

Замечания по применению для пользователя

Компонент FIA_UAU.2 содержит требование завершения аутентификации пользователя до выполнения любых действий при посредничестве ФБО от имени этого пользователя.

FIA_UAU.3 Аутентификация, защищенная от подделок

Замечания по применению для пользователя

Компонент FIA_UAU.3 содержит требования к механизмам, предоставляющим защиту аутентификационных данных. Аутентификационные данные, заимствованные у другого пользователя или полученные незаконным способом, следует обнаружить и/или отвергнуть. Эти механизмы предоставляют уверенность, что пользователи, аутентифицированные ФБО, действительно те, кем они представляются.

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

Операции

Выбор

В FIA_UAU.3.1 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать подделку данных аутентификации.

В FIA_UAU.3.2 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать копирование данных аутентификации.

FIA_UAU.4 Механизмы одноразовой аутентификации

Замечания по применению для пользователя

Компонент FIA_UAU.4 содержит требования к механизмам аутентификации, основанным на аутентификационных данных одноразового использования. В качестве таких данных может использоваться то, что пользователь имеет или знает, но не свойства самого пользователя. Примеры одноразовых данных аутентификации пользователя: одноразовые пароли, зашифрованные метки времени, случайные числа секретной таблицы преобразований.

Автор ПЗ/ЗБ может определить, к какому механизму(ам) аутентификации применимы эти требования.

Операции

Назначение

В FIA_UAU.4.1 автору ПЗ/ЗБ следует привести список механизмов аутентификации, к которым применяется это требование. Назначением может быть: "все механизмы аутентификации". Примером назначения может быть: "механизмы аутентификации, используемые для аутентификации пользователей во внешней сети".

FIA_UAU.5 Сочетание механизмов аутентификации

Замечания по применению для пользователя

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

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

Для допуска в систему анонимных пользователей можно ввести механизм аутентификации типа "отсутствие аутентификации". Использование доступа такого типа следует четко разъяснить в правилах FIA_UAU.5.2.

Операции

Назначение

В FIA_UAU.5.1 автору ПЗ/ЗБ следует определить предоставляемые механизмы аутентификации. Примером списка механизмов может служить: "отсутствие аутентификации, механизм пароля, биометрия (сканирование сетчатки), механизм ключа шифрования".

В FIA_UAU.5.2 автору ПЗ/ЗБ следует специфицировать правила, описывающие, как механизмы обеспечивают аутентификацию и когда используется каждый из них. Это значит, что для любой возможной ситуации необходимо указать совокупность механизмов, которые могли бы использоваться для аутентификации. Пример такого правила: "Для аутентификации пользователей, имеющих особые права доступа, должны использоваться совместно механизм пароля и биометрия, причем аутентификация успешна при успешной аутентификации каждым механизмом; для аутентификации остальных пользователей должен использоваться только механизм пароля".

Автор ПЗ/ЗБ может задать ограничения, в пределах которых уполномоченному администратору разрешено специфицировать конкретные правила. Пример правила: "аутентификация пользователя всегда должна производиться посредством аппаратного ключа; администратор может специфицировать дополнительные механизмы аутентификации, которые также необходимо использовать". Автор ПЗ/ЗБ может и не специфицировать ограничения, а оставить выбор механизмов аутентификации и их правил полностью на усмотрение уполномоченного администратора.

FIA_UAU.6 Повторная аутентификация

Замечания по применению для пользователя

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

Операции

Назначение

В FIA_UAU.6.1 автору ПЗ/ЗБ следует привести список условий, требующих повторной аутентификации. Этот список может включать в себя завершение периода времени, выделенного пользователю, запрос пользователя с целью изменения действующих атрибутов безопасности или запрос пользователя к ФБО с целью выполнения некоторых критичных функций безопасности.

Автор ПЗ/ЗБ может задать пределы, в которых следует допускать повторную аутентификацию, оставив их детализацию на усмотрение уполномоченного администратора. Пример подобного правила: "пользователь должен проходить повторную аутентификацию не реже одного раза в сутки; администратор может потребовать более частую повторную аутентификацию, но не чаще одного раза в 10 мин".

FIA_UAU.7 Аутентификация с защищенной обратной связью

Замечания по применению для пользователя

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

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

Операции

Назначение

В FIA_UAU.7.1 автору ПЗ/ЗБ следует определить вид обратной связи с пользователем при проведении аутентификации. Примером такого назначения может служить: "число набранных символов", другой тип обратной связи - "механизм аутентификации, через который не удалось осуществить аутентификацию".

Ж.5 Идентификация пользователя (FIA_UID)

Семейство FIA_UID определяет условия, при которых от пользователей требуется собственная идентификация до выполнения при посредничестве ФБО каких-либо иных действий, требующих идентификации пользователя.

FIA_UID.1 Выбор момента идентификации

Замечания по применению для пользователя

Компонент FIA_UID.1 устанавливает требования по идентификации пользователей. Автор ПЗ/ЗБ может указать конкретные действия, которые могут быть выполнены до завершения идентификации.

При использовании компонента упоминаемые в нем действия, которые допускается выполнять при посредничестве ФБО до идентификации, следует также привести и в компоненте FIA_UAU.1.

Операции

Назначение

В FIA_UID.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя до его собственной идентификации. Этот список не может быть пустым. Если приемлемых действий нет, следует вместо этого компонента использовать компонент FIA_UID.2. Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

FIA_UID.2 Идентификация до любых действий пользователя

Замечания по применению для пользователя

Компонент FIA_UID.2 содержит требование идентификации пользователей. До идентификации пользователя ФБО не допускают выполнение им никаких действий.

Ж.6 Связывание пользователь-субъект (FIA_USB)

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

FIA_USB.1 Связывание пользователь-субъект

Замечания по применению для пользователя

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