Интернет-дүкенге арналған HTTPS: TLS баптау және қауіпсіздік

Интернет-дүкенге арналған HTTPS: нені қорғау керек

Интернет-дүкен барлық беттерде HTTPS арқылы жұмыс істеуі керек: каталогтан бастап тапсырысты рәсімдеуге дейін. Бұл үшін жарамды TLS-сертификаты, веб-серверді дұрыс баптау және автоматты түрде ұзарту қажет. Сертификат деректерді тасымалдау кезінде қорғайды, бірақ сайттың осалдықтарын жоймайды, сатушының адалдығын растамайды және серверді зиянды бағдарламалардан қорғамайды.

SSL, TLS және HTTPS нені білдіреді

TLS — сатып алушының браузері мен сайт сервері арасында қауіпсіз байланыс жасайтын хаттама. Ол тасымалданатын деректердің құпиялылығын қамтамасыз етеді, оларды жолда білдіртпей өзгертуден қорғайды және браузерге сертификаттың қай домен үшін берілгенін тексеруге мүмкіндік береді. HTTPS-те дәл осы TLS қолданылады. «SSL-сертификаты» атауы күнделікті өмірде сақталды, дегенмен SSL 2.0 және SSL 3.0 хаттамалары ескірген және оларды қолданбау керек. Бұл туралы TLS бойынша OWASP-тың өзекті нұсқаулығында түсіндіріледі.

https:// мекенжайын ашқан кезде сервер браузерге ашық кілті, домендік атаулары, жарамдылық мерзімі және сертификаттау орталығының деректері бар сертификат жібереді. Браузер сенім тізбегін, доменнің сәйкестігін, жарамдылық мерзімін және сертификаттың күйін тексереді. Осыдан кейін тараптар сеанс кілттерін келісіп, алмасуды шифрлайды.

HTTPS нені қорғайды

• логиндерді, құпия сөздерді, байланыс деректерін және тапсырыс мазмұнын тасымалдау кезінде;
• сеанстық cookie файлдарын, егер сайт олар үшін Secure, HttpOnly және SameSite атрибуттарын дұрыс орнатса;
• қорғалмаған желіде бетті немесе сервердің жауабын білдіртпей ауыстырудан;
• браузердің сертификатта көрсетілген доменмен байланысын.

HTTPS нені қорғамайды

Chrome құлыпты жалпы сенім белгісі ретінде пайдаланудан бас тартты, өйткені HTTPS бет иесінің сенімділігін емес, қорғалған арнаны көрсетеді. Chromium командасының материалында барлық фишингтік сайттардың дерлік HTTPS-ті пайдаланатыны атап өтілген; Chrome 117 нұсқасынан бастап құлып бейтарап параметрлер белгішесімен ауыстырылды. Сондықтан қызметкерлер мен сатып алушылар «жасыл құлыпты» іздемей, дәл домендік атауды тексеруі керек. Дереккөз: An Update on the Lock Icon.

Бұл украиндық интернет-дүкен үшін неге маңызды

Интернет-дүкен аты-жөнді, телефон нөмірін, жеткізу мекенжайын, тапсырыстар тарихын және дербес деректер болып табылуы мүмкін басқа да ақпаратты өңдейді. Украинаның «Дербес деректерді қорғау туралы» Заңының 24-бабы иелері мен өкім етушілерін мұндай деректерді кездейсоқ жоғалтудан, заңсыз өңдеуден, жоюдан және қол жеткізуден қорғауға міндеттейді. Заң қорғау міндетін белгілейді, бірақ әрбір дүкенге ақылы OV немесе EV-сертификатын сатып алу туралы бөлек талап қоймайды. Дереккөз: Украинаның «Дербес деректерді қорғау туралы» Заңы.

