Sécurité dans Azure Database pour PostgreSQL - Serveur flexible

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Plusieurs couches de sécurité permettent de mieux protéger les données de votre instance Azure Database pour PostgreSQL – Serveur flexible. Cet article décrit ces différentes options de sécurité.

Étant donné que les organisations s’appuient de plus en plus sur les données stockées dans des bases de données pour favoriser les activités critiques de prise de décision qui tirent parti de l’avantage concurrentiel, la nécessité de mesures de sécurité de base de données solides n’a jamais été plus importante. Une défaillance de sécurité peut avoir des conséquences catastrophiques, notamment exposer des données confidentielles, ce qui peut endommager la réputation de l’organisation.

Protection et chiffrement des informations

Azure Database pour PostgreSQL – Serveur flexible chiffre les données de deux façons :

• Données en transit : Azure Database pour PostgreSQL – Serveur flexible chiffre les données en transit avec les protocoles SSL/TLS (Secure Sockets Layer/Transport Layer Security). Le chiffrement est appliqué par défaut. Pour plus d’informations sur la sécurité des connexions avec SSL\TLS, consultez cette documentation. Pour une meilleure sécurité, vous pouvez choisir d’activer l’authentification SCRAM dans Azure Database pour PostgreSQL - Serveur flexible.

  Même si cela n’est vraiment pas recommandé, à cause d’une incompatibilité avec le client hérité, vous pouvez si besoin désactiver TLS\SSL pour les connexions à Azure Database pour PostgreSQL – Serveur flexible en mettant à jour le paramètre de serveur require_secure_transport sur OFF. Vous pouvez également définir la version de TLS en utilisant les paramètres de serveur ssl_max_protocol_version.

• Données au repos : pour le chiffrement du stockage, Azure Database pour PostgreSQL – Serveur flexible utilise le module de chiffrement conforme à la norme FIPS 140-2. Les données sont chiffrées sur le disque, y compris les sauvegardes et les fichiers temporaires créés durant l’exécution des requêtes.

  Le service utilise le mode Galois/Counter Mode (GCM) avec le chiffrement AES 256 bits inclus dans le chiffrement de stockage Azure et les clés sont gérées par le système. Cela s’apparente à d’autres technologies de chiffrement au repos comme le chiffrement transparent des données (TDE) dans les bases de données SQL Server ou Oracle. Le chiffrement de stockage est toujours activé et ne peut pas être désactivé.

Sécurité du réseau

Quand vous utilisez Azure Database pour PostgreSQL - Serveur flexible, vous avez deux options de réseau principales :

• Accès privé : vous pouvez déployer votre serveur dans un réseau virtuel Azure. Les réseaux virtuels Azure facilitent la mise en place de communications réseau privées et sécurisées. Les ressources incluses sur un réseau virtuel peuvent communiquer par le biais d’adresses IP privées. Pour plus d’informations, consultez la vue d’ensemble de la mise en réseau pour Azure Database pour PostgreSQL - Serveur flexible.

  Les règles de sécurité dans les groupes de sécurité réseau permettent de filtrer le type de trafic réseau qui peut circuler vers et depuis les interfaces réseau et les sous-réseaux de réseau virtuel. Pour plus d’informations, consultez la vue d’ensemble des groupes de sécurité réseau.

• Accès public : le serveur est accessible par le biais d’un point de terminaison public. Le point de terminaison public est une adresse DNS résolvable publiquement. Son accès est sécurisé par un pare-feu qui bloque toutes les connexions par défaut.

  Les règles de pare-feu IP octroient l’accès aux serveurs en fonction de l’adresse IP d’origine de chaque requête. Pour plus d’informations, consultez la vue d’ensemble des règles de pare-feu.

Support de Microsoft Defender pour le cloud

Microsoft Defender pour les bases de données relationnelles open source détecte les activités anormales indiquant des tentatives d’accès ou d’exploitation inhabituelles et potentiellement dangereuses des bases de données. Defender pour le cloud fournit des alertes de sécurité concernant des activités anormales afin que vous puissiez détecter les menaces potentielles et y répondre à mesure qu’elles se produisent. Quand vous activez ce plan, Defender pour le cloud fournit des alertes s’il détecte des modèles de requête et un accès à la base de données anormaux, ainsi que des activités de base de données suspectes.

