Лекция 1: Обзор наиболее важных стандартов и спецификаций в области информационной безопасности



бет11/17
Дата25.10.2022
өлшемі0.51 Mb.
#463316
түріЛекция
1   ...   7   8   9   10   11   12   13   14   ...   17
!СтандартыИБ УчебноеПособие

Семейство FIA_UID ( идентификация пользователя) включает два компонента и определяет набор действий (например, получение справочной информации), которые разрешается выполнять до идентификации. Обычно применяют более сильный компонент FIA_UID.2 - идентификация до любых действий, выполняемых пользователем при посредничестве функций безопасности.
Семейство FIA_UAU ( аутентификация пользователя ) устроено сложнее. Оно специфицирует типы механизмов аутентификации и используемые при этом атрибуты. Два первых компонента, FIA_UAU.1 (выбор момента аутентификации) и FIA_UAU.2 ( аутентификация до любых действий пользователя), играют (применительно к аутентификации) ту же роль, что и компоненты семейства FIA_UID. На реализацию надежной аутентификации, устойчивой к сетевым угрозам, направлены компоненты FIA_UAU.3 ( аутентификация, защищенная от подделок), FIA_UAU.4 ( механизмы одноразовой аутентификации ) и FIA_UAU.5 ( сочетание механизмов аутентификации ). После периода неактивности пользователя и в ряде других ситуаций уместно применение компонента FIA_UAU.6 (повторная аутентификация ). Наконец, FIA_UAU.7 (аутентификация с защищенной обратной связью) указывает, как отображать пароль при вводе.
Семейство FIA_ATD ( определение атрибутов пользователя ) предусматривает наличие у пользователей не только идентификаторов, но и других атрибутов безопасности, предписываемых политикой безопасности.
Обычно после успешной идентификации и аутентификации от имени пользователя начинает действовать некий процесс (субъект). Семейство FIA_USB ( связывание пользователь-субъект ) содержит требования по ассоциированию атрибутов безопасности пользователя с этим субъектом.
Выявлением и реагированием на неудачи аутентификации ведает семейство FIA_AFL ( отказы аутентификации ). Разумеется, и число допустимых неудачных попыток, и действия, выполняемые при превышении порога неудач, - все это параметры единственного компонента семейства.
Обычно пользователь доказывает свою подлинность, сообщая нечто, что знает только он ( "секрет" в терминологии ОК). Семейство FIA_SOS (спецификация секретов) вводит понятие метрики качества секретов и содержит требования к средствам проверки качества и генерации секретов заданного качества. Примеры подобных средств - проверка выполнения технических ограничений на пользовательские пароли в ОС Unix и программные генераторы паролей.
В целом класс FIAпо сравнению с FAU, менее конкретен, его компоненты слишком параметризованы. Вероятно, это связано с тем, что криптография, без которой надежная и удобная для пользователя аутентификация невозможна, находится вне рамок "Общих критериев".
Класс FRU ( использование ресурсов ) включает три семейства, призванные разными способами поддерживать высокую доступность.
Выполнение требований семейства FRU_FLT ( отказоустойчивость ) должно обеспечить корректную работу всех или хотя бы некоторых функций объекта оценки даже в случае сбоев.
FRU_PRS ( приоритет обслуживания ) регламентирует действия по защите высокоприоритетных операций от препятствий или задержек со стороны операций с более низким приоритетом.
Семейство FRU_RSA ( распределение ресурсов ) для достижения высокой доступности ресурсов привлекает механизм квот.
Обращение к вопросу высокой доступности - несомненное достоинство "Общих критериев", которое, к сожалению, несколько проигрывает из-за отсутствия системного подхода. По неясным причинам в качестве сущностей одного уровня выделен один из трех высокоуровневых аспектов доступности и два механизма, способствующих ее поддержанию.
За пределами рассмотрения остались надежность и обслуживаемость, да и отказоустойчивость может достигаться очень разными способами - от использования многопроцессорных конфигураций до организации резервных вычислительных центров.
Помимо двух рассмотренных механизмов поддержания доступности существуют и другие, не менее важные, например, балансировка загрузки, проактивное управление и т.п. На наш взгляд, было бы целесообразным обобщить требования к доступности регистрационного журнала (см. выше семейство FAU_STG) на случай произвольных ресурсов.
Отметим также, что включение в класс FRU конкретных механизмов еще резче обозначает излишнюю обобщенность требований класса FIA.
Мы приступаем к рассмотрению двух следующих классов функциональных требований безопасности:

  • FCO - связь;

  • FPR - приватность.

