Dominio di sicurezza: sicurezza e privacy per la gestione dei dati

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 inoltre 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/componenti aggiuntivi sviluppati da 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 dati su Internet.

Controllo n. 1

Fornire prove per tutti i seguenti elementi:

• Verificare che la configurazione di TLS sia TLS1.2 o versione successiva.

• Viene conservato e gestito un inventario di chiavi e certificati attendibili.

Finalità: TLS

L'intenzione di questo sottopunto è garantire che i dati di Microsoft 365 utilizzati dall'organizzazione vengano trasmessi in modo sicuro. La configurazione del profilo TLS viene usata per definire requisiti specifici di TLS che consentono di garantire la protezione del traffico dagli attacchi man-in-the-middle.

Linee guida: TLS

Il modo più semplice per dimostrarlo consiste nell'eseguire lo strumento di test del server SSL Qualys su TUTTI i listener Web, inclusi quelli eseguiti su porte non standard.

Ricordarsi di selezionare l'opzione "Non visualizzare 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 singoli controlli. Per fornire prove di impostazioni specifiche, ad esempio la disabilitazione della compressione TLS, è possibile usare impostazioni di configurazione, script e strumenti software.

Prova di esempio: TLS

Lo screenshot seguente mostra i risultati dell'analisi SSL di Qualys per webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.

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

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

Prova di esempio: TLS

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

Finalità: chiavi e certificati

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

Linee guida: chiavi e certificati

L'evidenza deve dimostrare che esiste e viene gestito 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 Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud e così via.

Prova di esempio: chiavi e certificati

Lo screenshot seguente mostra che una chiave e un inventario certificati vengono gestiti in Confluence Cloud.

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

Lo screenshot seguente è tratto 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 con privilegi.

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

Nota: si prevede che il percorso di archiviazione delle chiavi disponga di controlli di accesso appropriati. Se la chiave privata viene compromessa, un utente potrebbe falsificato il server con un certificato legittimo.

Prova di esempio: chiavi e certificati

È anche possibile gestire un inventario di chiavi e certificati attendibili con Microsoft 365 Defender, che fornisce una funzionalità di inventario, come illustrato nello screenshot successivo.

Lo screenshot successivo mostra 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 il timestamp e la data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

Controllo n. 2

Fornire le prove per tutti i seguenti elementi:

• Mostra che la compressione TLS è disabilitata per tutti i servizi pubblici che gestiscono le richieste Web per impedire CRIME (Compression Ratio Info-leak Made Easy).

• Verifica che TLS HSTS sia abilitato e configurato per 180 giorni in tutti i siti.

Finalità: TLS

• L'attacco CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) è una vulnerabilità nella compressione dei protocolli Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Per questo motivo, le raccomandazioni del settore prevedono la disabilitazione della 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 evidenziato tramite lo strumento Qualys SSL Labs. Prova di esempio: TLS

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

Lo screenshot successivo mostra che HSTS è abilitato.

Nota: l'analista della certificazione esaminerà l'output completo per verificare che tutti i requisiti di configurazione del profilo TLS siano soddisfatti (fornire screenshot dell'output dell'analisi completa). A seconda delle prove fornite, gli analisti possono eseguire la propria analisi 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. Evidenza aggiuntiva

Screenshot come le impostazioni di configurazione delle intestazioni di sicurezza, in particolare HSTS, possono essere fornite per illustrare ulteriormente il comportamento di sicurezza del footprint pubblico.

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

Lo screenshot successivo 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 lo scanner SSL Qualys o le intestazioni di sicurezza, si prevede che il report completo venga fornito per una revisione.

Dati inattivi

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

Controllo n. 3

Fornire prove dimostrabili che i dati inattivi sono crittografati in linea con i requisiti del profilo di crittografia, usando algoritmi di crittografia come AES, Blowfish, TDES e dimensioni delle chiavi di crittografia a 128 bit e a 256 bit.

Finalità:

Alcuni algoritmi di crittografia meno recenti sono noti per contenere alcuni punti deboli di crittografia che aumentano le probabilità che un attore di 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:

Le prove possono essere fornite tramite screenshot, che mostrano la crittografia usata per proteggere i dati M365 all'interno di database e 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 TDE (Transparent Data Encryption) è abilitato nel database Contoso. La seconda schermata mostra la pagina della documentazione Microsoft Transparent data encryption for database SQL, Istanza gestita di SQL e Azure Synapse Analytics che mostra che la crittografia AES 256 viene usata per Azure TDE.

Nota: negli esempi precedenti gli screenshot completi non sono stati usati, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Prova di esempio:

Lo screenshot seguente mostra Archiviazione di Azure configurata con la crittografia per BLOB e file. Lo screenshot successivo mostra la pagina della documentazione Microsoft Crittografia archiviazione di Azure per i dati inattivi che mostra che Archiviazione di Azure usa AES-256 per la crittografia.

Conservazione, backup e eliminazione dei dati

Dove gli ISV usano e archiviano i dati di Microsoft 365, c'è il rischio di una compromissione dei dati nel caso in cui un attore di minacce comprova l'ambiente ISV. Per ridurre al minimo questo rischio, le organizzazioni devono conservare solo i dati necessari per fornire servizi e non i dati che potrebbero essere usati in futuro. Inoltre, i dati devono essere conservati solo per tutto il tempo necessario per fornire i servizi per cui sono stati acquisiti i dati. La conservazione dei dati deve essere definita e comunicata con gli utenti. Una volta che i dati superano il periodo di conservazione definito, è necessario eliminarli 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 sia formalmente stabilito e documentato.

Finalità:

Una politica di conservazione documentata e seguita è importante non solo per soddisfare alcuni obblighi legali, ad esempio la legislazione sulla privacy dei dati, ad esempio, ma non solo, il Regolamento generale sulla protezione dei dati (GDPR dell'UE) e il Data Protection Act (UK DPA 2018), ma anche per limitare i rischi di un'organizzazione. Comprendendo i requisiti dei dati delle organizzazioni e la durata dei dati necessari all'azienda per svolgere le proprie funzioni, le organizzazioni possono garantire che i dati vengano eliminati correttamente una volta scaduta l'utilità. Riducendo i volumi di dati archiviati, le organizzazioni riducono la quantità di dati che verrebbero esposti in caso di compromissione dei dati. Questo limiterà l'impatto complessivo.

Spesso le organizzazioni archivieranno i dati perché è bello avere solo nel caso in cui. Tuttavia, se l'organizzazione non ha bisogno dei dati per eseguire il servizio o la funzione aziendale, i dati non devono essere archiviati in quanto ciò aumenta inutilmente il rischio dell'organizzazione.

Questo controllo ha lo scopo di confermare che l'organizzazione ha formalmente stabilito e documentato un periodo di conservazione dei dati approvato per tutti i tipi di dati pertinenti. Ciò implica non solo specificare la durata per cui verranno archiviati diversi tipi di dati, ma anche delineare le procedure per l'eliminazione o l'archiviazione dopo la scadenza.

Linee guida:

Specificare i criteri di conservazione dei dati completi che descrivono chiaramente per quanto tempo devono essere conservati i dati (devono coprire tutti i tipi di dati) in modo che l'azienda possa svolgere le proprie funzioni aziendali.

Prova di esempio:

Lo screenshot successivo mostra i criteri di conservazione dei dati di Contoso.

Nota: questi screenshot mostrano uno snapshot di un documento di criteri/processi. L'aspettativa è che gli ISV condividano la documentazione effettiva relativa ai criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Controllo n. 5

Dimostrare che i dati vengono conservati solo per il periodo di conservazione definito, come illustrato nel controllo 4.

Finalità:

Lo scopo di questo controllo consiste semplicemente nel verificare che vengano soddisfatti i periodi di conservazione dei dati definiti. Come già illustrato, le organizzazioni possono avere l'obbligo legale di soddisfare questo obbligo, ma anche mantenendo i 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 una durata eccessivamente lunga né eliminati prematuramente, entrambi i quali potrebbero presentare rischi di natura diversa, legali, operativi o correlati alla sicurezza.

Linee guida:

Fornire la prova dello screenshot (o tramite condivisione dello schermo) che mostra che i dati archiviati (in tutte le varie posizioni dei dati, ad esempio database, condivisioni file, archivi e così via) non superano i criteri di conservazione dei dati definiti. Esempi possono essere screenshot di:

• record di database con un campo data, ricercati in ordine di record meno recente e/o

• Percorsi di archiviazione file che mostrano timestamp che rientrano nel periodo di conservazione Nota: tutti i dati personali/sensibili dei clienti devono essere redatti all'interno dello screenshot.

Prova di esempio:

L'evidenza seguente mostra una query SQL che mostra il contenuto della tabella di database ordinata in ordine crescente nel campo "DATE_TRANSACTION" per visualizzare i record meno recenti all'interno del database. Ciò mostra che i dati hanno meno di due mesi e non superano il periodo di conservazione definito.

Nota: si tratta di un database di test, pertanto non sono presenti molti dati cronologici al suo interno.

Nota: negli esempi precedenti non sono stati usati screenshot completi, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Controllo n. 6

Dimostrare che i processi sono in atto per eliminare in modo sicuro i dati dopo il periodo di conservazione.

Finalità:

Lo scopo di questo controllo è garantire che il meccanismo usato per eliminare i dati che superano il periodo di conservazione lo stia facendo in modo sicuro. I dati eliminati a volte possono essere recuperati; Pertanto, il processo di eliminazione deve essere sufficientemente affidabile da garantire che i dati non possano essere recuperati dopo l'eliminazione.

Linee guida:

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

Prova di esempio:

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. Si prega di notare che sarà necessario lo script; prova del processo in esecuzione e dei risultati.

Nota: negli esempi precedenti gli screenshot completi non sono stati usati, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Prova di esempio:

Lo screenshot seguente è stato tratto dai criteri di conservazione dei dati di Contoso (da Control 4): vengono visualizzate le procedure usate per la distruzione dei dati.

Nota: questo screenshot mostra uno snapshot di un documento di criteri/processi. L'aspettativa è che gli ISV condividano la documentazione effettiva relativa ai criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Prova di esempio:

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

Lo screenshot successivo mostra che il runbook è stato modificato per trovare i record e dispone di comandi di eliminazione non visualizzati come lo script.

Nota: l'URL e il nome utente completi devono essere visualizzati per questi screenshot e gli ISV dovranno mostrare uno screenshot di prima del numero di record di eliminazione e uno screenshot del numero di record dopo l'eliminazione.

Questi screenshot sono solo esempi dei diversi modi in cui è possibile affrontare questo approccio.

Controllo n. 7

Fornire prove che dimostrino che:

• È in atto un sistema di backup automatizzato e configurato per eseguire i backup in orari pianificati.

• Le informazioni di backup vengono testate in linea con la procedura di pianificazione del backup e ripristinate periodicamente per confermare l'affidabilità e l'integrità dei dati.

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

Finalità:

Questo controllo ha lo scopo di verificare che l'organizzazione disponga di un sistema di backup automatizzato configurato per eseguire i backup in momenti predeterminati.

Linee guida:

Fornire screenshot delle impostazioni di configurazione della soluzione di backup che mostrano che i backup vengono eseguiti in periodi pianificati/intervalli di tempo. Se la pianificazione dei backup viene eseguita automaticamente dalla soluzione, questa operazione può essere supportata fornendo la documentazione del fornitore.

Prova di esempio:

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

Lo screenshot successivo viene eseguito dopo il superamento di un periodo di tempo che mostra che sono stati eseguiti altri backup completi. I backup nei server flessibili sono basati su snapshot in cui il primo backup dello snapshot viene pianificato immediatamente dopo la creazione di un server e vengono eseguiti altri backup snapshot una volta al giorno.

Lo screenshot successivo mostra uno snapshot della documentazione online che descrive la frequenza di backup e la funzionalità di backup automatizzato.

Finalità:

Lo scopo di questo controllo è dimostrare che le informazioni di backup non vengono generate solo in base alla pianificazione, ma sono anche affidabili e ne mantengono l'integrità nel tempo. Per soddisfare questo obiettivo, verranno eseguiti test periodici sui dati di backup.

Linee guida:

L'evidenza per soddisfare questo controllo dipenderà dal processo e dalla procedura dell'organizzazione per il test dei dati di backup. È possibile fornire prove che mostrano che i backup vengono testati correttamente insieme ai record di completamento dei test cronologici.

Prova di esempio:

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

Lo screenshot successivo mostra una pagina di record cronologici dei test di backup per ognuno dei sistemi applicabili. Si noti che sul lato destro della tabella vengono indicati i ticket JIRA per ognuno dei test.

I quattro screenshot successivi mostrano il processo end-to-end di ripristino del Database di Azure per MySQL da uno snapshot. Usando l'opzione "Ripristino rapido" è possibile 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 il percorso 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 dallo snapshot di backup, come illustrato di seguito.

Al termine del test, in linea con il processo è stato creato un ticket JIRA per registrare il test di backup e i dettagli del ripristino eseguito. In questo modo si garantisce che i dati cronologici siano disponibili a scopo di conformità e che siano presenti record completi per la revisione nell'eventualità di un evento imprevisto o di emergenza per consentire all'organizzazione di eseguire un'analisi della causa radice.

Finalità:

A partire dal controllo precedente, i controlli di accesso devono essere implementati per limitare l'accesso solo ai singoli utenti responsabili dei dati di backup. Limitando l'accesso, si limita il rischio di modifiche non autorizzate e quindi si introducono modifiche non sicure. Per proteggere i backup, è necessario adottare un approccio con privilegi minimi.

Per proteggere correttamente i dati, le organizzazioni devono essere consapevoli dei dati che utilizzano l'ambiente o i sistemi e della posizione in cui vengono archiviati i dati. Una volta che questo è completamente compreso e documentato.

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

Linee guida:

Le prove devono essere fornite dal sistema o dalla tecnologia usata per dimostrare le autorizzazioni di accesso per i backup e le soluzioni di backup con la documentazione di supporto dell'elenco di accesso approvato.

Prova di esempio:

Negli screenshot seguenti sono illustrati i controlli di accesso implementati nell'istanza del database per limitare l'accesso solo a utenti autorizzati in base al ruolo del processo.

Prova di esempio:

Azure SQL backup automatizzati di istanze gestite di database e Azure SQL sono gestiti da Azure e la loro integrità è responsabilità della piattaforma Azure. Nessun utente può accedervi e viene crittografato 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 a un numero limitato di persone in base alle esigenze per ridurre le probabilità che i dati vengano compromessi in modo dannoso o accidentale. L'accesso ai dati e alle chiavi di crittografia deve essere limitato agli utenti con un'esigenza aziendale legittima di accedere per svolgere il proprio ruolo di lavoro. È necessario implementare un processo ben documentato e consolidato per richiedere l'accesso. L'accesso ai dati e alle chiavi di crittografia deve seguire il principio dei privilegi minimi.

Controllo n. 8

Fornire prove per dimostrare che un elenco di utenti con accesso ai dati e/o alle chiavi di crittografia:

• viene mantenuto includendo la giustificazione aziendale per ogni individuo.

• sono stati formalmente approvati in base ai privilegi di accesso necessari per la funzione del processo.

• sono configurati con i privilegi descritti nell'approvazione.

Finalità:

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:

Documentazione o screenshot dei sistemi interni che documenta tutti i dipendenti con accesso ai dati e/o alle chiavi di crittografia insieme alla giustificazione aziendale del motivo per cui questi utenti hanno accesso. Questo elenco verrà usato dall'analista della certificazione per campionare gli utenti per i controlli successivi.

Prova di esempio:

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

Nota: questo screenshot mostra un documento di criteri/processo, l'aspettativa è che gli ISV condividano la documentazione effettiva relativa ai criteri/procedure di supporto.

Finalità:

Il processo per concedere l'accesso ai dati e/o alle chiavi di crittografia deve includere l'approvazione, assicurando che l'accesso di un individuo sia necessario per la funzione di processo. Ciò garantisce che i dipendenti senza un motivo reale per l'accesso non ottengano l'accesso non necessario.

Linee guida:

In genere, l'evidenza fornita per il controllo precedente può aiutare a supportare questo controllo. Se non è presente un'approvazione formale nella documentazione fornita, l'evidenza può consistere in una richiesta di modifica generata e approvata per l'accesso all'interno di uno strumento come Azure DevOps o Jira.

Prova di esempio:

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 illustra che è stata creata una richiesta in Jira per ottenere l'approvazione di Sam Daily per le chiavi di crittografia nell'ambiente back-end dei sistemi. Questa operazione viene eseguita come passaggio successivo in cui è stata ottenuta l'autorizzazione scritta.

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

Il precedente mostra un flusso di lavoro in Jira per questo processo. Si noti che non è possibile aggiungere nulla come Done a meno che non sia stato eseguito il processo di approvazione automatizzato e pertanto non può essere ignorato.

La scheda Progetto mostra ora che è stata concessa l'approvazione per l'accesso di Sam Daily alle chiavi di crittografia. Il backlog seguente mostra l'approvazione della richiesta di Sam Daily e la persona assegnata a eseguire il lavoro.

Per soddisfare i requisiti di questo controllo, è necessario visualizzare tutti questi screenshot o prove simili/equivalenti applicabili con una spiegazione che dimostri di aver soddisfatto il requisito di controllo.

Nota: negli esempi precedenti gli screenshot completi non sono stati usati, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Prova di esempio:

Nell'esempio successivo sono state richieste autorizzazioni di accesso amministratore e controllo completo per un utente al database di produzione. La richiesta è stata inviata per l'approvazione come si può vedere a destra dell'immagine ed è stata approvata come illustrato a sinistra.

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

Nota: negli esempi precedenti gli screenshot completi non sono stati usati, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Intento

Lo scopo di questo sottopunto è verificare che l'accesso ai dati e/o alla chiave di crittografia sia configurato in base a quanto documentato.

Linee guida:

È possibile fornire prove tramite screenshot che mostra i dati e/o i privilegi di accesso alla chiave di crittografia concessi agli individui campionati. Le prove devono coprire tutte le posizioni dei dati.

Prova di esempio:

Questo screenshot mostra le autorizzazioni concesse all'utente "John Smith" che sarebbero state incrociate

viene fatto riferimento alla richiesta di approvazione per questo 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 il timestamp e la data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

Controllo n. 9

Fornire la prova che:

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

• I contratti di condivisione dei dati sono in vigore con tutte le terze parti che utilizzano dati.

Finalità:

Se terze parti vengono usate per l'archiviazione o l'elaborazione dei dati di Microsoft 365, queste entità possono rappresentare un rischio significativo. Le organizzazioni devono sviluppare un buon processo di due diligence e gestione di terze parti per garantire che queste terze parti archivino/elaborano i dati in modo sicuro e per garantire che rispettino eventuali obblighi legali che potrebbero avere, ad esempio come responsabile 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 sono forniti

• quali dati sono condivisi

• perché i dati sono condivisi

• informazioni di contatto chiave (ad esempio, contatto primario, contatto di notifica delle violazioni, DPO e così via)

• rinnovo/scadenza del contratto

• obblighi legali/di conformità (ad esempio, GDPR, HIPAA, PCI DSS, FedRAMP e così via)

Linee guida:

Fornire documentazione dettagliata su TUTTE le terze parti con cui vengono condivisi i dati di Microsoft 365.

Nota: se terze parti non sono in uso, questo dovrà essere confermato per iscritto (e-mail) da un membro del team dirigenziale senior.

Prova di esempio:

Nota: negli esempi precedenti non sono stati usati screenshot completi, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Prova di esempio:

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

Nota: in questi esempi non sono stati usati screenshot completi, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot completi che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

Finalità:

Quando i dati M365 vengono condivisi con terze parti, è importante che i dati vengano gestiti in modo appropriato e sicuro. Gli accordi di condivisione dei dati devono essere applicati per garantire che terze parti eserci scono i dati solo in base alle esigenze e comprendano i propri obblighi di sicurezza. La sicurezza di un'organizzazione è forte solo quanto il collegamento più debole. Lo scopo di questo controllo è garantire che terze parti non diventino un collegamento debole dell'organizzazione.

Linee guida:

Fornire i contratti di condivisione dei dati che sono in vigore con le terze parti.

Prova di esempio:

Lo screenshot successivo mostra un esempio semplicistico di un contratto di condivisione 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 degli utenti e garantire la gestione responsabile dei dati. Affinché un'organizzazione stabilisca un sistema di informazioni sulla privacy efficace, deve essere a conoscenza dei dati personali in loro possesso e dello scopo per l'elaborazione e l'archiviazione di tali dati. Un'organizzazione deve eseguire il mapping del flusso di informazioni e del modo in cui viene elaborato, riconoscendo che potrebbero verificarsi diversi tipi di elaborazione.

Controllo n. 10

L'organizzazione dispone di un sistema di gestione delle informazioni sulla privacy (PIM) stabilito, implementato e gestito:

• Mantiene l'impegno della leadership tramite un criterio o un'altra forma di documentazione/sistema informatizzato per il modo in cui le attività di gestione delle informazioni sulla privacy vengono mantenute per la riservatezza e l'integrità del sistema.

• Determina i ruoli, le responsabilità e le autorità di ogni persona che gestisce il sistema, inclusi processori e controller pii.

Finalità:

Lo scopo di questo punto è garantire che esista una "cultura della privacy" ed è supportato dalla leadership dell'organizzazione attraverso un programma di governance della privacy efficace. La gestione dell'organizzazione deve dimostrare tramite la documentazione e i processi stabiliti che esiste un sistema efficace di gestione della privacy, tali processi sono allineati agli obiettivi strategici dell'organizzazione e sono stabiliti all'interno del contesto e delle circostanze dell'organizzazione, nonché garantire che il sistema di gestione della privacy sia incorporato nei processi aziendali.

Linee guida:

Ciò sarebbe evidenziato fornendo la documentazione stabilita dall'organizzazione che delinea i criteri e la procedura di Gestione delle informazioni sulla privacy (PIM). Gli analisti di certificazione esamineranno questa certificazione per assicurarsi che tutte le informazioni fornite all'interno del controllo siano risolte.

Prova di esempio:

Gli screenshot seguenti mostrano gli snapshot di un criterio PIM.

Nota: l'aspettativa è che gli ISV condividano la documentazione effettiva dei criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Intento

La responsabilità è uno dei principi chiave della legge sulla protezione dei dati in quanto consente a un'organizzazione di ridurre al minimo i rischi associati alla gestione dei dati personali implementando criteri, procedure e processi appropriati ed efficaci. Queste misure devono essere proporzionali ai rischi, che possono variare a seconda della quantità di dati gestiti o trasferiti, della sua sensibilità e della tecnologia in uso. A tale scopo, ogni dipendente deve sapere chi è responsabile dei vari elementi del sistema di gestione della privacy per garantire un'implementazione corretta. Avendo una documentazione stabilita che delinea i ruoli, le responsabilità e le autorità in modo chiaramente definito e avendo i ruoli assegnati in modo appropriato, un'organizzazione può garantire che il proprio sistema di gestione della privacy sia efficace.

Linee guida:

Ciò sarebbe evidenziato fornendo la documentazione stabilita dall'organizzazione che delinea i ruoli, le responsabilità e le autorità di ogni persona pertinente. Gli analisti di certificazione esamineranno questa certificazione per assicurarsi che tutte le informazioni fornite all'interno del controllo siano risolte.

Prova di esempio:

Gli screenshot successivi mostrano gli snapshot di un criterio PIM che mostra una sezione dei criteri contenente l'elenco dei dipendenti approvati.

Nota: l'aspettativa è che gli ISV condividano la documentazione effettiva dei criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Controllo n. 11

Fornire l'evidenza dei processi per dimostrare che:

• La minimizzazione delle informazioni personali è in corso.

• La de-identificazione e l'eliminazione delle informazioni personali vengono eseguite alla fine del periodo di elaborazione.

• Sono previsti controlli per la trasmissione di informazioni personali, inclusa la riservatezza.

• Record del trasferimento di informazioni personali da un paese/area geografica a un altro con il consenso espresso a farlo.

Finalità: PII

Lo scopo della minimizzazione delle informazioni personali (informazioni personali) è quello di garantire che un'organizzazione raccoglie, usi e conservi solo la quantità minima di dati personali necessaria per raggiungere uno scopo specifico all'interno del contesto dell'organizzazione e all'interno della giustificazione aziendale. Quando si gestiscono i dati personali, un'organizzazione deve identificare la quantità minima di dati necessaria per raggiungere tale obiettivo/attività e assicurarsi che non vengano archiviati più dei dati minimi necessari. Riducendo al minimo l'elaborazione e l'archiviazione di dati personali non necessari, un'organizzazione garantisce che il livello di rischio associato all'uso improprio dei dati, all'accesso non autorizzato e alle violazioni dei dati venga ridotto.

Linee guida: informazioni personali

L'evidenza può essere fornita tramite le impostazioni di configurazione della soluzione usata per ridurre al minimo l'utilizzo delle informazioni personali se questa viene eseguita tramite una piattaforma automatizzata o se un processo amministrativo manuale, l'evidenza del processo di minimizzazione e l'evidenza dei record del processo in corso devono essere fornite all'analista per la revisione.

Prova di esempio: PII

Lo screenshot seguente mostra che è pianificata una riunione mensile ricorrente in cui tutti i nuovi dati ricevuti all'interno dell'organizzazione entro tale periodo vengono esaminati e, se applicabile, tutte le informazioni personali ritenute non necessarie vengono rimosse.

Nello screenshot successivo è riportato un esempio di modulo di registrazione utente compilato usato per eseguire l'onboarding di nuovi clienti all'interno della piattaforma.

Lo screenshot successivo dimostra che, in base alla riunione e alla revisione delle informazioni personali, si è ritenuto che alcune delle informazioni sensibili raccolte nel modulo non siano più necessarie per fornire il servizio all'utente. Nell'immagine successiva, le informazioni personali degli arbitri sono state rimosse, così come l'indirizzo di posta elettronica (l'aspettativa è che ogni organizzazione avrà una giustificazione aziendale per tenere o rimuovere tali informazioni).

