Lizenzierung: Nutzungsrechte, Metriken und technische Zählpunkte

Softwarelizenzierung verbindet einen rechtlichen Nutzungsvertrag mit technisch messbaren Objekten. Für Admins ist entscheidend, diese Ebenen nicht zu verwechseln. Ein Lizenzschlüssel, eine Cloudanzeige oder ein interner Benutzerzähler kann Funktionen aktivieren und Nutzung messen; er definiert aber nicht allein, was eine Organisation rechtlich verwenden darf. ISO/IEC 19770-3 behandelt digitale Entitlementdaten ausdrücklich als Abbildung von Nutzungsrechten und stellt klar, dass die ursprünglichen Lizenzbedingungen für rechtliche Zwecke Vorrang haben (ISO/IEC 19770-3:2016).

Die operative Aufgabe lautet deshalb: erworbene Rechte, technisch installierte oder zugewiesene Rechte und tatsächliche Nutzung reproduzierbar abgleichen. Abweichungen können Übernutzung, ungenutzte Kosten, falsche Verzeichnisfilter, verwaiste Konten, passive Clusterknoten, abgelaufene Token oder schlicht unterschiedliche Definitionen desselben Wortes «Benutzer» sein. Der Artikel beschreibt die technische Sicht; Vertrags- und Rechtsauslegung bleibt bei Einkauf, Lizenzmanagement und Rechtsberatung.

Die Erklärung beginnt beim vertraglichen Nutzungsrecht und verfolgt, wie Produkt, Metrik und technischer Zählpunkt daraus einen gemessenen Verbrauch machen. Danach folgen Zuweisung, Enforcement, Audit, Sonderfälle und Wiederherstellung.

Eine Lizenz ist zunächst ein Nutzungsrecht; technisch sichtbar wird sie erst durch Zuweisung, gemessene Nutzung und gegebenenfalls Enforcement. Der Artikel trennt diese vier Ebenen, bevor er Produktmetriken und Audits behandelt.

Entitlement, Zuweisung, Nutzung und Enforcement

Eine saubere Lizenzbilanz hält vier voneinander unabhängige Zustände:

1. Entitlement: Welche Nutzungsrechte wurden mit welchem Vertrag, Produkt, Metrik, Scope, Zeitraum und Sonderrecht erworben?
2. Deployment/Zuweisung: Auf welchen Geräten, Instanzen, Benutzern, Tenants oder Features ist Software installiert, aktiviert oder zugeordnet?
3. Nutzung: Welche lizenzrelevanten Objekte oder Funktionen wurden im vereinbarten Messzeitraum tatsächlich verwendet?
4. Enforcement: Welche Grenze prüft das Produkt technisch, und wie reagiert es bei fehlender Verbindung, Ablauf oder Überschreitung?

Ein vorhandenes Entitlement beweist keine korrekte Zuweisung; eine Zuweisung beweist keine Nutzung; geringe Nutzung hebt eine benannte Benutzerlizenz nicht automatisch auf. Umgekehrt kann ein Produkt technisch weiterlaufen, obwohl ein Subscription- oder Supportrecht abgelaufen ist. Compliance und technische Verfügbarkeit sind daher zwei verschiedene Kontrollziele.

