Pilotaż zero-trust w firmie technologicznej rzadko wygląda jak na diagramie z prezentacji. Pierwsze pięć dni pracy nad wdrożeniem to głównie inwentaryzacja, sporne decyzje i ustalanie, czego w tym tygodniu świadomie nie robimy. Poniżej zapis tego, co w praktyce okazało się wykonalne, a co trzeba było przesunąć na kolejne etapy.
Najwięcej czasu pochłonęło ustalenie, kto i do czego ma dostęp. Lista kont w katalogu głównym rozjechała się z rzeczywistością — część osób korzystała z kont technicznych, część z kont współdzielonych, a kilka systemów wewnętrznych w ogóle nie było podpiętych do centralnego uwierzytelniania. Bez tej mapy każda reguła dostępu byłaby zgadywaniem.
W praktyce pierwsze dwa dni zeszły na rozmowach z zespołami i porównywaniu logów uwierzytelnień z listą uprawnień. Efektem nie była żadna konfiguracja, tylko arkusz z trzema kolumnami: system, właściciel, realny zakres dostępu. Ten arkusz okazał się najcenniejszym dokumentem całego tygodnia.
Kusi, żeby od razu objąć regułami całe środowisko produkcyjne. W pierwszym tygodniu to pewny sposób na zablokowanie pracy zespołów i utratę zaufania do projektu. Zdecydowaliśmy się na jeden system wewnętrzny — repozytorium konfiguracji — i potraktowaliśmy go jako poligon.
Ograniczenie zakresu ma jeszcze jedną zaletę: łatwiej zmierzyć efekt. Po pięciu dniach widzieliśmy konkretne liczby — ile prób dostępu zostało odrzuconych, ile sesji wymagało ponownego uwierzytelnienia, ile zgłoszeń trafiło do helpdesku. Przy pełnym wdrożeniu te dane rozmyłyby się w szumie.
Segmentacja na poziomie brzegu sieci to stosunkowo prosta część. Prawdziwe pytania pojawiają się przy komunikacji między usługami wewnątrz środowiska. Część połączeń była udokumentowana, część wynikała z konfiguracji sprzed lat i nikt nie potrafił powiedzieć, czy są jeszcze potrzebne.
W pierwszym tygodniu nie da się tego uporządkować. Można natomiast zacząć rejestrować ruch między segmentami i oznaczyć połączenia, których nikt nie potrafi wyjaśnić. To materiał na kolejne tygodnie, ale bez niego każda reguła zero-trust będzie oparta na założeniach, a nie na faktach.
Trzy rzeczy wypadły z planu pierwszego tygodnia i nie było sensu ich forsować. Po pierwsze, pełne wdrożenie uwierzytelniania wieloskładnikowego dla wszystkich systemów — część z nich nie obsługuje nowoczesnych metod i wymaga wymiany albo obejścia. Po drugie, automatyczna rotacja poświadczeń dla kont technicznych, bo najpierw trzeba ustalić, które z nich są jeszcze używane. Po trzecie, integracja z systemem monitorowania zagrożeń — bez uporządkowanej listy zdarzeń dostarczałaby głównie szum.
Odłożenie tych elementów nie było porażką. Wręcz przeciwnie — pozwoliło skupić się na tym, co daje efekt natychmiast i nie blokuje codziennej pracy.
Po pięciu dniach mieliśmy działający pilotaż na jednym systemie, arkusz inwentaryzacji dostępu, wstępną listę nieudokumentowanych połączeń i kilka konkretnych wniosków na temat tego, gdzie organizacja ma luki w podstawach. To niewiele w porównaniu z pełną architekturą zero-trust, ale wystarczająco, żeby wiedzieć, w jakiej kolejności robić resztę.
Najważniejsze okazało się coś, czego nie da się zapisać w konfiguracji: zespół przestał traktować zero-trust jako projekt działu bezpieczeństwa i zaczął widzieć w nim serię decyzji, które dotyczą też jego codziennej pracy.
Jeśli szukasz punktu odniesienia dla własnego pilotażu, zajrzyj do notatek z sesji planistycznej albo napisz do nas przez stronę kontaktową — chętnie porównamy założenia.
Trzy materiały z tej serii. Każdy dotyczy innego etapu pracy z infrastrukturą i ochroną danych w firmie technologicznej.
Ten wpis opisuje konkretny temat zamiast ogólnego nagłówka. Wyjaśnia, co jest brane pod uwagę, dlaczego ma to znaczenie w kontekście ochrony sieci prywatnych i jakiego szczegółu czytelnik może się spodziewać w dalszej części. Tekst jest celowo prosty i rzeczowy, żeby czytało się go jak prawdziwy materiał, a nie zapowiedź.
Czytaj dalejMateriał skupia się na praktycznym użyciu, kompromisach i decyzjach, które czytelnik może rozpoznać z własnego środowiska pracy. Unika szerokich zapewnień marketingowych i trzyma temat blisko konkretnej sytuacji — pierwszego tygodnia po zmianach w infrastrukturze. Opis daje dość treści, żeby traktować go jako realny wpis, a nie kartę zastępczą.
Czytaj dalejTrzeci wpis ma własny powód istnienia w tej serii. Porusza osobny wątek, zawiera konkretny kontekst i nie powtarza tej samej obietnicy innymi słowami. Chodzi o to, co realnie zmieniło się po pierwszym przeglądzie — w regułach, w priorytetach i w sposobie patrzenia na ruch w sieci korporacyjnej.
Czytaj dalej