Modelo de responsabilidad compartida: patrones
Obtenga más información acerca de Well-Architected Confide → El modelo de responsabilidad compartida
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Seguridad | ✅ Los diseños de arquitectura asumen que la seguridad física del centro de datos, la vigilancia y las protecciones medioambientales son gestionadas por Salesforce (o AWS para Hyperforce) |
| Plataforma | Seguridad | ✅ Los diseños de seguridad de red aprovechan la mitigación de DDoS proporcionada por la plataforma y los sistemas de detección de intrusos sin inversión duplicada |
| Plataforma | Seguridad | ✅ Todo el cifrado de tráfico en tránsito (TLS 1,2+) y en reposo (AES-256) lo proporciona la infraestructura de plataforma |
| Plataforma | Seguridad | ✅ El endurecimiento de la plataforma, la gestión de vulnerabilidades y la implementación de parches son responsabilidades de Salesforce; los arquitectos planifican alrededor de plazos de mantenimiento programados |
| Plataforma | Seguridad | ✅ Seguridad de múltiples arrendatarios y arquitectura de aislamiento de arrendatarios garantizando la separación de datos son garantías proporcionadas por plataforma |
| Plataforma | Cumplimiento | ✅ Las certificaciones de cumplimiento de plataforma (SOC 1/2/3, ISO 27001/27017/27018, FedRAMP para ofertas de Government Cloud, HIPAA, PCI DSS, RGPD) están disponibles en Trust.salesforce.com y compliance.salesforce.com |
| Plataforma | Seguridad | ✅ Los servicios de cifrado de plataforma y la infraestructura de copia de seguridad son funciones gestionadas por plataforma que los arquitectos aprovechan sin responsabilidad de implementación |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Seguridad | ⚠️ Los diseños de arquitectura incluyen controles de seguridad física personalizados, defensas perimetrales de red o capacidades proporcionadas por la plataforma de duplicación de endurecimiento a nivel de SO |
| Plataforma | Seguridad | ⚠️ Las revisiones de seguridad cuestionan el cifrado de la plataforma en periodos de inactividad o la seguridad de la red sin consultar la documentación Trust.salesforce.com de los controles existentes |
| Plataforma | Cumplimiento | ⚠️ Las evaluaciones de cumplimiento vuelven a auditar controles de seguridad de infraestructura de plataforma en vez de aprovechar las certificaciones SOC 2/ISO existentes |
| Plataforma | Seguridad | ⚠️ La arquitectura asume la responsabilidad de parchear la infraestructura de la plataforma o gestionar el aislamiento de múltiples arrendatarios |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Identity | ✅ Gestión de identidad y acceso (funciones, perfiles, conjuntos de permisos, MFA, SSO, menos privilegios) están diseñados y configurados por arquitectos |
| Plataforma | Identity | ✅ Gestión del ciclo de vida de los usuarios y procesos de recertificación de acceso implementados con revisiones trimestrales documentadas |
| Plataforma | Datos | ✅ La regulación de datos incluyendo clasificación, enmascaramiento, seguridad a nivel de objeto/campo/registro, permisos CRUD y reglas de colaboración son responsabilidades del arquitecto |
| Plataforma | Integración | ✅ La seguridad de integración (OAuth 2.0, autenticación JWT, credenciales nombradas, extremos seguros, validación de sistemas externos) está diseñada y mantenida por arquitectos |
| Plataforma | Seguridad | ✅ Las funciones de supervisión y respuesta (Monitorización de eventos, seguimientos de auditoría, integración de SIEM, procedimientos de respuesta a incidentes) están implementadas por arquitectos |
| Plataforma | Desarrollo | ✅ La seguridad de aplicaciones, incluyendo código personalizado seguro (Apex, Lightning), validación de entrada, prevención de inyección y prácticas de desarrollo seguro son responsabilidades del arquitecto y desarrollador |
| Plataforma | Cumplimiento | ✅ Las soluciones mantienen la postura de cumplimiento a través de la gestión de privacidad/consentimiento, políticas de retención de datos y configuración de cumplimiento alineadas con requisitos reguladores |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Identity | ⚠️ La gestión de identidad y acceso se trata como “seguridad de plataforma” sin diseñar funciones, perfiles, conjuntos de permisos o requisitos de MFA |
| Plataforma | Datos | ⚠️ Se asume que la regulación de datos está proporcionada por plataforma; no se configura clasificación de datos, reglas de colaboración o seguridad a nivel de campo |
| Plataforma | Integración | ⚠️ La seguridad de integración se basa en controles a nivel de red sin implementar OAuth, gestión de credenciales o validación de extremos |
| Plataforma | Seguridad | ⚠️ La supervisión y la respuesta a incidentes se tratan como responsabilidades de Salesforce; no existen procedimientos de supervisión de eventos, integración de SIEM o respuesta |
| Plataforma | Desarrollo | ⚠️ La seguridad del código personalizado no está validada; se acumulan vulnerabilidades de inyección, falta de aplicación CRUD/FLS y patrones inseguros |
| Plataforma | Cumplimiento | ⚠️ La configuración de cumplimiento nunca se implementa; las soluciones infringen los requisitos normativos a pesar de las certificaciones de plataforma |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Cumplimiento | ✅ En la documentación de cumplimiento se hace referencia a las certificaciones de plataforma (SOC 2 Tipo II, ISO 27001, FedRAMP para ofertas de Government Cloud, HIPAA, PCI DSS, RGPD) como que cubren responsabilidades de infraestructura |
| Plataforma | Cumplimiento | ✅ Preparación de auditoría aprovecha la documentación Trust.salesforce.com y compliance.salesforce.com para controles de infraestructura de plataforma |
| Plataforma | Cumplimiento | ✅ La documentación de cumplimiento define claramente las certificaciones proporcionadas por la plataforma frente a los controles implementados por el arquitecto para soluciones personalizadas |
| Plataforma | Arquitectura | ✅ Los objetos personalizados, el código Apex, las integraciones y las configuraciones están diseñados para mantener la postura de cumplimiento que proporciona la plataforma |
| Plataforma | Cumplimiento | ✅ La documentación de arquitectura asigna explícitamente cómo las soluciones personalizadas satisfacen los requisitos reguladores mientras aprovechan las certificaciones de plataforma |
| Plataforma | Cumplimiento | ✅ Las certificaciones regionales y los requisitos de cumplimiento dirigen la selección de regiones Hyperforce durante el aprovisionamiento de la organización |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Cumplimiento | ⚠️ Se asume que las certificaciones de plataforma cubren todas las obligaciones de cumplimiento; no se implementan controles de soluciones personalizadas |
| Plataforma | Cumplimiento | ⚠️ Preparación de auditoría intenta volver a auditar controles de infraestructura de plataforma en vez de hacer referencia a certificaciones existentes |
| Plataforma | Arquitectura | ⚠️ El código personalizado, las configuraciones y las integraciones infringen los requisitos de cumplimiento a pesar de que la plataforma tenga las certificaciones apropiadas |
| Plataforma | Cumplimiento | ⚠️ La documentación de cumplimiento no separa claramente las certificaciones de plataforma de los controles implementados por el arquitecto |
| Plataforma | Cumplimiento | ⚠️ La arquitectura carece de asignación documentada de cómo las soluciones personalizadas mantienen el estado de cumplimiento mientras aprovechan las certificaciones de plataforma |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Seguridad | ✅ Colaboración de documentos de procedimientos de respuesta a incidentes: Salesforce proporciona detección y respuesta de plataforma; los arquitectos proporcionan detección y respuesta a nivel de solución |
| Plataforma | Seguridad | ✅ Las responsabilidades de gestión de vulnerabilidades están claramente documentadas: Salesforce parchea la plataforma; los arquitectos parchean el código personalizado y los paquetes instalados |
| Plataforma | Seguridad | ✅ La supervisión de seguridad combina eventos generados por plataforma (Monitorización de eventos) con flujos de trabajo de análisis, alertas y respuestas configurados por el arquitecto |
| Plataforma | Arquitectura | ✅ Cada principio de diseño, sección de tema y elemento de lista de comprobación en pilar Trust se trata como responsabilidad del arquitecto dentro del modelo de responsabilidad compartida |
| Plataforma | Seguridad | ✅ Las decisiones de diseño hacen referencia explícita a los límites del modelo de responsabilidad compartida, distinguiendo los controles proporcionados por la plataforma de los controles configurados por el arquitecto |
| Plataforma | Arquitectura | ✅ Architecture Decision Records documenta límites de responsabilidad para controles de seguridad, requisitos de cumplimiento y respuesta a incidentes |
| Plataforma | Seguridad | ✅ Las revisiones de seguridad validan que las responsabilidades del arquitecto (configuración, controles de acceso, código personalizado) se implementan de forma apropiada sobre bases proporcionadas por la plataforma |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Seguridad | ⚠️ Los procedimientos de respuesta a incidentes asumen que Salesforce gestiona todos los aspectos; no existen funciones de detección, respuesta o recuperación a nivel de solución |
| Plataforma | Seguridad | ⚠️ La gestión de vulnerabilidades no soluciona el código personalizado; solo se tienen en cuenta los parches de plataforma |
| Plataforma | Seguridad | ⚠️ La supervisión de seguridad se basa completamente en herramientas nativas de plataforma sin flujos de trabajo de análisis o respuesta configurados por el arquitecto |
| Plataforma | Arquitectura | ⚠️ Las decisiones de diseño no hacen referencia al Modelo de responsabilidad compartida; existe confusión sobre quién asegura qué |
| Plataforma | Arquitectura | ⚠️ Los registros de decisiones de arquitectura omiten los límites de responsabilidad; las suposiciones de seguridad son implícitas en vez de explícitas |
| Plataforma | Seguridad | ⚠️ Las revisiones de seguridad asumen que las certificaciones de plataforma eliminan responsabilidades de seguridad del arquitecto |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Atención sanitaria | HIPAA | ✅ Shield Platform Encryption está activado para todos los campos que contienen información de salud protegida (PHI) |
| Atención sanitaria | HIPAA | ✅ Seguimiento de auditoría de campo está configurado con retención cumpliendo el requisito de mantenimiento de registros de HIPAA para el seguimiento de acceso de PHI (confirme el periodo actual con la regulación vigente) |
| Atención sanitaria | HIPAA | ✅ Supervisión de eventos está configurada para detectar patrones de acceso de PHI no autorizados con alertas enrutadas a equipos de seguridad |
| Atención sanitaria | HIPAA | ✅ Las protecciones técnicas requeridas por la regla de seguridad HIPAA (controles de acceso, registro de auditoría, seguridad de transmisión) se implementan a través de la configuración del arquitecto |
| Financiero | SOX/PCI | ✅ La separación de funciones se implementa a través del diseño de conjuntos de permisos evitando que los usuarios únicos creen y aprueben transacciones financieras |
| Financiero | PCI DSS | ✅ Los números de cuenta principales completos (PAN) se mantienen fuera de Salesforce donde sea posible y se tokenizan a través de procesadores de pago para reducir el ámbito; donde se debe almacenar PAN, utiliza Campos personalizados cifrados bajo controles PCI DSS |
| Privacidad | RGPD/CCPA | ✅ La gestión de consentimiento se implementa con flujos de trabajo granulares de seguimiento y retirada de consentimiento por propósito |
| Privacidad | RGPD/CCPA | ✅ Los flujos de trabajo de derechos de titulares de datos (acceso, rectificación, borrado, portabilidad) se completan dentro del plazo de respuesta que establece la normativa vigente para su implementación |
| Privacidad | RGPD/CCPA | ✅ La automatización de retención de datos purga datos cuando caduca el consentimiento o finalizan los periodos de retención |
| Gobierno | FedRAMP | ✅ Salesforce Government Cloud se utiliza para cargas de trabajo gubernamentales reguladas que requieren el cumplimiento de FedRAMP |
| Gobierno | FedRAMP | ✅ Los controles NIST 800-53 se asignan a la configuración de Salesforce con implementación documentada para cada control aplicable |
| Gobierno | FedRAMP | ✅ Supervisión continua con Supervisión de eventos se enruta a la infraestructura SIEM del gobierno para la detección de amenazas en tiempo real |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Atención sanitaria | HIPAA | ⚠️ PHI se almacena en campos cifrados estándar sin Shield Platform Encryption o Field Audit Trail |
| Atención sanitaria | HIPAA | ⚠️ Supervisión de eventos no está configurada para detectar acceso de PHI no autorizado; las infracciones se producen sin ser detectadas |
| Financiero | SOX/PCI | ⚠️ Los usuarios únicos pueden crear y aprobar transacciones financieras; no se aplica la separación de funciones |
| Financiero | PCI DSS | ⚠️ Los números de cuenta principales completos (PAN) se almacenan en campos estándar de Salesforce sin cifrado en vez de utilizar tokenización de procesador de pago o almacenamiento cifrado compatible con PCI DSS |
| Privacidad | RGPD/CCPA | ⚠️ La gestión del consentimiento no está implementada; los datos se procesan sin consentimiento granular o funciones de retirada |
| Privacidad | RGPD/CCPA | ⚠️ Las solicitudes de derechos de titulares de datos se gestionan manualmente a través del equipo jurídico en vez de automatizar el tamaño de la ventana de respuesta del reglamento |
| Privacidad | RGPD/CCPA | ⚠️ La retención de datos es manual; los datos se acumulan indefinidamente a pesar del consentimiento caducado o la finalización del periodo de retención |
| Gobierno | FedRAMP | ⚠️ Las cargas de trabajo gubernamentales reguladas se ejecutan en instancias comerciales de Salesforce en vez de Government Cloud |
| Gobierno | FedRAMP | ⚠️ Los controles NIST 800-53 carecen de asignación documentada a la configuración de Salesforce; existen brechas de cumplimiento |
| Gobierno | FedRAMP | ⚠️ Supervisión de eventos no se enruta a SIEM gubernamental; no se cumplen los requisitos de supervisión continua |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Seguridad | ✅ Los usuarios con permisos críticos del sistema (Ver todos los datos, Modificar todos los datos, Gestionar usuarios) se inventarian y se siguen como activos de privilegios elevados |
| Plataforma | Supervisión de eventos Shield | ✅ Supervisión de eventos captura registros de eventos que cubren inicios de sesión, exportaciones de informes y datos, cambios de permisos y llamadas de API para análisis de seguridad |
| Plataforma | Supervisión de eventos Shield | ✅ Los registros de Supervisión de eventos se enrutan a una plataforma SIEM externa para su correlación con eventos de seguridad que no sean de Salesforce |
| Integración | SIEM | ✅ Las reglas de correlación SIEM detectan la distribución de privilegios, como cambios de permisos fuera de los plazos de cambio aprobados y anomalías de volumen de API por encima de la línea base |
| Integración | SIEM | ✅ Los paneles SIEM proporcionan visibilidad sobre cambios de activos de seguridad como subvenciones de usuario privilegiado y exportaciones de datos |
| Plataforma | Documentación | ✅ El inventario de activos de seguridad está documentado con categorías de activos (usuarios, datos, integraciones, paquetes, configuraciones), propietarios y cadencia de revisión |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Seguridad | ⚠️ El inventario de activos de seguridad se mantiene manualmente en hojas de cálculo que quedan desfasadas inmediatamente después de la creación |
| Plataforma | Seguridad | ⚠️ Los activos de seguridad se siguen a través de tribal Knowledge sin inventario documentado y consultable accesible durante incidentes |
| Plataforma | Seguridad | ⚠️ Las auditorías de seguridad se producen solo durante revisiones de cumplimiento anuales sin supervisión continua entre auditorías |
| Plataforma | Seguridad | ⚠️ El inventario de activos de seguridad se recopila pero nunca se revisa; las cuentas inactivas, las integraciones huérfanas y los permisos excesivos persisten indefinidamente |
| Plataforma | Seguridad | ⚠️ Se realiza un seguimiento de los usuarios de integración oficiales pero las unidades comerciales crean aplicaciones conectadas ad-hoc omitiendo la revisión de seguridad y las políticas de rotación de credenciales |
| Plataforma | Supervisión de eventos Shield | ⚠️ Supervisión de eventos está activada pero los eventos no se enrutan a SIEM; los eventos de seguridad permanecen aislados en Salesforce sin correlación |
| Plataforma | Integración | ⚠️ Las integraciones de Shadow IT omiten el seguimiento de inventario; la actividad de API no autorizada crea riesgos de exfiltración de datos |