Start · Rozwiązania · IT i systemy · Podejrzane logowania zatrzymane w minuty, nie na audycie
Rozwiązanie · IT i systemyRyzykowne logowania: kontekst, blokada, zgłoszenie i wyjaśnienie dla właściciela w kilka minut
Podejrzane logowania zatrzymane w minuty, nie na audycie
Każde oznaczone logowanie dostaje kontekst, playbook, powstrzymanie w granicach reguł, zgłoszenie i wyjaśnienie dla właściciela w Teams; analitycy rozstrzygają tylko konta chronione i spory.
Streszczenie dla zarządu
Alert pojawia się w sekundy, a powstrzymanie trwa zmianę, bo każdy krok między alertem a działaniem wykonuje człowiek.
Natywny sygnał zostaje tam, gdzie jest. Polityki ryzyka Entra ID Protection w Conditional Access pozostają pierwszą linią; my dodajemy reakcję.
Czas do powstrzymania spada ze zmian do minut dla spraw objętych playbookiem, bo nikt nie czeka na skrzynkę administratora.
Microsoft Entra ID przez Microsoft Graph; Microsoft Sentinel; ServiceNow
Problem biznesowy
Bezpieczeństwo
Wykrywanie jest w tej firmie problemem rozwiązanym; reagowanie nie. Entra ID Protection nadaje etykietę ryzyka, a Microsoft Sentinel zamienia ją w incydent, ale etykieta to nie decyzja. Decyzja wymaga kontekstu, który leży w czterech innych miejscach: czy osoba nadal jest zatrudniona, na urlopie albo w podróży (Workday); czy urządzenie jest zgodne z polityką (Intune); czy konto jest uprzywilejowane, współdzielone albo serwisowe (arkusz w zespole bezpieczeństwa); i czy istnieje już zgłoszenie (ServiceNow).
Dwuosobowy zespół zbiera to ręcznie, potem potrzebuje administratora, żeby unieważnić sesje lub wyłączyć konto, potrzebuje service desku, żeby dodzwonić się do użytkownika, a zgłoszenie pisze na końcu. Noce i weekendy należą do zewnętrznego dostawcy, który potrafi ocenić zdarzenie, ale nie ma uprawnień w tenancie, więc sobotnie wykrycie zamienia się w e‑mail, który ktoś czyta w poniedziałek.
Proces trwa, bo każde narzędzie dobrze obsługuje jeden krok, a przekazania między nimi to ludzie. Bezpieczeństwo odpowiada za decyzję, zespół tożsamości za uprawnienia, service desk za telefon, a użytkownik za historię, o którą nikt nie pytał do czwartego dnia.
Jak to wygląda dzisiaj
- SystemEntra ID Protection zgłasza wykrycie ryzyka, a Microsoft Sentinel otwiera incydent w kolejce
- OczekiwanieIncydent czeka na następną zmianę biurową; wszystko, co wykryto po piątkowym popołudniu, czeka do poniedziałku
- CzłowiekAnalityk sprawdza użytkownika w Workday, urządzenie w Intune, trzydzieści dni historii logowań, listę kont i ServiceNow, w pięciu kartach przeglądarki
- CzłowiekDecyduje „raczej w porządku” albo „raczej nie” i pisze e‑mail do administratora z prośbą o unieważnienie sesji lub wyłączenie konta
- OczekiwanieService desk dzwoni do użytkownika; nikt nie odbiera; druga próba następuje następnego dnia
- Ryzyko błęduPrawdziwe incydenty stoją w kolejce za fałszywymi alarmami ze współdzielonych urządzeń w magazynach, w kolejności wpływu
- Ryzyko błęduZgłoszenie powstaje na końcu, przełożony nigdy się nie dowiaduje, a incydent zamyka się jako „niegroźny” lub „powstrzymany” kilka dni po logowaniu
Dlaczego obecny proces kosztuje więcej, niż widać
Koszt rośnie tam, gdzie nikt na niego nie patrzy.
- Czas do powstrzymania decyduje o tym, czy przejęte konto stanie się naruszeniem, a tutaj mierzy się go zmianami: analityka, administratora i service desku.
- Godziny analityków idą na sprawdzenia, więc drodzy ludzie wykonują pracę biurową, a dwa przypadki w tygodniu, które ich potrzebują, czekają w tej samej kolejce.
- Oddzwanianie spada na service desk, który nie może niczego rozwiązać: nie widzi wykrycia, nie może niczego unieważnić i może jedynie prosić użytkownika o ponowny kontakt.
- Użytkownicy uczą się, że telefon z bezpieczeństwa jest o niczym, i przestają odbierać, a to zła lekcja przed tym jednym telefonem, który ma znaczenie.
- Nikt nie potrafi zaraportować średniego czasu do powstrzymania według typu wykrycia, więc o budżecie bezpieczeństwa dyskutuje się anegdotami, podczas gdy regulatorzy i ubezpieczyciele pytają właśnie o tę liczbę.
Koszt zaniechania
Wykrycia rosną szybciej niż liczba użytkowników. Zestawy phishingowe automatyzują password spray i zmęczenie MFA, a kolejka rośnie razem z nimi, podczas gdy czas do powstrzymania pozostaje funkcją grafiku zmian. Wiersze wyceniają wyłącznie godziny.
NIS2 liczy zegar wczesnego ostrzeżenia od momentu powzięcia wiedzy, a ta wiedza ma znacznik czasu w Sentinel niezależnie od tego, czy ktoś zadziałał w ciągu 24 godzin. Kwestionariusze ubezpieczeniowe pytają o średni czas do powstrzymania, a „nie mierzymy tego” ma własną składkę.
Przykładowa organizacja o realnych proporcjach: liczby służą do policzenia sprawy na Państwa danych, nie są wynikiem klienta.
Firma logistyczna z 6 500 użytkownikami, z których jedna trzecia to pracownicy pierwszej linii na współdzielonych skanerach i terminalach; Microsoft Entra ID P2, Microsoft Sentinel i Microsoft Intune; ServiceNow do zgłoszeń, Workday jako system kadrowy; dwuosobowy zespół bezpieczeństwa w godzinach biurowych i zewnętrzny dostawca w nocy.
Około 380 wykryć i incydentów związanych z logowaniem miesięcznie: nietypowa podróż, password spray, nieznane właściwości logowania, logowania z kont nieaktywnych od dziewięćdziesięciu dni, wyciekłe poświadczenia. Dwa na trzy dotyczą standardowych kont na zgodnych urządzeniach.
Każdy incydent jest ręcznie wzbogacany o dane kadrowe, dane urządzenia, historię logowań i zgłoszenia, powstrzymywany przez administratora proszonego e‑mailem i wyjaśniany użytkownikowi telefonicznie; zgłoszenie powstaje na końcu.
Mediana czasu od wykrycia do działania powstrzymującego to nieco ponad pięć godzin, w weekendy dłużej. 22 minuty pracy analityka na incydent idą na sprawdzenia i papierologię, zanim padnie jakakolwiek ocena.
Każdy incydent Sentinel dotyczący logowania uruchamia proces UiPath: robot wzbogaca go o kontekst, a tabela reguł wybiera playbook. Rutynowe powstrzymanie wykonuje się dla kont standardowych, w ServiceNow otwiera się zgłoszenie z materiałem dowodowym, a użytkownik odpowiada na zadanie „czy to Ty?” w Microsoft Teams. Konta chronione zawsze zatrzymują się u analityka.
W modelowanym przypadku sprawy objęte playbookiem są powstrzymywane w minuty zamiast w godziny, około dwie trzecie incydentów zamyka się bez udziału analityka, a telefony service desku ustępują zadaniu w Teams. Liczby są modelem, nie pomiarem.
Proponowane rozwiązanie
Natywny sygnał zostaje tam, gdzie jest. Polityki ryzyka Entra ID Protection w Conditional Access pozostają pierwszą linią; my dodajemy reakcję. Reguła automatyzacji w Sentinel uruchamia się przy każdym nowym incydencie dotyczącym logowania i przez niewielki playbook w Azure Logic Apps przekazuje go, wraz z identyfikatorem incydentu, do wyzwalacza API w UiPath Orchestrator.
Robot wzbogacający składa w sekundy to, co analityk składał przez dwadzieścia minut: status zatrudnienia i przełożonego z Workday, zgodność urządzenia z Intune, trzydzieści dni wzorca logowań, klasę konta i ewentualne otwarte zgłoszenie w ServiceNow. Tabela reguł, indeksowana typem wykrycia i klasą konta, wskazuje playbook. Nieaktywne konto byłego pracownika zostaje wyłączone, a jego sesje unieważnione, ze zgłoszeniem P2. Nietypowa podróż na zgodnym urządzeniu z zaliczonym uwierzytelnianiem wieloskładnikowym dostaje zgłoszenie P4 i zadanie w Microsoft Teams z pytaniem do użytkownika, czy to było jego logowanie. Password spray trafia do zespołu bezpieczeństwa, a zaatakowane konta są oznaczane jako przejęte, żeby polityka ryzyka użytkownika wymusiła zmianę hasła. Konta uprzywilejowane, kadry zarządzającej i serwisowe nigdy nie docierają do robota powstrzymującego; zatrzymują się na zadaniu analityka w UiPath Action Center, wykonywanym w Teams.
Każde działanie zapisuje się w zgłoszeniu ServiceNow i w rekordzie UiPath Data Fabric z identyfikatorem incydentu, wersją reguły, każdą akcją i odpowiedzią użytkownika. Incydent w Sentinel zamyka się z klasyfikacją, przełożony dostaje krótką kartę w Teams, a Power BI raportuje czas do powstrzymania według typu wykrycia, zmiany i klasy konta. Nie ma tu komponentu AI: o powstrzymaniu decydują reguły, które da się wyjaśnić i skontrolować.
Wykrycia ryzyka Microsoft Entra ID Protection i Conditional Access oparty na ryzyku (Entra ID P2); reguły automatyzacji Microsoft Sentinel z playbookiem Azure Logic Apps; wyzwalacze API, kolejki, magazyn poświadczeń i dziennik audytu UiPath Orchestrator; zadania UiPath Action Center jako powiadomienia z akcją w Microsoft Teams; Workflows w Microsoft Teams dla karty przełożonego; UiPath Data Fabric; Power BI
Roboty wzbogacający i powstrzymujący, tabele reguł, karty dla użytkownika i przełożonego, zadanie analityka, szablon zgłoszenia ServiceNow, rekord dowodowy i raport
Microsoft Graph z uprawnieniami aplikacji do unieważniania sesji, wyłączania kont, potwierdzania ryzyka, historii logowań i zgodności Intune; Workday i ServiceNow przez konektory UiPath Integration Service; odczyt i zamykanie incydentów Sentinel przez konektor Microsoft Azure Sentinel lub Sentinel REST API
Jak działa proces po automatyzacji
- SystemEntra ID Protection oznacza logowanie; Sentinel otwiera incydent, a jego reguła automatyzacji w ciągu minuty przekazuje go do zadania UiPath
- AutomatyzacjaRobot wzbogaca incydent: status zatrudnienia i przełożony, zgodność urządzenia, trzydzieści dni wzorca logowań, klasa konta, otwarte zgłoszenia
- AutomatyzacjaTabela reguł dopasowuje typ wykrycia i klasę konta do playbooka i zapisuje wersję reguły
- CzłowiekKonta uprzywilejowane, kadry zarządzającej i serwisowe zatrzymują się na zadaniu analityka w Action Center, rozstrzyganym w Teams, zanim cokolwiek się wykona
- AutomatyzacjaDla kont standardowych wykonuje się powstrzymanie: sesje unieważnione, konto wyłączone albo ryzyko potwierdzone, żeby Conditional Access wymusił zmianę hasła
- AutomatyzacjaW ServiceNow otwiera się zgłoszenie z materiałem dowodowym; użytkownik dostaje w Teams zadanie „czy to Ty?”, a przełożony kartę
- CzłowiekUżytkownik potwierdza albo zaprzecza; spory i incydenty niepasujące do żadnego playbooka trafiają do analityka ze wszystkim, co zebrano
- AutomatyzacjaIncydent zamyka się w Sentinel i ServiceNow z wersją reguły i wynikiem, a rekord dowodowy zasila raport
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Wzbogacenie każdego incydentu o status zatrudnienia, zgodność urządzenia, historię logowań, klasę konta i otwarte zgłoszenia
- Wybór playbooka i rutynowe powstrzymanie na kontach standardowych: unieważnienie sesji, wyłączenie konta, potwierdzenie ryzyka
- Zgłoszenie w ServiceNow, zamknięcie w Sentinel, rekord dowodowy i raport
- Zadanie potwierdzenia dla użytkownika i kartę dla przełożonego w Teams, z zapisaną odpowiedzią
Ludzie decydują
- Analitycy zatwierdzają lub odrzucają powstrzymanie na kontach uprzywilejowanych, kadry zarządzającej i serwisowych
- Analitycy badają spory i incydenty, które nie pasują do żadnego playbooka
- Bezpieczeństwo jest właścicielem tabel reguł i co miesiąc przegląda je na tle incydentów z poprzedniego miesiąca
- Service desk obsługuje użytkowników, do których Teams nie dotarł
Przed i po
Systemy i integracje
Nie dokładamy technologii, żeby architektura wyglądała poważniej. Każdy element poniżej ma w tym procesie konkretne zadanie.
Wejścia
- dzienniki logowań i wykrycia ryzyka Entra ID
- incydenty Microsoft Sentinel
- status zatrudnienia i przełożony z Workday
- zgodność urządzeń z Intune
- otwarte zgłoszenia w ServiceNow
- lista kont chronionych
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
- UiPath Data Fabric
- Azure Logic Apps (playbook Sentinel)
Systemy docelowe
- Microsoft Entra ID przez Microsoft Graph
- Microsoft Sentinel
- ServiceNow
- Power BI
Punkty styku z człowiekiem: zadania Action Center w Microsoft Teams dla analityków i użytkowników; karta przełożonego w Teams; podsumowanie na kanale bezpieczeństwa; service desk dla użytkowników nieosiągalnych w Teams
Wykorzystane technologie
wykrycia ryzyka i Conditional Access oparty na ryzyku jako pierwsza linia; potwierdzenie przejęcia konta wymusza zmianę hasła
Azamienia wykrycia ryzyka w incydenty; reguła automatyzacji i playbook Azure Logic Apps przekazują każdy z nich robotowi
Awyzwalacz API odbiera incydent; roboty wzbogacają, stosują reguły i powstrzymują; kolejki, ponowienia i audyt
Aodczytuje i zamyka incydenty, otwiera zgłoszenia, sprawdza status zatrudnienia, publikuje podsumowanie na kanale
Aunieważnianie sesji, wyłączanie kont, potwierdzanie ryzyka, historia logowań, zgodność urządzeń
Adecyzja analityka o kontach chronionych i potwierdzenie użytkownika
Akarta Adaptive Card dla przełożonego, publikowana z webhooka wywoływanego przez robota
Arekord dowodowy na incydent; czas do powstrzymania według typu wykrycia, zmiany i klasy konta
AJak to wdrażamy
Od opisu do działającego procesu
To rozwiązanie wdrażamy w ramach usługi automatyzacji procesów: najpierw mierzymy proces na danych firmy, potem budujemy, testujemy i utrzymujemy roboty.
Ilustracyjny model ekonomiczny
Ile to jest warte, policzone krok po kroku.
Praca analityka i oddzwanianie service desku to dwa strumienie wycenione poniżej i żadnego z nich nie zmierzono u klienta. Obsługa przez analityka to 22 minuty na incydent, z których uwalnia się udział objęty playbookiem: 65% w tym środowisku zdominowanym przez pierwszą linię. Oddzwanianie kosztuje desk 8 minut na incydent i zastępuje je zadanie w Teams. 63 € za godzinę to pełny koszt analityka wraz z uśrednioną stawką zewnętrznego dostawcy. 39 € za godzinę to pełny koszt service desku w Europie Środkowej. Dwa strumienie o dwóch stawkach nie mieszczą się w jednej linii kalkulatora. Opłaty za SOC, licencje i koszty naruszeń są poza modelem.
Korzyści biznesowe
- Czas do powstrzymania spada ze zmian do minut dla spraw objętych playbookiem, bo nikt nie czeka na skrzynkę administratora
- Czas analityków przesuwa się ze sprawdzeń na ocenę, jedyną rzecz, której dwuosobowy zespół nie może nikomu oddelegować
- Użytkownicy odpowiadają na zadanie w Teams w kilka sekund zamiast ignorować telefon, a odpowiedź staje się częścią zapisu
- Każdy incydent niesie ten sam materiał dowodowy w tych samych polach, więc audytor i ubezpieczyciel dostają spójny raport
- Fałszywe alarmy kosztują minuty pracy robota, więc prawdziwe incydenty wypływają szybciej w krótszej kolejce
Perspektywa zarządu
- Średni czas do powstrzymania według typu wykrycia, zmiany i klasy konta staje się liczbą, którą CISO może pokazać codziennie
- W kolejce zostają tylko sprawy wymagające oceny, więc obciążenie dwuosobowego zespołu jest przewidywalne, a zakres nocnego dostawcy jest regułą
- Tabele reguł są wersjonowane i wydawane, więc każde powstrzymanie da się przypisać do reguły, która je nakazała
- Telefony bezpieczeństwa znikają ze statystyk service desku, a przełożeni tego samego dnia dowiadują się, że konto w ich zespole zostało dotknięte i dlaczego
Wpływ na KPI zarządu
mediana czasu do powstrzymania według typu wykrycia · udział incydentów obsłużonych bez analityka · odsetek odpowiedzi użytkowników na zadanie potwierdzenia · incydenty zamknięte z kompletnym materiałem dowodowym · otwarte incydenty starsze niż jedna zmiana
Bezpieczeństwo i nadzór
Zaufanie do automatyzacji buduje się na śladzie, nie na deklaracji.
- Robot powstrzymujący działa pod jednostką usługi Entra z wyłącznie tymi uprawnieniami Graph, których wymagają jego playbooki, ograniczoną jednostkami administracyjnymi do kont standardowych; listę chronioną egzekwuje sam katalog
- Sekrety nigdy nie leżą w przepływie: robot pobiera je w czasie wykonania z Azure Key Vault przez magazyn poświadczeń Orchestrator, a dziennik audytu Orchestrator rejestruje każde zadanie i ponowienie
- Każde działanie zapisuje się z identyfikatorem incydentu, wersją reguły i wynikiem w rekordzie Data Fabric i w zgłoszeniu ServiceNow, więc każde powstrzymanie da się odtworzyć
- Tabele reguł zmieniają się wyłącznie przez przeglądnięte wydanie z imiennie wskazanym zatwierdzającym w zespole bezpieczeństwa
- Dane kadrowe ograniczają się do statusu i przełożonego. Przetwarzanie pozostaje w Państwa tenancie Microsoft 365 w granicach EU Data Boundary i w regionie EU UiPath Automation Cloud; żaden model językowy nie bierze w tym udziału
Dlaczego teraz
NIS2 uruchamia zegar wczesnego ostrzeżenia w chwili powzięcia wiedzy, a ta ma znacznik czasu w Sentinel. Reakcja, która czeka do poniedziałku, to opóźnienie podlegające zgłoszeniu, a ubezpieczyciele pytają o średni czas do powstrzymania w formularzu odnowienia polisy
Wykrywanie jest w większości środowisk Microsoft 365 E5 gotowe: Entra ID Protection i Sentinel są licencjonowane i działają. Godziny leżą w reakcji: modelowane 7 700 € miesięcznie z tabeli powyżej
Reguły automatyzacji Sentinel, wyzwalacze API Orchestrator, ograniczone uprawnienia Graph i zadania Action Center w Teams to udokumentowane funkcje; złożenie ich w całość to inżynieria, nie badania
Role zarządcze, których to dotyczy
Średni czas do powstrzymania staje się minutami dla spraw rutynowych i raportowaną liczbą dla wszystkich, według typu wykrycia i zmiany
Zespół bezpieczeństwa skaluje się wraz z wykryciami bez dodawania zmian, a service desk przestaje wykonywać telefony bezpieczeństwa, których nie może rozwiązać
Oddzwanianie znika ze statystyk desku; widzi on tylko użytkowników, do których Teams nie dotarł, z dołączonym materiałem dowodowym
Częste pytania i zastrzeżenia
Obsługuje triage. Powstrzymanie nadal wymaga kogoś z uprawnieniami w Państwa tenancie i znajomością Państwa danych kadrowych. Robot daje dostawcy zadanie i zgłoszenie zamiast e‑maila do Państwa administratora.
Konta chronione nigdy nie docierają do robota powstrzymującego; uniemożliwia to sam katalog, a trafiają one zawsze do analityka. Konta pierwszej linii na współdzielonych urządzeniach dostają zadanie potwierdzenia, nie blokadę.
Blokuje albo dodatkowo weryfikuje logowanie i tak powinno być. Nie otwiera zgłoszenia, nie sprawdza, czy osoba odeszła w zeszłym miesiącu, nie unieważnia istniejących sesji i nie informuje przełożonego; to właśnie jest praca ręczna.
Kiedy to nie jest właściwe rozwiązanie
- Brak Entra ID P2 albo Sentinel: brakuje sygnału i najpierw trzeba uporządkować licencje
- Platforma SOAR już wykonuje te playbooki; wtedy roboty pokrywają tylko systemy, do których ona nie sięga, jak HR i kolejka zgłoszeń
- Mniej niż około tysiąca użytkowników, gdzie wolumen incydentów rzadko uzasadnia playbooki, a dyżur z właściwymi uprawnieniami załatwia większość spraw
Pytanie na najbliższe posiedzenie
Gdyby napastnik zalogował się na jedno z naszych kont w sobotę rano, kiedy dowiedziałby się o tym ktoś z uprawnieniami do zablokowania go i który zapis by to udowodnił?
Podejście wdrożeniowe
Co dokładnie dostarczamy i czego potrzebujemy na start.
Dostarczamy
- Klasyfikację Państwa incydentów z ostatniego kwartału według typu wykrycia i klasy konta, z jednym projektem playbooka na typ uzgodnionym z bezpieczeństwem, HR i service deskiem
- Tabele reguł, z listą kont chronionych egzekwowaną w katalogu, a nie w regułach
- Roboty wzbogacający i powstrzymujący, playbook Logic Apps i wyzwalacz API Orchestrator, które łączą z nimi Sentinel
- Karty dla użytkownika i przełożonego, zadanie analityka, szablon zgłoszenia ServiceNow, rekord dowodowy i raport Power BI
- Kilka tygodni pracy w trybie „tylko rekomenduj”, żeby analitycy widzieli, co robot by zrobił, zanim to zrobi
Potrzebujemy od Państwa
- Wdrożonych Entra ID P2 i Sentinel oraz eksportu incydentów z ostatniego kwartału z usuniętymi nazwiskami
- Zasilenia statusem zatrudnienia i przełożonym z Workday, ograniczonego do tych dwóch pól
- Listy kont chronionych i właściciela tabel reguł w zespole bezpieczeństwa
- Jednostki usługi (service principal) dla robota powstrzymującego, ograniczonej jednostkami administracyjnymi do kont standardowych
Etapy
Rozpoznanie
Klasyfikacja incydentów z ostatniego kwartału; uzgodnione typy wykryć, klasy kont i lista chroniona
Projekt
Tabele reguł, playbooki, szablony zgłoszeń, karty, model bezpieczeństwa i uprawnienia Graph
Budowa
Roboty wzbogacający i powstrzymujący, przekazanie z Sentinel, zadania i karty w Teams, rekord dowodowy, raport
Tryb „tylko rekomenduj”
Każdy playbook proponuje, ale nie działa; analitycy przez kilka tygodni poprawiają reguły
Uruchomienie bezobsługowe
Rutynowe powstrzymanie na kontach standardowych działa bez nadzoru; konta chronione pozostają za analitykiem
Skalowanie
Nocny dostawca pracuje na tych samych kartach; nowe typy wykryć stają się playbookami
Działowe. O nakładzie decyduje liczba utrzymywanych typów wykryć, jakość zasilenia kadrowego i inwentarza kont oraz systemy poza ServiceNow, które muszą nieść zgłoszenie.
Wykrycie zajęło jedenaście sekund. Powstrzymanie czekało do poniedziałku.
Prosimy o cztery tygodnie wykryć ryzyka z Entra ID z usuniętymi nazwiskami. Odsyłamy macierz playbooków: każdy typ wykrycia przypisany do automatycznej pierwszej reakcji i punktu, w którym decyduje człowiek.
Zmapujmy cztery tygodnie Państwa wykryćTen sam problem ma zwykle sąsiedni proces
Konflikty uprawnień znajduje raz w roku audytor. Najstarszy z nich ma wtedy dwanaście miesięcy.
Zobacz rozwiązanie IT i systemyReset hasła w dwie minuty, bez zgłoszeniaNajczęstsze zgłoszenie na desku wciąż wymaga telefonu, trzech konsol i kontroli tożsamości, której nikt nie zapisuje.
Zobacz rozwiązanie IT i systemyUprawnienia administracyjne tylko na czas zadaniaUprawnienie nadane na cztery godziny zostaje na lata, w systemach, które nie potrafią go wygasić.
Zobacz rozwiązanie