Share via

  • Articolo

Pianificazione della protezione in Configuration Manager

 

Si applica a: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

Nota

Questo argomento è presente in: guida Amministrazione del sito per System Center 2012 Configuration Manager e guida Protezione e privacy per System Center 2012 Configuration Manager.

Usare le seguenti informazioni per la pianificazione della sicurezza in Microsoft System Center 2012 Configuration Manager.

  • Pianificazione di certificati (autofirmato e PKI)

    • Pianificazione di revoche di certificati PKI

    • Pianificazione di certificati radice trusted PKI e dell'elenco di autorità emittenti di certificati

    • Pianificazione della selezione del certificato client PKI

    • Pianificazione di una strategia di transizione per certificati PKI e gestione client basata su Internet

  • Pianificazione della chiave radice attendibile

  • Pianificazione di firma e crittografia

  • Pianificazione dell'amministrazione basata su ruoli

Oltre a queste sezioni, vedere Protezione e privacy per l'amministrazione del sito in Configuration Manager.

Per altre informazioni sulla modalità di utilizzo dei certificati e dei controlli crittografici da parte di Configuration Manager, vedere Guida tecnica per i controlli crittografici usati in Configuration Manager.

Pianificazione di certificati (autofirmato e PKI)

Configuration Manager usa una combinazione di certificati autofirmati e certificati di infrastruttura a chiave pubblica (PKI).

Come procedura di sicurezza consigliata, usare i certificati PKI quando possibile. Per altre informazioni sui requisiti dei certificati PKI, vedere Requisiti dei certificati PKI per Configuration Manager. Quando Configuration Manager richiede i certificati PKI, come durante la registrazione di dispositivi mobili e il provisioning AMT, è necessario usare Servizi di dominio Active Directory e un'autorità di certificazione dell'organizzazione (enterprise). Per tutti gli altri certificati PKI, sono necessarie una distribuzione e una gestione indipendenti da Configuration Manager

I certificati PKI sono inoltre richiesti quando i computer client si connettono a sistemi del sito basati su Internet e sono consigliati quando i client si connettono ai sistemi del sito che eseguono Internet Information Services (IIS). Per altre informazioni sulla comunicazione tra client, vedere Pianificazione delle comunicazioni client in Configuration Manager.

Quando si usa una PKI, è possibile usare anche IPsec per proteggere la comunicazione da server a server tra sistemi in un sito e tra siti e per qualsiasi altro scenario di trasferimento dati tra computer. È necessario configurare e implementare IPsec in modo indipendente da Configuration Manager.

Configuration Manager è in grado di generare automaticamente certificati autofirmati quando i certificati PKI non sono disponibili e alcuni certificati in Configuration Manager sono sempre autofirmati. Nella maggior parte dei casi, Configuration Manager gestisce automaticamente i certificati autofirmati e non sono richieste azioni aggiuntive. Una possibile eccezione è il certificato di firma del server del sito. Il certificato di firma del server del sito è sempre autofirmato e assicura che i criteri che i client scaricano dal punto di gestione siano stati inviati dal server del sito e che non abbiano subito manomissioni.

Pianificazione del certificato di firma (autofirmato) del server del sito

I client possono ottenere in modo protetto una copia del certificato di firma del server del sito da Servizi di dominio Active Directory e dall'installazione push client. Se i client non sono in grado di ottenere una copia del certificato di firma del server del sito tramite questi meccanismi, installare una copia di tale certificato quando si installa il client come procedura di sicurezza consigliata. Ciò è particolarmente importante se la prima comunicazione del client con il sito proviene da Internet, perché il punto di gestione è connesso a una rete non attendibile e, pertanto, è vulnerabile ad attacchi. Se non si adotta questa misura aggiuntiva, i client scaricano automaticamente una copia del certificato di firma del server del sito dal punto di gestione.

Di seguito sono elencati alcuni degli scenari in cui i client non sono in grado di ottenere in modo protetto una copia del certificato del server del sito:

  • Il client non è installato tramite push client e si verifica una delle seguenti condizioni:

    • Lo schema di Active Directory non viene esteso per Configuration Manager.

    • Il sito del client non viene pubblicato in Servizi di dominio Active Directory.

    • Il client deriva da un gruppo di lavoro o una foresta non trusted.

  • Il client viene installato mentre si trova su Internet.

Usare la procedura seguente per installare i client e una copia del certificato di firma del server del sito.

Per installare i client con una copia del certificato di firma del server del sito

  1. Individuare il certificato di firma del server del sito sul server del sito primario del client. Il certificato è archiviato nell'archivio certificati SMS e dispone del Nome oggetto Server del sito e del nome descrittivo Certificato di firma del server del sito.

  2. Esportare il certificato senza la chiave privata, archiviare il file in modo sicuro e accedervi solo da un canale protetto (ad esempio, usando la firma SMB o IPsec).

  3. Installare il client usando la proprietà Client.msi SMSSIGNCERT=<Percorso completo e nome file> con CCMSetup.exe.

Pianificazione di revoche di certificati PKI

