Нива на несигурност на MongoDB и как да ги избегнем

Повечето системи за управление на бази данни имат няколко техники за защита на своите данни от външен човек или неупълномощено лице или приложение. Техниките предотвратяват четенето или копирането на вашите данни без разрешението на потребителя.

MongoDB не е по-различен, тъй като има някои нива на несигурност. В тази публикация в блога ще обсъдим нивата на несигурност в MongoDB и как да ги избегнете, за да можете да защитите инсталацията на MongoDB.

За безопасността и сигурността на вашия MongoDB, по-долу са някои от основните мерки за сигурност, които трябва да вземете стриктно:

Удостоверяване на потребителски връзки.
Упълномощаване/ Контрол на достъпа, базиран на роли.
Мрежово шифроване/транспортно шифроване.
Шифроване на съхранение/ Шифроване в покой.
Одит.

В тази статия ще разгледаме подробно горните мерки за сигурност, като се фокусираме много върху удостоверяването и упълномощаването.

Удостоверяване и упълномощаване

Удостоверяването и упълномощаването трябва да бъдат активирани в унисон. Те обаче могат да се използват независимо един от друг. Удостоверяването не позволява на достъпа до неизвестно лице, което има мрежов достъп до сървъра на базата данни, да копира или повреди данните на базата данни. Удостоверяването изисква всички клиенти и сървъри да предоставят валидни идентификационни данни, преди да могат да се свържат със системата. Упълномощаването, от друга страна, не позволява на приложение или потребител да чете, променя или изтрива данни, различни от това, което е трябвало.

За да конфигурирате контрол на достъп, базиран на роли;

Първо създайте потребителски администратор.
Създайте допълнителни потребители.
След това създайте уникален потребител на MongoDB за всяко лице/приложение, което има достъп до системата.
Следвайки принципа на най-малко привилегии, трябва да създадете роли, които дефинират точните права за достъп, необходими за даден набор от потребители.
След това задайте на потребителите само ролите, които трябва да изпълняват в своите операции. Потребител може да бъде клиентско приложение или човек.

Трябва да отбележите, че потребителят може да има привилегии в различни или множество бази данни. В този сценарий, вместо да създавате потребител няколко пъти в различни бази данни, създайте един потребител с роли, които предоставят приложими привилегии на база данни.

По-често, отколкото не, тези две мерки за сигурност може да бъдат объркани, за да означават едно и също нещо. В някои сценарии те са подобни един на друг, но също така са различни.

Прилики между удостоверяване и упълномощаване

И двете са донякъде едно цяло, защото, когато активирате удостоверяване, упълномощаването се активира автоматично. Упълномощаването е разрешено в унисон с удостоверяването, следователно връзките от неизвестни потребители няма да имат привилегия за достъп до данни от базата данни. Упълномощаването също изисква потребителското име да бъде проверено чрез удостоверяване, за да се знае кои привилегии се прилагат към заявките за връзка. Следователно, тя не може да бъде активирана независимо от другата.
И двамата също са сходни по жалко, наследено именуване на опциите за конфигурация. Опцията за конфигурационен файл за удостоверяване е security.authorization вместо удостоверяване на сигурността, както се очаква. Когато използвате командата обаче, удостоверяването е първото, което се активира, а упълномощаването е разрешено само като последващ ефект. „-auth“ е аргументът на командния ред за активиране на удостоверяването, което автоматично принуждава и упълномощаването.

Разлики между удостоверяване и упълномощаване

Тези двете са различни, защото са две части на софтуера, които имат различни функции.

Удостоверяване ==Потребителска идентичност, чрез проверка на идентификационни данни.

Упълномощаване ==Присвояване и налагане на DB обекти и DB командни разрешения.

По време на първоначалната настройка удостоверяването е деактивирано за връзки с локален хост. Това е кратко, но тъй като получавате една възможност да създадете първия потребител, тогава привилегията за изключение (от правилото за удостоверяване и упълномощаване при заедно) отпада.

Как да проверите дали удостоверяването и упълномощаването са активирани или не

Първите версии на MongoDB имаха „- auth“ изключен по подразбиране и това се счита за лош ход. Дори във версия 4.0 той все още беше изключен по подразбиране. Празната конфигурация все още се равнява на изключване на упълномощаването, въпреки че има предупреждения при стартиране и различни намаления на експозицията , като например localhost да стане единственото мрежово устройство, свързано по подразбиране в MongoDB v3.6.

