Introduction
Azure Policies (ou Stratégies Azure) est une composante critique et importante du modèle de Gouvernance Global Azure.
Ce service vous permet de définir, créer et contrôler vos stratégies de sécurité (by Design) et de Compliance pour rester ISO avec vos normes/exigences de sécurité existantes (OnPrem).
Les Azure Policies vous permettent (entre autres) de :
  • Définir les régions dans lesquelles autoriser vos utilisateurs Azure à déployer les services Cloud Azure
  • Définir (Forcer) une Convention de nommage Azure à respecter lors de la création des Ressources Azure
  • Définir un Centre de coût (Billing Owner/Cost Center) pour des besoins de « Charge-Back »
  • Définir les types/Sizes de VMs pouvant être créées/déployées
Dans l’exemple suivant, nous allons créer une Stratégie Azure pour restreindre la création d’une interface Publique (Public IP Address) au sein d’un Groupe de Ressource (RG : Resource Group). Notez que cela peut aussi s’appliquer un Abonnement Azure.

Quel Outil utilisé ?

La création d’une stratégie Azure (Azure Policy) peut se faire via différents outils, à savoir :

  • GUI : Portail Azure
  • CLI  : PowerShell ou Az Cloud Shell

Dans l’exemple suivant, nous allons utiliser un Script PowerShell pour crée et assigner notre Azure Policy. Je vous détaillerai aussi la procédure à suivre pour créer et assigner une Stratégie Azure via le Portail Azure.

 

HowTo : Restreindre/Refuser la création d’Interface (IP@) Publique via PowerShell

Lancez une instance Windows PS ou de préférence PowerShell ISE, et Copy/Paste ensuite les codes PS ci-dessous :

Note : vous devez bien évidemment remplacez les valeurs du Script avec celles correspondant à votre environnement (Nom Abonnement, Nom RG…etc)

Ce script PS est disponible en Free Download depuis la Gallery TechNet :

 

 

Une fois le script exécuté, rendez-vous sur le Portail Azure, cliquez sur votre Groupe de Ressource Azure, et cliquez sur « Stratégies » > « Vue d’ensemble »

Comme illustré dans la capture d’écran ci-dessous, ma nouvelle Policy apparaît et m’indique que plusieurs Ressources Azure ne sont pas « Compliant » !

Sachez que cette nouvelle stratégie va permettre la restriction (refus) de création de toute nouvelle @IP Public mais ne peut en aucun cas modifier la configuration existante, si vous avez des VMs avec des NIC Public, il faudra modifier cela manuellement (Dissocier/Delete les Interfaces/IPs Publiques !) :

Essayons maintenant de créer une nouvelle adresse IP Publique pour mon serveur d’Administration (Jumpbox/ RDSH Server).

Je renseigne donc les premières valeurs de paramètres :

Ensuite la deuxième partie :

Lorsque je Click sur « Créer » pour lancer le déploiement du nouveau service Cloud (Public IP), le message d’erreur suivant est retourné :

Il est clairement indiqué que l’opération a été refusée/rejetée par la Stratégie Azure : RestrictionCreatPublicIP 😦

 

Ré-utiliser cette stratégie pour d’autres « Scopes »

Sachez que cette même stratégie Azure peut être appliquée (Assignée) à d’autres périmètres (D’autres Groupes de Ressource ou Abonnements Azure), pour ce faire :

  • Connectez-vous sur le Portail Azure > Cliquer sur l’objet sur lequel vous souhaitez « Linker » cette Policy (Groupe de Ressource ou Abonnement), enfin cliquez sur « Stratégies » :
  • Dans l’exemple suivant, je vais simplement restreindre la création d’@IP publique pour mes VMs (et LBs) hébergés dans le Groupe de Ressource « hk-confident-rg« , car je ne souhaite pas que mes ressources soient exposées à Internet (eg : VM accessible via RDP ou SSH depuis Internet !!!).

Maintenant, il suffit de cliquer sur « Assigner une stratégie » :

Notez que cette option est également disponible depuis le vole « Création > Affectations« 

