MFA – dodatek czy konieczność?

zgodnie z zapowiedzią kolejny fragment arcyciekawego wywiadu z d0m3lem. to ważny temat, więc warto o nim porozmawiać…

Czy MFA jest ważne?

<MG> W kontekście architektury zabezpieczeń, chciałbym rozszerzyć to pytanie. W ogóle jakie są największe teraz wyzwania, z którymi mierzycie się w całej tej działce Identity? Czy to jest brak wiedzy? Czy jednak te ograniczenia technologiczne, czy ten dług technologiczny?

<d0m3l> Ludzie nie chcą korzystać z MFA.

<MG> Czyli jednak interface białkowy to jest największe wyzwanie?

[…]

<d0m3l> Tak, generalnie kwestia jest taka: Spytaliśmy naszych kolegów z Google’a, jaką mają adopcję MFA? Okazuje się, że w momencie, kiedy jesteś goniony przez atakujących, przez hackerów to jest tak, jak bycie gonionym przez stado wilków. Jak Cię gonią wilki to nie chodzi o to, żeby prześcignąć wilki. To chodzi o to, żeby prześcignąć najwolniejszego w tłumie. Więc w momencie, kiedy masz włączony SMS jako jedyne MFA na Twoim koncie, na Twojej usłudze, gdziekolwiek, to Cię broni przed 1oo% zautomatyzowanych ataków. Czyli jak jest scriptkidi albo narzędzia tych atakujących hackerskich grup narodowych takich jak Iran, Somalia, Nigeria, jest parę takich bardzo fajnych organizacji, które próbują się dostać do Twojej poczty. Jeżeli masz SMS jako jedyne MFA na swoim koncie, jakikolwiek skrypt, oprogramowanie jakie mają, żeby Cię zbruteforce’ować, zespray’ować jest zablokowane. Jeżeli targetują Ciebie, jako osobę koszt zhackowania Ciebie rośnie z 70 centów do 70 dolarów i udaje im się to w 40% przypadków.

<nExoR> To jeszcze tylko jedna rzecz apropos tego MFA i statystyk, chciałem zaznaczyć, że strasznie kłamiecie. Bo nie potraficie zliczać MFA wymuszonego Conditional Accessem, gdzie na przykład w firmach administratorzy to np. 2% w stosunku do użytkowników. Administratorzy mają wymuszone MFA, cała reszta, czyli 98% ma Conditional Accessem. Co mówi Microsoft? 98% ludzi nie ma włączonego MFA.

<d0m3l> W tej chwili z mogę Ci powiedzieć dokładnie ile jest ludzi, którzy mają MFA. To jest 33% użytkowników w Office 365 podało jakiś sposób weryfikacji, że można ich w jakiś sposób wymusić.

<nExoR> Czyli to jest nie na podstawie włączonej opcji, że musisz mieć MFA, tylko to jest na podstawie danych, które zostały podane do kont?

<d0m3l> Tak.

<nExoR> To jak jesteśmy przy tym od razu. Czy będzie jakaś usługa, jakiś sposób zabezpieczenia, bo jest taka dziura w MFA przy onboardingu. Bo jak założysz konto, włączysz MFA, masz provisioning użytkowników to nadal do kogo pierwszego trafią Credentiale, ten sobie MFA ustawia. No i teraz wiadomo, że jest jakiś duży procent użytkowników, którzy, no wiadomo są takie cienie, ktoś nigdy nie przyszedł do pracy albo nie używa konta i one sobie wiszą. Jak zhackujesz takie konto to od razu sobie ustawiasz MFA, i jest jakby podwójnie uwierzytelniony w tej domenie i przez to jeszcze bardziej zhackowany. Czy tutaj można się spodziewać jakiegoś wyjścia naprzeciw? […]

<d0m3l> Generalnie są 2 sposoby. Sposób proceduralny i sposób technologiczny. Sposób proceduralny, pomijanie MFA ze względu na lokalizację, jedno z najgorszych zaleceń, jakie Microsoft kiedykolwiek wydał. MFA  powinno być też wymuszone w Corpnecie. MFA musisz zrobić zawsze. Jeden prompt per użytkownik, per urządzenie, per zmiana hasła, koniec kropka. To, że spiąłeś się VPNem nie powinno Cię wykluczać z wymagania MFA. To jest Zero Trust. To jest proceduralnie. Drugi to jest taki, że jest funkcjonalność w Conditional Accessie, która mówi, że żeby się zenrollować do MFA musisz spełniać wymagania. Jest takie coś, co nazywa się User Actions jako warunek w Conditional Accessie, gdzie możesz powiedzieć: “Żeby zenrollować się do MFA musisz być na urządzeniu, które uważam za zaufane” albo “Musisz być w konkretnym zakresie adresów IP”.

<nExoR> Zakresy IP to w ogóle są trochę od czapy te polityki z zakresami IP, bo połowa firm używa Proxy, Application Proxy czy innych mechanizmów przekierowujących ruch i wychodzenie ze stałego IP, zwłaszcza w świecie mobilnym, to jest w ogóle jakieś nieporozumienie.

<d0m3l> Kwestia jest taka, że nie ma wystarczającej ilości technologii na świecie, żeby naprawić gówniane procesy. Nie ma. Jeżeli Twój proces jest niewystarczający to możesz się bawić w hocki-klocki. Takie podatności o jakich Ty mówisz, że hacker albo zły aktor dostanie się i uwierzytelni zamiast użytkownika zdarzają się 2 w miesiącu na całą skalę Office 365. Na 320 milionów użytkowników. 2 w miesiącu. Oba z nich są łapane przez zwykłych użytkowników, którzy zostają wykopani z konta w momencie, kiedy ktoś zamiast nich dokona poświadczenia. Więc takie reaktywne wyłapywanie działa bardzo dobrze pod warunkiem, że nie masz wykluczeń MFA. Okazuje się, że najbardziej popularną polityką Conditional Access jaka istnieje jest: MFA dla wszystkich, poza zaufaną lokalizacją, czyli jeżeli jesteś na Cornplecie albo na Wi-Fi, żadnego MFA. Czyli Pani Józia, która siedzi w biurze i nigdy nie dostaje się do maila poza biurem, nigdy tego MFA nie zobaczy.

<nExoR> Tak, no wtedy go nigdy nie skonfiguruje, czyli jest niebezpieczne. No właśnie, czyli to taki drugi scenariusz.

<d0m3l> Dlatego jeżeli zły aktor dostanie hasło i spróbuje zrobić zarejestrowanie tego MFA, możesz to Conditional Accessem ograniczyć. Mówisz, że ktoś, kto ma hasło Pani Józi, żeby zarejestrować jej MFA musi być na urządzeniu, które jest dopięte do naszej domeny, musi być Hybrid Joined. I tyle.

[…]

