Microsoft AZ-801: Azure Arc e Gestione di Server Ibridi — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure Arc porta i server non Azure, sia on-premise che in altri cloud, sotto lo stesso piano di controllo delle risorse native di Azure. I server abilitati per Arc vengono esposti come risorse Azure di prima classe, consentendo di applicare Azure Policy, gestire le estensioni, raccogliere dati di telemetria con Azure Monitor Agent, orchestrare il patching con Update Management Center e standardizzare con Azure Automanage. La padronanza dei modelli di onboarding, dei requisiti dell’agente e di rete, del controllo degli accessi in base al ruolo (RBAC) e della governance su larga scala è essenziale per operare flotte ibride in modo sicuro e coerente.

Server abilitati per Azure Arc: onboarding, prerequisiti, networking, RBAC e accesso sicuro

L’onboarding connette una macchina ad Azure installando l’agente Azure Connected Machine (azcmagent), che registra un server in una sottoscrizione, un gruppo di risorse e una regione specifici.

• L’onboarding interattivo tramite script è il modo più rapido per iniziare. Dal portale di Azure, genera lo script “Aggiungi server” ed eseguilo localmente. Lo script scarica e installa l’agente, quindi utilizza il flusso ‘device code’ per autenticare il tuo utente su Azure Resource Manager e creare la risorsa ConnectedMachine.
• L’onboarding basato su service principal è il metodo raccomandato per l’ambiente di produzione. Crea una registrazione di app in Microsoft Entra e una credenziale con privilegi minimi (least-privilege) assegnando il ruolo Azure Connected Machine Onboarding con ambito sul gruppo di risorse di destinazione. Passa l’ID e il segreto del service principal allo script di onboarding per abilitare un deployment non presidiato e su larga scala tramite i tuoi strumenti esistenti (Configuration Manager, Group Policy, Ansible o automazione personalizzata).
• L’abilitazione su larga scala con Azure Policy si concentra sulla standardizzazione post-onboarding. Azure Policy non può installare l’agente Arc su macchine non Azure, ma una volta che le macchine sono connesse ad Arc, è possibile assegnare policy per distribuire automaticamente le estensioni richieste (Azure Monitor Agent, Dependency Agent, Custom Script) e le baseline di configurazione guest a migliaia di server, con rilevamento e correzione delle deviazioni (drift). Questo è l’approccio a minimo sforzo per integrare i server Arc in servizi come Microsoft Sentinel o VM insights, come testato.

I sistemi operativi supportati includono Windows Server 2012 R2, 2016, 2019 e 2022, e le comuni distribuzioni Linux enterprise come Ubuntu LTS (18.04+), RHEL 7–9, SLES 12/15, Oracle Linux 7/8/9, CentOS 7 e Amazon Linux 2. Verifica sempre le versioni precise e i requisiti del kernel nella documentazione aggiornata prima di un rollout su larga scala.

I prerequisiti dell’agente sono semplici: TLS 1.2, traffico HTTPS in uscita (TCP 443), spazio su disco e memoria sufficienti per la cache dell’agente e le estensioni, un orologio di sistema stabile e privilegi di amministratore/root per l’installazione. Per i proxy, l’agente supporta il proxy di sistema su Windows (WinHTTP) e un proxy esplicito su entrambe le piattaforme. Configura azcmagent per usare un proxy con azcmagent config set proxy.url=https://user:pass@proxy:port o sfrutta netsh winhttp set proxy su Windows. Se il tuo ambiente utilizza l’ispezione TLS, importa la CA radice attendibile del proxy nell’archivio certificati della macchina affinché l’agente possa convalidare gli endpoint di Azure.

Le allowlist del firewall e per il traffico in uscita devono consentire il traffico in uscita sulla porta 443 verso Microsoft Entra ID (per l’autenticazione), Azure Resource Manager e i servizi Arc regionali. Se intendi usare Update Management Center e Automanage, consenti anche il traffico verso Windows Update/Microsoft Update e i repository della tua distribuzione Linux, oltre agli endpoint di content delivery che distribuiscono i pacchetti. Arc non richiede alcuna apertura in entrata nel firewall; tutto il traffico di controllo ha origine dal server verso Azure.

L’RBAC per i server abilitati per Arc segue il modello di Azure. Usa i ruoli predefiniti per separare le responsabilità:

• Azure Connected Machine Onboarding consente di creare risorse ConnectedMachine tramite service principal, impedendo al contempo diritti di modifica più ampi.
• Azure Connected Machine Resource Administrator gestisce la risorsa del server Arc e le sue estensioni senza concedere autorizzazioni a livello di sottoscrizione.
• Azure Connected Machine User Login e Azure Connected Machine Administrator Login controllano l’accesso interattivo quando si abilita l’accesso basato su Azure AD tramite SSH (Linux) o RDP/WinRM (Windows). Organizza le macchine Arc in gruppi di risorse che riflettano l’ambiente (Prod/NonProd), la geografia, la business unit o l’anello di patching. Applica l’ambito di policy, blocchi e assegnazioni di ruolo a livello di gruppo di risorse o di gruppo di gestione per semplificare la governance.

L’accesso SSH sicuro senza un indirizzo IP pubblico è supportato tramite il tunneling just-in-time di Arc. Installa l’estensione AADSSHLoginForLinux per abilitare l’autenticazione basata su Entra ID e mappare utenti/gruppi ai principal locali. Gli utenti autorizzati con il ruolo di login appropriato possono eseguire az ssh arc --resource-group RG --name Server01 per stabilire un tunnel TLS effimero in uscita verso il demone SSH del server, senza richiedere porte in entrata, VPN o bastion. Applica Conditional Access e Privileged Identity Management per limitare nel tempo (time-bound) i ruoli di login.

Governance e configurazione su larga scala: configurazione guest di Azure Policy e Automanage

La configurazione guest è la funzionalità di auditing e configurazione in-guest di Azure Policy per Arc. Le policy predefinite coprono baseline comuni, come garantire che l’Azure Monitor Agent sia installato, eseguire l’auditing delle policy per le password, imporre la modalità BitLocker o FIPS su Windows dove supportato, o richiedere facility syslog specifiche su Linux. Assegna queste policy su larga scala agli scope di Arc e la piattaforma distribuirà l’estensione Guest Configuration secondo necessità. Per le policy personalizzate, crea un pacchetto di configurazione guest basato su DSC che esprima lo stato desiderato (ad esempio, una configurazione SSHD sottoposta a hardening o regole di Windows Firewall), pubblicalo come definizione di policy personalizzata, quindi assegnalo al tuo scope di Arc.

Le attività di correzione (remediation) trasformano gli audit in azioni. Le policy con effetti DeployIfNotExists o Modify possono creare o modificare la configurazione, ed è possibile attivare una correzione su richiesta (On-demand remediation) per rendere conformi le macchine esistenti. Per il drift ricorrente, abilita la correzione automatica in modo che il motore delle policy riapplichi lo stato desiderato. Tieni traccia dello stato di conformità (compliance posture) per policy, per macchina e per scope nel pannello Compliance ed esporta le prove per gli enti regolatori dalla stessa interfaccia utente.

Azure Automanage per server abilitati per Arc rende operative le “best practice per le macchine”. Seleziona un profilo di configurazione appropriato per Sviluppo/Test o Produzione e la piattaforma esegue l’onboarding della macchina in un set curato di servizi: Azure Monitor (tramite AMA e un profilo VM insights), Update Management Center con finestre di manutenzione definite, Change Tracking and Inventory, l’abilitazione del piano Microsoft Defender for Cloud e le baseline di sicurezza del sistema operativo di base. Automanage rileva continuamente il drift dal profilo scelto e lo corregge dove supportato, fornendo al contempo visibilità su eventuali elementi che richiedono un intervento manuale in ambienti non-Azure. Poiché Automanage utilizza Azure Policy “sotto il cofano”, è possibile distribuire profili su larga scala e fare affidamento sullo stesso modello di reporting della conformità.

Operatività e monitoraggio: Update Management Center, AMA e DCR, ed estensioni di Arc

Update Management Center (UMC) è il servizio di patching moderno e “agent-light” (con un agente leggero) per macchine Azure e Arc. Valuta continuamente gli aggiornamenti di sicurezza e non di sicurezza mancanti, mostra la conformità per gravità e classificazione e supporta sia configurazioni di manutenzione una tantum che ricorrenti. Definisci finestre di manutenzione con durata massima, comportamento di riavvio (Mai, Se necessario o Sempre), script pre e post-esecuzione e targeting dinamico utilizzando query e tag di Azure, in modo che le nuove macchine Arc che corrispondono ai criteri vengano incluse automaticamente. Per Windows, UMC si approvvigiona da Windows Update/Microsoft Update o da WSUS se configurato; per Linux, dai repository di pacchetti configurati. Utilizza i report di conformità per tracciare la percentuale di macchine aggiornate per scope, visualizzare i fallimenti con codici di errore granulari ed esportare i dati per gli audit. Poiché UMC non dipende da Azure Automation e dal legacy MMA, rappresenta il percorso strategico futuro per l’orchestrazione delle patch.

