Jump to content

GDPR un datubāzes lauku kriptēšana


Recommended Posts

Duncan F

Klients pieprasa, lai PostgreSQL datubāzē tādi PII (personally identifiable information) lauki kā email, first_name, last_name un address glabātos nevis plaintext formā, bet būtu kriptēti. Tas tiek pamatots ar GDPR prasībām. Pēc manas saprašanas GDRP kontekstā šāda kriptēšana ir rekomendācijas līmenī un nav dotas specifiskas vadlīnijas ne kriptēšanas algoritmiem, ne arī encryption key drošai uzglabāšanai. Vieta interpretācijai. Vai esat saskārušies ar šādu klientu prasību, kā to risinājāt?

 

Vēlos īpaši uzsvērt, ka varam izdalīt divu veidu kriptēšanu. Pirmā ir database-engine-level kriptēšana, otrā ir application-level kriptēšana.

Database-engine-level kriptēšana praktiski visiem projektiem nāk defaultā. Tādos servisos kā AWS un Azure to ir viegli uzstādīt un tā netraucē programmēšanai.

Application-level kriptēšana tiek ieviesta jau backend valodas līmenī (PHP, Python, whatever), tas nozīmē, ka uz datubāzi sūta jau kriptētus laukus nevis plaintext. Tas jau sāk traucēt programmēšanai.

 

Klients ir ļoti pārliecināts, ka ar database-engine-level kriptēšanu nepietiek un mums obligāti vajag application-level kriptēšanu. Tas, protams, radīs kaut kādu overhead un sarežģīs veikt pāris darbības. Kaut vai login pēc e-pasta un paroles, jo e-pasts plaintext formā vairs nebūs datubāzē atrodams. Protams, tam visam ir workaroundi.

 

Vai tā rīkoties tagad skaitās normāla prakse? Iepriekšējos projektos ar tādu prasību neesmu saskāries, ir bijusi tikai AWS piedāvātā datubāzes šifrēšana diska līmenī un neviens par. to liekus jautājumus nav uzdevis.

  • Patīk 1
Link to post
Share on other sites
Ronalds

GDPR šādu prasību pēc šifrēšanas nav! 

 

Un application level šifrēšana ir buļļa kakas jeb drošības imitācija. 

Aplikācijā jābūt iešūtai šifrēšanas/atšifrēšanas atslēgai.  Nu vai kaut kā citādi jābūt pieejamai. Reāli tas tikai nozīmē to, ka atšifrēšanas atslēga ir gandrīz publiski pieejama.

Tas reāli sarežģīs programmēšanu un pamatīgi palēlinās aplikāciju jo servera pusē nebūs iespējams veikt datu kārtošanu, meklēšanu. 

 

Es runātu ar klientu. Mēģinātu teikt ka tas būtiski izstrādes cenu un laiku palielinās.

Link to post
Share on other sites
ieleja
1 stundu atpakaļ, Duncan F teica:

login pēc e-pasta un paroles, jo e-pasts plaintext formā

 

DB glabājas hash no e-pasta un paroles

paņem to, ko klients iebaksta, nohasho un salīdzini ar DB lauka saturu

 

Link to post
Share on other sites
uldise
Pirms 54 minūtēm , Ronalds teica:

Aplikācijā jābūt iešūtai šifrēšanas/atšifrēšanas atslēgai

šifrēšanas jā, atšifrēt - a kāpēc tas vajadzīgs?

biedrs jau iepriekšējā komentārā pierakstija.

Link to post
Share on other sites
Ronalds

Aplikācijai (lietotajam) nav šie dati jāredz? 

Nevajag te lietotāju autentifikāciju jaukt klāt. 

 

Sistēmas lietotājs un dati par klientu (piemēram) nav viens un tas pats.

Link to post
Share on other sites
uldise

jā, piekrītu, rādāmos datus šifrēt/atšifrēt tiešām neredzu jēgu.

tipa, ja kāds pamanīsies nozagt DB, tad aplikācija tāpat būs pieejama.

Link to post
Share on other sites
e = d

No klienta vajag riska novērtējumu- pret kādiem draudiem viņš grib aizsargāties, ja šādas prasības. Piedāvāt, varbūt tos var mazināt citādi?

