Consigli sulla sicurezza per SSO

Con il sistema Enterprise Single Sign-On (SSO), gli utenti possono connettersi a sistemi diversi usando un solo set di credenziali. BizTalk Server sfrutta il sistema SSO come archivio per informazioni riservate. Anche se BizTalk Server installa automaticamente ogni volta che si installa il runtime di BizTalk Server, è anche possibile installare Enterprise Single Sign-On come componente autonomo, indipendentemente dall'ambiente BizTalk Server. Per altre informazioni sull'accesso Single Sign-On Enterprise, vedere Uso dell'accesso SSO. È consigliabile attenersi alle linee guida per la sicurezza e la distribuzione dei servizi e delle risorse di Enterprise Single Sign-On (SSO) nell'ambiente in uso.

Consigli generali sulla distribuzione di SSO

• Nell'intero ambiente devono essere presenti un solo server master secret e un solo database SSO, anche se sono presenti più gruppi BizTalk. È necessario configurare questi due server prima di configurare qualsiasi altro server BizTalk e SSO.

• L'ambiente deve comprendere un server di riferimento ora per garantire la sincronizzazione di tutti i server SSO. Se gli orologi dei server SSO non sono sincronizzati, la sicurezza dell'ambiente potrebbe risultare compromessa.

• Dal momento che è presente un solo server master secret in tutto l'ambiente, è consigliabile utilizzare una configurazione cluster attivo-passivo per tale server. 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 master secret contiene la chiave di crittografia utilizzata dal sistema SSO per crittografare le informazioni del database SSO. Non è consigliabile installare o configurare altri prodotti o servizi in questo 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 utilizza un supporto rimovibile, verificare di aver applicato le misure appropriate per garantirne la sicurezza. Se si esegue il backup del master secret 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, in modo che sia possibile ripristinare i dati del database SSO in caso di problemi del server master secret. Per altre informazioni sul backup del segreto master, vedere Gestione del segreto master.

• Eseguire il backup del master secret corrente o generare un nuovo master secret regolarmente, 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 utilizzare i gruppi di Windows anziché account utente singoli, in particolare per i gruppi Amministratori SSO e Amministratori applicazioni affiliate 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 amministratori SSO che eseguono attività amministrative quali la generazione e il backup del master secret devono essere amministratori di Windows, mentre non è necessario che gli account di servizio del runtime SSO siano amministratori di Windows.

  Importante

  I diritti utente degli amministratori di Windows non prevalgono su quelli dell'amministratore SSO. Per eseguire qualsiasi attività di amministrazione di SSO, è necessario essere membri del gruppo Amministratori SSO anche se si è già amministratori 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 utilizzare un account utente univoco per il servizio SSO corrispondente al server master secret.

• L'account dell'amministratore SSO è un account con privilegi elevati nel sistema SSO e corrisponde all'account dell'amministratore di SQL Server per il server SQL in cui si trova il database SSO. È preferibile utilizzare account dedicati per gli amministratori SSO da non utilizzare per altri scopi. È consigliabile limitare l'appartenenza al gruppo Amministratori SSO solo agli account responsabili dell'esecuzione e della gestione del sistema SSO.

• È necessario aggiungere manualmente il gruppo Amministratori BizTalk al gruppo Amministratori applicazioni affiliate SSO in modo che gli amministratori di BizTalk possano utilizzare il sistema SSO per salvare le informazioni di configurazione degli adapter nel database SSO. Solo gli amministratori BizTalk che gestiscono adapter devono essere membri del gruppo Amministratori applicazioni affiliate SSO. Non è necessario che gli amministratori BizTalk siano amministratori 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. Per altre informazioni sulla configurazione dei nomi dell'entità servizio, passare a Nomi entità servizio (SPN).