Nota: il precedente è un esempio di uno scenario potenziale. Non è affatto completo e quando si forniscono prove, il processo per ridurre al minimo le informazioni personali deve essere chiaramente dimostrato e deve essere applicato al contesto specifico dell'organizzazione.

Finalità: privacy dei dati

Lo scopo di questo sottopunto è multiforme e copre diverse tecniche e concetti diversi, ma l'obiettivo generale è che un'organizzazione sia conforme alle normative sulla protezione dei dati garantendo che la privacy dei dati all'interno dell'organizzazione sia migliorata.

A partire dalla de-identificazione, ovvero il processo di rimozione di informazioni specifiche che possono essere usate per identificare un individuo dai dati, lo scopo è quello di garantire che qualsiasi informazione considerata sensibile, ad esempio indirizzo di posta elettronica, data di nascita e così via, venga modificata/convertita (tramite varie tecniche come la pseudonimizzazione o la maschera) in un formato che lo rende inutilizzabile per collegarlo direttamente a un individuo. Lo scopo di questo processo non è solo quello di preservare l'utilità dei dati, ma anche di garantire la riduzione del livello di rischio associato all'uso improprio dei dati, all'accesso non autorizzato e alle violazioni dei dati.

Le organizzazioni devono definire la conservazione dei dati ed eliminare i dati non necessari alla fine del periodo di elaborazione. Quando i dati superano il periodo di conservazione dei dati definito, devono essere eliminati in modo sicuro per assicurarsi che non possano essere ricostruiti o ripristinati. Mantenere i dati necessari e per tutto il tempo necessario consente di ridurre il rischio per l'organizzazione in caso di violazione dei dati. Ciò garantisce che i dati non vengano conservati per una durata eccessivamente lunga né eliminati prematuramente, entrambi i quali potrebbero presentare rischi di natura diversa, legali, operativi o correlati alla sicurezza.