Jo, kā jau te minēja, Regulā netiek prasīta obligāta datu šifrēšana. To ir pasniedzis kāds konsultants, visticamāk. 
Regula prasa ieviest riskam atbilstošus drošības līdzekļus, kā, piemēram, šifrēšanu. 
Ja ir sensitīvie dati, par to var domāt. 

Link to post
Share on other sites
spameris

Nu jā tā doma ka jāšifrē ir programmas līmenī manuprāt ir nedaudz dīvaina. Varbūt jāpiedomā ir pie kāda neatkarīga servisa layera, kas atļauj piekļūt applikācijai tikai tiem datiem kuriem esi autentificējies. Tb aplikācija, var piekļūt tikai konkrētā autentificētā lietotāja datiem. 

Link to post
Share on other sites
Anonīms Alkoholiķis

Kā būtu ja šifrētu visus lietotāja datus un katram lietotājam izsniegtu hsm, lai katrs pats tos varētu atšifrēt?

Link to post
Share on other sites
Duncan F
17 hours ago, Ronalds said:

GDPR šādu prasību pēc šifrēšanas nav! 

 

Un application level šifrēšana ir buļļa kakas jeb drošības imitācija. 

Aplikācijā jābūt iešūtai šifrēšanas/atšifrēšanas atslēgai.  Nu vai kaut kā citādi jābūt pieejamai. Reāli tas tikai nozīmē to, ka atšifrēšanas atslēga ir gandrīz publiski pieejama.

Tas reāli sarežģīs programmēšanu un pamatīgi palēlinās aplikāciju jo servera pusē nebūs iespējams veikt datu kārtošanu, meklēšanu. 

 

Es runātu ar klientu. Mēģinātu teikt ka tas būtiski izstrādes cenu un laiku palielinās.

 

Lai gan tas nav GDPR burtiski pateikts, tomēr šifrēšana ir vairākas reizes mīklaini pieminēta. Daudzas kompānijas/konsultanti tāpēc tagad diezgan skaļi propagandē, ka šifrēšana ir teju obligāta un visi, kas tā nedara, ir plānā galdiņa urbēji, kam nevar uzticēties kā biznesa partneriem. Tas ir sīkāk izķidāts šajā rakstā: https://www.i-scoop.eu/gdpr-encryption/

 

Var argumentēt ka tas viss ir "security theatre", bet diemžēl šis viedoklis (mīts?) jau ir iesēdies galvā lielai daļai pasūtītāju. Jautājums vai ar viņiem stīdēties, vai nē.

 

Tas, ka būtiski palielinās izstādes cenu un laik nav līdz galam patiesība. Tādiem freimworkiem kā Laravel un Rails (gan jau arī citiem) ir diezgan viegli instalējami packagi, kas šo visu darīs diezgan automātiski.

 

Galvenokārt šis ir nevis laika/cenas jautājums, bet filozofiskas dabas jautājums vai mēs tiešām šādu praksi šifrēt email un firstname drīz uzskatīsim par normālu un vispārpieņemtu?

Link to post
Share on other sites
Ronalds

Lai kaut ko šifrētu droši, ir jānodrošina droša dešifrācijas atslēgas izplatīšana. Te ir galvenā problēma! 

Tā būs web aplikačija? Šajā gadījumā takš ir https protokols un vēl ko papildus šifrēt sakaru kanāla aizsardzībai ir lieki!

Tipa baidās ka db nodumpos? Pret kādiem riskiem ir mērķis aizsargāties? 

Jo ja uzlauzīs serveri un tiks pie db, tad visticamākais tiks arī pie dešifrācijas atslēgas.

 

Bet nu grūti kaut ko argumentēt cilvēkiem, kuri ko ieņēmuši galvā un kuri maz ko saprot no šifrēšanas un programmēšanas.

Link to post
Share on other sites
Duncan F
12 minutes ago, Ronalds said:

Lai kaut ko šifrētu droši, ir jānodrošina droša dešifrācijas atslēgas izplatīšana. Te ir galvenā problēma! 

Tā būs web aplikačija? Šajā gadījumā takš ir https protokols un vēl ko papildus šifrēt sakaru kanāla aizsardzībai ir lieki!

Tipa baidās ka db nodumpos? Pret kādiem riskiem ir mērķis aizsargāties? 

