Consigli sulla sicurezza per SSO

  • Articolo

Questa sezione contiene raccomandazioni per proteggere il sistema Enterprise Single Sign-On (SSO).

Con il sistema Enterprise Single Sign-On (SSO), gli utenti possono connettersi a sistemi diversi usando un solo set di credenziali. Host Integration Server usa il sistema SSO come archivio per informazioni riservate. Anche se viene installato automaticamente ogni volta che si installa il runtime di Host Integration Server, è anche possibile installare Enterprise Single Sign-On come componente autonomo, indipendentemente dall'ambiente Host Integration Server. È consigliabile seguire queste linee guida per proteggere e distribuire i servizi e le risorse SSO aziendali nell'ambiente.

Consigli generali sulla distribuzione di SSO

  • L'ambiente deve comprendere un server di riferimento ora per garantire la sincronizzazione di tutti i server SSO. Se gli orologi nei server SSO non vengono sincronizzati, questo potrebbe compromettere la sicurezza dell'ambiente.

  • Considerando che è presente un solo server segreto master nell'intero ambiente, si usa una configurazione del cluster attivo-passivo per il server segreto master. Per altre informazioni sul clustering del server segreto master, vedere How to Cluster the Master Secret Server.For more information about clustering the master secret server, see How to Cluster the Master Secret Server.

  • Il server segreto master contiene la chiave di crittografia utilizzata dal sistema SSO per crittografare le informazioni nel database SSO. È consigliabile non installare o configurare altri prodotti o servizi nel computer.

    Nota

    Non è necessario che il computer in cui si installa e si configura il server master secret sia un server.

  • Il server master secret deve poter accedere a un supporto rimovibile o una cartella del file system NTFS per eseguire il backup e il ripristino del master secret. Se si usano supporti rimovibili, assicurarsi di adottare misure appropriate per proteggere i supporti rimovibili. Se si esegue il backup del segreto master in un file system NTFS, assicurarsi di proteggere il file e la cartella. Solo l'amministratore SSO deve disporre dell'accesso a questo file.

  • È consigliabile eseguire il backup del master secret non appena viene generato dal server master secret, Ciò significa che è possibile recuperare i dati nel database SSO nel caso in cui il server segreto master non riesce. Per altre informazioni sul backup del segreto master, vedere Gestione del segreto master.

  • Eseguire il backup del segreto corrente o generare regolarmente un nuovo segreto, ad esempio una volta al mese. Senza il master secret non è possibile recuperare informazioni dal database SSO. Per altre informazioni sul backup e il ripristino del segreto master, vedere Gestione del segreto master.

Consigli sulla sicurezza per i gruppi e gli account SSO

  • È consigliabile usare i gruppi di Windows e non gli account utente singoli, soprattutto per i gruppi di amministratore SSO e amministratore di affiliazione SSO. Questi gruppi devono includere sempre almeno due account utente come membri del gruppo.

  • Gli account di servizio del runtime SSO e gli account utente degli amministratori SSO devono essere account diversi, anche se sono membri delle stesso gruppo Amministratori SSO. Gli utenti dell'amministratore SSO che eseguono attività amministrative, ad esempio la generazione e il backup del segreto, devono essere amministratori di Windows, mentre gli account del servizio di runtime SSO non devono essere amministratori di Windows.

    Importante

    I diritti utente degli amministratori di Windows non prevalgono su quelli dell'amministratore SSO. Per eseguire qualsiasi attività a livello di amministrazione SSO, è necessario essere un membro del gruppo Amministratori SSO anche se si è già un amministratore di Windows.

  • Se si utilizza la funzionalità di creazione di ticket SSO, è necessario utilizzare account di dominio riconosciuti dai computer del dominio che esegue l'elaborazione, ovvero il dominio in cui si trovano i server SSO.

  • È consigliabile usare un account di servizio univoco per il servizio SSO corrispondente al server segreto master.

  • L'account amministratore SSO è un account con privilegi elevati nel sistema SSO, che è anche l'account amministratore SQL Server per il server SQL con il database SSO. È preferibile utilizzare account dedicati per gli amministratori SSO da non utilizzare per altri scopi. È consigliabile limitare l'appartenenza al gruppo SSO Administrators solo a tali account responsabili dell'esecuzione e della gestione del sistema SSO.

