Infrastruttura di sicurezza: autenticazione - Procedure di mitigazione

Prodotto o servizio	Articolo
Applicazione Web	Valutare l'uso di un meccanismo di autenticazione standard per l'autenticazione nell'applicazione Web Gestire in modo sicuro scenari di autenticazione non riuscita mediante le applicazioni Abilitare l'autenticazione adattiva o incrementale Assicurarsi che le interfacce amministrative siano bloccate correttamente Implementare in modo sicuro funzionalità per la password dimenticata Assicurarsi che vengano implementati criteri di account e password Implementare controlli per prevenire l'enumerazione del nome utente
Database	Usare l'autenticazione di Windows per la connessione a SQL Server, se possibile Quando possibile, usare l'autenticazione di Microsoft Entra per Connessione per database SQL Assicurarsi che vengano applicati i criteri di account e password in SQL Server quando viene usata la modalità di autenticazione SQL Non usare l'autenticazione SQL nei database indipendenti
Hub eventi di Azure	Usare credenziali di autenticazione per dispositivo con i token di firma di accesso condiviso
Limite di trust di Azure	Abilitare l'autenticazione a più fattori Di Microsoft Entra per Azure Amministrazione istrators
Limite di trust di Service Fabric	Limitare l'accesso anonimo a un cluster di Service Fabric Assicurarsi che il certificato da client a nodo di Service Fabric sia diverso dal certificato da nodo a nodo Usare Microsoft Entra ID per autenticare i client nei cluster di Service Fabric Assicurarsi che i certificati di Service Fabric vengano ottenuti da un'Autorità di certificazione (CA) approvata
Identity Server	Usare scenari di autenticazione standard supportati da Identity Server Sostituire la cache dei token di Identity Server predefinita con un'alternativa scalabile
Limite di Trust del computer	Assicurarsi che i file binari dell'applicazione distribuita abbiano una firma digitale
WCF	Abilitare l'autenticazione nella connessione a code MSMQ in WCF WCF: non impostare il messaggio clientCredentialType su Nessuno WCF: non impostare il trasporto clientCredentialType su Nessuno
API Web	Assicurarsi che vengano usate tecniche di autenticazione standard per proteggere le API Web
Microsoft Entra ID	Usare scenari di autenticazione standard supportati da Microsoft Entra ID Eseguire l'override della cache dei token MSAL predefinita con una cache distribuita Assicurarsi che TokenReplayCache venga usato per impedire la riproduzione dei token di autenticazione in ingresso Usare le librerie MSAL per gestire le richieste di token dai client OAuth2 a Microsoft Entra ID (o AD locale)
Gateway IoT sul campo	Autenticare dispositivi che si connettono al gateway sul campo
Gateway IoT cloud	Assicurarsi che i dispositivi che si connettono al gateway cloud vengano autenticati Usare credenziali di autenticazione per dispositivo
Archiviazione di Azure	Assicurarsi che l'accesso in lettura anonimo venga concesso solo ai contenitori e ai BLOB necessari Concedere l'accesso limitato agli oggetti in Archiviazione di Azure tramite la firma di accesso condiviso o criteri di accesso archiviati

Valutare l'uso di un meccanismo di autenticazione standard per l'autenticazione nell'applicazione Web

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	L'autenticazione è il processo che permette a un'entità di dimostrare la propria identità, in genere mediante l'uso di credenziali, come un nome utente e una password. Sono disponibili più protocolli di autenticazione che potrebbero essere considerati. alcuni dei quali sono elencati di seguito: Certificati client Basato su Windows Basato su form Federazione: AD FS Federazione - Microsoft Entra ID Federazione: Identity Server Valutare l'uso di un meccanismo di autenticazione standard per identificare il processo di origine

Gestire in modo sicuro scenari di autenticazione non riuscita mediante le applicazioni

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	Le applicazioni che autenticano in modo esplicito gli utenti devono gestire in modo sicuro gli scenari di autenticazione non riusciti. Il meccanismo di autenticazione deve: Negare l'accesso alle risorse con privilegi quando l'autenticazione ha esito negativo. Visualizzare un messaggio di errore generico in caso di autenticazione non riuscita e accesso negato. Verificare quanto segue: Protezione delle risorse con privilegi dopo accessi non riusciti. Visualizzazione di un messaggio di errore generico in caso di autenticazione non riuscita e accesso negato. Disabilitazione degli account dopo un numero eccessivo di tentativi non riusciti.

