Infrastruttura di sicurezza: dati sensibili - Procedure di mitigazione

Prodotto o servizio Articolo
Limite di trust dei computer
Applicazione Web
Database
API Web
Azure DocumentDB
Limite di trust della macchina virtuale IaaS di Azure
Limite di trust di Service Fabric
Dynamics CRM
Archiviazione di Azure
Client per dispositivi mobili
WCF

Assicurarsi che i file binari che contengono informazioni riservate vengano offuscati

Titolo Dettagli
Componente Limite di trust dei computer
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 Crypto Obfuscator.

Valutare l'uso della tecnologia EFS (Encrypting File System) per proteggere dati riservati specifici dell'utente

Titolo Dettagli
Componente Limite di trust dei computer
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 dei computer
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 Compilare
Tecnologie applicabili Generico, Web Form, MVC 5, MVC 6
Attributi N/D
Riferimenti N/D
Passi 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 vengono visualizzate informazioni riservate, come l'indirizzo dell'utente, i dati della carta di credito, il codice fiscale o il nome utente, tali informazioni possono essere memorizzate nella cache del browser e quindi recuperate 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.

Esempio

<configuration>
  <system.webServer>
   <httpProtocol>
    <customHeaders>
        <add name="Cache-Control" value="no-cache" />
        <add name="Pragma" value="no-cache" />
        <add name="Expires" value="-1" />
    </customHeaders>
  </httpProtocol>
 </system.webServer>
</configuration>

Esempio

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

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI (Procedura: Crittografare le sezioni di configurazione in ASP.NET 2.0 usando DPAPI), Specifica di un provider di configurazione protetta, Using Azure Key Vault to protect application secrets (Uso di Azure Key Vault per proteggere i segreti dell'applicazione)
Passi 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

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti MSDN: autocomplete attribute (Attributo autocomplete), Using AutoComplete in HTML Forms (Uso di AutoComplete nei form HTML), Vulnerabilità legata alla disinfezione del contenuto HTML, Autocomplete...again?! (Ancora autocomplete?)
Passi 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.

Esempio

<form action="Login.aspx" method="post " autocomplete="off" >
      Social Security Number: <input type="text" name="ssn" />
      <input type="submit" value="Submit" />    
</form>

Assicurarsi che i dati sensibili visualizzati nella schermata dell'utente vengano mascherati

Titolo Dettagli
Componente Applicazione Web.
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 avvenire sia quando vengono accettati come input, ad esempio input type="password", sia quando vengono visualizzati nuovamente sullo schermo, ad esempio mostrando 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

Titolo Dettagli
Componente Database
Fase SDL Compilare
Tecnologie applicabili SQL Azure, locale
Attributi Versione SQL: 12, versione SQL: MSSQL2016
Riferimenti Maschera dati dinamica
Passi Lo scopo della maschera dati dinamica è limitare l'esposizione dei dati sensibili, impedendone la visualizzazione da parte di utenti che non dovrebbero avervi accesso. La maschera dati dinamica non impedisce agli utenti di database di connettersi direttamente al database ed eseguire query complete che espongono parti di 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

Titolo Dettagli
Componente Database
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Hash delle password con le API di crittografia di .NET
Passi 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 bcrypt, scrypt 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

Titolo Dettagli
Componente Database
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Versione SQL: tutte
Riferimenti Crittografia di dati sensibili in SQL Server, Procedura: Crittografare una colonna di dati in SQL Server, Crittografare con un certificato
Passi 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)

Titolo Dettagli
Componente Database
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Informazioni su Transparent Data Encryption (TDE) in SQL Server
Passi 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 protegge i dati inattivi, ovvero i file di dati e di log. Offre inoltre la possibilità di conformarsi a diverse leggi, normative e linee guida stabilite in vari settori.

Assicurarsi che i backup di database vengano crittografati

Titolo Dettagli
Componente Database
Fase SDL Compilare
Tecnologie applicabili SQL Azure, locale
Attributi Versione SQL: 12, versione SQL: MSSQL2014
Riferimenti Crittografia dei backup del database SQL
Passi 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 Compilare
Tecnologie applicabili MVC 5, MVC 6
Attributi Provider di identità: AD FS, provider di identità: Azure AD
Riferimenti N/D
Passi

