Proteggere i dati dei clienti e delle operazioni aziendali all’interno del CRM non è più un’opzione, ma un requisito fondamentale. Ogni record, contatto e opportunità commerciale racchiude informazioni sensibili la cui esposizione può causare danni reputazionali, sanzioni normative e perdite finanziarie significative. La domanda cruciale per ogni Responsabile IT, Compliance Officer o titolare d’azienda è: il nostro CRM è veramente al sicuro sia quando i dati sono “fermi” nel database sia quando viaggiano in rete?.

I moderni sistemi CRM, inclusi quelli basati su Microsoft Dynamics 365, implementano meccanismi di crittografia sofisticati. Tuttavia, comprendere la differenza tra crittografia at rest (dei dati a riposo) e crittografia in transit (dei dati in movimento), sapere come sono gestite le chiavi crittografiche e verificare il livello di protezione effettivo sono competenze essenziali per non scoprire vulnerabilità solo dopo un incidente.

In questo articolo, esploreremo in modo pratico e concreto come funziona la protezione dei dati nel CRM. Non ci addentreremo in tecnicismi inutili, ma ti forniremo una mappa chiara degli strumenti a tua disposizione, dei passaggi operativi per attivarli o verificarli, e delle implicazioni in termini di compliance (ad esempio verso normative come il GDPR o la NIS2). Affronteremo sia gli aspetti tecnicigestiti dal provider cloud sia le responsabilità che rimangono in capo alla tua organizzazione.

Prima di procedere, è utile fare un rapido <autovalutazione sulla maturità della sicurezza del tuo CRM>. Scopri subito se stai già coprendo le basi critiche con la nostra Checklist Gratuita: I 5 Pilastri della Crittografia CRM. Scaricala ora per identificare le priorità d’azione nel tuo contesto specifico.

[SOFT CTA: Scarica la Checklist Gratuita “I 5 Pilastri della Crittografia CRM”]

Introduzione: Perché Crittografare i Dati del CRM Non è più un’Opzione

I dati del tuo CRM non sono solo informazioni: sono il patrimonio strategico della tua organizzazione. Clienti, contratti, progetti, comunicazioni riservate. Lasciarli senza protezione adeguata oggi significa esporsi a due rischi concreti: violazioni di sicurezza costose e sanzioni regulatory per mancata conformità. Le normative come GDPR e NIS2 non sono più linee guida, ma obblighi stringenti che impongono la cifratura sia in transito che a riposo.

Non si tratta più di “se” crittografare, ma “come” farlo in modo efficace e gestibile. La crittografia dei dati nel CRM protegge le informazioni quando vengono archiviate sul server (a riposo) e durante il trasferimento tra dispositivi e datacenter (in transito). Piattaforme come Microsoft Dynamics 365 implementano standard come TLS 1.2 per le connessioni e Transparent Data Encryption (TDE) a livello di database, ma attivare e gestire correttamente queste funzionalità richiede competenze specifiche.

In questo articolo ti guidiamo oltre la teoria. Ti mostriamo nel concreto come implementare e governare la crittografia nel tuo CRM, quali sono i passaggi obbligatori, le implicazioni operative e come evitare errori comuni che possono compromettere l’efficacia della protezione o addirittura bloccarti l’accesso ai dati.

Prima di procedere, scarica la nostra checklist gratuita per valutare lo stato attuale della sicurezza dei dati nel tuo CRM e identificare le priorità d’azione immediate.

Il CRM come Tesoro Digitale e bersaglio privilegiato

Nei sistemi CRM sono custoditi i dati più sensibili dell’azienda: dall’elenco clienti con contatti e preferenze, alle offerte commerciali in corso, fino alle comunicazioni riservate e ai documenti finanziari. Per un cybercriminale, accedere a un CRM significa ottenere un colpo completo: identità, strategie e volumi di affari. Una violazione non è solo un rischio tecnologico, ma un evento che mina la fiducia dei clienti e può innescare sanzioni pesanti per violazione del GDPR o dei requisiti NIS2. Per questo, il CRM non è un semplice database: è il tesoro digitale dell’azienda e va protetto con le stesse armi di una banca.

Il costo della non-crittografia: violazioni, multe e perdita di fiducia

Omettere la crittografia dei dati in un CRM non è solo un gap tecnico: è un rischio finanziario e reputazionale concreto. Una violazione di dati può costare a un’organizzazione milioni in risposta all’incidente, risarcimenti, e attività di ripristino. Le normative come GDPR e NIS2 prevedono sanzioni amministrative che possono raggiungere importi significativi, fino a una percentuale del fatturato globale annuo. A questi costi diretti si aggiunge il danno involontario ma devastante alla fiducia di clienti e partner. La perdita di credibilità, una volta compromessa, richiede anni per essere recuperata e può tradursi in un calo di fatturato difficilmente quantificabile.

Fondamenti di Crittografia per il CRM: At Rest vs. In Transit

La crittografia nei sistemi CRM come Microsoft Dynamics 365 non è un’opzione, ma una necessità strategica per proteggere i dati aziendali. Comprendere la distinzione tra dati “in transito” e “a riposo” (at rest) è il primo passo per implementare una sicurezza efficace.

I dati in transito sono informazioni che viaggiano tra dispositivi e server, come quando un utente accede al CRM via browser o quando i dati sincronizzano tra applicazioni. La loro vulnerabilità principale è l’intercettazione durante il trasferimento. Perimetrarli significa cifrare il canale di comunicazione. Dynamics 365, ad esempio, utilizza il protocollo TLS 1.2 (Transport Layer Security) per tutte le connessioni, garantendo che i dati siano illeggibili se intercettati in rete.

I dati at rest, invece, sono quelli archiviati in modo permanente su dischi, database o backup. Sono bersagli principalmente per accessi non autorizzati al database o furti di supporti fisici. Dynamics 365 applica due livelli di protezione:

• Transparent Data Encryption (TDE): cifra l’intero database SQL Server in tempo reale, proteggendo i file di dati e di log. È attiva per default nelle istanze online.
• Crittografia a livello di campo (Field-level): cifra selettivamente attributi specifici contenenti informazioni sensibili (es. password di integrazione email), utilizzando lo standard FIPS 140-2. Questa è gestibile dall’amministratore in Impostazioni > Gestione dati > Crittografia dati.

L’implementazione pratica richiede attenzione: la crittografia a livello di campo va attivata manualmente (nelle versioni on-premise) e, una volta attivata, non può essere disattivata. Inoltre, presenta limitazioni note: i campi crittografati non possono essere indicizzati, personalizzati o sottoposti ad auditing.

Checklist operativa minima:

• Verifica che tutti gli accessi al CRM avvengano esclusivamente via HTTPS/SSL.
• Se utilizzi Dynamics 365 on-premise, accertati che la crittografia dei dati sia attiva.
• Per i campi che archiviano credenziali (es. profili server email), valuta se la crittografia a livello di campo è applicata.
• Documenta e conserva in luogo sicuro la chiave di crittografia, necessaria per operazioni di ripristino.