Consigli sulla sicurezza per una distribuzione SSO

  • Se la rete in uso supporta l'autenticazione Kerberos, è necessario registrare tutti i server SSO. Quando si utilizza l'autenticazione Kerberos tra il server master secret e il database SSO, è necessario configurare i nomi dell'entità servizio nel server SQL in cui si trova il database SSO.

  • Quando si esegue Windows Server 2003, se il server segreto master si trova in un dominio diverso dagli altri server SSO e dal database SSO, è necessario disabilitare la sicurezza RPC (come usato per l'autenticazione DTC) di Data Transaction Coordinator (DTC) nel server segreto master, nei server SSO (elaborazione computer nel dominio di elaborazione), e nel database SSO. La sicurezza RPC è una nuova funzionalità DTC in Windows Server 2003. Quando si disabilita la sicurezza RPC, il livello di sicurezza di autenticazione DTC per le chiamate RPC torna a uno disponibile in Microsoft Windows. Per altre informazioni sulla disabilitazione della sicurezza RPC, vedere Guida e supporto tecnico Microsoft.

  • È consigliabile che gli amministratori SSO controllino regolarmente nel registro eventi del server master secret e del server SSO la presenza di eventi di controllo SSO.

  • Oltre ai firewall, è consigliabile usare sicurezza del protocollo Internet (IPsec) o Secure Sockets Layer (SSL) tra tutti i server SSO e il database SSO. Per altre informazioni su SSL, vedere Guida e supporto tecnico Microsoft.

Rete perimetrale

Quando si esegue Internet Information Services (IIS) ed Enterprise Single Sign-On, attenersi alle indicazioni seguenti:

  • Se IIS si trova in una rete perimetrale (nota anche come subnet schermata), fornire un altro server che esegue IIS dietro il firewall per connettersi al sistema SSO.

  • Non aprire la porta RPC (Remote Procedure Call) in IIS.

Accesso a SQL Server

Tutti i server SSO accedono al database SQL Server credenziali.

Microsoft consiglia di usare Secure Sockets Layer (SSL) e/o Internet Protocol security (IPsec) per proteggere la trasmissione dei dati tra i server SSO e il database delle credenziali. Per altre informazioni sull'uso di SSL, vedere Guida e supporto tecnico Microsoft.

Per abilitare SSL solo per la connessione tra il server SSO e il database Credential, è possibile impostare il supporto SSL in ogni server SSO usando l'utilità ssoconfig. Questa opzione consente a SSO di usare sempre SSL quando si accede al database Credential. Per altre informazioni, vedere Come abilitare SSL for Enterprise Single Sign-On.

Password complesse

È molto importante utilizzare password complesse per tutti gli account, in particolare per gli account che sono membri del gruppo Amministratori SSO, in quanto questi utenti hanno il controllo dell'intero sistema SSO.

Account degli amministratori SSO

È consigliabile usare account di servizio diversi per i servizi SSO in esecuzione in computer diversi. Non è consigliabile utilizzare l'account dell'amministratore SSO che esegue operazioni di amministrazione quali la generazione e il backup del master secret per il servizio SSO. Anche se gli account del servizio SSO non devono essere amministratori locali nel computer, l'amministratore SSO che esegue le operazioni di amministrazione deve essere un amministratore locale nel computer per alcune operazioni.

Server master secret

È consigliabile proteggere e bloccare il server segreto master. Non utilizzare questo server come server di elaborazione. L'unica funzione di questo server dovrebbe essere quella di conservare il master secret. È necessario assicurare la sicurezza fisica di tale computer e limitarne l'accesso solo agli amministratori SSO.

Kerberos

SSO supporta Kerberos e si consiglia di configurare Kerberos per l'accesso SSO. Per configurare Kerberos con SSO, è necessario registrare un nome SPN per il servizio SSO. Per impostazione predefinita, quando si configura Kerberos, l'accesso SSO usa tale spN per autenticare i componenti usando il servizio SSO. È consigliabile configurare l'autenticazione Kerberos tra i servizi secondari amministrativi SSO e il server SSO. È anche possibile usare l'autenticazione Kerberos tra i server SSO e tra i server SSO e la SQL Server in cui è il database Credential.

Per configurare e verificare Kerberos, usare i set di utilitàpn e kerbtray.

Delegation

Quando si usa Windows Server 2003, è possibile usare la delega vincolata, ma è consigliabile non usare la delega per eseguire le attività dell'amministratore single Sign-On. Analogamente, è consigliabile non delegare attività aggiuntive o diritti utente all'amministratore single Sign-On.

Controllo

Il controllo è un meccanismo fondamentale per tenere traccia delle informazioni all'interno di un ambiente. Enterprise Single Sign-On (SSO) controlla tutte le operazioni eseguite nel database Credential. Utilizza i registri eventi e i log di controllo del database stesso e fornisce due tipi di livelli di controllo per i server Single Sign-On:

  • I livelli di controllo positivi controllano le operazioni riuscite.

  • Operazioni di controllo negative dei livelli di controllo che hanno esito negativo.

    Gli amministratori SSO possono impostare i livelli di controllo positivi e negativi più adatti ai criteri aziendali.

    I controlli positivi e negativi possono essere impostati su uno dei livelli seguenti:

  • 0 = Nessuno: questo livello non genera messaggi di controllo.

  • 1 = Basso

  • 2 = Medio

  • 3 = Alto : questo livello genera il maggior numero possibile di messaggi di controllo.

    Il valore predefinito per il controllo positivo è 0 (nessuno) e il valore predefinito per il controllo negativo è 1(basso). È possibile modificare questi valori a seconda dal livello di controllo che si desidera applicare al sistema SSO.

Importante

Enterprise Single Sign-On auditing genera messaggi generati dal servizio Single Sign-On. Non si tratta di un controllo di sicurezza e il sistema SSO non salva le informazioni nel log di sicurezza del registro eventi. Il sistema SSO salva i messaggi di controllo SSO direttamente nel registro eventi dell'applicazione.

Controllo a livello di database

Per il controllo a livello di database, il sistema SSO tiene traccia delle operazioni eseguite nel database Credential nelle tabelle di controllo nel database. Le dimensioni di queste tabelle di controllo sono definite a livello di sistema SSO. È possibile controllare le applicazioni affiliate eliminate, i mapping eliminati e le ricerche di credenziali eseguite. Per impostazione predefinita, la dimensione del controllo è impostata su 1000 voci. Gli amministratori SSO possono modificare questa dimensione in base ai criteri aziendali.

Uso di account di Sign-On aziendali

Questa sezione contiene procedure consigliate quando si usano gruppi di dominio e gruppi locali e singoli account nel sistema Enterprise Single Sign-On (SSO).

Gruppi e account di dominio di Windows

Quando si lavora con i gruppi di Windows di dominio, si applicano le raccomandazioni seguenti:

  • Utilizzare i gruppi di dominio e gli account di dominio.

  • Utilizzare un gruppo di dominio per gli amministratori SSO. Non è consigliabile specificare un account di dominio singolo come amministratore SSO, in quanto non è possibile sostituire questo account con un altro.

  • Sebbene sia possibile specificare un account di dominio singolo come amministratore di applicazioni affiliate SSO, è necessario utilizzare un gruppo di dominio.

  • Sebbene sia possibile specificare un account di dominio singolo come amministratore dell'applicazione, è preferibile utilizzare un gruppo di dominio.

  • È necessario usare i gruppi di dominio per l'account utenti dell'applicazione. L'account utenti delle applicazioni SSO non supporta un singolo account.

Vedere anche

Come controllare l'accesso Single Sign-On enterprise
Come aggiornare il database delle credenziali