Articles Tagués ‘OS Hardening’

Avant de déployer vos serveurs Windows Server 2016, je vous invite à consulter la Checklist ci-dessous.

Celle-ci contient + de 70 paramètres de sécurité & hardening Windows vous permettant de mieux protéger et sécuriser vos plateformes Windows Server 2016.

Note : 90% des paramètres /options listés ci-après d’applique également à Windows Server 2012 R2/2012 mais aussi 2008 R2/2008.

 

Informations techniques
Nom du serveur  
Adresse MAC
Adresse IP
Masque de sous-réseau
Passerelle par défaut
Serveur DNS #1
Serveur DNS #2
Compte Administrateur local
VM (Oui /Non) Si Physique, Asset TAG :
RAM
CPU
Nombre de Disques /vDisques
Configuration RAID
LAN /VLAN
Date
Checklist
Etape Action Statut Commentaire
  Préparation & Installation
1 Si nouvelle installation, isoler le serveur du réseau jusqu’à ce qu’il soit protégé et sécurisé (voir sections suivantes)
2 Utiliser l’Assistant Configuration de la Sécurité (SCW : Security Configuration Wizard) pour créer et configurer une stratégie de sécurité à appliquer sur le serveur.
  Services Packs & Correctifs
3 Installer les derniers Services Packs et correctifs depuis Microsoft Windows Update (ou WSUS : Windows Server Update Services)
4 Configurer les notifications automatiques de la disponibilité des mises à jour et correctifs
  Stratégies de comptes utilisateurs
5 Définir une longueur minimale du mot de passe
6 Définir les exigences de complexité du mot de passe
7 Ne pas enregistrer les mots de passe en utilisant un chiffrement réversible
8 Définir un seuil et une durée de verrouillage des comptes
  Attribution des droits utilisateurs
9 Autoriser l’accès au serveur à partir du réseau aux administrateurs et aux utilisateurs authentifiés uniquement
10 Ne pas attribuer le droit « Agir en tant que partie du système d’exploitation » aux utilisateurs standards
11 Autoriser l’ouverture de session locale aux Administrateurs uniquement
12 Refuser le droit « Ouvrir une session en tant que Service » aux utilisateurs invités, et ce localement ou à distance via Connexion Bureau à distance.
Paramètres de sécurité
13 Configurer un message d’avertissement à afficher lors de la tentative d’ouverture de Session. Celui-ci doit indiquer que l’accès au serveur est réservé aux personnes habilitées.
14 Ne pas autoriser les utilisateurs du réseau à créer et ouvrir une session à l’aide d’un compte Microsoft
15 Désactiver le compte « Invité »
16 Requérir la combinaison de touches Ctrl+Alt+Suppr pour les ouvertures de session interactives
17 Configurer la limite d’inactivité du serveur pour protéger les sessions interactives
18 Configurer le Client réseau Microsoft pour signer les communications numériquement (toujours)
19 Configurer le Client réseau Microsoft pour signer les communications numériquement (lorsque le serveur l’accepte)
20 Configurer le Serveur réseau Microsoft pour signer les communications numériquement (toujours)
21 Configurer le Serveur réseau Microsoft pour signer les communications numériquement (lorsque les clients l’acceptent)
22 Désactiver l’envoi de mots de passe non chiffrés à des serveurs SMB tiers
  Paramètres des journaux d’événements
23 Configurer une Taille maximale des journaux d’événements
24 Configurer une Méthode de conversation des journaux d’événements
25 Configurer une Durée de stockage des journaux d’événements
26 Configurer l’envoi de journaux
  Contrôles d’Accès au réseau
27 Désactiver la traduction de noms/SID anonymes
28 Ne pas autoriser l’énumération anonyme des comptes SAM et partages réseau
29 Ne pas attribuer et appliquer de permissions « Tout le monde » aux utilisateurs anonymes
30 Ne pas autoriser les canaux nommés qui sont accessibles de manière anonyme
31 Restreindre l’accès anonyme aux canaux nommés et partages
32 Ne pas autoriser l’accès aux partages réseau de manière anonyme
33 Requérir le partage « Classique » et Modèle de sécurité pour les comptes locaux
  Paramètres de Sécurité : Réseau
