Привет, форумчане. Хочу рассказать историю, после которой я перестал считать безопасность чем-то из корпоративного мира, к пет-проектам будто бы не относящимся. Пет-проект живёт по своим законам: сначала ты пишешь код ради удовольствия, потом выкладываешь его в интернет, а про безопасность вспоминаешь ровно тогда, когда уже поздно. У меня это случилось прошлой весной, и весь урок занял меньше десяти минут.
У меня был небольшой сервис для заметок с авторизацией, базой и телеграм-ботом для напоминаний. Тестовый сервер я поднял на дешёвом VPS, чтобы просто показать проект друзьям. Пароль от админки, токен бота, ключ от почтового сервиса и доступ к базе лежали в одном файле конфигурации в корне репозитория, потому что так было быстрее запустить. Я искренне считал, что репозиторий приватный, а значит можно не переживать. Спойлер: приватность — это не безопасность, а переживать всё-таки стоило.
Проснулся я от сообщения знакомого: мой сервис рассылал странные письма через мой же почтовый ключ, а в таблице пользователей появились записи, которых я не создавал. Выяснилось, что неделей раньше я случайно переключил репозиторий в публичный, а в истории коммитов так и остался файл с ключами. Дальше всё было механически: автоматический сканер нашёл конфиг, чужой скрипт подключился к базе, потому что порт был открыт всему интернету, а пароль к ней был коротким. От первого чужого запроса до рассылки прошло около десяти минут. Я потратил вечер на ротацию ключей, объяснения с несколькими сервисами и письма людям, чьи адреса утекли. Было очень стыдно.
Первое, что я вынес для себя: секреты не живут в коде. Все ключи я вынес в переменные окружения, файл с локальными значениями добавил в правила игнорирования и, что важнее, прошёлся по всей истории коммитов — просто удалить файл в новом коммите недостаточно, он остаётся в старых. Отдельно завёл разные ключи для разработки и для продакшена: когда что-то протекает на тестовой среде, это неприятно, но не смертельно. И теперь у меня есть привычка ротировать ключи после любого подозрительного события, а не ждать, пока станет больно.
Второе — инфраструктура. База данных у меня больше не смотрит в интернет: доступ только с локального адреса, порты закрыты, вход в систему возможен лишь по SSH-ключам, вход под суперпользователем запрещён. Почта и прочие сервисы получили ограничения по количеству запросов, чтобы утечка ключа не превратилась в бесконечную рассылку за мой счёт. Зависимости обновляю регулярно, потому что большинство реальных взломов маленьких проектов происходит не через хитрый эксплойт, а через старую версию библиотеки и открытую дверь рядом с ней. И да, бэкапы — я не просто их делаю, а периодически проверяю, что из них реально можно восстановиться.
Третье — ритуал на десять минут. Раз в месяц я садился и проходил короткий список: проверить, не появилось ли лишних портов, включить уведомления о подозрительных входах, глянуть логи, посмотреть, нет ли в репозитории чего-то похожего на ключ. Эти десять минут не требуют ни глубоких знаний, ни отдельного человека в команде, но именно они закрывают большинство сценариев, которые я когда-то считал нереалистичными. Если честно, главный сдвиг был не в инструментах, а в голове: безопасность маленького проекта — это не паранойя, а гигиена, как вовремя помыть руки.
Мораль простая: пока проект не стал публичным, ответственность всё равно уже твоя, и цена ошибки измеряется в репутации и вечерах, потраченных на разгребание. А вот приятная новость в том, что почти все перечисленные шаги занимают копейки времени и делаются один раз, а служат годами. Спасибо, что дочитали мою исповедь — если она убережёт хотя бы один пет-проект от неприятного утра, я буду считать, что ключи протекли не зря. А какой пункт вы добавили в свой личный чек-лист после собственного опыта, пусть даже не болезненного? Делитесь в комментариях — соберём из ваших ответов народный список, который спасёт чьи-то выходные.
У меня был небольшой сервис для заметок с авторизацией, базой и телеграм-ботом для напоминаний. Тестовый сервер я поднял на дешёвом VPS, чтобы просто показать проект друзьям. Пароль от админки, токен бота, ключ от почтового сервиса и доступ к базе лежали в одном файле конфигурации в корне репозитория, потому что так было быстрее запустить. Я искренне считал, что репозиторий приватный, а значит можно не переживать. Спойлер: приватность — это не безопасность, а переживать всё-таки стоило.
Проснулся я от сообщения знакомого: мой сервис рассылал странные письма через мой же почтовый ключ, а в таблице пользователей появились записи, которых я не создавал. Выяснилось, что неделей раньше я случайно переключил репозиторий в публичный, а в истории коммитов так и остался файл с ключами. Дальше всё было механически: автоматический сканер нашёл конфиг, чужой скрипт подключился к базе, потому что порт был открыт всему интернету, а пароль к ней был коротким. От первого чужого запроса до рассылки прошло около десяти минут. Я потратил вечер на ротацию ключей, объяснения с несколькими сервисами и письма людям, чьи адреса утекли. Было очень стыдно.
Первое, что я вынес для себя: секреты не живут в коде. Все ключи я вынес в переменные окружения, файл с локальными значениями добавил в правила игнорирования и, что важнее, прошёлся по всей истории коммитов — просто удалить файл в новом коммите недостаточно, он остаётся в старых. Отдельно завёл разные ключи для разработки и для продакшена: когда что-то протекает на тестовой среде, это неприятно, но не смертельно. И теперь у меня есть привычка ротировать ключи после любого подозрительного события, а не ждать, пока станет больно.
Второе — инфраструктура. База данных у меня больше не смотрит в интернет: доступ только с локального адреса, порты закрыты, вход в систему возможен лишь по SSH-ключам, вход под суперпользователем запрещён. Почта и прочие сервисы получили ограничения по количеству запросов, чтобы утечка ключа не превратилась в бесконечную рассылку за мой счёт. Зависимости обновляю регулярно, потому что большинство реальных взломов маленьких проектов происходит не через хитрый эксплойт, а через старую версию библиотеки и открытую дверь рядом с ней. И да, бэкапы — я не просто их делаю, а периодически проверяю, что из них реально можно восстановиться.
Третье — ритуал на десять минут. Раз в месяц я садился и проходил короткий список: проверить, не появилось ли лишних портов, включить уведомления о подозрительных входах, глянуть логи, посмотреть, нет ли в репозитории чего-то похожего на ключ. Эти десять минут не требуют ни глубоких знаний, ни отдельного человека в команде, но именно они закрывают большинство сценариев, которые я когда-то считал нереалистичными. Если честно, главный сдвиг был не в инструментах, а в голове: безопасность маленького проекта — это не паранойя, а гигиена, как вовремя помыть руки.
Мораль простая: пока проект не стал публичным, ответственность всё равно уже твоя, и цена ошибки измеряется в репутации и вечерах, потраченных на разгребание. А вот приятная новость в том, что почти все перечисленные шаги занимают копейки времени и делаются один раз, а служат годами. Спасибо, что дочитали мою исповедь — если она убережёт хотя бы один пет-проект от неприятного утра, я буду считать, что ключи протекли не зря. А какой пункт вы добавили в свой личный чек-лист после собственного опыта, пусть даже не болезненного? Делитесь в комментариях — соберём из ваших ответов народный список, который спасёт чьи-то выходные.