Perché Active Directory da sola non basta piùMicrosoft ha recentemente pubblicato un messaggio diretto ai reparti IT: Active Directory on-premises, da sola, non è più sufficiente per reggere il modello di sicurezza richiesto oggi. Non si tratta di un annuncio di fine vita per AD — che resta il fondamento dell’identità in moltissime organizzazioni — ma di un cambio di prospettiva su cosa un’infrastruttura identity debba garantire quando lavoro ibrido, SaaS, fornitori esterni e ora anche agenti AI accedono quotidianamente a dati e sistemi aziendali.

Per chi gestisce l’infrastruttura identity in produzione, la domanda non è “AD oppure #Entra ID”, ma come costruire un’architettura ibrida che riduca la superficie d’attacco senza un rip-and-replace che nella maggior parte dei contesti enterprise non è realistico né necessario. Vediamo cosa cambia concretamente e quali strumenti usare per la modernizzazione incrementale.

I cinque segnali di un’infrastruttura identity da modernizzareIl ragionamento di Microsoft si basa su cinque aree di attrito che chi amministra AD riconoscerà facilmente:

Onere operativo: patching dei domain controller, gestione #backup, rinnovo certificati, procedure di disaster recovery. Tempo sottratto ad automazione e governance, non alla sicurezza in sé.

Un modello di trust superato: AD è nato per un perimetro di rete definito. Il lavoro ibrido richiede decisioni di accesso basate su rischio dell’utente, postura del dispositivo e contesto — non sulla semplice appartenenza alla rete aziendale.

Proliferazione SaaS: Microsoft 365, Salesforce, Workday, ServiceNow e decine di altre applicazioni #cloud richiedono un piano di identità cloud-native, non solo una federazione con AD.

Utenti esterni: contractor, partner e fornitori richiedono provisioning e deprovisioning sistematico, difficile da gestire con i soli strumenti nativi di AD.

Permessi per agenti AI: applicazioni e agenti che accedono a dati ed eseguono azioni per conto degli utenti richiedono un modello di autorizzazione granulare che AD non è stato progettato per gestire.

Il punto centrale non è la sostituzione, ma la modernizzazione incrementale: spostare autenticazione e controlli di accesso verso il cloud, mantenendo AD per i carichi che ne dipendono ancora, fino a quando anche quelli non vengono modernizzati o dismessi.

Entra Connect Sync vs Cloud Sync: quale scegliereIl primo bivio tecnico in ogni percorso di modernizzazione riguarda lo strumento di sincronizzazione tra AD on-premises e Microsoft Entra ID. Le due opzioni non sono intercambiabili e la scelta ha implicazioni architetturali concrete.

Microsoft Entra Connect Sync è il tool “storico”: richiede un server #Windows dedicato (indicativamente 4 vCPU, 8 GB RAM, 100 GB disco) con un motore di sincronizzazione basato su #SQL Server (LocalDB per ambienti piccoli, SQL Server completo oltre una certa scala). Esegue una sincronizzazione differenziale ogni 30 minuti — non è possibile scendere sotto questa soglia per limiti architetturali — e regge ambienti fino a 500.000+ oggetti. Supporta scenari che Cloud Sync non copre: Pass-through Authentication (PTA), Group Writeback per i gruppi Microsoft 365, e mapping avanzato di attributi personalizzati.

Microsoft Entra Cloud Sync è invece un agente leggero, gestito da Microsoft, installabile su un domain controller o su un server nelle vicinanze, senza alcuna dipendenza da SQL Server. Sincronizza circa ogni 2 minuti — molto più reattivo di Connect Sync — ma è limitato a circa 150.000 oggetti. Supporta solo Password Hash Sync (non PTA), non offre Group Writeback e ha opzioni di mapping attributi più limitate. In compenso offre alta disponibilità nativa tramite agenti multipli auto-ridondanti, contro la modalità staging attivo-passivo di Connect Sync che richiede failover manuale.

In sintesi: Connect Sync resta la scelta per organizzazioni grandi con requisiti di PTA o Group Writeback; Cloud Sync è preferibile per nuovi deployment con requisiti più semplici, dove la cadenza di sync più rapida e il minor carico operativo pesano più della scala massima supportata.

Privileged Identity Management: ridurre l’esposizione degli account con ruoli elevatiUno dei controlli più efficaci per ridurre la superficie d’attacco descritta da Microsoft è l’eliminazione degli account con ruoli privilegiati assegnati in modo permanente (“standing access”). Microsoft Entra Privileged Identity Management (PIM) sposta il modello verso assegnazioni eligible (idonee ma non attive) che l’utente attiva solo quando necessario, per una durata limitata e con giustificazione registrata a fini di audit.

Con Microsoft Graph PowerShell, la gestione di questo flusso è completamente scriptabile. Assegnazione di un ruolo idoneo per 10 ore:

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Aggiunta assegnazione idonea"
"DirectoryScopeId" = "/"
"Action" = "AdminAssign"
"ScheduleInfo" = @{
"StartDateTime" = Get-Date
"Expiration" = @{
"Type" = "AfterDuration"
"Duration" = "PT10H"
}
}
}

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params |
Format-List Id, Status, Action, RoleDefinitionId, Justification, PrincipalIdL’utente attiva poi il ruolo solo quando serve, per un tempo limitato (qui un’ora):

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Attivazione ruolo per intervento pianificato"
"DirectoryScopeId" = "/"
"Action" = "SelfActivate"
"ScheduleInfo" = @{
"StartDateTime" = Get-Date
"Expiration" = @{
"Type" = "AfterDuration"
"Duration" = "PT1H"
}
}
}

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $paramse la disattiva esplicitamente al termine, o lascia che scada automaticamente:

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Fine intervento"
"DirectoryScopeId" = "/"
"Action" = "SelfDeactivate"
}

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $paramsIl parametro DirectoryScopeId impostato a / assegna il ruolo a livello di intero tenant; per limitare lo scope a una specifica unità amministrativa si usa un AppScopeId o lo scope dell’unità stessa. Automatizzare questi flussi via Graph PowerShell (ad esempio da una pipeline di onboarding/offboarding) è spesso più affidabile che affidarsi esclusivamente al portale, soprattutto quando serve integrare l’attivazione dei ruoli con sistemi di ticketing o approvazione esterni.

Autenticazione phishing-resistant e riduzione dei protocolli legacyLa seconda area indicata da Microsoft riguarda i metodi di autenticazione. Nella pratica, questo significa due interventi concreti su ogni tenant: primo, abilitare metodi resistenti al phishing come le chiavi di sicurezza FIDO2 o Windows Hello for Business al posto di SMS e app authenticator basate solo su OTP, che restano vulnerabili ad attacchi MFA fatigue e a proxy AiTM (adversary-in-the-middle). Secondo, disattivare progressivamente i protocolli di autenticazione legacy (Basic Auth su Exchange, POP/IMAP non moderni) che bypassano completamente la Conditional Access basata su rischio, perché non supportano la valutazione di device compliance o segnali di rischio in tempo reale.

Un percorso pragmatico per chi parte da AD puroPer chi gestisce ancora un’infrastruttura AD-centrica, l’indicazione pratica che emerge da questo cambio di approccio è di procedere per fasi, senza inseguire una migrazione big-bang:

Distribuire Entra Connect Sync o Cloud Sync (in base alla scala e ai requisiti di PTA/Group Writeback discussi sopra) per portare le identità in Entra ID mantenendo AD come source of truth.

Attivare Conditional Access basata su rischio utente e postura del dispositivo per le applicazioni cloud, riducendo la dipendenza dal solo perimetro di rete.

Migrare gli account con privilegi elevati a PIM, eliminando le assegnazioni permanenti dei ruoli critici.

Mappare quali applicazioni legacy dipendono ancora da Kerberos/NTLM puro e pianificarne la modernizzazione o l’isolamento in un segmento di rete dedicato.

Estendere la governance delle identità (lifecycle, access review periodiche) anche a utenti esterni, applicazioni registrate e, dove presenti, agenti AI con accesso a dati aziendali.

Nessuno di questi passaggi richiede di spegnere i domain controller. Il valore pratico dell’approccio ibrido è proprio questo: ridurre progressivamente la superficie d’attacco esposta dai componenti legacy, senza interrompere le applicazioni che oggi dipendono ancora da AD, fino a quando la modernizzazione di quelle stesse applicazioni non renderà possibile una dismissione più ampia.

Articolo ispirato e approfondito a partire da: Microsoft Says Active Directory Alone is No Longer Enough for Modern Identity Security, Petri IT Knowledgebase.

Negli ultimi mesi molti team hanno scoperto a proprie spese che il problema più grande di un agente AI in produzione non è la qualità del prompt, ma la sua affidabilità operativa. Un articolo recente su DZone, “Your AI Agent Is a Distributed System, Not a Chatbot”, mette a fuoco un punto che chi progetta sistemi backend conosce bene da anni: se un componente deve sopravvivere a crash, timeout, retry e attese umane di ore, non puoi trattarlo come una semplice chiamata sincrona a un modello. Devi trattarlo come un sistema distribuito, con tutto ciò che questo comporta: stato persistente, checkpoint, idempotenza e recovery.

In questo articolo riprendiamo quei concetti e li caliamo nella pratica con .NET, mostrando come #Azure Durable Functions (o alternative come Temporal) permettano di costruire agenti AI multi-step che non perdono lo stato quando qualcosa va storto — cosa che, in produzione, prima o poi succede sempre.

Perché un chatbot stateless non bastaUn chatbot classico è un ciclo request/response: l’utente scrive, il modello risponde, fine. Un agente AI enterprise, invece, tipicamente deve:

orchestrare più chiamate a modelli e strumenti in sequenza o in parallelo;

interrogare sistemi esterni (CRM, ticketing, knowledge base, database);

attendere l’approvazione di un umano, che può richiedere minuti oppure ore;

gestire fallimenti parziali senza dover ripartire da zero;

garantire che un’azione con effetti collaterali (un rimborso, un invio email, una scrittura su un sistema esterno) non venga eseguita due volte per colpa di un retry.

Nessuno di questi requisiti è nuovo: sono gli stessi problemi che i sistemi distribuiti risolvono da decenni con pattern come saga, checkpointing e idempotency key. La differenza è che oggi il “servizio downstream” spesso è un LLM, e la latenza dominante non è più quella di rete, ma quella dell’attesa umana.

Durable orchestration: lo stato che sopravvive al crashIl pattern architetturale proposto è un runtime di orchestrazione durevole, che mantiene lo stato del workflow indipendentemente dal ciclo di vita del processo che lo esegue. In .NET, l’implementazione più diretta è Azure Durable Functions, che introduce tre concetti chiave:

Orchestrator function: decide “cosa succede dopo”, applica le retry policy e coordina le chiamate, ma non esegue lavoro con effetti collaterali direttamente;

Activity function: esegue il lavoro reale (chiamata al modello, query, side effect) ed è il livello dove si applica l’idempotenza;

Checkpointing automatico: dopo ogni await, il runtime salva lo stato dell’orchestrazione, così un crash del processo non fa perdere il progresso già fatto.

Un’alternativa nota, citata anche nell’articolo originale, è Temporal, che applica lo stesso principio con un modello di programmazione simile ma un runtime a sé stante, spesso preferito in contesti multi-linguaggio o #Kubernetes-native.

Il pattern fan-out/fan-in per agenti multipliQuando un task richiede il contributo di più agenti specializzati (per esempio: un agente diagnostico, uno di ricerca sulla knowledge base, uno che consulta lo storico dei casi e uno che verifica le policy aziendali), il pattern corretto è il fan-out/fan-in: l’orchestratore lancia tutte le attività in parallelo e aggrega i risultati solo quando sono tutte terminate.

Ecco un esempio realistico in C# con il modello isolato di Azure Functions, ispirato agli esempi ufficiali Microsoft:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var caseId = context.GetInput();

// Fan-out: 4 agenti specializzati lanciati in parallelo
var diagnosticTask = context.CallActivityAsync<AgentFinding>(
    "RunDiagnosticAgent", caseId);
var knowledgeTask = context.CallActivityAsync<AgentFinding>(
    "RunKnowledgeSearchAgent", caseId);
var historyTask = context.CallActivityAsync<AgentFinding>(
    "RunHistoricalCaseAgent", caseId);
var policyTask = context.CallActivityAsync<AgentFinding>(
    "RunPolicyAgent", caseId);

// Fan-in: si attende che tutti i task completino
AgentFinding[] findings = await Task.WhenAll(
    diagnosticTask, knowledgeTask, historyTask, policyTask);

// Sintesi della raccomandazione finale
var recommendation = await context.CallActivityAsync<Recommendation>(
    "SynthesizeRecommendation", findings);

return new InvestigationResult(caseId, findings, recommendation);

}Il vantaggio rispetto a un semplice Task.WhenAll in un servizio stateless è che, se il processo host crasha mentre due agenti su quattro hanno già risposto, l’orchestrazione riparte dal checkpoint e non richiama gli agenti già completati.

Human-in-the-loop senza tenere aperta la computeIl collo di bottiglia più comune non è il modello, ma l’attesa di un’approvazione umana. Un workflow che tenesse una funzione serverless “in ascolto” per ore sarebbe insostenibile in termini di costo e di timeout. Il pattern corretto è sospendere l’orchestrazione in attesa di un evento esterno:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
// ... fan-out/fan-in come sopra ...

await context.CallActivityAsync("NotifyHumanReviewer", recommendation);

// Il workflow si sospende senza consumare risorse compute
// fino a quando l'evento non arriva, anche dopo diverse ore
var decision = await context.WaitForExternalEvent<HumanReviewDecision>(
    "HumanReviewCompleted");

if (decision.Approved)
{
    await context.CallActivityAsync("ApplyResolution", recommendation);
}

return new InvestigationResult(caseId, findings, recommendation, decision);

}L’evento viene “consegnato” all’orchestrazione in pausa tramite una chiamata separata (per esempio da una Function HTTP-triggered collegata a un pulsante “Approva” nella UI), e il runtime si occupa di riprendere l’esecuzione esattamente dal punto in cui era stata sospesa.

