Bezpieczeństwo Salesforce w praktyce: co dzieje się, gdy teoria spotyka rzeczywistość?

Bezpieczeństwo danych w Salesforce to temat, o którym wszyscy wiedzą, że jest ważny – ale dopiero w praktyce okazuje się, jak bardzo. W drugiej części rozmowy z Justyną Krajewską, Salesforce MVP i doświadczoną administratorką, schodzimy poziom niżej: z ogólnych zasad przechodzimy do realnych scenariuszy, narzędzi i decyzji, z jakimi na co dzień mierzą się administratorzy.

To rozmowa nie o „idealnym orgu z prezentacji”, ale o Salesforce takim, jakim faktycznie jest używany w firmach – małych, średnich i tych działających w silnie regulowanych branżach.

Od Shielda po sandboxy: jak naprawdę wygląda ochrona danych

W odcinku pojawiają się zaawansowane mechanizmy bezpieczeństwa Salesforce, takie jak Salesforce Shield, Event Monitoring, Field Audit Trail czy Data Mask – ale nie jako marketingowe hasła. Justyna tłumaczy, kiedy te narzędzia mają sens, a kiedy są po prostu przerostem formy nad treścią.

Dużo miejsca poświęcamy też pracy na sandboxach i danym testowym:
jak testować rozwiązania, nie narażając prawdziwych danych klientów,
jak pracować z kontraktorami zewnętrznymi,
i dlaczego „full sandbox” nie zawsze jest najlepszym pomysłem.

To bardzo praktyczna część rozmowy – szczególnie dla osób pracujących w delivery, utrzymaniu systemów i projektach wdrożeniowych.

AI, Data Cloud i… coraz większa odpowiedzialność administratora

W drugiej części rozmowy pojawia się również temat sztucznej inteligencji w Salesforce. Zamiast hype’u – spokojne, techniczne spojrzenie:
jak Salesforce zabezpiecza dane w kontekście AI,
czym jest warstwa zaufania (Trust Layer),
i dlaczego „łatwiejsze narzędzia” nie zawsze oznaczają mniejsze ryzyko.

Rozmawiamy też o trendach, które zmieniają rolę administratora: Flow, automatyzacja, Data Cloud i rosnąca liczba integracji sprawiają, że admin może dziś więcej niż kiedykolwiek – ale razem z tym rośnie odpowiedzialność za bezpieczeństwo całej organizacji.

🎧 Ten odcinek to obowiązkowa pozycja dla administratorów Salesforce, właścicieli systemów i osób technicznych, które chcą lepiej rozumieć ryzyka, a nie tylko „odhaczać checkboxy w Setupie”.

Jeśli nie słuchałeś pierwszej części rozmowy – warto zacząć właśnie od niej.
A potem wrócić tutaj i posłuchać, jak wygląda bezpieczeństwo Salesforce w prawdziwym świecie.

Tranksrypt

Cześć, witajcie serdecznie, z tej strony Łukasz Bujło z coffee&force.

Kontynuujemy naszą rozmowę dotyczącą bezpieczeństwa na platformie Salesforce w ramach już drugiej serii podcastów Salesforce na wyciągnięcie ręki. Salesforce na wyciągnięcie ręki to porcja inspirujących rozmów i historii prosto ze świata Salesforce. Ten projekt stworzony z myślą o Tobie powstał przy współpracy z samym Salesforce, aby przybliżyć tajniki technologii chmurowej, zarządzania relacjami z klientami i nie tylko.

Przygotuj się na dawkę inspiracji i wiedzy, która może zmienić Twoje spojrzenie na technologie w biznesie. Zrelaksuj się, bądź z nami i odkrywaj nieznane zakątki Salesforce w każdym odcinku. A w drugiej części kontynuujemy naszą rozmowę z Justyną Krajewską i opowiadamy o aspekcie bezpieczeństwa z perspektywy Salesforce administratora.

