Секреты в скриптах и bat-никах

В каждой живой инфраструктуре со временем появляются маленькие скрипты. Один копирует базу 1С ночью. Другой выгружает файлы на FTP. Третий перезапускает службу, чистит папку обмена или отправляет отчёт. Сначала это быстрое решение «на пару дней», потом оно годами работает в планировщике, и никто не трогает — потому что страшно сломать.

Проблема начинается, когда внутри такого bat-файла лежит пароль: к базе, сетевой папке, FTP, почтовому ящику, облаку бэкапов или административной учётке. Иногда пароль прямо в строке команды. Иногда рядом в .txt. Иногда в задаче планировщика под учёткой доменного администратора. Пока всё тихо, это кажется мелочью. При проверке безопасности или инциденте оказывается, что секреты лежали там, где их мог прочитать почти любой локальный администратор.

Почему пароли в скриптах опасны

Скрипт обычно создаётся ради автоматизации, а не ради безопасности. Его кладут в удобную папку, дают права «чтобы работало», добавляют в планировщик и забывают. Через год уже непонятно, кто владелец, какой пароль используется, можно ли его сменить и что перестанет работать после ротации.

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

Есть и эксплуатационная проблема: пароль меняют, скрипт падает, бэкап не выполняется, а об этом узнают только при аварии. Поэтому хранение секретов — это не только ИБ, но и надёжность.

Где искать такие секреты

Начните с планировщика задач на серверах и ключевых рабочих станциях. Посмотрите, какие задачи запускаются ночью, от какой учётки, какие команды выполняют. Часто там находятся старые .bat, .cmd, .ps1, архиваторы с паролем в параметрах, robocopy к сетевой папке или утилиты выгрузки на внешний сервер.

Затем проверьте папки с админскими скриптами: scripts, backup, 1c, exchange, рабочий стол администратора, общие сетевые шары. Ищите не только слово password, но и русские комментарии: «пароль», «логин», «не менять», «старый сервер». Полезно смотреть конфиги приложений, файлы .env, .ini, .config, выгрузки из старых панелей.

Отдельная зона — скрипты бэкапа. Если пароль от хранилища резервных копий лежит на том же сервере, который бэкапится, атакующий может получить доступ и к данным, и к копиям. В контексте готовности к ransomware это один из первых пунктов проверки.

Как хранить иначе

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

Для приложений и скриптов, которые поддерживают переменные окружения или отдельные secret-файлы с ограниченными правами, лучше вынести секреты из кода. Сам скрипт может лежать в git или общей папке, а пароль — в защищённом месте, доступном только процессу выполнения.

Для командных секретов, которые всё равно нужны людям, используйте корпоративный менеджер паролей. Там можно хранить владельца, назначение, дату ротации, связанные системы и резервные коды. Подробнее о подходе — в статье корпоративный менеджер паролей.

Минимизируйте права

Самая частая ошибка — запускать всё от администратора, потому что так быстрее заработало. Скрипту бэкапа не всегда нужны права доменного админа. Скрипту копирования не нужен доступ ко всем шарам. Задаче выгрузки отчёта не нужен интерактивный вход на сервер.

Создайте отдельные сервисные учётки под группы задач. Дайте им только нужные права: читать конкретную базу, писать в конкретное хранилище, запускать конкретную службу. Запретите интерактивный вход, где это возможно. Зафиксируйте владельца и назначение. Тогда при компрометации одного секрета ущерб будет ограничен.

Ротация тоже становится проще. Если сервисная учётка используется только для ночного копирования, её пароль можно менять по понятному списку. Если один пароль используется в десяти местах, любое изменение превращается в квест.

Как провести аудит без остановки работы

Не начинайте с массового удаления. Сначала составьте инвентарь: файл, сервер, задача, учётка, назначение, владелец, критичность. Отметьте секреты открытым текстом и широкие права. Затем двигайтесь от самых опасных: доменные администраторы, бэкапы, доступы к 1С, внешние FTP/SFTP, почта, VPN.

Каждое изменение лучше делать с проверкой: заменили учётку, запустили задачу вручную, убедились, что результат появился, добавили мониторинг успешного выполнения. Иначе есть риск «улучшить безопасность» и незаметно выключить резервное копирование.

Такой аудит хорошо совмещается с администрированием серверов: проверить планировщик, скрипты, бэкапы, права и мониторинг. Если у вас уже есть ИТ-аутсорсинг, это стоит включить в регулярную ревизию, а не вспоминать только после инцидента.

Нормальный итог

Цель не в том, чтобы запретить все скрипты. Автоматизация нужна, особенно когда нет большого ИТ-отдела. Цель — чтобы секреты не лежали открыто, права были минимальными, а владелец понимал, что сломается при смене пароля.

Если хотите проверить серверы и планировщики на такие «вечные временные решения», напишите нам через контакты. Разберём скрипты, найдём рискованные секреты и предложим порядок исправлений без резкого выключения рабочих процессов.