Внедрение действенных средств безопасности в среде на основе сервера Microsoft Office SharePoint Server (MOSS) 2007 может привести к значительному снижению непроизводительных затрат на управление. При этом обеспечивается возможность (о зонировании – далее в статье). Сервер MOSS 2007 содержит новейшие компоненты проверки подлинности, позволяющие обеспечить предписанный стандартами уровень безопасности в веб-системах. Для этого служат заказные поставщики, проверка подлинности на основе форм в стиле Интернета и единый вход через веб-интерфейс (SSO). Более того, сервер MOSS обеспечивает управление на детальном уровне правами доступа к таким средствам компании, как системные файлы 2007 Microsoft® Office, имеет собственные функции шифрования и частично освободить клиент от задач проверки подлинности. Далее описаны семь компонентов безопасности сервера MOSS 2007, которыми можно начать пользоваться немедленно. 1.) Подключаемый поставщик проверки подлинности. Поставщик проверки подлинности – это компонент, позволяющий проверять подлинность учетных данных пользователя. Одно из важнейших решений по безопасности в процессе организации проверки подлинности в стиле Интернета на сервере SharePoint® состоит в том, как настроить этот поставщик проверки подлинности в среде MOSS. MOSS по-прежнему поддерживает методы проверки подлинности средствами Windows®, имевшиеся в прежних версиях сервера SharePoint, в том числе, встроенную и обычную проверку подлинности (добавлена краткая проверка подлинности), что позволяет надежно соотносить пользователей с их учётными данными в Windows. Но теперь, помимо соотнесения с учетными данными в Windows, появились и другие возможности. Можно даже задействовать несколько поставщиков проверки подлинности, так что проверять подлинность при входе в систему собственных пользователей будут средства Windows, а сторонних – отдельный подключаемый поставщик. Сервер MOSS основан на среде ASP.NET 2.0, где можно задействовать подключаемые поставщики проверки подлинности. Это позволяет использовать для хранения пользовательской информации настраиваемые каталоги, по крайней мере, при наличии поставщика членства, т.е. принадлежности к группам ASP.NET 2.0 (факультативного поставщика ролей). Учетные данные подключаемого поставщика можно хешировать, шифровать или сохранять в текстовом формате, в зависимости от значений параметров узла, хранящихся в файле machine.config, соответствующем поставщику членства. Сервер MOSS рассчитан на работу с несколькими поставщиками членства, в частности LDAP V3 (входит в комплект поставки MOSS), а также поставщиками членства SQL Server™ и Active Directory®, имеющимися в среде ASP.NET 2.0. Сервер может сочетаться не только с типовыми поставщиками членства и ролей. Архитектура членства в среде ASP.NET 2.0 позволяет разрабатывать заказные поставщики на основе таких хранилищ информации о членстве, как базы данных Microsoft Access™ или Oracle, файлы XML и даже текстовые файлы. Заказной поставщик проверки подлинности наследует от интерфейса ASP.NET MembershipProvider, а тот, в свою очередь, от класса ProviderBase (см. рис. 1). Рисунок 1 Иерархия классов членства .NET Намереваясь использовать проверку подлинности на сервере MOSS средствами ASP.NET 2.0 (а не средствами Windows) следует принимать во внимание некоторые особенности. Важнее всего для многих пользователей будет ухудшение возможностей взаимодействия с клиентом Microsoft Office. Дело в том, что изначально обмен данными между клиентами MOSS и Office был рассчитан на работу с учётными записями Windows. Кроме того, некоторые службы MOSS, в особенности связанные с обходом и индексированием содержимого, вынуждены использовать учётную запись Windows даже при работе с подключаемым поставщиком. Чтобы реализовать этот режим, когда тип проверки подлинности не разрешается в учётную запись Windows, необходимо создавать дополнительную зону MOSS, где будет осуществляться проверка подлинности средствами Windows (о зонировании – далее в статье). (о зонировании – далее в статье). В некоторых случаях может быть вменена в обязанность инфраструктура открытых ключей, основанная на таких средствах, как микропроцессорные карточки. Поскольку открытые ключи или сертификаты здесь обрабатывают клиенты, обычно требуется разрешение учётной записи Windows, чтобы клиент мог, в зависимости от варианта реализации, корректно выполнить принятие сертификата и авторизацию. Для этого, в свою очередь, может потребоваться создать дополнительную зону MOSS или другую конфигурацию проверки подлинности. 2.) Проверка подлинности на основе форм и единый вход через веб-интерфейс В сервере MOSS 2007 имеется ещё один интересный механизм проверки подлинности – на основе форм, средствами ASP.NET 2.0. В предыдущих версиях SharePoint для этого требовалось либо заказное расширение ISAPI, либо расширение ISAPI CustomAuth из набора Internet Information Services (IIS) 6.0. И даже при их наличии на сервере SharePoint все равно требовалось обратное разрешение учётной записи в учётную запись пользователя Windows, что ограничивало возможности применения на периметре. Для проверки подлинности на сервере MOSS используются подключаемые поставщики проверки подлинности и ролей. Это позволяет реализовать механизмы безопасности в стиле Интернета, при которых пользователя не ставят в рамки старомодного входа в систему по приглашению, как в NT. Напротив, можно подстроиться под требования пользователей и разработать заказной процесс входа в систему. Дальнейшее повышение защищённости процесса проверки подлинности достигается тем, что файлы «cookie» проверки подлинности форм и билеты проверки подлинности зашифрованы и защищены от искажений. Поставщик учётных записей форм не обязательно устанавливать локально. Его можно подключить к внешней системе управления учётными записями, которая, в свою очередь, обеспечит и проверку учётных записей пользователей. Этот приём получил название «единый вход через веб-интерфейс». Он предполагает использование HTTP-модуля внешней проверки подлинности. С его помощью можно также осуществить федерацию учётных записей пользователей собственной компании и деловых партнёров, причём последние при проверке подлинности на сервере MOSS могут пользоваться регистрационными именами, присвоенными в их компаниях. 3.) Шифрование строк подключения приложений MOSS Включать столь ценную информацию, как строки подключения, в файл web.config «открытым текстом» – грубое нарушение правил безопасности. По этой информации пользователь может создать объектный экземпляр сервера базы данных SQL и манипулировать ценными данными. Однако в среде ASP.NET 2.0 есть функциональные возможности шифрования данных с помощью любого из двух средств: интерфейса прикладного программирования для защиты данных Windows (DPAPI) и RSA-шифрования. DPAPI осуществляет шифрование и дешифровку ключа компьютера сервера MOSS на основе встроенных в ОС Windows криптографических функций. При RSA-шифровании можно использовать алгоритмы с открытым ключом, но при этом возникает дополнительная нагрузка, поскольку для ключей необходимы соответствующие контейнеры. При использовании сервера MOSS 2007 и, более конкретно, подключаемого поставщика проверки подлинности SQL-сервера ASP.NET 2.0 желательно помещать узел <connectionStrings> в зашифрованном тексте, поскольку именно здесь возможны самые серьёзные нарушения безопасности: Code: <connectionStrings> <add name="MembershipConnectionString" connectionString="connectionString"/> </connectionStrings> Шифрование с помощью DPAPI проще и по принципу, и в реализации, поскольку в этом случае оно осуществляется собственными средствами шифрования ключа компьютера для каталога либо на виртуальном, либо на физическом уровне. Самый быстрый путь – ввести в командной строке следующие команды (хотя имеются и другие способы программной реализации шифрования): Code: aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider Поскольку главная задача состоит в шифровании узла строк соединения, можно, задав параметр раздела, зашифровать этот раздел отдельно: Code: aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider" aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider" После применения вместо узлов с секретной информацией появятся зашифрованные значения XML надлежащей формы: Code: <connectionStrings confiProtectionProvider= "EncryptionProvider"> <EncryptedData> <CipherData> <CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX </CipherValue> <CipherData> </EncryptedData> </connectionStrings> Эта модель является подключаемой, что соответствует общим свойствам архитектуры сервера MOSS. Иначе говоря, для обработки зашифрованного текста файлов конфигурации сервера MOSS, например, web.config или machine.config можно разрабатывать собственные поставщики шифрования, причём не обязательно на основе RSA или DPAPI. Шифрование, впрочем, не обходится без последствий. Поскольку для шифрования используется ключ локального компьютера, использовать этот узел конфигурации можно только на том сервере MOSS, где он был создан, в противном случае шифрование будет невозможно. Нарушитель, получивший доступ к серверу, сможет найти ключ компьютера и расшифровать строку соединения. Процесс расшифровки в незначительной степени скажется на производительности приложения в целом. 4.) Альтернативное сопоставление доступа и альтернативное сопоставление доступа по зонам весьма важны, особенно если в среде SharePoint имеется несколько точек входа. Альтернативное сопоставление доступа позволяет задать разные унифицированные указатели ресурсов (URL), через которые пользователям предоставляется доступ к одному узлу на физическом уровне (см. схему на рис. 2). Альтернативное сопоставление доступа позволяет направлять пользователей на физическом уровне на один и тот же путь к узлу MOSS, но при этом к ним будут применяться разные поставщики проверки подлинности и политики безопасности веб-приложений. К тому же, альтернативное сопоставление доступа компенсирует потери на использовании различных доменов, обратных прокси-серверов и других механизмов переадресации URL. Для указателя URL, который будет использовать сервер MOSS, сопоставление уже выполнено по умолчанию. Его можно распространить и на другие URL, которые архитектор SharePoint задаст в явном виде для целей обработки разных способов входа. Альтернативное сопоставление доступа также необходимо, чтобы обеспечить корректное сопоставление указателей URL внутренних и общедоступных ресурсов. Рисунок 2 Сопоставление указателей URL и зоны Зонирование – это новая возможность сервера MOSS, благодаря которой сопоставление узлов, осуществляемое компонентами альтернативного сопоставления доступа, становится более управляемым. Зонирование позволяет сопоставлять несколько поставщиков проверки подлинности с одним и тем же физическим путём и содержимым сервера MOSS в зависимости от того, как выполнено альтернативное сопоставление доступа для указателей URL ресурсов, через которые пользователи подключаются к содержимому. При описании сопоставления URL в режиме альтернативного сопоставления доступа привязывать зоны к механизмам проверки подлинности не обязательно, но желательно. Если в режиме альтернативного сопоставления доступа URL сопоставляется с зоной, не заданной на странице поставщиков проверки подлинности, будут использоваться настройки безопасности зоны по умолчанию. Зонирование следует планировать заранее, поскольку оно сильно сказывается на порядке проверки подлинности и маршрутизации через портал с различных URL точек входа пользователей. При расширении очередного веб-приложения можно задать желаемую зону в разделе настроек «Балансировка нагрузки URL» (см. рис. 3). Рекомендуется поместить URL ресурса, наиболее посещаемого сторонними пользователями (например, URL, который будет выставлен в Интернете), в зону по умолчанию, так как именно он будет использоваться SharePoint, когда невозможно точно определить требуемую зону. Рисунок 3 Настройка зон на сервере MOSS К каждой зоне можно привязать глобальную политику безопасности для веб-приложений, на основании которой будут определяться параметры разрешений для пользователей в этой зоне. Это позволяет организовать централизованное управление крупномасштабными изменениями разрешений. В веб-приложениях узлы зачастую объединяются в наборы, и если приложения громоздки и сложны, управление разрешениями на этих узлах может оказаться очень непростым. Применение сервера MOSS 2007 даёт возможность определять глобальные политики безопасности, на основе которых такие параметры безопасности, как полный доступ, полный доступ для чтения, доступ с запретом записи или полный запрет доступа, привязываются в приложении к конкретным пользователям или группам. Планировать настройку нужно очень тщательно, потому что глобальные политики могут иметь большую силу, чем детализированные политики, заданные на сервере MOSS, управление которыми осуществляется через интерфейс центральной администрации SharePoint. В конечном счёте, узел, доступный извне, будет иметь два указателя URL, определённые настройкой АСД: один – для входа корпоративных пользователей, второй – сторонних. Эти URL будут различаться, например, «contoso» для собственных пользователей, «extranet.contoso.com» – для доверенных партнёров. И хотя с обоими указателями URL сопоставлено одно и то же содержимое, пользователь из каждой из групп получает доступ к узлу через свою зону, а его подлинность проверяет «приписанный» к этой зоне поставщик на основе соответствующей политики безопасности приложения. Настройка зоны интрасети на внутреннем URL обеспечивает разрешение учётных записей внутренних пользователей средствами Windows на основе проверки подлинности по доменам. В то же время для партнёров осуществляется единый вход через веб-интерфейс в зону экстрасети, что позволяет им пользоваться учётными записями пользователей своих компаний. Привязка политик безопасности веб-приложений к зонам даёт значительный полезный эффект, так как позволяет предоставлять всем доверенным сторонним пользователям полный доступ для чтения, не прибегая к пообъектной настройке вручную. 5.) Целевое содержимое для безопасной совместной работы Фиксация наборов узлов на сервере SharePoint означает, что пользователи будут работать только с информацией, доступ к которой им разрешен. Новые адаптивные механизмы защиты позволяют лучше управлять информацией различных типов, хранящейся в среде MOSS. При использовании сервера MOSS 2007 можно привязать учетную запись к конкретному объекту – набору узлов, отдельному узлу, библиотеке документов, подкаталогу, списку, даже отдельному документу или позиции списка. Это позволяет детализировать управление доступом и организовать членство в явном виде на уровне объекта, так что пользователь, которому запрещён доступ, не узнает о самом существовании объекта, потому что в его интерфейс также будут внесены изменения. Эта функция сервера MOSS называется «безопасность на уровне элемента» или «защищённые объекты». Разрешения на доступ к объектам MOSS могут быть организованы иерархически, т.е. заданы на разных уровнях – от дробных объектов, например элементов списка, до более крупных, например, списка или библиотеки документов. Имеется возможность реализации наследования разрешений, так что дочерним объектам более низких уровней можно разрешить наследовать разрешения от родительских объектов более высокого уровня. Пользователь или группа пользователей служб SharePoint могут получать один из 33 типовых разрешений, каждое из которых можно привязать к объекту. Можно создавать и новые разрешения. Например, на узле управления проектом доступ к таким важным материалам по разработке, как техническое задание на проект и описание приёмов проектирования, выполненные в текстовом редакторе Microsoft Word и хранящиеся в библиотеке документов, можно разрешить только разработчикам и руководителям проекта. По умолчанию библиотека наследует распределение разрешений от узла. Однако его можно изменить так, чтобы разрешить доступ только разработчикам и руководителям проекта, или даже так, что любой документ в текстовом редакторе Word увидят и получат к нему доступ только руководитель и коллектив разработчиков соответствующего проекта. Несекретные материалы – отдельные позиции, папки или всю библиотеки документов – можно выложить в открытый доступ. Разрешения можно распространить и на события, например дату завершения проекта в списке «События», так что отдельные события смогут увидеть только некоторые члены групп. Более того, функции безопасности на уровне элемента могут обрабатывать и результаты поиска, т.е. лицо, осуществляющее поиск, получит лишь те объекты, которые соответствуют его параметрам в системе безопасности. В результате такого управления интерфейс пользователя будет усечён в соответствии с разрешениями данного конкретного пользователя. При разработке сервера MOSS 2007 архитектура управления разрешениями была значительно улучшена. Разрешения можно задавать и для групп SharePoint, и для групп доменов, и на индивидуальном уровне. Несколько групп создаются по умолчанию при установке, а именно, «владельцы» (которым предоставляются все возможности управления), «посетители» (с правом создания содержимого) и «члены» (с правом чтения). Отдельные пользователи и группы доменов можно относить к указанным группам по умолчанию или к заказным группам, которые создают и которыми управляют на уровне набора узлов. Каждая из таких групп может иметь свой уровень разрешений. При создании групп на основе ролей можно создать группы «разработчики» и «руководители проектов». Затем можно на более детальном уровне описать разрешения, например, разработчиков – на загрузку на сервер программной документации, а руководителей проектов – на чтение и утверждение, что позволит им оценивать и утверждать эту документацию. Членство в группе распространяется на весь набор узлов, так что единожды созданные группы можно использовать многократно на узлах разных проектов. 6.) Интеграция подключаемой системы единого входа В типичной вычислительной системе пользователю может быть предоставлен доступ к любому количеству приложений сторонних производителей, каждое из которых использует свои критерии проверки подлинности. Это приводит к нарушениям безопасности и создаёт трудности с запоминанием большого количества паролей. Служба единого входа сервера MOSS позволяет устранить эти недостатки за счёт хранения в кэше серверной части в зашифрованном виде учетных записей пользователей для сопоставления со связанными системами обеспечения основной деятельности. Это также способствует поиску важной для основной деятельности информации с целью её отображения, когда для этого задействуются такие механизмы MOSS, как каталог данных предприятия (англ. BDC, Business Data Catalog) или веб-части представления данных SharePoint (англ. DVWP, DataView Web Parts). Поставщик единого входа сервера MOSS является подключаемым, как и ряд других рассмотренных выше компонентов. Помимо комплектного поставщика единого входа сервера MOSS (SpsSsoProvider), можно задать и другой, однако пока вычислительная среда позволяет регистрировать одновременно не более одного такого поставщика на систему для одной сферы деятельности.
7.) Управление правами на доступ к данным Как защитить деловую информацию на уровне клиента даже в тех случаях, когда с ней работают в автономном режиме? Этим озабочены в компаниях, где работают с секретными данными или сведениями личного характера, особенно если на деятельность компании распространяются такие законы, как законопроект № 1386 Сената штата Калифорния, закон Сарбейнса-Оксли, закон о переносимости данных и отчётности при страховании здоровья (HIPAA). Служба управления правами на доступ данных на стороне сервера объединена с хранилищами MOSS в единый комплекс на основе структуры управления правами Windows. Служба управления правами на доступ к данным позволяет обеспечить надёжное управление данными предприятия, поскольку ограничения доступа действуют на уровне документа независимо от того, где документ хранится или кто пытается его открыть. Реализация службы управления правами на доступ к данным как общей даёт возможность разрешать только санкционированный просмотр и печать. Более того, можно, к примеру, потребовать проверки учётной записи пользователя по истечении определенного времени, запретить пользователям передавать в вышестоящую сеть средства, не предполагающие использования управления правами на доступ данных, установить метку плановой отмены ограничивающей политики, осуществить привязку к политике разрешения глобальной корпоративной службы управления правами на доступ к данным. Службу управления правами на доступ к данным осуществляет защитник. Несколько таких защитников устанавливаются совместно с сервером MOSS 2007. Защитник – это компонент, управляющий процессом шифрования файла; обычно для всех файлов, которые могут храниться на сервере MOSS, уже имеются защитники (шифрование системных файлов пакета Microsoft Office и файлов в формате OpenXML обеспечивается собственными средствами). Защитники, как и другие поставщики на сервере MOSS, имеют архитектуру подключаемых приложений. Это позволяет реализовать заказные защитники для файлов других типов. Первый этап реализации службы управления правами на доступ к данным состоит в том, чтобы убедиться, что среда MOSS отвечает всем требованиям. Клиент служб управления правами Windows должен быть установлен на каждом веб-сервере MOSS переднего плана, а службы Microsoft Rights Management Services (RMS) должны иметь связь с веб-серверами MOSS переднего плана. Затем нужно задать RMS-сервер – по умолчанию в Active Directory или явно указав его местонахождение. Сервер MOSS будет обращаться к нему через центральную администрацию SharePoint. В процессе сопровождения разрешений служба управления правами на доступ к данным непосредственно взаимодействует с такими структурами хранения данных сервера SharePoint, как библиотеки документов. Когда пользователь переходит к библиотеке документов, на которую распространяется действие указанной службы, и пытается загрузить документ, сервер MOSS привязывает к этому документу разрешения, заданные для библиотеки (см. рис. 4). В результате между MOSS и документом устанавливается взаимно однозначное сопоставление разрешений, так что роли, привязанные в SharePoint к документу, преобразуются в уровни разрешений службы управления правами на доступ к данным самого документа. Рисунок 4 Перенос разрешений службы управления правами на доступ к данным из библиотеки документов С целью обеспечения защиты при работе в автономном режиме, документ шифруется локально и остаётся зашифрованным до возвращения в библиотеку. После возвращения в вышестоящую систему документ хранится в незашифрованном виде. Благодаря этому сборщик данных SharePoint может проиндексировать его содержимое для полнотекстового поиска (однако доступ к незашифрованному содержимому не разрешён никому из пользователей). Сервер MOSS 2007 обладает рядом новых компонентов, благодаря которым в компании можно внедрить действенные меры безопасности без излишних непроизводительных затрат на управление. Дополнительный полезный эффект с точки зрения обеспечения доступа пользователей к необходимой информации даёт то, что эти компоненты отличаются высокой приспособляемостью и широкими возможностями адаптации. Автор: Адам Роберт Буэнз (Аdam Robert Buenz) Иcточник: TechNet Magazine
