Základní průvodce zabezpečením MongoDB

David Murphy slouží jako vedoucí praxe pro MongoDB ve společnosti Percona, poskytovatel řešení a služeb MySQL a MongoDB podnikové třídy.

Zabezpečení MongoDB je opět ve zprávách. Nedávná řada příběhů odhaluje, jak hackeři využívají databáze MongoDB a vykupují data za bitcoiny. Podle Rapid7 byly kompromitovány desítky tisíc instalací MongoDB.

Všichni se obáváme o bezpečnost. Pokud spouštíte aplikace, sítě nebo databáze, je zabezpečení vždy problémem nejvyšší úrovně. S tím, jak se více společností obrací na software s otevřeným zdrojovým kódem, jako je MongoDB, k ukládání důležitých podnikových dat, stává se zabezpečení ještě větší otázkou. V závislosti na vašem podnikání můžete také mít několik vládních (například Health Insurance Portability and Accountability Act nebo HIPAA) nebo obchodních (Payment Card Industry Data Security Standard nebo PCI DSS) standardů zabezpečení sítě, které musíte dodržovat.

Je databázový software MongoDB bezpečný? Vyhovuje těmto normám? Krátká odpověď: Ano, to je a ano! Jde jen o to vědět, jak nastavit, konfigurovat a pracovat s konkrétní instalací.

V tomto článku se budu zabývat zabezpečením MongoDB. MongoDB je bezpečné používat - pokud víte, co hledat a jak to nakonfigurovat.

Za prvé, jak se lidé pokazí v zabezpečení MongoDB? Pokud jde o zabezpečení MongoDB, uživatelé narazí na několik klíčových oblastí:

• Pomocí výchozích portů
• Nepovolení ověřování okamžitě (největší problém!)
• Při použití ověřování poskytuje všem široký přístup
• Nepoužívání protokolu LDAP k vynucení rotace hesla
• Nevynucuje použití SSL v databázi
• Neomezuje přístup k databázi známým síťovým zařízením (hostitelé aplikací, nástroje pro vyrovnávání zatížení atd.)
• Neomezuje to, která síť poslouchá (toto však již nemá vliv na podporované verze)

MongoDB má pět základních bezpečnostních oblastí:

• Ověření. Ověření LDAP centralizuje položky ve vašem firemním adresáři.
• Povolení. Autorizace definuje, jaké kontroly přístupu na základě rolí poskytuje databáze.
• Šifrování. Šifrování lze rozdělit na At-Rest a In-Transit. Šifrování je pro zabezpečení MongoDB zásadní.
• Auditování. Auditování se týká schopnosti zjistit, kdo co v databázi udělal.
• Správa věcí veřejných. Správa věcí veřejných se týká ověřování dokumentů a kontroly citlivých údajů (například čísla účtu, hesla, čísla sociálního zabezpečení nebo data narození). To se týká jak vědět, kde jsou uložena citlivá data, tak zabránit zavádění citlivých dat do systému.

Ověření LDAP

MongoDB má vestavěné uživatelské role a ve výchozím nastavení je vypíná. Chybí mu však položky, jako je složitost hesla, rotace podle věku, centralizace a identifikace uživatelských rolí versus servisní funkce. To je zásadní pro splnění předpisů, jako je shoda s PCI DSS. Například PCI DSS zakazuje používání starých hesel a snadno prolomitelných hesel a vyžaduje změny v přístupu uživatele, kdykoli se změní stav (například když uživatel opustí oddělení nebo společnost).

Naštěstí lze k vyplnění mnoha těchto mezer použít protokol LDAP. Mnoho konektorů umožňuje použití systémů Windows Active Directory (AD) pro komunikaci s LDAP.

Poznámka: Podpora LDAP je k dispozici pouze v MongoDB Enterprise. Není ve verzi pro komunitu. Je k dispozici v jiných otevřených zdrojových verzích MongoDB, jako je Percona Server pro MongoDB.