L’Azure Monitor Agent (AMA) è la pipeline di telemetria unificata per i server abilitati per Arc. Invece di codificare un workspace direttamente sulla macchina, si definiscono delle Regole di Raccolta Dati (Data Collection Rules - DCR) che descrivono:

• Cosa raccogliere: log degli eventi di Windows, facility e severity di syslog di Linux, contatori delle prestazioni e segnali di change tracking.
• Dove inviarli: uno o più workspace di Log Analytics, Azure Monitor Metrics e, facoltativamente, Event Hubs.
• Come trasformarli: data shaping opzionale prima dell’ingestion. Associa le DCR a livello di risorsa, gruppo di risorse, sottoscrizione o management group. Questo disaccoppia la configurazione dalla macchina e rende banale spostare una macchina tra workspace o raccogliere dati diversi in ambienti diversi. VM insights su Arc ora utilizza l’AMA con il profilo DCR di VM insights per le prestazioni; per le mappe delle dipendenze e la topologia dei processi, installa il Dependency Agent.

Le estensioni sono il meccanismo di distribuzione per le funzionalità in-guest. Gestiscile dal pannello Estensioni del server Arc, dalla CLI o tramite Policy:

• Microsoft Monitoring Agent (MMA) è legacy e ritirato per la maggior parte delle soluzioni; utilizzalo solo se una dipendenza non è ancora passata ad AMA.
• Azure Monitor Agent (AMA) è l’attuale standard per log e metriche; abbinalo alle DCR.
• Dependency Agent fornisce mappe dei servizi e dei processi, necessarie per la mappa di VM insights fino a quando la sua sostituzione completa non sarà terminata.
• Custom Script Extension (Windows/Linux) esegue script su larga scala per azioni di bootstrap o correttive quando la correzione tramite Policy non può esprimere la modifica desiderata.
• AADSSHLoginForLinux e AADLoginForWindows abilitano l’accesso con Entra ID. Altre estensioni comuni includono Defender for Endpoint e i client di gestione della configurazione. Usa Azure Policy per garantire che le estensioni richieste siano presenti e funzionanti. Gli aggiornamenti, i rollback e lo stato delle estensioni sono visibili nella risorsa e nel Log attività per scopi di auditing.

Inventario, conformità e reporting con Azure Resource Graph

Le query di Azure Resource Graph (ARG) restituiscono l’inventario e lo stato di conformità quasi in tempo reale per tutti i server abilitati per Arc, senza la necessità di agenti. Utilizzalo per guidare la sincronizzazione del CMDB, l’igiene dei tag e la selezione dell’ambito per le policy e l’applicazione di patch. I pattern comuni includono:

• Inventario ibrido per sistema operativo e posizione:

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, resourceGroup, location, osName = properties.osName, osVersion = properties.osVersion, status = properties.status

• Praticabilità per Sentinel/AMA:

Resources
| where type == "microsoft.hybridcompute/machines"
| extend hasAMA = todynamic(properties.extensions) has_any (x: x.name =~ "AzureMonitorWindowsAgent" or x.name =~ "AzureMonitorLinuxAgent")
| project name, hasAMA

• Reporting basato su tag e targeting per anello di patch (patch ring):

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, patchRing = tags.PatchRing, owner = tags.Owner
| summarize count() by patchRing

• Riepilogo della conformità alle policy:

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

Queste query sono alla base degli ambiti dinamici in Update Management Center, delle assegnazioni di Automanage e dei dashboard. Standardizzare un set minimo di tag (Environment, PatchRing, BusinessUnit, Owner) durante l’onboarding in modo che ARG rimanga sempre utilizzabile.

Scenario pratico

Contoso Ltd. possiede 600 VM on-premise Windows Server e Linux ospitate in due datacenter, gestite da Configuration Manager e Ansible. La direzione richiede monitoraggio standardizzato, applicazione mensile delle patch con rigorose finestre di manutenzione al sabato, onboarding in Sentinel e accesso SSH sicuro per gli ingegneri senza esporre IP pubblici. Vogliono anche prove di conformità per gli auditor e un minimo sforzo amministrativo continuo.

1. Preparare l’accesso con privilegi minimi