34 Autoriser « Système Local » à utiliser l’identité de l’ordinateur pour NTLM
35 Désactiver le recours session Local système NULL
36 Configurer les types de cryptage autorisés pour Kerberos
37 Ne pas stocker de valeurs de hachage de niveau LAN Manager
38 Configurer le niveau d’authentification LAN Manager pour autoriser NTLMv2 et refuser LM & NTLM
39 Activer le Pare-feu Windows sur les trois profils : Domaine – Privé – Public
40 Configurer le Pare-feu Windows pour bloquer tout traffic entrant sur les trois profils
  Paramètres de Sécurité : Connexions Bureau à distance
41 Activer l’authentification au niveau du réseau (NLA : Network Level Authentication)
42 Utiliser le niveau de chiffrement « Elevé » afin de protéger les données RDP à l’aide d’un chiffrement renforcé sur 128 bits
43 Configurer un certificat SSL sur le serveur et forcer l’utilisation de la couche de sécurité « SSL »
44 Toujours demander le mot de passe à la connexion
45 Configurer une Passerelle RDS pour gérer les accès depuis l’extérieur.
46 Si possible, forcer l’utilisation de l’authentification forte (e.i carte à puce)
47 Activer la fonctionnalité « Remote CredentialGuard »
  Paramètres de Sécurité : Serveur Membre du domaine AD
48 Chiffrer ou signer numériquement les données des canaux sécurisés (toujours)
49 Chiffrer numériquement les données des canaux sécurisés (lorsque cela est possible)
50 Signer numériquement les données des canaux sécurisés (lorsque cela est possible)
51 Exiger les clés de sessions fortes (Windows 2000 ou ultérieur)
52 Configurer le nombre de demandes d’ouverture de session précédentes à mettre en cache
  Paramètres de Stratégies d’Audit
53 Auditer les événements d’ouverture de session sur un compte
54 Auditer la gestion des comptes utilisateur
55 Auditer les ouvertures et fermetures de sessions
56 Auditer les changements de stratégie
57 Auditer l’utilisation des privilèges
  Paramètres de sécurité : OS
58 Si possible, convertir le serveur en mode « Core »
59 Désinstaller ou désactiver les services non utilisés
60 Désinstaller ou supprimer (binaires) tous les rôles et fonctionnalités non utilisés
61 Fermer tous les ports non utilisés
62 Supprimer ou désactiver les comptes utilisateurs non utilisés
63 Restreindre au maximum les droits aux utilisateurs du réseau
64 Vérifier que tous les volumes utilisent le système de fichier « NTFS »
65 Configurer les permissions au niveau du Registre
66 Si possible, désactiver l’accès distant au Registre
67 Installer et activer un anti-virus & anti-spyware
68 Configurer l’anti-virus & anti-spyware pour se mettre à jour automatiquement
69 Configurer la date & heure système, synchroniser ensuite l’horloge avec un serveur de temps (Serveur NTP : Network Time Protocol)
70 Si possible, activer le chiffrement de lecteur BitLocker
  Sécurité Physique
71 Protéger l’accès au BIOS à l’aide d’un mot de passe
72 Protéger l’accès aux consoles de gestion (e.i console iLO) à l’aide d’un mot de passe
73 Ne pas autoriser l’arrêt du système sans avoir ouvert de session Windows
74 Configurer l’ordre de boot pour éviter tout démarrage d’un média non autorisé
75 Configurer un écran de veille pour verrouiller l’écran (affichage) après un certain temps d’inactivité
  Informations additionnelles
76 Utiliser l’outil MBSA (Microsoft Baseline Security Analyzer) pour analyser et auditer la sécurité de votre serveur

 

Télécharger ce document (format PDF)

Cette Checklist est disponible (format PDF) en téléchargement gratuit depuis la Gallery TechNet.

Vous pouvez download le document ici.

Bonne lecture.

Vos feedbacks sont les bienvenus :).

#HK

S’applique à : AppLocker 2012 et 2012 R2

Note : Si vous n’avez pas encore découvert la fonctionnalité « Applocker » et son fonctionnement sous Windows Server 2012 R2, je vous invite à consulter cet article :

[PART1] Introduction à AppLocker sous Windows Server 2012 R2

Introduction

Windows PowerShell est l’interpréteur de commandes qui vous simplifie la vie :), en effet, si vous êtes amenés à implémenter, tester et gérer des Règles de restrictions logicielles via AppLocker 2012 ou 2012 R2, sachez que Windows PowerShell peut vous aider à accélérer le processus d’implémentation des Stratégies Applocker.