Quando si usano certificati PKI con Configuration Manager, pianificare se e in che modo client e server utilizzeranno un elenco di revoche di certificati (CRL) per verificare il certificato sul computer che si sta connettendo. L'elenco di revoche di certificati (CRL) è un file creato e firmato da un'autorità di certificazione (CA) e contiene un elenco di certificati rilasciati, ma revocati. I certificati possono essere revocati da un amministratore CA, ad esempio in caso di sospetta o accertata compromissione di un certificato rilasciato.

System_CAPS_importantImportante

Dal momento che il percorso dell'elenco CRL viene aggiunto a un certificato al momento del rilascio da parte di una CA, assicurarsi di aver pianificato l'elenco CRL prima di distribuire qualsiasi certificato PKI che sarà usato da Configuration Manager.

Per impostazione predefinita, IIS controlla sempre l'elenco CRL per i certificati client e questa configurazione non può essere modificata in Configuration Manager. Per impostazione predefinita, i client di Configuration Manager controllano sempre l'elenco CRL per i sistemi del sito. Tuttavia, è possibile disabilitare questa impostazione specificando una proprietà del sito e una proprietà CCMSetup. Quando si gestiscono computer basati su Intel AMT fuori banda, è possibile anche abilitare il controllo CRL per il punto di servizio fuori banda e per i computer che eseguono la console di gestione fuori banda.

Se i computer usano il controllo delle revoche di certificati ma non sono in grado di individuare l'elenco CRL, si comportano come se tutti i certificati nella catena di certificazione fossero revocati dal momento che non è possibile verificare la loro assenza dall'elenco. In questo scenario, non sarà possibile stabilire alcuna connessione che richieda certificati e usi un elenco CRL.

Il controllo dell'elenco CRL a ogni utilizzo di un certificato offre una maggiore protezione rispetto all'utilizzo di un certificato revocato, ma comporta un ritardo nella connessione e un'ulteriore elaborazione nel client. È più probabile che questo controllo di sicurezza aggiuntivo sia richiesto quando i client si trovano su Internet o su una rete non attendibile.

Consultare gli amministratori PKI prima di decidere se i client di Configuration Manager debbano controllare o meno l'elenco CRL, quindi considerare la possibilità di mantenere abilitata questa opzione in Configuration Manager in presenza di entrambe le condizioni seguenti:

  • L'infrastruttura PKI supporta un elenco CRL pubblicato dove tutti i client di Configuration Manager possono individuarlo. Tenere presente che potrebbero essere inclusi i client su Internet se si sta usando la gestione client basata su Internet nonché client in foreste non trusted.

  • La richiesta di controllo dell'elenco CRL per ciascuna connessione a un sistema del sito configurato per l'utilizzo di un certificato PKI è superiore alla richiesta di connessioni più rapide ed elaborazione più efficiente sul client. Inoltre, tale richiesta è superiore al rischio di mancate connessioni ai server da parte dei client nel caso in cui questi ultimi non siano in grado di individuare l'elenco CRL.

Pianificazione di certificati radice trusted PKI e dell'elenco di autorità emittenti di certificati

Se i sistemi del sito IIS usano certificati client PKI per l'autenticazione dei client su HTTP o per l'autenticazione e la crittografia dei client su HTTPS, potrebbe essere necessario importare i certificati CA radice come una proprietà del sito. I due scenari sono i seguenti:

  • I sistemi operativi sono distribuiti usando Configuration Manager e i punti di gestione accettano solo connessioni client HTTPS.

  • Si usano certificati client PKI non concatenati a un certificato di un'autorità di certificazione (CA) radice considerato attendibile dai punti di gestione.

    Nota

    Quando i certificati client PKI vengono rilasciati dalla stessa gerarchia CA che rilascia i certificati server usati per i punti di gestione, non è necessario specificare questo certificato CA radice. Tuttavia, se si usano più gerarchie CA e non si è certi che queste si considerino reciprocamente attendibili, importare la CA radice per la gerarchia CA dei client.

Se è necessario importare i certificati CA radice per Configuration Manager, esportarli dalla CA emittente o dal computer client. Se si esporta il certificato dalla CA emittente che corrisponde anche alla CA radice, assicurarsi che la chiave privata non venga esportata. Memorizzare il file del certificato esportato in un'ubicazione protetta per impedire eventuali manomissioni. È necessario poter accedere al file quando si configura il sito e, pertanto, in caso di accesso dalla rete, accertarsi che la comunicazione sia protetta da eventuali manomissioni usando la firma SMB o IPsec.

Se uno dei certificati CA radice importati viene rinnovato, è necessario importare i certificati rinnovati.

Questi certificati CA radice importati e il certificato CA radice di ciascun punto di gestione creano l'elenco di autorità emittenti di certificati usato dai computer Configuration Manager nei modi seguenti:

  • Quando i client si connettono a un punto di gestione, questo verifica che il certificato client sia concatenato a un certificato radice trusted presente nell'elenco di autorità emittenti di certificati del sito. Se ciò non avviene, il certificato viene rifiutato e la connessione PKI non riesce.

  • In presenza di un elenco di autorità emittenti di certificati, i client selezionano un certificato PKI concatenato a un certificato radice trusted presente nell'elenco. In assenza di una corrispondenza, il client non seleziona un certificato PKI. Per altre informazioni sul processo dei certificati client, vedere la sezione Pianificazione della selezione del certificato client PKI in questo argomento.