Jeśli nie słyszeliście pierwszej części rozmowy, obowiązkowo zachęcamy, aby powrócić i wysłuchać oraz nadrobić zaległości, a tymczasem nie przedłużam i zapraszam do wysłuchania. Też Salesforce prowadzi bardziej zaawansowane rzeczy, po to też chyba musimy sobie odpowiedzieć na jakim poziomie mamy różnego rodzaju organizacje. Jeżeli jest to np.

firma sprzedażowa, typowo mała firma nie ma takiej potrzeby, ale też Salesforce jest wykorzystywany we branży finansowej, gdzie chociażby tutaj na polskich realiach mamy KNF, mamy regulacje, mamy obwarowania prawne. Więc jakby Salesforce też na to odpowiedział i wprowadził różnego rodzaju zaawansowane i też odpłatne rozwiązania. Więc jakbyś mogła powiedzieć, może podzielić się, jakie to są rzeczy, do czego my więcej służą.

Więc mogę wspomnieć o nich, natomiast na co dzień z nich nie użyłam, ponieważ tak jak wspomniałam wcześniej, ja pracuję w tych mniejszych firmach, które nie mają aż takiego zapotrzebowania na tego typu narzędzia. Natomiast jest to Salesforce Shield z Event Monitoring czy Field Audit Trail, oni też mają Data Mask i Einstein Data Detect. Więc to są takie, to są narzędzia, które pomagają jakby zautomatyzować politykę bezpieczeństwa, bo możesz mieć więcej rzeczy raportowanych do siebie, dostać więcej alertów, czyli np.

jeżeli ktoś wykonuje jakąś akcję w Salesforce i jest ona podejrzana, czyli masz użytkownika, który nagle eksportuje dużo raportów, ma dostęp do różnych danych, a to nie jest, nie robi tego codziennie, tak, czyli wiemy, że to jest coś poza jego obowiązkami, możemy dostać wtedy alert. To co mówisz, to ja przerwę, to ja słyszałem właśnie o takim fajnym case’ie, kiedy to się wykorzystuje, żeby nie było takiej sytuacji, że pracownik, szczególnie w branży, gdzie jest tam sprzedaje, wyciąga, raportuje bazę wszystkich klientów i niestety sprzedaje to konkurencji, bo niestety też były takie przypadki, sytuacje, więc to może zabezpieczyć właśnie przed takim case’em, że okej, ktoś wyciąga bardzo duży raport wszystkich klientów i z automatu możemy się dowiedzieć, jaka była przyczyna i po co danemu pracownikowi raport tych wszystkich klientów. Jest też właśnie możliwość zaszyfrowania danych, tak, jeżeli pracujemy z różnymi, czy z medycznymi firmami, czy z bankowością, czy nawet z rządowych, tak, więc tam wszystkie, musisz mieć to wszystko dobrze zaszyfrowane, żeby nie były dostępne dane klientów, nie były dostępne dla wszystkich użytkowników.

Nawet czasami, bo w moim przypadku, jak jesteś adminem, to jesteś Bogiem, tak, masz, cała Salesforce jest Twoja i Ty jesteś tym zarządzającym. Natomiast są firmy i są działy, w których admin nie ma dostępu do wszystkich danych, tak, Ty masz dostęp tylko do rzeczy technicznych, a dane, tak jak na przykład, nie wiem, numery kart kredytowych, czy numery PSL, to wcale nie jest coś, co admin powinien i musi wiedzieć, tak, więc to jest wtedy cała polityka zaszyfrowania, dostosowania tego, kto i co może widzieć. Ciekawe.

Z takiej perspektywy teraz tworzenia danych testowych. Patrzę z perspektywy troszkę delivery, gdzie mamy system, chcemy sobie przetestować, tworzysz jakieś orgi, oczywiście na tych Dev Sandboxach jest problem, ponieważ nie mamy danych, potrzebujemy troszeczkę danych do testowania. Czy masz tutaj jakby doświadczenie i praktyki, jak dostarczać jakoś dane testowe, kreować, czy nawet na tych orgach, o których mówiłaś, mamy full copy, niekoniecznie chcemy, żeby ludzie mieli dostęp, tak, potrzebujemy pewne dane do przetestowania, ale nie chcemy, żeby to były jakby autentyczne, rzeczywiste dane.