Ces alertes s’affichent dans la page des alertes de sécurité de Defender pour le cloud et comprennent les informations suivantes :

• Détails de l’activité suspecte qui les a déclenchées
• Tactique MITRE ATT&CK associée
• Actions recommandées pour investiguer et atténuer la menace
• Options pour poursuivre vos investigations avec Microsoft Sentinel

Microsoft Defender pour le cloud et attaques par force brute

Une attaque par force brute compte parmi les méthodes de piratage les plus courantes et qui réussissent plutôt bien, même s’il s’agit d’une méthode de piratage moins sophistiquée. La théorie derrière une telle attaque est que si vous tentez de deviner un mot de passe avec un nombre infini de tentatives, vous allez tomber juste un jour ou l’autre. Lorsque Microsoft Defender pour le cloud détecte une attaque par force brute, il déclenche une alerte pour vous avertir qu’une attaque par force brute a eu lieu. Il peut également faire la distinction entre une attaque par force brute simple, une attaque par force brute sur un utilisateur valide et une attaque par force brute réussie.

Pour recevoir des alertes du plan Microsoft Defender, vous devez d’abord l’activer comme illustré dans la section suivante.

Renforcer la sécurité avec Microsoft Defender pour le cloud

1. Depuis le portail Azure, accédez au menu Sécurité dans le volet gauche
2. Choisir Microsoft Defender pour le cloud
3. Dans le volet droit, sélectionnez Activer.

Gestion de l’accès

La meilleure façon de gérer les autorisations d’accès à la base de données Azure Database pour PostgreSQL – Serveur flexible à grande échelle consiste à utiliser le concept de rôles. Un rôle peut être un utilisateur de base de données ou un groupe d’utilisateurs de base de données. Les rôles peuvent posséder des objets de base de données et attribuer des privilèges sur ces objets à d’autres rôles pour contrôler qui a accès à quels objets. Il est également possible d’accorder une appartenance à un rôle à un autre rôle, ce qui permet au rôle membre d’utiliser les privilèges attribués à un autre rôle. Azure Database pour PostgreSQL – Serveur flexible vous permet d’accorder des autorisations directement aux utilisateurs de la base de données. En guise de bonne pratique de sécurité, il peut être recommandé de créer des rôles avec des ensembles d’autorisations spécifiques en fonction des exigences minimales d’accès et d’application. Vous pouvez ensuite attribuer les rôles appropriés à chaque utilisateur. Les rôles servent à appliquer un modèle de privilèges minimum pour accéder aux objets de base de données.

L’instance Azure Database pour PostgreSQL – Serveur flexible est créée avec les trois rôles par défaut définis, en plus des rôles intégrés créés par PostgreSQL. Vous pouvez voir ces rôles en exécutant la commande :

SELECT rolname FROM pg_roles;

Les rôles sont répertoriés ci-dessous :

• azure_pg_admin
• azuresu
• rôle administrateur

Quand vous créez l’instance Azure Database pour PostgreSQL – Serveur flexible, vous fournissez les informations d’identification d’un rôle Administrateur. Ce rôle Administrateur permet de créer des rôles PostgreSQL supplémentaires.

Par exemple, ci-dessous, nous pouvons créer un exemple d’utilisateur/de rôle appelé « demouser »

 CREATE USER demouser PASSWORD password123;

Le rôle Administrateur ne doit jamais être utilisé par l’application.

Dans les environnements informatiques PaaS, l’accès à un compte de superutilisateur Azure Database pour PostgreSQL – Serveur flexible est limité aux opérations de plan de contrôle uniquement par les opérateurs cloud. Par conséquent, le compte azure_pg_admin existe en tant que compte pseudo-superutilisateur. Votre rôle Administrateur est membre du rôle azure_pg_admin.
Par contre, le compte administrateur de serveur ne fait pas partie du rôle azuresu, qui dispose de privilèges de super-utilisateur et est utilisé pour effectuer des opérations de plan de contrôle. Étant donné que ce service est un service PaaS managé, seul Microsoft fait partie du rôle de super-utilisateur.

