Module 7 : Sécurité DevOps
Service Connections
Les Service Connections permettent aux pipelines d'accéder aux ressources Azure :
# Types de Service Connections
+----------------------------------------------------------+
| Azure Resource Manager | Accès aux ressources Azure |
| GitHub | Accès aux repos GitHub |
| Docker Registry | Accès aux registres Docker |
| Kubernetes | Accès aux clusters K8s |
| Generic | Connexion personnalisée |
+----------------------------------------------------------+
# Créer une Service Connection (Portal)
Project Settings > Service Connections > New
Type: Azure Resource Manager
Authentication: Service Principal (automatic)
Scope: Subscription ou Resource Group
Name: azure-folab-dev
Workload Identity Federation
Recommandé : Utiliser Workload Identity Federation au lieu des secrets :
- Pas de secret à gérer
- Pas de rotation de credentials
- Plus sécurisé
# Service Connection avec Workload Identity
# Project Settings > Service Connections > New
Authentication method: Workload Identity federation (automatic)
# Le pipeline s'authentifie automatiquement via OIDC
# Sans stocker de secret
Gestion des secrets
# Option 1: Variable Groups liées à Key Vault
# Library > Variable Groups > New
Name: folab-secrets
Link secrets from Azure Key Vault: Yes
Azure subscription: azure-folab-dev
Key vault name: kv-folab-dev
Secrets: sql-connection-string, storage-key
# Utilisation dans le pipeline
variables:
- group: folab-secrets
steps:
- script: echo "Using secret..."
env:
SQL_CONN: $(sql-connection-string)
# Option 2: Variables secrètes inline (à éviter)
variables:
- name: mySecret
value: $(secret-from-library) # Jamais en clair!
Permissions Pipeline
| Permission | Description |
|---|---|
| Queue builds | Lancer des builds |
| Edit build pipeline | Modifier les pipelines |
| Manage build resources | Gérer agents et pools |
| Administer release | Admin des releases |
# Restreindre l'accès aux Service Connections
# Project Settings > Service Connections > [connection] > Security
Pipeline permissions:
- Restrict to specific pipelines
- Selected pipelines: ESG-Pipeline, Perf-Pipeline
# Restreindre l'accès aux Variable Groups
# Library > Variable Groups > [group] > Security
Pipeline permissions:
- Restrict
Sécurité des agents
# Agent self-hosted sécurisé
# - Réseau isolé (VNet)
# - Pas d'accès Internet direct
# - Accès via Private Endpoints
# - Service account avec droits minimaux
# Configuration agent pool
pool:
name: 'DataLab-Secure-Agents'
# Limiter les pipelines autorisés
# Organization Settings > Agent Pools > [pool] > Security
Pipeline permissions: Restricted
Audit et logs
# Azure DevOps Audit Logs
# Organization Settings > Auditing
Events tracés:
- Pipeline runs
- Service connection usage
- Permission changes
- Repository access
# Exporter vers Log Analytics
# Organization Settings > Auditing > Stream to Log Analytics
# Query KQL
AzureDevOpsAuditing
| where Area == "Pipelines"
| where OperationName == "Pipeline.RunCreated"
| project TimeGenerated, ActorDisplayName, Data
| order by TimeGenerated desc
Analyse de sécurité du code
# Intégrer des scans de sécurité dans le pipeline
# Microsoft Security DevOps (MSDO)
- task: MicrosoftSecurityDevOps@1
displayName: 'Run security scans'
inputs:
categories: 'secrets,code'
# Dependabot / WhiteSource
- task: WhiteSource@21
inputs:
cwd: '$(Build.SourcesDirectory)'
projectName: 'FOLAB-Data'
# SonarQube pour la qualité
- task: SonarQubePrepare@5
inputs:
SonarQube: 'SonarQube-Connection'
projectKey: 'folab-synapse'
projectName: 'FOLAB Synapse'
- task: SonarQubeAnalyze@5
- task: SonarQubePublish@5
inputs:
pollingTimeoutSec: '300'
Checklist sécurité DevOps
- [ ] Service Connections avec Workload Identity
- [ ] Secrets dans Key Vault (pas inline)
- [ ] Branch policies sur main/develop
- [ ] Approbations pour déploiement Prod
- [ ] Audit logs activés
- [ ] Scans de sécurité dans CI
- [ ] Principe du moindre privilège
- [ ] Agents dans réseau sécurisé