HTTPS pentru magazin online: configurare TLS și securitate

HTTPS pentru un magazin online: ce trebuie protejat

Un magazin online trebuie să funcționeze prin HTTPS pe toate paginile: de la catalog până la finalizarea comenzii. Pentru aceasta este nevoie de un certificat TLS valabil, configurarea corectă a serverului web și reînnoire automată. Certificatul protejează datele în timpul transmiterii, dar nu elimină vulnerabilitățile site-ului, nu confirmă buna-credință a vânzătorului și nu protejează serverul de malware.

Ce înseamnă SSL, TLS și HTTPS

TLS — protocolul care creează o conexiune securizată între browserul cumpărătorului și serverul site-ului. Acesta asigură confidențialitatea datelor transmise, le protejează împotriva modificărilor nedetectabile pe parcurs și permite browserului să verifice pentru ce domeniu a fost emis certificatul. TLS este folosit exact în HTTPS. Denumirea „certificat SSL” a rămas în uzul curent, deși protocoalele SSL 2.0 și SSL 3.0 sunt învechite și nu ar trebui utilizate. Acest lucru este explicat în ghidul actual OWASP pentru TLS.

La deschiderea unei adrese https://, serverul trimite browserului un certificat cu o cheie publică, nume de domenii, data expirării și datele autorității de certificare. Browserul verifică lanțul de încredere, corespondența domeniului, valabilitatea și starea certificatului. După aceasta, părțile convin asupra cheilor de sesiune și criptează schimbul de date.

Ce protejează HTTPS

• autentificările, parolele, datele de contact și conținutul comenzii în timpul transmiterii;
• cookie-urile de sesiune, dacă site-ul setează corect atributele Secure, HttpOnly și SameSite pentru acestea;
• împotriva substituirii nedetectabile a unei pagini sau a răspunsului serverului într-o rețea nesecurizată;
• conexiunea browserului cu domeniul specificat în certificat.

Ce NU protejează HTTPS

Chrome a renunțat la lacăt ca simbol universal de încredere, deoarece HTTPS indică un canal securizat, nu fiabilitatea proprietarului paginii. Materialul echipei Chromium menționează că aproape toate site-urile de phishing folosesc și ele HTTPS; începând cu Chrome 117, lacătul a fost înlocuit cu o pictogramă neutră de setări. Prin urmare, angajații și cumpărătorii trebuie să verifice numele exact al domeniului, în loc să caute un „lacăt verde”. Sursa: An Update on the Lock Icon.

De ce este important acest lucru pentru un magazin online ucrainean

Un magazin online procesează numele, numărul de telefon, adresa de livrare, istoricul comenzilor și alte informații care pot constitui date cu caracter personal. Articolul 24 din Legea Ucrainei „Privind protecția datelor cu caracter personal” obligă proprietarii și operatorii să protejeze astfel de date împotriva pierderii accidentale, prelucrării ilegale, distrugerii și accesului. Legea definește obligația de protecție, dar nu stabilește o cerință separată pentru fiecare magazin de a cumpăra un certificat OV sau EV plătit. Sursa: Legea Ucrainei „Privind protecția datelor cu caracter personal”.

Contextul ucrainean necesită o atenție deosebită la phishing. În martie 2026, CERT-UA a înregistrat trimiterea de scrisori presupus din partea însăși CERT-UA cu un apel de a descărca un fișier, iar Serviciul de Stat pentru Comunicații Speciale a raportat în iunie 2026 numeroase campanii folosind conturi compromise și tehnici de inginerie socială. Acestea sunt atacuri confirmate asupra organizațiilor ucrainene, nu rapoarte despre un atac asupra unui magazin sau program specific. Surse: raportul CERT-UA despre UAC-0255 și recenzia Serviciului de Stat pentru Comunicații Speciale despre campaniile de phishing.

Ce certificat să alegeți

Nivelul de verificare a proprietarului

