Sécuriser votre serveur Azure Database pour PostgreSQL

Azure Database pour PostgreSQL est un service de base de données entièrement managé qui fournit des fonctionnalités intégrées de haute disponibilité, de sauvegardes automatisées et de mise à l’échelle. La sécurisation de vos déploiements de base de données PostgreSQL est essentielle pour protéger les données sensibles et assurer la conformité aux normes du secteur.

Cet article vous guide sur la sécurisation du déploiement de votre serveur Azure Database pour PostgreSQL.

Sécurité réseau

La section Sécurité réseau vous guide tout au long de la prévention de l’accès public et de l’utilisation des fonctionnalités de mise en réseau pour intégrer votre PostgreSQL dans une architecture de réseau cloud sécurisée et segmentée.

• Désactivez l’accès au réseau public : désactivez l’accès au réseau public pour votre PostgreSQL afin d’empêcher l’exposition à Internet. Cette action garantit que seuls les réseaux approuvés peuvent accéder à votre base de données.

• Points de terminaison privés : utilisez des points de terminaison privés pour vous connecter en toute sécurité à votre PostgreSQL à partir de votre réseau virtuel.

• Vous pouvez également utiliser l’intégration de réseau virtuel : utilisez l’intégration de réseau virtuel pour connecter votre PostgreSQL à votre réseau virtuel. Cette intégration permet un accès sécurisé à partir de vos ressources Azure et du serveur aux ressources consommées, telles que l’IA.

• Règles de pare-feu héritées et points de terminaison de service : si vous devez autoriser l’accès à partir d’adresses IP spécifiques, utilisez des règles de pare-feu héritées et des points de terminaison de service. Toutefois, cette approche n’est pas recommandée. Au lieu de cela, préférez utiliser des points de terminaison privés ou une intégration de réseau virtuel.

Les articles sur la sécurité réseau se trouvent dans les sections Mise en réseau :

• Vue d’ensemble de la mise en réseau pour Azure Database pour PostgreSQL avec accès public (adresses IP autorisées)

• Réseau avec accès privé (intégration de réseau virtuel) pour Azure Database pour PostgreSQL

• Mise en réseau Azure Database pour PostgreSQL avec Private Link

Gestion des identités

La section Gestion des identités se concentre sur l’authentification, la sécurisation des identités et les contrôles d’accès à l’aide de systèmes de gestion des identités et des accès centralisés. Elle couvre les meilleures pratiques telles que les mécanismes d’authentification forts et les identités managées pour les applications.

Voici quelques-uns des services de sécurité, fonctionnalités et meilleures pratiques possibles pour la section Gestion des identités :

• Utilisez Entra au lieu de l’authentification locale de base de données : vous devez interdire l’authentification locale pour votre serveur PostgreSQL. Utilisez plutôt l’authentification Microsoft Entra uniquement (pas en mode mixte) pour gérer l’accès à votre base de données. Microsoft Entra fournit une authentification centralisée avec des contrôles de sécurité forts et une protection en temps réel defender pour Identity. Pour plus d’informations, consultez Microsoft Entra en général et Authentification Microsoft Entra avec Azure Database pour PostgreSQL.

• Utilisez des identités managées pour sécuriser l’accès aux applications : utilisez des identités managées dans Azure pour authentifier en toute sécurité les applications et services sans avoir à gérer les informations d’identification. Cela offre un moyen sécurisé et simplifié d’accéder aux ressources telles qu’Azure Database pour PostgreSQL. Pour plus d’informations, consultez Identités managées.

• Appliquer la sécurité via des stratégies d’accès conditionnel : configurez des stratégies d’accès conditionnel dans Microsoft Entra pour appliquer des contrôles de sécurité basés sur l’utilisateur, l’emplacement ou le contexte de l’appareil. Ces stratégies permettent l’application dynamique des exigences de sécurité en fonction du risque, ce qui améliore la posture globale de sécurité. Pour plus d’informations, consultez Accès conditionnel Microsoft Entra.

