Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utilisation d’une stratégie de mot de passe pour les connexions SQL Server sur RDS for SQL Server Amazon RDS vous permet de définir la stratégie de mot de passe pour votre instance de base de données Amazon RDS exécutant Microsoft SQL Server. Utilisez-le pour définir les exigences de complexité, de longueur et de verrouillage pour les connexions qui utilisent l’authentification SQL Server pour s’authentifier auprès de votre instance de base de données. ## Termes clés **Connexion** Dans SQL Server, un principal au niveau du serveur capable de s’authentifier auprès d’une instance de base de données est appelé **connexion**. D’autres moteurs de base de données peuvent désigner ce principal en tant qu’*utilisateur*. Dans RDS for SQL Server, une connexion peut s’authentifier à l’aide de l’authentification SQL Server ou de l’authentification Windows. **Connexion SQL Server** Une connexion qui utilise un nom d’utilisateur et un mot de passe pour s’authentifier à l’aide de l’authentification SQL Server est une connexion SQL Server. La stratégie de mot de passe que vous configurez via les paramètres de base de données s’applique uniquement aux connexions SQL Server. **Connexion Windows** Une connexion basée sur un principal Windows et authentifiée à l’aide de l’authentification Windows est une connexion Windows. Vous pouvez configurer la stratégie de mot de passe pour vos connexions Windows dans Active Directory. Pour plus d’informations, consultez [Utilisation d'Active Directory avec RDS for SQL Server](User.SQLServer.ActiveDirectoryWindowsAuth.md). ## Politique d’activation et de désactivation pour chaque connexion Chaque connexion à SQL Server comporte des indicateurs pour `CHECK_POLICY` et `CHECK_EXPIRATION`. Par défaut, les nouvelles connexions sont créées avec `CHECK_POLICY` défini sur `ON` et `CHECK_EXPIRATION` défini sur `OFF`. Si `CHECK_POLICY` est activé pour une connexion, RDS for SQL Server valide le mot de passe en fonction des exigences de complexité et de longueur minimale. Les politiques de verrouillage s’appliquent également. Exemple d’instruction T-SQL pour activer `CHECK_POLICY` et `CHECK_EXPIRATION` : ``` ALTER LOGIN [master_user] WITH CHECK_POLICY = ON, CHECK_EXPIRATION = ON; ``` Si `CHECK_EXPIRATION` est activé, les mots de passe sont soumis aux politiques relatives à l’ancienneté des mots de passe. L’instruction T-SQL pour vérifier si `CHECK_POLICY` et `CHECK_EXPIRATION` sont définis : ``` SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins; ``` ## Paramètres de la stratégie de mot de passe Tous les paramètres de la stratégie de mot de passe sont dynamiques et prennent effet sans qu’il soit nécessaire de redémarrer la base de données. Le tableau suivant répertorie les paramètres de base de données que vous pouvez définir afin de modifier la stratégie de mot de passe pour les connexions à SQL Server : **** | Paramètre de base de données | Description | Valeurs autorisées | Valeur par défaut | | --- | --- | --- | --- | | rds.password\$1complexity\$1enabled | Les exigences de complexité des mots de passe doivent être respectées lors de la création ou de la modification de mots de passe pour les connexions à SQL Server. Les contraintes suivantes doivent être respectées : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.PasswordPolicy.Using.html) | 0,1 | 0 | | rds.password\$1min\$1length | Nombre minimum de caractères requis dans un mot de passe pour une connexion à SQL Server. | 0-14 | 0 | | rds.password\$1min\$1age | Nombre minimum de jours pendant lesquels un mot de passe de connexion à SQL Server doit être utilisé avant que l’utilisateur puisse le modifier. Les mots de passe peuvent être modifiés immédiatement lorsque cette valeur est définie sur 0. | 0-998 | 0 | | rds.password\$1max\$1age | Nombre maximal de jours pendant lesquels un mot de passe de connexion à SQL Server peut être utilisé, après lequel l’utilisateur doit le modifier. Les mots de passe n’expirent jamais lorsque cette valeur est définie sur 0. | 0-999 | 42 | | rds.password\$1lockout\$1threshold | Nombre de tentatives de connexion infructueuses consécutives qui entraînent le blocage de la connexion à SQL Server. | 0-999 | 0 | | rds.password\$1lockout\$1duration | Nombre de minutes d’attente avant qu’une connexion à SQL Server bloquée ne soit débloquée. | 1-60 | 10 | | rds.password\$1lockout\$1reset\$1counter\$1after | Nombre de minutes qui doivent s’écouler après l’échec d’une tentative de connexion et avant que le compteur de tentatives de connexion infructueuses soit remis à 0. | 1-60 | 10 | **Note** Pour plus d’informations sur la stratégie de mot de passe de SQL Server, consultez [Stratégie de mot de passe](https://learn.microsoft.com/en-us/sql/relational-databases/security/password-policy). Les stratégies relatives à la complexité et à la longueur minimale des mots de passe s’appliquent également aux utilisateurs des bases de données contenues. Pour plus d’informations, consultez [Bases de données contenues](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases). Les contraintes suivantes s’appliquent aux paramètres de stratégie de mot de passe : + Le paramètre `rds.password_min_age` doit être inférieur à `rds.password_max_age parameter`, sauf si `rds.password_max_age` est défini sur 0 + Le paramètre `rds.password_lockout_reset_counter_after` doit être inférieur ou égal au paramètre `rds.password_lockout_duration`. + Si `rds.password_lockout_threshold` est défini sur 0, `rds.password_lockout_duration` et `rds.password_lockout_reset_counter_after` ne s’appliquent pas. ### Considérations relatives aux connexions existantes Une fois la stratégie de mot de passe modifiée sur une instance, les mots de passe existants pour les connexions **ne sont pas** évalués rétroactivement par rapport aux nouvelles exigences en matière de complexité et de longueur des mots de passe. Seuls les nouveaux mots de passe sont validés par rapport à la nouvelle stratégie. SQL Server **évalue** les mots de passe existants en fonction de l’ancienneté requise. Il est possible que les mots de passe expirent immédiatement après la modification d’une stratégie de mot de passe. Par exemple, si `CHECK_EXPIRATION` est activé pour une connexion et que son mot de passe a été modifié pour la dernière fois il y a 100 jours, et que vous définissez le paramètre `rds.password_max_age` sur 5 jours, le mot de passe expire immédiatement. Le mot de passe doit être modifié lors de la prochaine tentative de connexion. **Note** RDS for SQL Server ne prend pas en charge les stratégies d’historique de mot de passe. Les stratégies d’historique empêchent les connexions de réutiliser les mots de passe précédemment utilisés. ### Considérations sur les déploiements multi-AZ Le compteur de tentatives de connexion infructueuses et l’état de blocage des instances multi-AZ ne se répliquent pas entre les nœuds. Si une connexion est bloquée lorsqu’une instance multi-AZ bascule, il est possible que la connexion soit déjà débloquée sur le nouveau nœud. # Considérations sur l’utilisation du mot de passe pour la connexion principale Lorsque vous créez une instance de base de données RDS for SQL Server, le mot de passe de l’utilisateur principal n’est pas évalué par rapport à la stratégie de mot de passe. Un nouveau mot de passe principal n’est pas non plus évalué par rapport au mot de passe lorsque vous effectuez des opérations sur l’utilisateur principal, en particulier lors de la configuration de `MasterUserPassword` dans la commande `ModifyDBInstance`. Dans les deux cas, vous pouvez définir un mot de passe pour l’utilisateur principal qui ne correspond pas à votre politique en matière de mots de passe, et l’opération réussit tout de même. Si la politique n’est pas respectée, RDS tente de déclencher un événement RDS, avec la recommandation de définir un mot de passe fort. Veillez à n’utiliser que des mots de passe forts pour l’utilisateur principal. RDS tente de générer les messages d’événement suivants lorsque le mot de passe de l’utilisateur principal ne répond pas aux exigences de la stratégie de mot de passe : + L’utilisateur principal a été créé, mais le mot de passe ne respecte pas la longueur minimale requise par votre politique en matière de mots de passe. Envisagez d’utiliser un mot de passe plus fort. + L’utilisateur principal a été créé, mais le mot de passe ne respecte pas la complexité requise par votre politique en matière de mots de passe. Envisagez d’utiliser un mot de passe plus fort. + Le mot de passe de l’utilisateur principal a été réinitialisé, mais il passe ne respecte pas la longueur minimale requise par votre politique en matière de mots de passe. Envisagez d’utiliser un mot de passe plus fort. + Le mot de passe de l’utilisateur principal a été réinitialisé, mais il ne respecte pas la complexité requise par votre politique en matière de mots de passe. Envisagez d’utiliser un mot de passe plus fort. Par défaut, l’utilisateur principal est créé avec `CHECK_POLICY` et `CHECK_EXPIRATION` est défini sur `OFF`. Pour appliquer la stratégie de mot de passe à l’utilisateur principal, vous devez activer manuellement ces indicateurs pour l’utilisateur principal après la création de l’instance de base de données. Après avoir activé ces indicateurs, modifiez le mot de passe de l’utilisateur principal directement dans SQL Server (par exemple via des instructions T-SQL ou SSMS) pour valider le nouveau mot de passe par rapport à la stratégie de mot de passe. **Note** Si l’utilisateur principal est verrouillé, vous pouvez le déverrouiller en réinitialisant le mot de passe de l’utilisateur principal à l’aide de la commande `ModifyDBInstance`. ## Modification du mot de passe utilisateur principal Vous pouvez modifier le mot de passe de l’utilisateur principal à l’aide de la commande [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). **Note** Lorsque vous réinitialisez le mot de passe de l’utilisateur principal, RDS réinitialise diverses autorisations pour l’utilisateur principal, qui peut perdre certaines autorisations. La réinitialisation du mot de passe de l’utilisateur principal déverrouille également l’utilisateur principal, s’il a été verrouillé. RDS valide le nouveau mot de passe de l’utilisateur principal et tente d’émettre un événement RDS si le mot de passe ne respecte pas la politique. RDS définit le mot de passe même s’il ne respecte pas la stratégie de mot de passe.