Meilleures pratiques de sécurité pour OpenFang

24 min de lecture

La sécurité des agents IA autonomes ne doit pas être négligée. Dès sa conception, OpenFang intègre 16 niveaux de protection : 4 niveaux d'isolation en sandbox, 4 niveaux de sécurité réseau, 4 niveaux de sécurité des données et 4 niveaux d'audit et de conformité. Cet article propose trois modèles de configuration prédéfinis et une liste de contrôle de sécurité complète.

Meilleures pratiques de sécurité pour OpenFang : Analyse détaillée des 16 niveaux de protection

Slug: openfang-security-best-practices Catégorie: usage-guides (Guides d'utilisation) Mots-clés cibles: Sécurité OpenFang, Configuration de sécurité OpenFang, Meilleures pratiques de sécurité pour les agents Intention de recherche: Informationnelle (l'utilisateur souhaite déployer OpenFang en toute sécurité) Nombre de mots cible: ~2000 mots Langue: fr

Pourquoi la sécurité des agents est-elle cruciale ?

Les agents IA autonomes possèdent la capacité d'exécuter des commandes, d'accéder au réseau et de lire ou écrire des fichiers. Sans restrictions, ces capacités sont une recette pour le désastre. Un agent sans protection peut être manipulé par des attaques par injection de prompt pour exécuter des commandes dangereuses, divulguer des données sensibles ou être utilisé comme tremplin pour des attaques.

OpenFang a intégré la sécurité au cœur de son architecture dès le départ, offrant un mécanisme de protection à 16 niveaux. Cet article présente les méthodes de configuration et les meilleures pratiques pour chaque niveau, du plus simple au plus avancé.

Aperçu de l'architecture de sécurité

Les 16 niveaux de protection d'OpenFang sont divisés en quatre catégories :

CatégorieNiveauxObjectif de protection
Isolation Sandbox1–4Restreindre l'environnement d'exécution de l'agent
Sécurité réseau5–8Contrôler l'accès réseau de l'agent
Sécurité des données9–12Protéger les données sensibles contre les fuites
Audit et conformité13–16Enregistrer et auditer les comportements de l'agent

Première catégorie : Isolation Sandbox

Niveau 1 : Sandbox du système de fichiers

Restreindre les chemins du système de fichiers accessibles par l'agent :

toml
[security.sandbox.filesystem]mode = "strict"                  # off / basic / strictallowed_paths = [    "./workspace/",    "/tmp/openfang/",]denied_paths = [    "/etc/",    "~/.ssh/",    "~/.aws/",]read_only_paths = [    "./config/",    "/usr/share/openfang/",]

En mode strict, l'agent ne peut accéder à aucun chemin non listé dans allowed_paths. Il est recommandé de toujours créer un répertoire de travail dédié pour l'agent.

Niveau 2 : Sandbox des processus

Restreindre les commandes système que l'agent peut exécuter :

toml
[security.sandbox.process]allow_shell = false              # Interdire l'accès direct au Shellallowed_commands = [    "git",    "curl",    "python3",    "node",]denied_commands = [    "rm",    "sudo",    "chmod",    "wget",]command_timeout = 30             # Temps d'exécution maximal des commandes (secondes)

allow_shell = false est une configuration indispensable en environnement de production. L'agent ne peut interagir avec le système qu'à travers les commandes listées dans allowed_commands.

Niveau 3 : Limites de mémoire

Empêcher l'agent d'épuiser les ressources système en raison de fuites de mémoire ou de code malveillant :

toml
[security.sandbox.memory]max_memory_mb = 512              # Limite de mémoire de l'agentmax_per_hand_mb = 128            # Limite de mémoire par Handoom_policy = "kill_hand"         # kill_hand / restart / notify

Niveau 4 : Limites CPU

toml
[security.sandbox.cpu]max_cores = 2                    # Utilisation maximale de 2 cœurs CPUpriority = "low"                 # low / normal / highcfs_period_us = 100000cfs_quota_us = 50000             # Quota CPU de 50%

Deuxième catégorie : Sécurité réseau

Niveau 5 : Isolation réseau

Contrôler l'accès réseau sortant de l'agent :

toml
[security.network]mode = "allowlist"               # allowlist / blocklist / unrestrictedallowed_domains = [    "api.anthropic.com",    "api.openai.com",    "github.com",]allowed_ports = [443, 80]block_ip_ranges = [    "10.0.0.0/8",                # Bloquer l'accès au réseau interne    "172.16.0.0/12",    "192.168.0.0/16",]dns_over_https = true            # Utiliser le DNS chiffré

Niveau 6 : Chiffrement du trafic

toml
[security.network.tls]min_version = "1.2"verify_certificates = truecertificate_pinning = [    { domain = "api.anthropic.com", pin = "sha256/..." },]

Niveau 7 : Limitation de débit (Rate limiting)

Empêcher l'agent d'être utilisé pour envoyer un volume excessif de requêtes :

toml
[security.network.rate_limit]requests_per_minute = 60tokens_per_minute = 100000burst_multiplier = 2cooldown_after_exceeded = "5m"

Niveau 8 : Contrôle des proxies et des sorties

Tout le trafic de l'agent passe par le proxy de l'entreprise :

toml
[security.network.proxy]http_proxy = "${HTTP_PROXY}"https_proxy = "${HTTPS_PROXY}"no_proxy = ["localhost", "127.0.0.1"]enforce_proxy = true             # Forcer tout le trafic via le proxy

Troisième catégorie : Sécurité des données

Niveau 9 : Nettoyage des entrées

Protection contre les attaques par injection de prompt :

toml
[security.data.input_guard]enabled = truemode = "strict"[security.data.input_guard.rules]detect_jailbreak = truedetect_prompt_leak = truedetect_code_injection = truemax_input_length = 8000sanitize_markdown = true

Le nettoyeur d'entrées analyse les tentatives d'injection potentielles, y compris les prompts de jailbreak, les tentatives de fuite de prompt et les injections de code, avant que l'agent ne traite l'entrée utilisateur.

Niveau 10 : Filtrage des sorties

Empêcher la fuite de données sensibles via les réponses de l'agent :

toml
[security.data.output_guard]enabled = true[security.data.output_guard.patterns]credit_cards = trueapi_keys = true                  # Détecter et masquer le format des clés APIemails = "mask"                  # mask / block / allowphone_numbers = "mask"custom_patterns = [    "\\b(?:sk|pk)_[a-zA-Z0-9]{32,}\\b",    "\\bAKIA[A-Z0-9]{16}\\b",   # Clé d'accès AWS]

Niveau 11 : Chiffrement des données sensibles

toml
[security.data.encryption]encrypt_workspace = trueencrypt_logs = truekey_derivation = "argon2id"rotation_days = 30

Niveau 12 : Minimisation des données

toml
[security.data.minimization]log_user_inputs = false          # Ne pas enregistrer les entrées utilisateurlog_agent_outputs = false        # Ne pas enregistrer les sorties de l'agentretention_days = 7               # Conservation des logs pendant 7 joursstrip_pii = true                 # Supprimer automatiquement les PII

Quatrième catégorie : Audit et conformité

Niveau 13 : Audit des opérations

toml
[security.audit]enabled = truelog_level = "info"[security.audit.events]command_execution = truefile_access = truenetwork_request = trueconfig_change = truehand_start_stop = true

Les logs d'audit sont au format JSON et incluent l'horodatage, le type d'opération, l'opérateur, les détails et le résultat :

json
{  "timestamp": "2026-07-10T08:30:15.123Z",  "event": "command_execution",  "hand": "researcher",  "command": "git clone https://github.com/...",  "sandbox": "strict",  "result": "allowed",  "duration_ms": 1240}

Niveau 14 : Détection d'anomalies

