Questa guida presenta le best practice per l'esecuzione di Active Directory su Trusted Cloud by S3NS. La guida si concentra su pratiche specifiche per Trusted Cloud o di particolare importanza per il deployment di Active Directory su Trusted Cloud. La guida è complementare alle best practice generali per la protezione di Active Directory pubblicate da Microsoft.
Architettura
Le sezioni seguenti descrivono in dettaglio le best practice relative all'architettura.
Utilizza il pattern di architettura più adatto alle tue esigenze
Per eseguire il deployment di Active Directory su Trusted Cloud, devi prima decidere quale dominio e quale architettura della foresta utilizzare. Se utilizzi già Active Directory, devi anche decidere se e come integrare i due ambienti.
La scelta del design più adatto alla tua situazione dipende da una serie di fattori, tra cui la progettazione della rete on-premise, le modalità di interazione tra risorse on-premise e suTrusted Cloud , nonché i requisiti di disponibilità e autonomia amministrativa. Consulta i nostri pattern per l'utilizzo di Active Directory in un ambiente ibrido per capire in che modo questi fattori devono determinare il tuo design.
Se vuoi mantenere un confine di attendibilità traTrusted Cloud e il tuo ambiente on-premise, valuta la possibilità di implementare il pattern foresta di risorse. In questo pattern, esegui il deployment di una foresta separata su Trusted Cloud e utilizzi un trust tra foreste unidirezionale per integrare la foresta Trusted Cloud con la foresta Active Directory on-premise esistente.
Separa i test dalla produzione
A seconda dell'utilizzo di Active Directory, potrebbe essere necessario eseguire modifiche frequenti in Active Directory durante lo sviluppo e il test delle applicazioni. Gli sviluppatori potrebbero avere bisogno di creare e modificare account Active Directory, modificare le appartenenze ai gruppi se le applicazioni utilizzano i gruppi per gestire l'autorizzazione, oppure unire e rimuovere computer.
Per evitare che le attività di sviluppo e test influiscano sui workload di produzione o compromettano la sicurezza del deployment, ti consigliamo di eseguire il deployment di un dominio o di una foresta Active Directory separati per lo sviluppo e i test.
Un dominio o una foresta di sviluppo e test separati ti consentono inoltre di verificare le modifiche amministrative prima di applicarle in produzione. Alcuni esempi di queste modifiche includono esperimenti con le policy di gruppo, test degli script di automazione o azioni potenzialmente rischiose come l'aumento del livello funzionale di una foresta.
Configura la federazione Cloud Identity oltre a eseguire il deployment di Active Directory su Trusted Cloud by S3NS
Il deployment di Active Directory su Trusted Cloud ti consente di gestire le VM Windows su Trusted Cloud, può consentire agli utenti di accedere alle VM Windows utilizzando i loro account utente esistenti e supporta le applicazioni che si basano su Kerberos, NTLM o LDAP per l'autenticazione.
Tuttavia, per utilizzare la consoleTrusted Cloud , lo strumento a riga di comando gcloud o altri strumenti di Google e Trusted Cloud , devi eseguire l'autenticazione con un'identità Google. Pertanto, il deployment di Active Directory su Trusted Cloud non sostituisce la federazione di Active Directory esistente conTrusted Cloud se intendi utilizzare Active Directory come sistema principale per la gestione degli utenti.
Ad esempio, se esegui il deployment di una foresta separata su Trusted Cloud, puoi configurare la federazione con Active Directory on-premise come illustrato nel seguente diagramma. Gli utenti con account in Active Directory on-premise possono quindi utilizzare gli strumenti che richiedono un'identità Google, oltre alle tue applicazioni che si basano su Active Directory per l'autenticazione.
Se invece decidi di estendere la foresta o il dominio esistente a Trusted Cloud, hai anche la possibilità di utilizzare i domain controller e i server FS AD di cui è stato eseguito il deployment su Trusted Cloud per configurare la federazione.
La federazione ti consente inoltre di applicare un ciclo di vita comune per gli Account Google e Active Directory, in modo che, quando disattivi un account utente in Active Directory on-premise, venga sospeso anche l'utente Google corrispondente.
Networking
La sezione seguente illustra le best practice relative al networking.
Esegui il deployment di Active Directory in una rete VPC condivisa
Per consentire l'utilizzo di Active Directory in più progetti, esegui il deployment dei domain controller in una rete VPC condivisa. L'utilizzo di una rete VPC condivisa presenta diversi vantaggi:
Potenzialmente, puoi eseguire il deployment di ogni applicazione che potrebbe richiedere l'accesso ad Active Directory in un progetto separato. L'utilizzo di progetti separati aiuta a isolare le risorse e gestire l'accesso singolarmente.
Puoi utilizzare un progetto dedicato per i domain controller Active Directory, che ti consente di avere un controllo granulare su quali dei tuoi utenti possono accedere alle risorse Trusted Cloud correlate.
Le reti VPC condivise ti consentono di centralizzare la gestione degli indirizzi IP e la configurazione dei firewall, contribuendo a garantire la coerenza tra più progetti.
Poiché i VPC sono una risorsa globale, puoi utilizzare la stessa rete VPC condivisa in più regioni.
Non esporre i domain controller all'esterno
Per ridurre la superficie di attacco di Active Directory, evita di assegnare indirizzi IP esterni ai domain controller.
Poiché le istanze VM senza indirizzi IP esterni non hanno accesso a internet per impostazione predefinita, devi eseguire ulteriori passaggi per assicurarti che l'attivazione di Windows e gli aggiornamenti di Windows funzionino regolarmente sui domain controller.
Per supportare l'attivazione di Windows, abilita l'accesso privato Google nella subnet in cui prevedi di eseguire il deployment dei domain controller e assicurati che le istanze VM possano accedere a kms.windows.googlecloud.com. In questo modo, l'attivazione può avvenire senza accesso diretto a internet.
Esistono diverse opzioni per supportare gli aggiornamenti di Windows:
Se hai un server WSUS on-premise, puoi configurare la connettività ibrida e i domain controller in modo che utilizzino il server WSUS come origine per gli aggiornamenti.
Puoi attivare l'accesso a internet tramite un gateway NAT eseguendo il deployment di Cloud NAT.
Se hai configurato la connettività ibrida, puoi anche instradare il traffico in uscita tramite un gateway NAT o un server proxy on-premise.
Prenota in anticipo gli indirizzi IP statici per i domain controller
Poiché i domain controller fungono da server DNS, devi assegnare un indirizzo IP che non cambia. Per farlo, configura indirizzi IP interni statici per le VM dei domain controller.
Quando prenoti un indirizzo IP, il comportamento predefinito è la scelta automatica di un indirizzo non utilizzato. Per assicurarti che gli indirizzi IP dei domain controller siano facili da memorizzare, prenota un indirizzo IP interno statico.
Sui domain controller, imposta l'indirizzo IP della scheda di rete sullo stesso indirizzo. Anche se questo passaggio è facoltativo, impedisce ad Active Directory di emettere messaggi di avviso che indicano che l'indirizzo IP del computer potrebbe essere ancora assegnato in modo dinamico.
Esegui il deployment dei domain controller in più zone
Per aumentare la disponibilità, esegui il deployment di almeno due domain controller e distribuiscili su più zone. Poiché le subnet e gli indirizzi IP non sono legati a una zona, puoi eseguire il deployment di tutti i domain controller in un'unica subnet.
Se prevedi di eseguire il deployment dei workload in più regioni, valuta la possibilità di eseguire il deployment dei domain controller in ogni regione pertinente. Poiché le subnet sono una risorsa di regione, il deployment in un'altra regione richiederà un'altra subnet.
Crea un sito per regione
Quando un client tenta di individuare un domain controller, cerca per primo un domain controller nel sito Active Directory corrispondente all'indirizzo IP del client. Se non è disponibile alcun domain controller in questo sito, il client procede e tenta di localizzarne uno in un altro sito.
Puoi sfruttare questo comportamento creando un sito separato per ogni regione in cui esegui il deployment di domain controller o client di dominio. I client daranno quindi automaticamente la preferenza all'utilizzo dei domain controller situati nella stessa regione, il che può contribuire a ridurre la latenza e il costo del trasferimento di dati in uscita tra le regioni.
Se hai client in regioni in cui non è presente un domain controller, puoi influenzare i domain controller scelti da questi client modificando i costi dei sitelink in modo che riflettano la vicinanza geografica delle regioni e attivando l'impostazione Prova sito più vicino successivo.
L'utilizzo di più siti influisce sul comportamento della replica tra i domain controller. Uno svantaggio dell'utilizzo di più siti può essere che la replica tra siti avviene con meno frequenza rispetto alla replica all'interno dello stesso sito.
Tuttavia, non puoi creare siti Active Directory in Microsoft Active Directory gestito, perché quest'ultimo non supporta la funzionalità Siti e servizi Active Directory.
Utilizza le zone di forwarding privato di Cloud DNS
Quando crei una nuova istanza VM in Compute Engine, il sistema operativo viene preconfigurato per utilizzare un server DNS predefinito che fornisce l'accesso al DNS interno e al DNS pubblico.
Prima di poter unire un computer a un dominio Active Directory, devi assicurarti che il computer sia in grado di risolvere i record DNS gestiti da Active Directory. Il server DNS predefinito configurato da Compute Engine per un'istanza VM fornisce accesso al DNS interno e al DNS pubblico, ma non sarà in grado di risolvere i nomi DNS gestiti da Active Directory.
Crea una zona di forwarding DNS privato in Cloud DNS per consentire ai client di risolvere i record DNS gestiti da Active Directory. Configura la zona per inoltrare le query corrispondenti al tuo dominio Active Directory ai tuoi domain controller.
L'utilizzo di una zona di forwarding DNS privato offre diversi vantaggi rispetto alla configurazione dei client per l'utilizzo diretto dei tuoi domain controller Active Directory come server DNS:
Non è necessario modificare la configurazione di rete delle istanze VM. Questo semplifica la procedura di creazione di nuove VM.
Quando promuovi o retrocedi un domain controller, devi solo aggiornare la configurazione della zona di forwarding DNS privato, senza modificare le impostazioni dei client.
Le istanze VM hanno ancora accesso al DNS interno.
Tutti i record DNS che non corrispondono al tuo dominio Active Directory verranno gestiti da Cloud DNS, riducendo il carico sui domain controller.
Se utilizzi più domini, crea una zona di forwarding DNS privato separata per ogni dominio Active Directory.
Le zone di forwarding privato Cloud DNS hanno come ambito un singolo VPC. Se utilizzi più VPC connessi tramite peering, puoi esporre le zone di forwarding privato ad altri VPC configurando il peering DNS.
Devi comunque configurare manualmente le impostazioni DNS sui domain controller. Utilizza 127.0.0.1 come server DNS principale e, facoltativamente, l'indirizzo IP di un altro domain controller come server DNS secondario. Per saperne di più, consulta Impostazioni DNS consigliate e opzioni alternative.
Connettività ibrida
La sezione seguente illustra le best practice relative alla connettività ibrida.
Utilizza il forwarding del traffico DNS in entrata per risolvere i nomi DNS Trusted Cloud da on-premise
I client della tua rete on-premise potrebbero avere bisogno di risolvere i nomi DNS delle risorse di cui è stato eseguito il deployment su Trusted Cloud. Se estendi la foresta o esegui il deployment di una foresta di risorse suTrusted Cloud, utilizza il forwarding del traffico DNS in entrata per consentire ai client on-premise di cercare i record DNS per le risorse di cui è stato eseguito il deployment su Trusted Cloud. Per utilizzare il forwarding del traffico in entrata, crea una policy del server DNS per allocare un indirizzo IP dell'agente di inoltro del traffico in entrata e rendilo accessibile alla rete on-premise.
Se il dominio DNS utilizzato su Trusted Cloud (ad esempio cloud.example.com) è un sottodominio del dominio DNS utilizzato on-premise (ad esempio example.com), configura la delega DNS. Crea un record NS nel dominio on-premise che punti all'indirizzo IP dell'agente di inoltro del traffico in entrata. Il record NS fa sì che i client che tentano di cercare un nome DNS nel dominio ospitato su Trusted Cloudvengano reindirizzati all'indirizzo IP dell'agente di inoltro del traffico in entrata.
Se i domini DNS utilizzati su Trusted Cloud e in Active Directory on-premise sono diversi (ad esempio cloud.example.com e corp.example.com), configura il forwarding DNS condizionale nei tuoi domini on-premise e utilizza l'indirizzo IP dell'agente di inoltro del traffico in entrata come destinazione. Quando viene richiesta la risoluzione di un nome DNS nel dominio ospitato su Trusted Cloud, i domain controller on-premise inoltrano la richiesta all'indirizzo IP dell'agente di inoltro del traffico in entrata.
Quando utilizzi il forwarding DNS in entrata, assicurati che i firewall siano configurati adeguatamente.
Il forwarding DNS in entrata non è necessario se estendi il tuo dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono automaticamente replicati su Trusted Cloud e nell'ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizza il forwarding DNS in uscita per risolvere i nomi DNS on-premise da Trusted Cloud
I client in esecuzione su Trusted Cloud potrebbero avere bisogno di risolvere i nomi delle risorse di cui è stato eseguito il deployment on-premise. Se espandi la foresta o se esegui il deployment di una foresta di risorse su Trusted Cloud, crea una zona di forwarding privato in Cloud DNS per inoltrare le query DNS per i tuoi domini on-premise ai tuoi server DNS on-premise.
Quando utilizzi il forwarding DNS in uscita, assicurati che i firewall siano configurati adeguatamente.
Il forwarding DNS in uscita non è necessario se estendi il tuo dominio esistente ad Active Directory. In questo scenario, tutti i record DNS del dominio vengono automaticamente replicati su Trusted Cloud e nell'ambiente on-premise e resi disponibili per la ricerca in entrambi gli ambienti.
Utilizza i tunnel VPN per proteggere il traffico LDAP
Active Directory fa un uso intensivo del protocollo LDAP. A differenza della maggior parte degli altri protocolli utilizzati da Active Directory, LDAP non è criptato per impostazione predefinita.
Trusted Cloud garantisce che il traffico tra le macchine virtuali sia criptato, pertanto l'utilizzo di LDAP non criptato all'interno del VPC è accettabile. Se colleghi il tuo VPC a una rete on-premise, assicurati che il traffico LDAP venga scambiato solo tramite canali attendibili.
Se utilizzi Cloud VPN per connettere Trusted Cloud e la tua intranet, il traffico viene criptato automaticamente utilizzando IPSec traTrusted Cloud e il tuo endpoint VPN on-premise.
Cloud Interconnect e Partner Interconnect non forniscono la crittografia. Per garantire comunicazioni sicure, stabilisci un tunnel VPN sulla connessione Interconnect utilizzando un'appliance VPN disponibile su Google Cloud Marketplace.
Utilizza l'autenticazione selettiva e AES per i trust tra foreste
Quando crei una relazione di trust tra le foreste di Active Directory, preferisci i trust tra foreste rispetto a quelli esterni e sfrutta le seguenti funzionalità per migliorare la sicurezza:
Attiva l'autenticazione selettiva per i trust in uscita nella foresta di risorse. L'autenticazione selettiva garantisce che gli utenti della foresta dell'organizzazione non possano accedere alle risorse della foresta delle risorse, a meno che non venga concessa l'autorizzazione esplicita.
Attiva l'applicazione forzata del confine della foresta per la delega completa di Kerberos per i trust in entrata nella foresta dell'organizzazione. Questa funzionalità aiuta a prevenire gli attacchi di escalation dei privilegi impedendo alle risorse nella foresta delle risorse di richiedere TGT (Ticket Granting Ticket) agli utenti nella foresta dell'organizzazione.
Attiva l'opzione L'altro dominio supporta la crittografia AES Kerberos quando crei i trust. Questa opzione garantisce che i ticket utilizzati per l'autenticazione tra foreste vengano criptati utilizzando AES anziché l'algoritmo RC4 meno sicuro.
Sicurezza
La sezione seguente illustra le best practice relative alla sicurezza.
Evita interferenze della sicurezza di Trusted Cloud con la sicurezza di Active Directory
Active Directory ti offre un controllo granulare sugli utenti autorizzati ad accedere alle risorse. Quando esegui il deployment delle macchine come istanze VM in Compute Engine e gli utenti hanno accesso al progetto Trusted Cloudsottostante, devi considerare percorsi aggiuntivi che potrebbero consentire a un utente di accedere a una macchina:
Un membro di un progetto a cui è stato assegnato il ruolo Compute Instance Admin in un progetto Trusted Cloud può utilizzare la funzionalità di reimpostazione della password per creare account amministratore locali. Gli account amministratore locali rappresentano una minaccia per la sicurezza del tuo dominio Active Directory, in quanto possono essere utilizzati per compromettere le policy di gruppo o per installare software dannoso che potrebbe acquisire le credenziali di dominio di altri utenti che hanno eseguito l'accesso.
Aggiungendo uno script di avvio, un membro del progetto con privilegi può inserire in una VM codice dannoso che viene eseguito come
nt authority\systemal successivo riavvio della macchina.Utilizzando la console seriale, un membro del progetto con privilegi può anche accedere alla console di amministrazione speciale (SAC) di Windows. Windows considera gli accessi tramite SAC come accessi locali. Pertanto, la SAC può essere utilizzata impropriamente per eludere policy che negano gli accessi tramite RDP, ma non quelli locali.
Un membro del progetto con privilegi può utilizzare la SAC per inviare un comando
crashdump, che può causare la scrittura di un dump della memoria sul disco. Un dump della memoria di questo tipo potrebbe includere informazioni sensibili e credenziali.Montando il disco permanente su una VM diversa o utilizzando gli snapshot, un membro del progetto con privilegi potrebbe essere in grado di accedere ai contenuti del disco, inclusi potenzialmente i dump della memoria, di macchine a cui l'utente non avrebbe altrimenti l'autorizzazione per accedere.
Quando utilizzi Microsoft Active Directory gestito, per impostazione predefinita hai una protezione migliore da questi percorsi di accesso aggiuntivi. Il servizio non consente agli utenti con privilegi nel tuo progetto di reimpostare la password dell'amministratore di dominio, eseguire script di avvio o accedere alla console seriale sulle VM del domain controller AD.
Per ridurre ulteriormente questi rischi, assicurati che le autorizzazioni IAM dei progetti contenenti istanze VM aggiunte al dominio siano gestite in base al principio del privilegio minimo. Puoi ridurre ulteriormente il rischio utilizzando policy dell'organizzazione, policy di gruppo e Shielded VM:
Utilizza una policy dell'organizzazione per disattivare l'accesso alla porta seriale.
Applica una policy di gruppo che impedisce la creazione di account amministratore locali disattivando l'account manager. Definisci una preferenza per i file INI nella policy di gruppo (Configurazione computer > Preferenze > Impostazioni di Windows > File INI) per applicare la seguente impostazione:
- Azione: Aggiornamento
- Percorso file:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nome sezione:
accountManager - Nome proprietà:
disable - Valore proprietà:
true
Applica una policy di gruppo che rimuove gli account amministratore locali dalle istanze VM. Utilizza la funzionalità Utenti e gruppi locali (Configurazione computer > Preferenze > Impostazioni del Pannello di controllo > Utenti e gruppi locali) per rimuovere l'appartenenza al gruppo Amministratori e ad altri gruppi sensibili.
Valuta la possibilità di utilizzare Shielded VM in combinazione con la crittografia dei dischi BitLocker per impedire che i dischi permanenti o gli snapshot siano leggibili da utenti non autorizzati.
Evita interferenze tra la sicurezza di Active Directory e la sicurezza di Trusted Cloud
In un dominio Active Directory, le macchine ritengono attendibili i domain controller per gestire l'autenticazione e l'autorizzazione per loro conto. A meno che non sia limitato dalla policy di gruppo, dalla policy di sicurezza locale di una macchina o dall'autenticazione selettiva, un utente che ha dimostrato la propria identità a uno dei domain controller è autorizzato ad accedere a qualsiasi computer del dominio.
La possibilità per gli utenti di Active Directory di accedere a qualsiasi computer potrebbe consentire a malintenzionati di eseguire movimenti laterali all'interno di un dominio. Questi movimenti laterali possono portare a escalation dei privilegi se alcune istanze VM sono esenti dalle limitazioni del firewall o utilizzanoservice account Trusted Cloud : le credenziali di un service account sono accessibili a tutti i processi e gli utenti di un'istanza VM. Pertanto, qualsiasi utente che può utilizzare Active Directory per accedere a una macchina può accedere a queste credenziali del service account per ottenere l'accesso a qualsiasi risorsa Trusted Cloudaccessibile al service account.
Quando configuri Microsoft Active Directory gestito, il servizio crea un gruppo per facilitare la concessione a utenti specifici della possibilità di accedere tramite RDP alle VM aggiunte al dominio.
Per ridurre il rischio di movimenti laterali, organizza gli utenti in livelli amministrativi e utilizza le policy di gruppo Nega l'accesso a questo computer dalla rete e Nega l'accesso tramite Servizi Desktop remoto per limitare l'accesso alle VM in base al livello.
In una topologia di foresta delle risorse, sfrutta il vantaggio aggiuntivo dell'autenticazione selettiva per limitare ulteriormente l'insieme di utenti di altre foreste autorizzati ad accedere alle tue VM. Puoi semplificare la gestione delle autorizzazioni dell'autenticazione selettiva allineando le strutture delle risorse diTrusted Cloud e Active Directory: se le unità organizzative di Active Directory sono mappate sui progetti Trusted Cloud , puoi concedere agli utenti il diritto di autenticarsi a un livello corrispondente a un progettoTrusted Cloud .
Nei casi in cui non siano applicabili né l'autenticazione selettiva né le policy di gruppo, crea un service account separato, esporta le chiavi del service account, salvale sul disco locale dell'istanza VM o in una condivisione file e proteggile utilizzando un ACL NTFS in modo che solo gli utenti Active Directory autorizzati possano leggere e utilizzare le chiavi.
Utilizza progetti dedicati per i domain controller
I domain controller svolgono un ruolo fondamentale nella sicurezza di un dominio Active Directory e la compromissione di un singolo domain controller può comportare la compromissione dell'intera foresta di Active Directory.
Per limitare il rischio di accessi non autorizzati, utilizza un progetto Trusted Cloud separato per eseguire il deployment dei domain controller e concedi l'accesso a questo progetto sulla base del principio del privilegio minimo. Quando crei il progetto, tieni presente che alcune autorizzazioni potrebbero essere ereditate dalle cartelle principali. Per evitare di concedere inavvertitamente l'accesso tramite le autorizzazioni ereditate, ti consigliamo di creare il progetto al di fuori della normale gerarchia delle cartelle.
Quando configuri le policy IAM per il progetto, presta particolare attenzione a limitare l'accesso alle istanze VM, ai dischi permanenti che contengono il database ntds.dit, nonché a eventuali località di archiviazione che potrebbero contenere backup.
Oltre a utilizzare le policy IAM per limitare l'accesso al progetto, proteggi il progetto dall'eliminazione accidentale.
Utilizza VM e progetti separati per la gestione di Active Directory
Per gestire Active Directory, devi essere in grado di utilizzare strumenti come Utenti e computer di Active Directory o il Centro di amministrazione di Active Directory. Questi strumenti richiedono di accedere utilizzando un account di dominio con privilegi, il che rende la macchina su cui esegui questi strumenti un bersaglio appetibile per il furto di credenziali o il keylogging.
Per ridurre al minimo il rischio che malintenzionati ottengano le credenziali di dominio con privilegi, utilizza istanze VM dedicate per l'amministrazione del dominio e tratta queste VM di gestione come workstation con accesso privilegiato:
Utilizza le policy di gruppo per assicurarti che solo un sottoinsieme selezionato di utenti abbia il diritto di accedere alle VM di gestione. Se hai implementato l'amministrazione a più livelli, questo gruppo di utenti corrisponde al livello 0.
Analogamente ai domain controller, le VM di amministrazione possono essere messe a rischio se i membri del progetto creano account amministratore locali, accedono tramite la console seriale o manomettono i dischi permanenti. Per limitare il rischio di accessi non autorizzati, utilizza un progettoTrusted Cloud separato per le VM di amministrazione e concedi l'accesso a questo progetto in base al principio del privilegio minimo.
Se prevedi di accedere alle VM di amministrazione da una rete on-premise utilizzando la connettività ibrida, esegui il deployment delle VM di amministrazione in una subnet VPC dedicata. Una subnet dedicata alle VM di gestione ti consente di distinguere meglio le VM di amministrazione dalle altre VM durante la configurazione dei firewall on-premise. Se utilizzi un VPC condiviso, utilizza autorizzazioni a livello di subnet per assicurarti che solo gli amministratori con privilegi possano eseguire il deployment di istanze VM nella subnet di gestione. Questa pratica contribuisce ad assicurare che, se i firewall on-premise applicano regole diverse per le VM di gestione rispetto alle altre VM, gli utenti non possano eludere le regole firewall inserendo VM non di gestione nella subnet di gestione.
Inoltre, ti consigliamo di limitare la policy di gruppo che gestisce le limitazioni di accesso per le VM di gestione alla subnet di gestione. Questa pratica impone l'allineamento tra le restrizioni di accesso (in base a una policy di gruppo) e le regole firewall (in base alla subnet/all'indirizzo IP).
Oltre a utilizzare le policy IAM per limitare l'accesso al progetto, proteggi il progetto dall'eliminazione accidentale.
Utilizza le regole firewall per proteggere i domain controller e i server
I domain controller espongono una serie di servizi, tra cui LDAP, DNS, Kerberos e RPC. A seconda dei casi d'uso, le VM di cui è stato eseguito il deployment su Trusted Cloud, nonché le macchine in esecuzione on-premise, potrebbero dover accedere a sottoinsiemi diversi di questi servizi per sfruttare Active Directory.
Quando utilizzi Microsoft Active Directory gestito, il deployment dei domain controller AD avviene in un progetto tenant dedicato. La rete che ospita i domain controller AD è protetta automaticamente con regole firewall rafforzate specifiche per AD.
Per ridurre la superficie di attacco dei domain controller e delle VM, utilizza i firewall per non consentire alcuna comunicazione di rete non strettamente necessaria. Consulta la nostra guida sull'utilizzo di Active Directory con firewall per informazioni dettagliate sulle configurazioni firewall necessarie per accedere ad Active Directory dal VPC o dalle reti on-premise.
Organizza le risorse e gli utenti di Active Directory in livelli amministrativi
Alcune macchine in una foresta di Active Directory sono più importanti per la sicurezza complessiva di Active Directory rispetto ad altre. I domain controller e le VM di amministrazione sono due esempi di macchine particolarmente critiche e quindi particolarmente sensibili a potenziali attacchi.
Per identificare la criticità di ciascuna delle tue macchine, utilizza una tassonomia di livelli. Sebbene il numero di livelli giusto dipenda dalla tua configurazione specifica, puoi iniziare distinguendo tra tre livelli:
Livello 0 (alta criticità): questo livello include tutte le macchine fondamentali per la sicurezza della foresta Active Directory. Una volta compromessa una singola macchina di livello 0, devi presumere che l'intera foresta sia compromessa.
Livello 1 (critico): questo livello include la maggior parte dei server nel tuo ambiente, inclusi i server di applicazioni e i server di database. Un server di primo livello compromesso potrebbe avere un impatto sostanziale sull'attività, ma non rappresenta una minaccia immediata per l'intera foresta.
Livello 2 (normale): questo livello include workstation o altre macchine per uso generico. La compromissione di una macchina di livello 2 dovrebbe avere solo un impatto limitato sull'attività e sulla sicurezza complessiva.
Sebbene l'impatto immediato di una macchina di livello 2 compromessa possa sembrare limitato, esiste il rischio di effetti a catena: quando un utente che dispone dell'accesso amministrativo a macchine di livello 0 o 1 viene indotto a eseguire l'accesso a una macchina di livello 2 compromessa, potrebbe cadere vittima di un keylogger o di altre forme di furto di credenziali. Le credenziali acquisite potrebbero essere utilizzate per attaccare macchine di livelli superiori, causando un aumento dell'impatto complessivo.
Per evitare questi effetti a catena, assicurati di classificare non solo le macchine, ma anche gli account utente e limita l'insieme di macchine a cui questi utenti hanno accesso:
Livello 0 (alta criticità): utenti che hanno accesso alle macchine di livello 0.
Livello 1 (critico): utenti che hanno accesso alle macchine di livello 1.
Livello 2 (normale): utenti che hanno accesso alle macchine di livello 2.
Utilizza la seguente tabella come linea guida per stabilire quali utenti devono avere accesso a quali risorse:
| Gruppo | Livello | Accesso al dominio | Accesso a computer di livello 0 | Accesso a computer di livello 1 | Accesso a computer di livello 2 |
|---|---|---|---|---|---|
| Amministratori di Active Directory | 0 | Amministratore | Utente con limitazioni | Bloccato | Bloccato |
| Amministratori dei server di gestione | 0 | Utente con limitazioni | Amministratore | Bloccato | Bloccato |
| Amministratori dei server | 1 | Utente con limitazioni | Bloccato | Amministratore | Bloccato |
| Amministratori delle workstation VDI | 2 | Utente con limitazioni | Bloccato | Bloccato | Amministratore |
| Utenti delle workstation VDI | 2 | Utente con limitazioni | Bloccato | Bloccato | Utente con limitazioni |
Per maggiori dettagli e best practice sull'implementazione di un modello di livelli amministrativi in Active Directory, consulta la documentazione Microsoft.
Quando utilizzi il modello di livelli amministrativi nella foresta di Active Directory, assicurati che la sua integrità non sia minata dalle relazioni di trust della foresta. Se anche la foresta attendibile applica un modello di amministrazione a più livelli, utilizza l'autenticazione selettiva per assicurarti che gli utenti della foresta attendibile possano accedere solo alle risorse all'interno dello stesso livello:
Se la foresta attendibile non implementa l'amministrazione a più livelli, mappala su un determinato livello e utilizza l'autenticazione selettiva per assicurarti che gli utenti della foresta attendibile possano accedere solo alle risorse di quel determinato livello.
Utilizzo di Controlli di servizio VPC e accesso privato Google per gli host on-premise
Le API di Microsoft Active Directory gestito consentono di reimpostare la password dell'amministratore e di eseguire altre operazioni sensibili. Per i deployment di produzione critici, consigliamo di attivare i Controlli di servizio VPC e di utilizzare Accesso privato Google per gli host on-premise per aumentare la sicurezza.
Gestione
La sezione seguente illustra le best practice relative alla gestione di Active Directory.
Allinea le strutture delle risorse di Trusted Cloud e di Active Directory
Quando esegui il deployment di un nuovo dominio o foresta Active Directory suTrusted Cloud, devi definire una struttura di unità organizzative (UO) per organizzare le risorse con il tuo dominio Active Directory. Anziché progettare una struttura completamente nuova o applicare la struttura che utilizzi nel tuo ambiente on-premise, crea una struttura di UO in linea con la tua gerarchia delle risorseTrusted Cloud :
Se utilizzi un modello di amministrazione a più livelli, le UO di primo livello devono riflettere i tuoi livelli amministrativi.
Per ogni livello, crea UO per utenti e gruppi. Se prevedi di gestire un numero elevato di utenti e gruppi, crea UO secondarie in base alle esigenze.
Per ogni livello, crea una UO
Projectse UO secondarie per ogni progettoTrusted Cloud contenente risorse Active Directory. Utilizza l'UO secondaria specifica del progetto per gestire account di computer, service account o altre risorse Active Directory corrispondenti alle risorse del rispettivo progetto Trusted Cloud. Assicurati che esista una mappatura 1:1 tra le UO e i progetti.
Il seguente diagramma mostra una gerarchia di esempio che segue questi principi:
Se il numero di progetti che contengono risorse Active Directory è moderato, puoi creare una struttura di UO piatta sotto l'UO Projects. Se prevedi di gestire un numero elevato di progetti e hai progettato la gerarchia delle risorseTrusted Cloud in modo da utilizzare più livelli di cartelle, ti consigliamo di riflettere questa struttura di cartelle sotto l'UO Projects.
L'allineamento tra struttura di UO di Active Directory e gerarchia delle risorse Trusted Cloud offre diversi vantaggi:
Quando deleghi le autorizzazioni amministrative a un progetto Trusted Cloud utilizzando le policy IAM, potresti dover concedere anche agli utenti del progetto determinati privilegi in Active Directory. Ad esempio, gli amministratori di Compute Engine potrebbero dover essere in grado di unire le macchine al dominio in una determinata UO. L'allineamento tra UO e progetti Trusted Cloud ti consente di concedere queste autorizzazioni con lo stesso livello di granularità sia in Active Directory che in Trusted Cloud.
Se prevedi di utilizzare oggetti policy di gruppo (GPO) per gestire i computer, una struttura di UO che rispecchi la gerarchia delle risorse Trusted Cloud ti aiuta ad assicurarti che i GPO vengano applicati in modo coerente a tutte le VM di un determinato progetto o di una cartella.
Se utilizzi un trust tra foreste con autenticazione condizionale, puoi utilizzare le UO corrispondenti ai progetti Trusted Cloud per concedere l'autorizzazione Autorizzato ad autenticarsi in base al progetto.
Quando elimini un progetto in Trusted Cloud, puoi semplicemente eliminare l'UO associata, riducendo il rischio di lasciare risorse inattive nella directory.
Se ritieni che la struttura di UO debba discostarsi dalla struttura del progetto, questo potrebbe indicare che la struttura del progetto è troppo granulare o troppo approssimativa.
Utilizza i server di riferimento orario di Google
L'autenticazione Kerberos si basa su timestamp come parte del protocollo. Perché l'autenticazione riesca, gli orologi delle macchine client e server devono essere sincronizzati entro un determinato margine. Per impostazione predefinita, Active Directory non consente più di 5 minuti di differenza.
Di seguito è riportata la configurazione predefinita per la sincronizzazione dell'orario in un ambiente Active Directory on-premise:
- I computer associati al dominio sincronizzano l'orario con un domain controller.
- I domain controller sincronizzano l'orario con l'emulatore PDC del dominio.
- Gli emulatori PDC di tutti i domini sincronizzano l'orario con l'emulatore PDC del dominio principale della foresta.
In questa configurazione, l'emulatore PDC del dominio principale della foresta è la fonte dell'orario principale per Active Directory ed è comune configurare questa macchina perché utilizzi un server NTP esterno come origine dell'orario.
In Compute Engine, la configurazione predefinita per le VM Windows è l'utilizzo del server metadati (metadata.google.internal) come server NTP, che a sua volta si basa sui server NTP di Google per ottenere l'orario corretto. L'unione di una VM a un dominio Active Directory non modifica questa configurazione predefinita.
Mantieni la configurazione predefinita di Compute Engine se non hai eseguito il deployment dell'emulatore PDC del dominio principale della foresta al di fuori di Trusted Cloud.
Se hai eseguito il deployment dell'emulatore PDC al di fuori di Trusted Cloud, configuralo per utilizzare time.google.com come origine NTP.
In alternativa, puoi ripristinare il comportamento predefinito di Active Directory, che prevede la sincronizzazione dell'orario con l'emulatore PDC, riconfigurando le VM Compute Engine in modo che utilizzino l'origine NTP DOMHIER e configurando le regole firewall per consentire il traffico NTP in entrata (UDP/123) ai tuoi domain controller.
Consolida e monitora gli audit log
Quando esegui il deployment di Active Directory su Trusted Cloud, la sicurezza della foresta Active Directory e dei progetti Trusted Cloud è interconnessa: le attività sospette in Active Directory e Windows potrebbero mettere a rischio la sicurezza di altre risorse, così come le attività sospette in Trusted Cloud potrebbero mettere a rischio Active Directory.
La verifica della coerenza degli audit log è uno strumento importante per identificare tempestivamente minacce o configurazioni errate e ricostruire ed esaminare le attività passate. Cloud Audit Logs ti consente di acquisire e analizzare audit log delle attività di amministrazione e audit log di accesso ai dati. Analogamente, puoi utilizzare il logging delle regole firewall e i log di flusso VPC per analizzare il traffico di rete. Tuttavia, questi servizi della piattaforma non sono a conoscenza dei possibili eventi correlati alla sicurezza che si verificano in Active Directory. Per stabilire un audit trail coerente che copra sia gli eventi di controllo relativi alla piattaforma sia quelli relativi ad Active Directory, installa l'agente Cloud Logging sui domain controller e sulle macchine unite al dominio per esportare i log degli eventi di sicurezza di Windows in Cloud Logging.
Per impostazione predefinita, il log degli eventi di sicurezza di Windows potrebbe non acquisire tutti gli eventi di cui hai bisogno per i controlli. Consulta i consigli di Microsoft su come configurare le policy di audit e monitorare Active Directory per rilevare eventuali segni di compromissione per assicurarti di acquisire tutti gli eventi di controllo pertinenti.
Quando hai a che fare con un volume elevato di eventi, è facile che eventi critici sfuggano all'attenzione. Per evitare di farti sfuggire eventi critici, crea metriche basate su log per gli eventi che potrebbero essere particolarmente critici o sospetti e valuta la possibilità di configurare avvisi per ricevere notifiche quando la frequenza degli eventi cambia o supera le soglie accettabili.
Passaggi successivi
Scopri quale pattern per l'utilizzo di Active Directory in un ambiente ibrido è più adatto alla tua situazione.
Scopri come configurare Active Directory per consentire alle VM di unirsi automaticamente a un dominio.
Prova le altre funzionalità di Trusted Cloud . Visualizza i nostri tutorial.