• Quando si esegue Windows Server 2008 SP2 o Windows Server 2008 R2, se il server segreto master si trova in un dominio diverso dagli altri server SSO e dal database SSO, è necessario disabilitare la sicurezza RPC (utilizzata per l'autenticazione DTC) di Data Transaction Coordinator (DTC) nel server segreto master, nei server SSO (computer di elaborazione nel dominio di elaborazione), e nel database SSO. La sicurezza RPC è una funzionalità DTC in Windows Server 2008 SP2 e Windows Server 2008 R2. Quando si disabilita la sicurezza RPC, il livello di sicurezza dell'autenticazione DTC per le chiamate RPC torna a essere uno dei livelli disponibili in Microsoft Windows Server 2003.

• È 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 utilizzare Internet Protocol Security (IPSec) o Secure Sockets Layer (SSL) tra tutti i server SSO e il database SSO. Per altre informazioni sull'uso di SSL, vedere Abilitare le connessioni crittografate al motore di database. Per altre informazioni sull'uso di SSL tra tutti i server SSO e il database SSO, vedere Come abilitare SSL per l'accesso SSO.

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, è necessario inserire un altro server IIS oltre 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 SSO di SQL Server. Per altre informazioni su come proteggere i database SQL Server, vedere Protezione SQL Server.

È consigliabile utilizzare Secure Sockets Layer (SSL) e/o Internet Protocol Security (IPSec) per proteggere la trasmissione di dati tra i server SSO e il database SSO. Per altre informazioni sull'uso di SSL, vedere Abilitare le connessioni crittografate al motore di database.

Per abilitare SSL solo per la connessione tra il server SSO e il database SSO, è possibile impostare il supporto SSL in tutti i server SSO tramite l'utilità ssoconfig. Questa opzione consente a SSO di utilizzare sempre SSL per l'accesso al database SSO. Per altre informazioni, vedere Come abilitare SSL per l'accesso SSO.

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 utilizzare account di servizio diversi per i servizi SSO che vengono eseguiti 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. Gli account di servizio SSO non dovrebbero essere amministratori locali del computer in uso, tuttavia l'amministratore SSO che esegue le operazioni di amministrazione deve essere un amministratore locale del computer per eseguire alcune operazioni.

Server master secret

È consigliabile proteggere e bloccare il server master secret. 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 la configurazione di Kerberos per SSO è un'operazione consigliata. Per configurare Kerberos con SSO, è necessario registrare un nome SPN per il servizio SSO. Per impostazione predefinita, quando si configura Kerberos, SSO utilizza il nome SPN per autenticare i componenti tramite il servizio SSO. È consigliabile configurare l'autenticazione Kerberos tra i servizi secondari amministrativi SSO e il server SSO. È inoltre possibile utilizzare l'autenticazione Kerberos tra i server SSO e tra i server SSO e il server SQL in cui si trova il database SSO.

Per altre informazioni, vedere:

• Nomi dell'entità servizio (SPN)
• Registrazione di un nome dell'entità servizio per le connessioni Kerberos

Delegation

Quando si usa Windows Server 2008 SP2 o Windows Server 2008 R2, è possibile usare la delega vincolata, ma è consigliabile non usare la delega per eseguire le attività di Single Sign-On Administrator. In modo analogo, non è consigliabile delegare attività o diritti utente aggiuntivi 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 SSO. 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

• I livelli di controllo negativi controllano le operazioni non riuscite

  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 alcun messaggio di controllo

  1 = Basso

  2 = Medio

  3 = Alto. Questo livello genera il numero massimo di messaggi di controllo

  Il valore predefinito per i controlli positivi è 0 (nessuno), mentre il valore predefinito per i controlli negativi è 1 (basso). È possibile modificare questi valori a seconda dal livello di controllo che si desidera applicare al sistema SSO.

Controllo a livello di database

Per il controllo a livello di database, il sistema SSO tiene traccia delle operazioni eseguite nelle tabelle di controllo del database SSO. Le dimensioni di tali tabelle vengono 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 1.000 voci. Gli amministratori SSO possono modificare questa dimensione in base ai criteri aziendali.

Utilizzo di account SSO

In questa sezione vengono descritte le procedure consigliate quando si utilizzano gruppi di dominio e locali e account singoli nel sistema Enterprise Single Sign-On (SSO).

Gruppi e account di dominio di Windows

Quando si utilizzano i gruppi di dominio di Windows, è necessario attenersi alle indicazioni seguenti:

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

• Quando si usa Windows Server 2008 SP2 o Windows Server 2008 R2the ENTSSO service account può essere configurato per l'esecuzione nell'account del servizio di rete. Questa operazione è tuttavia sconsigliata per motivi di sicurezza, in quanto l'account Servizio di rete deve disporre del privilegio Amministratori SSO. È invece consigliabile utilizzare un account di servizio di dominio univoco per l'account del servizio ENTSSO.

• 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 utilizzare i gruppi di dominio per l'account utente dell'applicazione. L'account utente delle applicazioni SSO non supporta un account singolo.

• È possibile specificare più account per ognuno degli account di accesso SSO.

Vedere anche

Porte per i server single Sign-On enterprisediritti utente di sicurezza minimi