Archives de la catégorie ‘Azure Security’

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 :).

Publicités

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

 

Suite à la réalisation de plusieurs audits Azure chez différents clients grand comptes (Banques, Assurances, …etc), j’ai pu constaté que la plupart de leurs DC (Domain Controllers AD) hébergés dans le Cloud Azure (sous forme de VM Azure : mode Infra-as-aService), n’ont pas été Setupés, configurés et protégés correctement.

Plusieurs « Best Practices » relatives à l’exécution des Domain Controllers sur Azure (VM) sont souvent « oubliés » et rarement pris en considération lors de la phase « Build/Implementation ».

Si vous avez décidé d’étendre votre infrastructure AD vers Azure, je vous invite à prendre connaissance des items détaillés ci-dessous avant de vous lancer dans la création/build de VMs DCs.

Note : Le terme « Étendre » ici fait référence à un nouveau site distant (Site Active Directory) qui sera simplement le VNET/Subnet Azure et non pas la synchronisation d’annuaires : AD to AAD (Azure AD).

 

Liste des « Best Practices » que vous devez connaître avant de déployer vos DCs sur Azure (VM)
  • #1 : Tout d’abord, bien lire le guide « Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines » proposé par MS. Ce document vous détaille et explique bien la différence entre le déploiement d’infrastructure AD OnPrem (Infra AD traditionnelle) et le déploiement des Contrôleurs de domaine sur Azure (sur VM, connectées à des VNET/Réseaux Virtuels Azure). Je vous invite à prendre le temps de lire et comprendre tous les items détaillés dans cet article.
  • #2 : Déployez au moins deux Contrôleurs de domaine AD (2 VMs Azure)
  • #3 : Créez un Groupe à Haute Disponibilité (Availability Set) et placez-y vos Contrôleurs de domaine (au moins 2 DCs) : consulter cet article pour en savoir plus.
  • #4 : Déployez des Contrôleurs de domaine en mode « Core » plutôt qu’en mode GUI (Graphical User Interface)
    • HK Recommendation : pensez à déployer des DCs en mode Core avec un full remote management (via RSAT depuis un Bastion Environnement). Si vous déployez encore des DC sous Windows Server 2012 ou 2012 R2, vous pouvez déployer des DCs en mode MSI (Core + Minimal Server Interface > All GUI Tools)
      • Note : je vous invite à consulter cet article pour en savoir plus sur les différents modes : GUI | MSI | Core
  • #5 : Déployez des RODC (Read-Only Domain Controller) plutôt que des WDC (Writable Domain Controller)
    • Note importante : avant de déployer des RODC, vérifiez que vous Applications (à intégrer dans l’AD) supportent bien ce type de DC. Si vos Apps ont besoin d’écrire dans la base AD, déployez plutôt des WDC. Je vous invite à consulter cet article si vous avez besoin de tester la comptabilité de vos applications avec le RODC.
  • #6 : Ensuite, (TRES, TRES IMPORTANT), configurez des @IP Statiques sur vos DCs, cela doit se faire via le Portail Azure, PowerShell ou Azure CLI (depuis les Propriétés de la NIC de la VM DC) et non pas via les propriétés TCP/IP v4 de la Guest NIC :
    • Tips : vous pouvez configurer l’adresse IP (Statique) sur vos DCs via :
      • Le Portail Azure : consulter cet article pour en savoir plus.
      • Windows PowerShell [Module PS Azure] : consulter cet article pour en savoir plus.
      • Azure CLI [commande az vm]: consulter cet article pour en savoir plus.
  • #7 : Créer/Utiliser un Compte de Stockage Azure dédié pour stocker les vDisks (VHD) des Domain Controllers
  • #8 : En plus du vDisk OS créé/attaché à la VM automatiquement lors de sa création/provisioning, il est important de créer/attacher un nouveau vDisk à la VM DC (Data Disk) pour y stocker/placer la base de données AD, Fichiers Logs,SYSVOL 
  • #9 NE JAMAIS configurer de « Host Cache Prerence », lors de l’ajout du nouveau vDisk DATA (Disque de données pour AD Database, Logs & SySVOL), choisissez « None » comme valeur.
  • #10 : Utiliser les fonctionnalités RBAC (Role-Based Access Control /Contrôle d’accès en fonction du rôle) pour limiter/contrôler QUI doit ACCEDER/GERER le compte de Stockage and les clés d’accès
  • #11 : Activer le chiffrement de disque Azure (Azure Disk Encryption) avec une clé de chiffrement (KEK : Key Encryption key) pour les disques systèmes (OS vDisk) mais aussi les disques de données (Data vDisk). Azure Key Vault sera utilisé pour stocker les clés, il doit être déployé/hébergé dans la même Région & Abonnement Azure
  • #12 : Même chose pour Le coffre Key Vault, pensez à définir/implémenter une stratégie RBAC pour limiter l’accès au Key Vault stockant vos clés.
  • #13 : A l’aide d’un NSG (Network Security Group), créez et configurer des règles pour :
    • Autoriser que le traffic « Entrant » requis (Ports requis) pour les Domain Controllers
    • Refuser tout autre traffic
  • #14 : Implémentez des règles AppLocker pour autoriser que les .EXE, scripts… requis/utilisés par les DCs
  • #15 : NE JAMAIS créer/définir une @IP public pour les VMs faisant office de Domain Controllers.
  • #16 : Et bien évidemment, ne jamais activer le RDP (Remote Desktop Protocol) sur les DCs, pour réduire la surface d’attaque, et puis, on est d’accord, ce sont des DCs et non pas des serveurs RDS ou Citrix XA :).
  • #17 : Déployer et configurer l’agent Antimalware (en suivant votre standard OnPrem)
  • #18 : Déployer et configurer l’agent de monitoring (en suivant votre standard OnPrem)
  • #19 : Si votre architecture réseau le permet, implémentez une IPSec Policy pour sécuriser les communications entre vos DCs OnPrem et ceux sur Azure.
  • #20 : Et enfin, veillez à bien documenter toutes les options/fonctionnalités de sécurité implémentées, ainsi que toute modification apportée, cela vous permettra d’identifier les effets de bord/impacts post-implémentation d’une ou plusieurs Security Features spécifiques. e.g : mauvaise implémentation d’IPSec peut avoir un impact sur toute la communication inter-site (deny any<>any by default).