Украиналық контекст фишингке ерекше назар аударуды талап етеді. 2026 жылғы наурызда CERT-UA файлды жүктеп алуға шақыратын CERT-UA атынан жіберілген хаттарды тіркеді, ал Мемлекеттік арнайы байланыс қызметі 2026 жылғы маусымда бұзылған тіркелгілер мен әлеуметтік инженерия тәсілдерін қолданатын көптеген науқандар туралы хабарлады. Бұл нақты бір дүкенге немесе бағдарламаға жасалған шабуыл туралы хабарламалар емес, украиналық ұйымдарға жасалған расталған шабуылдар. Дереккөздер: CERT-UA-ның UAC-0255 туралы хабарламасы және Мемлекеттік арнайы байланыс қызметінің фишингтік науқандар туралы шолуы.

Қандай сертификатты таңдау керек

Иесін тексеру деңгейі

DV, OV және EV бірдей заманауи шифрлау алгоритмдерін пайдалана алады. Айырмашылық өтініш берушіні тексеру рәсімінде және сертификат мәліметтерінде. Жалпыға танылған сертификаттау орталығынан алынған тегін DV-сертификаты бағаның жоқтығына байланысты нашар шифрламайды. Let’s Encrypt тегін DV-сертификаттарын береді, бірақ OV және EV бермейді; жеке кілт сайт иесінің жағында жасалады және сақталады. Дереккөз: Let’s Encrypt ресми FAQ.

Домендер саны

• Бір атауға арналған сертификат SAN өрісінде көрсетілген нақты домендік атауды қамтиды.
• Көп доменді сертификат SAN өрісінде бірнеше атауды қамтиды. SAN және UCC атаулары көбінесе әртүрлі қорғаныс күшін емес, бірдей механизмді сипаттайды.
• Wildcard-сертификаты *.example.ua сияқты бірінші деңгейдегі қосалқы домендерді қамтиды, бірақ әдетте бөлек жазбасыз example.ua-ның өзін қамтымайды. Мұндай сертификаттың бір ұрланған жеке кілті барлық қамтылған қосалқы домендер үшін қауіп тудырады. OWASP wildcard-ты тек негізделген қажеттілік болған кезде ғана пайдалануға және оны сенімділік деңгейі әртүрлі жүйелер арасында бөліспеуге кеңес береді.

Жарамдылық мерзімі және автоматты түрде ұзарту

Жалпыға қолжетімді TLS-сертификаттарының мерзімдері қысқаруда. CA/Browser Forum-ның қолданыстағы базалық талаптарына сәйкес, 2026 жылғы 15 наурыздан 2027 жылғы 15 наурызға дейін берілген сертификаттар 200 күннен артық жарамды бола алмайды. 2027 жылғы 15 наурыздан бастап шектеу 100 күнді, ал 2029 жылғы 15 наурыздан бастап — 47 күнді құрайды. Дереккөз: CA/Browser Forum TLS Baseline Requirements 2.2.2.

2026 жылғы шілдедегі жағдай бойынша Let’s Encrypt стандартты сертификаттары 90 күн бойы жарамды, ал бөлек профиль қысқарақ сертификаттарды пайдалануға мүмкіндік береді. Иесі күнтізбелік сатып алу күнін емес, автоматты ACME клиентінің жұмысын, жаңа сертификаттың сәтті орнатылуын және веб-сервер конфигурациясының қайта іске қосылуын немесе қайта оқылуын бақылауы керек.

Шабуылдар мен іркілістердің негізгі сценарийлері

HTTPS-ті қалай дұрыс баптау керек

