PROJET – Green Ray, VEEAM Reporting Partie 1 : Théorie

Expression du besoin

Commençons par le début… J’ai eu le besoin professionnel d’extraire des indicateurs liés à la sauvegarde et tous ce qui touche de près ou de loin à la protection des données du SI¹. Jusque-là pas de problème, étant encore une fois sensibiliser comme il se doit à ITIL² les indicateurs de performance ça me connait.

Mais y a-t-il un outil pour répondre à ce besoin ? Bien sûr il y a une pelle d’outil sur le marché et dans les solutions de protection ils sont déjà présents. Erreur Grave ! Oui des métriques sont présentes mais il vous faudra un peu d’huile de coude pour les exploiter.

Une petite démonstration s’impose, voyons plutôt le cas suivant. Je suis chef d’entreprise et mon prestataire externe gérant mon informatique me garantit un taux de disponibilité de la sauvegarde de 99% (ou mon RSSI³ interne ayant définit dans la PSSI⁴ le même taux de disponibilité auprès des équipes opérationnelles).

Que se passe-t-il si nous demandions au prestataire ou l’équipe opérationnelle en interne de nous prouver que le taux de disponibilité est bien respecté ?

Deux réponses possibles :

• Honnête : Nous n’avons pas la capacité de vous fournir la métrique, mais nous vous assurons que tout est en ordre, nous pouvons vous mettre en copie des rapports des jobs de protection
• Malhonnête : Voici les chiffres tout est fonctionnel, mais nous ne pouvons pas vous communiquer avec précision le détail. Nous reviendrons vers vous sans faute.

Bien malheureusement le dernier cas est la réponse la plus commune est il n’y aura pas de retour. Néanmoins il y a aussi des poissons volants mais qui ne constituent pas la majorité du genre 😊

Donc il nous faut une solution qui nous permet un suivie Job par Job, journalier, hebdomadaire, mensuelle et annuelle et si possible orientée client final ou MSP⁵. Décorréler de la production et exploitable par le service qualité pour présenter des jolies métriques avec la plus grande transparence et honnêteté qu’il soit.

Cahier des Charges

L’expression du besoin étant je le pense bien poser, il faut maintenant réfléchir à comment mettre en œuvre cela sans pour autant se disperser et manger la feuille. Ce qui est je crois l’objectif d’un cahier des charges non ? Bien que dans les faits, mon esprit versatile sur le projet aura tout de même fait des siennes.

Il est indéniable que nous resterons sur les produits distribués par VEEAM et ces diverses API⁶. J’exclu volontairement pour l’instant un usage direct au produits VBR et souhaite utiliser la VSPC.

Ce choix est motivé par l’aspect de contrôle de l’ensemble de TOUS les types de sauvegardes, c’est-à-dire VBR⁷ et VB MO365⁸. De plus il permet de répondre aux deux problématiques d’un usage final ou MSP.

Mais pourquoi VEEAM ? VEEAM et le leader du marché et rare sont les sociétés qui n’utilise pas la solution.

Résumons donc, le produit devra être connectable à la VSPC⁹ via son API. Il convient donc de définir quel langage nous souhaitons utiliser ? Je choisie le Framework .Net avec powershell afin d’établir un mode manuel et un mode service. Certes pas esthétique mais avons-nous réellement besoin d’une interface GUI¹⁰ pour l’instant ? Naturellement, il est obligatoire que la solution laisse une trace de son exécution dans un fichier et ce à des fins de debug et de contrôle.

L’outil comportant un mode service, ce dernier doit être planifié de manière journalière pour traiter le point de suivi des métriques sur une durée donnée.

Les données seront stockées dans une base de données flexible et légère qui puisse être utilisé en dehors de la production et s’interfacer rapidement avec tous types de systèmes. Je propose d’utiliser SQLite3.

Concernant la partie exploitation et génération des métriques, j’ai pris parti d’utiliser PowerPI pour des raisons de praticité et de gain de temps. Toutefois, les données étant stockées dans une BDD¹¹, nous pourrions interfacer cette dernière à travers Excel (BOOOOUUUUUUUHHHH) ou à travers un site web type front/back.

Et là sécurité ? Afin d’assurer une sécurité la plus haute possible, le compte qui sera utilisé à communiquer avec l’API VEEAM doit être en lecture seule. Il n’y a aucun intérêt à réaliser des requêtes de type CREATE, UPDATE ou DELETE. Quant à l’exécution de la tâche planifiée dédiée au mode service un compte gMSA¹² répondra à toutes les problématiques.

En conclusion de notre liste de course, notre application utilisera :

