Прочитайте о расписаниях обновления здесь.

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

Salesforce ставит во главу угла Customer Trust и безопасность данных. Salesforce Platform обеспечивает конфиденциальность и безопасность. Сведения о производительности и безопасности системы в режиме реального времени доступны в Salesforce Trust.

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

Чтобы повысить безопасность решений, сосредоточьтесь на трех областях: организационная безопасность, безопасность сеанса и безопасность данных.

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

Ниже перечислены признаки проблемной организационной безопасности.

• Специальные процессы активации или деактивации пользователей
• Неясные шаги по обновлению авторизации для изменения роли пользователя или системы
• Использование институциональных Knowledge отдельных лиц для корректного назначения безопасности пользователей
• Несоответствие установленным системам безопасности или передовым методам отрасли
• Отсутствие структурированной системы управления данными и вспомогательных политик

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

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

Для создания безопасных потоков проверки подлинности в Salesforce:

• Создание пользователей Salesforce на основе отдельных лиц, а не персон. Встроенные возможности аудита Salesforce наиболее эффективны, когда каждая организация пользователя соответствует отдельному лицу, открывающему платформу. Использование общедоступных организаций-пользователей подрывает эффективность этих проверок, создает дополнительные уязвимости безопасности, повышает потенциальное влияние взлома организаций и затрудняет возможность создания эффективных схем авторизации. Сюда входят организации пользователей для пользователей интеграции.
• Безопасные сценарии доступа на основе пользовательского интерфейса. Для большинства пользователей требуется доступ на основе пользовательского интерфейса (часто называемый доступом входа) для организации Salesforce. Salesforce предоставляет несколько уровней защиты для следующих сценариев входа, включая:
  • Политики паролей. Киберпреступники часто выбирают имена пользователей и пароли для получения несанкционированного доступа к приложениям. Хотя настройка политик паролей является основополагающим шагом в защите доступа, важно отметить, что одного этого недостаточно, поскольку Salesforce разрешает переопределение этих политик для каждого пользователя.
  • Многофакторная проверка подлинности (MFA). Salesforce требует MFA для всех входов пользователей на основе пользовательского интерфейса. MFA предоставляет важную защиту от утечек регистрационных данных и атак грубой силы, требуя от пользователей предоставить дополнительную форму идентификации или фактор после успешного ввода имени пользователя и пароля. Этот дополнительный фактор обычно принимает физическую форму, например, мобильное устройство, ключ безопасности или биометрический маркер.
  • Единый вход (SSO). В сценариях единой регистрации пользователи используют только один набор регистрационных данных в приложениях организации. Доступ к системам обеспечивается и управляется из центрального расположения, что повышает безопасность. Salesforce может выступать в качестве поставщика услуг или поставщика удостоверений в сценариях единой регистрации. Обязательно разрешите некоторым или всем администраторам напрямую входить в Salesforce, чтобы они могли решить проблемы с внедрением единого входа.
  • Этапы после входа. В некоторых сценариях использования пользователям может понадобиться выполнить дополнительные действия перед доступом к системе. Настраиваемые потоки входа могут быть внедрены, чтобы помочь пользователям выполнить эти дополнительные этапы процесса. Примеры:
    • Принятие условий
    • Проработка сценариев обнаружения входа и входа без пароля
    • Ограничение количества одновременных сеансов Salesforce на пользователя для уменьшения вероятности атак на основе сеанса (см. безопасность сеанса).
    • Подключение к службам геофехтования
• Безопасные сценарии доступа на основе API. Любой пользователь может запросить доступ на основе API для организации Salesforce. Salesforce предоставляет несколько уровней защиты для сценариев на основе API, включая:
  • API Access Control. Без управления доступом к API любое приложение, поддерживающее допустимый набор регистрационных данных, может быть подключено к вашей организации, даже если связанное приложение не развернуто в организации. Средства контроля доступа к данным будут применяться, но пользователи могут получать доступ к информации неконтролируемым способом. Например, приложение может использоваться для загрузки больших объемов данных или даже передачи поврежденных сведений без разрешения системного администратора.
  • Полномочия API Only. Полномочия пользователя API Only можно настроить в Salesforce. Назначьте это как часть набора полномочий любому автоматическому пользователю или пользователю интеграции для полной блокировки доступа на основе пользовательского интерфейса.
  • Сертификаты и ключи. Сертификаты и ключи позволяют Salesforce проверять, исходят ли запросы от авторизованных предприятий или компаний. Чтобы использовать единую регистрацию в Salesforce, настройте сертификаты и ключи.
  • Связанные приложения. Настройка связанных приложений в Salesforce позволяет управлять доступом внешней системы к Salesforce, включительно с обязательными протоколами проверки подлинности, областью авторизации и поведением сеанса в одном определении.
  • Именованные регистрационные данные. Именованные регистрационные данные позволяют управлять внешними точками доступа и протоколами проверки подлинности в одном определении в Salesforce. Используйте их для безопасного определения и управления проверкой подлинности для выносок из Apex, внешних служб и источников данных Salesforce Connect.
