Trust

En Salesforce, Trust es nuestro valor número 1. Es la base de cada decisión arquitectónica en la plataforma. Para los arquitectos, Trust se logra a través de una asociación exclusiva: Salesforce proporciona una plataforma segura y compatible (la infraestructura, los metadatos y las herramientas para hacerla suya) mientras diseña soluciones seguras que se basan en esa base.

Esta asociación funciona a través del Modelo de responsabilidad compartida, que es un marco que divide claramente las responsabilidades de seguridad:

• Salesforce es responsable de la seguridad de la plataforma, incluyendo certificaciones de infraestructura, parches y cumplimiento.
• Usted es responsable de la seguridad en la plataforma, incluyendo la configuración, los controles de acceso, el código personalizado y la regulación de datos.

Esta división es esencial porque define la responsabilidad arquitectónica. Salesforce opera una arquitectura de múltiples arrendatarios donde miles de organizaciones comparten infraestructura. La plataforma proporciona fuertes protecciones de seguridad a nivel de infraestructura. Sus decisiones de arquitectura determinan si sus soluciones específicas se ganan la confianza de las partes interesadas.

El Modelo de responsabilidad compartida le pone a cargo del diseño de soluciones seguras mientras que la seguridad física, la protección de red, el parcheo de plataforma y el cifrado de infraestructura se gestionan por usted. Esto le permite centrarse en el diseño de soluciones seguras creadas sobre esa base (por ejemplo, gestión de identidad y acceso, protección de datos, seguridad de integración, prácticas de desarrollo seguras, cumplimiento y adhesión a la normativa y funciones de respuesta ante incidentes).

Neglecting Trust durante la deuda técnica de compuestos de diseño. Una estrategia de cifrado que falta se convierte en una actualización costosa cuando cambian las leyes. Una integración no gobernada se convierte en una vulnerabilidad cuando las credenciales están comprometidas. Crear Trust desde el principio es consistentemente menos costoso que actualizarlo más adelante.

Trust abarca cuatro dimensiones arquitectónicas que funcionan juntas de forma cohesionada:

• Los controles de seguridad protegen sistemas y datos
• Gestión de identidad rige el acceso
• Las prácticas de privacidad respetan la agencia de usuarios
• Los marcos de cumplimiento satisfacen obligaciones regulatorias

Los arquitectos que diseñan para las cuatro dimensiones crean soluciones que ganan y mantienen Trust a través de transparencia, control y resiliencia.

En la Era Agente, Trust se extiende al contexto de confianza en el que operan los agentes. Contexto de confianza significa que los agentes acceden a datos gobernados y verificados con límites de permisos e identidad claros, lo que permite a los sistemas de IA razonar y actuar en nombre de los usuarios manteniendo al mismo tiempo la seguridad, la capacidad de auditoría y el cumplimiento. El diseño de contexto de confianza es fundamental para la arquitectura de Agentic Enterprise.

Este pilar establece la línea base de seguridad de plataforma de la que depende cada solución de Salesforce. El pilar Agentic Trust se basa en esa línea base para abordar riesgos exclusivos de agentes autónomos, incluyendo inyección rápida, gobernanza de acciones y los datos a los que los agentes pueden acceder durante los tiempos de razonamiento. Es importante diseñar la línea base primero, luego aplicar capas a los controles específicos de los agentes utilizando las directrices de Agentic Trust.

Este pilar está profundamente relacionado con otras preocupaciones del marco.

• La fiabilidad depende de la infraestructura que resiste ataques y se recupera de brechas.
• Operational Excellence requiere oportunidades en curso de implementación seguras y funciones de respuesta ante incidentes.
• La equidad exige la gestión transparente y ética de los datos y las decisiones algorítmicas.

Juntos, estos pilares forman un enfoque unificado centrado en soluciones en el que las organizaciones pueden Trust con sus operaciones más confidenciales.

En el Modelo de Responsabilidad Compartida, Salesforce y los arquitectos deben cumplir sus respectivas responsabilidades para mantener Trust. Echemos un vistazo más de cerca a lo que cada parte debe asegurar.

Salesforce es responsable de proteger la plataforma y su infraestructura global, incluyendo:

• Controles de acceso al centro de datos, vigilancia y salvaguardas medioambientales
• Para Hyperforce, el proveedor de nube subyacente (por ejemplo, AWS, Azure o Google Cloud, dependiendo de la instancia) gestiona la seguridad física del centro de datos a través de la responsabilidad delegada. La documentación Infraestructura y subprocesadores de Salesforce identifica el proveedor y los subprocesadores para cada servicio.

• Controles de seguridad de capa de red, incluyendo protección DDoS y detección de amenazas
• Cifrado de tráfico en tránsito (TLS 1,2+) y en reposo (normalmente AES-256)

• Implementación de parches de plataforma y respuesta a vulnerabilidades a través de Salesforce (para obtener más información sobre avisos de seguridad, visite security.salesforce.com)
• Gestión de la seguridad del sistema operativo y la infraestructura

• Certificaciones y certificaciones: Salesforce mantiene la autorización SOC 1/2/3, ISO 27001/27017/27018, FedRAMP (se aplica a Government Cloud Plus y MuleSoft Government Cloud, no a la plataforma comercial multiusuario) y la validación PCI DSS Nivel 1.
• Compatibilidad normativa: Esto se aplica a servicios aptos para HIPAA con Acuerdos de asociados de negocio (BAA) o programas de cumplimiento de RGPD.
• Para obtener más información, visite trust.salesforce.com y compliance.salesforce.com.

• Arquitectura de aislamiento de arrendatarios: Un núcleo compartido dirigido por metadatos particiona los datos y metadatos de cada organización por Id. de organización, de modo que una organización no puede alcanzar los registros de otra organización aunque se ejecuten en infraestructura compartida. El núcleo aplica la separación en cada consulta, no a través de una configuración que debe mantener.
• Cifrado a nivel de infraestructura en tiempo de inactividad e infraestructura de copia de seguridad: Las licencias de plataforma base incluyen Cifrado clásico (AES-128 proporciona únicamente campos de texto personalizados). Shield Platform Encryption requiere una licencia separada (AES-256 le permite aportar su propia clave y proporciona campos, archivos y archivos adjuntos estándar y personalizados).

Estos controles garantizan que la plataforma sigue siendo segura, fiable y compatible.

Usted es responsable de proteger sus datos, configuraciones y procesos operativos.

• Identidad y federación: Para el inicio de sesión único (SSO) y la autenticación de múltiples factores (MFA), debe verificar la identidad del usuario.
• Restricción de acceso: Técnicamente, los intervalos de IP y las horas de inicio de sesión restringen cómo y cuándo se conectan las identidades.
• Principio de menor privilegio (PoLP): Utilice el PoLP para otorgar acceso únicamente para funciones, perfiles y conjuntos de permisos necesarios para realizar tareas de trabajo individuales.
• Gestión del ciclo: de vida Practique la gestión del ciclo de vida de los usuarios y acceda a directrices de recertificación.

• Utilizar clasificación de datos, enmascaramiento y seguridad a nivel de objeto/campo/registro
• Aplicar permisos CRUD y reglas de colaboración
• Posee, pruebe e implemente una estrategia probada para restaurar los datos de su organización, garantizando que la pérdida de datos o la recuperación de daños permanece bajo su control.

• Utilice la autenticación de API (por ejemplo, OAuth 2.0 o JWT) y credenciales nombradas.
• Active usuarios de integración exclusivos con conjuntos de permisos PoLP de modo que el acceso de cada integración tenga ámbito y pueda auditarse por separado de los usuarios humanos.
• Extremos seguros y validación del sistema externo.

• Utilice Monitoreo de eventos, seguimientos de auditoría e integración de Información de seguridad y Gestión de eventos (SIEM).
• Siga los procedimientos de respuesta ante incidentes y las revisiones de seguridad.

• Utilice código personalizado seguro (por ejemplo, Apex o Lightning) y validación de entrada.
• Ejecute Apex en modo de usuario de modo que los permisos de objeto, campo y colaboración se apliquen en código.
• Siga las prácticas de prevención de inyección y desarrollo seguro.

• Mantenga la postura de cumplimiento de soluciones.
• Siga las políticas de privacidad/gestión de consentimiento y retención de datos.

Algunas responsabilidades requieren colaboración:

• Respuesta ante incidentes de seguridad: Ambas partes participan en actividades de detección y respuesta.
• Gestión de vulnerabilidades: Salesforce parchea la plataforma, los arquitectos parchean código personalizado.
• Monitoreo de seguridad: Combine señales de seguridad generadas por plataforma con análisis de arquitecto.
• Certificaciones de cumplimiento: Salesforce certifica la plataforma (por ejemplo, SOC, ISO y FedRAMP para Government Cloud); los arquitectos son propietarios de lo que está construido en ella (objetos personalizados, código, integraciones y configuración) dentro de la postura certificada para proporcionar pruebas de cumplimiento para auditorías.
• Federación de identidad: Salesforce confía en las afirmaciones que emite el proveedor de identidad del arquitecto; los arquitectos mantienen la seguridad del proveedor y la relación Trust entre el proveedor y Salesforce.
• Gestión de claves: Utilizando cifrado de traer su propia clave, Salesforce opera el servicio de cifrado mientras los arquitectos generan, rotan y revocan el material de claves que protege los datos.

Cada principio de diseño, sección de tema y elemento de lista de selección en este documento representa su responsabilidad como arquitecto. El Modelo de responsabilidad compartida enmarca lo que debe diseñar y configurar para lograr Trust en Salesforce Platform.

El límite se amplía a obligaciones regulatorias. Salesforce mantiene las certificaciones y certificaciones de la plataforma y protege la infraestructura frente a infracciones. Los arquitectos son responsables de las obligaciones adjuntas a sus datos y jurisdicción (por ejemplo: qué leyes se aplican, cómo se clasifican los datos, qué reglas de retención y consentimiento los rigen y cómo detecta y reporta infracciones de los datos bajo su control). Frente a las leyes que rigen sus implementaciones, los arquitectos deben determinar las cifras específicas detrás de esas obligaciones (por ejemplo, periodos de retención y plazos de notificación), frente a la ley que rige su implementación, porque pueden variar por jurisdicción y cambiar con el tiempo.

Utilice estos principios para guiar sus decisiones de arquitectura para la seguridad en la plataforma.

