Entegrasyona berdewam û radestkirina berdewam (CI/CD) pipelines bingeha her rêxistineke nermalavê ne ku nermalavê bi awayekî "nûjen" ava dike. Otomasyon hêzek mezin peyda dike, lê piraniya pêşdebiran berpirsiyariya ku ew digire nav xwe ji dest didin.
Developer: Belê, em digirin CI/CD ewlekarî bi ciddî û kontrolek xurt li ser parastvanên kodê hebe, binirxînin commits berî yekbûnê; kar û pipelineji aliyê karmendên payebilind ve têne parastin, ew baldar in ku razên di hundir de neyên eşkerekirin. pipelines. Û amûr ji hêla karmendên ku bi vî karî dizanin ve hatiye sazkirin. Çi dikare xelet biçe?
Pêşdebirê hêja, CI/CD Sîstem tevlihev in. Rûyê êrîşa wê ya fireh aktorên xerab dikişand. Çêtir e ku hûn hişyar bin û qet zêde bawer nekin.
Carinan mîhengên xwerû têne parastin û dibin hevalê herî baş ji bo hackeran. Xeletiyên krîtîk dikarin di CI/CD pipeline çavkaniyan, di mîhengkirina pergalê de, an jî li dora pêvajo û çarçoveya pipeline û çawa ew tê çaksazkirin.
Di vê nivîsê de em ê xwe bixin cihê aktorên xerab. Xeyal bikin ku em ramanên M3M3N70 (Memento Mori?) û Hêrsbûna zozanê li cîhekî di tora tarî de, dibe ku bi zimanekî ne-rojavayî be, lê qet ji bîr nekin ku xerabî li çaraliyê cîhanê belav bûye.
Di demên kevin ên xweş de ew qas hêsan bû…
M3M3N70Vegere bo demên kevin ên baş, karê me pir hêsan bû… Rojên sifir fêkiyên hêsan bûn, sepan vekirî bûn û kêmasiyên wan bi hêsanî dihatin bikaranîn hebûn, û em dikarîn di cih de ber bi alîkî ve biçin.
Hêrsbûna zozanê: Fu#@Hell! Hin kes hîn dîn bûne, lê tişt guherîn. Yên mezin gelek ked dane wê qirêjiya AppSecê.
M3M3N70: Belê. Lê yên nû yên bêaqil pêşdebir in. Ji bo me, hêsantir bûye ku em amûrên ku ev kes bikar tînin hilbijêrin. Bi taybetî CI kaniyeke zêr e! Nîşaneyên gihîştina ewr, SCM bawernameyan, şîfreyên databasa hilberînê, mifteyên taybet ên SSH, bawernameyên bikarhênerên CI yên din… Ber bi tiştên pêşdebirên bêzar ve bazdan ji tiştên rastîn pir hêsan bû.
Otomatîkkirin ji bo çêkirin, ceribandin û bicihkirina nermalavê bi CI/CD Amûr pir caran hewce dike ku razên gav bi gav ji fermanan re veguhezîne. Û pir caran ew têne eşkerekirin, û encamên wan nebaş in.
Pipelinepêdivî bi razên ku carinan derdikevin holê hene
M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.
Dibe ku demên kevin ên baş ew bûn ku di dîroka Git de bibînin .env pelê (pêşdebir ji bîr kir ku wê lê zêde bike) .gitignore):
AWS_ACCESS_KEY_ID=AKIA...AWS_SECRET_ACCESS_KEY=wJalrXUtn...AWS_REGION=us-east-1APP_FOLDER=...S3BUCKET=...
ku di xebata GitHub de hate bikar anîn .github/deploy.yaml ku tiştekî wekî vê dihewîne:
jobs:
build:
name: Automated build and deployment into AWS
runs-on: ubuntu-22.04
steps:
# Load environment from .env file
- id: dotenv
uses: falti/dotenv-action@v1.0.2
- name: Configure AWS Credentials
uses:
with:
args: --acl public-read --follow-symlinks --delete
aws-access-key-id: $
aws-secret-access-key: $
aws-region: $
# ... build steps skipped ...
- name: Upload compiled code for deployment
working-directory: $/packaged_app
run: aws s3 cp my-app.zip s3://$
- name: Deploy the app
run: aws deploy create-deployment ...
M3M3N70: wow! Ew bişkokên aws dixebitin! Me pêşî guhertinek inocuos di sepanê de ceriband, dû re ji ber ku ew kes bêxeber xuya bûn, me sting lê zêde kir. Bingo! Çi kampanyayek…
Aktorê xerab tenê bişkokên AWS bikar anî da ku serîlêdanek guhertî bi malware bar bike û dûv re fermana deploy bi van bawernameyan bixebitîne. Sirên derketî, digel agahdariya ku di nav de heye pipeline"Çi kampanyayek!" dibe ku tê vê wateyê ku Memento wêranî li qurbaniya belengaz xwar.
Tiştê ku Memento li vir ji me re dibêje ev e ku gava rijandina nehênî çêbû, mîna mifteyên gihîştina AWS di mînakê de, divê hûn nehêniyê betal bikin (mifteyên jorîn bizivirînin) derhalHer tim heye pencereya rûdanê di navbera rijandinê de commit û betalkirina veşartî; ji nû ve nivîsandina dîroka Git dijwar e (heta dewleta otorîter a herî dijwar jî hewl da ku dîrokê ji nû ve binivîse, lê bê feyde bû) û dibe ku bêbandor be (dibe ku hevalên me berî depoyê bi rijandina nehênî klon kiribin) commit). Di cih de bişkokan bizivirîne, û dema ku hûn tomarên çalakiyên hesabê hedef dixwînin di pencereya eşkerekirinê de dua bikin!
Dibe ku divê rêxistin qedexekirina bikaranîna razên demdirêj di CI/CD pipelines, û wan bi bawernameyên demkî biguherînin. Di mînaka berê de bi mifteyên AWS di çalakiyên GitHub de, ewletir e ku meriv bikar bîne Pêşkêşvanê OpenID Connect (OIDC) ji bo bidestxistina bawernameyên demkurt ên ku ji bo çalakiyan hewce ne.
Hêrsbûna zozanê: Tu gelek bi şens bûyî! Derxistina skrîptan bi mifteyên kodkirî di demên berê de tiştekî asayî bû, hetta li ser buketên S3 yên ku gihîştina wan ji bo raya giştî jî hebû. Tekane tiştê ku divê tu bikira ev bû ku di nav tiştên di buketê de bigerî û hinek lêgerîn bikî da ku tiştên balkêş bibînî.
Carinan qada ku ji bo bicihkirinê tê bikar anîn (di vê mînakê de kepçeyek AWS S3) ji bo xwendinê ji derve vekirî bû, ji ber xeletiyek mîhengkirinê (ku nehat tespîtkirin). Hêrsbûna zozanê Tiştekî wekî vê dihat bikaranîn:
aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
aws s3 cp s3://<bucket_name>/FNAME - | \
grep '<regex_pattern>'"
Ew kepçe bi îhtimaleke mezin di şabloneke dabînkirinê de hatibe afirandin ku dikare bixweber ji bo kêmasiyên ewlehiyê were şopandin.
Mîhenga xwerû ya amûrê ji bo me pêlîstok bû
Ji bo ku em mînakên konkret bidin, em ê li ser vê yekê biaxivin Jenkins, yek ji amûrên CI yên herî populer.
Hêrsbûna zozanêMa hûn wê qutiya kontrolê ya "Ewlekariyê Çalak Bike" ya li Jenkins bi bîr tînin, û çend rêxistinan ji bo rehetiyê hilbijartin ku wê çalak nekin? Û ew "Her kes dikare her tiştî bike"kombînasyonên destûrnameyê wekî xwerû? Û ew pêvekên Jenkins ên acizker, mîna Pêveka GitHub OAuthKesê ku ew mîheng kir hem "Destûrên Xwendinê bide hemî Bikarhênerên Pejirandî" û hem jî "Destûrên depoya GitHub bikar bîne" hilbijart, û gihîştina hemî projeyên wan da me.
(Ji bo ku min te wek mînak danî, lêborînê dixwazim Jenkins 😉
Li gorî prensîbên ewlehiyê pispor (heta tiryak) bimîne. Yek ji wan ev e Ji hêla xwerû ve ewleh bikin prensîb: divê kontrol bi xwerû li ser mîhengên herî ewle yên gengaz bin. Divê ewlehî di nav de were çêkirin CI/CD alav û pipelineji sifirê heta jor, ne ku wekî ramanek paşîn be. Lê belê bikarhêner-dostane û rehetî pir caran bi ewlehiyê re li hev nakin.
Ji bo doza Jenkins, rastkirina çêkirî pir nazik e: qet mekanîzmayên pejirandinê yên çêkirî yên di Jenkins de bikar neyninÇêtir e ku mekanîzmayeke sêyemîn (SAML, LDAP, Google…) bi pêveka Stratejiya Destûrdayîna Li ser Rolê ("RBAC") hilbijêrin. Û bi pir hişyar bin. admin konto.
Li awayê kar û pipeline pelên di Jenkins de têne birêvebirin. Eynî tişt bi Pêveka Mîhengkirin-wek-Kodê û pelên mîhengê wê, yên ku ji bo mîhengê Jenkins têne sepandin.
Veguhastin ji mêvandariya xweser CI/CD pergalên SaaS-ê yên li ser ewr ber bi yên SaaS-ê yên li ser ewr ve hin xetereyên potansiyel ji holê radike ku rê dide tevgera alî di nav tora rêxistinê de, lê yên din lê zêde dike, wekî vekirina girêdanên derveyî di navbera pergalên navxweyî yên heyî û yên derveyîkirî de CI/CD hacet.
Divê rêxistin pratîkê bikincisbaldariya pêwîst di hişkkirina CI/CD sîstem, bi mîhengên herî sînordar dest pê dike û hêdî hêdî bi destûrên herî kêm ên pêwîst ji bo vekirina pipeline gavên.
Mîhengkirina ewlehiyê di CI/CD Amûr dikarin karekî tevlihev bin. Gelek ji wan pêvek an dirêjkirin hene ku piraniya qelsiyên wan hene û pêdivî ye ku werin nûvekirin.
Skanerên mîhengkirina xelet a ewlehiyê ji bo amûrên wisa tevlihev, an pîvanên benchmarkê dikarin bibin alîkar.
Kodê derzîkirinê tê de pipeline fermanên ji bo kêf û qezencê
M3M3N70Ma te qet Untrusted Code Checkouts bikar aniye, ku çalakî û skrîptên lawaz ên li hember derzîkirina fermanan lawaz in?
Ev beş nîşan dide ku pipeline dibe ku di xwe de xeletiyên kodkirinê hebin ku dihêle aktorên xirab darvekirina koda keyfî têxin hundur pipeline bêyî guhertina pipeline çavkanî bi xweMînakî bi karanîna PR-ê
Nimûneyek yekem a karê GitHubê yê bêbext:
# INSECURE. Provided as an example only.
on:
pull_request_target #1
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: $ #2
- uses: actions/setup-node@v1
- run: |
npm install #3
npm build
# ... more steps ...
Combining pull_request_target tetikandina herikîna kar bi kontrolkirina eşkere ya PR-yek ne pêbawer pratîkek xeternak e ku dibe ku bibe sedema xetereya depoyê. Di mînakê de, têkeliya nexweş a:
pull_request_targetbûyerek, ku bi xwerû destûra nivîsandinê ji bo depoya hedef û razên depoya hedef heye, hetta ji forkên derveyî jî, û di çarçoveya depoya hedef a PR-ê de dimeşe,- koda PR ji çavkaniyê kontrol bike, depoya ne pêbawer,
- her skrîptek çalak bike ku dibe ku li ser naverokên kontrolkirî yên PR-ê bixebite, mîna di rewşa
npm install, û - ne bikaranîna şertek ji bo tetikandinê
pull_request_targetbûyer tenê dê bixebite ger cureyek etîketa 'ev PR hate verastkirin' li PR-ê were destnîşankirin (bikarhênerên derveyî nikarin etîketan li PR-ê destnîşan bikin).
Nimûneyek duyemîn têketinek ne pêbawer digire (ji pirsgirêkek, şîroveyek an pull request) wekî çavkanî ji bo argumanên ku ji bo pipeline ferman bi rêya îfadeyan. Ev e pipeline guhertoya qelsiya derzîkirina fermana OS-ê.
- name: Check title
run: |
title="$"
if [[ ! $title =~ ^.*:\ .*$ ]]; then
echo "Bad issue title"
exit 1
fi
Operasyona xebitandinê li ser bingeha şablonê skrîptek qalikê ya demkî çêdike, bi $ hatiye guhertin, û ew ji bo derzîkirina fermana qalikê xeternak dike. Êrîşkarek bi hesabê GitHub-ê yê sexte dikare pirsgirêkek bi sernavek çêbike. a"; bad_code_goes_here;#, û bum!
Hêrsbûna zozanê: Ax, ew xort bi tenê vekirina pirsgirêkekê deriyê derzîkirina fermanan vedikirin…
Di çalakiyên GitHub de kêmasiyên darvekirina kodê hebûn, mîna şîroveya-gajira, niha rast hatiye kirin. Ji kerema xwe bixwînin "Têketina ne pêbawer di herikên xebatê yên GitHub de" ji bo agahdariya tevahî
Moralê çîrokê: Tu carî bêyî nirxandina PR-ê ji çavkaniyên ne pêbawer PR-an kontrol nekin û ava nekin. 'Ne pêbawer' li vir, heya ku di bin pejirandina hişk a eslê xwe de nebe, dikare were wateya her hesabê pêşdebirê ku potansiyel hatiye dizîn.
Belavkirina malware ya neqesdî li vir!
Dabeşkirina berdewam lûtkeya otomasyonê ye, lê ew lûtke dikare ji ber nebûna kontrolên pejirandinê yên guncaw li ser têk biçe pipeline herrikîn.
Xetereyên bicihkirina bi tevahî otomatîk ji çavkaniyê commit ji bo sîstemên hilberînê îhtîmala belavkirina kodên xerabkar li jîngehên hilberînê bêyî ku werin tespîtkirin, û her weha îhtîmala xeletiyên di pêvajoya belavkirinê de ku bibin sedema astengî an qutbûnên karûbarê vedihewîne.
Ji bo kêmkirina van xetereyan, pir caran tê pêşniyar kirin ku rêxistin di pêvajoya bicihkirina xwe de "navberek dijwar" bicîh bînin, ku pêdivî bi pejirandina mirovî berî ku berdêl li hawîrdorên dawî werin bicîhkirin.
Ew derîyan digirin
Hêrsbûna zozanêEw şîfreyên xwerû yên kêfxweş di nav de CI/CD amûr tên paqijkirin. Gihîştina
/var/lib/jenkins/secrets/initialAdminPasswordniha rêyeke mirî ye. Gelek amûr niha 2FA peyda dikin, ku Covid populer kiriye, û heta meymûnê kodê yê herî tembel jî wê bikar tîne!M3M3N70Em li dijî 2FA şer dikin, lê ew qas hêsan nîne. Zehmet e ku meriv wan kesan bi awayekî spear-phishing bikuje, ji ber ku "Scatter Swine" bi Twilio re kirBi mifteyên WebAuthn pir dijwartir e. Bi kêmanî, em dikarin hewl bidin ku ji bo derbasbûna ji MFA-yê kûkiyan dizînin, lê pêdivî ye ku meriv bikeve nav qutiya pêşdebiran.
Pejirandina Pir-Faktorî gaveke baş e di rêça rast de ji bo sînordarkirina xetera derxistina razên pejirandinê. Piraniya amûrên DevOps ên nûjen MFA piştgirî dikin. Û mifteyên pejirandinê di bin WebAuthn / U2F de (li Projeya FIDO2) dibe ku vebijarka çêtirîn ji bo MFA di DevOps de bin, ger bi rêkûpêk werin rêvebirin.
Hêrsbûna zozanê: Xortên DevOps şiyar dibin. Tişta "îmtiyaza herî kêm" di xwîna wan de heye. Û ew êdî meymûnên kodê nînin. Niha em ji hêla nirxanderan ve di sûc de tên girtin.
Di rastî, pipelineniha ji çend sal berê hinekî xurttir in, bi rakirina çalakî û skrîptên qels, û bi gavên ceribandina ewlehiyê yên zêde ku tewra dropperên me yên bi dizî veşartî tespît kirin. commits û pakêtên ku me revandin.
Pirsek ji bo xwendevan: gelo pêvajoya çêkirina nermalavê ji çavkaniyan û bicihkirina wê bo hilberînê karekî xeternak e? Hûn dikarin DevOps-a xwe di qonaxa... de bibînin? demên xweş ji bo mirovên xerab?
Pêşniyarên Dawîn
Ji ku derê dest pê bikin CI/CD pipelines?
Pêşniyara yekem li vir hêsan e: Bi baldarî axaftin pipelines (ew hene rexneyan çavkanî) ji bo pirsgirêkên ewlehiyê. Nirxandin biha ne lê pêwîst in, û divê bi rêkûpêk werin kirin. Divê nirxander hay ji tiştên ku divê lê binêrin hebin. Divê her gav ji bo kêmasiyên were kontrol kirin.
Dibe ku tevlîheviyek ji nirxanderên pispor ên çekdar bi skanerên kodên zirardar ên otomatîkî re bibe alîkar.
Pêşniyara duyemîn ew e ku pêşdebirên ku dinivîsin perwerde bikin pipelines û wan di ewlehiyê de bihêlinTiştên ku divê werin berçavgirtin:
- Meriv çawa rastkirina nasnameyê bi karûbarên navxweyî û ewr re bi rêkûpêk birêve dibe, da ku ji aciziya birêvebirina bawernameyên demdirêj dûr bikeve.
- Çawa sînordar bikin pipelines ji bo komek çavkaniyên rastîn ên ku ew hewce dike ku bigihîje wan. Prensîba îmtiyaza herî kêm dîsa dibiriqe.
- Meriv çawa gavên çêkirinê dinivîse pipelines dubarekirî mîna pinkirina guhertoyê, û dûrketina ji qelsiyên derzîkirina fermanê.
- Meriv çawa ji perspektîfa ewlehiyê ve bicihkirinan pesend dike (ew yên din in!): kîjan ewlehiyê standarddivê s li hev bên û meriv çawa kontrol/deriyên têkildar di nav de zêde dike pipelines.
Pêşniyareke sêyem ew e ku mîheng bikî CI/CD sîstem bi baldarî. Rastkirina bihêz, bê şîfreyên xwerû an mîhengên neewle, îmtiyazên kêm… Li xalên lawaz ên di pêvek û dirêjkirinên sazkirî de baldar bin. Ev dikare bibe mijara nivîsên jêrîn, ji kerema xwe li bendê bin.
Pêşniyara çaremîn ew e ku leverage the CI/CD pipelines ji bo otomatîkkirina ewlehiyêAnalîza koda çavkaniyê (SAST), analîza pêkhateya çavkaniyê (SCA), skankirina derçûnên razên veşartî, amûrên dijî-malware, skanerên ewlehiya konteynerê, an detektorên dema xebitandinê yên otomatîk (DAST û malware) dikarin bi rêkûpêk li ser werin xebitandin pipelineÛ rêxistina we dikare ferz bike standards derbarê berfirehkirina li ser şopandina ewlehiyê de li CI/CD.
Bînin bîra xwe, ev amûr hîn jî nirxandina pisporan ji hevkêşeyê dûr naxin, wekî din hûn dikarin hestek ewlehiyê ya derewîn hebe.
Eger hûn ji dehên top ên OWASP-ê şareza ne, projeyek nû ya xweş ev e 10 Top OWASP CI/CD Rîska Ewlekariyê.
Têbînî Disclaimer
(1) Nimûneyên di vê postê de GitHub wekî SCM, AWS wekî dabînkerê ewr, û GitHub Actions an Jenkins wekî CI/CD amûr. Ew ji alternatîfên xwe qelstir / ewletir nînin. Niyeta çapemeniyê ya xirab tune! Ev amûr bi hêz in û pêdivî ye ku bi rengek guncaw werin bikar anîn.
(2) M3M3N70 û Hêrsbûna zozanê karakterên xeyalî ne. Her şibandina bi kes an koman re, sax an mirin, tenê tesaduf e… an na?
Ji bo bêtir bixwînin
- Haymore, A. û yên din "10 çîrokên cîhana rastîn ên ka me çawa tawîz daye" CI/CD pipelines ”Koma NCC, Çile 2022.
configure-aws-credentialsÇalakiya GitHub û Mîhengkirina OpenID Connect di Amazon Web Services de ji bo hûrguliyên li ser çawaniya xebitandina fermanên AWS ji bo bicihkirinê di herikên xebatê yên GitHub de.- Lobacevski J. "Ewlekirina Çalakî û herikînên karê GitHub-a we Beş 1: Pêşîlêgirtina daxwazên pwn"Laboratuwara Ewlehiyê ya GitLab, Kanûna Pêşîn 2020.
- Lobacevski J. "Ewlekirina Çalakî û herikînên karê GitHub-a we Beş 2: Têketina ne pêbawer"Laboratuwara Ewlehiyê ya GitLab, Çile 2021.
- OWASP. "OWASP Top 10 CI/CD Rîskên EwlehiyêTîrmeh 2022.
- Saltzer J. û Schroeder M. "Parastina Agahdariyê di Sîstemên Komputerê de"Nîsana 1975. Prensîbên ewlehiyê bi teknolojiyê re pêş ketin, lê piştî 47 salan piraniya ramanên S&S hîn jî di meriyetê de ne.
- NCSC ya Keyaniya Yekbûyî. "Avakirin û bicihkirinê ewle bike" pipeline"Navenda Ewlekariya Sîber a Neteweyî ya Keyaniya Yekbûyî, Sibata 2019an.
