Miesiąc: grudzień 2020

Czas na tort Linuxowo Teamsowy z dodatkiem CA

Trochę przewrotnie, ale artykuł dotyczy obszaru który nie działa do końca tak, jak byśmy chcieli. Mam nadzieję komuś zaoszczędzi wpadki na projekcie, czy godzin analizy dlaczego coś się da, albo nie 😊.

Poruszę dwa scenariusze, które często realizuję w pracy z klientami dotykając Dostępu Warunkowego z Azure AD Premium. Mimo że AADP to elementy bezpieczeństwa tożsamości, ten obszar dotyczy konkretnie dostępu do danych.

Załóżmy sobie dwa proste, typowe, a nawet powiem klasyczne scenariusze w których będziemy się poruszali:

1) Organizacja modeluje reguły CA dla każdego scenariusza, urządzenia, aplikacji, sieci, itd., itp., ale… zostawia dziurę, i to jaką! Większość konfiguracji CA, które widziałem nie uwzględniała jednego przypadku – dostęp ze środowiska Linux. I o tym dalej…

2) Organizacja nie jest w powyższego przykładu i dla Linux chce także wprowadzić zasady CA. Ale jakie? A więc takie, aby dołożyć do całości MCAS i zabronić pobierania plików. Praca 100% w chmurze, żadnych danych offline – przecież nie zarządzamy tymi maszynami (w 99,9% przypadków).

No to popatrzmy o co tak naprawdę chodzi. Zacznijmy od przypadku Numer 1.

Kto zetknął się z warunkami (Conditions) w CA, wie że możemy wskazać dla jakich systemów polisy działają, dla jakich nie. A co jeśli te polisy zawsze mają wyjątek? Jak wiecie, na liście systemów nie mamy Linuxów (ale możecie o to grzecznie prosić – Feedback/UserVoice).

Dlatego też, tworząc najwymyślniejsze restrykcje, nie zrobiliśmy nic dla środowiska Linuxowego. (Oj jaka szkoda 😊). Możemy to na szczęście naprawić jedną, zgrabną polisą. W skrócie – Blokuj wszystko, jeśli platforma jest dowolną poza wskazanymi.

I to nam całkowicie załatwia sprawę, zarówno w przeglądarce, w aplikacjach, i dla wszystkich usług M365.

Och jakie proste. Szkoda tylko że większość (może i Ty) klientów u których analizowałem konfigurację CA miała taką prostą dziurkę…

Przypadek No. 2

Tutaj jest nieco trudniej. Mamy stacje Linuxowe, nie zarządzamy nimi, teoretycznie możemy prosić ludzi o korzystanie z Windows do pracy. Ale może jednak się da…

Na Linuxa mamy klienta Teams, bo o tym dzisiaj głównie mowa. Więc zbudujmy sobie klasyczną polisę CA, która jak dla No. 1 będzie działała na „wszystkie niezaznaczone” systemy i ustawmy jak dla innych urządzeń prywatnych – pracujcie, ale tylko w chmurze, w OneDrive, Sharepoint, ale bez zapisywania danych na stację (a bo może i pod KNF podlegamy i nie możemy na to pozwolić?).

Polityki CA – regulujemy czy działają dla przeglądarki, dla klienta desktop, dla innych. Czy to zadziała na Linux?

Oszczędzę wyjaśnień krok po kroku – NIE! Czemu?! Klient „Desktop” Teams dla Linux jest PRZEGLDRAKĄ!!!

Jak to? A no takto. Techniczne, klient Teams na Windows to też przeglądarka 😊.

No więc mamy stuację, przeglądarka jest przeglądarką, klient jest przeglądarką.

No to włączmy polisę, która zabrania pobierania plików. Proszę 😊

Zadziała?? NIE! MS wprost pisze, zasady MCAS i te w CA, działają tylko w klientach webowych. Więc skoro nasz Desktopowy Teams jest webowy to nie zadziała? NIE! I tu pies pogrzebany… Nie zadziała i tyle, pliki można ściągać do woli..

No i co teraz Panie Architekt? Chyba na statusie trzeba ten wątek poruszyć?

Oczywiście jest to element na który należy zwrócić uwagę, ale nie jesteśmy bez wyjścia. Przyglądając się informacjom logowania, widzimy jak wygląda string User Agent

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) MicrosoftTeams-Insiders/1.3.00.30857 Chrome/80.0.3987.163 Electron/8.5.3 Safari/537.36

MicrosoftTeams-Insiders – I to jest klucz. Jak to wykorzystać aby osiągnąć oczekiwaną konfigurację, czyli zablokować dostęp z „desktopowego” Teams, ale dopuszczając przeglądarkę (z ograniczeniem pobierania)? Nic prostszego, potrzebujemy do tego tortu 2 składników*:

polisą w MCAS zabronić dostępu dla danego User Agent,
polisą w MCAS/polisą CA zabronić pobierania plików w webowym Teams.

* – składniki można mieszać.
Wyglądało by to w MCAS w zasadach dostępu mniej więcej jak na poniższej grafice. Oczywiście polisy MCAS mogą wywołać inne akcje, jak właśnie też pobierania blokowania, czy np. ustawiania klasyfikacji AIP w przypadku pobrania pliku, ale nie o tym dzisiaj 🙂

Zapraszam także do kontaktu z nami, jeśli potrzebujesz wsparcia.

EOP – Exchange Online Protection – zestaw rozwiązań zabezpieczeń poczty dostępny w każdej (każdej!) subskrypcji O365/M365, w której mamy usługę Exchange Online.

