Ամպային անվտանգության խորհուրդները օգտակար են միայն այն դեպքում, երբ դրանք լուծում են հարձակվողների կողմից շահագործվող իրական բացթողումները՝ ոչ ոքի կողմից նկատված հանրային S3 դույլ, wildcard-ով CI runner։ AWS թույլտվություններ, կառուցման գրանցամատյանում արտահոսած գաղտնիք կամ չարամիտ կախվածություն, որը աննկատ տեղադրվել է pipeline գործարկել: Ամպային անվտանգության միջադեպերի մեծ մասը պայմանավորված չէ անհայտ սպառնալիքներով: Դրանք պայմանավորված են հայտնի թույլ կողմերով, որոնք երբեք չեն կիրառվել, առաջնահերթություն չեն տրվել կամ շտկվել:
Այս ուղեցույցը ներառում է ամպային անվտանգության 20 գործնական խորհուրդ, որոնք դասակարգված են ըստ շերտերի՝ ինքնություն, տվյալներ, ենթակառուցվածք, ծրագրային ապահովման մատակարարման շղթա, CI/CD pipelineներ, հայտնաբերում և միջադեպերի արձագանք: Անկախ նրանից, թե դուք ամրապնդում եք մեկ ամպային հաշիվ, թե ապահովում եք բազմա-թիմային DevSecOps pipeline, այս վերահսկողությունները օգնում են կանխել իրականում տեղի ունեցող խախտումները։
Ինչու է ամպային անվտանգությունը շարունակում ձախողվել՝ չնայած ամպային անվտանգության վերաբերյալ բազմաթիվ խորհուրդների
Ամպային անվտանգությունը կառավարման, քաղաքականության և գործիքների ամբողջություն է, որը պաշտպանում է տվյալները, ծրագրերը և ամպային միջավայրերում աշխատող ենթակառուցվածքները: Այն ընդգրկում է ինքնությունը, ցանցը, տվյալները, ծրագրի կոդը, կախվածությունները, ենթակառուցվածքի կարգավորումը և կառուցվածքը: pipelines.
Այն, որ այն շարունակում է ձախողվել նույնիսկ հասուն թիմերի համար, ոչ թե գիտելիքների պակասն է։ Այն կապված է երեք կառուցվածքային խնդիրների հետ՝
- Արագությունն ընդդեմ անվտանգության։ Pipelineարագ են շարժվում։ Անհարմարություններ առաջացնող կառավարման տարրերը անջատվում են։ Ամպային անվտանգությունը ճիշտ կերպով ապահովող թիմերը դարպասներ չեն ավելացնում, այլ ավտոմատացնում են կիրառումը անմիջապես աշխատանքային հոսքի մեջ։
- Գործիքների մասնատում: Գաղտնիքների սկանավորում մեկ գործիքում, SCA մեկ ուրիշի մեջ, IaC մեկ երրորդում։ Միասնական տեսակետի բացակայությունը նշանակում է, որ ծածկույթի շերտերի միջև կան բացեր, և արդյունքները երբեք չեն համադրվում իրական ռիսկի հետ։
- Զգուշության հոգնածություն։ Սկաներները, որոնք օրական հարյուրավոր CVE-ներ են հայտնաբերում, սովորեցնում են ինժեներներին անտեսել հայտնաբերումները, այդ թվում՝ կարևորագույնները։ Առաջնահերթությունների սահմանումը կամավոր չէ. դա է որոշում, թե արդյոք անվտանգությունն իրականում աշխատում է։
Ստորև բերված ամպային անվտանգության խորհուրդները նախատեսված են այդ բացերը գործնականում լրացնելու համար: Ամպային անվտանգությունը որպես միայն աշխատանքային ժամանակի խնդիր դիտարկելու փոխարեն, դրանք ներառում են կոդից ամպ մատակարարման ամբողջական ուղին:
20 ամպային անվտանգության խորհուրդ.
Անձնագրերի և մուտքի կառավարման ամպային անվտանգության խորհուրդներ
1. Միացրեք բազմաֆունկցիոնալ նույնականացումը ամենուրեք
MFA-ն մնում է ամպային անվտանգության մեջ ամենաբարձր ROI ապահովող միակ վերահսկողությունը։ Այն կանխում է մուտքի տվյալների գողության հարձակումները, և հարձակվողները գիտեն դրա մասին։ MFA չունեցող ցանկացած հաշիվ թույլ թիրախ է։
Կիրառեք MFA-ն ձեր ամպային միջավայրերի յուրաքանչյուր մարդկային ինքնության համար՝ մշակողների հաշիվներ, ադմինիստրատորի կոնսոլներ, ամպային մատակարարների պորտալներ, CI/CD dashboardարտոնյալ հաշիվների համար օգտագործեք ֆիշինգին դիմացկուն MFA (ապարատային բանալիներ, գաղտնաբառեր): Նույնականացման հավելվածի միջոցով ժամանակի վրա հիմնված կոդերը նվազագույն չափանիշն են:
2. Կիրառեք նվազագույն արտոնությունները, հատկապես ոչ մարդկային ինքնությունների նկատմամբ
Նվազագույն արտոնության սկզբունքը լավ հասկանալի է մարդկանց համար։ Թիմերը մշտապես անտեսում են ոչ մարդկային ինքնությունները. CI/CD ծառայության հաշիվներ, Lambda ֆունկցիաներ, կոնտեյներների աշխատանքային բեռներ, GitHub Actions գործարկիչներ։
Այս ինքնությունները կուտակում են wildcard թույլտվություններ, քանի որ դրանք կարգավորվում են մեկ անգամ և այլևս երբեք չեն վերանայվում։ Դրանք նաև հենց այն են, ինչ հարձակվողները թիրախավորում են մատակարարման շղթայի հարձակումների ժամանակ, քանի որ դրանք հասանելիություն ունեն գաղտնիքներին, պահոցներին, արտադրական ռեսուրսներին և հոսանքն ի վար համակարգերին։
Եռամսյակը մեկ անգամ ստուգեք ծառայության հաշվի թույլտվությունները: Հեռացրեք այն ամենը, ինչը չի օգտագործվել 90 օրվա ընթացքում:
3. Երկարատև հավատարմագրերը փոխարինեք կարճատև տոկեններով
Ստատիկ API բանալիները և երկարակյաց տոկենները ամպային խախտումների ամենատարածված արմատական պատճառներից մեկն են։ Դրանք ստանում են commitուղարկվել է պահոցներ, արտահոսել CI գրանցամատյաններում, պատճենվել Slack-ում և մոռացվել .env ֆայլերը, այնուհետև վավեր են մնում ամիսներ կամ տարիներ։
Հնարավորության դեպքում դրանք փոխարինեք կարճատև հավատարմագրերով։ AWS STS-ը ստանձնում է դերը, GCP աշխատանքային ծանրաբեռնվածության նույնականացման ֆեդերացիա, GitHub գործողություններ OIDCԵրբ ստատիկ մուտքային տվյալները անխուսափելի են, պահեք դրանք գաղտնիության կառավարիչում (Vault, AWS Secrets Manager, Azure Key Vault) և ավտոմատ կերպով փոխեք դրանք։
4. Բարձրացված արտոնությունների համար ներդրեք Just-in-Time Access-ը
Մշտական ադմինիստրատորի մուտքը մշտական ռիսկ է։ Մշտական բարձրացված թույլտվությունները նշանակում են, որ մեկ խախտված ինքնությունը բավարար է արտադրությանը հասնելու համար։
JIT մուտքի համակարգերը (AWS IAM Identity Center, GCP Privileged Access Manager, Okta Access Requests) տրամադրում են բարձրացված մուտք պահանջարկի դեպքում, ժամանակի սահմանափակմամբ և ամբողջական աուդիտի գրանցամատյաններով: Մշակողները ստանում են այն, ինչ իրենց անհրաժեշտ է, երբ դա անհրաժեշտ է: Հարձակվողները չեն գտնում որևէ մշտական թիրախ:
5. Զրոյական վստահության կիրառում ծառայությունից ծառայություն հաղորդակցության մեջ
Ավանդական պարագծային մոդելները ենթադրում են, որ ցանցի ներսում ամեն ինչ վստահելի է: Միկրոսպասարկումներով, կոնտեյներներով և դինամիկ աշխատանքային բեռներով ամպային միջավայրերը այդ ենթադրությունը վտանգավոր են դարձնում:
Eroրո վստահություն նշանակում է, որ յուրաքանչյուր հարցում նույնականացվում և լիազորվում է՝ անկախ նրանից, թե որտեղից է այն ծագում: Կիրառեք ծառայությունից ծառայություն նույնականացում (mTLS, ծառայության ցանցի նույնականացում), կիրառեք ցանցային քաղաքականությունը աշխատանքային ծանրաբեռնվածության մակարդակում և ներքին երթևեկությունը համարեք անվստահելի՝ ըստ լռելյայնի:
Տվյալների պաշտպանության ամպային անվտանգության խորհուրդներ
6. Ծածկագրեք ամեն ինչ, այդ թվում՝ ներքին երթևեկությունը
Գաղտնագրումը հանգստի վիճակում (AES-256- ը, կառավարվող KMS) այժմ standard մարզում։ Թիմերի մեծ մասի ունեցած բացը ներքին երթևեկության համար գաղտնագրումը տարանցման ընթացքում.
Միկրոսերվիսներով և կոնտեյներ-կոնտեյներ հաղորդակցությամբ VPC-ում «ներսում» մնացած երթևեկությունը բնույթով անվտանգ չէ: Ներքին ծառայությունների հաղորդակցության համար ներդրեք փոխադարձ TLS (mTLS): Օգտագործեք ծառայությունների ցանց (Istio, Linkerd) կամ զրոյական վստահության ցանցային շերտ՝ սա ավտոմատ կերպով կիրառելու համար, այլ ոչ թե հույսը դնեք յուրաքանչյուր թիմի վրա՝ այն ճիշտ կարգավորելու համար:
7. Հայտնաբերեք և շտկեք բացահայտված գաղտնիքները, նախքան դրանք տարածվեն
Գաղտնիք commitՊահոցին ուղարկվածը գաղտնի չի մնում։ GitHub-ը հանրային պահոցները ինդեքսավորում է վայրկյանների ընթացքում։ Ներքին պահոցները անձեռնմխելի չեն, և երբ գաղտնիքը հայտնվում է git-ի պատմության մեջ, այն հասանելի է պահոցին մուտք ունեցող յուրաքանչյուրին՝ հիմա կամ ապագայում։
Կանխարգելիչ շերտերը կարևոր են (pre-commit hooks, IDE պլագիններ), բայց բավարար չեն: Ձեզ անհրաժեշտ է անընդհատ սկանավորում բոլոր պահոցներում, ներառյալ պատմական commits, CI/CD տեղեկամատյանները, IaC ֆայլեր և կոնտեյներների պատկերներ: Երբ գաղտնիք է հայտնաբերվում, արձագանքը պետք է անհապաղ լինի՝ չեղարկել, պտտել և գնահատել, թե արդյոք դրան մուտք են գործել բացահայտման և հայտնաբերման միջև ընկած ժամանակահատվածում:
8. Դասակարգեք տվյալները և կիրառեք զգայունության վրա հիմնված վերահսկողություններ
Ձեր ամպային միջավայրում բոլոր տվյալները նույն ռիսկը չեն կրում, եթե բացահայտվեն։ Բոլորին նույն կերպ վերաբերվելը նշանակում է չափազանց շատ վերահսկողություն ներդնել ցածր ռիսկային տվյալների մեջ և թերպաշտպանել իրականում կարևոր տվյալները։
Դասակարգեք տվյալները զգայունության աստիճանով (հանրային, ներքին, գաղտնի, սահմանափակված): Կիրառեք մուտքի վերահսկողություն, կոդավորում: standardներ և յուրաքանչյուր մակարդակի համար աուդիտի գրանցման պահանջները: Հնարավորության դեպքում ավտոմատացրեք դասակարգումը, ձեռքով պիտակավորումը չի մասշտաբավորվում:
Ենթակառուցվածքի և կոնֆիգուրացիայի անվտանգություն
9. Սկան IaC ամեն Commit, Ոչ միայն տեղակայումից առաջ
Ենթակառուցվածքը որպես կոդ այն վայրն է, որտեղ ստեղծվում են սխալ կարգավորումներ, այլ ոչ թե արտադրության մեջ: Հանրային S3 դույլ, բաց անվտանգության խումբ կամ IAM դեր՝ *:* թույլտվությունները պատահաբար չեն հայտնվում։ Այն սկսվում է որպես տող Terraform ֆայլում կամ Kubernetes մանիֆեստում, որը ոչ ոք չի նշել։
IaC սկանավորումը պետք է իրականացվի ամեն pull request, կոդի վերանայման աշխատանքային հոսքում հայտնված բացահայտումներով։ Սկանավորեք Terraform-ը, Kubernetes-ի մանիֆեստները, CloudFormation-ը, Helm-ի դիագրամները, Dockerfiles-ը և CI/CD կարգավորումներ
Քսիգենի IaC Security սկանավորում է բոլոր աջակցվող ձևաչափերը commit, համապատասխանեցնում է արդյունքները որոշակի ռեսուրսների հետ և ինտեգրվում է ձեր PR աշխատանքային հոսքի հետ, որպեսզի մշակողները հետադարձ կապ ստանան այնտեղ, որտեղ աշխատում են, այլ ոչ թե առանձին։ dashboard նրանք երբեք չեն բացվում։ Սկսեք անվճար փորձաշրջանը →
10. Անվտանգության քաղաքականությունը դիտարկեք որպես կոդ
Ձեռքով անվտանգության ստուգումները չեն մասշտաբավորվում։ Քաղաքականությունը որպես կոդ՝ մասշտաբավորվում է։
Օգտագործեք OPA-ի (Open Policy Agent) կամ Kyverno-ի նման գործիքներ՝ անվտանգության կանոնները տարբերակված, փորձարկելի կոդի տեսքով արտահայտելու համար: Կիրառեք դրանք հետևյալ հասցեով՝ pipeline մակարդակ, այնպես որ Kubernetes-ի տեղակայումը արտոնյալ: ճշմարիտ կամ root-ի կարգավիճակով աշխատող կոնտեյները ամեն անգամ ավտոմատ կերպով ձախողում է կառուցման գործընթացը։ Երբ քաղաքականությունները գտնվում են կոդում, դրանք վերանայվում և կատարելագործվում են ինչպես ցանկացած ինժեներական արտեֆակտ։ Երբ դրանք գտնվում են փաստաթղթերում, դրանք շեղվում են։
11. Ապահով կոնֆիգուրացիայի բազային գծերի կիրառում և շեղումների վերահսկում
Լռելյայն կարգավորումները օպտիմալացված են հարմարության, այլ ոչ թե անվտանգության համար: Ամպային ծառայությունները, կոնտեյներների աշխատանքային ժամանակները և կառավարվող Kubernetes կլաստերները մատակարարվում են հեշտ օգտագործման և շահագործման կարգավորումներով:
Սկսեք CIS Ձեր ամպային մատակարարի, կոնտեյների աշխատանքային ժամանակի և օպերացիոն համակարգի համար չափորոշիչներ: Կոդավորեք դրանք որպես քաղաքականություն-որպես կոդ, որպեսզի դրանք ավտոմատ կերպով կիրառվեն: Մշտապես վերահսկեք շեղումները, նախորդ շաբաթ կոնֆիգուրացիայի համապատասխանությունը կարող է այսօր չհամապատասխանել ճնշման տակ արագ փոփոխության պատճառով:
12. Սեգմենտային ցանցեր և կողմնային շարժման սահմանափակում
Հարթ ցանցային ճարտարապետությունները նշանակում են, որ երբ հարձակվողը վտանգի է ենթարկում մեկ աշխատանքային բեռ, նա կարող է հասնել մնացած ամեն ինչի։ Ցանցի սեգմենտացիան պարունակում է պայթյունի շառավիղը։
Օգտագործեք VPC-ներ, ենթացանցեր և անվտանգության խմբեր՝ գործառույթի և զգայունության միջոցով մեկուսացման գոտիներ ստեղծելու համար: Սահմանափակեք արևելք-արևմուտք երթևեկությունը ծառայությունների միջև միայն անհրաժեշտի սահմաններում: Կիրառեք ելքային ֆիլտրացիա, վարակված աշխատանքային բեռների մեծ մասը պետք է հասնի հարձակվողի կողմից վերահսկվող սերվերի, և ելքային վերահսկողությունը դա հայտնաբերելու կամ կանխելու լավագույն հնարավորություններից մեկն է:
Ծրագրային ապահովման մատակարարման շղթայի ամպային անվտանգության խորհուրդներ
Ամպային անվտանգության ամենակարևոր խորհուրդներից մի քանիսը այլևս չեն սկսվում ամպային մատակարարի կոնսոլից։ Դրանք սկսվում են ավելի վաղ՝ ծրագրային ապահովման մատակարարման շղթայից։ Կախվածություններ, CI/CD Աշխատանքային հոսքերը, գաղտնիքները, կառուցման սկրիպտները և արտեֆակտները կարող են ամպային ռիսկեր առաջացնել տեղակայումից առաջ։
13. Սկանավորեք բոլոր կախվածությունները, նախքան դրանք կմտնեն ձեր կառուցվածքի մեջ
Բաց կոդով փաթեթները ժամանակակից մատակարարման շղթայի հարձակումներում ամենատարածված սկզբնական մուտքի վեկտորն են: 2024 թվականի Shai-Hulud արշավը վնասել է 830+ npm փաթեթներ: XZ Utils-ի հետին դուռը գրեթե վնասել է SSH նույնականացումը միլիոնավոր Linux համակարգերի վրա: Երկու դեպքում էլ վնասակար կոդը ժամանել է կախվածության տեղադրման սովորական գործընթացի միջոցով:
Հիմնական SCA (Ծրագրային ապահովման կազմի վերլուծություն), CVE-ի հում ցուցակները բավարար չեն: Իրականում ինչ է ձեզ անհրաժեշտ.
- Հասանելիության վերլուծությունխոցելի ֆունկցիան իրականում կանչվա՞ծ է ձեր կոդում։
- Չարամիտ ծրագրերի հայտնաբերումԱյս փաթեթը ցուցաբերո՞ւմ է չարամիտ վարքագիծ, խճճված սկրիպտներ, անսպասելի ցանցային զանգեր, կյանքի ցիկլ։ hooks որոնք տեղադրում են արտաքին գործարկման ժամանակներ։
- EPSS գնահատականՈրքա՞ն է հավանականությունը, որ այս CVE-ն ակտիվորեն շահագործվում է ոչ միայն տեսականորեն, այլև ընդհանրապես։
14. Կողպեք CI/CD Pipelines
CI/CD Համակարգերը հասանելիություն ունեն գաղտնիքներին, ամպային հավատարմագրերին և արտադրական միջավայրերին։ Դրանք նաև սովորաբար ավելի քիչ կարծրացված են, քան այն արտադրական համակարգերը, որոնցում տեղակայվում են։
Կիրառման համար նախատեսված վերահսկողություններ՝
- Պահանջել կոդի վերանայում ցանկացած փոփոխության համար pipeline կոնֆիգուրացիայի ֆայլեր (.github/աշխատանքային հոսքեր/, Ջենկինսֆիլ, Եւ այլն)
- Սահմանափակեք ինքնասպասարկվող վազորդներին հաստատված պահոցներով, չվերանայված վազորդի մուտքը վկայագրերի գողության ուղիղ ուղի է։
- Երբեք գաղտնի տվյալները չփոխանցել որպես պարզ տեքստային միջավայրի փոփոխականներ։ Օգտագործեք գաղտնիությունների կառավարիչի ինտեգրացիա։
- Աուդիտ pipeline անսպասելի հրամանների, անսովոր ցանցային զանգերի կամ անսպասելի ժամերին կատարվող հրամանների գրանցամատյաններ
Քսիգենի CI/CD Անվտանգություն պարտադրում է guardrails ուղղակիորեն ձեր մեջ pipeline , անապահով կառուցվածքների արգելափակում, ներարկված աշխատանքային հոսքերի հայտնաբերում և ապահովում pipeline ամբողջականություն յուրաքանչյուր փուլում։ Պատվիրեք ցուցադրություն →
15. Հաստատեք կառուցվածքի ամբողջականությունը և ստորագրեք արտեֆակտները
Եթե հարձակվողը կարող է կոդ ներարկել կառուցման սկրիպտի մեջ, փոփոխել արտեֆակտը կոմպիլյացիայից հետո կամ վտանգել CI գործարկիչը, ապա նա է ձեր ծրագրային ապահովման մատակարարման շղթայի սեփականատերը՝ անկախ նրանից, թե որքան մաքուր է ձեր սկզբնական կոդը։
Կիրառել կառուցման ամբողջականության վերահսկողությունները՝
- Բոլոր կախվածության տարբերակները և բազային պատկերները ամրացրեք ճշգրիտ ամփոփագրերում, այլ ոչ թե պիտակներում
- Ստորագրեք կառուցման արտեֆակտները և ստուգեք ստորագրությունները տեղակայումից առաջ
- Հետևեք անսպասելի փոփոխությունների CI/CD աշխատանքային հոսքի ֆայլերը, ներարկված աշխատանքային հոսքերը Շայ-Հուլուդի նման հարձակումների հիմնական ցուցիչն էին
- Կիրառել SLSA հավաստագրեր՝ կրիպտոգրաֆիկորեն ապացուցելու համար, թե ինչ է կառուցվել, ինչ աղբյուրից և ինչի կողմից։ pipeline
Սպառնալիքների հայտնաբերում և միջադեպերի արձագանք
16. Կենտրոնացրեք գրանցումը և ստեղծեք տեսանելիություն ամբողջ ստեքում
Դուք չեք կարող հայտնաբերել այն, ինչ չեք կարող տեսնել: Ամպային անվտանգության մոնիթորինգի մեծ մասը կենտրոնանում է կատարման ժամանակի, CloudTrail-ի, VPC հոսքի գրանցամատյանների, GuardDuty-ի վրա: Դա անհրաժեշտ է, բայց բավարար չէ:
Shai-Hulud-ի և SolarWinds-ի նման հարձակումները հաջողության հասան մասամբ այն պատճառով, որ վնասը տեղի է ունեցել կառուցման ընթացքում։ pipeline, շատ ավելի վաղ, քան որևէ բան հասավ արտադրության մոնիթորինգին։ Լրիվ տեսանելիությունը պահանջում է ծածկույթ սկզբնական կոդի փոփոխությունների, կառուցման և արտեֆակտների շերտերի, ամպային աշխատանքային ժամանակի և API գործունեության համար։
17. Արդյունքները դասակարգեք շահագործելիության, այլ ոչ թե միայն ծանրության հիման վրա
Շաբաթական 500 արդյունք ստեղծող սկաները թիմերին սովորեցնում է անտեսել արդյունքները, այդ թվում՝ կարևորագույնները: Առաջնահերթությունների սահմանումն է այն, ինչը տարբերակում է գործող անվտանգության ծրագրերը թղթի վրա գոյություն ունեցողներից:
Արդյունավետ առաջնահերթությունների սահմանումը համատեղում է. հասանելիությունը (խոցելի կոդը իրականում կատարվո՞ւմ է), տեսանելիությունը (ծառայությունը ինտերնետին միացված է՞), EPSS գնահատականը (ակտիվ շահագործման հավանականությունը) և բիզնես համատեքստը (արտադրությունն ընդդեմ մշակողների միջավայր):
Xygeni ASPM բերում է բոլոր հայտնագործությունները SAST, SCA, IaC, գաղտնիքներ և pipeline security միասնական ռիսկերի տեսանկյունից՝ համատեքստային առաջնահերթություններով, որը ձեր թիմին ճշգրիտ ասում է, թե առաջին հերթին ինչ շտկել։ Պատվիրեք ցուցադրություն →
18. Սահմանեք վարքային բազային գծեր և զգուշացրեք շեղումների դեպքում
Հայտնի-վատ ստորագրությունները որսում են հայտնի սպառնալիքները: Վարքային անոմալիաների հայտնաբերումը որսում է անհայտները, զրոյական օրերը, նոր հարձակման օրինաչափությունները, ներքին սպառնալիքները:
For Your CI/CD միջավայրում, սահմանեք բազային գծեր կառուցման տիպիկ տևողության, փաթեթների տեղադրման սովորական ձևերի, կառուցման ընթացքում սպասվող ցանցային ուղղությունների և standard Գաղտնիքներին մուտք գործելու օրինաչափություններ: Այս բազային գծերից շեղումները ձեր ամենավաղ նախազգուշացման ազդանշանն են, և այն շերտը, որտեղ թիմերի մեծ մասը զրոյական տեսանելիություն ունի:
19. Սահմանեք Runbook-եր ամպային միջադեպերի սցենարների համար
Միջադեպերին արձագանքման ընդհանուր պլանները չեն հաշվի առնում ամպային սցենարները՝ 40 ծառայություններում արդեն տեղադրված վնասված փաթեթ, վնասակար նախնական տեղադրման սկրիպտի կողմից գողացված մուտքային տվյալներով CI գործարկիչ, կառուցման արտեֆակտ, որը կարող է կեղծված լինել վերջին 72 ժամվա ընթացքում։
Ստեղծեք հատուկ runbook-եր հետևյալի համար՝ խախտված կախվածություն, pipeline Հավատարմագրերի գողություն, սխալ կոնֆիգուրացիայի հետևանքով առաջացած տվյալների բացահայտում և չարամիտ CI աշխատանքային հոսքի ներարկում: Յուրաքանչյուր runbook պետք է սահմանի, թե ում է պատկանում պատասխանը, ինչն է անմիջապես չեղարկվում և ինչ դատաբժշկական փորձաքննություններ են անհրաժեշտ պայթյունի շառավիղը որոշելու համար:
20. Գործարկեք սեղանի վարժությունըcisէս, տարեկան առնվազն երկու անգամ
Չփորձարկված runbook-ը վարկած է։cisբացահայտեք ձեր արձագանքման պլանի բացթողումները, նախքան հարձակվողը դա կանի։ Նպատակը գործողության ձեռնարկին կատարելապես հետևելը չէ, այլ բացահայտելն է, թե ինչն է բացակայում։
Կատարեք առնվազն երկու վարժությունcisտարեկան՝ մոդելավորելով տարբեր սցենարների տեսակներ՝ մատակարարման շղթայի խախտում, սխալ կոնֆիգուրացիայի պատճառով տվյալների արտահոսք, CI համակարգի խախտված համակարգ։ Ներառեք այն թիմերը, որոնք իրականում կարձագանքեն, անվտանգության, DevOps-ի և հերթապահ մշակողների։
Ամպային անվտանգության խորհուրդների ցանկ. Հակիրճ հղումներ
| շերտ | Հիմնական կառավարման տարրեր |
|---|---|
| Ինքնություն | Արտաքին գործերի նախարարություն ամենուրեք, նվազագույն արտոնություններ, կարճատև լիազորություններ, JIT մուտք |
| Ամսաթիվ | Ծածկագրում՝ ինչպես հանգստի, այնպես էլ տեղափոխման ժամանակ, գաղտնիության սկանավորում և ավտոմատ չեղարկում, տվյալների դասակարգում |
| Ենթակառուցվածքներ | IaC սկանավորումը միացված է commit, քաղաքականությունը որպես կոդ, CIS բազային գծի կիրառում, ցանցի սեգմենտացիա |
| Մատակարարման շղթա | SCA հասանելիության և վնասակար ծրագրերի հայտնաբերման միջոցով, CI/CD կարծրացում, կառուցողական ամբողջականություն և SLSA |
| Հայտնաբերում | Կենտրոնացված գրանցում, EPSS-ի վրա հիմնված առաջնահերթություն, վարքային անոմալիաների հայտնաբերում |
| պատասխան | Ամպային վազքի համար նախատեսված գրքեր, սեղանի վրա տեղադրվող վարժություններcises, պայթյունի շառավղի փաստաթղթավորված գնահատում |
Ինչպես է Xygeni-ն օգնում կիրառել ամպային անվտանգության խորհուրդները ամբողջ փաթեթում
Ամպային անվտանգության խորհուրդները գործում են միայն այն դեպքում, երբ թիմերը կարող են դրանք հետևողականորեն կիրառել ծրագրային ապահովման մատակարարման ողջ կյանքի ցիկլի ընթացքում: Գործիքների մեծ մասը ներառում է մեկ շերտ՝ աշխատանքային ժամանակ, կոդ, կախվածություններ, գաղտնիքներ կամ CI/CDԲայց իրական հարձակումները տեղի են ունենում տարբեր շերտերով։
Xygeni-ն այս շերտերը կապում է ինտեգրված հայտնաբերման, առաջնահերթության սահմանման և վերականգնման միջոցով՝ առաջին git push-ից մինչև արտադրություն։
| շերտ | Xygeni-ի կարողություն | Ինչն է այն կանխում |
|---|---|---|
| Source կոդը | SAST + Արհեստական բանականության վերականգնում | Ներարկում, վավերացման ձախողումներ, անապահով դիզայն |
| Կախվածություններ | SCA + Վնասակար ծրագրերի հայտնաբերում + EPSS | Մատակարարման շղթայի խախտումներ, խոցելի փաթեթներ |
| Secrets | Գաղտնիքներ Անվտանգություն + Ավտոմատ Չեղարկում | Հավատարմագրման ազդեցություն, երկարատև տոկենային ռիսկ |
| IaC & Կարգավորել | IaC Security | Սխալ կարգավորումներ՝ մինչև արտադրության հասնելը |
| CI/CD Pipeline | CI/CD Անվտանգություն + Անոմալիաների հայտնաբերում | Pipeline ներարկում, վազորդի խանգարում |
| Կառուցեք արտեֆակտներ | Build Security + SLSA provenance | Կեղծված արտեֆակտներ, չստորագրված հաղորդագրություններ |
| Ռիսկի դիրք | ASPM | Միասնական տեսք, խաչաձև առաջնահերթություն |
Արդյունքը՝ անվտանգության թիմերը ազդանշան են ստանում աղմուկի փոխարեն։ Մշակողները հետադարձ կապ են ստանում այնտեղ, որտեղ աշխատում են, այլ ոչ թե առանձին գործիքով, որը երբեք չեն բացում։ Եվ անվտանգությունը դառնում է գործընթացի մի մասը, այլ ոչ թե դարպաս, որը դանդաղեցնում է այն։
Վերջնական Մտքեր
Ամպային անվտանգության խորհուրդները հեշտ է թվարկել, բայց ավելի դժվար է կիրառել։ Իրական ամպային ռիսկերը նվազեցնող թիմերը չեն հիմնվում ձեռքով վերանայումների, ցրված գործիքների կամ միայն ծանրության վրա հիմնված առաջնահերթությունների վրա։ Դրա փոխարեն նրանք ավտոմատացնում են անվտանգության վերահսկողությունը ներսում։ pipelines, առաջնահերթություն տալ շահագործման հնարավորությամբ և ծրագրային ապահովման ամբողջական մատակարարման շղթան դիտարկել որպես ամպային հարձակման մակերեսի մի մաս։
Դա նշանակում է ապահովել ոչ միայն աշխատանքային ժամանակի ենթակառուցվածքը։ Դա նշանակում է պաշտպանել սկզբնական կոդը, կախվածությունները, գաղտնիքները, IaC, CI/CD աշխատանքային հոսքերը, արտեֆակտների կառուցումը և կիրառման ռիսկի դիրքորոշումը միասին։
Եթե ձեր ներկայիս գործիքները բացեր են թողնում այդ շերտերի միջև, Xygeni-ն օգնում է դրանք փակել՝ կոդից մինչև ամպ ինտեգրված հայտնաբերման, առաջնահերթության սահմանման և վերականգնման միջոցով։
???? Սկսեք ձեր 7-օրյա անվճար փորձաշրջանը , վարկային քարտ անհրաժեշտ չէ, սկանավորման արդյունքները րոպեների ընթացքում
???? Գիրք ցուցադրում և տեսեք, թե ինչպես է Xygeni-ն կապվում ձեր կոնկրետ ամպի հետ և pipeline մատչ
Հեղինակի մասին
Համահիմնադիր և տեխնիկական տնօրեն
Ֆաթիմա Said մասնագիտացած է AppSec, DevSecOps և այլ մշակողների համար նախատեսված բովանդակության մեջ։ software supply chain securityՆա բարդ անվտանգության ազդանշանները վերածում է հստակ, գործնական ուղեցույցի, որը օգնում է թիմերին ավելի արագ որոշել առաջնահերթությունները, նվազեցնել աղմուկը և ուղարկել ավելի անվտանգ կոդ։
