TLS, tīkla piekļuve un SQL tiesības atbild uz dažādiem jautājumiem
Savienojuma šifrēšana, avota ielaišana un tabulas piešķiršana ir trīs lēmumi. Izejiet tiem cauri secībā, pirms jautājat, vai TLS var aizstāt VPN.
Kāds ierosina dot klientam PostgreSQL pieteikšanos, lai izdevumu pieprasījums ceļotu šifrēts no sākuma līdz beigām. Datu bāzes administratoram vajag īstu SQL sesiju, un kāds cits tā vietā ierosina tīmekļa veidlapu. Abi priekšlikumi risina nepareizo problēmu, jo neviens no tiem nesākās ar darbību, ko klients patiešām veic. Izejiet trim lēmumiem cauri secībā, un jautājums, vai TLS var aizstāt VPN, atbildēs pats.
Sāciet ar darbību, kas klientam ir vajadzīga
Pierakstiet, kas klientam jāsasniedz. Pieprasījuma iesniegšana, vienas atskaites rindas lasīšana un acumirklīga vaicājuma izpilde ir trīs dažādas darbības ar trim dažādiem riska profiliem.
Pēc tam pierakstiet, kas iesniedz pieprasījumu. Klients, atbalsta aģents un administrators nav savstarpēji aizstājami, pat ja viņi aizskar vienu un to pašu tabulu. Atšķirība nosaka, cik daudz no vaicājumu valodas klientam vispār būtu jāredz.
Atbilžu pāris nosaka saskarni. Viss pēc tam ir ieviešana, un lielākā daļa strīdu par šifrēšanu patiesībā ir strīdi par to, kura saskarne tika izvēlēta.
Trīs kontroles, trīs lēmumi
Autentificēts TLS aizsargā savienojumu un nosaka, kuras TLS identitātes tiek pieņemtas. Tīkla piekļuve nosaka, kuri avoti vispār var sasniegt klausītāju. Datu bāzes autorizācija nosaka, kurus objektus un darbības loma drīkst izmantot.
Neviena no trim neaizstāj pārējās, ko tabula skaidri parāda.
| 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 |
Izlasiet rindu, uz kuru paļaujaties, pirms noņemat citu. Lielākā daļa šo projektu neizdodas tāpēc, ka kontrole tika pieņemta, nevis konfigurēta.
Tiešais SQL atstāj datu bāzes politiku atbildīgu
Ar apstiprinātu tiešu savienojumu saglabājiet gan pakalpojuma identitātes pārbaudi, gan paredzēto piekļuves politiku. TLS ieslēgšana padara šifrētus savienojumus pieejamus; tā neatmet nešifrētus, ja vien piekļuves konfigurācija to neprasa ar hostssl ierakstiem.
Šo atšķirību ir vērts pārbaudīt darbojošā konfigurācijā, nevis veidnē. Serveris, kas piedāvā TLS un pieņem atklātu tekstu, nav tas projekts, kuru lielākā daļa domā, ka ir ieviesuši. Izlasiet piekļuves noteikumus un apskatiet, kuri ieraksti to patiešām prasa. Šī viena pārbaude atdala serveri, kas spēj šifrēt, no tikai šifrēta servera.
Izmantojiet lomas tikai ar tām privilēģijām, kas nepieciešamas darbam, un pārskatiet īpašumtiesības, mantoto dalību un plaši piešķirtās atļaujas. PostgreSQL privilēģiju modelis ir datu bāzes objektu pilnvaru robeža.
VPN var ierobežot, kuras ierīces sasniedz pakalpojumu pirms datu bāzes autentifikācijas, un piekļuves vārteja var darīt ko līdzīgu. Neviens no tiem neizslēdz vajadzību uzturēt atklāto komponentu, pārvaldīt akreditācijas datus un ierobežot resursu izmantošanu.
Klienta sertifikāti ir akreditācijas dati, nevis ACL
Klienta sertifikāts var pievienot prasību savienojuma laikā. Iestatījums clientcert var prasīt uzticamu sertifikātu un stingrākā režīmā saistību starp sertifikāta nosaukumu un datu bāzes lietotāju.
Tie ir spēcīgāki akreditācijas dati. Tas nav autorizācijas saraksts, un tas nepadara serveri neredzamu, jo komponente, kas pieņem savienojumu, joprojām apstrādā tīkla trafiku un rokasspiedienu. Sertifikāta uztveršana kā piekļuves saraksta atstāj faktiskās atļaujas neskartas. Tas arī mēdz paplašināt sertifikātu izplatīšanu, kas rada nākamo problēmu.
Spēcīgs sertifikāts, kas piesaistīts lomai ar pārmērīgām privilēģijām, dod labi autentificētu administratoru. Pārbaudiet lomu, pirms svinat sertifikātu.
Izvēlieties šaurāko saskarni, kad tā der
Izdevumu pieprasījumam lietojumprogrammas galapunkts, kas pieņem pieprasījumu, piemēro biznesa noteikumus un atgriež attiecīgā lietotāja atļauto rezultātu, pārstāv darbību labāk nekā vispārējs SQL konts.
Pēc tam lietojumprogramma izmanto savu ierobežoto datu bāzes identitāti, un klients nekad nesaņem vaicājumu valodu kā funkciju. Tā ir mazāka virsma ar mazāk veidiem, kā kļūdīties.
Šis ir dizaina variants, nevis apgalvojums, ka lietojumprogrammas kods automātiski ir drošāks. Tam kodam ir jāautentificē savi izsaucēji, jāautorizē katra darbība un jāvalidē sava ievade, un tā paša datu bāzes atļaujas joprojām ir svarīgas.
Tiešais SQL joprojām ir pareizs cilvēkiem un rīkiem, kuru apstiprinātais darbs to prasa. Ierobežojiet šo dizainu ar lomām, tīkla tvērumu un operatīvajām robežām, un ļaujiet pārējiem klientiem saglabāt šaurāko saskarni. Abu grupu sajaukšana vienā lomā ir vieta, kur sākas strīdi.