Start · Rozwiązania · Inne rozwiązania

Rozwiązanie · Inne rozwiązania

Jeden katalog, jedna tabela polityk i uprawnienie, które wygasa samo

Dostęp do chmury i repozytoriów dla inżynierów w godzinę

Inżynier zamawia dostęp z katalogu w Microsoft Teams; tabela polityk od razu przyznaje zakresy rutynowe, roboty wykonują nadanie w GitHub, Azure, AWS i Snowflake, a każde uprawnienie wygasa.

Rozwiązanie działoweMicrosoft TeamsCzłowiek w pętli decyzyjnejAutomatyzacja deterministyczna
520wniosków o dostęp miesięcznie trafia do sześciu inżynierów platformy tej przykładowej firmy płatniczej, a mediana czasu nadania to nieco ponad dwa dni.

Streszczenie dla zarządu

Wyzwanie

Sześć dni czekania na repozytorium i osobisty token wklejony na czacie, żeby sprint ruszył dalej.

Co się zmienia

Pierwsze, co budujemy, to drzwi wejściowe: jeden katalog zasobów inżynierskich w języku, którym inżynierowie mówią.

Wartość biznesowa

Dostęp rutynowy przychodzi w ciągu godziny, więc powód, by pożyczać token kolegi, znika.

Systemy w tle

GitHub; subskrypcje Microsoft Azure i klastry Kubernetes; konta AWS

Problem biznesowy

Inżynieria

Dostęp inżynierski rozkłada się na systemy, których nigdy nie projektowano pod wspólny model zatwierdzania. Role w Azure można uczynić kwalifikowanymi w Microsoft Entra Privileged Identity Management. Zespołami w GitHub zarządza ten, kto ma rolę organisation owner. Role w AWS leżą w osobnej strukturze kont, hurtownia danych ma własne nadania, a klastry Kubernetes swoje.

Niemal każdy realny wniosek dotyka kilku z nich naraz, więc staje się zgłoszeniem dla zespołu platformowego, którego inżynierowie budują też samą platformę. Zatwierdzający bywa niejasny, więc wnioski czekają, aż ktoś ustali, kto ma zdecydować. Terminów nikt nie ustawia, więc uprawnienia się kumulują, aż kwartalny przegląd każe tech leadowi ocenić czterysta nazw ról za jednym posiedzeniem.

Inżynierowie, którzy czekają, obchodzą proces, a obejście jest zawsze mniej bezpieczne niż sam proces. Stan ten trwa, bo zespół platformowy rozliczany jest z dostępności i dostaw, a nie z kolejki, i bo nikt nie odpowiada za dostęp jak za produkt.

Jak to wygląda dzisiaj

  1. CzłowiekInżynier zakłada zgłoszenie w Jirze i opisuje otwartym tekstem repozytorium, środowisko albo rolę chmurową, której potrzebuje
  2. OczekiwanieZgłoszenie czeka w kolejce zespołu platformowego, który przebiera je między incydentami a pracą nad platformą i często dopytuje o szczegóły
  3. CzłowiekZatwierdzającego zgaduje się po nazwie zespołu i ponagla w wątku na czacie, aż ktoś odpowie
  4. OczekiwanieMijają dni; inżynier pożycza token kolegi, żeby sprint ruszył dalej
  5. SystemInżynier platformy nadaje uprawnienia w GitHub, potem w portalu Azure, potem w hurtowni, konsola po konsoli
  6. Ryzyko błęduZgłoszenie zamyka się bez terminu ważności, więc uprawnienie przeżywa projekt, zmianę zespołu i reorganizację
  7. Ryzyko błęduMiesiące później przegląd dostępu każe tech leadowi poświadczyć czterysta nazw ról i wszystko zostaje zatwierdzone
CzłowiekOczekiwanieSystemRyzyko błędu

Dlaczego obecny proces kosztuje więcej, niż się wydaje

