Sauvegarde et restauration sécurisées - Meilleures pratiques

Par Chander Kant et Dmitri Joukovski

Au cours des dernières années, de nombreux titres ont fait la une des journaux concernant des incidents très médiatisés de bandes de sauvegarde perdues ou volées. Malgré une attention croissante portée à la sécurité, les procédures de sauvegarde sont souvent négligées dans les politiques de sécurité globales. La principale raison de cet écart est que, historiquement, la sauvegarde et la sécurité ont eu des objectifs presque opposés. Les procédures de sécurité nécessitent souvent un contrôle d'accès strict aux données de l'utilisateur. Le logiciel de sauvegarde, cependant, est optimisé pour simplifier la récupération, parfois sur une plate-forme ou un emplacement différent et souvent par une personne autre que le propriétaire d'origine des données.

En utilisant l'exemple du plus populaire logiciel de sauvegarde et de restauration open source, Amanda, nous examinerons les meilleures pratiques pour assurer la sécurité des données de sauvegarde. Plus précisément, nous examinerons les aspects suivants de la sécurité des sauvegardes:

Vos systèmes contactent-ils vraiment le bon serveur de sauvegarde?

La plupart des centres de données reposent sur une sauvegarde basée sur le réseau. Pour ce faire en toute sécurité, une relation de confiance doit être établie entre le client de sauvegarde (la machine en cours de sauvegarde) et le serveur de sauvegarde (la machine effectuant la sauvegarde). Sans un moyen vérifiable d'établir cette relation de confiance, diverses attaques de type "man-in-the-middle" peuvent se produire.

Une vulnérabilité possible est le cas où le logiciel de sauvegarde permet au client de sauvegarde de spécifier que tout serveur de sauvegarde peut lancer une sauvegarde. Contrairement à Amanda, certains outils de sauvegarde à source fermée populaires sont livrés avec ce paramètre par défaut. À moins que vous ne soyez conscient de cette vulnérabilité et que vous ne modifiez le paramètre par défaut, toute personne disposant d'un ordinateur portable ou de bureau peut installer la version d'essai du package de sauvegarde et lancer la sauvegarde de n'importe quel client de sauvegarde de votre organisation. Ces sauvegardes pourraient alors facilement être dirigées vers le disque d'un serveur de sauvegarde non autorisé.

Une préoccupation similaire existe dans la direction opposée. Votre serveur de sauvegarde fournit-il des données à restaurer sur le système approprié? Ou est-ce que quelqu'un force un système à se faire passer pour un client de sauvegarde?