Abilitare l'autenticazione adattiva o incrementale

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	Verificare che l'applicazione disponga di un'autorizzazione aggiuntiva, ad esempio l'autenticazione a più fattori, tramite l'autenticazione a più fattori, ad esempio l'invio di OTP in SMS, posta elettronica e così via, o la richiesta di riautenticazione, in modo che l'utente venga sottoposto a richiesta prima di concedere l'accesso alle informazioni riservate. Questa regola si applica anche alle modifiche importanti a un account o un'azione. Ciò significa che l'adattamento dell'autenticazione deve essere implementato in modo che venga applicata correttamente l'autorizzazione sensibile al contesto per impedire la manipolazione non autorizzata, ad esempio tramite la manomissione dei parametri.

Assicurarsi che le interfacce amministrative siano bloccate correttamente

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	La prima soluzione consiste nel concedere l'accesso all'interfaccia amministrativa solo da un determinato intervallo IP di origine. Se questa soluzione non sarebbe possibile, è sempre consigliabile applicare un'autenticazione passo-up o adattiva per l'accesso all'interfaccia amministrativa

Implementare in modo sicuro funzionalità per la password dimenticata

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	Verificare prima di tutto che la funzionalità Password dimenticata e altri percorsi di recupero inviino un collegamento con un token di attivazione di durata limitata, anziché la password stessa. Potrebbe essere necessaria una ulteriore autenticazione basata su token software, come token SMS, applicazioni mobili native e così via, prima dell'invio del collegamento. In secondo luogo, non è consigliabile bloccare l'account degli utenti mentre è in corso il processo di recupero di una nuova password. Questo potrebbe causare un attacco Denial of Service ogni volta che un utente malintenzionato decide di bloccare intenzionalmente gli utenti con un attacco automatizzato. Ogni volta che viene avviata la richiesta di una nuova password, il messaggio visualizzato deve essere generalizzato per impedire l'enumerazione del nome utente. Infine, occorre sempre impedire l'uso di password precedenti e implementare criteri di password complessi.

Assicurarsi che vengano implementati criteri di account e password

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Dettagli	È necessario implementare criteri di account e password in conformità con i criteri e le procedure consigliate dell'organizzazione. Per proteggersi da attacchi di forza bruta e attacchi a dizionario è necessario implementare criteri per password complesse, per fare in modo che gli utenti creino password complesse, ad esempio con una lunghezza minima di 12 caratteri o con caratteri speciali e alfanumerici. I criteri di blocco dell'account possono essere implementati nel modo seguente: Blocco temporaneo: questo tipo di blocco è utile per proteggere gli utenti da attacchi di forza bruta. Ad esempio, ogni volta che l'utente immette una password errata tre volte l'applicazione potrebbe bloccare l'account per un minuto per rallentare il processo di forzatura bruta della password, rendendola meno redditizia per l'autore dell'attacco. Se si dovesse implementare contromisure di blocco rigido per questo esempio, si otterrebbe un "DoS" bloccando definitivamente gli account. In alternativa, l'applicazione potrebbe generare un OTP (una password una tantum) e inviarlo fuori banda (tramite posta elettronica, SMS e così via) all'utente. Un altro approccio potrebbe consistere nell'implementare CAPTCHA dopo il raggiungimento di un numero soglia di tentativi non riusciti. Blocco rigido: questo tipo di blocco deve essere applicato ogni volta che si rileva un utente che attacca l'applicazione e li contrasta tramite il blocco permanente del proprio account fino a quando un team di risposta non ha avuto il tempo di eseguire le analisi forensi. Dopo questo processo, è possibile decidere di restituire all'utente il proprio account o intraprendere ulteriori azioni legali contro di loro. Questo tipo di approccio impedisce all'autore dell'attacco di penetrare ulteriormente nell'applicazione e nell'infrastruttura. Per difendersi da attacchi ad account prevedibili e predefiniti, verificare che tutte le chiavi e le password siano sostituibili e che vengano generate o sostituite dopo la fase di installazione. Se l'applicazione deve generare automaticamente le password, assicurarsi che le password generate siano casuali e abbiano un'entropia elevata.

Implementare controlli per prevenire l'enumerazione del nome utente

Title	Dettagli
Componente	Applicazione Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	È necessario generalizzare i messaggi di errore per prevenire l'enumerazione del nome utente. Inoltre, a volte non è possibile evitare la perdita di informazioni nelle funzionalità, ad esempio una pagina di registrazione. In tal caso è necessario usare metodi di limitazione della frequenza, ad esempio i CAPTCHA, per prevenite attacchi automatizzati da parte di utenti malintenzionati.

Usare l'autenticazione di Windows per la connessione a SQL Server, se possibile

