Sécurité SQL Server

Les comptes et les rôles SQL Server jouent un rôle critique dans la sécurité de Windows Server AppFabric. AppFabric utilise ces entités SQL Server pour contrôler l'accès aux magasins et tables qui contiennent des données des opérations de surveillance, ainsi que des données de contrôle d'état relatives à la persistance des flux de travail. AppFabric ne fournit pas d'outils pour la gestion de la sécurité des bases de données. Pour créer des comptes et des rôles, et pour afficher et manipuler des objets de base de données, ainsi que pour leur attribuer les autorisations appropriées, servez-vous des outils fournis avec votre installation de base de données. Pour SQL Server, utilisez SQL Server Management Studio.

AppFabric utilise des connexions et des rôles SQL Server pour gérer l'accès à des ressources telles que les magasins de persistance et de surveillance, et les procédures stockées. Les stratégies de sécurité sont appliquées via des autorisations sur des tables et des procédures stockées qui déterminent qui peut lire et écrire des schémas de persistance et de surveillance, et effectuer des opérations administratives sur ces derniers. Chaque schéma est sécurisé avec son propre jeu de stratégies de sécurité.

Modes d'authentification SQL Server et AppFabric

SQL Server offre deux méthodes de sécurisation de l'authentification de ses serveurs de bases de données AppFabric :

• Authentification Windows. Elle est assurée par le mode d'authentification Windows par défaut. Il s'agit du mode d'authentification le plus sécurisé pour SQL Server. Lors de la configuration du mode d'authentification Windows, SQL Server utilise la sécurité Windows pour valider le compte et le mot de passe du compte d'utilisateur demandant avec le système d'exploitation Windows.

• Authentification SQL Server. Elle est assurée par le mode d'authentification SQL Server. Elle existe uniquement pour assurer la compatibilité descendante avec des applications et des utilisateurs qui doivent pouvoir accéder à SQL Server en utilisant un compte d'utilisateur et un mot de passe explicites. Il s'agit du mode le moins sécurisé.

Si AppFabric fonctionne avec l'authentification SQL Server, la transmission de noms de compte d'utilisateur et de mots de passe explicites incorporés dans une chaîne de connexion d'un fichier de configuration n'est pas une pratique de sécurité recommandée. Il est fortement recommandé de configurer SQL Server de façon à utiliser le mode d'authentification Windows et à éviter le mode d'authentification SQL Server.

Si vous devez utiliser le mode d'authentification SQL Server ou si vous utilisez un fournisseur non-SQL Server nécessitant le stockage des mots de passe dans la chaîne de connexion, il est recommandé d'utiliser des chaînes de connexion chiffrées. AppFabric ne pouvant pas traiter les sections chiffrées d'un fichier de configuration, vous ne pouvez pas afficher ni ajouter de chaînes de connexion chiffrées à l'aide des outils AppFabric.

Si vous devez sécuriser les fichiers de configuration sur un ordinateur AppFabric en chiffrant des parties d'un fichier de configuration, utilisez l'outil d'enregistrement ASP.NET aux services Internet (IIS) (Aspnet_regiis.exe). Cet outil permet de chiffrer (option -pe) toutes les sections d'un fichier de configuration présentant un caractère sensible en matière de sécurité, hors de l'interface utilisateur de AppFabric. Pour consulter ou modifier ultérieurement ces sections, vous pouvez les déchiffrer à l'aide de l'option –pd. Le déchiffrement des sections permet de les afficher dans les outils de AppFabric, d'apporter des modifications, d'enregistrer les modifications dans le fichier de configuration et de chiffrer à nouveau les sections à l'aide de l'outil hors de AppFabric. Pour plus d'informations sur l'utilisation de l'outil d'enregistrement ASP.NET aux services Internet (IIS), consultez la page ASP.NET IIS Registration, outil (Aspnet_regiis.exe) (https://go.microsoft.com/fwlink/?LinkId=169163).

Connexions SQL Server

Une connexion SQL Server nécessite de disposer d'un compte d'utilisateur et d'un mot de passe pour se connecter à un ordinateur SQL Server. Dans la terminologie de sécurité de Windows, on peut la comparer à un droit d'accès ou à une authentification. SQL Server utilise l'authentification Windows intégrée pour identifier les entités de sécurité tentant d'accéder aux ressources de base de données AppFabric ou de les gérer. Pour se connecter à SQL Server à l'aide d'une authentification Windows intégrée, vous devez fournir l'identité Windows sous laquelle votre application s'exécute. Vous devez également être certain que l'identité bénéficie d'un accès approprié à la base de données SQL Server.

Pour pouvoir effectuer une configuration ou des actions opérationnelles sur les schémas ou données de base de données, le compte de connexion doit être mappé sur un rôle SQL Server disposant des autorisations appropriées. Un rôle SQL Server fonctionne comme un groupe Windows. L'appartenance d'un compte de connexion à un rôle SQL Server détermine le contrôle dont il dispose sur les activités d'administration et les opérations de base de données. Un compte d’utilisateur peut être membre de plusieurs rôles de base de données.

Ces comptes de connexion SQL Server sont créés lors de l'installation de AppFabric.

Rôles de base de données SQL Server

