Sicurezza degli accessi: quando lacune legali, operative e firmware si allineano

A Southaven, Mississippi, un mediatore bussa alla porta e offre di comprare la casa. In cambio chiede di firmare una rinuncia a cause sul rumore di un data center e su una centrale elettrica nella stessa vertenza. La lettera porta il nome MZX, società legata a xAI. Dice che MZX “nega tutte le accuse” e, “poiché MZX richiede anche immobili per le proprie necessità di business”, propone l’acquisto con una liberatoria da “tutte le rivendicazioni” connesse alla causa. The Guardian, ripreso da The Verge, riporta la testimonianza di un residente: un agente avrebbe parlato di 418 abitazioni. Diciotto proprietari avrebbero già pianificato la vendita¹. Qui l’accesso non riguarda una dashboard: passa per una clausola legale. La tesi: problemi di controllo degli accessi attraversano fisico, rete, applicazioni, identità e firmware. La stessa carenza di governance e automazione espone risorse e persone.

Accesso fisico e controllo legale: offerte di acquisto come strumento operativo

La mossa di MZX usa un mezzo ordinario, l’acquisto immobiliare, per ottenere un effetto preciso: ridurre il rischio legale attorno a un data center e a una centrale elettrica oggetto della stessa vertenza. Le lettere fanno leva su una rinuncia a rivendicazioni legate al rumore prodotto da questi impianti. Secondo il racconto riportato, l’operazione potrebbe toccare 418 abitazioni, con 18 vendite già pianificate¹.

L’elemento comune con la sicurezza informatica è l’uso di condizioni di accesso in forma contrattuale. La clausola di liberatoria limita ciò che gli ex proprietari potranno reclamare. Senza una governance che colleghi impatto locale e gestione del rischio, l’operazione legale diventa lo strumento di mitigazione. È un segnale: quando le misure tecniche e organizzative non bastano, il controllo si sposta sul terreno dei diritti.

API, dati e attacchi abilitati da AI: la superficie applicativa che si apre

Il 18 settembre 123 Reg ha subito un attacco definito “guidato da AI”. L’azienda segnala l’esposizione di dati clienti. Le informazioni includono contatti, numeri di partita IVA aziendali e “product information” ottenute anche tramite API. Un portavoce elenca dati come nome, numero di telefono, paese, preferenze di lingua e di valuta, data di creazione dell’account, prodotti associati e preferenze di marketing². Qui l’accesso non è fisico, ma logico, e sfrutta interfacce documentate.

L’indagine attribuisce un ruolo a “AI cyberattack skills” ospitate su infrastruttura in Cina. Tra gli elementi citati ci sono copie di skill open source pubblicate da Anthropic, altri framework e script di sfruttamento orientati all’uso di AI. Gli indicatori includono indirizzi IP in Cina e a Singapore. Sulla base di questi segnali, 123 Reg parla di un attore con legami con la Cina². La lezione riguarda il controllo delle API: più parti del profilo cliente risultano estraibili via integrazioni. Senza politiche di minimizzazione e piani di revoca delle chiavi, l’interfaccia applicativa diventa la porta principale.

La connessione con Southaven è indiretta ma netta: l’accesso si governa prima di tutto a monte, con definizioni chiare di cosa si espone e a quali condizioni. In assenza di quel disegno, si scivola nella gestione ex post, tra liberatorie e notifiche.

Provisioning e deprovisioning: il rischio degli accessi residui nelle applicazioni

Un cliente rimuove un dipendente dal tuo SaaS. L’amministratore si aspetta la chiusura. Invece l’utente entra ancora. Il motivo è noto a chi costruisce prodotti multi-tenant: stato dell’account, sessioni attive, token di accesso, servizi connessi. Se questi quattro pezzi non restano allineati, l’utente che doveva uscire conserva aperture inattese. Basta un solo anello in ritardo per lasciare un varco³.

