Защищать, хранить и доказывать

🌐 Также доступно на 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 шифрует поля и файлы при хранении. Но «мы зашифровали, значит, мы соответствуем требованиям» — дважды неверно. Шифрование — одно средство контроля среди многих: доступ, хранение, аудит, согласие, мониторинг, минимизация и удаление. И у него есть функциональные компромиссы, которые нужно учесть при проектировании заранее. При схеме по умолчанию, вероятностной (probabilistic), зашифрованное поле нельзя использовать в предложениях SOQL WHERE, GROUP BY или ORDER BY и в фильтрах управления данными; детерминированное (deterministic) шифрование немного жертвует стойкостью, чтобы по полю можно было фильтровать. Зашифрованные поля не могут управлять правилами общего доступа на основе критериев, и по ним нельзя сортировать представления списков (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). Так что шифрование — не флажок в самом конце. Это архитектурное решение. Глава о безопасности данных разбирает это глубже.

Не копируйте риски рабочей среды в песочницу

Рабочая среда закрыта. Потом кто-то обновляет полную песочницу, и у разработчиков, тестировщиков, подрядчиков и тестовых интеграций теперь есть копии реальных персональных данных, которые им никогда не были нужны. Среда изменилась; чувствительность данных — нет. Инструменты маскирования 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).