Partager via

Intégrité de l’infrastructure Azure

  • Article

Installation de logiciels

Tous les composants de la pile de logiciels installés dans l’environnement Azure sont conçus de manière personnalisée conformément au processus Microsoft Security Development Lifecycle (SDL). Tous les composants logiciels, notamment les images de système d’exploitation et SQL Database, sont déployés dans le cadre du processus de gestion des modifications et des versions. Le système d’exploitation exécuté sur tous les nœuds est une version personnalisée. La version exacte est choisie par le contrôleur de structure en fonction du rôle qu’il a l’intention d’attribuer au système d’exploitation. De plus, le système d’exploitation hôte n’autorise pas l’installation de composants logiciels non autorisés.

Certains composants Azure sont déployés en tant que clients Azure s’exécutant sur une machine virtuelle invitée sur un système d’exploitation invité.

Analyses antivirus sur les builds

Les builds de composants logiciels Azure (notamment le système d’exploitation) doivent subir une analyse antivirus à l’aide de l’outil de protection antivirus Endpoint Protection. Chaque analyse antivirus crée un journal dans le répertoire de build associé, détaillant ce qui a été analysé et les résultats de l’analyse. L’analyse antivirus fait partie du code source de build pour chaque composant dans Azure. Le code ne peut pas passer en production sans avoir fait l’objet d’une analyse antivirus n’ayant révélé aucun problème. Si des problèmes sont détectés, la build est figée. La build est alors transmise aux équipes de sécurité au sein de Microsoft Security afin qu’elles identifient le point d’entrée du code « non autorisé » dans la build.

Environnement fermé et verrouillé

Par défaut, aucun compte d’utilisateur n’est créé sur les nœuds d’infrastructure Azure et les machines virtuelles invitées. Les comptes d’administrateur Windows par défaut sont également désactivés. Les administrateurs d’Azure Live Support peuvent, avec une authentification appropriée, se connecter à ces machines et administrer le réseau de production Azure à des fins de réparation d’urgence.

Authentification Azure SQL Database

Comme avec toute implémentation de SQL Server, la gestion des comptes utilisateur doit être contrôlée étroitement. Azure SQL Database prend uniquement en charge l’authentification SQL Server. Des mots de passe à la sécurité élevée et configurés avec des droits spécifiques doivent aussi être utilisés afin de compléter le modèle de sécurité des données du client.

Listes ACL et pare-feux entre le réseau d’entreprise Microsoft et un cluster Azure

Les listes de contrôle d'accès (ACL) et les pare-feux entre la plateforme de service et le réseau d’entreprise Microsoft protègent les instances SQL Database contre tout accès interne non autorisé. En outre, seuls les utilisateurs compris dans les plages d’adresses IP du réseau d’entreprise Microsoft peuvent accéder au point de terminaison de gestion de plateforme Windows Fabric.

Listes ACL et pare-feux entre les nœuds dans un cluster SQL Database

Dans le cadre de la stratégie de défense en profondeur, des listes ACL et un pare-feu ont été implémentés entre les différents nœuds d’un cluster SQL Database. Toutes les communications au sein du cluster de plateforme Windows Fabric ainsi que tout le code en cours d’exécution sont approuvés.

Exemple de surveillance personnalisée

SQL Database utilise des agents de gestion (MA) personnalisés appelés « agents de surveillance » afin de surveiller l’intégrité du cluster SQL Database.

Protocoles web

Surveillance et redémarrage des instances de rôle

Azure s’assure que tous les rôles déployés et activés (rôles avec accès à Internet ou rôles de worker de traitement back-end) font l’objet d’un monitoring continu de l’intégrité. Le monitoring de l’intégrité garantit que ces rôles fournissent avec efficacité et efficience les services pour lesquels ils ont été provisionnés. Dans le cas où un rôle perdrait son intégrité, suite à une défaillance critique de l’application hébergée ou à un problème de configuration sous-jacent au sein de l’instance de rôle proprement dite, le contrôleur de structure détectera le problème au sein de l’instance de rôle et lancera un état correctif.

Connectivité de calcul

Azure garantit que l’application/service déployé(e) est accessible par le biais de protocoles web standards. Les instances virtuelles de rôles web orientés vers Internet disposeront d’une connectivité Internet externe et seront accessibles directement par les utilisateurs web. Afin de protéger la confidentialité et l’intégrité des opérations effectuées par les rôles de worker pour le compte des instances virtuelles de rôles web accessibles publiquement, les instances virtuelles des rôles de worker de traitement back-end disposent d’une connectivité Internet externe mais ne sont pas accessibles directement par un utilisateur web externe.

Étapes suivantes

Pour en savoir plus sur ce que Microsoft fait pour sécuriser l’infrastructure Azure, consultez :