Idempotenza: il vero rischio nascostoUn runtime durevole garantisce tipicamente semantica at-least-once: dopo un crash, un’attività può essere rieseguita. Questo va benissimo per operazioni pure (una query di lettura), ma è pericoloso per operazioni con side effect (un rimborso, un invio email, una scrittura irreversibile). Il momento critico è il cosiddetto crash window: l’intervallo tra il completamento effettivo di un’azione e il salvataggio del suo checkpoint.

La soluzione è associare a ogni operazione critica una idempotency key deterministica, così che una riesecuzione accidentale venga riconosciuta e ignorata a livello applicativo:

[Function("ApplyGoodwillRefund")]
public static async Task ApplyGoodwillRefund(
[ActivityTrigger] RefundRequest request)
{
string idempotencyKey = $"{request.CaseId}:goodwill-refund";

if (await _paymentService.WasAlreadyProcessedAsync(idempotencyKey))
{
    return; // operazione già eseguita, nessun effetto collaterale duplicato
}

await _paymentService.ProcessRefundAsync(request, idempotencyKey);

}Questo pattern, ben noto a chi lavora con gateway di pagamento, va applicato sistematicamente a ogni activity che tocchi sistemi esterni non idempotenti per natura.

Successo parziale, non tutto-o-nienteSe uno dei quattro agenti fallisce (per esempio, il servizio di knowledge search va in timeout), il sistema non dovrebbe far fallire l’intera indagine. Meglio trattare i risultati come esiti strutturati, distinguendo tra “successo”, “fallito” e “degradato”, e permettere che la sintesi finale proceda comunque, segnalando esplicitamente quali fonti mancano:

public record AgentFinding(
string AgentName,
AgentStatus Status, // Success, Failed, Degraded
string? Result,
string? FailureReason);Questo approccio “graceful degradation” è preferibile a un fallimento totale che obbliga a rieseguire da capo un’indagine costosa in termini di tempo e token consumati.

Osservabilità come requisito di prodottoIn un sistema dove un’indagine può durare ore e coinvolgere quattro o più agenti, la tracciabilità non è un dettaglio tecnico: è parte dell’esperienza utente e, in molti contesti regolamentati, un requisito di audit. Vale la pena tracciare sistematicamente:

workflow instance ID, correlation ID e case ID;

lo stage corrente e la durata di ogni singolo agente;

il numero di retry e il motivo di ogni fallimento;

la latenza di revisione umana (spesso il fattore dominante);

la tracciabilità delle evidenze usate per la raccomandazione finale, per scopi di audit.

ConclusioneIl messaggio di fondo è semplice ma spesso trascurato: il workflow conta più del prompt. Un agente AI ben progettato non è quello con il prompt più raffinato, ma quello costruito su un runtime capace di sopravvivere a crash, gestire attese umane di ore senza sprecare risorse, ed evitare effetti collaterali duplicati. Per chi lavora nello stack .NET, Azure Durable Functions offre oggi gli strumenti necessari per applicare questi pattern senza dover reinventare un motore di orchestrazione da zero; per contesti poliglotta o già containerizzati, Temporal resta un’alternativa solida con la stessa filosofia.

Fonte originale: “Your AI Agent Is a Distributed System, Not a Chatbot” su DZone.

Quanti team stanno collegando agenti AI a Slack, a un’interfaccia #web o a server #MCP proteggendo l’accesso solo con un prompt di sistema ben scritto? Secondo un’#analisi pubblicata su DZone e basata su findings del Red Team di #NVIDIA, è proprio questo l’errore architetturale più diffuso nelle implementazioni enterprise di agenti AI: “i guardrail basati sul prompt falliscono sotto pressione avversaria”. Un attaccante sufficientemente motivato può camuffare attività malevole da comportamenti legittimi, scalare privilegi gradualmente o nascondere esecuzione di codice dentro interazioni apparentemente normali.

Il punto chiave, riassunto efficacemente dall’articolo originale, è questo: il modello non è il punto di applicazione della sicurezza, è la cosa che va difesa. Va trattato come qualsiasi altro componente non fidato della vostra infrastruttura — proprio come fareste con un processo che esegue codice arbitrario ricevuto da input esterni. In questo articolo ripercorriamo i cinque controlli infrastrutturali proposti, con esempi pratici applicabili su #Kubernetes e nello stack Microsoft.

1. Identità e propagazione dell’autenticazioneIl primo errore comune è usare credenziali condivise per l’agente, indipendentemente da chi lo stia effettivamente invocando (via Slack, web UI o endpoint MCP). Questo rende impossibile distinguere un’azione legittima da un abuso e complica ogni audit successivo.

La soluzione è propagare l’identità dell’utente umano fino ai sistemi a valle, invece di far agire l’agente con un account di servizio onnipotente. Lo standard di riferimento è OAuth 2.0 Token Exchange (RFC 8693), che permette di scambiare il token dell’utente con un token downstream a scope ridotto e vita breve:

POST /oauth2/token HTTP/1.1
Host: identity.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token={USER_TOKEN}
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=ticketing-api
&scope=tickets.read tickets.commentIl token risultante è specifico per l’audience richiesta (in questo caso l’API di ticketing), ha uno scope minimo e una scadenza breve. Ogni chiamata a valle porta con sé l’identità originale dell’utente, non quella generica dell’agente: questo è ciò che rende possibile un audit trail affidabile.

2. Presupporre l’esecuzione di codice e limitarne gli effettiUn agente con accesso a strumenti di code execution va trattato esattamente come un processo che esegue input non fidato, perché di fatto è quello che è. I controlli minimi da applicare a livello di #container:

filesystem di root read-only;

noexec su tutti i mount scrivibili, per impedire l’esecuzione di binari scaricati a runtime;

drop di tutte le capability #Linux non strettamente necessarie;

configurazione dell’agente montata come read-only da un mount point separato, così che l’agente stesso non possa alterare la propria configurazione;

allowlist esplicita dei binari eseguibili.

Un esempio di securityContext Kubernetes coerente con questi principi:

securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
volumeMounts:

• name: tmp
  mountPath: /tmp

  mount separato per lo storage scrivibile, con noexec applicato a livello di nodo

• name: agent-config
  mountPath: /etc/agent
  readOnly: true3. Egress default-denyUn agente compromesso o manipolato tramite prompt injection che possa raggiungere qualunque host su Internet è un rischio enorme: esfiltrazione dati, comando e controllo, o accesso agli endpoint di metadata del cloud provider (il classico 169.254.169.254, spesso usato per rubare credenziali IAM). La difesa è una NetworkPolicy Kubernetes default-deny in uscita, con eccezioni esplicite solo verso ciò che serve realmente:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ai-agent-default-deny-egress
namespace: agents
spec:
podSelector:
matchLabels:
app: ai-agent
policyTypes:
- Egress
egress:
# consente solo DNS e il proxy autenticato interno
- to:
- namespaceSelector: {}
ports:
- protocol: UDP
port: 53
- to:
- podSelector:
matchLabels:
app: egress-proxy
ports:
- protocol: TCP
port: 8080

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-cloud-metadata
namespace: agents
spec:
podSelector:
matchLabels:
app: ai-agent
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 169.254.169.254/32Le connessioni realmente necessarie devono passare attraverso un proxy autenticante con allowlist basata su FQDN, con logging completo di ogni richiesta e dell’identità utente associata: in questo modo ogni chiamata in uscita è tracciabile e limitata a destinazioni note.