Rachunek, którego nie widać w budżecie.

  • Inżynierowie platformy z górnej półki płacowej spędzają godziny tygodniowo na czynnościach urzędniczych, czyli na najmniej wartościowej pracy, jaką firma może od nich kupić.
  • Czekanie ma własną cenę: wnioskujący inżynier traci kontekst przy każdej przerwie, a pożyczony token to koszt, którego nie ma w żadnej pozycji budżetu.
  • Uprawnienia stałe rosną z każdym nadaniem bez terminu, więc zasięg jednego przejętego konta poszerza się po cichu.
  • Recenzent nie oceni tego, czego zakresu nie ustalił, więc kwartalny przegląd poświadcza narastanie zamiast je korygować.
  • Zapomniane subskrypcje sandboksowe dalej generują koszt, wdrożenie nowej osoby trwa tydzień dłużej, niż powinno, a każdy przejęty zespół przynosi kolejny komplet konsol.

Koszt bezczynności

Dwanaście miesięcy nadań wykonywanych konsola po konsoli≈ 153 504 €
Te same dwanaście miesięcy czekania inżynierów i obchodzenia kolejki≈ 162 240 €
Obie pule po przekroczeniu 500 osób w inżynierii, rocznie≈ 415 500 €

Wolumen idzie tu za zatrudnieniem i za architekturą: każda nowa usługa, klaster i konto chmurowe dokłada typy wniosków, a zespół platformowy rośnie wolniej niż jedno i drugie. Czas nadania się wydłuża, a obejście rozchodzi się od dwóch tech leadów do normy.

Drugi koszt kumuluje się, zamiast się powtarzać. Nadanie bez terminu z marca w grudniu wciąż działa, a wszystko, czego nigdy nie odebrano, jest zasięgiem jednego wyciekłego tokena, co dla firmy płatniczej oznacza rozmowę z regulatorem. Subskrypcje sandboksowe w tym czasie dalej generują koszt, a inżynierowie, którzy przychodzą z oczekiwaniem samoobsługi, wyciągają wnioski w pierwszym tygodniu.

Scenariusz ilustracyjny

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

Organizacja

Firma tworząca oprogramowanie płatnicze z 380 inżynierami; produkty działają na Microsoft Azure, część usług na AWS, kod jest w GitHub, potoki w Azure DevOps, analityka w Snowflake, a obciążenia na Kubernetes. Licencjonowany jest Microsoft Entra ID P2, a Privileged Identity Management skonfigurowano wyłącznie dla ról właściciela subskrypcji Azure.

Wolumen

Około 520 wniosków o dostęp miesięcznie trafia do sześcioosobowego zespołu platformowego jako zgłoszenia w Jirze: członkostwo w repozytoriach i zespołach, role środowisk nieprodukcyjnych, role odczytu produkcji, czasowe uprawnienia administracyjne na produkcji, subskrypcje chmurowe na eksperymenty.

Proces obecny

Zgłoszenia pisane otwartym tekstem, zatwierdzający zgadywany po nazwie zespołu, wykonanie ręczne w kilku konsolach i zgłoszenie zamykane bez terminu ważności. Mediana czasu nadania to nieco ponad dwa dni.

Wąskie gardło

Około 24 minut pracy inżyniera platformy na wniosek, na przebranie, poszukiwanie zatwierdzającego i wykonanie, oraz około 20 minut, które wnioskujący inżynier traci na przełączanie kontekstu, gdy zgłoszenie leży.

Rozwiązanie

Katalog zasobów inżynierskich za kartą wniosku w Microsoft Teams; tabela polityk, która od razu nadaje zakresy rutynowe, a resztę kieruje do wskazanego zatwierdzającego; roboty wykonujące nadanie tam, gdzie dostęp faktycznie żyje; rejestr wnioskującego, zatwierdzającego, zakresu i terminu ważności; oraz harmonogram odbierający uprawnienie, gdy czas minie.

