Поделиться через

Модель логической архитектуры: корпоративное развертывание

  • Статья

Содержание:

  • О модели

  • Общие задачи проекта

  • Фермы серверов

  • Пользователи, зоны и проверка подлинности

  • Поставщики общих служб

  • Сайты администрирования

  • Пулы приложений

  • Веб-приложения

  • Семейства сайтов

  • Базы данных контента

  • Зоны и URL-адреса

  • Политики зон

В данной статье приводятся практические примеры внедрения логических компонентов архитектуры для создания работоспособного проекта. Данная статья предназначена для использования в сочетании с моделью, описанной в статье Пример проекта: логическая архитектура копоративного развертывания (на английском языке) (https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x419) (на английском языке) .

Эта модель иллюстрирует стандартное корпоративное развертывание Microsoft Office SharePoint Server 2007. В этой модели применяются почти все логические компоненты архитектуры и иллюстрируется процедура внедрения этих компонентов в совокупный проект. В данной статье описываются задачи разработки модели и поясняются методы решения этих задач с помощью приведенных в модели логических компонентов архитектуры.

О модели

Данная модель иллюстрирует корпоративное развертывание в компании под вымышленным названием Fabrikam, Inc. В процедуре развертывания задействованы две серверные фермы. На одной серверной ферме размещается корпоративная интрасеть и партнерский веб-сайт. На другой ферме размещается веб-сайт компании (www.fabrikam.com).

Intranet (Интрасеть)

В состав корпоративной интрасети входят следующие приложения:

  • Опубликованное контент интрасети (например, HRweb)

  • Сайты совместно работающих групп

  • "Мои узлы"

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

  • выделяются различные функции Office SharePoint Server 2007;

  • размещаются данные с различными информационными показателями;

  • применяется отдельный профиль использования;

  • требуется отдельная стратегия управления правами доступа.

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

Использование единого поставщика общих служб объединяет эти приложения, обеспечивая:

  • навигацию по приложениям;

  • поиск в рамках предприятия;

  • совместный доступ к информации профилей.

На указанном далее рисунке отображены три приложения, формирующих корпоративную интрасеть.

Логическая архитектура для корпоративной модели

Партнерская сеть

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

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

    • Обзорный поиск только по уровню сайта.

    • Запрет навигации по семействам сайтов.

    • Запрет на общий доступ к информации профилей по семействам сайтов.

  • **Раздельная проверка подлинности учетных записей партнеров   **Учетные записи партнеров управляются посредством проверки подлинности на основе форм. Учетные записи партнеров не добавляются в корпоративный каталог.

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

В этой модели приложение партнерской сети размещается на той же ферме, что и контент интрасети.

Веб-сайт компании

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

  • Изоляция контента   У клиентов нет прав доступа к другим типам контента, размещенным на серверной ферме.

  • Целевое управление   Предоставляется доступ с проверкой подлинности для сотрудников, управляющих веб-сайтов, включая задачи администрирования и разработки.

  • Защищенная разработка и публикация контента   Разделенные семейства сайтов размещаются на ферме А в приложении партнерской сети для разработки и тестирования. Это обеспечивает безопасность совместной работы и разработки контента с участием как внутренних, так и удаленных сотрудников, а также партнеров-редакторов, специализирующихся в разработке веб-сайтов или контента. Настройки публикации контента позволяют автоматически публиковать контент из семейства сайтов разработки в промежуточное семейство сайтов (на ферме А), а из промежуточного семейства сайтов на ферме А в рабочее семейство сайтов на ферме Б. Процедура публикации отображена на следующем рисунке.

Логическая архитектура фермы — модель публикации

Общие задачи проекта

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

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

  • Создание платформы для разработки потенциально развивающейся среды. Решения по разработке отдельных приложений не препятствуют добавлению других приложений. Например, в состав исходного развертывания могут входить только сайты группы совместной работы или только три приложения, составляющие интрасеть (сайты групп, личные сайты и опубликованное контент интрасети). Используя аналогичную логическую структуру архитектуры, можно добавлять приложения в решения без воздействия на структуру исходных приложений. Другими словами, разработка не подразумевает выбора структуры, ограничивающей использование среды.

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

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

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

Серверные фермы

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

Требования лицензирования

Примечание

Согласно прежним требованиям лицензирования необходимо было иметь минимум два сервера для размещения контента интрасети и веб-сайтов (по одному серверу на каждый тип лицензии). Это требование теперь не действует. Этот раздел обновлен с учетом новых требований лицензирования, внедренных в сентябре 2008 года.

