Chroń, przechowuj, udowadniaj
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduł 6 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Zgoda i prawo do bycia zapomnianym · Dalej: następny rozdział, Dane podstawowe i tożsamość
Pytanie, na które odpowiada ten moduł: jak chronić dane, przechowywać je tak długo, jak trzeba, i to udowodnić?
Ustaliliśmy właścicieli i polityki, zatrzymaliśmy złe dane, spisaliśmy słownik, prześledziliśmy pochodzenie, sklasyfikowaliśmy to, co ważne, poznaliśmy przepisy i zamodelowaliśmy zgody. Teraz musimy to prowadzić. Dane przychodzą, są używane, kopiowane i zmieniane, starzeją się, a w końcu część z nich musi zniknąć. A kiedyś ktoś zapyta: udowodnij, co się wydarzyło.
Ład danych idzie za danymi
Dział zatytułowany „Ład danych idzie za danymi ”Nie myślę o ładzie danych jak o jednej funkcji. Myślę o tym, co dzieje się z danymi od chwili, gdy wchodzą, aż do chwili, gdy z nimi kończymy:
Pozyskaj → Sklasyfikuj → Chroń → Używaj → Przechowuj → Usuń → Audytuj
To nie siedem procesów technicznych: to siedem pytań, na które architektura musi odpowiedzieć. Pozyskiwanie i klasyfikację już omówiliśmy: zatrzymuj kosztowne błędy (moduł 2) i wiedz, które dane są wrażliwe (moduł 3). Klasyfikacja decyduje o tym, co dzieje się na każdym kolejnym etapie, więc ten moduł podejmuje wątek od tego miejsca.
Siedem pytań przez całe życie danych. Narzędzia wspierają politykę; nie definiują jej.
Chroń: dopasuj mechanizm kontroli do danych
Dział zatytułowany „Chroń: dopasuj mechanizm kontroli do danych ”Kto może je widzieć, zmieniać, otrzymywać? Czy powinny być szyfrowane, maskowane poza produkcją, eksportowalne, dostępne dla agenta? Tu bezpieczeństwo Salesforce staje się częścią ładu danych: udostępnianie, uprawnienia do obiektów i pól, szyfrowanie, maskowanie, dostęp integracji. Te tematy wypełniają całe kursy, więc nie będę ich ponownie wykładał. Uwaga dotycząca ładu danych: ochrona wynika z klasyfikacji i polityki. Nie każde pole potrzebuje tej samej ochrony, nie każdy użytkownik tego samego dostępu, nie każdy system dalej w łańcuchu każdego pola.
Szyfrowanie to mechanizm kontroli, a nie zgodność
Dział zatytułowany „Szyfrowanie to mechanizm kontroli, a nie zgodność ”Dla danych regulowanych szyfrowanie w spoczynku może być wymagane, a moje stanowisko jest takie, że Shield to odpowiedź na kluczowe wymagania regulacyjne tego rodzaju. Shield Platform Encryption szyfruje pola i pliki w spoczynku. Ale „zaszyfrowaliśmy, więc jesteśmy zgodni z przepisami” jest błędne podwójnie. Szyfrowanie to jeden mechanizm kontroli spośród dostępu, retencji, audytu, zgód, monitorowania, minimalizacji i usuwania. I ma kompromisy funkcjonalne, które trzeba zaprojektować z góry. Przy domyślnym schemacie probabilistycznym zaszyfrowanego pola nie da się użyć w klauzulach SOQL WHERE, GROUP BY ani ORDER BY ani w filtrach zarządzania danymi; szyfrowanie deterministyczne rezygnuje z odrobiny siły, żeby dało się filtrować po polu. Zaszyfrowane pola nie mogą sterować regułami udostępniania opartymi na kryteriach, a widoków list nie da się po nich sortować (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), po angielsku). Szyfrowanie to więc nie pole wyboru na końcu. To decyzja architektoniczna. Rozdział o bezpieczeństwie danych idzie głębiej.
Nie kopiuj ryzyka z produkcji do sandboxa
Dział zatytułowany „Nie kopiuj ryzyka z produkcji do sandboxa ”Produkcja jest zablokowana. Potem ktoś odświeża pełny sandbox, a programiści, testerzy, wykonawcy i integracje testowe mają teraz kopie prawdziwych danych osobowych, których nigdy nie potrzebowali. Zmieniło się środowisko; wrażliwość danych nie. Narzędzia Salesforce do maskowania istnieją właśnie po to. Zwróć uwagę na zmianę: zarządzany pakiet Data Mask kończy wsparcie 31 grudnia 2026, a jego następcą jest Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), po angielsku). Ale narzędzie wspiera politykę, a pytanie jest pierwsze: czy to środowisko w ogóle potrzebuje prawdziwych danych wrażliwych? Jeśli testowanie da się przeprowadzić na realistycznych, niewrażliwych danych, to lepsza odpowiedź.
Używaj: pozwolenie nie dotyczy tylko ludzi
Dział zatytułowany „Używaj: pozwolenie nie dotyczy tylko ludzi ”Z danych korzystają użytkownicy, integracje, analityka, partnerzy, automatyzacja i agenci. Zgoda (moduł 5), własność (moduł 1) i klasyfikacja (moduł 3) spotykają się tu w czasie działania. Czy ten użytkownik powinien widzieć numer telefonu odbiorcy? Czy ta integracja powinna go dostać, czy Snowflake, czy ten agent jako ugruntowanie? Odpowiedź nie może brzmieć „no, technicznie może”. Na tym polega różnica między możliwością a ładem danych: architektura decyduje, czy powinno.
Przechowuj: trzymanie wszystkiego na zawsze nie jest neutralne
Dział zatytułowany „Przechowuj: trzymanie wszystkiego na zawsze nie jest neutralne ”Wiele organizacji ma przypadkową politykę retencji: na zawsze. Nikt tego nie zdecydował; przestrzeń była, więc dane zostały. Ale trzymanie danych kosztuje przestrzeń i wydajność, poszerza ekspozycję na ryzyka prywatności i bezpieczeństwa, dodaje obowiązki w postępowaniach dowodowych i daje więcej miejsc do przeszukania, gdy ktoś prosi o zapomnienie. Dla każdej ważnej kategorii: po co je trzymać, jak długo, co zaczyna bieg terminu, czy jest prawne minimum albo maksimum wynikające z prywatności i co się dzieje na końcu: archiwizacja, usunięcie, deidentyfikacja?
A archiwizacja to nie to samo co rozwiązanie retencji. „Zarchiwizowaliśmy to”. Czy wymaganie retencji zniknęło? Wymaganie prywatności? Bezpieczeństwo? Zmieniono miejsce, w którym mieszkają dane, a nie to, czym są. Archiwum potrzebuje kontroli dostępu, reguł retencji i usuwania, możliwości wyszukiwania i audytu. Przenieś dane osobowe do archiwum, o którym wszyscy zapomną, a ład danych właśnie się pogorszył.
Usuń: cykl życia potrzebuje wyjścia
Dział zatytułowany „Usuń: cykl życia potrzebuje wyjścia ”Usuwanie to nie tylko indywidualne żądania dotyczące prywatności. Dane osiągają koniec okresu retencji; tymczasowe rekordy przeżywają swoją przydatność; archiwa wygasają; proces deidentyfikuje dane po określonym czasie. Cokolwiek mówi polityka, architektura potrzebuje wyjścia, a nie: pozyskaj → przechowuj → przechowuj więcej → przechowuj na zawsze. A jak pokazał moduł 5, usunięcie rekordu w Salesforce nie wystarczy, gdy kopie mieszkają gdzie indziej.
Historia to też dane
Dział zatytułowany „Historia to też dane ”Czasem bieżąca wartość nie wystarcza. Nazwa prawna partnera, klasyfikacja klienta, status zgody, atrybut finansowy: biznes albo regulator może potrzebować wiedzieć, jaki był wcześniej, kiedy się zmienił i kto go zmienił. Ta historia to dane i potrzebuje własnej decyzji o retencji.
Standardowe śledzenie historii pól obejmuje do 20 pól na obiekt i przechowuje zmiany do 18 miesięcy, a do 24 miesięcy tylko przez API, przez Data Loader albo queryAll() (Field History Tracking Overview (opens in a new tab), po angielsku). A dla długich pól tekstowych zapisuje tylko to, że pole edytowano, a nie, co w nim było: luka, jeśli to są twoje dowody. Field Audit Trail, część Shield albo kupowany osobno, obejmuje do 200 pól na obiekt i przechowuje historię do czasu, aż ją usuniesz, w archiwum dostępnym przez API (Field Audit Trail (opens in a new tab), po angielsku). Moje stanowisko: standardowa historia pól jest domyślna; używaj Field Audit Trail, gdy regulacja albo obowiązek zgodności wymaga dłuższej historii, którą da się udowodnić. Nie dlatego, że „audyt dobrze brzmi”.
Audyt i monitorowanie to nie to samo
Dział zatytułowany „Audyt i monitorowanie to nie to samo ”Historia pól odpowiada na pytania o zmiany wybranych pól. Szersze pytania (kto się logował, kto eksportował dane, jakie API wywoływano, kto co oglądał) to monitorowanie, a do tego służy Event Monitoring. Z mojego doświadczenia jest zwykle potrzebny u bardziej regulowanych klientów, a oto moje najmocniejsze stanowisko w tym rozdziale: skonfiguruj go, zanim będzie potrzebny, i z wyprzedzeniem kieruj zdarzenia do repozytorium, takiego jak Splunk albo inny SIEM.
Oto dlaczego. Pliki dziennika zdarzeń są przechowywane przez 1 dzień bez dodatku i tylko dla niektórych typów zdarzeń; domyślnie przez 30 dni z Shield albo dodatkiem Event Monitoring i do 365 dni, jeśli przedłużysz retencję (Event Monitoring FAQ (opens in a new tab), po angielsku). Wszystko starsze przepada, chyba że to wyeksportowano. A płatnych logów nie da się pobrać za żaden okres sprzed początku umowy (to samo FAQ): kupienie dodatku po incydencie nie przywróci przeszłości. Jedna z najgorszych rozmów, jakie może odbyć architekt, wygląda więc tak: „Możemy zobaczyć, co się stało pół roku temu?”. „Nie”. „Dlaczego?”. „Nie zbieraliśmy tego”. Nie można trafić na problem i dopiero wtedy odkryć, że tych zdarzeń nie zbierano i nie przechowywano. Wtedy odpowiedź po prostu nie istnieje.
Ustaw to, zanim będzie potrzebne.
Ale nie przeskakuj na „loguj wszystko”. Co próbujesz udowodnić? Które zdarzenia mają znaczenie, kto ich potrzebuje, jak długo, kto może czytać logi i czy same logi nie mogą zawierać danych wrażliwych? Logowanie tworzy dane, a te dane też potrzebują ładu. A dowody potrzebują właściciela: kto jest właścicielem repozytorium, przegląda alerty, sprawdza, czy retencja działa, zauważa, że zasilanie po cichu przestało działać trzy miesiące temu? Technologia bez właściciela to nie ład danych; wracamy do właściciela, stewarda i opiekuna technicznego z modułu 1.
Udowodnij mechanizm kontroli, a nie tylko konfigurację
Dział zatytułowany „Udowodnij mechanizm kontroli, a nie tylko konfigurację ”„Dane odbiorcy są dostępne tylko dla ekip przypisanych do przystanku”. Skąd wiemy? Konfiguracja bezpieczeństwa pokazuje, co powinno się dziać. Dowody operacyjne (kto naprawdę miał dostęp, nietypowe eksporty, integracja, która je pobierała, zmienione mechanizmy kontroli dostępu) pokazują, co się działo. Dobry ład danych często potrzebuje obu.
Poza egzaminem: co zmienia AI. Gdy agenci przechodzą od odpowiadania do działania, ład danych potrzebuje dowodów na to, co agent widział, co zdecydował albo wygenerował i co zrobił, oraz kto albo co go uruchomiło i na podstawie jakiej polityki. Mechanizmy logowania się zmienią; wymaganie nie: jeśli autonomiczne działanie ma znaczenie, zaprojektuj już teraz, jak je później odtworzysz.
Steve Trucking: cykl życia na jednym polu
Dział zatytułowany „Steve Trucking: cykl życia na jednym polu ”Weźmy numer telefonu odbiorcy. Pozyskaj: przychodzi w manifeście partnera; sprawdź, czy da się go użyć tam, gdzie potrzebuje go proces. Sklasyfikuj: dane osobowe. Chroń: otrzymują go tylko ludzie i systemy z potrzebą operacyjną, a ekipy widzą go tylko dla własnych przystanków, w dniu dostawy. Używaj: ekipa koordynuje dostawę; system wiadomości używa go w zatwierdzonym celu; agent używa go tylko wtedy, gdy pozwala na to polityka. Przechowuj: tak długo, jak mówi zatwierdzona polityka biznesowa i polityka prywatności. Usuń albo zdeidentyfikuj: gdy ten okres się kończy albo przychodzi uzasadnione żądanie, we wszystkich kopiach w krajobrazie. Audytuj: zachowaj dowody, że mechanizmy kontroli i działania miały miejsce.
Teraz weźmy kod centrum dystrybucyjnego. Pozyskaj go dokładnie, sklasyfikuj jako niewrażliwe dane referencyjne, chroń zwykłym dostępem operacyjnym, używaj szeroko, przechowuj tak, jak potrzebuje biznes, i audytuj zmiany, jeśli mają znaczenie. Ten sam cykl życia, inne mechanizmy kontroli. Do tego służy klasyfikacja.
Ładu danych nigdy się nie kończy
Dział zatytułowany „Ładu danych nigdy się nie kończy ”Pojawia się nowa regulacja. Nowy system albo integracja tworzy kolejną kopię. Zespół wymyśla kolejne pole. Rusza nowa platforma. Agent dostaje dostęp. Zmienia się reguła retencji. Przychodzi nowy partner detaliczny. Architektura się porusza, a ład danych porusza się razem z nią. Celem nie są idealne dane, nieskończone mechanizmy kontroli ani dokument o ładzie danych, którego nikt nie czyta. Celem są świadome decyzje o danych, wbudowane w architekturę.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Jakie mechanizmy ochrony dostaje każda kategoria danych, na podstawie klasyfikacji, polityki i rzeczywistego użycia, łącznie z kompromisami szyfrowania.
- Jak długo przechowuje się dane i ich historię, co zaczyna bieg terminu i co się dzieje na końcu.
- Kiedy wystarczy standardowa historia pól, a kiedy regulacja wymaga Field Audit Trail.
- Które zdarzenia są zbierane, gdzie przechowuje się dowody poza okresem retencji platformy i kto jest ich właścicielem.
- Jak architektura dowodzi po fakcie ważnych działań ludzi, integracji i agentów.
Ten rozdział zaczął się od jednej myśli: ład danych projektuje się w orgu, a nie pisze obok niego. Właściciele ustalają politykę, a architekci ją egzekwują. Zatrzymuj złe dane tam, gdzie ma to znaczenie. Wiedz, co znaczą twoje dane, skąd pochodzą i jak bardzo są wrażliwe. Szanuj przepisy, modeluj zgody, kontroluj, dokąd trafiają dane osobowe. Chroń, przechowuj i usuwaj zgodnie z polityką. I zbieraj dowody, zanim ktokolwiek o nie poprosi, bo pół roku po incydencie to fatalny moment, żeby odkryć, że dowody istniały tylko przez trzydzieści dni.
Do zgłębienia
Dział zatytułowany „Do zgłębienia ”- Pomoc Salesforce, General Shield Platform Encryption Considerations (opens in a new tab) i Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
- Pomoc Salesforce, Field History Tracking Overview (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
- Pomoc Salesforce, Field Audit Trail (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
- Pomoc Salesforce, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
- Pomoc Salesforce, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.