Не използвате удостоверяване или по-скоро нямате активирано удостоверяване, ако конфигурационните файлове на mongod не го правят:

Настройте security.authorization на „разрешено“.
Включете файл security.key.
Включете настройка security.clusterAuthMode, която принуждава да бъде включено удостоверяването.

За да проверите отново дали сте активирали удостоверяване и упълномощаване или не, можете да опитате тази бърза едноредова обвивка mongo (без зададени аргументи за потребителски идентификационни данни):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

Отговорът, който трябва да получите, е „неоторизирана“ грешка. Но, от друга страна, ако получите списък с имена на бази данни, това автоматично означава, че имате голо внедряване на MongoDB.

Външно удостоверяване

Както подсказва името, външното удостоверяване е да позволи на потребителите да бъдат удостоверявани във външна услуга. Като изключение, той не може да се използва за вътрешен потребител на системата mongodb __, но използването му за всеки реален потребител човек или акаунт за обслужване на клиентско приложение е напълно подходящ.

Просто външната услуга за удостоверяване ще бъде Kerberos KDC или ActiveDirectory или OpenLDAP сървър. Трябва да отбележите, че използването на външно удостоверяване не ви пречи да имате обикновени потребителски акаунти на MongoDB едновременно.

Вътрешно удостоверяване

Напротив, вътрешното удостоверяване на MongoDB не означава обратното на външното удостоверяване. Това е така, защото възел mongod, работещ с активирано удостоверяване, няма да вярва, че който и да е TCP партньор е друг, е друг mongod или mongos възел, само защото комуникира като такъв. По-скоро изисква партньорът да се удостовери чрез доказателство за споделена тайна.

Има два типа вътрешни механизми за удостоверяване в MongoDB:

Вътрешно удостоверяване на ключов файл.
Вътрешно удостоверяване на SCRAM или x.509.

Вътрешно удостоверяване на ключов файл

Това е вътрешният механизъм за удостоверяване по подразбиране в MongoDB. Терминът „Ключ“ означава асиметричен ключ за криптиране, но в реалния смисъл това е просто парола, независимо как сте я генерирали. Ключовият файл се записва в идентичен файл, разпределен на всеки възел mongod и mongos в клъстера. В сценария паролата се използва успешно, възел mongod ще позволи на командите, идващи от удостоверения партньор, да се изпълняват като суперпотребител на „_ _ system“.

Ако някой има копие на ключовия файл, той може просто да премахне контролните и непечатащите знаци от ключовия файл, за да направи низа с парола, който ще му позволи да се свърже като потребител на „_ _ системата“.

Въпреки това, ако това се случи и изпълните командата по-долу като потребител на mongod (или root) на един от вашите MongoDB сървъри и успеете, не трябва да се притеснявате, тъй като няма да има случайно изтичане на привилегия за четене . Това е така, защото mongod ще прекъсне при стартиране, ако ключовият файл е в нещо различно от 400 (или 600) режим на разрешения за файлове.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Въпреки това, случайното запазване на ключовия файл във вашия контрол на източника, който може да се чете от цял свят, може да позволи на потребители, които не са администратори на база данни (или администратори на сървъра с root), да прочетат копие на ключовия файл. Това се счита за грешка в сигурността.

Екстремният риск се увеличава, когато ключовият файл се разпространява с притежавани mongos възли и се изпълнява като един от потребителите на unix на екипа на приложението вместо „mongod“ или друг потребител на unix, притежаван от DBA екип.

SCRAM или x.509 вътрешно удостоверяване

Механизмът за вътрешно удостоверяване x.509 всъщност използва асиметрични частни или публични ключове и трябва да се използва в съюз с TLS/SSL. Този механизъм може да се използва за клиентски връзки, както и вътрешно удостоверяване.

Механизмът x.509 или SCRAM има предимство пред механизма Keyfile, тъй като в механизма x.509 е по-малко вероятно един от ключовете, внедрени с възли mongod и mongos, да бъде злоупотребен от натрапник, който получава копие от него. Това обаче зависи от това колко стриктно са настроени сертификатите x.509. За да се насладите на максимална сигурност от този механизъм, трябва да имате специален екип за сигурност, който разбира концепциите и най-добрите практики на x.509. Тези най-добри практики включват затягане на кои хостове ще работи и възможност за отмяна и прехвърляне на сертификати.