Indipendentemente dalla configurazione del sito, potrebbe essere anche richiesta l'importazione di un certificato CA radice quando si esegue la registrazione di dispositivi mobili o computer Mac e il provisioning di computer basati su Intel AMT per reti wireless.

Pianificazione della selezione del certificato client PKI

Se i sistemi del sito IIS utilizzeranno certificati client PKI per l'autenticazione dei client su HTTP o per l'autenticazione e la crittografia dei client su HTTPS, pianificare la modalità con cui i client basati su Windows selezioneranno il certificato da usare per Configuration Manager.

Nota

Non tutti i dispositivi supportano un metodo di selezione del certificato, al contrario selezionano automaticamente il primo certificato che soddisfa i requisiti del certificato. Ad esempio, i client su computer Mac e dispositivi mobili non supportano un metodo di selezione del certificato.

In molti casi, la configurazione e il comportamento predefiniti saranno sufficienti. Il client di Configuration Manager su computer basati su Windows filtra più certificati in base ai seguenti criteri:

  1. L'elenco di autorità emittenti di certificati: il certificato si concatena a una CA radice considerata attendibile dal punto di gestione.

  2. Il certificato si trova nell'archivio certificati predefinito Personale.

  3. Il certificato è valido, non revocato e non è scaduto. Il controllo di validità prevede di verificare che la chiave privata sia accessibile e che il certificato non sia stato creato usando un modello di certificato della versione 3, non compatibile con Configuration Manager.

  4. Il certificato dispone della funzionalità di autenticazione client o viene rilasciato al nome del computer.

  5. Il certificato ha il periodo di validità più lungo.

I client possono essere configurati per l'utilizzo dell'elenco di autorità emittenti di certificati usando i meccanismi seguenti:

  • Viene pubblicato come informazione del sito di Configuration Manager in Servizi di dominio Active Directory.

  • I client vengono installati tramite push client.

  • I client lo scaricano dal punto di gestione dopo essere stati correttamente assegnati al rispettivo sito.

  • Viene specificato durante l'installazione del client, come una proprietà client.msi CCMSetup di CCMCERTISSUERS.

Se i client non dispongono dell'elenco di autorità emittenti di certificati al momento dell'installazione iniziale e non sono ancora assegnati al sito, salteranno questo controllo. Quando dispongono dell'elenco di autorità emittenti di certificati ma non di un certificato PKI concatenato a un certificato radice trusted presente nell'elenco, la selezione del certificato non viene completata correttamente e i client non proseguono con gli altri criteri di selezione del certificato.

Nella maggior parte dei casi, il client di Configuration Manager identifica correttamente un certificato PKI univoco e appropriato da usare. Tuttavia, quando ciò non accade, invece di selezionare il certificato sulla base della funzionalità di autenticazione client, è possibile configurare due metodi di selezione alternativi:

  • Una corrispondenza della stringa parziale nel Nome oggetto del certificato client. Si tratta di una corrispondenza senza distinzione tra maiuscole e minuscole appropriata se si sta usando il nome di dominio completo (FQDN) di un computer nel campo oggetto e si desidera che la selezione del certificato sia basata sul suffisso del dominio, ad esempio contoso.com. Tuttavia, è possibile usare questo metodo di selezione per identificare qualsiasi stringa di caratteri sequenziali nel Nome oggetto del certificato che differenziano quest'ultimo dagli altri certificati nell'archivio certificati client.

    Nota

    Non è possibile usare la corrispondenza della stringa parziale con il Nome alternativo del soggetto (SAN) come un'impostazione del sito. Sebbene sia possibile specificare una corrispondenza della stringa parziale per il SAN usando CCMSetup, sarà sovrascritta dalle proprietà del sito negli scenari seguenti:

    • I client recuperano informazioni del sito pubblicate in Servizi di dominio Active Directory.

    • I client vengono installati tramite installazione push client.

    Usare una corrispondenza della stringa parziale nel SAN solo quando si installano i client manualmente e quando questi non recuperano le informazioni del sito da Servizi di dominio Active Directory. Ad esempio, queste condizioni si applicano solo ai client Internet.

  • Una corrispondenza nei valori attributo del nome oggetto del certificato client o nei valori attributo del nome alternativo del soggetto (SAN). Si tratta di una corrispondenza con distinzione tra maiuscole e minuscole appropriata se si sta usando un nome distinto X500 o identificatori oggetto (OID) equivalenti in conformità con RFC 3280 e si desidera che la selezione del certificato sia basata sui valori attributo. È possibile specificare solo gli attributi e i rispettivi valori richiesti per identificare o convalidare in modo univoco il certificato e differenziarlo dagli altri certificati nel relativo archivio.

Nella tabella seguente vengono illustrati i valori attributo che Configuration Manager supporta per i criteri di selezione del certificato client.

Attributo OID

Attributo del nome distinto

Definizione di attributo

0.9.2342.19200300.100.1.25

DC

Componente del dominio

1.2.840.113549.1.9.1

E o E-mail

Indirizzo di posta elettronica

2.5.4.3

CN

Nome comune

2.5.4.4

SN

Nome oggetto

2.5.4.5

SERIALNUMBER

Numero di serie

2.5.4.6

C

Codice paese

2.5.4.7

L

Località

2.5.4.8

S o ST

Nome di provincia o stato

2.5.4.9

STREET

Indirizzo

