Nima uchun ishlab chiquvchilarga haqiqiy kirishni boshqarish siyosati kerak (nafaqat nazariya)
Agar siz kodni ishlatayotgan bo'lsangiz, uni saqlab turasiz pipelines, yoki artefakt registrlarini boshqarish uchun sizga nazariyadan ko'proq narsa kerak. Zaif yoki aniqlanmagan kirishni boshqarish siyosati repo buzg'unchiligiga olib keladi, CI/CD zo'ravonlik va ma'lumotlarning oshkor bo'lishiDevSecOps shunchaki yashirin ruxsat sozlamalarini emas, balki haqiqiy ijroni talab qiladi.
Kod omborlarida kirishni boshqarish siyosatini samarali boshqarish uchun, CI/CD pipelines, va artefakt registrlari, ko'plab jamoalar Xygeni kabi avtomatlashtirilgan ijro vositalariga tayanadi. Rollarni, ruxsatnomalarni va siyosatga rioya qilishni doimiy ravishda kuzatib borish orqali Xygeni ruxsatlarning o'zgarishi, ruxsatsiz kirish va qo'lda bekor qilishlarning oldini olishga yordam beradi va majburiy kirishni boshqarish nazariyasini amalda qo'llaydi.
Kirishni boshqarish manba kodingizni to'g'ridan-to'g'ri qulflaydi, tuzilishlaringizni himoya qiladi va ishlab chiqarishingizni himoya qiladi pipelineAgar ishlab chiquvchilar boshqaruv elementlarini chetlab o'tishsa yoki xizmat hisoblari keng ruxsatlarga ega bo'lsa, siz xavfsizlik buzilishlariga yo'l ochasiz. Shuning uchun majburiy kirishni boshqarish, MAC kirishni boshqarish va boshqa modellarni tushunish juda muhimdir.
Kirishni boshqarish siyosati turlari Ishlab chiquvchilar bilishi kerak
Kirishni boshqarish siyosati uchta asosiy toifaga bo'linadi, ularning har biri turlicha mos keladi CI/CD ish jarayonlari. Aniqlashtirish uchun qisqacha yonma-yon tahlil:
| model | Kirishni kim nazorat qiladi? | Odatda foydalanish CI/CD | Xavf darajasi |
|---|---|---|---|
| DAC (Ixtiyoriy kirishni boshqarish) | Resurs egasi (ishlab chiquvchi, administrator) | Repozitoriya yoki registrga kirishni qo'lda almashish | Yuqori (inson xatosi) |
| RBAC (Rolga asoslangan kirishni boshqarish) | Tizim rol bo'yicha ruxsatlarni tayinlaydi | GitHub filialini himoya qilish, foydalanuvchi rollariga asoslangan CI ishga kirish | O'rta (noto'g'ri sozlangan rollar) |
| MAC (Majburiy kirishni boshqarish) | Tizim siyosati tomonidan amalga oshiriladi | Artefaktlarni nashr eta oladigan yoki kodni joylashtira oladiganlarni majburlaydi | Past (siyosat foydalanuvchi niyatini bekor qiladi) |
MAC va RBAC ni aniqlashtirish CI/CD Kontekst
Rolga asoslangan kirishni boshqarishni chalkashtirib yuborish oson (RBAC) majburiy kirish nazorati (mac kirish nazorati) bilan, ayniqsa CI/CD muhitlar. Holbuki CI/CD GitHub va GitLab kabi platformalar rollar va ruxsatlarni boshqarish uchun RBAC dan foydalanadi (masalan, kim birlashtirishi yoki joylashtirishi mumkin), bu hali ham asosan rolga asoslangan, haqiqiy MAC kirishni boshqarish emas.
RBAC sizga rollarga (ishlab chiquvchi, texnik xizmat ko'rsatuvchi va boshqalar) asoslangan ruxsatlarni belgilash imkonini beradi, ammo bu ruxsatnomalar hali ham foydalanuvchi tomonidan boshqariladi va o'zgartirilishi mumkin. Noto'g'ri konfiguratsiyalar yoki ruxsatnomalarning ko'payishi keng tarqalgan xavflardir.
Majburiy kirishni boshqarish (MAC kirishni boshqarish), aksincha, tizim yoki infratuzilma darajasida amalga oshiriladi. Foydalanuvchilar, jumladan, administratorlar, uni bekor qila olmaydi. Mac kirishni boshqarishni platformaga o'rnatilgan siyosatlar sifatida tasavvur qiling: bulut provayderlaridagi IAM siyosatlari (masalan, AWS IAM, GCP IAM) yoki SELinux yoki AppArmor kabi OS darajasidagi ijro vositalari. Bunday hollarda, kirish faqat oldindan belgilangan, chetlab o'tib bo'lmaydigan qoidalar bajarilganda beriladi.
In CI/CD, ko'plab vositalar MAC kirishni boshqarish xatti-harakatlarini qat'iy belgilangan IAM rollari yoki resurslarga xos ruxsatnomalar orqali simulyatsiya qiladi, ammo bu to'liq majburiy kirishni boshqarish emas. Haqiqiy majburiy kirishni boshqarishni amalga oshirish dastur sathidan pastda, OT, tarmoq yoki bulut infratuzilmasi darajasida boshqaruvni talab qiladi, bu yerda kirish inson konfiguratsiyasi emas, balki o'zgarmas kirishni boshqarish siyosati bilan boshqariladi.
Rolga asoslangan kirishni boshqarish (RBAC)
RBAC ruxsatlarni "ishlab chiquvchi", "xodim" yoki "reliz menejeri" kabi belgilangan rollarga bog'laydi. Bu GitHub va boshqa vositalarda boshqaruvni soddalashtiradi. GitLabFoydalanuvchini har bir foydalanuvchi uchun sozlash o'rniga, ularni rolga tayinlang va tizim qoidalarni bajarishiga ruxsat bering.
misol: GitHub CODE OWNERS fayli
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Bu faqat tayinlangan rollar muhim kataloglardagi o'zgarishlarni tasdiqlashi mumkinligini ta'minlaydi.
GitLab rol sozlamalari: Sozlamalar > A'zolar bo'limida loyihaga kirishni sozlang:
- Tuzuvchi: Xususiyat shoxlariga surish mumkin.
- Ta'minotchi: Himoyalangan filiallarga birlashishi mumkin.
- Mehmon: Faqat o'qish uchun kirish.
GitHub Actions ish oqimi RBAC misoli:
yaml # .github/workflows/deploy.yml name: Deploy to Production on: push: branches: - main jobs: deploy: if: github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Deploy run: ./scripts/deploy.sh Majburiy kirishni boshqarish (MAC)
Majburiy kirishni boshqarish (MAC kirishni boshqarish) foydalanuvchilar va administratorlar bekor qila olmaydigan qat'iy, tizim darajasidagi qoidalarni amalga oshiradi. Mac kirishni boshqarishdan foydalaning muhim resurslarni kim o'qishi, yozishi yoki bajarishi mumkinligini qat'iy nazorat qilish.
misol: Google Artifact Registry Policy (Soddalashtirilgan YAML)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com misol: Amazon ECR siyosati (soddalashtirilgan YAML)
yaml Version: "2008-10-17" Statement: - Effect: Deny Principal: "*" Action: ecr:PutImage Resource: arn:aws:ecr:region:account-id:repository/my-app Condition: StringNotEquals: aws:userid: ci-service-account Qo'lda bekor qilish xavflari va MAC ularni qanday oldini oladi
RBAC bilan bog'liq eng katta xavflardan biri va DAC modellari qasddan yoki tasodifiy qo'lda bekor qilish ehtimoli mavjud. Masalan, administrator yoki ishlab chiquvchi artefaktlarni to'g'ridan-to'g'ri himoyalangan registrga yuklashi yoki belgilangan kirishni boshqarish siyosatlaridan tashqarida ortiqcha ruxsatnomalar berishi mumkin. Bu harakatlar zaifliklarni keltirib chiqarishi yoki muvofiqlik bo'shliqlarini keltirib chiqarishi mumkin.
Majburiy kirishni boshqarish (MAC kirishni boshqarish) hech bir foydalanuvchi, hatto administratorlar ham chetlab o'tolmaydigan tizim darajasidagi siyosatlarni amalga oshirish orqali bunday bekor qilishlarning oldini oladi. Kirishcisionlar infratuzilmaga o'rnatilgan o'zgarmas qoidalar (masalan, bulutli IAM siyosati yoki OS darajasidagi xavfsizlik modullari) bilan boshqariladi. Bu degani:
- Agar Mac kirishni boshqarish siyosati ularni rad etsa, administrator artefaktlarni registrga qo'lda yuklay olmaydi.
- Foydalanuvchilar belgilangan kirishni boshqarish siyosatlaridan tashqarida imtiyozlarni oshira olmaydi yoki ruxsatnomalarni o'zgartira olmaydi.
- Avtomatlashtirilgan CI/CD pipelines qat'iy ravishda berilgan ruxsatnomalar doirasida ishlaydi, bu esa ko'lamning kengayishiga yo'l qo'ymaydi.
Qo'lda bekor qilishlarni bartaraf etish orqali majburiy kirishni boshqarish faqat RBAC yoki DACga qaraganda kuchliroq va ishonchliroq xavfsizlik holatini ta'minlaydi.
2.4 Ixtiyoriy kirishni boshqarish (DAC)
DAC resurs egalariga ruxsatlarni qo'lda belgilash imkonini beradi. Bu moslashuvchan, ammo xavfli. Bitta noto'g'ri ulashish repoga putur etkazishi mumkin. DAC quyidagicha ishlaydi: "Siz unga egalik qilasiz, kim kirishini o'zingiz hal qilasiz".
misol: a dev tashqi hamkorni taklif qiladi va ularga omborga yozish huquqini beradi. Hamkor xavfli kodni to'g'ridan-to'g'ri ... ga yuboradi ulkan filial.
In CI/CD, DAC har qanday belgilangan kirishni boshqarish siyosatidan tashqarida, konsol orqali vaqtinchalik jamoa a'zosiga ishlab chiqarishni joylashtirishga qo'lda ruxsat beruvchi dasturchiga o'xshab ko'rinishi mumkin.
Haqiqiy hayotda ishlaydigan kirishni boshqarish siyosatini qanday tanlash mumkin Pipelines
Gitda kirishni boshqarish
Ishtirokchi, qo'llab-quvvatlovchi va release rollarini boshqarish uchun RBAC dan foydalaning. Himoyalangan filiallarga birlashtirish huquqlarini qulflang. Imzo talab qilinadi commitva himoya vositalarini chetlab o'tishni cheklash.
Misol: GitHub filialini himoya qilish qoidalari
- Kerak pull request birlashtirishdan oldin sharhlar.
- Eskirganni rad etish pull request yangi bo'lganda tasdiqlashlar commits itariladi.
- Imzo qo'yilgan bo'lishi shart commits.
- Ishlab chiqarish uchun muhim omborlar uchun DACni o'tkazib yuboring. Yozish huquqini beparvolik bilan tarqatmang.
Pipeline Majburlash
Majburiy kirish nazoratini joriy qiling pipelines. Mac kirishni boshqarishning mustahkam modeli CI vazifalarini faqat ularga kerak bo'lgan ruxsatnomalar bilan cheklaydi.
- Sirlarni atrof-muhitga qarab ajrating.
- Har bir muhit uchun noyob tokenlardan foydalaning.
- Qo'lda bajariladigan ishlarning ishlab chiqarishga ta'sir qilishini oldini oling.
misol: CI ishi tasodifan sinov kodini jonli efirga uzatib, bosqichma-bosqich va prod-da joylashtirish tokenini qayta ishlatadi.
Token doirasini boshqarish uchun Mac kirishni boshqarish qoidalarini qo'shing:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Sirlarni qamrab olish misoli: Atrof-muhitga xos tokenlardan foydalanish
Sirlarni atrof-muhit bo'yicha to'g'ri baholash juda muhimdir tasodifiy yoki zararli muhitlararo kirishning oldini olish. Masalan, ishlab chiqish muhiti uchun joylashtirish tokeni hech qachon ishlab chiqarishga joylashtirish uchun ishlatilmasligi kerak.
GitHub Actions’da kirishni boshqarish siyosatiga asoslangan boshqaruv elementlari maxfiy foydalanishni qanday ajratib turishi quyidagicha:
yaml env: DEPLOY_TOKEN_DEV: ${{ secrets.DEPLOY_TOKEN_DEV }} DEPLOY_TOKEN_PROD: ${{ secrets.DEPLOY_TOKEN_PROD }} jobs: deploy-dev: if: github.ref == 'refs/heads/dev' && github.actor == 'developer' runs-on: ubuntu-latest steps: - name: Deploy to Dev run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_DEV }} deploy-prod: if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' runs-on: ubuntu-latest steps: - name: Deploy to Prod run: ./deploy.sh env: TOKEN: ${{ env.DEPLOY_TOKEN_PROD }} Bu quyidagilarni amalga oshirishni ta'minlaydi:
- Faqatgina dasturchi role dev tokenidan foydalanib, joylashtirishlarni ishga tushirishi mumkin ulkan filial.
- Faqatgina nashr menejeri rol ishlab chiqarishga prod tokenidan foydalanib joylashtirilishi mumkin asosiy filial.
Bunday keng qamrovli maxfiy foydalanish muhitlar bo'ylab tokenlarning oqish xavfini kamaytiradi va eng kam imtiyozni joriy qiladi CI/CD pipelines kuchli kirishni boshqarish siyosatiga amal qilish.
Artefaktga kirishni boshqarish vositalari
Majburiy kirishni boshqarish vositasidan foydalanib, artefakt registrlarini qulflang. CI/CD Tizimlar nashriyot bilan shug'ullanishi kerak, individual ishlab chiquvchilar emas.
Muayyan registrlardan qaysi jamoalar foydalanishini aniqlash uchun RBAC dan foydalaning. Ishlab chiquvchilarga faqat ishlab chiqarish paketlariga o'qish huquqi kerak bo'lishi mumkin.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Dasturiy ta'minot ish oqimlarida keng tarqalgan kirishni boshqarishdagi nosozliklar
Haddan tashqari ruxsat etilgan repo kirish
muammo: Juda ko'p foydalanuvchilarga omborlarga yozish/administratorlik huquqini berish.
Bu qanday sodir bo'ladi: Jamoa a'zolari ruxsatnomalar ko'rib chiqilmasdan lavozimga ko'tariladi yoki qo'shiladi. Rollar shishib ketadi.
Hujumchi ekspluatatsiyasi: Hujumchilar bu akkauntlarni o'g'irlangan ma'lumotlar yoki ijtimoiy muhandislik yordamida nishonga olishadi. Ichkariga kirgandan so'ng, ular zararli kodni kiritishi, orqa eshiklarni ochishi yoki izlarni yashirish uchun tarixni o'chirishi mumkin.
Dev va Prod o'rtasida umumiy ruxsatnomalar
muammo: Letting dev va prod pipelines ulashish ruxsatnomalari.
Bu qanday sodir bo'ladi: Jamoalar turli muhitlarda bir xil joylashtirish tokenini yoki CI xizmat hisobini qayta ishlatadilar.
Hujumchi ekspluatatsiyasi: Dasturchi muhitining buzilishi tajovuzkorlarga ishlab chiqarishga kirish huquqini beradi. Majburiy kirish nazorati ruxsatnomalarni ma'lum muhitlarga bog'lash orqali bunga yo'l qo'ymasligi mumkin.
Qo'lda artefakt yuklash
muammo: Ishlab chiqarish registrlariga qo'lda artefakt yuklashga ruxsat berish.
Bu qanday sodir bo'ladi: Dasturchilarni chetlab o'tish pipelines tezkor tuzatishlar yoki issiq yamalar uchun.
Hujumchi ekspluatatsiyasi: Shikastlangan ishlab chiquvchilar mashinalari zararli dasturlarni to'g'ridan-to'g'ri artefakt saqlash joyiga yuklashi mumkin, bu esa barcha CI/CD xavfsizlik tekshiruvlari.
Ro'yxatdan o'tish siyosatini suiiste'mol qilish xavfi: Artefaktlarni qo'lda nashr etish dasturiy ta'minot ta'minoti zanjirida muhim hujum yuzasini yaratadi. Hujumchilar bo'shliqdan foydalanadilar kirishni boshqarish siyosati ishonchli paketlarga yoki konteyner tasvirlariga zararli kodni kiritishi mumkin, bu esa keng tarqalgan keyingi buzilishlarga olib keladi. So'nggi dasturiy ta'minot ta'minoti zanjiridagi hodisalar tartibga solinmagan artefakt yuklashlar tezda katta xavfsizlik buzilishlariga aylanishi va son-sanoqsiz foydalanuvchilar va tizimlarga ta'sir qilishi mumkinligini ko'rsatdi.
Misol: aTo'liq npm registriga kirish huquqiga ega bo'lgan n stajyor xatolik bilan beqaror versiyani nashr qiladi. Agar tajovuzkor stajyorning mashinasini buzgan bo'lsa, ular buning o'rniga zararli dasturlarni nashr etishlari mumkin edi.
Kuchli kirish nazoratini amalga oshirishning amaliy qadamlari
- Rollarni aniq ruxsatnomalarga moslashtiring, barchaga mos keladigan bitta rol sozlamalarini bekor qiling
- Kirishni boshqarish siyosatini tekshirishni avtomatlashtiring CI/CD pipelines
- Majburiy kirish nazorati bilan registrlarni blokirovka qiling
- Muhim tizimlarga kirishni doimiy ravishda qayd eting va kuzatib boring
- Kirishni boshqarish siyosatlariga kod kabi munosabatda bo'ling. Har bir xatodan foydalanish mumkin
Xygeni roli: DevOps ish oqimlarida kirish siyosatini amalga oshirish va monitoring qilish
Xygeniy DevSecOps’dagi real, kundalik kirishni boshqarish siyosatini amalga oshirish muammolarini hal qilish orqali majburiy kirishni boshqarishni nazariyadan amalda qo‘llashga yordam beradi pipelines.
- Haddan tashqari ruxsat berilgan Git kirish muammosini hal qilish: Xygeni Git omborlarini RBAC qoidabuzarliklari, masalan, ko'rib chiqilmagan rol tayinlashlari yoki filial himoyasining yo'qligi uchun doimiy ravishda kuzatib boradi. U kirishni boshqarish siyosati belgilangan qoidalardan chetga chiqqanda ogohlantiradi va tasodifiy birlashishlar yoki zararli PRlarning oldini olish uchun tuzatish choralarini ko'radi.
- Qulflash CI/CD Pipelines: CI ishlari ba'zan mo'ljallanganidan kengroq doiralarda ishlaydi. Xygeni qachon aniqlaydi CI/CD ish o'rinlari o'zlariga tayinlangan rollardan tashqarida so'rovlar berishadi yoki ishlashadi, real vaqt rejimida doiraning kengayishi va imtiyozlarning noto'g'ri ishlatilishini aniqlaydilar. Bu MAC kirishni boshqarish tamoyillarini ichkarida amalga oshirishga yordam beradi pipelinekirishni qat'iy ravishda ishning o'ziga xosligi va maqsadiga bog'lash orqali.
- Artifact nashriyotini boshqarishni amalga oshirish: Agar ishlab chiquvchilar hali ham artefaktlar yoki rasmlarni qo'lda yuklayotgan bo'lsa, Xygeni bunga chek qo'yadi. U faqat tasdiqlangan fayllar uchun registr darajasidagi majburiy kirish nazoratini qo'llaydi. pipeline identifikatsiyalar artefaktlarni nashr qilishi mumkin. Ishlab chiqarish registrlariga endi inson tomonidan yuklash taqiqlanadi.
- Kirish monitoringi va anomaliyalarni belgilash: Xygeni yordamida siz kim nimaga, qachon va qanday kirganini ko'rishingiz mumkin. U noodatiy xatti-harakatlarni aniqlash, noto'g'ri konfiguratsiyalarni belgilash va hodisadan keyingi tahlilga yordam berish uchun maxfiy ma'lumotlardan foydalanishni, omborga kirishni va registr o'zaro ta'sirini doimiy ravishda kuzatib boradi.
Pastki qator: Xygeni kirishni boshqarish siyosatiga avtomatlashtirish va ijroni ta'minlaydi, shuning uchun DevOps muhitingiz sizni sekinlashtirmasdan xavfsiz bo'lib qoladi.
Shunday qilib, kirishni boshqarishni quyidagicha ko'rib chiqing Code Security
Joylashtirish huquqlariga yoki infratuzilmaga kirish huquqiga ega bo'lgan har qanday kishi tasodifan yoki yo'qmi, ilovangizni buzishi mumkin. Shuning uchun mustahkam kirishni boshqarish siyosati ixtiyoriy emas. Rollarni to'g'ri taqsimlash uchun RBAC dan foydalaning. Muhim tizimlarga majburiy kirish nazoratini qo'llang. Ishlab chiqarish yo'llari uchun DAC ni butunlay o'tkazib yuboring. Kirishni boshqarish siyosatini o'zingizga joylashtiring DevSecOpsning eng yaxshi amaliyotlari. Ularni avtomatlashtiring. Kuzating. Majburlang.
TP; DRYaxshi bajarilgan kirishni boshqarish siyosati sizning kod bazangizni, artefaktlaringizni va infratuzilmangizni avtomatik ravishda xavfsizroq qiladi.
