Réseau, audit et réseau isolé
Cette page couvre les contrôles qui régissent où AiHummer peut être atteint et atteindre, *ce qu’*il enregistre, et de quoi il est construit : la liste blanche des IP administratives, le mode isolé, le journal d’audit et la posture de la chaîne d’approvisionnement.
Niveau : ceci sont des contrôles de niveau payant, pas gratuits/à l’échelle de la plateforme. Le niveau qui bloque chacun :
| Fonctionnalité | Niveau |
|---|---|
| Liste blanche IP administrateur | Affaires+/Entreprise |
| Journal d’audit | Affaires |
| Mode isolé | Entreprise |
Liste blanche IP (contrôle d’accès IP administrateur)
Vous pouvez restreindre la surface d’administration aux réseaux connus avec un Liste d’autorisation IP, géré à /v1/admin/security/ip-allowlist. Une fois configuré, l’accès administrateur est contrôlé par l’adresse IP source, donc l’API et l’interface utilisateur administratives ne répondent qu’aux requêtes provenant des adresses que vous jugez fiables.
[!TIP] Combinez la liste blanche IP avec SSO d’entreprise et clés API limitées: la régulation du réseau limite où de, SSO limite qui, et les scopes limitent quoi.
Mode isolé
Pour les déploiements souverains ou isolés, définir AIHUMMER_AIRGAPPED=1 bloquer sortie publique contrôlée par modèle. Dans ce mode, les outils de l’agent ne peuvent pas accéder à l’internet public pour le compte du modèle, ce qui supprime toute une catégorie de risques d’exfiltration et de SSRF.
# /home/.aihummer/etc/gateway.env
AIHUMMER_AIRGAPPED=1[!WARNING] Le mode isolé désactive les outils qui dépendent de la sortie publique (par exemple récupérations open-web). Associez-le à des sidecars auto-hébergés et à des modèles locaux afin que le le déploiement reste entièrement fonctionnel sans appels externes. Pour un contrôle plus précis en l’absence d’une séparation complète par air, utilisez les listes d’autorisation de sortie décrites dans Garde-corps.
Journal d’audit
Les modifications de l’administrateur sont enregistrées dans un journal d’audit avec rétention et pagination, lisible à /v1/admin/audit. La rétention est contrôlée par AIHUMMER_AUDIT_RETENTION_DAYS, afin que vous puissiez conserver une trace aussi longtemps que l’exige votre politique de conformité et laisser les anciennes entrées expirer.
# /home/.aihummer/etc/gateway.env
AIHUMMER_AUDIT_RETENTION_DAYS=365La piste d’audit s’associe naturellement avec RBAC et SSO : SSO et la liste blanche d’IP déterminent qui peut agir, les clés limitées décident ce qu’ils peuvent faire, et le journal d’audit enregistre ce qu’ils ont fait.
Chaîne d’approvisionnement et posture d’exécution
Le temps d’exécution d’AiHummer est délibérément petit et inspectable :
| Propriété | Posture |
|---|---|
| Passerelle | Un seul binaire Go (plan de contrôle + moteur TURN). |
| Dépendances directes | Environ 25 modules Go directs — une surface petite et vérifiable. |
| Emballage | Hôte-natif : paquet tar + systemd, pas de Docker. |
| Side-cars | Services HTTP séparés accessibles par URL, installés uniquement si nécessaire. |
[!NOTE] L’emballage natif de l’hôte signifie qu’il n’y a pas de runtime de conteneur à renforcer ou à corriger en complément de l’application — vous exécutez un binaire Go sous systemd à partir de
/home/.aihummer. Il s’agit d’une propriété vérifiable de la manière dont le produit est livré, pas une affirmation concernant la sécurité absolue.
Où aller ensuite
- SSO d’entreprise — qui est autorisé à entrer.
- RBAC et clés API à portée — ce qu’ils peuvent faire une fois à l’intérieur.
- Garde-fous et défense contre l’injection d’instructions — sortie listes autorisées et protection SSRF pour les outils qui se connectent.