• Connecteur API à la console VSPC
  • Orienté MSP et SI finaux
  • Couvrir les produits VBR et VB MO365
  • Suivre les licences
• Langage de développement & Fonctionnalités
  • .NET Framwork à travers Powershell (v5)
  • Journalisation de l’exécution du code
  • Export des données en CSV
  • Mode manuel et mode service
  • Fichier de configuration
  • Aide au déploiement

• SGBD
  • SQLite3
• Reporting
  • Microsoft PowerBI
• Sécurité
  • Si poste au domaine, création et utilisation d’un compte de service gMSA dédiéSi hors domaine, création d’un compte restreint au poste
  • Token API en lecture seule sur la console VSPC

Il est temps de passer à la construction et définissions de nos différents niveaux de topographie d’architecture, applicative et logiciel.

Topographie – Infrastructure

La topographie est plutôt simple car j’ai fait le souhait que tout soit embarqué avec l’application. Donc il n’y a qu’à ouvrir le flux inbound de notre serveur VSPC console sur le port tcp/1280 (sauf si vous l’avez changé naturellement).

Topographie – Applicative

Je ne suis pas architecte d’application, bien que de ma formation de jadis il me reste certaines bases. J’ai donc structuré le répertoire source en plusieurs sous répertoire du mois dans la v2.

A la racine du répertoire, nous retrouvons les deux fichiers exécutables :

• SS_34_2.0.0_VEEAM-Backup-Reporting_Main.ps1 : Qui est le fichier d’instanciation de la solution est qui permet également de réaliser certaines actions en mode manuel.
• SS_34_1.0.0_VEEAM-Backup-Reporting_Services.ps1 : Presque le même fichier que le fichier Main mais dédié au mode service avec un code adapté. Il ne peut être exécuté si et seulement si l’instanciation et initialisation à eu lieu.

La suite se déroule en 6 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de trois dissociant la partie BDD, Windows et VEEAM VSPC.
• Database : Répertoire contenant la BDD qui va stocker les données. La SGBD¹³ étant sous SQLite il n’y a pas besoin de moteur SQLite. Seul le module SQLite pour powershell est nécessaire en termes de dépendance. La base de données est automatiquement générée si cette dernière n’est pas présente ou si cette dernière à un nom qui diffère du fichier de configuration. Uniquement lors de l’exécution du script en mode manuel.
• Config : Répertoire contenant le fichier de configuration powershell. Effectivement depuis des années je faisais ça directement dans le code… Je mourrai moins con ce soir comme dirait quelqu’un que je connais bien 🙂 Je reviendrai plus en détail sur la partie 2 sur le contenu de ce fichier. Afin de palier à toute suppression malencontreuse du fichier de configuration, j’ai développé une fonction pour regénérer ce dernier. Oui je suis adepte du Alt+Maj+Del et j’ai dû recommencer mon fichier. Maintenant plus de problème avec mon combo favori <3
• Report : Là où je stocke les fichiers Microsoft PowerBI. Je reviendrais sur ce point dans la partie 2.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa baignoire de corriger les bugs. Le fichier ne prend pas de place et est réinitialiser à chaque lancement.
• Export : Répertoire qui est une fonctionnalité legacy de la v1 de 2023. Bien que pas reprise pour l’instant elle accueille normalement dans une structure définit les données sous la forme de fichiers CSV sur une fréquence journalière, puis compile ces derniers selon l’échelle temporelle définit hebdomadaire, mensuelle et annuelle. Je ne vois pas l’utilité de reprendre cette dernière pour l’instant.

Il est important de noter que le script manuel et le script de service peuvent être dissocier. Ce qui se traduit dans un sens par je peux utiliser un serveur en mode type console avec l’outil manuel et garder l’automatisation sur un serveur avec uniquement le strict nécessaire.

Topographie – Logiciel

Le code reste je le pense à optimiser. Mais ce dernier est pour moi un bon candidat à la version béta stable. Pourquoi béta ? Parce que certaines fonctionnalités ne sont peut être pas adapté à tous les usages encore.

Attention, sortez les violons

Ce n’est pas évident tous les soirs d’enquiller une nouvelle journée de travail de 21h00 à 01h00/02h00 du matin. J’ai actuellement le sentiment du type qui est à table, qui n’a plus faim mais qui se force à manger… T’es c** ou quoi ? C’est toi qui t’infflige ça t’es au courant mec ? Oui, mais c’est aussi un plaisir de maintenir le blog, de partager et surtout je veux aller au bout de ce projet pour ne pas faire comme d’autres dont les blocs prennent la poussière dans un quoi de mon disque dur (ou du CLOUD). Bref, certaines fonctionnalités j’ai eu la flemme de faire propre ou de tester plus en profondeur.