Linee guida: privacy dei dati

Le prove possono essere fornite tramite le impostazioni di configurazione del meccanismo e/o della tecnica usata per garantire che i dati piI vengano anonimizzati ed eliminati in base al requisito di controllo.

Prova di esempio: privacy dei dati

L'esempio illustrato negli screenshot successivi usa il modello di anonimizzazione dei dati predefinito di Azure Data Factory che fa parte della raccolta modelli e consente di spostare un set di file di testo da una posizione a un'altra, anonimizzandone il contenuto. Mostra che esiste una data factory in Azure per l'anonimizzazione delle informazioni personali.

Lo screenshot successivo mostra la configurazione della pipeline di anonimizzazione delle informazioni personali. Sfrutta il codice per l'uso di Presidio in Servizio app di Azure per chiamare Presidio come endpoint REST HTTP nella pipeline Azure Data Factory durante l'analisi e l'archiviazione di ogni file come Archiviazione BLOB di Azure.

Lo screenshot seguente mostra i passaggi e la logica della pipeline.

Lo screenshot finale illustra una corretta esecuzione della pipeline per rendere anonime le informazioni personali.

Nota: il precedente è un esempio di uno scenario potenziale. Non è affatto completo e quando si forniscono prove, il processo di anonimizzazione delle informazioni personali deve essere chiaramente dimostrato e deve essere applicato al contesto specifico dell'organizzazione.

Prova di esempio: privacy dei dati

Lo screenshot seguente ha illustrato un esempio di risoluzione dell'eliminazione delle informazioni personali alla fine del periodo di elaborazione abilitando un criterio di gestione del ciclo di vita per l'account di archiviazione in Azure in cui sono contenute le informazioni personali.

Lo screenshot successivo mostra che la conservazione viene impostata per un periodo predefinito dopo il quale i dati vengono eliminati automaticamente.

Nota: il precedente è un esempio di uno scenario potenziale. Non è affatto completo e quando si forniscono prove, il processo per l'eliminazione dei dati PII e il periodo di conservazione specifico applicabile devono essere chiaramente dimostrati e devono essere applicati al contesto specifico dell'organizzazione.

Prova di esempio: privacy dei dati

Lo screenshot finale mostra che sono stati applicati criteri di conservazione per la gestione del ciclo di vita dei dati per il trasferimento e l'archiviazione dei dati piI in diverse posizioni all'interno dell'organizzazione, ad esempio SharePoint, OneDrive, dispositivi, cassette postali e così via. Questo criterio è abilitato tramite Microsoft Purview. I criteri di conservazione sono configurati per eliminare automaticamente eventuali informazioni personali al termine del periodo di conservazione predefinito.

Nota: il precedente è un esempio di uno scenario potenziale. Non è affatto completo e quando si forniscono prove, il processo per l'eliminazione dei dati PII e il periodo di conservazione specifico applicabile devono essere chiaramente dimostrati e devono essere applicati al contesto specifico dell'organizzazione.

Finalità: controlli

Lo scopo di questo sottopunto è garantire che le organizzazioni dispongano di misure di sicurezza tecniche e amministrative/operative appropriate per proteggere le informazioni personali durante l'elaborazione e la trasmissione. L'enfasi sulla riservatezza si riferisce alla protezione dei dati da accessi e divulgazioni non autorizzati tramite controlli tecnici e amministrativi come la crittografia dei dati inattivi e in transito, elenchi di controllo di accesso documentati e controlli regolari.

Linee guida: controlli

Le prove possono essere fornite tramite le impostazioni di configurazione dei meccanismi di protezione usati per garantire che i dati piI siano protetti in linea con il requisito di controllo. Tali meccanismi possono includere controlli di accesso, controllo degli accessi in base al ruolo, crittografia, prevenzione della perdita di dati e così via.

Dichiarazione di non responsabilità: gli esempi presentati mostrano alcuni scenari potenziali in cui vengono applicati i controlli per garantire la protezione delle informazioni personali. Si noti che il tipo di meccanismi di protezione in atto dipenderà dal contesto dell'organizzazione e dal modo in cui vengono usate, archiviate e così via.

Prova di esempio: Crittografia

Gli esempi seguenti mostrano la crittografia delle informazioni personali nel percorso di archiviazione in cui vengono mantenute le informazioni personali e la crittografia durante il transito tramite l'applicazione Web o la piattaforma in cui gli utenti inserirono le informazioni personali archiviate nel back-end dell'applicazione.

