Безпека Telegram-бота: захист токена, сервера та даних користувачів | CyberCalm

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

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

Зміст

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

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

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

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

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

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

Очевидний ризик — токен, вписаний безпосередньо в код. Але на практиці секрети часто витікають через менш помітні місця: старі коміти Git, лог-файли для налагодження, архіви проєкту, резервні копії конфігурації, історію команд оболонки, конфігурації 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Копіювати посиланняДрукПопереднє оповіданняЯк зменшити залежність від Google: що справді працює у 2026 році