Implementare entrambi gli strati di protezione – in transito e at rest – crea un framework di difesa in profondità, essenziale per soddisfare requisiti di compliance come il GDPR e ridurre la superficie d’attacco.

Crittografia ‘In Transit’: Proteggere i dati in movimento

La crittografia in transit protegge i dati mentre si muovono tra device e server, ad esempio durante l’accesso web al CRM, l’invio di email o le chiamate API. Un canale non cifrato è vulnerabile a intercettazioni (man-in-the-middle). Lo standard consolidato è TLS (Transport Layer Security), versione 1.2 o superiore. Per Dynamics 365 Online, tutte le connessioni pubbliche sono obbligatoriamente cifrate tramite TLS, garantendo confidenzialità e integrità dei pacchetti. Per implementazioni on-premise, è configurabile ma fortemente consigliato attivarlo e imporlo via policy. L’uso esclusivo di HTTPS è un requisito base, spesso rafforzato Mutual TLS per scenari ad alto rischio. Un check operativo immediato: verificare che nessuna risorsa del CRM sia reachable via HTTP. Una configurazione corretta TLS include cifrari robusti, gestione sicura dei certificati e disattivazione di protocolli obsoleti.

• Verifica obbligatoria: Tutte le URL di accesso utente devono reindirizzare forzatamente a HTTPS.
• Configura server: Nel web server (IIS/Apache), disabilitare SSL 3.0/TLS 1.0/1.1 e abilitare solo TLS 1.2/1.3 con cifrari consigliati.
• Test: Usare tool online (es. SSL Labs) per scannerizzare l’endpoint del CRM e attestare la conformità.

Crittografia ‘At Rest’: Proteggere i dati a riposo

Crittografia ‘At Rest’: Proteggere i dati a riposo

Quando i dati sono archiviati su disco (database, backup, file system), sono definiti “at rest”. Per Dynamics 365/CRM, la protezione primaria è affidata a SQL Server Transparent Data Encryption (TDE). Questa tecnologia crittografa in tempo reale l’intero database quando i dati vengono scritti su disco, rendendo illeggibili i file di dati e di backup anche in caso di accesso fisico non autorizzato ai supporti di archiviazione.

Oltre alla TDE, esiste la crittografia a livello di campo (field-level) per attributi specifici predefiniti, come le password degli account di posta. Questa utilizza la crittografia a cella di SQL Server e serve a soddisfare standard come FIPS 140-2. L’amministratore di sistema può gestire le chiavi di crittografia tramite il centro di amministrazione di Power Platform, con opzioni che includono la gestione personale delle chiavi (BYOK) tramite Azure Key Vault.

Esempio pratico: Un comune che conserva anagrafiche e pratiche di cittadini in Dynamics 365 deve garantire che la TDE sia attiva (lo è per default nelle versioni cloud) e valutare se utilizzare chiavi di crittografia gestite internamente (BYOK) per un controllo più diretto, in linea con i requisiti del GDPR o di normative innerenti la PA.

• Punti operativi:
  1. Verifica lo stato della crittografia TDE dal centro di amministrazione.
  2. Per on-premise, l’attivazione della crittografia a livello di campo è manuale.
  3. Considera la rotazione annuale delle chiavi come buona pratica.
  4. Valuta se i tuoi requisiti di compliance richiedono il modello BYOK.

La gestione delle chiavi è un processo critico: la loro perdita comporta la perdita permanente dei dati crittografati. Pertanto, è fondamentale definire procedure sicure di backup e recovery delle chiavi stesse.

Implementare la Crittografia In Transit nel tuo CRM: Una Guida Pratica

Implementare la Crittografia In Transit nel tuo CRM: Una Guida Pratica

La crittografia in transit protegge i dati mentre si muovono tra il browser dell’utente e i server del CRM. Implementarla non è opzionale: è il primo scudo contro l’intercettazione di credenziali e informazioni sensibili durante l’accesso.

Il cuore di questa protezione è il protocollo TLS (Transport Layer Security). La sua implementazione segue una logica semplice ma rigorosa:

• Verifica lo stato attuale: Controlla se il tuo CRM è raggiungibile solo via HTTPS (non HTTP). L’URL nella barra del browser deve iniziare con “https://” e mostrare l’icona del lucchetto.
• Forza TLS 1.2 o superiore: Disabilita versioni obsolete e insicure (SSL 3.0, TLS 1.0, 1.1) nella configurazione del web server che ospita il CRM. Questo è un requisito fondamentale per gli standard di sicurezza moderni.
• Gestisci i certificati: Un certificato SSL/TLS valido, emesso da una Certification Authority attendibile, è obbligatorio. Assicurati che non sia scaduto e che sia installato correttamente sul server. Per ambienti on-premise, sei responsabile del rinnovo; per soluzioni cloud, il fornitore lo gestisce.
• Configura la redirect forzata: Imposta il server per reindirizzare automaticamente tutto il traffico HTTP verso HTTPS. Questo chiude la porta a connessioni non crittografate, anche per errori di digitazione dell’URL.
• Testa l’implementazione: Usa tool online gratuiti (come SSL Labs) per verificare la qualità della configurazione TLS e identificare eventuali vulnerabilità o misconfigurazioni.

Checklist operativa per l’amministratore:

1. Accesso al pannello di controllo del server/web server (IIS, Apache, Nginx, load balancer).
2. Disabilitazione protocolli TLS/SSL obsoleti.
3. Installazione/rinnovo del certificato SSL.
4. Configurazione della regola di redirect HTTP → HTTPS.
5. Test con browser e strumenti di scansione.

Per i CRM basati su cloud (SaaS), questa configurazione è gestita interamente dal provider. Il tuo compito è verificare contrattualmente che il fornitore utilizzi TLS 1.2+ e condividere i report di conformità (es. SOC 2, ISO 27001) che attestino la cifratura in transito.

Requisiti per una connessione sicura: certificati, cifrari e versioni TLS

Per garantire una connessione sicura tra client e server, Microsoft Dynamics 365 si basa su tre componenti tecnici fondamentali. In primo luogo, è obbligatorio l’utilizzo del protocollo TLS (Transport Layer Security) versione 1.2 o superiore. Questa versione risolve vulnerabilità note nelle release precedenti e rappresenta lo standard industriale per la cifratura dei dati in transito.

• Certificati SSL/TLS validi: Tutti gli endpoint pubblici e le connessioni al servizio richiedono un certificato digitale valido, rilasciato da una Certification Authority (CA) attendibile. Il certificato deve essere correttamente installato e configurato sul web server (IIS per le distribuzioni on-premises) o gestito automaticamente nel caso di servizi cloud.
• Cifrari approvati: La configurazione deve limitare l’uso dei cifrari (cipher suite) a quelli considerati sicuri, escludendo algoritmi deboli o obsoleti (es. SSL 3.0, TLS 1.0/1.1, RC4). L’elenco esatto dipende dalla versione del sistema operativo e da .NET Framework.
• Politiche di sicurezza: Per le operazioni amministrative sensibili, come la modifica della chiave di crittografia via SDK, la connessione deve essere stabilita tramite HTTPS. Un controllo a livello di server blocca le richieste HTTP non cifrate.

