Discussion :

[FredFrance21]

Bonjour à toutes et à tous,

J'ignore s'il s'agit de la bonne section du forum dans laquelle poster mais suite à quelques recherches, je cherche à mettre en oeuvre les bonnes pratiques pour effectuer une connexion à une base de données SQL Server via C# de manière sécurisée et cloisonnée pour différentes catégories d'utilisateurs.

En effet, certains utilisateurs doivent avoir le droit de lire uniquement tandis que d'autres doivent pouvoir lire et insérer des données.
Il s'agit d'un environnement avec un Active Directory et donc un domaine d'entreprise.

En faisant des recherches sur la Toile, j'ai vu que des développeurs pratiquaient une authentification en stockant les identifiants dans la base de données SQL Server tandis que d'autres utilisent l'authentification Active Directory en déclarant des utilisateurs et leurs droits dans les paramètres de la base de données.

Je me demandais si certain(e)s d'entre vous avaient déjà mis en place ce type de connexion via une application développée en C# tout en distinguant les droits en lecture/écriture de chaque utilisateur.

Merci d'avance pour vos retours d'expérience ! ;-)

Fred

[popo]

Bonjour,

Le choix n'est pas si simple.
Il va dépendre de quelques facteurs dont je n'ai plus la liste en tête.

L'un d'entre eux est la gestion de ces utilisateurs.
Par exemple, à un moment ces droits pourront changer si l'utilisateur change de poste (carrière).

Le choix de la connexion par AD permet de définir des droits très fins sur UNE SEULE base de manière native.
SQL serveur fournit un tas d'outils pour gérer les utilisateurs et les rôles de ces utilisateurs de chaque base de données (s'il y en a plusieurs).
Mais cela implique un administrateur de base de données avec des connaissance avancée sur SQL Serveur pour le faire.

Le choix de la connexion par un utilisateur applicatif, comme son nom l'indique, signifie qu'un seul compte SQL est nécessaire et que les droits sont gérés par l'application.
Il faut donc développer une application pour gérer ces droits.
Mais cela permet à une personne non technique de le faire.

Personnellement, je préfère la seconde option (utilisateur applicatif) car elle permet de séparer la gestion des droits et le métier.
En gros j'ai une application pour gérer les droits (avec sa propre base de données) accessible par une personne habilitée.
Et une ou plusieurs applications métiers dont les accès sont données dans la première application.
Je peux donc développer un outil commun pour lire les droits et l'utiliser dans chacune des applications.

Je te suggère également de regarder du coté des schémas :
Les schémas permettent également une séparation naturelle entre les métiers.
Si je prend un thème concret comme la facturation.
Je peux avoir une table des codes postaux avec un schéma transverse (ex : Commun)
Je peux avoir une table contenant des données communes concernant les articles à la vente dans ce schéma transverse (ex : code, désignation, coloris)
Mais certaines données sont métiers et sont donc déclarées dans un schéma métier (ex : Ventes, Achats, Compta).
Le vendeur aura besoin du prix de vente de l'article mais pas de la famille comptable auquel il est rattaché (le prix sera dans une table du schéma "Ventes", la famille comptable dans une table du schéma "Compta").
Le fabriquant aura besoin de revient de l'article mais pas de son prix de vente (ce coût sera dans une table du schéma "Achats").
Le comptable aura besoin du prix de vente de l'article, du coût de revient et de la famille comptable pour faire son métiers (il aura accès aux trois schémas)

Cela est décrit sommairement dans cette page :
https://blog.developpez.com/sqlpro/p...des_schema_sql

[Noxen]

Est-ce-qu'on parle d'utilisateurs qui accèdent directement à la base de données via un outil comme SQLServer ou de façon indirecte dans le contexte d'une application métier ? Dans le second cas, c'est l'application elle-même qui devrait savoir qui a le droit de faire quoi dedans, quelle que soit sa source d'information (AD, base interne, autre gestionnaire d'identité), la notion de permissions sur la base devient secondaire puisque les utilisateurs eux-même ne touchent pas directement à la base.

[olsimare]

Bonjour,

Le choix n'est pas si simple.
Il va dépendre de quelques facteurs dont je n'ai plus la liste en tête.

L'un d'entre eux est la gestion de ces utilisateurs.
Par exemple, à un moment ces droits pourront changer si l'utilisateur change de poste (carrière).

Le choix de la connexion par AD permet de définir des droits très fins sur UNE SEULE base de manière native.
SQL serveur fournit un tas d'outils pour gérer les utilisateurs et les rôles de ces utilisateurs de chaque base de données (s'il y en a plusieurs).
Mais cela implique un administrateur de base de données avec des connaissance avancée sur SQL Serveur pour le faire.

Le choix de la connexion par un utilisateur applicatif, comme son nom l'indique, signifie qu'un seul compte SQL est nécessaire et que les droits sont gérés par l'application.
Il faut donc développer une application pour gérer ces droits.
Mais cela permet à une personne non technique de le faire.

