Захист Telegram-бота: збереження токена, сервера та даних користувачів

Наталя Зарудня

Наталя ЗарудняГоловна редакторкаГоловна редакторка та засновниця CyberCalm. Має понад 10-річний досвід у сфері кібербезпеки та технологічної журналістики. Пише про захист даних, мобільну безпеку, штучний інтелект та соціальні мережі.Слідкуйте: 25.08.2026Поділитися15 хвилин читання

Злом Telegram-бота не завжди починається зі складних кібератак. Часто вистачає токена, що потрапив у старий Git-репозиторій, резервної копії .env, доступної через веб, або процесу, який працює на сервері з надмірними правами.

Зміст

Витік токена означає повну втрату контролю над ботом
Секретні дані потрібно відокремлювати від програмного коду та файлової системи сайту
Навіть захищений код не врятує бота, якщо сервер погано охороняється
Webhook слід захищати так само, як будь-який зовнішній API
Команди, що надходять від користувача, не можна автоматично вважати дозволеними діями
Даних користувачів слід зберігати менше, ніж бажає розробник
Логи повинні допомагати у розслідуванні, а не створювати нові витоки
Безпеку бота потрібно перевіряти як цілісний ланцюжок, а не одним тестом

Тому безпеку бота слід розглядати як ланцюг: секрети, сервер, webhook, авторизація дій, дані користувачів та журнали. Якщо один із цих елементів є слабким, захист решти не гарантує безпеки всієї системи.

Нижче наведено практичний план аудиту: що саме перевіряти, які ознаки мають викликати занепокоєння та які дії виконати, якщо проблема вже виявлена.

Витік токена означає повну втрату контролю над ботом

Якщо токен Telegram-бота потрапив до рук сторонньої особи, його потрібно не просто «приховати», а перевипустити. Токен Bot API функціонує як секрет автентифікації: той, хто його отримав, може звертатися до API від імені бота без додаткового пароля чи коду підтвердження.

Де токен найчастіше опиняється випадково

Очевидний ризик — токен, записаний безпосередньо в коді. Однак на практиці секрети часто витікають через менш помітні місця: старі коміти Git, налагоджувальні журнали, архіви проєкту, резервні копії конфігурацій, історія shell, Docker Compose або конфігурації CI/CD. Видалення токена з поточного файлу недостатньо — Git добре зберігає те, про що розробник вже забув.

Для первинної перевірки варто шукати не лише саме значення токена, але й назви змінних, якими його зазвичай позначають:

grep -RE “BOT_TOKEN|TELEGRAM_TOKEN” /path/to/projectgit grep “BOT_TOKEN”git log -p –all

Окремо перевірте, чи не потрапляє .env до Git:

git statusgit check-ignore .env

Що робити після підозри на витік

Якщо токен міг потрапити назовні хоча б ненадовго, вважайте його скомпрометованим. Далі без зайвих зволікань: перевипустіть токен через BotFather, замініть секрет у робочому середовищі, перезапустіть процес бота та перегляньте журнали на предмет незвичайної активності. Видалення секрету з файлу без ротації токена не усуває ризик, адже копія могла вже залишитися у сторонньої особи або в автоматичному індексі.

Секретні дані потрібно відокремлювати від програмного коду та файлової системи сайту

Токен бота, пароль бази даних та ключі сторонніх API не повинні передаватися разом із кодом. Якщо секрети записані в Python-, PHP- чи Node.js-файлах, будь-яка копія проєкту автоматично стає копією облікових даних.

Змінні середовища та .env

Для невеликого проєкту поширеним варіантом є передача секретів через змінні середовища або файл .env. Однак сам факт наявності .env нічого не гарантує. Файл не повинен знаходитись у публічній директорії вебсервера, потрапляти до репозиторію чи резервних копій, доступних через HTTP.

Для сервісу під systemd зручно використовувати окремий файл середовища, який читається лише потрібним системним користувачем. Базова перевірка прав доступу виглядає так:

