Dati sensibili, Health Check e impostazioni di sicurezza

Il punto d’esame di questa unità tiene insieme due cose che in Setup vivono in posti diversi: le impostazioni di sicurezza che hai configurato tu, e i cambiamenti che Salesforce ha già deciso e che entreranno in vigore da soli, alla loro data. L’esame ci gira intorno con tre strumenti — Release Updates, Health Check e Security Center — e quasi tutte le risposte sbagliate nascono dallo scegliere l’uno al posto dell’altro.

Release Updates: i cambiamenti già decisi

Release Updates è il nodo di Setup dove Salesforce elenca le modifiche di comportamento che verranno attivate in modo obbligatorio a partire da una certa release. Non sono funzionalità nuove da adottare se ti piacciono: sono interruttori che a un certo punto scattano comunque. Alcuni cambiano il modo in cui viene valutato l’accesso degli utenti — ed è esattamente il caso che l’esame ama.

Ogni update ha una data Complete Steps By e finisce in una di quattro categorie:

La categoria non è una raccomandazione: è un conto alla rovescia. Il pulsante Get Started di ogni update apre una guida passo passo e, per molti update, un test run che aiuta a capire l’impatto sulle personalizzazioni esistenti prima di attivare davvero.

Quando un update è sotto Needs Action e sai che cambierà come viene valutato l’accesso di qualcuno, le due mosse giuste prima della data sono sempre le stesse: attivarlo prima in un sandbox e verificare lì chi perde o guadagna accesso, non in produzione e non aspettando che scatti. La documentazione di release readiness è netta: «Test any Release Updates. These are listed under Release Updates in your org Setup menu». Se il test fa emergere una rottura, la strada è aprire un caso con il supporto Salesforce finché c’è tempo — non disattivare l’update e sperare, perché l’attivazione automatica arriva lo stesso.

Quale sandbox, e la trappola del refresh

Testare «in un sandbox» non basta come risposta: serve un sandbox che abbia già la release nuova. È il sandbox preview: i sandbox che vivono su preview instances ricevono la release alcune settimane prima della produzione, quelli su non-preview instances la ricevono dopo — a volte dopo la produzione stessa. Quale sia il tuo lo si vede dalla colonna Location nell’elenco dei sandbox in Setup, incrociata con la guida ufficiale del sandbox preview.

La trappola da ricordare: un sandbox rinnovato durante la finestra di preview si sposta su un’istanza non-preview, e perde l’anteprima. La regola pratica è avere almeno un sandbox preview e non toccarlo con un refresh in quel periodo.

Health Check: una sola org, misurata contro un riferimento

Health Check si apre da Setup cercando Health Check nella Quick Find e mostra un punteggio da 0 a 100 che dice quanto le impostazioni di sicurezza dell’org sono allineate a quelle raccomandate da Salesforce. Sotto il punteggio c’è l’elenco delle singole impostazioni con il valore attuale e quello raccomandato, e due modi per intervenire: il link Edit accanto alla riga, oppure il pulsante Fix Risks, che porta tutte le impostazioni al valore raccomandato in un colpo solo. Per usarlo servono i permessi View Setup and Configuration e Manage Password Policies.

Il punto che l’esame sfrutta è il baseline. Di serie il confronto avviene contro lo standard baseline di Salesforce. Ma un’azienda regolata può avere uno standard interno più severo dei valori consigliati: in quel caso si importa un custom baseline, un file XML con i valori richiesti, e da quel momento il punteggio e le righe «a rischio» raccontano la distanza dallo standard aziendale, non da quello di Salesforce. È la risposta a «voglio vedere in un posto solo quanto la produzione si discosta dalla nostra policy»: non un report, non un flow, non Security Center — un custom baseline su Health Check.

Le impostazioni che Health Check pesa sono quelle a livello di org: i Session Settings (durata della sessione, Clickjack Protection, protezione XSS, HttpOnly, obbligo di HTTPS) e le password policy. Sono anche le prime da guardare quando qualcuno dice «vengo buttato fuori» o «non riesco più a entrare».

Trusted IP Ranges e Login IP Ranges non sono la stessa cosa

Due voci che si assomigliano e fanno cose opposte, ed è tipico materiale da troubleshooting.

Il secondo è restrittivo, il primo è solo una scorciatoia sulla verifica. Un utente che «non riesce a entrare da casa» è quasi sempre un caso di Login IP Ranges sul profilo, non di Network Access.

Security Center: molte org insieme

Health Check guarda un’org. Quando l’azienda ne ha diverse — tipico dopo acquisizioni — e qualcuno vuole una vista unica, lo strumento è Security Center: un’applicazione separata in cui si designa un’org come parent tenant e le altre si collegano come child tenant. Da lì una sola dashboard mostra, per tutte insieme, i metodi di autenticazione in uso, le assegnazioni di permessi sensibili (Modify All Data, View All Data, Author Apex), gli utenti e i profili, i pacchetti installati (managed, unmanaged e AgentExchange) e i punteggi di Health Check con il loro andamento.

Due dettagli operativi che tornano nelle domande: i dati si aggiornano una volta al giorno, con possibilità di aggiornamento manuale, e si possono creare alert — per esempio una notifica quando il punteggio di Health Check scende. È la differenza che l’esame cerca: Health Check è una fotografia della tua org, Security Center è la fotografia di tutte, con la storia e gli allarmi.

Trappole tipiche d’esame

• «Testa in un sandbox» non è la risposta completa. Se lo scenario parla di una release o di un Release Update, il sandbox deve essere preview; e un refresh fatto durante la finestra di preview sposta il sandbox su un’istanza non-preview, facendoti testare la release vecchia.
• Un Release Update sotto Needs Action non è opzionale. Non fare nulla non lo annulla: alla Complete Steps By scatta comunque. Le risposte «lo disattivo» o «chiedo un’esenzione» sono distrattori; quelle giuste sono attivarlo in sandbox, verificare l’impatto sull’accesso e aprire un caso al supporto se qualcosa si rompe.
• Standard baseline contro custom baseline. «Il nostro standard interno è più severo di quello di Salesforce» chiede l’import di un custom baseline XML in Health Check. Chi risponde Fix Risks porta l’org ai valori raccomandati da Salesforce, che in quel contesto sono troppo blandi — e cancella proprio lo scarto che si voleva misurare.
• Health Check è per una org sola. Appena lo scenario nomina più org, acquisizioni, o un CISO che vuole «una console unica», la risposta è Security Center con parent e child tenant, non Health Check eseguito org per org e nemmeno un report.
• Trusted IP Ranges non blocca nessuno. Restringe la verifica d’identità, non l’accesso. Il blocco vero sono i Login IP Ranges sul profilo o sul permission set: è lì che si guarda quando un utente non riesce a entrare da una rete nuova.
• Il punteggio di Health Check non è un certificato di compliance. È l’allineamento a un baseline: un’org può stare in cima al punteggio contro lo standard Salesforce e violare comunque la policy aziendale. Ed è il motivo per cui Security Center permette un alert sul calo del punteggio, non un obiettivo da raggiungere.