Мрежово шифроване/ Транспортно шифроване

Мрежовото криптиране не позволява на някого да копира данните, които се прехвърлят през мрежова връзка някъде между два сървъра. Мрежовото криптиране изисква малко или никакво мислене, когато става въпрос за решение дали да го използвате, тъй като е от решаващо значение. Но ако например вашият MongoDB клъстер и всички негови клиенти са във виртуална частна мрежа, за която смятате, че няма дупки в защитната стена и няма риск от ескалация на привилегиите от други приложения, тогава нямате нужда от мрежово криптиране.

За мрежово криптиране трябва да конфигурирате MongoDB да използва TLS/SSL за всички изходящи и входящи връзки. Шифровайте комуникацията между mongod и mongos компоненти на внедряване на MOngoDB, както и между всички приложения и MongoDB, използвайки TLS/SSL.

Започвайки от версия 4.0; MongoDB деактивира поддръжката за TLS 1.0 криптиране на системи, където е наличен TLS 1.1+ и също така използва следните собствени TLS/SSL библиотеки:

Windows – защитен канал (Schannel).
Linux/BSD - OpenSSL.
macOS – Сигурен транспорт.

Ограничете излагането на мрежата

Трябва да се уверите, че MongoDB работи в надеждна мрежова среда и също така да конфигурирате защитна стена или групи за сигурност, за да контролирате входящия и изходящия трафик за вашите екземпляри на MongoDB. Нещо повече, конфигурирайте да позволявате на доверени клиенти само достъп до мрежовите интерфейси и портове, на които са налични екземпляри на MongoDB. Например, използвайте белия списък за IP адреси, за да разрешите достъп от доверени IP адреси.

Изпълнете MongoDB със защитени опции за конфигуриране

MongoDB поддържа изпълняващия JavaScript код за следните операции от страна на сървъра:

mapReduce.
$where.
$accumulator.
$функция.

Използвайте опцията -- noscripting в командния ред, за да деактивирате скриптовете от страна на сървъра, ако не използвате горните операции. Поддържайте валидирането на входа активирано, въпреки че MongoDB активира проверка на входа по подразбиране чрез настройката net.wireObjectCheck. Това гарантира, че всички документи, съхранявани от mongod intsance, са валидни BSON.

Шифроване на MongoDB Storage/ Encryption-at-rest

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

Започвайки с MongoDB Enterprise 3.2, можете да шифровате данни в слоя за съхранение с родния Encryption-at-rest на механизма за съхранение на WiredTiger. Данните на MongoDB трябва да бъдат криптирани на всеки хост с помощта на файлова система, устройство или физическо криптиране, когато не се използва криптирането в състояние на покой на WiredTiger. Също така, трябва да събирате регистрационни файлове в централно хранилище за дневници, тъй като тези регистрационни файлове съдържат опити за удостоверяване на DB, включително IP адрес на източника. Криптирането на съхранение обаче има леки разходи за производителност.

Одит

Одитът помага при проследяване на потребител на база данни, който знае как да прикрие следите си след промяна или промяна на данните от базата данни. По принцип одитът проследява достъпа и промените в конфигурациите и данните на базата данни. MongoDB Enterprise има средство за одитиране на системата, което може да записва системни събития, като потребителски операции и събития за свързване на екземпляр на MongoDB.

Тези одитни записи помагат при криминалистичния анализ и позволяват на администраторите да проверят правилните контроли. Одитът е от голяма стойност за някои потребители, но може да бъде такъв само когато някои други рискове бъдат елиминирани. Например, нападателят не може да получи root достъп на Unix на сървърите, докато изпълнява живите възли mongod.

Преместване напред

Можете да настроите филтри за записване на конкретни събития като събития за удостоверяване. Но бъдете внимателни, защото когато филтрите за одит са направени твърде широки, тяхната производителност бързо ще се задави, което ще доведе до високи разходи за производителност. Въпреки че, ако одитът се използва по подходящ начин, няма да има големи разходи за производителност.