Hvilken tilgangskontrollpolicy trenger du?

Hvorfor utviklere trenger reelle retningslinjer for tilgangskontroll (ikke bare teori)

Hvis du pusher kode, vedlikeholder pipelines, eller administrasjon av artefaktregistre, trenger du mer enn teori. Svake eller udefinerte tilgangskontrollregler inviterer til manipulering av arkiver, CI/CD misbruk, og legitimasjonslekkasjerDevSecOps krever reell håndheving, ikke bare skjulte tillatelsesinnstillinger.

For å effektivt administrere tilgangskontrollpolicyer på tvers av kodelagre, CI/CD pipelinesog artefaktregistre, er mange team avhengige av automatiserte håndhevingsverktøy som Xygeni. Ved kontinuerlig å overvåke roller, tillatelser og overholdelse av policyer, bidrar Xygeni til å forhindre tillatelsesavvik, uautorisert tilgang og manuelle overstyringer, og omsette obligatorisk tilgangskontrollteori til handling.

Tilgangskontroll låser kildekoden din direkte, sikrer byggene dine og beskytter produksjonen din pipelineHvis utviklere omgår kontroller eller tjenestekontoer har brede tillatelser, åpner du døren for sikkerhetsbrudd. Derfor er det avgjørende å forstå obligatorisk tilgangskontroll, MAC-tilgangskontroll og andre modeller.

Typer tilgangskontrollpolicyer som utviklere bør kjenne til

Tilgangskontrollpolicyer faller inn i tre hovedkategorier, hver passer forskjellig inn i CI/CD arbeidsflyter. Her er en rask oversikt side om side for å avklare:

Modell	Hvem kontrollerer tilgang?	Typisk bruk i CI/CD	Risikonivå
DAC (diskresjonær tilgangskontroll)	Ressurseier (utvikler, administrator)	Manuell deling av tilgang til depot eller register	Høy (menneskelig feil)
RBAC (rollebasert tilgangskontroll)	Systemet tildeler tillatelser etter rolle	GitHub-grenbeskyttelse, CI-jobbtilgang basert på brukerroller	Medium (feilkonfigurerte roller)
MAC (obligatorisk tilgangskontroll)	Håndhevet av systempolicy	Håndhever hvem som kan publisere artefakter eller distribuere kode	Lav (policy overstyrer brukerens intensjon)

Avklaring av MAC vs. RBAC i CI/CD Kontekst

Det er lett å forveksle rollebasert tilgangskontroll (RBAC) med obligatorisk tilgangskontroll (Mac-tilgangskontroll), spesielt i CI/CD miljøer. Mens CI/CD Plattformer som GitHub og GitLab bruker RBAC til å administrere roller og tillatelser (f.eks. hvem som kan slå sammen eller distribuere), men dette er fortsatt fundamentalt rollebasert, ikke ekte MAC-tilgangskontroll.

RBAC lar deg tildele tillatelser basert på roller (utvikler, vedlikeholder osv.), men disse tillatelsene er fortsatt brukerkontrollerte og kan endres. Feilkonfigurasjoner eller tillatelseskryp er vanlige risikoer.

Obligatorisk tilgangskontroll (MAC-tilgangskontroll) håndheves derimot på system- eller infrastrukturnivå. Brukere, inkludert administratorer, kan ikke overstyre den. Tenk på Mac-tilgangskontroll som retningslinjer innebygd i plattformen: IAM-retningslinjer hos skyleverandører (f.eks. AWS IAM, GCP IAM), eller håndhevingsverktøy på OS-nivå som SELinux eller AppArmor. I disse tilfellene gis tilgang bare når forhåndsdefinerte, ikke-omgåelige regler er oppfylt.

In CI/CDMange verktøy simulerer MAC-tilgangskontrollens virkemåte gjennom strengt avgrensede IAM-roller eller ressursspesifikke tillatelser, men dette er ikke fullstendig obligatorisk tilgangskontroll. Ekte obligatorisk håndheving av tilgangskontroll krever kontroller under applikasjonslaget, på OS-, nettverks- eller skyinfrastrukturnivå, der tilgang styres av uforanderlige tilgangskontrollpolicyer, ikke menneskelig konfigurasjon.