Для Office SharePoint Server 2007 предоставляется две лицензии на серверы. Эти лицензии могут применяться к одному серверу или одной серверной ферме:

  • Лицензия на сервер Microsoft Office SharePoint Server 2007   Эта лицензия предназначена для контента интрасети, и для нее требуется использование клиентских лицензий. В случае создания сайтов для совместной работы с партнерами необходимо купить соответствующее число клиентских лицензий для сотрудников партнеров.

  • **Microsoft Office SharePoint Server 2007 для веб-сайтов   **Эта лицензия предназначена только для веб-сайтов, доступных в Интернете. Для этой лицензии не требуются клиентские лицензии. В случае создания сайтов для совместной работы с партнерами не требуется покупать дополнительные клиентские лицензии. Однако нельзя создавать сайты, предназначенные исключительно для использования сотрудниками компании.

Если планируется развернуть внутренний контент организации и доступный из Интернета контент для посторонних лиц на одной ферме, придется купить лицензии обоих типов. С учетом возможных вариантов развертывания клиенты, желающие консолидировать свои потребности Office SharePoint Server 2007 в одном развертывании, могут купить лицензии на оба продукта, присвоить их одному и тому же серверу и использовать один и тот же запущенный экземпляр программного обеспечения по обеим лицензиям одновременно. При этом они должны приобрести необходимые CAL в соответствии с правами на использование Office SharePoint Server 2007 для пользователей и устройств, подключающихся к контенту методом, не разрешенным в соответствии с правами на использование Office SharePoint Server 2007 для Интернет-сайтов.

Дополнительные сведения о влиянии требований лицензирования на количество требуемых ферм серверов см. в разделе Планирование ферм серверов.

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

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

  • Характер совместной работы   Если главной задачей сайта партнерской экстрасети является защищенный обмен информацией с большим количеством партнеров, то наиболее экономичным вариантом является серверная ферма Интернета. С другой стороны, если главной задачей является сотрудничество с небольшим количеством сотрудников партнеров, то предпочтительнее выбрать серверную ферму интрасети. Выбирайте вариант, который позволит оптимизировать ферму для предполагаемой роли (которой является совместная работа или предоставление контента с разрешением только на чтение).

  • Количество сотрудников партнеров   Если осуществляется совместная работа с большим количеством сотрудников партнеров и важно минимизировать затраты, то на ферме, подключенной к Интернету и использующей лицензии веб-сайтов, можно безопасно разместить как контент, предназначенный для совместной работы, так и анонимный контент.

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

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

Топология серверных ферм

В этой модели каждая серверная ферма состоит из пяти серверов со следующей топологией:

  • Два интерфейсных веб-сервера

  • Один сервер приложений

  • Два сервера баз данных с кластеризацией или дублированием.

В этой модели описывается логическая архитектура Office SharePoint Server 2007 с отображением следующих характеристик:

  • Все сайты дублируются на интерфейсных веб-серверах.

  • Сайт центра администрирования установлен на сервере приложений для защиты сервера приложений от непосредственного доступа пользователей.

На практике число серверов и топология серверных ферм не представляют значимости для логической архитектуры, за исключением увеличения емкости и производительности при необходимости. Логическую архитектуру можно создать независимо от топологии серверных ферм. Процедура планирования производительности и емкости помогает определить размер серверной фермы в соответствии с задачами производительности и емкости. Дополнительные сведения см. в разделе Планирование производительности и мощности (Office SharePoint Server).

Пользователи, зоны и проверка подлинности

В этой модели описываются пять различных классов пользователей, для каждого из которых определена отдельная зона. В каждом веб-приложении можно создать до пяти зон с одним из доступных имен: "По умолчанию", "Интрасеть", "Интернет", "Специальная" или "Экстрасеть". Ферма, на которой размещается более одного веб-приложения, может поддерживать пользовательские запросы из более чем пяти зон сети (до пяти зон на каждое веб-приложение). Однако в модели приведено только пять зон.

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

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

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

Custom (Настраиваемая)

Администраторы

Kerberos (встроенная проверка подлинности Windows)

Intranet (Интрасеть)

Внутренние сотрудники

NTLM (встроенная проверка подлинности Windows)

Default (По умолчанию)

Удаленные сотрудники

NTLM (встроенная проверка подлинности Windows) или проверка подлинности на основе форм по протоколу LDAP.

Extranet (Экстрасеть)

Сотрудники партнеров

Проверка подлинности через формы

Internet (Интернет)

Заказчики

Анонимный

В этой модели не все пользователи получили доступ к обеим серверным фермам. Соответственно, ни одна из ферм не использует все пять зон.

