Wprowadzenie do problemu / definicja
Architektura Zero Trust opiera się na zasadzie braku domyślnego zaufania wobec użytkowników, urządzeń i sesji. W praktyce wiele organizacji skupia się jednak na ochronie aktywnych kont oraz egzekwowaniu polityk dostępowych już po uruchomieniu tożsamości, pomijając etap jej początkowego ustanowienia. To właśnie w chwili zatrudnienia, aktywacji konta, rejestracji metod MFA i wydania urządzenia może powstać krytyczna luka bezpieczeństwa.
Problem ten bywa określany jako luka „day-one”, ponieważ dotyczy pierwszego dnia funkcjonowania nowej tożsamości w środowisku organizacji. Jeśli napastnik zdoła przejść proces rekrutacyjny lub zmanipuluje procedury service desku, może uzyskać legalnie utworzone konto, skonfigurowane silne uwierzytelnianie i dostęp do zasobów firmy.
W skrócie
Luka „day-one” polega na tym, że organizacja wdraża dojrzałe mechanizmy Zero Trust, ale nie stosuje równie rygorystycznej weryfikacji tożsamości na etapie onboardingu. W efekcie zabezpieczenia chronią już istniejącą tożsamość, lecz nie potwierdzają wystarczająco, czy nowa osoba rzeczywiście powinna taką tożsamość otrzymać.
- atakujący nie musi kraść konta, jeśli organizacja sama je utworzy,
- MFA i polityki dostępu mogą działać poprawnie, ale dla błędnie zweryfikowanej osoby,
- problem dotyczy bootstrappingu zaufania, czyli pierwszego ustanowienia poświadczeń,
- największe ryzyko pojawia się przy zdalnym zatrudnianiu i zautomatyzowanych procesach HR-to-IT.
Kontekst / historia
W ostatnich latach wzrosło zainteresowanie scenariuszami, w których fałszywe lub skradzione tożsamości są wykorzystywane do uzyskania zatrudnienia zdalnego albo dostępu do systemów przedsiębiorstw. To zmienia klasyczny model zagrożeń. W tradycyjnym scenariuszu napastnik przejmuje poświadczenia prawdziwego użytkownika. W modelu „day-one” organizacja sama tworzy tożsamość dla osoby, która nie powinna jej otrzymać.
Taka zmiana jest szczególnie istotna w środowiskach rozproszonych, gdzie onboarding przebiega szybko, wiele etapów realizowanych jest zdalnie, a decyzje opierają się na ograniczonym zestawie danych. Im mniej niezależnych punktów weryfikacji przed wydaniem konta, tym większa szansa, że błąd popełniony na początku zostanie później uznany przez systemy bezpieczeństwa za stan prawidłowy.
Analiza techniczna
Od strony technicznej problem nie wynika z samego istnienia MFA, passkey czy polityk warunkowego dostępu. Kluczowe znaczenie ma moment ich inicjalizacji. Dla aktywnego pracownika organizacja posiada zwykle historię logowań, wcześniej zarejestrowane urządzenia, znane metody uwierzytelniania i dodatkowe sygnały kontekstowe. W przypadku nowej osoby taki zestaw zaufanych atrybutów jeszcze nie istnieje.
To oznacza, że service desk lub zespół odpowiedzialny za onboarding musi podjąć decyzję wysokiego ryzyka przy ograniczonym kontekście. Jeśli weryfikacja opiera się na rozmowie telefonicznej, wiadomości e-mail, podstawowych danych osobowych lub dokumentach bez rzetelnej walidacji, napastnik może skutecznie przejść proces ustanawiania zaufania.
Po pozytywnej decyzji dalsze działania zazwyczaj przebiegają zgodnie z procedurą:
- tworzone jest konto w systemie tożsamości,
- przekazywane są dane startowe lub link aktywacyjny,
- rejestrowane są metody MFA,
- przypisywane są role i uprawnienia,
- konfigurowane jest urządzenie lub dostęp do aplikacji SaaS.
Z punktu widzenia narzędzi bezpieczeństwa wszystko wygląda poprawnie, ponieważ konto zostało utworzone legalnie i zgodnie z workflow. To właśnie sprawia, że późniejsze mechanizmy detekcji mogą mieć ograniczoną skuteczność: problemem nie jest obejście zabezpieczeń, lecz błędne ustanowienie zaufanej tożsamości źródłowej.
Konsekwencje / ryzyko
Skutki takiego incydentu mogą być poważne, ponieważ napastnik uzyskuje pełnoprawny dostęp wewnętrzny jako użytkownik postrzegany przez systemy jako legalny. Może to obejmować pocztę, komunikatory, repozytoria kodu, systemy HR, zasoby chmurowe, narzędzia administracyjne i platformy współpracy.
- trwałe osadzenie napastnika w środowisku jako „prawidłowego” użytkownika,
- ominięcie klasycznych mechanizmów wykrywania kradzieży poświadczeń,
- większa skuteczność działań przypominających aktywność insidera,
- możliwość dalszej eskalacji uprawnień po zakończeniu onboardingu,
- utrudnione dochodzenie powłamaniowe i analiza przyczyn incydentu.
Szczególnie narażone są organizacje korzystające z outsourcingu service desku, zatrudniające dużą liczbę kontraktorów lub automatyzujące łańcuch HR-to-IT. W takich środowiskach presja szybkości często osłabia kontrolę jakości procesu weryfikacji tożsamości.
Rekomendacje
Firmy powinny traktować pierwszy dzień życia tożsamości jako osobną strefę ryzyka w modelu Zero Trust. Ochrona tego etapu wymaga nie tylko silnego uwierzytelniania, ale przede wszystkim wiarygodnego potwierdzenia, że osoba otrzymująca konto rzeczywiście jest tą, za którą się podaje.
- wdrożenie formalnego procesu identity proofing przed wydaniem poświadczeń,
- walidacja dokumentów tożsamości z użyciem mechanizmów wykrywania fałszerstw,
- stosowanie kontroli żywotności biometrycznej tam, gdzie jest to uzasadnione,
- rozdzielenie rekrutacji, potwierdzenia tożsamości i aktywacji dostępu,
- nadawanie minimalnych uprawnień do czasu pełnej weryfikacji,
- wymuszenie phishing-resistant MFA w kontrolowanym procesie,
- dodatkowa autoryzacja działań service desku wobec nowych pracowników,
- pełne logowanie i audyt onboardingu oraz resetów metod uwierzytelniania,
- analiza sygnałów ryzyka, takich jak geolokalizacja, urządzenie i reputacja sieci,
- regularne testy procedur onboardingowych w ramach ćwiczeń red team i tabletop.
Najważniejsza zmiana podejścia polega na przesunięciu akcentu z pytania o poprawność logowania na pytanie, czy organizacja ma wystarczające podstawy, by w ogóle utworzyć dane konto. To właśnie na tym etapie Zero Trust może zostać wzmocnione lub podważone.
Podsumowanie
Luka „day-one” pokazuje, że skuteczność Zero Trust zależy nie tylko od MFA, polityk dostępu i monitoringu sesji, lecz także od jakości pierwszej weryfikacji tożsamości. Jeśli organizacja błędnie ustanowi zaufanie podczas onboardingu, wszystkie kolejne warstwy ochrony będą działały na fałszywych założeniach.
Bezpieczeństwo tożsamości powinno więc zaczynać się jeszcze przed pierwszym logowaniem. Dopiero połączenie identity proofing, kontrolowanego wydawania poświadczeń i ścisłego audytu procesu aktywacji może ograniczyć ryzyko, że legalne konto stanie się furtką dla nieautoryzowanego dostępu.