Służbowy komputer mniej bezpieczny niż osobisty? To całkiem możliwe

Wiele miejsc, w których Microsoft SBS byłby naturalnym środowiskiem, polegało na zbiorze "wolnostojących", ręcznie zarządzanych komputerów. Bez centralnego uwierzytelniania, bez kontroli oprogramowania na końcówkach, zbierania logów, aktualizacji antywirusa... Nie wspominając o zautomatyzowanych reinstalacjach i aktywacji systemu. Wszystkie te operacje przypadają Panu Jankowi z pendrivem (niegdyś jeszcze z klaserem lekko porysowanych płyt).

Tymczasem wdrożenia SBS pozwalały uniknąć tego koszmaru: katalog domowy był na serwerze, popsuty system reinstalowało się automatycznie, wypychając go w nocy po sieci, badanie logów sprawiało, że od razu znaleźć podejrzaną aktywność, a komputerami zarządzało się "jak jedną fabryką", a nie wszystkimi jednocześnie. Oszczędność czasu, będąca rezultatem niezajmowania się indywidualnie każdym komputerem, dawała administratorom szansę na dokładniejsze zajmowanie się siecią jako całością.

Dlatego poza wersjami Enterprise oraz kontrolerami dla wielkich firm, Microsoft zawsze oferował "mniejszy serwer", w postaci SBS (kiedyś BackOffice). Po ostatniej zmianie nazwy z klasycznej na sensowną, SBS zaczął nazywać się Server Essentials. Jest to tańsza wersja Windows Server, bez możliwości dodawania licencji na stacje, ograniczona do 25 pracowników.

Rok pracy zdalnej nadwyrężył infrastrukturę IT małych firm do takiego stopnia, że niektóre zaczynają się rozglądać za opcjami migracji np. z wersji 2012 R2 Essentials na coś nowszego. Podczas owych poszukiwań prędko uda się zauważyć, że najnowsza wersja Essentials, czyli Windows Server 2019, nie oferuje żadnych składników charakterystycznych dla klasycznego SBS. Innymi słowy, nie różni się niczym od zwykłego 2019, poza ograniczeniem dla ilości RAM-u i liczby użytkowników.

Nie jest to szczególnie nowe odkrycie. 2019 jest obecny na rynku już 2.5 roku. Ciekawsze jest co innego. Nadchodząca wersja Windows Server 2022 wydaje się nie oferować wersji Essentials wśród dostępnych wariantów. Microsoft sugeruje migrację na usługę Microsoft 365, która w ogóle nie zawiera kontrolera domeny. Wszystko odbywa się w chmurze. Ale... jak to?

Administratorzy Active Directory dobrze wiedzą, że przy całym tym gadaniu "o chmurze i Azurze", nie istnieje coś takiego, jak chmurowy kontroler domeny. Nie da się "dołączyć stacji roboczej do domeny w chmurze", bo po prostu koncepcja Azure Active Directory polega na czymś innym. Przez lata, zarządzanie końcówkami, Zasady Grupy i dystrybucja oprogramowania odbywały się w on-premowej domenie: gdzieś w firmie stał Windows Server z AD, a służbowe komputery były zdżojnowane, uniemożliwiając pracownikom samodzielne zarządzanie.

I właśnie to zaczyna się zmieniać. Microsoft mocno zniechęca do instalowania w małych firmach AD, sugerując zamiast tego wdrożenia chmurowe. Zamiast dodawać komputer do lokalnej domeny, stosując domenowe konto administracyjne, użytkownik-posiadacz komputera, dodaje w panelu "Uzyskaj dostęp do miejsca pracy lub nauki" swoje konto w usłudze Microsoft 365, którą wykupiła firma.

Teraz uwaga: to nie jest konto administracyjne! To żaden "administrator domeny", nie loguje się tu firmowy Dział IT, a dodawane konto to zwyczajne konto użytkownika dla pracownika. Jeżeli jest on uprawniony do dodawania się do M365, po zalogowaniu na komputer spłynie Office, Edge zacznie automatycznie logować do wszystkich usług chmurowych w ramach firmy, a komputer zostanie przekonfigurowany.

W jaki sposób takie "chmurowe" i mocno oparte o przeglądarkę internetową podejście jest bezpieczeniejsze od klasycznego? Przecież nie ma tu kontroli nad oprogramowaniem, zbierania logów, ochrona antywirusowa to jedynie podstawowa konfiguracja Defendera... Chyba o wiele łatwiej na takiej stacji uruchomić ransomware?

To prawda. Ale zarządzanie ryzykiem uczy nas, że zagrożenie związane z ransomware nie polega na tym, czy ktoś je uruchomi, tylko co się stanie, gdy już się to wydarzy. A w przypadku polityki BYOD (bring-your-own-device) wydarzy się mniej niż gdy złośliwe oprogramowanie zostanie uruchomione w domenie.

