5 things to know about AWS security

Guest post from Josh von Schaumberg, Senior Solutions Architect at Trek10

As the undeniable leader in public cloud, Amazon AWS is the cloud of choice for most of our VNS3 users. AWS does have “10x more cloud IaaS compute capacity in use” than all other IaaS providers in the 2015 Gartner Magic Quadrant, after all. Plus, the AWS Marketplace makes it very easy to find and deploy products like VNS3 easily.

One of our Solution Integrator (SI) partners, Trek10, is focused on helping customers get the most out of Amazon Web Services. Trek10 helps mid-market and enterprise customers from early adoption/POC stages through to transforming IT efficiency in the cloud. On the Cohesive blog today, Josh from Trek10 has 5 tips to get the most out of AWS security. 

 

From Josh, 5 tips to get the most out of AWS Security features:

  1. Disable and delete your root access key
    When an enterprise creates an AWS account, the initial account created is the “root account.” As the name suggests, this account has full access to do anything with the AWS account (like launch hundreds of servers for bitcoin mining, as an attacker may attempt!). It’s hard to believe that there was a time when the IAM service did not exist, and all AWS API calls were made with the root account. Today, there is no reason a root account should be used for anything outside of a few administrative activities in the console, and the access key should certainly not be activated or in use. Instead, IAM accounts should be created for all AWS access.
    At Trek10, whenever we work with a new account, the first line of action after securing the root account credentials and verifying MFA is to log in as root and check the root access key. If there is an active access key, we immediately notify the customer and request a full audit of the application code to find any root access key use. This key should be replaced with an access key from an IAM account with limited permissions. Rather than deleting the access key, you should first deactivate it and see if anything breaks in your application.consoleIAM.001
  2. Secure admin ports to VPN-connected users only
     Access to administrative ports on public facing servers should not be open to just any public IP address. For example, ports 22 (SSH) on Linux instances and port 3389 (RDP) for Windows instances should be locked down to a private subnet — over a VPN connection only.
    AWS Security Groups
    At Trek10, we use the Cohesive Networks VNS3 to establish a site-to-site IPsec tunnel from AWS to our customers’ on-premise networks. Then, we can lock down all non-public facing ports to an on-premise, private subnet only, meaning malicious actors on the Internet cannot attempt a brute force attack.
    Alternatively, some of our customers have opted for a full cloud migration — meaning there is no on-premise network — or they are remote users who do not typically connect from an office network. For these customers, the VNS3 allows for remote access VPN with secure, certificate-based authentication. This means that users on the road can connect straight into an instance using the AWS private IP address.
  3. Force multi-factor authentication (MFA) for all users
    After ensuring that MFA is enabled on the root account and there is no outstanding access key, the first policy we implement is one which requires all users to configure MFA. When the “force MFA” IAM policy is attached to a user, it denies all other granted permissions until the user sets up MFA and then logs in using MFA.
    Log in to AWS with MFA
    For example, if you attach the forced MFA policy to a user with full administrator rights, s/he will lose all AWS permissions (except those required to configure MFA) until the user logs in using MFA. We combine this policy statement with the policy statement to deny access to CloudTrail (see JSON policy below). Remember, once you configure MFA, you need to logout and then back in using your MFA device before permissions are allowed.
  4. Enable CloudTrail across all regions and deny access to logs
    CloudTrail is an AWS service that is used for audit logging; it records virtually every click in the web console, as well as each programmatic API call to AWS.
    Keep in mind that CloudTrail is not enabled by default, so be sure to turn it on in each region first (we wrote a Python script to quickly accomplish this). To ensure that no malicious actor can tamper with audit logs, it’s a great idea to attach a policy to all IAM users which explicitly denies access to the CloudTrail bucket. You can find the JSON below for the IAM policy which forces users to enable MFA and denies access to the CloudTrail bucket. Note that text outlined with “< >” is customer specific and must be replaced.
    <script src="https://gist.github.com/jvonschaumburg/c535e811077aa6377df6.js"></script>
  5. Use “roles” everywhere you can
    AWS roles have many different uses. In a recent post on our Trek10 blog, you can read an overview of how to leverage role assumption by IAM users for additional auditing and security capabilities. In general, roles are a way to give users or AWS infrastructure necessary permissions to access other AWS services.
    For example, launching an EC2 instance with a role is a simple way to give that instance AWS permissions. Let’s say that your EC2 instance hosts a Ruby application using the AWS SDK, and your application calls static assets from an S3 bucket. Your Ruby application needs the appropriate permissions to access said S3 bucket, which means permanently hard-coding an AWS access key into your source code — a security risk in itself, not to mention the hassle of periodically rotating those keys.
    With EC2 roles, you can launch an instance with the appropriate S3 permissions, and your application will look for an access key in the instance metadata, which is transparently provided by the EC2 role. This key is then rotated every few hours, making your code much more secure and easier to manage.

By: Margaret Valtierra