A bientôt, Keep in touch :).

#HK | Another IT Guy

Vous êtes clients Microsoft Azure ? Alors ce post est un « Must-Read » :

https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/

 

Resource Manager « Locks », qu’est ce que c’est ?!

Le modèle de déploiement ARM (Azure Resource Manager) inclut une fonctionnalité qui va sûrement intéresser les IT en charge d’administrer et de sécuriser les services et ressources Azure : il s’agit de « Resource Manager Locks »

Ces verrous vous permettent de protéger vos ressources Azure jugées « Critiques » en mettant en place des règles de restrictions pour empêcher toute modification et/ou suppression accidentelle. Les Locks Resource Manager n’ont aucun rapport avec une hiérarchie RBAC (Role-Based Access Control) car une fois appliqués, ils positionnent des restrictions sur la ressource pour TOUS les utilisateurs. Cela devient très utile quand vous souhaitez protéger des « Ressources Azure Critiques » contre toute modification ou suppression, même accidentelle.

Notez qu’il existe deux niveaux de verrouillage, à savoir :

  • CanNotDelete : ce niveau empêche tous les utilisateurs de supprimer la(es) ressource(s) Azure sur la(es) quelle(s) le verrou est activé. Les ressources Azure restent en revanche accessibles en lecture et peuvent être modifiée à tout moment.
  • ReadOnly : ce niveau rend les ressources Azure accessibles en « Lecture seule » uniquement. Les utilisateurs ne peuvent donc ni modifier ni supprimer la(s) ressource(s) sur la(es) quelle(s) le verrou est activé. Appliquez ce niveau de verrouillage a le même effet /impact que d’attribuer le rôle « Lecteur » à vos utilisateurs, en effet, les mêmes autorisations accordées par le rôle « Lecteur » sont appliquées via le Lock « ReadOnly ».