MongoDB 3.2 ukládá uživatele na LDAP, ale ne role (ty jsou aktuálně uloženy na jednotlivých počítačích). MongoDB 3.4 Enterprise by měl zavést schopnost ukládat role v LDAP pro centralizovaný přístup. (O rolích budeme hovořit později.)

Percona

Pomocí LDAP a AD můžete spojit uživatele s podnikovým adresářem. Když změní role nebo opustí společnost, mohou je odebrat lidské zdroje z vaší databázové skupiny. Máte tedy zavedený automatizovaný systém, který zajišťuje, že tak mohou učinit pouze ti, k nimž chcete přistupovat ručně, aniž by náhodou něco chybělo.

LDAP v Mongo je ve skutečnosti snadný. MongoDB má speciální příkaz, který mu říká, aby zkontroloval externí databázi LDAP: $ externí.

Některá další upozornění k používání LDAP:

• Vytvořit uživatele pomocí .vytvořit uživatele jako obvykle, ale nezapomeňte použít značky prostředků db / collection.
• Ověření LDAP navíc vyžaduje další dvě pole:
  • mechanismus: „PLAIN“
  • digestPassword: false

Vlastní role

Řízení přístupu na základě rolí (RBAC) je jádrem MongoDB. Integrované role jsou v MongoDB k dispozici od verze 2.6. Dokonce si můžete vytvořit vlastní, až po konkrétní akce, které může mít konkrétní uživatel povoleno. To vám umožní přesně definovat, co může konkrétní uživatel dělat nebo vidět. Toto je základní funkce MongoDB, která je k dispozici téměř ve verzi open source softwaru každého dodavatele.

Pět hlavních předdefinovaných rolí MongoDB, kterých byste si měli být vědomi:

• číst:
  • Přístup jen pro čtení, obvykle poskytovaný většině uživatelů
• číst psát:
  • číst psát přístup umožňuje úpravy dat
  • číst psát zahrnuje čtení
• dbOwner:
  • Zahrnuje číst psát, dbAdmin, userAdmin (pro databázi). userAdmin znamená přidávání nebo odebírání uživatelů, udělování oprávnění uživatelům a vytváření rolí. Tato oprávnění jsou přiřazena pouze konkrétnímu databázovému serveru.
• dbAdminAnyDatabase:
  • Vytváří dbAdmin ve všech databázích, ale neumožňuje správu uživatelů (například vytváření nebo odebírání uživatelů). Můžete vytvářet indexy, volání volání a další. To neposkytuje přístup ke sdílení.
• vykořenit:
  • Toto je superuživatel, ale s limity
  • Dokáže většinu věcí, ale ne všechny:
    • Sbírku systému nelze změnit
    • Některé příkazy této roli stále nejsou k dispozici, v závislosti na verzi. Například kořenová role MongoDB 3.2 vám neumožňuje změnit velikost oplogu nebo profilovače a kořenová role MongoDB 3.4 vám neumožňuje číst aktuální pohledy.

Zástupné databáze a sbírky

Zástupný znak znamená udělování oprávnění velkým skupinám databází nebo sbírek (nebo všem) na serveru. S nulovou hodnotou můžete určit všechny databáze nebo kolekce a vyhnout se dbAdminAnyDatabase role. To umožňuje konkrétním uživatelům mít všechna oprávnění, včetně administračních funkcí.

To je nebezpečné.

Když použijete zástupné znaky, udělíte spoustu zvláštních oprávnění a měli byste si být vědomi toho, že otevíráte možné cesty útoku:

• readWriteAnyDatabase je velmi široký a vystavuje uživatelská jména a role potenciálnímu útoku prostřednictvím uživatele aplikace
• Použití zástupných znaků znamená, že nebudete omezovat konkrétní aplikace na konkrétní databáze
• Zástupný znak vám brání používat multitenancy s více databázemi
• Novým databázím není automaticky udělen přístup

