Licenze: diritti d’uso, metriche e punti di conteggio tecnici

La licenza software collega un contratto legale di utilizzo a oggetti misurabili tecnicamente. Per gli amministratori è essenziale non confondere questi livelli. Una chiave di licenza, un indicatore cloud o un contatore interno di utenti può attivare funzioni e misurare l’utilizzo; tuttavia non definisce da solo ciò che un’organizzazione può utilizzare legalmente. ISO/IEC 19770-3 tratta esplicitamente i dati di entitlement digitali come rappresentazione dei diritti d’uso e chiarisce che le condizioni di licenza originali prevalgono a fini legali (ISO/IEC 19770-3:2016).

Il compito operativo consiste quindi nel confrontare in modo riproducibile i diritti acquisiti, i diritti installati o assegnati tecnicamente e l’utilizzo effettivo. Le discrepanze possono indicare sovrautilizzo, costi inutilizzati, filtri di directory errati, account orfani, nodi passivi di cluster, token scaduti o semplicemente definizioni diverse della stessa parola «utente». L’articolo descrive la prospettiva tecnica; l’interpretazione contrattuale e legale resta di competenza di acquisti, gestione delle licenze e consulenza legale.

La spiegazione parte dal diritto d’uso contrattuale e segue il modo in cui prodotto, metrica e punto di conteggio tecnico ne ricavano un consumo misurato. Seguono assegnazione, enforcement, audit, casi speciali e ripristino.

Una licenza è anzitutto un diritto d’uso; diventa tecnicamente visibile solo tramite assegnazione, utilizzo misurato ed eventualmente enforcement. L’articolo separa questi quattro livelli prima di trattare metriche di prodotto e audit.

Entitlement, assegnazione, utilizzo ed enforcement

Un bilancio di licenze corretto considera quattro stati indipendenti:

1. Entitlement: quali diritti d’uso sono stati acquisiti con quale contratto, prodotto, metrica, scope, periodo e diritto speciale?
2. Deployment/assegnazione: su quali dispositivi, istanze, utenti, tenant o funzionalità il software è installato, attivato o assegnato?
3. Utilizzo: quali oggetti o funzioni rilevanti ai fini della licenza sono stati effettivamente utilizzati nel periodo di misurazione concordato?
4. Enforcement: quale limite viene verificato tecnicamente dal prodotto e come reagisce in caso di assenza di connessione, scadenza o superamento?

Un entitlement esistente non dimostra un’assegnazione corretta; un’assegnazione non dimostra l’utilizzo; un utilizzo ridotto non revoca automaticamente una licenza utente nominativa. Viceversa, un prodotto può continuare a funzionare tecnicamente anche se è scaduto un diritto di abbonamento o di supporto. Conformità e disponibilità tecnica sono quindi due obiettivi di controllo distinti.

