A kódaláírás helyzete 2023-ban – Második rész

Az előző fejezetben ott hagytuk abba, hogy sikerült kiválasztanunk az ideális store-t a tanúsítványunknak. Hogy a tanúsítvány hogyan jut el a vaultba, hogy tudjuk használni a tanúsítványt és a használatról milyen audit adatokat találhatunk, erre keressük a válaszokat ebben a fejezetben. 

Azure Key Vault használata, CSR generálás és merge 

Az Azure Key Vault erőforrás menedzselhető CLI, SDK és az Azure Portal alól is. A könnyebb prezentálhatóság végett a továbbiakban a portálon történő használat kerül bemutatásra. Az Azure portálon a Key Vault service alatt tudunk új Key Vault resource-t létrehozni. Fontos, hogy pricing tier esetén a prémium legyen kiválasztva, mivel ez biztosítja a HSM alapú lehetőséget. 

Azure Key Vault létrehozása a portálról
Azure Key Vault létrehozása a portálról

Networking alatt beállíthatjuk, hogy bárhonnan elérhető legyen, korlátozhatjuk a publikus elérést adott IP cím és CIDR tartományra, illetve tilthatjuk teljesen a publikus elérést. Privát elérésre is lehetőségünk van, ilyen esetben választhajuk a virtual network access-t, ilyenkor service endpointal a teljes network elérheti privát módon, a publikus internet nélkül is, illetve választhatjuk a private endpoint lehetőséget is, ilyenkor az adott virtual network alatti kiválasztott subnet-ben egy network interface card(NIC) kerül létrehozásra emellett erre a NIC-re egy privát dns cím is beregisztrálásra kerül, ennek segítségével teljes kontrolt kapunk a KV elérhetőségének szabályozására. Az erőforrást elláthatjuk tagekkel is, ezek segítségével kulcs érték párokban tárolhatunk adatokat, pl milyen környezethez tartozik a resource. A létrehozás után a KV használatba is vehető. A létrehozott resource-t megnyitva a Certificates opciót választva vehetünk fel és importálhatunk új tanúsítványt. 

CSR generálás 

Jelen esetben generálunk kell egy Code Signing Request (CSR) fájlt, amelyet csatolhatunk a tanúsítvány igénylése mellé. A generálást az alább látható módon szükséges megtenni.  

CSR generálása a portálon
CSR generálása a portálon

Megadjuk a tanúsítvány nevét, amelyen elérjük a későbbiekben a KV-n belül. CA esetén fontos, hogy a Non integrated CA-t válasszuk, mivel külső szolgáltató fogja a tanúsítványt generálni, illetve az integrated opció jelenleg csak TLS/SSL tanúsítványhoz használható. Subject mezőben megadjuk a CSR-ben megjelenő adatokat – tanúsítvány attribútumokat, illetve megadjuk, hogy hány éves lejáratú tanúsítványt fogunk használni.  

Sima TLS/SSL tanúsítvány esetén ennyi elég is lenne, viszont code signing tanúsítványhoz szükséges az advanced configuration rész kitöltése is. EKUs alatt adjuk meg sima code signing-hoz az „1.3.6.1.5.5.7.3.3” OID kódot. Ha szükségünk van lifetime signingra, adjuk meg vesszővel elválasztva még a „1.3.6.1.4.1.311.10.3.13” OID kódot is. Fontos, ha nem tudod mi a lifetime signing és nincs rá szükséged akkor NE add meg, mivel a tanúsítvány lejárta után az ilyen típusú tanúsítvánnyal aláírt kód/szoftver nem megbízhatónak lesz jelezve!  

Innen már csak pár dolog maradt hátra. Az Exportable Private Key résznél válasszuk a No-t, mivel a tanúsítvány tárolásához kikötés, hogy a privát kulcs ne legyen kiexportálható, illetve ez az opció teszi elérhetővé a HSM kulcstípusokat. A Key Type esetén az RSA-HSM, Key Size esetén pedig a 4096 byte hosszt választjuk. Fontos, hogy létrehozás előtt az Advanced Settings résznél alul kattintsunk az OK gombra, mivel csak ekkor kerül elmentésre a most megadott extra konfiguráció.  

