Sécurité
Aperçu
Neotask est conçu avec une architecture axée sur la sécurité. Le Gateway se lie à localhost par défaut, toutes les données sensibles sont chiffrées au repos, et l'exécution des agents peut être mise en bac à sable dans des conteneurs isolés.
Sécurité réseau
Boucle locale par défaut
Le Gateway écoute uniquement sur 127.0.0.1 (localhost) à moins que vous ne changiez explicitement le mode de liaison. Aucune exposition réseau externe par défaut.
Authentification
Toutes les connexions WebSocket nécessitent une authentification :
- Auth par jeton, Jeton porteur (UUID ou chaîne personnalisée)
- Auth par mot de passe, Mot de passe haché Bcrypt
- Proxy de confiance, En-têtes pré-authentifiés provenant de proxys inverses
- Confiance locale, Les connexions de boucle locale sont implicitement de confiance
Sécurité de l'accès distant
Pour l'accès distant, l'approche recommandée est Tailscale VPN ou le tunnel SSH, n'exposez jamais le Gateway directement à Internet.
Couplage des appareils
Fonctionnement du couplage
Chaque client qui se connecte au Gateway doit être couplé :
- L'appareil présente son identité (empreinte + clé publique)
- Le Gateway émet un défi de couplage (nonce)
- L'appareil signe le nonce avec sa clé privée
- Vous approuvez l'appareil via l'interface utilisateur
- Le Gateway émet un jeton d'appareil pour les connexions futures
Modèle de confiance
- Les appareils locaux (boucle locale) sont auto-approuvés pour plus de commodité
- Les appareils non locaux nécessitent une approbation explicite
- Les jetons d'appareil sont stockés localement et réutilisés lors de la reconnexion
- Les appareils peuvent être révoqués à tout moment
Chiffrement
Données au repos
- AES-256-GCM, Tous les jetons, secrets et clés API sont chiffrés au repos
- Clés dérivées de la machine, Clés de chiffrement dérivées via scrypt de l'identité de l'appareil
- Aucun stockage en clair, Les jetons ne sont jamais stockés en clair
Données en transit
- TLS, HTTPS pour la communication API
- WSS, WebSocket sécurisé pour les connexions Gateway (lors de l'utilisation de Tailscale Serve ou d'un proxy inverse)
- Signature HMAC, Intégrité des requêtes avec nonce et horodatage
Bac à sable
Isolation basée sur Docker
L'exécution des commandes d'agents peut être mise en bac à sable dans des conteneurs Docker :
- Profils par agent, Chaque agent peut avoir sa propre configuration de bac à sable
- Limites de ressources, Limites configurables de CPU, mémoire et délai d'expiration
- Isolation réseau, Les conteneurs peuvent être isolés du réseau
- Confinement du système de fichiers, Les agents accèdent uniquement à leur espace de travail
- Images personnalisées, Utiliser des images préconstruites avec des outils spécifiques installés
Portées du bac à sable
| Portée | Description |
|---|---|
| Par session | Conteneur frais pour chaque session |
| Par agent | Conteneur persistant par agent |
| Partagé | Conteneur partagé entre les agents |
Accès à l'espace de travail
Les agents mis en bac à sable peuvent accéder à leur répertoire d'espace de travail (monté dans le conteneur) mais ne peuvent pas accéder au système de fichiers hôte en dehors de leur espace de travail.
Approbations d'exécution
Contrôlez quelles commandes les agents peuvent exécuter sur les nœuds et l'hôte du Gateway :
Modes
| Mode | Description |
|---|---|
| Liste d'autorisation | Seules les commandes préapprouvées s'exécutent |
| Demande | Les commandes inconnues demandent l'approbation de l'utilisateur |
| Complet | Aucune restriction (utiliser avec précaution) |
Configuration par nœud
Chaque nœud (macOS, hôte headless) a sa propre configuration d'approbation d'exécution, stockée localement. Vous pouvez autoriser des binaires spécifiques (par ex., /usr/bin/docker, /usr/local/bin/terraform) tout en bloquant tout le reste.
Mode élevé
Certaines opérations nécessitent de s'exécuter directement sur l'hôte du Gateway (pas dans un bac à sable). Le mode élevé est :
- Contrôlé par une permission explicite dans la configuration de l'agent
- Disponible uniquement sur l'hôte du Gateway
- Désactivé par défaut
- Auditable via la journalisation
Audit de sécurité
L'audit de sécurité intégré vérifie :
- Permissions des fichiers de configuration (devrait être 600)
- Permissions des fichiers de session
- Version de Node.js (correctifs de sécurité)
- Détection de secrets en clair
- Validation de la liste d'autorisation des plugins
- Audit des interfaces réseau ouvertes
- Complétude de la configuration d'authentification
L'audit peut corriger automatiquement de nombreux problèmes lorsque la permission est accordée.
Meilleures pratiques
- Gardez le Gateway sur la boucle locale, Utilisez Tailscale ou SSH pour l'accès distant
- Activez le bac à sable, Exécutez les commandes des agents dans des conteneurs Docker
- Utilisez des listes d'autorisation d'exécution, Limitez les commandes que les agents peuvent exécuter sur les nœuds
- Définissez des jetons d'authentification, Configurez toujours l'authentification par jeton, même pour la boucle locale
- Vérifiez les permissions des agents, Utilisez des profils d'outils minimaux lorsque c'est possible
- Maintenez Neotask à jour, Les mises à jour incluent des correctifs de sécurité
- Auditez régulièrement, Exécutez des audits de sécurité pour détecter les mauvaises configurations
- Limitez le chargement des plugins, N'installez que des plugins de confiance