Jo ja uzlauzīs serveri un tiks pie db, tad visticamākais tiks arī pie dešifrācijas atslēgas.

 

Bet nu grūti kaut ko argumentēt cilvēkiem, kuri ko ieņēmuši galvā un kuri maz ko saprot no šifrēšanas un programmēšanas.

 

https protoklu gan tu te iepini pilnīgi ne pa ķeksi.

Galvenās bailes ir - kāds kaut kā iegūs database dump. Un ir cerība, ka šis kaut kā automātiski nav devis pieeju arī pie vietas, kur glabājas encryption key.

 

Vispār jau kaut kāda neliela loģika tur ir. Visbiežāk datubāze nav publiski pieejama, lai tiktu tai klāt ir vispirms jāslēdzas ar SSH tuneli pie kāda servera, kas ir tajā pašā tīklā, kur datubāze. Te ir divi varianti - vai nu tas serveris ir tas pats, kur stāv kods un encryption key, vai arī tas ir principā tukšs serveris bez koda, tikai ar pieeju pie datubāzes. Ja hakeri iegūst pieeju tam otrajam, tad ir drošības ieguvums - db dumpu ieguva, bet encryption key nav izdevies iegūt.

 

Un nevajag jau arī izlikties, ka db dumpi nekur nekad nevienam nenoplūst. Vai tik tuvākais un smieklīgākais piemērs nav pats boot forums? Taču ir arī lielāki. Patreon, piemēram.

Link to post
Share on other sites
pirms 19 stundām , Duncan F teica:

Vai tā rīkoties tagad skaitās normāla prakse?

mistiski pieminētā šifrēšana GDPR vēl būtu viena lieta, jautājums drīzāk cits:

kā risinājumā / infrastruktūrā / klienta uzņēmumā plānots realizēt GDPR prasību 72 stundu laikā pēc drošības incidenta atklāšanas noziņot tieši kuru un tieši kādi klienta dati aizgājuši? (kāda ir vispārējā klienta datu apstrādes politika, nevis papīros, bet pēc būtības?)

 

un tad, serveri un procesi, fiziski un klaudā, un (pamatoti) baidāmies no uzlaušanas un dumpa, kā tiek plānots to visu izmeklēt? (aktivitāšu log uzkrāšanas un analīzes risinājumi, lietotāju akountu tiesību menedžmenta sistēmas un tā tālāk, un tjp.)

Link to post
Share on other sites
uldise
Pirms 23 minūtēm , Duncan F teica:

Galvenās bailes ir - kāds kaut kā iegūs database dump. Un ir cerība, ka šis kaut kā automātiski nav devis pieeju arī pie vietas, kur glabājas encryption key.

te jau iepriekš jautāja - kā ir paredzēts atkodēšanas atslēgu management? tā būš iešūta pašā aplikācijā, jeb izdalīta speciāli katram tās lietotājam? db dumpum tikt klāt būs krietni grūtāk, kā minētajai atslēgai - ja jau noplūst db dump, tad atslēga jau būs noplūdusi pirms tam jau.

Link to post
Share on other sites

Uzskaitītie lauki nav uzskatāmi par sensitīviem GDPR izpratnē un datubāzes līmeņa šifrēšana būtu vairāk nekā samērīgs pasākums šajā gadījumā.

Drošība ir pretēji proporcionāla funkcionalitātei un jo vairāk aizbīdņus saliek durvīm pret zagļiem, jo lielāka iespēja pašam sadegt ugunsgrēka laikā.

Jebkura šifrēšana ietekmēs sistēmas veiktspēju, palēninās izmaiņu ieviešanu un problēmu cēloņu meklēšanu, bez tam pazaudētu atslēgu gadījumā var palikt bez datiem.

 

Drīz nāks kvantu datori un vairums esošo šifrēšanas algoritmu kļūs bezjēdzīgi :pleasantry:

Link to post
Share on other sites
AndrisBB
pirms 2 stundām , Ronalds teica:

Jo ja uzlauzīs serveri un tiks pie db, tad visticamākais tiks arī pie dešifrācijas atslēgas.

 

Vaitad applikāciju un db tur uz viena servera? Parasti jau kautkādā atsevišķā kontenerā katrs griežās. Nu ja kautkāda sīklapa un slinkums čakarēties, tad jau var. Kautvai tīri no menedžēšanas viedokļa vieglāk updateidot/upskeilot vienu, neaiztiekot otru.

