Pierwszy przegląd infrastruktury zwykle kończy się listą usterek i wnioskiem, że „trzeba to uporządkować”. Trzy miesiące później okazuje się, że najwięcej zmieniło się nie w konfiguracji, a w sposobie, w jaki zespół rozmawia o dostępie do systemów. Poniżej zapis tego, co faktycznie zostało poprawione, a co nadal czeka na decyzję.
Punktem wyjścia był arkusz z kontami uprzywilejowanymi w trzech środowiskach: produkcyjnym, testowym i biurowym. W trakcie przeglądu okazało się, że część wpisów dotyczy osób, które od dawna nie pracują w firmie, a kilka kont współdzielonych nadal ma aktywne klucze API. Sama lista nie wystarczyła — trzeba było przypisać każde konto do konkretnej roli i właściciela.
Po pierwszym przeglądzie wprowadziliśmy zasadę, że każde konto uprzywilejowane ma osobę odpowiedzialną za jego przegląd co kwartał. Nie jest to rewolucja, ale wymusiło konkretną zmianę: zamiast pytać „kto ma dostęp do bazy”, pytamy „kto odpowiada za ten dostęp i kiedy go ostatnio potwierdził”.
Segmentacja była w firmie od dawna, ale reguły między strefami powstawały przy okazji kolejnych projektów i nikt ich później nie porządkował. Efekt był przewidywalny: kilkanaście reguł „any-any” w miejscach, gdzie wystarczyłby jeden konkretny port. Po przeglądzie zamknęliśmy większość z nich, zostawiając wyjątki tylko tam, gdzie zespół potrafił uzasadnić potrzebę.
Najwięcej pracy zajęło nie samo zamknięcie reguł, a ustalenie, kto może je otwierać ponownie. Wprowadziliśmy krótki formularz z uzasadnieniem i terminem ważności — reguła wygasa po 90 dniach, jeśli nikt jej nie odnowi. To prosty mechanizm, ale skutecznie ogranicza nawarstwianie się starych wpisów.
Przed przeglądem zbieraliśmy praktycznie wszystko, co dało się zbieraliśmy. Po analizie okazało się, że ponad połowa zdarzeń nigdy nie została przejrzana, a zespół reagował tylko na alerty z kilku źródeł. Zamiast dokładać kolejne narzędzia, zawęziliśmy zakres: uwierzytelnienia do systemów wewnętrznych, ruch wychodzący do nieznanych adresów i zmiany w uprawnieniach.
To nie znaczy, że reszta logów zniknęła — nadal są archiwizowane na wypadek dochodzenia. Zmienił się priorytet: to, co trafia do kolejki analityka, ma konkretny powód, a nie tylko „bo się zalogowało”.
Nie wszystko udało się domknąć. Wdrożenie uwierzytelniania wieloskładnikowego dla kont technicznych nadal jest w zawieszeniu, bo wymaga zmiany sposobu działania skryptów wdrożeniowych. Podobnie z przeglądem dostępu partnerów zewnętrznych — tu brakuje osoby, która po stronie biznesu potwierdzi, kto realnie potrzebuje dostępu do środowiska testowego.
Z perspektywy trzech miesięcy najważniejsza zmiana nie dotyczyła technologii. Dotyczyła tego, że przegląd przestał być jednorazowym wydarzeniem, a stał się cyklem z właścicielami i terminami. Reszta to konsekwencja.
Trzy wpisy z naszej redakcji — każdy o innym etapie pracy nad ochroną danych w firmie technologicznej. Bez ogólników, z konkretnym kontekstem i tym, co warto sprawdzić u siebie.
A concrete post with a clear subject and real-world context.
This page frames a concrete subject instead of using a generic heading. It explains what is being considered, why it matters in the site's context, and what detail a reader can expect next. The copy is intentionally plain and specific, so it reads like a real content item.
Czytaj wpis
A focused post built around practical decisions and constraints.
This item focuses on practical use, tradeoffs, and decisions that a reader may recognize. It avoids broad promotional claims and keeps the topic tied to a clear situation. The description gives enough substance for a real page rather than a placeholder card.
Czytaj wpis
A grounded post that adds a different angle without repeating the others.
This page gives the third item its own reason to exist. It covers a separate angle, includes concrete context, and avoids repeating the same promise in different words. The result should feel like a planned article, project, review, or offer.
Czytaj wpis