Jump to content

GDPR un datubāzes lauku kriptēšana


Duncan F
 Share

Recommended Posts

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

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.

man šī bilde rāda kaut ko ne to.

tip ja hakeris atradis veidu (pacēlis savas tiesības vidē) tik tālu ka darbojas kā izstrādātājs, visticamākais tad viņš var netraucēti darīt "dajebko" .... kriptēt, dekriptēt, mainīt, pārvietot :)

ja klientam nav (vai autõrs nav pateicis ka ir) automatizētu sistēmu vietā, kam uzdevums šādas darbības noteikt, atsekot, novērst, ja tur viss ir tikai uz cilvēciskā faktora - admin grupa, lietotāji, un viņu tiesības, tad.... kādi vēl kodu kalkulatori :)

(piedodiet, es ne profesionālis, es mimokrokodil)

 

 

 

 

Link to comment
Share on other sites

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

 

Man laikam ir problēmas ar uztveri, tāpēc būs jāpārjautā - ko konkrēti tu man "izstāstīji" par šo scenāriju?

Vienīgais izvairīšanās scenārijs ko redzu šajā diskusijā ir manis paša ieteiktais.

Svarīgajiem  datiem nav piekļuve publiskajam serverim vispār izmantojot SQL, tikai API. Kad klients ir autentificējies piemēram izmantojot OAuth, vai OpenID tad web serverim ir šī te klienta JWT tokens, kuru ir parakstījis autentifikācijas serveris. Tālāk ar šo te tokenu web serveris dodas pie API GW, kurš novalidē tokena parakstu un paskatās kādam klientam ir izsniegts šis te tokens. API GW pieliek klāt kautvai backenda API UserID paramteru un API ļauj tikai strādāt ar šī kliejnta datiem.

 

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

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

 

TIeši tāpat kā FB un citi publieskie autentificētāji, tu tak tiec tikai pie saviem datiem nevis vari maukt SQL pa facebook. Tikai tas tavs API ir privāts. Cik tu tur aizmugurē uzticies koderiem tas ir cits stāsts, par DB šifrēšanām utt...

Labots - spameris
Link to comment
Share on other sites

Te ir mēģināts pasargāties no DB kā faila noplūdes.

Advancētā gadījumā - šifrēšanas atslēga stāv spec. iekārtā  (HSM hardware Security Module) kas visu kriptē un dekriptē, iekšā tikt viņai nevar. 

Atslēgu no turienes ārā dabūt nevar , viņa var būt arī dalīta (nevienam nav pilnas atslēgas).

 

 

 

 

Link to comment
Share on other sites

Pag? Te tiek Pentagonam sistēma izstrādātā? :D 

 

Normāli developeriem nav pieejas pie produkcijas vides. Developeri strāda savā vidē, kur ja arī ir klienta dati, viņi tiek sabojāti, randomizēti - piemēram epasti un personas kodi aizstāti ar nejaušām virknēm. 

  • Patīk 1
Link to comment
Share on other sites

9 minutes ago, spameris said:

Svarīgajiem  datiem nav piekļuve publiskajam serverim vispār izmantojot SQL, tikai API. Kad klients ir autentificējies piemēram izmantojot OAuth, vai OpenID tad web serverim ir šī te klienta JWT tokens, kuru ir parakstījis autentifikācijas serveris. Tālāk ar šo te tokenu web serveris dodas pie API GW, kurš novalidē tokena parakstu un paskatās kādam klientam ir izsniegts šis te tokens. API GW pieliek klāt kautvai backenda API UserID paramteru un API ļauj tikai strādāt ar šī kliejnta datiem.

 

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

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

 

TIeši tāpat kā FB un citi publieskie autentificētāji, tu tak tiec tikai pie saviem datiem nevis vari maukt SQL pa facebook. Tikai tas tavs API ir privāts. Cik tu tur aizmugurē uzticies koderiem tas ir cits stāsts, par DB šifrēšanām utt...

 

Tas ir apbrīnojami, kā tu tur riņķī apkārt kaut ko mal... Pamanījies pat JWT tokenus vēl iesaistīt. Es pat nezinu, ko lai atbildu. Varbūt izlasi vēlreiz visu diskusiju no paša sākuma, citādi tālāk runāt nav vērts.


1 minute ago, Ronalds said:

Normāli developeriem nav pieejas pie produkcijas vides.

 

Programmētājiem normāli ir read-only pieeja pie produkcijas datubāzes. Debugging, monitorēšana utt. Ja vien tā nav tevis pieminētā Pentagona sistēma.


7 minutes ago, zeds said:

Te ir mēģināts pasargāties no DB kā faila noplūdes.

Advancētā gadījumā - šifrēšanas atslēga stāv spec. iekārtā  (HSM hardware Security Module) kas visu kriptē un dekriptē, iekšā tikt viņai nevar. 

Atslēgu no turienes ārā dabūt nevar , viņa var būt arī dalīta (nevienam nav pilnas atslēgas).

 

Jā, ļoti precīzi. HSM gan mums nebūs, būs kaut kas vienkāršāks.

Link to comment
Share on other sites

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

 

Tas ir apbrīnojami, kā tu tur riņķī apkārt kaut ko mal... Pamanījies pat JWT tokenus vēl iesaistīt. Es pat nezinu, ko lai atbildu. Varbūt izlasi vēlreiz visu diskusiju no paša sākuma, citādi tālāk runāt nav vērts.

Piedod, bet tu nerubī fišku par datu drošību. Tu mēģini kautko sargāt, no developeriem, bet publiskā daļa paliek slikti aizsargāta, un nekādi neizglābs no dampa ja web kritīs...

Labots - spameris
Link to comment
Share on other sites

5 minutes ago, spameris said:

publiskā daļa paliek slikti aizsargāta, un nekādi neizglābs no dampa ja web kritīs...

 

Uz kāda pamata tu secini, ka publiskā daļa ir slikti aizsargāta?
Ko precīzāk nozīmē "webs kritīs"?

Laikam joprojām uzskati mani par php 5.x mysql_xxx funkciju lietotāju un sql injekciju perēkli.

Link to comment
Share on other sites

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

Programmētājiem normāli ir read-only pieeja pie produkcijas datubāzes.

Pietiktu ar proxy serveri, kuram ir pieeja DB un caur FW un atsevišķā iekšējā tīklā ir pieejams web serverim. Respektīvi, webs neko nezina par tāda DB servera esamību. Jebkura cita konfigurācija bez HSM izmantošanas noved pie iespējas nospert atslēgu un tāpat dabūt datus. Nevajag dump, lai varētu kačāt datus. Savulaik Neo no VID EDS gigabaitus izkasīja. 

Link to comment
Share on other sites

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

 

Uz kāda pamata tu secini, ka publiskā daļa ir slikti aizsargāta?
Ko precīzāk nozīmē "webs kritīs"?

Laikam joprojām uzskati mani par php 5.x mysql_xxx funkciju lietotāju un sql injekciju perēkli.

Man tak vienalga kā tu tur būvē. Es vienkārši tev stāstu, kā "enterpraiza" līmeņa applikācijas tiek būvētas. Bet apgalvot, ka izmantotajā freimworkā nekad, nekad neatradīs kādu caurumu nav īpaši prātīgi.

Link to comment
Share on other sites

7 minutes ago, spameris said:

Man tak vienalga kā tu tur būvē. Es vienkārši tev stāstu, kā "enterpraiza" līmeņa applikācijas tiek būvētas. Bet apgalvot, ka izmantotajā freimworkā nekad, nekad neatradīs kādu caurumu nav īpaši prātīgi.

 

Nevienā brīdī ne ar pušplēstu vārdu neesmu kaut ko tādu apgalvojis, tāpēc aicināšu vēlreiz pārlasīt diskusiju no paša sākuma, paldies. Par to, kurš no mums kuram varētu pastāstīt, kā būvējamas scalable enterprise sistēmas arī vēl varētu pastrīdēties.

