IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La majorité des serveurs PostgreSQL sur Internet ne seraient pas sécurisés, selon Jonathan Mortensen,
Alors qu'il est souvent considéré comme un système plus fiable et plus robuste que MySQL

Le , par Bruno
5 commentaires

211PARTAGES

6  1 
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

5 commentaires
Commenter Signaler un problème
SQLpro
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 20/10/2022 à 15:05
Citation Envoyé par Escapetiger Voir le message
Je reviens sur ce point précis (parce que les écritures sont effectuées par la couche système), c'est parce que les paramètres fondamentaux «système/sécurité» ne sont pas appliqués :

«
General recommendation #2: Use Direct I/O for the transaction logs.

Using Direct I/O for your database workloads can greatly improve the overall reliability of your database workload's operations. By using Direct I/O, the database bypasses the Linux page cache and writes directly to the disks, thus avoiding loss of transactions in case of a failure.....
Cela n'a rien à voir avec le sécurité. Linux ne permet pas de verrouiller les fichiers accédés par un service de manière exclusive et durable. Dès que l'écriture est terminée, Linux rend la main et le fichier peut être accédé par un autre service ou un autre utilisateur pourvu des droits adéquats, donc supprimés par un malfrat. Je m'amuse toujours à montrer ceci dans des démos sur la mauvaise sécurisation de MySQL et PostGreSQL sur Linux et Windows...

Ce que tu invoques en fait c'est le fait que PostGreSQL a pendant 20 ans laissé le système par défaut d'écriture asynchrone permettant des corruptions de base....

"Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données"
4  0 
krysztophe
Avatar de krysztophe
Membre à l'essai https://www.developpez.com
Le 19/10/2022 à 19:45
Pour résumer :
- la sensibilisation au SSL a encore des progrès à faire hors du contexte des serveurs web,
- ceux qui installent PG ne configurent pas souvent le SSL, ou avec un certificat autosigné [NB : l'autosigné est par défaut sous Debian/Ubuntu, hélas pas sur Red Hat/CentOS...]
- des conseils techniques sur comment le mettre en place
- les outils clients [indépendamment de la base...] sont laxistes et n'exigent pas le SSL, honte à eux.

Tous les serveurs de prod PG que je vois ne sont de toute façon pas en frontal sur internet, mais derrière moults pare-feux, bastions et VPN (certes, ça n'excuse pas).
Pour tous les amateurs qui bricolent et permettent des connexions en local, ça ne m'étonne pas qu'ils ne pensent pas à quelque chose que les webmasters n'ont généralisé que dans les dernières années.
3  0 
SQLpro
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 11/10/2022 à 11:08
Pour information, un de nos clients a eu tous ses serveur PostGreSQL, MySQL et Oracle sous Linux atteints par une chiffrement des fichiers des bases, à l'exception des fichiers des bases SQL Server sous Windows. En effet, PostGreSQL et MySQL que ce soit sous Linux ou Windows ne peuvent verrouiller de manière exclusive les fichiers pendant toute leur utilisation parce que les écritures sont effectuées par la couche système et le nombre de fichiers à verrouiller est trop important et enfin, Linux (Open source) ne permet pas ce mode de verrouillage qui n'existe que dans Windows. Dans SQL Server tous les fichiers des bases étant verrouillé de manière exclusive par l'instance SQL, toute atteinte est impossible. Ce client, et ce n'est pas le seul, a vu toutes ses bases perdues... sauf les bases SQL Server et Oracle sous Windows...

La majorité des attaques se concentrent sous Linux, car moins sécurisé et en particulier sur les SGBD open source, plus "ouvert" et donc plus faciles à pirater...

A +
3  1 
Mingolito
Avatar de Mingolito
Expert éminent https://www.developpez.com
Le 10/10/2022 à 16:22
C'est pas pire que les 50% de bases Elasticsearch ouvertes à tout vent.
La cause : logiciels mal foutus, informaticiens bon à riens et irresponsables, et DI/DSI incompétents.
1  0 
Escapetiger
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 20/10/2022 à 11:35
Citation Envoyé par SQLpro Voir le message
En effet, PostGreSQL et MySQL que ce soit sous Linux ou Windows ne peuvent verrouiller de manière exclusive les fichiers pendant toute leur utilisation parce que les écritures sont effectuées par la couche système et le nombre de fichiers à verrouiller est trop important et enfin, Linux (Open source) ne permet pas ce mode de verrouillage qui n'existe que dans Windows. Dans SQL Server tous les fichiers des bases étant verrouillé de manière exclusive par l'instance SQL, toute atteinte est impossible. Ce client, et ce n'est pas le seul, a vu toutes ses bases perdues... sauf les bases SQL Server et Oracle sous Windows...

La majorité des attaques se concentrent sous Linux, car moins sécurisé et en particulier sur les SGBD open source, plus "ouvert" et donc plus faciles à pirater...

A +
Je reviens sur ce point précis (parce que les écritures sont effectuées par la couche système), c'est parce que les paramètres fondamentaux «système/sécurité» ne sont pas appliqués :

«
General recommendation #2: Use Direct I/O for the transaction logs.

Using Direct I/O for your database workloads can greatly improve the overall reliability of your database workload's operations. By using Direct I/O, the database bypasses the Linux page cache and writes directly to the disks, thus avoiding loss of transactions in case of a failure.

So how much of an impact does the usage of Direct I/O have on performance? In our test cases, the impact was significantly less than one percent. In benchmarking, this is generally considered white noise.
»

Source : PostgreSQL: Experiences and tuning recommendations on Linux on IBM Z - IBM Developer

De mémoire, les bases Oracle sur Unix également sont/étaient toutes installées en mode Direct I/O, je suppose qu'il en est de même sur Linux de nos jours.
1  0