Archives de la catégorie ‘Azure Security’

Introduction à Microsoft Azure Advisor 

Microsoft Azure Advisor est un Consultant Azure « Virtuel » et « Automatisé » qui vous aide à optimiser vos déploiements Cloud et réduire vos consommations Azure. Il s’appuie sur tout un ensemble de « Best Practices » et règles de conformité/sécurité standards.

En effet, Azure Advisor examine la configuration de tous vos services Azure déployés et vous propose des recommandations dans les domaines suivants

Haute Disponibilité (HA : High Availability)

Sécurité

Performance

Coût (Cost)

 

Grace à Azure Advisor, vous pouvez :

  • Bénéficier de recommandations en termes de meilleures pratiques proactives, interactives et personnalisées.
  • Améliorer les performances, la sécurité et la haute disponibilité de vos ressources Azure
  • Réduire le coût/consommation Azure.
  • Obtenir des recommandations avec des propositions d’actions intégrées.
    • Les recommandations proposées par Azure Advisor sont fournies avec des liens intégrés vous permettant d’implémenter directement les actions de remédiation.

 

Azure Advisor : ce que vous devez savoir !

Les recommandations fournies à travers Azure Advisor reposent sur les Best Practices courantes, telles que le placement de machines virtuelles (VM) dans des Groupes à haute disponibilité, Non-exposition des ports tels que RDP/SSH sur Internet…

Les recommandations de sécurité proviennent d’Azure Security Center. Alors que les données de facturation sont collectées à partir du portail Azure Enterprise, Azure Advisor peut analyser l’utilisation/consommation Azure et identifier les points pouvant réduire le coût tels que les VMs sous-utilisées. C’est la raison pour laquelle Azure Advisor, reste un outil assez puissant qui peut vous aider à renforcer votre gouvernance globale Azure.

Autorisations nécessaires pour accéder à Azure Advisor 

Les utilisateurs ayant les rôles suivants peuvent accéder à Azure Advisor et visualiser toutes les recommandations, et ce pour toutes les catégories :

  • Propriétaires
  • Contributeur
  • Lecteur

 

Ressources pouvant être analysées/évaluées par Azure Advisor 

Azure Advisor peut évaluer la configuration des ressources Azure suivantes seulement :

  • Machine Virtuelle Azure
  • Groupes à haute disponibilité
  • Passerelles d’application
  • App Services
  • Serveurs SQL
  • Cache Azure pour Redis.

 

Azure Advisor : Prise en main

Faisons un tour d’horizon d’Azure Advisor !

Azure Advisor est accessible depuis « Tous les services /All services » ou simplement en saisissant « Advisor » depuis la barre de recherche du Portail Azure

Tip : Je vous recommande de l’ajouter en tant que « Service Favoris » en cliquant sur l’Etoile noire:

Comme montré dans la capture d’écran ci-dessous, Azure Advisor est composé de plusieurs onglets :

  • Haute disponibilité : liste les recommandations qui vous aideront à augmenter la disponibilité de vos services Azure les plus critiques
  • Sécurité : liste les recommandations qui vous permettent de détecter les menaces et vulnérabilités pouvant conduire à des failles de sécurité.
  • Performance : liste les recommandations qui vous aideront à améliorer les performances de vos services Cloud Azure.
  • Coût : liste les recommandations qui vous permettant d’optimiser et réduire vos coûts /consommations Azure

Il existe deux autres volets qui sont :

  • Vue d’ensemble : cet onglet présente un résumé de toutes les recommandations, pour les 4 domaines/catégories (Sécurité, HA, Performance et Coût). Si vous souhaitez consulter les recommandations pour une catégorie spécifique, rendez-vous sur un des 4 onglets précédemment. eg : Onglet « Sécurité« : pour consulter les recommandations de sécurité).
  • Tous : cet onglet liste toutes les recommandations pour les 4 catégories. Vous pouvez simplement cliquer sur une recommandation pour afficher plus de détails. Vous avez ensuite la possibilité de la reporter/ignorer ou de réaliser l’action de remédiation proposée.

Configurer Azure Advisor

Azure Advisor vous offre la possibilité de configurer les abonnements et groupes de ressources à analyser/évaluer.

