Start · Rozwiązania · Inne rozwiązania

Rozwiązanie · Inne rozwiązania

Wniosek w Teams, zgoda właściciela, dostęp na godziny, odebranie przez harmonogram

Uprawnienia administracyjne tylko na czas zadania

Dostęp uprzywilejowany jest zgłaszany z powodem i czasem trwania, zatwierdzany przez właściciela systemu, nadawany przez Privileged Identity Management lub robota i odbierany po upływie czasu.

Rozwiązanie działoweMicrosoft TeamsCzłowiek w pętli decyzyjnejAutomatyzacja deterministyczna
240potrzeby dostępu uprzywilejowanego pojawiają się co miesiąc w tej ilustracyjnej firmie płatniczej. Każdą nadaje człowiek, a nie odbiera nikt.

Streszczenie dla zarządu

Wyzwanie

Uprawnienie nadane na cztery godziny zostaje na lata, w systemach, które nie potrafią go wygasić.

Co się zmienia

Projekt zaczyna się od podziału środowiska na to, czym Microsoft już zarządza, i na resztę, bo obie części wymagają innej mechaniki.

Wartość biznesowa

Populacja stałych administratorów kurczy się do ról, które muszą być stałe, bo cała reszta wygasa sama.

Systemy w tle

role Entra i Azure przez Privileged Identity Management; klastry SQL Server; hosty Linux

Problem biznesowy

Dostęp uprzywilejowany

Uprawnienie nadaje się na zadanie, a zostaje na całą karierę. Inżynier potrzebuje odczytu z produkcyjnej bazy danych podczas incydentu, pisze na Teams do inżyniera platformy i zostaje dodany do grupy, roli bazodanowej albo subskrypcji. Nadanie zajmuje cztery minuty, a zamiar późniejszego odebrania jest szczery. Odebranie jest jednak przerwaniem pracy, za którym nie stoi żaden wnioskodawca, i konkuruje z zadaniami, na które ktoś czeka, więc to „później” rzadko nadchodzi.

Narasta w ten sposób populacja, której nikt nie zaplanował. Arkusz stałych administratorów prowadzony jest ręcznie i recertyfikowany raz na kwartał na spotkaniu, które potwierdza stan zastany, bo nikt na sali nie ma danych o faktycznym użyciu, którymi mógłby go podważyć. Odpowiedzialność jest rozmyta: zespół platformy nadaje, bezpieczeństwo się martwi, a żaden wskazany właściciel nie odpowiada za to, kto co posiada.

Poza platformą tożsamości luka się pogłębia. Role w Entra i Azure można uczynić kwalifikowanymi zamiast stałych. Lokalny klaster SQL Server, flota maszyn Linux, urządzenie sieciowe czy własny magazyn użytkowników ERP już nie. Każdy ma swój sposób nadawania i żaden nie ma sposobu wygaszania, więc wygaśnięcie trzeba zbudować, a nie włączyć. Domyka to dostęp awaryjny. Opiera się on na współdzielonych poświadczeniach ze skarbca, którego nazwę znają wszyscy, przez co najbardziej wrażliwe działania w całym środowisku są najtrudniejsze do przypisania.

Jak to wygląda dzisiaj

Tak wygląda dziś droga wniosku o uprawnienie uprzywilejowane w większości zespołów infrastruktury.

  1. CzłowiekInżynier pisze na Teams do jednego z czterech inżynierów platformy: odczyt z produkcyjnej bazy danych, numer incydentu, potrzebne teraz
  2. CzłowiekInżynier platformy dodaje konto do grupy, roli bazodanowej albo subskrypcji i wraca do własnej pracy
  3. Ryzyko błęduNigdzie nie zapisuje się czasu zakończenia, bo większość tych systemów nie ma pola, w którym można go zapisać
  4. OczekiwanieOdebranie czeka, aż ktoś sobie o nim przypomni, a proszący nie ma powodu, żeby przypominać
  5. SystemArkusz stałych administratorów uzupełnia się później, z pamięci, kiedy jest na to czas
  6. OczekiwanieRaz na kwartał menedżerowie recertyfikują ten arkusz na spotkaniu prowadzonym bez żadnych danych o tym, kto czego używał
  7. Ryzyko błęduAudytor bada próbkę grup uprzywilejowanych, znajduje osoby, które zmieniły zespół, i ponownie zgłasza uwagę o stałych uprawnieniach
CzłowiekRyzyko błęduOczekiwanieSystem

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

Czas, który znika, zanim ktokolwiek go zmierzy.

  • Uprawnienie nadane na czterogodzinne zadanie jest aktywne przez wszystkie pozostałe godziny roku, a nic w środowisku nie odróżnia jednego od drugiego.
  • Zasięg potencjalnego incydentu to suma wszystkiego, czego nigdy nie odebrano. Gdy jedno konto inżyniera zostaje przejęte, raport z incydentu wylicza uprawnienia, które przetrwały swój cel o wiele miesięcy.
  • Recertyfikacja pochłania co kwartał czas doświadczonych ludzi z bezpieczeństwa i inżynierii, a zmienia niewiele, bo potwierdzenie listy jest szybsze niż jej podważanie bez danych o użyciu.
  • Współdzielone poświadczenia awaryjne sprawiają, że najbardziej wrażliwe działania są najtrudniejsze do przypisania, czyli dokładnie odwrotnie, niż potrzeba po sytuacji krytycznej.
  • Czekanie jest kosztem, nie tylko ryzykiem. Czterech inżynierów platformy wyznacza tempo, w jakim dostęp otrzymuje 220 inżynierów, więc pilne prace stoją w kolejce za tym, kto akurat jest wolny.

Koszt zaniechania

Dwanaście miesięcy ręcznego nadawania i odbierania uprawnień≈ 102 816 €
Cztery cykle recertyfikacji potwierdzające tę samą listę≈ 19 680 €
Wszystko, na co kolejna uwaga audytu wciąż będzie patrzeć, w skali roku≈ 122 496 €

Uprawnienia nie wygasają same. Nadanie zrobione na czterogodzinne zadanie jest wciąż aktywne o północy w grudniu, a suma wszystkiego, czego nigdy nie odebrano, to zasięg, jaki miałoby jedno przejęte konto inżyniera. Powyższa tabela wycenia obsługę. Tego wycenić nie potrafi, a to właśnie o to pyta zarząd po incydencie.

Ważniejszy od sum jest kierunek. Zatrudnienie w inżynierii rośnie szybciej niż zespoły platformowe, każdy nowy system przychodzi z własnym sposobem nadawania i bez sposobu wygaszania, a grupy uprzywilejowane zyskują członków między akcjami porządkowymi. Powtórzona uwaga o stałych uprawnieniach waży więcej niż pierwsza, a wtedy porządkowanie kosztuje więcej, niż kosztowałaby kontrola.

Scenariusz ilustracyjny

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

Organizacja

Firma płatnicza zatrudniająca 900 osób, w tym 220 inżynierów. Microsoft Entra ID i Microsoft Azure obsługują środowisko korporacyjne; lokalne klastry SQL Server, flota Linux, urządzenia sieciowe i magazyn użytkowników ERP leżą całkowicie poza rolami Entra.

Wolumen

Około 240 potrzeb dostępu uprzywilejowanego miesięcznie: odczyty z produkcyjnych baz danych podczas incydentów, czasowe prawa właściciela subskrypcji, podwyższony dostęp na serwerze aplikacyjnym, sporadyczna zmiana w sieci.

Obecny proces

Każda potrzeba trafia do jednego z czterech inżynierów platformy wiadomością na Teams. Wniosek, nadanie, późniejsze odebranie i wpis do arkusza zajmują łącznie około 45 minut, rozłożonych na kilka dni.

Wąskie gardło

Odebranie nie ma właściciela ani wyzwalacza. Kwartalna recertyfikacja stałych administratorów kosztuje mniej więcej 60 godzin czasu kadry bezpieczeństwa i inżynierii, a potwierdza większość tego, co przegląda. Ostatni audyt zgłosił stałe uprawnienia jako uwagę.

Rozwiązanie

Role w Entra i Azure stają się kwalifikowane zamiast stałych w ramach Privileged Identity Management. Wszystko poza Entra jest zgłaszane kartą w Microsoft Teams, zatwierdzane przez wskazanego właściciela systemu, nadawane przez robota i odbierane przez harmonogram, który czyta czas zakończenia z rejestru.

Potencjalny efekt

Siedem potrzeb na dziesięć obsłużonych bez inżyniera platformy, mniej więcej 126 godzin miesięcznie, oraz recertyfikacja sprowadzona do cotygodniowej listy wyjątków. To właśnie ten udział warto podważać; najpierw proszę sprawdzić go na własnym rejestrze zgłoszeń.

Proponowane rozwiązanie

Projekt zaczyna się od podziału środowiska na to, czym Microsoft już zarządza, i na resztę, bo obie części wymagają innej mechaniki. Dla ról w Entra i Azure konfigurujemy Privileged Identity Management: inżynier staje się kwalifikowany do roli zamiast jej członkiem. Aktywacja wymaga uzasadnienia i uwierzytelniania wieloskładnikowego, role wrażliwe dodatkowo zatwierdzenia, a każda rola ma maksymalny czas trwania. Pakiety dostępu w Entra ID Governance obejmują czasowy dostęp do aplikacji, a przeglądy dostępu obsługują tę resztę, która musi pozostać stała.

Dla wszystkiego, czego Entra nie obejmuje, budujemy tę samą dyscyplinę. Karta wniosku w Microsoft Teams zadaje cztery pytania: jaki system, jaka rola, po co i na jak długo w granicach maksimum z polityki. Zatwierdza tam właściciel systemu albo lider dyżuru. Robot nadaje uprawnienie w klastrze SQL Server, na hoście Linux, na urządzeniu sieciowym lub w magazynie użytkowników ERP przez jego interfejs administracyjny. Nadanie, osobę zatwierdzającą i czas zakończenia zapisuje do rejestru w UiPath Data Fabric. Wyzwalacz czasowy w Orchestrator odbiera każde przeterminowane uprawnienie i potwierdza usunięcie w systemie docelowym, zamiast zakładać, że się udało.

Obok ścieżki standardowej działają dwie inne. Dostęp awaryjny nadawany jest natychmiast, w całości rejestrowany i kierowany do wskazanej osoby z bezpieczeństwa do przeglądu następnego dnia roboczego, dzięki czemu sytuacje krytyczne pozostają szybkie, ale przestają być anonimowe. Cotygodniowy raport wylicza każde uprawnienie, za którym nie stoi otwarty wniosek, co zmienia recertyfikację ze spotkania w listę wyjątków.

Wykorzystane funkcje natywne

Microsoft Entra Privileged Identity Management z przypisaniami kwalifikowanymi, aktywacją na uzasadnienie i uwierzytelnianie wieloskładnikowe, zatwierdzaniem i maksymalnym czasem trwania; pakiety dostępu i przeglądy dostępu w Microsoft Entra ID Governance; aplikacja Approvals w Microsoft Teams; wyzwalacze czasowe, magazyn poświadczeń i ślad audytowy w UiPath Orchestrator; dziennik audytu Microsoft Purview

Co budujemy

Kartę wniosku w Teams, politykę czasów i osób zatwierdzających dla każdego systemu i roli, roboty nadające i odbierające uprawnienia w systemach poza Entra, rejestr nadań i czasów zakończenia, harmonogram odbierania wraz z krokiem potwierdzającym, ścieżkę awaryjną oraz cotygodniowy raport stałych uprawnień

Integracje dedykowane

Zmiany kwalifikacji i członkostwa w grupach przez konektor UiPath Integration Service, który wcześniej i nadal nosi nazwę „Microsoft Azure Active Directory”; interfejsy administracyjne klastrów SQL Server, floty Linux, urządzeń sieciowych i magazynu użytkowników ERP

Jak działa proces po automatyzacji

  1. CzłowiekInżynier otwiera w Teams kartę dostępu uprzywilejowanego i podaje system, rolę, powód oraz czas trwania mieszczący się w maksimum z polityki
  2. AutomatyzacjaRole w Entra i Azure trafiają do Privileged Identity Management, gdzie inżynier jest kwalifikowany, a aktywacja prosi o uzasadnienie i drugi składnik
  3. CzłowiekRole wrażliwe i każdy system poza Entra trafiają do wskazanego właściciela, który decyduje w Teams, mając powód przed oczami
  4. AutomatyzacjaRobot nadaje uprawnienie w systemie docelowym i zapisuje nadanie, osobę zatwierdzającą oraz czas zakończenia do rejestru
  5. AutomatyzacjaWyzwalacz czasowy w Orchestrator odbiera każde uprawnienie w jego czasie zakończenia i odczytuje system, by potwierdzić, że usunięcie nastąpiło
  6. Ryzyko błęduNieudane odebranie tworzy zadanie dla bezpieczeństwa w tej samej godzinie, zamiast być po cichu ponawiane
  7. AutomatyzacjaWnioski awaryjne są realizowane od razu, rejestrowane z osobą i powodem oraz kolejkowane do przeglądu następnego dnia
  8. SystemCotygodniowy raport wylicza każde stałe uprawnienie bez otwartego wniosku, w podziale na systemy i właścicieli
CzłowiekAutomatyzacjaRyzyko błęduSystem

Model współpracy człowieka z automatyzacją

Automatyzacja obsługuje

  • Przedstawienie wniosku wraz z maksymalnym czasem, jaki polityka dopuszcza dla danego systemu i roli
  • Nadawanie przez Privileged Identity Management w Entra i Azure, a wszędzie indziej przez roboty
  • Zapis każdego nadania wraz z osobą zatwierdzającą i czasem zakończenia w rejestrze
  • Odebranie po upływie czasu i potwierdzenie usunięcia w systemie docelowym
  • Przygotowanie cotygodniowego raportu uprawnień, które pozostają stałe

Ludzie decydują

  • Zatwierdzanie aktywacji i nadań dla ról wrażliwych oraz dla systemów poza Entra
  • Czasy, osoby zatwierdzające i grupy kwalifikowane dla każdego systemu, w gestii CISO, a nie zespołu platformy
  • Przegląd każdego użycia dostępu awaryjnego następnego dnia roboczego
  • Co zrobić ze stałymi uprawnieniami, których cotygodniowy raport nie potrafi wyjaśnić

Przed i po

PrzedPo
Nakład na jedną potrzebę uprzywilejowanąokoło 45 min rozłożone na dniminuty, wewnątrz samego wniosku
Czas od wniosku do dostępugodziny lub dni, zależnie od tego, kto jest wolnyminuty dla roli kwalifikowanej
Czas zakończenia nadanianigdzie nie zapisanyobowiązkowy i przechowywany w rejestrze
Odebraniepamiętane albo niewykonywane przez harmonogram i potwierdzane w systemie
Kwartalna recertyfikacjaokoło 60 godzin spotkańcotygodniowa lista wyjątków

Systemy i integracje

Stos jest krótki celowo: jeden silnik, jedna warstwa wykonawcza, jedno miejsce decyzji człowieka.

Wejścia

  • wnioski o dostęp uprzywilejowany w Microsoft Teams
  • numery incydentów z service desku
  • katalog systemów i ról ze wskazanymi właścicielami
  • wnioski awaryjne

Warstwa automatyzacji

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

Systemy docelowe

  • role Entra i Azure przez Privileged Identity Management
  • klastry SQL Server
  • hosty Linux
  • urządzenia sieciowe
  • magazyn użytkowników ERP

Punkty styku z człowiekiem: Microsoft Teams Approvals; zadania Action Center w Teams; cotygodniowy raport stałych uprawnień

wnioski o dostęp uprzywilejowany w Microsoft TeamsUiPath OrchestratorUiPath Robotsrole Entra i Azure przez Privileged Identity ManagementMicrosoft Teams Approvals

Wykorzystane technologie

Microsoft Entra Privileged Identity Management

czyni role w Entra i Azure kwalifikowanymi zamiast stałych; aktywacja z uzasadnieniem, uwierzytelnianiem wieloskładnikowym, zatwierdzeniem i maksymalnym czasem

A
Microsoft Entra ID Governance

pakiety dostępu dla czasowego dostępu do aplikacji i przeglądy dostępu dla tego, co zostaje stałe

A
Microsoft Teams (aplikacja Approvals)

karta wniosku i decyzja właściciela tam, gdzie inżynierowie już pracują

A
UiPath Robots + Orchestrator

nadawanie i odbieranie tam, gdzie nie sięga Entra; wyzwalacze czasowe, kolejki, magazyn poświadczeń, ślad audytowy

A
UiPath Integration Service

zmiany grup katalogowych i kwalifikacji przez konektor tożsamości Microsoft

A
UiPath Data Fabric

rejestr nadań, osób zatwierdzających, systemów i czasów zakończenia

A
UiPath Action Center

nieudane odebrania i nietypowe wnioski jako zadania realizowane w Teams

A
Microsoft Purview

dowody audytowe dla aktywacji, zatwierdzeń i działań administracyjnych

A
Apotwierdzona funkcja produktu (dokumentacja producenta)

Ilustracyjny model ekonomiczny

Liczby, które możecie sprawdzić na własnych danych.

Model ilustracyjny
168 z 240 miesięcznych potrzeb obsłużonych bez inżyniera platformy × 45 min= 126 h / miesiąc
126 h × 68 € pełnego kosztu godzinowego inżyniera= 8 568 € / miesiąc
× 12 miesięcy≈ 102 816 € / rok
Roczna uwolniona zdolność inżynierska (ilustracyjnie)≈ 102 816 €

Udział możliwy do zautomatyzowania jest wliczony w wolumen: spośród 240 potrzeb uprzywilejowanych miesięcznie kalkulator wycenia wyłącznie te 168, które Privileged Identity Management lub robot obsługuje od początku do końca. Liczymy po 45 minut pracy nad wnioskiem, nadaniem, odebraniem i arkuszem oraz 68 € pełnego kosztu godzinowego inżyniera w tej ilustracyjnej firmie płatniczej. Recertyfikacja trafia do kolejnej sekcji, a nie do kalkulatora, licencje i wdrożenie są wyłączone, a ograniczenie ryzyka, czyli właściwy powód tej zmiany, nie jest wyceniane wcale.

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

  • Populacja stałych administratorów kurczy się do ról, które muszą być stałe, bo cała reszta wygasa sama
  • Dostęp pojawia się w kilka minut z zapisanym zatwierdzeniem, szybciej niż znalezienie wolnego inżyniera platformy
  • Odebranie wykonuje harmonogram i potwierdza je w systemie, więc nadania przestają narastać między akcjami porządkowymi
  • Systemy poza Entra dostają tę samą dyscyplinę wygaszania co te w środku, co zamyka lukę, której audytorzy szukają najpierw
  • Każde działanie uprzywilejowane da się przypisać do osoby, powodu i wniosku, łącznie z sytuacjami awaryjnymi
  • Kwartalna recertyfikacja staje się krótkim przeglądem listy wyjątków zamiast 60-godzinnego rytuału

Perspektywa zarządu

  • Stałe uprawnienia przestają być opinią, a stają się liczbą zmieniającą się tydzień po tygodniu, w podziale na systemy i właścicieli
  • Własność jest jednoznaczna: każdy system ma wskazaną osobę, która ustala czasy i zatwierdza nadania
  • Dowody istnieją dla każdego nadania i każdego odebrania, więc próbkowanie audytowe przestaje zależeć od czyjejś pamięci
  • Doświadczeni ludzie z zespołu platformy przestają nadawać i odbierać uprawnienia, a dostęp przestaje stać w kolejce do ich kalendarzy

Wpływ na KPI zarządu

liczba utrzymujących się uprawnień stałychmediana czasu od wniosku do dostępuudział uprawnień odebranych terminowoużycia dostępu awaryjnego przejrzane w ciągu jednego dnia roboczegogodziny recertyfikacji na kwartał

Bezpieczeństwo i nadzór

Automat ma dokładnie te uprawnienia, których potrzebuje. Ani jednego więcej.

  • Uprawnienia samego robota są tu najbardziej wrażliwym elementem, więc każdy system docelowy dostaje dedykowane konto serwisowe ograniczone do przypisywania ról, a każde działanie niesie ze sobą wniosek, który je wywołał
  • Poświadczenia robotów leżą w zewnętrznym magazynie poświadczeń zintegrowanym z Orchestrator, zwykle Azure Key Vault, i nigdy nie są udostępniane człowiekowi
  • Wnioskowanie i zatwierdzanie są rozdzielone: inżynier nie zatwierdzi własnego nadania, a zespół platformy nie zmieni maksymalnego czasu bez udokumentowanej decyzji bezpieczeństwa
  • Nieudane odebrania traktujemy jak zdarzenia bezpieczeństwa i ujawniamy w tej samej godzinie, bo uprawnienie, które po cichu przeżywa swój czas zakończenia, jest tu najgroźniejszym trybem awarii
  • Nadania awaryjne są ograniczone czasowo, rejestrowane i przeglądane przez wskazaną osobę następnego dnia roboczego, a zatwierdzenia potwierdza Microsoft Purview
  • Przetwarzanie pozostaje w regionach UE UiPath Automation Cloud i Microsoft 365

Dlaczego teraz

01

Audytorzy przeszli od „pokażcie politykę” do „pokażcie nadanie i odebranie”, a ankiety ubezpieczycieli pytają wprost o uprawnienia stałe, co zamienia porządki w temat dla zarządu

02

Role kwalifikowane, aktywacja z zatwierdzeniem i przypisania na czas są dziś kwestią konfiguracji w Entra ID Governance, więc microsoftowa część środowiska nie wymaga programowania; reszta poza nią to obszar dla robotów

03

Modelowe 8 568 € miesięcznie zdolności inżynierskiej to argument mniejszy, ale kumulujący się: zespoły inżynierskie rosną szybciej niż platformowe, więc droga ręczna z każdym kwartałem jest wolniejsza

Role zarządcze, których to dotyczy

CISO

Stałe uprawnienia stają się mierzonym wyjątkiem z właścicielem zamiast domyślnym stanem środowiska, a uwaga audytu zyskuje drogę do zamknięcia

CTO

Inżynierowie dostają dostęp produkcyjny w minutach i z zapisem, a doświadczeni ludzie z platformy przestają tracić tygodnie na nadawanie i odbieranie

CIO

Dostęp uprzywilejowany staje się zarządzaną usługą z poziomem obsługi, a nie przysługą zależną od tego, kto jest online

Internal Audit

Dowody istnieją dla każdego nadania i każdego odebrania, w środowisku Microsoft i w systemach spoza niego

Częste pytania i zastrzeżenia

Inżynierowie znienawidzą tę biurokrację”.

Karta z zatwierdzeniem, które przychodzi w kilka minut, to mniejsza uciążliwość niż szukanie inżyniera platformy, a rola kwalifikowana aktywuje się w sekundy bez zatwierdzającego. Znika czekanie, pojawia się wpisanie powodu.

Privileged Identity Management już to obejmuje”.

Dla ról w Entra i Azure owszem, i to właśnie konfigurujemy, a nie budujemy od nowa. Stałe uprawnienia kryją się w klastrach baz danych, hostach Linux, urządzeniach sieciowych i magazynie użytkowników ERP, które nie mają własnego wygaszania; to obszar robotów i rejestru.

A co w prawdziwej sytuacji awaryjnej?

Ścieżka awaryjna nadaje natychmiast i rejestruje wszystko, więc nic nie zwalnia wtedy, kiedy liczy się czas. Różnica polega na tym, że wskazana osoba przegląda użycie następnego ranka, a konto nie jest współdzielone.

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

  • Całe środowisko mieści się w Entra i Azure: wystarczy skonfigurować Privileged Identity Management, rzetelnie je przeglądać i na tym poprzestać
  • Mniej niż kilkadziesiąt potrzeb uprzywilejowanych miesięcznie i dwuosobowy zespół platformy, który zna każde swoje nadanie
  • Wdrożona jest już platforma zarządzania dostępem uprzywilejowanym i obejmuje systemy poza Entra
  • Organizacja nie wskaże właściciela dla każdego systemu, więc przepływ nie ma komu przekazać decyzji

Pytanie na najbliższe posiedzenie

Stałe uprawnienia to decyzja, której nikt w tej firmie nie pamięta, więc kto na tej sali potrafi wskazać ostatnie uprawnienie administracyjne odebrane dlatego, że zadanie za nim stojące dobiegło końca?

Podejście wdrożeniowe

Zakres bez niedomówień, jeszcze przed podpisem.

Dostarczamy

  • Inwentaryzację stałych uprawnień w Entra, Azure i systemach poza nimi, wraz z datą ostatniego użycia każdego z nich
  • Konfigurację Privileged Identity Management i pakietów dostępu ze wskazanym właścicielem dla każdej roli
  • Politykę czasów i osób zatwierdzających dla każdego systemu i roli, uzgodnioną z CISO i spisaną
  • Roboty nadające i odbierające uprawnienia w każdym systemie poza Entra, z obsługą nadań nieudanych
  • Rejestr, harmonogram odbierania, ścieżkę awaryjną i cotygodniowy raport
  • Pilotaż na jednej roli Entra i jednym systemie zewnętrznym, potem wdrożenie według ryzyka z opieką powdrożeniową

Potrzebujemy od Państwa

  • Wskazanego właściciela dla każdego systemu wydającego uprawnienia, z prawem ustalania czasów i zatwierdzania
  • Licencji Entra ID P2 lub Entra ID Governance dla osób objętych zakresem
  • Dedykowanych kont administracyjnych dla robotów w każdym systemie docelowym, ograniczonych do przypisywania ról
  • Przeglądu bezpieczeństwa maksymalnych czasów i ścieżki awaryjnej przed uruchomieniem

Etapy

Inwentaryzacja

Każde stałe uprawnienie, gdzie leży, kto je ma i kiedy było użyte ostatnio

Polityka

Maksymalne czasy, osoby zatwierdzające i grupy kwalifikowane na system i rolę, zatwierdzone przez bezpieczeństwo

Budowa

Karta wniosku, roboty do nadawania i odbierania, rejestr, harmonogram odbierania, raportowanie

Pilotaż

Jedna rola Entra i jeden system poza Entra, z zespołem platformy zatwierdzającym każde nadanie

Wdrożenie

Systemy przełączane według ryzyka, potem członkostwo stałe przycięte do udokumentowanych wyjątków

Działowe. O nakładzie decyduje liczba systemów poza Entra, sposób nadawania i odbierania uprawnień w każdym z nich oraz to, jak szybko da się wskazać dla każdego właściciela.