Ha mindezzel megvagyunk, kattintsunk a Create gombra, ezzel létre is jön a megadott nevű tanúsítványunk. Innen már csak annyi a dolgunk, hogy kiválasztjuk a létrejött tanúsítványt, azon belül az aktuális verziót, és letöltsük a CSR fájlt, amit csatolunk a tanúsítvány igénylése mellé. A tanúsítvány igénylés leadását követően az adott tanúsító hatóság keresni fog minket a folytatással kapcsolatban. Sikeres azonosítás és HSM nyilatkozat elfogadása után elérhető a fájl, amivel használatba tudjuk venni a tanúsítványt.  

Merge

A Certificate Operations alatt ahol legutóbb letöltöttük a CSR fájlt található a Merge Signed Request gomb, aminek segítségével feltölthetjük a kapott fájlt. Sikeres merge esetén a tanúsítvány használatba vehető. 

Tanúsítvány merge Key Vault-ba a portálon
Tanúsítvány merge Key Vault-ba a portálon

Jogosultságok

A KV használatához nem elég tudni az URL-t, megfelelő jogosultságra is szükségünk van. Az Azure platformon több lehetőségünk is van megfelelő identity választására attól függően honnan és mivel szeretnénk interaktálni.  

Használhatunk user alapú identity-t, ez leginkább manuális aláírás esetén lehet hasznos, mivel jó esetben egy tényleges személy végzi az aláírást, ilyen esetben szükségünk lehet az access token megszerzéséhez egy érvényes felhasználói session-re, amely MFA-t is igényelhet, így ez automatizált esetekre nem feltétlen optimális, de ad-hoc esetekre megfelelő lehet.  

User alapú identity mellett rendelkezésünkre áll még a managed identity(MI) és a service principal(SP) is. Működés szempontjából hasonlóak, a fő különbség abban található, hogy a MI beégetett credential nélküli működést tesz lehetővé az Azure-ből. MI-t hozzárendelhetünk pl. egy vagy több VM, konténer vagy pipeline-hoz is, az ezeken futó alkalmazás pedig képes automatikusan rövid élettartamú tokent igényelni. SP esetén az Azure tenant ID, az SP client id-ja és a SP-hez generált secret segítségével igényelhetünk tokent. Az SP használata akkor lehet hasznos, ha nem áll rendelkezésre natív MI megoldás mivel pl. lokális szerveren vagy VPS-en fut a scriptünk, amivel szeretnénk elérni a megfelelő Azure resource-t. 

Most, hogy már rendelkezésre áll az identity, a megfelelő jogosultság megadása van csak hátra a használathoz. KV esetén két féle módon adhatunk jogosultságot a használatra, amelyet az Access Configuration alatt tehetünk meg az adott KV resource alatt. RBAC az újabb és általános jogosultság megadás, viszont jelen használatban a másik lehetőség, a Vault access policy-t választottuk, mivel a létrehozott KV egy dedikált vault direkten kód aláírásra. A szükséges jogosultságok alább láthatóak. Felmerülhet a kérdés, ha certificate-t hoztunk létre mi szükség van key és secret jogosultságokra, de fontos tudni, hogy a certificate az csak egy wrapper az utóbbiakra, így a tanusítvány privát kulcsa a keys rész alatt kerül tárolásra – kívülről ez nyilván nem fog látszani, a felhasználó csak 1db certificate elemet fog látni. 

A szükséges jogosultságok a KV használatához
A szükséges jogosultságok a KV használatához

Kódaláírás AzureSignTool használatával

A tanúsítvány a sikeres merge után használható, jogosultságunk is van, de hogy is tudjuk használni kód aláírásra? A sima Windows signtool nem tudja kezelni ezt a fajta tanúsítványt, így más megoldásra van szükség. Lehetőségünk van a dotnet sign CLI tool használatára, vagy akár használhatjuk direktben az ezen tool által használt AzureSignTool-t is direktben. Egyedül annyi a feladatunk, hogy telepítjük a tool-t és megadjuk neki a szükséges paramétereket.  

De mik ezek a paraméterek és honnan kapjuk meg őket? – az alábbi példában SP alapú működés kerül bemutatásra 