Personnellement, je préfère la seconde option (utilisateur applicatif) car elle permet de séparer la gestion des droits et le métier.
En gros j'ai une application pour gérer les droits (avec sa propre base de données) accessible par une personne habilitée.
Et une ou plusieurs applications métiers dont les accès sont données dans la première application.
Je peux donc développer un outil commun pour lire les droits et l'utiliser dans chacune des applications.

Je te suggère également de regarder du coté des schémas :
Les schémas permettent également une séparation naturelle entre les métiers.
Si je prend un thème concret comme la facturation.
Je peux avoir une table des codes postaux avec un schéma transverse (ex : Commun)
Je peux avoir une table contenant des données communes concernant les articles à la vente dans ce schéma transverse (ex : code, désignation, coloris)
Mais certaines données sont métiers et sont donc déclarées dans un schéma métier (ex : Ventes, Achats, Compta).
Le vendeur aura besoin du prix de vente de l'article mais pas de la famille comptable auquel il est rattaché (le prix sera dans une table du schéma "Ventes", la famille comptable dans une table du schéma "Compta").
Le fabriquant aura besoin de revient de l'article mais pas de son prix de vente (ce coût sera dans une table du schéma "Achats").
Le comptable aura besoin du prix de vente de l'article, du coût de revient et de la famille comptable pour faire son métiers (il aura accès aux trois schémas)

Cela est décrit sommairement dans cette page :
https://blog.developpez.com/sqlpro/p...des_schema_sql

Bonjour.

La gestion des droits ne doit pas se faire au niveau BDD.

C'est un non sens.

La BBD doit être protégé par une couche applicative qui elle s'appuie sur l'AD (Ou Entra ID comme on dit maintenant) pour géré le RBAC qui va bien.

Et pour la BDD, seuls des applicatifs y ont accès.

Cdt

[popo]

Olsimare, lorsque tu casses du sucre sur le dos de quelqu'un, la moindre de choses est de donner des arguments.
Surtout lorque tu mélanges deux notions bien distinctes qui sont l'accès à la base et les droits de l'utilisateur.

La BBD doit être protégé par une couche applicative qui elle s'appuie sur l'AD (Ou Entra ID comme on dit maintenant) pour géré le RBAC qui va bien.
Et pour la BDD, seuls des applicatifs y ont accès.
Cdt

Cela concerne l'accès à la base. Pas les droits.
Rien dans mon discours ne dit que l'utilisateur accède directement à la base sans passer par l'application.
S'appuyer sur l'AD peut être une bonne pratique dans ce contexte précis.
Mais ce n'est pas une vérité absolue.

La gestion des droits ne doit pas se faire au niveau BDD.
C'est un non sens.

Cela concerne les droits. Pas l'accès à la base.
En quoi cela n'a pas de sens.
Il faut donner des arguments quand on écrit ce genre de choses.
Depuis quand c'est l'AD qui définit ce qu'un utilisateur peut faire ou non dans une application ?

Voici, un exemple tout simple pour démontrer mon propos :
Dans mon application, je gère des dossiers clients avec des données sensibles.
Certains utilisateurs de mon application doivent intervenir sur ces données à la demande des clients.
D'autres ne doivent en aucun cas y avoir accès.
Selon toi, je ne dois rien avoir dans ma base de données pour définir que l'utilisateur A peut accéder à ces données et pas l'utilisateur B ?
Je dois mettre ça dans l'AD ?

[François DORIN]

La gestion des droits ne doit pas se faire au niveau BDD.

C'est un non sens.

Ecrire cela est un non sens. La gestion des droits doit se faire là où elle doit être faite.

En général, elle est faite côté applicative. C'est plus simple pour le développeur, c'est plus puissant, plus souple, et ne nécessite pas de compétences particulières en administration de base de données.

Maintenant, si on a des contraintes de sécurité forte, on peut tout à fait doubler la gestion des droits applicatifs par une gestion des droits au niveau BD. C'est une sécurité supplémentaire en cas de défaillance de l'applicatif. Restreindre l'accès au schéma de la compta par exemple, évitera qu'un membre lambda puisse accéder à toutes les informations. En cas de compromission de compte, c'est un énorme plus pour la protection des données.

On peut aussi restreindre l'écriture, l'exécution de procédures stockées, etc. Bref, on peut faire plein de chose. Mais cela nécessite des connaissances en administration de base de données que peu de développeurs ont.

Et pour la BDD, seuls des applicatifs y ont accès.

Non. Enfin, en théorie oui. Mais en pratique, des personnes ont accès à la BD (comme les admin) et il est donc important de bien protéger sa BD vis-à-vis de ça, pour éviter, par exemple, qu'une personne ayant accès au serveur (maintenance, déploiement, ...) ne puisse accéder à la BD si elle n'est pas sensée pouvoir le faire.

Après, je pense que la bonne question n'est pas l'un ou l'autre, mais une ou les deux ? Il me parait quasi-impossible aujourd'hui de se passer d'une gestion de droit au niveau applicatif. La question est donc de savoir s'il faut coupler ou non cette gestion de droits avec une gestion de droit côté BD. Et là, tout dépend du métier, de la criticité des données, des moyens dont vous disposez, etc.