Levvel Blog - Don’t Let Fear Rule Your Enterprise – Part 2

Don’t Let Fear Rule Your Enterprise – Part 2

The last post in this series gave a general overview of the complaints many enterprise IT organizations focus on when discussing moving to a cloud based infrastructure. The first complaint by IT organizations about cloud infrastructure is they are not as secure as a hosted data center. This post will focus on the security features available in a specific cloud platform, AWS.

AWS has, but is not limited to, the following security procedures available to your organization:

  • Built in firewalls, both internal and external.
  • Encryption in transit with TLS across all services
  • DDoS mitigation technologies
  • Encryption at rest for databases, file storage, and data warehouses
  • Dedicated hardware-based cryptographic key storage options
  • Identity and access management capabilities
  • Multifactor authentication for privileged accounts

The most important aspect of AWS security for your IT organization to understand is that AWS has a shared responsibility security model with it’s customers. This simply means that the AWS engineers will be responsible for securing aspects of the infrastructure, but is not responsible for securing higher level components like protecting your web application from an XSS attack. While this puts more work on your organization, it also gives your IT staff complete flexibility in the configuration of your infrastructure. In addition to giving your IT organization operational flexibility, AWS has a multitude of resources to help your IT organization follow industry best practices. They have a number of whitepapers/guides/best practices/FAQs to help direct your IT organization secure your cloud based data center. These tools are invaluable in protecting your organization’s data. AWS is responsible for securing:

  • Facilities
  • Physical security of hardware
  • Network infrastructure
  • Virtualization infrastructure

The customer is responsible for securing the following:

  • Amazon Machine Images (AMIs)
  • Operating systems
  • Applications Data in transit
  • Data at rest
  • Data stores
  • Credentials
  • Policies and configuration

You may see a few concerning pieces in this list like Data at rest or Data stores. While AWS is not responsible for securing these components, it does not mean they do not provide tools to help their customers follow security best practices for these components that will be explained later in this post.

The linchpin for all AWS security revolves around their Identity Access Management (IAM) product. IAM provides extremely fine grained security mechanisms for giving users, groups, and roles access to AWS services. Users are your individual employee accounts. Groups give the ability to treat a collection of employees the same and allows you to give access to specific resources to a large group of employees. Roles are similar to groups, but you can include both users and AWS resources (like an EC2 box) in a role. You can give specific users access to an RDS instance. You can give your developers the ability to spin up new EC2 boxes. You can even give an EC2 box access to an S3 bucket without storing credentials on the EC2 box via IAM roles. For best practices on configuring you IAM, read this article from AWS.

The second critical piece of AWS’ security protocol is the management of your account’s VPC. According to AWS a VPC “lets you provision a logically isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.” This service is extremely powerful because it gives your IT organization the ability to configure networks utilizing your organization’s current networking strategy. Through the use of subnets, route tables, and AWS security groups your IT organization can restrict access to any device within the VPC. An AWS security group is a virtual firewall to control inbound and outbound traffic within your VPC. AWS states the following properties for security groups in your VPC:

  • You can create up to 100 security groups per VPC. You can add up to 50 rules to each security group. If you need to apply more than 50 rules to an instance, you can associate up to 5 security groups with each network interface. For more information about network interfaces, see Elastic Network Interfaces (ENI).
  • You can specify allow rules, but not deny rules.
  • You can specify separate rules for inbound and outbound traffic.
  • By default, no inbound traffic is allowed until you add inbound rules to the security group.
  • By default, an outbound rule allows all outbound traffic. You can remove the rule and add outbound rules that allow specific outbound traffic only.
  • Security groups are stateful — responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa.
  • Instances associated with a security group can’t talk to each other unless you add rules allowing it (exception: the default security group has these rules by default).
  • Security groups are associated with network interfaces. After you launch an instance, you can change the security groups associated with the instance, which changes the security groups associated with the primary network interface (eth0). You can also change the security groups associated with any other network interface.

Security groups are one of the most critical components of AWS security and gives your IT organization full control over resource access. For example, you can restrict access to your production RDS database to your devops team, but still allow your developers access to your staging database all with a few configuration settings.

Securing users and network resources is a large part of the work performed your IT security staff. Another common complaint of enterprise organizations moving to the cloud is security data access. There are two locations data needs to be encrypted: in-transit and at rest. AWS provides tools for security your data in both locations. For securing data in transit between your VPC and your end users, AWS gives you the ability to configure an SSL certificate in IAM and utilize it to secure traffic over HTTPS. Many organizations will not be concerned about traffic within the VPC as it is already locked down from the outside world. However, if you are concerned about traffic within the VPC because of laws, regulations, or paranoia you can utilize the security groups of AWS to restrict all traffic to HTTPS between resources. Finally, for data at rest AWS provides services for creating a Key Management Infrastructure (KMI) utilizing a Hardware Security Module (HSM). AWS gives customers the ability to be in full control of the entire KMI, AWS can manage the Key Storage only, or AWS can manage the entire KMI. For more information, read the AWS whitepaper on data encryption at rest here.

This post has given a general overview of some of the advanced security you can perform when leveraging your organization. When AWS was first created it was not ready for securing enterprise resources, but in recent years it has become a prime candidate for moving organizations data centers into the cloud. Your IT organization can have full control over user access, networking infrastructure like firewalls, subnetting, or routing tables, and provides mechanisms for encrypting your data in-transit and at rest. Please check back for our next post in this series, which will focus on compliance issues for the enterprise in the cloud. If your organization would like assistance determining your organization’s cloud strategy, please reach out to us at Levvel and we can get you started.

Keith LaForce

Keith LaForce

SVP of Capabilities

I have been in the software industry for over 10 years. I am passionate about designing large scale system architectures, data science, and solving problems that no else wants to consider. I have extensive experience with PHP, .NET, NodeJS, and front-end Javascript.

Related Posts