Lai no/atšifrētu lietotājdatus jaunu nekādus būtiskus resursus nepatērēs salīdzinot ar tipusku datu apjomu ko aizņem pārējie dati.

Kā jau te teica no programmēšanas viedokļa tur nekas nemainas, vainu izmanto jau esošus freimworkus, vainu pats uztaisa kautkādu nelietu abstrakciju un no pašās web applikākijas skatu punkta nekas nemainas.

Edited by AndrisBB
Link to post
Share on other sites
Ronalds
Pirms 6 minūtēm , AndrisBB teica:

Kā jau te teica no programmēšanas viedokļa tur nekas nemainas,

Jā? 

Varēs taisīt pieprasījumus "order by email", "where email like...." utt, utjp. Varēs indeksus db veidot? 

Sanāk ka lai ko atrastu vai sakārtotu visi dati būs jādzen uz klientu... 

Link to post
Share on other sites
AndrisBB

Klientam nevar būt ID? Kapēc pēc emaila kautkas jāmeklē?

Edited by AndrisBB
Link to post
Share on other sites
uldise
Just now, Ronalds teica:

Sanāk ka lai ko atrastu vai sakārtotu visi dati būs jādzen uz klientu..

nu, vai arī uz slāni pa vidu, ja tādu uztaisīs.. jēgu joprojām īsti neredzu..

Link to post
Share on other sites
Anonīms Alkoholiķis

Vai klients nav prasījis aizsargāt arī datu pārraides kanālu? Jūs ethernet/optikas kabeļus liekat metāla caurulēs (arī no rūtera uz darbstacijām) vai ar piekaramo atslēgu pieslēdzat pie ieskrūvētiem enkuriņiem sienās?

Link to post
Share on other sites
AndrisBB

Ja klients kautko vēlas un ar mieru maksāt, tad kapēc uzdot muļķīgus jautājumus un atteikties no naudas?

  • Patīk 1
Link to post
Share on other sites
Pirms 32 minūtēm , AndrisBB teica:

Ja klients kautko vēlas un ar mieru maksāt, tad kapēc uzdot muļķīgus jautājumus un atteikties no naudas?

te gan izskatās, ka klients vēlas "daudz", un ir ar mieru maksāt "kaut ko" .

vēl nav zināms, ar ko tas var beigties, ja neuzdod "muļķīgus" jautājumus.

Link to post
Share on other sites
Mezavecis

 Galvenā problēma ir ātrdarbība. Piemēram, realizēt meklēšanu daudzu simtu klientu datu bāzē ir īsts pārbaudījums. Ja vēl klients tāds taupīgs un uz serveri ietaupījis, tad pēc tam nāks sūdzēties, ka sistēma lēna un līkrocis taisījis sistēmu. Kāpēc čakarēt sev reputāciju realizējot greizus risinājumus, par kuriem, iespējams, būs jāklausās pārmetumi par nekompetenci.

Link to post
Share on other sites
AndrisBB

Kur tur ir kautkas minēts par maksāšanu/nemaksāšanu?

Klients izskatās zin konkrēti ko vinš grib. Attiecīgi arī atblid, cik tas maksās.

Kur problēma?

 

 

Pirms 4 minūtēm , Mezavecis teica:

būs jāklausās pārmetumi par nekompetenci.

Kur problēma to visu uzskaitīt riskos vai iespējamos performances pudeles kakliņos? 

Bet nu mūsdienās ar zināmām serveru jaudām, tad parasti ir tikai x eiro vairāk un problēma atrisināta.

Edited by AndrisBB
Link to post
Share on other sites
e = d

Drošs risinājums būs datu bāze ar pilno šifrēšanu uz servera(TDE), atslēgas tiek glabātas HSMā, starp DB un aplikāciju ir uzlikts datu bāzu firewall specializētais. Katram no šiem objektiem ir cits administrators. HSM inicializācijai nepieciešamas divas atslēgas, no kurām viena glabājas pie uzņēmuma bosa.

Link to post
Share on other sites
AndrisBB

Drōši vien jau ka problēma šeit ir ka datu bāzes nozagšanas gadījumā var sasaistīt emailu ar vārdu/uzvārdu.