Rollebasert tilgangskontroll (RBAC)

RBAC tilordner tillatelser til definerte roller som «utvikler», «vedlikeholder» eller «utgivelsesansvarlig». Det forenkler administrasjon i verktøy som GitHub og GitLabI stedet for å konfigurere bruker for bruker, tildel dem en rolle og la systemet håndheve reglene.

Eksempel: GitHub CODEOWNERS-fil

				
					# CODEOWNERS
/docs/ @doc-team
/scripts/ @devops-team
/main.py @maintainers

Dette sikrer at bare de tildelte rollene kan godkjenne endringer i kritiske mapper.

GitLab-rolleinnstillinger: Konfigurer prosjekttilgang i Innstillinger > Medlemmer:

Utvikler: Kan presse til funksjonsgrener.
Vedlikeholder: Kan slås sammen med beskyttede grener.
Gjest: Skrivebeskyttet tilgang.

Eksempel på RBAC for GitHub-handlinger i arbeidsflyten:

				
					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

Obligatorisk tilgangskontroll (MAC)

Obligatorisk tilgangskontroll (MAC-tilgangskontroll) håndhever strenge regler på systemnivå som brukere og administratorer ikke kan overstyre. Bruk Mac-tilgangskontroll å strengt kontrollere hvem som kan lese, skrive eller kjøre kritiske ressurser.

Eksempel: Googles retningslinjer for artefaktregisteret (forenklet YAML)

				
					yaml
bindings:
  - role: roles/artifactregistry.writer
    members:
      - serviceAccount:ci-deployer@project.iam.gserviceaccount.com

Denne policyen gir bare skrivetillatelse til ci-deployer-tjenestekontoen, og sikrer at bare CI-jobber med denne identiteten kan sende artefakter.

Eksempel: Amazon ECR-policy (forenklet 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

Denne policyen nekter alle PutImage-handlinger på ECR-repositoriet med mindre de utføres av ci-service-kontoen. Den begrenser bildeopplastinger strengt til denne tjenestekontoen.

Risikoer ved manuell overstyring og hvordan MAC forhindrer dem

En av de største risikoene med RBAC og DAC-modeller er potensialet for bevisste eller utilsiktede manuelle overstyringer. For eksempel kan en administrator eller utvikler laste opp artefakter direkte til et beskyttet register eller gi overdreven tilgang til andre tilgangskontrolltilganger enn definerte retningslinjer. Disse handlingene kan introdusere sårbarheter eller forårsake samsvarshull.

Obligatorisk tilgangskontroll (MAC-tilgangskontroll) forhindrer slike overstyringer ved å håndheve policyer på systemnivå som ingen brukere, selv administratorer, kan omgå. TilgangsdecisIoner styres av uforanderlige regler som er innebygd i infrastrukturen (som sky-IAM-policyer eller sikkerhetsmoduler på OS-nivå). Dette betyr:

En administrator kan ikke laste opp artefakter manuelt til et register hvis Mac-tilgangskontrollpolicyen nekter dem.
Brukere kan ikke eskalere privilegier eller endre tillatelser utenfor de definerte tilgangskontrollpolicyene.
Automatisert CI/CD pipelines kjører strengt innenfor sine tildelte tillatelser, noe som forhindrer omfangskryp.

Ved å eliminere manuelle overstyringer sikrer obligatorisk tilgangskontroll en sterkere og mer pålitelig sikkerhetsstilling enn RBAC eller DAC alene.

2.4 Diskresjonær tilgangskontroll (DAC)

DAC lar ressurseiere manuelt tildele tillatelser. Det er fleksibelt, men risikabelt. Én feil deling kan kompromittere et repo. DAC fungerer slik: «Du eier det, du bestemmer hvem som kommer inn.»

Eksempel: The dev inviterer en ekstern samarbeidspartner og gir dem skrivetilgang til repoet. Samarbeidspartneren sender usikker kode direkte til dev gren.

In CI/CD, DAC kan se ut som en utvikler som manuelt gir produksjonstilgang til et midlertidig teammedlem via konsollen, utenfor en definert tilgangskontrollpolicy.

Hvordan velge en tilgangskontrollpolicy som fungerer i virkeligheten Pipelines

Tilgangskontroll i Git

Utnytt RBAC til å administrere bidragsyter-, vedlikeholds- og utgivelsesroller. Lås sammenslåingsrettigheter til beskyttede grener. Krev signering. commitog begrense hvem som kan omgå beskyttelser.

Eksempel: GitHub-grenbeskyttelsesregler

Krev pull request vurderinger før sammenslåing.
Avvis foreldet pull request godkjenninger når de er nye commits blir dyttet.
Krev signering commits.
Hopp over DAC for produksjonskritiske repositorier. Ikke gi ut skrivetilgang tilfeldig.

Pipeline Enforcement

Innfør obligatorisk adgangskontroll for pipelines. En solid Mac-tilgangskontrollmodell begrenser CI-jobber til kun de tillatelsene de trenger.

Skill hemmeligheter etter miljø.
Bruk unike tokens per miljø.
Forhindre at manuelle kjøringer påvirker produksjonen.

Eksempel: En CI-jobb bruker et distribusjonstoken på tvers av staging og prod, og sender testkoden til live ved et uhell.

Legg til Mac-tilgangskontrollregler for å kontrollere tokenomfanget:

				
					yaml
env:
  DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }}
