Адміністрування SQL Server 2000
Введення
SQL Server 2000 на сьогоднішній день є
ефективнішим програмним продуктом, який дозволять працювати з безліччю
баз даних. Виділяють два основні розділи роботи з сервером, кожен з яких
можна розділити на більш дрібні блоки: адміністрування; програмування.
Адміністрування в свою чергу можна розділити на
дві частини: власне адміністрування сервера і адміністрування баз даних.
Так як тема курсової роботи - адміністрування баз даних SQL Server 2000, то
розглянемо, перш за все, саме адміністрування баз даних.
Адміністрування баз даних являє собою окрему
більшу, чи не найголовнішу область роботи з SQL Server 2000. Воно включає
розробку структури бази даних, її реалізацію, проектування системи
безпеки, створення бази даних користувачів, надання їм прав
доступу, створення об'єктів і т. д. Крім того, адміністратор бази даних
він повинен регулярно створювати резервні копії, виконувати перевірку цілісності
даних і стежити за розміром файлів, як самої бази даних, так і журналу
транзакцій. Вказаний список можна довго продовжувати, так як область
адміністрування баз даних дуже обширна і перерахування всіх завдань
адміністрування зайняло б дуже багато часу, тому зупинимося на
основні завдання адміністратора.
Перша велика завдання, яке постає перед будь-яким
адміністратора або розробника, це проектування структури бази даних.
Нераціонально спроектована база даних надалі доставить багато проблем
робочого характеру, як адміністратору, так і програмістам і користувачам.
Тому слід відповідально поставитися до розробки бази даних, відразу ж
продумуючи різні варіанти використання даних, а також можливості
інтеграції з додатковими системами і доступу до даних за допомогою різних
технологій. А так само враховувати можливу необхідність внесення в майбутньому
змін в структуру бази.
Існує безліч технологій і методів розробки
баз даних, розгляд яких гідно окремої великої роботи. Для більш
детального знайомства з теорією реляційних баз даних і побудовою баз даних
з використанням ER-діаграм необхідно звернутися до спеціалізованої
літературі, присвяченій цим питанням. Для розуміння теорії реляційних баз
даних, яка є домінуючою в даний час, необхідно гарне
знання математики, тому що в основі реляційної моделі даних лежать математичні
об'єкти.
У широкому сенсі слова база даних - це сукупність
відомостей про конкретні об'єкти реального світу в якій-небудь предметної області.
Під предметною областю прийнято розуміти частину реального світу, що підлягає
вивчення для організації управління і, в кінцевому рахунку, автоматизації.
Прикладом може служити підприємство, вуз і т. д. Створюючи базу даних,
користувач прагне впорядкувати інформацію за різними ознаками і швидко
витягати потрібні відомості з довільним поєднанням ознак. Зробити це
можна, тільки якщо дані структуровані.
База даних - пойменована сукупність
взаємозв'язаних даних, що знаходяться під управлінням системи управління базами
даних (СУБД). СУБД це комплекс програмних і мовних засобів, необхідних
для створення баз даних, підтримання їх в актуальному стані та організації
пошуку в них необхідної інформації.
Основне завдання бази даних - зберігати і при необхідності
представляти на першу вимогу користувачів всі необхідні дані в одному
місці, виключаючи їх повторення і надмірність.
Централізований характер управління даними в базі
даних припускає існування певної особи (групи осіб), на яке
покладаються функції адміністрування даних, що зберігаються в базі.
Розрізняють централізовані та розподілені бази
даних. Розподілена база даних складається з декількох частин, що зберігаються в різних
ЕОМ обчислювальної мережі. Цей спосіб обробки має на увазі наявність декількох
серверів, на яких може зберігатися перетинає чи навіть дублююча
інформація. Для роботи з такою базою даних використовується система управління
розподіленими базами даних (СУРБД).
Централізована база даних зберігається в пам'яті однієї
обчислювальної системи, то є база даних розташовується на одному комп'ютері.
Якщо для цього комп'ютера встановлена підтримка мережі, то безліч
користувачів з клієнтських комп'ютерів можуть одночасно звертатися до
інформації, що зберігається в центральній базі даних. У локальних мережах найчастіше
використовується саме такий спосіб обробки даних. Системи централізованих
баз даних можуть суттєво відрізнятися в залежності від їх архітектури. [1]
Адміністрування SQL Server 2000
Файл-сервер
БД розташовується на файл-сервер (або кількох
файл-серверах), в якості якого може використовуватися найбільш потужна з
робочих станцій, об'єднаних в мережу. Опції файл-сервера полягають, в основному,
у зберіганні БД і забезпечення доступу до них користувачів, що працюють на
різних комп'ютерах. Файли бази даних у відповідності з призначеними для користувача
запитами передаються на робочі станції, де в основному і виробляється
обробка. Надіслані дані обробляються СУБД, яка знаходиться знову ж таки на
комп'ютерах користувачів. Після того як користувачі виконають необхідні
зміни даних, вони копіюють файли назад на файл-сервер, де інші
користувачі, у свою чергу, можуть знову їх використовувати. Крім того, кожен
користувач може створювати на локальному комп'ютері свої власні бази
даних, якими їм монопольно. Ця схема працює при не дуже великих
обсягах даних. При збільшенні числа комп'ютерів в мережі або зростанні БД
продуктивність різко падає. Це пов'язано із збільшенням обсягу даних,
переданих по мережі, тому що вся обробка відбувається на комп'ютері
користувача. Очевидним недоліком такого підходу є висока ймовірність
втрати змін, виконаних самими користувачами, при збереженні змінених
файлів на центральний сервер. [2]
Справа в тому, що користувачі можуть і не
підозрювати, що крім них ще хтось змінював дані. Прикладами СУБД,
призначеними безпосередньо для розробки локальних користувачів
додатків БД, тобто додатків, що працюють на одному локальному комп'ютері
або у комп'ютерній, мережі є: Microsoft Visual FoxPro, Microsoft
Access, Paradox, fpr Windows, dBase for Windows і ін
Клієнт-сервер. Технологія клієнт-сервер на увазі,
що крім зберігання бази даних центральний комп'ютер (сервер бази даних)
повинен забезпечувати виконання основного обсягу обробки даних. При технології
клієнт-сервер запит на виконання операції з даними (наприклад, звичайна
вибірка), що видається клієнтом (робочою станцією), породжує на сервері пошук та
вилучення даних. Витягнуті дані (але не файли) транспортуються по мережі
від сервера до клієнта. Система, що використовує технологію клієнт-сервер,
розділяється на дві частини: клієнтська частина (front-end) забезпечує
графічний інтерфейс і знаходиться на комп'ютері користувача; серверна частина
(back-end), яка знаходиться на спеціально виділених комп'ютерах,
забезпечує управління даними, поділ інформації, адміністрування та
безпеку. Прикладами СУБД технології клієнт-сервер є Microsoft SQL
Server, Oracle, IBM DB2, Sybase та ін Специфікою архітектури клієнт-сервер
є використання спеціальної мови структурованих запитів
(Structured Query Language, SQL), що забезпечує користувача простим і
ефективним інструментом доступу до даних. [3]
Крім підрозділи баз даних з методів обробки
можна класифікувати їх за використовуваної моделі (або структурі) даних.
Модель даних - сукупність структур даних та операцій з їх обробці. З
допомогою моделі даних можна наочно представити структуру об'єктів і
встановлені між ними зв'язку. Для термінології моделей даних характерні
поняття «елемент даних» та «правила зв'язування». Елемент даних описує
будь-який набір даних, а правила зв'язування визначають алгоритми взаємозв'язку
елементів даних. До теперішнього часу розроблена безліч різних моделей
даних, але на практиці використовується три основних. Виділяють ієрархічну,
мережеву та реляційну моделі даних. Відповідно говорять про ієрархічних,
мережних і реляційних СУБД.
Ієрархічна модель даних. Ієрархічно
організовані дані зустрічаються в повсякденному житті дуже часто. Наприклад,
структура вищого навчального закладу - це багаторівнева ієрархічна
структура. Ієрархічна (деревоподібна) БД складається з упорядкованого набору
елементів. В цій моделі вихідні елементи породжують інші елементи, причому
ці елементи в свою чергу породжують такі елементи. Кожен породжений
елемент має тільки один породжує елемент.
Організаційні структури, списки матеріалів,
зміст у книгах, плани проектів і багато інших сукупності даних можуть
бути представлені у ієрархічному вигляді. Автоматично підтримується
цілісність посилань між предками і нащадками. Основне правило: ніякої
нащадок не може існувати без свого батька.
Основним недоліком даної моделі є
необхідність використання тієї ієрархії, яка була закладена в основу БД
при проектуванні. Потреба в постійній реорганізації даних (а часто
неможливість цієї реорганізації) призвели до створення більш загальної моделі --
мережевий.
Мережева модель даних. Мережевий підхід до організації
даних є розширенням ієрархічного підходу. Дана модель відрізняється
від ієрархічної тим, що кожен породжений елемент може мати більше одного
породжує елементу.
Розглянемо предметну область для бази даних, у
якій зберігається інформація про замовлення магазину. Замовники беруть напрокат
фільми, використовуючи два носії: відеострічку і компакт-диски. Обслуговування
замовників виконують продавці. Кожен продавець обслуговує багатьох замовників.
Кожен продавець може користуватися послугами кількох магазинів і навпаки.
Існує багато копій одного й того ж фільму і т.д.
Оскільки мережна БД може представляти
безпосередньо всі види зв'язків, притаманних даними відповідної організації,
за цими даними можна переміщатися, дослідити і запитувати їх всілякими
способами, тобто мережева модель не пов'язана лише однією ієрархією.
Однак для того, щоб скласти запит до мережевої БД, необхідно достатньо
глибоко вникнути в її структуру (мати під рукою схему цієї БД) і виробити
механізм навігації по базі даних, що є істотним недоліком цієї
моделі БД.
Реляційна модель даних. Основна ідея реляційної
моделі даних полягає в тому, щоб представити будь-який набір даних у вигляді
двовимірної таблиці. У простому випадку реляційна модель описує
єдину двовимірну таблицю, але частіше за все ця модель описує структуру і
взаємини між кількома різними таблицями.
Отже, метою інформаційної системи є обробка
даних про об'єкти реального світу, з урахуванням зв'язків між об'єктами. У теорії БД
дані часто називають атрибутами, а об'єкти - сутностями. Об'єкт, атрибут і
зв'язок - фундаментальні поняття ІС. [4]
Об'єкт (або сутність) - це щось існуюче і
помітне, то є об'єктом можна назвати те «щось», для якого існують
назва і спосіб відрізняти один подібний об'єкт від іншого. Наприклад, кожна
школа - це об'єкт. Об'єктами є також людина, клас у школі, фірма,
сплав, хімічна сполука і т. д. Об'єктами можуть бути не тільки
матеріальні предмети, але і більш абстрактні поняття, що відображають реальний світ.
Наприклад, події, регіони, твори мистецтва, книги (не як
поліграфічна продукція, а як твори), театральні постановки,
кінофільми; правові норми, філософські теорії та ін.
Атрибут (або дане) - це деякий показник,
який характеризує якийсь об'єкт і приймає для конкретного примірника
об'єкта деяке числове, текстова чи іншого значення. Інформаційна
система оперує наборами об'єктів, спроектованими стосовно до даної
предметної області, використовуючи при цьому конкретні значення атрибутів (даних)
тих чи інших об'єктах.
Розвиток реляційних баз даних почалося в кінці 60-х
років, коли з'явилися перші роботи, в яких обговорювалися можливості
використання при проектуванні баз даних звичних і природних способів
подання даних - так званих табличних даталогіческіх моделей.
Основоположником теорії реляційних баз даних
вважається співробітник фірми IBM доктор Е. Коддом, що опублікував 6 червня 1970
статтю A Relational Model of Data for Large Shared Data Banks (Реляційна
модель даних для великих колективних банків даних). У цій статті вперше
був використаний термін «реляційна модель даних», що й поклало початок
реляційних баз даних. [5]
Теорія реляційних баз даних, розроблена в 70-х
роках у США доктором Е. Коддом, має під собою потужну математичну основу,
описує правила ефективної організації даних. Розроблена Е. Коддом
теоретична база стала основою для розробки теорії проектування баз
даних.
Е. Коддом, будучи математиком за освітою, запропонував
використовувати для обробки даних апарат теорії множин (об'єднання,
перетин, різниця, декартовій твір). Він довів, що будь-який розділ
даних можна представити у вигляді двовимірних таблиць особливого виду, відомих у
математиці як «відносини».
реляційної вважається така база даних, в якій всі
дані представлені для користувача у вигляді прямокутних таблиць значень даних,
і всі операції над базою даних зводяться до маніпуляцій з таблицями.
Таблиця складається з стовпців (полів) і рядків (записів);
має ім'я, унікальне всередині бази даних. Таблиця відображає тип об'єкта
реального світу (сутність), а кожна її рядок - конкретний об'єкт. Так,
таблиця Спортивна секція містить відомості про всіх дітей, які займаються в даній
спортивної секції, а її рядки являють собою набір значень атрибутів
кожної конкретної дитини. Кожен стовпець таблиці - це сукупність значень
конкретного атрибуту об'єкта. Стовпець Вага, наприклад, являє собою
сукупність всіх вагових категорій дітей, які займаються у секції. У стовпці Пол
можуть містити лише два різні значення: «чоловік.» і «дружин.». Ці значення
вибираються з множини всіх можливих значень атрибуту об'єкта, що
називається доменом (domain). Так, значення в стовпці вибираються з безлічі
всіх можливих ваг дітей. [6]
У самому загальному вигляді домен визначається завданням
деякого базового типу даних, до якого відносяться елементи домену, і
довільного логічного виразу, який застосовується до елементів даних. Якщо при
обчисленні логічного умови щодо елемента даних у результаті
отримано значення «істина», то цей елемент належить домену. У найпростішому
випадку домен визначається як допустимий потенційне безліч значень
одного типу. Наприклад, сукупність дат народження всіх співробітників складає
«Домен дат народження», а імена всіх співробітників складають «домен імен
співробітників ». Домен дат народження має тип даних, що дозволяє зберігати
інформацію про моменти часу, а домен імен співробітників повинен мати
символьний тип даних.
В один домен можуть входити значення з кількох
стовпців, об'єднаних, крім однакового типу даних, ще й логічно.
Наприклад, домен може складатися з стовпця з датою вступу на роботу і
стовпця з датою звільнення. Але в цей домен не можна включити стовпець з датою
народження, так як дата надходження чи звільнення з роботи не пов'язана з датою
народження.
Якщо два значення беруться з одного і того ж домена,
то можна виконувати порівняння цих двох значень. Наприклад, якщо два значення
взяті з домену дат народження, то можна порівняти їх і визначити, хто з
співробітників старше. Якщо ж значення беруться з різних доменів, то їх порівняння
не допускається, тому що, ймовірно, воно не має сенсу. Наприклад, з
порівняння імені та дати народження співробітника нічого певного не вийде.
У більшості систем управління реляційними базами
даних поняття домену не реалізовано. Кожен елемент даних у відношенні може
бути визначений із зазначенням його адреси у форматі A [i, j], де А- Елемент
даних, i - рядок відносин, j - номер атрибуту відносини.
Кількість атрибутів у відношенні визначає його
порядок (або ступінь. Безліч значень А [i, j] при постійному i і всіх
можливих j утворюють кортеж (або просто рядок таблиці). Кількість всіх
кортежів у відношенні визначає його потужність, або кардинальне число. Потужність
відносини, на відміну від порядку стосунки, може з часом змінюватися.
Сукупність усіх кортежів утворює тіло відносини (або власне таблицю). [7]
Оскільки відносини є математичними
множинами, які за визначенням не можуть містити співпадаючих елементів,
ніякі два кортежу у відношенні не можуть бути дублікатами один одного в будь-якій
момент часу.
Кожен стовпець (поле) має ім'я, яке зазвичай
записується у верхній частині таблиці. При проектуванні таблиць у рамках
конкретної СУБД є можливість вибрати для кожного поля його тип, тобто
визначити набір правил за його відображення, а також визначити ті операції,
які можна виконувати над даними, що зберігаються в цьому полі. Набори типів
можуть відрізнятися в різних СУБД. [8]
Ім'я поля має бути унікальним в таблиці, проте
різні таблиці можуть мати поля з однаковими іменами. Будь-яка таблиця повинна
мати, принаймні, одне поле; поля розташовані в таблиці відповідно до
порядком проходження їхніх імен при її створенні. На відміну від полів, рядки не
мають імен, порядок їх проходження в таблиці не визначений, а кількість
логічно не обмежена.
Так як рядки в таблиці не впорядковані, неможливо
вибрати рядок за її позиції - серед них не існує «перший», «друга»,
«Останньою». Будь-яка таблиця має один або декілька стовпців, значення в
яких однозначно ідентифікують кожен її рядок. Такий стовпець (або
комбінація стовпців) називається первинним ключем (primary key). У таблиці
Спортивна секція первинний ключ - це стовпець П.І.Б. Такий вибір первинного
ключа має істотний недолік: неможливо записати в секцію двох дітей з
одним і тим же значення поля П.І.Б., що на практиці зустрічається не так вже
рідко. Саме тому часто вводять штучне поле, призначене для
нумерації записів у таблиці. Таким полем, наприклад, може бути його порядковий
номер в журналі для кожної дитини, яка зможе забезпечити унікальність кожної
запису в таблиці. Ключ повинен мати наступні властивості. Унікальністю. У
кожний момент часу ніякі два різних кортежу відношення не мають
однакового значення для комбінації що входять в ключ атрибутів. Тобто в
таблиці не може бути двох рядків, які мають однаковий ідентифікаційний номер
або номер паспорта.
мінімальною. Жоден з вхідних в ключ атрибутів
не може бути виключений з ключа без порушення унікальності. Це означає, що
не варто створювати ключ, що включає і номер паспорта, довідку про присвоєння ідентифікаційного
номер. Досить використовувати будь-який з цих атрибутів, щоб однозначно ідентифікувати
кортеж. Не варто також включати в ключ неунікальний атрибут, тобто
забороняється використання в якості ключа комбінації ідентифікаційного
номера і імені службовця. При виключенні імені службовця з ключа все одно
можна унікально ідентифікувати кожен рядок.
Виконання умови унікальності є обов'язковим.
У той же час при необхідності може бути допущено порушення умови
мінімальності.
Кожне відношення має, принаймні, один
можливий ключ, оскільки сукупність всіх його атрибутів задовольняє
умові унікальності - це випливає з самого визначення відносини.
Один з можливих ключів довільно вибирається в
як первинний ключ. Інші можливі ключі, якщо вони є,
приймаються за альтернативні ключі. Наприклад, якщо в якості первинного
ключа вибрати ідентифікаційний номер, то номер паспорта буде альтернативним
ключем. [9]
Взаємозв'язок таблиць є найважливішим елементом
реляційної моделі даних. Вона підтримується зовнішніми ключами (foreign key).
Розглянемо приклад. При описі моделі реляційної бази даних для одного й
того ж поняття часто вживають різні терміни, що залежить від рівня
опису (теорія чи практика) і системи (Access, SQL Server, dBase).
Адміністрування
На будь-якому підприємстві де використовуються в роботі
кошти SQL Server 2000, зобов'язаний бути людина, відповідальна за
адміністрування баз даних, їх резервне копіювання на випадок збою. Також
необхідно розмежувати доступ до інформації всередині підприємства. Деяка
інформація може бути доступна всьому персоналу, інша частина інформації не
повинна виходити за рамки відділу. Наприклад, доступ до всієї інформації з
заробітної плати співробітників повинен мати тільки працівник бухгалтерії,
займається її нарахуванням. Всі інші співробітники підприємства в цьому
випадку володіють інформацією тільки про розмір своєї заробітної плати. Третя
категорія інформації є суворо конфіденційною і повинна бути доступна
тільки певним людям. Прикладом може служити відомості про власних оригінальних
розробки та технології, які компанія прагне вберегти від конкурентів.
Вихід такої інформації за межі компанії може принести великі збитки.
Крім крадіжки інформації є можливість її
ушкодження внаслідок помилки оператора або неправильно написаного програми.
Наслідки таких дій можуть спричинити за собою серйозні фінансові втрати.
Наприклад, якщо дані про клієнтів будуть втрачені, доведеться заново збирати
потрібну інформацію. А це втрата часу, фінансів, та й конкуренти в цей час
скористаються ситуацією і захоплять ринок.
У сучасних умовах, коли інформація має
величезне значення, вживання заходів для запобігання несанкціонованого
доступу, попередження втрати або пошкодження інформації стають
невід'ємною частиною роботи будь-якої компанії. Останнім часом все більше
підприємств відмовляються від паперових сховищ інформації і переходять до
комп'ютерної обробки документів. Система зберігання інформації повинна бути
максимально захищена як від випадкового, так і від навмисного пошкодження
або перекручування інформації. При створенні бази даних розробник повинен
спланувати її таким чином, щоб будь-який користувач не міг зробити
будь-що, не маючи на це відповідних прав. Не слід сподіватися на
компетентність користувача і його порядність. Можливе виправлення або
видалення даних не зі злого наміру, а просто через неуважність або помилки.
Система, наскільки це можливо, повинна перешкоджати подібним діям. [10]
Система управління базами даних Microsoft SQL Server
2000 має різноманітні засоби адміністрування для забезпечення захисту
даних
Загальні правила розмежування доступу
Якщо база даних призначена для використання більш
ніж однією людиною, необхідно подбати про розмежування прав доступу. У
процесі планування системи безпеки слід визначити, які дані
можуть переглядати ті чи інші користувачі і які дії в базі даних ним
дозволено при цьому робити.
Після проектування логічної структури бази даних,
зв'язків між таблицями, обмежень цілісності та інших структур необхідно
визначити коло користувачів, які будуть мати доступ до бази даних. Щоб
дозволити цим користувачам звертатися до сервера, необхідно створити для них
облікові записи в SQL Server або надати їм доступ за допомогою облікових
записів у домені, якщо використовується система безпеки Windows NT. Дозвіл
доступу до сервера не дає автоматично доступу до бази даних та її об'єктах.
Другий етап планування системи безпеки
полягає у визначенні дій, які може виконувати в базі даних
окремий користувач. Повний доступ до бази даних і всім її об'єктів має
адміністратор, який є свого роду господарем бази даних - йому
дозволено все. Друга людина після адміністратора - це власник об'єкта. При
створення будь-якого об'єкта в базі даних йому призначається власник, який може
встановлювати права доступу до цього об'єкта, модифікувати його і видаляти.
Третя категорія користувачів має права доступу, видані їм
адміністратором або власником об'єкта.
Слід ретельно планувати права, що видаються
користувачам відповідно до займаної посади і необхідністю
виконання конкретних дій. Так зовсім необов'язково призначати права на
зміна даних у таблиці, що містить відомості про зарплату співробітників,
директору компанії. І, звичайно ж, не можна надавати подібні права рядовому
співробітнику. Ви можете видати права лише на введення нових даних, наприклад
інформації про нових клієнтів. Неправильний введення такої інформації не завдасть
серйозного збитку компанії, але якщо додати до прав введення ще й можливість
виправлення або видалення вже існуючих даних, то зловмисник, заволодів
паролем, може нанести істотні фінансові втрати. Крім цього, слід
врахувати збиток від роботи користувачів, які не сильно замислюються про наслідки
своїх дій.
Правильно спроектована система безпеки не
повинна дозволяти користувачу виконувати дії, що виходять за рамки його
повноважень. Не зайвим також буде передбачити додаткові засоби захисту,
наприклад, не дозволяти видаляти дані, якщо термін їх зберігання не закінчився, тобто
вони не втратили актуальність. Можна також надавати службовцям, які нещодавно
влаштувалися на роботу, мінімальний доступ або доступ тільки в режимі читання.
Пізніше їм можна буде вирішити і зміна даних.
Слід уважно ставитися до руху співробітників
всередині компанії, їх переходах з одного відділу в іншій. Зміни займаної
посади повинні негайно відбиватися на правах доступу. Своєчасно
сдеует видаляти користувачів, які більше не працюють у компанії. Якщо залишити
людині, який обіймав керівну посаду і пішов у конкуруючу фірму,
доступ до даних, він може скористатися ними і завдати шкоди вашій компанії.
Архітектура системи безпеки SQL Server 2000
Система безпеки
Система безпеки SQL Server 2000 базується на
користувачів та облікових записах. Користувачі проходять наступні два етапи
перевірки системою безпеки. На першому етапі користувач ідентифікується
на ім'я облікового запису та паролю, тобто проходить аутентифікацію. Якщо дані
введені правильно, користувач підключається до SQL Server. Підключення до SQL
Server, або реєстрація, не дає автоматичного доступу до баз даних. Для
кожної бази даних сервера реєстраційне ім'я (або обліковий запис - login)
має відображатися в ім'я користувача бази даних (user). На другому етапі, на
основі прав, наданих користувачеві як користувачеві бази даних (user), його реєстраційне
ім'я (login) отримує доступ до відповідної бази даних. У різних базах
даних login одного і того ж користувача може мати однакові або різні
імена user з різними правами доступу.
Для доступу програм до баз даних їм також
знадобляться права. Найчастіше додаткам видаються ті ж права, які
надані користувачам, що запускають ці програми. Проте для роботи
деяких програм необхідно мати фіксований набір прав доступу, не
залежать від прав доступу користувача. SQL Server 2000 дозволяє надати
такі із застосуванням спеціальних ролей програми.
Отже, на рівні сервера система безпеки оперує
наступними поняттями:
1) аутентифікація (authentication);
2) обліковий запис (login);
3) вбудовані ролі сервера (fixed server roles).
На рівні бази даних використовуються такі поняття:
користувач бази даних (database user); фіксована роль бази даних (fixed
database role); користувальницька роль бази даних (users database role); роль
додатки (application role). [11]
Режими аутентифікації
SQL Server 2000 може використовувати два режими
аутентифікації користувачів: режим аутентифікації засобами Windows NT/2000 (Windows
NT Authentication); змішаний режим аутентифікації (Windows NT Authentication
and SQL Server Authentication).
Змішаний режим дозволяє користувачам
реєструватися як засобами Windows NT, так і засобами SQL Server. Крім
того, цей режим пропонує деякі зручності в порівнянні з першим. У
Зокрема, при аутентифікації тільки засобами домену Windows NT, якщо
користувач не має облікового запису в домені Windows NT, то він не зможе
отримати доступу до сервера баз даних. Змішаний режим аутентифікації дозволяє
уникнути цієї проблеми. [12]
При виборі режиму аутентифікації слід виходити як
з вимог забезпечення найбільшої безпеки, так і з міркувань
простоти адміністрування. Якщо ваша організація невелика і посади
адміністратора мережі і адміністратора баз даних поєднує одна людина, то
зручніше використовувати аутентифікацію Windows NT. Якщо ж в організації сотні
користувачів і функції системного адміністратора та адміністратора баз даних
виконують різні люди, то може виявитися, що аутентифікація засобами
SQL Server зручніше. В іншому випадку людині, що займається адмініструванням
сервера баз даних, доведеться постійно звертатися до системного адміністратора
для створення нового користувача, зміни пароля або для перекладу користувача
з однієї групи в іншу. До того ж системний адміністратор буде мати
можливість призначати права доступу на свій розсуд, а це зовсім ні до
чого.
З іншого боку, кожен користувач організації,
швидше за все, має в домені обліковий запис, адмініструванням якої
займається системний адміністратор. Завдяки аутентифікації Windows NT
адміністратор баз даних може використовувати вже готові облікові записи, а не
відволікатися на створення нових.
Режим аутентифікації SQL Server
Щоб встановити з'єднання з сервером SQL Server 2000,
що знаходиться в домені, з яким не встановлені довірчі відносини, можна
використовувати аутентифікацію SQL Server. Аутентифікація SQL Server також
використовується, коли взагалі немає можливості зареєструватися в домені.
Наприклад, при підключенні до SQL Server 2000 по Інтернету.
При роботі з аутентифікації SQL Server доступ також
надається на основі облікових записів. Але в цьому випадку використовуються
облікові записи SQL Server, а не Windows NT.
Для аутентифікації засобами SQL Server Server член
стандартної ролі сервера sysadmin або securityadmin повинен створити і
настроїти для користувача обліковий запис, в яку входить ім'я облікового
запису, унікальний ідентифікатор SQL Server і пароль. Вся ця інформація буде
зберігатися в системній базі master. Створювана обліковий запис не має
відносини до облікових записів Windows NT.
У цьому режимі при спробі користувача отримати доступ
до SQL Server сервер сам перевіряє правильність імені користувача та пароль,
порівнюючи їх з даними в системних таблицях. Якщо дані, введені
користувачем, збігаються з даними SQL Server, користувачеві дозволяється доступ
до сервера. В іншому випадку спроба доступу відхиляється і видається повідомлення
про помилку.
Аутентифікація SQL Server може застосовуватися в
наступних випадках: для користувачів Novell NetWare, Unix і т. д.; при
підключенні до SQL Server 2000 через Інтернет, коли реєстрація в домені НЕ
виконується; під керуванням операційної системи Windows 98.
У більшості випадків обліковий запис в SQL Server
створюється з метою надання доступу. Але бувають ситуації, коли необхідно
заборонити доступ користувачу або групі. Наприклад, за наявності складної системи
безпеки Windows NT доступ зазвичай надається групі користувачів.
Однак якщо в групі є людина, якій не можна дозволяти доступ до SQL
Server, його необхідно прибрати з цієї групи. Але такий підхід незадовільний,
якщо група призначена не тільки для об'єднання користувачів, які мають
доступ до SQL Server, але має ще й якісь додаткові функції. SQL Server
дозволяє створити обліковий запис з метою заборони доступу. Це гарантує,
що користувач ніяким чином не зможе встановити з'єднання з сервером.
Створивши групу Windows NT і заборонивши їй доступ до SQL Server, ви можете включати
в неї користувачів, яким необхідно відмовити в доступі. [13]
Компоненти структури безпеки
Фундаментом системи безпеки SQL Server 2000
є облікові записи (login), користувачі (user), ролі (role) і групи
(group).
Користувач, що підключається до SQL Server, повинен
ідентифікувати себе, використовуючи обліковий запис. Після того, як клієнт успішно
пройшов аутентифікацію, він отримує доступ до SQL Server. Для отримання доступу до
будь-якій базі даних облікова запись користувача (login) відображається в
користувача даної бази даних (user). Об'єкт «користувач бази даних»
застосовується для надання доступу до всіх об'єктів бази даних: таблиць,
уявленням, що зберігається процедурами і т. д. У користувача бази даних може
відображатися: обліковий запис Windows NT; група Windows NT; обліковий запис SQL
Server.
Подібне відображення облікового запису необхідно для
кожної бази даних, доступ до якої хоче отримати користувач. Відображення
зберігаються в системній таблиці sysusers, яка є в будь-якій базі даних.
Такий підхід забезпечує високу ступінь безпеки, запобігаючи
надання користувачам, що отримала доступ до SQL Server, автоматичного
доступу до всіх баз даних та їх об'єктів. Користувачі баз даних, у свою
чергу, можуть об'єднуватися в групи і ролі для спрощення керуванням системою
безпеки.
У ситуації, коли профіль не відображається в
користувача бази даних, клієнт все ж таки може отримати доступ до бази даних
під гостьовим ім'ям guest, якщо воно, звісно, є в базі даних. Зазвичай
користувачеві guest надається мінімальний доступ тільки в режимі читання.
Але в деяких ситуаціях і цей доступ необхідно запобігти.
Якщо в мережі є невелика кількість
користувачів, то досить легко надати доступ кожному користувачеві
персонально. Однак у великих мережах з сотнями користувачів подібний підхід
займе багато часу. Набагато більш зручним і ефективним є підхід,
коли доступ до SQL Server 2000 надається цілих груп користувачів. Як
саме такий підхід можливий при аутентифікації засобами Windows NT/2000, коли
на рівні домену створюється кілька груп, кожна з яких призначена
для вирішення специфічних завдань. На рівні SQL Server 2000 такій групі
дозволяється доступ до сервера, надаються необхідні права доступу до баз
даних та їх об'єктів. Досить включити обліковий запис Windows NT в одну з
груп, і користувач отримає усі повноваження, надані цій групі.
Більше того, одна й та ж обліковий запис може бути включена у безліч груп
Windows NT, що дасть цього облікового запису можливість користуватися правами
доступу, наданими всім цим групам. Адміністратор SQL Server 2000
повинен сам вирішити, як зручніше надавати доступ до сервера: персонально
кожного облікового запису або групи в цілому. [14]
Користувачі
Після того як користувач пройшов аутентифікацію та
отримав ідентифікатор облікового запису (login ID), він вважається
зареєстрованим і йому надається доступ до сервера. Для кожної бази
даних, до об'єктів якої користувачеві потрібно отримати доступ, облікова
запис користувача (login) асоціюється з користувачем (user) конкретної
бази даних. Користувачі виступають у якості спеціальних об'єктів SQL Server,
за допомогою яких визначаються всі дозволи доступу і володіння об'єктами в
базі даних.
Ім'я користувача може використовуватися для
надання доступу як конкретній людині, так і цілої групи людей (в
залежно від типу
