Considerazioni sulla sicurezza

Il protocollo di autenticazione Kerberos, supportato dai controller di dominio Windows 2000 e precedenti, è applicabile solo all'interno di un confine del trust. L'autenticazione Kerberos è il meccanismo utilizzato per l'autenticazione reciproca tra agenti e server di Operations Manager. L'autenticazione reciproca è obbligatoria per la comunicazione tra agenti e server di Shell di Operations Manager.

Un gruppo di gestione di Operations Manager ha la possibilità di eseguire l'individuazione e il monitoraggio al di fuori del limite di trust Kerberos in esso contenuto. Poiché, tuttavia, il protocollo di autenticazione predefinito per i computer basati su Windows e non inseriti in un dominio Active Directory è NTLM, per l'autenticazione reciproca è necessario utilizzare un altro meccanismo. Questo è costituito dalla scambio di certificati tra agenti e server.

Quando le comunicazioni di Operations Manager devono attraversare i confini del trust, ad esempio quando un server da monitorare si trova in un dominio Active Directory non trusted diverso da quello del gruppo di gestione che esegue il monitoraggio, è possibile soddisfare il requisito di autenticazione reciproca utilizzando i certificati. Con la configurazione manuale è possibile ottenere i certificati e associarli ai computer e ai servizi di Operations Manager in esecuzione su di essi. Quando un servizio che deve comunicare con un altro, situato in un computer diverso, viene avviato e tenta di ottenere l'autenticazione, l'autenticazione reciproca viene completata con lo scambio dei certificati.

Importante
I certificati utilizzati a questo scopo devono avere una relazione di trust con la stessa autorità di certificazione principale (CA).

Per ulteriori informazioni su come ottenere e utilizzare i certificati per l'autenticazione, vedere Distribuzione di un server gateway.

Sono disponibili quattro tipi di CA Microsoft:

• CA globale principale

• CA globale subordinata

• CA autonoma principale

• CA autonoma subordinata

• Entrambi i tipi di CA globale richiedono i servizi di dominio Active Directory, mentre le CA autonome non li richiedono. Ogni tipo di CA può produrre i certificati necessari per la reciproca autenticazione tra agenti e server attraverso i confini del trust.

Un'infrastruttura CA è costituita da una CA radice, che firma i propri certificati e certifica se stessa, e da una o più CA subordinate, certificate dalla CA radice. I server delle CA subordinate sono quelli ai quali vengono richiesti i certificati di servizio, mentre la CA radice rimane offline per motivi di sicurezza. Per ulteriori informazioni sulla progettazione dei certificati, vedere Infrastructure Planning and Design (Pianificazione e progettazione di infrastrutture) e Autenticazione e crittografia dei dati per i computer Windows.

L'Individuazione guidata consente di riconoscere i computer UNIX e Linux e di aggiungerli al gruppo di gestione come oggetti gestiti. Durante il processo di individuazione guidata, Operations Manager fa sì che i computer UNIX e Linux individuati generino un certificato autofirmato utilizzato per l'autenticazione reciproca con il server di gestione. La generazione del certificato, la firma e il processo di scambio operano analogamente a quanto avviene attivando l'individuazione SSH:

1. Il processo di individuazione guidata del server di gestione fa sì che i computer UNIX o Linux individuati generino un certificato autofirmato.

2. Il server di gestione che effettua l'individuazione invia una richiesta di certificato al computer UNIX o Linux.

3. Il computer UNIX o Linux restituisce il certificato al server di gestione

4. Il server di gestione di individuazione crea autonomamente una coppia di chiavi e un certificato autofirmato. Il server di gestione genera una coppia di chiavi e un certificato autofirmato solo quando individua il primo computer UNIX o Linux. Il server di gestione importa, quindi, il certificato nell'archivio dei certificati trust. Il server di gestione che esegue l'individuazione firma quindi il certificato UNIX o Linux con la propria chiave privata. Ad ogni firma successiva di certificati dei computer UNIX o Linux, il server di gestione riutilizza la chiave privata generata al momento della prima firma.

5. Il server di gestione di individuazione emette una richiesta di immissione del certificato che reimmette il certificato, ora firmato dal server di gestione, nel computer UNIX o Linux che l'ha generato inizialmente. Per attivare il certificato generato dal computer, il layer delle comunicazioni WSMAN dei computer UNIX o Linux viene quindi riavviato.