• Creare un’entità servizio (service principal) con ambito limitato ai RG che conterranno le macchine Arc e assegnare il ruolo Azure Connected Machine Onboarding. Ciò consente l’onboarding non presidiato tramite gli strumenti esistenti senza concedere autorizzazioni estese. Perché: L’onboarding basato su entità servizio è scalabile e soddisfa il principio del privilegio minimo.

2. Eseguire l’onboarding delle macchine con l’automazione

• Utilizzare lo script di onboarding di Arc generato con l’entità servizio in Configuration Manager per Windows e Ansible per Linux per installare azcmagent e registrare ogni server nel RG appropriato (taggato con Environment e PatchRing). Perché: Riutilizza gli strumenti di deployment esistenti per un rollout rapido e coerente e integra i tag per la governance a valle.

3. Stabilire l’uscita di rete e del proxy

• Garantire il traffico in uscita sulla porta 443 verso Entra ID, Azure Resource Manager, gli endpoint regionali di Arc, Windows Update/Microsoft Update e i repository delle distribuzioni. Configurare le impostazioni del proxy di azcmagent e importare la CA radice per l’ispezione TLS dove necessario. Perché: Garantisce la salute dell’agente e delle estensioni, il recupero degli aggiornamenti ed evita deviazioni di connettività.

4. Applicare le baseline con la configurazione guest di Azure Policy

• Assegnare le policy predefinite per distribuire l’estensione Guest Configuration, l’AMA e il Dependency Agent. Applicare un pacchetto di configurazione guest personalizzato per rafforzare (harden) le impostazioni SSH e RDP. Abilitare la correzione automatica per le impostazioni critiche. Perché: Le policy esprimono lo stato desiderato su larga scala, forniscono il rilevamento delle deviazioni (drift detection) e correggono le discrepanze.

5. Standardizzare le operazioni con Automanage

• Assegnare il profilo Automanage for Arc Production ai RG di produzione e il profilo Dev/Test a quelli non di produzione. Esaminare eventuali elementi contrassegnati come manuali per risorse non-Azure. Perché: Automanage applica continuamente le best practice con il minimo sforzo da parte dell’operatore.

6. Configurare il monitoraggio e l’onboarding in Sentinel

• Creare delle DCR (Data Collection Rules) per raccogliere Windows SecurityEvent, le facility di autenticazione di Syslog e i contatori delle prestazioni in un’area di lavoro Log Analytics centrale collegata a Microsoft Sentinel. Utilizzare Azure Policy per associare le DCR a tutte le macchine Arc e per distribuire i solution pack di Sentinel secondo necessità. Perché: AMA + DCR disaccoppiano la raccolta dati dalle macchine e Azure Policy fornisce il metodo di onboarding a minimo sforzo convalidato negli scenari d’esame.

7. Orchestrazione del patching con Update Management Center

• Definire configurazioni di manutenzione ricorrenti mensili per ogni tag PatchRing con una finestra di 4 ore il sabato, riavvio se necessario e hook di notifica. Utilizzare ambiti dinamici basati sui tag in modo che le nuove macchine vengano incluse automaticamente. Perché: UMC fornisce una governance delle patch leggera (agent-light), guidata dai tag e con reporting di conformità verificabile.

8. Abilitare l’accesso SSH sicuro senza IP pubblici

• Distribuire AADSSHLoginForLinux tramite Policy e concedere agli ingegneri il ruolo Azure Connected Machine User Login sui RG di destinazione tramite Privileged Identity Management. Istruire gli ingegneri a utilizzare az ssh arc con l’attivazione just-in-time. Perché: Il tunneling di Arc elimina la necessità di ingressi pubblici o jump host, e Entra ID più PIM forniscono un accesso con privilegi minimi e limitato nel tempo.

9. Reporting e audit con Resource Graph e Compliance

• Creare cartelle di lavoro (workbook) ARG per mostrare l’inventario Arc per ambiente, la copertura di AMA/Dependency Agent, i trend di conformità alle policy e la conformità delle patch di UMC per PatchRing. Esportare mensilmente le prove di conformità. Perché: ARG e i piani di conformità di Policy/UMC centralizzano le prove e riducono l’onere di audit.

Combinando l’onboarding basato su entità servizio, la distribuzione di estensioni e configurazioni guest guidata da Policy, i profili Automanage, AMA con DCR, il patching con UMC, Arc SSH e il reporting di Resource Graph, Contoso ottiene una gestione dei server ibridi sicura, coerente e verificabile con un intervento manuale minimo.

← Sicurezza di Active Directory Domain Services · Tutti i domini · Crittografia →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →