Как вы спроектируете управление TLS-сертификатами (выпуск, ротация, mTLS между внутренними сервисами) в масштабе платформы с десятками сервисов, и какие риски и компромиссы при этом нужно обсуждать с командой?

Короткий ответ

Однозначного решения нет: выбор между ручным управлением, ACME-автоматизацией для внешних сертификатов и выделенным внутренним CA с короткоживущими сертификатами для mTLS зависит от числа сервисов, регуляторных требований, зрелости команды в вопросах PKI и допустимого риска простоя при сбое самой системы выдачи сертификатов.

Как это работает подробнее

TLS-сертификаты имеют ограниченный срок действия, и при масштабе в десятки и сотни сервисов ручное отслеживание сроков становится ненадёжным источником инцидентов; для mTLS между внутренними сервисами дополнительно нужен собственный центр сертификации (internal CA) или интеграция с системой вроде SPIFFE/SPIRE или Vault PKI, которая умеет выпускать короткоживущие сертификаты автоматически и ротировать их прозрачно для приложений, снижая окно, в течение которого скомпрометированный сертификат остаётся действительным.

Пример кода

example.txtКопировать

Схема:
- Внешние сертификаты: ACME (Let's Encrypt) + автопродление + алерт за 14 дней до истечения
- Внутренний mTLS: internal CA (например, Vault PKI) выдаёт сертификаты на 24 часа,
  сайдкар автоматически обновляет их каждые 8 часов
- Fallback: при недоступности CA сервисы продолжают работать на последнем валидном
  сертификате до его истечения, алерт срабатывает заранее

Что использовать на практике

• Практика. для внешних сертификатов (публичные домены) используют ACME-автоматизацию (Let's Encrypt или аналог) с мониторингом срока действия и алертами задолго до истечения; для внутреннего mTLS — отдельный internal CA с короткоживущими сертификатами (часы-дни, а не годы) и автоматической ротацией через сайдкар или библиотеку, что требует продуманного fallback-поведения приложений при временной недоступности системы выдачи сертификатов, чтобы сбой самого CA не обрушил весь internal-трафик одновременно.
• Компромисс. Проверка: искусственно остановить систему выдачи сертификатов на контролируемое время и убедиться, что действующие mTLS-соединения продолжают работать до истечения текущих сертификатов, а не обрываются мгновенно, что подтверждает отсутствие единой точки отказа в момент кратковременного сбоя CA.

Подводные камни

• Риск. централизовать выпуск всех сертификатов через единую систему без отказоустойчивости самой этой системы, превращая её в единую точку отказа для всего внутреннего трафика; использовать долгоживущие сертификаты для mTLS 'для простоты', увеличивая ущерб от потенциальной компрометации ключа; не тестировать сценарий одновременного истечения большого числа сертификатов при сбое процесса автоматического продления.