sql >> Databáze >  >> NoSQL >> MongoDB

Zabezpečení databáze 101:Pochopení oprávnění přístupu k databázi

Data jsou novým zlatem pro velké společnosti a organizace. Jsou považována za životodárnou mízu většiny moderních podniků a existuje mnoho příležitostí k prodeji nebo marketingu velkému publiku na internetu. U velkých společností zabývajících se elektronickým obchodováním nebo sociálními médii data řídí jejich kapacitu generovat velké příjmy a výdělky, pro které jsou data přísně zabezpečena a mají sofistikovanou ochranu proti jakýmkoli škodlivým útokům a útokům narušení online.

Takže data jako zlato, jejich cenný stav začíná, jakmile jsou zpracována. Jeho surová hodnota je plná nepořádku, jako by šlo o gigantický netříděný kousek Jakmile je jeho podstata strukturována, hodnota dat se násobí. Představte si, že máte vzdělávací web, který umožňuje uživatelům platit. Jakmile budete mít spoustu přednášek a modulů, které se vaše cílové publikum může naučit, rozvíjet a získat určitý stupeň produktivity, pochopili jste chuť příležitosti a úspěchu, protože máte dveře regulovat poplatky, než mohou získat strukturovaná data, která chtějí. . Ačkoli to zní jako sen každého o úspěchu, pokud jde o velká data a jejich základní podstatu, existuje spousta komplikací při jejich zpracování a důležitým problémem jsou hrozby pro vaši databázi.

Databázové hrozby obecně mají četná a rozsáhlá odvětví, která je třeba zkoumat a zkoumat. Nejčastějšími příčinami jsou však krádeže dat a narušení dat. Další častou hrozbou jsou rozsáhlá oprávnění nebo přístup k databázím nesprávně přiděleným a/nebo poskytnutým uživateli. Ochrana celého hostitele serveru je starostí každého, kdo spravuje databázi. Zpřísněte zabezpečení a vypořádejte se se všemi typy použitelných útoků, jako je odposlouchávání, pozměňování, přehrávání a odmítnutí služby (DDoS), nejen pro databázi, ale také pro celý její základní zásobník, který má přístup nebo který je propojen s vaším datovým úložištěm.

V tomto blogu probereme rozsah nutnosti, proč potřebujete rozumět a mít přístupová práva k databázi.

Nebezpečí chybných přístupových oprávnění

Nevyhnutelně musíme sdílet nebo alespoň vytvořit uživatele na fyzické i technické úrovni. Poskytnutí přístupu někomu jinému znamená, že dané osobě důvěřujete. To také znamená, že oprávněná osoba musí chápat nebezpečí a nebezpečí sdílení přístupu a dat z vnějšího světa.

Nejdůležitějším bodem zabezpečení vašich přístupových práv je úroveň porozumění bezpečnosti mezi vašimi techniky, jako je správce databáze, bezpečnostní technik nebo správce serveru. Pokud je porozumění nedostatečné nebo chybí znalosti a zkušenosti, zejména pokud jde o nejaktuálnější zranitelnosti a ohrožení, může to být pro organizaci nebo společnost problém.

Jsou základní věci, kterým je třeba porozumět a vzít je v úvahu, aby to bylo minimální nebo alespoň nemohlo být rušeno nebo odhaleno. V opačném případě by to mohlo ohrozit vaše data zvenčí nebo alespoň pro nesprávnou osobu nebo osoby. Možná ukrást vaše data a použít je pro své vlastní účely k finančnímu zisku, nebo je od vás mohou vykoupit a požádat o peníze výměnou za vaši špatnou implementaci zabezpečení.

V této části se podíváme na některé běžné příčiny těchto bezpečnostních hrozeb.

Sdílení kořenového přístupového oprávnění

V místním prostředí se běžný případ narušení databáze většinou spoléhá na nebezpečí udělení přístupu root buď na úrovni OS nebo na úrovni databázového softwaru. Existují případy, kdy je heslo uživatele root distribuováno a vystaveno několika lidem, což by mělo být omezeno pouze na administrátory pracující pouze na systému. K tomu může dojít z důvodu chybějícího kontrolního seznamu zabezpečení nebo opatření v protokolu před implementací přístupových práv. Kontrolní seznam zabezpečení pomáhá sledovat jakýkoli přístup a oprávnění, která by mohla vystavit riziku a nebezpečí, zejména když je konkrétní uživatel OS vystaven vetřelci. Kontrolní seznam vám také pomůže diskutovat nebo získat přehled o bezpečnostních opatřeních zavedených a implementovaných jako protokol pro vaši organizaci.