4. Nessun segreto persistenteIniettare segreti tramite variabili d’ambiente, file di configurazione o, peggio, direttamente nel context window del modello è una pratica rischiosa: un agente che legge il proprio ambiente, o che viene indotto a farlo tramite prompt injection, può esfiltrare quei segreti con facilità.

L’approccio consigliato è il token brokering per singolo task, con TTL molto brevi (minuti, non ore) e revoca esplicita al completamento del task, non solo alla scadenza naturale:

ogni task riceve un token appena sufficiente per l’operazione richiesta;

il token viene revocato non appena il task termina, indipendentemente dalla sua scadenza nominale;

ogni emissione di segreto viene registrata con l’identità dell’utente umano che ha originato la richiesta.

Strumenti come Azure Key Vault (con identità gestite e token a vita breve) o soluzioni dedicate di secret brokering per workload agentic vanno preferiti rispetto a qualunque forma di credential injection statica.

5. Controllo della supply chain dei pacchettiUn agente con capacità di installare pacchetti (npm, pip, NuGet) durante l’esecuzione è una superficie di attacco enorme, soprattutto se può installare da repository VCS arbitrari o eseguire script di post-install non controllati. I controlli minimi:

uso di repository proxy interni (Artifactory o equivalente) come unica fonte consentita;

