- Серія контенту:
- Цей контент є частиною серії: Безпека DB2 UDB, частина 5
- Малюнок 1. Функція аудиту DB2 в архітектурі DB2 UDB
- Малюнок 2. Папка безпеки на Windows-сервері
- Налаштування буфера аудиту
- Налаштування охоплення і статусу аудиту
- Таблиця 1. Події бази даних, які можуть відслідковуватися функцією аудиту
- статус подій
- Обробка помилок
- Синтаксис команди db2audit
- Лістинг 1. Синтаксис утиліти db2audit
- Лістинг 2. Висновок описуваної команди db2audit в середовищі Windows
- Експорт записів аудиту
- важливе виправлення
- Видалення непотрібних записів в файлі db2audit.log
- Формат запису аудиту
- Лістинг 3. Фрагмент записів аудиту, витягнутих за допомогою опції FILE
- Лістинг 4. Фрагмент записів аудиту, витягнутих за допомогою опції DELASC
- Таблиця 2. Опис формату записів аудиту для типу подій AUDIT
- Завантаження витягнутих записів аудиту в таблиці DB2
- Робота з даними аудиту в таблицях DB2
- Узагальнимо отримані навички
- Лістинг 5. Результат запиту таблиці CHECKING
- Висновок
- Ресурси для скачування
Безпека DB2 UDB, частина 5
Серія контенту:
Цей контент є частиною # з серії # статей: Безпека DB2 UDB, частина 5
https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Безопасность+db2+udb,+часть+5
Слідкуйте за виходом нових статей цієї серії.
Цей контент є частиною серії: Безпека DB2 UDB, частина 5
Слідкуйте за виходом нових статей цієї серії.
Функція аудиту DB2 UDB - це важливий інструмент безпеки в інструментарії адміністратора бази даних. Ця функція створює протокол аудиту і надає адміністратору бази даних можливість вести його для серій використовуються стандартні подій бази даних. Вона може протоколювати такі події бази даних, як перевірка авторизації, управління об'єктами бази даних, управління безпекою, системне адміністрування та ідентифікація користувачів. У статті показано, як найбільш ефективно використовувати цю функцію для відстеження та дослідження підозрілої системної активності.
Аудит працює на рівні примірника, це означає, що після запуску функція відстежує активність для всіх баз даних в цьому екземплярі. Функція аудиту може бути запущена і зупинена окремо від бази даних. Наприклад, якщо ви зупинили екземпляр за допомогою команди db2stop, функція аудиту не завершується автоматично; її слід зупинити окремо, виконавши команду db2audit stop. Настроювання та використання функцію аудиту можуть тільки користувачі з повноваженнями SYSADM (системного адміністратора). Опис рівня повноважень SYSADM і принципу призначення їх групам користувачів см. В частини 4 даної серії статей. Цю інформацію також можна знайти в документації DB2 UDB .
На малюнку 1 показана Високорівнева діаграма функції аудиту та її місце в загальній архітектурі СУБД DB2 UDB.
Малюнок 1. Функція аудиту DB2 в архітектурі DB2 UDB
Описує синій овал на діаграмі представляє сервер бази даних DB2. Вписаний червоний прямокутник представляє екземпляр DB2. Як показано на малюнку, функція аудиту працює на рівні примірника, обслуговуючи всі бази даних цього примірника. Для налаштування параметрів аудиту використовується файл конфігурації.
Після запуску функції аудиту згенеровані записи аудиту записуються в буферну область, а потім переносяться на диск в файл аудиту. По завершенні періоду аудиту файл аудиту може бути конвертований з власного "машинного" формату в придатний для читання текстовий файл. Записи аудиту можуть бути також за бажанням завантажені в таблиці DB2, завдяки чому адміністратор отримує можливість запитувати дані, використовуючи SQL, і створювати власні звіти.
Файли, що створюються функцією аудиту, зберігаються і ведуться в папці безпеки примірника. На малюнку 2 показаний приклад вмісту цієї папки на Windows-сервері для екземпляра під назвою DB2.
Малюнок 2. Папка безпеки на Windows-сервері
У файлі db2audit.cfg зберігається інформація про параметри налаштування функції аудиту. Це двійковий файл, який слід змінити, лише з використанням синтаксису командного рядка db2audit. У файлі db2audit.log зберігаються "машинні" записи аудиту. Записи аудиту можуть бути вилучені з цього файлу в текстовий файл, який в подальшому можна буде проаналізувати. Файл db2audit.log не існує за замовчуванням і не створюється до тих пір, поки не будуть згенеровані записи аудиту або не відбудеться скидання буфера аудиту. При створенні нового екземпляра для цього файлу встановлюються дозволу "читання / запис"; користувачам не рекомендується змінювати ці дозволи.
Існує два основних аспекти настройки функції аудиту. Перший відноситься до налаштування буферної області, а другий стосується настройки типу подій, які підлягають аудиту. У наступних двох розділах більш детально розглядаються ці настройки.
Налаштування буфера аудиту
Записи аудиту перед скиданням на диск зазвичай пишуться в буферну область пам'яті. Розмір буфера визначається параметром конфігурації адміністратора бази даних AUDIT_BUF_SZ. Цей параметр визначає кількість сторінок розміром 4 К, які відводяться під розміщення буфера аудиту. Вибір розміру буфера може в значній мірі впливати на продуктивність, оскільки після початку аудиту в протокол аудиту може бути внесено багато записів.
Якщо розмір буфера встановлений рівним 0, відбувається синхронний запис протоколу, і буфер аудиту не використовується. У цій конфігурації подія, яка викликала генерацію записи аудиту, до повернення статусу повинно очікувати, поки запис аудиту не буде перенесена на диск. Очікування, пов'язане з кожним записом, викликає зниження продуктивності DB2. Якщо розмір буфера більше 0, записи аудиту пишуться не синхронно. Тобто, вони залишаються в буфері аудиту до тих пір, поки не будуть скинуті на диск. Щоб уникнути продовження періоду буферизації DB2 регулярно виконує примусову запис протоколу аудиту. Буфер аудиту можна скинути також вручну за допомогою команди скидання db2audit. При асинхронної записи протоколу, події, викликав генерацію протоколу аудиту, не доводиться очікувати повернення статусу до завершення запису протоколу аудиту на диск.
Припустимо, ви хочете збільшити розмір буфера аудиту до 40 Кбайт, щоб активізувати асинхронне протоколювання і підвищити продуктивність. Для виконання цього завдання ви можете виконати наступні команди:
update dbm cfg using audit_buf_sz 10
db2stop
db2start
Зверніть увагу, що після поновлення цих параметрів вам слід перезавантажити екземпляр, щоб зміна параметрів мало ефект.
Важливий фактор, який слід взяти до уваги, роблячи вибір між синхронним і асинхронним способом записи протоколу - це наслідки, які можуть статися в разі помилки адміністратора бази даних. Якщо помилка трапляється при використанні асинхронної записи протоколу, то кілька записів аудиту можуть бути втрачені, тому що перед записом на диск вони знаходяться в буфері. Якщо ведеться синхронний запис протоколу, то може бути втрачена лише один запис, адже помилка може перешкодити, щонайбільше, записи одного події аудиту.
Налаштування охоплення і статусу аудиту
Функція аудиту може відстежувати різні типи подій бази даних. Корисно розглянути ці типи подій до вивчення точного синтаксису команди db2audit, використовуваної для настройки функції.
У таблиці 1 перераховуються різні типи подій бази даних, які можуть відслідковуватися і описуватися при генерації записи аудиту. Слово в круглих дужках, яке слід за типом події - це відповідне ключове слово, яке використовується в конфігураційному вираженні команди db2audit.
Таблиця 1. Події бази даних, які можуть відслідковуватися функцією аудиту
Тип події Опис Аудит
(AUDIT)
- Генерує записи в тому випадку, якщо змінюються параметри аудиту або здійснюється доступ до протоколу аудиту.
перевірки авторизації
(CHECKING)
- Генерує записи в процесі перевірки авторизації при спробі доступу або маніпулювання об'єктами бази даних або функціями
управління об'єктами
(OBJMAINT)
- Генерує записи при створенні або видаленні об'єктів бази даних
обслуговування безпеки
(SECMAINT)
- Генерує записи при призначенні або відкликання дозволів для об'єкта або бази даних, а також повноважень адміністратора DBADM
- Записи також генеруються, якщо змінюються параметри конфігурації безпеки адміністратора бази даних SYSADM_GROUP, SYSCTRL_GROUP або SYSMAINT_GROUP
адміністрування системи
(SYSADMIN)
- Генерує записи при виконанні дій, що вимагають повноважень SYSADM, SYSMAINT або SYSCTRL
ідентифікація користувача
(VALIDATE)
- Генерує записи при аутентифікації користувачів або витягу системної інформації, пов'язаної з безпекою
зміст операції
(CONTEXT)
- Генерує записи, що показують зміст операції при виконанні дій з базою даних
- Ця категорія дозволяє краще інтерпретувати записи аудиту. При використанні разом з полем коррелятора протоколу, група подій відслідковується аж до окремої операції, яка може надати необхідні для аналізу результатів аудиту відомості.
Наприклад, якщо вам потрібно виконати аудит тільки підключень до бази даних і типу подій "системне адміністрування", то при налаштуванні функції вам потрібно визначити тільки типи подій VALIDATE і SYSADMIN.
статус подій
Після того, як ви вибрали потрібний тип подій, які підлягають аудиту, ви можете також визначити, які події будуть заноситися в протокол: тільки успішні, тільки невдалі або і ті, і інші. Запис успішних подій істотно збільшує кількість генеруються записів, тому використовуйте цю опцію розумно.
Обробка помилок
Ви можете також налаштувати спосіб обробки функцією аудиту помилок за допомогою виразу ERRORTYPE команди db2audit. Можна вибрати один з двох варіантів: помилки функції аудиту повертаються користувачу (AUDIT) або ігноруються (NORMAL). У першому випадку все помилки, включаючи ті, які відбуваються в самій функції аудиту, обробляються DB2, і всі негативні коди SQLCODE повідомляються з додатком. У другому випадку будь-які помилки, які генеруються функцією аудиту, ігноруються, і з додатком повертаються тільки ті коди SQLCODE, які відповідають помилок, пов'язаних з виконанням операцій.
Синтаксис команди db2audit
Тепер, коли вам відомі різні типи подій, які можуть відслідковуватися, а також параметри статусу і обробки помилок, давайте розглянемо синтаксис даної команди для налаштування і використання функції аудиту. У лістингу 1 показаний синтаксис команди db2audit, який використовується для настройки і роботи функції аудиту.
Лістинг 1. Синтаксис утиліти db2audit
>> - db2audit - + - configure - + - reset ------------------- + ---------------- ---------- + -> <| '- | Audit Configuration | - '| + -Describe ----------------------------------------------- --------- + + -extract-- | Audit Extraction | ----------------------------------- + + -flush -------- -------------------------------------------------- - + + -prune - + - all ---------------------------------------- ---------- + - + | '-Date - YYYYMMDDHH - + -------------------------------- + -' | | '-Pathname - Path_with_temp_space-' | + -Start ----------------------------------------------- ------------ + '-stop ---------------------------------- -------------------------- 'Audit Configuration: | - + ---------------- ------------- + - + --------------------- + -----> '-scope-- + -all -------------- + - '' -status - + - both ---- + - '| .-, ------------. | + -Success- + | V | | '-Failure-' '--- + - audit ---- + - + -' + -checking- + + -objmaint- + + -secmaint- + + -sysadmin- + + -validate- + '-context- - '> - + ----------------------- + -------------------- ---------------- | '-Errortype - + - audit - + -' '-normal-' Audit Extraction: | - + - file - output-file ------------------ --- + --------------------> '-delasc - + ------------------- -------- + - '' -delimiter - load-delimiter- '> - + ------------------------- --- + -------------------------------> | .-, ------------. | | V | | '-Category ---- + - audit ---- + - + -' + -checking- + + -objmaint- + + -secmaint- + + -sysadmin- + + -validate- + '-context--' > - + ------------------------- + - + ----------------- ---- + --------- | '-Database - database-name-' '-status - + - success - + -' '-failure-'
Щоб краще зрозуміти, як використовувати синтаксис команди, в цій статті наводиться кілька прикладів. У першому прикладі потрібно налаштувати функцію аудиту на протоколювання тільки невдалих подій AUDIT і VALIDATE, використовуючи алгоритм обробки помилок NORMAL. Щоб вирішити це завдання, виконайте наступну команду db2audit:
db2audit configure scope audit, validate status failure errortype normal
Щоб налаштувати функцію аудиту на відстеження будь-яких типів подій з протоколированием як успішних, так і невдалих спроб, а також використовувати алгоритм AUDIT для обробки помилок, виконайте наступну команду db2audit:
db2audit configure scope all status both errortype audit
Для перегляду поточних параметрів конфігурації і статусу скористайтеся наступною командою db2audit:
db2audit describe
Висновок цієї команди показаний в лістингу 2 :
Лістинг 2. Висновок описуваної команди db2audit в середовищі Windows
C: \ Program Files \ IBM \ SQLLIB \ DB2 \ security> db2audit describe DB2 AUDIT SETTINGS: Audit active: "TRUE" Log errors: "TRUE" Log success: "FALSE" Log audit events: "FALSE" Log checking events: " TRUE "Log object maintenance events:" FALSE "Log security maintenance events:" FALSE "Log system administrator events:" FALSE "Log validate events:" FALSE "Log context events:" FALSE "Return SQLCA on audit error:" FALSE "AUD0000I Operation succeeded.
Вивчаючи висновок, представлений в лістингу 2, ви можете бачити, що події були внесені в протокол, незалежно від того, була запущена функція аудиту чи ні. Щоб скинути поточні параметри конфігурації функції аудиту та повернути їх до вихідних значень (SCORE включає всі категорії, крім CONTEXT, STATUS дорівнює FAILURE, значення ERRORTYPE - NORMAL, а функція аудиту виключена -OFF), виконайте наступну команду:
db2audit configure reset
Ця команда також створює новий файл конфігурації функції аудиту, якщо оригінальний був втрачений або пошкоджений.
Після того, як ви налаштували типи подій, які хочете відстежувати, а також опції статусу і обробки помилок, ви можете запустити функцію аудиту. Згадаймо, що функція аудиту запускається і зупиняється незалежно від екземпляра бази даних. Щоб запустити функцію, виконайте наступну команду:
db2audit start
Після того, як ви закінчите дії аудиту і захочете зупинити функцію аудиту, виконайте наступну команду:
db2audit stop
Експорт записів аудиту
Записи аудиту в файлі db2audit.log зберігаються в "машинному" форматі. Ви можете отримати всі записи аудиту з цього файлу в текстовий файл, який потім можна буде проаналізувати. Ви можете також вибрати варіант вилучення записів аудиту в файли ASCII з роздільниками, які потім можна завантажити в реляційні таблиці DB2 для аналізу і запитів.
Перед витяганням записів аудиту з файлу db2audit.log, скиньте будь-які залишилися в буфері файли на диск, виконавши наступну команду:
db2audit flush
Щоб витягти записи з файлу db2audit.log в текстовий файл, виконайте наступну команду db2audit:
db2audit extract file c: \ temp \ audit_01_22_2006.aud
де "c: \ temp \ audit_01_22_2006.aud" - це шлях і ім'я для обраного файлу виводу. Якщо ви не визначили ім'я файлу, запису записуються в файл db2audit.out в підкаталозі безпеки $ INSTHOME / sqllib, де INSTHOME - це домашній каталог примірника. Якщо не заданий каталог, файл виводу записується в поточний робочий каталог.
Щоб витягти записи з файлу протоколу db2audit.log в файл ASCII з роздільниками, який згодом може бути завантажений в реляційні таблиці DB2, запустіть таку команду db2audit:
db2audit extract delasc delimiter!
Висновок буде поміщений в окремі файли (один файл для кожного типу події) в підкаталог безпеки каталогу sqllib. Використовуються такі імена файлів:
- audit.del
- checking.del
- objmaint.del
- secmaint.del
- sysadmin.del
- validate.del
- context.de
Якщо в попередню команду вставити вираз DELIMITER, а потім вказати новий роздільник полів (в даному випадку знак оклику "!"), Можна змінити роздільник полів за замовчуванням для функції аудиту (0хff) при отриманні даних з протоколу аудиту.
Ви також можете обмежити кількість і тип видобутих записів аудиту, визначивши відповідно вираження CATEGORY, DATABASE і STATUS. Вираз CATEGORY дозволяє визначити, які категорії подій аудиту слід витягти з протоколу аудиту. Якщо ви нічого не визначите в цьому виразі, всі категорії будуть придатні для вилучення. Вираз DATABASE дозволяє обмежити витяг записів певною базою даних. Якщо ви нічого не визначите в цьому виразі, то записи аудиту для всіх баз даних примірника будуть розглядатися як придатні для вилучення. Вираз STATUS дозволяє визначити, чи хочете ви отримати успішні, невдалі або як успішні, так і невдалі події. Якщо ви нічого не визначите в цьому виразі, всі записи будуть розглядатися як придатні для вилучення.
Припустимо, наприклад, що ви хочете отримати тільки записи про події типу AUDIT в файл формату ASCII з роздільником полів у вигляді символу знаку оклику "!" . Припустимо далі, що ви хочете отримати тільки записи, які стосуються базі даних SAMPLE, причому вас цікавлять тільки події зі статусом FAILURE. Для вирішення цього завдання виконайте наступну команду db2audit:
db2audit extract delasc delimiter! category audit database sample status failure
важливе виправлення
До версії DB2 UDB V8.1 Fix Pak 10 фаза вилучення могла поглинати багато ресурсів ЦПУ. Це було виправлено в пакеті виправлень Fix Pak 10. Більш детально це описано в інформації APAR .
Щоб витягти тільки події аудиту SYSADMIN в звичайний текстовий файл з назвою audit.db2; причому тільки події, пов'язані з базі даних SAMPLE, включаючи події зі статусом і SUCCESS, і FAILURE, виконайте наступну команду db2audit:
db2audit extract file audit.db2 category sysadmin database sample
Видалення непотрібних записів в файлі db2audit.log
Файл протоколу аудиту (db2audit.log) може дуже швидко розростися. Періодично видаляти з файлу втратили актуальність записи - дуже хороша думка. Видалення з протоколу аудиту тих записів, які вже були вилучені в текстовий файл, запобігає також повторне вилучення одних і тих же записів. Для видалення запису в файлі db2audit.log, виконайте наступну команду db2audit:
db2audit prune date YYYYMMDDHH
де YYYYMMDDHH означає поточний рік, місяць, день і годину. Всі записи аж до зазначених дати та часу, будуть видалені. Запишіть цю дату і зберігайте під рукою, якщо зберігаєте записи аудиту в таблицях DB2.
Щоб видалити всі записи, виконайте наступну команду db2audit:
db2audit prune all
Формат запису аудиту
Текстовий файл, что отримується в результате процесса вилучення, складається з декількох запісів аудиту, розділеніх рядком сімволів пробілу. У лістінгу 3 показаний фрагмент записів аудиту, які були вилучені за допомогою опції FILE.
Лістинг 3. Фрагмент записів аудиту, витягнутих за допомогою опції FILE
timestamp = 2006-02-06-11.54.52.443000; category = AUDIT; audit event = START; event correlator = 0; event status = 0; userid = tedwas; authid = TEDWAS; timestamp = 2006-02-06-11.55.14.664000; category = AUDIT; audit event = CONFIGURE; event correlator = 0; event status = 0; userid = tedwas; authid = TEDWAS; timestamp = 2006-02-06-11.55.19.371000; category = AUDIT; audit event = CONFIGURE; event correlator = 0; event status = 0; userid = tedwas; authid = TEDWAS; timestamp = 2006-02-06-11.55.30.718000; category = AUDIT; audit event = FLUSH; event correlator = 0; event status = 0; userid = tedwas; authid = TEDWAS;
Розглядаючи ці записи, ви можете бачити, що користувач 'TEDWAS' спочатку запустив утиліту аудиту, потім двічі змінив настройки, а на закінчення скинув буфер аудиту. Всі ці події відбулися в один виділений інтервал часу, як показує скупченість значень в поле TIMESTAMP. За значенням AUDIT в поле категорії ви можете також помітити, що ці події відносяться до типу подій AUDIT.
лістинг 4 демонструє фрагмент тих же записів, які були вилучені з протоколу аудиту на цей раз за допомогою опції DELASC з роздільником полів "крапка з комою (;)" Записи були взяті з файлу audit.del, який був згенерований в процесі вилучення.
Лістинг 4. Фрагмент записів аудиту, витягнутих за допомогою опції DELASC
; 2006-02-06-11.54.52.443000;,; AUDIT;,; START;, 0,0,; tedwas;,; TEDWAS; ; 2006-02-06-11.55.14.664000;,; AUDIT;,; CONFIGURE;, 0,0,; tedwas;,; TEDWAS; ; 2006-02-06-11.55.19.371000;,; AUDIT;,; CONFIGURE;, 0,0,; tedwas;,; TEDWAS; ; 2006-02-06-11.55.30.718000;,; AUDIT;,; FLUSH;, 0,0,; tedwas;,; TEDWAS; ; 2006-02-06-11.56.04.346000;,; AUDIT;,; EXTRACT;, 0,0,; tedwas;,; TEDWAS;
Зверніть увагу, що в кінці лістингу 4 з'являється додаткова запис. Ця запис була згенерована, коли створювався текстовий файл по команді з лістингу 3. Додаткова запис була згенерована тому, що в момент вилучення функція аудиту була налаштована на протоколювання всіх подій аудиту.
У таблиці 2 наведені значення всіх полів записів аудиту для подій типу AUDIT, представлених в лістингах 3 і 4.
Таблиця 2. Опис формату записів аудиту для типу подій AUDIT
Назва Формат Опис Метка часу CHAR (26) Дата і час події аудиту. Категорія CHAR (8) Категорія події аудиту. Можливі значення: AUDIT. Подія аудиту CHAR (32) Конкретне подія аудиту. Можливі значення: CONFIGURE, DB2AUD, EXTRACT, FLUSH, PRUNE, START, STOP, and UPDATE_ADMIN_CFG. Коррелятор події INTEGER Ідентифікатор кореляції для аудируемой операції. Може використовуватися для ідентифікації записів аудиту, пов'язаних з окремою подією. Статус події INTEGER Статус події аудиту, представлений кодом SQLCODE, де:
- Успішне подія> = 0
- Невдале подія <0
Ідентифікатор користувача VARCHAR (1024) Ідентифікатор користувача під час події аудиту. Ідентифікатор авторизації VARCHAR (128) Ідентифікатор авторизації під час події аудиту.
Детальний опис розкладки записів аудиту для інших типів подій можна знайти в документації DB2 UDB .
Завантаження витягнутих записів аудиту в таблиці DB2
Після того, як ви витягли записи аудиту в файли ASCII з роздільником, ви можете завантажити файли ASCII в таблиці DB2. Потім ви можете запустити для цієї таблиці пропозицію SQL і виконати розширений аналіз даних. Ви можете спочатку створити таблиці, які будуть містити дані аудиту. Найкращий метод - створення таких таблиць в окремій схемі, щоб ізолювати дані від неавторизованих користувачів, зберігши їх для цілей організації. Про те, які саме пропозиції CREATE TABLE слід використовувати, можна прочитати в документації DB2 UDB .
Після того, як ви створили необхідні таблиці, ви можете завантажити в них дані з файлів ASCII з роздільником, які були створені в процесі вилучення. Щоб завантажити дані в таблиці, скористайтеся утилітою LOAD. Наприклад, щоб завантажити в таблицю AUDIT дані з відповідного файлу audit.del, створеного в процесі попереднього вилучення, виконайте наступну команду LOAD:
LOAD FROM audit.del OF del MODIFIED BY CHARDEL! INSERT INTO MYSCHEMA.AUDIT
де MYSCHEMA - це схема, в якій розміщена ваша таблиця аудиту, а AUDIT - це ім'я таблиці. Зверніть увагу на використання виразу MODIFIED BY CHARDEL! Оскільки при створенні файлу ASCII з роздільниками, що містить витягнуті дані, був використаний роздільник полів, відмінний від очікуваного за замовчуванням роздільник (кома), утиліта LOAD була попередньо налаштована на інший роздільник.
Найкраще видалити з таблиці, в яку ви завантажили дані, будь-які непотрібні рядки, щоб переконатися в тому, що згодом ви не завантажте в таблицю дублюючі рядки. Файли аудиту з витягнутими даними можуть містити записи, які були записані вже після видалення непотрібних записів з протоколу аудиту, такі записи слід видалити з таблиці, щоб вони не впливали на результати аналізу. Наступна команда видаляє з таблиці AUDIT ті записи, які мають мітку часу з великим значенням, ніж мітка часу, що використовувалась при видаленні непотрібних записів з файлу протоколу аудиту.
DELETE FROM MYSCHEMA.audit WHERE TIMESTAMP> TIMESTAMP ( 'YYYYMMDDHH0000')
де MYSCHEMA - це схема, в якій розміщується таблиця аудиту, AUDIT - це ім'я таблиці, а YYYYMMDDHH0000 - значення, яке ви визначили при видаленні зайвих записів з протоколу аудиту.
Таким же способом ви можете завантажити в таблиці дані для інших типів подій. пошукайте в документації по DB2 більш детальну інформацію про те, які команди LOAD можна використовувати.
Робота з даними аудиту в таблицях DB2
Завантаження даних аудиту в таблиці має багато переваг. Звичайно, ви могли б написати програму для аналізу вмісту текстових файлів з витягнутими записами аудиту; але якщо дані аудиту розміщені в реляційних таблицях, зазвичай набагато простіше і швидше створити і виконати запит.
Припустимо, ви налаштували функцію аудиту на аудит як успішних, так і невдалих спроб зміни конфігурації функції аудиту. Після закінчення періоду моніторингу ви скидаєте буфер аудиту, витягаєте записи аудиту в файли ASCII з роздільниками, а потім завантажуєте ці файли в таблиці DB2. Якщо, наприклад, ви хочете зробити запит, щоб побачити п'ять ідентифікаторів користувачів, які зробили найбільше невдалих спроб змінити конфігурацію функції аудиту, ви можете виконати наступний запит:
SELECT userid, COUNT (*) AS count FROM MYSCHEMA.audit WHERE status <0 AND event = 'CONFIGURE' GROUP BY userid ORDER BY count FETCH FIRST 5 ROWS ONLY
Ви можете також вирішити використовувати програми вилучення даних для виявлення закономірностей у даних аудиту. Для цього виду аналізу особливо рекомендується сімейство програмних продуктів DB2 Intelligent Miner .
Узагальнимо отримані навички
Тепер, коли ви навчилися налаштовувати і використовувати функцію аудиту, давайте розглянемо приклад, який детально описує весь процес від початку до кінця.
Припустимо, що ви отримали анонімне застереження від одного з користувачів вашого додатка, про те, що користувач з ім'ям SAM в обідню перерву намагається отримати доступ до об'єктів і таблиць бази даних, доступ до яких йому не дозволено. Ви приймаєте рішення поспостерігати за примірником DB2 під час обідньої перерви на предмет виявлення невдалих спроб перевірки авторизації.
Ви починаєте з налаштування функції аудиту на аудит подій типу CHECKING, запис тільки невдалих спроб і використання алгоритму обробки помилок NORMAL.
db2audit configure scope checking status failure errortype normal
Ви забезпечуєте асинхронне протоколювання аудиту, встановлюючи розмір параметра адміністратора бази даних AUDIT_BUF_SZ на 40:
update dbm cfg using audit_buf_sz 40
db2stop
db2start
Ви чекаєте до 12 години дня, а потім запускаєте функцію аудиту:
db2audit start
Протягом періоду аудиту користувач SAM переходить до сервера бази даних і виконує вхід в систему. Він відкриває вікно командного рядка, підключається до бази даних SAMPLE і робить кілька невдалих спроб змінити оклади співробітників в таблиці EMPLOYEE. Він виконує наступні пропозиції SQL:
connect to sample user sam using bad123boy
update tedwas.employee set salary = salary * 1.5
, Отримавши у відповідь повідомлення про помилку:
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0551N "SAM" does not have the privilege to perform operation "UPDATE" on object "TEDWAS.EMPLOYEE". SQLSTATE = 42501
, Що показує, що він не має дозволу на оновлення цієї таблиці, він швидко виходить з системи сервера і йде, думаючи, що ніхто нічого не помітив.
Минає година, і ви вирішуєте перевірити вміст протоколу аудиту. Ви скидаєте буфер аудиту, щоб переконатися в тому, що всі записи аудиту, які все ще знаходяться в буфері, були записані на диск:
db2audit flush
Витягаєте записи з файлу db2audit.log в файл ASCII з роздільниками, використовуючи в якості символу роздільника полів крапку з комою, при цьому вибираєте тільки події CHECKING, що мають статус FAILURE:
db2audit extract delasc delimiter; category checking database sample status failure
Оскільки записи аудиту тепер доступні в текстовому форматі, ви вирішуєте видалити непотрібні записи з протоколу аудиту, щоб зберегти його керованим і запобігти дублювання записів:
db2audit prune date 2006020613
У вас є попередньо створені для роботи з даними аудиту таблиці DB2, і ви завантажуєте витягнуті дані з файлу checking.del в таблицю CHECKING за допомогою наступної команди:
LOAD FROM checking.del OF del MODIFIED BY CHARDEL; INSERT INTO audit.checking
Щоб уникнути використання в аналізі дублікатів записів, ви видаляєте з таблиці CHECKING рядки, значення мітки часу яких перевищує значення мітки часу, відповідної видалення зайвих записів з протоколу аудиту:
DELETE FROM audit.checking WHERE TIMESTAMP> TIMESTAMP ( '20060206130000')
Ви намагаєтеся отримати додаткову інформацію про невдалі спроби авторизації, запитуючи дані в таблиці AUDIT.CHECKING:
SELECT category, event, appid, appname, userid, authid FROM audit.checking
З результатів запиту, показаних в лістингу 5 , Ви можете бачити, що була згенерована одна запис аудиту для невдалої спроби поновлення стану.
Лістинг 5. Результат запиту таблиці CHECKING
SELECT category, event, appid, appname, userid, authid FROM audit.checking CATEGORY EVENT APPID APPNAME AUTHID ------------------------ ----- ------------------ ---------------- ------------ CHECKING CHECKING_OBJECT * LOCAL .DB2.060206220334 db2bp.exe SAM 1 record (s) selected.
Ви приймаєте рішення завершити аналіз аудиту на сьогодні і зупинити функцію аудиту за допомогою наступної команди (щоб більше не генерувалися записи аудиту):
db2audit stop
Тепер, коли ваші підозри підтвердилися, ви хочете продовжити збір доказів, щоб представити їх керівництву для вжиття заходів щодо виправлення ситуації.
Хоча цей сценарій розвитку подій дуже простий, він був написаний для того, щоб провести вас через весь процес. У цьому випадку аналіз не представляє складності. Його мета - підтвердження того, що користувач SAM намагається змінити таблиці, змінювати які він не має права. Складність аналізу в вашому власному оточенні може значно відрізнятися від описаної, в залежності від того, що ви намагаєтеся з'ясувати.
Висновок
Тепер ви можете відчувати себе в своїй тарілці при більш глибокому вивченні функції аудиту та створенні нових процесів і процедур аудиту для вашої середовища. Хоча відповідь моніторинг непередбачених подій необхідний, проактивний аудит також повинен стати важливим компонентом вашого плану забезпечення безпеки.
Ресурси для скачування
Схожі теми
- IBM DB2 Universal Database Enterprise Server Edition V8.2 для Linux, UNIX, and Windows : Завантажте ознайомчу версію з Web-сайту developerWorks;
- Створіть свій проект розробки за допомогою пробного ПО IBM , Яке можна завантажити безпосередньо з сайту developerWorks.
- " DB2 UDB security series (Статті з безпеки DB2 UDB) "(Сайт developerWorks): в цій серії статей досліджуються функції безпеки, доступні в DB2 UDB V8.2;
- Починаємо працювати з DB2 Servers Version 8.2, не відкладаючи : Документація DB2 UDB, в якій описуються варіанти установки сервера DB2 UDB;
- Інтернет-центр інформації по DB2 : Найостанніша документація по DB2 на сайті в інтернеті (з системою пошуку);
- " Understand how user and group accounts interact with DB2 UDB (Взаємодія облікових записів користувачів і груп з DB2 UDB) "(Сайт developerWorks, серпень 2005 року): додаткові відомості про облікові записи користувачів і груп, необхідних для установки і роботи з DB2 UDB;
- " Understand the DB2 Universal Database security plug-ins (Модулі безпеки універсальної бази даних DB2) "(Сайт developerWorks, грудень 2005 року): додаткові відомості про IBM DB2® підключаються модулях безпеки універсальної бази даних (DB2 UDB), нової можливості, що з'явилася у версії 8.2. У цій статті пояснюється, які функції виконують модулі, і розповідається, як написати і підключити свій модуль системи безпеки;
Підпишіть мене на повідомлення до коментарів
Jsp?