Lizenzen und Nutzungsrechte für Rechtsverbindlichkeiten und den Schutz geistigen Eigentums

Eine Softwarelizenz ist die rechtliche Vereinbarung, die die Bindung zwischen Entwickler und Endnutzer begründet und festlegt, was der Nutzer mit der Software tun darf und zu welchen Bedingungen. Eine Berechtigung ist die operative Durchsetzung dieser Lizenz und regelt, welche spezifischen Nutzer, Geräte oder Systeme diese Rechte ausüben dürfen. In Kryptografie- und PKI-Umgebungen müssen beide aktiv verwaltet werden, um geistiges Eigentum zu schützen, die Einhaltung von Auditvorgaben zu gewährleisten und die unbefugte Nutzung sensibler Software und kryptografischer Funktionen zu verhindern.

Kurzantwort: Was sind Softwarelizenzen und Nutzungsrechte?

Eine Softwarelizenz ist der Rechtsvertrag, der das Nutzungsrecht an Software regelt und zulässige Nutzungen, Einschränkungen, Gewährleistungen und den Schutz geistigen Eigentums definiert. Eine Berechtigung ist die nachgelagerte Durchsetzungsebene, die festlegt, welche Benutzer oder Geräte unter dieser Lizenz Zugriff erhalten. Die Lizenz definiert, was erlaubt ist; die Berechtigung definiert, wer sie erhält und überwacht die Nutzung im Rahmen des vertraglich vereinbarten Umfangs.

Wichtige Erkenntnisse

• Eine Softwarelizenz ist ein rechtsverbindliches Dokument, das Rechte, Einschränkungen, Gewährleistungen und den Schutz geistigen Eigentums zwischen Entwickler und Endnutzer festlegt. Eine Berechtigung ist die operative Ebene, die diese Rechte gegenüber bestimmten Nutzern, Geräten oder Systemen durchsetzt und nachverfolgt.
• Die fünf Hauptlizenztypen reichen von der freizügigsten (Public Domain) bis zur restriktivsten (Proprietary): Public Domain, LGPL, freizügig (MIT/Apache), Copyleft (GPL) und Proprietary.
• Endbenutzer-Lizenzverträge (EULAs) werden über den Einzelhandel und App-Stores vertrieben; Software-Lizenzverträge (SLAs) werden direkt zwischen Entwickler und Organisation ausgehandelt und beinhalten Bestimmungen zu Lizenzanzahl, Prüfrechten und Haftungsbeschränkungen.
• Floating-Lizenzen ermöglichen die gleichzeitige Nutzung in einem Netzwerk; gerätegebundene Lizenzen sind an ein bestimmtes Gerät gebunden. Diese Unterscheidung ist relevant für Compliance-Audits und für kryptografische Software, die an spezifische Hardware wie HSMs gebunden ist.
• In PKI- und Kryptografieumgebungen umfasst das Berechtigungsmanagement die Kontrolle darüber, welche Systeme Zertifikate anfordern, auf HSM-Partitionen zugreifen oder Schlüsselverwaltungsoperationen durchführen dürfen. Lücken im Berechtigungsmanagement dieser Umgebungen bergen Risiken für Audits und unautorisierte kryptografische Operationen.
• Code-Signaturzertifikate sind ein kryptografischer Mechanismus zur Durchsetzung des Schutzes geistigen Eigentums von Software, indem eine überprüfbare Verbindung zwischen einer Binärdatei und der Identität ihres Entwicklers hergestellt wird.

Was ist eine Softwarelizenz und warum begründet sie rechtliche Bindungen?

Eine Softwarelizenz ist ein Rechtsinstrument, das einem Nutzer oder einer Organisation das Recht einräumt, Software gemäß den vom Softwareentwickler oder Urheberrechtsinhaber festgelegten Bedingungen zu nutzen. Ohne Lizenz stellt die Nutzung von Software potenziell eine Urheberrechtsverletzung gemäß geltendem Recht dar. Die Lizenz schafft die rechtliche Bindung, die das Verhältnis zwischen den Rechten des Entwicklers am geistigen Eigentum und der zulässigen Nutzung durch den Nutzer definiert.

Nach Angaben der Open Source Initiative sind Open-Source-Lizenzen solche, die der Open-Source-Definition entsprechen: Sie erlauben die freie Nutzung, Modifizierung und Weitergabe der Software und müssen den Lizenzprüfungsprozess der OSI bestehen, um das OSI-Gütesiegel tragen zu dürfen.

Kommerzielle Softwarelizenzen funktionieren anders: Sie beschränken die Nutzung auf die vom Entwickler festgelegten Bedingungen. Diese umfassen typischerweise die Anzahl der zulässigen Nutzer oder Geräte, die zulässigen Anwendungsfälle (Entwicklung, Produktion, Test), geografische Beschränkungen und die Lizenzdauer. Diese Bedingungen sind rechtsverbindlich, da die Software auch nach dem Erwerb der Lizenz durch den Endnutzer geistiges Eigentum des Entwicklers bleibt.

Insbesondere bei kryptografischer Software kommt Lizenzen oft eine besondere Bedeutung zu: Eine Lizenzvereinbarung kann die Nutzung von Verschlüsselungsfunktionen auf Länder beschränken, in denen der Export der kryptografischen Algorithmen legal ist, die Verwendung der Software ausschließlich mit FIPS-validierten Modulen vorschreiben oder festlegen, dass das von der Software generierte private Schlüsselmaterial Eigentum der Organisation und nicht des Entwicklers bleibt. Diese Bestimmungen haben direkten Einfluss darauf, wie Organisationen ihre Schlüsselverwaltungs- und Zertifizierungsrichtlinien gestalten.

Wie hat sich die Softwarelizenzierung zu ihrer heutigen Form entwickelt?

Die Softwarelizenzierung als eigenständige Disziplin entwickelte sich in den 1980er-Jahren parallel zum Wachstum vernetzter Computersysteme. Frühe kommerzielle Software wurde als gerätegebundenes Produkt verkauft: eine Lizenz pro physischem Rechner. Da die Kosten für die Entwicklung von Unternehmensanwendungen (EAD) Zehntausende, mitunter sogar Hunderttausende von Dollar pro Lizenz betrugen, benötigten Unternehmen ein flexibleres Modell.

