← Sichere Softwarebereitstellung
Code Signing: eigenes Zertifikat oder Microsoft Artifact Signing?
Die passende Signierungsstrategie aus Vertrauensmodell, Lieferweg und Betriebsfähigkeit ableiten.
Code Signing bindet Herkunft und Integrität an ein Artefakt: Empfänger können prüfen, ob es seit der Signatur verändert wurde und welchem Zertifikat die Signatur zugeordnet ist. Es prüft nicht, ob der Code schadhaft ist. Ein eigenes Zertifikat passt bei Anforderungen an Schlüsselhoheit oder Offline-Signierung; Microsoft Artifact Signing bietet einen verwalteten Azure-Dienst für unterstützte Integrationen. Entscheidend sind Vertrauensmodell, CI/CD, Rollen, Wiederherstellung und Kosten – nicht nur der Signaturbefehl.
Ausgangslage
Release-Teams wollen etwa Anwendungen, Skripte oder Richtlinien signieren. Welche Artefaktarten und Integrationen Artifact Signing unterstützt, ist der aktuellen Microsoft-Learn-Dokumentation zu entnehmen; daraus lässt sich keine pauschale Unterstützung für Container ableiten. Ein lokaler Schlüssel kann Offline-Szenarien ermöglichen, erzeugt aber Schutz-, Zugriffs-, Rotation- und Notfallaufwand. Ein verwalteter Dienst reduziert die direkte Schlüsselverwaltung, macht den Release jedoch von Azure-Ressourcen, Identitäten, unterstützten Endpunkten und dem Dienststatus abhängig.
Fachliche Einordnung
Microsoft führt den Azure-Dienst aktuell als Artifact Signing (vormals Trusted Signing). Der Dienst verwaltet den Zertifikatslebenszyklus; dokumentierte Trust-Szenarien und Integrationen sowie Regions-, Identitäts- und Kontotyp-Voraussetzungen sind vor Nutzung im Zieltenant aktuell zu prüfen. Das ist eine Herstellerangabe, keine Zusage für unveränderte Verfügbarkeit, Regionen oder Funktionsgleichheit.
Signierung ist ein Vertrauensbaustein für die Freigabe und kann etwa Regeln in App Control for Business und Monitoring unterstützen. Sie ersetzt Malware-Scanning, Code Review, SBOM, Tests oder Incident Response nicht. CRA und NIS2 setzen risikoorientierte Anforderungen voraus; diese Seite behauptet daraus keine ausdrückliche allgemeine Signing-Pflicht.
Entscheidung: eigenes Zertifikat oder Artifact Signing?
Vertrauensziel
Eigenes Zertifikat: Eigene Vertrauenskette und Zertifikatswahl
Microsoft Artifact Signing: Verwaltete Profile innerhalb der Microsoft-Modelle
Artefakttyp
Eigenes Zertifikat: Durch Zertifikat, Tooling und Empfänger bestimmen
Microsoft Artifact Signing: Nur aktuell dokumentierte Formate und Integrationen
Schlüsselmodell
Eigenes Zertifikat: Kontrolle hängt von CA, HSM/Token, Cloud-KMS und Betrieb ab
Microsoft Artifact Signing: Schlüssel- und Zertifikatslebenszyklus durch Microsoft verwaltet
Offlinefähigkeit
Eigenes Zertifikat: Je nach eigener Infrastruktur möglich
Microsoft Artifact Signing: Signierauftrag benötigt Dienstzugriff; Offline-Fallback planen
Identität und RBAC
Eigenes Zertifikat: Eigenes Berechtigungsmodell umsetzen
Microsoft Artifact Signing: Azure RBAC; u. a. `Artifact Signing Certificate Profile Signer` und `Artifact Signing Identity Verifier`
CI/CD
Eigenes Zertifikat: Eigenes Tooling/Secrets/HSM-Integration
Microsoft Artifact Signing: SignTool, GitHub Actions, Azure DevOps, PowerShell, Azure PowerShell und SDK dokumentiert
Lifecycle
Eigenes Zertifikat: Beschaffung, Schutz, Rotation, Widerruf selbst betreiben
Microsoft Artifact Signing: Zertifikatsprofile und verwalteter Lifecycle; Identitätsvalidierung bleibt Prozessaufgabe
Volumen und Regionen
Eigenes Zertifikat: Kapazität und Verfügbarkeit selbst auslegen
Microsoft Artifact Signing: Quoten und Regionen im Zieltenant prüfen
Business Continuity
Eigenes Zertifikat: Ersatzschlüssel und Sperrprozess vorsehen
Microsoft Artifact Signing: Ausfall-, Regions- und Dienstwechselverfahren dokumentieren
Widerruf und Incident
Eigenes Zertifikat: Widerrufs-, Untersuchungs- und Kommunikationsprozess selbst betreiben
Microsoft Artifact Signing: Rollen-, Widerrufs- und Incident-Prozesse mit Dienstabhängigkeiten abstimmen
Aktuelle Voraussetzungen und Preise stehen auf der Azure-Preisseite für Artifact Signing. Sie sind vor Beschaffung für Vertrag, Region und Zieltenant zu prüfen; konkrete Preis- oder Kontingentangaben gehören nicht in diese Seite.
Was Unternehmen konkret klären müssen
- Welche Artefakte und Vertrauensempfänger benötigen welche Trust-Profile?
- Welcher Dienst oder welche Person darf eine Signatur auslösen – und darf ein Pipeline-Identität dies?
- Wie werden Freigabe, Zeitstempel, Audit-Spuren, Widerruf und Rotation nachgewiesen?
- Welche kritischen Releases brauchen ein getestetes Offline- oder Ersatzverfahren?
- Wie trennt die Pipeline Build, Sicherheitsprüfung, Freigabe und Signierung?
Vorgehen mit ADIUMENTO
Ob eine Signierungsarchitektur oder ein Pilot als Projektbaustein passt, hängt vom konkreten Auftrag und bestätigten Portfolio ab. Produktdetails sind auf Technologien und Leistungsbezüge auf Leistungen zu finden.
Typische Arbeitsergebnisse
- Entscheidungsdokument mit Trust-, Schlüssel- und Integrationsmodell;
- Rollen- und Freigabemodell für Personen und Pipeline-Identitäten;
- Signier-, Zeitstempel-, Widerrufs- und Fallbackprozess;
- Pilot für repräsentative Artefakte und messbare Betriebsanforderungen.
Grenzen und Abhängigkeiten
Eine gültige Signatur sagt nichts über Schadhaftigkeit, Zweckmäßigkeit oder rechtliche Konformität eines Artefakts aus. Regionen, Kontotyp-Voraussetzungen, Zertifikatsprofile, unterstützte Integrationen und Preise können sich ändern. Vor produktivem Einsatz sind aktuelle Microsoft-Dokumentation, Beschaffungsbedingungen und ein eigener Wiederanlaufplan zu prüfen. ADIUMENTO gibt keine Konformitäts- oder Verfügbarkeitsgarantie.
Weiterführende offizielle Quellen
- What is Artifact Signing? – Microsoft Learn
- Artifact Signing integrations – Microsoft Learn
- Azure Artifact Signing product – Microsoft Azure
Orientierung
Häufige Fragen
Ist Artifact Signing dasselbe wie Microsoft Trusted Signing?
Die aktuelle offizielle Azure-Dokumentation bezeichnet den Dienst Artifact Signing; technische Metadaten enthalten teils noch den Service-Namen `trusted-signing`. Für Architektur- und Beschaffungsentscheidungen ist die aktuelle Microsoft-Learn-Dokumentation maßgeblich.
Können wir Artifact Signing in unsere Pipeline integrieren?
Microsoft dokumentiert SignTool, GitHub Actions, Azure DevOps Tasks, PowerShell für Authenticode, Azure PowerShell für App-Control-CI-Richtlinien und ein SDK. Ob die eigene Pipeline, Region, Identität und Artefaktart passen, sollte ein Pilot verifizieren.
Ersetzt eine Signatur Defender oder WDAC?
Nein. Signaturen können in Vertrauensregeln berücksichtigt werden. Erkennung, Bewertung, Protokollierung und Reaktion bleiben eigenständige Kontrollen; siehe Defender, App Control, Monitoring und Incident Response.
Nächster sinnvoller Schritt
Grenzen Sie einen Release-Pfad, seine Vertrauensempfänger und die benötigte Wiederanlaufzeit ab. Falls vom Portfolio gedeckt, kann ein Pilot für Signierungsarchitektur und Betrieb über IT-Security & Compliance oder Leistungen geklärt werden.