Dominio di sicurezza: gestione dei dati, sicurezza e privacy

Questo dominio di sicurezza è progettato per garantire che tutti i dati utilizzati da Microsoft 365 siano adeguatamente protetti sia in transito che inattivi. Questo dominio garantisce anche che le preoccupazioni sulla privacy dei consumatori (interessati) siano soddisfatte dall'ISV, in linea con il GDPR (Regolamento generale sulla protezione dei dati) e HIPAA (Health Insurance Portability and Accountability Act del 1996).

Dati in transito

I requisiti di connettività delle app e dei componenti aggiuntivi sviluppati in Microsoft 365 richiedono la comunicazione tramite reti pubbliche, in particolare Internet. Pertanto, i dati in transito devono essere adeguatamente protetti. Questa sezione illustra la protezione delle comunicazioni di dati su Internet. 

Controllo n. 1

ERRORE DURO

Fornire la prova che:

• Tutte le configurazioni TLS sono TLS1.2 o versione successiva, come evidenziato nei requisiti di configurazione del profilo TLS. 

• Viene mantenuto un inventario di chiavi e certificati attendibili.

Requisiti di configurazione del profilo

Intento: TLS

Lo scopo di questo punto è garantire che i dati di Microsoft 365 utilizzati dall'organizzazione vengano trasmessi in modo sicuro. La configurazione del profilo TLS viene utilizzata per definire requisiti specifici di TLS che consentono di garantire che il traffico sia protetto contro gli attacchi man-in-the-middle. 

Linee guida: TLS

Il modo più semplice per dimostrarlo è eseguire lo strumento Qualys SSL Server Test su TUTTI i listener Web, inclusi quelli eseguiti su porte non standard. 

Ricordati di selezionare l'opzione "Non mostrare i risultati sulle bacheche", che impedisce l'aggiunta dell'URL al sito Web. 

I requisiti di configurazione del profilo TLS possono essere dimostrati fornendo prove di controlli individuali. Per fornire prove di impostazioni specifiche, ad esempio la disabilitazione della compressione TLS, è possibile utilizzare impostazioni di configurazione, script e strumenti software. 

Esempio di evidenza: TLS

Lo screenshot seguente mostra i risultati della scansione SSL di Qualys per il byendbagh6a0fcav.z01.azurefd.net webappfrontdoor-. 

La sezione Protocolli mostra che TLS1.2 è l'unico protocollo supportato/abilitato.

Nota: gli analisti di certificazione esamineranno l'output completo della scansione per verificare che tutti i requisiti dei requisiti di configurazione del profilo TLS siano soddisfatti. L'aspettativa sarà che vengano fornite analisi per tutti gli end point esposti pubblicamente (indirizzi IP e URL) all'ambiente back-end nell'ambito. A seconda delle prove fornite, gli analisti possono eseguire la propria scansione Qualys. 

Esempio di evidenza: TLS

Lo screenshot seguente mostra le impostazioni di configurazione per TLS nel servizio app di Azure, seguite dall'enumerazione TLS tramite PowerShell. 

Intento: chiavi e certificati

L'intenzione di questo punto è garantire che venga mantenuto un inventario completo di chiavi e certificati attendibili, che comporta l'identificazione di vari sistemi, servizi e applicazioni che dipendono da questi elementi crittografici. 

Linee guida: chiavi e certificati

Le prove devono dimostrare l'esistenza e il mantenimento di un inventario di chiavi e certificati attendibili. Inoltre, è possibile fornire prove applicabili degli strumenti usati per archiviare le chiavi e i certificati effettivi, ad esempio l'insieme di credenziali delle chiavi di Azure, i segreti dell'insieme di credenziali HashiCorp, Confluence Cloud e così via. 

Esempi di evidenza: chiavi e certificati

Lo screenshot seguente mostra che un inventario di chiavi e certificati viene mantenuto in Confluence Cloud. 

Lo screenshot seguente mostra l'elenco approvato di chiavi e certificati attendibili. Include dettagli come il certificato, le chiavi, i codici e i sistemi su cui sono installati. 

Lo screenshot seguente proviene da HashiCorp Vault. I certificati descritti e registrati nell'elenco di inventario vengono archiviati in questo insieme di credenziali online. HashiCorp Vault è uno strumento open source per la gestione dei segreti, la crittografia come servizio e la gestione degli accessi privilegiati.

Lo screenshot seguente è un estratto del certificato effettivo e delle chiavi archiviate all'interno dell'insieme di credenziali online.

Nota: l'attesa sarà che la posizione di archiviazione delle chiavi disponga di controlli di accesso appropriati. Se la chiave privata viene compromessa, qualcuno potrebbe falsificare il server con un certificato legittimo. 

Esempi di evidenza: chiavi e certificati

Lo screenshot successivo mostra prove di esempio di certificati archiviati in Azure KeyVault.  

Esempi di evidenza: chiavi e certificati

Un inventario di chiavi e certificati attendibili può essere gestito anche con Microsoft 365 Defender, che fornisce una funzionalità di inventario, come illustrato nello screenshot successivo.

Nella schermata successiva sono riportati i dettagli del certificato.

Nota: questi esempi non sono screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e data e ora per la revisione delle prove. Se sei un utente Linux, puoi farlo tramite il prompt dei comandi. 

Controllo n. 2

Fornire la prova che:

La compressione TLS è disabilitata per tutti i servizi pubblici che gestiscono le richieste Web per evitare il rapporto di compressione Info-leak Made Easy (CRIME). 

TLS HTTP Strict Transport Security (HSTS) è abilitato e configurato con un'età minima di 180 giorni in tutti i siti. 

Intento: TLS

L'attacco CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) è una vulnerabilità nella compressione dei protocolli SSL (Secure Sockets Layer)/TLS (Transport Layer Security). Per questo motivo, si raccomanda al settore di disabilitare la compressione SSL. 

HTTP Strict Transport Security (HSTS) è un meccanismo di sicurezza progettato per proteggere i siti Web da attacchi man-in-the-middle forzando le connessioni TLS tramite un campo di intestazione di risposta HTTPS denominato "Strict-Transport-Security". 

Linee guida: TLS

Ciò può essere dimostrato attraverso lo strumento Qualys SSL Labs. Esempio di evidenza: TLS

Lo screenshot seguente mostra che la compressione SSL/TLS è disabilitata. 

La schermata successiva mostra che HSTS è abilitato.

