Требования к произвольному (дискреционному) управлению доступом
Дальнейшее изложение основано на первой редакции проекта [1] Руководящего документа Гостехкомиссии России "Безопасность информационных технологий. Контролируемый доступ. Профиль защиты" (ПЗ КД), подготовленной в Центре безопасности информации. Его прототип [38], базирующийся на версии 2.0 "Общих критериев", был разработан в 1999 году в Агентстве национальной безопасности США.
В принципе, ПЗ КД соответствует классу безопасности C2 "Оранжевой книги" [41] или пятому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники [17], однако применение методологии и обширного набора требования безопасности из "Общих критериев" позволило сделать профиль, по сравнению с упомянутыми документами, существенно более детальным и обоснованным.
Из соответствия классу безопасности C2 следует, что в ПЗ КД рассматривается только дискреционное (произвольное) управление доступом. Требования, включенные в профиль, направлены на достижение базового уровня безопасности в условиях невраждебного и хорошо управляемого сообщества пользователей при наличии лишь непреднамеренных угроз.
Из числа частных функциональных требований ПЗ КД выделим наиболее важные:
- ассоциация идентификатора пользователя (FAU_GEN.2). Функции безопасности должны ассоциировать каждое потенциально протоколируемое событие с идентификатором пользователя - инициатора этого события (на первый взгляд кажется, что из данного требования есть очевидные исключения, например, неудачные попытки идентификации/аутентификации, однако на этой стадии средства контролируемого доступа еще не используются, а за идентификацию и аутентификацию отвечает другой сервис безопасности);
- выборочный просмотр аудита (FAU_SAR.3). Необходимо предоставить возможность поиска, сортировки, упорядочения регистрационных данных, основываясь на идентификаторах пользователей и, быть может, других специфицированных атрибутах;
- управление доступом, основанное на атрибутах безопасности (FDP_ACF.1).
Проводимая политика дискреционного управления доступом должна основываться на таких атрибутах, как идентификатор пользователя и принадлежность к группе (группам), а также атрибутах, ассоциированных с объектами. Последние дают возможность сопоставления разрешенных и запрещенных операций с идентификаторами одного или более пользователей и/или групп, задания разрешенных или запрещенных по умолчанию операций; - определение атрибутов пользователя (FIA_ATD.1). Для каждого пользователя должен поддерживаться следующий список атрибутов безопасности: идентификатор пользователя, принадлежность к группе, данные аутентификации, допустимые роли;
верификация секретов (FIA_SOS.1). При однократной попытке использования механизма аутентификации или при неоднократных попытках в течение одной минуты вероятность случайного доступа должна быть меньше 1:1000000. Любая обратная связь при попытках использования механизма аутентификации не должна приводить к превышению указанного уровня вероятности;- связывание пользователь-субъект (FIA_USB.1). Функции безопасности должны ассоциировать следующие атрибуты безопасности пользователя с субъектами, действующими от имени этого пользователя: идентификатор пользователя, который ассоциируется с событиями аудита; идентификаторы пользователя, применяемые для осуществления политики дискреционного управления доступом; принадлежность к группам, используемая для осуществления политики дискреционного управления доступом;
- инициализация статических атрибутов (FMT_MSA.3). Должны обеспечиваться ограничительные подразумеваемые значения для атрибутов безопасности, при помощи которых осуществляется политика дискреционного управления доступом (FMT_MSA.3.1). Должна предоставляться возможность определения альтернативных начальных значений для отмены подразумеваемых значений при создании объектов (FMT_MSA.3.2);
- отмена (FMT_REV.1). Право отмены атрибутов безопасности, ассоциированных с объектами, необходимо предоставлять только пользователям, уполномоченным на это политикой дискреционного управления доступом (FMT_REV.1.1).
Рассмотренный проект профиля показывает, что выделение общих требований к сервисам безопасности значительно сокращает специфическую часть, облегчает ее изучение и верификацию.
