Схемы защиты данных


Узнайте больше о Well-Architected T Trust → Защита и конфиденциальность данных

Шаблоны

Где искатьКак хорошо выглядит
Схема классификации данных✅ Схема классификации, документированная с уровнями (Общедоступный, внутренний, конфиденциальный, ограниченный)
✅ Примеры предприятий, предоставленные для каждого уровня классификации
✅ Схема классификации, согласованная с нормативными обязательствами (HIPAA, PCI DSS, GDPR)
✅ Моделировщики данных обучены последовательно применять классификацию во время проектирования
✅ Новые поля, классифицированные как часть процесса моделирования данных, а не задним числом
Классификация уровня поля✅ Классификация применяется на уровне поля, а не только на уровне объекта
✅ Поля в одном объекте могут иметь разные классификации
✅ Безопасность поля отображает различия классификации
✅ Неклассифицированные данные по умолчанию имеют самый высокий соответствующий уровень защиты
✅ Классификация управляет средствами защиты (шифрование, доступ, сохранность)
Настраиваемые объекты и поля✅ Все настраиваемые объекты имеют документированную классификацию данных
✅ Конфиденциальные поля (зарплата, SSN, PHI, данные оплаты), классифицированные как конфиденциальные или ограниченные
✅ Общедоступные поля (название компании, веб-сайт), задокументированные как общедоступные
✅ Метаданные классификации, собранные в описания полей
✅ Классификация, рассмотренная во время проверки кода и АРБ
Стандартные объекты✅ Поля стандартного объекта, оцениваемые по схеме классификации
✅ Shield Platform Encryption включен для стандартных полей «Ограничено»
✅ Безопасность поля, примененная к конфиденциальным стандартным полям
✅ Отчеты и списковые представления отфильтрованы для предотвращения открытия конфиденциальных стандартных полей
Данные интеграции✅ Данные, проходящие через интеграции, классифицированные до внедрения
✅ Оценка и документирование конфиденциальности данных внешней системы
✅ Обработка конечных точек интеграции Проверка подлинности на основе сертификата использования ограниченных данных
✅ Классификация данных, сохраненная в границах системы
Соотнесение соответствия✅ Определенные и обозначенные поля HIPAA ограничены
✅ Данные держателя карты PCI избегаются в Salesforce, когда это возможно: маркируются посредством шлюза оплаты для уменьшения области; где они должны храниться, используйте зашифрованные настраиваемые поля под управлением PCI DSS
✅ Личные данные GDPR, идентифицированные и подлежащие контролю конфиденциальности
✅ Финансовые данные SOX классифицированы и подлежат разделению обязанностей

Антишаблоны

Где искатьКак плохо выглядит
Равномерная защита⚠️ Одинаковая защита, применяемая ко всем полям, независимо от конфиденциальности
⚠️ Малозначные данные перезащищены (трата ресурсов), в то время как ценные данные недозащищены
⚠️ Сведения о публичной компании, обрабатываемые так же, как данные PHI или платежной карты
⚠️ Каждое поле, зашифрованное “на всякий случай” без обоснования классификации
Ретроактивная классификация⚠️ Данные, классифицированные после развертывания в производственной среде
⚠️ Конфиденциальные данные, обнаруженные в ходе аудита соответствия, а не проверки проектирования
⚠️ Данные, засекреченные только после инцидентов безопасности
⚠️ «Классификацию решим позже» по умолчанию во время разработки
Классификация только на уровне объекта⚠️ Целые объекты, классифицированные равномерно, если поля имеют разную чувствительность
⚠️ Доступ на уровне объекта предоставлен без безопасности поля для конфиденциальных полей
⚠️ Все поля в объектах «Организация» или «Контакт», предположительно имеющие одинаковую классификацию
⚠️ Полномочия объекта, используемые в качестве единственного элемента управления доступом для объектов со смешанной конфиденциальностью
Племенные Knowledge⚠️ Классификация не задокументирована, существует только в знаниях ключевых людей
⚠️ Разработчики полагались на “просто знать”, какие поля конфиденциальны
⚠️ Нет письменной схемы классификации, доступной всем разработчикам модели данных
⚠️ Привлечение новых участников рабочей группы без классификационной подготовки

Шаблоны

