Забытые staging-сервера: почему поиск сертификатов обязателен в чек-листе DevOps

Представьте: вы разбираете старый шкаф и натыкаетесь на вещи, о которых давно забыли. В вашей инфраструктуре то же самое. Только вместо одежды — TLS-сертификаты, поддомены и незащищенные серверы.

Феномен "призрачных" поддоменов

Девелопер создает staging-v2.yourcompany.com для теста фичи. Проект закрывают. Поддомен остается. Проходит пара лет — он все еще крутит старую версию приложения с дырами в зависимостях и без мониторинга.

Ваша security-команда следит за пятью ключевыми точками. А на деле их семнадцать.

Плюс: все сертификаты для этих поддоменов публично логируются. Не ищете их сами — рискуете вслепую.

Как работают CT-логи и зачем они нужны

Любая нормальная certificate authority при выдаче SSL/TLS-сертификата обязана записать это в публичные Certificate Transparency (CT) logs. Это защита от мошенников: чужой CA не сможет выдать фейковый сертификат на ваш домен тайком.

Зато вся история поддоменов теперь на виду у всех.

Хотите список всех поддоменов, для которых выдавались сертификаты? Запустите запрос к CT-логам. Получите его за секунды. Если вы можете — сможет и атакующий.

Проблема трех уровней обнаружения

Компании не знают свою инфраструктуру полностью. Данные разбросаны по трем местам:

1. DNS-записи
Показывают, что сейчас активно. Но DNS меняется. Старые записи стирают. А api-old.yourcompany.com может болтаться в настройках EC2-инстанса без DNS.

2. Активные сервисы
То, что вы считаете запущенным. Дашборды и доки это подтверждают. Но staging, тестовые боксы, замороженные проекты? Они прячутся в углу AWS-аккаунта.

3. Логи сертификатов
Истина в последней инстанции: все поддомены с валидными сертификатами когда-либо. Это ваш след, даже если вы его игнорируете.

Большинство смотрит только на 1–2 уровня. Отсюда и слепые зоны.

Почему это бьет по карману

Забытые серверы тянут за собой цепочку бед:

Риски безопасности: Необновленные приложения без логов и алертов. Идеальный вход в сеть для хакера.

Проблемы с compliance: SOC 2, ISO 27001, PCI-DSS требуют полного списка систем. Аудитор спросит — что ответите?

Утечка бюджета: Staging из 2022 жрет ресурсы. Ненужный load balancer начисляет счета. В месяц это тысячи.

Тормоза в инцидентах: Команда тратит часы на поиск "неизвестных" систем вместо реакции.

Как провести аудит: что проверять

Правильный поиск сертификатов включает:

1. Запрос к CT-логам
Вытащите все поддомены для вашего root domain. Полная история в кармане.

2. Тест TLS-handshake на живых сервисах
Не верьтесь логам — проверьте сейчас. Для каждого поддомена:

• Соответствует ли сертификат hostname?
• Кто выдал, когда?
• Когда истекает?
• Самоподписанный или от trusted CA?

3. Поиск несоответствий
Поддомен с сертификатом, но без DNS? Сертификат от lạкого issuer или просрочен? Это сирота — разбирайтесь.

Как внедрить постоянный контроль сертификатов

Разовый аудит — это старт. Нужно поддерживать:

Автоматизируйте мониторинг: Алerts на истечение сертификатов, особенно на забытых системах. Ошибка в проде — лучший будильник.

Интегрируйте в инвентарь: Загружайте данные из CT в CMDB. Забытые активы увидит вся команда.

Фиксируйте назначение поддоменов: Нашли в логах? Отметьте: prod, staging, устарел, партнерский. Контекст спасет от путаницы.

Проводите аудиты регулярно: Раз в месяц или квартал. Сравнивайте со старыми сканами — ловите новинки и изменения.

Улучшайте TLS: Заодно мигрируйте на сильные CA, добавьте OCSP stapling, HTTP/2. Полезно вдвойне.

Реальность DevOps

У масштаба — всегда забытые уголки. Это нормально, мы люди. Провал — игнорировать картину инфраструктуры.

Поиск сертификатов — скучная, но ключевая рутина. Не для спринтов, но спасет от аудита или бреши через старый staging.

Начните прямо сейчас

Хорошая новость: нужны только домен и инструмент. Укажите root domain, запросите CT-логи — увидите правду.

Удивитесь. Как все.

Дальше — классифицируйте находки, закрывайте лишнее, стройте процессы. Это реально повысит security.

Ваш staging 2022-го где-то ждет. Пора его найти.