Depuis Windows Server 2008 R2, Microsoft a introduit un nouveau Module PowerShell qui vous permet de créer, tester et gérer les Stratégies AppLocker, il s’agit du Module « Applocker ».

Ce dernier regroupe cinq Cmd-lets, saisissez Get-Command -Module AppLocker depuis une console Windows PowerShell pour en savoir plus :

AppLocker_1

Le tableau ci-après détaille plus d’informations sur chaque Cmd-let :

Cmd-let Description
Get-AppLockerFileInformation Permet de collecter des informations nécessaires pour AppLocker, et ce à partir d’un répertoire spécifique ou des Journaux d’événements.

Les informations collectées peuvent inclure des informations sur l’éditeur, Hash ou encore chemin d’accès aux fichiers

Set-AppLockerPolicy Permet de configurer et lier une Stratégie AppLocker à une GPO
Get-AppLockerPolicy Permet de lister les Stratégies AppLocker à partir d’une GPO Locale, du Domaine ou effective
New-AppLockerPolicy Utilise les informations collectées (via la Cmd-let Get-AppLockerFileInformation) pour générer automatiquement une Règle pour un utilisateur ou un groupe d’utilisateurs spécifique. Les règles générées peuvent être basées sur l’éditeur, Hash ou chemin d’accès.
Test-AppLockerPolicy Utilise une Stratégie AppLocker spécifique pour tester si un fichier ou une liste de fichiers est autorisée à s’exécuter sur la machine locale, et ce pour un utilisateur donné
Créez vos Règles AppLocker

Avant de pouvoir créer vos Règles de restrictions logicielles, AppLocker a besoin d’analyser et collecter certaines informations sur les Apps /Programmes dont l’exécution doit être autorisée ou restreinte.

Pour ce faire, la Cmd-let « Get-AppLockerFileInformation » doit être utilisée, dans l’exemple suivant, elle sera utilisée pour scanner le dossier C:\Sources afin de collecter les informations sur le Hash, Editeur … sur les exécutables /scripts /Libraries DLL qui y sont stockés

1

Note : le paramètre -Recurse est utilisé pour prendre en compte les sous-dossiers et fichiers du Dossier spécifié au niveau du paramètre -Directory.

La commande peut être suivie de « | Out-GridView » pour une meilleure visibilité des données collectées et retournées par la Cmd-let Get-AppLockerFileInformation

2

Comme illustré dans l’image ci-dessus, la Cmd-let Get-AppLockerFileInformation ne remonte aucune information sur l’éditeur « Publisher » concernant les deux .EXE (CA_SETUP.exe & ASE_SETUP_FINAL.exe).

Cette information est à prendre en compte lors de la création des Règles AppLocker.

Nous allons donc créer une nouvelle Règle AppLocker basée uniquement sur le Path ou Hash ou les deux pour autoriser les exécutables du dossier C:\Sources.

Une technique de création « Rapide » des Règles AppLocker existe, il s’agit de « piper » le résultat retourné par la Cmd-let Get-AppLockerFileInformation, et le passer à la Cmd-let « New-AppLockerPolicy »

Comment ça marche ?

Tout d’abord, les trois informations suivantes sont à renseignées  :

  • Type de règle (paramètre -RuleType) : Path et/ou Publisher et/ou Hash
  • Utilisateur ou Groupe d’utilisateurs (paramètre -User) : Utilisateur ou Groupe d’utilisateurs (locaux ou d’un domaine AD)
  • Nom de la règle (paramètre -RuleNamePrefix)

Dans l’exemple suivant, nous allons créer une règle AppLocker (nommée DevApps) pour autoriser l’exécution des Apps placées dans le dossier C:\Sources en se basant sur leur Hash, et ce uniquement pour le groupe d’utilisateurs AD « UtilisateursAppLocker« . La configuration de la règle est ensuite exportée vers un fichier XML nommé « DevApps.XML », ce dernier sera placé sur C:.

Get-AppLockerFileInformation -Directory C:\Sources -Recurse | New-AppLockerPolicy -RuleType Hash -User UtilisateursAppLocker -RuleNamePrefix DevApps -XML | Out-File C:\DevApps.XML 

Testez vos Règles AppLocker