Nota: l'analista di certificazione esaminerà l'output completo per verificare che tutti i requisiti dei requisiti di configurazione del profilo TLS siano soddisfatti (fornire screenshot dell'output di scansione completo). A seconda delle prove fornite, gli analisti possono eseguire la propria scansione Qualys. 

Altri strumenti che possono essere usati per verificare che HSTS sia abilitato sono "HTTP Header Spy" e

securityheaders.com come illustrato negli esempi seguenti. Ulteriori prove

Screenshot, come le impostazioni di configurazione delle intestazioni di sicurezza, in particolare HSTS, possono essere forniti per dimostrare ulteriormente la posizione di sicurezza del footprint pubblico. 

Gli screenshot seguenti mostrano la configurazione di Frontdoor di Azure e il set di regole implementato per la riscrittura delle intestazioni. 

Lo screenshot seguente mostra l'analisi delle intestazioni di sicurezza eseguita e l'implementazione di tutte le intestazioni di sicurezza, non solo di HSTS.

Nota: se si usano le intestazioni Qualys SSL Scanner o di sicurezza, si prevede che il report completo venga fornito per una revisione. 

Dati inattivi

Quando i dati usati dalla piattaforma Microsoft 365 vengono archiviati dagli ISV, i dati devono essere adeguatamente protetti. Questa sezione illustra i requisiti di protezione dei dati archiviati in database e archivi file. 

Controllo n. 3

ERRORE DURO

Fornire la prova che:

I dati inattivi vengono crittografati in linea con i requisiti del profilo di crittografia, usando algoritmi di crittografia come: Advanced Encryption Standard (AES), Blowfish e XChaCha20. 

Dimensioni delle chiavi di crittografia di almeno 128 bit. 

Requisiti del profilo di crittografia 

Intento: alcuni algoritmi di crittografia meno recenti sono noti per contenere alcuni punti deboli crittografici che aumentano le possibilità che un attore delle minacce sia in grado di decrittografare i dati senza conoscere la chiave. Per questo motivo, lo scopo di questo controllo è garantire che vengano usati solo algoritmi di crittografia accettati dal settore per proteggere i dati M365 archiviati. 

Linee guida: La prova può essere fornita tramite screenshot, che mostrano la crittografia utilizzata per proteggere i dati M365 all'interno dei database e di altre posizioni di archiviazione. L'evidenza dovrebbe dimostrare che la configurazione della crittografia è in linea con i requisiti di configurazione del profilo di crittografia della certificazione Microsoft 365. 

Prova di esempio: lo screenshot successivo mostra che la crittografia TDE (Transparent Data Encryption) è abilitata nel database Contoso. Il secondo screenshot mostra la pagina della documentazione Microsoft Transparent data encryption for database SQL, Istanza gestita di SQL, and Azure Synapse Analytics che mostra che la crittografia AES 256 è usata per Azure TDE. 

Nota: negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente che ha effettuato l'accesso e l'ora e la data del sistema. 

Esempio di evidenza: lo screenshot seguente mostra Archiviazione di Azure configurato con crittografia per BLOB e file. La schermata successiva mostra la pagina della documentazione Microsoft, crittografia di Archiviazione di Azure per i dati inattivi, che mostra che Archiviazione di Azure usa AES-256 per la crittografia. 

Conservazione, backup ed eliminazione dei dati

Se gli ISV consumano e archiviano i dati di Microsoft 365, esiste il rischio di una compromissione dei dati nel caso in cui un attore della minaccia comprometta l'ambiente ISV. Per ridurre al minimo questo rischio, le organizzazioni devono conservare solo i dati di cui hanno bisogno per fornire i servizi e non i dati che "potrebbero" essere utili in futuro. Inoltre, i dati devono essere conservati solo per il tempo necessario a fornire i servizi per cui sono stati acquisiti. La conservazione dei dati deve essere definita e comunicata agli utenti. Quando i dati superano il periodo di conservazione definito, devono essere eliminati in modo sicuro in modo che i dati non possano essere ricostruiti o recuperati. 

Controllo n. 4

Fornire la prova che:

Un periodo di conservazione dei dati approvato è formalmente stabilito e documentato. 

Intento: Una politica di conservazione documentata e seguita è importante non solo per soddisfare alcuni obblighi legali, ad esempio la legislazione sulla privacy dei dati come, a titolo esemplificativo, il Regolamento generale sulla protezione dei dati (GDPR UE) e il Data Protection Act (DPA 2018 del Regno Unito), ma anche per limitare il rischio di un'organizzazione. Comprendendo i requisiti dei dati dell'organizzazione e per quanto tempo i dati sono necessari affinché l'azienda svolga le sue funzioni, le organizzazioni possono garantire che i dati vengano smaltiti correttamente una volta scaduta la loro utilità. Riducendo i volumi di dati archiviati, le organizzazioni stanno riducendo la quantità di dati che verrebbero esposti in caso di compromissione dei dati. Ciò limiterà l'impatto complessivo. 

Spesso le organizzazioni archiviano i dati perché è bello averli per ogni evenienza. Tuttavia, se l'organizzazione non ha bisogno dei dati per svolgere il proprio servizio o funzione aziendale, i dati non devono essere archiviati in quanto ciò aumenta inutilmente il rischio per l'organizzazione. 

L'obiettivo di questo controllo è confermare che l'organizzazione abbia formalmente stabilito e documentato un periodo di conservazione dei dati approvato per tutti i tipi di dati pertinenti. Ciò comporta non solo la specifica della durata per la quale verranno conservati i diversi tipi di dati, ma anche la definizione delle procedure per la cancellazione o l'archiviazione dei dati dopo la scadenza.  

Linee guida: Fornire la politica di conservazione dei dati completa che specifichi chiaramente per quanto tempo i dati (devono coprire tutti i tipi di dati) devono essere conservati in modo che l'azienda possa svolgere le proprie funzioni aziendali. I criteri di conservazione devono coprire chiaramente tutti i dati dei clienti archiviati nell'ambiente back-end dell'applicazione in fase di certificazione. 

Esempio di evidenza: lo screenshot successivo mostra i criteri di conservazione dei dati di Contoso. 

Nota: questi screenshot mostrano uno snapshot di un documento di criterio/processo. L'aspettativa è che gli ISV condividano l'effettiva documentazione di supporto/procedura di supporto e non forniscano semplicemente uno screenshot. 

Controllo n. 5

Fornire la prova che:

I dati vengono conservati solo per il periodo di conservazione definito, come illustrato nel paragrafo 4. 

Scopo: lo scopo di questo controllo è semplicemente quello di convalidare che i periodi di conservazione dei dati definiti vengano soddisfatti. Come già discusso, le organizzazioni possono avere l'obbligo legale di soddisfare questo aspetto, ma anche la conservazione dei dati necessari e per tutto il tempo necessario aiuta a ridurre il rischio per l'organizzazione in caso di violazione dei dati. In questo modo si garantisce che i dati non vengano conservati per un periodo eccessivamente lungo né eliminati prematuramente, entrambi fattori che potrebbero comportare rischi di varia natura, legali, operativi o legati alla sicurezza. 

Linee guida: fornire prove di screenshot (o tramite condivisione dello schermo) che dimostrino che i dati archiviati (in tutte le varie posizioni di dati, inclusi database, condivisioni di file, archivi e backup) non superano i criteri di conservazione dei dati definiti. Esempi di screenshot accettabili includono:

Database Records con un campo data, ricercato nell'ordine dei record meno recenti, e/o

Percorsi di archiviazione file che mostrano i timestamp compresi nel periodo di conservazione. Nota: tutti i dati personali o sensibili dei clienti devono essere oscurati nello screenshot. 

I record di backup che mostrano che i dati di backup vengono conservati entro il periodo di conservazione definito ed eliminati correttamente dopo questo periodo. 

Esempio di evidenza: l'evidenza seguente mostra una query SQL che mostra il contenuto della tabella di database ordinato in ordine crescente nel campo 'DATE_TRANSACTION' per visualizzare i record meno recenti all'interno del database. Ciò indica che i dati sono vecchi di meno di due mesi, ovvero non superano il periodo di conservazione definito. 

Nota: questo è un database di prova, quindi non ci sono molti dati storici al suo interno. 

Nota: negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente connesso e l'ora e la data del sistema.

Controllo n. 6

Fornire la prova che:

Sono in atto processi per eliminare in modo sicuro i dati dopo il periodo di conservazione. 

Intento: lo scopo di questo controllo è garantire che il meccanismo usato per eliminare i dati che superano il periodo di conservazione avvenga in modo sicuro. A volte i dati eliminati possono essere recuperati; Pertanto, il processo di eliminazione deve essere sufficientemente solido da garantire che i dati non possano essere recuperati una volta eliminati. 

Linee guida: se il processo di eliminazione viene eseguito a livello di codice, fornire uno screenshot dello script utilizzato per eseguire questa operazione. Se viene eseguito in base a una pianificazione, fornire uno screenshot che mostri la pianificazione. Ad esempio, uno script per eliminare i file all'interno di una condivisione di file può essere configurato come un processo CRON, screenshot del processo CRON che mostra la pianificazione e lo script che viene eseguito; e fornire lo script che mostra il comando usato. 

Esempio di evidenza: si tratta di uno script semplice che può essere usato per eliminare tutti i record di dati conservati in base alla data -WHERE DateAdd è -30 giorni che eliminerà tutti i record conservati più vecchi di 30 giorni dopo la data di conservazione dei dati selezionata. Tieni presente che avremo bisogno dello script; Prove del processo in esecuzione e dei risultati. 

Nota: negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente che ha effettuato l'accesso e l'ora e la data del sistema. 

Prova di esempio: lo screenshot seguente è stato acquisito dai criteri di conservazione dei dati di Contoso (dal controllo 4): mostra le procedure usate per l'eliminazione dei dati.

Nota: questo screenshot mostra uno snapshot di un documento di criterio/processo. L'aspettativa è che gli ISV condividano l'effettiva documentazione di supporto/procedura di supporto e non forniscano semplicemente uno screenshot. 

Esempio di esempio: in questo esempio è stato creato un runbook e una pianificazione corrispondente in Azure per eliminare in modo sicuro i record con data di fine creata a partire dai 30 giorni successivi alla scadenza dei criteri di conservazione dei record di dati. Questo processo è impostato per essere eseguito ogni mese l'ultimo giorno del mese. 

La schermata successiva mostra che il runbook è stato modificato per trovare i record e ha i comandi di eliminazione non visualizzati come lo script.

Nota: l'URL completo e il nome utente devono essere visibili per questi screenshot e gli ISV dovranno mostrare uno screenshot del conteggio dei record prima dell'eliminazione e uno screenshot del conteggio dei record dopo l'eliminazione. 

Queste schermate sono puramente esempi dei diversi modi in cui questo può essere affrontato.

Controllo n. 7

Fornire la prova che:

È presente un sistema di backup automatizzato configurato per eseguire backup a orari pianificati secondo una procedura di backup documentata. 

Le informazioni di backup vengono ripristinate periodicamente per confermare l'affidabilità e l'integrità dei dati secondo la procedura di backup documentata. 

Vengono implementati adeguati controlli di accesso e meccanismi di protezione (ad es. backup immutabili) per garantire che i backup/snapshot di sistema siano protetti da accessi non autorizzati e per garantire la riservatezza, l'integrità e la disponibilità dei dati di backup. 

Intento:

L'obiettivo di questo controllo è confermare che l'organizzazione disponga di un sistema di backup automatizzato, configurato per eseguire i backup in orari predeterminati. 

Linee guida:

Fornire screenshot delle impostazioni di configurazione della soluzione di backup che mostrino che i backup vengono eseguiti a periodi o intervalli di tempo pianificati. Se la pianificazione del backup viene eseguita automaticamente dalla soluzione, ciò può essere supportato fornendo la documentazione del fornitore. 

Esempi di evidenza:

Lo screenshot seguente si applica al Database di Azure per MySQL, che è un'istanza gestita. Indica che è stato completato un primo backup automatico.

La schermata successiva eseguita dopo che è trascorso un periodo mostra che sono stati eseguiti ulteriori backup completi. I backup sui server flessibili sono basati su snapshot in cui il primo backup snapshot viene pianificato immediatamente dopo la creazione di un server e ulteriori backup snapshot vengono eseguiti una volta al giorno. 

La schermata successiva mostra un'istantanea della documentazione online che delinea la frequenza di backup e la funzionalità di backup automatico. 

Intento: Lo scopo di questo controllo è dimostrare che le informazioni di backup non solo vengono generate secondo la pianificazione, ma sono anche affidabili e mantengono la loro integrità nel tempo. Per raggiungere questo obiettivo, verranno eseguiti test periodici sui dati di backup. 

Linee guida: le prove per soddisfare questo controllo dipenderanno dal processo e dalla procedura dell'organizzazione per testare i dati di backup. Potrebbero essere fornite prove che dimostrino che i backup sono stati testati con successo insieme ai record di completamento dei test storici. 

Esempio di evidenza: lo screenshot seguente mostra che esiste e viene mantenuta una procedura di pianificazione e ripristino di backup e che è definita una configurazione di backup per tutti i sistemi applicabili, inclusa la frequenza dei backup eseguiti nella piattaforma Confluence.

La schermata successiva mostra una pagina di record cronologici di test di backup per ognuno dei sistemi applicabili. Osserva che sul lato destro della tabella si fa riferimento ai ticket JIRA per ciascuno dei test. 

I quattro screenshot successivi mostrano il processo end-to-end di ripristino del database di Azure per MySQL da uno snapshot. Utilizzando l'opzione "Fast Restore" possiamo avviare il processo di ripristino del database SQL. 

Lo screenshot seguente mostra la pagina di configurazione in cui è possibile personalizzare il ripristino.

Dopo aver selezionato la posizione di destinazione, la rete e lo snapshot da cui verrà ripristinato il database, è possibile avviare la distribuzione. Si noti che l'istanza del database è ora denominata 'test'.

Dopo un totale di cinque minuti, il database SQL è stato ripristinato correttamente e completamente dallo snapshot di backup, come illustrato di seguito.

Una volta completato il test, in linea con il processo è stato creato un ticket JIRA per registrare il test di backup e i dettagli del ripristino eseguito. Ciò garantisce che i dati storici siano disponibili ai fini della conformità e che esistano record completi per la revisione in caso di incidente o disastro per consentire all'organizzazione di eseguire un'analisi della causa principale. 

Intento: in base al controllo precedente, i controlli di accesso dovrebbero essere implementati per limitare l'accesso solo ai singoli utenti responsabili dei dati di backup. Limitando l'accesso, si limita il rischio che vengano apportate modifiche non autorizzate, introducendo in tal modo modifiche non sicure. È necessario adottare un approccio con privilegi minimi per proteggere i backup. 

Per proteggere correttamente i dati, le organizzazioni devono essere consapevoli dei dati consumati dal loro ambiente/sistema e da dove vengono archiviati i dati. Una volta che questo è pienamente compreso e documentato. 

Le organizzazioni sono quindi in grado non solo di implementare un'adeguata protezione dei dati, ma sono anche in grado di consolidare la posizione dei dati per implementare la protezione in modo più efficace. Inoltre, quando i dati vengono consolidati nel minor numero di posizioni possibile, è molto più facile implementare un adeguato controllo degli accessi in base al ruolo per limitare l'accesso al minor numero di dipendenti necessario. 

Linee guida: È necessario fornire prove dal sistema/tecnologia utilizzata che dimostrino i permessi di accesso ai backup e alle soluzioni di backup con la documentazione di supporto dell'elenco degli accessi approvato. 

Evidenza di esempio: Negli screenshot seguenti presentati possiamo vedere che i controlli di accesso sono implementati nell'istanza del database per limitare l'accesso solo agli individui autorizzati in base al ruolo lavorativo. 

Esempi di evidenza:

Database di Azure SQL e Istanze gestite di Azure SQL I backup automatici sono gestiti da Azure e la loro integrità è responsabilità della piattaforma di Azure; nessun utente ha accesso a tali backup e vengono crittografati inattivi senza possibilità di attacchi ransomware. Vengono anche replicati in altre aree per la protezione. 

Gestione dell'accesso ai dati

L'accesso ai dati deve essere limitato al minor numero di persone necessario per ridurre le possibilità che i dati vengano compromessi accidentalmente o accidentalmente. L'accesso ai dati e alle chiavi di cifratura dovrebbe essere limitato agli utenti che hanno una legittima necessità commerciale di accedervi per svolgere il loro ruolo professionale. Dovrebbe essere implementato un processo ben documentato e consolidato per richiedere l'accesso. L'accesso ai dati e alle chiavi di crittografia dovrebbe seguire il principio dei privilegi minimi. 

Controllo n. 8

Fornire la prova che:

Viene mantenuto un elenco di utenti con accesso ai dati e/o alle chiavi di crittografia, inclusa la motivazione aziendale per ogni persona. 

Questo elenco di utenti è stato formalmente approvato in base ai privilegi di accesso richiesti per la loro funzione lavorativa. 

Gli utenti sono configurati con i privilegi descritti nelle approvazioni. 

Nota: verrà selezionato un campione di utenti per dimostrare i punti B e C.

Intento:

Le organizzazioni devono limitare l'accesso ai dati e alle chiavi di crittografia al minor numero possibile di dipendenti. Lo scopo di questo controllo è garantire che l'accesso dei dipendenti ai dati e/o alle chiavi di crittografia sia limitato ai dipendenti con una chiara necessità aziendale per tale accesso. 

Linee guida:

Devono essere forniti documentazione o screenshot di sistemi interni che documentano tutti i dipendenti con accesso ai dati e/o alle chiavi di crittografia, insieme alla giustificazione aziendale del motivo per cui questi individui hanno accesso. Questo elenco verrà utilizzato dall'analista di certificazione per campionare gli utenti per i controlli successivi. 

Esempi di evidenza:

Il documento seguente mostra l'elenco documentato di utenti con accesso ai dati e la motivazione aziendale.

Nota: questo screenshot mostra un documento di criteri/processi, l'aspettativa è che gli ISV condividano l'effettiva documentazione di supporto/procedura di supporto. 

Intento: il processo per concedere l'accesso ai dati e/o alle chiavi di crittografia deve includere l'approvazione, garantendo che l'accesso di un individuo sia necessario per la sua funzione lavorativa. Ciò garantisce che i dipendenti senza un vero motivo per l'accesso, non ricevano un accesso non necessario. 

Linee guida: In genere, le prove fornite per il controllo precedente possono aiutare a supportare questo controllo. Se non c'è un'approvazione formale sulla documentazione fornita, la prova può consistere in una richiesta di modifica generata e approvata per l'accesso all'interno di uno strumento come Azure DevOps o Jira. 

Esempio di evidenza: questo set di immagini mostra i ticket Jira creati e approvati per il controllo (i) per concedere o negare l'accesso a dati sensibili e/o chiavi di crittografia. Questa immagine mostra che è stata creata una richiesta in Jira per ottenere l'approvazione giornaliera Sam per le chiavi di crittografia nell'ambiente back-end del sistema. Questo viene fatto come passo successivo in cui è stata ottenuta l'autorizzazione scritta. 

Ciò dimostra che la richiesta di concedere l'accesso a Sam Daily è stata approvata da Jon Smith, una persona della direzione. (Si prega di notare che l'approvazione deve provenire da qualcuno con l'autorità sufficiente per consentire la richiesta di modifica, non può essere un altro sviluppatore).

Quanto sopra mostra un flusso di lavoro in Jira per questo processo. Tieni presente che non è possibile aggiungere nulla come Eseguito a meno che non sia stato eseguito il processo di approvazione che è automatizzato e quindi non può essere ignorato.

Il consiglio di Project mostra ora che è stata data l'approvazione per l'accesso di Sam Daily alle chiavi di crittografia. Il seguente arretrato mostra l'approvazione della richiesta di Sam Daily e la persona incaricata di svolgere il lavoro.

Per soddisfare i requisiti di questo controllo, è necessario mostrare tutti questi screenshot o prove simili/equivalenti applicabili con una spiegazione per dimostrare che hai soddisfatto il requisito di controllo. 

Nota: negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente che ha effettuato l'accesso e l'ora e la data del sistema. 

Esempio di evidenza: nell'esempio successivo, l'accesso dell'amministratore e le autorizzazioni di controllo completo sono state richieste a un utente per il database di produzione. La richiesta è stata inviata per l'approvazione come si può vedere a destra dell'immagine ed è stata approvata come mostrato a sinistra. 

L'immagine successiva indica che l'accesso è stato approvato e approvato come eseguito.

Nota: negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente che ha effettuato l'accesso e l'ora e la data del sistema. 

Finalità Lo scopo di questo punto secondario è confermare che l'accesso ai dati e/o alla chiave di crittografia sia configurato in base a quanto documentato. 

Linee guida: La prova potrebbe essere fornita tramite uno screenshot che mostra i privilegi di accesso ai dati e/o alle chiavi di crittografia concessi agli individui campionati. Le prove devono coprire tutte le posizioni dei dati. 

Esempio di evidenza: questa schermata mostra le autorizzazioni concesse all'utente "Giovanni Rossi" che sarebbero incrociate

a cui viene fatto riferimento nella richiesta di approvazione per lo stesso utente in base all'evidenza per il controllo precedente. 

Nota: l'esempio seguente non è uno screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e ora e data per la revisione delle prove. Se sei un utente Linux, puoi farlo tramite il prompt dei comandi. 

Controllo n. 9

Fornire la prova che:

Viene mantenuto un elenco di tutte le terze parti con cui i dati sono condivisi. 

Sono in vigore accordi di condivisione dei dati con tutte le terze parti che consumano dati. 

Intento: quando vengono usate terze parti per l'archiviazione o l'elaborazione dei dati di Microsoft 365, queste entità possono rappresentare un rischio significativo. Le organizzazioni dovrebbero sviluppare un buon processo di due diligence e gestione da parte di terze parti per garantire che queste terze parti archivino/elaborino i dati in modo sicuro e per garantire che rispettino eventuali obblighi legali che potrebbero avere, ad esempio in qualità di responsabili del trattamento dei dati ai sensi del GDPR. 

Le organizzazioni devono mantenere un elenco di tutte le terze parti con cui condividono i dati con alcuni o tutti i seguenti:

Quali servizi vengono forniti

Quali dati vengono condivisi

Perché i dati vengono condivisi

Informazioni di contatto chiave (ad esempio, contatto primario, contatto per la notifica della violazione, DPO, ecc.)

rinnovo/scadenza del contratto

Obblighi legali/di conformità (ad esempio, GDPR, HIPAA, PCI DSS, FedRAMP, ecc.)

Linee guida: fornire la documentazione che illustra nel dettaglio TUTTE le terze parti con cui vengono condivisi i dati di Microsoft 365. 

Nota: se terze parti non vengono utilizzate, ciò dovrà essere confermato per iscritto (e-mail) da un membro del team di leadership senior. 

Esempi di evidenza:

Nota: - Negli esempi precedenti non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviati dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente di qualsiasi accesso e l'ora e la data del sistema. 

Esempi di evidenza:

Lo screenshot seguente mostra un esempio di messaggio di posta elettronica di un membro del team di leadership senior che conferma che non vengono usate terze parti per elaborare i dati di Microsoft 365. 

Nota: - In questi esempi non sono stati utilizzati screenshot completi, tuttavia TUTTI gli screenshot delle prove inviate dall'ISV devono essere screenshot completi che mostrino l'URL, l'utente che ha effettuato l'accesso e l'ora e la data del sistema. 

Intento: quando i dati di M365 vengono condivisi con terze parti, è importante che i dati vengano gestiti in modo appropriato e sicuro. Devono essere stipulati accordi di condivisione dei dati per garantire che le terze parti elaborino i dati solo in base alle esigenze e che comprendano i loro obblighi di sicurezza. La sicurezza di un'organizzazione è forte solo quanto l'anello più debole. L'intento di questo controllo è quello di garantire che le terze parti non diventino un anello debole dell'organizzazione. 

Linee guida: fornire gli accordi di condivisione dei dati in essere con le terze parti. 

Esempio di evidenza: lo screenshot successivo mostra un esempio semplicistico di accordo di condivisione dei dati. 

Nota: il contratto completo deve essere condiviso e non uno screenshot.

Privacy

La conformità alla privacy e la gestione delle informazioni sono essenziali per proteggere i diritti delle persone e garantire una gestione responsabile dei dati. Affinché un'organizzazione possa stabilire un efficace sistema di informazioni sulla privacy, deve essere consapevole dei dati personali in suo possesso e dello scopo dell'elaborazione e dell'archiviazione di tali dati. Un'organizzazione dovrebbe mappare il flusso di informazioni e il modo in cui questo viene elaborato, riconoscendo che potrebbero verificarsi diversi tipi di elaborazione. 

Controllo n. 10 – Dati personali

Fornire prove del fatto che l'organizzazione:

Mantiene un inventario aggiornato di tutti i dati personali raccolti, elaborati e archiviati, incluso lo scopo di ogni elemento di dati.  

Progetta moduli di raccolta dati in modo da includere solo i campi necessari per le finalità aziendali e implementa in modo appropriato i campi obbligatori e facoltativi.  

Sviluppa e applica criteri che specificano i tipi di dati personali che possono essere raccolti e gli scopi per i quali possono essere utilizzati.  

Consente agli utenti di rifiutare esplicitamente l'elaborazione o la visualizzazione generale dei propri dati personali, non essenziali per l'azienda.  

Intento: lo scopo di questo controllo è garantire il rispetto della privacy dei dati relativa alla raccolta di dati, garantire che vi sia una giustificazione per l'acquisizione dei dati ed essere trasparenti su cosa e perché i dati vengono raccolti. È altresì importante che gli utenti (interessati) abbiano la possibilità di rifiutare esplicitamente l'elaborazione.   

Linee guida: Questo controllo potrebbe essere evidenziato come segue:

A) Fornire una versione aggiornata del Registro delle attività di trattamento (RoPA) dell'organizzazione (vedere l'articolo 30 del GDPR) o un documento simile che descriva in dettaglio gli elementi di dati e le finalità del trattamento (vedere l'articolo 5.1.b del GDPR).  

Nella maggior parte dei casi, si tratta di un foglio di calcolo di Excel, che potrebbe essere estratto da strumenti come OneTrust.  

Se il file è troppo grande o contiene dati sensibili, potrebbe essere fornito un estratto, che mostra tutti i campi di dati per un determinato campione di dati, che può essere parzialmente oscurato purché le prove possano fornire la garanzia che il RoPA sia in atto.  

Non conforme: i record non esistono, sono obsoleti/obsoleti o mancano i campi chiave.  

B) Ai fini della "minimizzazione dei dati" (vedere l'articolo 5.1.c del GDPR), fornire tutti i moduli utilizzati per ottenere i dati, sia online, utilizzando tablet o dispositivi simili (ad esempio in una conferenza), sia cartacei. Questi potrebbero essere vuoti/modelli.  

Non conforme: i moduli hanno campi obbligatori che non sono necessari per lo scopo previsto del trattamento. Ad esempio, per richiedere numeri di telefono, età o sesso, per inviare una brochure via e-mail o a un indirizzo postale.   

C) Ai fini della "liceità, correttezza e trasparenza" (vedi articolo 5.1.a) del GDPR, l'Informativa sulla privacy (destinata ai dipendenti), l'Informativa sulla privacy (destinata agli utenti/clienti) deve essere in vigore. In genere, l'Informativa sulla privacy deve essere disponibile pubblicamente sul sito Web dell'organizzazione.   