Une approche bien meilleure exige que le logiciel de sauvegarde utilise une authentification forte à la fois du client de sauvegarde et du serveur de sauvegarde. Bien entendu, la méthode d'authentification doit également être soumise à un examen minutieux. Un bon choix serait un mécanisme basé sur des clés, similaire à celui proposé par l'outil open source openssh (http://www.openssh.com).

Vos données de sauvegarde peuvent-elles être compromises lorsqu'elles parcourent le réseau ou si votre bande de sauvegarde «tombe du camion»?

Cela ne sert à rien si votre client et votre serveur s'authentifient l'un l'autre, seulement pour découvrir que quelqu'un a intercepté les données de sauvegarde. Ceci est particulièrement important si vos données de sauvegarde transitent sur un réseau non sécurisé, par exemple sur Internet d'un bureau régional au siège.

Au cours des dernières années, il y a eu des événements très médiatisés où les entreprises perdent la trace de leurs bandes de sauvegarde. Ces derniers impliquent souvent la perte d'informations financières sensibles. Lors d'un de ces incidents en 2005, une société bien connue à temps partagé a perdu des bandes de sauvegarde contenant des informations financières sensibles pour 260,000 XNUMX de ses clients. De toute évidence, les dommages potentiels pour les clients étaient énormes, ainsi que les dommages causés à la société à temps partagé et à sa réputation.

Votre logiciel de sauvegarde doit offrir une flexibilité pour crypter les données en transit avant qu'elles ne soient envoyées sur un câble, ou au repos lorsque les données sont écrites sur le support de sauvegarde. Il doit utiliser des méthodes de cryptage librement disponibles et vérifiables. Vous devriez également avoir la possibilité d'utiliser différentes méthodes de cryptage et de profiter des nouveaux développements et des algorithmes de cryptage.

Il existe des solutions matérielles. La division Decru de Network Appliance et Neoscale proposent des appliances matérielles qui interceptent les écritures sur les supports de sauvegarde (bande) et les chiffrent à la volée. Cela présente l'avantage de la vitesse, mais entraîne un coût d'infrastructure élevé.

Amanda a la capacité de crypter les données soit sur le client, avant la transmission au serveur de sauvegarde, soit sur le serveur de sauvegarde lui-même. Le chiffrement côté client et côté serveur peut utiliser n'importe quel programme de chiffrement qui lit à partir de l'entrée standard et écrit sur la sortie standard. Cela inclut la commande aespipe, qui prend en charge diverses routines de chiffrement AES. Un autre outil couramment utilisé avec le programme de cryptage Amanda est gpg.

Bien entendu, sans une bonne gestion des clés, les données ne peuvent pas être récupérées. Amanda ne fournit pas de solution de gestion des clés en soi, mais travaille plutôt avec toute solution de gestion de clés mandatée par votre politique informatique.

L'ouverture et la flexibilité des options de chiffrement permettent à Amanda de bien s'intégrer aux politiques et processus de sécurité de la plupart des environnements informatiques, y compris les organisations ayant des exigences de sécurité strictes.

Qui contrôle vos sauvegardes et restaurations?

De nos jours, de nombreuses personnes doivent participer à la configuration et à l'utilisation des logiciels de sauvegarde et de restauration. Dans les grandes entreprises, il n'est pas rare que le personnel du service d'assistance s'adresse à des dizaines de personnes. Souvent, ces personnels doivent avoir une certaine autorité sur les opérations de récupération de données.

Il est judicieux de choisir un programme de sauvegarde qui vous permet de déléguer des pouvoirs à des individus, à condition qu'il offre un niveau de granularité fin. Si votre système de sauvegarde et de restauration n'a pas un niveau de granularité fin, vous êtes exposé à la possibilité d'abus de restauration. La plupart des packages de sauvegarde et de restauration ont le concept d'administrateurs. Ces administrateurs ont souvent des privilèges globaux et peuvent récupérer les données de n'importe qui. Cela peut inclure des données très sensibles, telles que la paie ou les dossiers financiers.

Entreprise Amanda adopte une meilleure approche. Il vous permet de créer des rôles pour chaque opérateur, en limitant les données auxquelles il a accès. Cela vous permet de séparer les données sensibles pour vous assurer que seuls ceux qui ont un besoin absolu de récupérer les données ont la possibilité de le faire.

Pouvez-vous sauvegarder via un pare-feu?

Les environnements de centre de données d'aujourd'hui incluent souvent l'utilisation de pare-feu, même en interne, pour protéger les ordinateurs de l'entreprise contre les attaques. Votre serveur de sauvegarde sera presque toujours derrière le pare-feu de votre entreprise. La question se pose - comment sauvegardez-vous ces ordinateurs de l'autre côté d'un pare-feu?

Une solution consiste à déployer un deuxième serveur de sauvegarde sur le côté approprié du pare-feu. Cependant, ce n'est pas toujours faisable ou souhaitable. Cela augmente les problèmes de sécurité, plutôt que de les réduire. Une meilleure solution est que votre client de sauvegarde et votre logiciel serveur utilisent des ports bien définis (mais modifiables) pour communiquer. Vous pouvez ensuite configurer votre pare-feu pour autoriser le trafic provenant d'adresses IP connues à travers le pare-feu pour permettre la sauvegarde et la restauration du trafic.

Une considération à propos de cette approche est le nombre de ports requis par le logiciel de sauvegarde. Votre logiciel de sauvegarde ne doit pas utiliser trop de ports, car il est déjà assez difficile d'ouvrir un ou deux ports dans votre pare-feu. Certains produits de sauvegarde à source fermée disponibles dans le commerce utilisent des dizaines de ports par serveur de sauvegarde.

Amanda a la possibilité d'utiliser quelques ports définis par l'administrateur avec lesquels le serveur de sauvegarde et le client peuvent communiquer. Cette capacité le rend bien adapté à la sauvegarde via un pare-feu.

Prise en charge des systèmes d'exploitation améliorés de sécurité tels que SE Linux

Security-Enhanced Linux (SELinux) est une variante Linux qui implémente une variété de politiques de sécurité, y compris des contrôles d'accès obligatoires de style US Department of Defense, via l'utilisation de modules de sécurité Linux (LSM) dans le noyau Linux. Depuis que Red Hat a introduit SELinux avec ses offres Enterprise, SELinux est maintenant largement utilisé dans les environnements gouvernementaux, militaires et souvent commerciaux. Aujourd'hui, aucun fournisseur de sauvegarde à source fermée ne prend en charge SELinux. Amanda, cependant, fonctionne très bien avec les politiques SELinux.

Votre logiciel de sauvegarde est-il conçu dans un souci de sécurité?

Le logiciel de sauvegarde contient des fichiers de configuration qui stockent les mots de passe et les droits de contrôle d'accès non seulement pour les serveurs de fichiers, mais également pour les serveurs d'applications et de bases de données. Assurez-vous que ces fichiers de configuration ne sont lisibles que par les utilisateurs autorisés.

Quiconque utilise un logiciel à source fermée ne peut que deviner ce qu'il contient. Étant donné que le fournisseur ne rend pas le code disponible pour inspection, il est très difficile de dire si le logiciel est totalement sécurisé ou s'il existe des «portes dérobées» codées dans le logiciel, comme la fameuse porte dérobée découverte dans les serveurs Microsoft IIS en 2000.

L'équipe de préparation aux urgences informatiques des États-Unis (US-CERT) émet en permanence des alertes de vulnérabilité pour les logiciels de sauvegarde commerciaux. Par exemple, la Vulnerability Note VU # 744137 alerte que dans Symantec Veritas NetBackup logiciel le démon de catalogue contient un débordement de tampon basé sur la pile qui pourrait permettre à un attaquant distant d'exécuter du code arbitraire sur un serveur maître NetBackup.

L'open source, en revanche, est presque insensible à ce genre de problème. Il existe un mécanisme intégré d'examen par les pairs du code qui garantit pratiquement que rien de ce qui n'est pas nécessaire n'est inclus. Aucun développeur Open Source qui se respecte ne risquerait sa réputation et sa carrière en mettant une porte dérobée à un produit open source. Même si une telle porte dérobée était incluse, elle serait probablement rapidement retrouvée et supprimée.

De plus, les logiciels open source peuvent être facilement inspectés pour la qualité et la sécurité. Il existe des outils open source commerciaux et disponibles gratuitement pour analyser le code logiciel des vulnérabilités de sécurité. Certains d'entre eux sont:

Ces outils sont disponibles gratuitement et capables de scanner une variété de langages de programmation. Bogosec (http://bogosec.sourceforge.net/index.html) est un wrapper autour de ces outils, et peut prédire les problèmes de sécurité dans les logiciels. Cependant, sans code source disponible pour le logiciel de sauvegarde, ces outils sont inutiles.

En ce qui concerne la sécurité des informations, ce sont des préoccupations très réelles pour tout paquet de sauvegarde. Lors de la sélection d'un package de sauvegarde, vous devez vous assurer qu'il n'y a aucune faille de sécurité connue dans le logiciel. Amanda, le principal package de sauvegarde open source, a été testé avec une variété d'outils et par plusieurs organisations. Par exemple, Coverity (http://scan.coverity.com), un effort de collaboration entre l'Université de Stanford et la communauté open source, a testé la qualité du code Amanda. Lorsque des bogues ont été découverts, la communauté Amanda les a rapidement corrigés et réduit le nombre à zéro. Cela se compare à un taux de défaut moyen de 20 à 30 bogues par 1000 lignes de code pour les logiciels commerciaux, selon le CyLab Sustainable Computing Consortium de l'Université Carnegie Mellon.