Isolation de l'agent

Ce que fait l'isolation de l'agent

L'agent tourne dans un service du système : une unité systemd sur Linux, un service sous LocalSystem sur Windows. Ce service porte des réglages de durcissement, et ses dossiers ne sont lus que par les comptes d'administration de la machine.

L'agent n'écoute sur aucun port du réseau. Il ouvre lui-même toutes ses connexions, en HTTPS. Son seul canal local est un socket Unix sur Linux, ou un tube nommé sur Windows.

Un administrateur de la machine garde le dernier mot. Quatre interrupteurs locaux coupent les restaurations depuis le portail, le parcours des dossiers, les partages réseau et les scripts. La plateforme ne les rallume pas.

Cette page donne les droits du service, les dossiers, le durcissement et les interrupteurs. Elle sert au DSI qui doit valider l'agent avant son déploiement.

Prérequis

• Aucun rôle du portail. Cette page décrit un comportement de l'agent sur la machine.
• Pour les vérifications et pour les interrupteurs : root sur Linux, ou un administrateur local sur Windows.
• Un agent installé. Voir Installer l'agent sur Linux ou Installer l'agent sur Windows.

Les noms et les chemins de cette page sont ceux du produit BaaStide. Avec un profil en marque blanche, ils portent les noms choisis par le MSP. Voir Marque blanche de l'agent.

Le compte du service

	Linux	Windows
Compte	root	LocalSystem
Service	Unité baastide.service	Service BaaStide
Démarrage	Au démarrage de la machine, après le réseau	Automatique différé, après le réseau
Après une panne	Redémarrage 10 secondes plus tard, autant de fois que nécessaire	Redémarrage 10 secondes plus tard, après toute défaillance
Surveillance	Chien de garde systemd de 60 secondes	L'agent contrôle son verrou toutes les 30 secondes et s'arrête après 2 minutes bloqué

L'agent tourne avec les droits les plus élevés de la machine. Il lit ainsi tous les fichiers à sauvegarder, et une restauration écrit dans les chemins d'origine. BaaStide ne propose pas de compte de service dédié.

Sur Windows, le service porte son propre identifiant de sécurité, NT SERVICE\BaaStide. Vous donnez les droits SQL Server à cet identifiant, sans mot de passe. Voir Sauvegarder SQL Server.

Les dossiers et les fichiers de l'agent

Contenu	Linux	Windows
Programme	/usr/local/bin/baastide	%ProgramFiles%\BaaStide\baastide.exe
Identité de la machine	/etc/baastide/agent.conf	%ProgramData%\BaaStide\agent.conf
État des mises à jour	/var/lib/baastide	%ProgramData%\BaaStide\state
Cache	/var/cache/baastide	%ProgramData%\BaaStide\cache
Journal	Journal du système (journalctl -u baastide)	%ProgramData%\BaaStide\log\agent.log
Canal local de restauration	/run/baastide/restore.sock	\\.\pipe\baastide-restore

Les droits sur ces dossiers :

• Linux : les dossiers sont en mode 0700, et le fichier d'identité en mode 0600. Ils appartiennent à root. Le service utilise UMask=0077 : un fichier qu'il crée est privé.
• Windows : %ProgramData%\BaaStide et agent.conf portent une liste de contrôle d'accès protégée, avec l'accès complet pour SYSTEM et pour les administrateurs seulement. Les sous-dossiers héritent de cette liste. Aucun héritage ne vient du dossier parent.
• L'installation refuse un dossier %ProgramData%\BaaStide qui existe déjà et qui appartient à un autre compte : ce propriétaire pourrait changer la liste d'accès.
• L'installation et chaque démarrage du service reposent cette liste d'accès.

Le fichier d'identité porte le secret de l'agent. Les clés des dépôts, elles, ne sont dans aucun fichier de la machine. Voir Chiffrement et clés.

Le durcissement du service sur Linux

L'unité baastide.service est fournie par l'agent. Elle porte ces réglages :

Réglage	Effet
NoNewPrivileges=yes	Un processus lancé par l'agent ne gagne aucun droit en plus, même par un fichier setuid.
ProtectKernelModules=yes	Le service ne charge aucun module du noyau.
ProtectKernelTunables=yes	Les réglages du noyau sont en lecture seule pour le service.
ProtectClock=yes	Le service ne change pas l'horloge de la machine.
ReadOnlyPaths	Le programme de l'agent et son dossier /usr/lib/baastide sont en lecture seule pour le service.
PrivateTmp=yes	Le service a ses propres /tmp et /var/tmp, effacés à son arrêt.
UMask=0077	Les fichiers créés par le service sont privés.
LimitCORE=0	Aucun fichier d'image mémoire n'est écrit après un arrêt brutal. Un secret ne peut donc pas sortir par ce fichier.

Deux points restent ouverts par nécessité :

• Le système de fichiers reste accessible en écriture. Une restauration depuis le portail écrit dans les chemins d'origine.
• Un réglage du noyau pour le réseau reste accessible en écriture. Le démarrage d'une VM ou d'un conteneur restauré sur un hôte Proxmox VE en a besoin.

Le canal local de restauration

La commande baastide restore restaure sur place, sans le portail. Elle parle à l'agent par un canal local :

• Sur Linux, le canal est un socket Unix en mode 0600, dans un dossier en mode 0700 qui appartient au compte du service. La commande refuse un socket qui n'est pas dans un tel dossier.
• Sur Windows, le canal est un tube nommé avec la même liste d'accès que les dossiers de l'agent. Il refuse un client distant. La commande vérifie que le tube appartient à SYSTEM ou aux administrateurs, et elle n'autorise aucune usurpation d'identité.
• La création du tube échoue quand son nom existe déjà. Personne ne prend donc sa place, et une deuxième instance de l'agent ne démarre pas.
• La commande envoie seulement la sélection et le dossier cible. Elle ne reçoit ni la clé du dépôt, ni le jeton d'accès au dépôt. L'agent les garde en mémoire.

Voir Restaurer en ligne de commande sur la machine.

Les interrupteurs locaux

Quatre réglages du fichier d'identité coupent une fonction sur une machine. Ils suivent les mêmes règles :

• Seul root, ou un administrateur local sur Windows, les change.
• La plateforme ne les change pas, et le portail ne les rallume pas. La plateforme apprend qu'un interrupteur est coupé par la réponse de l'agent à un ordre.
• L'agent les relit à chaque ordre. Aucun redémarrage n'est nécessaire.
• Une réécriture du fichier d'identité garde leur valeur. Un enrôlement de nouveau, ou un déplacement vers une autre instance, ne les rallume donc pas.

Réglage	Ce qu'il coupe	Page de la fonction
portal_restore	Les restaurations demandées depuis le portail. La commande locale reste possible.	Choisir la bonne restauration
browse	La lecture des dossiers de la machine depuis le portail.	Couper le parcours de la machine
shares	Tous les ordres qui touchent un partage réseau.	Sauvegarder un partage réseau
scripts	Les scripts avant et après une sauvegarde.	Scripts avant et après une sauvegarde

Couper le parcours de la machine

Le portail lit les dossiers de la machine en direct quand un technicien choisit les chemins d'une politique. Coupez cette lecture quand votre politique interne l'interdit.

1. Ouvrez une session root sur la machine Linux, ou une session d'administrateur sur la machine Windows.
2. Ouvrez le fichier d'identité avec un éditeur de texte : /etc/baastide/agent.conf sur Linux, ou %ProgramData%\BaaStide\agent.conf sur Windows.
3. Ajoutez la ligne "browse": false, juste après la première accolade.
4. Enregistrez le fichier. Le fichier reste au format JSON.
5. Gardez le mode 0600 et le propriétaire root sur Linux. Gardez la liste d'accès sur Windows.
6. Dans le portail, ouvrez une politique de fichiers de cette machine.
7. Cliquez Parcourir la machine, sous le champ Chemins.

Le portail écrit alors : « Le parcours est désactivé sur cette machine. Tapez le chemin à la main. » Un technicien tape les chemins à la main. Voir Politique de sauvegarde de fichiers.

Remettez la valeur à true, ou retirez la ligne, pour rallumer le parcours.

Ce que le parcours ne montre jamais

Le parcours ne remplace pas un accès à la machine. Même allumé, il reste borné :

