Основното ръководство за сигурност на MongoDB

Дейвид Мърфи служи като управител на практики за MongoDB в Percona, доставчик на решения и услуги за MySQL и MongoDB от корпоративен клас.

Сигурността на MongoDB отново е в новините. Неотдавнашен поток от истории разкрива как хакери изземват базите данни на MongoDB и откупуват данните за биткойни. Десетки хиляди инсталации на MongoDB са компрометирани, според Rapid7.

Всички се тревожим за сигурността. Ако стартирате приложения, мрежи или бази данни, сигурността винаги е от първостепенно значение. С повече компании, които се обръщат към софтуер с отворен код като MongoDB, за да съхраняват важни корпоративни данни, сигурността става още по-голям въпрос. В зависимост от вашия бизнес, може да имате и няколко правителствени (например Закона за преносимост и отчетност на здравното осигуряване или HIPAA) или бизнес (Standard за защита на данните от индустрията за платежни карти или PCI DSS) регулаторни стандарти за мрежова сигурност, с които трябва да се съобразите.

Сигурен ли е софтуерът за база данни MongoDB? Отговаря ли на тези стандарти? Краткият отговор: Да, така е и да! Въпросът е просто да знаете как да настроите, конфигурирате и работите с вашата конкретна инсталация.

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

На първо място, как хората се объркват със сигурността на MongoDB? Има няколко ключови области, които отблъскват потребителите по отношение на сигурността на MongoDB:

  • Използване на портовете по подразбиране
  • Не активиране на удостоверяването веднага (най-големият проблем!)
  • Когато използвате удостоверяване, предоставяйки на всички широк достъп
  • Не се използва LDAP за принудително завъртане на парола
  • Не принуждава използването на SSL в базата данни
  • Не ограничаване на достъпа до база данни до известни мрежови устройства (хостове на приложения, балансиращи натоварване и т.н.)
  • Не ограничава коя мрежа слуша (обаче това вече не засяга поддържаните версии)

MongoDB има пет основни области на сигурност:

  • Удостоверяване. LDAP удостоверяването централизира елементите във вашата фирмена директория.
  • Разрешение. Упълномощаването дефинира какви базирани на ролята контроли за достъп предоставя базата данни.
  • Шифроване. Шифроването може да бъде разбито на At-Rest и In-Transit. Криптирането е от решаващо значение за защитата на MongoDB.
  • Одит. Одитът се отнася до възможността да се види кой какво е направил в базата данни.
  • Управление. Управление се отнася до валидиране на документи и проверка за чувствителни данни (като номер на акаунт, парола, номер на социално осигуряване или дата на раждане). Това се отнася както за знанието къде се съхраняват чувствителни данни, така и за предотвратяване на въвеждането на чувствителни данни в системата.

LDAP удостоверяване

MongoDB има вградени потребителски роли и ги изключва по подразбиране. Той обаче пропуска елементи като сложност на паролата, ротация въз основа на възрастта и централизация и идентификация на потребителските роли спрямо сервизните функции. Те са от съществено значение за приемането на разпоредби като спазването на PCI DSS. Например PCI DSS забранява използването на стари пароли и лесни за разбиване пароли и изисква промени в достъпа на потребителя при промяна на състоянието (например когато потребителят напусне отдел или компания).

За щастие LDAP може да се използва за запълване на много от тези пропуски. Много конектори позволяват използването на Windows Active Directory (AD) системи за разговори с LDAP.

Забележка: Поддръжката на LDAP е налична само в MongoDB Enterprise. Не е във версията на Общността. Той се предлага в други версии на MongoDB с отворен код, като Percona Server за MongoDB. 

MongoDB 3.2 съхранява потребителите в LDAP, но не и роли (те в момента се съхраняват на отделните машини). MongoDB 3.4 Enterprise трябва да въведе възможността за съхраняване на роли в LDAP за централизиран достъп. (Ще обсъдим ролите по-късно.)

Перкона

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

