Autenticazione e crittografia dei dati in Operations Manager
System Center Operations Manager è costituito da funzionalità quali il server di gestione, il server gateway, il server di report, il database operativo, il data warehouse di reporting, l'agente, la console Web e la console operatore. Questo articolo illustra come viene eseguita l'autenticazione e identifica i canali di connessione in cui vengono crittografati i dati.
Autenticazione basata sui certificati
Quando un agente e un server di gestione di Operations Manager sono separati da una foresta non attendibile o da un limite del gruppo di lavoro, è necessario implementare l'autenticazione basata su certificati. Nelle seguenti sezioni vengono descritte le procedure necessarie per ottenere e installare i certificati delle autorità di certificazione basate su Windows.
Configurare la comunicazione tra agenti e server di gestione all'interno dello stesso limite di attendibilità
L'autenticazione Windows consente l'autenticazione reciproca tra un agente e un server di gestione affinché il server di gestione sia in grado di accettare i dati dall'agente. Il metodo di autenticazione predefinito è costituito dal protocollo Kerberos versione 5. Per il corretto funzionamento dell'autenticazione reciproca basata su Kerberos, è necessario che gli agenti e il server di gestione siano installati in un dominio di Active Directory. Se un agente e un server di gestione si trovano in domini distinti, tra i domini deve esistere una relazione di trust totale. In questo caso, a seguito dall'autenticazione reciproca, il canale dati tra l'agente e il server di gestione viene crittografato. Per l'autenticazione e la crittografia non è necessario l'intervento dell'utente.
Configurare la comunicazione tra agenti e server di gestione attraverso i limiti di attendibilità
È possibile che uno o più agenti siano distribuiti in un dominio (dominio B) distinto da quello del server di gestione (dominio A) e che tra i domini non esista un trust bidirezionale. Poiché non esiste alcuna relazione di trust tra i due domini, gli agenti in un dominio non possono eseguire l'autenticazione con il server di gestione nell'altro dominio usando il protocollo Kerberos. L'autenticazione reciproca tra le funzionalità di Operations Manager all'interno di ogni dominio si verifica ancora.
Per consentire l'autenticazione reciproca e la crittografia dei dati, è necessario installare un server gateway nello stesso dominio degli agenti e installare certificati nel server gateway e nel server di gestione. Se si utilizza un server gateway, sono necessari solo un certificato nel dominio B e una porta di accesso attraverso il firewall, come mostrato nella seguente illustrazione.
Configurare la comunicazione tra un dominio - Limite del gruppo di lavoro
È possibile che nel proprio ambiente uno o più agenti siano distribuiti in un gruppo di lavoro all'interno del firewall. L'agente nel gruppo di lavoro non può eseguire l'autenticazione con il server di gestione nel dominio usando il protocollo Kerberos. La soluzione al problema consiste nell'installazione dei certificati sia nel computer che ospita l'agente sia in quello che ospita il server di gestione al quale l'agente si connette, come mostrato nella seguente illustrazione.
Nota
In questo scenario, è necessario installare l'agente manualmente.
Effettuare le seguenti operazioni sia nel computer nel quale risiede l'agente che in quello del server di gestione utilizzando la stessa autorità di certificazione (CA).
- Richiedere i certificati dalla CA.
- Approvare le richieste di certificati sulla CA.
- Installare i certificati approvati negli archivi di certificati dei computer.
- Usare lo strumento MOMCertImport per configurare Operations Manager.
Nota
I certificati con KEYSPEC diversi da 1 non sono supportati.
Questi sono gli stessi passaggi per l'installazione dei certificati in un server gateway, ad eccezione dell'installazione o dell'esecuzione dello strumento di approvazione del gateway
Confermare l'installazione del certificato
Se il certificato è stato installato correttamente, l'evento seguente viene scritto nel registro eventi di Operations Manager.
Type | Origine | ID evento | Generali |
---|---|---|---|
Informazioni | OpsMgr Connector | 20053 | OpsMgr Connector ha caricato il certificato di autenticazione specificato. |
Durante l'installazione di un certificato, eseguire lo strumento MOMCertImport. Al termine del processo dello strumento MOMCertImport, il numero di serie del certificato importato viene scritto nella sottochiave indicata di seguito del Registro di sistema.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
Attenzione
È possibile che eventuali modifiche non corrette del Registro di sistema danneggino gravemente il sistema. Prima di apportare modifiche al Registro di sistema, si consiglia di effettuare il backup di tutti i dati importanti presenti sul computer.
Autenticazione e crittografia dei dati tra server di gestione, server gateway e agenti
Le comunicazioni tra queste funzionalità di Operations Manager hanno inizio con l'autenticazione reciproca. Se a entrambe le estremità del canale di comunicazione sono presenti certificati, questi vengono utilizzati per l'autenticazione reciproca. In caso contrario viene utilizzato il protocollo Kerberos versione 5. Se due funzionalità sono separate da un dominio non trusted, è necessario effettuare l'autenticazione reciproca utilizzando i certificati. Le normali comunicazioni, quali eventi, avvisi e distribuzione di Management Pack avvengono grazie a questo canale. L'illustrazione precedente mostra un esempio di avviso generato su uno degli agenti e inoltrato al server di gestione. Per la crittografia dei dati dall'agente al server gateway viene utilizzato il pacchetto di protezione Kerberos, perché il server gateway e l'agente risiedono nello stesso dominio. L'avviso viene decrittografato dal server gateway e ricrittografato utilizzando i certificati relativi al server di gestione. Il server gateway invia il messaggio crittografato al server di gestione in cui il server di gestione decrittografa l'avviso. Alcune comunicazioni tra il server di gestione e l'agente possono includere informazioni sulle credenziali, ad esempio i dati di configurazione e le attività. Il canale dati tra l'agente e il server di gestione aggiunge un altro livello di crittografia a quella normalmente utilizzata per il canale. Non è necessario alcun intervento dell'utente.
Server di gestione e Console operatore, server console Web e server di report
L'autenticazione e la crittografia dei dati tra il server di gestione e la console operatore, il server della console Web o il server di report viene eseguita tramite la tecnologia Windows Communication Foundation (WCF). Il tentativo iniziale di autenticazione viene eseguito utilizzando le credenziali dell'utente. Viene innanzitutto effettuato un tentativo con il protocollo Kerberos. Se il protocollo Kerberos non funziona, viene eseguito un altro tentativo usando NTLM. Se l'autenticazione ancora non riesce, viene richiesto all'utente di fornire le proprie credenziali. Dopo aver eseguito l'autenticazione, il flusso di dati viene crittografato come funzione del protocollo Kerberos o SSL se viene usato NTLM.
Nel caso di un server di report e di un server di gestione, dopo l'autenticazione, viene stabilita una connessione dati tra il server di gestione e SQL Server Reporting Server. Poiché la connessione prevede unicamente l'utilizzo del protocollo Kerberos, è necessario che il server di gestione e il server di report risiedano in domini trusted. Per ulteriori informazioni su WCF, vedere l'articolo MSDN Informazioni su Windows Communication Foundation.
Server di gestione e data warehouse di report
Tra un server di gestione e un data warehouse per reporting esistono due canali di comunicazione:
- Il processo host di monitoraggio generato dal servizio integrità di gestione di System Center in un server di gestione
- I servizi di System Center Data Access nel server di gestione
Processo host di monitoraggio e data warehouse per reporting
Per impostazione predefinita, il processo host di monitoraggio generato dal Servizio integrità, responsabile della scrittura degli eventi raccolti e dei contatori delle prestazioni nel data warehouse, consegue l'autenticazione integrata di Windows perché viene eseguito con l'account scrittura dati specificato durante l'installazione del componente di report. Le credenziali dell'account vengono memorizzate in modo protetto in un account RunAs denominato Account azione data warehouse. Tale account RunAs è assegnato al profilo RunAs denominato Account data warehouse, associato con le regole di raccolta in vigore.
Se il data warehouse di report e il server di gestione sono separati da un limite di attendibilità (ad esempio, ognuno si trova in domini diversi senza attendibilità), l'autenticazione integrata di Windows non funzionerà. Per risolvere questo problema, il processo host di monitoraggio può connettersi al data warehouse per reporting utilizzando l'autenticazione SQL Server. A questo scopo, creare un nuovo account RunAs, di tipo account semplice, con le credenziali dell'account SQL, e assegnarlo al profilo RunAs denominato Account di autenticazione di SQL Server per il data warehouse, indicando il server di gestione come computer di destinazione.
Importante
Per impostazione predefinita, al profilo RunAs Account di autenticazione di SQL Server per il data warehouse viene assegnato un account specifico utilizzando l'account RunAs con lo stesso nome. Non apportare mai modifiche all'account associato al profilo RunAs Account di autenticazione di SQL Server per il data warehouse. È consigliabile creare, invece, un proprio account e un proprio account RunAs e assegnare quest'ultimo al profilo RunAs Account di autenticazione di SQL Server per il data warehouse, quando si configura l'autenticazione SQL Server.
Di seguito vengono descritte le relazioni esistenti tra le credenziali dei diversi account, account RunAs e profili RunAs sia per l'autenticazione integrata di Windows sia per l'autenticazione SQL Server.
Predefinito: Autenticazione integrata di Windows
Profilo RunAs: account data warehouse
- Account RunAs: Azione data warehouse
- Credenziali dell'account: account writer di dati (specificato durante l'installazione)
Profilo RunAs: account di autenticazione di SQL Server per il data warehouse
- Account RunAs: autenticazione di SQL Server di Data Warehouse
- Credenziali dell'account: account speciale creato da Operations Manager (non modificare)
Facoltativo: autenticazione SQL Server
- Profilo RunAs: Account di autenticazione di SQL Server di Data Warehouse
- Account RunAs: un account RunAs specificato durante l'installazione.
- Credenziali dell'account: un account specificato durante l'installazione.
Il servizio di accesso ai dati di System Center e il data warehouse di reporting
Per impostazione predefinita, il servizio di accesso ai dati di System Center, responsabile della lettura dei dati dal data warehouse di reporting e della sua disponibilità nell'area dei parametri del report, ottiene l'autenticazione integrata di Windows eseguendo come account del servizio di accesso ai dati e del servizio di configurazione definito durante l'installazione di Operations Manager.
Se il data warehouse di report e il server di gestione sono separati da un limite di attendibilità (ad esempio, ognuno si trova in domini diversi senza attendibilità), l'autenticazione integrata di Windows non funzionerà. Per risolvere questo problema, il servizio di accesso ai dati di System Center può connettersi al data warehouse per reporting utilizzando l'autenticazione SQL Server. A questo scopo, creare un nuovo account RunAs, di tipo account semplice, con le credenziali dell'account SQL e assegnarlo al profilo RunAs denominato Account di autenticazione di SQL Server per l'SDK di report, indicando il server di gestione come computer di destinazione.
Importante
Per impostazione predefinita, al profilo RunAs, account di autenticazione di SQL Server per l'SDK dei report viene assegnato un account specifico utilizzando l'account RunAs con lo stesso nome. Non apportare mai modifiche all'account associato al profilo RunAs, l'account di autenticazione di SQL Server di Reporting SDK. È consigliabile creare, invece, un proprio account e un proprio account RunAs e assegnare quest'ultimo al profilo RunAs, account di autenticazione di SQL Server per l'SDK dei report, quando si configura l'autenticazione SQL Server.
Di seguito vengono descritte le relazioni esistenti tra le credenziali dei diversi account, account RunAs e profili RunAs sia per l'autenticazione integrata di Windows sia per l'autenticazione SQL Server.
Predefinito: Autenticazione integrata di Windows
Account di Data Access Service e del servizio di configurazione (definito durante l'installazione di Operations Manager)
- Profilo RunAs: Account di autenticazione di SQL Server per l'SDK dei report
- Account RunAs Account di autenticazione di SQL Server per l'SDK dei report
- Credenziali dell'account: account speciale creato da Operations Manager (non modificare)
Facoltativo: autenticazione SQL Server
- Profilo RunAs: account di autenticazione di SQL Server per il data warehouse
- Account RunAs: un account RunAs specificato durante l'installazione.
- Credenziali dell'account: un account specificato durante l'installazione.
Console operatore e server di report
La Console operatore consente di connettersi al server di report utilizzando la porta 80 tramite HTTP. L'autenticazione viene eseguita usando l'autenticazione di Windows. I dati sono crittografati utilizzando il canale SSL.
Server di report e data warehouse di report
L'autenticazione tra il server di report e il data warehouse per reporting viene effettuata mediante l'autenticazione di Windows. L'account specificato come account lettore dati durante l'installazione del componente di report diventa l'account di esecuzione del server di report. Se la password per l'account deve cambiare, sarà necessario apportare la stessa modifica della password usando Gestione configurazione Reporting Services in SQL Server. I dati tra il server di report e il data warehouse di report non vengono crittografati.