• Проверка подлинности пользователей Agentforce Agentforce. Агенты Agentforce, созданные на основе Salesforce, используют объекты пользователя-агента с управляемыми полномочиями, подобными полномочиям реальных пользователей. При настройке агента тщательно соотнесите доступ с ролью, которую играет агент, ограничив доступ к данным только тем, что требуется для обслуживания конечных пользователей. Не менее важно, что агенты могут быть настроены посредством общедоступных и личных действий. Для личных действий проверьте и проверьте подлинность конечных пользователей, соотнеся их с контекстом агента. Это позволяет Агенту изображать и действовать в рамках элементов управления доступом конечного пользователя, поддерживая безопасность и Trust.

Список шаблонов и антишаблонов ниже отображает правильную (и плохую) архитектуру проверки подлинности в организации Salesforce. Используйте их для проверки дизайна перед созданием или определения возможностей для дальнейших улучшений.

Чтобы узнать больше об инструментах проверки подлинности, доступных в Salesforce, см. Инструменты, связанные с безопасностью.

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

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

Для создания безопасных схем авторизации для Salesforce:

• Следуйте принципу наименьших привилегий. Придерживайтесь принципа наименьших привилегий (PoLP), назначив пользователям только необходимые полномочия для их задач. Чтобы следовать этому принципу, создайте детальные и модульные наборы полномочий. Это позволяет использовать сложные средства управления доступом посредством групп наборов полномочий, обеспечивая точное управление полномочиями, включая возможность игнорирования, установления дат истечения срока действия и прочее. Соотнесите функциональные единицы системы с бизнес-возможностями для определения подробных полномочий и эффективных групп наборов полномочий. Помните, что полномочия применяются к доступу к метаданным в Salesforce. Дополнительные сведения о настройке PoLP для доступа к данным Salesforce см. в разделе «Общий доступ и доступность».
• Представляйте доступ пользователей с точки зрения персон, а не отдельных лиц. Продумывание авторизации (или безопасности в целом) с точки зрения отдельных пользователей не настроит вашу систему на масштабирование и развитие. Вместо этого создайте образы, представляющие группы пользователей, и управляйте ими. Безопасные решения Salesforce используют отдельных лиц для проверки подлинности и лиц для авторизации. Определяя конфигурации безопасности для разных персон, вы получаете детальный контроль над доступом и привилегиями в модели безопасности, что минимизирует необходимость рефакторинга в долгосрочной перспективе. Добавьте персоны безопасности, определенные в стандарты и документацию.
• Управлять доступом пользователей к метаданным посредством наборов полномочий и групп наборов полномочий. Наборы полномочий и группы наборов полномочий определяют доступ пользователей к метаданным и их действия с этими метаданными. Дополнительные сведения о метаданных Salesforce см. в разделе «Метаданные и данные». Настройте назначения приложений, активации лицензии на компонент, доступ управляемого пакета, полномочия системы, доступ CRUD и доступ на уровне поля посредством наборов полномочий и групп наборов полномочий. Добавьте этот доступ в стандарты проектирования и документацию.
• Используйте единые стандартные параметры (OWD) и общий доступ для управления доступом к данным пользователей. Данные и метаданные являются отдельными объектами Salesforce, требующими отдельного контроля доступа для каждого объекта. Используйте OWD и встроенные инструменты общего доступа для настройки доступа к данным Salesforce (отдельные записи, файлы и документы). Дополнительные сведения см. в разделе Безопасность данных.
• Используйте области OAuth для управления доступом для связанных приложений. При настройке связанного приложения определите область или полномочия доступа пользователей приложения к ресурсам Salesforce. Дополнительные сведения об управлении маркерами OAuth см. в разделе Управление сеансами.
• Создание одного пользователя Salesforce для каждой интеграции. Чтобы придерживаться принципа наименьших прав, создайте уникального пользователя интеграции Salesforce для каждой интеграции. Это позволяет назначать определенный доступ к данным, улучшая контроль над операциями, обеспечивая отслеживаемость транзакций и минимизируя влияние потенциальных нарушений безопасности.
• Внедрите уникальные организации посредством PoLP для всех пользователей Agent. Каждый пользователь Agentforce Agent должен быть уникальным и не должен повторно использоваться в нескольких агентах. Полномочия для этих организаций должны строго соответствовать принципу наименьших прав. Помните, что действия, выполняемые пользователем-агентом, могут работать в повышенном контексте безопасности в Salesforce или против внешних систем, не соблюдающих управление доступом Salesforce. Это может привести к тому, что действия откроют или откроют пользователям конфиденциальную информацию.
• Уменьшите использование профилей и перенесите управление доступом из профилей. Профили предоставляют возможность ограничения доступа к диапазонам IP-адресов входа, часам входа и функциям, характерным для устаревшего пользовательского интерфейса Salesforce Classic (в частности, стандартные типы записей и назначения макетов страниц). Любые другие функции, доступные в профилях, должны быть перенесены на эквивалентные функции в наборах полномочий и группах наборов полномочий. Функции в ваших профилях, привязанные к функциям пользовательского интерфейса Salesforce Classic, должны быть устранены.

