How to secure ElasticCache in AWS

AWS offers services to handle the cache management process. Earlier, we were using Memcached or Redis installed on VM, which was a very complex and tough task to manage in terms of ensuring availability, patching, scalability, and security.

[box type="shadow" align="" class="" width=""]This article is an excerpt taken from the book,'Cloud Security Automation'. In this book, you'll learn the basics of why cloud security is important and how automation can be the most effective way of controlling cloud security.[/box]

On AWS, we have this service available as ElastiCache. This gives you the option to use any engine (Redis or Memcached) to manage your cache. It's a scalable platform that will be managed by AWS in the backend.

ElastiCache provides a scalable and high-performance caching solution. It removes the complexity associated with creating and managing distributed cache clusters using Memcached or Redis.

Now, let's look at how to secure ElastiCache.

Secure ElastiCache in AWS

For enhanced security, we deploy ElastiCache clusters inside VPC. When they are deployed inside VPC, we can use a security group and NACL to add a level of security on the communication ports at network level.

Apart from this, there are multiple ways to enable security for ElastiCache.

VPC-level security

Using a security group at VPC—when we deploy AWS ElastiCache in VPC, it gets associated with a subnet, a security group, and the routing policy of that VPC. Here, we define a rule to communicate with the ElastiCache cluster on a specific port.

ElastiCache clusters can also be accessed from on-premise applications using VPN and Direct Connect.

Authentication and access control

We use IAM in order to implement the authentication and access control on ElastiCache. For authentication, you can have the following identity type:

Root user: It's a superuser that is created while setting up an AWS account. It has super administrator privileges for all the AWS services. However, it's not recommended to use the root user to access any of the services.

IAM user: It's a user identity in your AWS account that will have a specific set of permissions for accessing the ElastiCache service.

IAM role: We also can define an IAM role with a specific set of permissions and associate it with the services that want to access ElastiCache. It basically generates temporary access keys to use ElastiCache.

Apart from this, we can also specify federated access to services where we have an IAM role with temporary credentials for accessing the service.

To access ElastiCache, service users or services must have a specific set of permissions such as create, modify, and reboot the cluster.

For this, we define an IAM policy and associate it with users or roles.

Let's see an example of an IAM policy where users will have permission to perform system administration activity for ElastiCache cluster:

{
   "Version": "2012-10-17",
   "Statement":[{
      "Sid": "ECAllowSpecific",
      "Effect":"Allow",
      "Action":[
          "elasticache:ModifyCacheCluster",
          "elasticache:RebootCacheCluster",
          "elasticache:DescribeCacheClusters",
          "elasticache:DescribeEvents",
          "elasticache:ModifyCacheParameterGroup",
          "elasticache:DescribeCacheParameterGroups",
          "elasticache:DescribeCacheParameters",
          "elasticache:ResetCacheParameterGroup",
          "elasticache:DescribeEngineDefaultParameters"],
      "Resource":"*"
      }
   ]
}

Authenticating with Redis authentication

AWS ElastiCache also adds an additional layer of security with the Redis authentication command, which asks users to enter a password before they are granted permission to execute Redis commands on a password-protected Redis server.

When we use Redis authentication, there are the following few constraints for the authentication token while using ElastiCache:

Passwords must have at least 16 and a maximum of 128 characters

Characters such as @, ", and / cannot be used in passwords

Authentication can only be enabled when you are creating clusters with the in-transit encryption option enabled

The password defined during cluster creation cannot be changed

To make the policy harder or more complex, there are the following rules related to defining the strength of a password:

A password must include at least three characters of the following character types:
- Uppercase characters
- Lowercase characters
- Digits
- Non-alphanumeric characters (!, &, #, $, ^, <, >, -)

A password must not contain any word that is commonly used

A password must be unique; it should not be similar to previous passwords

Data encryption

AWS ElastiCache and EC2 instances have mechanisms to protect against unauthorized access of your data on the server.

ElastiCache for Redis also has methods of encryption for data run-in on Redis clusters. Here, too, you have data-in-transit and data-at-rest encryption methods.

Data-in-transit encryption

ElastiCache ensures the encryption of data when in transit from one location to another. ElastiCache in-transit encryption implements the following features:

Encrypted connections: In this mode, SSL-based encryption is enabled for server and client communication

Encrypted replication: Any data moving between the primary node and the replication node are encrypted

Server authentication: Using data-in-transit encryption, the client checks the authenticity of a connection—whether it is connected to the right server

Client authentication: After using data-in-transit encryption, the server can check the authenticity of the client using the Redis authentication feature

Data-at-rest encryption

ElastiCache for Redis at-rest encryption is an optional feature that increases data security by encrypting data stored on disk during sync and backup or snapshot operations.

However, there are the following few constraints for data-at-rest encryption:

It is supported only on replication groups running Redis version 3.2.6. It is not supported on clusters running Memcached.

It is supported only for replication groups running inside VPC.

Data-at-rest encryption is supported for replication groups running on any node type.

During the creation of the replication group, you can define data-at-rest encryption.

Data-at-rest encryption once enabled, cannot be disabled.

To summarize, we learned how to secure ElastiCache and ensured security for PaaS services, such as database and analytics services. If you've enjoyed reading this article, do check out 'Cloud Security Automation' for hands-on experience of automating your cloud security and governance.

How to start using AWS

AWS Sydney Summit 2018 is all about IoT

AWS Fargate makes Container infrastructure management a piece of cake