Un esempio pratico: per un’istanza Dynamics 365 on-premises, l’amministratore deve verificare che il sito IIS sia associato a un binding HTTPS con un certificato valido e che le impostazioni di Schannel nel Registro di sistema abilitino solo i pacchetti cifrati TLS 1.2. Nel Power Platform Admin Center per il cloud, questa configurazione è gestita interamente da Microsoft.

Configurazione per integrazioni e API: autenticazione mutuale TLS (mTLS)

Per le integrazioni API e i sistemi connessi, il semplice TLS (Transport Layer Security) non basta. Quando il CRM deve scambiare dati sensibili con altri sistemi (es. ERP, piattaforme di marketing, servizi esterni), è fondamentale adottare l’autenticazione mutuale TLS (mTLS). A differenza del TLS standard, dove solo il server (il CRM) presenta un certificato, con mTLS entrambe le parti (client e server) si autenticano reciprocamente tramite certificati digitali. Questo crea un canale di comunicazione a doppia verifica, impedendo a qualsiasi sistema non autorizzato di connettersi alle API, anche se in possesso delle credenziali di accesso. La configurazione richiede la gestione di un’infrastruttura a certificatei (CA) e la distribuzione dei certificati client sui sistemi integrati. Implementare mTLS eleva drasticamente il livello di sicurezza delle integrazioni, trasformando un semplice canale cifrato in un canale di fiducia verificata.

Implementare la Crittografia At Rest: Strategie e Architetture

Implementare la Crittografia At Rest: Strategie e Architetture

La crittografia dei dati at rest – ovvero la protezione delle informazioni quando sono memorizzate su disco – è una轨道交通 fondamentale della sicurezza in Dynamics 365. L’implementazione varia significativamente tra le distribuzioni cloud (online) e on-premises, richiedendo strategie architetturali diverse.

Architettura Cloud (Dynamics 365 Online): Transparent Data Encryption (TDE)Gestita da Microsoft
In ambiente online, Microsoft applica automaticamente la Transparent Data Encryption (TDE) a livello di database SQL Server. Questa tecnologia crittografa in tempo reale i file di dati (.mdf, .ndf) e di log (.ldf) quando scritti su disco, senza richiedere modifiche all’applicazione. L’architettura è trasparente per l’utente finale e per gli sviluppatori: le operazioni di lettura e scrittura funzionano normalmente, mentre la crittografia/decrittografia avviene a livello di motore di database.

Per le organizzazioni che richiedono il controllo diretto delle chiavi (ad esempio per conformità normative specifiche), Dynamics 365 Online supporta la funzionalità Bring Your Own Key (BYOK). Tramite il Power Platform Admin Center, gli amministratori possono collegare un proprio insieme di chiavi crittografiche (file PFX o protezione HSM) archiviate in Azure Key Vault. In questo scenario:

• Microsoft gestisce l’infrastruttura di crittografia, ma la chiave master rooted in Azure Key Vault è di proprietà del cliente.
• La rotazione delle chiavi resta una responsabilità condivisa: il cliente ruota la chiave in Key Vault, Microsoft la applica automaticamente.
• Questa architettura soddisfa requisiti di separazione dei doveri, dove il provider cloud gestisce il servizio ma non ha accesso alle chiavi di decrittazione.

Architettura On-Premises: Crittografia a Livello di Campo (Field-Level)
Per le distribuzioni on-premises di Dynamics 365 Customer Engagement, la strategia si basa sulla SQL Server Cell-Level Encryption, applicata a un set predefinito di attributi considerati sensibili (es. password server di posta, password integrationi Yammer). Questa è un’implementazione a livello applicativo gestita tramite il SDK di Dynamics 365.

L’attivazione e la gestione avvengono esclusivamente tramite l’interfaccia di amministrazione (Settings > Data Management > Data Encryption) da parte di un utente con ruolo System Administrator. Il processo prevede:

1. Attivazione: una volta abilitata, la crittografia non può essere disattivata.
2. Gestione della Chiave: è possibile cambiare la chiave di crittografia (best practice: almeno annualmente), operazione che richiede che il sito web di Dynamics sia configurato con SSL/TLS.
3. Recupero della Chiave: la chiave originale deve essere copiata e conservata in luogo sicuro (es. file di testo). È essenziale per operazioni di ripristino, migrazione o dopo una ricreazione del database di configurazione (MSCRM_CONFIG).

Esempio Pratico: Protezione delle Credenziali Email
Lo scenario d’uso primario per la field-level encryption on-premise è la protezione delle credenziali utilizzate dal Microsoft Dynamics CRM Email Router. Quando il router è configurato per sincronizzare la posta, le password degli account di posta (incoming/outgoing) e delle caselle (Mailbox.Password) vengono archiviate nel database in forma crittografata. Questo impedisce a un amministratore di database malintenzionato (o a un DBA con accesso raw al DB) di leggere in chiaro le password, soddisfacendo così requisiti di sicurezza come FIPS 140-2.

Limitazioni Architetturali e Implicenze Operative
La crittografia a livello di campo introduce vincoli significativi da considerare in fase di progettazione:

• Campi non indicizzabili: gli attributi crittografati non possono essere indicizzati, quindi le ricerche basate su questi campi sono estremamente inefficienti o non supportate.
• Auditing disabilitato: non è possibile abilitare l’audit trail (tracciamento modifiche) sui campi crittografati.
• Null in lettura: durante un retrieveSDK o query, il valore effettivo del campo crittografato viene restituito come null. L’applicazione deve gestire la decrittografia trasparentemente tramite l’SDK.
• Solo attributi out-of-the-box: la crittografia si applica solo ai campi predefiniti elencati nelle tabelle di sistema (UserSettings.EmailPassword, Queue.EmailPassword, ecc.). Non è possibile estenderla a campi personalizzati.

Checklist Operativa per l’Implementazione On-Premises
Prima di attivare la crittografia in un ambiente di produzione, è essenziale:

1. Verificare i Prerequisiti: assicurarsi che il sito web IIS di Dynamics 365 sia configurato con un certificato SSL valido (HTTPS obbligatorio per l’attivazione e il cambio chiave).
2. Valutare l’Impatto: identificare tutti gli attributi che verranno crittografati (solo quelli predefiniti) e testare le conseguenze su eventuali integrazioni, report o plugin che accedono direttamente a questi campi.
3. Pianificare il Backup della Chiave: dopo l’attivazione, copiare immediatamente la chiave di crittografia in un file sicuro (es. .txt) e conservarlo in un luogo fisico o digitale diverso dal server. Perdere questa chiave significa perdere l’accesso ai dati crittografati.
4. Definire la Policy di Rotazione: schedulare un cambio annuale della chiave, ricordando che l’operazione richiede SSL e un periodo di manutenzione (l’operazione è bloccante a livello di messaggio SDK).
5. Documentare la Procedura di Recovery: definire il processo passo-passo per ripristinare la chiave in scenari di disaster recovery, incluso l’uso di Internet Explorer per incollare la chiave nel dialogo (compatibilità legacy).