Список шаблонов и антишаблонов ниже отображает правильные (и плохие) практики авторизации в организации Salesforce. Используйте их для проверки дизайна перед созданием или определения возможностей для дальнейших улучшений.

Дополнительные сведения об инструментах авторизации, доступных в Salesforce, см. в разделе «Инструменты, связанные с безопасностью».

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

✨ Ознакомьтесь с дополнительными схемами организационной безопасности в Проводнике по шаблонам и антипаттернам.

Сеанс — это последовательность запросов и ответов, связанных с пользователем за определенный период времени. Сеанс запускается при успешной авторизации пользователя в системе Salesforce. Безопасность сеанса — это практика настройки системы для предотвращения несанкционированного доступа и взлома данных посредством предотвращения помех или перехвата сеанса.

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

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

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

Протокол HTTPS упрощает связь между клиентом и Salesforce Platform. Клиенты могут включать обозреватели, мобильные приложения, локальные приложения и т. д. HTTPS является протоколом без гражданства, то есть каждое сообщение является дискретным и не связано с предыдущими или будущими сообщениями.

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

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

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

Для создания безопасного управления сеансами для Salesforce:

• Понимание классификации типов сеансов системой Salesforce. Определите и соотнесите утвержденные типы сеансов с персонами пользователей безопасности и запишите их в документацию.
• Управлять способом возникновения сеансов и направлением трафика сеансов. После определения типов сеансов, разрешенных разным пользователям, настройте элементы управления для блокировки сеансов, исходящих из неутвержденных источников или контекстов. Salesforce предоставляет несколько способов управления происхождением сеансов и трафиком, включая:
  • Встроенная защита сеанса. Salesforce автоматически включает единые средства защиты от вредоносных действий на основе сеанса, включительно с межсайтовым скриптингом, подделкой межсайтовых запросов, просмотром содержимого, кликджекингом и прочим. Эти средства защиты не должны быть отключены; некоторые не могут быть отключены.
  • Домены и диапазоны IP-адресов. Во всех организациях Salesforce включен «Мой домен» по умолчанию, что создает корпоративный субдомен для доступа Salesforce. Имя, связанное с организацией, можно настроить или изменить посредством «Моего домена». Кроме того, Salesforce поддерживает дополнительные конфигурации доменов для сайтов Experience Cloud и других страниц приложений. Примечание: Если пользователям нужен доступ к Salesforce из-за корпоративного брандмауэра, добавьте необходимые домены в списки разрешенных брандмауэров. Вы можете настроить диапазоны IP-адресов и диапазоны надежных IP-адресов для управления входящими запросами на вход и сеанс в Salesforce.
  • Часы входа. Если определенные персоны пользователей установили рабочие часы, вы можете ограничить их доступ к Salesforce вне заданных часов входа.
