Úrovně nejistoty MongoDB a jak se jim vyhnout

Většina systémů pro správu databází má několik technik zabezpečení dat před cizí osobou nebo neoprávněnou osobou nebo aplikací. Tyto techniky zabraňují čtení nebo kopírování vašich dat bez svolení uživatele.

MongoDB se nijak neliší, protože má určité úrovně zabezpečení. V tomto blogovém příspěvku budeme diskutovat o úrovních zabezpečení v MongoDB a o tom, jak se jim vyhnout, abyste mohli chránit svou instalaci MongoDB.

Pro bezpečnost a zabezpečení vašeho MongoDB jsou některá z hlavních bezpečnostních opatření, která je třeba přísně zvážit:

Ověřování uživatelských připojení.
Oprávnění/Řízení přístupu na základě rolí.
Síťové šifrování / Transportní šifrování.
Šifrování úložiště/šifrování v klidu.
Audit.

V tomto článku se podrobně podíváme na výše uvedená bezpečnostní opatření s velkým důrazem na Autentizaci a Autorizaci.

Ověření a autorizace

Autentizace a autorizace musí být aktivovány současně. Lze je však používat nezávisle na sobě. Autentizace zabraňuje v přístupu neznámé osobě, která má síťový přístup k databázovému serveru, zkopírovat nebo poškodit data databáze. Autentizace vyžaduje, aby všichni klienti a servery poskytli platná pověření, než se budou moci připojit k systému. Autorizace na druhé straně zabraňuje aplikaci nebo uživateli číst, měnit nebo mazat data jinak, než jaká měla.

Konfigurace řízení přístupu na základě rolí;

Nejprve vytvořte správce uživatelů.
Vytvořte další uživatele.
Potom vytvořte jedinečného uživatele MongoDB pro každou osobu/aplikaci, která přistupuje do systému.
Podle zásady nejmenšího privilegia byste měli vytvořit role, které definují přesná přístupová práva potřebná pro sadu uživatelů.
Poté přiřaďte uživatelům pouze role, které potřebují ke svým operacím. Uživatelem může být klientská aplikace nebo osoba.

Měli byste si uvědomit, že uživatel může mít oprávnění pro různé nebo více databází. V tomto scénáři namísto vytváření uživatele vícekrát v různých databázích vytvořte jednoho uživatele s rolemi, které udělují příslušná databázová oprávnění.

Častěji mohou být tato dvě bezpečnostní opatření zaměněna a znamenají totéž. V některých scénářích jsou si navzájem podobné, ale také se liší.

Podobnosti mezi ověřováním a autorizací

Oba jsou do jisté míry jedinou jednotkou, protože když povolíte ověřování, automaticky se povolí i autorizace. Autorizace je povolena současně s autentizací, takže připojení od neznámých uživatelů nebudou mít oprávnění pro přístup k databázovým datům. Autorizace také vyžaduje ověření uživatelského jména pomocí Authentication, aby bylo možné zjistit, jaká oprávnění se vztahují na požadavky připojení. Nelze jej tedy aktivovat nezávisle na druhém.
Oba jsou si také podobné v nešťastném, zastaralém pojmenování možností konfigurace. Volba konfiguračního souboru pro autentizaci je security.authorization namísto bezpečnostní autentizace, jak by se očekávalo. Když však příkaz použijete, Autentizace je povolena jako první a Autorizace je povolena až jako následný efekt. „-auth“ je argument příkazového řádku pro povolení autentizace, která automaticky vynutí, aby byla také zapnuta autorizace.

Rozdíly mezi autentizací a autorizací

Tyto dva se liší, protože se jedná o dvě části softwaru, které mají různé funkce.

Autentizace ==Identita uživatele pomocí kontroly pověření.

Autorizace ==Přidělování a vynucování oprávnění k objektům DB a příkazům DB.

Během počátečního nastavení je pro připojení localhost zakázáno ověřování. To je však stručné, protože dostanete jednu příležitost vytvořit prvního uživatele, pak je výsada výjimky (z pravidla Ověřování a autorizace společně) zrušena.

Jak zkontrolovat, zda je autentizace a autorizace povolena či nikoli

První verze MongoDB měly ve výchozím nastavení nastaveno „- auth“, což je obecně považováno za špatný krok. Dokonce i ve verzi 4.0 byla ve výchozím nastavení stále vypnutá. Prázdná konfigurace se stále rovná autorizaci, která je vypnutá, přestože má varování při spuštění a různá omezení vystavení, jako je například localhost, který se stal jediným výchozím síťovým zařízením v MongoDB v3.6.