if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'

Eksempel på omfang av hemmeligheter: Miljøspesifikk tokenbruk

Det er avgjørende å kartlegge hemmeligheter på riktig måte etter miljø. forhindre utilsiktet eller ondsinnet tilgang på tvers av miljøer. For eksempel skal et distribusjonstoken for utviklingsmiljøet aldri kunne brukes til distribusjon til produksjon.

Slik isolerer kontroller basert på tilgangskontrollpolicyer hemmelig bruk i 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 }}

Dette håndhever at:

Bare den utvikler rollen kan utløse distribusjoner ved hjelp av utviklertokenet på dev gren.
Bare den utgivelsesbehandler rollen kan distribueres til produksjon ved hjelp av prod-tokenet på main gren.

Slik bruk av begrenset hemmelighet reduserer risikoen for at tokenlekkasjer eskalerer på tvers av miljøer og håndhever minst mulig privilegium i CI/CD pipelines følge strenge retningslinjer for tilgangskontroll.

Tilgangskontroller for gjenstander

Lås ned gjenstandsregistre ved hjelp av obligatorisk tilgangskontroll. CI/CD Systemer bør håndtere publisering, ikke individuelle utviklere.

Bruk RBAC til å definere hvilke team som henter data fra bestemte registre. Utviklere trenger kanskje bare lesetilgang til produksjonspakker.

				
					json
{
  "rules": [
    {
      "action": "read",
      "resource": "npm-package:internal/*",
      "allowed_roles": ["developer", "qa"]
    },
    {
      "action": "write",
      "resource": "npm-package:internal/*",
      "allowed_principals": ["ci-pipeline"]
    }
  ]
}

Vanlige tilgangskontrollfeil i utviklerarbeidsflyter

Overpermissiv tilgang til depotet

problem: Gir for mange brukere skrive-/administratortilgang til repositorier.
Hvordan det skjer: Teammedlemmer blir forfremmet eller lagt til uten at tillatelser blir gjennomgått. Rollene blir oppblåste.
Angriperutnyttelse: Angripere angriper disse kontoene ved hjelp av stjålne påloggingsinformasjon eller sosial manipulering. Når de er inne, kan de injisere skadelig kode, bakdører eller slette historikk for å skjule spor.

Delte tillatelser mellom utvikler og produsent

problem: Lar utvikler og produksjon pipelines delingstillatelser.
Hvordan det skjer: Team bruker samme distribusjonstoken eller CI-tjenestekonto på tvers av miljøer.
Angriperutnyttelse: Et brudd i utviklingsmiljøet gir angripere produksjonstilgang. Obligatorisk tilgangskontroll kan forhindre dette ved å binde tillatelser til bestemte miljøer.

