Skip to main content

Use of an insecure channel - AWS

Need

Secure communication channels for data transmission in AWS

Context

  • Usage of Terraform for Infrastructure as Code (IaC)
  • Usage of AWS SDK for interacting with Amazon Web Services

Description

Non compliant code

provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
}

resource "aws_instance" "example" {
ami = "ami-0c94855ba95c574c8"
instance_type = "t2.micro"

tags = {
Name = "example-instance"
}
}

In the above Terraform code, we are creating an AWS instance in the us-west-2 region. The AWS provider is being configured with access_key and secret_key. However, this code doesn't implement any secure communication protocols or cipher suites.

This means that all the communications between the Terraform client and AWS endpoint are susceptible to Man-in-the-Middle (MitM) attacks, where an attacker could potentially intercept the communications, gaining unauthorized access to sensitive data, and possibly even modifying the data in transit.

In addition, the identity of the remote end of the connection (in this case, the AWS endpoint) is not being authenticated. This could allow an attacker to impersonate the AWS endpoint, tricking the Terraform client into sending sensitive data to an unauthorized endpoint.

This is a serious security vulnerability, as it could lead to data breaches and unauthorized access to AWS resources.

Steps

  • Use HTTPS instead of HTTP for communication with AWS services
  • Enable encryption in transit by configuring SSL/TLS for the communication channel
  • Ensure that secure cipher suites and encryption protocols are used
  • Implement mutual authentication to verify the identity of the remote end of the connection
  • Avoid hardcoding access keys and secret keys in the code, instead use secure credential management solutions

Compliant code

provider "aws" {
region = "us-west-2"
access_key = var.access_key
secret_key = var.secret_key
}

resource "aws_instance" "example" {
ami = "ami-0c94855ba95c574c8"
instance_type = "t2.micro"

tags = {
Name = "example-instance"
}

ebs_block_device {
encrypted = true
}
}

The updated code now uses variables for access_key and secret_key instead of hardcoding them directly into the provider block. This is a more secure practice as it prevents the keys from being exposed in the code. The keys can be provided through a secure method such as environment variables or AWS Secrets Manager.

In addition, an ebs_block_device block has been added to the aws_instance resource with the encrypted argument set to true. This ensures that the EBS volume attached to the instance is encrypted, providing data-at-rest security.

Please note that this code assumes that you are using a secure communication channel (HTTPS) with AWS services, and that you have enabled secure cipher suites and encryption protocols. Also, it is recommended to implement mutual authentication to verify the identity of the remote end of the connection.

Remember to replace var.access_key and var.secret_key with your actual AWS access key and secret key, which should be stored securely and not hardcoded into your Terraform code.

References