|
|
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
Всем привет! Есть задача: отслеживать действия пользователей, которые работают через приложение. Действия - это изменение, добавление, удаление. Возможно, в будущем ещё понадобится отлавливать ещё и просмотр объектов. Ещё нужно писать сеансы: какие пользователи в какое время в приложение заходили, и когда выходили. Администратор приложения должен иметь возможность просматривать всю записанную инфу в приложении. Вопросы: 1. Правильно ли я понимаю, что изменение, добавление, удаление вполне можно отслеживать, добавляя триггеры на таблицы, а затем записывать интересующие меня действия в какую-нибудь общую таблицу типа AUDIT (с указанием таблицы, столбца, id объекта, старого и нового значения, типа операции, пользователя, даты и времени действия)? 2. Будет ли хорошей идеей добавить в таблицу AUDIT ещё и некий GROUP_ID, чтобы потом было проще понять, какие операции были совершены одновременно? (например, если пользователь отредактировал 1 объект, изменив в нём несколько полей) 3. Какие вообще есть очевидные минусы при использовании триггеров и сваливании всех действий по всем таблицам в единую таблицу AUDIT? (в использовании отдельных таблиц а-ля TABLE_NAME_HISTORY отталкивает удвоение размера БД). 4. Правильно ли я понимаю, что никак нельзя отследить действие "просмотр объекта" при помощи триггеров и придётся использовать FGA? 5. Если отслеживание просмотров доступно только через FGA, насколько оправдано пользоваться и FGA, и триггерами одновременно? 6. Как отловить входы / выходы, чтобы потом вывести эту инфу в интерфейс администратору? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2017, 17:33 |
|
||
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
В общем случае (вернее в бoльшинстве случаев) нeправильно. Oтслеживать действия пользователей, которые работают через приложение нужно только в приложeнии. Пользователь прилoжения != пользователь базы. В большинстве случаев используется middle-tier, так-что даже информация с какого сервeра и каким OS пользователем открыта сессия ничего не дает, тем более что в большинстве случаев используется connection pooling. Так-что без пердачи приложeнием информации о пользователе приложeния отслеживать действия пользователей на уровне базы не получится да и смысла нет - ведь не все действия пользователей в приложeнии это действия в базе а уж если oтслеживать действия пользователей то все и хранить в единой repository. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2017, 20:46 |
|
||
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
ДжунВопросы: 1. Правильно ли я понимаю, что изменение, добавление, удаление вполне можно отслеживать, добавляя триггеры на таблицы, а затем записывать интересующие меня действия в какую-нибудь общую таблицу типа AUDIT (с указанием таблицы, столбца, id объекта, старого и нового значения, типа операции, пользователя, даты и времени действия)? 2. Будет ли хорошей идеей добавить в таблицу AUDIT ещё и некий GROUP_ID, чтобы потом было проще понять, какие операции были совершены одновременно? (например, если пользователь отредактировал 1 объект, изменив в нём несколько полей) 3. Какие вообще есть очевидные минусы при использовании триггеров и сваливании всех действий по всем таблицам в единую таблицу AUDIT? (в использовании отдельных таблиц а-ля TABLE_NAME_HISTORY отталкивает удвоение размера БД). 4. Правильно ли я понимаю, что никак нельзя отследить действие "просмотр объекта" при помощи триггеров и придётся использовать FGA? 5. Если отслеживание просмотров доступно только через FGA, насколько оправдано пользоваться и FGA, и триггерами одновременно? 6. Как отловить входы / выходы, чтобы потом вывести эту инфу в интерфейс администратору? Я не говорю, что Unified Auditing удовлетворит всем требованиям задачи, т.к. тут не раскрыты многие детали, но посмотрите в его сторону. По умолчанию, он буферизует записи в SGA, что плодотворно скажется на производительности. Политики unified auditing поддерживают условия их срабатывания, т.е. их можно сформировать гибко под конкретную задачу. Узким местом может стать большой поток записей через unified audit, но можно попробовать его ограничить через условия срабатывания (например, какая-то процедура выполняющая миллион update-ов - нужно ли это видеть в аудите - зависит от конкретных требований). Во вложении небольшой пример, когда политика unified auditing выполняется только для сессий определенного сервиса, с которым работает приложение. session1 dba session step1 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. session2 app_session в выводе видем нашего пользователя и ECID. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. session1 dba session step2 В выводе видим пользователя и ECID. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. По отдельным пунктам: ДжунВопросы: 2. Будет ли хорошей идеей добавить в таблицу AUDIT ещё и некий GROUP_ID, чтобы потом было проще понять, какие операции были совершены одновременно? (например, если пользователь отредактировал 1 объект, изменив в нём несколько полей) unified_audit_trail.transaction_id/ecid Джун4. Правильно ли я понимаю, что никак нельзя отследить действие "просмотр объекта" при помощи триггеров и придётся использовать FGA? Unified Auditing позволяет отслеживать "просмотр объекта", если мы имеем в виду под этим одно и то же. Джун6. Как отловить входы / выходы, чтобы потом вывести эту инфу в интерфейс администратору? unified_audit_trail.action_name=LOGON/LOGOFF%. SYOтслеживать действия пользователей, которые работают через приложение нужно только в приложeнии. Пользователь прилoжения != пользователь базы. Не только лишь в приложении. Допустим, middle-tier вызывает высокоуровневое API - PL/SQL процедуру, которая меняет множество всего в БД. Самого факт вызова PL/SQL процедуры и ее параметров - может оказаться не достаточно. middle-tier не знает ничего о том, чего эта процедура в БД наменяла и к каким данным обращалась (а если захочет знать, то это не всегда дешево предоставить). Поэтому само утверждение о том "что только в приложении" - не везде применимо. Логи приложения к дополнениям логи БД - это то, что нужно на тех проектах, где я работаю. Естественно, все лучше централизовать, например, через тот же ELK стэк, чтобы иметь все нужные данные в одном месте, а ECID использовать в качестве сквозного идентификатора - он генерится приложением, о нем знает приложение, о нем знает БД, и при необходимости он пробрасывается в иные системы (например, middle-tier зовет БД, БД зовет внешнюю систему или другую БД и т.д.). На практике, middle-tier может звать тучу БД в рамках XA-транзакции в рамках одного ECID, по которому, например, затем в ELK специально обученные пользователи смотрят, что происходило в рамках одного клиентского запроса в разных ИС. SYТак-что без пердачи приложeнием информации о пользователе приложeния отслеживать действия пользователей на уровне базы не получится да и смысла нет - ведь не все действия пользователей в приложeнии это действия в базе а уж если oтслеживать действия пользователей то все и хранить в единой repository. На уровне стандартов разработки вводится требование, что любые приложения при работе с БД используют: service, module, action, client_id, ecid. DBOP еще не введен, но я пока в нем не вижу большого смысла. JDBC все указанные поля передает на уровне одного SQL*Net пакета при выполнении следующего вызова в БД, т.е. нет дополнительных накладных расходов на поддержание инструментирования. Естественно, периодически возникают задачи по подключению к БД новых сторонних приложений, написанных набранными по объявлениям студентами, не знающими, что такое инструментирование. Они либо садятся на существующие/новые сервисы, или модифицируют свой код в соответствии с общепринятыми стандартами того проекта, где я работаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 07:09 |
|
||
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
SeaGateЯ не говорю, что Unified Auditing удовлетворит всем требованиям задачи, т.к. тут не раскрыты многие детали, но посмотрите в его сторону. Спасибо! А можно через него отследить именно вставку, удаление, изменение или всё равно нужно будет триггеры на таблицы прикручивать? И он как-то отдельно лицензируется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2017, 13:09 |
|
||
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
Джун, ДжунСпасибо! А можно через него отследить именно вставку, удаление, изменение или всё равно нужно будет триггеры на таблицы прикручивать? И он как-то отдельно лицензируется? В своем примере я привел аудит: insert update из процедуры По лицензированию, я не вижу, что он в Feature Availability by Edition в Licensing Manual указан. Насколько я знаю, он бесплатен, т.к.: его можно использовать со Standard Edition: Unable to Set Unified Auditing in Oracle Database Standard Edition (Doc ID 2021411.1) , а отдельные опции применимы только к EE: Database Licensing Information User Manual 2 Options and PacksAll the Oracle Database options can be purchased with Oracle Database Enterprise Edition. Oracle Real Application Clusters (Oracle RAC) is included with Oracle Database Standard Edition. You cannot purchase any options with Oracle Database Standard Edition One or Oracle Express Edition. The Personal Edition includes all options except Oracle RAC at no additional cost. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 04:07 |
|
||
|
Аудит действий пользователей FGA vs триггеры
|
|||
|---|---|---|---|
|
#18+
ДжунА можно через него отследить именно вставку, удаление, изменение или всё равно нужно будет триггеры на таблицы прикручивать? Зачем это нужно при аудите приложения? Пользователь приложения может выполнять только те функции которые доступны в приложении. Если пользователь создал, например, invoice то аудит и дoлжен содержать запись Вася Пупкин в такое-то время создал invoice на $100 за ремонт унитаза тете Соне. Какая разница в какие таблицы что пихалось? Тем более что вставку, удаление, изменение делал не Вася Пупкин а само приложение. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2017, 05:29 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39389982&tid=1886596]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
69ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
26ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 356ms |

| 0 / 0 |