Defender for Office 365 – (poprzednio nazywany Office 365 Advanced Threat Protection) – zestaw rozwiązań zabezpieczeń nie tylko poczty, ale także plików w usługach MS Teams i Sharepoint, dostępny w planach E5 (O365 E5, M365 E5, w dodatkach M365 E5 Security oraz jako produkt stand-alone).

Uruchamiając każdy tenant usługi Microsoft, w którym będziemy korzystali z poczty Exchange Online, należy dokonać konfiguracji, a przynajmniej przeglądu i zapoznać się z konfiguracją domyślną usługi EOP.

Uruchamiając tenant z dostępnymi licencjami Defender for Office 365, należy dokonać konfiguracji elementów zaawansowanych. Domyślnie nie są włączone czy przypisane do naszych użytkowników.

Zarówno funkcje dostępne w Defender się zmieniają, jak też zmieniają się czasami wytyczne i dobre praktyki. Jak w tym się nie pogubić, być na bieżąco z najlepszą możliwą konfiguracją, szczególnie dla narzędzi zaawansowanych? Mamy do dyspozycji 3 rozwiązania, popatrzmy co oferują.

1.  Manualny przegląd konfiguracji

Dlaczego nie jest dobry? 😊 Bo jest manualny! I nie pokazuje wszystkiego. Trzeba się „przeklikać” przez każde ustawienie, jeśli mamy kilka polityk np. dla różnych grup pracowników, trzeba to zrobić dla każdej z nich. A dodatkowo, nie wszystkie ustawienia są dostępne w GUI, część należy ustawiać przez Powershell, a jednocześnie nie mamy łatwego odniesienia do dodatkowych informacji.

Na szczęście, wszystko możemy wykonać w jednym portalu – https://protection.office.com/threatpolicy (lub dla samego EOP w portalu ECP Exchange https://outlook.office.com/ecp/).

2. ORCA

Nazwa pochodzi od „Office 365 Advanced Threat Protection Recommended Configuration Analyzer”.

Jest to narzędzie uruchamiane w PowerShell, dające w wyniku, dane wyświetlane w postaci witryny html. Pobieranie narzędzia wykonujemy poprzez Install-Module-Name ORCA, wygenerowanie raportu przez Get-ORCAReport, jednak każdorazowo przed wykonaniem raportu zalecane jest wykonanie aktualizacji modułu przez Update-Module ORCA.

Co dostajemy w rezultacie uruchomienia? Bardzo ładnie przedstawione wyniki skanu naszej konfiguracji wraz z rekomendacjami

Skanowane są ustawienia tenanta, reguł transportowych Exchange, oraz całej konfiguracji EOP z Defender.

Konfiguracja i status

Jak widać, 48 ustawień jest zgodnych z zaleceniami Microsoft, natomiast w 10 możemy coś poprawić, a dla 1 dostaniemy dodatkowe informacje. (Proszę zapamiętać – 48 – 10 – 1).

Dla ustawień, gdzie Micorosft sugeruje weryfikację, czy możliwa jest poprawa, dostaniemy zestaw wartości aktualnych, rekomendowanych, oraz łącza gdzie możemy uzyskać więcej informacji na ten temat.

Ustawienie musimy jednak odnaleźć samodzielnie, nie mamy z tego poziomu możliwości włączenia jakiejś opcji czy zmiany wartości. Ale tu uwaga, mamy rozwiązanie trzecie!

3. Analizator konfiguracji w portalu

Dostępny w portalu Protection (https://protection.office.com/threatpolicy) analizator konfiguracji jest prawie najlepszym rozwiązaniem. Dlaczego? O tym 2 słowa w podsumowaniu.

Daje nam wyniki podobne jak ORCA, jednak widać że zaleceń jest 9 nie 10 (to ten sam tenant). Dodatkowo, należy pamiętać ze Analizator pokazuje domyślnie zalecenia poziomu Standard, natomiast poniższy wynik to zalecenia ścisłe, strict.

Nie jest to „klikalne”, nie rozwinie się nam nic więcej (może w przyszłości będzie jakieś okienko wyskakiwało), więc nie jest łatwo ustalić o jakie konkretnie ustawienie chodzi albo o nim doczytać. Lecz, co jest bardzo fajnego? Jak przewiniemy ekran w prawo, możemy dane ustawienie po prostu włączyć😊

Narzędzie na pewno ma potencjał i nie odradzam go, w żadnym wypadku. W materiale video możecie zobaczyć dokładnie jak to działa.
https://youtu.be/H73d6QedCWE

Podsumowanie

Narzędzie Analizatora na pewno będzie się rozwijało i spełni moje oczekiwania w 100%. Ja jednak osobiście zostaję przy ORCA z kilku powodów:

– bezpośrednie odnośniki do Microosft Docs, gdzie można szczegółowo doczytać o danym ustawieniu, a co za tym idzie wykonujemy zmiany z głową, a nie tylko klikając. Oczywiście znając te wszystkie konfiguracje można sobie znacznie ułatwić pracę wspierając się analizatorem do wprowadzania konfiguracji,

– wylistowane są także funkcje ustawione zgodnie z rekomendacjami,

– plik raportu ORCA „odkłada” się na komputerze. Co prawda analizator ma funkcje historii co jest bardzo przydatne, jednak co plik to plik 😊. Jednocześnie, ORCA ma więcej opcji generowania raportów, np. do CosmosDB, skąd można je zaciągać np. przez PowerBI (więcej o parametryzacji wyników – https://github.com/cammurray/orca#supported-outputs )

– i na koniec – administrując wieloma tenantami można wykonywać skrypt automatycznie dla większej ilości klientów, jednocześnie składując wyniki w jednym miejscu.

Zapraszam także do kontaktu z nami, jeśli potrzebujesz wsparcia.