Trust

En Salesforce, Trust es nuestro valor #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 única: 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 opera 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 infraestructura, parches y certificaciones de cumplimiento.
• Usted es responsable de la seguridad en la plataforma, incluyendo configuración, controles de acceso, código personalizado y 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 que se crean 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 cumplimiento normativo y funciones de respuesta a 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 trabajan juntas de forma cohesiva:

• 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 las obligaciones normativas

Los arquitectos que diseñan para las cuatro dimensiones crean soluciones que se 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 identidad y permisos claros, lo que permite a los sistemas de IA razonar y actuar en nombre de los usuarios mientras mantienen 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 los riesgos exclusivos de los agentes autónomos, incluida la inyección rápida, la regulación 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 de controles específicos de 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 responsabilidades respectivas de mantener Trust. Echemos un vistazo más de cerca a lo que cada parte debe proteger.

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

• Controles de acceso al centro de datos, vigilancia y protecciones 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 de 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)

• Respuesta de vulnerabilidad e implementación de parches de plataforma 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 (con ámbito a Government Cloud Plus y MuleSoft Government Cloud, no la plataforma comercial multiusuario) y la validación PCI DSS Nivel 1.
• Apoyo normativo: Esto se aplica a servicios aptos para la HIPAA con Acuerdos de socios comerciales (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 divide 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 ambos 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 permanece segura, fiable y en conformidad.

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 privilegios mínimos (PoLP): Utilice el PoLP para otorgar acceso únicamente a 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 reglas de colaboración y permisos CRUD
• Posea, 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 dentro de 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 un ámbito y sea auditable por separado de los usuarios humanos.
• Proteja los extremos y la validación del sistema externo.

• Utilice Supervisión 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 a 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 el código personalizado.
• Supervisión 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 poseen lo que está construido en ella (objetos personalizados, código, integraciones y configuración) dentro del estado certificado 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 el 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 comprobació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 la plataforma Salesforce.

El límite se extiende a obligaciones reguladoras. Salesforce mantiene las certificaciones y certificaciones de la plataforma y protege la infraestructura contra brechas. 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, ya que 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 en sus propios méritos (identidad, autorización y contexto) en vez de confiar en ella para el lugar donde se originó.
• Otorgue el privilegio mínimo de forma predeterminada. Otorgue el nivel mínimo de acceso necesario para cada usuario, integración y proceso automatizado para cumplir 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 comerciales 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 de CRUD/FLS y políticas de Seguridad de transacciones que bloquean operaciones), controles de detective (por ejemplo, Supervisión 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. Cree 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 datos necesarios), limitación de propósitos (restringir el acceso por función de trabajo), gestión de consentimiento (aplicar consentimiento granular específico de propósito) y derechos de titulares de datos (activar flujos de trabajo de acceso, rectificación, borrado y portabilidad para completar en plazos reglamentarios).
• Diseño para trazabilidad. Haga que cada acción resultante sea atribuible y reconstruible después del hecho, antes de confiar 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 a prueba de manipulaciones. La trazabilidad es la condición previa para la detección, el análisis forense y la rendición de cuentas. Recuerde: no puede investigar lo que nunca se registró.
• Diseño para respuesta de incidentes. Diseño para la detectabilidad a través de Supervisión 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 a menudo llaman 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 posee el Trust Border donde se reúne con Salesforce para determinar cómo se autentican, qué identidad y permisos llevan, qué secretos guardan y qué datos cruzan el límite.

Los principios que se indican a continuación 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 para actuar en su nombre. Prefiera esto a una cuenta de servicio compartida dondequiera que se realice el trabajo para un usuario específico.

Diseñe el límite a la defensiva, porque un cliente que alberga 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 en cientos de organizaciones.

• Propagar la identidad de usuario, no agruparla. 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 Identidad y autenticación de agentes), de modo que los compromisos tengan ámbito al contexto de un usuario en vez de a todos ellos.
• Trate las credenciales de cliente de OAuth y los 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. Supervise 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 supervisión 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í mismo un control de seguridad: cada aplicación se ejecuta en un contenedor exclusivo sin tiempo de ejecución o memoria compartidos 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 de 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 y 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 confiar 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 de 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 de 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 eviten el tráfico no autorizado entre contenedores.

