Как применять Salesforce Health Check

Данная статья является вольным переводом англоязычной статьи - https://www.salesforceben.com/salesforce-health-check/

Проверка работоспособности Salesforce (или «Salesforce Health Check») может означать разные вещи в зависимости от того, кого вы спрашиваете. Администратор может улучшить текущее обслуживание организации; задачи могут включать в себя очистку неиспользуемых полей на часто используемом созданном объекте. Команды управления или комплаенса, вероятно, больше сосредоточатся на аспектах безопасности, например, если диапазоны IP-адресов заблокированы для всех пользователей. Руководитель будет больше всего заинтересован в общих расходах организации и использовании лицензий.

Для целей этой статьи воспользуемся смешанным подходом к изложенным выше соображениям. Цель состоит в том, чтобы получить моментальное понимание того, что происходит в организации; как она используется и насколько она в целом безопасна? Ответы на эти вопросы помогут определить направления, на которые нужно обратить внимание для улучшения общего состояния «Здоровья».

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

Давайте начнем.

Почему важен Health Check?

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

Когда вы в последний раз (если вообще) останавливались, чтобы спросить: «Как дела в организации в целом?»

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

Итак, давайте остановимся и зададим этот простой вопрос: «как дела у организации в целом?»

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

  • Администратором, который много лет руководил одной и той же организацией.

  • Менеджером проекта, пытающимся разобраться в системе Salesforce вашей компании.

  • Консультантом, впервые приходящим в новую организацию.

Документирование вашего Health Check

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

Если у вас еще нет какой-либо организационной документации, я бы посоветовал создать документ Google Doc или MS Word прямо сейчас - неплохо хранить результаты Health Check где-нибудь, чтобы к ним можно было легко получить доступ и поделиться. Во время проверки состояния важно записывать полученные результаты.

Исполнение Health Check

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

Шаг 1. Проверьте контракт Salesforce и использование продукта

Контракт Salesforce

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

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

  • Узнайте, на каком этапе цикла покупки мы находимся.

  • Спросите, какие продукты у нас есть.

  • Проанализируйте, действительно ли используются эти продукты.

Предполагая, что вы находитесь в Lightning Experience, перейдите в верхний правый угол и щелкните значок шестеренки. Вы должны увидеть ссылку под названием «Your Account» - нажмите на нее, а затем нажмите «View Your Contracts», чтобы увидеть список продуктов, приобретенных этой организацией у Salesforce. Если вы используете классический интерфейс (интерфейс Aloha), перейдите в верхний правый угол и щелкните раскрывающееся меню «App Name» (самая последняя кнопка в правом верхнем углу). Нажмите «Checkout», а затем «Purchased Products».


Здесь добавьте в свою документацию два примечания:

  1. Дата продления.

  2. Список приобретенных продуктов (с указанием их количества и стоимости).

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

Как выглядит эта общая картина для продуктов, приобретенных у Salesforce? Есть ли продукты, которые вас удивят? Я видел надстройки для хранения данных, которые больше не нужны организации; дополнительные вызовы API, которые были результатом плохой практики разработки в организации; сотни лицензий на платформы, оставшиеся от предыдущего проекта; и многое другое.

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

Проверить использование

Теперь, когда у нас есть четкое представление о том, какие продукты есть в организации, давайте посмотрим на исходные данные об использовании. Я говорю «сырые», потому что это скажет нам, какие лицензии и функции назначены, не обязательно, используются они или нет. Перейдите в Setup > Company information.


В разделе «User Licenses» представлены различные типы лицензий в организации, а также количество доступных и назначенных лицензий. Из этого раздела вы сможете получить хорошее представление о том, сколько основных лицензий каждого типа (Full Salesforce License, Platform Licenses и т. д.) назначено в контракте Salesforce. Записывайте все интересное, что вы найдете, включая количество «оставшихся лицензий» для любого типа лицензии.