Manuelle artefaktopplastinger

problem: Tillater manuell opplasting av artefakter til produksjonsregistre.
Hvordan det skjer: Utviklere omgår pipelines for raske reparasjoner eller problemløsninger.
Angriperutnyttelse: Kompromitterte utviklermaskiner kan laste opp skadelig programvare direkte til artefaktlagring, og omgå alle CI/CD sikkerhetskontroller.

Risiko for misbruk av registerpolicyer: Manuell publisering av artefakter skaper en kritisk angrepsflate i programvarens forsyningskjede. Angripere utnytter laps retningslinjer for tilgangskontroll kan sette inn skadelig kode i pålitelige pakker eller containerbilder, noe som fører til omfattende sikkerhetsbrudd nedstrøms. Nylige hendelser i programvareforsyningskjeden har vist hvordan uregulerte artefaktopplastinger raskt kan eskalere til store sikkerhetsbrudd, som påvirker utallige brukere og systemer.

Eksempel: enn-praktikant med full npm-registertilgang publiserer en ustabil versjon ved en feiltakelse. Hvis en angriper hadde kompromittert praktikantens maskin, kunne de ha publisert skadelig programvare i stedet.

Praktiske trinn for å håndheve sterke tilgangskontroller

Tilordne roller til eksakte tillatelser, dropp oppsett der én rolle passer alle
Automatiser kontroll av tilgangskontrollpolicyer i din CI/CD pipelines
Lås ned registre med obligatorisk tilgangskontroll
Kontinuerlig loggføring og overvåking av tilgang til kritiske systemer
Behandle retningslinjer for tilgangskontroll som kode. Hvert feiltrinn kan utnyttes

Xygenis rolle: Håndheving og overvåking av tilgangspolicyer i DevOps-arbeidsflyter

Xygeni hjelper deg med å gjøre obligatorisk tilgangskontroll fra teori til handling ved å løse reelle, daglige utfordringer med håndheving av tilgangskontrollpolicyer i DevSecOps pipelines.

Løsning av overdreven tilgang til Git: Xygeni overvåker kontinuerlig Git-repositorier for brudd på RBAC, som for eksempel ureviderte rolletildelinger eller manglende grenbeskyttelse. Den varsler når tilgangskontrollpolicyer avviker fra definerte regler og håndhever korrigerende tiltak for å unngå utilsiktede sammenslåinger eller ondsinnede PR-er.
Låsing CI/CD Pipelines: CI-jobber kjører noen ganger med bredere omfang enn tiltenkt. Xygeni oppdager når CI/CD jobber ber om eller opererer utover sine tildelte roller, og identifiserer omfangskryp og misbruk av rettigheter i sanntid. Dette bidrar til å håndheve prinsipper for MAC-tilgangskontroll inni pipelineved å knytte tilgang strengt til jobbens identitet og formål.
Håndheving av kontroller for publisering av artefakter: Hvis utviklere fortsatt laster opp artefakter eller bilder manuelt, setter Xygeni en stopper for det. Den bruker obligatorisk tilgangskontroll på registernivå, slik at bare verifiserte pipeline Identiteter kan publisere artefakter. Ingen flere menneskelige opplastinger til produksjonsregistre.
Overvåking av tilgang og flagging av avvik: Med Xygeni får du innsikt i hvem som åpnet hva, når og hvordan. Den sporer kontinuerlig bruk av hemmeligheter, tilgang til depotet og registerinteraksjoner for å oppdage uvanlig oppførsel, flagge feilkonfigurasjoner og hjelpe med analyse etter hendelser.

Bottom line: Xygeni automatiserer og håndhever tilgangskontrollpolicyer, slik at DevOps-miljøet ditt forblir sikkert uten å bremse deg ned.

Hvilken tilgangskontrollpolicy trenger du? La oss analysere det

Innlegg du må lese