Vytvoření vlastní role

Síla rolí MongoDB pochází z vytváření vlastních rolí. Ve vlastní roli můžete určit, že pro konkrétního uživatele lze zadat jakoukoli akci na jakémkoli prostředku. Díky této úrovni podrobnosti můžete hluboce ovládat, kdo může co dělat ve vašem prostředí MongoDB.

Pokud jde o určení vlastní role, existují čtyři odlišné typy prostředků:

• db. Určuje databázi. Můžete použít řetězec pro jméno nebo „“ pro „libovolný“ (bez zástupných znaků).
• sbírka. Určuje kolekci dokumentů. Můžete použít řetězec pro jméno nebo „“ pro „libovolný“ (bez zástupných znaků).
• shluk. Určuje shardovaný cluster nebo jiné prostředky metadat. Jedná se o logickou hodnotu true / false.
• anyResource. Určuje přístup ke všemu a kdekoli. Jedná se o logickou hodnotu true / false.

Jakákoli role může zdědit vlastnosti jiné role. Existuje pole s názvem „role“ a můžete do něj pustit novou roli. Zdědí vlastnosti zadané role.

Použití createRole přidat roli do pole.

Můžete přidat nové nebo stávající databáze uživateli nebo roli. Například můžete přidat přístup pro čtení a zápis do databáze připojením databáze k roli.

Použijte grantPrivilegesToRole příkaz pro přidání nových prostředků do existující role.

Níže je uveden příklad vytvoření nové role superuživatele. Účelem této role je opět mít jednoho uživatele, který není nijak omezen v prostředí MongoDB (pro nouzové situace).

db = db.geSiblingDB („správce“);

db.createRole ({

role: „superRoot“,

oprávnění: [{

zdroj: {anyResource: true},

akce: [„anyAction“]

     }]     

role: []

});

db.createUser ({

uživatel: “comanyDBA”,

pwd: „EWqeeFpUt9 * 8zq“,

role: [“superRoot”]

})

Tyto příkazy vytvářejí v databázi novou roli geSiblingDB volala super kořen a přiřadit této roli jakýkoli zdroj a jakoukoli akci. Potom vytvoříme nového uživatele ve stejné databázi s názvem společnost DBA (s heslem) a přiřaďte mu nový super kořen role.

Používání SSL pro všechny věci

SSL pomáhá zajistit bezpečnost vašich dat přes nezabezpečené sítě. Pokud zaměstnáváte databázi, která interaguje s internetem, měli byste použít SSL.

Existují dva velmi dobré důvody, proč používat SSL k zabezpečení MongoDB: soukromí a ověřování. Bez SSL lze k vašim datům přistupovat, kopírovat je a používat je pro nezákonné nebo škodlivé účely. S autentizací máte sekundární úroveň bezpečnosti. Infrastruktura soukromého klíče SSL (PKI) zaručuje, že k MongoDB mají přístup pouze uživatelé se správným certifikátem CA.

MongoDB má podporu SSL po dlouhou dobu, ale v posledních několika verzích dramaticky zlepšila podporu SSL. Dříve, pokud jste chtěli používat SSL, museli jste si jej stáhnout a ručně zkompilovat s komunitní verzí MongoDB. Od verze MongoDB 3.0 je ve výchozím nastavení kompilován SSL se softwarem.

U starších verzí MongoDB také chyběla platná kontrola hostitele; ověření hostitele bylo pouze příznakem, který můžete zkontrolovat v konfiguračním souboru, který uspokojil požadavek SSL z připojení.

Nejnovější verze SSL v MongoDB obsahují následující klíčové funkce:

• Kontroly platných hostitelů (volitelné)
• Schopnost ukazovat na konkrétní instalační soubor .key, který se má použít
• Vlastní certifikační autorita (CA) pro certifikáty s vlastním podpisem nebo alternativní podepisující
• allowSSL, preferSSL, requireSSL režimy, které vám umožňují vybrat podrobnost vašeho použití SSL (od méně zabezpečeného po bezpečnější)

