Aurreko argitalpenean, horri buruz CI/CD Pipelines, ikusi genuen nola hackeatu bat CI/CD eszenatoki hori zentzuzkoa babestuta zegoen.
Gogora dezagun aurreko mezuan esandakoa: batzuekin hasi ginen. pipeline zaurgarria zena. Zeharkako pozoitzea Pipeline Execution (I-PPE) eta, konpontzeko, banatzea erabaki genuen pipeline bitan:
- 1st pipeline (CI eraikia), D-PPE eta I-PPErentzat segurua, PR kodea egiaztatuko luke, eraikuntza egingo luke eta artefaktu bat sortuko luke.
- 2.a pipeline (Test CI), D-PPE eta I-PPE-rentzat ere segurua da oinarrizko kodea egiaztatuko lukeela (shell script-aren aldaketak saihesteko) eta jatorrizko script-ak exekutatuko lituzkeela artefaktuaren aurka.
- Proba CI sinkronizatzeko pipeline CI eraikiaren ONDOREN exekutatzeko pipeline, erabili genuen lan-fluxuaren_exekuzioa abiarazlea.
3. eszenatoki izena jarri genion horri.
Nahiz eta, mezu horretan aipatu genuen bezala, beste irtenbide batzuk badauden ere, "irtenbide" hau ezartzea erabaki genuen arrazoi pedagogikoengatik, ahultasunetan sakondu ahal izateko. CI/CD pipelines.
Ondoren, egoera hau nola hackeatu ikusi genuen artefaktua pozoitzea.Honi deitzen diogu Artefaktuen intoxikazioa, hau da, aldatzeko (hackeatzeko) gaitasuna pipeline logika bat aldatuz. pipeline artefaktu.
Zein da arazoa ikuspegi honekin? Ikusi genuen arazoa edozein erabiltzailek berri bat “sortzen” duenean sortzen dela pipeline.
Erabiltzaile batek PR bat irekitzen badu berri bat duena pipeline, GitHub-ek hori exekutatuko du pipeline (baldintza batzuk emanda, ikusi dugun bezala) postuan).
Erabiltzaileak berri bat sortu ahal izango du orduan pipeline Build CI izen berdinarekin!! Bai, harrigarria da, baina GitHub-ek bi sortzeko aukera ematen dizu pipelineizen berdinekoa!!
Erabiltzaileak aldaketa hauekin PR bat irekitzen duenean, "berria" pipeline exekutatuko da (artefaktu pozoitu bat igoz) eta CI zabaldua pipeline ondoren exekutatuko da, eta ondorioz, "aldatutako" shell script-ak "jatorrizko" shell script-a gainidatziko du pipeline lan-eremua. Beraz, "irtenbide" honek ez du I-PPE ahultasuna saihesten (behean ikus dezakegun bezala)
Zeintzuk dira arazoak? Gutxienez, badaude arazo pare bat:
- Lehenik eta behin, Nola ziurtatu eraikuntza prozesua ez dela aldatu? Egoera honetan, erabiltzaile gaiztoak eraikuntza-prozesua aldatu ahal izan du bere... pipeline pozoitutako artefaktu bat sortzeko.
- Bigarrenik, Nola ebaluatu dezakegu artefaktu baten jatorria?
Galdera hauek besoetan botatzen gaituzte Software Ziurtagiriak domeinua!!
Software Ziurtagiriak
An lekukotza zati bat da datuak ordezkari gertaera baten frogaMundu errealean, normalean hauei deitzen diegu ziurtagiriak.
Adibidez, laborategi batek zure odola aztertzen duenean, azterketari buruzko datuak erregistratu eta ziurtatzen dira. Odol-analisiaren emaitzak egiaztagarria trazagarria.
Gure IT domeinuari hurbilago, asma dezakezu zer izango litzatekeen prozesu honen itzulpena, adibidez, konpilazio-prozesu batera.
Konpilazio-zerbitzariaren inguruneari eta tresnei, materialei (iturri-kodea) eta produktuei/artefaktuei (kode bitarra) buruzko informazioa ziurtagiri horren parte izango litzateke.
Jakina, ziurtagiria baimendutako egiaztatzaile batek sortu behar du (egiaztatua eta ezeztaezina) sinesgarritasuna emateko.
Seguruenik, batzuek pentsatzen ariko zarete... eta zer da... sinadura eta ziurtagirien arteko aldea?
Kode Sinadurak eta Aitorpenak
Maila altuan, bat Sinadura gako-pare bat eta artefaktu bat erabiliz sortzen da. Gako-parea gako publiko batez eta gako pribatu batez osatuta dago.
Erabiltzaileak gako pribatua erabiliz sinatzen du artefaktu bat, eta beste batzuek sinadura egiaztatu dezakete gako publikoa erabiliz. Gako pribatua sekretuan gorde behar da, baina gako publikoa asko banatzen da.
Sinadurak erabil daitezke gako pribatuaren titularrak gako pribatua erabili zuela frogatzeko artefaktua sinatzeko.
sinadurak ez frogatu
- Erabiltzailearen asmoa artefaktua sinatzeko (engainatuta egon zitezkeen), edo
- Erabiltzaileak edozein gauza egiteko asmoa artefaktuari buruzko erreklamazio zehatza
With Atestatuak, artefaktu bat zuzenean sinatu beharrean, erabiltzaileek nolabaiteko dokumentua duen haien asmoa jasotzen du artefaktua sinatzearen atzean eta edozein erreklamazio zehatzak sinadura honen barruan egiten ari da.
Ziurtapen Esparru Osoa
Esparrurik ohikoena da Ziurtapen Esparru Osoa
- bat definitzen standard ziurtagirien formatua. subjektuak, deskribatzen ari diren artefaktuak, artefaktuari buruzko metadatu autentifikatuekin lotzen dituztenak
- multzo bat eskaintzen du aurrez definitutako predikatuak software hornikuntza-kateetan zehar autentifikatutako metadatuak komunikatzeko
Azter ditzagun xehetasun batzuk ziurtagiriaren formatuari buruz.
An Atestatua da digitalki sinatutako dokumentua dauka Adierazpenak.
The Statement ziurtagiriaren erdiko geruza da, jakin bati lotzen diona Gaia eta motak argi eta garbi identifikatzea Predikatu:
- Gaia: The artefaktuaren erreferentzia kriptografikoki segurua (normalean hash baten bidez), eta
- Predikatuakmultzo espezifiko bat erreklamazioak Artefaktu horri buruzko informazioari Adierazpen deitzen zaio. Baieztapen hauek bururatzen zaizun edozer gauza adierazteko (eta geroago frogatzeko) erabil daitezke! Eskuzko onarpena, artefaktuaren jatorria, proba automatizatuen emaitzak, auditoria-aztarna edo gehiago adieraz ditzakete!
Adierazpen hau kriptografikoki sinatzen denean, orduan deitzen zaio Atestatua
Modu honetan, adibidez, Alicek artefaktu bati buruzko Adierazpen bat sortzen du eta bere gako pribatua erabiliz sinatzen du, Ziurtagiri bat sortuz.
- Bobek orduan egin dezake sinadura egiaztatu. Aitorpen horretan, ahalbidetuz erreklamazioetan konfiantza izatea barruan.
Bobek erreklamazio horiek erabil ditzake orduan erabakitzeko artefaktu hau erabiltzea baimendu ala ez.
Ziurtagiriek artefaktuen pozoitzea konpontzen lagun dezakete?
Ziurtagiriei buruzko sarrera honen ondoren, itzul gaitezen gure arazora. Nola lagun gaitzakete ziurtapenek gure arazoa konpontzen, hau da, artefaktuen pozoitzea saihesten?
Erabiltzaile gaiztoak "mekanismo ofiziala" saihestuz artefaktu bat sortu ahal izan zuen, hau da, bere... pipeline artefaktua sortzeko.
Harrigarria litzateke deskargatzen ari diren artefaktuak ofizialki eraiki direla frogatu ahal izango bagenu. pipelines. Hau “Manipulazio puntuak” deitu genezakeenaren adibide bat besterik ez da, baina beste asko egon litezke.
Goiko irudian ikus dezakezuen bezala, manipulazio puntuak anitz dira. Horrela, kontsumitzailea pipeline (Gure adibidean, CI probak) ebaluatu behar du eraikuntza prozesuaren osotasuna , baita artefaktuaren beraren osotasuna.
Gure adibidean, pozoitutako artefaktua elementu (pozoidun) berri bat sartuz sortu da. pipeline eraikuntza prozesua aldatzen duena. Baina erabiltzaile gaiztoak gai izan zezakeen:
- kodea aldatu atera ondoren SCM bitar gaizto bat sortzeko
- Konpilazioak sortutako binario egokia beste edozein binario gaiztorekin ordezkatu
- Artefaktuen Erregistroa arriskuan jarri eta beste edozein modutan eraikitako artefaktu pozoitsu bat igo
- eta abar.
Ikus dezakezuenez, hainbat "manipulazio" puntu egon daitezke.
Zer da garrantzitsua hemen? Jakina, "manipulazio" puntu horiek guztiak babestea. Baina, azkenean, garrantzitsuena da artefaktuaren “kontsumitzaileak” artefaktuaren osotasuna ebaluatu dezakeela, eta aurrera egin ala ez erabaki dezakeela.
Ahal dugun artefaktu baten osotasuna ebaluatu bi modutan.
Bat ebaluatuz da jatorria artefaktuaren.
Sortuz. Jatorrizko Ziurtagiria, artefaktuari buruzko metadatu erabilgarriak (behar bezala autentifikatuak eta arbuiatu gabeak) ematen ditugu. Hurrengo adibideetan, erabiliko dugu Xygeni GATZA (Software Attestations Layer for Trust), software ziurtagiriak sortu, erregistratu eta egiaztatzeko osagaia.
- name: Building ... run: | # mvn will compile and create target/MyApp.war mvn clean package - name: Generating provenance run: | #!/usr/bin/env bash shopt -s expand_aliases alias salt=$PWD/salt_pro/xygeni_salt/salt echo " " echo "-----------" echo "Generating Provenance with CLI ..." salt at slsa \ --basedir ${GITHUB_WORKSPACE}/target \ --key="${PRIVATE_KEY}" \ --public-key=${GITHUB_WORKSPACE}/Test1_public.pem \ --key-password=${KEY_PASSWD} \ --output-unsigned=${GITHUB_WORKSPACE}/cli_provenance_${PIPELINE}_unsigned.json \ --pipeline ${PIPELINE} --pretty-print \ --file ./MyApp.war Goiko kodean, ikus dezakezu gerra fitxategia eraikitzen duen urrats bat dagoela eta sortzen duen bigarren urrats bat. Jatorrizko ZiurtagiriaHorretarako, pipeline gako pribatua erabiltzen du eta gako publikoa ere sartzen du ziurtagirian.
Eszena atzean, Xygeniren gatza komandoak ziurtagiria gordetzen du Ledger (hau da, ziurtagiri-erregistroa, erregistro gure kasuan, baina beste edozein erabil dezakezu). Hori eginda, kontsumitzailea pipeline Xygeni-ak barne har ditzake Egiaztapen-motorra artefaktuaren jatorria egiaztatzeko eta artefaktuaren osotasuna ebaluatzeko.
- name: 'Verifying the attestation' run: | #!/usr/bin/bash echo " " echo "-------" # Calculate sha256sum for the artifact SHA_SUM=$(sha256sum ./MyApp.war | cut -f1 -d ' ') # Recover the attestation Id from the sha256sum ATT_ID=$(echo $(salt -q registry search --digest sha256:$SHA_SUM --format json) | jq -r .[-1].gitoidSha256) echo " " echo "-------" # Download the provenance attestation echo "Downloading the provenance attestation ..." salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json echo " " echo "-------" echo "Verifying provenance ..." salt verify \ --basedir ${GITHUB_WORKSPACE} \ --attestation=${GITHUB_WORKSPACE}/provenance_kk.signed.json \ --public-key=${GITHUB_WORKSPACE}/Test1_public.pem \ --file ./MyApp.war Egiaztapen prozesuak honako hau ebaluatzen du:
- The sha256sum artefaktua baliozkoa da (hau da, "gai" horri buruzko ziurtagiri bat badago), eta
- The ziurtagiria behar bezala egiaztatuta dago (gako pribatu egokia erabiliz sortu da)
Egiaztapen-prozesu honek ebaluatu dezake bai artefaktua bai egiaztapena baliozkoak diren.
Baina, gogoratuko duzuenez, gure kasuan, artefaktua "gaizto" batek sortu zuen. pipeline (hau da, ez jatorrizkoa aldatutako baten bidez) pipeline). Orduan, beste alderdi bat egiaztatu behar dugu: artefaktua "jatorrizkoak" sortu du pipeline, ez beste edozein.
Horretarako, sartu lerro soil bat baldintza hori egiaztatzeko, adibidez:
echo " " echo "-------" # Download the provenance attestation echo "Downloading the provenance attestation ..." salt -q reg get --id=$ATT_ID --format=json > ${GITHUB_WORKSPACE}/provenance_kk.signed.json WFR=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json |base64 -d | jq -r .predicate.buildDefinition.internalParameters.environment.GITHUB_WORKFLOW_REF) echo $WFR | grep cicd_top10_3_salt\/.github\/workflows\/build.yml Egiaztapen gehigarri honek huts egingo du gure "seguru" sistemak sortu ez badu artefaktua. pipeline.
Jatorriz gure artefaktuak sortu bazuen pipeline (cicd_top10_3_salt/.github/workflows/build.yml), grep komandoak arrakasta izango du, bestela, huts egingo du, hautsiz pipeline eta beste edozein urrats bertan behera uztea.
"Eraikitzailea" pipeline egiaztatu beharreko manipulazio puntu bat besterik ez da, baina, aurretik aipatu bezala, egiaztatu beharko genituzkeen beste manipulazio puntu batzuk ere badaude.
Esate baterako, Zer gertatzen da iturburu-kodea aldatu bada biltegiaren azterketaren ondoren eta eraikuntza-komandoa baino lehen? Kasu honetan, eraiki beharreko kodea ez da gordetakoaren berdina. SCM.
Manipulazio puntu hau egiaztatzea hain erraza da, materialaren hash-ak urrats bakoitzean egiaztatzea bezain erraza.
SHA_ATT_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[0].predicate.materials[].digest[]) SHA_STEP_MATERIAL=$(jq -r .payload ${GITHUB_WORKSPACE}/provenance_kk.signed.json | base64 -d | jq -r .predicate.attestations[3].predicate.materials[0].digest[]) Ondorioak
Laburbilduz, bat Softwarearen Ziurtagiria software zati bati buruz egiten den baieztapena da, hau da, software artefaktu bati edo software artefaktu bilduma bati buruzko adierazpen autentifikatu bat (metadatuak).
Software-ziurtagiriak artefaktu/kode-sinadura gordinaren orokortze bat dira. Ziurtapena sinatutako dokumentu bat da (formatu jakin batean, normalean JSON oinarrituta), metadatuak artefaktu batekin lotzen dituena. Eraikuntza-urrats bakoitzean sarrerak (materialak) eta irteerak (ekoitzitako artefaktuak) lotzen dituzten ebidentzia adierazten dute.
Ziurtagiriek azken software-artefaktuak eraikitzeko egindako urratsen erregistro egiaztagarria eskaintzen dute, urrats bakoitzerako sarrera-materialak eta exekutatu diren eraikuntza-komandoak barne.
Ondorioz, Software Ziurtagiriak mekanismo bikaina dira gure eraikuntza prozesuaren osotasun alderdi asko egiaztatzeko.
Amaitu duzu seriea? Ez kezkatu! Anima zaitez berriro 'raPozoituta Pipeline Exekuzioa (PPE)' edo berriro zure interesa pizten duen beste edozein mezu!
Adi egon, softwarearen ziurtagirietan sakonduko dugu eta build security blog-eko beste argitalpen batzuetan.
