Trust

В Salesforce Trust - это наше значение No1. Это основа каждого архитектурного решения на платформе. Для архитекторов Trust достигается посредством уникального партнерства: Salesforce предоставляет безопасную совместимую платформу — инфраструктуру, метаданные и инструменты для создания собственной платформы, — а вы разрабатываете безопасные решения, основанные на этой основе.

Это партнерство функционирует на основе модели общей ответственности, которая представляет собой основу, позволяющую четко разделить обязанности по обеспечению безопасности:

• Salesforce отвечает за безопасность платформы, включая инфраструктуру, исправление и сертификацию соответствия.
• Вы ответственны за безопасность на платформе, включая конфигурацию, управление доступом, настраиваемый код и управление данными.

Это разделение необходимо, поскольку оно определяет архитектурную подотчетность. Salesforce использует многопользовательскую архитектуру, в которой тысячи организаций используют инфраструктуру. Платформа обеспечивает надежные средства защиты на уровне инфраструктуры. Ваши архитектурные решения определяют, заслужили ли ваши конкретные решения доверие заинтересованных лиц.

Модель общей ответственности возлагает на вас ответственность за разработку безопасных решений, а физическая безопасность, защита сети, исправление платформы и шифрование инфраструктуры выполняются за вас. Это позволяет сосредоточиться на разработке безопасных решений, основанных на этой основе (например, управление удостоверениями и доступом, защита данных, безопасность интеграции, безопасные практики разработки, соответствие и соблюдение нормативных требований, а также возможности реагирования на инциденты).

Пренебрежение Trust во время проектирования усугубляет техническую задолженность. Отсутствующая стратегия шифрования становится дорогостоящей модернизацией при изменении регламента. Неуправляемая интеграция становится уязвимой при нарушении регистрационных данных. Building Trust in с самого начала стабильно обходится дешевле, чем его переоснащение позже.

Trust охватывает четыре архитектурных измерения, которые слаженно работают вместе:

• Средства управления безопасностью защищают системы и данные
• Управление удостоверениями управляет доступом
• Практика конфиденциальности учитывает агентство пользователя
• Базовые принципы соблюдения соответствуют нормативным обязательствам

Архитекторы, создающие дизайн для всех четырех измерений, создают решения, которые зарабатывают и поддерживают Trust посредством прозрачности, контроля и устойчивости.

В эпоху агентов Trust распространяется на надежный контекст, в котором работают агенты. Надежный контекст означает, что агенты имеют доступ к управляемым проверенным данным с четкими границами удостоверения и полномочий, что позволяет системам искусственного интеллекта рассуждать и действовать от имени пользователей, поддерживая безопасность, проверяемость и соответствие. Создание надежного контекста является основой архитектуры Agentic Enterprise.

Этот компонент устанавливает базовый уровень безопасности платформы, от которого зависит каждое решение Salesforce. Компонент Agentic Trust опирается на этот базис для рассмотрения рисков, характерных только для автономных агентов, включая оперативную инъекцию, управление действиями и данные, доступные агентам во время рассуждений. Важно сначала создать базис, потом наслоить элементы управления, характерные для агентов, используя рекомендации Agentic Trust.

Этот компонент тесно связан с другими структурными проблемами.

• Надежность зависит от инфраструктуры, которая противостоит нападениям и восстанавливается после взлома.
• Оперативное совершенство требует безопасных ожидаемых продаж и возможностей реагирования на инциденты.
• Справедливость требует транспарентного, этического обращения с данными и алгоритмических решений.

В совокупности эти компоненты формируют единый подход, ориентированный на поиск решений, которому организации могут Trust со своими наиболее чувствительными операциями.

В модели общей ответственности Salesforce и архитекторы должны выполнять свои соответствующие обязанности по поддержанию Trust. Рассмотрим подробнее, что должна обеспечить каждая сторона.

Salesforce отвечает за безопасность платформы и ее глобальной инфраструктуры, включая:

• Контроль доступа к центру обработки и хранения данных, наблюдение и экологические гарантии
• В Hyperforce основной облачный поставщик (например, AWS, Azure или Google Cloud, в зависимости от экземпляра) занимается физической безопасностью центра обработки и хранения данных посредством делегированной ответственности. Документация инфраструктуры и подпроцессоров Salesforce определяет поставщика и подпроцессоры для каждой службы.

• Средства контроля безопасности сетевого уровня, включая защиту DDoS и обнаружение угроз
• Шифрование трафика в пути (TLS 1.2+) и в дежурном режиме (обычно AES-256)

• Реакция на уязвимости и развертывание исправления платформы посредством Salesforce (дополнительную информацию о рекомендациях по безопасности см. на сайте security.salesforce.com)
• Управление безопасностью операционной системы и инфраструктуры

• Сертификаты и проверки: Salesforce поддерживает SOC 1/2/3, ISO 27001/27017/27018, авторизацию FedRAMP (охватывает Government Cloud Plus и MuleSoft Government Cloud, а не коммерческую многопользовательскую платформу) и проверку PCI DSS уровня 1.
• Нормативная поддержка: Это относится к услугам, подпадающим под действие HIPAA, с программами соблюдения соглашений о деловом сотрудничестве (BAA) или GDPR.
• Дополнительную информацию можно получить на сайтах Trust.salesforce.com и complication.salesforce.com.

• Архитектура изоляции клиента: Общедоступное ядро, управляемое метаданными, разделяет данные и метаданные каждой организации по коду организации, поэтому одна организация не может получить доступ к записям другой организации, даже если они оба работают на общедоступной инфраструктуре. Ядро применяет разделение в каждом запросе, а не посредством конфигурации, которую нужно сохранить.
• Шифрование на уровне инфраструктуры в дежурной и резервной инфраструктуре: Базовые лицензии платформы включают классическое шифрование (AES-128 предоставляет только настраиваемые текстовые поля). Shield Platform Encryption требует отдельной лицензии (AES-256 позволяет принести собственный ключ и предоставляет стандартные и настраиваемые поля, файлы и вложения).

Эти элементы управления обеспечивают безопасность, надежность и соответствие платформы.

Вы ответственны за безопасность данных, конфигураций и операционных процессов.

• Удостоверение и федерация: Для единой регистрации (SSO) и многофакторной проверки подлинности (MFA) необходимо проверить подлинность пользователя.
• Ограничение доступа: Технически, диапазоны IP-адресов и часы входа ограничивают способ и время подключения удостоверений.
• Принцип наименьших привилегий (PoLP): Используйте PoLP для предоставления доступа только ролям, профилям и наборам полномочий, необходимым для выполнения отдельных должностных обязанностей.
• Управление жизненным циклом: Практика управления жизненным циклом пользователя и рекомендации по повторной сертификации доступа.

• Использование классификации данных, маскировки и безопасности объекта/поля/записи
• Применение полномочий CRUD и правил общего доступа
• Ответственность, тестирование и развертывание проверенной стратегии восстановления данных организации, гарантируя, что потеря данных или восстановление поврежденных данных не будут под вашим контролем.

• Используйте проверку подлинности API (например, OAuth 2.0 или JWT) и именованные регистрационные данные.
• Включите выделенных пользователей интеграции с наборами полномочий PoLP, чтобы доступ каждой интеграции был расширен и проверялся отдельно от пользователей-людей.
• Безопасные конечные точки и проверка внешней системы.

• Используйте мониторинг событий, контрольные журналы и интеграцию сведений о безопасности и управлении событиями (SIEM).
• Выполните процедуры реагирования на инциденты и проверки безопасности.

• Используйте безопасный настраиваемый код (например, Apex или Lightning) и проверку ввода.
• Запустите Apex в режиме пользователя, чтобы полномочия объекта, поля и общего доступа применялись в коде.
• Следуйте рекомендациям по предотвращению инъекций и безопасной разработке.

• Поддерживайте состояние соответствия решений.
• Следуйте политикам конфиденциальности/управления согласием и сохранности данных.

Некоторые обязанности требуют сотрудничества:

• Реакция на инцидент безопасности: Обе стороны участвуют в мероприятиях по обнаружению и реагированию.
• Управление уязвимостью: Salesforce исправляет платформу, архитекторы исправляют настраиваемый код.
• Отслеживание безопасности: Сочетайте сигналы безопасности платформы с анализом архитектора.
• Сертификация соответствия: Salesforce сертифицирует платформу (например, SOC, ISO и FedRAMP для Government Cloud); архитекторы ответственны за то, что на ней создано, — настраиваемые объекты, код, интеграции и конфигурация — в сертифицированной позиции, чтобы предоставить доказательства соответствия для аудита.
• Федерация удостоверений: Salesforce доверяет утверждениям, выдаваемым поставщиком удостоверений архитектора; архитекторы поддерживают безопасность поставщика и отношения Trust между поставщиком и Salesforce.
• Управление ключами: Используя шифрование «принеси собственный ключ», Salesforce управляет службой шифрования, пока архитекторы создают, ротируют и отменяют материал ключа, защищающий данные.

Каждый принцип проектирования, раздел темы и элемент контрольного списка в этом документе соответствует вашей ответственности как архитектора. Модель общей ответственности определяет параметры, которые должны быть разработаны и настроены для достижения Trust на Salesforce Platform.

Граница распространяется на нормативные обязательства. Salesforce поддерживает сертификаты и проверки платформы и защищает инфраструктуру от взлома. Архитекторы несут ответственность за обязательства, связанные с вашими данными и юрисдикцией (например: какие законы применяются, как классифицируются данные, какие правила хранения и согласия ими управляют, а также как вы обнаруживаете и сообщаете о взломе данных, находящихся под вашим контролем). По сравнению с регламентами по развертыванию архитекторы должны определить конкретные цифры, лежащие в основе этих обязательств (например, сроки хранения и сроки уведомлений), по сравнению с регламентом по развертыванию, поскольку они могут отличаться в зависимости от юрисдикции и меняться с течением времени.

Используйте эти принципы для руководства архитектурными решениями по безопасности на платформе.

• Примените нулевое доверие во всех слоях. Never assume Trust на основе расположения сети, знакомства пользователя или происхождения системы. Проверяйте каждый запрос доступа напрямую с помощью проверки подлинности, авторизации и шифрования на уровнях данных, приложения, интеграции и инфраструктуры. Архитектура с несколькими клиентами означает, что вы предоставляете общий доступ к инфраструктуре тысячам организаций, поэтому сеть, используемая вашим решением, не является периметром, который можно считать надежным. Проверяйте каждый запрос по его собственным достоинствам (идентичность, авторизация и контекст), а не доверяйте ему место происхождения.
• Предоставить наименьшие права по умолчанию. Предоставьте минимальный уровень доступа, необходимый каждому пользователю, интеграции и автоматическому процессу для достижения цели. Начните с самых строгих параметров (частные единые стандартные параметры (OWD) и минимальные полномочия) и намеренно расширяйте на основе документированных бизнес-требований. Используйте четырехуровневую модель доступа (организация → объект → поле → запись), чтобы каждый слой дополнительно ограничивал слои выше.
• Глубоко внедряйте защиту. Настройте несколько элементов управления безопасностью, чтобы сбой одного элемента управления не повредил всей системе. Объедините превентивные средства контроля (например, политики внедрения CRUD/FLS и безопасности транзакций, блокирующие операции), средства обнаружения (например, отслеживание событий) и адаптивные средства контроля (например, расширенная проверка подлинности и уведомления безопасности транзакций). Создайте каждый слой так, чтобы соседние слои могли не выполниться. Помните, что безопасность поля защищает данные, даже если правила общего доступа слишком разрешительны.
• Интегрируйте безопасность по проекту. Интегрируйте моделирование угроз, требования безопасности и проверку управления на каждом этапе архитектуры от исходной концепции до текущей эволюции. Выполните моделирование угроз подделки, фальсификации, отказа в предоставлении информации, отказа в обслуживании и повышения привилегий (STRIDE) перед началом сборки. Безопасность формирует выбор технологии и дизайнерские решения.
• Внедрение безопасности в автоматизацию. Встройте элементы управления безопасностью в автоматические ожидаемые продажи, шаблоны конфигурации и стандартные параметры платформы. Анализатор кода Salesforce в CI/CD обнаруживает уязвимости перед развертыванием. Configuration-as-code применяет базовые уровни безопасности. Встроенная безопасность обеспечивает согласованность и позволяет масштабировать безопасность с учетом сложности решения.
• Создание для конфиденциальности. Внедрите принципы конфиденциальности с начального этапа архитектуры. Создание для минимизации данных (только сбор необходимых данных), ограничения цели (ограничение доступа по функции задания), управления согласием (применение детального, целевого согласия) и прав субъекта данных (включение доступа, исправления, удаления и переносимости бизнес-процессов для выполнения в пределах регламентных временных шкал).
• Создание для отслеживания. Прежде чем полагаться на обнаружение аномалий, сделайте каждое последующее действие доступным и воссоздаваемым постфактум. Убедитесь, что изменения данных, полномочий и конфигурации хранятся в контрольных журналах, журнале полей и журналах событий, и сохраните эти записи в устойчивом к взлому хранилище. Отслеживание является предварительным условием обнаружения, криминалистики и подотчетности. Помните: вы не можете исследовать то, что никогда не было записано.
• Предназначение для реагирования на инцидент. Создайте для обнаружения посредством отслеживания событий и для вмешательства в реальном времени посредством политик безопасности транзакций. Включите быстрый ответ посредством задокументированных процедур и границ изоляции. Поддержка восстановления посредством резервных возможностей и сохранности судебной экспертизы. Протестируйте ответы посредством настольных упражнений и симуляции нарушения.

Архитекторы отвечают за безопасность решений на платформе, предоставляемой Salesforce.

Загруженность, взаимодействующая с Salesforce, все чаще выходит за пределы базовой платформы - службы интеграции, настраиваемые приложения и клиенты без заголовка часто вызывают Salesforce API, часто от имени пользователя. Чтобы ускорить эту схему, Salesforce открывает возможности платформы в виде API, инструментов и команд (например, Salesforce Headless 360). Независимо от того, кто управляет этими приложениями, архитектор несет ответственность за границу Trust, где они встречаются с Salesforce, чтобы определить, как они проходят проверку подлинности, какие удостоверения и полномочия носят с собой, какие секреты хранятся и какие данные пересекают границу.

Принципы ниже применяются к любой контейнеризированной платформе интеграции (например, MuleSoft CloudHub).

Когда внешний клиент авторизуется от имени указанного пользователя, модель безопасности платформы Salesforce применяется автоматически — полномочия объекта, безопасность поля и правила общего доступа применяются так же, как и в обозревателе. Проверка подлинности каждого пользователя охватывает каждый вызов полномочий этого лица и сохраняет контрольный журнал, то есть отзыв маркера пользователя немедленно лишает клиента возможности действовать от его имени. Предпочтение отдается общедоступной организации обслуживания при выполнении работы для определенного пользователя.

Оформите границу оборонительно, поскольку клиент, владеющий маркерами для многих пользователей, концентрирует Trust и становится ценным прокси для злоумышленника: один украденный маркер OAuth может доходить до данных каждого пользователя, обслуживаемого клиентом. Это не гипотетически. Инцидент с дрейфом Salesloft 2025 года привел к краже злоумышленниками маркеров OAuth и их использованию для доступа к данным Salesforce в сотнях организаций.

• Пропагандируйте удостоверение пользователя, не объединяйте его. Используйте проверку подлинности каждого пользователя или обмен маркерами OAuth 2.0 для переноса удостоверения пользователя посредством сервисных скачков (см. «Agentic Identity и Authentication»), чтобы компрометация ограничивалась контекстом одного пользователя, а не всеми.
• Считайте регистрационные данные клиента OAuth и маркеры обновления основной целью. Храните их в хранилище управляемых секретов, часто меняйте их и сохраняйте дизайн для немедленного отзыва. Отслеживайте использование API на наличие аномалий, которые сигнализируют прокси-взломщику.
• Уменьшить область с двух сторон. Ограничьте области OAuth приложения внешнего клиента (ECA) и полномочия Salesforce пользователя интеграции до минимума, требуемого функцией, чтобы скомпрометированный клиент не мог свести к несвязанным данным.
• Управление границей посредством приложений внешних клиентов. ECA определяют, как внешнее приложение проверяет подлинность, какие потоки разрешены и какие области применяются — разработайте новые интеграции против них (см. Архитектура проверки подлинности).

Проявите осторожность, когда клиент выполняется в качестве пользователя-агента или пользователя интеграции: Эти удостоверения могут работать в повышенном контексте — часто против внешних систем, которые не учитывают элементы управления доступом Salesforce — поэтому использование вышеописанной дисциплины полномочий и мониторинга — это то, что удерживает эту власть в пределах.

Когда интеграции выполняются на контейнерной платформе, изоляция уровня контейнера сама по себе считается элементом управления безопасностью: каждое приложение выполняется в специальном контейнере без общего времени выполнения или памяти между приложениями.

Эта изоляция предоставляет:

• Применение границ клиента: Компрометированные приложения не имеют доступа к данным или ресурсам из соседних приложений, использующих одну среду. Каждый контейнер содержит изолированную файловую систему и пространство процесса. Примените изоляцию сети посредством брандмауэра и конфигурации TLS и четко ограничьте исходящий трафик, а не полагайтесь на разрешительные стандартные параметры.
• Углубленная защита: Изоляция контейнера добавляет уровень безопасности за пределы контроля на уровне приложения. Даже если код приложения содержит уязвимости, границы контейнера ограничивают радиус взрыва.
• Сегментация соответствия: Регламентированные рабочие нагрузки (например, PCI и HIPAA) могут быть изолированы в специальных контейнерах, что предотвращает их смешивание с несоответствующими рабочими нагрузками.

Архитекторы, создающие многоприкладные среды, должны полагаться на изоляцию контейнеров для внедрения разделения обязанностей и доменов безопасности. Интеграции финансовых услуг, обрабатывающие данные держателя карты, должны выполняться в отдельных контейнерах от маркетинговых интеграций, даже в одной среде.

Межконтейнерные перевозки должны быть зашифрованы, и взаимные TLS (mTLS) должны применяться в тех случаях, когда нормативная база требует проверки подлинности с обеих сторон:

Как это работает:

• Настройте контексты TLS для включения дополнительного взаимного TLS (mTLS) для входящих подключений при необходимости.
• Используйте SSL уровня платформы с проверкой подлинности клиентского сертификата для обеспечения безопасности связи между службами платформы и репликами.
• Настройте контексты TLS для включения mTLS, если это требуется нормативными базами.
• Управляйте сертификатами в хранилище сертификатов платформы, чтобы жизненный цикл и отзыв оставались централизованными.
• Внедрите границы изоляции сети, предотвращающие несанкционированный трафик между контейнерами.

Шифрование трафика на уровне платформы обеспечивает глубокую защиту для транзитных данных. Даже если HTTPS уровня приложения настроен неправильно, контейнерный трафик остается зашифрованным.

Контейнеры, подключаемые к локальным системам посредством VPN, должны быть созданы для защиты данных в пути:

• Шифрование в туннеле: Перенаправляйте весь трафик между контейнерами и локальными системами посредством зашифрованных туннелей VPN. Это применяется независимо от TLS уровня приложения. Углубленная защита обеспечивает двойное шифрование конфиденциальных данных.
• Применение сегментации сети: Политики туннелей VPN ограничивают доступ контейнеров к локальным сетям. Компрометированные контейнеры не могут сводиться к несанкционированным внутренним системам за пределами сетей, разрешенных VPN.
• Доказательства соответствия: Шифрование VPN является одним из общепринятых механизмов защиты данных в облачных средах и из них. Аудиторы, проверяющие элементы управления HIPAA, PCI-DSS или SOX, ожидают документированного шифрования в пути для гибридных интеграций.

Архитекторы должны разработать политики VPN, внедряющие доступ к сети с наименьшими правами. Контейнеры интеграции маркетинга не должны перенаправляться во внутренние финансовые системы, даже если они доступны посредством VPN.

Домены Vanity (например, настраиваемые URL-адреса для API интеграции) требуют, чтобы архитекторы управляли сертификатами TLS в качестве Trust anchors:

Домены Vanity (например, настраиваемые URL-адреса для API интеграции) требуют, чтобы архитекторы управляли сертификатами TLS в качестве Trust anchors.

• Автоматизация жизненного цикла сертификата: Внедрите автоматическое продление и развертывание сертификатов. Просроченные сертификаты нарушают Integration Trust; клиенты отклоняют подключения с ошибками проверки сертификатов.
• Планирование отзыва сертификатов: Разработайте процедуры ротации сертификатов для инцидентов безопасности. Компрометированные секретные ключи требуют быстрой перевыпуски сертификата и развертывания во всех регионах.
• Конфигурация пакета шифров: Старые конфигурации TLS (TLS 1.0/1.1 и слабые шифры) не проходят проверки соответствия. Внедрите TLS 1.2+ (минимальное требование) и соотнесите конфигурации сертификатов и клиентов с политиками безопасности организации.
• Запись прозрачности сертификата: Современные сертификаты TLS отправляются в общедоступные журналы прозрачности сертификатов (CT) центрами сертификации (CA). Каждый журнал КТ возвращает отметку времени подписанного сертификата (SCT), криптографическое доказательство регистрации, которое центр сертификации встраивает в сертификат посредством расширения X.509v3. Архитекторы должны отслеживать журналы КТ на наличие несанкционированной выдачи сертификатов по их доменам, используя такие службы, как crt.sh или автоматическое оповещение.

Неправильное управление сертификатами напрямую влияет на состояние Trust:

• Просроченные сертификаты: Приведите к сбоям проверки подлинности, которые отображаются как сбои. Мониторинг должен включать отправку предупреждений в течение 30+ дней до истечения срока действия, чтобы разрешить запуск бизнес-правил продления.
• Сертификаты, подписываемые самостоятельно: Разрыв цепочек Trust для внешних клиентов. Производственные интеграции требуют сертификатов, подписываемых надежными центрами сертификации (CA).
• Развертывание сертификатов специальных символов: Обозначает слишком широкие специальные сертификаты (например, *.company.com), которые создают большой радиус взрыва, если они повреждены. Сертификаты узкого диапазона предпочтительны для каждого домена интеграции.

Регионы развертывания контейнеров должны соответствовать требованиям к резидентству данных и соответствию.

• Резиденция данных GDPR: GDPR требует надлежащей защиты персональных данных, покидающих Европейский союз (ЕС), но не развертывания ЕС как такового. Развертывание интеграций в регионе ЕС позволяет вычислять контейнеры и обрабатывать данные в рамках нормативных границ, что является самым прямым способом удовлетворения этого требования. Перемещение, осуществляемое за пределами ЕС, остается допустимым в соответствии с решением об адекватности, стандартными договорными оговорками (СТК) или обязательными корпоративными правилами (ОКП).
• Законы локализации данных: К числу стран с требованиями к локализации данных относятся: Россия (Федеральный закон 152-ФЗ и обязательное хранение) и Китай (PIPL/CSL для CIIO), что может потребовать развертывания контейнеров внутри страны. В Законе 2023 года о НВУ Индии используется метод «черных списков», не предусматривающий общего мандата на хранение в стране. Передача данных разрешена в любую страну, если только она не ограничена правительственным уведомлением. Архитекторы должны понимать правила юрисдикции.
• Механизмы трансграничной передачи данных: Если требуется развертывание на нескольких регионах, но данные должны пересекать границы, архитекторы должны внедрить SCC, BCR или другие юридические механизмы передачи.
• Выравнивание сертификации соответствия: Регионы развертывания контейнеров должны соответствовать сертификатам соответствия Salesforce. Загруженность, разрешенная FedRAMP, требует регионального развертывания США. Для интеграций, сертифицированных HITRUST, необходимо проверить, входит ли регион развертывания в активную область сертификации HITRUST.

Решения о региональном развертывании являются обязанностями архитектора, которые напрямую влияют на соответствие нормативным требованиям. Финансовые группы могут санкционировать развертывание только в США для интеграций, контролируемых SOX. Группы медицинского обслуживания могут требовать сертифицированные HITRUST регионы для обработки личных сведений о здоровье (PHI).

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

• Нет жестко запрограммированных секретов: Никогда не встраивайте регистрационные данные в код приложения или файлы конфигурации, развернутые в контейнерах. Используйте хранилища секретов под управлением платформы.
• Управляемый платформой секретный ввод: Разрешите секреты во время выполнения из управляемого магазина платформы (вместо их сохранения в файловой системе) и пометьте значения конфигурации, содержащие регистрационные данные, защищенными, чтобы они не открывались в журналах или на консоли.
• Ротация секретов: Разработайте интеграции для изящной обработки сменяемых секретов. Схемы обновления маркера OAuth, бизнес-правила ротации ключей API и изменения пароля базы данных не должны требовать развертывания контейнера.
• Доступ к секретам с наименьшими правами: Предоставьте контейнерам доступ только к секретам, необходимым для их функции. Маркетинговые интеграции не должны иметь доступа к регистрационным данным финансовой системы, даже если у них одна среда.

Открытые секреты - это распространенные инциденты безопасности интеграции. Архитекторы должны создать секреты, обрабатывающие процессы, которые могут пережить проверки кода, журналы, сообщения об ошибках и мониторинг панелей мониторинга без утечки регистрационных данных.

Приложения на границе Salesforce создают события аудита, соответствующие требованиям к регистрации соответствия:

• Запись запроса/ответа: Регистрация запросов API, ответов и решений маршрутизации. Группы по соблюдению используют эти журналы для проверки доступа, чтобы определить, кто и в какое время имел доступ к данным.
• Запись ошибок и исключений: Собирает события безопасности (например, ошибки проверки подлинности, отказы в авторизации и недействительные сертификаты) в журналах контейнера. Интеграция SIEM включает мониторинг безопасности в реальном времени.
• Политики сохранности журнала: Архитекторы должны настроить сроки хранения, соответствующие нормативным требованиям. Эти минимальные значения устанавливаются нормативными актами, отличаются по структуре и меняются с течением времени, поэтому они должны извлекаться из хорошо поддерживаемого источника соответствия, который проверяет каждую цифру по управляющему регламенту, а не по значениям жесткого кодирования.
• Шифрование журнала и управление доступом: Журналы аудита могут содержать конфиденциальные метаданные. Журналы должны быть зашифрованы в дежурном режиме и контролироваться только авторизованным персоналом безопасности/соответствия. Недостаточное количество журналов предотвращает расследование инцидентов и не выполняет проверки соответствия. Архитекторы должны соотносить многословность регистрации (например, влияние на производительность и затраты на хранение) с потребностями в соответствии и безопасности исследования.

Моделирование угроз должно быть частью разработки решений, а не отдельным этапом, выполняемым до или после него. Как только у вас есть потенциальный дизайн для размышлений, вам нужно смоделировать его потенциальные угрозы - и вернуться к модели по мере развития дизайна, чтобы безопасность формировала архитектуру, а не была переоборудована под нее. Salesforce управляет безопасностью инфраструктуры (например, защита сети, закаливание ОС и управление уязвимостями), но при этом необходимо определить риски на уровне приложения в конфигурации, интеграциях и настраиваемом коде. Примените инфраструктуру STRIDE (подделка, фальсификация, отказ в обслуживании, повышение привилегий) к векторам угроз Salesforce, указанным ниже. Определите границы Trust, где данные пересекают системы, сети или уровни привилегий.

Примените инфраструктуру STRIDE к следующим рекомендациям по моделированию угроз Salesforce:

• Потоки данных нескольких организаций создают дополнительные границы Trust, требующие четкой проверки подлинности и авторизации при каждом пересечении.
• Внешние интеграции используют API и промежуточное программное обеспечение, потенциально внедряя векторы атак, которые пропускают средства управления безопасностью платформы.
• Настраиваемые компоненты Apex и Lightning требуют безопасного анализа кодирования для внедрения, XSS и контроля доступа.
• Сайты Experience Cloud расширяют область атаки для непроверенных или слабопроверенных пользователей.
• Сторонний и ISV-код (например, управляемые пакеты, списки AgentExchange, связанные приложения, сторонние коннекторы, клиентские библиотеки JavaScript и внешние службы искусственного интеллекта, вызываемые агентами) — это вектор цепочки поставок, пересекающий границу Trust при установке или выполнении.

Сторонний и ISV- код является частью Your Trust Boundary.

Управляемые пакеты или списки AgentExchange выполняются в вашей организации с предоставленными полномочиями, поэтому их состояние безопасности становится состоянием безопасности в момент установки. Проверка безопасности Salesforce проверяет каждый пакет, прежде чем он достигнет AppExchange или AgentExchange. После этого входа у вас есть все:

• Оценка пакета относительно собственной классификации данных и состояния риска
• Предоставление ему наименьшего количества привилегий, необходимых для его документированных функций
• Поддержание актуальности с выпусками издателя
• И отслеживание его действий посредством тех же элементов управления мониторингом событий и аудитом, которые вы применяете к собственному коду.

Примените средства управления безопасностью на каждом уровне стека решений. Помните, что компромисс одного слоя не должен открывать всю систему.

Создайте каждый слой так, чтобы слои выше и ниже могли не выполниться. Помните, что несколько независимых элементов управления создают устойчивость.

Zero Trust устраняет implicit Trust на основе положения в сети или предыдущего состояния проверки подлинности. Каждый запрос должен быть проверен и авторизован независимо.

Применить нулевое Trust к:

• Доступ пользователей посредством постоянной проверки посредством MFA, политик сеансов и условного доступа на основе контекста (например, IP-адрес, устройство, время и поведение)
• Подключения интеграции посредством проверки маркера OAuth при каждом вызове, взаимного TLS на основе сертификата и добавления в список разрешенных IP-адресов
• Межсистемная связь посредством четкой проверки подлинности, которая также применяется к надежным внутренним системам
• Доступ к данным посредством CRUD и внедрения FLS для каждого запроса и операции, независимо от контекста вызова

Инвентарь активов безопасности - это вводные данные о дизайне безопасности: вы можете только моделировать угрозы, применять наименьшие привилегии и отслеживать первую перечисленную поверхность атаки, поэтому отслеживание активов, связанных с безопасностью, относится к решениям о создании, которые зависят от нее. Это отличается от управления операционной конфигурацией, охватываемого функцией «Operational Excellence» (например, версия параметров организации и определение отклонения конфигурации для обеспечения стабильности работы). Другими словами, проблема здесь более узкая: какие активы несут риски безопасности и почему?

Поддерживайте текущий запас всех активов, связанных с безопасностью, включая настраиваемые объекты, хранящие конфиденциальные данные, интеграции внешних систем, общедоступные API, привилегированные организации, гранты на производственный доступ и установленные пакеты с повышенными полномочиями.

Инвентарь активов безопасности должен содержать:

• Настраиваемые объекты и поля, содержащие конфиденциальные или ограниченные данные
• Конечные точки интеграции и механизмы проверки подлинности
• Пользователи с повышенными полномочиями (например, «Изменение всех данных», «Просмотр всех данных» и «Управление пользователями»)
• Пользователи интеграции только API и их области полномочий
• Приложения внешних клиентов (ECA) и их области OAuth, а также любые устаревшие связанные приложения, которые все еще присутствуют в организации
• Установленные пакеты AgentExchange и их полномочия
• Сайты Experience Cloud и их модели проверки подлинности и внешнего общего доступа
• Настраиваемые классы Apex с повышенными режимами общего доступа
• Обратите особое внимание на устаревшие классы: код, скомпилированный в версии API 66.0 или более ранней, пропускающий описание общего доступа по умолчанию на «без общего доступа» (например, системный режим, пропускающий доступ текущего пользователя к записи). Помните, что в версии API 67.0 (Summer '26) пропущенное описание по умолчанию содержит значение «с общим доступом», а операции базы данных выполняются в режиме пользователя. Однако, существующие классы сохраняют старый алгоритм до повторной компиляции в версии v67.0 (или более поздней), поэтому незаявленные классы, перенесенные из более ранних версий, остаются незаявленными.

Вы обязаны создать и настроить средства управления удостоверениями, которые обеспечивают наименьшие привилегии.

Рассмотрим более подробно, как правильно проектировать и настраивать элементы управления посредством PoLP.

Salesforce внедряет контроль доступа посредством четырех разных уровней: организация, объект, поле и запись. Решения, использующие все четыре уровня, должны быть разработаны намеренно. Базовый контроль доступа основан на грантах, то есть доступ является аддитивным, и пользователям нужно предоставить его на каждом уровне, чтобы получить запись. В базовой платформе нет общего правила «запрещать переопределения разрешают», поэтому вы не можете привязать целевой отказ к отмене доступа к широкому гранту, который уже предоставлен.

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

Правила ограничения и полномочия игнорирования — это два встроенных исключения, которые вычитают доступ, но каждое из них имеет узкую область действия (правила ограничения фильтрации на уровне записи и игнорирования полномочий, предоставленных в группе наборов полномочий), а не обобщенный слой отказа.

Задайте OWD значение «Личный» для объектов, содержащих конфиденциальные данные. Открытие OWD для общего доступа только для чтения, не говоря уже об общедоступном доступе для чтения и записи, открывает записи в широком смысле и уменьшает возможность ограничения доступа позже без потенциально значительной переархитектуры. Наиболее распространенный долг Trust в зрелых организациях вытекает из разрешительных OWD, установленных во время первичного внедрения.

Слой записи следует модели ограничения предоставления, часто представляемой в виде пирамиды общего доступа: Ограничительный базис устанавливается OWD, а иерархия ролей, правила общего доступа и ручной общий доступ открываются вверх оттуда. Два элемента управления преобразуют этот поток, чтобы забрать доступ, а не предоставить его, и оба стоит создать намеренно.

• Правила ограничения фильтруют то, что отображается пользователям в записях, к которым у них уже есть доступ, поэтому пользователи с широким доступом к объектам видят только поднабор, разрешенный правилом.
• Полномочия игнорирования вычитают определенные полномочия в группе наборов полномочий, чтобы собрать доступ из многоразовых групп, а потом удалить то, чего не должно быть у данной группы.
• Используйте эти правила, если только слои на основе грантов заставят вас переоценить или раздробить доступ на множество узких наборов полномочий.

Внедрите MFA (многофакторную проверку подлинности) для всех пользователей, входящих в производственную среду посредством пользовательского интерфейса, который Salesforce требует наличия платформы. Это требование не распространяется на доступ только к API: интеграции, использующие потоки JWT-носителя или регистрационных данных клиента, исключены, поэтому нужно защитить эти интеграции посредством управления сертификатами и ограничений IP-адресов. Распространите требования MFA на привилегированные операции.

Для SSO (единой регистрации) предпочтительны протоколы SAML 2.0 или OpenID Connect. Настройте политики сеансов для баланса безопасности и удобства использования:

• Время ожидания сеанса: Настройте время ожидания сеанса, соответствующее уровням полномочий пользователя (сокращение времени ожидания для организаций с высоким уровнем полномочий уменьшает риски от непросмотренных сеансов).
• Ограничения IP-адресов: Внедрите ограничения для административных профилей и пользователей интеграции.
• Часы входа: Ограничьте организации обслуживания ожидаемыми операционными окнами.
• Активация устройства: Используйте нативную активацию устройства Salesforce (проверку подлинности для входов с нераспознанных устройств) и добавьте ограничения MFA и IP-адресов для организаций с высоким уровнем привилегий. Поза Native device Trust внедряется посредством внешнего поставщика удостоверений.
• Блокировка IP-адреса сеанса: Заблокируйте сеансы на IP-адресе, с которого они были отправлены, чтобы украденный код сеанса нельзя было воспроизвести из другого расположения сети. Это ужесточает безопасность, но добавляет трения для мобильных пользователей и может нарушить автоматические интеграции - если блокировка нежизнеспособна, примените диапазоны строгих IP-адресов входа на уровне профиля с «Применение диапазонов IP-адресов входа по каждому запросу» в качестве компенсирующего элемента управления.
• Высоконадежные сеансы: Требовать высоконадежный уровень безопасности сеанса посредством политик уровня безопасности сеанса и политик доступа для конфиденциальных операций (например, доступ к отчетам или управление диапазонами IP-адресов), чтобы обычный вход не достигал высокоэффективных действий сам по себе. Lightning Experience не поддерживает стандартный сеанс с повторным напоминанием о MFA, поэтому рекомендуем использовать данную политику, зная, что пользователи стандартного сеанса блокируются в закрытой операции, а не получают запрос на повышение.
• Защита cookie-файлов сеанса: Требовать атрибут HttpOnly, чтобы сценарии не могли прочитать cookie-файл кода сеанса и заблокировать сеансы в домене, в котором они впервые использовались, чтобы притупить перехват сеанса.
• Доступ только к API для пользователей интеграции: Ограничьте учетные записи интеграции и обслуживания проверкой подлинности только API с полномочием «Пользователь только API», чтобы они не могли войти через пользовательский интерфейс. Для новых сборок назначьте профиль «Минимальный доступ - интеграции только API» с лицензией пользователя интеграции Salesforce; старый профиль интеграции систем только Salesforce API недоступен в организациях, инициализированных начиная с выпуска Spring '24, поэтому создайте новые интеграции с учетом текущего профиля, а не устаревшего.

Для проверки подлинности API выберите потоки OAuth 2.0, соответствующие схеме интеграции:

• Поток носителя JWT: Используйте это для интеграций между серверами, выполняемых от имени пользователя интеграции (на основе сертификата, предпочтительно для надежных сред).
• Поток веб-сервера (код авторизации с PKCE): Используйте это для веб-приложений, требующих авторизации пользователя, а также для интеграций между серверами, которые должны поддерживать определенный пользовательский контекст (хранение маркеров обновления на сервере во избежание повторных напоминаний обозревателя).
• Сделать поток кода авторизации безопасным для повтора: Внедрите PKCE, чтобы перехваченный код авторизации не был выкуплен кем-либо, кроме клиента, запросившего его, и измените маркеры обновления, создавая новый для каждого использования и аннулируя предыдущий, чтобы украденный маркер обновления имел узкое окно действия. Повторное использование изъятого из эксплуатации маркера указывает на компромисс.
• Код авторизации без заголовка и поток регистрационных данных (с PKCE): Используйте это для клиентов без заголовка и обозревателя, которые должны выполняться в контексте определенного пользователя - процесс веб-сервера на основе переадресации предполагает обозреватель, которого у этих клиентов нет.
• Поток устройства (для устройств без заголовка): Отметим, что с 28 августа 2025 года Salesforce навсегда заблокировала поток устройств OAuth 2.0 для связанного приложения Salesforce CLI по умолчанию. Используйте поток веб-сервера (веб-сайт входа организации) или поток носителя JWT (вход организации jwt) вместо этого для инструментов CLI и CI/CD.

Не используйте поток имени пользователя и пароля. Salesforce заблокировал его по умолчанию для организаций, созданных в выпуске Summer '23 или более поздних, и опубликовал планы вывода из эксплуатации для этого потока. Существующие интеграции, которые все еще зависят от потока имени пользователя и пароля, должны мигрировать в поток носителя JWT или поток регистрационных данных клиента сейчас, а не рассматривать миграцию как отложенную техническую задолженность.

Эти потоки настроены на регистрацию приложения, представляющую интеграцию. Начиная с выпуска Spring '26 Salesforce переносит регистрацию из связанных приложений во внешние клиентские приложения (ECA): создание новых связанных приложений отключено по умолчанию, и ECA - это конструкция для создания новых интеграций. Существующие связанные приложения остаются установленными, но после миграции организации они больше не обрабатывают проверку подлинности, поэтому учитывайте миграцию при проверке подлинности интеграций, а не рассматривайте связанные приложения как постоянную модель.

В дополнение к выбору потока проверки подлинности создайте отдельное управление, к которому приложения могут подключиться:

• Одна регистрация на интеграцию: Зарегистрируйте специальное приложение внешнего клиента для каждой новой интеграции и отдельное связанное приложение для каждой существующей. Ограниченная только областями OAuth, которые требуются каждой интеграции, вместо предоставления общего доступа к одной широкой регистрации многим, специальная регистрация поддерживает независимый контроль и отзыв доступа каждой интеграции.
• Предварительная авторизация доступа (рекомендуется): Установите политику «Разрешенные пользователи приложения внешнего клиента» на «Пользователи, допущенные администратором, предварительно авторизованы», чтобы администратор предоставлял доступ посредством профилей и наборов полномочий вместо предоставления пользователям возможности самостоятельной авторизации. Администраторы настраивают это напрямую в настройках, и это рекомендуемый элемент управления Salesforce для определения того, кто может подключиться.
• Контроль доступа к API (более строгий, на основе списка разрешенных): Для более жесткого контроля, API Access Control ограничивает пользователей, допущенных администратором, только разрешенными связанными приложениями. Включение требует обращения в службу поддержки Salesforce, поэтому спланируйте этот этап при создании в соответствии с ним, а не обрабатывайте его как параметр самообслуживания.

Никогда не встраивайте регистрационные данные в код, файлы конфигурации или управление версиями. Используйте именованные регистрационные данные и внешние регистрационные данные для централизованного управления проверкой подлинности посредством возможностей ротации.

В отличие от традиционной проверки подлинности пользователя, агентам требуются разные модели удостоверения, и правильная модель зависит от того, обслуживает ли агент сотрудников или внешних пользователей. Правильный дизайн удостоверения является основой безопасности агента: определяет данные, доступные агенту, и действия, доступные агенту.

Рассмотрим внутренних и внешних агентов. nts.

• Агенты сотрудников (внутренние): Выполняйте задачи в контексте входа пользователя. Они наследуют лицензии этого пользователя, наборы полномочий, безопасность поля и правила общего доступа, поэтому не предоставляется отдельное удостоверение агента, а существующая инфраструктура безопасности определяет действия агента.
• Агенты клиента (внешние): Взаимодействуйте через общедоступные каналы и выполняйте от имени специальных пользователей-агентов, специализированных пользователей интеграции, а не общедоступных пользователей-гостей. Выполнение в качестве выделенных пользователей интеграции позволяет агенту выполнять фоновые действия и получать данные (что недоступно непроверенным профилям гостей), но при этом быть связанным четкими полномочиями с наименьшими полномочиями. При создании агента-клиента предоставьте новому пользователю-агенту минимальный доступ и предоставьте только определенные полномочия, необходимые для его действий.

Если работа агента охватывает несколько служб, распространяйте удостоверение пользователя в каждом сервисном скачке, а не возвращайтесь к общедоступной или гостевой идентификации. Процесс обмена маркерами Salesforce OAuth 2.0 поддерживает следующее:

Клиент представляет существующий маркер поставщика удостоверений пользователя, а средство обмена маркерами Apex соотносит его с пользователем Salesforce и выпускает маркер доступа Salesforce, поэтому исходный контекст пользователя следует запросу, а не сворачивается в учетную запись службы. Отслеживайте действия агента посредством отслеживания событий, используя удостоверение пользователя агента для обнаружения аномалии поведения.

Выбор правильной модели зависит от того, кто инициирует подключение и в чьем контексте должна выполняться работа.

Распространенные сценарии подключения соотносятся с рекомендованными подходами следующим образом:

Создавайте иерархии ролей в соответствии с потребностями доступа к данным (которые требуются пользователям для доступа к записям, принадлежащим другим пользователям), а не в соответствии с диаграммой управленческой отчетности. Пусть глубина иерархии ролей соответствует подлинным взаимосвязям доступа к данным, а не добавляет уровни, которые не предоставляют дополнительного доступа, поскольку каждый уровень добавляет общий доступ к вычислению над головой - рекомендация, которая имеет больший вес в организациях с параметрами Private OWD и большими объемами данных.

Наборы полномочий и группы наборов полномочий уменьшают необходимость распространения профиля, предоставляя гибкий дополнительный доступ. Предоставьте функциональный доступ посредством наборов полномочий и групп наборов полномочий, а не профилей, которые поддерживают дополнительный доступ и возможность проверки. Профили остаются необходимыми: наряду с часами входа и ограничениями IP-адресов, они управляют назначением макета страницы, стандартными параметрами типа записи и доступностью приложения. Рассматривайте профили как прочную часть модели доступа, а не как конструкцию для устранения.

Политики безопасности транзакций не являются частью базиса, они являются дополнительной возможностью, дополняющей базовую модель авторизации: элементы управления удостоверением, ролью, профилем, набором полномочий и общим доступом выше уже самостоятельно устанавливают безопасное состояние авторизации, а безопасность транзакций добавляет контекстную оценку в реальном времени сверху. Настройте политики для обнаружения и блокировки аномального поведения, включая пакетную загрузку данных, превышающую обычные схемы, входы из непредвиденных географических районов и изменения полномочий вне окон изменений.

Средства управления безопасностью поддерживают компромиссы доступности, являющиеся архитектурной ответственностью. Слишком широкое ограничение IP-адресов может блокировать законных пользователей во время изменения сети, а политика безопасности транзакций, настроенная слишком агрессивно, может блокировать действительные бизнес-действия, поэтому ограничьте эти элементы управления реальным риском, разместите их только в режиме мониторинга, прежде чем внедрять их, и создайте бризантный путь для случаев, когда элемент управления пропускает управление.

Ваша ответственность: Создайте иерархию ролей, создайте наборы полномочий, настройте политики безопасности транзакций.

Традиционный контроль доступа на основе роли) предоставляет полномочия на основе роли пользователя. ABAC (контроль доступа на основе атрибутов) принимает решения авторизации на основе атрибутов данных, пользователя и контекста.

Для большинства требований базовая модель общего доступа полностью выражает доступ. Обратитесь к выделенной АБАК, если доступ должен соответствовать классификации данных, которую не может выразить общий доступ к записи: Data 360 ABAC предоставляет это посредством тегов и примечаний.

Data 360 ABAC работает посредством:

• Политики на основе тегов, определяющие правила доступа на основе тегов, применяемых к объектам данных (например, персональные данные (PII), финансовые, медицинские и конфиденциальные теги).
• Примечания применяются к объектам данных для поддержки решений авторизации на основе политики.
• Стандартная политика «Разрешить все» для новых и существующих организаций, которая должна быть явно удалена для включения политик детального управления.

Его основным архитектурным использованием является внедрение классификации данных - см. Классификация данных в разделе «Защита и конфиденциальность данных», чтобы узнать, как уровни классификации влияют на внедрение ABAC.

Этот уровень детализации сопряжен с операционными расходами. Базовый общий доступ отвечает на вопрос: «Кто может видеть эту запись и почему?» из небольшого инспектируемого набора правил (OWD, иерархия ролей и правила общего доступа), в то время как ABAC извлекает ответы во время оценки из сочетания тегов данных, атрибутов пользователей и контекста, поэтому эффективный доступ становится труднее рассуждать и проверять по мере накопления политик и тегов.

Внедрение аудита в качестве требования к конструкции: последовательно применять теги, сохранять набор политик маленьким и названным для применяемой классификации и сохранять возможность восстановления причины достижения пользователем данной записи. Зарезервируйте ABAC для обращений, управляемых классификацией, которые действительно не могут быть выражены в каждом общем доступе к записи, вместо того, чтобы рассматривать его как общую замену модели на основе ответственности.

Определите и защитите организации с повышенными привилегиями, включая системных администраторов, пользователей интеграции и автоматические организации процессов. Эти организации являются ценными целями для злоумышленников.

Применение расширенных элементов управления к организациям с критическим влиянием.

• Требовать фишингоустойчивые MFA
• Ограничение диапазонов IP-адресов входа известными административными расположениями
• Включение предупреждений о входе и уведомлений об изменении полномочий
• Проведение периодических проверок доступа с документированным подтверждением для организаций с высоким уровнем прав собственности, где частота определяется допустимыми организационными рисками и требованиями к соблюдению
• Поддержка процедур бризантного стекла для аварийного доступа и проверки после использования

Для организаций интеграции и обслуживания:

• Применение потоков OAuth; никогда не потоки имени пользователя и пароля
• Применение ограничений IP-адресов
• Внедрение расписаний ротации регистрационных данных
• Мониторинг аномальных схем использования API посредством мониторинга событий

Ваша ответственность: Определяйте критические организации, применяйте расширенный контроль, выполняйте ежеквартальные проверки.

Разработайте автоматические процессы для предоставления пользователям соответствующего первичного доступа, настройки полномочий по мере изменения ролей и оперативной отмены, если доступ больше не требуется.

Внедрите систему для междоменного управления удостоверениями (SCIM) для автоматической инициализации от поставщиков удостоверений. Своевременная инициализация SAML или OpenID Connect - это альтернатива, которая создает пользователя при первом входе, но не отменяет работу пользователей. Другими словами, SCIM является основой жизненного цикла, а не выбором против него.

Жизненный цикл удостоверения содержит:

• Инициализация: Создайте организации с базовым доступом, соответствующим функции задания, которая запускается событиями системы кадров.
• Поправки доступа: Предоставьте дополнительные полномочия по мере расширения ролей и отмените полномочия при изменении ролей.
• Периодическая повторная сертификация: Проверяйте и проверяйте доступ ежеквартально.
• Отмена: Немедленно отмените доступ, если занятость заканчивается или роли больше не требуют доступа Salesforce.

Внедрите процессы повторной сертификации доступа, когда менеджеры периодически проверяют и проверяют полномочия своих рабочих групп. Частота проверки определяется риском и требованиями к соответствию.

Ваша ответственность: Внедрение SCIM, разработка бизнес-правил инициализации, проведение ежеквартальной повторной сертификации.

Разделение данных на несколько организаций иногда рассматривается исключительно как решение о стоимости или месте жительства. Архитектурно это компромисс безопасности, а последствия управления находятся в вашем дизайне доступа.

Изолированность - ключевое преимущество. Отдельные организации предоставляют максимально сильную границу между наборами данных. Нет модели коллективного общего доступа и перекрестного кровотечения полномочий клиента, но есть четкая нормативная линия для юрисдикций, требующих ее. Эта же граница фрагментирует управление. Каждый контроль доступа, который нужно поддерживать только один раз в одной организации (например, дизайн набора полномочий, иерархия ролей, закаливание организаций с критическим влиянием, базовые показатели проверки состояния, мониторинг событий и корреляция SIEM), теперь умножается на организацию, что означает, что он должен поддерживать согласованность во всех организациях. Дрифт между организациями создает собственную поверхность атаки, поскольку полномочие, ужесточенное в одной организации и пропущенное в другой, создает несоответствие, которое могут найти и использовать злоумышленники. Межорганизационные интеграции добавляют границы authenticated Trust, которых раньше не было. Каждая межорганизационная интеграция - это подключение, которое нужно обезопасить и отслеживать.

Поэтому важно соотнести преимущества изоляции с множителем управления, прежде чем разделить организацию. Резервируйте мультиорганизацию для случаев, когда жесткий мандат локализации или требование изоляции клиента по контракту действительно не может быть выполнено в одной организации. При принятии нужно создать модель доступа, мониторинг и базовые параметры конфигурации, которые должны применяться одинаково в каждой организации с самого начала.

Ваша ответственность: Рассматривайте решение нескольких организаций как компромисс безопасности, а не только как затратное. Если требуется мультиорганизация, последовательно примените контроль доступа, мониторинг и проверку состояния в каждой организации и обезопасьте каждую межорганизационную интеграцию в качестве границы Trust.

Классификация данных, настройка шифрования, создание элементов управления конфиденциальностью - это ваша обязанность.

Рассмотрим способы правильной защиты данных и конфиденциальности.

Чтобы правильно классифицировать данные, необходимо знать их. Главная архитектурная задача — понять бизнес-домен и вести словарь данных, каталогизирующий хранящиеся у вас данные, их значение и место проживания конфиденциальных данных. Система позволяет классифицировать или защищать только данные, определенные первыми.

Создайте схему классификации данных, которая управляет соответствующими средствами защиты. Метка классификации сама по себе ничего не защищает. Это вводные данные для применяемых элементов управления, поэтому каждая назначенная классификация должна быть соотнесена с конкретным решением по шифрованию, доступу, сохранению или мониторингу. Решения классификации, принимаемые во время моделирования данных, напрямую влияют на требования к шифрованию, средства контроля доступа, политики сохранности и обязательства соответствия.

В Salesforce мы используем четырехуровневую схему, предоставляющую инфраструктуру, которую можно адаптировать к нормативным требованиям и бизнес-потребностям организации. Многие предприятия используют аналогичные модели, соответствующие отраслевым стандартам (например, ISO 27001 и NIST). Ваше конкретное внедрение должно отражать ваши обязательства по соблюдению (например, HIPAA, PCI DSS, GDPR и отраслевые регламенты) и бизнес-контекст.

Применение классификации на уровне поля. Одна запись организации может содержать поля «Общедоступный» (например, названия компаний), «Конфиденциальный» (например, доходы компании) и «Ограниченный» (например, номера социального обеспечения). Безопасность поля должна отражать эти различия.

Классификация становится доступной посредством управления доступом на основе атрибутов, которое считывает назначенные теги и применяет правила доступа. Это слой под управлением метаданных, дополняющий правила OWD и общего доступа.

Согласование ABAC со схемой классификации позволяет платформе:

• Ограничьте доступ к данным с меткой «Ограничено» или «Конфиденциально» из самой классификации, а не из правила общего доступа, сохраняемого для каждого объекта.
• Адаптация доступа по мере изменения классификации записи в динамике. Запись с тегом «Регулируется» наследует более строгий доступ без изменения правила вручную.
• Объедините атрибуты данных (например, классификация и конфиденциальность) с атрибутами пользователя (например, отдел и допуск) и контекстом (например, время и расположение) в одном решении авторизации.

Разработайте политики ABAC в соответствии с этой схемой, чтобы классификация поля в качестве ограниченного была действием, управляющим контролем доступа и поддерживающим привязку применения к классификации, а не сохранение правил общего доступа отдельно.

Ваша ответственность: Определите схему классификации, обучите специалистов по моделированию данных, классифицируйте поля во время проектирования, настройте элементы управления и соотнесите политики ABAC с уровнями классификации, чтобы теги способствовали внедрению.

Начните с информации, которую платформа уже предоставляет для каждой организации. Данные в дежурном режиме шифруются по умолчанию. Hyperforce применяет шифрование уровня объема, защищающее весь объем хранилища под одним ключом, за который ответственен и управляет Salesforce. Этот базис всегда включен и прозрачен для вашего решения, но он работает на уровне объема (не на поле), поэтому выбор того, что шифровать и контролировать в жизненном цикле ключа, лежит на платформе, а не на вас.

Если этот базис не может соответствовать обязательству соответствия, контракта или классификации данных, используйте Shield Platform Encryption. В частности, если вам нужна одна из трех вещей, которую не предоставляет шифрование на уровне объема:

• Управление жизненным циклом ключа для создания, ротации и отзыва материала ключа самостоятельно
• Выборка стандартных полей, настраиваемых полей, файлов и вложений, шифруемых в дежурном режиме
• Возможность сделать данные недоступными для Salesforce.

Ограниченные данные и данные, подпадающие под четкие нормативные мандаты управления ключами (например, HIPAA, PCI DSS и GDPR), являются обычными триггерами. Базовый уровень уже охватывает защиту всего остального на уровне инфраструктуры.

Shield Platform Encryption шифрует на уровне поля, и она предлагает две схемы, которые обменивают безопасность на возможность запроса.

Вероятностное шифрование — это сильная стандартная схема, но поля, зашифрованные посредством нее, не могут использоваться в критериях фильтрации, сортировке или функциях агрегации (например, функции MAX(), MIN() и COUNT_DISTINCT().

Детерминистское шифрование поддерживает фильтрацию точных совпадений в отчетах, списковых представлениях и условиях SOQL WHERE (чувствительных к регистру или регистру) с пониженной прочностью, поскольку один и тот же обычный текст всегда создает один и тот же шифрованный текст.

Рекомендуем использовать вероятностную схему шифрования по умолчанию и резервировать детерминистское шифрование для определенных полей, которые нужно отфильтровать или отсортировать. Оцените эти преимущества во время проектирования моделирования данных, включительно с влиянием на ссылки на поля формул, агрегацию отчетов и операции SOQL.

Управляемые клиентом ключи могут иметь две разные формы:

• Bring Your Own Key (BYOK) позволяет создавать материал ключа за пределами Salesforce (посредством собственных криптобиблиотек, корпоративной системы управления ключами или модуля аппаратной безопасности) и поставлять его на платформу.
• Служба кэш-ключей хранит ключ шифрования данных в контролируемой вами службе ключей. Salesforce извлекает его по запросу, а не сохраняет.

Обе формы позволяют сменять и уничтожать материал ключа по собственному расписанию. Уничтожение материала ключа делает данные, защищенные им, невосстановимыми, что является мощным, преднамеренным управлением вместо рутины. Важно также задокументировать процедуры ротации и отзыва ключей.

Все интеграции должны использовать TLS 1.2 или выше (платформа Salesforce внедряет это), но необходимо внедрить взаимную проверку подлинности на основе сертификата для интеграций, обрабатывающих ограниченные данные (используя собственную конфигурацию).

Ваша ответственность: Решите, где достаточно базиса платформы на уровне объема и где обязательство соответствия, контракта или классификации оправдывает Shield Platform Encryption, потом выберите схемы шифрования, выберите и управляйте стратегией ключей, контролируемых клиентом, и внедрите проверку подлинности на основе сертификата для конфиденциальных интеграций.

Защита конфиденциальных данных в непроизводственных средах посредством стратегий, предотвращающих проникновение данных с ограничением в безопасные среды.

• Частичное копирование безопасной среды исключает ограниченные данные из обновлений безопасной среды.
• Правила маскировки данных путают значения конфиденциальных полей в безопасных средах, используя схемы, сохраняющие характеристики данных.
• Создание синтетических данных применяется к средам разработки, которые не требуют производственных данных.
• Шаблоны безопасной среды определяют, какие объекты и поля добавлять в каждый тип безопасной среды.

Проектирование для проверки соответствия является архитектурной ответственностью. Создавайте циклы разработки и тестирования на основе синтетических данных с реалистичными характеристиками, чтобы рабочие группы могли проверять условия, аналогичные условиям производства, в то время как регулируемые данные остаются в пределах производственной границы.

Ваша ответственность: Разработка стратегии безопасной среды sandbox, настройка правил Data Mask, создание данных синтетических тестов.

Создайте решения, учитывающие конфиденциальность пользователей посредством архитектурных решений.

• Минимизация данных: Собирайте данные, необходимые только для заявленных бизнес-целей. Вызовите каждое добавление поля, спросив: «Какое архитектурное решение требует этих данных?» Помните, что самые безопасные данные - это данные, которые вы никогда не собираете.
• Ограничение цели: Разработайте схемы доступа к данным, обеспечивающие техническое ограничение цели. Используйте наборы полномочий и правила общего доступа для ограничения доступа к данным на основе цели функции задания. Например, пользователи Marketing не должны получать доступ к сведениям об обращении за поддержкой, если это не требуется их работой.
• Управление согласием: Внедрите отслеживание согласия на индивидуальном уровне для маркетинга, аналитики и дополнительной обработки данных. Создайте бизнес-процессы отзыва согласия, распространяющиеся в интегрированных системах. Другими словами, согласие является детализированным и имеет конкретную цель.
• Права субъекта данных: Создайте бизнес-правила для запросов доступа (например, предоставление копий данных), исправления (например, исправление неточностей), удаления (например, удаление данных, когда это разрешено законом) и переносимости (например, экспорт в машиночитаемый формат). Создайте эти бизнес-правила для выполнения в пределах крайнего срока ответа, установленного каждой управляющей инфраструктурой. Эти крайние сроки отличаются в зависимости от юрисдикции, и они периодически изменяются, поэтому важно параметризировать SLA бизнес-правила из сохраненного источника соответствия и подтвердить каждое окно в соответствии с управляющим регламентом (вместо жесткого кодирования одного значения).

Ваша ответственность: Разработайте модели данных с минимизацией, настройте доступ по цели, внедрите бизнес-процессы согласия, создайте автоматизацию прав субъекта данных.

Резиденция данных — это выбор архитектурного решения, принимаемый перед инициализацией, а не параметр, переключаемый после. Hyperforce предлагает региональное развертывание (но регион существует только там, где Salesforce управляет им), а резидентура организации фиксируется при инициализации. Ваша обязанность — определить местоположение каждой категории данных, подтвердить наличие подходящего региона и разработать механизмы передачи данных, которые законно пересекают границы.

Вместо стандартного хранения в стране, важно классифицировать обязательства проживания перед началом.:

• Обязательная локализация. Небольшой набор юрисдикций требует наличия определенных данных для пребывания в пределах национальных границ (иногда это относится только к регулируемым секторам). Если Salesforce не работает в регионе страны, нативное хранилище не может выполнить мандат самостоятельно, поэтому вам нужно наложение резидентства данных или отдельная организация для этих данных. Поскольку этот список может сместиться, важно подтвердить конкретный мандат относительно управляющего регламента.
• Инфраструктуры на основе подотчетности. Большинство режимов не навязывают мандат локализации. Их удовлетворяет региональный центр с соответствующим механизмом трансграничной передачи. В этих случаях решение основано на том, какой регион минимизирует задержку и упрощает соответствие.

Когда данные пересекают границу, смысл в осведомленности перед конфигурацией. Другими словами, нужно знать, какие передачи происходят и на какой правовой основе, а потом создать доступ, чтобы данные управлялись из конца в конец. Там, где они существуют, решения об адекватности сопряжены с наименьшим трением. Обязательные корпоративные правила (BCR) и стандартные договорные условия (SCC) охватывают большинство оставшихся перемещений. Используйте явное согласие только в крайнем случае.

Сочетайте механизм передачи с ограничительным доступом к записям (например, личные ОВД и целевой общий доступ), чтобы допустимая передача не стала чрезмерно широкой. Поток данных документа соотносится для отображения места происхождения, транзита и нахождения каждой категории данных. Повторите их при изменении регламентов или региональных доступностей.

Ваша ответственность: Классифицируйте обязательства проживания по категории данных, подтвердите региональную доступность перед инициализацией, выберите механизмы передачи (адекватность, BCR/SCC) для трансграничных потоков и задокументируйте карты потоков данных.

Ваша ответственность за разработку решений, поддерживающих состояние соответствия, предоставляемое платформой.

Это руководство является направленным. Регулирующие требования определяются юрисдикцией и меняются с течением времени. Всегда нужно проверять конкретные обязательства по регламенту (например, применимый устав, контролирующий орган или документация по соответствию Salesforce) для развертывания.

Salesforce поддерживает обширные сертификаты соответствия (доступны на Trust.salesforce.com и compliance.salesforce.com): SOC 2 Type II, ISO 27001, FedRAMP (для предложений Government Cloud), HIPAA, PCI DSS и региональные сертификаты. Эти сертификации охватывают обязанности Salesforce по инфраструктуре платформы и общедоступным службам.

Сертификация платформы уменьшает нагрузку на соответствие, но не устраняет архитектурную ответственность. Ваши настраиваемые объекты, код Apex, интеграции и конфигурации должны поддерживать состояние соответствия, предоставляемое платформой.

Ваша ответственность: Разработка решений, поддерживающих состояние соответствия, документирование соответствия архитектуры нормативным требованиям.

• Включите Shield Platform Encryption для всех полей, содержащих защищенную информацию о здоровье (PHI).
• Для соответствия HIPAA включите «Полевой контрольный журнал» с политиками сохранности, чтобы соответствовать требованиям HIPAA к ведению записей. Подтвердите текущий период относительно управляющего регламента.
• Настройте мониторинг событий для обнаружения несанкционированных схем доступа PHI.
• Внедрите все технические гарантии, требуемые правилом безопасности HIPAA, включительно с контролем доступа, регистрацией аудита и безопасностью передачи.

• Внедрите разделение обязанностей (SoD) посредством дизайнов наборов полномочий, чтобы предотвратить создание и утверждение финансовых транзакций отдельными пользователями.
• В средах PCI избегайте сохранения полных основных номеров организаций (PAN) в Salesforce, чтобы минимизировать область соответствия PCI DSS.
• При возможности используйте маркеризацию шлюза оплаты.

• Для GDPR и LGPD создайте управление согласием, собирающее детализированное, специальное согласие на согласие.
• CCPA/CPRA следует модели отказа. Предоставьте четкие механизмы для отказа от продажи или предоставления общего доступа к личным данным, а не от получения согласия с детализацией цели.
• Создайте бизнес-правила прав субъекта данных, которые выполняются в пределах крайнего срока ответа каждой инфраструктуры и подтверждаются управляющим регламентом.
• Внедрите автоматизацию сохранности данных, удаляющую данные после истечения срока действия согласия.

• Используйте Salesforce Government Cloud для регламентированных загруженности правительств.
• Внедрите элементы управления NIST 800-53, соотнесенные с конфигурацией Salesforce.
• Включите непрерывный мониторинг посредством мониторинга событий, перенаправляемого в правительственную инфраструктуру SIEM.

Ваша ответственность: Настройте Shield, контрольный журнал поля, разделение обязанностей, управление согласием, сохранность данных на основе нормативных требований.

Правила о конфиденциальности и защите данных существенно отличаются в разных правовых системах, и конкретные обязательства меняются быстро, поэтому этот уровень требует принятия решений, а не составления таблиц по странам.

Двумя архитектурными рычагами являются резидентство и трансграничная передача, которые охватываются разделами " Защита данных " и " Конфиденциальность " .

Чтобы придерживаться данных правил, необходимо:

• Классификация расположения каждой категории данных
• Убедитесь в наличии подходящей области перед инициализацией
• Создайте легальный механизм передачи данных, пересекающих границу.

Дополнительные сведения см. в разделе «Резиденция и суверенитет данных» для получения дополнительных сведений о структуре решений.

Все, что выходит за рамки этого, считается временной цифрой (например, модель согласия, используемая юрисдикцией, крайний срок запроса субъекта данных, окно для уведомления регулирующих органов или затрагиваемых лиц после нарушения и минимальный срок хранения для аудиторских записей). Эти цифры устанавливаются нормативными актами, они отличаются в зависимости от инфраструктуры и вносятся поправки в расписания регулирующих органов.

Не программируйте их здесь жестко. Вам нужно определить следующие этапы на основе регламента для развертывания (или поддерживаемого источника соответствия, который ссылается на него) и размер дизайна до самого тесного окна в вашем следе в работе.

Ниже указаны долговременные архитектурные последствия, которые должны быть предусмотрены в проекте.

• Крайний срок запроса темы данных, измеряемый в однозначных днях, не может быть соблюден специальным ручным процессом, поэтому выполнение DSR нужно автоматизировать при работе в любой юрисдикции с коротким сроком. Используйте Experience Cloud для приема, Service Cloud для отслеживания обращений, центр конфиденциальности для обнаружения и поток для выполнения.
• Окно уведомления о нарушении слишком тесное для импровизации, поэтому бизнес-правило реагирования на нарушение нужно создать заранее. Определите правила аномалий отслеживания событий, предварительно назначенные роли, предварительно составленные уведомления регулятора и субъекта данных, а также путь расширения, который предполагает самый жесткий срок в пределах вашего следа. Отдельные уведомления обычно запускаются определением высокого риска, поэтому необходимо добавить оценку риска в бизнес-правила.
• Некоторые юрисдикции требуют или рекомендуют сохранение журналов аудита в стране (минимум на протяжении нескольких лет), поэтому вам нужно увеличить хранение SIEM до самого длительного минимума в пределах вашего выброса и подтвердить, могут ли журналы выйти из юрисдикции.

Ваша ответственность: Разработайте резидентство и передачу на защиту и конфиденциальность данных, автоматизируйте бизнес-процессы DSR и реагирования на нарушения до самого жесткого крайнего срока в вашем следе и подтвердите каждую конкретную цифру юрисдикции относительно управляющего регламента, а не значения, записанного в этом руководстве.

Создайте для постоянной проверки соответствия, а не для своевременной подготовки к аудиту.

• Проверка состояния безопасности оценивает конфигурацию относительно базовых параметров безопасности Salesforce и предоставляет оценки риска. Регулярно выполняйте проверки для контроля соответствия базовым рекомендациям безопасности Salesforce. Поддерживайте рейтинги 80% или выше (очень хорошие или отличные группы).
• Отслеживание событий собирает подробные журналы действий пользователя, вызовов API, событий проверки подлинности и схем доступа к данным. Перенаправляйте файлы журнала событий во внешний SIEM для длительного хранения, превышающего собственные ограничения хранения.
• Безопасность транзакций оценивает события по полисам в режиме реального времени и может блокировать события, требовать увеличения MFA или уведомлять о нарушениях полисов.

Важно автоматизировать проверки соответствия в ожидаемых продажах развертывания, чтобы убедиться, что развертывания не ослабляют модели полномочий, не отключают параметры аудита и не внедряют несоответствующие конфигурации.

Ваша ответственность: Запустите проверку состояния ежеквартально, перенаправьте мониторинг событий в SIEM, настройте политики безопасности транзакций, автоматизируйте проверку соответствия в CI/CD.

Разработайте стратегии контрольного журнала, основанные на требованиях к соблюдению, потребностях расследования и обязательствах по сохранению.

В регулируемых средах внедрите мониторинг событий с внешней интеграцией SIEM для долгосрочной сохранности журнала и межсистемной корреляции. Разработка политик контрольного журнала поля, охватывающих все ограниченные и конфиденциальные поля, соответствующие нормативным требованиям к ведению записей.

Ваша ответственность: Включите контрольный журнал поля для конфиденциальных полей, перенаправьте мониторинг событий в SIEM, настройте политики безопасности транзакций.

Это ваша обязанность интегрировать безопасность на протяжении всей разработки, а не в качестве запоздалой мысли.

Интегрируйте методы безопасности на самом раннем этапе разработки. Моделирование угроз на этапе архитектуры предотвращает уязвимости на уровне дизайна. Требования безопасности, собранные вместе с функциональными требованиями, не позволяют относиться к безопасности как к запоздалому.

Устранение дефектов безопасности обходится значительно дороже, если они обнаружены в производстве, а не на этапах проектирования или разработки. Недостаток безопасности на уровне дизайна, обнаруженный во время проверки архитектуры, может исправиться только одним разговором. Однако, при обнаружении аналогичного недостатка в производстве требуется переархитектура, миграция данных, исправление соответствия и уведомление о потенциальном нарушении.

Поэтому мы практикуем безопасность смены налево, которая фокусируется на:

• Моделирование угроз до завершения проектирования
• Требования безопасности в историях пользователей
• Обучение разработчиков безопасному кодированию
• Статический анализ, интегрированный в IDE
• Проверка кода на безопасность
• Автоматическое тестирование безопасности в CI/CD
• Проверка безопасности перед развертыванием в производственной среде

Ваша ответственность: Выполните моделирование угроз, обучите разработчиков, интегрируйте анализатор кода в CI/CD, требуйте проверки кода с учетом безопасности.

Важно создать защиту от распространенных уязвимостей в контексте Salesforce. Рассмотрим более подробно соотнесение с топ-10 OWASP 2020 года в Salesforce.

• A01:2025 - Управление взломанным доступом: Программным способом внедряйте CRUD и безопасность поля (FLS) во всем доступе к данным Apex
  • В API версии 67.0 или более поздней Apex выполняется в контексте пользователя по умолчанию, что означает, что полномочия и FLS текущего пользователя внедряются во время выполнения кода.
    • WITH SECURITYENFORCED был удален, что приводит к ошибке компиляции. Замените любые существующие виды использования на «С ИСПОЛЬЗОВАНИЕМ_РЕЖИМА». Платформа применяет доступ в стандартном пользовательском интерфейсе.
  • В API версии 66.0 или более ранней системный режим используется по умолчанию. Используйте WITH USERMODE в запросах SOQL или Security.stripInaccessible() для операций DML.
• A01:2025 - Клиентские API данных: Lightning Data Service и пользовательский интерфейс API автоматически внедряют FLS, CRUD и общий доступ текущего пользователя, поэтому компонент, созданный на их основе, наследует наименьшие привилегии по умолчанию.
  • Эта защита теряется, когда компонент вызывает настраиваемый Apex. Императивный Apex применяет доступ только при работе в режиме пользователя, поэтому класс, заявленный без общего доступа, действует как аварийный люк, который негласно обходит модель.
  • Используйте Lightning Data Service и пользовательский интерфейс API для доступа к данным.
  • Необходимо повторно утвердить CRUD, FLS и общий доступ для каждого императивного вызова Apex из компонента.
• A02:2025 - Неправильная конфигурация безопасности: Отслеживайте отклонение конфигурации от базовых показателей безопасности посредством проверки состояния.
  • Отключите доступ пользователя-гостя на сайтах Experience Cloud (если только это не обязательно в соответствии с документированным бизнес-обоснованием).
• A05:2025 - Впрыск: Категория «Внедрение 2025 года» охватывает впрыскивание SOQL/SOSL и межсайтовое скриптирование (XSS).
  • Для инъекции запроса используйте переменные связывания для всех динамических запросов. Никогда не конкатенируйте вводные данные пользователя напрямую в строки запроса. Параметризованные механизмы запросов платформы исключают риск инъекции при правильном использовании.
  • Инъекции SOQL или SOSL ограничены показаниями, которые открывают записи или поля, к которым абонент не должен иметь доступа посредством расширения условий запроса. Поскольку эти языки читают данные во время выполнения записей посредством отдельных операций DML, это создает риск контроля доступа и конфиденциальности, поскольку это усугубляется, когда полномочия объекта и поля не применяются к запросу.
  • Для XSS веб-компоненты Lightning предоставляют автоматическую защиту посредством механизма рендеринга LWC.
  • Для компонентов Aura и Visualforce при отображении динамического содержимого нужно применить функции кодирования платформы (например, HTMLENCODE, JSENCODE и URLENCODE).

Ваша ответственность: Внедрите CRUD/FLS в настраиваемый код, примените функции кодировки, используйте переменные связывания, отслеживайте отклонение конфигурации.

Создайте конвейеры CI/CD с воротами безопасности на каждом этапе. Безопасность должна быть автоматизирована для масштабирования со скоростью разработки.

Рассмотрим этапы безопасности ожидаемых продаж.

• Контроль источников использует правила защиты ответвления с обязательными проверками кода. Прямых обязательств перед основными ответвлениями или подписанных обязательств нет.
• Статический анализ использует Salesforce Code Analyzer, который использует PMD, ESLint и RetireJS для обнаружения схем впрыска, XSS и небезопасных схем.
• Сканирование безопасности использует инструменты SAST и обнаружение секретов для предотвращения обязательств регистрационных данных и сканирования уязвимости зависимости.
• Проверка полномочий использует методы автоматического сравнения для проверки изменений полномочий по сравнению с базовыми показателями безопасности, отправляющими предупреждения о расширении полномочий.
• Шлюзы развертывания нарушают развертывание по критически важным выводам безопасности, требующим утверждения группой безопасности для изменений расширения полномочий.
• Мониторинг после развертывания использует предупреждения мониторинга событий для аномального поведения после развертывания.

Ваша ответственность: Интегрируйте анализатор кода в CI/CD, настройте защиту ответвления, внедрите шлюзы развертывания, проверьте полномочия автоматически.

Комплексное тестирование безопасности включает несколько методов, предназначенных для разных классов уязвимости. Рассмотрим более подробно каждую стратегию.

• Статический анализ запускает Salesforce Code Analyzer в IDE разработчика для немедленной обратной связи и в ожидаемых продажах CI/CD в качестве автоматических ворот. Статический анализ определяет уязвимости исходного кода без выполнения приложения.
• Тестирование проникновения выполняет тестирование проникновения для настраиваемых приложений, открытых для ненадежных пользователей, особенно сайтов Experience Cloud и общедоступных API.
  • В AppExchange и AgentExchange Security Review отчеты по статическому анализу всегда обязательны.
  • Динамический отчет по сканированию (тест на проникновение) обязателен, когда решение интегрирует стороннее веб-приложение или службу.
  • Тестирование проникновения имитирует приемы атаки против оперативных приложений.
• Тесты безопасной единицы пишут тесты Apex, проверяющие принудительное управление доступом посредством запуска в качестве пользователей с разными профилями полномочий. Важно проверить, блокирует ли применение CRUD/FLS несанкционированный доступ.
• Сканирование зависимости отслеживает пакеты AgentExchange и библиотеки JavaScript на наличие известных уязвимостей. Важно подписаться на рекомендации по безопасности для установленных пакетов.

Ваша ответственность: Запустите анализатор кода, выполните тестирование проникновения, напишите тесты блоков безопасности, отсканируйте зависимости.

В Salesforce меры безопасности и реагирования на инциденты данных фокусируются на обнаружении, локализации и восстановлении после взлома, несанкционированного доступа и уничтожения вредоносных данных. Группы реагирования на инциденты работают вместе с двумя соседними компонентами, ответственными за смежные обязанности:

• Operational Excellence охватывает оперативный механизм управления инцидентами (например, уровни серьезности, ротация по вызову, расширение и проверка после инцидента)
• Надежность охватывает восстановление доступности по сравнению с целями РТО и РПО, включая резервную копию и стратегию аварийного восстановления.

Архитектор несет ответственность за создание для обнаружения инцидентов безопасности, реагирования и восстановления.

Обнаруживаемость — это архитектурное качество, которое должно быть разработано специально. Без всеобъемлющего мониторинга инциденты в области безопасности могут оставаться незамеченными в течение длительного времени.

Важно внедрить обнаружение через несколько каналов.

• Отслеживание событий собирает исходные журналы событий, охватывающие входы, экспорт отчетов и данных, изменения полномочий и вызовы API. Вам нужно определить, какие события являются аномалиями, что требует наличия политик безопасности транзакций или корреляции SIEM вверху журналов, настроенных для определения логики обнаружения.
• Политики безопасности транзакций оценивают события в режиме реального времени и блокируют подозрительные действия. Вам нужно настроить эти политики.
• Контрольный журнал настройки отслеживает административные изменения, предоставляемые платформой, но их нужно отслеживать.
• Журнал настраиваемых приложений собирает события безопасности в Apex, которые нужно внедрить.

Перенаправляйте журналы мониторинга событий на платформы SIEM для корреляции с телеметрией безопасности предприятия. Разработайте правила предупреждения, которые определяют подозрительные схемы, а также минимизируют ложные положительные результаты посредством поведенческих базисов.

Ваша ответственность: Перенаправляйте мониторинг событий в SIEM, настраивайте политики безопасности транзакций, внедряйте настраиваемый журнал, устанавливайте поведенческие базисы.

Важно задокументировать архитектурные решения, поддерживающие реакцию на инциденты до того, как инциденты произойдут.

• Границы изоляции проектируют решения для изоляции скомпрометированных компонентов без нарушения важных бизнес-функций. Вам нужно настроить отзыв набора полномочий, изменения ограничения IP-адресов и завершение сеанса для предоставления возможностей быстрой изоляции .
• Сохранение криминалистики использует мониторинг событий для предоставления подробных журналов действий (функция платформы). Контрольный журнал поля сохраняет журнал изменений данных на основе конфигурации. Создайте журналы маршрутизации в неизменяемое хранилище, чтобы злоумышленники не могли изменить вашу архитектуру.
• Процедуры восстановления документируют протестированные процессы восстановления для распространенных типов инцидентов. Важно регулярно проверять целостность резервной копии. Вам нужно знать цель времени восстановления (RTO) и цель точки восстановления (RPO) для сценариев инцидентов безопасности.
• Бизнес-процессы связи разрабатывают механизмы уведомлений, функционирующие во время инцидентов (например, внешние каналы связи, готовые шаблоны и процедуры расширения, которые не зависят от потенциально скомпрометированных систем).
• Канал разглашения уязвимости предназначен для общедоступных сайтов Experience Cloud. Он предоставляет внешним исследователям документированный и отслеживаемый способ сообщить о проблемах безопасности посредством политики разглашения, опубликованной в стандарте безопасности RFC 9116.txt. Внешний отчет часто является первым сигналом инцидента, поэтому важно установить этот путь приема как часть архитектуры, за которую вы ответственны.

Ваша ответственность: Процедуры изоляции документов, маршрутизация журналов в неизменяемое внешнее хранилище, ежеквартальное тестирование процедур восстановления, установление внешних связей и публикация канала раскрытия уязвимости для общедоступных сайтов.

В Salesforce важно подготовить возможности ответа для сценариев платформы.

• Компрометированные организации пользователей обнаруживаются посредством аномалий входа Event Monitoring (например, непредвиденная география, необычное время и новые устройства). При компрометации организаций заморозьте пользователя, принудительно сбросьте регистрационные данные, просмотрите контрольный журнал настройки и журналы доступа к данным для определения периода компрометации.
• Пакетное извлечение данных обнаруживается посредством экспорта отчетов по мониторингу событий и аномалий объема доступа к данным API. При извлечении данных немедленно отзовите сеансы, ограничьте полномочия и определите задействованные записи и уровни классификации.
• Несанкционированное развертывание кода обнаруживается посредством мониторинга развертывания и изменений конфигурации контрольного журнала настройки. При развертывании несанкционированного кода немедленно откатите развертывание и проверьте все изменения по сравнению с скомпрометированными регистрационными данными развертывания.
• Повышение привилегий определяется контрольным журналом настройки на наличие изменений полномочий, выходящих за пределы утвержденных окон изменений. При повышении привилегий немедленно отмените расширенные привилегии и действия аудита, выполненные с повышенным доступом.

Ваша ответственность: Документируйте процедуры ответа для сценариев платформы, настройте мониторинг для обнаружения каждого сценария, протестируйте процедуры посредством настольных упражнений.

После инцидента важно провести беспристрастную проверку после инцидента, сфокусированную на архитектурных усовершенствованиях. Нужно задокументировать произошедшее, почему существующие средства контроля не смогли предотвратить или обнаружить инцидент, и какие архитектурные изменения необходимы для снижения будущих рисков.

Цели проверки после инцидента:

• Определите временную шкалу инцидента и приемы взлома.
• Определите ошибки управления, которые привели к инциденту.
• Задокументируйте все архитектурные слабости, которые выявил инцидент.
• Установите приоритеты исправления на основе уменьшения риска.
• Общий доступ к урокам, извлеченным в рабочей группе.
• Обновите правила обнаружения и процедуры ответа.

Важно отслеживать показатели инцидентов во времени, чтобы определить среднее время обнаружения (MTTD), среднее время ответа (MTTR) и область влияния.

Ваша ответственность: Своевременное проведение обзора после инцидента, документирование усовершенствований в ОРР, отслеживание тенденций MTTD и MTTR, обмен извлеченными уроками.

Используйте этот контрольный список во время проверок архитектуры, перед развертыванием производственной среды и периодически для текущей оценки. Каждый элемент соответствует вашим обязанностям архитектора Salesforce.

Совместная ответственность

• Задокументируйте все, что защищает Salesforce (например, инфраструктуру, платформу и сертификаты соответствия).
• Задокументируйте все необходимое (например, конфигурацию, доступ, настраиваемый код и управление данными).
• Определите области общей ответственности (например, реагирование на инциденты, управление уязвимостями и мониторинг).
• Как можно четче и лаконичнее излагать обязанности заинтересованным лицам и группам, занимающимся внедрением.

Архитектура безопасности

• Прежде чем начать создание, выполните моделирование угроз с помощью методологии STRIDE.
• Примените глубокое управление защитой на уровнях данных, приложения, удостоверения и интеграции.
• Внедрите принципы zero- Trust, требующие явной проверки для каждого запроса доступа.
• Ведите текущий запас активов безопасности, охватывающий конфиденциальные данные, интеграции, API и привилегированные организации.
• Документируйте решения архитектуры безопасности в ADR, включительно с анализом угроз и обоснованием управления.
• Защитите клиентов без заголовка и от имени клиента на границе Salesforce Trust, распространив удостоверения каждого пользователя, а не маркеры пула.
• Хранение, ротация и использование регистрационных данных OAuth с наименьшими полномочиями посредством приложений внешних клиентов.
• Для контейнерных интеграций внедрите изоляцию контейнеров в качестве границы безопасности, зашифруйте межконтейнерный и гибридный VPN-трафик посредством mTLS (когда этого требует инфраструктура) и соотнесите регионы развертывания с сертификатами резидентства данных и соответствия

Управление удостоверениями и доступом

• Задайте OWD значение «Личный» для объектов, содержащих конфиденциальные данные.
• Зарезервируйте «Общедоступный: только для чтения» для объектов, где широкий доступ для чтения является документированным требованием.
• Внедрите MFA для всех доступов производственного пользовательского интерфейса и ключи безопасности аппаратного обеспечения для привилегированных организаций. Интеграции только API, использующие JWT Bearer или регистрационные данные клиента, исключены.
• Внедрите SSO посредством SAML 2.0 или OpenID Connect с сильной проверкой подлинности IdP.
• Используйте OAuth 2.0 (предпочтительный носитель JWT) для любой проверки подлинности API. Никогда не используйте OAuth 2.0 для встроенных регистрационных данных.
• Предоставьте доступ посредством наборов полномочий, основанных на документированных требованиях к наименьшим правам.
• Примените расширенные элементы управления к организациям с критическим влиянием (например, ограничение IP-адресов, предупреждения о входе и периодические проверки доступа).
• Выполняйте периодические проверки доступа с использованием документированной проверки для организаций с высоким уровнем прав, где частота определяется допустимыми организационными рисками и требованиями соответствия.
• Автоматизируйте жизненный цикл удостоверения посредством инициализации SCIM и обнаружения неактивной организации за 90 дней.
• Запустите агентов сотрудников в контексте зарегистрированного пользователя и предоставьте выделенных пользователей-агентов с наименьшими полномочиями для агентов клиентов. Никогда не делайте этого для общедоступного пользователя-гостя.
• Внедрите JWT для проверки подлинности агента посредством экземпляра агента и идентификаторов определения бота.
• Определите политики ABAC, соответствующие классификации данных и согласованным стандартам присвоения тегов метаданных.

Защита и конфиденциальность данных

• Классифицируйте все данные и примените средства защиты, соответствующие каждому уровню классификации.
• Включите Shield Platform Encryption for Restricted посредством управления документированными ключами.
• Требовать TLS 1.2+ для всех интеграций с проверкой подлинности на основе сертификата для данных Restricted.
• Предотвращение проникновения ограниченных данных в непроизводственные среды посредством маскировки или исключения.
• Внедрите управление согласием посредством детального отслеживания и снятия бизнес-правил.
• Создайте бизнес-процессы прав субъекта данных, которые выполняются в пределах крайнего срока ответа каждой управляющей инфраструктуры. Они должны быть размером до самого тесного окна в вашем операционном следе и параметризированы для каждой юрисдикции из поддерживаемого источника соответствия, где каждая цифра подтверждается управляющим регламентом.
• Задокументируйте требования к резидентству данных и проверьте выравнивание региона Hyperforce.

Соответствие и соблюдение нормативных положений

• Проверьте сертификаты платформы, соответствующие нормативным требованиям вашей отрасли.
• Включите мониторинг событий с маршрутизацией SIEM для сохранности, превышающей собственные ограничения сохранности.
• Настройте контрольный журнал поля для охвата полей «Ограниченные», чтобы обеспечить соответствие сохранности нормативным минимумам.
• Поддерживайте рейтинги проверки состояния безопасности 80% или выше (диапазон «Очень хорошо» или «Отлично») и документируйте все исключения.
• Автоматическая проверка соответствия для ожидаемых продаж CI/CD, которые прерываются во время серьезных нарушений.
• Внедрите политики безопасности транзакций для обнаружения аномалий и реагирования в реальном времени.

Жизненный цикл безопасной разработки

• Выполните моделирование угроз на этапе проектирования (перед осуществлением значительных инвестиций в создание).
• Внедрите CRUD/FLS во всех средах Apex.
• Рекомендуем использовать автоматическое внедрение пользовательского режима для API версии 67.0 или более поздней или использовать WITH USERMODE или stripInaccessible() для API версии 66.0 или более ранней.
• Не используйте с помощью SECURITYENFORCED, удаленного в API версии 67.0.
• Запустите Salesforce Code Analyzer в CI/CD, когда критические выводы блокируют развертывание.
• Требуйте проверки кода проверяющими средствами безопасности для всех производственных изменений.
• Выполните тестирование проникновения для всех общедоступных приложений и сайтов Experience Cloud.
• Проверьте и оздоровите все вводные данные пользователя, предотвращающие закачку в контекстах SOQL, SOSL и HTML.

Реакция на инциденты безопасности

• Разработайте правила предупреждения Event Monitoring для обнаружения подозрительных схем посредством поведенческих базисов.
• Перенаправляйте журналы в неизменяемое внешнее хранилище для криминалистической сохранности.
• Задокументируйте и протестируйте процедуры реагирования на инциденты для сценариев платформы.
• Выполните безупречные проверки пост-аварий с помощью ADR для сбора архитектурных улучшений.
• Отслеживайте показатели MTTD и MTTR для определения пробелов обнаружения и ответа.

Опубликуйте отзыв о инфраструктуре с хорошей архитектурой.