La scala peggiora tutto. Aumentano gli utenti e le integrazioni. Crescono i casi di desincronizzazione. I clienti enterprise aggiungono single sign-on e delegano ruoli a identity provider centrali. Il tuo SaaS deve reagire a perdita di accesso, cambio di ruolo, uscita dall’organizzazione. Se la revoca non invalida sessioni e token in modo coerente, l’architettura distribuisce il rischio anziché contenerlo³.

Questo è controllo degli accessi come processo, non come funzione singola. Senza test continui, gli stati divergono e la revoca resta solo un flag nel database. Il parallelismo con le API è naturale: anche le chiavi e le sessioni sono interfacce. Vanno inventariate, limitate e revocate in modo tracciabile.

Firmware e boot: accessi precoci e controllo dell’integrità della piattaforma

CVE-2026-97631, gravità 9,5, consente esecuzione di codice nel firmware UEFI in fase di avvio. Il difetto nasce da una corruzione di memoria in un componente ICMP del firmware. Un attaccante può colpire prima che parta il sistema operativo e prima che il firmware applichi difese come Secure Boot. Secure Boot impone una catena di fiducia per il codice di avvio, incluso il Trusted Platform Module. Qui il codice malevolo può correre prima di quella catena⁴.

L’ampiezza dipende dal ruolo di TianoCore EDK II. Un rappresentante dell’UEFI Forum lo descrive come “la soluzione/implementazione preminente” delle specifiche UEFI. Quasi tutti i fornitori UEFI, spesso chiamati IBV, partono da quel codice di riferimento. Tra i nomi citati ci sono AMI, Insyde, Phoenix. Anche Project Mu, il fork EDK2 con obiettivi di hardening mantenuto da Microsoft, aveva incluso il codice interessato⁴. Una falla così bassa nella pila può annullare controlli impostati più in alto. Identità, permessi e regole applicative poggiano su un avvio integro.

Il legame con gli altri casi è netto. Se la base della piattaforma accetta codice ostile prima della catena di fiducia, la disciplina su API o deprovisioning perde valore. Il controllo degli accessi deve partire dal firmware e risalire fino al contratto con l’utente.

Che cosa collegano questi casi e dove intervenire prima di cercare rimedi puntuali

I quattro episodi mostrano una stessa falla di governance. L’accesso non si controlla a un solo livello. Vive in contratti, firmware, rete, applicazioni e identità. Soluzioni isolate non bastano. Servono misure coordinate e verificabili. Alcune linee, ancorate ai fatti:

• Per operazioni immobiliari che incidono su infrastrutture, legare le clausole a pratiche di trasparenza sul rischio e a canali di segnalazione pubblici. Senza trasparenza, la liberatoria diventa l’unico strumento di mitigazione¹.
• Per le API, ridurre la superficie esposta e imporre limiti e auditing. Valutare accessi machine-to-machine con scadenze brevi e revoca centralizzata delle chiavi. L’incidente 123 Reg mostra l’impatto quando i dati restano ampiamente disponibili via API².
• Per il deprovisioning, trattare sessioni e token come asset. Invalidare le sessioni al cambio di stato. Propagare le revoche ai servizi connessi. Testare i flussi con account reali e identità SSO³.
• Per il firmware, inserire verifiche e hardening della supply chain UEFI nei requisiti. Controllare la disponibilità di patch per componenti derivati da EDK II e da Project Mu quando applicabile⁴.

Il punto non è aggiungere un altro controllo, ma sincronizzare quelli esistenti. La coerenza tra livelli riduce il tempo in cui una finestra resta aperta. È quel tempo che un acquirente, un attaccante o una sessione orfana possono sfruttare. La prossima indagine che mette insieme lettere porta a porta, API rumorose, permessi residui e firmware vulnerabile non sorprenderà chi misura gli accessi come una catena unica e pretende prove di allineamento a ogni anello.