• L’authentification locale doit utiliser l’authentification SCRAM : si vous devez utiliser l’authentification locale, vérifiez que les stratégies de mot de passe fortes sont appliquées. Utilisez les exigences de complexité du mot de passe et la rotation régulière des mots de passe pour réduire le risque de compromission des comptes. Pour plus d’informations, consultez Authentification SCRAM dans Azure Database pour PostgreSQL.

Contrôle d’accès

La section Contrôle d’accès se concentre sur la sécurisation du niveau d’accès en fonction du principe des privilèges minimum. Elle met l’accent sur la réduction du risque d’accès non autorisé aux ressources sensibles en limitant et en gérant des autorisations élevées, en appliquant l’authentification multifacteur et en veillant à ce que les actions privilégiées soient journalisées et auditées.

Voici quelques-uns des services de sécurité, fonctionnalités et meilleures pratiques possibles pour la section Contrôle d’accès :

• Utilisez les rôles Entra pour le contrôle d’accès : implémentez le contrôle d’accès en fonction du rôle Azure (Role-Based Access Control – RBAC) pour gérer l’accès aux ressources Azure Database pour PostgreSQL. Attribuez des rôles en fonction du principe du privilège minimum, ce qui garantit que les utilisateurs et les applications disposent uniquement des autorisations dont ils ont besoin. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Azure (RBAC) en général, et Gérer les rôles Microsoft Entra dans Azure Database pour PostgreSQL.

• Suivez les bonnes pratiques d’Entra : utilisez l’authentification multifacteur, les stratégies d’accès conditionnel, juste-à-temps (JIT) pour protéger vos utilisateurs et bases de données.

• Gérer les utilisateurs, les rôles et les autorisations de base de données locale : utilisez la gestion intégrée des rôles PostgreSQL pour contrôler l’accès au niveau de la base de données. Créez des rôles personnalisés avec des autorisations spécifiques pour appliquer le principe du privilège minimum. Examinez et auditez régulièrement ces rôles pour garantir la conformité aux stratégies de sécurité. Pour plus d’informations, consultez Créer des utilisateurs dans Azure Database pour PostgreSQL.

Protection de données

La section Protection des données se concentre sur la sécurisation des données sensibles au repos et en transit. Elle garantit que les données sont chiffrées, que l’accès est contrôlé et que les informations sensibles sont protégées contre un accès non autorisé. Il met l’accent sur l’utilisation du chiffrement, des connexions sécurisées et du masquage des données pour protéger l’intégrité et la confidentialité des données.

Voici quelques services de sécurité, fonctionnalités et meilleures pratiques possibles pour la section Protection des données :

Chiffrer les données en transit

• Vérifiez les connexions TLS : Azure PostgreSQL utilise toujours SSL ou TLS pour chiffrer les données en transit entre votre application et la base de données. Vous devez configurer votre application pour vérifier le certificat utilisé, tel que l’autorité de certification racine, les certificats expirés, l’incompatibilité de nom d’hôte et la révocation de certificats. Cette pratique permet de protéger les informations sensibles contre les oreilles indiscrètes et les attaques par intercepteur. Pour plus d’informations, consultez Connectivité sécurisée avec TLS et SSL dans Azure Database pour PostgreSQL.

• Vérifiez que le client dispose des derniers certificats TLS installés : assurez-vous que vos applications clientes disposent des derniers certificats TLS installés pour prendre en charge les connexions sécurisées. Cette pratique permet d’éviter les défaillances de connexion et garantit que votre application peut établir des connexions sécurisées avec le serveur PostgreSQL. Pour plus d’informations, consultez Télécharger les certificats d’autorité de certification racine et mettre à jour les clients d’application.

• Exiger l’utilisation de TLS 1.3 : configurez votre serveur PostgreSQL pour exiger TLS 1.3 pour toutes les connexions. Cette configuration garantit que seule la version la plus récente et la plus sécurisée du protocole est utilisée, ce qui améliore la sécurité et les performances. Pour plus d’informations, consultez Versions TLS.

Chiffrement au repos

