Jump to content
php.lv forumi

duncanf293

Reģistrētie lietotāji
  • Content Count

    14
  • Joined

  • Last visited

Everything posted by duncanf293

  1. Šajā gadījumā jautājums nav par to kā to tehniski izdarīt (variantu ir daudz) - jautājums ir par to vai tagad mēs uzskatām jebkādu PII datu kriptēšanu par labo praksi un daram to "by default" pat tad, ja klients neprasa. Nav jau tā, ka veidotos kāds milzīgs overhead kodā dēļ tās PII kriptēšanas... Visiem lielākajiem FW ir tāds vai citāds package, kas procesu padara +- nesāpīgu.
  2. Tā nav gluži taisnība, kriptēšana ir pieminēta pat vairākas reizes. Tas ir sīkāk izķidāts šajā rakstā: https://www.i-scoop.eu/gdpr-encryption/ Tomēr nav strikti minēts, vai pietiek ar visas datubāzes disk-level encryption, vai arī rekomendē kriptēt individuālus laukus. Šajā stackoverflow jautājumā (nav gan diez ko daudz atbilžu, no kā izvēlēties), iesaka ne-kriptēt email lauku (dēļ login) bet kriptēt visu pārējo (first name, last name, address) - https://stackoverflow.com/questions/50579646/should-i-encrypt-the-entire-database-or-just-fields-within
  3. Tas, ko tu ielinkoji, manuprāt ir disk-level encryption, kas pasargā pret scenāriju, kur kāds datucentra darbinieks nospertu SSD disku. Mans klients savukārt runā par scenāriju, kur kāda trešā puse iegūtu mūsu datubāzes dumpu. Tādi precedenti citām kompānijām, protams, ir bijuši. Ja PII lauki datubāzes saturā būtu kriptēti, tad tas būtu... mazliet labāk. Var argumentēt, ka gadījumā, ja hakeris ir atradis piekļuvi datubāzes dumpam, tad vienlaicīgi ir atrasta piekļuve arī servera failu sistēmai un līdz ar to encryption key iekš .env faila. Tādā gadījumā kriptēšana bijusi bezjēdzīga. To
  4. Klients pieprasa, lai 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 prasību, kā to risinājāt? Konkrēti lietoju Laravel FW, tāpēc ir doma paņemt kādu package, piemēram, šo: https://github.com/betterapp/laravel-db-e
  5. Domu laikam sapratu, bet dažas lietas jāprecizē. Vendor ielikšana atsevišķā mapē pati par sevi diez vai kaut ko dod. Tas ko tu laikam gribēji pateikt ir, ka "app-vendors" ir iekopēts konteinerā ar COPY iekš Dockerfile, nevis pieslēgts caur volume? Caur volume pieslēgts tikai "app", jeb development laikā maināmais source kods? Tas varētu tiešām būt efektīvi.
  6. Novēroju apmēram šādu uzvedību - ja neesmu kādas 5min refrešojis lapu, tad pēc pirmā refreša load time būs lēns, kādas 3-5 sekundes. Uzreiz pēc tam atkārtoti spiežot refresh, ir labāks load time, varbūt 1-2 sekundes. Ja atstāju mierā uz 5min vai ilgāk, tad pirmais refresh atkal aizņem 3-5 sekundes un atkārtoti refreši biški mazāk, bet tāpat ilgi. Ok, šī varbūt nav lielākā problēma pasaulē, bet tomēr diezgan kaitinoši. Šķiet specifiski MacOS, jo uzliekot uz produkcijas linux servera, ātrdarbības problēmas vairs nav.
  7. Diemžēl nekādu īpašu efektu no "delegated" mount tipa nejūtu
  8. Nē, nav mēģināts. Strādā? Tā nav īsti tāda informācija pie kuras tu nonāc tajā posmā, kad vēl tikai mācies pirmos soļus ar Docker. Pamēģināšu palietot "delegated" kādu brīdi. Third-party risinājumus 0.x versijas stadijā gan ne pārāk gribas lietot, bet paldies par ieteikumu.
  9. Hmm, lokālajā dev vidē faili nekad nebūs pa tiešo uz docker image... Tā kā faili tiek visu laiku laboti, rakstīti klāt jauni, dzēsti utt. Tad projekta mape vienmēr ir pieslēgta caur mounted volume. Tas variants ko Tu aprakstīji ir produkcijā, bet tur jau arī MacOS nekad nebūs.
  10. Sveiki, esmu sācis lietot Docker un nevaru nepamanīt, ka uz MacOS tas darbojas diezgan lēni. Vispārīgi saprotu tam iemeslus - MacOS un Windows vide nav linux - tur ir vajadzīga vēl viena smaga/lēna abstrakcija. Izskatās bēdīgi, jo jaunam Macbook Pro ar i9 procesoru vajag kādas 2 sekundes, lai apstrādātu vienu web requestu. Tur pat nenotiek nekas resursu intensīvs, nav pat savienošanās ar datubāzi. Tikai parasta skata renderēšana. Salīdzinājumam švakāks DELL laptops ar linux burtiski lido. Vai tam ir kāds reāls risinājums? Bieži dzirdu par to cik Docker ir labs, cik plaši to izmanto utt, b
  11. f***k, jā, paldies. Tā kā 80 automātiski ir exposed, tad baigi viegli aizmirst, ka 443 nav exposed.
  12. Palīgā, es nemāku Docker! Mēģinu lietot pieredzējušākiem docker lietotājiem iespējams pazīstamo jwilder/nginx-proxy (https://github.com/nginx-proxy/nginx-proxy) Mērķis ir standarta darbība - lokāli palaist nginx, kurš visu http trafiku uz porta 80 pārsūta uz https. Ar self-signed sertifikātu. Nginx konfigurācijas fails un self-signed sertifikāti visticamāk ir pareizi, jo, ja nelietoju nginx-proxy vispār nemaz un vienkārši pieslēdzu savu nginx pa taisno host mašīnas portiem 80 un 443 - tad viss strādā. Savukārt, ja mēģinu vēl priekšā pielikt šo nginx-proxy, tad browserī atpakaļ saņe
×
×
  • Create New...