Vous pouvez auditer régulièrement la liste des rôles de votre serveur. Par exemple, vous pouvez vous connecter à l’aide du client psql et interroger la table pg_roles qui répertorie tous les rôles et des privilèges tels que ceux qui permettent de créer d’autres rôles, de créer des bases de données, d’effectuer une réplication, etc.

select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

La journalisation d’audit dans Azure DB pour PostgreSQL - Serveur flexible est également disponible avec Azure Database pour PostgreSQL – Serveur flexible pour suivre l’activité dans vos bases de données.

Contrôle de l’accès au schéma

Les bases de données nouvellement créées dans Azure Database pour PostgreSQL – Serveur flexible ont un ensemble de privilèges par défaut dans le schéma public de la base de données qui permettent à tous les utilisateurs et rôles de base de données de créer des objets. Pour mieux limiter l’accès des utilisateurs d’application aux bases de données que vous créez sur votre instance Azure Database pour PostgreSQL – Serveur flexible, nous vous recommandons de révoquer ces privilèges publics par défaut. Après cela, vous pouvez accorder des privilèges spécifiques aux utilisateurs de base de données sur une base de données plus précise. Par exemple :

• Pour empêcher les utilisateurs de base de données d’application de créer des objets dans le schéma public, révoquez les privilèges de création du schéma public du rôle public.

  REVOKE CREATE ON SCHEMA public FROM PUBLIC;
  

• Créez ensuite une base de données.

  CREATE DATABASE Test_db;
  

• Révoquez tous les privilèges du schéma PUBLIC sur cette nouvelle base de données.

  REVOKE ALL ON DATABASE Test_db FROM PUBLIC;
  

• Créer un rôle personnalisé pour les utilisateurs de base de données d’application

  CREATE ROLE Test_db_user;
  

• Donnez aux utilisateurs de base de données disposant de ce rôle la possibilité de se connecter à la base de données.

  GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
  GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;
  

• Créer une base de données

  CREATE USER user1 PASSWORD 'Password_to_change'
  

• Attribuer un rôle, avec ses privilèges de connexion et de sélection à l’utilisateur

  GRANT Test_db_user TO user1;
  

Dans cet exemple, l’utilisateur utilisateur1 peut se connecter et dispose de tous les privilèges dans notre base de données de test Test_db, mais pas dans toute autre base de données sur le serveur. Il serait recommandé, au lieu de donner à cet utilisateur\rôle TOUS LES PRIVILÈGES sur cette base de données et ses objets, de fournir des autorisations plus sélectives, telles que SELECT, INSERT, EXECUTE, etc. Pour plus d’informations sur les privilèges dans les bases de données PostgreSQL, consultez les commandes GRANT et REVOKE dans la documentation PostgreSQL.

Modifications apportée à la propriété de schéma public dans PostgreSQL 15

À partir de la version 15 de Postgres, la propriété du schéma public a été remplacée par le nouveau rôle pg_database_owner. Elle permet à chaque propriétaire de base de données de détenir le schéma public de base de données.
Vous trouverez plus d’informations dans les Notes de publication PostgreSQL.

Modifications apportées à la sécurité basée sur les rôles dans PostgreSQL 16

Dans le rôle de base de données PostgreSQL, vous pouvez avoir beaucoup d’attributs qui définissent ses privilèges. L’un de ces attributs est le CREATEROLE attribut, qui est important pour la gestion des bases de données PostgreSQL des utilisateurs et des rôles. Dans PostgreSQL 16, des modifications importantes ont été introduites à cet attribut. Dans PostgreSQL 16, les utilisateurs disposant d’un attribut CREATEROLE n’ont plus la possibilité de transmettre à n’importe qui l’appartenance à n’importe quel rôle. Au lieu de cela, comme les autres utilisateurs sans cet attribut, ils ne peuvent transmettre l’appartenance qu’aux rôles pour lesquels ils possèdent ADMIN OPTION. En outre, dans PostgreSQL 16, l’attribut CREATEROLE permet toujours à un non-super-utilisateur d’approvisionner de nouveaux utilisateurs, mais ils ne peuvent supprimer que les utilisateurs qu’ils ont créés eux-mêmes. Les tentatives de suppression d’utilisateurs qui ne sont pas créées par un utilisateur disposant de l’attribut CREATEROLE entraînent une erreur.