Useful info : Code JSON de cette Azure Policy
Si vous souhaitez créer cette même Policy depuis le Portail Azure, vous aurez besoin du code JSON suivant :
{
  "if": {
    "anyOf": [
      {
        "source": "action",
        "like": "Microsoft.Network/publicIPAddresses/*"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

En savoir plus sur les Stratégie Azure
Si vous êtes pas encore familier avec les Azure Policies, je vous invite à consulter cet article.
A bientôt pour de nouveaux posts autour de la sécurité et Gouvernance Azure :).
#HK
Publicités

Introduction à Azure ADDS

AADDS (Azure Active Directory Domain Services) est une offre PaaS (Platform-as-aService) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (Domain Controller-as-aService).

Azure AD DS est une instance (Forêt AD standalone) Windows Server Active Directory managée par Microsoft, cela veut dire que Microsoft créé, déploie et manage les Domain Controller pour vous.

Vous n’avez plus à vous soucier de la sécurité de vos Domain Controllers (Patch Management, Hardening, Sécurité Physique…etc).

Consultez cet article pour en savoir plus sur Azure Active Directory Domain Services.

Note importante : Le fait que MS manage les Domain Controllers à votre place présente certaines limitations que vous devez prendre en considérations, voir cet article pour en savoir plus : https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison > Rubrique « Compare Azure ADDS to DIY AD« 

Ancienne limitation/restriction relative à la stratégie (par défaut) de mot de passe d’une instance AADDS 

Par défaut, la durée de vie des mots des passe dont le hash est stocké dans une base Azure ADDS était définie à 90 jours.

Cette stratégie de mot de passe ne convient bien évidemment pas à tout le monde, par exemple :

  • Une société ayant des exigences de sécurité fortes : durée de vie des mots de passe des Domain Admin et Comptes à Haut privilège à 60 voire 30 jours !
  • Une société avec moins de crainte de sécurité ayant une stratégie de sécurité « Plus Relax » : durée de vie des mots de passe des Domain Admin et Comptes à Haut privilège à 180 jours voire 365 jours.

 

Plusieurs Customers (Clients) Azure ont donc remonté cette limitation (moi y compris :)) aux équipes MS Azure Corp.

Ces feedbacks ont été pris en compte et l’équipe Azure a fait un Goodjob sur cette partie en intégrant les stratégies de mots de passe affinées (FGPP : Fine-Grained Password Policy) au niveau des services ADDS Azure.

Note : si vous n’êtes pas encore familier avec les FGPP, je vous invite à consulter cet article.

 

Prérequis 

Vous devez bien évidemment disposer d’un abonnement Azure ainsi que :

  • Une instance Azure AD (IDaaS)
  • Une instance Azure ADDS configurée (DCaaS)
  • Une machine d’Administration membre de votre domaine managé Azure ADDS

 

Useful Links

Si vous ne disposez pas encore de compte/abonnement Azure, je vous invite à en créer un depuis cette URL : https://azure.microsoft.com/fr-fr/free/

Si vous n’avez pas encore créer et configurer un domaine Managé Azure ADDS, je vous invite à suivre les instructions détaillées dans ce post : https://docs.microsoft.com/fr-fr/azure/active-directory-domain-services/active-directory-ds-getting-started

Pour joindre une machine d’administration à votre domaine Azure ADDS, suivez les instructions détaillées dans cet article : https://docs.microsoft.com/fr-fr/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-windows-vm-portal

Dans l’exemple suivant, le DNS name configuré sur mon domaine Managé AADDS est hk.corp

 

Tout d’abord, vérifions la FGPP configurée par défaut sur un domaine managé Azure ADDS

Depuis votre machine d’administration membre du domaine managé, lancez la console DSAC (Active Directory Administrative Center) et développez : votre domaine managé > System > Password Settings Container, enfin double-cliquez sur ‘AADDSSTFPSO

Comme indiqué dans la Screenshot ci-dessous, la stratégie de mot de passe configurée par défaut sur votre domaine managé Azure ADDS a les caractéristiques/propriétés suivantes :

  1. Longueur minimale du password : 7 caractères
  2. Durée de vie des mots de passe : 90 Jours 
  3. Le mot de passe doit respecter les règles de complexité : Oui

Note importante : La stratégie de sécurité par défaut (AADDSSTFPSO) ne peut être modifiée ni supprimée !

 

HowTo : Configurez une stratégie de mot de passe personnalisée pour votre domaine Managé Azure ADDS

Nous allons dans l’exemple suivant, créer et configurer une stratégie de sécurité personnalisée pour définir les paramètres suivants :

  1. Longueur minimale du password : 16 caractères
  2. Durée de vie des mots de passe : 60 Jours 
  3. Le mot de passe doit respecter les règles de complexité : Oui

Les valeurs relatives aux options de verrouillage de compte (Lockout) respectent le standard de sécurité adopté aujourd’hui dans les entreprises, nous allons donc garder les mêmes valeurs, à savoir :

  • Compte verrouillé suite à : 5 tentatives de connexion échouées
  • Durée pendant laquelle le compte reste verrouillé : 30 minutes

 

Notez que cette nouvelle stratégie de sécurité (personnalisée) sera appliquée uniquement au groupe : Domain Admins

Comment ça marche ?

Suivez les instructions suivantes pour configurer votre stratégie de mots de passe au niveau de votre domaine AD managé AADDS :

  • Ouvrez une Session Windows sur la machine d’administration membre de votre domaine managé Azure ADDS
  • Lancez l’outil DSAC (ou DSAC.exe)
  • Naviguez jusqu’au : System > Password Settings Container > Depuis le volet ‘Tasks’, cliquez sur ‘New’ > ‘Password Settings’

  • Renseignez toutes les informations de configuration de votre nouvelle stratégie de sécurité, n’oubliez pas de spécifier le groupe « Domain Admins » au niveau de « Directly Applies To« , pour éviter que cette nouvelle stratégie de sécurité s’applique à tout le monde : un password lifetime pour un end user (utilisateur métier : basic/standard user) ne passera jamais :).

Note importante : veillez à bien décocher l’option « Protection from accidental deletion« , sinon la stratégie de sécurité ne pourra être créée (problème de permissions : by design sur l’instance Azure ADDS) : voir capture d’écran suivante avec le message d’erreur :

 

#HK | Just Another IT Guy

Image associée

BitLocker : Introduction

BitLocker est une fonctionnalité native dans les OS Windows Client et Server.

Cette Built-in Feature vous permet de chiffrer vos Disks Systèmes et DATA mais aussi vos Disks Amovibles (Removable Devices > eg : USB Key) à l’aide de la fonctionnalité BitLocker ToGo.

Avec BitLocker, vous pouvez donc protéger vos données et vous protéger contre les menaces liées au vol/perte de Laptop.

BitLocker a d’abord été introduit avec le couple Windows Vista/Windows Server 2008. Cette fonctionnalité de sécurité Windows a évoluée dans le temps et a été améliorée avec la sortie de chaque nouvelle version d’OS Windows.

Pour en savoir plus sur BitLocker, je vous invite à consulter cet article.

 

Suis-je Obligé d’utiliser un Module TPM (ou pas) ?

Pour pouvoir chiffrer vos Disks (OS & DATA) à l’aide de BitLocker, Microsoft recommande l’utilisation de ce qu’on appelle un TPM (Trusted Platform Module : Module de Plateforme Sécurisée).

Une puce TPM est un petit contrôleur de sécurité gravé (dès la conception/fabrication de votre Laptop) sur la carte mère, il s’agit d’un mini « HSM (Hardware Security Manager) qui servira de coffre-fort (Key Vault) pour stocker la clé de chiffrement utilisée par BitLocker.

Cette clé de chiffrement utilisée par BitLocker sert à chiffrer (et dé-chiffrer) vos données, elle est ensuite communiquée au lanceur du système seulement si les principaux fichiers de démarrage ne semblent pas avoir été modifiés. L’utilisateur doit ensuite s’authentifier pour démarrer l’OS.

Modes d’Authentification 

Deux modes d’authentifications sont possibles : par code PIN ou par une clé USB contenant une clé valide, ce mode ne nécessite donc pas de puce TPM mais une simple clé USB qui sera nécessaire pour le Boot de la machine.

Il n’est pas recommandé d’utiliser une clé USB (risque de perte/vol de celle-ci !!) pour stocker la clé de chiffrement utilisée par BitLocker. C’est la raison pour laquelle nous allons voir à travers cet article comment Activer BitLocker pour chiffrer vos Disks à l’aide d’un code PIN.

Stay Connected :).

 

