може створити роль і призначити певні права доступу для цієї ролі. Потім роль може бути присвоєна одному або декільком користувачам. Адміністрування безпеки бази даних таким чином спрощується. Наприклад, розглянемо таку послідовність операторів:
CREATE role MANAGER; COMMIT;
GRANT select , insert, update, delete on employee to MANAGER; GRANT select, insert, update, delete on job_title to MANAGER;
GRANT execute on payroll to MANAGER; COMMIT;
GRANT MANAGER to userl; COMMIT;
Цей сценарій створює нову роль під назвою MANAGER, видає права доступу до певних таблиць і процедурам для ролі, а потім привласнює користувачеві userl роль MANAGER.
Роль MANAGER може бути призначена й іншим користувачам, а адміністратору баз даних не потрібно буде пам’ятати про видачу для кожного з них окремого оператора GRANT, оскільки їм уже була привласнена роль MANAGER.
Групи
Право доступу рівня групи схоже з роллю. Проте кожна СУБД надає вбудовані групи, які не можуть бути змінені. Кожна СУБД реалізує безпеку бази даних на рівні групи різними шляхами, під різними назвами і з різними правами доступу. Однак існують деякі подібні елементи в усіх СУБД. Далі перелічені групи є загальними для основних СУБД.
Системний адміністратор. Іноді скорочується як SA або SYSADM,
група системного адміністратора є найбільш потужною в СУБД. Користувач, якому надається право доступу рівня системного адміністратора, звичайно може виконувати всі команди бази даних і отримувати доступ до всіх баз даних і об’єктів. Системний адміністратор зазвичай відповідає за установку СУБД і вважається власником системних ресурсів і таблиць системного каталогу.
Адміністратор баз даних. Іноді скорочується як DBADM або DBA, група адміністратора баз даних дає всі права доступу до визначеної бази даних плюс здатність отримувати доступ, але не модифікувати дані в таблицях в межах цієї бази даних. Користувачі, яким присвоєно право
421
доступу рівня адміністратора баз даних, можуть видаляти або змінювати будь-які об’єкти в базі даних (табличні області, таблиці та індекси).
Обслуговування бази даних. Іноді скорочується як DBMAINT,
група обслуговування баз даних включає певні права доступу до бази даних для обслуговування об’єктів баз даних (як наприклад, здатність запускати утиліти і видавати команди). Подібно групі адміністраторів баз даних, право доступу рівня DBMAINT надається на основі бази даних.
Адміністратор безпеки. Роль адміністратора безпеки має набір прав доступу, що дозволяє видачу та скасування безпеки бази даних у СУБД.
Будь-яка діяльність, пов’язана з безпекою бази даних, може виконуватися адміністратором безпеки, включаючи адміністрування реєстраційних імен і паролів, аудит, конфігурування властивостей безпечності, а також видачу GRANT і REVOKE. Іншою загальною назвою ролі адміністратора безпеки є SSO.
Контроль операцій. Іноді звана OPER або SYSOPR, роль контролю операцій має право виконувати завдання працюючої бази даних, такі, як резервування і відновлення або завершення завдань: які вийшли з-під контролю.
Обмеження кількості користувачів-системних адміністраторів
Організація повинна обмежувати кількість користувачів, яким назначається роль системного адміністратора або право доступу рівня групи. Користувач з можливостями системного адміністратора має дуже потужну владу. Тільки корпоративні адміністратори баз даних і системні програмісти повинні отримувати права доступу такого рівня. Кінцеві користувачі, менеджери і персонал розробки додатків не потребують правах доступу системного адміністратора для виконання своєї роботи.
Безпека рівня групи і каскадні REVOKE. Залежно від групи деякі користувачі, яким були призначені права доступу рівня групи, можуть видавати права доступу іншим користувачам. Якщо право доступу рівня групи скасовується для цього користувача, будь-які права доступу, видані цим користувачем, також будуть скасовані. Це подібно каскадним REVOKE, які відбуваються в результаті вибору WITH GRANT OPTION.
Перед скасуванням права доступу рівня групи для користувача переконайтеся, що встановили вплив каскадних REVOKE і готові до того, щоб встановити повторно необхідні права доступу, які будуть видалені через ефект каскадування.
Використання транзакції для ізолювання дій користувачів Визначення транзакцій
Транзакція – це атомарна частка роботи щодо відновлення і узгодженості. Логічна транзакція виконує повний діловий процес зазвичай від особи онлайн-користувача. Вона може складатися з декількох етапів та містити більше однієї фізичної транзакції. Результати запуску транзакції реєструють вплив ділового процесу – завершеного ділового процесу. Після виконання транзакції дані в базі даних повинні бути правильними і коректними.
Коли всі етапи, які складають певну транзакцію, будуть виконані, буде виданий COMMIT. COMMIT сигналізує про те, що вся робота починаючи з останньої фіксації (СОММIT), була коректна і повинна бути поміщена в базу даних. У будь-якій точці транзакції може бути прийнято рішення про зупинку і відкат впливів всіх змін, починаючи з останнього COMMIT. При відкаті транзакції дані в базі даних будуть перезаписані в первинний стан до запуску транзакції. СУБД зберігає журнал реєстрації транзакцій для відстеження змін бази даних.
Транзакції мають властивості АУІС (АУІС). АСІД – це абревіатура таких властивостей, як атомарність, узгодженість, ізольованість і стійкість. Кожне з цих чотирьох властивостей необхідно для правильного проектування транзакції.
Атомарність означає, що транзакція повинна представляти поведінку "все або нічого". Або всі з вказівок відбуваються в транзакції, або ні одне з них. Атомарність зберігає повноту виконання ділового процесу.
Узгодженість відноситься до стану даних як до, так і після виконання транзакції. Транзакція підтримує узгодженість стану даних. Іншими словами, після запуску транзакції всі дані в базі даних є "коректними".
Ізольованість означає, що транзакції можуть працювати одночасно. Будь транзакції, запущені паралельно, мають ілюзію, що паралельності немає. Іншими словами, здається, що система запускає тільки одну транзакцію одночасно. Жодну з інших паралельних транзакцій не видно незавершеним модифікаціям бази даних, виконуваним іншими транзакціями. Щоб досягти ізольованості, потрібно використовувати механізм блокування.
Стійкість відноситься до впливу простою або збою в роботі на діючу транзакцію. Стійка транзакція не буде впливати на стан даних, якщо робота транзакції припиниться неправильно. Дані переживуть будь-які збої.
Отримання несанкціонованого доступу до конфіденційної інформації шляхом логічних висновків
Захист СУБД є одним з найпростіших завдань. Це пов’язано з тим, що СУБД мають чітко визначену внутрішню структуру, і операції над елементами СУБД задані досить чітко. Є чотири основних дії – пошук, вставка, видалення і заміна елемента. Інші операції є допоміжними і застосовуються досить рідко. Наявність чіткої структури і чітко визначених операцій спрощує рішення задачі захисту СУБД. У більшості випадків хакери вважають за краще зламувати захист комп’ютерної системи на рівні операційної системи і отримувати доступ до файлів СУБД за допомогою засобів операційної системи. Однак у випадку, якщо використовується СУБД, що не має достатньо надійних захисних механізмів, або погано протестована версія СУБД, що містить помилки, або якщо при визначенні політики безпеки адміністратором СУБД були допущені помилки, то стає цілком ймовірним подолання хакером захисту, реалізованого на рівні СУБД.
Крім того, існує два специфічних сценарії атаки на СУБД, для захисту від яких потрібно застосовувати спеціальні методи. У першому випадку результати арифметичних операцій над числовими полями СУБД округляються в меншу сторону, а різниця підсумовується в деякому іншому записі СУБД (як правило, цей запис містить особовий рахунок хакера в банку, а числові поля, які округляються, відносяться до рахунків інших клієнтів банку). У другому випадку хакер отримує доступ до полів записів СУБД, для яких доступна тільки статистична інформація. Ідея хакерської атаки на СУБД – так хитро сформулювати запит, щоб безліч записів, для якого збирається статистика, складалося тільки з одного запису.
Особливості застосування криптографічних методів
Для полегшення використання баз даних існує безліч менеджерів (засобів управління базами даних), для забезпечення криптографічного захисту в засоби управління додані функції по шифруванню і дешифруванню даних. Такі функції в основному працюють практично за кадром тобто користувачу або адміністратору досить вказати що дані є приватними або подібними мітками позначити криптографічний захист. Ось деякі приклади:
Захищеність (Security) в Microsoft Message Queue Server. Сервер черг використовує списки прав доступу (ACL) Windows NT для визначення прав доступу до черги. Застосовуються також інші системи захисту, засновані на використанні відкритих (Public) ключів (система
захисту заснована на використанні API з RSA-провайдером). Для перевірки цілісності повідомлень застосовуються контрольні суми. Сервер черг використовує алгоритми шифрування RC2 і RC4; за замовчуванням вибирається алгоритм RC2. Для шифрування повідомлення додаток простопривласнює йому атрибут "private", все інше буде зроблено автоматично.
Технології віддаленого доступу до систем баз даних, тиражування та синхронізація в розподілених системах баз даних
В умовах, коли швидко розвиваються технології, доступність інформації є дуже важливим фактором, в умовах віддаленого доступу хорошим способом є кошти мережі Інтернет, розглянемо доступ до сервера СУБД через web-сервер. Для доступу web-навігатора до сервера СУБД через web-сервер використовується система програмних шлюзів. Програмний шлюз, отримавши запит від web-сервера, виступає в якості посередника між сервером web і сервером СУБД. Програмні шлюзи розробляються відповідно до визначених стандартів, визначальними способи виклику web-сервером прикладних програм або функцій динамічних бібліотек, а також способи обміну інформацією з цими програмними об’єктами. Одними з найбільш поширених стандартів даного типу є інтерфейс CGI (Common Gateway Interface – загальний інтерфейс шлюзів), а також його вдосконалена специфікація, названа як
FastCGI (прискорений CGI).
Інтерфейс CGI. Для доступу web-навігатора до сервера СУБД через Web-сервер за стандартом CGI необхідна відповідна CGIпрограма, що виконує роль програмного шлюзу між web-сервером і сервером СУБД (рис. 12.8).
Рис 12.8. Схема доступу до СУБД через CGI-програму
CGI-додатки працюють незалежно від web-сервера, а їх запуск здійснюється за викликом з web-документа при його обробці webнавігатором. CGI-програма взаємодіє з web-сервером за допомогою двостороннього обміну змінними середовища через стандартні канали вводу/виводу даного додатка.
Оскільки CGI-програми працюють незалежно від web-сервера і мають простий спільний інтерфейс, розробники web-документів мають можливість створювати свої CGI-програми будь-якою мовою, що підтримує стандартні файлові операції вводу/виводу. Крім того, при незалежній розробці можна створювати такі додатки, які з легкістю переносяться з одного на інший web-сервер. Існують і стандартні CGIпрограми, спеціально розроблені для взаємодії web-серверів з різними СУБД, наприклад, програма WebDBC.
У якості інтерфейсу між web-навігатором і сервером СУБД у складі web-документів застосовують HTML-форми, які дозволяють формулювати запити до бази даних. CGI-програма отримує інформацію від webсервера або через змінні оточення, або через стандартний ввід. Все залежить від методу доступу, який використовується при обміні даними між web-навігатором і web-сервером. Далі CGI-програма через драйвер
ODBC (Open DataBase Connectivity) звертається до сервера СУБД і повертає web-серверу відповідь на запит через стандартний вивід.
Драйвер ODBC забезпечує уніфікований спосіб доступу до різних СУБД за допомогою стандартної мови запитів SQL. Завдяки стандарту ODBC прикладні програми можуть використовувати єдиний діалект SQL і взаємодіяти з різними СУБД. Можна обійтися і без драйвера ODBC, але в цьому випадку CGI-програма повинна бути написана з орієнтацією на конкретну СУБД, що функціонує на сервері.
Таким чином, розробнику CGI-додатки не треба нічого знати про те, як влаштований web-сервер. Більше того, йому зовсім не обов’язково використовувати складні мови типу C++. CGI-програма може бути написана і командною мовою, наприклад Perl. Головне – витримати всі угоди, що накладаються стандартом CGI. Такий підхід істотно полегшує розробку прикладного програмного забезпечення для web взагалі і для сполучення баз даних з web-сервером зокрема.
Стандарт CGI володіє і недоліком – зниження швидкості обробки заптів при збільшенні інтенсивності їх надходження. При кожному виклику CGI-програми її доводиться завантажувати з диска (тобто
запускати новий процес). По завершенні роботи програми потрібно звільнити ресурси, які використовувалися нею. Такі операції створюють помітне додаткове навантаження на сервер, що позначається на його продуктивності. До того ж запуск нового процесу при кожному запиті знижує ефективність постійних процесів і доступність даних. Інформацію, яка згенерована в ході обробки одного запиту, неможливо використовувати при обробці іншого.
Інтерфейси API і FastCGI
Для того, щоб обійти проблеми, пов’язані зі швидкодією CGI, багато постачальників web-серверів, включаючи Microsoft і Netscape, розробили відповідні інтерфейси прикладного програмування (API). Корпорацією Microsoft був розроблений інтерфейс ISAPI (Інтернет Server API), a
корпорацією Netscape – інтерфейс NSAPI (Netscape Server API).
Ці інтерфейси тісно інтегровані з web-сервером, дозволяючи зберігати доступність постійно використовуваних процесів і даних. Програми з інтерфейсом ISAPI компілюються у файли, динамічно підключаються бібліотек DLL. Вони завантажуються в пам’ять під час першого звернення до них і тому для повторного виклику цих програм не потрібно породжувати новий процес. Функції інтерфейсу NSAPI завантажуються в серверний простір процесів. Відповідно при виклику цих функцій також не породжуються додаткові процеси. Завдяки APIінтерфейсу програма, яка його використовує, може залишати з’єднання з СУБД відкритим, тому наступному запиту до бази даних не доведеться витрачати час на відкриття і закриття з’єднання.
Однак API-інтерфейси web-серверів – хоч і непогане, але нестандартне рішення. Більшість додатків можна переносити з одного API на інший, і дуже рідко вдається перенести додатки на інші платформи. Крім того, більшість додатків для web-серверів все ще створюються для інтерфейсу CGI, тому перехід до додатків на базі API не є економічно виправданим.
Тому стали з’являтися способи побудови деякого проміжного варіанта, який, з одного боку, задовольняв би вимогам мобільності, незалежності та простоти програмування, а з іншого боку – був би досить ефективним. Одним з таких рішень є специфікація FastCGI. Ідея цієї специфікації у тому, що прикладна програма використовує спосіб передачі параметрів і даних, який використовується в CGI, але при цьому не видаляється з пам’яті, а залишається резидентною, обробляючи запити, що надходять.
Таким чином, додатки на базі FastCGI, подібно CGI-програмами, працюють незалежно від web-сервера і запускаються через стандартні посилання в web-документах. Але, як і програми на базі API, програми для FastCGI є постійно діючими. Коли програма закінчує обробку чергового запиту, її процес залишається відкритим в очікуванні нового запиту.
При доступі web-навігатора до реляційної бази даних через інтерфейс FastCGI виходить схема, в якій фактично використовуються три сервера: web-сервер, FastCGI-програма і сервер бази даних. webсервер отримує запит web-навігатора і передає його FastCGI-програмі, яка в свою чергу звертається до сервера баз даних. Результат повертається за зворотнім ланцюжком. Наведемо приклад дещо іншої технології віддаленого доступу: RMI-додатки.
RMI (Remote Method Invocation) – виклик віддалених методів,
забезпечує засоби комунікації між Java-програмами, навіть якщо вони виконуються на різних комп’ютерах, що знаходяться в протилежних точках.
Важлива особливість RMI полягає в тому, що він представляє програмуємий інтерфейс, який програмується, для роботи з мережами на відміну від сокетів TCP. Головна перевага його в тому, що він пропонує вам інтерфейс більш високого рівня, заснований на викликах методів так, як якщо б видалений об’єкт оброблявся локально. RMI більш зручний і природний, ніж інтерфейс, заснований на сокетах, але він вимагає виконання Java-програм на обох кінцях з’єднання. Мережне з’єднання досягається використанням все того ж ТСР-ІР-протоколу.
Кластерна організація серверів баз даних Дублювання серверів
Описані способи забезпечення надійного зберігання даних можна використовувати, тільки коли сам сервер працює надійно. У разі несправності сервера його клієнти будуть на якийсь час позбавлені можливості доступу до даних. І це триватиме тим довше, чим більше часу буде потрібно адміністратору на відновлення самого сервера або даних з стрічки на іншому сервері. Тому виникає необхідність резервування інформації в реальному масштабі часу.
Фірмою Octopus Technologies Inc випускається продукт Octopus Real Time Data Protection. З його допомогою можна організувати дублювання файлів або каталогів з одного сервера на один або декілька
інших серверів або робочих станцій. Інформацією, що посилається в дублікати каталогів, є тільки оновлення файлів і каталогів. Наприклад, якщо використовувати Octopus для резервування бази даних, по мережі реально передаються тільки оновлення (видалені або додані записи). Якби кожного разу передавалася вся база, то це призвело б до різкого зростання трафіка в мережі і зниження її продуктивності.
Ще одна перевага полягає в тому, що сервери пов’язані звичайною мережею, і при цьому не вимагається особливий протокол. Досить встановити серверну частину на комп’ютер, дані якого повинні резервуватися, і клієнтську частину – на комп’ютери, куди будуть надходити дані. Можливі такі комбінації резервування: з одного сервера на інший, з одного на кілька інших, з декількох на кілька і з декількох на один. Оновлення файлів виконуються на рівні транзакцій.
У разі краху сервера при використанні стандартної версії Octopus адміністратор системи повинен або відновити вихідний сервер, або перемкнути всіх користувачів на той, який був дублікатом. Останні версії Octopus мають додаткову функцію автоматичного перемикання, що дозволяє відразу ж перемикати користувачів на дублікат сервера при краху основного. У будь-якому випадку останні версії файлів залишаться збереженими.
Незважаючи на простоту і відносно невисоку вартість, у такої системи є мінус: користувачам необхідно переключатися на новий сервер, перезапускати процеси і заново відкривати файли. До того ж при цьому втрачається і вміст оперативної пам’яті.
Кластери серверів
Вища надійність досягається за допомогою кластерних систем, що забезпечують не тільки надійність зберігання даних, але і безперервність процесів, що виконуються в кластері, а також продуктивність, обумовлену сукупністю всіх серверів, що входять у кластер.
Кластером називається група незалежних систем, які працюють як єдине ціле. Клієнт взаємодіє з кластером як з одним сервером. Кластери використовуються як для підвищення доступності, так і для нарощуваності.
Доступність: коли одна з систем, складових кластера, виходить з ладу, програмне забезпечення кластера розподіляє роботу, виконувану нею, між іншими системами кластера.
429
Нарощуваність: коли загальне завантаження системи досягає межі можливостей систем, які складають кластер, його можна наростити, додавши додаткову систему. Раніше для цього потрібно було здобувати нові комп’ютери, що дозволяють встановити додаткові процесори, диски і пам’ять. За допомогою кластерів можна збільшити продуктивність в міру необхідності, просто додаючи нові системи.
Наприклад, можна навести роботу сучасного супермаркету. Касові апарати в його розрахункових центрах повинні бути постійно підключені до бази даних магазину, що зберігає інформацію про продукти, коди, назви і ціни. Якщо зв’язок рветься, то втрачається можливість обслуговування клієнтів, падає прибуток, і, що найгірше – підривається репутація підприємства.
У цьому випадку кластерна технологія використовується для підвищення доступності системи. В даному випадку можна запропонувати використання двох систем, підключених до багатопортового дискового масиву, на якому розташовується база даних. У разі збою одного з серверів резервна система (інший сервер) автоматично підхопить з’єднання так, що користувачі і не помітять, що стався збій. Таким чином, комбінуючи стандартну технологію забезпечення підвищеної надійності роботи з диском (чергування, дублювання і тощо) з кластерною технологією, можна забезпечити гарантовану достовірність інформації в системі.
Нарощуваність системи дозволяє відмовитися від дорогого устаткування ПК і використовувати широко розповсюджену систему на звичайних апаратних платформах навіть у таких ресурсоємних додатках, як фінансові або банківські системи. Нарощування потужності досягається додаванням ще однієї системи в кластер.
Традиційна архітектура високої надійності та нарощуваності
Підвищення надійності комп’ютерних систем досягається кількома способами. Самий типовий – дублювання систем з повністю повторюваними компонентами. Програмне забезпечення такої системи повністю відстежує стан працюючої системи, а друга система весь цей час простоює. У разі збою першої відбувається перемикання на другу. Такий підхід, з одного боку, значно підвищує вартість устаткування без підвищення продуктивності системи в цілому, а з іншого – не забезпечує захисту від помилок у додатках.
