Если вы используете SharePoint 2007 как инструмент для совместной работы, у вас, вероятно, есть некоторые проблемы с управлением разрешениями. Если же было выполнено обновление с Windows SharePoint Services (WSS) 2.0 или SharePoint Portal Server 2003, то у вас подобных проблем больше. Практически каждая организация должна убирать наследование разрешений на уровне сайта для того, чтобы воспользоваться преимуществами функций системы безопасности SharePoint. Когда вы убираете наследование разрешений в SharePoint, вы увеличиваете гибкость, но часто это происходит за счет управляемости. При написании данной статьи я преследовал две цели. Во-первых, мне хотелось пролить свет на то, как проблема может проявляться, и дать несколько рекомендаций относительно того, как уменьшить последствия. Во-вторых, я планировал рассказать, к какому решению пришли мы в своей компании, для того чтобы вновь вернуть управление разрешениями. Также я хочу дать несколько советов для периодического отслеживания текущего статуса разрешений.

.

Как работают разрешения

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

Базовые разрешения. На уровне корневого каталога серии базовых разрешений дают определенные права, а набор таких прав составляет уровень разрешений. Эти жестко закодированные, изначальные базовые разрешения, которые не могут быть добавлены, представляют собой строительные блоки для назначения прав пользователям и группам. Эти разрешения показаны на экранах 1, 2 и 3. Администраторы SharePoint до некоторой степени могут контролировать использование этих базовых разрешений. Например, уровень разрешений Full Control — это распространенная роль, которая включает потенциальные опасности, такие как базовое разрешение Manage Permissions. Manage Permissions дает пользователям право создавать собственные пользовательские уровни разрешений.

 

Экран 1. Личные разрешения

 

Экран 2. Список разрешений

 

Экран 3. Разрешения сайта

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

 

Экран 4. Уровни разрешений

Назначение разрешения. Когда группам, пользователям и группам Active Directory назначаются разрешения или они используются в SharePoint, им должен быть задан уровень разрешения в коллекции сайта. Вы назначаете права на доступ к контенту в SharePoint, указывая один или несколько уровней разрешений пользователям или группам. Например, на экране 5 показаны группы пользователей с несколькими назначенными уровнями разрешений.

 

Экран 5. Назначение разрешения

Наследование. Приведенная информация о разрешениях может показаться простой, но есть два важных момента. Первый — это наследование. SharePoint не будет полезным, если у всех сайтов и контента будут одни и те же уровни разрешений. По умолчанию все сайты и контент наследуют разрешения от старшего сайта — из корневого веб-каталога в коллекции сайта. SharePoint предоставлет механизмы изменения этого наследования на одном или на всех сайтах и добавления своих разрешений. В общем виде эта способность состоит в удалении определенных групп или добавлении других. Эти группы именуют подходящим образом согласно уровню доступных им разрешений на соответствующем сайте. Если у вас много сайтов, этот процесс может породить большое количество групп SharePoint. Если вы не собираетесь использовать эти группы, нужно назначить права отдельным пользователям или группам Active Directory, которые также могут создавать дополнительные затруднения.

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

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

В чем проблема?

Поскольку управление разрешениями — процесс очень гибкий, вы часто будете сталкиваться с непреднамеренным некорректным использованием назначения разрешений в SharePoint. В WSS 2.0 и SharePoint Portal Server 2003 не существовало такого разнообразия уровней разрешений, как в SharePoint 2007. Поэтому фермы SharePoint, которые прошли через обновление с выполнением назначений уникальных разрешений, являются очень запутанными в отношении разрешений. Все разрешения автоматически накапливаются и группируются на новых уровнях разрешений во время обновления. Но имя «уровня разрешений» является генерируемым, особенно это касается разрешений с непонятными именами. Уровни разрешений создаются на индивидуальном уровне подузла, что затрудняет их поиск.

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

