Jump to content
php.lv forumi

duncanf293

Reģistrētie lietotāji
  • Content Count

    14
  • Joined

  • Last visited

Posts posted by duncanf293

  1. On 10/9/2020 at 1:08 PM, werd said:

    https://dev.mysql.com/doc/refman/8.0/en/encryption-functions.html#function_aes-encrypt - iebūvētā AES_ENCRYPT() MySQL funkcija neder? Izmanto "sāli", lai enkriptētu un dekriptētu - bez sāls neviens nenolasīs to vērtību arī tad, ja iegūs tavu datu bāzi.

    Š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. 1 hour ago, Grey_Wolf said:

    Personas datu aizsardzībā nav tādu prasību..  pat ne īsti rekomendācijās..  viņa vispār neregulē, kā jāglabā dati..
    - ne formu, ne izskatu neko.. tur  tiek norādītas pa visam citas lietas.. 

    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. 17 minutes ago, briedis said:

    Visdrīzāk ar to ir domāts, ka datubāze ir kritpēta, nevis saturs. Tas būtu diezgan liels absurds, lai ielogotos lietotāja kontā, būtu jādekriptē visi ieraksti, lai atrastu kurš lietotājs tas ir :)

    Piemēram, ja lieto AWS RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html

    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.

    Tomēr izskatās, ka ir kompānijas, kas iet šādu ceļu. Tiem Laravel package kājas no kaut kurienes aug.

    Lai veiktu user loginu, nav jādekriptē visi ieraksti. Populāra metode ir atsevišķā indeksētā datubāzes laukā glabāt e-pasta hash un login brīdī meklēt pēc tā.

  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-encrypter
    Iekšēji package izmanto Laravela Crypt fasādi, kas paņem encryption key no .env faila. Modeļos var norādīt, kurus laukus vajag kriptēt, pārējie paliks plaintext.
    Teorētiski ar šo būtu jāpietiek?

  5. 18 hours ago, ViktorsN said:

    Arī kādu laiku atpakaļ cīnījos, lai paātrinātu ielādi development laikā uz MacOS.
    Tik tālu esmu nonācis pie tā, ka web-app'am (uz Laravel) vendorus (t.i. composer dependencies) instalēju ārpus source foldera. Respektīvi - šie vendori netiek sync'oti starp hostu un konteineri. (kontainerī tas izskatās šādi: app source man sēž iekš /app direktorijas, bet vendori iekš /app-vendors direktorijas).

    Īsāk sakot - jādara tā, lai tiek syncoti tikai vajadzīgie faili, nevis vēl visādi 3rd party faili, kurus development laikā neaiztiec, un būs laime.

    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. 2 hours ago, pcsssss said:

    Vai esi drošs, ka vaina Dockerī? 
    Man uz MacOS python django aplikācija ar ieslēgtām visām dev fīčām, datubāzes pieprasījumiem utt. vidēji 300ms izpildās. 

    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. 48 minutes ago, briedis said:

    Tu vispār mēģināji mainīt tos volume tipus pie mountošanas? consistent, cached, delegated utt.

    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.

    8 minutes ago, werd said:

    http://docker-sync.io - pieredze gan rāda, ka lielākiem projektiem tas vienā brīdī nosprūst (git checkout $FB etc.). Diemžēl sakarīga risinājuma priekš MacOS pagaidām nav.

    Third-party risinājumus 0.x versijas stadijā gan ne pārāk gribas lietot, bet paldies par ieteikumu.

  8. 18 minutes ago, Kasspars said:

    Lēna ir failu lasīšana no host mašīnas. Ja visi faili būs pa tiešo uz docker image, tad ātrdarbībai problēmu nebūs

    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.

  9. 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, bet nu kā tad to sūdu reāli izmantot ja sakarīgs ātrums ir tikai Linux vidē?

    Paldies!

  10. On 7/18/2020 at 1:47 PM, codehighriga said:

    Problēma varētu būt tā, ka docker-compose.yml trūkst "expose". Zem expose ir jābūt portiem 80 un 443.

    Ja Dockerfile ir bāzēts uz oficiālo nginx image bez izmaiņām, tad pēc noklusējuma expose ir tikai ports 80. Tā kā tu ļepini kopā SSL, tad tev vajag expose arī 443.

    f***k, jā, paldies. Tā kā 80 automātiski ir exposed, tad baigi viegli aizmirst, ka 443 nav exposed.

  11. 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ņemu 502 Bad Gateway.

    It kā izdarīts viss, kas minēts dokumentācijā:
    1. Kā environment mainīgie konteineram padoti VIRTUAL_HOST=mydomain.local, VIRTUAL_PROTO=https and VIRTUAL_PORT=443
    2. Pašam nginx-proxy konteineram kā volume padota mape ar .crt un .key sertifikātiem

    Un tomēr ir tas 502 Bad Gateway. Nginx error logs ir uzlikts uz "debug" līmenī, bet tajā logā tāpat nekas neiekrīt. Neredzu papildus iespējas, kā debugot.

    Nginx config fails:

    server {
        listen 80;
        return 301 https://$host$request_uri;
    }
    
    server {
    
        listen 443 ssl;
        listen [::]:443 ssl ipv6only=on;
        ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
        ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    
        error_log  /var/www/storage/logs/nginx-error.log debug; # tukšs
        access_log /var/www/storage/logs/nginx-access.log; # tukšs
    
       # other things...
    }

    docker-compose.yml:

    version: '3'
    
    services:
    
      nginx:
        build:
          context: ../
          dockerfile: ./docker/nginx/Dockerfile
    
        environment:
          - VIRTUAL_HOST=mydomain.local
          - VIRTUAL_PROTO=https
          - VIRTUAL_PORT=443
    
        volumes:
          - ${BASE_PATH}/public:/var/www/public
          - ${BASE_PATH}/storage/logs/nginx-error.log:/var/www/storage/logs/nginx-error.log
          - ${BASE_PATH}/storage/logs/nginx-access.log:/var/www/storage/logs/nginx-access.log

    self-signed sertifikātu ģenerācijai lietotā komanda:

    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt -subj "/"

     

×
×
  • Create New...