Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo argomento fornisce informazioni sulle procedure consigliate per pianificare e valutare la sicurezza quando si progetta la distribuzione di Active Directory Federation Services (AD FS). Questo argomento è un punto di partenza per esaminare e valutare le considerazioni che influiscono sulla sicurezza complessiva dell'uso di AD FS. Le informazioni contenute in questo argomento sono progettate per integrare ed estendere la pianificazione della sicurezza esistente e altre procedure consigliate per la progettazione.
Procedure consigliate per la sicurezza di base per AD FS
Le procedure consigliate di base seguenti 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, deve essere considerato come un sistema di "livello 0" come altri sistemi di identità nella rete. Per altre informazioni, vedere Modello di livello amministrativo di Active Directory.
Utilizzare la Configurazione guidata della sicurezza per applicare le procedure consigliate di sicurezza specifiche di AD FS ai server federativi e ai computer proxy dei server federativi
Lo strumento Configurazione guidata sicurezza (Security Configuration Wizard) è preinstallato in tutti i computer con Windows Server 2008, Windows Server 2008 R2 e Windows Server 2012. È possibile usarlo per applicare le procedure consigliate per la sicurezza che consentono di ridurre la superficie di attacco per un server, in base ai ruoli del server che si stanno installando.
Quando si installa AD FS, il programma di installazione crea file di estensione del ruolo che è possibile usare con la configurazione guidata per creare un criterio di sicurezza che verrà applicato al ruolo del server AD FS specifico (server federativo o proxy server federativo) scelto durante l'installazione.
Ogni file di estensione del ruolo installato rappresenta il tipo di ruolo e il sottobrole per cui è configurato ogni computer. I file di estensione del ruolo seguenti vengono installati nella directory C:WindowsADFSScw:
Farm.xml
SQLFarm.xml
StandAlone.xml
Proxy.xml (questo file è presente solo se il computer è stato configurato nel ruolo proxy server federativo).
Per applicare le estensioni del ruolo AD FS nell'SCW, completare i passaggi seguenti nell'ordine indicato:
Installare AD FS e scegliere il ruolo del server appropriato per tale computer. Per altre informazioni, vedere Installare il ruolo proxy del Servizio Federativo nella Guida alla distribuzione di AD FS.
Registrare il file di estensione del ruolo appropriato usando lo strumento da riga di comando Scwcmd. Per informazioni dettagliate sull'uso di questo strumento nel ruolo per cui è configurato il computer, vedere la tabella seguente.
Verificare che il comando sia stato completato esaminando il file SCWRegister_log.xml, che si trova nella directory WindowssecurityMsscwLogs.
È necessario eseguire tutti questi passaggi in ogni server federativo o computer proxy server federativo a cui si desidera applicare criteri di sicurezza basati su AD FS.
La tabella seguente illustra come registrare l'estensione del ruolo SCW appropriata, in base al ruolo del server AD FS scelto nel computer in cui è stato installato AD FS.
Ruolo del server AD FS Database di configurazione di AD FS usato Digitare il comando seguente al prompt dei comandi: Server federativo autonomo Database interno di Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwStandAlone.xml"Server federativo unito alla farm Database interno di Windows scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwFarm.xml"Server federativo appartenente a una farm SQL Server scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwSQLFarm.xml"Server proxy federativo Non disponibile scwcmd register /kbname:ADFS2Standalone /kbfile:"WindowsADFSscwProxy.xml"Per altre informazioni sui database che è possibile usare con AD FS, vedere Ruolo del database di configurazione di AD FS.
Usare il rilevamento della riproduzione dei token in situazioni in cui la sicurezza è un problema molto importante, ad esempio quando vengono usati chioschi multimediali. Il rilevamento della riproduzione dei token è una funzionalità di AD FS che garantisce che qualsiasi tentativo di riprodurre una richiesta di token effettuata al servizio federativo venga rilevata e la richiesta venga rimossa. Il rilevamento della riproduzione dei token è abilitato per impostazione predefinita. Funziona sia per il profilo WS-Federation passivo che per il profilo WebSSO SAML (Security Assertion Markup Language) assicurando che lo stesso token non venga mai usato più di una volta.
All'avvio del servizio federativo, inizia a compilare una cache di tutte le richieste di token soddisfatte. Nel corso del tempo, man mano che le richieste di token successive vengono aggiunte alla cache, la possibilità di rilevare eventuali tentativi di riprodurre più volte una richiesta di token aumenta per il servizio federativo. Se si disabilita il rilevamento della riproduzione dei token e successivamente si sceglie di abilitarlo di nuovo, tenere presente che il servizio federativo accetterà comunque i token per un periodo di tempo che potrebbe essere stato usato in precedenza, fino a quando la cache di riproduzione non ha avuto tempo sufficiente per ricompilarne il contenuto. Per altre informazioni, vedere Ruolo del database di configurazione di AD FS.
Usare la crittografia dei token, soprattutto se si usa il supporto della risoluzione degli artefatti SAML.
La crittografia dei token è fortemente consigliata per aumentare la sicurezza e la protezione da potenziali attacchi man-in-the-middle (MITM) che potrebbero essere tentati contro l'implementazione di AD FS. L'uso della crittografia potrebbe avere un impatto leggero sulla capacità, ma in generale, non dovrebbe essere generalmente notato e in molte implementazioni i vantaggi di una maggiore sicurezza compensano ampiamente i costi relativi alle prestazioni del server.
Per abilitare la crittografia dei token, prima di tutto aggiungere un certificato di crittografia per i trust della relying party. È possibile configurare un certificato di crittografia durante la creazione di un trust della parte fidata o successivamente. Per aggiungere in un secondo momento un certificato di crittografia a un trust di una relying party esistente, è possibile impostare un certificato da usare nella scheda Crittografia nelle proprietà del trust utilizzando lo snap-in AD FS. Per specificare un certificato per un trust esistente usando i cmdlet AD FS, utilizzare il parametro EncryptionCertificate dei cmdlet Set-ClaimsProviderTrust o Set-RelyingPartyTrust . Per impostare un certificato per il servizio federativo da usare durante la decrittografia dei token, usare il cmdlet Set-ADFSCertificate e specificare "
Token-Encryption" per il parametro CertificateType . È possibile abilitare e disabilitare la crittografia per un trust della relying party specifica utilizzando il parametro EncryptClaims del cmdlet Set-RelyingPartyTrust.Usare la protezione estesa per l'autenticazione
Per proteggere le distribuzioni, è possibile impostare e usare la protezione estesa per la funzionalità di autenticazione con AD FS. Questa impostazione specifica il livello di protezione estesa per l'autenticazione supportata da un server federativo.
La protezione estesa per l'autenticazione consente di proteggersi da attacchi MAN-in-the-middle (MITM), in cui un utente malintenzionato intercetta le credenziali client e le inoltra a un server. La protezione da tali attacchi è resa possibile tramite un token cbt (Channel Binding Token) che può essere richiesto, consentito o non richiesto dal server quando stabilisce comunicazioni con i client.
Per abilitare la funzionalità di protezione estesa, usare il parametro ExtendedProtectionTokenCheck nel cmdlet Set-ADFSProperties . I valori possibili per questa impostazione e il livello di sicurezza forniti dai valori sono descritti nella tabella seguente.
Valore del parametro Livello di sicurezza Impostazione di protezione Richiedere Il server è completamente rafforzato. La protezione estesa viene applicata e sempre richiesta. Consentire Il server è parzialmente protetto. La protezione estesa viene applicata quando i sistemi coinvolti sono stati sottoposti a patch per supportarlo. Nessuno Il server è vulnerabile. La protezione estesa non viene applicata. Se si utilizzano la registrazione e il monitoraggio, assicurati della privacy di tutte le informazioni riservate.
AD FS non espone o tiene traccia delle informazioni personali direttamente come parte del servizio federativo o delle normali operazioni. Quando la registrazione degli eventi e la registrazione della traccia di debug sono abilitate in AD FS, tuttavia, a seconda dei criteri di attestazioni configurati, alcuni tipi di attestazioni e i relativi valori associati potrebbero contenere informazioni personali che potrebbero essere registrate nei log di traccia o eventi di AD FS.
Pertanto, è consigliabile applicare il controllo di accesso alla configurazione di AD FS e i relativi file di log. Se non si vuole che questo tipo di informazioni sia visibile, è consigliabile disabilitare l'accesso o filtrare i dati personali o sensibili nei log prima di condividerli con altri utenti.
I suggerimenti seguenti consentono di evitare che il contenuto di un file di log venga esposto involontariamente:
Assicurarsi che i file di log eventi e di traccia di AD FS siano protetti da elenchi di controllo di accesso (ACL) che limitano l'accesso solo agli amministratori attendibili che richiedono l'accesso.
Non copiare o archiviare file di log usando estensioni di file o percorsi che possono essere facilmente gestiti tramite una richiesta Web. Ad esempio, l'estensione .xml nome file non è una scelta sicura. È possibile controllare la guida all'amministrazione di Internet Information Services (IIS) per visualizzare un elenco di estensioni che possono essere gestite.
Se si modifica il percorso del file di log, assicurarsi di specificare un percorso assoluto per il percorso del file di log, che deve trovarsi all'esterno della directory pubblica della radice virtuale dell'host Web (vroot) per impedirne l'accesso da parte di un'entità esterna tramite un Web browser.
Blocco Temporaneo Extranet di AD FS e Protezione del Blocco Intelligente Extranet di AD FS
In caso di attacco sotto forma di richieste di autenticazione con password non valide (non valide) provenienti dal proxy applicazione Web, il blocco extranet di AD FS consente di proteggere gli utenti da un blocco dell'account AD FS. Oltre a proteggere gli utenti da un blocco dell'account AD FS, il blocco extranet di AD FS protegge anche dagli attacchi di forza bruta per indovinare le password.
Per il blocco flessibile Extranet per AD FS in Windows Server 2012 R2, vedere Protezione blocco flessibile Extranet di AD FS.
Per Blocco Intelligente Extranet per AD FS in Windows Server 2016, vedere Protezione del Blocco Intelligente Extranet di AD FS.
Procedure consigliate per la sicurezza specifiche di SQL Server per AD FS
Le procedure consigliate per la sicurezza seguenti sono specifiche per l'uso di Microsoft SQL Server® o del database interno di Windows (WID) quando queste tecnologie di database vengono usate per gestire i dati nella progettazione e nella distribuzione di AD FS.
Nota
Queste raccomandazioni sono progettate per estendere, ma non sostituire, le linee guida per la sicurezza del prodotto SQL Server. Per altre informazioni sulla pianificazione di un'installazione sicura di SQL Server, vedere Considerazioni sulla sicurezza per un'installazione sicura di SQL (https://go.microsoft.com/fwlink/?LinkID=139831).
Distribuire sempre SQL Server dietro 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 data center devono essere in grado di raggiungere l'installazione di SQL Server che supporta AD FS. Per altre informazioni, vedere Elenco di controllo delle procedure consigliate per la sicurezza (https://go.microsoft.com/fwlink/?LinkID=189229).
Eseguire SQL Server con un account di servizio invece di utilizzare gli account di servizio di sistema predefiniti.
Per impostazione predefinita, SQL Server viene spesso installato e configurato per l'uso di uno degli account di sistema predefiniti supportati, ad esempio gli account LocalSystem o NetworkService. Per migliorare la sicurezza dell'installazione di SQL Server per AD FS, laddove possibile, usare un account del servizio separato per accedere al servizio SQL Server e abilitare l'autenticazione Kerberos registrando il nome dell'entità di sicurezza (SPN) di questo account nella distribuzione di Active Directory. Ciò consente l'autenticazione reciproca tra client e server. Senza registrazione SPN di un account del servizio separato, SQL Server userà NTLM per l'autenticazione basata su Windows, in cui viene autenticato solo il client.
Ridurre al minimo l'area di attacco di SQL Server.
Abilitare solo gli endpoint di SQL Server necessari. Per impostazione predefinita, SQL Server fornisce 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 per verificare se vengono aggiunte altre porte TCP definite dall'utente a un'installazione SQL, è possibile usare l'istruzione di query "SELECT * FROM sys.tcp_endpoints" in una sessione di Transact-SQL (T-SQL). Per altre informazioni sulla configurazione dell'endpoint di SQL Server, vedere Procedura: Configurare il motore di database per l'ascolto 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 come testo non crittografato sulla rete o archiviare le 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. L'archiviazione delle credenziali di accesso SQL (Structured Query Language) (nomi utente e password SQL) quando si usa l'autenticazione di SQL Server non è consigliabile. Per altre informazioni, vedere Modalità di autenticazione (https://go.microsoft.com/fwlink/?LinkID=189232).
Valutare attentamente la necessità di una maggiore sicurezza del canale nell'installazione di SQL.
Anche con l'autenticazione Kerberos, SQL Server Security Support Provider Interface (SSPI) non fornisce sicurezza a livello di canale. Tuttavia, per le installazioni in cui i server si trovano in modo sicuro in una rete protetta da firewall, la crittografia delle comunicazioni SQL potrebbe non essere necessaria.
Anche se la crittografia è uno strumento utile per garantire la sicurezza, non deve essere considerata per tutti i dati o le connessioni. Quando si decide se implementare la crittografia, valutare il modo in cui gli utenti accederanno ai dati. Se gli utenti accedono ai dati tramite una rete pubblica, potrebbe essere necessaria la crittografia dei dati per aumentare la sicurezza. Tuttavia, se tutti gli accessi ai dati SQL da AD FS comportano una configurazione Intranet sicura, la crittografia potrebbe non essere necessaria. Qualsiasi uso della crittografia deve includere anche una strategia di manutenzione per password, chiavi e certificati.
Se si verifica un problema per cui i dati SQL potrebbero essere visualizzati o manomessi tramite la rete, usare la sicurezza del protocollo Internet (IPsec) o Secure Sockets Layer (SSL) per proteggere le connessioni SQL. Tuttavia, questo potrebbe avere un effetto negativo sulle prestazioni di SQL Server, che potrebbero influire o limitare le prestazioni di AD FS in alcune situazioni. Ad esempio, le prestazioni di AD FS nel rilascio dei token potrebbero peggiorare quando le ricerche degli attributi da un archivio attributi basato su SQL sono fondamentali per il rilascio dei token. È possibile eliminare meglio una minaccia di manomissione SQL con una configurazione di sicurezza perimetrale avanzata. Ad esempio, una soluzione migliore per proteggere l'installazione di SQL Server consiste nel garantire che rimanga inaccessibile per utenti e computer Internet e che rimanga accessibile solo da utenti o computer all'interno dell'ambiente data center.
Per altre informazioni, vedere Crittografia delle connessioni a SQL Server o crittografia di SQL Server.
Configurare un accesso progettato in modo sicuro utilizzando stored procedure per eseguire tutte le ricerche basate su SQL da AD FS sui dati archiviati su SQL.
Per offrire un migliore servizio e un migliore isolamento dei dati, è possibile creare procedure archiviate per tutti i comandi di ricerca dell'archivio attributi. È possibile creare un ruolo del database a cui si concede quindi l'autorizzazione per eseguire le stored procedure. Assegna l'identità del servizio Windows AD FS a questo ruolo del database. Il servizio Windows AD FS non deve essere in grado di eseguire altre istruzioni SQL, diverse dalle stored procedure appropriate utilizzate per la ricerca degli attributi. Il blocco dell'accesso al database di SQL Server in questo modo riduce il rischio di un attacco di elevazione dei privilegi.