Archives de novembre, 2018

Hi Azure Guys,

Aujourd’hui je vais vous parler d’un Powerful Web tool dédié à l’offre IaaS d’Azure : Azure Virtual Machine

Il s’agit de AzurePrice.Net

Cet outil web vous permet de trouver et comparer rapidement les différentes offres Azure VM depuis une seule et même page.

Plusieurs clients trouvent qu’Azure Pricing Calculator n’est pas très pertinent quand il s’agit de sélectionner et calculer le prix de plusieurs VM Azure à la fois.

Azure Pricing Calculator est organisé par volet /par service Azure, il vous offre également la possibilité de calculer le prix d’une configuration spécifique/personnalisée, c’est la raison pour laquelle il reste l’outil à privilégier quand il s’agit de calculer le coût global d’une infrastructure Azure.

En revanche, si vous cherchez un outil simple & easy à utiliser pour calculer rapidement le coût d’une ou plusieurs VM Azure, (uniquement), eh bien AzurePrice.Net reste le meilleur outil. A garder dans sa Toolbox.

DEMO

Dans l’exemple suivant, je veux simplement connaître le coût mensuel (en €) d’une VM Azure de type « Standard_A2_v2 » hébergée en France.

Les filtres sont configurés avec les paramètres suivants :

  • Région : France Central
  • Coût : Euro (€)
  • Mode Facturation : Mensuel

 

Résultat de ma recherche :

Comme indiqué dans la Screenshot, le résultat retourné inclut également une colonne (Best Price /couleur verte) vous indiquant la Région Azure offrant le meilleur prix pour la même VM (West US 2 dans notre exemple). Si vous n’avez pas de contrainte spécifique pour héberger votre VM en dehors de la France (eg : contraintes légales), vous pouvez donc choisir d’héberger votre VM dans cette Région et économisez 28,3% sur le coût global comparé à un hébergement en France Central.

Enjoy :).

A bientôt.

#HK

 

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, Monitoring, 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« 

Prérequis

Avant d’aller plus loin dans ce Post, vérifiez que vous disposez bien d’un :

  • Abonnement Azure
  • Azure AD configuré
  • Une instance Azure ADDS configurée
  • Un certificat SSL délivré :
    • Par votre CA Entreprise interne (CA Privée)
    • Par une CA Public
    • Ou encore un certificat Self-Signed que vous générez-vous même : Déconseillé pour une instance AAD-DS de Prod

 

4 Steps pour configurer/forcer LDAPS sur votre Domaine « Managé » Azure ADDS

La configuration du LDAPS sur votre domaine Managé Azure ADDS se fera en 4 étapes :

  • Etape 1 : Générer un certificat SSL (auto-signé) pour les communications LDAPS
  • Etape 2 : Exporter le certificat SSL LDAPS vers un fichier .PFX
  • Etape 3 : Activer LDAPS sur votre Domaine Managé depuis le Portail Azure
  • Etape 4 : Configurer le DNS pour pouvoir accéder à votre Domaine Managé Azure ADDS depuis Internet

 

HowTo : Configurez LDAPS sur votre domaine « Managé » Azure ADDS 

Etape 1 : Générer votre certificat SSL pour les communications LDAPS (pour environnement Dev/Test/Training… Only !!)

Comme indiqué dans la capture d’écran ci-dessous, le nom de mon Domaine Managé Azure ADDS est HK.Corp :

Le certificat SSL à générer devra donc être configuré pour ce même DNS Name (HK.Corp)

Vous pouvez utiliser le script P(ower)S(hell) suivant pour générer votre Cert SSL Self-Signed :

Note : vous devez bien évidemment remplacer les valeurs des paramètres « -Subject » et « -DnsName » par celles correspondant à votre environnement.

Ce script PS est disponible en téléchargement depuis la Gallery TechNet :

 

Le certificat SSL (Auto-Signé) généré est automatiquement stocké dans le Magasin de certificats (Cert Store) local de la machine à partir de laquelle vous avez exécuté le Script

  • Pour le visualiser, lancez une console MMC vierge en exécutant l’outil MMC.exe depuis le Menu Démarrer ou Exécuter > Fichier > Ajouter/Supprimer des composants logiciel enfichable… > Certificats > AjouterUn Compte d’ordinateur > Ordinateur local > Terminer > OK

  • Maintenant, développez « Personnel » > « Certificats« 

Etape 2 : Exporter le certificat SSL LDAPS vers un fichier PFX 

Nous allons maintenant exporter le certificat (Self-signed) généré précédemment vers un fichier PFX. En effet, Azure ADDS s’appuie sur ce type de fichier pour forcer le LDAPS sur le domaine Managé.

