Російська версія "індійської захисту"

– Знаєш, зараз практично всі нові версії 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).

Рис. 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>

*

*