Mindannyian láttunk már olyan felugró ablakot, amelyben az operációs rendszer jelzi, hogy a telepíteni kívánt szoftver nem ellenőrizhető forrásból származik, ezáltal telepítése és futtatása nem ajánlott. Ez bizonyos esetben nem probléma, viszont sok esetben ez nem engedhető meg, amely magával vonja a kódaláírás szükségességét.
A kódaláírás (code signing) egy olyan biztonsági eljárás, amely során a szoftverfejlesztő digitálisan aláírja a kódot vagy alkalmazást, hogy hitelesítse annak eredetiségét és integritását. Ezen a módon a felhasználók megbizonyosodhatnak róla, hogy a letöltött vagy telepített szoftver valóban az eredeti forrásból származik, és nem módosították vagy fertőzték meg rosszindulatú kódokkal az aláírás elvégezte óta.
Code Signing OV és Code Signing EV
A code signing tanúsítványoknak többféle változata van annak függvényében, milyen kódot vagy alkalmazást aláírására tervezzük használni. Az egyik legelterjedtebb változata a Code Signing OV (Organizational Validation) és Code Signing EV (Extended Validation). Az OV és EV tanúsítvány közötti különbségek a kibocsátó fél azonosításának és az azonosítást igazoló eljárások szintjében rejlenek. Mindkét típusú tanúsítvány a kódaláírás céljára használható, de az EV tanúsítványok általában magasabb szintű bizalmat és hitelességet élveznek a felhasználók, böngészők és operációs rendszerek részéről. Ebből következik, hogy az EV tanúsítvány kiállítási ideje általában több időt igényel, illetve magasabb áron is érhetőek el.
Változások idéntől
Több elhalasztás után, idén 2023. június 1-től a Code Signing OV tanúsítványokat az összes publikus tanúsító hatóság és ezeknek viszonteladóik csak hardver alapú token vagy HSM (Hardware Security Module) alapon biztosítja.
De mit jelent ez, jó vagy rossz ez nekünk, hogy tudom ezt használni? Kezdésként érdemes tudni, hogy ennek bevezetése nem egy új, hirtelen jött ötlettől vezérelve érkezett, a Code Signing EV tanúsítványokat már 2021-től ilyen módon állítják ki. Előtte, illetve eddig OV tanúsítvány esetében legtöbb esetben a tanúsítvány megvásárlása után letölthettük a fájlt és használhattuk ahogy akartuk, nem sok megkötés volt. Ez biztonsági szempontból nem volt túl ideális, mivel a tanúsítvány birtokában bárki készíthet a cégünk által aláírt kódot és alkalmazást, amellyel nem csak a cégünk megítélését ronthatja, de különböző számítógépes vírusok, malware és rootkitek terjesztésére is felhasználható.
Az új megoldás lényege, hogy a tanúsítvány a hardver eszközt nem tudja elhagyni, nincs lehetőség a kulcs kiexportálására, így csak a megfelelő jogosultsággal rendelkező identity (személy/szoftver) használhatja, és emiatt az audit lehetőségek is jobban alkalmazhatóak.
Hardver token
Hardver token esetén lehetőségünk van a már meglévő, saját tokenünk használatára, illetve amennyiben nem rendelkezünk saját eszközzel a tanúsítvány igénylésekor rendelhetünk is egyet – nyilván ennek anyagi költsége is van ilyen esetben, viszont sok esetben, ha hosszabb időtartamú tanúsítványt vásárlunk, ingyen megkapjuk mellé a tokent. Ezen hardver tokenek a saját kezelő szoftverükkel érkeznek, azon keresztül használhatóak. Mivel ezen tokenek általában USB interfészen keresztül csatlakoztathatóak a PC/szerverhez, egyes esetekben limitálják a használhatóságot, mivel használathoz csatlakoztatni kell, így az egy idejű használat megoldása nehezen vagy egyáltalán nem kivitelezhető.
Alternatíva tárolásra még a HSM, amelynél szintén használhatunk saját, illetve itt választhatunk cloud alapú megoldást is.
Követelmények a HSM felé
A tanúsítvány privát kulcsát olyan HSM alatt kell tárolni, amely megfelel a FIPS 140-2 level 2, Common Criteria EAL 4+, vagy ezekkel egyenértékűvel biztonsági szintnek, plusz amely támogatja a 3072-bit vagy hosszabb kulcsot. Mivel egy saját dedikált HSM modul meglehetősen drága, érdemes lehet megvizsgálni a cloud alapú lehetőségeket is.
A nagyobb cloud szolgáltatóknál választhatunk natív HSM modult, illetve menedzselt megoldást is, amely esetben a használat alapján fizetünk. Itt érdemes felmérni a saját igényeinket, honnan szeretnénk elérni – csak privát elérés közvetlenül a cloudban elérhető virtual networkből, hibrid cloud kialakításban saját szervereinkről is VPN vagy dedikált csatorna felett, vagy akár interneten keresztül is szeretnénk használni.
Fontos még figyelembe venni, hogy hány tanúsítványt tervezünk tárolni rajta, illetve ezt milyen gyakori eléréssel tervezzük használni, mivel a menedzselt szolgáltatások általában Pay-as-You-Go (PAYG) alapúak, tehát használatért fizetünk – pl. request szám, tárolt tanúsítványok száma. Ezzel szemben a dedikált cloud HSM megoldás esetén nincs ilyen megkötés, fix díjjal számolhatunk az idő függvényében, így felhasználásunktól függően érdemes kiszámolnunk, hogy melyik éri meg legjobban számunkra, ezáltal elkerülve a felesleges költségeket.
Lehetőségek
Mivel mi is abban a helyzetben voltunk, hogy idén járt le a tanúsítványunk, szükséges volt megvizsgálnunk a lehetőségeinket. Három lehetséges opció közül választhattunk:
- első lehetséges opció volt, hogy a változás előtt igénylünk egy új tanúsítványt
- második opció volt áttérni hardver token alapú megoldásra
- harmadiknak pedig a HSM használata merült fel
Vizsgáljuk meg jobban a lehetőségeket, előnyeik és hátrányaik, költségük és szükséges időráfordítás tekintetében.
Az első opció volt, hogy új 3 éves lejáratú tanúsítványt igénylünk. Ennek vitathatatlan előnye, hogy a legkisebb idő és energiaráfordítást igényli, minden mehetett volna tovább az eddigiekben is használt módon. Hátránya viszont, hogy mivel a váltás elkerülhetetlen, ez csak elodázta volna a szükséges fejlesztéseket.
Második opció, a hardver token alapú megoldás. Előnye, amely egyben hátránya is, hogy a token biztonságáért mi vagyunk a felelősek, tehát ha a token eltűnik vagy megsemmisül, a kódaláírás egy új tanúsítvány beszerzéséig nem lehetséges. További fejtörést okozott a token “valós” mivolta, mivel használathoz ezt egy adott PC/szerver USB portjához kell csatlakoztatni és csak a token szoftverén keresztül használható, így a különböző szerver és virtualizált build környezetekbe való integrálhatósága nem feltétlenül triviális.
Harmadik opció egy megfelelő HSM megoldás választása. Saját HSM modul vásárlása meglehetősen drága, főleg, ha redundáns tárolást is szeretnénk különböző előre nem látható eseményekre. Mivel cégünknek már sok tapasztalata van különböző cloud alapú platformokon történő fejlesztés és üzemeltetés területén, felmerült a cloud alapú megoldás lehetősége is. Miután sikerült a saját igényeinket és használati szokásainkat felmérni, megállapítottuk, hogy a dedikált cloud HSM nem ideális a mi felhasználásunkra, így figyelmünk a service alapú megoldások felé fordult.
A választott megoldás – Azure Key Vault
A felhasználási igényeinknek végül a Microsoft Azure cloud platformon elérhető Azure Key Vault (KV) service bizonyult a legmegfelelőbbnek. Az Azure Key Vault lehetőséget biztosít secret, key, illetve certificate tárolására is, biztonságot tekintve 2 kivitelben érhető el:
- a standard esetben FIPS 140-2 level 1 szintnek felel meg,
- prémium kivitelben FIPS 140-2 level 2 szintet teljesít, amely megfelel a code signing tanúsítvány tárolásához szükséges követelménynek.
Költsége szemben a dedikált HSM megoldással request szám és tárolt tanúsítvány alapján számolódik, így ez a mi felhasználásunkra ideális és költséghatékony választás volt. Integrálhatósága relatív kis fejlesztés és időráfordítás árán megoldható.
A következő fejezetben megnézzük a tanúsítvány használatának a gyakorlati lépéseit.