Title	Dettagli
Componente	Database
Fase SDL	Compilazione
Tecnologie applicabili	Locale
Attributi	Versione SQL: tutte
Riferimenti	SQL Server: scegliere una modalità di autenticazione
Passaggi	L'autenticazione di Windows, per la quale viene utilizzato il protocollo di sicurezza Kerberos, garantisce l'applicazione dei criteri password mediante convalida della complessità delle password complesse, offre il supporto per il blocco dell'account e la scadenza delle password.

Quando possibile, usare l'autenticazione di Microsoft Entra per Connessione per database SQL

Title	Dettagli
Componente	Database
Fase SDL	Compilazione
Tecnologie applicabili	SQL Azure
Attributi	Versione SQL: 12
Riferimenti	Connessione di database SQL tramite l'autenticazione di Microsoft Entra
Passaggi	Versione minima: database SQL di Azure V12 necessaria per consentire database SQL di Azure di usare l'autenticazione di Microsoft Entra in Microsoft Directory

Assicurarsi che vengano applicati i criteri di account e password in SQL Server quando viene usata la modalità di autenticazione SQL

Title	Dettagli
Componente	Database
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Criteri password di SQL Server
Passaggi	Quando si usa l'autenticazione di SQL Server, in SQL Server vengono creati account di accesso che non sono basati su account utente di Windows. Sia il nome utente che la password vengono creati mediante SQL Server e archiviati in SQL Server. SQL Server può fare uso di meccanismi dei criteri password di Windows. Può applicare la stessa complessità e i criteri di scadenza di Windows alle password usate all'interno di SQL Server.

Non usare l'autenticazione SQL in database indipendenti

Title	Dettagli
Componente	Database
Fase SDL	Compilazione
Tecnologie applicabili	Sql Azure locale
Attributi	Versione SQL: MSSQL2012, versione SQL: 12
Riferimenti	Procedure di sicurezza consigliate con i database indipendenti
Passaggi	L'assenza di criteri password applicati potrebbe aumentare la probabilità che una credenziale debole venga stabilita in un database indipendente. Fare uso dell'autenticazione di Windows.

Usare credenziali di autenticazione per dispositivo con i token di firma di accesso condiviso

Title	Dettagli
Componente	Hub eventi di Azure
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Panoramica del modello di sicurezza e autenticazione di Hub eventi
Passaggi	Il modello di sicurezza di Hub eventi si basa su una combinazione di token di firma di accesso condiviso e autori di eventi. Il nome dell'autore rappresenta l'ID dispositivo che riceve il token. Questo permette di associare i token generati con i rispettivi dispositivi. Tutti i messaggi vengono contrassegnati con l'iniziatore sul lato del servizio, per consentire il rilevamento di tentativi di spoofing dell'origine nel payload. Durante l'autenticazione dei dispositivi, generare un token di firma di accesso condiviso per dispositivo con ambito limitato a un autore univoco.

Abilitare l'autenticazione a più fattori Di Microsoft Entra per Azure Amministrazione istrators

Title	Dettagli
Componente	Limite di trust di Azure
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Che cos'è l'autenticazione a più fattori Di Microsoft Entra?
Passaggi	L'autenticazione a più fattori (MFA) è un metodo di autenticazione che richiede più metodi di verifica e aggiunge un secondo livello critico di sicurezza agli accessi e alle transazioni degli utenti. In genere richiede due o più dei metodi di verifica seguenti: Un elemento noto (in genere, una password) Qualcosa che hai (un dispositivo attendibile che non è facilmente duplicato, come un telefono) Una caratteristica personale (biometria)

Limitare l'accesso anonimo a un cluster di Service Fabric

Title	Dettagli
Componente	Limite di trust di Service Fabric
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Ambiente: Azure
Riferimenti	Scenari di sicurezza di un cluster di Service Fabric
Passaggi	Per impedire a utenti non autorizzati di connettersi al cluster, è necessario proteggerlo, in particolare quando sono in esecuzione carichi di lavoro di produzione. Durante la creazione di un cluster di Service Fabric, assicurarsi che la modalità di sicurezza sia impostata su "secure" e configurare il certificato server X.509 necessario. La creazione di un cluster "insecure" permette a qualsiasi utente anonimo di connettersi al cluster, se questo espone gli endpoint di gestione a Internet pubblico.

Assicurarsi che il certificato da client a nodo di Service Fabric sia diverso dal certificato da nodo a nodo

