# Security best practices for Aurora DSQL Aurora DSQL provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions. **Topics** + [ # Detective security best practices for Aurora DSQL ](best-practices-security-detective.md) + [ # Preventative security best practices for Aurora DSQL ](best-practices-security-preventative.md) # Detective security best practices for Aurora DSQL In addition to the following ways to securely use Aurora DSQL, see [Security](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool to learn about how cloud technologies improve your security. **Amazon CloudWatch Alarms** Using Amazon CloudWatch alarms, you watch a single metric over a time period that you specify. If the metric exceeds a given threshold, a notification is sent to an Amazon SNS topic or AWS Auto Scaling policy. CloudWatch alarms do not invoke actions because they are in a particular state. Rather the state must have changed and been maintained for a specified number of periods. **Tag your Aurora DSQL resources for identification and automation** You can assign metadata to your AWS resources in the form of tags. Each tag is a simple label consisting of a customer-defined key and an optional value that can make it easier to manage, search for, and filter resources. Tagging allows for grouped controls to be implemented. Although there are no inherent types of tags, they enable you to categorize resources by purpose, owner, environment, or other criteria. The following are some examples: + Security – Used to determine requirements such as encryption. + Confidentiality – An identifier for the specific data-confidentiality level a resource supports. + Environment – Used to distinguish between development, test, and production infrastructure. You can assign metadata to your AWS resources in the form of tags. Each tag is a simple label consisting of a customer-defined key and an optional value that can make it easier to manage, search for, and filter resources. Tagging allows for grouped controls to be implemented. Although there are no inherent types of tags, they let you categorize resources by purpose, owner, environment, or other criteria. The following are some examples. + Security – used to determine requirements such as encryption. + Confidentiality – an identifier for the specific data-confidentiality level a resource supports. + Environment – used to distinguish between development, test, and production infrastructure. For more information, see [ Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html). # Preventative security best practices for Aurora DSQL In addition to the following ways to securely use Aurora DSQL, see [Security](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool to learn about how cloud technologies improve your security. **Use IAM roles to authenticate access to Aurora DSQL.** Users, applications, and other AWS services that access Aurora DSQL must include valid AWS credentials in AWS API and AWS CLI requests. You shouldn't store AWS credentials directly in the application or EC2 instances. These are long-term credentials that aren't automatically rotated. There is significant business impact if these credentials are compromised. An IAM role lets you obtain temporary access keys that you can use to access AWS services and resources. For more information, see [Authentication and authorization for Aurora DSQL](authentication-authorization.md). **Use IAM policies for Aurora DSQL base authorization.** When you grant permissions, you decide who is getting them, which Aurora DSQL API operations they are getting permissions for, and the specific actions you want to allow on those resources. Implementing least privilege is key in reducing security risk and the impact that can result from errors or malicious intent. Attach permissions policies to IAM roles and grant permissions to perform operations on Aurora DSQL resources. Also available are [permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), which let you set the maximum permissions that an identity-based policy can grant to an IAM entity. Similar to the [ root user best practices for your AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html), don't use the `admin` role in Aurora DSQL to perform everyday operations. Instead, we recommend that you create custom database roles to manage and connect to your cluster. For more information, see [ Accessing Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html) and [Understanding authentication and authorization for Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html). **Use `verify-full` in production environments.** This setting verifies that the server certificate is signed by a trusted certificate authority and that the server hostname matches the certificate. **Update your PostgreSQL client** Regularly update your PostgreSQL client to the latest version to benefit from security improvements. We recommend using PostgreSQL version 17.