2.5.4.10

O

Nome organizzazione

2.5.4.11

OU

Unità organizzativa

2.5.4.12

T o Title

Titolo

2.5.4.42

G o GN o GivenName

Nome specificato

2.5.4.43

I o Initials

Iniziali

2.5.29.17

(nessun valore)

Nome alternativo soggetto

Se viene individuato più di un certificato appropriato dopo aver applicato i criteri di selezione, è possibile ignorare la configurazione predefinita che prevede la selezione del certificato con il periodo di validità più lungo specificando che nessun certificato è selezionato. In questo scenario, il client non sarà in grado di comunicare con i sistemi del sito IIS usando un certificato PKI. Il client invia un messaggio di errore al suo punto di stato di fallback assegnato per avvisare circa l'esito negativo della selezione del certificato e consentire la modifica o il perfezionamento dei criteri di selezione del certificato. Il comportamento del client varia a seconda se la connessione non riuscita era su HTTPS o HTTP:

  • Se la connessione non riuscita era su HTTPS: Il client tenta di stabilire una connessione su HTTP e usa il certificato autofirmato.

  • Se la connessione non riuscita era su HTTP: Il client tenta di stabilire un'altra connessione su HTTP usando il certificato autofirmato.

Per identificare un certificato client PKI univoco, è possibile inoltre specificare un archivio personalizzato diverso dall'archivio predefinito Personale in Computer. Tuttavia, è necessario creare questo archivio indipendentemente da Configuration Manager nonché essere in grado di distribuire i certificati a questo archivio personalizzato e rinnovarli prima della scadenza del periodo di validità.

Per informazioni su come configurare le impostazioni per i certificati client, vedere la sezione Configurare le impostazioni per i certificati PKI client nell'argomento Configurazione della protezione per Configuration Manager.

Pianificazione di una strategia di transizione per certificati PKI e gestione client basata su Internet

Le opzioni di configurazione flessibile in Configuration Manager consentono di eseguire una transizione graduale dei client e del sito all'utilizzo dei certificati PKI per garantire la protezione degli endpoint dei client. I certificati PKI forniscono una migliore protezione e consentono la gestione dei client che si trovano su Internet.

Dato il numero di opzioni e scelte di configurazione in Configuration Manager, sono previste più modalità di transizione di un sito in modo che tutti i client utilizzino connessioni HTTPS. Tuttavia, è possibile attenersi alla seguente procedura come guida:

  1. Installare il sito di Configuration Manager e configurarlo in modo che i sistemi del sito accettino le connessioni client su HTTPS e HTTP.

  2. Configurare la scheda Comunicazione computer client nelle proprietà del sito in modo che Impostazioni sistema del sito sia HTTP o HTTPS, quindi selezionare la casella di controllo Usa certificato client PKI (funzionalità di autenticazione client) quando disponibile. Configurare le altre impostazioni richieste in questa scheda. Per altre informazioni, vedere la sezione Configurare le impostazioni per i certificati PKI client nell'argomento Configurazione della protezione per Configuration Manager.

  3. Eseguire il progetto pilota di un'implementazione PKI per i certificati client. Per una distribuzione di esempio, vedere la sezione Distribuzione del certificato client per computer Windows nell'argomento Esempio dettagliato di distribuzione dei certificati PKI per Configuration Manager: Autorità di certificazione di Windows Server 2008.

  4. Installare i client usando il metodo di installazione push client. Per altre informazioni, vedere la sezione Come installare i client di Configuration Manager usando push client nell'argomento Come installare i client in computer basati su Windows in Configuration Manager.

  5. Monitorare lo stato e la distribuzione dei client usando i report e le informazioni nella console di Configuration Manager.

  6. Tenere traccia del numero di client che usano un certificato client PKI visualizzando la colonna Certificato client nell'area di lavoro Asset e conformità, nodo Dispositivi.

    È inoltre possibile distribuire l'HTTPS Readiness Assessment Tool (Configuration Manager) di cmHttpsReadiness.exe ai computer e usare i report per visualizzare il numero di computer in grado di usare un certificato client PKI con Configuration Manager.

    Nota

    Quando il client di Configuration Manager viene installato sui computer client, lo strumento cmHttpsReadiness.exe viene installato nella cartella %windir%\CCM. Quando si esegue questo strumento sui client, è possibile specificare le opzioni seguenti:

    • /Store:<nome>

    • /Issuers:<elenco>

    • /Criteria:<criteri>

    • /SelectFirstCert

    Queste opzioni eseguono il mapping rispettivamente alle proprietà Client.msi CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL e CCMFIRSTCERT. Per altre informazioni su queste opzioni, vedere Informazioni sulle proprietà di installazione del client in Configuration Manager.

  7. Quando si è certi che un numero sufficiente di client sta usando correttamente il rispettivo certificato client PKI per l'autenticazione su HTTP, procedere nel modo seguente:

    1. Distribuire un certificato del server Web PKI a un server membro che eseguirà un punto di gestione aggiuntivo per il sito e configurare tale certificato in IIS. Per altre informazioni, vedere la sezione Distribuzione del certificato del server Web per sistemi del sito che eseguono IIS nell'argomento Esempio dettagliato di distribuzione dei certificati PKI per Configuration Manager: Autorità di certificazione di Windows Server 2008.

    2. Installare il ruolo del punto di gestione su questo server e configurare l'opzione Connessioni client nelle proprietà del punto di gestione per HTTPS.

  8. Monitorare e verificare che i client che dispongono di un certificato PKI utilizzino il nuovo punto di gestione tramite HTTPS. Per verificare ciò, è possibile usare la registrazione delle attività IIS o i contatori delle prestazioni.

  9. Riconfigurare altri ruoli del sistema del sito per l'utilizzo di connessioni client HTTPS. Se si desidera gestire i client su Internet, assicurarsi che i sistemi del sito dispongano di un FQDN Internet e configurare i singoli punti di gestione e di distribuzione in modo che accettino le connessioni client da Internet.

    System_CAPS_importantImportante

    Prima di configurare i ruoli del sistema del sito per l'accettazione di connessioni da Internet, rivedere le informazioni e i prerequisiti della pianificazione per la gestione client basata su Internet. Per altre informazioni, vedere la sezione Pianificazione della gestione client basata su Internet nell'argomento Pianificazione delle comunicazioni in Configuration Manager.

  10. Estendere l'implementazione del certificato PKI per i client e i sistemi del sito che eseguono IIS e configurare i ruoli del sistema del sito per le connessioni client HTTPS e le connessioni Internet, come richiesto.

  11. Per la massima protezione: Quando si è certi che tutti i client stanno usando un certificato client PKI per l'autenticazione e la crittografia, modificare le proprietà del sito per l'utilizzo esclusivo di HTTPS.

