SQLBase SafeGarde – СУБД з повним захистом даних

Забезпечення захисту даних виконується в SQLBase SafeGarde на адміністративному рівні і не вимагає перепрограмування бізнес-додатків.

Введення


Потреба в захисті електронної інформації ставати все більш актуальною. Цьому питанню присвячено багато розробок і досліджень. Але мета нашої статті інша, підкреслю найголовніше, що, на наш погляд, не є поки достатньо відомим у світі інформаційних технологій. Необхідність захисту інформації в інформаційних системах жорстко регламентується законодавством Російської Федерації. Існують десятки законів РФ і галузевих стандартів, які визначають необхідність захисту інформації та вимоги до її організації. Нещодавно (24 січня 2001 року) на цю тему в Interface Ltd був проведений семінар, результати обговорень по цій темі Ви можете знайти на сайті.

У зв'язку цим актуальним стає переорієнтація на програмні продукти і, зокрема, СУБД, які забезпечують повну або часткову захист. Так вийшло, що більшість SQL серверів є відкритими і прозорими не тільки для користувачів, але і для спроб несанкціонованого доступу: практично будь-який запит дозволяє отримати доступ до інформації, що зберігається в БД. Отримання або підбір системного пароля при нинішніх рівнях продуктивності комп'ютерів не є для зломщиків непереборною перешкодою. Одним з перших у світі, і першим у своєму класі СУБД, надає повний захист SQL СУБД фірми Centura – Centura SQLBase SafeGarde.

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

Спочатку кілька слів про сам програмному продукті для тих, хто недостатньо знайомий з продуктами Centura. Решта читачі можуть опустити наступні два підрозділи.

Версії SQLBase і нові версії, плановані в 2001 році

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

Сімейство версій СУБД SQLBase:


Рівні захисту інформації в SQLBase:


Перспективи виходу нових версій SQLBase з захистом даних:


СУБД SQLBase виходить в наступних комплектах:


Особливості СУБД, його відмінні властивості і функції


Особливості СУБД SQLBase виділені нижче:


СУБД SQLBase забезпечує виконання всіх функцій і операцій, характерних для професійного SQL сервера БД, зокрема виділимо основні:


Перейдемо далі до розгляду питань захисту інформації в SQLBase. Для цього попередньо потрібно відповісти на такі питання: що являє собою захист даних, і в яких випадках вона повинна застосовуватися?


Що таке захист інформації?

Рівень захищеності даних в інформаційних системах самого різного рівня визначається відповідями на сукупність питань представлених нижче. На малюнку, розташованому нижче (Мал. 1), схематично показані вузькі місця, в яких можливе розкрадання, навмисна зміна і несанкціонований доступ до інформації (на малюнку вони виділені піктограмою зі знаком питання). Якщо заходи, які застосовуються для захисту інформації, забезпечують позитивні відповіді на поставлені нижче питання, то можна вважати, що рівень захисту інформації у вашій системі досить високий. Основні питання наступні:


Ми постараємося відповісти на ці питання, розглядаючи можливості захисту інформації в SQLBase SafeGarde і методи їх практичної налаштування. Оскільки забезпечення захисту інформації в системах – захід дороге: за деякими оцінками витрати на захист наближаються до витрат на проектування і створення складних інформаційних систем (тобто витрати на проектування та експлуатацію можуть зрости майже вдвічі), то необхідно відповісти на питання про необхідність її введення. Постараємося відповісти на нього.



Коли потрібний захист інформації?

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

Рис. 1 Вузькі місця в системі з точки зору захисту інформації

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


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

Різновиди захисту в SQLBase Safegarde