Comment puis-je vérifier la présence (ou absence) du module TPM sur mon Laptop ?

Windows 10 est fourni avec un Buil-in Snap-in appelé « TPM Manager /Gestionnaire TPM ».

Cet outil vous permet de configurer et gérer vos modules TPM localement ou à distance.

Il s’agit du Snap-in TPM.msc, accessible depuis une console MMC ou directement depuis le Menu « Démarrer » ou « Exécuté ».

Une fois lancé, TPM Manager vous indique si un module TPM est présent (ou pas) sur votre machine Windows. Dans l’exemple suivant, il est indiqué que le module TPM est prêt à être utilisé, cela veut simplement dire que ma machine est bien équipée d’une puce TPM.

 

HowTo : Activez Bitlocker et sécurisez l’accès à vos OS Disk sans module TPM :).

Suivez les instructions suivantes pour activer BitLocker (avec PIN code) sur votre Laptop Windows 10

Lancez l’outil GPEdit.msc depuis le Menu « Exécuter » (ou Démarrer) :

Développez : Configuration Ordinateur \ Modèles d’Administration \ Composants Windows \ Chiffrement de lecteur BitLocker \ Lecteurs du système d’exploitation

Double-cliquez sur le paramètre « Exiger une authentification supplémentaire au démarrage »