Title	Dettagli
Componente	Limite di trust di Service Fabric
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Ambiente: Azure, ambiente: autonomo
Riferimenti	Sicurezza basata su certificati da client a nodo in Service Fabric, Connettersi a un cluster sicuro tramite il certificato client
Passaggi	La sicurezza basata su certificati da client a nodo viene configurata durante la creazione del cluster tramite il portale di Azure, modelli di Azure Resource Manager o un modello JSON autonomo specificando un certificato client di amministrazione e/o un certificato client di sola lettura. I certificati client di amministrazione e i certificati client utente specificati devono essere diversi dai certificati primario e secondario specificati per la sicurezza da nodo a nodo.

Usare Microsoft Entra ID per autenticare i client nei cluster di Service Fabric

Title	Dettagli
Componente	Limite di trust di Service Fabric
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Ambiente: Azure
Riferimenti	Scenari di sicurezza per i cluster: raccomandazioni sulla sicurezza
Passaggi	I cluster in esecuzione in Azure possono anche proteggere l'accesso agli endpoint di gestione usando l'ID Microsoft Entra, oltre ai certificati client. Per i cluster di Azure, è consigliabile usare la sicurezza Microsoft Entra per autenticare client e certificati per la sicurezza da nodo a nodo.

Assicurarsi che i certificati di Service Fabric vengano ottenuti da un'Autorità di certificazione (CA) approvata

Title	Dettagli
Componente	Limite di trust di Service Fabric
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	Ambiente: Azure
Riferimenti	Certificati X.509 e Service Fabric
Passaggi	Service Fabric usa i certificati server X.509 per l'autenticazione dei nodi e dei client. Aspetti importanti da considerare nell'uso dei certificati in Service Fabric: È consigliabile creare i certificati usati nei cluster che eseguono carichi di lavoro di produzione con un servizio certificati di Windows Server configurato correttamente oppure ottenerli da un'autorità di certificazione (CA) approvata. L'Autorità di certificazione può essere una CA esterna approvata o un'infrastruttura a chiave pubblica (PKI) a gestione interna. Non usare mai in fase di produzione certificati temporanei o di test creati con strumenti come MakeCert.exe. È possibile usare un certificato autofirmato, ma solo per i cluster di test e non nell'ambiente di produzione.

Usare scenari di autenticazione standard supportati da Identity Server

Title	Dettagli
Componente	Identity Server
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	IdentityServer3: quadro generale
Passaggi	Di seguito sono elencate le interazioni tipiche supportate da Identity Server: Comunicazione tra browser e applicazioni Web. Comunicazione tra applicazioni Web e API Web, talvolta in modo autonomo e talvolta per conto dell'utente. Comunicazione tra applicazioni basate su browser e API Web. Comunicazione tra applicazioni native e API Web. Comunicazione tra applicazioni basate su server e API Web. Comunicazione tra API Web e API Web, talvolta in modo autonomo e talvolta per conto dell'utente.

Sostituire la cache dei token di Identity Server predefinita con un'alternativa scalabile

Title	Dettagli
Componente	Identity Server
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Distribuzione di Identity Server: memorizzazione nella cache
Passaggi	IdentityServer ha una semplice cache in memoria predefinita. Tale cache è sufficiente per le applicazioni native su scala ridotta ma, per i motivi elencati di seguito, non può essere ridimensionata per le applicazioni back-end e di livello intermedio: Queste applicazioni sono accessibili da più utenti contemporaneamente. Il salvataggio di tutti i token di accesso nello stesso archivio crea problemi di isolamento e presenta difficoltà quando si opera su vasta scala. Un numero elevato di utenti, ognuno con un numero di token pari a quello delle risorse a cui l'app accede per suo conto, può far aumentare notevolmente la quantità e il costo delle operazioni di ricerca. Queste applicazioni vengono in genere distribuite in topologie distribuite, in cui più nodi devono avere accesso alla stessa cache. I token memorizzati nella cache devono resistere in caso di disattivazione e riciclo del processo. Per tutte queste ragioni, durante l'implementazione di app Web è consigliabile sostituire la cache dei token di Identity Server predefinita con un'alternativa scalabile, ad esempio Cache Redis di Azure

Assicurarsi che i file binari dell'applicazione distribuita abbiano una firma digitale

Title	Dettagli
Componente	Limite di Trust del computer
Fase SDL	Distribuzione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Assicurarsi che i file binari dell'applicazione distribuita abbiano una firma digitale, in modo che sia possibile verificare l'integrità dei file binari.

Abilitare l'autenticazione nella connessione a code MSMQ in WCF

