Leggi qui le nostre pianificazioni degli aggiornamenti.

Un sistema sicuro protegge gli stakeholder e i dati di un'organizzazione. Le architetture protette verificano l'identità degli utenti, limitano l'accesso ai dati solo alle informazioni necessarie e impediscono la compromissione dei dati.

Salesforce assegna priorità al Customer Trust e alla sicurezza dei dati. Salesforce Platform garantisce privacy e sicurezza. Le informazioni in tempo reale sulle prestazioni del sistema e sulla sicurezza sono disponibili presso Salesforce Trust.

La protezione dei dati dell'organizzazione e dei clienti è alla base della creazione di soluzioni Salesforce sicure. L'architetto Salesforce è responsabile della protezione dei dati dell'organizzazione e dei clienti utilizzando le funzioni di protezione incorporate di Salesforce. Considerare la distribuzione geografica, il settore, le procedure operative aziendali e i tipi di dati dei clienti quando si prendono queste decisioni.

È possibile rendere le soluzioni più sicure concentrandosi su tre aree: sicurezza organizzativa, sicurezza delle sessioni e sicurezza dei dati.

La protezione dell'organizzazione protegge i sistemi dall'accesso non autorizzato assicurando che solo gli utenti convalidati e autorizzati possano accedere a un sistema e solo alle funzioni e ai dati necessari.

I segnali che indicano problemi di sicurezza organizzativa includono:

• Processi ad hoc per attivare o disattivare gli utenti
• Passaggi non chiari per aggiornare l'autorizzazione per le modifiche dei ruoli utente o di sistema
• Affidamento alle Knowledge istituzionali delle persone per le assegnazioni corrette della sicurezza degli utenti
• Mancato allineamento ai framework di sicurezza o alle procedure consigliate del settore
• Assenza di un framework di governance dei dati strutturato e di policy a supporto

È possibile creare controlli di sicurezza organizzativi migliori per le organizzazioni Salesforce concentrandosi sull'autenticazione e l'autorizzazione.

L'autenticazione è fondamentale per la sicurezza e la gestione degli accessi, verificando l'identità degli utenti che tentano di accedere al sistema. Questo vale sia per gli utenti umani (dipendenti, clienti) che per gli utenti automatizzati (sistemi esterni, integrazioni), con ogni tipo di utente che richiede schemi di autenticazione specifici. Per garantire un accesso sicuro in tutti i punti di ingresso Salesforce dell'organizzazione, è necessario impostare vari metodi di autenticazione.

Per creare flussi di autenticazione protetti in Salesforce:

• Creare utenti Salesforce in base alle persone, non ai profili. Le funzionalità di controllo incorporate di Salesforce sono più efficaci quando ogni account utente corrisponde a una singola persona che accede alla piattaforma. L'uso di account utente condivisi compromette l'efficacia di questi controlli, introduce ulteriori vulnerabilità di sicurezza, aumenta il potenziale impatto delle violazioni degli account e complica la capacità di creare schemi di autorizzazione efficaci. Sono inclusi gli account utente per gli utenti integrazione.
• Scenari di accesso protetti basati sull'interfaccia utente. La maggior parte degli utenti richiede un tipo di accesso basato sull'interfaccia utente (spesso chiamato accesso) per un'organizzazione Salesforce. Salesforce offre diversi livelli di protezione per questi scenari di accesso, tra cui:
  • Polizze sulle password. I criminali informatici spesso prendono di mira nomi utente e password per ottenere l'accesso non autorizzato alle applicazioni. Benché la configurazione dei criteri relativi alle password sia un passaggio fondamentale per proteggere l'accesso, è importante notare che questo da solo non è sufficiente, poiché Salesforce consente la sostituzione di questi criteri per utente.
  • Autenticazione a più fattori (MFA). Salesforce richiede la MFA per tutti gli accessi utente basati sull'interfaccia utente. La MFA fornisce una difesa essenziale contro le fughe di credenziali e gli attacchi brute-force richiedendo agli utenti di fornire un'ulteriore forma di identificazione, o fattore, dopo aver immesso correttamente il nome utente e la password. Questo fattore aggiuntivo assume in genere una forma fisica, ad esempio un dispositivo mobile, una chiave di protezione o un indicatore biometrico.
  • Single-sign on (SSO). Negli scenari SSO, gli utenti utilizzano un solo insieme di credenziali nelle applicazioni di un'organizzazione. L'accesso ai sistemi viene fornito e gestito da una posizione centrale, il che migliora la sicurezza. Salesforce può agire come fornitore di servizi o provider di identità negli scenari SSO. Assicurarsi di consentire ad alcuni o a tutti gli amministratori di accedere direttamente a Salesforce in modo che possano risolvere eventuali guasti o problemi nell'implementazione di SSO.
  • Fasi post-accesso. Per alcuni casi d'uso, potrebbe essere necessario eseguire ulteriori operazioni prima di accedere al sistema. È possibile implementare flussi di accesso personalizzati per guidare gli utenti in queste fasi aggiuntive del processo. Gli esempi includono:
    • Accettazione di termini e condizioni
    • Uso degli scenari di individuazione degli accessi e di accesso senza password
    • Limitazione del numero di sessioni Salesforce simultanee per utente per ridurre la probabilità di attacchi basati su sessioni (vedere Sicurezza delle sessioni).
    • Connessione ai servizi di geofencing
• Scenari di accesso sicuri basati su API. Qualsiasi utente può richiedere l'accesso basato su API per un'organizzazione Salesforce. Salesforce offre diversi livelli di protezione per gli scenari basati su API, tra cui:
  • Controllo accessi API. Senza il controllo accesso API, chiunque disponga di un insieme di credenziali valido può utilizzare qualsiasi app per connettersi all'organizzazione, anche se l'applicazione connessa non è distribuita nell'organizzazione. I controlli di accesso ai dati continueranno a essere applicati, ma gli utenti potrebbero accedere alle informazioni in modi non controllati. Ad esempio, un'app può essere utilizzata per scaricare grandi volumi di dati o persino per caricare informazioni danneggiate senza l'approvazione di un amministratore di sistema.
  • Autorizzazioni API Only. È possibile configurare le autorizzazioni utente Solo API in Salesforce. Assegnarlo come parte di un insieme di autorizzazioni a qualsiasi profilo utente automatico o di integrazione per bloccare completamente l'accesso basato sull'interfaccia utente.
  • Certificati e chiavi. Certificati e chiavi consentono a Salesforce di confermare che le richieste provengono da aziende o aziende autorizzate. Se si desidera utilizzare SSO con Salesforce, sarà necessario configurare certificati e chiavi.
  • Applicazioni connesse. La configurazione delle applicazioni connesse in Salesforce consente di controllare l'accesso a Salesforce da parte di sistemi esterni, inclusi i protocolli di autenticazione, l'ambito di autorizzazione e il comportamento della sessione richiesti in un'unica definizione.
  • Credenziali denominate. Le credenziali denominate consentono di controllare i punti di accesso esterni e i protocolli di autenticazione in un'unica definizione in Salesforce. Utilizzarli per definire e gestire in modo sicuro l'autenticazione per le chiamate da Apex, servizi esterni e fonti di dati Salesforce Connect.
• Autenticazione Agentforce Agent Users. Gli agenti Agentforce, basati su Salesforce, utilizzano oggetti utente-agente con autorizzazioni gestibili esattamente come quelle degli utenti reali. Quando si imposta un agente, allineare attentamente l'accesso al ruolo svolto dall'agente, limitando l'accesso ai dati solo a ciò che è necessario per servire gli utenti finali. Altrettanto importante, gli agenti possono essere configurati con azioni sia pubbliche che private. Per le azioni private, convalidare e autenticare gli utenti finali mappandoli al contesto dell'agente. Ciò consente all'agente di impersonare e operare all'interno dei controlli di accesso dell'utente finale, mantenendo sicurezza e Trust.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto dell'architettura di autenticazione corretta (e scadente) in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di autenticazione disponibili in Salesforce, vedere Strumenti pertinenti per la sicurezza.

L'autorizzazione definisce le caratteristiche, le funzionalità e i dati a cui un utente può accedere, nonché le azioni che può eseguire con tali risorse dopo l'autenticazione. I controlli di autorizzazione non sono destinati solo agli utenti umani, ma devono anche essere personalizzati per gli utenti Agentforce Agent, in particolare per gli agenti che forniscono servizi agli utenti finali non autenticati.

Anche se limitare gli utenti che possono eseguire l'autenticazione nell'organizzazione è un primo passo fondamentale, è altrettanto essenziale associare un'autenticazione forte a un'autorizzazione efficace. Senza controlli di autorizzazione adeguati, gli utenti potrebbero potenzialmente creare, modificare ed eliminare record o accedere alle funzionalità del sistema in modi dannosi per l'azienda e gli stakeholder. Un controllo delle autorizzazioni inadeguato può anche rendere i sistemi più difficili da utilizzare. Controllando ciò che gli utenti possono fare all'interno del sistema, si alimentano livelli più elevati di Trust, salvaguardando sia il sistema che gli utenti.

Per creare schemi di autorizzazione sicuri per Salesforce:

• Seguire il principio dei minimi privilegi. Applicare il principio dei privilegi minimi assegnando agli utenti solo le autorizzazioni necessarie per le loro operazioni. Per seguire questo principio, progettare insiemi di autorizzazioni granulari e modulari. Ciò consente sofisticati controlli degli accessi tramite gruppi di insiemi di autorizzazioni, consentendo una gestione precisa delle autorizzazioni, inclusa la possibilità di silenziare, impostare date di scadenza e altro ancora. Allineare le unità funzionali dei sistemi alle funzionalità aziendali per definire autorizzazioni granulari e gruppi di insiemi di autorizzazioni efficaci. Ricordare che le autorizzazioni si applicano all'accesso ai metadati in Salesforce. Per informazioni dettagliate sulla configurazione dell'accesso ai dati PoLP per Salesforce, vedere Condivisione e visibilità.
• Pensare all'accesso degli utenti in termini di profili, non di singoli. Pensando all'autorizzazione (o alla sicurezza in generale) in termini di singoli utenti non si imposta il sistema per scalare ed evolvere. Progettare e gestire invece profili che rappresentano gruppi di utenti. Le soluzioni Salesforce sicure utilizzano le persone per l'autenticazione e i profili per l'autorizzazione. Definendo configurazioni di sicurezza per profili distinti, si ottiene un controllo granulare sull'accesso e i privilegi nel modello di sicurezza, riducendo al minimo la necessità di refactoring nel lungo periodo. Includere i profili di sicurezza definiti negli standard di progettazione.
• Controllare l'accesso degli utenti ai metadati utilizzando gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni. Gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni determinano a quali metadati gli utenti possono accedere e cosa possono fare con tali metadati. Per ulteriori informazioni sui metadati Salesforce, vedere Metadati e dati. Configurare le assegnazioni delle app, le attivazioni delle licenze funzioni, l'accesso ai pacchetti gestiti, le autorizzazioni di sistema, l'accesso CRUD e l'accesso a livello di campo tramite gli insiemi di autorizzazioni e i gruppi di insiemi di autorizzazioni. Includere questo accesso negli standard di progettazione.
• Utilizzare le impostazioni predefinite dell'organizzazione (OWD) e la condivisione per controllare l'accesso ai dati per gli utenti. Dati e metadati sono entità distinte in Salesforce, che richiedono controlli di accesso separati per ciascuna entità. Utilizzare OWD e strumenti di condivisione integrati per configurare l'accesso ai dati Salesforce (singoli record, file e documenti). Per ulteriori dettagli, vedere Sicurezza dei dati.
• Utilizzare gli ambiti OAuth per controllare l'accesso per le applicazioni connesse. Quando si configura un'applicazione connessa, si definisce l'ambito o le autorizzazioni di accesso degli utenti dell'applicazione alle risorse Salesforce. Per ulteriori informazioni sulla gestione dei token OAuth, vedere Gestione delle sessioni.
• Creare un utente Salesforce per ogni integrazione. Per rispettare il principio dei privilegi minimi, creare un utente integrazione Salesforce univoco per ogni integrazione. Ciò consente di assegnare un accesso specifico ai dati, migliorando il controllo sulle operazioni, garantendo la tracciabilità delle transazioni e riducendo al minimo l'impatto di potenziali violazioni della sicurezza.
• Implementare account univoci con PoLP per tutti gli utenti Agente. Ogni utente Agentforce Agent deve essere univoco e non riutilizzato in più agenti. Le autorizzazioni per questi account devono rispettare rigorosamente il principio dei privilegi minimi. Tenere presente che le azioni eseguite da un utente agente possono operare in un contesto di sicurezza elevata all'interno di Salesforce o contro sistemi esterni che non rispettano i controlli di accesso di Salesforce. Ciò potrebbe portare ad azioni che accedono o rivelano informazioni sensibili agli utenti.
• Ridurre al minimo l'uso dei profili e migrare eventuali controlli di accesso dai profili. I profili consentono di limitare l'accesso agli intervalli IP di accesso, agli orari di accesso e alle funzioni specifiche dell'interfaccia utente Salesforce Classic legacy (in particolare i tipi di record predefiniti e le assegnazioni dei layout di pagina). Tutte le altre funzionalità attualmente presenti nei profili devono essere migrate a funzionalità equivalenti negli insiemi di autorizzazioni e nei gruppi di insiemi di autorizzazioni. Le funzionalità dei profili collegate alle funzioni dell'interfaccia utente di Salesforce Classic devono essere oggetto di correzione.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto delle procedure di autorizzazione appropriate (e scadenti) in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di autorizzazione disponibili in Salesforce, vedere Strumenti rilevanti per la sicurezza.

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza organizzativa in Pattern & Anti-Pattern Explorer.

Una sessione è la serie di richieste e risposte associate a un utente in un periodo di tempo. Una sessione viene avviata quando un utente esegue correttamente l'autenticazione in Salesforce. La sicurezza della sessione è la procedura di configurazione del sistema per impedire l'accesso non autorizzato e le violazioni dei dati ostacolando le interferenze o gli attacchi hijack della sessione.