• Aplique zero Trust en todas las capas. Nunca asuma Trust basándose en la ubicación de red, la familiaridad del usuario o el origen del sistema. Verifique cada solicitud de acceso de forma explícita con autenticación, autorización y cifrado en las capas de datos, aplicación, integración e infraestructura. La arquitectura de múltiples arrendatarios significa que comparte infraestructura con miles de organizaciones, de modo que la red en la que se ejecuta su solución no es un perímetro que pueda tratar como de confianza. Verifique cada solicitud por sus propios méritos (identidad, autorización y contexto) en vez de confiar en ella para el lugar donde se originó.
• Otorgue el menor privilegio de forma predeterminada. Otorgue el nivel mínimo de acceso necesario para que cada usuario, integración y proceso automatizado alcance su propósito. Comience con la configuración más restrictiva (predeterminados de toda la organización privados (OWD) y permisos mínimos) y amplíe deliberadamente basándose en requisitos de negocio documentados. Utilice el modelo de acceso de cuatro capas (organización → objeto → campo → registro) de modo que cada capa restrinja aún más las capas anteriores.
• Implemente defensa en profundidad. Aplique múltiples controles de seguridad de modo que el fallo de un control no comprometa todo el sistema. Combine controles preventivos (por ejemplo, aplicación CRUD/FLS y políticas de Seguridad de transacciones que bloquean operaciones), controles de detectives (por ejemplo, Monitoreo de eventos) y controles con capacidad de respuesta (por ejemplo, autenticación y notificación de intensificación de Seguridad de transacciones). Diseñe cada capa como si las capas adyacentes pudieran fallar. Recuerde que la seguridad a nivel de campo protege los datos incluso cuando las reglas de colaboración son demasiado permisivas.
• Integre la seguridad por diseño. Integre el modelado de amenazas, los requisitos de seguridad y la validación de control en cada fase de la arquitectura desde el concepto inicial hasta la evolución continua. Dirija el modelado de amenazas Suplantación, Manipulación, Repudio, Revelación de información, Denegación de servicio y Elevación de privilegios (STRIDE) antes de que comience la construcción. La seguridad da forma a la selección de tecnología y las decisiones de diseño.
• Integre la seguridad en la automatización. Construya controles de seguridad en oportunidades en curso automatizadas, plantillas de configuración y valores predeterminados de plataforma. Salesforce Code Analyzer en CI/CD detecta vulnerabilidades antes de la implementación. Configuración como código aplica líneas base de seguridad. La seguridad integrada garantiza la coherencia y permite que la seguridad se amplíe con la complejidad de la solución.
• Diseño para privacidad. Incorpore principios de privacidad desde la fase de arquitectura inicial. Diseño para la minimización de datos (solo recopilar los datos necesarios), limitación de propósitos (restringir el acceso por función de trabajo), gestión de consentimiento (aplicar el consentimiento granular específico de propósito) y derechos de titulares de datos (permitir que los flujos de trabajo de acceso, rectificación, borrado y portabilidad se completen en plazos reglamentarios).
• Diseño para trazabilidad. Haga que cada acción resultante sea atribuible y reconstruible después del hecho, antes de basarse en la detección de anomalías en ella. Asegúrese de que los cambios en datos, permisos y configuración se capturan en seguimientos de auditoría, historial de campos y registros de eventos, y mantenga esos registros en almacenamiento resistente a manipulaciones. La trazabilidad es la condición previa para la detección, los análisis forenses y la rendición de cuentas. Recuerde: no puede investigar lo que nunca se registró.
• Diseño para la respuesta ante incidentes. Diseño para la detectabilidad a través de Monitoreo de eventos y para la intervención en tiempo real a través de políticas de Seguridad de transacciones. Active la respuesta rápida a través de procedimientos documentados y límites de aislamiento. Apoye la recuperación a través de funciones de copia de seguridad y preservación forense. Pruebe respuestas a través de ejercicios de sobremesa y simulaciones de brechas.

Los arquitectos son responsables de proteger las soluciones en la plataforma que proporciona Salesforce.

Las cargas de trabajo que interactúan con Salesforce se ejecutan cada vez más fuera de la plataforma principal: los servicios de integración, las aplicaciones personalizadas y los clientes desatendidos suelen llamar a las API de Salesforce, a menudo en nombre de un usuario. Para acelerar este patrón, Salesforce expone las funciones de la plataforma como API, herramientas y comandos (por ejemplo, Salesforce Headless 360). Independientemente de quién opere estas aplicaciones, el arquitecto es propietario del Trust Border donde se encuentran con Salesforce para determinar cómo se autentican, qué identidad y permisos portan, qué secretos guardan y qué datos cruzan el límite.

Los siguientes principios se aplican a cualquier plataforma de integración en contenedores (por ejemplo, MuleSoft CloudHub).

Cuando un cliente externo se autentica como un usuario nombrado, el modelo de seguridad de plataforma de Salesforce se aplica automáticamente: los permisos de objeto, la seguridad a nivel de campo y las reglas de colaboración se aplican exactamente como están en el navegador. La autenticación por usuario define el ámbito de cada llamada a los permisos de ese individuo y mantiene el seguimiento de auditoría, lo que significa que la revocación del token de un usuario elimina inmediatamente la capacidad del cliente de actuar en su nombre. Prefiera esto sobre una cuenta de servicio compartida dondequiera que se realice el trabajo para un usuario específico.

Diseñe el límite de forma defensiva, porque un cliente que tiene tokens para muchos usuarios concentra Trust y se convierte en un proxy de alto valor para un atacante: un único token de OAuth robado puede alcanzar datos entre cada usuario al que sirve el cliente. Esto no es hipotético. El incidente de deriva de Salesloft de 2025 vio a atacantes robar tokens de OAuth y utilizarlos para alcanzar datos de Salesforce entre cientos de organizaciones.

• Propagar la identidad de usuario, no la agrupe. Utilice la autenticación por usuario o el intercambio de tokens de OAuth 2.0 para llevar la identidad de un usuario entre saltos de servicio (consulte Autenticación e identidad de agente), de modo que los compromisos tengan ámbito al contexto de un usuario en vez de a todos ellos.
• Trate credenciales de cliente de OAuth y tokens de actualización como el destino principal. Almacénelos en un establecimiento de secretos gestionados, rótelos con frecuencia y mantenga diseños para su revocación inmediata. Monitoree el uso de API para los patrones anómalos que señalan a un atacante proxy.
• Minimice el ámbito en ambos lados. Restrinja los ámbitos de OAuth de la aplicación cliente externa (ECA) y los permisos de Salesforce del usuario de integración al mínimo que requiere la función, de modo que un cliente comprometido no pueda cambiar a datos no relacionados.
• Gobierne el límite a través de Aplicaciones cliente externas. Los ECA definen cómo se autentica una aplicación externa, qué flujos se permiten y qué ámbitos se aplican: diseñe nuevas integraciones en su contra (consulte Arquitectura de autenticación).

Tenga cuidado cuando un cliente se ejecuta como un Usuario agente o Usuario de integración: esas identidades pueden operar en un contexto elevado (a menudo en sistemas externos que no respetan los controles de acceso de Salesforce), de modo que el uso de la disciplina de permisos y monitoreo descrita anteriormente es lo que mantiene ese poder vinculado.

Cuando las integraciones se ejecutan en una plataforma en contenedores, el aislamiento a nivel de contenedor se considera en sí un control de seguridad: cada aplicación se ejecuta en un contenedor exclusivo sin tiempo de ejecución compartido o memoria entre aplicaciones.

Este aislamiento proporciona:

• Aplicación de límites de arrendatario: Las aplicaciones comprometidas no pueden acceder a datos o recursos desde aplicaciones vecinas que comparten el mismo entorno. Cada contenedor tiene un sistema de archivos y un espacio de proceso aislados. Aplique el aislamiento de red a través del cortafuegos y la configuración TLS, y restrinja explícitamente el tráfico saliente en vez de basarse en valores predeterminados permisivos.
• Defensa en profundidad: El aislamiento de contenedores agrega una capa de seguridad más allá de los controles a nivel de aplicación. Incluso si el código de aplicación tiene vulnerabilidades, los límites de contenedor limitan el radio de explosión.
• Segmentación de cumplimiento: Las cargas de trabajo reguladas (por ejemplo, PCI e HIPAA) pueden aislarse en contenedores exclusivos, evitando la mezcla con cargas de trabajo no compatibles.

Los arquitectos que están diseñando entornos de múltiples aplicaciones deben basarse en el aislamiento de contenedores para aplicar la separación de funciones y dominios de seguridad. Las integraciones de servicios financieros que gestionan datos de titulares de tarjetas deben ejecutarse en contenedores separados de las integraciones de marketing, incluso en el mismo entorno.

El tráfico entre contenedores debe cifrarse y debe aplicarse el TLS mutuo (mTLS) cuando un marco regulador requiera autenticación en ambos lados:

Cómo funciona:

• Configure contextos TLS para activar TLS mutua opcional (mTLS) para conexiones entrantes cuando sea necesario.
• Utilice SSL a nivel de plataforma con autenticación de certificado de cliente para proteger la comunicación entre servicios de plataforma y réplicas.
• Configure contextos TLS para activar mTLS cuando lo requieran los marcos reguladores.
• Gestione certificados a través del establecimiento de certificados de la plataforma de modo que el ciclo de vida y la revocación permanezcan centralizados.
• Aplique límites de aislamiento de red que evitan el tráfico no autorizado entre contenedores.

Cifrar el tráfico en la capa de plataforma proporciona defensa en profundidad para datos en tránsito. Incluso si el HTTPS de la capa de aplicación está mal configurado, el tráfico de contenedores permanece cifrado.

Los contenedores que se conectan a sistemas locales a través de VPN deben diseñar para la protección de datos en tránsito:

• Cifrado de túnel: Enrute todo el tráfico entre contenedores y sistemas locales a través de túneles VPN cifrados. Esto se aplica independientemente del TLS de la capa de aplicación. Defensa en profundidad garantiza que haya doble cifrado para datos confidenciales.
• Aplicación de segmentación de red: Las políticas de túnel VPN restringen a qué redes locales pueden llegar los contenedores. Los contenedores comprometidos no pueden cambiar a sistemas internos no autorizados más allá de las redes permitidas por VPN.
• Evidencia de cumplimiento: El cifrado VPN es uno de los mecanismos aceptados para proteger datos en tránsito hacia y desde entornos de nube. Los auditores que revisan los controles HIPAA, PCI-DSS o SOX esperan cifrado documentado en tránsito para integraciones híbridas.

Los arquitectos deben diseñar políticas de VPN que apliquen el acceso de red de menor privilegio. Los contenedores de integración de marketing no deben enrutar a sistemas financieros internos incluso si ambos son accesibles a través de VPN.

Los dominios vanidosos (por ejemplo, direcciones URL personalizadas para API de integración) requieren que los arquitectos gestionen certificados TLS como Trust anchors:

Los dominios vanidosos (por ejemplo, direcciones URL personalizadas para API de integración) requieren que los arquitectos gestionen certificados TLS como Trust anchors.

• Automatización del ciclo de vida de certificados: Implemente la renovación e implementación automatizadas de certificados. Los certificados caducados rompen la Trust de integración; los clientes rechazan conexiones con errores de validación de certificados.
• Planificación de revocaciones de certificados: Diseñe procedimientos de rotación de certificados para incidentes de seguridad. Las claves privadas comprometidas requieren una rápida reexpedición e implementación de certificados en todas las regiones.
• Configuración de conjunto de cifrado: Las configuraciones TLS más antiguas (TLS 1.0/1.1 y cifrados débiles) no superan las auditorías de cumplimiento. Aplique TLS 1.2+ (requisito mínimo) y alinee configuraciones de certificados y clientes con políticas de seguridad organizativas.
• Registro de transparencia de certificado: Los certificados TLS modernos se envían a registros públicos de Transparencia de certificados (CT) por Autoridades de certificados (CA). Cada registro de TC devuelve una Marca de tiempo de certificado firmado (SCT), una prueba criptográfica de registro, que el CA incrusta en el certificado a través de una extensión X.509v3. Los arquitectos deben monitorear los registros de TC para la emisión de certificados no autorizados en sus dominios, utilizando servicios como crt.sh o alertas automatizadas.

La mala gestión de certificados afecta directamente a la postura Trust:

• Certificados caducados: Provoca fallos de autenticación que aparecen como cortes. El monitoreo debe incluir el envío de alertas en un plazo de más de 30 días antes del vencimiento para permitir que comiencen los flujos de trabajo de renovación.
• Certificados autofirmados: Rompa cadenas Trust para clientes externos. Las integraciones de producción requieren certificados firmados por autoridades de certificados (CA) de confianza.
• Extensión de certificado comodín: Hace referencia a certificados comodín demasiado anchos (por ejemplo, *.company.com) que crean un gran radio de explosión si están comprometidos. Se prefieren certificados de ámbito estrecho por dominio de integración.

Las regiones de implementación de contenedores deben alinearse con los requisitos de cumplimiento y residencia de datos.

