Modelo de Seguridad para App Builder

El modelo de seguridad de Salesforce es un sistema de capas progresivamente más granulares. Cada capa restringe el acceso de forma más precisa.

Pirámide de Seguridad (de más amplio a más específico):

┌──────────────────────────────────┐
│   1. ORGANIZATION LEVEL          │  ← Quién puede entrar a la org
├──────────────────────────────────┤
│   2. OBJECT LEVEL (CRUD)         │  ← Qué objetos puede ver
├──────────────────────────────────┤
│   3. FIELD LEVEL (FLS)           │  ← Qué campos puede ver
├──────────────────────────────────┤
│   4. RECORD LEVEL                │  ← Qué registros específicos puede ver
└──────────────────────────────────┘

Capa 1 — Organization Level:
- Login IP Ranges: Restringir desde qué IPs puede iniciar sesión un perfil.
- En Profiles: Si el usuario está FUERA del rango, se BLOQUEA el acceso completamente.
- En Permission Sets: Si está FUERA, se requiere verificación de identidad (pero no se bloquea).
- Login Hours: Restringir en qué horarios puede iniciar sesión (por perfil).
- Password Policies: Complejidad, expiración, historial de contraseñas.
- MFA (Multi-Factor Authentication): Segundo factor de autenticación obligatorio.
- Session Security: Tiempo de expiración de sesión, niveles de seguridad.

Capa 2 — Object Level (CRUD):
- Profiles y Permission Sets controlan Create, Read, Update, Delete y View All / Modify All por objeto.
- Sin permiso Read → el usuario no ve el objeto en ningún contexto.
- Sin permiso Create → no puede crear registros de ese objeto.

Capa 3 — Field Level Security (FLS):
- Controla la visibilidad de campos individuales dentro de un objeto.
- Dos opciones por campo: Visible (puede ver) y Read-Only (puede ver pero no editar).
- Si un campo es invisible por FLS, no aparece en: UI, reportes, API, list views, ni results de búsqueda.
- FLS es el control más definitivo para campos.

Capa 4 — Record Level:
- Controla qué registros específicos puede ver cada usuario.
- Componentes: OWD + Role Hierarchy + Sharing Rules + Manual Sharing + Teams.
- Se detalla en las siguientes secciones.

Principio fundamental (CLAVE para el examen):
El acceso se configura de lo más restrictivo a lo más permisivo. Empezar con OWD restrictivo y abrir con Sharing Rules. NUNCA se puede restringir más que el OWD (excepto con Restriction Rules, que son una excepción avanzada).

Profiles (Perfiles):
Cada usuario tiene exactamente UN perfil. El perfil define los permisos BASE del usuario.

Qué controla un Profile:
- CRUD por objeto: Create, Read, Update, Delete, View All, Modify All.
- Field-Level Security: Visibilidad y editabilidad de campos.
- System Permissions: Permisos del sistema (API Enabled, View Setup, Create Reports, Manage Users, etc.).
- Login Hours: Horario de acceso permitido.
- Login IP Ranges: Rangos de IP permitidos (BLOQUEA si está fuera).
- Default Record Type: Record Type por defecto por objeto.
- Page Layout Assignment: Combinación con Record Type.
- App Visibility: Qué Lightning Apps puede ver el usuario.
- Tab Settings: Visibilidad de tabs (Default On, Default Off, Hidden).

Tipos de Profiles estándar:
- System Administrator: Todos los permisos. No se puede modificar ni eliminar.
- Standard User: Permisos básicos de lectura/escritura.
- Standard Platform User: Para usuarios de la plataforma (sin Sales/Service).
- Minimum Access - Salesforce: Acceso mínimo, ideal como base + Permission Sets.
- Read Only: Solo lectura en todos los objetos.

Salesforce recomienda: Usar el perfil "Minimum Access" como base y agregar permisos con Permission Sets. Esto se llama el modelo de "least privilege" (mínimo privilegio).

Permission Sets (Conjuntos de Permisos):
Un usuario puede tener múltiples Permission Sets. Solo AÑADEN permisos, nunca restan.

