Чаму распрацоўшчыкам патрэбныя рэальныя палітыкі кантролю доступу (а не толькі тэорыя)
Калі вы пішаце код, падтрымліваючы pipelineабо кіраванне рэестрамі артэфактаў, вам патрэбна больш, чым тэорыя. Слабыя або неакрэсленыя палітыкі кантролю доступу спрыяюць умяшанню ў рэпазіторыі, CI/CD злоўжыванні і уцечкі ўліковых дадзеныхDevSecOps патрабуе рэальнага выканання, а не проста схаваных налад дазволаў.
Каб эфектыўна кіраваць палітыкамі кантролю доступу ў розных рэпазіторыях кода, CI/CD pipelines, і рэестры артэфактаў, многія каманды абапіраюцца на аўтаматызаваныя інструменты забеспячэння выканання, такія як Xygeni. Дзякуючы пастаяннаму маніторынгу роляў, дазволаў і выканання палітык, Xygeni дапамагае прадухіліць дрэйф дазволаў, несанкцыянаваны доступ і ручное перавызначэнне, ператвараючы тэорыю абавязковага кантролю доступу ў практыку.
Кантроль доступу непасрэдна блакуе ваш зыходны код, абараняе вашы зборкі і аберагае вашу прадукцыйнасць pipelineКалі распрацоўшчыкі абыходзяць элементы кіравання або ўліковыя запісы службаў маюць шырокія дазволы, вы адкрываеце дзверы для парушэнняў бяспекі. Вось чаму разуменне абавязковага кантролю доступу, кантролю доступу па MAC-адрасе і іншых мадэляў мае вырашальнае значэнне.
Тыпы палітык кантролю доступу, якія павінны ведаць распрацоўшчыкі
Палітыкі кантролю доступу падзяляюцца на тры асноўныя катэгорыі, кожная з якіх па-рознаму падыходзіць для CI/CD працоўныя працэсы. Вось кароткі разбор для ўдакладнення:
| мадэль | Хто кантралюе доступ? | Тыповае выкарыстанне ў CI/CD | Узровень рызыкі |
|---|---|---|---|
| DAC (дыскрэцыйны кантроль доступу) | Уладальнік рэсурсу (распрацоўшчык, адміністратар) | Ручны доступ да рэпазітара або рэестра | Высокі (чалавечая памылка) |
| RBAC (кіраванне доступам на аснове роляў) | Сістэма прызначае дазволы па ролях | Абарона галінак GitHub, доступ да заданняў CI на аснове роляў карыстальнікаў | Сярэдні (няправільна настроеныя ролі) |
| MAC (абавязковы кантроль доступу) | Прымяняецца сістэмнай палітыкай | Вызначае, хто можа публікаваць артэфакты або разгортваць код | Нізкі (палітыка мае перавагу над намерам карыстальніка) |
Удакладненне MAC і RBAC у CI/CD Кантэкст
Лёгка пераблытаць кантроль доступу на аснове роляў (РБАК) з абавязковым кантролем доступу (кантроль доступу 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
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Гэта гарантуе, што толькі прызначаныя ролі могуць ухваляць змены ў крытычна важных каталогах.
Налады ролі GitLab: Наладзьце доступ да праекта ў раздзеле «Налады» > «Удзельнікі»:
- распрацоўшчык: Можна адпраўляць у галіны аб'ектаў.
- Суправаджальнік: Можа аб'ядноўвацца ў абароненыя галіны.
- Госць: Доступ толькі для чытання.
Прыклад працоўнага працэсу дзеянняў GitHub 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 pipelineвыконваюцца строга ў межах прызначаных ім дазволаў, што прадухіляе перанос вобласці дзеяння.
Выключаючы ручное кіраванне, абавязковы кантроль доступу забяспечвае больш моцную і надзейную бяспеку, чым толькі RBAC або DAC.
2.4 Дыскрэцыйны кантроль доступу (DAC)
DAC дазваляе ўладальнікам рэсурсаў уручную прызначаць правы доступу. Гэта гнутка, але рызыкоўна. Адзін няправільны агульны доступ можа паставіць пад пагрозу рэпазітар. DAC працуе наступным чынам: «Вы валодаеце ім, вы вырашаеце, хто ўваходзіць».
Прыклад: a распрацоўшчык запрашае знешняга супрацоўніка і дае яму доступ да запісу ў рэпазітар. Супрацоўнік адпраўляе небяспечны код непасрэдна ў DEV філіял.
In CI/CD, DAC можа выглядаць як распрацоўшчык, які ўручную дае доступ да разгортвання ў прадукцыйнай сістэме часоваму члену каманды праз кансоль, па-за межамі якой-небудзь вызначанай палітыкі кантролю доступу.
Як выбраць палітыку кантролю доступу, якая працуе ў рэальных умовах Pipelines
Кантроль доступу ў Git
Выкарыстоўвайце RBAC для кіравання ролямі ўдзельнікаў, суправаджальнікаў і выпускальнікаў. Заблакуйце правы зліцця для абароненых галін. Патрабаваць падпісаныя элементы. commitі абмежаваць, хто можа абыходзіць абарону.
Прыклад: Правілы абароны галін GitHub
- Патрабаваць pull request агляды перад аб'яднаннем.
- Адхіліць састарэлыя pull request зацвярджэнні, калі новыя commits штурхаюцца.
- Патрабуецца подпіс commits.
- Прапускайце DAC для крытычна важных для вытворчасці рэпазітараў. Не раздавайце доступ на запіс неасцярожна.
Pipeline Правапрымяненне
Устанавіць абавязковы кантроль доступу для pipelineс. Надзейная мадэль кантролю доступу Mac абмяжоўвае заданні CI толькі неабходнымі дазволамі.
- Асобныя сакрэты па асяроддзі.
- Выкарыстоўвайце унікальныя токены для кожнага асяроддзя.
- Не дапускайце ўплыву ручных выкананняў на вытворчасць.
прыклад: Заданне неперарыўнай інтэграцыі паўторна выкарыстоўвае токен разгортвання паміж прамежкавым і прадукцыйным этапамі, выпадкова публікуючы тэставы код.
Дадайце правілы кантролю доступу Mac для кіравання вобласцю дзеяння токена:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Прыклад вызначэння вобласці дзеяння сакрэтаў: выкарыстанне токенаў у залежнасці ад асяроддзя
Правільнае вызначэнне сакрэтаў па асяроддзі мае вырашальнае значэнне для прадухіліць выпадковы або зламысны доступ з іншага асяроддзя. Напрыклад, токен разгортвання для асяроддзя распрацоўкі ніколі не павінен быць прыдатным для разгортвання ў прадукцыйнай версіі.
Вось як элементы кіравання на аснове палітыкі доступу ізалююць выкарыстанне сакрэтных дадзеных у дзеяннях GitHub:
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"] } ] } Распаўсюджаныя памылкі кантролю доступу ў працоўных працэсах распрацоўшчыкаў
Звышдазвольны доступ да рэпазіторыя
Праблема: Наданне занадта вялікай колькасці карыстальнікаў доступу да запісу/адміністравання рэпазітараў.
Як гэта адбываецца: Члены каманды атрымліваюць павышэнне па службе або даданне без праверкі дазволаў. Ролі перагружаюцца.
Эксплойт зламысніка: Зламыснікі атакуюць гэтыя акаўнты, выкарыстоўваючы скрадзеныя ўліковыя дадзеныя або сацыяльную інжынерыю. Пасля пранікнення яны могуць укараніць шкоднасны код, стварыць бэкдоры або выдаліць гісторыю, каб схаваць сляды.
Агульныя дазволы паміж распрацоўшчыкам і прадзюсарам
Праблема: Здача ў арэнду распрацоўшчыкаў і прадзюсараў pipelineдазволы на агульны доступ.
Як гэта адбываецца: Каманды паўторна выкарыстоўваюць адзін і той жа токен разгортвання або ўліковы запіс службы неперасягненай інтэграцыі ў розных асяроддзях.
Эксплойт зламысніка: Узлом асяроддзя распрацоўкі дае зламыснікам доступ да вытворчых рэсурсаў. Абавязковы кантроль доступу можна прадухіліць гэта, прывязаўшы дазволы да пэўных асяроддзяў.
Ручная загрузка артэфактаў
Праблема: Дазвол на ручную загрузку артэфактаў у прадукцыйныя рэестры.
Як гэта адбываецца: Абыход распрацоўшчыкаў pipelineдля хуткіх выпраўленняў або гарачых патчаў.
Эксплойт зламысніка: Узламаныя машыны распрацоўшчыкаў могуць загружаць шкоднаснае праграмнае забеспячэнне непасрэдна ў сховішча артэфактаў, абыходзячы ўсе CI/CD праверкі бяспекі.
Рызыка злоўжывання палітыкай рэестра: Ручная публікацыя артэфактаў стварае крытычную паверхню для атакі ў ланцужку паставак праграмнага забеспячэння. Зламыснікі выкарыстоўваюць слабыя палітыкі кантролю доступу можа ўстаўляць шкоднасны код у надзейныя пакеты або вобразы кантэйнераў, што прыводзіць да шырока распаўсюджанага ўзлому праграмнага забеспячэння. Нядаўнія інцыдэнты ў ланцужку паставак праграмнага забеспячэння паказалі, як нерэгуляваная загрузка артэфактаў можа хутка перарасці ў сур'ёзныя парушэнні бяспекі, якія ўплываюць на незлічоных карыстальнікаў і сістэм.
Прыклад: аСтажор з поўным доступам да рэестра npm памылкова публікуе нестабільную версію. Калі б зламыснік узламаў машыну гэтага стажора, ён мог бы апублікаваць шкоднаснае праграмнае забеспячэнне.
Практычныя крокі па ўкараненні строгага кантролю доступу
- Прывязаць ролі да дакладных дазволаў, адмоўцеся ад універсальных налад
- Аўтаматызуйце праверкі палітыкі кантролю доступу ў вашым CI/CD pipelines
- Блакіроўка рэестраў з абавязковым кантролем доступу
- Пастаянна весці журнал і кантраляваць доступ да крытычна важных сістэм
- Ставіцеся да палітык кантролю доступу як да кода. Кожны няправільны крок можна выкарыстаць
Роля Xygeni: забеспячэнне і маніторынг палітык доступу ў працоўных працэсах DevOps
Ксігені дапамагае вам ператварыць абавязковы кантроль доступу з тэорыі ў практыку, вырашаючы рэальныя штодзённыя праблемы забеспячэння выканання палітыкі кантролю доступу ў DevSecOps pipelines.
- Рашэнне праблемы доступу да Git з залішнімі дазволамі: Xygeni пастаянна кантралюе рэпазіторыі Git на наяўнасць парушэнняў RBAC, такіх як неправераныя прызначэнні роляў або адсутная абарона галін. Ён папярэджвае, калі палітыкі кантролю доступу адхіляюцца ад вызначаных правілаў, і прымяняе карэкціруючыя дзеянні, каб пазбегнуць выпадковых зліццяў або шкоднасных PR.
- Блакіроўка CI/CD Pipelines: Заданні CI часам выконваюцца з больш шырокімі аб'ёмамі дзеянняў, чым меркавалася. Xygeni выяўляе, калі CI/CD заданні запытваюць або працуюць па-за межамі прызначаных ім роляў, выяўляючы распаўсюджванне прывілеяў і злоўжыванне імі ў рэжыме рэальнага часу. Гэта дапамагае выконваць прынцыпы кантролю доступу па MAC-адрасе ўнутры pipelineшляхам строгай прывязкі доступу да асобы і мэты працы.
- Забеспячэнне кантролю над публікацыяй артэфактаў: Калі распрацоўшчыкі ўсё яшчэ ўручную загружаюць артэфакты або выявы, Xygeni спыняе гэта. Ён ужывае абавязковы кантроль доступу на ўзроўні рэестра, каб толькі правераныя pipeline ідэнтыфікатары могуць публікаваць артэфакты. Больш ніякіх загрузак чалавекам у прадукцыйныя рэестры.
- Маніторынг доступу і паведамленне пра анамаліі: З дапамогай Xygeni вы атрымліваеце ўяўленне пра тое, хто, калі і як атрымліваў доступ да чаго. Xygeni пастаянна адсочвае выкарыстанне сакрэтаў, доступ да рэпазіторыя і ўзаемадзеянне з рэестрам, каб выяўляць незвычайную паводзіны, пазначаць няправільныя канфігурацыі і дапамагаць з аналізам пасля інцыдэнту.
Вынік: Xygeni аўтаматызуе і забяспечвае выкананне палітыкі кантролю доступу, каб ваша асяроддзе DevOps заставалася бяспечным, не запавольваючы вашу працу.
Такім чынам, разглядайце кантроль доступу як Code Security
Любы чалавек з правамі разгортвання або доступам да інфраструктуры можа выпадкова ці не пашкодзіць вашу праграму. Вось чаму надзейная палітыка кантролю доступу неабавязковая. Выкарыстоўвайце RBAC для правільнага дэлегавання роляў. Ужывайце абавязковы кантроль доступу да крытычна важных сістэм. Цалкам адмоўцеся ад DAC для вытворчых шляхоў. Укараніце палітыкі кантролю доступу ў свой Найлепшыя практыкі DevSecOps. Аўтаматызуйце іх. Кантралюйце іх. Выконвайце іх.
TL, д-рДобра выкананая палітыка кантролю доступу аўтаматычна робіць вашу кодавую базу, артэфакты і інфраструктуру бяспечнейшымі.
