Типовые требования к управлению электронными официальными документами (стр. 31 )

Эти уровни доступа э(64) превосходят любые другие права доступа, которые могут быть предоставлены с использованием возможностей, определенных в главе 4. Требования  данного раздела применимы только в организациях с потребностью в таких правах.

Это достигается назначением одного или более «грифа ограничения доступа э(63)» к классам э(11), делам э(34), разделам э(66), томам э(74) и/или официальным документам э(52).

Термин «гриф ограничения доступа э(63)» используется в данной спецификации со значением «один или несколько терминов, ассоциированных с официальным документом э(52), которые определяют управление правилами доступа к нему». Заметим, что этот термин используется исключительно для данной спецификации; не для обычного применения.

Пользователям э(68) может быть назначен единый гриф ограничения доступа э(63), который предотвращает доступ ко всем агрегациям э(3) или официальным документам э(52), которым был назначен более высокий гриф ограничения доступа э(63).

Грифы ограничения доступа э(63) могут состоять из подкатегорий. Некоторые подкатегории являются иерархическими по своей природе. Другие подкатегории могут быть организованы иначе, обычно уникальным для организации или сектора способом.

MoReq2 детально описывает только требования для иерархически выстроенных подкатегорий.

Примеры, приведенные здесь, основаны на применении меток национальной безопасности, но те же принципы применимы для меток, используемых в других секторах.

Могут также существовать специфическая для страны национальная классификация требований по безопасности. Если это необходимо, к ним можно адресовать в нулевой главе.

