Welche Zugriffskontrollrichtlinie benötigen Sie?

Warum Entwickler echte Zugriffskontrollrichtlinien brauchen (nicht nur Theorie)

Wenn Sie Code pushen, pflegen pipelines oder die Verwaltung von Artefaktregistern, brauchen Sie mehr als nur Theorie. Schwache oder undefinierte Zugriffskontrollrichtlinien laden zur Manipulation von Repos ein, CI/CD Missbrauch und Anmeldeinformationslecks. DevSecOps erfordert eine echte Durchsetzung, nicht nur versteckte Berechtigungseinstellungen.

Um Zugriffskontrollrichtlinien über Code-Repositories hinweg effektiv zu verwalten, CI/CD pipelinesund Artefaktregistern verlassen sich viele Teams auf automatisierte Durchsetzungstools wie Xygeni. Durch die kontinuierliche Überwachung von Rollen, Berechtigungen und Richtlinieneinhaltung trägt Xygeni dazu bei, Berechtigungsabweichungen, unbefugten Zugriff und manuelle Überschreibungen zu verhindern und die Theorie der obligatorischen Zugriffskontrolle in die Tat umzusetzen.

Die Zugriffskontrolle sperrt Ihren Quellcode direkt, sichert Ihre Builds und schützt Ihre Produktion pipelineWenn Entwickler Kontrollen umgehen oder Dienstkonten über weitreichende Berechtigungen verfügen, öffnen Sie Tür und Tor für Sicherheitsverletzungen. Deshalb ist es wichtig, die obligatorische Zugriffskontrolle, die MAC-Zugriffskontrolle und andere Modelle zu verstehen.

Arten von Zugriffskontrollrichtlinien, die Entwickler kennen sollten

Zugriffskontrollrichtlinien lassen sich in drei Hauptkategorien unterteilen. Jede passt anders in CI/CD Arbeitsabläufe. Hier ist eine kurze Übersicht zur Verdeutlichung:

Modell	Wer kontrolliert den Zugriff?	Typische Verwendung in CI/CD	Risikostufe
DAC (Diskretionäre Zugriffskontrolle)	Ressourcenbesitzer (Entwickler, Administrator)	Manuelle Freigabe des Repo- oder Registry-Zugriffs	Hoch (menschliches Versagen)
RBAC (rollenbasierte Zugriffskontrolle)	Das System weist Berechtigungen nach Rolle zu	GitHub-Zweigschutz, CI-Jobzugriff basierend auf Benutzerrollen	Mittel (falsch konfigurierte Rollen)
MAC (Mandatory Access Control)	Durch Systemrichtlinie erzwungen	Legt fest, wer Artefakte veröffentlichen oder Code bereitstellen darf	Niedrig (Richtlinie überschreibt Benutzerabsicht)

Klärung von MAC vs. RBAC in CI/CD Kontext

Es ist leicht, die rollenbasierte Zugriffskontrolle (RBAC) mit obligatorischer Zugriffskontrolle (Mac-Zugriffskontrolle), insbesondere in CI/CD Umgebungen. Während CI/CD Plattformen wie GitHub und GitLab verwenden RBAC zum Verwalten von Rollen und Berechtigungen (z. B. wer zusammenführen oder bereitstellen kann). Dies ist jedoch grundsätzlich immer noch rollenbasiert und keine echte MAC-Zugriffskontrolle.

Mit RBAC können Sie Berechtigungen basierend auf Rollen (Entwickler, Betreuer usw.) zuweisen. Diese Berechtigungen sind jedoch weiterhin benutzergesteuert und änderbar. Fehlkonfigurationen oder schleichende Berechtigungserweiterungen sind häufige Risiken.

Die obligatorische Zugriffskontrolle (MAC-Zugriffskontrolle) hingegen wird auf System- oder Infrastrukturebene erzwungen. Benutzer, einschließlich Administratoren, können sie nicht außer Kraft setzen. Stellen Sie sich die Mac-Zugriffskontrolle als in die Plattform eingebettete Richtlinien vor: IAM-Richtlinien von Cloud-Anbietern (z. B. AWS IAM, GCP IAM) oder Durchsetzungstools auf Betriebssystemebene wie SELinux oder AppArmor. In diesen Fällen wird der Zugriff nur gewährt, wenn vordefinierte, nicht umgehbare Regeln erfüllt sind.

In CI/CDViele Tools simulieren das MAC-Zugriffskontrollverhalten durch eng begrenzte IAM-Rollen oder ressourcenspezifische Berechtigungen. Dies stellt jedoch keine vollständige obligatorische Zugriffskontrolle dar. Eine echte obligatorische Zugriffskontrolle erfordert Kontrollen unterhalb der Anwendungsebene, auf Betriebssystem-, Netzwerk- oder Cloud-Infrastrukturebene, wo der Zugriff durch unveränderliche Zugriffskontrollrichtlinien und nicht durch menschliche Konfiguration geregelt wird.

