Gartner estima que 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, ¿estas plataformas brindan 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. Su proveedor asegura la infraestructura, y sus administradores y desarrolladores son responsables de garantizar los derechos de acceso con privilegios mínimos.
Configuraciones incorrectas de la nube son responsables de un aumento de tres veces en las filtraciones de datos. Por lo general, la configuración incorrecta ocurre cuando se permite que la configuración de seguridad sea predeterminada, se asignan niveles de acceso inadecuados o no se crean barreras de datos para proteger los datos confidenciales. Configurar una plataforma de código bajo es tan fácil que el administrador de código bajo a menudo no comprende el impacto de marcar una casilla.
Al observar el impacto de una simple marca de verificación, estas son las tres configuraciones erróneas más riesgosas en la plataforma de Salesforce: Modificar todos los datos (MAD) y Ver todos los datos (VAD), Compartir y compartir grupos y Ejecutar código Apex sin el método “runAs” .
Veamos cada uno y el impacto que pueden tener.
Los grupos de intercambio son muy poderosos, pero potencialmente pueden abrir el acceso accidental a usuarios no autorizados.
MAD y VAD
Comenzaremos con lo obvio y más peligroso. Los permisos Modificar todos los datos y Ver todos los datos hacen exactamente lo que dicen. Estos son los permisos de superusuario para Salesforce.
Si un usuario tiene VAD, tiene acceso de lectura a todos los registros de datos del sistema. MAD significa que también pueden actualizar y eliminar todos los registros. Estos permisos solo deben otorgarse a los administradores e incluso entonces, a un número muy limitado de personas.
¿Por qué un administrador se sentiría tentado a dar MAD o VAD a los no administradores? El caso típico es cuando un 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 la jerarquía 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 encuentran con el mismo dilema. Activan temporalmente MAD en el perfil de usuario para avanzar en su código y luego olvidan que lo activaron.
Source link