Base de référence de sécurité Azure pour Azure Database pour PostgreSQL – Serveur unique

Cette base de référence de sécurité applique les instructions du Benchmark de sécurité Azure version 1.0 à Azure Database pour PostgreSQL - Serveur unique. Le benchmark de sécurité Azure fournit des recommandations sur la façon dont vous pouvez sécuriser vos solutions cloud sur Azure. Le contenu est regroupé selon les contrôles de sécurité définis par le benchmark de sécurité Azure et les instructions associées applicables à Azure Database pour PostgreSQL - Serveur unique.

Vous pouvez surveiller cette base de référence de sécurité et ses recommandations à l’aide de Microsoft Defender pour Cloud. Azure Policy définitions seront répertoriées dans la section Conformité réglementaire du tableau de bord Microsoft Defender pour Cloud.

Lorsqu’une section a des définitions Azure Policy pertinentes, elles sont répertoriées dans cette ligne de base pour vous aider à mesurer la conformité aux contrôles et recommandations azure Security Benchmark. Certaines recommandations peuvent nécessiter un plan Microsoft Defender payant pour activer certains scénarios de sécurité.

Notes

Les contrôles non applicables à Azure Database pour PostgreSQL - Serveur unique, ou dont la responsabilité incombe à Microsoft, ont été exclus. Pour voir comment s’effectue le mappage intégral d’Azure SQL pour PostgreSQL - Serveur unique au benchmark de sécurité Azure, consultez le fichier de mappage complet de la base de référence de sécurité Azure SQL pour PostgreSQL - Serveur unique .

Sécurité réseau

Pour plus d’informations, consultez Benchmark de sécurité Azure : sécurité réseau.

1.1 : Protéger les ressources Azure au sein des réseaux virtuels

Aide : Configurer Private Link pour Azure Database pour PostgreSQL avec des points de terminaison privés Private Link vous permet de vous connecter à différents services PaaS dans Azure par le biais d’un point de terminaison privé. Azure Private Link intègre essentiellement les services Azure à votre Réseau virtuel privé. Le trafic entre votre réseau virtuel et l’instance PostgreSQL transite par le réseau principal de Microsoft.

Vous pouvez également utiliser des points de terminaison de service de réseau virtuel pour protéger et limiter l’accès réseau à vos implémentations Azure Database pour PostgreSQL. Les règles de réseau virtuel désignent une fonctionnalité de sécurité de pare-feu qui permet de contrôler si votre serveur Azure Database pour PostgreSQL doit accepter ou non les communications provenant de sous-réseaux spécifiques dans des réseaux virtuels.

Vous pouvez aussi sécuriser votre serveur Azure Database pour PostgreSQL avec des règles de pare-feu. Le pare-feu du serveur empêche tout accès à votre serveur de base de données jusqu’à ce que vous ayez spécifié les ordinateurs qui disposent d’autorisations. Pour configurer votre pare-feu, vous créez des règles de pare-feu qui spécifient les plages d’adresses IP acceptables. Vous pouvez créer des règles de pare-feu au niveau du serveur.

Responsabilité : Customer

Monitoring de Microsoft Defender pour le cloud : le benchmark de sécurité Azure est l’initiative de stratégie par défaut de Microsoft Defender pour le cloud et constitue la base des recommandations de Microsoft Defender pour le cloud. Les définitions Azure Policy associées à ce contrôle sont activées automatiquement par Microsoft Defender pour le cloud. Les alertes liées à ce contrôle peuvent nécessiter un plan Microsoft Defender pour les services associés.

Définitions intégrées à Azure Policy – Microsoft.DBforPostgreSQL :

Nom
(Portail Azure)
Description Effet(s) Version
(GitHub)
Le point de terminaison privé doit être activé pour les serveurs PostgreSQL Les connexions des points de terminaison privés permettent de sécuriser les communications en rendant la connectivité à Azure Database pour PostgreSQL privée. Configurez une connexion de point de terminaison privé pour autoriser l’accès uniquement au trafic provenant de réseaux connus et empêcher l’accès à partir de toutes les autres adresses IP, y compris dans Azure. AuditIfNotExists, Désactivé 1.0.2

1.2 : Superviser et journaliser la configuration et le trafic des réseaux virtuels, des sous-réseaux et des interfaces réseau

Aide : Quand votre instance Azure Database pour PostgreSQL est sécurisée sur un point de terminaison privé, vous pouvez déployer des machines virtuelles dans le même réseau virtuel. Vous pouvez utiliser un groupe de sécurité réseau pour réduire le risque d’exfiltration de données. Activez les journaux de flux NSG et transférez-les vers un compte de stockage pour l'audit du trafic. Vous pouvez aussi envoyer ces journaux vers un espace de travail Log Analytics et utiliser Traffic Analytics pour fournir des insights sur le flux de trafic dans votre cloud Azure. Parmi les avantages de Traffic Analytics figure la possibilité de visualiser l’activité réseau et d’identifier les zones réactives, d’identifier les menaces de sécurité, de comprendre les modèles de flux de trafic et de repérer les mauvaises configurations du réseau.

Responsabilité : Customer

1.4 : Refuser les communications avec des adresses IP connues comme étant malveillantes

Aide : Utiliser Advanced Threat Protection pour Azure Database pour PostgreSQL. Advanced Threat Protection détecte les activités anormales indiquant des tentatives d’accès ou d’exploitation inhabituelles et potentiellement dangereuses de vos bases de données.