Tutte le attività degli utenti nel sistema avvengono nel contesto di una sessione, quindi è fondamentale tenere conto di come vengono avviate le sessioni, di cosa può avvenire durante una sessione, dei dispositivi che gli utenti utilizzeranno (e dovrebbero) e di come rilevare e rispondere ai comportamenti sospetti o anomali della sessione.

È possibile creare la sicurezza delle sessioni in Salesforce concentrandosi su tre chiavi: gestione delle sessioni, accesso ai dispositivi e rilevamento e risposta alle minacce.

Le sessioni vengono avviate quando un utente esegue correttamente l'autenticazione e ottiene l'accesso a Salesforce. Queste sessioni consentono alla piattaforma di associare richieste e risposte specifiche a quel determinato utente.

Il protocollo HTTPS facilita la comunicazione tra un client front-end e Salesforce Platform. I client possono includere browser, applicazioni mobili, applicazioni locali e così via. HTTPS è un protocollo stateless, ovvero ogni comunicazione è discreta e non correlata a comunicazioni precedenti o future.

Questo approccio stateless accelera le comunicazioni di rete ed elimina gli errori causati dall'interruzione dei link tra i pacchetti. Tuttavia, le app Web necessitano ancora di un modo per tenere traccia dell'identità di ogni utente e di altre informazioni correlate in più interazioni di richiesta e risposta. Salesforce, come la maggior parte delle applicazioni Web, esegue questa operazione utilizzando sessioni e token.

• Le sessioni consentono a Salesforce di associare richieste e risposte agli utenti. Dopo che un utente è stato autenticato, la piattaforma invia di nuovo un ID sessione all'app client, che include questo ID con tutte le richieste dell'utente (ad esempio navigazione, ricerca e invio di dati).
• I token consentono agli utenti e alle applicazioni connesse di verificare la propria identità una sola volta e di utilizzare un token di accesso univoco da quel momento in poi. I token hanno una durata limitata e forniscono l'accesso solo a risorse specifiche (vedere Autorizzazione per ulteriori informazioni sulla configurazione dei livelli di accesso). I token consentono l'accesso alle risorse autorizzate senza richiedere agli utenti di eseguire l'accesso.

Se le sessioni e i token non sono protetti correttamente, i malintenzionati possono potenzialmente interferire con loro e impersonare gli utenti o eseguire codice dannoso nel sistema.

Per creare una gestione sicura delle sessioni per Salesforce:

• Informazioni su come Salesforce classifica i tipi di sessione. Identificare e mappare i tipi di sessione approvati ai profili utente di sicurezza e registrarli nella documentazione.
• Controllare come possono avere origine le sessioni e dove può andare il traffico della sessione. Dopo aver identificato i tipi di sessioni che i vari profili utente possono avviare, configurare i controlli per bloccare le sessioni originate da fonti o contesti non approvati. Salesforce offre diversi modi per controllare le origini delle sessioni e il traffico, tra cui:
  • Protezione sessione incorporata. Salesforce abilita automaticamente le protezioni a livello di organizzazione per le attività dannose basate su sessioni, tra cui cross-site scripting, contraffazione di richieste tra siti, sniffing di contenuti, clickjacking e altro ancora. Queste protezioni non devono mai essere disabilitate; alcune non possono essere disabilitate.
  • Domini e intervalli IP. Per impostazione predefinita, in tutte le organizzazioni Salesforce è abilitato Dominio personale, il che crea un sottodominio specifico dell'azienda per l'accesso a Salesforce. È possibile personalizzare o modificare il nome associato a un'organizzazione tramite Dominio personale. Inoltre, Salesforce supporta configurazioni di dominio aggiuntive per i siti Experience Cloud e altre pagine di applicazioni. Nota: Se gli utenti devono accedere a Salesforce da un firewall aziendale, aggiungere i domini richiesti agli elenchi consentiti del firewall. È possibile impostare intervalli IP di accesso e intervalli IP affidabili per controllare l'accesso in entrata e le richieste di sessione a Salesforce.
  • Orari di accesso. Se alcuni profili utente hanno impostato orari di lavoro, è possibile limitare la loro possibilità di accedere a Salesforce al di fuori degli orari di accesso definiti.