Gli screenshot dimostrano che il percorso di archiviazione dispone di dati inattivi crittografati per impostazione predefinita.

Si noti che se la crittografia non viene eseguita dalla piattaforma usata per impostazione predefinita e dalla propria crittografia

le chiavi sono in uso, quindi l'aspettativa è che tali chiavi siano adeguatamente protette e vengano fornite prove per dimostrarlo.

Il secondo screenshot mostra che TLS1.2 viene applicato in transito per l'applicazione in cui vengono raccolte informazioni personali.

Prova di esempio: controlli di accesso

Lo screenshot seguente illustra dal punto di vista della rete che solo l'intervallo IP autorizzato/approvato, ovvero la rete aziendale protetta, è autorizzato ad accedere al percorso di archiviazione delle informazioni personali.

Lo screenshot successivo mostra un esempio di Azure PIM e l'elenco di utenti con le assegnazioni idonee. Usando l'accesso JIT (Just-In-Time), consente agli utenti di ottenere l'accesso temporaneo a un ruolo o a una risorsa con privilegi per un periodo di tempo limitato, riducendo il rischio di compromissione di un utente con privilegi o di introduzione di modifiche all'ambiente, alle posizioni dei dati e così via.

Prova di esempio: prevenzione della trasmissione e della divulgazione delle informazioni personali

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

Di seguito è possibile osservare che è abilitato un criterio "Dati PII del Regno Unito". Ciò consente di impedire agli utenti di fornire dati sensibili a siti Web specifici, tra cui messaggi di posta elettronica personali, richieste generative di intelligenza artificiale, siti di social media e altro ancora quando si accede tramite un Web browser supportato. Ciò garantisce che il rischio di potenziali violazioni della riservatezza o divulgazione non autorizzata di informazioni personali da parte del dipendente venga ridotto man mano che tutti i dispositivi/utenti dell'area di lavoro hanno applicato i criteri dell'organizzazione.

Gli screenshot successivi offrono una panoramica completa dei criteri, incluso l'ambito a cui è applicato. Il criterio è impostato su tutti gli account in posizioni quali SharePoint, Dispositivi, OneDrive e così via.

Lo screenshot precedente e seguente mostra che i criteri DLP sono impostati per impedire agli utenti di copiare e incollare informazioni riservate, ad esempio informazioni personali

dai database interni dell'organizzazione ai propri account di posta elettronica personali, chatbot e siti di social media nei browser supportati.

Finalità: record

La finalità di questo sottopunto è duplice; garantisce che sia in atto una gestione efficace dei record per facilitare la governance dei dati e la protezione dei dati, garantendo al tempo stesso la conformità e la responsabilità legali, in quanto il trasferimento di informazioni personali in diversi paesi comporta la navigazione in diversi requisiti legali. Prima di avviare un trasferimento di informazioni personali, un'organizzazione deve assicurarsi di avere il consenso esplicito degli interessati a cui appartiene, tali persone devono essere informate circa il trasferimento, lo scopo del trasferimento e il rischio associato. Il record del consenso ottenuto convaliderà l'autorizzazione del trasferimento. Il record dei trasferimenti deve contenere anche dettagli aggiuntivi sul trasferimento, la valutazione dei rischi, l'impatto sulla protezione dei dati e il periodo di conservazione.

Linee guida: record

Le prove che possono essere fornite per i record dei trasferimenti di informazioni personali e i record del consenso espresso dipenderanno da come viene implementato il processo di trasferimento e la gestione dei record a livello di organizzazione. Ciò può includere se il consenso viene ottenuto tramite una piattaforma, termini e condizioni del servizio o tramite moduli di consenso compilati da ogni utente. Le prove fornite devono dimostrare che esistono i registri cronologici dei trasferimenti completati in un periodo e come viene rilevato, nonché i record di consenso esplicito ottenuto.

Prova di esempio: record

Lo screenshot successivo mostra un esempio di modulo di consenso compilato da uno degli utenti dei servizi dell'organizzazione. È possibile notare che l'utente ha fornito consenso esplicito, riconoscimento e comprensione delle condizioni.

Lo screenshot seguente mostra che esiste un record cronologico dei trasferimenti di informazioni personali e include i dettagli dei dati pii specifici scambiati, lo scopo del trasferimento, il paese di origine, il paese di destinazione, la protezione dei dati in transito, l'approvazione e così via.

Nota: il precedente è un esempio di uno scenario potenziale, non è affatto completo e quando si forniscono prove, il processo per il trasferimento dei dati piI, la gestione dei record e così via deve essere chiaramente dimostrato e deve essere applicato al contesto specifico dell'organizzazione.

GDPR

La maggior parte delle organizzazioni esetterà dati che sono potenzialmente dati di un cittadino europeo (interessati). Quando vengono elaborati i dati di QUALSIASI interessato, le organizzazioni dovranno rispettare il Regolamento generale sulla protezione dei dati (GDPR). Questo vale sia per i titolari del trattamento dei dati (si sta acquisendo direttamente tali dati) che per i responsabili del trattamento dei dati (questi dati vengono elaborati per conto di un titolare del trattamento dei dati). Anche se questa sezione non copre l'intero regolamento, affronta alcuni degli elementi chiave del GDPR per ottenere una certa garanzia che l'organizzazione stia prendendo sul serio il GDPR.

Controllo n. 12

Fornire prove che dimostrino che:

• Gli interessati sono in grado di generare richieste sacr.

• Verificare di essere in grado di identificare tutte le posizioni dei dati degli interessati quando si risponde a una richiesta DISA.

• È previsto un periodo di conservazione per i backup che consente ai client che richiedono la rimozione dei dati tramite i file SAR di essere rimossi quando vengono rimossi i backup in sequenza in un periodo di tempo (ciclo di vita delle eliminazioni di backup meno recenti/riscritto).

Finalità:

Il GDPR include obblighi specifici che devono essere soddisfatti dalle organizzazioni che elaborano i dati degli interessati. L'obbligo per le organizzazioni di gestire le richieste di accesso soggetto (SAR) è incluso nell'articolo 12 che, ai sensi dell'articolo 12.3, concede a un titolare del trattamento dei dati un mese dalla ricezione del sar per rispondere alla richiesta. Una proroga è consentita per altri due mesi se necessario e solo se vi è una giustificazione a tale scopo. Anche se l'organizzazione agisce come responsabile del trattamento dei dati, ciò sarà comunque necessario per aiutare i clienti (il titolare del trattamento dei dati) a rispettare i propri obblighi di titolare del trattamento dei dati.

Linee guida:

Specificare il processo documentato per la gestione delle richieste SAR. Prova di esempio:

Nell'esempio seguente viene illustrato un processo documentato per la gestione delle richieste SAR.

Nota: questo screenshot mostra un documento di criteri/processo, l'aspettativa è che gli ISV condividano la documentazione effettiva relativa ai criteri/procedure di supporto.

Finalità:

Lo scopo di questo controllo è garantire che l'organizzazione disponga di un meccanismo solido per identificare tutti i dati degli interessati. Può trattarsi di un processo manuale perché tutta l'archiviazione dei dati è ben documentata o altri strumenti possono essere usati per garantire che tutti i dati si trovino nell'ambito del processo di registrazione dei dati.

Linee guida:

Le prove possono essere fornite tramite un elenco di tutte le posizioni dei dati e un processo documentato per cercare i dati in tutte le posizioni dei dati. Sono inclusi tutti i comandi necessari per cercare i dati, ad esempio se sono inclusi percorsi SQL, istruzioni SQL specifiche verranno dettagliate per garantire che i dati vengano trovati correttamente.

Prova di esempio:

Lo screenshot successivo è un frammento della procedura del SAR precedente che mostra come verranno trovati i dati.

Le quattro immagini seguenti illustrano come sono state eseguite query sui percorsi dei dati ISV e Storage Explorer è stato usato per eseguire il drill-down dei file o del BLOB che dovevano essere rimossi dall'archiviazione per essere conformi alla richiesta SAR.

Nota: questi esempi non sono screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e il timestamp e data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