• Residencia de datos de RGPD: El RGPD requiere una protección adecuada para los datos personales que salen de la Unión Europea (UE), pero no la implementación de la UE como tal. La implementación de integraciones en una región de la UE mantiene la computación de contenedores y el procesamiento de datos dentro de los límites normativos, que es la forma más directa de satisfacer este requisito. Las transferencias que se produzcan fuera de la UE seguirán siendo admisibles en virtud de una decisión de adecuación, cláusulas contractuales estándar o reglas corporativas vinculantes.
• Leyes de localización de datos: Los países con requisitos de localización de datos incluyen: Rusia (Ley Federal 152-FZ y almacenamiento obligatorio) y China (PIPL/CSL para CIIO), que podrían requerir la implementación de contenedores en el país. La Ley PDDP de 2023 de India utiliza un enfoque de lista negra que no impone un mandato general de almacenamiento en el país. Las transferencias de datos se permiten a cualquier país a menos que se restrinjan específicamente por una notificación gubernamental. Los arquitectos deben comprender las leyes específicas de la jurisdicción.
• Mecanismos de transferencia transfronteriza de datos: Cuando se requiere una implementación multirregional, pero los datos deben cruzar fronteras, los arquitectos deben implementar SCC, BCR u otros mecanismos de transferencia legal.
• Alineación de certificación de cumplimiento: Las regiones de implementación de contenedores deben coincidir con las certificaciones de cumplimiento de Salesforce. Las cargas de trabajo autorizadas por FedRAMP requieren implementación regional de EE.UU. Para integraciones certificadas por HITRUST, debe verificar que la región de implementación recae en un ámbito de certificación HITRUST activo.

Las decisiones de implementación regionales son responsabilidades de arquitecto que afectan directamente al cumplimiento normativo. Los equipos de finanzas pueden ordenar la implementación solo de EE.UU. para integraciones controladas por SOX. Los equipos sanitarios pueden requerir regiones certificadas por HITRUST para procesar información de salud personal (PHI).

Los contenedores requieren acceso a credenciales, claves de API y claves de cifrado. Los arquitectos deben diseñar procesos de gestión de secretos que eviten la exposición:

• Sin secretos codificados: Nunca incruste credenciales en archivos de configuración o código de aplicación implementados en contenedores. Utilice establecimientos de secretos gestionados por plataforma.
• Inyección de secretos gestionados por plataforma: Resuelva secretos en tiempo de ejecución desde el establecimiento gestionado de la plataforma (en vez de mantenerlos en el sistema de archivos), y marque valores de configuración que tengan credenciales como protegidas de modo que no se expongan en registros o en la consola.
• Rotación de secretos: Diseñe integraciones para gestionar secretos rotados con gracia. Los patrones de actualización de tokens de OAuth, los flujos de trabajo de rotación de claves de API y los cambios de contraseña de base de datos no deben requerir la redistribución de contenedores.
• Acceso a secretos de menor privilegio: Otorgue a los contenedores acceso únicamente a los secretos requeridos para su función. Las integraciones de marketing no deben acceder a credenciales del sistema financiero incluso cuando comparten el mismo entorno.

Los secretos expuestos son incidentes de seguridad de integración comunes. Los arquitectos deben diseñar secretos que gestionan procesos que pueden sobrevivir a revisiones de código, registros, mensajes de error y tableros de monitoreo sin perder credenciales.

Las aplicaciones en el límite de Salesforce generan eventos de auditoría que satisfacen los requisitos de registro de cumplimiento:

• Registro de solicitudes/respuestas: Registra solicitudes de API, respuestas y decisiones de enrutamiento. Los equipos de cumplimiento utilizan estos registros para auditorías de acceso para determinar quién accedió a qué datos en qué momento.
• Registro de errores y excepciones: Captura eventos de seguridad (por ejemplo, fallos de autenticación, denegaciones de autorización y certificados no válidos) en los registros del contenedor. La integración de SIEM permite el monitoreo de seguridad en tiempo real.
• Políticas de retención de registros: Los arquitectos deben configurar periodos de retención que cumplan los requisitos normativos. Esos mínimos se establecen por normativa, varían por marco y cambian con el tiempo, de modo que deben derivarlos de un origen de cumplimiento bien mantenido que verifique cada cifra con la normativa vigente en vez de valores de codificación.
• Registrar cifrado y controles de acceso: Los registros de auditoría pueden contener metadatos confidenciales. Los registros deben cifrarse en periodos de inactividad y controlarse el acceso únicamente al personal de seguridad/cumplimiento autorizado. El registro insuficiente evita la investigación de incidentes y falla las auditorías de cumplimiento. Los arquitectos deben equilibrar la verbosidad del registro (por ejemplo, impacto en el desempeño y costos de almacenamiento) con las necesidades de investigación de cumplimiento y seguridad.

El modelado de amenazas debe formar parte del diseño de sus soluciones, en vez de un paso separado que se produce antes o después. En cuanto tenga un diseño candidato sobre el que razonar, debe modelar sus posibles amenazas y volver a visitar el modelo a medida que evoluciona el diseño, de modo que la seguridad moldee la arquitectura en vez de actualizarse en ella. Aunque Salesforce gestiona la seguridad de la infraestructura (por ejemplo, la protección de la red, el endurecimiento del sistema operativo y la gestión de vulnerabilidades), debe identificar los riesgos de la capa de aplicación en su configuración, integraciones y código personalizado. Aplique el marco de trabajo STRIDE (Suplantación, Manipulación, Repudio, Revelación de información, Denegación de servicio, Elevación de privilegios) a los vectores de amenazas específicos de Salesforce que se enumeran a continuación. Identifique límites Trust donde los datos cruzan sistemas, redes o niveles de privilegios.

Aplique el marco de trabajo STRIDE a estas consideraciones de modelado de amenazas específicas de Salesforce:

• Los flujos de datos multiorganización crean Trust limits adicionales que requieren autenticación y autorización explícitas en cada cruce.
• Las integraciones externas utilizan API y middleware, lo que podría introducir vectores de ataque que omiten los controles de seguridad de plataforma.
• Los componentes Apex y Lightning personalizados requieren un análisis de codificación seguro para la inyección, XSS y la aplicación del control de acceso.
• Los sitios de Experience Cloud amplían la superficie de ataque a usuarios no autenticados o ligeramente autenticados.
• El código externo e ISV (por ejemplo, paquetes gestionados, listados de AgentExchange, aplicaciones conectadas, conectores externos, bibliotecas JavaScript del lado del cliente y los servicios de IA externos a los que llaman sus agentes) es un vector de cadena de suministro que cruza su límite Trust, en el momento de la instalación o en el tiempo de ejecución.

Código externo e ISV forma parte de su Trust Boundary.

Los paquetes gestionados o listados de AgentExchange se ejecutan dentro de su organización con los permisos que les otorga, de modo que su postura de seguridad se convierte en su postura de seguridad en el momento de instalarlos. Revisión de seguridad de Salesforce comprueba cada paquete enumerado antes de que alcance AppExchange o AgentExchange; es propietario de todo después de esa puerta:

• Evaluación del paquete con respecto a su propia clasificación de datos y postura de riesgo
• Otorgarle la menor cantidad de privilegios que requiere su funcionalidad documentada
• Mantenerlo actualizado con las versiones del publicador
• Además, monitoree su actividad a través del mismo Monitoreo de eventos y controles de auditoría que aplica a su propio código.

Aplique controles de seguridad en cada capa de la pila de soluciones. Recuerde que el compromiso de una capa no debe exponer todo el sistema.

Diseñe cada capa como si las capas superior e inferior pudieran fallar. Recuerde que múltiples controles independientes crean resistencia.

Zero Trust elimina Trust implícita basándose en posición de red o estado de autenticación previa. Cada solicitud debe autenticarse y autorizarse de forma independiente.

Aplique Trust cero a:

• Acceso de usuario a través de verificación continua con MFA, políticas de sesión y acceso condicional basado en contexto (por ejemplo, IP, dispositivo, hora y comportamiento)
• Conexiones de integración a través de validación de tokens de OAuth en cada llamada, TLS mutua basada en certificado y lista de admisión de direcciones IP
• Comunicación entre sistemas mediante autenticación explícita, que también se aplica a sistemas internos de confianza
• Acceso a datos a través de la aplicación CRUD y FLS en cada consulta y operación independientemente del contexto de llamada

Inventario de activos de seguridad es una entrada de diseño de seguridad: solo puede modelar amenazas, aplicar el menor privilegio y monitorear una superficie de ataque que enumeró por primera vez, de modo que el seguimiento de sus activos relevantes para la seguridad pertenece a las decisiones de diseño que dependen de él. Esto es distinto de la gestión de la configuración operativa que cubre Operational Excellence (por ejemplo, versionando parámetros de organización y detectando desviación de configuración para estabilidad operativa). En otras palabras, la preocupación aquí es menor: ¿Qué activos conllevan riesgos de seguridad y por qué?

Mantenga un inventario actual de todos los activos relevantes para la seguridad, incluyendo objetos personalizados que almacenan datos confidenciales, integraciones de sistemas externos, API de cara al público, cuentas privilegiadas, subvenciones de acceso de producción y paquetes instalados con permisos elevados.

Su inventario de activos de seguridad debe incluir:

