Sophos AI Defense: wykrywanie i kontrolowanie wykorzystania AI

Sophos AI Defense zapewnia widoczność wykorzystania aplikacji AI i kontroluje, które usługi są dozwolone, wyświetlają ostrzeżenie lub są blokowane. Płatny dodatek dla kwalifikujących się środowisk Sophos EDR, XDR i MDR jest ogólnie dostępny od 13 października 2026 r. Zarządza się nim w Sophos Fusion, a dane pochodzą z istniejących sensorów Sophos. Sama licencja, widoczny kafelek czy ukończony asystent nie dowodzą jednak kompletności zbieranych danych ani skutecznego egzekwowania reguł.

Zalecana kolejność wdrożenia to: wyjaśnić kwestie licencji i stanu Fusion, zinwentaryzować źródła danych i istniejące polityki, w kontrolowany sposób spełnić wymagania sensorów, a dopiero potem przetestować politykę o wąskim zakresie. Inspekcja treści promptów nie jest przy tym gwarantowaną obecną funkcją ochronną: komunikaty producenta są w tej kwestii sprzeczne. Zakres, na którym można bezpiecznie oprzeć planowanie według tego artykułu, obejmuje widoczność, polityki dostępu do aplikacji i raportowanie; stan zweryfikowano na 20 października 2026 r.

Czym jest Shadow AI i jaki problem rozwiązuje AI Defense

Shadow AI to wykorzystanie AI poza przewidzianymi procesami zatwierdzania i kontroli. Na przykład pracownica korzysta z dodatkowego czatu internetowego, programista instaluje asystenta kodowania albo istniejąca aplikacja otrzymuje nową funkcję AI. Usługa może być przydatna, a mimo to mieć niejasne zasady dotyczące przesyłanych dokumentów, kodu źródłowego, wykorzystywania danych do trenowania czy lokalizacji danych.

AI Defense łączy trzy pytania: jakie aplikacje AI są używane, jakie przypisano im ryzyko i jaka polityka dostępu powinna obowiązywać? Przegląd produktu wymienia przeglądarkowe modele językowe, takie jak ChatGPT, Claude.ai i Copilot, a także nowsze aplikacje do kodowania, aplikacje desktopowe i agentowe, takie jak Claude Code, Cursor i OpenClaw. Przykłady te nie gwarantują wykrywania i kontrolowania każdego wariantu, połączenia API ani aktywności na każdym urządzeniu. Decydują konkretne sensory i faktycznie zaobserwowany zakres pokrycia.

W analizach Unsanctioned oznacza, że używana aplikacja nie jest wyraźnie dozwolona przez żadną politykę. Jest to przede wszystkim status zatwierdzenia, a nie dowód obecności złośliwego oprogramowania czy wycieku danych. Z kolei dozwolona usługa nie sprawia automatycznie, że każde jej użycie jest dopuszczalne. Nadal potrzebne są zasady organizacyjne określające, które dane wolno przekazywać do danej usługi.

AI Defense nie jest też Sophos AI Assistant ani AI Search do dochodzeń XDR. Tam AI wspomaga pracę analityków. AI Defense kontroluje wykorzystanie AI w organizacji. Ani nazwa Fusion, ani dostępne funkcje Assistant nie włączają automatycznie tego dodatku.

Wcześniejsze sprawdzenie licencji, Fusion i sensorów

Przed zamówieniem i przed konfiguracją należy sprawdzić różne wymagania:

Uprawnienie do zakupu: AI Defense to płatny dodatek dla kwalifikujących się klientów Sophos EDR, XDR i MDR. Sophos wskazuje dodatkowo korzystanie z Sophos EDR Endpoint Protection jako wymaganie. Sama licencja Sophos Endpoint lub samodzielny Sophos Firewall nie wystarczają więc jako dowód uprawnienia. Konkretny zakres umowy sprawdź według artykułu Aktywowanie i sprawdzanie licencji.
Dostęp techniczny: udokumentowana konfiguracja wymaga konta Sophos Fusion zaktualizowanego do nowej platformy z Security Operations. Kontrola przejścia do Fusion rozróżnia nazwę portalu i faktyczną aktualizację produktu.
Wyjątek zakupowy dla Taegis: uprawnieni klienci Taegis mogą kupić dodatek już od momentu ogólnej dostępności, nie czekając na migrację do Fusion. Nie jest to udokumentowany wyjątek od technicznych wymagań konfiguracji. Przed wdrożeniem trzeba wyjaśnić uprawnienie, sposób udostępnienia i stan aktualizacji z odpowiednią osobą kontaktową w Sophos.
Odpowiednie sensory: asystent konfiguracji oferuje obecnie Sophos Endpoint, Sophos Firewall i Sophos Linux Server. Ogólny przegląd produktu wymienia dodatkowo DNS Protection, Protected Browser i Sophos Data Lake jako źródła danych. Tej szerszej listy elementów architektury nie wolno traktować jako identycznej listy wyboru ani potwierdzenia jednakowych możliwości egzekwowania reguł przez wszystkie komponenty.

Przed zmianami udokumentuj objętych nimi użytkowników, urządzenia i sieci, dotychczasowe wartości polityk, odpowiedzialnych administratorów oraz sposób wycofania zmian. Przesyłanie danych i odszyfrowywanie HTTPS wpływają na ochronę danych i istniejące aplikacje. Wymagają zatwierdzenia przed włączeniem, nie dopiero podczas późniejszej analizy. W pilotażu używaj zatwierdzonego użytkownika testowego na zarządzanym urządzeniu testowym; niezbędne zmiany we współdzielonych politykach nie mogą nieumyślnie objąć całej organizacji.

Przygotowanie sensorów i przeprowadzenie onboardingu

Otwórz Sophos Fusion, a następnie My Products > AI Defense > Get started. Asystent pyta o rolę administratora, doświadczenie z narzędziami AI, liczbę użytkowników i branżę. W obszarze Choose your sensors wybierz faktycznie używane sensory. Następnie potwierdź spełnienie ich wymagań. Zaznaczenie pola potwierdza przeprowadzoną przez Ciebie kontrolę; nie zastępuje dowodu skuteczności.

Sophos Endpoint

Dla sensora Endpoint Sophos dokumentuje następujące ustawienia:

W obszarze Endpoint > Policies > Data Collection and Investigation w odpowiedniej polityce włącz Upload to the Data Lake i wybierz Process Data, HTTP Data, DNS Data oraz Network Data.
W obszarze Endpoint > Policies > Threat Protection włącz SSL/TLS decryption of HTTPS websites i Block QUIC browser connections. Udokumentowane zbieranie danych wymaga tej konfiguracji; bez sprawdzenia nie należy zakładać równoważnej widoczności. Odszyfrowywanie HTTPS i blokowanie QUIC mogą wpływać na aplikacje. Dlatego testuj zmiany w kontrolowanym pilotażu i nie usuwaj zbiorczo istniejących wyjątków.
W obszarze Global Settings > Protection and Remediation > Web Settings > Web Filtering Profiles utwórz profil WWW. Przypisz go w Endpoint > Policies > Web Control do nowych lub istniejących polityk dla przewidzianych użytkowników i urządzeń. Nie wszędzie musi być stosowany ten sam profil.
W obszarze Endpoint > Policies > Application Control włącz Detect controlled applications when users access them i wybierz Block the detected application. Przed zmianą sprawdź istniejące przypisania aplikacji i ich skutki; dotychczasową konfigurację wyjaśnia artykuł Endpoint Application Control.

Przycisk Take me to settings prowadzi do odpowiedniej konfiguracji. Po wdrożeniu ponownie sprawdź faktyczne przypisanie do urządzenia testowego i dopiero wtedy potwierdź wymagania w asystencie.

Sophos Firewall i Linux Server

W przypadku Sophos Firewall przewidziane zapory muszą być objęte zarządzaniem grupami w Firewall Management > Firewalls. Zapory poza zarządzaniem grupami nie otrzymują reguł egzekwowania AI Defense. Dodatkowo wymagane jest rejestrowanie zdarzeń w każdej odpowiedniej polityce WWW: z menu z trzema kropkami przy zaporze otwórz panel administracyjny WWW, w obszarze Web wybierz daną politykę i włącz jej logowanie. Bez tego brakuje aktywności potrzebnej do wykrywania. Przed zmianą sprawdź przynależność do grup i istniejące reguły grupowe, aby onboarding nie zmienił niezauważenie innych ustawień zapory.

Dla Sophos Linux Server konfiguracja wymaga w Server > Policies > Data Collection and Investigation włączonego Upload to the Data Lake z Network Data. Nie wynika z tego, że Linux Server egzekwuje takie same kontrole dostępu do aplikacji jak Endpoint lub Firewall. Podgląd polityki pokaże później, którego produktu dotyczy konkretna reguła.

Jeśli asystent nie może zweryfikować stanu sensora, oferuje Refresh. Gdy kontrola nadal się nie powiedzie, pozwala kontynuować. Nie jest to pozytywny wynik testu sensora: rozbieżność pozostaje otwarta i wymaga zbadania przed odbiorem ochrony.

Base Policy nie jest niewiążącym szkicem

W obszarze Define your base protection tworzona jest Base Policy, jeśli jeszcze jej nie ma. Obejmuje ona wszystkie osoby w organizacji. Generative AI category default określa dla aplikacji bez własnej reguły Block, Warn lub Allow. Reguły dla konkretnych aplikacji mają pierwszeństwo przed tym ustawieniem domyślnym. Asystent pokazuje w tym celu aplikacje z ostatnich 30 dni; nie jest to informacja o ogólnym okresie przechowywania danych.

Create base policy and finish tworzy Base Policy. Ten krok można również pominąć. Jeśli Base Policy już istnieje, onboarding jej nie zmienia; Finish and take me to the policy otwiera istniejącą konfigurację. Politykę przygotowaną przez partnera należy najpierw sprawdzić, a nie zapobiegawczo zastępować. Settings > Restart onboarding umożliwia ponowne uruchomienie asystenta; nie jest to udokumentowany reset ani sposób wycofania istniejących polityk.

Na potrzeby ograniczonego testu nie twórz zapobiegawczo reguły blokującej dla całej organizacji. Najpierw ustal, jakie globalne ustawienie domyślne zostało merytorycznie zatwierdzone. Następnie utwórz politykę pilotażową z wyraźnie ograniczonym zakresem.

Bezpieczne tworzenie polityk AI Defense

W obszarze My Products > AI Defense > Policies > Create policy nadaj nowej polityce dowolnie wybraną nazwę, na przykład AI-Pilot-Zatwierdzone-Uslugi. W opisie zapisz cel, osobę odpowiedzialną i planowaną datę przeglądu. Polityka składa się z Rules i Scope.

Reguły i priorytety

Zarówno lista polityk, jak i reguły wewnątrz polityki są oceniane od góry do dołu: decyduje pierwszy pasujący wpis. Poprawna reguła umieszczona poniżej wcześniejszej pasującej reguły może więc nie mieć żadnego efektu.

Nowa dodatkowa polityka zawiera domyślnie regułę blokującą wszystkie aplikacje AI. Sophos zaleca pozostawienie jej na dole i tworzenie nad nią konkretnych zezwoleń. W pilotażu ta reguła domykająca może obejmować tylko zatwierdzony zakres testowy. Nieprzemyślana aktywacja dla wszystkich użytkowników mogłaby zablokować również dotychczas dozwolone procesy pracy.

Za pomocą Add Rule wybierz Action, a przez Add Filter — Dimension i jej Value. Obsługiwane wymiary obejmują na przykład aplikację, poziom ryzyka i oferowane w interfejsie właściwości zgodności. Dla Application wybiera się konkretne aplikacje z listy. Używaj wyłącznie faktycznie dostępnych wartości; klasyfikacja ryzyka nie zastępuje własnej oceny usługi i zakupionego wariantu umowy.

