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_transportsur OFF. Vous pouvez également définir la version de TLS en utilisant les paramètres de serveurssl_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 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
- Depuis le portail Azure, accédez au menu Sécurité dans le volet gauche
- Choisir Microsoft Defender pour le cloud
- Dans le volet droit, sélectionnez Activer.
Remarque
Si la fonctionnalité « bases de données relationnelles open source » est activée dans votre plan Microsoft Defender, vous remarquerez que Microsoft Defender est automatiquement activé par défaut pour votre ressource de serveur flexible Azure Database pour PostgreSQL.
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. 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 liste tous les rôles ainsi que les privilèges comme ceux qui permettent de créer des rôles supplémentaires, 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
Il est important de noter que le nombre d’autorisations réservées au superutilisateur, comme la création de certaines casts implicites, n’est pas disponible avec Azure Database pour PostgreSQL – Serveur flexible, car le rôle azure_pg_admin ne s’aligne pas sur les permissions de PostgreSQL du rôle de superutilisateur.
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
publicdu rôlepublic.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é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 pu annuler 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 avec l’attribut ou le 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 des privilèges BYPASSRLS. Cependant, vous ne pouvez pas créer d’utilisateurs non administratifs avec le privilège BypassRLS, car le rôle d’administrateur n’a pas de privilèges de superutilisateur, comme souvent dans les services de 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