El cifrado del 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 pivotar 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 un cifrado documentado en tránsito para integraciones híbridas.

Los arquitectos deben diseñar políticas de VPN que apliquen el acceso de red con menos privilegios. 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 vanity (por ejemplo, direcciones URL personalizadas para API de integración) requieren que los arquitectos gestionen certificados TLS como Trust anchors:

Los dominios vanity (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 automatizada de certificados. Los certificados caducados rompen integration Trust; 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 reemisión e implementación de certificados en todas las regiones.
• Configuración de conjunto de cifrado: Las configuraciones de 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 certificados: 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 integra en el certificado a través de una extensión X.509v3. Los arquitectos deben supervisar 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 al estado Trust:

• Certificados caducados: Provoca fallos de autenticación que aparecen como cortes. La supervisión debe incluir el envío de alertas en 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 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 producen fuera de la UE siguen siendo permisibles en virtud de una decisión de adecuación, Cláusulas Contractuales Estándar (CCS) o Reglas Corporativas Obligatorias (BCR).
• 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 pueden requerir la implementación de contenedores en el país. La Ley DPDP 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 restrinja 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 regional son responsabilidades del arquitecto que afectan directamente al cumplimiento normativo. Los equipos financieros 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 almacenes de secretos gestionados por plataforma.
• Inyección secreta gestionada 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 los valores de configuración que albergan credenciales como protegidos 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ñas de bases de datos no deben requerir la reimplementació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 procesos de gestión de secretos que puedan sobrevivir a revisiones de código, registros, mensajes de error y paneles de supervisión sin filtrar credenciales.

Las aplicaciones en el límite de Salesforce generan eventos de auditoría que cumplen 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 la supervisión 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 regulación, 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 respecto a la regulación vigente en vez de valores de codificación.
• Cifrado de registros y controles de acceso: Los registros de auditoría pueden contener metadatos confidenciales. Los registros deben cifrarse en tiempo de inactividad y controlarse el acceso únicamente al personal de seguridad/cumplimiento autorizado. Un registro insuficiente evita la investigación de incidentes y no supera las auditorías de cumplimiento. Los arquitectos deben equilibrar la verbosidad del registro (por ejemplo, impacto en el rendimiento y costes 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 de él. 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 enumerados 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 entre organizaciones 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 la plataforma.
• Los componentes Apex y Lightning personalizados requieren un análisis de codificación seguro para inyección, XSS y 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 tiempo de instalación o en tiempo de ejecución.

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

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

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

Aplique controles de seguridad en cada capa de la pila de soluciones. Tenga en cuenta 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, múltiples controles independientes crean resiliencia.

Zero Trust elimina Trust implícita basándose en posición de red o estado de autenticación anterior. 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 token de OAuth en cada llamada, TLS mutua basada en certificado y lista de admisión de 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 menos privilegios y supervisar 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 configuración operativa que cubre Operational Excellence (por ejemplo, la versión de parámetros de organización y la detección de desviación de configuración para la estabilidad operativa). En otras palabras, la preocupación aquí es más estrecha: ¿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:

• Objetos y campos 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 de 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 de API 66.0 o anterior, 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 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 con más detalle a cómo diseñar y configurar correctamente controles utilizando el PoLP.

Salesforce aplica el control de acceso a través de cuatro capas diferentes: organización, objeto, campo y registro. Debe diseñar soluciones que aprovechen las cuatro capas deliberadamente. El control de acceso principal está basado en otorgamiento, 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 su capacidad de restricción, pero aumentan el esfuerzo: ampliar los valores predeterminados de toda la organización o los permisos de objeto de forma temprana significa confiar 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: las reglas de restricción al filtrado a nivel de registro y el 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 permisivos establecidos 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 eliminar 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 en registros a los que ya tienen acceso, de modo que los usuarios con acceso a objetos amplios 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 reunir acceso desde grupos reutilizables y luego eliminar lo que una población determinada no debería tener.
• Alcance estas reglas cuando las capas basadas en subvenciones 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 extiende al acceso solo de API: Las integraciones que utilizan flujos de portador de JWT o credenciales de cliente están exentas, por lo que debe proteger esas integraciones con gestión de certificados y restricciones de IP 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 facilidad de uso:

• Tiempo de espera: Configure los tiempos de espera de sesión apropiados para los niveles de privilegios de usuario (tiempos de espera más cortos para cuentas de privilegios altos 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 nativos de Salesforce (verificación de identidad para inicios de sesión desde dispositivos desconocidos) 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 las 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 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 informes o gestionar intervalos de IP), de modo que un inicio de sesión rutinario no pueda alcanzar por sí mismo acciones de alto impacto. En Lightning Experience, el paso de una sesión estándar a Alta seguridad volviendo a solicitar MFA no es compatible, 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: Requerir 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 las cuentas de integración y servicio a la autenticación solo de API con el permiso Solo usuario 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 obsoleto.

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 de navegador repetidas).
• 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 rotar 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 desatendido 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 dispositivos (para dispositivos desatendidos): Tenga en cuenta que desde el 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 ha publicado planes de jubilación para este flujo. Las integraciones existentes que aún se basan en el 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 deuda técnica aplazada.

Estos flujos se configuran en el registro de 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 en 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, de modo que tenga 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 el ámbito solo de 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 como “Los usuarios aprobados por el administrador se han autorizado 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 lista de admisión): Para controles más estrictos, el Control de acceso de API limita los usuarios aprobados por el administrador solo a aplicaciones conectadas en la lista de admisión. 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 los 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 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. La ejecución 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), sin dejar de estar vinculados por permisos explícitos de menor privilegio. Cuando cree 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 en una cuenta de servicio. Supervise la actividad de agentes a través de Supervisión 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 en torno a necesidades de acceso a datos (que los usuarios requieren acceso a registros propiedad de otros), no el gráfico de creación de informes 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 privado 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 de formatos de página, los valores predeterminados de 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 los patrones normales, inicios de sesión desde geografías inesperadas y cambios de permisos fuera de los plazos de cambio.