PostgreSQL 16 a également introduit des rôles intégrés nouveaux et améliorés. Le nouveau rôle pg_use_reserved_connections dans PostgreSQL 16 permet d’utiliser des emplacements de connexion réservés via reserved_connections. Le rôle pg_create_subscription permet aux superutilisateurs de créer des abonnements.

Sécurité au niveau des lignes

La sécurité au niveau des lignes (SNL) est une fonctionnalité de sécurité Azure Database pour PostgreSQL – Serveur flexible qui permet aux administrateurs de base de données de définir des stratégies pour contrôler la façon dont des lignes spécifiques de données s’affichent et fonctionnent pour un ou plusieurs rôles. La sécurité au niveau des lignes est un filtre supplémentaire que vous pouvez appliquer à une table de base de données Azure Database pour PostgreSQL – Serveur flexible. Quand un utilisateur tente d’effectuer une action sur une table, ce filtre est appliqué avant les critères de requête ou d’autres filtrages, et les données sont circonscrites ou rejetées en fonction de votre stratégie de sécurité. Vous pouvez créer des stratégies de sécurité au niveau des lignes pour des commandes spécifiques telles que SELECT, INSERT, UPDATE et DELETE, et les spécifier pour TOUTES les commandes. Les implémentations conformes PCI, les environnements classifiés et les applications d’hébergement partagé et multi-locataires comptent parmi les cas d’usage de la sécurité au niveau des lignes.

Seuls les utilisateurs disposant de droits SET ROW SECURITY peuvent appliquer des droits de sécurité des lignes à une table. Le propriétaire de table peut définir la sécurité des lignes d’une table. Comme OVERRIDE ROW SECURITY, il s’agit actuellement d’un droit implicite. La sécurité au niveau des lignes ne remplace pas les autorisations GRANT existantes ; elle ajoute un niveau de contrôle plus précis. Par exemple, si vous définissez ROW SECURITY FOR SELECT pour autoriser un utilisateur déterminé à accéder à des lignes, cet utilisateur ne bénéficiera d’un accès que s’il dispose aussi de privilèges SELECT sur la colonne ou la table en question.

Voici un exemple montrant comment créer une stratégie qui garantit que seuls les membres du rôle « manager » personnalisé créé peuvent accéder uniquement aux lignes d’un compte spécifique. Le code de l’exemple suivant a été partagé dans la documentation PostgreSQL.

CREATE TABLE accounts (manager text, company text, contact_email text);

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY account_managers ON accounts TO managers
    USING (manager = current_user);

La clause USING ajoute implicitement une clause WITH CHECK, ce qui garantit que les membres du rôle « manager » ne peuvent pas effectuer d’opérations SELECT, DELETE ou UPDATE sur les lignes appartenant à d’autres managers et ne peuvent pas non plus INSERT de nouvelles lignes appartenant à un autre manager. Vous pouvez annuler une stratégie de sécurité de ligne en utilisant la commande DROP POLICY, comme dans cet exemple :

DROP POLICY account_managers ON accounts;

Même si vous avez annulé la stratégie, le gestionnaire de rôles n’est toujours pas en mesure de visualiser les données appartenant à un autre manager. Cela est dû au fait que la stratégie de sécurité au niveau des lignes est toujours activée sur la table des comptes. Si la sécurité au niveau des lignes est activée par défaut, PostgreSQL utilise une stratégie de refus par défaut. Vous pouvez désactiver la sécurité au niveau des lignes, comme dans l’exemple ci-dessous :

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Contournement de la Sécurité au niveau des lignes

PostgreSQL dispose d’autorisations BYPASSRLS et NOBYPASSRLS qui peuvent être affectées à un rôle. NOBYPASSRLS est affectée par défaut. Pour les serveurs nouvellement approvisionnés dans Azure Database pour PostgreSQL - Serveur flexible, le contournement des privilèges de sécurité au niveau des lignes (BYPASSRLS) est implémenté comme suit :

