Перейти до вмісту

Безпека інструментів співпраці: приховані ризики в Slack, Teams та чат-платформах

A chat message bubble containing a database password, surrounded by open integrations and disconnected user avatars with warning indicators

23:47. Backend-інженер налагоджує збій у продакшені. База даних повертає помилки тайм-ауту, і черговий Slack-канал заповнюється пінгами від служби підтримки. Її колега просить облікові дані продакшн-бази даних, щоб перевірити налаштування пулу з’єднань. Вона вставляє логін і пароль прямо в канал. В каналі одинадцять людей. Троє з них підрядники, доступ яких мав закінчитися минулого кварталу. Повідомлення індексоване, доступне для пошуку і буде існувати в архіві Slack стільки, скільки існуватиме робочий простір.

Збій усувають до півночі. Облікові дані залишаються в тому каналі назавжди. Через шість місяців, коли акаунт підрядника в Slack компрометують через повторно використаний пароль, ці облікові дані стають першим, що знаходить зловмисник.

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

Що робить інструменти співпраці ризиком безпеки?

Section titled “Що робить інструменти співпраці ризиком безпеки?”

Безпека інструментів співпраці стосується політик, контролів та поведінки співробітників, які захищають корпоративні дані, що проходять через робочі чат-платформи, інструменти відеоконференцій та спільні робочі простори, такі як Slack, Microsoft Teams, Zoom та Google Chat. Ці платформи щодня обробляють величезний обсяг конфіденційної інформації. Slack повідомляє, що його середній корпоративний клієнт відправляє понад 200 000 повідомлень на місяць. Microsoft Teams перевищив 320 мільйонів активних користувачів на місяць у 2024 році. Кожне повідомлення, завантажений файл, демонстрація екрана та інтеграція є потенційною точкою експозиції, яку більшість програм безпеки ігнорує.

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

Більшість організацій серйозно інвестували в безпеку електронної пошти: антифішингові фільтри, DLP-сканування, шифрувальні шлюзи. Чат-платформи отримують частку цієї уваги, попри те, що вони несуть зростаючу частку конфіденційної комунікації. Gartner оцінив, що до 2025 року 70% командної комунікації у великих підприємствах відбуватиметься поза електронною поштою. Інструменти безпеки не встигають за цим зсувом.

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

Чому облікові дані постійно потрапляють у чат-повідомлення?

Section titled “Чому облікові дані постійно потрапляють у чат-повідомлення?”

Це найбільший ризик в інструментах співпраці, і він відбувається з гнітючою регулярністю. Опитування 1Password у 2023 році показало, що 34% IT- та безпекових працівників вставляли облікові дані в чат-повідомлення або спільні документи. Серед усіх співробітників цифра, ймовірно, вища, бо нетехнічний персонал менше усвідомлює ризик.

Сценарій майже завжди однаковий. Комусь потрібен доступ до системи. “Правильний” спосіб надати його (оновлення дозволів, використання менеджера секретів, подання запиту на доступ) потребує часу. Вставити пароль у Slack займає три секунди. Під тиском дедлайну три секунди завжди перемагають.

Це не лише продакшн-облікові дані. AWS access keys, Stripe API токени, рядки підключення до бази даних, SSH-ключі, VPN-облікові дані, паролі адмін-панелей. Звіт GitGuardian State of Secrets Sprawl 2024 виявив, що 12,8 мільйона нових захардкоджених секретів з’явилися у публічних GitHub-комітах лише у 2023 році. Та сама поведінка, що потрапляє у код, потрапляє і в чат. Різниця в тому, що GitHub має автоматичне сканування витоку секретів. Slack та Teams не мають, якщо організація спеціально не налаштує DLP-правила для їх виявлення.

Коли облікові дані потрапляють у чат-канал, вони стають доступними для пошуку. Будь-хто з доступом до каналу може знайти їх, шукаючи ключові слова “password”, “credentials” або “login”. Зловмисники, що компрометують один акаунт Slack, часто запускають саме цей пошук першим кроком. Вправа Collaboration Tool Hygiene детально розглядає цей сценарій, показуючи співробітникам, як облікові дані, опубліковані в чаті, створюють стійкі, доступні для пошуку вразливості, що переживають початкову потребу.

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

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

Що відбувається з інтеграціями, які ніхто не перевіряє?

Section titled “Що відбувається з інтеграціями, які ніхто не перевіряє?”