Mit der zunehmenden Verbreitung vernetzter Engineering-Workstations Ende der 1980er-Jahre wurde das Floating-Lizenzmanagement praktikabel. Anstatt jede Lizenz an ein bestimmtes Gerät zu binden, ermöglichten Floating-Lizenzen die gemeinsame Nutzung eines Lizenzpools im Netzwerk, wobei ein Lizenzserver die Anzahl der gleichzeitigen Nutzungen verwaltete. Dieses Modell senkte die Gesamtbetriebskosten für Organisationen mit vielen Nutzern, die nicht alle gleichzeitig Zugriff benötigten, erheblich.

Der Wechsel zu SaaS-Abonnementmodellen (Software as a Service) in den 2000er- und 2010er-Jahren veränderte das Berechtigungsmanagement grundlegend. Anstatt Lizenzdateien auf physischen Servern zu verwalten, wurden Berechtigungen kontobasiert und an Benutzeridentitäten gebunden, die über Identitätsanbieter verwaltet werden. Diese Entwicklung schuf sowohl neue Flexibilität als auch neue Herausforderungen im Bereich Compliance: Unternehmen konnten zwar problemlos Benutzerlizenzen bereitstellen, aber ohne systematische Prüfprozesse auch leicht mehr Lizenzen vergeben, als vertraglich vereinbart waren.

Welche zwei Hauptklassen von Softwarelizenzen gibt es?

Alle Softwarelizenzen lassen sich in eine von zwei grundlegenden Klassen einteilen, je nachdem, wie sie den Zugriff auf den Quellcode und die Rechte nachfolgender Nutzer regeln:

Lizenzklasse	Zugriff auf den Quellcode	Änderungsrechte	Vertriebsrechte	Reverse engineering
Proprietäre Software	Wird den Lizenznehmern nicht zur Verfügung gestellt. Der Quellcode ist ein Geschäftsgeheimnis des Entwicklers.	Nicht gestattet. Der Lizenznehmer erhält lediglich die kompilierte Binärdatei.	Eingeschränkt. Für die Weiterverbreitung ist in der Regel eine separate Vertriebslizenz des Entwicklers erforderlich.	Verboten. Lizenzvereinbarungen untersagen ausdrücklich das Reverse Engineering, um geistiges Eigentum zu schützen.
Freie und Open-Source-Software (FOSS)	Bereitgestellt. Lizenznehmer können den Quellcode lesen, prüfen und studieren.	Zulässig im Rahmen der Bedingungen der jeweiligen Open-Source-Lizenz.	Die Weitergabe ist im Rahmen der Bestimmungen der jeweiligen Lizenz zulässig. Copyleft-Lizenzen erfordern die Weiterverbreitung unter denselben Lizenzbedingungen.	Keine Einschränkungen. Der Quellcode ist frei verfügbar, wodurch Reverse Engineering überflüssig wird.

Welche fünf Hauptarten von Softwarelizenzen gibt es?

Softwarelizenzen werden üblicherweise nach verschiedenen Lizenztypen kategorisiert, von den am wenigsten bis zu den am stärksten restriktiven Lizenzen hinsichtlich der Nutzungsmöglichkeiten für Endnutzer und Entwickler. Die fünf Haupttypen sind:

Lizenztyp	Schlüsseleigenschaften	Pflichten von Nutzern und Entwicklern	Allgemeine Beispiele	Relevant für die Kryptographie
Public domain	Es werden keine Urheberrechte behalten. Die Software wird ohne jegliche Einschränkungen an die Öffentlichkeit freigegeben.	Keine. Nutzer und Entwickler dürfen die Software ohne Nennung des Urhebers oder Offenlegungspflicht verwenden, modifizieren, weiterverbreiten und in eigene Werke integrieren.	CC0, Lizenzfrei	Einige kryptografische Referenzimplementierungen und Testvektoren werden von Normungsorganisationen öffentlich zugänglich gemacht. Für den Entwickler besteht kein Schutz geistigen Eigentums.
Lizenz für die Allgemeinheit (LGPL)	Eine abgeschwächte Form des Copyleft, speziell für Bibliotheken entwickelt. Entwickler können LGPL-Bibliotheken in ihre Software einbinden, ohne dass die Copyleft-Bestimmungen auf ihren eigenen Code übertragen werden.	Entwickler müssen den Quellcode der Änderungen an der LGPL-Bibliothek selbst veröffentlichen, ihr eigener Anwendungscode kann jedoch proprietär bleiben. Benutzern muss es ermöglicht werden, eine modifizierte Version der Bibliothek erneut zu verlinken.	GNU LGPL v2.1, GNU LGPL v3	Manche kryptografische Bibliotheken verwenden die LGPL, um die Einbindung in kommerzielle Anwendungen zu ermöglichen und gleichzeitig die Bibliothek selbst als Open Source zu erhalten. Organisationen sollten die LGPL-Konformität überprüfen, bevor sie Produkte vertreiben, die LGPL-lizenzierte kryptografische Bibliotheken enthalten.
Freizügig (Open Source)	Ermöglicht die Nutzung, Änderung und Verbreitung in proprietärer oder Open-Source-Software mit minimalen Anforderungen, typischerweise nur der Nennung des Urhebers.	Namensnennung: Der ursprüngliche Urheberrechtshinweis und der Lizenztext müssen in den Verbreitungsmaterialien enthalten sein. Kein Copyleft: Abgeleitete Werke können unter beliebigen Bedingungen, einschließlich proprietärer Lizenzen, lizenziert werden.	MIT, Apache 2.0, BSD 2-Klausel, BSD 3-Klausel	Die Apache-2.0-Lizenz gilt für viele weit verbreitete kryptografische Bibliotheken und Werkzeuge. Sie beinhaltet eine explizite Patentgewährung, die für kryptografische Algorithmen relevant ist, die Patentansprüchen unterliegen. OpenSSL verwendet eine spezielle, freizügige Lizenz.
Copyleft (stark)	Verlangt, dass jegliche Software, die den unter der Copyleft-Lizenz stehenden Code enthält oder davon abgeleitet ist, unter denselben Lizenzbedingungen verbreitet wird. Oft als „virale“ Lizenzierung bezeichnet.	Wenn Sie Software vertreiben, die GPL-Code enthält, müssen Sie den vollständigen Quellcode des gesamten Werks unter der GPL zur Verfügung stellen. Dies verhindert wirksam die Einbindung von GPL-Code in proprietäre Software.	GNU GPL v2, GNU GPL v3, AGPL v3	Organisationen, die GPL-Kryptografiebibliotheken in kommerzielle Produkte integrieren, müssen Vorsicht walten lassen: Die GPL kann die Veröffentlichung des gesamten Produkts als Open Source erfordern. Vor der Integration von GPL-Kryptografiecode in proprietäre Software ist eine rechtliche Prüfung erforderlich.
Proprietäre	Der Entwickler behält alle Rechte. Endnutzer erhalten lediglich das Recht, die kompilierte Software gemäß den spezifischen Bedingungen der Lizenzvereinbarung zu nutzen.	Die Nutzer dürfen die Software weder verändern, weiterverbreiten, zurückentwickeln noch über die Lizenzbedingungen hinaus nutzen. Lizenzvereinbarungen legen üblicherweise die Anzahl der Lizenzen, zulässige Anwendungsfälle und geografische Beschränkungen fest.	Kommerzielle Softwarelizenzen von großen Anbietern	Die meisten kommerziellen HSM-Management-Softwarelösungen, CA-Software und Plattformen für das Zertifikatslebenszyklusmanagement sind proprietär. Lizenzvereinbarungen für diese Produkte legen in der Regel fest, ob die Software in Produktions- oder Entwicklungs-/Testumgebungen eingesetzt werden darf.

