--- schema_version: "1" id: c6f808b7a002ecb4ab0e4b4b31723149bfc6d675bcd31fd555993e707fd41214 title: Patrones de protección de datos collection: architect version: current locale: es-mx portal_url: https://docs.salesforce.com/architect/current/es-mx/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/es-mx/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: 7910421b4af66fef1b4c378b2f0cd88a230fdf27a1d922586082a241000196a6 products: - Marco bien estructurado - Architect Site Content Repo --- # Patrones de protección de datos
Obtenga más información acerca de Well-Architected [Confide](/docs/architect/es-mx/well-architected/guide/trust.html) → [Privacidad y protección](/docs/architect/es-mx/well-architected/guide/trust.html#data-protection-and-privacy) de datos ## Clasificación de datos **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Esquema de clasificación de datos | ✅ Esquema de clasificación documentado con niveles (Público, Interno, Confidencial, Restringido)
✅ Ejemplos de negocio proporcionados para cada nivel de clasificación
✅ Esquema de clasificación alineado con obligaciones regulatorias (HIPAA, PCI DSS, RGPD)
✅ Modeladores de datos capacitados para aplicar la clasificación de forma coherente durante el diseño
✅ Nuevos campos clasificados como parte del proceso de modelado de datos, no retroactivamente | | Clasificación a nivel de campo | ✅ Clasificación aplicada a nivel de campo, no solo a nivel de objeto
✅ Los campos dentro de un único objeto pueden tener clasificaciones diferentes
✅ La seguridad a nivel de campo refleja distinciones de clasificación
✅ Los datos no clasificados toman como valor predeterminado el nivel de protección apropiado más alto
✅ La clasificación dirige los controles de protección (cifrado, acceso, retención) | | Campos y objetos personalizados | ✅ Todos los objetos personalizados tienen clasificación de datos documentada
✅ Campos confidenciales (salario, SSN, PHI, datos de pago) clasificados como Confidencial o Restringido
✅ Campos públicos (nombre de la compañía, sitio web) documentados como Públicos
✅ Metadatos de clasificación capturados en descripciones de campos
✅ Clasificación revisada durante revisiones de código y ARB | | Objetos estándar | ✅ Campos de objeto estándar evaluados con esquema de clasificación
✅ Shield Platform Encryption activado para campos estándar Restringido
✅ Seguridad a nivel de campo aplicada a campos estándar Confidencial
✅ Reportes y vistas de lista filtrados para evitar la exposición de campos estándar confidenciales | | Datos de integración | ✅ Datos que fluyen a través de integraciones clasificadas antes de la implementación
✅ Se evaluó y documentó la confidencialidad de datos del sistema externo
✅ Gestión de extremos de integración Los datos restringidos utilizan autenticación basada en certificado
✅ Clasificación de datos conservada entre límites del sistema | | Asignación de cumplimiento | ✅ Campos HIPAA PHI identificados y marcados como Restringidos
✅ Datos de titulares de tarjetas de PCI evitados en Salesforce donde sea posible: tokenizados a través de pasarelas de pago para la reducción del ámbito; donde se deben almacenar, utilice Campos personalizados cifrados bajo controles de PCI DSS
✅ Datos personales del RGPD identificados y sujetos a controles de privacidad
✅ Datos financieros de SOX clasificados y sujetos a separación de funciones | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Protección uniforme | ⚠️ La misma protección aplicada a todos los campos independientemente de la confidencialidad
⚠️ Datos de bajo valor sobreprotegidos (desperdicio de recursos) mientras que los datos de alto valor están subprotegidos
⚠️ La información de la compañía pública se trata del mismo modo que los datos de PHI o tarjeta de pago
⚠️ Cada campo cifrado "solo para estar seguro" sin justificación de clasificación | | Clasificación retroactiva | ⚠️ Datos clasificados después de la implementación en producción
⚠️ Datos confidenciales descubiertos a través de auditorías de cumplimiento en vez de revisiones de diseño
⚠️ Datos clasificados solo después de incidentes de seguridad
⚠️ "Averiguaremos la clasificación más adelante" es el valor predeterminado durante el desarrollo | | Clasificación solo a nivel de objeto | ⚠️ Objetos completos clasificados uniformemente cuando los campos tienen diferente sensibilidad
⚠️ Acceso a nivel de objeto otorgado sin seguridad a nivel de campo para campos confidenciales
⚠️ Todos los campos en objetos Cuenta o Contacto que se supone que tienen la misma clasificación
⚠️ Permisos de objeto utilizados como el único control de acceso para objetos de sensibilidad mixta | | Knowledge tribal | ⚠️ Clasificación no documentada, existente únicamente en Knowledge de personas clave
⚠️ Los desarrolladores confiaban en "solo saber" qué campos son confidenciales
⚠️ No hay esquema de clasificación escrito accesible para todos los modeladores de datos
⚠️ Nuevos miembros del equipo incorporados sin entrenamiento de clasificación | ## Cifrado **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Cifrado en reposo | ✅ Todos los datos cifrados a nivel de infraestructura a través de Hyperforce
✅ Shield Platform Encryption activado para datos restringidos
✅ Esquema de cifrado (probabilista, determinista, determinista con distinción entre mayúsculas y minúsculas) seleccionado en base a requisitos de consulta y exclusividad
✅ Compensaciones de cifrado evaluadas durante el diseño del modelo de datos | | Estrategia Shield Platform Encryption | ✅ Cifrado probabilista utilizado para la mayoría de los campos restringidos (admite todas las operaciones de consulta)
✅ Cifrado determinista utilizado para campos que requieren cláusulas WHERE de coincidencia exacta o exclusividad
✅ Determinista que distingue entre mayúsculas y minúsculas utilizado donde la distinción de casos importa para la lógica de negocio
✅ Comportamiento de campo cifrado probado antes de la implementación de producción
✅ Referencias de campos de fórmula a campos cifrados gestionados de forma apropiada (trasladados a Apex si es necesario) | | Gestión de claves | ✅ Procedimientos de rotación de claves documentados y automatizados
✅ Escenarios de destrucción clave probados durante ejercicios de recuperación de desastres
✅ Claves gestionadas por el cliente (BYOK) evaluadas para el cumplimiento que requieren control de claves explícito
✅ Procedimientos de revocación de claves documentados
✅ Ciclo de vida de claves de cifrado gestionado según requisitos de cumplimiento | | Cifrado en tránsito | ✅ Se requiere TLS 1.2 o superior para todas las integraciones
✅ Autenticación mutua basada en certificado para integraciones que gestionan datos restringidos
✅ Encabezados HSTS configurados para sitios de Experience Cloud para evitar la degradación de protocolos
✅ Caducidad de certificado TLS monitoreado y renovación automatizada configurada
✅ Cifrados débiles y protocolos desactivados | | Código y configuración | ✅ Credenciales nunca incrustadas en código, archivos de configuración o control de versiones
✅ Credenciales nombradas y credenciales externas utilizadas para gestionar la autenticación de forma centralizada
✅ Funciones de rotación de credenciales integradas en la arquitectura
✅ Las credenciales nombradas abstraen la autenticación del código, permitiendo actualizaciones sin cambios de código | | Paquetes AppExchange | ✅ Requisitos de seguridad de paquetes evaluados antes de la instalación
✅ Campos cifrados accesibles para paquetes solo cuando el negocio está justificado
✅ Patrones de acceso de datos de paquetes monitoreados a través de Monitoreo de eventos
✅ Paquetes que requieren acceso a datos restringidos sujetos a revisión mejorada | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Cifrado sin evaluación | ⚠️ Cifrado probabilista activado en todos los campos sin pruebas
⚠️ Fallo de reportes críticos encontrados en producción porque no se pueden agregar campos cifrados
⚠️ Cifrado activado en orígenes de campos de fórmula sin comprender la repercusión
⚠️ Campos utilizados en consultas SOQL LIKE cifradas sin cambiar al cifrado determinista | | Credenciales integradas | ⚠️ Credenciales incrustadas en código, configuración personalizada o control de versión
⚠️ Claves de API, contraseñas y certificados codificados en clases Apex
⚠️ Credenciales confirmadas en repositorios de control de origen
⚠️ Credenciales almacenadas en metadatos personalizados o configuración personalizada sin cifrado | | Protocolos débiles o heredados | ⚠️ Se acepta TLS 1.0 o 1.1 (en desuso y vulnerable)
⚠️ Flujo de OAuth de nombre de usuario-contraseña permitido cuando el soporte JWT está disponible
⚠️ Certificados autofirmados aceptados en integraciones de producción
⚠️ Validación de certificado desactivada "para que la integración funcione" | | Sin gestión de claves | ⚠️ Shield Platform Encryption activado sin procedimientos de rotación de claves
⚠️ No hay escenarios de destrucción clave documentados
⚠️ Claves predeterminadas utilizadas sin evaluar claves gestionadas por el cliente para el cumplimiento
⚠️ Procedimientos de rotación y revocación de claves nunca probados | | Cifrado excesivo | ⚠️ Datos de clasificación pública o interna cifrados, agregando costo sin beneficio
⚠️ Shield Platform Encryption activado en cada campo, creando complejidad innecesaria
⚠️ BYOK utilizado cuando el cumplimiento no lo requiere (agrega gastos generales operativos)
⚠️ Cifrado obligatorio donde la clasificación de datos no lo justifica | ## Enmascaramiento de datos **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Estrategia de sandbox | ✅ Los datos restringidos nunca entran en entornos de desarrollo o prueba
✅ La copia parcial de sandbox excluye objetos y campos restringidos
✅ Las plantillas de sandbox definen qué objetos y campos incluir por tipo de entorno
✅ Data Mask configurado para entornos sandbox que requieren datos similares a producción | | Reglas Data Mask | ✅ Las reglas Data Mask ofuscan los campos confidenciales preservando las características de los datos
✅ Los patrones mantienen la integridad referencial (la misma entrada produce la misma salida enmascarada)
✅ Direcciones de email enmascaradas pero con formato válido para pruebas
✅ Números de teléfono enmascarados pero con formato válido
✅ Las fechas cambiaron de forma coherente manteniendo relaciones relativas
✅ Campos numéricos aleatorizados dentro de intervalos realistas | | Datos sintéticos | ✅ Los entornos de desarrollo utilizan la generación de datos sintéticos
✅ Los datos sintéticos tienen características realistas que permiten pruebas efectivas
✅ No se requieren datos de producción para el desarrollo
✅ Generación de datos de prueba automatizada en oportunidades en curso de desarrollo | | Entornos no de producción | ✅ Datos de producción nunca copiados en organizaciones de desarrollador personales
✅ Las capturas de pantalla y demostraciones utilizan datos enmascarados o sintéticos
✅ Los entornos de entrenamiento utilizan datos sintéticos o datos de producción fuertemente enmascarados
✅ Acceso de contratista y proveedor a datos no de producción restringidos a la clasificación Solo uso de negocio | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Datos de producción en entornos sandbox | ⚠️ Sandboxes completos actualizados con datos de producción desenmascarados para el desarrollo
⚠️ Datos restringidos copiados en entornos sandbox de desarrollador para mayor comodidad
⚠️ Se otorgó a los desarrolladores acceso amplio a entornos sandbox de datos de producción
⚠️ Sandboxes actualizados con datos confidenciales "porque las pruebas son más sencillas con datos reales" | | Sin datos sintéticos | ⚠️ Datos de producción en los que se basa únicamente para todas las pruebas
⚠️ Sin generación de datos sintéticos para entornos de desarrollo
⚠️ "Necesitamos datos reales" asumidos sin evaluar alternativas sintéticas
⚠️ Datos de prueba manuales creados cuando se puede automatizar la generación | ## Privacidad por diseño **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Minimización de datos | ✅ Solo se recopilan los datos necesarios para fines de negocio declarados
✅ Cada incorporación de campo impugnada con "¿qué decisión arquitectónica requiere estos datos?"
✅ Los datos ya no sirven para fines de recopilación eliminados
✅ Campos opcionales claramente marcados y no obligatorios sin justificación de negocio
✅ Retención de datos históricos alineada con la base legal, no "mantener todo para siempre" | | Limitación de propósito | ✅ Los conjuntos de permisos restringen el acceso a los datos en base al propósito de la función de trabajo
✅ Los usuarios de marketing no pueden acceder a detalles de casos de asistencia sin justificación documentada
✅ Los usuarios de ventas no pueden acceder a historiales de servicio al cliente a menos que el trabajo lo requiera
✅ El acceso a datos entre funciones requiere aprobación y monitoreo explícitos
✅ Propósito de acceso a datos documentado en descripciones de conjuntos de permisos | | Gestión del consentimiento | ✅ Consentimiento capturado a nivel individual para marketing, análisis, procesamiento opcional
✅ El consentimiento es granular (específico del propósito), no binario
✅ Los flujos de trabajo de retirada de consentimiento se propagan entre sistemas integrados
✅ Decisiones de consentimiento supervisadas con marca de tiempo, versión y mecanismo
✅ La interfaz de usuario de consentimiento explica claramente lo que el usuario está consintiendo | | Derechos de titular de datos | ✅ Los flujos de trabajo de solicitudes de acceso proporcionan copias de datos dentro del plazo que la normativa vigente establece para su implementación
✅ Los flujos de trabajo de rectificación corrigen imprecisiones con seguimiento de auditoría
✅ Los flujos de trabajo de borrado eliminan datos donde está permitido legalmente (considerando obligaciones de retención)
✅ Los flujos de trabajo de portabilidad exportan datos en formato legible por máquina
✅ Flujos de trabajo de derechos de titulares de datos probados regularmente para validar cronologías
✅ La automatización de flujos de trabajo garantiza que los plazos reglamentarios se cumplan de forma coherente | | Controles de privacidad | ✅ Controles de privacidad aplicados técnicamente, no solo a través de políticas
✅ Las reglas de colaboración implementan la limitación de propósitos
✅ La seguridad a nivel de campo protege atributos confidenciales
✅ Los seguimientos de auditoría capturan eventos relevantes para la privacidad
✅ Controles de privacidad validados en oportunidades en curso de CI/CD | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Recopilar todo | ⚠️ Enfoque "Recopilar todos los datos posibles, podríamos necesitarlos algún día"
⚠️ Campos agregados sin fines de negocio documentados
⚠️ Datos mantenidos indefinidamente sin justificación de retención
⚠️ Datos opcionales recopilados haciendo que los campos sean obligatorios | | Consentimiento general | ⚠️ Consentimiento único de "aceptar condiciones" para todos los fines
⚠️ Consentimiento de marketing combinado con entrega de servicio en una sola casilla de verificación
⚠️ Consentimiento hecho todo o nada cuando los propósitos son separables
⚠️ Consentimiento enterrado en condiciones de 20 páginas | | Póliza sin aplicación forzosa | ⚠️ La política de privacidad describe prácticas ideales que no se aplican técnicamente
⚠️ Capacitación de usuarios en la que se basa para evitar el acceso inapropiado a los datos
⚠️ Principios de privacidad documentados sin implementar controles técnicos
⚠️ Cumplimiento de póliza asumido sin monitoreo y validación | | Solicitudes de titulares de datos manuales | ⚠️ Solicitudes de RGPD/CCPA gestionadas a través de tickets de TI manuales que tardan meses
⚠️ No hay procedimientos documentados para el acceso, la rectificación, la eliminación y la portabilidad
⚠️ Se pierde el plazo de solicitud-completado que la regulación reguladora establece para su implementación
⚠️ Solicitar flujos de trabajo detectados durante auditorías que no existen | | Uso compartido excesivo de datos | ⚠️ Acceso amplio a datos otorgado entre departamentos sin justificación de propósito
⚠️ Marketing permitió el acceso a detalles de casos de asistencia
⚠️ Ventas permitió el acceso a historiales de servicio al cliente sin necesidad documentada
⚠️ OWD de lectura/escritura pública utilizado para objetos que contienen datos personales | ## Residencia de datos **Patrones** | Dónde buscar | Qué aspecto tiene | | --- | --- | | Implementación regional Hyperforce | ✅ Organización aprovisionada en la región Hyperforce cumpliendo los requisitos de residencia de datos
✅ El almacenamiento y procesamiento de datos se producen dentro de los límites geográficos requeridos
✅ Requisitos regionales documentados y validados antes del aprovisionamiento
✅ Requisitos de múltiples regiones solucionados a través de arquitectura de múltiples organizaciones donde sea necesario | | Asignación de flujos de datos | ✅ Documento de mapas de flujo de datos donde se originan, transitan y residen los datos
✅ Transferencias de datos transfronterizas identificadas y evaluadas con respecto a leyes
✅ Cláusulas contractuales estándar o reglas corporativas vinculantes para transferencias internacionales
✅ Rutas de tránsito de datos evaluadas para el cumplimiento de la residencia, no solo la ubicación de almacenamiento | | Ámbito de residencia de datos | ✅ Ubicación de almacenamiento de datos (región Hyperforce)
✅ Ubicación de procesamiento de datos (computar regiones)
✅ Ubicación de almacenamiento de copia de seguridad
✅ Registro y ubicación de almacenamiento de seguimiento de auditoría
✅ Rutas de tránsito de integración evaluadas para el movimiento de datos transfronterizo | | Arquitectura de múltiples organizaciones | ✅ Arquitectura de múltiples organizaciones utilizada cuando no se pueden cumplir los requisitos normativos en una sola organización
✅ Cada organización aprovisionada en la región apropiada para sus datos
✅ Los patrones de integración respetan las restricciones de residencia de datos
✅ Compensaciones de complejidad operativa documentadas en ADR | | Validación de cumplimiento | ✅ Requisitos de residencia de datos documentados por jurisdicción
✅ Selección de región Hyperforce validada frente a requisitos antes de aprovisionar
✅ Las auditorías periódicas confirman que los datos permanecen dentro de los límites requeridos
✅ Los cambios en las leyes de residencia desencadenan la revisión de la arquitectura | **Antipatrones** | Dónde buscar | Aspecto negativo | | --- | --- | | Supervisión de residencia | ⚠️ Infracciones de residencia de datos descubiertas durante auditorías de cumplimiento
⚠️ Organizaciones aprovisionadas sin evaluar los requisitos regionales
⚠️ "Nube es nube" supuesto sin tener en cuenta las leyes de ubicación de datos
⚠️ Jurisdicciones agregadas sin revisar obligaciones de residencia | | Tránsito ignorando la residencia | ⚠️ Solo se tiene en cuenta la ubicación de almacenamiento mientras se ignoran las rutas de tránsito
⚠️ Datos enrutados a través de regiones fuera de los límites de cumplimiento
⚠️ Middleware de integración utilizado en regiones no conformes
⚠️ Copias de seguridad almacenadas en regiones diferentes a los datos principales | | Múltiples organizaciones innecesarias | ⚠️ Arquitectura de múltiples organizaciones utilizada cuando una única organización con regiones Hyperforce es suficiente
⚠️ Complejidad operativa, costos de licencias y gastos generales de integración multiplicados sin necesidad de regulación
⚠️ Implementación de múltiples organizaciones "solo para estar seguro" sin un requisito de cumplimiento específico
⚠️ Multiorganización utilizada de forma predeterminada cuando la clasificación de datos y los controles de acceso son suficientes |