Ympäristömuuttujien lisääminen rakennusprosessiin on standard käytäntö modernissa CI/CD pipelines. Tiimit lisäävät ympäristömuuttujia koontiprosessiin välittääkseen salaisuuksia, tokeneita ja ajonaikaisia konfiguraatioita koontiversioihin ilman arvoja kovakoodauksessa. Pinnalta katsottuna tämä näyttää yksinkertaiselta ja turvalliselta mallilta.
Käytännössä siitä tulee kuitenkin usein yksi aliarvioiduimmista riskeistä ohjelmistojen toimitusketjussa.
Koska kun tiimit lisäävät ympäristömuuttujia rakennusprosessiin, nämä arvot lakkaavat olemasta erillisiä. Ne tulevat kaikkien sen sisällä toimivien toimintojen saataville. pipeline. Koontikomentosarjat, komentorivityökalut, kolmannen osapuolen toiminnot ja jopa riippuvuudet voivat lukea niitä.
Tässä kohtaa asiat alkavat hajota.
Tässä oppaassa käymme läpi, kuinka tiimit lisäävät ympäristömuuttujia rakennusprosessiin käytännössä. pipelines, missä vuotoja todellisuudessa tapahtuu ja miten rakennusprosessi voidaan suojata hidastamatta kehitystä.
Mitä ympäristömuuttujien lisääminen rakennusprosessiin tarkoittaa
Pohjimmiltaan ympäristömuuttujien syöttäminen tarkoittaa arvojen välittämistä pipeline ajonaikana, jotta työt voivat käyttää niitä suorituksen aikana.
Nämä arvot sisältävät tyypillisesti API-avaimia, tietokannan tunnistetietoja, tokeneita tai ympäristökohtaisia kokoonpanoja. Sen sijaan, että ne tallennettaisiin suoraan koodiin, CI/CD Järjestelmä lataa ne dynaamisesti, kun rakennus alkaa.
Tämä ratkaisee todellisen ongelman. Se pitää koodin puhtaana, välttää päällekkäisyyksiä ja mahdollistaa saman pipeline toimimaan eri vaiheissa, testaus- ja tuotantoympäristöissä.
Tämä malli kuitenkin perustuu oletukseen, joka ei enää päde: että rakennusympäristö on kontrolloitu ja ennustettava.
Moderni pipelineeivät ole kumpaakaan. Ne sisältävät useita vaiheita, ulkoisia integraatioita ja riippuvuuksia, jotka suorittavat koodia dynaamisesti. Tämän seurauksena, kun muuttuja on injektoitu, se ei ole enää pelkkä konfiguraatio. Siitä tulee osa suorituskontekstia.
Missä ympäristömuuttujat vuotavat rakennusprosessissa
Useimmat vuodot eivät tapahdu siksi, että joku paljastaa salaisuuden. Ne tapahtuvat siksi, että pipelinekäyttäytyvät tavoilla, joita kehittäjät eivät täysin osaa ennakoida.
Esimerkiksi kehittäjä voi ottaa käyttöön yksityiskohtaisen lokikirjauksen virheenkorjauksen tekemiseksi epäonnistuneessa koonnissa. CLI-työkalu voi tulostaa ympäristömuuttujia osana tulostettaan. Riippuvuus voi käyttää prosessimuuttujia hiljaisesti osana suoritustaan.
Mikään näistä toimista ei näytä epäilyttävältä yksinään. Yhdessä ne kuitenkin luovat useita vuotoreittejä.
Salaisuudet voivat päätyä seuraaviin:
- rakentaa lokeja, jotka tallennetaan ja indeksoidaan
- debug-tuloste jaettu tiimien kesken
- kolmannen osapuolen CI-toiminnot, jotka suorittavat ulkoista koodia
- riippuvuudet, jotka suoritetaan asennuksen tai suorituksen aikana
- rakennuksen aikana syntyneet väliaikaiset artefaktit
Kun salaisuus ilmestyy lokeihin, se harvoin pysyy tallessa. Lokit kopioidaan, tallennetaan ja säilytetään useissa järjestelmissä. Tässä vaiheessa paljastuminen ulottuu paljon alkuperäistä pidemmälle. pipeline.
Tästä syystä ympäristömuuttujavuodot havaitaan usein myöhään ja vasta vahingon jo tapahtuttua.
Miksi tiimit lisäävät ympäristömuuttujia rakennusprosessiin
Näistä riskeistä huolimatta tiimit luottavat vahvasti ympäristömuuttujien injektointiin. Ja hyvästä syystä.
Se mahdollistaa pipelinepysyäkseen joustavana. Yksi työnkulku voi mukautua erilaisiin ympäristöihin, todentaa itsensä useissa palveluissa ja muuttaa toimintaa dynaamisesti ilman koodin muokkaamista.
Nopeasti muuttuvissa DevOps-ympäristöissä tämä joustavuus on olennaista. Joustavuuteen liittyy kuitenkin aina kompromisseja. Mitä dynaamisempi pipeline Mitä enemmän siitä tulee, sitä vaikeammaksi sen sisällä tapahtuvien asioiden hallinta muuttuu. Jokainen lisävaihe, integraatio tai riippuvuus lisää niiden paikkojen määrää, joista arkaluonteisia tietoja voidaan käyttää.
Tämän seurauksena ympäristömuuttujien injektointi muuttuu kokoonpanotiedosta turvallisuusongelmaksi.
Yleisiä riskejä, kun ympäristömuuttujia lisätään koontiprosessiin
Riskit eivät ole teoreettisia. Ne ilmenevät käytännössä. pipelines joka päivä.
Salaisuuksia vuotaa lokeihin
Lokit ovat yksi niistä yleisimmät altistumislähteetVirheenjäljitysliput, komentorivityökalut ja pinonjäljitykset paljastavat usein arkaluontoisia arvoja kehittäjien huomaamatta.
Kun arvot ovat kerran paljastuneet, ne leviävät nopeasti järjestelmien välillä.
Liian salliva pääsy
Paljon pipelines altistaa kaikki muuttujat kaikille töille. Tämä luo tarpeetonta riskiä.
Jos yksi vaihe vaarantuu, se voi käyttää tunnistetietoja, joita se ei todellisuudessa tarvitse.
Riippuvuus ja toiminnan väärinkäyttö
Moderni pipelineluottavat vahvasti kolmannen osapuolen työkaluihin ja integraatioihin. Nämä komponentit toimivat samassa ympäristössä kuin salaisuutesi.
Jos jokin niistä käyttäytyy haitallisesti, se voi käyttää injektoituja muuttujia hiljaa.
Mukaan OWASPToimitusketjuhyökkäykset hyödyntävät usein luotettavia komponentteja rakennusprosessissa. Ympäristömuuttujista tulee usein helpoin kohde.
Varasalaisuudet koodissa
Kun koonnit epäonnistuvat puuttuvien muuttujien vuoksi, tiimit joskus lisäävät vara-arvoja pitääkseen pipelinejuoksee.
Ajan myötä nämä arvot muuttuvat commitotettu käyttöön, mikä aiheuttaa pitkäaikaisen altistuksen.
Parhaat käytännöt ympäristömuuttujien turvalliseen lisäämiseen koontiprosessiin
| Luokka | Paras harjoitus | Miksi se koskee |
|---|---|---|
| Salaisuuksien säilytys | Käytä holvia tai CI-salaisuuksien hallintaa | Estää altistumisen koodissa |
| Kulunvalvonta | Rajoita käyttöoikeuksia työkohtaisesti | Pienentää hyökkäyspinta-alaa |
| Hakkuu | Maskaa herkät arvot | Estää vuotoja |
| Soveltamisala ja käyttöikä | Käytä lyhytaikaisia tunnuksia | Rajoittaa räjähdyssädettä |
| Validation | Käännösten epäonnistuminen, jos muuttujia puuttuu | Välttää vaarallisia vararatkaisuja |
Miksi monet CI/CD Turvallisuustyökalut Miss Env Var -vuodot
Useimmat tietoturvatyökalut keskittyvät koodin tai riippuvuuksien skannaamiseen koontiversion valmistuttua.
Ympäristömuuttujien vuotoja kuitenkin tapahtuu suorituksen aikana.
A pipeline voi syöttää salaisuuksia oikein ja silti paljastaa ne lokien tai ajonaikaisen toiminnan kautta. Siihen mennessä, kun skanneri havaitsee ongelman, salaisuus voi jo olla vaarantunut.
Tämä luo kuilun havaitsemisen ja ehkäisyn välille.
Tiimit tarvitsevat kontrolleja, jotka toimivat samalla kun pipeline juoksee, ei sen päätyttyä.
Ympäristömuuttujien injektoinnin suojaamisen suositteleminen
Käytännössä tehokas suoja riippuu muutamista johdonmukaisista periaatteista.
Säilytä salaisuuksia ulkopuolella pipeline. Pistä ne vain suorituksen aikana. Rajoita käyttöoikeudet mahdollisimman pieneen vaadittuun laajuuteen. Käytä lyhytaikaisia tunnuksia aina kun mahdollista.
Samalla seurataan, miten pipelines pääsyherkkiin arvoihin. Odottamattomat käyttömallit viittaavat usein riskiin ennen kuin vuoto tulee näkyviin.
Tämä lähestymistapa siirtää turvallisuuden reaktiivisesta havaitsemisesta ennakoivaan hallintaan.
Miten Xygeni auttaa suojaamaan CI/CD Salainen injektio
Pelkän jälkikäteen tehtävän skannauksen sijaan Xygeni analysoi, miten pipelinekäyttävät ympäristömuuttujia suorituksen aikana. Tämä sisältää sen, miten salaisuudet siirtyvät töiden välillä, miten rakennusvaiheet käyttävät niitä ja miten riippuvuudet ovat vuorovaikutuksessa suoritusympäristön kanssa.
Esimerkiksi Xygeni pystyy havaitsemaan, kun pipeline paljastaa muuttujat liian laajasti, kun vaihe vaarantaa arkaluonteisten arvojen tulostamisen lokitiedostoihin tai kun riippuvuus yrittää käyttää tunnistetietoja odottamatta.
Samaan aikaan, guardrails valvoa käytäntöä suoraan pipelineTiimit voivat estää vaarallisia koontiversioita, rajoittaa salaista pääsyä tiettyihin töihin ja estää riskialttiiden kokoonpanojen luomisen ennen kuin ne pääsevät tuotantoon.
Koska tämä tapahtuu sisällä CI/CD työnkulun, kehittäjien ei tarvitse muuttaa työskentelytapojaan. Tietoturvasta tulee osa pipeline, ei erillinen vaihe.
Tämän seurauksena tiimit saavat näkyvyyttä salaisuuksien käyttöön, hallitsevat niiden paljastumista ja vähentävät vuotojen riskiä hidastamatta toimitusta.
Tiivistelmä
Se tuo kuitenkin mukanaan myös riskin, joka jää usein huomaamatta.
Haasteena ei ole se, käytetäänkö ympäristömuuttujia, vaan se, miten niiden näkyvyyttä hallitaan suorituksen aikana.
Nykyaikaisissa DevOps-ympäristöissä vuotojen estäminen rakennusprosessin aikana on paljon tärkeämpää kuin niiden havaitseminen jälkikäteen.
