Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

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)

<== предыдущая лекция | следующая лекция ==>
H.7.1 Замечания для пользователя | I.1.1 Замечания для пользователя
Поделиться с друзьями:


Дата добавления: 2014-01-15; Просмотров: 300; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.011 сек.