Non conforme: i criteri non esistono o mancano elementi chiave.  

Elementi chiave:

Informativa sulla privacy: raccolta e utilizzo delle informazioni, elementi di dati trattati, finalità del trattamento, liceità del trattamento, trasferimenti di dati in altri paesi, diritti degli interessati, conservazione e conservazione dei dati.   

D) Per il meccanismo di opt-out (vedere l'articolo 4.11 del GDPR, l'articolo 6 del GDPR e l'articolo 7 del GDPR), in genere su una pagina web. Controlla la navigazione che l'utente dovrebbe seguire per raggiungere quella pagina (ad esempio, è facile da trovare?).  

Non conforme: nessuna funzionalità di rifiuto esplicito o rifiuto esplicito "generico", senza granularità.  

Esempi di evidenza:

Per A):

Per B):

Per C):

Per D):

Controllo n. 11 – Consapevolezza dell'utente

Fornire prove che gli utenti conoscono:

Chi ha accesso ai propri dati. 

Chi ha accesso agli spazi in cui sta lavorando. 

Chi potrebbe accedere ai propri dati tramite la condivisione o i flussi di dati in modo che possano prendere decisioni informate. 

Intento: lo scopo di questo controllo è dimostrare il rispetto del principio di "trasparenza" della protezione dei dati (vedere l'articolo 5.1.a del GDPR). 

Linee guida: Per dimostrare che ciò è in atto, idealmente dovrebbe essere presente e registrata una qualche forma di riconoscimento da parte dell'utente (ad esempio aver letto l'Informativa sulla privacy). 

