Ankstesniame mūsų įraše apie CI/CD Pipelines, mes matėme kaip nulaužti CI/CD scenarijus, kuris spėjama buvo apsaugotas.
Prisiminkime ankstesniame įraše išsakytą mintį: pradėjome nuo kai kurių pipeline kuris buvo pažeidžiamas Netiesiogiai apsinuodijęs Pipeline Vykdymas (I-PPE) ir, norėdami tai ištaisyti, nusprendėme padalyti pipeline į dvi dalis:
- 1-asis pipeline (Build CI), saugus D-PPE ir I-PPE, patikrintų PR kodą, atliktų kūrimą ir sugeneruotų artefaktą
- "2" pipeline (Bandomasis CI), taip pat saugus D-PPE ir I-PPE, patikrintų bazinį kodą (kad būtų išvengta apvalkalo scenarijaus modifikavimo) ir vykdytų originalius scenarijus su artefaktu.
- Norėdami sinchronizuoti bandymo CI pipeline paleisti PO „Build CI“ pipeline, mes naudojom darbo eigos_vykdymas sukelti.
Mes tai pavadinome 3-iuoju scenarijumi.
Nors, kaip minėjome tame įraše, yra ir kitų sprendimų, nusprendėme įgyvendinti šį „sprendimą“ dėl pedagoginių priežasčių, kad galėtume išsamiau išnagrinėti pažeidžiamumus. CI/CD pipelines.
Vėliau pamatėme, kaip nulaužti šį scenarijų apsinuodijimas artefaktuTai mes vadiname Artefaktų apsinuodijimas, t. y. galimybė modifikuoti (nulaužti) pipeline logiką modifikuojant pipeline artefaktas.
Kokia šio metodo problema? Matėme, kad problema kyla, kai bet kuris vartotojas „sukuria“ naują pipeline.
Jei vartotojas atidaro PR, kuriame yra naujas pipeline„GitHub“ tai vykdys pipeline (esant tam tikroms sąlygoms, kaip matėme įraše).
Tada vartotojas gali sukurti naują pipeline tuo pačiu pavadinimu kaip ir „Build CI“!! Taip, tai stebina, bet „GitHub“ leidžia sukurti du pipelinesu tuo pačiu pavadinimu!!
Kai vartotojas atidaro PR su šiais pakeitimais, nauja" pipeline bus įvykdyta mirties bausmė (įkeliant užnuodytą artefaktą) ir „Deploy CI“ pipeline bus vykdomas po to, todėl „modifikuotas“ apvalkalo scenarijus perrašys „originalų“ apvalkalo scenarijų, esantį pipeline darbo sritis. Taigi, šis „sprendimas“ neišvengia I-PPE pažeidžiamumo (kaip matome toliau).
Kokios problemos? Bent kelios yra:
- Pirma, Kaip įsitikinti, kad kūrimo procesas nebuvo pakeistas? Šiuo atveju kenkėjiškas vartotojas galėjo modifikuoti numatytą kūrimo procesą naudodamas savo pipeline sukurti užnuodytą artefaktą.
- Antra, Kaip galime įvertinti artefakto kilmę?
Šie klausimai įmeta mus į glėbį Programinės įrangos atestacijos domenas!!
Programinės įrangos atestacijos
An atestacija yra gabalas duomenys atstovaujančių įvykio įrodymasRealiame pasaulyje mes tai paprastai vadiname atestatus.
Pavyzdžiui, kai laboratorija atlieka jūsų kraujo tyrimą, tyrimo duomenys yra registruojami ir patvirtinami. Kraujo tyrimo rezultatai yra patikrinti bei atsekamas.
Arčiau mūsų IT srities, galite spėti, kaip šis procesas būtų perkeltas, pavyzdžiui, į kompiliavimo procesą.
Informacija apie kompiliavimo serverio aplinką ir įrankius, medžiagas (šaltinio kodą) ir produktus / artefaktus (dvejetainį kodą) būtų tokio atestavimo dalis.
Akivaizdu, kad patvirtinimą turi sugeneruoti įgaliotas patvirtintojas (patvirtintas ir nepaneigiamas), kad būtų užtikrintas patikimumas.
Tikriausiai kai kurie iš jūsų galvoja... o kas gi yra... Skirtumas tarp parašų ir patvirtinimų?
Kodo parašai ir patvirtinimai
Aukštu lygiu, a parašas sukuriamas naudojant raktų porą ir artefaktą. Raktų porą sudaro viešasis raktas ir privatusis raktas.
Vartotojas pasirašo artefaktą naudodamas privatųjį raktą, o kiti gali patikrinti parašą naudodami viešąjį raktą. Privatusis raktas turi būti laikomas paslaptyje, tačiau viešasis raktas yra plačiai platinamas.
Parašus galima naudoti įrodyti, kad privataus rakto turėtojas panaudojo privatų raktą artefaktui pasirašyti.
Parašai neįrodyk
- Vartotojo tikslas pasirašyti artefaktą (jie galėjo būti apgauti) arba
- Vartotojo ketinimas atlikti bet kokius veiksmus konkretus teiginys apie artefaktą
Su Atestacijos, užuot tiesiogiai pasirašę artefaktą, vartotojai sukuria kažkokį dokumentas kad užfiksuoja jų ketinimus už artefakto pasirašymo ir bet kokio kito konkrečių pretenzijų sudaromas kaip šio parašo dalis.
In-toto atestavimo sistema
Dažniausiai pasitaikantis rėmelis yra „In-toto“ atestavimo sistema
- apibrėžia standard patvirtinimų formatas kurie susieja subjektus, aprašomus artefaktus, su autentifikuotais metaduomenimis apie artefaktą
- pateikia rinkinį iš anksto apibrėžti predikatai autentifikuotų metaduomenų perdavimui programinės įrangos tiekimo grandinėse ir tarp jų
Panagrinėkime šiek tiek išsamiau atestacijos formatą.
An Atestavimas yra skaitmeniniu būdu pasirašytas dokumentas kad yra pareiškimai.
Geriausios Pareiškimas yra vidurinis atestacijos sluoksnis, susiejantis ją su konkrečiu Tema ir vienareikšmiškai identifikuojant tipus Predikatas:
- Tema: kriptografiškai saugi nuoroda į artefaktą (paprastai per maišos kodą) ir
- Predikataikonkrečių rinkinys reikalavimai Informacija apie tą artefaktą vadinama teiginiu. Šie teiginiai gali būti naudojami norint išreikšti (ir vėliau įrodyti) bet ką, ką tik galite sugalvoti! Jie gali atspindėti rankinį patvirtinimą, artefakto kilmę, automatizuotų bandymų rezultatus, audito taką ar dar daugiau!
Kai šis pareiškimas yra kriptografiškai pasirašytas, jis vadinamas Atestavimas
Tokiu būdu, pavyzdžiui, Alisa sukuria pareiškimą apie artefaktą ir pasirašo jį naudodama savo privatųjį raktą, sukurdama patvirtinimą.
- Bobas tada gali patikrinkite parašą tame Liudijime, leidžiančiame jam pasitikėti teiginiais viduje.
Bobas gali panaudoti tuos teiginius nuspręsti ar leisti naudoti šį artefaktą, ar ne.
Ar atestacijos galėtų padėti išspręsti apsinuodijimo artefaktais problemą?
Po šios įžangos į atestacijas grįžkime prie savo problemos. Kaip atestacijos gali padėti mums išspręsti problemą, t. y. išvengti apsinuodijimo artefaktais?
Kenkėjiškas vartotojas sugebėjo sukurti artefaktą apeidamas „oficialų“ mechanizmą, t. y. naudodamas savo pipeline kad sugeneruotų artefaktą.
Būtų nuostabu, jei galėtume įrodyti, kad atsisiunčiami artefaktai buvo sukurti naudojant oficialią pipelines. Tai tik vienas pavyzdys to, ką galėtume pavadinti „klastojimo taškais“, tačiau jų gali būti ir daug kitų.
Kaip matote paveikslėlyje aukščiau, yra daug klastojimo taškų. Tokiu būdu vartotojas pipeline (Mūsų pavyzdyje bandymo CI) turi įvertinti kūrimo proceso vientisumas taip pat paties artefakto vientisumas.
Mūsų pavyzdyje užnuodytas artefaktas buvo sukurtas įvedant naują (užnuodytą) pipeline kuris kišasi į kūrimo procesą. Tačiau kenkėjiškas vartotojas galėjo:
- modifikuoti kodą po to, kai jis buvo paimtas iš SCM sugeneruoti kenkėjišką dvejetainį failą
- pakeisti kompiliavimo metu sukurtą teisingą dvejetainį failą bet kokiu kitu kenkėjišku dvejetainiu failu
- pažeisti artefaktų registrą ir įkelti bet kokiu kitu būdu sukurtą užkrėstą artefaktą
- ir taip toliau
Kaip matote, gali būti keli „klastojimo“ taškai.
Kas čia svarbu? Akivaizdu, kad reikia apsaugoti visas tas „klastojimo“ vietas. Bet galiausiai svarbiausia yra... kad artefakto „vartotojas“ galėtų įvertinti artefakto vientisumą ir nuspręsti, ar jį naudoti, ar ne.
Mes galime įvertinti artefakto vientisumą dviem būdais.
Vienas iš jų yra vertinant kilmė artefakto.
Sugeneruojant Kilmės patvirtinimas, pateikiame naudingus metaduomenis (tinkamai patvirtintus ir nepaneigiamus) apie artefaktą. Šiuose pavyzdžiuose naudosime Xygeni druska (Programinės įrangos atestavimo sluoksnis pasitikėjimui) – komponentas, skirtas programinės įrangos atestatams generuoti, registruoti ir tikrinti.
- 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
Aukščiau pateiktame kode matote, kad yra žingsnis, kuris sukuria WAR failą, ir antras žingsnis, kuris generuoja Kilmės patvirtinimasNorėdami tai padaryti, pipeline naudoja privatųjį raktą ir į patvirtinimą įtraukia ir viešąjį raktą.
Užkulisiuose, Xygeni druska komanda saugo patvirtinimą atmintyje vadovėlis (dar žinomas kaip atestacijos registras, įrašas mūsų atveju, bet galite naudoti bet kurį kitą). Tai padaręs, vartotojas pipeline gali apimti Xygeni Patvirtinimo modulis patikrinti artefakto kilmę ir įvertinti artefakto vientisumą.
- 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
Tikrinimo procese įvertinama:
- Geriausios artefaktas sha256sum yra galiojantis (t. y. yra patvirtinimas apie tą „dalyką“) ir
- Geriausios patvirtinimas yra tinkamai autentifikuotas (jis buvo sugeneruotas naudojant tinkamą privatųjį raktą)
Šis patikrinimo procesas gali įvertinti, ar ir artefaktas, ir patvirtinimas yra galiojantys.
Bet, kaip prisimenate, mūsų atveju artefaktą sukūrė „kenkėjiškas“ pipeline (t. y. ne originalas, pagamintas modifikuotu būdu pipeline). Tada turime patikrinti dar vieną aspektą: kad artefaktą sukūrė „originalas“ pipeline, ne bet kuris kitas.
Norėdami tai padaryti, tiesiog įtraukite paprastą eilutę, kad patikrintumėte tą sąlygą, pavyzdžiui:
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
Šis papildomas patikrinimas nepavyks, jei artefaktas nebuvo sugeneruotas mūsų „seifo“ pipeline.
Jei artefaktą sukūrė mūsų originalus pipeline (cicd_top10_3_salt/.github/workflows/build.yml), grep komanda bus sėkminga, kitu atveju ji nepavyks ir sugadins pipeline ir nutraukti bet kokius tolesnius veiksmus.
„Statytojas“ pipeline yra tik vienas patikrinamas klastojimo taškas, tačiau, kaip minėta anksčiau, yra ir kitų klastojimo taškų, kuriuos turėtume patikrinti.
Pavyzdžiui, O jeigu šaltinio kodas buvo pakeistas po saugyklos patikrinimo ir prieš paleidžiant komandą „build“? Šiuo atveju kuriamas kodas nėra toks pat, kaip saugomas SCM.
Šį klastojimo tašką patikrinti taip paprasta, kaip kiekviename žingsnyje patikrinti medžiagos maišos taškus.
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[])
Išvados
Apibendrinant, a Programinės įrangos atestavimas yra teiginys apie programinę įrangą, t. y. autentiškas teiginys (metaduomenys) apie programinės įrangos artefaktą arba programinės įrangos artefaktų rinkinį.
Programinės įrangos atestacijos yra neapdoroto artefakto / kodo pasirašymo apibendrinimas. Atestacija yra pasirašytas dokumentas (nurodytu formatu, paprastai pagrįstu JSON), kuris susieja metaduomenis su artefaktu. Jos yra įrodymai, susiejantys įvestis (medžiagas) ir rezultatus (sukurtus artefaktus) kiekviename kūrimo etape.
Atestacijose pateikiamas patikrinamas galutinių programinės įrangos artefaktų kūrimo veiksmų įrašas, įskaitant kiekvieno žingsnio įvesties medžiagas ir vykdymo kūrimo komandas.
Apibendrinant galima teigti, kad programinės įrangos atestacijos yra puikus mechanizmas, skirtas patikrinti daugelį skirtingų mūsų kūrimo proceso vientisumo aspektų.
Baigėte serialą? Nesijaudinkite! Galite grįžti į „“Apsinuodijęs Pipeline Vykdymas (AAP)“ arba bet koks kitas įrašas, kuris vėl sužadina jūsų susidomėjimą!
Sekite naujienas, mes išsamiai aptarsime programinės įrangos atestacijas ir build security tolesniuose tinklaraščio įrašuose.
