Categoría: Técnico
Subcategoría: Seguridad
Nivel: Intermedio
Tiempo de lectura: 6 minutos
Protegiendo el perímetro
Cuando un administrador de Salesforce habla de seguridad, la conversación suele girar alrededor de Profiles, Permission Sets, Roles, Sharing Rules u Organization-Wide Defaults. Es lógico: son los mecanismos que determinan qué puede hacer un usuario una vez que ya está dentro de la organización.
Sin embargo, todos estos controles tienen algo en común.
Ninguno decide si el usuario puede entrar.
Antes de que Salesforce evalúe un perfil, un permiso o una regla de compartición, ya tomó una decisión mucho más importante: permitir o denegar el acceso a la organización.
Esa diferencia puede parecer sutil, pero cambia por completo la forma de entender la seguridad de la plataforma. Antes de preguntarnos qué puede hacer un usuario, primero debemos responder una pregunta mucho más importante: ¿cómo logró entrar?
Después de más de 22 años trabajando en tecnología, vi compañías reduciendo costos en seguridad, disminuyendo políticas de seguridad para hacer que el acceso fuera más fácil y con menor cantidad de pasos para ingresar a los sistemas. Siempre vi cómo poner los costos y la comodidad por encima de la seguridad se convirtió en moneda corriente sin considerar un potencial costo que puede ser devastador.
Un ataque bien planeado puede derrumbar el futuro de cualquier compañía. El costo puede ser la subsistencia.
Otra cosa que aprendí con el tiempo: no importa el tamaño de una empresa ni el sector en el que opere. Tarde o temprano, toda organización expuesta a Internet enfrentará intentos de acceso no autorizados.
Por eso, cuando una organización diseña su estrategia de seguridad de acceso en Salesforce, suele hacerse una pregunta equivocada:
¿Van a intentar atacarnos?
La respuesta debería ser sí. La cuestión no es si alguien va a intentarlo, sino cuándo.
La pregunta realmente importante es otra: ¿Estamos preparados para cuando pase?
Ese cambio de perspectiva transforma por completo la forma de diseñar la seguridad. Dejamos de asumir que los controles existen para reaccionar ante un incidente y empezamos a construirlos para reducir la superficie de ataque antes de que ese incidente ocurra.
En seguridad informática existe un concepto fundamental para entender esta filosofía: el perímetro.
El perímetro es el conjunto de controles que determina quién puede intentar acceder a un sistema y bajo qué condiciones. En la seguridad de acceso en Salesforce, ese perímetro está formado por mecanismos como My Domain, los métodos de autenticación, Multi-Factor Authentication (MFA), las políticas de contraseñas, las restricciones por dirección IP, la verificación de dispositivos, la configuración de sesiones y las herramientas de auditoría.
Cada uno de estos controles resuelve un problema diferente. Comprenderlos de forma aislada es útil; comprender cómo trabajan juntos es lo que realmente permite diseñar una estrategia de seguridad sólida.
Esta serie nace también de un artículo que escribí hace unos meses como autor invitado en Salesforce Trail: “Salesforce Access Security: 10 Controls to Secure Your Org Perimeter”. Allí presenté una primera aproximación a los principales controles que protegen el perímetro de acceso de una organización. Esta vez voy a profundizar en cada uno de ellos, explorando no solo qué hacen, sino también por qué existen, cómo funcionan y cómo se relacionan entre sí.
Ese es el objetivo de esta serie.
No vamos a centrarnos en los pasos para configurar cada funcionalidad ni en recorrer las opciones disponibles en Setup, sino en entender la seguridad de acceso en Salesforce. El propósito es entender qué es cada mecanismo de seguridad, por qué existe, qué problema resuelve, cómo funciona y de qué manera interactúa con los demás controles.
Porque la seguridad de acceso en Salesforce no es una colección de configuraciones independientes. Es una arquitectura donde cada pieza cumple una función específica y solo cobra sentido cuando se entiende como parte de un sistema completo.
Índice de la serie
Esta serie está compuesta por trece artículos que, en conjunto, recorren la arquitectura de seguridad de acceso en Salesforce de principio a fin.
- Introducción: La arquitectura de seguridad de acceso en Salesforce (este artículo)
- My Domain: El Cimiento de la Identidad en el Perímetro
- Tipos de autenticación
- Políticas de contraseña
- Device Activation
- Network Access y Login IP Ranges
- Login Hours
- Connected Apps
- Session Settings
- Rastro de auditoría: qué quedó registrado
- Security Health Check
- Identity Licenses y Feature Entitlements
- Transaction Security Policies
A medida que se publiquen los siguientes capítulos, este índice se irá actualizando con enlaces a cada uno de ellos.
Antes de comenzar: las cuatro capas de seguridad de Salesforce
Aunque solemos hablar del «modelo de seguridad» de Salesforce como si fuera un único concepto, en realidad está compuesto por varias capas. Cada una responde a una pregunta diferente:
- Organization Layer: ¿Puede este usuario ingresar a la organización? Aquí encontramos controles como My Domain, autenticación, MFA, políticas de contraseñas, restricciones por dirección IP, horarios de acceso, verificación de dispositivos y configuración de sesiones.
- Object Layer: Una vez dentro, ¿puede acceder a este objeto?
- Record Layer: Si puede acceder al objeto, ¿qué registros específicos puede visualizar o modificar?
- Field Layer: Y dentro de esos registros, ¿qué campos puede ver o editar?
Estas capas no compiten entre sí ni se reemplazan. Se complementan y se evalúan de manera secuencial.
Si un usuario no supera los controles de la Organization Layer, Salesforce nunca llegará a evaluar sus permisos sobre objetos, registros o campos.
Por eso, esta serie estará dedicada exclusivamente a esa primera capa: la que protege el perímetro de la organización y decide quién puede cruzar la puerta de entrada.
Y en la seguridad de acceso en Salesforce, esa puerta tiene un nombre.