Los controles de seguridad conllevan compensaciones 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 comercial válida; por lo tanto, aplique estos controles a un riesgo genuino, escénelos en modo de solo monitor antes de aplicarlos y diseñe una ruta de interrupción para cuando un control falle.

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 para 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 opera 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 se deben eliminar explícitamente para activar políticas de gobernanza granulares.

Su uso arquitectónico principal es la aplicación de la clasificación de datos; consulte Clasificación de datos bajo Protección y privacidad de datos para ver cómo los niveles de clasificación dirigen la aplicación de ABAC.

Este nivel de granularidad conlleva un coste 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 un requisito de diseño: aplicar etiquetas de forma coherente, mantener el conjunto de políticas pequeño y nombrado para la clasificación que aplica y preservar 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 de forma genuina, en vez de tratarlo como un reemplazo 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
• Realizar revisiones de acceso periódicas con certificado documentado para cuentas de altos privilegios donde la frecuencia se determina por tolerancia al riesgo organizacional 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
• Supervisar patrones de uso de API anómalos a través de Supervisión 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 de dominios cruzados (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 de trabajo, que se desencadena por eventos del sistema de recursos humanos.
• 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 gerentes revisen y validen periódicamente los permisos de sus equipos. La frecuencia de revisión se basa en los requisitos de riesgo y cumplimiento.

Su responsabilidad: Implemente SCIM, diseñe flujos de trabajo de aprovisionamiento y realice una nueva certificación trimestral.

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

El aislamiento es el beneficio clave. Las organizaciones separadas proporcionan el límite más fuerte posible entre conjuntos de datos. No hay un modelo de colaboración colectiva y no hay sangrado 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 cuenta de impacto crítico, líneas base de Comprobación de estado, Supervisión de eventos y correlación SIEM) ahora se multiplica 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 supervisar.