ISO/IEC 19770-1 spezifiziert Anforderungen an ein IT-Asset-Management-System. ISO/IEC 19770-2 standardisiert Software Identification Tags (SWID), die Software identifizierbar machen, aber laut Norm keine Entitlement-Reconciliation vorschreiben. ISO/IEC 19770-3 definiert Begriffe und ein Transportformat für Entitlements und zugehörige Metriken. Zusammengenommen liefern sie die Datenebenen Inventar, Softwareidentität und Nutzungsrecht, nicht eine universelle Lizenzberechnung (ISO/IEC 19770-1:2017, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Lizenzmetriken: Was wird gezählt?

Eine Metrik ist nur mit ihrem vollständigen Vertrag interpretierbar:

Die technische Einheit darf nicht aus dem Produktnamen geraten werden. «Pro Core» kann physische Cores des Hosts, vCPUs der VM oder eine normalisierte Core-Metrik bedeuten. «Benutzer» kann natürliche Person, aktives Konto, Mailbox, lizenzierte Identität oder sendender Absender sein. «Instanz» kann laufend, installiert, registriert oder je Clusterknoten zählen. ISO/IEC 19770-3 standardisiert eine Entitlementstruktur, ersetzt aber nicht die konkrete Definition in Product Terms und Bestellung (ISO/IEC 19770-3:2016).

Die Metrik allein sagt noch nicht, wo gezählt wird. Erst der technische Zählpunkt erklärt, weshalb Herstellerportal, lokales Inventar und Rechnungswert voneinander abweichen können.

Der technische Zählpunkt

Jede Metrik wird als reproduzierbare Zählfunktion dokumentiert:

Zähler = Scope × Objektanker × Statusfilter × Zeitfenster × Aggregationsregel × Ausnahmen

• Scope: Organisation, Tenant, Domain, Cluster, Subscription, Standort oder Vertrag.
• Objektanker: unveränderliche User-ID, Device-ID, VM-ID, Hostserial, SKU-ID oder Hash – nicht nur Anzeigename.
• Statusfilter: enabled, assigned, provisioned, active, seen, mounted, running oder consumed.
• Zeitfenster: Stichtag, Kalendermonat, Peak, Durchschnitt, rollierendes Fenster oder Vertragsjahr.
• Aggregation: Distinct, Summe, Maximum, 95. Perzentil, Mindestpaket oder Staffel.
• Ausnahmen: externe Benutzer, Systemkonten, passive DR-Instanz, Trial, NFR oder vertraglich freier Use Case.

Der Zählpunkt ist oft ein Übergabepunkt. Ein LDAP-Import kann alle passenden Konten zählen, auch wenn sie nie eine Mailfunktion nutzen. Ein Gateway kann Absender aus dem Verkehr lernen und dadurch gelöschte oder technische Identitäten halten. Eine Cloud-SKU kann direkt oder transitiv über eine Gruppe zugewiesen sein. Microsoft Graphs licenseDetails-API liefert direkte und über Gruppenmitgliedschaft geerbte Lizenzen sowie einzelne Servicepläne und Provisioningstatus; das zeigt, warum ein Boolean «hat Lizenz» für die Analyse nicht genügt (Microsoft Graph – List licenseDetails).

Architektur eines Lizenzsystems

Kommerzielle Produkte verwenden unterschiedliche Implementierungen, lassen sich technisch aber in Kontrollflächen zerlegen. Dieses Modell ist eine betriebliche Synthese aus ISO/IEC-19770-Datenebenen und dokumentierten Herstellermechanismen, keine universelle Normarchitektur:

Cisco Smart Licensing beschreibt ein zentralisiertes Account- und Lizenzmanagement; Microsoft Graph exponiert erworbene SKUs, Zuweisungen und Servicepläne über APIs. Solche Systeme machen Lizenzierung zu einer verteilten Abhängigkeit aus Identität, Cloudservice, Netzwerk, TLS und Zeit. Ein Produkt kann weiterhin Daten verarbeiten, aber keine neue Lizenz beziehen; ein anderes kann nach einer Offlinefrist Features sperren. Das konkrete Verhalten muss aus Herstellerdokumentation und Vertrag übernommen werden (Cisco Licensing, Microsoft Graph – Get-MgSubscribedSku).

Identitätsbasierte Lizenzierung

Bei benannten Benutzern ist das Verzeichnis Teil des Lizenzsystems. Ein korrekter Filter beantwortet nicht nur «Personen in OU X», sondern:

• welches Attribut den unveränderlichen Objektanker bildet;
• ob deaktivierte, gesperrte, gelöschte oder noch nicht provisionierte Konten zählen;
• wie Shared/Resource Mailboxes, Servicekonten, Gäste, externe Partner und Testkonten behandelt werden;
• ob direkte und gruppenbasierte Zuweisungen zusammengeführt werden;
• wann eine entfernte Lizenz wieder verfügbar ist;
• ob historische Nutzung oder nur der Stichtagsbestand massgeblich ist;
• welche Attribute das Produkt lokal cached und wann es sie löscht.

LDAP liefert Einträge und Attribute, aber keine universelle Definition «lizenzierter Mensch». LDAP kann Scope und Filter technisch umsetzen; die Metrik kommt aus dem Vertrag. In Cloudverzeichnissen gilt dasselbe: SKU, Serviceplan, assignedLicenses, Provisioningstatus und tatsächlicher Workloadzustand sind unterschiedliche Daten. Microsoft Graph dokumentiert subscribedSku als erworbene kommerzielle Subscription und licenseDetails je Benutzer (Microsoft Graph – Get-MgSubscribedSku, Microsoft Graph – List licenseDetails).

Die Bereinigung verwaister Konten darf nicht direkt am Lizenzdruck orientiert werden. Zuerst werden Eigentümer, Aufbewahrung, Mailrouting, Legal Hold, Serviceabhängigkeiten und Recovery geprüft; danach wird die Identität kontrolliert deaktiviert oder gelöscht. Ein Lizenzreport ist ein Input in den Lifecycle, kein Löschauftrag.

Instanz-, Core- und Kapazitätsmodelle

Virtualisierung und Cluster machen den physischen Servernamen unzureichend. Ein Inventar benötigt Host, VM/Container, zugewiesene vCPU, physische CPU/Core, Hypervisorcluster, Mobilitätsregeln, Edition und Rolle. Wenn eine VM zwischen Hosts bewegen kann, kann je Vertrag der gesamte mögliche Hostscope relevant sein; eine harte CPU-Affinität kann technisch nachweisbar sein, ist aber nicht automatisch vertraglich anerkannt.

Editionen verbinden Nutzungsrecht mit technischen Limits. Microsoft dokumentiert bei Exchange Server beispielsweise Editionen, die sich unter anderem in der Anzahl gleichzeitig gemounteter Datenbanken unterscheiden; passive Datenbankkopien können dabei ebenfalls als gemountete Datenbanken zählen. Der Product Key setzt die Serveredition. Das ist ein Beispiel dafür, wie Enforcement und Kapazitätsarchitektur zusammenfallen, nicht eine allgemeine Exchange-Lizenzberechnung (Microsoft – Exchange Server Editions and Versions, Microsoft – Enter Exchange Product Key).

Kapazitätsmetriken benötigen einen Zeitverlauf. Ein momentaner Wert zeigt weder Monatspeak noch kurzzeitige Überziehung. Für Messaging sind insbesondere aktive Mailboxen, interne Absender, Domains, tägliche Nachrichtenzahl, Throughput, Speicher und verschlüsselte Benutzer verbreitete technische Zähler – ob sie lizenzrelevant sind, legt nur das Produktrecht fest. Dashboards speichern daher Rohwert, Zeit, Scope, Quelle und Berechnungsregel statt nur eine Ampel.

Sobald Instanzen oder Identitäten gezählt werden, betreffen Hochverfügbarkeit, Tests und Migrationen auch die Lizenzmenge. Passive Systeme sind nicht automatisch kostenfrei; massgeblich ist der jeweilige Vertrag.

HA, Disaster Recovery, Test und Migration

Passive Knoten, Cold Standby, Recoveryinstanzen, Lab, Test, Schulung und zeitweilige Parallelstände während einer Migration sind typische Sonderfälle. Technisch «passiv» kann trotzdem bedeuten, dass Software installiert ist, Replikation verarbeitet, Datenbanken gemountet oder eine Lizenz beim Server ausgecheckt wird. Die Vertragsbegriffe müssen auf beobachtbare Zustände abgebildet werden.

Für jeden Sonderfall werden dokumentiert:

• erlaubte Anzahl und Definition passiver/kalter Instanzen;
• ob Test, Patchqualifikation, Backuprestore oder DR-Test eingeschlossen ist;
• wie lange gleichzeitiger Alt-/Neubetrieb bei Migration erlaubt ist;
• ob eine Lizenz mobil ist und welche Reassignment-/Wartebedingungen gelten;
• ob Cloud- und On-premises-Rechte gekoppelt sind;
• welcher Beleg einen echten DR-Fall von produktiver Dauerlast unterscheidet;
• wie der Lizenzdienst in einem isolierten Recoverynetz funktioniert.

Das Backup-und-DR-Konzept enthält deshalb auch Lizenzdateien, Aktivierungsdaten, Lizenzserver, Offline-Token, Zertifikate, Uhrzeit, DNS/Proxy und Herstellerkontakte. Ein technisch perfekter Restore, der seine Edition oder benötigte Features nicht aktivieren kann, erfüllt das Recovery-Ziel nicht.

Ablauf, Grace Period und Ausfall des Lizenzdienstes

Bei Subscription-, Lease- oder Cloudmodellen sind mindestens folgende Timer relevant: Entitlementende, Tokenablauf, Heartbeat, Borrow-/Checkout-Dauer, Offlinefrist, Grace Period und Zertifikatsgültigkeit. Die Adminsicht hält absolute Zeit, Zeitzone, Synchronisationsquelle und zuletzt erfolgreiche Erneuerung. Eine falsche Uhr kann einen scheinbaren Lizenzablauf auslösen oder die Validierung eines signierten Tokens verhindern.

Das Verhalten bei Ablauf ist produktspezifisch:

• nur Warnung oder Complianceevent;
• keine neue Zuweisung, bestehende Nutzung bleibt;
• deaktiviertes Premiumfeature oder Rückfall auf kleinere Edition;
• begrenzte Anzahl neuer Sessions/Benutzer;
• Read-only-Betrieb;
• vollständiger Serviceunterbruch;
• lokale Grace Period bei nicht erreichbarem Cloudservice.

Diese Reaktion wird in einer Testumgebung oder anhand einer expliziten Herstellerquelle ermittelt, nicht im Produktionsablauf ausprobiert. Monitoring warnt vor dem frühesten betrieblichen Timer, nicht erst vor dem Vertragsende. Cisco dokumentiert für Smart Licensing eigene Online-/Offline- und Accountmechanismen; andere Hersteller verwenden lokale Lizenzserver, signierte Dateien, USB-Dongles, Produktkeys oder SaaS-Entitlements (Cisco Licensing).

Open Source: Nutzungsrecht ohne technischen Zähler

Open Source bedeutet nicht bloss sichtbaren Quellcode. Die Open Source Definition verlangt unter anderem freie Weitergabe, Quellcodezugang, abgeleitete Werke und technologie-neutrale Rechte. Einzelne Lizenzen stellen dabei unterschiedliche Bedingungen für Änderung, Weitergabe, Notices, Quellcodebereitstellung oder Patentlizenzen (Open Source Initiative – Open Source Definition).

Die Apache License 2.0 gewährt Copyright- und Patentlizenzen unter Bedingungen und verlangt bei Weitergabe unter anderem Lizenzkopie, Änderungsvermerke und Erhalt bestimmter Notices. Ein Downloadpreis von null beseitigt diese Pflichten nicht (Apache License 2.0). Bei Komponentenverbünden können mehrere Lizenzen gleichzeitig oder alternativ gelten.

SPDX License Expressions modellieren solche Fälle maschinenlesbar: AND für kumulative Pflichten, OR für eine Lizenzwahl und WITH für eine Exception. Ein SPDX-Ausdruck identifiziert die erklärte Lizenzsituation, führt aber keine rechtliche Kompatibilitätsprüfung durch (SPDX Specification – License Expressions). Für Admins gehören Lizenz- und Notice-Dateien, SBOM/Komponentenliste, Distributionsweg und eigene Änderungen in den Release- und Archivnachweis.

Admin-Werkzeuge für reproduzierbare Zähler

Die Beispiele zeigen technische Inventar- und Belegabfragen. Ob ein Feld lizenzrelevant ist, muss aus den Terms abgeleitet werden. Exporte können personenbezogene Daten enthalten und benötigen Zugriffsschutz, Aufbewahrung und Zweckbindung.

CPU-, Core- und Virtualisierungsinventar erfassen

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name,Manufacturer,Model,NumberOfProcessors,NumberOfLogicalProcessors,HypervisorPresent
Get-CimInstance Win32_Processor |
  Select-Object DeviceID,Name,SocketDesignation,NumberOfCores,NumberOfLogicalProcessors

lscpu --extended=CPU,NODE,SOCKET,CORE,ONLINE
lscpu

Get-CimInstance liest CIM/WMI-Inventardaten; lscpu sammelt CPU-, Core-, Thread-, Socket- und NUMA-Daten. In einer VM zeigen sie primär die Gastsicht. Hostscope, Clusterbewegung, Cloudinstanztyp und vertragliche Corefaktoren werden separat belegt.

Verzeichnisobjekte mit explizitem Scope zählen

Get-ADUser -SearchBase 'OU=Licensed,DC=example,DC=ch' -Filter * \
  -Properties ObjectGUID,Enabled,mail,employeeType |
  Select-Object ObjectGUID,SamAccountName,Enabled,mail,employeeType |
  Export-Csv .\\licensed-users.csv -NoTypeInformation -Encoding UTF8

ldapsearch -LLL -x -H ldaps://directory.example.ch \
  -b 'ou=Licensed,dc=example,dc=ch' \
  '(&(objectClass=person)(mail=*))' entryUUID uid mail employeeType

Get-ADUser und ldapsearch liefern Objektanker und Attribute. Search Base, Filter, Paging, Mehrwertattribute und deaktivierte Objekte werden dokumentiert. Der Export zählt keine «lizenzpflichtigen Personen», solange die Vertragsregel nicht exakt auf diese Felder abgebildet ist.

Cloud-SKUs und Benutzerzuweisungen auslesen

Get-MgSubscribedSku -All |
  Select-Object SkuId,SkuPartNumber,ConsumedUnits,PrepaidUnits,CapabilityStatus
Get-MgUserLicenseDetail -UserId 'admin@example.ch' |
  Select-Object SkuId,SkuPartNumber,ServicePlans

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 und curl lesen Microsoft-Graph-Daten. Tokens werden nicht in Skripten, Tickets oder Shell-History gespeichert. ConsumedUnits, Benutzerzuweisung, Serviceplan-Provisioning und tatsächlich genutzter Workload werden getrennt ausgewertet.

Lizenzserver oder Cloudendpunkt vom Produktnetz prüfen

Test-NetConnection license.example.ch -Port 443 -InformationLevel Detailed

nc -vz -w 5 license.example.ch 443

Test-NetConnection und nc prüfen DNS-/TCP-Aufbau vom gewählten Ursprung. Ein Erfolg belegt weder Proxy, TLS, Token, Accountzuordnung noch die Lizenztransaktion. Produktlogs und Herstellerstatus liefern den nächsten Zustandsübergang.

Auditexport gegen Veränderung sichern

Get-FileHash .\\evidence\\license-inventory.csv -Algorithm SHA256
Get-FileHash .\\evidence\\entitlements.pdf -Algorithm SHA256

sha256sum ./evidence/license-inventory.csv
sha256sum ./evidence/entitlements.pdf

Get-FileHash und sha256sum erkennen spätere Byteänderungen. Zusätzlich werden Erstellzeit, Abfragescope, Tool-/API-Version, Query, Zeitzone, Exporteur und sichere Ablage dokumentiert. Ein Hash bestätigt keine fachliche Vollständigkeit.

Lizenz- und Aktivierungsereignisse im Zeitraum prüfen

$since = [datetime]'2026-08-01T00:00:00Z'
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=$since} |
  Where-Object Message -Match 'licen[cs]e|activation|entitlement' |
  Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message

