Archives de la catégorie ‘Azure Security’

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

Publicités

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

La fonctionnalité tant attendue voit enfin le jour : Prise en charge de l’authentification Azure AD par le stockage Azure 🙂

Eh oui, vous pouvez désormais vous appuyez sur votre service Azure AD pour authentifier, gérer et contrôler les accès à vos données hébergées au niveau des comptes de stockage Azure, et plus précisément dans Azure Blobs et Azure Queue (File d’attente Azure).

Je vous laisse consulter cet article pour en savoir plus.

Cette feature est encore en mode « Public Preview » mais selon les informations que j’ai pu échangé avec MS Corp, la GA ne devrait pas tarder so stay tuned :).

Hello Azure Guys,

Great News !!

L’équipe Azure Corp a annoncé aujourd’hui la disponibilité générale du Service « Azure Health Service », good news non 🙂 ?

Petit rappel sur ASH

Microsoft Azure Service Health vous permet de créer des tableaux de bord (Dashbords) personnalisés qui vous fournissent des informations pertinentes sur les éventuels problèmes détectés liés à vos ressources Cloud déployées. Ces informations comprennent des « Guidances & Support & Liens vers des Fix ».

Contrairement à la page publique « Statut » qui remonte plus des informations générales sur les services Azure, Azure Service Health vous remonte des informations personnalisées en fonction de ce que aurez défini au niveau des alertes de journal d’activité (Activity Log alerts). De plus, ASH vous aide à préparer/planifier votre maintenance et autres changements qui peuvent impacter la disponibilité de vos ressources Azure.

HowTo : créer vos alertes de journal d’activité 

Toutes les instructions sont détaillées ici.

Azure Health Service « In Action »

Je vous invite à consulter la vidéo ci-dessous pour en savoir plus sur Azure Service Health :

 

 

Useful Info : Si vous n’avez pas encore consulté les 6 premiers HowTo Azure CLI 2.0, ceux-ci sont disponibles aux URLs ci-après:

HowTo #N°1 : Connecter l’interface Azure CLI 2.0 à votre abonnement Azure

HowTo #N°2 : Créer et gérer les groupes de ressources Azure

HowTo #N°3 Créer et gérer les réseaux virtuels Azure (VNET : Virtual Network)

HowTo #N°4 Créer et gérer les Machines Virtuelles Azure (Azure VM)

HowTo #N°5 : Gérer la facturation Azure (Azure Billing)

HowTo #N°6 Créer et gérer vos comptes de Stockage Azure

 

Introduction

Azure NSG (Network Security Groups) ou Groupes de Sécurité Réseau vous permettent de contrôler (autoriser ou refuser) le trafic entrant et sortant depuis et vers vos ressources Azure.

Les NSG sont basées sur des listes de règles de sécurité que vous créez/définissez manuellement. Notez que lors de la création d’un NGS, des règles par défaut sont générées automatiquement pour sécuriser certains trafics réseaux. Ces règles peuvent être bypassées en mettant en place des règles personnalisées.

Tip : Je vous invite à consulter cet article pour en savoir plus sur les NSG, leur fonctionnement et leur limitation.

 

La création d’un Groupe de Sécurité Réseau (NSG) peut se faire via :

Le nouveau portail Azure : portal.azure.com

Windows PowerShell : utilisation du module PS Azure

Azure CLI 2.0 : via l’utilisation de la commande az network nsg

 

Nous allons découvrir à travers cet article la troisième méthode qu’est l’utilisation de l’interface Azure CLI 2.0

Now let’s create & manage our Azure NSG via Azure CLI 2.0__O

 

HowTo : créer et gérer vos Groupes de Sécurité Réseau Azure (NGS)

Tout d’abord, je vous invite à saisir az network nsg -h pour en savoir plus sur les sous-commandes disponibles :

Pour lister tous les NSG existants, saisissez la commande suivante : az network nsg list 

Tip : pour une meilleure visibilité de la commande output, saisissez az network nsg list –out table

Commencez par créer un groupe de Ressource 

Azure ARM (Azure Resource Manager) introduit le concept des Groupes de ressources (RG : Resource Group). Ces derniers font office de « Conteneur » pour grouper et gérer les ressources Azure de manière centralisée.

Dans notre cas, nous allons créer un groupe de ressource pour regrouper les différents NSG Azure que nous allons créer par la suite.

Exécutez donc la commande suivante pour créer un nouveau groupe de ressource (nommé hk-demo-howto7) au niveau de la région Europe de l’Ouest (WestEurope)

az group create -n hk-demo-howto7 -l WestEurope

Maintenant que notre Groupe de Ressource est créé, nous allons créer notre premier Groupe de Sécurité Réseau Azure. Pour ce faire, exécutez la commande suivante (NSG nommé hk-demo-nsg dans l’exemple suivant) :

az network nsg create -n hk-demo-nsg -l WestEurope -g hk-demo-howto7

Vous pouvez également ajouter des « Tags » à vos NSG lors de leur création, dans l’exemple suivant nous allons créer un nouveau NSG Taggé « very_secure_network » :

az network nsg create -n hk-demo-nsg-vsecure -l WestEurope -g hk-demo-howto7 –tags very_secure_perimeter no_80 no_22 no_21

Pour afficher des informations détaillées sur un NSG spécifique, la commande suivante est à exécuter (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg show -n hk-demo-nsg-vsecure -g hk-demo-howto7

Enfin, si vous souhaitez supprimer un NSG, exécutez la commande suivante (hk-demo-nsg-vsecure dans l’exemple suivant) :

az network nsg delete -n hk-demo-nsg-vsecure -g hk-demo-howto7

Plusieurs HowTo Azure CLI (N°8/9 et 10) arrivent bientôt, so let’s keep in touch :).

A bientôt

#HK

Hi Azure Guys,

Microsoft a récemment publié un guide complet détaillant toutes les bonnes pratiques liées à la Sécurité Azure, cela comprend :

 

Je vous invite à consulter les liens ci-dessus et prendre connaissance de toutes les Security considerations & options lors de la phase « Design » de votre projet Cloud Azure.

Source : https://docs.microsoft.com/en-us/azure/security/security-best-practices-and-patterns