Activez la protection DDoS standard sur les réseaux virtuels associés à vos instances Azure Database pour PostgreSQL pour vous protéger contre les attaques DDoS. Utilisez la fonctionnalité de renseignement sur les menaces intégrée à Microsoft Defender pour le cloud afin de refuser les communications avec des adresses IP Internet connues comme étant malveillantes ou inutilisées.

Responsabilité : Customer

1.5 : Enregistrer les paquets réseau

Aide : Quand votre instance Azure Database pour PostgreSQL est sécurisée sur un point de terminaison privé, vous pouvez déployer des machines virtuelles dans le même réseau virtuel. Vous pouvez ensuite configurer un groupe de sécurité réseau pour réduire le risque d’exfiltration de données. Activez les journaux de flux NSG et transférez-les vers un compte de stockage pour l'audit du trafic. Vous pouvez aussi envoyer ces journaux vers un espace de travail Log Analytics et utiliser Traffic Analytics pour fournir des insights sur le flux de trafic dans votre cloud Azure. Parmi les avantages de Traffic Analytics figure la possibilité de visualiser l’activité réseau et d’identifier les zones réactives, d’identifier les menaces de sécurité, de comprendre les modèles de flux de trafic et de repérer les mauvaises configurations du réseau.

Responsabilité : Customer

1.6 : Déployer des systèmes de détection et de prévention d’intrusion (IDS/IPS) basés sur le réseau

Aide : Utiliser Advanced Threat Protection pour Azure Database pour PostgreSQL. Advanced Threat Protection détecte les activités anormales indiquant des tentatives d’accès ou d’exploitation inhabituelles et potentiellement dangereuses de vos bases de données.

Responsabilité : Customer

1.8 : Réduire la complexité et les frais administratifs liés aux règles de sécurité réseau

Aide : Pour les ressources qui doivent accéder à vos instances Azure Database pour PostgreSQL, utilisez des étiquettes de service de réseau virtuel afin de définir des contrôles d’accès réseau sur des groupes de sécurité réseau ou le pare-feu Azure. Vous pouvez utiliser des balises de service à la place des adresses IP spécifiques lors de la création de règles de sécurité. En spécifiant le nom de l’étiquette de service (par exemple SQL.WestUs) dans le champ de source ou de destination approprié d’une règle, vous pouvez autoriser ou refuser le trafic pour le service correspondant. Microsoft gère les préfixes d’adresse englobés par la balise de service et met à jour automatiquement la balise de service quand les adresses changent.

Remarque : Azure Database pour PostgreSQL utilise l’étiquette de service « Microsoft.Sql ».

Responsabilité : Customer

1.9 : Gérer les configurations de sécurité standard pour les périphériques réseau

Conseils : Définissez et implémentez des configurations de sécurité standard pour les paramètres réseau et les ressources réseau associées à vos instances Azure Database pour PostgreSQL avec Azure Policy. Utilisez des alias Azure Policy dans les espaces de noms « Microsoft.DBforPostgreSQL » et « Microsoft.Network » afin de créer des stratégies personnalisées pour auditer ou appliquer la configuration réseau de vos instances Azure Database pour PostgreSQL. Vous pouvez aussi utiliser des définitions de stratégie intégrées relatives à la mise en réseau ou à vos instances Azure Database pour PostgreSQL comme :

  • DDoS Protection Standard doit être activé

  • L’application de la connexion TLS doit être activée pour les serveurs de base de données PostgreSQL

Pour plus d’informations, voir les liens vers les références ci-dessous.

Responsabilité : Customer

1.10 : Règles de configuration du trafic de documents

Aide : Utilisez des étiquettes pour les ressources liées à la sécurité réseau et au flux de trafic de vos instances Azure Database pour PostgreSQL afin de fournir des métadonnées et une organisation logique.

Utilisez l’une des définitions Azure Policy intégrées en lien avec l’étiquetage comme « Exiger une étiquette et sa valeur » pour vous assurer que toutes les ressources créées sont étiquetées et être informé de l’existence de ressources non étiquetées.

Vous pouvez utiliser Azure PowerShell ou Azure CLI pour rechercher ou effectuer des actions sur des ressources en fonction de leurs étiquettes.

Responsabilité : Customer

1.11 : Utiliser des outils automatisés pour superviser les configurations des ressources réseau et détecter les modifications

Aide : Utiliser le journal d’activité Azure pour superviser les configurations des ressources réseau et détecter les modifications des ressources réseau associées à vos instances Azure Database pour PostgreSQL. Créez des alertes dans Azure Monitor, qui se déclenchent lors de la modification de ressources réseau critiques.

Responsabilité : Customer

Journalisation et supervision

Pour plus d’informations, consultez Benchmark de sécurité Azure : journalisation et supervision.

2.2 : Configurer la gestion des journaux de sécurité centrale

Aide : Activer les paramètres de diagnostic, les journaux du serveur et les journaux d’ingestion pour agréger les données de sécurité générées par vos instances Azure Database pour PostgreSQL. Dans Azure Monitor, utilisez des espaces de travail Log Analytics pour interroger et effectuer l’analytique, puis utilisez les comptes de stockage Azure pour le stockage à long terme/d’archivage. Vous pouvez également activer et intégrer les données dans Microsoft Sentinel ou une solution SIEM tierce.

