Аудит конфігурації HTTPS / TLS
Цільовий аудит того, як ваш ендпоінт узгоджує TLS і віддає HTTPS — для команд, яким замало значка «A+». Ми перевіряємо версії протоколів, вибір шифрів і forward secrecy, увесь ланцюг сертифікатів та відкликання, HSTS/preload, mixed content і заголовки безпеки, після чого видаємо пріоритезований список виправлень за базами Mozilla і NIST.
Що ми перевіряємо
Перелічення версій протоколів
Перевіряємо підтримку SSLv2/SSLv3/TLS1.0/1.1/1.2/1.3 і позначаємо будь-яке узгодження TLS 1.0/1.1 або SSL, які застаріли (RFC 8996) і заборонені PCI DSS та NIST SP 800-52r2.
Набори шифрів і forward secrecy
Перелічуємо запропоновані набори за кожним протоколом, перевіряємо обмін ключами ECDHE/DHE для forward secrecy і позначаємо RC4, 3DES, застарілі режими CBC, NULL, EXPORT та анонімні набори, а також слабкі параметри DH (<2048 біт).
Ланцюг і термін сертифіката
Валідуємо кінцевий сертифікат, проміжні та порядок ланцюга, довжину ключа й алгоритм підпису (позначаючи SHA-1 і RSA <2048), вікно дії, відповідність SAN/імені хоста та випадки self-signed чи недовіреного кореня.
Відкликання: OCSP і stapling
Перевіряємо доступність OCSP-респондера, OCSP stapling і must-staple, а також доступність CRL — щоб відкликаний сертифікат справді відхилявся, а не мовчки приймався.
HSTS і preload
Перевіряємо наявність Strict-Transport-Security, max-age щонайменше рік, includeSubDomains і право на preload та підтверджуємо, що заголовок віддається лише через HTTPS, як вимагає специфікація.
Посилення редиректів і mixed content
Підтверджуємо, що HTTP постійно перенаправляє на HTTPS до будь-якої чутливої відповіді, і скануємо сторінки на активний/пасивний mixed content (скрипти, стилі, зображення через http://), що ламає межу довіри.
Вразливість до відомих атак TLS
Тестуємо BEAST, POODLE, Heartbleed (CVE-2014-0160), ROBOT, CRIME/BREACH, Sweet32, LOGJAM, FREAK і помилки ренеґоціації безпечною детекцією класу testssl — без експлуатації живих даних.
Заголовки безпеки відповіді
Розбираємо CSP (включно з upgrade-insecure-requests), X-Content-Type-Options, X-Frame-Options/frame-ancestors, Referrer-Policy і Permissions-Policy на предмет прогалин, що послаблюють транспортний рівень.
Методологія
- 1
Обсяг і розвідка
Підтверджуємо авторизацію та хости/порти в обсязі, потім перелічуємо кожен ендпоінт, що термінує TLS — apex, www, піддомени API, балансувальники та краї CDN — оскільки конфігурація між ними часто розходиться.
- 2
Автоматичне базове сканування
Запускаємо інструменти класу testssl.sh і перевірки у стилі Mozilla Observatory по кожному ендпоінту, фіксуючи протоколи, порядок шифрів, дані сертифікатів і заголовки як відтворюване свідчення.
- 3
Ручна верифікація
Вручну підтверджуємо знахідки — узгоджуючи конкретні набори, проходячи ланцюг, перевіряючи stapling — щоб усунути хибні спрацювання сканера до потрапляння у звіт.
- 4
Зіставлення з базами та оцінка
Кожну знахідку оцінюємо відносно Mozilla Intermediate/Modern і NIST SP 800-52r2, з CVSS там, де застосовний CVE, щоб серйозність відображала реальний стандарт, а не літерну оцінку інструмента.
- 5
Звіт і рекомендації з виправлення
Ви отримуєте пріоритезований звіт із точними виправленнями — рядки шифрів, директиви HSTS, лагодження ланцюга — та готовою конфігурацією для nginx/Apache/HAProxy чи вашого CDN.
- 6
Ретест і верифікація
Після усунення ми повторно скануємо змінені ендпоінти і видаємо оновлену атестацію, що підтверджує відповідність базі — у межах вікна ретесту.
Стандарти та посилання
Що ви отримуєте
- Резюме для керівництва — Односторінковий огляд ризику з поточною позицією за Mozilla/NIST і небагатьма змінами з найбільшим ефектом — для менеджменту й аудиторів.
- Технічний звіт — Деталі за кожним ендпоінтом: протоколи, повний список шифрів, ланцюг сертифікатів, заголовки, кожна знахідка з серйозністю, свідченням і кроками відтворення.
- Готова ремедіація — Посилені фрагменти конфігурації для nginx/Apache/HAProxy/CDN — рядки шифрів, лише TLS 1.2+, OCSP stapling, HSTS і вказівки з подання у preload.
- Атестація після ретесту — Підписаний лист-верифікація після виправлень, що підтверджує відповідність узгодженій базі — для комплаєнсу та перевірок безпеки з боку клієнтів.
Часті запитання
Скільки триває аудит TLS і скільки коштує?+
Один хост зазвичай готовий за 1–2 робочі дні; набір пов'язаних ендпоінтів (apex, www, кілька піддоменів API) — за 3–5. Ціна фіксована для обсягу і залежить від кількості ендпоінтів, що термінують TLS, тож ви знаєте вартість до старту, а не платите погодинно.
Що потрібно від нас для початку?+
Достатньо хостів/IP і портів в обсязі та письмової авторизації від власника домену чи інфраструктури. Аудит виконується за вашим публічним TLS-ендпоінтом, тож не потрібні вихідний код, облікові дані чи встановлення агентів — хоча відомості про CDN і WAF перед сервісом допомагають точно протестувати кожен шар.
Чи безпечно запускати це по продакшену?+
Так. Перевірки — це зонди конфігурації й узгодження плюс безпечна, неруйнівна детекція вразливостей (класу testssl). Ми не експлуатуємо знахідки, не викрадаємо дані й не створюємо значного навантаження. Тести Heartbleed і подібні використовують м'яку детекцію, що не читає пам'ять і не пошкоджує сервіс.
Чи входить ретест після виправлень?+
Так. Один ретест виправлених ендпоінтів входить в обумовлене вікно (зазвичай 30 днів) і завершується оновленою атестацією. Якщо потрібне безперервне покриття за ротації сертифікатів і дрейфу конфігурації, ми пропонуємо і плановий моніторинг.
Ви просто дасте мені оцінку SSL Labs?+
Ні. Літерні оцінки приховують реальний ризик — сайт може мати «A», але все ще не мати HSTS preload, stapling чи коректного ланцюга. Ми зіставляємо кожну знахідку з Mozilla і NIST SP 800-52r2 і пріоритезуємо за реальним впливом, з точними виправленнями замість значка.
Чи перевіряєте ви також заголовки безпеки HTTP?+
Так. Безпека транспорту слабшає, якщо шар відповіді слабкий, тому ми розбираємо HSTS, CSP (включно з upgrade-insecure-requests), X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy і Permissions-Policy та позначаємо mixed content, що ламає межу довіри HTTPS.