Managing Complexity and AWS Security

Organizations making the jump from on-premise to cloud have to confront a broad set of security challenges. Amazon Web Services (AWS) provides a set of managed services and features designed specifically to address these risks. However, a common concern amongst startups and smaller engineering organizations is the feasibility of effectively utilizing these AWS security features — especially without substantial infrastructure or DevOps expertise. This article will explore some primary concerns in securing AWS cloud infrastructure. We’ll start off exploring how to build the right mental model for how to think about securing cloud infrastructure.

How to Think About Security in the (AWS) Cloud

Thinking about security within the content of Amazon Web Services (AWS) — or indeed any cloud service — requires an understanding of two core concepts: the Shared Responsibility Model and the fuzzy network boundary.

Shared Responsibility Model

AWS's Shared Responsibility Model sets out the responsibilities between AWS and AWS customers across various layers of the cloud infrastructure stack. The shared responsibility model is separated into two parts:  "Security of the Cloud" - AWS's responsibility - and "Security in the Cloud" - the customer's responsibility. AWS protects the infrastructure that operates all AWS Cloud services. This includes hardware, software, networking, and facilities. The customer's responsibility varies depending on the AWS Cloud services selected. It can range from security configuration and management tasks to managing data, classifying assets, and applying appropriate permissions.

This separation of concerns reflects a new paradigm in how engineers and technical leadership should think about securing their data and infrastructure. Traditional, physical infrastructure is implicitly cataloged and configured as it's deployed into a pre-defined geographic location. However in the cloud, this is the provider's responsibility. Security boundaries and processes can no longer be quantified by physical units. The focus shifts wholly to the application and configuration layers of the architecture; as one attack surface goes away, another expands significantly.

Fuzzy Network Boundary

The term “fuzzy network boundary” represents a more significant shift away from the logical network architecture patterns that often define on-premise computing environments. Traditional server networks are typically encased within multiple router/firewall boundaries. This creates a well-defined, logical network perimeter. New servers are, by default, not internet reachable. The physical segregation of network topology in a bare-metal datacenter means that security operations can count on an implicit security boundary being available and enforced for all newly provisioned computing resources and datastores.

In the cloud, this implicit security boundary no longer exists. In many cases, newly provisioned resources and datastores can be made to be publicly reachable with a few configuration toggles. This shift in network boundary dynamics demands a drastic change in how security is approached. Unlike the relatively static configurations of on-premise environments, cloud environments change often requires a much more proactive approach to securing data and resources. Instead of relying on the physical boundaries and inherent isolation of on-premise infrastructure, security in the cloud is heavily dependent on the correct implementation and continuous management of configurations, permissions, and access controls.

The correct approach to dealing with this shift is adopting a zero-trust architecture. Zero-trust operates on the principle that no user or system is trusted by default, whether inside or outside the network perimeter. Every access request to resources is authenticated, authorized, and encrypted independently; it’s assumed that any request or network traffic, at any time, could potentially have malicious origins. This approach necessitates rigorous identity and access management, micro-segmentation of networks, and robust encryption mechanisms. This often means a significant up-front investment in design and implementation, but it’s ultimately necessary to have an effective security model.

Network Security in the Cloud

While the Amazon Web Services (AWS) cloud environment allows for immediate public accessibility of individual nodes and resources, it does not completely abandon logical network constructs. AWS provides services such as Virtual Private Cloud (VPC), subnets, and NAT Gateways, which can effectively emulate a software-defined version of a traditional physical network.

The primary managed services AWS provides to help secure the boundary and overall network include:

• AWS Firewall Manager - A security management service provided by Amazon Web Services. It allows users to centrally configure and manage firewall rules across their accounts and applications in the AWS environment.

• AWS Network Firewall - A managed service by Amazon Web Services designed to provide network-level protection across Virtual Private Cloud (VPC) environments. This service allows users to create stateful firewall rule groups and policies to filter traffic at the network layer, monitor network activity, and block unwanted traffic patterns. 

• AWS Shield - A managed service offered by Amazon Web Services aimed at protecting applications running on AWS against distributed denial of service (DDoS) attacks.

• AWS Verified Access - A newer service that provides WireGuard-like capabilities by eliminating traditional VPNs and implementing a zero-trust network authentication model.

• AWS Web Application Firewall - a security service offered by Amazon Web Services that helps protect web applications from common web exploits. It enables users to set up rules to allow, block, or monitor (count) HTTP and HTTPS requests based on conditions such as IP addresses, HTTP headers, HTTP body, or URI strings.

Further monitoring can be enabled via VPC flow logs. VPC Flow Logs capture information about the IP traffic going to and from network interfaces in a Virtual Private Cloud (VPC). Monitoring these logs can be accomplished by storing them in other managed services like Amazon CloudWatch Logs or Amazon S3, or sending them to an Amazon Kinesis Data Stream for real-time or near-real-time analysis. Cloudwatch can be used to create filters and alarms to alert on specific events or anomalies.

