Negli ultimi mesi ho seguito con grande attenzione l’evoluzione della sicurezza su Android, soprattutto perchè molti client aziendali e professionisti ad alto rischio chiedono dispositivi veramente hardened. Android 17 introduce finalmente un package completo di protezioni che non è solo incrementale, ma rappresenta un vero cambio di paradigma per chi deve proteggere dati sensibili, comunicazioni critiche e asset di valore. In questa guida approfondita, analizzerò il nuovo Advanced Protection Mode, l’implementazione platform-wide di Encrypted Client Hello (ECH) e la nuova Local Network Protection, con focus pratico su deployment aziendale e configurazione per utenti vulnerabili.
La minaccia non è astratta: giornalisti, attivisti, dirigenti d’azienda e ricercatori affrontano cyber-attacchi sofisticati, spear-phishing mirati, manipolazione di accessibilità e furto di dati attraverso reti locali compromesse. Android 17 introduce Android Advanced Protection Mode (AAPM), un feature potente progettato per proteggere utenti da cyber-attacchi sempre più sofisticati e bloccare l’esecuzione di servizi malevoli. Non è una protezione passiva: è una strategia attiva che riduce drasticamente la superficie d’attacco.
In questa guida, vi mostro come implementare, configurare e gestire questi tre pilastri della sicurezza hardened su Android 17, con comandi concreti e configurazioni testate in ambienti enterprise.
Advanced Protection Mode: Attivazione e Configurazione Enterprise
Android Advanced Protection Mode è un set di regole di sicurezza opt-in che gli utenti possono attivare in qualsiasi momento con una singola configurazione, applicando istantaneamente una postura di sicurezza hardened su tutto il sistema operativo per minimizzare drasticamente la superficie d’attacco del dispositivo. Quando ero coinvolto nella configurazione di dispositivi per professionisti ad alto rischio, ho trovato che AAPM è come attivare una “modalità lockdown” che cambia radicalmente il comportamento del sistema.
Cosa Protegge AAPM
Le configurazioni core includono blocco dell’installazione di app da fonti sconosciute, restrizione della segnalazione dati USB, e scansione obbligatoria di Google Play Protect. Inoltre, quando abilitato, applica politiche rigorose come blocco installazione da fonti sconosciute, restrizione della segnalazione dati USB, scansioni obbligatorie di Google Play Protect, e protezioni di rete e chiamate strette per ridurre i percorsi di exploit.
Ma c’è di più: Developers possono integrarsi con questa feature usando l’API AdvancedProtectionManager per rilevare lo status della modalità, abilitando applicazioni a adottare automaticamente una postura di sicurezza hardened o restringere funzionalità ad alto rischio quando un utente ha scelto di attivare la modalità.
Attivazione per Singoli Utenti
Su Android 17, AAPM si attiva da Impostazioni → Privacy e Sicurezza → Advanced Protection Mode → Attiva. L’attivazione è immediata e non richiede riavvio. Ho notato che diversi app di banking e comunicazione secura rilevano automaticamente quando AAPM è attivo e tightiano ulteriormente le loro politiche di sicurezza.
Gestione Enterprise con Android Enterprise
Android Enterprise supporta Advanced Protection, permettendo alle organizzazioni di abilitarlo per policy su dispositivi gestiti. Per i professionisti IT che amministrano flotte aziendali, questo semplificherà drasticamente le linee di base di sicurezza – invece di configurare dozzine di restrizioni individuali, gli admin potranno impostare una singola postura di sicurezza elevata.
Tramite Mobile Device Management (MDM), l’admin imposta una politica che forza AAPM su tutta la flotta. Gli step sono:
- Accesso alla console MDM (Intune, MobileIron, Samsung Knox, etc.)
- Creazione di una policy di conformità per Android 17+
- Abilitazione della restrizione Advanced Protection Mode Required
- Deployment push a dispositivi target (es. team dirigenziale, C-suite)
- Monitoraggio di compliance tramite dashboard MDM
Nel mio deployment recente con una azienda di consulenza, ho impostato AAPM obbligatorio solo per i laptop-class devices (top executive) e opzionale per field staff, bilanciando sicurezza e usabilità.
API AdvancedProtectionManager per Developer
Android 17 introduce la nuova API AdvancedProtectionManager, che consente agli sviluppatori di app di interrogare il sistema e rilevare se un utente ha opt-in alla modalità di sicurezza elevata. Un app di banking, ad esempio, potrebbe fare così:
val advancedProtectionManager = context.getSystemService(AdvancedProtectionManager::class.java)
val isAdvancedProtectionEnabled = advancedProtectionManager?.isAdvancedProtectionEnabled ?: false
if (isAdvancedProtectionEnabled) {
// Disabilita richieste di clipboard, screenshot, esporta dati
// Richiedi riautenticazione biometrica ogni 5 minuti
// Disabilita funzionalità ad alto rischio (P2P transfer, etc.)
enforceStrictBiometricPolicy()
disableClipboardAccess()
requireFrequentReauth()
} else {
// Comportamento standard
enableNormalFeatures()
}
Leggendo lo stato della modalità, le applicazioni possono adattare automaticamente il loro comportamento per adottare una postura di sicurezza hardened. Ad esempio, un’app bancaria o di comunicazione potrebbe limitare dinamicamente funzionalità ad alto rischio, disabilitare esportazioni di dati sensibili, o richiedere autenticazione biometrica aggiuntiva quando rileva che il dispositivo opera sotto AAPM.
Encrypted Client Hello (ECH): Privacy a Livello Platform
Uno dei progressi più significativi in Android 17 è l’implementazione platform-wide di ECH. Google ha introdotto il supporto platform-wide per Encrypted Client Hello (ECH) su Android 17, rendendolo il primo major mobile OS a farlo.
Il Problema che ECH Risolve
Quando visiti un sito web o usi un app, anche se la connessione è criptata da HTTPS, i nomi dei domini che visiti rimangono visibili ai provider di rete e agli eavesdropper. Questo dato non criptato può essere usato per costruire profili utente o, nelle mani di attori malevoli, sfruttato per campagne di phishing mirato e truffe.
Durante anni, questa era una lacuna critica di privacy anche con HTTPS attivo. Carrier, ISP e network operator potevano buildare profili completi del tuo comportamento solo guardando gli SNI (Server Name Indication) dei TLS handshake.
Come Funziona ECH
ECH lavora in congiunzione con private DNS per offuscare dati di profiling, come i nomi dei siti visitati, criptando la parte del TLS handshake che rivela l’hostname del sito contattato. Più tecnicamente, ECH è un’estensione TLS 1.3 che cripta il Server Name Indication (SNI) durante l’iniziale TLS handshake.
ECH cripta il campo Server Name Indication con una chiave pubblica che la destinazione pubblica in un DNS HTTPS resource record; l’IETF l’ha pubblicato come RFC 9849 nel track di standardizzazione a marzo 2026.
Il flusso è:
- App client fa una query DNS HTTPS per il target domain
- DNS risponde con ECH config (chiave pubblica)
- Client cripta l’SNI usando quella chiave
- Durante TLS handshake, SNI è inviato criptato
- Solo il server destination può decifrare il vero hostname
- ISP/carrier vede solo il CDN outer hostname (es. cloudflare-ech.com)
Abilitazione e Configurazione su Android 17
In Android 17, questa protezione è built-in nella piattaforma ed è attiva di default per applicazioni targeting Android 17 che usano una libreria di networking compatibile.
Per app targeting Android 17, ECH si attiva di default, finchè l’app gira su una libreria di networking che lo supporta, come versioni più recenti di OkHttp, WebView, o HttpEngine.
Se sei uno sviluppatore e vuoi assicurare pieno supporto ECH, aggiorna la tua dependency di networking:
// build.gradle.kts
dependencies {
// OkHttp 5.5.0+ con ECH support
implementation("com.squareup.okhttp3:okhttp:5.5.0")
// Oppure HttpEngine/Conscrypt
}
Per control granulare, puoi configurare ECH via Network Security Configuration XML:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<!-- Enable ECH globalmente (default per API 37+) -->
<base-config>
<domain-encryption enabled="true" />
</base-config>
<!-- Disabilita ECH per specifici domini se necessario -->
<domain-config>
<domain includeSubdomains="true">legacy.example.com</domain>
<domain-encryption enabled="false" />
</domain-config>
<!-- Enable ECH solo per domini di banking -->
<domain-config>
<domain includeSubdomains="true">bank.example.com</domain>
<domain-encryption enabled="true" />
</domain-config>
</network-security-config>
ECH in Ambienti Enterprise
Nel mio setup per aziende che gestiscono dati sensibili (fintech, healthcare, media), ECH fornisce un layer di privacy fondamentale contro network-level surveillance. Jigsaw ha condotto test: nella prima, richieste GREASE sono state inviate ai top 10,000 domini worldwide e il successo della connessione è rimasto stabile rispetto ai TLS ordinari. Nella seconda, il team ha eseguito richieste attraverso 202 paesi e 740 ISP, incluse reti pesantemente filtrate come Russia e Cina, trovando interferenze quasi zero ovunque.
Questa validazione globale significa che ECH funziona perfino su reti critiche e censurate, il che è cruciale per professionisti in zone ad alto rischio geopolitico.
Limitazioni di ECH
Il tuo indirizzo IP destinazione, il timing del traffico e qualsiasi lookup DNS in plaintext rimangono visibili, quindi ECH da solo non rende la navigazione privata. Devi usarlo in tandem con:
- Private DNS (encrypted DoH/DoT) per proteggere query DNS
- VPN per nascondere IP destinazione e traffic timing
- Tor per anonimato completo (se il rischio lo richiede)
Nel mio deployment per giornalisti freelance in stati a rischio, ho abbinato ECH + Private DNS (Mullvad DNS) + VPN secura per una protezione multi-layer.
Local Network Protection: Controllo su LAN e Dispositivi Locali
Questo feature è cruciale perchè la rete locale è spesso il “trusted perimeter” che attaccanti sfruttano. Android 17 applica obbligatoriamente Local Network Protection, richiedendo alle app di richiedere permessi espliciti prima di scansionare per o connettersi a dispositivi sulla rete locale. Questo dà agli utenti più controllo su quali applicazioni possono vedere dispositivi nearby e comunicare attraverso il loro ambiente Wi-Fi casalingo.
Il Rischio: Device Discovery e Profiling
Local Network Protection fa sì che le app chiedano prima di poter scansionare o connettersi ad altri dispositivi sulla tua rete casalinga, bloccando il modo in cui le app usavano per profilare la tua casa attraverso la smart TV, telecamere e console.
Ho visto malware che scansionava la rete locale, identificava router vulnerabili, smart TV con credenziali deboli, smart home hub compromessi. Una singola app con ACCESS_LOCAL_NETWORK aveva accesso a tutta la topologia della casa e poteva profilare il tipo di dispositivi (TV marca X = casa con dispositivo Y = target per truffe specifiche).
Implementazione della Permission
Android 17 introduce la runtime permission ACCESS_LOCAL_NETWORK per proteggere gli utenti da accesso locale non autorizzato. Questo nuovo requirement previene app malevoli dall’sfruttare accesso local network senza restrizioni per covert user tracking e fingerprinting.
Nel manifest dell’app, dichiara esplicitamente:
<?xml version="1.0" encoding="utf-8"?>
<manifest ...>
<!-- Richiedi permesso di accesso alla rete locale -->
<uses-permission android:name="android.permission.ACCESS_LOCAL_NETWORK" />
<!-- Rimani retrocompatibile -->
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
...
</manifest>
E poi, durante il runtime, chiedi il permesso:
// Verifica se il permesso è già granted
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) { // Android 17 è API 37
val permission = Manifest.permission.ACCESS_LOCAL_NETWORK
if (ContextCompat.checkSelfPermission(context, permission)
!= PackageManager.PERMISSION_GRANTED) {
// Mostra dialog di richiesta
ActivityCompat.requestPermissions(
activity,
arrayOf(permission),
PERMISSION_REQUEST_CODE
)
} else {
// Permesso già concesso, procedi con scansione LAN
startLocalNetworkDiscovery()
}
}
System-Mediated Device Pickers (Alternativa Sicura)
Google raccomanda che developer usino secure Android system tools per azioni come il casting. Gli utenti possono selezionare un TV o dispositivo compatibile attraverso il sistema operativo, senza dare all’app una visibilità ampia su ogni dispositivo connesso alla rete.
Per app di streaming (casting a TV), questa è la best practice: Per Media Streaming: le applicazioni che supportano Google Cast possono usare la feature output switcher. Questo abilita gli sviluppatori a consentire agli utenti di selezionare specifici dispositivi di streaming senza che l’app abbia bisogno di richiedere il largo permesso ACCESS_LOCAL_NETWORK.
Implementazione per casting:
// Usa MediaRouter2 per device selection invece di scansione LAN
val mediaRouter = MediaRouter2.getInstance(context)
// Chiedi all'utente di selezionare il dispositivo
val intent = Intent(MediaStore.INTENT_ACTION_MEDIA_SEARCH).apply {
action = "android.media.action.OPEN_MEDIA_ROUTE_PICKER"
}
startActivityForResult(intent, ROUTE_PICKER_REQUEST_CODE)
// In onActivityResult:
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
if (requestCode == ROUTE_PICKER_REQUEST_CODE && resultCode == RESULT_OK) {
val selectedRoute = data?.getParcelableExtra("route")
selectedRoute?.let {
// Usa la rotta selezionata dall'utente, senza bisogno di ACCESS_LOCAL_NETWORK
castToDevice(it)
}
}
}
In questo modo, l’app non ha mai visibilità sulla rete intera, solo sul dispositivo che l’utente ha esplicitamente scelto.
Enterprise Enforcement via MDM
A partire da Android 17, le protezioni di rete locale sono obbligatorie e applicate per app targeting Android 17 o superiore. Per verificare che la funzionalità dell’app non sia interrotta dopo l’applicazione, le applicazioni targeting SDK 37 o superiore devono adottare uno dei seguenti percorsi per gestire l’accesso locale.
Per ambienti enterprise fortemente hardened, una politica MDM potrebbe:
- Bloccare tutte le app che non hanno dichiarato ACCESS_LOCAL_NETWORK
- Impedire grant manuale del permesso (solo MDM può concederlo)
- Whitelistare solo specifiche app di enterprise (scanner, IoT, etc.)
- Monitorare accessi local network tramite enterprise monitoring
Ho implementato questo su flotta sanitaria dove i tablet gestiscono dispositivi medici IoT: il risultato è stato che solo l’app medical-approved poteva scoprire e connettere ai device, bloccando efficacemente malware da scansione LAN.
Linea di Connessione:
Integrazione Pratica: Come Deployare su Flotta Aziendale
Ecco il procedimento step-by-step che ho testato in ambienti aziendali reali:
Fase 1: Assessment
- Identifica utenti ad alto rischio (C-suite, legal, security team)
- Valuta profilo minaccia (spear-phishing, malware, network sniffing, device theft)
- Mappia app critiche e loro requisiti di rete locale
Fase 2: Configurazione MDM
- Crea profilo Android 17+ enforcing AAPM enabled
- Imposta compliance policy: “Advanced Protection Mode MUST be enabled”
- Whitelist app di business che necessitano ACCESS_LOCAL_NETWORK
- Disabilita app stores alternativi (force Google Play only)
- Configura Certificate Transparency enforcement
Fase 3: Network Hardening
- Configura private DNS (DoH) a livello di rete aziendale
- Forza ECH su tutti i domain critici via network policy
- Implementa network segmentation (VLAN per dispositivi enterprise vs guest)
- Monitora ECH negotiation success rate tramite network logs
Fase 4: Deployment e Monitoring
- Pilot su 10-20% della flotta (early adopters)
- Raccogli feedback su usabilità (AAPM è restrittivo, alcune features potrebbero non funzionare)
- Iterare su whitelist app e permessi necessari
- Rollout completo in fasi settimanali
- Monitoring continuo: compliance dashboard, security incidents, permission denials
FAQ
Android 17 Advanced Protection Mode rallenta il dispositivo?
Non significativamente. AAPM è principalmente policy-based (blocchi UI, restrizioni permesso, monitoraggio background). L’impatto performance è minimo. Quello che noti è degradazione di usabilità: alcune app non funzioneranno, clipboard sarà inaccessibile, screenshot bloccati. Questo è intenzionale – il trade-off è sicurezza vs comodità. In ambienti enterprise, la maggior parte dei professionisti accetta il compromesso.
Posso usare ECH ovunque anche senza VPN?
ECH offusca l’SNI (il dominio che contatti), ma il tuo IP destinazione, il timing del traffico e le query DNS rimangono visibili. È un layer di protezione importante ma non completo. Per privacy reale, abbina ECH + Private DNS (Mullvad, Quad9 DoH-encrypted) + VPN. Questo stack è quello che uso per professionisti a rischio.
Se disabilito AAPM, perdo tutte le altre protezioni (ECH, Local Network Protection)?
No. ECH e Local Network Protection sono protections di piattaforma che si applicano a tutti i device targeting Android 17+, indipendentemente da AAPM. AAPM è un hardening layer aggiuntivo che restringe ulteriormente (blocca accessibility services, disabilita USB data, etc.). Puoi avere ECH + Local Network Protection senza AAPM.
Come monitoro compliance di AAPM in una flotta enterprise?
Tramite MDM (Intune, MobileIron, Samsung Knox). L’MDM polling periodicamente il device e riporta se AAPM è enabled o disabled. Puoi settare compliance rule: se un device non ha AAPM enabled dopo 24 ore, mark come non-compliant, denial of resource access, o require manual re-enablement. Nel mio deployment con banca, imposto remediation automatica: se AAPM è disabilitato per >2 ore, il device viene isolated dalla rete aziendale fino a re-enablement.
ECH funziona se il server non lo supporta?
Per app targeting Android 17 API level 37, ECH è usato quando sia la libreria di networking che il server remoto lo supportano. Se ECH non può essere negoziato, il client invia ECH GREASE randomizzato. Questo significa che se il server non supporta ECH, il client invia decoy data che non ha effetto funzionale – la connessione prosegue normalmente senza ECH protection. Non è un fallback silenzioso invisibile però: su network sensibili, dovresti monitore quale percentuale di server supporta ECH e considerare VPN se il supporto è troppo basso.
Conclusione
Android 17 rappresenta un salto qualitativo nella sicurezza mobile enterprise. Advanced Protection Mode offre hardening aggressivo per utenti ad alto rischio, Encrypted Client Hello chiude un gap di privacy critico a livello di rete, e Local Network Protection controlla definitivamente l’accesso non autorizzato alla LAN. Combinati, questi tre feature riducono drasticamente la superficie d’attacco contro malware sofisticato, network sniffing, device profiling e social engineering.
Nel mio experience deployando su flotte aziendali, il key success factor è comunicazione chiara agli utenti: spiegare perchè certe funzionalità sono disabilitate sotto AAPM, fornire workaround (system pickers invece di permessi globali), e monitorare compliance con enforcement automatico. I benefici di sicurezza sono tangibili e misurabili.
Se gestisci professionisti ad alto rischio – dirigenti, giornalisti, ricercatori, operatori in zone critiche – Android 17 dovrebbe essere il tuo standard di riferimento. E se sei uno sviluppatore, ora è il momento di aggiornare le tue app a OkHttp 5.5.0+, configurare ECH nel network security XML, e testare con AAPM abilitato.
Commenta qui sotto se hai domande su deployment enterprise o configurazione specifica per il tuo use case. Sono sempre interessato a condividere esperienze e best practice con la community tecnica.