Última actualización el 5 de octubre de 2021 por Rakesh Gupta

¿Qué le viene a la mente cuando alguien le pregunta? ¿Puede explicar cómo se configura la seguridad en una organización de Salesforce? Si se le pasó por la cabeza el valor predeterminado para toda la organización (OWD), entonces pertenece a un grupo de usuarios experimentados de Salesforce 😊.

Porque, cuando se aprende sobre cómo asegurar una organización de Salesforce, OWD es uno de los primeros conceptos, y uno muy importante en eso, ¡uno aprende a entenderlo! Esto se debe a que OWD dicta la configuración de uso compartido de nivel base de los registros dentro de un objeto. La configuración de OWD garantiza que los usuarios no puedan acceder a los registros, incluso si tienen acceso a un Objeto dentro del cual residen esos registros, sin que se les otorgue acceso específicamente a los registros que no son de su propiedad.

El siguiente diagrama muestra la seguridad básica de los registros en Salesforce. En esto, OWD juega un papel clave:

La única forma de proteger los datos de registro en Salesforce es configurar un OWD restrictivo; todo lo demás, como la jerarquía de roles, la regla de uso compartido, el uso compartido manual, el uso compartido de equipos, la administración de territorios empresariales, se usa para abrir el acceso a los registros que un usuario no posee .

Por ejemplo , Alex Pisani trabaja como arquitecto de seguridad en Universal Containers. Ha recibido un requisito de su director de ventas para configurar el acceso de los usuarios a los registros de clientes potenciales. Requisitos: (1) solo los usuarios que sean propietarios de los registros del cliente potencial; y (2) los usuarios que están más arriba en la jerarquía de funciones pueden acceder a los registros del cliente potencial.

El caso de uso empresarial anterior se puede abordar configurando OWD en Privado y aprovechando la jerarquía de roles.

Sin embargo, al igual que no todos los cinco dedos de sus manos son iguales, los requisitos comerciales varían y, por lo tanto, todos los requisitos no se pueden resolver con una solución única para todos. Por ejemplo, a continuación, echemos un vistazo a un ejemplo diferente:

En Universal Containers, el director de ventas quiere promover una competencia sana entre los equipos de ventas. Como resultado, le pide a Alex, el arquitecto de seguridad, que se asegure de que los representantes de ventas no puedan ver las actividades de los demás, aunque estas actividades (tareas y eventos) estén en la misma cuenta .

¿Se encuentra pensando demasiado en encontrar una solución? Si es así, permítame advertirle previamente: cambiar el OWD de tareas o eventos no es una opción porque afectará a otras unidades comerciales, así como a muchos otros procesos comerciales (objetos personalizados o estándar).

Presentación de la regla de restricción

¡Las reglas de restricción funcionan como un puño de hierro! Ellos le permiten mejorar la seguridad de su organigrama, ya que permite conceder acceso a los usuarios sólo los registros, y actividades relacionadas, que les desea acceder. En otras palabras, le brinda un control muy granular sobre cómo desea desembolsar el acceso a los usuarios.

Cuando usa la regla de restricción, la cantidad de acceso que tiene un usuario a un registro depende de dos factores: (1) el acceso a los registros a través de la configuración de uso compartido más (2) los criterios horneados en el filtro de registro de la regla de restricción. Es lo mismo que un filtro de usuario en los registros de un informe o vista de lista.

Revisemos algunos ejemplos en los que la regla de restricción puede resultar útil:

  1. Muestra solo los contratos que son propiedad del usuario que inició sesión, independientemente de dónde se encuentren en la jerarquía de funciones.
  2. Asegúrese de que solo los usuarios seleccionados tengan acceso a las tareas y eventos en una cuenta determinada, incluso si tienen acceso al registro de la cuenta .
  3. Para los objetos personalizados, incluso si un usuario tiene acceso al registro maestro, evite su acceso a los registros detallados.

