Patrones de protección de datos
Obtenga más información acerca de Well-Architected Confide → Privacidad y protecció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 |
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 |
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 |
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 |
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 |