Pēctam sūtīt spamu vai izmantot citiem mērķiem.

Link to post
Share on other sites
Mezavecis
Pirms 11 minūtēm , AndrisBB teica:

Kur problēma to visu uzskaitīt riskos vai iespējamos performances pudeles kakliņos? 

Tu vari uzskaitīt jebko, sastādīt riskus enciklopēdijas biezumā, bet klients parastais parasti šo visu pēc mēneša būs aizmirsis un izstrādātājs būs vainīgs. Ņemot vērā šo dīvaino prasību šifrēt epastus, acīmredzot, tur pēc tam daudz nāksies skaidroties, jo viņš neatšķir DB no front end. 

 

Link to post
Share on other sites
spameris

 

Pirms 15 minūtēm , e = d teica:

Drošs risinājums būs datu bāze ar pilno šifrēšanu uz servera(TDE), atslēgas tiek glabātas HSMā, starp DB un aplikāciju ir uzlikts datu bāzu firewall specializētais. Katram no šiem objektiem ir cits administrators. HSM inicializācijai nepieciešamas divas atslēgas, no kurām viena glabājas pie uzņēmuma bosa.

Da lab, topika autors neteica ka plāno hostēt narko kartelim servisus, un skatos uz visiem šitiem ar baigajām aizdomām ka visas tās uber kriptēšanas arī ir diezgan liela iespēja palikt vispār bez datiem ja kautkas noiet greizi.

 

Drošais tīkls<-->web serveris<--klients

[DB<-->API<--API GW]<-->[WEB serveris]-->brauzeris

 

1. autentificēts klients var veikt tikai sava lietotāja konetkstā API call, nekādi SQL no web servera uz DB, tikai API

2. API GW ir whitelistoti pieprasījumi

3. API GW monitorings kliedz ja pārāk daudz visādas kļūdas tiek spamotas

 

tb, doma ja web krīt, tad tas nenozīmē DB dump.

 

Edited by spameris
Link to post
Share on other sites
Duncan F

Klients ir tehniski ļoti kompetents un maksātspējīgs, tur nav ko piekasīties. Nav galīgi no sērijas "neatšķir DB no frontenda". Projekts patiesībā jau vairākus mēnešus ir izstrādes stadijā, tikai tagad nejauši pacēlās diskusija par privātumu. Izdiskutējām arī to, ka šī kriptēšana palīdzēs tikai pret diezgan specifiskiem scenārijiem, kuros dumps ir noplūdis bez encryption key iesaistes. Klients to saprot.

 

Jebkurā gadījumā, sausais atlikums pagaidām no jūsu atbildēm - mūsu reģionā šādu kriptēšanu neuzskata par normu, vismaz ne pagaidām. Tas arī ir galvenais, ko gribēju uzzināt. Citādi šķita, ka esmu kaut ko palaidis garām.

 

Neskatoties uz to visu, konkrētajam projektam kriptēšanu tomēr ieviesīsim. Klients būs laimīgāks un būs iespēja papildināt savu pieredzi...

Link to post
Share on other sites
AndrisBB
Pirms 5 minūtēm , Duncan F teica:

mūsu reģionā šādu kriptēšanu neuzskata par normu, vismaz ne pagaidām

Nu te jau neviens kurš "cērt drēbi" neatbildēja. Vairāk tādi amatieri, tapēc īpaši jau tās atbildes nav jēga ņemt vērā.

Link to post
Share on other sites
Duncan F
4 minutes ago, AndrisBB said:

Nu te jau neviens kurš "cērt drēbi" neatbildēja. Vairāk tādi amatieri, tapēc īpaši jau tās atbildes nav jēga ņemt vērā.

 

Diemžēl ir maz tādu online vietu/forumu, kur padiskutēt par programmēšanu ar Latvijā bāzētiem cilvēkiem, kas "cērt drēbi". Jāizlīdzās ar to, kas ir.

Link to post
Share on other sites
Mezavecis
Pirms 15 minūtēm , Duncan F teica:

mūsu reģionā šādu kriptēšanu neuzskata par normu, vismaz ne pagaidām