Was ist der Unterschied zwischen einer EULA und einem Softwarelizenzvertrag?

Endbenutzer-Lizenzverträge (EULAs) und Software-Lizenzverträge (SLAs) sind beides Instrumente zur Softwarelizenzierung, unterscheiden sich jedoch in ihrer Bereitstellung, ihren Verhandlungstaktiken und den typischerweise enthaltenen Bedingungen:

Kategorie	EULA (Endbenutzer-Lizenzvereinbarung)	SLA (Software-Lizenzvertrag)
Wie es geliefert wird	Wird bei der Softwareinstallation oder über einen Vertriebskanal im Einzelhandel oder App Store präsentiert. Typischerweise handelt es sich um eine Click-Through-Vereinbarung.	Ausgehandelt und direkt zwischen dem Softwareentwickler und der kaufenden Organisation vor oder zum Zeitpunkt des Kaufs unterzeichnet.
Wer verhandelt es?	Es gelten die vom Entwickler festgelegten, nicht verhandelbaren Standardbedingungen. Der Nutzer akzeptiert die Software oder installiert sie nicht.	Verhandelbar. Die einkaufende Organisation kann über die Anzahl der Lizenzen, die Supportbedingungen, die Haftungsbegrenzungen, die Prüfrechte und den Einsatzumfang verhandeln.
Geistiges Eigentum	Definitionen des geistigen Eigentums: Der Entwickler behält das Urheberrecht. Die Endbenutzer-Lizenzvereinbarung (EULA) definiert, was der Benutzer mit der Software tun darf.	Urheberrechtsvorbehalt: Der Entwickler behält das Urheberrecht. Die SLA regelt die Rechte zum Kopieren, Anzeigen und Verbreiten präziser als eine EULA.
Gewährleistungen und Haftung	Eingeschränkte Gewährleistungen: Diese werden in der Regel vollständig ausgeschlossen oder auf den Ersatz defekter Datenträger beschränkt. Die Haftung ist auf den Kaufpreis begrenzt.	Verhandelbar: SLAs können Verfügbarkeitsgarantien, Service-Level-Verpflichtungen, Freistellungsklauseln und Haftungsobergrenzen beinhalten, die auf Basis des Wertes der Geschäftsbeziehung ausgehandelt werden.
Nutzungsbeschränkungen	Nutzungsbeschränkungen: Definiert die zulässige Anzahl an Installationen, geografische Beschränkungen und zulässige Anwendungsfälle. Im Allgemeinen nicht spezifisch.	Änderungsbeschränkungen: Legt genau fest, welche Umgebungen (Produktion, Entwicklung, Test), geografischen Regionen und Benutzerkategorien von der Lizenz abgedeckt werden.
Prüfungsrechte	Normalerweise nicht enthalten. Der Anbieter hat nur begrenzte Möglichkeiten, die Einhaltung der Vorschriften zu überprüfen.	Typischerweise beinhaltet dies auch das Prüfrecht des Anbieters: Der Entwickler darf die Softwarenutzung der Organisation prüfen, um die Einhaltung der Lizenzanzahl- und Bereitstellungsbeschränkungen zu verifizieren.
Typischer Anwendungsfall	Verbrauchersoftware, mobile Apps, Desktop-Anwendungen, die über App-Stores oder Einzelhändler erworben werden.	Unternehmenssoftware, HSM-Managementplattformen, CA-Software, Zertifikatslebenszyklusmanagementsysteme und jegliche Software, bei der die Organisation die Bedingungen aushandelt.

Worin besteht der Unterschied zwischen Floating- und Node-Locked-Lizenzen?

Die Unterscheidung zwischen Floating- und Node-Locked-Lizenzen ist besonders wichtig in kryptografischen und PKI-Softwareumgebungen, wo die Bindung zwischen Software und Hardware direkte Sicherheitsauswirkungen haben kann:

Lizenzmodell	So funktioniert’s	Auswirkungen auf die Einhaltung	Sicherheitsimplikationen in Krypto-Umgebungen
Knotengebunden (gerätespezifisch)	Die Lizenz ist an ein bestimmtes Gerät gebunden, das durch einen Hardware-Fingerabdruck identifiziert wird: MAC-Adresse, CPU-ID, TPM-Bindung oder HSM-Seriennummer. Nur auf diesem Gerät kann die lizenzierte Software ausgeführt werden.	Einfache Überprüfung: Das Gerät verfügt entweder über die Lizenz oder nicht. Keine Verwaltung gleichzeitiger Nutzung erforderlich.	Starke Kompatibilität mit HSM-Implementierungen, bei denen die Software explizit an ein bestimmtes Hardwaremodul gebunden ist. Verhindert die Übertragung der Software auf ein nicht autorisiertes Gerät, was insbesondere in FIPS-validierten Umgebungen relevant ist, da die Validierung eine spezifische Hardwarekonfiguration umfasst.
Gleitend (gleichzeitig)	Ein Lizenzpool wird von einem Lizenzserver verwaltet. Jedes Gerät im lizenzierten Netzwerk kann eine Lizenz bis zur erworbenen Anzahl gleichzeitiger Benutzer nutzen. Sobald ein Benutzer die Software schließt, wird die Lizenz dem Pool wieder hinzugefügt.	Erfordert eine kontinuierliche Überwachung, um sicherzustellen, dass die gleichzeitige Nutzung die Anzahl der erworbenen Lizenzen nicht überschreitet. Ein häufiger Grund für Beanstandungen bei Software-Audits.	In PKI- und Zertifikatsverwaltungsumgebungen ist bei Floating-Lizenzen die Sicherung des Lizenzservers selbst erforderlich. Unbefugter Zugriff auf den Lizenzserver kann es nicht autorisierten Systemen ermöglichen, Lizenzberechtigungen zu nutzen und potenziell auf Funktionen zur Zertifikatsausstellung oder Schlüsselverwaltung zuzugreifen.
Abonnement (SaaS-basiert)	Die Lizenz ist an eine Benutzeridentität gebunden, die über einen Identitätsanbieter verwaltet wird. Die Lizenz ist benutzergebunden und nicht gerätegebunden. Der Zugriff wird über das Identitätsmanagementsystem bereitgestellt und entzogen.	Bei Berechtigungsprüfungen muss sichergestellt werden, dass nur aktuelle Mitarbeiter oder autorisierte Partner über aktive Berechtigungen verfügen. Werden ausgeschiedene Benutzer nicht ordnungsgemäß deaktiviert, führt dies sowohl zu Überlizenzierung als auch zu Sicherheitsrisiken.	In cloudbasierten HSM- oder Zertifikatsverwaltungsplattformen steuern Abonnementberechtigungen den Zugriff auf HSM-Partitionen, CA-Funktionen und Schlüsselverwaltungsvorgänge. Berechtigungslücken ermöglichen es unberechtigten Benutzern, kryptografische Operationen durchzuführen, die eigentlich eingeschränkt sein sollten.

Was ist eine Softwareberechtigung und wie unterscheidet sie sich von einer Lizenz?

Die Berechtigungsvergabe ist der operative Schritt nach der Lizenzierung. Während eine Lizenz festlegt, wofür und unter welchen Bedingungen die Software verwendet werden darf, spezifiziert eine Berechtigungsvergabe den genauen Umfang, wer oder was unter dieser Lizenz Zugriff erhält.

Ein konkretes Beispiel: Eine Organisation erwirbt eine Softwarelizenz für 50 Lizenzen einer Zertifikatsverwaltungsplattform. Die Lizenz berechtigt bis zu 50 gleichzeitige Benutzer zur Nutzung der Software. Die Berechtigungen sind die 50 spezifischen Zuweisungen: Benutzer A erhält Zugriff auf die Produktions-Zertifizierungsstelle, Benutzer B nur auf die Berichtsfunktion und die Benutzer C bis F auf die Entwicklungsumgebung. Die Berechtigungsebene setzt die Lizenzbedingungen auf Benutzer- und Systemebene durch und generiert die Prüfnachweise, die die Einhaltung der Lizenzvereinbarung bestätigen.

Eine Produktberechtigung definiert typischerweise vier Dinge:

• Welches Produkt wurde gekauft? Das spezifische Softwareprodukt, die Version und die Edition, die von der Lizenz abgedeckt werden.
• Die Anzahl der gekauften Plätze oder Instanzen: Die maximale Anzahl gleichzeitiger Benutzer, Geräte oder Bereitstellungen, die im Rahmen der Lizenz zulässig sind.
• Der Lizenztyp: Ob die Lizenz gerätegebunden (knotengebunden), flexibel (gleichzeitig) oder abonnementbasiert (benutzeridentitätsbasiert) ist.
• Abonnementzeitraum und -umfang: Die Laufzeit der Lizenz, welche Updates enthalten sind, welche Umgebungen (Produktion, Entwicklung, Notfallwiederherstellung) abgedeckt sind und etwaige geografische oder anwendungsfallbezogene Einschränkungen.

Wie verhalten sich Lizenzen und Berechtigungen in Kryptographie- und PKI-Umgebungen?

In kryptografischen Umgebungen und PKI-Umgebungen haben Lizenzen und Berechtigungen eine weitreichendere Bedeutung als die übliche Softwarekonformität. Die lizenzierte Software steuert häufig den Zugriff auf sensible kryptografische Funktionen: die Generierung privater Schlüssel, die Zertifikatsausstellung, die HSM-Partitionsverwaltung oder Codesignierungsvorgänge. Lücken in den Berechtigungen bergen in diesen Umgebungen sowohl Compliance- als auch Sicherheitsrisiken.