Link to comment
Share on other sites

Pirms 2 minūtēm , ieleja teica:

 

@Duncan F

 

tā ir mūsu foruma "fiška", tu kaut ko pajautā par savu sistēmu, problēmu, bet pēc pāris stundām tu jau "esi stulbenis, kas neko nesaprot"

 

var jau neņemt vērā to ko es tur rakstīju, jo ne visur tāda datu aizsardzība ir vajadzīga, jābūt samērīgumam, ne jau es sāku par personālijām runāt, ka es tur kautko maļot un ko vēl, sūta ko nu vēl tur pārlasīt, viņam tur ORMi, neuzlaužams cietoksnis,  paiplaini:D ... pietiktu ar paldies, esošā publiskā daļa manam web ir pietiekoši aizsrgāta. 

Link to comment
Share on other sites

4 hours ago, spameris said:

var jau neņemt vērā to ko es tur rakstīju, jo ne visur tāda datu aizsardzība ir vajadzīga, jābūt samērīgumam, ne jau es sāku par personālijām runāt, ka es tur kautko maļot un ko vēl, sūta ko nu vēl tur pārlasīt, viņam tur ORMi, neuzlaužams cietoksnis,  paiplaini:D ... pietiktu ar paldies, esošā publiskā daļa manam web ir pietiekoši aizsrgāta. 

 

Mīļo cilvēk, tā vietā lai runātu par datubāzes satura kriptēšanas lietderību tu man atreferēji single page application darbību, tiki līdz JWT tokeniem un sql injections. Tās visas ir ar web programmēšanu saistītas lietas, tomēr ar tēmas būtību pilnīgi nesaistītas un bezjēdzīgi šeit iepītas.

Labots - Duncan F
Link to comment
Share on other sites

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

 

Mīļo cilvēk, tā vietā lai runātu par datubāzes satura kriptēšanas lietderību tu man atreferēji single page application darbību, tiki līdz JWT tokeniem un sql injections. Tās visas ir ar web programmēšanu saistītas lietas, tomēr ar tēmas būtību pilnīgi nesaistītas un bezjēdzīgi šeit iepītas.

 

OpenID ir vairāki autorizācijas flowi , tikai implicit flow izmanto single page application, parasti ir authentification flow kur JWT nenonāk nemaz klienta brauzerī, bet vispirms web backendā. Ja ir mikroservisu arhitektūra, tad tas JWT tokens tiek sūtīts no viena servisa uz otru, kā atslēga, lai varētu tikt pie konkrētā lietotāja datiem, tie servisi pat var būt tur virknē, kur viens API izsauc nākamo utt.... API->API-API kur kā jau es teicu tiek lietots JWT. Ja ir liela sistēma, un ar paaugstinātām drošības prasībām tā kā tu saki taisīt nedrīkst. Bet kā jau es teicu ne visur tas vajadzīgs.

 

 

https://developers.onelogin.com/openid-connect

Link to comment
Share on other sites

10 hours ago, spameris said:
Ja ir liela sistēma, un ar paaugstinātām drošības prasībām tā kā tu saki taisīt nedrīkst.

 

Es pagaidām vēl pilnīgi neko neesmu teicis par aplikācijas arhitektūru, ir/nav SPA, ir/nav mikroservisi, tāds vai šitāds auth flow, katram servisam sava datubāze vai kopēja utt. Kāda tam visam šobrīd nozīme? Jautājums vai kriptēt datubāzes saturu ir ļoti vispārīgs un neatkarīgs no tādām lietām vai tev ir liela monolītiska datubāze vai arī katram mikroservisam sava. Visas kopējās sistēmas drošība ir pārāk plašs topiks un par to ir neproduktīvi runāt, es gribētu koncentrēties konkrēti uz datubāzes kriptēšanu, citādi veidojas derailed diskusija.

Link to comment
Share on other sites