Viss atkarīgs no datiem un cik tie sensitīvi. E-pasts, vārds, uzvārds nekādīgi neatbilst šādam drošības līmenim. Esmu taisījis šajā reģionā risinājumu, kur dati bija šifrēti (finanšu informācija), tāpēc zinu, ar kādām problēmām jāsaskaras. Kā jau minēju, galvenā problēma ir ātrdarbība un katrai vienkāršai darbībai pēc tam jātaisa savs algoritms datu apstrādei priekš front-end.  

 

Pirms 2 minūtēm , Duncan F teica:

Diemžēl ir maz tādu online vietu/forumu, kur padiskutēt par programmēšan

Ar īstiem programmētājiem nav par ko runāt  - katrs maļ savu maļāmo par savu tēmu un jēgas nekādas. Ja vēl sastopas Linux vs MS programmētājs, tad villa pa gaisu.

  • Haha 1
Link to post
Share on other sites
spameris
Pirms 11 minūtēm , Duncan F teica:

 

Diemžēl ir maz tādu online vietu/forumu, kur padiskutēt par programmēšanu ar Latvijā bāzētiem cilvēkiem, kas "cērt drēbi". Jāizlīdzās ar to, kas ir.

Man gan šķiet ka tev pats funktieris nav īsti pareizs, ja webs ir publisks, tad uzskati, ka viņš var tikt nogāzts, kautvai visādos freimworkos mēdz būt caurumi, kautkas var izslīdēt cauri staiskajai koda analīzet, arī pat ja web requesti ir whitelistoti, kautkas cauri var izslīdēt. Un ja webs runā ar DB pa tiešo caur SQL tad ir ļoti grūti aizsargāties no datu noplūdes ja uzbrucējs ir ticis tik tālu, ka var kautko izpidīt uz web servera, kaut ar datu šifrēšanu. Tāpēc arī zīmēju shēmu, kā no tā mēģināt izvairīties.

Edited by spameris
Link to post
Share on other sites
Duncan F
1 minute ago, spameris said:

Un ja webs runā ar DB pa tiešo caur SQL tad ir ļoti grūti aizsargāties no datu noplūdes ja uzbrucējs ir ticis tik tālu, ka var kautko izpidīt uz web servera, kaut ar datu šifrēšanu.

 

Nē, es neesmu tas tips, kurš vēl joprojām lieto php 5.x un lipina kopā raw sql ar mysql_xxxx funkcijām. Mums ir normāls ORM, datubāze uz atsevišķa servera un visi citi modernie jaukumi.


6 minutes ago, Mezavecis said:

Viss atkarīgs no datiem un cik tie sensitīvi. E-pasts, vārds, uzvārds nekādīgi neatbilst šādam drošības līmenim. Esmu taisījis šajā reģionā risinājumu, kur dati bija šifrēti (finanšu informācija)

 

Pagaidām es tev piekrītu, bet nebrīnīšos, ja paies pāris gadi un tā daļa par e-pastu, vārdu, uzvārdu vairs nebūs taisnība.

Link to post
Share on other sites
spameris
Pirms 1 minūtes , Duncan F teica:

 

Nē, es neesmu tas tips, kurš vēl joprojām lieto php 5.x un lipina kopā raw sql ar mysql_xxxx funkcijām. Mums ir normāls ORM, datubāze uz atsevišķa servera un visi citi modernie jaukumi.

un kā tas palīdz ja tiec pie DB connection stringa. un vari izpildīt php.

Edited by spameris
Link to post
Share on other sites
Duncan F
4 minutes ago, spameris said:

un kā tas palīdz ja tiec pie DB connection stringa.

Es jau iepriekš izklāstīju vienu scenāriju... Visbiežāk programmētāji nevar datubāzei pieslēgties pa taisno. Vispirms ir ar SSH jāpieslēdzas kādam serverim, kurš var tālāk pieslēgties datubāzei.

Vienkāršākajā variantā uz šī palīgservera stāv aplikācijas kods ar encryption key, bet var uztaisīt arī tā, ka ir speciāls (tukšs) serveris, kas paredzēts tikai, lai pieslēgtos datubāzei. Ja "hakeris" iegūst piekļuvi šim tukšajam serverim, tad hakera rīcībā būs DB dumps, bet ne encryption key.

 

Serverim, uz kura stāv encryption key, pieslēgties var tikai kaut kāds automatizētais deploy pipeline. Kā arī uzņēmuma devops persona. Pārējie mirstīgie pie datubāzes slēdzas caur "tukšo" serveri.