Kryptografische Funktion	Lizenzüberlegungen	Anspruchsprüfung	Lückenrisiko
HSM (Hardware-Sicherheitsmodul)-Verwaltungssoftware	HSM-Managementsoftware wird üblicherweise pro Partition, pro Gerät oder pro Cluster lizenziert. FIPS 140-3-validierte Konfigurationen sind häufig an eine bestimmte, durch das CMVP-Zertifikat abgedeckte Softwareversion gebunden. Ein Upgrade der Managementsoftware kann eine erneute Validierung erforderlich machen.	Berechtigungen steuern, welche Administratoren auf welche HSM-Partitionen zugreifen können. Zu viele Berechtigungen (zu viele Benutzer mit Partitionszugriff) vergrößern die Angriffsfläche für Insider-Bedrohungen. Zu wenige Berechtigungen (wichtige Verantwortliche ohne Zugriff) bergen Risiken für die Betriebskontinuität.	Unberechtigter Partitionszugriff ermöglicht die Extraktion von Schlüsseln; Unfähigkeit zur Wiederherstellung von Schlüsseln aufgrund unzureichender Berechtigungen; FIPS-Compliance-Lücke durch die Verwendung einer Softwareversion, die nicht durch das CMVP-Zertifikat abgedeckt ist.
Zertifizierungsstellen-Software (CA-Software)	CA-Softwarelizenzen unterscheiden üblicherweise zwischen Root-CA-, ausstellenden CA- und Richtlinien-CA-Bereitstellungen. Einige Anbieter lizenzieren nach der Anzahl der jährlich ausgestellten Zertifikate. Lizenzprüfungen stellen sicher, dass die Bereitstellungstopologie der lizenzierten Konfiguration entspricht.	Berechtigungen in CA-Software steuern, welche Betreiber Zertifikate für welche Profile und Zertifikatstypen (TLS, Codesignatur, Clientauthentifizierung) ausstellen dürfen. Zertifikatsprofilberechtigungen verhindern, dass ein Betreiber ein Wildcard-TLS-Zertifikat ausstellt, wenn nur DV-Zertifikate mit einem einzigen Namen autorisiert sind.	Unerlaubte Zertifikatsausstellung durch überberechtigte Betreiber; Ausstellung gefälschter Zertifikate außerhalb des autorisierten Profils; Feststellungen bei Prüfungen, dass CA-Implementierungen nicht der lizenzierten Topologie entsprechen.
Plattformen für das Zertifikatslebenszyklusmanagement (CLM)	CLM-Plattformen werden üblicherweise nach Anzahl der verwalteten Zertifikate, Anzahl der verbundenen Systeme oder Anzahl der Benutzerlizenzen lizenziert. Die Einhaltung der Lizenzbestimmungen setzt voraus, dass die Anzahl der verwalteten Zertifikate das vertraglich vereinbarte Limit nicht überschreitet.	Berechtigungen in CLM-Plattformen steuern, welche Systeme automatisch Zertifikate anfordern können, welche Zertifikatvorlagen für welche Systeme verfügbar sind und welche Benutzer Zertifikatsanfragen genehmigen können. Berechtigungsregeln setzen die Zertifikatsrichtlinie der Organisation auf operativer Ebene durch.	Unberechtigte Zertifikatsanforderungen von Systemen außerhalb des Berechtigungsbereichs; Verstöße gegen die Zertifikatsrichtlinien durch Zugriff auf nicht autorisierte Zertifikatsprofile; Überlizenzierung, die unnötige Kosten verursacht.
Software und Infrastruktur für die Codesignierung	Codesignaturplattformen werden üblicherweise pro Entwicklerplatz oder pro Signiervorgang lizenziert. Die Lizenz umfasst das Recht zur Nutzung der Signierinfrastruktur; das Codesignaturzertifikat selbst wird im Rahmen einer separaten Zertifizierungsstelle mit eigener Gültigkeitsdauer und eigenen Bedingungen ausgestellt.	Berechtigungen in Codesignaturplattformen steuern, welche Entwickler oder Pipelines Code mit welchen Zertifikaten und für welche Produktlinien signieren dürfen. Korrekte Berechtigungen verhindern, dass ein Entwickler eine Produktionsversion mit einem Entwicklungszertifikat signiert oder Code für eine Produktlinie signiert, für die er nicht autorisiert ist.	Unautorisierte Codesignierung, die es bösartigem Code ermöglicht, gültige Signaturen zu tragen; Entwicklungszertifikate, die in der Produktion verwendet werden; Lücken im Prüfprotokoll, wenn die Durchsetzung von Berechtigungen nicht protokolliert wird.
Schlüsselverwaltungssysteme (KMS)	KMS-Plattformen werden typischerweise nach der Anzahl der verwalteten Schlüssel, der Anzahl der verbundenen Anwendungen oder dem Umfang kryptografischer Operationen lizenziert. Die Lizenzbedingungen können zulässige Anwendungsfälle (Verschlüsselung ruhender Daten, Schlüsselaustausch, Zertifikatssignierung) festlegen.	Berechtigungen in einem KMS definieren, welche Anwendungen welche Schlüssel für welche kryptografischen Operationen mit welchen Zugriffsrechten anfordern können. Rollenbasierte Berechtigungen trennen die Schlüsselerzeugung von der Schlüsselverwendung, den Schlüsselexport von der Schlüsselverwaltung und den reinen Prüfzugriff vom operativen Zugriff.	Anwendung greift auf Schlüssel außerhalb ihres autorisierten Bereichs zu; Rechteausweitung durch übermäßige Berechtigungen; fehlender Prüfpfad für Schlüsselzugriffsvorgänge.

Wie schützt die Codesignierung das geistige Eigentum an Software?

Die Codesignierung ist der kryptografische Mechanismus, der den Schutz des geistigen Eigentums einer Softwarelizenz über die vertragliche Vereinbarung hinaus technisch durchsetzt. Eine Lizenzvereinbarung legt fest, dass die Software nicht ohne Genehmigung verändert oder verbreitet werden darf. Ein Codesignierungszertifikat macht unautorisierte Änderungen und Verbreitungen erkennbar.

Wenn ein Entwickler seine Software mit einem Codesignaturzertifikat signiert , erstellt er einen kryptografischen Hash der Binärdatei und verschlüsselt diesen mit seinem privaten Schlüssel. Der zugehörige öffentliche Schlüssel, der im Codesignaturzertifikat eingebettet ist, ermöglicht es jedem Benutzer oder System, zwei Dinge zu überprüfen: dass die Binärdatei seit der Signierung durch den Entwickler nicht verändert wurde und dass sie von der im Zertifikat genannten Entität signiert wurde. Dadurch entsteht eine lückenlose Beweiskette, die belegt, dass die Binärdatei das authentische Werk des Entwicklers ist.

Für die Durchsetzung von Softwarelizenzen ist dies aus folgenden Gründen relevant:

• Die unautorisierte Weitergabe modifizierter Software führt zur Beschädigung der Codesignatur. Jeder Empfänger, der die Signatur vor der Installation überprüft, wird die Manipulation feststellen.
• Gefälschte Software, die unter dem Namen des Entwicklers ohne authentische Signatur vertrieben wird, kann durch Signaturprüfung als nicht authentisch identifiziert werden.
• Betriebssysteme und Bereitstellungsplattformen fordern zunehmend gültige Codesignaturen, bevor sie die Ausführung von Software zulassen. Dadurch wird ein Mechanismus zur Durchsetzung der Authentizitätsanforderungen der Lizenz geschaffen.
• Bei Software-Updates gewährleisten signierte Update-Pakete, dass nur der autorisierte Entwickler Codeänderungen an die installierten Systeme weitergeben kann, wodurch eine unautorisierte Patch-Verteilung verhindert wird.

Für die kommerzielle Softwaresignatur verwendete Codesignaturzertifikate werden üblicherweise von einer Zertifizierungsstelle (CA) ausgestellt, die vor der Ausstellung die Identität der Entwicklerorganisation überprüft. Für höchste Sicherheit bei der Signatur, insbesondere für Software, die in regulierten Umgebungen eingesetzt wird, bieten erweiterte Validierungszertifikate (EV) eine zusätzliche Identitätsprüfung und erfordern, dass der private Signaturschlüssel in einem nach FIPS 140-3 Level 2 oder Level 3 validierten Hardwaremodul gespeichert wird. Eine detaillierte Anleitung zur Implementierung finden Sie in unserem Leitfaden zur Verbesserung der Softwaresicherheit durch Codesignatur .

