Infrastruttura di sicurezza: autenticazione - Procedure di mitigazione

• 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

• Usare l'autenticazione di Windows per la connessione a SQL Server, se possibile
• Quando possibile usare l'autenticazione di Microsoft Entra per la connessione a 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

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

• Abilitare l'autenticazione a più fattori Di Microsoft Entra per gli amministratori di Azure

• 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

• Usare scenari di autenticazione standard supportati da Identity Server
• Sostituire la cache dei token di Identity Server predefinita con un'alternativa scalabile

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

• 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

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

• 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)

• Autenticare dispositivi che si connettono al gateway sul campo

• Assicurarsi che i dispositivi che si connettono al gateway cloud vengano autenticati
• Usare credenziali di autenticazione per dispositivo

• 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

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

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.

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.

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.

È 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.

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.

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)

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.

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.

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.

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.

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

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.

Microsoft Entra ID semplifica l'autenticazione per gli sviluppatori fornendo identità come servizio, con supporto per protocolli standard del settore, ad esempio OAuth 2.0 e OpenID Connect. 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.

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.

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.

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.

• 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.

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

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.