Налаштування HTTPS для інтернет-магазину: вибір TLS та безпека

HTTPS для інтернет-магазину: що потрібно захистити

Інтернет-магазин має працювати через HTTPS на всіх сторінках: від каталогу до оформлення замовлення. Для цього потрібен чинний TLS-сертифікат, правильне налаштування вебсервера та автоматичне продовження. Сертифікат захищає дані під час передавання, але не усуває вразливості сайту, не підтверджує добросовісність продавця і не захищає сервер від шкідливого програмного забезпечення.

Що означають SSL, TLS та HTTPS

TLS — протокол, який створює захищене з’єднання між браузером покупця та сервером сайту. Він забезпечує конфіденційність переданих даних, захищає їх від непомітної зміни в дорозі та дає браузеру змогу перевірити, для якого домену видано сертифікат. Саме TLS використовується в HTTPS. Назва «SSL-сертифікат» залишилася в побуті, хоча протоколи SSL 2.0 і SSL 3.0 застаріли та не повинні застосовуватися. Це пояснює актуальна настанова OWASP щодо TLS.

Під час відкриття адреси 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; приватний ключ створюється й зберігається на стороні власника сайту. Джерело: офіційний FAQ Let’s Encrypt.

Кількість доменів

• Сертифікат для одного імені покриває конкретне доменне ім’я, зазначене в полі SAN.
• Багатодоменний сертифікат містить кілька імен у полі SAN. Назви SAN і UCC часто описують той самий механізм, а не різну силу захисту.
• Wildcard-сертифікат покриває піддомени одного рівня, наприклад *.example.ua, але зазвичай не покриває сам example.ua без окремого запису. Один викрадений приватний ключ такого сертифіката створює ризик для всіх охоплених піддоменів. OWASP радить використовувати wildcard лише за обґрунтованої потреби та не ділити його між системами з різними рівнями довіри.

Строк дії та автоматичне продовження

Строки публічних TLS-сертифікатів скорочуються. За чинними базовими вимогами CA/Browser Forum сертифікати, видані з 15 березня 2026 року до 15 березня 2027 року, не можуть діяти довше 200 днів. З 15 березня 2027 року межа становитиме 100 днів, а з 15 березня 2029 року — 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 сам по собі не гарантує позицій у пошуку. Джерело: рекомендації Google щодо канонічних URL.
6. Приберіть змішаний вміст. Зображення, шрифти, стилі, скрипти, форми та запити API мають завантажуватися через HTTPS. Активний HTTP-вміст браузер може заблокувати, а його підміна дає змогу виконати сторонній код.
7. Увімкніть HSTS після перевірки. Заголовок Strict-Transport-Security наказує браузеру надалі використовувати HTTPS. Спочатку перевірте всі піддомени й почніть із малого max-age; помилкова конфігурація HSTS може зробити сайт недоступним. Настанови щодо перенаправлень, HSTS і захищених cookie наведені в посібнику web.dev з увімкнення HTTPS.
8. Захистіть панелі керування. Для реєстратора, DNS, CDN, хостингу, системи керування сайтом і пошти використовуйте окремі облікові записи, багатофакторну автентифікацію та мінімально потрібні права. Видаліть доступ звільнених працівників і колишніх підрядників.
9. Контролюйте випуск сертифікатів. Журнали Certificate Transparency дають змогу побачити сертифікати, видані для ваших доменів, і виявити неочікуваний випуск. Принцип роботи моніторів описано на Certificate Transparency.

HTTPS і приймання платежів

Якщо магазин перенаправляє покупця на сторінку банку, еквайра або іншого платіжного надавача, TLS-з’єднання магазину захищає шлях лише до моменту переходу. Платіжна сторінка повинна мати власний чинний сертифікат, а адресу потрібно звіряти з документацією надавача. Магазин не повинен самостійно додавати поля для картки, зберігати CVV або передавати реквізити через власну базу, якщо така архітектура не погоджена з еквайром і не відповідає застосовним вимогам PCI DSS.

Національний банк України окремо попереджає про шахрайство під час онлайн-платежів і фальшиві інтернет-магазини. Для покупця це означає, що наявність HTTPS потрібно оцінювати разом із точною адресою сайту, способом оплати та перевіркою продавця. Практичні матеріали зібрані на офіційному ресурсі НБУ «ШахрайГудбай».

Чинною версією стандарту є PCI DSS 4.0.1. Вимоги до безпеки платіжних сторінок, що набрали чинності 31 березня 2025 року, зосереджені на авторизації скриптів, перевірці їхньої цілісності та виявленні несанкціонованих змін. Вони протидіють вебскімінгу, коли код у браузері копіює реквізити з форми. Джерело: PCI SSC: Payment Page Security and Preventing E-Skimming.

Що робити, якщо браузер показує помилку сертифіката

