Start · Rozwiązania · Inne rozwiązania

Rozwiązanie · Inne rozwiązania

O dostępie decyduje polityka: nadany w minuty, udowodniony bez arkusza kalkulacyjnego

Dostęp do aplikacji według polityki, w minuty i z dowodem

Standardowe pakiety dostępu są nadawane w ramach polityki, role wrażliwe zatwierdzają wskazane osoby, roboty zakładają konta w aplikacjach bez SCIM, a każde nadanie ma dowód i datę końcową.

Rozwiązanie działoweMicrosoft TeamsCzłowiek w pętli decyzyjnejAutomatyzacja deterministyczna
550wniosków o dostęp miesięcznie trafia do zgłoszeń w tej ilustracyjnej grupie inżynieryjnej. Sześć na dziesięć dotyczy roli, którą spisana polityka już opisuje.

Streszczenie dla zarządu

Wyzwanie

Dostęp nadaje się z interpretowanych maili, zatwierdzenia się ponagla, a audytor nie znajduje dowodów.

Co się zmienia

Zaczynamy od własnej polityki dostępu klienta i zamieniamy ją w access packages w Microsoft Entra ID Governance: pakiety takie jak „inżynier budowy.

Wartość biznesowa

Standardowy dostęp jest gotowy w minuty, bo decyduje polityka, a nie łańcuch maili.

Systemy w tle

Microsoft Entra ID oraz Microsoft Entra ID Governance; aplikacje SaaS podłączone przez SCIM; ERP

Problem biznesowy

Tożsamość i dostęp

Wnioski przychodzą w formie zdań. „Proszę dać Annie to samo, co ma Piotr” interpretuje administrator, który zna systemy, ale nigdy nie czytał polityki, bo polityka jest dokumentem, a formularz wniosku polem tekstowym. Zatwierdzenie ponagla się mailem, a gdy projekt stoi, administrator najpierw nadaje, a potem pyta.

Każda aplikacja ma własnego administratora, własną konsolę i własne wyobrażenie o tym, czym jest rola, więc jeden wniosek rozchodzi się na cztery nadania w cztery różne dni, a właściciela aplikacji rzadko ktokolwiek pyta. Nic nie zapisuje, kiedy dostęp powinien się skończyć, więc się nie kończy. Dowody mieszkają w skrzynkach pocztowych, gdzie audytorzy stwierdzają ich brak. Polityki, wniosku i nadania nigdy ze sobą nie połączono, a każdy audyt sprawdza właśnie to połączenie.

Jak to wygląda dzisiaj

  1. CzłowiekKierownik prosi service desk o „taki sam dostęp, jak ma kolega”; desk zamienia zdanie w zgłoszenie
  2. CzłowiekAdministrator przekłada zdanie na role, z pamięci
  3. OczekiwanieZgłoszenie czeka na mailowe zatwierdzenie kierownika, zwykle od dwóch do pięciu dni
  4. SystemAdministrator nadaje uprawnienia kolejno w każdej konsoli: katalog, ERP, system projektowy, serwer licencji CAD
  5. Ryzyko błęduWłaściciela aplikacji nikt nie pyta, więc kombinacje ról zakazane przez politykę pojawiają się bez niczyjej decyzji
  6. Ryzyko błęduDowód trafia do zgłoszenia, jeśli ktoś pamięta, daty końcowej nikt nie zapisuje, a próbka audytora znajduje lukę
CzłowiekOczekiwanieSystemRyzyko błędu

Dlaczego obecny proces kosztuje więcej, niż widać

Najdroższa część tego procesu nie ma własnej pozycji kosztowej.

  • Czekanie to koszt widoczny: kontroler projektu, który przez tydzień nie może księgować w ERP, to tydzień cudzej pracy.
  • Dostęp nadany bez wiedzy właściciela aplikacji po cichu łamie rozdzielenie obowiązków; konfliktu nikt nie zaprojektował i nikt go nie widzi.
  • Uprawnienia bez daty końcowej narastają, a każde nagromadzone uprawnienie to jedno więcej, z którego skorzysta wykradzione hasło.
  • Przygotowanie do audytu staje się kwartalnym projektem odtwarzania dowodów, a ustalenie wraca, bo jego przyczyna jest strukturalna.

Koszt zaniechania

Dwanaście miesięcy obsługi udziału standardowego przez ludzi≈ 123 552 €
Cztery audyty rocznie z dowodami zatwierdzeń odtwarzanymi ręcznie, 160 godzin≈ 8 320 €
Trzy lata audytowe od dziś, obie pozycje razem≈ 395 616 €

