Isolation des comptes et locataires

Méthode de contrôle

Vérifie que les politiques limitent les lignes à leur propriétaire et non à tout utilisateur connecté.

Type de preuve possible

Lecture du code ou de la configuration, sans exploitation du risque.

Accès et limites

Accès autorisé à la base de données compatible. Les résultats réels et les contrôles non exécutés figurent dans votre rapport. Un contrôle sans détection ne garantit pas l’absence de risque.

Situation concrète

Un compte de l’espace A lit un objet de l’espace B.

Ce qu’il faut examiner

Examiner périmètre dans requêtes, politiques, stockage et tâches différées. Un sélecteur d’espace ne fait pas respecter les droits.

Approche de correction

Appliquer l’appartenance validée à chaque opération et vérifier les refus entre espaces lorsque autorisé.

Comprendre les droits, les politiques et l’identité

Les droits de la base déterminent si un rôle peut atteindre une table ou une fonction ; la sécurité par ligne détermine les lignes accessibles. Activer RLS sans politique utilisable peut bloquer les utilisateurs, tandis qu’une politique trop large expose les autres comptes. Un identifiant serveur privilégié peut contourner ces protections et ne doit jamais atteindre le navigateur.

1. Identifier le rôle de la requête et l’identité utilisée par la politique.
2. Examiner les droits de table et les politiques pour chaque lecture ou écriture.
3. Vérifier l’accès propriétaire aux éléments privés, brouillons et archives séparément de l’accès public.

Valider sans modifier les données de production

Une inspection du catalogue montre les définitions et droits, mais ne prouve pas tous les chemins d’accès applicatifs. Les exercices avec deux comptes apportent une preuve comportementale plus forte lorsqu’ils sont autorisés séparément. La présence d’une sauvegarde est aussi différente d’un test de restauration réussi.

1. Examiner définitions et droits avec l’audit compatible en lecture seule.
2. Utiliser des données isolées pour tout exercice comportemental autorisé.
3. Revérifier l’accès propriétaire attendu et le refus entre comptes après les changements.

Références

OWASP A01