Blog

AWS Security Deep Dive

Table of Contents

Hackers Held 23,000 Unsecured MongoDB Databases Ransom

Choosing, developing, managing, and operating your infrastructure in the public cloud requires a lot of consideration. Today’s organizations may have data stored in traditional places, like data centers and on-premise networks, but it’s also stored elsewhere, such as in endpoints, with third-party vendors, and, of course, in the cloud. In those environments, identifying who or what is accessing data and ensuring access is limited to need and nothing more is critically important. Just as perimeter defenses were once the prime way to protect data, now identity has assumed that role.

With identity as the new perimeter, organizations need to fashion their data protection strategy as if the network controls they’ve implemented don’t exist. In that “Zero Trust” world, anyone or anything that accesses data needs to be authenticated, not just once, but continually. What’s more, they shouldn’t be given more access than they need to fulfill their job, commonly referred to as “least privilege.”

Maintaining a Zero Trust environment can be a complex task. It can require the creation of thousands of rules to achieve the granular permissions needed to make the process work. That’s why it’s important for organizations to understand their public cloud provider’s security approach.

Let’s take a deeper look into AWS Security

AWS has greater flexibility in the design of its offering for the public cloud than some of their competitors. They have done a nice job of making identity one of the prime control mechanisms across the AWS platform. What’s more, AWS has continued to add functionality to those identity controls to make its security better and better.

Last year, for example, AWS incorporated the ability to add tags as a control to an identity policy. That now gives an organization a way to add granularity to its access policy by linking an identity to specific tags. AWS is constantly improving the public cloud. They provide lots of security tools, such as AWS Config, CloudWatch, CloudTrail, GuardDuty, Macie, and Security Hub, just to name a few. AWS gives organizations a good base for their security needs.

Another feature is that AWS allows policies to be created to restrict commands to regions within the cloud. Features like that give an organization the kinds of levers it may require to manage the laundry list of rules needed to manage an identity-based security environment.

Also, AWS allows users to put projects or workloads in separate accounts, which creates boundaries that can limit the blast radius of any data breach.

It’s important to understand that some AWS features, like Elastic Compute Cloud (EC2) and Simple Cloud Storage Service (S3), support other features in Amazon. That can affect a user’s security posture on the service. For example, a user may believe they’ve blocked off all direct Internet access to their data, but exposure may still exist through EC2 or S3 APIs.

AWS differs from some of its competitors by locating all an organization’s access rules in a central repository. That can make it very difficult to determine from within a resource what identities — whether they be people or non-people identities — have access to that resource. In addition, there can be secondary resource policies that can actually override what’s going on in an identity policy. All that creates complexity that makes it difficult to look at a resource and know who or what has access to it.

Considerations to Keep in Mind

A big plus of AWS is its ability to assign roles to entities. It allows a strong identity and access policy to be imposed on things like serverless functions, containers, or workloads. It helps developers avoid bad practices, such as embedding credentials where they shouldn’t be embedded.

On the downside, it can be hard to find things in a user’s cloud because there’s no central view. That can create complexity. Something as common as finding an account linked to an access key in a service can be a chore.

Naming patterns in permissions and actions in AWS can also be puzzling. Finding consistency in the patterns can be complicated.

Consistency in the handling of resource statements can also be challenging. Resource statements can be used to restrict access to a resource.

For example, in S3 there are many buckets, there might be a directory of security log information, as well as one with credit card information. A resource statement could be used in a security control to make sure identities with access to the security log data don’t have access to the credit card data.

The problem is that not all resources in AWS support resource statements, which can lead to overprivileged access. To address that problem, users often create more and more accounts, which can add complexity to managing their AWS environment.

In a similar vein, there are inconsistencies in the implementation of regions. Some security tools work in some regions but not others. In addition, some services aren’t supported in all regions. What’s more, resources can be lost by putting them in a region where they’re unsupported.

Nevertheless, an organization still needs to figure out how to make those levers work. AWS helps users do that with some excellent documentation, clear examples, and consistent development of AWS.

There is a lot to consider when creating an identity-based security environment in a public cloud. In a “Zero Trust” world, anyone or anything that accesses data needs to be authenticated continually. By understanding the limitations of each of the public cloud platforms, you can better maintain a Zero Trust environment, implement best practices, and choose the right technology for your environment.

Sonrai Security Can Help

If your organization has implemented AWS and you are not sure where you risks maybe, Sonrai Security can help. We deliver an enterprise security platform focused on identity and data protection inside public clouds. We show you all the ways data has been accessed and can be accessed in the future. Our platform delivers a complete risk model of all these identity and data relationships, including activity and movement across cloud accounts, cloud providers, and third-party data stores.

We help organizations understand and monitor IAM configuration, helping to eliminate weak or accidental configurations that, if left unchecked, will inevitably lead to a disaster. Core to the platform is the collection and analysis of a broad range of API and log data, which now includes findings from the AWS IAM Access Analyzer, which quickly finds potential risk to critical data stored in a public cloud.