От SharePoint 2003 к SharePoint 2007
В результате постоянного совершенствования продукт Microsoft SharePoint Services 2003 превратился в Microsoft Office SharePoint Server 2007 — решение с гораздо более полным и мощным набором инструментов безопасности. Безопасность SharePoint 2003 основывалась на защищенной процедуре регистрации, подкрепленной Active Directory (AD), защитой портала и защитой на уровне списков. В SharePoint 2007 усовершенствованы прежние функции безопасности и появились дополнительные функции аудита, политики хранения данных и надежно защищенные продукты коллективной работы, такие как Excel Services. В данной статье показано, как развивались методы защиты SharePoint, какой подход к проверке подлинности и авторизации применялся в каждой версии и каким образом преимущества SharePoint 2007 можно реализовать в конкретной компании.
Проверка подлинности в SharePoint 2003
Для начала рассмотрим особенности системы безопасности решений и технологий Microsoft SharePoint 2003. Фундамент любого продукта безопасности — возможность управлять доступом к защищенным материалам, которая, в сущности, сводится к цифровым удостоверениям личности и паролям. Технологии SharePoint 2003 для проверки учетной записи пользователя основаны на AD, поэтому политики паролей любого сайта SharePoint, в сущности, представляют собой политики паролей базовой сети AD. Как отмечается в комплекте ресурсов Microsoft SharePoint Products and Technologies Resource Kit, в политиках паролей необходимо учитывать множество рекомендаций, особенно при использовании технологий SharePoint в сети. Этими рекомендациями оговаривается минимальная длина пароля, его сложность, число последовательных попыток ввода и использование смарт-карт и биометрических устройств.
Какое именно влияние оказывает использование AD на процесс проверки подлинности пользователей (пользователь должен быть именно тем, за кого он себя выдает)? В SharePoint 2003 предусмотрено два режима работы: ранее существовавшей учетной записи (preexisting-account mode) и создания учетной записи (account-creation mode). В режиме ранее существовавшей учетной записи (иначе — доменном режиме) учетная запись AD должна уже существовать до того, как пользователь обратится к сайту SharePoint. В режиме создания учетной записи (выбираемом во время установки SharePoint) можно автоматически создавать учетную запись AD каждый раз при добавлении нового пользователя SharePoint. Определить режим, в котором находится SharePoint 2003, можно с помощью инструмента командной строки Stsadm.exe, поставляемого вместе с продуктом.
В любом случае существование учетной записи AD обеспечивает необходимую для доступа к SharePoint проверку подлинности. SharePoint проверяет существование пользователя в AD через протокол NTLM или Kerberos. Чтобы выполнить авторизацию, проверенная учетная запись сопоставляется с информационным списком управления доступом для сайта SharePoint. Эти списки авторизации хранятся в базах данных контента Microsoft SQL Server и изменяются изнутри SharePoint. Эти списки или группы можно организовать на уровне пользователя, в группы уровня сайта или в группы многосайтового уровня.
Чуть выше отмечалось, что в SharePoint для проверки учетной записи используется AD, но это утверждение не совсем точное. Можно задействовать и локальные учетные записи Windows. Однако, если не использовать AD, нельзя заполнить базу данных профиля заранее. А если у кого-нибудь из пользователей есть личные сайты, то они не будут зарегистрированы для межфермерной синхронизации на серверах фермы. Из-за этих ограничений настоятельно рекомендуется работать с AD.
Авторизация SharePoint 2003
Каковы последствия применения AD для авторизации пользователя (проверки, что у пользователя есть разрешение для доступа к ресурсу)? Авторизация SharePoint 2003 основана на группах прав, к которым привязываются пользователи или группы пользователей. Группы безопасности можно настроить, но по умолчанию в составе Windows SharePoint Services имеется пять групп:
-
Administrator (администратор) — полный контроль над Web-узлом;
-
Web Designer (Web-конструктор) — управляет внешним видом и реакцией Web-узла на действия пользователей;
-
Contributor (участник) — может добавлять контент в существующие компоненты Web Part;
-
Reader (читатель) — имеет доступ только для чтения содержимого в списках и библиотеках документов;
-
Guest (гость) — имеет низший уровень прав. Эта группа обеспечивает доступ для чтения разделов сайта без доступа ко всему сайту.
Права разделяются на три основные категории: права списка, права сайта и личные права. В результате проверки списочных прав выясняется, может ли пользователь вносить элементы в список, редактировать их, управлять столбцами в списке и т.д. Проверка прав сайта выполняется при каждой попытке пользователя создать сайт, управлять пользователями сайта, изменить внешний вид и поведение сайта и во многих других случаях. Личные права проверяются, когда пользователь пытается создать или изменить вид личного списка и использовать частные или личные компоненты Web Part. На экране 1 показан полный список прав, имеющихся в SharePoint 2003.
Если знать, как в SharePoint организовано распределение прав по группам, становится понятно, как организовать пользователей. Можно индивидуально управлять разрешениями каждого пользователя, но лучше сформировать группы пользователей. Существует два варианта распределения пользователей по группам: группы сайта и межсайтовые группы. Группа сайта — это группа пользователей, которых можно связать с конкретным сайтом SharePoint. Если пользователи объединены в межсайтовой группе, то эта группа создается на верхнем уровне семейства сайтов и доступна для любого сайта в этом семействе.
Предположим, что в компании Contoso есть несколько подразделений, в частности Marketing (маркетинг), Executive (руководители), Finance (финансы) и IT (ИТ). Если каждое из этих подразделений располагает собственным сайтом ниже сайта верхнего уровня, то у пользователя в подразделении Executive может не быть доступа к документам, хранящимся в финансовом подразделении, если ему явно не назначено таких прав. Однако, если пользователи каждого подразделения размещаются в межсайтовых группах, менеджеру подразделения Finance следует предоставить только межсайтовой группе Executive право чтения в портале, и оно сразу распространится на всех членов команды.
Безопасность на уровне сайта
Итак, имеются группы пользователей и группы прав. Как использовать эти группы для защиты портала SharePoint? SharePoint 2003 обеспечивает два уровня безопасности: на уровне сайта и на уровне списка. При создании сайта SharePoint создатель или владелец имеет возможность выбрать режим безопасности. Можно наследовать разрешения родительского сайта или использовать уникальные разрешения. Если решено наследовать родительские разрешения, то параметры безопасности передаются вниз новому сайту портала, и каждый, кто имеет тот или иной уровень доступа к родительскому сайту, имеет такой же доступ в новом сайте. Если выбраны уникальные разрешения, то первоначально создатель оказывается единственным пользователем, имеющим какие-либо права доступа в новом портале. После создания сайта можно добавить в сайт новых пользователей или группы пользователей и назначить специальные разрешения.
Предположим, что в компании Contoso есть ИТ-подразделение. Его сотрудники должны иметь возможность отслеживать заявки о неполадках через список контроля проблем SharePoint. Для этого в ИТ-подразделении построен сайт ИТ-портала, дочерний для основного сайта Contoso. В этой вымышленной компании каждый член домена имеет по крайней мере доступ для чтения на основном сайте компании. Создаваемый сайт ИТ-портала наследует разрешения; любой пользователь домена может подключиться к сайту ИТ-портала и увидеть данные на домашней странице, в том числе список контроля проблем на домашней странице сайта ИТ-портала. В настоящее время ИТ-подразделению необходимо определить место для хранения специальной информации, в частности паролей сервера. Руководитель ИТ-службы не хочет, чтобы пользователи видели, что такая документация существует, поэтому строится новый сайт портала с уникальными разрешениями. Пользователями этого сайта портала PrivateIT могут быть только члены ИТ-службы. Если другие пользователи пытаются обратиться к сайту портала PrivateIT, они получают сообщение об ошибке из-за отсутствия разрешения для доступа к ресурсу. В дополнительном сообщении можно разъяснить, что разрешение для доступа к защищенному порталу они могут получить у администратора.
Безопасность на уровне списка
Безопасность на уровне списка обеспечивается аналогично, но на уровне отдельных списков, а не на уровне сайта. Обратимся вновь к примеру общедоступного сайта ИТ-портала со списком контроля проблем. Предположим, что ИТ-подразделение намерено предоставить каждому пользователю возможность читать элементы списка, но руководитель считает необходимым предоставить членам межсайтовой группы Managers возможность добавлять новые и редактировать существующие элементы. В параметрах разрешений списка можно добавлять пользователей или группы и назначать им различные разрешения. Достаточно ввести список, щелкнуть на Modify Settings and Columns, а затем на ссылке Change permissions for this list. На экране 2 показан самый подробный список прав, который можно назначить. Обратите внимание на заманчивую ссылку Modify item-level security в левой панели. Эта ссылка позволяет лишь переключать представления пользователей из режима просмотра и редактирования всех элементов списка в режим, в котором можно увидеть лишь собственные элементы списка.
Разрешение на уровне элемента было предвестником новшеств SharePoint 2007, которые стали важным шагом в эволюции методов проверки подлинности и авторизации, с более разнообразными, детализированными и интуитивно понятными вариантами.
Проверка подлинности SharePoint 2007
В SharePoint 2007 не только сохранены прежние возможности, интегрированные с Windows, но и появилась модель провайдера ASP.NET. Благодаря модели провайдера ASP.NET устраняется необходимость в учетных записях Windows или AD и предоставляются новые возможности, в частности проверка подлинности форм с использованием хранилища данных пользователя (например, базы данных SQL Server). Также можно задействовать процедуру однократной регистрации SSO на базе Web, при которой пользователь регистрируется с помощью формы регистрации, отличной от SharePoint. Известный пример процедуры однократной регистрации на базе Web — Windows Live ID (в прошлом .NET Passport). В результате эволюции проверки подлинности разработчики и администраторы получают большую гибкость при установке и настройке SharePoint 2007.
Авторизация в SharePoint 2007
Изменения в процедуре проверки подлинности SharePoint важны, но они не так существенны, как будущие усовершенствования авторизации. В SharePoint 2003 пользователи и администраторы наделены правами (right), а в SharePoint 2007 используется термин «разрешения» (permission), и различия между группами пользователей и группами разрешений определены гораздо более четко. Сотрудники распределяются по логическим группам, таким как ИТ-менеджеры, младший финансовый персонал и члены команды руководителей. Разрешения назначаются логическим группам, таким как конструкторы и читатели, а разрешения, связанные с этими группами, четко определены. В SharePoint 2003 различия размыты. На уровне сайта можно назначить сотруднику роль Readers, но на уровне списка группа Readers действует в соответствии со своими правами. В SharePoint 2003 такое динамическое распределение приводит к путанице среди администраторов: неясно, что разрешено делать той или иной группе в каждом сайте и в каждом списке. Другое важное улучшение безопасности SharePoint 2007 — добавление детализированных разрешений. Теперь можно защитить не только сайт или список, но и папку и элемент в списке. Поэтому конфиденциальные и общедоступные документы можно хранить в одной библиотеке. Чтобы предотвратить несанкционированные обращения, урезается интерфейс SharePoint 2007. Документ или пункт меню даже не видны пользователю, у которого нет разрешения для их просмотра. Если нет разрешений для использования ни одного из пунктов меню Site Actions, все меню целиком исчезает с экрана.
SharePoint Groups — логические группы или объединения людей. По умолчанию в программе имеются три группы: Owners, Members и Visitors. Функционирование этих групп аналогично межсайтовым группам SharePoint 2003, так как им можно поставить в соответствие семейство сайтов, и впоследствии они будут доступны для использования повсюду в данном семействе сайтов. Благодаря таким группам разрешения можно масштабировать на большое число сотрудников.
Первоначальная концепция групп сайта SharePoint чрезвычайно гибкая, что затрудняет эффективную организацию пользователей и ролей. Пользователей можно приписать к группе сайта и назначить права группе сайта. Затем, сопоставляя пользователей групп сайта с группами, содержащими права, можно, в сущности, создать роль, определяя, какие пользователи могут выполнять конкретные действия. В новой версии неоднозначность устраняется при определении и назначении групп. В SharePoint 2007 ролевая концепция семейств разрешений четко определена как уровень разрешений, который функционирует в качестве роли. Разрешения приписываются к уровням разрешений, и администратор назначает уровни разрешений группам SharePoint.
Группы также всегда определены на уровне семейства сайтов, что обеспечивает единое соглашение об именовании во всех сайтах семейства. Все эти меры снижают вероятность путаницы.
Рассмотрим практический пример. В портале SharePoint щелкните на ссылке People and Groups в панели Quick Nav (экран 3). Щелкните на кнопке More, чтобы увидеть все группы. В результате выяснится, что сайт располагает только группами, создаваемыми по умолчанию. Чтобы добавить две новые группы, представляющие пользователей ИТ-подразделения Contoso и пользователей финансового подразделения, щелкните на New и выберите из раскрывающегося списка пункт New Group. Для ИТ-подразделения следует заполнить форму, показанную на экране 4. Обратите внимание на уровень разрешений внизу формы. Прежде чем перейти к добавлению группы для финансового департамента, необходимо создать новый уровень разрешений безопасности для пользователей Finance. В списке групп щелкните на кнопке Site Permissions, чтобы перейти к панели, показанной на экране 5. Здесь показаны уровни разрешений и группы, к которым отнесены пользователи Finance, и можно управлять взаимодействием типа «многие со многими» между группами и уровнями разрешений. Роли Read, Contribute и Full Control (т. е. администрирование) существуют наряду с новыми для SharePoint 2007 уровнями Limited Access (аналогичен уровню Guest в SharePoint 2003) и Approver («утверждающий»). Чтобы добавить новый уровень разрешений для членов команды Finance, щелкните на Settings, Permission Levels. На экране появится список доступных разрешений. Щелкните на кнопке Add a Permission Level, чтобы создать новую роль пользователя Finance. На экране 6 видно, насколько больше доступных разрешений в SharePoint 2007, чем в SharePoint 2003. Выберите нужные разрешения (предоставьте широкие права списка) и щелкните на кнопке Create. Таким образом, подготовлен новый уровень разрешений для сотрудников финансового подразделения. Теперь следует вернуться на домашнюю страницу Permissions и ввести в новую группу сотрудников Finance. Добавленная группа разрешений пользователей Finance появится внизу экрана New Group. После этого можно добавить пользователей в группу Finance, и любой пользователь группы Finance будет иметь одинаковые разрешения на любом сайте в семействе сайтов SharePoint.
Поняв способы объединения пользователей в группы и назначения группам различных разрешений, можно применить эти группы для защиты SharePoint 2007. Как и в SharePoint 2003, можно явно назначать или запрещать доступ к сайту или списку, но теперь появляется дополнительная возможность защитить отдельные элементы списка и папки библиотеки документов. Поэтому пользователь может обращаться к сайту и библиотеке документов, но администратор вправе запретить ему доступ к отдельным документам или папкам.
Административная безопасность
В данной статье мы рассмотрели меры безопасности на уровнях пользователя и сайта в SharePoint 2003 и SharePoint 2007. В распоряжении администраторов SharePoint появились дополнительные уровни безопасности, а также возможность применять защиту на уровне служб Shared Services и на центральном административном уровне в SharePoint 2007.
В сущности, администрирование Shared Services означает, что администратор фермы серверов может делегировать авторизацию для определенных задач другим пользователям. Это удобно, если пользователи делают неудачные изменения, например удаляют объект (и затем очищают «Корзину»). Благодаря делегированию авторизации пользователю не приходится обращаться за помощью к администратору фермы.
Последний возможный уровень настройки системы безопасности в экземпляре SharePoint 2007 — уровень централизованного администрирования. Среди множества новых функций этого уровня есть и политики безопасности — набор разрешений, применяемых в любых местах фермы. Эти политики допуска и запретов отменяют все другие разрешения, и их можно задавать для отдельных Web-приложений и Web-зон. Типичные примеры использования политики безопасности — предоставление полного доступа для чтения аудиторам и запрет любых операций записи для всех пользователей из зоны Internet (т. е. внешней сети). На этом уровне можно также создать служебные учетные записи AD, чтобы предотвратить нежелательное поведение приложения в сети. На этом уровне настраиваются учетные записи пула приложений, учетные записи службы SharePoint (SPTimer и Admin Service) и доступ к SQL Server.
Огромные возможности
SharePoint 2007 существенно облегчает работу конечных пользователей. Благодаря более удобному интерфейсу и таким приемам, как урезание функциональности в целях безопасности, пользователь видит только сайты, списки и документы, для которых есть разрешения. Еще более важно, что с появлением SharePoint 2007 упрощается задача администратора, благодаря четкой организации пользователей и ролей, определенных на одном уровне, возможности делегировать операции другим пользователям через службу Shared Services и применению политик безопасности в масштабах системы.
Мэтт Ранлетт (mranlett@devcow.com) — консультант компании Intellinet в Атланте. Имеет сертификат Microsoft MVP. Вице-президент организации Technology for INETA и один из основателей сообщества Atlanta .NET Regular Guys.
Брендон Шварц (bschwartz@devcow.com) — старший консультант в Атланте. Имеет сертификат Microsoft MVP. Вице-президент организации Technology for INETA и один из основателей сообщества Atlanta .NET Regular Guys, размещенного на сайте DevCow (http://www.devcow.com).
Учебные ресурсы
Ресурсы Microsoft
Microsoft SharePoint Products and Technologies Resource Kit;
http://www.microsoft.com/technet/windowsserver/sharepoint/V2/reskit/c2461881x.mspx
Microsoft Office SharePoint Server 2007;
http://www.microsoft.com/office/preview/servers/sharepointserver/overview.mspx
Microsoft SharePoint Products and Technologies Team Blog;
http://blogs.msdn.com/sharepoint
Ресурсы Web
SharePoint Blogs;
http://www.sharepointblogs.com/
«How can I tell if WSS is in Account Creation Mode?»;
http://wss.collutions.com/Lists/FAQ/DispForm.aspx?ID=151