Assicurarsi che i file binari che contengono informazioni riservate vengano offuscati
Titolo
Dettagli
Componente
Limite di Trust del computer
Fase SDL
Distribuzione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Assicurarsi che vengano offuscati i file binari che contengono informazioni riservate, come segreti commerciali o logica di business riservata che non deve essere sottoposta a reverse engineering. Questa misura consente di prevenire il reverse engineering degli assembly. A questo scopo, è possibile usare strumenti come CryptoObfuscator.
Valutare l'uso della tecnologia EFS (Encrypting File System) per proteggere dati riservati specifici dell'utente
Titolo
Dettagli
Componente
Limite di Trust del computer
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Valutare l'uso della tecnologia EFS (Encrypting File System) per proteggere i dati riservati specifici dell'utente da antagonisti che abbiano fisicamente accesso al computer.
Assicurarsi che i dati sensibili archiviati dall'applicazione nel file system vengano crittografati
Titolo
Dettagli
Componente
Limite di Trust del computer
Fase SDL
Distribuzione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Se non è possibile applicare la tecnologia EFS, assicurarsi che i dati sensibili archiviati dall'applicazione nel file system vengano crittografati, ad esempio tramite DPAPI.
Assicurarsi che i contenuti sensibili non vengano memorizzati nella cache del browser
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Creazione
Tecnologie applicabili
Generico, Web Form, MVC 5, MVC 6
Attributi
N/D
Riferimenti
N/D
Passaggi
I browser possono archiviare informazioni per motivi di memorizzazione nella cache e cronologia. Questi file memorizzati nella cache vengono archiviati in una cartella, come la cartella File temporanei Internet nel caso di Internet Explorer. Quando queste pagine vengono visitate di nuovo, il browser le visualizza dalla cache. Se all'utente vengono visualizzate informazioni riservate (ad esempio il proprio indirizzo, i dettagli della carta di credito, il numero di previdenza sociale o il nome utente), queste informazioni potrebbero essere archiviate nella cache del browser e quindi recuperabili esaminando la cache del browser o semplicemente premendo il pulsante "Indietro" del browser. Impostare il valore dell'intestazione della risposta del controllo cache su "no-store" per tutte le pagine.
Per l'implementazione è possibile usare un filtro. È possibile usare l'esempio seguente:
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Crittografare le sezioni dei file di configurazione dell'app Web contenenti dati sensibili
I file di configurazione, ad esempio Web.config e appsettings.json, vengono spesso usati per memorizzare informazioni sensibili, inclusi nomi utente, password, stringhe di connessione del database e chiavi di crittografia. Se non si proteggono queste informazioni, l'applicazione è vulnerabile agli utenti malintenzionati che ottengono informazioni sensibili, ad esempio nomi account utente e password, nomi dei database e nomi dei server. In base al tipo di distribuzione (Azure/locale), crittografare le sezioni sensibili dei file config usando DPAPI o servizi come Azure Key Vault.
Disabilitare in modo esplicito l'attributo HTML di completamento automatico in input e moduli sensibili
L'attributo autocomplete specifica se la funzionalità di completamento automatico di un modulo debba essere abilitata o disabilitata. Quando il completamento automatico è abilitato, il browser completa automaticamente i valori in base a valori immessi in precedenza dall'utente. Ad esempio, quando si immette un nuovo nome e una password in un modulo, che poi viene inviato, il browser chiede se si vuole salvare la password. Quando il modulo viene visualizzato successivamente, il nome e la password vengono popolati automaticamente o vengono compilati immettendo il nome. Un utente malintenzionato con accesso in locale può ottenere la password non crittografata dalla cache del browser. Il completamento automatico è abilitato per impostazione predefinita e deve essere disabilitato in modo esplicito.
Assicurarsi che i dati sensibili visualizzati nella schermata dell'utente vengano mascherati
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
I dati sensibili, come password, numeri di carte di credito, codice fiscale e così via devono essere mascherati quando vengono visualizzati sullo schermo. Questa misura serve a impedire l'accesso ai dati da parte di personale non autorizzato, ad esempio con la tecnica dello shoulder surfing o la visualizzazione del codice fiscale dell'utente da parte del personale di supporto. Assicurarsi che questi elementi di dati non siano visibili come testo normale e vengano mascherati in modo appropriato. Questo deve essere preso cura di accettarli come input (ad esempio, input type="password") e visualizzare nuovamente sullo schermo (ad esempio, visualizzare solo le ultime 4 cifre del numero di carta di credito).
Implementare la maschera dati dinamica per limitare l'esposizione di dati sensibili a utenti senza privilegi
Lo scopo della maschera dati dinamica consiste nel limitare l'esposizione dei dati sensibili, impedendo la visualizzazione dei dati agli utenti che non dovrebbero averne accesso. La maschera dati dinamica non mira a impedire agli utenti del database di connettersi direttamente al database ed eseguire query complete che espongano parti dei dati sensibili. La maschera dati dinamica è complementare ad altre funzionalità di sicurezza di SQL Server, come il controllo, la crittografia, la sicurezza a livello di riga e così via, ed è consigliabile usarla insieme a tali funzionalità per proteggere meglio i dati sensibili nel database. Si noti che questa funzionalità è supportata unicamente da SQL Server, a partire dalla versione 2016, e dal database SQL di Azure.
Assicurarsi che le password vengano archiviate in formato hash con valori salt
Le password non devono essere archiviate in database dell'archivio utenti personalizzati. Gli hash delle password devono invece essere archiviati con valori salt. Assicurarsi che il valore salt per l'utente sia sempre univoco e di applicare b-crypt, s-crypt o PBKDF2 prima di archiviare la password, con un conteggio delle iterazioni del fattore lavoro minimo di 150.000 cicli per eliminare la possibilità di attacchi di forza bruta.
Assicurarsi che i dati sensibili nelle colonne di database vengano crittografati
I dati sensibili, come i numeri di carte di credito, devono essere crittografati nel database. A tale scopo è possibile usare la crittografia a livello di colonna o una funzione di applicazione tramite funzioni di crittografia.
Assicurarsi che venga abilitata la crittografia a livello di database (TDE)
La funzionalità Transparent Data Encryption (TDE) in SQL Server consente di crittografare i dati sensibili in un database e proteggere le chiavi usate per crittografare i dati con un certificato. Questo impedisce l'uso dei dati senza le chiavi. TDE consente di proteggere i dati "non operativi", ovvero i file di dati e di log, e assicura la conformità a numerose leggi, normative e linee guida stabilite in vari settori.
Assicurarsi che i backup di database vengano crittografati
SQL Server permette di crittografare i dati durante la creazione di un backup. Specificando l'algoritmo di crittografia e il componente di crittografia, ad esempio un certificato o una chiave asimmetrica, durante la creazione di un backup, è possibile creare un file di backup crittografato.
Assicurarsi che i dati sensibili relativi all'API Web non vengano memorizzati nell'archivio del browser
Titolo
Dettagli
Componente
API Web
Fase SDL
Creazione
Tecnologie applicabili
MVC 5, MVC 6
Attributi
Provider di identità - ADFS, provider di identità - Microsoft Entra ID
Riferimenti
N/D
Passaggi
In alcune implementazioni, gli elementi sensibili relativi all'autenticazione dell'API Web vengono memorizzati nell'archivio locale del browser. Ad esempio, artefatti di autenticazione di Microsoft Entra come adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key e così via.
Tutti questi elementi sono disponibili anche dopo la disconnessione o la chiusura del browser. Se un antagonista ottiene accesso a questi elementi, può riutilizzarli per accedere alle risorse protette, ovvero alle API. Assicurarsi che tutti gli elementi sensibili relativi all'API Web non vengano memorizzati nell'archivio del browser. Nei casi in cui non è possibile evitare l'archiviazione lato client, ad esempio nel caso delle applicazioni a pagina singola che fanno uso di flussi OAuth/OpenID Connect impliciti e che devono archiviare i token di accesso in locale, usare le opzioni di archiviazione senza persistenza. Ad esempio, è preferibile usare SessionStorage anziché LocalStorage.
Esempio
Il frammento JavaScript seguente proviene da una libreria di autenticazione personalizzata che archivia gli elementi di autenticazione nell'archivio locale. Evitare le implementazioni di questo tipo.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for IE, as sessionStorage does not work for localhost.
};
Crittografare i dati sensibili archiviati in Azure Cosmos DB
Titolo
Dettagli
Componente
Azure DocumentDB
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Crittografare i dati sensibili a livello dell'applicazione prima di archiviarli in DocumentDB o in altre soluzioni di archiviazione come Archiviazione di Azure o SQL Azure.
Usare Crittografia dischi di Azure per crittografare i dischi usati dalle macchine virtuali
Titolo
Dettagli
Componente
Limite di trust della macchina virtuale IaaS di Azure
Crittografia dischi di Azure è una nuova funzionalità attualmente in anteprima. Questa funzionalità consente di crittografare i dischi dati e del sistema operativo usati da una macchina virtuale IaaS. Per Windows, le unità vengono crittografate mediante la tecnologia di crittografia BitLocker standard del settore. Per Linux, i dischi vengono crittografati mediante la tecnologia DM-Crypt, integrata nell'insieme di credenziali delle chiavi per consentire il controllo e la gestione delle chiavi di crittografia del disco. La soluzione Crittografia dischi di Azure supporta i tre scenari di crittografia dei clienti descritti di seguito:
Abilitare la crittografia in nuove VM IaaS create da file VHD crittografati dal cliente e chiavi di crittografia fornite dal cliente, che vengono archiviate nell'insieme di credenziali delle chiavi di Azure.
Abilitare la crittografia di nuove VM IaaS create da Azure Marketplace.
Abilitare la crittografia delle VM IaaS esistenti già in esecuzione in Azure.
Crittografare i segreti nelle applicazioni di Service Fabric
I segreti possono essere informazioni riservate, ad esempio le stringhe di connessione di archiviazione, le password o altri valori che non devono essere gestiti in testo normale. Usare Azure Key Vault per gestire le chiavi e i segreti nelle applicazioni di Service Fabric.
Eseguire la modellazione di sicurezza e usare team e unità aziendali quando richiesto
Titolo
Dettagli
Componente
Dynamics CRM
Fase SDL
Creazione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Eseguire la modellazione di sicurezza e usare team e unità aziendali quando richiesto
Ridurre al minimo l'accesso alla funzionalità di condivisione nelle entità critiche
Titolo
Dettagli
Componente
Dynamics CRM
Fase SDL
Distribuzione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Ridurre al minimo l'accesso alla funzionalità di condivisione nelle entità critiche
Istruire gli utenti sui rischi associati alla funzionalità di condivisione di Dynamics CRM e sulle procedure di sicurezza consigliate
Titolo
Dettagli
Componente
Dynamics CRM
Fase SDL
Distribuzione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Istruire gli utenti sui rischi associati alla funzionalità di condivisione di Dynamics CRM e sulle procedure di sicurezza consigliate
Includere una regola sugli standard di sviluppo che vieta la visualizzazione dei dettagli di configurazione nella gestione delle eccezioni
Titolo
Dettagli
Componente
Dynamics CRM
Fase SDL
Distribuzione
Tecnologie applicabili
Generica
Attributi
N/D
Riferimenti
N/D
Passaggi
Includere una regola sugli standard di sviluppo che vieta la visualizzazione dei dettagli di configurazione nella gestione delle eccezioni al di fuori del contesto di sviluppo. Testare tale regola come parte di revisioni del codice o ispezioni periodiche.
Usare Crittografia del servizio di archiviazione di Azure per dati inattivi (anteprima)
Crittografia del servizio di archiviazione di Azure per dati inattivi consente di proteggere e salvaguardare i dati, in modo da soddisfare i criteri di sicurezza e conformità dell'organizzazione. Questa funzionalità consente ad Archiviazione di Azure di crittografare automaticamente i dati prima della persistenza nella risorsa di archiviazione e di decrittografarli prima del recupero. La crittografia, la decrittografia e la gestione delle chiavi sono completamente trasparenti per gli utenti. SSE viene applicato solo per BLOB in blocchi, BLOB di pagine e BLOB di aggiunta. Altri tipi di dati, tra cui tabelle, code e file, non verranno crittografati.
Flusso di lavoro di crittografia e decrittografia:
Il cliente abilita la crittografia sull'account di archiviazione.
Quando il cliente scrive nuovi dati (PUT Blob, PUT Block, PUT Page e così via) nell'archivio BLOB, ogni operazione di scrittura viene crittografata mediante la crittografia AES a 256 bit, una delle crittografie a blocchi più solide tra quelle disponibili.
Quando il cliente deve accedere ai dati (GET Blob e così via), i dati vengono decrittografati automaticamente prima della restituzione all'utente.
Se la crittografia è disabilitata, le nuove operazioni di scrittura non vengono più crittografate e i dati crittografati esistenti rimangono crittografati fino a quando non vengono riscritti dall'utente. Quando la crittografia è abilitata, le operazioni di scrittura nell'archivio BLOB verranno sempre crittografate. Lo stato dei dati non cambia quando l'utente abilita/disabilita la crittografia per l'account di archiviazione.
Tutte le chiavi di crittografia vengono archiviate, crittografate e gestite da Microsoft.
Al momento, le chiavi usate per la crittografia sono gestite da Microsoft. Microsoft genera le chiavi in origine e ne gestisce l'archiviazione protetta, nonché la rotazione regolare secondo quanto definito dai criteri interni di Microsoft. In futuro, i clienti potranno gestire le proprie chiavi di crittografia e fornire un percorso di migrazione dalle chiavi gestite da Microsoft alle chiavi gestite dal cliente.
Usare la crittografia lato client per archiviare dati sensibili in Archiviazione di Azure
Il pacchetto NuGet della libreria client di archiviazione di Azure per .NET supporta la crittografia dei dati all'interno delle applicazioni client prima del caricamento in Archiviazione di Azure, nonché la decrittografia dei dati durante il download nel client. La libreria supporta anche l'integrazione con l'insieme di credenziali delle chiavi di Azure per la gestione delle chiavi dell'account di archiviazione. Ecco una breve descrizione del funzionamento della crittografia lato client:
Azure Storage Client SDK genera una chiave di crittografia del contenuto (CEK) che funziona come chiave simmetrica monouso.
I dati del cliente vengono crittografati con la chiave CEK.
Viene quindi eseguito il wrapping della chiave CEK mediante la chiave di crittografia della chiave (KEK). La chiave di crittografia della chiave è identificata con un identificatore di chiave e può essere costituita da una coppia di chiavi asimmetriche o da una chiave simmetrica. Può essere gestita localmente o archiviata in Azure Key Vault. Il client di archiviazione non ha mai accesso alla chiave KEK. Richiama solo l'algoritmo di wrapping della chiave fornito dall'insieme di credenziali chiave. Volendo, i clienti possono scegliere di usare provider personalizzati per il wrapping o la rimozione del wrapping delle chiavi.
I dati crittografati vengono quindi caricati nel servizio Archiviazione di Azure. Per informazioni dettagliate sull'implementazione, vedere i collegamenti riportati nella sezione dei riferimenti.
Crittografare le informazioni personali o i dati sensibili scritti nell'archivio locale del telefono
Se l'applicazione scrive le informazioni sensibili, come le informazioni personali dell'utente, vale a dire messaggi di posta elettronica, numero di telefono, nome, cognome, preferenze e così via, nel file system del dispositivo mobile, le informazioni devono essere crittografate prima della scrittura nel file system locale. Se si tratta di un'applicazione aziendale, valutare la possibilità di pubblicare l'applicazione tramite Microsoft Intune.
Esempio
Per proteggere i dati sensibili, è possibile configurare Intune con i criteri di sicurezza seguenti:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Esempio
Se non si tratta di un'applicazione aziendale, usare l'archivio chiavi offerto dalla piattaforma e i portachiavi per archiviare le chiavi di crittografia, tramite l'operazione di crittografia che può essere eseguita nel file system. Il frammento di codice seguente mostra come accedere alla chiave dal portachiavi usando Xamarin:
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Offuscare i file binari generati prima della distribuzione agli utenti finali
È necessario offuscare i file binari generati, ovvero gli assembly all'interno di APK, per impedire che gli assembly siano sottoposti a reverse engineering. A questo scopo, è possibile usare strumenti come CryptoObfuscator.
Impostare clientCredentialType su Certificate o su Windows
L'uso di UsernameToken con una password in testo normale tramite un canale non crittografato espone la password a utenti malintenzionati che potrebbero eseguire lo sniffing dei messaggi SOAP. I provider di servizi che fanno uso di UsernameToken possono accettare le password inviate in testo normale, ma l'invio di password in testo normale tramite un canale non crittografato può esporre le credenziali a utenti malintenzionati che potrebbero eseguire lo sniffing dei messaggi SOAP.
Esempio
La configurazione del provider di servizi WCF riportata di seguito fa uso di UsernameToken:
Non è stata definita alcuna sicurezza del trasporto o del messaggio. Le applicazioni che trasmettono messaggi senza sicurezza del trasporto o del messaggio non possono garantire l'integrità o la riservatezza dei messaggi. Quando un'associazione di sicurezza di WCF è impostata su None, la sicurezza del trasporto e quella del messaggio sono entrambe disabilitate.
Esempio
La configurazione seguente imposta la modalità di sicurezza su None.
Le associazioni ai servizi presentano cinque modalità di sicurezza possibili:
Nessuno. Disabilita la sicurezza.
Transport. Usa la sicurezza del trasporto per la protezione reciproca del messaggio e dell'autenticazione.
Messaggio. Usa la sicurezza del messaggio per la protezione reciproca del messaggio e dell'autenticazione.
Entrambe. Permette di specificare le impostazioni per la sicurezza del trasporto e a livello di messaggio (supportata solo in MSMQ).
TransportWithMessageCredential. Le credenziali vengono passate con il messaggio. La protezione dei messaggi e l'autenticazione server sono garantite dal livello di trasporto.
TransportCredentialOnly. Le credenziali del client vengono passate con il livello di trasporto e non viene applicata alcuna protezione al messaggio. Usare la sicurezza del messaggio e del trasporto per proteggere l'integrità e riservatezza dei messaggi. La configurazione seguente indica al servizio di usare la sicurezza del trasporto con le credenziali del messaggio.