Potencjalny efekt

Dostęp rutynowy przychodzi w ciągu godziny, trzy wnioski na cztery nie docierają do inżyniera platformy, a uprawnienia stałe przestają rosnąć, bo każde nadanie ma termin. Ilustracyjnie, nie jest to wynik u klienta.

Proponowane rozwiązanie

Pierwsze, co budujemy, to drzwi wejściowe: jeden katalog zasobów inżynierskich w języku, którym inżynierowie mówią, od repozytorium i roli środowiska nieprodukcyjnego po rolę odczytu produkcji, rolę w hurtowni i subskrypcję chmurową na eksperyment. Inżynier otwiera kartę wniosku w Microsoft Teams, wybiera pozycję, podaje zakres i przyjmuje albo skraca domyślny czas trwania. Otwarty tekst zamienia się w wybór, a wybór da się rozstrzygnąć.

Drugie to sama decyzja. Bezpieczeństwo pisze tabelę polityk, utrzymywaną jako reguły biznesowe DMN w UiPath Maestro, i żadna reguła nie mieszka nigdzie indziej. Odczyt nieprodukcyjny dla członka zespołu będącego właścicielem zasobu jest nadawany od ręki. Odczyt produkcji wymaga tech leada, który zatwierdza z zadania UiPath Action Center w tym samym kliencie Teams. Zapis lub administracja na produkcji wymagają tech leada i bezpieczeństwa, a nadanie przybiera formę czasowej aktywacji w Microsoft Entra Privileged Identity Management albo równoważnej roli krótkotrwałej. Nikt nie zatwierdza własnego wniosku.

Trzecie to wykonanie i zegar. Roboty UiPath nadają uprawnienia tam, gdzie dostęp żyje: przypisania Azure RBAC i PIM przez Microsoft Graph, role AWS i Snowflake przez ich konektory w UiPath Integration Service, członkostwo w zespołach GitHub przez konektor, który budujemy na REST API GitHub. Każde nadanie jest odczytywane zwrotnie z systemu docelowego i zapisywane w UiPath Data Fabric wraz z wnioskującym, zatwierdzającym, zakresem i terminem. Wyzwalacz czasowy w UiPath Orchestrator odbiera je po upływie terminu, po karcie przedłużenia. Power BI raportuje czas nadania według zakresu, uprawnienia stałe i to, co wygasa w tym tygodniu. Bez AI na ścieżce: decyzję o dostępie trzeba dać się przeczytać wiersz po wierszu rok później.

Wykorzystane funkcje natywne

Role kwalifikowane Microsoft Entra Privileged Identity Management z aktywacją na czas określony, zatwierdzeniem i historią audytu; Azure RBAC; pakiety dostępu Microsoft Entra ID Governance; UiPath Maestro BPMN z regułami biznesowymi DMN; zadania UiPath Action Center wykonywane wewnątrz Microsoft Teams; wyzwalacze czasowe, magazyny poświadczeń i dziennik audytu UiPath Orchestrator; encje UiPath Data Fabric z audytem

Co budujemy

Katalog zasobów, tabelę polityk, karty wniosku i zatwierdzenia, robota wykonawczego na każdy system docelowy z odczytem zwrotnym, rejestr nadań, harmonogram wygasania i przedłużeń, kolejkę wyjątków oraz raport Power BI

Integracja niestandardowa

Członkostwo w zespołach i repozytoriach GitHub przez konektor zbudowany w Connector Builder na REST API GitHub; role AWS IAM i Snowflake przez ich konektory w UiPath Integration Service; przypisania Azure RBAC i PIM przez Microsoft Graph

