Gestión de identidad y acceso: patrones
Obtenga más información acerca de Well-Architected Confide → Gestión de identidad y acceso
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Arquitectura | ✅ Los controles de acceso verifican la identidad explícitamente en cada solicitud, independientemente de la ubicación de red o el dispositivo |
| Plataforma | Arquitectura | ✅ Los controles de seguridad basados en identidad sustituyen los supuestos de Trust basados en red |
| Plataforma | Organización | ✅ Las decisiones de acceso tienen en cuenta quién está solicitando acceso (autenticación), para qué están autorizados (autorización) y contexto (dispositivo, ubicación) |
| Plataforma | Documentación | ✅ La arquitectura de seguridad documenta la identidad como el límite Trust principal, no el perímetro de red |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Arquitectura | ⚠️ Los usuarios en red corporativa o VPN se asumen confiables y se les otorga un acceso más amplio basándose en la posición de red únicamente |
| Plataforma | Arquitectura | ⚠️ Los controles de acceso se basan en el perímetro de red en vez de la verificación de identidad |
| Plataforma | Organización | ⚠️ Las decisiones de acceso no tienen en cuenta señales de contexto (dispositivo, ubicación, hora, patrones de comportamiento) |
| Plataforma | Documentación | ⚠️ La arquitectura de seguridad trata la ubicación de red como límite Trust principal |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Organización | ✅ Las soluciones aprovechan las cuatro capas de acceso de Salesforce: Organización (licencias, funciones), Objeto (CRUD), Campo (FLS), Registro (compartición) |
| Plataforma | Organización | ✅ El modelo de acceso está diseñado de arriba abajo (organización → objeto → campo → registro) y validado de abajo arriba |
| Plataforma | Organización | ✅ Los valores predeterminados de toda la organización (OWD) se establecen como Privado para objetos que contienen datos confidenciales |
| Plataforma | Organización | ✅ Los OWD establecidos como Solo lectura pública están limitados a objetos de referencia (productos, listas de precios) donde una amplia visibilidad admite negocios sin exponer riesgos |
| Plataforma | Organización | ✅ Las restricciones a nivel de organización (licencias, intervalos de IP, horas de inicio de sesión, permisos de funciones) definen funciones de línea base para poblaciones de usuarios |
| Plataforma | Organización | ✅ Los permisos de objeto (a través de perfiles y conjuntos de permisos) controlan el acceso de creación, lectura, modificación y eliminación a cada objeto para segmentos de usuario |
| Plataforma | Organización | ✅ La seguridad a nivel de campo protege campos confidenciales incluso cuando se otorga acceso a objetos |
| Plataforma | Organización | ✅ La colaboración a nivel de registro utiliza reglas de colaboración y jerarquía de funciones basadas en requisitos comerciales documentados |
| Plataforma | Organización | ✅ El acceso se amplía deliberadamente desde la línea base restrictiva, no restringida después de valores predeterminados permisivos |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Organización | ⚠️ El modelo de acceso no aprovecha las cuatro capas (organización, objeto, campo, registro) |
| Plataforma | Organización | ⚠️ Los OWD se establecen como Lectura/escritura pública para mayor comodidad durante el desarrollo sin planes de restricción |
| Plataforma | Organización | ⚠️ Las OWD demasiado permisivas establecidas de forma temprana se vuelven exponencialmente más difíciles de restringir a medida que crece el volumen de datos y cristalizan los procesos comerciales |
| Plataforma | Organización | ⚠️ La seguridad a nivel de campo no está configurada, basándose únicamente en controles de acceso a nivel de objeto o registro |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Organización | ✅ Se aplica la autenticación de múltiples factores (MFA) para todos los usuarios que acceden a entornos de producción (obligatorio para el acceso a la interfaz de usuario) |
| Plataforma | Organización | ✅ MFA se amplía a operaciones privilegiadas incluyendo exportaciones masivas de datos, cambios de permisos y configuración administrativa |
| Plataforma | Organización | ✅ El inicio de sesión único (SSO) utiliza los protocolos SAML 2.0 u OpenID Connect |
| Plataforma | Organización | ✅ El tiempo de espera de la sesión está configurado correctamente: 2 horas para usuarios estándar, 15-30 minutos para administradores y usuarios que acceden a datos restringidos |
| Plataforma | Organización | ✅ Las restricciones de IP se aplican para perfiles administrativos y usuarios de integración |
| Plataforma | Organización | ✅ El horario de inicio de sesión restringe las cuentas de servicio a los plazos operativos esperados |
| Plataforma | Organización | ✅ La activación de dispositivos nativos verifica inicios de sesión desde dispositivos no reconocidos; las restricciones de MFA e IP agregan protección para cuentas de alto privilegio |
| Plataforma | Organización | ✅ Si SSO está activado, los usuarios administradores aprobados tienen acceso de inicio de sesión directo (procedimientos break-glass) |
| Plataforma | Organización | ✅ La relación entre usuarios y entidades que inician sesión en Salesforce es 1:1 (sin cuentas de usuario compartidas) |
| Plataforma | Organización | ✅ Control de acceso de API evita que los usuarios se autentiquen a través de aplicaciones conectadas no autorizadas |
| Plataforma | Credenciales nombradas | ✅ Las credenciales nombradas y las credenciales externas gestionan la autenticación de forma centralizada con funciones de rotación |
| Plataforma | Credenciales nombradas | ✅ Las credenciales nombradas abstraen detalles de autenticación del código, activando actualizaciones de credenciales sin cambios de código |
| Plataforma | Credenciales nombradas | ✅ Las credenciales nunca se incrustan en código, archivos de configuración o control de versión |
| Plataforma | Apex | ✅ Los métodos que ejecutan la autenticación utilizan credenciales nombradas para gestionar flujos de nombre de usuario/contraseña |
| Plataforma | Apex | ✅ No aparecen nombres de usuario o contraseñas en código en formatos legibles (sin valores o cadenas codificados) |
| Plataforma | Aura | ✅ Los métodos que ejecutan la autenticación utilizan credenciales nombradas para gestionar flujos de nombre de usuario/contraseña |
| Plataforma | Aura | ✅ No aparecen nombres de usuario o contraseñas en código en formatos legibles |
| Plataforma | Componentes web Lightning (LWC) | ✅ Los métodos que ejecutan la autenticación utilizan credenciales nombradas |
| Plataforma | Componentes web Lightning (LWC) | ✅ No aparecen nombres de usuario o contraseñas en el código |
| Integración | API | ✅ El flujo de soporte JWT de OAuth 2.0 se utiliza para integraciones de servidor a servidor en entornos de confianza (preferido para integraciones de producción) |
| Integración | API | ✅ El flujo de servidor web de OAuth 2.0 se utiliza para integraciones de servidor a servidor que requieren contexto de usuario |
| Integración | API | ✅ El flujo de dispositivos de OAuth 2.0 se utiliza para dispositivos desatendidos; las herramientas de CLI y CI/CD utilizan flujo de servidor web (sf org login web) o flujo de soporte JWT (sf org login jwt): el flujo de dispositivos se bloqueó para la aplicación conectada Salesforce CLI predeterminada a partir del 28 de agosto de 2025 |
| Integración | API | ✅ No se utiliza el flujo de OAuth nombre de usuario-contraseña; las integraciones existentes que se basan en él se migran al flujo de credenciales de cliente o portador de JWT |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Organización | ⚠️ MFA no se aplica para el acceso al entorno de producción |
| Plataforma | Organización | ⚠️ Las configuraciones de inicio de sesión no se alinean con los requisitos de Salesforce MFA |
| Plataforma | Organización | ⚠️ MFA no se amplía a operaciones privilegiadas (exportaciones masivas, cambios de permisos, configuración administrativa) |
| Plataforma | Organización | ⚠️ El tiempo de espera de la sesión no está configurado o es excesivamente permisivo (>24 horas) |
| Plataforma | Organización | ⚠️ Las políticas de sesión no distinguen entre usuarios estándar y administradores/usuarios que acceden a datos restringidos |
| Plataforma | Organización | ⚠️ Las restricciones de IP no se aplican para perfiles administrativos y usuarios de integración |
| Plataforma | Organización | ⚠️ Las cuentas de servicio no tienen horarios de inicio de sesión restringidos a los plazos operativos esperados |
| Plataforma | Organización | ⚠️ Las cuentas de alto privilegio no se basan en nada más que la activación de dispositivos: no se agregan restricciones de MFA o IP |
| Plataforma | Organización | ⚠️ Si SSO está activado, ningún usuario administrador aprobado tiene acceso de inicio de sesión directo (sin procedimientos de ruptura de vidrio) |
| Plataforma | Organización | ⚠️ La relación entre usuarios y entidades no es 1:1 (existen cuentas de usuario compartidas) |
| Plataforma | Organización | ⚠️ El Control de acceso de API no está activado |
| Plataforma | Credenciales nombradas | ⚠️ Las credenciales están incrustadas directamente en código, archivos de configuración o control de versión |
| Plataforma | Apex | ⚠️ Los nombres de usuario y contraseñas aparecen en código en formatos legibles |
| Plataforma | Apex | ⚠️ La autenticación se gestiona ad hoc sin una implementación coherente |
| Plataforma | Aura | ⚠️ La autenticación se gestiona ad hoc sin credenciales nombradas |
| Plataforma | Aura | ⚠️ Los nombres de usuario y contraseñas aparecen en código |
| Plataforma | Componentes web Lightning (LWC) | ⚠️ La autenticación se gestiona ad hoc sin credenciales nombradas |
| Plataforma | Componentes web Lightning (LWC) | ⚠️ Los nombres de usuario y contraseñas aparecen en código |
| Plataforma | Negocio | ⚠️ No existen requisitos y SLA de aprovisionamiento y desaprovisionamiento de usuarios |
| Integración | API | ⚠️ El flujo de OAuth nombre de usuario-contraseña se utiliza cuando hay flujos de OAuth más seguros disponibles |
| Integración | API | ⚠️ Los ámbitos de OAuth son demasiado permisivos (acceso completo cuando el ámbito limitado es suficiente) |
| Integración | API | ⚠️ Las credenciales de cliente (Id. de cliente, secreto de cliente) se almacenan de forma insegura en archivos de código o configuración |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Organización | ✅ La profundidad de la jerarquía de funciones es de 5 a 7 niveles máximo (evitando gastos generales de rendimiento y solucionando problemas de complejidad) |
| Plataforma | Organización | ✅ Los conjuntos de permisos y los grupos de conjuntos de permisos proporcionan acceso flexible y aditivo sin proliferación de perfiles |
| Plataforma | Organización | ✅ Los conjuntos de permisos otorgan acceso para funciones de trabajo específicas, solicitudes o privilegios elevados temporales |
| Plataforma | Organización | ✅ Los grupos de conjuntos de permisos combinan conjuntos de permisos relacionados con funciones de silenciamiento para excepciones |
| Plataforma | Organización | ✅ Todo el acceso funcional se otorga a través de conjuntos de permisos y grupos de conjuntos de permisos (no perfiles), proporcionando flexibilidad a medida que evolucionan las funciones de trabajo |
| Plataforma | Organización | ✅ Las políticas de Seguridad de transacciones amplían la autorización con evaluación contextual en tiempo real |
| Plataforma | Organización | ✅ Las políticas de Seguridad de transacciones detectan y bloquean comportamientos anómalos (descargas masivas de datos que superan patrones, inicio de sesión desde geografías inesperadas, cambios de permisos fuera de plazos de cambio) |
| Plataforma | Organización | ✅ Las restricciones de IP están configuradas para operaciones altamente confidenciales o acceso a datos |
| Plataforma | Organización | ✅ Un usuario de integración exclusivo solo de API está configurado para cada integración |
| Plataforma | Apex | ✅ Todo el código que accede a los datos aplica CRUD y FLS utilizando WITH USER_MODE, WITH SYSTEM_MODE palabras clave o métodos Security.stripInaccessible() |
| Plataforma | Apex | ✅ Las consultas SOQL utilizan palabras clave WITH USER_MODE o WITH SYSTEM_MODE de forma explícita basándose en requisitos comerciales |
| Plataforma | Apex | ✅ Las operaciones DML utilizan Security.stripInaccessible() para la aplicación de acceso antes de las operaciones de inserción/actualización/alteración |
| Plataforma | Apex | ✅ Las declaraciones DML de base de datos declaran el modo de usuario o sistema explícitamente para operaciones de datos |
| Plataforma | Apex | ✅ Las operaciones de base de datos utilizan métodos stripInaccessible() para filtrar resultados de consultas y subconsultas |
| Plataforma | Apex | ✅ Las palabras clave de colaboración (con colaboración, sin colaboración, colaboración heredada) se utilizan de forma apropiada basándose en requisitos de seguridad comercial |
| Plataforma | Estándares de diseño | ✅ Los casos de uso para otorgar privilegios elevados (Modificar todos los datos, Ver todos los datos) están claramente documentados con justificación comercial |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Organización | ⚠️ La jerarquía de funciones es más profunda que 5-7 niveles, creando sobrecarga de rendimiento en cálculos de colaboración y solución de problemas de complejidad |
| Plataforma | Organización | ⚠️ La jerarquía de funciones otorga acceso amplio sin justificación comercial |
| Plataforma | Organización | ⚠️ Los perfiles se duplican repetidamente para variaciones de permisos menores, creando docenas de perfiles con distinciones poco claras |
| Plataforma | Organización | ⚠️ Los perfiles contienen controles de acceso para metadatos (deberían utilizar conjuntos de permisos) |
| Plataforma | Organización | ⚠️ Las políticas de Seguridad de transacciones no están implementadas para detectar comportamientos anómalos |
| Plataforma | Organización | ⚠️ Las restricciones de IP no están configuradas para operaciones altamente confidenciales o acceso a datos |
| Plataforma | Organización | ⚠️ Los usuarios solo de API no están configurados o se comparten entre múltiples integraciones |
| Plataforma | Organización | ⚠️ Los permisos Ver todos los datos o Modificar todos los datos se otorgan sin justificación documentada |
| Plataforma | Apex | ⚠️ Las consultas SOQL/SOSL y las operaciones DML se ejecutan en modo de sistema predeterminado sin comprobaciones de acceso explícitas |
| Plataforma | Apex | ⚠️ La aplicación de CRUD y FLS es incoherente o falta |
| Plataforma | Apex | ⚠️ SOQL se basa en WITH SECURITY_ENFORCED, que se eliminó y ahora causa un error de compilación (sustituya con WITH USER_MODE) |
| Plataforma | Apex | ⚠️ Las palabras clave de colaboración se utilizan de forma incoherente o no se utilizan en absoluto |
| Plataforma | Estándares de diseño | ⚠️ Los casos de uso para otorgar permisos elevados no están claramente documentados |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Data 360 | ✅ RBAC (funciones, perfiles, conjuntos de permisos) controla el acceso a la plataforma (quién puede utilizar Data 360), ABAC controla el acceso a los datos (qué datos ven basándose en atributos) |
| Plataforma | Data 360 | ✅ Los agentes de IA se ejecutan en el contexto del usuario solicitante (en nombre de), de modo que las consultas generadas por agentes están restringidas por el acceso de ese usuario en vez de ejecutarse con acceso a nivel del sistema |
| Plataforma | Documentación | ✅ La taxonomía de clasificación de datos está documentada con definiciones de atributos, reglas de aplicación y justificación comercial |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Data 360 | ⚠️ El acceso que debe seguir la clasificación de datos se fuerza a través de la jerarquía de funciones y la colaboración, que no puede expresarlo, en vez de alcanzar el control de acceso basado en atributos |
| Plataforma | Data 360 | ⚠️ Omisión de FLS: usuarios sin acceso a nivel de campo recuperan datos a través de consultas de API o SOQL que no aplican FLS |
| Plataforma | Data 360 | ⚠️ Los agentes de IA consultan datos sin ejecutarse en el contexto del usuario solicitante; las consultas generadas por agentes omiten los controles de acceso a nivel de objeto, campo y registro |
| Plataforma | Data 360 | ⚠️ El contexto de ejecución de agentes no incluye atributos de usuario en nombre de; los agentes operan con acceso a nivel del sistema |
| Plataforma | Documentación | ⚠️ La taxonomía de clasificación de datos no está documentada; las definiciones de atributos varían según el equipo creando una aplicación incoherente |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Organización | ✅ Las cuentas de impacto crítico (administradores del sistema, usuarios de integración, cuentas de procesos automatizados) se identifican y se siguen en el inventario de activos |
| Plataforma | Organización | ✅ Las cuentas de impacto crítico representan objetivos de alto valor debido a privilegios elevados que proporcionan acceso amplio a la plataforma |
| Plataforma | Organización | ✅ Se requieren llaves de seguridad de hardware o aplicaciones de autenticación para MFA (no SMS, que es vulnerable al intercambio de SIM) |
| Plataforma | Organización | ✅ Los intervalos de direcciones IP de inicio de sesión están restringidos a ubicaciones administrativas conocidas |
| Plataforma | Organización | ✅ Las alertas de inicio de sesión y las notificaciones de cambio de permisos están activadas |
| Plataforma | Organización | ✅ Las revisiones de acceso trimestrales se realizan con certificado documentado |
| Plataforma | Organización | ✅ Existen procedimientos de vidrio roto para el acceso de emergencia con auditoría posterior al uso |
| Integración | Cuentas de servicio | ✅ Los flujos de OAuth se utilizan para cuentas de integración y servicio (nunca nombre de usuario-contraseña) |
| Integración | Cuentas de servicio | ✅ Se aplican restricciones de IP para usuarios de integración |
| Integración | Cuentas de servicio | ✅ Se implementan programas de rotación de credenciales (trimestrales o por política) |
| Integración | Cuentas de servicio | ✅ Los patrones de uso de API anómalos se supervisan a través de Supervisión de eventos |
| Integración | Cuentas de servicio | ✅ Cada integración tiene una cuenta de servicio dedicada con los permisos mínimos requeridos (no compartido “usuario de integración” con acceso amplio) |
| Integración | Cuentas de servicio | ✅ Las cuentas de servicio aplican menos privilegios rigurosamente ya que funcionan sin supervisión |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Organización | ⚠️ Las cuentas de impacto crítico (administrador, integración, automatización) no se identifican, se siguen o se inventarian |
| Plataforma | Organización | ⚠️ Los administradores del sistema utilizan MFA basada en SMS en vez de llaves de seguridad de hardware o aplicaciones de autenticación |
| Plataforma | Organización | ⚠️ Las cuentas de impacto crítico no tienen restricciones de hora de inicio de sesión o IP |
| Plataforma | Organización | ⚠️ No hay alertas configuradas para cambios de inicio de sesión o permisos en cuentas privilegiadas |
| Plataforma | Organización | ⚠️ El acceso a cuentas de impacto crítico nunca se revisa o revisa de forma irregular (no trimestral) |
| Plataforma | Organización | ⚠️ No existen procedimientos de rotura de vidrio para el acceso de emergencia |
| Integración | Cuentas de servicio | ⚠️ Se comparte una única cuenta de “Usuario de API” entre múltiples integraciones con el permiso Modificar todos los datos |
| Integración | Cuentas de servicio | ⚠️ Las cuentas de servicio utilizan autenticación de nombre de usuario-contraseña cuando OAuth está disponible |
| Integración | Cuentas de servicio | ⚠️ Las credenciales de cuenta de servicio utilizan contraseñas estáticas sin cambios durante años (sin rotación) |
| Integración | Cuentas de servicio | ⚠️ Las cuentas de servicio tienen privilegios excesivos más allá de lo que requiere la integración |
| Integración | Cuentas de servicio | ⚠️ Los patrones de uso de API anómalos para cuentas de servicio no se supervisan |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Proceso | ✅ Ciclo de vida de identidad incluye: Aprovisionamiento (crear con acceso de línea base), Ajuste de acceso (concesión/revocación a medida que cambian las funciones), Recertificación periódica (validación trimestral), Desaprovisionamiento (revocación inmediata) |
| Plataforma | Organización | ✅ SCIM (Sistema para Gestión de identidad entre dominios) está implementado para el aprovisionamiento automatizado desde proveedores de identidad |
| Plataforma | Proceso | ✅ El aprovisionamiento crea cuentas con función de trabajo coincidente de acceso de línea base, desencadenado por eventos del sistema de recursos humanos |
| Plataforma | Proceso | ✅ El ajuste de acceso otorga permisos adicionales a medida que se amplían las funciones y revoca permisos cuando cambian las funciones |
| Plataforma | Proceso | ✅ La recertificación periódica se produce trimestralmente donde los gerentes revisan y validan el acceso para sus equipos |
| Plataforma | Proceso | ✅ La anulación del aprovisionamiento revoca el acceso inmediatamente cuando finaliza el empleo o la función ya no requiere Salesforce |
| Plataforma | Organización | ✅ La detección automatizada identifica usuarios que no iniciaron sesión en 90 días y desencadena flujos de trabajo de revisión de acceso |
| Plataforma | Organización | ✅ El aprovisionamiento Just-in-Time (JIT) crea usuarios automáticamente desde SSO cuando es apropiado |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Organización | ⚠️ El aprovisionamiento de SCIM no está implementado a pesar de tener integración de proveedor de identidad |
| Plataforma | Proceso | ⚠️ Los nuevos usuarios se crean manualmente sin procedimientos de incorporación estándar |
| Plataforma | Proceso | ⚠️ El acceso inicial del usuario es incoherente o se basa en copiar usuarios existentes |
| Plataforma | Proceso | ⚠️ Los cambios de acceso para cambios de funciones o transferencias se retrasan o están incompletos |
| Plataforma | Proceso | ⚠️ La incorporación se retrasa; los antiguos empleados conservan el acceso tras la rescisión (no la desactivación el mismo día) |
| Plataforma | Organización | ⚠️ No existe automatización para el aprovisionamiento de usuarios (solo creación manual de usuarios) |
| Plataforma | Proceso | ⚠️ No existen campañas de recertificación de acceso (sin revisión trimestral o anual) |
| Plataforma | Proceso | ⚠️ No se elimina el acceso innecesario identificado durante la recertificación |
| Plataforma | Proceso | ⚠️ La recertificación de acceso no es rigurosa para cuentas privilegiadas, acceso entre organizaciones, usuarios externos |
| Plataforma | Organización | ⚠️ Las cuentas latentes (sin inicio de sesión en más de 90 días) se acumulan sin revisión o desactivación |