Jeszcze ja mam swój, wydaje mi się, że są dostępne online’owo, fake’owe dane, że tak powiem. Ja przez moje lata stworzyłam sobie taki pliczek z tymi podstawowymi obiektami Salesforce’a, który jeżeli deweloper, czy jeżeli firma zewnętrzna musi coś przetestować, to wtedy im stworzą takiego Dev Orga, dodaje te dane, żeby oni sobie mogli przetestować i coś stworzyć. Natomiast mamy też zasadę taką, że jeżeli coś idzie, oczywiście to musi iść w pewnym momencie do Full Sandboxu, żeby użytkownicy to mogli przetestować, żeby biznes mógł powiedzieć, czy jest zadowolony, czy rzeczywiście o to chodziło, jeżeli jest coś dużego, czy to współgra ze wszystkimi automatyzacjami, które mamy już w systemie.

Więc w pewnym momencie masz inne zabezpieczenia, ten kontraktor podpisuje NDA, podpisuje z tobą ustalenia i ty mu dajesz dostęp do Sandboxu, natomiast w większości my też tak robimy, że to ja jestem w Sandboxie, oni jeszcze mają dostęp do Sandboxu, natomiast ja jestem jedyną osobą, która robi deployment do produkcji, czyli ja się z nimi łączę, jeżeli to jest coś skomplikowanego i muszą mi powiedzieć dokładnie, gdzie kliknąć, natomiast oni nie dostają tego, naprawdę w minimalnych przypadkach dostaje ktoś z zewnątrz dostęp do produkcji. Czyli to też jest dodatkowa forma bezpieczeństwa. O uprawnieniach, o zarządzaniu dostępem troszeczkę już sobie porozmawialiśmy, a powiedz z twojej perspektywy, mam nadzieję, znaczy nie mam nadzieję, ale trzymam kciuki, że pewnie w swojej karierze ty się osobiście może nie spotkałaś, ale czy słyszałaś o jakichś takich naruszeniach bezpieczeństwa w sytuacjach, które wydarzyły się może z wyciekiem danych? Są na pewno i były na pewno, natomiast nie mam ich tak, żeby tutaj zrękawać opowiedzi o wydarzeniach.

To zdarza się na porządku dziennym. Chodzi o to, że ponieważ firmy są znane albo większe, jest to bardziej znane i dodane do publiczności, niektóre firmy nadal próbują to ukryć, czyli że nic się nie dzieje, zachowajmy to dla siebie, klienci nie muszą się dowiedzieć. Natomiast jako takich przykładów niestety nie mam w głowie teraz na ten moment.

A wiesz jakiego typu to mogą być, jakby nie konkretne, które firmy, co się dokładnie wydarzyło, ale jakiego typu naruszania bezpieczeństwa było? Takim najprostszym i wręcz obwiniającym firmy jest za duży dostęp użytkowników. Pracownik, który został zwolniony, on albo zaloguje się po raz ostatni do tego Salesforce’a i skasuje to co może, albo wręcz tak jak Ty wtedy powiedziałaś, wyeksportuje sobie bazę klientów i zabierze ją gdzie indziej. Skoro go tutaj niedocenili, to on sobie to zdobi coś innego.

Z drugiej strony cała masa jest różnych rzeczy związanych z community, czyli z digital experience, bo tam dostęp jest bardzo specyficzny, bo już dajesz dostęp do części danych na zewnątrz i tam źle napisany APEX, który nie ogranicza dostępu, czy sama Salesforce odkryła guest user, czyli użytkownik-gość, jeżeli chcesz mieć swoją platformę, swoją community, gdzie ludzie nie muszą się od razu zalogować i tam danie pewnych uprawnień przez przypadek, niezwrócenie sobie uwagi, że tego nie powinno być, potrafi uwidocznić prywatne dane na zewnątrz. Nawet Salesforce się zorientowała, że oni od początku tego nie do końca dobrze zrobili i sama to częściowo zablokowała. Teraz jest osobny użytkownik guest user, który może mieć swoje permission settings.