Responsabilité : Customer

2.3 : Activer la journalisation d’audit pour les ressources Azure

Conseils : Activez les paramètres de diagnostic sur vos instances Azure Database pour PostgreSQL afin d’accéder aux journaux d’audit, de sécurité et de ressources. Veillez à activer spécifiquement le journal d’audit de PostgreSQL. Les journaux d’activité, automatiquement disponibles, incluent la source de l’événement, la date, l’utilisateur, l’horodatage, les adresses sources, les adresses de destination et d’autres éléments utiles. Vous pouvez aussi activer les paramètres de diagnostic des journaux d’activité Azure et envoyer les journaux vers le même espace de travail Log Analytics ou le même compte de stockage.

Responsabilité : Customer

2.5 : Configurer la conservation du stockage des journaux de sécurité

Aide : Dans Azure Monitor, pour l’espace de travail Log Analytics utilisé pour stocker vos journaux Azure Database pour PostgreSQL, définissez la période de conservation dans le respect des réglementations de conformité de votre organisation. Utilisez les comptes de stockage Azure pour le stockage à long terme/d’archivage.

Responsabilité : Customer

2.6 : Superviser et examiner les journaux

Aide : Analyser et superviser les journaux de vos instances Azure Database pour PostgreSQL à la recherche d’un comportement anormal. Utilisez Log Analytics d’Azure Monitor pour examiner les journaux et effectuer des requêtes sur leurs données. Vous pouvez également activer et intégrer les données dans Microsoft Sentinel ou une solution SIEM tierce.

Responsabilité : Customer

2.7 : Activer les alertes d’activité anormale

Conseils : Activer Advanced Threat Protection pour Azure Database pour PostgreSQL. Advanced Threat Protection détecte les activités anormales indiquant des tentatives d’accès ou d’exploitation inhabituelles et potentiellement dangereuses de vos bases de données.

En outre, vous pouvez activer les journaux et les paramètres de diagnostic du serveur pour PostgreSQL, et envoyer les journaux à un espace de travail Log Analytics. Intégrez votre espace de travail Log Analytics à Microsoft Sentinel pour bénéficier d’une solution SOAR (Security Orchestration Automated Response). Cela permet de créer des playbooks (solutions automatisées) utilisables pour corriger des problèmes de sécurité.

Responsabilité : Customer

Contrôle des accès et des identités

Pour plus d’informations, consultez Benchmark de sécurité Azure : contrôle des accès et des identités.

3.1 : Tenir un inventaire des comptes d’administration

Aide : Conserver un inventaire des comptes d’utilisateur qui ont un accès d’administration au plan de contrôle (par exemple le portail Azure) de vos instances Azure Database pour PostgreSQL. En outre, conservez un inventaire des comptes d’administration qui ont accès au plan de données (dans la base de données elle-même) de vos instances Azure Database pour PostgreSQL. (Lors de la création du serveur PostgreSQL, vous fournissez des informations d’identification pour un utilisateur administrateur. Cet administrateur peut être utilisé pour créer des utilisateurs PostgreSQL supplémentaires.)

Azure Database pour PostgreSQL ne prend pas en charge le contrôle d’accès en fonction du rôle intégré, mais vous pouvez créer des rôles personnalisés basés sur des opérations de fournisseurs de ressources spécifiques.

Responsabilité : Customer

3.2 : Modifier les mots de passe par défaut lorsque cela est possible

Aide : Azure Active Directory (Azure AD) et Azure Database pour PostgreSQL n’ont pas le concept de mots de passe par défaut.

Lors de la création de la ressource Azure Database pour PostgreSQL elle-même, Azure force la création d’un utilisateur administrateur avec un mot de passe fort. Cependant, une fois l’instance PostgreSQL créée, vous pouvez utiliser le premier compte d’administrateur de serveur que vous avez créé pour créer des utilisateurs supplémentaires et leur accorder un accès d’administration. Lors de la création de ces comptes, veillez à configurer un mot de passe fort et différent pour chaque compte.

Responsabilité : Customer

3.3 : Utiliser des comptes d’administration dédiés

Aide : Créer des procédures de fonctionnement standard autour de l’utilisation de comptes d’administration dédiés ayant accès à vos instances Azure Database pour PostgreSQL. Utilisez la gestion des identités et des accès de Microsoft Defender pour le cloud afin de monitorer le nombre de comptes d’administration.

Responsabilité : Customer

3.4 : Utiliser l’authentification unique (SSO) Azure Active Directory

Aide : la connexion à Azure Database pour PostgreSQL est prise en charge à la fois avec le nom d’utilisateur/mot de passe configuré directement dans la base de données et avec une identité Azure Active Directory (Azure AD) et l’utilisation d’un jeton Azure AD pour se connecter. Quand vous utilisez un jeton de Azure AD, différentes méthodes sont prises en charge, comme un utilisateur Azure AD, un groupe Azure AD ou une application Azure AD qui se connecte à la base de données.

Séparément, l’accès au plan de contrôle pour PostgreSQL est disponible via l’API REST et prend en charge l’authentification unique. Pour vous authentifier, définissez l’en-tête d’autorisation pour vos demandes sur un jeton web JSON que vous avez obtenu auprès d’Azure AD.

Responsabilité : Customer

3.5 : Utiliser l’authentification multifacteur pour tous les accès basés sur Azure Active Directory

