Backup pull-only. Pourquoi la production ne doit jamais atteindre ses propres backups

La plupart des conceptions de backup sont bâties pour la panne que tout le monde imagine : un disque mort, une table supprimée, une mise à niveau ratée. La panne qui met réellement fin à des entreprises est différente. Quelqu'un entre sur un serveur de production, trouve les identifiants du backup posés là, et supprime les backups avant de chiffrer tout le reste. Cet article explique comment concevoir des backups qui survivent à ce jour-là, avec le modèle sur lequel nous construisons : le côté backup tire, la production ne pousse jamais, et les clés qui créent les backups ne peuvent pas les détruire.

Le problème du push

Le backup le plus simple est un cron sur le serveur qui copie des données vers une cible de backup. Il se met en place facilement, et il porte un défaut structurel. Pour pousser, le serveur de production a besoin d'une route vers la cible de backup et d'identifiants capables d'y écrire. Très souvent, ces identifiants peuvent aussi supprimer, écraser ou purger, parce que la rétention doit se faire quelque part et que le client est l'endroit évident.

Le serveur que vous protégez détient donc les clés de sa propre protection. Quiconque possède ce serveur possède ses backups. Les opérateurs de ransomware le savent, et la première chose que fait une intrusion compétente est de chercher les agents de backup, les partages de backup montés et les clés SSH qui pointent vers des hôtes de stockage.

Monter un partage de backup sur l'hôte de production en est la pire forme. Un partage accessible en écriture depuis la production n'est, du point de vue de l'attaquant, que du disque supplémentaire à chiffrer.

Retournez la flèche

Le remède est d'inverser le sens de la confiance. Le système de backup initie chaque connexion. Il entre dans la production, prend ce dont il a besoin et repart. La production n'a aucun chemin réseau vers l'infrastructure de backup et ne détient aucun identifiant pour elle.

Imposez-le là où cela ne peut pas être défait depuis un hôte compromis : sur l'appliance firewall entre les deux zones, pas dans le firewall hôte du serveur de backup. Le jeu de règles est court :

permit ip <management-subnet> host <backup-host>   ! admin access only
deny   ip any host <backup-host>                    ! production and everyone else
permit ip any any                                   ! leave other traffic alone

L'hôte de backup lui-même a besoin d'un accès sortant vers la production sur les ports qu'il utilise pour collecter les données, et de rien en entrée hormis depuis la gestion. Si une connexion depuis un hôte de production réussit encore, la conception n'est pas en vigueur, quoi qu'en dise le schéma.

C'est, dans l'esprit, un modèle de diode de données, et il correspond nettement aux contrôles sur lesquels les auditeurs interrogent : ségrégation de l'infrastructure de backup, moindre privilège et protection des frontières dans ISO/IEC 27001, NIS2 et NIST SP 800-53.

Moindre privilège côté production

Tirer signifie toujours que l'hôte de backup se connecte à la production. Cette connexion doit être inutile pour tout autre chose que prendre un backup. Avec SSH, c'est simple : donnez à la clé de l'hôte de backup une commande forcée et l'option restrict dans le authorized_keys du serveur de production.

command="rrsync -ro /srv/www",restrict ssh-ed25519 AAAA... backup-files
command="/usr/local/bin/backup-dump",restrict ssh-ed25519 AAAA... backup-db

La première clé ne peut que lire la racine web via rrsync en lecture seule. La seconde ne peut qu'exécuter un script de dump que vous avez écrit, qui prend un dump cohérent de la base de données (pour MySQL ou MariaDB, depuis un réplica ou un nœud qui ne reçoit pas d'écritures, avec --single-transaction ou un outil physique comme Percona XtraBackup) et l'envoie sur la sortie standard. Aucune des deux clés ne donne de shell, de redirection de port ni de transfert d'agent. Si l'hôte de backup lui-même était compromis, l'attaquant obtiendrait un accès en lecture aux données d'un client, pas le contrôle de la production.

Utilisez des clés distinctes pour des tâches distinctes, et des clés distinctes pour des clients distincts. Le rayon d'impact doit être une tâche chez un client.

Rendez le dépôt append-only

La seconde moitié de la conception est ce qui se passe côté backup. Avec BorgBackup, l'archiveur à déduplication, compression et chiffrement, un dépôt peut être accédé en mode append-only : de nouvelles archives peuvent être écrites, mais les données existantes ne peuvent être ni supprimées ni réécrites par ce chemin d'accès.

