Guía de seguridad de Salesforce para operaciones reguladas

Una guía de seguridad de Salesforce solo sirve de algo si empieza por los registros y las decisiones que pueden poner en riesgo a tu empresa, ya sea a nivel operativo, normativo o financiero. Para una aseguradora, podría tratarse de un ajuste en la reserva para siniestros. Para un equipo comercial del sector de las ciencias de la vida, podría ser una interacción con profesionales sanitarios sujeta a la obligación de transparencia. Para una operación de mantenimiento, reparación y revisión (MRO) en el sector de la aviación, podría ser un flujo de trabajo de autorización de mantenimiento vinculado a un proceso responsable según la Parte 145 de la EASA. Se trata de la configuración de seguridad, ya que es la que define quién puede ver, modificar, exportar o automatizar esos registros.

Salesforce cuenta con sólidas funciones de seguridad listas para usar. Sin embargo, Salesforce no deducirá tus matrices de separación de funciones (SoD), estrategias de retención ni límites de confianza de integración. Todo eso forma parte del diseño contextual, que se basa en cómo se desarrolla el trabajo en Sales Cloud, Service Cloud, Financial Services Cloud, Health Cloud o en tu aplicación personalizada de Salesforce.

Guía de seguridad de Salesforce: Empieza por el flujo de trabajo

La mayoría de las iniciativas de seguridad en Salesforce lo confunden con una jornada de limpieza de perfiles. Claro, los perfiles, los conjuntos de permisos y la autenticación de dos factores (MFA) son importantes. Sin embargo, un diseño de seguridad de Salesforce que se pueda defender empieza por el flujo de trabajo: desde la recepción hasta la toma de decisiones y el archivo.

En un flujo de trabajo de suscripción de seguros comerciales de Financial Services Cloud, un asistente podría introducir los datos de la solicitud, un suscriptor evaluar el riesgo, un suscriptor sénior aprobar una excepción y el departamento de operaciones formalizar la póliza. Se necesitan diferentes combinaciones de acceso a los registros, visibilidad a nivel de campo, permisos de edición y autoridad de aprobación. Además, el flujo de trabajo debería impedir que un usuario modifique un campo de riesgo y, al mismo tiempo, apruebe la excepción creada por ese cambio en el campo.

Esa es una cuestión de separación de funciones, no de conjuntos de permisos. Las aseguradoras, como las que se rigen por Solvencia II, exigen gobernanza y trazabilidad en la toma de decisiones importantes. En Salesforce, eso suele significar combinar las decisiones sobre la jerarquía de roles con OWD, las reglas de compartición, los grupos de conjuntos de permisos, las reglas de restricción y el diseño de los procesos de aprobación. La fórmula depende del modelo operativo. Una oficina de suscripción centralizada tiene requisitos de acceso diferentes a los de los equipos de suscripción regionales con autoridad delegada.

Antes de modificar los permisos de acceso, ten en cuenta lo siguiente:

• ¿Qué registros contienen datos regulados, sensibles o sujetos a restricciones comerciales?
• ¿Qué campos pueden influir en una decisión, un pago, una puntuación de riesgo o el estado de cumplimiento?
• ¿Qué roles inician, revisan, aprueban y dan luz verde al trabajo?
• ¿Qué sistemas externos leen o escriben en el registro?
• ¿Qué acciones requieren un historial auditable y durante cuánto tiempo debe conservarse ese historial?

Deberás tener un diseño de controles que podrán revisar los equipos de TI, seguridad, cumplimiento normativo y el propio negocio. Si no, cometerás el error habitual de que un conjunto amplio de permisos creado para una situación puntual de puesta en marcha se convierta en una excepción permanente.

Seguridad en Salesforce: configura el acceso a partir de conjuntos de permisos, no de puestos de trabajo

Los perfiles de Salesforce deben ser concisos. Estos definen el acceso básico, mientras que los conjuntos de permisos y los grupos de conjuntos de permisos establecen los derechos necesarios para un rol operativo concreto. Así resulta más fácil revisar, probar y revocar el acceso cuando a alguien le cambian las responsabilidades del puesto.