Conseil : Activez l’authentification multifacteur Azure Active Directory (Azure AD) et suivez les recommandations relatives à la gestion des identités et des accès de Microsoft Defender pour le cloud. L’utilisation de jetons Azure AD pour la connexion à votre base de données vous permet d’exiger l’authentification multifacteur pour les connexions à la base de données.

Responsabilité : Customer

3.6 : Utiliser des stations de travail sécurisées et gérées par Azure pour les tâches administratives

Conseil : utilisez des stations de travail disposant d’un accès privilégié avec l’authentification multifacteur configurée pour vous connecter aux ressources Azure et les configurer.

Responsabilité : Customer

3.7 : Journaliser et générer des alertes en cas d’activités suspectes sur des comptes d’administration

Aide : Activer Advanced Threat Protection pour Azure Database pour PostgreSQL de façon à générer des alertes en cas d’activité suspecte.

En outre, vous pouvez utiliser Azure Active Directory (Azure AD) Privileged Identity Management pour générer des journaux et des alertes quand des activités suspectes ou potentiellement dangereuses se produisent dans l’environnement.

Utilisez les détections de risque Azure AD pour visualiser les alertes et des rapports sur les comportements à risque des utilisateurs.

Responsabilité : Customer

3.8 : Gérer les ressources Azure à partir des emplacements approuvés uniquement

Conseils : Utilisez des emplacements nommés à accès conditionnel pour autoriser l’accès au portail et à Azure Resource Manager seulement à partir de regroupements logiques spécifiques de plages d’adresses IP ou de pays/régions.

Responsabilité : Customer

3.9 : Utiliser Azure Active Directory

Aide : Utiliser Azure Active Directory (Azure AD) comme système d’authentification et d’autorisation central. Azure AD protège les données en utilisant un chiffrement fort pour les données au repos et en transit. De plus, AAD sale, hache et stocke de manière sécurisée les informations d’identification utilisateur.

Pour la connexion à Azure Database pour PostgreSQL, il est recommandé d’utiliser Azure AD et un jeton Azure AD pour se connecter. Quand vous utilisez un jeton de Azure AD, différentes méthodes sont prises en charge, comme un utilisateur Azure AD, un groupe Azure AD ou une application Azure AD qui se connecte à la base de données.

Les informations d’identification Azure AD peuvent également être utilisées pour l’administration au niveau du plan de gestion (par exemple le portail Azure) pour contrôler les comptes d’administrateur PostgreSQL.

Responsabilité : Customer

3.10 : Examiner et rapprocher régulièrement l’accès utilisateur

Aide : passez en revue les journaux Azure Active Directory (Azure AD) pour découvrir les comptes obsolètes, qui peuvent inclure ceux ayant des rôles d’administration Azure Database pour PostgreSQL. Utilisez également des révisions d’accès d’identité Azure pour gérer efficacement les appartenances aux groupes, les accès aux applications d’entreprise susceptibles d’être utilisées pour accéder à Azure Database pour PostgreSQL et les attributions de rôles. Il convient d’examiner régulièrement les accès des utilisateurs, par exemple tous les 90 jours, pour vérifier que seuls les utilisateurs appropriés sont autorisés à accéder.

Responsabilité : Customer

3.11 : Superviser les tentatives d’accès à des informations d’identification désactivées

Aide : activez les paramètres de diagnostic pour Azure Database pour PostgreSQL et Azure Active Directory (Azure AD) de façon à envoyer tous les journaux à un espace de travail Log Analytics. Configurez les alertes souhaitées (comme les tentatives d’authentification en échec) dans Log Analytics.

Responsabilité : Customer

3.12 : Alerter en cas d’écart de comportement de connexion à un compte

Aide : Activer Advanced Threat Protection pour Azure Database pour PostgreSQL de façon à générer des alertes en cas d’activité suspecte.

Utilisez les fonctionnalités de protection des identités et de détection des risques d’Azure Active Directory (Azure AD) pour configurer des réponses automatisées aux actions suspectes détectées. Vous pouvez activer des réponses automatisées via Microsoft Sentinel pour implémenter les réponses de sécurité de votre organisation.

Vous pouvez également ingérer des journaux dans Microsoft Sentinel pour approfondir vos recherches.

Responsabilité : Customer

3.13 : Fournir à Microsoft un accès aux données client pertinentes pendant les scénarios de support

Conseils : Actuellement non disponible ; Customer Lockbox n’est pas encore pris en charge pour Azure Database pour PostgreSQL.

Responsabilité : Customer

Protection des données

Pour plus d’informations, consultez Benchmark de sécurité Azure : protection des données.

4.1 : Conserver un inventaire des informations sensibles

Aide : Utilisez des étiquettes pour faciliter le suivi des instances Azure Database pour PostgreSQL ou des ressources associées qui stockent ou traitent des informations sensibles.

Responsabilité : Customer

4.2 : Isoler les systèmes qui stockent ou traitent les informations sensibles

Conseils : Implémentez des abonnements et/ou des groupes d’administration distincts pour le développement, les tests et la production. Utilisez une combinaison de Private Link, de points de terminaison de service et/ou de règles de pare-feu pour isoler et limiter l’accès réseau à vos instances Azure Database pour PostgreSQL.

Responsabilité : Customer

4.3. : Surveiller et bloquer le transfert non autorisé d’informations sensibles