journalctl --since '2026-08-01 00:00:00 UTC' \
  --output short-iso-precise --no-pager \
  | grep -Ei 'licen[cs]e|activation|entitlement'

Get-WinEvent, journalctl und grep filtern lokale Ereignisse. Herstellerlogs können strukturierte Codes statt englischer Textmeldungen verwenden; bevorzugt werden Provider, Event-ID oder definierte Felder. Zeit, Rotation und zentrale Logkopie gehören in den Befund.

Aus Entitlement, Zählpunkt und Betriebszustand entsteht der Auditnachweis. Er muss reproduzierbar zeigen, was gekauft, zugewiesen, installiert und tatsächlich genutzt wurde.

Audit- und Betriebsnachweis

Ein reproduzierbarer Lizenznachweis enthält:

• Vertrags-/Bestellreferenz, Produkt/SKU, Metrik, Menge, Scope, Laufzeit und Sonderrechte;
• Software- und Hardwareinventar mit unveränderlichen IDs, Edition, Version und Clusterbeziehung;
• direkte, gruppenbasierte und automatische Zuweisungen mit Quelle und Provisioningstatus;
• Rohmesswerte und Berechnungsregel je Zeitfenster;
• Ausnahmen mit Begründung, Owner, Ablaufdatum und technischer Kontrolle;
• HA/DR/Test/Migration als eigene Population;
• Produktanzeige, API-/CLI-Export und unabhängige Gegenrechnung;
• Zeit, Zeitzone, Query/Toolversion, Hash und geschützte Ablage.

