Quelle politique de contrôle d'accès vous faut-il ?

Pourquoi les développeurs ont besoin de véritables politiques de contrôle d'accès (et pas seulement de théorie)

Si vous poussez du code, maintenez pipelinePour gérer des registres d'artefacts ou pour gérer des registres d'artefacts, la théorie ne suffit pas. Des politiques de contrôle d'accès faibles ou indéfinies favorisent la falsification des dépôts. CI/CD abus, et fuites d'informations d'identificationDevSecOps exige une véritable application, pas seulement des paramètres d'autorisation cachés.

Pour gérer efficacement les politiques de contrôle d'accès dans les référentiels de code, CI/CD pipelines, et les registres d'artefacts, de nombreuses équipes s'appuient sur des outils d'application automatisés comme Xygeni. En surveillant en permanence les rôles, les autorisations et le respect des politiques, Xygeni contribue à prévenir les dérives d'autorisations, les accès non autorisés et les contournements manuels, transformant ainsi la théorie du contrôle d'accès obligatoire en action.

Le contrôle d'accès verrouille directement votre code source, sécurise vos builds et protège votre production pipelineSi les développeurs contournent les contrôles ou si les comptes de service disposent d'autorisations étendues, vous ouvrez la porte à des failles de sécurité. C'est pourquoi il est essentiel de comprendre le contrôle d'accès obligatoire, le contrôle d'accès MAC et d'autres modèles.

Types de politiques de contrôle d'accès que les développeurs doivent connaître

Les politiques de contrôle d'accès se répartissent en trois catégories principales, chacune s'adaptant différemment CI/CD Flux de travail. Voici une brève analyse comparative pour clarifier les choses :

Modèle	Qui contrôle l’accès ?	Utilisation typique dans CI/CD	Niveau de risque
DAC (Contrôle d'accès discrétionnaire)	Propriétaire de la ressource (développeur, administrateur)	Partage manuel de l'accès au référentiel ou au registre	Élevé (erreur humaine)
RBAC (Contrôle d'accès basé sur les rôles)	Le système attribue des autorisations par rôle	Protection des branches GitHub, accès aux tâches CI en fonction des rôles des utilisateurs	Moyen (rôles mal configurés)
MAC (Contrôle d'accès obligatoire)	Appliqué par la politique du système	Définit qui peut publier des artefacts ou déployer du code	Faible (la politique remplace l'intention de l'utilisateur)

Clarification MAC vs. RBAC dans CI/CD Contexte

Il est facile de confondre le contrôle d'accès basé sur les rôles (RBAC (Contrôle d'accès basé sur le rôle)) avec contrôle d'accès obligatoire (contrôle d'accès mac), notamment dans CI/CD environnements. Tandis que CI/CD des plateformes comme GitHub et GitLab utilisent RBAC pour gérer les rôles et les autorisations (par exemple, qui peut fusionner ou déployer), cela reste fondamentalement basé sur les rôles, et non sur un véritable contrôle d'accès MAC.

RBAC vous permet d'attribuer des autorisations en fonction des rôles (développeur, mainteneur, etc.), mais ces autorisations restent contrôlées et modifiables par l'utilisateur. Les erreurs de configuration ou la dérive des autorisations sont des risques courants.

Le contrôle d'accès obligatoire (MAC), en revanche, est appliqué au niveau du système ou de l'infrastructure. Les utilisateurs, y compris les administrateurs, ne peuvent pas le contourner. Considérez le contrôle d'accès Mac comme des politiques intégrées à la plateforme : politiques IAM des fournisseurs de cloud (par exemple, AWS IAM, GCP IAM) ou outils d'application au niveau du système d'exploitation comme SELinux ou AppArmor. Dans ces cas, l'accès n'est accordé que si des règles prédéfinies et non contournables sont respectées.

In CI/CDDe nombreux outils simulent le comportement du contrôle d'accès MAC via des rôles IAM étroitement définis ou des autorisations spécifiques aux ressources, mais il ne s'agit pas d'un contrôle d'accès obligatoire complet. Une véritable application du contrôle d'accès obligatoire nécessite des contrôles sous la couche applicative, au niveau du système d'exploitation, du réseau ou de l'infrastructure cloud, où l'accès est régi par des politiques de contrôle d'accès immuables, et non par une configuration humaine.

Contrôle d'accès basé sur les rôles (RBAC)

RBAC associe les autorisations à des rôles définis tels que « développeur », « mainteneur » ou « responsable des versions ». Il simplifie la gestion dans des outils comme GitHub et gitlab ceAu lieu de configurer utilisateur par utilisateur, attribuez-leur un rôle et laissez le système appliquer les règles.

Exemple : Fichier GitHub CODEOWNERS

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

Cela garantit que seuls les rôles attribués peuvent approuver les modifications dans les répertoires critiques.

Paramètres de rôle GitLab : configurez l’accès au projet dans Paramètres > Membres :

Développeur: Peut pousser vers les branches de fonctionnalités.
Mainteneur : Peut fusionner en branches protégées.
Invité: Accès en lecture seule.

Exemple de RBAC de workflow d'actions GitHub :

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

Contrôle d'accès obligatoire (MAC)

Le contrôle d'accès obligatoire (MAC) applique des règles strictes au niveau du système, que les utilisateurs et les administrateurs ne peuvent contourner. Utiliser le contrôle d'accès Mac pour contrôler étroitement qui peut lire, écrire ou exécuter des ressources critiques.

Exemple : Politique du registre d'artefacts de Google (YAML simplifié)

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

Cette politique accorde l'autorisation d'écriture uniquement au compte de service ci-deployer, garantissant que seuls les travaux CI avec cette identité peuvent envoyer des artefacts.

Exemple : Politique Amazon ECR (YAML simplifié)

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

Cette politique interdit toute action PutImage sur le référentiel ECR, sauf si elle est effectuée par le compte de service ci. Elle limite strictement les téléchargements d'images à ce compte de service.

Risques liés au remplacement manuel et comment MAC les prévient

L’un des plus grands risques liés au RBAC et Modèles DAC Il existe un risque de contournement manuel intentionnel ou accidentel. Par exemple, un administrateur ou un développeur peut télécharger directement des artefacts dans un registre protégé ou accorder des autorisations excessives en dehors des politiques de contrôle d'accès définies. Ces actions peuvent introduire des vulnérabilités ou entraîner des failles de conformité.

Le contrôle d'accès obligatoire (contrôle d'accès MAC) empêche de tels dépassements en appliquant des politiques au niveau du système qu'aucun utilisateur, même les administrateurs, ne peut contourner.cisLes ions sont régis par des règles immuables intégrées à l'infrastructure (comme les politiques IAM cloud ou les modules de sécurité au niveau du système d'exploitation). Cela signifie :

Un administrateur ne peut pas télécharger manuellement des artefacts dans un registre si la politique de contrôle d’accès Mac les refuse.
Les utilisateurs ne peuvent pas augmenter leurs privilèges ni modifier leurs autorisations en dehors des politiques de contrôle d’accès définies.
Chaînes de vente CI/CD pipelines'exécutent strictement dans le cadre des autorisations qui leur sont attribuées, évitant ainsi toute dérive de portée.

En éliminant les remplacements manuels, le contrôle d’accès obligatoire garantit une posture de sécurité plus solide et plus fiable que RBAC ou DAC seul.

2.4 Contrôle d'accès discrétionnaire (DAC)

DAC permet aux propriétaires de ressources d'attribuer manuellement les autorisations. C'est une solution flexible, mais risquée. Un partage erroné peut compromettre un dépôt. DAC fonctionne comme suit : « Vous êtes propriétaire, vous décidez qui y accède. »

Exemple: à Le développeur invite un collaborateur externe et lui accorde un accès en écriture au dépôt. Ce collaborateur envoie le code non sécurisé directement au développeur. dev branche.

In CI/CD, DAC peut ressembler à un développeur accordant manuellement l'accès au déploiement de production à un membre temporaire de l'équipe via la console, en dehors de toute politique de contrôle d'accès définie.

Comment choisir une politique de contrôle d'accès qui fonctionne en réalité Pipelines

Contrôle d'accès dans Git

Exploitez le RBAC pour gérer les rôles de contributeur, de mainteneur et de publication. Verrouillez les droits de fusion sur les branches protégées. Exigez la signature. commits et limiter qui peut contourner les protections.

Exemple : règles de protection des branches GitHub

Exiger pull request avis avant fusion.
Rejeter les obsolètes pull request approbations lorsque nouveau commits sont poussés.
Exiger une signature commits.
Évitez le DAC pour les dépôts critiques pour la production. N'accordez pas les droits d'écriture à la légère.

Pipeline Toujours vérifier

Mettre en place un contrôle d'accès obligatoire pour pipelines. Un modèle de contrôle d'accès Mac solide limite les tâches CI aux seules autorisations dont elles ont besoin.

Séparez les secrets par environnement.
Utilisez des jetons uniques par environnement.
Empêchez les exécutions manuelles d’affecter la production.

Exemple : un travail CI réutilise un jeton de déploiement entre la phase de préparation et la phase de production, poussant accidentellement le code de test vers le direct.

Ajoutez des règles de contrôle d'accès Mac pour contrôler la portée du jeton :

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

Exemple de définition de la portée des secrets : utilisation de jetons spécifiques à l'environnement

Il est essentiel de définir correctement la portée des secrets par environnement pour empêcher l'accès accidentel ou malveillant entre environnements. Par exemple, un jeton de déploiement pour l’environnement de développement ne doit jamais être utilisable pour un déploiement en production.

Voici comment les contrôles basés sur les politiques de contrôle d'accès isolent l'utilisation des secrets dans 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 }}

Cela impose que :

Seulement le promoteur rôle peut déclencher des déploiements en utilisant le jeton de développement sur le dev branche.
Seulement le responsable des versions rôle peut être déployé en production à l'aide du jeton de production sur le principal branche.

Une telle utilisation limitée des secrets réduit le risque de fuites de jetons qui s'étendent à travers les environnements et applique le principe du moindre privilège dans CI/CD pipelines suivant des politiques strictes de contrôle d’accès.

Contrôles d'accès aux artefacts

Verrouillez les registres d’artefacts à l’aide d’un contrôle d’accès obligatoire. CI/CD les systèmes devraient gérer la publication, et non les développeurs individuels.

Utilisez RBAC pour définir les équipes qui extraient des données de registres spécifiques. Les développeurs peuvent n'avoir besoin que d'un accès en lecture aux packages de production.

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

Échecs courants du contrôle d'accès dans les workflows de développement

Accès au référentiel trop permissif

Problème: Accorder à trop d'utilisateurs un accès en écriture/administration aux dépôts.
Comment cela se passe : Les membres de l'équipe sont promus ou ajoutés sans que leurs autorisations soient vérifiées. Les rôles deviennent alors pléthoriques.
Exploit de l'attaquant : Les attaquants ciblent ces comptes en utilisant des identifiants volés ou des techniques d'ingénierie sociale. Une fois à l'intérieur, ils peuvent injecter du code malveillant, créer des portes dérobées ou supprimer l'historique pour masquer les traces.

Autorisations partagées entre le développement et la production

Problème: Laisser le développement et la production pipelines partager les autorisations.
Comment cela se passe : Les équipes réutilisent le même jeton de déploiement ou le même compte de service CI dans tous les environnements.
Exploit de l'attaquant : Une violation de l’environnement de développement donne aux attaquants un accès à la production. Contrôle d'accès obligatoire peut empêcher cela en liant les autorisations à des environnements spécifiques.

Téléchargements manuels d'artefacts

Problème: Autoriser les téléchargements manuels d'artefacts vers les registres de production.
Comment cela se passe : Les développeurs contournent pipelines pour des correctifs rapides ou des correctifs à chaud.
Exploit de l'attaquant : Les machines de développement compromises peuvent télécharger des logiciels malveillants directement sur le stockage des artefacts, contournant ainsi tous les CI/CD contrôles de sécurité.

Risque d'abus de la politique du registre : La publication manuelle d'artefacts crée une surface d'attaque critique dans la chaîne d'approvisionnement logicielle. Les attaquants exploitent les failles politiques de contrôle d'accès peuvent insérer du code malveillant dans des packages ou des images de conteneurs fiables, entraînant une compromission généralisée en aval. De récents incidents dans la chaîne d'approvisionnement logicielle ont montré comment le téléchargement non réglementé d'artefacts peut rapidement dégénérer en failles de sécurité majeures, affectant d'innombrables utilisateurs et systèmes.

Exemple : unUn stagiaire disposant d'un accès complet au registre NPM publie par erreur une version instable. Si un attaquant avait compromis la machine de ce stagiaire, il aurait pu publier un logiciel malveillant.

Mesures pratiques pour appliquer des contrôles d'accès stricts

Associez les rôles à des autorisations précises et abandonnez les configurations à rôle unique
Automatisez les contrôles de politique de contrôle d'accès dans votre CI/CD pipelines
Verrouiller les registres avec un contrôle d'accès obligatoire
Enregistrez et surveillez en permanence l'accès aux systèmes critiques
Considérez les politiques de contrôle d'accès comme du code. Chaque erreur peut être exploitée.

Rôle de Xygeni : application et surveillance des politiques d'accès dans les workflows DevOps

Xygéni vous aide à transformer le contrôle d'accès obligatoire de la théorie à l'action en résolvant les défis réels et quotidiens d'application des politiques de contrôle d'accès dans DevSecOps pipelines.

Résolution des problèmes d'accès Git surautorisés : Xygeni surveille en permanence les dépôts Git pour détecter les violations RBAC, telles que les attributions de rôles non vérifiées ou les protections de branches manquantes. Il alerte lorsque les politiques de contrôle d'accès s'écartent des règles définies et applique des mesures correctives pour éviter les fusions accidentelles ou les demandes de publication malveillantes.
Confinement CI/CD Pipelines: Les tâches d'intégration continue (CI) s'exécutent parfois avec des portées plus larges que prévu. Xygeni détecte ces situations. CI/CD Les tâches demandent ou fonctionnent au-delà de leurs rôles assignés, ce qui permet d'identifier en temps réel les dérives de portée et les abus de privilèges. Cela contribue à appliquer les principes de contrôle d'accès MAC à l'intérieur. pipelineen liant strictement l'accès à l'identité et à l'objectif du poste.
Application des contrôles de publication d'artefacts : Si les développeurs continuent de télécharger manuellement des artefacts ou des images, Xygeni y met un terme. Il applique un contrôle d'accès obligatoire au niveau du registre afin que seules les données vérifiées soient vérifiées. pipeline Les identités peuvent publier des artefacts. Plus besoin de télécharger des données manuellement dans les registres de production.
Surveillance des accès et signalement des anomalies : Avec Xygeni, vous bénéficiez d'une visibilité sur qui a accédé à quoi, quand et comment. Il suit en continu l'utilisation des secrets, les accès aux référentiels et les interactions avec le registre pour détecter les comportements inhabituels, signaler les erreurs de configuration et faciliter l'analyse post-incident.

En résumé : Xygeni apporte l'automatisation et l'application de la politique de contrôle d'accès afin que votre environnement DevOps reste sécurisé sans vous ralentir.

Quelle politique de contrôle d'accès vous faut-il ? Décryptons-la.

Table des Matières

Articles à lire absolument

Derniers articles d'intérêt