Gestione delle Chiavi di Crittografia (KMS): il cuore del sistema

La gestione delle chiavi di crittografia (Key Management System – KMS) è il componente che determina l’effettiva sicurezza di un sistema di crittografia. Senza una gestione centralizzata e protetta delle chiavi crittografiche, anche la crittografia più avanzata può essere compromessa. In Dynamics 365, il KMS è strettamente integrato con Azure Key Vault, il servizio cloud di Microsoft per la protezione di chiavi crittografiche, certificati e segreti.

Di default, Microsoft gestisce interamente le chiavi di crittografia del database (TDE) e le chiavi per la crittografia a livello di campo. Questa opzione “gestita” riduce l’onere operativo per l’organizzazione. Tuttavia, per carichi di lavoro con requisiti di conformità stringenti (es. norme che richiedono la separazione dei doveri) o per un controllo diretto sul ciclo di vita delle chiavi, è possibile adottare il modello Bring Your Own Key (BYOK).

Con BYOK, l’organizzazione genera o importa le proprie chiavi crittografiche (ad esempio in un modulo di protezione hardware – HSM) e le carica in Azure Key Vault. Dynamics 365 vi fa riferimento per le operazioni di crittografia/decrittografia, senza mai esporre la chiave in chiaro. Questo garantisce che solo l’organizzazione, e non Microsoft, possa accedere fisicamente alla chiave master, soddisfando così requisiti normativi specifici per PA e PMI in settori critici.

Il pannello di amministrazione della Power Platform permette di configurare questa integrazione in modo guidato. La scelta tra gestione automatica e BYOK non è solo tecnica, ma strategica: incide sui processi di audit, sulla disaster recovery (dove la disponibilità della chiave è vitalizia) e sulla governance complessiva dei dati.

Esempio pratico: Un’azienda fornitrice di servizi finanziari, soggetta a linee guida della Banca d’Italia che impongono il controllo diretto sulle chiavi di crittografia, utilizza BYOK. Le chiavi sono generate nel proprio HSM locale e importate in un Azure Key Vault dedicato. Dynamics 365 vi accede per crittografare i dati sensibili dei clienti, garantendo audit trail diferenciato e separazione dei ruoli tra amministratori di sistema e responsabili della sicurezza.

[CTA SOFT – Integrata] La gestione delle chiavi è un pilastro della tua strategia di sicurezza. Scarica la nostra Checklist Operativa per il KMS in Dynamics 365 (5 minuti) e valuta se la tua configurazione corrente soddisfa i principi di controllo e resilienza.

Implementazione nativa nella piattaforma CRM (Salesforce Shield, Microsoft Purview, etc.)

Le piattaforme CRM moderne integrano funzionalità di crittografia native, riducendo la necessità di soluzioni esterne complesse. In Microsoft Dynamics 365, la crittografia è gestita a più livelli: Transparent Data Encryption (TDE) per i dati a riposo, che cifra in tempo reale i file del database SQL Server; crittografia a livello di campo (field-level encryption) per attributi sensibili specifici, come password di posta e credenziali, usando standard FIPS 140-2. Quest’ultima è configurabile tramite l’area Impostazioni > Gestione dati > Crittografia dati e richiede un amministratore di sistema. La gestione delle chiavi è centralizzata nel Power Platform Admin Center, con supporto a BYOK (Bring Your Own Key) e archiviazione sicura in Azure Key Vault.

Salesforce Shield offre un toolkit nativo di crittografia avanzata: Shield Platform Encryption cifra dati at rest (inclusi campi personalizzati e file allegati) con chiavi gestite da Salesforce o dal cliente (BYOK), mentre Shield Field Encryption保护特定字段。Entrambi i sistemi garantiscono la cifratura in transito tramite TLS 1.2 o superiore.

Microsoft Purview (ex Microsoft 365 Compliance) estende le capacità di governance e cifratura, con policy automatizzate per classificare e proteggere i dati sensibili in Dynamics 365, integrando controlli di accesso condizionale e audit trail.

Queste implementazioni native semplificano la conformità a normative come GDPR e NIS2, poiché la piattaforma gestisce automaticamente la crittografia senza interventi manuali sui singoli record. Ad esempio, una volta attivata la crittografia a livello di campo in Dynamics 365, le credenziali di integrazione email sono automaticamente protette, prevenendo l’accesso non autorizzato anche da parte di amministratori di database.

• Verifica lo stato della crittografia nativa nella tua piattaforma CRM (impostazioni di sicurezza).
• Per Dynamics 365 on-premises, pianifica la sostituzione annuale delle chiavi e configura obbligatoriamente TLS/SSL.
• Valuta l’uso di BYOK se la tua organizzazione richiede il controllo completo delle chiavi di crittografia.

Crittografia a livello di database: TDE per环境 on-premise o IaaS

Crittografia a livello di database: TDE per ambienti on-premise o IaaS

Per le distribuzioni Microsoft Dynamics 365 on-premise o in infrastruttura IaaS (Infrastructure as a Service), la crittografia dei dati “at rest” a livello di database è gestita attraverso Transparent Data Encryption (TDE) di SQL Server. A differenza dell’ambiente cloud gestito da Microsoft, in questi scenari l’organizzazione ha la piena responsabilità della configurazione e della gestione delle chiavi di crittografia.

Come funziona TDE in autonomia:

• TDE crittografa in tempo reale i file di dati (.mdf, .ldf, .bak) quando vengono scritti su disco, rendendo illeggibili i backup e i file del database sottratti.
• L’amministratore di sistema deve attivare manualmente TDE tramite comandi T-SQL o strumenti di gestione SQL Server. Non è attiva per default nelle nuove installazioni on-premise.
• Le chiavi di crittografia del database (DEK) e il certificato o la chiave asimmetrica utilizzati per proteggerle sono gestiti interamente dal cliente.

Implicazioni operative chiave:

• Responsabilità delle chiavi: Perdere le chiavi di crittografia significa perdere definitivamente l’accesso ai dati. È obbligatorio implementare procedure sicure di backup e archiviazione delle chiavi, preferibilmente in un HSM (Hardware Security Module) o in un servizio come Azure Key Vault.
• Performance: L’overhead di TDE è generalmente minimo (sotto il 5%), ma va valutato in caricamenti di I/O intensivi.
• Requisiti di compliance: TDE aiuta a soddisfare requisiti normativi che richiedono la crittografia dei dati persistenti (es. FIPS 140-2), ma non protegge i dati durante l’elaborazione.
• Limitazioni: TDE agisce a livello di file di database, non a livello di singolo campo (field-level). Per proteggere attributi specifici (come password) è necessaria la crittografia a livello applicativo, che in CRM on-premise rimane limitata ai campi di sistema predefiniti.

