Microsoft SharePoint 2010: Обязательные службы в SharePoint

Есть обязательные и дополнительные службы, которые вы можете установить и активировать в Microsoft SharePoint 2010.

Стив Райт и Кори Эркес

Адаптированная выдержка из книги «SharePoint Governance» (Apress, 2012).

На самом базовом уровне службы SharePoint можно разделить на обязательные и необязательные. Обязательными службами являются те, которые всегда должны быть, чтобы система функционировала нормально. Существуют службы, необходимые по техническим причинам. В организации могут применяться законодательные или нормативные требования, которые заставляют превратить дополнительные службы в обязательные. Например, если есть портал, где хранятся корпоративные записи, подпадающие под действие закона Сарбейнса-Оксли (Sarbanes-Oxley), может потребоваться наличие функций управления записями SharePoint.

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

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

Обязательные службы

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

Инфраструктурные службы

Инфраструктурные службы являются основой для остальной части системы.

Аппаратная инфраструктура

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

При разработке аппаратного плана портала необходимо учитывать следующее:

• Пользовательская нагрузка Сколько пользователей будут использовать систему одновременно? Какие службы будут наиболее активно использоваться?
• Объем хранения Сколько данных нужно хранить на портале, включая все версии и типы документов?
• Конфигурация хранения Будет ли все содержимое хранится на отдельном SQL Server, NAS- или SAN-массиве? Нужен ли доступ к данным через службу удаленного хранения BLOB (больших двоичных объектов) на SQL Server?
• Пропускная способность сети Сколько данных будет отправлять и получать портал?
• Сетевая маршрутизация Нужно ли вам приложение для балансировки сетевой нагрузки? Как насчет новых параметров брандмауэра?
• Серверные уровни Любому порталу SharePoint требуется один или больше веб-серверов и серверов баз данных. Требуются ли для вашего портала отдельные серверы запросов и индексирования? А как насчет других служб уровня приложений, таких как Excel Services, Access Services и PerformancePoint Services? Эти службы можно разместить на веб-серверах переднего плана, но это отрицательно скажется на производительности.

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

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

Проверка подлинности

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

• Классическая проверка подлинности используется на большинстве веб-сайтов и в более ранних версиях SharePoint. При этом проверяются учетные данные на предмет соответствия данным поставщика удостоверений Windows, Active Directory (Windows NT LAN Manager) или Kerberos. Информация включает в себя основные атрибуты пользователя, включая членство в группах безопасности.
• Проверки подлинности на основе утверждений является новым в SharePoint 2010. Утверждение (claim) представляет собой набор информации о субъекте, предоставленный доверенным поставщиком утверждений. Эта информация передается в зашифрованном маркере безопасности, выданным поставщиком. Пользователь представляет утверждение в качестве доказательства своей подлинности для того, чтобы получить доступ к данной системе.

Active Directory, Kerberos и многие другие поставщики могут также служить поставщиками проверки подлинности на основе утверждений. При выполнении проверки подлинности на основе форм (например, когда пользователь входит в систему с учетными данными, хранящимися в базе данных), в качестве поставщиков утверждений выступают компоненты, известные как поставщики членства в группах и ролях. Другой распространенный метод заключается в использовании централизованного хранилища удостоверений, такого как Windows Live ID для предоставления утверждений с применением языка SAML (Security Assertion Markup Language).

При использовании проверки подлинности следует принимать во внимание следующие факторы:

• Где хранятся имя пользователя и пароль?
• Как пользователь меняет свой пароль?
• Кто создаются и отключаются пользователи?
• Какая конфигурация необходима для размещения указанных учетных данных в SharePoint?
• Как портал будет устанавливать доверительные отношения со своими поставщиками утверждений?

Нередко используются несколько форм проверки подлинности в пределах одной фермы SharePoint. Для проверки подлинности внутренних пользователей в интрасети чаще всего используют проверку подлинности Active Directory. Все больше администраторов осваивает протокол Kerberos, поэтому его популярность растет. Для внешних пользователей экстрасети или общедоступного веб-сайта использование проверки подлинности Active Directory часто невозможно. Чаще применяется проверка подлинности с использованием  форм или интернет-службы удостоверений, такой как Windows Live.

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

Авторизация

Авторизация относится к процессу определения того, какие пользователи могут выполнять те или иные действия в системе. При проверке подлинности получают ответ на вопрос: «Кто данный пользователь?», а авторизация дает ответ на вопрос: «Что данному пользователю доступно в системе?»

Первое понятие в авторизации — удостоверение. Удостоверением пользователя является его имя и членство в группах безопасности. Есть два типа удостоверений в SharePoint — на уровне домена и на уровне групп SharePoint:

• Доменные удостоверения это имена пользователей и имена групп, определяемые утверждениями или классическим поставщиком, используемые для входа в систему. После входа пользователя в SharePoint имена пользователей домена и групп используются одинаково. Менять состав членов доменной группы из SharePoint нельзя.
• Группы SharePoint позволяют объединять доменных пользователей и группы для упрощения управления разрешениями. Вы можете редактировать группы SharePoint через веб-интерфейс. Можете предоставить пользователям добавить себя в члены или запрашивать членство у владельца группы. Одним из недостатков групп SharePoint заключается в том, что они относятся только к коллекции сайтов, в которой созданы. Нельзя использовать их «перекрестно», то есть в других коллекциях.

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

