ГОСТ Р ИСО/МЭК15408-2—2008
да ПБО» и ADVJNT.3 «Минимизация сложности». Кроле того, если требуется полное посредничество при обра
щениях. требования компонентов из класса FDP «Защита данных пользователя» необходимо распространить на
все объекты.
J.11.2 FPT
_
SEP.1 Отделение домена ФБО
J.11.2.1 Замечания для пользователя
Без отдельного защищенного домена для ФБО не может быть доверия тому, что ФБО не подвергались
каким-либо воздействиям со стороны недоверенных субъектов. Такие воздействия могут привести к модифика ции
кода и/ипи структур данных ФБО.
J.11.3 FPT
_
SEP.2 Отделение домена ПФБ
J.11.3.1 Замечания по применению для пользователя
Наиболее важной функцией ФБО является поддержка осуществляемых ими ПФБ. Чтобы упростить разра
ботку ПФБ и приблизить их свойства к свойствам монитора обращений, в частности, к стойкости к воздействиям,
функции, проводящие ПФБ. необходимо сосредоточить в домене, отличном от остальной части ФБО.
J.11.3.2 Замечания по применению для оценщика
Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функций, чем требу
ется в ПФБ. Это проистекает из практической реализации многоуровневого проекта программного обеспечения.
При этом функции, не относящиеся к ПФБ, следует свести к минимуму.
Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене
монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или несколь ких
ПФБ). Если имеется несколько доменов монитора обращений для нескольких ПФБ. они могут быть равно
правными или образовывать иерархию.
Для FPT
_
SEP.2.1 выражение «неизолированная часть ФБО» относится к той части ФБО. которая не охваче
на в FPT
_
SEP.2.3.
J.11.3.3 Операции
J.11.3.3.1 Назначение
В FPT
_
SEP.2.3 автору ПЗ’ЗБ следует специфицировать те ПФБ управления доступом и/ипи информацион
ными потоками, которым следует занимать отдельный домен.
J.11.4 FPT
_
SEP.3 Полный монитор обращений
J.11.4.1 Замечания по применению для пользователя
Наиболее важной функцией из числа ФБО является поддержка осуществляемых ими ПФБ. Компонент
FPT
_
SEP.3 завершает требования предыдущих компонентов семейства, устанавливая, что все функции безопас
ности. проводящие ПФБ управления доступом и>’или информационными потоками, будут выполняться в домене,
отличном от домена выполнения остальных ФБО. Эго упрощает разработку ФБО и приближает их свойства к
свойствам монитора обращений, в частности, к стойкости к воздействиям.
J.11.4.2 Замечания по применению для оценщика
Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функций, чем требу
ется в ПФБ. Это проистекает из практической реализации многоуровневого проекта программного обеспечения.
При этом функции, не относящиеся к ПФБ, следует свести к минимуму.
Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене
монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или несколь ких
ПФБ). Если имеется несколько доменов монитора обращений для нескольких ПФБ. они могут или быть
равноправными, или образовывать иерархию.
J.12 Протокол синхронизации состояний (FPT
_
SSP)
J.12.1 Замечания для пользователя
Распределенные системы могут иметь ббльшую сложность, чем нераспределенные, из-за многообразия
состояний частей системы, а также из-за задержек связи. В большинстве случаев синхронизация состояния
между распределенными функциями включает в себя, вместо обычных действий, применение протокола обме на.
Если в среде распределенных систем существуют угрозы безопасности, потребуются более сложные защи
щенные протоколы.
Семейство FPT
_
SSP «Протокол синхронизации состояний» устанавливает требование использования на
дежных протоколов некоторыми критичными по безопасности функциями из числа ФБО. Оно обеспечивает, что бы
две распределенные части ОО (например главные ЭВМ) синхронизировали свои состояния после действий,
связанных с безопасностью.
Некоторые состояния невозможно синхронизировать, или затраты на транзакцию будут слишком велики
для практического применения; отмена ключа шифрования является примером, когда после выполнения дей
ствия состояние может стать неопределенным. Другой пример; действие предпринято, а подтверждение не
может быть отправлено либо сообщение проигнорировано получателем и поэтому отмены не произойдет.
Неопределенность присуща распределенным системам. Проблема неопределенности связана с необходимо
стью синхронизации состояний и может решаться соответствующими методами. Планировать неопределенные
состояния бесполезно: в подобных случаях автору ПЗ/ЗБ следует прибегнуть к другим требованиям (например
подача сигнала тревоги, проведение аудита).
156