Середній робочий простір Slack має десятки інтеграцій: боти, вебхуки, кастомні додатки, сторонні коннектори. Кожен з них має API-токен зі специфічними дозволами. Деякі можуть читати повідомлення. Деякі можуть публікувати від імені користувачів. Деякі мають доступ до завантажених файлів у всьому робочому просторі.

Аналіз Productiv 2024 року показав, що підприємства в середньому мають 87 SaaS-інтеграцій, підключених до основних платформ співпраці. Багато з них були встановлені для конкретного проєкту, конкретною людиною, яка вже може не працювати в компанії. Інтеграція залишається активною. Її токен залишається дійсним. Ніхто не перевіряє, чи потрібні їй ще надані дозволи.

Вебхуки особливо ризиковані. Вихідний вебхук, що публікує повідомлення про збірки в канал, звучить нешкідливо. Але якщо URL вебхука витікає або приймаючий ендпоінт скомпрометовано, зловмисник може ін’єктувати повідомлення у внутрішні канали. Вхідні вебхуки ще гірші. Вони надають URL, який будь-хто з посиланням може використовувати для публікації повідомлень у конкретний канал. Ці URL часто зберігаються в конфігураціях CI/CD, скриптах та документаційних вікі з мінімальним контролем доступу.

У 2023 році дослідники безпеки продемонстрували, як скомпрометований URL вхідного вебхука може використовуватись для публікації переконливих фішингових повідомлень у внутрішніх Slack-каналах, імітуючи автоматизовані системи, яким довіряють працівники. Повідомлення від “Jira Bot” з проханням повторно автентифікуватись виглядає правдоподібно, коли з’являється в інженерному каналі поряд із справжніми повідомленнями Jira.

Це форма тіньового IT, що ховається на видному місці. Інтеграції технічно “схвалені”, бо хтось із правами адміністратора робочого простору їх встановив. Але ніхто не веде інвентаризацію, не перевіряє дозволи щокварталу та не деактивує інтеграції, коли проєкт, для якого вони були потрібні, завершується.

Злам Slack компанії EA Games у 2024 році ілюструє ризик. Зловмисники придбали вкрадений cookie сесії Slack за $10 на чорному ринку, увійшли у внутрішній Slack EA, і використали його для соціальної інженерії агента IT-підтримки, щоб отримати доступ до внутрішньої мережі. Звідти вони вкрали 780 ГБ вихідного коду. Початковий вхід був через інструмент співпраці. Шлях від cookie до вихідного коду зайняв менше доби.

Наша вправа Collaboration Tool Hygiene включає модуль з ідентифікації та аудиту застарілих інтеграцій до того, як вони стануть точками входу. Вона також охоплює гігієну токенів сесій, про яку більшість працівників не думають, коли відмічають “запам’ятати мене” на робочому ноутбуці вдома.

Хто досі має доступ після звільнення?

Section titled “Хто досі має доступ після звільнення?”

Коли працівник звільняється, IT зазвичай деактивує його обліковий запис Active Directory, відкликає доступ до VPN та збирає ноутбук. Доступ до інструментів співпраці часто є другорядним. Проблема особливо гостра, тому що акаунти Slack та Teams можуть бути не прив’язані до того самого провайдера ідентифікації, що й інші корпоративні системи, особливо для зовнішніх гостей та підрядників, яких ніколи не було в Active Directory.

Гостьові акаунти Slack для підрядників та агентських партнерів особливо проблематичні. Вони створюються для конкретного проєкту, рідко документуються в тій самій системі, що й облікові записи працівників, і майже ніколи не включаються в чек-листи при звільненні. Звіт Cerby 2023 року показав, що 60% організацій мали активні акаунти колишніх працівників або підрядників принаймні в одному SaaS-додатку. Середнє велике підприємство працює з 200+ зовнішніми постачальниками та агенціями одночасно. Кожні партнерські відносини генерують гостьові акаунти, які хтось повинен відстежувати та з часом відкликати.

Спільні канали Microsoft Teams ускладнюють ситуацію. Коли дві організації з’єднуються через спільні канали, користувачі зовнішньої організації отримують доступ до повідомлень, файлів, а іноді й сайтів SharePoint. Коли партнерство закінчується, від’єднання спільного каналу це ручний крок, який хтось повинен пам’ятати зробити.

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

Наша вправа Guest Access Management навчає працівників перевіряти надання зовнішнього доступу та позначати акаунти, що пережили своє призначення.

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

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

Чи можна прослуховувати дзвінки в інструментах співпраці?