Jak działa proces zautomatyzowany

  1. CzłowiekInżynier otwiera kartę wniosku w Microsoft Teams, wybiera pozycję katalogu, podaje zakres i przyjmuje albo skraca czas trwania
  2. AutomatyzacjaTabela polityk ocenia wnioskującego, zespół, zasób i zakres i oddziela to, co nadaje sama, od tego, co wymaga człowieka
  3. AutomatyzacjaZakres rutynowy, czyli odczyt nieprodukcyjny dla członka zespołu będącego właścicielem, jest nadawany w kilka minut i potwierdzany na tym samym czacie
  4. CzłowiekReszta trafia do zatwierdzającego wskazanego przez katalog jako zadanie Action Center w Teams: tech lead przy odczycie produkcji, dodatkowo bezpieczeństwo przy zakresie uprzywilejowanym
  5. SystemRobot wykonuje nadanie w systemie docelowym, odczytuje wynik zwrotnie i zapisuje w rejestrze wnioskującego, zatwierdzającego, zakres i termin
  6. AutomatyzacjaPrzed terminem karta przedłużenia trafia do wnioskującego i zatwierdzającego; bez przedłużenia harmonogram odbiera uprawnienie i zapisuje jego usunięcie
  7. CzłowiekNieudane nadanie albo wniosek niepasujący do żadnej pozycji katalogu staje się zadaniem zespołu platformowego, który decyduje i dopisuje pozycję, gdy się powtarza
CzłowiekAutomatyzacjaSystem

Model współpracy człowiek–automat

Automatyzacja obsługuje

  • Ocenę każdego wniosku wobec tabeli polityk i natychmiastowe nadanie zakresów rutynowych
  • Kierowanie reszty do zatwierdzającego wskazanego przez katalog i ponaglanie go w Teams
  • Wykonanie i odczyt zwrotny nadań w GitHub, Azure, AWS i Snowflake oraz zarejestrowanie każdego z nich
  • Wysyłkę kart przedłużenia i odbieranie uprawnień, których czas minął

Ludzie decydują

  • Tech leadzi zatwierdzają odczyt produkcji dla własnych zespołów i rozstrzygają o przedłużeniach
  • Bezpieczeństwo odpowiada za tabelę polityk i zatwierdza każdy zakres uprzywilejowany
  • Zespół platformowy obsługuje nieudane nadania i decyduje, które wyjątki wchodzą do katalogu
  • Kierownictwo inżynierii przegląda uprawnienia stałe raz w miesiącu

Przed i po

PrzedPo
Czas od wniosku do działającego dostępumediana nieco ponad dwa dniminuty przy zakresie rutynowym
Termin ważności nadanianie jest zapisywanyobowiązkowy, w rejestrze i egzekwowany harmonogramem
Konsole dotykane przy wnioskudo pięciu, ręcznieżadna; roboty wykonują i odczytują wynik zwrotnie
Pożyczane tokeny w czasie oczekiwanianieformalna normanie ma już powodu, żeby pożyczać
Przegląd dostępuczterysta nazw ról ocenianych z pamięcinadania przedłużone świadomie, z zakresem i zatwierdzającym

Systemy i integracje

Każdą pozycję da się sprawdzić w dokumentacji producenta. Klasa dowodu jest podana przy każdej.

Wejścia

  • karty wniosków z Microsoft Teams
  • katalog zasobów
  • tabela polityk prowadzona przez bezpieczeństwo

Warstwa automatyzacji

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

Systemy docelowe

  • GitHub
  • subskrypcje Microsoft Azure i klastry Kubernetes
  • konta AWS
  • Snowflake
  • Azure DevOps
  • Microsoft Entra ID z Privileged Identity Management

Punkty kontaktu z ludźmi: karta wniosku w Teams; zadania zatwierdzenia w UiPath Action Center; karty przedłużenia przed terminem; kolejka wyjątków zespołu platformowego

karty wniosków z Microsoft TeamsUiPath MaestroUiPath OrchestratorGitHubkarta wniosku w Teams

Wykorzystane technologie

Microsoft Entra Privileged Identity Management