Wydaje mi się, że nawet nie może być właścicielem rekordu, a wcześniej mógł być, a sam nadanie komuś gościowi, czyli komuś, kto nie jest zarejestrowany dostępu do czegokolwiek, wręcz otwiera drzwi dla innych hakerów i innych ludzi, którzy nie są tak mili i na tym żerują, że tak powiem. Rzeczywiście, o tym przypadku z guest userem w tym Experience Cloudie z WSAM to była ta rzecz, ale o tych wszystkich rzeczach, o których innych mówisz, to rzeczywiście tylko pokazuje, jak ta kwestia bezpieczeństwa, czyli nadawania uprawnień jest zdecydowanie kluczowa, że złe dobranie uprawnień, czasami to może być bagatelizowany temat albo proste, OK, stworzę sobie profil, dodam uprawnienie i już będzie wszystko działać, ale tutaj większość czy tak naprawdę wszystkie naruszenia bezpieczeństwa dotyczą chyba dwóch aspektów. Dobranie odpowiedniego security, czyli całego bezpieczeństwa, które w Salesforce jest, a z drugiej strony, niestety cały czas mamy ten czynnik ludzki.

Bo o takich przypadkach, gdzie bezpośrednio z Salesforce’a był wyciek danych, to nie słyszałam. Nie, bo to reklamie to albo pracownicy, albo przez community, przez bezkonstruowanie. Dobrze.

I jeszcze chyba warto wspomnieć o tym, że Salesforce informuje też o stanie orgów, co się dzieje, czyli to jest ten trust w Salesforce.com. Jak byś mogła coś powiedzieć więcej? Tak, że jeżeli Salesforce stara się… Trust w Salesforce.com jest to bardzo fajny site, czyli można się zalogować i tam, jeżeli znamy tylko swój org, nawet nie id, tylko to się nazywa instans, nie wiem jak to się po polsku nazywa, na której instans jest zorganizowany twój org, możesz się zalogować i sprawdzić, czy są jakieś problemy. Czyli na przykład zauważasz, że Salesforce trochę wolniej działa, to możesz sprawdzić, jeżeli użytkownik, kilku użytkowników ci to mówi, czy to jest rzeczywiście… czy Salesforce ma rzeczywiście jakiś problem, czy to jest zły network u nich w domu. Więc tam sobie od razu sprawdzasz, co i jak.

To jest też site, który ja często używam, ponieważ tam są dokładne daty, kiedy będą nasze release, kiedy twoja org dostanie jedną z trzech rocznych release. I to przynajmniej dla mnie jest też dobre do sprawdzenia, ponieważ jeżeli refreshujesz, odświeżasz sandbox, on potrafi zmienić instans, na którym jest. I wtedy mogę sobie sprawdzić, okej, to teraz w tej release mój sandbox dostanie nowe feature tego dnia, czyli ja wiem, że ja muszę ten sandbox sobie wcześniej odświeżyć, żeby mieć pewność, że to jest dokładna kopia mojej produkcji.

Więc dla mnie bardzo często tego wykorzystam, bo oni mają już na trzy kolejne release konkretne daty. Więc ja wtedy mogę sobie też poinformować biznes i powiedzieć im, że tutaj musimy zdobyć przerwę z czymkolwiek rozwijaniem czegoś w sandboxie, bo ja muszę ten sandbox odświeżyć, żeby być w pełni przygotowana do testowania nowych rzeczy przed wprowadzeniem ich do produkcji. Są tam też rzeczy, które jeżeli Salesforce ma jakieś pracę czy maintenance, tam też jest dokładnie powiedziane, czyli jaki cloud będzie robiony i kiedy.