Ranger les violons

Dans son fonctionnement, nous pourrions voir le fonctionnement suivant :

• 0 : Contrôle et vérification des prérequis. Pour simplifier la chose, lecture du fichier de configuration vérification de la BDD et tout le toutim. Et dans une certaine mesure, création de la tâche planifiée.
• 1 : Appel API vers la serveur console VSPC afin d’extraire, les données VBR, VB MO365 ainsi que les données administratives
• 2 : Traitement des données retournée par l’API afin de stocker ces dernières dans la SGBD, naturellement si l’option est activée l’ensemble des sorties consoles sont redirigées dans un fichier de log
• 3 : Une fois le modèle en place de reporting (PowerBI) configuré (comprendre faire les jointures dans l’application), rafraichir les données
• 4 : Modifier les filtres et exploiter l’application.

Je ne présente pas pour l’instant les différents bouts de code. Deux raisons à cela. La première étant que cela rendra l’article imbuvable. La seconde, je ne souhaite pas pour l’instant s’évaporer les fruits de mes travaux si versatiles soient ils. Je suis toujours néanmoins en réflexion pour ouvrir le projet à une communauté.

Sécurité

La sécurité quitte à réchauffer des propos déjà écris précédemment dans d’autres articles relève d’angles majeurs que nous ne pouvons ignorer de nos jours. Je ne vois qu’au moment de la rédaction de cette article deux points à améliorer concernant la VSPC et la SGBD.

SGBD

La partie SGBD, tout reste à faire. La première approche reste toujours la traditionnelle question :

Est ce que c’est/était légal ?

Si la fameuse réplique du film est « Absolument pas« , ma réponse sera « Carrément« . Il n’y a pas de données à caractère personnelle ou sensible et donc reste conforme avec la législation en vigueur avec la RGPD¹⁴.

Ouai mais là tu parles de ta BDD et de son contenu. Quel rapport avec la sécurité de la base ?

Question légitime pour laquelle je répondrai en affirmant que le contenu du BDD, peu importe la SGBD doit être sécurisé et répondre aux lois garantissant la sécurité de ces dernières. Toutefois et c’est dans ce sens que commençait cet article, je n’ai mis aucun mécanisme de sécurité sur ma base de données.

Cette dernière n’est pas chiffrée (pour quoi faire ?), les données ne sont critiques et en cas d’exfiltration elles ne représentent pas un risque. Si ce n’est peut-être des ID¹⁵ uniques ? Il n’y a pas de compte d’accès. Après on reste sur du SQLite, mais nous pourrions envisager d’implémenter cela par la suite et également penser à développer d’autres plugins pour d’autres SGBDs SQL.

Une sécurité de base, serait de paramétrer les ACLs afin que le fichier de BDD ne soit accessible que du compte de service et des comptes utilisateurs habilités à lancer l’application en manuel.

Et sinon tu nous présentes le MCD ?

Non. Le MCD¹⁶ a commencé sur papier. Puis j’ai essayé de me souvenir des bonnes pratiques acquises il y a longtemps durant mon BTS Indus avec Merise (et non Guillaume MEURICE… Ahahahahah Nul ta blague !). Puis j’ai vite compris que cela serait :

• Imbitable
• N’apporterai pas de valeur ajoutée si ce n’est alourdir et rendre indigeste l’article

Si je partage le code, naturellement que je renseignerai dernier. Mais bon, ne nous mentons pas. Si je fournis le code est que la BDD est générée. De facto, un petit coup de SQLite Browser et le tour est joué… La structure n’est pas vraiment complexe (28 tables au total…).

VSPC

Dans la VSPC, j’ai pris le parti de générer un compte API mais en lecture seul uniquement pour le compte Administrateur.

Pour bien faire, il ne faudrait pas utiliser le compte Administrateur local, mais un compte utilisateur. Secondo, l’application ne fait que de la lecture de données à travers les méthodes GET de l’API de la VSPC. Donc comme il n’y a pas de volonté de modifier les ressources jointent à la plateforme VSPC, le paramètre lecture seul suffit parfaitement.

En plus en termes de sécurité, serait de définir la clé d’API en dehors du fichier de configuration et de chiffrer ce dernier avec les news WAPI¹⁷ dans un fichier XML¹⁸. Oui oui, c’est le retour du fichier CLIXML 🙂 M’enfin, je me dis que le risque est maitrisé.

Ah ouai ? Et sur quels critères c’est maitrisé ?