Narastanie to liczba, której ta tabela nie pokaże. Każda nowa aplikacja dokłada konsolę do rozproszonych nadań, każde zatrudnienie dokłada wniosków, a środowisko uprawnień rośnie o różnicę między nadaniami a odebraniami, co dziś oznacza niemal każde nadanie. Ustalenie z audytu wraca za każdym razem ostrzejszym tonem; po dwunastu miesiącach firma ma więcej kont z większą liczbą uprawnień i dowody, które nadal zależą od tego, kto pamiętał wkleić zatwierdzenie.

Scenariusz ilustracyjny

Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.

Organizacja

Grupa inżynieryjno-budowlana, 2 800 pracowników, około 60 aplikacji biznesowych za Microsoft Entra ID; mniej więcej 20 aplikacji SaaS podłączonych przez SCIM; ERP, system zarządzania projektami i serwer licencji CAD nie mają interfejsu do zakładania kont.

Wolumen

Około 550 wniosków o dostęp miesięcznie; sześć na dziesięć dotyczy standardowej roli, którą spisana polityka już opisuje; cztery audyty rocznie.

Obecny proces

Zgłoszenia opisowe interpretowane przez administratora, zatwierdzenie ponaglane mailem, nadania wykonywane ręcznie w każdej konsoli, dowód wklejany do zgłoszenia, gdy ktoś pamięta.

Wąskie gardło

Około 36 minut łącznej obsługi wniosku po stronie service desku, administratora, administratorów aplikacji i dokumentowania dowodów; około 40 godzin odtwarzania dowodów na każdy audyt.

Rozwiązanie

Access packages w Microsoft Entra ID Governance wykonują spisaną politykę; aplikacje SCIM zasila Microsoft Entra ID; UiPath Robots zakładają konta w pozostałych trzech; rejestr w UiPath Data Fabric przechowuje wniosek, zatwierdzenia, nadanie i datę wygaśnięcia; wyjątki trafiają do administratora w Microsoft Teams.

Potencjalny efekt

W modelowanym przypadku sześć wniosków na dziesięć jest nadawanych w ramach polityki bez niczyjej obsługi, każde nadanie ma datę końcową, a próbka audytora staje się eksportem. Całość ma charakter ilustracyjny; niczego tu nie zmierzono u klienta.

Proponowane rozwiązanie

Zaczynamy od własnej polityki dostępu klienta i zamieniamy ją w access packages w Microsoft Entra ID Governance: pakiety takie jak „inżynier budowy, standard” czy „kontroler projektu”. Każdy pakiet wymienia swoje role, wnioskujących, zatwierdzających, maksymalny czas obowiązywania i cykl przeglądu. Standardowy pakiet niskiego ryzyka jest nadawany bezpośrednio i zapisywany jako decyzja polityki; nic wrażliwego nie może zostać zakończone bez kierownika, właściciela aplikacji i, tam gdzie polityka tak stanowi, działu bezpieczeństwa. Uwaga licencyjna: entitlement management wymaga Microsoft Entra ID P2 albo Microsoft Entra ID Governance.

Aplikacje podłączone przez SCIM zasila samo Microsoft Entra ID. W przypadku pozostałych trzech zatwierdzone przypisanie generuje zdarzenie zmiany członkostwa w grupie, które uruchamia proces UiPath: robot zakłada użytkownika i rolę przez interfejs administracyjny, odczytuje wynik zwrotnie i zapisuje go, wraz z datą wygaśnięcia, w rejestrze w UiPath Data Fabric. Te same roboty odbierają dostęp po wygaśnięciu. Microsoft Teams niesie przypomnienia dla zatwierdzających, komunikat o gotowości oraz zadanie UiPath Action Center dla administratora, gdy wniosek nie pasuje do żadnego pakietu albo nadanie się nie powiedzie.

Wykorzystane funkcje natywne

Microsoft Entra ID Governance entitlement management (access packages, etapy zatwierdzania, przypisania ograniczone czasowo); automatyczne zakładanie kont użytkowników w Microsoft Entra ID (SCIM); access reviews; kolejki, wyzwalacze zdarzeniowe, magazyn poświadczeń i dziennik audytowy UiPath Orchestrator; zadania UiPath Action Center w Microsoft Teams; encje UiPath Data Fabric z audytem; konektor Microsoft Teams w UiPath Integration Service

Co budujemy

Katalog pakietów odwzorowany ze spisanej polityki; roboty zakładające, zmieniające i usuwające konta oraz role w trzech aplikacjach bez SCIM, z odczytem zwrotnym; rejestr i jego eksport dowodowy; odbieranie dostępu po wygaśnięciu; obsługę wyjątków; komunikaty w Teams

