Російська версія “індійської захисту”, або захист даних в СУБД Oracle, Криптографія, Security & Hack, статті

– Знаєш, зараз практично всі нові версії Oracle пишуть індійські програмісти.
– Так, шкода, що не наші …
З розмови російських програмістів

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

Але поки наші законодавці сперечаються про проекти законів про комерційну таємницю та електронної торгівлі, у громадських місцях – в переходах метро і навіть на автостоянках, не кажучи вже про Інтернет, продовжують продаватися компакт-диски з різноманітними базами даних (БД). Вибір надзвичайно широкий: за 40-60 дол вам запропонують БД МГТС (актуалізація – січень 2003 р.), Єдиної державної реєстрації підприємств (повна інформація про підприємства, зареєстрованих в Росії в 2003 р.), відомості про прописку в Москві і Московській області, а дорожче, за 110 дол, можна купити БД ЗЕД і т. д. Злегка “залежаний товар”, наприклад, трохи застарілі дані про абонентів МТС (станом на листопад 2002 р.), йде всього за 40 “у. е”.

Навряд чи будь-чесному громадянину буде приємно виявити свої персональні дані на придбаному таким способом компакт-диску. Адже такий диск може легко купити не тільки “допитливий товариш”, а й так звані кримінальні структури. Однак найстрашніше, що реальних механізмів запобігання крадіжки інформації та докази злочину для покарання зловмисників до теперішнього часу практично не існувало. За даними авторів, на момент написання статті рішення, що реалізує захист даних під керуванням СУБД Oracle 9i за допомогою електронних ключів еToken, не має аналогів на світовому ринку захисту інформації.

Суть методу полягає в застосуванні штатних механізмів інфраструктури відкритих ключів та організації доступу користувачів до інформації по пред’явленню цифрових сертифікатів Х.509, підтримуваних засобами Oracle Advanced Security, в двох рівнях: для аутентифікації в корпоративній мережі (наприклад, під керуванням Microsoft Windows Server 2000/2003) і для доступу до конфіденційних даних, які обробляються і зберігаються на серверах Oracle. Обидва сертифіката зберігаються в персональному ідентифікаторі у вигляді USB-ключа або смарт-карти eToken.

Цей метод дозволяє значно знизити ризики від втрат, пов’язаних з людським фактором, і однозначно персоніфікувати дії користувачів інформаційної системи, що працюють з СУБД Oracle 9i.

Основні питання


Чому крадіжки інформації трапляються у різних організаціях, навіть у силових відомствах? Які передумови витоку даних, і чи треба володіти великими знаннями і умінням зломщика, щоб подолати існуючу захист? Чи існують способи побудови систем захисту інформації (СЗІ), що дозволяють звести до мінімуму ризики втрати даних? Чи можна захистити корпоративні дані від власного системного адміністратора?

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

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


Типова модель захисту доступу користувача до корпоративних даних і додатків включає в себе чотири елементи:


Оскільки організаційні заходи і механізми обмеження доступу до корпоративної мережі докладно описані з точки зору як методології [1, 2], так і практичної реалізації, варто докладніше зупинитися на завданнях захисту доступу до СУБД і обмеження на використання прикладного програмного забезпечення. Але спочатку поговоримо про те, які умови “сприяють” викрадення інформації.

Чому крадуть інформацію


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

Причина перша і головна – відсутність системного підходу до оцінки загроз. На жаль, в даний час лише мала частина підприємств застосовує на практиці міжнародний досвід і докладно описаний у роботах Держтехкомісії загальний підхід до оцінки загроз [3], а також рекомендації щодо застосування адекватних засобів захисту інформації.

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

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

Зовнішні загрози неправомірного доступу до корпоративних даних також поділяються на два підкласи, з яких на частку зовнішніх хакерів припадає до 20%, а на частку легальних користувачів корпоративної мережі – до 100%.

Причина друга – неспроможність парольного захисту. Незважаючи на величезну кількість публікацій про те, що паролі не забезпечують належний захист даних і програм, цей спосіб до цих пір найбільш широко поширений, перш за все через свою нульовою вартістю. Досить докладно питання про неспроможність парольного захисту розглянутий, наприклад, в роботах [4, 5].

Найнеприємніше, що такий підхід часто застосовується і в далеко не дрібних організаціях. А доступ до ресурсів системи кількох різних користувачів під одним і тієї ж обліковим записом – вельми поширена і міцно закорінена практика. Наприклад, якщо в організації працюють п’ять системних адміністраторів, то всі вони можуть мати доступ по одному паролю. Добре ілюструє порочність такої організації доступу аналогія з їздою по вулицях великого міста на автомобілях без номерів. Ніякої співробітник ДАІ не зможе чітко ідентифікувати автомобіль, що перевищує дозволену швидкість, в потоці “анонімів”, якщо все їдуть без номерних знаків.