<d0m3l> MFA musi być włączone zawsze. Ten link, który pokazałem, M365 Golden Config. Użytkownik przychodzi pierwszego dnia w pracy. Tego pierwszego dnia w pracy użytkownik musi potwierdzić, że ma dostęp do jakiegoś MFA. Problemem zaczyna się robić wdrożenie gdzie masz 23.ooo użytkowników, którzy jeszcze nie podali danych. MFA ma 1o% Faliure Rate przy rejestracji. 1o% użytkowników będzie Ci krzyczało, że nie umieją zeskanować kodu QR na ekranie.

[…]

<MG> Czy MFA jest, zadam takie pytanie znowu z wyższego poziomu, czy MFA jest idealnym zabezpieczeniem? Jak nie, to czego mu brakuje?

[…]

<d0m3l> Powiem tak: Grzesiek pytał o te statystyki Googlowe. Statystyki są prosto z konferencji, która nazywa się “Stripe”. Google mówił, że jedyne idioto-odporne, bo MFA da się zfishować. Fishing, czyli ktoś wysyła Ci maila, klikasz link i podajesz Twój login, hasło i MFA. MFA da się zrobić fish. Bez problemu, potem mam dostęp do Twojej poczty forever and ever, dopóki nie zmienisz swojego hasła. Jedyny sposób, który takiemu atakowi zapobiegnie to używanie metod poświadczeń, które są oparte o sprzęt. Czyli: Hello for Businnes – niefishowalny, Tokeny FIDO – niefishowalne. Dlatego, w momencie kiedy masz hasło i coś po haśle dopóty, dopóki to będzie aktywnym MFA, dopóty będziesz miał możliwość, że ktoś je zhackuje. Do wtedy, gdy będziesz klikał w te linki fishingowe. Nie da się zrobić, żeby mniej niż 20% Twoich użytkowników klikało w linki fishingowe. Możesz robić banery, ostrzeżenia itd.., 2o% ludzi kliknie w link, który się im pojawi w skrzynce odbiorczej. SANS Institute zrobił badania. 2o% to jest podłoga. W Microsofcie 35% ludzi jest fishowalnych, wewnętrznie u nas w firmie, bo jesteśmy przyklejeni do maila 24/7. 35% ostatnia kampania wewnętrzna fishingowa, testowa.

<MG> Czyli trzeba ogólnie całkowicie ominąć możliwość tego fisha, czyli tak, jak mówiłeś, Tokeny FIDO na przykład.

<A> Ale pamiętaj, że jeszcze masz drugą możliwość, czyli na przykład “o, tu jest taka fakturka”; “Ty, słuchaj, nie chce mi się w niczym otworzyć, zobacz co to”.

<d0m3l>     No. „Każdy burdel da się ogarnąć, tylko proszę dane do faktury”, nie? Ale to już jest chyba trochę taki Social Engeneering, prawda?

End Of Quote

oryginał rozmowy tutaj.

