Захищати, зберігати і доводити

🌐 Також доступно 28 мовами

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)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 6 з 6 розділу Якість даних і врядування, розділ 5 курсу Data Architect. Кожен модуль самостійний. Попередній: Згода і право на забуття · Наступний: наступний розділ, Основні дані та ідентичність

Питання, на яке відповідає цей модуль: Як захистити дані, зберігати їх стільки, скільки потрібно, і довести це?

Ми встановили власників і політики, не пустили погані дані, написали словник, простежили походження, класифікували важливе, вивчили закони й змоделювали згоду. Тепер це треба запустити. Дані надходять, використовуються, копіюються й змінюються, старіють, і зрештою частина з них мусить піти. А колись хтось попросить: доведіть, що сталося.

Врядування йде за даними

Я не думаю про врядування як про одну функцію. Я думаю про те, що відбувається з даними від моменту, коли вони входять, до моменту, коли ми з ними закінчили:

Збір → Класифікація → Захист → Використання → Зберігання → Видалення → Аудит

Не сім технічних процесів: сім запитань, на які має відповісти архітектура. Збір і класифікацію ми розглянули: не пускати дорогі помилки (модуль 2) і знати, які дані чутливі (модуль 3). Класифікація вирішує, що відбувається на кожному наступному етапі, тож цей модуль продовжує звідти.

Click to enlarge

Сім запитань на всьому шляху життя даних. Інструменти підтримують політику; вони її не визначають.

Захист: підберіть контроль до даних

Хто може це бачити, змінювати, отримувати? Чи має це бути зашифровано, замасковано поза продакшном, придатне до експорту, досяжне для агента? Тут безпека Salesforce стає частиною врядування даних: спільний доступ, дозволи на об’єкти й поля, шифрування, маскування, доступ інтеграцій. Ці теми заповнюють цілі курси, тож я їх не викладатиму знову. Суть для врядування: захист іде за класифікацією і політикою. Не кожному полю потрібен однаковий захист, не кожному користувачеві — однаковий доступ, не кожній системі нижче за потоком — кожне поле.

Шифрування — контроль, а не відповідність