However, it's difficult to overlook the reality: configuring multiple managed cloud services for network security is a complex endeavor. Effective management of cloud resources at scale, necessitates infrastructure-as-code (IaC), which brings its own demands on operational and technical acumen. Without forward looking design roadmaps and implementation skills in place for managing cloud network resources, this can quickly spiral into a brittle and tech-debt laden system. Managed services can also have a compounding effect on cost, particularly network-based services that charge based on traffic or number of rulesets.

Identity Security

Managing identity infrastructure and keeping it secure is one of the most important facets of cloud infrastructure security. Any compromise to user identities or credentials can pave the way for severe data breaches and unauthorized access.

Amazon Web Services (AWS) offers a range of services specifically designed to handle identity-related concerns. These include:

• AWS Identity and Access Management (IAM) - IAM is the core service that underpins identity and access in the AWS cloud. AWS IAM is a Relationship-Based Access Control (ReBAC) system. It enables assignment of permissions to specific roles, which are attached to identities representing users or services. These permissions are outlined in policy documents, which define what actions are allowed or denied on specific AWS resources.

   

• AWS IAM Identity Center (the successor to AWS SSO) - AWS IAM Identity Center provides Single-Sign-On capabilities for organizations with existing identity management platforms. 

• Amazon Cognito - Manages user authentication and access for web and mobile applications.

• Amazon Verified Permissions - Manages and authorizes permissions for custom applications. It centralizes policy management and administration using the Cedar policy language.

• AWS Directory Service - AWS managed service implementation of Microsoft Active Directory (AD).

• AWS Resource Access Manager - Makes cross-account and cross-organizational sharing of resources easier to manage via IAM policy.

• AWS Organizations - Consolidates and centrally manages multiple AWS accounts. It allows for policy-based management of multiple AWS accounts.

Recent service additions like AWS Resource Access Manager and Amazon Verified Permissions, as well as AWS Organizations makes the implementation and management of IAM easier. Prior implementations required customers to craft complex, bespoke automation to apply and enforce IAM configuration in large or complex environments. However, even with managed services, careful choices must be made around how the system is designed, implemented, and managed.

The selection of an appropriate identity management design and implementation depends on several factors. These include the existing infrastructure, the size of the engineering team, the complexity of the environment, and future growth plans. For a small team, AWS IAM and Identity Center might suffice. However, as an engineering organization grows, so too does the complexity of its application architecture, and with it the complexity of managing access and authorization. For a small startup focusing on shipping an MVP, “good enough” is often all that’s needed for an identity implementation, but what about scaling? Early design choices may limit future flexibility, creating potential bottlenecks and security vulnerabilities.

Configuration Security

Effective management and enforcement of cloud resource configuration is foundational to maintaining a secure cloud environment. Misconfigurations can unintentionally expose sensitive data, create opportunities for unauthorized access, and disrupt service functionality. Having robust policies and systems in place to manage and monitor resource configuration is not just a best practice, but a necessity for any organization operating in the cloud.

To assist in managing these concerns, AWS offers services such as AWS Config, which aids in auditing and establishing a baseline of configuration state. Amazon CloudWatch and AWS CloudTrail can provide event streams or logs emanating from resources and the AWS API, providing visibility into operational health and application performance.

Nevertheless, it's important to note that these services come with a fairly bare-bones set of defaults. While they provide a foundation, most organizations will find that they need to develop custom policies and automation that’s integrated throughout the Software Development Life Cycle (SDLC) to effectively manage configuration. For instance, an organization may implement policies using Open Policy Agent's (OPA) rego language, which are then automatically applied to code changes in infrastructure-as-code environments.

Organizations often find the biggest challenge with large cloud environments like AWS is that maintaining a baseline configuration, and enforcing it, becomes exponentially more difficult as their cloud usage grows. Maintaining a baseline configuration across cloud resources is integral to ensuring a consistent and secure operating environment. However, without proper identity and access management (IAM) practices in place, new resources might bypass these configuration enforcement measures. This can lead to potential security vulnerabilities.

Managing Security Means Managing Complexity

AWS offers a variety of services that appear to make cloud security easy. However, even managed services demand domain and provider-specific experience to fully utilize, and implementation becomes even more complex as headcount grows and the application architecture expands. 

For startups and small teams, the primary focus is often on feature delivery; product development and business growth are the lifeblood of a startup. For these teams, a platform-based approach may be the best path. Divio’s PaaS solution shifts more of the operational and security responsibility away from development teams. By abstracting away as much of the operational and security burdens as possible, these teams are free to focus on application engineering. Managing reduced complexity ultimately makes managing security an easier goal to achieve.

Interested to learn more about Divio's approach to cloud security? Contact us and let's talk!

Join us over on LinkedIn and X/Twitter for access to exclusive insights, news, and more.