Jak používat šifrování k ochraně dat MongoDB

Zabezpečení databáze je klíčovým faktorem, který je třeba zvážit u každé aplikace, která zahrnuje vysoce citlivá data, jako jsou finanční a zdravotní zprávy. Ochrany dat lze dosáhnout pomocí šifrování na různých úrovních počínaje samotnou aplikací až po soubory obsahující data.

Protože MongoDB je nerelační databáze, není třeba před vložením dat definovat sloupce; a proto dokumenty ve stejné kolekci mohou mít navzájem různá pole.

Na druhou stranu pro SQL DBMS je třeba definovat sloupce pro data, takže všechny řádky mají stejné sloupce. Před zapojením do procesu databáze se můžete rozhodnout zašifrovat jednotlivé sloupce, celý databázový soubor nebo data z aplikace.

Nejvýhodnější je šifrování jednotlivých sloupců, protože je levnější a šifruje se méně dat, čímž se zlepšuje latence. Obecně platí, že celkový výkon má dopad v důsledku šifrování.

Pro NoSQL DBMS však tento přístup nebude nejlepší. Vzhledem k tomu, že ne všechny dokumenty mohou obsahovat všechna pole, která chcete při šifrování použít, nelze šifrování na úrovni sloupců provést.

Šifrování dat na aplikační úrovni je poměrně nákladné a obtížně implementovatelné. Zůstáváme proto u možnosti šifrování dat na úrovni databáze.

MongoDB poskytuje nativní šifrování, které nevyžaduje žádné dodatečné náklady za zabezpečení vašich citlivých dat.

Šifrování dat v MongoDB

Jakákoli databázová operace zahrnuje jednu z těchto dvou datových forem, data v klidu nebo data v pohybu.

Data v pohybu jsou tok dat procházející jakýmkoliv typem sítě, zatímco data v klidu jsou statická, a tudíž se nikam neposouvají.

Oba tyto dva datové typy jsou náchylné k externímu rušení ze strany anonymních uživatelů, pokud se nejedná o šifrování. Proces šifrování zahrnuje:

• Generování hlavního klíče pro celou databázi
• Generování jedinečných klíčů pro každou databázi
• Šifrování dat pomocí vámi vygenerovaných databázových klíčů
• Šifrování celé databáze pomocí hlavního klíče

Šifrování dat při přenosu

Data jsou mezi MongoDB a serverovou aplikací přenášena dvěma způsoby, a to prostřednictvím Transport Layer Security (TLS) a Secure Socket Layer (SSL).

Tyto dva jsou nejpoužívanějšími šifrovacími protokoly pro zabezpečení odesílaných a přijímaných dat mezi dvěma systémy. V zásadě jde o šifrování připojení k instancím mongod a mongos tak, aby síťový provoz byl čitelný pouze zamýšleným klientem.

TLS/SSL se v MongoDB používají s některými certifikáty jako soubory PEM, které vydává certifikační autorita nebo mohou být certifikáty s vlastním podpisem. Ten má omezení v tom, že bez ohledu na to, že je komunikační kanál zašifrován, vždy nedochází k ověření identity serveru, a proto je uprostřed cesty zranitelný vůči externím útokům. Je proto vhodné používat certifikáty důvěryhodných autorit, které umožňují ovladačům MongoDB ověřit identitu serveru.

Kromě šifrování lze TLS/SSL použít při autentizaci klienta a interních autentizacích členů sad replik a sdílených clusterů prostřednictvím certifikátů.

Konfigurace TLS/SSL pro klienty

Existují různá nastavení možností TLS/SSL, která lze použít při konfiguraci těchto protokolů.

Pokud se například chcete připojit k instanci Mongoda pomocí šifrování, spustíte svou instanci takto:

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl povolí připojení TLS/SSL.

--sslCAFile určuje soubor pem certifikační autority (CA) pro ověření certifikátu předloženého mongodem nebo mongos. Shell Mongo proto ověří certifikát vydaný instancí mongoda proti zadanému souboru CA a názvu hostitele.

Můžete také chtít připojit instanci MongoDB, která vyžaduje klientský certifikát. Používáme ukázku kódu níže

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

Volba --sslPEMKeyFile určuje soubor .pem, který obsahuje certifikát prostředí mongo a klíč, který se má předložit instanci mongod nebo mongos. Během procesu připojení:

Shell mongo ověří, zda je certifikát od zadané certifikační autority, kterou je (--sslCAFile), a pokud ne, shell se nepřipojí.

Za druhé, shell také ověří, zda název hostitele zadaný ve volbě --host odpovídá SAN/CN v certifikátu předloženém mongodem nebo mongos. Pokud tento název hostitele neodpovídá žádnému z těchto dvou, připojení se nezdaří.

Pokud nechcete používat certifikáty s vlastním podpisem, musíte se ujistit, že síť připojení je důvěryhodná.

Kromě toho musíte omezit vystavení soukromého klíče, zejména tam, kde se jedná o sady replik/sharded cluster. Toho lze dosáhnout použitím různých certifikátů na různých serverech.

Další možnosti, které lze v připojeních použít, jsou:

requireSSL:toto omezí každý server na používání pouze šifrovaných připojení TLS/SSL.

--sslAllowConnectionsWithoutCertificates:Umožňuje ověření, pokud certifikát předloží pouze klient, jinak pokud certifikát neexistuje, bude klient stále připojen v šifrovaném režimu. Například:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:tato možnost zabraňuje serverům přijímat příchozí připojení, která používají specifické protokoly. To lze provést pomocí:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Šifrování dat v klidu

Od verze 3.2 MongoDB zavedl možnost nativního šifrování pro úložiště WiredTiger. Přístup k datům v tomto úložišti třetí stranou lze dosáhnout pouze prostřednictvím dešifrovacího klíče pro dekódování dat do čitelného formátu.

Běžně používaný šifrovací šifrovací algoritmus v MongoDB je AES256-GCM. K šifrování a dešifrování dat používá stejný tajný klíč. Šifrování se zapíná pomocí režimu FIPS, čímž je zajištěno, že šifrování splňuje nejvyšší standardy a shodu.

Celé databázové soubory jsou šifrovány pomocí Transparent data encryption (TDE) na úrovni úložiště.

Kdykoli je soubor zašifrován, je vygenerován jedinečný soukromý šifrovací klíč a je dobré porozumět tomu, jak jsou tyto klíče spravovány a uloženy. Všechny vygenerované databázové klíče jsou poté zašifrovány hlavním klíčem.

Rozdíl mezi databázovými klíči a hlavním klíčem je v tom, že databázové klíče mohou být uloženy spolu se samotnými šifrovanými daty, ale pro hlavní klíč MongoDB doporučuje, aby byl uložen na jiném serveru než šifrovaná data, jako je podnikový klíč třetí strany. řešení pro správu.

U replikovaných dat nejsou kritéria šifrování sdílena s ostatními uzly, protože data nejsou nativně šifrována po drátě. Pro uzly lze znovu použít stejný klíč, ale nejlepším postupem je použít jedinečné individuální klíče pro každý uzel.

Rotující šifrovací klíče

Spravovaný klíč používaný k dešifrování citlivých dat by měl být otočen nebo nahrazen alespoň jednou ročně. V MongoDB jsou dvě možnosti, jak dosáhnout rotace.

Hlavní rotace KMIP

V tomto případě se změní pouze hlavní klíč, protože je spravován externě. Postup otáčení klíče je popsán níže.

1. Hlavní klíč pro sekundární členy v sadě replik se otáčí jeden po druhém. T.j.

   mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

   Po dokončení procesu se mongod ukončí a budete muset restartovat sekundární server bez parametru kmipRotateMasterKey

   mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

2. Primární sada replik je snížena:
   Pomocí metody rs.stepDown() je primární deaktivována, čímž je vynucena volba nového primárního prvku.

3. Zkontrolujte stav uzlů pomocí metody rs.status() a pokud primární ukazuje, že byly sníženy, otočte jeho hlavní klíč. Restartujte člen se sníženou funkcí včetně možnosti kmipRotateMasterKey.

   mongod --enableEncryption --kmipRotateMasterKey \
     --kmipServerName <KMIP Server HostName> \
     --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Protokolování

MongoDB vždy pracuje se souborem protokolu pro záznam nějakého stavu nebo specifikovaných informací v různých intervalech.

Soubor protokolu však není zašifrován jako součást modulu úložiště. To představuje riziko, že instance mongodu běžící s protokolováním může vydávat potenciálně citlivá data do souborů protokolu právě jako součást běžného protokolování.

Od verze MongoDB 3.4 existuje nastavení security.redactClientLogData, které zabraňuje zaznamenávání potenciálně citlivých dat do protokolu procesů mongod. Tato možnost však může komplikovat diagnostiku protokolu.

Výkon šifrování v MongoDB

Šifrování v určitém okamžiku vede ke zvýšené latenci, a tím ke snížení výkonu databáze. To je obvykle případ, kdy se jedná o velký objem dokumentů.

Šifrování a dešifrování vyžaduje více zdrojů, a proto je důležité porozumět tomuto vztahu, aby bylo možné odpovídajícím způsobem upravit plánování kapacity.

Pokud jde o testy MongoDB, šifrované úložiště bude mít při nejvyšší zátěži latenci mezi 10 % až 20 %. To se často stává, když uživatel zapisuje do databáze velké množství dat, což vede ke snížení výkonu. Pro operace čtení je snížení výkonu zanedbatelné, asi 5 - 10 %.

Pro lepší praxi šifrování v MongoDB je nejvýhodnější modul úložiště WiredTiger kvůli jeho vysokému výkonu, zabezpečení a škálovatelnosti. Dále optimalizuje šifrování databázových souborů na úroveň stránky, což má velkou výhodu v tom, že pokud uživatel čte nebo zapisuje data do šifrované databáze, operace propustnosti bude aplikována pouze na stránku, na které jsou data uložena, nikoli na celou databáze.

Sníží se tak množství dat, která budou muset být zašifrována a dešifrována pro zpracování jednoho kusu dat.

Shrnutí

Zabezpečení citlivých informací je nutností a je potřeba je chránit, aniž by došlo ke snížení výkonu databázového systému.

MongoDB poskytuje robustní nativní šifrovací postupy, které nám mohou pomoci zabezpečit naše data jak v klidu, tak i v pohybu. Kromě toho by šifrovací postupy měly odpovídat stanoveným standardům různých organizací.

Pokročilý modul úložiště WiredTiger poskytuje lepší možnost díky souvisejícím výhodám, jako je vysoký výkon, škálovatelnost a zabezpečení. Při šifrování dat v sadách replik je dobrým zvykem používat pro každou z nich různé hlavní klíče, kromě toho je alespoň jednou ročně měnit.

Nicméně dostupnost možností šifrování třetích stran, neexistuje žádná záruka, že se vaše nasazení bude shodovat s nimi, pokud jde o škálovatelnost. Je tedy docela ohleduplné používat šifrování na úrovni databáze.