• Controllare le attività che richiedono una maggiore protezione a livello di sessione. Per impostazione predefinita, le sessioni possono avere due tipi di livelli di sicurezza: standard e high assurance. Utilizzare questi livelli di sicurezza per controllare in che modo gli utenti possono e non possono svolgere attività come accedere a rapporti e cruscotti digitali o gestire le configurazioni di sicurezza in un'organizzazione Salesforce. Le policy di protezione a livello di sessione possono richiedere agli utenti di stabilire sessioni High Assurance per eseguire operazioni o impedire agli utenti di eseguire operazioni sensibili.
• Controllare le attività che richiedono autorizzazioni aggiuntive basate su sessioni. Salesforce supporta le attivazioni delle autorizzazioni basate su sessioni per consentire temporaneamente agli utenti un'autorizzazione o un accesso elevati alle autorizzazioni durante una determinata sessione. Le autorizzazioni basate su sessioni si possono attivare e disattivare tramite le API Flusso o Salesforce.
• Gestire le sessioni utente inattive durante i timeout. La fine delle sessioni inattive è una parte fondamentale della gestione della sicurezza delle sessioni. Ciò consente di proteggere il sistema quando, ad esempio, un utente lascia aperta una sessione Salesforce in una scheda del browser ma sta lavorando attivamente in un'altra applicazione, oppure quando il dispositivo mobile di un utente è connesso a Salesforce ma non è sorvegliato. Salesforce ha un timeout di inattività sessione predefinito di due ore. È possibile aumentare o ridurre i livelli di timeout di inattività della sessione, ma l'aumento dei timeout deve essere eseguito solo con una giustificazione convincente e ben documentata.
• Gestire le sessioni dell'applicazione connessa tramite la configurazione del token. Quando si configura un'applicazione connessa, si definisce anche l'ambito, o il livello di autorizzazione, che verrà concesso agli utenti che accedono a Salesforce tramite l'applicazione connessa. Questo ambito viene applicato a livello di sessione tramite i token OAuth, che vengono emessi dopo che un utente di un'applicazione connessa esegue correttamente l'autenticazione. È possibile controllare la durata di un token tramite le politiche di aggiornamento. Se necessario, gli amministratori dell'organizzazione possono revocare manualmente i token per utente e per organizzazione.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto corretto (e inadeguato) della gestione delle sessioni in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di gestione delle sessioni disponibili in Salesforce, vedere Strumenti rilevanti per la sicurezza.

Nel contesto attuale, un dispositivo è qualsiasi apparecchiatura elettronica che un individuo utilizzerà per accedere a Salesforce, ad esempio una workstation desktop, un laptop, un tablet o un telefono cellulare.

I dispositivi portatili offrono agli utenti la flessibilità di accedere a Salesforce da qualsiasi posizione. Tuttavia, questa comodità potenzialmente introduce ulteriori vettori di attacco per gli attori malintenzionati. Questi vettori di minacce vanno da semplici tattiche, come la navigazione a spalla in un luogo pubblico per rubare le credenziali, a metodi più sofisticati come l'installazione di malware su un dispositivo o la creazione di una rete Wi-Fi pubblica fasulla per intercettare le trasmissioni di dati. Per questo motivo, proteggere i dispositivi, in particolare i dispositivi portatili, è essenziale per la sicurezza generale del sistema.

Per proteggere l'accesso ai dispositivi per Salesforce:

• Utilizzare le soluzioni dell'app mobile fornite da Salesforce. Chiedere agli utenti dei dispositivi mobili che devono accedere a Salesforce di utilizzare le app Salesforce ufficiali. Se le esigenze aziendali richiedono una soluzione mobile personalizzata, è necessario utilizzare Salesforce Mobile SDK, che fornisce metodi per l'autenticazione e l'autorizzazione sicure.
• Progettare l'utilizzo dei dispositivi mobili nella gestione delle sessioni. I livelli di sicurezza delle sessioni, i timeout delle sessioni e altri controlli del contesto della sessione devono tenere conto di qualsiasi accesso previsto da parte degli utenti sui dispositivi mobili. Considerare quali dispositivi devono e non devono essere autorizzati ad accedere a Salesforce e quali tipi di utenti devono avere accesso alle sessioni mobili. Includere gli standard di accesso mobile nella documentazione del profilo di sicurezza. Per ulteriori informazioni su questo argomento, vedere Gestione delle sessioni.
• Integrazione della protezione a livello di dispositivo con la tecnologia MDM (Mobile Device Management). Le app Salesforce per iOS e Android sono compatibili con molte suite MDM. È possibile configurare ulteriori controlli di accesso per l'app Salesforce sui dispositivi degli utenti tramite la soluzione MDM preferita.
• Integrare la protezione a livello di app con la tecnologia MAM (Mobile Application Management). La tecnologia MAM supporta i controlli a livello di app sui dispositivi mobili. Salesforce offre un componente aggiuntivo MAM a pagamento per le app mobili Salesforce.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto di una corretta (e scarsa) gestione dei dispositivi in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di gestione dei dispositivi disponibili in Salesforce, vedere Strumenti rilevanti per la sicurezza.

