Secure cloud governance guardrails with AWS Organizations and Network Access Management
Cloud Governance guardrails are essential for enabling your developers to work fast, without having to second-guess each change for how it aligns with your security posture or compliance.
In a recent blog post we took a close look at Identity Access Management (IAM) and Resource Configuration Management. We defined which guardrails are most effective for preventing issues like privilege escalation and configuration consistency issues. A solid strategy is needed for these, otherwise your cloud can quickly become vulnerable and/or hinder your development team value delivery velocity.
This time, we’re going to focus on what guardrails you can put in place using AWS Organizations and what Network Access Management measures are needed to secure your network. This way, you can directly benefit from our own experiences - and without having to learn from your own mistakes!
Trust us - by taking just a little time to put these guardrails in place, you can save a whole lot of time and heartache down the road.
Taking control with AWS Organizations
It’s easy to centrally manage all the accounts in your organization with AWS Organizations.
It gives a clear overview and offers a wide range of options for access management and other policies.
These policies can be applied selectively to specific accounts, groups, or the whole organization, depending on what is needed. By putting general and granular policies in place, you can keep everything running the way it should, without needing to manage things manually each time.
Here are some key policies we recommend setting up in AWS Organizations:
Service control policies (SCPs)
These aren’t a replacement for a comprehensive IAM strategy, but SCPs can give you an extra layer of protection.
These policies define the maximum allowable permission that can be granted, minimizing the potential for privilege escalation. SCPs are managed centrally, and cover all the accounts in your organization.
SCPs can be used to prevent users from deleting certain logs, or to prevent them from disabling services like AWS Config or CloudWatch, or altering their configuration,
SCPs can also be used to control which regions or resources are allowed to be used.
Tag policies
With a good tagging system, you can easily create granular reporting like detailed cost breakdowns, inventories of AWS resources, and create an easier access management system based on tags like team name, business unit, etc. Tags enable a sophisticated system for categorization and allow you to keep complex resources well-organized. For example, we often use tags like ‘environment’, ‘product’, or ‘team’, to make it easy to isolate the right resources.
But to deliver the promised value, your tagging system must be 100% consistent. Tag policies help achieve this by enforcing your preferred schema across the whole organization.
Tag policies are easy to create – they’re just simple JSON statements that define which values are permitted for each resource type. The result is a consistent (reliable) tagging system that can quickly identify non-compliant tags.
Good to know: Tag policies are managed in AWS Organizations, but the compliance of tag policies is managed via AWS Resource Groups.
Organization-wide backup with AWS Backup
Neglecting backup is always a bad idea. Backups are one of the pillars of reliable IT, so you need to have a complete backup strategy that can be enforced across all accounts in your organization.
Thankfully, it’s easy to set up a comprehensive backup strategy by managing backup in AWS Organizations. This will ensure that all resources assigned to an organization or organization unit (OU) are backed up on a regular basis.
Backup policies are defined in an easy to read JSON text. These are then implemented by attaching the policy to the organization root, organizational unit, or to specific AWS accounts.
You can also create backup plans in AWS Backup, which define the backup period, frequency, and duration of backup storage. You can monitor backup events in AWS CloudTrail. This is a situation where a good tagging system (enforced by your tag policies, above) will really help, as tags are used to identify resources for backup too.
Network Access Management
With AWS Organizations keeping an eye on the account activities across your organization, the other side to look at is your network itself. Securing and controlling network access and traffic is another vital layer of protection that safeguards your cloud without placing unnecessary restrictions on developers.
Control over your network means you have better control over where traffic is routed and governed. With these four guardrails you can easily manage and control network access while enabling third-party or remote access possibilities.
Route table
Defining a route table for your subnet allows you to determine which routes traffic will flow to based on CIDR block, and how packets are routed within your Virtual Private Cloud (VPC).
By restricting which routes packets can take, it’s far harder for packets to be routed outside of your trusted cloud.
Security groups
Security groups are often compared to being ‘like a firewall’, and you can manage VPC security groups within your VPC. AWS Security Groups allows you to have control over what traffic is allowed to reach defined resources, traffic source can be IP CIDR or another security group
With an assigned security group (or multiple groups) for each resource, you can define which network traffic is permitted access. VPCs are assigned a default security group automatically as soon as they’re created, with the default settings. These allow HTTP (80) and HTTPS (443) traffic by default. Most of the time the default security groups are enough, but you can also request custom security groups from AWS Managed Services, when the need is clear.
Network access control lists (ACLs)
Network ACLs are very effective at restricting network access by only permitting whitelisted inbound/outbound traffic to subnets. It can act as a safety guard against mis-configured security group configurations. The network ACL will always take precedence over a security group.
By default, the ACL will allow all traffic, unless you specify otherwise. ACLs are customizable, so they can always reflect your overall security posture and other policies, and align with the security groups you’ve set up.
An ACL rule is made of these key elements: rule number, type, protocol, port range, source, destination, and allow/deny.
Client Virtual Private Network (VPN)
There may be situations where third parties or contractors need access, or where team members need to work remotely and still need access to your cloud. In these cases you can enable secure network access over TLS connections with a client VPN.
With AWS Client VPN, you can both grant secure access to resources in your network, and retain an overview of activity, including login attempts, with the connection logs.
This means you’re not just handing over the keys to users with remote access. Instead, you can precisely control external access and keep a close eye on access patterns. Rules can be customized and highly specific, and defined at the active directory level.
Meeting the specific needs of your cloud
Each layer of protection you can add will provide you with peace of mind without adding extra work for you or your team.
Combined with guardrails for Identity Access Management (IAM) and Resource Configuration Management, the measures we’ve highlighted for AWS Organizations and Network Access Management will help you start out right, and protect your cloud as you move forwards.
Of course, every project and every team is different, so you may need to apply guardrails differently. You may also need additional measures, other than the ones highlighted above.
