Безопасность SharePoint: Основы безопасности развертываний SharePoint

Брайен Поузи

Даже неопытный администратор сможет за несколько часов развернуть Microsoft Office SharePoint Server 2007. Однако очень вероятно, что после этого базовая функциональность будет вполне доступной, но конфигурация не будет обеспечивать оптимальной безопасности. SharePoint Server 2007 одно из тех приложений, которые установить просто, но очень сложно сделать это правильно.

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

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

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

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

SQL Server

Все данные в списках и библиотеках SharePoint, а также большинство параметров настройки, хранятся в базе данных SQL Server. Ясно, что обязательно обезопасить SQL Server.

Экономя на оборудовании, небольшие организации часто устанавливают SQL Server и SharePoint на одном сервере. Но такая конфигурация неудачна с точки зрения как безопасности, так и производительности.

Одно из фундаментальных понятий в защите ИТ — сокращение контактной зоны. У сервера, на котором располагаются SQL Server и SharePoint, довольно большая контактная зона. Поэтому прежде всего порекомендую устанавливать SQL Server на выделенной машине. Если выделенный SQL Server «не вписывается» в бюджет, можно изолировать SQL и SharePoint, использовав виртуализацию.

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

Как же решить, что можно отключить? На помощь придет предоставляемое Microsoft Средство настройки контактной зоны сервера (Server Surface Area Configuration Tool) (рис. 1). Этот инструмент предназначен для анализа SQL Server и отключения неиспользуемых компонентов. Средство настройки контактной зоны надо выполнять после настройки и запуска SharePoint.

Чтобы запустить это средство в меню Пуск/Все программы/Microsoft SQL Server 2005/Средства настройки (Start/All Programs/Microsoft SQL Server 2005/Configuration Tools), выберите «Настройка контактной зоны SQL Server» (SQL Server Surface Area Configuration).

SQL Server surface area configuration tool

Рис. 1 Средство настройки контактной зоны SQL Server помогает выяснять компоненты и службы, которые можно отключить.

Нужно аккуратно выбирать метод проверки подлинности, чтобы гарантировать максимальную безопасность SQL Server. Среди доступных вариантов — смешанный режим или интегрированная проверка подлинности Windows.При настройке SQL Server всегда предпочтительнее второй вариант. Интегрированная проверка подлинности Windows безопаснее, чем смешанный режим, потому что в ней используется протокол проверки подлинности Kerberos. Кроме того, в проверке подлинности Windows используются доменные учетные записи пользователей, которые подчиняются всем политикам паролей, действующим в Active Directory.

Служебные учетные записи

Одна из самых больших ошибок в области безопасности, которыми часто грешат администраторы при развертывании SharePoint 2007 — неправильная настройка служебных учетных записей. Если вы когда-либо устанавливали SharePoint 2007, то знаете, что несколько раз в процессе установки и конфигурирования вам предлагается предоставить служебных учетные записи.

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

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

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

Также желательно создать специальную учетную запись пользователя исключительно для установки SharePoint и SQL Server. Обычно администраторы развертывают SharePoint, используя свою личную учетную запись или учетную запись администратора домена. Использование существующей учетной записи рискованно с точки зрения безопасности, потому как имеющиеся у этой учетной записи дополнительные права получит и процесс установщика.

Если вы решите использовать для установки выделенную учетную запись, ее придется ввести в группу локальных администраторов на каждом из серверов SharePoint, а также сделать членом группы SQL Server Logins, что позволит учетной записи входить в систему SQL Server.

Наконец, на SQL Server этой учетной записи нужно назначить роли SQL Server Database Creator и SQL Server Security Administrator, которые позволят ей создавать и изменять базы данных и управлять защитой SQL Server. Наличие этих специальных разрешений — основные рекомендации по использованию выделенной учетной записи пользователя.

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

Учетная запись доступа к базе данных. Эту учетную запись SharePoint будет использовать для подключения к базе данных SQL Server.

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

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

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

Служебная учетная запись SQL Server. Серверу SQL Server также нужна учетная запись службы и для этой цели нужно использовать выделенную учетную запись.

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

Соглашения об именах

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

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

Полное имя сервера, SharePoint, использовать не рекомендуется из-за определенных унаследованных ограничений. Windows позволяет создавать имена пользователей длиной до 100 символов, но ранее их длина была ограничена 16 символами. Возможны проблемы с более длинными именами пользователя из-за унаследованных особенностей оборудования или ПО. Это случается редко, но все-таки лучше придерживаться более коротких имен.

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

Шифрование трафика

Планируя развертывание SharePoint, администраторы тратят много времени на проектирование архитектуры серверов, но часто забывают об одном важном элементе — об инфраструктуре открытых ключей (Public Key Infrastructure, PKI). Ее нужно установить до начала развертывания SharePoint — она позволит надежно шифровать трафик SharePoint. HTTP-трафик между серверами SharePoint и конечными пользователями нужно шифровать, используя протокол SSL (то есть HTTPS).

Аналогично нужно шифровать трафик между серверами SharePoint средствами IPSec. В обоих видах шифрования используются сертификаты и имеющаяся инфраструктура PKI.

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

Брайен Поузи (Brien Posey) носит звание MPV и является независимым автором, из-под пера которого вышли тысячи статей и десятки книг. Связаться с Брайеном можно через его веб-сайт * brienposey.com*.

Материалы по теме

·       Планирование административных и служебных учетных записей (Office SharePoint Server)

·       Понимание поверхностной конфигурации

·       Пошаговое руководство по службам сертификации Active Directory