H.7.4.2.1 Назначение

H.7.4.2 Операции

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

H.7.3.2.1 Назначение

H.7.3.2 Операции

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

H.7.2.2.1 Назначение

H.7.2.2 Операции

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

Компонент FMT_SMR.1 определяет различные роли, которые ФБО следует распознавать. В системах часто проводится различие между владельцем сущности, администратором и остальными пользователями.

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

H.7.3 FMT_SMR.2 Ограничения на роли безопасности

Компонент FMT_SMR.2 специфицирует различные роли, которые ФБО следует распознавать, и условия, при которых этими ролями можно управлять. В системах часто проводится различие между владельцем сущности, администратором и другими пользователями.

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

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

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

H.7.4 FMT_SMR.3 Принятие ролей

Компонент FMT_SMR.3 определяет, что для принятия некоторых ролей необходим явный запрос.

В FMT_SMR.3.1 автору ПЗ/ЗБ следует специфицировать роли, для принятия которых требуется явный запрос. Примеры: аудитор и администратор.

Приложение I
(обязательное)
Приватность (FPR)

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

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

Класс FPR вместе с другими классами (содержащими требования аудита, управления доступом, предоставления доверенного маршрута и неотказуемости) обеспечивает гибкость при спецификации желательного режима приватности. В то же время, требования этого класса могут налагать ограничения на использование компонентов других классов, таких как FIA «Идентификация и аутентификация» или FAU «Аудит безопасности». Например, если уполномоченным пользователям не разрешено знать идентификатор пользователя (например, в семействах «Анонимность» или «Псевдонимность»), то, очевидно, невозможно будет оставить отдельных пользователей ответственными за выполняемые ими относящиеся к безопасности действия, на которые распространяются требования приватности. Тем не менее, и в этом случае возможно включение в ПЗ/ЗБ требований аудита, когда само возникновение некоторых событий, связанных с безопасностью, важнее, чем знание того, кто был их инициатором.

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

Этот класс содержит четыре семейства: «Анонимность», «Псевдонимность», «Невозможность ассоциации» и «Скрытность». Три первых семейства имеют сложные взаимосвязи. При выборе семейства для применения следует учитывать выявленные угрозы. Для некоторых типов угроз приватности «Псевдонимность» подойдет больше, чем «Анонимность» (например, при требовании проведения аудита). Кроме того, некоторым видам угроз приватности наилучшим образом противостоит сочетание компонентов из нескольких семейств.

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

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

FPR_ANO Анонимность

FPR_PSE Псевдонимность

FPR_UNL Невозможность ассоциации

FPR_UNO Скрытность

Следует, чтобы ФБО предоставляли защиту от действий не только отдельных пользователей, но и пользователей, объединившихся для получения определенной информации. Декомпозиция класса FPR на составляющие его компоненты приведена на рисунке I.1.

Рисунок I.1 – Декомпозиция класса FPR «Приватность»

I.1 Анонимность (FPR_ANO)

Дата добавления: 2014-01-15