# Security best practices for Amazon Keyspaces
<a name="best-practices-security"></a>

Amazon Keyspaces (for Apache Cassandra) 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**
+ [Preventative security best practices for Amazon Keyspaces](best-practices-security-preventative.md)
+ [Detective security best practices for Amazon Keyspaces](best-practices-security-detective.md)

# Preventative security best practices for Amazon Keyspaces
<a name="best-practices-security-preventative"></a>

The following security best practices are considered preventative because they can help you anticipate and prevent security incidents in Amazon Keyspaces.

**Use encryption at rest**  
Amazon Keyspaces encrypts at rest all user data that's stored in tables by using encryption keys stored in [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/). This provides an additional layer of data protection by securing your data from unauthorized access to the underlying storage.  
By default, Amazon Keyspaces uses an AWS owned key for encrypting all of your tables. If this key doesn’t exist, it's created for you. Service default keys can't be disabled.   
Alternatively, you can use a [customer managed key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for encryption at rest. For more information, see [Amazon Keyspaces Encryption at Rest](https://docs.aws.amazon.com/keyspaces/latest/devguide/EncryptionAtRest.html).

**Use IAM roles to authenticate access to Amazon Keyspaces**  
For users, applications, and other AWS services to access Amazon Keyspaces, they must include valid AWS credentials in their AWS API requests. You should not store AWS credentials directly in the application or EC2 instance. These are long-term credentials that are not automatically rotated, and therefore could have significant business impact if they are compromised. An IAM role enables you to obtain temporary access keys that can be used to access AWS services and resources.  
For more information, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html).

**Use IAM policies for Amazon Keyspaces base authorization**  
When granting permissions, you decide who is getting them, which Amazon Keyspaces APIs they are getting permissions for, and the specific actions you want to allow on those resources. Implementing least privilege is key in reducing security risks and the impact that can result from errors or malicious intent.  
Attach permissions policies to IAM identities (that is, users, groups, and roles) and thereby grant permissions to perform operations on Amazon Keyspaces resources.  
You can do this by using the following:  
+ [AWS managed (predefined) policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)
+ [Customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)

**Use IAM policy conditions for fine-grained access control**  
When you grant permissions in Amazon Keyspaces, you can specify conditions that determine how a permissions policy takes effect. Implementing least privilege is key in reducing security risks and the impact that can result from errors or malicious intent.  
You can specify conditions when granting permissions using an IAM policy. For example, you can do the following:  
+ Grant permissions to allow users read-only access to specific keyspaces or tables.
+ Grant permissions to allow a user write access to a certain table, based upon the identity of that user.
 For more information, see [Identity-Based Policy Examples](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html).

**Consider client-side encryption**  
If you store sensitive or confidential data in Amazon Keyspaces, you might want to encrypt that data as close as possible to its origin so that your data is protected throughout its lifecycle. Encrypting your sensitive data in transit and at rest helps ensure that your plaintext data isn’t available to any third party.

# Detective security best practices for Amazon Keyspaces
<a name="best-practices-security-detective"></a>

The following security best practices are considered detective because they can help you detect potential security weaknesses and incidents.

**Use AWS CloudTrail to monitor AWS Key Management Service (AWS KMS) AWS KMS key usage**  
If you're using a [customer managed AWS KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) for encryption at rest, usage of this key is logged into AWS CloudTrail. CloudTrail provides visibility into user activity by recording actions taken on your account. CloudTrail records important information about each action, including who made the request, the services used, the actions performed, parameters for the actions, and the response elements returned by the AWS service. This information helps you track changes made to your AWS resources and troubleshoot operational issues. CloudTrail makes it easier to ensure compliance with internal policies and regulatory standards.  
You can use CloudTrail to audit key usage. CloudTrail creates log files that contain a history of AWS API calls and related events for your account. These log files include all AWS KMS API requests that were made using the console, AWS SDKs, and command line tools, in addition to those made through integrated AWS services. You can use these log files to get information about when the AWS KMS key was used, the operation that was requested, the identity of the requester, the IP address that the request came from, and so on. For more information, see [Logging AWS Key Management Service API Calls with AWS CloudTrail](https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html) and the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).

**Use CloudTrail to monitor Amazon Keyspaces data definition language (DDL) operations**  
CloudTrail provides visibility into user activity by recording actions taken on your account. CloudTrail records important information about each action, including who made the request, the services used, the actions performed, parameters for the actions, and the response elements returned by the AWS service. This information helps you to track changes made to your AWS resources and to troubleshoot operational issues. CloudTrail makes it easier to ensure compliance with internal policies and regulatory standards.  
All Amazon Keyspaces [DDL operations](cql.ddl.md) are logged in CloudTrail automatically. DDL operations let you create and manage Amazon Keyspaces keyspaces and tables.  
When activity occurs in Amazon Keyspaces, that activity is recorded in a CloudTrail event along with other AWS service events in the event history. For more information, see [Logging Amazon Keyspaces operations by using AWS CloudTrail](https://docs.aws.amazon.com/keyspaces/latest/devguide/logging-using-cloudtrail.html). You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in the *AWS CloudTrail User Guide*.  
For an ongoing record of events in your AWS account, including events for Amazon Keyspaces, create a [trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html). A trail enables CloudTrail to deliver log files to an Amazon Simple Storage Service (Amazon S3) bucket. By default, when you create a trail on the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs.

**Tag your Amazon Keyspaces resources for identification and automation**  
You can assign metadata to your AWS resources in the form of tags. Each tag is a simple label that consists 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:  
+ Access – Used to control access to Amazon Keyspaces resources based on tags. For more information, see [Authorization based on Amazon Keyspaces tags](security_iam_service-with-iam.md#security_iam_service-with-iam-tags).
+ Security – Used to determine requirements such as data protection settings.
+ Confidentiality – An identifier for the specific data-confidentiality level that a resource supports.
+ Environment – Used to distinguish between development, test, and production infrastructure. 
For more information, see [AWS tagging strategies](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) and [Adding tags and labels to resources](https://docs.aws.amazon.com/keyspaces/latest/devguide/tagging-keyspaces.html).