blocco esplicito delle installazioni da URL o VCS diretti (es. pip install git+https://...);

abilitazione di ignore-scripts=true per prevenire l’esecuzione di script post-install, un vettore di attacco noto nell’ecosistema npm;

verifica dell’hash dei pacchetti installati.

.npmrc per l'ambiente dell'agente

registry=https://artifactory.contoso.com/api/npm/npm-proxy/
ignore-scripts=true
audit=trueValidare i controlli con test automatici, non con documentazioneIl consiglio più pratico dell’articolo è forse questo: questi cinque controlli vanno implementati come test case automatici nella pipeline CI/CD, non lasciati a una checklist di sicurezza scritta a mano. Alcuni esempi di assertion da includere:

un chiamante non autenticato deve essere rifiutato;

un tentativo di scrittura su file di configurazione nascosti (dotfile) deve fallire;

ogni connessione in uscita non allowlisted deve essere bloccata e loggata;

nessun segreto deve essere presente nelle variabili d’ambiente del processo agente;

l’endpoint di metadata cloud deve risultare irraggiungibile;

un’installazione di pacchetto da VCS diretto deve essere bloccata dal proxy.

ConclusioneGli agenti AI non introducono nuovi principi di sicurezza: richiedono di applicare con rigore quelli che già conosciamo — least privilege, isolamento, gestione dei segreti a vita breve, egress controllato — a un tipo di workload che, per sua natura, esegue codice e prende decisioni sulla base di input non completamente prevedibili. Chi gestisce infrastrutture Kubernetes o Azure ha già gli strumenti per implementare questi controlli; il passo mancante, spesso, è semplicemente la decisione di applicarli con la stessa serietà riservata a qualunque altro workload che esegue codice non fidato.

Fonte originale: “5 Infrastructure Controls for Securing AI Agents” su DZone.

For #SeaWednesday a photo of Isola di Salina (island of Salina) in the Mediterranean Sea.

Nikon D700

NIKKOR AF-S 20mm f1.8 G ED

--

#Salina #Lipari #sicilia #sicily #sizilien #italia #italy #italien #Eolie #Aeolian #TyrrhenianSea #mediterranean #MediterraneanSea #island #insel #sea #meer #Seagull #Möwe #cloud #Wolke #Azure #Azurblau #photography #photo #travel #reise #sailing #segeln #travelphotography #reisefotografie #seascape #landscapephotography #landschaftsfotografie #PhotoOfTheDay #MeerMittwoch #captureone #nikon #d700 #davidpoertner #davidpoertnerphotography

Il problema che risolveChi progetta reti #Azure da qualche anno conosce bene il limite: gli endpoint privati (Private Endpoint) e Azure Private Link, il meccanismo che permette di raggiungere un servizio PaaS — storage account, database, Key Vault — attraverso un indirizzo IP privato all’interno della propria rete virtuale invece che tramite l’endpoint pubblico, hanno sempre funzionato solo su IPv4. Per le organizzazioni che stanno completando la transizione verso reti dual-stack o #IPv6-only — spinte da esaurimento di #spazio IPv4 privato, requisiti normativi o semplicemente modernizzazione dell’infrastruttura — questo obbligava a mantenere un livello di traduzione o connettività IPv4 residua solo per parlare con i servizi PaaS.

Microsoft ha annunciato la preview pubblica di Azure Private Link over IPv6, che elimina questa dipendenza: gli endpoint privati possono ora esporre un indirizzo IPv6, permettendo a client e workload nativamente IPv6 di raggiungere i servizi PaaS supportati senza alcuna intermediazione IPv4.

Servizi supportati nella previewAl momento della preview pubblica, il supporto copre un sottoinsieme mirato di servizi PaaS ad alto utilizzo:

Azure Storage (Blob, ecc.)

Azure SQL Database

Azure Key Vault

Azure Data Explorer

È lecito aspettarsi che l’elenco si allarghi man mano che la feature matura verso la disponibilità generale, seguendo lo schema tipico delle preview Azure: si parte dai servizi con maggiore adozione enterprise e si estende progressivamente.

Due scenari di connettivitàLa documentazione distingue due modalità d’uso, entrambe rilevanti per chi progetta reti ibride:

Connettività nativa AzureMacchine virtuali dual-stack o IPv6-only all’interno di una rete virtuale Azure accedono ai servizi PaaS tramite l’endpoint privato IPv6, con il traffico che rimane interamente sulla dorsale privata Microsoft — lo stesso principio di isolamento dal traffico pubblico che Private Link garantisce già per IPv4.

Connettività ibrida on-premisesClient IPv6 in un datacenter on-premises possono raggiungere i servizi Azure attraverso ExpressRoute, con una connessione privata end-to-end che non attraversa mai la rete pubblica #Internet. Questo scenario richiede tipicamente una Virtual Network Routing Appliance (VNRA) con route definite dall’utente (UDR) per instradare correttamente il traffico IPv6 tra l’ambiente on-premises e la rete virtuale Azure.

Requisiti di configurazionePer attivare e usare la feature in preview servono alcuni passaggi preliminari:

Registrazione della subscription al feature flag della preview pubblica (come per la maggior parte delle feature in anteprima su Azure, tramite az feature register o dal portale).

Rete virtuale dual-stack: la VNet deve avere spazio di indirizzamento sia IPv4 sia IPv6 configurato, non è sufficiente aggiungere IPv6 alla sola subnet dell’endpoint privato.

Endpoint privati abilitati IPv6, creati esplicitamente con configurazione dual-stack.

#DNS coerente: le zone DNS private devono risolvere i nomi dei servizi PaaS anche verso i record AAAA (indirizzi IPv6) associati agli endpoint privati, non solo verso i record A esistenti.

Per lo scenario ibrido, la VNRA con UDR menzionata sopra, per garantire che il traffico IPv6 proveniente da ExpressRoute venga instradato correttamente verso l’endpoint privato.

Un dettaglio che vale la pena sottolineare per chi pianifica un rollout: la configurazione DNS è spesso il punto in cui i deployment IPv6 falliscono silenziosamente. Se la zona privata continua a restituire solo record A, i client dual-stack proveranno comunque a instradare la richiesta su IPv4, vanificando parte del vantaggio della nuova feature. Vale la pena verificare esplicitamente con nslookup -type=AAAA o dig AAAA che la risoluzione avvenga come previsto prima di considerare il deployment completo.

Disponibilità regionaleLa preview pubblica è per ora limitata a un numero ristretto di region:

West Central US

East Asia

UK South

Central US

North Europe

Chi opera in altre region europee (ad esempio West Europe o Italy North) dovrà attendere l’espansione della preview o la disponibilità generale prima di poter testare la feature sui propri workload di produzione — un fattore da tenere in conto nella pianificazione di eventuali migrazioni a reti IPv6-only che dipendano da questa capacità.

Perché conviene iniziare a pianificare oraAnche per chi non ha una scadenza imminente per l’adozione IPv6, ci sono buone ragioni pratiche per iniziare a familiarizzare con questa capacità:

Esaurimento dello spazio IPv4 privato: le grandi organizzazioni con centinaia di VNet e subnet spesso si scontrano con conflitti di indirizzamento RFC 1918 quando serve fare peering tra reti create in tempi diversi o durante fusioni aziendali. IPv6 elimina strutturalmente questo problema.

#Compliance e requisiti governativi: diverse amministrazioni pubbliche, in Italia come altrove, hanno tabelle di marcia che richiedono supporto IPv6 nativo per i servizi digitali entro scadenze specifiche.

Riduzione della complessità NAT: meno traduzione di indirizzi significa meno stato da gestire e da diagnosticare quando qualcosa si rompe — un vantaggio concreto in fase di troubleshooting di rete.

Per un architetto di rete Azure, il percorso pragmatico consiste nel registrare fin da ora una subscription non di produzione alla preview, distribuire una VNet dual-stack di test e verificare il comportamento end-to-end (inclusa la risoluzione DNS) prima che la feature diventi disponibile su larga scala. Arrivare preparati alla disponibilità generale, quando probabilmente coprirà più servizi e più region, evita di dover improvvisare un redesign di rete sotto pressione.

ConclusioneAzure Private Link over IPv6 chiude una lacuna che gli architetti di rete Azure conoscono da anni: l’impossibilità di raggiungere i servizi PaaS più comuni tramite endpoint privati IPv6 senza intermediazione IPv4. La preview è ancora limitata per servizi e region, ma la direzione è chiara e coerente con il resto dell’ecosistema Azure #networking (Application Gateway ed ExpressRoute hanno già ricevuto supporto IPv6 esteso nell’ultimo periodo). Chi gestisce infrastrutture ibride o pianifica una transizione IPv6 farebbe bene a iniziare i test già in questa fase di anteprima.

Fonte: Azure Private Link Over IPv6 Enters Public Preview — Petri IT Knowledgebase. Annuncio ufficiale: Microsoft Tech Community.

Il SOC incontra il GitOpsCon l’aggiornamento di luglio 2026, Microsoft #Sentinel porta la logica #DevOps fin dentro il cuore del rilevamento delle minacce: le regole di detection personalizzate entrano ufficialmente tra i contenuti gestibili come Detections-as-Code (DaC) tramite le Sentinel Repositories, mentre un nuovo pannello Table Insights rende finalmente leggibile a colpo d’occhio lo stato di #salute dell’ingestion. Sono due funzionalità distinte ma complementari, ed entrambe parlano direttamente a chi in azienda gestisce SIEM e pipeline CI/CD con lo stesso approccio.

Detections-as-Code: le regole di rilevamento come contenuto versionatoMicrosoft Sentinel Repositories esisteva già per contenuti come analytics rules, automation rules, hunting queries, parser, playbook e workbook: la novità è che ora anche le regole di detection personalizzate (custom detection rules) rientrano in questo flusso, gestibili tramite la Microsoft Security Bicep extension. Il repository esterno — #GitHub o #Azure DevOps — diventa la single source of truth: qualunque modifica fatta manualmente dal portale di Sentinel viene sovrascritta alla successiva sincronizzazione dal repository.

Per collegare un repository servono permessi precisi, spesso motivo di attrito nei team più strutturati:

ruolo Owner sul resource group che contiene il workspace Sentinel, per creare la connessione;

accesso Collaborator sul repository GitHub, oppure Project Administrator su Azure DevOps;

GitHub Actions abilitate (o Pipelines per Azure DevOps);

per Azure DevOps, la connessione deve risiedere nello stesso tenant del workspace Sentinel.

Ogni workspace Sentinel è limitato a cinque connessioni repository, e ogni resource group a 800 deployment nella sua history — un limite da tenere presente se si pianifica una struttura multi-repo per team o ambienti diversi.

Bicep, non ARM JSON: la scelta consigliataMicrosoft consiglia esplicitamente Bicep rispetto ai template ARM JSON grezzi per descrivere le regole. Un paio di dettagli tecnici da non sottovalutare in fase di migrazione:

i file Bicep non supportano la proprietà id: le regole esportate da Sentinel la includono, e va rimossa manualmente prima della decompilazione;

per una decompilazione pulita da ARM JSON a Bicep conviene forzare lo schema alla versione 2019-04-01;

le connessioni create prima del 1° novembre 2024 non supportano Bicep e vanno rimosse e ricreate per abilitarlo.

Per chi parte da zero, il repository ufficiale SentinelCICD/RepositoriesSampleContent fornisce template di esempio per ogni tipo di contenuto, comprese le funzionalità avanzate delle connessioni repository.

Smart deployments: non ridistribuire ciò che non è cambiatoUna delle frizioni tipiche del content-as-code applicato a un SIEM è il rischio di ridistribuire regole invariate a ogni deploy, resettando ad esempio schedule dinamici delle analytics rule. Sentinel risolve il problema con gli smart deployments: un file CSV nella cartella .sentinel del repository tiene traccia dei commit e il workflow evita di ridistribuire contenuti non modificati dall’ultimo deploy. È abilitato di default sulle nuove connessioni; per disattivarlo (e forzare sempre il deploy completo) si interviene sul file YAML del workflow o della pipeline.

Il flusso operativo tipico diventa quindi: un analista propone una nuova regola di detection in una pull request, il team la revisiona come farebbe con codice applicativo, al merge la pipeline CI/CD (GitHub Actions o Azure Pipelines) distribuisce automaticamente solo le modifiche nel workspace Sentinel collegato — con audit trail completo su chi ha cambiato cosa e quando, cosa che il portale da solo non garantisce con la stessa granularità.

Table Insights: capire l’ingestion senza scrivere KQLLa seconda novità rilevante del mese è Table Insights, un nuovo pannello nella pagina Tables della configurazione di Sentinel (Defender portal → Microsoft Sentinel → Configuration → Tables). Mostra, senza bisogno di query KQL manuali:

il volume di ingestion degli ultimi 30 giorni, suddiviso per tier (Analytics vs Auxiliary/Data Lake);

le variazioni giorno su giorno e settimana su settimana, utili per individuare picchi o cali anomali;

le tabelle che consumano più ingestion, per stimare rapidamente i costi;

i connettori che hanno smesso di inviare dati — spesso il primo sintomo di un problema di raccolta che altrimenti si scopre solo durante un’investigazione, quando è troppo tardi.

Chi preferisce restare in KQL può ottenere una vista equivalente sfruttando il campo Plan della tabella Usage, che permette di scomporre l’ingestion per Analytics, Basic e Auxiliary direttamente in query native — utile per costruire dashboard personalizzate o alert di costo oltre al pannello grafico.

Nuovi connettori datiL’aggiornamento di luglio amplia anche la copertura dei data connector con il supporto nativo per GitHub Enterprise, Agari, Airlock Digital e Gigamon — un’estensione che si allinea bene proprio con l’adozione di Detections-as-Code, dato che GitHub Enterprise diventa ora sia sorgente di log di audit sia repository di regole.

Perché conviene iniziare oraPer un SOC maturo, la combinazione di queste due funzionalità è più significativa della somma delle parti: Detections-as-Code porta revisione tra pari, versionamento e rollback affidabile sulle regole di rilevamento, mentre Table Insights riduce il tempo necessario per accorgersi che una sorgente di log si è interrotta silenziosamente — un problema che, senza query dedicate, spesso passa inosservato per settimane. Chi gestisce già Infrastructure-as-Code su Azure con Bicep o #Terraform troverà il modello concettuale familiare; la parte più delicata resta la migrazione delle regole esistenti dal portale al repository, che conviene pianificare per gruppi di severità o per data source, non tutta insieme.

Fonte: Petri IT Knowledgebase – Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, con approfondimenti dalla documentazione ufficiale Microsoft Learn su Sentinel Repositories.

Chi amministra Microsoft #Entra ID conosce bene il problema dei “gruppi nidificati”: per anni non è stato possibile costruire un gruppo dinamico che includesse automaticamente i membri di un altro gruppo. La regola preview memberOf, introdotta proprio per colmare questa lacuna, sta però per essere ritirata. Dal 3 novembre 2026 tutte le configurazioni che la usano smetteranno di aggiornarsi, restando congelate all’ultimo stato elaborato correttamente. Se gestite gruppi dinamici, unità amministrative dinamiche o policy di entitlement management basate su memberOf, è il momento di pianificare la migrazione.

Cos’è (stato) l’operatore memberOfIn anteprima pubblica, memberOf ha permesso di creare gruppi a membership dinamica popolati a partire dall’appartenenza ad altri gruppi, di sicurezza, Microsoft 365 o sincronizzati da Active Directory on-premises. La regola si scriveva nella sintassi avanzata del rule editor, non essendo mai stata supportata dal rule builder grafico:

// Regola per un gruppo dinamico di utenti
user.memberof -any (group.objectId -in ['<groupObjectId>'])

// Regola per un gruppo dinamico di device
device.memberof -any (group.objectId -in ['<groupObjectId>'])

// Più gruppi sorgente contemporaneamente
user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])Era possibile usarla per gruppi dinamici veri e propri, per unità amministrative dinamiche e per policy di auto-assignment in Entra ID Governance, con limiti già stringenti in preview: 500 gruppi memberOf per tenant, massimo 50 gruppi sorgente per regola, nessuna combinazione con altri operatori o con altre regole memberOf annidate.

Perché Microsoft la ritiraDurante la preview, Microsoft ha osservato che l’uso di memberOf può rallentare l’elaborazione della membership dinamica per tutti i gruppi del tenant, non solo per quelli che la utilizzano: un singolo gruppo configurato con questo operatore può introdurre ritardi di elaborazione a livello di tenant. Per questo motivo Microsoft ha deciso di ritirare l’operatore dalla preview, pur riconoscendo la validità dello scenario d’uso, e sta sviluppando una soluzione alternativa più scalabile, senza però fornire ancora una data di disponibilità.

Cosa succede dopo il 3 novembre 2026Le configurazioni che usano ancora memberOf non genereranno errori visibili: semplicemente smetteranno di aggiungere o rimuovere membri quando cambia l’appartenenza ai gruppi sorgente, restando congelate all’ultimo stato noto. È un comportamento subdolo perché non c’è un evento di rottura evidente, solo un progressivo disallineamento tra la realtà organizzativa e ciò che Entra ID applica. Gli effetti possono includere:

Accessi Teams e SharePoint non più aggiornati per utenti entrati o usciti da un gruppo sorgente

Targeting delle policy di Conditional Access basato su appartenenze obsolete

Licenze assegnate tramite group-based licensing non più coerenti con l’organico reale

Ambiti amministrativi (administrative unit) che non riflettono più la struttura corrente

Assegnazioni di access package in Entra ID Governance bloccate sullo stato congelato

Come prepararsi: audit prima della deadlineIl primo passo è mappare ogni configurazione che dipende da memberOf. Per i gruppi dinamici, si può esportare l’elenco dall’Entra admin center oppure interrogare Microsoft Graph #PowerShell cercando la stringa nella proprietà MembershipRule:

Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
-Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' } |
Select-Object Id, DisplayName, MembershipRulePer le unità amministrative dinamiche e le policy di auto-assignment dell’entitlement management non esiste (ancora) un filtro diretto lato server sulla regola: occorre enumerare gli oggetti e verificare la proprietà della regola dinamica, ad esempio:

Unità amministrative dinamiche

Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' }

Policy di auto-assignment (Entitlement Management)

Get-MgEntitlementManagementAccessPackageAssignmentPolicy -All |
Where-Object { $_.AutomaticRequestSettings.RequestAccessForAllowedTargets -ne $null }Per le policy di entitlement management è comunque consigliabile incrociare l’output con la revisione manuale in Entra ID Governance, dato che la struttura della regola può variare a seconda di come è stata configurata.

Strategie di migrazioneUna volta identificate le configurazioni a rischio, Microsoft indica due strade principali:

Sostituire la regola con operatori dinamici supportati (ad esempio basati su attributi utente o dispositivo), quando esiste un equivalente funzionale

Convertire a membership assegnata quando non è possibile replicare la logica di nesting con le regole standard, accettando la gestione manuale o tramite automazione esterna (es. script PowerShell schedulati o Logic App)

In entrambi i casi, prima di considerare chiusa la migrazione bisogna validare concretamente: verificare che la membership finale del gruppo coincida con quella attesa, controllare che le assegnazioni di licenza, gli scope di Conditional Access e i pacchetti di accesso continuino a comportarsi correttamente, ed eliminare le configurazioni ormai inutilizzate invece di lasciarle come debito tecnico silente.

ConclusioneIl ritiro di memberOf è un promemoria di un principio più generale nel #cloud amministrato: le funzionalità in preview non vanno mai considerate stabili in produzione, per quanto risolvano un problema reale. Con circa tre mesi di margine dalla data di scrittura di questo articolo al 3 novembre 2026, il momento giusto per l’audit è ora, prima che il “congelamento” silenzioso della membership diventi un problema di accesso scoperto in produzione da un utente che segnala di aver perso l’accesso a un canale Teams.

Fonte: Microsoft Learn – Configure dynamic membership groups with the memberOf operator, con approfondimenti da 4sysops e Petri IT Knowledgebase.

Big sunflower

https://www.blipfoto.com/entry/3533562450181884736

#blip of a large #sunflower #flower with a pollen covered bee on it, against a #azure sky.

#blipfoto #gimp #rawtherapee #photography #france #garden

Il problema delle Throughput Unit staticheChi ha già lavorato con Azure Event Grid Namespaces conosce bene il concetto di Throughput Unit (TU): ogni TU definisce una capacità fissa di ingress/egress per gli eventi, di publish MQTT e di connessioni client MQTT. Fino ad oggi, il numero di TU andava impostato in fase di creazione del namespace e poi regolato manualmente ogni volta che il pattern di traffico cambiava — tipicamente sovradimensionando “per sicurezza” durante i picchi, con conseguente spreco di capacità (e di budget) nei periodi di bassa attività.

Microsoft ha da poco introdotto in public preview la funzionalità Autoscale per Event Grid Namespaces (tier Standard), che elimina questa gestione manuale: il servizio monitora il carico e regola automaticamente le TU tra un minimo e un massimo configurati dall’amministratore.

Come funziona AutoscaleIl funzionamento è deliberatamente semplice, in linea con la filosofia “meno configurazione, più automazione” che Azure sta applicando a diversi servizi PaaS. Event Grid valuta continuamente l’utilizzo su quattro categorie:

Event ingress: tasso di eventi in ingresso sui namespace topic HTTP.

Event egress: tasso di eventi in uscita verso i sottoscrittori.

MQTT publish rate (inbound/outbound): frequenza dei messaggi pubblicati e ricevuti sul broker MQTT.

MQTT client count: numero di client MQTT registrati e connessi.

Quando una qualunque di queste metriche supera la soglia di scale-up, il servizio aggiunge automaticamente Throughput Unit. Quando tutte le categorie scendono sotto la soglia di scale-down, le TU in eccesso vengono rilasciate. L’amministratore non definisce policy o soglie personalizzate: si limita a impostare i limiti minimo e massimo di TU, e Event Grid gestisce internamente le decisioni di scaling.

Un richiamo ai concetti di namespacePer chi non ha ancora familiarità con il modello a namespace di Event Grid (distinto dai topic “classici” di Event Grid Basic), vale la pena ricordare la struttura:

Un namespace è un contenitore di gestione che espone un FQDN unico e due endpoint: uno HTTP per i namespace topic, uno MQTT per scenari IoT.

I namespace topic supportano sia la pull delivery (il consumer si collega ed estrae i messaggi con semantica queue-like) sia la push delivery (attualmente verso Event Hubs come destinazione).

Gli eventi pubblicati devono rispettare lo standard CloudEvents 1.0 del CNCF, con binding HTTP e formato JSON.

Autoscale agisce a livello di namespace, quindi tutte le risorse contenute (topic, topic space MQTT, client, client group) beneficiano della stessa capacità elastica senza bisogno di scaling indipendente per ciascuna.

Abilitare Autoscale: portale, ARM e REST APILa funzionalità, essendo in preview, va abilitata esplicitamente. Dal portale Azure basta aprire il namespace Event Grid, andare nella sezione di configurazione della capacità e attivare l’opzione Autoscale specificando TU minime e massime.

Per chi gestisce l’infrastruttura as code, lo stesso risultato si ottiene via ARM template (o Bicep) impostando le proprietà di scaling sulla risorsa del namespace:

{
 "type": "Microsoft.EventGrid/namespaces",
 "apiVersion": "2025-04-01-preview",
 "name": "ns-iot-produzione",
 "location": "westeurope",
 "sku": {
 "name": "Standard",
 "capacity": 4
 },
 "properties": {
 "isZoneRedundant": true,
 "topicsConfiguration": {},
 "publicNetworkAccess": "Enabled",
 "topicSpacesConfiguration": {
 "state": "Enabled"
 }
 }
}Nota: al momento della stesura la configurazione fine di Autoscale (min/max TU) va completata tramite portale o REST API dedicata, poiché lo schema ARM per questa preview è ancora in evoluzione — vale la pena controllare la pagina di supporto ufficiale prima di automatizzare il deployment in pipeline CI/CD.

Via REST API, la capacità del namespace si legge e modifica sulla stessa risorsa esposta dall’API di gestione di Event Grid:

GET https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.EventGrid/namespaces/{namespaceName}?api-version=2025-04-01-previewQuando ha senso usarloAutoscale è pensato in particolare per due categorie di carico che chi lavora con architetture event-driven conosce bene:

Workload IoT con MQTT: il numero di dispositivi connessi e il fan-out delle sottoscrizioni possono variare rapidamente (pensiamo a una flotta di sensori che si riattiva tutta insieme dopo un’interruzione di rete). Dimensionare le TU staticamente per il picco significa pagare capacità inutilizzata per la maggior parte del tempo.

Event broker con traffico “a burst”: pipeline di ingestion che ricevono ondate di eventi correlate a batch job, deployment, o processi di business con picchi orari/giornalieri (fine mese, chiusura contabile, campagne marketing).

Per i .NET developer che costruiscono microservizi basati su eventi, questo significa poter progettare la sottoscrizione a namespace topic senza dover stimare a priori il traffico di picco con lo stesso margine di sicurezza richiesto finora — riducendo sia il rischio di throttling sotto carico sia i costi nei periodi di quiete.

ConclusioneAutoscale per Event Grid Namespaces arriva in un’area, il messaging event-driven, dove il dimensionamento manuale è da sempre un compromesso scomodo tra costo e resilienza. Essendo ancora in public preview, prima di adottarlo su workload di produzione critici vale la pena testarlo su un namespace non critico, verificando i tempi di reazione dello scaling automatico sotto carico reale e monitorando le metriche di throttling durante la fase di transizione tra un livello di TU e l’altro.

Fonte: Petri IT Knowledgebase – Azure Event Grid Namespaces Add Autoscale for Dynamic Messaging Workloads; concetti tecnici da Microsoft Learn – Concepts for Event Grid namespace topics

Se la vostra organizzazione ha già spostato la maggior parte dei carichi rivolti agli utenti su Microsoft 365, Intune e Microsoft Entra ID, è lecito chiedersi perché esista ancora un Domain Controller che gira in produzione. La risposta più comune è “così abbiamo sempre fatto”, ed è esattamente la definizione di debito tecnico: un’infrastruttura che continua a costare in manutenzione, superficie di attacco e complessità operativa senza generare più un valore proporzionato. L’identità ibrida, con Entra Connect che sincronizza un Active Directory locale verso il cloud, è diventata per molte aziende proprio questo tipo di debito.

Non si tratta di demonizzare l’ibrido: per organizzazioni con applicazioni legacy pesantemente dipendenti da NTLM, LDAP o Kerberos, mantenere un ponte con l’on-premise è spesso l’unica scelta razionale. Il punto è che la decisione va presa consapevolmente, dopo un inventario reale delle dipendenze, e non per inerzia.

Perché il cloud-only conviene, quando è applicabilePer un’organizzazione che gira già prevalentemente su Entra ID, Microsoft 365 e client Windows moderni, il modello cloud-only centralizza la gestione IT e accelera l’accesso a nuove funzionalità di sicurezza che spesso arrivano prima, o esclusivamente, sui tenant che non dipendono più da sincronizzazione ibrida. I vantaggi concreti che spingono in questa direzione sono quattro:

Riduzione del carico operativo: patching, alta disponibilità e scalabilità dei Domain Controller passano al provider cloud.

Postura di sicurezza migliore: funzionalità come Conditional Access granulare, Identity Protection e governance degli accessi privilegiati sono nativamente più semplici da applicare senza il vincolo di compatibilità con AD locale.

Costi più prevedibili: si eliminano hardware ridondante, licenze Windows Server per i DC e il tempo ingegneristico dedicato a mantenerli in salute.

Velocità di adozione: nuove capacità (passkey, agenti AI con identità propria, automazioni Conditional Access) arrivano più rapidamente su tenant che non devono conciliarsi con un’infrastruttura ibrida.

L’errore più comune: migrare l’infrastruttura prima di validare le dipendenzeIl fallimento tipico di un progetto cloud-only non è tecnico, è di sequenza: i team iniziano a spegnere server e migrare workload prima di aver mappato davvero cosa dipende ancora da Active Directory. Un approccio più solido segue queste fasi.

1. Mappare i carichi di lavoro che bloccano il cloud-onlyPartite da un audit completo di infrastruttura, applicazioni, dati e dipendenze. Non fermatevi alla lista delle VM: cercate esplicitamente le dipendenze che raramente compaiono nei piani di migrazione di alto livello, perché sono quelle che tengono in vita Entra Connect molto più a lungo del necessario:

Applicazioni che richiedono ancora query LDAP dirette

Service account legacy non documentati

Applicazioni con autenticazione NTLM hard-coded

Impostazioni di Group Policy che nessuno ha mai rivisto

Servizi certificati (ADCS) che presuppongono un Domain Controller sempre raggiungibile

2. Definire l’architettura cloud che volete davvero gestireStabilite obiettivi chiari su performance, disponibilità, sicurezza e compliance prima di scegliere gli strumenti. Decidete se una strategia single-cloud o multi-cloud è coerente con la vostra tolleranza al rischio e con le competenze del team, non solo con il marketing del vendor.

3. Modernizzare l’identità prima di spegnere Active DirectoryQui sta il cuore del progetto. Rivedere la strategia IAM significa garantire autenticazione robusta, accesso a privilegio minimo e protezione dell’identità sfruttando gli strumenti nativi di Entra ID per unificare la gestione utenti su tutti i servizi, invece di replicare in cloud le stesse logiche pensate per un dominio locale.

4. Ridisegnare la connettività attorno all’accesso cloud, non al data centerMolte architetture di rete sono ancora progettate assumendo che il traffico debba passare da un data center centrale. Un modello cloud-only ribalta la logica: la connettività va progettata per l’accesso diretto ai servizi cloud, sfruttando le backbone dei provider e i servizi di sicurezza integrati, sia per utenti in ufficio sia da remoto.

5. Trattare le applicazioni legacy come il vero collo di bottigliaFile share, servizi di stampa, applicazioni gestionali interne e integrazioni con piattaforme di terze parti datate sono i blocchi reali dei progetti cloud-only, molto più della migrazione di VM o storage. Un’applicazione finance che si aspetta autenticazione Windows integrata, un sistema di magazzino che dipende da query LDAP o una file share con permessi ereditati da anni possono rallentare il progetto più di qualunque altro fattore. Per ciascuna, valutate lift-and-shift, refactoring o riscrittura in base a complessità e valore strategico.

6. Ricostruire la governance per un modello operativo cloud-firstAggiornate le policy per riflettere una postura cloud-first, automatizzate il reporting di compliance e sfruttate strumenti di sicurezza nativi cloud per cifratura, rilevamento minacce e incident response, invece di adattare policy pensate per l’on-premise.

7. Preparare il team IT al cambio operativoInvestite nella formazione sulle competenze cloud-specifiche, comunicate i cambiamenti con chiarezza e create canali di supporto e feedback per intercettare problemi prima che diventino bloccanti.

Cosa si rompe per primo in una migrazione cloud-onlyAnche con una pianificazione accurata, alcuni punti critici emergono quasi sempre:

Dipendenze nascoste da Active Directory: connessioni LDAP hard-coded, service account non gestiti, applicazioni dipendenti da NTLM o flussi di autenticazione mai documentati. Vanno inventariati prima di ritirare i Domain Controller o disattivare la sincronizzazione.

Blocchi operativi da Conditional Access e MFA: l’enforcement di Conditional Access e multi-factor authentication migliora la sicurezza, ma una sequenza sbagliata può bloccare fuori gli amministratori o interrompere l’accesso a servizi critici. Testate sempre account di emergenza, opzioni di rollback e flussi di accesso privilegiato prima di un enforcement ampio.

Resistenza culturale: il cambiamento comporta rischio percepito; serve chiarezza sui benefici e sui nuovi ruoli per ridurre lo scetticismo dei team.

Interruzioni di servizio: pianificate la migrazione a fasi, con pilot e backup, per minimizzare l’impatto sul business.

Il test pratico per capire quanto siete lontani dal cloud-onlySe la vostra organizzazione ha già adottato Microsoft 365, Intune ed Entra ID per la maggior parte dei carichi rivolti agli utenti, l’identità ibrida va trattata come debito tecnico, a meno che non abbiate una ragione precisa e documentata per mantenerla. Prima di pianificare una migrazione cloud-only, identificate ogni dipendenza residua da Active Directory: se la maggior parte supporta già l’autenticazione moderna, probabilmente siete più vicini al cloud-only di quanto pensiate.

Per i sistemisti che gestiscono ambienti Microsoft, il consiglio pratico è iniziare da un inventario mirato: interrogate Entra Connect per capire quali oggetti sincronizzati sono ancora effettivamente in uso, verificate quali applicazioni autenticano ancora tramite Kerberos/NTLM controllando i log di sicurezza dei Domain Controller, e mappate le Group Policy applicate per capire quali impostazioni di sicurezza andranno ricreate tramite Intune prima di spegnere l’ultimo controller di dominio.

ConclusioneLa migrazione a cloud-only non è un progetto infrastrutturale, è un progetto di identità. Le organizzazioni che falliscono di solito partono dal lato sbagliato del problema, migrando VM e storage prima di aver capito cosa dipende ancora da un dominio Active Directory che nessuno ha mai documentato del tutto. Chi parte invece dall’inventario delle dipendenze di identità, tratta l’ibrido come uno stato temporaneo e non come un’architettura permanente, arriva a un ambiente più semplice da gestire, più sicuro per costruzione e meno costoso da mantenere nel tempo.

Fonte: Why Hybrid Identity Becomes Technical Debt and How to Move to Cloud-Only, Petri IT Knowledgebase (Dean Ellerby).

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GAFino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente

Select target — scelta o creazione della VM SQL Server di destinazione

Migrate data — trasferimento effettivo dei database

Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazioneUna parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazionePer un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restoreIl meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

Viene eseguito un backup completo del database sorgente

Il backup viene caricato su un account di Azure Blob Storage intermedio

Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure

I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato

Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti praticiUna subscription Azure attiva

L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)

L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
SERVERPROPERTY('Edition') AS Edizione,
SERVERPROPERTY('EngineEdition') AS TipoMotore;Cosa considerare prima di partireIl pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

ConclusionePortare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.