Edited by Duncan F
Link to post
Share on other sites
spameris
Pirms 1 minūtes , Duncan F teica:

Es jau iepriekš izklāstīju vienu scenāriju... Visbiežāk programmētāji nevar datubāzei pieslēgties pa taisno. Vispirms ir ar SSH jāpieslēdzas kādam serverim, kurš var tālāk pieslēgties datubāzei.

Vienkāršākajā variantā uz šī palīgservera stāv aplikācijas kods ar encryption key, bet var uztaisīt arī tā, ka ir speciāls (tukšs) serveris, kas paredzēts tikai, lai pieslēgtos datubāzei. Ja "hakeris" iegūst piekļuvi šim tukšajam serverim, tad hakera rīcībā būs DB dumps, bet ne encryption key.

man liekas, ka mēs pa dažādām lietām runājam, es vismaz par iedomātu publisku  web lapu kurai slēdzas kautkādi lietotāji un kur serviss izpilda SQL  nevis par developeriem, no kuriem ja gribi vari sargāt to DB.

Link to post
Share on other sites
Duncan F
2 minutes ago, spameris said:

man liekas, ka mēs pa dažādām lietām runājam, es vismaz par iedomātu publisku  web lapu kurai slēdzas kautkādi lietotāji un kur serviss izpilda SQL  nevis par developeriem, no kuriem ja gribi vari sargāt to DB.

 

Mēs runājam par vienu un to pašu. Ir publiski pieejama web sistēma (kauns to saukt vienkārši par "lapu"). Parastie lietotāji to izmanto caur savu web browseri.

Paralēli ir izstrādes komanda, kādi 5 developeri, kas ik pa laikam pievieno jaunas fīčas un, citastarpā, arī piekļūst produkcijas datubāzei (monitorēšana, debugging).

Potenciāli ir arī sneaky hakeris, kas meklē veidus, kā nozagt informāciju datubāzē.

 

Kā nu sagadās kā nē, hakeris atrod veidu, kā pieslēgties serverim pa to pašu ceļu, ko izmanto sistēmas izstrādātāji.

Ja runa iet par serveri ar kodu un encryption key, tad sūdi ir lieli, jo hakeris var dekriptēt visu datubāzes saturu.

Ja runa iet par "tukšo" serveri, kam piekļuve ir tikai pie datubāzes, tad hakera rīcībā ir kriptēta datubāze ir mazākām malicious pielietošanas iespējām.

Link to post
Share on other sites
spameris
Pirms 1 minūtes , Duncan F teica:

 

Mēs runājam par vienu un to pašu. Ir publiski pieejama web sistēma (kauns to saukt vienkārši par "lapu"). Parastie lietotāji to izmanto caur savu web browseri.

Paralēli ir izstrādes komanda, kādi 5 developeri, kas ik pa laikam pievieno jaunas fīčas un, citastarpā, arī piekļūst produkcijas datubāzei (monitorēšana, debugging).

Potenciāli ir arī sneaky hakeris, kas meklē veidus, kā nozagt informāciju datubāzē.

 

Kā nu sagadās kā nē, hakeris atrod veidu, kā pieslēgties serverim pa to pašu ceļu, ko izmanto sistēmas izstrādātāji.

Ja runa iet par serveri ar kodu un encryption key, tad sūdi ir lieli, jo hakeris var dekriptēt visu datubāzes saturu.

Ja runa iet par "tukšo" serveri, kam piekļuve ir tikai pie datubāzes, tad hakera rīcībā ir kriptēta datubāze ir mazākām malicious pielietošanas iespējām.

Nu tas tak ir normāli, ka nevar tikt pa tiešo tikt produkcijas DB. Un es tev stāstu kā izvairīties no:

 

""Ja runa iet par serveri ar kodu un encryption key, tad sūdi ir lieli, jo hakeris var dekriptēt visu datubāzes saturu."

 

un ja tie dati tiešām ir tik svarīgi tad nāksies likt malā visus laraveļu SQL ORMus.

 

 

 

 

Link to post
Share on other sites
Raimonds1

Katram kodu kalkulatoru un speciālu datoru, kur kodēšana notiek dzelžu līmenī.

Tā, lai nu nekā nevar tai datu bāzei tikt klāt.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...