Protezione delle credenziali nella configurazione dello stato desiderato tramite certificati

Sono nuovo di DSC e sto cercando di capire come farlo funzionare per noi.

Ciò su cui sono bloccato è come le credenziali sono effettivamente protette. La mia attuale comprensione è che non è poi così eccezionale.

I tre grandi problemi sono questi. In che modo l'utilizzo di una chiave pubblica come fonte di decrittografia protegge davvero tali credenziali? Quali computer necessitano del certificato in scenari push and pull? Quali sono le migliori pratiche per gestire le credenziali alla luce di questi problemi?

L'uso di una chiave pubblica di un certificato è utile per autenticare l'origine di una trasmissione. Ma usarlo come chiave di decrittazione significa che l'accesso alla chiave pubblica del certificato determina l'accesso alla password.

Se devi inviare il certificato a tutti i computer che devono decrittografare i file MOF, cosa c'è che impedisce agli utenti medi di accedere al certificato e di essere in grado di decrittografare il MOF? Dire che la sicurezza di Active Directory significa che puoi anche lasciarlo in chiaro e fare affidamento sulla sicurezza di Active Directory.

Qualcuno può aiutarmi a risolvere il problema?

L'idea di base

1. L'host da configurare deve avere un certificato installato (con chiave privata).
2. Quando si imposta il gestore della configurazione locale (LCM) del nodo di destinazione, è necessario specificare l'identificazione personale di quel certificato. Questo indica all'LCM quale certificato locale (o più precisamente quale chiave privata del certificato) verrà utilizzato per decrittografare le credenziali.
3. La configurazione DSC deve puntare a un file che contiene solo il certificato (chiave pubblica) dello stesso certificato. Questo viene fatto nei dati di configurazione, quindi è possibile specificare un certificato diverso per ciascun nodo, se si intende utilizzare la stessa configurazione per ciascuno di essi.
4. Quando viene generato il MOF, la chiave pubblica viene utilizzata dalla macchina che genera il MOF per codificare le credenziali.
5. Quando LCM sul nodo di destinazione recupera la configurazione dal server pull (in formato MOF), utilizza la chiave privata del certificato identificato dall'identificazione personale per decrittografare l'oggetto credenziale.

In alcuni dettagli

La chiave pubblica non può essere utilizzata per decrittografare e non si condivide la chiave privata con la generazione della configurazione né i computer di distribuzione.

Sembra che tu stia considerando il flusso di lavoro come se ci fosse un singolo certificato in uso per tutte le credenziali. Potresti farlo, ma penso che l'idea sia che ogni nodo abbia la sua coppia di chiavi.

"Utenti medi" che intendo per utenti non amministrativi, non sono in grado di esportare la chiave privata di un certificato (a meno che non vengano concessi i permessi) e poiché non si sposta questa chiave, ci sono poche possibilità di essendo esposto. Se l'utente è un amministratore, allora ovviamente ha accesso.

È molto più probabile che l'archiviazione delle credenziali di testo normale in una configurazione sia esposta attraverso la configurazione non elaborata di PowerShell o il MOF generato. Se non è crittografato, allora dovresti proteggere:

• Il percorso del file system / della rete in cui è memorizzata la configurazione
• La fs / share in cui sono memorizzati i MOF generati
• La fs / share in cui si memorizzano i MOF sul server pull
• Assicurati che il pull server sia in esecuzione su SSL (dovresti farlo comunque)
• Assicurati che ci sia autenticazione sul server Pull, altrimenti qualsiasi query anonima potrebbe recuperare una configurazione con credenziali esposte.

Penso che le credenziali sicure in DSC siano fatte piuttosto bene, ma è un po 'difficile iniziare con esso inizialmente.

AD PKI rende tutto più semplice

Se si utilizza Enterprise PKI nel proprio ambiente AD, è probabile che ogni macchina sia configurata per la registrazione automatica presso la CA, quindi ha già un certificato specifico per macchina che si rinnova da solo. Ha le impostazioni necessarie per essere utilizzato a questo scopo.

Come lo sto implementando

Poiché gli strumenti sono così spogli per DSC in questo momento, è probabile che creerai il tuo flusso di lavoro per generare config e scrivere script per aiutare comunque.

Nel mio caso ho script separati per la generazione del meta MOF LCM e per la generazione della configurazione effettiva del nodo, quindi i miei passaggi per la protezione delle credenziali sono divisi tra entrambi.

Nello script di generazione LCM, in realtà chiedo all'autorità di certificazione il dominio di trovare il certificato che corrisponde al nome host della macchina che si sta configurando. Recupero il certificato (la CA non ha la chiave privata, solo il pubblico) e la salvo in un percorso per un uso successivo. Il meta MOF viene configurato per utilizzare l'identificazione personale del certificato.

Nello script di configurazione del nodo ho impostato i dati di configurazione per utilizzare il file cert (di nuovo solo chiave pubblica). Quando viene generato il MOF, le credenziali vengono crittografate con quel certificato e possono essere decrittografate solo con la chiave privata sul nodo specifico.

Riferimento

Ho fatto riferimento alla mia esperienza in precedenza, ma questo articolo è stato di grande aiuto lungo la strada: https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state- configurazione

Ho dovuto riempire alcuni dei buchi da solo. Una cosa da notare negli esempi che mostrano è che forniscono la Thumprintconfigurazione del nodo. Questo non è necessario per la configurazione del nodo; stanno solo generando la configurazione e la meta-configurazione LCM contemporaneamente e stanno utilizzando i dati di configurazione per memorizzare l'impronta digitale da utilizzare lì.

L'ultimo paragrafo potrebbe essere fonte di confusione, ma ha più senso nel contesto dell'articolo. Se non stai generando entrambe le configurazioni contemporaneamente, il loro esempio sembra strano. L'ho provato; Thumbprintnon è richiesto nei dati di configurazione per la crittografia delle credenziali. CertificateFileè necessario, tuttavia, e deve trovarsi nei dati di configurazione, quindi se non si utilizzavano i dati di configurazione prima, lo sarà ora.