В этой статье мы хотели бы показать, как работа с 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