HTTPS pre internetový obchod: nastavenie TLS a bezpečnosť

HTTPS pre internetový obchod: čo je potrebné chrániť

Internetový obchod musí fungovať cez HTTPS na všetkých stránkach: od katalógu až po pokladňu. Vyžaduje si to platný TLS certifikát, správne nastavenie webového servera a automatické obnovovanie. Certifikát chráni údaje počas prenosu, ale neodstraňuje zraniteľnosti stránky, nepotvrdzuje bezúhonnosť predajcu a nechráni server pred škodlivým softvérom.

Čo znamenajú SSL, TLS a HTTPS

TLS — protokol, ktorý vytvára zabezpečené spojenie medzi prehliadačom kupujúceho a serverom stránky. Zabezpečuje dôvernosť prenášaných údajov, chráni ich pred nepozorovanou úpravou počas prenosu a umožňuje prehliadaču overiť, pre ktorú doménu bol certifikát vydaný. Práve TLS sa používa v HTTPS. Názov „SSL certifikát“ zostal v bežnom používaní, hoci protokoly SSL 2.0 a SSL 3.0 sú zastarané a nemali by sa používať. Vysvetľuje to aktuálna príručka OWASP pre TLS.

Pri otvorení adresy https:// server odošle prehliadaču certifikát s verejným kľúčom, názvami domén, dátumom exspirácie a údajmi certifikačnej autority. Prehliadač skontroluje reťazec dôvery, zhodu domény, platnosť a stav certifikátu. Potom sa strany dohodnú na relačných kľúčoch a zašifrujú komunikáciu.

Čo HTTPS chráni

• prihlasovacie mená, heslá, kontaktné údaje a obsah objednávky počas prenosu;
• relačné súbory cookie, ak stránka pre ne správne nastavuje atribúty Secure, HttpOnly a SameSite;
• pred nepozorovaným nahradením stránky alebo odpovede servera v nezabezpečenej sieti;
• spojenie prehliadača s doménou uvedenou v certifikáte.

Čo HTTPS nechráni

Prehliadač Chrome upustil od zámku ako univerzálneho symbolu dôvery, pretože HTTPS ukazuje zabezpečený kanál, nie spoľahlivosť majiteľa stránky. Materiál tímu Chromium uvádza, že takmer všetky phishingové stránky tiež používajú HTTPS; od verzie Chrome 117 bol zámok nahradený neutrálnou ikonou nastavení. Zamestnanci a kupujúci si preto musia skontrolovať presný názov domény, namiesto hľadania „zeleného zámku“. Zdroj: An Update on the Lock Icon.

Prečo je to dôležité pre ukrajinský internetový obchod

Internetový obchod spracúva meno, telefónne číslo, adresu doručenia, históriu objednávok a ďalšie informácie, ktoré môžu byť osobnými údajmi. Článok 24 zákona Ukrajiny „O ochrane osobných údajov“ zaväzuje vlastníkov a správcov chrániť takéto údaje pred náhodnou stratou, nezákonným spracovaním, zničením a prístupom. Zákon definuje povinnosť ochrany, ale nestanovuje pre každý obchod samostatnú požiadavku na kúpu plateného OV alebo EV certifikátu. Zdroj: Zákon Ukrajiny „O ochrane osobných údajov“.

Ukrajinský kontext si vyžaduje osobitnú pozornosť phishingu. V marci 2026 zaznamenal CERT-UA rozosielanie listov údajne v mene samotného CERT-UA s výzvou na stiahnutie súboru a Štátna služba špeciálneho spojenia a ochrany informácií Ukrajiny v júni 2026 informovala o mnohých kampaniach využívajúcich kompromitované účty a techniky sociálneho inžinierstva. Ide o potvrdené útoky na ukrajinské organizácie, nie o správy o útoku na konkrétny obchod alebo program. Zdroje: správa CERT-UA o UAC-0255 a prehľad Štátnej služby špeciálneho spojenia o phishingových kampaniach.

Aký certifikát si vybrať

Úroveň overenia vlastníka