¡Sí, muy poderoso de hecho!

Configurar la regla de restricción

Ahora puede crear y administrar reglas de restricción en la configuración, así como mediante el uso de la API de herramientas o la API de metadatos. Comencemos con un caso de uso empresarial.

Brenda David trabaja como administradora de sistemas en Universal Containers (UC). Su equipo ahora está implementando el proceso de admisión de la Asociación. Como resultado, Brenda creó dos objetos con una relación Maestro-Detalle.

  1. Solicitud de asociación (maestro)
  2. Proceso de incorporación (detalle)

Brenda quiere diseñar una solución para los siguientes requisitos:

  1. Aunque todos pueden ver todos los registros de solicitud de asociación y incorporación, se aplican las siguientes excepciones:
    1. Los representantes de ventas solo pueden ver los registros de solicitudes de incorporación que crean .
    2. Sin embargo, los representantes de ventas pueden ver todos los registros de solicitudes de asociación.

Instrucciones paso a paso

El requisito empresarial anterior se puede resolver cambiando el tipo de relación, etc. Sin embargo, las mejores prácticas de Salesforce dictan que diseñamos la solución más óptima para abordar un requisito. Por lo tanto, el requisito anterior requiere el uso de: ¡lo adivinó bien! – ¡la regla de restricción! Como sabe, si alguien tiene acceso a un registro principal, automáticamente obtiene acceso a los registros secundarios siempre que los dos objetos estén conectados a través de una relación maestro-detalle.

Entonces, usemos la regla de restricción para resolver el requisito comercial de Brenda. Siga los pasos a continuación:

  1. Haga clic en Configuración .
  2. En el Administrador de objetos, escriba Procesos de incorporación .
  3. Seleccione Proceso de incorporación , luego navegue hasta Regla de restricción .
  4. Seleccione Regla de restricción y luego haga clic en Nueva regla .
  5. Ingrese el nombre de la regla y haga clic en Siguiente. El nombre completo se completará automáticamente.
  6. Seleccione la casilla de verificación Está activo . En Criterios de usuario : seleccione a qué usuarios se aplica esta regla de restricción:
    1. Campo: Título
    2. Operador: Igual que
    3. Tipo: Cadena
    4. Valor: Representante de ventas
  7. En Criterios de registro : seleccione qué registros pueden ver los usuarios especificados:
    1. Campo: CreatedById
    2. Operador: Igual que
    3. Tipo: Usuario actual
    4. Valor: UserId
  8. Al final, la regla de restricción de Brenda se verá como la siguiente captura de pantalla :
  9. Una vez que todo se vea bien, haga clic en Guardar .

Cosas para recordar

  • A partir del lanzamiento de Winter'22, la regla de restricción solo admite los siguientes objetos:
    • Tarea, Evento, Contrato, Objeto personalizado, Hoja de tiempo y Entrada de hoja de tiempo.
  • Puede crear reglas de restricción a través de:
    • API de herramientas
    • API de metadatos
    • Ventas antes de la configuración
  • Es posible implementar reglas de restricción usando conjuntos de cambios.
  • Puede crear hasta dos reglas de restricción por objeto en las ediciones Enterprise y Developer y hasta cinco reglas de restricción por objeto en las ediciones Performance y Unlimited.
  • Consulte este artículo de ayuda para encontrar una lista completa de las consideraciones y limitaciones de las reglas de restricción.

Evaluación formativa:

¡Quiero saber de ti!

¿Qué aprendió de esta publicación, es relevante para usted y cómo modificará los conceptos enseñados en la publicación para sus propios procesos comerciales? ¡Comparte tus consejos en los comentarios!

Haz una publicación y etiquétame en Twitter @automationchamp usando #AutomationChampionFlow.

 Corrector de pruebas : - Munira Majmundar

Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://automationchampion.com/2021/10/05/build-a-robust-security-architecture-control-sensitive-records-with-restriction-rules/

Entradas recomendadas