AzureSignTool.exe sign ` 
  --file-digest sha256 ` 
  --azure-key-vault-url $keyVaultUrl ` 
  --azure-key-vault-client-id $clientId `  
  --azure-key-vault-tenant-id $tenantId ` 
  --azure-key-vault-client-secret $clientSecret ` 
  --azure-key-vault-certificate $certName ` 
  --timestamp-rfc3161 http://timestamp.digicert.com ` 
  --timestamp-digest sha256 `
  $path 

Az alábbi script powershell-ben való futtatásával aláírásra is kerül a kód/alkalmazás. Az AzureSignTool dokumentációjában részletesen megtalálhatóak a különböző identity esetén milyen paraméterek szükségesek. Jelenesetben, SP használatánál a keyvault url és az általunk megadott tanúsítványnév mellett az SP tenant és client ID, illetve a secret megadása kötelező. A path alatt megadhatunk egy vagy több értéket is, attól függően, hogy csak a végső exe-t, vagy az egyéb működéshez szükséges DLL fájlokat is alá szeretnénk írni. 

A sikeresen aláírt fájl
A sikeresen aláírt fájl

Audit

Most, hogy már tudunk aláírni, célszerű beállítani egy auditot is, hogy tudjuk, hogy ki és mikor írt alá a tanúsítványával.   

Az audit adatok exportját a KV alatt a Diagnostic settings alatt tudjuk beállítani, itt választhatjuk ki a célt. Tárolhatjuk a logokat közvetlenül Log Analytics workspace alatt és Storage Account-ban is. A Log Analytics workspace egy komplex service, a logok tárolása és megjelenítése mellett KQL query nyelv segítségével az adatok kereshetőek és szűrhetőek is. Storage Account alapú tárolás esetén az eventek json formátumban kerülnek exportálásra, amely fájlokat megfelelő toolok segítségével feldolgozhatunk, vagy akár archiválási céllal is tárolhatjuk itt az adatokat.  

Ha már használunk valamilyen audit megoldást, érdemes lehet megnézni az Azure Marketplace-t, hogy tudjuk-e könnyen exportálni a logokat a partner solutions segítségével. Ha ez nem áll rendelkezésre, vagy egyedi megoldást használunk, használhatjuk az Azure Event Hub-t, ahonnan teljesen testre szabhatjuk az exportot, akár direkt ingest endpointot is megadhatunk, mint cél. 

A könnyű prezentálhatóság miatt egy Log Analytics workspace alapon mutatok egy példát az alábbiakban. A példán a teljes event egy része látható. Az eventből megtudhatjuk, hogy mikor történt az esemény, milyen művelet került meghívásra, az sikerült-e, ki kezdeményezte ezt a művelet és milyen IP címről. A KQL query-k alapján akár alertet is beállíthatunk, ezáltal automatikusan értesülünk róla, ha valami gyanús tevékenység történt. 

Az event logból egy részlet
Az event logból egy részlet

Végszó

Ebben a kétrészes cikksorozatban bemutatásra került a teljes út, amit pár hónapja mi is végigjártunk a kódaláírással kapcsolatos változások miatt. Összegezve a tapasztalatokat, a teljes tanulási görbe a sok új technológia miatt az elején megterhelő lehet, ha nem rendelkezünk cloud alapú tapasztalattal, szerencsére cégünk esetén ez a tapasztalat már adott volt, így gyorsan, pár hét leforgása alatt teljesen adaptálódni és gyakorlatban is alkalmazni tudtuk az itt leírtakat. 

Mindenkinek sikeres kódaláírást kívánunk!

Vitarex - informatikai megoldások komplex igények szerint

Kulcsrakész szoftver rendszereket építünk az általad választott platformon: legyen az webapp, weboldal, felhős alkalmazás, mobil app vagy klasszikus asztali szoftver. Megvalósítjuk vadonatúj ötleteidet, karbantartjuk és új életet varázsolunk a régi szoftvereidbe, mesterséges intelligenciával tuningoljuk új vagy meglévő alkalmazásaidat. 25 éve vagyunk Ügyfeleink megbízható partnerei.

Szólj hozzá!