DV, OV și EV pot folosi aceiași algoritmi moderni de criptare. Diferența constă în procedura de verificare a solicitantului și în detaliile certificatului. Un certificat DV gratuit de la o autoritate de certificare recunoscută universal nu criptează mai slab din cauza lipsei prețului. Let’s Encrypt emite certificate DV gratuite, dar nu emite OV și EV; cheia privată este creată și stocată pe partea proprietarului site-ului. Sursa: FAQ oficial Let’s Encrypt.

Numărul de domenii

• Certificat pentru un singur nume acoperă un nume de domeniu specificat în câmpul SAN.
• Certificat multidomeniu conține mai multe nume în câmpul SAN. Numele SAN și UCC descriu adesea același mecanism, nu o forță de protecție diferită.
• Certificat wildcard acoperă subdomeniile de primul nivel, cum ar fi *.example.ua, dar de obicei nu acoperă example.ua în sine fără o înregistrare separată. O cheie privată furată a unui astfel de certificat creează un risc pentru toate subdomeniile acoperite. OWASP recomandă utilizarea wildcard doar atunci când este justificată și evitarea partajării acestuia între sisteme cu niveluri de încredere diferite.

Perioada de valabilitate și reînnoirea automată

Perioadele de valabilitate ale certificatelor TLS publice se scurtează. Conform cerințelor de bază actuale ale CA/Browser Forum, certificatele emise între 15 martie 2026 și 15 martie 2027 nu pot fi valabile mai mult de 200 de zile. Din 15 martie 2027, limita va fi de 100 de zile, iar din 15 martie 2029 — 47 de zile. Sursa: CA/Browser Forum TLS Baseline Requirements 2.2.2.

Începând cu iulie 2026, certificatele standard Let’s Encrypt sunt valabile 90 de zile, iar un profil separat permite utilizarea certificatelor mai scurte. Proprietarul trebuie să controleze nu data calendaristică a achiziției, ci funcționarea clientului automat ACME, instalarea cu succes a noului certificat și repornirea sau reîncărcarea configurației serverului web.

Principalele scenarii de atacuri și erori

Cum să configurați corect HTTPS

1. Faceți o listă de nume. Adăugați domeniul principal, varianta cu www, subdomeniile de plată și interne, dacă sunt utilizate efectiv. Nu cumpărați un wildcard doar pentru comoditate.
2. Emiteți certificatul pe server sau printr-o platformă gestionată. Cheia privată nu trebuie trimisă pe mesagerii, prin poștă sau stocată într-un folder partajat.
3. Automatizați ciclul complet. Clientul ACME trebuie să obțină noul certificat, să-l instaleze, să reîncarce configurația serverului și să raporteze o eroare. O monitorizare externă separată ar trebui să verifice certificatul real pe care îl vede cumpărătorul.
4. Lăsați protocoalele moderne. OWASP recomandă utilizarea TLS 1.3 în mod implicit și susținerea TLS 1.2 pentru compatibilitate. TLS 1.0, TLS 1.1, SSL 2.0 și SSL 3.0 trebuie dezactivate. Începând cu iulie 2026, ghidul publicat de NIST rămâne SP 800-52 Rev. 2; NIST a început deja revizuirea acestuia în 2026.
5. Redirecționați HTTP către HTTPS. Folosiți o redirecționare permanentă a serverului 301 sau 308. Specificați adresele HTTPS în canonical, sitemap și hreflang. Google preferă paginile HTTPS corecte ca fiind canonice, dar HTTPS în sine nu garantează poziții în căutări. Sursa: recomandările Google privind URL-urile canonice.
6. Eliminați conținutul mixt. Imaginile, fonturile, stilurile, scripturile, formularele și cererile API trebuie să se încarce prin HTTPS. Conținutul HTTP activ poate fi blocat de browser, iar substituirea acestuia permite executarea de cod terț.
7. Activați HSTS după verificare. Antetul Strict-Transport-Security instruiește browserul să folosească HTTPS de acum înainte. Mai întâi, verificați toate subdomeniile și începeți cu un max-age mic; o configurație HSTS greșită poate face site-ul inaccesibil. Liniile directoare pentru redirecționări, HSTS și cookie-uri sigure sunt furnizate în ghidul web.dev pentru activarea HTTPS.
8. Protejați panourile de control. Pentru registrator, DNS, CDN, găzduire, CMS și e-mail, utilizați conturi separate, autentificare multifactorială și drepturi minime necesare. Eliminați accesul angajaților concediați și al foștilor contractori.
9. Controlați emiterea certificatelor. Jurnalele Certificate Transparency vă permit să vedeți certificatele emise pentru domeniile dvs. și să detectați emiterile neașteptate. Modul în care funcționează monitoarele este descris pe Certificate Transparency.