A jeżeli rzeczywiście jest outage, to jest na czerwono też, że coś się dzieje, że instans, które są tym dotknięte, to takie, takie i takie. Więc Salesforce próbuje być transparentne, informować swoich klientów o stanie systemu. Super, a jeszcze chciałbym wrócić do tego, teraz pomyślałem o tym, co rozmawialiśmy, troszkę o naruszeniu bezpieczeństwa danych i jeszcze w takim tradycyjnym modelu, gdzie były serwerownie, jest jakiś atak, coś się dzieje, to łatwo było mi gdzieś tam ogarnąć ten temat, że ludzie nie mają dostępu chociażby przez wyłączenie serwera, tak? Salesforce jest technologią chmurową, gdzie nie mam takiej możliwości wyłączenia, odcięcia serwera od internetu.

No i teraz z takiej perspektywy Twojej, administratora, czy są jakieś mechanizmy i możliwości, jak Ty możesz zarządzić? Widzisz, czy jest jakieś tak naruszenie bezpieczeństwa i żeby po prostu odciąć użytkowników od dostępu do Salesforce’a? Wiesz co, pierwszą taką rzeczą, jeżeli to jest jeden użytkownik, który coś, widzisz, że robi coś podejrzanego i chcesz sprawdzić, to jest jego albo zamrożenie, tak się mówi po polsku, żeby od razu nie deaktywować, bo czasami deaktywacja na przykład w community może sprawić, że tam jego ustawienia się zmienią, czy jakieś permissions, natomiast tu jeżeli nie chcesz niczego, jest podejrzenie, ale jeszcze nie wykroczenie, tak? Możesz szybciutko takiego użytkownika zamrozić i on od razu traci dostęp do Salesforce’a. Możesz też zapewnić na przykład, że masz godziny logowania, tak? Możesz specjalnie określić godziny pracy Twojej firmy i godziny, w których użytkownicy mogą się zalogować, nie pozwalając im na logowanie się w innych godzinach czy w weekendy, tak? Praca w weekendy może zostać zakażona i to w pewnym momencie ograniczy. Czy logowanie się z różnych określeni IP, w których mogą się zalogować, tak? Czyli nie mogą wszędzie jeździć i sobie zalogować skąd tylko chcą, czyli Ty masz jakąś, jakąś na tym kontrolę.

Jeżeli w większości to jest albo, wydaje mi się, że można tworzyć profil taki, jeżeli chcemy zablokować wszystkich użytkowników na chwilę, ponieważ chcemy wprowadzić jakieś zmiany, tak? I w tym momencie nie chcemy żadnego użytkownika. Wydaje mi się, że raz tak zrobiliśmy, że na początku zmieniliśmy kto ma jaki profil, sobie to zachowaliśmy, zbackupowaliśmy, zrobiliśmy profil użytkownika z niemożliwością zalogowania się i ten profil dodaliśmy do wszystkich użytkowników i po tym, jak już dokonaliśmy wszelkich zmian, przywróciliśmy użytkowników do ich normalnych profili. Mhm, świetnie, czyli trochę tych możliwości jest.

Lubicie nasze rozmowy o Salesforce? Kliknijcie subskrybuj i bądźcie na bieżąco z każdym nowym odcinkiem. Twoja kolejna porcja inspiracji już w drodze. Dołącz do nas.

Nie pamiętam, czy to w tym systemie, bo też mam trochę inne doświadczenie z innymi systemami, czy nie było też możliwości w ogóle wyłączenia logowania poza administratorami. Chyba też kiedyś taka opcja była, że tylko systemadministratorzy mogą się logować do systemu, reszta nie, ale to nie wiem czy teraz… Sprawdźcie, sprawdźcie. Nie słyszałam, nie potrzebowałam, więc nie słyszałam.

Nie wiem, czy teraz wymyślam, czy nie, ale tak. Dobra, ale mechanizmy są najważniejsze, to co powiedziałaś, że jest możliwość zablokowania tutaj użytkowników, więc jestem w stanie sobie z tym wszystkim poradzić. Poruszaliśmy to już też troszeczkę w podcaście, bo chcę troszkę zahaczyć o temat AI-a.