Title	Dettagli
Componente	WCF
Fase SDL	Compilazione
Tecnologie applicabili	Generico, NET Framework 3
Attributi	N/D
Riferimenti	MSDN
Passaggi	Il programma non riesce ad abilitare l'autenticazione quando ci si connette a code MSMQ e un utente malintenzionato può inviare messaggi in modo anonimo alla coda per l'elaborazione. Se non si usa l'autenticazione per connettersi a una coda MSMQ usata per recapitare un messaggio a un altro programma, un utente malintenzionato potrebbe inviare un messaggio anonimo dannoso.

Esempio

L'elemento <netMsmqBinding/> del file di configurazione WCF seguente indica a WCF di disabilitare l'autenticazione quando ci si connette a una coda MSMQ per il recapito di messaggi.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

Configurare MSMQ perché venga sempre richiesta l'autenticazione del certificato o del dominio di Windows per qualsiasi messaggio in ingresso o in uscita.

Esempio

L'elemento <netMsmqBinding/> del file di configurazione WCF seguente indica a WCF di abilitare l'autenticazione quando ci si connette a una coda MSMQ. Il client viene autenticato tramite certificati X.509. Il certificato client deve essere presente nell'archivio certificati del server.

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

WCF: non impostare il messaggio clientCredentialType su Nessuno

Title	Dettagli
Componente	WCF
Fase SDL	Compilazione
Tecnologie applicabili	.NET Framework 3
Attributi	Tipo di credenziali client: nessuno
Riferimenti	MSDN, Fortify
Passaggi	L'assenza di autenticazione indica che tutti possono accedere a questo servizio. Un servizio che non esegue l'autenticazione dei client consente l'accesso a tutti gli utenti. Configurare l'applicazione per l'autenticazione con le credenziali del client. A tale scopo, è possibile impostare il messaggio clientCredentialType su Windows o su Certificate.

Esempio

<message clientCredentialType=""Certificate""/>

WCF: non impostare il trasporto clientCredentialType su Nessuno

Title	Dettagli
Componente	WCF
Fase SDL	Compilazione
Tecnologie applicabili	Generico, .NET Framework 3
Attributi	Tipo di credenziali client: nessuno
Riferimenti	MSDN, Fortify
Passaggi	L'assenza di autenticazione indica che tutti possono accedere a questo servizio. Un servizio che non esegue l'autenticazione dei client consente a tutti gli utenti di accedere alle funzionalità. Configurare l'applicazione per l'autenticazione con le credenziali del client. A tale scopo, è possibile impostare il trasporto clientCredentialType su Windows o su Certificate.

Esempio

<transport clientCredentialType=""Certificate""/>

Assicurarsi che vengano usate tecniche di autenticazione standard per proteggere le API Web

