Discussion :

[Antoun]

Bonjour à tous,

Je dois donner un cours de SQL, habituellement je m'appuie sur MySQL, comme ce groupe-là suit un cursus axé sur la sécurité informatique, je m'étais dit que la gestion de la sécurité par MySQL était trop bizarre et que j'allais passer sur PostgreSQL.

Je commence à découvrir cet aspect-là de PG, et je crois comprendre que tous les utilisateurs ont toujours le droit de voir toutes les databases, tous les schémas et tous les objets de schéma, même s'ils n'y ont pas pas accès ???

Est-ce que je n'ai rien compris ? Est-ce qu'il y a un moyen d'empêcher cela ?

Merci d'avance pour vos lumières !

[ced]

Salut Antoun,

Je commence à découvrir cet aspect-là de PG, et je crois comprendre que tous les utilisateurs ont toujours le droit de voir toutes les databases, tous les schémas et tous les objets de schéma, même s'ils n'y ont pas pas accès ???

Non, heureusement... Déjà, il faut que l'utilisateur puisse se connecter à l'instance (via le fichier pg_hba.conf).
Ensuite, il faut qu'il est les droits pour se connecter à une base de données (GRANT CONNECT...).
Puis, qu'il ait les droits d'utiliser un schéma (GRANT USAGE...).
Et enfin qu'il ait les droits de lecture / écriture / exécution / etc. sur les différents objets du schéma.

ced

[escartefigue]

C'est une très bonne chose de ne pas avoir retenu MySQL comme base d'apprentissage pour la gestion des privilèges.
En effet, MySQL ne connait pas la notion de schéma SQL, puisqu'il la confond avec la notion de database ce qui n'a absolument rien à voir !
Quand on sait à quel point les schémas SQL sont importants vis à vis des privilèges (grant / revoke), l'impasse faite par MySQL est un choix pour le moins curieux et très gênant
Notez qu'on parle de "privilèges" plutôt que de "droits"
D'autres aspects liés à la sécurité seront sans doute à aborder, comme le cryptage des données, la qualité des mots de passe, le piratage...

[SQLpro]

Je viens de réaliser pour un de mes clients une comparaison de la sécurité de MySQmerde... En voici un extrait...

Fonctionnalité	MySQL / MariaDB
Compte de service (ou de daemon)	Souvent root !
Paramétrage du SGBD	Dans un fichier texte (1)
Compte d’administrateur	La gestion des comptes d’administrateur nécessite souvent l’utilisation du compte « root » qui à tout pouvoir sur la machine et est généralement et par défaut aussi DBA du SGBDR
Base de données et schémas SQL	Confusion entre base de données et schémas SQL
Structure de stockage des bases	Multiples fichiers à raison d’au moins 1 par table, voire plusieurs avec stockage délégué à la couche OS (2)
Protection des fichiers des bases	Aucune : les fichiers peuvent être copier ou supprimer pendant le fonctionnement du serveur (3)
READ ONLY au niveau stockage	Impossible (4)
READ ONLY au niveau base	Impossible (4)
Journal de transactions	Un seul pour toutes les bases/schéma SQL
Chiffrement transparent du stockage (TDE) (5)	N’existe pas dans la version communautaire. Nécessite un accès Cloud ou la version Enterprise. Dans tous les cas une dégradation importante des performances globales des IO de 50 à 70 % Les données de sauvegarde restent en clair (non chiffrées) (6)
Sécurité de niveau « instance »	N’existe pas
Sécurité de niveau base de données	Utilisateur SQL ayant des privilèges sur tous les objets
Authentification	Uniquement au niveau utilisateur SQL
Gestion des privilèges	Incohérente (viol de la hiérarchie) (7)
Cloisonnement par base de données	Impossible (la confusion entre schéma SQL et base de données ne permet aucun cloisonnement de même, le journal de transaction est partagé par toutes les bases)
Chiffrement du mot de passe	Via hachage par SHA-1 (160 bits) non salé (8)
Sécurité au niveau ligne	Partiellement implémentée (fonction non déterministe)
Masquage des données	Externe via MaxScale 2.0
Impersonnalisation (9)	NON
Dépersonnalisation (9)	NON
Déclencheur à la connexion	NON
Déclencheur DDL (CREATE, ALTER, DROP…) (10)	N’existe pas
Traçage automatique des connexions	NON
Chiffrement des données	Par plugin externe, avec l’algorithme AES 128, 192 ou 256 bits.
Chiffrement de bout en bout	NON
Salage automatique du chiffrement	N’existe pas (8)
Protection des clés de chiffrement	Non, sauf pour MySQL Enterprise avec un outil supplémentaire d’Oracle
Exposition des clés	Oui
Sécurisation des clés par HSM (11)	Impossible, sauf version Enterprise
Enclave sécurisées	NON
Historisation automatique des données	NON, sauf version Enterprise payante (implémentation partielle non conforme à la norme SQL) (12)
Traçage des transactions via BlockChain	NON
Compression des données (13)	NON
Protection des LOBs (14) externalisés (15)	IMPOSSIBLE
Cohérence de sauvegardes des LOBs (14) externalisés (15)	IMPOSSIBLE sans arrêter tous les systèmes en effectuant une copie.
Audit de securité	MySQL continue à fonctionner si le système d’audit de sécurité ne peut plus tracer les données (saturation d’un disque par exemple)….(16)

