Riduci il rischio umano in Intune con il Multi-Admin Approval, dal day-to-day all’emergenza

Perché esiste (e perché conviene usarlo sempre)

Gli errori o le azioni troppo frettolose capitano ogni giorno. Multi-Admin Approval (MAA) introduce un doppio controllo su operazioni e configurazioni sensibili in Microsoft Intune: una persona propone, un’altra approva, e solo dopo il proponente completa l’azione. Semplice, misurabile, auditabile.

Che cosa copre davvero

MAA non serve solo a evitare il wipe accidentale. Puoi applicarlo a:

• Azioni sui dispositivi: delete, wipe, retire

• Distribuzione delle app

• Script (Windows)

• RBAC: ruoli, membership e gruppi amministrativi

• Le stesse Access policies (la “meta-sicurezza” del meccanismo)

Suggerimento: una policy per ambito (es. una per le device actions, una per RBAC) semplifica governance e audit.

Come si crea una Access policy MAA (passo-passo)

Portale: Intune → Tenant administration → Multi-admin approval → Access policies → Create.

Basics: assegna Nome - Descrizione (opzionale) chiari (es. “Policy delete device”)

Policy type: scegli l’ambito da proteggere.

• Per l’esempio: Device delete.

• In altri casi: Device wipe/retire, Apps, Scripts, RBAC, Access policies.

Approvers: seleziona il gruppo approvatori (Entra ID) per l’ambito scelto - Intune-Admin-Approver

Business justification (obbligatoria): inserisci la motivazione della policy (perimetro, rischi che mitiga, riferimento a ticket/change)

La policy orà dovrà essere approvata da un altro amministratore di Intune; colleghiamoci con l'utenza e approviamo la policy appena creata

L'amministratore che ha richiesto la creazione di questa policy può ora completare la creazione cliccando su Complete request

Ruoli e responsabilità (modello operativo minimale)

• Proponente: crea la policy o richiede l’azione, compila la business justification.

• Approvatore: è esterno al team operativo; valuta impatto e conformità.

• Owner (facoltativo): definisce quando serve MAA e lo standard di motivazione.
  Consiglio: ruoli in JIT con PIM per ridurre privilegi permanenti.

Ciclo di vita di una richiesta

Requested → Approved/Rejected → Completed → (eventuale) Expired/Cancelled
Punto spesso dimenticato: dopo Approve, il proponente deve sempre chiudere con Complete.

Esempio pratico: Delete di un device

Scenario: un tecnico vuole eliminare un dispositivo obsoleto o duplicato dall’inventario Intune.

Proposta

• Nella pagina del dispositivo, scegli Delete.

• Compila la business justification (ticket, motivo eliminazione, conferma che non servirà re-enrollment).

• Invia: stato Requested.

Revisione

• Un approvatore (membro del gruppo scelto in precedenza al momento della creazione della policy - Intune-Admin-Approver) verifica che sia davvero un device da rimuovere e non un rename o un asset ancora in uso.

• Approve request (o Reject con nota).

Esecuzione controllata

• Il proponente torna sulla richiesta e preme Complete.

• Stato Completed e l’oggetto viene eliminato.

Perché il delete è delicato: a differenza di retire o wipe, qui sparisce l’oggetto dal tenant e perdi scorciatoie operative (cronologia rapida, riferimenti). Il doppio tocco riduce i falsi positivi.

Linee guida che reggono nel tempo

• Separazione dei compiti: chi opera non approva; ruoli JIT per minimizzare l’esposizione.

• Gruppi approvatori dedicati: membership essenziale e revisionata periodicamente.

• Regole scritte e leggere: quando usare MAA, business justification obbligatoria (anche per la creazione/modifica delle policy), chi approva nei casi urgenti.

• Audit disciplinato: verifica periodica che ogni Approved sia poi Completed e che non restino pendenti storiche.

Quando attivarlo “senza pensarci”

• Azioni irreversibili o ad alto impatto (delete/wipe/retire).

• RBAC e gruppi privilegiati.

• Distribuzioni ampie (app/script su “All devices/users” o grandi platee).

• Modifiche alle Access policies stesse.

Conclusione

MAA è un controllo semplice che alza in modo concreto l’affidabilità dei processi Intune. Crea la policy con business justification, assegna approvatori credibili e ricordati il passaggio finale di Complete. Così il “sei sicuro?” diventa una pratica strutturata, tracciata e ripetibile.