Seguridad de APIs en integraciones Salesforce y ERP

Como ejemplo hipotético, una integración entre Salesforce, un ERP y un WMS puede intercambiar miles de registros sin llamar la atención durante meses. El problema aparece cuando una credencial expira, un permiso queda demasiado abierto o una API acepta datos que no debería procesar. Esta guía de seguridad de APIs parte de esa realidad: proteger interfaces no consiste en añadir un control al final, sino en diseñar una operación que pueda resistir errores, cambios y usos indebidos sin comprometer la continuidad del negocio.

Para una empresa B2B en crecimiento, las APIs no son un detalle técnico aislado. Son el canal por el que viajan pedidos, precios, inventario, datos de clientes, estados de servicio y decisiones operativas. Si ese canal falla o queda expuesto, el impacto se traslada rápidamente a ventas, finanzas, almacén y atención al cliente.

Seguridad de APIs: el riesgo está en el flujo completo

Una API segura no se define solo por usar HTTPS o exigir un token. Esas medidas son necesarias, pero no responden a preguntas operativas relevantes: ¿qué sistema puede modificar un pedido?, ¿qué ocurre si se reintenta el mismo mensaje?, ¿quién detecta una extracción anómala de datos?, ¿cómo se revoca el acceso de un proveedor sin detener el resto de integraciones?

El punto de partida debe ser un inventario verificable. Cada API necesita un propietario funcional y técnico, una finalidad documentada, los datos que procesa, sus consumidores, su método de autenticación y su dependencia de otros servicios. Sin este mapa, una empresa suele descubrir interfaces críticas durante una incidencia, cuando cambiar una credencial o bloquear un endpoint ya tiene consecuencias difíciles de medir.

También conviene distinguir entre APIs internas, integraciones con terceros y APIs expuestas a clientes o partners. El nivel de exposición, la sensibilidad de los datos y el modelo de soporte no son iguales. Aplicar el mismo patrón a todos los casos puede generar dos problemas opuestos: controles insuficientes en canales públicos o fricción innecesaria en procesos internos de alta frecuencia.

Autenticación y autorización no son lo mismo

La autenticación responde a quién realiza una llamada. La autorización determina qué puede hacer esa identidad en cada recurso, operación y contexto. Muchas brechas ocurren porque el primer punto está resuelto y el segundo se trata de forma genérica: un token válido termina teniendo más acceso del necesario.

Para integraciones sistema a sistema, las identidades de servicio deben ser individuales, no compartidas entre aplicaciones o entornos. Un conector entre el ERP y Salesforce no debería reutilizar la misma credencial que una aplicación de reporting o un proveedor externo. Esta separación permite revocar acceso con precisión, investigar actividad y limitar el alcance de un incidente.

Los permisos deben aplicarse con mínimo privilegio. Si un proceso solo consulta disponibilidad de inventario, no necesita crear artículos ni acceder a información financiera. Cuando existen varios clientes, unidades de negocio o cuentas dentro de la misma plataforma, la autorización debe comprobar además el ámbito de datos. Validar que un usuario tiene token no basta si puede consultar registros de otra cuenta modificando un identificador en la URL.

Validar entradas y respuestas protege la operación

Una API debe asumir que recibirá datos incompletos, malformados, repetidos o manipulados. La validación de esquemas, tipos, longitudes, formatos y valores permitidos debe realizarse antes de ejecutar lógica de negocio o persistir información. No se trata solo de evitar ataques: evita que una actualización defectuosa de un sistema origen introduzca estados inválidos en el CRM o en el ERP.

La validación debe incluir reglas de negocio. Por ejemplo, un cambio de estado de pedido puede requerir que exista una cuenta activa, líneas válidas y una referencia de origen única. Si la API admite operaciones de creación o actualización, la idempotencia es especialmente relevante. Un reintento por timeout no debería duplicar una orden, un pago o una oportunidad.

Las respuestas también merecen control. Devolver todos los campos de una entidad por comodidad expone datos que el consumidor no necesita y convierte futuros cambios internos en una dependencia externa. Diseñar contratos explícitos reduce superficie de exposición y facilita evolucionar servicios sin romper consumidores.

Secretos, tokens y certificados requieren ciclo de vida

Las claves API, secretos de cliente, certificados y tokens no deben aparecer en código fuente, archivos de configuración compartidos, tickets ni hojas de cálculo. Deben gestionarse en un almacén de secretos con acceso restringido, auditoría y rotación definida. La práctica de crear una credencial "temporal" para desbloquear una incidencia suele convertirse en una dependencia permanente si no existe un control de caducidad.

La rotación debe probarse antes de ser necesaria. Si una organización no puede reemplazar una credencial sin una intervención manual incierta, tiene un riesgo operativo aunque no haya sufrido un incidente. En integraciones críticas, es razonable mantener periodos de solapamiento controlados entre credenciales antiguas y nuevas, con fechas de retirada registradas.

Diseñar límites para reducir el radio de impacto

