¶ºÒõ¹Ý

  1. FAQ
  2. Vertrouwen in codeondertekening
  3. Wat zijn best practices voor codeondertekening?
FAQ Hero
Vertrouwen in codeondertekening

Wat zijn best practices
voor codeondertekening?

Wat zijn best practices voor codeondertekening?

Met codeondertekening wordt de identiteit van de softwareontwikkelaar of -uitgever geverifieerd, om te bevestigen dat de integriteit van de code in stand is gebleven vanaf het moment van ondertekening totdat deze werd gedownload. Dit bewijst dat de software kan worden vertrouwd. Helaas proberen kwaadwilligen doorlopend de codeondertekening te doorbreken om vervolgens malware in vertrouwde code te verbergen.

Hier volgen enkele best practices voor het verkleinen van de risico's:

  • Veilige sleutelopslag: Als de persoonlijke sleutel is gecompromitteerd of wordt gestolen van een organisatie, kan die worden gebruikt om software met malware te ondertekenen, zodat de gepubliceerde software afkomstig van die organisatie als legitiem wordt aangeduid. Persoonlijke sleutels moeten worden beveiligd in een HSM (Hardware Secure Module) of worden versleuteld op fysieke media. Volgens de voorschriften van het CA/B Forum moeten sleutels voor openbaar vertrouwen worden opgeslagen in een HSM.
  • Toegangscontroles voor sleutels en ondertekening handhaven: Stel beleidsregels op en gebruik toegangscontroles om ervoor te zorgen dat alleen ontwikkelaars en geautoriseerde gebruikers kunnen ondertekenen met specifieke sleutels wanneer dat nodig is. Genereer sleutels in de cloud zodat ze niet kunnen worden gedeeld of gestolen. Dwing scheiding van taken af door de verantwoordelijkheden van degenen die sleutels genereren te scheiden van de verantwoordelijkheden van degenen die ondertekenen. Implementeer meervoudige authenticatie (MFA) om te waarborgen dat de persoon die gaat ondertekenen ook echt is wie hij zegt dat hij is. Trek de toegang in van ex-medewerkers en medewerkers die niet meer hoeven te ondertekenen en geen sleutels meer hoeven te genereren.
  • Bewaak en audit workflows voor ondertekening met sleutels: Houd bij wie wat wanneer heeft ondertekend, zodat u snel kunt reageren op ongeautoriseerde ondertekeningen en herstelacties kunt ondernemen. Houd regelmatig audits voor activiteiten met betrekking tot sleutelparen, zoals het maken ervan, handelingen met certificaten en het toekennen van toegang tot sleutels en ondertekening.
  • Blijf op de hoogte en handhaaf organisatiebrede beleidsregels voor cryptografische normen: Branchevoorschriften kunnen nuttig zijn voor organisaties om het toenemende aantal bedreigingen bij te benen. Het CA/B Forum schrijft tegenwoordig 3072-bits RSA voor als minimale eis voor sleutels die worden gebruikt voor openbaar vertrouwde codeondertekening en tijdstempels voor certificaten. Deze vereiste is sinds 1 juni 2021 van kracht. Ontwikkelaars en gebruikers binnen een organisatie zijn mogelijk niet op de hoogte van de veranderingen bij het genereren van sleutels of ondertekenen van code. Daarom moeten organisaties de branchevoorschriften handhaven om te voorkomen dat gebruikers sleutels genereren of certificaten aanvragen die niet aan de voorschriften voldoen en zijn gebaseerd op zwakke algoritmen, sleutelgrootten of krommen.
  • Gebruik automatische codeondertekening in softwareontwikkelingsprocessen: Integreer en automatiseer ondertekening in softwareontwikkelingsprocessen zoals CI/CD-pipelines voor beperking van het risico van niet-ondertekende code of ondertekening die niet aan de voorschriften voldoet. Tegelijk met de automatisering kunt u beveiligingscontroles opzetten om te garanderen dat uw software veilig en compliant is, ook wanneer de ontwikkeling daarvan doorlopend en snel plaatsvindt.
  • Vergelijk handtekeningen van verschillende build-servers: Recente aanvallen op de software-supplychain hebben geleid tot langdurige operationele onderbrekingen en hoge kosten bij toonaangevende organisaties over de hele wereld. Hackers infiltreren de ontwikkelactiviteiten bij het doelwit en voegen malware toe aan de code. Met de release van die gemanipuleerde code komt de malware ook in de systemen van klanten terecht. Onderteken de software en vergelijk de hashes van verschillende build-servers voorafgaand aan de release, om te controleren of de verschillende server-builds afwijkingen vertonen. Als er minimaal twee builds identiek zijn, kan dat de garantie bieden dat de builds veilig zijn en er geen onbekende code is toegevoegd.
  • Trek gecompromitteerde certificaten in: Als u ontdekt dat sleutels zijn gecompromitteerd of malware is ondertekend, moet u dat melden aan uw certificeringsinstantie. Het codeondertekeningscertificaat wordt dan ingetrokken, waarmee de software als ongeldig wordt aangemerkt en de verspreiding van malware wordt gestopt.
  • Voorzie uw ondertekende code van een tijdstempel: Vermijd het onverwacht verlopen van software bij het verlopen van het codeondertekeningscertificaat. Codeondertekeningscertificaten zijn 1 tot 3 jaar geldig. Wanneer zo'n certificaat verloopt, verloopt ook de geldigheid van de software, tenzij die bij de ondertekening van een tijdstempel is voorzien. Het systeem registreert het tijdstempel, en de software blijft geldig zolang deze in productie is. Een andere reden om uw code van een tijdstempel te voorzien, is het beperken van de gevolgen van het intrekken van een certificaat. Als er malware is gevonden en het bijbehorende certificaat moet worden ingetrokken, blijven de gevolgen daarvan dankzij een tijdstempel beperkt, omdat de intrekking alleen geldt voor software die is gepubliceerd na de datum waarop die is gecompromitteerd.

  • ¶ºÒõ¹Ý Logo

    De meestvertrouwde wereldwijde leverancier oplossingen op het gebied van TLS/SSL, PKI, IoT en ondertekening.Ìý