Les « Locks » Resource Manager peuvent être appliqués aux :

  • Abonnements (Azure Subscriptions)
  • Groupes de Ressources (Azure Resources Group)
  • Ressources (Azure Resources)

Note importante : quand vous appliquez un verrou au niveau d’un abonnement, toutes les ressources placées dans cet abonnement (y compris celles que vous créerez plus tard) héritent le même niveau de verrouillage. De plus, et contrairement au RBAC, une fois appliqués, les Locks impactent tous les utilisateurs, quelque soit leur rôle. Donc, si la modification ou suppression d’une ressource (déjà Lockée) devient vraiment nécessaire, vous devrez d’abord supprimer le verrou associé à la ressource avant de la modifier ou la supprimer.


Les Permissions : ce que vous devez connaître !

Les permissions qui vous permettent de créer et supprimer les verrous nécessitent l’accès à l’une des permissions RBAC suivante :

  • Microsoft.Authorization/*
  • Microsoft.Authorization/locks/*

Par défaut, ces actions /permissions sont prédéfinies pour les rôles « Owner /Propriétaire » et « User Access Administrator /Administrateur de l’accès Utilisateur ». Si nécessaire, vous pouvez les ajouter à des rôles spécifiques /personnalisés.

 

Logs /Traçabilité 

Les opérations de « Création & Suppression » de verrous sont (par défaut) inscrites dans les Journaux d’Activité Azure (Azure Activité Logs).

Les utilisateurs qui tente de supprimer ou modifier une ressource ayant un « Lock » déjà en place recoivent le message d’erreur suivant :

Au niveau du New Azure Portal (portal.Azure.com) :

Au niveau de l’interface Azure CLI, l’Admin IT reçoit le message suivant :

The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’ cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

Même chose côté PowerShell, le message d’erreur suivant est retourné à l’Admin IT :

Remove-AzureRmResource : ScopeLocked : The scope ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c/resourceGroups/hk-dev-rg/providers/Microsoft.Storage/storageAccounts/hkcriticalstorage1’
cannot perform delete operation because following scope(s) are locked: ‘/subscriptions/31854640-1004-4040-81fc-be333f3cef5c’. Please remove the lock and try again.

 

HowTo : Créer vos « Verrous /Locks »

Les « Locks » Resource Manager peuvent être créés soit au moment de la création de la ressource (au niveau du Template ARM) ou ultérieurement via le nouveau portal Azure (portal.Azure.com), Windows PowerShell ou encore l’interface en ligne de commande (Az CLI 2.0).

Création des « Locks » lors de la création d’une Ressource

La création de Verrous lors de la configuration du Template ARM est le meilleur moyen de s’assurer que votre protection est bien place une fois vos ressources Azure créées /provisionnées.

Les Verrous sont des ressources ARM de « Haut Niveau », ils ne font pas partis de la configuration (sous-couche) des ressources Azure mais plutôt référence à la (aux) ressource(s) à verrouiller, celles-ci doivent donc d’abord exister pour pouvoir créer des « Locks ».

Dans l’exemple suivant, nous allons créer un compte de stockage nommé hkcriticalstorage1 et ensuite verrouiller cette ressource contre la suppression. Notez que le paramètre « Type » fait référence au type de ressource que vous voulez « Verrouiller ».

 

{
« type »: « Microsoft.Storage/storageAccounts »,
« name »: « hkcriticalstorage1 »,
« apiVersion »: « 2015-01-01 »,
« location »: « [resourceGroup().location] »,
« tags »: {
« displayName »: « hkcriticalstorage1 »
},
« properties »: {
« accountType »: « Standard_LRS »
}
},
{
« name »: « [concat(‘hkcriticalstorage1’, ‘/Microsoft.Authorization/criticalStorageLock’)] »,
« type »: « Microsoft.Storage/storageAccounts/providers/locks »,
« apiVersion »: « 2015-01-01 »,
« properties »: {
« level »: « CannotDelete »
}
}
]

 

Le niveau de verrouillage peut être défini à « ReadOnly » simplement en changeant la valeur du paramètre « Level » et la définissant à ReadOnly

Création des « Locks » via le Portail Azure

Comme expliqué précédemment, les verrous s’appliquent à différent niveau : abonnement, groupe de ressource ou encore à des ressources individuelles.

Pour ajouter un « Lock », il suffit de sélectionner l’objet sur lequel vous souhaitez l’appliquer, et cliquez (depuis le volet gauche) sur :

Verrous (ou Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Groupe de Ressources ou une Ressource individuelle

 

 

 

 

Verrous de ressources (ou Resource Locks si votre portail Azure est en En« glish ») : s’il s’agit d’un Abonnement Azure

 

 

 

 

 

 

Dans l’exemple suivant, nous allons ajouter un « Lock » au niveau de mon abonnement (Visual Studio Premium avec MSDN) en spécifiant les informations suivantes :

  • Nom du Verrou : hk-subscription-lock-del(etion)
  • Type de verrou : Supprimer
  • Remarques : Ce Verrou permet d’empêcher tout utilisateur de supprimer les ressources de l’abonnement Azure « VS Prem MSDN » de HK

Pour ce faire, il faut simplement cliquer sur « Verrous de ressources » > Ajouter > et spécifier ensuite les informations de configuration:

Pour confirmer que les ressources Azure hébergées au niveau de l’abonnement héritent bien ce « Lock » nouvellement créé, cliquez sur n’importe quelle ressource de l’abonnement et rendez-vous ensuite sur « Verrous » ou « Locks », constatez l’apparition du « Lock », précédemment créé :

Création des « Locks » via Windows PowerShell

Le code PS ci-après peut être utilisé pour ajouter un « Lock » à une ressource existante. Encore une fois, le type de ressource (paramètre ResourceType) dépend du type de la ressource que vous souhaitez verrouiller.

Pour supprimer le Verrou, vous devez utiliser la Cmd-let Remove-AzureRmResourceLock.

 

Création des « Locks » via Azure CLI 2.0

Note : si vous n’avez pas encore connecter votre Interface Azure CLI 2.0 à votre compte Azure, je vous invite à consultez cet article.

La commande qui vous permet de créer et gérer les « Verrous » est : Az Lock

Depuis l’interface CLI 2.0, saisissez Az Lock -h pour faire apparaître l’aide en ligne de cette commande :

Pour créer un « Lock » de type « ReadOnly » et l’appliquer au niveau de votre abonnement Azure, la commande suivante est utilisée :

az lock create –name criticalStorageLock –resource-group hk-criticalstorage-rg –lock-type ReadOnly

Je vous invite à consulter cet article très bien rédigé par l’équipe MS Azure pour en savoir plus sur toute la syntaxe et paramètre disponibles avec la commande Az Lock.

 

Ce qu’il faut retenir

Notez que les Locks permettent seulement la protection contre toute suppression ou modification accidentelle des ressources Azure « Critiques », ceux-ci ne permettent pas une restriction totale car les Admins Azure peuvent facilement supprimer les verrous et récupérer les droits de « Supprimer et/ou Modifier » les ressources Azure.

Perso, je considère les Locks comme une couche de protection supplémentaire des ressources Azure car, ils s’appliquent à TOUS les utilisateurs, quelque soit leur rôle (hiérarchie RBAC), cela permettra donc une amélioration de la sécurité /protection de l’infrastructure Cloud, Azure.

What Next ?

Je vous laisse créer et tester vos new Resource Manager Locks sur vos ressources Azure et me faire part de votre feedback pour cette fonctionnalité.

Restez connecté, plusieurs articles autour de l’Azure sont en cours de finalisation et verront le jour très prochainement sur mon blog :).

A bientôt.