role kwalifikowane aktywowane na czas określony z zatwierdzeniem, uzasadnieniem i historią audytu

A
Microsoft Entra ID Governance (entitlement management)

pakiety dostępu dla zakresów opartych na grupach, z etapami zatwierdzania i przypisaniami, które kończą się same

A
UiPath Maestro (BPMN z regułami biznesowymi DMN)

tabela polityk: kto o co może wnioskować, co jest nadawane od razu i kto zatwierdza resztę

A
UiPath Robots + UiPath Orchestrator

wykonanie w każdym systemie docelowym z odczytem zwrotnym; wyzwalacze czasowe wygasania i odbierania; magazyn poświadczeń i dziennik audytu

A
UiPath Integration Service (konektory AWS, Snowflake, Microsoft Azure i Microsoft Teams, Connector Builder)

nadania w AWS IAM i Snowflake, wywołania zarządcze Azure, komunikaty w Teams i własny konektor na API GitHub

A
UiPath Action Center w Microsoft Teams

zadania zatwierdzenia i wyjątków wykonywane bez wychodzenia z klienta czatu

A
UiPath Data Fabric

rejestr nadań: wnioskujący, zatwierdzający, zakres, termin, przedłużenie i odebranie, z audytem

A
Power BI

czas nadania według zakresu, udział nadań w ramach polityki, uprawnienia stałe i terminy do upływu

A
Apotwierdzona funkcja produktu (dokumentacja producenta)

Ilustracyjny model ekonomiczny

Arytmetyka jest jawna, żeby dało się z nią spierać.

Model ilustracyjny
390 wniosków miesięcznie objętych tabelą polityk (trzy na cztery z 520) × 24 minuty= 156 h / miesiąc
156 h × 82 € pełnego kosztu godzinowego inżyniera platformy= 12 792 € / miesiąc
× 12 miesięcy≈ 153 504 € / rok
Roczne uwolnione moce inżynierii platformowej (ilustracyjnie)≈ 153 504 €

W kalkulatorze jest wyłącznie własna praca zespołu platformowego i wyłącznie ta jej część, którą przejmuje tabela polityk. Liczymy trzy wnioski na cztery z 520, po 24 minuty, jakie każdy kosztuje w przebraniu, poszukiwaniu zatwierdzającego i wykonaniu w konsolach, przy 82 € pełnego kosztu godzinowego inżyniera platformy. 20 minut wnioskującego inżyniera na wniosek leży w kolejnej sekcji. Licencje, zapomniane subskrypcje sandboksowe i wartość bezpieczeństwa wynikająca z likwidacji współdzielonych tokenów zostają poza arytmetyką, a ostatnia z nich zwykle jest powodem, dla którego sponsorem projektu zostaje CISO.

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

  • Dostęp rutynowy przychodzi w ciągu godziny, więc powód, by pożyczać token kolegi, znika
  • Każde nadanie ma termin egzekwowany przez harmonogram, więc uprawnienia stałe przestają narastać między akcjami porządkowymi
  • Zatwierdzających wskazuje katalog, a nie zgadywanie po nazwie zespołu, więc nic nie czeka na niewłaściwą osobę
  • Inżynierowie platformy przestają nadawać uprawnienia ręcznie w pięciu konsolach i wracają do platformy, z której są rozliczani
  • Przegląd dostępu kurczy się do nadań przedłużonych świadomie, z zakresem, zatwierdzającym i datą już zapisanymi
  • Wdrożenie zespołu albo przejętej spółki staje się wpisami w katalogu, a nie wiedzą plemienną

Perspektywa zarządu

  • Czas nadania staje się mierzoną liczbą według typu zasobu, więc powolny zatwierdzający jest widoczny, a nie podejrzewany
  • Uprawnienia stałe mają linię trendu, a jej kierunek jest tą kontrolą, o którą zarząd prosił
  • Rejestr odpowiada, kto co ma, od kogo dostał i do kiedy, w jednym zapytaniu
  • Kolejka zespołu platformowego zamienia się w listę wyjątków, więc jego moce da się planować, a nie tylko wchłaniać