• Campos y objetos personalizados que contienen datos confidenciales o restringidos
• Extremos de integración y mecanismos de autenticación
• Usuarios con privilegios elevados (por ejemplo, Modificar todos los datos, Ver todos los datos y Gestionar usuarios)
• Usuarios de integración solo de API y sus ámbitos de permisos
• Aplicaciones cliente externas (ECA) y sus ámbitos de OAuth, junto con cualquier aplicación conectada heredada que aún esté presente en la organización
• Paquetes AgentExchange instalados y sus concesiones de permisos
• Sitios de Experience Cloud y sus modelos de autenticación y colaboración externa
• Clases Apex personalizadas con modos de colaboración elevados
• Preste especial atención a las clases heredadas: código compilado en la versión 66.0 o anterior de la API, que omite una declaración de colaboración toma como valor predeterminado "sin colaboración" (por ejemplo, modo del sistema, omitiendo el acceso de registro del usuario que ejecuta). Recuerde que desde la versión 67.0 de la API (Summer '26), una declaración omitida toma como valor predeterminado "con colaboración" y las operaciones de la base de datos se ejecutan en modo de usuario. Sin embargo, las clases existentes mantienen el comportamiento antiguo hasta que se vuelven a compilar en la versión 67.0 (o posterior), de modo que las clases no declaradas trasladadas desde versiones anteriores permanecen silenciosamente elevadas.

Es su responsabilidad diseñar y configurar controles de identidad que aplican el menor privilegio.

Echemos un vistazo más de cerca a cómo diseñar y configurar controles correctamente utilizando el PoLP.

Salesforce aplica el control de acceso a través de cuatro capas distintas: organización, objeto, campo y registro. Debe diseñar soluciones que aprovechen las cuatro capas deliberadamente. El control de acceso principal está basado en becas, lo que significa que el acceso es aditivo, y los usuarios necesitan tenerlo otorgado en cada capa para alcanzar un registro. No existe una regla generalizada de "denegar sustituciones permitidas" en la plataforma principal, de modo que no puede deshacer el acceso a una concesión amplia que ya está otorgada.

Las capas superiores permisivas no le cuestan la capacidad de restringir, pero aumentan el esfuerzo: ampliar los permisos de objeto o los valores predeterminados de toda la organización de forma temprana significa basarse en la seguridad a nivel de campo y la configuración de colaboración para recuperar el acceso que nunca debería haberse otorgado.

Las reglas de restricción y los permisos de silenciamiento son dos excepciones integradas que restan acceso, pero cada una tiene un ámbito restringido (reglas de restricción al filtrado a nivel de registro y silenciamiento a permisos otorgados dentro de un grupo de conjuntos de permisos), no una capa de denegación generalizada.

Establezca OWD como Privado para objetos que contienen datos confidenciales. La apertura de OWD a Solo lectura pública (y mucho menos Lectura/Escritura pública) expone registros de forma amplia y erosiona su capacidad de restringir el acceso más adelante sin una rearquitectura potencialmente significativa. La deuda Trust más común en organizaciones maduras proviene de OWD permisivas establecidas durante la implementación inicial.

La capa de registro sigue un modelo de concesión y restricción, a menudo representado como una pirámide de colaboración: Los OWD establecen la línea base restrictiva y la jerarquía de funciones, las reglas de colaboración y el acceso abierto de colaboración manual hacia arriba desde allí. Dos controles invierten ese flujo para quitar el acceso en vez de otorgarlo, y ambos merecen la pena diseñarse deliberadamente.

• Las reglas de restricción filtran lo que los usuarios pueden ver dentro de registros a los que ya tienen acceso, de modo que los usuarios con acceso de objeto amplio aún ven solo el subconjunto que permite una regla.
• Los permisos de silenciamiento restan permisos específicos dentro de un grupo de conjuntos de permisos, de modo que puede ensamblar el acceso desde grupos reutilizables y luego eliminar lo que una población concreta no debe tener.
• Alcance estas reglas cuando las capas basadas en becas por sí solas le obligan a sobreaprovisionar o fragmentar el acceso en muchos conjuntos de permisos estrechos.

Aplique MFA (autenticación de múltiples factores) para todos los usuarios que inician sesión en entornos de producción a través de la interfaz de usuario, que Salesforce establece como un requisito de plataforma. Este requisito no se amplía al acceso solo de API: Las integraciones que utilizan flujos de soporte de JWT o credenciales de cliente están exentas, de modo que debe proteger esas integraciones con restricciones de IP y gestión de certificados en su lugar. Amplíe los requisitos de MFA a operaciones privilegiadas.

Para SSO (inicio de sesión único), se prefieren los protocolos SAML 2.0 u OpenID Connect. Configure políticas de sesión para equilibrar la seguridad y la capacidad de uso:

• Tiempo de espera: de sesión Configure tiempos de espera de sesión apropiados para niveles de privilegios de usuario (tiempos de espera más cortos para cuentas de alto privilegio reducen los riesgos de sesiones desatendidas).
• Restricciones de PI: Aplique restricciones para perfiles administrativos y usuarios de integración.
• Horas de inicio: de sesión Restrinja las cuentas de servicio a los plazos operativos previstos.
• Activación de dispositivo: Confíe en la activación de dispositivos nativa de Salesforce (verificación de identidad para inicios de sesión desde dispositivos no reconocidos) y agregue restricciones de MFA e IP para cuentas de alto privilegio. La postura de Trust de dispositivo nativo se aplica a través de un proveedor de identidad externo.
• Bloqueo de IP de sesión: Bloquee sesiones en la dirección IP desde la que se originaron, de modo que no se pueda reproducir un Id. de sesión robado desde otra ubicación de red. Esto refuerza la seguridad, pero agrega fricción para usuarios móviles y puede interrumpir integraciones automatizadas: donde el bloqueo no es viable, aplique Intervalos de direcciones IP de inicio de sesión estrictos en el nivel de perfil con "Aplicar intervalos de direcciones IP de inicio de sesión en cada solicitud" como el control de compensación.
• Sesiones de alta seguridad: Requerir un nivel de seguridad de sesión de Alta seguridad, a través de Políticas de nivel de seguridad de sesión y Políticas de acceso, para operaciones confidenciales (como acceder a reportes o gestionar intervalos de IP), de modo que un inicio de sesión rutinario no pueda por sí solo alcanzar acciones de alto impacto. En Lightning Experience, no se admite el paso de una sesión estándar a Alta seguridad volviendo a solicitar MFA, de modo que aplique esta política sabiendo que se bloquea a los usuarios de sesión estándar la operación cerrada en vez de solicitar su elevación.
• Protección de cookies: de sesión Requiera el atributo HttpOnly de modo que las secuencias de comandos no puedan leer la cookie de Id. de sesión y bloquear sesiones en el dominio en el que se utilizaron por primera vez para atenuar el secuestro de sesiones.
• Acceso solo de API para usuarios de integración: Restrinja la integración y las cuentas de servicio a la autenticación solo de API con el permiso Usuario solo de API, de modo que no puedan iniciar sesión a través de la interfaz de usuario. Para nuevas compilaciones, asigne el perfil Acceso mínimo - Integraciones solo de API con la licencia de usuario Integración de Salesforce; el perfil Integración de sistemas solo de API de Salesforce anterior no está disponible en organizaciones aprovisionadas desde Spring '24 en adelante, de modo que diseñe nuevas integraciones con el perfil actual en vez del desusado.

Para la autenticación de API, seleccione flujos de OAuth 2.0 apropiados para el patrón de integración:

• Flujo de soporte JWT: Utilice esto para integraciones de servidor a servidor que se ejecutan como un usuario de integración (basado en certificado, preferido para entornos de confianza).
• Flujo de servidor web (código de autorización, con PKCE): Utilice esto para aplicaciones web que requieren autorización de usuario y para integraciones de servidor a servidor que necesitan mantener contexto de usuario específico (almacenamiento de tokens de actualización en el lado del servidor para evitar solicitudes repetidas del navegador).
• Hacer que la reproducción de flujos de código de autorización sea segura: Aplique PKCE de modo que un código de autorización interceptado no pueda ser canjeado por nadie más que el cliente que lo solicitó, y rote tokens de actualización (emitiendo uno nuevo en cada uso e invalidando el anterior), de modo que un token de actualización robado tenga un plazo de validez estrecho. La reutilización de un token retirado señala un compromiso.
• Flujo Código de autorización de identidad desatendida y credenciales (con PKCE): Utilice esto para clientes genuinamente desatendidos y sin navegador que deben ejecutarse en el contexto de un usuario específico: el flujo de servidor web basado en redireccionamiento asume un navegador que estos clientes no tienen.
• Flujo de dispositivo (para dispositivos desatendidos): Tenga en cuenta que a partir del 28 de agosto de 2025, Salesforce bloqueó permanentemente Flujo de dispositivos de OAuth 2.0 para la aplicación conectada Salesforce CLI predeterminada. Utilice el flujo de servidor web (web de inicio de sesión de organización sf) o el flujo de soporte JWT (jwt de inicio de sesión de organización sf) en su lugar para herramientas de CLI y CI/CD.

No utilice el flujo Nombre de usuario-Contraseña. Salesforce lo bloqueó de forma predeterminada para organizaciones creadas en Summer '23 o versiones posteriores y publicó planes de retirada para este flujo. Las integraciones existentes que aún dependen del flujo Nombre de usuario-Contraseña deben migrar al flujo Portador de JWT o al flujo Credenciales de cliente ahora, en vez de tratar la migración como una deuda técnica aplazada.

Estos flujos se configuran en el registro de la aplicación que representa su integración. A partir de Spring '26, Salesforce está trasladando ese registro de Aplicaciones conectadas a Aplicaciones cliente externas (ECA): La creación de nuevas aplicaciones conectadas está desactivada de forma predeterminada, y ECA es la construcción con la que diseñar nuevas integraciones. Las aplicaciones conectadas existentes permanecen instaladas; sin embargo, una vez que se migra una organización ya no gestionan la autenticación, por lo que debe tenerse en cuenta la migración al auditar cómo se autentican las integraciones en vez de tratar las aplicaciones conectadas como el modelo permanente.

Además de elegir un flujo de autenticación, cree una regulación distinta para la que las aplicaciones puedan conectarse:

• Un registro por integración: Registre una aplicación cliente externa exclusiva para cada nueva integración y una aplicación conectada distinta para cada una existente. Con ámbito solo para los ámbitos de OAuth que requiere cada integración en vez de compartir un registro amplio entre muchos, un registro exclusivo mantiene el acceso de cada integración de forma independiente auditable y revocable.
• Autorice el acceso de forma explícita (se recomienda): Establezca la política Usuarios permitidos de la aplicación cliente externa en "Los usuarios aprobados por el administrador están autorizados previamente", de modo que un administrador otorgue acceso a través de perfiles y conjuntos de permisos en vez de permitir a los usuarios autorizarse. Los administradores configuran esto directamente en Configuración, y es el control recomendado de Salesforce para determinar quién puede conectarse.
• Control de acceso de API (más estricto, basado en listas de admisión): Para controles más estrictos, Control de acceso de API limita los usuarios aprobados por el administrador a aplicaciones conectadas en la lista de admisión únicamente. La activación requiere una solicitud al Servicio de atención al cliente de Salesforce, de modo que planifique ese paso al diseñar alrededor de él en vez de tratarlo como una configuración de autoservicio.

Nunca incruste credenciales en código, archivos de configuración o control de versiones. Utilice credenciales nombradas y credenciales externas para gestionar la autenticación de forma centralizada con funciones de rotación.

A diferencia de la autenticación de usuario tradicional, los agentes requieren modelos de identidad distintos, y el modelo correcto depende de si el agente sirve a empleados o usuarios externos. Diseñar la identidad correctamente es la base de la seguridad de los agentes: Determina a qué datos puede acceder el agente y las acciones a las que puede llegar el agente.

Echemos un vistazo con más detalle a agentes internos y externos. nts.

• Agentes empleados (internos): Ejecute tareas en el contexto del usuario que inició sesión. Heredan las licencias, los conjuntos de permisos, la seguridad a nivel de campo y las reglas de colaboración de ese usuario, de modo que no se aprovisiona ninguna identidad de agente separada y el marco de trabajo de seguridad existente rige lo que el agente puede hacer.
• Agentes clientes (externos): Interactúe a través de canales públicos y ejecútese como Usuarios agentes exclusivos, usuarios de integración especializados, no usuarios invitados de sitio público. Ejecutar como usuarios de integración exclusivos permite al agente realizar acciones de backend y alcanzar datos (que los perfiles de invitado no autenticados no pueden), mientras sigue vinculado por permisos explícitos de menor privilegio. Cuando crea un agente de cliente, aprovisione un nuevo Usuario de agente con acceso mínimo y otorgue solo los permisos específicos que requieren sus acciones.

Donde el trabajo de un agente abarca múltiples servicios, propague la identidad del usuario entre cada salto de servicio en vez de recurrir a una identidad compartida o de invitado. El flujo de intercambio de tokens de Salesforce OAuth 2.0 admite esto:

Un cliente presenta el token de proveedor de identidad existente del usuario y un controlador de intercambio de tokens Apex lo asigna a un usuario de Salesforce y emite un token de acceso de Salesforce, de modo que el contexto del usuario original sigue la solicitud en vez de contraerse a una cuenta de servicio. Monitoree la actividad de agentes a través de Monitoreo de eventos, utilizando la identidad de usuario del agente para detectar comportamientos anómalos.

La selección del modelo correcto depende de quién inicia la conexión y en qué contexto debe ejecutarse el trabajo.

Los escenarios de conexión comunes se asignan a enfoques recomendados del siguiente modo:

Diseñe jerarquías de funciones alrededor de necesidades de acceso a datos (que los usuarios requieren acceso a registros propiedad de otros), no el gráfico de creación de reportes de gestión. Permita que la profundidad de jerarquía de funciones siga relaciones de acceso a datos genuinas en vez de agregar niveles que no otorgan acceso adicional, ya que cada nivel agrega sobrecarga de cálculo de colaboración, una consideración que tiene más peso en organizaciones con configuración de OWD privada y grandes volúmenes de datos.

Los conjuntos de permisos y los grupos de conjuntos de permisos reducen la necesidad de proliferación de perfiles proporcionando acceso flexible y aditivo. Otorgue acceso funcional a través de conjuntos de permisos y grupos de conjuntos de permisos en vez de perfiles, que mantienen el acceso aditivo y auditable. Los perfiles siguen siendo necesarios: junto con las horas de inicio de sesión y las restricciones de IP, controlan la asignación del formato de página, los valores predeterminados del tipo de registro y la visibilidad de la aplicación. Trate los perfiles como una parte duradera del modelo de acceso, en vez de una construcción para eliminar.

Las políticas de Seguridad de transacciones no forman parte de la línea base, son una función complementaria que complementa el modelo de autorización principal: los controles de identidad, función, perfil, conjunto de permisos y colaboración anteriores ya establecen una postura de autorización segura por sí mismos, y Seguridad de transacciones agrega evaluación contextual en tiempo real en la parte superior. Configure políticas para detectar y bloquear comportamientos anómalos, incluyendo descargas masivas de datos que superan patrones normales, inicios de sesión desde geografías inesperadas y cambios de permisos fuera de plazos de cambio.

Los controles de seguridad conllevan ventajas de disponibilidad que son una responsabilidad arquitectónica. Una restricción de IP demasiado amplia puede bloquear usuarios legítimos durante un cambio de red, y una política de Seguridad de transacciones ajustada de forma demasiado agresiva puede bloquear la actividad de negocio válida; por lo tanto, aplique el ámbito de estos controles a un riesgo genuino, escénelos en modo de solo monitor antes de aplicarlos y diseñe una ruta de emergencia para cuando un control falla.

Su responsabilidad: Diseñe jerarquías de funciones, cree conjuntos de permisos y configure políticas de Seguridad de transacciones.

Control de acceso basado en funciones tradicional) otorga permisos basándose en la función de un usuario. ABAC (control de acceso basado en atributos) toma decisiones de autorización basándose en atributos de los datos, el usuario y el contexto.