Dokonajmy porównania. Wymaga ono, naturalnie, zignorowania częstego, acz błędnego i nierealistycznego hasła "w dobrze zarządzanych sieciach to użytkownicy w ogóle nie mogą uruchamiać żadnych EXE!". Gdy już pogodzimy się w duchu, że owa genialna uwaga nierzadko nie mapuje się na rzeczywistość, o wiele łatwiej będzie ocenić co się dzieje, gdy komputer w sieci domenowej uruchomi ransomware.

Jeżeli miało to miejsce, oznacza to że antywirus go nie zauważył. Gdy mamy do czynienia z odpowiednio cwanym szkodnikiem, uniknie on wykrycia przez SIEM wskutek odkrywczych metod forkowania i zdobywania uprawnień (reguły sigma są zawsze od krok za przestępcami!). Poważne zagrożenia, zanim rozpoczną szyfrowanie plików, dokonują dwóch rzeczy: ruchu poziomego oraz prób zrzucania poświadczeń. Dzięki temu propagują się "wzdłuż" (na kolejne stacje robocze) oraz "wszerz" (logując do kolejnych usług, do których poznano hasła).

Odpowiednio długa podróż po sieci czasem może zaowocować zrzuceniem poświadczeń dla administratora domeny i przejęciem NTDS.DIT, wtedy firma jest całkowice pwnd, można ją straszyć wyciekiem stanu usługi katalogowej, a pliki zaszyfrować. W dodatku, jeżeli niczym opryszczka, uda się pozostać w sieci po odbudowaniu domeny, warto sprawdzić, czy przypadkiem dalej nie pasują stare hasła - i nie zacząć zabawy od nowa.

Co się dzieje, gdy uruchomimy ransomware na prywatnym komputerze dołączonym do Azure AD w ramach Microsoft 365? Na pewno odpada ruch poziomy w ramach sieci lokalnej (a przynajmniej firmowej sieci lokalnej!). Przeglądarka nie musi trzymać hasła do Microsoft 365... ale nawet, jeżeli jest w niej zapisane, to próba kradzieży i użycia go skończy się powiadomieniem na telefonie w ramach dwuskładnikowego uwierzytelniania. Poszkodowany pracownik odrzuca takie powiadomienie, administrator resetuje mu hasło i próba szturmowania firmy dobiega końca.

Wszelkie hasła ukradzione z przeglądarki wywołają alerty 2FA. Możliwa jest też kradzież całej sesji, czyli podpięcie kradzionego katalogu AppData do komputera złodzieja, ale Microsoft 365 dba o unikatowość, a nie tylko poprawność sesji, więc prędko uda się to zablokować (polecam sprawdzić, jak na takie zachowanie reaguje np. Facebook!).

Co z szyfrowaniem plików? Cóż, jeżeli nie są akurat otwierane bezpośrednio z chmury via OneDrive, obsługujący kopie zapasowe i historię zmian, to Kontrolowany Dostęp Do Folderu (uruchamiany z M365) powinien temu zapobiec. Jeżeli tego nie zrobi, to i tak ucierpią tylko lokalne kopie plików, a nie materiały firmowe. Przy okazji, M365 uruchamia także Redukcję Powierzchni Ataków, co wyłącza możliwość forkowania się ze złośliwych makr do PowerShella. Jest to główna dziś metoda uruchamiania złośliwego kodu.

Microsoft 365 wymaga aktualnego Windows 10. Kolejne wersje "Dziesiątki" dbają o to, by wszystkie stacje miały wspólny minimalny poziom zabezpieczeń, którego nie da się obniżyć (security baseline). Intune tym bardziej zadba o to, gdy nie gmerać w Defenderze.

To wszystko jest znacznie mniejsza skala szkód w porównaniu z klasycznym Active Directory. I dla jasności: tu nie chodzi tylko o rozwiązania Microsoftu. W ten sam sposób zachowują się usługi Google dla firm. Zarządzalna przeglądarka Chrome, pliki wyłącznie w chmurze Google Docs oraz dwuskładnikowe uwierzytelnianie sprawiają, że nawet praca na kradzionym systemie pełnym keyloggerów może się skończyć "tylko" wyciekiem danych, ale nie zaszyfrowaniem ich i odcięciem firmy.

Active Directory jest niedoścignionym wzorem i przykładem geniuszu projektowego. Okazuje się jednak, że nadaje się do zarządzania biurem pełnym komputerów stacjonarnych bez opcji pracy z domu, istniejącym w świecie bez skomercjalizowanego czarnego rynku wirusów, szpiegów i porywaczy. Przy obecnej specyfice pracy dostarcza on unikatowe słabości i zwiększa ryzyko, nierównoważone już przez zalety w postaci szczegółowego, centralnego zarządzania przez GPO.

"Polski small business" pełen samodzielnych komputerów i bez działu IT okazuje się dziś mniej podatny na zagrożenia, z którymi muszą dziś walczyć wielkie firmy. Ucieczka w chmurę będzie więc postępować, "zjadając" nie tylko takie produkty, jak Windows Server Essentials, ale także (stopniowo) wiele klasycznych wdrożeń Active Directory.