Cliquez sur « Activé » et cochez l’option « Autoriser BitLocker sans un module de plateforme sécurisée compatible (requiert un mot de passe ou une clé de démarrage……USB). Enfin, cliquez sur « Ok » pour valider :

Saisissez un GpUpdate depuis une Invite de Commande (CMD.exe) ou le Menu « Démarré » pour Refresh le moteur des stratégies de groupe local.

Maintenant, rendez-vous dans Panneau de configuration > Chiffrement de lecteur BitLocker :

Au niveau de votre partition système (C:), cliquez sur « Activer BitLocker »

L’assistant suivant apparaît, cliquez sur « Entrer un code confidentiel (recommandé) »

Saisissez votre PIN Code (Je vous recommande l’utilisation d’un code avec 14 et 16 caractères minimum) :

Si toutefois vous oubliez votre code PIN (parce que vous partez en vacances ce soir et que vous revenez que dans un mois :-D), la clé de récupération que vous êtes invité à sauvegarder lors de cette étape vous permettra la récupération/accès à votre PC. Vous aurez compris, il faut l’enregistrer/sauvegarder dans un endroit sûr !

L’assistant vous propose plusieurs options :

  • Enregistrement dans le Cloud (Microsoft bien évidement) : OneDrive doit être configuré au préalable sur votre machine
  • Enregistrement dans un fichier (Texte) : l’assistant refusera l’enregistrement du fichier (clé de récup) sur le même disque à chiffrer, vous devez donc disposez d’au moins deux disques locaux (physiques) attachés à votre machine, un disque dur externe ou une clé USB.
  • Impression de la clé de récupération : WTF !!! à éviter bien évidemment

 

Dans l’exemple suivant, ma clé de récupération sera sauvegardée dans le Cloud (sur mon Onedrive qui est déjà sécurisé et chiffré : Data-in-Transit et At-Rest)

Si vous choisissez l’option « Enregistrement dans un fichier », vous devez simplement sélectionnez un emplacement (externe > ExHDD ou USB Key) et cliquez sur « Enregistrer » :