Quelques explications :
(1) Le paramétrage d’un SGBDR dans un fichier texte en dehors du scope de sécurité du SGBDR constitue une vulnérabilité car il est possible de modifier le fichier sans avoir les privilèges d’accéder au SGBDR et dans ce cas par exemple d’allouer une mémoire cache voisine de zéro afin de faire tomber le serveur pour le rendre inaccessible (attaque par déni de service)
(2) MySQL ne gère pas son stockage et le délègue à la couche OS, contrairement à Oracle, IBM DB2 ou SQL Server dont le moteur de stockage créé des volumes systèmes (équivalent de disques virtuels) spécifiquement formaté et assure ses propres routines de lecture et d’écriture des fichiers sans passer par la couche système de l’OS, à la fois pour des raisons de sécurité et de performance…
(3) Linux ne permet pas de verrouiller de manière exclusive les fichiers pour un service (daemon) particulier.
(4) La commande SET GLOBAL read_only agit pour toutes les bases de données.
(5) Transparent Data Encryption (chiffrement transparent des données) permet de chiffrer le stockage des fichiers de la base. Le moteur de stockage déchiffre à la volée au moment des lecture et chiffre à la volée au moment de l’écriture, ce qui fait que le vol des fichiers d’une base ou le vol d’une sauvegarde n’est pas utilisable.
(6) Pour plus de détail voire l’article de David Baffaleuf : https://blog.capdata.fr/index.php/qu...mysql-mariadb/
(7) Dans MySQL/MariaDB, un utilisateur dépourvu d’accès à une table, peut quand même lire et écrire les données de cette table à travers un autre objet tel qu’une vue si on lui en donne l’accès !
(8) Le salage du chiffrement est indispensable dans les données des bases. En effet, les bases de données portant d’importantes collections de données, une attaque par analyse fréquentielle des données chiffrée est aisé sur des données dont on connait la distribution statistique, comme les noms (voir https://www.geneanet.org/genealogie/), les prénoms (https://www.insee.fr/fr/statistiques...mmaire=7635552), les données comptables (loi de Benford), les numéros de sécurité sociale…
(9) L’impersonnalisation ou la dépersonnalisation de routines permet d’exécuter un bloc de code sous le contrôle d’une entité de sécurité différente possédant des privilèges plus étendu nécessaire à des actions temporaires sans la rendre visible à l’utilisateur (délégation). Par exemple, pour un utilisateur n’ayant que des permissions de lecture, insérer une ligne dans une table pour indiquer le moment ou il s’est connecté en dépersonnalisant la routine…
(10) Les déclencheurs de connexion (trigger « LOGON ») permettent de contrôler les accès, par exemple pour limiter le nombre des sessions autorisées sur un même compte de connexion, ou de tracer les paramètres de la connexion.
(11) Les HSM (Hardware Security Module) comme celui de Thales (Luna) permettent le stockage des clés de chiffrement dans des boitiers externes inviolables. En cas de tentative d’intrusion électronique ou mécanique, l’électronique est détruite par une action chimique visant à anéantir physiquement les composants électroniques.
(12) Notamment pas de choix du nom des colonnes de temporalisation des données qui peuvent conduire à un télescopage logique.
(13) Les techniques de compression des données des bases ne nécessitent pas de décompression pour accéder aux données dans SQL Server, sauf pour la compression ZIP qui n’est réellement utilisable que pour les LOBs. Le gain est donc double : en volume et en temps d’accès. Le revers de la médaille est un temps d’écriture un peu plus long.
(14) Les LOBs ou Large Object communément appelés BLOBs, sont des données de grandes dimensions, souvent utilisés en mode binaire pour stocker des fichiers électroniques, des images, du son, de la vidéo…
(15) le DATALINK (norme SQL) permet de gérer des fichiers de données (pdf, photos, sons…) stockés à titre de fichier dans le « file système » sous le contrôle et la sécurité du Serveur SQL (transactionnement, anonymisation, droits d’accès en lecture écriture…).
(16) Dans ce cas il suffit de bloquer le système de trace pour corrompre les données en toute impunité...

Cela dit, la moitié de ce que tu viens de lire s'applique aussi à PostGreSQL !!!

A +

[Michel.Priori]

Je viens de réaliser pour un de mes clients une comparaison de la sécurité de MySQmerde...
[...]
Cela dit, la moitié de ce que tu viens de lire s'applique aussi à PostGreSQL !!!

De ce que je constate en entreprise c'est que 90% et + des logiciels du marché exigent d'être à minima Db_owner (si ce n'est sysadmin, db_creator, ...) pour le compte applicatif.
Sans parler du cas des BI qui veulent simplement capturer le CDC et qui se retrouvent avec des droits largement supérieurs qu'une simple lecture.
Ajoutons le modèle de sécurité des "serveurs liés" ou du fait que M$ SQL server n'accepte pas les upn (utiliser l'adresse mail comme nom de compte) comme authentification valide.

Avoir, pour un produit donné, un catalogue de possibilité de sécurisation c'est effectivement rassurant.
Que ce même catalogue soit totalement cohérent relève de l'exploit. Faut s'attendre à faire des compromis (c'est ce qu'on fait juste avant la compromission )
Et que les principes simples de sécurité soient effectivement appliqués, n'est possible que par un périmètre réduit avec une équipe réduite. (Ce qui correspond à la définition d'une PME, qui n'a pas forcément les moyens d'une sécurité de haut vol.)