Для реалізації захисту інформації в SQLBase Safegarde запропоновані механізми:

  • Використання привілеїв користувачів для доступу до таблиць і view БД, і обмеження можливості делегування привілеїв. Всі входить в стандартний набір SQL мови і розвинених SQL серверів є в SQLBase.
  • Регламентація підключення до консолі сервера і контроль за діями користувачів. Для цього вводяться спеціальні паролі доступу до сервера.
  • Парольний захист адміністративних дій з сервером. Для цього вводиться спеціальний пароль доступу до консолі сервера.
  • Кодування даних в БД (64 і 128 бітне DES) при мінімальних втратах продуктивності. Задається спеціальними командами.
  • Контроль несанкціонованого доступу до файлів за допомогою захисту сторінок БД спеціальними кодами. Задається спеціальними командами.
  • Привілеї доступу до серверних процедур (Stored procedure) і функцій.
  • Затриманий контроль пароля для протидії злому і підбору пароля.

    Реалізація захисту в СУБД по окремих позиціях

    Дані механізми реалізовані в SQLBase SafeGarde наступним чином:

    Авторизація прав доступу і привілеї доступу до об'єктів БД і процедур:

    Введено чотири категорії користувачів, права яких різні:


  • SYSADM – дозволяється все
  • DBA – все, але без паролів, користувачів та рівнів
  • RESOURCE – управління об'єктами БД і права користувачів для об'єктів
  • CONNECT – робота з об'єктами із заданим доступом

    Використовуються спеціальні SQL і SQLTalk команди для призначення привілеїв та режимів захисту:


  • GRANT – команда SQL для призначення привілеїв
  • REVOKE CONNECT FROM <auth-id> – управління доступом

    Паролі для сервера та захисту:

    Введені спеціальні команди для встановлення режимів захисту даних і сервера:


  • ALTER DBSECURITY – для управління захистом і шифруванням
  • ALTER PASSWORD <old password> TO <new password>-завдання системного пароля
  • ALTER EXPORTKEY TO <new password> – для завдання пароля копіювання

    Передбачено два роздільних, але взаємозалежних пароля для захисту:


  • Server connection passwords – пароль підключення до сервера.
  • Server security passwords – пароль для управління захистом.

    Server connection passwords:

    Server connection passwords – встановлюється в SQL.INI (секція сервера) і служить для виконання адміністративних операцій та отримання інформації про сервер БД. Його можна використовувати навіть для БД, які не шифруються. Його можна опускати ("*") і бажано не використовувати в зашифрованих БД. Роль Server connection passwords в цьому випадку буде грати Server security passwords.

    Server connection passwords дозволяє:


  • Відновлювати, зберігати БД і їх журнали
  • Створювати та видаляти БД
  • Інсталювати і деінсталювати БД
  • Контролювати виконання операцій з SQL / API

    Підключення до сервера для виконання адміністративних функцій і з паролем для доступу (приклад): SET SERVER SERVER1/SECRET;

    Server security passwords

    Server security passwords – на додаток до функцій Server connection passwords цей пароль дозволяє вам шифрувати БД і контролювати несанкціоновані зміни сторінок БД. Поки не заданий Server security passwords, неможлива шифровка БД і не можна отримати доступ до зашифрованих БД. Для доступу до зашифрованої БД або установки режиму захисту потрібно вказати ключ шифрування (database encryption key).

    ALTER DBSECURITY – команда установки ключа (команда SQLTalk). Встановлення – при роботі в WINDOWS виберете <Security-Set Security Password в SQLBase консолі сервера>. При роботі в NetWare натисніть F4. Тільки після установки Server security passwords (16 символів максимально) ви отримуєте можливість використання і введення коду для шифрування БД (ключ шифрування – 18 символів максимально).

    У команді в SQLTalk ALTER DBSECURITY задаються: ключ, режими шифрування даних, а також режими захисту сторінок. Це робиться наступними параметрами:


  • SET KEY TO "newkey" – для установки ключа для шифрування (макс. 18 символів)
  • SET SECURITY TO NONE / LOW / MEDIUM / HIGH – для встановлення рівня шифрування даних
  • SET CHECK TO NONE / CRC / SHA – для установки режиму контроль несанкціонованого доступу до сторінок БД

    Код шифрування буде сформований на основі двох параметрів: ключа шифрування (database encryption key) і пароля шифрування сервера (Server security passwords).

    Режими шифрування БД і Рівні захисту даних

    За допомогою параметра SET SECURITY TO можуть бути встановлені чотири режими шифрування даних в БД, які визначають ступінь захисту інформації. Це наступні режими:

    ь NONE – немає шифрування в БД, режим шифрування відключений.


  • LOW – низький рівень захисту (кожен символ по складному алгоритму замінюється іншим). У цьому режимі забезпечується найвища продуктивність, але рівень захисту даних найнижчий.
  • MEDIUM – забезпечується більш високий захист (64 бітний ключ) і спостерігається незначний вплив на продуктивність СУБД.
  • HIGH – найвищий рівень захисту і забезпечується не дуже сильний вплив на продуктивність СУБД (128 бітний ключ).

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

    Призначення режимів захисту сторінок від доступу

    БД розділена на сторінки розміром 1кб. На кожну станицю створюється ключ / код, що дозволяє контролювати доступ: неможливо прочитати і при зміні вручну не записується в БД. СУБД контролює несанкціоноване зміна сторінок БД. У разі порушення доступу сервер автоматично закривається. Передбачені наступні режими, що задаються параметром SET CHECK TO команди ALTER DBSECURITY:

    ь NONE – немає захисту, але при захисті в БД сторінку все одно не можна змінити!


  • CRC – 16-bit CRC (Cyclic Redundancy Check) – виконується захист циклічної контрольною сумою. Сервер знімає БД і закривається при порушенні доступу.
  • SHA SHA (Secure Hash Algorithm) виконується захист спеціальної сигнатурою, що задається нетривіальною функцією і формованої для кожної сторінки. Сервер знімає БД і закривається при порушенні доступу. Більше високий захист від зміни сторінок, ніж CRC.

    Захист при передачі даних

    Для захисту з передачі даних у SQL.INI в клієнтській і серверній частині встановлюються параметр secureapi = {0/1/2} (Визначає режими: None, Medium, High). При цьому спеціально не потрібно програмувати захисні функції. Для роботи з захистом передачі даних потрібно всього підключити три DLL: SQLWNTM, SQLNGCI і будь-яка comdll (наприклад, для TCP / IP – sqlws32).

    Затримка при перевірці пароля

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

    Захист від виконання функцій SQL / API для захисту файлів від доступу

    За допомогою спеціальної директиви (fileaccess = 0) можна виключити виконання функцій доступу до файлів БД на рівні "З" API для SQLBase. Цих функцій нижнього рівня декілька: sqlfgt, sqlfpt, sqlmop і sqlmdl. Весь інший контроль і захист даних виконає сервер SQLBase Safegarde при доступі за допомогою SQL команд.

    Оцінка зниження продуктивності при захисті даних

    СУБД SQLBase 7.5 в порівнянні з попередньою версією (7.0) є більш продуктивним приблизно в три рази, це досягається за рахунок оптимізують алгоритмів доступу до даних. При введенні рівнів захисту для ОС Windows NT продуктивність знижується до 99% (MEDIUM і LOW) і до 94% (HIGH) відповідно. При використанні NetWare зниження більш помітно: 93% (MEDIUM і LOW) і до 91% (HIGH) відповідно. Дані вимірювання проводилися третій фірмою. Таким чином, максимальне зниження продуктивності знаходиться в межах 10%, що є дуже гарним показником для СУБД із захистом інформації, зазвичай ця величина становить кілька десятків відсотків.

    Висновок

    На закінчення відзначимо, що потужний і сучасний SQL сервер із захистом інформації в БД – Centura SQLBase Safecarde безсумнівно приверне велику кількість користувачів та розробників, як це було зроблено в Німеччині при автоматизації Berliner Deutsche Bank.


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


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

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

    Ваш отзыв

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

    *

    *