Waarom ontwikkelaars echte toegangscontrolebeleid nodig hebben (niet alleen theorie)
Als u code pusht, onderhoudt u pipelines, of het beheren van artefactregisters, heb je meer nodig dan theorie. Zwakke of ongedefinieerde toegangscontrolebeleidsregels nodigen uit tot manipulatie van de repository. CI/CD misbruik, en lekken van legitimatiebewijzenDevSecOps vereist echte handhaving, niet alleen verborgen machtigingsinstellingen.
Om effectief toegangscontrolebeleid in codeopslagplaatsen te beheren, CI/CD pipelines, en artefactregisters, vertrouwen veel teams op geautomatiseerde handhavingstools zoals Xygeni. Door rollen, machtigingen en naleving van beleid continu te bewaken, helpt Xygeni om machtigingsafwijkingen, ongeautoriseerde toegang en handmatige overrides te voorkomen, waardoor de theorie van verplichte toegangscontrole in de praktijk wordt omgezet.
Toegangscontrole vergrendelt uw broncode direct, beveiligt uw builds en beschermt uw productie pipelineAls ontwikkelaars controles omzeilen of serviceaccounts brede rechten hebben, zet u de deur open voor beveiligingsinbreuken. Daarom is inzicht in verplichte toegangscontrole, MAC-toegangscontrole en andere modellen cruciaal.
Soorten toegangscontrolebeleid die ontwikkelaars moeten kennen
Toegangscontrolebeleid valt in drie hoofdcategorieën uiteen, die elk op een andere manier passen CI/CD workflows. Hier is een korte, naast elkaar liggende analyse ter verduidelijking:
| Model | Wie beheert de toegang? | Typisch gebruik in CI/CD | Risico niveau |
|---|---|---|---|
| DAC (Discretionaire Toegangscontrole) | Resource-eigenaar (ontwikkelaar, beheerder) | Handmatig delen van repo- of registertoegang | Hoog (menselijke fout) |
| RBAC (op rollen gebaseerde toegangscontrole) | Systeem wijst rechten toe op basis van rol | Bescherming van GitHub-branches, toegang tot CI-taken op basis van gebruikersrollen | Medium (verkeerd geconfigureerde rollen) |
| MAC (Verplichte Toegangscontrole) | Afgedwongen door systeembeleid | Handhaaft wie artefacten kan publiceren of code kan implementeren | Laag (beleid overschrijft gebruikersintentie) |
Verduidelijking van MAC versus RBAC in CI/CD Context
Het is gemakkelijk om op rollen gebaseerde toegangscontrole te verwarren (RBAC) met verplichte toegangscontrole (mac-toegangscontrole), vooral in CI/CD omgevingen. Terwijl CI/CD Platformen zoals GitHub en GitLab gebruiken RBAC om rollen en machtigingen te beheren (bijvoorbeeld wie kan samenvoegen of implementeren), maar dit is nog steeds fundamenteel rolgebaseerd en geen echte MAC-toegangscontrole.
Met RBAC kunt u machtigingen toewijzen op basis van rollen (ontwikkelaar, beheerder, enz.), maar deze machtigingen blijven wel door de gebruiker beheerd en aanpasbaar. Verkeerde configuraties of permission creep zijn veelvoorkomende risico's.
Verplichte toegangscontrole (MAC-toegangscontrole) wordt daarentegen afgedwongen op systeem- of infrastructuurniveau. Gebruikers, inclusief beheerders, kunnen deze niet negeren. Beschouw Mac-toegangscontrole als beleid dat in het platform is geïntegreerd: IAM-beleid in cloudproviders (bijv. AWS IAM, GCP IAM) of afdwingingstools op besturingssysteemniveau zoals SELinux of AppArmor. In deze gevallen wordt toegang alleen verleend wanneer aan vooraf gedefinieerde, niet-omzeilbare regels wordt voldaan.
In CI/CDVeel tools simuleren MAC-toegangscontrolegedrag via nauwkeurig gedefinieerde IAM-rollen of resourcespecifieke machtigingen, maar dit is geen volledige verplichte toegangscontrole. Echte verplichte toegangscontrole vereist controles onder de applicatielaag, op het niveau van het besturingssysteem, het netwerk of de cloudinfrastructuur, waar de toegang wordt beheerd door onveranderlijke toegangscontrolebeleidsregels en niet door menselijke configuratie.
Op rollen gebaseerde toegangscontrole (RBAC)
RBAC koppelt machtigingen aan gedefinieerde rollen zoals 'ontwikkelaar', 'beheerder' of 'releasemanager'. Het vereenvoudigt het beheer in tools zoals GitHub en GitLabIn plaats van het configureren per gebruiker, wijst u ze toe aan een rol en laat u het systeem de regels afdwingen.
Voorbeeld: GitHub CODEOWNERS-bestand
# CODEOWNERS /docs/ @doc-team /scripts/ @devops-team /main.py @maintainers Hiermee wordt gegarandeerd dat alleen de toegewezen rollen wijzigingen in kritieke mappen kunnen goedkeuren.
GitLab-rolinstellingen: Configureer projecttoegang in Instellingen > Leden:
- Ontwikkelaar: Kan naar feature branches pushen.
- Onderhouder: Kan worden samengevoegd tot beschermde takken.
- Gast: Alleen-lezen toegang.
Voorbeeld van RBAC in GitHub Actions Workflow:
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 Verplichte toegangscontrole (MAC)
Verplichte toegangscontrole (MAC-toegangscontrole) dwingt strikte regels op systeemniveau af die gebruikers en beheerders niet kunnen overschrijven. Gebruik Mac-toegangscontrole om strikt te controleren wie cruciale bronnen kan lezen, schrijven of uitvoeren.
Voorbeeld: Google Artifact Registry-beleid (vereenvoudigde YAML)
yaml bindings: - role: roles/artifactregistry.writer members: - serviceAccount:ci-deployer@project.iam.gserviceaccount.com Voorbeeld: Amazon ECR-beleid (vereenvoudigde 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 Risico's van handmatige override en hoe MAC deze voorkomt
Een van de grootste risico's bij RBAC en DAC-modellen is de kans op opzettelijke of onbedoelde handmatige overschrijvingen. Een beheerder of ontwikkelaar kan bijvoorbeeld artefacten rechtstreeks uploaden naar een beveiligd register of buitensporige rechten verlenen buiten het gedefinieerde toegangscontrolebeleid. Deze acties kunnen kwetsbaarheden introduceren of compliance-hiaten veroorzaken.
Verplichte toegangscontrole (MAC-toegangscontrole) voorkomt dergelijke overschrijvingen door beleid op systeemniveau af te dwingen dat geen enkele gebruiker, zelfs geen beheerders, kan omzeilen.cisionen worden beheerd door onveranderlijke regels die in de infrastructuur zijn ingebed (zoals IAM-beleid in de cloud of beveiligingsmodules op besturingssysteemniveau). Dit betekent:
- Een beheerder kan artefacten niet handmatig uploaden naar een register als het toegangscontrolebeleid van de Mac deze weigert.
- Gebruikers kunnen hun rechten niet verhogen of machtigingen wijzigen buiten de gedefinieerde toegangscontrolebeleidsregels.
- Automatische CI/CD pipelineworden strikt binnen de toegewezen rechten uitgevoerd, waardoor scope creep wordt voorkomen.
Doordat handmatige overschrijvingen worden geëlimineerd, zorgt verplichte toegangscontrole voor een sterkere en betrouwbaardere beveiliging dan alleen RBAC of DAC.
2.4 Discretionaire toegangscontrole (DAC)
Met DAC kunnen resource-eigenaren handmatig rechten toewijzen. Het is flexibel, maar riskant. Eén verkeerde share kan een repository in gevaar brengen. DAC werkt als volgt: "Jij bent de eigenaar, jij bepaalt wie erin komt."
Voorbeeld: The dev nodigt een externe medewerker uit en geeft hem/haar schrijftoegang tot de repository. De medewerker pusht onveilige code rechtstreeks naar de dev tak.
In CI/CDDAC kan eruit zien alsof een ontwikkelaar handmatig via de console toegang tot productie-implementatie verleent aan een tijdelijk teamlid, buiten de gedefinieerde toegangscontrolebeleidsregels om.
Hoe kiest u een toegangscontrolebeleid dat in de praktijk werkt? Pipelines
Toegangscontrole in Git
Gebruik RBAC om de rollen van bijdragers, beheerders en releases te beheren. Vergrendel samenvoegingsrechten voor beveiligde branches. Vereist ondertekende commiten beperk wie de beveiliging kan omzeilen.
Voorbeeld: GitHub Branch Protection Rules
- Vereisen pull request beoordelingen vóór de fusie.
- Verwijder verouderd pull request goedkeuringen wanneer nieuw commits worden geduwd.
- Vereist ondertekend commits.
- Sla DAC over voor productiekritieke opslagplaatsen. Geef niet zomaar schrijftoegang.
Pipeline Handhaving
Zorg voor verplichte toegangscontrole voor pipelines. Een solide Mac-toegangscontrolemodel beperkt CI-taken tot alleen de machtigingen die ze nodig hebben.
- Scheid geheimen per omgeving.
- Gebruik unieke tokens per omgeving.
- Voorkom dat handmatige processen de productie beïnvloeden.
Voorbeeld: Een CI-taak hergebruikt een implementatietoken in de staging- en productieomgeving en pusht daardoor onbedoeld testcode naar live.
Voeg Mac-toegangscontroleregels toe om het tokenbereik te beheren:
yaml env: DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }} if: github.ref == 'refs/heads/main' && github.actor == 'release-manager' Voorbeeld van geheimenbereik: omgevingsspecifiek tokengebruik
Het is van cruciaal belang om geheimen op de juiste manier per omgeving te definiëren. voorkom onbedoelde of kwaadaardige toegang tot andere omgevingen. Een implementatietoken voor de ontwikkelomgeving mag bijvoorbeeld nooit gebruikt kunnen worden voor implementatie in productie.
Dit is hoe op toegangscontrolebeleid gebaseerde besturingselementen het gebruik van geheimen in GitHub Actions isoleren:
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 }} Hiermee wordt afgedwongen dat:
- Alleen de ontwikkelaar rol kan implementaties activeren met behulp van het dev-token op de dev tak.
- Alleen de release-manager rol kan worden geïmplementeerd in productie met behulp van het prod-token op de hoofd- tak.
Een dergelijk beperkt geheim gebruik vermindert het risico dat tokenlekken escaleren in verschillende omgevingen en dwingt de minste privileges af in CI/CD pipelines volgens een streng toegangscontrolebeleid.
Toegangscontrole voor artefacten
Vergrendel artefactregisters met verplichte toegangscontrole. CI/CD Systemen moeten de publicatie afhandelen, niet individuele ontwikkelaars.
Gebruik RBAC om te definiëren welke teams gegevens uit specifieke registers halen. Ontwikkelaars hebben mogelijk alleen leestoegang nodig tot productiepakketten.
json { "rules": [ { "action": "read", "resource": "npm-package:internal/*", "allowed_roles": ["developer", "qa"] }, { "action": "write", "resource": "npm-package:internal/*", "allowed_principals": ["ci-pipeline"] } ] } Veelvoorkomende fouten bij toegangscontrole in Dev-workflows
Overmatig permissieve repo-toegang
probleem: Te veel gebruikers schrijf-/beheerdersrechten tot opslagplaatsen verlenen.
Hoe het gebeurt: Teamleden worden gepromoveerd of toegevoegd zonder dat de rechten worden gecontroleerd. Rollen worden opgeblazen.
Exploit van aanvaller: Aanvallers richten zich op deze accounts met behulp van gestolen inloggegevens of social engineering. Eenmaal binnen kunnen ze schadelijke code, backdoors of het verleden verwijderen om sporen te verbergen.
Gedeelde rechten tussen Dev en Prod
probleem: Dev en prod laten pipelines deelrechten.
Hoe het gebeurt: Teams hergebruiken hetzelfde implementatietoken of CI-serviceaccount in verschillende omgevingen.
Exploit van aanvaller: Bij een inbreuk op de ontwikkelomgeving krijgen aanvallers toegang tot de productieomgeving. Verplichte toegangscontrole kan dit voorkomen door machtigingen te binden aan specifieke omgevingen.
Handmatige artefactuploads
probleem: Handmatige uploads van artefacten naar productieregisters toestaan.
Hoe het gebeurt: Ontwikkelaars omzeilen pipelinevoor snelle oplossingen of hot patches.
Exploit van aanvaller: Gecompromitteerde ontwikkelaarsmachines kunnen malware rechtstreeks naar de artefactopslag uploaden, waardoor alle CI/CD veiligheidscontroles.
Risico op misbruik van registerbeleid: Het handmatig publiceren van artefacten creëert een kritiek aanvalsoppervlak in de softwaretoeleveringsketen. Aanvallers die misbruik maken van laksheid toegangscontrole beleid Kan schadelijke code in vertrouwde pakketten of containerimages invoegen, wat leidt tot wijdverspreide downstream-compromissen. Recente incidenten in de softwaretoeleveringsketen hebben aangetoond hoe ongereguleerde uploads van artefacten snel kunnen escaleren tot grote beveiligingsinbreuken, met gevolgen voor talloze gebruikers en systemen.
Voorbeeld: eenEen stagiair met volledige NPM-registertoegang publiceert per ongeluk een onstabiele versie. Als een aanvaller de computer van die stagiair had gehackt, had hij in plaats daarvan malware kunnen publiceren.
Praktische stappen om sterke toegangscontroles af te dwingen
- Wijs rollen toe aan exacte machtigingen en laat de 'one-rol-fits-all'-configuratie achterwege
- Automatiseer toegangscontrolebeleidcontroles in uw CI/CD pipelines
- Sluit registers af met verplichte toegangscontrole
- Registreer en bewaak continu de toegang tot kritieke systemen
- Behandel toegangscontrolebeleid als code. Elke misstap kan worden uitgebuit.
De rol van Xygeni: het afdwingen en bewaken van toegangsbeleid in DevOps-workflows
Xygeni helpt u bij het omzetten van verplichte toegangscontrole van theorie naar actie door het oplossen van echte, dagelijkse uitdagingen op het gebied van het afdwingen van toegangscontrolebeleid in DevSecOps pipelines.
- Problemen met Git-toegang met te veel rechten oplossen: Xygeni controleert Git-repositories continu op RBAC-schendingen, zoals niet-gecontroleerde roltoewijzingen of ontbrekende branchbeveiligingen. Het waarschuwt wanneer toegangsbeheerbeleid afwijkt van de gedefinieerde regels en dwingt corrigerende maatregelen af om onbedoelde samenvoegingen of kwaadaardige PR's te voorkomen.
- Vergrendelen CI/CD Pipelines: CI-taken worden soms uitgevoerd met een bredere scope dan bedoeld. Xygeni detecteert wanneer CI/CD Taken verzoeken om of werken buiten hun toegewezen rollen, waardoor scope creep en misbruik van privileges in realtime worden geïdentificeerd. Dit helpt bij het handhaven van MAC-toegangscontroleprincipes binnen pipelinedoor de toegang strikt te koppelen aan de identiteit en het doel van de baan.
- Handhaving van controles op het publiceren van artefacten: Als ontwikkelaars nog steeds handmatig artefacten of afbeeldingen uploaden, maakt Xygeni daar een einde aan. Het past verplichte toegangscontrole op registerniveau toe, zodat alleen geverifieerde pipeline Identiteiten kunnen artefacten publiceren. Geen menselijke uploads meer naar productieregisters.
- Toegang bewaken en anomalieën signaleren: Met Xygeni krijgt u inzicht in wie, wanneer en hoe toegang heeft gehad tot wat. Het volgt continu het gebruik van geheimen, toegang tot repositories en registerinteracties om ongebruikelijk gedrag te detecteren, misconfiguraties te signaleren en te helpen bij analyse na incidenten.
Bottom line: Xygeni automatiseert en handhaaft toegangscontrolebeleid, zodat uw DevOps-omgeving veilig blijft zonder dat dit uw prestaties vertraagt.
Behandel toegangscontrole daarom als Code Security
Iedereen met implementatierechten of infrastructuurtoegang kan je app kapotmaken, per ongeluk of niet. Daarom is een ijzersterk toegangscontrolebeleid geen optie. Gebruik RBAC om rollen correct te delegeren. Pas verplichte toegangscontrole toe op kritieke systemen. Sla DAC volledig over voor productiepaden. Integreer toegangscontrolebeleid in uw Aanbevolen werkwijzen voor DevSecOps. Automatiseer ze. Monitor ze. Handhaaf ze.
TL; DR:Een goed gehandhaafd toegangscontrolebeleid zorgt er automatisch voor dat uw codebase, artefacten en infrastructuur veiliger zijn.