Затем в разделе «Feature Licenses» раздел «User Licenses» разбивается на более мелкие детали. Это дополнительные продукты (если они есть в вашей организации), которые приобретаются в дополнение к обычным лицензиям Salesforce, например, для использования Knowledge, Live Agent и других. Запишите и это; спросите, сколько из этих лицензий назначено по сравнению с тем, что было куплено. Есть ли что-нибудь особенное?

Погрузитесь глубже в использование лицензий (необязательно)

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

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

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

  • В чем причина, по которой они вообще получили лицензию?

  • Было ли это для конкретного проекта, над которым все еще работают?

  • Или это был вариант использования, который больше не действителен? В каком случае их можно удалить из системы?

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

Другая информация об использовании

Пока мы находимся на странице «Company Information» в меню «Setup», давайте также взглянем на другие важные показатели использования.


Справа, примерно на середине страницы, вы должны увидеть «Запросы API за последние 24 часа». В зависимости от типа вашей организации и количества лицензий, которые она содержит, вы должны увидеть количество запросов API по сравнению с максимальным количеством, разрешенным в течение любого 24-часового периода.

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

Наконец, давайте посмотрим на использование данных и файлов. Их также можно найти справа, чуть выше информации об использовании API. Хранилище данных - это количество фактических хранимых записей Salesforce (учетные записи, контакты и т. Д.), а под хранилищем файлов понимается все остальное, прикрепленное к записям Salesforce (вложения из электронных писем, изображения, прикрепленные к обращениям, PDF-файлы, прикрепленные к возможностям и т. д.).

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

Шаг 2 - Проверка безопасности

«Health Check»

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

Ирония заключается в том, что у Salesforce на самом деле есть невероятно полезный инструмент, чтобы помочь в этом… Они называют это «Health Check»!


Перейдите в раздел «Setup > Health Check», и вы должны увидеть базовый балл для своей организации. Ниже настройки безопасности разбиты на высокий, средний и низкий уровень риска. Вы увидите, каким параметрам безопасности соответствует организация, а также области, в которых ваша организация не соответствует требованиям. Вы также увидите текущую ценность организации и ту ценность, которую рекомендует Salesforce.

Безопасность - очень сложная тема. К счастью, нам действительно не нужно точно знать, что означает каждый аспект безопасности. По большей части я бы рекомендовал обновить любую политику, чтобы она соответствовала тому, что Salesforce рекомендует как «Стандартное значение».

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

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

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

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

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

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

Многофакторная аутентификация (MFA)

MFA - лучший способ защитить вашу организацию от доступа неавторизованных пользователей. Он связывает то, что вы знаете (пароль), с другим фактором (например, с вашим адресом электронной почты или текстом). Вы можете найти это здесь: «Setup > Session Settings > Session Security Levels > Multi-Factor Authentication».

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


Сделав еще один шаг, к 1 февраля 2022 года Salesforce потребуется включить еще более безопасную версию MFA. Это требование аутентификации устранит возможность использования текста/электронной почты в качестве второго метода аутентификации. Вместо этого потребуется приложение для проверки подлинности или ключ безопасности. Это приложение аутентификации (загруженное на телефон пользователя Salesforce) выдает шестизначные коды, действительные только в течение 30 секунд. Для получения дополнительных сведений перейдите в раздел «Setup > Multi-Factor Authentication Assistant».

Мой домен

Мой домен делает ваш URL-адрес Salesforce специфичным для вашей организации/компании. Таким образом, вместо login.salesforce.com он становится mycompany.lightning.force.com. Это не только необходимо для использования многих новых функций, но и помогает защитить вашу организацию - неавторизованным пользователям сначала необходимо знать ваш «мой домен», прежде чем даже пытаться получить доступ к вашей организации. Я не буду вдаваться в подробности здесь, но вы найдете информацию в «Setup > My Domain», и, если он еще не включен, я бы порекомендовал это исправить.

