Sicurezza: profili, permission set e modello di condivisione

La sicurezza di Salesforce si legge a strati che si restringono: organizzazione (chi può entrare, da dove, con quale verifica), oggetto (chi crea, legge, modifica, elimina un tipo di record), campo e record (quali singole righe). Ogni strato è indipendente: chi non ha Read sull’oggetto Opportunity non vedrà mai un’opportunità, nemmeno se una sharing rule gliela condivide. L’esame sfrutta continuamente questa indipendenza.

Controlli di sicurezza dell’organizzazione

Il primo strato non decide cosa vedi, decide se e da dove puoi accedere.

• Login Hours — si impostano sul profilo e definiscono le fasce orarie in cui gli utenti di quel profilo possono effettuare il login. Fuori fascia il login è rifiutato. Il dettaglio che l’esame ama: se l’utente è già dentro quando le login hours finiscono, può continuare a vedere la pagina corrente ma non può compiere altre azioni. Non viene espulso e non perde il lavoro già salvato: resta congelato in sola visualizzazione.
• Login IP Ranges — anch’essi sul profilo. Chi tenta il login da un indirizzo IP fuori dagli intervalli dichiarati non entra affatto, e non gli viene offerto alcun codice di verifica alternativo. È il vero blocco per località.
• Trusted IP Ranges — impostazione a livello di org (Setup → Network Access). Non bloccano nessuno: chi arriva da un IP fidato salta la verifica dell’identità, chi arriva da fuori entra comunque, dopo aver inserito un codice di verifica.

• Identity verification e MFA — per i login diretti alla UI Salesforce riconosce quattro famiglie di metodi: Salesforce Authenticator, app TOTP di terze parti (Google Authenticator, Microsoft Authenticator, Authy), security key fisiche conformi a FIDO U2F / WebAuthn (YubiKey, Titan) e built-in authenticator del dispositivo, cioè i lettori biometrici (Touch ID, Face ID, Windows Hello). SMS, e-mail, telefonata e domande di sicurezza non figurano fra i metodi che soddisfano il requisito MFA.
• Session Settings — timeout e durata della sessione, vincolo della sessione all’indirizzo IP di origine e soprattutto i Session Security Levels, dove si dichiara quali metodi di autenticazione valgono High Assurance. Su questo poggiano i session-based permission set, che concedono un permesso solo finché la sessione è attiva: chiusa la sessione, il permesso va riattivato.
• Setup Audit Trail — registra le modifiche di setup recenti fatte dagli amministratori. È la risposta corretta quando la domanda chiede «chi ha cambiato questa impostazione e quando»; non traccia le modifiche ai dati dei record.
• Accesso degli agenti — un agente Agentforce non ha un modello di sicurezza proprio: opera con un utente dedicato e vede esattamente ciò che profilo, permission set e regole di condivisione di quell’utente gli concedono. È funzionalità recente e in rapida evoluzione: verificane il comportamento nella release della tua org.

Profili, permission set e permission set group

Il profilo è obbligatorio e unico per utente; i permission set sono facoltativi e cumulabili. La regola pratica: nel profilo si mette il minimo comune denominatore, nei permission set le eccezioni.

Un permission set group aggrega più permission set in un unico blocco pensato per una mansione: i permessi si sommano in unione. Tre punti che l’esame verifica:

1. lo stesso permission set può appartenere a più gruppi;
2. un permission set incluso in un gruppo resta assegnabile anche singolarmente;
3. il gruppo ha uno stato (Updated, Outdated, Updating, Failed) perché ogni modifica ai permission set che contiene ne innesca il ricalcolo.

Il muting permission set è l’unico strumento sottrattivo: disattiva permessi specifici dentro quel gruppo. Ma il muting non è una revoca globale. Se lo stesso permesso arriva all’utente da un profilo, da un permission set assegnato direttamente o da un altro gruppo, l’utente continua ad averlo. Per togliere davvero un permesso bisogna eliminarne tutte le fonti.

