Gestion des accès et sécurité

Imagine un vrai cauchemar : t'es admin de base de données, et d'un coup, une table importante avec les données clients... disparaît. Qui a fait ça ? Pourquoi ? Peut-être que c'est une erreur d'un stagiaire pas très expérimenté qui a tapé DROP TABLE par accident. Ou alors, c'était un utilisateur malveillant qui avait accès à la base... Peu importe, c'est trop tard pour paniquer ! Il ne te reste qu'à te réveiller, reprendre tes esprits et te plonger dans la sécurité des bases de données. Parce qu'une base sans sécurité, c'est comme une maison sans fondations.

Pour les bases de données, la sécurité doit être au top pour éviter des menaces comme :

• Accès non autorisé : quelqu'un accède à des données auxquelles il n'a pas droit.
• Fuite de données : des mots de passe, cartes bancaires ou infos confidentielles tombent entre de mauvaises mains.
• Injections SQL : une technique sournoise qui permet à un attaquant de manipuler ta base via des requêtes mal protégées.
• Erreurs humaines : suppression accidentelle de données ou modification impossible à annuler.

Dans PostgreSQL, la sécurité est gérée à plusieurs niveaux : de la création de rôles et gestion des droits jusqu'à la limitation de l'accès réseau. Ça permet de configurer précisément qui peut faire quoi avec tes données.

Niveaux principaux de sécurité dans PostgreSQL

Dans PostgreSQL, il y a trois niveaux principaux où tu peux gérer les accès :

1. Gestion des accès au niveau de la base de données. À ce niveau, tu décides qui peut se connecter à ta base et ce qu'il peut faire une fois connecté. Par exemple, tu peux interdire à certains utilisateurs d'entrer dans la base. D'autres — leur donner juste le droit de lire les données. L'outil clé ici, c'est les rôles.

2. Contrôle d'accès au niveau des tables, lignes et colonnes.

Dans PostgreSQL, tu peux limiter l'accès aux données de façon très précise. Tu peux :

• Autoriser un utilisateur à lire seulement certaines colonnes.
• Autoriser la lecture des données d'une table seulement si l'utilisateur est le propriétaire de la ligne. Ça s'appelle ROW LEVEL SECURITY (RLS), et on va voir ça en détail dans les prochaines leçons.
• Limiter l'accès uniquement à certaines parties de la base (schémas) où se trouvent les données sensibles.

3. Configuration de l'accès réseau. La base de données peut être configurée pour accepter les requêtes seulement de clients de confiance. Ça se règle via le fichier de config PostgreSQL qui s'appelle pg_hba.conf. Avec ce fichier, tu peux par exemple autoriser la connexion seulement depuis la machine locale ou certaines adresses IP.

Outils de sécurité PostgreSQL

Voyons un peu quels outils de sécurité PostgreSQL propose et comment ça marche en vrai.

On commence par les rôles et privilèges — c'est la base du système de gestion des accès. Dans PostgreSQL, un rôle, ce n'est pas juste un utilisateur, c'est plus flexible. Ça peut représenter une personne ou tout un groupe. Par exemple, tu peux créer un rôle qui s'appelle manager et qui a tous les droits sur la table des commandes, alors que le stagiaire aura le rôle intern avec juste les droits en lecture — histoire qu'il ne casse rien par accident.

Les rôles sont super configurables : tu peux donner plus ou moins de droits à chacun, et même permettre à un rôle d'hériter des droits d'un autre. C'est ça qui détermine qui peut se connecter à la base, quels schémas et tables sont accessibles, et même quelles lignes on peut voir ou modifier.

Ensuite, il y a les fichiers de configuration. Dans PostgreSQL, il y a deux fichiers de config principaux qui jouent un rôle clé pour la sécurité.

Le premier, c'est pg_hba.conf. Il gère l'accès réseau à la base. C'est là que tu règles qui a le droit de se connecter au serveur, depuis quelle adresse IP et comment l'authentification va se passer. Si tu veux limiter l'accès à certaines machines ou utilisateurs — c'est ici que ça se passe.

Le deuxième fichier, c'est postgresql.conf. Il gère les paramètres globaux du serveur, et notamment les options de logs et d'audit. Ça permet de surveiller qui fait quoi, de repérer les activités suspectes et d'enquêter si besoin.

Enfin, logs et audit. "Les logs, c'est ton meilleur pote". Ça sonne bizarre, mais pour un admin de base de données, c'est la règle numéro un. Dans PostgreSQL, tu peux configurer les logs pour enregistrer toutes les requêtes et actions des utilisateurs. Ça aide à comprendre qui a fait quoi si jamais il y a un souci.

Exemple : protéger les données contre les injections SQL

Les injections SQL, c'est un des moyens d'attaque les plus courants contre une base de données. Et il faut vraiment savoir s'en protéger. Imagine que t'as une appli où l'utilisateur entre l'ID de son compte pour voir son profil. Et l'appli lance une requête comme ça :

SELECT * FROM users WHERE id = 123;

Mais si l'utilisateur tape 123 OR 1=1 au lieu d'un nombre ? La requête devient :

SELECT * FROM users WHERE id = 123 OR 1=1;

Et au lieu d'une seule ligne, toute la table users devient accessible.

Comment se protéger ? PostgreSQL te permet d'utiliser des requêtes paramétrées ou des commandes préparées (PREPARE et EXECUTE), pour que les données utilisateur ne soient jamais mélangées au code SQL. Voilà à quoi ça ressemble :

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

D'autres exemples de vraies menaces

Pour que tu comprennes bien pourquoi la sécurité est importante, voici deux scénarios réels :

Exemple 1 : "Un employé a supprimé toute la table"

Un jour, dans une boîte (en vrai, ça arrive souvent, et dans plein d'entreprises...) un stagiaire a tapé dans la console :

DROP TABLE employees;

Et 10 ans de données sur les employés sont partis en fumée. Comment éviter ça ?

• Gère bien les droits ! Par exemple, le rôle intern ne devrait avoir que la lecture.
• Configure l'audit ! Les logs te diront qui a lancé la commande fatale.

Exemple 2 : "Fuite de données via une connexion non chiffrée"

Si un utilisateur se connecte au serveur PostgreSQL sans chiffrement, son login et mot de passe peuvent être interceptés par un attaquant. Configure SSL et assure-toi que les connexions sont sécurisées.

Tâches clés pour les admins

Pour finir cette intro, voici les trois missions principales de tout admin PostgreSQL :

• Contrôle des accès. Vérifie que seuls les utilisateurs autorisés peuvent faire certaines actions.
• Chiffrement. Les données sensibles doivent toujours être stockées et transmises de façon chiffrée.
• Surveillance. Mets en place l'audit et surveille les activités suspectes dans les logs.

Dans les prochaines leçons, tu verras comment créer des rôles, gérer les accès avec GRANT et REVOKE, mettre en place le contrôle d'accès au niveau des lignes et utiliser le chiffrement pour protéger les données.