• Les données sont toujours chiffrées de manière transparente avec SMK : Azure Database pour PostgreSQL chiffre automatiquement les données au repos à l’aide de clés gérées par le service (SMK). Ce chiffrement garantit que vos données sont protégées sans nécessiter de configuration supplémentaire. Il s’appuie sur l’infrastructure de stockage Azure sous-jacente. Il couvre le serveur principal, les réplicas, la récupération dans le temps (PITR) et les sauvegardes. Pour plus d’informations, consultez Chiffrement des données dans Azure Database pour PostgreSQL.

• Utilisez des clés gérées par le client pour un contrôle supplémentaire : si vous avez besoin d’un contrôle plus important sur les clés de chiffrement, utilisez des clés gérées par le client (CMK) stockées dans Azure Key Vault ou Azure HSM. Cette option vous permet de gérer vos clés de chiffrement et fournit des options de sécurité et de conformité supplémentaires. Pour plus d’informations, consultez Clés gérées par le client dans Azure Database pour PostgreSQL et Configurer le chiffrement des données dans Azure Database pour PostgreSQL.

• Configurer la rotation automatique des clés dans KV ou HSM managé : si vous utilisez des clés gérées par le client, configurez la rotation automatique des clés dans Azure Key Vault pour vous assurer que vos clés de chiffrement sont régulièrement mises à jour. Azure Database pour PostgreSQL prend en charge les mises à jour automatiques de version de clé après la rotation d’une clé. Pour plus d’informations, consultez Configurer la rotation automatique de clé dans Azure Managed HSM ou Présentation de la rotation automatique dans Azure Key Vault pour plus d’informations. Pour plus d’informations, consultez Configurer le chiffrement des données avec une clé gérée par le client pendant l’approvisionnement du serveur pour plus d’informations sur la configuration de la rotation automatique des clés.

• Chiffrer les données ultra-sensibles avec le chiffrement côté client : pour les données ultra-sensibles, envisagez d’implémenter le chiffrement côté client. Cette approche implique le chiffrement des données avant de l’envoyer à la base de données, ce qui garantit que seules les données chiffrées sont stockées dans la base de données. Cette pratique offre une plus grande couche de sécurité, car la base de données elle-même et, par conséquent, l’administrateur de base de données n’a pas accès aux données non chiffrées.

Calcul confidentiel

L’Informatique confidentielle Azure permet aux organisations de traiter et de collaborer en toute sécurité sur des données sensibles, telles que des données personnelles ou des informations médicales protégées. L’Informatique confidentielle Azure fournit une protection intégrée contre l’accès non autorisé en sécurisant les données en cours d’utilisation par le biais d’environnements d’exécution de confiance.

• Les fournisseurs SaaS et d’hébergement prennent en compte la configuration du calcul confidentiel : si vous êtes un logiciel en tant que service (SaaS) ou un fournisseur d’hébergement et que vos charges de travail PostgreSQL impliquent le traitement des données sensibles, envisagez d’utiliser Azure Confidential Computing pour protéger les données en cours d’utilisation. Cette solution offre une couche de sécurité supplémentaire en garantissant que les données sont traitées dans un environnement sécurisé, ce qui empêche même les utilisateurs privilégiés d’accéder sans autorisation. Pour plus d’informations, consultez Azure Informatique confidentielle pour Azure Database pour PostgreSQL pour plus d’informations.

Masquage et réaction des données

• Implémenter le masquage des données : utilisez l’extension PostgreSQL Anonymiser pour prendre en charge :

• Vidages anonymes : exportez les données masquées dans un fichier SQL.

• Masquage statique : supprimez les données personnelles en fonction des règles.

• Masquage dynamique : masquer les données personnelles uniquement pour les utilisateurs masqués.

• Affichages masquage : créez des vues dédiées pour les utilisateurs masqués.

• Masquage des wrappers de données : appliquez des règles de masquage sur des données externes.

Journalisation et détection des menaces

La section Journalisation et de détection des menaces couvre les contrôles de détection des menaces dans les environnements Azure. Il couvre l’activation, la collecte et le stockage des journaux d’audit pour les services Azure. Il met l’accent sur l’utilisation des fonctionnalités de détection des menaces natives, la gestion centralisée des journaux et la rétention appropriée des journaux pour les enquêtes de sécurité et la conformité. Cette section se concentre sur la génération d’alertes de haute qualité, la centralisation de l’analyse de la sécurité par le biais d’outils Azure, la gestion de la synchronisation de temps précise et la mise en place de stratégies de rétention des journaux efficaces.