Allow: pozwala na pasujące wykorzystanie aplikacji.
Warn: użytkownicy otrzymują ostrzeżenie, ale mogą nadal korzystać z usługi. Nie zastępuje to blokady.
Block: pasujące wykorzystanie aplikacji ma zostać zablokowane przez obsługiwany produkt. Pilotaż musi wykazać, czy działa to dla planowanej ścieżki dostępu.

Dobry przykład testowy to aplikacja wyraźnie dozwolona nad regułą blokującą pozostałe aplikacje oraz druga aplikacja zatwierdzona do testu, ale bez własnego zezwolenia. Pozwala to sprawdzić zamierzoną logikę wyjątków bez używania prawdziwych poufnych treści. Nazwy aplikacji i zgodę na ich użycie określa organizacja; powyższe przykłady produktów nie są rekomendacją korzystania z nich.

Zakres i aktywacja

W obszarze Scope ogranicz politykę do przewidzianych użytkowników, grup lub sieci, na przykład przez Specific Users and Groups do istniejącej grupy testowej. Strona pokazuje, czy polityka jest stosowana do Sophos Endpoint, czy Sophos Firewall. W What will happen reguły, zakres i skutek dla produktu muszą być zgodne z zamierzeniem przed zaznaczeniem I’ve reviewed the rules and scope above.

Save zapisuje dodatkową politykę bez aktywacji. Pozwala to najpierw sprawdzić jej pozycję na liście. Natomiast Save & Enable aktywuje ją natychmiast z najwyższym priorytetem. Dlatego dla przygotowanego pilotażu zaleca się najpierw Save; przed późniejszą aktywacją należy ponownie sprawdzić pozycję i zakres. Ta udokumentowana, istotna dla bezpieczeństwa różnica między przyciskami dotyczy dodatkowo tworzonych polityk i nie może być automatycznie odnoszona do zakończenia tworzenia Base Policy.

Szablony w Browse templates > Use oraz Clone w menu z trzema kropkami mogą oszczędzić pracy. Dostarczają jednak już wypełnione reguły lub skopiowany zakres. Oba elementy trzeba przed zapisem dostosować do własnego środowiska. Istniejące polityki można edytować przez ich wpis na liście, ikonę Edit reguły wraz z Save Rule oraz Scope > Edit.

Prawidłowe odczytywanie wykorzystania, ryzyka i raportów

W obszarze My Products > AI Defense różne widoki odpowiadają na różne pytania. Zawsze najpierw wybierz odpowiedni okres za pomocą ikony kalendarza:

Dashboard: pokazuje całkowitą aktywność, zablokowane aktywności, unikatowe aplikacje i użytkowników oraz podział na Allow, Block i Warn. Do tego dochodzą najczęstsze aplikacje i użytkownicy, Shadow AI, rozkład ryzyka, przepływ wykorzystania i przebieg w czasie. Wynik stanu zabezpieczeń o maksymalnej wartości 100 uwzględnia pokrycie sensorami, dojrzałość polityk i ryzyko wykorzystania. Wysoki wynik nie gwarantuje pełnej ochrony.
AI Defense Activity: pokazuje aplikację, Actor jako urządzenie, ryzyko, sensor, czas, działanie i wywołującą je politykę. Unknown oznacza brak zarejestrowanego rozstrzygnięcia, a nie pewność, że aktywność była dozwolona. Poziomy ryzyka to Low, Medium, High i Critical. Widżety pozwalają na przykład filtrować dozwolone aktywności; Export tworzy CSV.
Inventory > Apps lub Users: pomaga sprawdzić faktycznie zaobserwowane aplikacje i użytkowników. Unsanctioned Use wskazuje brak wyraźnego zezwolenia, a Trains on Data — zarejestrowaną informację o wykorzystywaniu danych do trenowania przez dostawcę. Klasyfikacja ryzyka aplikacji uwzględnia między innymi dowody zgodności i praktyki trenowania. W statystykach wykorzystania aplikacji jedna aktywność grupuje użycie aplikacji przez urządzenie w 10-minutowym oknie. Liczba aktywności nie jest więc liczbą pojedynczych promptów. Obie listy inwentarzowe można eksportować jako CSV.
Detections: pokazuje na przykład aplikację wykrytą po raz pierwszy, ryzykowne wykorzystanie lub użycie niezatwierdzonej aplikacji. Threat score ma skalę od 0 do 10, a Severity — od Info do Critical. Filtry zawężają wyniki według Severity, Threat Score lub tytułu. Widok szczegółów zawiera opis, użytkownika lub host, którego dotyczy wykrycie, zalecane działanie i dane źródłowe w JSON. Eksport jest dostępny jako formatowane CSV, CSV lub JSON.

