В первую очередь, давайте определим отличие Teams от большинства других продуктов Microsoft в их предложении Office 365 (в дальнейшем, для краткости – O365).
Teams — это только клиент, не имеющий собственного облачного приложения. И он размещает данные, которыми управляет, в различных приложениях O365.
Мы покажем, что происходит «под капотом» при работе пользователей в Teams, SharePoint Online (далее SPO) и OneDrive.

Знакомьтесь с Командой внутреннего проекта компании 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"), и к ним предоставляется доступ участникам чата
● Чат и содержимое переписки хранятся в почтовых ящиках пользователей и Команды, соответственно, в скрытых папках. Сейчас нет возможности получить к ним дополнительный доступ.
В карбюраторе вода, в трюме — течь
Основные тезисы, которые важно помнить в разрезе информационной безопасности:● Контроль за доступом, и понимание того, кому можно предоставлять права к важным данным, передан на уровень конечного пользователя. Не предусмотрено полноценного централизованного контроля или мониторинга.● Когда кто-то делится данными компании – ваши «слепые зоны» видны другим, но не вам.a

В списке лиц, которые входят в Команду (через группу безопасности в 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 – вызовы ИТ
Простейший процесс предоставления доступа к данным на файловых хранилищах внутри периметра организаций не особо сложен и практически не предоставляет возможностей для обхода предоставленных прав доступа.

В O365 же много возможностей для совместной работы и предоставления доступа к данным.
● Пользователи не понимают, зачем ограничивать доступ к данным, если можно просто предоставить ссылку на файл, доступную для всех, поскольку не имеют базовой экспертизы в сфере информационной безопасности, или пренебрегают рисками, делая допущения о малой вероятности их наступления● Вследствие этого критичная информация может покинуть пределы организации и стать доступной широкому кругу лиц● Помимо этого, возможностей предоставить избыточный доступ очень много
Microsoft в O365 предоставили, вероятно, слишком много способов изменить списки контроля доступа. Такие настройки есть на уровне тенанта, сайтов, папок, файлов, самих объектов и ссылок на них. Конфигурация настроек возможностей предоставления доступа важна и не следует ею пренебрегать.
Мы предоставляем возможность пройти бесплатный, примерно полуторачасовой видеокурс о конфигурации этих параметров, ссылка на который приведена в начале данной статьи.
Недолго думая, можно заблокировать и весь внешний файлообмен, но тогда:
● Часть возможностей платформы O365 останется неиспользованной, особенно, если часть пользователей привыкла их использовать дома или на предыдущей работе
● Продвинутые пользователи будут «помогать» другим сотрудникам нарушать установленные вами правила с помощью иных средств
Настройка возможностей предоставления совместного доступа включает в себя:
● Различные конфигурации для каждого приложения: OD, SPO, AAD and MS Teams (часть конфигураций может сделать только администратор, часть – только сами пользователи)● Конфигурации настроек на уровне тенанта и на уровне каждого конкретного сайта

 Что это значит для ИБ
Как мы видели выше, полные достоверные права доступа к данным нельзя увидеть в едином интерфейсе:

Таким образом, чтобы понять, кто имеет доступ к КАЖДОМУ конкретному файлу или папке – потребуется самостоятельно сформировать матрицу доступа, собрав для неё данные, учитывая следующее:
● Члены Команд видны в Azure AD и в Teams, но не в SPO● Владельцы Команд могут назначать Совладельцев, которые могут расширять список Команды самостоятельно● Также в Команды могут входить ВНЕШНИЕ пользователи – «Гости»● Ссылки, предоставленные для совместного доступа или скачивания, не видны в Teams или в Azure AD – только в SPO, и только лишь после утомительных переходов по массе ссылок● Доступ только к сайту SPO не виден в Teams
Отсутствие централизованного контроля означает, что вы не можете:
● Увидеть, у кого есть доступ к каким ресурсам● Увидеть, где находятся критичные данные● Отвечать требованиям регуляций, требующих подхода к планированию сервисов с ориентиром на конфиденциальность доступа в их основе● Обнаружить нестандартное поведение в отношении критичных данных● Ограничить площадь атаки● Выбрать эффективный способ сокращения уровня рисков, исходя из их оценки

Резюме
Как вывод, мы можем сказать, что:
● Для отделов ИТ организаций, выбирающих работу с O365, важно иметь квалифицированных сотрудников, способных как реализовать технически изменения настроек совместного доступа, так и обосновать последствия изменения тех или иных параметров, для написания согласованных с ИБ и бизнес-подразделениями политик работы с O365● Для ИБ важно иметь возможность проводить на автоматической ежедневной основе, или даже в реальном времени, аудит доступа к данным, нарушения согласованных с ИТ и бизнес-подразделениями политик работы с O365 и анализ корректности предоставленных доступов, а также видеть атаки на каждый из сервисов в их тенанте O365