SSL: Použití vlastní CA.

Novější verze SSL v MongoDB umožňují používat vlastní CA. To vám dává flexibilitu při určování toho, jak chcete pracovat s SSL, ale přichází s upozorněními. Pokud se jednoduše pokoušíte zabezpečit připojení, můžete být v pokušení se rozhodnout sslAllowInvalidCertficates. To je však obecně špatný nápad z několika důvodů:

• Umožňuje jakékoli připojení, jehož platnost vypršela, a zrušeným certifikátům
• Nezajišťujete omezení konkrétního názvu hostitele
• Nejste zdaleka tak zabezpečení, jak si myslíte

Chcete-li to opravit, jednoduše nastavte net.ssl.CAFilea MongoDB použije oba klíč a soubor CA (musíte to udělat na klientovi).

Používání SSL má však známou nevýhodu: výkon. Při používání SSL určitě ztratíte nějaký výkon.

Šifrování disku

Data jsou „v přenosu“ nebo „v klidu“. V MongoDB můžete šifrovat jeden nebo oba. Diskutovali jsme o šifrování dat při přenosu (SSL). Nyní se podívejme na data v klidu.

Data v klidu jsou data uložená na disku. Šifrování Data-at-Rest obvykle odkazuje na data uložená do šifrovaného úložiště. To má zabránit krádeži fyzickými prostředky a vytvořit zálohy, které jsou uloženy způsobem, který není snadno čitelný žádnou třetí stranou. Existují v tom praktická omezení. Největší je důvěra ve správce systému - a za předpokladu, že hacker nezískal přístup správce do systému.

Toto není problém jedinečný pro MongoDB. Také zde fungují preventivní opatření použitá v jiných systémech. Mohou zahrnovat šifrovací nástroje, jako jsou LUKS a cryptfs, nebo dokonce bezpečnější metody, jako je podepisování šifrovacích klíčů pomocí LDAP, čipových karet a tokenů typu RSA.

Při provádění této úrovně šifrování musíte vzít v úvahu faktory, jako je automatické připojení a dešifrování jednotek. Pro správce systému to ale není novinka. Mohou tento požadavek spravovat stejným způsobem jako v jiných částech sítě. Další výhodou je jediný postup pro šifrování úložiště, nikoli jeden pro jakoukoli technologii, kterou konkrétní funkce používá.

Šifrování Data-at-Rest lze vyřešit některým z následujících postupů:

• Zašifrujte celý svazek
• Šifrujte pouze soubory databáze
• Šifrování v aplikaci

První položku lze vyřešit šifrováním disku v systému souborů. Nastavení je snadné pomocí LUKS a dm-crypt. Pro splnění požadavků PCI DSS a další požadavky na certifikaci je vyžadována pouze první a druhá možnost.

Auditování

Ústředním bodem každého dobrého bezpečnostního návrhu je schopnost sledovat, který uživatel provedl jakou akci v databázi (podobně jako byste měli ovládat své skutečné servery). Auditování umožňuje filtrovat výstup konkrétního uživatele, databáze, kolekce nebo umístění zdroje. Tím se vygeneruje protokol ke kontrole případných bezpečnostních incidentů. Ještě důležitější je, že ukazuje každému auditorovi zabezpečení, že jste podnikli správné kroky k ochraně databáze před vniknutím a porozuměli hloubce jakéhokoli narušení, pokud by k němu došlo.

Auditování vám umožňuje plně sledovat akce vetřelce ve vašem prostředí.

Poznámka: Audit je k dispozici pouze v MongoDB Enterprise. Není ve verzi pro komunitu. Je k dispozici v některých dalších otevřených zdrojových verzích MongoDB, jako je Percona Server pro MongoDB.