In pratica, proprio che la Privacy Policy (per i dipendenti), l'Informativa sulla Privacy (per gli utenti e i clienti), forniscono sufficienti dettagli su quanto segue:

- Con chi vengono condivisi i dati personali (responsabili del trattamento, sub-responsabili del trattamento, terze parti, appaltatori, ecc.). 

Non conforme: Non esistono riconoscimenti o l'Informativa sulla privacy/Informativa sulla privacy non esiste. 

Esempi di evidenza:

OPPURE

Controllo n. 12 – Accordi sul trattamento dei dati (DPA)

Fornire la prova dell'Accordo sul trattamento dei dati, che dovrebbe contenere un elenco di tutte le terze parti/sub-responsabili del trattamento approvati. 

Intento: Garantire la trasparenza con gli interessati, assicurando che siano informati su quali terze parti/sub-responsabili del trattamento potrebbero avere accesso ai loro dati, il ruolo che svolgono nel trattamento (titolare del trattamento, responsabile del trattamento), le rispettive responsabilità e i meccanismi di sicurezza in atto. 

Inoltre, quando la condivisione dei dati comporterebbe trasferimenti di dati in territori al di fuori dell'UE (ai sensi del GDPR), i dettagli del meccanismo per garantire che i trasferimenti siano legittimi. (Vedere Articolo 5 del GDPR e Articolo 44-50 del GDPR)

Per il GDPR, i territori per l'elaborazione devono soddisfare una delle condizioni seguenti:

- Essere uno Stato membro dell'Unione Europea. 

- Essere considerato dalla Commissione europea come "garanzie adeguate". L'elenco attuale è disponibile qui: Adeguatezza della protezione dei dati per i paesi extra UE 

A partire dal 13 giugno 2025:

• Fa parte del Framework per la privacy dei dati (DPF) ed è elencato qui: Framework per la privacy dei dati 

• Disporre di norme vincolanti d'impresa (BCR). 

• Avere clausole contrattuali standard (CPC). 

Linee guida: La prova potrebbe essere fornita tramite campionamento di un paio di accordi sul trattamento dei dati (DPA) con sub-responsabili del trattamento esistenti. In alcuni casi, le organizzazioni potrebbero non avere autorità di protezione dei dati, ma avrebbero addendum ai contratti o "clausole sulla privacy". 

Non conforme:

• L'elenco di terze parti/sub-responsabili del trattamento non è presente. 

• Non vengono forniti dettagli sui paesi destinatari. 

• I paesi non sono elencati come "paesi adeguati" e non ci sono BCR o SCC in vigore. 

Prova di esempio: questo esempio mostra un esempio di autorità per la protezione dei dati da IAPP, o la prova potrebbe essere un documento correlato che elenca le parti con cui vengono condivisi i dati. 

Verificare inoltre i meccanismi per il trasferimento dei dati al di fuori dell'UE.

Controllo n. 13 – Valutazioni d'impatto sulla protezione dei dati (DPIA)

Fornire prove del fatto che l'organizzazione esegue la valutazione d'impatto sulla protezione dei dati (DPIA)

     OPPURE

Specificare il nome della valutazione correlata alla privacy e alla protezione dei dati a cui è collegata questa revisione della privacy. 