Section titled “Чи можна прослуховувати дзвінки в інструментах співпраці?”

Віддалена та гібридна робота перенесли конфіденційні розмови з конференц-залів у відеодзвінки через WiFi та Bluetooth-гарнітури. Це створило категорію ризику, яку більшість програм безпеки інструментів співпраці повністю ігнорує. Звіт Buffer State of Remote Work 2024 показав, що 98% віддалених працівників хочуть продовжувати працювати дистанційно принаймні частину часу. Розподілена робоча сила стала постійною, як і ризики аудіобезпеки, які вона несе.

Bluetooth, протокол, що з’єднує вашу гарнітуру з ноутбуком, має відомі вразливості. Атака KNOB (Key Negotiation of Bluetooth), розкрита у 2019 році, дозволяє зловмиснику в радіусі дії примусити Bluetooth-з’єднання використовувати слабший ключ шифрування, потенційно дозволяючи перехоплення аудіо в реальному часі. Атака BLUFFS, опублікована дослідниками EURECOM наприкінці 2023 року, продемонструвала, що зловмисник може примусити Bluetooth-пристрої перейти у режим застарілого з’єднання, який дозволяє брутфорс ключів сесії між кількома сесіями.

Практичний ризик найвищий у спільних просторах. Кав’ярні, коворкінги, аеропортні лаунжі, готельні лобі. Працівник, що приймає дзвінок ради директорів із готельного лобі через Bluetooth-гарнітуру, транслює аудіодані в радіусі 10 метрів. Вправа Safe Bluetooth Practices охоплює конкретні сценарії, де безпровідне прослуховування стає реалістичною загрозою, та навчає працівників, коли переключатись на дротове аудіо або відкладати конфіденційні дзвінки.

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

Демонстрація екрана створює паралельний ризик. Під час дзвінка Zoom або Teams працівник ділиться екраном, щоб показати документ. Спливає повідомлення з особистої пошти, або на мить стає видимою вкладка браузера з конфіденційними даними, або промайне повідомлення Slack з іменем клієнта. Демонстрація екрана транслює все на дисплеї, не лише призначене вікно. Опитування Tessian 2023 року показало, що 28% працівників випадково ділилися конфіденційними даними під час демонстрації екрана. Вправа Shadow IT Awareness охоплює те, як особисті додатки, що працюють поряд з робочими інструментами, створюють моменти випадкової експозиції.

Як часто файли потрапляють не в той канал?

Section titled “Як часто файли потрапляють не в той канал?”

Випадковий обмін тихіший за витік облікових даних, але потенційно такий же руйнівний. HR-менеджер завантажує таблицю зарплат у публічний канал замість приватного. Менеджер з продажів ділиться контрактом з конкурентом клієнта, бо вибрала не той канал зі списку. Розробник публікує продакшн-конфігурацію з API-ключами в загальний інженерний канал замість обмеженого інфраструктурного. Це не крайні випадки. Вони трапляються в кожній організації з більш ніж кількома каналами.

Звіт Verizon DBIR 2024 показав, що помилкова доставка (відправка інформації не тому отримувачу) становила 43% помилок, що призвели до витоків даних. Інструменти співпраці роблять помилкову доставку без тертя. Коли кожен канал в одному кліку, неправильний клік має таку ж вагу, як і правильний.

На відміну від електронної пошти, де ви принаймні бачите ім’я отримувача перед відправкою, чат-платформи дозволяють публікувати в каналах з подібними назвами в швидкій послідовності. М’язова пам’ять набору тексту та натискання Enter не залишає місця для перевірки “чи вибрав я правильний канал?”. Наша вправа Insider Threat (Accidental) симулює саме цей тип сценарію, де добронамірений працівник надсилає не той файл не в те місце і повинен розбиратися з наслідками.

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

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

Чи справді “приватні” канали приватні?

Section titled “Чи справді “приватні” канали приватні?”

Працівники говорять у приватних каналах речі, які ніколи не написали б в електронному листі. Стратегічні плани, думки про клієнтів, скарги на керівництво, обговорення зарплат. Вони припускають, що “приватний” означає те, як це звучить. Це не так.

Адміністратори робочих просторів Slack на планах Enterprise Grid можуть отримувати доступ до повідомлень приватних каналів через Compliance-експорти. Адміністратори Microsoft Teams з дозволами eDiscovery можуть шукати та експортувати вміст приватних каналів. Корпоративні юридичні команди можуть отримати записи приватних каналів через юридичні утримання. І будь-яка інтеграція з правильним OAuth scope може мовчки читати повідомлення приватних каналів. Опитування Aware (раніше Aware360) 2022 року показало, що 68% працівників вважали, що їхні прямі повідомлення в робочому чаті видимі лише учасникам. Це не так.

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

