Come configurare una policy MAM di Intune

Quando usare una policy MAM in Intune

Una policy MAM di Intune serve quando vuoi proteggere i dati aziendali dentro le app, senza per forza registrare o gestire l’intero dispositivo. È il caso tipico di scenari BYOD, consulenti, utenti esterni o ambienti in cui il controllo del device sarebbe troppo invasivo. La logica è semplice: la protezione segue l’app, non il telefono.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il punto chiave è distinguere MAM da MDM. Con MDM gestisci il dispositivo; con MAM applichi regole alle app supportate, come Outlook, Teams, OneDrive e altre app compatibili con i criteri di protezione di Intune. Se l’obiettivo è impedire copia/incolla verso app personali, forzare PIN nell’app, cifrare i dati aziendali e controllare il salvataggio locale, MAM è spesso la scelta giusta.

Se invece hai bisogno di Wi-Fi, certificati, configurazioni device-wide o compliance sul terminale, MAM da sola non basta. In quel caso si ragiona su MDM o su un modello misto MDM+MAM.

Prerequisiti che evitano il 90% degli errori

Prima di creare la policy, verifica questi punti. Saltarli porta quasi sempre a problemi del tipo “la policy è assegnata ma non si applica”.

1. Licenza Intune valida per gli utenti coinvolti.
2. Tenant Entra ID funzionante e utenti correttamente sincronizzati o creati.
3. App supportate da MAM e versioni aggiornate sui dispositivi target.
4. Gruppi di destinazione già pronti, meglio se dinamici o comunque ben definiti.
5. Accesso condizionale coerente con il modello scelto: solo app approvate, oppure app approvate e app protection policy richieste.

Un controllo rapido lato tenant lo fai dal portale Microsoft Intune, nella sezione dedicata alle app. Se vedi già policy vecchie o conflitti storici, conviene mappare prima le assegnazioni attive. Il problema più comune non è creare la policy, ma assegnarla a un gruppo che contiene utenti con condizioni diverse tra loro.

Struttura della policy: cosa stai davvero impostando

Una policy MAM non è un blocco unico. Di solito include quattro aree operative:

• protezione dei dati, come copia/incolla, salvataggio su storage personale e trasferimento verso app non gestite;
• requisiti di accesso, come PIN dell’app, password, timeout e biometria;
• condizioni di avvio, come jailbreak/root detection o versione minima del sistema;
• azioni in caso di perdita o rischio, come wipe selettivo dei dati aziendali nell’app.

In pratica, stai definendo cosa può fare l’utente con i dati aziendali una volta aperti nell’app. Questo è il motivo per cui la policy va pensata insieme al flusso di accesso, non come un oggetto isolato da “spuntare” a posteriori.

Creazione della policy nel portale Intune

Il percorso classico nel portale è quello delle app e delle app protection policy. La nomenclatura può cambiare leggermente con gli aggiornamenti dell’interfaccia, ma il flusso resta lo stesso: crei una policy, scegli piattaforma e tipo di policy, poi definisci le impostazioni e l’assegnazione.

1. Apri il portale di gestione Intune.
2. Vai in Apps e cerca la sezione delle App protection policies.
3. Crea una nuova policy per la piattaforma desiderata, ad esempio iOS/iPadOS o Android.
4. Assegna un nome chiaro, ad esempio MAM-OUTLOOK-BYOD-IT.
5. Definisci le impostazioni di protezione dei dati.
6. Definisci i requisiti di accesso all’app.
7. Assegna la policy a un gruppo di utenti pilota.

Il naming conta più di quanto sembri. Se in futuro avrai più policy per area, piattaforma o livello di rigidità, il nome deve dirti subito a chi si applica e con quale scopo. Evita sigle opache che non si capiscono dopo tre mesi.

Impostazioni di protezione dati: il blocco più importante

Qui si decide quanto è stretta la separazione tra dati aziendali e dati personali. Le opzioni cambiano nel dettaglio a seconda della piattaforma, ma i concetti sono sempre gli stessi.

