P. ¿Qué es un grupo de conjuntos de permisos?
Grupos de conjuntos de permisos es una función que permite a los administradores combinar varios conjuntos de permisos en un solo grupo de conjuntos de permisos para la asignación de usuarios. Con el mecanismo de agrupación, los administradores pueden aplicar verdaderamente el control de acceso basado en roles para administrar los derechos de los usuarios en las organizaciones de Salesforce.
P. ¿Qué es el conjunto de permisos personalizados?
Actualmente, en Salesforce tenemos muchas funciones que requieren verificaciones de acceso que especifican qué usuarios pueden acceder a determinadas funciones. Sin embargo, los conjuntos de permisos y los perfiles no incluyen el acceso a algunos procesos y aplicaciones personalizados. Los permisos personalizados le permiten definir comprobaciones de acceso que se pueden asignar a los usuarios a través de conjuntos de permisos o perfiles, de manera similar a cómo asigna permisos de usuario y otras configuraciones de acceso. Por ejemplo, puede definir comprobaciones de acceso en Apex que hacen que un botón en una página de Visualforce esté disponible solo si un usuario tiene el permiso personalizado apropiado. En cualquier momento, el administrador puede revocar el permiso personalizado del perfil o conjunto de permisos para revocar el acceso a la aplicación del procesador.
La siguiente lógica representa el bloque de página según el permiso personalizado.
<apex: pageBlock renderizado = ”{! $ Permiso. Opportunity_Stage_Edit} ”>
</ apex: pageBlock>
P ¿Cómo activar la regla de uso compartido del campo Fórmula?
La regla de uso compartido no le permite usar campos de fórmula en los criterios de la regla, pero la solución es reemplazar el campo de fórmula con un campo regular y colocar la fórmula que lo completa en un flujo de trabajo que se activa cada vez que se crea o edita un objeto. Tendremos un campo regular con el mismo valor.
ejemplo: hay una ciudad (campo de fórmula) en el objeto Student_c y debemos usarla en los criterios que cuando Ciudad = ‘Delhi’ se comparta con el rol de Soporte de ventas. Ahora, como no podemos acceder al campo de fórmula en la regla de uso compartido, crearemos otro campo en el objeto del estudiante, digamos CityValue. Ahora crearemos un flujo de trabajo que siempre que City (formulaField) = ‘Delhi’, luego fieldUpdate CityValue (TextField) a ‘Delhi’. Luego acceda al campo CityValue en la regla Compartir.
P. ¿Es posible omitir el acceso Conceder acceso mediante jerarquías en el caso de objetos estándar?
No
P. ¿El objeto personalizado en el lado de los detalles puede tener una regla para compartir?
Los objetos personalizados en el lado de los detalles de una relación maestro-detalle no pueden tener reglas de uso compartido, uso compartido manual o colas, ya que requieren el campo Propietario.
P. ¿Por qué no puedo encontrar la lista de campos de Cuenta personal en la configuración de Seguridad de nivel de campo (FLS) cuando navego a los campos en Objeto de cuenta?
La seguridad de nivel de campo (FLS) de los campos de la cuenta personal se controla mediante los campos de contacto. Por lo tanto, si desea configurar el FLS de los campos de cuenta personal, navegue a los campos de contacto y se reflejará en la cuenta personal.
P: Tipos de reglas para compartir, ¿cuántas hay?
Las reglas de uso compartido se utilizan para abrir el acceso al registro de Salesforce.
La regla de uso compartido funciona si el registro OWD es privado o público de solo lectura
Cuando se ejecuta la regla de uso compartido, Salesforce crea un registro detrás de escena para compartir obect
No podemos compartir los registros con el usuario directamente. Necesitamos agregar usuarios al grupo público para compartir registros.
Hay tres tipos de reglas para compartir:
- Regla de uso compartido basada en el propietario
- Regla de uso compartido basada en criterios. No puede utilizar Apex para crear reglas de intercambio basadas en criterios. Además, el uso compartido basado en criterios no se puede probar con Apex.
- Acceso de usuario invitado, según criterios
Puede compartir registro con:
- Grupo público
- Roles
- Colas
- Roles y subordinados internos
- Roles, portal y subordinados internos
P: ¿Explique Apex Sharing?
Para acceder a compartir mediante programación , debe utilizar el objeto compartido asociado con el objeto estándar o personalizado para el que desea compartir. Por ejemplo, AccountShare es el objeto compartido para el objeto Cuenta, ContactShare es el objeto compartido para el objeto Contacto. Además, todos los objetos de uso compartido de objetos personalizados se denominan de la siguiente manera, donde MyCustomObject es el nombre del objeto personalizado:
MyCustomObject__Share
Un objeto compartido incluye registros que admiten los tres tipos de uso compartido:
compartir gestionado
uso compartido administrado por el usuario
Uso compartido administrado por Apex
P. ¿Cuáles son algunas consideraciones para el uso compartido administrado de Apex?
Solo los usuarios con el permiso «Modificar todos los datos» pueden agregar o cambiar el uso compartido administrado de Apex en un registro
P. ¿Cuáles son las consideraciones de compartir objetos?
Los objetos en el lado de los detalles de una relación maestro-detalle no tienen un objeto compartido asociado.
No podemos crear el objeto «__share» por ti mismo. El sistema lo crea por nosotros. Si la configuración para compartir de un objeto es «Lectura / escritura pública», el sistema no creará el objeto «__share», ya que no hay un alcance para compartir, todos los registros están abiertos para todos en la organización. Sin embargo, si la configuración de uso compartido del objeto es «Público de solo lectura» o «Privado», el sistema crea un objeto «__share» para nosotros.
P. El objeto de caso tiene OWD configurado como privado. Ahora, independientemente de las jerarquías, como de arriba hacia abajo (por ejemplo, el gerente puede ver los casos de clientes potenciales), de abajo hacia arriba (por ejemplo, el cliente potencial puede ver los casos de los jefes) y horizontal (por ejemplo, el cliente potencial puede ver los casos de clientes potenciales) y de forma transversal, todos los casos deben ser visibles. a cualquier persona sin cambios en OWD. ¿Cómo es esto posible?
Cree una regla de uso compartido basada en criterios en la que otorgue acceso a «Roles y subordinados» al jefe de departamento, esto permitirá que todos accedan al caso independientemente de la jerarquía.
P: ¿Es posible crear reglas de uso compartido para el objeto de detalle?
No, podemos crear reglas de uso compartido para objetos de detalles porque no tienen un campo de propietario.
P. ¿Cuáles son las propiedades del objeto compartido?
objectNameAccessLevel: el nivel de acceso que se le ha otorgado al usuario o grupo especificado para un sObject compartido
Los valores válidos son:
• Editar
• Leer
• Todas
ParentID: el ID del objeto. Este campo no se puede actualizar.
RowCause: el motivo por el que se concede acceso al usuario o grupo . El motivo determina el tipo de intercambio , que controla quién puede alterar el registro de intercambio . Este campo no se puede actualizar.
UserOrGroupId: los ID de usuario o grupo a los que está otorgando acceso . Un grupo puede ser:
• Un grupo público o un grupo de uso compartido asociado con un rol.
• Un grupo territorial.
P. ¿Cuáles son algunas de las consideraciones para compartir el ápice?
Los objetos en el lado de los detalles de una relación maestro-detalle no tienen un objeto compartido asociado. El acceso al registro de detalles está determinado por el objeto de uso compartido del maestro y la configuración de uso compartido de la relación.
P: ¿En qué modo se ejecuta Apex?
Apex generalmente se ejecuta en el contexto del sistema ; es decir, los permisos del usuario actual y la seguridad a nivel de campo no se tienen en cuenta durante la ejecución del código. Sin embargo, las reglas de uso compartido no siempre se omiten: la clase debe declararse con la palabra clave sin compartir para garantizar que no se apliquen las reglas de uso compartido.
Las únicas excepciones a esta regla son el código Apex que se ejecuta con la llamada executeAnonymous y Connect en Apex. executeAnonymous siempre se ejecuta con todos los permisos del usuario actual. Para obtener más información sobre executeAnonymous, consulte Bloques anónimos.
P: ¿Qué efecto tiene el hecho de compartir en el permiso del usuario y FLS?
Hacer cumplir las reglas de uso compartido mediante el uso de la palabra clave with sharing no impone los permisos del usuario ni la seguridad a nivel de campo. El código Apex siempre tiene acceso a todos los campos y objetos de una organización, lo que garantiza que el código no deje de ejecutarse debido a campos u objetos ocultos para un usuario.
P: ¿Cómo aplicar FLS a nivel de objeto en Apex?
Apex no aplica los permisos a nivel de objeto ni a nivel de campo de forma predeterminada, puede aplicar estos permisos en sus consultas SOQL mediante WITH SECURITY_ENFORCED.
También puede aplicar permisos a nivel de objeto y de campo en su código llamando explícitamente a los métodos de resultado de descripción de sObject (de Schema.DescribeSObjectResult) y al método de resultado de descripción de campo (de Schema.DescribeFieldResult ) que verifican los niveles de permisos de acceso del usuario actual. De esta manera, puede verificar si el usuario actual tiene los permisos necesarios, y solo si tiene los permisos suficientes, puede realizar una operación DML específica o una consulta.
Por ejemplo, puede llamar a los métodos isAccessible, isCreateable o isUpdateable de Schema.DescribeSObjectResult para verificar si el usuario actual ha leído, creado o actualizado el acceso a un sObject, respectivamente .
Para verificar el permiso de actualización a nivel de campo del campo de correo electrónico del contacto antes de actualizarlo:
- if (Schema.sObjectType.Contact.fields.Email.isUpdateable ()) {
- // Actualizar el número de teléfono de contacto
- }
Para verificar el permiso de creación a nivel de campo del campo de correo electrónico del contacto antes de crear un nuevo contacto:
- if (Schema.sObjectType.Contact.fields.Email.isCreateable ()) {
- // Crear nuevo contacto
- }
Para verificar el permiso de lectura a nivel de campo del campo de correo electrónico del contacto antes de consultar este campo:
- if (Schema.sObjectType.Contact.fields.Email.isAccessible ()) {
- Contact c = [SELECT Email FROM Contact WHERE Id =: Id];
- }
Para comprobar el permiso a nivel de objeto para el contacto antes de eliminarlo:
- if (Schema.sObjectType.Contact.isDeletable ()) {
- // Borrar contacto
- }
P: ¿Cuál es el uso de stripInaccessible?
Utilice el método stripInaccessible para hacer cumplir la protección de datos a nivel de campo y de objeto . Este método se puede utilizar para quitar los campos y los campos de relación de los resultados de consultas y subconsultas a los que el usuario no puede acceder. El método también se puede utilizar para eliminar campos sObject inaccesibles antes de las operaciones DML para evitar excepciones y desinfectar sObjects que se han deserializado de una fuente que no es de confianza.
La verificación de acceso se basa en el permiso a nivel de campo del usuario actual en el contexto de la operación especificada: crear, leer, actualizar o actualizar. El método stripInaccessible comprueba los registros de origen en busca de campos que no cumplan con la comprobación de seguridad a nivel de campo del usuario actual. El método también verifica los registros de origen en busca de campos de búsqueda o de relación maestro-detalle a los que el usuario actual no tiene acceso. El método crea una lista de retorno de sObjects que es idéntica a los registros de origen, excepto que se eliminan los campos que son inaccesibles para el usuario actual.
P: ¿stripInaccessible es compatible con el objeto AggregateResult?
El método stripInaccessible no es compatible con AggregateResult SObject. Si los registros de origen son del tipo AggregateResult SObject, se lanza una excepción.
P: ¿Cómo recalcular el uso compartido administrado por ápice?
Para volver a calcular el uso compartido administrado de Apex, debe escribir una clase de Apex para realizar el nuevo cálculo. Esta clase debe implementar la interfaz Database.Batchable proporcionada por Salesforce.
La interfaz Database.Batchable se utiliza para todos los procesos de Apex por lotes, incluido el recalculado del uso compartido administrado de Apex.
Para este ejemplo, suponga que está creando una aplicación de contratación y tiene un objeto llamado Trabajo. Desea validar que el reclutador y el gerente de contratación que figuran en el trabajo tienen acceso al registro. La siguiente clase de Apex realiza esta validación. Este ejemplo requiere un objeto personalizado llamado Trabajo, con dos campos de búsqueda asociados con registros de usuario llamados Hiring_Manager y Recruiter. Además, el objeto personalizado Trabajo debe tener dos razones para compartir agregadas llamadas Hiring_Manager y Recruiter. Antes de ejecutar esta muestra, reemplace la dirección de correo electrónico con una dirección de correo electrónico válida a la que desea enviar notificaciones de error y notificaciones de finalización del trabajo.
P: ¿Qué es el uso compartido administrado por el usuario?
En el uso compartido administrado por el usuario, un usuario que tiene acceso completo al registro comparte los registros con otros, pero cuando se cambia el propietario del registro, este registro se eliminará de la tabla de uso compartido. De manera similar , cuando el intercambio de ápice se define como «Manual» en RowCause, eliminará el registro de la tabla de intercambio cuando se cambie el propietario del registro.
Para resolver este problema, necesitamos definir Apex Sharing Reason en Rowcause mientras escribimos Apex Sharing.
Código de ejemplo:
Dado que hemos definido Apex Sharing Reason en el uso compartido de objetos personalizados, mantendrá actualizados los registros de la tabla Share siempre que se cambie el propietario del registro. Por lo tanto, el usuario aún autorizado puede acceder a los registros sin ningún problema.
P: ¿Explique el uso compartido de Apex para objetos estándar?
Los objetos estándar no son compatibles con Apex Sharing Reason . Por lo tanto, al compartir registros de objetos estándar, de forma predeterminada debe definir RowCause como «Manual».
P. El objeto de caso tiene OWD configurado como privado. Ahora, independientemente de las jerarquías, como de arriba hacia abajo (por ejemplo, el gerente puede ver los casos de clientes potenciales), de abajo hacia arriba (por ejemplo, el cliente potencial puede ver los casos de los jefes) y horizontal (por ejemplo, el cliente potencial puede ver los casos de clientes potenciales) y de forma transversal, todos los casos deben ser visibles. a cualquier persona sin cambios en OWD. ¿Cómo es esto posible?
Cree una regla de uso compartido basada en criterios en la que otorgue acceso a «Roles y subordinados» al jefe de departamento, esto permitirá que todos accedan al caso independientemente de la jerarquía.
¿Cuáles son los escenarios en los que podemos usar sin compartir?
Sin compartir
1. Si tenemos una página de LWC en la que estamos mostrando «Rendimiento del representante de ventas», que muestra una bandera en rojo, verde y amarillo. Ahora bien, lo ideal es que este campo no esté visible siempre que un Representante de ventas acceda a esta página. Pero siempre es visible si la clase no tiene una palabra clave especificada o si una clase tiene sin compartir especificado.
¿Cuáles son las consideraciones al usar con compartir?
- Si la clase no se declara como Con compartir o Sin compartir, la clase se toma por defecto como Sin compartir.
- Tanto las clases internas como las externas se pueden declarar como Con uso compartido.
- Si la clase interna se declara como With Sharing y la clase de nivel superior se declara como Sin compartir, entonces, de forma predeterminada, todo el contexto se ejecutará en With Sharing Context.
- Si una clase no se declara como Con / Sin compartir y si esta clase es llamada por otra clase en la que se aplican las reglas de uso compartido, ambas clases se ejecutan con Con uso compartido.
- La clase externa se declara como With Sharing y la clase interna se declara como Without Sharing, luego la clase interna se ejecuta solo en el contexto Sin compartir (la clase interna no toma las propiedades de Sharing de la clase externa).
P: ¿Cuál es la diferencia entre el uso compartido gestionado por ápice y el uso compartido?
Apex Managed Sharing se utiliza para otorgar acceso a los registros . Se trata de configurar de manera programática las reglas para compartir. La palabra clave «Con uso compartido» se utiliza para respetar la regla actual de uso compartido del usuario.
P: ¿Cuáles son las consideraciones al utilizar el uso compartido administrado por Apex?
- Si el propietario del registro cambia , el uso compartido creado a través del uso compartido administrado por ápice se mantiene, pero si el usuario comparte el registro manualmente , el uso compartido de registros se perderá si el propietario cambia.
- El usuario con «modificar todos los datos» solo puede agregar, editar o eliminar registros en la tabla de compartir.
P: ¿Cuáles son las limitaciones del uso compartido manual?
- El uso compartido manual no puede ser más estricto que los valores predeterminados de toda la organización.
- El uso compartido manual solo está disponible en registros individuales, no está disponible para todos los registros de un determinado objeto.
- Solo se aplica a los registros que tienen acceso público o privado de solo lectura en OWD.
- Al configurar el uso compartido automático y manual, los usuarios y administradores deben definir si la seguridad debe extenderse a los registros relacionados.
- ¿Qué es Con compartir y sin compartir?
- Con uso compartido: significa «con la configuración de seguridad aplicada». Si declara una clase como Con uso compartido, las reglas de uso compartido proporcionadas al usuario actual se tendrán en cuenta. Esto se refiere únicamente a respetar los OWD y las Reglas de uso compartido. No podemos aplicar «automáticamente» la seguridad a nivel de campo o los permisos de perfil con «con compartir»,
- Ejemplo
- público con compartir clase sharingClass
- Sin compartir: si declara una clase como Sin compartir, esta clase de Apex se ejecuta en modo de sistema, lo que significa que el código de Apex tiene acceso a todos los objetos y campos independientemente de las reglas de uso compartido de los usuarios actuales, la seguridad de nivel de campo y los permisos de Objeto.
P. ¿Diferencia entre rol y perfil?
- Los perfiles ayudan a controlar los privilegios de objetos como CRED (Crear, Leer, Editar, Eliminar). También contienen permisos del sistema que un usuario puede realizar, como exportar datos.
- Los roles ayudan a compartir registros en una organización. Funcionan de forma jerárquica, dando a los usuarios acceso a registros que son propiedad de personas más bajas en la jerarquía.
- Un usuario solo puede tener un único perfil y rol asignado.
P: ¿Diferencia entre grupo público y cola?
- Las colas se utilizan cuando asignamos un registro a un grupo de usuarios. Con la ayuda de las colas podemos asignar un registro a múltiples usuarios (usando colas) para que cualquier miembro de la cola pueda trabajar en el registro. También permite a los usuarios tener vistas separadas.
- Se utiliza para equilibrar la carga.
- Se puede crear para objetos personalizados y para casos, clientes potenciales y versiones de artículos de conocimiento.
- Ejemplo:
- Escenario de la vida real
- Hay muchos ejecutivos de atención al cliente en un centro de llamadas y muchos clientes llaman a la vez y un ejecutivo puede hablar con un cliente a la vez, por lo que las llamadas de otros clientes se mantienen en colas. Cada usuario debe tener asignado al menos un cliente potencial y el mismo número de clientes potenciales.
- Lo mismo ocurre en Salesforce:
- El usuario debe manejar el cliente potencial asignado individualmente y todos los usuarios de la organización deben tener asignado el mismo número de clientes potenciales, en este caso podemos definir usuarios en la organización como Cola y asignarlos uno por uno y en el mismo número mediante la asignación de clientes potenciales por turnos.
Los grupos públicos son usuarios relacionados con el equipo o el grupo, que se utilizan para compartir datos. No son los propietarios de los registros (como la cola), pero pueden compartir los registros (en términos de acceso).
El grupo público se puede crear en cualquier objeto.
QA puede ver los datos B pero B no puede ver los datos A. ¿Por qué?
- Verifique las siguientes condiciones
- 1 – ¿Ambos usuarios tienen el mismo perfil?
- 2. Compruebe la jerarquía de roles de A y B.
- 3. Marque la regla de uso compartido
P. ¿Qué es TOTP?
TOTP es una contraseña de un solo uso basada en el tiempo. Podemos utilizar el flujo de inicio de sesión que mejora la autenticación TOTP con un método de autenticación de dos factores que admite Salesforce. El algoritmo TOTP calcula una contraseña de un solo uso a partir de una clave secreta compartida y la hora actual.
Los usuarios pueden utilizar una aplicación de autenticación basada en el tiempo (como Salesforce Authenticator o Google Authenticator) para escanear el código QR y generar un token TOTP.
P. ¿Qué es Con compartir y sin compartir?
Con uso compartido: significa «con la configuración de seguridad aplicada». Si declara una clase como Con uso compartido, las reglas de uso compartido proporcionadas al usuario actual se tendrán en cuenta. Esto se refiere únicamente a respetar los OWD y las Reglas de uso compartido. No podemos aplicar «automáticamente» la seguridad a nivel de campo o los permisos de perfil con «con compartir»,
Ejemplo
público con compartir clase sharingClass
Sin compartir: si declara una clase como Sin compartir, esta clase de Apex se ejecuta en modo de sistema, lo que significa que el código de Apex tiene acceso a todos los objetos y campos independientemente de las reglas de uso compartido de los usuarios actuales, la seguridad de nivel de campo y los permisos de Objeto.
P: El usuario A tiene el botón CLONAR visible en Cuentas, el Usuario B no puede ver el botón CLONAR en Cuentas. ¿Por qué?
Verifique las siguientes condiciones
1 – ¿Ambos usuarios tienen el mismo perfil?
2 – No hay ningún conjunto de permisos personalizados asignado a ningún usuario
3 – ¿Tiene tipos de registro para el objeto de cuenta y diseños de página asociados para esos tipos de registro?
4 – Ha verificado el diseño de la página y el botón Clonar se agrega al Diseño de página.
P: Tenemos 2 usuarios A y B con el mismo perfil y función. ¿Cómo podemos restringir los registros de A a B y viceversa?
En el conjunto de perfiles Ver todos los datos y modificar todos los permisos de fecha a ‘falso’. Esto restringirá el acceso del usuario a los datos creados por otros usuarios.
P. Hay 100 usuarios. ¿90 usuarios pueden leer registros, 10 usuarios pueden actualizar registros?
Crea dos perfiles:
El primer perfil otorga permiso de lectura y agrega 90 usuarios.
El segundo perfil otorga permiso de lectura y edición y agrega 10 usuarios.
P. ¿Cuáles son los tipos de OWD?
Privado
Solo lectura pública
Lectura y escritura pública
Lectura / escritura / transferencia pública
P. ¿Cuáles son las limitaciones del modelo OWD?
OWD reduce el acceso. No se puede abrir el acceso
P. Hay cinco usuarios bajo un perfil y solo un usuario ve todos los datos. La cuenta es privada. ¿Por qué?
Cree un conjunto de permisos con ver todos los accesos a las cuentas y asigne un conjunto de permisos a un usuario específico
P. ¿Qué es SAML?
Security Assertion Markup Language (SAML) es un estándar abierto que permite el inicio de sesión único (SSO). Al hacer que una variedad de recursos sea accesible con un solo conjunto de credenciales de inicio de sesión, puede proporcionar un acceso sin problemas a los recursos y eliminar la proliferación de contraseñas inseguras.
SAML habilita específicamente la federación de identidades, lo que hace posible que los proveedores de identidad (IdP) pasen de manera transparente y segura identidades autenticadas y sus atributos a los proveedores de servicios (SP).
P. ¿Qué es OWD y por qué es necesario?
OWD es el valor predeterminado de toda la organización. Se utiliza para seguridad a nivel de registro. Es seguridad básica. Proporciona el acceso más restrictivo para el registro y luego podemos abrirlo con jerarquía de roles, regla de uso compartido, uso compartido manual.
Público Acceso completo.
La opción de acción completa pública está disponible para configurar el objeto de campaña únicamente. A través del acceso público, el usuario puede tener la capacidad de buscar registros, informes y registros, agregar registros relacionados, editar detalles del registro y eliminar el registro.
Lectura / Escritura / Transferencia
La opción de lectura / escritura / transferencia solo está disponible para clientes potenciales y casos. Aquí podemos configurar Privado, Público Rad solamente, Público Lectura / Escritura y público / Lectura / Escritura / Transferencia para casos y objetos principales. Cuando los objetos de caso y cliente potencial se establecen en público / Lectura / Escritura / Transferencia, todos los usuarios pueden ver, editar, transferir e informar sobre todos los casos y registros de clientes potenciales.
Lectura / escritura pública.
Cuando un registro se establece en lectura / escritura pública, el usuario puede ver, editar e informar sobre todos los registros.
Solo lectura pública.
Cuando un registro se establece como público de solo lectura, el usuario puede buscar los registros, ver e informar sobre cada registro, pero el usuario no puede editar ese registro. Los propietarios y usuarios de registros pueden editar esos registros.
Privado.
Cuando un registro se configura como privado, solo el propietario del registro y los usuarios superiores a los roles en una jerarquía pueden ver, editar e informar sobre esos registros.
Sin acceso, solo visualización, uso.
Esta opción Sin acceso, Ver solo, Usar solo está disponible para las listas de precios. Podemos establecer el nivel de acceso para la configuración de OWD del libro de precios en Sin acceso, solo ver o usar.
El uso es el nivel de acceso predeterminado para la lista de precios y permite a los usuarios acceder a la información de la lista de precios y pueden usar esa información de la lista de precios en oportunidades con productos.
Ver solo permite a los usuarios acceder a la información de la lista de precios y no utilizar esa información en oportunidades con productos.
Sin acceso restringe a los usuarios el acceso a la información y los precios de la lista de precios.
P: ¿Qué es el cifrado de plataforma Shield?
Shield Platform Encryption brinda a sus datos una nueva capa de seguridad al tiempo que preserva la funcionalidad crítica de la plataforma. Le permite cifrar datos confidenciales en reposo y durante la transmisión a través de la red .
Shield Platform Encryption se basa en las opciones de cifrado de datos que Salesforce ofrece de forma inmediata. Los datos almacenados en muchos campos estándar y personalizados y en archivos y adjuntos se cifran mediante un sistema avanzado de derivación de claves basado en HSM , por lo que están protegidos incluso cuando otras líneas de defensa se han visto comprometidas.
Su clave de cifrado de datos nunca se guarda ni se comparte entre organizaciones. En su lugar, se deriva a pedido de un secreto maestro y el secreto de inquilino específico de su organización, y se almacena en caché en un servidor de aplicaciones.
P. ¿Cómo rastreamos si el campo está encriptado o no?
Si es un usuario autorizado para acceder al registro, los datos se mostrarán normalmente en el registro. Entonces, ¿cómo podemos rastrear si los campos están encriptados o no? Lo primero que podemos hacer es comprobar la información archivada de Workbench
- WorkBench : puede iniciar sesión en Workbench
Información-> Objeto estándar y personalizado -> Seleccione el objeto
Luego expanda la carpeta Campos -> Seleccione el campo que ha cifrado. En detalle, obtendrá cifrado en verdadero.
- Destruyendo la clave del inquilino: si destruye la clave del inquilino, verá directamente el resultado de los campos cifrados a nivel de registro. Para obtener acceso autorizado nuevamente a los campos cifrados, importe la clave de inquilino.
Estadísticas de cifrado:
Las estadísticas de cifrado le proporcionarán un informe completo sobre la cantidad de datos cifrados por Shield Platform Encryption y la cantidad de datos cifrados por un secreto de inquilino activo.
Configuración -> Cifrado de plataforma -> Estadísticas de cifrado
P. ¿Diferencia entre el cifrado clásico y el cifrado de escudo?
Con Shield Platform Encryption, puede cifrar una variedad de campos estándar ampliamente utilizados, junto con algunos campos personalizados y muchos tipos de archivos. Shield Platform Encryption también admite cuentas personales, casos, búsqueda, procesos de aprobación y otras funciones clave de Salesforce. El cifrado clásico le permite proteger solo un tipo especial de campo de texto personalizado, que crea para ese propósito.
P: ¿Qué es compartir implícitamente?
El intercambio implícito es automático . No puede apagarlo ni encenderlo, es nativo de la plataforma.
El uso compartido implícito de los padres proporciona acceso de solo lectura a los registros de los padres (solo cuenta), cuando el usuario tiene acceso al registro de los niños, como: oportunidades, casos o contactos para esa cuenta. Esto no significa que el usuario deba ser el registro propiedad del registro secundario.
Cuando el usuario tiene acceso a un registro de otros objetos (NO oportunidad, caso o contacto) que tienen una búsqueda en la Cuenta, el usuario verá solo el Nombre de la Cuenta, pero no accederá a los detalles de la Cuenta ; esto incluye la búsqueda de la Cuenta en la Cuenta Principal, secundaria el propietario de la cuenta solo verá el nombre de la cuenta principal.
El uso compartido implícito de niños es la capacidad del propietario de la cuenta para acceder a los registros secundarios (contactos, oportunidades y casos), incluso si no son propiedad del propietario de la cuenta. La función del propietario de la cuenta determina el nivel de acceso a los registros secundarios (solo lectura o lectura / escritura).
P: ¿Qué es System.RunAs?
Generalmente, todo el código Apex se ejecuta en modo de sistema, donde no se tienen en cuenta los permisos y el uso compartido de registros del usuario actual. El método del sistema runAs nos permite escribir métodos de prueba que cambian el contexto del usuario a un usuario existente o un nuevo usuario para que se aplique el uso compartido de registros del usuario.
El método runAs no impone permisos de usuario o permisos de nivel de campo, solo uso compartido de registros. Podemos usar runAs solo en métodos de prueba.
…
Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://www.sfdcamplified.com/2021/04/interview-question-on-sharing-and-security-in-salesforce.html#utm_source=rss&utm_medium=rss&utm_campaign=interview-question-on-sharing-and-security-in-salesforce
