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