БЕЗПЕКА БАЗИ ДАНИХ

Безпека бази даних


Про переважно спеціалізуються формою організації інформаційних масивів в ІС є бази даних. Базу даних можна визначити як сукупність взаємопов'язаних зберігаються разом даних при наявності такої мінімальної надмірності, яка допускає їх використання оптимальним чином для одного або декількох додатків. На відміну від файлової системи організації і використання інформації, БД існує незалежно від конкретної програми і призначена для спільного використання багатьма користувачами. Така централізація і незалежність даних в технології БД зажадали створення відповідних СУБД - складних комплексів програм, які забезпечують виконання операцій коректного розміщення даних, надійного їх зберігання, пошуку, модифікації і видалення.

Про АГАЛЬНІ вимоги з безпеки даних, які пред'являються до БД і СУБД, багато в чому збігаються з вимогами, що пред'являються до безпеки даних в комп'ютерних системах - контроль доступу, криптозащита, перевірка цілісності, протоколювання і т.д.

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

  1. Забезпечення достовірності. У кожен елемент даних інформація заноситься точно відповідно до опису цього елемента .Должни бути передбачені механізми забезпечення стійкості елементів даних і їх логічних взаємозв'язків до помилок або не мають відповідної кваліфікації дій користувачів.
  2. Управління параллелізмом.Нарушеніе цілісності БД може виникнути при одночасному виконанні операцій над даними, кожна з яких окремо не порушує цілісності БД. Тому повинні бути передбачені механізми управління даними, що забезпечують підтримку цілісності БД при одночасному виконанні декількох операцій.

  3. Відновлення. Збережені в БД дані повинні бути стійкі по відношенню до несприятливих фізичних впливів (апаратні помилки, збої харчування і т. П.) і помилок в програмному забезпеченні. Тому повинні бути передбачені механізми відновлення за гранично короткий час того стану БД, яке було перед появою несправності.

В опитування управління доступом і підтримки цілісності БД тісно пов'язані між собою, і в багатьох випадках для їх вирішення використовуються одні й ті ж механізми. Різниця між цими аспектами забезпечення безпеки даних в БД полягає в тому, що управління доступом пов'язано із запобіганням навмисного руйнування БД, а управління цілісністю - із запобіганням ненавмисного внесення помилки.

Управління доступом в базах даних

Б ольшинство систем БД є засіб єдиного централізованого зберігання даних. Це значно скорочує надмірність даних, спрощує доступ до даних і дозволяє більш ефективно захищати дані. Однак, в технології БД виникає ряд проблем, пов'язаних, наприклад, з тим, що різні користувачі повинні мати доступ до одними даними і не мати доступу до інших. Тому, не використовуючи спеціальні засоби і методи, забезпечити надійне поділ доступу в БД практично неможливо.

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

Управління цілісністю даних

Н арушеніе цілісності даних може бути викликано рядом причин:

  • збої обладнання, фізичні дії або стихійні лиха;

  • помилки санкціонованих користувачів або навмисні дії несанкціонованих користувачів;

  • програмні помилки СУБД або ОС;

  • помилки в прикладних програмах;

  • спільне виконання конфліктних запитів користувачів і ін.

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

управління паралелізмом

П оддержаніе цілісності на основі наведених вище обмежень цілісності являє собою досить складну проблему в системі БД навіть з одним користувачем. У системах, орієнтованих на багато користувачів режим роботи, виникає цілий ряд нових проблем, пов'язаних з паралельним виконанням конфліктуючих запитів користувачів. Перш, ніж розглянути механізми захисту БД від помилок, що виникають у разі конфлікту призначених для користувача запитів, розкриємо ряд понять, пов'язаних з управлінням паралелізмом.

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

З точки зору безпеки даних такий механізм відображення змін в БД дуже істотний. Якщо транзакція була перервана, то спеціальні вбудовані засоби СУБД здійснюють так званий відкат - повернення БД в стан, що передує початку виконання транзакції (насправді відкат зазвичай полягає просто в невиконанні змін, обумовлених ходом транзакції, у фізичній БД). Якщо виконання однієї транзакції не порушує цілісності БД, то в результаті одночасного виконання декількох транзакцій цілісність БД може бути порушена. Щоб уникнути подібного роду помилок, СУБД повинна підтримувати механізми, що забезпечують захоплення транзакціями модифікуються елементів даних до моменту завершення модифікації так звані блокування. При цьому гарантується, що ніхто не отримає доступу до модифікуються елементу даних, поки транзакція не звільнить його. Застосування механізму блокувань призводить до нових проблем управління паралелізмом, зокрема, до виникнення ситуацій клінчу двох транзакцій. Причому, якщо деяка транзакція намагається блокувати об'єкт, який вже блокований інший транзакцією, то їй доведеться чекати, поки не буде знято блокування об'єкта транзакцією, що встановила цю блокування. Іншими словами, блокування об'єкта може виконувати тільки одна транзакція.

Відновлення даних

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

М ожно виділити три основні рівні відновлення:

  1. Оперативне відновлення, яке характеризується можливістю відновлення на рівні окремих транзакцій при ненормальному закінчення ситуації маніпулювання даними (наприклад, при помилці в програмі).

  2. Проміжне відновлення .Якщо виникають аномалії в роботі системи (системно-програмні помилки, збої програмного забезпечення, не пов'язані з руйнуванням БД), то потрібно відновити стан всіх виконуваних на момент виникнення збою транзакцій.

  3. Тривале відновлення. При руйнуванні БД в результаті дефекту на диску відновлення здійснюється за допомогою копії БД. Потім відтворюють результати виконаних з моменту зняття копії транзакцій і повертають систему в стан на момент руйнування.

Транзакція і відновлення

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

  1. необхідно, щоб транзакція або виконувалася повністю, або не виконувалася зовсім;
  2. необхідно, щоб транзакція допускала можливість повернення до попереднього стану, причому, для забезпечення незалежного повернення транзакції в початковий стан монопольну блокування необхідно здійснювати до моменту завершення зміни всіх об'єктів;

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

У процесі виконання будь-якої транзакції настає момент її завершення. При цьому всі обчислення, зроблені транзакцією в її робочої області, повинні бути закінчені, копія результатів її виконання повинна бути записана в системний журнал. Подібні дії називають операцією фіксації. При появі збою доцільніше здійснювати повернення не в початок транзакції, а в деяке проміжне положення. Точку, куди відбувається таке повернення, називають точкою фіксації (контрольною точкою). Користувач може встановити в процесі виконання транзакції довільну кількість таких точок. Якщо в ході виконання транзакції досягається точка фіксації, то СУБД автоматично здійснює зазначену вище операцію.

Відкат і розкрутка транзакції

Про сновним засобом, використовуваним при відновленні, є системний журнал, в якому реєструються всі зміни, що вносяться до БД кожної транзакцією. Повернення транзакції в початковий стан складається в анулювання всіх змін, які здійснені в процесі виконання транзакції. Таку операцію називають відкатом. Для відтворення результатів виконання транзакції можна, використовуючи системний журнал, відновити значення проведених змін в порядку їх виникнення, або виконати транзакцію повторно. Відтворення результатів виконання транзакції з використанням системного журналу називається розкручуванням. Розкрутка є досить складною, але необхідною операцією механізмів відновлення сучасних БД.

Сайт управляється системою uCoz