0

I’m reviewing a design where the architect has proposed a solution with API Gateway, Lambda and DynamoDB. The security team representative is complaining that our data (Dynamo DB) should be protected in a subnet that is not accessible to the public. The developer is stating that this is not necessary and that this can be accomplished with AWS IAM. Where can we find guidance on this type of scenario. This is a new initiative and we want to protect our assets in a cost effective manner.

  • This is probably going to be too Opinion Based for general Stack Overflow - however, in general: Subnets are needed for controlling access to server based apps - such as SQL tables or other things hosted on EC2 Instances. for all Serverless based resources (Lambda, Dynamo, ect) IAM roles will suffice just fine *as long as they are properly Least Needed* - if the roles are properly locked down with Principles and Resources, it is not possible for an outside source to access them. A resource policy on the dynamo that explicit denies to anything NOT a given arn is secure. – lynkfox Aug 17 '22 at 13:03
  • TO give your security team something: https://dynobase.dev/dynamodb-vpc/#:~:text=Frequently%20Asked%20Questions&text=DynamoDB%20is%20located%20outside%20the,is%20in%20a%20private%20subnet. or https://stackoverflow.com/questions/54870838/why-use-a-vpc-with-aws-lambda-or-aws-dynamodb – lynkfox Aug 17 '22 at 13:04
  • @lynkfox DynamoDB tables don't allow resource policies so you cannot "explicit denies to anything NOT a given arn", if I understand what you mean by that. – jarmod Aug 17 '22 at 14:48
  • This *might* be on-topic for [SoftwareEngineering.SE] or [ServerFault](//ServerFault.com). – outis Aug 18 '22 at 03:00

1 Answers1

1

A couple of key things to understand here:

  1. DynamoDB cannot be deployed into a VPC. DynamoDB is a managed, global NoSQL database service. It is not like an Amazon RDS database instance which is essentially a small cluster of VMs (actually EC2 instances), running standalone database software (e.g. MySQL), that you can configure to run in a VPC.

  2. DynamoDB doesn't support resource-based policies. Some AWS resources do allow you to configure a policy on that resource restricting where access originates from. For example, access can be restricted to traffic originating in a specific VPC. S3 buckets are an example where this is possible (where access is controlled by S3 bucket policy and access may only originate from a specific VPC via a VPC Endpoint). You cannot apply a resource policy on a DynamoDB table that restricts where access originates from.

DynamoDB table access is controlled through authentication (API request signing with valid AWS credentials) and through authorization (IAM policies in effect for the given IAM principal making the API call).

Many of the most highly-sensitive applications running on AWS utilize DynamoDB and their compliance teams leverage the various AWS security guidance and compliance accreditations and their development teams implement best security practices.

If your compliance requirements mandate that all traffic between your application and the DynamoDB service occur over a non-public network route, then you can do that with a VPC Endpoint. This does not in any way restrict other valid, authenticated clients from accessing the DynamoDB table from outside of that VPC, however. The solution to that problem is to restrict access to AWS credentials.

You can read more at Security and compliance in Amazon DynamoDB.

jarmod
  • 71,565
  • 16
  • 115
  • 122