Résumé : Cet article présente principalement les types de modèles de sécurité pour les applications WEB ASP.NET, compare leurs avantages et inconvénients, et propose un mécanisme de sélection.
Mots-clés : modèle de sécurité, sous-modèle fiable, sous-modèle de simulation/délégation, application WEB ASP.NET
1.Préface
Les applications WEB ASP.NET appartiennent généralement à une architecture multicouche. Généralement, la structure logique peut être divisée en couche de présentation, couche de logique métier et couche d'accès aux données. Pour accéder aux ressources de l'application, l'authentification et l'autorisation de l'identité du client doivent s'étendre sur plusieurs couches. niveau. Cet article traite principalement du modèle de sécurité d'accès aux ressources des applications SP.NET
2. Identification de l'accès aux ressources
Les ressources typiques fournies en externe par les applications WEB aux clients incluent :
les ressources du serveur Web, telles que les pages Web, les services Web et les ressources statiques (pages et images HTML).
Ressources de base de données, telles que les données par utilisateur ou les données au niveau de l'application.
Ressources réseau, telles que les ressources du système de fichiers distant, etc.
Ressources système, telles que le registre, les journaux d'événements et les fichiers de configuration, etc.
Les clients accèdent à ces ressources à travers les couches d'application, avec une identité traversant chaque couche. Cette identité utilisée pour l'accès aux ressources comprend :
L'identité de l'appelant d'origine. L'identité de l'appelant d'origine est obtenue et circule ensuite à travers chaque couche du système.
ID de processus L'accès aux ressources locales et les appels en aval sont effectués à l'aide de l'ID de processus actuel. La faisabilité de cette approche dépend de la frontière à franchir, puisque l'identité du processus doit être reconnue par le système cible. Cela doit être appelé de deux manières :
Traversez les domaines de sécurité Windows au sein du même domaine de sécurité Windows : utilisez des approbations et des comptes de domaine, ou utilisez des noms d'utilisateur et des mots de passe en double là où aucune relation d'approbation n'existe.
Compte de service Cette approche utilise un compte de service (fixe). Par exemple, pour l'accès à la base de données, le compte de service peut être représenté par un nom d'utilisateur et un mot de passe SQL fixes par un composant connecté à la base de données.
Lorsqu'une identité Windows fixe est requise, l'application serveur Enterprise Services doit être utilisée.
Identité personnalisée Lorsqu'aucun compte Windows n'est disponible, vous pouvez utiliser Iprincipal et Iidentity pour construire votre propre identité, qui peut inclure des détails sur le contexte de sécurité.
3. Modèle d'accès aux ressources
3.1 Modèle de sous-système de confiance
Comme le montre la figure 1, dans ce modèle, le contexte de sécurité de l'appelant d'origine ne traverse pas le service au niveau du système d'exploitation, mais une identité fixe est utilisée dans la couche de service intermédiaire pour accéder aux services et ressources en aval. Le modèle de sous-système de confiance tire son nom du fait qu'un service en aval (peut-être une base de données) fait confiance à un service en amont pour autoriser ses appelants. Dans l'exemple de la figure 1, la base de données fait confiance à l'autorisation de l'appelant par la couche intermédiaire et autorise uniquement les appelants autorisés à accéder à la base de données en utilisant des identités de confiance.
3.1.1 Mode d'accès aux ressources
Dans le modèle de sous-système approuvé, le modèle d'accès aux ressources est le suivant :
Authentifier les utilisateurs Mapper les utilisateurs aux rôles Autoriser en fonction de l'appartenance au rôle Utiliser une identité approuvée fixe pour accéder aux ressources en aval
3.1.2 Identification fixe
Identité fixe utilisée pour accéder aux systèmes en aval et aux gestionnaires de ressources, qui peut être fournie à l'aide d'une identité de processus ou d'un compte de service de compte Windows prédéfini. Pour SQL Server Explorer, cela signifie l'authentification Windows auprès de SQL Server.
Lorsque vous utilisez l'identité de processus, vous utilisez généralement l'identité de processus ASP.NET (la valeur par défaut est le compte ASPNET). Dans les applications pratiques, il est souvent nécessaire de remplacer le compte ASPNET par un mot de passe plus sécurisé et de créer un compte Windows sur l'ordinateur SQL Server qui correspond au compte de processus ASP.NET. La méthode spécifique est la suivante :
Modifiez le fichier Machine.config situé dans le répertoire %windr%Microsoft.NETFrameworkv1.1.4322CONFIG et reconfigurez l'attribut password sur l'élément <processModel> à sa valeur par défaut <!-UserName="machine" password = "AutoGenerate" --> Remplacez par <!-UserName="machine" password="NewPassword" --> ; ou utilisez l'outil ASPNET_setreg.exe pour enregistrer le nom d'utilisateur et le mot de passe dans le registre et modifiez la configuration comme : < !- Enable="true" UserName="Registre : HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" password=" Registre :HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
D'autres applications utilisent un compte SQL désigné (spécifié par le nom d'utilisateur et le mot de passe dans la chaîne de connexion) pour accéder à SQL Server. Dans ce cas, la base de données doit être configurée pour l'authentification SQL. La chaîne de connexion enregistrée dans le fichier de configuration doit être protégée par cryptage.
3.2 Modèle de simulation/délégation
Comme le montre la figure 2, lors de l'utilisation du modèle d'emprunt d'identité/suppression, un service ou un composant (généralement situé dans la couche des services métier logiques) utilise les capacités d'emprunt d'identité du système d'exploitation pour usurper l'identité du client avant d'accéder au service en aval suivant. Si le service est sur la même machine, l'emprunt d'identité suffit, si le service en aval est sur une machine distante, vous devez également utiliser la délégation, le contexte de sécurité de l'accès aux ressources en aval est le contexte du client.
3.3 Sélectionner le modèle d'accès aux ressources
La comparaison des deux modèles d’accès aux ressources est présentée dans le tableau 1.
Le backend de la fonction de simulation de modèle de sous-système de confiance/d’audit de modèle délégué fait confiance aux services de couche supérieure. Si la couche intermédiaire est compromise, les ressources back-end sont vulnérables aux attaques. Le service back-end peut authentifier et autoriser chaque appelant avec une bonne sécurité.
L'évolutivité prend en charge le regroupement de connexions et offre une bonne évolutivité. Ne prend pas en charge le regroupement de connexions et présente une faible évolutivité.
Gestion des ACL back-end L'ACL est configurée pour une seule entité, nécessitant moins de travail de gestion. Chaque utilisateur doit disposer du niveau d'accès correspondant. Lorsque le nombre de ressources back-end et d'utilisateurs augmente, le travail de gestion devient fastidieux.
Pas besoin de déléguer les problèmes techniques. Une délégation est nécessaire. La plupart des fournisseurs de services de sécurité ne prennent pas en charge la délégation.
Le modèle de sous-système de confiance est utilisé dans la plupart des applications Internet ainsi que dans les grandes applications intranet, principalement parce que ce modèle peut bien prendre en charge l'évolutivité. Le modèle simulation/délégué a tendance à être utilisé dans des systèmes plus petits. Pour ces applications, l’évolutivité n’est pas la considération principale ; la considération principale est l’audit.