Chraňte, uchovávejte a prokazujte

🌐 K dispozici také v 29 jazycích

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 6 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Souhlas a právo být zapomenut · Další: další kapitola, Kmenová data a identita

Otázka, na kterou tento modul odpovídá: Jak data chránit, uchovávat je tak dlouho, jak je třeba, a prokázat to?

Stanovili jsme vlastníky a zásady, nepustili dovnitř špatná data, napsali slovník, vystopovali původ, klasifikovali, na čem záleží, naučili se zákony a namodelovali souhlas. Teď to musíme provozovat. Data přicházejí, používají se, kopírují a mění, stárnou a nakonec část z nich musí pryč. A jednoho dne se někdo zeptá: prokažte, co se stalo.

Správa dat následuje data

Správu dat nevnímám jako jednu funkci. Přemýšlím o tom, co se s daty děje od chvíle, kdy vstoupí, dokud s nimi neskončíme:

Zachytit → Klasifikovat → Chránit → Používat → Uchovávat → Smazat → Auditovat

Ne sedm technických procesů: sedm otázek, na které musí architektura odpovědět. Zachycení a klasifikaci jsme probrali: nepustit dovnitř drahé chyby (modul 2) a vědět, která data jsou citlivá (modul 3). Klasifikace rozhoduje o tom, co se stane v každé další fázi, takže tento modul navazuje odtud.

Kliknutím zvětšíte

Sedm otázek napříč životem dat. Nástroje zásadu podporují; nedefinují ji.

Chránit: přizpůsobte kontrolu datům

Kdo je smí vidět, měnit, dostávat? Mají být šifrovaná, mimo produkci maskovaná, exportovatelná, dosažitelná agentem? Tady se zabezpečení Salesforce stává součástí správy dat: sdílení, oprávnění k objektům a polím, šifrování, maskování, přístup integrací. Tato témata plní celé kurzy, takže je znovu učit nebudu. Pointa správy dat: ochrana se řídí klasifikací a zásadou. Ne každé pole potřebuje stejnou ochranu, ne každý uživatel stejný přístup, ne každý systém po proudu každé pole.

Šifrování je kontrola, ne soulad

U regulovaných dat může být šifrování v klidu povinné a můj postoj zní, že Shield je odpovědí na klíčové regulatorní požadavky, jako je tento. Shield Platform Encryption šifruje pole a soubory v klidu. „Zašifrovali jsme to, takže jsme v souladu“ je ale dvakrát špatně. Šifrování je jedna kontrola z mnoha vedle přístupu, uchovávání, auditu, souhlasu, monitorování, minimalizace a výmazu. A má funkční kompromisy, se kterými musíte při návrhu počítat předem. S výchozím pravděpodobnostním (probabilistic) schématem nelze šifrované pole použít v klauzulích SOQL WHERE, GROUP BY nebo ORDER BY ani ve filtrech správy dat; deterministické šifrování se trochu vzdá síly, abyste podle pole mohli filtrovat. Šifrovaná pole nemohou řídit pravidla sdílení podle kritérií a podle nich nelze řadit zobrazení seznamů (General Shield Platform Encryption Considerations (otevře se v nové kartě); Filter Encrypted Data with Deterministic Encryption (otevře se v nové kartě)). Šifrování tedy není zaškrtávací políčko na konci. Je to architektonické rozhodnutí. Kapitola o zabezpečení dat jde hlouběji.

Nekopírujte riziko z produkce do sandboxu

Produkce je zamčená. Pak někdo obnoví plný sandbox a vývojáři, testeři, dodavatelé a testovací integrace teď drží kopie skutečných osobních údajů, které nikdy nepotřebovali. Prostředí se změnilo; citlivost dat ne. Přesně pro tohle existují nástroje Salesforce pro maskování. Všimněte si změny: spravovaný balíček Data Mask končí s podporou 31. prosince 2026 a jeho nástupcem je Data Mask & Seed (Data Mask (Legacy) (otevře se v nové kartě)). Nástroj ale zásadu jen podporuje a otázka přichází první: potřebuje toto prostředí skutečná citlivá data vůbec? Pokud testování zvládnou realistická, necitlivá data, je to lepší odpověď.

Používat: oprávnění není jen o lidech

Data používají uživatelé, integrace, analytika, partneři, automatizace i agenti. Souhlas (modul 5), vlastnictví (modul 1) a klasifikace (modul 3) se tu potkávají za běhu. Má tento uživatel vidět telefonní číslo příjemce? Má ho dostat tato integrace, nebo Snowflake, nebo tento agent jako ukotvení? Odpověď nemůže znít „no, technicky to jde“. To je rozdíl mezi schopností a správou dat: architektura rozhoduje, jestli by to mělo jít.