Por ejemplo, un gestor de reclamaciones podría editar los campos de evaluación de reclamaciones en Service Cloud, pero no modificar las instrucciones de pago ni exportar una cartera de reclamantes. Un supervisor de reclamaciones podría aprobar excepciones de pago, pero no modificar el resultado de la validación de la cuenta bancaria subyacente. No se trata solo de seguridad a nivel de campo. También incluye reglas de validación, pasos de aprobación y acceso a los registros.

Ningún control por sí solo puede sustituir a los demás. Los grupos de conjuntos de permisos resultan especialmente útiles cuando un rol incluye varias funciones; por ejemplo, un responsable de suscripción con conjuntos de permisos estándar de suscripción y capacidad de aprobación controlada. Usa los conjuntos de permisos silenciados con prudencia. Aunque pueden reducir los derechos efectivos de un grupo de conjuntos de permisos, los conjuntos de permisos excesivamente silenciados hacen que las revisiones de derechos sean más difíciles de entender.

Vale la pena prestar atención a las reglas de restricción en las organizaciones donde los usuarios tienen un amplio acceso a los objetos, pero una visibilidad limitada desde el punto de vista operativo. Estas reglas limitan los registros que un usuario puede ver, independientemente de la jerarquía de roles. Son útiles cuando, por ejemplo, los peritos solo pueden ver los siniestros asignados a su unidad operativa. Sin embargo, no son motivo para evitar un modelo de uso compartido sensato. Pruébalas con informes, vistas de lista, acceso a la API y los paquetes gestionados específicos que estés utilizando.

La certificación de acceso trimestral debería evaluar el acceso real, no solo los conjuntos de permisos asignados. Lo que quieres saber es si un usuario puede llevar a cabo una acción inadecuada en el flujo de trabajo, no si la matriz de roles parece estar en orden.

Seguridad en Salesforce: protege los datos confidenciales sin afectar al funcionamiento

La HIPAA, el RGPD, la norma PCI DSS y las normas GxP no exigen lo mismo. Clasificarlos todos como «datos confidenciales» da lugar a controles poco eficaces y a auditorías difíciles de responder.

En una implementación de Health Cloud sujeta a la HIPAA, la información sanitaria protegida debe clasificarse a nivel de campo, con una decisión documentada sobre si ese campo debe ocultarse, cifrarse, tener acceso restringido, contar con un historial de auditoría o excluirse de cualquier análisis posterior. La clasificación de datos te ayuda a hacer un inventario de todo eso, pero las etiquetas de clasificación no son controles.

El cifrado de la plataforma Salesforce Shield puede ser adecuado para campos que contengan identificadores confidenciales, datos clínicos o información financiera. Debes definir su alcance en función del comportamiento real que necesites en los informes, las búsquedas, las integraciones, los campos de fórmula y cualquier proceso posterior. No es solo marcar una casilla. Un campo que ya no admita un proceso de coincidencia de operaciones puede hacer que los usuarios recurran a hojas de cálculo y generar un problema de control mucho mayor que el diseño inicial de Salesforce.

En los flujos de trabajo GxP validados, la configuración de seguridad debe formar parte del estado validado. Eso significa que los requisitos, la evaluación de riesgos, la documentación de la configuración, los guiones de prueba, los registros de aprobación y el control de cambios deben abarcar la configuración de seguridad que protege los registros electrónicos. Si un usuario de operaciones clínicas puede modificar un hito del centro tras su aprobación, necesitas pruebas que indiquen quién lo hizo, por qué, qué se modificó y si la modificación activó la revisión necesaria.

El historial de auditoría de campos puede cubrir los requisitos de auditoría a largo plazo cuando la retención estándar del historial de los campos no es suficiente. Define bien el alcance de la auditoría. Auditar todos los campos de todos los objetos supone un coste y una sobrecarga innecesaria. Si solo se auditan los campos clínicos o financieros más obvios, es posible que se pasen por alto los cambios de estado que explican por qué se tomó una decisión.

Seguridad en Salesforce: trata las integraciones como si fueran usuarios con privilegios

La mayoría de los incidentes de exposición en Salesforce se originan fuera de la interfaz de usuario de Salesforce. Una integración que se ejecute con permisos amplios de API puede socavar las cuidadosas matrices de permisos integradas en Salesforce para los usuarios humanos.

