En la mayoría de empresas a las que entramos, Salesforce y ciberseguridad pertenecen a líderes distintos, vendors distintos y líneas de presupuesto distintas. Esa separación tenía sentido cuando CRM era una herramienta de ventas y la seguridad era un firewall perimetral. Ninguna de las dos cosas es cierta hoy.

Por qué existe el muro

La razón histórica es simple. El CRM vivía bajo Ventas o Customer Success. La seguridad vivía bajo TI o, cada vez más, un CISO dedicado. Cada uno creció con su propio ecosistema de vendors, sus propios consultores, sus propios KPIs. CRM optimizaba para velocidad de ingreso; seguridad para reducción de riesgo. Rara vez necesitaron coordinarse porque los datos que fluían por CRM eran, francamente, menos interesantes para los atacantes que los sistemas financieros o el core bancario.

Eso cambió cuando los CRMs pasaron a ser el sistema de registro de todo — identidad del cliente, relaciones financieras, datos sensibles de producto, evaluaciones de empleados, contratos con partners. Hoy, un org de Salesforce completamente poblado está entre los blancos de mayor valor en cualquier empresa. Sin embargo, el modelo de seguridad alrededor suele heredarse de la era en que CRM eran notas de venta.

Dónde se ve la sangría

Tres patrones se repiten en nuestros engagements:

Sprawl de permisos. Sin revisión de seguridad, profiles, permission sets y sharing rules se acumulan. Hemos auditado orgs con 400+ permission sets, la mayoría creados durante peticiones de proyecto one-off. Cada uno es un vector potencial de movimiento lateral. Cada uno también frena a los admins legítimos.

Puntos ciegos en integraciones. Las integraciones custom con ERP, data warehouses o SaaS de terceros típicamente las construyen los equipos de delivery de Salesforce sin revisión de seguridad. Encontramos rutinariamente credenciales hardcoded, service accounts sobre-privilegiadas y egress de datos sin monitorear.

A la inversa, equipos de seguridad que no entienden Salesforce asumen lo peor, bloquean integraciones legítimas y agregan latencia a flujos críticos de ingreso. Ambos equipos construyen workarounds para el otro. Nadie gana.

Cómo se ve un modelo integrado

El primer movimiento es estructural, no técnico: un comité conjunto de revisión de arquitectura donde el arquitecto de Salesforce y el arquitecto de seguridad firman cada integración, cambio de modelo de permisos y release mayor. No tiene que frenar la entrega; la cadencia operativa correcta es 90 minutos semanales.

El segundo movimiento es observabilidad. El monitoreo de eventos Salesforce Shield (o su equivalente en tu edición) alimenta al SIEM del SOC, junto con logs de infraestructura y endpoint. Los playbooks del SOC ganan escenarios específicos de Salesforce: impersonation de usuarios privilegiados, mass exports, detección de anomalías en API.

El tercer movimiento es respuesta a incidentes compartida. El runbook para un compromiso de credenciales involucra a ambos equipos desde el minuto cero — no como handoff sino como operación conjunta. El admin Salesforce sabe qué data se expuso; el analista de seguridad sabe cómo ocurrió la brecha. Juntos, lo contienen.

Cuánto cuesta ignorarlo

En un engagement, un banco regional tenía tres orgs de Salesforce. Su equipo de seguridad no sabía que uno de ellos existía — lo había levantado un equipo de marketing con una tarjeta corporativa. Ese org contenía 80.000 registros de clientes y estaba integrado con un scraper no mantenido que corría cada noche. La detección ocurrió en nuestra fase de discovery, no en el SOC.

La limpieza costó más que un año entero de comités conjuntos de arquitectura. El banco ahora opera un comité conjunto. No han encontrado otro org rogue desde entonces.