TLS, síťový vstup a oprávnění SQL odpovídají na různé otázky
Šifrování spojení, vpuštění zdroje a udělení tabulky jsou tři rozhodnutí. Projděte je v pořádku, než se zeptáte, zda TLS může nahradit VPN.
Někdo navrhuje dát zákazníkovi přihlášení do PostgreSQL, aby žádost o výdaj putovala šifrovaně od začátku do konce. Správce databáze potřebuje skutečnou relaci SQL a někdo jiný místo toho navrhuje webový formulář. Oba návrhy řeší špatný problém, protože ani jeden nezačal u operace, kterou klient skutečně provádí. Projděte tři rozhodnutí v pořádku a otázka, zda TLS může nahradit VPN, si odpoví sama.
Začněte u operace, kterou klient potřebuje
Zapište, čeho má klient dosáhnout. Podání žádosti, přečtení jednoho řádku sestavy a spuštění okamžitého dotazu jsou tři různé operace se třemi různými rizikovými profily.
Pak zapište, kdo žádost podává. Zákazník, pracovník podpory a správce nejsou zaměnitelní, i když sahají na stejnou tabulku. Rozdíl určuje, kolik z dotazovacího jazyka by měl klient vůbec vidět.
Dvojice odpovědí určuje rozhraní. Všechno další je implementace a většina sporů o šifrování jsou ve skutečnosti spory o to, které rozhraní bylo zvoleno.
Tři kontroly, tři rozhodnutí
Ověřené TLS chrání spojení a určuje, které identity TLS se přijímají. Síťový vstup určuje, které zdroje se vůbec mohou dostat k naslouchajícímu procesu. Autorizace v databázi určuje, které objekty a akce smí role používat.
Žádná ze tří nenahrazuje ostatní, což tabulka ukazuje výslovně.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Přečtěte si řádek, na který se spoléháte, než odstraníte jiný. Většina těchto návrhů selhává, protože kontrola byla předpokládána, a ne nakonfigurována.
Přímé SQL nechává politiku databáze ve vedení
U schváleného přímého spojení zachovejte ověření identity služby i zamýšlenou politiku přístupu. Zapnutí TLS zpřístupní šifrovaná spojení; nezamítá nešifrovaná, pokud to konfigurace přístupu nevyžaduje pomocí položek hostssl.
Ten rozdíl stojí za kontrolu v běžící konfiguraci, ne v šabloně. Server, který nabízí TLS a přijímá otevřený text, není návrh, o kterém si většina lidí myslí, že ho nasadila. Přečtěte si pravidla přístupu a podívejte se, které položky to skutečně vyžadují. Tato jediná kontrola odděluje server schopný šifrování od serveru pouze šifrovaného.
Používejte role jen s oprávněními, která práce potřebuje, a revidujte vlastnictví, zděděné členství a široce udělená oprávnění. Model oprávnění PostgreSQL je hranicí pravomoci pro objekty databáze.
VPN může omezit, která zařízení se dostanou ke službě před autentizací v databázi, a přístupová brána může udělat něco podobného. Ani jedno neodstraňuje potřebu udržovat vystavenou komponentu, spravovat přihlašovací údaje a omezovat využití zdrojů.
Klientské certifikáty jsou údaj, ne ACL
Klientský certifikát může při připojení přidat požadavek. Nastavení clientcert může vyžadovat důvěryhodný certifikát a v přísnějším režimu vztah mezi názvem certifikátu a uživatelem databáze.
To je silnější údaj. Není to seznam autorizace a nečiní server neviditelným, protože komponenta přijímající spojení stále zpracovává síťový provoz a handshake. Zacházení s certifikátem jako se seznamem přístupu nechává skutečná oprávnění nedotčená. Také mívá tendenci rozšiřovat distribuci certifikátů, což vytváří další problém.
Silný certifikát připojený k roli s nadměrnými oprávněními vytváří dobře ověřeného správce. Zkontrolujte roli, než certifikát oslavíte.
Vyberte užší rozhraní, když se hodí
Pro žádost o výdaj aplikační koncový bod, který žádost přijme, vynutí obchodní pravidla a vrátí povolený výsledek daného uživatele, představuje operaci lépe než obecný účet SQL.
Aplikace pak používá vlastní omezenou identitu v databázi a zákazník nikdy nedostane dotazovací jazyk jako funkci. To je menší povrch s menším počtem způsobů, jak udělat chybu.
Toto je možnost návrhu, ne tvrzení, že aplikační kód je automaticky bezpečnější. Tento kód musí ověřovat své volající, autorizovat každou akci a validovat svůj vstup a jeho vlastní oprávnění v databázi stále záleží.
Přímé SQL zůstává správné pro lidi a nástroje, jejichž schválená práce to vyžaduje. Kvalifikujte tento návrh rolemi, síťovým rozsahem a provozními limity a ostatním klientům nechte užší rozhraní. Míchání obou skupin v jedné roli je místo, kde spory začínají.