• Управлять действиями, требующими дополнительной безопасности сеанса. По умолчанию сеансы могут иметь два вида уровней безопасности: стандартный и высоконадежный. Используйте эти уровни безопасности для управления способами выполнения пользователями действий (например, доступ к отчетам и панелям мониторинга или управление конфигурациями безопасности в организации Salesforce). Политики безопасности сеанса могут требовать от пользователей создания высоконадежных сеансов для выполнения операций или блокировки выполнения любых конфиденциальных операций.
• Управлять действиями, требующими дополнительных полномочий на основе сеанса. Salesforce поддерживает активации сеансовых полномочий, чтобы временно разрешить пользователям повышенную авторизацию или доступ к полномочиям во время определенного сеанса. Полномочия на основе сеанса можно активировать и деактивировать посредством Flow или Salesforce API.
• Управление неактивными сеансами пользователей посредством истечения срока действия. Завершение неактивных сеансов является ключевым элементом управления безопасностью сеанса. Это помогает защитить вашу систему, если, например, пользователь оставляет сеанс Salesforce открытым во вкладке обозревателя, но активно работает в другом приложении, или если мобильное устройство пользователя вошло в Salesforce, но без присмотра. Время ожидания неактивности сеанса Salesforce по умолчанию составляет два часа. Вы можете увеличить или уменьшить уровни времени ожидания неактивности сеанса, но увеличение времени ожидания должно быть выполнено только с убедительным и документированным обоснованием.
• Управление сеансами связанного приложения посредством конфигурации маркера. При настройке связанного приложения определите область или уровень авторизации, которая будет предоставлена пользователям, входящим в Salesforce посредством связанного приложения. Эта область внедряется на уровне сеанса посредством маркеров OAuth, выдаваемых после успешной проверки подлинности пользователя связанного приложения. Вы можете управлять продолжительностью действия маркера посредством политик обновления маркера. При необходимости администраторы организации могут вручную отзывать маркеры для каждого пользователя и организации.

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

Дополнительные сведения об инструментах управления сеансами, доступных в Salesforce, см. в разделе «Инструменты, связанные с безопасностью».

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

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

Для обеспечения доступа к устройству для Salesforce:

• Используйте решения мобильного приложения, предоставленные Salesforce. Пользователи мобильных устройств, которым нужен доступ к Salesforce, могут использовать официальные приложения Salesforce, доступные для iOS и Android. Если бизнес-потребности требуют настраиваемого мобильного решения, используйте Salesforce Mobile SDK, предоставляющий методы безопасной проверки подлинности и авторизации.
• Определите использование мобильного устройства в управлении сеансами. Уровни безопасности сеанса, время ожидания сеанса и другие элементы управления контекстом сеанса должны учитывать предполагаемый доступ пользователей на мобильных устройствах. Определите, какие устройства должны иметь доступ к Salesforce и какие типы пользователей должны иметь доступ к мобильным сеансам. Добавьте стандарты мобильного доступа в документацию о лицах безопасности. Дополнительные сведения по этой теме см. в разделе Управление сеансами.
• Дополните безопасность устройства технологией управления мобильными устройствами (MDM). Приложения Salesforce для iOS и Android совместимы со многими популярными пакетами MDM. Вы можете настроить дополнительные элементы управления доступом для приложения Salesforce на устройствах пользователя посредством предпочтительного решения MDM.
• Дополните безопасность приложения технологией управления мобильными приложениями (MAM). Технология MAM поддерживает управление на уровне приложения на мобильных устройствах. Salesforce предлагает платное дополнение MAM для мобильных приложений Salesforce.

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

Чтобы узнать больше об инструментах управления устройствами, доступных в Salesforce, см. Инструменты, связанные с безопасностью.

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

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

Для создания эффективной стратегии обнаружения угроз и реагирования для решений Salesforce:

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

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

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

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

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

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

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

✨ Ознакомьтесь с дополнительными схемами безопасности сеанса в Проводнике по шаблонам и антипаттернам.

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

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

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

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

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

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

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

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

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

Для настройки эффективного общего доступа и доступности в Salesforce:

• Создание доступа вокруг значимых функций задания. Создайте матрицу безопасности, которая соотносит лица пользователя с бизнес-функциями, которые они должны выполнять. Используйте этот шаблон в качестве основы для создания общего доступа и доступности. Дополнительные сведения об определении значимых бизнес-функций см. в разделе «Функциональные единицы».
• Выберите самый простой путь к применению принципа наименьших привилегий. Применяя принцип наименьших прав при создании схем общего доступа и доступности, сделайте это самым простым способом. Избегайте чрезмерно разработанных ограничений данных и схем общего доступа, которые могут привести к проблемам обслуживания, масштабируемости и адаптируемости системы. Вместо этого воспользуйтесь гибким многоуровневым общим доступом к данным в Salesforce для настройки точных правил доступа пользователей на уровне данных.
• Задайте внутренним единым стандартным параметрам (OWD) значение «Общедоступный: только для чтения», если ваше предприятие не обрабатывает конфиденциальные данные — используйте «Личный». OWD управляют уровнем «наименьших» привилегий пользователей на уровне данных. Вы не можете ограничивать доступ ниже уровня OWD. Хотя частные ОВД могут казаться идеальными в каждом случае использования, пользователи в компании часто могут непреднамеренно реплицировать более мягкий ОВД посредством сложных схем общего доступа. Кроме того, личные OWD могут привести к созданию повторов данных. Вычисления общего доступа (и пересчеты) могут занять значительное время, в зависимости от объема данных и перекоса «родительский-дочерний» или «ответственность», что усугубляется частными OWD. Важно отметить, что OWD не управляют полномочиями CRUD и доступностью поля. Выберите OWD рядового, только если это оправдано бизнес-требованиями. Чаще всего такие обоснования будут связаны с соответствием.
• Задайте внешним единым стандартным параметрам (OWD) значение «Личный», если только у вас нет веских бизнес-причин для предоставления большего доступа. Внешние OWD применяются к пользователям, имеющим доступ к данным Salesforce из сайтов Experience Cloud, порталов и т. д. Это позволяет настроить отдельные базовые показатели OWD для внутренних и внешних пользователей, чтобы разрешить разные типы привилегий «наименьший». Всегда устанавливайте OWD для внешних пользователей на «Личный» — исключения для более открытого уровня должны быть четко обоснованы бизнес-требованиями.

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

Чтобы узнать больше об инструментах общего доступа и доступности в Salesforce, см. Инструменты, связанные с безопасностью.

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

Для создания правильных способов использования шифрования в решениях Salesforce:

• Всегда адекватно шифровать данные в пути. Salesforce использует безопасность транспортного уровня (TLS) для всех сеансов, проходящих в поддерживаемом Salesforce обозревателе, и требует, чтобы исходящие вызовы посредством HTTPS соответствовали определенным стандартам безопасности. API платформы также используют HTTPS по умолчанию. Кроме того, данные, отправленные между сайтом или порталом Salesforce Experience Cloud и связанной с ним организацией Salesforce, шифруются в пути по умолчанию. Если вы используете встроенные службы эл. почты Salesforce, существуют стандартные уровни безопасности транспортного уровня (TLS), используемые Salesforce для отправки и попытки доставки эл. почты. Вы должны как минимум обеспечить параметры организации не ниже стандартных параметров, если у вас нет четкого бизнес-обоснования. На основе классификации и конфиденциальности данных рекомендуем использовать подключение к Salesforce посредством AWS Direct Connect или Salesforce Private Connect. Это гарантирует, что ваши данные не пересекут общедоступный интернет, а будут безопасно поступать через частное сетевое подключение для доступа пользователей и интеграций.
• Если это необходимо компании, шифруйте данные в дежурном режиме. Salesforce предлагает разные способы шифрования данных в дежурном режиме.
  • Hyperforce. Данные шифруются в дежурном режиме в организациях, использующих Hyperforce. Управление шифрованием для вашей организации выполняется системой Salesforce. Невозможно создать (или уничтожить) собственные ключи шифрования.
  • Salesforce Shield. Salesforce Shield позволяет шифровать данные в дежурном режиме в организации Salesforce на дополнительных уровнях, включая уровни приложения и базы данных. С помощью Shield у вас есть полные возможности управления ключами шифрования клиента, включительно с надежными параметрами «Свой ключ» (BYOK). Можно также зашифровать неструктурированные данные (включая файлы, вложения, поисковые индексы и события). Экземпляры на основе Hyperforce предлагают возможность использования внешнего менеджера ключей, что позволяет использовать собственный AWS KMS. С помощью этой возможности вы сохраняете полный контроль над ключами шифрования в KMS, используемыми для шифрования и расшифровки данных, хранимых в Salesforce, укрепляя безопасность и согласуя с требованиями соответствия организации.

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

Дополнительные сведения об инструментах шифрования, доступных в Salesforce, см. в разделе «Инструменты, связанные с безопасностью».

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

✨ Ознакомьтесь с дополнительными схемами безопасности данных в Проводнике по шаблонам и антипаттернам.

Помогите нам поддерживать актуальность Salesforce «Хорошо архитектура». Пройдите опрос, чтобы предоставить отзыв об этом содержимом и сообщить, что вы хотите видеть дальше.