Sur mon avis arbitraire et totalitaire M’sieur le Juge et je vous attends avec une bonne droite évangélique (ou plutôt de gifle et j’en suis pas mort…). Plus sérieusement, si sur mon serveur qui exécute les scripts et compromis, c’est que je me suis fait péter mon SI et tous les mécanismes de sécurité en place… Donc si nous sommes réalistes, quand le vers est dans le fruit il ne faut pas trop s’inquiéter pour la peau mais plus pour le noyau de notre fruit. Ce que je cherche à dire, c’est que le pirate, l’individu malveillant que dis-je ce malotru ! Ce n’est pas mon script qui va l’intéresser, mais plutôt de continuer à se déplacer latéralement dans mon SI est TOUT exploser. Dans ces circonstances là, je pense que je peux dire que le risque est maitrisé et il existe tout de même des gardes fous et d’autres mécanismes.

Taches Planifiées

Dans le cadre du mode service, selon l’approche et le contexte la sécurisation de ce dernier est variable.

Le premier point concerne l’environnement, le poste qui va exécuter le script est il au domaine ou non ?

Le second point étant relatif au secret. Devons nous chiffrer, déchiffrer des informations sensibles ?

Dans le cadre d’un environnement hors domaine, il conviendra de créer un compte utilisateur dédié avec les droits nécessaire pour assurer la sécurité. Néanmoins et lors de la création de la tâche, il conviendra de préciser le mot de passe ainsi que le compte local. Ce qui n’est pas ouf en termes de MCO¹⁹. Mais c’est aujourd’hui l’une des méthodes que j’affectionne si le serveur est hors domaine.

A l’inverse, si l’environnement est lié à un domaine, l’approche est différente et j’ai pour le coup changer mon fusil d’épaule (va t’il passer l’arme à gauche ?). Je suis devenu un convaincu des groupes de compte de services administrés (gMSA) dans une certaine mesure. Après réflexion sur mon infrastructure ainsi que les 43 types de scripts développés, je me suis dit qu’il n’était pas déconnant de définir un serveur de script dédiée à des tâches planifiées.

De ce fait, je n’installe pas sur tout les serveurs les RSATs²⁰ ActiveDirectory et la rotation de mes mots de passe est périodique sans avoir à repasser, modifier les taches à chaque fois. C’est cool non ?

Il subsiste toutefois une petite pirouette si nous venions à utiliser les fonctions de chiffrement windows pour encoder et décoder une information. La création de la tâche nécessitera une configuration manuelle pour assurer le chiffrement.

Dépendances

Il est difficile de pas parler des prérequis tiers nécessaires au bon fonctionnement de l’application. Oui, j’ai du faire appel à des outils développer par d’autres personnes/organisations.

• Connecteur .Net Powershell – VSPC : L’ensemble des méthodes sont natives au framework .NET. La connexion se fait à travers l’API de la VSPC à partir de la documentation disponible sur le site de VEEAM. Rien à faire, si ce n’est ouvrir le port qui va bien.
• Interface .Net Powershell – SQLite : Pour communiquer avec une base de données SQLite, j’ai installé le plugin powershell PSSQLite depuis le repo officiel.
• Connecteur MS PowerBI et SQLite : Il me manquait les drivers ODBC, j’ai donc du télécharger et installer ces derniers afin d’assurer la connexion entre l’application PowerBI et la BDD SQLite (lien).

Et c’est tout. Rien de plus, rien de moins.

Avec toute la théorie, je pense que nous pouvons maintenant aborder la seconde partie pratique qui n’est rien d’autre que le guide d’installation et de configuration de l’application développée.

PROJET – Green Ray

Partie 2 : Pratique —>

1. SI : Système d’Information ↩︎
2. ITIL : Information Technology Infrastructure Library ↩︎
3. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
4. PSSI : Politique de Sécurité des Systèmes d’Informations ↩︎
5. MSP : Managed Services Provider ↩︎
6. API : Application Programing Interface ↩︎
7. VBR : VEEAM Backup et Réplication ↩︎
8. VB MO365 : VEEAM Backup for Microsoft Office365 ↩︎
9. VSPC : VEEAM Service Provider Console ↩︎
10. GUI : Graphical User Interface ↩︎
11. BDD : Base De Données ↩︎
12. gMSA : Groupe Managed Service Account ↩︎
13. SGBD : Système de Gestion des Bases de Données ↩︎
14. RGPD : Règlement Général sur la Protection des Données ↩︎
15. ID : IDentité ↩︎
16. MCD : Modèle Conceptuel de Données ↩︎
17. WAPI : Windows ↩︎
18. XML : Extensible Markup Language ↩︎
19. MCO : Maintient en Condition Opérationnel ↩︎
20. RSATs : Remote System Administration Tools ↩︎