Администраторы

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

  • Внедрение независимого набора URL-адресов и политик. Например, администраторы могут использовать URL-адреса, связанные с настраиваемой зоной, для выполнения задач администрирования в соответствии с политиками зоны. Также администраторы могут использовать URL-адреса интрасети для все остальных задач в соответствии с политиками, настроенными для приложений, составляющих интрасеть. Такой подход разделяет два типа контента и обеспечивает отсутствие конфликтов между разрешениями политик.

  • Внедрение более безопасного метода проверки подлинности для администраторов. Таким образом обеспечивается более высокий уровень безопасности для решения в целом.

  • Проверка подлинности через другого поставщика в случаях, когда поддержка сайтов осуществляется внешним поставщиком.

В этой модели предполагается, что администраторы являются сотрудниками компании Fabrikam и используют внутренний доступ к сети. Также предполагается использование встроенной проверки подлинности Windows для администраторов (проверка подлинности Kerberos или NTLM).

Внутренние сотрудники

Для доступа внутренних сотрудников используется зона интрасети. Применяется встроенная проверка подлинности Windows.

Удаленные сотрудники

Для удаленных сотрудников используется зона по умолчанию. Задачи разработки модели:

  • Проверка подлинности посредством внутренней среды службы каталогов Active Directory.

  • Упрощение управления разрешениями при помощи проверки подлинности Windows как для внутренних, так и для удаленных сотрудников. Эта задача очень важна, поскольку если пользователи подключаются к сайтам через двух разных поставщиков проверки подлинности, то Office SharePoint Server 2007 создает две разных учетных записи для каждого пользователя. Причем для каждой из этих двух учетных записей необходимо установить разрешения.

В этой модели представлены два варианта проверки подлинности для удаленных сотрудников. В первом варианте (встроенная проверка подлинности Windows с использованием NTLM) выполняются обе задачи разработки. Во втором варианте (проверка подлинности на основе форм) выполнима только первая задача. Соответственно, предпочтительным является первый вариант.

В следующей таблице приведены сводные данные о различиях между этими двумя подходами.

Метод проверки подлинности Встроенная проверка подлинности Windows с использованием NTLM Проверка подлинности на основе форм по протоколу LDAP

Как это работает

Данный метод основан на использовании серверов ISA Server 2006 или Intelligent Application Gateway (IAG 2007) для проверки подлинности пользователей и последующей отправки учетных данных пользователей в Office SharePoint Server 2007. Эти серверы применяют проверку подлинности через формы для проверки пользователей в среде Active Directory. Затем они направляют учетные данные Windows в Office SharePoint Server 2007. Дополнительные сведения см. в следующих статьях.

Поскольку данная зона является зоной по умолчанию, то для выполнения требования компонента индексирования используется проверка подлинности NTLM. Дополнительные сведения см. в разделе "Требования к конфигурации зоны по умолчанию" далее в данной статье.

Office SharePoint Server 2007 использует проверку подлинности на основе форм по протоколу LDAP для проверки подлинности удаленных сотрудников во внутренней среде Active Directory.

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

Достоинства

Office SharePoint Server 2007 не создает двух разных учетных записей для пользователей, работающих и внутри компании, и удаленно. Таким образом управление разрешениями значительно упрощается.

Для проверки подлинности пользователей и направления учетных данных не требуется прокси-сервер.

Недостатки

Требуется дополнительное согласование и настройка ISA Server 2006 или другого прокси-серверного продукта.

Если пользователь подключается к Office SharePoint Server 2007 и внутри компании, и удаленно, то в Office SharePoint Server 2007 создается две разные учетные записи. Соответственно, для обеих учетных записей необходимы разрешения на доступ к сайтам и документам. Потенциально сотрудник может создавать два личных сайта. Если сотрудник планирует работать и внутри сети, и удаленно, то ему необходимо управлять разрешениями на доступ к собственным сайтам и документам из обеих учетных записей.

Сотрудники партнеров

Сотрудники партнеров получают доступ к сети через зону экстрасети, а проверка их подлинности осуществляется на основе форм. Для хранения учетных записей партнеров в экстрасети требуется отдельный каталог и поставщик, например база данных и поставщик Microsoft SQL Server. Преимуществом данного подхода является возможность раздельного управления учетными записями партнеров и отсутствие необходимости в добавлении учетных записей партнеров в каталог внутренних сотрудников.

В качестве альтернативы можно воспользоваться технологией единого входа в Интернете (SSO) для проверки подлинности через собственный каталог партнера. Однако при данном подходе требуется отдельная зона для каждого партнерского каталога.

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