Nota: L’attivazione di TDE richiede always encryption o connessioni SSL/TLS per le operazioni di gestione delle chiavi.

Esempio pratico: Un’azienda che ospita Dynamics 365 on-premise sui propri server deve pianificare un processo di cambio chiavi annuale, testare i backup crittografati e garantire che l’account del servizio SQL disponga delle autorizzazioni necessarie per accedere al certificato di crittografia all’avvio.

Crittografia e Compliance: GDPR, CCPA e Altri Quadri Normativi

Crittografia e Compliance: GDPR, CCPA e Altri Quadri Normativi

La crittografia dei dati nel CRM non è solo una misura tecnica di sicurezza; è un elemento cardine per la conformità normativa. Quadri come il GDPR (Regolamento UE 2016/679), la CCPA/CPRA californiana e standard come ISO/IEC 27001 e NIS2 considerano la cifratura un controllo tecnico-organizzativo fondamentale per proteggere i dati personali e ridurre il rischio di violazioni.

Per il GDPR, l’articolo 32 obbliga i titolari del trattamento a implementare misure tecniche appropriate, come la pseudonimizzazione e la cifratura, per garantire un livello di sicurezza adeguato. La crittografia dei dati at rest (nella base dati) e in transit (nelle comunicazioni) è citata esplicitamente come esempio di tali misure. In caso di violazione (data breach), la cifratura efficace può mitigare le conseguenze legali e amministrative, poiché i dati resi unintelligibili a terzi non autorizzati possono essere considerati “non compromessi” ai fini della notifica all’autorità di controllo e agli interessati.

Similmente, la CCPA/CPRA richiede “procedure e pratiche ragionevoli di sicurezza” per proteggere le informazioni personali. L’implementazione di crittografia conforme agli standard industriati (es. TLS 1.2+ per i dati in transito, algoritmi AES per i dati a riposo) rappresenta una dimostrazione tangibile di tali sforzi. Anche lo standard ISO/IEC 27001:2022, nel controllo A.8.24 (“Crittografia”), richiede l’uso della crittografia per proteggere la riservatezza, l’autenticità e l’integrità delle informazioni.

Nel contesto di un CRM Dynamics 365, attivare la Transparent Data Encryption (TDE) soddisfa il requisito di crittografia dei dati at rest a livello di database. Parallelamente, la crittografia a livello di campo (Field-Level Encryption) per attributi sensibili come password e credenziali (es. per l’integrazione con Exchange) risponde alla necessità di proteggere dati specifici anche da amministratori di sistema, un punto cruciale per il principio della minimizzazione dei dati e per la sicurezza in scenari di outsourcing cloud.

Per allinearsi a queste normative, non basta *avere* la crittografia attiva. Serve un approccio strutturato:

• Documentare le scelte: specificare nel registro delle attività di trattamento (GDPR) quali dati sono crittografati, con quali algoritmi e chi gestisce le chiavi.
• Gestire le chiavi crittografiche: adottare pratiche di key management sicure, come l’uso di Azure Key Vault con Customer-Managed Keys (BYOK) per Dynamics 365, per avere controllo Audit Trail e separazione dei ruoli.
• Verificare periodicamente: condurre assessment per confermare che la crittografia sia attiva, aggiornata (es. algoritmi non deprecati) e che le eccezioni (campi non crittografabili) siano giustificate e compensate da altri controlli.
• Formare il personale: assicurare che amministratori e sviluppatori comprendano le limitazioni (es. campi crittografati non indicizzabili, auditing disabilitato) per progettare correttamente le soluzioni.

Un errore comune è credere che la semplice attivazione della crittografia su database o disco esaurisca gli obblighi. La compliance nasce dalla valutazione del rischio contestuale: una PA che tratta dati sanitari in un CRM dovrà considerare normative specifiche (es. normative nazionali di attuazione del GDPR, linee guida AgID) che potrebbero richiedere standard aggiuntivi o la crittografia anche durante le fasi di elaborazione (in use), non solo a riposo e in transito.

In sintesi, la crittografia nel CRM è un abilitatore strategico per la compliance. Trasforma un obbligo normativo astratto (“implementare misure di sicurezza”) in una configurazione tecnica verificabile, riducendo l’esposizione legale e costruendo fiducia con clienti e partner.

GDPR: la crittografia come misura tecnica e organizzativa appropriata (Art. 32)

GDPR: la crittografia come misura tecnica e organizzativa appropriata (Art. 32)

Il Regolamento Generale sulla Protezione dei Dati (GDPR), all’Articolo 32, obbliga titolari e responsabili del trattamento a implementare misure tecniche e organizzative appropriate per garantire un livello di sicurezza adeguato al rischio. Tra le misure esplicitamente citate vi è la crittografia dei dati personali. Per un CRM, che custodisce il cuore dei dati clienti (contatti, comunicazioni, opportunità commerciali), la crittografia non è solo una best practice, ma un pilastro della conformità.

La normativa distingue tra i due stati fondamentali del dato:

• Crittografia at rest: protegge i dati archiviati nel database del CRM (es. record clienti, cronologie) da accessi non autorizzati al supporto fisico o a copie di backup.
• Crittografia in transit: protegge i dati durante la trasmissione, ad esempio quando un utente accede al CRM via web o quando i dati sincronizzano tra sistemi. Il protocollo TLS/SSL è lo standard minimo richiesto.

Implementare entrambe le forme di crittografia dimostra all’autorità di controllo (es. Garante Privacy) che avete adottato un approccio proattivo e basato sul rischio. Contribuisce a mitigare l’impatto di violazioni, riducendo il rischio di sanzioni e il danno reputazionale. Tuttavia, la crittografia da sola non basta: deve essere parte di un quadro più ampio che include gestione degli accessi, logging e formazione del personale.

Per un’azienda che utilizza un CRM, valutare se la soluzione in uso (cloud o on-premise) offre questi standard di crittografia nativi è il primo passo. Spesso, per le PMI, affidarsi a piattaforme enterprise-grade come Microsoft Dynamics 365, che integrano TDE (Transparent Data Encryption) e TLS per default, semplifica l’aderenza a questo requisito GDPR.

CCPA/CPRA: sicurezza dei dati personali e diritto alla cancellazione

Il CCPA/CPRA impone requisiti rigorosi sulla sicurezza dei dati personali e sul diritto alla cancellazione. La crittografia at rest (ad esempio Transparent Data Encryption in Microsoft Dynamics 365) e in transit (TLS) sono controlli tecnici essenziali per mitigare i rischi di accesso non autorizzato, allineandosi al principio di “security by design” della normativa. Tuttavia, la semplice crittografia non basta ad adempiere agli obblighi di cancellazione. Quando un consumatore esercita il diritto all’oblio, l’organizzazione deve eliminare definitivamente i dati, inclusi quelli crittografati. Ciò richiede la distruzione delle chiavi di decrittazione e la rimozione di tutte le copie di backup. Una gestione centralizzata delle chiavi (come Azure Key Vault) aiuta a controllare l’accesso, ma deve essere affiancata da procedure documentate per la cancellazione sicura e verificabile.