Questa query conferma gli account di archiviazione in uso. È possibile eseguire query e rimuovere archiviazione, BLOB e/o file usando Resource Graph Explorer (Kusto) o PowerShell (vedere la pagina successiva).

Nota: per gli esempi in questa sezione non sono stati usati screenshot completi, tuttavia tutti gli screenshot delle prove inviate da ISV devono essere screenshot a schermo intero che mostrano l'URL, l'ora e la data dell'utente e del sistema connessi.

L'immagine successiva mostra i dati trovati all'interno del contenitore BLOB per il client che devono essere rimossi e l'azione seguente mostra l'azione per eliminare o eliminare temporaneamente le informazioni nel BLOB.

Nota: gli esempi non sono screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e il timestamp e la data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

Finalità:

Questo controllo ha lo scopo di dimostrare l'esistenza di un periodo di conservazione formale per i backup, progettato in modo da supportare la rimozione dei dati ai sensi delle sanatorie. Il framework di conservazione deve consentire l'eliminazione graduale dei backup meno recenti in un periodo definito, assicurando che tutti i dati rimossi a causa di un sar vengano infine cancellati da tutti i backup. Ciò è fondamentale per allineare le procedure di backup e conservazione dei dati dell'organizzazione agli obblighi derivanti dalle autorità di certificazione, rispettando così i requisiti normativi relativi al diritto alla cancellazione.

Linee guida:

È possibile fornire prove tramite uno screenshot che mostra le impostazioni di configurazione del backup che illustrano il periodo e la metodologia con cui vengono eseguiti i backup. L'enfasi deve essere posta sul periodo di frequenza del backup.

Prova di esempio:

Lo screenshot seguente è un frammento di impostazioni di configurazione dal database di Azure per MySQL, un'istanza gestita.

È possibile vedere nello screenshot che il periodo di conservazione del backup è impostato per 28 giorni.

In base alla sezione backup, è noto che i backup nei server flessibili sono snapshot basati sul primo backup dello snapshot viene pianificato immediatamente dopo la creazione di un server e vengono eseguiti altri backup snapshot ogni giorno una volta.

La conservazione dei backup di 28 giorni combinata con la frequenza di backup significa che quando viene soddisfatto un sar, il backup in sequenza continuerà per un massimo di 27 giorni in sequenza e diminuirà in base al periodo di conservazione fino a quando non vengono rimossi tutti i dati utente.

Controllo n. 13

Fornire l'informativa sulla privacy che deve contenere tutti gli elementi necessari come indicato di seguito:

• Dettagli entità (nome, indirizzo e così via)

• Dettagli sul tipo di dati personali elaborati.

• Dettagli per quanto tempo verranno conservati i dati personali.

• Dettagli sulla liceità del trattamento dei dati personali.

• Dettagli dei diritti dell'interessato:

  • Diritto di essere informati

  • Diritto di accesso da parte dell'interessato

  • Diritto alla cancellazione

  • Diritto alla restrizione dell'elaborazione

  • Diritto alla portabilità dei dati

  • Diritto all'oggetto

  • Diritti relativi al processo decisionale automatizzato, inclusa la profilatura

Finalità:

L'articolo 13 del GDPR include informazioni specifiche che devono essere fornite agli interessati nel momento in cui vengono ottenuti i dati personali. Lo scopo di questo controllo è garantire che l'informativa sulla privacy dei dati delle organizzazioni fornisca agli interessati alcune delle informazioni chiave incluse nell'articolo 13.

Linee guida:

Questo sarebbe in genere fornito fornendo l'informativa sulla privacy dei dati. Gli analisti di certificazione esamineranno questo aspetto per assicurarsi che tutte le informazioni fornite all'interno del controllo siano incluse nell'informativa sulla privacy dei dati.

Prova di esempio:

Gli screenshot successivi mostrano gli snapshot di un'informativa sulla privacy.

Nota: questi esempi non sono screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e il timestamp e la data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

Le immagini di un'informativa sulla privacy mostrano un esempio di informativa sulla privacy online con l'articolo 13 del GDPR incluso.

Di seguito è riportato un criterio di protezione dei dati che può essere usato in combinazione con l'informativa sulla privacy mostrata in precedenza.

L'immagine precedente di Azure mostra come Azure è stato configurato per soddisfare i requisiti di conformità del GDPR per i dati archiviati in un ambiente back-end. Il criterio (che può essere personalizzato o compilato da Azure Blueprints) consente all'ISV di garantire che i dati del client siano archiviati correttamente e che siano accessibili solo dalle metriche specificate. Inoltre, gli avvisi sono impostati per garantire la conformità e mostreranno i dati non conformi o l'accesso utente nel dashboard di Compliance Manager.

Nota: gli esempi precedenti non sono screenshot a schermo intero, ti verrà richiesto di inviare screenshot a schermo intero con qualsiasi URL, utente connesso e il timestamp e la data per la revisione delle prove. Se si è un utente Linux, questa operazione può essere eseguita tramite il prompt dei comandi.

HIPAA (Health Insurance Portability and Accountability Act)

Il 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 riguarda anche tutte le organizzazioni al di fuori degli Stati Uniti che elaborano i dati sanitari dei cittadini americani. L'introduzione della legislazione imponeva al Segretario del Dipartimento della Salute e dei Servizi Umani (HHS) degli Stati Uniti di sviluppare normative che proteggevano 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 singolarmente trasmesse da supporti elettronici, mantenute in supporti elettronici o trasmesse o mantenute in qualsiasi altra forma o supporto. Quando vengono elaborati i dati sull'integrità di QUALSIASI interessato, le organizzazioni dovranno soddisfare HIPAA.

HIPAA ha due leggi che devono essere considerate: "La regola sulla privacy" o Standard per la privacy delle informazioni sanitarie identificabili singolarmente, che delinea gli standard nazionali per la protezione di determinate informazioni sanitarie, e "Gli standard di sicurezza" per la protezione delle informazioni sanitarie protette elettroniche, dette anche "regola di sicurezza". Quest'ultimo stabilisce un insieme nazionale di norme di sicurezza per la protezione di determinate informazioni sanitarie che vengono conservate o trasferite in forma elettronica.

Da una panoramica generale, "La regola di sicurezza" è un'implementazione pratica delle protezioni offerte dalla "regola sulla privacy". Descrive le misure tecniche e non tecniche che le "entità coperte" devono implementare per garantire la sicurezza delle "informazioni sanitarie protette elettroniche" (e-PHI) degli individui. Anche se questa sezione non copre l'intero regolamento, affronta alcuni degli elementi chiave di HIPAA per ottenere una certa garanzia che l'organizzazione soddisfi il requisito e che l'organizzazione stia proteggendo le informazioni sanitarie che elabora.

Controllo n. 14

Fornire prove dimostrabili che:

• Esiste un criterio per la gestione HIPAA e HIPAA all'interno dell'organizzazione per il personale, gli appaltatori e così via.

• L'ISV garantisce la riservatezza, l'integrità e la disponibilità di ePHI che crea, riceve, gestisce o trasmette.

• Proteggere da eventuali minacce ragionevolmente previste e pericoli per la sicurezza o l'integrità di ePHI.

Finalità:

Lo scopo di questo sottopunto è garantire che le organizzazioni abbiano stabilito protocolli che fungono da procedure standard per la gestione delle informazioni sull'integrità, la gestione di emergenze e interruzioni dei servizi e l'accesso del personale alle informazioni e alla formazione sull'integrità. Inoltre, si prevede che le organizzazioni mantengano e descrivono queste misure di sicurezza amministrative nell'ambito del programma di sicurezza HIPAA. Si tratta di un aspetto fondamentale del rispetto delle normative HIPAA.

Linee guida:

Ciò sarebbe dimostrato fornendo la documentazione stabilita dall'organizzazione che delinea i criteri e la procedura HIPAA. Gli analisti di certificazione esamineranno questa certificazione per assicurarsi che tutte le informazioni fornite all'interno del controllo siano risolte.

Prova di esempio:

Gli screenshot mostrano gli snapshot di un criterio HIPAA. Nota: l'aspettativa è che gli ISV condividano la documentazione effettiva dei criteri/procedure di supporto e non forniscano semplicemente uno screenshot.