Wpływ na KPI zarządu

mediana czasu nadania według zakresuudział nadań w ramach polityki bez udziału człowiekauprawnienia stałeuprawnienia odebrane w terminiewnioski spoza katalogu

Bezpieczeństwo i nadzór

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

  • Każdy robot wykonawczy ma jedno wąskie uprawnienie na system: aplikację GitHub ograniczoną do członkostwa w zespołach, prawo przypisywania ról Azure ograniczone do definicji ról z katalogu, rolę AWS ograniczoną do wymienionych ról IAM, rolę Snowflake ograniczoną tak samo
  • Zakresy uprzywilejowane nigdy nie są stałe: to aktywacje Privileged Identity Management albo role krótkotrwałe, których termin egzekwuje harmonogram, przechowywane obok zatwierdzenia, które je przyznało
  • Tabela polityk należy do bezpieczeństwa, jest wersjonowana i zmienia się wyłącznie przez recenzowane wydanie; nikt nie zatwierdza własnego wniosku, a ścieżka awaryjna jest odnotowywana jako taka
  • Sekrety robotów są pobierane w czasie wykonania z Azure Key Vault przez magazyn poświadczeń Orchestratora, a każde nadanie, odczyt zwrotny i odebranie to osobny zapis
  • Przetwarzanie pozostaje w Państwa dzierżawie Microsoft 365 i w regionie UE UiPath Automation Cloud. Rejestr niesie identyfikatory, zakresy i daty, nigdy kod ani dane z systemów, do których nadano dostęp

Dlaczego teraz

01

Regulacje dotyczące oprogramowania finansowego, w tym DORA, traktują dostęp uprzywilejowany jako coś, co trzeba udowodnić, a nie opisać. Rejestr nadań z zatwierdzającym i terminem jest właśnie tym dowodem

02

Privileged Identity Management i Azure RBAC dają natywnie czasową, zatwierdzaną aktywację dla środowiska Microsoft, więc zostaje obudowa wokół GitHub, AWS i platformy danych, a konektory czynią z niej ćwiczenie konfiguracyjne

03

Inżynierowie oczekują samoobsługi platformowej i głosują obejściami, gdy jej nie dostają. Modelowe 12 792 € miesięcznie obsługi po stronie platformy biegnie w tym czasie dalej, a pożyczane tokeny razem z nim

Istotne role kierownicze

CTO

Inżynierowie są odblokowani w ciągu godziny bez osłabiania kontroli, a zespół platformowy buduje, zamiast nadawać uprawnienia

CISO

Współdzielone tokeny tracą rację bytu, uprawnienia wygasają domyślnie, a każde nadanie niesie swoje zatwierdzenie

Dyrektor inżynierii

Wdrożenie zespołu albo przejętej spółki staje się wpisami w katalogu, a nie wiedzą plemienną

CIO

Jeden proces dostępu dla kodu, chmury i danych, z rejestrem do odpytania zamiast pięciu konsol

Częste pytania i zastrzeżenia

Privileged Identity Management już to potrafi.

Dla ról Entra i Azure RBAC owszem, i używamy go pod spodem, a nie obok. Ten sam wniosek nadal staje się zgłoszeniem dla GitHub, AWS, Snowflake i klastra; katalog, tabela polityk i rejestr obejmują je wszystkie.

Inżynierowie znienawidzą kolejny formularz.

Formularz to karta w Teams z pozycją, zakresem i czasem trwania, z odpowiedzią w kilka minut. Nienawidzą sześciodniowego zgłoszenia i dlatego je obchodzą.

Nadawanie bez człowieka to ryzyko.