o ważności MFA jestem świadom i zawsze jest to pierwsza rzecz jaką sprawdzam – czy jest włączone. muszę przyznać, że zezwolenie na brak MFA kiedy się jest w biurze wydawało mi się zawsze dobrym pomysłem. teraz nie jestem już taki pewien (; pozostawiam do oceny czytelnikom.

eN.

czy Microsoft słucha użytkowników?

pasjonaci IT

nie tak dawno zapraszałem na spotkanie z Danielem Stefaniakiem, IAM Product Manager w Microsoft, pracującym w samym sercu tego, gdzie powstają usługi M365 – w Redmond. pełne nagranie z tego spotkania można obejrzeć na YT na kanale “Pasjonaci IT” . ilość wiedzy jaka posypała się podczas tych 1,5h okazała się olbrzymia. ponieważ nie każdy lubi słuchać, niektórzy nadal lubią czytać – zamieszczę kilka ważnych informacji jakie padły podczas tej rozmowy. dziś na smaka wrzucę fragment dotyczący User Voice – czy to tylko taki ‘anti-stress button’ żeby ludzi mogli wylać swoje frustracje, czy faktycznie Microsoft przygląda się tym wpisom, analizuje i zmienia swoje plany?

poniżej fragment transkryptu, który może być nieco zmodyfikowany dla wygody czytania.

UserVoice

  • <nExoR>   […] to ciekawe, co powiedziałeś. Wiem, że uservoice funkcjonuje całkiem fajnie od jakiegoś czasu, natomiast jak to realnie wygląda procentowo? No bo uservoice – uservoice’em, natomiast musi być jakaś road mapa odgórna. czy jesteś w stanie określić na ile procentowo jest to uservoice, na ile odgórne ustalenia? np. uservoice to jest 15% całego rozwoju, a 85% to jest roadmapa, czy może jest odwrotnie, że właśnie 15% to jest jakaś odgórna wizja, a 85% to jest to, co ludzie chcą? Jak byś to mniej więcej określił?
  • <d0m3l>  W mojej działce, w Azure Active Directory [IAM], uservoice to jest około 15 – 2o% . Tak naprawdę chodzi o to, że w tej chwili Azure AD to jest system, który wiezie ze sobą 32o milionów użytkowników codziennie, więc to nie jest taki stateczek, który da się zawrócić z dnia na dzień. Więc w tej chwili korzystamy z uservoice’ów, albo z pracy z największymi klientami z Fortune 5oo, którzy na nas krzyczą: “Dlaczego to, kurka, tak nie działa? Bo próbuję zrobić XYZ, ale Wy mi nie dajecie takiej możliwości”. więc szturchamy na prawo i lewo, żeby ten stateczek popłynął tam, gdzie klienci będą chcieli na niego wsiąść, bo na pewno nie stoi w miejscu. Więc z uservoice te rzeczy, które mają powyżej 1oo głosów, czy tam 15o, muszą być wciśnięte w road mapę na najbliższe 12 miesięcy. Nasza Pani Vice President powiedziała, że tak ma być, koniec kropka: “Właściciele funkcjonalności wymyślcie, jak zaadresować uservoice’a”.
  • <MG>        1oo – 15o głosów to nie jest taki duży próg…
  • <domel>     W Azure AD to jest bardzo wysoki próg.
  • <nExoR>   Naprawdę? Tak mało jest uservoice’ów?
  • <domel>     Tak. Największy uservoice ma 13oo głosów.
  • <nExoR>   I na co jest?
  • <domel>     Rozdzielenie albo połączenie Microsoft Account i kont Azure AD. Bo, jak pamiętacie LifeID rozdzieliło się od Office 365 w jednym momencie i teraz się okazuje, że  jak masz LifeID i konto w Office 365 na ten sam adres e-mail to masz ten głupi label pod tytułem “konto organizacyjne vs. konto prywatne“, więc ludzie na to bluzgają strasznie. Drugi w tej chwili to jest chyba cel w Service Password Reset bez dostępu do kontrolera domeny, więc to są dwa takie największe. Teamsy mają dziesiątki tysięcy uservoice’ów [bo to frontend’owa aplikacja]

End of Quote

swoją drogą sprawdziłem i są jeszcze dwa requesty:

  • nested groups: ~18oo głosów
  • tokeny B2C zawierające członkostwo użytkownika: ~15oo głosów

i to faktycznie max. a Top Ideas dla Teams ma ponad 55k. to pokazuje, różnicę backend vs frontend q:

w świetnym dziele filozoficznym, post-humanistycznym “Po piśmie“, Jacek Dukaj pokazuje jak zmieniała się ludzkość na przestrzeni dziejów – z kultury mówionej, teraz przez literacką… a w przyszłości w przekaz natychmiastowy. ludzie już dziś wolą obejrzeć niż przeczytać, podcasty i filmy zastępują książki, video zastępuje instrukcje i poradniki…

jestem dinozaurem – ja wolę czytać. albo może to technologia jeszcze nie dorosła po prostu – bo jak wyszukać jakiś interesujący fragment? jak wyszukać interesującą frazę w 1,5h materiale? albo jak ‘przelecieć wzrokiem’ video? czasem mniej ciekawe fragmenty artu można po prostu szybko ominąć, przy video trudniej. dla tego  w najbliższych dniach dodam jeszcze trochę fajnych informacji z naszej rozmowy – bo czasem tygodnie, a nawet miesiące surfowania, nie dadzą takich wyniqw.

d0m3lu – dzięki [twoje konto cały czas jeszcze jest na w-files q: ]

eN.

M365 jako platforma – inna perspektywa

kolejne spojrzenie na ‘platformę’ – w dwóch kontekstach. po pierwsze – bezpieczeństwo, po drugie – konsekwencje ‘on-premowego myślenia’. w sumie to odwrotnie, bo zaniechania z w prawidłowej konfiguracji bezpieczeństwa wynikają głównie z faktu, że M365 nie jest prawidłowo rozumiane. bo cały czas poqtuje ‘stare myślenie’. taka oto anegdota [prawdziwa], która powinna dobrze zobrazować, co mam na myśli…

dzień dobry, my po Teamsy….

niedawno, po wybuchu pandemii, duża firma postanowiła zwiększyć możliwości pracy z domu [#WFH]. więc firma chce wdrożyć Microsoft Teams. *tylko* Teams…

[parafrazując] “no bo przecież takie Teamsy, to zainstaluje się i już – ludzie mogą sobie korzystać. mamy jakieś licencje i to w ramach EA nawet O365 E3 i to całkiem sporo. nie chcemy od razu dla wszystkich tylko małymi kroczkami – odpalimy dla np. 5o osób jako PoC a potem dla reszty organizacji. a jakieś dodatki typu skrzynki czy OneDrive to może potem. na razie chcemy szybko [i tanio], żeby skorzystać z możliwości tej wspaniałej pracy grupowej, jaką daje Teams”…

khmmm… no i to takie “onpremowe myślenie”. zupełnie wszystko do góry nogami. jeśli nie wiecie o czym mówię – to znaczy, że jeszcze musicie się w M365 wgryźć… jakie błędy zostały popełnione w tym rozumowaniu? zadajmy klientowi kilka pytań i co się okaże:

  • jest już AD. oczywiście powinno być SSO, a w przyszłości bardziej wykorzystać usługę. czyli trzeba zacząć od zaprojektowania tożsamości hybrydowej, synchronizacji, określić zasady synchronizacji – nawet jeśli początkowo synchronizowałoby się tylko kilka osób, to trzeba zrobić pełny projekt. firma niemała, AD niemałe, a wiadomo – jak się zajrzy do szafy [AD] to zaczną trupy wypadać [cała historia i nakładające się modele zarządzania]. trzeba jakieś serwery dla ADConnect postawić, redundancja, ustalić metodę uwierzytelnienia – w końcu to ma być produkcja, jak się źle poustala, to potem będzie ciężko to zmieniać… to tak w ramach rozgrzewki…
  • jest Exchange on-premise. ale Teams korzysta ze skrzynek pocztowych. nie dość, że trochę ciężko przewidzieć co by się stało jak by to tak po prostu rozdzielnie potraktować [znaczy duplicate-mailbox by się stało], ale klient wspomniał, że będzie raczej chciał usługę mocniej utylizować w przyszłości. a to oznacza hybrydę Exchange – i znów projekt i DNSy i mailflow i reguły na FW itd….
  • jest oczywiście i SfB on-premise… czyli musi być współdzielony SIP domain, hybryda SfB … i znów – trzeba to zaprojektować, wdrożyć ….
  • przetwarzane są informacje wrażliwe a firma podlega licznym normom i wymaganiom bezpieczeństwa – a więc trzeba skonfigurować polityki bezpieczeństwa dla wszystkich komponentów, ustalić co użytkownicy mogą a czego nie mogą … o tym więcej za chwilę, ale już widać – że to nie zadanie na 5 minut tylko ciężki projekt.

w dużym skrócie – nie ma pojęcia ‘tylko Teamsy’… no ok, da się ‘tylko Teamsy’. można wdrożyć na szybko tenant M365, zostać przy domenie *.onmicrosoft.com i sobie z Teamsów korzystać od razu. ale nie ma mowy o integracji, nie ma mowy o tym, żeby to post factum łączyć ze środowiskiem on-premise [technicznie się da, ale czas i koszty…], funkcjonalność będzie ograniczona, no i tak czy inaczej – trzeba to przecież zabezpieczyć… ma być zgodność z normami i bezpieczeństwo – a gdzie licencje EMS? a to będzie kosztowało …. w sumie to bez różnicy bo kwota już i tak przekroczyła jakiekolwiek wyobrażenia wstępne – coś co miało być szybkim wdrożeniem dla 5o osób okazuje się olbrzymim projektem – być może na długie miesiące. o kwotach nawet nie wspominam.

to tylko skrzynki Exchange

o bezpieczeństwie myślą niby wszyscy, niektórzy próbują, ale niewiele osób ma pojęcie co to w ogóle znaczy ‘bezpieczeństwo M365’. może inna anegdota, tym razem mniejsza firma, ale schemat [czy raczej końcowy efekt], który obserwuję bez względu na wielkość firmy:

“mamy pocztę w takim to serwisie, i kupiliśmy licencje o365 i będziemy migrować”

“a bezpieczeństwo? macie jakiś projekt/pomysł jak to zabezpieczyć?”

“ale to tylko skrzyneczki”

czy aby na pewno? najbardziej oczywistym elementem, który pewnie każdy wskaże – jest tożsamość. w rozwiązaniach Chmury publicznej bezpieczeństwo sqpia się głównie na tożsamości [i danych]. w nazwie ‘Chmura Publiczna’ dość kluczowe jest słowo ‘Publiczna’. każdy – skądkolwiek na świecie, może próbować się logować, atakować konta itd. ale to dopiero początek… o czym [z przerażeniem zauważam] się zapomina. przecież wystarczy pojedyncza licencja, choćby trial, choćby wygasła dawno temu – ale jeśli była, to uruchamiane zostały w ramach M365 usługi, które objęte są/były licencją! to że licencje wygasły – nie wyłącza usług w ramach tenanta – co najwyżej z usługi nie da się w pełni korzystać, ale ona działa. to, że firma chce ‘tylko skrzyneczki’, nie oznacza, że cała reszta nie istnieje. to nie jest onprem – w którym stawiamy sobie Exchange, a reszty nie ma, bo jeszcze nie zdecydowaliśmy czy instalować serwer SharePoint – te usługi są, działają, mają jakieś ustawienia wyjściowe, są dostępne – czyt. można próbować się do nich dostać. i nie mówię tylko o próbach włamania. zauważyłem, że powszechną praktyką jest przypisywanie użytkownikom pełnych licencji, bez wyłączania planów serwisowych – nawet jeśli firma jeszcze nie planowała z nich korzystać. a to oznacza, że użytkownicy mogą korzystać z pozostałych usług i zrobić sobie krzywdę. czy też firmie. np. przypadkiem udostępniając plik z danymi wrażliwymi, lub w ramach zabawy i nauki ustawić jakiś konektor, który automatycznie gdzieś tam wysyła maile czy kopiuje pliki…

a tych usług jest dużo: OneDrive, SharePoint, Teams, same grupy M365, co za tym idzie wieloraka możliwość współdzielenie plików na zewnątrz, możliwość dodawania dowolnych konektorów – i w Outlook i w Teams i w … można by tak wymieniać a szczegółów jest dużo.

a całe środowisko M365 projektowane jest przez DevOpsów tak, aby zaspakajać ich potrzeby. czyli wszycy-wszytko-wszytkim-zawsze-wszędzie-proszęBardzo. zupełnie jak na tych teaserach reklamowych Microsoft Teams – gdzie wszyscy są kreatywni, wszyscy piękni, młodzi i ambitni i świetnie adaptują te nowe super technologie. taaa… i rozgrzeszenie i życie wieczne za darmo, przy wyqpieniu Software Assurance.

życie zazwyczaj wygląda nieco odmiennie. dla tego…

ZABEZPIECZ SWOJE M365 KOMPLEKSOWO i AUDYTUJ

nie ma że ‘tylko skrzyneczki’ czy ‘tylko Teams’. trzeba wdrożyć minimum bezpieczeństwa dla *całego tenanta* – czyli wszystkich usług, bez względu no to czy dziś chcemy z nich korzystać. tym bardziej, że jest bardzo wiele elementów, związanych bezpośrednio z AAD i o365, które są dla wszystkich – a [prawie] nikt i tak tego nie konfiguruje zostawiając ustawienia wyjściowe, które są [za]bardzo liberalne. do tego trzeba pamiętać, że Chmura to nie jest ‘produkt w wersji X’ – to jest dynamicznie rozwijające się środowisko. dla tego nie wystarczy ‘zabezpieczyć’ – trzeba robić przeglądy, sprawdzać jakie nowe aplikacje się pojawiły, jakie dodatki – bo za chwilę pojawi się kolejna nowa aplikacja, która wymaga znów przyjrzenia się jej możliwościom i bezpieczeństwu, ocenić czy użytkownicy będą z niej korzystać i w jaki sposób i zaplanować co z nią zrobić i jak skonfigurować – bo wbrew dość powszechnej opinii – SaaS wcale nie oznacza, że tam się nic nie konfiguruje, czy że wszystko jest od razu bezpieczne.

jeśli myślisz poważnie o bezpieczeństwie a twoja firma musi być zgodna z normami – pomyśl od razu o licencjach EMS, M365sec, albo przynajmniej Business Premium dla mniejszych.

a po wiedzę – cóż, trzeba zgłosić się do odpowiednich konsultantów (:

eN.

Microsoft nie dostarcza produktów a platformę

Optymalizacja ROI

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:

  • biorą minimalne licencje – np. tylko Office365 E1/E3 czy wersje Business dla mniejszych
  • starają się jak najlepiej zutylizować te licencje, które posiadają – np. rezygnując z produktów, na rzecz tego, co jest w ofercie Microsoft – zastąpić DropBox przez OneDrive czy webEx przez Teams

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:

  • jest część funkcjonalności stricte nazywająca się DLP w M365
  • w zasadzie cała szersza część tzw. ‘Compliance&Security’ adresuje niektóre elementy DLP. choćby np. polityki retencji danych czy mechanizm Sensitive Labels, a można wymieniać więcej
  • część funkcjonalności dostępne jest jako mechanizm wbudowany OS Windows – np. WIP (Windows Information Protection) – co podlega zarządzaniu, zależnie od MDM dla Windows – czy to przez GPO, czy SCCM czy przez InTune jako urządzenie mobilne. DLP to przecież również prawidłowe zabezpieczenie prawidłowości konfiguracji stacji
  • do tego dochodzą produkty bezpieczeństwa takie jak CASB/MCAS (Microsft Cloud App Security) do kontroli sesji i reguł alertowania i monitoringu, cała konfiguracja polityki ochrony tożsamości, czy MDATP (Microsoft Defender ATP) działający jako część całego ekosystemu po stronie endpointów, czy AATP (Azure ATP) – co prawda to rozwiązania bardziej do monitoringu bezpieczeństwa ogólnie, ale pewne elementy się wzajemnie uzupełniają

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:

  • czy rozwiązanie ma zapewnić ochronę na serwerach on-premise? Microsoft’owe DLP potrafi to w bardzo ograniczonym zakresie, więc może nie wystarczać
  • czy ochrona ma obejmować stacje działające na systemach typu Linux, OSX czy innych wynalazkach? zazwyczaj backoffice działa na Windows ale wiadomo – OSX jest również popularną stacją roboczą. jeśli odpowiedź jest pozytywna – to dochodzi kolejna kwestia…
  • gdzie są przechowywane dane. cały czas firmy żyją wedle starych przyzwyczajeń i dane są na serwerach onprem i stacjach użytkowników – więc może warto pomyśleć o prawidłowej adaptacji Chmury i przenieść się do OneDrive/SharePoint? uniezależnić stacje robocze od lokalnego AD i lokalnych serwerów i zacząć tworzyć je według idei ‘mobile workstation’, z danymi w Chmurze, zarządzane przez InTune? a wtedy również MS DLP będzie bardziej przydatne – bo zoptymalizowane jest właśnie pod takie zastosowanie.

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.

 

 

wygaszanie tokenów – zmora bezpieczeństwa i CAEP

Obsługa tokenu w czasie rzeczywistym

wpis dotyczy nowego mechanizmu bezpieczeństwa – Continues Access Evaluation Protocol. bardzo fajnie, że Microsoft w końcu adresuje bardziej życiowe sytuacje dotyczące sesji użytkownika – konkretnie obsługę wymuszenia wygaśnięcia tokenu uwierzytelnienia. obserwując jednak z poziomu wyższego, działania aplikacji, mam obawy, że to nie adresuje najważniejszych bolączek. przekonamy się wkrótce.

ale…. o czym ja mówię?

przykład podany w linkowanym arcie dotyczy wymuszenia wygaśnięcia tokenu bezpieczeństwa np. w przypadq zmiany typu sieci (biurowa/otwarta) w trakcie trwania sesji. w tej chwili token jest przyznawany na 1h i sobie jest póki nie wygaśnie.

ale obserwuję większy problem. 1h nie brzmi jak problem – ale już 2 dni? z praktyki i obserwacji tak właśnie to wygląda – użytkownicy, którzy zostali zablokowani lub wyłączeni często mają dostęp do danych nawet przez kilka dni. na to ile de facto to będzie czasu, wpływa wiele czynników:

  • czy środowisko jest cloud-only czy hybryda
  • jeśli hybryda to w jakim trybie – PHS, PTA czy ADFS? każdy z mechanizmów zmienia przebieg procesu uwierzytelniania i znacząco zmienia wiele aspektów związanych z bezpieczeństwem tożsamości.
  • pośrednio konfiguracja Conditional Access
  • wykorzystanie Cloud App Security – który podobnie do CAEP ma na celu kontrolę sesji a nie warunków dostępu
  • system operacyjny na końcówce – iOS, Android, Windows… na każdym apki zachowują się nieco inaczej
  • inne ustawienia typu konfiguracja serwera MFA w AAD ile czasu może być cache’owany.

w efekcie miałem okazję obserwować sytuacje, w których użytkownik jeszcze przez kilka dni (sic!) miał dostęp do swojego maila. tak – mógł odbierać i wiadomości. póty, póki nie zabił aplikacji na urządzeniu – dopiero wtedy pojawiło się żądanie uwierzytelnienia.

jest nadzieja, że ta oddolna zmiana opisuje tylko część konsekwencji ale w rezultacie zaadresuje ten problem – zwłaszcza, że pierwszymi klientami, które dostaną update jest Outlook i Teams.

procedury w przypadkach krytycznych

jest (teoretyczna) możliwość zabicia wszystkich sesji użytkownika i zmuszenia go do odświeżenia tokenu. jest również możliwość wyczyszczenia danych na końcówkach.

wipe-out

wyczyszczenie danych na końcówce jest możliwe jedynie jeśli zarządzane są aplikacje lub stacja – scenariusze BYOD z managed apps oraz klasyczny MDM z tzw. ‘enrollmentem’ urządzeń. odpowiednik ‘dodania do domeny’ pod kontrolę InTune (lub innego MDM) do zarządzania końcówką. wtedy zależnie od scenariusza (managed apps/MDM) możemy z portalu Azure wymusić wyczyszczenie danych firmowych (managed apps) lub całego urządzenia (MDM).

warunkiem jest oczywiście, że urządzenie zarejestruje się do sieci, co w przypadq świadomej kradzieży w celu pozyskania danych nie jest oczywiście dużym pocieszeniem. warto również pamiętać, że to już podlega licencjom InTune.

reset sesji

ciekawszym i bardziej powszechnym scenariuszem jest reset sesji użytkownika. po co? uwierzytelnienie jest ‘bramą’ którą jak się przekroczy, mamy określony czas przebywania (sesję). do tego należy dodać różne mechanizmy cache – obecne zwłaszcza w aplikacjach mobilnych, ze względu na … mobilność. czyli częste utraty sieci i zmiany punktów dostępowych. pomimo, że token uwierzytelniania żyje 1h, to sesja utrzymywana jest, aż do zerwania albo jakiegoś timeoutu w aplikacji. dla Outlook obserwowałem długie czasy, sięgające nawet 2 dni [dodam, że taki scenariusz miałem ok roq temu – to o tyle istotne, że przy obecnej szybkości zmian, nie do końca wiadomo co jest aktualne. nie robiłem testów ostatnio].

(teoretyczny) reset sesji można wykonać na 3 sposoby. czy też może w 3ech krokach? bo nie jest dla mnie oczywiste w których częściach te kroki się pokrywają a w których wymagają wykonania oddzielnie [zapraszam do komentarzy i wrzucenia linqw – jeśli ktoś posiada materiały wyjaśniające te ‘detale’, a jakże istotne ze względu na bezpieczeństwo].

  • z interfejsu AAD, w części ‘Authentication Methods’ – opcja ‘Revoke MFA sessions’
  • z PowerShell Revoke-AzureADUserAllRefreshToken, który zgodnie z opisem ‘unieważnia wszystkie tokeny wydane dla aplikacji użytkownika’
  • z portalu M365 Admin Center – wyszukując użytkownika, w zakładce… OneDrive. tam dostępna jest opcja, która obecnie opisana jest ‘Sign-out of all Office 365 sessions’

historycznie opcja ‘sign-out user sessions’ działała tylko dla OD właśnie. czy dziś, zostając w tym samym miejscu w interfejsie, zrywa faktycznie sesje? podam taki przykład świeży, z przed miesiąca:

wraz z końcem miesiąca, zakończyło pracę sporo osób pracujących w projekcie i z dostępami administracyjnymi. ok. 3 dni później zgłasza się do mnie jedna z osób z pytaniem, czemu osoba, która już nie powinna być w organizacji ‘świeci się w Teams na zielono’ – czyli jest jako aktywna. konto zablokowane, wszelkie resety porobione. nie pomaga. mija kolejny dzień – nadal ‘active’. zakładam ticket w MS Support, jakaś tam analiza logów, że user zablokowany, że na pewno nie może się dostać – generalnie nic, czego bym nie wiedział. odpowiedzi na to, czemu sesja jest widoczna jako ‘active’ i jak taką sesję zabić – brak. w tej sytuacji nie było zagrożenia, bo faktycznie wszystko było poblokowane i potwierdzały to logi dostępowe, ale ogólnie… brak narzędzi pozwalających na jakąkolwiek kontrolę sesji użytkowników to spory problem chmury. pozostawia sporo niejasności, co w kontekście bezpieczeństwa nie jest pożądane.

liczę na to, że implementacja CAEP znacząco poprawi element kontroli sesji….

eN.

Teams: grupowy bałagan


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:

  1. 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?
  2. jak ktoś dołączy do spotkania – czy będzie widział zapis rozmowy i wszystkie pliki?
  3. po zakończeniu spotkania – jak osoby dołączą ponownie, czy będą tam te wszystkie pliki i zapiski i notatki?
  4. 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.

opcje spotkań Teams i wspólne oglądanie

dodatkowe opcje spotkań Teams

Teams przeżywa boom, jednak wiele opcji pozostaje niezbyt jasnych, drobna porcja nieoczywistości – czyli dodatkowe opcje spotkań Teams.

z niewyjaśnionych przyczyn, pewne opcje spotkania Teams nie są dostępne ‘normalnie’ podczas tworzenia spotkania, a co najmniej jedno z nich jest bardzo przydatne. owa ważna opcja to możliwość zdefiniowania kto może prezentować. standardowo – każdy, bo Teams historycznie jest narzędziem ‘agile’ do pracy ‘współdzielonej’ na równych warunkach. w tym przypadq rzeczywistość weryfiqje konieczność pracy z dziećmi i prowadzenie zajęć – bo o ile na spotkaniu firmowym nikt raczej nie zacznie nagle pokazywać swojego ekranu, ale z dzieciakami wiadomo… czy też raczej właśnie nic nie wiadomo.

ogólnie ‘opcje dodatkowe’ to:

  • kto może nie czekać w lobby – standardowo ‘zewnętrzni’ czekają. niestety braqje opcji ‘nikt’ tak aby każdy musiał poczekać na prezentera /: póki co goście poczekają w poczekali a osoby z tego samego tenanta to ‘bliska rodzina’ która może wejść w dowolnym momencie.
  • dwie opcje dotyczące ‘wdzwanianych’ – opcja wymaga service planu ‘Audio Conferencing’ która umożliwia dołączenia via PSTN (zwykły telefon). opcje pozwalają ustawić lobby oraz wyłączyć powiadomienia głosowe kiedy ktoś dołącza lub opuszcza spotkanie z telefonu (mega rozbijające).
  • no i wspomniana opcja ‘kto może prezentować’.

co ciekawe… większości ustawień standardowych dla tych opcji nie da się wysterować się administracyjnie. są opcje dotyczące ‘wdzwanianych’, dla ułatwienia inaczej się nazywają:

ogólnie dla osób szukających co można w Teams ustawić/włączyć/wyłączyć – przypominam, że jest panel https://admin.teams.microsoft.com …. wraz z przypomnieniem o ostrożności (;

jak dostać się do opcji

do opcji można dostać się dopiero PO założeniu spotkania. trzeba z powrotem wejść do spotkania i wśród wygenerowanych linqw pojawia się ‘Meeting Options’ – można wejść zarówno z kalendarza Outlook czy Teams, bo to po prostu część ‘tekstu’, opisu spotkania.

wspólne oglądanie

na koniec opcja, o którą męczyła mnie córa, dla której Teams to teraz podstawowy sposób na spotkania ze znajomymi – jak wspólnie pooglądać YouTube?

proste ale nieoczywiste. wystarczy mieć możliwość prezentowania (czyli by default każdy), wybrać opcję prezentowania (sugeruję tylko przeglądarkę a nie cały pulpit, choć to nie ma znaczenia dla tego działania) i należy zauważyć, że jest tam opcja, która jest standardowo wyłączona – ‘Include system audio’ – dzięki której dzieciaki mogą wspólnie bawić się Internatami (;

eN.

Jak nie zakładać spotkań MS Teams

opis problemu

spotkanie w Teams każdy umie założyć. nic wielkiego – ot wchodzimy do kalendarza Outlook czy Teams i klikamy ‘new Teams Meeting’. mniej-więcej. ale przy zakładaniu spotkań hurtowo, szukamy drogi na skróty. i nagle zaczynają się dziać dziwne rzeczy – jedne osoby weszły na inne spotkanie niż pozostałe, a to nagle pojawia się jakiś stary chat, który tu nie powinien być, a to nie to spotkanie, którego się spodziewaliśmy? o co chodzi? dla czego tak się dzieje?

przykłady scenariuszy biznesowych przy których tak się działo otrzymałem od osób, które zajmują się organizacją spotkań i robią ich wiele dla różnych grup…

o co cho? czyli jak nie tworzyć spotkań Teams

aby zrozumieć problem musiałem najpierw zrozumieć jak te osoby zakładają spotkania. okazało się, że dla przyspieszenia procesu robią np:

  • copy-paste spotkania zmieniając osoby
  • ‘przesuwanie’ spotkania z przeszłości w przyszłość, żeby je powtórzyć
  • kopiują link do spotkania, tworzą maila do wybranych osób i wysyłają link zwykłym mailem lub zaproszeniem do kalendarza
  • różne kombinacje powyższych metod polegające na ‘jakimś skopiowaniu’ informacji o spotkaniu i wysłaniu go innym kanałem. jednym z najgorszych (co zaraz pokażę) opcji jest założenie spotkania Teams, po czym wklejenie do zaproszenia linku z innego zaproszenia…
  • ciekawym scenariuszem jest – jak zaprosić osoby na spotkanie tak, żeby były w BCC a nie widoczne. ale, to tak tylko na boq…

no więc o co chodzi? dla czego zaczynają się dziać dziwne rzeczy? wynika to z tego czym ‘Teams Meeting’ jest.

nietechniczne, najlepiej traktować każde nowo utworzone spotkanie jako ‘stworzenie nowego pokoju (wirtualnego)’, w którym jest biurko/szafa, na którym zachowywane są materiały używane podczas spotkania – chat, nagrania, załączone pliki etc. to jest clue całości, więc powtórzę, trochę inaczej:

aby móc zachowywać unikalną historię spotkania i materiały z nim związane, dla każdego spotkania tworzony jest oddzielny pokój.

adresem takiego pokoju jest oczywiście link do spotkania, którym zajmę się na końcu – ciekawe dla technicznych. w związq z tym co powyżej, jeśli kopiujemy spotkania – de facto zapraszamy osoby do tego samego pokoju, wraz z jego historią. jednym z najciekawszych scenariuszy jest:

  • założyć spotkanie poprzez ‘new Teams Meeting’
  • wycięcie treści zaproszenia
  • wklejenie linka z innego spotkania, np jakiegoś tam z przeszłości.

w takim scenariuszu są dwa różne linki – jeden zapisany ‘w spotkaniu’ i drugi – wklejony. co techniczne oznacza ‘zapisany w spotkaniu’ za chwilę, a widok normalny to:

i zarówno wchodząc przez opcję wskazaną na obrazq, jak w momencie kiedy kalendarz wyświetla przypomnienie z opcją ‘join online’ – to jest link ‘zapisany w spotkaniu’ i niewidoczny gołym okiem. link ‘wklejony’ jest nieprawidłowym adresem, innego pokoju. w efekcie – część osób kliknie w link, część zatwierdzi popup kalendarza – i mamy dwa spotkania w tym samym czasie.

należy zatem takich ‘przekładanek’ unikać, chyba, że świadomie chcemy trafić do tego samego pokoju, wraz z jego historią.

technicznie

teraz dwie informacje przydatne przy ew. debugowaniu problemów lub po prostu z ciekawości: jak zbudowany jest link to spotkania oraz jak podejrzeć ‘zapisany w spotkaniu’.

konstrukcja linku MS Teams

oto przykładowy (fejkowy) link do spotkania:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZjjakKI4NjAtXxY3My00ZYuJLWFmNAbCY2U2YzE3ZGJlYWVm%40thread.v2/0?context=%7b%22Tid%22%3a%22bc6245c1-aabb-9999-b2a1-6219a2cca5dc%22%2c%22Oid%22%3a%2294df7928-cfex-4abc-82cf-1ea2b35afeea%22%7d

na pierwszy rzut okiem widać elementy spotkania i jakieś GUIDy. deszyfracja:

{standardowy link do aplikacji MS Teams} {identyfikator spotkania aka ‘nr. pokoju’} {GUID tenanta AzureAD} {GUID mailboxa w którym jest zapisane. konkretnie ExternalDirectoryObjectId}

czyli adres spotkania składa się z instrukcji: Aplikacja Teams, spotkanie nr “XYZ”, u klienta “contoso.com”, hostowane przez osobę “mr.Hoster”. ta ostatnia wartość wynika z faktu, że informacje dotyczące Teams zapisywane są w skrzynce osoby, która go tworzy. tak, w niewidocznym miejscu, ukryte katalogi. pliki i nagrania oczywiście są na SharePoint – również w ukrytych site’ach, niewidocznych normalnie.

gdzie jest zapisany link do spotkania

a informację ‘zapisaną w spotkaniu’ można podejrzeć w widoku Developer . po włączeniu opcji Developer przejdź do widoq formularza

i tutaj w polach formularza są informacje dotyczące spotkania, m.in. link, który jest pod ‘Join Online’

eN.

zarządzanie użytkownikami w hybrydzie

ponieważ to pytanie wraca do mnie niemal przy każdym projekcie i ponieważ obserwuję problem w zrozumieniu tych mechanizmów, zamieszczam krótkie podsumowanie najważniejszych informacji, które powinny pomóc w przygotowaniu doqmentacji ‘zarządzania użytkownikiem’ oraz administracji w środowisq hybrydowym.

‘Hybryda’

wedle moich obserwacji najważniejsze, a zarazem wymykające się intuicji jest to, że ‘hybryda’ tak na prawdę w większości wdrożeń powinna być nazywa ‘hybrydy’ – w liczbie mnogiej. w standardowym scenariuszu mamy bowiem:

  • hybryda tożsamości – połączenie pomiędzy AD i AzureAD. obiekty wraz z atrybutami synchronizowane są z onprem do Chmury, zapewniając (przy odpowiedniej konfiguracji) pojedynczą tożsamość i SSO (lub same-password w mniej wykwintnej implementacji)
  • hybryda Exchange – połączenie pomiędzy Ex a EXO. to co zaburza intuicję jest fakt, że wiele atrybutów Exchange jest przechowywanych w AD i synchronizowanych w ten sam sposób. jednak włączenie/wyłączenie hybrydy Exchange to w dużej mierze właśnie zdefiniowane czy ten zestaw atrybutów ma być synchronizowany czy też nie.
  • hybryda SfB – czyli połączenie pomiędzy onpremowym Lync/SfB a SOL/Teams. i tutaj podobnie jak w przypadq Exchange – mylącym jest fakt, że w takim środowisq informacje na temat konta SfB są zapisywane w AD i tak synchronizowane.

każdą z nich można mieć lub nie mieć … no ok, hybryda tożsamości musi być w każdym scenariuszu – ale Ex czy SfB to już kwestia wymagań klienta.

teoretycznie ‘hybryda’ powinna dawać jedno, centralne miejsce zarządzania i unifikację… de facto sprawa jest bardziej zagmatwana, ale poniżej przedstawione zasady powinny pomóc

Zarządzanie użytkownikami

zarządzanie użytkownikami w środowisq tożsamości hybrydowej odbywa się w zasadzie w pełni z onprem. w tym przypadq jest zatem najmniej zmian w kwestii procedur zarządzania.

wyjątkiem są:

  • zarządzanie licencjami, ale wtedy na pomoc przychodzi Group-Based Licensing .
  • wymuszenie zmiany hasła
  • do różnic można dorzucić jeszcze rozwiązywanie problemów i audyt – oczywiście zdarzenia logowania i te ‘ruchome elementy’ dzieją się w ramach AAD więc tutaj też trzeba sięgnąć do chmury…. a w zasadzie do obu środowisk na raz (a w ogóle to najlepiej jakiś SIEM zintegrowany).

należy dodać do tego pewne bardziej skomplikowane sytuacje, ponieważ wybór strony gdzie należy wykonać akcję może się różnić zależnie od metody uwierzytelnienia (PH, PTA, ADFS) lub wdrożenia SSPR – ale to są wszystko kwestie z zakresu obsługi hasła czy blokady konta.

Zarządzanie Exchange

ten element jest najbardziej kłopotliwy i hybryda Ex generalnie ma swoje specyficzne ograniczenia… największą pomocą jest tutaj traktowanie oddzielnie skrzynki i użytkownika. w ogólności są dwie perspektywy: administracja serwisem i użytkownikiem. pierwsze jest proste do wyjaśnienia:

  • Ex i EXO są rozdzielne – polityki bezpieczeństwa, mail flow, ustawienia globalne – robi się oddzielnie po obu stronach i nie są to elementy podlegające synchronizacji.
  • sprawa jest dość skomplikowana w przypadq polityki maili (recipient policies) bo … przenikają się częściowo. nie mogę teraz znaleźć linka.. ale w uproszczeniu najlepiej też zarządzać z onprem – ponieważ tam jest konto użytkownika i synchronizowany atrybut ‘proxyAddresses’

przy zarządzaniu pojedynczym użytkownikiem:

  • operacje związane z kontem użytkownika wykonuje się z onprem (aliasy mailowe, zmiany nazw/opisów/informacji)
  • operacje związane ze skrzynką – po tej stronie gdzie jest skrzynka [bo może być przecież albo tu albo tam] (limity skrzynki, statystyki, uprawnienia). w skrócie to, co robi ‘set-mailbox*‘ wykonuje się tam, gdzie ten mailbox leży.

jest kilka ‘dzwinostek’ typu uprawnienie ‘send as’ które wynika z faktu, że jest de facto zapisywane w AD i niesynchronizowane. zarządzanie, czy wspomniane przetwarzanie polis recipient policies, które w specyficznych przypadkach może wydawać się niespójne… są też różnice zależnie czy która wersja jest w OnPrem (zwłaszcza, jeśli to Ex 2o1o).

napisanie spójnych procedur zarządzania dla Exchange Hybrid jest wyzwaniem.

Zarządzanie SfB

do czasu Teamsów sprawę dało się jeszcze ogarnąć. szczęśliwie dla SfB w zasadzie nie ma specjalnie zarządzania

  • konto w hybrydzie trzeba włączyć/wyłączyć, co robi się oczywiście po stronie onprem,
  • wszelkie zarządzanie danymi o userze to de facto zapis do AD – więc też onprem

są oczywiście elementy integracji VoIP, polisy czy inne elementy usługi – i to jest rozdzielnie dla każdej strony.

  • przypisanie polis – to tam, gdzie jest konto SfB, oddzielne są polisy więc zależnie od strony hostującej, tam się te polisy definiuje i przypisuje.

hybryda SfB jest imho najtrudniejsza do zestawienia ale najmniej potem przy niej administracji i ‘ruchomych elementów’ a najtrudniejsze części to równocześnie te najrzadziej wykorzystywane czyli część integracji z VoIP, cloud PBX itp.

procedury administracyjne nie wymagają zatem specjalnych zmian.

na zakończenie

o ile hybryda tożsamości to ‘must have’ dla każdego środowiska opartego o AD, o tyle przejście do cloud-only i rezygnacja z hybrydy jest posunięciem często możliwym a w takim przypadq – sugerowanym. środowiska hybrydowe tylko pozornie są ‘zunifikowane’ – po obu stronach barykady (firewalla) są produkty w innych wersjach i choć mają symulować ‘jedną organizację’ to jest to proteza, która wprowadza sporo niejasności i komplikacji w konfiguracji i zarządzaniu. konieczność wykorzystania PowerShell do części zadań powoduje, że niektóre zadania normalnie wykonywane przez helpdesk, nagle są eskalowane do 2giej linii. przykładem mogą być procedury provisioningu użytkownika w hybrydzie Ex1o z EXO – gdzie nie ma wsparcia zakładania konta ze skrzynką online z interfejsu, a skrzynkę współdzieloną da się tylko zrobić hackując z poziomu atrybutów AD bo nawet PowerShell w tej wersji nie ma opcji ‘-Shared’ która pojawiła się w Ex13.

przejście dla tych usług na cloud-only znacznie ułatwia administrację.

eN.

Spotkania w czasie kryzysu

jest dziwnie. osobiście czuję się jakbym był częścią filmu SF o pandemii… tyle, że to się dzieje na prawdę. ponieważ pracuję w większości zdalnie, nie odczuwam tak tej kwarantanny ani paniki. zacząłem to lepiej rozumieć w momencie, kiedy zorganizowaliśmy otwarte wydarzenie dla pracowników. i o tym wydarzeniu chciałem trochę opowiedzieć w dwóch kontekstach.

TECHNICZNIE

korzystamy z Teams Live Event. max liczba odbiorców to 1oK więc nawet duża organizacja może zrobić otwarte wydarzenie dla pracowników. konfiguracja jest dość prosta. nie korzystałem z żadnych dodatkowych narzędzi tym bardziej, że wszyscy prezentujący byli w domach. TLE działa inaczej niż zwykłe Teamsy i służy tylko do broadcastowania – video i voice nadają tylko prezenterzy/producenci a uczestnicy tylko słuchają. można włączyć funkcję QnA aby mieć kontakt z uczestnikami.

cały streaming, aby był skalowalny na takie liczby idzie przez Azure Media Services. wadą jest 1o-2o sek opóźnienia dla odbiorcy końcowego (więc nie tak 1oo% live) ale to nie przeszkadza przy tej skali eventu. pomimo kłopotów jakie ostatnio występują u dostawców chmury publicznej, wydajność i działanie – bez zarzutu. oczywiście zdarzało się, że komuś domowe wifi słabo działało ale to już niezależnie od usługi. mamy okres globalnego stress testu sieci na całym świecie.

jestem bardzo pozytywnie zaskoczony tym jak TLE działa – narzędzie jest proste, może nawet trochę prymitywne, ale w 9o% scenariuszy to wystarcza, a całość jest płynna, daje możliwości przeanalizowania statystyk i wrzucenia nagrania np. na Streams.

PSYCHOLOGICZNIE

na pierwsze spotkanie dołączyło 55o osób. dwa-trzy dni później, na kolejnej edycji, ta liczba została zdublowana.TLEspotkanie prowadzone przez Chiefs, Heads, Directors itp. jednymi z najczęściej zadawanych pytań to ‘czy stracimy pracę?’ oraz ‘czy adopcja pracy zdalnej zostanie po kwarantannie?’. o ile pytanie o qlturę jest po prostu ciekawe, to ogólnie przeglądając QnA i pytania jakie zadają ludzie uświadomiły mi jak bardzo ludzie boją się – nie wirusa, ale o przyszłość, co po nim? pracując z domu, trochę jakbym miał normalnie kwarantannę. ale dla osób pracujących klasycznie, w biurze, przyzwyczajonych do przemieszczania się i ciągłego spędzania czasu wśród ludzi … to olbrzymia zmiana. pozostawienie z własnymi myślami i zatruwani wiadomościami o rosnącej liczbie zarażeń… ludzie się boją. choć szukając odrobinę pozytywnego aspektu – dobrze, że boją się o przyszłość, a nie tego co jest teraz, bo to oznacza, że jeszcze nie jest tak tragicznie, że każdy tą przyszłość widzi i nie jest to jeszcze apokalipsa (choć i takie głosy dochodzą mnie już brrrr!).

PODSUMOWUJĄC

widzę jak ważne jest ‘spotykanie się’. w różnych kontekstach. ludzie w tej trudnej chwili potrzebują pocieszenia w postaci konkretów, faktów, informacji wskazującej co będzie dalej, zbudowania wizji przyszłości. uważam, że to zacna inicjatywa i polecam wszystkim firmom/organizacjom na robienie spotkań – w mniejszych lub większych grupach. nie pozostawiać swoich pracowników samym-sobie, aby nie pogrążali się w strachu i panice.

to ważny czas dla każdego aby wyłuskać z siebie trochę mocy i podjąć inicjatywę -zarówno firmowa jak prywatnie – i organizować jakieś spotkania. być razem. szczęśliwie żyjemy w czasach w których miejsce fizycznie nie musi nas więzić i możemy spotykać się w wirtualu. hasło ‘tomorrow is today’ spadło nam na karki i trzeba wycisnąć z tego wszystko dobre co się da.

NIE PODDAWAJCIE SIĘ DEPRESJI I PANICE, sięgajcie o pomoc do znajomych i szefów, organizujcie się!

eN.