La seguridad de APIs mejora cuando la arquitectura evita confiar ciegamente en cualquier red, aplicación o usuario. Un API gateway, una capa de integración o un servicio intermedio puede centralizar autenticación, limitación de tráfico, versionado, registro y políticas de acceso. Sin embargo, añadir una plataforma no corrige por sí solo contratos ambiguos ni permisos excesivos en los sistemas de destino.

La segmentación importa. Las APIs de administración no deberían compartir exposición con las de consulta pública. Los entornos de desarrollo, pruebas y producción deben usar identidades, datos y credenciales separados. Copiar datos de producción a un sandbox sin anonimización puede crear un problema de privacidad aunque la API productiva esté bien protegida.

También es necesario establecer límites de consumo. Rate limiting, cuotas y límites de tamaño de petición reducen el riesgo de abuso, errores de bucles de integración y degradación involuntaria. Los valores correctos dependen de cada caso: una sincronización nocturna de catálogo no tiene el mismo patrón que la reserva de inventario en tiempo real. El objetivo no es bloquear tráfico por defecto, sino preservar la capacidad del proceso crítico.

Observabilidad: detectar antes de que el negocio lo descubra

Un 401, un 429 o un 500 no son solo códigos HTTP. Son señales que deben correlacionarse con una integración, una versión, una identidad de servicio y un proceso de negocio. Registrar solicitudes sin contexto aporta poco; registrar datos sensibles completos genera otro riesgo. La trazabilidad útil conserva identificadores técnicos y de negocio, tiempos, resultado, origen y motivo de error, mientras minimiza o enmascara información personal y secretos.

Los equipos deberían poder responder con rapidez a preguntas concretas: qué pedidos no llegaron al ERP, desde cuándo falla una versión de API, qué cliente supera su cuota o qué cuenta de servicio accedió a un recurso fuera de su patrón habitual. Para lograrlo, métricas, logs y alertas deben definirse junto con el diseño de la integración, no después del primer incidente.

Las alertas necesitan criterio. Avisar por cada error transitorio provoca fatiga y termina ocultando lo relevante. Es preferible combinar umbrales, ventanas temporales y criticidad de proceso. Un fallo aislado en una consulta no tiene el mismo tratamiento que veinte minutos sin confirmar pedidos entrantes.

Qué pedir en una revisión de integraciones

Antes de contratar, acordad qué interfaces se revisarán, qué entornos se utilizarán y quién validará los resultados. Una propuesta útil debería concretar:

• Inventario de interfaces y responsables, con los flujos críticos para el negocio.
• Revisión de identidades, permisos por recurso y gestión de credenciales.
• Pruebas acordadas de validación, errores y reintentos en un entorno adecuado.
• Evidencias de los hallazgos, prioridad y dependencias de cada corrección.
• Plan de cambios, validación funcional y reversión.

Esta revisión de integración no equivale por sí sola a una prueba de penetración ni a una certificación de seguridad. Si se necesitan, su alcance y especialistas deben definirse expresamente.

Cómo priorizar las mejoras

La mejora de seguridad debe realizarse por prioridades y con límites claros. Intentar rediseñar todas las integraciones a la vez suele retrasar controles básicos sobre los flujos que ya concentran mayor riesgo.

En la fase de entender, se identifican APIs, propietarios, consumidores, datos, credenciales, flujos críticos y dependencias. El entregable no es únicamente un diagrama: debe incluir decisiones pendientes, riesgos priorizados y evidencia de qué interfaces están realmente activas.

En la fase de mejorar, se corrigen primero los puntos con exposición directa o alto impacto operativo. Esto puede implicar separar cuentas de servicio, retirar secretos del código, endurecer autorizaciones, definir esquemas, incorporar idempotencia o establecer políticas de gateway. Cada cambio debe incluir pruebas de regresión y un plan de reversión, porque asegurar una integración no justifica interrumpir la facturación o el despacho.

Finalmente, mantener y evolucionar significa tratar la seguridad como una capacidad operativa. Se revisan accesos, se rota material criptográfico, se controlan dependencias, se prueban cambios de versión y se actualiza la documentación. Un control que no tiene responsable, frecuencia y evidencia termina siendo una intención, no una medida de seguridad.

Una API bien protegida no es la que acumula más capas, sino la que permite saber quién accede, qué puede hacer, qué datos mueve y cómo recuperar el control cuando algo cambia. Ese nivel de claridad permite integrar nuevos sistemas sin convertir cada avance operativo en una nueva fuente de riesgo.

Referencias técnicas para profundizar

La guía de seguridad REST de OWASP desarrolla controles de transporte, autorización y validación. Su guía de logging ayuda a diseñar registros útiles sin exponer información sensible. Aplicad estas referencias según la arquitectura y los riesgos de vuestro entorno.

¿Necesitáis mejorar una integración con Salesforce?

Si los errores entre Salesforce, vuestro ERP y otras aplicaciones consumen tiempo del equipo, podéis consultar nuestro servicio de desarrollo, integraciones y evolución de Salesforce. Compartid el proceso afectado y el objetivo que queréis conseguir; una primera conversación permitirá valorar el encaje y definir un alcance proporcionado.