Si vous voulez exclure certains abonnements ou groupes de ressources du scope d’Azure Advisor, eh bien cela peut être configuré en cliquant sur le bouton « Configurer » :

Vous pouvez ensuite, inclure ou exclure des abonnements ou groupes de ressources dans l’évaluation Azure Advisor :

Note : Par défaut, tous les abonnements Azure (et leurs RG associés) sont inclus dans le scope d’Azure Advisor.

 

Filtrer vos abonnements Azure

Vous pouvez configurer vos filtres pour n’afficher que les recommandations proposées pour un abonnement spécifique.

Cela peut être configuré depuis « Répertoire + abonnement »

Dans l’exemple suivant, le filtre d’abonnement global Azure sera modifié pour sélectionner que l’abonnement « Microsoft Azure Sponsorship » :

Comme montré dans la Screenshot ci-dessus, l’abonnement sélectionné depuis « Répertoire + abonnement » est automatiquement configuré au niveau d’Azure Advisor. Notez que vous pouvez également configurer ce filtre depuis le Dashbord Azure Advisor, depuis la liste déroulante « Abonnements« .

 

Filtrer vos ressources Azure

Vous avez également la possibilité de filtrer les types de ressources Azure pour lesquels vous voulez afficher les recommandations Azure Advisor.

Dans l’exemple suivant, le filtre « Type de ressource > Machines Virtuelles » sera configuré. Les recommandations affichées depuis le Dashbord Azure Advisor concernent uniquement celles qui s’appliquent aux VMs Azure :

 

Grouper vos recommandations par Abonnement

Azure Advisor vous permet d’organiser les recommandations Azure Advisor par Abonnement.

Cela peut être configuré en sélectionnant l’option « Grouper par abonnement » :

Afficher les détails sur les recommandations Azure Advisor

Comme indiqué précédemment, pour obtenir plus d’informations sur les recommandations proposées par Azure Advisor, il faut se rendre dans l’onglet « Tous » ou sur l’onglet correspondant à une catégorie spécifique.

Cliquez sur une recommandation pour en savoir plus. Dans l’exemple suivant, je vais cliquer sur « Utiliser des groupes à haute disponibilité….« :

Les informations détaillées suivantes sont affichées :

  • La colonne « Machine Virtuelle« , liste les VMs impactées/concernées par la recommandation.
  • La colonne « Actions recommandées« , vous permet d’implémenter l’action recommandée (création d’AS dans notre exemple: Availability Set).
  • La colonne « Action » vous permet de reporter cette action ou de l’ignorer.

Dans mon cas, je peux simplement ignorer cette recommandation car il s’agit ici de VMs de Test/Demo.

En effet, un Groupe à haute disponibilité est plutôt destiné à des environnements de Production (Domain Controllers, SQL Server IaaS, ERP, Business App…etc).

 

Configurer la règle « Utilisation moyenne CPU » pour les VMs à analyser par Azure Advisor 

Par défaut, les VMs présentant une utilisation de <5 % CPU sont considérées comme étant « surdimensionnées », c’est la raison pour laquelle vous recevrez des recommandations vous indiquant des VMs sous-utilisées avec comme action « Redimensionnement Machine Virtuelle ». Si vous estimez que cette valeur est très basse, vous pouvez la modifier à tout moment en cliquant « Configurer » > « Règles » > sélectionnez l’abonnement concerné par cette modification > cliquez ensuite sur « Modifier« , enfin spécifier la valeur qui vous convient (<10% dans l’exemple suivant) :

 

Télécharger les rapports Azure Advisor 

Le service « Azure Advisor » vous offre la possibilité de télécharger les rapports des recommandations.

Deux types de rapports peuvent être générés :

  • Rapport au format PDF
  • Rapport au format CSV

Les rapports PDF sont présentables dans l’état, en revanche les rapports CSV doivent être formatés si vous devez les présenter à votre client ou votre responsable hiérarchique.

Voici un exemple de rapport CSV AzAdvisor format (Excel Data convertie)

Les rapports PDF générés ressemblent à l’image ci-dessous :

 

Azure Advisor : Pricing 

Azure Advisor est un service gratuit :).

Gérer Azure Advisor via Windows PowerShell

Je prépare actuellement un autre guide Step-by-Step sur l’utilisation d’Azure Advisor via Windows PowerShell (Az PowerShell Module).