Por eso es importante ponderar el beneficio de aislamiento con el multiplicador de regulación 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 única organización. Cuando lo adopte, debe diseñar el modelo de acceso, la supervisión 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 coste. Donde se requiere múltiples organizaciones, aplique controles de acceso, supervisión 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 con más detalle a cómo proteger adecuadamente los datos y la privacidad.

Para clasificar correctamente sus datos, necesita conocer sus datos. La tarea arquitectónica general es comprender su dominio comercial 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 supervisión. 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 que puede adaptar a los requisitos normativos y las necesidades comerciales de su organización. Muchas empresas utilizan modelos similares alineados con los estándares del sector (por ejemplo, ISO 27001 y NIST). Su implementación específica debe reflejar sus obligaciones de cumplimiento (por ejemplo, HIPAA, PCI DSS, RGPD y leyes del sector) y contexto comercial.

Aplique la clasificación a nivel de campo. Un único registro Cuenta puede contener campos Público (por ejemplo, nombres de empresa), campos Confidencial (por ejemplo, ingresos de empresa) 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:

• Restringir 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 única decisión de autorización.

Diseñe políticas de ABAC para alinearse con este esquema de modo que clasificar 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, entrene 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 dirijan la aplicación.

Comience con la información que la plataforma ya proporciona para cada organización. Los datos en reposo se cifran 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 de 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 la clave 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 de agregación (por ejemplo, funciones MAX(), MIN() y COUNT_DISTINCT()).

El cifrado determinista permite el filtrado de coincidencia exacta en informes, vistas de lista y cláusulas WHERE de SOQL (distingue entre mayúsculas y minúsculas) a una fuerza 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 informes y operaciones SOQL.

Las claves controladas por el cliente se presentan en dos formas diferentes:

• Bring Your Own Key (BYOK) le permite generar material de claves fuera de Salesforce (utilizando sus propias bibliotecas de criptomonedas, sistema de gestión de claves de empresa o módulo de seguridad de hardware) y suministrarlo a la plataforma.
• El servicio de claves de solo caché mantiene su clave de cifrado de datos en un servicio de claves que controla. Salesforce lo obtiene bajo demanda 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 protegió 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 necesita implementar la autenticación mutua basada en certificado 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. A continuación, seleccione esquemas de cifrado, seleccione y opere una estrategia de claves controlada por el cliente e implemente una autenticación basada en certificado para integraciones confidenciales.