Qué controla un Permission Set:
- Todos los mismos permisos que un Profile (CRUD, FLS, System Permissions).
- Login IP Ranges (con comportamiento diferente: pide verificación, no bloquea).
- Object permissions, Field permissions, System permissions, App permissions.

Ventajas sobre Profiles:
- Se pueden asignar múltiples PS a un usuario.
- Son acumulativos (suman permisos).
- Permiten dar permisos granulares sin crear múltiples perfiles.
- Más fáciles de mantener: un PS puede servir para múltiples perfiles.

Permission Set Groups (Grupos de Conjuntos de Permisos):
- Agrupan múltiples Permission Sets en un solo paquete asignable.
- Simplifican la gestión: en vez de asignar 5 PS individualmente, asignas 1 grupo.
- Muting Permission Set: Se puede incluir un PS especial dentro del grupo que desactiva permisos específicos de los otros PS del grupo. Es la única forma de "restar" permisos dentro de un grupo.

Tabla comparativa para el examen:

Característica	Profile	Permission Set	PS Group
Asignación por usuario	1 obligatorio	0 o más	0 o más
Añade permisos	✅	✅	✅
Quita permisos	❌	❌	✅ (Muting PS)
Login Hours	✅	❌	❌
Login IP Ranges	✅ (bloquea)	✅ (verifica)	❌
Default Record Type	✅	✅	❌
Page Layout Assignment	✅	❌	❌

La seguridad a nivel de registro determina qué registros específicos puede ver cada usuario, incluso si tiene permisos CRUD sobre el objeto.

Organization-Wide Defaults (OWD) — La Base:
Definen el nivel de acceso por DEFECTO que tienen todos los usuarios para cada objeto.

OWD Setting	Significado
Private	Solo el propietario y superiores en jerarquía pueden ver sus registros
Public Read Only	Todos pueden ver, pero solo el propietario puede editar
Public Read/Write	Todos pueden ver Y editar todos los registros
Public Read/Write/Transfer	Todos pueden ver, editar y transferir (solo Leads y Cases)
Controlled by Parent	Hereda el acceso del objeto padre (solo en Master-Detail)

Regla de oro: Si CUALQUIER grupo de usuarios necesita acceso restringido a registros de un objeto → el OWD debe ser Private (o Public Read Only). Luego se abre el acceso con herramientas de sharing.

Si el OWD es Public Read/Write, NO necesitas configurar Sharing Rules ya que todos pueden ver y editar todo.

Role Hierarchy (Jerarquía de Roles):
- Los usuarios en roles superiores automáticamente heredan acceso a los registros de usuarios en roles inferiores.
- Ejemplo: VP de Ventas puede ver todos los registros de sus Sales Managers, que a su vez pueden ver los registros de sus Sales Reps.
- La jerarquía de roles NO es lo mismo que el organigrama (reporting hierarchy en el User record). La jerarquía de roles es para ACCESO A DATOS.
- Grant Access Using Hierarchies: Configuración por objeto que permite desactivar la herencia de la jerarquía de roles para custom objects. Para standard objects, siempre está activa.

Sharing Rules (Reglas de Compartición):
Abren el acceso más allá del OWD para grupos específicos de usuarios.

Dos tipos de Sharing Rules:

1. Ownership-Based Sharing Rules:
- "Los registros propiedad de usuarios del Grupo A son visibles para usuarios del Grupo B."
- Se basa en quién es el propietario del registro.
- Ejemplo: Los registros de Opportunities propiedad de Sales Team West se comparten con Sales Managers.

2. Criteria-Based Sharing Rules:
- "Los registros que cumplen CRITERIOS específicos son visibles para un grupo."
- Se basa en valores de campos del registro (no en el propietario).
- Ejemplo: Todos los Cases donde Priority = 'Critical' se comparten con Executive Team.
- Más flexibles que Ownership-Based.

Shared with options: Public Groups, Roles, Roles & Subordinates, Queues.

