Современные информационные технологии /4. Информационная безопасность

Шмир М. А., Мелешко О. О.

Національний авіаційний університет, Україна

MongoDB: слабкі сторони типової нереляційної бази банних

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

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

Переваги використання MongoDB

1) Це документ-орієнтована БД (інакше відома як база даних NoSQL).

2) Як правило, DB NoSQL використовує XML, YAML, JSON та BSON для кодування даних. MongoDB використовує бінарний JSON (BSON).

3) Бази даних NoSQL мають свою власну термінологію, яка відрізняється від типових реляційних баз даних, таких як MSSQL та MySQL.

Таким чином, типова колекція бази даних NoSQL (таблиця) містить один або кілька "документів" (записів). Кожен документ може мати одне або кілька полів (стовпців).

Його використовують все більше і більше у виробництві гнучких програм, тобто швидко розробляють та розгортають і часто використовують у проектах типу "великі дані". Це можуть бути приклади банківських додатків та зберігання документів.

Слабкості аутентифікації

За замовчуванням БД встановлюється без пароля! Читаючи посібник користувача MongoDB, розробники MongoDB повністю переклали відповідальність за захист даних на розробників програмного забезпечення та на використання надійного середовища. На жаль, невдалий досвід незахищеної аутентифікації попередників RDBMS баз даних не був взятий до уваги.

Слабкості авторизації

Будь-який тільки-но створений користувач має права читання (“read-only”) всієї бази даних. Тобто, створивши користувача, стандартно ви отримуєте доступ до всієї інформації, що зберігається в базі даних, що не відповідає критеріям безпеки.

Слабкість авторизації адміністратора

Користувач, що має доступ до бази даних «Admin», має доступ до читання/запису всіх даних бази. Відсутнє розмежування прав. З перечисленого вище, нам відомо, що за замовчуванням пароль адміністратора – відсутній. Тому очевидно, що будь-хто отримає доступ до всієї БД.

Відкритий текст

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

Слабкість, що зумовлена підтримкою багатьох інтерфейсів

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

Відсутність шифрування

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

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

Використовуючи вище сказані дані, ось що потрібно зробити, щоб підключитись до незахищеної БД:

- Знайти хости з відкритим 27017 TCP портом.

- Перевірити, чи потрібна аутентифікація.

- Спробувати ввійти в базі «Admin» оминувши аутентифікацію.

- Переглянути список доступних БД і користуватись на здоров‘я.

З огляду на недостатню безпеку MongoDB після стандартної установки, основні методи посилення безпеки повинні включати:

- Вимкнення сторінки статусу за замовчуванням - за допомогою опції "nohttpinterface" вимкніть порт 28017.

- Використовуйте інший порт – відконфігуруйте параметр "порт".

- Не вмикайте REST на основному середовищі - не використовуйте параметр " rest".

- Прив'яжіть процес mongodb до одного інтерфейсу / IP - використовуйте 'bind_ip'.

- Не запускайте «daemon» mongodb як root-користувач.

- Вимкнути анонімний доступ - скористайтеся опцією 'auth'.

- Шифрування даних: щоб підтримати вимоги до аудиту, вам може знадобитися шифруваня даних, що зберігаються в MongoDB. Для отримання найкращих результатів ви можете шифрувати ці дані на рівні додатків, шифруючи вміст полів, які містять захищені дані.

- Шифрування зв'язку: рекомендовано для використання SSL.

- Не довіряйте безпеку бази даних розробникам програмного забезпечення.

Висновок

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

Список використаних джерел:

1. СУБД NoSQL – cильные и слабыестороны [Електроний ресурс] // JetInfo/ online : корпоративний журнал компанії «ІнфосистемиДжет» – Режим доступу: URL: http://www.jetinfo.ru/stati/silnye-i-slabye-storony-nosql

2. KarlSeguin: TheLittleMongoDBBook [Електроний ресурс] / K. Seguin // JSmanзаметки о JavaScript : електронне видання. – Режим доступу: URL: http://jsman.ru/mongo-book/

3. MongoDBSecutiryGuiderelease 3.0.7 / [MongoDBInc.] – 24.11.2015 – 136 p.

4. Users [Електроний ресурс] // MongoDBforgiantideas : офіційний сайт компанії - Режим доступу: URL: //docs.mongodb.org/manual/core/security-users/