DV, OV a EV môžu používať rovnaké moderné šifrovacie algoritmy. Rozdiel spočíva v postupe overovania žiadateľa a v údajoch certifikátu. Bezplatný DV certifikát od všeobecne uznávanej certifikačnej autority nešifruje slabšie kvôli chýbajúcej cene. Let’s Encrypt vydáva bezplatné DV certifikáty, ale nevydáva OV a EV; súkromný kľúč sa vytvorí a uloží na strane majiteľa stránky. Zdroj: oficiálne FAQ Let’s Encrypt.

Počet domén

• Certifikát pre jedno meno pokrýva konkrétne doménové meno uvedené v poli SAN.
• Viacdoménový certifikát obsahuje viac mien v poli SAN. Názvy SAN a UCC často opisujú ten istý mechanizmus, nie rôznu úroveň ochrany.
• Wildcard certifikát pokrýva subdomény prvej úrovne, napríklad *.example.ua, ale zvyčajne nepokrýva samotnú doménu example.ua bez samostatného záznamu. Jeden ukradnutý súkromný kľúč takého certifikátu vytvára riziko pre všetky pokryté subdomény. OWASP odporúča používať wildcard len v prípade opodstatnenej potreby a nezdieľať ho medzi systémami s rôznou úrovňou dôvery.

Doba platnosti a automatické obnovovanie

Doby platnosti verejných TLS certifikátov sa skracujú. Podľa platných základných požiadaviek CA/Browser Forum certifikáty vydané od 15. marca 2026 do 15. marca 2027 nemôžu platiť dlhšie ako 200 dní. Od 15. marca 2027 bude limit 100 dní a od 15. marca 2029 — 47 dní. Zdroj: CA/Browser Forum TLS Baseline Requirements 2.2.2.

Od júla 2026 platia štandardné certifikáty Let’s Encrypt 90 dní a samostatný profil umožňuje používať kratšie certifikáty. Majiteľ musí kontrolovať nie kalendárny dátum nákupu, ale fungovanie automatického ACME klienta, úspešnú inštaláciu nového certifikátu a reštartovanie alebo opätovné načítanie konfigurácie webového servera.

Hlavné scenáre útokov a porúch

Ako správne nastaviť HTTPS

1. Vytvorte zoznam názvov. Pridajte hlavnú doménu, variant s www, platobné a interné subdomény, ak sa skutočne používajú. Nekupujte wildcard len pre pohodlie.
2. Vydávajte certifikát na serveri alebo cez spravovanú platformu. Súkromný kľúč by sa nemal posielať v messengeroch, poštou ani ukladať v zdieľanom priečinku.
3. Zautomatizujte celý cyklus. ACME klient musí získať nový certifikát, nainštalovať ho, znova načítať konfiguráciu servera a nahlásiť chybu. Samostatné externé monitorovanie by malo kontrolovať skutočný certifikát, ktorý vidí kupujúci.
4. Ponechajte moderné protokoly. OWASP odporúča štandardne používať TLS 1.3 a podporovať TLS 1.2 pre kompatibilitu. TLS 1.0, TLS 1.1, SSL 2.0 a SSL 3.0 musia byť vypnuté. Od júla 2026 zostáva aktuálnou zverejnenou smernicou NIST SP 800-52 Rev. 2; NIST ju už začal revidovať v roku 2026.
5. Presmerujte HTTP na HTTPS. Použite trvalé serverové presmerovanie 301 alebo 308. Adresy HTTPS uveďte v canonical, sitemape a hreflang. Google uprednostňuje správne HTTPS stránky ako kanonické, ale samotné HTTPS nezaručuje pozície vo vyhľadávaní. Zdroj: odporúčania Google pre kanonické adresy URL.
6. Odstráňte zmiešaný obsah. Obrázky, písma, štýly, skripty, formuláre a požiadavky API sa musia načítavať cez HTTPS. Aktívny HTTP obsah môže prehliadač zablokovať a jeho nahradenie umožňuje spustiť kód tretej strany.
7. Po overení zapnite HSTS. Hlavička Strict-Transport-Security dáva prehliadaču pokyn, aby odteraz používal HTTPS. Najprv skontrolujte všetky subdomény a začnite s malým max-age; chybná konfigurácia HSTS môže spôsobiť, že stránka bude nedostupná. Pokyny pre presmerovania, HSTS a bezpečné súbory cookie sú uvedené v príručke web.dev k zapnutiu HTTPS.
8. Chráňte ovládacie panely. Pre registrátora, DNS, CDN, hosting, CMS a poštu používajte samostatné účty, viacfaktorovú autentifikáciu a minimálne potrebné práva. Odstráňte prístup prepusteným zamestnancom a bývalým dodávateľom.
9. Kontrolujte vydávanie certifikátov. Denníky Certificate Transparency vám umožňujú vidieť certifikáty vydané pre vaše domény a odhaliť neočakávané vydanie. Princíp fungovania monitorov je popísaný na Certificate Transparency.