Impatto su Data Localization e trasferimenti internazionali (Schrems II)

Impatto su Data Localization e Trasferimenti Internazionali (Schrems II)

La crittografia dei dati nel CRM gioca un ruolo cruciale nella gestione dei rischi connessi ai trasferimenti internazionali e al principio di localizzazione. La sentenza Schrems II ha rafforzato l’obbligo di adottare misure tecniche complementari, come la cifratura robusta (at rest e in transit), per garantire un livello di protezione sostanzialmente equivalente quando i dati lascano l’UE.

Implementare standard come TLS 1.2 per il transito e TDE/SQL Server Cell Level Encryption per i dati archiviati riduce l’esposizione a intercettazioni e accessi non autorizzati durante il trasferimento e lo stoccaggio. Questo non elude l’obbligo di valutare il contesto giuridico del paese di destinazione, ma costituisce una misura tecnica concreta per mitigare i rischi identificati dalla Corte di Giustizia UE.

Per le organizzazioni che operano globalmente, integrare una strategia di crittografia forte nel CRM è un elemento essenziale per documentare la due diligence nella valutazione degli strumenti di trasferimento (es. Clausole Contrattuali Standard) e dimostrare l’adozione di “supplemental measures” post-Schrems II.

Valutare Fornitori CRM e Servizi Cloud: Domande Critiche sulla Sicurezza

Quando si sceglie un fornitore di CRM cloud o un servizio di infrastruttura, la sicurezza della crittografia non è un dettaglio tecnico, ma il fondamento della protezione dei tuoi dati. Un fornitore trasparente su questi aspetti è un partner affidabile. Ecco le domande critiche da porre per valutare la sua reale posture di sicurezza.

1. Dove sono fisicamente ubicati i miei dati e chi ha accesso diretto al livello infrastrutturale?

Chiedi la localizzazione precisa dei data center e se il fornitore garantisce il data residency per rispettare normative specifiche (es. GDPR per dati UE). Informati anche su chi, tra il personale del fornitore, può accedere all’infrastruttura fisica e logica. L’accesso deve essere strettamente controllato, registrato e basato sul principio del minimo privilegio.

2. Come vengono gestite le chiavi di crittografia? Chi le controlla realmente?

Questa è la domanda più importante. Distingui tra:

• Gestione chiavi da parte del fornitore: il fornitore genera, archivia e gestisce le chiavi. Più semplice per te, ma devi fidarti della sua policies interne.
• Bring Your Own Key (BYOK) o Customer-Managed Key: tu generi o importi le tue chiavi (es. in un HSM dedicato) e il fornitore le usa senza mai vederle. Massimo controllo, ma maggiore complessità operativa.

Chiedi: “Posso rifiutare l’accesso del fornitore alle mie chiavi crittografiche in qualsiasi momento?”.

3. Quali standard di crittografia e certificazioni di sicurezza vengono implementati e verificati?

Pretendi risposte specifiche: oltre al TLS 1.2+ per il transit, quale tecnologia viene usata per i dati at rest (es. AES-256)? Il fornitore ha certificazioni ISO/IEC 27001 e/o SOC 2 Type II? Richiedi i report di audit più recenti.

4. Come avviene il controllo degli accessi (IAM) e l’auditing delle operazioni critiche?

Verifica che esista un sistema centralizzato di gestione identità (es. integrazione con Azure AD) e che ogni azione su dati sensibili—soprattutto quelle che implicano decrittografia—sia loggata in modo immutabile. Chiedi: “Posso ricevere un alert in tempo reale se qualcuno tenta di accedere a un record crittografato?”.

5. Cosa succede in caso di disastro o errore umano? Avete un piano di recovery testato?

I backup sono anch’essi crittografati? Il processo di restore garantisce che le chiavi siano disponibili? Chiedi dettagli sul Recovery Time Objective (RTO) e Recovery Point Objective (RPO). Un fornitore serio esegue test periodici di recovery e può documentarli.

Una valutazione basata solo sul prezzo o sulle funzionalità è riskosa. Usa queste domande come checklist durante le demo e nelle call commerciali. Un fornitore che evita o vaga nelle risposte sta nascondendo qualcosa.

Checklist per il RFI/RFP: crittografia at rest predefinita e configurabile

• Crittografia at rest predefinita: La soluzione attiva automaticamente la Transparent Data Encryption (TDE) di SQL Server per tutti i dati archiviati? Specificare se l’attivazione è immediata per nuove istanze.
• Gestione delle chiavi: Le chiavi di crittografia del database sono gestite dal fornitore (default) o consentono il self-management? Viene offerta l’opzione Bring Your Own Key (BYOK) con integrazione Azure Key Vault?
• Crittografia a livello di campo: La piattaforma applica la crittografia cell-level per attributi sensibili predefiniti (es. password) e/o supporta campi personalizzati? Specificare gli attributi protetti di default.
• Frequenza di rotazione: È possibile automatizzare il cambio delle chiavi? Viene consigliata una periodicità (es. annuale) e quali sono i requisiti (es. TLS/SSL configurato)?
• Limitazioni operative: La crittografia impedisce l’auditing sui campi protetti, la loro indicizzazione o personalizzazione? Specificare eventuali impatti sulle integrazioni (es. Email Router).
• Ambiente on-premise: Per distribuzioni on-premise, l’attivazione della crittografia è manuale e irreversibile? Richiede configurazione SSL on the website?
• Recupero chiavi: Fornite procedure documentate per esportare/salvare la chiave di crittografia? La chiave è accessibile solo a ruoli specifici (es. System Administrator)?
• Compliance: La crittografia implemented soddisfa standard come FIPS 140-2? Fornite report o certificazioni relative?

Comprensione del modello di responsabilità condivisa (Shared Responsibility Model)

Il modello di responsabilità condivisa definisce chiaramente i confini tra le misure di sicurezza gestite dal provider cloud (Microsoft) e quelle di competenza del cliente. Per Dynamics 365 Online, Microsoft si assume la responsabilità della sicurezza fisica dei datacenter, della crittografia at rest tramite TDE e di quella in transit con TLS. Il cliente, invece, è responsabile della corretta configurazione del sistema, della gestione degli accessi utente (ruoli e privilegi), della protezione delle proprie credenziali e, se attivata, della gestione delle chiavi di crittografia personalizzate (BYOK).

Nelle distribuzioni on-premises, la responsabilità ricade quasi interamente sul cliente, che deve gestire l’infrastruttura, l’applicazione degli aggiornamenti di sicurezza, la configurazione del protocollo SSL/TLS e l’implementazione della crittografia a livello di campo. Comprendere questo modello è essenziale per evitare falsi sense of security: la crittografia del fornitore protegge solo lo strato infrastrutturale, mentre le vulnerabilità applicative o di configurazione rimangono a carico dell’organizzazione.

