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é buen aspecto tiene |
|---|---|
| Esquema de clasificación de datos | ✅ Esquema de clasificación documentado con niveles (Público, Interno, Confidencial, Restringido) ✅ Ejemplos comerciales proporcionados para cada nivel de clasificación ✅ Esquema de clasificación alineado con obligaciones reguladoras (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 en 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) |
| Objetos y campos 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 empresa, sitio web) documentados como Públicos ✅ Metadatos de clasificación capturados en descripciones de campo ✅ Clasificación revisada durante revisiones de código y ARB |
| Objetos estándar | ✅ Campos de objeto estándar evaluados con respecto al esquema de clasificación ✅ Shield Platform Encryption activado para campos estándar Restringido ✅ Seguridad a nivel de campo aplicada a campos estándar Confidencial ✅ Informes 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 Uso de datos restringido de 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 PCI evitados en Salesforce donde sea posible; tokenizados a través de pasarelas de pago para la reducción de ámbito; donde se deben almacenar, utilice Campos personalizados cifrados bajo controles 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 | ⚠️ Se aplica la misma protección a todos los campos independientemente de la sensibilidad ⚠️ Datos de bajo valor sobreprotegidos (desperdicio de recursos) mientras que los datos de alto valor están subprotegidos ⚠️ La información de la empresa pública se trata igual 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 indocumentada, existente solo en Knowledge de personas clave ⚠️ Los desarrolladores se basaron 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é buen aspecto tiene |
|---|---|
| Cifrado en reposo | ✅ Todos los datos cifrados a nivel de infraestructura mediante Hyperforce ✅ Shield Platform Encryption activado para datos restringidos ✅ Esquema de cifrado (probabilista, determinista, determinista que distingue entre mayúsculas y minúsculas) seleccionado basándose en 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 sensible a mayúsculas y minúsculas utilizado donde la distinción de casos importa para la lógica comercial ✅ 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 clave de destrucción 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 del protocolo ✅ Caducidad de certificado TLS supervisada y renovación automatizada configurada ✅ Cifrados y protocolos débiles desactivados |
| Código y configuración | ✅ Credenciales nunca incrustadas en código, archivos de configuración o control de versión ✅ 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, activando actualizaciones sin cambios de código |
| Paquetes AppExchange | ✅ Requisitos de seguridad del paquete evaluados antes de la instalación ✅ Campos cifrados accesibles para paquetes solo cuando está justificado por el negocio ✅ Patrones de acceso a datos de paquetes supervisados a través de Supervisión 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 ⚠️ Los informes críticos encontrados en producción fallan porque no se pueden agregar campos cifrados ⚠️ Cifrado activado en orígenes de campos de fórmula sin comprender el impacto ⚠️ Campos utilizados en consultas SOQL LIKE cifradas sin cambiar al cifrado determinista |
| Credenciales integradas | ⚠️ Credenciales integradas 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 (obsoleto 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 el cumplimiento de claves gestionadas por el cliente ⚠️ Procedimientos de rotación y revocación de claves nunca probados |
| Cifrado excesivo | ⚠️ Datos de clasificación pública o interna cifrados, agregando coste sin beneficio ⚠️ Shield Platform Encryption activado en cada campo, creando una 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é buen 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 los de producción |
| Reglas Data Mask | ✅ Las reglas Data Mask confunden 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 correo electrónico 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 aleatorios 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 que no son 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 altamente enmascarados ✅ Acceso de contratista y proveedor a datos que no son de producción restringidos a la clasificación Solo uso comercial |
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 ⚠️ Los desarrolladores tienen acceso amplio a entornos sandbox de datos de producción ⚠️ Sandboxes actualizados con datos confidenciales “porque las pruebas son más fáciles con datos reales” |
| Sin datos sintéticos | ⚠️ Datos de producción en los que se basan únicamente 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é buen aspecto tiene |
|---|---|
| Minimización de datos | ✅ Solo se recopilan los datos necesarios para fines comerciales declarados ✅ Cada incorporación de campo desafiada con “¿qué decisión de arquitectura requiere estos datos?” ✅ Datos que ya no sirven para el propósito de recopilación eliminados ✅ Campos opcionales claramente marcados y no obligatorios sin justificación comercial ✅ Retención de datos históricos alineados con la base legal, no “mantener todo para siempre” |
| Limitación de propósito | ✅ Los conjuntos de permisos restringen el acceso a datos basándose en el 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 multifuncional requiere aprobación y supervisión explícitas ✅ Propósito de acceso a datos documentado en descripciones de conjuntos de permisos |
| Gestión de 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 establece la normativa reguladora para su implementación ✅ Los flujos de trabajo de rectificación corrigen imprecisiones con el 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 del flujo 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 limitación de propósitos ✅ La seguridad a nivel de campo protege atributos confidenciales ✅ 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 propósito comercial documentado ⚠️ Datos mantenidos indefinidamente sin justificación de retención ⚠️ Datos opcionales recopilados haciendo que los campos sean obligatorios |
| Consentimiento general | ⚠️ Consentimiento único de “aceptar términos” para todos los fines ⚠️ Consentimiento de marketing combinado con entrega de servicio en una casilla de verificación única ⚠️ Consentimiento hecho todo o nada cuando los propósitos son separables ⚠️ Consentimiento enterrado en términos y condiciones de 20 páginas |
| Política sin aplicación | ⚠️ La política de privacidad describe prácticas ideales que no se aplican técnicamente ⚠️ Se confió en la formación de usuarios para evitar el acceso inapropiado a los datos ⚠️ Principios de privacidad documentados sin implementar controles técnicos ⚠️ Cumplimiento de políticas asumido sin supervisión y validación |
| Solicitudes manuales de titulares de datos | ⚠️ Solicitudes de RGPD/CCPA gestionadas a través de tickets informáticos manuales que tardan meses ⚠️ No hay procedimientos documentados para el acceso, rectificación, eliminación, portabilidad ⚠️ Se pierde el plazo de solicitud-finalización que el reglamento regulador establece para su implementación ⚠️ Solicitar flujos de trabajo detectados durante auditorías que no existen |
| Uso compartido excesivo de datos | ⚠️ Acceso amplio a los 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é buen 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 las leyes ✅ Cláusulas contractuales estándar o reglas corporativas vinculantes para transferencias internacionales ✅ Rutas de tránsito de datos evaluadas para el cumplimiento de residencia, no solo 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 transfronterizo de datos |
| Arquitectura de múltiples organizaciones | ✅ Arquitectura de múltiples organizaciones utilizada cuando no se pueden cumplir los requisitos normativos en una única 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 con respecto 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 regulaciones de residencia desencadenan una 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 las necesidades 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 |
| Multiorganización innecesaria | ⚠️ Arquitectura multiorganización utilizada cuando una única organización con regiones Hyperforce es suficiente ⚠️ Complejidad operativa, costes de licencia y gastos generales de integración multiplicados sin necesidad de regulación ⚠️ Implementado por 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 |