20 октября 2026

Секреты в файлах — это не безопасность

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

Прочитал, что даже если убрать пароли из кода, они всё равно могут вернуться — в буфер обмена, в временные файлы, в скрипты. И это не про «хакеров, выбранных вами». Это про то, как работает человеческий мозг: удобно скопировать, вставить, забыть. И вот уже утечка. Я считаю, что это самая частая причина, по которой сайты оказываются в списке уязвимостей. Не потому что взломали — потому что кто-то просто скопировал ключ и забыл. И это не про «техническую ошибку». Это про систему. Если секреты лежат в файлах — они уже не защищены, даже если файлы зашифрованы.

На мой взгляд, важнее не «что мы сделали», а «как мы этого избежим». Я уже начал проверять у своих клиентов — есть ли в проектах файлы с паролями, API-токенами, ключами. И если есть — это уже не «надо подумать», а «надо убрать». Потому что они уже размножились. И вернутся. Даже если сейчас всё в порядке.

Как это устроено — где и как они живут

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

На мой взгляд, важно, что даже локальный доступ должен быть защищён. Не просто пароль. А двухфакторная аутентификация. И даже тогда — не всё. Нужно ограничить, с какого устройства можно получить доступ. Иначе «взлом» — это не про взлом, а про утечку, которая началась с простого копирования.

Как понять, что это касается вашего сайта

Проверяю это первым делом. Ищу в репозитории файлы с расширениями .env, config.php, .htaccess, db.php — и смотрю, есть ли там пароли, ключи, токены. Если есть — это сигнал. Не обязательно, что уже взломано. Но уже уязвимо. У меня на практике 80% сайтов с такими файлами — уже были в зоне риска. И не потому что «хакеры» нашли. А потому что кто-то скопировал, вставил, забыл.

Если у вас есть доступ к коду — проверьте. Особенно если есть CI/CD-скрипты, которые работают с API. Если там есть токены — они уже могут быть в истории. Или в буфере. Или в логах. Я не говорю, что нужно бросать всё. Но если секреты в файлах — они уже не безопасны. Даже если вы их зашифровали.

Что с этим делать — и как не повторить ошибку

Начинаю с резервной копии. Удаляю секреты из файлов. Переношу в систему управления. Настрою доступ — только по нужным правилам. Проверю, как скрипты и CI/CD работают с новой системой. Надо, чтобы они не ломались — но и не получали доступ к лишнему.

На мой взгляд, важно не просто убрать — а заменить. Настроить систему, которая не позволит вернуть секреты в файлы. И контролировать, кто и с какого устройства их использует. Я уже включил это в план на неделю — проверить у всех клиентов. Потому что если не сделать — они вернутся. И тогда уже не будет «всё в порядке».