Code Signing nutzt die Public Key Infrastructure (PKI), um als digitaler Reisepass für Ihre Software zu dienen. Durch digitale Signaturen wird ein kryptografischer Nachweis der Authentizität und Integrität erstellt. Es authentifiziert Sie als Herausgeber und stellt die Integrität Ihres Codes sicher, indem es beweist, dass Ihr Code seit der Veröffentlichung nicht mehr verändert wurde.
Wenn Benutzer Ihre Software herunterladen, vertrauen sie Ihnen die Sicherheit ihres Systems an. Brechen Sie dieses Vertrauen einmal, und Sie sind erledigt.
Inhaltsübersicht
- Schützen Sie private Schlüssel mit Hardware-Sicherheitsmodulen
- Implementierung strenger Zugriffskontrollen für Code Signing Keys
- Zeitstempel für Ihren Code während des Signiervorgangs
- Trennen Sie die Test-Signatur von der Freigabe-Signatur-Umgebung
- Implementieren Sie Code-Authentifizierung und Integritätsprüfung vor dem Signieren
- Vor dem Signieren einen Virenscan des Codes durchführen
- Schlüssel rotieren und mehrere Zertifikate verwenden
- Nehmen Sie den Widerruf von Zertifikaten ernst
- Nutzen Sie Extended Validation Code Signing-Zertifikate
- Automatisieren und zentralisieren Sie die Verwaltung von Code Signing
- Sichern Sie Ihre Software-Lieferkette mit SSL Dragon
Nachdem die Sicherheitslücke bei SolarWinds kritische Schwachstellen in der Software-Lieferkette aufgedeckt hatte, wurde es ernst. Es zeigte sich, wie kompromittierte Signierschlüssel legitime Software-Updates zu Waffen machen und Tausende von Unternehmen gefährden können. Mehr denn je ist das Befolgen von Best Practices für das Signieren von Code nicht optional, sondern von grundlegender Bedeutung für den Schutz Ihrer Benutzer und Ihres Rufs.
Der Schutz der Software-Lieferkette hat für Unternehmen aller Größenordnungen höchste Priorität. Diese Richtlinien helfen Ihnen bei der Implementierung von Sicherheitsmaßnahmen, die von Bedeutung sind, unabhängig davon, ob Sie ein einzelner Entwickler sind oder DevOps-Pipelines in Unternehmen verwalten. Egal, ob Sie ausführbare Windows-Dateien, macOS-Anwendungen, Linux-Pakete oder mobile Apps für iOS und Android signieren, diese Grundsätze gelten für alle Plattformen.
Schützen Sie private Schlüssel mit Hardware-Sicherheitsmodulen
Ihr privater Schlüssel ist das A und O beim Code Signing. Wird er kompromittiert, können Angreifer Malware mit Ihrer Identität signieren. Ihr Zertifikat wird widerrufen, Ihre Kunden verlieren das Vertrauen, und Ihre Marke erleidet einen Schaden, von dem Sie sich möglicherweise nicht mehr erholen.
Warum die Sicherheit privater Schlüssel so wichtig ist
Betrachten Sie Ihren privaten Schlüssel als den Hauptschlüssel für die Glaubwürdigkeit Ihrer Software – er erzeugt die digitalen Signaturen, die Ihre Identität beweisen. Wenn jemand ihn stiehlt, kann er bösartigen Code verbreiten, der aussieht, als käme er von Ihnen. Sie müssen Ihr Zertifikat widerrufen, alles, was Sie jemals veröffentlicht haben, neu signieren und hoffen, dass Ihre Kunden den Unterschied bemerken, bevor sie die infizierte Software installieren.
Der traditionelle Ansatz, Schlüssel auf Festplatten oder Build-Servern zu speichern, birgt Probleme. Die Rechner der Entwickler werden kompromittiert. Build-Server werden geknackt. Selbst bei verschlüsselter Speicherung auf normaler Hardware sind die Schlüssel anfällig für eine Extraktion.
FIPS 140-2 zertifizierte Hardware-Lösungen
Hardware-Sicherheitsmodule (HSMs) lösen dieses Problem, indem sie private Schlüssel in fälschungssicherer Hardware speichern. Als Eckpfeiler Ihrer PKI-Infrastruktur bieten HSMs die Sicherheitsgrundlage, die zertifikatsbasiertes Vertrauen erfordert. Diese Geräte generieren und verwenden Schlüssel intern, ohne sie jemals Ihrem System preiszugeben. Wenn Sie versuchen, ein HSM physisch zu manipulieren, werden die Schlüssel zerstört.
Die FIPS 140-2-Zertifizierung ist hier wichtig. Level 2 erfordert einen physischen Manipulationsnachweis, während Level 3 zusätzlich eine aktive Manipulationsreaktion vorsieht, bei der die Schlüssel gelöscht werden, wenn jemand versucht, einzubrechen. Für die meisten Unternehmen bietet Level 2 einen soliden Schutz. Diese Hardwarelösungen lassen sich nahtlos in Windows-, macOS- und Linux-Entwicklungsumgebungen integrieren und schützen Ihre Schlüssel unabhängig von der Build-Plattform. Behörden und hochsichere Anwendungen sollten Level 3 in Betracht ziehen.
USB-Tokens bieten eine tragbare HSM-Alternative. Es handelt sich dabei um FIPS-zertifizierte kryptografische Hardware, die Sie bei sich tragen können und die durch ihren Besitz zusätzliche physische Sicherheit bietet. Die wichtigsten Zertifizierungsstellen unterstützen sowohl HSM- als auch USB-Token-Implementierungen für Code Signing-Zertifikate.
Die Richtlinien der Zertifizierungsstellen sind jedoch unterschiedlich, und Sie müssen sich darauf einstellen. DigiCert und GoGetSSL stellen Code Signing-Zertifikate nur für 1 Jahr aus, und Sie können entweder ein von der CA bereitgestelltes HSM oder Ihre eigene Hardware verwenden.
Sectigo (Comodo) bietet mehrjährige Zertifikate bis zu 3 Jahren an, allerdings mit strengeren Regeln. Wenn Sie sich für ein 2- oder 3-Jahres-Zertifikat entscheiden, müssen Sie Ihr eigenes HSM verwenden. Von CA zur Verfügung gestellte Hardware ist nur für 1-Jahres-Bestellungen verfügbar.
Sie möchten Code signieren? Sie brauchen den Token. Ohne Token keine Signierung – selbst wenn jemand Ihr gesamtes Netzwerk kompromittiert.
Implementierung strenger Zugriffskontrollen für Code Signing Keys
Nicht jeder in Ihrem Team braucht Zugang zu den Signierschlüsseln der Produktion. Tatsächlich sollten die meisten Leute ihn nicht haben.
Das Prinzip ist einfach: Weniger Personen mit Zugriffsrechten bedeuten weniger Angriffsvektoren. Richten Sie eine rollenbasierte Zugriffskontrolle (RBAC) ein, die Signierberechtigungen auf bestimmte Rollen beschränkt. Ihr QA-Team braucht keinen Produktionssignaturzugriff. Ihre Nachwuchsentwickler wahrscheinlich auch nicht.
Erstellen Sie Genehmigungs-Workflows, die mehrere Signaturen für Produktionsversionen erfordern. Eine Person reicht den Code zum Signieren ein, eine andere genehmigt ihn, und erst dann erfolgt die eigentliche Signierung. Diese Aufgabentrennung fängt Fehler ab und verhindert Insider-Bedrohungen.
Führen Sie umfassende Prüfprotokolle. Halten Sie fest, wer was wann und von welchem System aus signiert hat. Im Whitepaper Code Signing Best Practices des CA Security Council wird betont, dass eine detaillierte Protokollierung für die Reaktion auf Vorfälle und forensische Untersuchungen unerlässlich ist. Wenn etwas schief läuft – und das tut es letztendlich immer – müssen Sie genau wissen, was passiert ist.
Auch die physische Sicherheit ist wichtig:
- Lassen Sie keine USB-Tokens auf den Schreibtischen liegen.
- Speichern Sie die HSM-Zugangsdaten nicht in einfachen Textdateien.
- Schreiben Sie keine PIN-Codes auf Klebezettel.
Dies klingt offensichtlich, aber es sind häufige Probleme, die ansonsten solide Sicherheit untergraben.
Zeitstempel für Ihren Code während des Signiervorgangs
Es gibt ein Problem: Code Signing-Zertifikate laufen ab, in der Regel nach ein bis drei Jahren. Ohne Zeitstempel wird Ihre Signatur ungültig, wenn Ihr Zertifikat abläuft. Die Benutzer sehen dann Warnmeldungen über nicht vertrauenswürdige Software, obwohl sich an Ihrem Code nichts geändert hat.
Das Zeitstempeln behebt dieses Problem, indem ein vertrauenswürdiger Zeitstempel vom Zeitstempelserver einer Zertifizierungsstelle während des Signiervorgangs hinzugefügt wird. Dieser Zeitstempel beweist, dass Sie den Code signiert haben, als Ihr Zertifikat noch gültig war. Die Signatur bleibt auch dann vertrauenswürdig, wenn Ihr Zertifikat abläuft oder widerrufen wird.
Stellen Sie sich das wie einen Notarstempel mit einem Datum vor. Der Notar könnte in den Ruhestand gehen oder sein Geschäft schließen, aber sein Stempel auf Ihrem Dokument aus dem Jahr 2020 beweist immer noch, dass das Dokument im Jahr 2020 existierte und überprüft wurde.
Der technische Prozess ist einfach. Während des Signierens kontaktiert Ihr Tool einen Zeitstempel-Server, der von Ihrer Zertifizierungsstelle betrieben wird. Der Server gibt einen signierten Zeitstempel zurück, der in die Signatur Ihres Codes eingebettet wird. Wenn Benutzer Ihre Signatur auf einer beliebigen Plattform – Windows, macOS, Linux, iOS oder Android – überprüfen, werden sowohl Ihr Signierzertifikat als auch der Zeitstempel überprüft. Durch diesen Überprüfungsprozess bleibt die Integrität des Codes über die Zeit erhalten, auch wenn Zertifikate ablaufen und sich Sicherheitsstandards weiterentwickeln.
Das spart auch Geld. Ohne Zeitstempel müssten Sie Ihre gesamte verteilte Software jedes Mal neu signieren, wenn Sie Ihr Zertifikat erneuern. Mit Zeitstempeln bleiben alte Versionen auf unbestimmte Zeit vertrauenswürdig.
Sparen Sie 10% auf SSL-Zertifikate, wenn Sie heute bei SSL Dragon bestellen!
Schnelle Ausgabe, starke Verschlüsselung, 99,99% Browservertrauen, engagierter Support und 25 Tage Geld-zurück-Garantie. Coupon-Code: SAVE10
Trennen Sie die Test-Signatur von der Freigabe-Signatur-Umgebung
Ihre Testumgebung sollte nicht die gleichen Signierschlüssel wie die Produktionsumgebung verwenden. Niemals.
Testzertifikate sollten entweder selbst signiert oder von einer internen Testzertifizierungsstelle ausgestellt werden, die auf eine andere Stammzertifizierungsstelle verweist als Ihre Produktionszertifikate. Diese architektonische Trennung verhindert, dass test-signierter Code fälschlicherweise für releasefähige Software gehalten wird.
Richten Sie für jede Umgebung eine eigene Signierinfrastruktur ein. Ihre Test-Signierung kann zugänglicher und weniger restriktiv sein – die Entwickler müssen schnell iterieren. Aber die Signierung in der Produktionsumgebung sollte mit all den Sicherheitsmaßnahmen, die wir besprochen haben, fest verschlossen sein.
Kennzeichnen Sie Testpakete deutlich. Fügen Sie „TEST“ oder „BETA“ in die Dateinamen ein. Verwenden Sie unterschiedliche Produktbezeichnungen. Machen Sie es unmöglich, versehentlich test-signierten Code an Kunden weiterzugeben.
Auch die Zugriffskontrollen sollten sich deutlich unterscheiden. Entwickler könnten direkten Zugriff auf die Testsignierung haben. Für die Produktionssignierung sollten Genehmigungsworkflows und möglicherweise ganz andere Anmeldeinformationen erforderlich sein.
Implementieren Sie Code-Authentifizierung und Integritätsprüfung vor dem Signieren
Die Code-Signierung bietet eine Code-Authentifizierung – sie bestätigt, wer die Software veröffentlicht hat. Es bestätigt nicht, dass die Software sicher ist.
Diese Unterscheidung ist wichtig, weil Sie letztendlich für alles, was Sie unterschreiben, verantwortlich sind, auch wenn Sie nicht alles geschrieben haben. Wenn Sie einen Code unterschreiben, den Sie nicht überprüft haben, ist das so, als würden Sie einen Kredit mitunterzeichnen, ohne die Finanzen des Kreditnehmers zu überprüfen.
Implementieren Sie Einreichungs- und Genehmigungsverfahren, bevor etwas unterzeichnet wird. Lassen Sie jemanden überprüfen, was signiert werden soll. Vergleichen Sie den Code auf Ihrem Build-Server mit Ihrem Quellcode-Repository. Stellen Sie sicher, dass sie genau übereinstimmen.
Die Sicherheitsverletzung bei SolarWinds hat uns gezeigt, dass Angreifer bösartigen Code in Build-Pipelines einschleusen können. Dieser Angriff hat gezeigt, wie wichtig die Sicherheit der Software-Lieferkette ist – jede Komponente, jede Abhängigkeit und jeder Build-Schritt stellt einen potenziellen Angriffsvektor dar. Wenn Sie signieren, ohne zu überprüfen, vertrauen Sie jedem Teil Ihrer Infrastruktur und jedem Stück Code aus externen Quellen. Das ist keine Wette, die Sie eingehen wollen.
Richten Sie nach Möglichkeit automatische Prüfungen ein. Überprüfen Sie digitale Signaturen von Code, den Entwickler in Ihr Repository einchecken. Führen Sie statische Analysetools aus. Erstellen Sie Prüfsummen von genehmigten Builds und überprüfen Sie diese vor dem Signieren.
Protokollieren Sie alles. Wenn jemand einen Code zum Signieren einreicht, halten Sie fest, was eingereicht wurde, wer es eingereicht hat, wer es genehmigt hat und was signiert wurde. Diese Prüfpfade sind bei der Untersuchung von Vorfällen von entscheidender Bedeutung.
Vor dem Signieren einen Virenscan des Codes durchführen
Die Codesignierung beweist, dass Sie die Software veröffentlicht haben. Die Benutzer vertrauen darauf, dass Sie keine Malware veröffentlichen, aber Code Signing-Zertifikate sind kein Beweis für Sicherheit.
Dies ist wichtig, wenn Sie Code aus externen Quellen einbinden – Open-Source-Bibliotheken, Komponenten von Drittanbietern, Beiträge von Auftragnehmern. Sie signieren das alles unter Ihrem Namen.
Scannen Sie alles, bevor Sie es signieren. Verwenden Sie nach Möglichkeit mehrere Antivirenprogramme. Suchen Sie nach bekannten Malware-Signaturen, verdächtigen Mustern und potenziellen Schwachstellen. Dies gilt unabhängig davon, ob Sie ausführbare Windows-Dateien, macOS-Anwendungen, Linux-Pakete oder mobile Anwendungen für iOS und Android vorbereiten.
Wenn Sie eine versehentliche bösartige Einfügung vor der Signierung erkennen, schützen Sie Ihre Benutzer und Ihren Ruf. Wird er entdeckt, nachdem Sie signierte Malware verteilt haben, bedeutet dies den Entzug des Zertifikats, die Benachrichtigung Ihrer Kunden und Schadensbegrenzung.
Das Scannen verlängert den Erstellungsprozess nur minimal, bietet aber einen wesentlichen Schutz für die Integrität und Authentizität des Codes. Machen Sie es obligatorisch, nicht optional.
Schlüssel rotieren und mehrere Zertifikate verwenden
Legen Sie nicht alle Eier in einen Korb. Wenn Sie ein einziges Code Signing-Zertifikat für alles verwenden, entsteht ein einziger Fehlerpunkt.
Ziehen Sie in Erwägung, verschiedene Zertifikate für verschiedene Produktlinien oder Hauptversionen zu verwenden. Wenn Sie eine Sicherheitslücke in der Verwaltung eines Zertifikats entdecken, müssen Sie nur dieses spezielle Zertifikat widerrufen. Ihre anderen Produkte bleiben vertrauenswürdig.
Das regelmäßige Wechseln der Schlüssel schränkt das Risiko ebenfalls ein. Wenn jemand Ihren Schlüssel vor sechs Monaten kompromittiert hat, Sie aber inzwischen ein neues Zertifikat verwenden, kann er keinen aktuellen Code als Sie signieren. Der Schaden beschränkt sich auf ältere Versionen.
Einige Unternehmen weisen verschiedenen DevOps-Teams oder Versionszweigen eindeutige Zertifikate zu. Dadurch wird das Risiko verteilt und die Untersuchung von Kompromissen erleichtert. Wenn etwas schief geht, wissen Sie genau, welches Zertifikat beteiligt war und welche Versionen betroffen sind.
Stellen Sie einen Rotationsplan auf, der ein Gleichgewicht zwischen Sicherheit und operativem Aufwand herstellt. Eine jährliche oder halbjährliche Rotation ist für viele Unternehmen geeignet. In hochsicheren Umgebungen kann die Rotation vierteljährlich erfolgen.
Nehmen Sie den Widerruf von Zertifikaten ernst
Die Sperrung von Zertifikaten ist die nukleare Option, aber manchmal ist sie notwendig.
Widerrufen Sie sofort, wenn Ihr privater Schlüssel kompromittiert wird. Warten Sie nicht, bis Sie den Schaden abschätzen können. Hoffen Sie nicht, dass niemand etwas bemerkt. Widerrufen Sie, benachrichtigen Sie Ihre Zertifizierungsstelle und beginnen Sie mit der Eindämmung.
Der Widerruf betrifft den gesamten mit diesem Zertifikat signierten Code. Die Benutzer erhalten Warnungen. Automatisierte Systeme könnten die Installation blockieren. Aus diesem Grund ist der Zeitstempel so wichtig – er begrenzt den Schaden auf Code, der nach dem Zeitstempel, aber vor dem Widerruf signiert wurde.
Verfolgen Sie Ihre Zertifikate innerhalb Ihrer PKI-Infrastruktur sorgfältig. Sie wissen, wo sie sind, wer Zugriff hat, wann sie ablaufen und welchen Code sie signiert haben. Die Verwaltung des Lebenszyklus von Zertifikaten wird entscheidend, wenn Sie Ihr Unternehmen vergrößern.
Melden Sie Kompromittierungen Ihrer Zertifizierungsstelle gemäß deren Verfahren. Sie helfen Ihnen bei der Sperrung und haben möglicherweise Hinweise zu den Meldepflichten.
Wenn Sie einen Widerrufsplan haben, bevor Sie ihn brauchen, ist der Prozess weniger chaotisch. Dokumentieren Sie die Schritte, weisen Sie Verantwortlichkeiten zu und üben Sie das Verfahren.
Nutzen Sie Extended Validation Code Signing-Zertifikate
Extended Validation (EV) Code Signing-Zertifikate sind digitale X.509-Zertifikate, die eine höhere Sicherheit als Standardzertifikate bieten. Die Zertifizierungsstelle führt eine strengere Identitätsprüfung durch, bevor sie sie ausstellt.
EV-Zertifikate erfordern einen Hardwarespeicher, der den Standards von FIPS 140-2 Level 2 oder höher entspricht. Sie können kein EV-Zertifikat erhalten und es auf Ihrer Festplatte speichern. Dieser obligatorische Hardwareschutz verringert das Risiko einer Schlüsselkompromittierung.
Die meisten EV-Zertifikate werden auf USB-Tokens mit PIN-Schutz geliefert. Sie benötigen sowohl den physischen Token als auch die PIN, um den Code zu signieren. Dieser Zwei-Faktoren-Ansatz erschwert die unbefugte Unterzeichnung.
Forschungen des Georgia Tech Cyber Forensics Innovation Lab haben ergeben, dass EV-signierte ausführbare Dateien 99,99 % der getesteten Phishing-Angriffe widerstanden, verglichen mit 90 % bei Standardsignaturen. Betriebssysteme wie Windows, macOS und mobile Plattformen wie iOS und Android erkennen EV-Signaturen und zeigen den Benutzern erweiterte Vertrauensindikatoren an. Die verbesserten Vertrauensindikatoren und die strenge Überprüfung machen einen messbaren Unterschied.
Wählen Sie EV-Zertifikate wenn Sie ein Höchstmaß an Vertrauen benötigen – Flaggschiffprodukte, weit verbreitete Software oder Anwendungen, die sensible Daten verarbeiten. Die zusätzlichen Kosten und der Verwaltungsaufwand machen sich durch erhöhte Glaubwürdigkeit und Sicherheit bezahlt.
Automatisieren und zentralisieren Sie die Verwaltung von Code Signing
Die manuelle Verwaltung von Zertifikaten lässt sich in DevOps-Umgebungen, in denen mehrere Teams kontinuierlich Code veröffentlichen, nicht skalieren.
Lösungen für die Verwaltung des Lebenszyklus von Zertifikaten (CLM) zentralisieren die Kontrolle und integrieren sich gleichzeitig in CI/CD-Pipelines. Plattformen wie Sectigo Certificate Manager und AppViewX CERT+ bieten CLM-Funktionen auf Unternehmensniveau, die speziell für Code Signing Workflows entwickelt wurden. Entwickler erhalten einen Self-Service-Zugang zur Erstellung digitaler Signaturen ohne direkten Schlüsselzugriff. Sicherheitsteams behalten den Überblick und setzen Richtlinien für alle Signieraktivitäten durch.
Diese Plattformen verfolgen den Zertifikatsbestand, das Ablaufdatum und die Nutzungsmuster. Eine zentrale Verwaltung ist für die Sicherheit der Software-Lieferkette unerlässlich, insbesondere wenn mehrere Teams und Auftragnehmer zu Ihrer Codebasis beitragen. Sie automatisieren die Erneuerung von Zertifikaten und machen Audits einfach. Wenn Sie wissen müssen, was mit welchem Zertifikat signiert wurde, haben Sie die Informationen zur Hand.
Die Integration mit Build-Systemen bedeutet, dass sich die Entwickler keine Gedanken über Zertifikatsdetails machen müssen. Sie übermitteln den Code, die Pipeline übernimmt automatisch die Signierung mit dem entsprechenden Zertifikat, und am anderen Ende kommt das signierte Artefakt heraus.
Vordefinierte Workflows setzen Ihre Sicherheitsrichtlinien durch. Code kann ohne Genehmigung nicht signiert werden. Testzertifikate können nicht für die Produktion verwendet werden. Entwickler in einer Geschäftseinheit können nicht auf die Signierschlüssel einer anderen Einheit zugreifen.
Die Zentralisierung vereinfacht die Sicherheit, ohne den Entwicklern das Leben schwer zu machen. Das ist das Gleichgewicht, das Sie brauchen – starke Sicherheit, die mit Ihrem Entwicklungsprozess zusammenarbeitet, nicht gegen ihn.
Sichern Sie Ihre Software-Lieferkette mit SSL Dragon
SSL Dragon bietet Code Signing-Zertifikate von führenden Zertifizierungsstellen wie DigiCert und Sectigo. Ob Sie nun Standard Code Signing für interne Anwendungen oder EV-Zertifikate für weit verbreitete Software benötigen, wir helfen Ihnen bei der Auswahl der richtigen Lösung.
Unser Team kennt die Sicherheitsherausforderungen, mit denen Softwareentwickler konfrontiert sind. Wir können Sie bei der Auswahl, Implementierung und Verwaltung von Zertifikaten unterstützen, um sicherzustellen, dass Ihre Code Signing-Infrastruktur den besten Praktiken der Branche entspricht.
Informieren Sie sich über die Code Signing-Zertifikate von SSL Dragon oder kontaktieren Sie unser Team, um zu besprechen, welche Lösung am besten zu Ihren Softwareentwicklungs- und Sicherheitsanforderungen passt. Schützen Sie Ihre Software-Lieferkette – Ihre Benutzer verlassen sich darauf.
Sparen Sie 10% auf SSL-Zertifikate, wenn Sie noch heute bestellen!
Schnelle Ausstellung, starke Verschlüsselung, 99,99% Browser-Vertrauen, engagierter Support und 25-tägige Geld-zurück-Garantie. Gutscheincode: SAVE10