Cada integración debería tener un responsable de negocio, un responsable técnico y un usuario dedicado a la integración, además de un método de autenticación definido y unos permisos mínimos para objetos, campos y API. Las aplicaciones conectadas deberían evaluarse en cuanto a los ámbitos de OAuth, los usuarios autorizados, las restricciones de IP cuando sea necesario, el ciclo de vida de los tokens y si la integración puede actuar en nombre de usuarios individuales.

Imagina un flujo de trabajo de ejecución de la fabricación en el que una aplicación personalizada envía datos sobre la finalización de lotes a Manufacturing Cloud. Es posible que la interfaz tenga que crear registros de producción y actualizar el estado de las excepciones. No debería tener acceso general a los datos de la cuenta, a las previsiones comerciales ni a los casos de servicio no relacionados, simplemente porque esos objetos existan en la misma organización.

La supervisión de eventos proporciona información sobre llamadas a la API, exportaciones, acceso a informes y patrones anómalos que los registros estándar quizá no muestren con claridad. El objetivo no es tener más datos de telemetría, sino detectar eventos que merezcan una respuesta: una exportación masiva y repentina de historiales de pacientes, una integración que llama a un punto final por encima del volumen esperado o una cuenta de servicio que accede a objetos fuera de su ámbito declarado.

Seguridad de Salesforce: integra la IA dentro del mismo perímetro de control

Las funciones de IA de Salesforce, como Einstein y las integraciones de IA de terceros, suponen una decisión adicional sobre el tratamiento de datos. No se trata de si un modelo puede resumir un caso o redactar una respuesta. Se trata de qué datos se introducen en el modelo, qué puede recuperar el modelo, quién puede actuar en función de sus resultados y cómo puede la organización auditar un error.

En el flujo de trabajo de un servicio sanitario, el resumen de un caso debe respetar los mismos controles de acceso a nivel de campo y de intercambio que el registro subyacente. En un flujo de trabajo de servicios financieros, los siguientes pasos generados por la IA no deberían saltarse una matriz de aprobación ni crear una recomendación que no se pueda explicar a un supervisor. Según la Ley de IA de la UE, la clasificación y los requisitos dependen del caso de uso, pero la gobernanza debería empezar antes de la implementación, no después de que un regulador pida pruebas.

Utiliza fuentes de datos contrastadas, búsquedas delimitadas, registro de comandos y resultados cuando esté permitido, y aprobación humana para las acciones que tengan consecuencias importantes. La IA está bien para resumir un historial de servicios complejo o identificar solicitudes incompletas. Sin embargo, no es tan adecuada como responsable de la toma de decisiones sin supervisión en casos de denegación de reclamaciones, elegibilidad para la suscripción de seguros o cambios en un estado clínico regulado.

Seguridad en Salesforce: haz que la seguridad sea operativa tras la puesta en marcha

La seguridad falla cuando se convierte en un mero ejercicio anual de hojas de cálculo, desconectado de los lanzamientos, las adquisiciones, las nuevas integraciones y las correcciones urgentes en producción. Necesitas un modelo operativo con responsabilidades claras entre la administración de Salesforce, la seguridad, la arquitectura empresarial, el cumplimiento normativo y el responsable del proceso.

Mide un pequeño conjunto de controles para comprobar si el diseño funciona, como cuentas con privilegios inactivas, revisiones de acceso vencidas, cambios en los conjuntos de permisos sin tickets aprobados, autenticaciones de integración fallidas y eventos de exportación masiva investigados dentro del plazo de respuesta acordado. Mide también los cambios en producción con pruebas completas. Las métricas adecuadas dependen del flujo de trabajo, pero deberían poder observarse sin tener que preparar un informe de auditoría manual cada trimestre.

Para las organizaciones que llevan a cabo operaciones complejas y reguladas, el objetivo de la tecnología es hacer que la vía segura sea la más práctica para los evaluadores de riesgos, los profesionales clínicos, los planificadores y los equipos de servicio. Si los controles crean obstáculos innecesarios sin proteger una decisión o un conjunto de datos reales, hay que rediseñarlos. Si un control protege un flujo de trabajo de alto impacto, asegúrate de que la responsabilidad, la documentación y el proceso de excepciones estén claros antes de la próxima actualización.