Еволюція безпеки SharePoint, MS Office, Програмні керівництва, статті

В результаті постійного вдосконалення продукт Microsoft SharePoint Services 2003 перетворився в Microsoft Office SharePoint Server 2007 – рішення з набагато більш повним і потужним набором інструментів безпеки. Безпека SharePoint 2003 грунтувалася на захищеної процедурі реєстрації, підкріпленої Active Directory (AD), захистом порталу та захистом на рівні списків. У SharePoint 2007 вдосконалені колишні функції безпеки і з’явилися додаткові функції аудиту, політики зберігання даних і надійно захищені продукти колективної роботи, такі як Excel Services. В даній статті показано, як розвивалися методи захисту SharePoint, який підхід до перевірки автентичності та авторизації застосовувався в кожній версії і яким чином переваги SharePoint 2007 можна реалізувати в конкретній компанії.


Перевірка автентичності в SharePoint 2003

Для початку розглянемо особливості системи безпеки рішень і технологій Microsoft SharePoint 2003. Фундамент будь-якого продукту безпеки – можливість управляти доступом до захищених матеріалів, яка, по суті, зводиться до цифрових посвідченнями особистості і паролів. Технології SharePoint 2003 для перевірки облікового запису користувача засновані на AD, тому політики паролів будь-якого сайту SharePoint, по суті, являють собою політики паролів базової мережі AD. Як наголошується в комплекті ресурсів Microsoft SharePoint Products and Technologies Resource Kit, в політиках паролів необхідно враховувати безліч рекомендацій, особливо при використанні технологій SharePoint в мережі. Цими рекомендаціями обмовляється мінімальна довжина пароля, його складність, число послідовних спроб введення і використання смарт-карт і біометричних пристроїв.

Яке саме вплив робить використання AD на процес перевірки автентичності користувачів (користувач повинен бути саме тим, за кого він себе видає)? У SharePoint 2003 передбачено два режими роботи: раніше існуючої облікового запису (preexisting-account mode) і створення облікового запису (account-creation mode). В режимі раніше існуючої облікового запису (інакше – доменному режимі) обліковий запис AD повинна вже існувати до того, як користувач звернеться до сайту SharePoint. В режимі створення облікового запису (вибирається під час встановлення SharePoint) можна автоматично створювати обліковий запис AD кожен раз при додаванні нового користувача SharePoint. Визначити режим, в якому знаходиться SharePoint 2003, можна за допомогою інструмента командного рядка Stsadm.exe, що поставляється разом з продуктом.

У будь-якому випадку існування облікового запису AD забезпечує необхідну для доступу до SharePoint перевірку автентичності. SharePoint перевіряє існування користувача в AD через протокол NTLM або Kerberos. Щоб виконати авторизацію, перевірена обліковий запис зіставляється з інформаційним списком управління доступом для сайту SharePoint. Ці списки авторизації зберігаються в базах даних контенту Microsoft SQL Server і змінюються зсередини SharePoint. Ці списки або групи можна організувати на рівні користувача, у групи рівня сайту або в групи Многосайтовий рівня.

Трохи вище зазначалося, що в SharePoint для перевірки облікового запису використовується AD, але це твердження не зовсім точне. Можна задіяти і локальні облікові записи Windows. Однак, якщо не використовувати AD, не можна заповнити базу даних профілю заздалегідь. А якщо в когось з користувачів є особисті сайти, то вони не будуть зареєстровані для межфермерной синхронізації на серверах ферми. Через ці обмежень настійно рекомендується працювати з AD.


Авторизація SharePoint 2003

Які наслідки застосування AD для авторизації користувача (перевірки, що у користувача є дозвіл для доступу до ресурсу)? Авторизація SharePoint 2003 заснована на групах прав, до яких прив’язуються користувачі або групи користувачів. Групи безпеки можна налаштувати, але за замовчуванням в складі Windows SharePoint Services є п’ять груп:


Права поділяються на три основні категорії: права списку, права сайту та особисті права. В результаті перевірки облікових прав з’ясовується, чи може користувач вносити елементи в список, редагувати їх, управляти стовпцями у списку і т.д. Перевірка прав сайту виконується при кожній спробі користувача створити сайт, керувати користувачами сайту, змінити зовнішній вигляд і поведінка сайту і в багатьох інших випадках. Особисті права перевіряються, коли користувач намагається створити або змінити вид особистого списку і використовувати приватні або особисті компоненти Web Part. На екрані 1 показаний повний список прав, наявних в SharePoint 2003.

Екран 1. Доступні права в SharePoint 2003

Якщо знати, як в SharePoint організовано розподіл прав за групами, стає зрозуміло, як організувати користувачів. Можна індивідуально керувати дозволами кожного користувача, але краще сформувати групи користувачів. Існує два варіанти розподілу користувачів по групах: групи сайту і міжсайтовий групи. Група сайту – це група користувачів, яких можна пов’язати з конкретним сайтом SharePoint. Якщо користувачі об’єднані в міжсайтовий групі, то ця група створюється на верхньому рівні колекції сайтів і доступна для будь-якого сайту в цьому сімействі.

Припустимо, що в компанії Contoso є кілька підрозділів, зокрема Marketing (маркетинг), Executive (керівники), Finance (фінанси) і IT (ІТ). Якщо кожне з цих підрозділів має власним сайтом нижче сайту верхнього рівня, то у користувача в підрозділі Executive може не бути доступу до документів, що зберігаються в фінансовому підрозділі, якщо йому явно не призначено таких прав. Однак, якщо користувачі кожного підрозділу розміщуються в міжсайтових групах, менеджеру підрозділи Finance слід надати тільки міжсайтовий групі Executive право читання в порталі, і воно відразу пошириться на всіх членів команди.


Безпека на рівні сайту

Отже, є групи користувачів і групи прав. Як використовувати ці групи для захисту порталу SharePoint? SharePoint 2003 забезпечує два рівня безпеки: на рівні сайту і на рівні списку. При створення сайту SharePoint творець або власник має можливість вибрати режим безпеки. Можна наслідувати дозволу батьківського сайту або використовувати унікальні дозволи. Якщо вирішено успадковувати батьківські дозволу, то параметри безпеки передаються вниз новому сайту порталу, і кожен, хто має той чи інший рівень доступу до батьківського сайту, має такий же доступ в новому сайті. Якщо обрані унікальні дозволи, то спочатку творець виявляється єдиним користувачем, які мають які-небудь права доступу в новому порталі. Після створення сайту можна додати у сайт нових користувачів або групи користувачів і призначити спеціальні дозволи.

Припустимо, що в компанії Contoso є ІТ-підрозділ. Його співробітники повинні мати можливість відстежувати заявки про неполадки через список контролю проблем SharePoint. Для цього в ІТ-підрозділі побудований сайт ІТ-порталу, дочірній для основного сайту Contoso. У цій вигаданій компанії кожен член домену має принаймні доступ для читання на основному сайті компанії. Створюваний сайт ІТ-порталу успадковує дозволу; будь-який користувач домену може підключитися до сайту ІТ-порталу та побачити дані на домашній сторінці, в тому числі список контролю проблем на домашній сторінці сайту ІТ-порталу. В даний час ІТ-підрозділу необхідно визначити місце для зберігання спеціальної інформації, зокрема паролів сервера. Керівник ІТ-служби не хоче, щоб користувачі бачили, що така документація існує, тому будується новий сайт порталу з унікальними дозволами. Користувачами цього сайту порталу PrivateIT можуть бути тільки члени ІТ-служби. Якщо інші користувачі намагаються звернутися до сайту порталу PrivateIT, вони отримують повідомлення про помилку через відсутність дозволу для доступу до ресурсу. У додатковому повідомленні можна роз’яснити, що дозвіл для доступу до захищеного порталу вони можуть отримати в адміністратора.


Безпека на рівні списку