Единственное, о чем здесь нужно знать это опция «запретить вход с login.salesforce.com», которую вы можете включить после включения «My Domain» - это по существу блокирует вход на общую страницу входа. Просто убедитесь, что все интеграции в вашей организации настроены так, чтобы справиться с этим (и не указывают на общий логин).

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

Шаг 3 - Проверьте контроль доступа

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

Админы

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

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

Перейдите в раздел «Setup > Profiles > “System Administrator” profile > Assigned Users», чтобы увидеть, каким пользователям в настоящее время назначен профиль администратора. Как выглядит этот список пользователей? Единственные пользователи, которым должен быть назначен этот профиль это пользователи, которые фактически участвуют в управлении самим приложением. Нет причин назначать этот профиль «менеджерам по продажам» или другим лицам, которым требуется большой доступ к данным. Не вдаваясь в подробности, этим пользователям следует предоставить дополнительный доступ через Permision Set.

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

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

Небольшое примечание по этому поводу: при просмотре профиля «System Administrator» назначенные пользователи в программе установки покажут вам всех настоящих администраторов. По-прежнему можно предоставить широкие «административные» разрешения через другой Profile или с помощью Permission Set. По сути, любой Prodile или Permission Set с параметрами «Customize Application» или «Read/View all Data» следует рассматривать как имеющий доступ администратора. Вы можете создать «List View», чтобы выявлять эти дополнительные Profiles/ Permision Sets.

Конфиденциальные разрешения

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

Я бы начал с составления списка из пяти наиболее важных типов данных в вашей организации. С общей точки зрения Contacts могут быть наиболее конфиденциальными, за ними следуют любые объекты, содержащие PII (личную информацию), например Contacts. Или это может быть определенный класс Apex, который является сверхчувствительным, но, опять же, вам необходимо определить, какие типы данных относятся к вашей конкретной компании.

Когда у вас есть этот список, вам необходимо определить, какие профили содержат эти разрешения и, в свою очередь, какие пользователи назначены этим профилям, чтобы определить, каким пользователям был предоставлен доступ. Для этого в профиле выберите «Setup > Profiles». У вас должна быть возможность создать новый список (вид «Create new View» в верхнем левом углу) и отфильтровать его по разрешениям, которые вы сочли важными. Честно говоря, я считаю, что List View в лучшем случае подходят для таких настроек как тип записи или доступ к полю, но это лучший инструмент, который предлагает Salesforce.

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

Шаг 4 - Анализ построения организации

Оптимизатор Salesforce

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

Однако, с учетом сказанного, Salesforce создала очень прочную отправную точку со своим инструментом «Optimizer». Оптимизатор встроен в Salesforce и может помочь выявить проблемные области в вашей сборке. А именно, он помогает идентифицировать Fields, Profiles, Permision Sets и Roles, которые не используются. Он также предлагает способы решения проблемы. У этого инструмента есть ограничения, и он, несомненно, порождает ложные «проблемы», но это отличное начало.

Перейдите в раздел «Setup > Optimizer», чтобы запустить его, а затем проанализируйте результаты.

oAtlas - понимание, документирование и создание отчетов о вашей организации Salesforce

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

oAtlas устраняет многие из вышеперечисленных точек преткновения и более функционален, чем стандартные инструменты:

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

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

  • Погрузитесь глубже в сборку организации - получите подробную «карту» того, как создается организация и как она используется.

  • Документация прямо в вашей организации.

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

Посетите веб-сайт oAtlas, чтобы узнать больше, или напишите по адресу support@cloudstudio.build.

Резюме

Я надеюсь, что это руководство по проведению проверки работоспособности Salesforce помогло вам сделать вашу организацию Salesforce более «здоровой»! Система Salesforce - это большие инвестиции, и обеспечение ее работоспособности - один из лучших способов ее защитить.

2 Вподобання