Zero-trust model boosts AWS infrastructure security
Security worries slowed early cloud adoption, and while many organizations eventually migrated, they failed to lock down access. Here's one way to combat that problem.
For a long time, many businesses relied on security zones as key parts of their infrastructure security plans. This zone-based framework differentiates an internet-facing, untrusted zone and a demilitarized zone -- a subnetwork that exposes external-facing services to that untrusted zone -- from a trusted zone, which is typically an internal network contained within a data center. This security framework allows or denies traffic flow accordingly.
While this model works well to separate your infrastructure from the outside world, it lacks the kind of granular internal segmentation that greatly benefits overall network security.
Today, as more enterprises migrate to the public cloud, they must place even tighter controls over access to business environments. One way to achieve this is through a zero-trust model, although this requires careful planning to implement in AWS infrastructure.
Trust no one
The zero-trust model relies on a principle of no inherent trust. This approach reduces threat levels through microsegmentation and granular enforcement of rules on each perimeter within your infrastructure. To use a zero-trust model, IT teams must implement security on all levels, as the overall protection of your account is only as strong as its weakest link.
With this model, users can only access resources or applications on a need-to-know basis. This requires administrators to identify the traffic and flow of the data but also to understand who the users are that access their data.
An IT team must also implement least-privilege access control, as it can significantly reduce both internal and external pathways for potential attackers. In addition, teams must log and inspect all traffic, regardless of the source or destination. This "never trust, always verify" methodology completely trumps the idea of inherent trust and further reduces the chance of intrusion into your critical resources.
When you implement a zero-trust model on AWS, only focus on the traffic flowing inside your cloud infrastructure; all the data that enters your data center from either the public internet or your own on-premises data center -- via virtual private network or Direct Connect -- has to hit the AWS firewall. By default, this means there is no trust between AWS and any external systems.
Get more granular
Within your AWS environment, you can further segment via network access control lists (ACLs) and security groups.
Network ACLs provide an optional layer of security that operates on a subnet level and limit traffic based on predefined rules. Both allow and deny rules are accepted, and they are evaluated from the top down. These lists are stateless, which means they do not allow return traffic by default; it must be explicitly allowed. Admins apply network ACLs to subnets to monitor all traffic that flows to instances within that subnet. You can have only one network ACL per subnet to avoid a conflict with the rules, but you can apply one network ACL to multiple subnets, which enables you to protect many resources at the same time.
New technologies lead to new security approaches
Before cloud computing, physical hardware limited successful implementation of security models, like zero trust. Security appliances protected infrastructure at various perimeter points, mostly separating an on-premises private network from a public one. Infrastructure as a service and virtualization enabled the possibility of distributed firewall technology to control traffic and enable microsegmentation on all levels. With a flurry of tools available, administrators can now abide by zero-trust principles and follow guidelines to protect their infrastructure.
If you allow access to a critical subnet from anywhere within your AWS environment, anyone can potentially access -- and abuse -- that subnet. But if you use the network ACL, AWS limits access to that subnet to a number of sources from one other specific subnet or, even better, only a few instances. This greatly reduces the chances of a security breach. You can also limit access from a subnet. For example, you might want to explicitly deny all developer subnets access to any production environment.
Security groups operate on an instance level and only support allow rules -- whatever is not explicitly allowed is automatically denied -- but unlike with network ACLs, all rules are evaluated. Security groups open access for inbound traffic only, and outbound traffic is always allowed. These groups are also stateful, so they allow return traffic by default.
Admins can only apply security groups to instances when they select to, either during the provisioning process or when they modify an instance. For example, you can allow only Secure Shell (SSH) access to an instance and only from a specific range of IPs used for bastion host. Alternatively, you could allow only TCP port 3306 for MySQL to a Relational Database Service instance, but only from your web servers.