HTTPS a prijímanie platieb

Ak obchod presmeruje kupujúceho na stránku banky, nadobúdateľa alebo iného poskytovateľa platieb, spojenie TLS obchodu chráni cestu len do momentu prechodu. Platobná stránka musí mať vlastný platný certifikát a adresu je potrebné overiť s dokumentáciou poskytovateľa. Obchod by nemal samostatne pridávať polia pre kartu, ukladať CVV alebo prenášať údaje prostredníctvom vlastnej databázy, pokiaľ takáto architektúra nie je dohodnutá s nadobúdateľom a nespĺňa príslušné požiadavky PCI DSS.

Národná banka Ukrajiny osobitne varuje pred podvodmi pri online platbách a falošnými internetovými obchodmi. Pre kupujúceho to znamená, že prítomnosť HTTPS musí hodnotiť spolu s presnou adresou stránky, spôsobom platby a overením predajcu. Praktické materiály sú zhromaždené na oficiálnom zdroji NBU „FraudGoodbye“.

Aktuálnou verziou štandardu je PCI DSS 4.0.1. Požiadavky na bezpečnosť platobných stránok, ktoré nadobudli účinnosť 31. marca 2025, sa zameriavajú na autorizáciu skriptov, overovanie ich integrity a detekciu neoprávnených zmien. Čelia web skimmingu, pri ktorom kód v prehliadači kopíruje údaje z formulára. Zdroj: PCI SSC: Payment Page Security and Preventing E-Skimming.

Čo robiť, ak prehliadač zobrazí chybu certifikátu

1. Nežiadajte kupujúcich, aby varovanie obišli. Dočasne pozastavte reklamnú návštevnosť a platby, ak nie je k dispozícii bezpečná cesta pre dokončenie objednávky.
2. Zaznamenajte chybu. Uložte presný čas, doménu, text chyby, snímku obrazovky, údaje z externého monitorovania a posledné zmeny na hostingu.
3. Zistite príčinu. Bežné možnosti: uplynula platnosť; certifikát vydaný pre nesprávne meno; server vracia starý certifikát; chýba sprostredkujúci certifikát; nesprávny čas na serveri; CDN a hlavný server majú odlišné konfigurácie; automatické obnovenie prebehlo, ale webový server nenačítal nový súbor.
4. Opravte konfiguráciu. V prípade potreby znovu vydajte certifikát, nainštalujte úplný reťazec a otestujte každú verejnú doménu z rôznych sietí.
5. Otestujte proces objednávky. Prejdite katalóg, autorizáciu, košík, presmerovanie na poskytovateľa platieb, návrat po platbe, upozornenia a integračné požiadavky.
6. Nájdite organizačnú príčinu. Opravte automatizáciu, pridajte externé upozornenie, zdokumentujte vlastníka procesu a záložný kontakt.

Čo robiť v prípade kompromitácie kľúča alebo webového servera