Teraz jakby wszyscy mówią o tym AI-u. No i w AI-u też nie ma do końca tej świadomości o tym wycieku danych. Tak samo jak wcześniej był duży problem z translatorami, m.in. z Google Translatorem, gdzie powszechnie niektórzy dalej stosują, wrzucają całe maile od klienta czy korespondencję wewnętrzną, żeby sobie przetłumaczyć.

A oczywiście wiadomo, że to wszystko wychodzi na zewnątrz. Tak samo pewnie z czatem GPTS czy z innymi rozwiązaniami, że ludzie wrzucają bezpośrednio dane. Teraz jeszcze tam jest więcej możliwości.

Możesz sobie wrzucać raporty, dokumenty, które on analizuje i to też jest duży wyciek danych. A jak to jest w Salesforce ze sztuczną inteligencją? Jak jest w Salesforce? Więc Salesforce też wprowadza pewne elementy AI-a do Salesforce’a. Od dawna był Einstein, który chyba Einstein się jeszcze nazywa nadal, który pomagał ci napisać maile, podpowiadał w searchach i ogólnie ułatwiał wprowadzanie w pracę z Salesforce’em.

Natomiast, z tego co się nie mylę, to jest nadal płatne. Czyli nie wszyscy się na to od razu przepiszą i zapiszą. Z drugiej strony Salesforce wprowadziła ten element trust, czyli ten layer trust, że oni mówią, że nawet jeżeli wprowadzasz AI do swojego orga, oni to kontrolują i jest ten trust level, który zapewnia bezpieczeństwo.

Czyli nawet jeżeli połączysz to sobie z OpenAI, to będzie sprawdzone przez Salesforce’a. Nawet chyba nie jest sprawdzone, tam jest nawet anonimizacja tych danych. Nawet jak korzystamy z tych zewnętrznych systemów, te dane są klienta czy inne rzeczy anonimizowane i one nie dostają się na zewnątrz, a później jak przychodzi odpowiedź, to Salesforce sobie bezpośrednio wie, jakie dane podstawić.

Na przykład to przykład taki generowania maila. Tak, poproszę sobie OpenAI o wygenerowanie maila, on jakby wyśle request, ale później w odpowiednie miejsca wstawi mi dane klienta. Więc chyba to jest taka najważniejsza rzecz, gdzie nie dopuszczamy, aby dane wrażliwe czy w ogóle dane klienta dostały się jakkolwiek na zewnątrz.

Pozdrawiamy Ullę Grassl i zachęcam do odsłuchania tego podcastu, gdzie Ulla tłumaczy, jak w ogóle to podejście AI-owe działa w Salesforce’ie. Ok, ale chciałaś jeszcze coś powiedzieć i chyba ci przerwałam, to przepraszam. Nie chciałam tylko powiedzieć, że ponieważ ludzie używają AI-a do wszystkiego.

Teraz nawet się mówi, że deweloperzy są zagrożeni, ponieważ każdy może napisać kod. Napisać, że stwórz mi klasę do tego, zrób mi to i to, że to admin może zdobić. Natomiast to też jest takie, że jeżeli zaczniemy tego używać, to to musi być na czym się oprzeć.

Jeżeli mamy zły kod w systemie, to ten AI nauczy się generować kolejne złe kody i sami sobie strzelimy w kolano ze względu na bezpieczeństwo. Bo jeżeli skopiujemy skądś klasę i powiedz ona, na podstawie tego zrób mi taką samą, tylko inną do czegoś innego, to on nie powie, że tu jest błąd i po prostu musi mieć dobrą bazę, o czym czasami też zapominamy, że to jest ułatwienie, ale to może być też otwarcie na niebezpieczne zagrywki. OK.