BitLocker peut chiffrer tout le disque ou uniquement l’espace disque utilisé, le chiffrement de tout le disque risque de prendre plusieurs heures voire des jours s’il s’agit de plusieurs centaines de GigaB ou plusieurs TeraB. Je vous recommande de chiffrer que l’espace disque utilisé :

Comme mentionné dans l’assistant, depuis la v1511 de Windows 10, BitLocker prend en charge un nouveau mode de chiffrement de disque (basé sur du chiffrement par bloc : XTS-AES). Si votre Windows 10 est compatible XTS-AES, je vous recommande l’utilisation de ce mode de chiffrement :

Are You Ready 🙂 ? Si oui, laissez l’option « Exécuter la vérification du système BitLocker » cochée et cliquez sur « Continuer » :

La notification suivante apparaît dans le coin inférieur gauche de votre écran, et vous indiquant que le chiffrement de votre disque démarrera après le reboot de la machine :

Redémarrez votre machine (assurez-vous que tous vos travaux soient enregistrés et fermés 🙂 : document Word ouvert, Mail écrit mais non enregistré/non envoyé…etc) :

Après redémarrage, la fenêtre suivante apparaît, vous pouvez continuer à travailler sur votre machine le temps que BitLocker encrypte votre(vos) Disk(s). Cliquez simplement sur le bouton « Fermer » pour cacher la petite fenêtre « Chiffrement de lecteur BitLocker » :

 

Une fois le disque chiffré, BitLocker retourne le statut suivant :

Enfin, redémarrez votre Ordinateur et notez l’apparition de l’assistant BitLocker au démarrage, vous devez saisir votre PIN Code (configuré précédemment) pour pouvoir démarrer votre OS :).

That’s All :).

J’espère que cette astuce pourra vous être utile. N’attendez plus, commencez à sécuriser vos Laptops/PC de Bureau dès aujourd’hui.

A bientôt,

#HK

Introduction

Vous apprenez à travers cet article « Comment déplacer vos Ressources Azure d’un abonnement à un autre ». Notez que la technique expliquée dans le présent article s’applique également à un Move de ressource entre RG (Resource Groups).

 

Prérequis 

Avant de pouvoir déplacer vos ressources Azure (entre Abonnements ou RG), vous devez d’abord enregistrer la feature « ManagedResourceMove« , fournie avec le le fournisseur d’espace de nom « Microsoft.Compute« .

Pour ce faire, exécutez les deux commandes PS ci-dessous :

Register-AzureRmProviderFeature -FeatureName ManagedResourcesMove -ProviderNamespace Microsoft.Compute

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute

Comme indiqué au niveau de l’état d’enregistrement (RegistrationState), la fonctionnalité « ManagedResourcesMove » est toujours en « Registering »

Avant de pouvoir déplacer vos Managed Disks/VMs, l’enregistrement de cette fonctionnalité doit passer à « Registered »

 

HowTo : Déplacer vos ressources vers un autre Abonnement Azure via Az CLI 2.0

1 : Commencez par lister les abonnements associés à votre compte Azure en exécutant la commande suivante :

az account list -o table

Note importante : si vous n’avez pas encore connecté l’interface (locale) Azure CLI 2.0 à votre compte Azure, je vous invite à consulter cet article.

 

2 : Maintenant, définissez l’abonnement contenant les ressources à déplacer en tant qu’Abonnement par défaut. Pour ce faire, exécutez la commande suivante :

Note : dans mon cas, l’abonnement qui contient la ressource Azure que je souhaite déplacer est nommée « Visual Studio Premium avec MSDN« 

az account set -s « Visual Studio Premium avec MSDN »

3 : Lister les groupes de Ressources de l’abonnement « Source » en exécutant la commande az group list -o table

4 : La ressource que je souhaite déplacer est un VNET (Virtual Network), placé dans le groupe de ressource « hk-demo-rg« . Le VNET est appelé « hk-test-vnet » :

az resource list -g hk-demo-rg 

5 : Maintenant, nous devons récupérer l’ID(entifiant) de la ressource « Source » à déplacer.

La commande Az CLI suivante nous permet d’obtenir cette information :