ls -lastat .envchmod 600 .envchown botuser:botuser .env

Секрети в Docker і CI/CD

У контейнерному середовищі слід уникати жорстко зашитих секретів у Dockerfile або файлах, які комітяться разом із проєктом. Для CI/CD краще використовувати сховище секретів самої системи та не виводити значення змінних у build-лог. Production і test також слід розділяти: один і той самий токен або пароль у двох середовищах збільшує площу ризику.

Добра перевірка тут дуже проста: код можна передати розробнику або зберегти в репозиторії, не передаючи разом із ним робочі секрети. Якщо це неможливо, межа між кодом і конфігурацією проведена некоректно.

Навіть захищений код не врятує бота, якщо сервер погано охороняється

Telegram-бот не повинен працювати з надмірними системними правами. Якщо процес запущено від root, вразливість у самому застосунку потенційно надає атакувальнику значно більше можливостей, ніж потрібно боту для нормального функціонування.

SSH і системний користувач

Для бота доцільно створити окремого Linux-користувача, надати йому доступ лише до каталогу застосунку та запускати сервіс через systemd від його імені. Для адміністративного SSH краще використовувати ключі, обмежити прямий вхід root і не залишати парольну авторизацію «про всяк випадок», якщо вона не потрібна.

У sshd_config варто перевірити параметри PermitRootLogin і PasswordAuthentication, а після внесення змін — переконатися, що новий спосіб входу справді працює, перш ніж закривати поточну сесію.

Порти, firewall і зайві сервіси

Спочатку проаналізуйте, що реально слухає мережу й запущено в системі:

ss -tulpnsystemctl –type=service –state=runningufw status

ufw status є доречним, якщо на сервері використовується UFW; для nftables або firewalld потрібно перевірити відповідні правила. Список відкритих портів має бути коротким і зрозумілим: SSH, вебсервер для webhook та лише ті служби, які реально потрібні. Не варто відкривати порт лише тому, що так швидше під час налагодження. Якщо база даних використовується виключно локально, їй зазвичай не потрібен публічний доступ з Інтернету.

Безпека залежить також від способу розгортання: чим менше ручних операцій із секретами та файлами, тим нижчий ризик випадкової помилки. Такий підхід із винесенням керування ботом у вебпанель використовується, зокрема, на сайті UkrLine, але сама панель не замінює захист ОС, контроль прав, firewall та регулярні оновлення.

Для журналу конкретного процесу корисна команда:

journalctl -u bot.service

Якщо бот приймає файли, запускає фонові завдання або працює з БД, принцип найменших привілеїв є особливо важливим: процес повинен отримувати рівно ті права, без яких він не може виконати свою функцію.

Webhook слід захищати так само, як будь-який зовнішній API

HTTPS сам по собі не робить webhook Telegram-бота захищеним від сторонніх запитів. TLS охороняє канал, але не вирішує питання, кому дозволено надсилати запити до endpoint. Застосунок все одно повинен відрізняти очікуваний запит від довільного POST, надісланого на ту саму адресу.

Secret token для webhook

Під час налаштування webhook доцільно встановити secret token і перевіряти заголовок X-Telegram-Bot-Api-Secret-Token перед обробкою update. Якщо значення не збігається, запит має завершуватися помилкою 4xx без запуску бізнес-логіки.

Перевірка повинна бути першим кроком у ланцюжку. Якщо застосунок спочатку парсить великий body, звертається до БД і лише потім перевіряє секрет, захисний механізм спрацьовує запізно.

Rate limiting і контроль запиту

Для webhook корисно обмежити розмір request body, додати rate limiting на рівні Nginx або застосунку та не зберігати повний вміст кожного запиту в логах без реальної потреби. Це не заміна перевірці secret token, а окремий шар захисту від шуму, помилкових інтеграцій та простих спроб перевантаження endpoint.

