pasjonaci IT – rozmawiamy z Product Manager Identity

Michał Guzowski rozpoczął ostatnio inicjatywę dla pasjonatów IT – ot po prostu spotkać się raz na tydzień i porozmawiać na tematy związane z IT. w najbliższy wtorek do spotkania dołączy Senior Product Manager of Identity & Access Management, prosto z Redmond. I *nie będzie* to spotkanie w języq angielskim – ponieważ jest nim Polak (: można więc będzie w przystępny dla każdego sposób dowiedzieć się kilq ciekawostek, zarówno dotyczących produktów, ale również samej kariery w Microsoft…

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.