LDAP в Монго всъщност е лесен. MongoDB има специална команда, за да го кажа, за да се провери външна база данни LDAP: $external.

Някои други предупреждения за използване на LDAP:

  • Създайте потребител с, .createUserкакто обикновено, но не забравяйте да използвате db / collection таг ресурси.
  • Освен това LDAP удостоверяването изисква още две полета:
    • механизъм: „РАВЕН“
    • digestPassword: невярно

Персонализирани роли

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

Петте основни вградени роли на MongoDB, които трябва да знаете:

  • read:
    • Достъп само за четене, обикновено се дава на повечето потребители
  • readWrite:
    • readWrite достъпът позволява редактиране на данни
    • readWrite включва четене
  • dbOwner:
    • Включва readWrite, dbAdmin, userAdmin(за базата данни). userAdminозначава добавяне или премахване на потребители, предоставяне на привилегии на потребителите и създаване на роли. Тези права се присвояват само на конкретния сървър на база данни.
  • dbAdminAnyDatabase:
    • Създава dbAdminвъв всички бази данни, но не позволява администриране на потребители (например за създаване или премахване на потребители). Можете да създавате индекси, уплътнения на обаждания и др. Това не осигурява достъп за рязане.
  • root:
    • Това е суперпотребител, но с ограничения
    • Може да прави повечето неща, но не всички:
      • Не може да се промени системната колекция
      • Някои команди все още не са достъпни за тази роля, в зависимост от версията. Например основната роля на MongoDB 3.2 не ви позволява да променяте размера на оплога или профила, а основната роля на MongoDB 3.4 не ви позволява да четете текущите изгледи.

Бази данни и колекции с заместващи символи

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

Това е опасно.

Когато използвате заместващи символи, предоставяте много специални привилегии и трябва да знаете, че отваряте възможни пътища за атака:

  • readWriteAnyDatabaseе изключително широк и излага потребителски имена и роли на потенциална атака чрез потребителя на приложението
  • Използването на заместващи символи означава, че няма да ограничите конкретни приложения до конкретни бази данни
  • Уайлдкардингът ви пречи да използвате мултитенанс с множество бази данни
  • Новите бази данни не получават автоматично достъп

Създаване на персонализирана роля

Силата на ролите на MongoDB идва от създаването на персонализирани роли. В персонализирана роля можете да посочите, че всяко действие върху който и да е ресурс може да бъде посочено за конкретен потребител. С това ниво на детайлност можете дълбоко да контролирате кой какво може да прави във вашата среда на MongoDB.

Що се отнася до определянето на персонализирана роля, има четири различни типа ресурси:

  • db. Посочва база данни. Можете да използвате низ за име или „“ за „всеки“ (без заместващи символи).
  • collection. Посочва колекция от документи. Можете да използвате низ за име или „“ за „всеки“ (без заместващи символи).
  • cluster. Указва остър клъстер или други ресурси с метаданни. Това е булева стойност на true / false.
  • anyResource. Посочва достъп до всичко, навсякъде. Това е булева стойност на true / false.

Всяка роля може да наследи свойствата на друга роля. Има масив, наречен „роли“, и можете да пуснете нова роля в масива. Той ще наследи свойствата на посочената роля.

Използвайте createRoleза добавяне на роля към масива.

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

Използвайте grantPrivilegesToRoleкомандата, за да добавите нови ресурси към съществуваща роля.

По-долу е даден пример за създаване на нова супер потребителска роля. Целта на тази роля отново е да има един потребител, който по никакъв начин не е ограничен в средата MongoDB (за извънредни ситуации).

db = db.geSiblingDB(“admin”);

db.createRole({     

     role: “superRoot”,     

     privileges:[{          

          resource: {anyResource:true},          

          actions: [‘anyAction’]     

     }]     

     roles:[]

});

db.createUser({     

     user: “comanyDBA”,     

     pwd: “EWqeeFpUt9*8zq”,     

     roles: [“superRoot”]

})