Rollenbasierte Zugriffskontrolle (RBAC)

RBAC ordnet Berechtigungen definierten Rollen wie „Entwickler“, „Betreuer“ oder „Release Manager“ zu. Es vereinfacht die Verwaltung in Tools wie GitHub und GitlabAnstatt die Konfiguration für jeden Benutzer einzeln vorzunehmen, weisen Sie ihnen eine Rolle zu und überlassen Sie die Durchsetzung der Regeln dem System.

Ejemplo: GitHub CODEOWNERS-Datei

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

Dadurch wird sichergestellt, dass nur die zugewiesenen Rollen Änderungen in kritischen Verzeichnissen genehmigen können.

GitLab-Rolleneinstellungen: Konfigurieren Sie den Projektzugriff unter Einstellungen > Mitglieder:

Entwickler: Kann auf Feature-Branches pushen.
Betreuer: Kann in geschützte Zweige integriert werden.
Gast: Nur Lesezugriff.

GitHub Actions Workflow RBAC-Beispiel:

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

Obligatorische Zugangskontrolle (MAC)

Die obligatorische Zugriffskontrolle (MAC-Zugriffskontrolle) erzwingt strenge Regeln auf Systemebene, die Benutzer und Administratoren nicht außer Kraft setzen können. Verwenden Sie die Mac-Zugriffskontrolle um streng zu kontrollieren, wer kritische Ressourcen lesen, schreiben oder ausführen kann.

Ejemplo: Google Artifact Registry-Richtlinie (vereinfachtes YAML)

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

Diese Richtlinie erteilt nur dem Dienstkonto „ci-deployer“ Schreibberechtigung und stellt sicher, dass nur CI-Jobs mit dieser Identität Artefakte pushen können.

Ejemplo: Amazon ECR-Richtlinie (vereinfachtes 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

Diese Richtlinie verweigert alle PutImage-Aktionen im ECR-Repository, sofern sie nicht vom CI-Service-Konto ausgeführt werden. Sie beschränkt das Hochladen von Bildern strikt auf dieses Service-Konto.

Risiken der manuellen Übersteuerung und wie MAC sie verhindert

Eines der größten Risiken bei RBAC und DAC-Modelle besteht die Gefahr absichtlicher oder versehentlicher manueller Überschreibungen. Beispielsweise könnte ein Administrator oder Entwickler Artefakte direkt in ein geschütztes Register hochladen oder übermäßige Berechtigungen außerhalb der definierten Zugriffskontrollrichtlinien erteilen. Diese Aktionen können Sicherheitslücken schaffen oder Compliance-Lücken verursachen.

Die obligatorische Zugriffskontrolle (MAC-Zugriffskontrolle) verhindert solche Außerkraftsetzungen, indem sie Richtlinien auf Systemebene durchsetzt, die kein Benutzer, nicht einmal Administratoren, umgehen kann. Zugriff decisionen werden durch unveränderliche Regeln geregelt, die in die Infrastruktur eingebettet sind (wie Cloud-IAM-Richtlinien oder Sicherheitsmodule auf Betriebssystemebene). Das bedeutet:

Ein Administrator kann Artefakte nicht manuell in ein Register hochladen, wenn die Mac-Zugriffskontrollrichtlinie dies verweigert.
Benutzer können ihre Privilegien nicht erhöhen oder Berechtigungen außerhalb der definierten Zugriffskontrollrichtlinien ändern.
Automated CI/CD pipelines werden streng im Rahmen der ihnen zugewiesenen Berechtigungen ausgeführt, wodurch eine Ausweitung des Funktionsumfangs verhindert wird.

Durch die Beseitigung manueller Übersteuerungen gewährleistet die obligatorische Zugriffskontrolle eine stärkere und zuverlässigere Sicherheitslage als RBAC oder DAC allein.

2.4 Diskretionäre Zugriffskontrolle (DAC)

Mit DAC können Ressourcenbesitzer Berechtigungen manuell zuweisen. Das ist flexibel, aber riskant. Eine falsche Freigabe kann ein Repository gefährden. DAC funktioniert nach dem Motto: „Du besitzt es, du entscheidest, wer Zugriff erhält.“

Beispiel: zu dev lädt einen externen Mitarbeiter ein und gewährt ihm Schreibzugriff auf das Repo. Der Mitarbeiter schiebt unsicheren Code direkt an den dev Ast.

In CI/CDDAC könnte so aussehen, dass ein Entwickler einem temporären Teammitglied manuell über die Konsole Zugriff auf die Produktionsbereitstellung gewährt, ohne dass eine definierte Zugriffskontrollrichtlinie vorliegt.

So wählen Sie eine Zugriffskontrollrichtlinie aus, die in der Praxis funktioniert Pipelines

Zugriffskontrolle in Git

Nutzen Sie RBAC, um die Rollen von Mitwirkenden, Betreuern und Releases zu verwalten. Sperren Sie Merge-Rechte für geschützte Zweige. Signierte commits und beschränken Sie, wer den Schutz umgehen kann.

Beispiel: GitHub-Branch-Schutzregeln

Erfordern pull request Überprüfungen vor dem Zusammenführen.
Abgestandene entlassen pull request Zulassungen bei Neu commits werden gepusht.
Signiert erforderlich commits.
Überspringen Sie DAC für produktionskritische Repos. Vergeben Sie Schreibzugriff nicht leichtfertig.

Pipeline aktionen

Setzen Sie eine obligatorische Zugriffskontrolle ein für pipelines. Ein solides Mac-Zugriffskontrollmodell beschränkt CI-Jobs auf die Berechtigungen, die sie benötigen.

Geheimnisse nach Umgebung trennen.
Verwenden Sie eindeutige Token pro Umgebung.
Verhindern Sie, dass manuelle Läufe die Produktion beeinträchtigen.

Ejemplo: Ein CI-Job verwendet ein Bereitstellungstoken für Staging und Produktion erneut und überträgt versehentlich Testcode in die Live-Phase.

Fügen Sie Mac-Zugriffskontrollregeln hinzu, um den Token-Umfang zu steuern:

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

Beispiel für den Umfang von Geheimnissen: Umgebungsspezifische Token-Verwendung

Die richtige Eingrenzung der Geheimnisse nach Umgebung ist entscheidend für Verhindern Sie versehentlichen oder böswilligen umgebungsübergreifenden Zugriff. Beispielsweise sollte ein Bereitstellungstoken für die Entwicklungsumgebung niemals für die Bereitstellung in der Produktion verwendet werden können.

So isolieren auf Zugriffsrichtlinien basierende Kontrollen die Verwendung von Geheimnissen in 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 }}

Dies erzwingt Folgendes:

Nur der Entwickler Rolle kann Bereitstellungen mithilfe des Dev-Tokens auf dem dev Ast.
Nur der Release-Manager Rolle kann mithilfe des Prod-Tokens auf der Haupt- Ast.

Eine solche eingeschränkte Nutzung von Geheimnissen verringert das Risiko, dass Token-Lecks über Umgebungen hinweg eskalieren und erzwingt das Prinzip der geringsten Privilegien in CI/CD pipelines Befolgen strenger Zugriffskontrollrichtlinien.

Zugriffskontrollen für Artefakte

Sperren Sie Artefaktregister mithilfe einer obligatorischen Zugriffskontrolle. CI/CD Die Veröffentlichung sollte von Systemen und nicht von einzelnen Entwicklern durchgeführt werden.

Verwenden Sie RBAC, um zu definieren, welche Teams aus bestimmten Registern abrufen. Entwickler benötigen möglicherweise nur Lesezugriff auf Produktionspakete.

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

Häufige Zugriffskontrollfehler in Entwicklungs-Workflows

Zu freizügiger Repo-Zugriff

Problem: Gewähren Sie zu vielen Benutzern Schreib-/Administratorzugriff auf Repos.
Wie es passiert: Teammitglieder werden befördert oder hinzugefügt, ohne dass die Berechtigungen überprüft werden. Die Rollen werden aufgebläht.
Angreifer-Exploit: Angreifer zielen mit gestohlenen Anmeldeinformationen oder Social Engineering auf diese Konten ab. Sobald sie sich Zugang verschafft haben, können sie Schadcode oder Hintertüren einschleusen oder den Verlauf löschen, um Spuren zu verwischen.

Gemeinsame Berechtigungen zwischen Entwickler und Produktion

Problem: Entwicklung und Produktion pipelines Freigabeberechtigungen.
Wie es passiert: Teams verwenden dasselbe Bereitstellungstoken oder CI-Dienstkonto in allen Umgebungen erneut.
Angreifer-Exploit: Durch einen Verstoß gegen die Entwicklungsumgebung erhalten Angreifer Zugriff auf die Produktion. Obligatorische Zugriffskontrolle kann dies verhindern, indem Berechtigungen an bestimmte Umgebungen gebunden werden.

Manuelle Artefakt-Uploads

Problem: Ermöglicht das manuelle Hochladen von Artefakten in Produktionsregister.
Wie es passiert: Entwickler umgehen pipelines für schnelle Lösungen oder Hot Patches.
Angreifer-Exploit: Kompromittierte Entwicklermaschinen können Malware direkt in den Artefaktspeicher hochladen und dabei alle CI/CD Sicherheitskontrollen.

Risiko des Missbrauchs der Registrierungsrichtlinie: Das manuelle Veröffentlichen von Artefakten schafft eine kritische Angriffsfläche in der Software-Lieferkette. Angreifer nutzen laxe Zugriffskontrollrichtlinien kann schädlichen Code in vertrauenswürdige Pakete oder Container-Images einfügen, was zu weitreichenden Kompromittierungen führt. Jüngste Vorfälle in der Software-Lieferkette haben gezeigt, wie unregulierte Artefakt-Uploads schnell zu schwerwiegenden Sicherheitsverletzungen führen können, die unzählige Benutzer und Systeme betreffen.

Beispiel: aEin Praktikant mit vollem Zugriff auf die NPM-Registrierung veröffentlicht versehentlich eine instabile Version. Hätte ein Angreifer den Rechner des Praktikanten kompromittiert, hätte er stattdessen Schadsoftware veröffentlichen können.

Praktische Schritte zur Durchsetzung strenger Zugriffskontrollen

Ordnen Sie Rollen genauen Berechtigungen zu und verzichten Sie auf einheitliche Rollenkonfigurationen.
Automatisieren Sie die Überprüfung der Zugriffskontrollrichtlinien in Ihrem CI/CD pipelines
Sperren Sie Register mit obligatorischer Zugriffskontrolle
Protokollieren und überwachen Sie kontinuierlich den Zugriff auf kritische Systeme
Behandeln Sie Zugriffskontrollrichtlinien wie Code. Jeder Fehltritt kann ausgenutzt werden

Xygenis Rolle: Durchsetzung und Überwachung von Zugriffsrichtlinien in DevOps-Workflows

Xygeni hilft Ihnen, die obligatorische Zugriffskontrolle von der Theorie in die Praxis umzusetzen, indem es reale, alltägliche Herausforderungen bei der Durchsetzung von Zugriffskontrollrichtlinien in DevSecOps löst pipelines.

Beheben von Problemen mit Git-Zugriffen mit zu vielen Berechtigungen: Xygeni überwacht Git-Repositories kontinuierlich auf RBAC-Verstöße wie nicht überprüfte Rollenzuweisungen oder fehlenden Branch-Schutz. Es warnt, wenn Zugriffskontrollrichtlinien von definierten Regeln abweichen, und erzwingt Korrekturmaßnahmen, um versehentliche Zusammenführungen oder böswillige PRs zu vermeiden.
Sperren CI/CD Pipelines: CI-Jobs werden manchmal mit größeren Umfängen ausgeführt als beabsichtigt. Xygeni erkennt, wenn CI/CD Jobs erfordern oder über ihre zugewiesenen Rollen hinausgehen, wodurch Scope Creep und Privilegienmissbrauch in Echtzeit erkannt werden. Dies trägt zur Durchsetzung der MAC-Zugriffskontrollprinzipien innerhalb pipelines, indem der Zugriff streng an die Identität und den Zweck des Jobs geknüpft wird.
Durchsetzung von Kontrollen zur Veröffentlichung von Artefakten: Wenn Entwickler immer noch manuell Artefakte oder Bilder hochladen, macht Xygeni dem ein Ende. Es wendet eine obligatorische Zugriffskontrolle auf Registrierungsebene an, sodass nur verifizierte pipeline Identitäten können Artefakte veröffentlichen. Keine menschlichen Uploads mehr in Produktionsregister.
Zugriffsüberwachung und Kennzeichnung von Anomalien: Mit Xygeni erhalten Sie Einblick, wer wann und wie auf was zugegriffen hat. Die Lösung verfolgt kontinuierlich die Nutzung von Geheimnissen, den Repository-Zugriff und die Registrierungsinteraktionen, um ungewöhnliches Verhalten zu erkennen, Fehlkonfigurationen zu kennzeichnen und die Analyse nach einem Vorfall zu unterstützen.

Bottom line: Xygeni automatisiert und setzt Zugriffskontrollrichtlinien durch, sodass Ihre DevOps-Umgebung sicher bleibt, ohne Sie auszubremsen.

Welche Zugriffskontrollrichtlinie benötigen Sie? Lassen Sie es uns aufschlüsseln

Inhaltsverzeichnis

Must-Read-Beiträge

Neueste interessante Beiträge