Infrastruttura di sicurezza: gestione della configurazione - Procedure di mitigazione
Implementare i criteri di sicurezza del contenuto (CSP) e disabilitare JavaScript inline
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | Introduzione ai criteri di sicurezza dei contenuti, Informazioni di riferimento sui criteri di sicurezza dei contenuti, Introduzione ai criteri di sicurezza dei contenuti, È possibile usare CSP? |
| Passaggi | Content Security Policy (CSP) è un meccanismo di sicurezza avanzato, uno standard W3C, che consente ai proprietari di applicazioni Web di avere il controllo del contenuto incorporato nel sito. CSP viene aggiunto come intestazione della risposta HTTP nel server Web e viene applicato sul lato client dai browser. Si tratta di un criterio basato su elenco consentito: un sito Web può dichiarare un set di domini attendibili da cui è possibile caricare contenuto attivo, ad esempio JavaScript. CSP offre i seguenti vantaggi per la sicurezza:
|
Esempio
Criteri di esempio:
Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com
Questi criteri consentono il caricamento degli script solo dal server dell'applicazione Web e dal server Google Analytics. Gli script caricati da altri siti verranno rifiutati. Quando CSP viene abilitato in un sito Web, le funzionalità seguenti vengono automaticamente disabilitate per mitigare gli attacchi XSS.
Esempio
Gli script inline non verranno eseguiti. Di seguito sono riportati esempi di script inline.
<script> some JavaScript code </script>
Event handling attributes of HTML tags (for example, <button onclick="function(){}">
javascript:alert(1);
Esempio
Le stringhe non verranno valutate come codice.
Example: var str="alert(1)"; eval(str);
Abilitare il filtro XSS del browser
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | XSS Protection Filter (Filtro di protezione XSS) |
| Passaggi | La configurazione dell'intestazione della risposta X-XSS-Protection controlla il filtro di cross-site scripting del browser. Questa intestazione della risposta può avere i valori seguenti:
Si tratta di una funzione di Chromium che utilizza i report sulle violazioni CSP per inviare i dettagli all'URI scelto. Le ultime due opzioni sono considerate valori sicuri. |
Le applicazioni ASP.NET devono disabilitare la traccia e il debug prima della distribuzione
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | Panoramica del debug di ASP.NET, Panoramica dell'analisi di ASP.NET, Procedura: Abilitare l'analisi per un'applicazione ASP.NET, Procedura: Abilitare il debug per applicazioni ASP.NET |
| Passaggi | Quando l'analisi viene abilitata per la pagina, ogni browser che la richiede ottiene anche le informazioni di analisi contenenti i dati sul flusso di lavoro e sullo stato del server interno. Tali informazioni possono essere relative alla sicurezza. Quando il debug viene abilitato per la pagina, gli errori che si verificano sul server restituiscono dati di analisi dello stack completa presentati al browser. Tali dati possono esporre informazioni relative alla sicurezza sul flusso di lavoro del server. |
Accedere solo a JavaScript di terze parti da origini attendibili
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | È consigliabile fare riferimento a JavaScript di terze parti solo da origini attendibili. Gli endpoint di riferimento devono sempre essere in TLS. |
Assicurarsi che le pagine ASP.NET autenticate incorporino difese contro attacchi di tipo UI redress o click-jacking
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | OWASP Click-Jacking Defense Cheat Sheet, Internet Explorer Internals - Lotta contro il click-jacking con X-Frame-Options |
| Passaggi | Il click-jacking, noto anche come "attacco di correzione dell'interfaccia utente", è quando un utente malintenzionato usa più livelli trasparenti o opachi per ingannare un utente a fare clic su un pulsante o un collegamento in un'altra pagina quando intendevano fare clic sulla pagina di primo livello. Questa sovrapposizione si ottiene creando una pagina dannosa con un iframe, che carica la pagina della vittima. L'utente malintenzionato assume quindi il controllo dei clic destinati alla pagina e li instrada a un'altra pagina, quasi certamente di proprietà di un'altra applicazione o dominio oppure di entrambi. Per impedire gli attacchi di tipo click-jacking, impostare le intestazioni della risposta HTTP X-Frame-Options appropriate che indicano al browser di non consentire l'inserimento in frame da altri domini |
Esempio
L'intestazione X-FRAME-OPTIONS può essere impostata tramite IIS web.config. Frammento di codice Web.config per i siti che non devono mai essere framed:
<system.webServer>
<httpProtocol>
<customHeader>
<add name="X-FRAME-OPTIONS" value="DENY"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Esempio
Codice di Web.config per siti che devono essere inseriti in un frame solo dalle pagine nello stesso dominio:
<system.webServer>
<httpProtocol>
<customHeader>
<add name="X-FRAME-OPTIONS" value="SAMEORIGIN"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato nelle applicazioni Web ASP.NET
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Web Form, MVC 5 |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | La sicurezza del browser impedisce a una pagina Web di creare richieste AJAX per un altro dominio. Questa restrizione è nota come criteri di corrispondenza dell'origine e impedisce a un sito dannoso di leggere dati sensibili da un altro sito. In alcuni casi può tuttavia essere necessario esporre in modo sicuro le API che gli altri siti possono utilizzare. Cross Origin Resource Sharing (CORS) è uno standard W3C che consente a un server di ridurre i criteri di corrispondenza dell'origine. Con CORS un server può consentire in modo esplicito alcune richieste multiorigine e rifiutarne altre. CORS è più sicuro e flessibile delle tecniche precedenti, ad esempio JSONP. In sostanza, abilitando CORS sarà possibile aggiungere alcune intestazioni della risposta HTTP (Access-Control-*) all'applicazione Web in due modi. |
Esempio
Se è disponibile l'accesso a Web.config, CORS può essere aggiunto tramite il codice seguente:
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="Access-Control-Allow-Origin" value="https://example.com" />
</customHeaders>
</httpProtocol>
Esempio
Se l'accesso a web.config non è disponibile, è possibile configurare CORS aggiungendo il codice C# seguente:
HttpContext.Response.AppendHeader("Access-Control-Allow-Origin", "https://example.com")
Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo "Access-Control-Allow-Origin" sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consente ai siti dannosi di attivare richieste tra le origini all'applicazione >Web senza restrizioni, rendendo l'applicazione vulnerabile agli attacchi CSRF.
Abilitare l'attributo ValidateRequest nelle pagine ASP.NET
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Web Form, MVC 5 |
| Attributi | N/D |
| Riferimenti | Request Validation - Preventing Script Attacks (Convalida della richiesta: prevenzione degli attacchi basati su script) |
| Passaggi | Convalida della richiesta, una caratteristica di ASP.NET dalla versione 1.1, impedisce al server di accettare contenuti contenenti HTML non codificato. Questa funzionalità è progettata per aiutare ad evitare alcuni attacchi intrusivi di script in base ai quali il codice di script client o HTML può essere inconsapevolmente inviato a un server, archiviato e quindi presentato ad altri utenti. Raccomandiamo ancora vivamente di convalidare tutti i dati di input e di codificarli HTML quando appropriato. La convalida della richiesta viene eseguita confrontando tutti i dati di input con un elenco di valori potenzialmente pericolosi. Se viene rilevata una corrispondenza, ASP.NET genera |
Esempio
Questa funzionalità può essere tuttavia disabilitata a livello di pagina:
<%@ Page validateRequest="false" %>
o a livello di applicazione.
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
Si noti che la funzionalità di convalida delle richieste non è supportata e non fa parte della pipeline MVC6.
Usare le versioni più recenti ospitate in locale delle librerie JavaScript
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Gli sviluppatori che usano librerie JavaScript standard, ad esempio JQuery, devono usare versioni approvate delle comuni librerie JavaScript che non contengono difetti di sicurezza noti. È consigliabile usare la versione più recente delle librerie, perché contiene aggiornamenti della sicurezza per le vulnerabilità note delle versioni precedenti. Se la versione più recente non può essere usata per motivi di compatibilità, è consigliabile usare la versione inferiore a quella minima. Versioni minime accettabili:
Non caricare mai librerie JavaScript da siti esterni, ad esempio reti CDN pubbliche. |
Disabilitare l'analisi MIME automatica
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | IE8 Security Part V: Comprehensive Protection (Sicurezza di IE8 parte V: protezione completa), MIME type (Tipo MIME) |
| Passaggi | L'intestazione X-Content-Type-Options è un'intestazione HTTP che consente agli sviluppatori di specificare che il contenuto non deve essere sottoposto ad analisi MIME. Questa intestazione è progettata per mitigare gli attacchi basati sull'analisi MIME. Per ogni pagina che potrebbe includere contenuti controllabili dall'utente, è necessario usare l'intestazione HTTP X-Content-Type-Options:nosniff. Per abilitare l'intestazione necessaria a livello globale per tutte le pagine nell'applicazione, eseguire una di queste operazioni. |
Esempio
Aggiungere l'intestazione nel file web.config se l'applicazione è ospitata da Internet Information Services (IIS) 7 o versione successiva.
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Esempio
Aggiungere l'intestazione tramite il Application_BeginRequest globale
void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers["X-Content-Type-Options"] = "nosniff";
}
Esempio
Implementare un modulo HTTP personalizzato
public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
return;
if (application.Response.Headers["X-Content-Type-Options "] != null)
return;
application.Response.Headers.Add("X-Content-Type-Options ", "nosniff");
}
}
Esempio
È possibile abilitare l'intestazione necessaria solo per pagine specifiche aggiungendola a singole risposte:
this.Response.Headers["X-Content-Type-Options"] = "nosniff";
Rimuovere le intestazioni del server standard nei siti Web di Microsoft Azure per evitare la creazione di impronte digitali
| Titolo | Dettagli |
|---|---|
| Componente | Applicazione Web |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | Tipo di ambiente: Azure |
| Riferimenti | Removing standard server headers on Windows Azure Web Sites (Rimozione di intestazioni del server standard nei siti Web di Microsoft Azure) |
| Passaggi | Intestazioni come Server, X-Powered-By e X-AspNet-Version rivelano informazioni sul server e sulle tecnologie sottostanti. È consigliabile eliminare queste intestazioni evitando così di creare impronte digitali dell'applicazione |
Configurare Windows Firewall per l'accesso al motore di database
| Titolo | Dettagli |
|---|---|
| Componente | Database |
| Fase SDL | Build |
| Tecnologie applicabili | SQL Azure, locale |
| Attributi | N/D, versione SQL: V12 |
| Riferimenti | Come configurare un firewall database SQL di Azure, Configurare Windows Firewall per l'accesso motore di database |
| Passaggi | I sistemi firewall consentono di impedire l'accesso non autorizzato alle risorse del computer. Per accedere a un'istanza del motore di database di SQL Server tramite un firewall, è necessario configurare il firewall sul computer che esegue SQL Server per consentire l'accesso. |
Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato nell'API Web ASP.NET
| Titolo | Dettagli |
|---|---|
| Componente | API Web |
| Fase SDL | Build |
| Tecnologie applicabili | MVC 5 |
| Attributi | N/D |
| Riferimenti | Enabling Cross-Origin Requests in ASP.NET Web API 2 (Abilitazione di richieste multiorigine nell'API Web ASP.NET 2), API Web ASP.NET: supporto di CORS nell'API Web ASP.NET 2 |
| Passaggi | La sicurezza del browser impedisce a una pagina Web di creare richieste AJAX per un altro dominio. Questa restrizione è nota come criteri di corrispondenza dell'origine e impedisce a un sito dannoso di leggere dati sensibili da un altro sito. In alcuni casi può tuttavia essere necessario esporre in modo sicuro le API che gli altri siti possono utilizzare. Cross Origin Resource Sharing (CORS) è uno standard W3C che consente a un server di ridurre i criteri di corrispondenza dell'origine. Con CORS un server può consentire in modo esplicito alcune richieste multiorigine e rifiutarne altre. CORS è più sicuro e flessibile delle tecniche precedenti, ad esempio JSONP. |
Esempio
In App_Start/WebApiConfig.cs aggiungere il codice seguente al metodo WebApiConfig.Register.
using System.Web.Http;
namespace WebService
{
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// New code
config.EnableCors();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
}
}
}
Esempio
L'attributo EnableCors può essere applicato ai metodi di azione in un controller, come segue:
public class ResourcesController : ApiController
{
[EnableCors("http://localhost:55912", // Origin
null, // Request headers
"GET", // HTTP methods
"bar", // Response headers
SupportsCredentials=true // Allow credentials
)]
public HttpResponseMessage Get(int id)
{
var resp = Request.CreateResponse(HttpStatusCode.NoContent);
resp.Headers.Add("bar", "a bar value");
return resp;
}
[EnableCors("http://localhost:55912", // Origin
"Accept, Origin, Content-Type", // Request headers
"PUT", // HTTP methods
PreflightMaxAge=600 // Preflight cache duration
)]
public HttpResponseMessage Put(Resource data)
{
return Request.CreateResponse(HttpStatusCode.OK, data);
}
[EnableCors("http://localhost:55912", // Origin
"Accept, Origin, Content-Type", // Request headers
"POST", // HTTP methods
PreflightMaxAge=600 // Preflight cache duration
)]
public HttpResponseMessage Post(Resource data)
{
return Request.CreateResponse(HttpStatusCode.OK, data);
}
}
Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo EnableCors sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consentirà ai siti dannosi di attivare richieste tra le origini all'API senza restrizioni, >rendendo quindi l'API vulnerabile agli attacchi CSRF. EnableCors può essere decorato a livello di controller.
Esempio
Per disabilitare CORS in un determinato metodo di una classe, l'attributo DisableCors può essere usato come illustrato sotto:
[EnableCors("https://example.com", "Accept, Origin, Content-Type", "POST")]
public class ResourcesController : ApiController
{
public HttpResponseMessage Put(Resource data)
{
return Request.CreateResponse(HttpStatusCode.OK, data);
}
public HttpResponseMessage Post(Resource data)
{
return Request.CreateResponse(HttpStatusCode.OK, data);
}
// CORS not allowed because of the [DisableCors] attribute
[DisableCors]
public HttpResponseMessage Delete(int id)
{
return Request.CreateResponse(HttpStatusCode.NoContent);
}
}
| Titolo | Dettagli |
|---|---|
| Componente | API Web |
| Fase SDL | Build |
| Tecnologie applicabili | MVC 6 |
| Attributi | N/D |
| Riferimenti | Enabling Cross-Origin Requests (CORS) in ASP.NET Core 1.0 (Abilitazione di richieste multiorigine (CORS) in ASP.NET Core 1.0) |
| Passaggi | In ASP.NET Core 1.0 CORS può essere abilitato usando il middleware o MVC. Quando si usa MVC per abilitare CORS, vengono usati gli stessi servizi CORS, ma non il middleware CORS. |
Approccio 1 Abilitazione di CORS con il middleware: per abilitare CORS per l'intera applicazione, aggiungere il middleware CORS alla pipeline di richieste usando il metodo di estensione UseCors. Si possono specificare criteri multiorigine quando si aggiunge il middleware CORS usando la classe CorsPolicyBuilder. A questo scopo è possibile procedere in due modi:
Esempio
Il primo consiste nel chiamare UseCors con un operatore lambda. L'operatore lambda accetta un oggetto CorsPolicyBuilder:
public void Configure(IApplicationBuilder app)
{
app.UseCors(builder =>
builder.WithOrigins("https://example.com")
.WithMethods("GET", "POST", "HEAD")
.WithHeaders("accept", "content-type", "origin", "x-custom-header"));
}
Esempio
Il secondo consiste nel definire uno più criteri CORS denominati e quindi nel selezionare i criteri per nome in fase di esecuzione.
public void ConfigureServices(IServiceCollection services)
{
services.AddCors(options =>
{
options.AddPolicy("AllowSpecificOrigin",
builder => builder.WithOrigins("https://example.com"));
});
}
public void Configure(IApplicationBuilder app)
{
app.UseCors("AllowSpecificOrigin");
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
});
}
Approccio 2 Abilitazione di CORS in MVC: in alternativa gli sviluppatori possono usare MVC per applicare CORS specifici per azione, per controller o a livello globale per tutti i controller.
Esempio
Per azione: per specificare un criterio CORS per un'azione specifica, aggiungere l'attributo [EnableCors] all'azione. Specificare il nome del criterio.
public class HomeController : Controller
{
[EnableCors("AllowSpecificOrigin")]
public IActionResult Index()
{
return View();
}
Esempio
Per controller:
[EnableCors("AllowSpecificOrigin")]
public class HomeController : Controller
{
Esempio
A livello globale:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<MvcOptions>(options =>
{
options.Filters.Add(new CorsAuthorizationFilterFactory("AllowSpecificOrigin"));
});
}
Si noti che è fondamentale assicurarsi che l'elenco di origini nell'attributo EnableCors sia impostato su un set finito e attendibile di origini. Se non si configura questa impostazione in modo inappropriato (ad esempio, l'impostazione del valore come "*") consentirà ai siti dannosi di attivare richieste tra le origini all'API senza restrizioni, >rendendo quindi l'API vulnerabile agli attacchi CSRF.
Esempio
Per disabilitare CORS per un controller o un'azione, usare l'attributo [DisableCors].
[DisableCors]
public IActionResult About()
{
return View();
}
Crittografare le sezioni dei file di configurazione dell'API Web contenenti dati sensibili
| Titolo | Dettagli |
|---|---|
| Componente | API Web |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| 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) |
| Passaggi | 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. |
Assicurarsi che tutte le interfacce amministrative siano protette con credenziali sicure
| Titolo | Dettagli |
|---|---|
| Componente | Dispositivo IoT |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Tutte le interfacce amministrative esposte dal dispositivo o dal gateway sul campo devono essere protette con credenziali sicure. Anche tutte le altre interfacce esposte, ad esempio WiFi, SSH, condivisioni file e FTP, devono essere protette con credenziali sicure. Non si devono usare le password vulnerabili predefinite. |
Assicurarsi che un codice sconosciuto non possa essere eseguito sui dispositivi
| Titolo | Dettagli |
|---|---|
| Componente | Dispositivo IoT |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | Enabling Secure Boot and BitLocker Device Encryption on Windows 10 IoT Core (Abilitazione dell'avvio protetto e della crittografia dispositivo BitLocker in Windows 10 IoT Core) |
| Passaggi | L'avvio protetto UEFI limita il sistema consentendo solo l'esecuzione di file binari firmati da un'autorità specificata. Questa funzionalità impedisce l'esecuzione di codice sconosciuto sulla piattaforma e il potenziale indebolimento del comportamento di sicurezza. Abilitare l'avvio protetto UEFI e limitare l'elenco di autorità di certificazione considerate attendibili per la firma del codice. Firmare tutto il codice distribuito nel dispositivo usando una delle autorità attendibili. |
Crittografare il sistema operativo e altre partizioni del dispositivo IoT con BitLocker
| Titolo | Dettagli |
|---|---|
| Componente | Dispositivo IoT |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Windows 10 IoT Core implementa una versione lightweight della crittografia dispositivo BitLocker, che dipende fortemente dalla presenza di un modulo TPM nella piattaforma, incluso il protocollo preOS necessario in UEFI che esegue le misurazioni necessarie. Queste misurazioni preOS assicurano che il sistema operativo in un secondo momento abbia un record definitivo della modalità di avvio del sistema operativo. Crittografare le partizioni del sistema operativo usando BitLocker e qualsiasi altra partizione anche nel caso in cui archiviino dati sensibili. |
Assicurarsi che sui dispositivi siano abilitati solo servizi/funzionalità minime
| Titolo | Dettagli |
|---|---|
| Componente | Dispositivo IoT |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Non abilitare né disattivare funzionalità o servizi del sistema operativo non necessari per il funzionamento della soluzione. Ad esempio, se il dispositivo non richiede la distribuzione di un'interfaccia utente, installare Windows IoT Core in modalità headless. |
Crittografare il sistema operativo e altre partizioni del gateway sul campo IoT con BitLocker
| Titolo | Dettagli |
|---|---|
| Componente | Gateway IoT sul campo |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Windows 10 IoT Core implementa una versione lightweight della crittografia dispositivo BitLocker, che dipende fortemente dalla presenza di un modulo TPM nella piattaforma, incluso il protocollo preOS necessario in UEFI che esegue le misurazioni necessarie. Queste misurazioni preOS assicurano che il sistema operativo in un secondo momento abbia un record definitivo della modalità di avvio del sistema operativo. Crittografare le partizioni del sistema operativo usando BitLocker e qualsiasi altra partizione anche nel caso in cui archiviino dati sensibili. |
Assicurarsi che le credenziali di accesso predefinite del gateway sul campo vengano modificate durante l'installazione
| Titolo | Dettagli |
|---|---|
| Componente | Gateway IoT sul campo |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Assicurarsi che le credenziali di accesso predefinite del gateway sul campo vengano modificate durante l'installazione |
Assicurarsi che il gateway nel cloud implementi un processo per mantenere aggiornato il firmware dei dispositivi connessi
| Titolo | Dettagli |
|---|---|
| Componente | Gateway IoT cloud |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | Opzione gateway: Hub IoT di Azure |
| Riferimenti | hub IoT Gestione dispositivi Panoramica, Aggiornamento dei dispositivi per hub IoT di Azure esercitazione con l'immagine di riferimento Raspberry Pi 3 B+. |
| Passaggi | LWM2M è un protocollo di Open Mobile Alliance per la gestione dei dispositivi IoT. Gestione dei dispositivi dell'hub IoT di Azure consente di interagire con dispositivi fisici tramite processi del dispositivo. Assicurarsi che il gateway nel cloud implementi a processo per mantenere regolarmente aggiornati il dispositivo e gli altri dati di configurazione usando Gestione dei dispositivi dell'hub IoT di Azure. |
Assicurarsi che i dispositivi abbiano i controlli di sicurezza degli endpoint configurati in base ai criteri organizzativi
| Titolo | Dettagli |
|---|---|
| Componente | Limite di Trust del computer |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | N/D |
| Passaggi | Assicurarsi che i dispositivi dispongano di controlli di sicurezza end-point, ad esempio BitLocker per la crittografia a livello di disco, antivirus con firme aggiornate, firewall basato su host, aggiornamenti del sistema operativo, criteri di gruppo e così via, configurati in base ai criteri di sicurezza dell'organizzazione. |
Assicurare una gestione sicura delle chiavi di accesso alle risorse di archiviazione di Azure
| Titolo | Dettagli |
|---|---|
| Componente | Archiviazione di Azure |
| Fase SDL | Distribuzione |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | Guida alla sicurezza di Archiviazione di Azure: gestione delle chiavi dell'account di archiviazione |
| Passaggi | Archiviazione chiavi: è consigliabile archiviare le chiavi di accesso alle risorse di archiviazione di Azure in Azure Key Vault come segreto e fare in modo che le applicazioni recuperino la chiave dall'insieme di credenziali delle chiavi. È consigliabile per i motivi seguenti:
|
Assicurarsi che siano consentite solo origini attendibili se CORS è abilitato in Archiviazione di Azure
| Titolo | Dettagli |
|---|---|
| Componente | Archiviazione di Azure |
| Fase SDL | Build |
| Tecnologie applicabili | Generica |
| Attributi | N/D |
| Riferimenti | Supporto di CORS per i servizi di archiviazione di Azure |
| Passaggi | Archiviazione di Azure consente di abilitare CORS (Condivisione risorse tra le origini). Per ogni account di archiviazione è possibile specificare i domini che possono accedere alle risorse in tale account di archiviazione. Per impostazione predefinita, CORS è disabilitato in tutti i servizi. È possibile abilitare CORS con l'API REST o la libreria client di archiviazione per chiamare uno dei metodi che impostano i criteri del servizio. |
Abilitare la funzionalità di limitazione dei servizi di WCF
| Titolo | Dettagli |
|---|---|
| Componente | WCF |
| Fase SDL | Build |
| Tecnologie applicabili | .NET Framework 3 |
| Attributi | N/D |
| Riferimenti | MSDN, Fortify Kingdom |
| Passaggi | Se non si imposta un limite all'uso delle risorse di sistema, potrebbe verificarsi un problema di esaurimento risorse e infine di Denial of Service.
|
Esempio
Di seguito è riportato un esempio di configurazione con la funzionalità di limitazione abilitata:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Throttled">
<serviceThrottling maxConcurrentCalls="[YOUR SERVICE VALUE]" maxConcurrentSessions="[YOUR SERVICE VALUE]" maxConcurrentInstances="[YOUR SERVICE VALUE]" />
...
</system.serviceModel>
Diffusione di informazioni di WCF tramite i metadati
| Titolo | Dettagli |
|---|---|
| Componente | WCF |
| Fase SDL | Build |
| Tecnologie applicabili | .NET Framework 3 |
| Attributi | N/D |
| Riferimenti | MSDN, Fortify Kingdom |
| Passaggi | I metadati possono consentire agli utenti malintenzionati di ottenere informazioni sul sistema e di pianificare un attacco. I servizi WCF possono essere configurati per esporre i metadati. I metadati offrono informazioni dettagliate sui servizi e non devono essere trasmessi negli ambienti di produzione. Le proprietà HttpGetEnabled / HttpsGetEnabled della classe ServiceMetaData definiscono se un servizio esporrà i metadati. |
Esempio
Il codice seguente indica a WCF di trasmettere i metadati di un servizio.
ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
smb.HttpGetUrl = new Uri(EndPointAddress);
Host.Description.Behaviors.Add(smb);
Non trasmettere i metadati del servizio in un ambiente di produzione. Impostare le proprietà HttpGetEnabled/HttpsGetEnabled della classe ServiceMetaData su false.
Esempio
Il codice seguente indica a WCF di non trasmettere i metadati di un servizio.
ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
smb.HttpGetEnabled = false;
smb.HttpGetUrl = new Uri(EndPointAddress);
Host.Description.Behaviors.Add(smb);