For any service you write, you’ll need third-party libraries. It would be very hard to build everything yourself from scratch. That’s why there are so many libraries and packages you can include in your projects to reduce your work and get things done. As you start writing services that are constantly growing, you’ll want to delegate as much boilerplate as possible to ready-to-use libraries so you can focus on the business logic that is crucial to your business.

But when you’re including tens of such third-party libraries in your project, you can’t always be sure that they’re doing only what they say they are. For example, you might include a library to send out emails to all your registered users. The email library you choose tells you that it only sends an email to the recipient that you mention. But behind the scenes, it could actually be collecting all those email addresses to sell them to the highest bidder.

There could also be more serious issues when you use third-party libraries. Suppose you have a serverless setup on Amazon Web Services (AWS) and you use Lambda functions for most of your computer needs and S3 for all your storage needs. There could be a Lambda function in your architecture that reads files from an S3 bucket and performs some type of operations.

When you’re talking about serverless or AWS services, IAM is mandatory and crucial for access management, but you should be careful with the access you provide for your roles. For example, for your Lambda function, you give read access to the bucket where your files are stored. But how can you be sure that the third-party libraries you use in your Lambda function read only the files they’re supposed to read and keep their hands off other files in the bucket?

IAM roles and privileges become very crucial here. Even though you are sure that you’re not doing anything suspicious in your code, you can’t guarantee the same for all the third-party libraries you are using. So when you’re configuring roles and privileges for your Lambda functions, you need to be extra careful about what is allowed and what is not.

Also, as your business grows and you start collecting data, you need to make sure that you’re protecting the data and following all compliance standards. When you’re storing your users’ personal information, financial or medical records, there could be legal implications if the data you hold is compromised. That means that compliance should always be your top priority.

Compliance Standards

Most countries have their own compliance standards, and all of these standards hold the company collecting and storing the data responsible for any kind of data breach, which is perfectly logical. When a data breach takes place, companies have to go through very demanding legal proceedings, including possibly lawsuits.

Even if it wasn’t your code that was responsible for the breach but a third party-library, you will be held responsible for not finding and fixing it. When you’re working with user data, you can never be confident enough.

Restricting Access to Resources Using IAM Roles

How do you make sure your Lambda function or any other service in your architecture does not have too much access to data? The answer is IAM roles. AWS gives you a very easy way of providing or restricting access to data and resources.

If you’re new to AWS and IAM roles, it can be very difficult to understand how IAM works and how to configure it. Giving complete access to resources is very easy and tempting, but it’s never a good idea. For example, if you are configuring access to DynamoDB, you should make sure you’re not giving write and read access to all of DynamoDB. If you want to write to a table, you should give only write access, not even read access, to that table and that table only.

This is called the principle of least privilege, which states that a Lambda function or any other service should be given the least amount of privileges required for it to complete the task. With the DynamoDB example, if your Lambda function writes only to a DynamoDB table, write access to that one table is all that it needs to complete its task.

This applies not only to Lambda functions, but to all resources in AWS. This is one way to guarantee there are no excess privileges, but it’s not always the best and most feasible way of handling privileges. For example, if your Lambda function is updated and now needs to read data from another DynamoDB table, you’ll have to make sure the privileges are also updated in the IAM console. As the requirements change, it becomes difficult to constantly change privileges in IAM.

Also, when there’s a team working on the same functionality or feature in a project, it will be a challenge to make sure this principle is always maintained, so you’ll want to monitor what is happening from outside of AWS.

This is where Thundra’s security and compliance monitoring comes into the picture. With Thundra, you can see what resources your code is accessing and how frequently. Even with restrictions, though, it quickly becomes very complex and cumbersome to make sure there is nothing funny happening in your architecture. For that, you’ll need something more advanced. You’ll need the power of denylist and allowlist for access to resources. Thundra’s security and compliance features can help.

Thundra’s Security Features

With Thundra’s Architecture view, you can easily see what resources your Lambda functions are accessing. You can fine tune this access in the Security tab of your Lambda’s details page. The screenshot below shows the control to configure these security settings.

Figure 1: Lambda function’s security tab

Click the “Configure your Security Settings” link to open the security settings. As you can see from the image below, you can allow or block access to certain resources in Thundra using the denylist or allowlist options.

Figure 2: Thundra’s security configuration options

From this page, select either deny or allow and click the Next button to move to the next page, shown in Figure 3, which lets you add allowlist or denylist resources based on the selection you made in the previous section.

Figure 3: Thundra’s allowlist resources options

Once you’ve selected all the resources, you can choose whether to allow or block access to them. Because you will have configured Thundra’s layer in your Lambda function, Thundra will be able to either allow or block all these access requests to the listed resources.

It doesn’t end there. Thundra can also notify you that there was an attempt to access the listed resources. You have the option to be notified whenever there was an access request, whether it was allowed or blocked. This means you can always be sure that access is controlled and that you’ll be made aware of any access attempts.

Updating Access When Required

With these security features, you can be sure that your services are not accessing resources they aren’t supposed to. This greatly reduces the chances of a data breach and gives you assurance that your compliance is on track.

But this in no way means that your job is over. Whenever there’s a change in requirements—for example, if your Lambda function needs to read or write from a new DynamoDB table—you’ll need to come back to Thundra and allow or block access to that new table. Otherwise, the Lambda function might not work as expected.

Thundra + IAM = Better Security and Control

Even after configuring access to roles in IAM, you may not be able to get a clear picture of all the resources your architecture is accessing. Integrating the Thundra layer into your Lambda functions not only makes it easy to visualize your architecture, but tells you clearly which Lambda function has what kind of access to which resource. And with this information, you can easily take control of resource access for a more secure and compliant environment.