Oltre la Crittografia: Considerazioni Operazionali e Avanzate

Attivare la crittografia è solo il primo passo. Una strategia di protezione dati efficace richiede una gestione operativa costante e consapevole delle sue implicazioni.

Gestione e rotazione delle chiavi. Le chiavi di crittografia non sono “impostate e dimenticate”. Microsoft consiglia di cambiarle almeno una volta all’anno per mitigare i rischi. La rotazione richiede che il sito web CRM sia configurato con SSL/TLS. Per le distribuzioni on-premise, l’amministratore di sistema deve conservare una copia di backup della chiave originale in un luogo sicuro (come un archivio offline). Perdere la chiave significa perdere definitivamente l’accesso ai dati cifrati.

Limitazioni funzionali da معرفة. La crittografia a livello di campo ha compromessi operativi significativi. I campi cifrati, come le password degli account email, non possono essere indicizzati, il che può rallentare le prestazioni delle query che vi fanno riferimento. Inoltre, non è possibile abilitare l’auditing su di essi, limitando la tracciabilità delle modifiche. La personalizzazione (ad esempio, aggiungere regole di business) è spesso preclusa per questi campi. Questi vincoli vanno valutati durante la progettazione del sistema.

Disaster Recovery e continuità. Il piano di ripristino deve includere le chiavi di crittografia. In caso di migrazione, ripristino da backup o ricreazione del database di configurazione, la chiave originale è indispensabile per riattivare la crittografia e rendere leggibili i dati. Senza di essa, il backup risulta inutilizzabile. Testare regolarmente le procedure di ripristino assicurando che le chiavi siano accessibili è fondamentale per la resilienza operativa.

Monitoraggio e allineamento normativo. La semplice attivazione non garantiede la conformità. È necessario documentare le politiche di gestione delle chiavi, i tempi di rotazione e i processi di backup. Verificare che la soluzione soddisfi i requisiti specifici della normativa applicabile (es. GDPR per la protezione dei dati personali, NIS2 per la sicurezza informatica) è un processo continuo che va oltre la configurazione tecnica. La crittografia è un controllo, non la soluzione completa.

• Checklist operativa: Verifica backup chiavi | Documenta policy di rotazione | Testa ripristino con chiavi | Valida impatto su performance | Registra controlli per audit.

Impatto sulle performance e best practice per l’ottimizzazione

La crittografia, soprattutto a livello di campo (cell-level), introduce un leggero overhead computazionale che può impattare le performance del CRM, in particolare su operazioni di lettura e scrittura massiva. I campi crittografati non sono indicizzabili e le query che li coinvolgono risultano più lente.

Best practice per l’ottimizzazione:

• Attivare la crittografia solo per attributi che contengono dati strettamente sensibili (es. password, dati finanziari), evitando un uso estensivo.
• Implementare sempre TLS/SSL per la crittografia in transito, utilizzando protocolli moderni (TLS 1.2+) e configurare correttamente i certificati.
• Per la gestione delle chiavi (specialmente in scenari BYOK), affidarsi ad Azure Key Vault perCentralizzare e automatizzare la rotazione, riducendo il rischio operativo.
• Pianificare test di carico dopo l’attivazione per misurare l’impatto reale e identificare eventuali colli di bottiglia.
• Cambiare la chiave di crittografia almeno una volta all’anno, come raccomandato da Microsoft, per mitigare i rischi di compromise.

Backup e ripristino: garantire la ripristinabilità dei dati crittografati

Backup e ripristino: garantire la ripristinabilità dei dati crittografati

La strategia di backup deve necessariamente considerare la crittografia. I backup automatizzati di Dynamics 365 (online) sono crittografati per default, spesso in conformità a standard come FIPS 140-2. Il vero focus non è il backup in sé, ma il ripristino controllato.

Per ripristinare dati crittografati, l’accesso alla chiave di crittografia corretta è fondamentale. Se si utilizza la gestione delle chiavi da parte di Microsoft (default), il processo è trasparente. Se si adotta il self-management (BYOK) con chiavi proprie in un HSM (Hardware Security Module), bisogna preservare l’accesso a tale modulo e ai relativi certificati. In ambito on-premises, l’amministratore deve documentare e proteggere la chiave utilizzata per l’attivazione della crittografia, poiché sarà richiesta per importare o ripristinare il database in un nuovo ambiente.

Esempio pratico: In uno scenario di ripristino dopo un incidente, senza la chiave di crittografia originale (o l’accesso all’Azure Key Vault che la custodisce), i dati nel database ripristinato rimarrebbero illeggibili, rendendo il backup inutile.

• Checklist operativa: Verificare che il processo di backup includa un backup separato e sicuro delle chiavi di crittografia (o dei certificati). Documentare la procedura per il ripristino in un ambiente di test.
• Errore comune: Presupporre che il backup del database sia sufficiente, dimenticando che la chiave è un componente distinto e critico.

Crittografia e funzionalità CRM: ricerca, indicizzazione, reporting

Crittografia e funzionalità CRM: ricerca, indicizzazione, reporting

Attivare la crittografia a livello di campo (field-level) in Dynamics 365 ha implicazioni dirette sulle funzionalità di piattaforma. I campi protetti da questo meccanismo non possono essere indicizzati dal sistema di ricerca full-text. Di conseguenza, le query di ricerca che includono questi campi restituiranno risultati nulli o incompleti.

Allo stesso modo, i report e le viste che si basano su questi campi crittografati non possono essere elaborate correttamente, poiché il dato rimane illeggibile per il motore di reporting. Anche l’auditing nativo non è supportato sui campi crittografati.

Valutare attentamente quali dati sensibili richiedono obbligatoriamente la crittografia a livello di campo, bilanciando il requisito di sicurezza con l’esigenza di mantenere piene funzionalità di ricerca e analisi dati sugli altri attributi.

Consiglio pratico: Limitare l’attivazione della crittografia field-level solo agli attributi di sistema che gestiscono password (es. EmailServerProfile.Password), a meno che non sia strettamente necessario per campi custom, accettando la rinuncia alle funzionalità correlate.

Conclusioni e Tendenze Future: Post-Quantum Cryptography e Zero Trust

La crittografia dei dati nel CRM non è più un’opzione, ma una necessità operativa. Come visto, Dynamics 365 implementa protezioni solide con TDE per i dati at rest e TLS per quelli in transit. Tuttavia, il panorama delle minacce evolve rapidamente. Due trend stanno ridisegnando il futuro della sicurezza dei dati.

La Crittografia Post-Quantistica (PQC) emerge come risposta alla futura minaccia dei computer quantistici, capaci di violare gli algoritmi crittografici attuali. Enti come il NIST stanno standardizzando nuovi algoritmi a prova quantistica. Le organizzazioni devono iniziare a valutare la “quantum readiness” dei propri sistemi CRM, pianificando la migrazione graduale verso standard PQC per proteggere la riservatezza dei dati a lungo termine.

