🛡️
El Modelo de Seguridad de Salesforce: Capas de Acceso
Dominando OWD, jerarquía de roles, perfiles, conjuntos de permisos y reglas de compartición.
⏱️ Tiempo estimado de lectura: 45 minutos
La Pirámide de Seguridad
El acceso en Salesforce se gestiona en tres niveles principales. Imagina una pirámide:
1. Objeto (Nivel Base): ¿Puede el usuario ver el objeto 'Cuentas'? (Perfiles/Permission Sets).
2. Campo: Si puede ver el objeto, ¿puede ver el campo 'Salario'? (Field-Level Security).
3. Registro (Nivel Superior): Si puede ver el objeto y el campo, ¿puede ver el registro específico de 'Cliente A'? (OWD, Jerarquía de Roles, Sharing Rules).
1. Objeto (Nivel Base): ¿Puede el usuario ver el objeto 'Cuentas'? (Perfiles/Permission Sets).
2. Campo: Si puede ver el objeto, ¿puede ver el campo 'Salario'? (Field-Level Security).
3. Registro (Nivel Superior): Si puede ver el objeto y el campo, ¿puede ver el registro específico de 'Cliente A'? (OWD, Jerarquía de Roles, Sharing Rules).
Puntos Clave
- ✓ Los Perfiles y Permission Sets determinan qué puede hacer el usuario (CRED: Create, Read, Edit, Delete)
- ✓ El acceso a registros determina qué datos específicos puede ver
- ✓ Regla de Oro: Los permisos de Objeto SIEMPRE se respetan. Si no tengo acceso al objeto, no importa si alguien comparte un registro conmigo.
Acceso a Objetos y Campos (Perfiles y Permission Sets)
Perfiles: Son la base. Cada usuario tiene uno. Definen permisos de objeto, apps visibles, horas de login e IPs.
Permission Sets: Extienden el acceso. Se usan para dar permisos específicos sin crear perfiles nuevos.
Field-Level Security (FLS): Es la forma más restrictiva de seguridad. Si un campo es oculto por FLS, el usuario no lo verá en reportes, vistas de lista ni resultados de búsqueda, incluso si tiene acceso al registro.
Permission Sets: Extienden el acceso. Se usan para dar permisos específicos sin crear perfiles nuevos.
Field-Level Security (FLS): Es la forma más restrictiva de seguridad. Si un campo es oculto por FLS, el usuario no lo verá en reportes, vistas de lista ni resultados de búsqueda, incluso si tiene acceso al registro.
Puntos Clave
- ✓ Permission Sets solo pueden OTORGAR acceso, nunca restringirlo
- ✓ Standard Profiles no se pueden editar (debes clonarlos)
- ✓ FLS prevalece sobre los Page Layouts: si un campo es obligatorio en el layout pero el usuario no tiene permiso de edición en FLS, no podrá editarlo.
Record-Level 1: Organization-Wide Defaults (OWD)
Los OWD definen el acceso base de los usuarios a los registros que NO son de su propiedad.
- Private: Solo el dueño ve el registro.
- Public Read-Only: Todos ven, solo el dueño edita.
- Public Read/Write: Todos ven y editan.
- Controlled by Parent: (Solo para hijos en Master-Detail). La seguridad depende del objeto padre.
- Private: Solo el dueño ve el registro.
- Public Read-Only: Todos ven, solo el dueño edita.
- Public Read/Write: Todos ven y editan.
- Controlled by Parent: (Solo para hijos en Master-Detail). La seguridad depende del objeto padre.
Puntos Clave
- ✓ OWD es la única forma de RESTRINGIR acceso a registros
- ✓ Se debe configurar el OWD al nivel más restrictivo posible para el negocio
- ✓ Para objetos personalizados, puedes desmarcar 'Grant Access Using Hierarchies' para que los mánagers no vean registros de sus subordinados (en objetos estándar esto no se puede desactivar).
Record-Level 2 & 3: Jerarquía de Roles y Sharing Rules
Role Hierarchy (Acceso Vertical): Permite que los usuarios en niveles superiores de la jerarquía vean los registros de sus subordinados. No tiene que coincidir con el organigrama de la empresa.
Sharing Rules (Acceso Horizontal): Son excepciones automáticas. Permiten compartir registros entre grupos públicos, roles o territorios basados en criterios (ej: 'Compartir todas las Cuentas de tipo Farmacia con el equipo de Madrid').
Sharing Rules (Acceso Horizontal): Son excepciones automáticas. Permiten compartir registros entre grupos públicos, roles o territorios basados en criterios (ej: 'Compartir todas las Cuentas de tipo Farmacia con el equipo de Madrid').
Puntos Clave
- ✓ Sharing Rules solo se usan cuando el OWD es Private o Public Read-Only
- ✓ Existen dos tipos de Sharing Rules: Based on Owner (dueño) y Based on Criteria (campos)
- ✓ Los Roles determinan qué registros ves; los Perfiles determinan qué haces con ellos.
Record-Level 4: Manual Sharing y Equipos
Manual Sharing: Permite al dueño de un registro compartirlo individualmente con otro usuario. En Lightning, se hace mediante el botón 'Sharing'.
Account/Opportunity/Case Teams: Permite que un grupo de usuarios trabaje en un registro específico. El administrador debe habilitar los equipos y definir los roles de equipo.
Account/Opportunity/Case Teams: Permite que un grupo de usuarios trabaje en un registro específico. El administrador debe habilitar los equipos y definir los roles de equipo.
Puntos Clave
- ✓ Para compartir manualmente, el usuario debe ser el Dueño, un Mánager en la jerarquía o un Administrador
- ✓ Los equipos facilitan reportes sobre quién colaboró en una venta exitosa
- ✓ Si el dueño del registro cambia, el Manual Sharing se elimina automáticamente.
Monitoreo: Health Check y Auditoría
Health Check: Es una herramienta que escanea la configuración de seguridad y asigna una puntuación (0-100%). Identifica riesgos como contraseñas débiles o sesiones que no expiran.
Setup Audit Trail: Registra los cambios hechos por los administradores en los últimos 180 días (quién cambió un perfil, quién creó un campo).
Setup Audit Trail: Registra los cambios hechos por los administradores en los últimos 180 días (quién cambió un perfil, quién creó un campo).
Puntos Clave
- ✓ Login History: Muestra los últimos 6 meses de intentos de inicio de sesión (éxitos y fallos)
- ✓ Field Audit Trail: Permite rastrear la historia de valores de un campo (requiere licencia adicional para más de 18 meses)
- ✓ Password Policies se pueden configurar a nivel de Org o a nivel de Perfil (el Perfil siempre gana).