Для регульованих даних може вимагатися шифрування в стані спокою, і моя позиція: Shield — відповідь на ключові регуляторні вимоги, як ця. Shield Platform Encryption шифрує поля й файли в стані спокою. Але «ми це зашифрували, тож ми відповідаємо вимогам» — хибне двічі. Шифрування — один контроль серед доступу, зберігання, аудиту, згоди, моніторингу, мінімізації й видалення. І воно має функціональні компроміси, під які ви проєктуєте заздалегідь. За стандартної імовірнісної схеми зашифроване поле не можна використовувати в клаузах SOQL WHERE, GROUP BY чи ORDER BY або у фільтрах керування даними; детерміноване шифрування трохи поступається стійкістю, щоб за полем можна було фільтрувати. Зашифровані поля не можуть керувати правилами спільного доступу на основі критеріїв, і за ними не можна сортувати подання списків (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Тож шифрування — не позначка наприкінці. Це архітектурне рішення. Розділ про безпеку даних іде глибше.

Не копіюйте ризик продакшну в sandbox

Продакшн закритий. А потім хтось оновлює full sandbox, і розробники, тестувальники, підрядники й тестові інтеграції тепер мають копії справжніх персональних даних, які їм ніколи не були потрібні. Середовище змінилося; чутливість даних — ні. Інструменти маскування Salesforce існують саме для цього. Зверніть увагу на зміну: керований пакет Data Mask припиняє підтримку 31 грудня 2026 р., а його наступник — Data Mask & Seed (Data Mask (Legacy) (opens in a new tab)). Але інструмент підтримує політику, а запитання йде першим: чи потрібні цьому середовищу взагалі справжні чутливі дані? Якщо тестувати можна на реалістичних нечутливих даних, це краща відповідь.

Використання: дозвіл — не лише про людей

Дані використовують користувачі, інтеграції, аналітика, партнери, автоматизація й агенти. Згода (модуль 5), власність (модуль 1) і класифікація (модуль 3) зустрічаються тут під час роботи. Чи має цей користувач бачити номер телефону отримувача? Чи має його отримати ця інтеграція, чи Snowflake, чи цей агент як grounding? Відповідь не може бути «ну, технічно воно може». Це різниця між можливістю і врядуванням: архітектура вирішує, чи варто.

Зберігання: зберігати все назавжди — не нейтрально

Багато організацій мають випадкову політику зберігання: назавжди. Ніхто цього не вирішував; сховище було, тож дані лишилися. Але зберігання даних коштує сховища і продуктивності, розширює ризики приватності й безпеки, додає обов’язків під час розкриття інформації і дає більше місць для пошуку, коли хтось просить про забуття. Для кожної важливої категорії: навіщо зберігати, як довго, що запускає годинник, чи є юридичний мінімум чи максимум для приватності і що станеться в кінці: архівувати, видалити, деідентифікувати?

І архівування — не те саме, що розв’язати питання зберігання. «Ми це заархівували». А вимога зберігання зникла? Вимога приватності? Безпека? Ви змінили, де живуть дані, а не що вони таке. Архіву потрібні контролі доступу, правила зберігання й видалення, пошук і аудит. Перенесіть персональні дані в архів, про який усі забувають, — і врядування стане гіршим.

Видалення: життєвому циклу потрібен вихід

Видалення — не лише для індивідуальних запитів щодо приватності. Дані досягають кінця строку зберігання; тимчасові записи переживають свою користь; архіви спливають; процес деідентифікує після встановленого часу. Хоч би що казала політика, архітектурі потрібен вихід, а не «зібрати → зберегти → зберегти більше → зберігати вічно». І, як показав модуль 5, видалити запис Salesforce недостатньо, коли копії живуть деінде.

Історія — теж дані

Іноді поточного значення недостатньо. Юридична назва партнера, класифікація клієнта, статус згоди, фінансовий атрибут: бізнесу чи регуляторові може знадобитися знати, яким воно було раніше, коли змінилося і хто його змінив. Ця історія — дані, і їй потрібне власне рішення про зберігання.

Стандартне відстеження історії полів охоплює до 20 полів на об’єкт і зберігає зміни до 18 місяців, а до 24 місяців — лише через API, за допомогою Data Loader чи queryAll() (Field History Tracking Overview (opens in a new tab)). А для довгих текстових полів воно записує лише те, що поле редагували, а не що в ньому було: прогалина, якщо це ваш доказ. Field Audit Trail, частина Shield або окрема покупка, охоплює до 200 полів на об’єкт і зберігає історію, доки ви її не видалите, в архіві, до якого звертаються через API (Field Audit Trail (opens in a new tab)). Моя позиція: стандартна історія полів — варіант за замовчуванням; використовуйте Field Audit Trail, коли регулювання чи обов’язок відповідності вимагає довшої, доказової історії. Не тому, що «аудит звучить добре».

Аудит і моніторинг — не одне й те саме

Історія полів відповідає на запитання про зміни вибраних полів. Ширші запитання (хто входив, хто експортував дані, які API викликали, хто що переглядав) — це моніторинг, і це Event Monitoring. З мого досвіду, він зазвичай потрібен регульованішим клієнтам, і ось моя найсильніша позиція в цьому розділі: налаштуйте його, перш ніж він знадобиться, і заздалегідь спрямуйте події в репозиторій, як-от Splunk чи інша SIEM.

Ось чому. Файли журналів подій зберігаються 1 день без доповнення, і то лише для деяких типів подій; 30 днів за замовчуванням із Shield чи доповненням Event Monitoring і до 365 днів, якщо продовжити зберігання (Event Monitoring FAQ (opens in a new tab)). Усе старіше зникло, якщо ви його не експортували. А платні журнали не можна отримати за жоден період до початку вашого контракту (той самий FAQ): купівля доповнення після інциденту не поверне минуле. Тож одна з найгірших розмов, які може мати архітектор, звучить так: «Чи можемо ми побачити, що сталося пів року тому?» «Ні». «Чому?» «Ми цього не фіксували». Не буває так, щоб ви натрапили на проблему, а потім з’ясували, що не фіксували й не зберігали ці події. Тоді відповідь просто зникла.

Click to enlarge

Налаштуйте це до того, як воно знадобиться.

Але не кидайтеся в «журналюйте все». Що ви намагаєтеся довести? Які події важливі, кому вони потрібні, як довго, хто може читати журнали і чи можуть самі журнали містити чутливі дані? Журналювання створює дані, і цим даним теж потрібне врядування. А доказам потрібен власник: хто володіє репозиторієм, переглядає сповіщення, перевіряє, що зберігання працює, помічає, що потік тихо зламався три місяці тому? Технологія без власності — не врядування; ми повернулися до власника, стюарда й адміністратора з модуля 1.

Доводьте контроль, а не лише конфігурацію

«Дані отримувача доступні лише бригадам, призначеним на зупинку». Як ми це знаємо? Конфігурація безпеки показує, що має статися. Операційні докази (хто насправді мав доступ, незвичні експорти, інтеграція, що їх тягне, змінені контролі доступу) показують, що сталося. Добре врядування часто потребує і того, й іншого.

За межами іспиту: що змінює ШІ. Коли агенти переходять від відповідей до дій, врядуванню потрібні докази того, що агент бачив, що вирішив чи згенерував і що зробив, а також хто чи що його запустив і за якою політикою. Механізми журналювання змінюватимуться; вимога — ні: якщо автономна дія важлива, проєктуйте вже зараз, як ви її пізніше відтворите.

Steve Trucking: життєвий цикл на одному полі

Візьміть номер телефону отримувача. Збір: він надходить у маніфесті партнера; перевірте, що він придатний там, де він потрібен процесу. Класифікація: персональні дані. Захист: його отримують лише люди й системи з операційною потребою, а бригади бачать його лише для своїх зупинок, того дня. Використання: бригада узгоджує доставку; платформа повідомлень використовує його для погодженої мети; агент використовує його, лише якщо дозволяє політика. Зберігання: стільки, скільки каже погоджена бізнес-політика й політика приватності. Видалення чи деідентифікація: коли цей строк закінчується або надходить дійсний запит, у кожній копії на ландшафті. Аудит: зберігайте докази, що контролі й дії відбулися.

Тепер візьміть код розподільчого центру. Зафіксуйте його точно, класифікуйте як нечутливі довідкові дані, захистіть звичайним операційним доступом, використовуйте широко, зберігайте, скільки потрібно бізнесу, і аудитуйте зміни, якщо вони важливі. Той самий життєвий цикл, інші контролі. Для цього й існує класифікація.

Врядування ніколи не завершене

З’являється нове регулювання. Нова система чи інтеграція створює ще одну копію. Команда вигадує ще одне поле. Запускається нова платформа. Агент отримує доступ. Правило зберігання змінюється. Приходить новий роздрібний партнер. Архітектура рухається, і врядування рухається разом із нею. Мета — не ідеальні дані, нескінченні контролі чи документ про врядування, якого ніхто не читає. Мета — свідомі рішення щодо даних, вбудовані в архітектуру.

Що тут вирішує архітектор

• Які контролі захисту отримує кожна категорія даних, виходячи з класифікації, політики й реального використання, зокрема компроміси шифрування.
• Як довго зберігаються дані та їхня історія, що запускає годинник і що станеться в кінці.
• Коли стандартної історії полів достатньо, а коли регулювання вимагає Field Audit Trail.
• Які події фіксуються, де зберігаються докази понад строк зберігання платформи і хто ними володіє.
• Як архітектура доводить важливі дії людей, інтеграцій і агентів постфактум.

Цей розділ почався з однієї ідеї: врядування закладається в org, а не пишеться поруч. Власники встановлюють політику, а архітектори її забезпечують. Не пускайте погані дані там, де це важливо. Знайте, що означають ваші дані, звідки вони і наскільки чутливі. Поважайте закони, моделюйте згоду, контролюйте, куди йдуть персональні дані. Захищайте, зберігайте й видаляйте за політикою. І фіксуйте докази, перш ніж хтось про них попросить, бо через пів року після інциденту — жахливий час дізнатися, що докази існували лише тридцять днів.

Додаткові матеріали

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) і Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Field Audit Trail (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (англійською, перевірено 2026-10-14).
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (англійською, перевірено 2026-10-14).