A környezeti változók beillesztése az építési folyamatba egy standard gyakorlat a modern világban CI/CD pipelines. A csapatok környezeti változókat injektálnak a build folyamatba, hogy titkokat, tokeneket és futásidejű konfigurációt adjanak át a buildeknek anélkül, hogy fix értékeket kellene beírniuk. Első pillantásra ez egy egyszerű és biztonságos mintának tűnik.
A gyakorlatban azonban gyakran az egyik leginkább alábecsült kockázattá válik a szoftverellátási láncban.
Mert miután a csapatok környezeti változókat injektálnak a build folyamatba, ezek az értékek már nem elszigeteltek. Hozzáférhetővé válnak minden számára, ami a folyamatban fut. pipelineBuild szkriptek, CLI eszközök, harmadik féltől származó műveletek és még függőségek is képesek olvasni őket.
Itt kezdenek szétesni a dolgok.
Ebben az útmutatóban bemutatjuk, hogyan juttatnak be a csapatok környezeti változókat a build folyamatba valós körülmények között. pipelines, hol történnek valójában a szivárgások, és hogyan lehet biztonságossá tenni az építési folyamatot a fejlesztés lassítása nélkül.
Mit jelent környezeti változók befecskendezése az építési folyamatba?
A környezeti változók injektálása lényegében azt jelenti, hogy értékeket adunk át egy pipeline futásidőben, hogy a feladatok (jobok) a végrehajtás során hozzáférhessenek hozzájuk.
Ezek az értékek jellemzően API-kulcsokat, adatbázis-hitelesítő adatokat, tokeneket vagy környezetspecifikus konfigurációt tartalmaznak. Ahelyett, hogy közvetlenül a kódban tárolná őket, a CI/CD A rendszer dinamikusan tölti be őket, amikor a build elindul.
Ez egy valós problémát old meg. Tiszta kódot biztosít, elkerüli a duplikációt, és lehetővé teszi ugyanazt. pipeline tesztelési, előkészítési és éles környezetekben való futtatáshoz.
Ez a modell azonban egy olyan feltételezésen alapul, amely már nem áll fenn: hogy az építési környezet ellenőrzött és kiszámítható.
Modern pipelineAz ok egyik sem. Több lépést, külső integrációkat és függőségeket tartalmaznak, amelyek dinamikusan végrehajtják a kódot. Ennek eredményeként, miután egy változót befecskendeznek, az már nem csak konfiguráció. A végrehajtási kontextus részévé válik.
Hol szivárognak a környezeti változók az építési folyamat során?
A legtöbb szivárgás nem azért történik, mert valaki nyíltan felfed egy titkot. Azért történnek, mert pipelineolyan módon viselkednek, amelyet a fejlesztők nem teljesen előre látnak.
Például egy fejlesztő engedélyezheti a részletes naplózást egy hibás build hibakereséséhez. Egy CLI eszköz kimenete részeként kinyomtathatja a környezeti változókat. Egy függőség a végrehajtás részeként csendben hozzáférhet a folyamatváltozókhoz.
Önmagukban egyik cselekedet sem tűnik gyanúsnak. Együttesen azonban több szivárgási útvonalat hoznak létre.
A titkok a következőkben végződhetnek:
- naplókat kell létrehozni, amelyeket tárolnak és indexelnek
- csapatok között megosztott hibakeresési kimenet
- külső kódot futtató harmadik féltől származó CI-műveletek
- telepítés vagy futásidő alatt végrehajtódó függőségek
- az építés során keletkezett ideiglenes műtermékek
Ha egy titkos információ egyszer megjelenik a naplókban, ritkán marad meg a rendszeren. A naplókat lemásolják, tárolják és megőrzik több rendszeren keresztül. Ezen a ponton a kiszivárgás messze túlmutat az eredetin. pipeline.
Ezért a környezeti változók szivárgásait gyakran későn fedezik fel, miután a kár már megtörtént.
Miért adnak a csapatok környezeti változókat a build folyamathoz?
Ezen kockázatok ellenére a csapatok nagymértékben támaszkodnak a környezeti változók injektálására. És jó okkal.
Lehetővé teszi pipelines a rugalmasság megőrzése érdekében. Egyetlen munkafolyamat képes alkalmazkodni a különböző környezetekhez, több szolgáltatáshoz is hitelesíthető, és dinamikusan változtathatja a viselkedését a kód módosítása nélkül.
A gyorsan változó DevOps környezetekben ez a rugalmasság elengedhetetlen. A rugalmasság azonban mindig kompromisszumokkal jár. Minél dinamikusabb egy pipeline Minél több adatot tárolunk, annál nehezebbé válik annak ellenőrzése, hogy mi történik benne. Minden további lépés, integráció vagy függőség növeli azon helyek számát, ahol az érzékeny adatokhoz hozzá lehet férni.
Ennek eredményeként a környezeti változók injektálása a konfigurációs részletből biztonsági problémává válik.
Gyakori kockázatok környezeti változók építési folyamatba történő befecskendezésekor
A kockázatok nem elméletiek. A valóságban is megjelennek. pipelineminden nap.
Titkok szivárognak a naplókba
A naplók az egyik leggyakoribb expozíciós forrásokA hibakeresési jelzők, a parancssori felület (CLI) eszközök és a veremkövetések gyakran érzékeny értékeket tárnak fel anélkül, hogy a fejlesztők észrevennék.
Miután ezek az értékek napvilágra kerülnek, gyorsan terjednek a rendszerek között.
Túlzottan engedékeny hozzáférés
Sok pipelines minden változót kitesznek az összes munkának. Ez szükségtelen kockázatot teremt.
Ha egy lépés veszélybe kerül, olyan hitelesítő adatokhoz férhet hozzá, amelyekre valójában nincs szüksége.
Függőség és cselekvési visszaélés
Modern pipelinenagymértékben támaszkodnak harmadik féltől származó eszközökre és integrációkra. Ezek az összetevők ugyanabban a környezetben futnak, mint a titkok.
Ha egyikük rosszindulatúan viselkedik, csendben hozzáférhet a befecskendezett változókhoz.
Szerint OWASPAz ellátási lánccal kapcsolatos támadások gyakran kihasználják a megbízható komponenseket a build folyamatban. A környezeti változók gyakran a legkönnyebb célponttá válnak.
Tartalék titkok a kódban
Amikor a buildek hiányzó változók miatt meghiúsulnak, a csapatok néha tartalék értékeket adnak hozzá a megőrzésük érdekében. pipelinefut.
Idővel ezek az értékek commitbevetve vagy telepítve, ami hosszú távú kitettséget teremt.
Ajánlott gyakorlatok környezeti változók biztonságos befecskendezéséhez a build folyamatba
| Kategória | Legjobb gyakorlat | Miért számít? |
|---|---|---|
| Titkok tárolása | Használjon trezort vagy CI-titkok kezelőjét | Megakadályozza a kódban való kitettséget |
| Belépési ellenőrzés | Hozzáférés korlátozása feladatonként | Csökkenti a támadási felületet |
| Fakitermelés | Érzékeny értékek maszkolása | Megakadályozza a szivárgást |
| Hatály és élettartam | Használjon rövid életű hitelesítő adatokat | Korlátozza a robbanási sugarat |
| Érvényesítés | Hiányzó változók esetén a buildek sikertelenek | Kerüli a nem biztonságos tartalék megoldásokat |
Miért sokan CI/CD Biztonsági eszközök Miss Env Var Leaks
A legtöbb biztonsági eszköz a kód vagy a függőségek beolvasására összpontosít a build befejezése után.
A végrehajtás során azonban környezeti változók szivárgása történik.
A pipeline helyesen tudja beilleszteni a titkos kódokat, és továbbra is felfedheti azokat a naplókon vagy a futásidejű viselkedésen keresztül. Mire a szkenner észleli a problémát, a titkos kód már veszélybe kerülhet.
Ez szakadékot teremt a felderítés és a megelőzés között.
A csapatoknak olyan kontrollokra van szükségük, amelyek akkor is működnek, amikor a pipeline fut, nem miután befejeződött.
Hogyan ajánljuk a környezeti változók befecskendezésének biztonságossá tételét?
A gyakorlatban a hatékony védelem néhány következetes alapelv betartásán múlik.
Őrizd meg a titkokat a külső téren pipelineCsak futásidőben injektáld őket. Korlátozd a hozzáférést a minimálisan szükséges hatókörre. Használj rövid életű hitelesítő adatokat, amikor csak lehetséges.
Ezzel egyidejűleg figyelje meg, hogyan pipelines hozzáférés-érzékeny értékek. A váratlan hozzáférési minták gyakran már a szivárgás láthatóvá válása előtt jelzik a kockázatot.
Ez a megközelítés a biztonságot a reaktív észlelésről a proaktív ellenőrzésre helyezi át.
Hogyan segít a Xygeni a védelemben? CI/CD Titkos injekció
Ahelyett, hogy csak az utólagos szkennelésre hagyatkozna, a Xygeni elemzi, hogyan pipelinekörnyezeti változókat használnak futás közben. Ez magában foglalja azt is, hogy a titkok hogyan mozognak a feladatok között, hogyan férnek hozzájuk a build lépések, és hogyan hatnak egymásra a függőségek a végrehajtási környezettel.
Például a Xygeni képes érzékelni, amikor egy pipeline túl széles körben teszi elérhetővé a változókat, amikor egy lépés kockáztatja a bizalmas értékek naplókba nyomtatását, vagy amikor egy függőség váratlanul megpróbál hozzáférni a hitelesítő adatokhoz.
Ugyanabban az időben, guardrails közvetlenül érvényesítse a szabályzatot pipelineA csapatok blokkolhatják a nem biztonságos buildeket, korlátozhatják a titkos hozzáférést bizonyos feladatokhoz, és megakadályozhatják a kockázatos konfigurációkat, mielőtt azok elérnék az éles környezetet.
Mert ez belül történik CI/CD a munkafolyamatnak köszönhetően a fejlesztőknek nem kell megváltoztatniuk a munkamódszerüket. A biztonság a folyamat részévé válik. pipeline, nem egy külön lépés.
Ennek eredményeként a csapatok betekintést nyernek abba, hogyan használják a titkos információkat, szabályozhatják azok nyilvánosságra kerülését, és csökkenthetik a szivárgások kockázatát a kézbesítés lassítása nélkül.
Záró gondolatok
Azonban egy olyan kockázati réteget is jelent, amely gyakran észrevétlen marad.
A kihívás nem az, hogy használjunk-e környezeti változókat, hanem az, hogy hogyan szabályozzuk azok elérhetőségét a végrehajtás során.
A modern DevOps környezetekben a szivárgások megelőzése a build folyamat során sokkal fontosabb, mint azok utólagos észlelése.
