Скритият проблем със staging сървърите: Защо търсенето на сертификати трябва да е в твоя DevOps чеклист

Забравял ли си за дрехи в дъното на гардероба? Инфраструктурата ти прави същото – само че там се крият TLS сертификати, субдомейни и стари сървъри без ъпдейти.

Феноменът на призрачните субдомейни

Представи си: разработчик стартира staging-v2.firma.com за тест на нова функция. Проектът умира. Субдомейнът остава. Две години по-късно – стар софтуер, уязвими библиотеки и никакъв мониторинг.

Тимът ти мисли, че следи пет ключови адреса. Всъщност са седемнадесет.

Най-лошото? Всички сертификати за тях са публично достъпни. Ако не ги търсиш активно, си с вързани очи.

Как работят Certificate Transparency логовете (и защо са важни)

Когато CA издаде SSL/TLS сертификат, той го логва в публични CT логове. Това е защита срещу фалшиви CAs – не могат да ти издават сертификати тайно.

Но и субдомейните ти стават публични. Искаш ли пълен списък на всичко с сертификат? Едно търсене в CT инструмент – и е готово за секунди. Ако ти можеш, правят го и другите.

Проблемът с трите слоя на откриването

Фирмите рядко знаят цялата си инфраструктура, защото данните са разпръснати:

1. DNS записи
Показват какво е активно сега. Но се променят. Стар api-old.firma.com може да е изтрит от DNS, но да виси на EC2 инстанс.

2. Живи услуги
Какво мислиш, че работи. Дашбордът го показва, документацията го описва. Staging? Тестови кутии? Забравени проекти? Те се крият в ъгъла на AWS акаунта.

3. Certificate логове
Абсолютната истина: всяко субдомейн с валиден сертификат някога. Това е твоят архив, с или без теб.

Повечето следят само един-два слоя. Там се раждат сляпите петна.

Защо удря по джоба ти

Забравените сървъри носят каскадни проблеми:

Сигурност: Непъпдейтнати апликации без логове и警报и. Лесна врата за хакери.

Комплаенс: SOC 2, ISO 27001, PCI-DSS искат пълен списък на системите. Ще кажеш ли на одитора всичко?

Разходи: Staging от 2022 все още курсира. Load balancer към нищото? Таксите се трупат. Месечно – хиляди лв.

Реакция при инцидент: Когато фраска, губиш време да търсиш забравени неща.

Как да направиш одит: Какво да провериш

Ето какво включва добър сертификатен одит:

1. Търсене в CT логове
Извлечи всички субдомейни за основния ти domain. Пълна историческа картина.

2. Тест на живи TLS връзки
Не се задоволявай с логове. За всяко субдомейн – нова TLS връзка и проверка:

• Съвпада ли сертификатът с хоста?
• Кой го е издал и кога?
• Кога изтича?
• Само-подписан ли е или от доверен CA?

3. Откриване на несъответствия
Субдомейн с сертификат, но без DNS запис? Червен флаг. Неочакван издател или изтекъл? Някой го е осиновил.

Как да изградиш трайна система за управление на сертификати

Един одит не стига. Трябва постоянен контрол:

Автоматизирай мониторинга:警报и за изтичащи сертификати – особено на забравени системи. Нищо не мотивира като грешка в продакшъна.

Свържи с инвентара: Вкарвай откритията в CMDB или asset tool. Всички да виждат забравените.

Класифицирай субдомейните: От CT логове – production? Staging? Стар? Партньорски? Контекстът спасява от объркване.

Регулярни одити: Месечно или тримесечно. Сравнявай с предишни – виж нови или неавторизирани.

Подобри TLS практиките: Използвай откриванията да смениш слаби CA, добавиш OCSP stapling или HTTP/2.

Реалността в DevOps

Ако управляваш мащаб – дори десетки услуги – имаш забравени неща. Нормално е. Грешка е да работиш без пълна картина.

Търсенето на сертификати е скучна, но ключова работа. Не е за спринт ретроспективи. Но спасява от одитори и пробиви.

Започни днес

Няма нужда от нови инструменти. Един domain стига. Насочи CT търсачка към него – и виж какво изплува.

Ще се изненадаш. Всички се изненадват.

После – класифицирай, затвори и автоматизирай. Това реално укрепва сигурността.

Staging-ът от 2022 те чака. Време е да го намериш.