Aide : Quand vous utilisez des machines virtuelles Azure pour accéder à des instances Azure Database pour PostgreSQL, utilisez Private Link, les configurations réseau PostgreSQL, les groupes de sécurité réseau et les étiquettes de service pour réduire le risque d’une exfiltration de données.

Microsoft gère l’infrastructure sous-jacente d’Azure Database pour PostgreSQL et a implémenté des contrôles stricts pour empêcher la perte ou l’exposition de données client.

Responsabilité : Partagé

4.4 : Chiffrer toutes les informations sensibles en transit

Conseils : Azure Database pour PostgreSQL prend en charge la connexion de votre serveur PostgreSQL aux applications clientes via TLS (Transport Layer Security), anciennement SSL (Secure Sockets Layer). L’application de connexions TLS entre votre serveur de base de données et vos applications clientes vous protège contre les « attaques de l’intercepteur » en chiffrant le flux de données entre le serveur et votre application. Dans le portail Azure, vérifiez que l’option « Appliquer une connexion SSL » est activée par défaut pour toutes vos instances Azure Database pour PostgreSQL.

Les versions TLS actuellement prises en charge pour Azure Database pour PostgreSQL sont TLS 1.0, TLS 1.1, TLS 1.2.

Responsabilité : Partagé

Supervision Microsoft Defender pour le cloud : le Benchmark de sécurité Azure est l’initiative de stratégie par défaut pour Microsoft Defender pour le cloud et constitue la base des recommandations de Microsoft Defender pour le cloud. Les définitions Azure Policy associées à ce contrôle sont activées automatiquement par Microsoft Defender pour le cloud. Les alertes liées à ce contrôle peuvent nécessiter un plan Microsoft Defender pour les services associés.

Définitions intégrées à Azure Policy – Microsoft.DBforPostgreSQL :

Nom
(Portail Azure)
Description Effet(s) Version
(GitHub)
L’application de la connexion SSL doit être activée pour les serveurs de base de données PostgreSQL Azure Database pour PostgreSQL prend en charge la connexion de votre serveur Azure Database pour PostgreSQL aux applications clientes via SSL (Secure Sockets Layer). L’application de connexions SSL entre votre serveur de base de données et vos applications clientes vous protège contre les « attaques de l’intercepteur » en chiffrant le flux de données entre le serveur et votre application. Cette configuration garantit que le protocole SSL est toujours activé pour l’accès à votre serveur de base de données. Audit, Désactivé 1.0.1

4.5 : Utiliser un outil de découverte actif pour identifier les données sensibles

Aide : Les fonctionnalités d’identification des données, de classification des données et de protection contre la perte de données ne sont pas encore disponibles pour Azure Database pour PostgreSQL. Implémentez une solution tierce si nécessaire à des fins de conformité.

Pour la plateforme sous-jacente managée par Microsoft, Microsoft considère tout le contenu client comme sensible et met tout en œuvre pour empêcher la perte et l’exposition des données client. Pour garantir la sécurité des données client dans Azure, Microsoft a implémenté et tient à jour une suite de contrôles et de fonctionnalités de protection des données robustes.

Responsabilité : Partagé

4.6 : Utiliser Azure RBAC pour contrôler l’accès aux ressources

Aide : Utilisez le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour contrôler l’accès au plan de contrôle de base de données Azure Database pour PostgreSQL (par exemple, le portail Azure). Pour l’accès au plan de données (dans la base de données elle-même), utilisez des requêtes SQL pour créer des utilisateurs et configurer des autorisations utilisateur. Azure RBAC ne modifie pas les autorisations utilisateur dans la base de données.

Responsabilité : Customer

4.9 : Consigner et alerter les modifications apportées aux ressources Azure critiques

Conseils : Utiliser Azure Monitor avec le journal d’activité Azure pour créer des alertes en cas de modifications sur des instances de production Azure Database pour PostgreSQL et d’autres ressources critiques ou associées.

Responsabilité : Customer

Gestion des vulnérabilités

Pour plus d’informations, consultez Benchmark de sécurité Azure : Gestion des vulnérabilités.

5.1 : Exécuter les outils d’analyse des vulnérabilités automatisés

Conseil : Suivez les recommandations de Microsoft Defender pour le cloud concernant la sécurisation de vos ressources Azure Database for PostgreSQL et apparentées.

Microsoft assure la gestion des vulnérabilités sur les systèmes sous-jacents prenant en charge Azure Database pour PostgreSQL.

Responsabilité : Partagé

Gestion des stocks et des ressources

Pour plus d’informations, consultez Benchmark de sécurité Azure : Gestion des stocks et des ressources.

6.1 : Utiliser la solution de détection automatisée des ressources

Conseils : utilisez Azure Resource Graph pour interroger et découvrir toutes les ressources (y compris les instances Azure Database pour PostgreSQL) dans vos abonnements. Vérifiez que vous disposez des autorisations (en lecture) appropriées dans votre locataire et pouvez répertorier tous les abonnements Azure ainsi que les ressources qu’ils contiennent.

Responsabilité : Customer

6.2 : Gérer les métadonnées de ressources

Aide : Appliquer des étiquettes à des instances Azure Database pour PostgreSQL et à d’autres ressources associées en ajoutant des métadonnées pour les organiser logiquement en une taxonomie.

Responsabilité : Customer

