हाम्रो अघिल्लो पोस्टमा यस बारेमा CI/CD Pipelines, हामीले देख्याै कसरी ह्याक गर्ने CI/CD परिदृश्य जुन सम्भवतः संरक्षित थियो।
अघिल्लो पोस्टमा हाम्रो कुरा सम्झौं: हामीले केहीबाट सुरु गर्यौं pipeline जुन जोखिममा थियो अप्रत्यक्ष विषाक्तता Pipeline कार्यान्वयन (I-PPE) र, यसलाई ठीक गर्न, हामीले विभाजन गर्ने निर्णय गर्यौं pipeline दुईमा:
- पहिलो pipeline (बिल्ड CI), D-PPE र I-PPE मा सुरक्षित, PR कोड जाँच गर्नेछ, निर्माण गर्नेछ, र एक कलाकृति उत्पन्न गर्नेछ।
- दोस्रो pipeline (टेस्ट CI), D-PPE र I-PPE को लागि पनि सुरक्षित छ भने, शेल स्क्रिप्ट परिमार्जनबाट बच्नको लागि आधार कोड जाँच गर्नेछ र कलाकृति विरुद्ध मूल स्क्रिप्टहरू कार्यान्वयन गर्नेछ।
- परीक्षण CI लाई सिङ्क्रोनाइज गर्न pipeline निर्माण CI पछि चलाउन pipeline, हामीले प्रयोग गर्यौं कार्यप्रवाह_रन ट्रिगर
हामीले यसलाई परिदृश्य #३ नाम दियौं।
यद्यपि, हामीले त्यो पोस्टमा उल्लेख गरेझैं, अन्य समाधानहरू पनि छन्, हामीले शैक्षिक कारणहरूले गर्दा यो "समाधान" लागू गर्ने निर्णय गर्यौं, ताकि हामी जोखिमहरूमा गहिरो डुब्न सकौं। CI/CD pipelines.
पछि, हामीले यो परिदृश्य कसरी ह्याक गर्ने भनेर देख्यौं कलाकृतिलाई विषाक्त पार्दै। हामी यसलाई भन्छौं कलाकृति विषाक्तता, अर्थात् परिमार्जन (ह्याक) गर्ने क्षमता pipeline परिमार्जन गरेर तर्क pipeline कलाकृति।
यो दृष्टिकोणमा के समस्या छ? हामीले देख्यौं कि समस्या तब उत्पन्न हुन्छ जब कुनै प्रयोगकर्ताले नयाँ "सिर्जना" गर्छ pipeline.
यदि प्रयोगकर्ताले नयाँ समावेश भएको PR खोल्छ भने pipeline, GitHub ले त्यो कार्यान्वयन गर्नेछ pipeline (केही सर्तहरू दिइएको छ, जस्तै हामीले देख्यौं पोस्टमा).
त्यसपछि प्रयोगकर्ताले नयाँ सिर्जना गर्न सक्षम हुन्छ pipeline Build CI को नाम जस्तै !! हो, यो अचम्मको कुरा हो, तर GitHub ले तपाईंलाई दुई सिर्जना गर्न अनुमति दिन्छ pipelineएउटै नाम भएको!!
जब प्रयोगकर्ताले यी परिवर्तनहरू सहितको PR खोल्छ, "नयाँ" pipeline (विषाक्त कलाकृति अपलोड गर्ने) लाई मृत्युदण्ड दिइनेछ। र डिप्लोय CI pipeline त्यसपछि कार्यान्वयन गरिनेछ, जसको परिणामस्वरूप "परिमार्जित" शेल स्क्रिप्टले "मूल" शेल स्क्रिप्टलाई अधिलेखन गर्नेछ। pipeline कार्यस्थान। त्यसैले, यो "समाधान" ले I-PPE जोखिमलाई बेवास्ता गर्दैन (जस्तै हामी तल देख्न सक्छौं)
समस्याहरू के के हुन्? कम्तीमा, केही समस्याहरू छन्:
- पहिलो, निर्माण प्रक्रियामा कुनै हस्तक्षेप गरिएको छैन भनेर कसरी पक्का गर्ने? यस परिदृश्यमा, दुर्भावनापूर्ण प्रयोगकर्ताले तिनीहरूको प्रयोग गरेर अभिप्रेत निर्माण प्रक्रिया परिमार्जन गर्न सक्षम भएको छ pipeline विषाक्त कलाकृति सिर्जना गर्न।
- दोश्रो, हामी कलाकृतिको उत्पत्ति कसरी मूल्याङ्कन गर्न सक्छौं?
यी प्रश्नहरूले हामीलाई सफ्टवेयर प्रमाणीकरणहरू डोमेन!!
सफ्टवेयर प्रमाणीकरणहरू
An प्रमाणीकरण को एउटा टुक्रा हो डाटा प्रतिनिधित्व घटनाको प्रमाण। वास्तविक संसारमा, हामी सामान्यतया यी भन्छौं प्रमाणपत्र.
उदाहरणका लागि, जब प्रयोगशालाले तपाईंको रगत परीक्षण गर्छ, परीक्षणको बारेमा डेटा रेकर्ड गरिन्छ र प्रमाणित गरिन्छ। रगत परीक्षणको नतिजाहरू प्रमाणित र पत्ता लगाउन सकिने.
हाम्रो IT डोमेनको नजिक, तपाईं अनुमान गर्न सक्नुहुन्छ कि यो प्रक्रियाको अनुवाद के हुनेछ, उदाहरणका लागि, संकलन प्रक्रियामा।
संकलन सर्भर वातावरण र उपकरणहरू, सामग्रीहरू (स्रोत कोड), र उत्पादनहरू/कलाकृतिहरू (बाइनरी कोड) बारे जानकारी यस्तो प्रमाणीकरणको अंश हुनेछ।
स्पष्ट रूपमा, विश्वसनीयता प्रदान गर्न प्रमाणीकरण एक अधिकृत प्रमाणक (प्रमाणित र अस्वीकृत) द्वारा उत्पन्न हुनुपर्छ।
सम्भवतः, तपाईंहरू मध्ये कोही सोच्दै हुनुहुन्छ होला .. र के हो हस्ताक्षर र प्रमाणीकरण बीचको भिन्नता?
कोड हस्ताक्षर र प्रमाणीकरण
उच्च स्तरमा, एक हस्ताक्षर कुञ्जी जोडी र कलाकृति प्रयोग गरेर सिर्जना गरिन्छ। कुञ्जी जोडीमा सार्वजनिक कुञ्जी र निजी कुञ्जी हुन्छ।
प्रयोगकर्ताले निजी कुञ्जी प्रयोग गरेर कुनै कलाकृतिमा हस्ताक्षर गर्छ, र अरूले त्यसपछि सार्वजनिक कुञ्जी प्रयोग गरेर हस्ताक्षर प्रमाणित गर्न सक्छन्। निजी कुञ्जी गोप्य राख्नुपर्छ, तर सार्वजनिक कुञ्जी व्यापक रूपमा वितरण गरिन्छ।
हस्ताक्षरहरू प्रयोग गर्न सकिन्छ निजी कुञ्जी धारकले कलाकृतिमा हस्ताक्षर गर्न निजी कुञ्जी प्रयोग गरेको प्रमाणित गर्न.
हस्ताक्षर प्रमाणित नगर्नुहोस्
- प्रयोगकर्ताको इरादा कलाकृतिमा हस्ताक्षर गर्न (तिनीहरूलाई धोका दिइएको हुन सक्छ), वा
- प्रयोगकर्ताको कुनै पनि बनाउने मनसाय कलाकृतिको बारेमा विशिष्ट दाबी
संग प्रयासहरू, सिधै कुनै कलाकृतिमा हस्ताक्षर गर्नुको सट्टा, प्रयोगकर्ताहरूले कुनै प्रकारको सिर्जना गर्छन् दस्तावेज कि उनीहरूको मनसाय समात्छ कलाकृतिमा हस्ताक्षर गर्नु पछाडि र कुनै पनि विशिष्ट दावीहरू यस हस्ताक्षरको अंशको रूपमा बनाइएको।
इन-टुटो प्रमाणीकरण फ्रेमवर्क
सबैभन्दा सामान्य रूपरेखा हो इन-टुटो प्रमाणीकरण फ्रेमवर्क
- परिभाषित गर्दछ standard प्रमाणीकरणको लागि ढाँचा जसले विषयहरू, वर्णन गरिएका कलाकृतिहरूलाई कलाकृतिको बारेमा प्रमाणित मेटाडेटासँग बाँध्छ
- को एक सेट प्रदान गर्दछ पूर्व-परिभाषित भविष्यवाणीहरू सफ्टवेयर आपूर्ति श्रृंखलाहरूमा र भरि प्रमाणित मेटाडेटा सञ्चार गर्नको लागि
प्रमाणीकरण ढाँचाको बारेमा केही विवरणमा जाऔं।
An सत्यापन एक डिजिटल हस्ताक्षर गरिएको कागजात समावेश गर्दछ कथनहरू।
यो विवरण प्रमाणीकरणको बीचको तह हो, यसलाई एक विशेषमा बाँध्दै विषय र स्पष्ट रूपमा प्रकारहरू पहिचान गर्दै भविष्यवाणी गर्नुहोस्:
- विषय: a कलाकृतिको लागि क्रिप्टोग्राफिक रूपमा सुरक्षित सन्दर्भ (सामान्यतया ह्यास मार्फत), र
- भविष्यवाणी गर्छ: विशिष्टहरूको सेट दावी त्यो कलाकृतिको बारेमा कथन भनिन्छ। यी दावीहरू तपाईंले सोच्न सक्ने कुनै पनि कुरा व्यक्त गर्न (र पछि प्रमाणित गर्न) प्रयोग गर्न सकिन्छ! तिनीहरूले म्यानुअल स्वीकृति, कलाकृतिको उत्पत्ति, स्वचालित परीक्षण परिणामहरू, अडिट ट्रेल, वा थप प्रतिनिधित्व गर्न सक्छन्!
जब यो कथन क्रिप्टोग्राफिक रूपमा हस्ताक्षर गरिन्छ, तब यसलाई एक भनिन्छ सत्यापन
यसरी, उदाहरणको रूपमा, एलिसले कुनै कलाकृतिको बारेमा एउटा कथन सिर्जना गर्छिन् र आफ्नो निजी कुञ्जी प्रयोग गरेर त्यसमा हस्ताक्षर गर्छिन्, जसले गर्दा एउटा प्रमाणीकरण सिर्जना हुन्छ।
- त्यसपछि बबले सक्छ हस्ताक्षर प्रमाणित गर्नुहोस् त्यो प्रमाणीकरणमा, उसलाई अनुमति दिँदै दाबीहरूलाई विश्वास गर्न भित्र।
त्यसपछि बबले ती दाबीहरू प्रयोग गर्न सक्छन् निर्णय गर्नु यो कलाकृति प्रयोग गर्न दिने कि नदिने।
के प्रमाणीकरणले कलाकृति विषाक्तता समाधान गर्न मद्दत गर्न सक्छ?
प्रमाणीकरणको यो परिचय पछि, हाम्रो समस्यामा फर्कौं। प्रमाणीकरणले हाम्रो समस्या समाधान गर्न, अर्थात् कलाकृति विषाक्तताबाट बच्न कसरी मद्दत गर्न सक्छ?
दुर्भावनापूर्ण प्रयोगकर्ताले "आधिकारिक" संयन्त्रलाई बाइपास गरेर एउटा कलाकृति सिर्जना गर्न सक्षम भयो, अर्थात् उसको/उनको प्रयोग गरेर pipeline कलाकृति उत्पन्न गर्न।
डाउनलोड भइरहेका कलाकृतिहरू आधिकारिक रूपमा बनाइएको हो भनेर प्रमाणित गर्न सकियो भने यो अद्भुत हुनेछ। pipelines. यो हामीले "छेडछाड बिन्दुहरू" भन्न सक्ने एउटा उदाहरण मात्र हो, तर अरू धेरै हुन सक्छन्।
माथिको तस्वीरमा तपाईंले देख्न सक्नुहुन्छ, छेडछाडका बिन्दुहरू धेरै छन्। यसरी, उपभोक्ता pipeline (हाम्रो उदाहरणमा परीक्षण CI) ले मूल्याङ्कन गर्नुपर्छ निर्माण प्रक्रियाको अखण्डता साथै साथ कलाकृतिको नै अखण्डता.
हाम्रो उदाहरणमा, विषाक्त कलाकृति नयाँ (विषाक्त) परिचय गरेर सिर्जना गरिएको छ। pipeline जसले निर्माण प्रक्रियामा हस्तक्षेप गर्छ। तर दुर्भावनापूर्ण प्रयोगकर्ताले निम्न गर्न सक्थ्यो:
- बाट चेक आउट गरिसकेपछि कोड परिमार्जन गर्नुहोस् SCM दुर्भावनापूर्ण बाइनरी उत्पन्न गर्न
- संकलनद्वारा उत्पादित दायाँ बाइनरीलाई कुनै पनि अन्य दुर्भावनापूर्ण बाइनरीसँग प्रतिस्थापन गर्नुहोस्।
- आर्टिफ्याक्ट रजिस्ट्रीलाई सम्झौता गर्नुहोस् र अन्य कुनै पनि तरिकाले निर्मित विषाक्त कलाकृति अपलोड गर्नुहोस्
- आदि
तपाईंले देख्न सक्नुहुन्छ, त्यहाँ धेरै "छेडछाड" बिन्दुहरू हुन सक्छन्।
यहाँ के महत्त्वपूर्ण छ? स्पष्ट रूपमा ती सबै "छेडछाड" बिन्दुहरूलाई जोगाउन। तर, अन्तमा, सबैभन्दा महत्त्वपूर्ण कुरा के हो भने कलाकृतिको "उपभोक्ता" ले कलाकृतिको अखण्डताको मूल्याङ्कन गर्न सक्छ, र यसलाई अगाडि बढाउने वा नगर्ने निर्णय गर्न सक्छ।
हामी सक्छौ कुनै वस्तुको सत्यता मूल्याङ्कन गर्नुहोस् दुई तरिकामा।
एउटा भनेको मूल्याङ्कन गरेर हो provenance कलाकृतिको।
उत्पन्न गरेर उत्पत्ति प्रमाणीकरण, हामी कलाकृतिको बारेमा उपयोगी मेटाडेटा (राम्रोसँग प्रमाणित र अस्वीकृत) प्रदान गर्छौं। निम्न उदाहरणहरूमा, हामी प्रयोग गर्नेछौं जाइगेनी साल्ट (सफ्टवेयर एटेस्टेसन लेयर फर ट्रस्ट), सफ्टवेयर एटेस्टेसनहरू उत्पन्न गर्ने, दर्ता गर्ने र प्रमाणित गर्ने घटक।
- 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
माथिको कोडमा, तपाईंले देख्न सक्नुहुन्छ कि त्यहाँ एउटा चरण छ जसले युद्ध फाइल निर्माण गर्दछ र दोस्रो चरण जसले उत्पन्न गर्दछ उत्पत्ति प्रमाणीकरण। यो गर्नको लागि, pipeline निजी कुञ्जी प्रयोग गर्दछ र प्रमाणीकरणमा सार्वजनिक कुञ्जी पनि समावेश गर्दछ।
पर्दा पछाडि, जाइगेनीको नमक आदेशले प्रमाणीकरणलाई a मा भण्डारण गर्दछ लेजर (उर्फ प्रमाणीकरण रजिस्ट्री, रेकर्ड हाम्रो मामलामा तर तपाईं कुनै पनि अन्य प्रयोग गर्न सक्नुहुन्छ)। त्यसो गरे, उपभोक्ताले pipeline Xygeni समावेश गर्न सकिन्छ प्रमाणीकरण इन्जिन कलाकृतिको उत्पत्ति प्रमाणित गर्न र कलाकृतिको अखण्डताको मूल्याङ्कन गर्न।
- 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
प्रमाणीकरण प्रक्रियाले मूल्याङ्कन गर्दछ:
- यो कलाकृति sha256sum मान्य छ (अर्थात् त्यो "विषय" को बारेमा प्रमाणीकरण छ), र
- यो प्रमाणीकरण राम्रोसँग प्रमाणित गरिएको छ (यो पर्याप्त निजी कुञ्जी प्रयोग गरेर उत्पन्न गरिएको हो)
यो प्रमाणीकरण प्रक्रियाले त्यसपछि कलाकृति र प्रमाणीकरण दुवै मान्य छन् भनी मूल्याङ्कन गर्न सक्छ।
तर, तपाईंलाई सम्झना छ, हाम्रो मामलामा, कलाकृति "दुर्भावनापूर्ण" द्वारा उत्पन्न गरिएको थियो। pipeline (अर्थात् परिमार्जित द्वारा मूल होइन) pipeline)। त्यसपछि हामीले अगाडि बढेर अर्को पक्ष जाँच गर्नुपर्छ: त्यो कलाकृति "मूल" द्वारा उत्पन्न गरिएको हो। pipeline, अरू कुनै होइन।
त्यसो गर्न, त्यो अवस्था जाँच गर्न एउटा साधारण लाइन समावेश गर्नुहोस्, उदाहरणका लागि:
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
यदि कलाकृति हाम्रो "सुरक्षित" द्वारा उत्पन्न गरिएको थिएन भने यो अतिरिक्त जाँच असफल हुनेछ। pipeline.
यदि कलाकृति हाम्रो मौलिक द्वारा उत्पन्न गरिएको थियो भने pipeline (cicd_top10_3_salt/.github/workflows/build.yml), grep कमाण्ड सफल हुनेछ, अन्यथा, यो असफल हुनेछ, तोड्दै pipeline र थप कुनै पनि चरणहरू रद्द गर्दै।
"निर्माणकर्ता" pipeline जाँच गर्नको लागि केवल एउटा छेडछाड बिन्दु हो तर, पहिले उल्लेख गरिएझैं, हामीले जाँच गर्नुपर्ने केही अन्य छेडछाड बिन्दुहरू छन्।
जस्तै, यदि रिपो चेकआउट पछि र बिल्ड कमाण्ड अघि स्रोत कोडमा छेडछाड गरिएको छ भने के हुन्छ? यस अवस्थामा, निर्माण गरिने कोड भण्डारण गरिएको जस्तै छैन SCM.
यो छेडछाड बिन्दु जाँच गर्न यति सजिलो छ कि हरेक चरणमा सामग्रीको ह्यासहरू जाँच गर्न सकिन्छ।
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[])
निष्कर्ष
संक्षेपमा, एक सफ्टवेयर प्रमाणीकरण सफ्टवेयरको कुनै टुक्राको बारेमा गरिएको दाबी हो, अर्थात् सफ्टवेयर कलाकृति वा सफ्टवेयर कलाकृतिहरूको सङ्ग्रहको बारेमा प्रमाणित कथन (मेटाडेटा)।
सफ्टवेयर प्रमाणीकरणहरू कच्चा कलाकृति/कोड हस्ताक्षरको सामान्यीकरण हो। प्रमाणीकरण भनेको हस्ताक्षर गरिएको कागजात हो (दिइएको ढाँचामा, सामान्यतया JSON मा आधारित) जसले मेटाडेटालाई कलाकृतिसँग सम्बद्ध गर्दछ। तिनीहरूले प्रत्येक निर्माण चरणमा इनपुट (सामग्री) र आउटपुट (उत्पादित कलाकृतिहरू) लाई लिङ्क गर्ने प्रमाण प्रतिनिधित्व गर्छन्।
प्रमाणीकरणहरूले अन्तिम सफ्टवेयर कलाकृतिहरू निर्माण गर्न गरिएका चरणहरूको प्रमाणित रेकर्ड प्रदान गर्दछ, जसमा प्रत्येक चरणको लागि इनपुट सामग्रीहरू र चलाइएका निर्माण आदेशहरू समावेश छन्।
निष्कर्षमा, सफ्टवेयर प्रमाणीकरण हाम्रो निर्माण प्रक्रियाको धेरै फरक अखण्डता पक्षहरू जाँच गर्न एक उत्कृष्ट संयन्त्र हो।
शृङ्खला सकियो? चिन्ता नगर्नुहोस्! 'मा फर्कन नहिचकिचाउनुहोस्।विषाक्त Pipeline कार्यान्वयन (पीपीई)' वा तपाईंको रुचि फेरि जगाउने कुनै अन्य पोस्ट!
सम्पर्कमा रहनुहोस्, हामी सफ्टवेयर प्रमाणीकरणमा गहिरो डुब्नेछौं र build security थप ब्लग पोस्टहरूमा।
