Kontrola aplikacji w firmie – blokuj nieautoryzowane oprogramowanie

Dlaczego kontrola aplikacji chroni firmy MŚP

Większość incydentów ransomware i wycieków danych w firmach MŚP zaczyna się od jednego punktu: niezaufanego oprogramowania uruchomionego na firmowym komputerze. Może to być darmowy konwerter PDF pobrany przez pracownika, piracka wtyczka do przeglądarki czy złośliwy instalator dostarczony przez phishing. Bez kontroli aplikacji każdy użytkownik może uruchomić praktycznie dowolny plik wykonywalny.

Kontrola aplikacji (ang. application control lub application whitelisting) odwraca domyślną logikę bezpieczeństwa: zamiast blokować znane zagrożenia tak jak robi to antywirus, definiujesz listę dozwolonych programów i blokujesz wszystko inne. To jeden z najskuteczniejszych mechanizmów obronnych, rekomendowanych przez NIST, CIS Controls i wymaganych przez wiele polis cyberubezpieczeń.

• Ochrona przed ransomware – złośliwe oprogramowanie nie uruchomi się, jeśli nie figuruje na liście dozwolonych aplikacji.
• Eliminacja shadow IT – pracownicy nie zainstalują niezatwierdzonego oprogramowania bez wiedzy działu IT.
• Zgodność z regulacjami – wymagana m.in. przez ISO 27001, NIS2 i coraz częściej przez warunki umów ubezpieczeniowych.
• Redukcja powierzchni ataku – mniej uruchomionych procesów oznacza mniejsze ryzyko exploitowania luk w oprogramowaniu.

W środowisku Windows firmy mają do dyspozycji dwa główne narzędzia: starszy AppLocker oraz nowszy Windows Defender Application Control (WDAC). Oba działają na poziomie systemu operacyjnego i mogą być wdrożone przez zasady grupy (GPO) lub Microsoft Intune.

AppLocker – sprawdzone narzędzie wbudowane w Windows

AppLocker to mechanizm kontroli aplikacji dostępny od systemów Windows 7 i Server 2008 R2, wbudowany w edycje Enterprise oraz Education. Pozwala tworzyć reguły kontrolujące, które pliki mogą być uruchamiane przez użytkowników lub grupy użytkowników.

AppLocker obsługuje pięć typów kolekcji reguł:

• Pliki wykonywalne (.exe, .com) – kontrola standardowych aplikacji desktopowych.
• Skrypty (.ps1, .bat, .vbs, .js) – blokowanie nieautoryzowanych skryptów PowerShell i Windows Script Host.
• Instalatory Windows (.msi, .msp) – kontrola uprawnień do instalacji oprogramowania przez użytkowników.
• Biblioteki DLL – zaawansowana ochrona przed atakami dll-hijacking (domyślnie wyłączona, wymaga ostrożności przy włączaniu).
• Aplikacje pakowane (AppX/MSIX) – kontrola aplikacji instalowanych ze Sklepu Microsoft.

Każda reguła może być oparta na jednym z trzech kryteriów:

1. Wydawca (Publisher) – najlepsza opcja dla standardowych aplikacji: zezwala na programy podpisane przez konkretnego producenta, np. Microsoft lub Adobe. Reguła pozostaje ważna nawet po aktualizacji oprogramowania do nowej wersji.
2. Ścieżka (Path) – zezwolenie na uruchamianie plików z określonego folderu, np. C:\Program Files\. Łatwa w konfiguracji, ale podatna na obejście przez skopiowanie pliku do dozwolonej lokalizacji.
3. Skrót pliku (Hash) – najdokładniejsza, lecz wymaga aktualizacji reguł przy każdej nowej wersji chronionego oprogramowania.

Ważne ograniczenie: AppLocker działa wyłącznie w przestrzeni użytkownika i może zostać ominięty przez zaawansowane techniki, takie jak Regsvr32 czy MSHTA. Microsoft traktuje go jako narzędzie uzupełniające, a nie jedyną linię obrony.

WDAC – nowoczesna kontrola aplikacji dla Windows 10 i 11

Windows Defender Application Control (WDAC), znany wcześniej jako Device Guard, to nowsza i znacznie trudniejsza do obejścia technologia kontroli aplikacji. Działa na poziomie jądra systemu operacyjnego (kernel-level) i jest dostępna we wszystkich edycjach systemu Windows 10/11 oraz Windows Server 2016+, bez wymogu licencji Enterprise.

