Ներածություն: Ինչու IaC Security Կարևոր է յուրաքանչյուր DevOps թիմի համար
Ենթակառուցվածքը որպես կոդ (IaC) փոխել է միջավայրերի կառուցման և մասշտաբավորման մեր եղանակը։ Մեկ commit, դուք կարող եք տեղակայել ցանցեր, տվյալների բազաներ և ամբողջական ծրագրային փաթեթներ րոպեների ընթացքում: Սակայն նույն արագությունը կարող է աշխատել ձեր դեմ: Terraform-ի, Kubernetes-ի կամ CloudFormation սկրիպտների սխալ կարգավորումները հաճախ արտադրության մեջ են մտնում ավելի արագ, քան ավանդական անվտանգության ստուգումները կարող են արձագանքել: Համաձայն 2024 թվականի Պալո Ալտոյի 42-րդ ստորաբաժանման ամպային սպառնալիքի մասին զեկույց, կազմակերպությունների գրեթե 70%-ը ուներ IaC առնվազն մեկ անվտանգության սխալ կազմաձևմամբ ձևանմուշներ, և այս խնդիրներից շատերը անմիջապես շահագործելի էին։ Ավելին, 2023թ. Red Hat-ի DevSecOps-ի վիճակի մասին զեկույց պարզվել է, որ DevOps թիմերի 55%-ը տեղակայվում է IaC փոփոխություններ՝ առանց հատուկ անվտանգության վերանայման, մեծացնելով թաքնված խոցելիությունների տարածման ռիսկը միջավայրերում։
Սա է պատճառը, IaC security տեղակայման ընթացքում լրացուցիչ քայլից ավելին է։ Իրականում, ճիշտ է ենթակառուցվածքը որպես code security նշանակում է լավագույն փորձի վավերացում և կիրառում անմիջապես ձեր մշակման աշխատանքային հոսքում: Խոսքը վերաբերում է ռիսկային փոփոխականների, չափազանց թույլատրելի IAM քաղաքականության կամ բաց անվտանգության խմբերի որսմանը: մինչեւ նրանք երբևէ կհասնեն ձեր ամպային հաշվին։
Approachիշտ մոտեցմամբ, IaC կիբեր անվտանգությունը դառնում է ձեր ծրագրային ապահովման մշակման կյանքի ցիկլի մի մասը (SDLC)։ Այս կերպ, ձեր IaC Կոդը սկանավորվում է իրական ժամանակում, սխալ կարգավորումները վաղաժամ են հայտնաբերվում, և անվտանգ շտկումները կարող են կիրառվել ավտոմատ կերպով՝ առանց առաքումը դանդաղեցնելու։
Ենթակառուցվածքների իրական ռիսկերի ըմբռնումը որպես կոդ
Եթե դուք նորեկ եք այս գաղափարի մեջ, ծանոթացեք մեր ուղեցույցին «Ներածություն ենթակառուցվածքին որպես կոդ» անվտանգության կողմին անցնելուց առաջ լիարժեք վերլուծության համար։
Ենթակառուցվածքի կոդի ամենամեծ ուժեղ կողմը՝ արագությունն ու հետևողականությունը, նաև դրա ամենամեծ թուլությունն են, երբ անվտանգությունը ներառված չէ։ Terraform սկրիպտում կամ Kubernetes մանիֆեստում մեկ սխալ կարգավորված ռեսուրսը կարող է անմիջապես դառնալ ձեր տեղակայած յուրաքանչյուր միջավայրի մաս։
Սխալ կոնֆիգուրացիաները հազվադեպ դեպքեր չեն, OWASP- ը IaC Security Նախագիծ ընդգծում է, որ IAM-ի չափազանց թույլատրելի դերերը ավտոմատացված տեղակայումների ամենատարածված կրկնվող խնդիրներից մեկն են։
Օրինակ՝ Terraform IAM դեր՝ Wildcard թույլտվություններով
resource "aws_iam_policy" "dangerous_policy" {
name = "dangerous-policy"
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = "*"
Effect = "Allow"
Resource = "*"
}
]
})
}
Առաջին հայացքից սա կարող է թվալ արագ միջոց՝ «պարզապես այն աշխատեցնելու» համար։ Այնուամենայնիվ, այն ձեր հաշվի ամեն ինչին տալիս է ադմինիստրատորի լիակատար մուտք։ IaC-driven աշխատանքային հոսքի միջոցով, այս վատ քաղաքականությունը կարող է վայրկյանների ընթացքում տեղակայվել բոլոր միջավայրերում։
Օրինակ՝ Kubernetes-ի տեղակայումը արտոնյալ ռեժիմով
securityContext:
privileged: true
Այս կարգավորումը թույլ է տալիս կոնտեյներներին աշխատել հոսթինգի մակարդակի թույլտվություններով։ Հետևաբար, եթե հարձակվողը վտանգի ենթարկի պոդը, նա կարող է մեծացնել թույլտվությունները և վերահսկողություն ստանձնել հիմքում ընկած հանգույցի նկատմամբ։
Սրանք վերացական ռիսկեր չեն, դրանք տարածված սխալներ են, որոնք ի հայտ են գալիս իրական արտադրական միջադեպերում: Եվ երբ այս սահմանումները միավորվում են ձեր գլխավոր ճյուղի մեջ, դրանք ավտոմատ կերպով տարածվում են յուրաքանչյուր ապագա տեղակայման վրա:
Հիմնական փախուստ. առանց կանխարգելիչ սկանավորման և ավտոմատացված guardrails, IaC սխալ կարգավորումները կտարածվեն աննկատ՝ շրջանցելով ավանդական աշխատանքային ժամանակի անվտանգությունը գործիքներ.
Շինություն IaC Կիբերանվտանգությունը ձեր աշխատանքային հոսքում
Ձեր ենթակառուցվածքի կոդի պաշտպանությունը չի նշանակում տեղակայումից առաջ միանվագ սկանավորում կատարել։ Այն վերաբերում է ներդրմանը։ IaC security նույն աշխատանքային հոսքերի մեջ, որոնք դուք արդեն օգտագործում եք կոդ գրելու, վերանայելու և ուղարկելու համար: Դա նշանակում է, որ պետք է բռնել ռիսկային կարգավորումները pull requests, միավորումից առաջ անվտանգ փոփոխությունների արգելափակում և ձեր համակարգում լավագույն փորձի ավտոմատ կիրառում CI/CD pipelines.
Պալո Ալտոյի 42-րդ ստորաբաժանման ամպային սպառնալիքի մասին զեկույցը պարզել է, որ Ամպային ռեսուրսների 80%-ը սահմանված է IaC ձևանմուշները պարունակում էին առնվազն մեկ սխալ կարգավորումԱվելի մտահոգիչ է այն, որ դրանց գրեթե կեսը դասակարգվել է որպես բարձր ռիսկային, ինչը նշանակում է, որ դրանք կարող էին անմիջապես շահագործվել տեղակայման դեպքում։ Սա ցույց է տալիս, թե ինչու ենթակառուցվածքը որպես code security պետք է սկսվի նախքան ձեր կոդը արտադրության մեջ մտնի։
հետ IaC կիբեր անվտանգությունը թխված մեջ SDLCԴուք կարող եք,
- Տվյալների հաջորդաբար ընթերցումը IaC Շաբլոններ իրական ժամանակում. Հայտնաբերեք անապահով լռելյայն կարգավորումները, բաց ցանցային միացքները և չափազանց շատ թույլտվությունները՝ դեռևս IDE-ում գտնվելով։
- Պարտադրել guardrails in CI/CD: Արգելափակել տեղակայումները՝ օգտագործելով չհամապատասխանող անվտանգության խմբեր կամ հանրային պահեստավորման դույլեր։
- Ինտեգրվել քաղաքականության կոդի հետ շրջանակներն: Հավասարեցնել ձեր IaC անվտանգության բազային գծերով NIST 800-53 or CIS Չափանիշներ։
- Հայտնաբերել մատակարարման շղթայի ռիսկերըՁեր մեջ ներդրված վնասակար մոդուլների կամ բազային պատկերների նույնականացում և արգելափակում IaC կախվածություններ։
Տեղաշարժվելով IaC Մնացած ստուգումներից հետո դուք այլևս չեք հույսը դնում գործարկման ժամանակի ծանուցումների վրա։ Դրա փոխարեն, դուք համոզվում եք, որ միայն անվտանգ սահմանումները են առաջին հերթին մտնում արտադրության մեջ, և հենց այստեղ է, որ Xygeni-ի նման գործիքները փայլում են։ Փորձեք այն ձեր սեփականում pipeline, Սկսեք անվճար և բռնել IaC security ռիսկերը միավորումից առաջ։
Xygeni-ն սկանավորում է Terraform-ը, Kubernetes, CloudFormation և այլն IaC շրջանակները անմիջապես ձեր մշակման մեջ և CI/CD աշխատանքային հոսքեր: Դուք ստանում եք ակնթարթային արձագանք, արհեստական բանականության վրա հիմնված ավտոմատ շտկման առաջարկներ և անոմալիաների հայտնաբերում՝ ձեր պահոցներում կամ pipeline կարգավորումներ։ Արդյունքում, դուք կանխում եք անվտանգ ենթակառուցվածքների տեղակայումը՝ առանց դանդաղեցնելու ձեր մատակարարման տեմպը։
Ընդհանուր IaC Security Սպառնալիքներ, որոնք դուք չեք կարող անտեսել
Նույնիսկ մեկ IaC Սխալ կոնֆիգուրացիան կարող է հիմք հանդիսանալ խոշոր ամպային խախտման համար: MITRE ATT&CK ամպային մատրիցը փաստաթղթավորում է իրական աշխարհի հարձակվողների տեխնիկաները, որոնք հաճախ սկսվում են անապահով կամ չափազանց թույլատրելի ենթակառուցվածքներից՝ որպես կոդի սահմանումներ: Ստորև ներկայացված են ամենատարածված և ամենավտանգավոր սպառնալիքներից մի քանիսը, ինչպես նաև թե ինչպես: Քսիգենի հայտնաբերում և արգելափակում է դրանք մինչեւ դրանք տեղակայված են։
| Վտանգ | Իրական աշխարհի օրինակ | MITRE ATT&CK քարտեզագրում | Ինչպես է Xygeni-ն հայտնաբերում և արգելափակում այն |
|---|---|---|---|
| Չափազանց թույլատրող IAM քաղաքականություններ | Terraform սկրիպտ, որը տրամադրում է *:* AWS դերի թույլտվություններ, ինչը արդյունավետորեն այն դարձնում է բոլոր ծառայությունների ադմինիստրատոր։ | T1078 – Գործող հաշիվներ | Scans- ը IaC Wildcard IAM թույլտվությունների համար նշում է գերլուսաբանված դերերը և առաջարկում է ամենաքիչ արտոնություններ ունեցող քաղաքականություններ՝ ավտոմատ շտկմամբ։ |
| Հանրային հասանելի պահեստ | S3 դույլ, որը ստեղծվել է public-read ACL-ը, որը զգայուն գրանցամատյանները բացահայտում է ինտերնետին։ | T1530 – Տվյալներ ամպային պահեստավորման օբյեկտից | Հայտնաբերում է Terraform, CloudFormation և ARM ձևանմուշներում անապահով պահեստավորման կոնֆիգուրացիաները նախքան commit կամ PR միաձուլում։ |
| Կոշտ կոդավորված գաղտնիքներ IaC | AWS մուտքի բանալիներ, որոնք ներդրված են Terraform փոփոխականների ֆայլում commitտրվել է Գիտին։ | T1552 – Անպաշտպան հավատարմագրեր | Գործարկում է գաղտնիքների սկանավորումը IaC ֆայլերը, ստուգում է մատակարարի հետ և ավտոմատ կերպով չեղարկում է խախտված հավատարմագրերը։ |
| Անվտանգության խմբի լռելյայն կանոններ | Անվտանգության խումբ՝ 0.0.0.0/0 մուտքային մուտք դեպի 22-րդ պորտ (SSH), որը թույլ է տալիս իրականացնել կոպիտ ուժային հարձակումներ։ | T1021 – Հեռակա ծառայություններ | Նշում է չափազանց լայն ցանցային կանոնները և խորհուրդ է տալիս անվտանգ CIDR տիրույթներ կամ միայն VPN-ով մուտք գործել։ |
| Չգաղտնագրված տվյալներ հանգստի վիճակում | ARM ձևանմուշում առանց կոդավորման կարգավորումների սահմանված Azure սկավառակ։ | T1602 – Տվյալների կոդավորում | Հայտնաբերում է բացակայող կոդավորման դրոշները և ավտոմատ թարմացումները IaC ձևանմուշներ՝ մատակարարի կողմից բնիկ կոդավորումը միացնելու համար։ |
| Անապահով կոնտեյներների կոնֆիգուրացիաներ | Kubernetes տեղակայումը YAML-ով privileged: true է securityContext. | T1613 – Կոնտեյներների կառավարման հրաման | Սկանավորում է K8-ի մանիֆեստները՝ արտոնյալ կոնտեյներներ հայտնաբերելու համար և արգելափակում է միաձուլումները մինչև անվտանգ գործարկման քաղաքականությունների սահմանումը։ |
Ինչու է սա կարևոր.
Ինչպես MITRE ATT&CK ամպային մատրիցն է հստակեցնում, հարձակվողները հաճախ օգտագործում են այս թույլ կողմերը։ Երբ նրանք հայտնվում են, իրավիճակը արագ էսկալացվում։ Հետևաբար, ամենաապահով ռազմավարությունը այս խնդիրները հայտնաբերելն ու շտկելն է ձեր… SDLC, դեռևս ամպում դրանց տեղակայումից շատ առաջ։ Xygeni-ն կիրառում է այս ձախից տեղաշարժման մոդելը՝ արգելափակելով անվտանգ չլինող IaC սահմանումներ commit կամ PR, այլ ոչ թե հույսը դնել ուշ փուլում կատարողականի հայտնաբերման վրա։
Ինչպես է Xygeni-ն կիրառում ենթակառուցվածքները որպես Code Security
Ենթակառուցվածքի կոդի տեսքով անվտանգությունը միայն խնդիրներ գտնելը չէ, այլ դրանք վաղ հայտնաբերելը, արագ շտկելը և համոզվելը, որ դրանք երբեք արտադրության չեն հասնի: Xygeni-ն անվտանգությունը ներառում է անմիջապես ձեր մշակման աշխատանքային հոսքում, ուստի IaC պաշտպանությունը տեղի է ունենում ավտոմատ կերպով։
- Սկանավորել ամեն commit և pull request հայտնաբերելու ռիսկերը, նախքան դրանք կհասնեն ձեր գլխավոր մասնաճյուղ։
- Հայտնաբերվել են բացված տվյալներ, անապահով կարգավորումներ և չստուգված մոդուլներ հենց այնտեղ, որտեղ դուք աշխատում եք։
- ինտեգրել IaC սկանավորում SAST, SCA, եւ Guardrails լրիվ pipeline լուսաբանումը:
- Կիրառեք արհեստական բանականության վրա հիմնված ավտոմատ վերականգնում ռիսկային կարգավորումները ակնթարթորեն շտկելու համար՝ առանց ձեռքով վերամշակման անհրաժեշտության։
Xygeni-ի միջոցով դուք ոչ միայն գտնում եք սխալ կարգավորումներ, որոնք դուք կիրառում եք IaC security քաղաքականությունները իրական ժամանակում, անմիջապես ձեր IDE-ում և CI/CD pipelines.
Իրական աշխարհի օրինակ. Ռիսկային արգելափակում IaC Տեղակայումից առաջ փոփոխություն
Ենթադրենք, որ մշակողը Terraform սկրիպտ է գործարկում՝ աշխարհի համար 22-րդ պորտը բացելու համար։
🚨 Ռիսկային IAM քաղաքականություն — Գրանտներ *:* բոլոր ծառայություններին լիարժեք մուտք
resource "aws_iam_policy" "dangerous_policy" {
name = "dangerous-policy"
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Action = "*"
Effect = "Allow"
Resource = "*"
}
]
})
}
Այս տեսակի կարգավորումը դասական է IaC security կարմիր դրոշ։ Արտադրության մեջ այն թույլ կտար կոպիտ ուժով հարձակումներ իրականացնել ցանկացած վայրից։
Ահա թե ինչ է կատարվում Xygeni-ի առկայության դեպքում.
- Հայտնաբերում commit: մեր ենթակառուցվածքը որպես code security Ձեր PR-ում ստուգումները ավտոմատ կերպով են կատարվում։
- Անհապաղ արձագանք. Վտանգավորը
0.0.0.0/0միջակայքը նշված է ռիսկի հստակ բացատրությամբ։ - Ավտոմատ շտկում. Xygeni-ն առաջարկում է սահմանափակել վստահելի IP տիրույթին մուտքը կամ օգտագործել անվտանգ բաստիոն հոսթինգ։
- Հարկադիր կատարում: CI/CD Guardrail-ը արգելափակում է միաձուլումը մինչև փոփոխությունը չհամապատասխանի քաղաքականությանը։
Դա IaC կիբեր անվտանգությունը գործողության մեջ՝ կանխելով սխալ կոնֆիգուրացիայի մուտքը ձեր արտադրական միջավայր։
Գործողություն ձեռնարկեք. կառուցեք ամուր ենթակառուցվածքներ, ինչպես Code Security
Ապահովելով ձեր ենթակառուցվածքը որպես ծածկագիր այլևս ընտրովի չէ։ IaC security ուղղակիորեն ձևավորում է ձեր ամպային անվտանգության դիրքը, և Terraform-ում, Kubernetes-ում կամ CloudFormation-ում մեկ սխալ քայլը կարող է ձեր միջավայրը ենթարկել հարձակվողների վտանգին։
Ներդրելով ենթակառուցվածքը որպես code security ձեր աշխատանքային հոսքի մեջ դուք՝
- Բռնեք սխալ կարգավորումները, նախքան դրանք արտադրության հասնեն։
- Նաև նվազեցրեք հարձակման մակերեսը ձեր ամպային միջավայրերում։
- Խնայեք ժամանակ՝ արհեստական բանականության վրա հիմնված շտկումներով և ավտոմատացված կիրառմամբ։
Քսիգենիի հետ, IaC կիբեր անվտանգությունը դառնում է միասնական կիբերանվտանգության հարթակի մաս, որը ներառում է ձեր կոդը, կախվածությունները, pipelines, կոնտեյներներ և SCM — բոլորը մեկ տեղում։