Quando si adotta questo piano di introduzione graduale dei certificati PKI, prima per l'autenticazione solo su HTTP e poi per l'autenticazione e la crittografia su HTTPS, si riduce il rischio di client non gestiti. Inoltre, è possibile beneficiare della massima protezione supportata da Configuration Manager.

Pianificazione della chiave radice attendibile

La chiave radice attendibile di Configuration Manager garantisce un meccanismo che consente ai client di Configuration Manager di verificare che i sistemi del sito appartengano alla loro gerarchia. Ogni server del sito genera una chiave di scambio per comunicare con altri siti. La chiave di scambio dal sito di livello superiore nella gerarchia viene chiamata chiave radice attendibile.

La funzione della chiave radice attendibile in Configuration Manager è simile a quella di un certificato radice in un'infrastruttura a chiave pubblica per il fatto che tutto ciò che viene firmato dalla chiave privata della chiave radice attendibile è considerato attendibile nei livelli inferiori della gerarchia. Ad esempio, firmando il certificato del punto di gestione con la chiave privata della coppia di chiavi radice attendibili e mettendo a disposizione dei client una copia della chiave pubblica della coppia di chiavi radice attendibili, i client possono distinguere i punti di gestione presenti nella loro gerarchia da quelli assenti. I client usano WMI per memorizzare una copia della chiave radice attendibile nello spazio dei nomi root\ccm\locationservices.

I client possono recuperare automaticamente la copia pubblica della chiave radice attendibile tramite due meccanismi:

  • Lo schema di Active Directory viene esteso per Configuration Manager, il sito viene pubblicato in Servizi di dominio Active Directory e i client possono recuperare queste informazioni del sito da un server del catalogo globale.

  • I client vengono installati tramite push client.

Se i client non sono in grado di recuperare la chiave radice attendibile tramite uno di questi meccanismi, considereranno attendibile la chiave radice attendibile fornita dal primo punto di gestione con cui è stata stabilita una connessione. In questo scenario, un client potrebbe essere erroneamente indirizzato al punto di gestione dell'autore di un attacco in cui riceverebbe criteri dal punto di gestione non autorizzato. Tale azione sarebbe probabilmente opera di un utente malintenzionato esperto e potrebbe verificarsi solo in un intervallo di tempo limitato prima che il client recuperi la chiave radice attendibile da un punto di gestione valido. Tuttavia, per ridurre il rischio di un errato indirizzamento dei client a un punto di gestione non autorizzato, è possibile eseguire il pre-provisioning dei client usando la chiave radice attendibile.

Usare le procedure seguenti per eseguire il pre-provisioning e verificare la chiave radice attendibile per un client di Configuration Manager:

  • Eseguire il pre-provisioning di un client usando la chiave radice attendibile tramite file.

  • Eseguire il pre-provisioning di un client usando la chiave radice attendibile senza file.

  • Verificare la chiave radice attendibile in un client.

Nota

Non è necessario eseguire il pre-provisioning del client con la chiave radice attendibile se è possibile ottenerla da Servizi di dominio Active Directory o se è stata eseguita un'installazione push client. Inoltre, non è necessario eseguire il pre-provisioning dei client quando usano la comunicazione HTTPS con i punti di gestione perché l'attendibilità viene stabilita tramite i certificati PKI.

È possibile rimuovere la chiave radice attendibile da un client usando la proprietà RESETKEYINFORMATION = TRUE di Client.msi con CCMSetup.exe. Per sostituire tale chiave, reinstallare il client insieme alla nuova chiave radice attendibile, usando, ad esempio, l'installazione push client o specificando la proprietà SMSPublicRootKey di Client.msi tramite CCMSetup.exe.