Где искатьКак хорошо выглядит
Шифрование в дежурном режиме✅ Все данные, зашифрованные на уровне инфраструктуры посредством Hyperforce
✅ Shield Platform Encryption включено для данных ограниченного доступа
✅ Схема шифрования (вероятностная, детерминистская, чувствительная к регистру детерминистская), выбранная на основе запроса и требований уникальности
✅ Компромиссы шифрования, оцениваемые во время проектирования модели данных
Стратегия Shield Platform Encryption✅ Вероятностное шифрование, используемое для большинства ограниченных полей (поддерживает все операции запроса)
✅ Детерминистское шифрование, используемое для полей, требующих точного совпадения условий WHERE или уникальности
✅ Чувствительный к регистру детерминистский, используемый там, где различие обращений имеет значение для бизнес-логики
✅ Алгоритм зашифрованного поля протестирован перед развертыванием в производственной среде
✅ Ссылки полей формулы на зашифрованные поля, обработанные надлежащим образом (при необходимости перемещенные в Apex)
Управление ключами✅ Документирование и автоматизация процедур ротации ключей
✅ Ключевые сценарии уничтожения проверены во время учений по аварийному восстановлению
✅ Управляемые клиентом ключи (BYOK) оцениваются на соответствие, требующее четкого контроля ключей
✅ Ключевые процедуры отзыва задокументированы
✅ Жизненный цикл ключа шифрования управляется в соответствии с требованиями соответствия
Шифрование в пути✅ Для всех интеграций требуется TLS 1.2 или выше
✅ Взаимная проверка подлинности на основе сертификата для интеграций, обрабатывающих ограниченные данные
✅ Заголовки HSTS, настроенные для сайтов Experience Cloud для предотвращения понижения уровня протокола
✅ Мониторинг истечения срока действия сертификата TLS и настройка автоматического продления
✅ Отключены слабые шифры и протоколы
Код и конфигурация✅ Регистрационные данные, не встроенные в код, файлы конфигурации или управление версиями
✅ Именованные регистрационные данные и внешние регистрационные данные, используемые для централизованного управления проверкой подлинности
✅ Возможности ротации регистрационных данных, встроенные в архитектуру
✅ Именованные регистрационные данные абстрактная проверка подлинности из кода, включение обновлений без изменений кода
Пакеты AppExchange✅ Требования безопасности пакета, оцениваемые перед установкой
✅ Зашифрованные поля, доступные пакетам только при наличии бизнес-оправданий
✅ Схемы доступа к данным пакета, отслеживаемые посредством мониторинга событий
✅ Пакеты, требующие доступа к ограниченным данным, подлежащим расширенной проверке

Антишаблоны

Где искатьКак плохо выглядит
Шифрование без оценки⚠️ Вероятностное шифрование включено во всех полях без тестирования
⚠️ Важные отчеты, обнаруженные в производстве, не выполняются, поскольку зашифрованные поля нельзя агрегировать
⚠️ Шифрование включено в источниках полей формулы без понимания влияния
⚠️ Поля, используемые в SOQL LIKE запросы, зашифрованные без переключения на детерминистское шифрование
Встроенные регистрационные данные⚠️ Регистрационные данные, встроенные в код, настраиваемые параметры или управление версиями
⚠️ Ключи API, пароли и сертификаты, жестко запрограммированные в классах Apex
⚠️ Регистрационные данные, принятые в хранилища контроля источников
⚠️ Регистрационные данные, сохраненные в настраиваемых метаданных или настраиваемых параметрах без шифрования
Слабые или устаревшие протоколы⚠️ TLS 1.0 или 1.1 принят (не рекомендуется и уязвим)
⚠️ Процесс OAuth имени пользователя и пароля разрешен при наличии носителя JWT
⚠️ Самозаверенные сертификаты, принимаемые в производственных интеграциях
⚠️ Проверка сертификата отключена «чтобы интеграция работала»
Управление ключами отсутствует⚠️ Shield Platform Encryption включен без процедур ротации ключей
⚠️ Нет задокументированных ключевых сценариев уничтожения
⚠️ Стандартные ключи, используемые без оценки управляемых клиентом ключей на соответствие
⚠️ Процедуры ротации и отзыва ключей не тестировались
Перешифрование⚠️ Общедоступные или внутренние данные классификации зашифрованы, что добавляет стоимость без каких-либо преимуществ
⚠️ Shield Platform Encryption включен в каждом поле, что создает ненужные сложности
⚠️ BYOK используется, когда соответствие не требует этого (добавляет операционные накладные расходы)
⚠️ Шифрование обязательно, если классификация данных не оправдывает его

Шаблоны

