TLS, reta aliro kaj SQL-rajtoj respondas al malsamaj demandoj
Ĉifri konekton, akcepti fonton kaj doni tabelon estas tri decidoj. Trapasu ilin laŭorde antaŭ ol demandi ĉu TLS povas anstataŭigi VPN-on.
Iu proponas doni al kliento PostgreSQL-an saluton, por ke elspeza postulo vojaĝu ĉifrite de unu fino al la alia. Datumbaza administranto bezonas veran SQL-sesion, kaj iu alia proponas anstataŭe retan formularon. Ambaŭ proponoj solvas la malĝustan problemon, ĉar neniu el ili komenciĝis per la operacio, kiun la kliento efektive plenumas. Trapasu la tri decidojn laŭorde kaj la demando, ĉu TLS povas anstataŭigi VPN-on, respondas sin mem.
Komencu per la operacio, kiun la kliento bezonas
Skribu, kion la kliento devas atingi. Sendi postulon, legi unu vicon de raporto kaj ruli tujan konsulton estas tri malsamaj operacioj kun tri malsamaj riskiprofiloj.
Poste skribu, kiu faras la peton. Kliento, subtena agento kaj administranto ne estas interŝanĝeblaj eĉ kiam ili tuŝas la saman tabelon. La diferenco decidas, kiom da la konsulta lingvo la kliento entute vidu.
La paro de respondoj decidas la interfacon. Ĉio poste estas efektivigo, kaj plej multaj disputoj pri ĉifrado estas fakte disputoj pri tio, kiu interfaco estis elektita.
Tri kontroloj, tri decidoj
Aŭtentikigita TLS protektas la konekton kaj decidas, kiuj TLS-identoj estas akceptataj. Reta aliro decidas, kiuj fontoj entute povas atingi la aŭskultanton. Datumbaza rajtigo decidas, kiujn objektojn kaj agojn rolo rajtas uzi.
Neniu el la tri anstataŭas la aliajn, kion la tabelo klare montras.
| 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 |
Legu la vicon, sur kiun vi fidas, antaŭ ol forigi alian. Plej multaj el ĉi tiuj dizajnoj malsukcesas ĉar kontrolo estis supozita anstataŭ agordita.
Rekta SQL lasas la datumbazan politikon respondeca
Ĉe aprobita rekta konekto, konservu kaj la kontrolon de serva idento kaj la celitan alirpolitikon. Ŝalti TLS-on igas ĉifritajn konektojn haveblaj; ĝi ne malakceptas neĉifritajn krom se la alira agordo tion postulas per hostssl-eroj.
Tiu distingo indas kontrolon en la funkcianta agordo, ne en ŝablono. Servilo, kiu proponas TLS kaj akceptas klaran tekston, ne estas la dezajno, kiun plej multaj homoj kredas ke ili deplojis. Legu la alirregulojn kaj vidu, kiuj eroj efektive postulas ĝin. Tiu unu kontrolo apartigas servilon kapablan je ĉifrado de nur ĉifrita servilo.
Uzu rolojn nur kun la privilegioj, kiujn la laboro bezonas, kaj reviziu posedon, hereditan membrecon kaj vaste donitajn permesojn. La privilegia modelo de PostgreSQL estas la aŭtoritata limo por datumbazaj objektoj.
VPN povas limigi, kiuj aparatoj atingas la servon antaŭ ol datumbaza aŭtentikigo okazas, kaj alira pordego povas fari ion similan. Neniu el ili forigas la bezonon prizorgi la elmetitan komponanton, administri akreditaĵojn kaj limigi rimeduzon.
Klientaj atestiloj estas akreditaĵo, ne ACL
Klienta atestilo povas aldoni postulon dum la konekto. La agordo clientcert povas postuli fidata atestilon kaj, en la pli strikta reĝimo, rilaton inter la atestila nomo kaj la datumbaza uzanto.
Tio estas pli forta akreditaĵo. Ĝi ne estas rajtiga listo, kaj ĝi ne igas la servilon nevidebla, ĉar la komponanto akceptanta la konekton ankoraŭ prilaboras retan trafikon kaj manpremon. Trakti atestilon kiel aliran liston lasas la fakajn permesojn netuŝitaj. Ĝi ankaŭ emas vastigi la disdonadon de atestiloj, kio kreas la sekvan problemon.
Forta atestilo ligita al troprivilegia rolo produktas bone aŭtentikigitan administranton. Kontrolu la rolon antaŭ ol festi la atestilon.
Elektu la pli mallarĝan interfacon kiam ĝi taŭgas
Por elspeza postulo, aplika finpunkto, kiu akceptas la postulon, plenumas la komercajn regulojn kaj redonas la permesitan rezulton de tiu uzanto, reprezentas la operacion pli bone ol ĝenerala SQL-konto.
La aplikaĵo tiam uzas sian propran limigitan datumbazan identon, kaj la kliento neniam ricevas konsultan lingvon kiel funkcion. Tio estas pli malgranda surfaco kun malpli da manieroj erari.
Ĉi tio estas dezajna opcio, ne aserto ke aplika kodo estas aŭtomate pli sekura. Tiu kodo devas aŭtentikigi siajn vokantojn, rajtigi ĉiun agon kaj validigi sian enigon, kaj ĝiaj propraj datumbazaj permesoj ankoraŭ gravas.
Rekta SQL restas ĝusta por homoj kaj iloj, kies aprobita laboro tion postulas. Limigu tiun dezajnon per roloj, reta amplekso kaj operaciaj limoj, kaj lasu la aliajn klientojn konservi la pli mallarĝan interfacon. Miksi la du populaciojn en unu rolo estas kie la disputoj komenciĝas.