Управление удостоверениями и доступом - схемы
Узнайте больше о Well-Architected Trust → Управление удостоверениями и доступом
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Архитектура | ✅ Средства управления доступом проверяют подлинность в каждом запросе, независимо от расположения сети или устройства |
| Платформа | Архитектура | ✅ Средства безопасности на основе удостоверений заменяют предположения Trust на основе сети |
| Платформа | Организация | ✅ Решения о доступе учитывают, кто запрашивает доступ (проверка подлинности), что он уполномочен делать (авторизация) и контекст (устройство, расположение) |
| Платформа | Документация | ✅ Архитектура безопасности документирует удостоверение в качестве первичной границы Trust, а не периметра сети |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Архитектура | ⚠️ Пользователи корпоративной сети или VPN считаются надежными и получают более широкий доступ только на основе положения в сети |
| Платформа | Архитектура | ⚠️ Средства управления доступом зависят от периметра сети, а не от проверки подлинности |
| Платформа | Организация | ⚠️ Решения доступа не учитывают контекстные сигналы (устройство, расположение, время, схемы поведения) |
| Платформа | Документация | ⚠️ Архитектура безопасности рассматривает расположение сети как основную границу Trust |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Организация | ✅ Решения используют все четыре уровня доступа Salesforce: Организация (лицензии, функции), объект (CRUD), поле (FLS), запись (общий доступ) |
| Платформа | Организация | ✅ Модель доступа разработана сверху вниз (организация → объект → поле → запись) и проверена снизу вверх |
| Платформа | Организация | ✅ Единым стандартным параметрам (OWD) задано значение «Личный» для объектов, содержащих конфиденциальные данные |
| Платформа | Организация | ✅ OWD, заданные на значение «Общедоступный: только для чтения», ограничены справочными объектами (продуктами, прайс-листами), где широкая доступность поддерживает бизнес без риска |
| Платформа | Организация | ✅ Ограничения на уровне организации (лицензии, диапазоны IP-адресов, часы входа, полномочия функции) определяют базовые возможности для групп пользователей |
| Платформа | Организация | ✅ Полномочия объекта (посредством профилей и наборов полномочий) управляют доступом к созданию, чтению, редактированию и удалению каждого объекта для пользовательских сегментов |
| Платформа | Организация | ✅ Безопасность поля защищает конфиденциальные поля даже при предоставлении доступа к объекту |
| Платформа | Организация | ✅ Общий доступ на уровне записи использует иерархию ролей и правила общего доступа на основе документированных бизнес-требований |
| Платформа | Организация | ✅ Доступ расширяется намеренно от ограничительного базиса, а не ограничивается после разрешительных стандартных параметров |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Организация | ⚠️ Модель доступа не использует все четыре уровня (организация, объект, поле, запись) |
| Платформа | Организация | ⚠️ БД установлены на «Общедоступный: для чтения и записи» для удобства во время разработки без планов ограничения |
| Платформа | Организация | ⚠️ Чрезмерно мягкие ОВД, установленные раньше, становится все труднее ограничивать по мере роста объема данных и кристаллизации бизнес-процессов |
| Платформа | Организация | ⚠️ Безопасность поля не настроена, зависит только от управления доступом на уровне объекта или записи |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Организация | ✅ Многофакторная проверка подлинности (MFA) внедрена для всех пользователей, имеющих доступ к производственным средам (обязательно для доступа к пользовательскому интерфейсу) |
| Платформа | Организация | ✅ MFA распространяется на привилегированные операции, включительно с экспортом пакетных данных, изменениями полномочий и административной конфигурацией |
| Платформа | Организация | ✅ Единая регистрация (SSO) использует протоколы SAML 2.0 или OpenID Connect |
| Платформа | Организация | ✅ Время ожидания сеанса настроено соответствующим образом: 2 часа для стандартных пользователей, 15-30 минут для администраторов и пользователей, имеющих доступ к ограниченным данным |
| Платформа | Организация | ✅ Ограничения IP-адресов применяются для административных профилей и пользователей интеграции |
| Платформа | Организация | ✅ Часы входа ограничивают сервисные организации ожидаемыми операционными окнами |
| Платформа | Организация | ✅ Собственная активация устройства проверяет входы с нераспознанных устройств; ограничения MFA и IP-адресов добавляют защиту для организаций с высоким уровнем прав |
| Платформа | Организация | ✅ Если единый вход включен, утвержденные пользователи-администраторы имеют прямой доступ к входу (процедуры битья стекла) |
| Платформа | Организация | ✅ Взаимосвязь между пользователями и объектами, входящими в Salesforce, составляет 1:1 (нет общедоступных организаций пользователей) |
| Платформа | Организация | ✅ Контроль доступа API предотвращает авторизацию пользователей посредством несанкционированных связанных приложений |
| Платформа | Именованные регистрационные данные | ✅ Именованные регистрационные данные и внешние регистрационные данные управляют проверкой подлинности централизованно посредством возможностей ротации |
| Платформа | Именованные регистрационные данные | ✅ Именованные регистрационные данные извлекают сведения о проверке подлинности из кода, включая обновления регистрационных данных без изменений кода |
| Платформа | Именованные регистрационные данные | ✅ Регистрационные данные никогда не встроены в код, файлы конфигурации или управление версиями |
| Platform | Apex | ✅ Методы, выполняющие проверку подлинности, используют именованные регистрационные данные для обработки потоков имени пользователя/пароля |
| Platform | Apex | ✅ Имена пользователей или пароли не отображаются в коде в читаемых форматах (без жестко запрограммированных значений или строк) |
| Платформа | Aura | ✅ Методы, выполняющие проверку подлинности, используют именованные регистрационные данные для обработки потоков имени пользователя/пароля |
| Платформа | Aura | ✅ Имена пользователей или пароли не отображаются в коде в читаемых форматах |
| Platform | Веб-компоненты Lightning (LWC) | ✅ Методы, выполняющие проверку подлинности, используют именованные регистрационные данные |
| Platform | Веб-компоненты Lightning (LWC) | ✅ Имена пользователей или пароли не отображаются в коде |
| Интеграция | API | ✅ Процесс носителя OAuth 2.0 JWT используется для интеграций между серверами в надежных средах (предпочтительно для производственных интеграций) |
| Интеграция | API | ✅ Процесс веб-сервера OAuth 2.0 используется для интеграций между серверами, требующих пользовательского контекста |
| Интеграция | API | ✅ Процесс устройства OAuth 2.0 используется для устройств без заголовка; CLI и CI/CD инструмент используют поток веб-сервера (sf org login web) или поток носителя JWT (sf org login jwt) — поток устройства заблокирован для связанного приложения Salesforce CLI по умолчанию с 28 августа 2025 года |
| Интеграция | API | ✅ Процесс OAuth имени пользователя и пароля не используется; существующие интеграции, которые его используют, мигрируют в поток регистрационных данных носителя JWT или клиента |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Организация | ⚠️ MFA не применяется для доступа к производственной среде |
| Платформа | Организация | ⚠️ Конфигурации входа не соответствуют требованиям Salesforce MFA |
| Платформа | Организация | ⚠️ MFA не распространяется на привилегированные операции (пакетный экспорт, изменение полномочий, административная конфигурация) |
| Платформа | Организация | ⚠️ Время ожидания сеанса не настроено или чрезмерно непозволительно (>24 часа) |
| Платформа | Организация | ⚠️ Политики сеансов не проводят различия между стандартными пользователями и администраторами/пользователями, имеющими доступ к ограниченным данным |
| Платформа | Организация | ⚠️ Ограничения IP-адресов не применяются для административных профилей и пользователей интеграции |
| Платформа | Организация | ⚠️ Сервисные организации не имеют часов входа, ограниченных ожидаемыми операционными окнами |
| Платформа | Организация | ⚠️ Высокопривилегированные организации не зависят ни от чего, кроме активации устройства — не добавлены ограничения MFA или IP-адресов |
| Платформа | Организация | ⚠️ Если включена единая регистрация, ни один авторизованный пользователь-администратор не имеет прямого доступа для входа (нет процедур битья стекла) |
| Платформа | Организация | ⚠️ Взаимосвязь между пользователями и объектами не 1:1 (существуют общедоступные организации пользователей) |
| Платформа | Организация | ⚠️ Управление доступом к API не включено |
| Платформа | Именованные регистрационные данные | ⚠️ Регистрационные данные встроены напрямую в код, файлы конфигурации или управление версиями |
| Platform | Apex | ⚠️ Имена пользователей и пароли отображаются в коде в читаемых форматах |
| Platform | Apex | ⚠️ Проверка подлинности обрабатывается ситуативно без последовательного внедрения |
| Платформа | Aura | ⚠️ Проверка подлинности обрабатывается ситуативно без именованных регистрационных данных |
| Платформа | Aura | ⚠️ Имена пользователей и пароли отображаются в коде |
| Platform | Веб-компоненты Lightning (LWC) | ⚠️ Проверка подлинности обрабатывается ситуативно без именованных регистрационных данных |
| Platform | Веб-компоненты Lightning (LWC) | ⚠️ Имена пользователей и пароли отображаются в коде |
| Платформа | Бизнес | ⚠️ Инициализация и отмена предоставления пользователям соглашений об уровне обслуживания и требований отсутствуют |
| Интеграция | API | ⚠️ Процесс OAuth имени пользователя и пароля используется при наличии более безопасных потоков OAuth |
| Интеграция | API | ⚠️ Области OAuth слишком нестрогие (полный доступ, если ограниченной области достаточно) |
| Интеграция | API | ⚠️ Регистрационные данные клиента (код клиента, секрет клиента) хранятся небезопасно в файлах кода или конфигурации |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Организация | ✅ Глубина иерархии ролей составляет не более 5-7 уровней (избегая накладных расходов и сложности устранения неполадок) |
| Платформа | Организация | ✅ Наборы полномочий и группы наборов полномочий предоставляют гибкий дополнительный доступ без распространения профиля |
| Платформа | Организация | ✅ Наборы полномочий предоставляют доступ для определенных рабочих функций, приложений или временных повышенных привилегий |
| Платформа | Организация | ✅ Группы наборов полномочий сочетают связанные наборы полномочий с возможностями игнорирования для исключений |
| Платформа | Организация | ✅ Все функциональные доступы предоставляются посредством наборов полномочий и групп наборов полномочий (не профилей), обеспечивая гибкость по мере изменения ролей заданий |
| Платформа | Организация | ✅ Политики безопасности транзакций расширяют авторизацию посредством контекстуальной оценки в реальном времени |
| Платформа | Организация | ✅ Политики безопасности транзакций обнаруживают и блокируют аномальное поведение (пакетная загрузка данных, превышающая схемы, вход из непредвиденных географий, изменение полномочий за окнами изменений) |
| Платформа | Организация | ✅ Ограничения IP-адресов настроены для высококонфиденциальных операций или доступа к данным |
| Платформа | Организация | ✅ Уникальный пользователь интеграции только API настроен для каждой интеграции |
| Platform | Apex | ✅ Все коды, получающие доступ к данным, внедряют CRUD и FLS посредством методов WITH USER_MODE, WITH SYSTEM_MODE или Security.stripInaccessible() |
| Platform | Apex | ✅ Запросы SOQL используют с помощью USER_MODE или С ключевыми словами SYSTEM_MODE, явно исходя из бизнес-требований |
| Platform | Apex | ✅ Операции DML используют Security.stripInaccessible() для принудительного доступа перед операциями insert/update/upsert |
| Platform | Apex | ✅ Операторы DML базы данных объявляют пользовательский или системный режим явно для операций над данными |
| Platform | Apex | ✅ Операции базы данных используют методы stripInaccessible() для фильтрации запросов и результатов подзапросов |
| Platform | Apex | ✅ Ключевые слова общего доступа (с общим доступом, без общего доступа, унаследованный общий доступ) используются надлежащим образом, исходя из требований безопасности бизнеса |
| Платформа | Стандарты проектирования | ✅ Сценарии использования для предоставления повышенных привилегий (Изменение всех данных, Просмотр всех данных) четко документированы с бизнес-обоснованием |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Организация | ⚠️ Иерархия ролей глубже 5-7 уровней, что создает производительность над головой при расчетах общего доступа и устранении неполадок сложности |
| Платформа | Организация | ⚠️ Иерархия ролей предоставляет широкий доступ без бизнес-обоснования |
| Платформа | Организация | ⚠️ Профили клонируются неоднократно для незначительных вариантов полномочий, создавая десятки профилей с нечеткими различиями |
| Платформа | Организация | ⚠️ Профили содержат элементы управления доступом к метаданным (должны использовать наборы полномочий) |
| Платформа | Организация | ⚠️ Политики безопасности транзакций не применяются для обнаружения аномалии поведения |
| Платформа | Организация | ⚠️ Ограничения IP-адресов не настроены для высококонфиденциальных операций или доступа к данным |
| Платформа | Организация | ⚠️ Пользователи только API не настроены или общедоступны в нескольких интеграциях |
| Платформа | Организация | ⚠️ Полномочия «Просмотр всех данных» или «Изменение всех данных» предоставляются без документального подтверждения |
| Platform | Apex | ⚠️ Запросы SOQL/SOSL и операции DML выполняются в стандартном системном режиме без явных проверок доступа |
| Platform | Apex | ⚠️ Применение CRUD и FLS несогласовано или отсутствует |
| Platform | Apex | ⚠️ SOQL зависит от параметра SECURITY_ENFORCED, который был удален и теперь приводит к ошибке компиляции (заменить на WITH USER_MODE) |
| Platform | Apex | ⚠️ Ключевые слова общего доступа используются непоследовательно или не используются вовсе |
| Платформа | Стандарты проектирования | ⚠️ Сценарии использования для предоставления повышенных полномочий четко не задокументированы |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Platform | Data 360 | ✅ RBAC (роли, профили, наборы полномочий) управляет доступом к платформе (кто может использовать Data 360), ABAC управляет доступом к данным (какие данные они видят на основе атрибутов) |
| Platform | Data 360 | ✅ Агенты на основе искусственного интеллекта выполняют в контексте запрашивающего пользователя (от имени), поэтому запросы, созданные агентом, ограничены доступом этого пользователя, а не выполняются с доступом на системном уровне |
| Платформа | Документация | ✅ Таксономия классификации данных документирована с определениями атрибутов, правилами правоприменения и бизнес-обоснованием |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Platform | Data 360 | ⚠️ Доступ, который должен следовать классификации данных, принудительно предоставляется посредством иерархии ролей и общего доступа, которые не могут его выразить, вместо того, чтобы обращаться к управлению доступом на основе атрибутов |
| Platform | Data 360 | ⚠️ Шунтирование FLS: пользователи без доступа уровня поля извлекают данные посредством запросов API или SOQL, которые не внедряют FLS |
| Platform | Data 360 | ⚠️ Агенты на основе искусственного интеллекта запрашивают данные без выполнения в контексте запрашивающего пользователя; созданные агентом запросы обходят средства управления доступом на уровне объекта, поля и записи |
| Platform | Data 360 | ⚠️ Контекст выполнения агента не содержит атрибутов пользователя от имени; агенты работают с доступом на уровне системы |
| Платформа | Документация | ⚠️ Таксономия классификации данных не задокументирована; определения атрибутов различаются рабочей группой, создающей несогласованное правоприменение |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Организация | ✅ Организации с критическим влиянием (системные администраторы, пользователи интеграции, организации автоматизированных процессов) определяются и отслеживаются в инвентаризации активов |
| Платформа | Организация | ✅ Организации критического влияния представляют собой ценные цели из-за повышенных привилегий, предоставляющих широкий доступ к платформе |
| Платформа | Организация | ✅ Аппаратные ключи безопасности или приложения средства проверки подлинности обязательны для MFA (не SMS-сообщений, которые уязвимы для замены SIM-сообщений) |
| Платформа | Организация | ✅ Диапазоны IP-адресов входа ограничены известными административными расположениями |
| Платформа | Организация | ✅ Включены предупреждения о входе и уведомления об изменении полномочий |
| Платформа | Организация | ✅ Ежеквартальные проверки доступа проводятся с документированным подтверждением |
| Платформа | Организация | ✅ Существуют процедуры битого стекла для экстренного доступа с аудитом после использования |
| Интеграция | Сервисные организации | ✅ Потоки OAuth используются для организаций интеграции и обслуживания (никогда не имя пользователя и пароль) |
| Интеграция | Сервисные организации | ✅ Ограничения IP-адресов применяются для пользователей интеграции |
| Интеграция | Сервисные организации | ✅ Реализованы расписания ротации регистрационных данных (ежеквартально или по политикам) |
| Интеграция | Сервисные организации | ✅ Отслеживание аномальных схем использования API посредством мониторинга событий |
| Интеграция | Сервисные организации | ✅ Каждая интеграция имеет специальную учетную запись службы с минимальными обязательными полномочиями (не общедоступный «пользователь интеграции» с широким доступом) |
| Интеграция | Сервисные организации | ✅ Сервисные организации применяют наименее строгие привилегии, поскольку они работают без присмотра |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Организация | ⚠️ Учетные записи о критически важном влиянии (администрирование, интеграция, автоматизация) не определяются, не отслеживаются и не инвентаризируются |
| Платформа | Организация | ⚠️ Системные администраторы используют MFA на основе SMS вместо аппаратных ключей безопасности или приложений средства проверки подлинности |
| Платформа | Организация | ⚠️ Организации с критическим влиянием не имеют ограничений по времени входа или IP-адресам |
| Платформа | Организация | ⚠️ Не настроены предупреждения для входа или изменения полномочий в привилегированных организациях |
| Платформа | Организация | ⚠️ Доступ к организациям с критическим влиянием никогда не проверяется или проверяется нерегулярно (не ежеквартально) |
| Платформа | Организация | ⚠️ Для аварийного доступа не существует процедур стеклобоя |
| Интеграция | Сервисные организации | ⚠️ Одна организация «Пользователь API» общедоступна в нескольких интеграциях с полномочием «Изменение всех данных» |
| Интеграция | Сервисные организации | ⚠️ Сервисные организации используют проверку подлинности имени пользователя и пароля при наличии OAuth |
| Интеграция | Сервисные организации | ⚠️ Регистрационные данные учетной записи службы используют статические пароли без изменений годами (без ротации) |
| Интеграция | Сервисные организации | ⚠️ Сервисные организации имеют чрезмерные привилегии, выходящие за рамки требуемого интеграции |
| Интеграция | Сервисные организации | ⚠️ Не отслеживаются аномальные схемы использования API для организаций обслуживания |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Процесс | ✅ Жизненный цикл удостоверения содержит: Инициализация (создание с базовым доступом), Корректировка доступа (предоставление/отмена по мере изменения ролей), Периодическая повторная сертификация (ежеквартальная проверка), Отмена инициализации (немедленный отзыв) |
| Платформа | Организация | ✅ SCIM (Система для междоменного управления удостоверениями) внедрена для автоматической инициализации от поставщиков удостоверений |
| Платформа | Процесс | ✅ Инициализация создает организации с базовым доступом, соответствующим функции задания, запущенной событиями системы кадров |
| Платформа | Процесс | ✅ Поправка доступа предоставляет дополнительные полномочия по мере расширения ролей и отзывает полномочия при изменении ролей |
| Платформа | Процесс | ✅ Периодическая переаттестация проводится ежеквартально, когда менеджеры рассматривают и проверяют доступ для своих рабочих групп |
| Платформа | Процесс | ✅ Отмена инициализации немедленно отменяет доступ, когда занятость заканчивается или роль больше не требует Salesforce |
| Платформа | Организация | ✅ Автоматическое определение определяет пользователей, которые не вошли в систему в течение 90 дней, и инициирует бизнес-процессы проверки доступа |
| Платформа | Организация | ✅ Своевременная инициализация (JIT) создает пользователей автоматически из SSO, при необходимости |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Организация | ⚠️ Инициализация SCIM не внедрена, несмотря на наличие интеграции поставщика удостоверений |
| Платформа | Процесс | ⚠️ Новые пользователи создаются вручную без стандартных процедур адаптации |
| Платформа | Процесс | ⚠️ Первичный доступ пользователя несогласован или основан на копировании существующих пользователей |
| Платформа | Процесс | ⚠️ Задержка или незавершенность изменений доступа для изменения или передачи ролей |
| Платформа | Процесс | ⚠️ Автономный режим задерживается; бывшие сотрудники сохраняют доступ после увольнения (не деактивация в тот же день) |
| Платформа | Организация | ⚠️ Автоматизация для инициализации пользователя не существует (только создание пользователя вручную) |
| Платформа | Процесс | ⚠️ Кампании повторной сертификации доступа не проводятся (не проводятся ежеквартальные или годовые проверки) |
| Платформа | Процесс | ⚠️ Неудаленный доступ, определенный во время повторной сертификации, не удаляется |
| Платформа | Процесс | ⚠️ Повторная сертификация доступа нестрога для привилегированных организаций, межорганизационного доступа, внешних пользователей |
| Платформа | Организация | ⚠️ Неактивные организации (нет входа за 90+ дней) накапливаются без проверки и деактивации |