Factors that underpin cloud security best practices are frequently overlooked during accelerated large-scale migration or adoption. The result is shaky foundations that put the organisation at risk of accidental or malicious breaches. To prevent this, security should be considered a fundamental aspect of cloud builds from the outset, not a standalone activity.
In this blog, we look at how to avoid early cloud mistakes in the initial set-up that can cause problems later. We focus on the AWS Organizations service with a specific slant on security at-scale, using a recent project with a Canada-based bank as an example. When security best practices are implemented in a consistent and repeatable manner, the entire cloud environment becomes more robust and resilient, even during periods of rapid growth and change.
More information on AWS Organizations, including terminology and concepts, is available here.
AWS Organizations: a Centralised Service
The release of AWS Organizations saw AWS move towards a more centralised model for building and operating in the cloud. It forms the basis of a well-architected multi-account environment and facilitates high standards across visibility, efficiency, and management and control. These characteristics made the service ideal for our banking client which was in the early to mid-stage of cloud adoption. However, centralised resources can present problems too, such as increased blast radius if an account is compromised or resources are accidentally deleted. One of the most significant drawbacks is that they are a high-value target for cybercriminals. A checkbox approach to security on AWS Organizations would not go far enough for this client. We needed to fully enumerate the threat landscape so we could devise effective security controls of the right magnitude. Our first step was to secure the management account.
Securing the Management Account
AWS Organizations environments are rooted in a management account (formerly called a master account). One of its primary functions is the creation of new AWS accounts, and policies related to service control, firewalls, tagging and backups are also enforced here. Any breach of the management account will have severe repercussions, so starting out with a rigorous approach to its configuration is essential.
We began by considering the complex threat landscape of the management account. For instance, the fact that it provides unique identifiers for use in policy statements can facilitate default access at that level. It also allows full administrator access to sub-accounts by default, enabling single-click resource deployment across the entire AWS Organization. Additional risk factors include its ability to eject an account from the Organisation or invite accounts to join it.
A common misconception is that service control policies (SCPs) for permissions will mitigate many of the above risks. However, SCPs have no effect on the management account, so specific controls need to be implemented and automated. Effective approaches include the use of multi-factor authentication (MFA) on the build pipeline and custom automation scripts for identity and access management (IAM). Enhancements can be made to detective controls and log audits too, alongside baselining account activity and monitoring deviations from this. Setting these measures up from the get-go significantly improves the overall security posture, and this is the approach we took for the Canadian bank.
Leveraging Multi-account Structure Benefits
When it’s deployed strategically, a multi-account structure like that offered by AWS Organizations is one of the most secure ways to build and operate in the cloud. The secret is to create accounts with security in mind. As with many aspects of cloud best practice, this is facilitated by a ‘cattle not pets’ mindset shift and we supported our client in making this important transition.
Think about what an account is for. It doesn’t do anything itself, it’s simply a place for applications to land. So, creating separate accounts for different development teams and applications is a rational way to both augment and simplify security. When teams can only access their own accounts, there’s less need for complex permissions within them. What’s more, AWS accounts function as IAM domains by default because permissions do not extend outside the account. This facilitates effective role-based access control (RBAC) and attribute-based access control (ABAC), which is especially useful for large enterprises or those operating in highly regulated industries.
Tactical use of parameters for different AWS accounts can also aid security. You might set service usage limits according to the needs of workloads deployed to individual accounts. Cloud zoning units can also be enhanced through policies and API disablement to reduce applications’ attack surfaces.
To streamline the management of multiple accounts, we advised the bank to take advantage of the AWS Organizational Units (OU) capability. This enables accounts to be grouped together in a logical and straightforward way. It’s also possible to apply policies at the OU level. The following diagram gives a high-level overview of the bank’s OU structure. Each element apart from the ‘root’ represents a distinct OU and contains accounts that are relevant to its purpose.
Security policies applied at one level cascade down to the next, so we take general measures at the root, then become more specific in the layers beneath. With the Canadian bank, we focused on setting up ‘explicit denies’ at the root for actions that would not be permissible in any of its OUs. This included explicit denies to mitigate threats such as attempts to delete or disable encryption keys, or the creation, deletion or modification of networking infrastructure that could punch holes through the platform’s perimeter defense.
At the platform level, we used techniques such as ‘implicit denies’. For instance, we enabled around 20 AWS services including S3, CloudFront, EC2, Web Application Firewall and EKS. Those that weren’t enabled had their functionality denied by default. Moving down to the next level, we considered what each OU needed, ensuring it was given just enough capabilities to perform its intended function. Take the network OU; it didn’t require database functionality, so by not enabling this we minimised the threat surface.
From the services and portfolio OUs, we branched into production and non-production OUs. Again, this segmentation enhances risk management. Tight controls need to be exerted in production, whereas controls can be sparingly relaxed to permit experimentation in lower environments. For example, in a non-production environment, you might allow the ability to edit Lambda functions directly to avoid the delays caused by having to re-run new code through the deployment pipeline. Similarly, having a standalone sandbox OU means developers can be given greater freedom to explore new tools, services and approaches without putting the other OUs at risk.
Setting out Naming Conventions
We also set the bank up with a standardised naming convention, as per the above diagram. Many of the problems experienced after an accelerated or ad hoc approach to cloud migration are linked to the haphazard naming of accounts and deployed resources. As the number of cloud resources escalates this can quickly result in poor visibility and traceability which hinders security management. Taking a simple, consistent approach from the outset mitigates this risk.
Besides improving visibility, a coherent naming strategy facilitates the use of algorithms for the creation of new accounts. It can also be aligned with various deployment strategies, such as the Git feature branch workflow model. In the above diagram, names clearly indicate account tiers [i.e. production (prod) or non-production (nonp)] making it easier to separate
environments (or branches in a Git feature branch model). This is something that development teams are extremely familiar with, and it loops back to the above point about the inherent security benefits of the multi-account structure.
Simple Steps Make a Big Difference to Security
The measures we adopted for the bank – securing the management account, leveraging multi-account benefits, and setting out naming conventions – are not difficult. However, they are easily overlooked by teams that lack cloud experience or who need to move to the cloud fast. In fact, these two circumstances often go together, and the resultant security vulnerabilities put the entire organisation at risk. Taking a thorough, well-architected approach to security from the start avoids the need for complex and costly ‘cloud v2’ projects in years to come. It pays to lay strong foundations for cloud at scale, and security due diligence plays a central role.
James Peek is a Principal Cloud Consultant at Sourced. Find out more about our approach to cloud security here.
James Peek is based in Toronto, having been with Sourced Group for 4 years. His passions include helping businesses enable secure public cloud consumption at scale. In his free time, he enjoys skydiving, scuba diving and motorbikes.