Есть один важный вопрос: вы знаете состояние своей среды SharePoint? Конечно, этот вопрос связан и с рядом других: как много пользователей имеют право Manage Permissions? Сколько списков и элементов списков в вашей ферме имеют уникальные разрешения? Как много существует отдельных групп SharePoint? В каких местах отменено наследование и на каком уровне — на сайте, в списке или в элементе списка? Как много уровней разрешений было создано без вашего ведома с дублированными именами, но не с дублированными правами? Либо другой вариант: с дублированными правами, но без дублированных имен? Как вы собираетесь отслеживать все эти процессы?

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

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

Какое выбрать решение?

Проблемы, которые я описал, имеют различные уровни сложности для организаций разных типов. Чтобы справиться с ними в своей среде, я написал небольшое приложение для определения базовых данных, анализа статуса разрешений и создания системы для корректировки разрешений. Хотя приложения сторонних компаний могут справиться с просмотром, копированием и управлением разрешениями, я решил написать собственное приложение, поскольку ни одно из имеющихся приложений не было таким, каким я хотел бы его видеть. Мое приложение — не предмет для обсуждения в данной статье, но опыт развертывания SharePoint пригодится, если вы тоже решите написать свое приложение. Я надеюсь, что мой опыт и догадки заставят вас принять меры к тому, чтобы избежать проблем с разрешениями. Далее я описываю то, что выяснила моя команда.

  1. Уровни. Первое, что мы сделали, это взяли под контроль все уровни разрешений в нашей большой коллекции сайтов SharePoint. У нашей команды была идея свести все права к 6 или 8. Так мы могли бы их поименовать, описать и распределить по подсайтам. Как я уже говорил, подсайты, которые не только изменяли наследование, но и редактировали уровни разрешений, способствуют возникновению дополнительной проблемы: уровни разрешений больше не будут совместно использоваться сайтами. Это вызвано тем, что пользователям доступно базовое право Manager Permissions.
  2. Объединение в группы. Объединив уровни разрешений в управляемое количество наборов и заставив все подсайты использовать их, мы хотели исключить назначение прав индивидуальным пользователям и назначение одному пользователю разных прав. Цель состояла в том, чтобы только группы SharePoint получали разрешения, а всех пользователей можно было просто добавлять к различным группам. Это огромная работа, если выполнять ее вручную.
  3. Гарантия правильного доступа. Одна из проблем при объединении пользователей в группы и ликвидации большинства уровней разрешений состоит в том, что нам нужно либо дать дополнительные разрешения, либо забрать некоторые имеющиеся у пользователей. Проблема неизбежна, но существует логический метод ее обхода. Наш подход состоял в использовании данных, которые мы собрали для того, чтобы просмотреть все уникальные разрешения, назначенные во всей коллекции сайтов, а затем урезать назначенные разрешения до базовых. Такой маневр облегчило использование матрицы из 10–15 уровней разрешений, которые должны были стать одним уровнем. На экране 6 показана часть крупноформатной таблицы, использованной для создания этой матрицы.

 

Экран 6. Создание матрицы

Как можно заметить, большинство разрешений похожи, поэтому их легко разделить по уровням. Мы смогли просмотреть 11 уникальных наборов прав и убедиться, что они предназначены для права Read. Дополнительным преимуществом права Read является согласованность: мы убедились, что все базовые разрешения, назначенные этому уровню, были стандартными для всех сайтов.

После вычленения всех уникальных прав мы смогли классифицировать их. Однако были нестандартные уровни, которые нужно было принять во внимание. Это дополнительные права для просмотра, предназначенные для ограничения возможности удалять или редактировать элементы, и некоторые административные права для ограничения возможности управлять разрешениями и создавать подсайты. Сведя уровни разрешений к определенным правам с соответствующим их именованием, мы упрощаем просмотр разрешений сайта. Например, группе SharePoint могут быть назначены такие уровни: Site Owner (владелец сайта), Manage Permissions (разрешение на управление) и Create Sub-site (создание подсайта). Мы были очень внимательны, назначая права Manage Permissions.

Как мы это сделали?

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

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

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

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

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

Несколько слов на будущее

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

Райан Томас (rthomas@syrinx.com) — директор департамента SharePoint Practice в Syrinx Consulting. Имеет сертификаты Microsoft Certified Professional Developer и Microsoft Certified Application Developer