Intento: lo scopo di questo controllo è garantire l'esecuzione di valutazioni sui potenziali rischi per i diritti e le libertà degli individui, in particolare in relazione all'introduzione di nuove tecnologie o a nuovi usi di tecnologie esistenti. (Vedere l'articolo 35 del GDPR)

Linee guida: Questo controllo verrebbe valutato esaminando un DPIA recente o la relativa documentazione di valutazione. 

Non conforme:

Una DPIA dovrebbe avere i seguenti elementi:

• Identificazione della necessità di una DPIA. 

• Descrizione del trattamento previsto, inclusi ambito, contesto e finalità. 

• Valutazione della necessità e della proporzionalità. 

• Identificazione e valutazione dei rischi. 

• Identificazione delle misure per ridurre il rischio. 

• Risultati registrati. 

Se una delle operazioni precedenti risulta mancante o viene eseguita solo a livello superficiale, questo controllo può essere contrassegnato come non conforme. 

Esempi di evidenza:

Il modello completo di una DPIA può essere trovato sul sito web dell'ICO qui dpia-template.docx

Controllo n. 14 – Dati biometrici

L'applicazione interagisce con i dati biometrici? In caso affermativo,

Fornire la prova che i dati biometrici hanno superato la revisione legale, sono protetti e gli utenti vengono informati e viene data loro la possibilità di acconsentire o rifiutare esplicitamente la raccolta dei dati biometrici. 

Intento: questo controllo è interessato a garantire un'adeguata protezione dei dati biometrici, che ai sensi dell'articolo 9 del GDPR sono classificati come una categoria speciale di dati.  L'uso di dati biometrici è stato sottoposto a un'analisi di legittimità. 

Linee guida: l'uso dei dati biometrici deve essere sottoposto a revisione legale, quindi deve essere fornito come parte della raccolta delle prove. Se non esiste, richiedi il modello che verrebbe utilizzato (per verificarne l'idoneità). 

Non conforme:

La revisione legale sul trattamento dei dati biometrici dovrebbe contenere quanto segue:

• Basi giuridiche per il trattamento (una o più delle seguenti opzioni):

Consenso	Esecuzione di un contratto	Altri obblighi legali
Consenso	Esecuzione di un contratto	Altri obblighi legali
Interessi vitali	Interesse pubblico	Interesse legittimo

• Elencare una condizione valida per il trattamento dei dati biometrici (una o più delle seguenti condizioni):

Consenso esplicito dell'utente	Occupazione o sicurezza sociale
Consenso esplicito dell'utente	Occupazione o sicurezza sociale
Protezione degli interessi vitali	Attività legittime
Dati personali resi manifestamente pubblici dall'interessato	Costituzione, esercizio o difesa di un diritto in sede giudiziaria
Rilevante interesse pubblico	Medicina preventiva o del lavoro
Interesse pubblico nel settore della sanità pubblica	Scopi di archiviazione nell'interesse pubblico, ricerca scientifica o storica

• Considerazione sull'uso di alternative, invece dei dati biometrici.

Se una delle operazioni precedenti risulta mancante o viene eseguita solo a livello superficiale, questo controllo può essere contrassegnato come non conforme.

Esempi di evidenza:

Fonti:

- GDPR Articolo 9 – Trattamento di categorie speciali di dati: Art. 9 GDPR – Trattamento di categorie speciali di dati personali - Regolamento generale sulla protezione dei dati (GDPR)

- ICO "Come trattiamo legalmente i dati biometrici?": come trattiamo legalmente i dati biometrici? | ICO

 

Controllo n. 15 - Informazioni dettagliate sui dati

Fornire prove che le metriche mostrano solo dati aggregati e anonimi senza dati identificabili individualmente. Il tenant deve essere in grado di configurare il limite inferiore del livello di aggregazione preferito, con un minimo assoluto di cinque consentiti dal prodotto. Fornire la prova che i dati biometrici hanno superato la revisione legale, sono protetti e gli utenti vengono informati e viene data loro la possibilità di acconsentire o rifiutare esplicitamente la raccolta dei dati biometrici. 

Intento: lo scopo di questo controllo è garantire che siano stati implementati e mantenuti lo stato dei dati anonimizzati e pseudonimizzati per l'intero ciclo di vita dei dati. (Vedi

Linee guida: Per dimostrare che questo controllo è in atto, le prove tramite GUI o CLI dovrebbero fornire per dimostrare:

• Configurazione a livello di utente per i limiti minimi dei livelli di aggregazione. 

• Esempio di metriche. 

Valuta se l'utente può configurare una soglia per i livelli di aggregazione preferiti su un minimo di 5. L'evidenza dovrebbe dimostrare che solo anonimizzato è presente nel campione di metriche. 

Non conforme:

• Gli utenti non sono in grado di personalizzare i livelli di aggregazione fino a un minimo di 5, né ci si può aspettare le competenze tecniche necessarie per farlo dall'utente tipico. 

• I dati personali sono presenti nel campione di metriche; ad esempio: nome, cognome, carta d'identità, numero cliente, numero di telefono, indirizzo e-mail, indirizzo postale, coordinate bancarie, parenti stretti, ecc. 

Esempio di evidenza: catture di schermata delle impostazioni di configurazione, con i dettagli specifici. 

Esempio di metriche raccolte. Forse chiedi informazioni sul processo per ottenere l'anonimato. 

GDPR

La maggior parte delle organizzazioni elaborerà dati potenzialmente di cittadini europei (interessati). Se vengono elaborati i dati di QUALSIASI interessato, le organizzazioni dovranno soddisfare il Regolamento generale sulla protezione dei dati (GDPR). Questo vale sia per i titolari del trattamento dei dati (che stai acquisendo direttamente da tali dati) sia per i responsabili del trattamento dei dati (stai elaborando questi dati per conto di un titolare del trattamento). Sebbene questa sezione non copra l'intero regolamento, affronta alcuni degli elementi chiave del GDPR per aiutare a ottenere una certa garanzia che l'organizzazione stia prendendo sul serio il GDPR. 

Controllo n. 16

Fornire prove che dimostrino il rispetto dei diritti dell'interessato mostrando:

• Facilitazione delle richieste di accesso dei soggetti (SAR): documentazione che conferma che gli interessati sono informati del loro diritto di accedere ai dati personali e possono inviare richieste di accesso ai soggetti all'organizzazione. 

• Individuazione dei dati e adempimento SAR: prova della capacità dell'organizzazione di individuare e recuperare tutti i dati personali relativi a un singolo interessato in tutti i sistemi e repository in risposta a un SAR. 

Intento: lo scopo di questo controllo è garantire che siano in atto meccanismi adeguati per consentire agli interessati di effettuare richieste sui propri dati personali detenuti dall'organizzazione e che l'adempimento delle richieste legittime sia completo. (Vedere l'articolo 15 del GDPR). 

Linee guida: A) L'Informativa sulla privacy dovrebbe contenere dettagli su come effettuare un SAR, che potrebbe utilizzare i seguenti metodi:

• Uso di un modulo Web fornito dall'organizzazione

• Uso di un indirizzo di posta elettronica fornito dall'organizzazione

• Uso di un numero di telefono/webchat fornito dall'organizzazione

• Utilizzo di un'autorità di vigilanza (ad es. l'ICO nel Regno Unito)

Richiedere la prova del metodo in atto; Le catture di schermata dovrebbero essere sufficienti. 

B) Una RoPA o un documento simile può essere utilizzato per identificare i luoghi in cui risiedono i dati personali relativi all'interessato, sia digitali che come parte di sistemi di archiviazione (fisici). 

In alternativa, gli esercizi di e-discovery possono ottenere lo stesso risultato. 

Richiedi prove del processo/flusso di lavoro che verrebbe utilizzato per eseguire una SAR e una spiegazione su come è stato determinato che il processo è completo e non perderà alcun dato personale relativo all'interessato. 

Non conforme:

A) Nessuna informazione viene fornita sul sito web dell'organizzazione (in genere nell'Informativa sulla privacy). 

B) Le prove indicano che il processo di raccolta dei dati personali non è completo o può mancare di dettagli tecnici (ad esempio, non vengono forniti nomi/posizioni per i database). 

Esempi di evidenza:

A) Di seguito sono riportati esempi di quali prove potrebbero essere fornite per coprire il punto A). 

• Modulo Web:

Fonte: Richiesta di accesso dei soggetti - Police Care UK

• Indirizzo Email/numero di telefono:

Fonte: Quale? Informativa sulla privacy - Quale?

• Chat web:

Fonte: Effettuare una richiesta di accesso dell'interessato all'HMRC - GOV.UK

• Tramite un'autorità di vigilanza (ad es. l'ICO):

Fonte: Effettuare la richiesta di accesso dell'interessato | ICO 

B) Fornito artefatti di prova Dettagliare i flussi di lavoro o le descrizioni dei processi con sufficienti dettagli tecnici, che potrebbero plausibilmente essere utilizzati per soddisfare il SAR.    Lo screenshot seguente mostra prove di esempio della capacità di un'organizzazione di individuare e recuperare tutti i dati personali relativi a un interessato specifico da un database Azure SQL in risposta a una richiesta di accesso dell'interessato (SAR). L'esempio mostra un amministratore che esegue una stored procedure predefinita all'interno del Azure SQL Editor di query per recuperare i record associati a un identificatore univoco dell'interessato in più tabelle del database di produzione. 

Lo screenshot seguente mostra prove di esempio della capacità di un'organizzazione di individuare e recuperare tutti i dati personali relativi a un interessato specifico da un account di archiviazione di Azure in risposta a una richiesta di accesso dell'interessato (SAR). L'esempio mostra un amministratore che individua tutti i documenti associati a un identificatore univoco dell'interessato all'interno di Archiviazione BLOB di Azure, dimostrando la capacità dell'organizzazione di identificare e recuperare i dati personali non strutturati archiviati nell'ambiente.

Controllo n. 17

ERRORE DURO

Fornire l'Informativa sulla privacy che deve contenere tutti gli elementi richiesti come segue:

• L'identità e i dettagli di contatto dell'organizzazione e il Responsabile della protezione dei dati (DPO), se applicabile. 

