Las 3 configuraciones erróneas más peligrosas de Salesforce • TechCrunch

Gartner lo aprecia Para 2025, el 70 % de las aplicaciones empresariales se crearán en plataformas de código bajo y sin código como Salesforce y ServiceNow. Pero, ¿proporcionan estas plataformas una falsa sensación de seguridad?

Cuando se les pregunta, los administradores de Salesforce suelen responder que la empresa es responsable de la seguridad. La seguridad es una responsabilidad compartida en las aplicaciones SaaS. El proveedor protege la infraestructura y sus administradores y desarrolladores son responsables de garantizar los derechos de acceso con menos privilegios.

Errores de configuración de la nube Responsable de triplicar las filtraciones de datos. La configuración incorrecta generalmente ocurre cuando se permite que la configuración de seguridad sea predeterminada, se establecen niveles de acceso inadecuados o cuando no se crean barreras de datos para proteger los datos confidenciales. Configurar una plataforma de código bajo es tan fácil que los administradores de código bajo a menudo no entienden el efecto de marcar la casilla.

Al observar el efecto de una simple marca de verificación, estas son las tres configuraciones incorrectas más graves en la plataforma de Salesforce: modificar todos los datos (MAD) y mostrar todos los datos (VAD), compartir y compartir grupos y ejecutar código Apex sin el método «runAs» .

Echemos un vistazo a cada uno y el impacto que pueden tener.

Los grupos son muy poderosos, pero potencialmente pueden abrir el acceso no deseado a usuarios no autorizados.

MAD y VAD

Empezaremos con lo obvio y lo peligroso. Modificar todos los datos y ver todos los permisos de datos hacen exactamente lo que dicen. Estos son los permisos de superusuario para Salesforce.

READ  Gran Turismo 7 deslumbra con un juego sin editar en Deep Forest Raceway en PS5

Si el usuario tiene VAD VAD, tiene acceso de lectura a todos los registros de datos del sistema. MAD significa que también pueden actualizar y eliminar cada registro. Estos permisos solo deben otorgarse a los administradores, e incluso así, a un número muy limitado de personas.

¿Por qué un funcionario podría verse tentado a dar MAD o VAD a no funcionarios? El caso típico es cuando el usuario no puede acceder a los datos que necesita ver. El administrador revisa el perfil del usuario y los conjuntos de permisos, todas las reglas de uso compartido y las secuencias de funciones, y no puede determinar por qué el usuario no puede ver la información. Como una «solución temporal», le dan al usuario MAD o VAD y ahora el usuario puede ver los registros, junto con todo lo demás en el sistema.

Este error también puede ocurrir cuando los desarrolladores se enfrentan al mismo dilema. Ejecutan MAD temporalmente en el perfil del usuario para poder avanzar con su código y luego olvidan que lo han ejecutado.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.