Тези команди създават нова роля в базата данни, geSiblingDBнаречена superRootи присвояват тази роля на всеки ресурс и всяко действие. След това създаваме нов потребител в същата база данни, наречена companyDBA(с парола), и му присвояваме новата superRootроля.

Използване на SSL за всички неща

SSL помага да се гарантира сигурността на вашите данни през незащитени мрежи. Ако използвате база данни, която взаимодейства с интернет, трябва да използвате SSL.

Има две много добри причини да се използва SSL за защита на MongoDB: поверителност и удостоверяване. Без SSL данните ви могат да бъдат достъпни, копирани и използвани за незаконни или вредни цели. С удостоверяването имате второстепенно ниво на безопасност. Инфраструктурата на частния ключ на SSL (PKI) гарантира, че само потребители с правилния CA сертификат имат достъп до MongoDB.

MongoDB има SSL поддръжка за дълго време, но значително подобри SSL поддръжката през последните няколко версии. Преди това, ако искате да използвате SSL, трябваше да го изтеглите и да го компилирате ръчно с версията на MongoDB Community. От MongoDB 3.0 SSL се компилира със софтуера по подразбиране. 

В старите версии на MongoDB също липсва валидна проверка на хоста; Удостоверяването на хоста беше просто флаг, който можете да проверите в конфигурационния файл, който удовлетворява SSL заявка от връзка.

Най-новите версии на SSL в MongoDB включват следните ключови характеристики:

  • Проверки за валидни хостове (по избор)
  • Възможност за посочване на конкретен .key файл за настройка, който да се използва
  • Персонализиран сертифициращ орган (CA) за самоподписани сертификати или алтернативни подписващи
  • allowSSL, preferSSL, requireSSLРежими, които ви позволяват да изберете детайлност за вашия SSL употреба (от по-малко сигурен за по-сигурно)

SSL: Използване на персонализиран CA

По-новите версии на SSL в MongoDB ви позволяват да използвате персонализиран CA. Въпреки че това ви дава гъвкавост при определяне на начина, по който искате да работите със SSL, той идва с предупреждения. Ако просто се опитвате да защитите връзката, може да се изкушите да изберете sslAllowInvalidCertficates. Това обаче обикновено е лоша идея поради няколко причини:

  • Позволява всяка връзка от изтекла до отменени сертификати
  • Не гарантирате ограничения за конкретно име на хост
  • Не сте почти толкова сигурни, колкото си мислите

За да поправите това, просто задайте net.ssl.CAFileи MongoDB ще използва както ключа, така и CA файла (трябва да направите това на клиента).

Използването на SSL обаче има известен недостатък: производителност. Със сигурност ще загубите малко производителност, когато използвате SSL.

Шифроване на диска

Данните са „в процес на предаване“ или „в покой“. Можете да шифровате едното или и двете в MongoDB. Обсъдихме криптиране на данни при транспортиране (SSL). Сега нека разгледаме данните в покой.

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

Това не е проблем, уникален за MongoDB. Превантивните мерки, използвани в други системи, работят и тук. Те могат да включват инструменти за криптиране като LUKS и cryptfs или дори по-сигурни методи като подписване на ключове за криптиране с LDAP, смарт карти и RSA тип жетони.

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

Криптирането на данни в покой може да бъде решено с някое или всички от следните:

  • Шифровайте целия том
  • Шифровайте само файловете на базата данни
  • Шифроване в приложението

Първият елемент може да бъде решен с дисково криптиране на файловата система. Лесно е да се настрои с помощта на LUKS и dm-crypt. За спазване на PCI DSS и други изисквания за сертифициране се изискват само първата и втората опции.

Одит

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

Одитът ви позволява да проследите напълно действията на нарушител във вашата среда.

Забележка: Одитът е достъпен само в MongoDB Enterprise. Не е във версията на Общността. Той се предлага в някои други версии на MongoDB с отворен код, като Percona Server за MongoDB.