Il modello Zero Trust si affianca come strategia architetturale. Si fonda sul principio “mai fidarsi, verificare sempre”, applicando controlli di accesso granulari e autenticazione forte per ogni accesso ai dati, sia interno che esterno. In un CRM, Zero Trust significa crittografare i dati non solo a riposo e in movimento, ma anche durante l’uso, gestendo policy dinamiche basate sul contesto (utente, dispositivo, localizzazione).

L’integrazione di questi approcci è il prossimo passo. Un CRM moderno dovrà fondere cifratura avanzata, gestione centralizzata delle chiavi (come in Azure Key Vault) e un modello Zero Trust per una difesa multilivello. La preparazione inizia oggi: audit della crittografia esistente, formazione del team e definizione di una roadmap per l’adozione di standard futuri.

Prossime evoluzioni normative e tecnologiche

Prossime evoluzioni normative e tecnologiche

Il panorama normativo e tecnologico evolve rapidamente verso modelli di sicurezza più proattivi.

• Normative: Direttive come NIS2 e i continui aggiornamenti del GDPR spingono verso l’obbligo di cifratura dei dati “by design” e la notifica tempestiva delle violazioni, rendendo la crittografia non più opzionale ma elemento centrale dei piani di sicurezza.
• Tecnologia: La cifratura sta evolvendo dal semplice at-rest a modelli field-level più granulari, estesi anche a campi personalizzati. Cresce l’adozione di chiavi gestite dal cliente (BYOK) e l’integrazione con piattaforme di gestione chiavi cloud (come Azure Key Vault) per centralizzare il controllo.
• Tendenze: L’AI viene esplorata per automatizzare il rilevamento di pattern anomali nell’accesso ai dati cifrati. Il principio Zero Trust ridefinisce la crittografia non più come bariera statica, ma come parte di un ecosistema di controllo dinamico per ciascuna transazione.

Per PA e PMI, prepararsi significa valutare soluzioni che supportino standard aperti e policy di key management scalabili, evitando il vendor lock-in.

Piani d’azione immediati: dove iniziare domani mattina

Se la tua organizzazione utilizza Dynamics 365 o CRM, domani mattina puoi avviare queste verifiche pratiche in meno di 30 minuti:

• Verifica lo stato attuale: Accedi all’area Impostazioni > Gestione dati > Crittografia dati per controllare se la crittografia a livello di campo è attiva. Per le versioni cloud, TDE (Transparent Data Encryption) per i dati at rest è già abilitata per default.
• Configurazione SSL (on-premise): Assicurati che il sito web CRM sia raggiungibile via HTTPS/SSL. È obbligatorio per cambiare la chiave di crittografia e per usare le API di gestione.
• Rotazione della chiave: Se la crittografia è attiva da oltre 12 mesi, pianifica la rotazione della chiave di crittografia utilizzando il messaggio SetDataEncryptionKeyRequest. Ricorda: una volta attivata, la crittografia non può essere disattivata.
• Documenta la chiave corrente: Copia la chiave di crittografia attuale in un luogo sicuro e offline (es. un vault aziendale). Questa operazione è critica per disaster recovery o migrazioni.
• Valuta il BYOK: Se la compliance (es. ISO 27001, NIS2) richiede il controllo completo delle chiavi, esplora la funzionalità di gestione chiavi nel Power Platform Admin Center con supporto a PFX/BYOK e Azure Key Vault.

Questi step costituiscono una baseline di sicurezza immediata senza impattare le operazioni quotidiane.

Domande Frequenti (FAQ)

La crittografia At Rest nel CRM è obbligatoria per il GDPR?

Il GDPR (Art. 32) richiede ‘misure tecniche e organizzative appropriate’ per garantire un livello di sicurezza adeguato. La crittografia dei dati è esplicitamente menzionata come esempio di misura tecnica. Mentre non è tecnicamente obbligatoria in ogni caso, rappresenta lo standard industriale per la protezione dei dati personali ed è il modo più efficace per mitigare le conseguenze di una violazione (in quanto i dati rubati sono illeggibili). In Assenza di crittografia, spetterebbe all’azienda dimostrare di aver adottato misure equivalenti, il che è molto difficile.

Qual è la differenza principale tra TDE e crittografia a livello di colonna?

La **TDE (Transparent Data Encryption)** crittografa l’intero file di database o lo storage a livello di disco. È trasparente per l’applicazione e l’utente, con impatto minimo sulle operazioni. Tuttavia, i dati sono decrittografati quando caricati in memoria dal database. La **crittografia a livello di colonna** (o campo) applica la cifratura solo a campi specifici (es. numeri di telefono, email, carte di credito) all’interno del database. Offre controllo granulare e ‘defense in depth’ (i dati restano cifrati anche in memoria se gestiti correttamente), ma può complicare query, indicizzazione e reporting.

La crittografia influisce sulle performance del CRM? Quanto?

Sì, introduce un overhead computazionale, ma con l’hardware e le ottimizzazioni moderne l’impatto è spesso minimo (<5% per la TDE). L'impatto maggiore deriva dalla **crittografia a livello di applicazione/colonna** per query complesse su dati cifrati. Il vero costo è nella **gestione delle chiavi** e nella complessità operativa (backup, disaster recovery, rotazione). Una valutazione deve testare carichi di lavoro reali in ambiente staging. L'uso di acceleratori hardware (AES-NI) e KMS efficienti mitiga drasticamente l'overhead.

Se il mio CRM è cloud (es. Salesforce), chi è responsabile della crittografia At Rest?

Si applica il **Modello di Responsabilità Condivisa**. Il fornitore cloud (Salesforce, Microsoft) è responsabile della sicurezza *dell’infrastruttura*: fisica, ipervisor, storage fisico (che è già crittografato). L’**utente/cliente** è responsabile della sicurezza *dei dati*: gestione degli accessi, configurazione della crittografia a livello di campo/dati (es. Salesforce Shield), gestione delle chiavi se si usa BYOK, e configurazione delle connessioni. Devi sempre verificare il contratto e i documenti di conformità del fornitore (SOC 2, ISO 27001).

Posso usare la mia stessa chiave di crittografia (BYOK) con un CRM cloud?

Sì, e questa è spesso la configurazione più sicura e preferita per la compliance. Il **BYOK (Bring Your Own Key)** o **HYOK (Hold Your Own Key)** ti permette di generare e gestire le tue chiavi crittografiche in un tuo sistema di gestione (es. un tuo HSM on-premise o un cloud KMS sotto il tuo controllo), concedendo solo l’uso (non la proprietà) al fornitore CRM. Il fornitore non può mai accedere alle chiavi in chiaro. Verifica che il tuo CRM supporti questa integrazione (es. Salesforce Shield con External Key Manager, Azure Information Protection con BYOK).

Contattaci

contattaci per saperne di più