Il modello di condivisione dei record

L’accesso ai record si costruisce partendo dal livello più chiuso e aprendo per eccezioni.

1. Org-wide default (OWD) — il pavimento: Private, Public Read Only, Public Read/Write, Controlled by Parent. Si sceglie il valore più restrittivo di cui l’utente meno privilegiato ha bisogno.
2. Role hierarchy — apre solo verso l’alto: chi sta a un dato livello vede, modifica e riporta su tutti i dati posseduti da chi sta sotto di lui. Mai di lato (i pari grado non si vedono) e mai verso il basso. Per gli oggetti custom si può disattivare Grant Access Using Hierarchies; sugli oggetti standard il travaso gerarchico resta.
3. Sharing rule — automatiche, aprono lateralmente: owner-based (i record posseduti da certi utenti, ruoli o gruppi) o criteria-based (i record i cui campi soddisfano un criterio).
4. Public group — l’insieme riutilizzabile con cui si popolano sharing rule e condivisione delle cartelle. Può contenere utenti, ruoli, ruoli e subordinati, territori (e territori e subordinati) e altri public group. Non contiene profili né permission set.
5. Manual sharing — il pulsante Share sul singolo record: il proprietario (o chi sta sopra di lui) apre l’accesso caso per caso.
6. Team (Account Team, Opportunity Team, Case Team) — la via corretta quando su pochi record specifici servono livelli di accesso diversi per persona e anche sugli oggetti correlati: un team member di account può ricevere Read Only sull’account e Read/Write sui case collegati, un altro solo Read Only su tutto.

Cartelle di report e dashboard

Report e dashboard vivono in cartelle che possono essere private, condivise o pubbliche; l’accesso si concede a ruoli, ruoli e subordinati, public group o territori, con livelli Viewer, Editor, Manager. Accesso alla cartella e accesso ai dati sono due cose diverse: la cartella decide se apri il report, il modello di condivisione decide quante righe ci trovi dentro.

Sulle dashboard il campo View Dashboard As sceglie il running user: un utente fisso, oppure The dashboard viewer — la dynamic dashboard, in cui ognuno vede i propri dati. Vincolo strutturale: una dynamic dashboard non può essere salvata in una cartella privata, va messa in una cartella condivisa con il pubblico previsto.

Trappole tipiche d’esame

• Login Hours ≠ logout forzato. Allo scadere l’utente resta sulla pagina corrente in sola lettura: non viene disconnesso e non perde la sessione. Le risposte «viene espulso» o «perde le modifiche non salvate» sono distrattori.
• Login IP Ranges contro Trusted IP Ranges. I primi (sul profilo) bloccano; i secondi (org-wide) esentano dalla verifica ma non impediscono a nessuno di entrare. Se lo scenario dice «solo un profilo deve essere confinato, gli altri devono poter entrare da ovunque», la risposta è Login IP Ranges su quel profilo — non toccare le impostazioni org-wide.
• SMS e e-mail non sono metodi MFA validi. I quattro riconosciuti sono Salesforce Authenticator, app TOTP, security key FIDO e authenticator integrato nel dispositivo.
• La gerarchia dei ruoli non è un ascensore bidirezionale. Salire di un livello sotto il manager fa vedere i record al manager, non al collaboratore. Con OWD Private e nessuna sharing rule, il rep continua a vedere solo i propri record.
• Il muting non revoca un permesso assegnato altrove. Se lo stesso permission set è anche assegnato direttamente all’utente, il muting dentro il gruppo non produce alcun effetto: va rimossa l’assegnazione diretta.
• Una dynamic dashboard non sta in una cartella privata. Se lo scenario parla di View Dashboard As impostato su «the dashboard viewer» e di distribuzione al team, il difetto è la cartella, non l’impostazione del running user.
• Public group ≠ contenitore di profili. Ci si mettono utenti, ruoli, ruoli e subordinati, territori e altri gruppi. Il profilo non è un membro possibile.