Recent leaked documents have toppled analyst expectations of the Big Four hyperscalers’ market. While Azure was thought to hold its own in the cloud services market, the poorly-redacted documents – part of Microsoft’s ongoing battle with the Federal Trade Commission – showed a valuation $10 billion lower than previous analyst estimates. AWS’ market domination is even greater than once thought.

Despite the flexibility offered by AWS’ new form of infrastructure, the cloud provider has also been uncomfortably close to cutting-edge attacks leveraged against some of its largest customers. Knowing how to make use of AWS – without it becoming your organization’s weak spot – requires a thorough understanding and implementation of the following four areas of best practice.

Identity and access management: Centralize and enforce

Humans aren’t the only identities making use of your cloud services. In fact, the employees, administrators, and developers that make up your colleagues are vastly outnumbered by the swarms of machine identities handling your organization’s AWS requests and resources. Each identity involves its own type of risk: as identity and access management is today’s security front-line, it’s vital to treat each with due caution.

Best practices for human identities

Human identities are as they sound – individuals like administrators, developers, operators, and consumers who access AWS environments and applications. They can be internal members of your organization or external collaborators who interact with your AWS resources using various tools like web browsers, client applications, or mobile apps. Protecting from human identity misuse requires the following guardrails:

Enforce strong passwords

Password length holds a direct relationship with their security. This is because each extra character demands exponentially more from attackers’ brute-force computation attempts. By enforcing a minimum length and complexity, users have the guardrails to keep their accounts safe.

Use Multi Factor Authentication (MFA)

Credential theft generates a huge proportion of cyberattackers’ illicit wages. MFA can drastically strengthen the authentication process, allowing you to prove who’s behind the screen by requesting an extra layer of proof.

Give each user their own identity

Instead of using shared credentials, it is recommended to create individual identities for each user. By doing so, each user will have their own unique set of security credentials – this sets the foundation for more granular visibility into each user’s activities.

Rely on a centralized identity provider

No matter what stage of cloud architecture growth you’re at, the number of services and applications swirling throughout a modern tech stack can quickly stack the cards against streamlined authentication. To combat this, AWS best practice suggests using a centralized identity provider. This gives you a single platform for overseeing all authentication processes, and gives you greater control to allow users to register their own MFA devices and implement adaptive authentication processes.

Best practices for machine identities

These identities are used by your workload applications, operational tools, and components to make requests to AWS services. They include machines that read and edit your AWS environments, such as EC2 instances or Lambda functions. as these constitute the majority of your cloud-connected identities, it’s vital to adhere to the following practices:

Use temporary credentials

Given the risk that leaky machine identities pose, temporary credentials offer immediate improvement to your security baseline. Instead of long-term access keys, developers can make full use of the service-specific guardrails that help abstract short-term keys, minimizing any disruption in the Software Development Life Cycle (SDLC). For example, AWS Lambda offers an execution role that grants service permissions via temporary credentials; AWS Cognito and EC2 offer identity pools and roles that automatically configure short-term credentials.

For scenarios that don’t fit short-term access keys – such as users with programmatic access – best practice dictates that access keys are rotated regularly. This process can be implemented with no interruption to running applications or accounts.

Store and use secrets responsibly

Including IAM access keys directly within source code, configuration files, or mobile applications is a leading cause of breaches.

To assess your own infrastructure and identify secret mismanagement, automated tools such as Amazon CodeGuru can scan your code repositories and filter the results by Type=Secrets. This will help you identify the code paths that contain hard-coded credentials.

Make the most of user groups

As the number of users you handle increases, managing them efficiently at scale becomes increasingly important. To achieve this, it’s essential to organize users with similar security needs into groups established by your identity provider. Additionally, ensure that user attributes, like department or location, which may impact access control, are accurate and kept up-to-date.

By utilizing these groups and attributes for access control, you can simplify management processes. Instead of dealing with individual users, you can centrally manage access by modifying a user’s group membership or attributes. This approach saves time and effort, as you won’t have to update numerous individual policies whenever a user’s access requirements change. Alongside making life easier for the security team, it shows the positive momentum that each practice builds: with each change, your cloud undergoes exponential security maturation.

Data protection: Encrypt and classify

The data that populates your AWS architecture is one of the most valuable components of your organization. Unfortunately, many engineers and security teams fail to implement suitable protective measures. Below are the three forms of data protection that need to form the backbone of your organization’s defenses.

Classify

Knowing who can access, modify, and delete data is an essential part of protecting it. Data classification allows you to decrease the scope of sensitive data and implement stricter access controls for the data that needs it. Alongside helping build a deeper understanding of different data types, classification also allows you to optimize costs by reducing any duplicated data taking up database or compute space.

A key component of data classification is tagging: this allows your security team or engineers to assign metadata to various AWS resources, thereby making the data easily searchable and traceable. While the prospect of retroactively tagging entire S3 databases can seem daunting, this can be automated with services such as Amazon Macie.

