Я думаю, всем очевидна высокая роль системы безопасности в enterpise системах. Подобные системы являются центральными хранилищами информации организации. Это позволяет представить документы организации в структурированном виде, упростить их поиск. В зависимости от типа системы (CRM, ERP, ECM) под информацией может подразумеваться:
— сведения о сотрудниках;
— контактные данные о клиентах;
— договора и другие важные документы;
— отчеты и статистика;
— финансовая информация.
Получение доступа к этой информации сторонними лицами может привести к серьезным последствиям. Поэтому основной задачей любой системы безопасности является защита от несанкционированного доступа, а также обеспечение целостности и доступности информации.
Вещи казалось бы очевидные и понятные, все понимают значимость безопасности в программных продуктах промышленного уровня, однако на деле безопасность внедренных решений далеко не всегда оказывается на должном уровне . Причин этому, как мне кажется, несколько.
Первая и очевидная причина – это некоторая сложность систем, обусловленная их масштабами. От этого никуда не денешься. Системы подобного плана обычно состоят из многих компонентов, которые взаимодействуют между собой. Это безусловно накладывает свой отпечаток на систему безопасности — обычно для каждой такой связи необходимо рассмотреть вопрос безопасности: создать и настроить аккаунты, раздать права, настроить шифрование и т.п.
Системы подобных размеров часто тесно интегрируются с компонентами операционной системой и сторонними программами. Это требует от администраторов, внедряющих и обслуживающих такие системы, серьезных знаний, подкрепленных опытом. Сухой теории бывает мало в случае любых систем и технологий, в случае с enterprise системами — тем более. А найти администраторов, с опытом внедрения и поддержки подобных систем нелегко.
Второй причиной, над которой обычно мало задумываются – является отсутствие планирования безопасности до внедрения системы. А этот шаг очень важен. Многие проблемы в безопасности связаны с тем, что ей начинают заниматься после того, как система установлена. Часто при установке применяются настройки по умолчанию, при этом не учитывается то, что они редко удовлетворяют требованиям какой-либо конкретной организации. А каждый случай требует индивидуального рассмотрения.
Причинами отсутствия планирования безопасности часто бывают поджимающие сроки сдачи проекта (при этом внимание больше акцентируется на бизнес составляющей). Однако встречаются случаи, когда причиной является “святая вера“ в универсальность настроек по умолчанию и применимость их для конкретного случая.
SharePoint является enterprise системой, поэтому затронутые выше темы также относятся и к нему. Целью данного цикла статей является собрание воедино основной информации о системе безопасности данного продукта Майкрософт.
Информация, содержащая в статьях актуальна для следующих версий SharePoint: Microsoft Office SharePoint Server 2007 и Windows SharePoint Services 3.0
Безопасность в SharePoint реализуется на нескольких логических уровнях (в статьях Майкрософт часто употребляется термин defense-in-depth). Для создания полноценных и защищенных порталов и приложений четкое понимание системы безопасности на каждом уровне является необходимым.
SharePoint включает в себя много компонентов и поддерживает простую интеграцию со сторонними продуктами, но в первую очередь представляет собой платформу для веб приложений. Под платформой веб приложений я подразумеваю систему для простого создания и настройки интранет порталов и их составляющих: страниц, форм ввода, рабочих процессов, поискового механизма, форумов, блогов, wiki и т.п…
Помимо интранет приложений SharePoint также позволяет создавать обычные интернет сайты с анонимным доступом и свободной регистрацией, а также extranet решения. Это также находит свое отражения на системе безопасности SharePoint, в частности в выборе метода аутентификации и шифрования.
Отличительной особенностью SharePoint является его максимальная гибкость в вопросах раздачи прав на создание, удаление, просмотр объектов и другие операции. Права могут быть выданы как группе пользователей, так и конкретному пользователю и для определенного документа. Неграмотное распределение прав на объекты, может привести к ” дырам в безопасности”, что может в будущем привести к взлому системы и потере информации. Поэтому необходимо четко знать и понимать, как устроена система распределения прав, ролей, а также знать назначение и права встроенных групп пользователей.
SharePoint также известен своими возможностями по интеграции со сторонними приложениями, системами, базами данных, что безусловно отражается на системе безопасности. Для удобства восприятия информация статья разбита на несколько частей.
Как уже отмечалось выше, важным моментом является заблаговременное планирование безопасности, грамотный подбор аккаунтов для сервисов. Эти вопросы, а также общее описание архитектуры безопасности будут рассмотрены во второй части статьи.
Часто при настройке безопасности SharePoint и других систем подобного уровня основное внимание уделяется защите системы от неавторизованного доступа извне. Однако помимо этого стоит уделять внимание на разграничение прав доступа для уже авторизованных пользователей. Эта тема обсуждается в третьей части статьи. В ней объясняются основы безопасности SharePoint сайтов: роли, группы, права, уровни прав, а также будет представлено описание стандартных групп пользователей.
В четвертой части статьи будет рассмотрено API для работы с безопасностью SharePoint. Статья будет содержать примеры кода по созданию, удалению пользователей, их прав, групп, назначению прав доступа на объекты. Также будут рассмотрены вопросы наследования ролей и имперсонации с использованием кода.
SharePoint известен своей возможностями по расширению функционала путем разработки кастомных описаний списков, типов содержимого, рабочих процессов, форм и конечного же веб частей. В интернете полно статей по данному вопросу, но к сожалению лишь малая часть из них затрагивает вопросы безопасности при разработке собственных компонентов. Пятая часть статьи постарается как можно подробнее освятить данный вопрос. Будет дано подробное описание CAS (Code Access Security), уровней доверия и Safe Controls. Также будет приведена информация о том, под какими аккаунтами запускаются сервисы SharePoint (workflows, event listeners, timer jobs).
Хочется, однако, отметить, что в статье будет представлена далеко не вся информацию по вопросу безопасности SharePoint. Поэтому по тексту и в конце каждой статьи будут приведены ссылки на ресурсы, где может быть найдено подробное описание того или иного вопроса.
P.S. Не смотря на “водянистость” данного введения, последующие статьи будут носить технический характер и будут в основном предназначены для администраторов SharePoint серверов и программистов, разрабатывающих приложения для SharePoint и использующих его API.
Комментарии, замечания и здоровая критика приветствуются. Спасибо за внимание.
— сведения о сотрудниках;
— контактные данные о клиентах;
— договора и другие важные документы;
— отчеты и статистика;
— финансовая информация.
Получение доступа к этой информации сторонними лицами может привести к серьезным последствиям. Поэтому основной задачей любой системы безопасности является защита от несанкционированного доступа, а также обеспечение целостности и доступности информации.
Вещи казалось бы очевидные и понятные, все понимают значимость безопасности в программных продуктах промышленного уровня, однако на деле безопасность внедренных решений далеко не всегда оказывается на должном уровне . Причин этому, как мне кажется, несколько.
Первая и очевидная причина – это некоторая сложность систем, обусловленная их масштабами. От этого никуда не денешься. Системы подобного плана обычно состоят из многих компонентов, которые взаимодействуют между собой. Это безусловно накладывает свой отпечаток на систему безопасности — обычно для каждой такой связи необходимо рассмотреть вопрос безопасности: создать и настроить аккаунты, раздать права, настроить шифрование и т.п.
Системы подобных размеров часто тесно интегрируются с компонентами операционной системой и сторонними программами. Это требует от администраторов, внедряющих и обслуживающих такие системы, серьезных знаний, подкрепленных опытом. Сухой теории бывает мало в случае любых систем и технологий, в случае с enterprise системами — тем более. А найти администраторов, с опытом внедрения и поддержки подобных систем нелегко.
Второй причиной, над которой обычно мало задумываются – является отсутствие планирования безопасности до внедрения системы. А этот шаг очень важен. Многие проблемы в безопасности связаны с тем, что ей начинают заниматься после того, как система установлена. Часто при установке применяются настройки по умолчанию, при этом не учитывается то, что они редко удовлетворяют требованиям какой-либо конкретной организации. А каждый случай требует индивидуального рассмотрения.
Причинами отсутствия планирования безопасности часто бывают поджимающие сроки сдачи проекта (при этом внимание больше акцентируется на бизнес составляющей). Однако встречаются случаи, когда причиной является “святая вера“ в универсальность настроек по умолчанию и применимость их для конкретного случая.
SharePoint является enterprise системой, поэтому затронутые выше темы также относятся и к нему. Целью данного цикла статей является собрание воедино основной информации о системе безопасности данного продукта Майкрософт.
Информация, содержащая в статьях актуальна для следующих версий SharePoint: Microsoft Office SharePoint Server 2007 и Windows SharePoint Services 3.0
Безопасность в SharePoint реализуется на нескольких логических уровнях (в статьях Майкрософт часто употребляется термин defense-in-depth). Для создания полноценных и защищенных порталов и приложений четкое понимание системы безопасности на каждом уровне является необходимым.
SharePoint включает в себя много компонентов и поддерживает простую интеграцию со сторонними продуктами, но в первую очередь представляет собой платформу для веб приложений. Под платформой веб приложений я подразумеваю систему для простого создания и настройки интранет порталов и их составляющих: страниц, форм ввода, рабочих процессов, поискового механизма, форумов, блогов, wiki и т.п…
Помимо интранет приложений SharePoint также позволяет создавать обычные интернет сайты с анонимным доступом и свободной регистрацией, а также extranet решения. Это также находит свое отражения на системе безопасности SharePoint, в частности в выборе метода аутентификации и шифрования.
Отличительной особенностью SharePoint является его максимальная гибкость в вопросах раздачи прав на создание, удаление, просмотр объектов и другие операции. Права могут быть выданы как группе пользователей, так и конкретному пользователю и для определенного документа. Неграмотное распределение прав на объекты, может привести к ” дырам в безопасности”, что может в будущем привести к взлому системы и потере информации. Поэтому необходимо четко знать и понимать, как устроена система распределения прав, ролей, а также знать назначение и права встроенных групп пользователей.
SharePoint также известен своими возможностями по интеграции со сторонними приложениями, системами, базами данных, что безусловно отражается на системе безопасности. Для удобства восприятия информация статья разбита на несколько частей.
Как уже отмечалось выше, важным моментом является заблаговременное планирование безопасности, грамотный подбор аккаунтов для сервисов. Эти вопросы, а также общее описание архитектуры безопасности будут рассмотрены во второй части статьи.
Часто при настройке безопасности SharePoint и других систем подобного уровня основное внимание уделяется защите системы от неавторизованного доступа извне. Однако помимо этого стоит уделять внимание на разграничение прав доступа для уже авторизованных пользователей. Эта тема обсуждается в третьей части статьи. В ней объясняются основы безопасности SharePoint сайтов: роли, группы, права, уровни прав, а также будет представлено описание стандартных групп пользователей.
В четвертой части статьи будет рассмотрено API для работы с безопасностью SharePoint. Статья будет содержать примеры кода по созданию, удалению пользователей, их прав, групп, назначению прав доступа на объекты. Также будут рассмотрены вопросы наследования ролей и имперсонации с использованием кода.
SharePoint известен своей возможностями по расширению функционала путем разработки кастомных описаний списков, типов содержимого, рабочих процессов, форм и конечного же веб частей. В интернете полно статей по данному вопросу, но к сожалению лишь малая часть из них затрагивает вопросы безопасности при разработке собственных компонентов. Пятая часть статьи постарается как можно подробнее освятить данный вопрос. Будет дано подробное описание CAS (Code Access Security), уровней доверия и Safe Controls. Также будет приведена информация о том, под какими аккаунтами запускаются сервисы SharePoint (workflows, event listeners, timer jobs).
Хочется, однако, отметить, что в статье будет представлена далеко не вся информацию по вопросу безопасности SharePoint. Поэтому по тексту и в конце каждой статьи будут приведены ссылки на ресурсы, где может быть найдено подробное описание того или иного вопроса.
P.S. Не смотря на “водянистость” данного введения, последующие статьи будут носить технический характер и будут в основном предназначены для администраторов SharePoint серверов и программистов, разрабатывающих приложения для SharePoint и использующих его API.
Комментарии, замечания и здоровая критика приветствуются. Спасибо за внимание.