Nepoužíváte ověřování nebo spíše nemáte povoleno ověřování, pokud konfigurační soubory mongodu ne:

Mějte security.authorization nastavenou na hodnotu ‘enabled’.
Zahrňte soubor security.key.
Zahrňte nastavení security.clusterAuthMode, které vynutí zapnutí ověřování.

Chcete-li znovu zkontrolovat, zda máte povolenou autentizaci a autorizaci či nikoli, můžete vyzkoušet tento rychlý mongo shell one-liner (bez nastavených argumentů uživatelských pověření):

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

Odpověď, kterou byste měli obdržet, je „neoprávněná“ chyba. Ale na druhou stranu, pokud získáte seznam názvů databází, pak to automaticky znamená, že máte nahé nasazení MongoDB.

Externí ověření

Jak název napovídá, externí autentizace je o tom, že umožňuje uživatelům autentizaci v externí službě. Výjimečně jej nelze použít pro interního uživatele systému mongodb __, ale použití pro jakéhokoli skutečného lidského uživatele nebo účet služby klientské aplikace je naprosto vhodné.

Jednoduše, externí autentizační službou bude Kerberos KDC nebo server ActiveDirectory nebo OpenLDAP. Měli byste si uvědomit, že použití externího ověřování vám nebrání mít současně běžné uživatelské účty MongoDB.

Interní ověření

Naopak, interní autentizace MongoDB neznamená opak externí autentizace. Důvodem je to, že uzel mongod běžící s povolenou autentizací nebude věřit, že některý TCP peer je jiný, je jiný uzel mongod nebo mongos jen proto, že komunikuje jako jeden. Spíše to vyžaduje, aby se peer autentizoval pomocí důkazu sdíleného tajemství.

V MongoDB existují dva typy mechanismů interního ověřování:

Interní ověřování souboru klíčů.
Interní ověřování SCRAM nebo x.509.

Interní ověření souboru klíčů

Toto je výchozí mechanismus interního ověřování v MongoDB. Termín „klíč“ označuje asymetrický šifrovací klíč, ale ve skutečném smyslu je to pouze heslo bez ohledu na to, jak jste jej vygenerovali. Klíčový soubor je uložen v identickém souboru distribuovaném každému mongodu a mongos uzlu v clusteru. Ve scénáři, kdy je heslo úspěšně použito, uzel mongod umožní příkazům přicházejícím od ověřeného peeru běžet jako superuživatel „_ _ system“.

Pokud má někdo kopii souboru klíčů, může ze souboru klíčů jednoduše odstranit kontrolní a netisknutelné znaky a vytvořit řetězec hesla, který mu umožní připojit se jako uživatel „_ _ system“.

Pokud k tomu však dojde a spustíte příkaz níže jako uživatel mongod (nebo root) na jednom ze svých serverů MongoDB a uspějete, neměli byste se obávat, protože nedojde k náhodnému úniku oprávnění ke čtení . Je to proto, že mongod se při spuštění přeruší, pokud je soubor klíče v jiném než 400 (nebo 600) režimu oprávnění k souboru.

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

Ovšem náhodné uložení souboru klíče do vašeho světově čitelného ovládacího prvku zdroje může umožnit uživatelům, kteří nejsou správci databází (nebo správci serveru s rootem), číst kopii souboru klíče. To je považováno za selhání zabezpečení.

Extrémní riziko se zvyšuje, když je klíčový soubor distribuován s uzly mongos vlastněnými a provozovanými jako jeden z unixových uživatelů aplikačního týmu namísto „mongod“ nebo jiného unixového uživatele vlastněného týmem DBA.

SCRAM nebo interní ověření x.509

Mechanismus interního ověřování x.509 ve skutečnosti používá asymetrické soukromé nebo veřejné klíče a musí být používán ve spojení s TLS/SSL. Tento mechanismus lze použít pro připojení klientů i pro interní ověřování.

Mechanismus x.509 nebo SCRAM má oproti mechanismu Keyfile výhodu, protože v mechanismu x.509 je méně pravděpodobné, že jeden z klíčů nasazených v uzlech mongod a mongos může být zneužit vetřelce, který dostane jeho kopii. To však závisí na tom, jak přísně jsou certifikáty x.509 nastaveny. Chcete-li využít maximální zabezpečení z tohoto mechanismu, měli byste mít vyhrazený bezpečnostní tým, který rozumí konceptům x.509 a osvědčeným postupům. Tyto osvědčené postupy zahrnují zpřísnění toho, na kterých hostitelích bude fungovat, a možnost zrušit a převrátit certifikáty.