HTTPS și acceptarea plăților

Dacă magazinul redirecționează cumpărătorul către pagina unei bănci, acquirer sau alt furnizor de plăți, conexiunea TLS a magazinului protejează calea doar până la momentul tranziției. Pagina de plată trebuie să aibă propriul certificat valabil, iar adresa trebuie verificată conform documentației furnizorului. Magazinul nu ar trebui să adauge independent câmpuri pentru card, să stocheze CVV sau să transmită detalii prin propria bază de date, cu excepția cazului în care o astfel de arhitectură este convenită cu acquirer-ul și respectă cerințele PCI DSS aplicabile.

Banca Națională a Ucrainei avertizează în mod specific cu privire la frauda în timpul plăților online și magazinele online false. Pentru cumpărător, aceasta înseamnă că prezența HTTPS trebuie evaluată împreună cu adresa exactă a site-ului, metoda de plată și verificarea vânzătorului. Materiale practice sunt colectate pe resursa oficială a NBU „FraudGoodbye”.

Versiunea actuală a standardului este PCI DSS 4.0.1. Cerințele de securitate a paginilor de plată, intrate în vigoare la 31 martie 2025, se concentrează pe autorizarea scripturilor, verificarea integrității lor și detectarea modificărilor neautorizate. Acestea combat web skimming-ul, unde codul din browser copiază detaliile dintr-un formular. Sursa: PCI SSC: Payment Page Security and Preventing E-Skimming.

Ce trebuie să faceți dacă browserul arată o eroare de certificat

1. Nu cereți cumpărătorilor să ocolească avertismentul. Suspendați temporar traficul publicitar și plățile dacă calea securizată de finalizare a comenzii este indisponibilă.
2. Înregistrați eroarea. Salvați ora exactă, domeniul, textul erorii, captura de ecran, datele de monitorizare externă și modificările recente pe găzduire.
3. Verificați cauza. Opțiuni comune: expirat; certificat emis pentru un nume greșit; serverul returnează un certificat vechi; lipsă certificat intermediar; oră incorectă pe server; CDN și serverul principal au configurații diferite; reînnoirea automată s-a executat, dar serverul web nu a reîncărcat noul fișier.
4. Remediați configurația. Reemiteți certificatul dacă este necesar, instalați lanțul complet și testați fiecare domeniu public din rețele diferite.
5. Testați procesul de comandă. Treceți prin catalog, autorizare, coș, redirecționare către furnizorul de plăți, revenire după plată, notificări și cereri de integrare.
6. Găsiți cauza organizatorică. Remediați automatizarea, adăugați o alertă externă, documentați proprietarul procesului și un contact de rezervă.

Ce trebuie să faceți în caz de compromitere a cheii sau a serverului web