1. Obmedzte prístup k zasiahnutému uzlu. Nemažte súbory a denníky a nepreinštalujte systém pred zabezpečením dôkazov, pokiaľ to nie je potrebné na zastavenie prebiehajúcej škody.
2. Uložte dôkazy. Urobte snímku systému alebo disku, exportujte denníky webového servera, CDN, CMS, DNS, panela hostingu a autentifikácie. Zaznamenajte čas v jednom časovom pásme.
3. Odvolajte certifikát. Vytvorte nový pár kľúčov na čistom systéme a získajte nový certifikát. Jednoduché obnovenie so starým kľúčom nerieši kompromitáciu.
4. Zmeňte súvisiace tajomstvá. Zmeňte heslá a relácie administrátorov, API kľúče, prístupy k databáze, SSH, panelom hostingu, CDN, registrátorovi, DNS, pošte a repozitáru. Začnite od čistého zariadenia.
5. Skontrolujte stránku. Hľadajte nových administrátorov, zmenené súbory, skripty tretích strán, plánovače úloh, web shelly, pravidlá presmerovania, zmenené platobné údaje a neočakávané certifikáty v denníkoch CT.
6. Obnovujte iba z overenej zálohy. Záloha musí byť vytvorená pred prienikom a otestovaná v samostatnom prostredí. Po obnove nainštalujte aktualizácie, odstráňte prvotnú príčinu a až potom vráťte stránku do prevádzky.
7. Informujte dotknuté strany. Zapojte hosting, vývojára, nadobúdateľa, zodpovednú osobu pre ochranu osobných údajov a právnika. Kybernetický incident môžete nahlásiť CERT-UA; znaky trestného činu alebo podvodu — cez systém elektronických podaní Kyberpolície.

Zálohy a obnova

Certifikát nie je záložná kópia stránky. Na obnovu sú potrebné overené kópie kódu, databázy, nahraných súborov, konfigurácie webového servera, záznamov DNS, pravidiel CDN, nastavení integrácie a zdokumentovaného procesu vydávania certifikátu. Súkromný kľúč by sa nemal zbytočne kopírovať: v mnohých konfiguráciách je bezpečnejšie vytvoriť nový kľúč a certifikát znova vydať.

Uchovávajte aspoň jednu kópiu oddelene od produkčného servera a jeho neustále prístupných účtov. Pravidelne kontrolujte integritu záloh a vykonávajte testovacie obnovy v izolovanom prostredí. CISA odporúča udržiavať offline šifrované kópie kritických údajov a pravidelne testovať ich dostupnosť a integritu v scenári obnovy po havárii. Zdroj: CISA StopRansomware Guide.

HTTPS, Torgsoft a Windows server obchodu

TLS certifikát internetového obchodu chráni webové spojenia s príslušnou doménou. Nechráni lokálny server ani hlavný počítač s Torgsoftom, pokladničné počítače, sieťové priečinky a zálohy. Tieto systémy si vyžadujú samostatnú ochranu.

• server alebo hlavný počítač s Torgsoftom by sa mal ideálne používať len na chod programu a databázy;
• nemal by sa na ňom čítať e-mail, otvárať messengery, sťahovať náhodné súbory, prehliadať cudzie stránky a inštalovať nepotrebné programy;
• priamy RDP prístup z verejného internetu nesmie byť otvorený;
• vzdialený prístup musí byť poskytovaný kontrolovane: cez VPN alebo inú bezpečnú bránu, pod samostatnými účtami, so zaznamenávaním a viacfaktorovou autentifikáciou, ak ju vybrané riešenie podporuje;
• zamestnanci musia pracovať bez trvalých práv administrátora;
• kópia na tom istom serveri alebo trvalo pripojenom disku môže byť poškodená alebo zašifrovaná spolu s hlavnými údajmi;
• na obnovu je potrebná funkčná záloha vytvorená pred prienikom a overená testovacím nasadením.

Kto za čo zodpovedá

Praktický kontrolný zoznam

Na externé testovanie konfigurácie môžete použiť Qualys SSL Labs Server Test. OWASP tiež odporúča overiť konfiguráciu po sprísnení nastavení a uvádza zoznam online a lokálnych nástrojov v TLS Cheat Sheet. Automatický test nenahrádza otestovanie košíka, autorizácie, platobného presmerovania, API a obnovy zo zálohy.