Где искатьКак хорошо выглядит
Стратегия безопасной среды✅ Ограниченные данные никогда не попадают в среды разработки или тестирования
✅ Частичное копирование безопасной среды исключает ограниченные объекты и поля
✅ Шаблоны безопасной среды определяют, какие объекты и поля добавлять по типу среды
✅ Data Mask настроена для безопасных сред, требующих данных производственного назначения
Правила Data Mask✅ Правила Data Mask затушевывают конфиденциальные поля, сохраняя характеристики данных
✅ Шаблоны поддерживают целостность регистрационных данных (одинаковый ввод создает одинаковый маскируемый вывод)
✅ Адреса эл. почты маскируются, но остаются действительным форматом для тестирования
✅ Номера телефонов замаскированы, но остаются действительными в формате
✅ Смещенные даты последовательно сохраняют относительные взаимосвязи
✅ Числовые поля, рандомизированные в реалистичных диапазонах
Синтетические данные✅ Среды разработки используют создание синтетических данных
✅ Синтетические данные имеют реалистичные характеристики, позволяющие эффективно тестировать
✅ Для разработки не требуются производственные данные
✅ Создание тестовых данных автоматизировано в ожидаемых продажах разработки
Непроизводственные среды✅ Производственные данные никогда не копировались в личные организации разработчика
✅ Сборы экрана и демонстрационные ролики используют маскируемые или синтетические данные
✅ Учебные среды используют синтетические данные или сильно замаскированные производственные данные
✅ Доступ подрядчика и поставщика к непроизводственным данным ограничен классификацией «Только бизнес-использование»

Антишаблоны

Где искатьКак плохо выглядит
Производственные данные в безопасных средах⚠️ Полные безопасные среды обновлены с помощью немаскированных производственных данных для разработки
⚠️ Ограниченные данные, копируемые в безопасные среды разработчика для удобства
⚠️ Разработчикам предоставлен широкий доступ к безопасным средам с производственными данными
⚠️ Безопасные среды обновлены конфиденциальными данными, “поскольку тестирование проще с реальными данными”
Нет синтетических данных⚠️ Производственные данные опираются исключительно на все тесты
⚠️ Отсутствие создания синтетических данных для сред разработки
⚠️ «Нам нужны реальные данные» предполагает без оценки синтетических альтернатив
⚠️ Данные тестирования, созданные вручную, когда создание можно автоматизировать

Шаблоны

Где искатьКак хорошо выглядит
Минимизация данных✅ Собраны только данные, необходимые для указанных бизнес-целей
✅ Каждое добавление поля, заданное вопросом “какое архитектурное решение требует этих данных?”
✅ Данные, больше не служащие цели коллекции, удалены
✅ Дополнительные поля четко обозначены и не обязательны без бизнес-обоснования
✅ Хранение архивных данных соответствует правовой основе, а не «хранить все вечно»
Ограничение цели✅ Наборы полномочий ограничивают доступ к данным на основе цели функции задания
✅ Пользователи Marketing не имеют доступа к сведениям об обращении за поддержкой без документального подтверждения
✅ Пользователи по продажам не имеют доступа к журналам обслуживания клиентов, если это не требуется заданием
✅ Межфункциональный доступ к данным требует четкого утверждения и мониторинга
✅ Цель доступа к данным задокументирована в описаниях наборов полномочий
Управление согласием✅ Сбор согласия на индивидуальном уровне для маркетинга, аналитики, дополнительной обработки
✅ Согласие является детальным (целевым), а не двоичным общим согласием
✅ Бизнес-процессы отзыва согласия распространяются в интегрированных системах
✅ Отслеживание решений согласия с отметкой времени, версией и механизмом
✅ Пользовательский интерфейс согласия четко объясняет, на что соглашается пользователь
Права субъекта данных✅ Бизнес-процессы запроса доступа предоставляют копии данных в срок, установленный управляющим регламентом для развертывания
✅ Бизнес-правила исправления исправляют неточности с помощью контрольного журнала
✅ Удаление бизнес-правил при наличии юридически допустимых данных (учитывая обязательства по сохранению)
✅ Переносимость бизнес-правил экспортирует данные в машиночитаемом формате
✅ Бизнес-правила прав субъекта данных регулярно тестируются для проверки временных шкал
✅ Автоматизация бизнес-правил обеспечивает последовательное соблюдение нормативных сроков
Средства контроля конфиденциальности✅ Контроль конфиденциальности внедрен технически, а не только посредством политики
✅ Правила общего доступа реализуют ограничение цели
✅ Безопасность поля защищает конфиденциальные атрибуты
✅ Контрольные журналы собирают события, связанные с конфиденциальностью
✅ Средства контроля конфиденциальности проверены в ожидаемых продажах CI/CD

Антишаблоны

Где искатьКак плохо выглядит
Соберите все⚠️ Подход «Соберите все возможные данные, они могут когда-нибудь понадобиться»
⚠️ Поля, добавленные без задокументированной бизнес-цели
⚠️ Данные хранятся неопределенно долго без обоснования сохранности
⚠️ Дополнительные данные, собранные путем назначения полей обязательными
Одеяло согласия⚠️ Единое согласие “согласиться на условия” для всех целей
⚠️ Маркетинговое согласие в сочетании с предоставлением услуг в одном поле с флажком
⚠️ Согласие, сделанное «все или ничего», когда цели разделимы
⚠️ Согласие похоронено в 20-страничных условиях
Политика без принудительной реализации⚠️ Политика конфиденциальности описывает идеальные практики, которые не применяются технически
⚠️ Обучение пользователей использовалось для предотвращения ненадлежащего доступа к данным
⚠️ Принципы конфиденциальности документированы без внедрения технических средств контроля
⚠️ Соответствие политике предполагается без мониторинга и проверки
Запросы темы данных вручную⚠️ Запросы GDPR/CCPA обрабатываются посредством ручных ИТ-билетов, требующих месяцев
⚠️ Отсутствие задокументированных процедур доступа, исправления, удаления, переносимости
⚠️ Окно запроса-завершения, определяемое управляющим регламентом для развертывания, пропущено
⚠️ Запрос на отсутствие бизнес-правил, обнаруженных во время аудита
Чрезмерный общий доступ к данным⚠️ Широкий доступ к данным, предоставленный департаментам без обоснования цели
⚠️ Маркетинг разрешил доступ к сведениям об обращении за поддержкой
⚠️ Разрешенный доступ к журналам обслуживания клиентов без документально подтвержденной необходимости
⚠️ Общедоступный OWD для чтения и записи, используемый для объектов, содержащих личные данные

Шаблоны

Где искатьКак хорошо выглядит
Региональное развертывание Hyperforce✅ Инициализация организации в регионе Hyperforce, соответствующая требованиям к резидентству данных
✅ Хранение и обработка данных осуществляются в пределах обязательных географических границ
✅ Региональные требования, документированные и проверенные до обеспечения
✅ Удовлетворение потребностей нескольких регионов посредством архитектуры нескольких организаций, при необходимости
Соотнесение потока данных✅ Документ соотнесения потока данных, где данные происходят, транзитируются и находятся
✅ Трансграничные перемещения данных, выявленные и оцененные в сопоставлении с нормативными актами
✅ Стандартные договорные положения или обязательные корпоративные правила для международных передач
✅ Пути транзита данных оцениваются на соответствие резидентству, а не только на наличие расположения хранилища
Область резидентства данных✅ Расположение хранилища данных (какой регион Hyperforce)
✅ Расположение обработки данных (регионы вычисления)
✅ Расположение резервного хранилища
✅ Место хранения журнала и контрольного журнала
✅ Оценены пути транзита интеграции для трансграничного перемещения данных
Архитектура нескольких организаций✅ Мультиорганизационная архитектура, используемая, когда нормативные требования не могут быть выполнены в рамках одной организации
✅ Каждая организация, инициализированная в соответствующем регионе для своих данных
✅ Схемы интеграции учитывают ограничения резидентства данных
✅ Компромиссы операционной сложности, зафиксированные в ДОПОГ
Проверка соответствия✅ Требования к резидентству данных, документированные по юрисдикции
✅ Выбор региона Hyperforce проверен по требованиям перед инициализацией
✅ Периодические проверки подтверждают, что данные остаются в требуемых границах
✅ Изменения в правилах проживания инициируют пересмотр архитектуры

Антишаблоны

Где искатьКак плохо выглядит
Надзор за резидентурой⚠️ Нарушения резидентства данных, обнаруженные во время проверок соответствия
⚠️ Обеспечение организаций без оценки региональных требований
⚠️ “Облако - это облако” предполагает без учета регламентов расположения данных
⚠️ Юрисдикции добавлены без проверки обязательств по резидентству
Резиденция игнорирования транзита⚠️ Учитывается только расположение хранилища при игнорировании путей транзита
⚠️ Данные, перенаправленные через регионы за пределами границ соответствия
⚠️ Промежуточное программное обеспечение интеграции, используемое в несоответствующих регионах
⚠️ Резервные копии, хранящиеся в разных регионах, кроме основных данных
Ненужная мультиорганизация⚠️ Мультиорганизационная архитектура, используемая, когда одной организации с областями Hyperforce достаточно
⚠️ Умножение операционной сложности, расходов на лицензирование и накладных расходов на интеграцию без необходимости регулирования
⚠️ Мультиорганизация внедрена «на всякий случай» без конкретного требования соответствия
⚠️ Мультиорганизация, используемая по умолчанию, когда достаточно классификации данных и элементов управления доступом