Адміністративні методи захисту

Сучасні СУБД оснащені механізмами, які забезпечують “живучість” сервера. Засоби, розглянуті нами раніше, реалізовані на рівні кода СУБД або на рівні додатків самої системи (збережені процедури, тригери ...).

Механізм під назвою treshold є певною реакцією системи на події в ній. Treshold є, по суті, збереженою процедурою, яка запускається при настанні певної події в СУБД. Наприклад, при переповненні лога транзакцій запускається treshold, який блокує deadlock (“намертво”) будь-яку операцію, що формує транзакцію, і робить запис в лозі адміністратора про настання критичної ситуації. Приблизно так само поводить себе treshold, реагуючий на переповнення сховища даних.

Захист даних від деструктивних дій користувачів є основною задачею адміністратора бази даних. Щоб забезпечити такий захист, важливо здійснювати контроль доступу користувачів до даних. Для цього використовуються права доступу (permission) для ролі сервера, облікового запису (login) або запису користувача.

Право доступу – це дозвіл на отримання доступу до певного об’єкта в базі даних (наприклад, до таблиці). Права надаються деякому запису користувача або ролі і дозволяють їм виконувати деякі операції, наприклад, виборки даних, вставку нових записів чи оновлення вже існуючих. Для кожного з типів об’єктів бази даних є декілька видів прав доступу. Їх ми розглянемо трохи нижче.

Всі права доступу автоматично надються власнику чи тому, хто створює об’єкт. В подальшому власник може прийняти рішення про надання іншим користувачам або їх групам тих прав, які їм необхідні.

Власник бази даних (Database owner – DBO) має повний набір прав по відношенню до всiх об’єктів бази даних.

Системний адміністратор (System administrator – SA) має повний набір прав по відношенню до всіх об’єктів в усіх базах даних на сервері.

Для надання або відміни прав користувача в MS SQL Server, наприклад, є команди GRANT i REVOKE.

Права доступу до об’єкта (object permission) представляють собою дозволи на виконання конкретних дій над таблицями та іншими об’єктами в базі даних, наприклад, над представленнями і збереженими процедурами.

Для доступу до таблиць і їх описів існують такі типи прав:

• SELECT – дозволяє користувачу вибирати або читати дані з таблиці або представлення таблиці;

• Insert – дозволяє користувачу заносити нові дані в таблицю або представлення таблиці;

• UPDATE – дозволяє користувачу змінювати дані в таблиці або представленні;

• DELETE – дозволяє користувачу видаляти дані з таблиці або представлення;

• EXECUTE – дозволяє користувачу виконувати збережені процедури;

• DRI/REFERENCES – дозволяє користувачу додавати до таблиці обмеження, які описуються зовнішнім ключем;

• DDL/Data Definition Language – дозволяє користувачу створювати, змінювати і оновлювати об’єкти бази даних (наприклад, командами CREATE TABLE, DROP DATABASE, ALTER TABLE);

• ALL – надає користувачу повний набір прав щодо даного об’єкта. Зауважимо, що, коли для об’єкта вже назначені права типу DDL, права типу ALL на цей об’єкт може надати лише SA.

Розсинхронізація даних в розподіленій моделі

При організації розподіленої бази даних, виникає необхідність синхронізувати деякі дані. Як найбільш вдалий приклад цього можна навести архітектуру, в якій є загальні системні довідники. Так, внесення змін у довідник однієї бази буде вимагати від адміністратора системи внести такі ж самі зміни у довідники другої бази.

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

Довідники змінюються не часто, але якщо синхронізувати доводиться данні, які оновлюються декілька разів на годину, то реплікація є найбільш логічним рішенням. Реалізація підключення програми до бази при використанні стандартних системних драйверів (наприклад, ODBC) буде займати ресурси операційної системи, цього можна уникнути, якщо використовувати пряме підключення засобами виробника СУБД. Але й це не надасть переваги над реплікацією, оскільки програма буде для СУБД звичайним користувачем з визначеним рівнем ізоляції при збільшенні якого може виникати deadlock таблиці.

Отже програма-синхронізатор буде працювати значно довше реплікації, з’їдати більше системних ресурсів ще й утворюючи аварійні ситуації. Зрозуміло, що витративши N годин, програму можна зробити негірше реплікації, але це є вже питанням наявності проблем у експлуатації реплікації або вільного часу у програмістів.