В этой статье мы хотели бы показать, как работа с 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”), и к ним предоставляется доступ участникам чата
- Чат и содержимое переписки хранятся в почтовых ящиках пользователей и Команды, соответственно, в скрытых папках. Сейчас нет возможности получить к ним дополнительный доступ.
В карбюраторе вода, в трюме — течь
Основные тезисы, которые важно помнить в разрезе securitatea informatiei:
- Контроль за доступом, и понимание того, кому можно предоставлять права к важным данным, передан на уровень конечного пользователя. Не предусмотрено полноценного централизованного контроля или мониторинга.
- Когда кто-то делится данными компании – ваши «слепые зоны» видны другим, но не вам.
В списке лиц, которые входят в Команду (через группу безопасности в Azure AD), мы не видим Emma, но у неё есть доступ к конкретному файлу, ссылку на который направил ей James.
Точно так же мы не узнаем о её возможности доступа к файлам и из интерфейса Teams:
Можем ли мы как-то получить информацию о том, к какому объекту есть доступ у Emma? Да, можем, но только с помощью изучения прав доступа на все или на конкретный объект в SPO, в отношении которого у нас есть подозрения.
Изучив такие права, мы увидим, что к объекту есть права на уровне SPO у Emma и Chris.
Chris? Не знаем мы никакого Chris. Откуда он взялся?
А «пришёл» он к нам из «локальной» группы безопасности SPO, в которую уже, в свою очередь, входит группа безопасности Azure AD, с членами Команды “Compensations”.
Poate sa, 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
Отсутствие централизованного контроля означает, что вы не можете:
- Увидеть, у кого есть доступ к каким ресурсам
- Увидеть, где находятся критичные данные
- Отвечать требованиям регуляций, требующих подхода к планированию сервисов с ориентиром на конфиденциальность доступа в их основе
- Обнаружить нестандартное поведение в отношении критичных данных
- Ограничить площадь атаки
- Выбрать эффективный способ сокращения уровня рисков, исходя из их оценки
Rezumat
Как вывод, мы можем сказать, что
- Для отделов ИТ организаций, выбирающих работу с O365, важно иметь квалифицированных сотрудников, способных как реализовать технически изменения настроек совместного доступа, так и обосновать последствия изменения тех или иных параметров, для написания согласованных с ИБ и бизнес-подразделениями политик работы с O365
- Для ИБ важно иметь возможность проводить на автоматической ежедневной основе, или даже в реальном времени, аудит доступа к данным, нарушения согласованных с ИТ и бизнес-подразделениями политик работы с O365 и анализ корректности предоставленных доступов, а также видеть атаки на каждый из сервисов в их тенанте O365
Sursa: www.habr.com