1. Атаулар тізімін жасаңыз. Негізгі доменді, www бар нұсқасын, төлем және қызметтік қосалқы домендерді (егер олар шынымен қолданылса) қосыңыз. Ыңғайлылық үшін ғана wildcard сатып алмаңыз.
2. Сертификатты серверде немесе басқарылатын платформа арқылы шығарыңыз. Жеке кілтті мессенджерлерде, пошта арқылы жіберуге немесе ортақ қалтада сақтауға болмайды.
3. Толық циклді автоматтандырыңыз. ACME-клиент жаңа сертификат алып, оны орнатып, сервер конфигурациясын қайта оқып, қате туралы хабарлауы керек. Бөлек сыртқы мониторинг сатып алушы көретін нақты сертификатты тексеруі керек.
4. Заманауи хаттамаларды қалдырыңыз. OWASP әдепкі бойынша TLS 1.3 пайдалануды және үйлесімділік үшін TLS 1.2 қолдауды ұсынады. TLS 1.0, TLS 1.1, SSL 2.0 және SSL 3.0 өшірілуі керек. 2026 жылғы шілдедегі жағдай бойынша NIST-тің жарияланған қолданыстағы нұсқаулығы SP 800-52 Rev. 2 болып қалады; NIST оны 2026 жылы қайта қарай бастады.
5. HTTP-ті HTTPS-ке қайта бағыттаңыз. 301 немесе 308 тұрақты серверлік қайта бағыттауды пайдаланыңыз. HTTPS-мекенжайларды canonical, сайт картасында және hreflang ішінде көрсетіңіз. Google дұрыс HTTPS-беттерді канондық ретінде қалайды, бірақ HTTPS-тің өзі іздеудегі позицияларға кепілдік бермейді. Дереккөз: Канондық URL мекенжайлар бойынша Google ұсыныстары.
6. Аралас мазмұнды алып тастаңыз. Суреттер, қаріптер, стильдер, скрипттер, формалар және API сұраулары HTTPS арқылы жүктелуі керек. Белсенді HTTP-мазмұнды браузер бұғаттауы мүмкін, ал оны ауыстыру бөгде кодты орындауға мүмкіндік береді.
7. Тексергеннен кейін HSTS қосыңыз. Strict-Transport-Security тақырыбы браузерге бұдан былай HTTPS-ті пайдалануды бұйырады. Алдымен барлық қосалқы домендерді тексеріп, кішігірім max-age мәнінен бастаңыз; қате HSTS конфигурациясы сайтты қолжетімсіз етуі мүмкін. Қайта бағыттаулар, HSTS және қорғалған cookie файлдары бойынша нұсқаулар HTTPS-ті қосу бойынша web.dev нұсқаулығында келтірілген.
8. Басқару панельдерін қорғаңыз. Тіркеуші, DNS, CDN, хостинг, CMS және пошта үшін бөлек тіркелгілерді, көп факторлы аутентификацияны және ең қажетті минималды құқықтарды пайдаланыңыз. Жұмыстан шығарылған қызметкерлер мен бұрынғы мердігерлердің рұқсаттарын өшіріңіз.
9. Сертификаттардың шығарылуын бақылаңыз. Certificate Transparency журналдары домендеріңіз үшін берілген сертификаттарды көруге және күтпеген шығарылымды анықтауға мүмкіндік береді. Мониторлардың жұмыс істеу принципі Certificate Transparency сайтында сипатталған.

HTTPS және төлемдерді қабылдау

Егер дүкен сатып алушыны банктің, эквайердің немесе басқа төлем провайдерінің бетіне қайта бағыттаса, дүкеннің TLS байланысы жолды тек өту сәтіне дейін ғана қорғайды. Төлем бетінде өзінің жарамды сертификаты болуы керек, ал мекенжайды провайдердің құжаттамасымен тексеру қажет. Дүкен өз бетінше карта үшін өрістер қоспауы, CVV сақтамауы немесе деректемелерді өз базасы арқылы тасымалдамауы керек, егер мұндай архитектура эквайермен келісілмеген болса және қолданыстағы PCI DSS талаптарына сәйкес келмесе.

Украинаның Ұлттық банкі онлайн-төлемдер кезіндегі алаяқтық және жалған интернет-дүкендер туралы бөлек ескертеді. Сатып алушы үшін бұл HTTPS-тің болуын сайттың дәл мекенжайымен, төлем әдісімен және сатушыны тексерумен бірге бағалау керектігін білдіреді. Практикалық материалдар ҰБУ-дың «ШахрайГудбай» ресми ресурсында жинақталған.