Para la mayoría de los requisitos, el modelo de colaboración principal expresa acceso completamente. Alcance ABAC exclusivo cuando el acceso debe seguir la clasificación de datos que la colaboración por registro no puede expresar: Data 360 ABAC proporciona esto a través de etiquetas y anotaciones.

Data 360 ABAC funciona a través de:

• Políticas basadas en etiquetas que definen reglas de acceso basadas en etiquetas aplicadas a objetos de datos (por ejemplo, Información de identificación personal (PII), Financiera, Asistencia sanitaria y Etiquetas confidenciales).
• Las anotaciones se aplican a objetos de datos para dar cobertura a decisiones de autorización basadas en políticas.
• Política predeterminada "Permitir todo" para organizaciones nuevas y existentes que deben eliminarse explícitamente para activar políticas de gobernanza granulares.

Su uso arquitectónico principal es la aplicación forzosa de la clasificación de datos; consulte Clasificación de datos bajo Privacidad y protección de datos para obtener información acerca de cómo los niveles de clasificación dirigen la aplicación forzosa de ABAC.

Este nivel de granularidad conlleva un costo operativo. La colaboración principal responde a la pregunta: "¿Quién puede ver este registro y por qué?" desde un conjunto pequeño e inspeccionable de reglas (OWD, jerarquía de funciones y reglas de colaboración), mientras que ABAC deriva sus respuestas en tiempo de evaluación desde la combinación de etiquetas de datos, atributos de usuario y contexto, de modo que el acceso efectivo se hace más difícil de razonar y auditar a medida que se acumulan políticas y etiquetas.

Aplicar la capacidad de auditoría como requisito de diseño: aplique etiquetas de forma coherente, mantenga el conjunto de políticas pequeño y nombrado para la clasificación que aplica y mantenga la capacidad de reconstruir por qué un usuario alcanzó un registro concreto. Reserve ABAC para casos dirigidos por clasificación que la colaboración por registro no puede expresar genuinamente, en vez de tratarla como una sustitución general para el modelo basado en propiedad.

Identifique y proteja cuentas con privilegios elevados, incluyendo administradores del sistema, usuarios de integración y cuentas de procesos automatizados. Estas cuentas son objetivos de alto valor para atacantes.

Aplique controles mejorados a cuentas de impacto crítico.

• Requerir MFA resistente a phishing
• Restringir intervalos de direcciones IP de inicio de sesión a ubicaciones administrativas conocidas
• Activar alertas de inicio de sesión y notificaciones de cambio de permisos
• Dirigir revisiones de acceso periódicas con certificado documentado para cuentas de alto privilegio donde la frecuencia se determina por tolerancia a riesgos organizativos y requisitos de cumplimiento
• Mantener procedimientos de vidrio roto para el acceso de emergencia y la auditoría posterior al uso

Para cuentas de integración y servicio:

• Aplicar flujos de OAuth; nunca flujos de nombre de usuario-contraseña
• Aplicar restricciones de IP
• Implementar programaciones de rotación de credenciales
• Monitorear patrones de uso de API anómalos a través de Monitoreo de eventos

Su responsabilidad: Identifique cuentas críticas, aplique controles mejorados y realice revisiones trimestrales.

Diseñe procesos automatizados para proporcionar a los usuarios el acceso inicial apropiado, ajuste los permisos a medida que evolucionan las funciones y anule el aprovisionamiento rápidamente cuando ya no se requiera el acceso.

Implemente un Sistema para Gestión de identidad entre dominios (SCIM) para el aprovisionamiento automatizado desde proveedores de identidad. El aprovisionamiento Just-in-Time de SAML u OpenID Connect es una alternativa que crea un usuario tras el primer inicio de sesión, pero no desaprovisiona usuarios. En otras palabras, SCIM es la columna vertebral del ciclo de vida, no una opción en su contra.

El ciclo de vida de identidad incluye:

• Aprovisionamiento: Cree cuentas con acceso de línea base que coincida con la función del trabajo, que se desencadena por eventos del sistema de RRHH.
• Ajustes de acceso: Otorgue permisos adicionales a medida que se amplían las funciones y revoque permisos cuando cambian las funciones.
• Recertificación periódica: Revise y valide el acceso trimestralmente.
• Desaprovisionamiento: Revoque el acceso inmediatamente cuando finalice el empleo o las funciones ya no requieran acceso de Salesforce.

Implemente procesos de recertificación de acceso cuando los gestores revisen y validen periódicamente los permisos de sus equipos. La frecuencia de revisión se basa en los requisitos de cumplimiento y riesgo.

Su responsabilidad: Implemente SCIM, diseñe flujos de trabajo de aprovisionamiento, realice recertificaciones trimestrales.

La separación de datos en múltiples organizaciones se considera a veces como una decisión puramente de costo o residencia. Arquitectónicamente hablando, es una compensación de seguridad, y las consecuencias de la regulación pertenecen a su diseño de acceso.

El aislamiento es el beneficio clave. Las organizaciones separadas proporcionan el límite más sólido posible entre conjuntos de datos. No existe un modelo de colaboración colectiva y no hay fuga de permisos entre arrendatarios, pero hay una línea reguladora clara para jurisdicciones que demandan uno. Ese mismo límite fragmenta la regulación. Cada control de acceso que solo necesita mantener una vez en una única organización (por ejemplo, diseño de conjuntos de permisos, jerarquía de funciones, endurecimiento de cuentas de impacto crítico, líneas base de Comprobación de estado, Monitoreo de eventos y correlación SIEM) se multiplica ahora por organización, lo que significa que debe mantener la coherencia entre todas ellas. La desviación entre organizaciones crea su propia superficie de ataque porque un permiso restringido en una organización y que se pierde en otra crea una incoherencia que los atacantes pueden encontrar y explotar. Las integraciones entre organizaciones agregan límites Trust autenticados que no existían antes. Cada integración entre organizaciones es una conexión que necesita proteger y monitorear.

Es por eso que es importante sopesar el beneficio de aislamiento con el multiplicador de gobernanza antes de dividir una organización. Reserve múltiples organizaciones para casos donde un mandato de localización permanente o el requisito de aislamiento contractual de un cliente no se puede cumplir genuinamente en una sola organización. Cuando lo adopte, debe diseñar el modelo de acceso, el monitoreo y las líneas base de configuración para que se apliquen de forma idéntica en cada organización desde el principio.

Su responsabilidad: Trate una decisión de múltiples organizaciones como una compensación de seguridad, no solo un costo. Donde se requieran múltiples organizaciones, aplique controles de acceso, monitoreo y líneas base de Comprobación de estado de forma coherente en cada organización y proteja cada integración entre organizaciones como un Trust Border.

Es su responsabilidad clasificar datos, configurar cifrado, diseñar controles de privacidad.

Echemos un vistazo más de cerca a cómo proteger los datos y la privacidad correctamente.

Para clasificar correctamente sus datos, necesita conocer sus datos. La tarea arquitectónica general es comprender su dominio de negocio y mantener un diccionario de datos que cataloge qué datos tiene, qué significa y dónde residen los datos confidenciales. Solo puede clasificar (o proteger) datos que identificó primero.

Establezca un esquema de clasificación de datos que dirija los controles de protección apropiados. Una etiqueta de clasificación no protege nada por sí sola. Es la entrada a los controles que aplica, de modo que cada clasificación que asigne debe asignarse a una decisión concreta de cifrado, acceso, retención o monitoreo. Las decisiones de clasificación que se toman durante el modelado de datos influyen directamente en los requisitos de cifrado, los controles de acceso, las políticas de retención y las obligaciones de cumplimiento.

En Salesforce, utilizamos un esquema de cuatro niveles que proporciona un marco de trabajo que puede adaptar a los requisitos normativos y las necesidades de negocio de su organización. Muchas empresas utilizan modelos similares alineados con los estándares de la industria (por ejemplo, ISO 27001 y NIST). Su implementación específica debe reflejar sus obligaciones de cumplimiento (por ejemplo, HIPAA, PCI DSS, GDPR y leyes de la industria) y contexto de negocio.

Aplique la clasificación a nivel de campo. Un único registro Cuenta puede contener campos Público (por ejemplo, nombres de compañía), campos Confidencial (por ejemplo, ingresos de compañía) y campos Restringido (por ejemplo, números de seguridad social). La seguridad sobre el terreno debe reflejar estas distinciones.

La clasificación se vuelve aplicable a través del control de acceso basado en atributos, que lee las etiquetas que asigna y aplica reglas de acceso. Esta es una capa dirigida por metadatos que complementa OWD y reglas de colaboración.

La alineación de ABAC con su esquema de clasificación permite a la plataforma:

• Restrinja el acceso a datos etiquetados como Restringido o Confidencial desde la clasificación en sí, en vez de desde una regla de colaboración que se mantiene por objeto.
• Adapte el acceso a medida que cambia la clasificación de un registro con el tiempo. Un registro etiquetado recientemente como Regulado hereda un acceso más estricto sin un cambio de regla manual.
• Combine atributos de datos (por ejemplo, clasificación y confidencialidad) con atributos de usuario (por ejemplo, departamento y autorización) y contexto (por ejemplo, hora y ubicación) en una sola decisión de autorización.

Diseñe políticas de ABAC para alinearse con este esquema de modo que la clasificación de un campo como Restringido sea el acto que dirige sus controles de acceso y mantiene la aplicación anclada en la clasificación en vez de mantener reglas de colaboración por separado.

Su responsabilidad: Defina el esquema de clasificación, capacite modeladores de datos, clasifique campos durante el diseño, configure controles y alinee políticas de ABAC con los niveles de clasificación de modo que las etiquetas impulsen la aplicación.

ComienceComience con la información que la plataforma ya proporciona para cada organización. Los datos en periodos de inactividad están cifrados de forma predeterminada. Hyperforce aplica cifrado a nivel de volumen que protege un volumen de almacenamiento completo bajo una única clave que Salesforce posee y gestiona. Esta línea base siempre está activada y es transparente para su solución, pero funciona a nivel de volumen (no por campo), de modo que elegir qué cifrar y controlar dentro del ciclo de vida de claves recae en la plataforma, no en usted.

Cuando esa línea base no puede satisfacer una obligación de cumplimiento, contractual o clasificación de datos, utilice Shield Platform Encryption. Específicamente, cuando necesita una de las tres cosas que el cifrado a nivel de volumen no proporciona:

• Control del ciclo de vida de claves de modo que pueda generar, rotar y revocar el material clave usted mismo
• Selectividad sobre qué campos estándar, campos personalizados, archivos y archivos adjuntos están cifrados en periodos de inactividad
• La capacidad de hacer que los datos no sean accesibles para Salesforce.

Los datos restringidos y los datos que están bajo mandatos de control de claves reguladores explícitos (por ejemplo, HIPAA, PCI DSS y GDPR) son los desencadenadores habituales. La línea base ya cubre la protección a nivel de infraestructura de todo lo demás.

Shield Platform Encryption cifra a nivel de campo y ofrece dos esquemas que cambian la seguridad por la capacidad de consulta.

