Procedure consigliate per la pianificazione e la distribuzione sicure di ADFS
In questo argomento sono disponibili informazioni sulle procedure consigliate per facilitare la pianificazione e la valutazione della sicurezza quando si progetta la distribuzione di Active Directory Federation Services (AD FS). Questo argomento offre un punto di partenza per rivedere e valutare le considerazioni relative alla sicurezza complessiva per l'uso di AD FS. Le informazioni in questo argomento sono complementari ed estendono la pianificazione della sicurezza esistente, nonché altre procedure consigliate per la progettazione.
Procedure consigliate per la sicurezza di base per ADFS
Le procedure consigliate di base che seguono sono comuni a tutte le installazioni di AD FS in cui si vuole migliorare o estendere la sicurezza della progettazione o della distribuzione:
Proteggere AD FS come sistema di livello 0
Poiché AD FS è fondamentalmente un sistema di autenticazione, va considerato un sistema di livello 0, come gli altri sistemi di identità nella rete. Per altre informazioni, vedere Modello a livelli dell'amministrazione di Active Directory.
Usare la Configurazione guidata impostazioni di sicurezza per applicare le procedure consigliate per la sicurezza specifiche di AD FS ai computer server federativi e proxy server federativi
La Configurazione guidata impostazioni di sicurezza è uno strumento preinstallato in tutti i computer che eseguono Windows Server 2008, Windows Server 2008 R2 e Windows Server 2012. È possibile usarla per applicare le procedure consigliate per la sicurezza che contribuiscono a ridurre la superficie di attacco di un server in base ai ruoli del server installati.
Quando si installa ADFS, il programma di installazione crea file di estensione dei ruoli che si possono usare con la Configurazione guidata impostazioni di sicurezza per creare i criteri di sicurezza che saranno applicati al ruolo del server ADFS specifico, cioè server federativo o proxy server federativo, scelto durante l'installazione.
Ogni file di estensione dei ruoli installato rappresenta il tipo di ruolo e ruolo secondario per cui è configurato ogni computer. I file di estensione dei ruoli seguenti sono installati nella directory C:WindowsADFS:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (questo file è presente solo se per il computer è configurato il ruolo di proxy server federativo).
Per applicare le estensioni dei ruoli di ADFS nella Configurazione guidata impostazioni di sicurezza, completare i seguenti passaggi nell'ordine indicato:
Installare ADFS e scegliere il ruolo del server appropriato per il computer. Per altre informazioni, vedere Installare il servizio ruolo proxy del servizio federativo nella Guida alla distribuzione di AD FS.
Registrare il file di estensione dei ruoli appropriato con lo strumento da riga di comando Scwcmd. Per dettagli sull'uso di questo strumento nel ruolo per cui è configurato il computer, vedere la tabella seguente.
Verificare che il comando sia stato completato correttamente esaminando il file SCWRegister_log.xml, disponibile nella directory WindowssecurityMsscwLogs.
Tutti questi passaggi devono essere eseguiti su ogni computer server federativo o proxy server federativo a cui si vogliono applicare i criteri di sicurezza della Configurazione guidata impostazioni di sicurezza basati su ADFS.
Nella seguente tabella è spiegato come registrare l'estensione dei ruoli della Configurazione guidata impostazioni di sicurezza appropriata in base al ruolo del server ADFS scelto nel computer in cui è installato ADFS.
Ruolo del server ADFS Database di configurazione di ADFS usato Al prompt dei comandi digitare il comando seguente: Server federativo autonomo Database interno di Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Server federativo aggiunto alla farm Database interno di Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Server federativo aggiunto alla farm SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Proxy server federativo N/D scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Per altre informazioni sui database che si possono usare con AD FS, vedere Ruolo del database di configurazione di AD FS.
Usare il rilevamento riproduzione token in situazioni in cui la sicurezza rappresenta un aspetto molto importante, ad esempio quando vengono usati chioschi multimediali. Il rilevamento riproduzione token è una funzionalità di AD FS che assicura che qualsiasi tentativo di riprodurre una richiesta di token fatta al Servizio federativo venga rilevata e sia ignorata. Il rilevamento riproduzione token è abilitato per impostazione predefinita. Funziona sia per il profilo passivo WS-Federation sia per il profilo WebSSO SAML (Security Assertion Markup Language), assicurando che lo stesso token non venga mai usato più di una volta.
Quando il Servizio federativo viene avviato, inizia a compilare una cache di tutte le richieste di token soddisfatte. Poiché con il tempo vengono aggiunte alla cache richieste di token successive, per il Servizio federativo aumenta la capacità di rilevare qualsiasi tentativo di riprodurre più volte una richiesta di token. Se si disabilita il rilevamento riproduzione token e in seguito si sceglie di riabilitarlo, si ricordi che il Servizio federativo continuerà ad accettare token per un periodo di tempo che potrebbe essere stato usato in precedenza, finché la cache di riproduzione non avrà avuto abbastanza tempo per ricostruire il proprio contenuto. Per altre informazioni, vedere Ruolo del database di configurazione di AD FS.
Usare la crittografia dei token, specialmente se si usa la risoluzione artefatto SAML di supporto.
La crittografia dei token è particolarmente consigliata per migliorare la sicurezza e la protezione da potenziali tentativi di attacchi man-in-the-middle contro la distribuzione di AD FS. L'uso della crittografia potrebbe avere un leggero impatto sulla velocità effettiva, ma in generale non è di solito rilevabile e in molte distribuzioni i vantaggi dati da una maggiore sicurezza superano qualsiasi costo in termini di prestazioni del server.
Per abilitare la crittografia di token, aggiungere prima di tutto un certificato di crittografia per i trust della relying party. È possibile configurare un certificato di crittografia quando si crea un trust della relying party o in seguito. Per aggiungere un certificato di crittografia a un trust della relying party esistente in un secondo momento, è possibile impostare il certificato da usare nella scheda Crittografia all'interno delle proprietà di trust dello snap-in AD FS. Per specificare un certificato per un trust esistente con i cmdlet di AD FS, usare il parametro EncryptionCertificate oppure il cmdlet Set-ClaimsProviderTrust o Set-RelyingPartyTrust. Per impostare un certificato per il Servizio federativo da usare per decrittografare i token, usare il cmdlet Set-ADFSCertificate e specificare "
Token-Encryption" per il parametro CertificateType. Per abilitare e disabilitare la crittografia per il trust della relying party specifico, è possibile usare il parametro EncryptClaims del cmdlet Set-RelyingPartyTrust.Usare la protezione estesa per l'autenticazione
Per facilitare la protezione delle distribuzioni, è possibile impostare e usare la protezione estesa come funzionalità di autenticazione in AD FS. Questa impostazione specifica il livello di protezione estesa per l'autenticazione supportato da un server federativo.
La protezione estesa per l'autenticazione consente di contrastare gli attacchi man-in-the-middle in cui l'autore di un attacco intercetta le credenziali del client e le inoltra a un server. La protezione da tali attacchi è possibile grazie al token di binding che può essere richiesto, consentito o non richiesto dal server quando stabilisce le comunicazioni con i client.
Per abilitare la funzionalità di protezione estesa, usare il parametro ExtendedProtectionTokenCheck nel cmdlet Set-ADFSProperties. I valori possibili di questa impostazione e il livello di sicurezza fornito dai valori sono descritti nella tabella seguente.
Valore del parametro Livello di sicurezza Impostazione di protezione Richiedi Il server è completamente protetto. La protezione estesa è applicata e sempre richiesta. Consenti Il server è parzialmente protetto. La protezione estesa è applicata ai sistemi interessati se sono stati configurati per supportarla. Nessuno Il server è vulnerabile. La protezione estesa non è applicata. Se si usano registrazione e traccia, verificare che sia garantita la privacy delle informazioni sensibili.
Per impostazione predefinita, AD FS non espone né tiene traccia direttamente delle informazioni personali come parte del Servizio federativo o delle normali operazioni. Tuttavia, quando sono abilitate la registrazione eventi e la registrazione della traccia di debug in AD FS, a seconda dei criteri delle attestazioni configurati, alcuni tipi di attestazione e i valori associati possono contenere informazioni personali che potrebbero essere registrate nel registro eventi o nel log di traccia di AD FS.
L'applicazione del controllo di accesso nella configurazione di AD FS e nei relativi file di log è quindi particolarmente consigliabile. Se non si vuole che questo tipo di informazioni sia visibile, disabilitare la registrazione o filtrare qualsiasi informazione personale o sensibile eliminandola dai log prima di condividerli con altri.
I suggerimenti seguenti possono essere utili per evitare che il contenuto di un file di log sia esposto accidentalmente:
Verificare che il registro eventi e i file di log di traccia di AD FS siano protetti da elenchi di controllo di accesso (ACL) che limitano l'accesso solo agli amministratori attendibili che lo richiedono.
Non copiare o archiviare file di log usando estensioni di file o percorsi che possono essere facilmente serviti usando una richiesta Web. Ad esempio, l'estensione di file XML non è una scelta sicura. Per un elenco di estensioni che possono essere servite, vedere la guida all'amministrazione di Internet Information Services (IIS).
Se si modifica il percorso del file di log, accertarsi di specificare un percorso assoluto che dovrebbe trovarsi all'esterno della directory radice virtuale pubblica dell'host Web, in modo da evitarne l'accesso da una parte esterna con un Web browser.
Protezione di blocco della Extranet parziale e blocco della Extranet intelligente di AD FS
Nel caso di un attacco sotto forma di richieste di autenticazione con password non valide provenienti dal Proxy applicazione Web, il blocco Extranet di AD FS consente di proteggere gli utenti da un blocco dell'account di AD FS. Oltre a proteggere gli utenti da un blocco dell'account di AD FS, il blocco Extranet di AD FS protegge anche dagli attacchi di forza bruta con tentativo di determinazione delle password.
Per il blocco della Extranet parziale per AD FS in Windows Server 2012 R2, vedere Protezione Extranet Soft Lockout di AD FS.
Per il blocco della Extranet intelligente per AD FS in Windows Server 2016, vedere Protezione Extranet Smart Lockout di AD FS.
Procedure consigliate per la sicurezza di base specifiche di SQL Server per ADFS
Le procedure consigliate per la sicurezza di seguito riguardano in modo specifico l'uso di Microsoft SQL Server® o di Database interno di Windows (WID) quando si usano queste tecnologie database per la gestione dei dati nella progettazione e distribuzione di AD FS.
Nota
Questi suggerimenti costituiscono un'estensione della guida alla sicurezza del prodotto SQL Server, ma non la sostituiscono. Per altre informazioni sulla pianificazione di un'installazione sicura di SQL Server, vedere Considerazioni sulla sicurezza per un'installazione di SQL Server (https://go.microsoft.com/fwlink/?LinkID=139831).
Distribuire sempre SQL Server proteggendolo con un firewall in un ambiente di rete fisicamente sicuro.
Un'installazione di SQL Server non deve mai essere esposta direttamente a Internet. Solo i computer all'interno del datacenter dovrebbero poter raggiungere l'installazione di SQL server che supporta AD FS. Per altre informazioni, vedere l'elenco di controllo delle procedure consigliate per la sicurezza (https://go.microsoft.com/fwlink/?LinkID=189229).
Eseguire SQL Server con un account del servizio anziché con gli account dei servizi di sistema predefiniti incorporati.
Per impostazione predefinita, SQL Server è spesso installato e configurato per l'uso di uno degli account di sistema predefiniti supportati, ad esempio LocalSystem o NetworkService. Per migliorare la sicurezza dell'installazione di SQL Server per AD FS, usare un account del servizio distinto per accedere al servizio SQL Server e abilitare l'autenticazione Kerberos ogni volta che è possibile, registrando il nome dell'entità di sicurezza (SPN) di questo account nella distribuzione di Active Directory. In questo modo si abilita l'autenticazione reciproca tra client e server. Senza la registrazione dell'SPN di un account del servizio distinto, SQL Server userà NTLM per l'autenticazione basata su Windows in cui solo il client viene autenticato.
Ridurre al minimo la superficie di attacco di SQL Server.
Abilitare solo gli endpoint di SQL Server necessari. Per impostazione predefinita, SQL Server include un singolo endpoint TCP predefinito che non può essere rimosso. Per AD FS è necessario abilitare questo endpoint TCP per l'autenticazione Kerberos. Per esaminare gli endpoint TCP correnti e verificare se a un'installazione di SQL sono state aggiunte altre porte TCP definite dall'utente, è possibile usare l'istruzione di query "SELECT * FROM sys.tcp_endpoints" in una sessione Transact-SQL (T-SQL). Per altre informazioni sulla configurazione degli endpoint di SQL Server, vedere Procedura: Configurazione del Motore di database per l'attesa su più porte TCP (https://go.microsoft.com/fwlink/?LinkID=189231).
Evitare di usare l'autenticazione basata su SQL.
Per evitare di dover trasferire password non crittografate attraverso la rete o di archiviare password nelle impostazioni di configurazione, usare l'autenticazione di Windows solo con l'installazione di SQL Server. L'autenticazione di SQL Server è una modalità di autenticazione legacy. Non è consigliabile archiviare le credenziali di accesso SQL (Structured Query Language), cioè nomi utente e password SQL, quando si usa l'autenticazione di SQL Server. Per altre informazioni, vedere Modalità di autenticazione (https://go.microsoft.com/fwlink/?LinkID=189232).
Valutare con attenzione la necessità di applicare un livello di sicurezza del canale aggiuntivo nell'installazione di SQL.
Anche con l'autenticazione Kerberos attivata, Security Support Provider Interface (SSPI) di SQL Server non offre la sicurezza a livello di canale. Tuttavia, per le installazioni in cui i server sono collocati in una rete protetta da firewall, la crittografia delle comunicazioni SQL potrebbe non essere necessaria.
Anche se la crittografia è uno strumento valido ai fini della sicurezza,non deve essere necessariamente considerata per tutti i tipi di dati e di connessioni. Quando si decide se implementare la crittografia, considerare la modalità di accesso ai dati da parte degli utenti. Se gli utenti accedono ai dati attraverso una rete pubblica, la crittografia dei dati potrebbe essere indispensabile per migliorare la sicurezza. Se tuttavia tutto l'accesso ai dati SQL da parte di AD FS prevede una configurazione sicura della rete Intranet, la crittografia potrebbe non essere necessaria. Qualsiasi uso della crittografia dovrebbe includere anche una strategia di manutenzione per password, chiavi e certificati.
Nel caso si tema che i dati SQL possano essere visualizzati o manomessi attraverso la rete, usare il protocollo IPSec (Internet Protocol Security) o SSL (Secure Sockets Layer) per migliorare la sicurezza delle connessioni SQL. Questa impostazione può però avere un effetto negativo sulle prestazioni di SQL Server che, in alcune situazioni, potrebbe interessare o limitare le prestazioni di AD FS. Ad esempio, le prestazioni di AD FS per il rilascio dei token potrebbero peggiorare nel caso in cui le ricerche di attributi in un archivio attributi basato su SQL siano cruciali per il rilascio dei token. È possibile scegliere un modo migliore per eliminare una minaccia di manomissione di SQL usando una configurazione di sicurezza del perimetro avanzata. Ad esempio, per proteggere in modo più efficace l'installazione di SQL Server, la soluzione migliore consiste nell'assicurare che rimanga inaccessibile per gli utenti e i computer Internet e accessibile solo per gli utenti e i computer nel proprio ambiente di datacenter.
Per altre informazioni, vedere Crittografia delle connessioni a SQL Server o Crittografia di SQL Server.
Configurare l'accesso progettato in modo sicuro usando stored procedure per eseguire tutte le ricerche basate su SQL di dati archiviati in SQL da AD FS.
Per offrire un migliore isolamento di dati e servizi, si possono creare stored procedure per tutti i comandi di ricerca nell'archivio attributi. È possibile creare un ruolo del database al quale concedere poi l'autorizzazione di eseguire le stored procedure. Assegnare l'identità del servizio Windows AD FS a questo ruolo del database. Il servizio Windows AD FS non dovrebbe riuscire a eseguire altre istruzioni SQL oltre alle stored procedure appropriate usate per la ricerca di attributi. Il blocco dell'accesso al database SQL Server in questo modo riduce il rischio di un attacco tramite elevazione dei privilegi.