• I tipi di dati personali gestiti dall'organizzazione (nome, cognome, numero cliente, indirizzo di posta elettronica, numero di telefono, ecc.). Inoltre, le fonti di dati personali (ad esempio da dove provengono i dati personali), nel caso in cui l'organizzazione non li abbia ottenuti direttamente dagli interessati. 

• Le finalità del trattamento dei dati personali. 

• La base giuridica del trattamento dei dati personali (compresi gli interessi legittimi, se pertinenti). 

• Parti con cui l'organizzazione condivide i dati personali. 

• Dettagli sul periodo di conservazione dei dati personali. 

• Dettagli sui diritti degli interessati:

• Diritto di essere informato

• Diritto di accesso

• Diritto di rettifica

• Diritto alla cancellazione

• Diritto alla limitazione del trattamento

• Diritto alla portabilità dei dati

• Diritto di opposizione

• Diritti in relazione al processo decisionale automatizzato, compresa la profilazione

• I dettagli relativi a qualsiasi trasferimento di dati personali verso un paese terzo e le misure di sicurezza adottate. 

• Il diritto di presentare un reclamo a un'autorità di controllo, fornendo i dettagli di contatto dell'autorità di controllo (ad esempio l'ICO nel Regno Unito). 

Intento: L'intento è garantire che l'Informativa sulla privacy pubblicata contenga dettagli sufficienti includendo gli elementi e i principi di cui sopra, ai sensi del Capitolo 3 del GDPR. 

Linee guida: in base al controllo 10.c, in base al quale è necessario pubblicare un'informativa sulla privacy che copra il servizio incluso nella certificazione Microsoft 365. La presente Informativa sulla privacy deve contenere gli elementi e i principi sopra evidenziati. 

Non conforme:

Fare riferimento a Controllo 10.c. 

Esempi di evidenza:

Nota: La tua Informativa sulla privacy deve riflettere accuratamente la tua applicazione e il tuo sito web. L'avviso deve essere pubblicato e disponibile al pubblico sul sito web della tua azienda.  

HIPAA (Legge sulla portabilità e la responsabilità dell'assicurazione sanitaria)

L'Health Insurance Portability and Accountability Act del 1996 (HIPAA) è una legislazione federale applicabile ai cittadini americani e alle organizzazioni sanitarie. È importante notare che questa legislazione copre anche tutte le organizzazioni al di fuori degli Stati Uniti che elaborano dati sanitari di cittadini americani. L'introduzione della legislazione ha incaricato il Segretario del Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS) di sviluppare regolamenti che proteggano la privacy e la sicurezza di determinate informazioni sanitarie. Alcune organizzazioni possono elaborare dati che sono informazioni sanitarie potenzialmente protette (ePHI), ovvero informazioni sanitarie identificabili individualmente trasmesse da media elettronici, conservate in media elettronici o trasmesse o mantenute in qualsiasi altra forma o mezzo. Quando vengono elaborati i dati sanitari di QUALSIASI interessato, le organizzazioni dovranno soddisfare HIPAA. 

L'HIPAA ha due atti legislativi che devono essere considerati: "The Privacy Rule", o Standard for Privacy of Individually Identifiable Health Information, che delinea gli standard nazionali per la protezione di determinate informazioni sanitarie, e "The Security Standards" per la protezione delle informazioni sanitarie elettroniche protette, nota anche come "Security Rule". Quest'ultimo stabilisce una serie nazionale di standard di sicurezza per la protezione di determinate informazioni sanitarie detenute o trasferite in formato elettronico. 

Da una panoramica di alto livello, "La regola di sicurezza" è un'implementazione pratica delle protezioni offerte dalla "Regola sulla privacy". Delinea le misure tecniche e non tecniche che le "entità coperte" devono attuare per garantire la sicurezza delle "informazioni sanitarie elettroniche protette" (e-PHI) degli individui. Sebbene questa sezione non copra l'intero regolamento, affronta alcuni degli elementi chiave dell'HIPAA per aiutare a ottenere una certa garanzia che l'organizzazione soddisfi la conformità al requisito e che l'organizzazione stia salvaguardando le informazioni sanitarie che elabora. 

Controllo n. 18

Fornire prove che verifichino la conformità dell'organizzazione all'Health Insurance Portability and Accountability Act (HIPAA) fornendo prove che:

• Informativa sulle pratiche sulla privacy (NPP) e sulla formazione della forza lavoro: è in vigore un avviso sulle pratiche sulla privacy e viene istituito un programma di formazione della forza lavoro sulla gestione delle informazioni sanitarie protette (PHI) ai sensi dell'HIPAA per dipendenti, appaltatori, fornitori e altre parti interessate. 

• Salvaguardie per le informazioni sanitarie protette elettroniche (ePHI): l'organizzazione ha implementato misure di sicurezza amministrative, fisiche e tecniche come richiesto dalla norma di sicurezza HIPAA per garantire la riservatezza, l'integrità e la disponibilità di tutte le PHI elettroniche (ePHI) che crea, riceve, mantiene o trasmette. 

• Politiche di gestione del rischio: l'organizzazione dispone di politiche e misure di gestione del rischio per proteggersi da qualsiasi minaccia o pericolo ragionevolmente previsto per la sicurezza o l'integrità di ePHI. 

Intento: L'intento di questo punto è garantire che le organizzazioni abbiano stabilito protocolli che fungano da procedure standard per la gestione delle informazioni sanitarie, la gestione delle emergenze e delle interruzioni dei servizi e l'accesso del personale alle informazioni sanitarie e alla formazione. Inoltre, le organizzazioni sono tenute a mantenere e delineare queste garanzie amministrative come parte del loro programma di sicurezza HIPAA. Questo è un aspetto cruciale della conformità alle normative HIPAA. 

Linee guida: Ciò sarebbe dimostrato fornendo la documentazione stabilita dall'organizzazione che delinea la politica e la procedura HIPAA. Gli analisti di certificazione esamineranno questo aspetto per garantire che tutte le informazioni fornite nell'ambito del controllo siano affrontate. 

Esempio di evidenza: gli screenshot mostrano snapshot di un criterio HIPAA. Nota: l'aspettativa è che gli ISV condividano l'effettiva documentazione di supporto/procedura di supporto e non forniscano semplicemente uno screenshot. 

Nota: l'aspettativa è che un ISV condivida l'effettiva documentazione completa della politica/procedura di supporto e non fornisca semplicemente uno screenshot. 

Intento:

Al fine di comprendere l'intento di questo punto e garantire la conformità alla Regola di sicurezza, le "entità coperte" devono prima sapere come sono definiti i termini di riservatezza, integrità e disponibilità ai sensi del § 164.304:

Riservatezza: "la proprietà che i dati o le informazioni non siano resi disponibili o divulgati a persone o processi non autorizzati". 

Integrità: "la proprietà che i dati o le informazioni non siano stati alterati o distrutti in modo non autorizzato". 

Disponibilità: "la proprietà che i dati o le informazioni siano accessibili e utilizzabili su richiesta da una persona autorizzata". 

L'intento di questo requisito è che le organizzazioni implementino salvaguardie/misure tecniche come l'accesso, l'audit, l'integrità e i controlli di trasmissione all'interno dell'infrastruttura IT per garantire la riservatezza delle ePHI mantenendone l'integrità e la disponibilità per gli utenti autorizzati. 

Linee guida:

La prova può essere fornita mediante le impostazioni di configurazione dei meccanismi di protezione utilizzati per garantire che i dati ePHI siano protetti in linea con l'obbligo di controllo. Tali meccanismi possono includere controlli di accesso, procedure di accesso di emergenza, RBAC, crittografia ecc. 

Esempi di controlli: controlli di accesso e integrità

Lo screenshot successivo mostra che esiste un elenco di accesso autorizzato di persone che dispongono delle autorizzazioni per gestire le posizioni di archiviazione delle ePHI ed è mantenuto all'interno del documento di politica HIPAA. Inoltre, negli screenshot che seguono l'elenco di inventario approvato, è possibile osservare che l'accesso in scrittura in tutto il cluster è limitato, con solo l'amministratore e l'analista di manutenzione del database in grado di leggere e scrivere nel cluster. 

Lo screenshot successivo tratto da uno dei database di archiviazione ePHI in Atlas Mongo dimostra che solo gli utenti autorizzati hanno l'accesso documentato e che tutti gli account hanno ID utente univoci per garantire la responsabilità. 

Il primo screenshot mostra la posizione di archiviazione principale/cluster di database per ePHI. 

Il secondo screenshot mostra che gli utenti approvati hanno documentato solo i ruoli e l'accesso.

I due screenshot successivi mostrano una visualizzazione più granulare di ognuno dei ruoli assegnati e di tutte le autorizzazioni associate, che sono in linea con l'approvazione dell'accesso precedente.

Ogni ruolo personalizzato ha un set di autorizzazioni e un ambito di accesso.

Infine, lo screenshot successivo dimostra dal punto di vista della rete che solo l'intervallo IP autorizzato, ovvero la rete aziendale protetta, è autorizzato ad accedere al cluster.

Esempi di controlli: controlli di audit

Questi screenshot mostrano l'implementazione della registrazione e degli avvisi per il cluster di database. La prima schermata mostra che gli avvisi sono abilitati. Si noti che l'aspettativa è che le prove fornite mostrino anche le regole di allerta che sono state impostate in base alla necessità/implementazione dell'organizzazione. Il secondo screenshot mostra l'abilitazione del controllo del database. 

La schermata successiva mostra la cronologia degli accessi al cluster di database da registrare. L'aspettativa è che gli avvisi siano impostati e basati sui registri di controllo e qualsiasi accesso non autorizzato che non soddisfi le condizioni predefinite attiverà un avviso.

I due screenshot finali mostrano che i log di controllo vengono generati per il cluster di database e che i log possono essere esportati per l'analisi.

Si noti che l'aspettativa è che esista un processo in atto per l'analisi dei log di controllo generati, è necessario fornire anche la prova del processo di revisione. Se ciò viene ottenuto a livello di codice, è necessario fornire screenshot delle impostazioni di configurazione dell'inserimento del registro nella piattaforma/soluzione di registrazione utilizzata, nonché screenshot delle regole, per la revisione. 

Esempi di evidenza: controlli di crittografia e trasmissione

Gli screenshot successivi mostrano che la posizione di archiviazione ha dati inattivi crittografati per impostazione predefinita. Si noti che se la crittografia non viene eseguita dalla piattaforma usata per impostazione predefinita e le chiavi di crittografia sono in uso, ci si aspetta che tali chiavi siano adeguatamente protette e vengono fornite prove per dimostrarlo. 

I due screenshot successivi mostrano che la posizione di archiviazione ha dati in transito crittografati per impostazione predefinita. Il primo screenshot mostra che un'API dati è abilitata con autorizzazioni di "lettura e scrittura".

Una scansione SSL dell'endpoint dimostra che i dati in transito sono crittografati tramite TLS 1.2.

Evidenze di esempio: controlli di disponibilità e ripristino

Lo screenshot seguente mostra che il cluster di database viene replicato in tre aree per garantire la disponibilità. Questa operazione viene eseguita per impostazione predefinita da Mongo Atlas. Inoltre, il backup è abilitato ed è attivo.

Lo screenshot seguente mostra la dashboard di backup del cluster, che dimostra anche che è già stato creato uno snapshot.

I due screenshot successivi mostrano che è in atto un criterio di backup per eseguire backup pianificati in momenti diversi (PIT).

Quanto segue indica che esistono criteri di conservazione sia per gli snapshot che per il ripristino temporizzato (PIT).

Intento: L'intento di questo sottopunto è in linea con la regola di sicurezza che è stata sviluppata per garantire flessibilità e scalabilità in modo che un'"entità coperta" possa implementare politiche, procedure e soluzioni tecnologiche adatte allo scopo per le dimensioni dell'entità, la sua struttura organizzativa e i loro rischi specifici, nonché la loro propensione al rischio. Da un punto di vista pratico, ciò significa che le misure di sicurezza appropriate implementate dipenderanno dalla natura dell'attività dell'"entità coperta", nonché dalle sue dimensioni e risorse. 

È fondamentale che ogni organizzazione conduca un'analisi completa dei rischi per scoprire potenziali rischi e vulnerabilità per la riservatezza, l'integrità e la disponibilità di e-PHI. Attraverso questa analisi dei rischi, le organizzazioni possono quindi implementare controlli di sicurezza appropriati per mitigare questi rischi identificati. 

Linee guida: le prove possono essere fornite tramite l'output dell'analisi del rischio. Se l'analisi dei rischi è effettuata e gestita tramite una piattaforma online, dovrebbero essere forniti screenshot dell'intero output. 

Prove di esempio: gli screenshot successivi mostrano istantanee del processo di valutazione del rischio, seguite dall'analisi del rischio eseguita per determinare la misura in cui i controlli sono implementati correttamente e funzionano come previsto per proteggere le ePHI. Il secondo screenshot mostra un'analisi dei rischi identificati nella valutazione dei rischi e i controlli compensativi e le mitigazioni implementate per ridurre il livello di rischio. 

Esempio 1 - Snapshot del processo di valutazione del rischio all'interno della politica HIPAA e analisi del rischio eseguita

Nota: questo screenshot mostra uno snapshot di un documento di analisi dei rischi, questo è solo un esempio, e l'aspettativa è che gli ISV condividano la documentazione effettiva e non forniscano semplicemente uno screenshot.

Esempio 2 - Screenshot del processo di valutazione del rischio nell'ambito della politica HIPAA e analisi del rischio eseguita (mantenuta nella piattaforma cloud Confluence)

Il secondo screenshot mostra un'analisi dei rischi identificati nella valutazione dei rischi e i controlli compensativi e le mitigazioni implementate per ridurre il livello di rischio. Possiamo vedere che questo esiste ed è mantenuto nella piattaforma cloud Confluence.

Controllo n. 19

Fornire la prova che:

L'organizzazione ha stabilito e implementato un piano di backup dei dati e un piano di ripristino di emergenza come parte del piano di emergenza, in conformità con le misure di sicurezza amministrative della norma di sicurezza HIPAA ai sensi di 45 CFR §164.308(a)(7)(ii)(A) (Piano di backup dei dati) e 45 CFR §164.308(a)(7)(ii)(B) (Piano di ripristino di emergenza). 

Intento: La norma sulla privacy definisce quali informazioni sanitarie protette (PHI) sono coperte dalla legge e vieta usi e divulgazioni impropri di PHI. L'intento di questo punto è che un'organizzazione deve limitare l'accesso e l'uso di e-PHI solo a coloro che ne hanno bisogno per scopi autorizzati e che devono rispettare la regola minima necessaria, che richiede loro di utilizzare o divulgare solo la quantità minima di e-PHI necessaria per raggiungere lo scopo previsto. 

Deve essere messa in atto una combinazione di garanzie tecniche e amministrative per limitare l'uso delle ePHI e per garantire che il rischio di divulgazione delle ePHI sia ridotto. 

Linee guida: le prove fornite devono mostrare le garanzie tecniche in atto, come le tecnologie e i meccanismi in uso per proteggere le e-PHI e il modo in cui i controlli dell'organizzazione controllano l'accesso e lo spostamento di tali dati. 

Esempi di evidenza: gli screenshot successivi mostrano Prevenzione della perdita dei dati Microsoft Purview (DLP), una piattaforma integrata che consente alle organizzazioni di gestire i propri criteri di prevenzione della perdita dei dati da un'unica posizione centralizzata. 

Di seguito è possibile osservare che è abilitato un criterio "U.S. HIPAA Enhanced", che consente di impedire agli utenti di incollare dati sensibili in siti Web specifici, tra cui posta elettronica personale, richieste generative di intelligenza artificiale, siti di social media e altro ancora, quando l'accesso viene eseguito tramite un Web browser supportato. 

Lo screenshot seguente offre una panoramica più completa del criterio, incluso l'ambito a cui viene applicato. Il criterio è impostato su tutti gli account in posizioni come SharePoint, Dispositivi, OneDrive e così via.

Quando si seleziona l'opzione "Modifica criterio", viene visualizzata una visualizzazione più granulare delle configurazioni specifiche disponibili.

I due screenshot seguenti mostrano la definizione del contenuto e le condizioni che devono essere soddisfatte per applicare il criterio.

Il criterio copre vari tipi di dati sensibili, nonché un set di classificatori.

La sezione successiva mostra le azioni configurate da eseguire quando vengono soddisfatte le condizioni illustrate negli screenshot precedenti.

Lo screenshot seguente mostra che il criterio di prevenzione della perdita dei dati è impostato per impedire agli utenti di copiare e incollare informazioni sensibili, ad esempio informazioni personali, dai database interni dell'organizzazione agli account di posta elettronica personali, ai chatbot e ai siti di social media nei browser supportati.

Infine, le notifiche degli utenti sono configurate per notificare e fornire indicazioni agli utenti durante la gestione dei dati ePHI.

Lo screenshot seguente mostra il pannello di configurazione per la generazione di avvisi quando si verifica un incidente.

Intento: L'intento di questo sottopunto è che un'organizzazione deve formare il proprio personale su come gestire le e-PHI in modo sicuro e appropriato e che deve applicare politiche e procedure per garantire la conformità alla regola di sicurezza. 

Linee guida: Le prove fornite devono dimostrare che la formazione HIPAA viene eseguita su come gestire le ePHI e che esistono registri di frequenza e completamento della formazione. Ove applicabile, ciò può essere supportato dalla documentazione politica e dai materiali di formazione utilizzati. 

Prove di esempio: gli esempi seguenti mostrano le potenziali prove che possono essere presentate per dimostrare che un'adeguata formazione HIPAA avviene in linea con la politica. 

Lo screenshot successivo mostra un'istantanea della politica HIPAA con una sezione specifica che delinea i requisiti per la formazione. Si prega di notare che questo è solo un esempio e non un documento/implementazione completo, l'aspettativa è che l'ISV disponga di un processo stabilito applicabile alla propria organizzazione. 

Esempio 1 - Formazione per gli utenti HIPAA tramite processo amministrativo

Nella schermata successiva, la diapositiva panoramica del corso mostra un riepilogo degli obiettivi del corso. Se la formazione è costruita internamente, i materiali di formazione devono essere forniti per la revisione, si prega di notare che il materiale completo deve essere inviato e non solo uno screenshot del riepilogo.

Lo screenshot seguente mostra il registro delle presenze dei dipendenti che hanno partecipato alla formazione. Il record mostra anche il punteggio minimo e la data del prossimo allenamento programmato.

Il secondo esempio mostra come usare Microsoft 365 Defender per impostare e lanciare campagne di formazione.

Esempio 2 - Formazione degli utenti HIPAA tramite la piattaforma di simulazione degli attacchi di Microsoft 365 Defender (tutti gli utenti)

Lo screenshot precedente mostra la campagna di formazione sulla sicurezza HIPAA, la durata totale in minuti e lo stato di completamento. La schermata successiva offre una panoramica degli utenti a cui è stato assegnato il training e dello stato del training che indica il completamento con successo.

Esempio 3 - Formazione degli utenti HIPAA tramite la piattaforma di simulazione degli attacchi di Microsoft 365 Defender (utente singolo)

Mentre l'esempio precedente era incentrato sulla dimostrazione che tutti gli utenti hanno completato la campagna di formazione annuale, l'esempio finale mostra prove mirate che dimostrano il completamento per un dipendente.

Nei due screenshot precedenti si può osservare che non appena è stata lanciata la campagna di formazione, ogni dipendente ha ricevuto un'e-mail di conferma dell'assegnazione e della scadenza della formazione, nonché dei moduli assegnati, della durata, ecc.

Utilizzando il collegamento disponibile nella notifica tramite posta elettronica, lo screenshot seguente mostra la pagina Attività di formazione per l'utente e i due moduli che sono stati completati.

Intento: ai sensi della norma di sicurezza HIPAA, un piano di backup dei dati e un piano di ripristino di emergenza sono obbligatori per qualsiasi "entità coperta" che gestisce informazioni sanitarie protette elettroniche (ePHI). Tali piani fanno parte della strategia di emergenza che mira a garantire la disponibilità e la sicurezza delle ePHI in caso di emergenza o altro evento che danneggi i sistemi che contengono ePHI. 

L'intento del piano di backup dei dati è quello di creare e mantenere copie identiche recuperabili di ePHI, ciò dovrebbe includere anche test periodici dei backup per garantire che il recupero dei dati sia possibile. L'intento del piano di ripristino di emergenza è quello di ripristinare i dati potenzialmente persi in caso di emergenza, e questo dovrebbe specificare i passaggi che devono essere eseguiti per ripristinare l'accesso ai dati, inclusa la modalità di ripristino dei file dai backup. 

Linee guida: Fornire la versione completa del piano/procedura di ripristino di emergenza che dovrebbe coprire il piano di backup e il piano di ripristino. Fornire il documento PDF/Word effettivo se in versione digitale, in alternativa se il processo viene mantenuto tramite una piattaforma online fornire un'esportazione PDF o se non è possibile esportare a causa di limitazioni della piattaforma, fornire screenshot che coprano l'intera polizza. 

Esempio di evidenza: Lo screenshot successivo mostra istantanee della politica di sicurezza HIPAA contenenti una panoramica della procedura di backup generale e di alto livello e del piano di ripristino di emergenza. 

Nota: questo screenshot mostra uno snapshot di un documento di criteri/processi, questo è solo un esempio, e l'aspettativa è che gli ISV condividano la documentazione completa di criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Documentazione

Murdoch D. (2018) Manuale del Blue Team: Edizione di risposta agli incidenti: una guida sul campo condensata per il soccorritore di risposta agli incidenti di sicurezza informatica. 2a edizione, editore: CreateSpace Independent Publishing Platform.

Riferimenti

• Frode d'azione Segnalazione del crimine informatico Disponibile all'indirizzo: https://www.actionfraud.police.uk/ (Accesso: 12/10/2023).

• UE. (2021) Lista di controllo GDPR per i titolari del trattamento dei dati Disponibile all'indirizzo: https://gdpr.eu/checklist/ (Accesso: 10/12/2023).

• Microsoft. (2018) Registrazione eventi (Windows Installer) Disponibile all'indirizzo: Registrazione eventi (Accesso: 03/05/2024).

• Tecnologie positive. (2020) Come affrontare lo sviluppo software sicuro Disponibile all'indirizzo: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accesso:12/10/2023).

• Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati) (Testo rilevante ai fini del SEE) (2016) Disponibile all'indirizzo: https://www.legislation.gov.uk/eur/2016/679/contents (Consultato il: 12/10/2023).

