У гэтым артыкуле мы хацелі б паказаць, як праца з 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