Wyłącznie w granicach tabeli polityk napisanej przez bezpieczeństwo i wyłącznie dla wskazanych w niej zakresów: odczytu nieprodukcyjnego dla członka zespołu będącego właścicielem. Reszta zachowuje wskazanego zatwierdzającego, a każde nadanie teraz wygasa, co jest większą kontrolą niż dziś.

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

  • Mniej niż około pięćdziesięciu inżynierów na jednej chmurze, gdzie Privileged Identity Management i dobrze utrzymana struktura zespołów w GitHub już odpowiadają na to pytanie
  • Wewnętrzna platforma deweloperska oferująca już samoobsługowy dostęp; wtedy sensowną pracą jest rejestr i termin ważności, a nie drugie drzwi wejściowe
  • Brak gotowości bezpieczeństwa do napisania tabeli polityk; bez niej każdy wniosek pozostaje decyzją człowieka, a kolejka zostaje tam, gdzie jest

Pytanie na najbliższe posiedzenie

Gdybyśmy dziś zapytali trzech naszych tech leadów, czy kiedykolwiek udostępnili token, żeby odblokować kolegę, ilu odpowiedziałoby twierdząco i co to powiedziałoby nam o odległości między naszym procesem dostępu a naszą spisaną polityką bezpieczeństwa?

Podejście wdrożeniowe

Wdrożenie idzie etapami, bo tak da się je zatrzymać w każdej chwili.

Dostarczamy

  • Klasyfikację zgłoszeń o dostęp z ostatniego kwartału na pozycje katalogu, wraz z udziałem, jaki nadałaby polityka
  • Tabelę polityk opracowaną z bezpieczeństwem i dwoma liderami inżynierii: zakresy, zatwierdzający, czasy trwania i to, co uchodzi za rutynę
  • Karty wniosku i zatwierdzenia w Microsoft Teams oraz kolejkę wyjątków dla zespołu platformowego
  • Roboty wykonawcze na każdy system docelowy z odczytem zwrotnym, zaczynając od GitHub i nieprodukcyjnego Azure
  • Rejestr nadań, karty przedłużenia, harmonogram odbierania oraz raport Power BI o czasie nadania i uprawnieniach stałych
  • Testy w trybie cienia na rzeczywistych wnioskach, dokumentację i szkolenie tech leadów oraz zespołu platformowego

Potrzebujemy od Państwa

  • Dostępu do API każdego systemu docelowego, z kontem na system ograniczonym do ról z katalogu
  • Microsoft Entra ID P2 albo Microsoft Entra ID Governance dla zakresów uprzywilejowanych oraz właściciela tabeli polityk po stronie bezpieczeństwa
  • Wskazanego zatwierdzającego dla każdej pozycji katalogu i zgłoszeń o dostęp z ostatniego kwartału z Jiry

Etapy

Rozpoznanie

Zgłoszenia z ostatniego kwartału sklasyfikowane; pozycje katalogu i pierwsza tabela polityk opracowane z bezpieczeństwem

Projekt

Zakresy, zatwierdzający, domyślne czasy trwania, schemat rejestru i model bezpieczeństwa

Pilotaż

GitHub i nieprodukcyjny Azure dla dwóch zespołów, obok kolejki zgłoszeń, automatyczne nadania tylko dla odczytu nieprodukcyjnego

Walidacja

Rzeczywiste wnioski odtworzone w trybie cienia; nadania, odczyty zwrotne i odebrania przetestowane

Skalowanie

Zakresy produkcyjne przez Privileged Identity Management, potem AWS, Snowflake i pozostałe zespoły

Utrzymanie

Comiesięczny przegląd uprawnień stałych, zmiany w katalogu i kolejka wyjątków jako backlog

Działowe. Nakład zależy od liczby systemów docelowych i jakości ich API, od tego, ile z polityki bezpieczeństwo zapisze, i od tego, czy zatwierdzającego da się wskazać dla pozycji katalogu, a nie dla zespołu.