Restez connectés :).

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

A bientôt,

#HK

Publicités

Liste des premiers modules « Gouvernance Azure »

Les deux premiers modules « Azure Naming Convention » et « Azure Locks » sont disponibles depuis les URLs suivantes :

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

[Azure Free Training] Lesson2 : Protégez vos ressources Azure, Appliquez des « Locks Azure »

 

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (Onprem) vers Azure et/ou construire de nouvelles architectures Azure (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 :

  • Convention de nommage (définition de vos naming standards pour vos ressources Azure)
  • Modèle de délégation (RBAC)
  • Policies (Stratégies Azure)
  • Tags (Azure Resources Tags)
  • Azure Locks
  • Subscrption Design (Nombre d’abonnements à créer..etc)
  • …Etc

 

Durant cette « Lesson 3 », nous allons découvrir la composante « Azure Tags » ou « Balises Azure » en Français.

Azure Tags vous permettent d’organiser, de manière logique les ressources Azure avec les propriétés que vous définissez. Les Tags deviennent très utiles lorsque vous devez organiser des ressources pour une meilleure gestion et/ou facturation (Billing) > eg : combine me coûte toutes les VMs de Production > il suffit de sélectionner toutes les VMs ayant comme Tag « Environnement=Production » pour le savoir :).

 

Step-by-step guide sur Azure Tags : Introduction & HowTo

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 :

  • Azure Policies
  • Azure RBAC
  • Azure Resources Groups

 

N’hésitez pas à vous abonner à mon Blog (ou à mon profil SlideShare) pour rester informé de toute nouvelle publication.

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

#HK

Premier module de la série « Gouvernance Azure »

Le premier Module de la série « Gouvernance Azure » > « Azure Naming Convention » est disponible depuis l’URL suivante :

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

 

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (Onprem) vers Azure et/ou construire de nouvelles architectures Azure (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 :

  • Convention de nommage (définition de vos naming standards pour vos ressources Azure)
  • Modèle de délégation (RBAC)
  • Policies (Stratégies Azure)
  • Tags (Azure Resources Tags)
  • Azure Locks
  • Subscrption Design (Nombre d’abonnements à créer..etc)
  • …Etc

 

Durant la « Lesson 2 », nous allons découvrir la composante « Azure Locks » ou « Verrous Azure » en Français.

Il s’agit d’une Feature de sécurité Azure qui vous permet de protéger vos abonnements, Groupes de Ressources ou encore des ressources Azure spécifiques contre la modification ou suppression accidentelle.

 

Step-by-step guide sur Azure Locks : Introduction & HowTo

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 Module : Azure Tags

La deuxième Module « Azure Tags » est disponible à cet URL :

[Azure Free Training] Lesson3 : Tout ce que vous devez savoir sur Azure Tags

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

A bientôt,

#HK

Introduction

RDP (Remote Desktop Protocol) est (par défaut) considéré comme un protocole vulnérable qui peut exposer votre infrastructure (voire tout votre S.I) à des risques assez importants, notamment :

  • Brute-Force Attack
  • DoS (Denial-of-Service) Attack
  • Encryption Attack
  • Man-in-The-Middle (MiTM) Attack

 

Vous exposerez également votre S.I à un risque de sécurité si vous êtes consommateur (Cloud Consumer) d’une solution/Application Cloud hébergée sur une infrastructure RDS distante : Multi-tenancy Risk.

Plusieurs Cloud Providers proposant des applications SaaS (Software-as-a-Service) virtualisées et distribuées (RemoteApp) via des Portail RD Web Access personnalisés. Ces Apps sont souvent hébergées sur des infrastructures RDS « Partagées /Shared », cela veut dire que plusieurs clients, se connectent et consomment les mêmes Apps Cloud RDS depuis le même environnement. Pour des raisons de réduction de coût, plusieurs Cloud Providers déploient des RD Session Host en mode « Shared », et proposent rarement des infrastructures RDS dédiées (Collections de Session RDS dédiées par client/app).

Malheureusement la plupart des clients ne pensent pas à poser la question et se contentent de signer un contrat désignant les responsabilités de chacun (SLA) : en mode SaaS vous êtes uniquement responsable de vos données, les couches infra/storage/middleware sont gérées par le CP, seul ce dernier est responsable de la gestion, maintenance, patching… de l’environnement Cloud.

En revanche, vous avez la responsabilité de s’assurer du niveau de sécurité offert à travers ces applis Cloud qui souvent font parties de votre IT globale car les devices clients depuis lesquels vos users se connectent sont souvent intégrés dans votre AD local et connectés au niveau de votre Coporate Network.

 

Guide de Sécurité RDS : Liste des Risques, Menaces et Bonnes Pratiques que vous connaître 

Je viens de publier sur Slideshare un Guide de sécurité RDS assez complet (en Anglais) traitant ce sujet.

Il décrit et détaille toutes les Security Risks, menaces ainsi que les bonnes pratiques que vous devez prendre en considération lors de la phase « Design » de tout projet RDS (de 2008 R2 à 2019).

Il vous liste également les Risks/Menaces liées à des infrastructures RDS Offsites (hébergées chez un Cloud Provider), si vous êtes Cloud Customer d’une ou plusieurs Apps Cloud, vous pouvez toujours challenger l’éditeur/Cloud Provider en posant les questions listées dans ce Slide.

Le document est disponible sur SlideShare, à cet URL.

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

Si vous souhaitez être accompagné, n’hésitez pas à me Ping via MP pour planifier un call et discuter plus en détail de votre projet.

Bonne lecture à tous,

#HK

Introduction

Le Portail Azure vous offre la possibilité de configurer les options de déconnexion automatique (Automatic Logout) après une certaine période d’inactivité.

Par défaut, une Session ouverte sur le Portail Azure n’expire jamais car le délai d’inactivité défini par défaut est « Jamais« .

Cette valeur doit obligatoirement être changée dès la première connexion car vous vous exposez à un risque assez important en laissant une Session ouverte qui n’expire jamais sur le Portail Azure.

HowTo : Configurer la déconnexion automatique du Portail Azure après une période d’inactivité !

La procédure est simple, connectez-vous sur le Portail Azure (https://portal.azure.com), et cliquez ensuite sur le bouton « Paramètres »

Sous « Me déconnecter lorsque je suis inactif« , sélectionnez le délai qui vous convient et cliquez ensuite sur « Appliquer »

Note : option recommandée par #HK est « Au bout de 15 minutes« . C’est toujours plus Secure qu’un délai d’inactivité d’une ou deux heures.

Configurez un délai d’inactivité « Personnalisé »

Sachez que vous pouvez définir un délai d’inactivité personnalisé (faisant pas parti de la liste par défaut proposée dans le Portail). Pour ce faire, il suffit de sélectionner « Durée personnalisée » et spécifier ensuite le délai d’inactivité (en HH et MM) qui vous convient le plus.

Dans l’exemple suivant, 3 heures a été spécifié comme délai personnalisé :

#HK

Hi All,

Suite à la réalisation de plusieurs missions (Consulting /Expertise Azure), j’ai pu constater que plusieurs clients se posent toujours la même question quant il s’agit de gérer les identités et accès aux applications Cloud.

The Question est la suivante :

Quelle est la différence entre une infrastructure AD (Windows Server Active Directory) traditionnelle, Azure Active Directory (AAD) et Azure Active Directory Domain Services (AADDS) ?

Si vous vous posez aussi la même question, eh bien sachez que vous êtes à la bonne adresse :).

Let’s see la différence !

 

First of all, définissons ce que c’est Windows Server Active Directory, Azure AD et Azure ADDS !

Windows Server Active Directory (ADDS)

ADDS pour Active Directory Domain Services (aka AD pour Active Directory) est un rôle natif fourni (par défaut) sur toute nouvelle installation de Windows Server, que ce soit en mode GUI (Graphical User Interface) ou en mode Core (Installation Minimale)

Le rôle ADDS vous permet de déployer un annuaire AD (Base de données AD : NTDS.dit) pour stocker et gérer de manière centralisée tous vos objets réseaux et sécurité : ordinateurs, utilisateurs, imprimantes, partages, GPOs…etc

Cet annuaire permet également de stocker et gérer les données relatives aux applications pouvant être intégrées dans un AD et l’interroger via LDAP.

A l’aide de GPOs (Group Policy Objects) de domaine, vous pouvez également centraliser la configuration, le paramétrage et la sécurisation de vos comptes utilisateurs et ordinateurs du réseaux.

ADDS représente la base (Backbone) d’un réseau Microsoft d’entreprise.

 

Azure Active Directory (Azure AD)

Azure Active Directory (aka AAD) est l’offre IDaaS (IDentity-asaService) proposé par Microsoft Azure.

AAD est une solution (service Cloud mutualisé >> Mulit-Tenant) de gestion des identités et des accès pour les applications (principalement WEB) hébergées et exécutées dans le Cloud Azure mais aussi celles hébergées dans vos Datacenters OnPrem(ise).

Je vous invite à regarder la vidéo suivante pour en savoir plus sur Azure AD :

La documentation complète sur Azure Active Directory est disponible à cet URL.

Azure Active Directory Domain Services (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 (DomainController-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, Manage et sécurise 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« 

 

Mais quelle est la différence entre un annuaire AD (traditionnel), un Azure AD et une instance Azure ADDS ?

Nous allons tout d’abord voir la différence entre Windows ADDS et Azure AD, car il s’agit des deux items souvent confondus par les clients.

Pour commencer, il faut toujours garder à l’esprit qu’un Azure AD n’est pas une solution remplaçante ou équivalente d’Active Directory dans le Cloud.

Quand on parle d’Active Directory (AD), on pense généralement à :

  • Forêt /Domaine (Root & Child) Active Directory
  • Contrôleurs de domaine (DC : Domain Controller) hébergés chez vous généralement et sur lesquels vous avez Full Control (qu’ils soient physiques ou virtuels).
  • Service d’annuaire qui a une structure hiérarchique basée sur X.500
  • Annuaire pouvant stocker de multiple type d’objet : utilisateurs, ordinateurs, imprimantes, GPOs, Sites AD, Partages…
  • Service DNS utilisé en tant que « Locator » de ressources réseaux (traduction d’@IP en Host et vice versa)
  • Annuaire pouvant être interrogé à l’aide du protocole LDAP (Lightweight Directory Access Protocol) ou LDAPS
  • Authentification via Kerberos/NTLM
  • Organisation des objets à l’aide d’OU (Organitional Unit)
  • Configuration des postes clients (Ordinateurs) et utilisateurs à l’aide de GPO (Group Policy Object)
  • Relation d’approbation entre deux ou plusieurs forêts/Domaine AD si ces dernières ont besoin de discuter et partager des ressources entre elles.

 

Un Azure AD quant à lui est :

  • Un service Cloud (IDaaS) : cela veut dire que Microsoft conçoit, déploie et gère toute l’infrastructure (mutualisée) hébergeant Azure AD. Et vous, en tant que « Cloud Customer », vous consommez et payer ce service de manière mensuelle (en fonction du nombre d’utilisateurs s’authentifiant à travers votre Azure AD).
  • Authentifie les utilisateurs aux niveaux des applications hébergées dans Azure ou celles hébergées chez vous OnPrem, via l’utilisation du service Azure AD Application Proxy.
  • L’authentification se fait via Internet : Azure AD s’appuie principalement sur une authentification over Internet (HTTP/80 ou HTTPS/433).
  • L’authentification ne se limite pas aux devices connectés sur le réseau Corporate de l’Entreprise mais plutôt to Any Device (vu que la communication avec un Azure AD se fait à l’aide des protocoles HTTP ou HTTPS, il suffit d’avoir un device connecté à Internet pour pouvoir communiquer avec un Azure AD.
  • Azure AD s’appuie quant à lui sur des protocoles dis « Modern Authentication Protocol » tels que OpenID Conncet /Oauth2 /SAML /WS-FEDERATION (Goodbye Kerberos & NTLM ^_^).
  • Contrairement à un Active Directory, Azure AD peut être interrogé via une interface REST API, appelée AD Graph API
  • Azure AD étant un service Cloud (IDentity-as-a-Service), vous n’avez pas la main sur l’infrastructure hébergeant cette solution IAM, il n’y pas de gestion de GPO possible, la création d’une structure d’OU n’est pas non plus disponible car il s’agit d’une structure Plate (Flat).
  • Azure AD stocke et gère uniquement les objets « Users » et « Groups » : pas de GPO, pas de partage réseau, pas de sites AD…etc
  • La manière dont les objets AD classiques (users, computers, partages, groupes….) sont stockés et gérés est complètement différente entre un AD et Azure AD :
    • AD : Structure Hiérarchique (Hierarchical Structure)
    • Azure AD : Structure plate (Flat Structure)

Les deux schémas suivants illustre les deux types de structures :

 

En ce qui concerne Azure ADDS, c’est ni plus ni moins qu’un Active Directory traditionnelle déployé et géré par Microsoft. Les mêmes caractéristiques liées à AD listées ci-haut s’appliquent également à un Azure ADDS, ce dernier s’appuie sur Kerberos/NTLM pour authentifier les utilisateurs du réseau, permet l’organisation des objets dans des OU et vous permet de créer et configurer des GPOs. Il existe tout de même certaines limitations relatives à un Azure ADDS :

  • Contrairement à un AD, Azure ADDS ne vous permet pas d’établir/créer de relations d’approbation entre plusieurs instances Azure ADDS.
  • Vous n’avez plus la main sur les comptes « Admins Entreprises » et « Admins du Schéma »
  • Et enfin, l’extension du schéma AD n’est pas possible sur un domaine (Managé) Azure ADDS.

 

Ce qu’il faut retenir !

Ce qu’il faut garder en tête :

Windows Server Active Directory (ou Services de Domaine Active Directory, ou encore Windows ADDS) est un rôle natif dans les plateformes Windows Server (from Windows Server 2000 :)). ADDS authentifie les utilisateurs via les protocoles Kerberos (ou NTLM), vous permet de créer tout type d’objet dans l’AD et les stocker dans des OUs. Ces objets peuvent être gérés à l’aide de GPO (User ou Computer).

Azure Active Directory (ou Azure AD, ou encore AAD), est une offre IDaaS (IDentity-as-a-Service) de Microsoft Azure, qui vous permet d’authentifier vos utilisateurs sur les applications Cloud (ou locales via l’utilisation d’Azure AD Application Proxy). Il peut héberger uniquement des objets « Utilisateurs » et « Groupes ». Ces objets peuvent être directement créés dans Azure AD (Cloud Only mode) ou récupérés depuis votre AD local via une synchronisation AD to AAD à l’aide de l’outil Azure AD Connect (Synchro Mode). Azure AD est conçu pour les Apps/Services Web, il s’appuie sur les protocoles Web Modernes tels que SAML /WS-FEDERATION /OAuth2…etc.

Quand vous déployez un Azure AD, vous êtes considérés comme un « Tenant » > Client Cloud

Votre Azure AD étant « Trusted » par défaut avec plusieurs annuaires (comme ceux de Facebook, Google..etc), vous pouvez automatiquement accéder à d’autres services Web en utilisant le même compte Azure AD (SSO by default).
Pour finir, il faut considérer Azure AD comme un « Federation Hub » car vous pouvez à tout moment « Trust » un autre Azure AD (d’autres clients/partenaires) et accéder à leurs ressources (et vice versa) en rien de temps !

Azure Active Directory Domain Services (ou Azure ADDS ou encore AADDS) est une offre DCaaS (DC-as-a-Service) de Microsoft Azure. Cette plateforme représente votre infrastructure AD locale dans Azure, la différence réside dans le fait que c’est Microsoft (le Cloud Provider) qui créé, déploie, gère et sécurise les Contrôleurs de domaine pour vous. Il s’agit d’une instance « Standalone » d’une forêt AD isolée et déconnectée de votre réseau local. Si vous avez des contraintes de sécurité relatives à la réplication de votre AD local vers Azure (vers des DCs hébergés sous forme de VMs Azure), l’offre Azure ADDS peut être une solution à adopter pour créer rapidement une nouvelle forêt dédiée pour Azure, pour authentifier (via Kerberos/NTLM) vos utilisateurs/machines Windows hébergés dans Azure. Azure ADDS reste aussi le meilleur compromis (Sécu, Réduction de coût /Réduction des efforts liés aux MCO) quand il s’agit de migrer des plateformes/locales Apps « Legacy » vers Azure et donc faire du Lift-and-Shift (ou As-Is) Migration.

 

That’s All,

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