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.
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:
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.