Checkliste zur Prüfung von Lizenzen und Berechtigungen in kryptografischen Umgebungen

Organisationen, die kryptografische Software verwalten, sollten im Rahmen ihrer Software-Asset-Management- und Sicherheitskonformitätsprogramme die folgenden Kontrollen aufrechterhalten:

Kontrollbereich	Anforderung	Beweisstück	Eigentümer	Status
Lizenzbestand	Vollständiges Verzeichnis aller Softwarelizenzen für kryptografische Funktionen: HSM-Management, CA-Software, CLM-Plattformen, Codesignatur-Tools und KMS-Systeme	Software-Asset-Register mit Lizenztyp, Anzahl der Lizenzen, Lizenzlaufzeit und Anbieter für jedes Produkt	IT-Asset-Management / Compliance	Zum Handeln
Überprüfung der Lizenzkonformität	Prüfen Sie, ob die tatsächlichen Softwarebereitstellungen den vertraglich vereinbarten Lizenzumfang (Anzahl der Arbeitsplätze, Anzahl der Instanzen, Anzahl der Zertifikate, Bereitstellungsumgebung) nicht überschreiten.	Lizenzkonformitätsbericht mit Angabe der Anzahl der installierten und lizenzierten Systeme; ggf. Lieferantenauditbericht	IT Asset Management	Zum Handeln
Berechtigungszuordnung	Jeder Benutzer und jedes System mit Zugriff auf lizenzierte kryptografische Software verfügt über eine dokumentierte Berechtigungszuweisung mit geschäftlicher Begründung.	Berechtigungsregister zur Zuordnung von Benutzern/Systemen zu lizenzierten Produkten, Zugriffsebenen und Genehmigern	IAM / Sicherheit	Zum Handeln
Berechtigungsrezertifizierung	Berechtigungen werden mindestens jährlich überprüft und neu zertifiziert; Berechtigungen ausgeschiedener Benutzer werden innerhalb der definierten Service-Level-Vereinbarung (SLA) deaktiviert.	Rezertifizierungsnachweise mit Datum und Unterschriften der Genehmiger; Deaktivierungsprotokoll mit Zeitstempeln	IAM / HR	Zum Handeln
HSM-Partitionsberechtigungen	Der Zugriff auf die HSM-Partition wird durch dokumentierte Berechtigungen gesteuert; die Rollenverteilung zwischen Schlüsselerzeugung, Schlüsselverwendung und Schlüsselprüfung wird durchgesetzt.	HSM-Administratorrollenmatrix; Partitionszugriffsprotokolle; Dokumentation zur Rollentrennung	Sicherheitstechnik / Schlüsselverwaltung	Zum Handeln
Berechtigungen für CA-Betreiber	Die Rechte zur Zertifikatsausstellung sind durch dokumentierte Berechtigungen beschränkt; Betreiber dürfen nur Zertifikatstypen innerhalb ihres autorisierten Profilumfangs ausstellen.	Dokumentation der CA-Operatorrolle; Zugriffsmatrix für Zertifikatsprofile; Prüfung des Ausstellungsprotokolls	PKI-Team / Sicherheit	Zum Handeln
Berechtigungen für die Codesignierung	Codesignierungsvorgänge sind auf autorisierte Entwickler und Pipelines beschränkt; Produktionssignaturzertifikate sind von Entwicklungs-/Testzertifikaten getrennt.	Codesignatur-Berechtigungsregister; Signaturkonfiguration der CI/CD-Pipeline; Nachweis der Zertifikatsprofiltrennung	Entwicklung / Sicherheitstechnik	Zum Handeln
Einhaltung der Open-Source-Lizenz	Open-Source-Komponenten in kryptografischer Software wurden identifiziert und ihre Lizenzverpflichtungen bewertet; GPL-lizenzierte kryptografische Bibliotheken wurden ohne rechtliche Prüfung nicht in proprietäre Produkte integriert.	Bericht zur Softwarezusammensetzungsanalyse (SCA); Verzeichnis von Open-Source-Lizenzen; Aufzeichnungen zur rechtlichen Prüfung von Copyleft-Komponenten	Entwicklung / Recht	Zum Handeln
FIPS-Versionsausrichtung	Bei FIPS-konformen Bereitstellungen ist zu überprüfen, ob die verwendete Softwareversion durch das aktive FIPS 140-3 CMVP-Zertifikat für dieses Produkt abgedeckt ist.	CMVP-Zertifikatsnummer und Versionsabdeckung; Dokumentation der Softwareversion; jährliches Re-Verifizierungsprotokoll	Sicherheitstechnik / Compliance	Zum Handeln
Überwachung der Lizenzlaufzeit	Ablaufdaten von Softwarelizenzen werden überwacht; die Verlängerung wird vor Ablauf eingeleitet, um Lücken in der autorisierten Nutzung zu vermeiden.	Ablaufkalender für Lizenzen; Aufzeichnungen über die Einleitung von Verlängerungen; Bestätigung des verlängerten Lizenzinhabers durch den Anbieter	IT-Asset-Management / Beschaffung	Zum Handeln

Was Verschlüsselungsberatung empfiehlt

In kryptografischen Umgebungen und PKI-Umgebungen ist das am häufigsten unterschätzte Lizenz- und Berechtigungsrisiko nicht die übermäßige Bereitstellung von Softwarelizenzen. Es ist die Berechtigungsverschiebung in Zertifikats- und Schlüsselverwaltungssystemen: die schleichende Anhäufung von Benutzern mit umfassenderen Zugriffsrechten, als ihre aktuelle Rolle rechtfertigt. Dies ist oft die Folge von Rollenwechseln, Teamumstrukturierungen oder Projektübergängen, bei denen Berechtigungen zwar erteilt, aber nie überprüft oder eingeschränkt wurden.

Die praktische Konsequenz ist, dass Zertifikatsausstellung, HSM-Partitionszugriff und Codesignierungsvorgänge auch Benutzern zur Verfügung stehen, deren aktuelle Rolle diese Berechtigungen nicht erfordert. Wenn ein Insider oder ein kompromittiertes Konto diese Berechtigungen ausnutzt, zeigt der Prüfpfad den autorisierten Zugriff mit einer gültigen Berechtigung an, wodurch die unautorisierte Aktion deutlich schwerer zu erkennen und zuzuordnen ist. Die regelmäßige Rezertifizierung von Berechtigungen ist keine bloße Pflichterfüllung, sondern eine der effektivsten Zugriffskontrollen für kryptografische Systeme.