toml
[security.audit.anomaly_detection]enabled = truebaseline_days = 7sensitivity = "medium"           # low / medium / highalert_on = ["unusual_command", "off_hours_activity", "unusual_destination"]

Niveau 15 : Rapports de conformité

toml
[security.compliance]generate_reports = trueschedule = "0 0 1 * *"           # Génération mensuelleframeworks = ["SOC2", "ISO27001"]export_format = "pdf"

Niveau 16 : Réponse aux incidents de sécurité

toml
[security.incident_response]auto_contain = true              # Isoler automatiquement l'agent en cas d'anomaliecontainment_action = "pause_all_hands"notify_channels = ["slack:#security", "email:[email protected]"]forensic_snapshot = true         # Enregistrer un instantané de la scène lors du déclenchement

Modèles de configuration de sécurité rapide

Choisissez la configuration de sécurité prédéfinie adaptée à votre scénario de déploiement :

Environnement de développement (exigences de sécurité faibles)

bash
openfang security preset development

Environnement de production (exigences de sécurité standard)

bash
openfang security preset production

Environnement hautement sécurisé (Finance/Santé/Gouvernement)

bash
openfang security preset hardened

Différences clés entre les trois modèles :

ConfigurationDevelopmentProductionHardened
Système de fichiersbasicstrictstrict
Accès ShellAutoriséInterditInterdit
Mode réseaublocklistallowlistallowlist
Filtrage sortieDésactivéActivéActivé
Logs d'auditDésactivéActivéActivé
Chiffrement donnéesDésactivéActivéActivé
Détection anomaliesDésactivémediumhigh
Isolation autoDésactivéDésactivéActivé

Liste de contrôle de sécurité

Avant le déploiement en production, utilisez la commande openfang security audit pour vérifier chaque point :

bash
openfang security audit# Exemple de sortie :# ✅ [1/16] Sandbox système de fichiers : strict# ✅ [2/16] Sandbox processus : aucun accès shell# ✅ [3/16] Limite mémoire : 512 Mo# ✅ [4/16] Limite CPU : 2 cœurs# ✅ [5/16] Réseau : mode allowlist# ⚠️ [6/16] TLS cert pinning : non configuré# ✅ [7/16] Limitation de débit : activée# ...# Score : 14/16 — 2 recommandations en attente

FAQ

Que faire si la configuration de sécurité est trop stricte et empêche l'agent de fonctionner correctement ?
Utilisez une stratégie d'assouplissement progressif. Commencez par le modèle hardened et observez le comportement de l'agent. Pour les opérations nécessaires bloquées, utilisez les logs d'audit pour identifier l'élément bloqué, puis ajoutez-le spécifiquement à la liste blanche.
L'injection de prompt peut-elle vraiment être contrée ?
Le nettoyeur d'entrées d'OpenFang offre une défense multicouche, mais aucune défense n'est parfaite. La meilleure pratique consiste à combiner plusieurs couches : nettoyage des entrées + restrictions sandbox + isolation réseau. Même si une injection réussit à contourner le nettoyage, les restrictions sandbox et réseau minimisent l'impact.
Comment superposer des couches de sécurité dans un environnement conteneurisé (Docker/K8s) ?
Les couches de sécurité d'OpenFang sont complémentaires à la sécurité au niveau de l'application, elles ne la remplacent pas. Les profils seccomp/AppArmor de Docker peuvent servir de couche de protection supplémentaire (niveau 0), mais ne doivent pas remplacer les mécanismes de sécurité intégrés d'OpenFang.
Que faire en cas d'incident de sécurité ?
1. Vérifiez les logs d'audit pour déterminer l'étendue de l'incident.
2. Si auto_contain = true est configuré, l'agent a déjà été isolé automatiquement.
3. Téléchargez l'instantané médico-légal : openfang security forensics download --run-id xxx
4. Analysez la cause profonde et corrigez la vulnérabilité.
5. Restaurez à partir d'un instantané ou réinitialisez l'agent.

Prochaines étapes