1. Restrizioni su copia e incolla: limita il trasferimento verso app non gestite. È una delle prime leve da verificare quando vuoi ridurre l’esfiltrazione accidentale.
2. Salvataggio con “Save As”: puoi limitare il salvataggio solo in posizioni gestite o impedirlo del tutto fuori dal perimetro aziendale.
3. Backup e sincronizzazione: evita che i dati aziendali finiscano in backup personali o servizi non autorizzati.
4. Apri in app gestite: controlla quali app possono ricevere contenuti da quella protetta.
5. Wipe selettivo: rimuove solo i dati aziendali nell’app, senza cancellare il dispositivo.

Un criterio pratico: se la policy è troppo permissiva, non serve a molto; se è troppo rigida, gli utenti la aggirano o aprono ticket a raffica. La soglia utile è quella che blocca i percorsi davvero rischiosi senza distruggere il lavoro quotidiano.

Un esempio concreto: su Outlook mobile puoi consentire la lettura della posta aziendale ma vietare il copia/incolla verso note personali o client non gestiti. In questo modo riduci il rischio di fuga dati senza impedire il normale uso dell’app.

Requisiti di accesso: PIN, biometria e timeout

La seconda area è quella del controllo dell’accesso all’app. Qui puoi imporre un PIN separato, usare la biometria se supportata, definire il timeout di inattività e richiedere il re-authentication periodico.

1. Imposta un PIN dell’app se vuoi separare la sicurezza aziendale da quella del dispositivo.
2. Definisci un timeout ragionevole, ad esempio pochi minuti per dati sensibili, più lungo per scenari meno critici.
3. Abilita la biometria solo se il parco dispositivi e le policy di sicurezza la supportano davvero.
4. Allinea il comportamento con l’esperienza utente: un timeout troppo aggressivo produce frizione inutile.

Qui la regola è non duplicare controlli già presenti altrove senza motivo. Se hai già un forte Conditional Access e una postura di rischio elevata, il PIN dell’app ha senso. Se stai già imponendo un device trust molto stretto, valuta se stai aggiungendo solo complessità operativa.

Assegnazione corretta: gruppi, scope e conflitti

La policy va assegnata a gruppi di utenti, non a caso. Il gruppo deve rappresentare il perimetro reale di chi usa le app in modalità MAM. In un tenant ordinato, conviene separare almeno tre insiemi: pilota, produzione e eccezioni.

1. Crea un gruppo pilota con pochi utenti rappresentativi.
2. Assegna la policy solo al pilota e osserva il comportamento per almeno un ciclo d’uso reale.
3. Controlla eventuali policy sovrapposte sullo stesso utente.
4. Solo dopo il test estendi il gruppo a produzione.

Un conflitto tipico è avere più policy con livelli diversi di restrizione sulla stessa piattaforma e sugli stessi utenti. In quel caso il comportamento finale non è sempre intuitivo. Se qualcosa non torna, controlla prima le assegnazioni e poi le impostazioni singole.

Conditional Access: il pezzo che fa funzionare davvero il modello

La policy MAM da sola non basta se l’accesso alle app non è coerente. In molti casi devi affiancarla a Conditional Access per imporre che l’accesso avvenga solo da app approvate e con protezione applicata.

Il modello più pulito è questo: l’utente si autentica con Entra ID, l’app viene riconosciuta come approvata, la policy MAM viene applicata e solo allora l’accesso ai dati aziendali è consentito. Se manca uno di questi anelli, la protezione si indebolisce o l’esperienza utente diventa incoerente.

Per verificare il flusso, controlla il pannello di Sign-in logs di Entra ID e cerca l’utente interessato. Lì puoi capire se il blocco arriva da Conditional Access, da mancata registrazione dell’app o da un problema di policy non applicata. Se il log mostra successo ma l’app non si comporta come previsto, il problema è quasi sempre nella protezione applicata all’app o nel supporto della versione installata.

Test pratici dopo la pubblicazione

Dopo aver assegnato la policy, non limitarti a vedere che “è verde” nel portale. Fai test funzionali sul dispositivo reale, perché la parte critica è il comportamento dell’app in mano all’utente.

1. Accedi con un account pilota su un dispositivo non gestito.
2. Apri l’app protetta e verifica che richieda l’autenticazione prevista.
3. Prova il copia/incolla verso una app non gestita.
4. Prova il salvataggio locale o l’apertura in un’altra app.
5. Verifica il wipe selettivo su un account di test, non su produzione.