Der zweite Bereich, der besondere Beachtung verdient, ist die Einhaltung der Open-Source-Lizenzbestimmungen für kryptografische Bibliotheken. Organisationen, die Open-Source-Bibliotheken in kommerzielle Produkte integrieren, müssen die Lizenzbestimmungen jeder einzelnen Bibliothek kennen. Eine unter der Apache-2.0-Lizenz stehende Bibliothek kann unter Angabe der Quelle in ein proprietäres Produkt eingebunden werden. Eine unter der GPL-Lizenz stehende Bibliothek hingegen verpflichtet bei gleicher Einbindung dazu, das gesamte Produkt als Open Source zu veröffentlichen. Viele Entwicklungsteams versäumen die rechtliche Prüfung der Lizenzen von Open-Source-Bibliotheken vor der Produktveröffentlichung, bis ein Audit des Anbieters oder die Due-Diligence-Prüfung eines Käufers die Lücke aufdeckt.

Wie Verschlüsselungsberatung bei der Lizenz- und Berechtigungsverwaltung helfen kann

Encryption Consulting ist ein nach ISO/IEC 27001:2022 und SOC 2 zertifiziertes Unternehmen für angewandte Kryptografie. Wir unterstützen Organisationen bei der Implementierung von Berechtigungskontrollsystemen, der Verwaltung des Zertifikatslebenszyklus und der Infrastruktur für Codesignierung, um die operative Durchsetzung von Softwarelizenzen zu gewährleisten.

• CertSecure Manager: CertSecure Manager Die Plattform bietet ein umfassendes Zertifikatslebenszyklusmanagement, das die Berechtigungsrichtlinien für die Zertifikatsausstellung durchsetzt. Zertifikatsprofile, Autorisierung von Anforderern, Genehmigungsworkflows und Ausstellungsprotokolle liefern Unternehmen den operativen Nachweis, dass ihre Zertifizierungsstellenberechtigungen korrekt durchgesetzt werden. Diese Plattform ist ideal für Organisationen, deren Compliance-Programme eine nachweisbare Kontrolle darüber erfordern, wer welche Zertifikate von welchen Zertifizierungsstellen anfordern darf.
• CodeSign Secure: CodeSign Secure Die Software setzt Berechtigungen für die Codesignierung durch, indem sie kontrolliert, welche Entwickler, Pipelines und Build-Systeme Code mit welchen Zertifikaten und für welche Produktlinien signieren dürfen. Private Signaturschlüssel werden in FIPS 140-3-validierten HSMs gespeichert. Dadurch wird sichergestellt, dass der Schutz geistigen Eigentums durch die Codesignierung auch durch hardwareseitigen Schlüsselschutz gewährleistet ist. Audit-Logs jedes Signaturvorgangs liefern die von Lizenzvereinbarungen und Compliance-Programmen geforderten Nachweise.
• PKI als Dienstleistung: Für Organisationen, die ihre CA-Infrastruktur aufbauen oder modernisieren, PKI-as-a-Service Bietet eine vollständig verwaltete Zertifizierungsstelle (CA) mit Zertifikatsrichtlinien (CP) und Zertifizierungspraxisanweisungen (CPS), die die Berechtigungsregeln für die Zertifikatsausstellung auf Governance-Ebene definieren. Die Richtliniendokumente, die festlegen, wer welche Zertifikatstypen erhalten kann, bilden das grundlegende Berechtigungsframework für die gesamte PKI.
• HSM als Dienstleistung: Für Organisationen, deren Softwarelizenzen eine HSM-gestützte Schlüsselspeicherung erfordern, HSM-as-a-Service bietet FIPS 140-3 Level 3 validierte HSM-Partitionen mit dokumentierten Partitionszugriffskontrollen, die sowohl die Lizenzanforderungen für HSM-gestützte Bereitstellungen als auch die Anforderungen an das Berechtigungsmanagement zur Steuerung des HSM-Operatorzugriffs erfüllen.
• Beratungsleistungen im Bereich Compliance: Unsere Compliance-Beratungsdienste Die Leistungen umfassen die Überprüfung der Einhaltung von Softwarelizenzbestimmungen, die Bewertung von Anspruchslücken in kryptografischen Softwareumgebungen, die Überprüfung der Open-Source-Lizenzverpflichtungen für Produkte, die kryptografische Bibliotheken enthalten, sowie die vollständige Dokumentation, die für interne Audits und externe regulatorische Bewertungen erforderlich ist.

Fazit

Lizenzen und Nutzungsrechte bilden zusammen den rechtlichen und operativen Rahmen, der die Nutzung von Software, einschließlich kryptografischer Software, und die jeweiligen Nutzer regelt. Die Lizenz schafft die rechtliche Bindung und schützt das geistige Eigentum des Entwicklers. Das Nutzungsrecht setzt diese Bindung auf operativer Ebene durch, indem es den Zugriff auf den vertraglich vereinbarten Umfang verfolgt und kontrolliert.

In kryptografischen Umgebungen und PKI-Umgebungen kommt diesem Rahmenwerk eine besondere Bedeutung zu: Die lizenzierte Software steuert den Zugriff auf sensible Funktionen wie Zertifikatsausstellung, Schlüsselgenerierung, HSM-Partitionsverwaltung und Codesignierung. Berechtigungslücken in diesen Umgebungen bergen sowohl Compliance- als auch Sicherheitsrisiken. Regelmäßige Überprüfungen der Lizenzkonformität und die Rezertifizierung von Berechtigungen stellen keinen zusätzlichen Verwaltungsaufwand dar, sondern sind Zugriffskontrollen für die sensibelsten Funktionen der Sicherheitsinfrastruktur des Unternehmens.

Für Organisationen, die Open-Source-Kryptografiebibliotheken verwenden, sind Lizenzprüfungen ebenso wichtig: Die Lizenzbedingungen (permissive oder Copyleft-Lizenz) jeder Bibliothek bestimmen, ob und unter welchen Bedingungen sie in proprietäre Produkte integriert werden darf. Eine Software Composition Analysis (SCA) der Abhängigkeiten von Kryptografiebibliotheken ist der Mindestbeginn für jede Organisation, die Produkte mit Open-Source-Kryptografiecode vertreibt.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen einer Softwarelizenz und einer Berechtigung?