Причина третя – не повністю задіяні вбудовані в СУБД засоби захисту інформації та моніторингу дій користувачів, а також невиправдані надії на кваліфікацію розробників прикладного ПО в частині організації системи управління правами доступу. На кому реально лежить відповідальність за застосування / незастосування вбудованих в СУБД засобів захисту інформації? Швидше за все, на розробників прикладного ПЗ, які впроваджують свої системи у замовників. Але парадокс полягає в тому, що розробники в переважній більшості не мають у своєму штаті спеціаліста по СЗІ і не знають про штатні можливості організації захисту СУБД. За найскромнішими оцінками, на російському ринку працює кілька тисяч прикладних систем і програмних продуктів, що базуються на використанні промислових СУБД. При цьому в переважній більшості випадків вважається, що всі питання, пов’язані з безпекою даних, виконує сама СУБД1, а доступ в ІС відбувається за паролем.

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

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

Вбудовані засоби захисту


Якщо розглядати засоби забезпечення безпеки в частині доступу до БД, зберігання інформації та передачі по мережі, то сьогодні явний лідер2 ринку систем управління базами даних – СУБД Oracle. Вона надає розробникам ПО і адміністраторам прикладних систем повний спектр засобів та інструментів, необхідних для побудови захищених систем. Серед них варто виділити наступні:

Virtual Private Database (VPD) – Засоби розмежування доступу до даних на рівні рядків (у версії 10g – і на рівні колонок) і можливість організації роботи користувача тільки з віртуальною регламентованої частиною даних, а не з реальною базою даних;

Oracle Advanced Security – Комплекс засобів аутентифікації і забезпечення мережевої безпеки, що включає в себе підтримку захищених протоколів передачі даних, у тому числі SSL;

Oracle Label Security (OLS)– Кошти, аналогічні VPD, але з можливістю перевірки рівня доступу користувача;

Fine Grained Audit Control (FGAC) – Інструмент докладного аудиту.

Штатні засоби Oracle + еToken


Кардинально підвищити безпеку роботи додатків БД дозволяє захист клієнтського ПЗ СУБД Oracle 9i за допомогою електронних ключів еToken. Істотно посилити захист вдалося завдяки застосуванню кількох технологічних рішень.

Перш за все метод аутентифікації користувачів по імені і паролю був замінений більш надійною – двофакторної аутентифікації з використанням цифрових сертифікатів стандарту X.509. І хоча вбудовані засоби Oracle Advanced Security підтримують аутентифікацію по цифрових сертифікатах, питання про зберігання сертифікатів та особистих ключів залишається відкритим. Пропоновані Oracle способи зберігання сертифікатів у вигляді файлів-контейнерів формату PKCS # 12 або реєстру ОС Windows мають ряд істотних недоліків. Суть вбудованих в Advanced Security можливостей ілюструє схема зберігання сертифікатів (рис. 1).

Рис. 1. Схема зберігання цифрових сертифікатів Oracle в архітектурі Oracle Advanced Security з використанням eToken.

Файл-контейнер, наприклад, може бути викрадений зловмисником, які мають права на читання відповідного ключа реєстру або файла-контейнера. У той же час робота з СУБД дозволений тільки користувачеві, для якого сформовано відповідний контейнер і, більше того, він “прив’язаний” до певної робочої станції (де знаходиться файл-контейнер). Щоб уникнути цих “неприємностей”, необхідно зберігати цифрові сертифікати безпосередньо в пам’яті електронного ключа eToken, а для виконання криптографічних операцій із закритим ключем використовувати вбудований в нього кріптопроцессор з додатковою PIN-авторизацією користувача.

Очевидно, що, крім підвищення надійності, аутентифікація з використанням eToken дає ряд переваг у порівнянні з традиційним (логін / пароль) методом. Перш за все електронний ключ дає можливість користувачеві різних додатків не зберігати “де потрапило” і не запам’ятовувати необхідні імена та паролі. Знаючи один PIN-код і вибравши сертифікат із запропонованого списку, можна, маючи відповідні права і привілеї, звертатися до конкретної БД, причому c будь-якої робочої станції.

Адміністратор безпеки отримує при цьому додаткові зручності у вигляді централізованого управління доступом та контролю роботи системних адміністраторів. Всі ці можливості управління забезпечує єдиний інструмент – служба каталогів Oracle Internet Directory. Існуючі програми отримують “в особі” служби каталогів єдину точку входу – свого роду портал архітектури клієнт-сервер. При цьому в більшості випадків змін у прикладному ПЗ не потрібно.








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

На сервері:



  • СУБД Oracle (Enterprise Edition + Oracle Advanced Security option)
  • Служба каталогу Oracle Internet Directory (OID) версії 9.2.0.2 або вище
На робочій станції-клієнта:



  • ОС Microsoft Windows 2000/XP
  • Oracle9i Database Release 2 Client версії 9.2.0.3 і вище
  • eToken RTE 3.0.116 і вище
  • eToken RTX 1.0 і вище

Архітектурні особливості


Запропоноване рішення базується на використанні цифрових сертифікатів стандарту X.509 та протоколу Secure Sockets Layer (SSL), що підтримує сувору двохфакторну аутентифікацію користувачів СУБД Oracle, а також шифрування інформації, переданої по мережі між сервером БД і клієнтської робочої станцією (рис. 2). При цьому задіяні лише штатні налаштування СУБД і клієнта Oracle, описані в документації по Oracle Advanced Security [6]. Установка на робочій станції сервісів eToken дає можливість застосовувати наявні на ключі сертифікати для аутентифікації в СУБД Oracle (див. врізку “Процедура аутентифікації в СУБД Oracle з використанням eToken “).

Рис. 2. Архітектура надання доступу.








Процедура аутентифікації в СУБД Oracle з використанням eToken

Етап 1. Встановлення з’єднання клієнт-сервер



  1. Клієнт надсилає запит на встановлення SSL-з’єднання.
  2. Сервер відповідає на запит посилкою свого сертифіката і робить запит сертифіката клієнта.
  3. Клієнт перевіряє цілісність, дату і термін дії сертифіката, а також те, що сертифікат підписаний довіреною видавцем.
  4. У разі підтвердження автентичності сертифіката сервера клієнт посилає йому власний сертифікат, який користувач може вибрати із запропонованого списку.
  5. Сервер перевіряє цілісність, дату і термін дії сертифіката, а також те, що сертифікат клієнта підписано довіреною видавцем, і при підтвердженні справжності “дає згоду” на обмін даними (в зворотному випадку – відмова в доступі).
  6. Клієнт і сервер обмінюються ключовою інформацією, використовуючи криптографічні алгоритми з відкритим ключем. На даній стадії запитується авторизація користувача в eToken (введення PIN-коду).
  7. На підставі ключової інформації формується сесійний ключ для шифрування трафіку протягом сесії з використанням найкращого симетричного алгоритму, доступного і для клієнта, і для сервера.
  8. З’єднання клієнта з сервером встановлено.
Етап 2. Авторизація користувача мережевими службами Oracle в БД



  1. У LDAP-каталозі (Oracle Internet Directory) проводиться пошук розпізнавального імені користувача, відповідного полю Subject сертифіката клієнта.
  2. Якщо знайдено відповідність, то по рядку зв’язку з’єднання визначається потрібна БД, а по полю Subject сертифіката клієнта – схема доступу користувача до зазначеної БД.
  3. Визначаються ролі масштабу підприємства (enterprise roles) та їх відповідність ролям у вибраній схемі користувача.
  4. Встановлюється з’єднання з БД.

Сертифікати та пов’язані з ними закриті ключі зберігаються в захищеній пам’яті eToken (вона доступна тільки вбудованому в нього кріптопроцессору). Щоб виконати криптографічні операції із закритим ключем, користувач повинен ввести PIN-код. Такий підхід дозволяє на практиці реалізувати модель організації захищеного доступу користувача до даних (СКБД) з використанням цифрових сертифікатів Х.509, встановлених в eToken, у двох рівнях. Легальні користувачі корпоративної мережі (наприклад, під управлінням контролера домену Windows 2000/2003) можуть авторизуватися в мережі (рис. 3) тільки після успішного завершення процесу аутентифікації по смарт-картки, що включає пред’явлення відповідного сертифікату (перший рівень). На другому рівні захисту доступ авторизованих користувачів корпоративної мережі до захищених даними СУБД можливий тільки при пред’явленні відповідного сертифіката Oracle.

Рис. 3. Дворівнева модель доступу до захищених даних за допомогою цифрових сертифікатів Х.509.

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

Додаткові джерела інформації


  1. ДСТУ ISO / IEC 15408-2002 Інформаційна технологія. Методи і засоби забезпечення безпеки. Критерії оцінки безпеки інформаційних технологій. Частини 1, 2, 3. Керівний документ. Безпека інформаційних технологій. Критерії оцінки безпеки інформаційних технологій. Частина 1: Вступ та загальна модель. Держтехкомісії Росії, 2002.
  2. Керівний документ. Автоматизовані системи. Захист від несанкціонованого доступу до інформації. Класифікація автоматизованих систем і вимоги щодо захисту інформації. Держтехкомісії Росії, 1992.
  3. Калайда І. А. “Основні розглядаються загрози при проведенні оцінки відповідності систем управління мережами передачі даних вимогам безпеки інформації”. Матеріали 2-й міжвідомчої конференції “ТелекомТранс-2004”.
  4. Сабруков А., Груші А. “Аутентифікація в комп’ютерних системах”. Системи безпеки, № 5 (53), 2003.
  5. Галицький А. В., Рябко С. Д., Шаньгина В. Ф. “Захист інформації в мережі – аналіз технологій і синтез рішень”. М.: ДМК Пресс, 2004.
  6. Oracle Advanced Security Administrator”s Guide Release 2 (9.2).


1 – Зазвичай промислові СУБД класу DB2 і Oracle сертифіковані як мінімум по класу захищеності С2.

2 – За даними ряду джерел, у тому числі IDC. – Прим. ред.

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


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

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

Ваш отзыв

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

*

*