Пример проекта: корпоративное развертывание (SharePoint Server 2010)
Применимо к: SharePoint Foundation 2010, SharePoint Server 2010
Последнее изменение раздела: 2017-01-18
В этой статье описывается практическая реализация компонентов логической архитектуры для получения работоспособной разработки. Эта статья предназначена для использования со следующими примерами разработок:
Пример разработки: корпоративный портал с классической проверкой подлинности
Пример разработки: корпоративный портал с проверкой подлинности на основе утверждений
Чтобы загрузить эти модели, перейдите на страницу, на которой приводятся примеры разработок SharePoint Server 2010 — корпоративного портала с классической проверкой подлинности или с проверкой подлинности на основе утверждений (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x419) (Возможно, на английском языке).
Содержание статьи
Общие сведения о примерах разработок
Общие цели разработки
Фермы серверов
Пользователи, зоны и проверка подлинности
Службы
Альтернативы разработки и публикации
Сайты администрирования
Пулы приложений
Веб-приложения
Семейства сайтов
Базы данных контента
Зоны и URL-адреса
Политики зон
Примеры разработок иллюстрируют универсальное корпоративное развертывание Microsoft SharePoint Server 2010. В этих примерах применяются почти все компоненты логической архитектуры и иллюстрируется их включение в общую разработку. Эти два примера иллюстрируют одинаковые службы и сайты, но включают разные методы проверки подлинности, описанные ниже:
Классическая проверка подлинности: этот пример разработки представляет способ обновления сайтов из Microsoft Office SharePoint Server 2007 в Microsoft SharePoint Server 2010. Данный пример содержит классическую проверку подлинности, при которой для доступа к сайтам используются методы проверки подлинности Windows. Для каждого метода проверки подлинности используется другая зона. В то время как проверка подлинности Windows используется для сайтов SharePoint, брандмауэр или шлюз может быть настроен для использования проверки подлинности на основе форм для сбора учетных данных Windows, пересылаемых в SharePoint Server 2010. Учетные записи сотрудников партнера добавляются в корпоративный каталог.
Проверка подлинности на основе утверждений: этот пример разработки включает новую модель проверки подлинности на основе утверждений. Несколько поставщиков и типов проверки подлинности реализованы в одной зоне. Проверка подлинности на основе утверждений поддерживает проверку подлинности на основе форм, проверку подлинности на основе маркеров SAML и проверку подлинности Windows. В этом примере партнерские компании добавляются с помощью проверки подлинности на основе маркеров SAML для проверки непосредственно в каталогах партнеров. Существует несколько вариантов поставщика для учетных записей сотрудников партнера.
Используйте тот пример разработки, который наилучшим образом представляет ваши требования к проверке подлинности.
В этой статье описываются цели разработки для примеров и объясняются способы достижения этих целей с помощью компонентов логической архитектуры, иллюстрируемых в примерах.
Общие сведения о примерах разработок
Примеры разработок иллюстрируют корпоративное развертывание для вымышленной компании Fabrikam, Inc. Развертывание включает две фермы серверов. В одной ферме серверов размещается интрасеть компании и партнерский веб-сайт. Во второй ферме размещается веб-сайт компании (www.fabrikam.com). Далее в данном разделе описываются эти сайты верхнего уровня.
Интрасеть
Корпоративная интрасеть включает следующие сайты:
Опубликованный контент интрасети (например, HRweb)
Сайты для совместной работы групп
Личные сайты
Вместе это сайты контента и совместной работы, которые сотрудники будут использовать на повседневной основе. По отдельности каждое из этих приложений представляет конкретный тип контента. Типы контента выполняют следующие функции:
Выделяют разные возможности SharePoint Server 2010.
Размещают данные с разными характеристиками.
Регулируются разными профилями использования.
Требуют различной стратегии управления разрешениями.
Следовательно, выбор разработки для каждого из этих приложений имеет своей целью оптимизацию их производительности и безопасности.
Разработка приложений-служб сводит эти три приложения вместе, чтобы обеспечить следующие возможности:
Навигация между приложениями
Поиск на уровне предприятия
Использование общих данных профиля и корпоративных метаданных
Следующая диаграмма иллюстрирует три приложения, формирующих корпоративную интрасеть.
.gif "Сайты интрасети")
URL-адреса в этой иллюстрации взяты из примера разработки с классической проверкой подлинности.
Веб-приложение для партнеров
Веб-приложение для партнеров размещает доступные извне сайты для безопасной совместной работы с партнерскими компаниями и отдельными партнерами. Это приложение разработано, чтобы облегчить сотрудникам компании создание сайтов для безопасной совместной работы. Партнерам не разрешается доступ к другим типам контента, размещенного на ферме серверов. Для этой цели используются зоны и приложения-службы.
В примере разработки веб-приложение для партнеров размещается той же фермой, которая размещает контент интрасети.
Интернет-сайт компании
Интернет-сайт — это представительство компании в Интернете. Контент делается доступным для клиентов с помощью настройки анонимного доступа с разрешением только на чтение. При разработке этого приложения определяющими являются следующие ключевые факторы:
Изоляция контента: клиенты не могут получить доступ к другим типам контента, размещенным на ферме серверов.
Целевое управление: доступ с проверкой подлинности предоставляется для сотрудников, которые управляют веб-сайтом, выполняя задачи администрирования и разработки.
Безопасное создание и публикация контента: отдельное семейство сайтов размещается в ферме A в веб-приложении для партнеров для создания контента. Это обеспечивает возможность безопасной совместной работы и разработки контента для внутренних и удаленных сотрудников, а также для редакционных партнеров, которые специализируются на разработке веб-сайтов или создании контента. Для публикации контента настраивается автоматическая публикация из семейства сайтов разработки в первой ферме в рабочее семейство сайтов во второй ферме. Следующая диаграмма иллюстрирует процесс публикации.
.gif "Опубликованные сайты")
Общие цели разработки
Пример разработки предоставляет практическую реализацию возможностей SharePoint Server 2010 в рамках нескольких общих типов приложений. В данной статье обсуждается реализация разработок для каждого отдельного приложения. Пример разработки включает следующие основные цели:
Использование минимального количества ферм серверов для размещения самых общих типов веб-сайтов, обычно необходимых для корпорации, т. е. сайтов интрасети, экстрасети и интернет-сайтов.
Создание платформы для разработки среды, которая может расширяться. Решения по разработке для отдельных приложений не исключают добавление новых приложений. Например, начальное развертывание может включать только сайты для совместной работы групп или только три приложения, составляющих интрасеть (сайты рабочих групп, персональные сайты и опубликованный контент интрасети). Используя подобную разработку логической архитектуры можно добавлять приложения в решение, не затрагивая разработку начальных приложений. Другими словами, разработка не включает варианты, которые ограничивают использование среды в целом.
Предоставление доступа для нескольких групп пользователей без снижения безопасности контента в разных типах сайтов. Пользователи из разных зон сети (как внутренних, так и внешних) с разными поставщиками проверки подлинности могут участвовать с совместной работе. Кроме того, пользователи могут получать доступ только к тому контенту, который для них предназначен. С помощью подобной разработки логической архитектуры можно создавать условия для предоставления доступа пользователям в различных расположениях и с различными целями. Например, начальная разработка может быть предназначен только для доступа внутренних сотрудников. Однако при использовании подобной разработки можно также разрешить доступ для удаленных сотрудников, сотрудников партнеров, партнерских компаний и клиентов.
Обеспечение возможности для использования разработки в среде экстрасети. Варианты разработки тщательно выбираются для обеспечения возможности безопасного развертывания ферм серверов в сети периметра.
Далее в этой статье рассматриваются все логические компоненты, представленные в примере разработки (во всех его элементах) и обсуждаются варианты разработки, примененные в примере разработки. Целью такого подхода является демонстрация различных способов конфигурации компонентов логической архитектуры на основе приложения.
Фермы серверов
Пример разработки включает использование двух ферм серверов. В этом разделе описываются требования к лицензированию, которые влияют на число ферм серверов, необходимых в корпоративной среде, и приводятся топологии ферм серверов, которые были продемонстрированы в примере разработки.
Требования к лицензированию
Для размещения контента интрасети и интернет-сайтов требуется как минимум два сервера. Это необходимо для удовлетворения требований лицензирования.
Для SharePoint Server 2010 доступны две серверные лицензии:
Лицензия сервера для Microsoft SharePoint Server 2010: это лицензия, необходимая для контента интрасети, используемого для совместной работы. Эта лицензия требует использования клиентских лицензий (CAL). При создании сайтов для совместной работы с партнерами необходимо приобрести требуемое количество клиентских лицензий для сотрудников партнеров.
Microsoft SharePoint Server 2010 для интернет-сайтов: эта лицензия предназначена только для веб-сайтов с выходом в Интернет. Эта лицензия не требует использования клиентских лицензий. При создании сайтов для совместной работы с партнерами не нужно приобретать дополнительные клиентские лицензии. Однако вы не можете создавать сайты, предназначенные исключительно для использования вашими сотрудниками.
Примечание
Эти лицензии не могут совмещаться на одном и том же компьютере сервера или в одной и той же ферме серверов.
При данных вариантах лицензирования наиболее критическим решением разработки является выбор фермы для размещения веб-приложения для партнеров. В примере разработки первая ферма размещает контент интрасети, а вторая ферма размещает интернет-сайт компании. Согласно условиям лицензирования, любая из этих ферм может размещать веб-приложение для партнеров.
При определении, какая из этих двух ферм должна размещать веб-приложение для партнеров, необходимо руководствоваться следующими общими соображениями:
Характер совместной работы: если основным назначением сайта экстрасети для партнеров является безопасный обмен данными со многими партнерами, наиболее экономичным выбором будет ферма интернет-серверов. С другой стороны, если основной целью является совместная работа с небольшим числом сотрудников партнеров, ферма серверов интрасети может быть лучшим выбором. Выберите тот вариант, который позволит оптимизировать ферму для выполнения предназначенной ей роли.
Количество сотрудников партнеров: если при совместной работе с множеством сотрудников партнеров важно минимизировать затраты, можно безопасно разместить контент для совместной работы и анонимный контент в ферме с выходом в Интернет, используя лицензию для интернет-сайтов.
В примере разработки веб-приложение для партнеров предназначено для интенсивной совместной работы с партнерскими компаниями, включающей разработку и отладку интернет-сайта компании. Размещение веб-приложения для партнеров в первой ферме позволяет организации оптимизировать каждую из двух ферм с учетом их предназначения (соответственно — для совместной работа или контента, доступного только для чтения). Однако размещать веб-приложение для партнеров может любая из ферм.
Пример разработки включает Microsoft Office Web Apps. Для Office Web Apps требуется клиентская лицензия Microsoft Office 2010. Другими словами, если вы делаете Office Web Apps доступным для партнеров, вы должны приобрести для них клиентские лицензии Office 2010.
Топология ферм серверов
Каждая ферма в примере разработки состоит из пяти серверов со следующей топологией:
Два интерфейсных веб-сервера
Один сервер приложений
Два сервера баз данных, кластеризованных или зеркальных
Пример разработки иллюстрирует логическую архитектуру SharePoint Server 2010, показывая при этом, что:
для всех сайтов существуют зеркальные образы на интерфейсных веб-серверах;
сайт центра администрирования установлен на сервере приложений, чтобы обеспечить защиту от прямого доступа пользователей.
В реальности число серверов и топология фермы не важны для логической архитектуры, а имеют значение только для обеспечения необходимой емкости и производительности. Логическая архитектура может быть разработана независимо от топологии фермы серверов. Процесс планирования емкости и производительности поможет определить размер фермы серверов, соответствующий целям обеспечения производительности и емкости. Дополнительные сведения см. в статье Управление производительностью и емкостью (SharePoint Server 2010).
Масштабирование для случая более двух ферм
Для бизнеса может потребоваться представление более двух ферм. В отдельной выделенной ферме можно разместить следующие сайты:
Личные сайты: многие организации с большим количеством сотрудников или студентов размещают личные сайты в отдельной выделенной ферме серверов.
Сайты для разработки и отладки контента: при публикации сложного или обширного контента разработку и отладку можно более эффективно оптимизировать при размещении этих сайтов в отдельной выделенной ферме, состоящей из одного сервера, использующего лицензию Microsoft SharePoint Server 2010 для интернет-сайтов. Например, публикация контента, содержащего метаданные с тегами, увеличивает сложность примера разработки служб, используемых как фермой разработки, так и фермой публикации, включая совместное использование служб фермами и выбор способа совместного использования служб другими типами веб-приложений в многоцелевой ферме.
Сайты партнеров: требования к безопасности и изоляции могут служить основанием для использования отдельной выделенной фермы для совместной работы с партнерами. Такой подход создает физическую изоляцию между внутренним контентом и контентом, разработанным совместно с внешними партнерами.
Пользователи, зоны и проверка подлинности
При создании веб-приложения в SharePoint Server 2010 необходимо сделать выбор между проверкой подлинности на основе утверждений и классической проверкой подлинности. Режим проверки подлинности определяет внутреннее использование учетных записей в SharePoint Server 2010. В следующей таблице приводится обзор этих вариантов.
Тип проверки подлинности |
Описание |
Рекомендации |
Классическая проверка подлинности |
Учетные записи пользователей обрабатываются в SharePoint Server 2010 как традиционные учетные записи Windows Active Directory. Поддерживаются следующие протоколы проверки подлинности: Kerberos, NTLM, обычная проверка, дайджест-проверка и анонимный доступ. Проверка подлинности на основе форм не поддерживается. Для одной зоны может быть настроен только один метод проверки подлинности. |
Классический режим рекомендуется для обновления сред из Microsoft Office SharePoint Server 2007, где проверка подлинности на основе форм не требуется. Если при обновлении выбрана классическая проверка подлинности, выполнять перенос пользователей не нужно. |
Проверка подлинности на основе утверждений |
Учетные записи пользователей обрабатываются в SharePoint Server 2010 как удостоверяющие утверждения. Учетные записи Windows автоматически преобразуются в удостоверяющие утверждения. Этот режим дополнительно поддерживает проверку подлинности на основе форм и проверку подлинности в отношении соответствующего доверенного поставщика удостоверений. Для одной зоны может быть настроено несколько типов проверки подлинности. |
Проверка подлинности на основе утверждений рекомендуется для новых развертываний SharePoint Server 2010. Она также необходима для обновления решений Office SharePoint Server 2007, которым требуется проверка подлинности на основе форм. |
Обсуждаемые в данной статье примеры разработок представляют оба этих варианта. В следующих разделах более конкретно обсуждается проверка подлинности, включенная в примеры разработок.
Пример разработки с классической проверкой подлинности
Пример разработки, использующий классическую проверку подлинности, включает традиционный вариант проверки подлинности "одна зона на тип", который был включен в предыдущий выпуск. По этой причине этот пример представляет способ обновления из Office SharePoint Server 2007 в SharePoint Server 2010.
Единственное, что здесь следует помнить: в классическом режиме не поддерживается проверка подлинности на основе форм. При использовании классической проверки подлинности все проверяемые учетные записи должны располагаться в службах доменов Active Directory (AD DS). Пользователям, получающим доступ к сайтам удаленно, рекомендуется использовать проверку подлинности на основе форм в брандмауэре или шлюзе для сбора учетных данных Windows, которые перенаправляются в ферму SharePoint.
Пример классического режима иллюстрирует четыре разных класса пользователей, назначенных разным зонам. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть".
В следующей таблице показаны зоны, пользователи и тип проверки подлинности, заданные в примере разработки с классическим режимом.
.gif "Таблица, содержащая сведения о зонах, пользователях и проверке подлинности.")
Для учетной записи обхода контента при поиске требуется доступ как минимум к одной зоне, использующей проверку подлинности NTLM. Если ни одна зона для пользователей не настроена для использования NTLM, настройте специальную зону для использования проверки подлинности NTLM.
Пример разработки с проверкой подлинности на основе утверждений
Проверка подлинности на основе утверждений рекомендуется для всех новых развертываний SharePoint Server 2010 и необходима для обновления решений Office SharePoint Server 2007, которым требуется проверка подлинности на основе форм. Кроме поддержки стандартных методов проверки подлинности Windows, проверка подлинности на основе утверждений может выполняться относительно других каталогов, таких как Windows Live ID, службы федерации Active Directory 2.0 или сторонний поставщик удостоверений, поддерживающий маркеры SAML и протокол WS Federation.
В примере разработки проверка подлинности на основе утверждений используется в ферме для совместной работы. Проверка подлинности на основе утверждений позволяет использовать несколько типов проверки подлинности в одной и той же зоне. В примере разработки используется зона "По умолчанию" для всех типов проверки подлинности. В следующей таблице показаны зоны, пользователи и тип проверки подлинности, указанные в примере фермы для совместной работы.
.gif "Таблица, содержащая сведения о зонах, пользователях и проверке подлинности.")
В примере разработки сайт опубликованного контента интрасети, сайты рабочих групп и личные сайты доступны только для сотрудников, независимо от того, находятся ли они в сети или вне ее. В примере разработки реализуется только один URL-адрес (использующий SSL), который может применяться изнутри сети и извне. Используются учетные записи Active Directory. При необходимости LDAP может использоваться с проверкой подлинности на основе форм или стандарта SAML, что требует дополнительной настройки.
В примере разработки веб-приложение для партнеров представляет сайт экстрасети, доступный для сотрудников партнеров и партнерских компаний. Использование проверки подлинности на основе утверждений в этом сценарии требует настройки доверия с одной или несколькими внешними службами маркеров безопасности. Это можно обеспечить с помощью одного из следующих подходов:
Ферма SharePoint может быть настроена для доверия внешней службе маркеров безопасности, например службе маркеров безопасности, связанной с Windows Live (для проверки подлинности отдельных партнеров), или службе маркеров безопасности, которая находится в партнерской компании (для проверки подлинности непосредственно в каталоге партнера).
Служба маркеров безопасности в корпоративной среде может быть настроена для доверия внешней службе маркеров безопасности. Эта связь должна быть явно установлена администраторами в обеих организациях. В этом сценарии ферма SharePoint настроена на доверие только той службе маркеров безопасности, которая находится в ее собственной корпоративной среде. Эта внутренняя служба маркеров безопасности проверяет маркер, который получает из внешней службы маркеров безопасности, и выдает маркер, позволяющий пользователю партнера получить доступ к ферме SharePoint. Это рекомендуемый подход.
Альтернативой реализации среды на основе утверждений для проверки подлинности партнеров является использование проверки подлинности на основе форм и управление учетными записями с помощью отдельного хранилища, например базы данных.
Дополнительные сведения о реализации среды проверки подлинности на основе утверждений см. в следующем техническом документе, посвященном использованию удостоверения на основе утверждений для Windows в службах федерации Active Directory 2.0, Windows CardSpace 2.0 и Windows Identity Foundation (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x419) (Возможно, на английском языке).
В примере разработки проверки подлинности на основе утверждений для фермы публикаций настроено использование классической проверки подлинности. Альтернативой является использование проверки подлинности на основе утверждений для фермы публикаций, а также реализация отдельной зоны для анонимных пользователей. Важным элементом разработки является использование отдельной зоны для анонимных пользователей для создания изоляции между средой с доступом только для чтения и средой с доступом для чтения и записи, независимо от реализованного режима проверки подлинности. В следующей таблице показаны зоны, пользователи и тип проверки подлинности, проиллюстрированные для фермы публикаций.
.gif "Таблица, содержащая сведения о зонах, пользователях и проверке подлинности.")
И в этом случае для учетной записи обхода контента при поиске требуется доступ как минимум к одной зоне, использующей проверку подлинности NTLM. В случае необходимости проверку подлинности NTLM можно добавить в зону проверки подлинности на основе утверждений. В классическом режиме, если ни одна из зон для пользователей не настроена для использования NTLM, настройте специальную зону для использования проверки подлинности NTLM.
Зоны
Для успешного развертывания на этапе разработки зон большую важность имеет ряд ключевых решений. К таковым относятся решения по разработке и настройке следующих зон:
Зона по умолчанию
Зоны для внешнего доступа
В следующих разделах описаны решения, включенные в пример разработки.
Требования к настройке зоны по умолчанию
Больше всего внимания требуется уделить настройке зоны "По умолчанию". В SharePoint Server 2010 предъявляются следующие требования по настройке зоны "По умолчанию":
Когда запрос пользователя не может быть соотнесен с зоной, применяется проверка подлинности и политики зоны "По умолчанию". Следовательно, зона "По умолчанию" должна быть наиболее безопасной.
Административная электронная почта, включая сообщения для владельцев сайтов, почти исчерпавших квоту, отправляется со ссылками из зоны по умолчанию. Таким образом, пользователи, которые получают такие типы сообщений электронной почты и предупреждений, должны иметь возможность получить доступ к ссылкам через зону по умолчанию. Это особенно важно для владельцев сайтов.
Именованные семейства сайтов доступны только в зоне по умолчанию. Все пользователи, которым назначен доступ к именованным семействам сайтов, должны иметь доступ к зоне по умолчанию.
Настройка зон для среды экстрасети
В среде экстрасети разработка зон крайне важна по следующим причинам:
Запросы пользователей могут быть инициированы из нескольких разных сетей. В примере разработки пользователи инициируют запросы из внутренней сети, Интернета и партнерских компаний.
Пользователи используют контент нескольких веб-приложений. В примере разработки интрасеть состоит из трех разных веб-приложений. Кроме того, внутренние и удаленные сотрудники могут потенциально участвовать в администрировании контента во всех веб-приложениях: интрасети, веб-приложении для партнеров и интернет-сайте компании.
Убедитесь, что в среде экстрасети соблюдены следующие принципы разработки:
Зоны нескольких веб-приложений должны быть настроены так, чтобы они зеркально отражали друг друга. Настройки проверки подлинности и назначения пользователей должны быть одинаковы, но политики, связанные с зонами, могут отличаться для разных веб-приложений. Например, необходимо обеспечить, чтобы зона интрасети использовалась одними и теми же сотрудниками во всех веб-приложениях. Другими словами, нельзя настраивать зону интрасети в одном веб-приложении для внутренних сотрудников, а в другом — для удаленных сотрудников.
Альтернативные сопоставления доступа для каждой зоны и каждого ресурса должны быть настроены правильно и точно. Альтернативные сопоставления доступа создаются автоматически при создании зоны. Однако SharePoint Server 2010 можно настроить для обхода контента во внешних ресурсах, например в общей папке. Ссылки на эти внешние ресурсы должны быть созданы вручную для каждой зоны с помощью альтернативных сопоставлений доступа.
Если зоны в веб-приложениях не отражают зеркально друг друга и ссылки на внешние ресурсы некорректны, существуют следующие риски:
Имена серверов, DNS-имена и IP-адреса потенциально могут предоставляться извне внутренней сети.
Пользователи не смогут получить доступ к веб-сайтам и другим ресурсам.
Службы
Иллюстрируемая архитектура служб показывает наиболее сложный вариант для развертывания служб в трех разных типах сайтов: интрасети, веб-приложении для партнеров и интернет-сайте компании. Выделенные и секционированные службы развертываются для партнерского веб-сайта. Отдельный экземпляр приложения-службы управляемых метаданных развертывается исключительно для разработки семейства сайтов и интернет-сайта публикаций.
Гораздо более простой альтернативой является развертывание одного набора приложений-служб и совместное использование всех служб между сайтами по мере необходимости. Эта архитектура основана на фильтрации по ролям безопасности для отображения только того контента, к которому пользователи имеют доступ. Следующая диаграмма иллюстрирует этот упрощенный подход.
.gif "Планирование архитектуры служб")
Основное решение по разработке, которое требуется принять при развертывании приложений-служб касается степени распространения таксономии организации. Архитектуру служб можно упростить при совместном использовании управляемых метаданных, профиля пользователя и поиска по всем веб-приложениям, а также использовании фильтрации по ролям безопасности для управления доступом к контенту. В упрощенной архитектуре, описанной в этой статье, один экземпляр службы управляемых метаданных совместно используется всеми сайтами. Однако при такой конфигурации все пользователи имеют доступ к корпоративной таксономии. Создатели решения должны решить, следует ли реализовать несколько экземпляров службы управляемых метаданных. Им также необходимо принять решение о том, насколько широким должно быть совместное использование данных профиля пользователя.
Веб-сайт для партнеров
Для партнерского веб-сайта (пользовательская группа в ферме 1) минимальными службами, определенными в примере разработки, являются службы поиска и управляемых метаданных. При добавлении Office Web Apps в группу служб, используемых партнерским веб-сайтом, убедитесь в наличии необходимых лицензий для всех пользователей этого веб-сайта, включая партнеров. Приложение-служба профиля пользователя не включена в пример разработки, чтобы предотвратить просмотр данных сотрудников в организации, который может осуществляться пользователями партнеров.
В упрощенной архитектуре партнеры имеют доступ ко всей корпоративной таксономии и могут просматривать данные пользователей в организации. Однако поиск ограничивает результаты сайтами и контентом, к которым партнеры имеют доступ.
Если партнерские сайты требуют изоляции контента между проектами, развертывание выделенных и секционированных приложений-служб является хорошим выбором, как показано в примере разработки. Это увеличивает сложность архитектуры служб, но гарантирует, что партнеры не получат доступ к метаданным, связанным с контентом интрасети или даже с другими проектами на партнерском веб-сайте.
Интернет-сайт компании
В упрощенной архитектуре разработки приложение-служба корпоративных управляемых метаданных также используется совместно с интернет-сайтом публикаций. В примере разработки выделенный экземпляр приложения-службы управляемых метаданных разворачивается в ферме для совместной работы для исключительного использования семейством сайтов разработки и фермой публикаций.
Если ферма публикаций является анонимной и имеет доступ только для чтения, то не существует риска, связанного с открытием доступа к управляемым метаданным, не связанным с опубликованным контентом. Анонимные пользователи имеют доступ только к опубликованному контенту и не могут отправлять оценки или создавать другие типы метаданных.
Совместное использование приложения-службы управляемых метаданных в организации (как показано в упрощенной архитектуре в данной статье) позволяет авторам использовать корпоративную таксономию. Напротив, развертывание выделенного экземпляра службы для разработки и публикации (показанное в примере разработки) гарантирует изоляцию управляемых метаданных.
Выделенный экземпляр приложения службы поиска разворачивается в ферме, в которой размещается интернет-сайт компании. Это рекомендуемая конфигурация для сайта публикаций с выходом в Интернет.
Альтернативы разработке и публикации
Для интернет-сайта компании в примере разработки иллюстрируется процесс публикации, который включает использование функции развертывания контента для перемещения контента из семейства сайтов разработки в ферму публикации. Более простой альтернативой такому подходу является разработка непосредственно на ферме публикации. Такой способ обычно называется разработкой в рабочей среде.
Разработка в рабочей среде значительно упрощает решение, консолидируя службы в одной ферме и устраняя необходимость развертывания контента. Пример разработки включает дополнительные зоны, которые могут использоваться авторами для безопасной работы без влияния на анонимных пользователей. Не забудьте заблокировать входящий анонимный доступ на порте, связанном с зонами, которые используются авторами. Если активность разработки на сайте не превышает 500 записей в час, вероятнее всего производительность сайта публикаций не пострадает при разработке в рабочей среде.
В SharePoint Server 2010 включены функции публикации, которые можно использовать в этом сценарии, чтобы обеспечить недоступность контента для анонимных пользователей до тех пор, пока он не буде готов. Дополнительные сведения см. в следующих статьях, посвященных:
планированию даты начала и завершения для опубликованной страницы (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x419) (Возможно, на английском языке)
утверждению или отклонению отложенной отправки (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x419)
настройке разрешений для публикации (Возможно, на английском языке) (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x419) (Возможно, на английском языке)
Сайты администрирования
В примере разработки сайты центра администрирования для всех ферм серверов размещаются на сервере приложений. Это защищает сайты от прямого контакта с пользователем. Если возникновение узкого места производительности или нарушение безопасности негативно сказывается на доступности интерфейсных серверов, сайт центра администрирования остается доступным.
URL-адреса с балансировкой нагрузки для сайтов администрирования не упоминаются в примере разработки или в данной статье. Соответствующие рекомендации состоят в следующем:
Если в административных URL-адресах используются номера портов, используйте нестандартные порты. Номера портов включаются в URL-адреса по умолчанию. Несмотря на то, что обычно номера портов не используются в клиентских URL-адресах, использование номеров портов для сайтов администрирования может повысить безопасность, ограничив возможность доступа к этим сайтам только использованием нестандартных портов.
Создайте отдельные записи DNS для сайтов администрирования.
В дополнение к этим рекомендациям можно при желании сбалансировать нагрузку сайта центра администрирования между несколькими серверами, чтобы добиться избыточности.
Пулы приложений
Отдельные пулы приложений IIS обычно реализуются для достижения изоляции процесса от контента. Пулы приложений позволяют нескольким сайтам выполняться на одном сервере, но в то же время иметь свои собственные рабочие процессы и удостоверения. Это устраняет наличие эксплойта, который позволяет злоумышленнику с одного из сайтов внедрить код на сервер для атаки других сайтов.
На практике следует предусмотреть использование выделенного пула приложений в следующих сценариях:
Отделение контента, прошедшего проверку подлинности, от анонимного контента.
Изоляция приложений, сохраняющих пароли внешних бизнес-приложений и взаимодействующих с этими приложениями (хотя для этой цели можно использовать службу безопасного хранения).
Изоляция приложений, в которых пользователи имеют большую свободу действий для создания и администрирования сайтов и совместной работы над контентом.
В примере разработки пулы приложений используются следующим образом:
Каждый сайт администрирования размещается в выделенном пуле приложений. Это требование Продукты SharePoint 2010.
Контент интрасети разделен на два разных пула приложений. Контент для совместной работы (личные сайты и сайты рабочих групп) размещается в одном пуле приложений. Опубликованный контент интрасети размещается в отдельном пуле приложений. Такая конфигурация обеспечивает изоляцию процессов для опубликованного контента интрасети, в которых более вероятно использование подключений к бизнес-данным.
Веб-приложение для партнеров размещается в выделенном пуле приложений.
Интернет-сайт компании размещается в выделенном пуле приложений на второй ферме. Если эта ферма должна также размещать контент для совместной работы с партнерами, эти два типа контента (интернет-контент и партнерский контент) должны размещаться в разных пулах приложений.
Веб-приложения
Веб-приложение — это веб-сайт IIS, созданный и используемый Продукты SharePoint 2010. Каждое веб-приложение представлено отдельным веб-сайтом в IIS.
Основной сферой применения выделенных веб-приложений являются следующие задачи:
Отделение анонимного контента от контента, прошедшего проверку подлинности. В примере разработки интернет-сайт компании размещается в выделенном веб-приложении и пуле приложений.
Изолирование пользователей. В примере разработки веб-сайт для партнеров размещается в выделенном веб-приложении и пуле приложений, чтобы гарантировать недоступность контента интрасети для партнеров.
Обеспечение разрешений. Выделенное веб-приложение предоставляет возможность для обеспечения разрешений политиками с помощью страницы "Политика для веб-приложения" в центре администрирования. Например, на интернет-сайте компании можно создать политику для явного запрета доступа на запись одной или нескольким группам пользователей. Политики для веб-приложения обеспечиваются независимо от разрешений, настроенных для отдельных сайтов или документов в рамках веб-приложения.
Оптимизация производительности. Производительность приложений можно повысить, разместив их в веб-приложениях вместе с другими приложениями со схожими характеристиками данных. Например, группа личных сайтов обычно характеризуется большим количеством сайтов небольшого размера. С другой стороны, сайты рабочих групп обычно состоят из небольшого количества очень крупных сайтов. Если разместить эти два разных типа сайтов в раздельных веб-приложениях, то конечные базы данных будут состоять из данных со схожими характеристиками, что оптимизирует производительность базы данных. В примере разработки личные сайты и сайты рабочих групп не имеют уникальных требований к изоляции данных — они совместно используют один пул приложений. Однако личные сайты и сайты рабочих групп размещены в отдельных веб-приложениях для оптимизации производительности.
Оптимизация управляемости. Поскольку создание раздельных веб-приложений предполагает наличие отдельных сайтов и баз данных, то можно реализовать различные ограничения сайта (для корзины, сроков давности и размера), а также согласовать различные соглашения об уровне обслуживания. Например, можно предусмотреть больше времени для возможности восстановления контента личного сайта, если это не самый критичный тип контента в организации. Это позволит восстанавливать более важный контент до восстановления контента личных сайтов. В примере разработки личные сайты размещены в отдельном веб-приложении, что позволяет администраторам более активно управлять ростом системы по сравнению с другими приложениями.
Семейства сайтов
Семейства сайтов объединяют логическую и информационную архитектуру. В примере разработки целью разработки семейств сайтов является обеспечение соответствия требованиям для разработки URL-адресов и создание логических подразделов контента.
Для соответствия требованиям разработки URL-адресов каждое веб-приложение включает одно семейство сайтов корневого уровня. Управляемые пути используются для включения второго уровня семейств сайтов верхнего уровня. Дополнительные сведения о требованиях к URL-адресам и использовании управляемых путей см. в разделе "Зоны и URL-адреса" далее в этой статье. После второго уровня семейств сайтов все сайты являются дочерними.
Следующая диаграмма иллюстрирует иерархию сайтов рабочих групп.
.gif "Сайты рабочей группы")
При заданном требовании для семейства сайтов корневого уровня решения по разработке так или иначе связаны со вторым уровнем семейств сайтов. Пример разработки включает варианты, основанные на характере приложения.
Опубликованный контент интрасети
Для веб-приложения опубликованного контента интрасети предполагается, что несколько подразделений в компании будут размещать опубликованный контент. В примере разработки контент каждого подразделения размещается в отдельном семействе сайтов. Это обеспечивает следующие преимущества:
Каждое подразделение может управлять своим контентом и разрешениями независимо.
Контент каждого подразделения может храниться в выделенной базе данных.
Недостатки использования нескольких семейств сайтов состоят в следующем:
Главные страницы, макеты страниц, шаблоны, веб-части и навигация не могут совместно использоваться семействами сайтов.
Требуется больше усилий для координации настроек и навигации между семействами сайтов.
В зависимости от информационной архитектуры и особенностей проектирования приложения интрасети опубликованный контент может отображаться для пользователей как единое приложение. Или же каждое семейство сайтов может отображаться как отдельный веб-сайт.
Личные сайты
Личные сайты имеют особые характеристики, и рекомендации по развертыванию личных сайтов весьма просты. В примере разработки приложение личных сайтов включает сайт верхнего уровня с URL-адресом http://my. Первое семейство сайтов верхнего уровня создается с помощью шаблона "Расположение личных узлов". Включается управляемый путь (с использованием подстановочных знаков), который позволяет разместить неограниченное число пользовательских сайтов. Все сайты на более низких уровнях относительно управляемого пути являются независимыми семействами сайтов, которые наследуют шаблон "Узел личных сайтов". Имя пользователя добавляется к URL-адресу в виде http://my personal/имя_пользователя. На следующей иллюстрации показаны личные сайты.
.gif "Личные сайты")
Сайты группы
Для разработки семейств сайтов в приложении сайта группы можно использовать один из следующих двух подходов:
Позволить группам создавать семейства сайтов через самостоятельное создание сайтов. Преимущество такого подхода заключается в том, что группы могут легко создавать сайты по мере необходимости без помощи администратора. Однако у этого подхода существует множество недостатков, например следующие:
Теряется возможность реализации содержательной таксономии.
Приложение может стать трудноуправляемым.
Сайты могут не использоваться.
Невозможно совместно использовать шаблоны и навигацию между проектами или группами, которые могут альтернативным образом совместно использовать семейство сайтов.
Создать для организации определенное количество семейств сайтов с учетом методов работы организации. При таком подходе семейства сайтов создаются администратором SharePoint. После создания семейства сайтов группы могут создавать сайты в семействе в соответствии со своими нуждами. Этот подход обеспечивает возможность реализации содержательной таксономии, которая предоставляет структуру для управления и расширения сайтов групп. Также существует больше возможностей для совместного использования шаблонов и навигации между проектами и группами, которые совместно используют семейство сайтов.
Пример разработки включает второй подход, что приводит к созданию иерархии семейства сайтов групп, подобной иерархии для опубликованного контента интрасети. Задача информационных архитекторов состоит в создании второго уровня семейств сайтов, необходимых для организации. В следующей таблице приведены предложения для различных типов организаций.
| Тип организации | Рекомендуемая таксономия семейства сайтов |
|---|---|
Разработка продуктов |
|
Проведение исследований |
|
Высшее учебное заведение |
|
Государственное законодательное учреждение |
|
Юридический отдел компании |
|
Производство |
|
Веб-приложение для партнеров
Веб-приложение для партнеров предназначено для использования в процессе совместной работы с внешними партнерами над проектами, имеющими определенные границы или определенные сроки. Изначально сайты в веб-приложении для партнеров не предназначены для связи с другими сайтами. Требования к веб-приложению для партнеров состоят, в частности, в обеспечении следующих возможностей:
Владельцы проектов могут легко создавать сайты для совместной работы с партнерами.
Партнеры и другие участники имеют доступ только к тому проекту, над которым они работают.
Разрешениями управляют владельцы сайтов.
Результаты поиска в одном проекте не предоставляют доступ к контенту других проектов.
Администраторы могут легко идентифицировать сайты, которые больше не используются, и удалять их.
Для соответствия этим требованиям пример разработки включает семейство сайтов для каждого проекта. Таким образом достигаются следующие преимущества:
Отдельные семейства сайтов обеспечивают необходимый уровень изоляции между проектами.
Может быть реализовано самостоятельное создание сайтов.
Поскольку веб-приложение для партнеров также размещает семейства сайтов для разработки контента для интернет-сайта компании, отдельные семейства сайтов создаются для разработки и промежуточного хранения.
Интернет-сайт компании
Интернет-сайт компании включает одно семейство сайтов корневого уровня. Все сайты с более низким уровнем относительно этого семейства сайтов являются дочерними. Такая структура упрощает URL-адреса для страниц в рамках сайта. Следующая диаграмма иллюстрирует архитектуру интернет-сайта компании.
.gif "Интернет-сайт компании")
Базы данных контента
Для включения баз данных контента в разработку можно использовать следующие два подхода (пример разработки включает оба подхода):
Установить определенные размеры для баз данных контента с соответствующими порогами предупреждений, касающимися размеров. При достижении такого порога создаются новые базы данных. При таком подходе семейства сайтов автоматически добавляются к доступной базе данных (или к базам данных) только на основе указанного размера. Этот подход применяется чаще всего.
Связать семейства сайтов с определенными базами данных контента. Данный подход позволяет помещать одно или несколько семейств сайтов в отдельную базу данных, которой можно управлять независимо от остальных баз.
Чтобы связать семейства сайтов с определенными базами данных контента, можно воспользоваться следующими методами:
Используйте Windows PowerShell для создания семейства сайтов в определенной базе данных.
Выделите базу данных для одного семейства сайтов, применив следующие параметры емкости базы данных:
Число сайтов, по достижении которого выдается предупреждение, равно 1.
Максимальное число сайтов, которое может быть создано в этой базе данных = 1
Добавьте группу семейств сайтов в выделенную базу данных, выполнив следующие действия:
В веб-приложении создайте базу данных и установите ее в состояние Готово.
Все остальные базы данных установите в состояние Автономная. Пока базы данных контента автономны, новые семейства сайтов не могут создаваться. Однако существующие семейства сайтов в автономных базах данных по-прежнему доступны и для операций чтения, и для операций записи.
Создайте семейства сайтов. Они будут автоматически добавлены в базу данных.
Верните состояние Готово для всех остальных баз данных.
Опубликованный контент интрасети
Для опубликованного контента интрасети пример разработки включает одну базу данных для упрощения управления. При необходимости добавьте базы данных в соответствии с ограничениями целевых размеров.
Личные сайты
Для личных сайтов в примере разработки достигается эффективное масштабирование посредством приведения баз данных к максимальным целевым размерам. Для достижения этой цели настраиваются следующие параметры:
Максимальный объем дискового пространства, используемого сайтом: этот параметр, который настраивается на странице шаблонов квот в центре администрирования, ограничивает размер личного сайта.
Корзина второго уровня: этот параметр, который настраивается на странице "Общие параметры веб-приложений", определяет объем дополнительного пространства, выделяемого для корзины второго уровня.
Максимальное число сайтов, которое может быть создано в этой базе данных: этот параметр настраивается при создании базы данных. Рассчитайте общий допустимый размер сайтов, используя значения, указанные в двух предыдущих параметрах. Затем, на основании целевого размера каждой базы данных, определите количество сайтов, которые могут поместиться в базе данных.
В примере разработки задаются следующие параметры размеров на основании целевого объема базы данных 200 гигабайт (ГБ) и целевого размера личного сайта 1 ГБ:
Ограничение размера одного сайта = 1 ГБ
Целевой размер базы данных = 175 ГБ
Резерв для корзины второго уровня = 15%
Максимальное число сайтов = 180
Предупреждение уровня сайта = 150
При достижении значения предупреждения уровня сайта создайте новую базу данных. После создания новой базы данных новые личные сайты добавляются поочередно в новую и существующую базы данных, пока не будет достигнуто максимальное число сайтов для одной из них.
Сайты групп
Для сайтов групп в примере разработки также достигается эффективное масштабирование посредством приведения баз данных к максимальным целевым размерам. Сайты групп для большинства организаций должны быть намного больше, чем личные сайты. Пример разработки задает параметры базы данных на основании ограничения размера семейств сайтов в 30 ГБ. Выберите ограничение, подходящее для сайтов групп в вашей организации.
Другим подходом для организаций с группами, которым необходимо большое дисковое пространство, является выделение одной базы данных для каждого семейства сайтов групп верхнего уровня.
Веб-приложение для партнеров
Подобно личным сайтам, веб-приложение для партнеров достигает эффективного масштабирования посредством приведения баз данных к максимальным целевым размерам. Однако в примере разработки веб-приложение для партнеров также размещает семейство сайтов разработки для интернет-сайта компании. Следовательно, разработка базы данных включает оба подхода:
Семейство сайтов для разработки размещается в выделенной базе данных.
Параметры базы данных и размеров настраиваются для управления остальными сайтами и базами данных.
Поскольку веб-приложение для партнеров размещается в выделенном веб-приложении, можно задать ограничения размеров, которые больше подходят для созданных типов сайтов. В примере разработки задаются следующие параметры размеров:
Целевой размер базы данных = 200 ГБ
Квота хранилища на сайт = 5 ГБ
Максимальное число сайтов = 40
Семейство сайтов для разработки размещается в выделенной базе данных
Интернет-сайт компании
При использовании одного семейства сайтов в разработке интернет-сайта компании используется одна база данных для этого веб-приложения.
Зоны и URL-адреса
В примере разработки показывается, как согласовать URL-адреса между несколькими приложениями при корпоративном развертывании.
Цели разработки
На решения по разработкам, касающимся URL-адресов, влияют следующие цели:
Имена URL-адресов не ограничивают зоны, через которые может быть получен доступ к контенту.
В примере разработки стандартные порты HTTP и HTTPS (80 и 443) могут использоваться во всех приложениях.
Номера портов не включены в URL-адреса. На практике номера портов обычно не используются в рабочих средах.
Принципы разработки
Для достижения указанных целей разработки применяются следующие принципы разработки:
Именованные семейства сайтов не используются. Обратите внимание, что именованные семейства сайтов отличаются от заголовков узлов IIS. Именованные семейства сайтов не работают с функцией альтернативных сопоставлений доступа. Альтернативные сопоставления доступа требуются для доступа к одному и тому же контенту через несколько доменных URL-адресов. Следовательно, при использовании именованных сайтов эти сайты доступны только через зону "По умолчанию".
Каждое приложение включает одно корневое семейство сайтов. Это требование касается использования альтернативных сопоставлений доступа. Если в веб-приложении требуется несколько корневых семейств сайтов и для доступа пользователей планируется использовать только зону "По умолчанию", именованные семейства сайтов являются хорошим вариантом.
Для приложений, включающих несколько семейств сайтов верхнего уровня, в которых каждое семейство представляет группу или проект верхнего уровня (например, сайты групп), пример разработки включает управляемые пути. Управляемые пути обеспечивают лучшее управление URL-адресами для этих типов сайтов.
Компромиссные решения разработки
Достижение целей разработки приводит к некоторым компромиссным решениям, включая следующие:
Используются более длинные URL-адреса.
Именованные семейства сайтов не используются.
Разработка URL-адресов со сбалансированной нагрузкой
При создании веб-приложения необходимо выбрать URL-адрес со сбалансированной нагрузкой для назначения приложению. Кроме того, следует создать URL-адреса со сбалансированной нагрузкой для каждой зоны, создаваемой в веб-приложении. URL-адрес со сбалансированной нагрузкой включает протокол, схему, имя узла и порт, если используется. URL-адрес со сбалансированной нагрузкой должен быть уникальным в пределах всех веб-приложений и зон. Следовательно, для каждого приложения и каждой зоны в приложении требуется уникальный URL-адрес в пределах примера разработки.
Интрасеть
Для каждого из трех веб-приложений, из которых состоит интрасеть, требуется уникальный URL-адрес. В примере разработки целевой аудиторией для контента интрасети являются внутренние и удаленные сотрудники. В примере разработки с проверкой подлинности на основе утверждений сотрудники используют одни и те же URL-адреса для каждого из этих приложений, независимо от того, получают ли они локальный или удаленный доступ. Несмотря на то, что этот подход добавляет к разработке SharePoint уровень безопасности (весь трафик использует SSL), при таком подходе требуется либо маршрутизация внутреннего трафика через брандмауэр или шлюз вместе с удаленным трафиком, либо настройка отдельной среды DNS для разрешения внутренних запросов во внутренней сети.
Для примера разработки с классической проверкой подлинности URL-адреса для внутренних и удаленных сотрудников различны. В следующей таблице показаны URL-адреса для внутренних и удаленных сотрудников для доступа к каждому приложению в примере разработки с классической проверкой подлинности.
| Приложение | URL-адрес внутреннего сотрудника | URL-адрес удаленного сотрудника |
|---|---|---|
Опубликованный контент интрасети |
http://fabrikam |
https://intranet.fabrikam.com |
Сайты группы |
http://teams |
https://teams.fabrikam.com |
Личные сайты |
http://my |
https://my.fabrikam.com |
Веб-сайт для партнеров
В примере разработки к веб-сайту для партнеров получают доступ внутренние и удаленные сотрудники, а также сотрудники партнеров. В примере разработки с проверкой подлинности на основе утверждений все эти пользователи вводят один и тот же URL-адрес независимо от метода проверки подлинности. В примере разработки с классической проверкой подлинности разные типы пользователей вводят разные URL-адреса. Хотя и удаленные сотрудники и сотрудники партнеров получают доступ к веб-сайту для партнеров извне, используя протокол SSL (HTTPS), для каждой группы требуется свой URL-адрес, чтобы применить преимущества использования отдельных зон — т. е. разные методы проверки подлинности и разные политики зон. В следующей таблице приведены URL-адреса, которые используют внутренние и удаленные сотрудники и партнеры для доступа к веб-сайту для партнеров, как показано в примере разработки с классической проверкой подлинности.
| Зона | URL-адрес |
|---|---|
URL-адрес внутреннего сотрудника |
http://partnerweb |
URL-адрес удаленного сотрудника |
https://remotepartnerweb.fabrikam.com |
URL-адрес партнера |
https://partnerweb.fabrikam.com |
Интернет-сайт компании
Интернет-сайт компании — это общедоступный сайт и к нему может получить доступ любой пользователь с помощью URL-адреса по умолчанию, http://www.fabrikam.com. Применяются политики зоны "Интернет" (т. е. анонимный доступ и запрет записи).
Однако для поддержки задач администрирования и разработки на общедоступном сайте пример разработки включает URL-адреса для внутренних и удаленных сотрудников. Можно использовать политики для этих зон, которые гарантируют соответствующий доступ для целевых групп безопасности для задач разработки и поддержки. В примерах разработок с обоими режимами проверки подлинности используется одинаковый подход для этой фермы. В следующей таблице показаны URL-адреса для каждой зоны.
| Зона | URL-адрес |
|---|---|
URL-адрес внутреннего сотрудника |
http://fabrikamsite |
URL-адрес удаленного сотрудника |
https://fabrikamsite.fabrikam.com |
URL-адрес клиента |
http://www.fabrikam.com |
Использование явных включений и включений по шаблону для URL-путей
Определяя управляемые пути, можно указать пути для семейств сайтов в пространстве URL-имен веб-приложения. Также можно указать уникальный путь под корневым сайтом, в котором существуют одно или несколько семейств сайтов. Без использования управляемых путей все сайты, созданные ниже корневого семейства сайтов, становятся частью корневого семейства.
Можно создать два следующих типа управляемых путей:
Явное включение: семейство сайтов с явно заданным URL-адресом. Явное включение применяется только к одному семейству сайтов. Можно создать множество явных включений ниже корневого семейства сайтов. Примером URL-адреса для семейства сайтов, созданного с помощью этого метода, является URL-адрес http://fabrikam/hr. Каждый добавленный явный путь снижает производительность, поэтому рекомендуется ограничить число семейств сайтов, созданных с помощью явного включения, примерно до 20.
Включение по шаблону: путь, который добавляется к URL-адресу. Этот путь обозначает, что все сайты, указанные сразу после имени пути, являются уникальными семействами сайтов. Этот вариант обычно используется для семейств сайтов, поддерживающих самостоятельное создание, например для личных сайтов. Примером URL-адреса для семейства сайтов, созданного с помощью этого метода, является URL-адрес http://my/personal/user1.
Пример разработки включает использование обоих типов, как описано в следующих разделах.
Явные включения: опубликованный контент интрасети
В примере разработки опубликованное веб-приложение интрасети включает использование явных включений.
Опубликованный контент интрасети
В опубликованном веб-приложении контента интрасети явное включение используется для каждого дочернего сайта, например для отдела кадров, подразделений обслуживания и закупок. При необходимости каждое из этих семейств сайтов может быть связано с отдельной базой данных контента. Использование явных включений в этом примере предполагает, что в веб-приложении не созданы другие типы сайтов, в том числе включения по шаблону.
Рекомендуется ограничить число сайтов, созданных с использованием явного включения, до 20. Если для организации требуется большее число семейств сайтов, предусмотрите использование включения по шаблону или именованных семейств сайтов.
В примере разработки с классической проверкой подлинности в результате использования явных включений создаются URL-адреса, показанные в следующей таблице.
| Внутренний сотрудник (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
В этом примере корневое семейство сайтов http://fabrikam представляет домашнюю страницу интрасети по умолчанию. Этот сайт предназначен для размещения контента для пользователей.
Включения по шаблону: сайты групп, личные сайты и веб-приложение для партнеров
Сайты групп, личные сайты и веб-приложение для партнеров включают использование включения по шаблону. Включения по шаблону идеально подходят для приложений, которые позволяют пользователям создавать собственные семейства сайтов, а также для веб-приложений, которые содержат множество семейств сайтов. Включение по шаблону показывает, что следующим элементом после шаблона является корневой сайт или семейство сайтов.
Сайты групп
В приложении сайтов групп включение по шаблону используется для каждого семейства сайтов группы. Для хорошего управления рекомендуется сохранять количество сайтов групп верхнего уровня в пределах управляемого их числа. Кроме того, таксономия сайтов групп должна логически соответствовать методам работы предприятия.
В примере разработки с классической проверкой подлинности в результате использования включений по шаблону создаются URL-адреса, приведенные в следующей таблице.
| Внутренний сотрудник (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://teams/sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams/sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams/sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
В этом примере корневое семейство сайтов http://team не обязательно должно размещать контент для пользователей.
Личные сайты
Личные сайты поддерживают самостоятельное создание сайтов. Если при первом просмотре интрасети пользователь щелкнет Мой сайт, автоматически создается личный сайт для пользователя. В примере разработки личные сайты содержат включение по шаблону с именем /personal (http://my/personal). Компонент личного сайта автоматически добавляет к URL-адресу имя пользователя.
В примере разработки с классической проверкой подлинности это приводит к созданию URL-адресов, формат которых представлен в следующей таблице.
| Внутренние (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
Веб-приложение для партнеров
Веб-приложение для партнеров предназначено для облегчения создания сотрудниками безопасных сайтов для совместной работы с внешними партнерами. Для поддержки этой цели разрешается самостоятельное создание сайтов.
В примере разработки с классической проверкой подлинности веб-приложение для партнеров содержит включение по шаблону с именем /sites (http://partnerweb/sites). Это приводит к созданию URL-адресов в формате, представленном в следующей таблице.
| Внутренний сотрудник (зона интрасети) | Удаленный сотрудник (зона по умолчанию) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Партнерские участники могут получить доступ к веб-сайтам для партнеров, используя URL-адреса, приведенные в следующей таблице.
| Партнер (зона экстрасети) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
Исключением для веб-приложения для партнеров, как показано в примерах разработок, является семейство, выделенное для разработки контента для интернет-сайта компании. Для этого семейства сайтов используется явное включение. Это позволяет представить пример использования обоих типов включений в одном веб-приложении.
Политики зон
Можно создать политику для веб-приложения, чтобы обеспечить разрешения на уровне веб-приложения. Политика может быть задана для веб-приложения в целом или только для определенной зоны. Политика обеспечивает разрешения для всего контента в веб-приложении или в зоне. Разрешения политики переопределяют все параметры безопасности, которые настроены для сайтов и контента. Политику можно настраивать на основе пользователей или групп пользователей, но не на основе групп SharePoint. При добавлении или изменении политики зоны служба поиска должна повторно обойти контент сайтов для сбора новых разрешений.
Политики не используются в примере разработки с проверкой подлинности на основе утверждений для фермы совместной работы, когда в одной зоне действует несколько типов проверки подлинности. Политики реализованы в примере разработки с классической проверкой подлинности и для фермы публикаций примера разработки с проверкой подлинности на основе утверждений, когда определена проверка подлинности Windows. Для фермы публикаций использование политик добавляет дополнительный уровень безопасности между анонимными пользователями и пользователями, имеющими доступ для управления сайтами.
В примерах разработок представлены примеры нескольких политик для достижения следующих целей:
Запрет доступа на запись для опубликованного контента.
Обеспечение авторам и тест-инженерам необходимого им доступа к опубликованному контенту.