# Usar política de senha para logins do SQL Server no RDS para SQL Server O Amazon RDS permite que você defina a política de senha para a instância de banco de dados do Amazon RDS que executa o Microsoft SQL Server. Use isso para definir os requisitos de complexidade, duração e bloqueio para logins que usam a autenticação do SQL Server para se autenticar na instância de banco de dados. ## Principais termos **Login** No SQL Server, uma entidade principal em nível de servidor que pode se autenticar em uma instância de banco de dados é chamado de **login**. Outros mecanismos de banco de dados podem se referir a essa entidade principal como *usuário*. No RDS para SQL Server, um login pode se autenticar usando a Autenticação do SQL Server ou a Autenticação do Windows. **Login do SQL Server** Um login que usa um nome de usuário e uma senha para se autenticar usando a Autenticação do SQL Server é um login do SQL Server. A política de senha que você configura por meio de parâmetros de banco de dados se aplica somente aos logins do SQL Server. **Login do Windows** Um login baseado em uma entidade principal do Windows e se autentica usando a Autenticação do Windows é um login do Windows. É possível configurar a política de senha para os logins do Windows no Active Directory. Para ter mais informações, consulte [Trabalhar com o Active Directory com o RDS para SQL Server](User.SQLServer.ActiveDirectoryWindowsAuth.md). ## Habilitar e desabilitar a política para cada login Cada login do SQL Server tem sinalizadores para `CHECK_POLICY` e `CHECK_EXPIRATION`. Por padrão, novos logins são criados com `CHECK_POLICY` definido como `ON` e `CHECK_EXPIRATION` definido como `OFF`. Se `CHECK_POLICY` estiver habilitado para um login, o RDS para SQL Server valida a senha em relação aos requisitos de complexidade e de tamanho mínimo. As políticas de bloqueio também são aplicáveis. Um exemplo de declaração T-SQL para habilitar `CHECK_POLICY` e `CHECK_EXPIRATION`: ``` ALTER LOGIN [master_user] WITH CHECK_POLICY = ON, CHECK_EXPIRATION = ON; ``` Se `CHECK_EXPIRATION` estiver habilitado, as senhas estarão sujeitas às políticas de idade da senha. A declaração T-SQL para conferir se `CHECK_POLICY` e `CHECK_EXPIRATION` estão definidos: ``` SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins; ``` ## Parâmetros da política de senha Todos os parâmetros da política de senha são dinâmicos e não exigem a reinicialização do banco de dados para entrar em vigor. A tabela a seguir lista os parâmetros de banco de dados que você pode definir para modificar a política de senha para logins do SQL Server: **** | Parâmetro de banco de dados | Descrição | Valores permitidos | Valor padrão | | --- | --- | --- | --- | | rds.password\$1complexity\$1enabled | Os requisitos de complexidade da senha devem ser atendidos ao criar ou alterar senhas para logins do SQL Server. As seguintes restrições devem ser atendidas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.PasswordPolicy.Using.html) | 0,1 | 0 | | rds.password\$1min\$1length | O número mínimo de caracteres exigido em uma senha para um login do SQL Server. | 0-14 | 0 | | rds.password\$1min\$1age | O número mínimo de dias em que uma senha de login do SQL Server deve ser usada para que o usuário possa alterá-la. As senhas podem ser alteradas imediatamente quando definidas como 0. | 0-998 | 0 | | rds.password\$1max\$1age | O número máximo de dias em que uma senha de login do SQL Server pode ser usada, após o qual o usuário deve alterá-la. As senhas nunca expiram quando definidas como 0. | 0-999 | 42 | | rds.password\$1lockout\$1threshold | O número de tentativas consecutivas de login com falha que fazem com que um login do SQL Server fique bloqueado. | 0-999 | 0 | | rds.password\$1lockout\$1duration | O número de minutos que um login bloqueado do SQL Server deve esperar antes de ser desbloqueado. | 1-60 | 10 | | rds.password\$1lockout\$1reset\$1counter\$1after | O número de minutos que devem decorrer após uma tentativa de login malsucedida antes que o contador de tentativas de login com falha seja redefinido como 0. | 1-60 | 10 | **nota** Para ter mais informações sobre a política de senha do SQL Server, consulte [ Password Policy](https://learn.microsoft.com/en-us/sql/relational-databases/security/password-policy). As políticas de complexidade e tamanho mínimo da senha também se aplicam aos usuários do banco de dados em bancos de dados contidos. Para ter mais informações, consulte [ Contained Databases](https://learn.microsoft.com/en-us/sql/relational-databases/databases/contained-databases). As seguintes restrições se aplicam aos parâmetros de política de senha: + O parâmetro `rds.password_min_age` deve ser menor que `rds.password_max_age parameter`, a menos que `rds.password_max_age` esteja definido como 0. + O parâmetro `rds.password_lockout_reset_counter_after` deve ser menor que ou igual ao parâmetro `rds.password_lockout_duration`. + Se `rds.password_lockout_threshold` estiver definido como 0, `rds.password_lockout_duration` e `rds.password_lockout_reset_counter_after` não se aplicarão. ### Considerações sobre logins existentes Depois de modificar a política de senha em uma instância, as senhas existentes para logins **não** são avaliadas retroativamente em relação aos novos requisitos de complexidade e de tamanho da senha. Somente novas senhas são validadas de acordo com a nova política. O SQL Server **não** avalia as senhas existentes de acordo com os requisitos de idade. É possível que as senhas expirem imediatamente depois que uma política de senha for modificada. Por exemplo, se um login tiver `CHECK_EXPIRATION` habilitado e sua senha foi alterada pela última vez há cem dias e você definiu o parâmetro `rds.password_max_age` como cinco dias, a senha expirará imediatamente e será necessário alterar a senha na próxima tentativa de login. **nota** O RDS para SQL Server não é compatível com políticas de histórico de senha. As políticas de histórico impedem que os logins reutilizem senhas usadas anteriormente. ### Considerações para implantações Multi-AZ O contador de tentativas de login com falha e o estado de bloqueio das instâncias multi-AZ não se replicam entre os nós. No caso de um login ser bloqueado quando uma instância multi-AZ falha, é possível que o login já esteja desbloqueado no novo nó. # Considerações sobre senhas para o login mestre Ao criar uma instância de banco de dados do RDS para SQL Server, a senha do usuário mestre não é avaliada em relação à política de senha. Uma nova senha mestra também não é avaliada em relação à senha ao realizar operações com o usuário mestre, especificamente ao configurar `MasterUserPassword` no comando `ModifyDBInstance`. Nos dois casos, é possível definir uma senha para o usuário mestre que não atenda à política de senha, e a operação ainda ser bem-sucedida. Se a política não for satisfeita, o RDS tentará gerar um evento do RDS, com a recomendação de definir uma senha forte. Tome cuidado para usar somente senhas fortes para o usuário mestre. O RDS tenta gerar as seguintes mensagens de evento quando a senha do usuário mestre não atende aos requisitos da política de senha: + O usuário mestre foi criado, mas a senha não atende ao requisito de tamanho mínimo da política de senha. Pense em usar uma senha mais forte. + O usuário mestre foi criado, mas a senha não atende ao requisito de complexidade da política de senha. Pense em usar uma senha mais forte. + A senha do usuário mestre foi redefinida, mas ela não atende ao requisito de tamanho mínimo da política de senha. Pense em usar uma senha mais forte. + A senha do usuário mestre foi redefinida, mas ela não atende ao requisito de complexidade da política de senha. Pense em usar uma senha mais forte. Por padrão, o usuário mestre é criado com `CHECK_POLICY` e `CHECK_EXPIRATION` definidos como`OFF`. Para aplicar a política de senha ao usuário mestre, você deve habilitar manualmente esses sinalizadores para o usuário mestre após a criação da instância de banco de dados. Depois de habilitar esses sinalizadores, modifique a senha do usuário mestre diretamente no SQL Server (por exemplo, por meio de declarações T-SQL ou SSMS) para validar a nova senha em relação à política de senha. **nota** Se o usuário mestre for bloqueado, você poderá desbloqueá-lo redefinindo a senha do usuário mestre com o comando `ModifyDBInstance`. ## Modificar a senha do usuário mestre É possível modificar a senha do usuário mestre usando o comando [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). **nota** Quando você redefine a senha do usuário mestre, o RDS redefine várias permissões para o usuário mestre e este pode perder determinadas permissões. A redefinição da senha do usuário mestre também desbloqueia o usuário mestre, caso ele tenha sido bloqueado. O RDS valida a nova senha do usuário mestre e tentará emitir um evento do RDS se a senha não atender à política. O RDS define a senha mesmo que ela não atenda à política de senha.