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

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

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

Любой факт обращения к официальному документу э(52) и все другие действия, затрагивающие его самого или связанные с ним официальные документы э(52) и данные, должны быть отражены в протоколе аудита э(4), чтобы гарантировать его юридическую значимость и помочь при восстановлении данных. Требования к протоколу аудита э(4) перечислены в разделе 4.2.; эти требования касаются, главным образом, характеристик аутентичности э(5) и целостности официального документа э(52), определенных в разделе 7.2 ISO 15489.

Защита официальных документов э(52) также включает средства сохранения данных при сбое системы посредством резервного копирования и возможность восстановления официальных документов э(52) из резервных копий. Эти требования изложены в разделе 4.3; эти требования относятся к особенностям удобства пользования официальными документами э(52), определенным  в разделе 7.2 ISO 15489.

Особо важные документы э(73) – это критически важные для жизнедеятельности организации официальные документы э(52), которые должны быть восстановлены немедленно в случае утраты. Требования к ним  рассматриваются в разделе 4.4.

Доступ

Организациям требуется контролировать доступ к их официальным документам э(52), и обычно это достигается путем определения и применения политики безопасности, а именно доступ к официальным документам э(52) делегируется в соответствии с ролью э(62) работника в организации. Управление пользователями э(68) обычно осуществляется централизованно, они одновременно получают доступ к нескольким корпоративным системам, включая СУЭОД э(32).

Нельзя принимать в качестве наилучшего варианта управление доступом в СУЭОД э(32) выдачу индивидуальных разрешений на индивидуальные сущности индивидуальным пользователям э(68). Права доступа обычно предоставляются  ролям э(62) и/или группам э(37), позволяя им сохранять и обращаться к официальным документам э(52) в установленных классах э(11)  или делах э(34) в пределах схемы классификации э(14).

Помимо предоставления права доступа к определенным частям схемы классификации э(14), разрешения ограничивают действия, которые пользователь э(68), роль э(62) или группа э(37) могут применять к сущностям в СУЭОД э(32), такие как инспектирование их метаданных э(40) или содержания, их изменение или уничтожение, а также создание или просмотр сущностей определенного типа.

Например, лицо, исполняющее роль пользователя э(71), может искать и читать официальные документы э(52), но организация практикующая ролевую э(62) политику информационной безопасности может ограничить поиск и чтение отдельных частей схемы классификации э(14).

Разрешения могут применяться к группам э(37) и могут быть унаследованы членами группы э(37). Применение их на групповом э(37) уровне, а не на уровне пользователя э(68), улучшает управление СУЭОД э(32) со временем, т. к. прибавляются новые пользователи э(68), а существующие пользователи э(68) меняются или уходят.

Хотя присвоение ролей э(62) в многочисленных разрешениях СУЭОД э(32) может быть обеспечено пользователю э(68) или группе э(37) автоматически, позже, когда пользователь э(68) или группа э(37)  удаляются из роли э(62), все разрешения автоматически аннулируются.

СУЭОД э(32) должна быть способной лимитировать установку этих прав доступа для определенных ролей э(62). В таблице 13.4 это показано по отношению к ролям администраторов э(1).

Заметим, однако, что роли администраторов э(1), с точки зрения системы, лишь исполняют, а политические решения принимает высшее руководство организации. Политика информационной безопасности и ее применение к индивидуальным конечным пользователям э(68) обычно основаны на деловых потребностях пользователей э(68) в доступе к информации, порядке работы с официальными документами э(52) в организации, на требованиях закона и других нормативных документов, таких как законодательство в области информации, защиты данных, архивного дела и отраслевых нормативных актах (см. раздел 11.5).

В некоторых условиях управление доступом в СУЭОД э(32) всецело осуществляется внутри СУЭОД э(32). В других случаях управление доступом осуществляется с использованием отдельного программного обеспечения, такого как утилита сетевой оперативной системы. Оба способа допустимы при соответствии  следующим требованиям.

Идентифицированные роли э(62) только «обозначены». Организация сама должна установить количество и поведение ролей э(62), которые она использует, если она вообще использует роли э(62), в соответствии с ее собственными потребностями.

