Comment devrais-je concevoir un module de sécurité [contrôleur d'accès aux données] dans un projet MEF?

Question

J'ai lu sur le contrôle d'accès basé sur le rôle et j'essaie de comprendre comment je devrais mettre en œuvre le contrôle de sécurité. Dans mon projet MEF, j'ai un contrôleur de sécurité qui est responsable de la validation de l'utilisateur, de la vérification des rôles, etc.

Naturellement, le contrôleur de sécurité doit pouvoir accéder à une base de données pour exécuter la validation sur un utilisateur et récupérer le (s) rôle (s) de l'utilisateur. J'ai l'intention d'implémenter des classes à partir de l'espace de noms System.Security.Principal.

Le module de contrôleur de sécurité doit-il avoir sa propre base de données dans laquelle les informations utilisateur sont conservées séparément des données métier?

Et, serait un fichier sérialisé binaire adéquat pour ce aussi longtemps que les mots de passe de l'utilisateur (uniquement le hachage) ne sont pas stockées dans ledit fichier?Je suppose cependant que pour que cela fonctionne, le fichier sérialisé doit être accessible par plusieurs instances de l'application ...

Mise à jour Depuis c'est un projet MEF, je me suis demandé sur la façon dont la sécurité devrait fonctionner. Voici mes pensées:

Security Controller est un objet Identity lui-même, par conséquent devrait probablement mettre en œuvre IIdentity et avoir une propriété GenericIdentity. SecControl devrait aussi être le GenericPrincipal ... ??? SecControl serait également responsable de la modification des jeux d'autorisations AppDomain. Je ne veux pas que des modules aient accès à des ressources (bases de données, fichiers, partages réseau, etc.) qui ne sont pas spécifiquement accordées par SecControl.

Non seulement les utilisateurs sont authentifiés, mais les modules le sont également. Les modules (plug-ins) implémenteront probablement IIdentity et auront également des propriétés GenericIdentity.

Answer 1

Le module de contrôleur de sécurité doit-il avoir sa propre base de données dans laquelle les informations utilisateur sont gérées séparément des données métier?

dépend du contexte de votre système:

• Si seulement une application utilise cette base de données et la configuration de votre serveur serveur d'application/base de données est relativement sécurisée et un accès contrôlé déjà - vous n'avez probablement pas besoin une base de données distincte, bien que vous souhaitiez vous assurer que l'accès à vos informations utilisateur est correctement contrôlé dans la base de données.
• Si vous partagez la base de données avec d'autres applications, vous pouvez envisager d'avoir un mécanisme de stockage séparé pour les informations utilisateur/rôle/privilège que vous pouvez contrôler plus attentivement.

Il y a aussi la considération de ce que vous protégez. Si vous tentez surtout de garder le silence et ne travaillez pas avec les informations financières, les informations sur la santé ou les informations de défense, vous risquez d'être confronté à un certain niveau de risque dans le stockage des informations utilisateur. Si vous avez une application de haute sécurité, vous pouvez même aller jusqu'à penser aux produits logiciels commecerial pour le contrôle d'accès (comme un annuaire LDAP qui possède ses propres journaux d'audit, serveur, processus administratifs, etc.).Lorsque vous pensez au magasin de données, ne vous limitez pas à penser à la façon dont les données sont stockées et protégées. Considérez également comment accéder aux données (via une connexion cryptée ou en clair?), Comment les accès sont consignés (dans un système de haute sécurité, la vérification des informations d'identification est un événement qui doit être enregistré), comment les journaux sont protégés. infalsifiable?), et comment les données sont protégées - pas seulement de l'examen, mais aussi de la modification. Et, un fichier sérialisé binaire serait-il suffisant pour cela tant que les mots de passe utilisateur (seulement le hachage) ne sont pas stockés dans ce fichier? Je suppose, cependant, que pour que cela fonctionne, le fichier sérialisé doit être accessible par plusieurs instances de l'application ...

Ma plus grande question à ce sujet est - comment ce fichier est-il protégé contre le changement? Puisqu'un fichier binaire searlized est relativement facile à analyser à partir d'une application, comment contrôlez-vous la capacité des autres processus à écrire dans le fichier? L'attaque la plus simple consisterait à ajouter votre propre compte à privilège élevé et votre hachage nom d'utilisateur/mot de passe, puis à utiliser le faux compte pour pirater le reste du système. Dans quelle mesure serait-il facile de le faire et comment serait-il facile de prendre un ensemble d'informations d'identification de faible privilège et de les transformer en privilèges élevés? C'est plus qu'un simple mécanisme de stockage de fichiers - cela signifie également que vous devez avoir un sens du contrôle d'accès sur votre système d'exploitation et comment cela est géré. Ce qui peut aider: - signer numériquement le fichier avec une clé asymétrique stockée ailleurs, puis vérifier l'altération avant d'utiliser le fichier. - stockez le fichier dans un compte qui ne peut être modifié que si vous êtes administrateur.