Szczegóły aplikacji pozwalają bliżej przeanalizować jej funkcje, podsumowanie ryzyka, zasady trenowania, zgodność i wykorzystanie danych; szczegóły aktywności podają również Data Residency. Informacje te wspierają decyzję, ale nie potwierdzają, że konkretny używany plan, konto czy indywidualna umowa powierzenia przetwarzania mają identyczne warunki.

Po zbadaniu Detection zapisz w oknie szczegółów uzasadniony status: True positive benign, True positive malicious, False positive lub Not actionable. Prawidłowo wykryte wykorzystanie może być nieszkodliwe; sam wpis Detection nie uprawnia do uznania go za udany atak.

Aby utworzyć raport, otwórz AI Defense > Reports > AI Risk Assessment Report > Generate, wybierz Report period i w razie potrzeby Download PDF. Raport łączy ryzyka aplikacji, ekspozycję na Shadow AI i porównanie ograniczania ryzyka między okresami raportowymi. Listy pięciu czołowych pozycji są wycinkami, a nie pełnym inwentarzem. To odrębny raport AI Defense, nie obietnica automatycznego dostarczania raportów MDR. Eksporty mogą zawierać dane użytkowników i urządzeń; należy przechowywać je w miejscu o ograniczonym dostępie przez uzgodniony okres.

Walidacja pilotażu i diagnozowanie problemów

Poniższa kontrola to proponowana procedura odbioru, a nie test tenanta lub test laboratoryjny przeprowadzony przez Avanet. Uzgodnij wcześniej okno testowe, urządzenie, użytkownika, dozwolone usługi i oczekiwane działania. Używaj wyłącznie zatwierdzonych, syntetycznych danych testowych, na przykład To tylko test działania bez danych firmowych. Nie przesyłaj do usługi AI danych klientów, danych dostępowych, dokumentów wewnętrznych ani prawdziwego kodu źródłowego. Sam test dostępu nie wymaga wprowadzania poufnych treści.

Zacznij od aplikacji wyraźnie dozwolonej, a następnie sprawdź przewidzianą w pilotażu regułę blokady lub ostrzeżenia. Dla każdej próby zapisz usługę, urządzenie, czas i faktyczne zachowanie po stronie użytkownika. Przy Warn kontynuacja musi być możliwa; przy Block testowana ścieżka dostępu nie może być użyteczna.
W AI Defense Activity dla tego samego okresu porównaj aplikację, Actor, sensor, Action i Policy. Widoczna blokada i odpowiadający jej wpis muszą pasować do zamierzonej próby. Sama strona blokady mogła pochodzić także z dotychczasowej reguły Web Control lub Application Control.
W Inventory sprawdź, czy pojawiają się aplikacja i oczekiwany status zatwierdzenia. Ze względu na grupowanie w okna 10-minutowe nie porównuj liczby aktywności z pojedynczymi wpisami użytkownika. W raporcie użyj tego samego okresu. Nie udokumentowano stałego opóźnienia wyświetlania; nie maskuj brakujących wpisów dowolnie dużą liczbą testów.
Przeprowadź kontrolę z użytkownikiem spoza grupy pilotażowej lub urządzeniem nieobjętym pilotażem. Jego zatwierdzone procesy pracy powinny pozostać bez zmian. Zakres rozszerzaj stopniowo dopiero po udokumentowanym odbiorze.

Aplikacja nie jest widoczna: najpierw sprawdź okres, faktycznie rejestrowaną ścieżkę dostępu i sensor. Następnie skontroluj przesyłanie danych, a w przypadku Endpoint — udokumentowane ustawienia Threat Protection, Web Control i Application Control. Przy zbieraniu danych z Firewall dodatkowo sprawdź logowanie w polityce WWW. Pusty Dashboard nie dowodzi, że nikt nie używa AI.

