« La sécurité d’une base de données, c’est comme un bon mot de passe : tu peux inventer la clé la plus compliquée, mais si tu la colles sur un post-it sur ton écran, ça sert à rien. » Donc notre but, c’est pas juste de mettre en place des mécanismes de protection, mais aussi d’éviter les erreurs classiques qui peuvent tout foutre en l’air.
1. Utiliser des rôles avec trop de droits
Souvent, les devs ont peur de limiter l’accès et créent des rôles avec des privilèges trop larges, genre ils filent SUPERUSER ou ALL PRIVILEGES. Leur argument c’est : « On sait jamais, ça peut servir ! ». Mais filer trop de droits, c’est ouvrir une énorme faille de sécurité.
Exemple de droits excessifs :
GRANT ALL PRIVILEGES ON DATABASE university TO student_role;
Ici, student_role a accès à toutes les données de la base. Même si ce rôle devait juste lire, il peut maintenant supprimer des tables, changer la structure et même retirer l’accès à l’admin.
Comment éviter ça ?
Crée des rôles avec le minimum de droits. C’est le principe du moindre privilège. Par exemple, un rôle juste pour lire les données devrait ressembler à ça :GRANT CONNECT ON DATABASE university TO student_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO student_role;
Avec cette approche, tu sais exactement ce que student_role peut faire : se connecter à la base et juste lire.
2. Pas de chiffrement des données sensibles
Imagine une table users où on stocke les mots de passe en clair :
CREATE TABLE users (
id SERIAL PRIMARY KEY,
username TEXT NOT NULL,
password TEXT NOT NULL
);
Si un pirate chope cette table, il a tous les mots de passe. C’est comme cacher les clés de chez toi sous le paillasson.
Pour éviter ça, utilise le chiffrement des mots de passe avec pgcrypto. Par exemple :
CREATE EXTENSION IF NOT EXISTS pgcrypto;
INSERT INTO users (username, password)
VALUES ('johndoe', pgp_sym_encrypt('mot_de_passe_sécurisé', 'clé_de_chiffrement'));Pour vérifier un mot de passe, tu peux déchiffrer comme ça :
SELECT username
FROM users
WHERE pgp_sym_decrypt(password::BYTEA, 'clé_de_chiffrement') = 'mot_de_passe_sécurisé';
Ne stocke jamais d’infos sensibles en clair !
3. Ignorer les injections SQL
Les injections SQL restent une des attaques les plus courantes, parce que les devs continuent de construire des requêtes avec de l’interpolation de chaînes. Exemple :
DO $$
DECLARE
username TEXT := 'John';
query TEXT;
BEGIN
query := 'SELECT * FROM users WHERE username = ''' || username || ''';';
EXECUTE query;
END $$;
Si un pirate met à la place du nom d’utilisateur John' OR '1'='1, il récupère toutes les données de la table users.
Comment éviter ça ? Utilise des requêtes paramétrées :
PREPARE user_query (TEXT) AS
SELECT * FROM users WHERE username = $1;
EXECUTE user_query('John');Là, la variable est insérée de façon safe, donc pas d’injection possible.
4. Mauvaise config de pg_hba.conf
pg_hba.conf — c’est l’outil principal pour contrôler l’accès par IP. Une erreur dans ce fichier et l’accès peut être bien trop large.
Exemple de mauvaise config :
host all all 0.0.0.0/0 trust
Cette ligne autorise n’importe qui à se connecter à n’importe quelle base depuis n’importe quelle IP, sans mot de passe.
Comment éviter ça ? Autorise l’accès seulement pour des IP précises et utilise l’authentification md5 ou scram-sha-256 :
host university student_role 192.168.1.0/24 md5
Ça limite l’accès de student_role au réseau local, avec mot de passe.
Après avoir modifié pg_hba.conf, pense à recharger la config avec :
pg_ctl reload
5. Mauvaise utilisation de ROW LEVEL SECURITY
RLS — c’est super puissant, mais ça sert à rien si c’est mal configuré ou oublié. Par exemple, même si tu écris une policy d’accès, elle ne marche pas si RLS est désactivé :
CREATE POLICY ma_politique ON users
USING (username = current_user);
-- Mais RLS n’est pas activé !
SELECT * FROM users; -- On voit toutes les lignes !Comment éviter ça ? N’oublie pas d’activer RLS :
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
Et vérifie comment la policy s’applique :
SET ROLE student_role;
SELECT * FROM users; -- On ne voit que les lignes autorisées par la policy.6. Actions admin non prises en compte
Parfois, les admins de la base ont accès à toutes les données, même si ce n’est pas nécessaire pour leur taf. Si leur compte est compromis, c’est un risque de fuite énorme.
Comment éviter ça ? Sépare les rôles. Pour l’admin, crée un rôle sans accès aux données :
CREATE ROLE admin_role WITH LOGIN CREATEDB CREATEROLE;
Pour l’accès aux données, crée un autre rôle avec le minimum de droits :
CREATE ROLE data_analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO data_analyst_role;
Assigne les rôles aux utilisateurs selon leurs besoins :
GRANT admin_role TO some_user;
GRANT data_analyst_role TO another_user;
7. Logs insuffisants
Si tu ne configures pas les logs, tu ne verras jamais les actions suspectes avant qu’il soit trop tard.
Exemple d’absence de logs :
-- Aucune config dans le fichier postgresql.conf
log_statement = 'none';
Comment éviter ça ? Active au moins les logs de base :
log_statement = 'all'
log_connections = on
log_disconnections = on
Comme ça, tu vois toutes les requêtes, connexions et déconnexions.
Tu peux aussi activer l’audit avec l’extension pgAudit pour un contrôle plus fin :
CREATE EXTENSION pgaudit;
8. Utiliser des méthodes d’authentification dépassées
Utiliser des méthodes d’authentification comme password, c’est plus assez sécurisé.
Comment éviter ça ? Passe à des méthodes plus sûres comme scram-sha-256 :
ALTER SYSTEM SET password_encryption = 'scram-sha-256';
Et mets à jour les mots de passe des utilisateurs :
ALTER USER student_role WITH PASSWORD 'nouveau_mot_de_passe_sécurisé';
Ça peut paraître des détails, mais chacune de ces erreurs peut devenir une grosse faille de sécurité. Ton job, c’est de gérer la base comme si chaque utilisateur qui essaie de se connecter était suspect. Comme on dit, « fais confiance, mais vérifie ». Maintenant, t’as les outils pour sécuriser ta base et éviter les erreurs les plus courantes. Bonne chance, et que tes données restent safe !
GO TO FULL VERSION