Office 365&Microsoft Teams – удобство совместной работы и влияние на безопасность



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

    Комментарии 6

      0
      И самое главное — запретить разбрасываться файлами в Microsoft Teams, то есть просто отключить sharing файлов для всех раз и навсегда — нельзя! Какую бы лицензию вы не купили. Просто нельзя и всё. Видимо, Teams это не продукт, который в Microsoft продают клиентам, а исключительно способ переманить всех в своё облако.
        0
        Да, отключить возможность предоставления доступа к файлам пользователями полностью нельзя. Но можно выставить, без применения сторонних средств, ограничения на предоставление доступа внешним пользователям, а также указать диапазон IP-адресов, с которого возможно подключение к O365 для вашего теннанта.
        0
        Вот в тексте у вас проскочило «Недолго думая, можно заблокировать и весь внешний файлообмен». Так все-таки можно? У меня руководство похоронило проект по Teams именно потому что все партнеры MS сказали что так нельзя.
        ну и совсем тупой вопрос (на который не ответили Croc, Softline и айтеко) — есть ли все-таки способ разрешить Teams для части пользователей только с определенных «айпишников»? Говоря по простому только когда они работают внутри корпоративного периметра? Лирику про то, что «облака не для этого» и «надо воспитывать ответственного пользователя» мы тут опускаем…
          0
          Вот в тексте у вас проскочило «Недолго думая, можно заблокировать и весь внешний файлообмен». Так все-таки можно? У меня руководство похоронило проект по Teams именно потому что все партнеры MS сказали что так нельзя.

          Имеется в виду, можно запретить обмениваться файлами с гостями и со сторонними облаками, но не с Microsoft.

          ну и совсем тупой вопрос (на который не ответили Croc, Softline и айтеко) — есть ли все-таки способ разрешить Teams для части пользователей только с определенных «айпишников»? Говоря по простому только когда они работают внутри корпоративного периметра? Лирику про то, что «облака не для этого» и «надо воспитывать ответственного пользователя» мы тут опускаем…

          При наличии Microsoft Azure AD Premium P1 лицензии и выше, можно настроить Conditional Acess Policy с разрешением захода группе пользователей только из Named Location. А Named Location настраивается по IP ranges. Опционально, можно потребовать двухфакторную аутентификацию при попытке входа извне, но надо иметь в виду, что если телефон не указан в настройках пользователя, то первый раз пустит из любого места с любым телефоном и запомнит этот телефон, что противоречит идеологии двухфакторной аутентификации на корню, но зато не надо лишний раз напрягаться.
            0
            Как вы верно отметили, мы написали о том, что внешний файлообмен (так, как понимает его Microsoft) заблокировать можно. Более детально об этом вы можете узнать, посмотрев указанный в начале статьи обучающий курс.
            Если же отвечать на ваш вопрос так, как он задан:
            «есть ли все-таки способ разрешить Teams для части пользователей только с определенных «айпишников»? Говоря по простому только когда они работают внутри корпоративного периметра?»
            — то ответ будет скорее нет, чем да, если лица, которым требуется ограничить доступ, будут использовать для работы с O365 из периметра корпоративной сети ноутбуки и/или личные устройства.

            В ином случае, есть вариант настроить MFA таким образом, чтобы, используя сертификаты, или ещё какие-либо критерии, ограничивать доступ в облако, связывая условие с конкретными устройствами. Т.е. пользователи, которым таковой доступ извне периметра будет разрешён, будут, например, иметь на носимых устройствах, или домашних компьютерах, соответствующие сертификаты. Разумеется, в таком примере, сертификаты придётся установить и на все рабочие станции/терминальные серверы внутри периметра тоже.
            Эту меру можно совместить с указанием «белого списка» IP-адресов для доступа, если планируется также запретить и доступ с динамического диапазона (когда человек находится в дороге или просто решил использовать мобильную точку доступа Wi-Fi с не разрешённым к использованию Вами IP-адресом).

            Вероятно, имеются какие-либо продвинутые CASB, которые могут регулировать политику доступа так же, как указано в ответе на комментарий выше (без сертификатов или иных критериев, только по IP-адресам), но разделяя на группы пользователей, для которых применяются строгие и менее строгие ограничения по диапазонам адресов, с которых возможен доступ. Нам о таких решениях неизвестно.
            0
            Есть что почерпнуть в вашей статье, но:
            В M365 есть Центр администрирования «Безопасность и соответствие». В разделе «поиск в журнале аудита», можно просматривать всю цепочку предоставления прав на документы пользователями.
            Так же если не ошибаюсь в политиках потери данных можно настроить политики на чувствительные данные (например оповещение отдела ИБ, если дан доступ на файл с номером счёта).
            Мне кажется если забрать у людей возможность просто и быстро расшарить файл, они могут искать обходные пути, например скачать файл и перекинуть другому, открыть и скопировать информацию для передачи другому, и в таком случае вы уже теряете цепочку передачи информации.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое