Najgroźniejsza luka w Salesforce? Nie w platformie, a w Twoich integracjach

Wycieka 75,1 mln rekordów powiązanych z danymi Salesforce, a jednocześnie firma zapewnia, że atak nie dotknął krytycznych systemów. Brzmi absurdalnie? Właśnie takie sytuacje – jak incydent w Loblaw (Dark Web Informer) – pokazują największą nieoczywistą prawdę o bezpieczeństwie: najgroźniejsza luka w Twoim orgu Salesforce zwykle nie jest w samym Salesforce, ale w tym, co do niego podłączyłeś. Dlaczego integracje i Connected Apps stały się głównym wektorem ryzyka oraz co praktyk w Polsce powinien zrobić już dziś, aby uniknąć powtórki z Odido czy Loblaw.

Ukryta warstwa ryzyka: Connected Apps i integracje, których nikt nie kontroluje

Incydent Loblaw pokazuje skalę, jakiej wcześniej nie widzieliśmy: 75,1 mln rekordów powiązanych z Salesforce, 55,3 mln rekordów SFMC, 19,3 mln tożsamości z Oracle IDCS (źródło: Dark Web Informer). To nie jest atak na jedną aplikację, tylko na cały ekosystem, w którym CRM jest węzłem integracyjnym. W polskich orgach wygląda to podobnie: do Salesforce podłączonych jest zwykle od 20 do 80 systemów – od e-commerce po aplikacje terenowe. Problem polega na tym, że większość z nich ma stałe tokeny, szerokie zakresy OAuth i brak monitoringu w czasie rzeczywistym.

Technicznie Connected App to tylko deklaracja dostępu. Prawdziwym zagrożeniem jest to, że jej access token często żyje miesiącami. Co gorsza, tokeny wciąż bywają przechowywane w kodzie, w CI/CD albo w plikach konfiguracyjnych na serwerach dostawców. To oznacza, że wyciek jak w Loblaw może nie dotyczyć bezpośrednio Salesforce, ale nadal prowadzić do masowego wyciągnięcia danych z CRM.

Implikacja jest prosta: jeśli masz org z dużą liczbą integracji, to musisz założyć, że najsłabsze ogniwo znajduje się poza Salesforce. W Polsce dotyczy to zwłaszcza firm handlowych, które integrują SF z legacy ERP lub platformami e-commerce. Warto w tym miejscu spojrzeć na realny przykład ryzyka z rodzimego rynku opisany w incydencie Odido, który pokazuje, jak łatwo zhakować integrację poprzez phishing.

Ten trend nie zniknie. Wraz z rosnącą liczbą mikroserwisów i agentów AI korzystających z API CRM, liczba Connected Apps rośnie wykładniczo. To oznacza, że bez twardego governance każdy org zamienia się w niekontrolowaną sieć połączeń, gdzie trudno wskazać, kto naprawdę ma dostęp do czego.

Mechanika ataku: jak złamanie systemu zewnętrznego prowadzi do przejęcia CRM

Większość praktyków Salesforce wciąż myśli o bezpieczeństwie w perspektywie: role, profile, FLS, encryption. Ale atakujący nie wchodzi od frontu. Wejście jest dużo prostsze: wyciągnięcie access tokena systemu, który łączy się z Salesforce. W przypadku wielu rynków – w tym polskiego – są to często platformy loyalty, aplikacje mobilne, systemy marketing automation lub integracje budowane na szybko przez lokalnych vendorów.

Technicznie wygląda to tak: jeśli atakujący przejmie dostęp do serwera integracji, może natychmiast zacząć wykonywać API calls w imieniu tej aplikacji. I jeśli Connected App ma uprawnienia broad-scoped, np. full API, to atakujący może ściągnąć wszystkie rekordy kontaktów, leadów, a nawet dane transakcyjne backupowane w Big Objects. Z perspektywy Salesforce API to „legalny” ruch – nie ma żadnych anomalii poza nagłym wzrostem wolumenu.

To problem, który świetnie ilustruje wniosek płynący z analizy naruszeń BeyondTrust, opisanej na Coffeeforce w kontekście architektury integracji. W obu przypadkach wektor ataku był poza CRM, ale skutki uderzyły w CRM. To dokładnie ten sam wzorzec, który widzimy w Loblaw.

Dla praktyków oznacza to obowiązek zmiany podejścia: nie zabezpieczamy wyłącznie orga, ale cały łańcuch zależności. Bo jeśli jeden vendor trzyma refresh token w logach, to nie masz już orga, tylko otwartą bazę klientów.

Architektura bezpieczeństwa: co trzeba zmienić w polskich orgach Salesforce

Większość orgów w Polsce działa według schematu: jeden principal integration user, kilkanaście Connected Apps, żaden realny monitoring. Taki model przestaje być utrzymywalny. Wyciek Loblaw pokazuje, że atakujący nie musi łamać CRM, by wyciągnąć CRM. Dlatego fundamentem powinna być segmentacja integracji – dedykowani integration users z minimalnymi uprawnieniami, podział per aplikacja, odcięcie możliwości wykonywania zapytań SOQL full-export.

Kolejnym krokiem jest rotacja tokenów i enforce token expiration. Wiele systemów legacy w Polsce oczekuje tokenu „wiecznego”. Trzeba je migrować, bo inaczej nie spełniają nawet minimalnych standardów RODO. Warto też wprowadzić API monitoring oparty o behavioral anomaly detection. W ekosystemie Salesforce pojawiają się już narzędzia, które to ułatwiają – między innymi rozwiązania oparte na automatyzacjach Agentforce, analizowane przez nas w kontekście nowego Security Center.

Perspektywicznie ataki będą coraz bardziej skierowane na integracje AI i automatyzacje MCP/Agentforce. Każdy dodatkowy agent AI to dodatkowy vektor OAuth. Org, który nie ma governance na Connected Apps, będzie miał jeszcze większy chaos, gdy agentów w procesach pojawi się kilkanaście lub kilkadziesiąt.

Strategia na 30 dni: realna checklista zabezpieczeń dla praktyków Salesforce

Największy problem w bezpieczeństwie Salesforce nie polega na braku narzędzi, ale na tym, że nikt nie ma czasu na audyt integracji. Dlatego poniżej spójna, 30-dniowa strategia wdrożeniowa, oparta na incydentach Loblaw, BeyondTrust i Odido.

Lista działań: identyfikacja wszystkich Connected Apps, podział na aktywne i nieużywane, usunięcie aplikacji o nieznanym pochodzeniu, wprowadzenie approval flow dla nowych integracji, forcing minimal scopes OAuth, rotacja refresh tokenów; osobne konta integration user dla każdej aplikacji; włączenie zapisów i alertów API Event Monitoring; analiza SOQL-heavy calls; wdrożenie API call throttling; przegląd logiki integracji z zewnętrznymi vendorami w kontekście RODO. To praca, którą realnie można zamknąć w miesiąc.

Trend na kolejny rok jest jasny: to nie userzy są największym zagrożeniem, tylko integracje. A wraz z eksplozją AI w CRM liczba tych integracji urośnie jeszcze szybciej. Bez governance polskie orgi wejdą w 2027 rok z technicznym i prawnym długiem nie do utrzymania.

Wnioski końcowe: Incydent Loblaw nie dotyczy bezpośrednio Salesforce, ale pokazuje coś groźniejszego: CRM stał się centralnym węzłem ataku, nawet jeśli nie jest pierwotnie złamany. Dla polskich praktyków oznacza to konieczność traktowania Connected Apps i integracji jako krytycznej powierzchni bezpieczeństwa, nie dodatku. Kluczowe pytanie brzmi: czy w Twoim orgu wiesz dokładnie, które aplikacje mają dostęp do danych klientów i kto naprawdę kontroluje ich tokeny?