Les « Best Practices » MS consistent à tester et valider les règles AppLocker avant toute application /déploiement sur un environnement de production.

Tester les règles AppLocker au préalable permet en effet de détecter tout impact /effet de bord sur les autres Apps existantes sur vos serveurs ou simplement corriger une erreur de configuration.

Le test des règles AppLocker peut être effectué via la Cmd-let Test-AppLockerPolicy.

Dans l’exemple suivant, nous allons tester (simuler) l’exécution de l’Application « ZoomIT.exe » placé dans le dossier C:\Sources :

Test-AppLockerPolicy -XMLPolicy C:\DevApps.XML -Path C:\Sources\ZOOMIT.exe

Le résultat retourné par cette commande détaille l’action qui sera effectuée par AppLocker après exécution de l’exe ZoomIT.

Cela vous permet de vous assurer que la restriction logicielle sera bien en place lors de l’application de la règle AppLocker.

Appliquer vos règles AppLocker

Le fichier XML généré précédemment peut être importé (appliqué) :

  • sur une GPO locale (restriction appliquée uniquement sur une seule machine)
  • sur une GPO du domaine (restriction appliquée sur un ou plusieurs machines : selon la liaison de la GPO > OU, Site, Domaine … )

Pour importer le fichier XML sur une GPO locale, la commande suivante est utilisée :

Set-AppLockerPolicy –XMLPolicy C:\DevApps.XML

Pour importer le fichier XML sur une GPO du domaine, la commande suivante est utilisée :

Set-AppLockerPolicy –XMLPolicy C:\DevApps.XML -LDAP « LDAP://FQDN_DC/CN={GUID},CN=Policies,CN=System,DC=MonDomaine,DC=lan »

Vous devez remplacer les variables suivantes par les informations liées à votre domaine AD et DC.

FQDN_DC = Nom DNS du DC hébergeant les services AD DS

GUID = ID de la GPO dans laquelle les règles configurées sur le fichier XML seront importées

MonDomaine = Nom NetBIOS de votre domaine AD

Note : le GUID d’une GPO peut être obtenu via la commande suivante :

Get-GPO -All | select DispayName, ID

TMP_AppLocker1

Dans l’exemple suivant, les règles du fichier XML DevApps.XML seront importées dans la GPO « AppLocker » dont le GUID est 53fa551d-2e8e-436a-8a35-f0dc7f534dcd

Set-AppLockerPolicy –XMLPolicy C:\DevApps.XML -LDAP « LDAP://LABDC01.vLAB.LAN/CN={53fa551d-2e8e-436a-8a35-f0dc7f534dcd},CN=Policies,CN=System,DC=vLAB,DC=LAN »

Après exécution de la commande ci-dessus, lancez l’outil GPMC.msc, naviguez jusqu’à la GPO utilisée précédemment et constatez l’apparition de nouveaux paramètres, notamment l’apparition des règles AppLocker :

TMP_AppLocker2

Cet article est un extrait de l’eBook : AppLocker 2012 R2 – Design et déploiement en Entreprise [Guide du Consultant]

applocker_cover

S’applique à : AppLocker sous Windows Server 2012 et 2012 R2

Introduction

AppLocker est une fonctionnalité de Windows Server qui permet de renforcer la sécurité du S.I en contrôlant comment les utilisateurs du réseau peuvent exécuter les Programmes et Applications tels que les fichiers exécutables, fichiers Windows Installer, Applications Packagées, Scripts ou encore les Bibliothèques de Liens Dynamiques (DLL).

AppLocker a été introduit avec Windows Server 2008 R2 et Windows 7, il représente une évolution des Stratégies de Restrictions Logicielles (SRP : Software Restriction Policy) supportés sous Windows Server 2008 /Windows Vista et Windows Server 2003 /Windows XP.

Bien qu’AppLocker est (techniquement) le successeur des stratégies SRP, les deux fonctionnalités peuvent être utilisées au niveau d’un même domaine Active Directory ou au niveau d’une même machine locale.

 

Nouveautés AppLocker 2012 R2