1. Limitați accesul la nodul afectat. Nu ștergeți fișiere și jurnale și nu reinstalați sistemul până la securizarea dovezilor, cu excepția cazului în care este necesar pentru oprirea daunelor în curs.
2. Păstrați dovezile. Faceți un instantaneu al sistemului sau discului, exportați jurnalele serverului web, CDN, CMS, DNS, panoului de găzduire și autentificării. Înregistrați ora într-un singur fus orar.
3. Revocați certificatul. Creați o nouă pereche de chei pe un sistem curat și obțineți un nou certificat. Reînnoirea simplă cu cheia veche nu rezolvă compromiterea.
4. Schimbați secretele asociate. Schimbați parolele și sesiunile administratorilor, cheile API, accesul la baza de date, SSH, panourile de găzduire, CDN, registrator, DNS, e-mail și depozit. Începeți de la un dispozitiv curat.
5. Verificați site-ul. Căutați noi administratori, fișiere modificate, scripturi terțe, planificatoare de sarcini, shell-uri web, reguli de redirecționare, detalii de plată modificate și certificate neașteptate în jurnalele CT.
6. Restaurați doar dintr-o copie verificată. Copia de rezervă trebuie creată înainte de intruziune și testată într-un mediu separat. După restaurare, instalați actualizări, eliminați cauza principală și abia apoi readuceți site-ul în funcțiune.
7. Notificați părțile afectate. Implicați găzduirea, dezvoltatorul, acquirer-ul, responsabilul cu protecția datelor și avocatul. Un incident cibernetic poate fi raportat la CERT-UA; semne ale unei infracțiuni penale sau fraude — prin sistemul electronic de apeluri al Poliției Cibernetice.

Copii de rezervă și recuperare

Un certificat nu este o copie de rezervă a unui site. Recuperarea necesită copii verificate ale codului, bazei de date, fișierelor încărcate, configurației serverului web, înregistrărilor DNS, regulilor CDN, setărilor de integrare și a unui proces documentat de emitere a certificatului. O cheie privată nu ar trebui duplicată fără necesitate: în multe configurații, este mai sigur să creați o cheie nouă și să reemiteți certificatul.

Păstrați cel puțin o copie separată de serverul de producție și de conturile sale permanent accesibile. Verificați în mod regulat integritatea copiilor de rezervă și efectuați recuperări de testare într-un mediu izolat. CISA recomandă menținerea copiilor offline criptate ale datelor critice și testarea regulată a disponibilității și integrității acestora într-un scenariu de recuperare în caz de dezastru. Sursa: CISA StopRansomware Guide.

HTTPS, Torgsoft și serverul Windows al magazinului

Certificatul TLS al unui magazin online protejează conexiunile web către domeniul corespunzător. Nu protejează serverul local sau computerul principal care rulează Torgsoft, casele de marcat, folderele de rețea și copiile de rezervă. Aceste sisteme necesită protecție separată.

• serverul sau computerul principal cu Torgsoft ar trebui, de preferat, să fie folosit doar pentru rularea programului și bazei de date;
• pe el nu ar trebui să se citească e-mailuri, să se deschidă mesagerii, să se descarce fișiere aleatorii, să se navigheze pe site-uri terțe și să se instaleze programe inutile;
• accesul RDP direct din internetul public nu trebuie deschis;
• accesul la distanță trebuie acordat controlat: prin VPN sau un alt gateway securizat, folosind conturi separate, cu jurnalizare și autentificare multifactorială dacă este suportată de soluția aleasă;
• angajații trebuie să lucreze fără drepturi permanente de administrator;
• o copie pe același server sau pe o unitate conectată permanent poate fi coruptă sau criptată împreună cu datele principale;
• recuperarea necesită o copie sănătoasă creată înainte de intruziune și verificată prin implementare de test.

Cine și de ce este responsabil

Checklist practic

Pentru testarea externă a configurației, puteți utiliza Qualys SSL Labs Server Test. OWASP recomandă, de asemenea, verificarea configurației după întărirea setărilor și oferă o listă de instrumente online și locale în TLS Cheat Sheet. Un test automat nu înlocuiește testarea coșului, a autorizării, a redirecționării la plată, a API-ului și a restaurării dintr-o copie de rezervă.