Wycieki powiązane z Salesforce: lekcja dla adminów

2,3 GB danych Udemy, 12,8 GB danych 7-Eleven i 192 GB danych wiązanych z Zara trafiło do publikacji po roszczeniach grupy ShinyHunters o dostęp do rekordów Salesforce i systemów cloud.

Dla praktyków Salesforce najważniejsze nie jest dziś samo nazwisko atakującego, ale wzorzec incydentu: dane mają pochodzić nie tylko z CRM, lecz także z połączonych usług analitycznych i środowisk chmurowych (Hackread). To oznacza, że ocena ryzyka nie może kończyć się na konfiguracji orga, profilach i MFA. W 2026 realnym polem ataku staje się cały łańcuch dostępu do danych – od Salesforce po konektory, platformy analityczne i zewnętrzne usługi, które dziedziczą uprawnienia lub kopie rekordów.

Co wiemy o wyciekach i dlaczego sam org to za mało

W opublikowanych listingach pojawiają się trzy znane marki: Udemy, 7-Eleven i Zara. Dla Udemy mowa o 2,3 GB danych, w tym o ponad 1,4 mln rekordów Salesforce zawierających dane osobowe i informacje wewnętrzne. W przypadku 7-Eleven pada liczba 12,8 GB oraz ponad 600 tys. rekordów Salesforce. Zara wyróżnia się innym wektorem – listing wskazuje 192 GB danych z BigQuery oraz powiązanie z Anodot, czyli usługą analityczną działającą jako element szerszego ekosystemu danych.

Na moment publikacji żadna z tych firm publicznie nie potwierdziła incydentu. Z punktu widzenia architekta, admina czy security ownera ważniejsze od potwierdzenia medialnego jest jednak to, jak wygląda model zagrożenia. Jeżeli atakujący rzeczywiście uzyskują dostęp do rekordów Salesforce albo do ich kopii w systemach zewnętrznych, to klasyczne myślenie w stylu „mamy dobrze ustawione role i IP ranges” przestaje wystarczać. Dane żyją dziś równolegle w CRM, warstwie raportowej, hurtowniach, narzędziach do analityki behawioralnej i usługach integracyjnych.

To właśnie dlatego warto zestawić ten przypadek z wcześniejszymi obserwacjami dotyczącymi phishingu i przejęć dostępu do orgów, opisanymi w analizie ataku na Odido i słabości zabezpieczeń wokół Salesforce. Nawet jeśli punkt wejścia nie znajduje się bezpośrednio w samym orgu, konsekwencja biznesowa pozostaje podobna – wyciek rekordów klientów, danych operacyjnych i informacji wewnętrznych.

Dla polskich zespołów oznacza to konieczność aktualizacji mapy danych. Trzeba wiedzieć nie tylko, jakie obiekty są przechowywane w Salesforce, ale też gdzie te dane są replikowane, eksportowane lub analizowane. Bez tego nie da się rzetelnie ocenić skutków incydentu ani przygotować sensownego planu ograniczenia szkód.

Jak działa ten wzorzec ataku: cloud, partnerzy i rozszerzony obwód zaufania

ShinyHunters jest łączony z koncentracją na usługach cloud i integracjach third-party. W tym przypadku szczególnie istotne jest powiązanie z Anodot przy wycieku dotyczącym Zara. To sugeruje scenariusz, w którym dostęp do jednej usługi analitycznej otwiera drogę do danych przechowywanych lub synchronizowanych w innych środowiskach. W praktyce Salesforce oznacza to problem rozszerzonego obwodu zaufania: aplikacja partnerska, konektor ETL, narzędzie BI albo platforma monitoringu może stać się pośrednią ścieżką do danych klientów.

Taki model ryzyka jest często niedoszacowany, bo zespoły security skupiają się na loginach użytkowników końcowych, a mniej uwagi poświęcają kontom technicznym, tokenom OAuth, Connected Apps, integracjom serwer-serwer i kopiowaniu danych do zewnętrznych repozytoriów. Jeżeli partner ma szeroki zakres uprawnień, to kompromitacja partnera może mieć skutki zbliżone do kompromitacji samego orga.

To podejście dobrze uzupełnia analiza ryzyk wynikających z integracji zewnętrznych wokół Salesforce. Problem nie sprowadza się do jednego produktu, ale do architektury zależności. Im więcej narzędzi pobiera dane z CRM, tym więcej miejsc trzeba objąć monitoringiem, rotacją sekretów i przeglądem uprawnień.

Dodatkowy sygnał ostrzegawczy daje skala aktywności przypisywanej tej grupie. Mowa o około 400 celach związanych ze środowiskami Salesforce oraz publikacji danych co najmniej 42 organizacji. Niezależnie od tego, jak każda z tych spraw wygląda technicznie w szczegółach, kierunek jest jasny: Salesforce bywa traktowany nie jako odizolowany system, ale jako centrum danych o wysokiej wartości, do którego prowadzi wiele ścieżek.

Co z tym zrobić w orgu Salesforce już teraz

Pierwszy krok to inwentaryzacja integracji. Lista aplikacji połączonych z orgiem powinna obejmować nie tylko nazwę dostawcy, ale też zakres danych, model autoryzacji, właściciela biznesowego i technicznego, częstotliwość synchronizacji oraz miejsce docelowego przechowywania danych. Jeżeli zespół nie potrafi odpowiedzieć, które integracje kopiują PII poza Salesforce, to ma lukę governance niezależnie od jakości konfiguracji samej platformy.

Drugi krok to ograniczenie uprawnień. Konta integracyjne nie powinny mieć szerszego dostępu niż wymaga konkretny proces. W praktyce oznacza to przegląd permission sets, polityk OAuth, zakresów API i zasad retencji danych po stronie systemów zewnętrznych. Szczególnie ryzykowne są integracje analityczne, które pobierają duże wolumeny rekordów i utrzymują ich kopie poza kontrolą zespołu CRM.

Trzeci krok to przygotowanie scenariusza incydentowego dla wycieku z partnera. W wielu firmach istnieje plan na przejęcie konta użytkownika, ale nie ma planu na sytuację, w której problem pojawia się w usłudze trzeciej strony. Taki runbook powinien obejmować natychmiastowe wyłączenie integracji, rotację sekretów, analizę zakresu danych, identyfikację obiektów dotkniętych wyciekiem i ocenę obowiązków regulacyjnych. Dobrą ramą do takiego podejścia jest myślenie secure-by-default, rozwinięte w analizie jak budować bezpieczeństwo Salesforce zanim pojawi się incydent.

Czwarty krok to monitoring eksportów i anomalii. Jeżeli organizacja korzysta z dużej liczby integracji, sama kontrola dostępu nie wystarczy. Potrzebne są alerty na nietypowe wolumeny pobrań, nowe lokalizacje użycia tokenów, nagłe zmiany częstotliwości synchronizacji i nietypowe aktywności kont technicznych. W przeciwnym razie wyciek zostanie zauważony dopiero wtedy, gdy dane pojawią się poza organizacją.

Ten przypadek nie dowodzi jeszcze publicznie każdego szczegółu technicznego, ale już teraz pokazuje coś ważniejszego: granica bezpieczeństwa Salesforce przebiega dziś dużo dalej niż ekran logowania do orga. Pytanie dla polskich zespołów brzmi nie tylko „czy nasz org jest zabezpieczony”, ale „czy wiemy, kto i gdzie przetwarza nasze dane po opuszczeniu Salesforce”.