Proteja datos confidenciales en entornos que no son 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. Cree 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 comerciales declarados. Desafía 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 apliquen 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 propaguen 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 permisible hacerlo) y portabilidad (por ejemplo, exportando a un formato legible por máquina). Diseñe estos flujos de trabajo para completarse en el plazo de respuesta que impone cada marco de trabajo. Estos plazos varían por jurisdicción (y se modifican 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 respecto a 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, 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 legítimamente las fronteras.

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 dentro del 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. Dado que esta lista puede cambiar, es importante confirmar el mandato específico en 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 estos casos, la decisión se basa en qué región minimiza la latencia y simplifica el cumplimiento.

Cuando los datos cruzan un borde, el punto es la conciencia antes de la configuración. En otras palabras, necesita 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. Cuando existen, 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.

Empareje el mecanismo de transferencia con acceso de registro restrictivo (por ejemplo, OWD privados y colaboración con fines específicos) de modo que una transferencia permisible no se vuelva demasiado amplia. Los mapas de flujo de datos de documentos muestran 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 las obligaciones de residencia por categoría de datos, confirme la disponibilidad regional antes del aprovisionamiento, 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 directriz es direccional. Los requisitos normativos varían según la jurisdicción y cambian con el tiempo. Siempre debe verificar obligaciones específicas con respecto a la regulación vigente (por ejemplo, el estatuto aplicable, la autoridad de supervisión o la documentación de cumplimiento de Salesforce) 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 en infraestructura de plataforma y 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 el estado de cumplimiento, documente cómo la arquitectura satisface los requisitos normativos.

• Active Shield Platform Encryption para todos los campos que contienen información de salud 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 con respecto al reglamento vigente.
• Configure Monitorización de eventos para detectar patrones de acceso de PHI no autorizados.
• Implemente todas las protecciones 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 el uso compartido 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 respecto a 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 la supervisión continua a través de Supervisión 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 se tratan en Protección y privacidad de datos.

Para cumplir con estas regulaciones, debe:

• Clasificar dónde debe residir cada categoría de datos
• Confirme 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 decisión.

Todo fuera de esto se considera una cifra de punto en el tiempo (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 las leyes, varían por marco y se modifican en las programaciones de los reguladores.

No los codifique aquí. Debe determinar los siguientes pasos basándose en la regulación reguladora 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.

• Un plazo de solicitud de asunto de datos que se mide en días de un solo dígito no se puede cumplir por 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.
• Una ventana de notificación de infracción es demasiado estrecha 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 Supervisión de eventos, funciones asignadas previamente, notificaciones de regulador y asunto de datos redactadas previamente y una ruta de distribución que asume el plazo más ajustado 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 Protección y privacidad de datos, automatice los flujos de trabajo de DSR y de respuesta a infracciones al plazo más ajustado en su huella, y confirme cada cifra específica de la jurisdicción con respecto a 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 puntuaciones de riesgo. Ejecute comprobaciones regularmente para supervisar el cumplimiento de las recomendaciones de línea base de seguridad de Salesforce. Mantenga puntuaciones del 80% o superiores (bandas Muy buenas o Excelentes).
• Monitorización de eventos captura registros detallados para actividad de usuario, 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 las políticas en tiempo real y puede bloquear eventos, requerir un aumento de MFA o notificarle infracciones de políticas.

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

Su responsabilidad: Ejecute Comprobación de estado trimestralmente, enrute Supervisión 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 Supervisión 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 reglamentarios.

Su responsabilidad: Active Seguimiento de auditoría de campo para campos confidenciales, enrute Supervisión 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 que 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 conversación en solucionarse. Sin embargo, cuando se encuentra el mismo fallo en producción requiere rearquitectura, migración de datos, solución de cumplimiento y posible notificación de brecha.

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
• Formación de codificación segura 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 conscientes de la 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 asigna al 10 principal OWASP 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 posterior de la API, Apex se ejecuta en contexto de usuario de forma predeterminada, lo que significa que los permisos del usuario actual y FLS se aplican durante la ejecución del código.
    • CON 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 de API 66.0 o anterior, 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 el FLS, CRUD y la colaboración del usuario que ejecuta, de modo que un componente creado sobre ellos hereda el privilegio mínimo de forma predeterminada.
  • Esta protección se pierde cuando un componente llama a un Apex personalizado. Apex imperativo solo impone 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 - Error de configuración de seguridad: Supervise la desviación de configuración de las líneas base de seguridad utilizando Comprobación de estado.
  • Desactive el acceso de Usuario invitado en sitios de Experience Cloud (a menos que se requiera explícitamente bajo una justificación comercial documentada).
• A05:2025 - Inyección: La categoría Inyección 2025 cubre inyección de SOQL/SOSL y secuencias de comandos de sitio cruzado (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 SOQL o SOSL tienen un ámbito de lectura que revela registros o campos a los que la persona que llama no debería poder acceder ampliando las condiciones de consulta. Dado que estos idiomas leen datos mientras escriben se ejecutan a través de 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, supervise 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 a escala 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 obligatorias. No hay confirmaciones directas a 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 vulnerabilidad de dependencias.
• La validación de permisos utiliza técnicas de comparación automatizadas para revisar los cambios de permisos con respecto a las líneas base de seguridad, 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.
• La supervisión posterior a la implementación utiliza alertas de Supervisión de eventos para un comportamiento anómalo 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 con más detalle a cada estrategia.

• El 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 AgentExchange Security Review, siempre se requieren informes de análisis estáticos.
  • Se requiere un informe de análisis dinámico (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 de CRUD/FLS bloquea el acceso no autorizado.
• El escaneo de dependencias supervisa 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, escriba pruebas de unidad de seguridad, analice dependencias.

En Salesforce, la respuesta a incidentes de datos y seguridad se centra en detectar, contener y recuperarse de brechas, accesos no autorizados 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 a petición, 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 ante 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 una supervisión exhaustiva, los incidentes de seguridad pueden permanecer sin detectar durante largos períodos de tiempo.

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

• Monitorización de eventos captura registros de eventos sin procesar que cubren inicios de sesión, exportaciones de datos e informes, 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.
• La configuración del seguimiento de auditoría realiza un seguimiento de los cambios administrativos que proporciona la plataforma, pero debe supervisarlos.
• El registro de aplicaciones personalizado captura eventos relevantes para la seguridad en Apex que necesita implementar.

Enrute registros de Supervisión de eventos a plataformas SIEM para su correlación con la telemetría de seguridad empresarial. Diseñe reglas de alerta que detectan patrones sospechosos mientras minimizan los falsos positivos a través de líneas base de comportamiento.

Su responsabilidad: Enrute Supervisión 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 a incidentes antes de que se produzcan incidentes.

• Los límites de aislamiento diseñan soluciones para aislar componentes comprometidos sin interrumpir funciones comerciales críticas. Debe configurar la revocación del conjunto de permisos, los cambios de restricción de IP y la finalización de sesión para proporcionar funciones de aislamiento rápido.
• La conservación forense utiliza Supervisión 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 registros a 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 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 los investigadores externos una forma documentada y supervisada de informarle de problemas de seguridad a través de una política de revelación publicada en el estándar RFC 9116 security.txt. Un informe 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 Supervisión de eventos (por ejemplo, geografía inesperada, horas inusuales y nuevos dispositivos). Cuando las cuentas están comprometidas, congele el usuario, fuerce el restablecimiento de credenciales, revise la Configuración Seguimiento de auditoría y los registros de acceso a datos para determinar el periodo de compromiso.
• La exfiltración masiva de datos se detecta a través de exportaciones de informes de Supervisión 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 de la supervisión de la implementación y los cambios de configuración de 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 de la supervisión de 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 las actividades de auditoría que se realizaron con acceso elevado.

Su responsabilidad: Documente procedimientos de respuesta para escenarios específicos de plataforma, configure la supervisión 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 que se basa 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 impacto.

Su responsabilidad: Realizar una revisión oportuna posterior al incidente, documentar mejoras en las RAM, realizar un seguimiento de las tendencias de MTTD y MTTR, compartir 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 protege (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 a incidentes, gestión de vulnerabilidades y supervisión).
• Comunicar responsabilidades a las partes interesadas y 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 crear.
• 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 tokens de agrupación.
• Almacenar, rotar y credenciales de OAuth de ámbito mínimo 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 de trabajo lo requiera) y alinee las regiones de implementación con las certificaciones de cumplimiento y residencia 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 credenciales de cliente o portador de JWT están exentas.
• Implemente SSO utilizando SAML 2.0 u OpenID Connect con autenticación de IdP sólida.
• Utilice OAuth 2.0 (JWT Bearer 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 altos privilegios donde la frecuencia se determina por tolerancia al riesgo organizativo y 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 proporcione 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 alineen 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 documentadas.
• Requerir TLS 1.2+ para todas las integraciones con autenticación basada en certificado para datos restringidos.
• Evitar que los datos restringidos entren en entornos que no sean de producción mediante enmascaramiento o exclusión.
• Implemente la gestión de 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. Estos deben dimensionarse hasta el plazo más ajustado en 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 la región Hyperforce.

Cumplimiento y cumplimiento normativo

• Valide certificaciones de plataforma que cumplen los requisitos normativos para su sector.
• Active Supervisión 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 puntuaciones 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 modelado 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 en 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.
• Requerir 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 a incidentes de seguridad

• Diseñe reglas de alerta de Supervisión de eventos 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 bien diseñado.