6.3 : Supprimer des ressources Azure non autorisées

Aide : Utiliser des étiquettes, des groupes d’administration et des abonnements distincts pour organiser et suivre les instances Azure Database pour PostgreSQL et les ressources associées. Rapprochez régulièrement l’inventaire et assurez-vous que les ressources non autorisées sont supprimées de l’abonnement en temps utile.

Responsabilité : Customer

6.4 : Définir et tenir un inventaire des ressources Azure approuvées

Aide : Non applicable. Cette recommandation concerne les ressources de calcul et Azure dans son ensemble.

Responsabilité : Customer

6.5 : Analyser les ressources Azure non approuvées

Conseils : Appliquez des restrictions quant au type de ressources pouvant être créées dans les abonnements clients, en utilisant Azure Policy avec les définitions intégrées suivantes :

  • Types de ressources non autorisés

  • Types de ressources autorisés

Utilisez également Azure Resource Graph pour interroger/découvrir des ressources dans les abonnements.

Responsabilité : Customer

6.9 : Utiliser des services Azure approuvés uniquement

Conseils : Appliquez des restrictions quant au type de ressources pouvant être créées dans les abonnements clients, en utilisant Azure Policy avec les définitions intégrées suivantes :

  • Types de ressources non autorisés
  • Types de ressources autorisés

Pour plus d’informations, voir les liens vers les références ci-dessous.

Responsabilité : Customer

6.11 : Limiter la capacité des utilisateurs à interagir avec Azure Resource Manager

Aide : Utilisez l’accès conditionnel Azure pour limiter la capacité des utilisateurs à interagir avec Azure Resource Manager en configurant « Bloquer l’accès » pour l’application « Gestion Microsoft Azure ». Ceci peut empêcher la création et les modifications des ressources dans un environnement de haute sécurité, comme des instances Azure Database pour PostgreSQL contenant des informations sensibles.

Responsabilité : Customer

Configuration sécurisée

Pour plus d’informations, consultez Benchmark de sécurité Azure : Configuration sécurisée.

7.1 : Établir des configurations sécurisées pour toutes les ressources Azure

Aide : Définir et implémenter des configurations de sécurité standard pour vos instances Azure Database pour PostgreSQL avec Azure Policy. Utilisez des alias Azure Policy dans l’espace de noms « Microsoft.DBforPostgreSQL » afin de créer des stratégies personnalisées pour auditer ou appliquer la configuration réseau de vos instances Azure Database pour PostgreSQL. Vous pouvez aussi utiliser des définitions de stratégie intégrées relatives à vos instances Azure Database pour PostgreSQL comme :

  • L’application de la connexion TLS doit être activée pour les serveurs de base de données PostgreSQL
  • Les connexions de journal doivent être activées pour les serveurs de bases de données PostgreSQL

Pour plus d’informations, voir les liens vers les références ci-dessous.

Responsabilité : Customer

7.3 : Gérer les configurations de ressources Azure sécurisées

Aide : Utilisez les stratégies Azure Policy [refuser] et [déployer s’il n’existe pas] pour appliquer des paramètres sécurisés à vos ressources Azure.

Responsabilité : Customer

7.5 : Stocker en toute sécurité la configuration des ressources Azure

Aide : Si vous utilisez des définitions Azure Policy personnalisées pour vos instances Azure Database pour PostgreSQL et des ressources associées, utilisez Azure Repos pour stocker et gérer votre code de façon sécurisée.

Responsabilité : Customer

7.7 : Déployer des outils de gestion de la configuration pour les ressources Azure

Aide : Utiliser des alias Azure Policy dans l’espace de noms « Microsoft.DBforPostgreSQL » pour créer des stratégies personnalisées afin d’alerter, d’auditer et d’appliquer des configurations système. En outre, développez un processus et un pipeline pour la gestion des exceptions de stratégie.

Responsabilité : Customer

7.9 : Mettre en place une supervision automatisée de la configuration pour les ressources Azure

Aide : Utiliser des alias Azure Policy dans l’espace de noms « Microsoft.DBforPostgreSQL » pour créer des stratégies personnalisées afin d’alerter, d’auditer et d’appliquer des configurations système. Utilisez les stratégies Azure Policy [auditer], [refuser] et [déployer si elle n’existe pas] pour appliquer automatiquement des configurations pour vos instances Azure Database pour PostgreSQL et les ressources associées.

Responsabilité : Customer

7.11 : Gérer les secrets Azure en toute sécurité

Aide : Pour les machines virtuelles Azure ou les applications web s’exécutant sur Azure App Service utilisées pour accéder à vos instances Azure Database pour PostgreSQL, utilisez Managed Service Identity conjointement avec Azure Key Vault pour simplifier et sécuriser la gestion des secrets d’Azure Database pour PostgreSQL. Vérifiez que la suppression réversible est activée dans Key Vault.

Responsabilité : Customer

7.12 : Gérer les identités de façon sécurisée et automatique

Aide : Le serveur Azure Database pour PostgreSQL prend en charge l’authentification Azure Active Directory (Azure AD) pour accéder aux bases de données. Quand vous créez un serveur Azure Database pour PostgreSQL, vous fournissez les informations d’identification pour un utilisateur administrateur. Cet administrateur peut être utilisé pour créer des utilisateurs de base de données supplémentaires.