SQL Server offre trois types de rôles de base de données : serveur, application et base de données. Nous les présentons brièvement ici. AppFabric utilise exclusivement le modèle de rôle de base de données pour la sécurité de SQL Server.

• Rôle « serveur » SQL Server. Un rôle de « serveur » SQL Server est défini en dehors de tout magasin au niveau du serveur. Les rôles SQL Server sont prédéfinis. Il n'est pas possible d'en modifier le nombre ni le contenu. Le rôle sysadmin est un exemple de rôle de serveur courant. L'appartenance à ce rôle offre au compte de connexion un contrôle total de toutes les opérations de base de données et la possibilité d'effectuer toute opération sur les données de SQL Server dans tout magasin. AppFabric n'utilise pas explicitement de rôles de serveur dans son modèle de sécurité.

• Rôle d'« application » SQL Server. Les rôles d'application prennent en charge les besoins de sécurité plus complexes et personnalisés d'une application particulière. Un magasin peut être utilisé par plusieurs applications ayant un besoin commun d'assurer la sécurité de ses données quand l'une d'elle y accède. AppFabric n'utilise pas explicitement de rôles d'application dans son modèle de sécurité.

• Rôle de « base de données » SQL Server. AppFabric fait un usage intensif du rôle de base de données. Il existe trois types de rôles de base de données : public, défini par l'utilisateur et fixe. Nous les présentons brièvement ici. AppFabric utilise exclusivement le modèle de rôle de base de données défini par l'utilisateur pour une part importante de la sécurité de SQL Server.

  Il existe trois types de rôles de base de données SQL Server :

  • Public. Le rôle de base de données public contient des autorisations d'accès par défaut pour tous les utilisateurs de base de données. Ainsi, chaque compte de connexion créé par AppFabric est membre de ce rôle.

  • Fixe. Comme les rôles de « serveur » SQL Server (par exemple, sysadmin), les rôles de base de données fixes ne peuvent pas être modifiés. À la différence des rôles de serveur qui existent au niveau du serveur, les rôles de base de données existent au niveau de la base de données pour chaque magasin. db_owner est un exemple de rôle de base de données fixe. Vous pouvez ajouter des comptes d'utilisateur de connexion SQL à un rôle de base de données fixe ou en supprimer.

  • Défini par l'utilisateur. AppFabric crée des rôles de base de données spécifiques vides définis par l'utilisateur durant l'installation. Le programme d'installation de AppFabric n'insère pas explicitement de compte Windows ni de compte de connexion SQL Server dans ces rôles de base de données définis par l'utilisateur. Vous devez ajouter explicitement des comptes à l'aide des outils de gestion de SQL Server.

AppFabric utilise des rôles de base de données SQL Server pour contrôler l'accès à ses magasins de données de surveillance et de persistance. Lorsque vous initialisez un nouveau magasin de données de surveillance ou de persistance AppFabric, plusieurs rôles de sécurité de base de données définis par l'utilisateur sont créés durant l'installation. Le tableau suivant illustre la manière dont ces nouveaux rôles sont mappés sur les comptes de connexion SQL Server décrits dans la section précédente.

Si vous utilisez Active Directory, il est fortement recommandé de concevoir vos rôles de sécurité AppFabric à l'aide de comptes de domaine afin de simplifier la sécurité sur plusieurs ordinateurs. En tant qu'administrateur AppFabric, vous pouvez utiliser Active Directory pour créer explicitement deux comptes de groupe personnalisés pour les rôles Administrateurs et Observateurs. Vous pouvez les nommer, par exemple, « DOMAIN\MyAppFabricAdmins » et « DOMAIN\MyAppFabricObservers ». Vous pouvez ensuite octroyer les autorisations appropriées aux deux groupes sur chaque ordinateur en ajoutant manuellement le groupe « DOMAIN\MyAppFabricAdmins » au groupe LOCALHOST\AS_Administrators, puis le groupe « DOMAIN\MyAppFabricObservers » au groupe LOCALHOST\AS_Observers. Les services service de collecte d'événements ; et Service de gestion du flux de travail doivent s'exécuter sous des comptes de domaine membres du groupe « DOMAIN\MyAppFabricAdmins ».

Sécurité Remarque
Les cmdlets AppFabric qui utilisent SQL Server dépendent de ces rôles de base de données SQL Server pour authentifier leurs identités en cours d'exécution.

Stockage de base de données non-SQL Server

Les rôles de base de données SQL Server sont propres à SQL Server. Toutefois, si vous n'utilisez pas le fournisseur SQL Server par défaut et décidez de créer votre propre fournisseur, vous pouvez mapper les fonctionnalités de ces rôles sur leur équivalent fonctionnel dans votre magasin non-SQL Server.

Pour les magasins non-SQL Server, vous devez inclure un ID d'utilisateur et un mot de passe dans une chaîne de connexion pour sécuriser l'accès au magasin. S'il est admissible de transmettre à un magasin des ID et des mots de passe dans des chaînes de connexion, comme dans le cas de l'authentification SQL Server, cette méthode est néanmoins déconseillée. Si la transmission d'un ID d'utilisateur et d'un mot de passe dans une chaîne de connexion découle d'un choix personnel, assurez-vous de suivre les pratiques de sécurité appropriées de .NET Framework pour être certain que les chaînes de connexion soient chiffrées.

  2011-12-05