Authentification de base de données pour applications intranet

Question

Je recherche les meilleures pratiques pour l'authentification de bout en bout pour les applications Web internes dans la couche base de données.

Le scénario le plus courant que j'ai vu consiste à utiliser un seul compte SQL avec les autorisations définies sur les exigences de l'application. Ce compte est utilisé par tous les appels d'application. Ensuite, lorsque des utilisateurs ont besoin d'accéder à la base de données via des outils de requête ou lorsqu'un groupe distinct est créé avec l'accès à la requête et que les utilisateurs ont accès à ce groupe.

L’autre scénario que j’ai vu consiste à utiliser l’authentification Windows complète de bout en bout. Ainsi, les utilisateurs eux-mêmes sont ajoutés aux groupes disposant de toutes les autorisations afin de pouvoir mettre à jour et modifier les paramètres en dehors des paramètres de l'application. Cela implique normalement de sécuriser les utilisateurs jusqu'aux procédures stockées appropriées afin qu'ils ne mettent pas à jour les tables directement.

Le premier scénario semble relativement facile à maintenir, mais soulève des problèmes s'il existe une faille de sécurité dans l'application, l'ensemble de la base de données est donc compromise.

Le deuxième scénario semble plus sûr mais a le souci opposé de disposer de beaucoup de logique métier dans les procédures stockées de la base de données. Cela semble limiter l’utilisation de technologies vraiment géniales comme Nhibernate et LINQ. Cependant, à l’époque où les gens peuvent utiliser les données de tant de façons différentes, nous ne prévoyons pas, par exemple. mash-ups, etc. est-ce la meilleure approche?

Answer 1

Dale - C'est tout à fait ça. Si vous souhaitez fournir à ces utilisateurs un accès au magasin de données sous-jacent, utilisez-le via des services. Et d’après mon expérience, ce sont les utilisateurs d’ordinateurs expérimentés qui sortent de Uni / College qui causent le plus de dégâts. Comme dit le proverbe, ils en savent juste assez pour être dangereux.

S'ils souhaitent automatiser une partie de leur travail et qu'ils peuvent afficher qu'ils possèdent les connaissances requises, continuez, accordez à leur compte de domaine l'accès au serveur. De cette manière, tout ce qu'ils font via leur petite automatisation VBA est lié à leur compte et vous savez exactement qui consulter lorsque les données seront stockées.

Mon argument de base est que la base de données est le Saint Graal de l’application. Vous voulez le moins de doigts possible dans cette tarte.

En tant que consultant, chaque fois que j'entends dire que des utilisateurs normaux ont été autorisés à accéder à la base de données, mes yeux s’éclairent car je sais que cela va devenir un gros chèque de paie pour moi lorsque je serai appelé à le réparer.

Answer 2

Personnellement, je ne veux pas d'utilisateurs finaux normaux dans la base de données. Pour une application intranet (en particulier une application située dans un domaine), je fournirais un compte unique pour l’accès des applications à la base de données, qui ne dispose que des droits nécessaires au fonctionnement de l’application.

L'accès à l'application serait alors contrôlé via le compte de domaine de l'utilisateur (désactiver l'accès anonyme dans IIS, etc.).

SI un utilisateur a besoin et peut justifier l'accès direct à la base de données, puis son compte de domaine aurait accès à la base de données et pourrait se connecter à la base de données. SGBD utilisant les outils appropriés.

Answer 3

J'ai été responsable du développement de plusieurs applications Web internes au cours de la dernière année.

Notre solution utilisait l'authentification Windows (Active Directory ou LDAP).

Notre objectif était simplement de permettre une connexion simple à l'aide d'un identifiant / mot de passe d'entreprise existant. Nous voulions également nous assurer que le service existant serait toujours responsable de la vérification et de la gestion des autorisations d'accès.

Bien que je ne puisse pas répondre à l'argument concernant Nhibernate ou LINQ, à moins que vous ne possédiez une fonction tueur spécifique que ces fonctionnalités peuvent implémenter, Active Directory ou LDAP sont suffisamment simples pour être implémentés et maintenus. Cela vaut la peine d'essayer.

Answer 4

Je suis d'accord avec Stephen Wrighton. La sécurité de domaine est la voie à suivre. Si vous souhaitez utiliser des mashups ou non, vous pouvez exposer des parties de la base de données via une interface RESTful lisible par machine. SubSonic a un intégré .

Answer 5

Stephen - Garder les utilisateurs finaux normaux à l'écart de la base de données est une bonne chose, mais je me demande si de nos jours, avec autant d'utilisateurs expérimentés qui sortent de l'université / du collège, si cette solution est la bonne. Si quelqu'un veut automatiser une partie de son travail, qui inclut une mise à jour VBA vers une base de données, ce que je lui permets de faire via l'application normale, nous perdons des gains en limitant son accès de cette manière.

Je suppose que l'autre chemin sous-jacent implique que vous pouvez ouvrir l'application via des services, puis sécuriser ces services via des groupes tout en maintenant les utilisateurs séparés de la base de données.

Ensuite, par délégation, vous pouvez autoriser les départements à contrôler l'accès à leurs propres comptes via les groupes, conformément à la publication de Jonathan.