В определении роли задается разрешение или разрешенные действия, например просмотр сайта, редактирование элемента списка и удаление страницы. SharePoint также позволяет создавать уровни разрешений. Уровень разрешений представляет собой группу разрешений, которую можно определить как единое целое. Назначение пользователю уровня разрешений для объекта предоставляет им все права, предусмотренные этим уровнем разрешений. К наиболее популярным уровням разрешений относятся Full Control (полный доступ), Contribute (соавторство), Read (чтение) и Design (конструирование). Можно создавать и редактировать уровни разрешений средствами веб-интерфейса SharePoint. Как и группы SharePoint, уровни разрешений определены в пределах одной коллекции сайтов.

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

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

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

• Будете ли вы управлять членством в группах SharePoint или доменных группах? Группы SharePoint определены только в пределах каждой коллекции сайтов, но вы можете легко управлять ими через веб-интерфейс. Доменные группы носят глобальный характер, но управлять ими нужно за пределами SharePoint.
• Как пользователи будут запрашивать и получать доступ к той или иной группе?
• Подходят ли для ваших нужд стандартные уровни разрешений, предоставляемые SharePoint? Если нет, то можно изменить или создать новые уровни в соответствии с ситуацией.
• Владельцы сайта обычно назначают разрешения на своих сайтах. Кто будет владельцами того или иного сайта и как вы будете передавать управление, когда пользователи покидают организацию?
• Кто будет отвечать за удаление прав доступа пользователей, которые покидают организацию?

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

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

Интеграция электронной почты

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

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

При проектировании интеграции электронной почты в портале учитывайте следующие моменты:

• Исходящая электронная почта необходима в большинстве интранет-порталов. Является ли входящая электронная почта действительно необходимой или только желательной?
• Будет ли на веб-серверах использоваться локальная служба SMTP или внешние серверы электронной почты?
• Какие конфигурации безопасности необходимы для пересылки электронной почты внутрь и наружу фермы SharePoint?
• Как настроить почтовые серверы и брандмауэр, чтобы предотвратить использование сайта SharePoint как перевалочного пункта для спама?
• Как входящий спам будет отфильтровываться из почтового ящика SharePoint?

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

Администрирование и мониторинг

Службы администрирования и мониторинга помогут вам настроить и контролировать ферму SharePoint Server.

Веб-сайт Central Administration

Основным интерфейсом администрирования SharePoint является веб-сайт Central Administration (CA). Он содержит инструменты для выполнения практически всех функций администрирования SharePoint. Такой веб-сайт должен быть только на одном сервере SharePoint в ферме. Используя его, можно создавать новые веб-сайты и коллекции сайтов, конфигурировать службы фермы, распределять ресурсы и квоты, а также с помощью простого веб-интерфейса выполнять множество других задач.

Вот несколько рекомендаций по работе с CA:

• Позаботьтесь, чтобы на сайт CA не поступал веб-трафик из Интернета. Используйте параметры брандмауэра или сетевую маршрутизацию, чтобы предотвратить доступ для хакеров.
• Стоит подумать о размещении сайта CA на уровне сервера приложений, который не взаимодействуют с Интернетом.
• Ограничьте количество администраторов фермы. Доступ к СА должны иметь только высококвалифицированные специалисты.
• Храните журнал всех изменений, выполненных на CA.
• Перенос веб-сайта CA с сервера на сервер выполняется с помощью Мастера настройки продуктов и технологий SharePoint.
• Изменить случайным образом номер порта, присвоенный при развертывании веб-сайта CA, можно с помощью командлета Set-SPCentralAdministration оболочки Windows PowerShell.

Хотя выполнять большинство административных действий можно с помощью интерфейса CA, некоторые из них требуют использования инструментов командной строки SharePoint. Интерфейс Windows PowerShell позволяет писать сложные, объектно-ориентированные сценарии администрирования. Это предпочтительный инструмент создания сценариев для SharePoint 2010. Команда STSADM, используемая в предыдущих версиях SharePoint, по-прежнему доступна в версии 2010, но она считается устаревшей и включена только для поддержки обратной совместимости.

Ведение журналов и трассировка

SharePoint использует Universal Logging System для консолидации трассировочной информации из различных компонентов продукта. Эти журналы могут становиться очень большими. Необходимо выделить достаточно места для их хранения, иначе система может оказаться не в состоянии регистрировать важные данные. Кроме того, если по умолчанию в системе используется диск C, то журналы могут заполнить системный диск и вызвать сбой системы.

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

Использование и сбор данных о текущем состоянии

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

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

Стив Райт (Steve Wright) — является старшим менеджером в отделе бизнес-аналитики компании Sogeti USA из Омахи, штат Небраска. За последние 20 лет с небольшим Стив работал над системами управления воздушным движением, а также над финансовыми, страховыми и многими другими системами. Он выступал в роли автора и рецензента многих изданий, посвященных таким продуктам Microsoft, как Windows, SharePoint, SQL Server и BizTalk.

Кори Эркес (Corey Erkes) — работает управляющим консультантом в компании Sogeti USA из Омахи, штат Небраска. Erkes работал со многими компаниями на разных этапах внедрения их решений SharePoint. Он также является одним из создателей пользовательской группы SharePoint в Омахе.