Per eseguire il pre-provisioning di un client con la chiave radice attendibile tramite file

  1. In un editor di testo aprire il file <directory Configuration Manager>\bin\mobileclient.tcf.

  2. Individuare la voce SMSPublicRootKey=, copiare la chiave da tale riga e chiudere il file senza apportare modifiche.

  3. Creare un nuovo file di testo e incollare le informazioni della chiave copiate dal file mobileclient.tcf.

  4. Salvare il file e posizionarlo in un punto in cui tutti i computer possano accedervi ma in cui sia protetto da eventuali manomissioni.

  5. Installare il client usando un metodo di installazione che accetti le proprietà Client.msi e specificare la proprietà SMSROOTKEYPATH=<Percorso completo e nome file> di Client.msi.

    System_CAPS_importantImportante

    Quando si specifica la chiave radice attendibile per la protezione aggiuntiva durante l'installazione dei client, è anche necessario specificare il codice del sito usando la proprietà SMSSITECODE=<codice sito> di Client.msi.

Per eseguire il pre-provisioning di un client con la chiave radice attendibile senza file

  1. In un editor di testo aprire il file <directory Configuration Manager>\bin\mobileclient.tcf.

  2. Individuare la voce SMSPublicRootKey=, annotare la chiave da tale riga o copiarla negli Appunti, quindi chiudere il file senza apportare modifiche.

  3. Installare il client usando qualsiasi metodo di installazione che accetti le proprietà Client.msi e specificare la proprietà Client.msi SMSPublicRootKey=<chiave> di Client.msi, dove <chiave> è la stringa copiata da mobileclient.tcf.

    System_CAPS_importantImportante

    Quando si specifica la chiave radice attendibile per la protezione aggiuntiva durante l'installazione dei client, è anche necessario specificare il codice del sito usando la proprietà SMSSITECODE=<codice sito> di Client.msi

Per verificare la chiave radice attendibile in un client

  1. Nel menu Start fare clic su Esegui, quindi digitare Wbemtest.

  2. Nella finestra di dialogo Tester Strumentazione gestione Windows fare clic su Connetti.

  3. Nella finestra di dialogo Connetti, nella casella Spazio dei nomi, digitare root\ccm\locationservices, quindi fare clic su Connetti.

  4. Nella finestra di dialogo Tester Strumentazione gestione Windows, nella sezione IWbemServices, fare clic su Enum classi.

  5. Nella finestra di dialogo Informazioni superclasse selezionare Ricorsivo, quindi fare clic su OK.

  6. Nella finestra Risultato query scorrere fino alla fine dell'elenco, quindi fare doppio clic su TrustedRootKey ().

  7. Nella finestra di dialogo Editor oggetti per TrustedRootKey fare clic su Istanze.

  8. Nella nuova finestra di Risultato query in cui vengono visualizzate le istanze di TrustedRootKey fare doppio clic su TrustedRootKey=@

  9. Nella finestra di dialogo Editor oggetti per TrustedRootKey=@, nella sezione Proprietà, scorrere in basso fino a TrustedRootKey CIM_STRING. La stringa nella colonna destra è la chiave radice attendibile. Verificarne la corrispondenza con il valore SMSPublicRootKey nel file <directory Configuration Manager>\bin\mobileclient.tcf.

Pianificazione di firma e crittografia

Quando si usano certificati PKI per tutte le comunicazioni dei client, non è necessario pianificare la firma e la crittografia per proteggere la comunicazione dei dati dei client. Tuttavia, se si configura qualsiasi sistema del sito che esegue IIS in modo da consentire le connessioni client HTTP, è necessario stabilire la modalità di protezione della comunicazione client per il sito.

Per proteggere i dati che i client inviano ai punti di gestione, è possibile richiedere che vengano firmati. Inoltre, è possibile richiedere che tutti i dati firmati dai client che usano HTTP vengano firmati usando l'algoritmo SHA-256. Si tratta di un'impostazione più sicura; non abilitare questa opzione a meno che tutti i client supportino SHA-256. Molti sistemi operativi supportano SHA-256 in modo nativo, ma i sistemi operativi precedenti potrebbe richiedere un aggiornamento o un hotfix. Ad esempio, i computer che eseguono Windows Server 2003 SP2 devono installare un hotfix a cui si fa riferimento nell'articolo della Knowledge Base 938397.

Mentre la firma consente di proteggere i dati da eventuali manomissioni, la crittografia consente di proteggere i dati dalla divulgazione di informazioni. È possibile attivare la crittografia 3DES per i dati di inventario e i messaggi di stato che i client inviano ai punti di gestione presenti nel sito. Non sarà necessario installare aggiornamenti nei client per il supporto di questa opzione, ma tenere presente l'utilizzo di CPU aggiuntivo che sarà necessario nei client e nel punto di gestione per eseguire crittografia e decrittografia.

Per informazioni su come configurare le impostazioni per la firma e la crittografia, vedere la sezione Configurare la firma e la crittografia nell'argomento Configurazione della protezione per Configuration Manager.

Pianificazione dell'amministrazione basata su ruoli

L'amministrazione basata su ruoli consente di progettare e implementare la protezione amministrativa per la gerarchia di System Center 2012 Configuration Manager tramite una o più delle seguenti opzioni:

  • Ruoli di sicurezza

  • Raccolte

  • Ambiti di protezione