Voici quelques-uns des services de sécurité, fonctionnalités et meilleures pratiques possibles pour la section Journalisation et détection des menaces :

• Activer la collecte des journaux de diagnostic : vérifiez que la journalisation des diagnostics est activée en sélectionnant le groupe de catégories « audit ». Utilisez Azure Policy pour implémenter :

• Stratégie Activer la journalisation par groupe de catégories pour PostgreSQL (microsoft.dbforpostgresql/flexibleservers) sur Log Analytics

• Initiative Activer la journalisation des ressources de groupe de catégorie d’audit pour les ressources prises en charge dans Log Analytics

• Utilisez Microsoft Defender pour Open-Source bases de données relationnelles : utilisez Microsoft Defender pour Open-Source bases de données relationnelles pour améliorer la posture de sécurité de votre instance de serveur flexible PostgreSQL. Ce service fournit une protection avancée contre les menaces, des évaluations des vulnérabilités et des recommandations de sécurité adaptées aux bases de données open source. Pour plus d’informations, consultez Vue d’ensemble de Microsoft Defender pour bases de données relationnelles Open-Source.

• Activer la journalisation d’audit : configurez la journalisation d’audit pour votre PostgreSQL pour suivre et journaliser les activités de base de données à l’aide de l’extension pgaudit. Pour plus d’informations, consultez la journalisation d’audit dans Azure Database pour PostgreSQL.

Sauvegarde et récupération

La section Sauvegarde et récupération se concentre sur la garantie que les données et les configurations entre les services Azure sont régulièrement sauvegardées, protégées et récupérables en cas de défaillances ou de sinistres. Il met l’accent sur l’automatisation des sauvegardes, la sécurisation des données de sauvegarde et la vérification que les processus de récupération sont testés et validés pour répondre aux objectifs de délai de récupération (RTO) et aux objectifs de point de récupération (RPO). La section met également en évidence l’importance de la surveillance et de l’audit des processus de sauvegarde pour garantir la conformité et la préparation. Pour obtenir une vue d’ensemble, consultez Vue d’ensemble de la continuité d’activité avec Azure Database pour PostgreSQL.

Voici quelques-uns des services de sécurité, fonctionnalités et meilleures pratiques possibles pour la section Détection de sauvegarde et récupération :

• Utilisez la haute disponibilité : implémentez des configurations de haute disponibilité pour votre instance de serveur flexible PostgreSQL afin de réduire les temps d’arrêt et de garantir l’accès continu à votre base de données. Pour plus d’informations, consultez Haute disponibilité (fiabilité) dans Azure Database pour PostgreSQL et Configurer la haute disponibilité.

• Configurez des sauvegardes automatisées : Azure Database pour PostgreSQL effectue automatiquement des sauvegardes quotidiennes de vos fichiers de base de données et sauvegarde en continu les journaux des transactions. Vous pouvez conserver les sauvegardes de sept jours jusqu’à 35 jours. Vous pouvez restaurer votre serveur de base de données à n’importe quel point dans le temps au cours de la période de conservation de votre sauvegarde. Le RTO dépend de la taille des données à restaurer et du temps d’exécution de la récupération des journaux. Il peut aller de quelques minutes à 12 heures. Pour plus d’informations, consultez Sauvegarde et restauration dans Azure Database pour PostgreSQL.

• Configurez les réplicas en lecture : utilisez les réplicas en lecture pour décharger les opérations de lecture à partir du serveur principal, ce qui améliore les performances et la disponibilité. Vous pouvez également utiliser des réplicas en lecture pour les scénarios de récupération d’urgence, ce qui vous permet de basculer rapidement vers un réplica avec une défaillance du serveur principal. Pour plus d’informations, consultez Réplicas en lecture dans Azure Database pour PostgreSQL.

• Protégez les données de sauvegarde avec le chiffrement de clé gérée par le client : sécurisez vos données de sauvegarde à l’aide du chiffrement au repos.

Contenu connexe

• Base de référence de sécurité Azure pour Azure Database pour PostgreSQL