La version d’AppLocker sous Windows Server 2012 R2 apporte un lot de nouveautés, notamment :

  • Capacité à créer et gérer des Stratégies pour les Applications Packagées
  • Capacité à créer et gérer des Stratégies pour les Installeurs d’Applications Packagées
  • Control de tous les composants d’une App Packagée avec une seule et unique Règle
  • Ajout de deux nouveaux formats de fichiers aux Types de fichiers pouvant être contrôlés par les Règles AppLocker :
    • .MST   : Fichier utilisé par Windows pour personnaliser les paramètres d’installation des Apps Windows Installer
    • .APPX : Format de fichier associé aux Applications Packagées prêtes pour déploiement sur les OS Client : Windows 8 et ultérieur.

Note : Comme son l’indique, une Application Packagée est un Package contenant l’Application (fonctionnelle) ainsi que ses Scripts et ressources associées, le but étant de rationaliser la configuration et le déploiement logiciel.

 

AppLocker vs SRP

À partir de Windows XP et Windows Server 2003, Microsoft introduit les SRP permettant la mise en œuvre d’une politique de restrictions logicielles. Grâce aux SRP, il devient possible de restreindre l’exécution de programmes sur la machine de l’utilisateur en définissant une White-List à l’aide de règles particulières.

Bien configurées, les SRP offrent une protection efficace. Néanmoins, leur configuration peut être assez lourde à maintenir dans un environnement dynamique, en particulier sur un grand parc de machines.

De plus, les Stratégies SRP peuvent être contournées assez facilement par des « Utilisateurs avertis », en effet, une faille de sécurité a été détectée et remontée à Microsoft, en revanche aucun Hotfix n’a été proposé pour corriger cette faille !

En outre, si l’IT en charge de la mise en place des Stratégies SRP commet une erreur dans la création d’une Règle, cela peut créer un conflit avec les autres Applications autorisées et impacter l’ensemble des utilisateurs du réseau et donc impacter la production dans son intégralité.

À cet égard, AppLocker qui est une évolution des SRP apporte de nettes améliorations, et ce au niveau de la configuration, fonctionnement mais surtout sécurité.

Une différence fondamentale entre SRP et AppLocker est le champ d’application des règles. Avec SRP, tous les utilisateurs d’une machine sont impactés indifféremment par les règles. Avec AppLocker, il est possible de cibler un utilisateur ou un groupe d’utilisateurs précis au niveau d’une machine ou d’un Domaine Active Directory.

Enfin, la mise à jour d’une Application déclarée « Autorisée » et contrôlée par une Règle de « Hachage » SRP nécessitait la création d’une nouvelle Règle (Nouvelle version d’Application = Nouvelle Règle SRP), ce qui n’est pas le cas pour AppLocker qui permet d’associer toutes les versions d’une même Application sous une seule et unique Règle, e.i : Règle1 pour App1 v2 et +

 

Prérequis

Pour pouvoir bénéficier d’AppLocker sur les Postes de travail des utilisateurs, il est impératif de disposer de Windows 7 édition Entreprise/Intégrale ou Windows 8 /8.1 édition Entreprise.

Les éditions « Professionnelles » de Windows 7 et Windows 8 /8.1 permettent de configurer des règles AppLocker, mais ces dernières sont inopérantes. Ainsi, AppLocker peut être activé sur les systèmes suivants :

  • Windows 7 Editions « Entreprise » et « Intégrale »
  • Windows 8 et 8.1 Edition « Entreprise »
  • Windows Server 2008 et 2008 R2 Editions « Standard », « Entreprise », « Datacenter » et pour les systèmes Itanium
  • Windows Server 2012 et 2012 R2 Editions « Standard » et « Datacenter »

Note importante : Windows 7, Windows 8 et Windows 8.1 supportent toujours les SRP, mais si une stratégie configure simultanément des règles SRP et AppLocker, seules les règles AppLocker seront prises en compte.

Recommandation : Pour mettre en œuvre une politique de restrictions logicielles fine, il est préférable d’utiliser Applocker plutôt que SRP.

 

Fonctionnement

AppLocker permet d’« AUTORISER » ou de « REFUSER » à un utilisateur (ou un groupe d’utilisateurs) le lancement de programmes sous différentes formes :

  • Exécutables : fichiers .EXE et .COM
  • Windows Installers : fichiers .MSI, .MST et MSP
  • Scripts : .PS1 (PowerShell), .BAT, .CMD , .VBS, .JS
  • Bibliothèques : .DLL et .OCX.
  • Apps Packagées : .APPX

AppLocker1