Uchovávat: uchovávat všechno navždy není neutrální

Mnoho organizací má náhodnou politiku uchovávání: navždy. Nikdo o ní nerozhodl; úložiště bylo k dispozici, tak data zůstala. Uchovávání dat ale stojí úložiště i výkon, rozšiřuje expozici z hlediska soukromí a bezpečnosti, přidává povinnosti při vyhledávání a dává vám víc míst k prohledání, když někdo požádá o zapomenutí. U každé důležité kategorie: proč ji uchovávat, jak dlouho, co spouští lhůtu, existuje zákonné minimum nebo maximum kvůli soukromí a co se stane na konci: archivovat, smazat, deidentifikovat?

A archivace není totéž co vyřešené uchovávání. „Archivovali jsme to.“ Zmizel požadavek na uchovávání? Požadavek na soukromí? Bezpečnost? Změnili jste, kde data žijí, ne čím jsou. Archiv potřebuje řízení přístupu, pravidla uchovávání a mazání, vyhledávání i audit. Přesuňte osobní údaje do archivu, na který všichni zapomenou, a správa dat se právě zhoršila.

Smazat: životní cyklus potřebuje východ

Mazání není jen pro jednotlivé žádosti o ochranu soukromí. Data dosáhnou konce své doby uchovávání; dočasné záznamy přežijí své použití; archivy vyprší; proces po stanovené době deidentifikuje. Ať zásada říká cokoli, architektura potřebuje východ, ne zachytit → uložit → uložit víc → uložit navždy. A jak ukázal modul 5, smazání záznamu v Salesforce nestačí, když kopie žijí jinde.

I historie jsou data

Někdy aktuální hodnota nestačí. Oficiální název partnera, klasifikace zákazníka, stav souhlasu, finanční atribut: byznys nebo regulátor může potřebovat vědět, jaká hodnota byla předtím, kdy se změnila a kdo ji změnil. Tato historie jsou data a potřebuje vlastní rozhodnutí o uchovávání.

Standardní sledování historie polí (field history tracking) sleduje až 20 polí na objekt a uchovává změny až 18 měsíců a až 24 měsíců jen přes API, s Data Loaderem nebo queryAll() (Field History Tracking Overview (otevře se v nové kartě)). A u dlouhých textových polí zaznamená jen to, že bylo pole upraveno, ne co v něm stálo: mezera, pokud je to váš důkaz. Field Audit Trail, součást Shield nebo kupovaný samostatně, sleduje až 200 polí na objekt a historii uchovává, dokud ji nesmažete, v archivu, ke kterému se dostanete přes API (Field Audit Trail (otevře se v nové kartě)). Můj postoj: standardní historie polí je výchozí volba; Field Audit Trail použijte, když předpis nebo povinnost souladu vyžaduje delší, prokazatelnou historii. Ne proto, že „audit zní dobře“.

Audit a monitorování nejsou totéž

Historie polí odpovídá na otázky o změnách vybraných polí. Širší otázky (kdo se přihlásil, kdo exportoval data, která API se volala, kdo si co prohlížel) jsou monitorování, a to je Event Monitoring. Podle mých zkušeností ho typicky potřebují regulovanější zákazníci, a tady je můj nejsilnější postoj v této kapitole: nastavte ho dřív, než ho budete potřebovat, a události předem posílejte do úložiště, jako je Splunk nebo jiný SIEM.

Tady je proč. Soubory protokolů událostí se bez doplňku uchovávají 1 den, a jen pro některé typy událostí; se Shield nebo doplňkem Event Monitoring ve výchozím stavu 30 dní a až 365 dní, pokud uchovávání prodloužíte (Event Monitoring FAQ (otevře se v nové kartě)). Cokoli staršího je pryč, pokud jste to nevyexportovali. A placené protokoly nelze získat za žádné období před začátkem vaší smlouvy (stejné FAQ): koupě doplňku po incidentu minulost nevrátí. Jeden z nejhorších rozhovorů, jaké může architekt vést, tedy zní: „Můžeme se podívat, co se stalo před šesti měsíci?“ „Ne.“ „Proč ne?“ „Nezachytávali jsme to.“ Nechcete narazit na problém a teprve pak zjistit, že jste ty události nezachytávali a neukládali. Tehdy už je odpověď prostě pryč.

Kliknutím zvětšíte

Nastavte to dřív, než to budete potřebovat.

