sp_addapprole |
Ajout un rôle d'application |
| SQL Server |
Syntaxe
|
sp_addapprole [ @rolename = ] 'role' , [ @password = ] 'password'
|
Paramètres
| Nom |
Description |
| rolen |
Ce paramètre permet d'indiquer le nom du nouveau rôle d'application. @rolename est un nom système, sans valeur par défaut. @rolename doit être un identifiant valide et ne doit pas exister dans la base de données actuelle. Les noms de rôles d'application peuvent contenir de 1 à 128 caractères, y compris des lettres, des symboles et des chiffres. Les noms de rôles ne peuvent pas contenir de barre oblique inverse (\), ni être nuls ou une chaîne de caractères vide (''). |
| password |
Ce paramètre permet d'indiquer le mot de passe requis pour activer le rôle d'application. @password est sysname, sans valeur par défaut. @password ne peut pas être NULL. |
Description
Cette Stored Procedure permet d'ajouter un rôle d'application à la base de données actuelle.
Remarques
- Compatibilité ascendante avec les versions antérieures de SQL Server : La procédure sp_addapprole existe principalement pour maintenir la compatibilité
avec les versions de SQL Server antérieures à 2005. Dans ces versions, la séparation entre rôles et schémas n'était pas claire, ce qui justifie la logique interne de
la procédure. Depuis SQL Server 2005, CREATE APPLICATION ROLE est la méthode recommandée.
- Création implicite d'un schéma avec le même nom que le rôle : Lorsqu'un rôle applicatif est ajouté avec sp_addapprole, un schéma du même nom est
automatiquement créé si aucun schéma existant ne porte ce nom. Ce comportement peut surprendre si l'on ne s'y attend pas, surtout lorsqu'on travaille dans un environnement
avec une gestion stricte des schémas.
- Échec si un schéma du même nom existe déjà : Si un schéma ayant déjà le même nom que le rôle applicatif existe dans la base de données, la procédure
sp_addapprole échoue. Cela signifie que cette procédure est sensible aux conflits de noms entre schémas et rôles, ce qui nécessite une gestion rigoureuse des
conventions de nommage.
- Pas de vérification de la complexité du mot de passe : Contrairement à CREATE APPLICATION ROLE, la
procédure sp_addapprole ne vérifie pas la complexité du mot de passe fourni. Cela peut poser un risque de sécurité si cette procédure est utilisée dans des
scripts d'installation sans mesures de validation préalables.
- Le mot de passe est entreposé sous forme de hachage unidirectionnel : Même si la complexité n'est pas vérifiée, le mot de passe fourni à sp_addapprole
est entreposé sous forme de hachage, ce qui empêche sa récupération en clair. Cela améliore la sécurité de l'entreposage, mais ne protège pas contre les attaques par
dictionnaire si le mot de passe est faible.
- Ne peut pas être exécutée à l'intérieur d'une transaction définie par l'utilisateur : L'appel à sp_addapprole à l'intérieur d'une transaction
explicite (BEGIN TRAN...COMMIT) échoue. Ce comportement est important à connaître pour éviter des erreurs inattendues dans des scripts complexes d'installation ou de
déploiement.
- Permissions nécessaires pour l'exécution : L'exécution de sp_addapprole nécessite la permission ALTER ANY APPLICATION ROLE. Si un nouveau schéma doit
être créé en même temps, la permission CREATE SCHEMA est également requise. Ces prérequis doivent être pris en compte lors de la délégation d'accès ou l'automatisation.
- Conseils de sécurité pour l'entreposage des identifiants : Microsoft recommande de ne pas entreposer les identifiants d'un rôle applicatif en clair
dans les fichiers de configuration. Lorsque cela est inévitable, il est conseillé d'utiliser les API de chiffrement de Windows (CryptoAPI) pour sécuriser les
données. Le paramètre Encrypt d'ODBC n'est d'ailleurs pas supporté par le fournisseur SqlClient.
Dernière mise à jour : Dimanche, le 29 Août 2021