AI to jest jakby jedna z takich rzeczy, jak by teraz najbardziej powszechna, ale jakbyś mogła powiedzieć o swoim zdaniem, przyszłych trendach, czy podejściu, jakie mogą wpłynąć na zarządzanie bezpieczeństwem danych w Salesforce? Na pewno AI będzie to ugórowało wszystkim i chęć. Z drugiej strony masz też Data Cloud, czyli zaczynanie, łączenie wszystkiego ze wszystkim. Czyli łączenie wielu zewnętrznych aplikacji i wymiana danych między nimi.

Więc to będzie takie, jak dla mnie, automatyzacja i wręcz rozbudowa nawet najmniejszych systemów. Każdy będzie chciał mieć dostęp do wszystkiego. Ten Customer 360 jest przedstawiony tak, żeby każdy pracownik w firmie miał dostęp do wszystkiego, co powoduje, że chcemy więcej systemów, chcemy więcej, chcemy lepiej i w pewnym momencie musimy być bardzo uważni, jak to wprowadzamy.

I co z czym łączymy. Jest też cały czas mnóstwo zmian w różnych ustawach, czy krajowych, czy Unii Europejskiej, czy na bazie światowej. Co jest pozwolone, co nie.

Więc nawet utrzymywanie znajomości na pewnym poziomie. Ok, teraz to ja muszę się przyjrzeć temu, ponieważ do tej pory nie zwracam na to uwagę. To też nie jest łatwe zajęcie do obeznania.

I tak jak wspomniałam, może sobie sama podcinam w tym momencie gałąź, na której siedzę, gdyż jestem adminem, ale admin ma coraz więcej dostępu, możliwości. Taki flow, który kiedyś był tylko a la process builder, teraz nagle może robić rzeczy, które kiedyś były dostępne tylko przez kod. I admin czasami może sobie nawet z tego sprawy nie zdawać, bo to przychodzi tak łatwo, to jest takie, że masz drag and click i to ci wszystko działa, ale jesteśmy w stanie, admin może zbudować coś, co usuwa rekordy.

Jest pewne, że coś, co może zablokować jakąś akcję w Apexie, bo nie da sobie z tego sprawy, bo on się Apexu nie dotyka, on sobie przecież tylko robi flow. Więc ten taki trend, że admin może więcej, z jednej strony jest fantastyczny, bo nareszcie nie potrzebujemy developerów non-stop, żeby coś tylko zrobić, natomiast to też jest w pewnym momencie ryzyko. I jak to będzie się dalej rozwijało, to to może być też pewnym zagrożeniem, jak dla mnie.

Mówimy jeszcze o zagrożeniu, możemy się zatrzymać przy tym aspekcie zagrożenia i jakbyś mogła powiedzieć, jakie są wyzwania dla Ciebie jako system administratora, jeżeli chodzi o całe security, te nowoczesne technologie, podejścia itd., ale pewnie są jeszcze inne rzeczy, które mogą się pojawić. Wyzwania z dnia codziennego, to są wyznania, takie jak wspomniałam wcześniej, to przekonanie managmentu w firmie, że hierarcha w firmie nie jest hierarchią w Salesforce, że to musi być zorganizowane i tu musi być struktura. Jest też takie uzmysłowienie sobie, że to też nie jest takie dla adminów, że coś zrobiłem, sobie checkbox, zrobiłem to i o tym zapomnę, bo to jest takie non-stop powtarzające się, to jest nieustający proces.

My musimy sprawdzać, może nie na co dzień sprawdzać, co się dzieje, ale tak jak mieć jakąś strukturę, czyli że sprawdzamy sobie tego optimizera, czy sprawdzamy dostępy, musimy dobrze przekonywać użytkowników, że to, że oni mają MFA włączony i muszą jeszcze ten tutaj kod wpisać, to jest dla ich dobra, że to nie jest coś złośliwego, że my im próbujemy unieprzyjemnić logowanie się do firmy, tylko że to są już standardy, że w pewnym momencie to musi zostać zrobione, żebyśmy mieli bezpieczeństwo, że to oni się logują, że jeżeli stracą, zgubią laptopa czy coś, to my nie będziemy już od razu zamykać wszystkiego, bo jeden laptop został stracony. Więc to są takie rzeczy, wydaje mi się, na co dzień admina, który z jednej strony jest odpowiedzialny za org, a z drugiej strony ma też biznes, który jest klientem, jego klientem, bo co robimy, to robimy wszystko dla biznesu, dla klientów, więc w pewnym momencie wytłumaczenie, znalezienie tego poziomu negocjacji czy poziomu rozmowy. Dzięki wielkie za te postrzelenia.

