Шифруете конфиги — шифруйте так, чтобы инцидент не начинался с одного файла

Шифруете конфиги — шифруйте так, чтобы инцидент не начинался с одного файла



Конфиг — это не «удобный JSON». Это точка сборки доступа: токены, куки, прокси, ключи API, ротация, лимиты. Если он лежит в открытом виде, любой бэкап, лог или утечка из рабочей машины превращается в компрометацию всей инфраструктуры. Статистика показывает следующее: ломают не всегда серверы, чаще — дисциплину хранения.

Базовый минимум выглядит скучно, но работает:
— хранить секреты отдельно от логики;
— шифровать конфиги на диске и в резервных копиях;
— не дублировать один и тот же ключ в десятке сервисов;
— выдавать доступ по принципу минимально необходимого;
— вести ротацию и отзыв как обязательную процедуру, а не «когда-нибудь».

Отдельно смотрите на логи и CI/CD. Системы любят щедро писать в stdout то, что им писать не следовало бы. Если в пайплайне есть сбор артефактов, окружения и дампы переменных, считайте это дополнительным контуром риска. Хорошая практика — маскирование, раздельные роли и проверка, что секрет не попадает в сборку даже случайно.

Оптимизируем пороговые значения: если доступ к конфигу нужен человеку реже одного раза в неделю, он не должен лежать у него локально в открытом виде. Храните секреты так, будто утечка уже произошла, и тогда развертывание пройдет в штатном режиме.