Découvrez notre société Contactez-nous

e-Xpert Solutions Genève

109, chemin du Pont-Du-Centenaire
CH-1228 Plan-les-Ouates / Genève
SUISSE

Tel. : +41 22 727 05 55 Fax : +41 22 727 05 50

e-Xpert Solutions Lausanne

Avenue de Gratta-Paille 20
CH-1018 Lausanne
SUISSE

Tel. : +41 21 802 26 78 Fax : +41 22 727 05 50
Contactez notre support : +41 22 727 05 56
En cochant cette case, vous acceptez notre politique de confidentialité disponible en cliquant ici
Envoyez votre message

Swiss Security Hackademy

Suivez notre blog bilingue en sécurité informatique !

Retour aux articles

Créer un workflow de validation de demandes de changement

Use-Case e-Xpert Solutions Analytics Tool for F5


Auteur : Gilliek

Date de publication : 22 décembre 2021 - Dernière mise à jour : 22 décembre 2021


Le scénario présenté ci-dessous fourni aux utilisateurs standards la possibilité de demander la création d’objets sur des équipements F5. Le ou les administrateur(s) peuvent alors valider la demande et l’accepter ou la refuser en ajoutant la raison du choix. De plus, si cette dernière est acceptée, l’objet sera alors créé sur F5.

Cet exemple à pour but de rester simple, mais il est bien entendu possible de le pousser bien plus loin. Lors d’une implémentation dans un environnement réel, il serait par exemple intéressant d’offrir aux utilisateurs un formulaire simplifié afin d’abstraire au maximum les détails de fonctionnement du F5. Pourquoi pas raisonner en termes d’application plutôt que de virtual server ? Et plutôt que de sélectionner le FQDN du F5 sur lequel déployer l’objet, sa zone (DMZ, …) ?

Il est également important de noter que dans cet exemple nous allons démontrer ce use-case sur des virtual servers, mais cela peut fonctionner sur n’importe quel type d’objet.

Pour implémenter ce use-case, nous allons utiliser la solution que nous avons développé en interne « Analytics Tool for F5 ».

Comment ça fonctionne ?

Le schéma ci-dessous décrit comment le use-case va fonctionner :

Nous avons ici 2 acteurs : un utilisateur et un administrateur. L’utilisateur se connecte sur la solution et accède au dashboard pour soumettre de nouvelles demandes.

Ce dashboard lui est personnel, il n’a donc accès qu’à ses propres demandes. L’utilisateur remplit un formulaire de demande de création d’objet depuis le dashboard directement en cliquant sur le bouton « + REQUEST » :

La demande est alors enregistrée dans une base de données locale. Un log d’audit est ensuite créé et 2 notifications sont envoyées : La première à l’utilisateur, pour confirmer que la demande a bien été enregistrée. La seconde à l’administrateur pour l’inviter à valider la demande.


L’administrateur reçoit donc l’email et accède à son dashboard administrateur où il voit toutes les demandes ainsi que leur statut.

Il voit alors la nouvelle demande et peut la valider.

Il a le choix d’accepter ou de refuser la demande. Le statut va alors être mis à jour dans la base de données locale puis un log d’audit va être généré. Si la demande est acceptée, l’objet va être créé sur le F5. Des emails de notifications vont alors être envoyés à l’utilisateur et à l’administrateur.

« Behind the scenes »

Au niveau de notre produit, les objets suivants ont dû être créés pour mettre en place ce workflow :

Index

Un index a été créé pour stocker les logs d’audit générés. Cela permet de rechercher facilement toutes les actions qui ont été faites, par qui, à quelle heure, etc.

Cet index pourrait être exploité pour faire un dashboard.

Wizards

Il nous a fallu créer 2 « wizards ». Le premier pour que l’utilisateur puisse soumettre la demande. Ce wizard a un iscript attaché qui va se charger de valider les paramètres fournis par l’utilisateur, d’enregistrer la demande dans la base de données locale puis de créer le log d’audit correspondant. Le second pour que l’administrateur puisse valider la requête de l’utilisateur. Ce wizard récupère la demande de l’utilisateur et l’affiche à l’administrateur ainsi que des options supplémentaires pour accepter/refuser la demande. Il a également un iscript attaché afin de pouvoir mettre à jour l’entrée dans la base de données locale et générer un log d’audit local.

Workflows

On a aussi besoin d’un workflow qui reçoit en temps réel chaque log d’audit :

L’idée de ce workflow est de trapper les logs d’audit, et en fonction du type d’action (request, approved ou denied) envoyer un email de notification à l’utilisateur et à l’administrateur.

Par exemple, un nœud conditionnel ressemble à ça :

Et un template d'email:

Dashboards

Finalement, on a besoin de 2 dashboards. Le premier pour l’utilisateur, qui n’affichera que les demandes de l’utilisateur courant en utilisant les informations de l’utilisateur connecté pour filtrer les informations affichées. Ce dashboard fournit un bouton qui déclenche le wizard créé précédemment afin que l’utilisateur puisse soumettre sa demande. Le second pour l’administrateur afin d’afficher la liste de toutes le demandes (en cours et passées) avec leur statut. De plus, il fournit un menu pour chaque demande et qui déclenche le wizard correspondant afin que l’administrateur puisse valider la demande.

Pour conclure

Nous avons vu qu’il était possible de créer depuis notre solution tout un workflow pour gérer la validation de demandes de création d’objets F5 par des utilisateurs ainsi que d’automatiser la création desdits objets.

Pour plus d’information concernant ce use-case et sa mise-à-place, n’hésitez par à nous contacter via le formulaire de contact sur notre site web ou via notre support.

Pensez aussi à consulter nos autres use-cases pour la solution « Analytics Tool for F5 »