Заказчики

Для доступа клиентов используется зона Интернета. Эта зона настраивается на разрешение анонимного доступа с доступом только для чтения.

Зоны

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

  • Зона по умолчанию.

  • Зоны для внешнего доступа.

В следующих разделах описаны решения, внедренные в модели.

Требования к конфигурации зоны по умолчанию

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

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

  • Для обхода контента компонент индексирования требует доступа к контенту по крайней мере одной зоны. По умолчанию компонент индексирования использует проверку подлинности NTLM. Администратор SSP может настроить правила обхода, чтобы использовать при обходе определенного диапазона URL-адресов либо базовую проверку подлинности, либо клиентский сертификат. Соответственно, для обхода контента необходимо настроить не менее одной зоны на проверку подлинности NTLM, базовую проверку подлинности или сертификаты. Кроме того, обходчик будет проверять зоны в указанном порядке до тех пор, пока не обнаружит зону, через которую он сможет осуществить проверку подлинности: зону по умолчанию, зону интрасети, зону Интернета, настраиваемую зону или зону экстрасети. Однако если обходчик сначала обнаружит зону, которая настроена на использование проверки подлинности Kerberos, то обходчик не будет проверять ее подлинность и не произведет попытки доступа к следующей зоне. Поэтому удостоверьтесь, что настройка зон, использующих проверку подлинности Kerberos, не остановит индексирование компонентов обходчиком. Дополнительные сведения о требованиях проверки подлинности, связанных с обходом контента, см. в статье Планирование способов проверки подлинности (Office SharePoint Server).

  • Административная электронная почта отправляется со ссылками от зоны по умолчанию. Это относится и к электронной почте для владельцев сайтов, которые почти исчерпали квоту. Соответственно, пользователи, получающие этот тип электронной почты и предупреждения, должны иметь возможность открыть ссылки через зону по умолчанию. Это особенно важно для владельцев сайтов.

  • Именованные семейства сайтов доступны только в зоне по умолчанию. Все пользователи, которым назначен доступ к именованным семействам сайтов, должны иметь доступ к зоне по умолчанию.

В этой модели для доступа удаленных сотрудников применяется зона по умолчанию, что вызвано следующими причинами:

  • Сотрудники могут открывать ссылки, содержащиеся в административной электронной почте, независимо от своего местоположения.

  • Имена и URL-адреса внутренних серверов защищены от раскрытия, если невозможно определить зону, связанную с пользовательским запросом. Поскольку зона по умолчанию уже настроена для удаленных сотрудников, то при применении этой зоны в URL-адресах не указывается важных данных.

Настройка зон для среды экстрасети

Разработка зон в среде экстрасети крайне важна по следующим двум причинам:

  • Пользовательские запросы можно инициировать из нескольких различных сетей. В этой модели пользователи инициируют запросы из внутренней сети, из Интернета и из партнерских компаний.

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

Убедитесь, что в среде экстрасети соблюдены следующие принципы разработки:

  • Настройте зоны группы веб-приложений так, чтобы они были согласованы друг с другом. Настройки проверки подлинности и назначения пользователей должны быть одинаковы. Однако политика, связанная с зонами, может отличаться для разных веб-приложений. Например, убедитесь, что зона интрасети используется для одних и тех же сотрудников во всех веб-приложениях. Другими словами, не настраивайте зону интрасети в одном веб-приложении для внутренних сотрудников, а в другом — для удаленных сотрудников.

  • Альтернативные сопоставления доступа для каждой зоны и каждого ресурса должны быть настроены корректно и точно.

В этой модели зона по умолчанию для каждого веб-приложения настроена одинаково применительно к доступу удаленных сотрудников. Кроме того, зона интрасети настроена одинаково во всех веб-приложениях для доступа внутренних сотрудников. Зона экстрасети и зона Интернета одинаково настроены только для одного веб-приложения каждая.

