A TLS, a hálózati belépés és az SQL-jogosultságok különböző kérdésekre válaszolnak
Egy kapcsolat titkosítása, egy forrás beengedése és egy tábla megadása három döntés. Járja végig őket sorrendben, mielőtt megkérdezné, helyettesítheti-e a TLS a VPN-t.
Valaki azt javasolja, hogy adjunk egy ügyfélnek PostgreSQL-bejelentkezést, hogy a költségigény végponttól végpontig titkosítva utazzon. Az adatbázis-adminisztrátornak valódi SQL-munkamenetre van szüksége, és valaki más helyette webes űrlapot javasol. Mindkét javaslat a rossz problémát oldja meg, mert egyik sem abból a műveletből indult ki, amelyet az ügyfél valóban végrehajt. Járja végig a három döntést sorrendben, és a kérdés, hogy helyettesítheti-e a TLS a VPN-t, magától megválaszolódik.
Kezdje azzal a művelettel, amelyre az ügyfélnek szüksége van
Írja le, mit kell az ügyfélnek elérnie. Egy igény benyújtása, egy jelentés egy sorának elolvasása és egy alkalmi lekérdezés futtatása három különböző művelet három különböző kockázati profillal.
Ezután írja le, ki nyújtja be a kérést. Az ügyfél, az ügyfélszolgálati munkatárs és az adminisztrátor nem felcserélhető akkor sem, ha ugyanazt a táblát érintik. A különbség dönti el, mennyit lásson az ügyfél egyáltalán a lekérdezési nyelvből.
A válaszpár dönti el a felületet. Minden, ami ezután következik, megvalósítás, és a titkosításról szóló viták többsége valójában arról szól, melyik felületet választották.
Három ellenőrzés, három döntés
A hitelesített TLS védi a kapcsolatot, és eldönti, mely TLS-identitások fogadhatók el. A hálózati belépés eldönti, mely források érhetik el egyáltalán a figyelőt. Az adatbázis-engedélyezés eldönti, mely objektumokat és műveleteket használhat egy szerepkör.
Egyik sem helyettesíti a másikat, amit a táblázat egyértelművé tesz.
| 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 |
Olvassa el azt a sort, amelyre támaszkodik, mielőtt eltávolít egy másikat. E tervek többsége azért bukik meg, mert egy ellenőrzést feltételeztek ahelyett, hogy beállítottak volna.
A közvetlen SQL az adatbázis-szabályzatot tartja felelősnek
Jóváhagyott közvetlen kapcsolat esetén tartsa meg a szolgáltatás identitásának ellenőrzését és a tervezett hozzáférési szabályzatot is. A TLS bekapcsolása elérhetővé teszi a titkosított kapcsolatokat; nem utasítja el a titkosítatlanokat, hacsak a hozzáférési konfiguráció hostssl-bejegyzéseken keresztül ezt nem írja elő.
Ezt a különbséget érdemes a futó konfigurációban ellenőrizni, nem egy sablonban. Egy TLS-t kínáló és egyszerű szöveget elfogadó kiszolgáló nem az a terv, amelyet a legtöbben telepítettek. Olvassa el a hozzáférési szabályokat, és nézze meg, mely bejegyzések igénylik ezt valóban. Ez az egyetlen ellenőrzés elválasztja a titkosításra képes kiszolgálót a csak titkosítottól.
Csak a munkához szükséges jogosultságokkal rendelkező szerepköröket használjon, és vizsgálja felül a tulajdonjogot, az örökölt tagságot és a széles körben megadott engedélyeket. A PostgreSQL jogosultsági modellje az adatbázis-objektumok hatáskörének határa.
A VPN korlátozhatja, mely eszközök érik el a szolgáltatást az adatbázis-hitelesítés előtt, és egy hozzáférési átjáró valami hasonlót tehet. Egyik sem szünteti meg a kitett összetevő karbantartásának, a hitelesítő adatok kezelésének és az erőforrás-felhasználás korlátozásának szükségességét.
Az ügyféltanúsítvány hitelesítő adat, nem ACL
Az ügyféltanúsítvány követelményt adhat a kapcsolódás idején. A clientcert beállítás megbízható tanúsítványt és szigorúbb módban a tanúsítvány neve és az adatbázis-felhasználó közötti kapcsolatot írhatja elő.
Ez erősebb hitelesítő adat. Ez nem engedélyezési lista, és nem teszi láthatatlanná a kiszolgálót, mert a kapcsolatot fogadó összetevő továbbra is hálózati forgalmat és egy kézfogást dolgoz fel. A tanúsítvány hozzáférési listaként kezelése érintetlenül hagyja a tényleges engedélyeket. Hajlamos továbbá kiszélesíteni a tanúsítványok terjesztését, ami a következő problémát teremti.
A túlzott jogosultságú szerepkörhöz kapcsolt erős tanúsítvány jól hitelesített adminisztrátort eredményez. Ellenőrizze a szerepkört, mielőtt ünnepelné a tanúsítványt.
Válassza a szűkebb felületet, ha az megfelel
Egy költségigény esetében az az alkalmazásvégpont, amely elfogadja az igényt, érvényesíti az üzleti szabályokat és visszaadja az adott felhasználó engedélyezett eredményét, jobban képviseli a műveletet, mint egy általános SQL-fiók.
Az alkalmazás ezután a saját korlátozott adatbázis-identitását használja, és az ügyfél soha nem kap lekérdezési nyelvet szolgáltatásként. Ez kisebb felület kevesebb hibalehetőséggel.
Ez tervezési lehetőség, nem annak állítása, hogy az alkalmazáskód automatikusan biztonságosabb. Ennek a kódnak hitelesítenie kell a hívóit, engedélyeznie minden műveletet és ellenőriznie a bemenetét, és a saját adatbázis-engedélyei továbbra is számítanak.
A közvetlen SQL továbbra is helyes azoknak az embereknek és eszközöknek, akiknek a jóváhagyott munkája ezt megköveteli. Határolja be ezt a tervet szerepkörökkel, hálózati hatókörrel és üzemeltetési korlátokkal, és hagyja, hogy a többi ügyfél megtartsa a szűkebb felületet. A két csoport egy szerepkörben való keverése az a pont, ahol a viták elkezdődnek.