Nota: l'aspettativa è che un ISV condivida la documentazione completa dei criteri/procedure di supporto e non fornisca semplicemente uno screenshot.

Finalità:

Per comprendere la finalità di questo sottopunto e garantire la conformità alla regola di sicurezza, le "entità coperte" devono innanzitutto conoscere come vengono definite le condizioni per la riservatezza, l'integrità e la disponibilità ai sensi della sezione 164.304:

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

• Integrità: "la proprietà che i dati o le informazioni non sono stati modificati o distrutti in modo non autorizzato".

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

Lo scopo di questo requisito è che le organizzazioni implementino misure o misure tecniche quali l'accesso, il controllo, l'integrità e i controlli di trasmissione all'interno dell'infrastruttura IT per garantire la riservatezza ePHI mantenendone l'integrità e la disponibilità per gli utenti autorizzati.

Linee guida:

Le prove possono essere fornite tramite le impostazioni di configurazione dei meccanismi di protezione usati per garantire che i dati ePHI siano protetti in linea con il requisito di controllo. Tali meccanismi possono includere controlli di accesso, procedure di accesso di emergenza, controllo degli accessi in base al ruolo, crittografia e così via.

Prova di esempio: controlli di accesso e integrità

Lo screenshot successivo mostra che esiste un elenco di accesso autorizzato di utenti che dispongono delle autorizzazioni per gestire i percorsi di archiviazione ePHI e viene gestito all'interno del documento sui criteri HIPAA. Inoltre, negli screenshot che seguono l'elenco di inventario approvato è possibile osservare che l'accesso in scrittura nel cluster è limitato e solo l'amministratore e l'analista della manutenzione del database possono 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à.

La prima schermata mostra il percorso di archiviazione o il cluster di database principale per ePHI.

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

Le due schermate successive mostrano una visualizzazione più granulare di ognuno dei ruoli assegnati e di tutte le autorizzazioni associate in linea con l'approvazione di accesso precedente.

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

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

Prova di esempio: controlli di controllo

Queste schermate mostrano che la registrazione e gli avvisi sono implementati per il cluster di database. La prima schermata mostra che gli avvisi sono abilitati. Si noti che l'aspettativa è che l'evidenza fornita mostri anche le regole di avviso impostate in base alle esigenze/implementazione dell'organizzazione. La seconda schermata mostra che è in corso l'abilitazione del controllo del database.

Lo screenshot successivo mostra la cronologia di accesso al cluster di database registrato. L'aspettativa è che gli avvisi siano impostati e in base ai log di controllo e qualsiasi accesso non autorizzato che non soddisfi le condizioni predefinite attiverà un avviso.

Le due schermate 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 sia in atto un processo per l'analisi dei log di controllo generati e che sia necessario fornire anche le prove del processo di revisione. Se questa operazione viene eseguita a livello di codice, è necessario fornire screenshot delle impostazioni di configurazione dell'inserimento del log nella soluzione di piattaforma/registrazione usata, nonché screenshot delle regole per la revisione.

Prova di esempio: controlli di crittografia e trasmissione

Gli screenshot successivi dimostrano che il percorso di archiviazione contiene dati inattivi crittografati per impostazione predefinita. Si noti che se la crittografia non viene eseguita dalla piattaforma usata per impostazione predefinita e le proprie chiavi di crittografia sono in uso, si prevede che tali chiavi siano adeguatamente protette e vengano fornite prove per dimostrarlo.

I due screenshot successivi dimostrano che il percorso di archiviazione include dati in transito crittografati per impostazione predefinita. La prima schermata dimostra che un'API dati è abilitata con autorizzazioni di lettura e scrittura.

Un'analisi SSL dell'endpoint dimostra che i dati in transito vengono crittografati tramite TLS 1.2.

Prova di esempio: controlli di disponibilità e ripristino

Lo screenshot successivo dimostra 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 il dashboard di backup del cluster che mostra anche che è già stato creato uno snapshot.

I due screenshot successivi illustrano che è in atto un criterio di backup per eseguire backup pianificati in momenti diversi.The next two screenshots demonstrate that a backup policy is in place to perform scheduled backups at different points in time (PIT).

Di seguito è indicato un criterio di conservazione sia per gli snapshot che per il ripristino temporizzato.

Finalità:

Lo scopo di questo sottopunto è allineato alla regola di sicurezza sviluppata per garantire flessibilità e scalabilità in modo che un'"entità coperta" possa implementare criteri, procedure e soluzioni tecnologiche adatte allo scopo per le dimensioni dell'entità, la struttura organizzativa e i rischi specifici, nonché la propensione al rischio. Dal punto di vista pratico, ciò significa che le misure di sicurezza appropriate implementate dipenderanno dalla natura dell'attività dell'entità coperta, nonché dalle dimensioni e dalle risorse.

È fondamentale che ogni organizzazione conduca un'analisi completa dei rischi per individuare potenziali rischi e vulnerabilità per la riservatezza, l'integrità e la disponibilità di e-PHI. Tramite 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 dei rischi. Quando l'analisi dei rischi viene eseguita e gestita tramite una piattaforma online, devono essere forniti screenshot dell'intero output.

Prova di esempio:

Gli screenshot successivi mostrano gli snapshot del processo di valutazione dei rischi, seguiti dall'analisi dei rischi eseguita per determinare la misura in cui i controlli vengono implementati correttamente e funzionano come previsto per proteggere ePHI. Il secondo screenshot mostra un'analisi dei rischi per i rischi identificati nella valutazione dei rischi e i controlli e le mitigazioni di compensazione implementati per ridurre il livello di rischio.

Esempio 1: snapshot del processo di valutazione dei rischi all'interno dei criteri HIPAA e dell'analisi dei rischi 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 dei rischi all'interno dei criteri HIPAA e dell'analisi dei rischi eseguita (Gestito nella piattaforma cloud confluence)

Il secondo screenshot mostra un'analisi dei rischi per i rischi identificati nella valutazione dei rischi e i controlli e le mitigazioni di compensazione implementati per ridurre il livello di rischio. È possibile notare che esiste e viene mantenuto nella piattaforma cloud Confluence.

Controllo n. 15

Fornire la prova che l'utente (ISV):

• Protegge da usi ragionevolmente previsti o divulgazione di tali informazioni che non sono consentite dalla regola sulla privacy; E

• Garantire la conformità con la regola di sicurezza da parte del personale.

• Piano di backup dei dati e ripristino di emergenza ai sensi della versione 164..308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B).

Intento

La regola sulla privacy definisce quali parti di Informazioni sanitarie protette (PHI) sono coperte dalla legge e proibisce usi e divulgazione impropri di PHI. Lo scopo di questo sottopunto è 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 deve rispettare la regola minima necessaria, che richiede loro di usare o divulgare solo la quantità minima di e-PHI necessaria per realizzare lo scopo previsto.

Per limitare l'uso dell'ePHI e garantire la riduzione del rischio di divulgazione dell'ePHI, deve essere presente una combinazione di misure di sicurezza tecniche e amministrative.

Linee guida:

Le prove fornite devono mostrare le misure di sicurezza tecniche in atto, ad esempio tecnologie e meccanismi in uso per proteggere e-PHI e come l'organizzazione controlla l'accesso e lo spostamento di tali dati.

Prova di esempio:

Gli screenshot successivi mostrano Prevenzione della perdita dei dati Microsoft Purview (DLP), una piattaforma integrata che consente alle organizzazioni di gestire i 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 agli utenti di incollare dati sensibili a siti Web specifici, tra cui posta elettronica personale, richieste generative di intelligenza artificiale, siti di social media e altro ancora quando si accede tramite un Web browser supportato.

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

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

Le due schermate successive mostrano la definizione del contenuto e le condizioni che devono essere soddisfatte per l'applicazione dei criteri.

I criteri riguardano vari tipi di dati sensibili e un set di classificatori.

La sezione successiva mostra le azioni configurate per l'esecuzione quando vengono soddisfatte le condizioni visualizzate negli screenshot precedenti.