Manual Sharing:
- El propietario del registro (o un admin) puede compartir un registro específico con usuarios, roles o public groups.
- Se hace clic en el botón 'Sharing' en el registro.
- Es temporal y se elimina si cambia el propietario del registro.

Account Teams / Opportunity Teams / Case Teams:
- Permiten asignar un equipo de usuarios a un registro específico con diferentes niveles de acceso.
- Se configuran como un tipo de rol dentro del equipo (ej: Account Manager, Executive Sponsor).
- Cada miembro del equipo puede tener acceso Read Only o Read/Write.

Public Groups:
- Contenedores de usuarios, roles, y/o otros public groups que simplifican la asignación de Sharing Rules.
- Ejemplo: crear un grupo Executive_Team que incluye roles de CEO, CFO, CTO, y luego compartir registros con ese grupo.

Queues:
- Grupos especiales de usuarios que pueden ser propietarios de registros.
- Los registros en una Queue aparecen en una List View compartida.
- Solo disponibles para: Leads, Cases, Custom Objects y algunos objetos estándar.
- Caso de uso: asignación de Leads/Cases entrantes a un pool de agentes.

El examen PAB presenta escenarios donde debes elegir la solución de seguridad correcta. Aquí los patrones más comunes:

Escenario 1: "Los vendedores solo deben ver sus propias Opportunities"
- Solución: OWD de Opportunity = Private.
- Los managers verán las de sus subordinados gracias a la Role Hierarchy.
- No se necesitan Sharing Rules adicionales.

Escenario 2: "El equipo de Marketing necesita ver, pero no editar, todas las Opportunities"
- Solución: OWD de Opportunity = Private (para que vendedores no vean entre sí).
- Sharing Rule: Compartir todas las Opportunities con el Public Group 'Marketing' con acceso Read Only.

Escenario 3: "Un usuario no puede ver un campo específico en la UI ni en reportes"
- Solución: Field-Level Security (FLS). Hacer el campo invisible para el perfil del usuario.
- FLS oculta el campo en TODOS los contextos.

Escenario 4: "Un usuario puede ver el objeto Account pero no puede crear nuevos registros"
- Solución: En el Profile o Permission Set, dar permiso Read pero NO Create para Account.

Escenario 5: "Los Cases críticos deben ser visibles para el equipo ejecutivo"
- Solución: Criteria-Based Sharing Rule: Donde Priority = 'Critical', compartir con el grupo 'Executive Team' con Read/Write.

Escenario 6: "Necesito dar permisos adicionales a un grupo de usuarios sin crear un nuevo perfil"
- Solución: Permission Set o Permission Set Group.
- Crear un PS con los permisos adicionales y asignarlo a los usuarios.

Escenario 7: "Un usuario ve registros en el objeto pero un campo aparece vacío cuando tiene datos"
- Causa probable: FLS — el campo no es visible para el perfil del usuario.
- O: el campo puede estar excluido del Page Layout asignado.

Escenario 8: "Un propietario de registro necesita compartir un caso específico con un colega temporalmente"
- Solución: Manual Sharing — hacer clic en 'Sharing' en el registro y añadir al usuario.

Escenario 9: "Los Leads entrantes deben ser distribuidos entre un grupo de agentes"
- Solución: Queue — crear una Queue con los agentes. Los Leads se asignan a la Queue y los agentes los toman de la lista compartida.

Escenario 10: "Un administrador quiere aplicar el principio de mínimo privilegio"
- Solución: Asignar el perfil Minimum Access - Salesforce a todos los usuarios y usar Permission Sets para añadir solo los permisos necesarios.

Tabla de decisión rápida:

Necesidad	Herramienta
Controlar qué objetos puede ver	Profile / Permission Set (CRUD)
Ocultar campos en todos los contextos	Field-Level Security (FLS)
Limitar acceso a registros específicos	OWD + Sharing Rules
Permisos adicionales para grupo de usuarios	Permission Set / PS Group
Compartir un registro específico temporalmente	Manual Sharing
Distribuir registros entre un pool de agentes	Queue
Restricciones de horario de login	Profile (Login Hours)
Restricciones de IP	Profile (bloquea) o PS (verifica)