Загрози безпеці сховищ даних

Список основних вразливостей сховищ даних актуальний не тільки для реляційних БД, але і для рішень NoSQL. За підсумками 2015 року визначено десять найважливіших загроз безпеки баз та сховищ даних [14]: надмірні і невикористовувані привілеї, призначені для користувача; зловживання привілеями; mputін'єкції (ін'єкції в полі вводу); хакерські програми; недостатні заходи з аудиту даних; незахищеність носіїв інформації; експлуатація вразливих та неправильно сконфігурованих БД; некерована конфіденційна інформація; відмова в обслуговуванні (DoS); брак знань і досвіду в сфері ІБ.

Можна визначити два основних способи злому БД за допомогою ін'єкцій коду:

• 1) SQL-ін'єкції, застосовувані для злому реляційних СУБД.
• 2) NoSQL-ін'єкції, які використовуються для злому платформ Big Data. NoSQL-ін'єкції зазвичай є впровадженням недозволеного або шкідливого коду в поля введення веб-додатків, компонент MapReduce, Hive. Реалізуються шляхом [15]:
  • · використання регулярних виразів в параметрах запиту;
  • · отримання доступу до даних через спеціальний інтерфейс, який підтримується NoSQL (наприклад, MongoDB використовує як мову запитів BSON, eXist застосовує XQuery, а Sonic GraphDB — GraphQL, тому для MongoDB можна реалізувати JSON-ін'єкції і т. д.);
  • · маніпулювання з REST-інтерфейсом (Representational state transfer) і підробки міжсайтових запитів (CSRF);
  • · виконання скриптів на сервері, на якому встановлена NoSQL (наприклад, MongoDB дозволяє запускати JavaScript-код, тому можливе виконання JavaScript-ін'єкції).

В обох випадках успішно проведена ін'єкція може дати необмежений доступ до вмісту БД. Незважаючи на те, що технічно NoSQL є невразливими для SQL-ін'єкцій тому, що в них не застосовується мова SQL, вони відкриті для атак, які організовані за аналогічними принципами.

Одним із джерел вразливостей даних є недосконала реалізація розмежування доступу до них. Існує ймовірність використання користувачами (додатками) своїх легітимних прав доступу в протиправних цілях або зловживання привілеями, обсяги яких перевищують необхідні для виконання посадових (функціональних) обов’язків. Як і будь-який додаток, NoSQL DBMS та RDBMS можуть піддаватися атакам переповнення буфера або мати вразливу схему автентифікації.

Атакувати рівень СУБД досить складно, тому що користувачі і компаніярозробник намагаються виправляти помилки по мірі їх виявлення. Крім того, більшість програмних продуктів NoSQL поставляються з відкритим кодом, а значить, його можна проаналізувати. Більшість СУБД мають велику кількість різних бібліотек (клієнтське API) для доступу до даних. Ймовірність виявити вразливість в клієнтській бібліотеці є значно більшою, ніж безпосередньо в самій СУБД. При цьому можна не тільки знайти вразливість, яка відкриє доступ до всіх програм, побудованих на основі цього API, але зрозуміти, як саме відбувається діалог між клієнтським кодом і сервером баз даних та який використовується протокол. На рівні додатку для пошуку вразливостей зломщики шукають ті місця, де програміст забув перевірити вхідні дані, і намагаються їх використовувати. У такому випадку для боротьби використовується той же підхід, що і при пошуку SQL-ін'єкцій, тобто аналізується код і повідомлення про помилки з використанням мов додатків, наприклад, JSON, JavaScript тощо.

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

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

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

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

Розвиток засобів внутрішньої безпеки не встигає за зростанням обсягів даних, при цьому багато організацій недостатньо оснащені і підготовлені для протидії загрозам. Причинами цього є як недостатня інформованість або увага адміністраторів СУБД і прикладних програмістів, так і відсутність вбудованих засобів контролю відомих вразливостей в більшості СУБД. Хорошим рішенням були б автоматизація і перенесення контролю таких загроз на рівень сервера, однак різноманіття мов і мовних діалектів не дозволяє це зробити [12].