Zašto programerima trebaju stvarne politike kontrole pristupa (ne samo teorija)
Ako šaljete kod, održavanje pipelineili upravljanje registrima artefakata, potrebno vam je više od teorije. Slabe ili nedefinirane politike kontrole pristupa potiču neovlašteno mijenjanje repozitorija, CI/CD zlostavljanje i curenje vjerodajnicaDevSecOps zahtijeva stvarnu provedbu, a ne samo skrivene postavke dozvola.
Za učinkovito upravljanje pravilima kontrole pristupa u svim repozitorijima koda, CI/CD pipelines, i registre artefakata, mnogi se timovi oslanjaju na automatizirane alate za provedbu poput Xygenija. Kontinuiranim praćenjem uloga, dopuštenja i pridržavanja pravila, Xygeni pomaže u sprječavanju pomicanja dopuštenja, neovlaštenog pristupa i ručnih poništavanja, pretvarajući teoriju obavezne kontrole pristupa u djelo.
Kontrola pristupa izravno zaključava vaš izvorni kod, osigurava vaše verzije i štiti vašu produkciju. pipelineAko programeri zaobilaze kontrole ili servisni računi imaju široka dopuštenja, otvarate vrata sigurnosnim propustima. Zato je razumijevanje obavezne kontrole pristupa, kontrole pristupa MAC adresom i drugih modela ključno.
Vrste politika kontrole pristupa koje bi programeri trebali znati
Pravila kontrole pristupa spadaju u tri glavne kategorije, a svaka se drugačije uklapa u CI/CD tijekove rada. Evo kratkog usporednog pregleda radi pojašnjenja:
| Model | Tko kontrolira pristup? | Tipična upotreba u CI/CD | Razina rizika |
|---|---|---|---|
| DAC (Diskrecijska kontrola pristupa) | Vlasnik resursa (razvojni programer, administrator) | Ručno dijeljenje pristupa repozitoriju ili registru | Visoko (ljudska pogreška) |
| RBAC (Kontrola pristupa temeljena na ulogama) | Sustav dodjeljuje dozvole prema ulogama | Zaštita grana GitHub-a, pristup CI poslovima na temelju korisničkih uloga | Srednje (pogrešno konfigurirane uloge) |
| MAC (Obavezna kontrola pristupa) | Provodi se pravilima sustava | Provodi tko može objavljivati artefakte ili implementirati kod | Nisko (pravilo poništava namjeru korisnika) |
Pojašnjenje MAC-a u odnosu na RBAC u CI/CD Kontekst
Lako je pomiješati kontrolu pristupa temeljenu na ulogama (RBAC) s obveznom kontrolom pristupa (kontrola pristupa MAC-u), posebno u CI/CD okruženja. Dok CI/CD Platforme poput GitHuba i GitLaba koriste RBAC za upravljanje ulogama i dozvolama (npr. tko može spajati ili implementirati), ovo je i dalje u osnovi kontrola pristupa temeljena na ulogama, a ne na pravoj MAC adresi.
RBAC vam omogućuje dodjeljivanje dozvola na temelju uloga (razvojni programer, održavatelj itd.), ali te dozvole i dalje kontroliraju korisnici i mogu se mijenjati. Pogrešne konfiguracije ili širenje dozvola uobičajeni su rizici.
Obvezna kontrola pristupa (MAC kontrola pristupa), nasuprot tome, provodi se na razini sustava ili infrastrukture. Korisnici, uključujući administratore, ne mogu je poništiti. Zamislite kontrolu pristupa Macu kao pravila ugrađena u platformu: IAM pravila kod pružatelja usluga u oblaku (npr. AWS IAM, GCP IAM) ili alati za provedbu na razini operativnog sustava poput SELinuxa ili AppArmora. U tim slučajevima, pristup se odobrava samo kada su ispunjena unaprijed definirana pravila koja se ne mogu zaobići.
In CI/CDMnogi alati simuliraju ponašanje kontrole pristupa MAC-om putem usko ograničenih IAM uloga ili dozvola specifičnih za resurse, ali to nije potpuna obavezna kontrola pristupa. Prava provedba obavezne kontrole pristupa zahtijeva kontrole ispod sloja aplikacije, na razini OS-a, mreže ili infrastrukture oblaka, gdje je pristup reguliran nepromjenjivim pravilima kontrole pristupa, a ne ljudskom konfiguracijom.
Kontrola pristupa temeljena na ulogama (RBAC)
RBAC mapira dopuštenja na definirane uloge poput "razvojnog programera", "održavatelja" ili "voditelja izdanja". Pojednostavljuje upravljanje u alatima poput GitHuba i GitLabUmjesto konfiguriranja korisnika po korisniku, dodijelite im ulogu i pustite sustav da provodi pravila.
Primjer: GitHub datoteka CODEOWNERS
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers To osigurava da samo dodijeljene uloge mogu odobriti promjene u kritičnim direktorijima.
Postavke uloge u GitLabu: Konfigurirajte pristup projektu u Postavke > Članovi:
- Proizvođač: Može gurati na istaknute grane.
- Održavatelj: Može se spojiti u zaštićene grane.
- Gost: Pristup samo za čitanje.
Primjer RBAC-a za tijek rada GitHub akcija:
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 Obavezna kontrola pristupa (MAC)
Obavezna kontrola pristupa (kontrola pristupa MAC-om) provodi stroga pravila na razini sustava koja korisnici i administratori ne mogu poništiti. Koristite kontrolu pristupa Mac-u strogo kontrolirati tko može čitati, pisati ili izvršavati kritične resurse.
Primjer: Pravila registra artefakata Googlea (pojednostavljeni YAML)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com Primjer: Amazon ECR politika (pojednostavljeni 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 Rizici ručnog premošćivanja i kako ih MAC sprječava
Jedan od najvećih rizika s RBAC-om i DAC modeli postoji mogućnost namjernih ili slučajnih ručnih poništavanja. Na primjer, administrator ili programer mogu izravno prenijeti artefakte u zaštićeni registar ili dodijeliti prekomjerna dopuštenja izvan definiranih pravila kontrole pristupa. Ove radnje mogu uvesti ranjivosti ili uzrokovati propuste u usklađenosti.
Obavezna kontrola pristupa (MAC kontrola pristupa) sprječava takva poništavanja provođenjem pravila na razini sustava koja nijedan korisnik, pa čak ni administratori, ne može zaobići.cisIone reguliraju nepromjenjiva pravila ugrađena u infrastrukturu (poput pravila cloud IAM-a ili sigurnosnih modula na razini operativnog sustava). To znači:
- Administrator ne može ručno prenijeti artefakte u registar ako ih pravila kontrole pristupa Macu odbijaju.
- Korisnici ne mogu povećavati privilegije ili mijenjati dozvole izvan definiranih pravila kontrole pristupa.
- Automatizirana CI/CD pipelineizvršavaju se strogo unutar dodijeljenih dozvola, sprječavajući širenje opsega.
Uklanjanjem ručnih poništavanja, obavezna kontrola pristupa osigurava jaču i pouzdaniju sigurnosnu poziciju od samo RBAC-a ili DAC-a.
2.4 Diskrecijska kontrola pristupa (DAC)
DAC omogućuje vlasnicima resursa ručno dodjeljivanje dozvola. Fleksibilan je, ali rizičan. Jedno pogrešno dijeljenje može ugroziti repozitorij. DAC funkcionira ovako: „Ti ga posjeduješ, ti odlučuješ tko ulazi.“
Primjer: Dev poziva vanjskog suradnika i daje mu pristup za pisanje u repozitorij. Suradnik šalje nesiguran kod izravno u dev podružnica.
In CI/CD, DAC može izgledati kao da programer ručno odobrava pristup implementaciji produkcije privremenom članu tima putem konzole, izvan bilo koje definirane politike kontrole pristupa.
Kako odabrati politiku kontrole pristupa koja funkcionira u stvarnosti Pipelines
Kontrola pristupa u Gitu
Iskoristite RBAC za upravljanje ulogama suradnika, održavatelja i izdavatelja. Zaključajte prava spajanja za zaštićene grane. Zahtijevajte potpisano commiti ograničiti tko može zaobići zaštite.
Primjer: Pravila zaštite grana GitHub-a
- Zahtijevati pull request recenzije prije spajanja.
- Odbaci zastarjelo pull request odobrenja kada su nova commits su gurnuti.
- Zahtijeva potpis commits.
- Preskočite DAC za repozitorije kritične za produkciju. Nemojte ležerno davati pristup za pisanje.
Pipeline Izvršenje
Uvedite obaveznu kontrolu pristupa za pipelines. Čvrst model kontrole pristupa za Mac ograničava CI poslove samo na dopuštenja koja su im potrebna.
- Odvojite tajne prema okruženju.
- Koristite jedinstvene tokene po okruženju.
- Spriječite utjecaj ručnih pokretanja na proizvodnju.
Primjer: CI posao ponovno koristi token za implementaciju u fazi pripreme i produkcije, slučajno puštajući testni kod u rad.
Dodajte pravila kontrole pristupa za Mac kako biste kontrolirali opseg tokena:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Primjer određivanja opsega tajni: Korištenje tokena specifičnog za okruženje
Pravilno određivanje opsega tajni po okruženju ključno je za spriječiti slučajan ili zlonamjeran pristup iz različitih okruženja. Na primjer, token za implementaciju za razvojno okruženje nikada ne bi trebao biti upotrebljiv za implementaciju u produkciju.
Evo kako kontrole temeljene na pravilima kontrole pristupa izoliraju korištenje tajnih podataka u 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 }} Ovo nameće sljedeće:
- Samo razvijač uloga može pokrenuti implementacije pomoću razvojnog tokena na dev podružnica.
- Samo voditelj izdanja uloga se može implementirati u produkciju pomoću prod tokena na glavni podružnica.
Takva ograničena tajna upotreba smanjuje rizik od eskalacije curenja tokena u različitim okruženjima i provodi najmanje privilegija u CI/CD pipelines slijedeći stroge politike kontrole pristupa.
Kontrole pristupa artefaktima
Zaključajte registre artefakata pomoću obvezne kontrole pristupa. CI/CD Sustavi bi trebali rješavati objavljivanje, a ne pojedinačni programeri.
Koristite RBAC za definiranje koji timovi povlače podatke iz određenih registara. Programerima će možda trebati samo pristup za čitanje produkcijskih paketa.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Uobičajeni kvarovi kontrole pristupa u razvojnim tijekovima rada
Previše dopustiv pristup repozitoriju
Problem: Odobravanje pristupa za pisanje/administriranje repozitorija prevelikom broju korisnika.
Kako se to događa: Članovi tima dobivaju promaknuće ili dodavanje bez pregleda dopuštenja. Uloge postaju prenapuhane.
Iskorištavanje napadača: Napadači ciljaju ove račune koristeći ukradene vjerodajnice ili društveni inženjering. Jednom kada uđu, mogu ubrizgati zlonamjerni kod, backdoorove ili ukloniti povijest kako bi sakrili tragove.
Zajedničke dozvole između razvojnog i produkcijskog okruženja
Problem: Najam razvoja i produkcije pipelinedopuštenja za dijeljenje.
Kako se to događa: Timovi ponovno koriste isti token za implementaciju ili CI servisni račun u različitim okruženjima.
Iskorištavanje napadača: Kršenje razvojnog okruženja daje napadačima pristup produkciji. Obavezna kontrola pristupa to se može spriječiti vezanjem dozvola za određena okruženja.
Ručno učitavanje artefakata
Problem: Omogućavanje ručnog prijenosa artefakata u produkcijske registre.
Kako se to događa: Zaobilaženje programera pipelineza brza rješenja ili hitne zakrpe.
Iskorištavanje napadača: Kompromitirana računala programera mogu izravno prenijeti zlonamjerni softver u pohranu artefakata, zaobilazeći sve CI/CD sigurnosne provjere.
Rizik od zlouporabe pravila registra: Ručno objavljivanje artefakata stvara kritičnu površinu za napad u lancu opskrbe softverom. Napadači iskorištavaju slabe pravila kontrole pristupa može umetnuti zlonamjerni kod u pouzdane pakete ili slike spremnika, što dovodi do široko rasprostranjenog kompromitiranja nizvodno. Nedavni incidenti u lancu opskrbe softverom pokazali su kako neregulirani prijenosi artefakata mogu brzo eskalirati u velike sigurnosne propuste, utječući na bezbrojne korisnike i sustave.
Primjer: aPripravnik s punim pristupom npm registru greškom objavljuje nestabilnu verziju. Da je napadač kompromitirao računalo pripravnika, mogao je umjesto toga objaviti zlonamjerni softver.
Praktični koraci za provedbu strogih kontrola pristupa
- Mapirajte uloge na točne dozvole, riješite se postavki "jedna uloga odgovara svima"
- Automatizirajte provjere pravila kontrole pristupa u svom CI/CD pipelines
- Zaključajte registre s obveznom kontrolom pristupa
- Kontinuirano bilježiti i pratiti pristup kritičnim sustavima
- Pravila kontrole pristupa tretirajte kao kod. Svaki pogrešan korak može se iskoristiti.
Xygenijeva uloga: Provođenje i praćenje politika pristupa u DevOps tijekovima rada
Xygeni pomaže vam da obaveznu kontrolu pristupa pretvorite iz teorije u djelo rješavanjem stvarnih, svakodnevnih izazova u provedbi politika kontrole pristupa u DevSecOps-u pipelines.
- Rješavanje problema s prekomjernim dopuštenjima za pristup Gitu: Xygeni kontinuirano prati Git repozitorije za kršenja RBAC-a kao što su nepregledane dodjele uloga ili nedostajuće zaštite grana. Upozorava kada se politike kontrole pristupa odstupaju od definiranih pravila i provodi korektivne radnje kako bi se izbjegla slučajna spajanja ili zlonamjerni PR-ovi.
- Zaključavanje CI/CD Pipelines: CI poslovi se ponekad izvode sa širim opsegom nego što je predviđeno. Xygeni otkriva kada CI/CD poslovi zahtijevaju ili djeluju izvan svojih dodijeljenih uloga, identificirajući širenje opsega i zlouporabu privilegija u stvarnom vremenu. To pomaže u provođenju principa kontrole pristupa MAC adresom unutar pipelinetako što je pristup strogo povezan s identitetom i svrhom posla.
- Provođenje kontrola objavljivanja artefakata: Ako programeri i dalje ručno prenose artefakte ili slike, Xygeni tome staje na kraj. Primjenjuje obaveznu kontrolu pristupa na razini registra tako da samo provjereni pipeline identiteti mogu objavljivati artefakte. Nema više ljudskog prijenosa u produkcijske registre.
- Praćenje pristupa i označavanje anomalija: S Xygenijem dobivate uvid u to tko je čemu pristupio, kada i kako. Kontinuirano prati korištenje tajni, pristup repozitoriju i interakcije s registrom kako bi otkrio neobično ponašanje, označio pogrešne konfiguracije i pomogao u analizi nakon incidenta.
Dno crta: Xygeni donosi automatizaciju i provedbu pravila kontrole pristupa kako bi vaše DevOps okruženje ostalo sigurno bez usporavanja.
Dakle, tretirajte kontrolu pristupa kao Code Security
Svatko s pravima implementacije ili pristupom infrastrukturi može oštetiti vašu aplikaciju, slučajno ili ne. Zato čvrsta politika kontrole pristupa nije opcionalna. Koristite RBAC za pravilno delegiranje uloga. Primijenite obaveznu kontrolu pristupa na kritične sustave. U potpunosti preskočite DAC za produkcijske putove. Uključite pravila kontrole pristupa u svoj Najbolje prakse DevSecOps-a. Automatizirajte ih. Pratite ih. Provodite ih.
TL; DRDobro provedena politika kontrole pristupa automatski čini vašu kodnu bazu, artefakte i infrastrukturu sigurnijima.