La combinazione di queste impostazioni consente di definire un ambito amministrativo per un utente amministratore. Lo scopo amministrativo controlla gli oggetti che un utente amministratore può visualizzare nella console di Configuration Manager e le autorizzazioni di tale utente sugli oggetti. Le configurazione dell'amministrazione basata su ruoli vengono replicate in ogni sito della gerarchia come dati globali e quindi vengono applicate a tutte le connessioni amministrative.

System_CAPS_importantImportante

I ritardi di replica tra siti possono impedire a un sito di ricevere modifiche per l'amministrazione basata su ruoli. Per altre informazioni su come monitorare la replica di database tra siti, vedere la sezione Come monitorare lo stato e i collegamenti di replica di database nell'argomento Monitoraggio dei siti e della gerarchia di Configuration Manager.

Pianificazione dei ruoli di sicurezza

Usare i ruoli di sicurezza per concedere le autorizzazioni di sicurezza a utenti amministratori. I ruoli di sicurezza sono gruppi di autorizzazioni di sicurezza assegnate agli utenti amministratori in modo che possano eseguire le relative attività amministrative. Le autorizzazioni di sicurezza definiscono le azioni amministrative che un utente amministratore può eseguire e le autorizzazioni concesse per determinati tipi di oggetto. Come procedura consigliata di sicurezza, assegnare i ruoli di sicurezza che forniscono i privilegi minimi.

System Center 2012 Configuration Manager dispone di diversi ruoli di sicurezza incorporati per supportare i raggruppamenti tipici di attività amministrative. È possibile creare ruoli di sicurezza personalizzati per soddisfare particolari esigenze aziendali. Esempi di ruoli di sicurezza incorporati:

  • Amministratore completo: questo ruolo di sicurezza concede tutte le autorizzazioni in Configuration Manager.

  • Analista asset: questo ruolo di sicurezza consente agli utenti amministratori di visualizzare i dati raccolti mediante Asset Intelligence, l'inventario software, l'inventario hardware e il controllo del software. Gli utenti amministratori possono creare regole di controllo software ed etichette, famiglie e categorie di Asset Intelligence.

  • Amministratore aggiornamento software: questo ruolo di sicurezza concede le autorizzazioni per definire e distribuire gli aggiornamenti software. Gli utenti amministratori associati a questo ruolo possono creare raccolte, gruppi di aggiornamento software, distribuzioni e modelli e attivare gli aggiornamenti software per la funzionalità Protezione accesso alla rete (NAP).

System_CAPS_tipSuggerimento

È possibile visualizzare l'elenco di ruoli di sicurezza incorporati e i ruoli di sicurezza personalizzati creati, incluse le descrizioni, nella console di Configuration Manager. A tale scopo, nell'area di lavoro Amministrazione espandere Sicurezza e selezionare Ruoli di protezione.

Ogni ruolo di sicurezza dispone di autorizzazioni specifiche per diversi tipi di oggetto. Ad esempio, il ruolo di sicurezza Amministratore applicazione dispone delle seguenti autorizzazioni per le applicazioni: Approva, Crea, Elimina, Modifica, Modifica cartella, Sposta oggetto, Leggi/Distribuisci, Imposta ambito di protezione. Non è possibile modificare le autorizzazioni per i ruoli di sicurezza incorporati, ma è possibile copiare il ruolo, apportare modifiche e quindi salvare tali modifiche come un nuovo ruolo di sicurezza personalizzato. È inoltre possibile importare ruoli di sicurezza esportati da un'altra gerarchia (ad esempio da una rete di prova). Esaminare i ruoli di sicurezza e le relative autorizzazioni per stabilire se usare i ruoli di sicurezza incorporati o se sia necessario crearne di personalizzati.

Usare i seguenti passaggi per la pianificazione dei ruoli di sicurezza:

  1. Identificare le attività eseguite dagli utenti amministratori in System Center 2012 Configuration Manager. Queste attività possono far riferimento a uno o più gruppi di attività di gestione, ad esempio distribuzione di pacchetti e applicazioni, distribuzione di sistemi operativi e impostazioni di conformità, configurazione di siti e protezione, controllo, computer con controllo remoto e raccolta di dati di inventario.

  2. Eseguire il mapping di queste attività amministrative in uno o più ruoli di sicurezza incorporati.

  3. Se alcuni utenti amministratori eseguono le attività di più ruoli di sicurezza, assegnare più ruoli di sicurezza a tali utenti amministratori invece di creare un nuovo ruolo di sicurezza che combini queste attività.

  4. Se le attività identificate non eseguono il mapping ai ruoli di sicurezza incorporati, creare e testare nuovi ruoli di sicurezza.

Per informazioni su come creare e configurare i ruoli di sicurezza per l'amministrazione basata su ruoli, vedere le sezioni Creare ruoli di sicurezza personalizzati e Configurare i ruoli di sicurezza nell'argomento Configurazione della protezione per Configuration Manager.

Pianificazione delle raccolte

Le raccolte specificano utente e risorse del computer che un utente amministratore può visualizzare o gestire. Ad esempio, per poter distribuire applicazioni o eseguire il controllo remoto, agli utenti amministratori deve essere assegnato un ruolo di sicurezza che consente l'accesso a una raccolta che include queste risorse. È possibile selezionare raccolte di utenti o dispositivi.

Per altre informazioni sulle raccolte, vedere Introduzione alle raccolte in Configuration Manager.

Prima di configurare l'amministrazione basata su ruoli, verificare se è necessario creare nuove raccolte per uno dei seguenti motivi:

  • Organizzazione funzionale. Ad esempio, separare raccolte di server e workstation.

  • Allineamento geografica. Ad esempio, separare raccolte per il Nord America e l' Europa.

  • Requisiti di protezione e processi aziendali. Ad esempio, separare raccolte per produzione e computer di prova.

  • Allineamento dell'organizzazione. Ad esempio, separare le raccolte per ogni Business Unit.

Per informazioni su come configurare raccolte per l'amministrazione basata su ruoli, vedere la sezione Configurare le raccolte per la gestione della sicurezza nell'argomento Configurazione della protezione per Configuration Manager.

Pianificazione degli ambiti di protezione

Usare gli ambiti di protezione per fornire agli utenti amministratori l'accesso a oggetti a protezione diretta. Gli ambiti di protezione sono una raccolta denominata di oggetti a protezione diretta che vengono assegnati agli utenti amministratori come gruppo. Tutti gli oggetti a protezione diretta devono essere assegnati a uno o più ambiti di protezione. In Configuration Manager sono due ambiti di protezione predefiniti:

  • Tutto: questo ambito di protezione incorporato consente l'accesso a tutti gli ambiti. Non è possibile assegnare gli oggetti a questo ambito di protezione.

  • Predefinito: per impostazione predefinita, questo ambito di protezione incorporato viene usato per tutti gli oggetti. Quando si installa System Center 2012 Configuration Manager per la prima volta, tutti gli oggetti vengono assegnati a questo ambito di protezione.

Se si desidera limitare gli oggetti che gli utenti amministratori possono visualizzare e gestire, è necessario creare ed usare scopi di protezione personalizzati. Gli ambiti di protezione non supportano una struttura gerarchica e non possono essere nidificati. Gli ambiti di protezione possono contenere uno o più tipi di oggetto, tra cui:

  • Sottoscrizioni di avvisi

  • Applicazioni

  • Immagini d'avvio

  • Gruppi di limiti

  • Elementi di configurazione

  • Impostazioni client personalizzate

  • Punti di distribuzione e gruppi di punti di distribuzione

  • Pacchetti driver

  • Condizioni globali

  • Processi di migrazione

  • Immagini del sistema operativo

  • Pacchetti di installazione del sistema operativo

  • Pacchetti

  • Query

  • Siti

  • Regole di controllo software

  • Gruppi di aggiornamenti software

  • Pacchetti di aggiornamenti software

  • Pacchetti di sequenze attività

  • Pacchetti e elementi di impostazioni del dispositivo Windows CE

Esistono inoltre alcuni oggetti che non è possibile includere negli ambiti di protezione poiché sono protetti solo dai ruoli di sicurezza. Il relativo accesso amministrativo non può essere limitato a un sottoinsieme degli oggetti disponibili. Ad esempio, potrebbe essere presente un utente amministratore che crea gruppi di limiti usati per un sito specifico. Poiché l'oggetto limite non supporta agli ambiti di protezione, non è possibile assegnare a questo utente un ambito di protezione che consente l'accesso solo ai limiti che potrebbero essere associati a tale sito. Poiché un oggetto limite non può essere associato a un ambito di protezione, quando si assegna a un utente un ruolo di sicurezza che include l'accesso a oggetti limite tale utente può accedere a ogni limite presente nella gerarchia.

Tra gli oggetti non limitati dagli ambiti di protezione sono inclusi i seguenti:

  • Foreste Active Directory

  • Utenti amministratori

  • Avvisi

  • Criteri antimalware

  • Limiti

  • Associazioni di computer

  • Impostazioni client predefinite

  • Modelli di distribuzione

  • Driver di dispositivo

  • Connettore Exchange Server

  • Mapping di migrazione da sito a sito

  • Profili di registrazione dispositivo mobile

  • Ruoli di sicurezza

  • Ambiti di protezione

  • Indirizzi di siti

  • Ruoli del sistema del sito

  • Titoli software

  • Aggiornamenti software

  • Messaggi di stato

  • Affinità utente dispositivo

Creare ambiti di protezione quando è necessario limitare l'accesso per separare le istanze di oggetti. Ad esempio:

  • Si dispone di un gruppo di utenti amministratori che deve essere in grado di visualizzare applicazioni di produzione e applicazioni di prova. Creare un ambito di protezione per le applicazioni di produzione e un altro per le applicazioni di prova.

  • Diversi utenti amministratori richiedono un accesso diverso ad alcune istanze di un tipo di oggetto. Ad esempio, un gruppo di utenti amministratori richiede l'autorizzazione Lettura per gruppi di aggiornamenti software specifici e un altro gruppo di utenti amministratori richiede le autorizzazioni Modifica e Elimina per altri gruppi di aggiornamento software. Creare ambiti di protezione diversi per questi gruppi di aggiornamento software.

Per informazioni su come configurare gli ambiti di protezione per l'amministrazione basata su ruoli, vedere la sezione Configurare gli ambiti di protezione per un oggetto nell'argomento Configurazione della protezione per Configuration Manager.