Устранение распространенных неполадок детальных разрешений для SharePoint Server

Статья
05/31/2024

ОБЛАСТЬ ПРИМЕНЕНИЯ: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint в Microsoft 365

После внедрения детальных разрешений в среде SharePoint могут возникнуть проблемы с безопасностью или производительностью. Следующие сведения помогут вам устранить проблемы, которые могут быть связаны с детальными разрешениями.

Рекомендуемые способы устранения распространенных проблем с производительностью детальных разрешений

Следующие решения помогут сократить влияние проблем с производительностью, связанных с интенсивным использованием детальных разрешений. Каждое из перечисленных ниже решений охватывает изменения в системе безопасности среды, иерархии объектов или пользовательском коде, которые приводят к проблемам с производительностью, связанным с детальными разрешениями. Каждая проблема начинается со следующего примера среды, в которой один веб-сайт содержит несколько библиотек документов, каждая из которых содержит множество уникальных дочерних объектов с уникальными разрешениями.

Показан одиночный веб-сервер с несколькими библиотеками документов, каждая из которых содержит большое число дочерних объектов с уникальными разрешениями.

Решение 1. Удаление детальных разрешений и использование улучшений системы безопасности только на уровне веб-сервера

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

Очистка системы безопасности среды

При удалении пользователя из области на уровне веб-сервера внутренней объектной модели необходимо удалить пользователя из каждой области, расположенной под уровнем веб-сервера. Удаление отдельных пользователей для очистки существующих разрешений занимает много времени. Вместо этого сначала удалите каждую уникальную область на уровне элемента, чтобы элемент наследовал разрешения от родительского объекта. Это займет меньше времени, чем удаление пользователей, так как действия выполняются только над одной областью для элемента.

Важно!

Если текущий веб-сайт не является корневым для семейства веб-сайтов, а также если для него настроено наследование разрешений от родительского веб-сайта, будут удалены все его уникальные области, а данные членства, предусматривающие ограниченный доступ, будут перезаписаны в рамках одного кругового пути SQL Server.

Показана очистка разрешений путем удаления пользователя из области действия на уровне веб-сервера. При выполнении этой операции внутренняя объектная модель должна удалить пользователя из каждой области действия ниже уровня веб-сервера.

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

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

Изменение архитектуры безопасности среды

После удаления существующих детальных разрешений и областей следует придерживаться долгосрочного плана проектирования архитектуры для поддержки уникальной области только на уровне веб-сервера. На следующей схеме показано, как спроектировать архитектуру таким образом, чтобы сохранить только область на уровне веб-сервера. Основное требование в архитектуре заключается в том, чтобы не было слишком много элементов на одном уровне иерархии в библиотеках документов, так как время, необходимое для обработки элементов в представлениях, увеличивается.

Решение:

Максимальное число элементов и папок на любом уровне иерархии должно составлять примерно 2000 элементов.

Показана архитектура, определяющая структуру области действия на уровне веб-сервера.

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

Решение 2. Использование детальных разрешений путем внесения изменений в иерархическую структуру

Изменение иерархии среды

На следующей схеме физическая архитектура была изменена, чтобы каждая библиотека документов находилась в интернете с уникальными разрешениями. Кроме того, если необходимо сохранить детализированные разрешения на уровне элемента, рекомендуется, что совокупное число субъектов безопасности, которым будет предоставлен доступ, должно быть ограничено примерно 2000, хотя это не является фиксированным ограничением. Таким образом, эффективное членство каждого веб-сервера, включающего всех участников с ограниченным доступом, не должно превышать примерно 2000 пользователей. Это предотвращает разрастание каждой из областей на уровне веб-сервера.

Показана библиотека документов на веб-сервере с уникальными разрешениями. Число членов на каждом веб-сервере не должно превышать 2000 пользователей.

Количество уникальных дочерних элементов не является серьезной проблемой и может масштабироваться до большого числа. Тем не менее ограничительным фактором станет количество субъектов, которые будут добавлены в качестве пользователей с ограниченным доступом вверх по цепочке областей к первому веб-серверу с уникальными разрешениями.

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

Решение 3. Использование детальных разрешений путем внесения изменений в структуру областей

Чтобы перепроектировать среду так, чтобы она по-прежнему использовала детализированные разрешения, но без слишком большого количества обновлений или изменения размера одной области веб-сайта, рассмотрите возможность использования другого процесса защиты элементов. Это применимо, если причиной большого количества уникальных областей был автоматизированный процесс, например обработчик событий или рабочий процесс, динамически изменяющий разрешения объекта. В этом случае рекомендуется изменить код процесса, который отвечает за создание уникальных областей безопасности.

Динамическое изменение кода безопасности

На следующей схеме архитектура области была изменена, чтобы членство в области не приводило к повторному пересчету списка ACL в родительской библиотеке документов и в Интернете. Как указывалось ранее, веб-сервер, который включает всех участников с ограниченным доступом, не должен насчитывать более чем примерно 2000 активных участников для предотвращения разрастания области на уровне веб-сервера. В этом случае, реализуя новую группу SharePoint, в которую будут входить все участники, которые должны иметь права ограниченного доступа, область не будет увеличиваться слишком большой. Когда пользователи добавляются в отдельные области на уровне веб-сайта с помощью метода SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly , они также могут быть добавлены с помощью дополнительного кода в новую группу, которая была установлена как с ограниченным доступом на уровне веб-библиотеки и библиотеки документов.

Показано членство в области действия, которое не приводит к перерасчету списка ACL в родительской библиотеке документов и на родительском веб-сервере.

Решение:

Если необходимо сохранить детализированные разрешения на уровне элементов, совокупное число субъектов безопасности, которым будет предоставлен доступ, должно быть ограничено примерно 2000, хотя это не является фиксированным ограничением. При увеличении числа субъектов безопасности для пересчета двоичного списка ACL требуется больше времени. Двоичный список ACL необходимо пересчитать в случае изменения членства в области. Добавление пользователей в уникальную области с дочерними элементами приведет к добавлению в родительские области новые участников с ограниченным доступом, даже если это в итоге никак не повлияет членство родительской области. В таком случае необходимо также пересчитать двоичный список ACL для родительских областей.

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

Поделиться через