Eksperci bezpieczeństwa potrzebowali tylko hasła „123456”, żeby uzyskać dostęp do danych osobowych 64 milionów kandydatów do pracy w systemie rekrutacyjnym McDonald’s.
Incydent w platformie McHire ujawnił słabe hasło na nieaktywnym koncie testowym oraz błąd autoryzacji API, który otwierał dostęp do danych kandydatów. Dla organizacji wdrażających AI oznacza to konieczność weryfikacji rzeczywistych zabezpieczeń dostawcy, niezależnie od posiadanych certyfikatów.
Dwa podstawowe błędy otworzyły dostęp do danych kandydatów
Badacze bezpieczeństwa Ian Carroll i Sam Curry przeanalizowali platformę McHire używaną przez franczyzobiorców McDonald’s. System prowadzi kandydatów przez rekrutację przy pomocy asystentki Olivia, stworzonej przez Paradox.ai. Olivia zbiera dane kontaktowe, informacje o dostępności i odpowiedzi udzielane podczas procesu rekrutacyjnego.
Badacze znaleźli panel logowania przeznaczony dla pracowników Paradox.ai. Wpisali „123456” jako nazwę użytkownika i hasło. Dane logowania zapewniły im dostęp do starego konta testowego, które według Paradox nie było używane od 2019 roku. Strona logowania nie wymagała wieloskładnikowego uwierzytelniania (MFA).
Samo konto testowe dawało ograniczony dostęp. Znacznie poważniejszy problem znajdował się w interfejsie programowania aplikacji (API). Endpoint pobierający dane kandydata przyjmował identyfikator lead_id, lecz nie sprawdzał właściwie uprawnień użytkownika do wskazanego rekordu.
Zmiana numeru identyfikatora pozwalała pobierać dane innych osób. Taki błąd określa się jako niebezpieczne bezpośrednie odwołanie do obiektu (IDOR). Badacze uzyskali w ten sposób dostęp do nazwisk, adresów, numerów telefonów, adresów e‑mail, historii formularzy oraz tokenów umożliwiających otwarcie interfejsu kandydata.
Liczba 64 milionów wymaga precyzyjnego wyjaśnienia
Nagłówki dotyczące incydentu często mówią o wycieku danych 64 milionów kandydatów. Dostępne informacje uzasadniają ostrożniejsze sformułowanie.
Identyfikatory rekordów przekraczały 64 miliony. Badacze uznali, że podatny endpoint pozwalał przeglądać zgromadzone interakcje. Paradox wyjaśnił później, że większość tych rekordów nie była powiązana z kandydatami i nie zawierała danych osobowych. Według firmy badacze pobrali siedem rekordów, z których pięć zawierało dane kandydatów ze Stanów Zjednoczonych.
Paradox poinformował również, że nie znalazł dowodów na wcześniejsze wykorzystanie podatności przez inne osoby. Dane nie zostały publicznie opublikowane, a dostawca zamknął dostęp do konta i poprawił endpoint w ciągu kilku godzin od zgłoszenia. Incydent pozostaje więc przypadkiem szerokiej ekspozycji danych, bez potwierdzonego masowego pobrania 64 milionów aplikacji.
Rozróżnienie ma znaczenie dla oceny skutków prawnych i operacyjnych. Możliwość dostępu, liczba podatnych rekordów i rzeczywisty zakres odczytanych danych opisują trzy różne elementy zdarzenia. Raport dla Zarządu i organu nadzorczego powinien przedstawiać je oddzielnie.
Certyfikat potwierdza określony zakres kontroli
Paradox informuje o posiadaniu certyfikatu ISO 27001 oraz raportu SOC 2 Type II. Oba mechanizmy dostarczają wartościowych informacji o systemie zarządzania bezpieczeństwem i działaniu wybranych kontroli. Ich znaczenie zależy jednak od zakresu audytu, okresu badania, przyjętych kryteriów oraz systemów objętych oceną.
Certyfikat ISO 27001 potwierdza funkcjonowanie systemu zarządzania bezpieczeństwem informacji w zadeklarowanym zakresie. Organizacja określa ten zakres, aktywa, lokalizacje i procesy. Standard dopuszcza również akceptację części ryzyka, jeżeli organizacja uzasadni decyzję.
Raport SOC 2 Type II ocenia projekt i działanie określonych kontroli w przyjętym okresie. Raport może wykazać, że proces zarządzania kontami istnieje i działa dla badanej próby. Nadal może pominąć pojedyncze konto testowe, pozostawione poza standardowym cyklem przeglądu.
Paradox przyznał, że wcześniejsze testy penetracyjne nie wykryły podatnego endpointu. Firma wskazała również, że konto testowe powinno zostać wcześniej wycofane. Obie informacje pokazują ograniczenia kontroli działających na podstawie prób, okresowych przeglądów i przyjętego zakresu technicznego.
Certyfikat pozostaje jednym z dowodów w ocenie dostawcy. Decyzja o dopuszczeniu systemu do danych kandydatów wymaga również analizy architektury, kontroli dostępu, cyklu życia kont, zabezpieczeń API oraz wyników testów technicznych.
Źródłem incydentu był cykl życia konta i błędna autoryzacja
Pierwsza luka powstała w procesie zarządzania tożsamością. Konto testowe pozostawało aktywne przez kilka lat, używało łatwych do odgadnięcia danych logowania i nie wymagało MFA. Organizacja utraciła kontrolę nad zasobem, który przestał pełnić uzasadnioną funkcję biznesową.
Proces zarządzania kontami powinien obejmować właściciela, przeznaczenie, termin przeglądu i warunki automatycznego wyłączenia. Konta testowe, serwisowe i techniczne wymagają tych samych zasad. Ich niewielka widoczność często zwiększa czas pozostawania poza kontrolą.
Druga luka dotyczyła autoryzacji na poziomie obiektu. System uwierzytelnił użytkownika, lecz nie sprawdził jego prawa do konkretnego rekordu. Posiadanie aktywnej sesji otwierało więc drogę do danych przypisanych innym restauracjom i kandydatom.
Testy bezpieczeństwa API powinny sprawdzać każdą operację na danych z perspektywy różnych ról. Zmiana identyfikatora rekordu stanowi jedno z podstawowych badań. Wymaga małego nakładu pracy, a może ujawnić dostęp do całego zbioru.
AI zwiększyła skalę przetwarzania klasycznego błędu
Podatność McHire nie wynikała z zachowania modelu językowego. Badacze próbowali wcześniej zastosować wstrzyknięcie polecenia (prompt injection), lecz nie uzyskali w ten sposób użytecznego dostępu. Drogę do danych otworzyły słabe dane logowania i wadliwa autoryzacja API.
Znaczenie AI wynika z roli platformy w procesie rekrutacyjnym. System gromadził dane kontaktowe, odpowiedzi kandydatów, preferencje dotyczące czasu pracy i historię kolejnych etapów. Automatyzacja pozwoliła przetwarzać te informacje na dużą skalę oraz przechowywać je w jednym środowisku.
System rekrutacyjny oparty na AI łączy ryzyko cyberbezpieczeństwa, ochrony danych, praw kandydatów i zależności od dostawcy. Organizacja powinna więc oceniać pełny proces. Analiza samego modelu lub chatbota pozostawia poza zakresem konta administratorów, integracje, interfejsy API i bazy danych.
Bezpieczeństwo AI zaczyna się od tych samych fundamentów co bezpieczeństwo każdego systemu informacyjnego. Obejmuje zarządzanie dostępem, minimalizację danych, rejestrowanie zdarzeń, testy autoryzacji, zarządzanie podatnościami i wycofywanie zbędnych zasobów.
RODO wymaga oceny realnych środków bezpieczeństwa
W przypadku przetwarzania danych osób w Unii Europejskiej organizacja musi ustalić role administratora i podmiotu przetwarzającego. Administrator odpowiada za wybór dostawcy zapewniającego wystarczające gwarancje wdrożenia odpowiednich środków. Umowa powierzenia stanowi element tego procesu, lecz nie zastępuje oceny zabezpieczeń.
Artykuł 32 RODO wymaga środków odpowiednich do ryzyka. Ocena powinna uwzględniać charakter danych, zakres przetwarzania, prawdopodobieństwo naruszenia i możliwe skutki dla kandydatów. Dane kontaktowe połączone z informacją o poszukiwaniu pracy mogą wspierać wiarygodny phishing rekrutacyjny lub próbę wyłudzenia danych potrzebnych do wypłaty wynagrodzenia.
RODO przewiduje administracyjne kary pieniężne do 20 milionów euro lub czterech procent światowego obrotu przedsiębiorstwa. Kwota ta stanowi górną granicę dla określonych naruszeń. Organ uwzględnia między innymi skalę zdarzenia, winę, podjęte działania, współpracę oraz kategorie danych.
Przychody McDonald’s Corporation za 2024 rok wyniosły 25,92 miliarda dolarów. Proste przemnożenie tej wartości przez cztery procent daje ponad miliard dolarów. Wynik przedstawia wyłącznie matematyczny limit oparty na przychodach spółki. Nie stanowi prognozy kary ani oceny odpowiedzialności konkretnego podmiotu.
AI Act obejmuje część systemów rekrutacyjnych
Załącznik III do AI Act obejmuje systemy wykorzystywane do rekrutacji i selekcji osób, w szczególności do analizy i filtrowania aplikacji oraz oceny kandydatów. Klasyfikacja zależy od przeznaczenia systemu i jego wpływu na decyzję. Narzędzie ograniczone do prostych czynności pomocniczych może spełnić przesłanki wyłączenia przewidziane w artykule 6 ustęp 3.
System wysokiego ryzyka wymaga między innymi zarządzania ryzykiem, dokumentacji technicznej, rejestrowania zdarzeń, nadzoru człowieka oraz odpowiedniego poziomu dokładności, odporności i cyberbezpieczeństwa. Obowiązki rozkładają się pomiędzy dostawcę, podmiot stosujący, importera i dystrybutora. Rola organizacji zależy więc od sposobu zakupu, konfiguracji i wykorzystania narzędzia.
AI Act przewiduje kary do 15 milionów euro lub trzech procent światowego obrotu za naruszenie wybranych obowiązków dotyczących operatorów systemów. Górna granica nie oznacza automatycznego zastosowania maksymalnej kwoty. Znaczenie mają rodzaj obowiązku, rola podmiotu i stan prawny obowiązujący w chwili zdarzenia.
Na dzień 20 lipca 2026 roku tekst AI Act przewiduje stosowanie większości przepisów od 2 sierpnia 2026 roku. Komisja Europejska informuje równocześnie o politycznym porozumieniu dotyczącym przesunięcia obowiązków dla systemów wysokiego ryzyka w zatrudnieniu na 2 grudnia 2027 roku. Organizacje powinny śledzić formalne przyjęcie zmian i zachować gotowość wobec obowiązującego tekstu rozporządzenia.
DORA i NIS2 wzmacniają nadzór nad dostawcami
Zakres DORA obejmuje podmioty finansowe oraz ich zarządzanie ryzykiem ICT. Dla banku, ubezpieczyciela lub instytucji płatniczej korzystającej z podobnej platformy McHire stanowi przykład ryzyka zewnętrznego dostawcy technologii. Znaczenie systemu zależy od wspieranej funkcji, rodzaju danych i wpływu niedostępności lub naruszenia na działalność podmiotu.
DORA wymaga zarządzania ryzykiem dostawców ICT jako częścią ram zarządzania ryzykiem ICT. Podmiot finansowy zachowuje odpowiedzialność za zgodność również wtedy, gdy korzysta z zewnętrznej usługi. Ocena przed zawarciem umowy powinna uwzględniać koncentrację, możliwość audytu, lokalizację danych, podwykonawców i strategie wyjścia.
NIS2 nakłada na podmioty objęte dyrektywą obowiązek stosowania środków bezpieczeństwa łańcucha dostaw. Zarząd zatwierdza środki zarządzania ryzykiem i nadzoruje ich wdrożenie. Ocena dostawcy powinna więc obejmować jakość jego praktyk bezpieczeństwa, podatności produktów oraz sposób reagowania na incydenty.
DORA, NIS2 i AI Act mają różne zakresy. Łączy je odpowiedzialność organizacji za sposób wyboru, wdrożenia i nadzorowania technologii. Przekazanie procesu zewnętrznemu dostawcy nie przenosi całego ryzyka poza organizację.
Audyt dostawcy AI powinien obejmować sześć obszarów
1. Zakres certyfikacji
Organizacja powinna uzyskać certyfikat, deklarację stosowania oraz opis zakresu systemu zarządzania. W przypadku SOC 2 znaczenie ma pełny raport, okres badania, opinia audytora i wyjątki wskazane podczas testowania. Sam znak graficzny na stronie dostawcy nie pozwala ocenić, czy usługa objęta umową znalazła się w zakresie badania.
2. Cykl życia tożsamości
Audyt powinien sprawdzić tworzenie, zatwierdzanie, przegląd i wyłączanie kont. Osobnej kontroli wymagają konta testowe, awaryjne, serwisowe i techniczne. Organizacja powinna poznać zasady MFA, przechowywania sekretów oraz okresowych przeglądów uprawnień.
3. Autoryzacja interfejsów API
Test techniczny powinien obejmować kontrolę dostępu do każdego obiektu i każdej operacji. Zespół powinien sprawdzić zmianę identyfikatorów, eskalację uprawnień i dostęp między klientami. Dotyczy to również funkcji dostępnych wyłącznie z panelu administracyjnego.
4. Przepływ danych
Organizacja powinna znać źródła danych, miejsca przechowywania, odbiorców i okresy retencji. Analiza musi obejmować dostawcę modelu, usługi chmurowe, narzędzia analityczne oraz pozostałych podwykonawców. Wynik powinien wskazywać możliwość usunięcia danych i wykonania praw osób, których dane dotyczą.
5. Reagowanie na podatności
Umowa powinna określać sposób zgłaszania podatności, czas potwierdzenia i termin usunięcia problemu. Dostawca powinien posiadać dostępny kanał kontaktu dla badaczy. Program zarządzania podatnościami powinien obejmować testy, aktualizacje, analizę przyczyn i weryfikację poprawek.
6. Niezależna weryfikacja
System przetwarzający dane kandydatów wymaga testu adekwatnego do skali ryzyka. Zakres może obejmować test penetracyjny, przegląd architektury, analizę konfiguracji lub ćwiczenie zespołu czerwonego (red team). Organizacja powinna otrzymać wyniki, terminy działań i potwierdzenie usunięcia ustaleń.
Zarząd potrzebuje informacji o kontroli, a nie listy certyfikatów
Raport dla Zarządu powinien wskazywać dane przekazywane dostawcy, funkcje wspierane przez system oraz skutki jego naruszenia. Powinien również przedstawiać zakres certyfikacji, wynik testów, najważniejsze luki i ryzyko pozostające po wdrożeniu zabezpieczeń.
Każda luka wymaga właściciela, terminu i kryterium zamknięcia. Ryzyko zaakceptowane powinno zawierać uzasadnienie biznesowe oraz datę ponownego przeglądu. Tak przygotowana dokumentacja wspiera decyzje Zarządu i pozostaje użyteczna podczas audytu.
W projektach Davidson Consulting zaczynamy ocenę dostawcy od funkcji biznesowej oraz danych powierzanych systemowi. Następnie sprawdzamy dowody potwierdzające działanie konkretnych środków kontroli. Takie podejście pozwala odróżnić formalne zapewnienia od zabezpieczeń działających w środowisku produkcyjnym.
Certyfikat dostarcza dowodu, audyt określa jego znaczenie
Incydent McHire wynikał z dwóch błędów znanych od wielu lat. Stare konto testowe zachowało aktywne uprawnienia, a API nie sprawdzało dostępu do poszczególnych rekordów. Certyfikaty i wcześniejsze testy nie objęły skutecznie obu elementów.
Organizacja wdrażająca system AI powinna oceniać dostawcę przez pryzmat konkretnej usługi, danych i zależności operacyjnych. Certyfikat może zmniejszyć zakres dalszych prac, lecz nie powinien zamykać analizy. Im większa skala automatyzacji, tym wyższa wartość niezależnego sprawdzenia zabezpieczeń.
Koszt takiej weryfikacji pozostaje przewidywalny. Koszt incydentu obejmuje reakcję techniczną, obsługę prawną, komunikację, roszczenia i możliwe postępowania nadzorcze. Rezygnacja z testu w celu oszczędności może więc szybko stać się skórką za wyprawkę.
FAQ
Czy certyfikat ISO 27001 potwierdza bezpieczeństwo konkretnego systemu?
Certyfikat potwierdza działanie systemu zarządzania w określonym zakresie. Ocena konkretnej aplikacji wymaga sprawdzenia zakresu certyfikacji, architektury, konfiguracji i wyników testów technicznych.
Czy każda platforma rekrutacyjna oparta na AI jest systemem wysokiego ryzyka?
Klasyfikacja zależy od przeznaczenia i wpływu systemu na decyzje rekrutacyjne. Narzędzia analizujące, filtrujące lub oceniające kandydatów mogą podlegać przepisom dotyczącym wysokiego ryzyka.
Czy DORA obejmuje system rekrutacyjny?
DORA obejmuje podmioty sektora finansowego i ich ryzyko ICT. Znaczenie konkretnej platformy zależy od funkcji, danych i wpływu zakłócenia na działalność podmiotu finansowego.
Kto odpowiada za bezpieczeństwo systemu dostawcy?
Odpowiedzialność rozkłada się zgodnie z rolami prawnymi i umownymi. Organizacja korzystająca z usługi nadal odpowiada za dobór dostawcy, ocenę ryzyka i nadzorowanie powierzonych procesów.
Jak często należy ponawiać ocenę dostawcy AI?
Ocena powinna odbywać się przed zawarciem umowy oraz po znaczącej zmianie usługi, architektury, podwykonawców lub zakresu danych. Częstotliwość przeglądów powinna odpowiadać poziomowi ryzyka.
Źródła
Ian Carroll i Sam Curry, „Would you like an IDOR with that? Leaking 64 million McDonald’s job applications”, 2025.
Paradox, „Responsible Security Update”, 2025.
Paradox, informacje dotyczące bezpieczeństwa oraz certyfikatów ISO 27001 i SOC 2 Type II.
McDonald’s Corporation, „2024 Annual Report” oraz wyniki za 2024 rok.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679, RODO.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554, DORA.
Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555, NIS2.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689, AI Act.