Il rilevamento delle minacce è il processo di identificazione degli schemi di comportamento nel sistema che possono indicare attività dannose. Ciò può includere volumi di dati scaricati superiori alla media o la modifica da parte di un utente di campi contenenti dati sensibili su più record in un periodo di tempo inferiore alla media. Le risposte alle minacce possono includere la scadenza automatica delle sessioni, avvisi e altre notifiche.

L'obiettivo del rilevamento delle minacce è identificare e rispondere ai potenziali problemi il più rapidamente possibile. L'esecuzione di azioni basate sul rilevamento delle minacce in tempo reale può arrestare i comportamenti dannosi. Salesforce offre il monitoraggio evento in tempo reale come componente aggiuntivo o come parte di Salesforce Shield. Utilizzare una di queste soluzioni se si dispone di applicazioni estremamente sensibili o se sono necessarie solide funzionalità di rilevamento delle minacce e risposta in tempo reale.

Per creare una strategia efficace di rilevamento e risposta alle minacce per le soluzioni Salesforce:

• Utilizzare funzionalità di controllo incorporate. Salesforce offre una varietà di strumenti integrati per monitorare e controllare le modifiche apportate all'organizzazione. Ad esempio, l'itinerario di controllo consente di visualizzare la cronologia di controllo delle azioni amministrative. Salesforce tiene traccia delle modifiche a livello di campo per un periodo di tempo limitato per impostazione predefinita, ma è possibile attivare il Tracciamento cronologia campi per visualizzare le modifiche dei campi per un massimo di 18 mesi nell'interfaccia utente e fino a 24 mesi tramite l'API. Inoltre, è possibile attivare l'itinerario di controllo per conservare una cronologia di controllo per le modifiche a livello di campo a tempo indeterminato (fino a quando non si eliminano manualmente i dati).
• Stabilire revisioni periodiche. Il controllo è fondamentale per identificare le modifiche anomale che il rilevamento delle minacce in tempo reale potrebbe non rilevare. Si supponga uno scenario in cui un utente con accesso legittimo elimina costantemente un numero limitato di record al giorno per un periodo prolungato. Poiché questo utente dispone di credenziali di accesso valide, dell'autorizzazione appropriata per eliminare i record e non elimina un volume elevato di record contemporaneamente, è improbabile che l'attività venga rilevata come una minaccia in tempo reale. Tuttavia, un team di audit che esamina i rapporti sulle attività degli utenti identificherebbe chiaramente questa tendenza all'eliminazione eccessiva dei record da parte di un singolo utente nel tempo, rendendo più semplice la gestione. Nell'ambito delle politiche di governance, stabilire intervalli regolari per il controllo della cronologia accessi, dell'attività delle sessioni utente e dell'utilizzo delle applicazioni connesse.
• Sviluppare una strategia di risposta alle minacce e includerla nelle policy di sicurezza. Creare una strategia di risposta alle minacce che copra:
  • Definizioni dei tipi di risposta alle minacce (ad esempio, avvisi e automazioni) ed eventuali gruppi di stakeholder. Per ulteriori informazioni sulla progettazione di messaggi o avvisi, vedere Errori e notifiche.
  • Categorie specifiche per le modifiche in tempo reale o le attività che potrebbero essere considerate minacce e il tipo di risposta associato per ciascuna
  • Elenco chiaro di tutte le risposte alle minacce automatiche (ad esempio revoca dei token, chiusura delle sessioni, disattivazione degli account utente o blocco dell'accesso alle risorse) e dei trigger di automazione

Monitoraggio evento fornisce i dati necessari per applicare questo principio abilitando il rilevamento e la risposta alle minacce in tempo reale. La sicurezza delle transazioni applica le azioni della società basate sulle policy e i tipi di evento supportano il monitoraggio dell'accesso di utenti e applicazioni nel tempo.

Il servizio di rilevamento delle minacce nativo di Salesforce utilizza modelli statistici e di machine learning per identificare comportamenti sospetti. Questo servizio genera eventi specifici che proteggono dagli attacchi informatici e dall'accesso ai dati sospetto.

La sicurezza delle transazioni migliora ulteriormente la sicurezza poiché offre un framework che intercetta gli eventi chiave che si verificano nell'organizzazione e applica le azioni della società basate sulle policy. Questo trasforma Monitoraggio evento da strumento di registrazione a componente importante di una difesa della sicurezza automatica.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto corretto (e scarso) del rilevamento e della risposta alle minacce in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di rilevamento delle minacce, di avviso e di automazione della risposta disponibili in Salesforce, vedere Strumenti rilevanti per la sicurezza.

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza delle sessioni in Pattern & Anti-Pattern Explorer.

La sicurezza dei dati è la procedura di protezione dei dati da accesso non autorizzato, corruzione o eliminazione involontaria. La sicurezza dei dati consiste nella protezione dei dati sia in transito che a riposo.

Una forte sicurezza dei dati riduce al minimo i rischi e i potenziali danni derivanti dall'accesso non autorizzato al sistema. Una sicurezza dei dati inadeguata rende i sistemi vulnerabili alle violazioni dei dati, che possono avere un impatto grave sui clienti e sulla società. Pertanto, proteggere i dati è fondamentale per creare architetture sicure.

Il miglioramento della sicurezza dei dati inizia con una chiara comprensione di ciò che sono considerati dati in Salesforce, insieme alla loro classificazione. I singoli record, file e documenti archiviati in un'organizzazione Salesforce sono i relativi dati. Per ulteriori informazioni sulla distinzione tra metadati e dati, vedere Nozioni di base sull'architettura Salesforce.

È possibile rafforzare la sicurezza dei dati nelle soluzioni Salesforce concentrandosi sulla condivisione e la visibilità nonché sull'uso della crittografia.

Nota: Quando si progetta per la sicurezza dei dati, assicurarsi di tenere conto della privacy dei dati, nonché dell'archiviazione e della rimozione, poiché entrambi questi concetti influiscono sulla sicurezza dei dati complessiva delle soluzioni.

Identificare e classificare tutti i dati memorizzati nella piattaforma Salesforce in base alla loro riservatezza (ad esempio, pubblica, interna, riservata, limitata). Definire una politica di classificazione chiara che descriva come gestire e proteggere ogni tipo di dati. Implementare controlli di sicurezza appropriati, ad esempio protezione a livello di campo, crittografia e mascheramento dei dati, per applicare la policy e proteggere i dati sensibili da accessi o esposizioni non autorizzate. Esaminare e controllare regolarmente queste classificazioni e questi controlli per assicurarsi che rimangano in linea con i requisiti aziendali e di conformità.

La condivisione e la visibilità includono la configurazione del sistema per controllare il modo in cui gli utenti accedono ai dati all'interno di Salesforce. È importante notare che la condivisione e la visibilità controllano i singoli record a cui un utente può accedere, ma queste impostazioni da sole non controllano in ultima analisi cosa può fare un utente con un determinato record o quali campi specifici all'interno di quel record sono visibili. Le autorizzazioni per eseguire operazioni sui dati (ad esempio CRUD) vengono assegnate agli utenti tramite controlli di accesso ai metadati, che possono essere configurati per un utente a livello di singolo oggetto e campo. Per ulteriori informazioni, vedere Autorizzazione.

Le azioni Agentforce possono esporre i dati sia agli utenti autenticati che a quelli anonimi che in genere non dispongono di accesso diretto. Durante la creazione degli agenti Agentforce, considerare attentamente e documentare tutte le azioni assegnate all'agente. Per ogni azione è necessario comprendere:

• A quali dati possono accedere le azioni.
• Contesto di sicurezza in cui vengono eseguite le azioni.
• Indica se le azioni dispongono del recupero Knowledge o di altre funzionalità che possono incorporare dati sensibili o limitati nella sessione dell'agente.

Per configurare condivisione e visibilità efficaci in Salesforce:

• Progettare l'accesso in base a funzioni lavorative significative. Creare una matrice di protezione che mappa i profili utente alle funzioni aziendali che devono svolgere. Utilizzare questo modello come base per progettare la condivisione e la visibilità. Per ulteriori informazioni sull'identificazione di funzioni aziendali significative, vedere Unità funzionali.
• Scegliere il percorso più semplice per applicare il principio dei minimi privilegi. Quando si applica il principio dei minimi privilegi nella progettazione di schemi di condivisione e visibilità, farlo nel modo più semplice. Evitare restrizioni dei dati e schemi di condivisione eccessivamente ingegnerizzati, che possono causare problemi a valle per la manutenibilità, la scalabilità e l'adattabilità del sistema. Sfruttare invece la condivisione dati flessibile per configurare regole precise per l'accesso degli utenti a livello di dati.
• Impostare le impostazioni predefinite interne dell'organizzazione su Sola lettura pubblica, a meno che l'azienda non tratti dati sensibili, quindi utilizzare Privato. Gli OWD controllano il livello di privilegi "minimi" che gli utenti avranno a livello di dati. Non è possibile limitare l'accesso al di sotto del livello di OWD. Benché gli OWD privati possano sembrare ideali in ogni caso d'uso, gli utenti di tutta l'azienda spesso possono finire per replicare inavvertitamente un OWD più permissivo attraverso schemi di condivisione complessi. Inoltre, gli OWD privati possono causare la creazione di dati duplicati da parte degli utenti. Il completamento dei calcoli di condivisione (e dei ricalcoli) può richiedere una notevole quantità di tempo a seconda del volume di dati e della distorsione controllante-controllato o della proprietà. È importante notare che le OWD non controllano le autorizzazioni CRUD e la visibilità a livello di campo. Scegliere un OWD di Privato solo quando è giustificato dalle esigenze aziendali: il più delle volte, tali giustificazioni saranno correlate alla conformità.
• Impostare le impostazioni predefinite esterne dell'organizzazione su Privato, a meno che non si disponga di un valido motivo aziendale per consentire un accesso più ampio. Gli OWD esterni si applicano agli utenti che accedono ai dati Salesforce da siti Experience Cloud, portali e così via. Ciò consente di configurare basi di riferimento OWD separate per gli utenti interni ed esterni, per consentire diversi tipi di privilegi "minimi". Impostare sempre OWD per gli utenti esterni su Privato: le eccezioni per un livello più aperto devono essere chiaramente giustificate dalle esigenze aziendali.

L'elenco degli schemi e antischemi riportato di seguito mostra l'aspetto corretto (e scarso) della condivisione e della visibilità in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di condivisione e visibilità di Salesforce, vedere Strumenti rilevanti per la sicurezza.

La crittografia converte i dati leggibili in un formato codificato indecifrabile. I dati crittografati possono essere decrittografati o riportati al formato originale tramite una chiave. Di conseguenza, la crittografia è uno dei metodi più efficaci per proteggere i dati sia a riposo che in transito, assicurando che anche se parti non autorizzate accedono ai dati, saranno illeggibili.

Per progettare un uso corretto della crittografia nelle soluzioni Salesforce:

• Crittografia sempre adeguata dei dati in transito. Salesforce impiega Transport Layer Security (TLS) per tutte le sessioni che si svolgono in un browser supportato da Salesforce e richiede che le chiamate in uscita che utilizzano HTTPS soddisfino standard di sicurezza specifici. Le API piattaforma utilizzano anche HTTPS per impostazione predefinita. Inoltre, i dati inviati tra un sito Experience Cloud Salesforce o un portale e la relativa organizzazione Salesforce vengono crittografati in transito per impostazione predefinita. Se si utilizzano i servizi email integrati di Salesforce, esistono livelli predefiniti per la sicurezza degli strati di trasporto (TLS) utilizzata da Salesforce per inviare e tentare la consegna. È necessario, come minimo, assicurarsi che le impostazioni dell'organizzazione non siano inferiori a quelle predefinite, a meno che non si disponga di una chiara giustificazione aziendale. In base alla classificazione e alla riservatezza dei dati, valutare la possibilità di utilizzare una connessione di rete privata a Salesforce tramite AWS Direct Connect o Salesforce Private Connect. Ciò garantisce che i dati non attraversino Internet pubblico, ma fluiscano in modo sicuro su una connessione di rete privata sia per l'accesso degli utenti che per le integrazioni.
• Se l'azienda lo richiede, crittografare i dati a riposo. Salesforce offre diversi modi per crittografare i dati a riposo.
  • Hyperforce. I dati vengono crittografati a riposo nelle organizzazioni che utilizzano Hyperforce. La crittografia è gestita per l'organizzazione da Salesforce. Non è possibile creare (o distruggere) le proprie chiavi di crittografia.
  • Salesforce Shield. Salesforce Shield consente di crittografare i dati a riposo in un'organizzazione Salesforce a livelli aggiuntivi, inclusi i livelli applicazione e database. Con Shield si dispone di funzionalità di gestione complete per le chiavi di crittografia del tenant, incluse le potenti opzioni "Bring Your Own Key" (BYOK). È anche possibile crittografare dati non strutturati (inclusi file, allegati, indici di ricerca ed eventi). Le istanze basate su Hyperforce offrono l'opzione di utilizzare un gestore chiavi esterno, che consente di utilizzare il proprio KMS AWS. Con questa funzionalità si mantiene il controllo completo sulle chiavi di crittografia all'interno del KMS utilizzate per crittografare e decrittografare i dati archiviati in Salesforce, rafforzando la sicurezza e allineandosi ai requisiti di conformità dell'organizzazione.

L'elenco di schemi e antischemi riportato di seguito mostra l'aspetto di un uso corretto (e errato) della crittografia in un'organizzazione Salesforce. Utilizzarli per convalidare i progetti prima di crearli o identificare opportunità per ulteriori miglioramenti.

Per ulteriori informazioni sugli strumenti di crittografia disponibili in Salesforce, vedere Strumenti rilevanti per la sicurezza.

Questa tabella mostra una selezione di schemi da cercare (o creare) nell'organizzazione e di schemi anti-schemi da evitare o a cui indirizzare la correzione.

✨ Scopri altri schemi per la sicurezza dei dati in Pattern & Anti-Pattern Explorer.

Aiutaci a mantenere Salesforce Well-Architected pertinente per te; partecipa al nostro sondaggio per fornire un feedback su questo contenuto e dirci cosa vorresti vedere dopo.