Устранение пробелов в системе безопасности на уровне элементов
Популярность Microsoft SharePoint Portal Server 2003 и Windows SharePoint Services 2.0 растет, и многие администраторы Exchange Server проектируют и внедряют системы на основе одного или обоих продуктов SharePoint. Компания Microsoft и другие широко рекламировали достоинства SharePoint Portal Server и Windows SharePoint Services. Однако цель данной статьи — рассказать о слабых местах этих продуктов, в частности о недостаточной защите на уровне элементов, и предложить возможные решения. Термин SharePoint здесь относится как к SharePoint Portal Server 2003, так и к Windows SharePoint Services 2.0.
Суть проблемы
Защита SharePoint представляет собой комбинацию различных мер безопасности на уровне как портала (через SharePoint Portal Server), так и сайта (через Windows SharePoint Services). Но SharePoint не хватает возможности устанавливать специальные разрешения для отдельных фрагментов контента. В документации и пользовательском интерфейсе продукта можно встретить упоминания о защите на уровне элементов, которая применима к списку SharePoint Portal Server, хотя и примитивна: в сущности, пользователь с правами Administrator может управлять разрешениями других пользователей для чтения и редактирования элементов списка. На экране 1 показан раздел Item-level Permissions экрана Properties элемента списка. SharePoint не располагает функциями для управления разрешениями, назначенными одиночному элементу списка или фрагменту информации. Прежде чем рассмотреть пробел в системе безопасности на уровне элементов и возможные пути его устранения, важно понять общую архитектуру безопасности SharePoint и различия в безопасности SharePoint Portal Server и Windows SharePoint Services.
|
| Экран 1. Разрешения уровня элементов SharePoint Portal Server |
Роли. В состав SharePoint входит объект, именуемый группой сайтов (site group) или ролью. Роль содержит набор полномочий, которые совместно обеспечивают полезную функцию SharePoint. Увидеть роли SharePoint можно через графический интерфейс, но более очевидный способ получить список всех стандартных ролей SharePoint — воспользоваться административным инструментом stsadm.exe. Например, чтобы перечислить все роли, определенные в портале с именем portal01, следует ввести команду
stsadm -o enumroles -url http://portal01
Как видно из результатов выполнения этой команды (экран 2), две стандартные роли SharePoint — Contributor и Web Designer. Роль Contributor может добавлять контент в библиотеки документов и списки; Web Designer имеет право изменять внешний вид и поведение области SharePoint Portal Server и сайта Windows SharePoint Services. Нельзя изменить права стандартных ролей Guest и Administrator или удалить эти роли. Администратор может настроить права других стандартных ролей, но мы рекомендуем создать новые роли и изменять их при необходимости. Таким образом, будут сохранены стандартные права, назначаемые готовым ролям, которые можно использовать в качестве шаблонов при определении новых ролей.
Чтобы обеспечить функциональность роли, ей назначаются пользовательские учетные записи или группы. Когда в иерархии SharePoint назначается роль, пользователю предоставляется право на выполнение заданий, связанных с этой ролью. Если экземпляр SharePoint не входит в домен Active Directory (AD), то учетные записи пользователей и групп должны быть определены в компьютере, в котором выполняется SharePoint. Если сервер SharePoint или Web-ферма SharePoint является частью домена, то можно связать с ролями учетные записи локальных пользователей и групп либо учетные записи пользователей и групп AD. Разрешения SharePoint можно назначать непосредственно группам или пользователям, но компания Microsoft рекомендует назначать группы ролям и добавлять пользователей в эти группы.
Применение мер безопасности. Уяснив связь между ролями, пользователями и группами, можно уже разобраться в методах применения мер безопасности в SharePoint. В таблице перечислены и описаны все элементы SharePoint (поверхность безопасности), к которым можно применить меры безопасности. Полные описания этих элементов приведены в документе «Windows SharePoint Services Administrator?s Guide» по адресу http://tinyurl.com/3hnup. Документ SharePoint Portal Server Administrator?s Guide можно найти в программной группе SharePoint Portal Server меню All Programs. На каждой поверхности безопасности можно назначить роли учетную запись группы или пользователя. Чтобы упростить дальнейшее изложение, учетные записи групп и пользователей в данном контексте будут именоваться субъектами безопасности.
При назначении субъекту безопасности роли на поверхности безопасности SharePoint, которая имеет дочерние элементы, потомок наследует параметры безопасности родителя. Например, подобласть SharePoint Portal Server наследует разрешения родительской области. В Windows SharePoint Services подсайт, рабочее пространство и список наследуют разрешения своего родителя. Наследование проходит по всей иерархии, если не блокировать его явным назначением субъектов безопасности для поверхности безопасности.
Но в этой структуре не все логично: роли субъектам безопасности назначаются на самом верху иерархии SharePoint Portal Server, а затем назначенные роли передаются вниз всем подобластям порталов, для которых наследование разрешено и не блокировано явными разрешениями, назначенными родителю подобласти. В Windows SharePoint Services роли создаются в коллекции сайтов из экрана Top-Level Site Administration Manage Site Groups. После того как роли созданы, они могут наследоваться по иерархии коллекции сайтов. Но в Windows SharePoint Services роли субъектам безопасности можно явно назначать в любом месте иерархии. В SharePoint Portal Server разрешено только наследование ролей.
Такое несоответствие в настройке ролей между SharePoint Portal Server и Windows SharePoint Services не является уязвимым местом само по себе, но в результате при необходимости добавить роль в SharePoint Portal Server и использовать эту роль где-нибудь в иерархии SharePoint Portal Server требуется активизировать наследование в подобласти, чтобы роль могла появиться в этой области. Можно явно назначить субъект безопасности в области SharePoint Portal Server, указав набор разрешений. Такой метод может быть удобным, но управлять им сложнее, чем наследованием, так как он ведет к усложнению конфигурации системы безопасности.
Главные различия в архитектуре безопасности между SharePoint Portal Server и Windows SharePoint Services заключаются в том, где и как применяются меры защиты. SharePoint обеспечивает явное применение мер безопасности на базе роли, группы и пользователя для областей SharePoint Portal Server, сайтов Windows SharePoint Services и списков Windows SharePoint Services, но ни один продукт на обеспечивает единообразного подхода к безопасности на уровне элемента.
Новый взгляд на вещи
Может показаться, что существует лишь два способа защиты на уровне элемента: приложить значительные усилия для программирования расширений SharePoint или интегрировать продукт независимой компании, обеспечивающий нужный уровень функциональности. Однако самый простой и наименее дорогостоящий подход — по-новому взглянуть на природу элемента SharePoint и его безопасность.
Элемент SharePoint — больше чем фрагмент контента, это также метаданные (например, имя автора, указатель категории), присоединенные к элементу, и его страница, и компоненты Web Part, окружающие элемент. Например, в рабочем пространстве документа может быть указан членский Web Part, в котором перечислены пользователи рабочего пространства, участвующие в совместной работе над документом. Крупномасштабный взгляд на контент требует аккуратного подхода к выстраиванию информационной архитектуры предприятия. Структура областей SharePoint Portal Server должна быть такой, чтобы контент с одинаковыми разрешениями доступа располагался в одной области. Следует построить иерархию областей безопасности, в которой требования к разрешениям становятся более строгими по мере перемещения вглубь иерархии. Например, объявления для всех сотрудников компании следует поместить в области, доступной для всего персонала. Ниже этой области нужно создать подобласть с данными о трудовых ресурсах, доступ к которой имеют сотрудники отдела кадров; еще ниже следует организовать другую подобласть с конфиденциальными кадровыми данными, доступную не всем сотрудникам отдела кадров. Для более детального управления необходимо настроить разрешения для списков Windows SharePoint Services и библиотек документов. Область и список или библиотеку документов можно рассматривать как аналог папки файловой системы с разрешениями, назначенными для защиты контента.
Чтобы защищенный контент Windows SharePoint Services появился в SharePoint Portal Server, следует использовать списки портала; ограничить круг получателей списков контента можно, выделив целевую аудиторию. Аудитория (audience) — именованное правило или набор правил на базе атрибутов AD (например, членства в группе) либо атрибутов профиля SharePoint Portal Server (которые могут соответствовать или не соответствовать атрибутам AD). Выделяя целевую аудиторию, можно ограничить круг лиц, которые могут просмотреть список, предоставив аудитории разрешения для просмотра. Выделяя целевую аудиторию, можно также ограничить число пользователей, которым разрешено видеть компонент Web Part. Выделение целевой аудитории не относится к числу мер управления доступом. Скорее этот прием затрудняет поиск списка или компонента Web Part для пользователей, не входящих в состав созданной целевой аудитории.
Оставаться в границах архитектуры безопасности SharePoint — самый простой и недорогой способ устранить уязвимое место в системе безопасности на уровне элементов. Однако сложность эффективной реализации такого подхода заключается в осуществлении полного контроля над информационной архитектурой и политиками безопасности предприятия. Если организация предъявляет строгие требования к управлению документами, то SharePoint можно интегрировать с другим продуктом для управления контентом на предприятии ECM (Enterprise Content Management), таким как EMC Documentum. SharePoint обеспечивает интерфейс пользователя и компоненты коллективной работы, а продукт ECM, наряду с другими возможностями, — репозитарий документов с защитой на уровне элементов. Однако у такого подхода есть ряд недостатков.
- Продукт ECM заменяет, а не расширяет довольно ограниченную инфраструктуру управления контентом SharePoint.
- Продукт ECM значительно увеличивает стоимость реализации SharePoint.
- Продукт ECM непросто интегрировать с SharePoint, для интеграции требуются выделенные ресурсы или сторонний поставщик (например, Vorsite).
- Можно лишиться простого пути перехода к следующей версии SharePoint.
Несовершенный, но определенно более удачный вариант
Любой ИТ-специалист подтвердит, что безупречных программных продуктов не существует. У любого сложного приложения есть недостатки. Аналогично, коммерческие программные продукты удовлетворяют лишь часть потребностей сообщества пользователей, особенно если контингент пользователей разнообразен. Идентификация пробелов и поиск решений — важный компонент оценки или работы с продуктом. С ростом популярности SharePoint поиск и устранение слабых мест все более заметно способствуют успешному применению продуктов на предприятии. Дополнительную информацию по устранению пробелов можно получить в статье «Обходим ограничения SharePoint», опубликованной в февральском номере Windows IT Pro/RE за 2006 г.
Если же забежать немного вперед, то следует сказать, что в новой версии продукта SharePoint 2007 многие из описанных в статье решений уже будут реализованы на уровне базового продукта, например можно будет настраивать права доступа к каждому элементу списка или папки через задание политик использования документа, с помощью которых можно также задавать настройки для периода хранения документов, действия после завершения этого периода и проводить аудит использования документа. Интеграция политик с клиентскими приложениями сделает их использование прозрачным и несложным для сотрудников и позволит компаниям менять поведение приложений в соответствии с потребностями бизнеса.
Этан Вилански - Редактор Windows IT Pro и главный технолог подразделения Technology Strategy and Architecture компании EDS. Автор и соавтор более десятка книг, выпущенных компанией Microsoft. ewilansky@windowsitpro.com
Джефф Сандлер - Ведущий технолог подразделения Technology Strategy and Architecture компании EDS. Проработал в компании EDS более 15 лет в качестве архитектора и разработчика. jsandl01@gmail.com
Экран 2. Список ролей SharePoint
Guest Reader Contributor Web Designer Administrator Content Manager Member