Od czego zaczęliśmy

Punktem wyjścia była mapa przepływów danych między działem produktu, środowiskiem testowym a zewnętrznymi dostawcami API. Sama mapa zajęła pół dnia, bo nikt wcześniej nie spisał jej w jednym miejscu. Okazało się, że dwa zespoły korzystają z tego samego konta serwisowego do zadań, które nie mają ze sobą nic wspólnego.

To typowy problem w firmach, które rosły szybciej niż ich dokumentacja. Konto było wygodne, więc nikt nie kwestionował jego zakresu. Dopiero rozpisanie uprawnień na tablicy pokazało, jak szeroko sięga dostęp.

Trzy decyzje, które zapadły

Pierwsza: rozdzielenie kont serwisowych według zadań, nie według zespołów. Druga: wprowadzenie przeglądu uprawnień co kwartał, z jasnym właścicielem każdej roli. Trzecia: włączenie logowania połączeń wychodzących z segmentu produkcyjnego, żeby mieć punkt odniesienia przy późniejszych analizach.

Nie ustaliliśmy jeszcze narzędzia do monitoringu. Świadomie odłożyliśmy tę decyzję, bo najpierw chcemy wiedzieć, jakie zdarzenia faktycznie generuje nasza infrastruktura. Wybór platformy przed zebraniem danych zwykle kończy się konfiguracją pod cudze scenariusze.

Co zostało na później

Temat segmentacji sieci prywatnej wróci na kolejnym spotkaniu. Na razie mamy tylko szkic stref: produkcyjna, testowa, biurowa i partnerska. Reguły ruchu między nimi wymagają jeszcze konsultacji z zespołem odpowiedzialnym za środowisko deweloperskie, bo zbyt sztywne zasady potrafią zatrzymać pracę na kilka godzin.

Osobno zapisaliśmy kwestię dostępu zdalnego dla podwykonawców. To wątek, który łatwo pominąć, a później okazuje się, że połowa tymczasowych kont nigdy nie została wyłączona.

Następny krok

Zespół przygotuje inwentaryzację tożsamości i przypisze każdą z nich do konkretnej roli. Bez tego kolejne etapy — czy to zero-trust, czy monitoring zagrożeń — będą opierać się na założeniach, a nie na faktach. Kolejne notatki z sesji pojawią się po przeglądzie pierwszych logów.