Pour déterminer si un programme est autorisé à s’exécuter ou non, AppLocker évalue d’abord les règles du type « REFUSER » puis celles du type « AUTORISER ». Notez qu’il est possible de combiner des règles « AUTORISER » et « REFUSER ».

Pour une règle donnée, il peut aussi être défini une ou plusieurs exceptions. Lorsqu’un programme ne fait l’objet d’aucune règle du type « AUTORISER », il est automatiquement bloqué (refus implicite).

Lorsqu’un programme est bloqué par Applocker, l’utilisateur en est informé par un message d’erreur du type : « Ce programme est bloqué par une stratégie de groupe. Pour plus d’informations, contactez votre administrateur système ». Ce message peut être personnalisé en modifiant le paramètre de stratégie de groupe suivant :
Configuration Ordinateur -> Stratégies -> Modèles d’Administration -> Composants Windows -> Explorateur Windows -> Définir le lien d’une page web de support.

Cette possibilité peut être utilisée par exemple pour rediriger l’utilisateur vers l’ouverture d’un ticket d’incident.

Recommandation : pour une meilleure lisibilité du comportement d’AppLocker, il est préférable de n’utiliser que des règles du type « AUTORISER » avec si nécessaire des exceptions

L’autorisation ou le refus d’exécution d’un programme est conditionné à la vérification de règles pour lesquelles trois types différents existent :

AppLocker2

  • Les règles basées sur le chemin d’accès, qui permettent d’autoriser ou de refuser l’exécution de fichiers se trouvant dans le répertoire et les sous-répertoires du chemin. Pour désigner les répertoires classiques du système de fichiers, AppLocker utilise des variables qui sont différentes des variables d’environnement de Windows
  • Les règles basées sur une signature électronique, permettent d’autoriser seulement les fichiers signés par un éditeur donné, et répondant éventuellement à d’autres critères comme le nom du produit, le nom du fichier et sa version
  • Les règles basées sur l’empreinte cryptographique (sha256) d’un fichier, qui n’autorisent que le fichier correspondant à l’empreinte.

Les règles basées sur le chemin d’accès offrent une grande souplesse, mais exigent en contrepartie la maîtrise dans le temps du contenu et des autorisations des répertoires associés afin de s’assurer que seuls des programmes légitimes peuvent s’y trouver. En général, la mise à jour d’un logiciel n’oblige pas à modifier les règles existantes.

Les règles basées sur une signature électronique obtenue à l’aide de certificats de confiance offrent quant à elles plus de sécurité et, selon leur configuration, une souplesse à géométrie variable. Les mises à jour des programmes sont en général transparentes.

Les règles basées sur des empreintes offrent le meilleur niveau de sécurité car elles n’autorisent que les fichiers correspondant à l’empreinte cryptographique. Par contre, lors de la mise à jour d’un logiciel, les règles doivent la plupart du temps être modifiées.
De façon analogue aux règles, les exceptions peuvent s’appliquer à un répertoire, à une signature électronique ou à une empreinte de fichier, et ce quel que soit le type de la règle auxquelles elles sont rattachées.

Recommandation : Lorsque cela est possible, il convient d’utiliser des règles basées sur la signature électronique pour autoriser ou refuser l’exécution d’un programme en s’étant assuré au préalable que les certificats et les autorités de certification sont de confiance

Lors de la deuxième partie, je vous montre comment utiliser Windows PowerShell (utilisation du module PS : AppLocker) pour créer, tester et appliquer les règles AppLocker en mode Command Line.

 

Cet article est un extrait de l’eBook : AppLocker 2012 R2 – Design et déploiement en Entreprise [Guide du Consultant]

applocker_cover

 

P2G_OSHardening

Dans le cadre d’un projet d’industrialisation IT et sécurisation des infrastructures systèmes WS Server (Hardening d’OS) d’un client dans le secteur bancaire, la Checklist disponible en téléchargement gratuit ici a été rédigée, elle regroupe tous les paramètres & options de sécurité à configurer pour verrouiller et sécuriser au maximum l’infrastructure WS Server. Cette checklist s’applique à des serveurs Windows Server 2012 et 2012 R2 situés sur l’infrastructure « OnPremise » ou sur Microsoft Azure. J’espère qu’elle pourra être utile à certains Consultants /Architectes travaillant sur le même type de projet.

Bonne lecture & Keep in touch :).