Eine Softwarelizenz ist die rechtliche Vereinbarung, die das Recht zur Nutzung von Software unter festgelegten Bedingungen einräumt. Die Berechtigungsverwaltung setzt diese Lizenz operativ um und legt fest, welche Benutzer, Geräte oder Systeme zur Nutzung der Software berechtigt sind. Sie überwacht die tatsächliche Nutzung im Verhältnis zum vereinbarten Umfang. Die Lizenz definiert, was erlaubt ist; die Berechtigungsverwaltung definiert, wer diese Berechtigung erhält. In PKI- und Kryptografieumgebungen steuert die Berechtigungsverwaltung zudem, welche Systeme Zertifikate anfordern, auf HSM-Partitionen zugreifen oder privilegierte Schlüsselverwaltungsoperationen durchführen dürfen.

Worin besteht der Unterschied zwischen einer EULA und einem Softwarelizenzvertrag?

Eine Endbenutzer-Lizenzvereinbarung (EULA) wird bei der Softwareinstallation über einen Vertriebskanal wie den Einzelhandel oder einen App-Store angezeigt. Sie ist nicht verhandelbar und regelt die Rechte der Endbenutzer zu Standardbedingungen. Ein Softwarelizenzvertrag (SLA) wird direkt zwischen dem Softwareentwickler und dem Käufer ausgehandelt und enthält typischerweise vereinbarte Bedingungen für die Anzahl der Lizenzen, den Bereitstellungsumfang, Supportverpflichtungen, Prüfrechte und Haftungsbeschränkungen. Kryptografische Unternehmenssoftware wie CA-Plattformen, HSM-Management-Software und CLM-Systeme unterliegen stets SLAs anstelle von EULAs.

Was ist der Unterschied zwischen einer Floating-Lizenz und einer Node-Locked-Lizenz?

Eine gerätegebundene Lizenz ist über einen Hardware-Fingerabdruck an ein bestimmtes Gerät gebunden und kann nur auf diesem verwendet werden. Eine Floating-Lizenz hingegen wird netzwerkweit bereitgestellt und ermöglicht es jedem Gerät, eine Lizenz bis zur erworbenen Anzahl gleichzeitiger Benutzer zu nutzen. In HSM-Umgebungen ist die gerätegebundene Lizenzierung üblich, da die Managementsoftware an die jeweilige HSM-Hardware gebunden ist. CLM- und PKI-Plattformen verwenden hingegen häufiger Floating- oder abonnementbasierte Lizenzen. Diese Unterscheidung ist relevant für Compliance-Audits und FIPS-validierte Konfigurationen, deren Validierung eine bestimmte Kombination aus Hardware- und Softwareversionen umfasst.

In welchem ​​Verhältnis stehen Softwarelizenzen zu Codesignaturzertifikaten?

Codesignaturzertifikate gewährleisten die kryptografische Durchsetzung der Schutzrechte des geistigen Eigentums in einer Softwarelizenz. Jede Änderung der Binärdatei, die mit einem Codesignaturzertifikat signiert ist, führt zum Verlust der Signatur und ist für jeden erkennbar, der die Signatur vor der Installation überprüft. Dadurch lassen sich unautorisierte Weitergabe, Manipulation oder Änderung lizenzierter Software kryptografisch und nicht nur vertraglich nachweisen. EV-Codesignaturzertifikate erfordern die Speicherung des privaten Signaturschlüssels in einem nach FIPS 140-3 Level 2 oder Level 3 validierten HSM und ergänzen so den Schutzmechanismus für geistiges Eigentum um eine Hardwareebene.

Was ist Software-Berechtigungsmanagement und warum ist es für die Sicherheit wichtig?

Die Verwaltung von Softwareberechtigungen umfasst die Nachverfolgung, Durchsetzung und Prüfung, welche Benutzer, Geräte und Systeme zur Nutzung lizenzierter Software berechtigt sind und welche Zugriffsrechte sie besitzen. In kryptografischen Umgebungen führt die schleichende Anhäufung von Benutzern mit weitergehenden Zugriffsrechten als für ihre Rolle erforderlich sowohl zu Compliance-Risiken als auch zu Bedrohungen durch Insider. Die regelmäßige Rezertifizierung von Berechtigungen ist eine der effektivsten Zugriffskontrollen für HSM-Partitionen, Zertifizierungsstellen und Codesignierungsvorgänge.

Was ist eine Open-Source-Lizenz und welche Verpflichtungen bringt sie mit sich?

Eine Open-Source-Lizenz gewährt das Recht, den Quellcode einzusehen, zu verändern und zu verbreiten. Die konkreten Verpflichtungen variieren jedoch je nach Lizenztyp. Permissive Lizenzen (z. B. MIT, Apache 2.0) erlauben die Einbindung in proprietäre Software lediglich unter Angabe der Quelle. Copyleft-Lizenzen (z. B. GPL) schreiben vor, dass abgeleitete Werke unter derselben Lizenz verbreitet werden müssen. Dies kann die Einbindung in proprietäre Produkte verhindern, ohne das gesamte Produkt als Open Source zu veröffentlichen. Organisationen, die Open-Source-Kryptografiebibliotheken in kommerzielle Produkte integrieren, müssen die Lizenzverpflichtungen vor der Verbreitung prüfen, da GPL-lizenzierte Bibliotheken erhebliche Probleme im Bereich des geistigen Eigentums verursachen können.

Wie helfen Tools für das Zertifikatslebenszyklusmanagement bei der Einhaltung von Lizenz- und Berechtigungsbestimmungen?

CLM-Tools setzen Berechtigungsrichtlinien für digitale Zertifikate durch, indem sie steuern, welche Systeme welche Zertifikatstypen von welchen Zertifizierungsstellen anfordern dürfen, die Ausstellung anhand dokumentierter Berechtigungsregeln automatisieren und einen Prüfpfad generieren, der die Einhaltung der Berechtigungsrichtlinien verifiziert. Diese operative Durchsetzung auf Zertifikatsebene ist die praktische Umsetzung der Zertifikatsrichtlinie des Unternehmens, welche die Berechtigungen für die Zertifikatsausstellung auf Governance-Ebene definiert. Ohne eine CLM-Plattform, die Berechtigungsregeln durchsetzt, erfolgt die Zertifikatsausstellung häufig standardmäßig an Personen mit Administratorrechten der Zertifizierungsstelle, was eine häufige Ursache für unautorisierte Zertifikatsausstellungen ist.