Найкраще перевірити це не лише очима в конфігурації, а й за допомогою запиту. Наприклад, для тестового endpoint:

curl -i -X POST https://bot.example.com/webhook -H “Content-Type: application/json” -H “X-Telegram-Bot-Api-Secret-Token: correct-secret” -d ‘{“update_id”:1}’curl -i -X POST https://bot.example.com/webhook -H “Content-Type: application/json” -H “X-Telegram-Bot-Api-Secret-Token: wrong-secret” -d ‘{“update_id”:1}’

Другий запит повинен отримати 4xx і не дійти до обробника подій бота. Саме це підтверджує, що контроль доступу реально функціонує, а не просто присутній у коді.

Команди, що надходять від користувача, не можна автоматично вважати дозволеними діями

Callback-кнопка Telegram не є механізмом контролю доступу. Те, що користувач не бачить адміністративної кнопки в інтерфейсі, не означає, що серверна функція захищена. Авторизацію потрібно перевіряти на бекенді під час кожної привілейованої операції.

user_id, роль і дозвіл — не одне й те саме

user_id допомагає ідентифікувати користувача, але цього недостатньо для складнішого бота. Потрібно окремо визначати ролі та набір дозволених дій: наприклад, оператор може переглядати заявки, але не змінювати налаштування або видаляти дані.

Для невеликого службового бота allowlist із конкретними user_id може бути достатнім, однак перевірка має виконуватися перед кожною адміністративною дією. Не варто будувати захист лише навколо команди /admin, прихованого меню або значення callback_data.

Критичні операції

Видалення даних, зміна реквізитів, запуск зовнішніх завдань або інші ризиковані операції краще підтверджувати окремо. Для багатокрокових сценаріїв можна використовувати короткоживучий стан або одноразову ознаку підтвердження, щоб стара кнопка не запускала дію через тривалий час після створення.

Перевірити логіку варто негативним тестом: сформувати той самий виклик від користувача без потрібної ролі та переконатися, що сервер відмовляє незалежно від того, як саме була викликана функція — командою, callback або іншим маршрутом.

Даних користувачів слід зберігати менше, ніж бажає розробник

Найбезпечніші персональні дані — ті, які бот не зберігає без потреби. Якщо для функціонування достатньо user_id та статусу заявки, немає сенсу роками накопичувати повні тексти повідомлень, телефони, файли та службові копії «про всяк випадок».

Мінімізація даних

Для кожного поля в БД має бути чітка відповідь на два питання: навіщо воно потрібне та як довго його слід зберігати. Якщо відповіді немає, поле варто переглянути. Компрометація БД не може розкрити дані, яких у ній ніколи не було.

Паролі, ключі та доступ до БД

Паролі користувачів не слід зберігати у відкритому вигляді або «шифрувати так, щоб потім розшифрувати». Для паролів потрібне стійке хешування, наприклад Argon2id або bcrypt. Токени, API-ключі та інші секрети мають зберігатися окремо від звичайних даних і бути доступними лише тим процесам, яким вони справді потрібні.

Обліковий запис БД для бота також не повинен мати зайвих прав. Якщо застосунку не потрібне створення нових користувачів БД або адміністративні операції, таких дозволів у його облікового запису бути не повинно.

Резервні копії теж містять дані

Backup часто випадає з уваги під час аудиту, хоча це ще одна копія тієї самої бази. Потрібно перевірити, де зберігаються резервні копії, хто має до них доступ, чи не потрапляють вони до публічних каталогів і як довго зберігаються. Якщо основну БД очищують через 30 днів, а архіви зберігаються роками, політика видалення фактично не працює.

Логи повинні допомагати у розслідуванні, а не створювати нові витоки

Debug-лог корисний рівно до моменту, поки сам не стає джерелом витоку. BOT_TOKEN, паролі, cookie, приватні ключі, заголовки Authorization та повні тіла приватних повідомлень не повинні записуватися «для зручності».

