ЗМІСТ
ВСТУП
1. ЗАХИСТ ІНФОРМАЦІЇ
1.1 Поняття захисту інформації
1.2 Захист інформації в базах даних
2. РЕАЛІЗАЦІЯ ЗАХИСТУ В ДЕЯКИХ СУБД
3. MS SQL SERVER
3.1 Організація захисту
3.2 Користувачі бази даних
4. БЕЗПЕКА ДАНИХ У ORACLE 7
4.1 Обмеження доступу
4.2 Юридичний захист авторських прав на базах даних
ВИСНОВОК
СПИСОК ЛІТЕРАТУРИ
ВСТУП
Сучасні СУБД в основному є додатками Windows, так як дана середовище дозволяє більш повно використовувати можливості персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК зумовив не тільки широкий перехід до середовища Windows, де розробник програмного забезпечення може меншою мірою піклуватися про розподіл ресурсів, але також зробив програмне забезпечення ПК в цілому і СУБД зокрема менш критичними до апаратних ресурсів ЕОМ. Серед найбільш яскравих представників систем управління базами даних можна відзначити: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а також баз даних Microsoft SQL Server і Oracle, що використовуються в додатках, побудованих за технологією "клієнт -сервер ".
Проблема забезпечення захисту інформації є однією з найважливіших при побудові надійної інформаційної структури установи на базі ЕОМ. Ця проблема охоплює як фізичний захист даних і системних програм, так і захист від несанкціонованого доступу до даних, що передаються по лініях зв'язку і перебувають на накопичувачах, що є результатом діяльності як сторонніх осіб, так і спеціальних програм-вірусів. Таким чином, у поняття захисту даних включаються питання збереження цілісності даних і управління доступу до даних (санкціонування). Технологічний аспект даного питання пов'язаний з різними видами обмежень, які підтримуються структурою СУБД і повинні бути доступні користувачеві.
Зазвичай в СУБД в мову маніпулювання даними вже закладаються необхідні компоненти реалізації зазначених обмежень. Проблема забезпечення санкционированности використання даних є неоднозначною, але в основному охоплює питання захисту даних від небажаної модифікації або знищення, а також від несанкціонованого їх читання. У даній роботі я зачіпаю основні аспекти захисту баз даних, їх реалізацію на прикладах конкретних СУБД, а так само юридичну сторону даного питання.
1. ЗАХИСТ ІНФОРМАЦІЇ
1.1 Поняття захисту інформації
Захист інформації - комплекс заходів, спрямованих на забезпечення найважливіших аспектів інформаційної безпеки (цілісності, доступності та, якщо потрібно, конфіденційності інформації та ресурсів, що використовуються для введення, зберігання, обробки і передачі даних) [1]. Система називається безпечною, якщо вона, використовуючи відповідні апаратні і програмні засоби, управляє доступом до інформації так, що тільки належним чином авторизовані особи або ж діють від їхнього імені процеси отримують право читати, писати, створювати і видаляти інформацію.
Очевидно, що абсолютно безпечних систем немає, і тут мова йде про надійну систему у сенсі "система, якій можна довіряти" (як можна довіряти людині). Система вважається надійною, якщо вона з використанням достатніх апаратних і програмних засобів забезпечує одночасну обробку інформації різного ступеня секретності групою користувачів без порушення прав доступу. Основними критеріями оцінки надійності є: політика безпеки та гарантованість. Політика безпеки, будучи активним компонентом захисту (включає в себе аналіз можливих загроз і вибір відповідних заходів протидії), відображає той набір законів, правил і норм поведінки, яким користується конкретна організація при обробці, захисту та поширення інформації. Вибір конкретних механізмів забезпечення безпеки системи здійснюється відповідно до сформульованої політикою безпеки.
Гарантованість, будучи пасивним елементом захисту, відображає міру довіри, яке може бути надано архітектурі та реалізації системи (іншими словами, показує, наскільки коректно обрані механізми, що забезпечують безпеку системи).
У надійній системі повинні реєструватися всі події, що відбуваються, стосуються безпеки (повинен використовуватися механізм підзвітності протоколювання, що доповнює аналізом запомненной інформації, тобто аудитом). При оцінці ступеня гарантоване, з якою систему можна вважати надійною, центральне місце займає достовірна (надійна) обчислювальна база. Достовірна обчислювальна база (ДВІ) являє собою повну сукупність захисних механізмів комп'ютерної системи, яка використовується для втілення в життя відповідної політики безпеки. Надійність ДВБ залежить виключно від її реалізації та коректності введених даних (наприклад, даних про благонадійність користувачів, які визначаються адміністрацією). Кордон ДВБ утворює периметр безпеки. Компоненти ДВБ, що знаходяться всередині цього кордону, повинні бути надійними (отже, для оцінки надійності комп'ютерної системи досить розглянути тільки її ДВБ). Від компонентів, що знаходяться поза периметром безпеки, взагалі кажучи, не потрібно надійності. Однак це не повинно впливати на безпеку системи.
Так як зараз широко застосовуються розподілені системи обробки даних, то під "периметром безпеки" розуміється межа володінь певної організації, у підпорядкуванні якої знаходиться ця система. Тоді за аналогією те, що знаходиться всередині цього кордону, вважається надійним. За допомогою шлюзової системи, яка здатна протистояти потенційно ненадійного, а може бути навіть і ворожого оточення, здійснюється зв'язок через цей кордон. Контроль допустимості виконання суб'єктами певних операцій над об'єктами, тобто функції моніторингу, виконується достовірної обчислювальної базою. При кожному зверненні користувача до програм або даними монітор перевіряє допустимість даного звернення (узгодженість дії конкретного користувача зі списком дозволених для нього дій). Реалізація монітора звернень називається ядром безпеки, на базі якої будуються всі захисні механізми системи. Ядро безпеки має гарантувати власну незмінність.
1.2 Захист інформації в базах даних
У сучасних СУБД підтримується один з двох найбільш загальних підходів до питання забезпечення безпеки даних: виборчий підхід і обов'язковий підхід. В обох підходах одиницею даних або "об'єктом даних", для яких повинна бути створена система безпеки, може бути як вся база даних цілком, так і будь-який об'єкт всередині бази даних. Ці два підходи відрізняються наступними властивостями: У разі виборчого управління деякий користувач володіє різними правами (привілеями чи повноваженнями) при роботі з цими об'єктами. Різні користувачі можуть мати різні правами доступу до одного і того ж об'єкту.
Виборчі права характеризуються значною гнучкістю. У разі виборчого управління, навпаки, кожному об'єкту даних присвоюється певний класифікаційний рівень, а кожен користувач має деяким рівнем допуску. При такому підході доступом до певного об'єкту даних мають тільки користувачі з відповідним рівнем допуску. Для реалізації виборчого принципу передбачені такі методи. У базу даних вводиться новий тип об'єктів БД - це користувачі. Кожному користувачеві в БД присвоюється унікальний ідентифікатор. Для додаткового захисту кожен користувач крім унікального ідентифікатора постачається унікальним паролем, причому якщо ідентифікатори користувачів у системі доступні системного адміністратора, то паролі користувачів зберігаються частіше за все в спеціальному кодованому вигляді і відомі тільки самим користувачам. Користувачі можуть бути об'єднані в спеціальні групи користувачів. Один користувач може входити в кілька груп.
У стандарті вводиться поняття групи PUBLIC, для якої повинен бути визначений мінімальний стандартний набір прав. За умовчанням передбачається, що кожен новостворюваний користувач, якщо спеціально не вказано інше, належить до групи PUBLIC. Привілеї або повноваження користувачів або груп - це набір дій (операцій), які вони можуть виконувати над об'єктами БД. В останніх версіях ряду комерційних СУБД з'явилося поняття "ролі". Роль - це пойменований набір повноважень. Існує ряд стандартних ролей, які визначені в момент встановлення сервера баз даних. І є можливість створювати нові ролі, групуючи в них довільні повноваження. Введення ролей дозволяє спростити управління привілеями користувачів, структурувати цей процес. Крім того, введення ролей не пов'язане з конкретними користувачами, тому ролі можуть бути визначені і сконфігуровані до того, як визначені користувачі системи. Користувачеві може бути призначена одна або декілька ролей.
Об'єктами БД, які підлягають захисту, є всі об'єкти, що зберігаються в БД: таблиці, подання, збережені процедури і тригери. Для кожного типу об'єктів є свої дії, тому для кожного типу об'єктів можуть бути визначені різні права доступу. На самому елементарному рівні концепції забезпечення безпеки баз даних виключно прості. Необхідно підтримувати два фундаментальних принципи: перевірку повноважень і перевірку автентичності (аутентифікацію). Перевірка повноважень заснована на тому, що кожному користувачеві або процесу інформаційної системи відповідає набір дій, які він може виконувати по відношенню до певних об'єктів. Перевірка автентичності означає достовірне підтвердження того, що користувач або процес, який намагається виконати санкціонована дія, дійсно той, за кого він себе видає.
Система призначення повноважень має в деякому роді ієрархічний характер. Найвищими правами і повноваженнями має системний адміністратор або адміністратор сервера БД. Традиційно тільки цей тип користувачів може створювати інших користувачів і наділяти їх певними повноваженнями. СУБД в своїх системних каталогах зберігає як опис самих користувачів, так і опис їх привілеїв по відношенню до всіх об'єктів.
Далі схема надання повноважень будується за наступним принципом. Кожен об'єкт в БД має власника - користувача, який створив цей об'єкт. Власник об'єкта має всі права-повноваженнями на даний об'єкт, у тому числі він має право надавати іншим користувачам повноваження по роботі з даним об'єктом або забирати у користувачів раніше надані повноваження.
У ряді СУБД вводиться наступний рівень ієрархії користувачів - це адміністратор БД. У цих СУБД один сервер може управляти безліччю СУБД (наприклад, MS SQL Server, Sybase). У СУБД Oracle застосовується однобазовая архітектура, тому там вводиться поняття подсхеми - частини загальної схеми БД і вводиться користувач, який має доступ до подсхеме. У стандарті SQL не визначена команда створення користувача, але практично у всіх комерційних СУБД створити користувача можна не тільки в інтерактивному режимі, але і програмно з використанням спеціальних процедур, що зберігаються. Проте для виконання цієї операції користувач повинен мати право на запуск відповідної системної процедури.
У стандарті SQL визначені два оператори: GRANT і REVOKE відповідно надання та скасування привілеїв.
Оператор надання привілеїв має наступний формат:
GRANT {<список дій | ALL PRIVILEGES}
ON <імя_об'екта> ТО (<ім'я користувача>] PUBLIC} [WITH GRANT OPTION]
Тут список дій визначає набір дій з общедопустімого переліку дій над об'єктом даного типу.
Параметр ALL PRIVILEGES вказує, що дозволені всі дії з допустимих для об'єктів даного типу.
<Імя_обьекта> - задає ім'я конкретного об'єкта: таблиці, подання, збереженої процедури, тригера.
<Ім'я користувача> або PUBLIC визначає, кому надаються дані привілеї.
Параметр WITH GRANT OPTION є необов'язковим і визначає режим, при якому передаються не тільки права на зазначені дії, а й право передавати ці права іншим користувачам. Передавати права в цьому випадку користувач може тільки в рамках дозволених йому дій.
Розглянемо приклад, нехай у нас існують три користувачі з абсолютно унікальними іменами userl, user2 і user3. Всі вони є користувачами однієї БД.
User1 створив об'єкт Таb1, він є власником цього об'єкта і може передати права на роботу з цим об'єктом іншим користувачам. Припустимо, що користувач user2 є оператором, який повинен вводити дані в Таb1 (наприклад, таблицю нових замовлень), а користувач user 3 є великим начальником (наприклад, менеджером відділу), який повинен регулярно переглядати введені дані.
Для об'єкта типу таблиця повним допустимим переліком дій є набір з чотирьох операцій: SELECT, INSERT, DELETE, UPDATE. При цьому операція оновлення може бути обмежена декількома стовпцями.
Загальний формат оператора призначення привілеїв для об'єкта типу таблиця буде мати наступний синтаксис:
GRANT {[SELECT] [. INSERT] [, DELETED [. UPDATE (<список стовпців>)]} ON <ім'я таблиці>
ТО {<ім'я користувача> PUBLIC}
[WITH GRANT OPTION]
Тоді резонно буде виконати наступні призначення:
GRANT INSERT
ON Tab1
ТО user2 GRANT SELECT
ON Tab1
TO user3
Ці призначення означають, що користувач user2 має право тільки вводити нові рядки в ставлення Таb1> а користувач user3 має право переглядати всі рядки в таблиці Таb1.Прі призначення прав доступу на операцію модифікації можна уточнити, значення яких стовпців може змінювати користувач. Припустимо, що менеджер відділу має право змінювати ціну на послуги, що надаються. Припустимо, що ціна задається в стовпці COST таблиці Таb1. Тоді операція призначення привілеїв користувачеві user3 може змінитися і виглядати наступним чином:
GRANT SELECT. UPDATE (COST) ON Tab1 TO user3
Якщо наш користувач user1 припускає, що користувач user4 може його заміщати в разі його відсутності, то він може надати цьому користувачеві всі права по роботі зі створеною таблицею Таb1.
GRANT ALL PRIVILEGES
ON Tab1
TO user4 WITH GRANT OPTION
У цьому випадку користувач user4 може сам призначати привілеї по роботі з таблицею Таb1 за відсутності власника об'єкта користувача user1. Тому в разі появи нового оператора користувача user5 він може призначити йому права на введення нових рядків у таблицю командою
GRANT INSERT
ON Tab1 TO user5
Якщо при передачі повноважень набір операцій над об'єктом обмежений, то користувач, якому передано ці повноваження, може передати іншому користувачеві тільки ті повноваження, які є у нього, або частину цих повноважень. Тому якщо користувачеві user4 були делеговані такі повноваження:
GRANT SELECT. UPDATE. DELETE
ON Tab1
TO user4 WITH GRANT OPTION,
то користувач user4 не зможе передати повноваження на введення даних користувачеві user5, тому що ця операція не входить до списку дозволених для нього самого.
Крім безпосереднього призначення прав по роботі з таблицями ефективним методом захисту даних може бути створення уявлень, які будуть містити лише необхідні стовпці для роботи конкретного користувача і надання прав на роботу з даним поданням користувачеві. Так як уявлення можуть відповідати підсумковим запитам, то для цих уявлень неприпустимі операції зміни, і, отже, для таких уявлень набір допустимих дій обмежується операцією SELECT. Якщо ж подання відповідають вибірці з базової таблиці, то для такого подання допустимими будуть всі 4 операції: SELECT, INSERT, UPDATE і DELETE.
Для скасування раніше призначених привілеїв в стандарті SQL визначений оператор REVOKE. Оператор скасування привілеїв має наступний синтаксис:
REVOKE {<список операцій | ALL PRIVILEGES} ON <імя_об'екта>
FROM {<список користувачів | PUBLIC} {CASCADE | RESTRICT}
Параметри CASCADE або RESTRICT визначають, яким чином повинна здійснюватися скасування привілеїв. Параметр CASCADE скасовує привілеї не тільки користувача, який безпосередньо згадувався в операторі GRANT при наданні йому привілеїв, але і всім користувачам, яким цей користувач присвоїв привілеї, скориставшись параметром WITH GRANT OPTION.
ВСТУП
1. ЗАХИСТ ІНФОРМАЦІЇ
1.1 Поняття захисту інформації
1.2 Захист інформації в базах даних
2. РЕАЛІЗАЦІЯ ЗАХИСТУ В ДЕЯКИХ СУБД
3. MS SQL SERVER
3.1 Організація захисту
3.2 Користувачі бази даних
4. БЕЗПЕКА ДАНИХ У ORACLE 7
4.1 Обмеження доступу
4.2 Юридичний захист авторських прав на базах даних
ВИСНОВОК
СПИСОК ЛІТЕРАТУРИ
ВСТУП
Сучасні СУБД в основному є додатками Windows, так як дана середовище дозволяє більш повно використовувати можливості персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК зумовив не тільки широкий перехід до середовища Windows, де розробник програмного забезпечення може меншою мірою піклуватися про розподіл ресурсів, але також зробив програмне забезпечення ПК в цілому і СУБД зокрема менш критичними до апаратних ресурсів ЕОМ. Серед найбільш яскравих представників систем управління базами даних можна відзначити: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а також баз даних Microsoft SQL Server і Oracle, що використовуються в додатках, побудованих за технологією "клієнт -сервер ".
Проблема забезпечення захисту інформації є однією з найважливіших при побудові надійної інформаційної структури установи на базі ЕОМ. Ця проблема охоплює як фізичний захист даних і системних програм, так і захист від несанкціонованого доступу до даних, що передаються по лініях зв'язку і перебувають на накопичувачах, що є результатом діяльності як сторонніх осіб, так і спеціальних програм-вірусів. Таким чином, у поняття захисту даних включаються питання збереження цілісності даних і управління доступу до даних (санкціонування). Технологічний аспект даного питання пов'язаний з різними видами обмежень, які підтримуються структурою СУБД і повинні бути доступні користувачеві.
Зазвичай в СУБД в мову маніпулювання даними вже закладаються необхідні компоненти реалізації зазначених обмежень. Проблема забезпечення санкционированности використання даних є неоднозначною, але в основному охоплює питання захисту даних від небажаної модифікації або знищення, а також від несанкціонованого їх читання. У даній роботі я зачіпаю основні аспекти захисту баз даних, їх реалізацію на прикладах конкретних СУБД, а так само юридичну сторону даного питання.
1. ЗАХИСТ ІНФОРМАЦІЇ
1.1 Поняття захисту інформації
Захист інформації - комплекс заходів, спрямованих на забезпечення найважливіших аспектів інформаційної безпеки (цілісності, доступності та, якщо потрібно, конфіденційності інформації та ресурсів, що використовуються для введення, зберігання, обробки і передачі даних) [1]. Система називається безпечною, якщо вона, використовуючи відповідні апаратні і програмні засоби, управляє доступом до інформації так, що тільки належним чином авторизовані особи або ж діють від їхнього імені процеси отримують право читати, писати, створювати і видаляти інформацію.
Очевидно, що абсолютно безпечних систем немає, і тут мова йде про надійну систему у сенсі "система, якій можна довіряти" (як можна довіряти людині). Система вважається надійною, якщо вона з використанням достатніх апаратних і програмних засобів забезпечує одночасну обробку інформації різного ступеня секретності групою користувачів без порушення прав доступу. Основними критеріями оцінки надійності є: політика безпеки та гарантованість. Політика безпеки, будучи активним компонентом захисту (включає в себе аналіз можливих загроз і вибір відповідних заходів протидії), відображає той набір законів, правил і норм поведінки, яким користується конкретна організація при обробці, захисту та поширення інформації. Вибір конкретних механізмів забезпечення безпеки системи здійснюється відповідно до сформульованої політикою безпеки.
Гарантованість, будучи пасивним елементом захисту, відображає міру довіри, яке може бути надано архітектурі та реалізації системи (іншими словами, показує, наскільки коректно обрані механізми, що забезпечують безпеку системи).
У надійній системі повинні реєструватися всі події, що відбуваються, стосуються безпеки (повинен використовуватися механізм підзвітності протоколювання, що доповнює аналізом запомненной інформації, тобто аудитом). При оцінці ступеня гарантоване, з якою систему можна вважати надійною, центральне місце займає достовірна (надійна) обчислювальна база. Достовірна обчислювальна база (ДВІ) являє собою повну сукупність захисних механізмів комп'ютерної системи, яка використовується для втілення в життя відповідної політики безпеки. Надійність ДВБ залежить виключно від її реалізації та коректності введених даних (наприклад, даних про благонадійність користувачів, які визначаються адміністрацією). Кордон ДВБ утворює периметр безпеки. Компоненти ДВБ, що знаходяться всередині цього кордону, повинні бути надійними (отже, для оцінки надійності комп'ютерної системи досить розглянути тільки її ДВБ). Від компонентів, що знаходяться поза периметром безпеки, взагалі кажучи, не потрібно надійності. Однак це не повинно впливати на безпеку системи.
Так як зараз широко застосовуються розподілені системи обробки даних, то під "периметром безпеки" розуміється межа володінь певної організації, у підпорядкуванні якої знаходиться ця система. Тоді за аналогією те, що знаходиться всередині цього кордону, вважається надійним. За допомогою шлюзової системи, яка здатна протистояти потенційно ненадійного, а може бути навіть і ворожого оточення, здійснюється зв'язок через цей кордон. Контроль допустимості виконання суб'єктами певних операцій над об'єктами, тобто функції моніторингу, виконується достовірної обчислювальної базою. При кожному зверненні користувача до програм або даними монітор перевіряє допустимість даного звернення (узгодженість дії конкретного користувача зі списком дозволених для нього дій). Реалізація монітора звернень називається ядром безпеки, на базі якої будуються всі захисні механізми системи. Ядро безпеки має гарантувати власну незмінність.
1.2 Захист інформації в базах даних
У сучасних СУБД підтримується один з двох найбільш загальних підходів до питання забезпечення безпеки даних: виборчий підхід і обов'язковий підхід. В обох підходах одиницею даних або "об'єктом даних", для яких повинна бути створена система безпеки, може бути як вся база даних цілком, так і будь-який об'єкт всередині бази даних. Ці два підходи відрізняються наступними властивостями: У разі виборчого управління деякий користувач володіє різними правами (привілеями чи повноваженнями) при роботі з цими об'єктами. Різні користувачі можуть мати різні правами доступу до одного і того ж об'єкту.
Виборчі права характеризуються значною гнучкістю. У разі виборчого управління, навпаки, кожному об'єкту даних присвоюється певний класифікаційний рівень, а кожен користувач має деяким рівнем допуску. При такому підході доступом до певного об'єкту даних мають тільки користувачі з відповідним рівнем допуску. Для реалізації виборчого принципу передбачені такі методи. У базу даних вводиться новий тип об'єктів БД - це користувачі. Кожному користувачеві в БД присвоюється унікальний ідентифікатор. Для додаткового захисту кожен користувач крім унікального ідентифікатора постачається унікальним паролем, причому якщо ідентифікатори користувачів у системі доступні системного адміністратора, то паролі користувачів зберігаються частіше за все в спеціальному кодованому вигляді і відомі тільки самим користувачам. Користувачі можуть бути об'єднані в спеціальні групи користувачів. Один користувач може входити в кілька груп.
У стандарті вводиться поняття групи PUBLIC, для якої повинен бути визначений мінімальний стандартний набір прав. За умовчанням передбачається, що кожен новостворюваний користувач, якщо спеціально не вказано інше, належить до групи PUBLIC. Привілеї або повноваження користувачів або груп - це набір дій (операцій), які вони можуть виконувати над об'єктами БД. В останніх версіях ряду комерційних СУБД з'явилося поняття "ролі". Роль - це пойменований набір повноважень. Існує ряд стандартних ролей, які визначені в момент встановлення сервера баз даних. І є можливість створювати нові ролі, групуючи в них довільні повноваження. Введення ролей дозволяє спростити управління привілеями користувачів, структурувати цей процес. Крім того, введення ролей не пов'язане з конкретними користувачами, тому ролі можуть бути визначені і сконфігуровані до того, як визначені користувачі системи. Користувачеві може бути призначена одна або декілька ролей.
Об'єктами БД, які підлягають захисту, є всі об'єкти, що зберігаються в БД: таблиці, подання, збережені процедури і тригери. Для кожного типу об'єктів є свої дії, тому для кожного типу об'єктів можуть бути визначені різні права доступу. На самому елементарному рівні концепції забезпечення безпеки баз даних виключно прості. Необхідно підтримувати два фундаментальних принципи: перевірку повноважень і перевірку автентичності (аутентифікацію). Перевірка повноважень заснована на тому, що кожному користувачеві або процесу інформаційної системи відповідає набір дій, які він може виконувати по відношенню до певних об'єктів. Перевірка автентичності означає достовірне підтвердження того, що користувач або процес, який намагається виконати санкціонована дія, дійсно той, за кого він себе видає.
Система призначення повноважень має в деякому роді ієрархічний характер. Найвищими правами і повноваженнями має системний адміністратор або адміністратор сервера БД. Традиційно тільки цей тип користувачів може створювати інших користувачів і наділяти їх певними повноваженнями. СУБД в своїх системних каталогах зберігає як опис самих користувачів, так і опис їх привілеїв по відношенню до всіх об'єктів.
Далі схема надання повноважень будується за наступним принципом. Кожен об'єкт в БД має власника - користувача, який створив цей об'єкт. Власник об'єкта має всі права-повноваженнями на даний об'єкт, у тому числі він має право надавати іншим користувачам повноваження по роботі з даним об'єктом або забирати у користувачів раніше надані повноваження.
У ряді СУБД вводиться наступний рівень ієрархії користувачів - це адміністратор БД. У цих СУБД один сервер може управляти безліччю СУБД (наприклад, MS SQL Server, Sybase). У СУБД Oracle застосовується однобазовая архітектура, тому там вводиться поняття подсхеми - частини загальної схеми БД і вводиться користувач, який має доступ до подсхеме. У стандарті SQL не визначена команда створення користувача, але практично у всіх комерційних СУБД створити користувача можна не тільки в інтерактивному режимі, але і програмно з використанням спеціальних процедур, що зберігаються. Проте для виконання цієї операції користувач повинен мати право на запуск відповідної системної процедури.
У стандарті SQL визначені два оператори: GRANT і REVOKE відповідно надання та скасування привілеїв.
Оператор надання привілеїв має наступний формат:
GRANT {<список дій | ALL PRIVILEGES}
ON <імя_об'екта> ТО (<ім'я користувача>] PUBLIC} [WITH GRANT OPTION]
Тут список дій визначає набір дій з общедопустімого переліку дій над об'єктом даного типу.
Параметр ALL PRIVILEGES вказує, що дозволені всі дії з допустимих для об'єктів даного типу.
<Імя_обьекта> - задає ім'я конкретного об'єкта: таблиці, подання, збереженої процедури, тригера.
<Ім'я користувача> або PUBLIC визначає, кому надаються дані привілеї.
Параметр WITH GRANT OPTION є необов'язковим і визначає режим, при якому передаються не тільки права на зазначені дії, а й право передавати ці права іншим користувачам. Передавати права в цьому випадку користувач може тільки в рамках дозволених йому дій.
Розглянемо приклад, нехай у нас існують три користувачі з абсолютно унікальними іменами userl, user2 і user3. Всі вони є користувачами однієї БД.
User1 створив об'єкт Таb1, він є власником цього об'єкта і може передати права на роботу з цим об'єктом іншим користувачам. Припустимо, що користувач user2 є оператором, який повинен вводити дані в Таb1 (наприклад, таблицю нових замовлень), а користувач user 3 є великим начальником (наприклад, менеджером відділу), який повинен регулярно переглядати введені дані.
Для об'єкта типу таблиця повним допустимим переліком дій є набір з чотирьох операцій: SELECT, INSERT, DELETE, UPDATE. При цьому операція оновлення може бути обмежена декількома стовпцями.
Загальний формат оператора призначення привілеїв для об'єкта типу таблиця буде мати наступний синтаксис:
GRANT {[SELECT] [. INSERT] [, DELETED [. UPDATE (<список стовпців>)]} ON <ім'я таблиці>
ТО {<ім'я користувача> PUBLIC}
[WITH GRANT OPTION]
Тоді резонно буде виконати наступні призначення:
GRANT INSERT
ON Tab1
ТО user2 GRANT SELECT
ON Tab1
TO user3
Ці призначення означають, що користувач user2 має право тільки вводити нові рядки в ставлення Таb1> а користувач user3 має право переглядати всі рядки в таблиці Таb1.Прі призначення прав доступу на операцію модифікації можна уточнити, значення яких стовпців може змінювати користувач. Припустимо, що менеджер відділу має право змінювати ціну на послуги, що надаються. Припустимо, що ціна задається в стовпці COST таблиці Таb1. Тоді операція призначення привілеїв користувачеві user3 може змінитися і виглядати наступним чином:
GRANT SELECT. UPDATE (COST) ON Tab1 TO user3
Якщо наш користувач user1 припускає, що користувач user4 може його заміщати в разі його відсутності, то він може надати цьому користувачеві всі права по роботі зі створеною таблицею Таb1.
GRANT ALL PRIVILEGES
ON Tab1
TO user4 WITH GRANT OPTION
У цьому випадку користувач user4 може сам призначати привілеї по роботі з таблицею Таb1 за відсутності власника об'єкта користувача user1. Тому в разі появи нового оператора користувача user5 він може призначити йому права на введення нових рядків у таблицю командою
GRANT INSERT
ON Tab1 TO user5
Якщо при передачі повноважень набір операцій над об'єктом обмежений, то користувач, якому передано ці повноваження, може передати іншому користувачеві тільки ті повноваження, які є у нього, або частину цих повноважень. Тому якщо користувачеві user4 були делеговані такі повноваження:
GRANT SELECT. UPDATE. DELETE
ON Tab1
TO user4 WITH GRANT OPTION,
то користувач user4 не зможе передати повноваження на введення даних користувачеві user5, тому що ця операція не входить до списку дозволених для нього самого.
Крім безпосереднього призначення прав по роботі з таблицями ефективним методом захисту даних може бути створення уявлень, які будуть містити лише необхідні стовпці для роботи конкретного користувача і надання прав на роботу з даним поданням користувачеві. Так як уявлення можуть відповідати підсумковим запитам, то для цих уявлень неприпустимі операції зміни, і, отже, для таких уявлень набір допустимих дій обмежується операцією SELECT. Якщо ж подання відповідають вибірці з базової таблиці, то для такого подання допустимими будуть всі 4 операції: SELECT, INSERT, UPDATE і DELETE.
Для скасування раніше призначених привілеїв в стандарті SQL визначений оператор REVOKE. Оператор скасування привілеїв має наступний синтаксис:
REVOKE {<список операцій | ALL PRIVILEGES} ON <імя_об'екта>
FROM {<список користувачів | PUBLIC} {CASCADE | RESTRICT}
Параметри CASCADE або RESTRICT визначають, яким чином повинна здійснюватися скасування привілеїв. Параметр CASCADE скасовує привілеї не тільки користувача, який безпосередньо згадувався в операторі GRANT при наданні йому привілеїв, але і всім користувачам, яким цей користувач присвоїв привілеї, скориставшись параметром WITH GRANT OPTION.
Наприклад, при використанні операції:
REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE
будуть скасовані привілеї і користувача user5, якому користувач user4 встиг привласнити привілеї. Параметр RESTRICKT обмежує скасування привілеїв тільки користувачеві, безпосередньо згаданому в операторі REVOKE. Але при наявності делегованих привілеїв цей оператор не буде виконаний.
Так, наприклад, операція:
REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT
не буде виконана, тому що користувач user4 передав частину своїх повноважень користувачу user5.
За допомогою оператора REVOKE можна відібрати всі або тільки деякі з раніше присвоєних привілеїв по роботі з конкретним об'єктом. При цьому з опису синтаксису оператора скасування привілеїв видно, що можна відібрати привілеї одним оператором відразу у декількох користувачів або у цілої групи PUBLIC.
Тому коректним буде таке використання оператора REVOKE: REVOKE INSERT ON Tab! TO user2.user4 CASCADEПрі роботі з іншими об'єктами змінюється список операцій, які використовуються в операторахGRANT і REVOKE.По замовчуванням дію, відповідне запуску (виконання) збереженої процедури, призначається усім членам групи PUBLIC.Еслі ви хочете змінити цю умову, то після створення збереженої процедури необхідно записати оператор REVOKE.REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE І тепер ми можемо призначити нові права користувачеві user4.GRANT EXECUTE ON COUNT_EX TO user4
Системний адміністратор може дозволити деякого користувачеві створювати і змінювати таблиці в деякій БД. Тоді він може записати оператор надання прав наступним чином:
У цьому випадку користувач user1 може створювати, змінювати або видаляти таблиці в БД DB_LIB, проте він не може дозволити створювати або змінювати таблиці в цій БД іншим користувачам, тому що йому дано дозвіл без права делегування своїх можливостей.
У деяких СУБД користувач може отримати права створювати БД. Наприклад, в MS SQL Server системний адміністратор може надати користувачеві main_user право на створення своєї БД на цьому сервері. Це може бути зроблено наступною командою:
GRANT CREATE DATABASE
ON SERVERJ) TO main user
За принципом ієрархії користувач main_user, створивши свою БД, тепер може надати права на створення або зміна будь-яких об'єктів у цій БД іншим користувачам. У СУБД, які підтримують однобазовую архітектуру, такі дозволи неприпустимі. Наприклад, у СУБД Oracle на сервері створюється тільки одна БД, але користувачі можуть працювати на рівні подсхеми (частини таблиць БД і пов'язаних з ними об'єктів). Тому там вводиться поняття системних привілеїв. Їх дуже багато, 80 різних привілеїв. Вони видаються тільки на дії і конкретний тип об'єкта. Тому - якщо ви, як системний адміністратор, надали користувачеві право створення таблиць (CREATE TABLE), то для того щоб він міг створити тригер для таблиці, йому необхідно надати ще одну системну привілей CREATE TRIGGER. Система захисту в Oracle вважається однією з найбільш потужних, але це має і зворотний бік - вона досить складна. Тому завдання адміністрування в Oracle вимагає гарного знання як семантики принципів підтримки прав доступу, так і фізичної реалізації цих можливостей.
2. РЕАЛІЗАЦІЯ ЗАХИСТУ В ДЕЯКИХ СУБД
Якщо у вас є досвід роботи з захистом, використовуваним на сервері або великий ЕОМ, структура захисту в Access здасться вам знайомою. Ви можете вказати користувачів, яким надається або, навпаки, не дозволяється доступ до об'єктів бази даних. Крім того, ви можете визначити групи користувачів і встановити дозволи на рівні групи, щоб полегшити побудову захисту для великого числа користувачів. Користувачеві досить бути членом групи, щоб отримати права доступу, установлені для неї.
Access зберігає інформацію про захист у двох місцях. Під час встановлення програма Setup створить в папці Program Files Microsoft Oficeffice стандартний файл робочої групи (System.mdw), який у подальшому використовується за умовчанням при запуску Access. Цей файл містить інформацію про всіх користувачів і групах. При створенні бази даних Access зберігає відомості про права, що надаються конкретним користувачам і групам, у файлі бази данних.Общая структура захисту Access відображена на малюнку 1. Облікові записи користувачів і груп зберігаються у файлі робочої групи. Дозвіл на доступ до конкретних об'єктів зберігаються у файлі бази даних.
Рис.1
Розташування поточного файлу робочої групи зберігається в реєстрі Windows. Можна використовувати службову програму Wrkadm.exe (адміністратор робочих груп) для зміни поточного або визначення нового файлу робочої групи. Крім того, можна вибирати потрібний файл робочої групи під час виконання програми, задавши відповідний параметр командного рядка в ярлику запуску. Якщо вам доводиться часто запускати в мережі спільно використовуване захищене додаток, потрібно подбати про те, щоб системний адміністратор задав вашу робочу групу, яка використовується за умовчанням, як загальний файл в мережевій папці.
Кожна робоча група має унікальний внутрішній ідентифікатор, генерований Access при визначенні файлу робочих груп. Будь-яка база даних, створена користувачем робочої групи, "належить" як цьому користувачеві, так і робочій групі. Кожен користувач і група також має унікальний внутрішній ідентифікатор, але можна дублювати один і той самий код користувача і групи в декількох робочих групах. Коли ви призначаєте право доступу до об'єкта своєї бази даних, Access зберігає у ній внутрішній ідентифікатор користувача або групи разом з інформацією про доступ. Таким чином, надані вами права переміщуються разом з файлом бази даних при копіюванні його в іншу папку або на інший комп'ютер.
3. MS SQL SERVER
3.1 Організація захисту
У критичних для бізнесу додатках, коли сервер СУБД повинен бути постійно доступний для клієнтів, більшість профілактичних робіт з підтримки бази даних доводиться виконувати фактично в режимі on - line. MS SQL Server володіє можливостями динамічного резервного копіювання даних, тобто навіть коли ці дані використовуються і змінюються клієнтами. У випадку збою обладнання, відключення живлення і т. д. механізм автоматичного відновлення MS SQL Server відновлює всі бази даних до їхнього останнього цілісного стану без втручання адміністратора. Всі завершені, але не відображені в базі транзакції з журналу транзакцій застосовуються до бази даних (це фактично те, що відбувається при події chekpoint), а незавершені транзакції, тобто ті, які були активними на момент збою, вичищаються з журналу.
Говорячи про симетричної архітектурі, операції резервного копіювання і відновлення можуть розпаралелюється на кілька потоків і виконуватися одночасно, використовуючи переваги асинхронного введення / виводу. На кожне резервне пристрій відводиться свій потік. Паралельне резервне копіювання підтримує до 32 одночасних резервних пристроїв (backup devices), що дозволяє швидко створювати страхувальні копії баз даних навіть дуже великої місткості. Можливість резервного копіювання і відновлення окремих таблиць, про що ми згадували, розглядаючи Transact-SQL, дозволяє економити місце і час, не виконуючи копіювання всієї бази заради тільки деяких її об'єктів.
Однак резервне копіювання окремої таблиці вимагає накладення на неї блокування exclusive на відміну від резервного копіювання всієї бази або журналу транзакцій, які можуть виконуватися незалежно від ступеня активності користувачів. Резервних копій може бути призначений граничний строк зберігання або дата втрати актуальності, до настання якої місце, зайняте на пристрої цими копіями, не може використовуватися для розміщення інших резервних копій при ініціалізації пристрою.
Для невеликої бази даних і журнал транзакцій зазвичай зберігається на тому ж пристрої, що і сама база, і архівується разом з нею. Журналювання транзакцій ведеться за принципом write-ahead, що означає, що будь-яка зміна спочатку відображається в журналі транзакцій і лише потім потрапляє власне в базу. У разі знаходження журналу транзакцій на окремому пристрої існує можливість окремого резервного копіювання журналу транзакцій. Як правило, резервне копіювання бази даних організується з меншою частотою, ніж журналу транзакцій. Наприклад, збереження журналу транзакцій виконується щодня, а страхова копія всієї бази може робитися раз на тиждень, так як архівування журналу транзакцій відбувається значно швидше за часом і займає менше місця, ніж дамп цілої бази.
На відміну від резервування бази даних дамп журналу транзакцій очищає його неактивну частину, тобто всі завершилися (зафіксовані або абортовані) з моменту останнього дампа транзакції, якщо тільки не використана опція NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, що очищає журнал транзакцій, корисна в разі його переповнення, яке можна контролювати, наприклад, оператором DBCC SQLPERF (LOGSPACE). Якщо ступінь переповнення журналу дуже висока, можна при його очищенні відмовитися від журналірованія факту самого цієї події: DUMP TRANSACTION NO_LOG. Якщо копіювання транзакцій не представляє інтересу, можна включити опцію очищення останніх завершених транзакцій в базі по настанню події checkpoint. Cмисл механізму checkpoint складається в періодичній запису даних з кеша на диск, щоб не допускати брудних даних.
Такого роду події постійно генеруються MS SQL Server або виникають з ініціативи користувача. Включена опція truncate log on checkpoint гарантує виконання з певною частотою обробником події дій, приблизно еквівалентних команді DUMP TRANSACTION TRUNCATE_ONLY.Прі відновлення журналу транзакцій відповідні транзакції застосовуються до бази даних. Це означає, що якщо на початку тижня була зроблена резервна копія всієї бази, а потім щоденно архівувалися транзакції за кожен день, то при необхідності відновлення піднімається стан бази на початок тижня і на нього послідовно накочуються дампи журналу транзакцій за всі дні, що передують моменту відновлення. MS SQL Server 6.5 має можливість відновлення даних з журналу транзакцій на довільний момент часу (зрозуміло, що відображений у журналі) за допомогою команди LOAD TRANSACTION STOPAT або у вікні database backup and restore вибором опції until time. Всі містяться в цьому дампі транзакції, відмічені завершилися після цього моменту, будуть відкинуті. Можливість планування завдань резервного копіювання у часі та надіслання повідомлення по e-mail у разі успішного / неуспішного завершення розглядалася нами при обговоренні SQL Executive.
MS SQL Server 6.5 передбачає можливість дзеркалювання пристроїв, перемикання на дзеркальні пристрої в якості основних, вимикання дзеркалювання та знищення дзеркального пристрої також "на льоту", тобто без зупинки штатної роботи сервера з обслуговування користувача запитів. Віддзеркалення і дуплексірованіе пристроїв для роботи з MS SQL Server може бути також виконано засобами Windows NT, а також на апаратному рівні (підтримка різних RAID-систем і т. д.). Мабуть, слід припускати, що реалізація першого етапу кластерної технології WolfPack буде підтримувати MS SQL Server 6.5 в відмовостійких кластерах з двох вузлів. Поява наступної версії MS SQL Server має забезпечити роботу серверів в кластері як єдиного віртуального сервера.Transfer Manager використовується для експорту / імпорту об'єктів і даних БД на MS SQL Server між різними апаратними платформами, наприклад між процесорами Intel і Alpha, а також між різними версіями MS SQL Server, зокрема з більш ранніх в більш пізні або між рівноцінними.
Дуже часто проектування об'єктів бази ведеться за допомогою різних графічних засобів, але проектна документація може вимагати структуру об'єктів з точністю до операторів DDL. Для отримання скриптів, що описують створення окремого об'єкта бази даних, можна використовувати команду transfer з контекстного меню об'єкта або вибрати відповідний клас та ім'я об'єкта в Transfer Manager. Крім цього, вміст даних може бути вивантажено / додано за допомогою утиліти bcp.
Говорячи про переваги інтеграції з операційною системою, MS SQL Server використовує у своїй роботі сервіси безпеки Windows NT. Нагадаємо, що Windows NT на сьогодні сертифікована за класами безпеки С2/Е3. MS SQL Server може бути налаштований на роботу в одному з трьох режимах безпеки. Інтегрований режим передбачає використання механізмів аутентифікації Windows NT для забезпечення безпеки всіх користувальницьких сполук. У цьому випадку до сервера дозволяються тільки трастові, або аутентифицирующей, з'єднання (named pipes і multiprotocol). Адміністратор має можливість відобразити групи користувачів Windows NT на відповідні значення login id MS SQL Server за допомогою утиліти SQL Security Manager. У цьому випадку при вході на MS SQL Server login name та пароль, передані через DB-Library або ODBC, ігноруються. Стандартний режим безпеки припускає, що на MS SQL Server будуть заводитися самостійні login id і відповідні їм паролі. Змішаний режим використовує інтегровану модель при встановленні з'єднань за пойменованим каналах або мультіпротоколу і стандартну модель у всіх інших випадках.
MS SQL Server забезпечує багаторівневу перевірку привілеїв при завантаженні на сервер. Спочатку ідентифікуються права користувача на встановлення з'єднання з вибраним сервером (login name і пароль) і виконання адміністративних функцій: створення пристроїв і баз даних, призначення прав іншим користувачам, зміна параметрів налаштування сервера і т.д. Максимальними правами володіє системний адміністратор. На рівні бази даних кожен користувач, що завантажив на сервер, може мати ім'я користувача (username) бази та права на доступ до об'єктів всередині неї. Є можливість відобразити декількох login id на одного користувача бази даних, а також об'єднувати користувачів у групи для зручності адміністрування та призначення подібних привілеїв. По відношенню до об'єктів бази даних користувачеві можуть бути призначені права на виконання різних операцій над ними: читання, додавання, видалення, зміна, декларативна посилальна цілісність (DRI), виконання процедур, що зберігаються, а також права на доступ до окремих полів. Якщо цього недостатньо, можна вдатися до представлень (views), для яких сказане залишається справедливим. Нарешті, можна взагалі заборонити користувачеві безпосередній доступ до даних, залишивши за ним лише права на виконання збережених процедур, в яких буде прописаний весь сценарій його доступу до бази. Збережені процедури можуть створюватися з опцією WITH ENCRYPTION, яка шифрує безпосередній текст процедури, що зберігається зазвичай у syscomments. Права на виконання деяких команд (створення баз, таблиць, замовчувань, правил, уявлень, процедур, резервне копіювання баз і журналів транзакцій) не є об'єктно-специфічними, тому вони призначаються системним адміністратором сервера чи власником (засновником) бази даних при редагуванні бази даних.
Адміністрування користувальницьких привілеїв зазвичай ведеться в SQL Enterprise Manager, тим не менш в Transact-SQL є процедури, що зберігаються (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) і оператори (GRANT, REVOKE), які дозволяють здійснювати дії щодо створення користувачів, призначенням та скасування прав при виконанні скриптів. Додаткову можливість адміністрування привілеїв надають розглянуті нами вище SQL-DMO.
3.2 Користувачі бази даних
Поняття користувач бази даних відноситься до бази (або баз) даних, до яких може отримати доступ окремий користувач. Після успішного підключення сервер визначає, чи має цей користувач дозвіл на роботу з базою даних, до якої звертається.
Об'єктні права доступу дозволяють контролювати доступ до об'єктів у SQL Server, надаючи і анулюючи права доступу для таблиць, стовпців, уявлень і збережених процедур. Щоб виконати по відношенню до деякого об'єкта деяку дію, користувач повинен мати відповідне право доступу. Наприклад, якщо користувач хоче виконати оператор SELECT * FROM table, то він повинен і міть права виконання оператора SELECT для таблиці table. Командні права доступу визначає тих користувачів, які можуть виконувати адміністративні дії, наприклад, створювати або копіювати базу даних.
Нижче наведені командні права доступу:
CREATE DATABASE - право створення бази даних;
CREATE DEFAULT - право створення стандартного значення для стовпця таблиці;
CREATE PROCEDURE - право створення збереженої процедури.
CREATE TABLE - право створення таблиці;
CREATE VIEW - право створення подання;
BACKUP DATABASE - право створення резервної копії;
BACKUP TRANSACTION - право створення резервної копії журналу транзакцій.
4. Безпека даних у Oracle 7
4.1 Обмеження доступу
Якщо ми впевнені, що підключатися до нашої бази даних можуть лише уповноважені користувачі і що вони можуть запускати тільки ті модулі, на виконання яких їм явно надано право, то потрібно подумати про наступному рівні безпеки - обмеження доступу цих користувачів до даних. Величезним кроком уперед у забезпеченні безпеки даних стало введення ролей у Oracle7. До Oracle7 кожному користувачеві доводилося явно надавати права доступу до кожного об'єкта бази даних, який йому дозволено було використовувати. Цей процес спрощується за рахунок того, що доступ до сукупності об'єктів надається ролі, а потім право на використання цієї ролі надається відповідним особам. За допомогою команди GRANT ми можемо надати користувачам право виконувати над об'єктами БД (наприклад, над таблицями) операції SELECT, INSERT, UPDATE і DELETE. Однак саме по собі це не забезпечує значною гнучкості. Ми можемо обмежити доступ користувачів частинами таблиці, розділивши її по горизонталі (обмеживши користувача певними рядками), по вертикалі (обмеживши його певними стовпцями) чи й по горизонталі, і по вертикалі.
4.2 Юридичний захист авторських прав на бази даних
Питання правового захисту програм для ЕОМ і бази даних від незаконного використання є дуже актуальними в даний момент. Для ілюстрації цього наведемо декілька фактів.
За даними Асоціації виробників комп'ютерного забезпечення, рівень комп'ютерного піратства в Росії складає 94%. Рівень піратства в країнах Заходу істотно нижчим: у Німеччині - 50%, у США - 35%. За даними МВС РФ, втрати російського бюджету від несплати податків продавцями комп'ютерних програм становлять 85 млн. дол Гроші, отримані від продажу, часто йдуть у розпорядження кримінальних структур.
Крім того, 105 млн. дол втрачають російські підприємства. В області розробки комп'ютерних програм і баз даних в країні працює близько шести тисяч фірм, які забезпечують зайнятість понад 200 тис. чоловік. Даній сфері виробництва загрожує стагнація - програмісти просто втрачають стимули до створення нових передових програмних продуктів. Визнання права - перший з перерахованих у п. 1 ст. 18 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" способів захисту авторських прав. Цей спосіб захисту грає в основному превентивну роль і служить встановленню визначеності у взаємовідносинах суб'єктів цивільного права.
Визнання права як спосіб захисту застосовується, коли оспорюється або заперечується належність певній особі виняткових авторських прав на програму для ЕОМ чи базу даних. Визнання права як засіб його захисту може бути реалізовано лише у судовому порядку шляхом підтвердження наявності або відсутності в особи окремих авторських правомочностей або їх сукупності.
П. 1 ст. 17 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" визначає порушника авторського права як фізична або юридична особа, яка не виконує вимог цього закону до виключних прав правовласників, в тому числі ввозить до Російської Федерації екземпляри програми для ЕОМ чи бази даних , виготовлені без дозволу правовласника. Це може виражатися у привласненні авторства, здійсненні перерахованих у ст. 10 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" дій без дозволу правовласника і т. д.
Окрему виділення імпорту примірників програми для ЕОМ чи бази даних, виготовлених без дозволу їх правовласників пояснюється тим, що в державі, де дані екземпляри були виготовлені, ця дія може вважатися законним і не тягне відповідальності.
ВИСНОВОК
Інформаційна безпека відноситься до числа дисциплін, що розвиваються надзвичайно швидкими темпами. Цьому сприяють як загальний прогрес інформаційних технологій, так і постійне протиборство нападників і захищаються.
На жаль, подібна динамічність об'єктивно ускладнює забезпечення надійного захисту. Причин цього кілька:
• підвищення швидкодії мікросхем, розвиток архітектур з високим ступенем паралелізму дозволяє методом грубої сили (перебором варіантів) долати бар'єри (насамперед криптографічні), які раніше здавалися неприступними;
• розвиток мереж, збільшення числа зв'язків між інформаційними системами, зростання пропускної здатності каналів розширюють число потенційних зловмисників, які мають технічну можливість здійснити напад;
• поява нових інформаційних сервісів веде і до появи нових загроз як "усередині" сервісів, так і на їх стиках;
• конкуренція серед виробників програмного забезпечення змушує скорочувати терміни розробки системи, що веде до зниження якості тестування та випуску продуктів з дефектами захисту;
• нав'язувана споживачам парадигма постійного нарощування апаратного та програмного забезпечення вступає в конфлікт з бюджетними обмеженнями, через що знижується частка асигнувань на безпеку.
Забезпечення інформаційної безпеки сучасних інформаційних систем потребує комплексного підходу. Вона неможлива без застосування широкого спектру захисних засобів, об'єднаних в продуману архітектуру. Далеко не всі ці кошти отримали поширення в Росії, деякі з них навіть у світовому масштабі перебувають у стадії становлення. У цих умовах позиція по відношенню до інформаційної безпеки повинна бути особливо динамічною. Теоретичні погляди, стандарти, сформовані порядки необхідно постійно звіряти з вимогами практики. Від атак не захиститися книгою (навіть помаранчевої) або сертифікатом. Реальна безпека потребує щоденній роботі всіх зацікавлених сторін.
СПИСОК ЛІТЕРАТУРИ
Голіцина О.Л., Максимов Н.В. та ін, "Бази даних" (навчальний посібник)
Могилів А.В., Пак Н.І. та ін, "Інформатика"
Родзинок В.П. "Піратство у сфері програмного забезпечення" / / Фінансові новини від 23 травня 2003
Стаття Юрія Шермана / / www.tour-soft.com
Стаття Сергія Гаврилова / / www.sergevg @ usa.net
Партика Т.Л., Попов І.І. "Інформаційна безпека" 2004 р.
Герасименко В.А., Малюк О.О., "Основи захисту інформації" М.: МІФІ, 2001 р.
REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE
будуть скасовані привілеї і користувача user5, якому користувач user4 встиг привласнити привілеї. Параметр RESTRICKT обмежує скасування привілеїв тільки користувачеві, безпосередньо згаданому в операторі REVOKE. Але при наявності делегованих привілеїв цей оператор не буде виконаний.
Так, наприклад, операція:
REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT
не буде виконана, тому що користувач user4 передав частину своїх повноважень користувачу user5.
За допомогою оператора REVOKE можна відібрати всі або тільки деякі з раніше присвоєних привілеїв по роботі з конкретним об'єктом. При цьому з опису синтаксису оператора скасування привілеїв видно, що можна відібрати привілеї одним оператором відразу у декількох користувачів або у цілої групи PUBLIC.
Тому коректним буде таке використання оператора REVOKE: REVOKE INSERT ON Tab! TO user2.user4 CASCADEПрі роботі з іншими об'єктами змінюється список операцій, які використовуються в операторахGRANT і REVOKE.По замовчуванням дію, відповідне запуску (виконання) збереженої процедури, призначається усім членам групи PUBLIC.Еслі ви хочете змінити цю умову, то після створення збереженої процедури необхідно записати оператор REVOKE.REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE І тепер ми можемо призначити нові права користувачеві user4.GRANT EXECUTE ON COUNT_EX TO user4
Системний адміністратор може дозволити деякого користувачеві створювати і змінювати таблиці в деякій БД. Тоді він може записати оператор надання прав наступним чином:
У цьому випадку користувач user1 може створювати, змінювати або видаляти таблиці в БД DB_LIB, проте він не може дозволити створювати або змінювати таблиці в цій БД іншим користувачам, тому що йому дано дозвіл без права делегування своїх можливостей.
У деяких СУБД користувач може отримати права створювати БД. Наприклад, в MS SQL Server системний адміністратор може надати користувачеві main_user право на створення своєї БД на цьому сервері. Це може бути зроблено наступною командою:
GRANT CREATE DATABASE
ON SERVERJ) TO main user
За принципом ієрархії користувач main_user, створивши свою БД, тепер може надати права на створення або зміна будь-яких об'єктів у цій БД іншим користувачам. У СУБД, які підтримують однобазовую архітектуру, такі дозволи неприпустимі. Наприклад, у СУБД Oracle на сервері створюється тільки одна БД, але користувачі можуть працювати на рівні подсхеми (частини таблиць БД і пов'язаних з ними об'єктів). Тому там вводиться поняття системних привілеїв. Їх дуже багато, 80 різних привілеїв. Вони видаються тільки на дії і конкретний тип об'єкта. Тому - якщо ви, як системний адміністратор, надали користувачеві право створення таблиць (CREATE TABLE), то для того щоб він міг створити тригер для таблиці, йому необхідно надати ще одну системну привілей CREATE TRIGGER. Система захисту в Oracle вважається однією з найбільш потужних, але це має і зворотний бік - вона досить складна. Тому завдання адміністрування в Oracle вимагає гарного знання як семантики принципів підтримки прав доступу, так і фізичної реалізації цих можливостей.
2. РЕАЛІЗАЦІЯ ЗАХИСТУ В ДЕЯКИХ СУБД
Якщо у вас є досвід роботи з захистом, використовуваним на сервері або великий ЕОМ, структура захисту в Access здасться вам знайомою. Ви можете вказати користувачів, яким надається або, навпаки, не дозволяється доступ до об'єктів бази даних. Крім того, ви можете визначити групи користувачів і встановити дозволи на рівні групи, щоб полегшити побудову захисту для великого числа користувачів. Користувачеві досить бути членом групи, щоб отримати права доступу, установлені для неї.
Access зберігає інформацію про захист у двох місцях. Під час встановлення програма Setup створить в папці Program Files Microsoft Oficeffice стандартний файл робочої групи (System.mdw), який у подальшому використовується за умовчанням при запуску Access. Цей файл містить інформацію про всіх користувачів і групах. При створенні бази даних Access зберігає відомості про права, що надаються конкретним користувачам і групам, у файлі бази данних.Общая структура захисту Access відображена на малюнку 1. Облікові записи користувачів і груп зберігаються у файлі робочої групи. Дозвіл на доступ до конкретних об'єктів зберігаються у файлі бази даних.
Рис.1
Розташування поточного файлу робочої групи зберігається в реєстрі Windows. Можна використовувати службову програму Wrkadm.exe (адміністратор робочих груп) для зміни поточного або визначення нового файлу робочої групи. Крім того, можна вибирати потрібний файл робочої групи під час виконання програми, задавши відповідний параметр командного рядка в ярлику запуску. Якщо вам доводиться часто запускати в мережі спільно використовуване захищене додаток, потрібно подбати про те, щоб системний адміністратор задав вашу робочу групу, яка використовується за умовчанням, як загальний файл в мережевій папці.
Кожна робоча група має унікальний внутрішній ідентифікатор, генерований Access при визначенні файлу робочих груп. Будь-яка база даних, створена користувачем робочої групи, "належить" як цьому користувачеві, так і робочій групі. Кожен користувач і група також має унікальний внутрішній ідентифікатор, але можна дублювати один і той самий код користувача і групи в декількох робочих групах. Коли ви призначаєте право доступу до об'єкта своєї бази даних, Access зберігає у ній внутрішній ідентифікатор користувача або групи разом з інформацією про доступ. Таким чином, надані вами права переміщуються разом з файлом бази даних при копіюванні його в іншу папку або на інший комп'ютер.
3. MS SQL SERVER
3.1 Організація захисту
У критичних для бізнесу додатках, коли сервер СУБД повинен бути постійно доступний для клієнтів, більшість профілактичних робіт з підтримки бази даних доводиться виконувати фактично в режимі on - line. MS SQL Server володіє можливостями динамічного резервного копіювання даних, тобто навіть коли ці дані використовуються і змінюються клієнтами. У випадку збою обладнання, відключення живлення і т. д. механізм автоматичного відновлення MS SQL Server відновлює всі бази даних до їхнього останнього цілісного стану без втручання адміністратора. Всі завершені, але не відображені в базі транзакції з журналу транзакцій застосовуються до бази даних (це фактично те, що відбувається при події chekpoint), а незавершені транзакції, тобто ті, які були активними на момент збою, вичищаються з журналу.
Говорячи про симетричної архітектурі, операції резервного копіювання і відновлення можуть розпаралелюється на кілька потоків і виконуватися одночасно, використовуючи переваги асинхронного введення / виводу. На кожне резервне пристрій відводиться свій потік. Паралельне резервне копіювання підтримує до 32 одночасних резервних пристроїв (backup devices), що дозволяє швидко створювати страхувальні копії баз даних навіть дуже великої місткості. Можливість резервного копіювання і відновлення окремих таблиць, про що ми згадували, розглядаючи Transact-SQL, дозволяє економити місце і час, не виконуючи копіювання всієї бази заради тільки деяких її об'єктів.
Однак резервне копіювання окремої таблиці вимагає накладення на неї блокування exclusive на відміну від резервного копіювання всієї бази або журналу транзакцій, які можуть виконуватися незалежно від ступеня активності користувачів. Резервних копій може бути призначений граничний строк зберігання або дата втрати актуальності, до настання якої місце, зайняте на пристрої цими копіями, не може використовуватися для розміщення інших резервних копій при ініціалізації пристрою.
Для невеликої бази даних і журнал транзакцій зазвичай зберігається на тому ж пристрої, що і сама база, і архівується разом з нею. Журналювання транзакцій ведеться за принципом write-ahead, що означає, що будь-яка зміна спочатку відображається в журналі транзакцій і лише потім потрапляє власне в базу. У разі знаходження журналу транзакцій на окремому пристрої існує можливість окремого резервного копіювання журналу транзакцій. Як правило, резервне копіювання бази даних організується з меншою частотою, ніж журналу транзакцій. Наприклад, збереження журналу транзакцій виконується щодня, а страхова копія всієї бази може робитися раз на тиждень, так як архівування журналу транзакцій відбувається значно швидше за часом і займає менше місця, ніж дамп цілої бази.
На відміну від резервування бази даних дамп журналу транзакцій очищає його неактивну частину, тобто всі завершилися (зафіксовані або абортовані) з моменту останнього дампа транзакції, якщо тільки не використана опція NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, що очищає журнал транзакцій, корисна в разі його переповнення, яке можна контролювати, наприклад, оператором DBCC SQLPERF (LOGSPACE). Якщо ступінь переповнення журналу дуже висока, можна при його очищенні відмовитися від журналірованія факту самого цієї події: DUMP TRANSACTION NO_LOG. Якщо копіювання транзакцій не представляє інтересу, можна включити опцію очищення останніх завершених транзакцій в базі по настанню події checkpoint. Cмисл механізму checkpoint складається в періодичній запису даних з кеша на диск, щоб не допускати брудних даних.
Такого роду події постійно генеруються MS SQL Server або виникають з ініціативи користувача. Включена опція truncate log on checkpoint гарантує виконання з певною частотою обробником події дій, приблизно еквівалентних команді DUMP TRANSACTION TRUNCATE_ONLY.Прі відновлення журналу транзакцій відповідні транзакції застосовуються до бази даних. Це означає, що якщо на початку тижня була зроблена резервна копія всієї бази, а потім щоденно архівувалися транзакції за кожен день, то при необхідності відновлення піднімається стан бази на початок тижня і на нього послідовно накочуються дампи журналу транзакцій за всі дні, що передують моменту відновлення. MS SQL Server 6.5 має можливість відновлення даних з журналу транзакцій на довільний момент часу (зрозуміло, що відображений у журналі) за допомогою команди LOAD TRANSACTION STOPAT або у вікні database backup and restore вибором опції until time. Всі містяться в цьому дампі транзакції, відмічені завершилися після цього моменту, будуть відкинуті. Можливість планування завдань резервного копіювання у часі та надіслання повідомлення по e-mail у разі успішного / неуспішного завершення розглядалася нами при обговоренні SQL Executive.
MS SQL Server 6.5 передбачає можливість дзеркалювання пристроїв, перемикання на дзеркальні пристрої в якості основних, вимикання дзеркалювання та знищення дзеркального пристрої також "на льоту", тобто без зупинки штатної роботи сервера з обслуговування користувача запитів. Віддзеркалення і дуплексірованіе пристроїв для роботи з MS SQL Server може бути також виконано засобами Windows NT, а також на апаратному рівні (підтримка різних RAID-систем і т. д.). Мабуть, слід припускати, що реалізація першого етапу кластерної технології WolfPack буде підтримувати MS SQL Server 6.5 в відмовостійких кластерах з двох вузлів. Поява наступної версії MS SQL Server має забезпечити роботу серверів в кластері як єдиного віртуального сервера.Transfer Manager використовується для експорту / імпорту об'єктів і даних БД на MS SQL Server між різними апаратними платформами, наприклад між процесорами Intel і Alpha, а також між різними версіями MS SQL Server, зокрема з більш ранніх в більш пізні або між рівноцінними.
Дуже часто проектування об'єктів бази ведеться за допомогою різних графічних засобів, але проектна документація може вимагати структуру об'єктів з точністю до операторів DDL. Для отримання скриптів, що описують створення окремого об'єкта бази даних, можна використовувати команду transfer з контекстного меню об'єкта або вибрати відповідний клас та ім'я об'єкта в Transfer Manager. Крім цього, вміст даних може бути вивантажено / додано за допомогою утиліти bcp.
Говорячи про переваги інтеграції з операційною системою, MS SQL Server використовує у своїй роботі сервіси безпеки Windows NT. Нагадаємо, що Windows NT на сьогодні сертифікована за класами безпеки С2/Е3. MS SQL Server може бути налаштований на роботу в одному з трьох режимах безпеки. Інтегрований режим передбачає використання механізмів аутентифікації Windows NT для забезпечення безпеки всіх користувальницьких сполук. У цьому випадку до сервера дозволяються тільки трастові, або аутентифицирующей, з'єднання (named pipes і multiprotocol). Адміністратор має можливість відобразити групи користувачів Windows NT на відповідні значення login id MS SQL Server за допомогою утиліти SQL Security Manager. У цьому випадку при вході на MS SQL Server login name та пароль, передані через DB-Library або ODBC, ігноруються. Стандартний режим безпеки припускає, що на MS SQL Server будуть заводитися самостійні login id і відповідні їм паролі. Змішаний режим використовує інтегровану модель при встановленні з'єднань за пойменованим каналах або мультіпротоколу і стандартну модель у всіх інших випадках.
MS SQL Server забезпечує багаторівневу перевірку привілеїв при завантаженні на сервер. Спочатку ідентифікуються права користувача на встановлення з'єднання з вибраним сервером (login name і пароль) і виконання адміністративних функцій: створення пристроїв і баз даних, призначення прав іншим користувачам, зміна параметрів налаштування сервера і т.д. Максимальними правами володіє системний адміністратор. На рівні бази даних кожен користувач, що завантажив на сервер, може мати ім'я користувача (username) бази та права на доступ до об'єктів всередині неї. Є можливість відобразити декількох login id на одного користувача бази даних, а також об'єднувати користувачів у групи для зручності адміністрування та призначення подібних привілеїв. По відношенню до об'єктів бази даних користувачеві можуть бути призначені права на виконання різних операцій над ними: читання, додавання, видалення, зміна, декларативна посилальна цілісність (DRI), виконання процедур, що зберігаються, а також права на доступ до окремих полів. Якщо цього недостатньо, можна вдатися до представлень (views), для яких сказане залишається справедливим. Нарешті, можна взагалі заборонити користувачеві безпосередній доступ до даних, залишивши за ним лише права на виконання збережених процедур, в яких буде прописаний весь сценарій його доступу до бази. Збережені процедури можуть створюватися з опцією WITH ENCRYPTION, яка шифрує безпосередній текст процедури, що зберігається зазвичай у syscomments. Права на виконання деяких команд (створення баз, таблиць, замовчувань, правил, уявлень, процедур, резервне копіювання баз і журналів транзакцій) не є об'єктно-специфічними, тому вони призначаються системним адміністратором сервера чи власником (засновником) бази даних при редагуванні бази даних.
Адміністрування користувальницьких привілеїв зазвичай ведеться в SQL Enterprise Manager, тим не менш в Transact-SQL є процедури, що зберігаються (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) і оператори (GRANT, REVOKE), які дозволяють здійснювати дії щодо створення користувачів, призначенням та скасування прав при виконанні скриптів. Додаткову можливість адміністрування привілеїв надають розглянуті нами вище SQL-DMO.
3.2 Користувачі бази даних
Поняття користувач бази даних відноситься до бази (або баз) даних, до яких може отримати доступ окремий користувач. Після успішного підключення сервер визначає, чи має цей користувач дозвіл на роботу з базою даних, до якої звертається.
Об'єктні права доступу дозволяють контролювати доступ до об'єктів у SQL Server, надаючи і анулюючи права доступу для таблиць, стовпців, уявлень і збережених процедур. Щоб виконати по відношенню до деякого об'єкта деяку дію, користувач повинен мати відповідне право доступу. Наприклад, якщо користувач хоче виконати оператор SELECT * FROM table, то він повинен і міть права виконання оператора SELECT для таблиці table. Командні права доступу визначає тих користувачів, які можуть виконувати адміністративні дії, наприклад, створювати або копіювати базу даних.
Нижче наведені командні права доступу:
CREATE DATABASE - право створення бази даних;
CREATE DEFAULT - право створення стандартного значення для стовпця таблиці;
CREATE PROCEDURE - право створення збереженої процедури.
CREATE TABLE - право створення таблиці;
CREATE VIEW - право створення подання;
BACKUP DATABASE - право створення резервної копії;
BACKUP TRANSACTION - право створення резервної копії журналу транзакцій.
4. Безпека даних у Oracle 7
4.1 Обмеження доступу
Якщо ми впевнені, що підключатися до нашої бази даних можуть лише уповноважені користувачі і що вони можуть запускати тільки ті модулі, на виконання яких їм явно надано право, то потрібно подумати про наступному рівні безпеки - обмеження доступу цих користувачів до даних. Величезним кроком уперед у забезпеченні безпеки даних стало введення ролей у Oracle7. До Oracle7 кожному користувачеві доводилося явно надавати права доступу до кожного об'єкта бази даних, який йому дозволено було використовувати. Цей процес спрощується за рахунок того, що доступ до сукупності об'єктів надається ролі, а потім право на використання цієї ролі надається відповідним особам. За допомогою команди GRANT ми можемо надати користувачам право виконувати над об'єктами БД (наприклад, над таблицями) операції SELECT, INSERT, UPDATE і DELETE. Однак саме по собі це не забезпечує значною гнучкості. Ми можемо обмежити доступ користувачів частинами таблиці, розділивши її по горизонталі (обмеживши користувача певними рядками), по вертикалі (обмеживши його певними стовпцями) чи й по горизонталі, і по вертикалі.
4.2 Юридичний захист авторських прав на бази даних
Питання правового захисту програм для ЕОМ і бази даних від незаконного використання є дуже актуальними в даний момент. Для ілюстрації цього наведемо декілька фактів.
За даними Асоціації виробників комп'ютерного забезпечення, рівень комп'ютерного піратства в Росії складає 94%. Рівень піратства в країнах Заходу істотно нижчим: у Німеччині - 50%, у США - 35%. За даними МВС РФ, втрати російського бюджету від несплати податків продавцями комп'ютерних програм становлять 85 млн. дол Гроші, отримані від продажу, часто йдуть у розпорядження кримінальних структур.
Крім того, 105 млн. дол втрачають російські підприємства. В області розробки комп'ютерних програм і баз даних в країні працює близько шести тисяч фірм, які забезпечують зайнятість понад 200 тис. чоловік. Даній сфері виробництва загрожує стагнація - програмісти просто втрачають стимули до створення нових передових програмних продуктів. Визнання права - перший з перерахованих у п. 1 ст. 18 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" способів захисту авторських прав. Цей спосіб захисту грає в основному превентивну роль і служить встановленню визначеності у взаємовідносинах суб'єктів цивільного права.
Визнання права як спосіб захисту застосовується, коли оспорюється або заперечується належність певній особі виняткових авторських прав на програму для ЕОМ чи базу даних. Визнання права як засіб його захисту може бути реалізовано лише у судовому порядку шляхом підтвердження наявності або відсутності в особи окремих авторських правомочностей або їх сукупності.
П. 1 ст. 17 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" визначає порушника авторського права як фізична або юридична особа, яка не виконує вимог цього закону до виключних прав правовласників, в тому числі ввозить до Російської Федерації екземпляри програми для ЕОМ чи бази даних , виготовлені без дозволу правовласника. Це може виражатися у привласненні авторства, здійсненні перерахованих у ст. 10 Закону РФ "Про правову охорону програм для ЕОМ і баз даних" дій без дозволу правовласника і т. д.
Окрему виділення імпорту примірників програми для ЕОМ чи бази даних, виготовлених без дозволу їх правовласників пояснюється тим, що в державі, де дані екземпляри були виготовлені, ця дія може вважатися законним і не тягне відповідальності.
ВИСНОВОК
Інформаційна безпека відноситься до числа дисциплін, що розвиваються надзвичайно швидкими темпами. Цьому сприяють як загальний прогрес інформаційних технологій, так і постійне протиборство нападників і захищаються.
На жаль, подібна динамічність об'єктивно ускладнює забезпечення надійного захисту. Причин цього кілька:
• підвищення швидкодії мікросхем, розвиток архітектур з високим ступенем паралелізму дозволяє методом грубої сили (перебором варіантів) долати бар'єри (насамперед криптографічні), які раніше здавалися неприступними;
• розвиток мереж, збільшення числа зв'язків між інформаційними системами, зростання пропускної здатності каналів розширюють число потенційних зловмисників, які мають технічну можливість здійснити напад;
• поява нових інформаційних сервісів веде і до появи нових загроз як "усередині" сервісів, так і на їх стиках;
• конкуренція серед виробників програмного забезпечення змушує скорочувати терміни розробки системи, що веде до зниження якості тестування та випуску продуктів з дефектами захисту;
• нав'язувана споживачам парадигма постійного нарощування апаратного та програмного забезпечення вступає в конфлікт з бюджетними обмеженнями, через що знижується частка асигнувань на безпеку.
Забезпечення інформаційної безпеки сучасних інформаційних систем потребує комплексного підходу. Вона неможлива без застосування широкого спектру захисних засобів, об'єднаних в продуману архітектуру. Далеко не всі ці кошти отримали поширення в Росії, деякі з них навіть у світовому масштабі перебувають у стадії становлення. У цих умовах позиція по відношенню до інформаційної безпеки повинна бути особливо динамічною. Теоретичні погляди, стандарти, сформовані порядки необхідно постійно звіряти з вимогами практики. Від атак не захиститися книгою (навіть помаранчевої) або сертифікатом. Реальна безпека потребує щоденній роботі всіх зацікавлених сторін.
СПИСОК ЛІТЕРАТУРИ
Голіцина О.Л., Максимов Н.В. та ін, "Бази даних" (навчальний посібник)
Могилів А.В., Пак Н.І. та ін, "Інформатика"
Родзинок В.П. "Піратство у сфері програмного забезпечення" / / Фінансові новини від 23 травня 2003
Стаття Юрія Шермана / / www.tour-soft.com
Стаття Сергія Гаврилова / / www.sergevg @ usa.net
Партика Т.Л., Попов І.І. "Інформаційна безпека" 2004 р.
Герасименко В.А., Малюк О.О., "Основи захисту інформації" М.: МІФІ, 2001 р.