Lo screenshot seguente mostra che i criteri DLP sono impostati per impedire agli utenti di copiare e incollare informazioni riservate, ad esempio informazioni personali (PII) dai database interni dell'organizzazione nei propri account di posta elettronica personali, chatbot e siti di social media nei browser supportati.

Infine, le notifiche utente 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 evento imprevisto.

Finalità:

Lo scopo di questo sottopunto è che un'organizzazione deve formare il proprio personale su come gestire e-PHI in modo sicuro e appropriato e che deve applicare criteri 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 ePHI e che esistono record di frequenza e completamento della formazione. Se applicabile, questo può essere supportato dalla documentazione dei criteri e dai materiali di formazione usati.

Prova di esempio:

Gli esempi seguenti illustrano le potenziali prove che possono essere inviate per dimostrare che il training HIPAA appropriato avviene in linea con i criteri.

Lo screenshot successivo mostra uno snapshot dei criteri HIPAA con una sezione specifica che descrive il requisito per il training. Si noti che questo è solo un esempio e non un documento/implementazione completo, l'aspettativa è che l'ISV avrà un processo stabilito applicabile alla propria organizzazione.

Esempio 1: training utente HIPAA tramite processo amministrativo

Nello screenshot successivo la diapositiva panoramica del corso mostra un riepilogo degli obiettivi del corso. Se la formazione viene compilata all'interno dell'azienda, i materiali di formazione devono essere forniti per la revisione, si noti che il materiale completo deve essere inviato e non solo uno screenshot del riepilogo.

Lo screenshot seguente mostra il record di partecipazione per i dipendenti che hanno partecipato alla formazione. Il record mostra anche il punteggio di superamento e la data pianificata del training successivo.

Il secondo esempio illustra come usare Microsoft 365 Defender per impostare e avviare campagne di formazione.

Esempio 2: formazione degli utenti HIPAA tramite Microsoft 365 Defender Attack Simulation Platform (Tutti gli utenti)

Lo screenshot precedente mostra la campagna di training HIPAA Security, la durata totale in minuti e lo stato di completamento. Lo screenshot successivo fornisce una panoramica degli utenti a cui è stato assegnato il training e lo stato del training che mostra il completamento corretto.

Esempio 3: Training utente HIPAA tramite microsoft 365 Defender Attack Simulation Platform (singolo utente)

Mentre l'esempio precedente si è concentrato 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.

È possibile osservare nei due screenshot precedenti che non appena è stata avviata la campagna di formazione, ogni dipendente ha ricevuto un messaggio di posta elettronica che conferma l'assegnazione del training e la data di scadenza, nonché i moduli assegnati, la durata e così via.

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

Finalità:

In base alla regola di sicurezza HIPAA, un piano di backup dei dati e un piano di ripristino di emergenza sono obbligatori per qualsiasi "entità coperta" che gestisce le informazioni sanitarie protette elettroniche (ePHI). Tali piani fanno parte della strategia di emergenza che mira a garantire la disponibilità e la sicurezza di ePHI in caso di emergenza o altro evento che danneggia i sistemi che contengono ePHI.

Lo scopo del piano di backup dei dati è creare e mantenere copie identiche recuperabili di ePHI, che devono includere anche test periodici dei backup per garantire che sia possibile il ripristino dei dati. Lo scopo del piano di ripristino di emergenza è ripristinare eventuali dati persi in caso di emergenza, specificando i passaggi da eseguire per ripristinare l'accesso ai dati, inclusa la modalità di ripristino dei file dai backup.

Linee guida:

Specificare la versione completa del piano o della procedura di ripristino di emergenza che deve coprire il piano di backup e il piano di ripristino. Fornire il documento PDF/Word effettivo se in una versione digitale, in alternativa se il processo viene gestito tramite una piattaforma online fornire un'esportazione PDF o se non è possibile esportare a causa di limitazioni della piattaforma, fornire screenshot che coprono l'intero criterio.

Prova di esempio:

Lo screenshot successivo mostra gli snapshot dei criteri 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 del 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) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2nd Edition, Publisher: CreateSpace Independent Publishing Platform.

Riferimenti

• Action Fraud Cyber Crime Reporting Disponibile all'indirizzo: https://www.actionfraud.police.uk/ (Accesso: 10/12/2023).

• UE. (2021) Elenco 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: 05/03/2024).

• Tecnologie positive. (2020) How to approach secure software development Available at: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).

• Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016 sulla protezione delle persone fisiche per quanto riguarda il trattamento dei dati personali e sulla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (Regolamento generale sulla protezione dei dati) (Testo rilevante per il SEE) (2016) Disponibile all'indirizzo: (Accessibile: https://www.legislation.gov.uk/eur/2016/679/contents 10/12/2023).

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

• Williams J. OWASP Risk Ranking Disponibile all'indirizzo: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (accessibile: 10/12/2023).

• Qualys. (2014) SSL Labs: Nuovi livelli di attendibilità (T) e problemi di mancata corrispondenza (M) disponibili all'indirizzo: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accesso: 10/12/2023).

• NIST SP800-61r2: Guida alla gestione degli eventi imprevisti per la sicurezza dei computer 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 il motore di Google Kubernetes | .NET

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

• Il piano di ripristino di emergenza è disponibile 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 all'indirizzo: https://www.sans.org/information-security-policy/ (Accesso: 10/10/23).

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

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

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

• Modello di esercizio della tabella BCP (Business Continuity Plan) all'indirizzo: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Accessibile: 10/10/23).

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

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

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

• Cosa è considerato PHI in HIPAA? Aggiornamento 2023 (hipaajournal.com) (Accesso: 10/18/2023).

• Criteri e procedure HIPAA (hipaajournal.com) ( accesso: 10/18/2023).

• Progettazione di criteri HIPAA & criteri amministrativi | Soluzioni Dash (dashsdk.com) (accesso: 10/18/2023).

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

• / Legal Information Institute (cornell.edu) (accesso: 10/18/2023).

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

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

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

• SP 800-66 Rev. 1, Guida introduttiva alle risorse per l'implementazione dellaregola di sicurezza HIPAA (Health Insurance Portability and Accountability Act) | CSRC (nist.gov) (accesso: 10/18/2023).

• Regola di sicurezza | HHS.gov (accesso: 10/18/2023).

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

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

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

• https://www.restore.co.uk/Records/Services/Magnetic-Tape-Storage (Accesso: 10/19/2023).

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

• Configurare la crittografia - Manuale di MongoDB (accesso: 10/19/2023).

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

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

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

• 45 CFR § 164.308 - Misure di sicurezza amministrative. | Codice elettronico delle normative federali (e-CFR)

• | Legge degli Stati Uniti | LII/Legal Information Institute> (cornell.edu) (accesso: 10/24/2023).

• https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (Accesso: 10/24/2023).

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

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

• Framework di responsabilità | ICO (accessibile: 11/08/2023).

• Requisito 5.1 ISO 27001 - Impegno & leadership | ISMS.online (accesso: 11/08/2023).

• Piattaforma di esplorazione online (OBP) (iso.org) (accesso: 11/08/2023).

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

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

• Principio (c): minimizzazione dei dati | ICO (accessibile: 11/08/2023).

• De-identificazione e nuova identificazione delle informazioni personali in set di dati su larga scala tramite La protezione dei dati sensibili| Cloud Architecture Center | Google Cloud (accesso: 11/08/2023).

• De-identificare i dati sensibili | Documentazione relativa alla protezione dei dati sensibili | Google Cloud (accesso: 11/08/2023).

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

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

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

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

• ISO 27701 Privacy Information Management System (PIMS) | ISMS.Online (accesso: 11/08/2023).

Immagini/testo tratti da Documenti Microsoft

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

• Ottenere analisi del comportamento e rilevamento anomalie (accesso:03/05/24).

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

• Ottenere analisi comportamentale e rilevamento 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: 10/09/23).

• Che cos'è Azure Information Protection?

• Transparent data encryption for database SQL, Istanza gestita di SQL e Azure Synapse Analytics (accesso:03/05/24).

• Avvio rapido: Creare un'assegnazione di criteri per identificare le risorse non conformi (accesso:03/05/24).

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

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

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

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

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

Ulteriori informazioni

• Guida alle prove di esempio - Panoramica
• Guida alle prove di esempio - Operazioni