← Retour à la Base de connaissances← Question précédenteQuestion suivante →
ProgrammationArchitecte SQL

Quels sont les moyens de protection des données contre les modifications involontaires ou malveillantes via les droits et rôles dans SQL ? Quelles sont les différences entre les niveaux d'accès et comment mettre en œuvre une politique de sécurité à plusieurs niveaux de manière adéquate ?

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

Le serveur SQL prend en charge un système multi-niveaux de droits d'accès via rôles, droits utilisateurs (GRANT/REVOKE) et schémas (schemas). Principes clés :

  • Assignez une rôle = un ensemble d'autorisations que l'utilisateur obtiendra ensuite.
  • Offrez les minimums de droits, uniquement ce qui est nécessaire (principe du minimum privilège).
  • Séparez les droits au niveau de la base de données, des tables, des vues, des procédures de manière distincte.
  • Pour les opérations particulièrement importantes - utilisez uniquement via des procédures stockées ou des vues, et non un accès direct aux tables.

Exemple de création de rôles et d'attribution de droits :

-- Créons un rôle pour les analystes
CREATE ROLE Analyst;
-- Donnons uniquement SELECT aux tables nécessaires
GRANT SELECT ON Sales TO Analyst;
-- Interdisons la modification des données
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Assignez le rôle à l'utilisateur
GRANT Analyst TO user_ivan;

Il est souvent recommandé de créer des rôles pour la lecture (read-only), la modification, l'administration et les opérations distinctes.

Question piégeuse.

Piège : "Un utilisateur ayant accès uniquement à une vue (VIEW) peut-il modifier la table de base à travers elle ? Donnez un exemple."

Réponse : Oui, si la VIEW ne contient pas d'agrégation/grouper et n'est pas uniquement en lecture (WITH CHECK OPTION) – des opérations INSERT/UPDATE/DELETE peuvent être effectuées sur la VIEW, et les modifications toucheront la table de base, si les autorisations le permettent.

-- Vue qui exclut les colonnes non nécessaires
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Si cela est autorisé, l'utilisateur effectuera des modifications ainsi :
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Cela affectera Sales.total pour id=42

Solution : utiliser uniquement des VIEW en lecture seule ou interdire les droits de modification des données via des vues.

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet.

Histoire

Projet : Portail RH, données personnelles des employés.

Erreur : Les opérateurs avaient accès à la table de base via une VIEW sans restriction sur UPDATE - ils ont modifié accidentellement les salaires des autres, bien que la VIEW ait été initialement conçue "uniquement pour les rapports".

Histoire

Projet : Comptabilité, intégrations externes.

Erreur : Donné à un système externe des droits INSERT et SELECT sur toute la BD au lieu de seulement INSERT dans les tables nécessaires. Résultat : vulnérabilité à la lecture de toute la BD et possible violation de la législation sur la GDPR.

Histoire

Projet : Plateforme SaaS, rapports multi-utilisateurs.

Erreur : Tous les clients travaillaient dans un même schéma avec des droits partagés : ils voyaient accidentellement et pouvaient modifier les données des autres. Solution - division en schémas, rôles distincts et restrictions propres au niveau de la Sécurité au Niveau de la Ligne (RLS).