Стандарттың қолданыстағы нұсқасы PCI DSS 4.0.1 болып табылады. 2025 жылғы 31 наурызда күшіне енген төлем беттерінің қауіпсіздігіне қойылатын талаптар скрипттерді авторизациялауға, олардың тұтастығын тексеруге және рұқсатсыз өзгерістерді анықтауға бағытталған. Олар браузердегі код формадан деректемелерді көшіретін веб-скиммингке қарсы тұрады. Дереккөз: PCI SSC: Payment Page Security and Preventing E-Skimming.

Егер браузер сертификат қатесін көрсетсе не істеу керек

1. Сатып алушылардан ескертуді айналып өтуді сұрамаңыз. Егер тапсырысты рәсімдеудің қауіпсіз жолы қолжетімсіз болса, жарнама трафигін және төлемдерді уақытша тоқтатыңыз.
2. Қатені тіркеңіз. Дәл уақытты, доменді, қате мәтінін, скриншотты, сыртқы мониторинг деректерін және хостингтегі соңғы өзгерістерді сақтаңыз.
3. Себебін тексеріңіз. Типтік нұсқалар: мерзімі өткен; сертификат басқа атауға берілген; сервер ескі сертификатты қайтарады; аралық сертификат жоқ; сервердегі уақыт қате; CDN мен негізгі сервердің конфигурациялары әртүрлі; автоматты ұзарту орындалды, бірақ веб-сервер жаңа файлды қайта оқымады.
4. Конфигурацияны түзетіңіз. Қажет болса, сертификатты қайта шығарыңыз, толық тізбекті орнатыңыз және әрбір жалпыға қолжетімді доменді әртүрлі желілерден тексеріңіз.
5. Тапсырысты рәсімдеуді тексеріңіз. Каталогты, авторизацияны, себетті, төлем провайдеріне қайта бағыттауды, төлемнен кейін оралуды, хабарламаларды және интеграциялық сұрауларды тексеріңіз.
6. Ұйымдастырушылық себебін табыңыз. Автоматтандыруды түзетіңіз, сыртқы хабарлама қосыңыз, процесс иесін және резервтік контактіні құжаттаңыз.

Кілт немесе веб-сервер бұзылған кезде не істеу керек

1. Зақымдалған түйінге кіруді шектеңіз. Ағымдағы зиянды тоқтату үшін қажет болмаса, дәлелдемелер бекітілгенге дейін файлдар мен журналдарды жоймаңыз және жүйені қайта орнатпаңыз.
2. Дәлелдемелерді сақтаңыз. Жүйенің немесе дискінің суретін жасаңыз, веб-сервер, CDN, CMS, DNS, хостинг және аутентификация панельдерінің журналдарын экспорттаңыз. Уақытты бірыңғай уақыт белдеуінде тіркеңіз.
3. Сертификатты қайтарып алыңыз. Тексерілген жүйеде жаңа жеке кілт жасап, жаңа сертификат алыңыз. Ескі кілтпен жай ғана ұзарту бұзылуды жоймайды.
4. Байланысты құпияларды өзгертіңіз. Әкімшілердің құпия сөздері мен сеанстарын, API кілттерін, дерекқорға, SSH-қа, хостинг панельдеріне, CDN, тіркеушіге, DNS-ке, поштаға және репозиторийге кіру рұқсаттарын өзгертіңіз. Таза құрылғыдан бастаңыз.
5. Сайтты тексеріңіз. Жаңа әкімшілерді, өзгертілген файлдарды, бөгде скрипттерді, тапсырма жоспарлаушыларын, веб-қабықшаларды (веб-шелл), қайта бағыттау ережелерін, өзгертілген төлем деректемелерін және CT журналдарында күтпеген сертификаттарды іздеңіз.
6. Тек тексерілген көшірмеден ғана қалпына келтіріңіз. Көшірме бұзылуға дейін жасалған болуы және бөлек ортада тексерілуі керек. Қалпына келтіргеннен кейін жаңартуларды орнатыңыз, бастапқы себебін жойыңыз және содан кейін ғана сайтты жұмысқа қайтарыңыз.
7. Қатысты тараптарға хабарлаңыз. Хостингті, әзірлеушіні, эквайерді, дербес деректерге жауапты адамды және заңгерді тартыңыз. Киберинцидент туралы CERT-UA-ға хабарлауға болады; қылмыстық құқық бұзушылық немесе алаяқтық белгілері туралы — Киберполицияның электрондық өтініштер жүйесі арқылы.