№	Требование	Тест
СУЭОД э(32) не должна разрешать никаким лицам производить какие-либо действия в СУЭОД э(32) за исключением лиц, являющихся уполномоченными пользователями э(6), которые успешно идентифицированы, и чья подлинность личности аутентифицирована э(5) (удостоверена).	Д
MoReq2 не определяет характер механизма аутентификации э(5). Во многих ситуациях механизм использования идентификатора пользователя э(6) и пароля считается достаточным для  аутентификации э(5). Организациям, использующим MoReq2 для достижения результата, необходимо быть уверенными, что применяется достаточный уровень аутентификации э(5).
СУЭОД э(32) должна разрешать ролям администраторов э(1) назначать доступ к официальным документам э(52), разделам э(66), делам э(34), классам э(11) и метаданным э(40) указанным пользователям э(68) и/или ролям пользователей э(71) и/или группам пользователей э(69) на указанный период времени.	Д
СУЭОД э(32) не должна лимитировать число ролей э(62) или групп э(37), которые могут быть установлены.	В
СУЭОД э(32) должна разрешать ролям администраторов э(1) поддерживать разрешения для всех ролей э(62) и групп э(37). Они определяют функциональность, элементы метаданных э(40), официальные документы э(52) или дела э(34), к которым роли э(62) и группы э(37) имеют доступ, и разрешенные виды доступа.	Д
СУЭОД э(32) должна разрешать ролям администраторов э(1) использовать разрешения для: ограничения доступа к определенным делам э(34) или официальным документам э(52); ограничения доступа к определенным классам э(11) схемы классификации э(14); ограничения доступа пользователя э(68) в соответствии с его уровнем допуска э(64) (там, где применимо); ограничения доступа к отдельным особенностям или функциям (например, чтение, обновление и/или удаление указанных элементов метаданных э(40)); отказа доступа после определенной даты; разрешения доступа после определенной даты.	В
Разрешения должны использоваться для распределения прав доступа в соответствии с политикой информационной безопасности, принятой в организации.
Определение необходимого числа уровней доступа показано в разделе 13.4.
СУЭОД э(32) должна позволять конфигурировать доступ посредством интегрированного сетевого вхождения в систему.	Д
СУЭОД э(32) должна позволять ролям администраторов э(1) добавлять и удалять пользователей э(68) к ролям э(62) и группам э(37) (из ролей и групп) в любое время.	Д
Допустимо, чтобы роли администратора э(1) управляли группами э(37) с помощью отдельного программного обеспечения для управления директорией.
СУЭОД э(32) должна разрешать назначение прав администрирования различных разделов схемы классификации э(14) различным ролям администраторов э(1).	Д
Пример  модели управления доступом см. в разделе 13.4.
СУЭОД э(32) должна разрешать ролям администраторов э(1) помечать индивидуального пользователя э(68) как неактивного, без удаления пользователя э(68) из системы.	Д
Допустимо, чтобы роли администраторов э(1) управляли пользователями э(68) с помощью отдельного программного обеспечения для управления директорией.
СУЭОД э(32) должна разрешать ролям администраторов э(1) определять ролям пользователей э(71) те же права доступа, что и пользователям э(68).	Д
Эта возможность позволяет ролям администраторов э(1) управлять и обслуживать ограниченное число конфигураций прав доступа для ролей э(62) вместо настройки прав для большого числа отдельных пользователей э(68). Примерами могут быть Менеджер, Регистратор, Специалист по безопасности, Администратор э(2) базы данных.
СУЭОД э(32) должна быть в состоянии применить наборы требований доступа через роли э(62).	Д
Для примеров см. раздел 13.4.
СУЭОД э(32) должна разрешать роли администратора э(1) устанавливать и обслуживать группы э(37) из пользователей э(68).	Д
Примерами групп э(37) могут быть Персонал, Северная группа продаж.
СУЭОД э(32) должна позволять пользователю э(68) быть членом одной группы э(37), нескольких групп э(37) или быть вне групп э(37).	Д
Возможно, что у некоторых пользователей э(68)  будут разные требования доступа для разных частей схемы классификации э(14). Во всех классах пользователи э(68) относятся ролями администраторов э(1) к группам э(37) в соответствии с производственной необходимостью и политикой.
СУЭОД э(32) должна разрешать ролям администраторов э(1) составлять специальные списки индивидуальных пользователей э(68) с целью контроля доступа к определенным частям схемы классификации э(14) или  официальным документам э(52).	Д
СУЭОД э(32) должна разрешать выполнение системных функций и связанных с ними действий только ролям администраторов э(1).	Д
Это необходимо с целью защиты авторитарности электронных официальных документов э(31).
СУЭОД э(32) должна разрешать только ролям администраторов э(1) устанавливать  профиль пользователя э(70) и относить пользователей э(68) к группам э(37) и ролям э(62).	Д
См. также раздел 13.4
СУЭОД э(32) должна разрешать ролям э(62) с правом владения официальными документами э(52) определять, какие еще пользователи э(68) или группы э(37) могут иметь доступ к этим официальным документам э(52).	Д
См. глоссарий MoReq2 об использовании термина «владелец э(44)». Если регламент работы организации позволяет, владельцем может являться лицо, выполняющее роль администратора э(1).
СУЭОД э(32) должна разрешать производить изменения, такие как добавление, приложение и уничтожение профилей э(51) групп э(37), ролей э(62) или пользователей э(68) только лицам, выполняющим роль администратора э(1).	Д
Это включает такие атрибуты, как права доступа, привилегии, установление пароля и управление.
СУЭОД э(32) должна разрешать ролям администраторов э(1) устанавливать и применять правила по управлению доступа пользователей э(68) к функциям СУЭОД э(32), с тем, чтобы разные роли э(62) имели доступ к разным комбинациям функций. СУЭОД э(32) должна разрешать устанавливать такие правила с минимальным уровнем градуирования (т. е. число разбивки), показанным в иллюстрации прав доступа в таблице раздела 13.4.	Д
В различных организациях существуют различные требования контроля функционального доступа. Таким образом, было бы неправильным пытаться определить общую для всех модель. Соответственно вместо этого  данное  требование определяет  уровень контроля, который должна  предлагать СУЭОД э(32).
СУЭОД э(32) должна разрешать ролям администраторов э(1) создать роли э(62) в дополнение к показанным в разделе 13.4.	Д
Организация может определять роли э(62) с определенными правами доступа, такие как исполнитель э(10),  менеджер и т. п.
СУЭОД э(32) должна обеспечивать применение интерфейса прикладного программирования (API) для обеспечения доступа к официальным документам э(52) по инициативе другой прикладной системы.	Н
Если пользователь э(68) производит поиск, который включает поиск содержания (обычно, но не обязательно, поиск полного текста или поиск свободного текста), СУЭОД э(32) не должна включать в список результатов поиска никакие официальные документы э(52), к которым пользователь э(68) не имеет права доступа.	Д
Это требование необходимо для предотвращения возможности поиска пользователями э(68) текста с целью исследования содержания документов э(26), к которым у них нет разрешения на доступ.
Если пользователь э(68) запрашивает доступ, просматривает или ищет без поиска содержания, любой предмет, на который у него нет права доступа, как то:  официальный документ э(52), том э(74), раздел э(66), дело э(34) или класс э(11), то в подобных случаях СУЭОД э(32) должна обеспечить один из следующих ответов (в зависимости от настройки на этапе конфигурации э(20) или позже): не предоставлять никакой информации о предмете, таким образом, не давать ответа, существует предмет или нет; подтвердить существование и (по выбору) владельца э(44) предмета показать идентификатор его дела э(34) или официального документа э(52), но не его заголовок или другие метаданные э(40); отобразить только заголовок, тип сущности (класс э(11), официальный документ э(52)  и т. д.), дату создания и владельца э(44); отобразить заголовок и другие метаданные э(40) объекта.	Д
Выбор в первом ответе требования определяет такой же результат, как и в случае поиска содержания (см. 4.1.22). Три остальных выбора намеренно предлагают другие возможности, применимые в некоторых организациях; они показаны здесь в порядке снижения требований к доступу. Они должна быть конфигурированы ролями администраторов э(1).
Это требование применяется только к попыткам доступа, которые не включают в себя поиск содержания официального документа э(52). Поиск содержания официального документа э(52) рассматривается в разделе 4.1.22, с которым следует соотносить данное требование.
СУЭОД э(32) не должна разрешать, чтобы ответы, указанные в 4.1.23 и избираемые  для класса э(11) в качестве альтернативы, являлись параметрам всей системы на этапе конфигурации э(20)  или позже.	Д

Протокол аудита

Протокол аудита э(4) – это официальный документ э(52), в который записываются все действия, происходящие в СУЭОД э(32). Это: действия пользователей э(68) или ролей администраторов э(1), а также действия, выполнение которых инициировано СУЭОД э(32) вследствие заданных системных параметров. См. формальное определение в Глоссарии (раздел 13.1).