Atak na Odido ujawnia lukę w orgach Salesforce, o której nikt nie mówi

Wycieki danych w Salesforce ponownie trafiają na nagłówki: tym razem to 6 mln rekordów klientów holenderskiego Odido, uzyskanych nie przez złamanie zabezpieczeń platformy, ale przez przejęcie kont pracowników (źródło: NOS). Dla zespołów Salesforce to sygnał alarmowy, bo scenariusz ataku jest dokładnie tym, na co orgi w Polsce są dziś najbardziej podatne: phishing, MFA push fatigue, brak kontroli nad Connected Apps i zbyt szerokie uprawnienia w Service Cloud. Pokazujemy, jak ten incydent zmienia podejście do security w polskich orgach i jakie działania można wdrożyć w ciągu 7 dni, aby zamknąć te same wektory ataku.

Atak nie był technologiczny, tylko procesowy – i to jest największy problem

Według informacji podanych przez NOS, przestępcy uzyskali dostęp do Salesforce poprzez logowanie na konta pracowników contact center, zdobywając hasła przez phishing i następnie wymuszając akceptację MFA, podszywając się pod dział IT (źródło: NOS). To nie jest exploit platformy, co potwierdził Salesforce w oświadczeniu: platforma działała poprawnie i nie odnotowano żadnej podatności. Mechanizm wejścia był klasyczny – credential phishing plus social engineering – ale skutki powstały dopiero po wejściu do Salesforce, gdzie konta miały dostęp do danych milionów klientów.

To właśnie ta architektura uprawnień jest kluczowym elementem, który w polskich orgach często pozostaje nietknięty przez lata. Pracownicy contact center w wielu firmach mają profil z dostępem do Lead, Contact, Case i pełnych danych personalnych bez precyzyjnego podziału obowiązków. Jeden przejęty login może więc oznaczać pełny dump bazy. Salesforce udostępnia mechanizmy jak Field-Level Security, Restriction Rules czy Transaction Policies, ale większość orgów korzysta z nich w minimalnym zakresie. I to jest realny problem.

Z perspektywy trendu widać, że incydenty w Salesforce nie wynikają z luk w platformie, ale z braku odpowiedniego governance wokół kont użytkowników i integracji. To pokrywa się ze wzrostem przypadków opisanych w ostatnim roku, gdzie wyciek pochodził z kont serwisowych lub testowych API. Podobny mechanizm analizowaliśmy także przy fałszywym wycieku NordVPN, w którym to misconfigured dev integracje otwierały ryzyko udostępnienia danych na sandboxach, a nie błędy platformy w analizie sandbox security.

Techniczne fundamenty ataku: MFA nie wystarczy, jeśli to pracownik jest celem

W ataku na Odido MFA nie zostało złamane technicznie – to pracownik zatwierdził fraudowe logowanie. To przykład push bombing, który w ostatnich miesiącach staje się najbardziej skutecznym narzędziem atakujących w enterprise SaaS. Przestępcy proszą pracownika o „akceptację jednorazowego sprawdzenia konfiguracji” i MFA przestaje pełnić rolę bariery. Większość polskich orgów korzysta z prostego MFA typu OTP lub push, które jest najbardziej podatne na takie manipulacje.

Salesforce pozwala jednak na znacznie silniejsze mechanizmy, jak Session Security Policies, ograniczenie dostępów do danych przez Transaction Security oraz blokowanie downloadów danych dla wybranych profili. Mało który zespół w Polsce wykorzystuje te narzędzia, bo nie są one uruchomione domyślnie, a implementacja wymaga zmian w procesach operacyjnych. Efekt jest taki, że org działa natywnie jak system z 2015 roku – MFA + szerokie permission sets + brak alertingu na masowy eksport danych.

To właśnie tu pojawia się przestrzeń, w której Agentforce zaczyna pełnić rolę realnego Security Copilota. Salesforce intensywnie wzmacnia Security Center, dodając mechanizmy automatycznej detekcji anomalii i triage incydentów. Opisywaliśmy to w analizie modernizacji centrum bezpieczeństwa w kontekście Agentforce Security Center. Tego typu narzędzia mogą wykryć masowy eksport zanim dane opuszczą org, ale wymagają wdrożenia polityk i integracji z procesem SOC.

Największe ryzyko w polskich orgach: Connected Apps i brak kontroli API

SF Ben zwrócił uwagę, że admins powinni niezwłocznie przeprowadzić audyt Connected Apps, a to jest być może najtrafniejsza rekomendacja w całym incydencie. W polskich orgach często działa od kilkunastu do kilkudziesięciu aplikacji, o których nikt w firmie nie pamięta. Integracje typu marketing automation, pojedyncze PoC agentów AI, testowe połączenia developerskie – to wszystko mapuje do OAuth scopes, które umożliwiają eksport Lead, Contact lub Case bez interakcji użytkownika.

To właśnie te elementy stanowią punkt wejścia dla shadow AI – setek agentów i aplikacji instalowanych zbyt szybko, bez validacji lub zbyt szerokimi uprawnieniami. Opisywaliśmy te ryzyka w analizie zjawiska agent sprawl w kontekście MuleSoft Agent Fabric w artykule o automatycznym wykrywaniu agentów. Dla wielu orgów to obecnie największe ryzyko – nie przejęcie konta pracownika, ale nieświadomie zainstalowany Connected App mający dostęp do wszystkich rekordów w orgu.

To pokazuje, że bezpieczeństwo Salesforce nie jest już tylko kwestią MFA i roli profili. To pełne zarządzanie ekosystemem aplikacji i agentów, którzy łączą się z orgiem. Brak kontroli oznacza, że incydent może rozpocząć się od kliknięcia w link OAuth, a nie phishingu.

Plan dla polskich orgów: 7 dni na zamknięcie wektorów ataku

Incydent z Odido to moment, w którym wiele firm powinno przerwać bieżące sprinty i wykonać szybki, ale technicznie sensowny audyt. W praktyce 7 dni wystarczy, aby wyeliminować 80 procent ryzyka, bo większość luk pochodzi z prostych błędów w konfiguracji. Pierwszy krok to pełny eksport Connected Apps, analiza OAuth scopes i natychmiastowe wyłączenie aplikacji nieużywanych.

Drugi krok to zawężenie uprawnień dla profili contact center, zwłaszcza dostępu do eksportów danych. Trzeci to aktywacja Data Access Governance w Security Center – nawet jeśli firma nie korzysta z Agentforce, podstawowa analityka dostępów jest dostępna dla wszystkich orgów Enterprise. Na koniec konieczne jest wprowadzenie polityki, w której żaden pracownik nie może zatwierdzić MFA bez zgłoszenia i potwierdzenia w procedurze SOC.

W dłuższej perspektywie ataki social engineering będą tylko rosły, zwłaszcza przy rosnącej liczbie agentów AI i automatyzacji, która podnosi wartość danych. To kierunek, w którym polskie firmy będą musiały inwestować, równolegle z modernizacją architektury danych opisywaną w analizach pokroju Data 360. Governance danych i bezpieczeństwo użytkowników stają się równie ważne jak performance integracji.

W tym kontekście incydent z Odido nie jest problemem holenderskiego operatora – to zapowiedź tego, co może wydarzyć się w każdym orgu, w którym pracownik ma zbyt szerokie uprawnienia i zbyt słabe procesy wokół MFA.

Konkluzja: Ten incydent pokazuje, że bezpieczeństwo Salesforce nie rozbija się o podatności platformy, ale o procesy, które przez lata były odkładane jako mniej priorytetowe. Pytanie dla każdego zespołu w Polsce brzmi: czy przejęcie jednego konta użytkownika pozwoliłoby wykraść połowę waszego CRM, czy zatrzyma się na kilku rekordach? Warto to sprawdzić zanim ktoś zrobi to za was.