Integracje dedykowane

Zdarzenia przypisań i zmian członkostwa w grupach z Microsoft Entra ID przez oparty na Graph konektor tożsamości w UiPath Integration Service (konektor nadal nosi wcześniejszą nazwę Microsoft Azure Active Directory); ERP, system zarządzania projektami i serwer licencji CAD przez ich interfejsy administracyjne lub API

Jak działa proces po automatyzacji

  1. CzłowiekKierownik lub pracownik wybiera z katalogu access package, podając powód i czas obowiązywania
  2. AutomatyzacjaPolityka pakietu decyduje: standardowy pakiet niskiego ryzyka jest nadawany w ramach polityki; wszystko inne trafia do zatwierdzających, których polityka wskazuje
  3. CzłowiekW przypadku pakietów wrażliwych zatwierdzają kierownik, właściciel aplikacji i, gdy to wymagane, dział bezpieczeństwa; przypomnienie dociera do nich w Teams, a Microsoft Entra ID Governance zapisuje decyzję
  4. SystemAplikacje podłączone przez SCIM zasila Microsoft Entra ID; pozostałe trzy stają się pozycjami w kolejce Orchestrator
  5. AutomatyzacjaRobot zakłada konto i rolę, odczytuje wynik zwrotnie, zapisuje go w rejestrze z datą wygaśnięcia i informuje wnioskującego w Teams; po wygaśnięciu usuwa to, co założył
  6. CzłowiekNieudane nadanie albo wniosek niepasujący do żadnego pakietu staje się zadaniem Action Center w Teams dla administratora IT, który podejmuje decyzję
CzłowiekAutomatyzacjaSystem

Model współpracy człowieka z automatyzacją

Automatyzacja obsługuje

  • Przedstawienie wniosku jako wyboru spośród pakietów, a nie pola tekstowego
  • Ocenę według polityki: nadanie bezpośrednie albo wskazanie, którzy zatwierdzający muszą zdecydować
  • Zakładanie kont przez Microsoft Entra ID albo przez roboty, z odczytem zwrotnym
  • Zapis wniosku, zatwierdzeń, nadania i daty wygaśnięcia oraz odebranie dostępu, gdy ta data nadejdzie

Ludzie decydują

  • Zatwierdzenia ról wrażliwych: kierownik, właściciel aplikacji i dział bezpieczeństwa, każdy z imienia i nazwiska
  • Kto jest właścicielem każdego pakietu, co pakiet zawiera i co polityka traktuje jako niskie ryzyko
  • Wnioski niepasujące do żadnego pakietu, rozstrzygane przez administratora IT w Teams

Przed i po

PrzedPo
Czas od wniosku do działającego dostępudni, wyznaczane przez najwolniejszego zatwierdzającegominuty dla pakietów standardowych
Nadania bez wskazanego zatwierdzającegowykrywane w próbce audytowejbrak; nadania bezpośrednie zapisane jako decyzje polityki
Dowody dla 25 wylosowanych kontdni odtwarzania ze skrzynek pocztowychjeden eksport z rejestru

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

  • wnioski o access package z portalu My Access
  • zdarzenia przypisań i zmian członkostwa w grupach z Microsoft Entra ID
  • spisana polityka dostępu

Warstwa automatyzacji

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Integration Service
  • UiPath Action Center
  • UiPath Data Fabric

Systemy docelowe

  • Microsoft Entra ID oraz Microsoft Entra ID Governance
  • aplikacje SaaS podłączone przez SCIM
  • ERP
  • system zarządzania projektami
  • serwer licencji CAD

Punkty styku z człowiekiem: etapy zatwierdzania w polityce access package; zadania Action Center w Microsoft Teams; statusy i przypomnienia w Teams; eksport dowodowy

wnioski o access package z portalu My AccessUiPath OrchestratorUiPath RobotsMicrosoft Entra IDetapy zatwierdzania w polityce access package

Wykorzystane technologie

Microsoft Entra ID Governance (entitlement management)

access packages, etapy zatwierdzania, przypisania ograniczone czasowo z automatycznym odbieraniem

A
Microsoft Entra ID (automatyczne zakładanie kont użytkowników, SCIM)

zakłada, aktualizuje i usuwa konta w podłączonych aplikacjach SaaS

A
UiPath Robots + UiPath Orchestrator

zakładają i usuwają konta oraz role w trzech aplikacjach bez SCIM; kolejki, ponowienia, dziennik audytowy; poświadczenia z Azure Key Vault

A
UiPath Integration Service (konektory tożsamości i Microsoft Teams)

odbiera zdarzenia przypisań z Microsoft Entra ID; publikuje statusy i przypomnienia w Teams

A
UiPath Action Center w Microsoft Teams

zadania wyjątkowe dla administratora IT, zamykane bez opuszczania Teams

A
UiPath Data Fabric (wcześniej Data Service)

rejestr: wniosek, zatwierdzenia, czas nadania, wygaśnięcie, odebranie; eksport dowodowy

A
Apotwierdzona funkcja produktu (dokumentacja producenta)

Ilustracyjny model ekonomiczny

Ile to jest warte, policzone krok po kroku.

Model ilustracyjny
330 standardowych wniosków miesięcznie (sześć na dziesięć z 550) × 36 minut obsługi= 198 h / miesiąc
198 h × 52 € pełnego kosztu godzinowego= 10 296 € / miesiąc
× 12 miesięcy≈ 123 552 € / rok
Roczna uwolniona zdolność service desku i administratorów (ilustracyjnie)≈ 123 552 €

Polityka uwalnia tylko tę pracę, o której potrafi rozstrzygnąć, dlatego wolumen poniżej to 330, a nie 550: sześć wniosków na dziesięć, które mieszczą się w standardowym pakiecie. Trzydzieści sześć minut to łączna obsługa po stronie service desku, administratora, administratorów aplikacji i dokumentowania dowodów; 52 € za godzinę to pełny koszt specjalisty IT w Europie Środkowej. Cztery audyty rocznie ujęto w koszcie zaniechania. Każda liczba jest ilustracyjna.

Policz to na swoich danych

godzin do odzyskania miesięcznie
rocznej przepustowości do odzyskania

Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.

Korzyści biznesowe

  • Standardowy dostęp jest gotowy w minuty, bo decyduje polityka, a nie łańcuch maili
  • Ścieżka „nadano zgodnie z rozmową telefoniczną” zostaje zamknięta: rola wrażliwa nie może istnieć bez zatwierdzających wskazanych w polityce, zapisanych przy nadaniu
  • Próbka audytora staje się zapytaniem do rejestru zamiast dwóch tygodni odtwarzania, a ustalenie z audytu zostaje zamknięte
  • Każde nadanie ma datę końcową, a trzy aplikacje bez SCIM są w tym samym procesie, więc zasięg konektora nie ogranicza już kontroli

Perspektywa zarządu

  • Polityka jest egzekwowana w chwili wniosku, a nie opisana w dokumencie: zakazane kombinacje ról sprawdza się przed nadaniem, a nie po audycie
  • Dowody istnieją domyślnie, w formie, o którą pyta audytor: kto wnioskował, kto zatwierdził, kiedy i na jak długo
  • „Kto ma dostęp do czego” ma jedną odpowiedź, a od tego pytania zaczyna się każdy przegląd incydentu

Wpływ na KPI zarządu

udział wniosków nadanych w ramach politykimediana czasu od wniosku do działającego dostępunadania bez zapisanego zatwierdzającegoprzypisania po terminie wygaśnięcia nadal aktywnegodziny przygotowania do audytu na cykl

Bezpieczeństwo i nadzór

Kontrola nie jest dodatkiem.

  • Ról wrażliwych nie da się nadać poza procesem: Microsoft Entra ID Governance wymusza wskazanych zatwierdzających, a zakazane kombinacje ról są sprawdzane w chwili wniosku
  • Roboty mają wyłącznie uprawnienia do zakładania kont, na dedykowanym koncie serwisowym dla każdej aplikacji. Hasła są pobierane w czasie wykonania z Azure Key Vault przez magazyn poświadczeń Orchestrator, a każda czynność jest logowana przy swoim wniosku
  • Rejestr jest tylko dopisywalny dla wniosków, zatwierdzeń i nadań: korekta to nowy zapis, nigdy edycja
  • Przetwarzanie pozostaje w regionie EU UiPath Automation Cloud i wewnątrz Państwa tenanta Microsoft 365 w granicach EU Data Boundary; access reviews obejmują to, co pozostaje stałe

Dlaczego teraz

01

Audytorzy i ubezpieczyciele cyberryzyka przeszli od pytania „czy jest polityka” do „proszę pokazać nadanie, zatwierdzającego i datę końcową”; ostatnie ustalenie dotyczyło dowodów, a następne będzie powtórką

02

Entitlement management, polityki zatwierdzania i access reviews to standard w Microsoft Entra ID Governance, już obecny w tenancie; to, co pozostało trudne, czyli aplikacje bez interfejsu, jest zwykłą pracą robotów

03

Modelowe 10 296 € miesięcznie obsługi trwa tak długo, jak długo service desk interpretuje zdania

Role zarządcze, których to dotyczy