6. Quando il server di gestione richiede che il computer UNIX o Linux autentichi se stesso, quest'ultimo fornisce al server un certificato trust. Il server di gestione legge la firma sul certificato ricevuto e accerta l'attendibilità della firma (che è costituita dalla sua stessa chiave privata, memorizzata nell'archivio certificati trust) e accetta il certificato come prova che il computer UNIX o LINUX è quello identificato dal server di gestione.

7. Per autenticare se stesso con il computer UNIX o Linux, il server di gestione che esegue l'individuazione utilizzerà le credenziali UNIX o Linux configurate nel profilo RunAs appropriato. Per ulteriori dettagli, vedere la sezione Pianificazione dei profili RunAs per UNIX o Linux.

Importante
L'ordine delle operazioni, riportato in precedenza, si riferisce all'individuazione di UNIX o Linux nella versione meno sicura.

Quando i computer UNIX o Linux sono gestiti dal server di gestione che esegue l'individuazione, viene avviata l'esecuzione delle individuazioni e dei flussi di lavoro dei Management Pack. Per il completamento dei flussi di lavoro è necessario utilizzare le credenziali. Indipendentemente dagli oggetti, dalle classi o dai gruppi ai quali vengono applicate e ai computer ai quali vengono distribuite, tali credenziali sono contenute nei profili RunAs. Quando si importano i Management Pack UNIX nel gruppo di gestione, vengono importati anche i due profili RunAs indicati di seguito.

• Profilo Account azione UNIX: questo profilo RunAs e le relative credenziali UNIX o Linux vengono utilizzati per attività meno sicure nei computer UNIX o Linux specificati.

• Profilo Account privilegiato UNIX: questo profilo RunAs e le relative credenziali UNIX o Linux vengono utilizzati per attività ad elevato livello di sicurezza e, di conseguenza, richiedono un account con privilegi superiori nel computer UNIX o Linux. Può trattarsi, anche se non necessariamente, dell'account root.

Per il corretto funzionamento, è necessario configurare tali profili con le credenziali del computer UNIX o Linux appropriate per i flussi di lavoro del Management Pack in cui vengono utilizzati.

Operations Manager controlla l'accesso a gruppi, attività e visualizzazioni monitorati, nonché a funzioni amministrative mediante l'assegnazione degli account utente ai ruoli. Un ruolo di Operations Manager è rappresentato da una combinazione del tipo di profilo, ad esempio operatore, operatore avanzato, amministratore, e dell'ambito, determinato dai dati ai quali il ruolo ha accesso. I gruppi di protezione di Active Directory, in genere, sono assegnati ai ruoli e, successivamente, i singoli account vengono assegnati a tali gruppi. Prima della distribuzione, pianificare i gruppi di protezione di Active Directory da aggiungere e gli eventuali ruoli personalizzati in modo che sia possibile poi aggiungere i singoli account utente ai gruppi di protezione.

Operations Manager offre le seguenti definizioni di ruoli predefinite.

È possibile aggiungere i gruppi di protezione o i singoli account di Active Directory a qualsiasi ruolo predefinito. In questo caso, i soggetti saranno in grado di esercitare i privilegi di uno specifico ruolo sugli oggetti previsti dall'ambito.

Operations Manager consente inoltre di creare ruoli personalizzati in base ai profili Operatore, Operatore di sola lettura, Autore e Operatore avanzato. Durante la creazione del ruolo è possibile limitare ulteriormente l'ambito di gruppi, attività e visualizzazioni cui il ruolo può accedere. È possibile, ad esempio, creare un ruolo denominato "Operatore Exchange" e limitarne l'ambito solo ai gruppi, alle visualizzazioni e alle attività relativi a Exchange. Gli account utente assegnati a questo ruolo avranno la possibilità di eseguire soltanto azioni a livello di operatore sugli oggetti relativi a Exchange.

I dipendenti della società che desiderino interagire spesso con Operations Manager, ad esempio un amministratore di Exchange al quale sia stato assegnato il ruolo di Operatore Exchange, hanno l'esigenza di individuare i nuovi avvisi. Questa operazione può essere eseguita osservando l’eventuale presenza di nuovi avvisi nella console operatore o facendo in modo che Operations Manager ne dia informazione attraverso canali di comunicazione supportati.Operations Manager supporta le notifiche tramite posta elettronica, messaggistica istantanea, SMS o messaggi di cercapersone. Le notifiche relative alle informazioni necessarie al ruolo sono dirette ai destinatari specificati in Operations Manager. Un destinatario di Operations Manager non è altro che un oggetto con un indirizzo valido per la ricezione della notifica, ad esempio un indirizzo SMTP per le notifiche via posta elettronica.

Pertanto è logico combinare l'assegnazione del ruolo con l'appartenenza al gruppo di notifica mediante un gruppo di protezione abilitato alla ricezione di posta elettronica. Creare, ad esempio, un gruppo di protezione Amministratori di Exchange e associare al gruppo le persone dotate delle conoscenze e delle autorizzazioni necessarie per risolvere eventuali problemi con Exchange. Assegnare il gruppo di protezione a un ruolo personalizzato Amministratore di Exchange in modo da consentirne l'accesso ai dati e la possibilità di utilizzare la posta elettronica. Creare quindi un destinatario utilizzando l'indirizzo SMTP del gruppo di protezione abilitato allo scambio di messaggi di posta elettronica.

In fase di distribuzione, è necessario disporre dei seguenti account di servizio. Se si utilizzano gli account di dominio e se per il proprio oggetto Criteri di gruppo dominio (GPO) è impostato il criterio obbligatorio e predefinito di scadenza della password, è necessario poter modificare le password degli account di servizio secondo la pianificazione oppure utilizzare account di sistema a manutenzione ridotta o configurare gli account in modo che le password non abbiano scadenza.

Quando si distribuisce Operations Manager, potrebbe essere necessario registrare un nome principale servizio (SPN) in alcune configurazioni. Gli SPN vengono utilizzati dall'autenticazione Kerberos per consentire al client di autenticarsi reciprocamente con il server. Per ulteriori informazioni, vedere What Are Service Publication and Service Principal Names? (Che cosa sono la pubblicazione dei servizi e i nomi principali di servizio?).

Quando si installa Operations Manager, si seleziona un account per Servizio di configurazione di System Center e servizio di accesso ai dati di System Center. Per altre informazioni, vedere Distribuzione di System Center 2012 - Operations Manager.

Attenzione
Non modificare le autorizzazioni predefinite di Active Directory per consentire a un account effettuare modifiche senza restrizioni di propri SPN.

Se si seleziona Sistema locale come account del servizio di accesso ai dati di System Center, l'account è in grado di creare l'SPN appropriato. Non è necessaria alcuna configurazione aggiuntiva.

Se si utilizza un account di dominio, è necessario registrare un nome SPN per ogni server di gestione. Utilizzare lo strumento della riga di comando SETSPN. Per ulteriori informazioni sull'esecuzione di tale strumento, vedere Setspn Overview (Panoramica di Setspn).

Registrare il nome netbios e il nome di dominio completo del server di gestione utilizzando la sintassi seguente:

setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>

setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>

Suggerimento
È possibile elencare gli SPN registrati per il computer o l'account utente con la seguente sintassi: setspn –l <DAS account name> setspn –l <fqdn>

Se si utilizza Bilanciamento carico di rete o un sistema hardware di bilanciamento del carico, il servizio di accesso ai dati di System Center deve essere eseguito in un account di dominio. Oltre al programma di installazione già descritto, è necessario registrare il nome del carico bilanciato utilizzando la sintassi seguente:

setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

Gli agenti dei computer monitorati possono eseguire attività, moduli e monitoraggi su richiesta, nonché in risposta a condizioni predefinite. Per impostazione predefinita, tutte le attività vengono eseguite utilizzando le credenziali dell'account Azione agente. In alcuni casi, l'account azione agente potrebbe non disporre di diritti e privilegi sufficienti per eseguire una determinata azione nel computer.Operations Manager supporta l'esecuzione di attività tramite agenti nel contesto di un set alternativo di credenziali denominato account RunAs. Un account RunAs è un oggetto creato in Operations Manager, in modo analogo a un destinatario, che viene mappato a un account utente di Active Directory. Per la mappatura dell'account RunAs a un determinato computer viene utilizzato un profilo RunAs. Per eseguire nel computer di destinazione una regola, un'attività o un monitoraggio associato a un profilo RunAs durante lo sviluppo di un Management Pack, viene utilizzato l'account RunAs specificato.

Operations Manager include già numerosi account e profili RunAs, ma, se necessario, è possibile crearne altri. È inoltre possibile modificare le credenziali Active Directory alle quali è associato l'account RunAs. A questo scopo, è necessario pianificare, creare e gestire altre credenziali Active Directory. Tali account devono essere considerati come account di servizio in relazione alla scadenza della password, ai servizi di dominio Active Directory, al percorso e alla sicurezza.

È quindi necessario collaborare con gli autori dei Management Pack durante lo sviluppo delle richieste di account RunAs. Per ulteriori informazioni, vedere Index to Security-related Information for Operations Manager (Indice delle informazioni correlate alla sicurezza per Operations Manager).