Title	Dettagli
Componente	API Web
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Autenticazione e autorizzazione nell'API Web ASP.NET, Servizi di autenticazione esterna con l'API Web ASP.NET (C#)
Passaggi	L'autenticazione è il processo che permette a un'entità di dimostrare la propria identità, in genere mediante l'uso di credenziali, come un nome utente e una password. Sono disponibili più protocolli di autenticazione che potrebbero essere considerati. alcuni dei quali sono elencati di seguito: Certificati client Basato su Windows Basato su form Federazione: AD FS Federazione - Microsoft Entra ID Federazione: Identity Server I collegamenti riportati nella sezione dei riferimenti permettono di ottenere informazioni dettagliate su come implementare ognuno degli schemi di autenticazione per proteggere un'API Web.

Usare scenari di autenticazione standard supportati da Microsoft Entra ID

Title	Dettagli
Componente	Microsoft Entra ID
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Scenari di autenticazione per Microsoft Entra ID, esempi di codice di Microsoft Entra, guida per gli sviluppatori di Microsoft Entra
Passaggi	Microsoft Entra ID semplifica l'autenticazione per gli sviluppatori fornendo identità come servizio, con il supporto per protocolli standard del settore, ad esempio OAuth 2.0 e OpenID Connessione. Di seguito sono riportati i cinque scenari principali dell'applicazione supportati da Microsoft Entra ID: Da Web browser a applicazione Web: un utente deve accedere a un'applicazione Web protetta da Microsoft Entra ID Applicazione a pagina singola (SPA): un utente deve accedere a un'applicazione a pagina singola protetta da Microsoft Entra ID Applicazione nativa all'API Web: un'applicazione nativa eseguita su un telefono, un tablet o un PC deve autenticare un utente per ottenere risorse da un'API Web protetta da Microsoft Entra ID Applicazione Web all'API Web: un'applicazione Web deve ottenere risorse da un'API Web protetta da Microsoft Entra ID Daemon o applicazione server all'API Web: un'applicazione daemon o un'applicazione server senza interfaccia utente Web deve ottenere risorse da un'API Web protetta da Microsoft Entra ID Per informazioni dettagliate sull'implementazione, vedere i collegamenti riportati nella sezione dei riferimenti.

Eseguire l'override della cache dei token MSAL predefinita con una cache distribuita

Title	Dettagli
Componente	Microsoft Entra ID
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Serializzazione della cache dei token in MSAL.NET
Passaggi	La cache predefinita usata da MSAL (Microsoft Authentication Library) è una cache in memoria ed è scalabile. Esistono tuttavia opzioni diverse che è possibile usare come alternativa, ad esempio una cache di token distribuita. Questi hanno meccanismi L1/L2, dove L1 è in memoria e L2 è l'implementazione della cache distribuita. Questi possono essere configurati di conseguenza per limitare la memoria L1, crittografare o impostare criteri di rimozione. Altre alternative includono Cache Redis, SQL Server o Azure Comsos DB. Un'implementazione di una cache di token distribuita è disponibile nell'esercitazione seguente : Introduzione a ASP.NET Core MVC.

Assicurarsi che TokenReplayCache venga usato per impedire la riproduzione dei token di autenticazione MSAL

Title	Dettagli
Componente	Microsoft Entra ID
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Autenticazione moderna con Microsoft Entra ID per applicazioni Web
Passaggi	La proprietà TokenReplayCache consente agli sviluppatori di definire una cache di riproduzione dei token, ovvero un archivio in cui salvare i token allo scopo di verificare che nessun token venga usato più di una volta. Si tratta di una misura adatta a un tipo di attacco comune, detto attacco di riproduzione dei token, in cui un utente malintenzionato che intercetta il token inviato al momento dell'accesso potrebbe provare a inviarlo nuovamente all'app, ovvero "riprodurlo", per stabilire una nuova sessione. Ad esempio, nel flusso di concessione del codice OIDC dopo l'autenticazione dell'utente viene inviata una richiesta all'endpoint "/signin-oidc" della relying party con i parametri "id_token", "code" e "state". La relying party convalida la richiesta e stabilisce una nuova sessione. Se un antagonista acquisisce questa richiesta e la riproduce, può stabilire una sessione ed effettuare lo spoofing dell'utente. La presenza del parametro nonce in OpenID Connect può limitare, ma non eliminare del tutto, le circostanze che permettono di mettere in atto l'attacco. Per proteggere le applicazioni, gli sviluppatori possono fornire un'implementazione di ITokenReplayCache e assegnare un'istanza a TokenReplayCache.

Esempio

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

Esempio

Di seguito è riportato un esempio di implementazione dell'interfaccia ITokenReplayCache. Personalizzare l'esempio e implementare il framework di memorizzazione nella cache specifico del progetto.

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

Le opzioni OIDC devono fare riferimento alla cache implementata tramite la proprietà "TokenValidationParameters", come indicato di seguito.

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

Si noti che per testare l'efficacia di questa configurazione, accedere all'applicazione locale protetta da OIDC e acquisire la richiesta all'endpoint "/signin-oidc" in fiddler. In assenza di protezione, la riproduzione di questa richiesta in Fiddler imposta un nuovo cookie di sessione. Quando la richiesta viene riprodotta dopo aver aggiunto la protezione TokenReplayCache, l'applicazione genera un'eccezione simile alla seguente: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

Usare le librerie MSAL per gestire le richieste di token dai client OAuth2 a Microsoft Entra ID (o AD locale)

Title	Dettagli
Componente	Microsoft Entra ID
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	MSAL
Passaggi	Microsoft Authentication Library (MSAL) consente agli sviluppatori di acquisire i token di sicurezza da Microsoft Identity Platform per autenticare gli utenti e accedere ad API Web protette. MSAL può essere usata per assicurare un accesso sicuro a Microsoft Graph, ad altre API Microsoft, ad API Web di terze parti o ad API Web. MSAL supporta molte architetture e piattaforme per applicazioni diverse, tra cui .NET, JavaScript, Java, Python, Android e iOS.

MSAL offre molti modi per acquisire i token, con un'API coerente per molte piattaforme. Non è necessario usare direttamente le librerie OAuth o il codice sul protocollo nell'applicazione e può acquisire token per conto di un utente o di un'applicazione (se applicabile alla piattaforma).

MSAL gestisce anche una cache dei token e aggiorna i token quando sono vicini alla scadenza. MSAL consente anche di specificare il gruppo di destinatari a cui si vuole accedere l'applicazione e di configurare l'applicazione dai file di configurazione e risolvere i problemi dell'app.

Autenticare dispositivi che si connettono al gateway sul campo

Title	Dettagli
Componente	Gateway IoT sul campo
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	N/D
Passaggi	Assicurarsi che ogni dispositivo venga autenticato dal gateway sul campo prima di accettare dati dal dispositivo e prima di agevolare le comunicazioni upstream con il gateway cloud. Assicurarsi anche che i dispositivi si connettano con credenziali per dispositivo, in modo che sia possibile identificare i singoli dispositivi in modo univoco.

Assicurarsi che i dispositivi che si connettono al gateway cloud vengano autenticati

Title	Dettagli
Componente	Gateway IoT cloud
Fase SDL	Compilazione
Tecnologie applicabili	Generico, C#, Node.js
Attributi	N/A, opzione gateway: Hub IoT di Azure
Riferimenti	N/A, hub IoT di Azure con .NET, Introduzione all'hub IoT e Node JS, Protezione di IoT con firma di accesso condiviso e certificati, repository Git
Passaggi	Generico: il dispositivo viene autenticato tramite Transport Layer Security (TLS) o IPSec. L'infrastruttura deve supportare l'uso di una chiave precondivisa (PSK) nei dispositivi che non riescono a gestire la crittografia asimmetrica completa. Sfruttare Microsoft Entra ID, Oauth. C#: quando si crea un'istanza di DeviceClient, per impostazione predefinita il metodo Create crea un'istanza di DeviceClient che usa il protocollo AMQP per comunicare con l'hub IoT. Per usare il protocollo HTTPS, usare l'override del metodo Create che consente di specificare il protocollo. Se si usa il protocollo HTTPS, è necessario aggiungere al progetto anche il pacchetto NuGet Microsoft.AspNet.WebApi.Client per includere lo spazio dei nomi System.Net.Http.Formatting.

Esempio

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

Esempio

Node.js: autenticazione

Chiave simmetrica

• Creare un hub IoT in Azure
• Creare una voce nel registro delle identità del dispositivo

  var device = new iothub.Device(null);
  device.deviceId = <DeviceId >
  registry.create(device, function(err, deviceInfo, res) {})
  

• Creare un dispositivo simulato

  var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
  var Message = require('azure-iot-device').Message;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
  var client = clientFromConnectionString(connectionString);
  

  Token di firma di accesso condiviso

• Viene generato internamente quando si usa una chiave simmetrica, ma è anche possibile generarlo e usarlo in modo esplicito
• Definire un protocollo: var Http = require('azure-iot-device-http').Http;
• Creare un token di firma di accesso condiviso:

  resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
  var deviceName = "<deviceName >";
  var expires = (Date.now() / 1000) + expiresInMins * 60;
  var toSign = resourceUri + '\n' + expires;
  // using crypto
  var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
  const hmac = crypto.createHmac('sha256', decodedPassword);
  hmac.update(toSign);
  var base64signature = hmac.digest('base64');
  var base64UriEncoded = encodeURIComponent(base64signature);
  // construct authorization string
  var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
  + base64UriEncoded + "&se=" + expires;
  if (policyName) token += "&skn="+policyName;
  return token;
  

• Connessione usando il token di firma di accesso condiviso:

  Client.fromSharedAccessSignature(sas, Http);
  

  Attestati

• Generare un certificato X.509 autofirmato con qualsiasi strumento, ad esempio OpenSSL, per generare file CERT e KEY in cui archiviare, rispettivamente, il certificato e la chiave
• Effettuare il provisioning di un dispositivo che accetta connessioni protette tramite i certificati

  var connectionString = '<connectionString>';
  var registry = iothub.Registry.fromConnectionString(connectionString);
  var deviceJSON = {deviceId:"<deviceId>",
  authentication: {
      x509Thumbprint: {
      primaryThumbprint: "<PrimaryThumbprint>",
      secondaryThumbprint: "<SecondaryThumbprint>"
      }
  }}
  var device = deviceJSON;
  registry.create(device, function (err) {});
  

• Connessione un dispositivo usando un certificato

  var Protocol = require('azure-iot-device-http').Http;
  var Client = require('azure-iot-device').Client;
  var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
  var client = Client.fromConnectionString(connectionString, Protocol);
  var options = {
      key: fs.readFileSync('./key.pem', 'utf8'),
      cert: fs.readFileSync('./server.crt', 'utf8')
  };
  // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
  client.setOptions(options);
  //call fn to execute after the connection is set up
  client.open(fn);
  

Usare credenziali di autenticazione per dispositivo

Title	Dettagli
Componente	Gateway IoT cloud
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	Opzione gateway: Hub IoT di Azure
Riferimenti	Token di sicurezza dell'hub IoT di Azure
Passaggi	Usare credenziali di autenticazione per dispositivo tramite token di firma di accesso condiviso basati sulla chiave del dispositivo o sul certificato client, anziché criteri di accesso condiviso a livello di hub IoT. Questo permette di prevenire il riutilizzo dei token di autenticazione di un dispositivo o di un gateway sul campo da parte di altri.

Assicurarsi che l'accesso in lettura anonimo venga concesso solo ai contenitori e ai BLOB necessari

Title	Dettagli
Componente	Archiviazione di Azure
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	Tipo di archiviazione: BLOB
Riferimenti	Gestire l'accesso in lettura anonimo a contenitori e BLOB, Firme di accesso condiviso, parte 1: informazioni sul modello di firma di accesso condiviso
Passaggi	Per impostazione predefinita, un contenitore e tutti i BLOB all'interno di esso possono essere accessibili solo dal proprietario dell'account di archiviazione. Per concedere a utenti anonimi autorizzazioni di lettura per un contenitore e i relativi BLOB, è possibile impostare le autorizzazioni del contenitore per consentire l'accesso pubblico. Gli utenti anonimi possono leggere i BLOB presenti in un contenitore accessibile pubblicamente senza effettuare l'autenticazione della richiesta. I contenitori forniscono le seguenti opzioni per la gestione dell'accesso al contenitore: Accesso in lettura pubblico completo: I dati BLOB e del contenitore possono essere letti tramite richiesta anonima. I client possono enumerare i BLOB all'interno del contenitore tramite richiesta anonima, ma non sono in grado di enumerare i contenitori all'interno dell'account di archiviazione. Accesso in lettura pubblico solo per i BLOB: I dati BLOB all'interno di questo contenitore possono essere letti tramite richiesta anonima, ma i dati del contenitore non sono disponibili. I client non possono enumerare i BLOB all'interno del contenitore tramite richiesta anonima. Nessun accesso in lettura pubblico: i dati del BLOB e del contenitore possono essere letti solo dal proprietario dell'account. L'accesso anonimo è ideale per scenari in cui alcuni BLOB devono essere sempre disponibili per l'accesso in lettura anonimo. Per un controllo più capillare, è possibile creare una firma di accesso condiviso, che permette di delegare l'accesso limitato con autorizzazioni diverse e per un intervallo di tempo specificato. Assicurarsi che ai contenitori e ai BLOB, che potrebbero potenzialmente contenere dati sensibili, non venga concesso l'accesso anonimo accidentalmente

Concedere l'accesso limitato agli oggetti in Archiviazione di Azure tramite la firma di accesso condiviso o criteri di accesso archiviati

Title	Dettagli
Componente	Archiviazione di Azure
Fase SDL	Compilazione
Tecnologie applicabili	Generica
Attributi	N/D
Riferimenti	Firme di accesso condiviso, parte 1: informazioni sul modello di firma di accesso condiviso, Firme di accesso condiviso, parte 2: creare e usare una firma di accesso condiviso con l'archivio BLOB, Come delegare l'accesso agli oggetti nell'account usando firme di accesso condiviso e criteri di accesso archiviati
Passaggi	La firma di accesso condiviso è uno strumento efficace per concedere ad altri client un accesso limitato agli oggetti nell'account di archiviazione, senza dover esporre la chiave di accesso dell'account. La firma di accesso condiviso è un URI che racchiude nei parametri di query tutte le informazioni necessarie per l'accesso autenticato a una risorsa di archiviazione. Per accedere alle risorse di archiviazione con la firma di accesso condiviso, il client deve solo passare la firma al costruttore o al metodo appropriato. È possibile usare una firma di accesso condiviso quando si desidera fornire l'accesso alle risorse dell'account di archiviazione a un client al quale non si desidera fornire la chiave dell'account. Le chiavi dell'account di archiviazione includono una chiave primaria e una chiave secondaria, che garantiscono entrambi accesso amministrativo all'account e a tutte le risorse in esso presenti. Se si espone una delle chiavi dell'account, è possibile che l'account venga utilizzato in modo dannoso o non appropriato. Le firme di accesso condiviso costituiscono un'alternativa sicura per consentire ad altri client di leggere, scrivere ed eliminare dati nell'account di archiviazione sulla base delle autorizzazioni concesse e senza richiedere la chiave dell'account. Se è disponibile un set logico di parametri simili ogni volta, è preferibile usare i criteri di accesso archiviati. Poiché l'uso di una firma di accesso condiviso derivata da criteri di accesso archiviati offre la possibilità di revocare immediatamente la firma di accesso condiviso, è consigliabile usare sempre i criteri di accesso archiviati, quando possibile.