1. Не просіть покупців обходити попередження. Тимчасово припиніть рекламний трафік і платежі, якщо безпечний шлях оформлення замовлення недоступний.
2. Зафіксуйте помилку. Збережіть точний час, домен, текст помилки, знімок екрана, дані зовнішнього моніторингу та останні зміни на хостингу.
3. Перевірте причину. Типові варіанти: строк дії минув; сертифікат випущено не для того імені; сервер віддає старий сертифікат; відсутній проміжний сертифікат; неправильний час на сервері; CDN і основний сервер мають різні конфігурації; автоматичне продовження виконалося, але вебсервер не перечитав новий файл.
4. Виправте конфігурацію. Перевипустіть сертифікат за потреби, встановіть повний ланцюжок і перевірте кожен публічний домен з різних мереж.
5. Перевірте оформлення замовлення. Пройдіть каталог, авторизацію, кошик, редирект до платіжного надавача, повернення після оплати, повідомлення та інтеграційні запити.
6. Знайдіть організаційну причину. Виправте автоматизацію, додайте зовнішнє сповіщення, документуйте власника процесу й резервний контакт.

Що робити при компрометації ключа або вебсервера

1. Обмежте доступ до ураженого вузла. Не видаляйте файли й журнали та не перевстановлюйте систему до фіксації доказів, якщо це не потрібно для припинення поточної шкоди.
2. Збережіть докази. Зробіть знімок системи або диска, експортуйте журнали вебсервера, CDN, системи керування сайтом, DNS, панелі хостингу та автентифікації. Зафіксуйте час у єдиному часовому поясі.
3. Відкличте сертифікат. Створіть новий приватний ключ на перевіреній системі й отримайте новий сертифікат. Просте продовження зі старим ключем не усуває компрометацію.
4. Змініть пов’язані секрети. Змініть паролі й сеанси адміністраторів, ключі API, доступ до бази, SSH, панелі хостингу, CDN, реєстратора, DNS, пошти та репозиторію. Починайте з чистого пристрою.
5. Перевірте сайт. Знайдіть нових адміністраторів, змінені файли, сторонні скрипти, планувальники завдань, вебоболонки, правила перенаправлення, змінені платіжні реквізити та неочікувані сертифікати в журналах CT.
6. Відновлюйте лише з перевіреної копії. Копія має бути створена до проникнення та пройти перевірку на окремому середовищі. Після відновлення встановіть оновлення, усуньте початкову причину й лише потім повертайте сайт у роботу.
7. Повідомте сторони, яких це стосується. Залучіть хостинг, розробника, еквайра, відповідального за персональні дані та юриста. Про кіберінцидент можна повідомити CERT-UA; про ознаки кримінального правопорушення або шахрайства — через систему електронних звернень Кіберполіції.

Резервні копії та відновлення

Сертифікат не є резервною копією сайту. Для відновлення потрібні перевірені копії коду, бази даних, завантажених файлів, конфігурації вебсервера, DNS-записів, правил CDN, налаштувань інтеграцій і документованого процесу випуску сертифіката. Приватний ключ не варто без потреби розмножувати: у багатьох конфігураціях безпечніше створити новий ключ і перевипустити сертифікат.

Зберігайте щонайменше одну копію окремо від робочого сервера та його постійно доступних облікових записів. Регулярно перевіряйте цілісність копій і виконуйте тестове відновлення в ізольованому середовищі. CISA рекомендує підтримувати автономні зашифровані копії критичних даних і регулярно перевіряти їхню доступність та цілісність у сценарії аварійного відновлення. Джерело: CISA StopRansomware Guide.

HTTPS, Торгсофт і Windows-сервер магазину

TLS-сертифікат інтернет-магазину захищає вебз’єднання з відповідним доменом. Він не захищає локальний сервер або основний комп’ютер із Торгсофт, касові комп’ютери, мережеві папки та резервні копії. Ці системи потребують окремого захисту.

• сервер або основний комп’ютер із Торгсофт бажано використовувати лише для роботи програми та бази;
• на ньому не варто читати пошту, відкривати месенджери, завантажувати випадкові файли, переглядати сторонні сайти й установлювати непотрібні програми;
• прямий RDP-доступ із загальнодоступного інтернету відкривати не можна;
• віддалений доступ потрібно надавати контрольовано: через VPN або інший захищений шлюз, за окремими обліковими записами, з журналюванням і багатофакторною автентифікацією, якщо її підтримує вибране рішення;
• працівники повинні працювати без постійних прав адміністратора;
• копія на тому самому сервері або постійно підключеному диску може бути пошкоджена чи зашифрована разом з основними даними;
• для відновлення потрібна справна копія, створена до проникнення та перевірена тестовим розгортанням.

Хто за що відповідає

Практичний чекліст

Для зовнішньої перевірки конфігурації можна використовувати Qualys SSL Labs Server Test. OWASP також рекомендує перевіряти конфігурацію після посилення налаштувань і наводить перелік онлайн- та локальних інструментів у TLS Cheat Sheet. Автоматичний тест не замінює перевірку кошика, авторизації, платіжного переходу, API та відновлення з резервної копії.