Šifrování sítě / Šifrování přenosu

Síťové šifrování zabraňuje někomu zkopírovat data přenášená přes síťové spojení někde mezi dvěma servery. Síťové šifrování vyžaduje minimální nebo žádné přemýšlení, pokud jde o rozhodování, zda jej použít, protože je klíčové. Ale pokud se například váš cluster MongoDB a všichni jeho klienti nacházejí ve virtuální privátní síti, o které se domníváte, že nemá žádné díry ve firewallu a žádné riziko eskalace oprávnění z jiných aplikací, pak šifrování sítě nepotřebujete.

Pro síťové šifrování byste měli nakonfigurovat MongoDB tak, aby používal TLS/SSL pro všechna odchozí a příchozí připojení. Šifrujte komunikaci mezi komponentami mongod a mongos nasazení MOngoDB a také mezi všemi aplikacemi a MongoDB pomocí TLS/SSL.

Od verze 4.0; MongoDB deaktivuje podporu pro šifrování TLS 1.0 na systémech, kde je k dispozici TLS 1.1+, a také používá následující nativní knihovny TLS/SSL:

Windows – zabezpečený kanál (Skanál).
Linux/BSD – OpenSSL.
macOS – Secure Transport.

Omezit síťové vystavení

Měli byste se ujistit, že MongoDB běží v důvěryhodném síťovém prostředí, a také nakonfigurovat firewall nebo skupiny zabezpečení pro řízení příchozího a odchozího provozu pro vaše instance MongoDB. Navíc nakonfigurujte tak, aby povoloval přístup pouze důvěryhodným klientům k síťovým rozhraním a portům, na kterých jsou dostupné instance MongoDB. Například pomocí whitelistingu IP povolte přístup z důvěryhodných IP adres.

Spusťte MongoDB s možnostmi bezpečné konfigurace

MongoDB podporuje spouštění kódu JavaScript pro následující operace na straně serveru:

mapReduce.
$where.
$accumulator.
$funkce.

Pokud nepoužijete výše uvedené operace, použijte volbu -- noscripting na příkazovém řádku k zakázání skriptování na straně serveru. Nechte ověření vstupu povolené, ačkoli MongoDB ve výchozím nastavení povoluje ověření vstupu prostřednictvím nastavení net.wireObjectCheck. Tím je zajištěno, že všechny dokumenty uložené instancí mongod jsou platné BSON.

Šifrování úložiště MongoDB / šifrování v klidu

Šifrování úložiště brání někomu v získání kopie základních databázových souborů. To se může stát, když se někdo vloupe do vašeho datového centra a ukradne pevný disk vašeho serveru. Data MongoDB zahrnují datové soubory, konfigurační soubory, protokoly auditu a soubory klíčů.

Počínaje MongoDB Enterprise 3.2 můžete šifrovat data ve vrstvě úložiště pomocí nativního Encryption-at-rest modulu úložiště WiredTiger. Data MongoDB by měla být šifrována na každém hostiteli pomocí souborového systému, zařízení nebo fyzického šifrování, pokud nepoužíváte šifrování WiredTiger v klidu. Také byste měli shromažďovat protokoly do centrálního úložiště protokolů, protože tyto protokoly obsahují pokusy o ověření DB včetně zdrojové IP adresy. Šifrování úložiště však má mírné náklady na výkon.

Audit

Audit pomáhá při sledování uživatele databáze, který ví, jak zakrýt své stopy po změně nebo změně dat databáze. Audit v zásadě sleduje přístup a změny konfigurací databáze a dat. MongoDB Enterprise má systém auditování, který může zaznamenávat systémové události, jako jsou operace uživatelů a události připojení v instanci MongoDB.

Tyto záznamy auditu pomáhají při forenzní analýze a umožňují správcům ověřit správné kontroly. Audit má pro některé uživatele vysokou hodnotu, ale může být takový pouze tehdy, když jsou eliminována některá další rizika. Útočník například nemůže získat unixový root přístup na serverech, když běží živé mongod nody.

Posun vpřed

Můžete nastavit filtry pro záznam konkrétních událostí, jako jsou události ověřování. Buďte však opatrní, protože když jsou filtry auditu příliš široké, jejich výkon se rychle udusí, což povede k vysokým nákladům na výkon. I když, pokud je auditování používáno vhodně, nebudou náklady na výkon příliš vysoké.