Pour ce faire, suivez les instructions suivantes :

  • Faites un Click-droit sur le certificat auto-signé généré (HK.Corp dans l’exemple suivant), et sélectionnez « Toutes les tâches » > Exporter…
  • L’assistant d’exportation de certificat apparaît, cliquez sur « Suivant« 
  • Veillez à bien cocher « Oui, exporter la clé privée« , cela est très important sinon la sécurisation de votre domaine AADDS à l’aide de ce certificat ne pourra être effectuée

  • Maintenant, vérifiez que l’option « Echange d’informations personnelles (.PFX) » est bien cochée et cliquez sur « Suivant » :

  • Cochez « Mot de passe« , spécifiez votre mot de passe et confirmez-le, cliquez ensuite sur « Suivant » pour continuer :

  • Spécifiez un emplacement pour enregistrer le fichier .PFX et cliquez sur « Suivant« :

  • Enfin, cliquez sur « Terminer » pour lancer l’exportation du certificat (en .PFX File) :

  • Si le certificat est exporté avec succès, le message suivant apparaît, cliquez sur « OK » pour fermer la boite de dialogue :

Etape 3 : Activer LDAPS sur votre Domaine Managé depuis le Portail Azure

Pour activer LDAPS sur votre domaine Managé Azure ADDS, suivez les instructions suivantes :

  • Connectez-vous sur le Portail Azure (https://portal.azure.com)
  • Localisez et cliquez sur le service « Azure AD Domain Services« 

  • Cliquez sur votre Domaine Managé AADDS (HK.Corp dans l’exemple suivant) :

  • Par défaut, LDAPS est désactivé sur tout Domaine Managé Azure ADDS déployé :

  • Cliquez sur « Activé« , localisez et sélectionnez le PFX exporté précédemment, renseignez ensuite le mot de passe associé a ce fichier et cliquez sur « Enregistrer« . Comme illustré dans l’image suivante, n’autorisez pas l’accès LDAPS à votre domaine Managé sur Internet 

  • La configuration du LDAPS sur votre Domaine Managé démarre… notez que cette opération peut prendre jusqu’à 10 voire 15 minutes, soyez donc patient 🙂 !

Comme mentionné dans le message/avertissement suivant, le port 636 doit être autorisé (en Inbound) au niveau de vos DC-as-a-Service AADDS, faute de quoi les communications LDAPS entre vos clients et Domain Controllers AADDS échoueront !

Note : comme indiqué dans la Screenshot précédente, LDAPS (LDAP over SSL) communique sur le port 636. Vous pouvez le confirmer en consultant la base IANA (Internet Assigned Numbers Authority) à cette URL.

Vous devez donc le configurer (autoriser) manuellement au niveau de votre NSG (Network Security Group) :

  • Dès que l’opération de configuration du LDAPS sur votre Domaine Managé est terminée, les informations suivantes apparaissent depuis le volet « Vue d’Ensemble » : Empreinte de votre Certificat ainsi que sa date d’expiration 

Etape 4 : Configurer le DNS pour accéder à votre Domaine Managé Azure ADDS depuis Internet

Azure vous offre la possibilité d’accéder à votre domaine Managé Azure ADDS depuis Internet, cela vous permet de joindre des machines distantes (connectées depuis n’importe ou !!) à votre domaine Managé.

  • Il suffit d’activer l’option « Autoriser l’accès LDAP sécurisé sur Internet » :

  • Suite à cette opération, une Adresse IP (ADRESSE IP EXTERNE DE LDAP SÉCURISÉ) est générée et est disponible depuis les Propriétés de votre Domaine Managé Azure ADDS :

 

Maintenant, il vous reste plus qu’à créer un enregistrement DNS (publique) qui pointe vers cette @IP publique. Il faut simplement se connecter sur l’interface d’Administration Web de votre fournisseur de domaine et créer cette entrée DNS (cf documentation de votre hébergeur/fournisseur de domaine).

WARNING !!

Je ne suis pas Fan de cette option car exposé son annuaire AD à Internet n’est pas Best Practice (Sécu), en effet cela vous expose à des risques assez important (Password Brute-force-Attack : Attaque Directe sur votre Domaine Managé vu qu’il sera accessible depuis le réseau Internet).

Azure vous avertir d’ailleurs quand activez l’accès LDAPS sur Internet, en effet, le message d’avertissement suivant est affiché en permanence depuis le volet « Vue d’ensemble« :

Nous pouvons toujours filtrer le trafic (entrant) à l’aide de Rule NSG mais le risque restera toujours présent, le moindre changement (erreur de config !!) des règles NSG peut rendre votre domaine accessible via Internet !

MS recommande la mise en place de ce filtrage comme WorkAround/Option de sécurisation mais faites moi confiance, exposer son annuaire AD sur Internet n’a jamais été un Best Practice et ne le sera jamais, so Fortget this option !

De plus, aucun client acceptera la publication de son domaine AD (Managé en plus :s) sur Internet et donc l’exposer à la terre entière !

Option donc à éviter. Ce n’est pas quelque chose que je pousse chez mes clients aujourd’hui, et je vous recommande de faire la même chose.

La DEMO est donnée ici  à titre indicatif si toutefois vous souhaitez tester les différentes options fournies avec un Domaine Managé Azure ADDS

That’s All :).

N’hésitez pas à vous abonner sur mon Blog, plusieurs articles autour de l’Azure arrive les prochains jours/semaines.

A bientôt

#HK

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

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 » :