Класс FCO состоит из двух семейств, FCO_NRO и FCO_NRR, ведающих неотказуемостью (невозможностью отказаться от факта отправки или получения данных), которая достигается путем избирательной или принудительной генерации допускающих верификацию свидетельств, позволяющих ассоциировать атрибуты отправителя (получателя) с элементами передаваемых данных.
Класс FPR ( приватность ) содержит четыре семейства функциональных требований, обеспечивающих защиту пользователя от раскрытия и несанкционированного использования его идентификационных данных.
Семейство FPR_ANO ( анонимность ) дает возможность выполнения действий без идентификатора пользователя. Анонимность может быть полной или выборочной. В первом случае функции безопасности обязаны предоставить заданный набор услуг без запроса идентификатора пользователя. Во втором предусмотрено более слабое требование, в соответствии с которым идентификатор может запрашиваться, но должен скрываться от заранее указанных пользователей и/или субъектов.
Семейство FPR_PSE ( псевдонимность ) обеспечивает условия, когда пользователь может использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время подотчетным за свои действия. Базовый компонент семейства, FPR_PSE.1, предписывает выборочную анонимность, а также наличие средств генерации заданного числа псевдонимов и определения или принятия псевдонима от пользователя с верификацией соответствия некоторой метрике псевдонимов. Эти требования дополняются в компоненте FPR_PSE.2 (обратимая псевдонимность ) возможностью определения доверенными субъектами идентификатора пользователя по представленному псевдониму, а в компоненте FPR_PSE.3 (альтернативная псевдонимность ) - возможностью оперативного перехода на новый псевдонимсвязь которого со старым проявляется лишь в заранее оговоренных ситуациях.
Семейство FPR_UNL ( невозможность ассоциации ) содержит единственный компонент, предусматривающий неоднократное применение пользователем информационных сервисов, не позволяя заданным субъектам ассоциировать их между собой и приписывать одному лицу. Невозможность ассоциации защищает от построения профилей поведения пользователей (см. выше компонент FAU_SAA.2).
Самым сложным в классе FPR является семейство FPR_UNO ( скрытность ). Его требования направлены на то, чтобы пользователь мог незаметно для кого бы то ни было работать с определенными информационными сервисами. Наиболее интересны два из четырех имеющихся компонентов семейства. FPR_UNO.2 ( распределение информации, влияющее на скрытность ) предписывает рассредоточить соответствующие данные по различным частям объекта оценки. Это одно из немногих архитектурных требований "Общих критериев" (правда, выраженное в очень общей форме). В некотором смысле противоположную роль играет компонент FPR_UNO.4 (открытость для уполномоченного пользователя), согласно которому уполномоченные пользователи должны иметь возможность наблюдать за тем, как употребляются заданные ресурсы и/или услуги. (Как сказал один пессимист: "Я так и знал, что этим все кончится!")
Требования приватности ставят очень серьезную проблему многоаспектности информационной безопасности, заставляют искать баланс конфликтующих интересов субъектов информационных отношений. Разработчики заданий по безопасности должны учесть и конкретизировать эти требования с учетом действующего законодательства и специфики систем ИТ.


Достарыңызбен бөлісу:
1   ...   7   8   9   10   11   12   13   14   ...   17




©dereksiz.org 2024
әкімшілігінің қараңыз

    Басты бет