Що варто залишати в журналі

Для більшості інцидентів достатньо часу події, типу операції, результату, коду помилки, технічного ідентифікатора користувача за потреби та запису про відмову в авторизації. Такі дані дозволяють відновити послідовність подій, не копіюючи в лог увесь вміст запиту.

Швидкий аудит журналів можна розпочати з пошуку очевидних маркерів:

grep -REi “token|authorization|password” /var/log/

Результати потрібно переглядати вручну: саме слово authorization ще не означає витік. Мета — знайти фактичні значення секретів або надмірно детальні дампи.

Ротація та права доступу

Для файлових логів налаштовується ротація, наприклад через logrotate; для systemd-сервісів контролюються журнали через journalctl. Окремо перевіряються права читання та термін зберігання. Лог, який без ротації росте роками, одночасно створює ризик витоку та ризик заповнення диска.

Вимкнення журналювання повністю також не варто робити. Після інциденту без логів складно зрозуміти, чи була проблема одиничним збоєм, помилкою конфігурації або реальною спробою несанкціонованої дії.

Безпеку бота потрібно перевіряти як цілісний ланцюжок, а не одним тестом

Первинний аудит Telegram-бота варто проводити послідовно: токен → сервер → webhook → права користувачів → дані → логи. Компрометація будь-якого одного компонента може зробити захист інших рівнів недостатнім, тому перевірка лише BOT_TOKEN або firewall дає хибне відчуття безпеки.

Проблема	Що під ризиком	Як перевірити	Перша дія
Токен у Git	Керування Bot API	git log, git grep	Перевипустити токен
.env доступний через веб	Токени, БД, API-ключі	HTTP-перевірка, права файлу	Закрити доступ і змінити секрети
SSH із паролем для root	Увесь сервер	sshd_config	Обмежити root і перейти на ключі
Webhook без secret token	Endpoint бота	Тестовий POST-запит	Додати перевірку секрету
Права перевіряються не завжди	Привілейовані функції	Негативний тест іншим акаунтом	Додати server-side авторизацію
Секрети в логах	Токени й приватні дані	grep журналів	Маскування та ротація

Короткий чек-лист перед запуском або після оновлення

Токен відсутній у репозиторії та старих публічних архівах.
.env не доступний через веб і має обмежені права.
Бот працює від окремого системного користувача, а не від root.
SSH налаштований через ключі, зайві порти закриті firewall.
ОС, бібліотеки та залежності регулярно оновлюються.
Webhook працює через HTTPS і перевіряє secret token перед обробкою update.
Привілейовані дії щоразу перевіряють user_id і роль.
callback_data не використовується як доказ дозволу на операцію.
Бот не накопичує дані, які не потрібні його функціям.
База даних не відкрита в Інтернет без реальної потреби.
Резервні копії мають окремий контроль доступу та строк зберігання.
У логах немає токенів, паролів, Authorization headers та інших секретів.
Налаштована ротація журналів і можна бачити помилки авторизації та падіння процесу.

Такий аудит не замінює повноцінного тестування безпеки складної системи, але добре допомагає виявити типові конфігураційні помилки. Якщо після перевірки кожен рівень має зрозумілу відповідь на питання «хто має доступ, навіщо і як це контролюється», захист бота вже не тримається на одному випадково добре налаштованому компоненті.

Будь ласка, залиште це поле порожнім

О, привіт
Приємно познайомитися!

Ми не розсилаємо спам! Ознайомтеся з нашою політикою конфіденційності для отримання додаткової інформації.

Перевірте свою поштову скриньку або папку зі спамом, щоб підтвердити підписку.

ТЕГИ:TelegramTelegram-ботБезпека данихПоділитисяFacebookThreadsКопіювати посиланняДрукВаші думки?В захваті0Сумно0Смішно0Палає0Овва!0Попередня публікація