Безпека на рівні списку забезпечується аналогічно, але на рівні окремих списків, а не на рівні сайту. Звернімося знову до прикладу загальнодоступного сайту ІТ-порталу із списком контролю проблем. Припустимо, що ІТ-підрозділ має намір надати кожному користувачеві можливість читати елементи списку, але керівник вважає за необхідне надати членам міжсайтовий групи Managers можливість додавати нові і редагувати існуючі елементи. В параметрах дозволів списку можна додавати користувачів або групи і призначати їм різні дозволи. Досить ввести список, клацнути на Modify Settings and Columns, а потім на засланні Change permissions for this list. На екрані 2 показаний найдокладніший список прав, який можна призначити. Зверніть увагу на привабливу посилання Modify item-level security в лівій панелі. Це посилання дозволяє лише перемикати уявлення користувачів з режиму перегляду і редагування всіх елементів списку в режим, в якому можна побачити лише власні елементи списку.

Екран 2. Детальні права SharePoint 2003

Дозвіл на рівні елемента було передвісником нововведень SharePoint 2007, які стали важливим кроком в еволюції методів перевірки автентичності та авторизації, з більш різноманітними, деталізованими та інтуїтивно зрозумілими варіантами.


Перевірка справжності SharePoint 2007

У SharePoint 2007 не тільки збережені колишні можливості, інтегровані з Windows, але і з’явилася модель провайдера ASP.NET. Завдяки моделі провайдера ASP.NET усувається необхідність в облікових записах Windows або AD і надаються нові можливості, зокрема перевірка справжності форм з використанням сховища даних користувача (наприклад, бази даних SQL Server). Також можна задіяти процедуру одноразової реєстрації SSO на базі Web, при якій користувач реєструється за допомогою форми реєстрації, відмінної від SharePoint. Відомий приклад процедури одноразової реєстрації на базі Web – Windows Live ID (у минулому. NET Passport). В результаті еволюції перевірки автентичності розробники й адміністратори отримують більшу гнучкість при установці і настройці SharePoint 2007.


Авторизація в SharePoint 2007


Адміністративна безпека

У даній статті ми розглянули заходи безпеки на рівнях користувача і сайту в SharePoint 2003 і SharePoint 2007. У розпорядженні адміністраторів SharePoint з’явилися додаткові рівні безпеки, а також можливість застосовувати захист на рівні служб Shared Services і на центральному адміністративному рівні вSharePoint 2007.

По суті, адміністрування Shared Services означає, що адміністратор ферми серверів може делегувати авторизацію для певних завдань іншим користувачам. Це зручно, якщо користувачі роблять невдалі зміни, наприклад видаляють об’єкт (і потім очищують “кошику”). Завдяки делегуванню авторизації користувачеві не доводиться звертатися за допомогою до адміністратора ферми.

Останній можливий рівень настройки системи безпеки в примірнику SharePoint 2007 – рівень централізованого адміністрування. Серед безлічі нових функцій цього рівня є і політики безпеки – набір дозволів, що застосовуються в будь-яких місцях ферми. Ці політики допуску та заборон скасовують всі інші дозволи, і їх можна задавати для окремих Web-додатків і Web-зон. Типові приклади використання політики безпеки – надання повного доступу для читання аудиторам і заборона будь-яких операцій запису для всіх користувачів із зони Internet (тобто зовнішньої мережі). На цьому рівні можна також створити службові облікові записи AD, щоб запобігти небажану поведінку програми в мережі. На цьому рівні налаштовуються облікові записи пулу додатків, облікові записи служби SharePoint (SPTimer і Admin Service) і доступ до SQL Server.


Величезні можливості

SharePoint 2007 істотно полегшує роботу кінцевих користувачів. Завдяки більш зручному інтерфейсу і таких прийомів, як урізання функціональності в цілях безпеки, користувач бачить тільки сайти, списки та документи, для яких є дозволи. Ще більш важливо, що з появою SharePoint 2007 спрощується завдання адміністратора, завдяки чіткій організації користувачів і ролей, визначених на одному рівні, можливості делегувати операції іншим користувачам через службу Shared Services і застосування політик безпеки в масштабах системи.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*