Protect data at rest

Data rest represents one of the easiest modes to secure. It includes any data that persists in non volatile storage, including block storage, object storage, databases and archives.

Encryption maintains the confidentiality of sensitive data even in the event of a breach thanks to a cryptographic key – without this key, content can’t be decrypted into plaintext. Services such as Amazon S3 allow you to enforce encryption on a bucket by default, meaning all new objects will automatically be encrypted.

Given the importance that decryption keys play in data security, it’s vital to keep an eye on how liberal your organization’s approach to key access is. Unmonitored and overly-permissive keys can allow an attacker just as much access to a database as no encryption at all.

Protect data in transit

Encryption continues to play a major role in securing data in motion: this is provided by HTTPS endpoints, which only communicate via secure TLS protocol. Traffic that flows solely within your internal network confines is supported by internal encryption. Furthermore, AWS internal networks within the same zones are decrypted by default – making DNS sniffing or spoofing impossible.

Infrastructure protection: Segment and manage in macro

Create network layers

By grouping components that share sensitivity requirements together, your organization can minimize the blast radius of unauthorized access. One of the most accessible forms of segmentation is AWS’ basic VPC. These offer segmented layers to serverless workload deployments and Lambda functions. To give an on-the-ground view of how your resources are configured, use tools such as the AWS Reachability Analyzer. Once you’ve verified that there are no anomalies in the paths linking source and destination, the Network Access Analyzer can further highlight unintended network access to resources.

A focus on layer segmentation should also define how you approach traffic within your network layers: for instance, traffic should flow only from the next least sensitive resource, instead of allowing direct database access from the load balancer or even the application itself. By logically grouping similar network components, unauthorized users are given far smaller scope to pivot to high-sensitivity resources.

As the scope of your organization’s network connectivity increases to hundreds or thousands of VPCs, AWS Transit Gateway provides a hub that grants a wider scope of control over how traffic is routed.

Control traffic at all layers

Part of the power of VPC is the definition it lends to your security team. Not only can you define your own network topology across each AWS region, but subnets can further lend a greater degree of visibility into how your networks’ access patterns.

With each resource cluster attributed to its own private subnet, the IP traffic coming in and out of each can be closely tracked. This monitoring defines the strength of your incident detection and response process. Subnet creation further bolsters wider swathes of best practice, as the tagging function helps engineers understand each group’s individual process.

As this shift-left process allows your security team’s focus to become increasingly macro, the management of multiple security groups can be bolstered with tools such as AWS’ Firewall Manager.

Reduce your attack surfaces

Managed services go far beyond infrastructure offerings – with them, core compute resources can be transformed into a hardened part of your defenses. Amazon Relational Database Service (RDS), for example, helps operate relational databases while automatically keeping administrative tasks at a best-practice baseline. Taking full advantage of the shared responsibility model can also let you prune your compute resources; shrink the number of consumable services in use; and identify active vulnerabilities in your architecture. This process helps reinforce the next area of AWS best practice.

Detection and incident response: Store and simulate

Analyze logs centrally

Effective security management requires a cohesive view of the entirety of your cloud structure. As a result, organizations need a singular capability to retrieve event logs reliably and consistently.

To achieve this, centralized logs need to be brought together into a unified location. Centralization simplifies log management, analysis, and monitoring, making it easier to detect potential security threats and respond promptly when necessary.

An on-the-ground example of this best practice is the integration of security events into a dedicated workflow or ticketing system.

Keep a long-term view of log storage

When selecting a log querying tool, consider the people, process, and technology aspects of your security operations. Choose a tool that meets operational, business, and security requirements, and ensure it remains accessible and maintainable in the long term. Keep in mind that log querying tools perform best when the number of logs falls within their capacity limits; this is why it’s common practice to use multiple querying tools.

For context, AWS customers typically have three months to one year of logs available for querying – they may then retain logs for up to seven years.

Automate event response

Amazon EventBridge offers a scalable rules engine in AWS, enabling investigations into unexpected changes. It can handle both native AWS event formats, including AWS CloudTrail events, and custom events generated from your applications.

Amazon GuardDuty complements this by allowing you to route events to various destinations. These suspicious events are then fed into an incident response system like AWS Step Functions; a central Security Account; or a bucket for further analysis. This builds a hyper-accurate forensic toolkit to help you zero in on suspicious events proactively.

Simulate

With each of these security best practices in place, it’s easy for organizations to feel invulnerable. However, it’s vital to keep in mind the fact that – as organizations grow – so do the threats facing their infrastructure. Simulations use real-world threat scenarios to put your infrastructure to the test.

Make security simple

Security has traditionally felt like a Sisyphean task; the new generation of AI and automation promises to change this by lending security analysts and engineers increasing control over multi-headed hybrid environments. Alongside this, AWS-native tools offer a first step toward stricter access and infrastructural protection at every level.