Це важливо для запобігання витоку даних, тому що працівники ставляться до приватних каналів як до безпечних місць для обміну конфіденційною інформацією. Вони публікують API-ключі “тільки між нами”, діляться скаргами клієнтів з ідентифікаційними деталями та обговорюють цілі для поглинання. Весь цей контент можна виявити, експортувати та отримати доступ до нього, скомпрометувавши адміністраторський акаунт або достатньо привілейовану інтеграцію.

Для організацій у регульованих галузях це створює ризик відповідності, коли захищені дані з’являються в каналах, що не підлягають належному контролю збереження та доступу. Приватний канал Slack з інформацією про пацієнтів, захищеною HIPAA, або персональними даними, захищеними GDPR, підлягає тим самим регуляторним вимогам, що й база даних або ланцюжок електронних листів. Позначка “приватний” каналу не надає юридичного захисту. Дивіться посібник з відповідності для того, як вимоги навчання відповідають конкретним регуляторним рамкам.

Як виглядає практична програма безпеки інструментів співпраці?

Section titled “Як виглядає практична програма безпеки інструментів співпраці?”

Говорити працівникам “будьте обережні в чаті” не дає жодних вимірюваних результатів. Розпливчасті вказівки дають розпливчасту відповідність. Робоча програма адресує конкретні поведінки, що створюють ризик, з контролями та навчанням, прив’язаними до кожної.

Обмін обліковими даними. Розгорніть менеджер паролів із функціями безпечного обміну та зробіть його шляхом найменшого опору. Блокуйте повідомлення, що містять патерни, схожі на паролі або API-ключі, використовуючи Slack Enterprise DLP або Microsoft Purview. Навчайте працівників, чому обмін обліковими даними через чат небезпечний, через вправи на кшталт нашої симуляції Collaboration Tool Hygiene.

Гігієна інтеграцій. Перевіряйте підключені додатки щокварталу. Вимагайте адміністраторського затвердження для нових інтеграцій. Встановлюйте терміни дії URL вебхуків. Видаляйте інтеграції, встановлені працівниками, що покинули організацію. Ротуйте URL вебхуків за регулярним розкладом, так само, як ви ротуєте API-ключі. Навчання практикам безпечного обміну повідомленнями повинне включати обізнаність щодо інтеграцій, а не лише вмісту повідомлень.

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

Дисципліна каналів. Встановіть конвенції назв, що сигналізують рівні конфіденційності. Префікс #proj- для проєктних каналів, #ext- для каналів із зовнішніми гостями, #restricted- для конфіденційних тем дає працівникам візуальну підказку перед публікацією. Навчіть працівників перевіряти канал перед публікацією. Впровадьте мітки класифікації даних у каналах із конфіденційним вмістом. Використовуйте DLP-політики для позначення та карантину повідомлень, що містять PII, облікові дані або контент з маркуванням класифікації.

Обізнаність про безпровідну безпеку. Включіть гігієну Bluetooth та WiFi у вашу політику безпеки віддаленої роботи. Навчіть працівників, коли дротові з’єднання необхідні для конфіденційних дзвінків. Заповніть цю прогалину вправами на кшталт Safe Bluetooth Practices та зміцніть обізнаність щодо того, як надмірний обмін у соціальних мережах може розкрити деталі, що полегшують цілеспрямоване прослуховування.

Гігієна демонстрації екрана. Навчіть працівників використовувати демонстрацію на рівні вікна замість повноекранної під час відеодзвінків. Закривайте непотрібні додатки та вимикайте спливаючі повідомлення перед презентацією. Ці маленькі звички запобігають випадковим експозиціям, що трапляються, коли Slack DM або повідомлення з особистої пошти спалахує на спільному екрані під час презентації клієнту.


Найшвидший спосіб побудувати ці звички через практику, а не політичні документи. Перегляньте наш повний каталог навчання з кібербезпеки для вправ з інструментів співпраці, управління обліковими даними, витоку даних та контролю доступу. Кожна вправа занурює працівників у реалістичний сценарій, де ці ризики проявляються, тому що читання про витік облікових даних у слайд-деку не те саме, що спостерігати, як симульований зловмисник шукає у вашій історії Slack слово “password”.