Trust

In Salesforce, Trust è il nostro valore principale. È alla base di ogni decisione architettonica sulla piattaforma. Per gli architetti, Trust si ottiene attraverso una partnership unica: Salesforce offre una piattaforma sicura e conforme (l'infrastruttura, i metadati e gli strumenti necessari per personalizzarla) mentre si progettano soluzioni sicure basate su queste basi.

Questa partnership opera attraverso il Modello di responsabilità condivisa, che è un framework che divide chiaramente le responsabilità in materia di sicurezza:

• Salesforce è responsabile della sicurezza della piattaforma, incluse l'infrastruttura, le patch e le certificazioni di conformità.
• L'utente è responsabile della sicurezza della piattaforma, inclusi configurazione, controlli di accesso, codice personalizzato e governance dei dati.

Questa divisione è essenziale perché definisce la responsabilità architettonica. Salesforce gestisce un'architettura multi-tenant in cui migliaia di organizzazioni condividono l'infrastruttura. La piattaforma offre forti protezioni di sicurezza a livello di infrastruttura. Le decisioni architettoniche determinano se le soluzioni specifiche guadagnano la fiducia degli stakeholder.

Il modello di responsabilità condivisa consente di progettare soluzioni sicure mentre la sicurezza fisica, la protezione della rete, le patch della piattaforma e la crittografia dell'infrastruttura vengono gestite automaticamente. Ciò consente di concentrarsi sulla progettazione di soluzioni sicure basate su tali basi (ad esempio, gestione dell'identità e dell'accesso, protezione dei dati, sicurezza dell'integrazione, procedure di sviluppo sicure, conformità e conformità ai regolamenti e capacità di risposta agli incidenti).

Trascurare Trust durante la progettazione aggrava il debito tecnico. Una strategia di crittografia mancante diventa un ammodernamento costoso quando cambiano i regolamenti. Un'integrazione non governata diventa una vulnerabilità quando le credenziali vengono compromesse. Creare Trust fin dall'inizio è sempre meno costoso che ristrutturarlo in seguito.

Trust abbraccia quattro dimensioni architettoniche che lavorano insieme in modo coerente:

• I controlli di sicurezza proteggono i sistemi e i dati
• La gestione dell'identità regola l'accesso
• Le pratiche sulla privacy rispettano l'agenzia degli utenti
• I framework di conformità soddisfano gli obblighi normativi

Gli architetti che progettano per tutte e quattro le dimensioni creano soluzioni che guadagnano e sostengono Trust attraverso trasparenza, controllo e resilienza.

Nell'era degli agenti, Trust si estende al contesto affidabile in cui operano gli agenti. Contesto affidabile significa che gli agenti accedono a dati gestiti e verificati con confini di identità e autorizzazioni chiari, il che consente ai sistemi di intelligenza artificiale di ragionare e agire per conto degli utenti mantenendo al contempo sicurezza, controllabilità e conformità. La progettazione di un contesto affidabile è fondamentale per l'architettura Agentic Enterprise.

Questo pilastro stabilisce la base di riferimento per la sicurezza della piattaforma da cui dipende ogni soluzione Salesforce. Il pilastro Agentic Trust si basa su tale base di riferimento per affrontare i rischi specifici degli agenti autonomi, tra cui la pronta iniezione, la governance delle azioni e i dati a cui gli agenti possono accedere durante i tempi di ragionamento. È importante progettare prima la base di riferimento, quindi stratificare i controlli specifici degli agenti utilizzando le linee guida Agentic Trust.

Questo pilastro si collega profondamente ad altre preoccupazioni del quadro.

• L'affidabilità dipende dall'infrastruttura che resiste agli attacchi e recupera dalle violazioni.
• L'eccellenza operativa richiede opportunità di distribuzione sicure e capacità di risposta agli incidenti.
• L'equità richiede la gestione trasparente ed etica dei dati e delle decisioni algoritmiche.

Insieme, questi pilastri costituiscono un approccio unificato e incentrato sulle soluzioni di cui le organizzazioni possono fare Trust per le loro operazioni più delicate.

Nel modello di responsabilità condivisa, Salesforce e gli architetti devono adempiere alle rispettive responsabilità per mantenere il Trust. Vediamo più nel dettaglio che cosa deve garantire ogni parte.

Salesforce è responsabile della protezione della piattaforma e della relativa infrastruttura globale, tra cui:

• Controlli dell'accesso ai data center, sorveglianza e tutele ambientali
• Per Hyperforce, il provider cloud sottostante (ad esempio AWS, Azure o Google Cloud, a seconda dell'istanza) gestisce la sicurezza fisica del data center tramite responsabilità delegata. La documentazione Infrastruttura e sottoprocessori Salesforce identifica il fornitore e i sottoprocessori per ogni servizio.

• Controlli della protezione a livello di rete, tra cui protezione DDoS e rilevamento delle minacce
• Crittografia del traffico in transito (TLS 1.2+) e a riposo (tipicamente AES-256)

• Risposta alle vulnerabilità e distribuzione delle patch piattaforma tramite Salesforce (per ulteriori informazioni sugli avvisi di sicurezza, visitare security.salesforce.com)
• Gestione della sicurezza del sistema operativo e dell'infrastruttura

• Certificazioni e attestazioni: Salesforce gestisce SOC 1/2/3, ISO 27001/27017/27018, l'autorizzazione FedRAMP (limitata a Government Cloud Plus e MuleSoft Government Cloud, non alla piattaforma multi-tenant commerciale) e la convalida PCI DSS di livello 1.
• Supporto normativo: Questo vale per i servizi idonei all'HIPAA con accordi commerciali associati (BAA) o programmi di conformità al GDPR.
• Per ulteriori informazioni, visitare Trust.salesforce.com e compliance.salesforce.com.

• Architettura di isolamento tenant: Un kernel condiviso e basato sui metadati suddivide i dati e i metadati di ogni organizzazione in base all'ID organizzazione, in modo che un'organizzazione non possa raggiungere i record di un'altra anche se entrambi sono in esecuzione su un'infrastruttura condivisa. Il kernel impone la separazione su ogni query, non tramite una configurazione che è necessario mantenere.
• Crittografia a livello di infrastruttura a riposo e infrastruttura di backup: Le licenze piattaforma di base includono Crittografia classica (AES-128 fornisce solo campi di testo personalizzati). Shield Platform Encryption richiede una licenza separata (AES-256 consente di portare la propria chiave e fornisce campi, file e allegati standard e personalizzati).

Questi controlli garantiscono che la piattaforma rimanga sicura, affidabile e conforme.

L'utente è responsabile della protezione dei dati, delle configurazioni e dei processi operativi.

• Identità e federazione: Per Single Sign-On (SSO) e autenticazione a più fattori (MFA), è necessario verificare l'identità dell'utente.
• Limita di accesso: Tecnicamente, gli intervalli IP e gli orari di accesso limitano come e quando le identità si connettono.
• Principio dei privilegi minimi (PoLP): Utilizzare il PoLP per concedere l'accesso solo ai ruoli, ai profili e agli insiemi di autorizzazioni necessari per svolgere le singole mansioni lavorative.
• Gestione del ciclo: di vita Praticare la gestione del ciclo di vita degli utenti e accedere alle linee guida per la ricertificazione.

• Utilizzare la classificazione dei dati, il mascheramento e la protezione a livello di oggetto/campo/record
• Imponi autorizzazioni CRUD e regole di condivisione
• Possedere, testare e distribuire una strategia collaudata per ripristinare i dati dell'organizzazione, assicurando che la perdita di dati o il ripristino della corruzione rimangano sotto il proprio controllo.

• Utilizzare l'autenticazione API (ad esempio, OAuth 2.0 o JWT) e le credenziali denominate.
• Abilitare gli utenti integrazione dedicati con gli insiemi di autorizzazioni PoLP in modo che l'accesso a ogni integrazione sia limitato e controllabile separatamente dagli utenti umani.
• Proteggere gli endpoint e la convalida del sistema esterno.

• Utilizzare Monitoraggio evento, itinerari di controllo e integrazione SIEM (Security Information and Event Management).
• Seguire le procedure di risposta agli incidenti e i controlli di sicurezza.

• Utilizzare codice personalizzato protetto (ad esempio Apex o Lightning) e convalida dell'input.
• Eseguire Apex in modalità utente in modo che le autorizzazioni oggetto, campo e condivisione vengano applicate nel codice.
• Seguire le procedure di prevenzione e sviluppo sicuro delle iniezioni.

• Mantenere il comportamento di conformità delle soluzioni.
• Seguire le policy di gestione della privacy/del consenso e di conservazione dei dati.

Alcune responsabilità richiedono collaborazione:

• Risposta agli incidenti di sicurezza: Entrambe le parti partecipano alle attività di rilevamento e risposta.
• Gestione delle vulnerabilità: Salesforce patcha la piattaforma, gli architetti patchano il codice personalizzato.
• Monitoraggio della sicurezza: Combinare i segnali di sicurezza generati dalla piattaforma con l'analisi dell'architetto.
• Certificazioni di conformità: Salesforce certifica la piattaforma (ad esempio, SOC, ISO e FedRAMP per Government Cloud); gli architetti sono titolari di ciò che è stato creato su di essa (oggetti personalizzati, codice, integrazioni e configurazione) all'interno della posizione certificata per fornire prove di conformità per i controlli.
• Federazione delle identità: Salesforce si fida delle asserzioni rilasciate dal provider di identità dell'architetto; gli architetti mantengono la protezione del provider e la relazione Trust tra il provider e Salesforce.
• Gestione delle chiavi: Utilizzando la crittografia "porta la tua chiave", Salesforce gestisce il servizio di crittografia mentre gli architetti generano, ruotano e revocano il materiale della chiave che protegge i dati.

Ogni principio di progettazione, sezione argomento ed elemento elenco di controllo in questo documento rappresenta la responsabilità dell'utente come architetto. Il modello di responsabilità condivisa definisce gli elementi che è necessario progettare e configurare per ottenere Trust nella piattaforma Salesforce.

Il confine si estende agli obblighi normativi. Salesforce mantiene le certificazioni e gli attestati della piattaforma e protegge l'infrastruttura dalle violazioni. Gli architetti sono responsabili degli obblighi connessi ai dati e alla giurisdizione dell'utente (ad esempio, quali leggi si applicano, come vengono classificati i dati, quali regole di conservazione e consenso li disciplinano e come l'utente rileva e segnala le violazioni dei dati sotto il proprio controllo). In base ai regolamenti in vigore per le distribuzioni, gli architetti devono determinare le cifre specifiche dietro tali obblighi (ad esempio, periodi di conservazione e scadenze di notifica) rispetto al regolamento in vigore per la distribuzione, poiché possono variare in base alla giurisdizione e cambiare nel tempo.

Utilizzare questi principi per guidare le decisioni relative all'architettura per la sicurezza sulla piattaforma.

• Applicare zero Trust in tutti i livelli. Non assumere mai Trust in base alla posizione di rete, alla familiarità degli utenti o all'origine del sistema. Verificare esplicitamente ogni richiesta di accesso con autenticazione, autorizzazione e crittografia a livello di dati, applicazione, integrazione e infrastruttura. L'architettura multi-tenant consente di condividere l'infrastruttura con migliaia di organizzazioni, quindi la rete su cui viene eseguita la soluzione non è un perimetro che può essere considerato affidabile. Verificare ogni richiesta in base ai propri meriti (identità, autorizzazione e contesto) anziché considerarla affidabile per la posizione in cui è stata originata.
• Concedere i privilegi minimi per impostazione predefinita. Concedere il livello minimo di accesso necessario a ogni utente, integrazione e processo automatico per raggiungere lo scopo. Iniziare con le impostazioni più restrittive (predefinizioni private dell'organizzazione) e autorizzazioni minime) ed espandere deliberatamente in base ai requisiti aziendali documentati. Utilizzare il modello di accesso a quattro livelli (organizzazione → oggetto → campo → record) in modo che ogni livello limiti ulteriormente i livelli superiori.
• Implementare la difesa in profondità. Livellare più controlli di sicurezza in modo che l'errore di un controllo non comprometta l'intero sistema. Combinare controlli preventivi (ad esempio, l'imposizione CRUD/FLS e le policy sulla sicurezza delle transazioni che bloccano le operazioni), controlli detective (ad esempio, Monitoraggio evento) e controlli reattivi (ad esempio, autenticazione e notifica step-up per la sicurezza delle transazioni). Progettare ogni livello come se i livelli adiacenti potessero fallire. Ricordare che la protezione a livello di campo protegge i dati anche quando le regole di condivisione sono troppo permissive.
• Integrare la sicurezza fin dalla progettazione. Integrare la modellazione delle minacce, i requisiti di sicurezza e controllare la convalida in ogni fase dell'architettura, dal concetto iniziale all'evoluzione in corso. Eseguire la modellazione delle minacce Spoofing, Manomissione, Ripudio, Divulgazione delle informazioni, Denial of Service ed Elevation of Privilege (STRIDE) prima di iniziare la creazione. La sicurezza determina la selezione della tecnologia e le decisioni di progettazione.
• Incorporare la sicurezza nell'automazione. Incorporare i controlli di sicurezza nelle pipeline automatiche, nei modelli di configurazione e nelle impostazioni predefinite della piattaforma. Salesforce Code Analyzer in CI/CD rileva le vulnerabilità prima della distribuzione. Configuration-as-code impone le basi di riferimento per la sicurezza. La protezione incorporata garantisce la coerenza e consente la scalabilità della protezione in base alla complessità della soluzione.
• Progettare per la privacy. Incorporare i principi di privacy fin dalla fase iniziale dell'architettura. Progettare per la riduzione al minimo dei dati (raccogliere solo i dati necessari), la limitazione dello scopo (limitare l'accesso in base alla funzione lavorativa), la gestione del consenso (applicare un consenso granulare e specifico per lo scopo) e i diritti degli interessati (consentire il completamento dei flussi di lavoro di accesso, rettifica, cancellazione e portabilità entro le tempistiche normative).
• Progettazione per la tracciabilità. Rendere ogni azione consequenziale attribuibile e ricostruibile a posteriori, prima di affidarsi al rilevamento di anomalie al suo interno. Assicurarsi che le modifiche ai dati, alle autorizzazioni e alla configurazione vengano acquisite negli itinerari di controllo, nella cronologia dei campi e nei registri eventi e conservare tali record in archivi a prova di manomissione. La tracciabilità è la precondizione per il rilevamento, l'analisi forense e la responsabilità. Ricorda: non è possibile indagare su ciò che non è mai stato registrato.
• Progettazione per la risposta agli incidenti. Progettare per la rilevabilità tramite Monitoraggio evento e per l'intervento in tempo reale tramite le policy sulla sicurezza delle transazioni. Abilitare la risposta rapida tramite procedure documentate e confini di isolamento. Supportare il ripristino tramite funzionalità di backup e conservazione forense. Testare le risposte tramite esercizi da tavolo e simulazioni di violazioni.

Gli architetti sono responsabili della protezione delle soluzioni sulla piattaforma fornita da Salesforce.

I carichi di lavoro che interagiscono con Salesforce vengono eseguiti sempre più spesso al di fuori della piattaforma centrale: servizi di integrazione, applicazioni personalizzate e client headless chiamano spesso le API Salesforce, spesso per conto di un utente. Per accelerare questo schema, Salesforce espone le funzionalità della piattaforma come API, strumenti e comandi (ad esempio, Salesforce Headless 360). Indipendentemente da chi gestisce queste applicazioni, l'architetto è titolare del confine Trust in cui incontra Salesforce per determinare come eseguire l'autenticazione, quale identità e autorizzazioni portare con sé, quali segreti detengono e quali dati superano il confine.

I principi seguenti si applicano a qualsiasi piattaforma di integrazione containerizzata (ad esempio, MuleSoft CloudHub).

Quando un client esterno esegue l'autenticazione come utente denominato, il modello di sicurezza della piattaforma di Salesforce viene applicato automaticamente: le autorizzazioni per gli oggetti, la protezione a livello di campo e le regole di condivisione vengono applicate esattamente come nel browser. L'autenticazione per utente circoscrive ogni chiamata alle autorizzazioni di quella persona e mantiene l'itinerario di controllo, il che significa che la revoca del token di un utente rimuove immediatamente la capacità del client di agire per suo conto. È preferibile a un account di servizio condiviso ovunque il lavoro venga eseguito per un utente specifico.

Progettare il confine in modo difensivo, perché un client che contiene token per molti utenti concentra Trust e diventa un proxy di alto valore per un aggressore: un singolo token OAuth rubato può raggiungere i dati di ogni utente servito dal client. Questo non è ipotetico. L'incidente di Salesloft Drift del 2025 ha visto gli aggressori rubare token OAuth e utilizzarli per raggiungere i dati Salesforce in centinaia di organizzazioni.

• Propagare l'identità degli utenti, non metterla in pool. Utilizzare l'autenticazione per utente o lo scambio di token OAuth 2.0 per trasferire l'identità di un utente tra i vari hop di servizio (vedere Identità e autenticazione agenti), in modo che i compromessi siano limitati al contesto di un utente anziché a tutti.
• Trattare le credenziali client OAuth e i token di aggiornamento come destinazione principale. Archiviarli in un archivio di segreti gestiti, ruotarli spesso e gestire i progetti per la revoca immediata. Monitorare l'utilizzo dell'API per individuare gli schemi anomali che segnalano un aggressore proxy.
• Ridurre al minimo l'ambito su entrambi i lati. Limitare gli ambiti OAuth dell'app client esterna (ECA) e le autorizzazioni Salesforce dell'utente integrazione al minimo richiesto dalla funzione, in modo che un client compromesso non possa eseguire il pivot su dati non correlati.
• Governare il confine tramite le app client esterne. Le ECA definiscono le modalità di autenticazione di un'applicazione esterna, i flussi consentiti e gli ambiti applicabili, progettando nuove integrazioni (vedere Architettura di autenticazione).

Prestare attenzione quando un client viene eseguito come Utente agente o Utente integrazione: queste identità possono operare in un contesto elevato, spesso contro sistemi esterni che non rispettano i controlli di accesso di Salesforce, quindi l'utilizzo della disciplina di autorizzazione e monitoraggio descritta sopra è ciò che mantiene tale potere limitato.

Quando le integrazioni vengono eseguite in una piattaforma containerizzata, l'isolamento a livello di contenitore è di per sé considerato un controllo di sicurezza: ogni applicazione viene eseguita in un contenitore dedicato senza runtime o memoria condivisa tra le applicazioni.

Questo isolamento fornisce:

• Applicazione dei confini tenant: Le applicazioni compromesse non possono accedere ai dati o alle risorse delle applicazioni vicine che condividono lo stesso ambiente. Ogni contenitore ha un filesystem e uno spazio di processo isolati. Applicare l'isolamento della rete tramite firewall e configurazione TLS e limitare esplicitamente il traffico in uscita anziché affidarsi a impostazioni predefinite permissive.
• Difesa approfondita: L'isolamento del contenitore aggiunge un livello di sicurezza che va oltre i controlli a livello di applicazione. Anche se il codice dell'applicazione presenta vulnerabilità, i confini del contenitore limitano il raggio di esplosione.
• Segmentazione della conformità: I carichi di lavoro regolamentati (ad esempio, PCI e HIPAA) possono essere isolati in contenitori dedicati, evitando la combinazione con carichi di lavoro non conformi.

Gli architetti che progettano ambienti multiapplicazione devono affidarsi all'isolamento dei contenitori per imporre la separazione dei compiti e dei domini di sicurezza. Le integrazioni di servizi finanziari che gestiscono i dati dei titolari di carte devono essere eseguite in contenitori separati dalle integrazioni di marketing, anche all'interno dello stesso ambiente.

Il traffico tra container dovrebbe essere crittografato e il TLS reciproco (mTLS) dovrebbe essere applicato quando un quadro normativo richiede l'autenticazione da entrambe le parti:

Come funziona:

• Configurare i contesti TLS per abilitare TLS reciproco facoltativo (mTLS) per le connessioni in entrata quando necessario.
• Utilizzare SSL a livello di piattaforma con l'autenticazione client-certificato per proteggere la comunicazione tra servizi e repliche della piattaforma.
• Configurare i contesti TLS per abilitare mTLS quando richiesto dai quadri normativi.
• Gestire i certificati tramite l'archivio certificati della piattaforma in modo che il ciclo di vita e la revoca rimangano centralizzati.
• Applicare i confini di isolamento della rete che impediscono il traffico non autorizzato tra i contenitori.

La crittografia del traffico a livello di piattaforma offre una protezione approfondita per i dati in transito. Anche se l'HTTPS a livello di applicazione non è configurato correttamente, il traffico contenitore rimane crittografato.

I contenitori che si collegano a sistemi locali tramite VPN devono essere progettati per la protezione dei dati in transito:

• Crittografia tunnel: Instradare tutto il traffico tra container e sistemi locali attraverso tunnel VPN crittografati. Questo vale indipendentemente dal TLS a livello di applicazione. Difesa in profondità garantisce una doppia crittografia per i dati sensibili.
• Imposizione della segmentazione della rete: Le policy sui tunnel VPN limitano i contenitori delle reti locali che possono raggiungere. I contenitori compromessi non possono eseguire il pivot a sistemi interni non autorizzati oltre le reti consentite dalla VPN.
• Prove di conformità: La crittografia VPN è uno dei meccanismi accettati per proteggere i dati in transito da e verso gli ambienti cloud. Gli auditor che rivedono i controlli HIPAA, PCI-DSS o SOX si aspettano la crittografia documentata in transito per le integrazioni ibride.

Gli architetti devono progettare policy VPN che impongano l'accesso alla rete con privilegi minimi. I contenitori di integrazione marketing non devono essere instradati ai sistemi finanziari interni anche se entrambi sono raggiungibili tramite VPN.

I vanity domain (ad esempio, gli URL personalizzati per le API di integrazione) richiedono che gli architetti gestiscano i certificati TLS come trust anchor:

I vanity domain (ad esempio, gli URL personalizzati per le API di integrazione) richiedono che gli architetti gestiscano i certificati TLS come trust anchor.

• Automazione del ciclo di vita del certificato: Implementare il rinnovo e la distribuzione automatici dei certificati. I certificati scaduti rompono l'integration Trust; i client rifiutano le connessioni con errori di convalida dei certificati.
• Pianificazione della revoca del certificato: Progettare procedure di rotazione dei certificati per gli incidenti di sicurezza. Le chiavi private compromesse richiedono un rilascio e una distribuzione rapidi dei certificati in tutte le regioni.
• Configurazione della suite Cipher: Le configurazioni TLS più datate (TLS 1.0/1.1 e cifrari deboli) non superano i controlli di conformità. Applicare TLS 1.2+ (requisito minimo) e allineare le configurazioni di certificati e client alle policy di sicurezza dell'organizzazione.
• Registrazione trasparenza certificato: I certificati TLS moderni vengono inviati ai registri pubblici di trasparenza dei certificati dalle autorità di certificazione (CA). Ogni registro CT restituisce un Signed Certificate Timestamp (SCT), una prova crittografica della registrazione, che la CA incorpora nel certificato tramite un'estensione X.509v3. Gli architetti devono monitorare i registri CT per rilevare l'emissione non autorizzata di certificati nei loro domini, utilizzando servizi come crt.sh o avvisi automatici.

La cattiva gestione dei certificati influisce direttamente sul comportamento Trust:

• Certificati scaduti: Causare errori di autenticazione che vengono visualizzati come interruzioni. Il monitoraggio deve includere l'invio di avvisi entro 30 giorni prima della scadenza per consentire l'avvio dei flussi di lavoro di rinnovo.
• Certificati autofirmati: Rompere le catene Trust per i clienti esterni. Le integrazioni di produzione richiedono certificati firmati da autorità di certificazione (CA) affidabili.
• Diffusione dei certificati con caratteri jolly: Si riferisce a certificati con caratteri jolly troppo ampi (ad esempio, *.company.com) che creano un raggio di esplosione elevato se vengono compromessi. I certificati con ambito ristretto sono preferiti per dominio di integrazione.

Le regioni di distribuzione dei container devono rispettare i requisiti di residenza dei dati e conformità.

• Residenza dati GDPR: Il GDPR richiede una protezione adeguata per i dati personali che lasciano l'Unione Europea (UE), ma non la distribuzione nell'UE in quanto tale. La distribuzione delle integrazioni in un'area dell'UE consente di mantenere l'elaborazione dei container e dei dati entro i confini normativi, il modo più diretto per soddisfare questo requisito. I trasferimenti che si verificano al di fuori dell'UE rimangono consentiti in base a una decisione di adeguatezza, alle clausole contrattuali standard o alle regole aziendali vincolanti.
• Leggi sulla localizzazione dei dati: I paesi con requisiti di localizzazione dei dati includono: Russia (legge federale 152-FZ e stoccaggio obbligatorio) e Cina (PIPL/CSL per i CIIO), che potrebbero richiedere la distribuzione di container nel paese. L'India's DPDP Act of 2023 utilizza un approccio da lista nera che non impone un mandato generale di stoccaggio nel paese. I trasferimenti di dati sono consentiti a qualsiasi paese a meno che non siano specificamente limitati da una notifica governativa. Gli architetti devono comprendere i regolamenti specifici della giurisdizione.
• Meccanismi di trasferimento transfrontaliero dei dati: Quando è necessaria una distribuzione multiregionale ma i dati devono superare i confini, gli architetti devono implementare SCC, BCR o altri meccanismi di trasferimento legali.
• Allineamento della certificazione di conformità: Le regioni di distribuzione dei contenitori devono corrispondere alle certificazioni di conformità Salesforce. I carichi di lavoro autorizzati da FedRAMP richiedono la distribuzione regionale negli Stati Uniti. Per le integrazioni certificate HITRUST, è necessario verificare che la regione di distribuzione rientri in un ambito di attestazione HITRUST attivo.

Le decisioni di distribuzione regionale sono responsabilità dell'architetto che influiscono direttamente sulla conformità normativa. I team finanziari possono imporre la distribuzione solo negli Stati Uniti per le integrazioni controllate da SOX. I team sanitari possono richiedere regioni certificate HITRUST per l'elaborazione delle informazioni sanitarie personali (PHI).

I contenitori richiedono l'accesso a credenziali, chiavi API e chiavi di crittografia. Gli architetti devono progettare processi di gestione dei segreti che impediscano l'esposizione:

• Nessun segreto codificato: Non incorporare mai le credenziali nel codice dell'applicazione o nei file di configurazione distribuiti nei contenitori. Utilizzare i punti vendita di segreti gestiti dalla piattaforma.
• Iniezione segreta gestita dalla piattaforma: Risolvere i segreti in fase di esecuzione dall'archivio gestito della piattaforma (anziché mantenerli nel filesystem) e contrassegnare i valori di configurazione che contengono credenziali come protetti in modo che non vengano visualizzati nei registri o nella console.
• Rotazione dei segreti: Progettare integrazioni per gestire i segreti ruotati con grazia. Gli schemi di aggiornamento dei token OAuth, i flussi di lavoro di rotazione delle chiavi API e le modifiche delle password del database non devono richiedere la ridistribuzione del contenitore.
• Accesso ai segreti con privilegi minimi: Concedere ai contenitori l'accesso solo ai segreti necessari per la loro funzione. Le integrazioni marketing non devono accedere alle credenziali del sistema finanziario anche quando condividono lo stesso ambiente.

I segreti esposti sono incidenti comuni di sicurezza dell'integrazione. Gli architetti devono progettare processi di gestione dei segreti che possano sopravvivere a revisioni del codice, registri, messaggi di errore e cruscotti digitali di monitoraggio senza perdite di credenziali.

Le applicazioni al confine di Salesforce generano eventi di controllo che soddisfano i requisiti di registrazione della conformità:

• Registro richieste/risposte: Registra le richieste API, le risposte e le decisioni di instradamento. I team di conformità utilizzano questi registri per i controlli dell'accesso per determinare chi ha eseguito l'accesso ai dati e in quale momento.
• Registrazione di errori ed eccezioni: Acquisisce gli eventi di sicurezza (ad esempio errori di autenticazione, rifiuti di autorizzazione e certificati non validi) nei registri del contenitore. L'integrazione SIEM consente il monitoraggio della sicurezza in tempo reale.
• Criteri di conservazione dei registri: Gli architetti devono configurare periodi di conservazione che soddisfino i requisiti normativi. Questi minimi sono stabiliti per regolamento, differiscono a seconda del framework e cambiano nel tempo, quindi devono derivarli da una fonte di conformità ben gestita che verifica ogni cifra rispetto al regolamento vigente anziché dai valori di codifica.
• Crittografia dei registri e controlli di accesso: I registri di controllo possono contenere metadati sensibili. I registri devono essere crittografati a riposo e controllati dall'accesso solo al personale di sicurezza/conformità autorizzato. Una registrazione insufficiente impedisce le indagini sugli incidenti e non supera i controlli di conformità. Gli architetti devono bilanciare la verbosità della registrazione (ad esempio, l'impatto sulle prestazioni e i costi di archiviazione) con le esigenze di verifica della conformità e della sicurezza.

La modellazione delle minacce deve far parte della progettazione delle soluzioni, anziché essere una fase separata che si verifica prima o dopo di essa. Non appena si ha un progetto candidato su cui ragionare, è necessario modellarne le potenziali minacce e rivedere il modello man mano che il progetto si evolve, in modo che la sicurezza dia forma all'architettura anziché essere adattata a posteriori. Mentre Salesforce gestisce la sicurezza dell'infrastruttura (ad esempio, protezione della rete, hardening del sistema operativo e gestione delle vulnerabilità), è necessario identificare i rischi a livello di applicazione nella configurazione, nelle integrazioni e nel codice personalizzato. Applicare il framework STRIDE (spoofing, manomissione, ripudio, divulgazione delle informazioni, negazione del servizio, elevazione dei privilegi) ai vettori di minacce specifici di Salesforce elencati di seguito. Identificare i confini Trust dove i dati attraversano sistemi, reti o livelli di privilegi.

Applicare il framework STRIDE alle seguenti considerazioni sulla modellazione delle minacce specifiche di Salesforce:

• I flussi di dati creano ulteriori confini Trust che richiedono autenticazione e autorizzazione esplicite a ogni attraversamento.
• Le integrazioni esterne utilizzano API e middleware, potenzialmente introducendo vettori di attacco che ignorano i controlli di sicurezza della piattaforma.
• I componenti Apex e Lightning richiedono un'analisi del codice sicura per l'iniezione, XSS e l'imposizione del controllo degli accessi.
• I siti Experience Cloud espandono la superficie di attacco agli utenti non autenticati o leggermente autenticati.
• Il codice ISV e di terze parti (ad esempio pacchetti gestiti, elenchi AgentExchange, applicazioni connesse, connettori di terze parti, librerie JavaScript lato client e servizi di intelligenza artificiale esterni chiamati dagli agenti) è un vettore della supply chain che attraversa il confine Trust, in fase di installazione o di esecuzione.

Il codice ISV e di terze parti fa parte del tuo Trust.

I pacchetti gestiti o gli elenchi AgentExchange vengono eseguiti all'interno dell'organizzazione con le autorizzazioni concesse, quindi il loro comportamento di sicurezza diventa il comportamento di sicurezza dell'utente nel momento in cui viene installato. Revisione della sicurezza Salesforce controlla ogni pacchetto elencato prima che raggiunga AppExchange o AgentExchange; si è titolari di tutto dopo quel cancello:

• Valutare il pacchetto in base alla propria classificazione dei dati e al proprio comportamento a rischio
• Concedendogli il minor numero di privilegi che la sua funzionalità documentata richiede
• Mantenerlo aggiornato con i rilasci del publisher
• e monitorarne l'attività tramite gli stessi controlli di Monitoraggio evento e controllo applicati al proprio codice.

Applicare controlli di sicurezza a ogni livello dello stack di soluzioni. Tenere presente che la compromissione di un livello non deve esporre l'intero sistema.

Progettare ogni livello come se i livelli sopra e sotto potessero fallire. Ricordare che più controlli indipendenti creano resilienza.

Zero Trust elimina il Trust implicito basato sulla posizione di rete o sullo stato di autenticazione precedente. Ogni richiesta deve essere autenticata e autorizzata in modo indipendente.

Applicare zero Trust a:

• Accesso utente tramite verifica continua con MFA, policy di sessione e accesso condizionale in base al contesto (ad esempio, IP, dispositivo, ora e comportamento)
• Connessioni di integrazione tramite convalida del token OAuth su ogni chiamata, TLS reciproco basato su certificato ed elenco IP consentiti
• Comunicazione tra sistemi tramite autenticazione esplicita, che si applica anche ai sistemi interni affidabili
• Accesso ai dati tramite l'imposizione CRUD e FLS su ogni query e operazione indipendentemente dal contesto della chiamata

Inventario asset di sicurezza è un input per la progettazione della sicurezza: è possibile solo modellare le minacce, applicare i privilegi minimi e monitorare una superficie di attacco che è stata enumerata per prima, quindi il tracciamento degli asset rilevanti per la sicurezza appartiene alle decisioni di progettazione che dipendono da esso. Questo è distinto dalla gestione della configurazione operativa coperta da Eccellenza operativa (ad esempio, il controllo delle impostazioni dell'organizzazione e il rilevamento della fluttuazione della configurazione per la stabilità operativa). In altre parole, la preoccupazione qui è più stretta: quali asset comportano rischi per la sicurezza e perché?

Gestire un inventario aggiornato di tutti gli asset rilevanti per la sicurezza, inclusi gli oggetti personalizzati che archiviano dati sensibili, le integrazioni di sistemi esterni, le API rivolte al pubblico, gli account con privilegi, le sovvenzioni per l'accesso in produzione e i pacchetti installati con autorizzazioni elevate.

L'inventario degli asset di sicurezza deve includere:

• Oggetti personalizzati e campi contenenti dati riservati o limitati
• Endpoint di integrazione e meccanismi di autenticazione
• Utenti con privilegi elevati (ad esempio, Modifica tutti i dati, Visualizza tutti i dati e Gestisci utenti)
• Utenti integrazione solo API e relativi ambiti di autorizzazione
• External Client Apps (ECA) e i relativi ambiti OAuth, insieme alle applicazioni connesse legacy ancora presenti nell'organizzazione
• Pacchetti AgentExchange installati e relative autorizzazioni concesse
• Siti Experience Cloud e relativi modelli di autenticazione e condivisione esterna
• Classi Apex personalizzate con modalità di condivisione elevate
• Prestare particolare attenzione alle classi legacy: il codice compilato all'API versione 66.0 o precedente, che omette una dichiarazione di condivisione, viene impostato automaticamente su "senza condivisione" (ad esempio, modalità di sistema, ignorando l'accesso ai record dell'utente in esecuzione). Tenere presente che dall'API versione 67.0 (Summer '26), una dichiarazione omessa viene invece impostata automaticamente su "con condivisione" e le operazioni di database vengono eseguite in modalità utente. Tuttavia, le classi esistenti mantengono il vecchio comportamento fino a quando non vengono ricompilate alla versione 67.0 (o successiva), in modo che le classi non dichiarate riportate dalle versioni precedenti rimangano silenziosamente elevate.

È responsabilità dell'utente progettare e configurare controlli dell'identità che impongano privilegi minimi.

Vediamo in dettaglio come progettare e configurare correttamente i controlli utilizzando PoLP.

Salesforce impone il controllo dell'accesso attraverso quattro livelli distinti: organizzazione, oggetto, campo e record. È necessario progettare soluzioni che sfruttano deliberatamente tutti e quattro i livelli. Il controllo dell'accesso di base è basato su sovvenzioni, il che significa che l'accesso è additivo e che gli utenti devono averlo concesso a ogni livello per raggiungere un record. Poiché non esiste una regola generalizzata "nega le esclusioni consentite" nella piattaforma principale, non è possibile bloccare un rifiuto mirato per annullare l'accesso a un'ampia sovvenzione già conferita.

I livelli più alti permissivi non costano la possibilità di limitare, ma aumentano l'impegno: ampliare precocemente le impostazioni predefinite dell'organizzazione o le autorizzazioni oggetto significa affidarsi alla protezione a livello di campo e alla configurazione di condivisione per recuperare l'accesso che non avrebbe mai dovuto essere concesso.

Le regole di restrizione e la disattivazione delle autorizzazioni sono due eccezioni predefinite che sottraggono l'accesso, ma ciascuna di esse ha un ambito ristretto (regole di restrizione ai filtri a livello di record e disattivazione delle autorizzazioni concesse all'interno di un gruppo di insiemi di autorizzazioni) e non un livello di rifiuto generalizzato.

Impostare OWD su Privato per gli oggetti contenenti dati sensibili. L'apertura degli OWD in Sola lettura pubblica, nonché in Lettura/Scrittura pubblica, espone i record in modo ampio ed erode la possibilità di limitare l'accesso in un secondo momento senza una riarchitettura potenzialmente significativa. Il debito Trust più comune nelle organizzazioni mature deriva da OWD permissivi impostati durante l'implementazione iniziale.

Il livello record segue un modello grant-then-restrict, spesso rappresentato come una piramide di condivisione: Gli OWD impostano la base di riferimento restrittiva e la gerarchia dei ruoli, le regole di condivisione e l'accesso aperto in condivisione manuale verso l'alto da qui. Due controlli invertono il flusso per rimuovere l'accesso anziché concederlo, ed è opportuno progettare entrambi deliberatamente.

• Le regole di restrizione filtrano ciò che gli utenti possono vedere all'interno dei record a cui hanno già accesso, in modo che gli utenti con ampio accesso agli oggetti vedano comunque solo il sottoinsieme consentito da una regola.
• La disattivazione delle autorizzazioni sottrae autorizzazioni specifiche all'interno di un gruppo di insiemi di autorizzazioni, in modo da poter assemblare l'accesso da gruppi riutilizzabili e quindi rimuovere ciò che una determinata popolazione non dovrebbe avere.
• Raggiungere queste regole quando i livelli basati su sovvenzioni da soli costringerebbero a un provisioning eccessivo o a frammentare l'accesso in molti insiemi di autorizzazioni ristretti.

Applicare la MFA (autenticazione a più fattori) per tutti gli utenti che accedono agli ambienti di produzione tramite l'interfaccia utente, che Salesforce impone come requisito della piattaforma. Questo requisito non si estende all'accesso solo API: le integrazioni che utilizzano flussi JWT-bearer o client-credentials sono esenti, quindi è necessario proteggere tali integrazioni con la gestione dei certificati e le restrizioni IP. Estendere i requisiti della MFA alle operazioni con privilegi.

Per SSO (Single Sign-On), sono preferiti i protocolli SAML 2.0 o OpenID Connect. Configurare le policy di sessione per bilanciare sicurezza e fruibilità:

• Timeout sessione: Configurare i timeout delle sessioni in base ai livelli di privilegi utente (timeout più brevi per gli account con privilegi elevati riducono i rischi delle sessioni incustodite).
• Restrizioni IP: Applicare restrizioni per i profili amministrativi e gli utenti integrazione.
• Orari di accesso: Limitare gli account di servizio alle finestre operative previste.
• Attivazione del dispositivo: Basarsi sull'attivazione nativa del dispositivo Salesforce (verifica dell'identità per gli accessi da dispositivi non riconosciuti) e aggiungere restrizioni MFA e IP per gli account con privilegi elevati. La posizione nativa del device Trust viene imposta tramite un provider di identità esterno.
• Bloccaggio IP sessione: Bloccare le sessioni all'indirizzo IP da cui hanno avuto origine, in modo che un ID sessione rubato non possa essere riprodotto da un'altra posizione di rete. Questo rafforza la sicurezza, ma aumenta la frizione per gli utenti mobili e può interrompere le integrazioni automatiche, dove il blocco non è possibile, applicare intervalli IP di accesso rigorosi a livello di profilo con "Applica intervalli IP di accesso su ogni richiesta" come controllo compensativo.
• Sessioni High Assurance: Richiedere un livello di sicurezza sessione High Assurance, tramite Policy livello di sicurezza sessione e Policy di accesso, per le operazioni sensibili (ad esempio l'accesso ai rapporti o la gestione degli intervalli IP), in modo che un accesso di routine non possa da solo raggiungere azioni di grande impatto. In Lightning Experience, il passaggio di una sessione standard a High Assurance richiedendo nuovamente la MFA non è supportato, quindi applicare questa policy per sapere che gli utenti delle sessioni standard sono bloccati dall'operazione di gate anziché essere invitati a elevazione.
• Protezione dei cookie di sessione: Richiedere l'attributo HttpOnly in modo che gli script non possano leggere il cookie dell'ID sessione e bloccare le sessioni nel dominio in cui sono state utilizzate per la prima volta, per ridurre gli attacchi hijack della sessione.
• Accesso solo API per gli utenti integrazione: Limitare l'integrazione e gli account di servizio all'autenticazione solo API con l'autorizzazione Utente solo API, in modo che non possano accedere tramite l'interfaccia utente. Per le nuove build, assegnare il profilo Accesso minimo - Integrazioni solo API con la licenza utente Integrazione Salesforce; il profilo Integrazione sistemi solo API Salesforce più datato non è disponibile nelle organizzazioni di cui è stato eseguito il provisioning a partire dal rilascio Spring '24, quindi progettare nuove integrazioni in base al profilo corrente anziché a quello deprecato.

Per l'autenticazione API, selezionare i flussi OAuth 2.0 appropriati allo schema di integrazione:

• Flusso bearer JWT: Utilizzare questa opzione per le integrazioni da server a server eseguite come utente integrazione (basato su certificato, preferito per gli ambienti affidabili).
• Flusso server Web (codice di autorizzazione, con PKCE): Utilizzare questa opzione per le applicazioni Web che richiedono l'autorizzazione dell'utente e per le integrazioni da server a server che devono mantenere un contesto utente specifico (memorizzazione dei token di aggiornamento sul lato server per evitare di ripetere i prompt del browser).
• Rendi sicuro il flusso Codice di autorizzazione: Applicare PKCE in modo che un codice di autorizzazione intercettato non possa essere riscattato da nessuno tranne dal client che lo ha richiesto e ruotare i token di aggiornamento (emettendone uno nuovo a ogni utilizzo e invalidando quello precedente) in modo che un token di aggiornamento rubato abbia una finestra di validità ridotta. Il riutilizzo di un token ritirato segnala una compromissione.
• Flusso Codice di autorizzazione e credenziali identità headless (con PKCE): Utilizzare questa opzione per client headless senza browser che devono essere eseguiti nel contesto di un utente specifico: il flusso del server Web basato sul reindirizzamento presuppone un browser che questi client non hanno.
• Flusso dispositivo (per dispositivi headless): Tenere presente che a partire dal 28 agosto 2025 Salesforce ha bloccato in modo permanente il flusso dispositivo OAuth 2.0 per l'applicazione connessa Salesforce CLI predefinita. Utilizzare il flusso server Web (sf org login web) o il flusso bearer JWT (sf org login jwt) per il tooling di CLI e CI/CD.

Non utilizzare il flusso Nome utente-Password. Salesforce lo ha bloccato per impostazione predefinita per le organizzazioni create nel rilascio Summer '23 o successivi e ha pubblicato piani di ritiro per questo flusso. Le integrazioni esistenti che si basano ancora sul flusso Username-Password dovrebbero migrare ora al flusso bearer JWT o al flusso credenziali client anziché trattare la migrazione come debito tecnico differito.

Questi flussi vengono configurati nella registrazione dell'app che rappresenta l'integrazione. A partire dal rilascio Spring '26, Salesforce sta spostando la registrazione dalle applicazioni connesse alle applicazioni client esterne (ECA): la creazione di nuove applicazioni connesse è disabilitata per impostazione predefinita e la funzione ECA è il costrutto in base al quale progettare nuove integrazioni. Le applicazioni connesse esistenti rimangono installate; tuttavia, una volta eseguita la migrazione di un'organizzazione, non gestiscono più l'autenticazione, quindi tenere presente la migrazione quando si controlla come vengono eseguite le integrazioni anziché considerare le applicazioni connesse come il modello permanente.

Oltre a scegliere un flusso di autenticazione, creare una governance distinta per cui le app possono connettersi:

• Una registrazione per integrazione: Registrare un'applicazione client esterna dedicata per ogni nuova integrazione e un'applicazione connessa distinta per ogni integrazione esistente. Limitata solo agli ambiti OAuth richiesti da ogni integrazione anziché condividere una registrazione generale in molte, una registrazione dedicata mantiene l'accesso di ogni integrazione controllabile e revocabile in modo indipendente.
• Accesso pre-autorizzato esplicitamente (consigliato): Impostare la policy Utenti con autorizzazioni dell'app client esterna su "Gli utenti approvati dall'amministratore sono pre-autorizzati", in modo che un amministratore conceda l'accesso tramite profili e insiemi di autorizzazioni anziché consentire agli utenti di autorizzarsi autonomamente. Gli amministratori lo configurano direttamente in Imposta ed è il controllo consigliato da Salesforce per determinare chi può connettersi.
• Controllo dell'accesso API (più rigoroso, basato su elenchi consentiti): Per controlli più rigorosi, Controllo accesso API limita gli utenti approvati dall'amministratore solo alle applicazioni connesse nell'elenco consentiti. L'abilitazione richiede una richiesta all'Assistenza clienti Salesforce, quindi pianificare questa fase quando si progetta intorno a essa anziché trattarla come un'impostazione self-service.

Non incorporare mai le credenziali nel codice, nei file di configurazione o nel controllo di versione. Utilizzare le credenziali denominate e le credenziali esterne per gestire l'autenticazione a livello centrale con funzionalità di rotazione.

A differenza dell'autenticazione utente tradizionale, gli agenti richiedono modelli di identità distinti e il modello giusto dipende dal fatto che l'agente serva i dipendenti o gli utenti esterni. Progettare correttamente l'identità è alla base della sicurezza degli agenti: determina a quali dati l'agente può accedere e le azioni che può raggiungere.

Vediamo più in dettaglio gli agenti interni ed esterni.

• Agenti dipendenti (interni): Eseguono operazioni nel contesto dell'utente che ha eseguito l'accesso. Ereditano le licenze, gli insiemi di autorizzazioni, la protezione a livello di campo e le regole di condivisione dell'utente, quindi non viene fornita un'identità agente separata e il framework di sicurezza esistente regola le operazioni che l'agente può eseguire.
• Agenti clienti (esterni): Interagire attraverso i canali pubblici ed eseguire come utenti agenti dedicati, utenti integrazione specializzati, non utenti guest di siti pubblici. L'esecuzione come utenti integrazione dedicati consente all'agente di eseguire azioni di backend e di raggiungere i dati (cosa che i profili guest non autenticati non possono fare), pur essendo vincolato da autorizzazioni esplicite con privilegi minimi. Quando si crea un agente cliente, eseguire il provisioning di un nuovo utente agente con un accesso minimo e concedere solo le autorizzazioni specifiche richieste dalle sue azioni.

Quando il lavoro di un agente si estende a più servizi, propagare l'identità dell'utente in ogni salto di servizio anziché tornare a un'identità condivisa o guest. Il flusso Salesforce OAuth 2.0 Token Exchange supporta quanto segue:

Un client presenta il token del provider di identità esistente dell'utente e un handler exchange token Apex lo mappa a un utente Salesforce ed emette un token di accesso Salesforce, in modo che il contesto dell'utente originale segua la richiesta anziché comprimersi in un account di servizio. Monitorare l'attività degli agenti tramite Monitoraggio evento, utilizzando l'identità utente dell'agente per rilevare comportamenti anomali.

La scelta del modello giusto dipende da chi avvia la connessione e dal contesto in cui deve essere eseguito il lavoro.

Gli scenari di connessione comuni vengono mappati agli approcci consigliati come segue:

Progettare le gerarchie dei ruoli in base alle esigenze di accesso ai dati (a cui gli utenti devono poter accedere per i record di cui sono titolari altri utenti), non in base al grafico dei rapporti di gestione. Lasciare che la profondità della gerarchia dei ruoli segua relazioni di accesso ai dati genuine anziché aggiungere livelli che non concedono alcun accesso aggiuntivo, poiché ogni livello aggiunge un sovraccarico di calcolo della condivisione, una considerazione che ha più peso nelle organizzazioni con impostazioni OWD private e volumi di dati elevati.

Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni riducono la necessità di proliferazione dei profili offrendo un accesso flessibile e additivo. Concedere l'accesso funzionale tramite gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni anziché i profili, che mantengono l'accesso additivo e controllabile. I profili rimangono necessari: oltre agli orari di accesso e alle restrizioni IP, controllano l'assegnazione dei layout di pagina, le impostazioni predefinite dei tipi di record e la visibilità dell'app. Considerare i profili come una parte durevole del modello di accesso, anziché come un costrutto da eliminare.

Le policy sulla sicurezza delle transazioni non fanno parte della base di riferimento, sono una funzionalità aggiuntiva che integra il modello di autorizzazione di base: l'identità, il ruolo, il profilo, l'insieme di autorizzazioni e i controlli di condivisione di cui sopra stabiliscono già un comportamento di autorizzazione sicuro e la sicurezza delle transazioni aggiunge una valutazione contestuale in tempo reale. Configurare policy per rilevare e bloccare comportamenti anomali, inclusi download di dati in blocco che superano schemi normali, accessi da aree geografiche impreviste e modifiche delle autorizzazioni al di fuori delle finestre di modifica.

I controlli di sicurezza comportano compromessi sulla disponibilità che sono una responsabilità architettonica. Una restrizione IP troppo ampia può bloccare gli utenti legittimi durante una modifica della rete e una policy sulla sicurezza delle transazioni ottimizzata in modo troppo aggressivo può bloccare le attività aziendali valide, quindi limitare questi controlli a un rischio reale, impostarli in modalità solo monitor prima di applicarli e progettare un percorso break-glass per quando un controllo non viene attivato.

La tua responsabilità: Progettare la gerarchia dei ruoli, creare insiemi di autorizzazioni, configurare le policy sulla sicurezza delle transazioni.

Controllo dell'accesso basato sui ruoli tradizionale) concede autorizzazioni basate sul ruolo di un utente. ABAC (attribute-based access control) prende le decisioni di autorizzazione in base agli attributi dei dati, dell'utente e del contesto.

Per la maggior parte dei requisiti, il modello di condivisione core esprime l'accesso completamente. Reach per ABAC dedicato quando l'accesso deve seguire una classificazione dei dati che la condivisione per record non può esprimere: Data 360 ABAC lo fornisce tramite tag e annotazioni.

Data 360 ABAC opera attraverso:

• Politiche basate su tag che definiscono regole di accesso basate sui tag applicati agli oggetti dati (ad esempio, informazioni personali (PII), tag finanziari, sanitari e riservati).
• Le annotazioni vengono applicate agli oggetti dati per supportare le decisioni di autorizzazione basate su policy.
• Policy "Consenti tutti" predefinita per le organizzazioni nuove ed esistenti che devono essere eliminate esplicitamente per abilitare policy di governance granulari.

L'uso principale dell'architettura è l'imposizione della classificazione dei dati, vedere Classificazione dei dati in Protezione dei dati e privacy per informazioni su come i livelli di classificazione determinano l'imposizione dell'ABAC.

Questo livello di dettaglio comporta un costo operativo. La condivisione di base risponde alla domanda "Chi può visualizzare questo record e perché?" da un piccolo insieme di regole ispezionabili (OWD, gerarchia dei ruoli e regole di condivisione), mentre ABAC deriva le sue risposte in fase di valutazione dalla combinazione di tag di dati, attributi utente e contesto, quindi l'accesso effettivo diventa più difficile da ragionare e controllare man mano che policy e tag si accumulano.

Applicare la verificabilità come requisito di progettazione: applicare i tag in modo coerente, mantenere l'insieme di policy piccolo e denominato per la classificazione che applica e mantenere la possibilità di ricostruire il motivo per cui un utente ha raggiunto un determinato record. Riservare l'ABAC ai casi basati sulla classificazione che la condivisione per record non può esprimere, anziché trattarlo come un sostituto generale del modello basato sulla proprietà.

Identificare e proteggere gli account con privilegi elevati, inclusi gli amministratori di sistema, gli utenti integrazione e gli account dei processi automatici. Questi account sono destinazioni di grande valore per gli aggressori.

Applicare controlli ottimizzati agli account con impatto critico.

• Richiedi MFA resistente al phishing
• Limita gli intervalli IP di accesso alle posizioni amministrative note
• Abilitare gli avvisi di accesso e le notifiche di modifica delle autorizzazioni
• Eseguire revisioni periodiche dell'accesso con attestazione documentata per gli account con privilegi elevati la cui frequenza è determinata dai requisiti di tolleranza del rischio e conformità dell'organizzazione
• Gestire procedure di break-glass per l'accesso di emergenza e il controllo post-utilizzo

Per gli account integrazione e servizio:

• Applica flussi OAuth; mai flussi nome utente-password
• Imponi restrizioni IP
• Implementare pianificazioni di rotazione delle credenziali
• Monitoraggio degli schemi di utilizzo API anomali tramite Monitoraggio evento

La tua responsabilità: Identificare gli account critici, applicare controlli ottimizzati, eseguire revisioni trimestrali.

Progettare processi automatici per fornire agli utenti l'accesso iniziale appropriato, modificare le autorizzazioni man mano che i ruoli eseguono e annullare prontamente il provisioning quando l'accesso non è più necessario.

Implementare un sistema per la gestione dell'identità tra domini (SCIM) per il provisioning automatico dai provider di identità. Il provisioning just in time SAML o OpenID Connect è un'alternativa che crea un utente al primo accesso, ma non annulla il provisioning degli utenti. In altre parole, SCIM è la spina dorsale del ciclo di vita, non una scelta contraria.

Il ciclo di vita dell'identità include:

• Provisioning: Creare account con accesso di base corrispondente alla funzione lavorativa, attivata da eventi di sistema delle risorse umane.
• Rettifiche dell'accesso: Concedere autorizzazioni aggiuntive man mano che i ruoli si espandono e revocare le autorizzazioni quando i ruoli cambiano.
• Ricertificazione periodica: Esaminare e convalidare l'accesso ogni trimestre.
• Deprovisioning: Revocare immediatamente l'accesso quando il rapporto di lavoro termina o i ruoli non richiedono più l'accesso a Salesforce.

Implementare processi di ricertificazione dell'accesso quando i responsabili rivedono e convalidano periodicamente le autorizzazioni dei propri team. La frequenza di revisione si basa sui requisiti di rischio e conformità.

La tua responsabilità: Implementare SCIM, progettare flussi di lavoro di provisioning, eseguire ricertificazioni trimestrali.

La separazione dei dati in più organizzazioni è a volte considerata una decisione puramente di costo o di residenza. Dal punto di vista architettonico, si tratta di un compromesso in termini di sicurezza e le conseguenze sulla governance rientrano nella progettazione dell'accesso.

L'isolamento è il vantaggio chiave. Organizzazioni separate offrono il confine più stretto possibile tra le serie di dati. Non esiste un modello di condivisione collettiva né un sanguinamento delle autorizzazioni tra tenant, ma esiste una chiara linea normativa per le giurisdizioni che ne richiedono uno. Lo stesso confine frammenta la governance. Ogni controllo degli accessi che è necessario mantenere una sola volta all'interno di una singola organizzazione (ad esempio, progettazione degli insiemi di autorizzazioni, gerarchia dei ruoli, rafforzamento degli account con impatto critico, base di riferimento per il controllo dello stato, Monitoraggio evento e correlazione SIEM) ora viene moltiplicato per organizzazione, il che significa che deve mantenere la coerenza in tutte le organizzazioni. La fluttuazione tra le organizzazioni crea una propria superficie di attacco perché un'autorizzazione che viene stretta in un'organizzazione e che non viene rispettata in un'altra crea un'incoerenza che gli aggressori possono trovare e sfruttare. Le integrazioni tra organizzazioni aggiungono confini Trust autenticati che prima non esistevano. Ogni integrazione tra organizzazioni è una connessione che è necessario proteggere e monitorare.

Ecco perché è importante valutare il vantaggio dell'isolamento rispetto al moltiplicatore di governance prima di suddividere un'organizzazione. Riservare la multi-organizzazione ai casi in cui un mandato di localizzazione definitivo o il requisito di isolamento contrattuale di un cliente non possono essere soddisfatti da una singola organizzazione. Quando viene adottato, è necessario progettare il modello di accesso, il monitoraggio e le basi di riferimento della configurazione in modo che vengano applicati in modo identico in ogni organizzazione fin dall'inizio.

La tua responsabilità: Considerare una decisione tra più organizzazioni come un compromesso di sicurezza, non solo un compromesso di costo. Quando è necessario utilizzare più organizzazioni, applicare i controlli di accesso, il monitoraggio e le basi di riferimento per il controllo dello stato in modo coerente in ogni organizzazione e proteggere ogni integrazione tra organizzazioni come confine Trust.

È responsabilità dell'utente classificare i dati, configurare la crittografia, progettare controlli della privacy.

Vediamo più in dettaglio come proteggere correttamente i dati e la privacy.

Per classificare correttamente i dati, è necessario conoscere i dati. L'operazione architettonica generale è comprendere il dominio aziendale e gestire un dizionario dei dati che cataloga i dati in possesso, cosa significa e dove si trovano i dati sensibili. È possibile classificare o proteggere solo i dati identificati per primi.

Definire uno schema di classificazione dei dati che gestisca controlli di protezione appropriati. Un'etichetta di classificazione non protegge nulla da sola. Poiché si tratta dell'input per i controlli applicati, ogni classificazione assegnata deve essere mappata a una decisione concreta di crittografia, accesso, conservazione o monitoraggio. Le decisioni di classificazione prese durante la modellazione dei dati influenzano direttamente i requisiti di crittografia, i controlli di accesso, le policy di conservazione e gli obblighi di conformità.

Salesforce utilizza uno schema a quattro livelli che fornisce un framework che è possibile adattare ai requisiti normativi e alle esigenze aziendali dell'organizzazione. Molte aziende utilizzano modelli simili allineati agli standard del settore (ad esempio, ISO 27001 e NIST). L'implementazione specifica deve riflettere gli obblighi di conformità (ad esempio, HIPAA, PCI DSS, GDPR e regolamenti di settore) e il contesto aziendale.

Applicare la classificazione a livello di campo. Un singolo record Account può contenere campi Pubblici (ad esempio, nomi di società), Campi Riservati (ad esempio, redditi di società) e Campi Limitati (ad esempio, numeri di previdenza sociale). La protezione a livello di campo deve riflettere queste distinzioni.

La classificazione diventa applicabile tramite il controllo dell'accesso basato sugli attributi, che legge i tag assegnati e applica le regole di accesso. Si tratta di un livello basato sui metadati che integra OWD e le regole di condivisione.

L'allineamento di ABAC allo schema di classificazione consente alla piattaforma di:

• Limitare l'accesso ai dati contrassegnati con Limitato o Riservato dalla classificazione stessa anziché da una regola di condivisione mantenuta per oggetto.
• Adattare l'accesso man mano che la classificazione di un record cambia nel tempo. Un record contrassegnato di nuovo come Regolamentato eredita un accesso più limitato senza una modifica manuale della regola.
• Combinare gli attributi dei dati (ad esempio, classificazione e riservatezza) con gli attributi degli utenti (ad esempio, reparto e autorizzazione) e il contesto (ad esempio, ora e posizione) in un'unica decisione di autorizzazione.

Progettare policy ABAC in modo che siano allineate a questo schema in modo che la classificazione di un campo come Limitato sia l'azione che determina i relativi controlli di accesso e mantiene l'imposizione ancorata alla classificazione anziché mantenere le regole di condivisione separatamente.

La tua responsabilità: Definire lo schema di classificazione, addestrare i modellatori di dati, classificare i campi durante la progettazione, configurare i controlli e allineare le policy ABAC ai livelli di classificazione in modo che i tag favoriscano l'imposizione.

IniziareIniziare con le informazioni già fornite dalla piattaforma per ogni organizzazione. I dati a riposo sono crittografati per impostazione predefinita. Hyperforce applica la crittografia a livello di volume che protegge un intero volume di memoria sotto un'unica chiave di cui Salesforce è titolare e che gestisce. Questa base di riferimento è sempre attiva e trasparente per la soluzione, ma opera a livello di volume (non per campo), quindi la scelta di ciò che crittografare e controllare entro il ciclo di vita della chiave dipende dalla piattaforma, non dall'utente.

Quando la base di riferimento non è in grado di soddisfare un obbligo di conformità, contrattuale o di classificazione dei dati, utilizzare Shield Platform Encryption. In particolare, quando è necessaria una delle tre cose che la crittografia a livello di volume non fornisce:

• Controllo del ciclo di vita della chiave per consentire la generazione, la rotazione e la revoca del materiale della chiave
• Selettività dei campi standard, personalizzati, file e allegati crittografati a riposo
• Possibilità di rendere i dati inaccessibili a Salesforce.

I dati limitati e i dati soggetti a mandati espliciti di controllo delle chiavi normative (ad esempio, HIPAA, PCI DSS e GDPR) sono i soliti trigger. La base di riferimento copre già la protezione a livello di infrastruttura di tutto il resto.

Shield Platform Encryption esegue la crittografia a livello di campo e offre due schemi che scambiano la sicurezza con la possibilità di eseguire query.

La crittografia probabilistica è uno schema predefinito forte, ma i campi crittografati con essa non possono essere utilizzati nei criteri di filtro, nell'ordinamento o nelle funzioni di aggregazione (ad esempio, le funzioni MAX(), MIN() e COUNT_DISTINCT().

La crittografia deterministica abilita il filtro delle corrispondenze esatte nei rapporti, nelle visualizzazioni elenco e nelle clausole WHERE SOQL (con distinzione tra maiuscole e minuscole o senza distinzione tra maiuscole e minuscole) a una potenza ridotta poiché lo stesso testo normale produce sempre lo stesso testo cifrato.

Si consiglia di eseguire la crittografia con lo schema probabilistico per impostazione predefinita e di riservare la crittografia deterministica per i campi specifici che è necessario filtrare o ordinare. Valutare questi compromessi durante la progettazione della modellazione dei dati, inclusi gli impatti sui riferimenti ai campi formula, sull'aggregazione dei rapporti e sulle operazioni SOQL.

Le chiavi controllate dal cliente sono disponibili in due forme distinte:

• Bring Your Own Key (BYOK) consente di generare materiale della chiave all'esterno di Salesforce, utilizzando le proprie librerie crittografiche, il sistema di gestione delle chiavi aziendale o il modulo di sicurezza hardware, e di fornirlo alla piattaforma.
• Servizio chiavi solo cache mantiene la chiave di crittografia dei dati in un servizio chiavi controllato dall'utente. Salesforce lo recupera su richiesta anziché archiviarlo.

Entrambi i moduli consentono di ruotare e distruggere il materiale della chiave in base alle proprie pianificazioni. La distruzione del materiale della chiave rende irrecuperabili i dati che proteggeva, ovvero un controllo potente e deliberato anziché una routine. È anche importante documentare le procedure di rotazione e revoca delle chiavi.

Tutte le integrazioni devono utilizzare TLS 1.2 o superiore (la piattaforma Salesforce lo impone), ma è necessario implementare l'autenticazione reciproca basata su certificato per le integrazioni che gestiscono dati con restrizioni (utilizzando la propria configurazione).

La tua responsabilità: Decidere dove è sufficiente la base di riferimento a livello di volume della piattaforma e dove un obbligo di conformità, contrattuale o di classificazione richiede Shield Platform Encryption, quindi selezionare gli schemi di crittografia, scegliere e applicare una strategia basata sulle chiavi controllata dal cliente e implementare l'autenticazione basata su certificato per le integrazioni sensibili.

Proteggere i dati sensibili in ambienti non di produzione utilizzando strategie che impediscono l'ingresso di dati con restrizioni nei Sandbox.

• La copia parziale Sandbox esclude i dati con restrizione dagli aggiornamenti Sandbox.
• Le regole di mascheramento dei dati confondono i valori dei campi sensibili nei Sandbox utilizzando schemi che conservano le caratteristiche dei dati.
• La generazione dati sintetici si applica agli ambienti di sviluppo che non richiedono mai dati di produzione.
• I modelli Sandbox definiscono gli oggetti e i campi da includere in ogni tipo di Sandbox.

Progettare per i test di conformità è una responsabilità architettonica. Creare cicli di sviluppo e test su dati sintetici con caratteristiche realistiche, in modo che i team possano eseguire la convalida in base a condizioni simili a quelle di produzione pur mantenendo i dati regolamentati entro i confini di produzione.

La tua responsabilità: Progettare una strategia Sandbox, configurare le regole Data Mask, generare dati di test sintetici.

Progettare soluzioni che rispettino la privacy degli utenti tramite decisioni architettoniche.

• Riduzione al minimo dei dati: Raccogliere i dati necessari solo per scopi aziendali dichiarati. Sfidare ogni aggiunta di campo chiedendo: "Quale decisione architettonica richiede questi dati?" Ricordare che i dati più sicuri sono quelli che non si raccolgono mai.
• Limitazione dello scopo: Progettare schemi di accesso ai dati che impongano tecnicamente la limitazione dello scopo. Utilizzare gli insiemi di autorizzazioni e le regole di condivisione per limitare l'accesso ai dati in base allo scopo di una funzione lavorativa. Ad esempio, gli utenti marketing non dovrebbero accedere ai dettagli dei casi di assistenza a meno che il loro lavoro non lo richieda.
• Gestione del consenso: Implementare il tracciamento del consenso a livello individuale per il marketing, l'analisi e il trattamento facoltativo dei dati. Progettare flussi di lavoro di revoca del consenso che si propagano tra i sistemi integrati. In altre parole, il consenso è granulare e specifico dello scopo.
• Diritti degli interessati: Creare flussi di lavoro per le richieste di accesso (ad esempio, fornire copie dei dati), la rettifica (ad esempio, correggere le imprecisioni), la cancellazione (ad esempio, eliminare i dati quando è legalmente consentito farlo) e la portabilità (ad esempio, esportare in un formato leggibile dal computer). Progettare questi flussi di lavoro in modo che vengano completati entro la scadenza di risposta imposta da ogni framework di governo. Queste scadenze variano a seconda della giurisdizione e vengono modificate periodicamente, quindi è importante parametrizzare il contratto sul livello di servizio del flusso di lavoro da una fonte di conformità mantenuta e confermare ogni finestra rispetto al regolamento in vigore (anziché codificare un singolo valore).

La tua responsabilità: Progettare modelli di dati riducendo al minimo, configurare l'accesso per scopo, implementare flussi di lavoro di consenso, creare l'automazione dei diritti degli interessati.

La residenza dei dati è una scelta dell'architettura che viene presa prima del provisioning, non un'impostazione che viene attivata in seguito. Hyperforce offre una distribuzione regionale, ma esiste solo una regione in cui Salesforce ne gestisce una, e la residenza di un'organizzazione viene fissata al provisioning. È responsabilità dell'utente stabilire dove deve risiedere ogni categoria di dati, verificare se è disponibile una regione adatta e progettare i meccanismi di trasferimento dei dati che attraversano legittimamente le frontiere.

Anziché utilizzare per impostazione predefinita l'archiviazione interna, è importante classificare gli obblighi di residenza prima di iniziare.:

• Localizzazione obbligatoria. Un piccolo insieme di giurisdizioni richiede che alcuni dati rimangano all'interno dei confini nazionali (talvolta, questo vale solo per i settori regolamentati). Quando Salesforce non opera in una regione del paese, l'archiviazione nativa non è in grado di soddisfare il mandato da sola, quindi è necessaria una sovrapposizione dati-residenza o un'organizzazione separata per i dati. Poiché questo elenco può cambiare, è importante confermare il mandato specifico contro il regolamento in vigore.
• Framework basati sulla responsabilità. La maggior parte dei regimi non impone un mandato di localizzazione. Sono soddisfatti da un hub regionale con un meccanismo di trasferimento transfrontaliero appropriato. In questi casi, la decisione si basa sulla regione che riduce al minimo la latenza e semplifica la conformità.

Quando i dati attraversano un confine, il punto è la consapevolezza prima della configurazione. In altre parole, è necessario sapere quali trasferimenti avvengono e su quale base giuridica e quindi progettare l'accesso in modo che i dati siano regolati dall'inizio alla fine. Quando esistono, le decisioni di adeguatezza sono quelle meno frizionate. Le regole aziendali vincolanti (BCR) e le clausole contrattuali standard (SCC) coprono la maggior parte dei trasferimenti rimanenti. Utilizzare il consenso esplicito solo come ultima risorsa.

Abbinare il meccanismo di trasferimento a un accesso limitato ai record (ad esempio, OWD privati e condivisione mirata) in modo che un trasferimento consentito non diventi eccessivamente ampio. Mappature del flusso di dati del documento per mostrare da dove proviene, transita e risiede ogni categoria di dati. Riesaminarle quando cambiano i regolamenti o le disponibilità regionali.

La tua responsabilità: Classificare gli obblighi di residenza per categoria di dati, verificare la disponibilità regionale prima del provisioning, selezionare i meccanismi di trasferimento (adeguatezza, BCR/SCC) per i flussi transfrontalieri e documentare le mappe dei flussi di dati.

È responsabilità dell'utente progettare soluzioni che mantengano il comportamento conforme fornito dalla piattaforma.

Queste indicazioni sono direzionali. I requisiti normativi variano a seconda della giurisdizione e cambiano nel tempo. È sempre necessario verificare obblighi specifici rispetto al regolamento vigente (ad esempio, lo statuto applicabile, l'autorità di supervisione o la documentazione di conformità Salesforce) per la distribuzione.

Salesforce gestisce numerose certificazioni di conformità (disponibili su Trust.salesforce.com e compliance.salesforce.com): SOC 2 Tipo II, ISO 27001, FedRAMP (per le offerte Government Cloud), HIPAA, PCI DSS e certificazioni regionali. Queste certificazioni coprono le responsabilità di Salesforce per l'infrastruttura della piattaforma e i servizi condivisi.

Le certificazioni piattaforma riducono il carico di conformità, ma non eliminano la responsabilità architettonica. Gli oggetti personalizzati, l'Apex Code, le integrazioni e le configurazioni devono mantenere il comportamento conforme fornito dalla piattaforma.

La tua responsabilità: Progettare soluzioni che mantengano il comportamento conforme e documentino in che modo l'architettura soddisfa i requisiti normativi.

• Abilitare Shield Platform Encryption per tutti i campi che contengono informazioni sanitarie protette (PHI).
• Per garantire la conformità HIPAA, abilitare l'itinerario di controllo con policy di conservazione per soddisfare il requisito di conservazione dei record HIPAA. Confermare il periodo corrente rispetto al regolamento in vigore.
• Configurare Monitoraggio evento per rilevare schemi di accesso PHI non autorizzati.
• Implementare tutte le misure di protezione tecniche richieste dalla regola di sicurezza HIPAA, inclusi i controlli di accesso, la registrazione dei controlli e la sicurezza della trasmissione.

• Implementare la separazione dei doveri (SoD) tramite strutture di insiemi di autorizzazioni per impedire ai singoli utenti di creare e approvare transazioni finanziarie.
• Per gli ambienti PCI, evitare di memorizzare numeri di account principali completi (PAN) in Salesforce per ridurre al minimo l'ambito di conformità PCI DSS.
• Ove possibile, utilizzare la tokenizzazione del gateway di pagamento.

• Per GDPR e LGPD, progettare una gestione del consenso che acquisisca un consenso esplicito granulare specifico per lo scopo.
• CCPA/CPRA segue un modello di rifiuto esplicito. Fornire meccanismi chiari per escludere esplicitamente la vendita o la condivisione delle informazioni personali anziché fornire un consenso granulare basato sullo scopo.
• Creare flussi di lavoro per i diritti degli interessati completati entro i termini di risposta di ogni framework e confermati in base al regolamento in vigore.
• Implementare un'automazione della conservazione dei dati che elimina i dati alla scadenza del consenso.

• Utilizzare Salesforce Government Cloud per i carichi di lavoro governativi regolamentati.
• Implementare i controlli NIST 800-53 mappati alla configurazione Salesforce.
• Abilitare il monitoraggio continuo tramite Monitoraggio evento instradato all'infrastruttura SIEM governativa.

La tua responsabilità: Configurare Shield, Itinerario di controllo campi, separazione delle mansioni, gestione del consenso, conservazione dei dati in base ai requisiti normativi.

I regolamenti sulla protezione dei dati e tutela della privacy variano in modo significativo nelle giurisdizioni (e gli obblighi specifici cambiano rapidamente), quindi questo livello richiede un processo decisionale anziché una tabella paese per paese.

Le due leve architettoniche sono la residenza e il trasferimento transfrontaliero, che sono coperti da Data Protection e Privacy.

Per rispettare questi regolamenti, è necessario:

• Classificazione della posizione in cui deve risiedere ogni categoria di dati
• Verificare che esista una regione adatta prima del provisioning
• Progettare un meccanismo di trasferimento legale per i dati che attraversano un confine.

Per ulteriori informazioni, vedere Data Residency and Sovereignty (Residenza e sovranità dei dati) per ulteriori dettagli sul framework decisionale.

Tutto ciò che non rientra in questa categoria è considerato una cifra temporale (ad esempio, il modello di consenso utilizzato da una giurisdizione, la scadenza per una richiesta di interessato, la finestra temporale per la notifica alle autorità di regolamentazione o alle persone interessate dopo una violazione e il periodo minimo di conservazione per i record di controllo). Queste cifre sono stabilite dai regolamenti, differiscono a seconda del framework e vengono modificate in base alle pianificazioni delle autorità di regolamentazione.

Non codificarli qui. È necessario determinare le fasi successive in base al regolamento vigente per la distribuzione (o a una fonte di conformità mantenuta che ne cita una) e dimensionare la progettazione in base alla finestra più stretta della propria impronta operativa.

Ecco le conseguenze architettoniche durevoli che appartengono alla progettazione.

• Poiché una scadenza per la richiesta dell'interessato misurata in giorni a una sola cifra non può essere rispettata da un processo manuale ad hoc, è necessario automatizzare l'evasione del DSR quando si opera in una giurisdizione con scadenze brevi. Utilizzare Experience Cloud per l'accettazione, Service Cloud per il tracciamento dei casi, Centro privacy per l'individuazione e Flusso per l'evasione.
• Poiché una finestra di notifica della violazione è troppo stretta per essere improvvisata, è necessario creare in anticipo il flusso di lavoro di risposta alla violazione. Determinare le regole dell'anomalia di Monitoraggio evento, i ruoli preassegnati, le notifiche predefinite dell'autorità di regolamentazione e dell'interessato e un percorso di inoltro al livello superiore che presuppone la scadenza più ravvicinata all'interno della propria impronta. Poiché le singole notifiche sono generalmente attivate da una determinazione ad alto rischio, è necessario includere una valutazione del rischio nel flusso di lavoro.
• Alcune giurisdizioni richiedono o consigliano la conservazione dei registri di controllo nel paese, con minimi che si estendono su più anni, quindi è necessario limitare la conservazione SIEM al minimo più lungo all'interno della propria impronta e verificare se i registri possono lasciare la giurisdizione.

La tua responsabilità: Progettare la residenza e il trasferimento in base alla protezione dei dati e alla privacy, automatizzare i flussi di lavoro DSR e di risposta alle violazioni fino alla scadenza più ravvicinata e confermare ogni valore specifico della giurisdizione rispetto al regolamento in vigore anziché un valore scritto in questa guida.

Progettare per la convalida continua della conformità anziché per la preparazione al controllo puntuale.

• Il Controllo dello stato valuta la configurazione in base ai valori di base di sicurezza di Salesforce e fornisce i punteggi di rischio. Eseguire controlli regolari per monitorare la conformità ai consigli di base sulla sicurezza di Salesforce. Mantenere punteggi dell'80% o superiori (bande molto buone o eccellenti).
• Monitoraggio evento acquisisce registri dettagliati per l'attività degli utenti, le chiamate API, gli eventi di autenticazione e gli schemi di accesso ai dati. Instradare i file registro eventi a SIEM esterni per la conservazione a lungo termine che supera i limiti di conservazione nativi.
• La sicurezza delle transazioni valuta gli eventi rispetto alle policy in tempo reale e può bloccare gli eventi, richiedere un aumento della MFA o informare l'utente di violazioni delle policy.

È importante automatizzare i controlli di conformità nelle opportunità in corso di realizzazione per verificare che le distribuzioni non indeboliscano i modelli di autorizzazione, disabilitino le impostazioni di controllo o introducano configurazioni non conformi.

La tua responsabilità: Eseguire il controllo dello stato trimestralmente, instradare Monitoraggio evento a SIEM, configurare le policy sulla sicurezza delle transazioni, automatizzare la convalida della conformità in CI/CD.

Progettare strategie di audit trail basate sui requisiti di conformità, sulle esigenze di indagine e sugli obblighi di conservazione.

Per gli ambienti regolamentati, implementare Monitoraggio evento con integrazione SIEM esterna per la conservazione dei registri a lungo termine e la correlazione tra sistemi. Progettare policy Itinerario di controllo campi che coprano tutti i campi Limitati e Riservati soggetti a requisiti normativi per la conservazione dei record.

La tua responsabilità: Abilitare Itinerario di controllo campi per i campi sensibili, instradare Monitoraggio evento a SIEM, configurare le policy sulla sicurezza delle transazioni.

È responsabilità dell'utente integrare la sicurezza durante lo sviluppo, non come ripensamento.

Integrare le procedure di sicurezza nella prima fase di sviluppo possibile. La modellazione delle minacce durante la fase di architettura evita vulnerabilità a livello di progettazione. I requisiti di sicurezza acquisiti insieme ai requisiti funzionali impediscono di trattare la sicurezza come un ripensamento.

I difetti di sicurezza costano molto di più quando vengono rilevati in produzione anziché durante le fasi di progettazione o sviluppo. Una falla di protezione a livello di progettazione rilevata durante la revisione dell'architettura può richiedere una sola conversazione per essere risolta. Tuttavia, quando si rileva lo stesso difetto nell'ambiente di produzione, è necessario eseguire una nuova architettura, la migrazione dei dati, la correzione della conformità e la notifica di potenziali violazioni.

Ecco perché pratichiamo la sicurezza turni a sinistra, che si concentra su:

• Modellazione delle minacce prima della finalizzazione della progettazione
• Requisiti di sicurezza nelle storie utente
• Formazione sul codice protetto per gli sviluppatori
• Analisi statica integrata nelle IDE
• Revisioni del codice incentrate sulla sicurezza
• Test di sicurezza automatici in CI/CD
• Convalida della sicurezza prima della distribuzione in produzione

La tua responsabilità: Eseguire la modellazione delle minacce, formare gli sviluppatori, integrare Code Analyzer in CI/CD, richiedere revisioni del codice sensibili alla sicurezza.

È importante progettare difese contro le vulnerabilità comuni in un contesto Salesforce. Vediamo più in dettaglio come mappare la Top 10 OWASP 2025 di Salesforce.

• A01:2025 - Controllo dell'accesso rotto: Applicare a livello di programmazione CRUD e protezione a livello di campo (FLS) in tutti gli accessi ai dati Apex.
  • Nell'API versione 67.0 o successive, Apex viene eseguito nel contesto dell'utente per impostazione predefinita, il che significa che le autorizzazioni e l'FLS dell'utente corrente vengono imposti durante l'esecuzione del codice.
    • WITH SECURITYENFORCED è stato rimosso, causando un errore di compilazione. Sostituire eventuali utilizzi esistenti con WITH USER_MODE. La piattaforma impone l'accesso nell'interfaccia utente standard.
  • Nell'API versione 66.0 o precedente, la modalità di sistema è l'impostazione predefinita. Utilizzare WITH USERMODE nelle query SOQL o Security.stripInaccessible() per le operazioni DML.
• A01:2025 - API dati lato client: Lightning Data Service e l'API dell'interfaccia utente impongono automaticamente FLS, CRUD e condivisione dell'utente in esecuzione, in modo che un componente basato su di essi erediti i privilegi minimi per impostazione predefinita.
  • Questa protezione viene persa quando un componente chiama un Apex personalizzato. Apex imperativo impone l'accesso solo quando viene eseguito in modalità utente, quindi una classe dichiarata senza condivisione funge da escape hatch che ignora silenziosamente il modello.
  • Utilizzare Lightning Data Service e l'API dell'interfaccia utente per l'accesso ai dati.
  • È necessario riaffermare CRUD, FLS e condivisione per ogni chiamata Apex imperativa da un componente.
• A02:2025 - Configurazione errata della protezione: Monitorare la fluttuazione della configurazione rispetto ai valori di base della sicurezza utilizzando il controllo dello stato.
  • Disabilitare l'accesso degli utenti guest sui siti Experience Cloud (a meno che non sia esplicitamente richiesto da una giustificazione aziendale documentata).
• A05:2025 - Iniezione: La categoria 2025 Injection include SOQL/SOSL injection e cross-site scripting (XSS).
  • Per l'inserimento di query, utilizzare le variabili di collegamento per tutte le query dinamiche. Non concatenare mai l'input dell'utente direttamente nelle stringhe di query. I meccanismi di query parametrizzati della piattaforma eliminano il rischio di iniezioni quando vengono utilizzati correttamente.
  • Le iniezioni SOQL o SOSL vengono limitate a una lettura che rivela record o campi che il chiamante non dovrebbe essere in grado di raggiungere ampliando le condizioni di query. Poiché queste lingue leggono i dati mentre le scritture vengono eseguite attraverso operazioni DML separate, questo crea un rischio di accesso-controllo e riservatezza perché si aggrava quando le autorizzazioni oggetto e campo non vengono applicate alla query.
  • Per XSS, i componenti Web Lightning offrono una protezione automatica tramite il motore di rendering LWC.
  • Per i componenti Aura e Visualforce, è necessario applicare le funzioni di codifica della piattaforma (ad esempio, HTMLENCODE, JSENCODE e URLENCODE) durante la visualizzazione di contenuti dinamici.

La tua responsabilità: Applicare CRUD/FLS nel codice personalizzato, applicare funzioni di codifica, utilizzare variabili di collegamento, monitorare la fluttuazione della configurazione.

Progettare pipeline CI/CD con varchi di sicurezza in ogni fase. La sicurezza deve essere automatizzata per essere scalabile con la velocità di sviluppo.

Vediamo più nel dettaglio le fasi della sicurezza delle opportunità in corso di realizzazione.

• Il controllo sorgente utilizza le regole di protezione delle filiali con revisioni del codice richieste. Non sono presenti conferme dirette alle filiali principali o conferme firmate.
• L'analisi statica utilizza Salesforce Code Analyzer, che incorpora PMD, ESLint e RetireJS per rilevare schemi di iniezione, XSS e insicuri.
• La scansione della sicurezza utilizza gli strumenti e il rilevamento dei segreti SAST per impedire le conferme delle credenziali e la scansione della vulnerabilità delle dipendenze.
• La convalida delle autorizzazioni utilizza tecniche di confronto automatiche per esaminare le modifiche delle autorizzazioni rispetto alle norme di base di sicurezza, che inviano avvisi relativi all'espansione dei privilegi.
• I gate di distribuzione interrompono la distribuzione per i risultati di sicurezza critici che richiedono l'approvazione del team di sicurezza per le modifiche che estendono le autorizzazioni.
• Il monitoraggio post-distribuzione utilizza gli avvisi di Monitoraggio evento per rilevare comportamenti anomali dopo le distribuzioni.

La tua responsabilità: Integrare Code Analyzer in CI/CD, configurare la protezione delle filiali, implementare i gateway di distribuzione, convalidare automaticamente le autorizzazioni.

Test di sicurezza completi includono più tecniche che riguardano diverse classi di vulnerabilità. Vediamo più nel dettaglio ogni strategia.

• L'analisi statica esegue Salesforce Code Analyzer nelle IDE sviluppatore per un feedback immediato e nelle pipeline CI/CD come porte automatiche. L'analisi statica identifica le vulnerabilità nel codice sorgente senza eseguire l'applicazione.
• Il test di penetrazione esegue test di penetrazione per le applicazioni personalizzate esposte a utenti non affidabili, in particolare i siti Experience Cloud e le API rivolte al pubblico.
  • Per AppExchange e AgentExchange Security Review sono sempre necessari rapporti di analisi statica.
  • Un rapporto di scansione dinamico (test di penetrazione) è necessario quando la soluzione integra un'applicazione o un servizio Web di terze parti.
  • Il test di penetrazione simula le tecniche di attacco contro le applicazioni live.
• I test di unità scrivono test Apex che convalidano l'imposizione del controllo degli accessi eseguendoli come utenti con profili di autorizzazioni diversi. È importante verificare che l'imposizione CRUD/FLS blocchi l'accesso non autorizzato.
• L'analisi delle dipendenze monitora i pacchetti AgentExchange e le librerie JavaScript per individuare vulnerabilità note. È importante abbonarsi agli avvisi di sicurezza per i pacchetti installati.

La tua responsabilità: Eseguire Code Analyzer, eseguire test di penetrazione, scrivere test di unità di sicurezza, analizzare le dipendenze.

In Salesforce, la protezione e la risposta agli incidenti sui dati si concentrano sul rilevamento, il contenimento e il ripristino da violazioni, accessi non autorizzati e distruzione di dati dannosi. I team di risposta agli incidenti lavorano insieme a due pilastri vicini che hanno responsabilità adiacenti:

• L'eccellenza operativa copre i meccanismi operativi della gestione degli incidenti (ad esempio, livelli di gravità, rotazione su chiamata, inoltro al livello superiore e riesame post-incidente)
• L'affidabilità copre il ripristino della disponibilità rispetto ai target RTO e RPO, incluse le strategie di backup e ripristino di emergenza.

In qualità di architetto, è responsabilità dell'utente progettare per la rilevabilità, la risposta e il ripristino degli incidenti di sicurezza.

La rilevabilità è una qualità architettonica per cui è necessario progettare in modo esplicito. Senza un monitoraggio completo, gli incidenti di sicurezza potrebbero non essere rilevati per lunghi periodi di tempo.

È importante implementare il rilevamento attraverso più canali.

• Monitoraggio evento acquisisce registri eventi non elaborati che coprono accessi, esportazioni di rapporti e dati, modifiche delle autorizzazioni e chiamate API. È necessario identificare gli eventi anomali, che richiedono policy sulla sicurezza delle transazioni o correlazione SIEM oltre ai registri configurati per determinare la logica di rilevamento.
• Le policy sulla sicurezza valutano gli eventi in tempo reale e bloccano le azioni sospette. È necessario configurare queste policy.
• L'itinerario di controllo impostazioni tiene traccia delle modifiche amministrative fornite dalla piattaforma, ma è necessario monitorarle.
• La registrazione personalizzata delle applicazioni acquisisce gli eventi rilevanti per la sicurezza in Apex che è necessario implementare.

Instradare i registri di Monitoraggio evento alle piattaforme SIEM per la correlazione con la telemetria di sicurezza aziendale. Progettare regole di avviso che rilevino schemi sospetti riducendo al minimo i falsi positivi attraverso valori di riferimento comportamentali.

La tua responsabilità: Instradare Monitoraggio evento a SIEM, configurare le policy sulla sicurezza delle transazioni, implementare la registrazione personalizzata, stabilire valori di riferimento comportamentali.

È importante documentare le decisioni architettoniche che supportano la risposta agli incidenti prima che si verifichino.

• I limiti dell'isolamento progettano soluzioni per isolare i componenti compromessi senza interrompere le funzioni aziendali critiche. È necessario configurare la revoca dell'insieme di autorizzazioni, le modifiche delle restrizioni IP e la chiusura della sessione per fornire funzionalità di isolamento rapido.
• La conservazione forense utilizza Monitoraggio evento per fornire registri attività dettagliati (funzionalità piattaforma). L'itinerario di controllo campi conserva la cronologia delle modifiche dei dati in base alla configurazione. I registri di progettazione vengono instradati a memoria immutabile in modo che gli aggressori non possano modificare l'architettura.
• Le procedure di ripristino documentano i processi di ripristino testati per i tipi di incidenti più comuni. È importante convalidare regolarmente l'integrità del backup. È necessario conoscere l'Obiettivo tempo di ripristino (RTO) e l'Obiettivo punto di ripristino (RPO) per gli scenari di incidenti di sicurezza.
• I flussi di lavoro progettano meccanismi di notifica che funzionano durante gli incidenti (ad esempio, canali di comunicazione fuori banda, modelli predefiniti e procedure di inoltro al livello superiore che non dipendono da sistemi potenzialmente compromessi).
• Il canale di informativa è destinato ai siti Experience Cloud rivolti al pubblico. Offre ai ricercatori esterni un modo documentato e monitorato per segnalare problemi di sicurezza tramite una policy di informativa pubblicata nello standard RFC 9116 security.txt. Un rapporto esterno è spesso il primo segnale di un incidente, quindi è importante stabilire questo percorso di accettazione come parte dell'architettura di cui si è responsabili.

La tua responsabilità: Documentare le procedure di isolamento, instradare i registri all'archiviazione esterna immutabile, testare le procedure di ripristino trimestralmente, stabilire una comunicazione fuori banda e pubblicare un canale di divulgazione delle vulnerabilità per i siti rivolti al pubblico.

In Salesforce, è importante preparare le funzionalità di risposta per gli scenari specifici della piattaforma.

• Gli account utente compromessi vengono rilevati tramite anomalie di accesso di Monitoraggio evento (ad esempio, area geografica imprevista, orari insoliti e nuovi dispositivi). Quando gli account sono compromessi, congelare l'utente, forzare la reimpostazione delle credenziali, esaminare l'itinerario di controllo impostazioni e i registri di accesso ai dati per determinare il periodo di compromesso.
• L'esfiltrazione in blocco viene rilevata tramite le esportazioni dei rapporti di Monitoraggio evento e le anomalie del volume di accesso ai dati API. Quando si verifica l'esfiltrazione dei dati, revocare immediatamente le sessioni, limitare le autorizzazioni e identificare i record e i livelli di classificazione interessati.
• La distribuzione codice non autorizzata viene rilevata tramite il monitoraggio della distribuzione e le modifiche alla configurazione dell'itinerario di controllo impostazioni. Quando viene distribuito codice non autorizzato, ritirare immediatamente la distribuzione e controllare tutte le modifiche apportate dalla credenziale di distribuzione compromessa.
• L'inoltro dei privilegi al livello superiore viene rilevato tramite il monitoraggio dell'itinerario di controllo impostazioni per le modifiche delle autorizzazioni che non rientrano nelle finestre di modifica approvate. Quando si verifica l'inoltro dei privilegi al livello superiore, revocare immediatamente i privilegi inoltrati al livello superiore e controllare le attività eseguite con accesso elevato.

La tua responsabilità: Documentare le procedure di risposta per scenari specifici della piattaforma, configurare il monitoraggio per rilevare ogni scenario, testare le procedure tramite esercizi da tavolo.

Dopo un incidente, è importante condurre una revisione post-incidente senza giudizi e incentrata sui miglioramenti architettonici. È necessario documentare l'accaduto, il motivo per cui i controlli esistenti non sono riusciti a prevenire o rilevare l'incidente e le modifiche architettoniche necessarie per ridurre i rischi futuri.

Obiettivi del riesame post-incidente:

• Determinare la tempistica dell'incidente e le tecniche di attacco.
• Identificare gli errori di controllo che hanno abilitato l'incidente.
• Documentare tutte le debolezze architettoniche evidenziate dall'incidente.
• Assegnare la priorità alla riparazione basata sulla riduzione del rischio.
• Condividere le lezioni apprese tra i team.
• Aggiornare le regole di rilevamento e le procedure di risposta.

È importante tenere traccia delle metriche degli incidenti nel tempo per determinare il tempo medio di rilevamento (MTTD), il tempo medio di risposta (MTTR) e l'ambito dell'impatto.

La tua responsabilità: Eseguire un riesame post-incidente tempestivo, documentare i miglioramenti nelle ADR, tenere traccia delle tendenze MTTD e MTTR, condividere le lezioni apprese.

Utilizzare questo elenco di controllo durante le revisioni dell'architettura, prima della distribuzione in produzione e periodicamente per una valutazione continua. Ogni elemento rappresenta le responsabilità di un architetto Salesforce.

Responsabilità condivisa

• Documentare tutto ciò che Salesforce protegge (ad esempio, infrastruttura, piattaforma e certificazioni di conformità).
• Documentare tutto ciò che è necessario proteggere (ad esempio configurazione, accesso, codice personalizzato e governance dei dati).
• Identificare le aree di responsabilità condivisa (ad esempio, risposta agli incidenti, gestione delle vulnerabilità e monitoraggio).
• Comunicare le responsabilità agli stakeholder e ai team di implementazione nel modo più chiaro e conciso possibile.

Architettura di sicurezza

• Completare la modellazione delle minacce utilizzando la metodologia STRIDE prima di iniziare a creare.
• Applicare controlli approfonditi a livello di dati, applicazione, identità e integrazione.
• Implementare i principi zero Trust che richiedono una verifica esplicita per ogni richiesta di accesso.
• Gestire l'inventario aggiornato degli asset di protezione che include dati sensibili, integrazioni, API e account con privilegi.
• Documentare le decisioni dell'architettura di sicurezza nelle ADR, incluse l'analisi delle minacce e la giustificazione del controllo.
• Proteggere i client headless e per conto dei clienti al confine del Trust Salesforce propagando le identità per utente anziché i token pool.
• Archiviare, ruotare e archiviare le credenziali OAuth con ambito con privilegi minimi tramite le app client esterne.
• Per le integrazioni containerizzate, imporre l'isolamento dei container come confine di sicurezza, crittografare il traffico VPN inter-container e ibrido con mTLS (quando il framework lo richiede) e allineare le regioni di distribuzione alle certificazioni di residenza dei dati e conformità

Gestione delle identità e degli accessi

• Impostare OWD su Privato per gli oggetti che contengono dati sensibili.
• Riservare Sola lettura pubblica agli oggetti in cui è richiesto un ampio accesso in lettura.
• Applicare la MFA per tutti gli accessi dell'interfaccia utente di produzione e le chiavi di protezione hardware per gli account con privilegi. Le integrazioni solo API che utilizzano JWT Bearer o le credenziali client sono esenti.
• Implementare SSO utilizzando SAML 2.0 o OpenID Connect con autenticazione IdP avanzata.
• Utilizzare OAuth 2.0 (JWT Bearer preferito) per tutta l'autenticazione API. Non utilizzare mai OAuth 2.0 per le credenziali incorporate.
• Concedere l'accesso tramite insiemi di autorizzazioni basati su requisiti con privilegi minimi documentati.
• Applicare controlli ottimizzati agli account con impatto critico (ad esempio, restrizione IP, avvisi di accesso e revisioni periodiche dell'accesso).
• Eseguire revisioni periodiche dell'accesso utilizzando attestazioni documentate per gli account con privilegi elevati la cui frequenza è determinata dai requisiti di tolleranza del rischio e conformità dell'organizzazione.
• Automatizzare il ciclo di vita dell'identità tramite il provisioning SCIM e il rilevamento degli account dormienti per 90 giorni.
• Eseguire gli agenti dipendenti nel contesto dell'utente connesso ed eseguire il provisioning degli utenti agenti dedicati con privilegi minimi per gli agenti clienti. Non eseguire mai questa operazione per un utente guest di un sito pubblico.
• Implementare JWT per l'autenticazione degli agenti utilizzando gli identificatori di istanza agente e definizione bot.
• Definire policy ABAC in linea con gli standard di classificazione dei dati e di creazione di tag di metadati coerenti.

Protezione dei dati e privacy

• Classificare tutti i dati e applicare i controlli di protezione appropriati a ogni livello di classificazione.
• Abilitare Shield Platform Encryption per i dati limitati utilizzando la gestione delle chiavi documentata.
• Richiedere TLS 1.2+ per tutte le integrazioni con autenticazione basata su certificato per Dati limitati.
• Impedire l'accesso dei dati limitati agli ambienti non di produzione tramite mascheramento o esclusione.
• Implementare la gestione del consenso con flussi di lavoro di tracciamento e ritiro granulari per scopo.
• Creare flussi di lavoro per i diritti degli interessati completati entro la scadenza di risposta di ogni framework di governo. Questi devono essere dimensionati in base alla finestra più stretta della propria impronta operativa e parametrizzati in base alla giurisdizione da una fonte di conformità mantenuta in cui ogni dato è confermato rispetto al regolamento vigente.
• Documentare i requisiti di residenza dei dati e convalidare l'allineamento delle regioni Hyperforce.

Conformità e osservanza normativa

• Convalidare le certificazioni piattaforma che soddisfano i requisiti normativi per il proprio settore.
• Abilitare Monitoraggio evento con instradamento SIEM per la conservazione che supera i limiti di conservazione nativi.
• Configurare l'itinerario di controllo campi in modo che copra i campi Limitati per garantire che la conservazione soddisfi i minimi normativi.
• Mantenere punteggi del controllo dello stato della sicurezza pari o superiori all'80% (fascia Molto buono o Eccellente) e documentare eventuali eccezioni.
• Automatizzare la convalida della conformità per le pipeline CI/CD che si interrompono durante violazioni critiche.
• Implementare policy sulla sicurezza delle transazioni per il rilevamento e la risposta in tempo reale alle anomalie.

Ciclo di vita dello sviluppo sicuro

• Eseguire la modellazione delle minacce durante la fase di progettazione (prima di effettuare investimenti significativi nella creazione).
• Applicare CRUD/FLS in tutti gli ambienti Apex.
• Utilizzare l'imposizione automatica in modalità utente per l'API versione 67.0 o successiva, oppure utilizzare WITH USERMODE o stripInaccessible() per l'API versione 66.0 o precedente.
• Non utilizzare WITH SECURITYENFORCED, che è stato rimosso nell'API versione 67.0.
• Eseguire Salesforce Code Analyzer in CI/CD quando i risultati critici bloccano la distribuzione.
• Richiedere revisioni del codice da parte di revisori attenti alla sicurezza per tutte le modifiche di produzione.
• Eseguire test di penetrazione per tutte le applicazioni rivolte al pubblico e i siti Experience Cloud.
• Convalidare e disinfettare tutti gli input degli utenti che impediscono l'iniezione in contesti SOQL, SOSL e HTML.

Risposta agli incidenti di sicurezza

• Progettare regole di avviso di Monitoraggio evento per rilevare schemi sospetti tramite valori di riferimento comportamentali.
• Instradare i registri ad archivi esterni immutabili per la conservazione forense.
• Documentare e testare le procedure di risposta agli incidenti per scenari specifici della piattaforma.
• Eseguire revisioni post-incidente senza colpe con le ADR per acquisire miglioramenti architettonici.
• Tenere traccia delle metriche MTTD e MTTR per identificare i gap di rilevamento e risposta.

Condividere i propri commenti sul framework ben progettato.