Альтернативные сопоставления доступа автоматически создаются при создании зоны. Однако можно настроить Office SharePoint Server 2007 для обхода контента внешних ресурсов, например файлового хранилища. Ссылки на эти внешние ресурсы необходимо создавать вручную для каждой зоны, используя альтернативные сопоставления доступа. Например, файловое хранилище можно открыть для внутренних пользователей с внутренним URL-адресом (file://). Это же файловое хранилище можно открыть в качестве FTP-ссылки для внешних пользователей (ftp://). Таким образом обеспечивается доступность данных ресурсов пользователям в соответствии с контекстом их зон. Когда пользователи получают ссылки на эти ресурсы в результатах поиска, ссылки доступны.

Если зоны веб-приложений не дублируют друг друга, а ссылки на внешние ресурсы некорректны, то возможны следующие риски:

  • Имена серверов, имена системы доменных имен (DNS) и IP-адреса могут потенциально открываться вне внутренней сети.

  • У пользователей может отсутствовать доступ к веб-сайтам и другим ресурсам.

Поставщики общих служб

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

  • службы личной настройки;

  • аудитории;

  • каталог бизнес-данных;

  • службы Excel;

  • Служба поиска Office SharePoint Server

  • отчеты об использовании портала.

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

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

  • Intranet (Интрасеть)

  • Партнерская сеть

  • Клиентский веб-сайт

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

Intranet (Интрасеть)

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

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

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

    Архитектура поставщика общих служб

Партнерская сеть

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

  • Ограничение результатов поиска отдельными семействами сайтов.

  • Использование аудиторий для указанного контента и определенных групп пользователей.

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

    Для включения этой конфигурации воспользуйтесь командой

    Stsadm.exe -o setproperty –url https://server/ –pn "peoplepicker-onlysearchwithinsitecollection" –pv yes

    Для выключения этой конфигурации воспользуйтесь командой

    Stsadm.exe -o setproperty –url https://server/ –pn "peoplepicker-onlysearchwithinsitecollection" –pv no

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

  • ограничение доступа к сайтам для определенных пользователей или групп.

  • Использование групп SharePoint для разрешения доступа к контенту.

Веб-сайт компании

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

  • Отдельный пул приложений обеспечивает изоляцию процессов.

  • Отдельное веб-приложение обеспечивает возможность указания политик.

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

Сайты администрирования

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

  • Веб-сайты администрирования общих служб   В этой модели представлен выделенный сайт администрирования для каждого поставщика общих служб. Сайты администрирования общих служб нельзя изолировать на одном сервере или группе серверов. Эти сайты автоматически дублируются на всех интерфейсных веб-серверах.

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

В этой модели и в данной статье для сайтов администрирования не рассматриваются URL-адреса с балансом нагрузки. Рекомендации:

  • Если в административных URL-адресах используются номера портов, применяйте нестандартные порты. По умолчанию номера портов включаются в URL-адреса. Хотя номера портов обычно не используются в URL-адресах, предназначенных для клиентов, но использование номеров портов для сайтов администрирования позволяет повысить уровень безопасности путем ограничения доступа к этим сайтам по нестандартным портам.

  • Разрешение доступа к сайтам администрирования только из административного домена.

  • Создание отдельных DNS-записей для сайтов администрирования.

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

Пулы приложений

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

На практике выделенный пул приложений целесообразно использовать в следующих случаях:

  • Разделение проверенного и анонимного контента.

  • Для изолирования приложений, хранящих пароли для внешних бизнес-приложений и взаимодействующих с ними (например, для подключений к каталогу бизнес-данных).

  • Для изолирования приложений, которые предоставляют пользователям возможность создавать и администрировать сайты, а также совместно работать с контентом.

В этой модели пулы приложений используются следующим образом:

  • Каждый сайт администрирования размещается в выделенном пуле приложений. Это требование Office SharePoint Server 2007.

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

  • Приложение партнерской сети размещается в выделенном пуле приложений.

  • Веб-сайт компании размещается в выделенном пуле приложений на ферме Б. Если на данной ферме также размещается контент для совместной работы с партнерами, то эти два типа контента (веб-сайта и партнеров) будут размещены в двух разных пулах приложений.

Веб-приложения

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

Основной сферой применения выделенных веб-приложений являются следующие задачи:

  • Отделение анонимного контента от контента, прошедшего проверку подлинности. В этой модели веб-сайт компании размещается в выделенном веб-приложении и отдельном пуле приложений.

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

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

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

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

Семейства сайтов

Семейства сайтов объединяют логическую и информационную архитектуру. В этой модели задачей разработки семейств сайтов является удовлетворение потребностей в разработке URL-адресов и создание логических подразделов контента.

Для удовлетворения потребностей в разработке URL-адресов каждому веб-приложению присваивается одно семейство сайтов корневого уровня. Управляемые пути применяются для внедрения второго уровня в семействах сайтов верхнего уровня. Дополнительные сведения о требованиях URL-адресов и об использовании управляемых путей см. в разделе "Зоны и URL-адреса" далее в этой статье. Каждый сайт ниже второго уровня семейств сайтов является дочерним сайтов.

На следующем рисунке отображена иерархия сайтов групп.

Логическая архитектура для веб-сайтов совместной работы

Учитывая требование для семейства сайтов корневого уровня, решения по разработке непосредственно связаны со вторым уровнем семейств сайтов. В этой модели приведены варианты, основанные на направленности приложения.

Опубликованный контент интрасети

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

  • Каждое подразделение может независимо управлять своим контентом и указывать разрешения для него.

  • Контент каждого подразделения может храниться в выделенной базе данных.

К недостаткам использования нескольких семейств сайтов можно отнести следующее:

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

  • Для координации настроек и навигации по семействам сайтов требуется больше усилий.

В зависимости от информационной архитектуры и структуры приложения интрасети опубликованный контент может отображаться пользователю как удаленное приложение. В альтернативном варианте каждое семейство сайтов может отображаться как отдельный веб-сайт.

"Мои узлы"

У личных сайтов есть четкие характеристики, и рекомендации по развертыванию личных сайтов просты. В этой модели приложение личных сайтов использует сайт верхнего уровня с URL-адресом http://my/. Первое созданное семейство сайтов верхнего уровня применяет шаблон "My Site Host". Используется управляемый путь (путем применения включения по шаблону), что позволяет создавать неограниченное количество пользовательских сайтов. Все сайты ниже управляемого пути представляют собой независимые семейства сайтов, наследующие шаблон "My Site Host". К URL-адресу добавляется имя пользователя в формате http://my/ personal/имя_пользователя. На следующем рисунке приведен пример личных сайтов.

Логическая архитектура сети для личных веб-сайтов

Дополнительные сведения о разработке приложения для личных сайтов см. в статье Построение архитектуры личных сайтов.

Сайты группы

Для создания семейства сайтов в приложении сайта группы можно использовать один из следующих двух подходов:

  • Разрешить группам создавать семейства сайтов путем самостоятельного создания сайтов. Преимуществом данного подхода является предоставляемая группам возможность легко создавать сайты при необходимости, без помощи администратора. Однако у данного подхода есть и ряд недостатков:

    • Вы лишаетесь возможности реализации продуманной таксономии.

    • Управление приложением может оказаться непростой задачей.

    • Сайты могут быть с легкостью заброшены пользователями.

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

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

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

Тип организации Рекомендованные таксономии для семейств сайтов

Разработка продуктов

  • Создать семейство сайтов для каждого разрабатываемого продукта. Разрешить рабочим группам создавать сайты в рамках семейства сайтов.

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

Исследования

  • Создать семейство сайтов для каждого долгосрочного исследовательского проекта.

  • Создать семейство сайтов для каждой категории исследовательских проектов.

Высшее учебное заведение

  • Создать семейство сайтов для каждого учебного подразделения.

Государственный законодательный орган

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

  • Создать семейство сайтов для каждого комитета. Либо создать одно семейство сайтов для всех комитетов.

Корпоративная юридическая фирма

  • Создать семейство сайтов для каждого корпоративного клиента.

Промышленное предприятие

  • Создать семейство сайтов для каждой производственной линии.

Партнерская сеть

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

  • Владельцы проекта могут легко создавать сайты для сотрудничества с партнерами.

  • Партнеры и другие участники получают доступ только к проекту, над которым они работают.

  • Разрешениями управляют владельцы сайтов.

  • Результаты поиска по одному проекту не открывают контент других проектов.

  • Администраторы могут легко определять неиспользуемые сайты и удалять их.

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

  • Отдельные семейства сайтов предоставляют необходимый уровень изоляции между проектами.

  • Возможно внедрение возможности самостоятельного создания сайтов.

Поскольку в приложении партнерской сети также размещаются семейства сайтов для разработки контента веб-сайта компании, то для разработки и тестирования создаются отдельные семейства сайтов.

Веб-сайт компании

В веб-сайте компании содержится одно семейство сайтов корневого уровня. Все сайты, находящиеся ниже уровня этого семейства сайтов, являются дочерними сайтами. Данная структура упрощает URL-адреса для страниц сайта. На следующем рисунке отображена архитектура веб-сайта компании.

Логическая архитектура развертывания

Базы данных контента

Для внедрения баз данных контента в проект можно воспользоваться следующими двумя подходами (в модели применены оба подхода):

  • Установите определенные размеры для баз данных контента с соответствующими лимитами размеров, после достижения которых следует предупреждение. После достижении лимита и получения предупреждения создавайте новые базы данных. При таком подходе семейства сайтов автоматически добавляются к доступным базам данных, основываясь только на указанном размере.

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

Чтобы связать семейства сайтов с определенными базами данных контента, воспользуйтесь следующим методом:

  • Используйте инструмент командной строки Stsadm, чтобы создать семейство сайтов в определенной базе данных.

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

    • Число сайтов, при достижении которого выдается предупреждение = 1

    • Максимальное число сайтов, которое может быть создано в этой базе данных = 1

  • Добавьте группу семейств сайтов в выделенную базу данных, выполнив следующие действия:

    1. Создайте базу данных в веб-приложении и установите для базы данных статус Готово.

    2. Для всех остальных баз данных установите статус Отключено. Пока базы данных контента отключены, создавать новые семейства сайтов нельзя. Однако существующие семейства сайтов в отключенных базах данных по-прежнему доступны и для операций чтения, и для операций записи.

    3. Создайте семейства сайтов. Они будут автоматически добавлены в базу данных.

    4. Верните статус Готово для всех остальных баз данных.

Опубликованный контент интрасети

Для опубликованного контента интрасети в модели применяется выделенная база данных на каждое семейство сайтов подразделения.

Данный подход позволяет каждому подразделению независимо управлять соответствующим контентом.

"Мои узлы"

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

  • Максимальный объем дискового пространства, используемого сайтом   Этот параметр ограничивает размер личного сайта и находится на странице "Шаблоны квот" в центре администрирования.

  • Корзина второго уровня   Этот параметр указывает объем дополнительного дискового пространства, выделенного для корзины второго уровня. Он находится на странице "Общие параметры веб-приложения".

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

В этой модели представлены указанные далее примеры настроек размеров на основе конечного размера базы данных в 100 гигабайт (Гб) и конечного размера личного сайта в 500 мегабайт (МБ):

  • Ограничение размера сайта = 500 МБ

  • Конечный размер базы данных = 100 Гб

  • Максимальное число сайтов = 200

  • Предупреждение о размере сайта = 150

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

Дополнительные сведения о разработке настроек баз данных для личных сайтов см. в статье Построение архитектуры личных сайтов.

Сайты группы

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

Партнерская сеть

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

  • Каждое семейство сайтов разработки и тестирования размещается в выделенной базе данных.

  • Параметры базы данных и размера настраиваются для управления всеми остальными сайтами и базами данных.

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

  • Конечный размер базы данных = 100 Гб

  • Квота дискового пространства на сайт = 5 Гб

  • Максимальное число сайтов = 20

  • Семейства сайтов для разработки и тестирования размещаются в выделенных базах данных

Веб-сайт компании

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

Зоны и URL-адреса

В этой модели иллюстрируется процедура согласования URL-адресов для ряда приложений в рамках корпоративного развертывания.

Задачи разработки

На решения по разработке URL-адресов оказывают влияние следующие задачи:

  • Соглашения по URL-адресам не ограничивают зоны, через которые возможен доступ к контенту.

  • Стандартные порты HTTP и HTTPS (80 и 443) можно использовать во всех приложениях этой модели.

  • Номера портов не входят в состав URL-адресов. На практике номера портов обычно не используются в рабочей среде.

Принципы разработки

Для решения этих задач применяются следующие принципы разработки:

  • Именованные семейства сайтов не используются. Обратите внимание, что именованные семейства сайтов отличаются от заголовков сайтов IIS. Именованные семейства сайтов не поддерживают функцию альтернативного сопоставления доступа. Эта функция необходима для доступа к одному и тому же контенту через несколько URL-адресов в домене. Соответственно, при использовании именованных сайтов эти сайты доступны только через зону по умолчанию. Функция сопоставления доступа также обеспечивает поддержку внешнего завершения SSL-соединений, что позволяет сценариям доступа удаленных сотрудников и партнеров использовать протокол SSL (HTTPS).

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

  • Для приложений, включающих несколько семейств сайтов высокого уровня, где каждое семейство сайтов соответствует группе или проекту верхнего уровня (например, сайты групп), то в модели применяются управляемые пути. Управляемые пути обеспечивают значительно большие возможности управления URL-адресами для этих типов сайтов.

Компромиссные решения при разработке

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

  • URL-адреса длиннее.

  • Именованные семейства сайтов не используются.

Разработка URL-адресов с балансировкой нагрузки

При создании веб-приложения необходимо назначить веб-приложению выбранный URL-адрес с балансировкой нагрузки. Кроме того, необходимо создать URL-адрес с балансировкой нагрузки для каждой зоны, создаваемой в рамках веб-приложения. В состав URL-адреса с балансировкой нагрузки входит протокол, схема, имя узла, а также при необходимости номер порта. Каждый URL-адрес с балансировкой нагрузки должен быть уникальным для всех веб-приложений и зон. Соответственно, для каждого приложения и для каждой зоны в рамках каждого приложения требуется уникальный во всей модели URL-адрес.

Intranet (Интрасеть)

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

Приложение URL-адрес внутреннего сотрудника URL-адрес удаленного сотрудника

Опубликованный контент интрасети

http://

https://intranet.fabrikam.com/

Сайты группы

http://teams/

https://teams.fabrikam.com/

"Мои узлы"

http://my/

https://my.fabrikam.com/

Партнерская сеть

В этой модели доступ к партнерской сети используют внутренние сотрудники, удаленные сотрудники и сотрудники партнеров. Хотя и удаленные сотрудники, и сотрудники партнеров получают доступ к партнерской сети извне по протоколу SSL (https), но каждой из этих двух групп требуется свой URL-адрес для реализации преимуществ применения отдельных зон — разных методов проверки подлинности и разных политик зон. В следующей таблице перечисляются URL-адреса для доступа внутренних сотрудников, удаленных сотрудников и сотрудников партнеров к партнерской сети.

Зона URL

URL-адрес внутреннего сотрудника

http://partnerweb/

URL-адрес удаленного сотрудника

https://remotepartnerweb.fabrikam.com/

Partner 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-адреса семейства сайтов, созданного с использованием данного метода, — http://fabrikam/hr.

  • Включение по шаблону   Путь, который добавляется к URL-адресу. Этот путь обозначает, что все сайты, указанные сразу после имени сайта, являются уникальными семействами сайтов. Этот вариант обычно применяется для приложений, поддерживающих самостоятельное создание сайтов, например личных сайтов. Пример URL-адреса семейства сайтов, созданного с использованием данного метода, — http://my//personal/user1.

В этой модели предусматривается применение обоих типов включения, которые описаны в следующих разделах.

Явные включения: сайты групп и опубликованный контент интранета

В этой модели и для приложения сайтов групп, и для приложений опубликованного контента интрасети предусматривается применение явных включений.

Сайты группы

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

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

Внутренний сотрудник (зона интрасети) Удаленный сотрудник (зона по умолчанию)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

В этой примере корневое семейство сайтов, http://team,/ не обязательно содержит контент для пользователей.

Опубликованный контент интрасети

В приложении опубликованного контента интрасети явное включение применяется для каждого дочернего сайта: HR, Facilities и Purchasing. Таким образом обеспечивается независимое управление каждым из этих сайтов. Каждое из этих семейств сайтов можно при необходимости связать с отдельной базой данных для управления развитием и предоставления возможности независимого резервного копирования и восстановления данных для этих сайтов.

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

Внутренний сотрудник (зона интрасети) Удаленный сотрудник (зона по умолчанию)

http://

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,/ представляет домашнюю страницу интрасети по умолчанию. Этот сайт предназначен для размещения контента для пользователей.

Включения по шаблону: партнерская сеть и личные сайты

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

"Мои узлы"

Личные сайты предоставляют возможность самостоятельного создания сайтов. Если пользователь при просмотре интрасети сначала щелкаетМой узел, то для пользователя автоматически создается личный сайт. В этой модели личный сайт содержит включение по шаблону "/personal" (http://my//personal). Функция личного сайта автоматически добавляет к URL-адресу имя пользователя.

Таким образом формат URL-адреса соответствует приведенной далее таблице.

Внутренний (зона интрасети) Удаленный сотрудник (зона по умолчанию)

http://my//sites/user1

https://my.fabrikam.com//personal/user1

http://my//sites/user2

https://my.fabrikam.com//personal/user2

http://my//sites/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

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

URL-адреса администрирования

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

Приложение URL

Опубликованный контент интрасети

http://fabrikam.admin/

Сайты группы

http://teams/.admin/

"Мои узлы"

http://my/.admin/

Партнерская сеть

http://partnerweb/.admin/

Веб-сайт компании

http://fabrikamsite/.admin/

В этой модели предполагается, что у администраторов есть внутренний доступ к корпоративной сети.

Политики зон

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

В модели предоставляются примеры нескольких политик для достижения следующих целей:

  • Предоставить администраторам доступ ко всему контенту.

  • Запретить доступ на запись для опубликованного контента.

  • Обеспечить авторам и тестерам соответствующий доступ к опубликованному контенту.

Загрузить эту книгу

Для упрощения чтения и печати эта тема включена в следующую загружаемую книгу:

См. полный список доступных книг на веб-сайте Загружаемые материалы для Office SharePoint Server 2007.