• L'agent lit un seul niveau d'un dossier par ordre. Il ne lit aucun contenu de fichier.
• Sur Linux, ces dossiers ne sont pas listés : /proc, /sys, /dev, /run, /etc/baastide, /var/lib/baastide et /var/cache/baastide. Les systèmes de fichiers virtuels sont refusés, y compris par un montage lié.
• Sur Windows, le chemin / liste les lecteurs. Ces dossiers ne sont pas listés : les dossiers de l'agent, System Volume Information et les dossiers de travail des restaurations, à la racine de chaque lecteur.
• L'agent ouvre le chemin nom par nom, sans suivre un lien ni un point de jonction. Un lien est listé, jamais suivi.
• Un ordre s'arrête au bout de 5 secondes, ou après 100 000 éléments dans un dossier.
• Le journal de l'agent garde l'identifiant de l'ordre, la durée, le nombre d'éléments et le code d'erreur. Il ne garde ni le chemin, ni les noms.

Couper les scripts sur une machine

1. Ouvrez une session root sur la machine Linux, ou une invite d'administrateur sur la machine Windows.
2. Exécutez baastide agent scripts off.
3. Exécutez baastide agent scripts pour lire l'état en cours.

Pour couper les scripts dès l'installation, ajoutez --no-scripts à install.sh, ou -NoScripts à install.ps1. Voir Scripts avant et après une sauvegarde.

Vérifier l'isolation sur une machine Linux

1. Ouvrez une session root sur la machine.
2. Exécutez systemctl cat baastide.service. La commande donne l'unité et ses ajouts.
3. Vérifiez les réglages de durcissement du tableau ci-dessus.
4. Exécutez stat -c '%a %U' /etc/baastide /etc/baastide/agent.conf. Attendez 700 root puis 600 root.
5. Exécutez stat -c '%a %U' /var/lib/baastide /var/cache/baastide. Attendez 700 root deux fois.
6. Exécutez ss -lntp. Aucune ligne ne nomme l'agent : il n'écoute sur aucun port.
7. Exécutez systemctl status baastide. Lisez l'état du service et son dernier démarrage.

Vérifier l'isolation sur une machine Windows

1. Ouvrez une invite PowerShell en tant qu'administrateur.
2. Exécutez Get-Service BaaStide. Lisez l'état du service.
3. Exécutez sc.exe qc BaaStide. Vérifiez SERVICE_START_NAME : LocalSystem et un démarrage automatique différé.
4. Exécutez (Get-Acl "$env:ProgramData\BaaStide").Access. Seuls SYSTEM et les administrateurs ont l'accès complet.
5. Exécutez (Get-Acl "$env:ProgramData\BaaStide\agent.conf").Access. Attendez la même liste.
6. Exécutez Get-Acl "$env:ProgramData\BaaStide" | Select-Object Owner. Le propriétaire est SYSTEM ou le groupe des administrateurs.

Limites et précautions

• Le durcissement ne protège pas la machine contre son propre administrateur. Root sur Linux, et un administrateur local sur Windows, lisent l'identité de l'agent, coupent ses interrupteurs et désinstallent l'agent.
• L'agent tourne en root ou sous LocalSystem. Un script avant ou après une sauvegarde s'exécute avec ce même compte. Relisez chaque script. Voir Scripts avant et après une sauvegarde.
• Avec baastide restore sur Linux, ne choisissez pas une cible dans /tmp ni dans /var/tmp. Le service a ses propres dossiers temporaires : vous ne retrouveriez pas les fichiers. L'agent refuse d'ailleurs une cible qu'un administrateur ne voit pas.
• Pour changer un réglage de l'unité sur une seule machine, posez un fichier d'ajout dans /etc/systemd/system/baastide.service.d/. Une mise à jour de l'agent remplace l'unité quand elle diffère de la référence, mais elle ne touche jamais vos fichiers d'ajout.
• Sur un système avec une version de systemd antérieure à 236, le programme de l'agent n'est pas en lecture seule pour le service. L'installation pose alors un fichier d'ajout qui garde le retour à la version précédente.
• Si le fichier d'identité existe mais devient illisible, une réécriture coupe le parcours, les partages réseau et les scripts. L'agent ne rallume jamais un interrupteur par défaut.
• Le fichier d'identité est un secret. Ne le copiez pas d'une machine à une autre : chaque machine a sa propre identité.
• Une désinstallation retire le programme, le service et les dossiers de l'agent. Elle garde le dossier des fichiers restaurés quand il n'est pas vide. Voir Désinstaller l'agent.

Référence

• CLI de l'agent : baastide agent scripts pour l'interrupteur des scripts.
• CLI de l'agent : baastide restore pour le canal local de restauration.
• CLI de l'agent : baastide agent pour le service.