Azure DevOps är en kraftfull molnbaserad plattform som integrerar människor, processer och verktyg för att effektivisera programvaruutveckling och möjliggöra sömlöst samarbete genom hela utvecklingscykeln. Från idé till distribution och därefter erbjuder Azure DevOps ett komplett utbud av tjänster som täcker hela programvaruutvecklingscykeln. Den samlar kraftfulla tekniker som Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans och Azure Artifacts för att stärka utvecklingsteam och låta dem uppnå en snabbare time-to-market, högre produktivitet och högre kundnöjdhet. Genom att integrera Azure i sina CI/CD-arbetsflöden kan organisationer accelerera programvaruleverans, förbättra samarbetet och upprätthålla höga kvalitetsstandarder genom hela utvecklingscykeln.
Kodsignering
Kodsignering är en procedur som verifierar författarens legitimitet och originaliteten och äktheten hos digital information, särskilt programkod. Det säkerställer också att informationen inte är skadlig kod. Dessutom garanterar det att denna information inte har ändrats, förfalskats eller annullerats efter att den signerats digitalt . Den digitala signaturen skapas med en privat nyckel som endast är tillgänglig för programvaruutgivaren. När programvaran laddas ner och installeras kontrolleras den digitala signaturen mot den publika nyckeln för att bekräfta att den matchar och att programvaran inte har modifierats. Kodsignering är viktigt för att säkerställa säkerheten för programvaruapplikationer, eftersom det hjälper till att förhindra spridning av skadlig kod och annan skadlig programvara.
Integrering av Azure DevOps med kodsignering, kort sagt: registrera en självhostad agent med SignTool och KSP-klienten installerad, kör agentens tjänst under ett dedikerat konto med låg behörighet (inte administratör), autentisera med en personlig åtkomsttoken med snävt omfång och lägg sedan till ett pipeline-skriptsteg som anropar signtool mot det KSP-registrerade certifikatet. Den privata nyckeln finns kvar i HSM hela tiden.
Key Takeaways
- Varken agentens tjänstkonto eller den personliga åtkomsttoken behöver breda eller fullständiga åtkomstbehörigheter. Ange PAT:n till agentpooler (läs och hantera) och ge tjänstkontot endast den specifika behörighet som KSP kräver.
- Den här sidan behandlar Azure DevOps specifikt som en plattformshandledning. För den bredare referensarkitekturen, godkännandegrindar och revisionsbevismodellen, se Bästa praxis för kodsignering i SDLC.
Encryption Consulting har en kodsigneringslösning, ” CodeSign Secure ”, som kan hjälpa dig med manipulationssäker förvaring av nycklar och fullständig insyn och kontroll över kodsigneringsaktiviteter . De privata nycklarna till kodsigneringscertifikatet kan lagras i en HSM för att eliminera riskerna med stulna, skadade eller missbrukade nycklar.
Integration av Azure DevOps för samdesign
För att komma igång med detta behöver du först ett Azure-konto och ett system där du har signtool och ECSigningKSP installerade och konfigurerade. Lista ner förutsättningarna.
- Ett system som har ECSigning KSP, Signtool installerat och konfigurerat. Agentens tjänstkonto behöver den specifika behörighet som KSP kräver för att autentisera och få åtkomst till certifikatsökvägen, inte fullständiga administratörsbehörigheter.
- Azure-konto.
För att konfigurera ECSigningKSP och Signtool, följ följande steg:
Ladda ner Windows SDK: ( developer.microsoft.com/en-us/windows/downloads/windows-10-sdk/ )
Du kan välja att endast installera Windows SDK-signeringsverktygen för skrivbordsappar.
Öppna filen winsdksetup.exe. Kom ihåg standardsökvägen som visas i installationssökvägen, eftersom det kommer att vara till hjälp när du kör dessa kommandon från kommandotolken.
På sidan Sekretess för Windows Kits är båda alternativen för att tillåta Microsoft att samla in insikter okej. Klicka på Nästa.
Acceptera licensavtalet
Avmarkera alla funktioner utom Windows SDK-signeringsverktyg för skrivbordsappar och välj sedan installera.
När du tillfrågas om du vill tillåta att den här appen gör ändringar väljer du ja.
Klicka på Windows sökfält i aktivitetsfältet och skriv "Redigera systemmiljövariablerna" och välj alternativet med samma namn på kontrollpanelen.
Klicka på miljövariabler.
Innan du redigerar variabellistan, navigera till den plats där Windows SDK är installerat med hjälp av Utforskaren. Du måste kopiera sökvägen till mappen som innehåller signtool-programmet. Standardsökvägen är C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64, se skärmdumpen nedan. Se till att högerklicka och kopiera sökvägen som visas. Du kan också se signtool-programmet längst ner i fillistan, det är detta kommando du kommer att köra.
I listan Systemvariabler klickar du på ny. Skriv sedan Sökväg som variabelnamn och kopiera och klistra in den ovannämnda sökvägen. Klicka sedan på OK i fönstret för miljövariabler och systemegenskaper.
För att testa installationen, öppna kommandotolken och skriv signtool, så bör utdata vara som visas nedan.
Standardinstallationsplatsen för signtool är till exempel: C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64
För att konfigurera KSP, följ stegen nedan:
Om du använder vår lösning kan du ladda ner KSP med hjälp av stegen nedan:
- Logga in Kodsignera säkert.
-
Navigera till: Arkiv för signeringsverktyg.
- Ladda ner “Krypteringskonsulting CNG-SigningKSP”
-
Installera klientverktygen med hjälp av .MSI-installationsprogrammet. .MSI-installationsprogrammet automatiserar mycket av konfigurationen. Navigera till var den nedladdade filen är sparad och starta installationsprogrammet.
-
Klicka på Nästa när installationsguiden visas.
-
Klicka på nästa.
- I Användarnamn fält, skriv admin.
-
I fältet Kod kopierar du koden från Postman API Repository . Klicka på GetLoginToken API och kopiera koden från brödtexten.
Ladda ner PostMan från den här länken . När nedladdningen är klar klickar du på knappen "hoppa över" längst ner i fönstret. Lägg till en ny samling med hjälp av plustecknet bredvid "samlingar" på instrumentpanelen.
GetLoginToken API (http://codesignsecureapi.encryptionconsulting.com/api/auth/GetLoginToken): Detta är det viktigaste API:et, eftersom det ger dig en Bearer-token att använda med resten av API:erna. Vad som ska finnas i texten visas nedan. Koden fungerar som ett lösenord för att få en Bearer-token, användarfältet är användarnamnet och identitetstypfältet anger användartypen. Klicka på Skicka för att generera en utdata som har Bearer-token listad längst ner. Kopiera denna token för användning.
- Ändra Identitet Typ till 1.
- Lämna API-basURL det samma.
-
Klicka på nästa.
-
Klicka på nästa.
-
Du får då ett meddelande om att programmet kommer att göra ändringar på din dator, klicka på ja.
-
Installationen är nu klar.
Följ stegen nedan för att konfigurera med Azure Devops:
- Navigera till dev.azure.com och logga in med ditt Microsoft-konto eller så kan du börja gratis med ditt GitHub-konto också.
-
Ange detaljerna enligt anvisningarna
- Du kommer att bli ombedd att skapa en organisation om du inte redan har gjort det. Skapa en organisation och kom igång med projektet.
-
Om du redan har ett projekt där du vill bygga pipelinen, navigera till pipelines. Om inte, skapa ett enkelt projekt först. Ange nödvändig information för att fortsätta.
-
När ett projekt har skapats, navigera till användarinställningarna längst upp till vänster på skärmen och klicka på personlig åtkomsttoken. På nästa sida klickar du på "Ny token". I dialogrutan som visas anger du nödvändig information, såsom namn på token, organisationsnamn (den organisation du skapade/åtkom tidigare). Ställ in utgångsdatum och omfattning. Avgränsa token till vad agentregistreringen faktiskt behöver, vanligtvis agentpooler (läs och hantera), snarare än fullständig åtkomst; en fullständig åtkomsttoken som används för detta ändamål är en bredare autentiseringsuppgift än vad uppgiften kräver och en större förlust om den läcker.
Klicka på skapa och kopiera token någonstans eftersom du inte kommer att kunna se token igen.
-
När vi är klara med att hämta en token behöver vi konfigurera en självhostad runner. Det här är en maskin där Signtool och ECSigningKSP är installerade och konfigurerade. För att göra det, gå tillbaka till sidan Kodsammanfattning och längst ner till höger på skärmen ser du Projektinställningar, klicka på den.
Under Pipelines ser du Agentpooler. Klicka på den och klicka sedan på standard.
Klicka på ny agent längst upp till vänster.
Hämta agenten enligt ditt operativsystem. Jag fortsätter med Windows. Ladda ner agenten, extrahera den till mappen "C:\agents".
Du kan också följa den här dokumentationen för mer hjälp om detta
-
När du har extraherat filerna, navigera till mappen där du extraherade dem från cmd och kör .\config.cmd.
Nu kommer server-URL:en att vara https://dev.azure.com/<ditt_organisationsnamn. Tryck bara på Enter för PAT på autentiseringstypen och ange den token som kopierades tidigare på nästa fråga.
När agenten är registrerad, för Agent Pool, eftersom vi har den som standard, tryck på Enter. Om du vill ge din agent något namn kan du namnge dem men tryck på Enter för att den ska namnges som KLIENT.
När agenten har lagts till kan du lämna arbetsmappen som standard eller ändra den efter eget tycke. För att köra agent som en tjänst, ange J som i ja. För att användarkontot ska användas för tjänsten, använd ett dedikerat tjänstkonto med låg behörighet istället för administratör . Det här kontot behöver bara den specifika behörighet som KSP kräver för att autentisera och få åtkomst till certifikatsökvägen som refereras till i pipelinen, inte fullständiga administratörsrättigheter. Att behandla ett signeringsbehörighetsfel som en anledning att bevilja administratör är en undvikbar överträdelse av minsta behörighet. Ange lösenordet för det dedikerade kontot.
Eftersom vi har ställt in detta som en tjänst kommer agenten att köras automatiskt. Om vi inte hade ställt in detta som en tjänst skulle vi behöva köra agenten manuellt.
Navigera till services.msc och scrolla ner till Azure Pipeline Agent för att bekräfta vilket konto det är inställt att logga in som. Om det för närvarande är inställt på Administratör, ändra det till ditt dedikerade tjänstkonto med låg behörighet istället, och ge det kontot endast den snäva behörighet som KSP kräver. En dialogruta visas när du klickar på logga in där du kan uppdatera kontot och ange dess lösenord, sedan starta om tjänsten. När detta är klart, gå tillbaka till Azure DevOps för att bygga pipelinen.
-
Klicka på pipelines för att komma igång.
Klicka på Skapa pipeline på följande sida.
-
På nästa sida, i avsnittet Anslut, välj var din kod finns. Här finns min kod i GitHub och jag fortsätter med det. Du behöver administratörsbehörighet för ditt repository för att ge åtkomst.
-
Välj det arkiv där du har din kod.
-
Om du inte redan har .yml-filen i ditt repository klickar du på Starter Pipeline i konfigurationsavsnittet. Om du har det klickar du på Existing Azure Pipeline. För startpipelinen kan du behöva skapa en ny gren eller commit på själva huvudgrenen, det är ditt val.
-
Skriv följande skript i editorn
trigger:
- <your_branch_name>
pool:
name: <your_pool_name> #In this documentation it’s set as Default
variables:
varible_name: variable_value
steps:
- script: |
signtool sign /csp "Encryption Consulting Key Storage provider" /kc <Key_name> /fd <hashing algorithm> /f <certificate location> /tr <time stamping server> /td SHA256 <file path>
Var vänlig ersätt variablerna som anges under <variabelnamn> . En kort beskrivning av den förväntade variabeln ges nedan.
<nyckelnamn>: Detta hänvisar till den kryptografiska nyckel som används för att signera koden. Exempel – evcodesigning
<hashingalgoritm> : Du måste ange namnet på hashingalgoritmen, till exempel SHA256, SHA384 eller SHA512. Det måste vara ett av dessa tre värden.
<certifikatplats> : Ett exempel på vad som kan anges i det här fältet är C:\testing.pem. Certifikatets .pem -fil MÅSTE inkluderas i denna inmatning. Du kan generera en pem-fil av certifikatet för samdesign, om du har nyckelnamnet med hjälp av ECSigningKSP. Följ kommandona nedan för att göra det:
På den enhet där du har ECSigningKSP installerat och konfigurerat, navigera till mappen för ECSigningKSP, som vanligtvis finns i "C:\Program Files\Encryption Consulting\SigningKSP".
I kommandotolken, gå till den här katalogen.
Använd sedan följande kommando för att hämta pem-filen för certifikatet.
ECGetCert.exe <Nyckelnamn> (exempel: ECGetCert.exe evcodesigning)
Ange platsen för det sparade certifikatet.
<tidsstämpelserver>: En tidsstämpelserver tillhandahåller bevis på att en digital signatur utfördes vid en viss tidpunkt , vilket möjliggör verifiering i framtiden att en fil signerades vid en viss tidpunkt. Den vi vanligtvis använder är http://timestamp.digicert.com
<sökväg> : Här anger du sökvägen till den fil som du vill signera. Exempel C:\<Mappnamn>\<Filnamn>. Se till att du har angett ett filnamn med rätt filändelse.
Mitt manus var:
trigger:
- azure-pipelines1
pool:
name: Default
variables:
EC_Client_Auth: C:\Users\riley\Documents\EncryptionConsulting\testClient.pfx
steps:
- script: |
signtool sign /csp "Encryption Consulting Key Storage provider" /kc evcodesigning /fd SHA256 /f
C:\\Users\\Administrator\\Desktop\\ForTesting\\evcodesigning.pem /tr http://timestamp.digicert.com /td SHA256
C:\\Users\\Administrator\\Desktop\\ForTesting\\AgentService.exe
När du klickar på spara och kör får du upp en branch-tagg. Se till att namnet som anges här och under triggern i skriptet är samma innan du kör skriptet.
När bygget har slutförts ser du att din fil har signerats.
Verifiering och felhantering
Betrakta inte en lyckad pipeline-körning som bevis på att signaturen är giltig. Lägg till ett skriptsteg omedelbart efter signering som körs. signtool verify /pa mot den signerade filen och misslyckas med bygget om verifieringen inte returnerar lyckat resultat. Om själva signeringssteget misslyckas, kontrollera tabellen nedan innan du antar att certifikatet är ogiltigt.
Vanliga fel
| Fel | Troligtvis orsak | Fast |
|---|---|---|
| Inga certifikat hittades som uppfyllde alla angivna kriterier | Nyckelnamnet (/kc) matchar inte en registrerad KSP-nyckel, eller så är KSP-klienten inte autentiserad på agenten. | Bekräfta det exakta nyckelnamnet och kontrollera KSP:ns autentiseringsstatus igen oberoende av pipelinen. |
| Åtkomst nekad | Agentens servicekonto saknar den specifika behörighet som KSP behöver (inte en anledning att byta till administratör) | Bevilja den snäva behörighet som KSP-dokumentationen anger för klientautentisering |
| TF400813 eller liknande auktoriseringsfel vid anslutning till Azure DevOps | Den personliga åtkomsttoken har gått ut eller saknar agentpoolernas omfattning. | Återskapa PAT med agentpoolernas omfattning (läs och hantera) istället för att utöka den till fullständig åtkomst. |
Vanliga frågor om partihandel med mat och dryck
Behöver Azure Pipelines agent-tjänstkontot administratörsrättigheter?
Nej. Den behöver den specifika behörighet som KSP kräver för att autentisera och få åtkomst till certifikatsökvägen som används i pipelinen, inte fullständiga administratörsrättigheter. Att behandla ett behörighetsfel som en anledning att bevilja administratörsrättigheter är en undvikbar kränkning av minsta behörighet.
Ska den personliga åtkomsttoken som används för agentregistrering ha fullständig åtkomst?
Nej. Omfånga det till agentpooler (läs och hantera), vilket är vad agentregistrering faktiskt kräver. En token med fullständig åtkomst är en bredare autentiseringsuppgift än vad uppgiften behöver och en större förlust om den läcker.
Slutsats
Artikeln ovan demonstrerar processen för att integrera din Azure Devops CI/CD-pipeline med codesigning. Det är en mycket enkel process eftersom du bara behöver konfigurera en runner, ansluta den till ett Azure Devops-konto och bygga pipelinen för att köra jobbet. Codesigning är avgörande i dagens läge då skadlig programvara och filer fortsätter att växa. Kodsignering skapar förtroende mellan programvaruutgivare och slutanvändare och försäkrar dem om att koden inte har komprometterats eller ändrats. Du kan kontakta oss på [email protected] för hjälp med vår kodsigneringslösning.