In alcune implementazioni, gli elementi sensibili relativi all'autenticazione dell'API Web vengono memorizzati nell'archivio locale del browser. Si tratta, ad esempio, di elementi di autenticazione di Azure AD 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 le 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 Cosmos DB

Titolo Dettagli
Componente Azure DocumentDB
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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
Fase SDL Distribuzione
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Uso di Crittografia dischi di Azure per crittografare i dischi usati dalle macchine virtuali
Passi

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

Titolo Dettagli
Componente Limite di trust di Service Fabric
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Ambiente: Azure
Riferimenti Gestione dei segreti nelle applicazioni di Service Fabric
Passi 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 Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti N/D
Passi 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 Generico
Attributi N/D
Riferimenti N/D
Passi 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 Generico
Attributi N/D
Riferimenti N/D
Passi 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 Generico
Attributi N/D
Riferimenti N/D
Passi 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)

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi Tipo di archiviazione: BLOB
Riferimenti Crittografia del servizio di archiviazione di Azure per dati inattivi (anteprima)
Passi

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 relative chiavi di crittografia e verrà fornito 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

Titolo Dettagli
Componente Archiviazione di Azure
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Crittografia lato client e Azure Key Vault per Archiviazione di Microsoft Azure, Esercitazione: Crittografare e decrittografare i BLOB in Archiviazione di Microsoft Azure tramite Azure Key Vault, Storing Data Securely in Azure Blob Storage with Azure Encryption Extensions (Archiviazione protetta dei dati nell'archivio BLOB di Azure con le estensioni di crittografia di Azure)
Passi

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 KEK è 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 nell'insieme di credenziali delle chiavi di Azure. 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

Titolo Dettagli
Componente Client per dispositivi mobili
Fase SDL Compilare
Tecnologie applicabili Generico, Xamarin
Attributi N/D
Riferimenti Gestire impostazioni e funzionalità nei dispositivi con i criteri di Microsoft Intune, Keychain Valet
Passi

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

Titolo Dettagli
Componente Client per dispositivi mobili
Fase SDL Compilare
Tecnologie applicabili Generico
Attributi N/D
Riferimenti Crypto Obfuscator For .Net
Passi È 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, è possano utilizzare strumenti come Crypto Obfuscator.

Impostare clientCredentialType su Certificate o su Windows

Titolo Dettagli
Componente WCF
Fase SDL Compilare
Tecnologie applicabili .NET Framework 3
Attributi N/D
Riferimenti Fortify
Passi 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:

<security mode="Message"> 
<message clientCredentialType="UserName" />

Impostare clientCredentialType su Certificate o su Windows.

WCF: la modalità di sicurezza non è abilitata

Titolo Dettagli
Componente WCF
Fase SDL Compilare
Tecnologie applicabili Generico, .NET Framework 3
Attributi Modalità di sicurezza: trasporto, modalità di sicurezza: messaggio
Riferimenti MSDN, Fortify Kingdom, CoDe Magazine: Fundamentals of WCF Security (Concetti fondamentali sulla sicurezza in WCF)
Passi 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.

<system.serviceModel> 
  <bindings> 
    <wsHttpBinding> 
      <binding name=""MyBinding""> 
        <security mode=""None""/> 
      </binding> 
  </bindings> 
</system.serviceModel> 

Esempio

Le associazioni ai servizi presentano cinque modalità di sicurezza possibili:

  • None. Disabilita la sicurezza.
  • Transport. Usa la sicurezza del trasporto per la protezione reciproca del messaggio e dell'autenticazione.
  • Message. Usa la sicurezza del messaggio per la protezione reciproca del messaggio e dell'autenticazione.
  • Both. 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. <system.serviceModel> <bindings> <wsHttpBinding> <binding name=""MyBinding""> <security mode=""TransportWithMessageCredential""/> <message clientCredentialType=""Windows""/> </binding> </bindings> </system.serviceModel>