CIO

Dostęp staje się usługą objętą nadzorem, z katalogiem i rejestrem, zamiast kolejki interpretowanych maili

CISO

Polityka jest wykonywana w chwili wniosku; role wrażliwe mają imienne zatwierdzenia, a każde nadanie wygasa z założenia

Dyrektor IT

Administratorzy przestają ponaglać zatwierdzenia w czterech konsolach, a ekspert od ról w ERP przestaje być pojedynczym punktem awarii

Dyrektor ds. zgodności

Dowody audytowe są eksportem, a ustalenie zamyka się w następnym cyklu

Częste pytania i zastrzeżenia

Czy Microsoft Entra ID Governance nie zrobi tego samo?

Dla aplikacji podłączonych przez SCIM w dużej mierze tak. Tam, gdzie aplikacja wystawia punkt końcowy SQL, LDAP lub SCIM, mogą to objąć również lokalne konektory zakładania kont w Microsoft Entra ID, a krok robota odpada. Aplikacje bez żadnego interfejsu to te, z których nadal płyną zgłoszenia, a roboty wprowadzają je do tej samej polityki, tego samego wygaśnięcia i tego samego rejestru.

Zdefiniowanie pakietów zajmie wieczność.

W większości firm dziesięć pakietów pokrywa większość wolumenu; zaczynamy od ról stojących za kwartałem wniosków, a kolejka wyjątków pokazuje, który pakiet ma być następny.

Nadawanie bez zatwierdzenia brzmi jak mniej kontroli.

To więcej kontroli, na piśmie. Polityka stwierdza, co jest niskim ryzykiem, i te wnioski są nadawane jako zapisane decyzje polityki; wszystko inne dostaje wskazanych zatwierdzających, za każdym razem.

Kiedy to nie jest właściwe rozwiązanie

  • Mniej niż sto wniosków o dostęp miesięcznie i garść aplikacji: udokumentowana macierz ról i zdyscyplinowany service desk kosztują mniej niż licencje
  • Brak spisanej polityki dostępu i brak właściciela gotowego ją spisać; to jest pierwszy projekt
  • Trwa migracja platformy identity governance albo każda aplikacja jest już podłączona przez SCIM i pakiety istnieją; wtedy luką jest adopcja, a nie automatyzacja

Pytanie na najbliższe posiedzenie

Dostęp prawidłowy, ale bez dowodu, oblewa audyt dokładnie tak samo jak dostęp błędny: czy dla następnej próbki 25 kont ta firma potrafiłaby wskazać wnioskującego, zatwierdzającego, datę i datę końcową każdego nadania z systemu, a nie ze skrzynki pocztowej?

Podejście wdrożeniowe

Co dokładnie dostarczamy i czego potrzebujemy na start.

Dostarczamy

  • Analizę kwartału wniosków i macierzy dostępu, by znaleźć dziesięć ról stojących za większością wolumenu
  • Projekt pakietów i polityki z CISO oraz właścicielami aplikacji: zawartość, zatwierdzający, czasy obowiązywania, co uznaje się za niskie ryzyko
  • Konfigurację Microsoft Entra ID Governance oraz roboty dla trzech aplikacji bez SCIM, z odczytem zwrotnym i obsługą wyjątków
  • Rejestr, eksport dowodowy, odbieranie dostępu po wygaśnięciu, komunikaty w Teams oraz pilotaż w jednej jednostce biznesowej

Potrzebujemy od Państwa

  • Spisanej polityki dostępu albo właściciela, który ją spisze, oraz obecnej macierzy dostępu
  • Wskazanych właścicieli każdej aplikacji w zakresie oraz decyzji o licencji Microsoft Entra ID Governance
  • Kont administracyjnych dla robotów, ograniczonych do zakładania kont, oraz kwartału zgłoszeń z wnioskami

Etapy

Rozpoznanie

Wnioski, macierz, zatwierdzający w praktyce, podział na aplikacje SCIM i pozostałe

Projekt

Katalog pakietów, mapowanie polityki, etapy zatwierdzania, czasy obowiązywania, model bezpieczeństwa

Budowa

Konfiguracja Microsoft Entra ID Governance, roboty dla każdej aplikacji, rejestr, zadania w Teams

Walidacja

Historyczne wnioski odtworzone na pakietach; zakładanie kont przetestowane w systemach testowych

Uruchomienie

Jedna jednostka biznesowa z nadal otwartą ścieżką zgłoszeń, potem przełączenie service desku na katalog

Działowe. Nakład zależy od liczby aplikacji bez interfejsu, odległości między spisaną polityką a praktyką oraz od tego, czy da się wskazać właścicieli.