6 : Nous allons créer un nouveau Groupe de Ressource au niveau de l’abonnement de « Destination ».

Ce groupe de ressources portera le même nom que le RG « Source ».

La commande Az CLI qui permet de créer un nouveau RG est la suivante :

az group create -n hk-demo-rg -l WestEurope (ou FranceCentral)

7 : Vous devez à ce stade, récupérer l’ID de l’abonnement de Destination en exécutant la commande az account list -o table :

8 : Pour déplacer notre ressource Azure (VNET : hk-test-vnet) vers le nouveau groupe de ressources du nouvel abonnement, la commande suivante est utilisée :

9 : L’opération démarre, vous pouvez vous connecter sur le portail Azure (https://portal.azure.com) et surveiller le statut/état d’avancement du « Move » :

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (Onprem) vers Azure et/ou construire de nouvelles architectures (Mode « Cloud Only »), notez que la Step1 de votre projet va consiste à définir un Modèle de Gouvernance Global pour Azure.

Comme illustré dans le schéma ci-dessus, le modèle de Gouvernance Azure (Azure Scaffold) est composé de :

  • Modèle de délégation (RBAC)
  • Policies (Stratégies Azure)
  • Tags (Azure Resources Tags)
  • Abonnements (Azure
  • Et Surtout la convention de nommage (Naming Convention/Standards) qui est un objet « transferve » du modèle de Gouvernance Azure.

 

La convention de Nommage est l’une des composantes « Critique » de ce modèle de Gouvernance Azure.

En effet, définir une bonne convention de nommage vous facilitera la vie quand il s’agit de Reporter, faire du Billing Track, Localiser les ressources Cloud facilement….etc

Pour vous aider à construire ce modèle de Convention de Nommage Azure, je vous ai préparé un document détaillé (SlideShare) à travers lequel je vous explique toutes les contraintes et restrictions (Naming Rules Azure) à prendre en compte, et surtout mes Best Practices pour réussir la définition de votre Document de Convention de Nommage Azure.

 

Step-by-step guide : Comment construire sa convention de nommage Azure ?

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

Ce Slide a été rédigé en Anglais (pour atteindre un public plus large) mais sera bientôt disponible en Français sur la même plateforme.

 

Next Lesson ?

Je travaille actuellement sur les autres « Lessons/Modules » du modèle de Gouvernance Global Azure, à savoir :

  • Les Policies Azure
  • RBAC Azure
  • Resources Groups
  • Et Resources Tags

 

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication.

Sinon, vos Comments/Feedbacks sont bien évidemment les bienvenus :).

#HK

 

Plusieurs modifications ont été apportées aux rôles, services de rôles et fonctionnalités de Windows Server 2019.

Avant la sortie officielle de Windows Server 2019 (le 02 Octobre 2018), l’équipe Windows Server Corp a mis à jour la liste des rôles/service de rôles et fonctionnalités ayant été modifiés par rapport à Windows Server 2016.

Cette liste (complète) est disponible à cet URL.

Je vais vous lister quelques « Major Changes » à travers cet article.

Nouveaux Rôles 

Pas de nouveaux rôles !

Nouveaux Services de Rôles

Pas de nouveaux services de rôle !

Rôles Supprimés

Les deux rôles suivants ont été supprimés de Windows Server 2019 :

MultiPoint Services

Expérience Windows Server Essentials 

 

Services de Rôles supprimés

Seul le service de rôle suivant a été supprimé (Fonctionnalité de Scan Management). Il a été introduit avec WS Server 2008 R2, mais n’a pas connu beaucoup de succès, de plus pas beaucoup de devices sont compatibles avec cette Windows Feature, MS a donc décidé d’arrêter le développement de ce service de rôle.

Serveur de numérisation distribuée

 

Fonctionnalités Modifiées

Les deux fonctionnalités Windows Server suivantes ont été modifées suite à l’évolution de version :

ASP.NET 4.7 au lieu de ASP.NET 4.6

Extensibilité .NET 4.7 au lieu de Extensibilité .NET 4.6