Пароль в команде — это не ошибка, это риск

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

Пароль в команде — это не техническая ошибка, это риск

Статья напомнила, что любой пользователь на сервере, даже без прав, может увидеть пароль в списке процессов. Достаточно ввести `ps -eo cmd` — и вот он, пароль от БД, токен API, ключ в строке запуска. Это не про «хакеров», а про то, что кто-то просто не проверил, что видно у всех.

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

Как это работает — и почему это так просто увидеть

Когда вы запускаете команду вроде `mysql -u admin -pSecretPass123`, пароль попадает в аргументы процесса. А те лежат в `/proc/ /cmdline` — и доступны любому пользователю системы. Даже если вы не root, даже если у вас нет привилегий.

Это не уязвимость в системе — это поведение по умолчанию. И оно работает везде: в скриптах, в CI, в cron, в контейнерах. Главное — не то, что можно увидеть, а то, что уже видят. И это не только пароли: токены, ключи, секреты — всё, что передаётся в аргументах, висит на поверхности.

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

Я проверяю это первым делом, когда берусь за новый проект или проверяю старый. Достаточно трёх команд: `ps -eo cmd | grep -i password`, `grep -riE 'password=' ~/.bash_history`, и `grep -rlE 'password' /etc/cron.d /etc/systemd/system`. Если что-то выдаёт — значит, где-то пароль в открытом виде.

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

Что я делаю, когда нахожу такое

Сначала — не удаляю, а заменяю. Пароль не в аргументах, не в переменных, не в истории. Он в файле с правами 600, или передаётся через stdin, или берётся из менеджера секретов в момент использования.

Если это скрипт — переписываю его так, чтобы пароль не попадал в аргументы. Если это cron — убираю его из файла, переношу в переменные окружения (но не в `environ`, а в безопасные места), или в файл. Объём работы — зависит от того, где он живёт. Но главное — не просто убрать, а закрыть причину.

Что здесь даёт поддержка

На нашей поддержке это закрывается заранее. Мы не ждём, пока кто-то увидит пароль в процессах. Мы проверяем, где он может быть, и убираем до того, как станет проблемой. Это часть регулярной проверки инфраструктуры — не аврал, а профилактика.

Главный итог не в том, что мы починим — а в том, что вы перестанете думать о сайте. Предсказуемость вместо авралов. Мы работаем с 2002 года, более 100 клиентов по всему миру. Приглашаю на бесплатный аудит сайта — проверим, где ваша инфраструктура дышит открытым паролем.