Pour les machines virtuelles Azure ou les applications web s’exécutant sur Azure App Service utilisées pour accéder à votre serveur Azure Database pour PostgreSQL, utilisez Managed Service Identity conjointement avec Azure Key Vault pour stocker et récupérer des informations d’identification pour Azure Database pour PostgreSQL. Vérifiez que la suppression réversible est activée dans Key Vault.

Utilisez des identités managées pour fournir aux services Azure une identité gérée automatiquement dans Azure AD. Les identités managées vous permettent de vous authentifier auprès d’un service qui prend en charge l’authentification Azure AD, y compris Key Vault, sans informations d’identification dans votre code.

Responsabilité : Customer

7.13 : Éliminer l’exposition involontaire des informations d’identification

Conseils : Exécuter le moteur d’analyse des informations d’identification pour identifier les informations d’identification dans le code. Le moteur d’analyse des informations d’identification encourage également le déplacement des informations d’identification découvertes vers des emplacements plus sécurisés, tels qu’Azure Key Vault.

Responsabilité : Customer

Défense contre les programmes malveillants

Pour plus d’informations, consultez Benchmark de sécurité Azure : Défense contre les programmes malveillants.

8.2 : Pré-analyser les fichiers à charger sur des ressources Azure non liées au calcul

Aide : Microsoft Antimalware est activé sur l’hôte sous-jacent qui prend en charge les services Azure (par exemple Azure Database pour PostgreSQL), mais il ne s’exécute pas sur du contenu client.

Pré-analysez tout contenu chargé sur des ressources Azure non liées au calcul, comme App Service, Data Lake Storage, Stockage Blob, Azure Database pour PostgreSQL, etc. Microsoft ne peut pas accéder à vos données dans ces instances.

Responsabilité : Partagé

Récupération des données

Pour plus d’informations, consultez Benchmark de sécurité Azure : récupération de données.

9.1 : Garantir des sauvegardes automatiques régulières

Conseils : Azure Database pour PostgreSQL effectue des sauvegardes des fichiers de données et du journal des transactions. Selon la taille de stockage maximale prise en charge, nous prenons en charge des sauvegardes complètes et différentielles (serveurs de stockage de 4 To maximum) ou des sauvegardes d’instantanés (serveurs de stockage jusqu’à 16 To maximum). Celles-ci vous permettent de restaurer un serveur à n’importe quel point dans le temps au sein de votre période de rétention de sauvegarde configurée. La période de rétention de sauvegarde par défaut est de sept jours. Vous pouvez éventuellement la configurer sur 35 jours maximum. Toutes les sauvegardes sont chiffrées à l’aide du chiffrement AES de 256 bits.

Responsabilité : Partagé

Supervision Microsoft Defender pour le cloud : le Benchmark de sécurité Azure est l’initiative de stratégie par défaut pour Microsoft Defender pour le cloud et constitue la base des recommandations de Microsoft Defender pour le cloud. Les définitions Azure Policy associées à ce contrôle sont activées automatiquement par Microsoft Defender pour le cloud. Les alertes liées à ce contrôle peuvent nécessiter un plan Microsoft Defender pour les services associés.

Définitions intégrées à Azure Policy – Microsoft.DBforPostgreSQL :

Nom
(Portail Azure)
Description Effet(s) Version
(GitHub)
La sauvegarde géoredondante doit être activée pour Azure Database pour PostgreSQL Azure Database pour PostgreSQL vous permet de choisir l’option de redondance pour votre serveur de base de données. Vous pouvez choisir un stockage de sauvegarde géoredondant. Dans ce cas, les données sont non seulement stockées dans la région qui héberge votre serveur, mais elles sont aussi répliquées dans une région jumelée pour offrir une possibilité de récupération en cas de défaillance régionale. La configuration du stockage géoredondant pour la sauvegarde est uniquement possible lors de la création du serveur. Audit, Désactivé 1.0.1

9.2 : Effectuer des sauvegardes complètes du système et sauvegarder les clés gérées par le client

Aide : Azure Database pour PostgreSQL crée automatiquement des sauvegardes du serveur et les conserve dans un stockage géoredondant ou redondant localement, au choix de l’utilisateur. Les sauvegardes peuvent être utilisées pour restaurer votre serveur à un point dans le temps. La sauvegarde et la restauration sont une partie essentielle de toute stratégie de continuité d’activité, dans la mesure où elles protègent vos données des corruptions et des suppressions accidentelles.

Si vous utilisez Azure Key Vault pour stocker les informations d’identification de vos instances Azure Database pour PostgreSQL, veillez à faire des sauvegardes automatisées régulières de vos clés.

Responsabilité : Partagé

Supervision Microsoft Defender pour le cloud : le Benchmark de sécurité Azure est l’initiative de stratégie par défaut pour Microsoft Defender pour le cloud et constitue la base des recommandations de Microsoft Defender pour le cloud. Les définitions Azure Policy associées à ce contrôle sont activées automatiquement par Microsoft Defender pour le cloud. Les alertes liées à ce contrôle peuvent nécessiter un plan Microsoft Defender pour les services associés.

Définitions intégrées à Azure Policy – Microsoft.DBforPostgreSQL :