Aplikacja jest widoczna, ale zamierzone działanie nie działa: porównaj stan aktywacji, kolejność polityk i reguł, zakres oraz produkt wskazany w What will happen. Przy egzekwowaniu przez Firewall sprawdź również zarządzanie grupami. Nie próbuj naprawiać problemu szeroką blokadą dla całej organizacji ani wyłączaniem istniejących zabezpieczeń.

Po zmianie przestała działać aplikacja biznesowa: porównaj ostatnią zmianę z wcześniej zapisanymi wartościami i wycofaj pilotaż. Nie twórz ogólnych wyjątków TLS ani globalnych reguł Allow, aby ukryć problem.

Jeśli rozbieżność pozostaje niewyjaśniona, zbierz oczyszczone z danych wrażliwych zdarzenia, okres ze strefą czasową, sensor, urządzenie, oczekiwane działanie, faktyczne zachowanie, kolejność polityk i zakres. Te informacje pozwolą otworzyć zgłoszenie Sophos Support bez przekazywania poufnych promptów.

Wycofanie zmian i granice ochrony

Przed pilotażem zapisz dotychczasowy zestaw reguł, kolejność, zakres i zmienione polityki sensorów. Aby wycofać zmianę, przywróć zakłócającą regułę pilotażową do poprzedniego stanu przez udokumentowaną edycję polityki lub przywróć zakres pilotażu do wcześniej zatwierdzonego zakresu. Następnie ponownie sprawdź wcześniej dozwolony proces pracy i widok aktywności. Zmienioną Base Policy trzeba odtworzyć w sposób ukierunkowany na podstawie zapisanego wcześniej ustawienia domyślnego i wyjątków aplikacji. Restart onboarding jej nie resetuje.

Zmiany sensorów wolno cofnąć tylko do konkretnych poprzednich wartości, jeśli zostały wprowadzone specjalnie na potrzeby próby i nie zależą od nich inne zadania ochrony lub dochodzeń. W szczególności nie wyłączaj zbiorczo przesyłania danych do Data Lake, odszyfrowywania TLS ani Application Control. Wycofanie polityki nie usuwa automatycznie już zebranej telemetrii ani wyeksportowanych raportów. Postępowanie z nimi podlega uzgodnionemu procesowi ochrony i przechowywania danych.

Przy planowaniu istotne pozostają trzy ograniczenia:

Widoczność nie oznacza kontroli bez luk. Samą centralną polityką nie zabezpieczysz nierejestrowanego prywatnego urządzenia końcowego, innej ścieżki dostępu ani brakującego wymagania sensora. Wykrycie aplikacji nie dowodzi również kontrolowania wszystkich autonomicznych działań agenta.
Kontrola dostępu do aplikacji nie jest gwarantowaną funkcją DLP dla promptów. Komunikaty prasowe o ogólnej dostępności opisują inspekcję promptów i przesyłanych danych w czasie rzeczywistym już jako funkcję. Późniejsza informacja dla partnerów wyraźnie przypisuje inspekcję i ochronę promptów do przyszłych wydań. Dopóki konkretny zakres funkcji nie zostanie wiarygodnie potwierdzony, nie należy zakładać takiej ochrony, a zwłaszcza testować jej na prawdziwych poufnych danych.
Plan rozwoju nie jest zobowiązaniem zakupowym. Rozróżnianie prywatnych i służbowych kont AI oraz dodatkowe funkcje ochrony agentów również opisano jako elementy planu rozwoju, bez wiążącego terminu. Jeśli potrzebujesz właśnie tych funkcji, przed decyzją uzyskaj potwierdzenie dla własnego tenanta i przeprowadź osobny odbiór.

Rozsądny początek nie brzmi więc „AI jest już zabezpieczona”, lecz oznacza weryfikowalny inwentarz, świadomie zatwierdzone usługi, ograniczone polityki i powtarzalny dowód ich skuteczności.