Неліктен әзірлеушілерге нақты кіруді бақылау саясаты қажет (тек теория емес)
Егер сіз кодты басып жатсаңыз, оны сақтайсыз pipelines, немесе артефакт тізілімдерін басқару үшін сізге теориядан артық нәрсе қажет. Әлсіз немесе анықталмаған кіруді бақылау саясаты репозиторийдің бұзылуына әкеледі, CI/CD қорлау және деректер құпиялылығының бұзылуыDevSecOps тек жасырын рұқсат параметрлерін емес, нақты орындауды талап етеді.
Код қоймаларында кіруді басқару саясатын тиімді басқару үшін, CI/CD pipelinesжәне артефактілік тізілімдерінде көптеген топтар Xygeni сияқты автоматтандырылған құқық қорғау құралдарына сүйенеді. Рөлдерді, рұқсаттарды және саясатты сақтауды үздіксіз бақылау арқылы Xygeni рұқсаттардың ауытқуын, рұқсатсыз кіруді және қолмен қайта жазуды болдырмауға көмектеседі, міндетті кіруді бақылау теориясын іс жүзінде қолданады.
Кіруді басқару бастапқы кодыңызды тікелей құлыптайды, құрастыруларыңызды қорғайды және өндірісіңізді қорғайды pipelineЕгер әзірлеушілер басқару элементтерін айналып өтсе немесе қызметтік тіркелгілерде кең рұқсаттар болса, сіз қауіпсіздік бұзушылықтарына жол ашасыз. Сондықтан міндетті кіруді бақылауды, MAC кіруді бақылауды және басқа модельдерді түсіну өте маңызды.
Әзірлеушілер білуі керек кіруді бақылау саясатының түрлері
Кіруді бақылау саясаты үш негізгі санатқа бөлінеді, олардың әрқайсысы әртүрлі CI/CD жұмыс процестері. Нақтылау үшін қысқаша сипаттама берілген:
| моделі | Кіруді кім басқарады? | Әдеттегі қолданылуы CI/CD | Тәуекел деңгейі |
|---|---|---|---|
| DAC (Дискрециялық кіруді басқару) | Ресурс иесі (әзірлеуші, әкімші) | Репозиторийге немесе тізілімге қол жеткізуді қолмен бөлісу | Жоғары (адам қателігі) |
| RBAC (Рөлге негізделген кіруді басқару) | Жүйе рөл бойынша рұқсаттарды тағайындайды | GitHub филиалын қорғау, пайдаланушы рөлдеріне негізделген CI жұмысына қол жеткізу | Орташа (дұрыс конфигурацияланбаған рөлдер) |
| MAC (Міндетті кіруді бақылау) | Жүйелік саясатпен күшіне енген | Артефактілерді жариялай алатын немесе кодты орналастыра алатын адамдарды міндеттейді | Төмен (саясат пайдаланушы ниетін қайта анықтайды) |
MAC және RBAC арасындағы айырмашылықтарды анықтау CI/CD контекст
Рөлге негізделген кіруді басқаруды шатастыру оңай (RBAC) міндетті түрде кіруді бақылаумен (mac кіруді бақылау), әсіресе CI/CD орталар. Әзірге CI/CD GitHub және GitLab сияқты платформалар рөлдер мен рұқсаттарды басқару үшін RBAC пайдаланады (мысалы, кім біріктіре алады немесе орналастыра алады), бұл әлі де негізінен рөлге негізделген, шынайы MAC қатынауды басқару емес.
RBAC рөлдерге (әзірлеуші, қолдау көрсетуші және т.б.) негізделген рұқсаттарды тағайындауға мүмкіндік береді, бірақ бұл рұқсаттарды пайдаланушы басқарады және өзгертуге болады. Дұрыс емес конфигурациялар немесе рұқсаттардың жоғалуы жиі кездесетін қауіптер болып табылады.
Керісінше, міндетті кіруді бақылау (MAC кіруді бақылау) жүйе немесе инфрақұрылым деңгейінде жүзеге асырылады. Әкімшілерді қоса алғанда, пайдаланушылар оны қайта анықтай алмайды. Mac кіруді бақылауды платформаға ендірілген саясаттар деп ойлаңыз: бұлт провайдерлеріндегі IAM саясаттары (мысалы, AWS IAM, GCP IAM) немесе SELinux немесе AppArmor сияқты ОС деңгейіндегі орындау құралдары. Мұндай жағдайларда кіру тек алдын ала анықталған, айналып өтуге болмайтын ережелер орындалған кезде ғана беріледі.
In CI/CD, көптеген құралдар MAC қатынауды басқару әрекетін қатаң ауқымдағы IAM рөлдері немесе ресурстарға тән рұқсаттар арқылы модельдейді, бірақ бұл толық міндетті қатынауды басқару емес. Нақты міндетті қатынауды басқаруды қамтамасыз ету қолданбалы деңгейдің астындағы, ОС, желі немесе бұлттық инфрақұрылым деңгейіндегі басқару элементтерін талап етеді, мұнда қатынау адам конфигурациясымен емес, өзгермейтін қатынауды басқару саясатымен реттеледі.
Рөлге негізделген қатынасты басқару (RBAC)
RBAC рұқсаттарды «әзірлеуші», «қызмет көрсетуші» немесе «шығару менеджері» сияқты анықталған рөлдерге байланыстырады. Ол GitHub және басқа құралдарда басқаруды жеңілдетеді. GitLabПайдаланушыны әр пайдаланушы үшін конфигурациялаудың орнына, оларды рөлге тағайындаңыз және жүйенің ережелерді орындауына мүмкіндік беріңіз.
Мысал: GitHub КОД ИЕЛЕРІ файлы
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Бұл тек тағайындалған рөлдердің ғана маңызды каталогтардағы өзгерістерді бекіте алатынын қамтамасыз етеді.
GitLab рөлінің параметрлері: Жобаға кіруді Параметрлер > Мүшелер бөлімінде конфигурациялаңыз:
- әзірлеуші: Белгі тармақтарына өтуге болады.
- Қызмет көрсетуші: Қорғалған тармақтарға біріктірілуі мүмкін.
- Қонақ: Тек оқуға арналған қолжетімділік.
GitHub Actions жұмыс ағынының RBAC мысалы:
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 Міндетті кіруді бақылау (MAC)
Міндетті кіруді бақылау (MAC кіруді бақылау) пайдаланушылар мен әкімшілер қайта жаза алмайтын қатаң, жүйелік деңгейдегі ережелерді орындайды. Mac кіруді бақылауды пайдаланыңыз маңызды ресурстарды кім оқи, жаза немесе орындай алатынын қатаң бақылау.
Мысал: Google артефакт тізілімінің саясаты (жеңілдетілген YAML)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com Мысал: Amazon ECR саясаты (жеңілдетілген 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 Қолмен қайта орнатудың қауіптері және MAC оларды қалай болдырмайды
RBAC-пен байланысты ең үлкен тәуекелдердің бірі және ЦАТ модельдері әдейі немесе кездейсоқ қолмен қайта жазу мүмкіндігі болып табылады. Мысалы, әкімші немесе әзірлеуші артефактілерді қорғалған тізілімге тікелей жүктей алады немесе анықталған кіруді бақылау саясатынан тыс шамадан тыс рұқсаттар бере алады. Бұл әрекеттер осалдықтарды тудыруы немесе сәйкестік кемшіліктерін тудыруы мүмкін.
Міндетті кіруді бақылау (MAC кіруді бақылау) ешбір пайдаланушы, тіпті әкімшілер де айналып өте алмайтын жүйелік деңгейдегі саясаттарды орындау арқылы мұндай қайта анықтаулардың алдын алады.cisиондар инфрақұрылымға ендірілген өзгермейтін ережелермен басқарылады (мысалы, бұлттық IAM саясаттары немесе ОС деңгейіндегі қауіпсіздік модульдері). Бұл мынаны білдіреді:
- Егер Mac кіруді басқару саясаты оларды қабылдамаса, әкімші артефактілерді тізілімге қолмен жүктей алмайды.
- Пайдаланушылар анықталған кіруді басқару саясатынан тыс артықшылықтарды кеңейте немесе рұқсаттарды өзгерте алмайды.
- автоматтандырылған CI/CD pipelines тек берілген рұқсаттар шеңберінде жұмыс істейді, бұл ауқымның кеңеюіне жол бермейді.
Қолмен қайта орнатуды жою арқылы міндетті кіруді бақылау тек RBAC немесе DAC-қа қарағанда сенімдірек және сенімдірек қауіпсіздікті қамтамасыз етеді.
2.4 Дискрециялық кіруді басқару (DAC)
DAC ресурс иелеріне рұқсаттарды қолмен тағайындауға мүмкіндік береді. Бұл икемді, бірақ қауіпті. Бір қате бөлісу репозиторийге қауіп төндіруі мүмкін. DAC келесідей жұмыс істейді: «Сіз оны иеленесіз, кімнің кіретінін өзіңіз шешесіз».
мысал: а dev сыртқы серіктесті шақырады және оларға репозиторийге жазу құқығын береді. Серіктес қауіпсіз емес кодты тікелей жібереді Dev филиал.
In CI/CD, DAC кез келген анықталған кіруді басқару саясатынан тыс, консоль арқылы уақытша топ мүшесіне өндірісті орналастыруға қол жеткізуді қолмен беретін әзірлеуші сияқты көрінуі мүмкін.
Нақты өмірде жұмыс істейтін кіруді бақылау саясатын қалай таңдауға болады Pipelines
Git бағдарламасындағы кіруді басқару
RBAC көмегімен үлес қосушы, қолдаушы және босату рөлдерін басқарыңыз. Қорғалған тармақтарға біріктіру құқықтарын құлыптаңыз. Қол қоюды талап етіңіз commitжәне қорғанысты айналып өте алатындарды шектейді.
Мысал: GitHub филиалын қорғау ережелері
- Қажет pull request біріктіру алдындағы шолулар.
- Ескіргенді қабылдамау pull request жаңа кездегі мақұлдау commits итеріледі.
- Қол қойылған болуы керек commits.
- Өндірістік маңызды репозиторийлер үшін DAC өткізіп жіберіңіз. Жазу құқығын кездейсоқ бермеңіз.
Pipeline Іске асыру
Міндетті кіруді бақылауды орнатыңыз pipelines. Mac кіруді басқарудың сенімді моделі CI тапсырмаларын тек оларға қажетті рұқсаттармен шектейді.
- Қоршаған орта бойынша құпияларды бөліңіз.
- Әр орта үшін бірегей таңбалауыштарды пайдаланыңыз.
- Қолмен іске қосудың өндіріске әсер етуіне жол бермеңіз.
Мысал: CI тапсырмасы staging және prod арқылы орналастыру токенін қайта пайдаланады, кездейсоқ сынақ кодын іске қосады.
Токен ауқымын басқару үшін Mac кіруді басқару ережелерін қосыңыз:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Құпияларды анықтау мысалы: қоршаған ортаға тән токенді пайдалану
Қоршаған орта бойынша құпияларды дұрыс анықтау өте маңызды кездейсоқ немесе зиянды орта арқылы кірудің алдын алу. Мысалы, әзірлеу ортасына арналған орналастыру токенін ешқашан өндіріске орналастыру үшін пайдалануға болмайды.
GitHub Actions бағдарламасында құпия пайдалануды қалай оқшаулайтынын мына жерден көруге болады:
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 }} Бұл мынаны міндеттейді:
- Тек әзірлеуші рөл әзірлеуші токенін пайдаланып орналастыруларды іске қоса алады Dev филиал.
- Тек шығарылым менеджері рөлді өндіріске prod токенін пайдаланып орналастыруға болады басты филиал.
Мұндай ауқымды құпия пайдалану токендердің ағып кету қаупін орталарда және ең аз артықшылықты қамтамасыз етеді CI/CD pipelines қатал кіруді бақылау саясатын ұстана отырып.
Артефактқа кіруді басқару элементтері
Міндетті кіруді бақылауды пайдаланып, артефактілер тізілімдерін құлыптаңыз. CI/CD жүйелер жеке әзірлеушілер емес, жариялаумен айналысуы керек.
Белгілі бір тізілімдерден қай командалардың алатынын анықтау үшін RBAC пайдаланыңыз. Әзірлеушілерге тек өндірістік пакеттерге оқуға рұқсат қажет болуы мүмкін.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Әзірлеуші жұмыс процестеріндегі жиі кездесетін кіруді басқару ақаулары
Репозиторийге шамадан тыс рұқсат етілген қол жеткізу
Мәселе: Репозиторийлерге жазу/әкімшілік ету құқығын тым көп пайдаланушыларға беру.
Бұл қалай болады: Команда мүшелері рұқсаттар тексерілмей-ақ лауазымы бойынша көтеріледі немесе қосылады. Рөлдер көбейіп кетеді.
Шабуылдаушының эксплуатациасы: Шабуылдаушылар бұл тіркелгілерді ұрланған тіркелгі деректерін немесе әлеуметтік инженерияны пайдаланып нысанаға алады. Ішке кіргеннен кейін олар зиянды кодты енгізе алады, бэкдорларды пайдалана алады немесе іздерін жасыру үшін тарихты жоя алады.
Әзірлеуші мен өнім арасындағы ортақ рұқсаттар
Мәселе: Әзірлеуші мен өнімді жалға беру pipelines бөлісу рұқсаттары.
Бұл қалай болады: Командалар орталарда бірдей орналастыру токенін немесе CI қызмет тіркелгісін қайта пайдаланады.
Шабуылдаушының эксплуатациасы: Әзірлеуші ортасын бұзу шабуылдаушыларға өндіріске кіру мүмкіндігін береді. Міндетті кіруді бақылау рұқсаттарды белгілі бір орталарға байланыстыру арқылы мұның алдын ала алады.
Қолмен артефакт жүктеу
Мәселе: Өндірістік тізілімдерге артефактіні қолмен жүктеуге рұқсат беру.
Бұл қалай болады: Әзірлеушілерді айналып өту pipelines жылдам түзетулер немесе ыстық патчтар үшін.
Шабуылдаушының эксплуатациасы: Бұзылған әзірлеуші машиналар зиянды бағдарламаларды артефакт қоймасына тікелей жүктей алады, бұл барлық мүмкіндіктерді айналып өтеді CI/CD қауіпсіздік тексерулері.
Тіркеу саясатын теріс пайдалану қаупі: Артефактілерді қолмен жариялау бағдарламалық жасақтама жеткізу тізбегінде маңызды шабуыл бетін жасайды. Шабуылдаушылар босаңдықты пайдаланады кіруді бақылау саясаты зиянды кодты сенімді пакеттерге немесе контейнер кескіндеріне енгізуі мүмкін, бұл кең таралған кейінгі бұзушылықтарға әкеледі. Бағдарламалық жасақтама жеткізу тізбегіндегі соңғы оқиғалар реттелмеген артефакттарды жүктеудің сансыз пайдаланушылар мен жүйелерге әсер ететін ірі қауіпсіздік бұзушылықтарына тез арада ұласуы мүмкін екенін көрсетті.
Мысал: аТолық npm тізіліміне кіру мүмкіндігі бар n тағылымдамадан өтуші қателікпен тұрақсыз нұсқаны жариялайды. Егер шабуылдаушы тағылымдамадан өтушінің компьютерін бұзған болса, олар зиянды бағдарламаны жариялай алар еді.
Қатаң кіруді бақылауды қамтамасыз етудің практикалық қадамдары
- Рөлдерді дәл рұқсаттармен салыстырыңыз, барлығына сәйкес келетін бір рөлді орнатудан бас тартыңыз
- Кіруді бақылау саясатын тексеруді автоматтандырыңыз CI/CD pipelines
- Міндетті кіруді бақылау арқылы тізілімдерді құлыптау
- Маңызды жүйелерге кіруді үнемі тіркеу және бақылау
- Қолжетімділікті бақылау саясатын код сияқты қарастырыңыз. Әрбір қатені пайдалануға болады
Xygeni рөлі: DevOps жұмыс процестерінде кіру саясатын орындау және бақылау
Ксигени DevSecOps жүйесіндегі күнделікті нақты қол жеткізуді бақылау саясатын орындау мәселелерін шешу арқылы міндетті қол жеткізуді бақылауды теориядан іс жүзінде қолдануға көмектеседі pipelines.
- Шамадан тыс рұқсат етілген Git қатынасын шешу: Xygeni Git репозиторийлерін RBAC бұзушылықтарына, мысалы, қаралмаған рөлдік тағайындаулар немесе тармақтық қорғаныстың болмауына үздіксіз бақылайды. Ол кіруді басқару саясаты анықталған ережелерден ауытқыған кезде ескертеді және кездейсоқ біріктірулерді немесе зиянды PR-ларды болдырмау үшін түзету әрекеттерін орындайды.
- Құлыптау CI/CD Pipelines: CI жұмыстары кейде көзделгеннен кеңірек ауқымдармен орындалады. Xygeni қашан анықтайды CI/CD жұмыс орындары тағайындалған рөлдерінен тыс сұрайды немесе жұмыс істейді, нақты уақыт режимінде ауқымды кеңейтуді және артықшылықтарды теріс пайдалануды анықтайды. Бұл MAC кіруді басқару принциптерін ішкі деңгейде сақтауға көмектеседі. pipelineқол жеткізуді жұмыстың жеке басы мен мақсатына қатаң байланыстыру арқылы.
- Artifact баспасын басқаруды күшейту: Егер әзірлеушілер әлі де артефактілерді немесе кескіндерді қолмен жүктеп жатса, Xygeni бұған тоқтау салады. Ол тізілім деңгейіндегі міндетті кіруді бақылауды қолданады, осылайша тек тексерілген pipeline Жеке тұлғалар артефактілерді жариялай алады. Өндірістік тізілімдерге енді адам жүктемейді.
- Қолжетімділікті бақылау және ауытқуларды белгілеу: Xygeni көмегімен сіз кімнің неге, қашан және қалай кіргенін көре аласыз. Ол құпияларды пайдалануды, репозиторийге кіруді және тізілім өзара әрекеттесуін үздіксіз бақылап, ерекше әрекеттерді анықтайды, конфигурациялардың дұрыс еместігін белгілейді және оқиғадан кейінгі талдауға көмектеседі.
Төменгі жолда: Xygeni кіруді бақылау саясатына автоматтандыру мен орындауды енгізеді, осылайша сіздің DevOps ортаңыз сізді баяулатпай қауіпсіз болып қалады.
Сонымен, кіруді бақылауды былай қарастырыңыз Code Security
Орналастыру құқықтары немесе инфрақұрылымға қол жеткізу құқығы бар кез келген адам қолданбаңызды кездейсоқ немесе кездейсоқ бұзуы мүмкін. Сондықтан сенімді қол жеткізуді басқару саясаты міндетті емес. Рөлдерді дұрыс бөлу үшін RBAC пайдаланыңыз. Маңызды жүйелерге міндетті кіруді бақылауды қолданыңыз. Өндірістік жолдар үшін DAC-ты толығымен өткізіп жіберіңіз. Кіруді бақылау саясатын сіздің жүйеңізге енгізіңіз DevSecOps-тың ең жақсы тәжірибелері. Оларды автоматтандырыңыз. Бақылаңыз. Оларды орындаңыз.
TL; DRЖақсы орындалған кіруді бақылау саясаты код базаңызды, артефактілеріңізді және инфрақұрылымыңызды автоматты түрде қауіпсіз етеді.
