MS Teams to skomplikowany zwierz
czemu tak trudno jest zrobić kopię zapasową Teams? czemu w zasadzie nie ma aplikacji do migracji Teams (Teams merge, Teams copy etc)? czemu tak długo zajmuje przygotowanie możliwości łatwego przełączania między tenantami?
to tylko niektóre pytania… a dziś chciałem się sqpić na spotkaniach i bezpieczeństwie dostępu oraz pokazać jeden z powodów, będący (częściową) odpowiedzią na powyższe pytania.
Kawałek historii
[można spokojnie pominąć tą część, nudy. część właściwa jest dużo niżej. ]
Teams, jak zresztą cały O365 (a obecnie M365), był tworzony przez developerów dla developerów – aby zaspokoić dziki pęd w kierunq 'edżajla’. Teamsy w pierwszych dniach swojego istnienia przypominały Internet lat 9o, albo wręcz ten 8otych, kiedy dopiero wpadł w ręce uniwersytetów – cudowna idea nieograniczonego współdzielenia, wszyscy mamy prawo do informacji, dzielmy się wiedzą. jak każda idea – szybko jest weryfikowana przez życie i zaraz zaczęły powstawać firewalle i inne kontrole dostępu. także samo wyglądał wczesny Teams, co w wielu miejscach widać do tej pory – wszystko dla wszystkich, brak kontroli uprawnień, każdy może założyć nowy zespół i każdy może udostępnić każdemu cokolwiek…
…i od razu 'likwidujemy skype i drogie firmy, macie chwilkę na przesiadkę’. pominę ten fragment historii, bo choć z produktami Microsoft znam się dłużej niż większością znajomych [a na pewno znam je lepiej (; ], to uważam, że Teamsy dopiero teraz zaczynają się nadawać dla rynq Enterprise… <skip>
Teamsy w ciągu ostatniego roq-dwóch zostały mocno uzbrojone, dodana została kontrola kto może je zakładać i trochę narzędzi do governance’u, ale nadal pozostają dziury – jak np. brak kontroli uprawnień na poziomie katalogów/kanałów. tutaj podam link podesłany przez Ewangelista.it i jeszcze filmik jak te uprawnienia przypisać. no więc jest czy nie ma? moje testy zmiany uprawnień na poziomie katalogów SP skończyły się problemami z dostępem – zwłaszcza Web Office, który nie potrafił tych pliqw otworzyć i potrafił się wysypać – ale to było dawno. więc testujcie i zapraszam do podzielenia się doświadczeniami. ja nadal klientom będę póki co odradzał grzebanie na poziomie SP – przynajmniej póty, póki w końcu nie zostanie on zupełni przykryty Teamsami [tak, żeby w ogóle zniknęły odnośniki do SP, a wszystkie operacje będą wykonywane z Teams]. to będzie dla mnie oznaka, że Teams rozumie już uprawnienia na poziomie katalogu, a na tą chwilę, uważam że to jest playground dla szkół.
przykład z niejasnością działania uprawnień w jakiś sposób nawiązuje do najważniejszego przekazu – Teamsy są makabrycznie złożone. Frankenstein by się zawstydził, z jak wielu kawałqw, jak dziwnie połączonych, można zbudować taki organizm. zapewne wszyscy wiedzą, że Teams to de facto GUI, które pod spodem łączy się z Exchange, SharePoint i [dawnym] Skype for Business – częścią telekonferencyjną. każda jest oddzielną aplikacją, z własnym RBAC [kontrolą dostępu/modelem administracyjnym – o którym kiedyś jak będę miał siłę, też opiszę, bo jest niemniej pojechany niż Teamsy], z wieloma portalami administracyjnymi. wszystkie wymienione mają własny sposób zarządzania, nadal nieuporządkowany i w wielu miejscach niespójny – AAD, Exchange, SP, do tego Teams, i całe Security, Compliance i jeszcze kilka innych… tak tak, M365 jest dużo bardziej złożone niż większości osób się to wydaje… a więc Teamsy muszą założyć sesje do [niemal] każdego serwisu, każdy serwis może być inaczej zabezpieczony i w dawnych modelach administracyjnych – zarządzany przez oddzielne działy. rysuje się wam jakiś obrazek?
mówiąc w skrócie – nieźle zamieszane. ale to nie koniec. czas przejść do meritum i zobaczyć że to jest jak cebula – kiedy odkryjemy jedną warstwę złożoności, naszym oczom ukazują się dwie kolejne…
Gdzie są moje dane?
i nie chodzi o pytanie geograficzne, związane ze zgodnością z normami (Compliance) – to można zleźć tutaj. chodzi natomiast o taki scenariusz:
- CTO zakłada spotkanie Teams Meeting. zaprasza CIO i Head of all Heads.
- podczas tworzenia spotkania dołączony został plik z prezentacją dot. strategii firmy na najbliższy rok.
- podczas spotkania panie i panowie wrzucili dodatkowe pliki w okienq rozmowy (chat), zawierające krytyczne dla firmy dane finansowe i plany zaqpowe na nowy rok.
- przy okazji chwilę porozmawiali na chat i zrobili notatkę ze spotkania, gdzie zapisane zostały propozycje firm, które wezmą udział w przetargu wartym $1.ooo.ooo
- mógłbym jeszcze dodać whiteboard, który jest ciekawym przypadkiem sam-w-sobie, choćby z tego względu, że nadal znajduje się tylko na serwerach w USA i do tego ostatnio nie działa. ale uznajmy, że właśnie nie działał…
no więc mamy paczkę bardzo wrażliwych danych. gdzie leży problem? zadam zatem kilka pytań – jeśli znasz odpowiedzi – możesz się uważać za osobę znającą Teams *rewelacyjnie* i masz dużą świadomość bezpieczeństwa danych:
- kto może do takiego spotkania dołączyć? tylko osoby, który były zaproszone, czy każdy kto ma link, czy każdy kto ma link nawet z poza organizacji?
- jak ktoś dołączy do spotkania – czy będzie widział zapis rozmowy i wszystkie pliki?
- po zakończeniu spotkania – jak osoby dołączą ponownie, czy będą tam te wszystkie pliki i zapiski i notatki?
- biorąc pod uwagę pyt. 1 – czy osoby które nie były zaproszone będą miały dostęp do informacji wrażliwych?
dodałbym jeszcze pytanie o ogólne eDiscovery i DLP dla Teams – ale o tym nie będę dalej pisał, bo chciałem się sqpić na rzeczach dużo bardziej podstawowych – gdzie są te wszystkie pliki i informacje ze spotkań przechowywane? jak są zabezpieczone?? czy tymi zabezpieczeniami da się sterować po spotkaniu?
cebula – cz. I
o tym jak się zachowują regularne Zespoły jest niezła intuicja – w końcu tym zajmują się administratorzy. ale spotkania.. uciekają uwadze. a przecież tam również często są przechowywane wrażliwe dane a znów mamy 'security by obscurity’ – jakiś totalnie zamieszany system.
zacznę od linka, który wskazuje gdzie te lokalizacje są. nie odpowiada jednak na wiele pytań związanych z zachowaniem. zacznę od kopii tabeli z artqłu, jako dowód na to, jak można zamieszać:
[table id=3 /]
w tej tabeli zabrakło jeszcze informacji 'gdzie są pliki, dołączone podczas zakładania spotkania w Outlook, jako załącznik’. te są w skrzynce pocztowej użytkownika. no i oczywiście regionalizacja – nazwa katalogu na OneDrive będzie zależna od ustawień regionalnych, więc może się okazać, że macie kilka katalogów, w różnych językach.
aby coś zabezpieczyć dobrze spełnione powinny być warunki:
- musimy wiedzieć GDZIE są dane. dobrze żeby były w pojedynczym miejscu, łatwiej je kontrolować i nakładać takie same zasady
- powinny być w systemach o ujednoliconych uprawnieniach – bo co oznacza 'read only’ dla pliq w Outlook a co dla pliq w bibliotece SP?
- muszą być zarządzane centralnie, z jednego interfejsu, dając pojedynczy widok na wszystko co zabezpieczamy – tak aby niczego nie przeoczyć
Tu mówimy o self-service – to użytkownik jest administratorem spotkania, i to na użytkownika spada odpowiedzialność zadbania o bezpieczeństwo danych na spotkaniu. oceńcie sami, czy użytkownik ma taką szansę?
a administrator – czy ma jakiekolwiek narzędzia aby tym bałaganem zarządzać? stwierdzić gdzie są jakie pliki i jakie mają uprawnienia? jak na to działają polityki współdzielenia nałożone na OD?
kolejna warstwa cebulki – linia czasu.
czas na odpowiedzi do pytań, z kolejną warstwą zamieszania. a to dla tego, że zachowanie jest inne jeśli spotkanie jeszcze trwa, a inne gdy już się zakończyło:
[table id=1 /]
a pod spodem – kolejne warstwy
jeśli nadal nadążasz, gratulacje. w takim razie dodam jeszcze kilka elementów, które powodują, że powyższa tabela jest kłamstwem, bo wykonywane zadania były w konkretnej sekwencji i przy uproszczonych założeniach. kolejna porcja wariacji, wpływającej na zachowanie:
- jest różnica pomiędzy Guest a External. przykładowy link – jednak polecam poszukać innych. już samej nomenklaturze jest problem, która uległa zmianie i nie do końca przemawia, różnice będą inne zależnie od systemu – ale co najważniejsze – użytkownicy zapraszający kogoś np. Pan.Zewnetrzny@innafirma.com – nie ma jasności jaki to rodzaj użytkownika. Guest czy External? a jeśli nawet jakimś cudem wie – pójdźcie i wyjaśnijcie użytkownikowi różnice….
- jest różnica między osobą dołączającą 'anonimowo’ [czyli nie posiadającą licencji na Teams], a dołączającą z innej organizacji [posiada normalnie Teams/EXO/OD]. wystarczy spojrzeć gdzie przechowywane są informacje [na OD i EXO] żeby zorientować się, że jeśli osoba, która dołącza nie ma konta licencjonowanego nie ma ani skrzynki ani OD. gdzie zatem będą przechowywane pliki jaki wrzuci lub historia chatu?
- kto wrzucał pliki – jeśli osoba z poza organizacji czy ktoś z niej? w pewien sposób rozwinięcie poprzedniego punktu – to samo pytanie z innej perspektywy. choć nie sprawdzałem czy jak osoba z poza organizacji załączy plik – czy będzie przechowywany jako cross-reference między OD w innych tenantach, czy zostanie skopiowany?
- różnica między osobą dołączającą z aplikacji a wersji web i mobilnej – tak, tak, i tu są pewne różnice. na tyle niewielkie [z moich obserwacji], że z punktu widzenia bezpieczeństwa można pominąć.
- można zamienić typ spotkania – zakładać je jako spotkanie Zespołu, poprzez odpalenie bezpośrednio z kanału Teams. to znów zmienia logikę…
- jak już ktoś wszedł na to spotkanie – jest dopisywany do listy – i to jest mega ciekawy hack! aż opiszę go w oddzielnym akapicie
taki scenariusz: spotkanie między C* odbyło się, ale przechwyciłem linka. dołączam do spotkania – niewiele widzę, bo nie mam historii. wychodzę ze spotkania. ale C*s dołączają do spotkanie ponownie… tyle, że informacja o mnie, referencja do mojej skrzynki jest już zapisana w spotkaniu! czyli teraz jak zaczną pisać i udostępniać pliki na chat – będą docierać i do mnie!
czy ja to rozumiem?
pomimo spędzenia jakiejś ilości czasu nad testami – w pewnym momencie nie byłem w stanie stwierdzić czy zachowanie wynika z jakiejś sekwencji, sposobu dostępu, typu użytkownika czy może złej pogody na zewnątrz. mówiąc w skrócie – całość podsumowałbym tak: *to jest nieprzewidywalne*. ponieważ nawet jeśli rozpiszemy te wszystkie permutacje, nic nam to nie da – ani nie przekażemy takiej informacji użytkownikom, ani nie jesteśmy w stanie sensownie tej informacji wykorzystać.
odpowiedź: mniej-więcej rozumiem. i dla tego radzę
co zatem zrobić?
w pierwszej kolejności: poinstruować użytkowników, aby nie dzielili się plikami poprzez chat czy na spotkaniach. pliki powinny być trzymane w bibliotekach a nie w 'notatkach’ czy chacie. to spowoduje, że będa centralnie przechowywane ze zdeterminowanymi uprawnieniami dostępu.
kolejnym krokiem jest oczywiście zabezpieczenie poprzez Unified Labeling + DLP + Conditional Access ew. IRM a dla bogatych i mocno doświadczonych – MCAS. to wszystko 'duże systemy’ choć o ostatnich zmianach [przejście z Office na Microsoft w licencjach] część funkcjonalności jest dostępnych dla mniejszych, to są to wdrożenia niełatwe i wymagają bardzo dojrzałego podejścia do całej platformy.
przestraszyłem trochę? dobrze – strach to naturalny sposób na to, aby działać proaktywnie. nie należy jednak panikować – wystarczy że zastosuje się kilka prostych zasad na początek, a potem zacznie się wdrażać wspomniane mechanizmy bezpieczeństwa.
znaleźliście inne ciekawe scenariusze? przetestowaliście wykryliście inne zachowanie lub ciekawostkę? podzielcie się w komentarzach. chętnie zaktualizuję wpis uzupełniając o kolejne niuanse – a tych jak widać nie braqje….
eN.
Obsługa tokenu w czasie rzeczywistym
Microsoft nie dostarcza produktów a platformę
Klienci uzbrojeni w licencje Microsoft chcą osiągnąć maksymalny ROI [Return of Investment], żeby nie płakać co miesiąc wydając tysiące, dziesiątki tysięcy czy wręcz setki tysięcy PLN [licencja M365 E5 to obecnie €53.7o x 1o.ooo userów – i mamy €537oo miesięcznie]. firmy więc szukają oszczędności na dwa podstawowe sposoby:
pierwsza opcja sprawdzi się w zasadzie tylko dla małych firm… i tutaj właśnie wchodzi 'M365 to platforma’. licencje podstawowe typu E1 czy Business Standard pozbawione są [drogich] elementów bezpieczeństwa – co dla wdrożenia Enterprise jest zazwyczaj niedopuszczalne. Najłatwiej byłoby oczywiście sięgnąć po licencje M365 E3 lub E5… i wtedy oczywiście pojawia się sposób drugi – próba optymalizacji wykorzystywanych produktów, wykorzystanie funkcji w ramach posiadanych licencji i pozbycie się tego, co się dupliqje.
niby oczywiste, ale podane wcześniej przykłady – DropBox czy WebEx – są bardzo proste i odnoszą się właśnie do 'produktu’. czyli aplikacji/rozwiązania realizującego określony cel. ale wiele rozwiązań jest bardzo złożonych – np. rozwiązania DLP, audyty i monitoring [SIEM i monitoring systemów], systemy EndPoint Protection itp. .
I teraz firma zwraca się z prośbą o porównanie – dajmy na to Symantec DLP z DLP dostępnym w ramach M365, aby sprawdzić czy funkcjonalności dostępne w ramach M365 są wystarczające i czy można zrezygnować z kosztów związanych z produktem, potencjalnie duplikującym możliwości, za które płaci. oczywiście pierwszy odruch – sprawdźmy Gartnera… i okazuje się, że Microsoft w ogóle nie występuje na liście dostawców DLP. [ i jeszcze np. tutaj lista wyróżnień za 2o19 ]. sprawdzamy stronę Microsoft DLP – bida. faktycznie możliwości niewielkie….
ALE
„M365 to platforma a nie produkt”
nie będę próbował udowadniać, że DLP dostarczane przez Microsoft jest lepsze niż firm, które dostarczają produkty DLP – nie jest. ale też należy spojrzeć się na problem holistycznie i zrozumieć środowisko klienta oraz całe rozwiązanie M365. część, która faktycznie widnieje pod nazwą DLP jest uboga, ale uzupełniają ją inne produkty, rozwiązania, aplikacje:
zwłaszcza ostatni przykład jest istotny – MDATP staje się bardzo ważnym komponentem całej układanki. oczywiście to przede wszystkim rozwiązania EDR/EPP [w EPP Microsoft jest liderem na magicznym kwadracie] – ale czyż 'bezpieczeństwo’ nie wymaga spojrzenia holistycznego? funkcje się nawzajem przenikają, uzupełniają – w końcu mają finalnie zapewnić pełną ochronę. Wdrażając pełny stack M365 może się okazać, że ochrona którą zapewnia jest wystarczająca.
problem na jaki natrafiam to fakt, że… to się nie spina w tabelkach. bardzo często firma mogłaby [długofalowo] wprowadzić oszczędności i lepiej zutylizować posiadane licencje M365, ale projekt architektury jest zbyt wybiórczy, nie próbuje rozpatrywać jako całość, sqpiając się na pojedynczej funkcjonalności. i tak kiedy wpisze się w excelu że 'produkt firmy A robi to i to’ a obok czy 'Microsoft X to robi?’ – często może wypaść to na niekorzyść M365.
jak zdecydować?
wybrałem DLP nie bez powodu – bo to faktycznie jedno z trudniejszych porównań. podstawowym problemem w tym kontekście jest brak uniwersalności. ale każda firma/organizacja [i jej potrzeby] są specyficzne, i nie da się podać gotowej odpowiedzi bez dobrego zrozumienia ekosystemu i wymagań. pociągnę zatem porównanie na przykładzie DLP:
to tylko kilka z podstawowych pytań, ale idea jest prosta – przyjrzeć się środowisq nie 'tu-i-teraz’ ale raczej pomyśleć o środowiq '2b’ – przyszłym. krótkofalowo może nie opłacać się wymienić tego-czy-innego komponentu, ale jeśli ustali się długofalową strategię przejścia do Chmury, to koszty i ROI liczy się nie w perspektywie pojedynczej inwestycji, tylko całego rozwiązania. przy pełnej strategii na np. 5 lat, i wyznaczeniu kierunq, tak modnego obecnie 'Digital Transformation’, nie rozpatruje się pojedynczego elementu i jak on pasuje do nas, tylko można spojrzeć z przeciwnej perspektywy – jak my możemy się zmienić, żeby najlepiej zutylizować licencje, za które płaci się grube pieniądze, i oczywiście jak powinniśmy się zmienić – żeby faktycznie zacząć korzystać z możliwości jakie dają rozwiązania Chmurowe. usilne trzymanie się przyzwyczajeń 'myślenia on-premise’ będzie kotwicą dla całej idei transformacji.
eN.