• Pour les serveurs Postgres 16 et les versions ultérieures, nous suivons le comportement standard de PostgreSQL 16. Les utilisateurs non administratifs créés par le rôle d’administrateur azure_pg_admin vous permettent de créer des rôles disposant de l’attribut/du privilège BYPASSRLS, le cas échéant.
• Pour les serveurs Postgres 15 et les versions antérieures. , vous pouvez utiliser l’utilisateur azure_pg_admin pour effectuer des tâches administratives qui nécessitent un privilège BYPASSRLS. Cependant, vous ne pouvez pas créer d’utilisateurs non administratifs avec un privilège BypassRLS, car le rôle d’administrateur n’a pas de privilèges de superutilisateur, comme souvent dans les services PaaS PostgreSQL basés sur le cloud.

Mise à jour des mots de passe

Pour une sécurité accrue, il est recommandé d’effectuer régulièrement une rotation du mot de passe de l’administrateur et des mots de passe des utilisateurs de la base de données. Il est recommandé d’utiliser des mots de passe forts utilisant à la fois des majuscules, des minuscules, des chiffres et des caractères spéciaux.

Utiliser SCRAM

Le SCRAM (Salted Challenge Response Authentication Mechanism) améliore considérablement la sécurité de l’authentification utilisateur par mot de passe, en ajoutant plusieurs fonctionnalités de sécurité clés qui empêchent les attaques par table arc-en-ciel, les attaques par l’intercepteur et les attaques de mot de passe stockées, tout en ajoutant la prise en charge de plusieurs algorithmes de hachage et mots de passe qui contiennent des caractères non ASCII.

Dans l’authentification SCRAM, le client participe au travail de chiffrement afin de produire la preuve d’identité. L’authentification SCRAM décharge donc certains coûts de calcul pour ses clients, qui, dans la plupart des cas, sont des serveurs d’applications. Outre un algorithme de hachage plus fort, l’adoption de SCRAM offre également une protection contre les attaques par déni de service distribué (DDoS) contre PostgreSQL, en empêchant une surcharge du processeur du serveur pour calculer les hachages de mot de passe.

Si le pilote de votre client prend en charge SCRAM, vous pouvez configurer l’accès à Azure Database pour PostgreSQL - Serveur flexible en utilisant SCRAM comme scram-sha-256 par rapport à la valeur par défaut md5.

Réinitialiser le mot de passe de l’administrateur

Suivez le guide de procédure sur la réinitialisation du mot de passe de l’administrateur.

Mettre à jour le mot de passe des utilisateurs de la base de données

Vous pouvez utiliser les outils clients pour mettre à jour les mots de passe des utilisateurs de la base de données.
Par exemple,

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Prise en charge d’Azure Policy

Azure Policy aide à appliquer les normes organisationnelles et à évaluer la conformité à grande échelle. Avec son tableau de bord de conformité, il fournit une vue agrégée permettant d’évaluer l’état général de l’environnement, avec la possibilité d’explorer au niveau de chaque ressource et stratégie. Il vous aide également à mettre vos ressources en conformité par le biais de la correction en bloc pour les ressources existantes et de la correction automatique pour les nouvelles ressources.

Définitions de stratégie intégrées

Les stratégies intégrées sont développées et testées par Microsoft, en s’assurant qu’elles répondent aux normes et bonnes pratiques courantes, un déploiement rapide sans avoir besoin d’une configuration supplémentaire, ce qui les rend idéales pour les exigences de conformité standard. Les stratégies intégrées couvrent souvent des normes et des infrastructures de conformité largement reconnues.

La section ci-dessous fournit un index des définitions de stratégie intégrées Azure Policy pour Azure Database pour PostgreSQL : serveur flexible. Utilisez le lien de la colonne Source pour voir la source dans le dépôt GitHub Azure Policy.

Définitions de stratégies personnalisées

Les stratégies personnalisées peuvent être adaptées avec précision pour répondre aux exigences spécifiques de votre organisation, y compris les stratégies de sécurité uniques ou les mandats de conformité. Avec des stratégies personnalisées, vous avez un contrôle total sur la logique et les paramètres de stratégie, ce qui permet de définir des définitions de stratégie sophistiquées et affinées.

Contenu connexe

• Règles de pare-feu pour les adresses IP
• Réseaux d’accès privé avec Azure Database pour PostgreSQL - Serveur flexible
• Authentification Microsoft Entra