Już myślę, że powoli będziemy sobie kończyć naszą rozmowę i może takie podsumowanie, uwieńczenie naszej rozmowy byłoby z twojej strony podanie kilka porad dla aktualnych, dla przyszłych systemadministratorów czy dla właścicieli systemów, bo też pewnie nie wszędzie mamy systemadministratorów. Na co zwracać uwagę, jeżeli chodzi o security w Salesforce? Jakie najważniejsze rzeczy? Najważniejsze rzeczy, więc jak dla mnie to jest nieustający proces. Musimy sprawdzić dawanie najmniejszej z koniecznych dostępów, czyli nie to, że kogoś lubimy, czy ktoś jest na wysokim stanowisku, że musi od razu mieć dostęp do wszystkiego.

Dokładnie sprawdzamy, co ta osoba robi, jaki jest zakres obowiązków i dopasujemy widoczność i dostępność według tego. Dokumentacja, dokumentacja, dokumentacja, czyli każda zmiana zrobiona przez admina powinna zostać udokumentowana. To jest A dla nas, jeżeli zostanie nam dłużej, bo nie będziemy wiedzieć, dlaczego coś zrobiliśmy wcześniej, a jak ktoś powie, że o to, a teraz wszyscy to widzą, albo dlaczego to jest niewidoczne, musimy to wiedzieć, tak samo, jakbyśmy zmieniali firmę.

Powinniśmy mieć jakikolwiek support i wiedzieć, co jest co i jak. Sprawdzanie profili, albo teraz właśnie przejście na, próbowanie migracji z profili na permission set, czyli tworzenie sobie przejrzystości, co jest moim orgiem, kto co może. Jest kilka apex zewnętrznych, które Ci w tym pomagają, natomiast to też jest odpowiedzialność admina, jak on do tego dojdzie i co zrobi.

Natomiast jest to pierwsze, czyli cały setup Twój przyjaciel. Idziesz tam i sprawdzasz, co kto może, co jest uaktualnione, health check i optimizer od razu, żeby wiedzieć, co i jak. Później właśnie sprawdzenie tych kilku ważnych permissions dla osób, czyli kto ma dostęp do setupu, kto może co zrobić, kto może eksportować dane i to, co widzi.

Cała hierarchia. Dzięki wielkie. Moim ważnym gościem była Justyna Krejewska, Salesforce MVP, ale też Salesforce administrator, która na co dzień podzieliła się z nami, na czym polega jej codzienna praca, ale ze względu na bezpieczeństwo, bo pewnie wyobrażam sobie, że tych zadań w ogóle z system administratora jest zdecydowanie więcej, więc to jest ogrom pracy.

Tutaj dzisiaj skupiliśmy się na środkach bezpieczeństwa, jeżeli chodzi o samo security w Salesforce. Poznaliśmy wiele fajnych, dodatkowych narzędzi, które w Salesforce są i myślę, że rady Justyny były dosyć cenne, aby zwrócić, uświadomić sobie, jak ta rola, też system administratora jest ważna i jak security może wpływać bezpośrednio na Waszą firmę czy na Wasz biznes. Dzięki jeszcze raz Justyna za poświęcony czas i do usłyszenia.

Dzięki, pa. Salesforce. Pierwszy portal o technologii i ekosystemie Salesforce w Polsce.

Podcasty, aktualności, wydarzenia. Nie tylko przy kawie. coffeeforce.pl