Se vuoi un controllo più tecnico, la verifica lato client dipende dalla piattaforma e dall’app. In generale devi osservare due cose: il token di accesso viene emesso correttamente e la policy viene recepita dall’app. Se una delle due manca, il problema è a monte o nel supporto dell’app stessa.

Problemi comuni e come leggerli senza perdere tempo

Quando una policy MAM sembra non funzionare, i casi ricorrenti sono pochi.

• La policy è assegnata ma non si applica: spesso il gruppo è sbagliato, l’utente non è nel perimetro o l’app non è supportata.
• Le restrizioni sono troppo deboli: la policy esiste, ma i controlli dati sono impostati in modo permissivo.
• L’utente viene bloccato troppo presto: Conditional Access e MAM non sono allineati, oppure l’app non è aggiornata.
• Il wipe selettivo non produce l’effetto atteso: l’account non è stato realmente gestito come “corporate” dall’app, oppure il test è stato fatto su un profilo non coerente.

Il modo corretto di diagnosticare è partire dai log di accesso e dall’assegnazione policy, non dal tentativo di modificare subito tutte le impostazioni. Cambiare tre parametri insieme ti fa perdere il nesso causa-effetto.

Approccio consigliato per un rollout pulito

Se devi introdurre MAM in un ambiente già in esercizio, l’ordine giusto è quasi sempre questo: pilota, osservazione, estensione, rifinitura. Non partire con una policy massimamente restrittiva su tutta l’azienda.

1. Definisci il caso d’uso: BYOD, contractor, mobile email, accesso a documenti, collaborazione.
2. Costruisci una policy base con il minimo necessario di protezione.
3. Assegna a un gruppo pilota ristretto.
4. Raccogli feedback su compatibilità e frizione operativa.
5. Rafforza i controlli solo dopo aver visto come viene usata davvero.

Questo approccio riduce i ticket e ti permette di capire dove serve davvero il controllo. In molti tenant la tentazione è mettere tutto al massimo: è la strada più veloce per avere utenti bloccati e una policy che tutti considerano inutilizzabile.

Esempio di configurazione ragionata

Immagina una policy per Outlook mobile su dispositivi personali. L’obiettivo è permettere la consultazione della posta aziendale, ma impedire che i messaggi finiscano in app personali o in archivi non controllati.

1. Attiva un PIN dell’app.
2. Consenti solo copia/incolla verso app gestite.
3. Blocca il salvataggio in storage personale.
4. Consenti il wipe selettivo dei dati aziendali.
5. Assegna la policy a un gruppo pilota di utenti mobili.

In questo scenario il guadagno è chiaro: l’utente continua a lavorare, ma il dato aziendale resta dentro un perimetro controllato. È un compromesso molto più realistico di un blocco totale, soprattutto se il device non è di proprietà aziendale.

Manutenzione nel tempo

Una policy MAM non si crea una volta sola e poi si dimentica. Ogni aggiornamento delle app, ogni cambio di requisito di sicurezza e ogni modifica al Conditional Access può alterarne il comportamento.

1. Rivedi periodicamente le app supportate e le versioni minime.
2. Controlla che i gruppi di assegnazione siano ancora corretti.
3. Verifica che i log di accesso non mostrino blocchi anomali.
4. Rivedi i controlli su copia/incolla e salvataggio quando cambiano i processi aziendali.

La parte più sottovalutata è il drift operativo. Una policy perfetta oggi può diventare rumorosa o inefficace dopo un cambiamento di app, di versione OS o di modello di accesso. Per questo conviene trattarla come una configurazione viva, non come un documento statico.

Decisione pratica finale

Se vuoi proteggere i dati aziendali su dispositivi non gestiti, una policy MAM di Intune è spesso la soluzione più equilibrata. Ti consente di mettere barriere concrete senza imporre il controllo totale del dispositivo. Il successo però dipende dalla qualità dell’assegnazione, dall’allineamento con Conditional Access e dalla scelta di restrizioni che siano abbastanza forti da avere senso, ma non così rigide da rendere il servizio ingestibile.

La regola operativa è questa: prima osserva, poi restringi, infine standardizza. Se il tenant è pulito, la policy è ben assegnata e i test vengono fatti sul flusso reale, MAM diventa uno strumento molto efficace per tenere separati il dato aziendale e il resto del dispositivo.