Quand Borg lui-même doit tourner sur la source (par exemple parce qu'une racine web contient des millions de petits fichiers et que vous voulez que la déduplication se fasse avant que les données ne traversent le réseau), vous pouvez quand même garder le hub aux commandes. Le hub ouvre la session SSH vers l'hôte de production et fournit un tunnel inverse vers lui-même, et le compte à l'autre bout de ce tunnel est verrouillé sur le hub :

command="borg serve --append-only --restrict-to-repository /srv/backup/tenants/<customer>/borg",restrict ssh-ed25519 AAAA... customer-node

L'hôte de production n'initie jamais rien. Il ne parle qu'en retour, à travers le tunnel que le hub a ouvert, et uniquement à son propre dépôt, en mode append-only.

La rétention devient alors une tâche séparée et locale sur le hub :

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /srv/backup/tenants/<customer>/borg
borg compact /srv/backup/tenants/<customer>/borg

Exécutez-la comme tâche privilégiée sur l'hôte de backup lui-même, jamais par le chemin que la production peut voir. Un attaquant qui chiffre le serveur d'un client peut, au pire, écrire davantage d'archives. Il ne peut pas retirer les anciennes.

Un dépôt, une clé, un client

Sur une plateforme de backup multi-clients, donnez à chaque client son propre dépôt et sa propre phrase secrète, avec le chiffrement activé à la création du dépôt :

borg init --encryption=repokey-blake2 /srv/backup/tenants/<customer>/borg

L'isolation tient alors au niveau cryptographique, pas seulement dans les permissions de fichiers : les données d'un client ne peuvent pas être lues avec la clé d'un autre client, même par quelqu'un disposant d'un shell sur le hub. La déduplication fonctionne toujours bien à l'intérieur d'un client, et entre les nœuds web quasi identiques d'un même client, le second nœud ne coûte presque rien.

Prouvez-le, ne lui faites pas confiance

Un job de backup vert vous dit que le job a tourné. Il ne vous dit pas que chaque machine qui compte a été couverte, ni que les données reviennent. Trois habitudes ferment cet écart.

1. Vérifiez la couverture par rapport à l'inventaire vivant. Listez ce qui tourne, listez ce qui a un backup frais sur disque, et comparez. Tout ce qui tourne sans point de restauration récent est une trouvaille.
2. Surveillez la fraîcheur, pas l'état. Mettez une alarme sur « heures depuis la dernière bonne archive » par client, pour qu'un job qui cesse silencieusement de tourner soit remarqué vite.
3. Restaurez selon un calendrier. Extrayez des fichiers, restaurez une base de données dans une instance de brouillon et vérifiez-la, régulièrement. Borg rend cela peu coûteux :

borg list /srv/backup/tenants/<customer>/borg
borg extract --dry-run /srv/backup/tenants/<customer>/borg::<archive>
borg check --verify-data /srv/backup/tenants/<customer>/borg

Les restaurations suivent aussi la règle du pull-only. L'hôte de backup, ou un ingénieur, livre les données restaurées à la production. La production ne reçoit jamais d'accès au dépôt, pas même « juste pour la restauration ».

Quoi vérifier sur votre propre plateforme

• Un serveur de production peut-il ouvrir une connexion vers votre stockage de backups ? Essayez.
• Des identifiants sur un serveur de production permettent-ils la suppression ou la purge des backups ?
• Y a-t-il un partage de backup monté, accessible en écriture, sur un hôte de production ?
• Les clés de backup sont-elles restreintes à une seule commande, ou donnent-elles un shell ?
• Chaque client ou système est-il dans son propre dépôt chiffré avec sa propre clé ?
• À quand remonte votre dernière restauration, et en avez-vous vérifié le résultat ?

Si une réponse vous met mal à l'aise, commencez par la règle de firewall. C'est le contrôle le moins coûteux de cette liste et il supprime en premier le chemin le plus dangereux.

Si vous souhaitez un second regard sur la conception de vos backups, nos ingénieurs seront heureux d'aider. Parler à un ingénieur

Related

Voir aussi : Backup infogéré sur Veeam et Borg, pull-only · Disaster recovery et réplicas entre sites