Резервтік көшірмелер және қалпына келтіру

Сертификат сайттың резервтік көшірмесі емес. Қалпына келтіру үшін кодтың, дерекқордың, жүктелген файлдардың, веб-сервер конфигурациясының, DNS жазбаларының, CDN ережелерінің, интеграция баптауларының тексерілген көшірмелері және сертификатты шығарудың құжатталған процесі қажет. Жеке кілтті қажетсіз көбейтпеген жөн: көптеген конфигурацияларда жаңа кілт жасап, сертификатты қайта шығарған қауіпсіз.

Жұмыс серверінен және оның тұрақты қолжетімді тіркелгілерінен бөлек кем дегенде бір көшірмені сақтаңыз. Резервтік көшірмелердің тұтастығын үнемі тексеріп отырыңыз және оқшауланған ортада тесттік қалпына келтіруді орындаңыз. CISA маңызды деректердің автономды шифрланған көшірмелерін қолдауды және апаттық қалпына келтіру сценарийінде олардың қолжетімділігі мен тұтастығын үнемі тексеріп отыруды ұсынады. Дереккөз: CISA StopRansomware Guide.

HTTPS, Торгсофт және дүкеннің Windows-сервері

Интернет-дүкеннің TLS-сертификаты тиісті доменмен веб-байланысты қорғайды. Ол жергілікті серверді немесе Торгсофт орнатылған негізгі компьютерді, кассалық компьютерлерді, желілік қалталарды және резервтік көшірмелерді қорғамайды. Бұл жүйелер бөлек қорғауды қажет етеді.

• Торгсофт орнатылған серверді немесе негізгі компьютерді бағдарлама мен дерекқордың жұмысы үшін ғана пайдаланған жөн;
• онда поштаны оқуға, мессенджерлерді ашуға, кездейсоқ файлдарды жүктеп алуға, бөгде сайттарды қарауға және қажетсіз бағдарламаларды орнатуға болмайды;
• жалпыға қолжетімді интернеттен тікелей RDP-кіруді ашуға болмайды;
• қашықтан кіруді бақылаумен қамтамасыз ету керек: VPN немесе басқа қорғалған шлюз арқылы, бөлек тіркелгілермен, журнал жүргізумен және көп факторлы аутентификациямен (егер таңдалған шешім оны қолдаса);
• қызметкерлер тұрақты әкімші құқықтарынсыз жұмыс істеуі керек;
• сол сервердегі немесе тұрақты қосылған дискідегі көшірме негізгі деректермен бірге зақымдалуы немесе шифрлануы мүмкін;
• қалпына келтіру үшін бұзылуға дейін жасалған және тесттік өрістету арқылы тексерілген жарамды көшірме қажет.

Кім не үшін жауап береді

Практикалық чек-парақ (Checklist)

Конфигурацияны сырттай тексеру үшін Qualys SSL Labs Server Test қолдануға болады. OWASP сондай-ақ баптауларды күшейткеннен кейін конфигурацияны тексеруді ұсынады және TLS Cheat Sheet-те онлайн және локальды құралдардың тізімін келтіреді. Автоматты тест себетті, авторизацияны, төлемге өтуді, API-ді және резервтік көшірмеден қалпына келтіруді тексеруді алмастырмайды.