№	Требование	Тест
СУЭОД э(32) обязательно должна разрешать выбор одной из следующих опций на этапе конфигурации э(20): грифы ограничения доступа э(63) назначаются классам э(11), делам э(34), разделам э(66) и/или томам э(74) (а не индивидуальным официальным документам э(52)); грифы ограничения доступа э(63) назначаются индивидуальным официальным документам э(52) (а не классам э(11), делам э(34), разделам э(66) и/или томам э(74)); грифы ограничения доступа э(63) назначаются как индивидуальным официальным документам э(52), так и классам э(11), делам э(34), разделам э(66) и/или томам э(74).	Д
Некоторые организации захотят контролировать конфиденциальные официальные документы э(52) индивидуально, тогда как другие захотят контролировать их на уровне класса э(11), дела э(34) и так далее.
СУЭОД э(32) обязательно должна разрешать роли администратора э(1) указывать на этапе конфигурации э(20), какие роли э(62) могут указывать и менять гриф ограничения доступа э(63) для официальных документов э(52)  и агрегаций э(3).	Д
В некоторых организациях только владельцы э(44) информации будут обладать данной привилегией. В других другие роли э(62), такие как службы безопасности или линейные менеджеры (если такие роли э(62) существуют) будут иметь эти привилегии.
СУЭОД э(32) обязательно должна разрешать, но не обязательно требовать, чтобы грифы ограничения доступа э(63) состояли из одной или более «подкатегорий».	Д
Например, гриф ограничения доступа э(63) может состоять из трех подкатегорий, как в следующем вымышленном примере:
Класс безопасности; Предостережение; Описание.
Каждая подкатегория может рассматриваться, как одно изменение, определяющее уровень безопасности информации. Так, в этом примере любая возможная комбинация из трех подкатегорий – класс безопасности, предостережение и описание, которые могут быть применены к официальному документу э(52).
СУЭОД э(32) обязательно должна требовать от роли администратора э(1) определение и поддержку контрольных словарей, лимитирующих разрешаемые значения для каждой подкатегории.	Д
Например, подкатегории могут быть, как в следующем вымышленном примере:
Подкатегория Допустимые значения Класс безопасности (гриф) Сов. секретно Секретно Конфиденциально Ограниченного доступа Без ограничений Предостережение NATO Eyes Onl y7 WEU Eyes Only Описание Коммерческая информация Персональная информация Управление Аудит и бухгалтерия
В этом вымышленном примере, подкатегория «класс безопасности» является иерархической (см. э10.13.6), в то время как другие подкатегории – нет. Требования для иерархических категорий являются общими;  они описаны ниже.
Требования к неиерархическим подкатегориям могут быть более сложными и специфическими для сектора, в котором они применяются; за исключением требований э10.13.5 и э10.13.7 они не представлены здесь детально.
СУЭОД э(32) должна позволять специфические реализации сложных и уникальных правил безопасности.	Н
Это может быть достижимо за счет надлежащего интерфейса прикладного программирования (API). Примерами потребности в них может быть необходимость управления официальными документами э(52) с использованием меток, не получивших отражения здесь,  таких как метки IDO (International Defence Organisation) или метки ограничения доступа к медицинским официальным документам э(52).
По крайней мере, для одной подкатегории СУЭОД э(32) обязательно должна поддерживать иерархию как минимум пяти уровней, от доступа без ограничений на высшем уровне до строго ограниченного доступа на нижнем уровне.	Д
Например, подкатегория «класс безопасности» (гриф) в требовании э10.13.3.
Там где подкатегория и соответствующие уровни допуска э(64) не выстроены иерархически, СУЭОД э(32) обязательно должна позволять выбор одной из следующих опций на этапе конфигурации э(20): СУЭОД э(32) обязательно должна требовать ввода имеющего силу допуска э(15) для каждого нового пользователя э(68); СУЭОД э(32) обязательно должна применять уровень допуска э(64) по умолчанию для новых пользователей э(68). Роль администратора э(1) обязательно должна быть способна переназначить уровень допуска э(64), назначенный по умолчанию на этапе конфигурации э(20) или позднее.	Д
Иными словами, применение уровней допуска э(64) для пользователей э(68) должно быть обязательным.
Там, где СУЭОД э(32) назначает новым пользователям э(68) иерархический уровень допуска э(64) по умолчанию (как в э10.13.7), она обязательно должна назначать им по умолчанию самый низший уровень допуска э(64) в иерархии (а именно, самый ограниченный).	Д
СУЭОД э(32) обязательно должна ограничивать доступ к официальным документам э(52) (и классам э(11), делам э(34), разделам э(66) и томам э(74) в зависимости от сделанного выбора в э10.13.1) теми пользователями э(68), у которых уровень допуска э(64) равен или выше, чем гриф ограничения доступа э(63).	Д
Заметим, что этот уровень допуска э(64) может быть недостаточным для получения доступа. Доступ к электронным официальным документам э(31) может быть дополнительно ограничен пользователями э(68), ролями э(62) и/или группами э(37), с функциями, описанными в главе 4.
Там, где подкатегория является иерархической, СУЭОД э(32) обязательно должна использовать один из следующих способов оперирования для назначения подкатегории новым классам э(11), официальным документам э(52) и др., выбранный ролью администратора э(1)  на этапе конфигурации э(20) (или позднее): СУЭОД э(32) обязательно должна применять значение по умолчанию, которое выбрано ролью администратора э(1); СУЭОД э(32) обязательно должна использовать по умолчанию значение родительской агрегации э(3); СУЭОД э(32) обязательно должна требовать от роли администратора э(1) ввести значение.	Д
Там, где подкатегория неиерархическая, СУЭОД э(32) обязательно должна использовать один из следующих способов оперирования для назначения подкатегории новым классам э(11), официальным документам э(52) и др., выбранный ролью администратора э(1) на этапе конфигурации э(20) (или позднее): СУЭОД э(32) обязательно должна применять значение по умолчанию, которое выбрано ролью администратора э(1); СУЭОД э(32) обязательно должна использовать по умолчанию значение родительской агрегации э(3); СУЭОД э(32) обязательно должна разрешать, но не должна требовать от роли администратора э(1) введение значения.	Д
Когда определяется новый иерархический гриф ограничения доступа э(63) или подкатегория, СУЭОД э(32) обязательно должна применять значение по умолчанию ко всем существующим классам э(11), официальным документам э(52) и др., а именно самый нижний уровень в иерархии, другими словами, по умолчанию должен предоставляться минимальный набор прав доступа в иерархии.	Д
СУЭОД э(32) должна позволять пользователям э(68) назначать уровень допуска э(64) для роли э(62) и «по наследству». Там, где уровень допуска э(64) унаследован от роли э(62), СУЭОД э(32) обязательно должна разрешать применение другого уровня допуска э(4) для индивидуального пользовательского э(68) уровня.	Д
Если СУЭОД э(32) поддерживает единые грифы ограничения доступа э(63) одновременно действующие как на официальные документы э(52), так и на классы э(11) и др. (смотри э10.13.1), она должна быть способна не разрешать классу э(11), делу э(34), разделу э(66) или тому э(74) иметь более низкий гриф ограничения доступа э(63), чем любой  содержащийся в них официальный документ э(52).	Д
Если пользователь э(68) пытается захватить э(8) официальный документ э(52), который обладает более высоким грифом ограничения доступа э(63), чем агрегация э(3), в которую он захватывается э(8), то СУЭОД э(32) обязательно должна уведомить пользователя э(68) о необходимых действиях; СУЭОД э(32) обязательно должна разрешать как минимум следующие действия (предполагая, что они были разрешены на этапе конфигурации э(20)): повышение грифа ограничения доступа э(63) для агрегации э(3) до уровня официального документа э(52); отказ пользователю э(68) в разрешении захватывать э(8) официальный документ э(52) в агрегацию э(3); автоматическая пересылка официального документа э(52) указанному пользователю э(68) для обработки; пользователю э(68) предлагается создать новую агрегацию э(3) для официального документа э(52) со значениями метаданных э(40), взятых из оригинальной агрегации э(3), по умолчанию; а затем захватить э(8) официальный документ э(52) в новую агрегацию э(3), как один интегрированный процесс.	Д
Роль администратора э(1) обязательно должна быть способна назначить наивысший гриф ограничения доступа э(63) для любого официального документа э(52) в любом классе э(11), деле э(34), разделе э(66) или томе э(74) посредством одного простого запроса.	Д
В некоторых случаях это может быть важная функция в целях повышения управляемости.
В соответствии с поддержкой требования э10.13.1, роль администратора э(1) обязательно должна быть способна изменять гриф ограничения доступа э(63) для класса э(11), дела э(34), раздела э(66), тома э(74) или официального документа э(52).	Д
Смотри также э10.13.27.
СУЭОД э(32) должна поддерживать рутинный, периодический, запланированный пересмотр грифов ограничения доступа э(63), состоящий из: разрешения пользователю э(68) (с надлежащими допуском э(15) и разрешениями) просмотр определенных официальных документов э(52)  и их грифов ограничения доступа э(63); разрешения пользователю э(68) изменять грифы ограничения доступа э(63).	Д
MoReq2 не указывает, как это достигается.
СУЭОД э(32) должна автоматически сохранять историю значений грифов ограничения доступа э(63) в метаданных э(40) официальных документов э(52), классов э(11) и так далее, к которым они относятся.	Д
Когда пользователь э(68) изменяет значение грифа ограничения доступа э(63) (во время пересмотра, как в э10.13.18, или в других случаях), СУЭОД э(32) обязательно должна разрешать пользователю э(68) вводить причину изменения и должна сохранять ее в истории (как в э10.13.19) как метаданные э(40).	Д
Смотри э10.13.2, детализирующий, каким пользователям э(68) разрешено изменять грифы ограничения доступа э(63)
СУЭОД э(32) обязательно должна разрешать пользователям э(68), у которых есть допуск э(15) и разрешения, позволяющие видеть официальный документ э(52), видеть текущие значение(я) его грифа(ов) ограничения доступа э(63) и любую историю (как в э10.13.19).	Д
СУЭОД э(32) должна поддерживать назначение грифа ограничения доступа э(63) для класса э(11), дела э(34), раздела э(66) или тома э(74), имеющего силу только в определенный период времени, и должна автоматически снижать уровень грифа ограничения доступа э(63) до низшего уровня по окончании этого периода.	Д
СУЭОД э(32) должна поддерживать назначение грифа ограничения доступа э(63) для класса э(11), дела э(34), раздела э(66) или тома э(74), имеющего силу только в определенный период времени, и должна автоматически снижать уровень грифа ограничения доступа э(63) до низшего, заранее определенного уровня грифа ограничения доступа э(63) по окончании этого периода.	Д
СУЭОД э(32) должна поддерживать уведомление роли администратора э(1) об истечении установленного срока времени, на которое гриф ограничения доступа э(63) был назначен классу э(11), делу э(34), разделу э(66) или тому э(74), и позволять переоценивать и корректировать метку ограничения доступа.	Д
Например, СУЭОД э(32) должна послать уведомление в «День рождения + х лет». Это может использоваться в медицинских официальных документах э(52) или в других целях для защиты информации.
СУЭОД э(32) обязательно должна автоматически регистрировать все изменения грифа ограничения доступа э(63) и значений подкатегорий в протоколе аудита э(4).	Д
СУЭОД э(32) никогда не должна разрешать пользователю э(68) применять гриф ограничения доступа э(63) по отношению к классу э(11), делу э(34), разделу э(66) или тому э(74), к которому у пользователя э(68)  нет доступа.	Д
Роль администратора э(1) обязательно должна быть способна изменять грифы ограничения доступа э(63) всех официальных документов э(52) и дочерних сущностей (в зависимости от конфигурированной опции в э10.13.1) в классe э(11), делe э(34), разделe э(66) или томe э(74) одним действием.	Д
Это часто требуется для снижения уровня защиты, установленного для официальных документов э(52), так как их конфиденциальность уменьшается со временем.
СУЭОД э(32) обязательно должна предупреждать роль администратора э(1), если грифы ограничения доступа э(63) каких-либо официальных документов э(52) были снижены, и ждать подтверждения для завершения операции.	Д
Это особенно важно, если гриф ограничения доступа э(63) агрегации э(3) снижен до более низкого уровня, чем гриф официальных документов э(52), хранящихся в ней.
СУЭОД э(32) обязательно должна автоматически записывать историю, например, даты и детали любых изменений грифа ограничения доступа э(63), в метаданных э(40) соответствующих классов э(11), дел э(34), разделов э(66), томов э(74) или официальных документов э(52).	Д
Для каждого произведенного изменения история может включать, например, дату, пользователя э(68), значения до и после изменения и причину.

НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Некоторые свойства успешного применения СУЭОД э(32) не могут быть определены в терминах функциональности. На практике нефункциональные требования также важны для успеха. Данная глава представляет все эти требования.