Kluczowe różnice w stosunku do AppLockera:

• Ochrona na poziomie jądra – trudniejsza do ominięcia nawet przez atakujących posiadających uprawnienia administratora lokalnego.
• Dostępna we wszystkich edycjach Windows 10/11 – działa na licencjach Pro, co czyni ją odpowiednią dla większości firm MŚP bez konieczności dokupowania droższych licencji.
• Polityki w formacie XML – elastyczne, wersjonowalne i dobrze integrujące się z Intune oraz procesami zarządzania konfiguracją.
• Wsparcie dla Intelligent Security Graph – opcjonalna integracja z globalną reputacją plików Microsoftu, która automatycznie zezwala na znane, bezpieczne oprogramowanie.
• Wiele aktywnych polityk jednocześnie – od Windows 11 można stosować kilka polityk WDAC równocześnie, co ułatwia zarządzanie wyjątkami dla różnych grup użytkowników.

WDAC nie posiada dedykowanego interfejsu graficznego – polityki tworzy się za pomocą modułu PowerShell ConfigCI lub bezpośrednio przez Microsoft Intune. Wymaga to nieco więcej pracy technicznej niż AppLocker, ale efektem jest znacznie silniejsza i trudniejsza do obejścia ochrona.

Microsoft rekomenduje stopniowe przejście z AppLockera na WDAC. Oba mechanizmy mogą działać równocześnie, przy czym WDAC ma pierwszeństwo w przypadku konfliktu reguł dotyczących tego samego pliku.

Konfiguracja AppLockera przez GPO – krok po kroku

Poniżej przedstawiamy minimalną konfigurację AppLockera wdrażaną przez zasady grupy, odpowiednią jako punkt startowy dla firm posiadających Active Directory i licencje Windows Enterprise lub Education.

1. Utwórz nowy obiekt GPO i połącz go z jednostką organizacyjną (OU) zawierającą komputery pracowników. Nie stosuj polityki bezpośrednio do kontrolerów domeny.
2. Przejdź do ustawień AppLockera w edytorze GPO: Konfiguracja komputera → Ustawienia systemu Windows → Ustawienia zabezpieczeń → Zasady kontroli aplikacji → AppLocker.
3. Włącz usługę Application Identity: bez tej usługi AppLocker nie działa. W sekcji usług systemowych GPO ustaw usługę Application Identity (AppIDSvc) na tryb Automatyczny.
4. Uruchom tryb audytu jako pierwszy krok: kliknij prawym przyciskiem myszy pozycję Pliki wykonywalne i wybierz Właściwości. Ustaw tryb Tylko inspekcja. Przez 2–4 tygodnie obserwuj logi w Podglądzie zdarzeń pod ścieżką: Dzienniki aplikacji i usług → Microsoft → Windows → AppLocker.
5. Wygeneruj domyślne reguły: kliknij prawym przyciskiem myszy Pliki wykonywalne i wybierz opcję Utwórz reguły domyślne. Generuje to reguły zezwalające na uruchamianie ze ścieżek systemowych oraz przez administratorów lokalnych.
6. Dodaj reguły dla aplikacji firmowych: użyj kreatora reguł opartych na Wydawcy dla kluczowych aplikacji – Microsoft 365, przeglądarki, Adobe Acrobat. Zainstaluj oprogramowanie na stacji referencyjnej i pozwól kreatorowi automatycznie wygenerować reguły na podstawie podpisów cyfrowych producenta.
7. Włącz egzekwowanie: po analizie logów audytowych i uzupełnieniu brakujących reguł zmień tryb na Wymuszaj reguły. Wdróż zmiany najpierw na grupie pilotażowej liczącej 5–10 osób z różnych działów.

Przydatne identyfikatory zdarzeń w Podglądzie zdarzeń: 8003 – aplikacja zablokowana, 8002 – aplikacja dozwolona w trybie audytu, 8006 – skrypt zablokowany, 8007 – skrypt dozwolony w trybie audytu.

Wdrożenie WDAC przez Microsoft Intune – krok po kroku

Jeśli firma zarządza urządzeniami przez Microsoft Intune, WDAC można wdrożyć bez Active Directory i bez infrastruktury GPO. Oto kolejne kroki:

1. Stwórz bazową politykę w PowerShell na stacji administracyjnej z uprawnieniami administratora:
   New-CIPolicy -FilePath C:\WDAC\BasePolicy.xml -Level Publisher -Fallback Hash -UserPEs
   Polecenie analizuje zainstalowane aplikacje i tworzy politykę opartą na podpisach cyfrowych wydawców.
2. Włącz tryb audytu w wygenerowanym pliku XML: otwórz go w edytorze tekstowym i w sekcji Rules dodaj opcję Enabled:Audit Mode. Polityka będzie logować potencjalne blokady zamiast je faktycznie egzekwować – jest to niezbędne na etapie testów.
3. Konwertuj politykę XML do formatu binarnego wymaganego przez system:
   ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\BasePolicy.xml -BinaryFilePath C:\WDAC\BasePolicy.bin
4. Prześlij politykę do Intune: w portalu Microsoft Intune przejdź do sekcji Zabezpieczenia punktu końcowego → Redukcja powierzchni ataku, utwórz nową politykę dla platformy Windows 10 i nowsze, a następnie prześlij plik .bin przez profil niestandardowych ustawień OMA-URI.
5. Przypisz politykę do grupy pilotażowej i monitoruj zdarzenia przez Podgląd zdarzeń lub raporty Intune przez co najmniej 2 tygodnie. Szukaj zdarzeń o ID 3076 (tryb audytu) i 3077 (zablokowane).
6. Po pomyślnej weryfikacji usuń opcję trybu audytu z pliku XML, ponownie przekonwertuj go do formatu .bin i zaktualizuj politykę w Intune, stopniowo rozszerzając przypisanie na kolejne grupy urządzeń.

Microsoft udostępnia gotowe przykładowe polityki WDAC w publicznym repozytorium WDAC-Toolkit, które można pobrać i dostosować do indywidualnych potrzeb firmy bez konieczności budowania polityk od zera.

Najlepsze praktyki i jak unikać typowych błędów

Wdrożenie kontroli aplikacji może zakończyć się paraliżem produkcyjnym, jeśli zostanie przeprowadzone zbyt pochopnie. Poniżej zebraliśmy zasady, których przestrzeganie znacząco zwiększa szanse na sukces:

• Zawsze zacznij od trybu audytu – co najmniej 2–4 tygodnie obserwacji pozwolą zidentyfikować wszystkie aplikacje używane w firmie, w tym te zapomniane lub uruchamiane sporadycznie przez pojedynczych pracowników.
• Pilotaż przed pełnym wdrożeniem – wybierz grupę 5–10 użytkowników z różnych działów. Błędy w regułach nie sparaliżują całej firmy, a pilotażowi użytkownicy sami często zgłaszają brakujące aplikacje.
• Nie pomijaj skryptów – ataki ransomware bardzo często wykorzystują PowerShell, VBScript lub pliki batch. Skonfiguruj reguły dla plików .ps1, .bat i .vbs – nie tylko dla plików wykonywalnych.
• Uważaj z regułami ścieżkowymi dla folderów zapisu użytkownika – reguła zezwalająca na uruchamianie czegokolwiek z folderu Downloads lub Temp praktycznie niweluje całą ochronę. Ogranicz reguły ścieżkowe wyłącznie do folderów systemowych.
• Synchronizuj z procesem zarządzania zmianą – każde wdrożenie nowego oprogramowania powinno automatycznie wyzwalać aktualizację reguł kontroli aplikacji. Brak tego procesu prowadzi do narastającego chaosu wyjątków.
• Regularnie przeglądaj logi blokad – ustaw alert przy dużej liczbie zablokowanych uruchomień. Może to sygnalizować próbę ataku lub po prostu brakującą regułę dla nowej wersji aplikacji.
• Nie włączaj reguł DLL bez gruntownych testów – reguły dla bibliotek DLL w AppLockerze generują liczne fałszywe alarmy i mogą uniemożliwić poprawne działanie systemu Windows. Włącz je dopiero po wyczerpującym audycie środowiska.

Pamiętaj, że kontrola aplikacji to nie jednorazowe wdrożenie, lecz ciągły proces wymagający utrzymania. Nowe oprogramowanie, aktualizacje i zmiany organizacyjne wymagają regularnej weryfikacji polityk – zalecamy formalny przegląd co najmniej raz na kwartał.