Список управления доступом к базе (ACL)
Каждая база Notes имеет список управления доступом (Access Control List, ACL), определяющий, какие пользователи, группы пользователей, и серверы могут иметь к ней доступ и какие задачи в этой базе они могут исполнять.
ACL включает две компоненты:
· список элементов ACL, каждый из которых содержит имя субъекта (пользователя, сервера или группы), его уровень доступа к базе и дополнительные свойства;
· список ролей вместе с назначением субъектов на роли.
Список управления доступом создается при создании базы и далее ведется менеджером базы данных в диалоговом окне, получаемом из меню File - Database - Access control....
Если имя пользователя или сервера не внесено в ACL базы данных явно или как члена группы, считается, что он - -Default-.
В Notes используется семь уровней доступа.
(Менеджер) может выполнять все возможные действия в базе данных - чтение, запись, редактирование документов, создание, модификация и удаление элементов дизайна (форм, видов, агентов…). Менеджер, в отличие от более низких уровней доступа, может также изменять ACL, настройки репликаций, установки локального шифрования базы и удалять базу данных. База данных всегда имеет по крайней мере одного менеджера.
Рис. 9.6. Список управления доступом - закладка Basics
(Дизайнер), в отличие от более низких уровней доступа, может создавать, модифицировать и удалять элементы дизайна (поля, формы, виды, общих агентов…), модифицировать репликационные формулы базы, создавать индекс полнотекстового поиска. И, конечно, выполнять те же самые действия, что и субъекты с более низким уровнем доступа
(Редактор) может читать, создавать и редактировать все документы в базе данных (в том числе и созданные другими пользователями), но не может изменить элементы дизайна, ACL и прочие атрибуты, присущие более высоким уровням доступа.
(Автор) может читать существующие документы и создать новые, но может редактировать только созданные им документы (но не другими).
(Читатель) может читать документы, но не может добавлять новые или редактировать существующие.
(Депозитор) может добавлять новые документы, но не может читать существующие, потому что попросту "не видит" их в видах базы.
No Access (Нет доступа). Пользователь не может открыть базу данных.
Кроме того, для каждого уровня доступа имеется свой собственный набор дополнительных флагов, уточняющих возможности на уровне. Ниже приведены все возможные флаги, но без учета уровня доступа, для которого они имеют смысл:
· Create documents - может создавать документы;
· Delete documents - может удалять документы;
· Create personal agents - может создавать личных агентов;
· Create personal folders/views - может создавать личные виды и папки;
· Create shared folders/views - может создавать общие виды и папки;
· Create LotusScript Agents - может создавать агентов на LotusScript;
· Read public documents - может читать общедоступные документы;
· Write public documents - может создавать общедоступные документы.
Из большого количества связанных с доступом комбинаций обратим ваше внимание на два момента. Во-первых, менеджер может "разрешить" читателю создавать личных агентов. А читатель может создать агента, который удаляет все документы в базе. Читатель может даже запустить этого агента. Но агент не сможет удалить документы в базе, поскольку "его читательского доступа" недостаточно для выполнения этой операции. Во-вторых, начиная с версии 4.5 даже пользователь с уровнем доступа No Access может быть "наделен возможностью" читать и (или) создавать в базе данных т.н. общедоступные документы. Чтобы эта возможность функционировала, разработчик базы должен создать в ней одну или несколько форм со свойством Available to Public Access users и полем (обычно, "невидимым") с предопределенным именем $PublicAccess типа Text и значением "1". Кроме того, обычно создаются и виды или папки, имеющие свойство Available to Public Access users, и содержащие общедоступные документы.
Группы - списки пользователей, серверов или других групп, создаваемые администратором в общей адресной книге. При использовании групп действуют следующие соглашения:
· если пользователь фигурирует в ACL и как член группы, и как физическое лицо, он получает права доступа физического лица, даже если права группы предоставляют ему больший уровень доступа;
· если пользователь - член двух групп в ACL - он получает права доступа группы с большим уровнем доступа.
Роли доступа используются для управления доступом пользователей или групп к определенным формам, видам или агентам в базе данных.
Рис. 9.7. Список управления доступом - закладка Roles
Дизайнер может предусмотреть при создании некоторых форм, видов или агентов, что доступ к ним должны иметь только те лица, которых впоследствии менеджер базы назначит на эту роль, а не все имеющие необходимый уровень доступа в ACL. Дизайнер (обычно при разработке базы он имеет и права менеджера) добавляет названия ролей в ACL базы. Например, [FormReadAccess] (к сожалению, название роли не "длиннее" 15 символов). Затем он использует эти названия ролей при определении доступа к некоторым формам или видам. При разработке агентов на LotusScript соответствующая проверка, назначен или нет запустивший агента пользователь на роль, выполняется в самом агенте. Если пользователь не назначен на роль, агент попросту не выполняет своего действия.
Менеджер базы впоследствии назначает (на закладке Basics щелчком мыши по названию роли при "выбранном" субъекте) на эту роль пользователей базы из числа имеющихся в ACL. Выполняемые менеджером изменения в списках назначенных на роль не требуют изменения доступа в использующих эту роль формах, видах и агентах. Только назначенные на роль смогут воспользоваться использующими роли формами, видами и агентами - простого присутствия в ACL недостаточно.
На закладке Log содержится информация о том, кто, когда и что изменял в ACL базы.
Рис. 9.8 Список управления доступом - закладка Log
На последней закладке, во-первых, можно задать для базы сервер администрирования и уточнить, должна ли серверная задача Administration Process вносить изменения в поля типа Readers и Authors при операциях изменения имен или удаления пользователей. Однако это уже рассматривалось в 3.2.14.
Во-вторых, менеджер базы данных может обеспечить, чтобы список управления доступа (ACL) оставался тем же самым во всех репликах базы. Для этого менеджер на закладке Advanced выбирает опцию Enforce a consistent Access Control List across all replica copies of this database ("предписать непротиворечивый список управления доступом во всех репликах этой базы данных"). Выбор этой опции не только гарантирует, что ACL будет оставаться одинаковой во всех репликах базы на серверах, но и то, что ACL будет оставаться одинаковой и будет функционировать в репликах на станциях пользователей. Если же эта опция не выбрана, пользователи имеют доступ менеджера к своим локальным репликам, а следовательно, могут менять их ACL, даже если в реплике на сервере они не имеют такого уровня доступа, хотя такие локальные изменения в ACL не поступают в реплику на сервере.
Рис. 9.9 Список управления доступом - закладка Advanced
Поддержка ACL в репликах на станциях тем не менее не является настоящим средством защиты, если вы физически не гарантируете безопасность станции или не применяете локального шифрования. Во-первых, зная имя группы, использованное в ACL, всегда можно создать группу с таким именем и включить в ее состав пользователя, которому необходим доступ. Во-вторых, зная полное имя пользователя, фигурирующего в ACL, можно создать новый ID-файл с таким именем (но, конечно, другими ключами) и получить "под ним" доступ к базе. Кроме того, серверные add-in - программы могут "обходить" список управления доступа, предписанный для локальных реплик.
Чтобы обеспечить распространение репликационных установок во все реплики базы на других серверах, следует выбрать данную опцию в реплике на том сервере, который имеет доступ менеджера во всех других серверных репликах, иначе репликация будет неудачной - сервер не сможет изменить ACL в репликах базы на других серверах. В сообщениях о неудаче репликации по этой причине вы встретите слова "inconsistent ACL".
В-третьих, в Notes версий 4. 5 появилась возможность указать максимальный уровень доступа к этой базе с использованием Web-броузера. На сервере Notes такой доступ поддерживает серверная задача HTTP, рассматриваемая в 10.2.
В-четвертых, кнопка Look Up User Types for "Unspecified" Users обеспечивает проверку фигурирующих в ACL имен по адресной книге и конкретизацию их типа: Person, Server, Person Group, Server Group, Mixed Group. Нажмите кнопку и вернитесь на первую закладку - в типах имен могут произойти изменения. Для чего это необходимо? Например, администратор сервера может запустить на сервере станцию Notes и работать под ID сервера с базой, если в ACL для имени сервера задан тип Unspecified. Но он не сможет этого сделать, если в ACL для имени сервера задан тип Server.
Как выяснить, чем определяется доступ пользователя к базе данных
Чтобы выяснить, что именно (например, какая группа) определяет уровень доступа пользователя к базе данных, "нажмите мышью" пиктограмму уровня доступа в строке состояния в нижней части окна рабочей области.
Рис. 9.10 К этой базе пользователь Nikolay N. Iontsev/InterTrustCorp/SU получает доступ менеджера как член группы Administrators
В появившемся диалоговом окне содержатся:
· все группы из адресной книги, членом которых является пользователь;
· шаблоны имен, которым удовлетворяет имя пользователя;
· роли, на которые пользователь назначен (они заключены в скобки []).
Галочкой отмечены те имена, на основании которых станция "принимает решение" о предоставлении пользователю его уровня доступа.
Такая возможность работает для баз на серверах и локальных баз, для которых выбрана опция Enforce a consistent Access Control List across all replicas of this database.