Nom
(Portail Azure)
Description Effet(s) Version
(GitHub)
La sauvegarde géoredondante doit être activée pour Azure Database pour PostgreSQL Azure Database pour PostgreSQL vous permet de choisir l’option de redondance pour votre serveur de base de données. Vous pouvez choisir un stockage de sauvegarde géoredondant. Dans ce cas, les données sont non seulement stockées dans la région qui héberge votre serveur, mais elles sont aussi répliquées dans une région jumelée pour offrir une possibilité de récupération en cas de défaillance régionale. La configuration du stockage géoredondant pour la sauvegarde est uniquement possible lors de la création du serveur. Audit, Désactivé 1.0.1

9.3 : Valider toutes les sauvegardes, y compris les clés gérées par le client

Aide : Dans Azure Database pour PostgreSQL, l’exécution d’une restauration crée un serveur à partir de sauvegardes de serveur d’origine. Deux types de restauration sont disponibles : Restauration à un point dans le temps et géorestauration. La restauration à un point dans le temps est disponible avec l’option de redondance de la sauvegarde et elle crée un serveur dans la même région que votre serveur d’origine. La géorestauration est disponible seulement si vous avez configuré votre serveur pour le stockage géoredondant. Elle vous permet de restaurer votre serveur dans une autre région.

Le délai estimé de récupération dépend de plusieurs facteurs, notamment du nombre total de bases de données à récupérer dans la même région au même moment, de la taille des bases de données, de la taille du journal des transactions et de la bande passante réseau. Le délai de récupération est généralement inférieur à 12 heures.

Testez régulièrement la restauration de vos instances Azure Database pour PostgreSQL.

Responsabilité : Customer

9.4 : Garantir la protection des sauvegardes et des clés managées par le client

Conseils : Azure Database pour PostgreSQL accepte les sauvegardes complètes, différentielles et du journal des transactions. Celles-ci vous permettent de restaurer un serveur à n’importe quel point dans le temps au sein de votre période de rétention de sauvegarde configurée. La période de rétention de sauvegarde par défaut est de sept jours. Vous pouvez éventuellement la configurer sur 35 jours maximum. Toutes les sauvegardes sont chiffrées à l’aide du chiffrement AES de 256 bits.

Responsabilité : Customer

Réponse aux incidents

Pour plus d’informations, consultez Benchmark de sécurité Azure : réponse aux incidents.

10.1 : Créer un guide de réponse aux incidents

Conseils : Créez un guide de réponse aux incidents pour votre organisation. Assurez-vous qu’il existe des plans de réponse aux incidents écrits qui définissent tous les rôles du personnel, ainsi que les phases de gestion des incidents, depuis la détection jusqu’à la revue une fois l’incident terminé.

Responsabilité : Customer

10.2 : Créer une procédure de notation et de classement des incidents

Aide : Microsoft Defender pour le cloud attribue un niveau de gravité à chaque alerte afin de vous aider à les classer par ordre de priorité pour savoir lesquelles examiner en premier. La gravité dépend du niveau de confiance que Microsoft Defender pour le cloud accorde au résultat ou à la métrique utilisés pour émettre l’alerte, ainsi que du niveau de confiance concernant le caractère malveillant de l’intention derrière l’activité à l’origine de l’alerte.

En outre, marquez clairement les abonnements (par exemple, production, non-production) et créez un système d’attribution de noms pour identifier et classer les ressources Azure de façon claire.

Responsabilité : Customer

10.3 : Tester les procédures de réponse de sécurité

Aide : Exécutez des exercices pour tester les fonctionnalités de réponse aux incidents de vos systèmes de façon régulière. Identifiez les points faibles et les lacunes, et révisez le plan en fonction des besoins.

Responsabilité : Customer

10.4 : Fournir des informations de contact pour les incidents de sécurité et configurer des notifications d’alerte pour les incidents de sécurité

Conseils : Les informations de contact d’incident de sécurité seront utilisées par Microsoft pour vous contacter si Microsoft Security Response Center (MSRC) découvre que les données du client ont été utilisées par un tiers illégal ou non autorisé. Examinez les incidents après les faits pour vous assurer que les problèmes sont résolus.

Responsabilité : Customer

10.5 : Intégrer des alertes de sécurité à votre système de réponse aux incidents

Conseils : Exportez les alertes et les recommandations de Microsoft Defender pour le cloud à l’aide de la fonctionnalité d’exportation continue. L’exportation continue vous permet d’exporter les alertes et les recommandations manuellement, ou automatiquement de manière continue. Vous pouvez utiliser le connecteur de données Microsoft Defender pour le cloud afin d’envoyer en streaming les alertes à Microsoft Sentinel.

Responsabilité : Customer

10.6 : Automatiser la réponse aux alertes de sécurité

Conseils : Utilisez la fonctionnalité d’automatisation des workflows dans Microsoft Defender pour le cloud pour déclencher automatiquement des réponses via « Logic Apps » sur les alertes et recommandations de sécurité.

Responsabilité : Customer

Tests d’intrusion et exercices Red Team

Pour plus d’informations, consultez Benchmark de sécurité Azure : tests d’intrusion et exercices Red Team.

11.1 : Procéder régulièrement à des tests d’intrusion des ressources Azure et veiller à corriger tous les problèmes de sécurité critiques détectés

Aide : Suivez les règles d’engagement de Microsoft pour garantir que vos tests d’intrusion sont conformes aux stratégies de Microsoft : https://www.microsoft.com/msrc/pentest-rules-of-engagement?rtc=1

Responsabilité : Partagé

Étapes suivantes