• Metriche di sicurezza. (2020) Guida alle metriche di sicurezza per la conformità PCI DSS. Disponibile all'indirizzo: https://info.securitymetrics.com/pci-guide-2020(Accesso: 10/12/2023).

• Williams J. OWASP Classifica del rischio Disponibile su: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Accesso: 12/10/2023).

• Qualys. (2014) SSL Labs: nuovi voti per i problemi di fiducia (T) e discrepanza (M) Disponibile su: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accesso: 12/10/2023).

• NIST SP800-61r2: Guida alla gestione degli incidenti di sicurezza informatica Disponibile all'indirizzo: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Accesso: 10/12/2023).

• Creazione di una pipeline CI/CD con Azure Pipelines e Google Kubernetes Engine | .NET

• Google Cloud (Accesso: 10/10/2023).

• Il piano di ripristino di emergenza all'indirizzo: https://www.sans.org/white-papers/1164/ (Accesso: 10/10/2023).

• https://github.com/ (Accesso: 10/10/23).

• Modelli di criteri di sicurezza a: https://www.sans.org/information-security-policy/ (Accesso: 10/10/23).

• https://www.openedr.com/ (Accesso: 02/10/23).

• https://www.atlassian.com/software/confluence (Accesso: 10/10/23).

• https://www.atlassian.com/software/jira (Consultato il 28/09/23).