El cifrado probabilista es un esquema sólido y predeterminado, pero los campos cifrados con él no se pueden utilizar en criterios de filtro, clasificación o funciones agregadas (por ejemplo, funciones MAX(), MIN() y COUNT_DISTINCT().

El cifrado determinista permite el filtrado de coincidencia exacta en reportes, vistas de lista y cláusulas WHERE de SOQL (distingue entre mayúsculas y minúsculas) con una resistencia reducida porque el mismo texto sin formato siempre produce el mismo texto cifrado.

Recomendamos cifrar con el esquema probabilista de forma predeterminada y reservar el cifrado determinista para los campos específicos que debe filtrar u ordenar. Evalúe estas compensaciones durante el diseño del modelado de datos, incluyendo impactos en referencias de campos de fórmula, agregación de reportes y operaciones SOQL.

Las claves controladas por el cliente tienen dos formas distintas:

• Bring Your Own Key (BYOK) le permite generar material de claves fuera de Salesforce (utilizando sus propias bibliotecas criptográficas, sistema de gestión de claves de negocio o módulo de seguridad de hardware) y suministrarlo a la plataforma.
• Servicio de claves de solo caché mantiene su clave de cifrado de datos en un servicio de claves que controla. Salesforce lo obtiene on demand en vez de almacenarlo.

Ambos formularios le permiten rotar y destruir material clave en su propia programación. La destrucción de material clave hace que los datos que protegía sean irrecuperables, lo que es un control potente y deliberado en vez de una rutina. También es importante documentar sus procedimientos de rotación y revocación de claves.

Todas las integraciones deben utilizar TLS 1.2 o superior (la plataforma Salesforce aplica esto), pero debe implementar la autenticación mutua basada en certificados para integraciones que gestionan datos restringidos (utilizando su propia configuración).

Su responsabilidad: Decida dónde es suficiente la línea base a nivel de volumen de la plataforma y dónde una obligación de cumplimiento, contractual o clasificación garantiza Shield Platform Encryption, luego seleccione esquemas de cifrado, seleccione y opere una estrategia de claves controlada por el cliente e implemente la autenticación basada en certificados para integraciones confidenciales.

Proteja datos confidenciales en entornos no de producción utilizando estrategias que evitan que los datos restringidos entren en entornos sandbox.

• La copia parcial de sandbox excluye datos restringidos de actualizaciones de sandbox.
• Las reglas de enmascaramiento de datos confunden valores de campo confidenciales en entornos sandbox utilizando patrones que conservan características de datos.
• La generación de datos sintéticos se aplica a entornos de desarrollo que nunca requieren datos de producción.
• Las plantillas de sandbox definen qué objetos y campos incluir en cada tipo de sandbox.

El diseño para pruebas de cumplimiento es una responsabilidad arquitectónica. Construya ciclos de desarrollo y prueba en datos sintéticos con características realistas, de modo que los equipos puedan validar en condiciones similares a las de producción mientras los datos regulados permanecen dentro de su límite de producción.

Su responsabilidad: Diseñar estrategia de sandbox, configurar reglas Data Mask, generar datos de prueba sintéticos.

Diseñe soluciones que respeten la privacidad del usuario a través de decisiones arquitectónicas.

• Minimización de datos: Recopile datos necesarios solo para fines de negocio declarados. Desafíe cada incorporación de campo preguntando: "¿Qué decisión de arquitectura requiere estos datos?" Recuerde, los datos más seguros son los datos que nunca recopila.
• Limitación de propósito: Diseñe patrones de acceso a datos que aplican la limitación de propósitos técnicamente. Utilice conjuntos de permisos y reglas de colaboración para restringir el acceso a datos basándose en el propósito de una función de trabajo. Por ejemplo, los usuarios de marketing no deben acceder a detalles de casos de asistencia a menos que su trabajo lo requiera.
• Gestión de consentimiento: Implemente el seguimiento de consentimiento a nivel individual para marketing, análisis y procesamiento de datos opcional. Diseñe flujos de trabajo de retirada de consentimiento que se propagan entre sistemas integrados. En otras palabras, el consentimiento es granular y específico del propósito.
• Derechos de titular de datos: Cree flujos de trabajo para solicitudes de acceso (por ejemplo, proporcionando copias de datos), rectificación (por ejemplo, corrigiendo imprecisiones), eliminación (por ejemplo, eliminando datos cuando es legalmente permitido hacerlo) y portabilidad (por ejemplo, exportando a un formato legible por máquina). Diseñe estos flujos de trabajo para que se completen dentro del plazo de respuesta que impone cada marco de trabajo de gobierno. Estos plazos varían por jurisdicción (y se corrigen periódicamente), de modo que es importante parametrizar el SLA del flujo de trabajo desde un origen de cumplimiento mantenido y confirmar cada plazo con la regulación vigente (en vez de codificar un único valor).

Su responsabilidad: Diseñe modelos de datos con minimización, configure el acceso por propósito, implemente flujos de trabajo de consentimiento y cree automatización de derechos de titulares de datos.

La residencia de datos es una decisión arquitectónica que toma antes de aprovisionar, no una configuración que alterna después. Hyperforce ofrece implementación regional, pero solo existe una región donde Salesforce opera una, y la residencia de una organización está fija en el aprovisionamiento. Su responsabilidad es establecer dónde debe residir cada categoría de datos, confirmar si una región adecuada está disponible y diseñar los mecanismos de transferencia de datos que cruzan fronteras legítimamente.

En vez de tomar como valor predeterminado el almacenamiento en el país, es importante clasificar sus obligaciones de residencia antes de empezar.:

• Localización obligatoria. Un pequeño conjunto de jurisdicciones requiere que ciertos datos permanezcan dentro de las fronteras nacionales (a veces, esto solo se aplica a sectores regulados). Cuando Salesforce no opera en una región de país, el almacenamiento nativo no puede satisfacer el mandato por sí solo, de modo que necesita una superposición de residencia de datos o una organización separada para esos datos. Puesto que esta lista puede cambiar, es importante confirmar el mandato específico frente a la regulación vigente.
• Marcos basados en la rendición de cuentas. La mayoría de los regímenes no imponen un mandato de localización. Están satisfechos por un núcleo regional con un mecanismo de transferencia transfronteriza apropiado. En estas instancias, la decisión se basa en qué región minimiza la latencia y simplifica el cumplimiento.

Cuando los datos cruzan una frontera, el punto es la conciencia antes de la configuración. En otras palabras, debe saber qué transferencias se producen y sobre qué base legal, y luego diseñar el acceso de modo que los datos se rijan de extremo a extremo. Dondequiera que existan, las decisiones de adecuación conllevan la menor fricción. Las reglas corporativas vinculantes (BCR) y las cláusulas contractuales estándar (SCC) cubren la mayoría de las transferencias restantes. Utilice el consentimiento explícito solo como último recurso.

Emparejar el mecanismo de transferencia con acceso de registro restrictivo (por ejemplo, OWD privados y colaboración con ámbito de propósito) de modo que una transferencia permitida no se vuelva demasiado amplia. Documente mapas de flujo de datos para mostrar dónde se origina, transita y reside cada categoría de datos. Vuelva a visitarlos cuando cambien las leyes o las disponibilidades regionales.

Su responsabilidad: Clasifique obligaciones de residencia por categoría de datos, confirme la disponibilidad regional antes de aprovisionar, seleccione mecanismos de transferencia (adecuación, BCR/SCC) para flujos transfronterizos y documente mapas de flujos de datos.

Es su responsabilidad diseñar soluciones que mantengan la postura de cumplimiento que proporciona la plataforma.

Esta orientación es direccional. Los requisitos normativos varían según la jurisdicción y cambian con el tiempo. Siempre debe verificar las obligaciones específicas con respecto a la normativa vigente (por ejemplo, el estatuto, la autoridad de supervisión o la documentación de cumplimiento de Salesforce aplicables) para su implementación.

Salesforce mantiene amplias certificaciones de cumplimiento (disponibles en Trust.salesforce.com y compliance.salesforce.com): SOC 2 Tipo II, ISO 27001, FedRAMP (para ofertas de Government Cloud), HIPAA, PCI DSS y certificaciones regionales. Estas certificaciones cubren las responsabilidades de Salesforce para la infraestructura de plataforma y los servicios compartidos.

Las certificaciones de plataforma reducen su carga de cumplimiento, pero no eliminan su responsabilidad arquitectónica. Sus objetos personalizados, código Apex, integraciones y configuraciones deben mantener la postura de cumplimiento que proporciona la plataforma.

Su responsabilidad: Diseñe soluciones que mantienen la postura de cumplimiento, documente cómo la arquitectura satisface los requisitos normativos.

• Active Shield Platform Encryption para todos los campos que contienen información sanitaria protegida (PHI).
• Para el cumplimiento de HIPAA, active el Seguimiento de auditoría de campo con políticas de retención para cumplir el requisito de mantenimiento de registros de HIPAA. Confirme el periodo actual frente a la regulación vigente.
• Configure Monitoreo de eventos para detectar patrones de acceso de PHI no autorizados.
• Implemente todas las salvaguardas técnicas requeridas por la Regla de seguridad de HIPAA, incluyendo controles de acceso, registro de auditoría y seguridad de transmisión.

• Implemente la segregación de funciones (SoD) a través de diseños de conjuntos de permisos para evitar que los usuarios únicos creen y aprueben transacciones financieras.
• Para entornos PCI, evite almacenar números de cuenta principales completos (PAN) en Salesforce para minimizar el ámbito de cumplimiento de PCI DSS.
• Cuando sea posible, utilice la tokenización de pasarela de pago.

• Para RGPD y LGPD, diseñe una gestión de consentimiento que capture el consentimiento de suscripción granular y específico del propósito.
• CCPA/CPRA sigue un modelo de anulación de suscripción. Proporcione mecanismos claros para anular la suscripción a la venta o colaboración de información personal en vez de consentimiento granular basado en fines.
• Cree flujos de trabajo de derechos de titulares de datos que se completen dentro del plazo de respuesta de cada marco de trabajo y se confirmen con la normativa vigente.
• Implemente la automatización de retención de datos que purga datos cuando caduca el consentimiento.

• Utilice Salesforce Government Cloud para cargas de trabajo gubernamentales reguladas.
• Implemente controles NIST 800-53 asignados a la configuración de Salesforce.
• Active el monitoreo continuo a través de Monitoreo de eventos que se enruta a la infraestructura SIEM gubernamental.

Su responsabilidad: Configure Shield, Seguimiento de auditoría de campo, segregación de funciones, gestión de consentimiento, retención de datos basándose en requisitos normativos.

Las leyes de privacidad y protección de datos varían significativamente entre jurisdicciones, y las obligaciones específicas cambian rápidamente, de modo que este nivel requiere la toma de decisiones en vez de una tabla país por país.

Las dos palancas arquitectónicas son la residencia y la transferencia transfronteriza, que están cubiertas bajo Privacidad y protección de datos.

Para cumplir con estas leyes, debe:

• Clasificar dónde debe residir cada categoría de datos
• Confirmar que existe una región adecuada antes del aprovisionamiento
• Diseñe un mecanismo de transferencia legal para datos que cruzan una frontera.

Para obtener más información, consulte Residencia y soberanía de datos para obtener más detalles sobre el marco de decisiones.

Todo lo demás se considera una cifra puntual (por ejemplo, qué modelo de consentimiento utiliza una jurisdicción, el plazo para una solicitud de titular de datos, el plazo para notificar a los reguladores o personas afectadas tras una infracción y el periodo de retención mínimo para registros de auditoría). Estas cifras están establecidas por leyes, difieren por marco y se corrigen en las programaciones de los reguladores.

No los codifique aquí. Debe determinar los siguientes pasos en base a la regulación vigente para su implementación (o un origen de cumplimiento mantenido que cite uno) y dimensionar su diseño al plazo más ajustado en su huella operativa.

Estas son las consecuencias arquitectónicas duraderas que pertenecen al diseño.

• Una fecha límite de solicitud de asunto de datos que se mide en días de un solo dígito no se puede cumplir con un proceso manual ad-hoc, de modo que necesita automatizar la realización de DSR cuando opera en cualquier jurisdicción de plazo corto. Utilice Experience Cloud para la admisión, Service Cloud para el seguimiento de casos, Centro de privacidad para la detección y Flujo para la realización.
• Un plazo de notificación de infracción es demasiado estrecho para improvisar, por lo que debe crear el flujo de trabajo de respuesta a la infracción con antelación. Determine reglas de anomalías de Event Monitoring, funciones asignadas previamente, notificaciones de regulador y asunto de datos redactadas previamente y una ruta de distribución que asume la fecha límite más ajustada dentro de su huella. Las notificaciones individuales se desencadenan generalmente por una determinación de alto riesgo, de modo que debe incluir una evaluación de riesgo en el flujo de trabajo.
• Algunas jurisdicciones requieren o recomiendan la retención en el país de registros de auditoría (con mínimos que abarcan varios años), de modo que necesita dimensionar la retención de SIEM al mínimo más largo dentro de su huella y confirmar si los registros pueden salir de la jurisdicción.

Su responsabilidad: Diseñe la residencia y la transferencia por Privacidad y protección de datos, automatice los flujos de trabajo de DSR e infracción-respuesta hasta el plazo más ajustado en su huella, y confirme cada cifra específica de jurisdicción en la regulación vigente en vez de un valor escrito en esta guía.

Diseño para validación de cumplimiento continua en vez de preparación de auditoría de punto en el tiempo.

• Security Health Check evalúa la configuración con respecto a las líneas base de seguridad de Salesforce y proporciona puntuajes de riesgo. Ejecute comprobaciones regularmente para monitorear el cumplimiento de las recomendaciones de la línea base de seguridad de Salesforce. Mantenga puntuajes del 80% o superiores (bandas Muy buenas o Excelentes).
• Monitoreo de eventos captura registros detallados para la actividad de usuarios, llamadas de API, eventos de autenticación y patrones de acceso a datos. Enrute Archivos de registro de eventos a SIEM externo para una retención a largo plazo que supere los límites de retención nativos.
• Seguridad de transacciones evalúa los eventos con respecto a pólizas en tiempo real y puede bloquear eventos, requerir un aumento de MFA o notificarle infracciones de pólizas.

Es importante automatizar las comprobaciones de cumplimiento en oportunidades en curso de implementación para validar que las implementaciones no debilitan los modelos de permisos, desactivar los parámetros de auditoría o introducir configuraciones no conformes.

Su responsabilidad: Ejecute Comprobación de estado trimestralmente, enrute Monitoreo de eventos a SIEM, configure políticas de Seguridad de transacciones y automatice la validación de cumplimiento en CI/CD.

Diseñe estrategias de seguimiento de auditoría basadas en requisitos de cumplimiento, necesidades de investigación y obligaciones de retención.

Para entornos regulados, implemente Monitoreo de eventos con integración SIEM externa para la retención de registros a largo plazo y la correlación entre sistemas. Diseñe políticas de Seguimiento de auditoría de campos que cubran todos los campos Restringidos y Confidenciales sujetos a requisitos de mantenimiento de registros normativos.

Su responsabilidad: Active Seguimiento de auditoría de campo para campos confidenciales, enrute Monitoreo de eventos a SIEM, configure políticas de Seguridad de transacciones.

Es su responsabilidad integrar la seguridad en todo el desarrollo, no como una idea posterior.

Integre prácticas de seguridad en la fase de desarrollo más temprana posible. El modelado de amenazas durante la fase de arquitectura evita vulnerabilidades a nivel de diseño. Los requisitos de seguridad capturados junto con los requisitos funcionales le impiden tratar la seguridad como una idea posterior.

Los defectos de seguridad cuestan sustancialmente más de lo que cuesta remediarlos cuando se detectan en producción en vez de durante las fases de diseño o desarrollo. Un fallo de seguridad a nivel de diseño que se detecta durante la revisión de arquitectura solo puede tardar una plática en solucionarse. Sin embargo, cuando se encuentra el mismo fallo en producción, requiere rearquitectura, migración de datos, corrección de cumplimiento y posible notificación de infracción.

Por eso practicamos la seguridad de turno a la izquierda, que se centra en:

• Modelado de amenazas antes de la finalización del diseño
• Requisitos de seguridad en historias de usuario
• Capacitación segura en codificación para desarrolladores
• Análisis estático integrado en IDE
• Revisiones de código centradas en la seguridad
• Pruebas de seguridad automatizadas en CI/CD
• Validación de seguridad antes de la implementación de producción

Su responsabilidad: Dirija el modelado de amenazas, capacite desarrolladores, integre Code Analyzer en CI/CD, requiera revisiones de código de seguridad.

Es importante diseñar defensas contra vulnerabilidades comunes en un contexto de Salesforce. Echemos un vistazo con más detalle a cómo se asignan al OWASP Top 10 2025 en Salesforce.

• A01:2025 - Control de acceso dañado: Aplique de forma programática CRUD y seguridad a nivel de campo (FLS) en todo el acceso a datos Apex.
  • En la versión 67.0 o posteriores de la API, Apex se ejecuta en contexto de usuario de forma predeterminada, lo que significa que los permisos y FLS del usuario actual se aplican durante la ejecución del código.
    • WITH SECURITYENFORCED se eliminó, lo que provoca un error de compilación. Sustituya cualquier uso existente por WITH USER_MODE. La plataforma aplica el acceso en la interfaz de usuario estándar.
  • En la versión 66.0 o anterior de la API, el modo del sistema es el predeterminado. Utilice WITH USERMODE en consultas SOQL o Security.stripInaccessible() para operaciones DML.
• A01:2025 - API de datos del lado del cliente: Lightning Data Service y la API de la interfaz de usuario aplican automáticamente FLS, CRUD y colaboración del usuario que ejecuta, de modo que un componente creado sobre ellos hereda el menor privilegio de forma predeterminada.
  • Esta protección se pierde cuando un componente llama a un Apex personalizado. Apex imperativa solo aplica el acceso cuando se ejecuta en modo de usuario, de modo que una clase declarada sin colaboración actúa como una compuerta de escape que omite silenciosamente el modelo.
  • Utilice Lightning Data Service y la API de la interfaz de usuario para el acceso a los datos.
  • Debe reafirmar CRUD, FLS y colaboración para cada llamada Apex imperativa desde un componente.
• A02:2025 - Fallo de configuración de seguridad: Monitoree la desviación de configuración desde las líneas base de seguridad utilizando Comprobación de estado.
  • Desactive el acceso Usuario invitado en sitios de Experience Cloud (a menos que se requiera explícitamente bajo una justificación de negocio documentada).
• A05:2025 - Inyección: La categoría Inyección 2025 abarca la inyección SOQL/SOSL y las secuencias de comandos de sitio cruzadas (XSS).
  • Para la inyección de consultas, utilice variables de vinculación para todas las consultas dinámicas. Nunca concatene la entrada de usuario directamente en cadenas de consulta. Los mecanismos de consulta parametrizados de la plataforma eliminan el riesgo de inyección cuando se utilizan correctamente.
  • Las inyecciones de SOQL o SOSL tienen ámbito a una lectura que revela registros o campos a los que la persona que llama no debería poder acceder ampliando las condiciones de consulta. Como estos idiomas leen datos mientras escriben se ejecutan en operaciones DML separadas, esto crea un riesgo de control de acceso y confidencialidad porque se complica cuando los permisos de objeto y campo no se aplican en la consulta.
  • Para XSS, los componentes web Lightning proporcionan protección automática a través del motor de representación LWC.
  • Para componentes Aura y Visualforce, debe aplicar funciones de codificación de plataforma (por ejemplo, HTMLENCODE, JSENCODE y URLENCODE) al representar contenido dinámico.

Su responsabilidad: Aplique CRUD/FLS en código personalizado, aplique funciones de codificación, utilice variables de vinculación y monitoree la desviación de configuración.

Diseñe oportunidades en curso de CI/CD con puertas de seguridad en cada etapa. La seguridad debe automatizarse para ampliarse con la velocidad de desarrollo.

Echemos un vistazo con más detalle a las etapas de seguridad de las oportunidades en curso.

• El control de origen utiliza reglas de protección de sucursales con revisiones de código requeridas. No hay confirmaciones directas en sucursales principales o confirmaciones firmadas.
• El análisis estático utiliza Salesforce Code Analyzer, que incorpora PMD, ESLint y RetireJS para detectar patrones de inyección, XSS e inseguros.
• El escaneo de seguridad utiliza herramientas SAST y detección de secretos para evitar confirmaciones de credenciales y el escaneo de vulnerabilidades de dependencias.
• La validación de permisos utiliza técnicas de comparación automatizadas para revisar los cambios de permisos en las líneas base de seguridad, lo que envía alertas sobre la expansión de privilegios.
• Las puertas de implementación interrumpen la implementación en hallazgos de seguridad críticos que requieren la aprobación del equipo de seguridad para cambios de ampliación de permisos.
• El monitoreo posterior a la implementación utiliza alertas de Monitoreo de eventos para comportamientos anómalos tras las implementaciones.

Su responsabilidad: Integre Code Analyzer en CI/CD, configure la protección de sucursales, implemente puertas de implementación y valide permisos automáticamente.

Las pruebas de seguridad integrales incluyen múltiples técnicas que solucionan diferentes clases de vulnerabilidad. Echemos un vistazo más detallado a cada estrategia.

• Análisis estático ejecuta Salesforce Code Analyzer en IDE de desarrollador para comentarios inmediatos, y en oportunidades en curso de CI/CD como puertas automatizadas. El análisis estático identifica vulnerabilidades en el código fuente sin ejecutar la aplicación.
• Pruebas de penetración realiza pruebas de penetración para aplicaciones personalizadas que están expuestas a usuarios que no son de confianza, en particular sitios de Experience Cloud y API de cara al público.
  • Para AppExchange y Revisión de seguridad de AgentExchange, siempre se requieren reportes de análisis estáticos.
  • Se requiere un reporte de exploración dinámica (prueba de penetración) cuando la solución integra una aplicación o servicio web externo.
  • Las pruebas de penetración simulan técnicas de atacante en aplicaciones en vivo.
• Pruebas de unidad centradas en la seguridad redactan pruebas de Apex que validan la aplicación del control de acceso ejecutándose como usuarios con diferentes perfiles de permisos. Es importante verificar que la aplicación CRUD/FLS bloquea el acceso no autorizado.
• La exploración de dependencias monitorea paquetes de AgentExchange y bibliotecas JavaScript para vulnerabilidades conocidas. Es importante suscribirse a avisos de seguridad para paquetes instalados.

Su responsabilidad: Ejecute Code Analyzer, realice pruebas de penetración, redacte pruebas de unidades de seguridad, explore dependencias.

En Salesforce, la respuesta ante incidentes de datos y seguridad se centra en detectar, contener y recuperarse de infracciones, acceso no autorizado y destrucción de datos maliciosos. Los equipos de respuesta a incidentes trabajan junto con dos pilares vecinos que poseen responsabilidades adyacentes:

• Operational Excellence cubre el mecanismo operativo de gestión de incidentes (por ejemplo, niveles de gravedad, rotación de llamadas, distribución y revisión posterior a incidentes)
• La fiabilidad cubre la recuperación de disponibilidad frente a objetivos de RTO y RPO, incluyendo la estrategia de copia de seguridad y recuperación de desastres.

Como arquitecto, es su responsabilidad diseñar para la capacidad de detección, respuesta y recuperación de incidentes de seguridad.

La detectabilidad es una cualidad arquitectónica para la que debe diseñar de forma explícita. Sin un monitoreo integral, los incidentes de seguridad podrían permanecer sin detectarse durante periodos de tiempo prolongados.

Es importante implementar la detección a través de múltiples canales.

• Monitoreo de eventos captura registros de eventos sin procesar que cubren inicios de sesión, exportaciones de reportes y datos, cambios de permisos y llamadas de API. Debe identificar qué eventos son anómalos, lo que requiere políticas de Seguridad de transacciones o correlación SIEM en la parte superior de los registros que configura para determinar la lógica de detección.
• Las políticas de seguridad de transacciones evalúan eventos en tiempo real y bloquean acciones sospechosas. Debe configurar estas políticas.
• Seguimiento de auditoría de configuración realiza un seguimiento de los cambios administrativos que proporciona la plataforma, pero debe monitorearlos.
• El registro de aplicaciones personalizado captura eventos relevantes para la seguridad en Apex que necesita implementar.

Enrute registros de Monitoreo de eventos a plataformas SIEM para su correlación con la telemetría de seguridad de la compañía. Diseñe reglas de alerta que detectan patrones sospechosos minimizando al mismo tiempo los falsos positivos a través de líneas base de comportamiento.

Su responsabilidad: Enrute Monitoreo de eventos a SIEM, configure políticas de Seguridad de transacciones, implemente el registro personalizado, establezca líneas base de comportamiento.

Es importante documentar las decisiones de arquitectura que admiten la respuesta ante incidentes antes de que se produzcan incidentes.

• Los límites de aislamiento diseñan soluciones para aislar componentes comprometidos sin interrumpir funciones de negocio críticas. Debe configurar la revocación del conjunto de permisos, los cambios de restricción de IP y la terminación de sesión para proporcionar funciones de aislamiento rápido.
• La conservación forense utiliza Monitoreo de eventos para proporcionar registros de actividad detallados (función de plataforma). Seguimiento de auditoría de campo conserva el historial de cambios de datos basándose en su configuración. Diseñe el enrutamiento de los registros al almacenamiento inmutable de modo que los atacantes no puedan modificar su arquitectura.
• Los procedimientos de recuperación documentan procesos de recuperación probados para tipos de incidentes comunes. Es importante validar la integridad de la copia de seguridad regularmente. Necesita conocer su Objetivo de tiempo de recuperación (RTO) y Objetivo de punto de recuperación (RPO) para escenarios de incidentes de seguridad.
• Los flujos de trabajo de comunicación diseñan mecanismos de notificación que funcionan durante incidentes (por ejemplo, canales de comunicación fuera de banda, plantillas redactadas previamente y procedimientos de distribución que no dependen de sistemas potencialmente comprometidos).
• El canal de revelación de vulnerabilidades es para sitios de Experience Cloud de cara al público. Proporciona a investigadores externos una forma documentada y monitoreada de reportarle problemas de seguridad a través de una política de revelación publicada en el estándar RFC 9116 security.txt. Un reporte externo es a menudo la primera señal de un incidente, por lo que es importante establecer esta ruta de admisión como parte de la arquitectura de la que es responsable.

Su responsabilidad: Documente procedimientos de aislamiento, enrute registros a almacenamiento externo inmutable, pruebe procedimientos de recuperación trimestralmente, establezca comunicación fuera de banda y publique un canal de revelación de vulnerabilidades para sitios de cara al público.

En Salesforce, es importante preparar funciones de respuesta para escenarios específicos de plataforma.

• Las cuentas de usuario comprometidas se detectan a través de anomalías de inicio de sesión de Event Monitoring (por ejemplo, geografía inesperada, horas inusuales y nuevos dispositivos). Cuando las cuentas están comprometidas, inmovilice el usuario, fuerce el restablecimiento de credenciales, revise la Configuración del seguimiento de auditoría y los registros de acceso a datos para determinar el periodo de compromiso.
• La exfiltración de datos masiva se detecta a través de exportaciones de reportes de Monitoreo de eventos y anomalías de volumen de acceso a datos de API. Cuando se produzca la exfiltración de datos, revoque sesiones inmediatamente, restrinja permisos e identifique registros y niveles de clasificación afectados.
• La implementación de código no autorizado se detecta a través del monitoreo de la implementación y los cambios de configuración del seguimiento de auditoría de configuración. Cuando se implementa código no autorizado, revierta inmediatamente la implementación y audite todos los cambios desde la credencial de implementación comprometida.
• La distribución de privilegios se detecta a través del monitoreo del seguimiento de auditoría de configuración para cambios de permisos que están fuera de los plazos de cambio aprobados. Cuando se produzca la distribución de privilegios, revoque inmediatamente los privilegios distribuidos y audite las actividades que se realizaron con acceso elevado.

Su responsabilidad: Documente procedimientos de respuesta para escenarios específicos de plataforma, configure el monitoreo para detectar cada escenario, pruebe procedimientos a través de ejercicios de sobremesa.

Después de un incidente, es importante realizar una revisión posterior al incidente sin juicios centrada en mejoras arquitectónicas. Debe documentar lo que sucedió, por qué los controles existentes fallaron para evitar o detectar el incidente y qué cambios arquitectónicos se necesitan para reducir riesgos futuros.

Objetivos de revisión posterior al incidente:

• Determine la cronología del incidente y las técnicas del atacante.
• Identifique los fallos de control que activaron el incidente.
• Documente todas las debilidades arquitectónicas que reveló el incidente.
• Dé prioridad a la solución basada en la reducción de riesgos.
• Comparta lecciones aprendidas entre equipos.
• Actualice las reglas de detección y los procedimientos de respuesta.

Es importante realizar un seguimiento de mediciones de incidentes a lo largo del tiempo para determinar el tiempo medio de detección (MTTD), el tiempo medio de respuesta (MTTR) y el ámbito de repercusión.

Su responsabilidad: Dirija una revisión posterior al incidente oportuna, documente mejoras en las evaluaciones de resultados, realice un seguimiento de tendencias de MTTD y MTTR, comparta lecciones aprendidas.

Utilice esta lista de comprobación durante revisiones de arquitectura, antes de la implementación de producción y periódicamente para una evaluación continua. Cada elemento representa sus responsabilidades como arquitecto de Salesforce.

Responsabilidad compartida

• Documente todo lo que Salesforce asegura (por ejemplo, infraestructura, plataforma y certificaciones de cumplimiento).
• Documente todo lo que debe proteger (por ejemplo, configuración, acceso, código personalizado y regulación de datos).
• Identifique áreas de responsabilidad compartida (por ejemplo, respuesta ante incidentes, gestión de vulnerabilidades y monitoreo).
• Comunique las responsabilidades a las partes interesadas y los equipos de implementación de la forma más clara y concisa posible.

Arquitectura de seguridad

• Complete el modelado de amenazas utilizando la metodología STRIDE antes de empezar a construir.
• Aplique controles de defensa en profundidad en capas de datos, aplicación, identidad e integración.
• Implemente principios de zero Trust que requieren verificación explícita para cada solicitud de acceso.
• Mantenga el inventario de activos de seguridad actual que cubre datos confidenciales, integraciones, API y cuentas privilegiadas.
• Documente decisiones de arquitectura de seguridad en ADR, incluyendo análisis de amenazas y justificación de control.
• Proteja clientes desatendidos y en nombre de clientes en el límite de Salesforce Trust propagando identidades por usuario en vez de agrupar tokens.
• Almacenar, rotar y credenciales de OAuth con el menor ámbito de privilegios a través de aplicaciones cliente externas.
• Para integraciones en contenedores, aplique el aislamiento de contenedores como límite de seguridad, cifre el tráfico VPN híbrido e intercontenedor con mTLS (cuando el marco lo requiera) y alinee regiones de implementación con certificaciones de residencia y cumplimiento de datos

Gestión de identidad y acceso

• Establezca OWD como Privada para objetos que contienen datos confidenciales.
• Reserve Solo lectura pública para objetos donde el acceso de lectura amplio es un requisito documentado.
• Aplique MFA para todo el acceso de la interfaz de usuario de producción y llaves de seguridad de hardware para cuentas privilegiadas. Las integraciones solo de API que utilizan el portador de JWT o credenciales de cliente están exentas.
• Implemente SSO utilizando SAML 2.0 u OpenID Connect con autenticación de IdP sólida.
• Utilice OAuth 2.0 (portador JWT preferido) para toda la autenticación de API. Nunca utilice OAuth 2.0 para credenciales integradas.
• Otorgue acceso a través de conjuntos de permisos basados en requisitos de privilegios mínimos documentados.
• Aplique controles mejorados a cuentas de impacto crítico (por ejemplo, restricción de IP, alertas de inicio de sesión y revisiones de acceso periódicas).
• Realice revisiones de acceso periódicas utilizando certificados documentados para cuentas de alto privilegio donde la frecuencia se determina por la tolerancia al riesgo organizativo y los requisitos de cumplimiento.
• Automatice el ciclo de vida de identidad a través del aprovisionamiento SCIM y la detección de cuentas latentes de 90 días.
• Ejecute agentes de empleados en el contexto del usuario que inició sesión, y aprovisione Usuarios de agente con menos privilegios exclusivos para agentes de clientes. Nunca haga esto para un usuario invitado de sitio público.
• Implemente JWT para la autenticación de agentes utilizando identificadores de instancia de agente y definición de bot.
• Defina políticas de ABAC que se alinean con la clasificación de datos y estándares de etiquetado de metadatos coherentes.

Privacidad y protección de datos

• Clasifique todos los datos y aplique controles de protección apropiados para cada nivel de clasificación.
• Active Shield Platform Encryption para datos restringidos utilizando la gestión de claves documentada.
• Requerir TLS 1.2+ para todas las integraciones con autenticación basada en certificado para datos restringidos.
• Evite que los datos restringidos entren en entornos que no son de producción a través del enmascaramiento o la exclusión.
• Implemente la gestión del consentimiento con flujos de trabajo granulares de seguimiento y retirada por propósito.
• Cree flujos de trabajo de derechos de titulares de datos que se completen dentro del plazo de respuesta de cada marco de trabajo vigente. Estos deben dimensionarse en el plazo más ajustado de su huella operativa y parametrizarse por jurisdicción desde un origen de cumplimiento mantenido donde cada cifra se confirma en la regulación vigente.
• Documente los requisitos de residencia de datos y valide la alineación de regiones Hyperforce.

Cumplimiento y cumplimiento normativo

• Valide las certificaciones de plataforma que cumplen los requisitos normativos para su industria.
• Active Monitoreo de eventos con enrutamiento SIEM para la retención que supera los límites de retención nativos.
• Configure Seguimiento de auditoría de campo para cubrir campos Restringidos para garantizar que la retención cumple los mínimos reglamentarios.
• Mantenga puntuajes de Comprobación de estado de seguridad del 80% o superiores (banda Muy buena o Excelente) y documente cualquier excepción.
• Automatice la validación de cumplimiento para oportunidades en curso de CI/CD que se interrumpen durante infracciones críticas.
• Implemente políticas de Seguridad de transacciones para la detección y respuesta de anomalías en tiempo real.

Ciclo de vida de desarrollo seguro

• Realice modelos de amenazas durante la fase de diseño (antes de realizar inversiones de construcción significativas).
• Aplique CRUD/FLS en todos los entornos Apex.
• Confíe en la aplicación automática del modo de usuario para la versión 67.0 o posterior de la API, o utilice WITH USERMODE o stripInaccessible() para la versión 66.0 o anterior de la API.
• No utilice WITH SECURITYENFORCED, que se eliminó en la versión 67.0 de la API.
• Ejecute Salesforce Code Analyzer en CI/CD cuando los hallazgos críticos bloqueen la implementación.
• Requiera revisiones de código por revisores de seguridad para todos los cambios de producción.
• Realice pruebas de penetración para todas las aplicaciones de cara al público y sitios de Experience Cloud.
• Valide y desinfecte todas las entradas de usuario que evitan la inyección en contextos SOQL, SOSL y HTML.

Respuesta ante incidentes de seguridad

• Diseñe reglas de alerta de Event Monitoring para detectar patrones sospechosos a través de líneas base de comportamiento.
• Enrute registros a almacenamiento externo inmutable para su conservación forense.
• Documente y pruebe procedimientos de respuesta ante incidentes para escenarios específicos de plataforma.
• Realice revisiones posteriores a incidentes sin culpa con ADR para capturar mejoras arquitectónicas.
• Realice un seguimiento de mediciones de MTTD y MTTR para identificar brechas de detección y respuesta.

Comparta sus comentarios sobre el Marco de trabajo bien diseñado.