ISO/IEC 19770-1 specifica i requisiti di un sistema di gestione degli asset IT. ISO/IEC 19770-2 standardizza i Software Identification Tags (SWID), che rendono identificabile il software, ma secondo la norma non prescrivono alcuna riconciliazione degli entitlement. ISO/IEC 19770-3 definisce termini e un formato di trasporto per entitlement e metriche associate. Nel loro insieme forniscono i livelli dati inventario, identità software e diritto d’uso, non un calcolo universale delle licenze (ISO/IEC 19770-1:2017, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Metriche di licenza: che cosa viene conteggiato?

Una metrica è interpretabile solo insieme al contratto completo:

L’unità tecnica non deve essere dedotta dal nome del prodotto. «Per core» può significare core fisici dell’host, vCPU della VM o una metrica core normalizzata. «Utente» può indicare una persona fisica, un account attivo, una casella di posta, un’identità con licenza o un mittente. «Istanza» può essere conteggiata in esecuzione, installata, registrata o per nodo di cluster. ISO/IEC 19770-3 standardizza una struttura di entitlement, ma non sostituisce la definizione concreta nei Product Terms e nell’ordine (ISO/IEC 19770-3:2016).

La sola metrica non indica ancora dove viene effettuato il conteggio. Solo il punto di conteggio tecnico spiega perché portale del produttore, inventario locale e valore di fatturazione possono differire.

Il punto di conteggio tecnico

Ogni metrica viene documentata come funzione di conteggio riproducibile:

Contatore = scope × ancoraggio dell’oggetto × filtro di stato × finestra temporale × regola di aggregazione × eccezioni

• Scope: organizzazione, tenant, dominio, cluster, subscription, sede o contratto.
• Ancoraggio dell’oggetto: ID utente immutabile, ID dispositivo, ID VM, seriale host, ID SKU o hash – non solo nome visualizzato.
• Filtro di stato: enabled, assigned, provisioned, active, seen, mounted, running o consumed.
• Finestra temporale: data di riferimento, mese di calendario, picco, media, finestra mobile o anno contrattuale.
• Aggregazione: distinct, somma, massimo, 95° percentile, pacchetto minimo o scaglione.
• Eccezioni: utenti esterni, account di sistema, istanza DR passiva, trial, NFR o caso d’uso contrattualmente gratuito.

Il punto di conteggio è spesso un punto di consegna. Un’importazione LDAP può conteggiare tutti gli account corrispondenti, anche se non utilizzano mai una funzione di posta. Un gateway può apprendere i mittenti dal traffico e quindi mantenere identità eliminate o tecniche. Una SKU cloud può essere assegnata direttamente o indirettamente tramite un gruppo. L’API licenseDetails di Microsoft Graph fornisce licenze dirette e ereditate dall’appartenenza a gruppi, nonché singoli piani di servizio e stati di provisioning; ciò mostra perché un booleano «ha licenza» non è sufficiente per l’analisi (Microsoft Graph – List licenseDetails).

Architettura di un sistema di licenze

I prodotti commerciali utilizzano implementazioni diverse, ma tecnicamente possono essere scomposti in superfici di controllo. Questo modello è una sintesi operativa dei livelli dati ISO/IEC 19770 e dei meccanismi documentati dai produttori, non un’architettura normativa universale:

Cisco Smart Licensing descrive una gestione centralizzata di account e licenze; Microsoft Graph espone SKU acquisite, assegnazioni e piani di servizio tramite API. Tali sistemi rendono le licenze una dipendenza distribuita da identità, servizio cloud, rete, TLS e tempo. Un prodotto può continuare a elaborare dati ma non riuscire a ottenere una nuova licenza; un altro può bloccare funzionalità dopo un periodo offline. Il comportamento concreto deve essere ricavato dalla documentazione del produttore e dal contratto (Cisco Licensing, Microsoft Graph – Get-MgSubscribedSku).

Licenze basate sull’identità

Per gli utenti nominativi, la directory fa parte del sistema di licenze. Un filtro corretto non risponde solo a «persone nell’OU X», ma anche a:

• quale attributo costituisce l’ancoraggio immutabile dell’oggetto;
• se vengono conteggiati account disattivati, bloccati, eliminati o non ancora sottoposti a provisioning;
• come vengono trattate caselle Shared/Resource, account di servizio, ospiti, partner esterni e account di test;
• se le assegnazioni dirette e basate su gruppi vengono consolidate;
• quando una licenza rimossa torna disponibile;
• se conta l’utilizzo storico o solo lo stato alla data di riferimento;
• quali attributi il prodotto memorizza localmente nella cache e quando li elimina.

LDAP fornisce voci e attributi, ma non una definizione universale di «persona con licenza». LDAP può implementare tecnicamente scope e filtro; la metrica deriva dal contratto. Lo stesso vale nelle directory cloud: SKU, piano di servizio, assignedLicenses, stato di provisioning e stato effettivo del workload sono dati distinti. Microsoft Graph documenta subscribedSku come subscription commerciale acquisita e licenseDetails per utente (Microsoft Graph – Get-MgSubscribedSku, Microsoft Graph – List licenseDetails).

La pulizia degli account orfani non deve essere guidata direttamente dalla pressione sulle licenze. Prima si verificano proprietari, conservazione, routing della posta, Legal Hold, dipendenze di servizio e ripristino; poi l’identità viene disattivata o eliminata in modo controllato. Un report di licenze è un input del ciclo di vita, non un ordine di eliminazione.

Modelli per istanze, core e capacità

Virtualizzazione e cluster rendono insufficiente il nome del server fisico. Un inventario richiede host, VM/container, vCPU assegnate, CPU/core fisici, cluster hypervisor, regole di mobilità, edizione e ruolo. Se una VM può spostarsi tra host, a seconda del contratto può essere rilevante l’intero scope possibile degli host; una rigida affinità CPU può essere dimostrabile tecnicamente, ma non è automaticamente riconosciuta dal contratto.

Le edizioni collegano il diritto d’uso ai limiti tecnici. Microsoft documenta per Exchange Server, ad esempio, edizioni che differiscono tra l’altro nel numero di database montati contemporaneamente; anche le copie passive del database possono essere conteggiate come database montati. Il Product Key imposta l’edizione del server. Questo è un esempio di come enforcement e architettura di capacità coincidano, non un calcolo generale delle licenze Exchange (Microsoft – Exchange Server Editions and Versions, Microsoft – Enter Exchange Product Key).

Le metriche di capacità richiedono una serie temporale. Un valore istantaneo non mostra né il picco mensile né un superamento di breve durata. Per la messaggistica, contatori tecnici diffusi sono in particolare caselle di posta attive, mittenti interni, domini, numero giornaliero di messaggi, throughput, storage e utenti cifrati; se siano rilevanti ai fini della licenza lo stabilisce esclusivamente il diritto di prodotto. I dashboard memorizzano pertanto valore grezzo, ora, scope, fonte e regola di calcolo anziché solo un semaforo.

Non appena vengono conteggiate istanze o identità, alta disponibilità, test e migrazioni incidono anche sulla quantità di licenze. I sistemi passivi non sono automaticamente gratuiti; fa fede il contratto specifico.

HA, Disaster Recovery, test e migrazione

Nodi passivi, Cold Standby, istanze di ripristino, laboratorio, test, formazione e funzionamento parallelo temporaneo durante una migrazione sono casi speciali tipici. Dal punto di vista tecnico «passivo» può comunque significare che il software è installato, viene elaborata la replica, sono montati database o viene effettuato il checkout di una licenza sul server. I termini contrattuali devono essere mappati su stati osservabili.

Per ogni caso speciale vengono documentati:

• numero consentito e definizione delle istanze passive/fredde;
• se sono inclusi test, qualificazione delle patch, ripristino di backup o test DR;
• per quanto tempo è consentito il funzionamento simultaneo vecchio/nuovo durante la migrazione;
• se una licenza è mobile e quali condizioni di riassegnazione/attesa si applicano;
• se i diritti cloud e on-premises sono collegati;
• quale evidenza distingue un vero caso DR da un carico produttivo continuativo;
• come funziona il servizio di licenza in una rete di ripristino isolata.

Il concetto di backup e DR include quindi anche file di licenza, dati di attivazione, server di licenza, token offline, certificati, ora, DNS/proxy e contatti del produttore. Un ripristino tecnicamente perfetto che non riesce ad attivare la propria edizione o le funzionalità necessarie non soddisfa l’obiettivo di recovery.

Scadenza, Grace Period e guasto del servizio di licenza

Nei modelli subscription, lease o cloud sono rilevanti almeno i seguenti timer: fine dell’entitlement, scadenza del token, heartbeat, durata di borrow/checkout, periodo offline, Grace Period e validità del certificato. La prospettiva amministrativa mantiene ora assoluta, fuso orario, fonte di sincronizzazione e ultimo rinnovo riuscito. Un orologio errato può causare una presunta scadenza della licenza o impedire la validazione di un token firmato.

Il comportamento alla scadenza dipende dal prodotto:

• solo avviso o evento di conformità;
• nessuna nuova assegnazione, l’utilizzo esistente resta;
• funzionalità premium disattivata o ritorno a un’edizione inferiore;
• numero limitato di nuove sessioni/utenti;
• funzionamento in sola lettura;
• interruzione completa del servizio;
• Grace Period locale se il servizio cloud non è raggiungibile.

Questa reazione viene determinata in un ambiente di test o tramite una fonte esplicita del produttore, non sperimentata nel flusso di produzione. Il monitoraggio avvisa prima del primo timer operativo, non solo della fine del contratto. Cisco documenta per Smart Licensing propri meccanismi online/offline e di account; altri produttori utilizzano server di licenza locali, file firmati, dongle USB, Product Key o entitlement SaaS (Cisco Licensing).

Open Source: diritto d’uso senza contatore tecnico

Open Source non significa semplicemente codice sorgente visibile. La Open Source Definition richiede, tra l’altro, libera ridistribuzione, accesso al codice sorgente, opere derivate e diritti tecnologicamente neutrali. Le singole licenze prevedono condizioni differenti per modifica, ridistribuzione, notices, messa a disposizione del codice sorgente o licenze di brevetto (Open Source Initiative – Open Source Definition).

La Apache License 2.0 concede licenze di copyright e brevetto a determinate condizioni e, in caso di ridistribuzione, richiede tra l’altro una copia della licenza, avvisi di modifica e il mantenimento di specifici notices. Un prezzo di download pari a zero non elimina tali obblighi (Apache License 2.0). Per combinazioni di componenti possono applicarsi più licenze contemporaneamente o in alternativa.

Le SPDX License Expressions modellano tali casi in modo leggibile dalla macchina: AND per obblighi cumulativi, OR per una scelta di licenza e WITH per un’eccezione. Un’espressione SPDX identifica la situazione di licenza dichiarata, ma non esegue alcuna verifica di compatibilità legale (SPDX Specification – License Expressions). Per gli amministratori, file di licenza e notice, SBOM/elenco dei componenti, canale di distribuzione e modifiche proprie devono rientrare nell’evidenza di rilascio e archiviazione.

Strumenti amministrativi per contatori riproducibili

Gli esempi mostrano interrogazioni tecniche di inventario e raccolta di evidenze. Se un campo sia rilevante ai fini della licenza deve essere dedotto dai Terms. Le esportazioni possono contenere dati personali e richiedono controllo degli accessi, conservazione e limitazione delle finalità.

Rilevare l’inventario di CPU, core e virtualizzazione

Get-CimInstance legge dati di inventario CIM/WMI; lscpu raccoglie dati di CPU, core, thread, socket e NUMA. In una VM mostrano principalmente la vista del guest. Scope dell’host, spostamento del cluster, tipo di istanza cloud e fattori core contrattuali vengono documentati separatamente.

Conteggiare oggetti della directory con scope esplicito

Get-ADUser e ldapsearch forniscono ancoraggi degli oggetti e attributi. Vengono documentati Search Base, filtro, paging, attributi multivalore e oggetti disattivati. L’esportazione non conta «persone soggette a licenza» finché la regola contrattuale non è mappata esattamente su questi campi.

Leggere SKU cloud e assegnazioni utenti

curl --fail --silent --show-error \
  --header "Authorization: Bearer $GRAPH_ACCESS_TOKEN" \
  'https://graph.microsoft.com/v1.0/subscribedSkus?$select=skuId,skuPartNumber,consumedUnits,prepaidUnits,capabilityStatus'

Get-MgSubscribedSku, Get-MgUserLicenseDetail e curl leggono dati Microsoft Graph. I token non vengono salvati in script, ticket o cronologia della shell. ConsumedUnits, assegnazione utenti, provisioning del piano di servizio e workload effettivamente utilizzato vengono valutati separatamente.

Verificare il server di licenza o endpoint cloud dalla rete del prodotto

Test-NetConnection e nc verificano la connessione DNS/TCP dall’origine scelta. Un esito positivo non dimostra né proxy, TLS, token, associazione dell’account né la transazione di licenza. I log del prodotto e lo stato del produttore forniscono la transizione di stato successiva.

Proteggere l’esportazione di audit dalle modifiche

Get-FileHash e sha256sum rilevano successive modifiche a livello di byte. Vengono inoltre documentati ora di creazione, scope della query, versione dello strumento/API, query, fuso orario, esportatore e archiviazione sicura. Un hash non conferma la completezza sostanziale.

Verificare gli eventi di licenza e attivazione nel periodo

Get-WinEvent, journalctl e grep filtrano eventi locali. I log del produttore possono utilizzare codici strutturati anziché messaggi testuali in inglese; sono preferibili provider, Event ID o campi definiti. Ora, rotazione e copia centralizzata dei log fanno parte del riscontro.

Da entitlement, punto di conteggio e stato operativo nasce l’evidenza di audit. Deve mostrare in modo riproducibile cosa è stato acquistato, assegnato, installato ed effettivamente utilizzato.

Evidenza di audit e operativa

Un’evidenza di licenza riproducibile contiene:

• riferimento del contratto/ordine, prodotto/SKU, metrica, quantità, scope, durata e diritti speciali;
• inventario software e hardware con ID immutabili, edizione, versione e relazione di cluster;
• assegnazioni dirette, basate su gruppi e automatiche con fonte e stato di provisioning;
• valori di misurazione grezzi e regola di calcolo per ciascuna finestra temporale;
• eccezioni con motivazione, owner, data di scadenza e controllo tecnico;
• HA/DR/test/migrazione come popolazione distinta;
• indicazione del prodotto, esportazione API/CLI e ricalcolo indipendente;
• ora, fuso orario, versione query/strumento, hash e archiviazione protetta.

Le discrepanze vengono classificate: errore dei dati (duplicati, vecchi account), errore del modello (metrica errata), errore di processo (licenza non rimossa dopo l’uscita), errore tecnico (sync/token/server) o entitlement mancante. Solo questa separazione mostra se la risposta sia pulizia, configurazione, chiarimento contrattuale, approvvigionamento o Incident Response.

Evoluzione tecnica delle licenze

Le chiavi prodotto locali e i dongle collegavano inizialmente strettamente il diritto d’uso a un computer. I server di licenza di rete hanno introdotto pool condivisi e lease concorrenti; la virtualizzazione ha richiesto nuove regole per host, core e mobilità. Abbonamenti e SaaS hanno spostato gli entitlement in account cloud, gruppi di identità e piani di servizio. Cisco Smart Licensing e Microsoft Graph illustrano modelli centralizzati basati su account/API, mentre ISO/IEC 19770 standardizza dati SWID e di entitlement (Cisco Licensing, Microsoft Graph – List licenseDetails, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Parallelamente, Open Source ha reso superflua l’attivazione tecnica per molti componenti, ma non le condizioni di licenza. SPDX ha creato identificatori brevi ed espressioni leggibili dalla macchina per le catene di fornitura software. Il compito dell’amministratore si è quindi spostato da «inserire una chiave» a un problema di dati relativo a contratto, identità, asset, durata, telemetria e composizione del software. L’approccio opposto è lo stesso del monitoraggio: ancoraggi chiari degli oggetti, finestre temporali esplicite, dati grezzi e calcoli riproducibili.

Fonti

• ISO/IEC 19770-3:2016 – Entitlement Schema
• ISO/IEC 19770-1:2017 – IT Asset Management Systems
• ISO/IEC 19770-2:2015 – Software Identification Tag
• Microsoft Graph – List licenseDetails
• Cisco – Licensing
• Microsoft Graph PowerShell – Get-MgSubscribedSku
• Microsoft – Exchange Server Editions and Versions
• Microsoft – Enter Exchange Server Product Key
• Open Source Initiative – Open Source Definition
• Apache Software Foundation – Apache License 2.0
• SPDX Specification 3.0.1 – License Expressions
• Microsoft Learn – Get-CimInstance
• Linux man-pages – lscpu
• Microsoft Learn – Get-ADUser
• OpenLDAP – ldapsearch
• Microsoft Graph PowerShell – Get-MgUserLicenseDetail
• curl – command line manpage
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc
• Microsoft Learn – Get-FileHash
• GNU Coreutils – SHA-2 utilities
• Microsoft Learn – Get-WinEvent
• systemd – journalctl
• GNU Grep – Manual