Například uživatel, který má přístup root, může způsobit velké škody, jako je odstranění všech vašich dat z fyzického úložného disku, resetování hesla uživatele root, vytvoření vlastního uživatele/hesla, které vypadá jako legitimní uživatel (lze jej použít po velmi dlouhou dobu ke sběru dat, pokud nejsou zachycena brzy), sudo jinému uživateli OS, jako je uživatel postgres, a mnohem děsivější věci, které si může vetřelec užít.

Pokud používáte MongoDB, může se k vašemu databázovému serveru přihlásit uživatel s přístupem root. Pokud útočník dokáže najít váš /etc/mongod.conf nebo váš konfigurační soubor mongodb a najít cestu vašeho klíče, je snadné se přihlásit. Například pomocí tohoto příkazu se můžete přihlásit,

[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"

Vezměte si v úvahu normální nastavení instalace MySQL, root přístup může být ponechán bez hesla pro přístup k localhost. Jakmile jste root, je snadné získat přístup. Přístup k souborům, jako je $HOME/.my.cnf nebo prohlížení obsahu /etc/my.cnf, vám umožní snadno získat přístup.

Důrazně se doporučuje omezit nebo prostě dát váš root přístup y co nejmenšímu počtu lidí, kteří pracují přímo se serverem na aktualizaci balíčků, aktualizací zabezpečení a použití záplat, které jsou vyžadovány vývojový tým.

Správné používání sudoers

Mainstreamový databázový software s otevřeným zdrojovým kódem, jako je PostgreSQL, MySQL/MariaDB, MongoDB, vyžaduje vytvoření konkrétního uživatele OS. Uživatel OS vyžaduje specifickou roli omezenou tak, aby umožňovala správu jeho schopností v rámci funkčnosti databáze. Pro základní cestu úložného zařízení je třeba nastavit správná oprávnění ke čtení a zápisu. Existují však případy, kdy někteří, kteří používají tyto konkrétní uživatele pro databázový software, mají oprávnění sudo, která jsou také schopna přistupovat k uživateli určenému výhradně pro přístup k databázi. Uživatelská oprávnění v OS musí být omezena a nejlepší je omezit jeho přístup na základě role. Například pro Percona Server CVE-2016-6664, ačkoli to bylo opraveno, je tento typ zranitelnosti příkladem možného útoku ze strany konkrétního uživatele, který má přístup k účtu MySQL a získává root přístup. Uživatelé sudo musí být zkontrolováni a musí pochopit, že role je omezena pouze na konkrétní práci.

Povolení systému Linux Auditing System, jako je auditd, může pomoci zlepšit zabezpečení, protože zvyšuje přehlížená přístupová oprávnění na úrovni operačního systému, což by mohlo vést k bezpečnostním chybám vaší databáze. SELinux a AppArmor jsou dobrými příklady bezpečnostních modulů pro vaše linuxové prostředí, které hostují váš databázový systém, aby pomohly zlepšit vaše zabezpečení proti narušitelům nebo narušení, která by vedla k ohrožení vašich dat.

Udělování oprávnění pro přístup k databázi

Mainstreamové databáze s otevřeným zdrojovým kódem nabízejí podrobný seznam oprávnění, která lze přizpůsobit tak, aby byla přiřazena pouze konkrétní akci pro konkrétního uživatele. Jedná se o rozsáhlý způsob, jak správcům databází pomoci bezpečně oddělit data a zacílit akci na základě konkrétních oprávnění.

Společná přístupová oprávnění

Vaše nejčastěji používaná oprávnění budou založena na těchto třech kategoriích:

  • Umí číst/najít, např. VYBRAT, ZOBRAZIT, NAJÍT

  • Schopnost vkládat/aktualizovat/mazat, např. INSERT, UPDATE, DELETE, REMOVE

  • Schopnost provádět administrativní akce, jako je VYTVOŘENÍ UŽIVATELE, VYTVOŘENÍ ROLE, ZMĚNIT, REPLIKACE, PŘERUŠIT UŽIVATELE/TABULKY/ SCHEMA, operace zabíjení atd.

Tyto kategorie lze rozšířit na jemnější oprávnění na základě vašeho kontrolního seznamu zabezpečení. Je dobré definovat konkrétního uživatele, který má být vytvořen se specifickými oprávněními pro konkrétní úkol. Aplikace může mít například více uživatelů s přidělenými vlastními oprávněními. I když aplikace může být s tímto typem implementace komplexní. Existují případy, kdy konektivita pro jednotlivé uživatele může být náročná na zdroje, jako je například použití ORM, jako je Hibernate. Na druhou stranu záleží na architektonickém návrhu vaší aplikace. Účel použití na úrovni jednotlivých uživatelů v aplikaci může pomoci udržet preciznější přístupová práva k databázi a vyhnout se poškození vašich dat nechtěným smazáním, aktualizacemi nebo injekcí SQL napadající vaši databázi.

Ve většině případů používá aplikace k připojení k databázi jednoho uživatele, což je omezeno pouze na akce, které má konkrétní aplikace spustit. Nejlepší je navrhnout uživatelská oprávnění aplikace tak, aby umožňovala pouze čtení a zápis. Zatímco pokud jsou vyžadovány administrativní akce, musí být specifický skript, démon nebo modul v přístupu k vaší aplikaci oddělen od běžných uživatelů.-.

Je třeba se vyhnout přístupu k databázi

PostgreSQL a MySQL/MariaDB mají tuto možnost udělit uživateli VŠECHNA oprávnění. Pro PostgreSQL je také nejlepší mít svého uživatele s NOSUPERUSER. Je-li to možné, je třeba se tomu za každou cenu vyhnout. Toto oprávnění může provádět většinu všech akcí, které mohou potenciálně zničit nebo poškodit vaše cenná data. Pro přístup správce nebo root můžete použít VŠECHNA oprávnění, ale jsou omezena pouze na uživatele, kteří vyžadují super oprávnění k provádění administrativních úkolů a správě dat.

Přístup podle tabulky nebo schématu

Dobrým postupem je poskytnout uživateli přístup pouze k požadovaným tabulkám. . Takže i když má uživatel nějaká administrátorská práva, jakékoli poškození se týká pouze omezené sady tabulek. Buď můžete nastavit na celé schéma; poskytování přístupu k omezené tabulce poskytuje granulární typ oprávnění a pomáhá vám chránit vaše data před poškozením.

Omezený přístup pouze pro hostitele

Připojení prostřednictvím IP adresy zdroje pomáhá omezit přístup k vašim datům. Nepoužívejte '%', například v MySQL,

GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';

Rozsah poškození je vystaven každému hostiteli, ke kterému se může připojit, a to jste nechtěli. Způsobuje zranitelnost a problém narušení vaší databáze je velmi nízký.

U PostgreSQL se ujistěte, že jste nastavili svůj pg_hba.conf a uživatele pouze na jeho specifický limit hostitele. To platí také pro MongoDB, pro které to můžete nastavit v konfiguračním souboru MongoDB nebo /etc/mongodb.conf. V MongoDB si můžete pohrát s Authentication Restrictions a nastavit clientSource nebo serverAddress, ale pouze pro ty, pro které požadujete, aby se klient nebo uživatel připojil nebo aby byl ověřen.

Řízení přístupu na základě rolí

Řízení přístupu založeného na rolích (RBAC) v databázích poskytuje pohodlný způsob správy uživatele nebo snadný způsob, jak seskupit uživatele s přiděleným oprávněním propojeným se seznamem uživatelů nebo skupinou uživatelů.

I když musíte vzít na vědomí, že role se ve všech open source databázích zachází odlišně. Například MySQL definovalo role takto,

Role MySQL je pojmenovaná kolekce oprávnění. Stejně jako uživatelské účty mohou mít role udělená a odebraná oprávnění.

Uživatelskému účtu lze udělit role, které účtu udělují oprávnění spojená s každou rolí. To umožňuje přidělování sad oprávnění účtům a poskytuje pohodlnou alternativu k udělování individuálních oprávnění, a to jak pro konceptualizaci přidělování požadovaných oprávnění, tak pro jejich implementaci.

MongoDB definuje roli s RBAC jako,

MongoDB využívá k řízení přístupu k systému MongoDB řízení přístupu založeného na rolích (RBAC). Uživateli je udělena jedna nebo více rolí, které určují přístup uživatele k databázovým prostředkům a operacím. Mimo přiřazení rolí nemá uživatel přístup do systému.

Zatímco v PostgreSQL

PostgreSQL spravuje oprávnění k přístupu k databázi pomocí konceptu rolí. Role může být chápána buď jako uživatel databáze, nebo jako skupina uživatelů databáze, v závislosti na tom, jak je role nastavena. Role mohou vlastnit databázové objekty (například tabulky a funkce) a mohou k těmto objektům přidělovat oprávnění jiným rolím, aby řídily, kdo má ke kterým objektům přístup. Kromě toho je možné udělit členství v roli jiné roli, což umožňuje členské roli používat oprávnění přiřazená jiné roli.

Koncept rolí zahrnuje pojmy „uživatelé“ a „skupiny“. Ve verzích PostgreSQL před 8.1 byli uživatelé a skupiny odlišnými druhy entit, ale nyní existují pouze role. Jakákoli role může fungovat jako uživatel, skupina nebo obojí.

I když tyto databáze implementují role specifické pro jejich použití, sdílejí koncept přidělování rolí uživateli, aby bylo možné pohodlně přidělovat oprávnění. Použití rolí umožňuje správcům databází spravovat požadované uživatele pro přihlášení nebo přístup k databázi.

Představte si, že máte seznam uživatelů, které musíte spravovat, nebo seznam uživatelů, kteří mohou být zrušeni nebo odvoláni, když už je nepotřebujete. V některých specifických případech, pokud určitá úloha vyžaduje práci, mohou správci databáze vytvořit uživatele s již zavedenými rolemi. Tito vytvoření uživatelé mohou být přiřazeni ke konkrétní roli jen na krátkou dobu a poté odvoláni, jakmile to není potřeba.

Audity také pomáhají oddělit uživatele, kteří mají podezření na zranitelnost nebo ohrožení dat, takže v takovém případě pomáhají velmi snadno spravovat uživatele s rolemi.

Systém správy uživatelů

Pokud je zabezpečení vašich dat správně řešeno a implementováno, dláždí vám cestu k úspěchu. Ačkoli neexistuje dokonalé řešení, zranitelnosti a narušení se také vždy vyvíjejí. Je to jako červ, který se neustále snaží číhat, dokud není schopen dosáhnout svého cíle prolomit vaši bezpečnost a získat přístup k vašim datům. Bez řádných nástrojů, jako jsou systémy varování nebo upozornění na jakékoli nejistoty a zranitelnosti, by bylo obtížné chránit vaše data.

ClusterControl vám pomáhá spravovat uživatele a ověřovat nebo kontrolovat uživatelská oprávnění od nástrojů pro vyrovnávání zatížení až po uživatele hlavní databáze. Nabízí také poradce a upozornění, aby vás upozornil na možná zranitelnosti nebo narušení.

Například použití MySQL/MariaDB s ProxySQL předem umožňuje import a přidávání uživatelů. Pro import uživatelů shromažďuje seznam uživatelů, kteří jsou přítomni ve vašem aktuálním clusteru MySQL/MariaDB, a nabízí vám kontrolu jeho aktuálních oprávnění. Viz níže,

Také v tomto případě může být uživatel ProxySQL rychle deaktivován, pokud taková chyba zabezpečení byl známý pro konkrétního uživatele.

ClusterControl vám také nabízí přímou správu uživatelů z vaší databáze, jako je MySQL/MariaDB nebo PostgreSQL. Pro MySQL/MariaDB můžete přejít na → Spravovat → Schémata a uživatelé.

Pro PostgreSQL: → Spravovat → Správa uživatelů.

S ClusterControl si můžete přizpůsobit upozornění pomocí poradců. Poradci jsou entity založené na skriptech, které lze upravit. Například je to v clusteru MySQL/MariaDB, jak je znázorněno níže, ke kterému lze přistupovat přes → Výkon → Poradci:

Kliknutím na tlačítko Upravit můžete upravit, jak bude ClusterControl reagovat v případě, že najde uživatele s jakýmkoli hostitelem nebo '%' nebo uživatele bez hesla. Podívejte se, jak se skript zobrazí, jakmile stisknete tlačítko Upravit.

Jakmile ClusterControl zjistí, že je spuštěn některý z těchto poradců, zobrazí se upozornění a bude také zasláno na vámi nastavený e-mail nebo pokud jsou integrována nějaká upozornění třetích stran, bude upozorněno tam také.

Závěr

Oprávnění pro přístup k databázi je jedním z hlavních cílů, které se týkají narušení dat a průniků. Pokud je uživatel vaší databáze odhalen nebo pokud existuje velká hrozba pro aktuální verzi databáze, která nebyla opravena, je šance na hacknutí nebo terč ransomwaru a krádeže velmi vysoká. Pochopení přístupových práv a nastavení správných limitů vám pomůže zmírnit nebezpečí vystavení vašich cenných dat.


  1. Kořenový uživatel MongoDB

  2. Jak správně zvýšit počet dat v mongoDB?

  3. Jak doplnit použitou paměť v Redis?

  4. Škálování Socket.IO na více procesů Node.js pomocí clusteru