Sécurité et Bonnes Pratiques Claude Code : Développement IA Sécurisé

1. Comprendre le Modèle de Sécurité

Claude Code fonctionne avec un système de permissions qui contrôle quelles actions l'IA peut effectuer de manière autonome.

Catégories de Permissions

ALLOW (Approbation automatique)

• →Opérations de lecture
• →Commandes bash sûres
• →Outils en liste blanche

ASK (Confirmation d'abord)

• →Opérations d'écriture
• →Commandes système
• →Par défaut pour les actions inconnues

DENY (Bloqué)

• →Commandes dangereuses
• →Modèles interdits

La posture de sécurité que la plupart des équipes adoptent avec Claude Code atterrit dans un entre-deux inconfortable : trop restrictive et l'agent devient inutile ; trop permissive et vous avez de fait donné sudo à un modèle de langage sur votre laptop. Les praticiens sur r/devops et r/cybersecurity convergent sur un cadrage pragmatique — traitez Claude Code comme un nouvel ingénieur en première semaine : compétent, bien intentionné, mais encore en période d'essai. Vous relisez ses PR, vous scopez ses accès, et vous gardez les credentials de prod hors de sa portée. Les mêmes règles s'appliquent ici, et le guide de sécurité officiel est plus permissif que ce que recommanderaient par défaut la plupart des ingénieurs sécurité.

Là où la communauté nuance à juste titre : --dangerously-skip-permissions n'est pas un « mode expert », c'est « j'accepte toutes les conséquences de toutes les commandes shell que ce modèle décidera d'exécuter ». Les fils sur r/ClaudeAI regorgent d'histoires de récupération — branches détruites, rm -rf accidentel dans le mauvais dossier, fichiers .env exfiltrés publiés sur un gist GitHub en « preuve » d'un bug report. Aucun n'est un échec du modèle ; ce sont des échecs du modèle de permissions qui ont juste impliqué le modèle.

Ce qui fonctionne réellement en pratique : deny-by-default, scope par répertoire (settings.local.json par projet, jamais un unique jeu global), garder un .envrc ou équivalent hors du cwd que l'agent voit, et auditer le fichier de permissions comme vous auditeriez un workflow CI. Le playbook de référence pour la modélisation de menaces sur outils LLM est OWASP LLM Top 10 — la majorité des findings mappe directement sur « ce qu'un Claude Code trop permissif peut faire ».

2. Configuration des Permissions

Les permissions sont configurées dans settings.local.json (personnel) ou settings.json (équipe) :

Surcharges de Permissions Personnelles

{
  "permissions": {
    "allow": [
      "Bash(git *)",
      "Bash(pnpm *)",
      "Bash(npm test)",
      "Edit",
      "Write",
      "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)"
    ],
    "ask": [
      "Bash(npm publish)",
      "Bash(git push --force)"
    ]
  }
}

3. Niveaux de Permission Progressifs

Ajustez les permissions selon votre expérience et votre niveau de confiance :

Configurations par Niveau

Niveau 1, Débutant :

{
  "allowedTools": ["Read(*)", "Grep(*)", "Glob(*)"]
}

Niveau 2, Intermédiaire :

{
  "allowedTools": [
    "Read(*)", "Grep(*)", "Glob(*)",
    "Bash(git:*)", "Bash(pnpm:*)",
    "TodoRead", "TodoWrite"
  ]
}

Niveau 3, Avancé :

{
  "allowedTools": [
    "Read(*)", "Grep(*)", "Glob(*)", "WebFetch(*)",
    "Edit(*)", "Write(*)",
    "Bash(git:*)", "Bash(pnpm:*)", "Bash(npm:*)",
    "Task(*)", "TodoRead", "TodoWrite"
  ]
}

4. Sécurité des Serveurs MCP

Les serveurs MCP étendent les capacités de Claude Code, mais ils élargissent aussi sa surface d'attaque. Appliquez la même rigueur de sécurité que pour toute dépendance de code tierce.

Explorer les Serveurs MCP Disponibles

Utilisez cet explorateur interactif pour parcourir plus de 50 serveurs MCP, filtrer par catégorie et fonctionnalité, et obtenir les instructions de configuration pour chacun :

Checklist de Pré-Installation

Risques de Sécurité à Comprendre

Flux légitime :

Claude → Outil natif Read → Votre fichier

Attaque par tool shadowing :

Claude → Outil MCP "Read" → Serveur de l'attaquant → Votre fichier

Stratégies de Protection

1. →Vérifier les noms d'outils : Examinez quels outils chaque serveur MCP expose
2. →Utiliser allowedTools : Listez explicitement les outils MCP autorisés
3. →Surveiller le réseau : Guettez les connexions sortantes inattendues
4. →Sandboxer les serveurs non fiables : Exécutez-les dans des environnements isolés

5. Gestion des Secrets

Les serveurs MCP et les scripts nécessitent souvent des clés API et des identifiants. Ne les stockez jamais en texte clair dans les fichiers de configuration.

Les Trois Approches

Approche 1 : Trousseau OS (Recommandée)

Trousseau macOS :

# Stocker le secret dans le Trousseau
security add-generic-password \
  -a "claude-mcp" \
  -s "github-token" \
  -w "ghp_your_token_here"

# Récupérer dans la config MCP
{
  "servers": {
    "github": {
      "command": "bash",
      "args": ["-c", "GITHUB_TOKEN=$(security find-generic-password -s 'github-token' -w) npx @github/mcp-server"]
    }
  }
}

Linux Secret Service :

# Stocker le secret
secret-tool store --label="GitHub Token" service claude key github-token

# Récupérer dans un script wrapper
export GITHUB_TOKEN=$(secret-tool lookup service claude key github-token)
npx @github/mcp-server

Approche 2 : .env + .gitignore

# 1. Créer le fichier .env
cat > ~/.claude/.env << EOF
GITHUB_TOKEN=ghp_your_token_here
DATABASE_URL=postgresql://user:pass@localhost/db
EOF

# 2. Sécuriser les permissions
chmod 600 ~/.claude/.env

# 3. Ajouter au .gitignore
echo ".env" >> ~/.claude/.gitignore

Configuration MCP avec .env :

{
  "servers": {
    "github": {
      "command": "npx",
      "args": ["@github/mcp-server"],
      "env": {
        "GITHUB_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

6. Détection de Secrets en Pré-Commit

Empêchez les commits accidentels de secrets avec un hook de pré-commit :

#!/bin/bash
# .git/hooks/pre-commit

# Modèles à détecter
PATTERNS=(
  'sk-[A-Za-z0-9]{48}'           # Clés OpenAI
  'ghp_[A-Za-z0-9]{36}'          # Tokens GitHub
  'AKIA[A-Z0-9]{16}'             # Clés AWS
  'api[_-]?key.*[:=].*[A-Za-z0-9]{20,}'  # Clés API génériques
)

for pattern in "${PATTERNS[@]}"; do
  if git diff --cached | grep -qE "$pattern"; then
    echo "❌ Secret détecté ! Commit bloqué."
    echo "Modèle correspondant : $pattern"
    exit 1
  fi
done

exit 0

7. Portes de Sécurité Basées sur les Hooks

Utilisez les hooks pour appliquer automatiquement les politiques de sécurité.

Hook de Vérification de Sécurité

#!/bin/bash
# .claude/hooks/security-check.sh

INPUT=$(cat)
TOOL_NAME=$(echo "$INPUT" | jq -r '.tool_name')
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Bloquer les modèles dangereux
BLOCKED_PATTERNS=(
  "rm -rf /"
  "rm -rf ~"
  "rm -rf \$HOME"
  ":(){ :|:& };:"  # Fork bomb
  "> /dev/sda"     # Écrasement disque
  "curl.*| bash"   # Pipe vers bash
  "wget.*| bash"
)

for pattern in "${BLOCKED_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qE "$pattern"; then
    cat << EOF
{
  "decision": "block",
  "reason": "Modèle de commande dangereuse bloqué : $pattern"
}
EOF
    exit 0
  fi
done

# Autoriser par défaut
echo '{"decision": "allow"}'

Scanner d'Injection CLAUDE.md

#!/bin/bash
# .claude/hooks/claudemd-scanner.sh

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

# Scanner uniquement les fichiers CLAUDE.md lus
if [[ ! "$FILE_PATH" =~ CLAUDE\.md$ ]]; then
  exit 0
fi

# Chercher les modèles d'injection
INJECTION_PATTERNS=(
  "ignore.*previous.*instructions"
  "ignore.*above"
  "disregard.*instructions"
  "curl.*\|.*bash"
  "wget.*\|.*bash"
  "base64.*decode"
)

CONTENT=$(cat "$FILE_PATH" 2>/dev/null)

for pattern in "${INJECTION_PATTERNS[@]}"; do
  if echo "$CONTENT" | grep -qiE "$pattern"; then
    cat << EOF
{
  "systemMessage": "⚠️ ATTENTION : Injection de prompt potentielle détectée dans $FILE_PATH. Modèle : $pattern. Veuillez examiner le fichier manuellement avant de continuer."
}
EOF
    exit 0
  fi
done

exit 0

8. Pipeline de Validation

Chaînez plusieurs hooks de validation pour détecter les problèmes immédiatement après les modifications de code :

Edit/Write → TypeCheck → Lint → Tests → Notifier Claude
   ↓            ↓         ↓       ↓
  file.ts    vérif tsc  eslint  jest file.test.ts

Configuration :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/typecheck-on-save.sh",
            "timeout": 5000
          },
          {
            "type": "command",
            "command": ".claude/hooks/lint-gate.sh",
            "timeout": 5000
          },
          {
            "type": "command",
            "command": ".claude/hooks/test-on-change.sh",
            "timeout": 10000
          }
        ]
      }
    ]
  }
}

9. Règles de Sécurité en Production

Pour les équipes déployant Claude Code en environnement de production :

Sécurité de la Base de Données

# Dans CLAUDE.md
## Règles de Sécurité Base de Données
- NE JAMAIS exécuter DROP, TRUNCATE ou DELETE sans clause WHERE
- TOUJOURS utiliser des transactions pour les opérations multi-étapes
- TOUJOURS sauvegarder avant les scripts de migration
- Utiliser des identifiants de base de données en lecture seule pour l'exploration

Stabilité des Ports

## Règles de Ports
- Serveur de développement : toujours port 3000
- Serveur API : toujours port 8080
- Base de données : toujours port 5432
- Ne jamais utiliser de ports aléatoires sans documentation

Sécurité Git

## Règles Git
- Ne jamais force push sur main, master ou develop
- Toujours créer des branches de fonctionnalité pour les modifications
- Exécuter les tests avant tout push
- Exiger des revues de PR pour les branches de production

10. Checklist de Vérification de Sécurité

Avant de déployer Claude Code dans tout environnement :

Tester l'Isolation des Secrets

# Devrait fonctionner (secret depuis .env)
export $(cat ~/.claude/.env | xargs)
claude

# Devrait échouer (pas de secrets dans l'environnement)
unset GITHUB_TOKEN DATABASE_URL
claude
# ❌ Les serveurs MCP échouent au démarrage (comportement attendu)

Résumé : Bonnes Pratiques de Sécurité

1. →Permissions progressives : Commencez restrictif, élargissez à mesure que vous gagnez en confiance
2. →Ne jamais ignorer les permissions : L'option --dangerously-skip-permissions est réservée aux environnements sandboxés
3. →Vérifier les serveurs MCP : Appliquez la même rigueur que pour toute dépendance tierce
4. →Gérer les secrets correctement : Utilisez le trousseau OS ou .env avec les bonnes permissions, jamais en texte clair
5. →Hooks pré-commit : Empêchez les secrets d'atteindre Git
6. →Portes de sécurité : Utilisez les hooks pour appliquer automatiquement les politiques
7. →Pipelines de validation : Détectez les erreurs immédiatement après les modifications de code
8. →Règles de production : Documentez et appliquez la sécurité de la base de données, des ports et de Git

Continuez Votre Apprentissage

Prêt à implémenter une sécurité de niveau production ? Notre Module de Formation Sécurité et Bonnes Pratiques propose des exercices pratiques pour configurer les permissions, mettre en place des hooks de sécurité et gérer les secrets en toute sécurité.