N'oublions pas que la sécurité va à l'encontre de l'opérationnalité : si on met un verrou sur une porte c'est pour pas qu'elle puisse s'ouvrir.
Alors que l'objectif d'une entreprise est de créer de la richesse, les mesures de conservations (sécurité, PRA, ...) ont un budget relatif à l'assurance.

Pour être efficace le modèle doit être simple (et pas simpliste) et maintenable sur la durée.
A ce jeux, je rejoins Frédéric, M$ Sql server est très bien placé malgré les zones d'ombres.

J'en profite pour lancer un appel : faire que Pg accepte les groupes AD, à l'image de Linux.

[Antoun]

Salut Antoun,
Non, heureusement... Déjà, il faut que l'utilisateur puisse se connecter à l'instance (via le fichier pg_hba.conf).
Ensuite, il faut qu'il est les droits pour se connecter à une base de données (GRANT CONNECT...).
Puis, qu'il ait les droits d'utiliser un schéma (GRANT USAGE...).
Et enfin qu'il ait les droits de lecture / écriture / exécution / etc. sur les différents objets du schéma.
ced

Salut ced, et merci pour ta réponse !
Il doit y avoir un truc que je fais de travers. Voici ce que je fais côté admin, sur une instance nouvellement créée et la base postgres.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
-- côté admin
create role antoine login password 'password' ; 
create role etudiants inherit ;
grant etudiants to antoine ; 
 
create schema secret ;
create table secret.tresors (num INT) ;
 
revoke usage on schema secret from etudiants ; 
revoke usage on schema secret from antoine ; 
revoke usage on schema secret from public ;

Maintenant, je me connecte en tant que antoine par pgAdmin, et je vois tous les objets :

Je me suis dit que ça pouvait être une extrapolation de pgAdmin où mon compte admin est ouvert, donc je me connecte en tant qu'antoine sur DBeaver qui ne connaît pas mon compte admin, et c'est la même chose :


Quand maintenant je teste un SELECT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from secret.tresors t ;

SQL Error [42501]: ERROR: permission denied for schema secret
Position*: 15

Je confirme donc que je vois la table alors que je n'ai ni USAGE ni SELECT !

Autre test avec un résultat rigolo : quand j'interroge information_schema en tant qu'antoine, je ne vois ni le schéma secret ni la table tresors. Par contre, quand je regarde pgcatalog, je vois tout !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select * from information_schema.schemata ; 
select * from information_schema.tables where table_schema = 'secret' ;
 
select * from pg_catalog.pg_tables where schemaname = 'secret' ;

C'est quoi que j'ai raté ?

[ced]

Tu n'as rien raté...
PgAdmin et DBeaver interrogent tous les deux le catalogue de PostgreSQL qui est dans le schéma pg_catalog, et pas information_schema.
Par défaut, les droits de lecture sont accordés sur les différents objets (tables et vues) de pg_catalog au groupe PUBLIC. Ce qui explique pourquoi tu vois toujours la liste des objets de ton schéma.

Mais tout cela reste configurable en enlevant les droits des utilisateurs sur les objets de ce schéma.

Une des curiosités de PostgreSQL, c'est qu'il n'accorde pas par défaut les mêmes droits sur pg_catalog et sur information_schema...

ced

[Antoun]

Mais tout cela reste configurable en enlevant les droits des utilisateurs sur les objets de ce schéma.

J'ai révoqué le SELECT, qu'est-ce que je doit retirer d'autre pour que mon utilisateur test ne voit plus la table dans le pg_catalog ?

[ced]

Comme ça, je dirais retirer l'usage du schéma pg_catalog...

À tester, je n'ai jamais eu besoin de le mettre en œuvre.

ced