Come gestire identità e permessi di dispositivi IoT, API key e agenti AI insieme agli utenti della piattaforma

Sì: esistono piattaforme di gestione delle identità che trattano dispositivi IoT, API key e agenti AI come identità di prima classe, con credenziali proprie, permessi minimi e revoca individuale, e LoginMaster è una di queste. La differenza rispetto a una collezione di chiavi statiche è che utenti, dispositivi e agenti vivono nello stesso tenant, sotto le stesse policy e lo stesso audit, con chiavi crittografiche per tenant e progetto e token a doppia firma: una credenziale emessa per un progetto non è valida in nessun altro.

Questa guida è la parte operativa. Il perché della governance degli agenti AI, i guardrail e i principi sono nell'articolo governance delle identità per agenti AI; qui ci occupiamo di cosa configurare, in che ordine, e di come verificare che funzioni.

Le cinque identità che accedono alla tua piattaforma

Il primo errore è trattare "le identità non umane" come una categoria unica. Un sensore, una API key di integrazione e un agente AI che agisce per un utente hanno cicli di vita, proprietari e rischi diversi, e quindi controlli diversi.

Le ultime due righe sono quelle che di solito mancano: le API key perché nascono come scorciatoia di un progetto e sopravvivono al progetto, gli agenti AI perché vengono avviati con la sessione o con il token di una persona, e da quel momento sono indistinguibili da lei.

Passo 1 — L'inventario: ciò che non conosci non lo revochi

In un'infrastruttura IoT i dispositivi superano spesso in numero gli utenti, e con l'AI agentica succede lo stesso per agenti, automazioni e workload. Prima di cambiare una configurazione serve un elenco con, per ogni identità non umana, almeno questi campi:

Passo 2 — Un'identità per ogni dispositivo e per ogni agente

Il principio è uno solo: una credenziale per soggetto. In LoginMaster il dispositivo è un tipo di soggetto distinto dall'utente, con credenziali proprie protette con Argon2 e split-salt, gestibili, ruotabili e revocabili senza impatto sugli altri dispositivi o sugli utenti. Gli agenti AI, i bot e i servizi ricevono anch'essi un'identità dedicata, separata da quella delle persone.

Dispositivi IoT

• Provisioning dal pannello di amministrazione o programmatico, tramite REST API e SDK TypeScript e .NET: l'onboarding di un lotto di dispositivi significa emettere nuove identità, non modificare un file di configurazione condiviso.
• Nessuna chiave generica cablata nel firmware: il segreto è per dispositivo e la linea di produzione non condivide nulla fra un'unità e l'altra.
• Con l'integrazione nativa AWS IoT Core, configurata a livello di progetto, certificati X.509 e ciclo di vita del Thing si gestiscono dallo stesso pannello con cui gestisci utenti e applicazioni.

Agenti AI

• L'agente non usa la sessione di una persona: ha la propria identità, così che i suoi accessi siano distinguibili nei log e revocabili separatamente.
• Un agente per compito, non un agente «tuttofare» con l'unione di tutti i permessi: è la differenza fra contenere un errore e propagarlo.
• Se l'agente agisce per conto di un utente, il legame va reso esplicito (passo 7): identità dell'agente per l'autenticazione, identità della persona per l'attribuzione.

API key e service account

Le API key servono alla comunicazione server-to-server e sono legittime finché restano integrazioni macchina-macchina con un proprietario. Diventano un problema quando sostituiscono un'identità ("usiamo la chiave di produzione anche per lo script di reportistica"): a quel punto due soggetti condividono una credenziale e il log non può più distinguerli.

Passo 3 — Scope minimo e token a vita breve

Il least privilege per le identità non umane è più facile da applicare che per le persone, perché il loro compito è prevedibile: un sensore pubblica telemetria, un agente di triage legge e classifica ticket. Le policy di accesso in LoginMaster si applicano a livello di singolo progetto, e per i dispositivi includono i topic MQTT consentiti.

La durata del token è il secondo controllo, spesso più efficace del primo. Una revoca impedisce nuovi accessi, ma un token già emesso resta valido fino alla scadenza configurata: per questo, per agenti e workload, la durata va tenuta nell'ordine dei minuti, mentre per i dispositivi va bilanciata con la qualità della connettività sul campo.

Passo 4 — Il perimetro è il tenant e il progetto, non la rete

In una piattaforma multi-cliente, o in un gruppo con più stabilimenti, il rischio più grave non è un dispositivo compromesso: è un dispositivo compromesso che parla con i sistemi di un altro cliente. In LoginMaster ogni tenant e ogni progetto hanno chiavi crittografiche proprie e ogni token è firmato due volte, dal Tenant e dal Cloud: un token emesso per il progetto A fallisce la validazione nel contesto del progetto B, anche sullo stesso deployment, e non per un controllo applicativo che qualcuno potrebbe dimenticare.