Ar klientu ir runāts par kopējo risinājumu? Ir manīti visādi pseidovarianti, kur atslēga mētājās citā tabulā, konfigā vai citā DB. Minēju VID EDS piemēru, ka dati var būt šifrēti visos iespējamos veidos, bet to iegūšanai pietiek ar identificatoru un zūd jēga visiem papildus pasākumiem, ja atstāti caurumi. Ir arī pieredzēta otra galējība - dati pakāsti dēļ tā, ka atslēga nozaudēta, jo nav pienācīgi uzglabāta.

Link to comment
Share on other sites

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

gribētu koncentrēties konkrēti uz datubāzes kriptēšanu, citādi veidojas derailed diskusija

Tak atbildēja jau pirmajā lapā - GDPR dēļ šifrēšana nav vajadzīga. Tā ir svarīga, ja novērtējot kopējo sistēmas drošību, tiek identificēti riski, kurus citām metodēm var novērst tikai daļēji un atlikušais risks ir nepieņemams.

  • Patīk 2
Link to comment
Share on other sites

2020.09.21. , 14:56, Duncan F teica:

 

.....

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

.....

 

pirms 13 stundām , Duncan F teica:

 

Es pagaidām vēl pilnīgi neko neesmu teicis par aplikācijas arhitektūru, ir/nav SPA, ir/nav mikroservisi, tāds vai šitāds auth flow, katram servisam sava datubāze vai kopēja utt. Kāda tam visam šobrīd nozīme? 

 

 

Es tikai tev stāstu kā izvairīties no augstāk minētā scenārija un viss. Es būvēju sistēmu/as kurās ir vairāki miljoni lietotāji  un transakciju skaits vairāki desmiti miljardi un mēģinu iestāstīt kādus principus vajadzētu primāri ievērot, kā vājā vieta ir ORM/SQL no publiskās daļas (kurus tu pats pieminēji)  Kā vienu no opcijām minēju JWT, jeb visiem datiem jābūt tikai lietotāja kontekstā no publiskās daļas un izmantojot API(+api ir izsekojams, logojams un monitorējams daudz vieglāk), lai neietu cauri visādi NEO varianti utt... Un atkal atkārtošos, negiribi neievēro un arī drošībā jāievēro samērīgums.

 

 

Labots - spameris
Link to comment
Share on other sites

Pirms 55 minūtēm , spameris teica:

Es būvēju sistēmu/as kurās ir vairāki miljoni lietotāji

Kuras tad būtu tās daudzmiljonu sistēmas? :D

Sā izklausīties pēc Bonifācija.

Labots - AndrisBB
  • Kādas šausmas! 1
Link to comment
Share on other sites

1 stundu atpakaļ, AndrisBB teica:

Kuras tad būtu tās daudzmiljonu sistēmas? :D

Sā izklausīties pēc Bonifācija.

Lab es šinī topikā vairs neko nerakstīšu.

Link to comment
Share on other sites

10 hours ago, spameris said:

Es būvēju sistēmu/as kurās ir vairāki miljoni lietotāji  un transakciju skaits vairāki desmiti miljardi un mēģinu iestāstīt kādus principus vajadzētu primāri ievērot, kā vājā vieta ir ORM/SQL no publiskās daļas (kurus tu pats pieminēji)  Kā vienu no opcijām minēju JWT, jeb visiem datiem jābūt tikai lietotāja kontekstā no publiskās daļas un izmantojot API(+api ir izsekojams, logojams un monitorējams daudz vieglāk), lai neietu cauri visādi NEO varianti utt... Un atkal atkārtošos, negiribi neievēro un arī drošībā jāievēro samērīgums.

 

Es arī būvēju sistēmas ar lielu lietotāju bāzi, desmitiem miljardu transakciju un pirkumu gan mums nav, tāpēc jāsecina, ka esi daudz vairāk pieredzējis un gudrāks kā es. Man jāpiekāpjas.

Labots - Duncan F
Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...