У цій статті ми хотіли б показати, як робота з Microsoft Teams виглядає з погляду користувачів, адміністраторів ІТ та співробітників ІБ.
Насамперед, давайте усвідомимо відмінність Teams від більшості інших продуктів Microsoft у їх пропозиції Office 365 (надалі, для стислості – O365).
Teams - це тільки клієнт, який не має власної хмарної програми. І він розміщує дані, якими керує, у різних додатках O365.
Ми покажемо, що відбувається під капотом при роботі користувачів в Teams, SharePoint Online (далі SPO) і OneDrive.
Якщо ви вже зараз хотіли б перейти до практичної частини із забезпечення безпеки засобами Microsoft (1 година із загального часу курсу) – рекомендуємо прослухати наш курс Office 365 Sharing Audit, доступний Цей курс покриває, в тому числі, і налаштування загального доступу до O365, які доступні для зміни тільки через PowerShell.
Знайомтесь з командою внутрішнього проекту Acme Co.
Ось як ця Команда виглядає у Teams, після її створення та надання відповідних доступів її членам Власником цієї Команди – Amelia:
Команда розпочинає роботу
Linda має на увазі, що до розміщеного в створеному нею Каналі файлу з планом бонусних виплат звертатимуться тільки James і William, з якими вони це обговорювали.
James, у свою чергу, направляє посилання на доступ до цього файлу співробітниці відділу роботи з персоналом Emma, яка не входить до Команди.
William же відправляє в чаті MS Teams іншому члену Команди договір із персональними даними третьої особи:
Лезем під капот
Zoey, з легкої руки Amelia, тепер може будь-якої миті додати будь-кого до Команди, або видалити з неї:
Linda, викладаючи документ з критичними даними, призначений для використання лише двома її колегами, помилилася з типом Каналу під час його створення, і файл став доступним всім членам Команди:
На щастя, є програма Microsoft для O365, в якій можна (використовуючи її зовсім не за призначенням) оперативно побачити, до яких критичних даних мають доступ абсолютно всі користувачі, використовуючи для тесту користувача, що входить лише у загальну групу безпеки.
Навіть якщо файли знаходяться всередині Приватних Каналів (Private Channels) – це може бути гарантією того, що до них буде доступ тільки у певного кола осіб.
У прикладі з James він надав посилання на файл Emma, яка навіть не входить до Команди, не кажучи вже про доступ до Приватного Каналу (якби він був таким).
У цій ситуації найгірше – те, що ми не побачимо інформації про це ніде у групах безпеки в Azure AD, оскільки права доступу надані їй безпосередньо.
Відправлений William файл з ПДн буде доступний Margaret будь-коли, а не тільки під час роботи в чаті онлайн.
Залазимо до пояса
Розбираємось далі. Спочатку подивимося, що відбувається, коли який-небудь користувач створює нову Команду в MS Teams:
- Створюється нова група безпеки Office 365 в Azure AD, що включає власників Команди та її членів.
- Створюється сайт нової Команди у SharePoint Online (далі – SPO)
- Створюються три нові локальні (діючі тільки в цьому сервісі) групи в SPO: Власники, Члени, Відвідувачі
- Здійснюються зміни і в Exchange Online
Дані MS Teams, і де вони мешкають
Teams – це не сховище даних чи платформа. Він інтегрований із усіма рішеннями Office 365.
- O365 пропонує безліч додатків та продуктів, але дані завжди зберігаються в таких місцях: SharePoint Online (SPO), OneDrive (далі – OD), Exchange Online, Azure AD
- Дані, якими ви ділитеся або які отримуєте через MS Teams, зберігаються саме на цих платформах, а не всередині самого Teams
- В даному випадку, ризиком є тренд, що набирає обертів, на спільну роботу. Будь-хто, хто має доступ до даних на платформах SPO і OD, може зробити їх доступними будь-кому як всередині, так і поза організацією.
- Всі дані Команди (за винятком вмісту приватних каналів) зібрані на сайті SPO, створюваному автоматично при створенні Команди
- Для кожного створюваного Каналу автоматично створюється підпапка у папці Documents у цьому сайті SPO:
- файли у Каналах завантажуються у відповідні підпапки папки Documents сайту SPO Команди (названі так само, як Канал)
- Email-и, що надсилаються до Каналу, зберігаються в підпапці “Email Messages” папки Каналу
- Коли створюється новий Приватний Канал, для зберігання його вмісту створюється окремий сайт SPO, з тією ж структурою, як описано вище для звичайних Каналів (важливо для кожного Приватного Каналу створюється свій спеціальний сайт SPO)
- Файли, що надсилаються через чати, зберігаються в обліковому записі користувача OneDrive (до папки “Microsoft Teams Chat Files”), і до них надається доступ учасникам чату
- Чат і вміст листування зберігаються у поштових скриньках користувачів та Команди, відповідно, у прихованих папках. Наразі немає можливості отримати до них додатковий доступ.
У карбюраторі вода, у трюмі - текти
Основні тези, які важливо пам'ятати у розрізі інформаційної безпеки:
- Контроль за доступом та розуміння того, кому можна надавати права до важливих даних, передано на рівень кінцевого користувача. Не передбачено повноцінного централізованого контролю чи моніторингу.
- Коли хтось ділиться даними компанії – ваші сліпі зони видно іншим, але не вам.
У списку осіб, які входять до Команди (через групу безпеки в Azure AD), ми не бачимо Emma, але має доступ до конкретного файлу, посилання на який направив їй James.
Так само ми не дізнаємося про її можливість доступу до файлів та з інтерфейсу Teams:
Чи можемо ми отримати інформацію про те, до якого об'єкта є доступ у Emma? Так, можемо, але лише за допомогою вивчення прав доступу на всі або на конкретний об'єкт у SPO, щодо якого ми маємо підозри.
Вивчивши такі права, ми побачимо, що до об'єкта є права на рівні SPO Emma і Chris.
Chris? Не знаємо ми ніякого Chris. Звідки він узявся?
А «прийшов» він до нас із «локальної» групи безпеки SPO, до якої вже, у свою чергу, входить група безпеки Azure AD з членами Команди “Compensations”.
може, Microsoft Cloud App Security (MCAS) зможе пролити світло на питання, що цікавлять нас, надавши потрібний рівень розуміння?
На жаль, ні… Незважаючи на те, що ми зможемо побачити Chris та Emma, ми не зможемо побачити конкретних користувачів, яким надано доступ.
Рівні та способи надання доступу до O365 – виклики ІТ
Найпростіший процес надання доступу до даних на файлових сховищах усередині периметра організацій не надто складний і практично не надає можливостей для обходу наданих прав доступу.
У O365 багато можливостей для спільної роботи і надання доступу до даних.
- Користувачі не розуміють, навіщо обмежувати доступ до даних, якщо можна просто надати посилання на файл, доступне для всіх, оскільки не мають базової експертизи в сфері інформаційної безпеки, або нехтують ризиками, роблячи припущення про малу ймовірність їх настання.
- Внаслідок цього критична інформація може залишити межі організації та стати доступною широкому колу осіб
- Крім цього, можливостей надати надлишковий доступ дуже багато
Microsoft у O365 надали, ймовірно, занадто багато способів змінити списки контролю доступу. Такі налаштування є на рівні тенанта, сайтів, папок, файлів, самих об'єктів та посилань на них. Конфігурація параметрів можливостей надання доступу важлива і не слід нею нехтувати.
Ми надаємо можливість пройти безкоштовний, приблизно півторагодинний відеокурс про конфігурацію цих параметрів, посилання на який наведено на початку цієї статті.
Недовго думаючи, можна заблокувати весь зовнішній файлообмін, але тоді:
- Частина можливостей платформи O365 залишиться невикористаною, особливо якщо частина користувачів звикла їх використовувати вдома або на попередній роботі
- "Просунуті користувачі" будуть "допомагати" іншим співробітникам порушувати встановлені вами правила за допомогою інших засобів
Налаштування можливостей надання спільного доступу включає:
- Різні конфігурації для кожної програми: OD, SPO, AAD and MS Teams (частина конфігурацій може зробити тільки адміністратор, частина – лише користувачі)
- Конфігурації налаштувань на рівні тенанта та на рівні кожного конкретного сайту
Що це означає для ІБ
Як ми бачили, повні достовірні права доступу до даних не можна побачити в єдиному інтерфейсі:
Таким чином, щоб зрозуміти, хто має доступ до КОЖНОГО конкретного файлу або папки - потрібно самостійно сформувати матрицю доступу, зібравши для неї дані, враховуючи наступне:
- Члени Команд видно в Azure AD і Teams, але не в SPO
- Власники команд можуть призначати співвласників, які можуть розширювати список команди самостійно
- Також до Команди можуть входити ЗОВНІШНІ користувачі – «Гості»
- Посилання, надані для спільного доступу або скачування, не видно в Teams або Azure AD - тільки в SPO, і тільки після стомлюючих переходів по масі посилань
- Доступ лише до сайту SPO не видно у Teams
Відсутність централізованого контролю означає, що ви не можете:
- Побачити, хто має доступ до яких ресурсів
- Побачити, де знаходяться критичні дані
- Відповідати вимогам регуляцій, які потребують підходу до планування сервісів з орієнтиром на конфіденційність доступу на їх основі
- Виявити нестандартну поведінку щодо критичних даних
- Обмежити площу атаки
- Вибрати ефективний спосіб скорочення рівня ризиків, виходячи з їх оцінки
Резюме
Як висновок, ми можемо сказати, що
- Для відділів ІТ організацій, що обирають роботу з O365, важливо мати кваліфікованих співробітників, здатних як технічно реалізувати зміни налаштувань спільного доступу, так і обґрунтувати наслідки зміни тих чи інших параметрів, для написання узгоджених з ІБ та бізнес-підрозділами політик роботи з O365
- Для ІБ важливо мати можливість проводити на автоматичній щоденній основі, або навіть у реальному часі, аудит доступу до даних, порушення узгоджених з ІТ та бізнес-підрозділами політик роботи з O365 та аналіз коректності наданих доступів, а також бачити атаки на кожен із сервісів у них тенанте O365
Джерело: habr.com