• Modello di esercizio da tavolo del piano di continuità aziendale (BCP) su: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Accesso: 10/10/23).

• Riepilogo della regola di sicurezza HIPAA | HHS.gov (Accesso: 18/10/2023).

• Leggi sulla privacy delle informazioni sanitarie nell'era digitale: HIPAA non si applica - PMC (nih.gov) (Accesso: 18/10/2023).

• Qual è lo scopo dell'HIPAA? Aggiornamento 2023 (hipaajournal.com) (Accesso: 18/10/2023).

• Cosa è considerato PHI ai sensi dell'HIPAA? Aggiornamento 2023 (hipaajournal.com) (Accesso: 18/10/2023).

• Politiche e procedure HIPAA (hipaajournal.com) (Accesso: 18/10/2023).

• Progettazione di politiche HIPAA & politiche amministrative | Dash Solutions (dashsdk.com) (Accesso: 18/10/2023).

• 45 CFR § 164.304 - Definizioni. | Codice elettronico dei regolamenti federali (e-CFR) | Legge degli Stati Uniti | LII

• / Istituto di informazione giuridica (cornell.edu) (Accesso: 18/10/2023).

• Che cos'è la conformità HIPAA? Leggi & regole HIPAA | Proofpoint UK (Accesso: 18/10/2023).

• Regole, regolamenti e standard di sicurezza HIPAA (training-hipaa.net) (Accesso: 18/10/2023).

• Riepilogo della regola di sicurezza HIPAA | HHS.gov (Accesso: 18/10/2023).

• SP 800-66 Rev. 1, Una guida introduttiva alle risorse per l'attuazione della regola di sicurezza dell'Health InsurancePortability and Accountability Act (HIPAA) | CSRC (nist.gov) (Accesso: 18/10/2023).

• La regola di sicurezza | HHS.gov (Accesso: 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Accesso: 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Accesso: 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Accesso: 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Accesso: 19/10/2023).

• Configurazione della crittografia - Manuale MongoDB (Accesso: 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Accesso: 19/10/2023).

• Prevenzione della perdita dei dati di Microsoft Purview: annuncio della disponibilità generale di diverse funzionalità

• Microsoft Community Hub (Accesso: 24/10/2023).

• 45 CFR § 164.308 - Garanzie amministrative. | Codice elettronico dei regolamenti federali (e-CFR)

• | Legge degli Stati Uniti | LII / Istituto> di informazione giuridica (cornell.edu) (Accesso: 24/10/2023).

• Quando dobbiamo fornire le informazioni sulla privacy? | ICO (Accesso: 08/11/2023).

• Come dobbiamo redigere le nostre informazioni sulla privacy? | ICO (Accesso: 08/11/2023).

• Quadro di responsabilità | ICO (Accesso: 08/11/2023).

• ISO 27001 Requisito 5.1 - Leadership & impegno | ISMS.online (Accesso: 08/11/2023).

• Piattaforma di navigazione online (OBP) (iso.org) (Accesso: 08/11/2023).

• Clausola 5.3 Ruoli organizzativi, responsabilità e autorità - Formazione ISO (Accesso: 08/11/2023).

• 5.3 Ruoli, responsabilità e autorità (iso9001help.co.uk) (Accesso: 08/11/2023).

• De-identificazione e re-identificazione delle PII in set di dati su larga scala utilizzando la protezione dei dati sensibili| Centro di architettura cloud | Google Cloud (Accesso: 08/11/2023).

• De-identificazione dei dati sensibili | Documentazione sulla protezione dei dati sensibili | Google Cloud (Accesso: 08/11/2023).

• Guida alla sicurezza dei dati | ICO (Accesso: 08/11/2023).

• Trasferimenti internazionali di dati | ICO (Accesso: 08/11/2023).

• Gestione e sicurezza dei record | ICO (Accesso: 08/11/2023).

• ISO 27701 - Gestione delle informazioni sulla privacy (Accesso: 08/11/2023).

• ISO 27701 Sistema di gestione delle informazioni sulla privacy (PIMS) | ISMS.Online (Accesso: 08/11/2023).

Immagini/testi tratti da Documenti Microsoft

• https://www.sans.org/information-security-policy/ (Accesso: 18/02/21).

• Ottenere analisi comportamentali e rilevamento delle anomalie (Accesso:03/05/24).

• Che cosa sono gli avvisi di Monitoraggio di Azure? (Accesso:03/05/24).

• Ottenere analisi comportamentali e rilevamento delle anomalie

• (Accesso:03/05/24).

• Gestire e rispondere agli avvisi di sicurezza in Microsoft Defender per il cloud (Accesso:03/05/24).

• Gestire e rispondere agli avvisi di sicurezza in Microsoft Defender per il cloud (Accesso:03/05/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Accesso: 09/10/23).

• Che cos'è Azure Information Protection?

• Transparent Data Encryption per database SQL, Istanza gestita di SQL e Azure Synapse Analytics (Accesso:03/05/24).

• Guida introduttiva: Creare un'assegnazione di criteri per identificare le risorse non conformi (Accesso:03/05/24).

• Configurare Advanced Threat Protection per il database Azure SQL (Accesso:03/05/24).

• Backup e ripristino nel Database di Azure per MySQL - Server flessibile (Accesso:03/05/24).

• Inventario certificati (Accesso:05/03/24).

• Backup e ripristino in Database di Azure per MySQL (Accesso:05/03/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Accesso: 08/11/2023).

Ulteriori informazioni

• Esempi di guida alle evidenze - Panoramica
• Guida alle prove di esempio - Operazioni