Abweichungen werden klassifiziert: Datenfehler (Dubletten, alte Konten), Modellfehler (falsche Metrik), Prozessfehler (Lizenz nach Austritt nicht entfernt), technischer Fehler (Sync/Token/Server) oder fehlendes Entitlement. Erst diese Trennung zeigt, ob die Antwort Bereinigung, Konfiguration, Vertragsklärung, Beschaffung oder Incident Response ist.

Technische Entwicklung der Lizenzierung

Lokale Produktkeys und Dongles verbanden Nutzungsrecht zunächst eng mit einem Rechner. Netzwerk-Lizenzserver führten gemeinsam genutzte Pools und Concurrent Leases ein; Virtualisierung erforderte neue Host-, Core- und Mobilitätsregeln. Abonnements und SaaS verlagerten Entitlements in Cloudaccounts, Identitätsgruppen und Servicepläne. Cisco Smart Licensing und Microsoft Graph illustrieren zentrale Account-/API-Modelle, während ISO/IEC 19770 SWID- und Entitlementdaten standardisiert (Cisco Licensing, Microsoft Graph – List licenseDetails, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Parallel machte Open Source technische Aktivierung für viele Komponenten überflüssig, nicht aber Lizenzbedingungen. SPDX schuf maschinenlesbare Kurzkennungen und Ausdrücke für Softwarelieferketten. Damit verschob sich die Adminaufgabe von «Key eintragen» zu einem Datenproblem über Vertrag, Identität, Asset, Laufzeit, Telemetrie und Softwarezusammensetzung. Der Gegenentwurf ist derselbe wie bei Monitoring: klare Objektanker, explizite Zeitfenster, Rohdaten und reproduzierbare Berechnungen.