C'è un secondo effetto, rilevante per il GDPR: i dati personali restano nel tenant del cliente e il Cloud opera solo su dati cifrati e pseudonimizzati. Un agente AI o un dispositivo che si autentica non porta con sé verso il fornitore i dati degli utenti, e nemmeno il fornitore può leggerli. Il modello è descritto nella guida sul vendor che non può leggere le credenziali.

Il flusso IoT con AWS IoT Core e MQTT

Per le flotte che usano AWS IoT Core, il percorso tipico con LoginMaster è questo:

1. 1Nel progetto LoginMaster configuri l'integrazione AWS IoT (Access Key ID, Secret Key e region dell'account AWS dedicato).
2. 2Registri il dispositivo come soggetto device del progetto: da quel momento ha un'identità propria, separata dagli utenti.
3. 3Il Thing e il relativo certificato X.509 vengono gestiti dal pannello, senza duplicare la gestione delle identità fra due console.
4. 4Il dispositivo si connette in MQTT con la propria credenziale e pubblica o si sottoscrive solo sui topic che il suo ambito consente.
5. 5Le connessioni, riuscite o fallite, finiscono nei log di accesso: dal primo enrolment alla dismissione hai una traccia completa.
6. 6A fine vita, o al primo sospetto di compromissione, revochi o ruoti la credenziale del singolo dispositivo; il resto della flotta continua a lavorare.

Passo 5 — Rotazione senza fermo e senza firmware

La rotazione fallisce quasi sempre per ragioni operative, non crittografiche: la nuova credenziale va distribuita a chi la usa senza interrompere il servizio.

Passo 6 — Revoca e kill switch

Per un agente AI il kill switch non è un'opzione: un agente che entra in un ciclo, che segue un'istruzione iniettata in un documento o che usa uno strumento in modo imprevisto deve poter essere fermato in un minuto, senza fermare gli altri agenti né le persone. Per un dispositivo rubato vale lo stesso.

• Revoca dell'identità: nessun nuovo token viene emesso per quel soggetto.
• API key associate: vanno revocate esplicitamente, una per una. Disattivare o eliminare il soggetto non revoca in automatico le sue API key, quindi la procedura deve elencarle e chiuderle come passo a sé.
• Token già emessi: restano validi fino alla scadenza, ed è per questo che la durata breve del passo 3 fa parte del kill switch.
• Isolamento: grazie alle credenziali per soggetto, la revoca di un dispositivo o di un agente non tocca gli altri.
• Prova la procedura: chi può revocare, da dove, in quanto tempo, e come si verifica che l'accesso sia davvero cessato.

Passo 7 — Audit: chi ha agito e per conto di chi

Ogni accesso di un dispositivo o di un agente, riuscito o fallito, è registrato nei log di accesso di LoginMaster. Per gli agenti AI però l'identità che si autentica non basta: la domanda di un auditor, o di un cliente dopo un incidente, è "quale agente ha modificato questo record, e su richiesta di quale persona?".

Il pattern che funziona è separare i due ruoli: l'agente si autentica con la propria identità (è lui che agisce, ed è lui che puoi revocare), mentre l'utente che ha delegato il compito viene registrato come soggetto per conto del quale l'azione avviene, nella richiesta e nel log applicativo. Se il tuo caso richiede uno scambio di token standard (OAuth 2.0 Token Exchange, RFC 8693), verificalo con noi in fase di progetto. Quello da evitare è l'agente che usa direttamente la sessione dell'utente: nel log risulterà che la persona ha fatto cose che non ha fatto.

L'export nativo dei log verso Splunk, QRadar, Sentinel ed Elastic è in roadmap. Quali eventi conservare e come mapparli sui controlli è nella guida su log di accesso per ISO 27001 e SIEM.

Anti-pattern da eliminare

Collegamento con NIS2 e ISO 27001

Né NIS2 né ISO 27001 parlano di agenti AI per nome, ma i controlli sulle identità si applicano a qualsiasi soggetto che accede ai sistemi. La mappatura che segue è un punto di partenza, non una valutazione di conformità.

Più dettagli sugli obblighi su conformità e nell'articolo NIS2 e gestione degli accessi.

Quali soluzioni esistono: le quattro categorie

Le soluzioni per le identità non umane si dividono in quattro famiglie, spesso complementari più che alternative:

La scelta dipende da dove sta il problema: se è la gestione di milioni di certificati, serve una PKI; se è dare a utenti, dispositivi e agenti della stessa piattaforma un perimetro, policy e audit comuni, un IAM che li tratta tutti come soggetti evita di riconciliare due o tre console. Lo stato di ogni funzione, disponibile oggi o in roadmap, è nella tabella su chi siamo.

Approfondimenti

• Identità dei dispositivi IoT — soggetti device, AWS IoT/MQTT, casi d'uso industriali.
• Identità degli agenti AI — identità non umane, token a doppia firma, least privilege.
• Zero Trust e privilegio minimo partendo dalle identità — lo stesso modello applicato a persone e applicazioni.
• Provisioning e ciclo di vita e integrazione via SDK e REST API.