| Termin | Definicja |
|---|---|
| Salesforce – złożone uprawnienia | Złożone uprawnienia Salesforce wymagają starannego planowania, by integracja z pocztą nie ujawniła nadmiaru danych. Model uprawnień w SalesforceZłożone uprawnienia Salesforce wynikają z kilku niezależnych warstw kontroli dostępu. Profil określa podstawowe uprawnienia użytkownika, między innymi możliwość logowania, dostęp do aplikacji, obiektów i wybranych funkcji systemu. Uprawnienia do obiektów obejmują operacje CRUD: tworzenie rekordów, odczyt, edycję i usuwanie. Sam dostęp do obiektu nie oznacza jednak automatycznie dostępu do wszystkich jego pól ani do każdego rekordu. Rozszerzenia uprawnień są zwykle nadawane za pomocą permission sets, czyli zestawów uprawnień przypisywanych użytkownikom bez modyfikowania profilu. Permission set groups pozwalają łączyć takie zestawy w logiczne pakiety, a muting permission sets umożliwiają wyciszenie wybranych uprawnień w obrębie grupy. Takie rozdzielenie ułatwia analizę, ponieważ można odróżnić uprawnienia wynikające z profilu od dodatkowego dostępu przyznanego konkretnej osobie. Rozdzielenie dostępu do obiektów, pól i rekordówW Salesforce dostęp do danych jest oceniany na kilku poziomach. Object-level security decyduje, czy użytkownik może korzystać z danego obiektu, na przykład Account, Contact, Lead lub Case. Field-level security ogranicza widoczność albo możliwość edycji pojedynczych pól. Ma to znaczenie przy integracji pocztowej, ponieważ użytkownik może mieć dostęp do rekordu kontaktu, lecz nie powinien widzieć wszystkich jego atrybutów. Record-level security określa, które konkretne rekordy są dostępne po uzyskaniu dostępu do obiektu. W tej warstwie działają między innymi ustawienia Organization-Wide Defaults, hierarchia ról, reguły udostępniania, zespoły rekordów, udostępnianie ręczne oraz programowe udostępnianie rekordów. Szerszy dostęp przyznany na poziomie obiektu nie zastępuje reguł rekordowych. Z kolei hierarchia ról może rozszerzyć widoczność danych, ale nie służy do nadawania wszystkich uprawnień administracyjnych. Integracja Salesforce z pocztą a nadmiar danychPołączenie Salesforce z pocztą elektroniczną powinno być analizowane jako osobny przepływ danych. Należy ustalić, czy użytkownik jedynie synchronizuje wiadomości, czy także zapisuje je jako aktywności przy rekordach, korzysta z funkcji wysyłania poczty z Salesforce albo używa dodatku pocztowego. Każdy z tych scenariuszy może wymagać innego zestawu uprawnień do obiektów, pól i rekordów. Sam fakt, że wiadomość jest powiązana z kontaktem lub sprawą, nie powinien oznaczać automatycznego udostępnienia całego rekordu wszystkim użytkownikom poczty. W integracjach korzystających z OAuth istotne są uprawnienia przyznane aplikacji oraz zakresy dostępu określone dla połączenia. Zakres umożliwiający odczyt lub modyfikację danych powinien odpowiadać rzeczywistej funkcji integracji. Trzeba również sprawdzić użytkownika, w którego imieniu działa połączenie, sposób przechowywania tokenów oraz możliwość ich unieważnienia. Przydatne jest testowanie na koncie o ograniczonym profilu i z użyciem danych testowych. Weryfikacja powinna obejmować zarówno widoczność wiadomości w Salesforce, jak i to, czy synchronizacja nie przenosi niepotrzebnych pól, załączników lub historii aktywności. Przegląd konfiguracji i śladów dostępuPraktyczny przegląd złożonych uprawnień Salesforce zaczyna się od sporządzenia macierzy: użytkownik lub grupa, profil, permission sets, permission set groups, obiekt, pole, zakres operacji i zasięg rekordów. Następnie należy porównać tę macierz z rzeczywistym scenariuszem pracy. Szczególną uwagę warto zwrócić na uprawnienia Modify All Data, View All Data, Modify All oraz View All, ponieważ mogą znacznie rozszerzać dostęp poza standardowe reguły udostępniania. Kontrola powinna obejmować także Connected Apps, zasady logowania, historię zmian konfiguracji i dzienniki użycia, jeżeli są dostępne w danej edycji oraz konfiguracji organizacji. Należy sprawdzić konta nieużywane, uprawnienia nadane tymczasowo oraz zestawy, które pozostały po zmianie stanowiska. Po każdej korekcie trzeba wykonać test jako użytkownik o ograniczonym dostępie: otworzyć rekord, sprawdzić widoczność pól, spróbować wykonać dozwoloną i niedozwoloną operację oraz zweryfikować zachowanie integracji pocztowej. Taki test pozwala wykryć różnicę między uprawnieniem zapisanym w konfiguracji a faktycznym dostępem widocznym w interfejsie. |