SQL Server chez les clients – Confidentialité des données par la séparation des rôles

  • Article

 

La divulgation de données contenant des informations sensibles ou à caractère personnel sont préjudiciables pour une entreprise en terme d’image et de parts de marché. Sur les applications critiques où intervient l’équipe MCS SQL BI, la confidentialité des données est une préoccupation majeure.

Les bonnes pratiques de développement, la fortification des protections au niveau logiciel et infrastructure dissuadent très souvent les intrusions externes. Cependant le risque le plus fort provient de l’intérieur de l’entreprise, notamment des personnes habilitées à accéder aux données et en particulier les DBA.

Problématique

  • Protéger les accès aux données sensibles sans impacter les performances.
  • Opérer et supporter efficacement une application sensible en production sans accéder aux données.

Bénéfices

  • Respect des règles de conformité et des règlementations économiques.
  • Confidentialité des données sensibles.
  • Simplicité de mise en œuvre des mesures de protection.

 

La séparation des rôles pour les accès applicatifs

La séparation des rôles a pour objectif de limiter l’utilisation de privilège élevé pour réaliser une opération. Il a aussi pour but d’éviter les conflits de rôles et empêcher l’élévation de privilège.

Une application critique métier doit implémenter ce concept dès la phase de développement. En effet, de nombreux projets démarrent la phase de développement avec des comptes en authentification SQL disposant du rôle serveur administrateur système (sysadmin).

Lorsque le projet avance, il devient alors complexe et coûteux de durcir les accès aux données. On retrouve alors ces applications avec un compte d’authentification SQL dont le mot de passe est stocké dans un fichier de configuration et possédant des autorisations sur les bases de données de type propriétaire (dbo) ou administrateur (sa) !

Dans les projets où intervient MCS, la mise en œuvre de norme de développement simple garantit le déploiement en production d’une application sécurisée :

  • Utilisation de compte de service, de pool d’application ou de proxy avec une authentification Windows forte intégrée à un annuaire Active Directory
  • Un compte distinct par domaine applicatif permettant de différencier par exemple les accès en lecture seule de l’administration du référentiel
  • Autorisation par rôle applicatif uniquement sur les procédures, fonctions plutôt que les tables sous-jacentes

Le schéma ci-dessous illustre parfaitement ces concepts :

Exemple de définition des rôles applicatifs

Il s’agit d’une application métier reposant sur des Services Web avec rupture d’identité entre serveur application et base de données. L’identité du pool d’application spécifique à chaque domaine fonctionnel est autorisée dans la base avec un rôle spécifique disposant du minimum de privilèges.

 

Principes du moindre privilège pour les DBA

La séparation des rôles applicatifs peut être complétée en production par de l’encryption des données :

-  Encryption colonne avec une clé symétrique ou asymétrique qui n’est pas sans impact sur la complexité de l’architecture et les performances en général.

-   « Transparent Database Encryption » qui permet d’encrypter les fichiers de base de données et de backup mais n’interdit pas l’accès à la base quand un utilisateur en possède l’autorisation.  

 

Le DBA utilise très souvent un compte avec privilège « sysadmin » (sa) pour l’administration quotidienne en production et a donc accès à toutes les ressources SQL Server y compris les données sensibles lorsque celles-ci ne sont pas encryptées au niveau colonne.  

Cependant, le DBA pour son administration quotidienne effectue souvent des opérations qui ne nécessitent pas de privilèges « sa » : sauvegarde, gestion des fichiers de base, des utilisateurs, des tâches planifiées….Il existe plus de 120 permissions permettant de définir des rôles serveur d’une granularité plus fine que les rôles par défaut.

Pour les opérations qui requièrent des droits élevés comme la maintenance de base ou de table, il est possible de fournir des procédures stockées signées :

-       La procédure est exécutée avec le rôle « sa » par un compte à moindre privilège

-       La signature de la procédure évite l’altération du code  

-       L’exécution de la procédure est tracée dans une piste d’audit

 Ces principes sont illustrés dans le « white paper »  SQL Server Separation of Duties.docx

 

Limiter l'utilisation de "sa"

Mais que se passe-t-il quand un DBA a absolument besoin d’un accès « sa »?

L’accès « sa » est géré par un tiers de confiance, qui valide et autorise l’utilisation temporaire de ce compte. Une trace d’audit SQL est démarrée afin de suivre toutes les commandes du DBA dont par exemple des opérations de sélection de table ou de création de compte utilisateur…

La configuration de l’audit SQL server permet de détecter rapidement une utilisation non autorisée du privilège « sa ». Le tiers de confiance peut alors réagir pour limiter les dommages. L’audit étant intégré au moteur SQL, son impact en performance est plus faible que les traces. De plus l’arrêt de l’audit peut provoquer un arrêt immédiat du service SQL.

Avec l’arrivée de SQL Server 2014 (actuellement en CTP1), il sera beaucoup plus simple de gérer la séparation des rôles et notamment de définir un nouveau profil DBA sans accès aux données. Trois nouvelles permissions apparaissent : 

CONNECT ANY DATABASE

IMPERSONATE ANY LOGIN

SELECT ALL USER SECURABLES

Ces permissions combinées à CONTROL SERVER permettent de créer par exemple plusieurs rôles d’administration:

-       Administrateur sans accès aux données

-       Administrateur sans gestion de la sécurité et de capacité d’impersonation

-       Administrateur avec uniquement accès aux méta-données pour les outils d’analyse de performance (SCOM)

Comme on peut le voir, le rôle « sa » ne sera plus nécessaire pour administrer les bases de données SQL Server 2014, ce rôle devenant une sorte de « super utilisateur » qui pourra être confié à un tiers de confiance dans l’entreprise sans mise en place d’un processus particulier pour son activation.

 

L’expertise Microsoft Consulting Services au service de ses clients

Les consultants de l’équipe SQL/BI sont dotés d’une solide expérience sur la mise en œuvre des technologies SQL Server pour des applications critiques et contenant des données à caractère confidentiel, dont voici quelques exemples de secteurs d’activité :

-       Banque d’investissement

-       Distribution d’énergie

-       Défense

Ces expériences permettent ainsi d’aligner l’implémentation d’une solution basée sur SQL Server avec les exigences de sécurité exprimées par leurs clients, notamment en appliquant le principe de séparation des rôles.

Pour plus d’informations sur les offres packagées Microsoft Consulting Services, rendez-vous sur https://www.microsoft.com/france/services

Plus d’informations sur les blogs « SQL Server chez les clients ».

 

Christian François, Consultant BI/SQL, Microsoft Consulting Services

J’interviens dans du conseil en avant-vente, architecture et expertise avancée auprès des grands comptes ce qui m’a permis d'acquérir une forte expérience des projets d'infrastructure et de développement d'application SQL Server à haute criticité. J’ai été l’un des premiers certifié SQL Ranger en 2007.