Nepřeskočte ale k „logujte všechno“. Co se snažíte prokázat? Na kterých událostech záleží, kdo je potřebuje, jak dlouho, kdo smí protokoly číst a nemohou samy protokoly obsahovat citlivá data? Logování vytváří data a ta data potřebují také správu. A důkazy potřebují vlastníka: kdo vlastní úložiště, prověřuje výstrahy, kontroluje, že uchovávání funguje, všimne si, že tok před třemi měsíci potichu selhal? Technologie bez vlastnictví není správa dat; jsme zpátky u vlastníka, správce a technického správce z modulu 1.

Prokažte kontrolu, ne jen konfiguraci

„Data příjemců jsou dostupná jen posádkám přiřazeným k zastávce.“ Jak to víme? Konfigurace zabezpečení ukazuje, co se má dít. Provozní důkazy (kdo k nim skutečně přistupoval, neobvyklé exporty, integrace, která je stahuje, změněné řízení přístupu) ukazují, co se stalo. Dobrá správa dat často potřebuje obojí.

Nad rámec zkoušky: co mění AI. Jak agenti přecházejí od odpovídání k jednání, potřebuje správa dat důkazy o tom, co agent viděl, co rozhodl nebo vygeneroval a co udělal, a kdo nebo co ho spustilo, podle jaké zásady. Mechanismy logování se změní; požadavek ne: pokud na autonomní akci záleží, navrhněte už teď, jak ji později zrekonstruujete.

Steve Trucking: životní cyklus na jednom poli

Vezměte telefonní číslo příjemce. Zachytit: přichází na manifestu partnera; zkontrolujte, že je použitelné tam, kde ho proces potřebuje. Klasifikovat: osobní údaj. Chránit: dostávají ho jen lidé a systémy s provozní potřebou a posádky ho vidí jen u svých vlastních zastávek, v daný den. Používat: posádka koordinuje doručení; zasílání zpráv ho používá ke schválenému účelu; agent ho použije, jen pokud to zásady dovolují. Uchovávat: tak dlouho, jak říká schválená obchodní zásada a zásada ochrany soukromí. Smazat nebo deidentifikovat: když ta doba skončí nebo přijde platná žádost, napříč každou kopií v krajině. Auditovat: uchovejte důkazy, že kontroly a kroky proběhly.

Teď vezměte kód distribučního centra. Zachyťte ho přesně, klasifikujte ho jako necitlivá referenční data, chraňte ho běžným provozním přístupem, používejte ho široce, uchovávejte ho podle potřeb byznysu a auditujte změny, pokud na nich záleží. Stejný životní cyklus, jiné kontroly. K tomu je klasifikace.

Správa dat nikdy nekončí

Objeví se nový předpis. Nový systém nebo integrace vytvoří další kopii. Tým vymyslí další pole. Spustí se nová platforma. Agent dostane přístup. Změní se pravidlo uchovávání. Přijde nový maloobchodní partner. Architektura se hýbe a správa dat se hýbe s ní. Cílem nejsou dokonalá data, nekonečné kontroly ani dokument o správě dat, který nikdo nečte. Jsou to záměrná rozhodnutí o datech, zabudovaná do architektury.

Co tady rozhoduje architekt

• Jaké kontroly ochrany dostane každá kategorie dat, podle klasifikace, zásad a skutečného používání, včetně kompromisů šifrování.
• Jak dlouho se uchovávají data a jejich historie, co spouští lhůtu a co se stane na konci.
• Kdy stačí standardní historie polí a kdy předpis vyžaduje Field Audit Trail.
• Které události se zachytávají, kde se důkazy uchovávají déle, než je uchovává platforma, a kdo je vlastní.
• Jak architektura dodatečně prokazuje důležité akce lidí, integrací a agentů.

Tato kapitola začala jednou myšlenkou: správa dat se navrhuje do orgu, nepíše se vedle něj. Vlastníci stanovují zásady a architekti je vynucují. Kde na tom záleží, nepouštějte dovnitř špatná data. Vězte, co vaše data znamenají, odkud přišla a jak jsou citlivá. Respektujte zákony, modelujte souhlas, řiďte, kam osobní údaje jdou. Chraňte, uchovávejte a mažte podle zásad. A zachyťte důkazy dřív, než o ně kdokoli požádá, protože šest měsíců po incidentu je strašná doba na zjištění, že důkazy existovaly jen třicet dní.

K prozkoumání

• Salesforce Help, General Shield Platform Encryption Considerations (otevře se v nové kartě) a Filter Encrypted Data with Deterministic Encryption (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Field History Tracking Overview (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Field Audit Trail (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (otevře se v nové kartě), ověřeno 2026-10-17.