Sensitive data is a reality of the current landscape of technology. Whether a business handles credit cards or payment information, confidential user or patient data or even inventory information, the need to make sure certain privileged data is appropriately protected is ever-present. Certain industry standards, such as HIPAA in the USA and PCI actually enforce and uphold such practices in order to protect users from misuse of their information. Therefore, as a business offering services that may require gathering and storing sensitive data, it is also very important that the technical implementations behind these solutions are sound, even when dealing with environments deployed to the cloud.
One solution for securing private data in the AWS ecosystem is making sure that any APIs and databases that interact with and store such data are protected using a VPC. Perhaps it is important to note at this point that AWS is in fact HIPAA compliant in terms of infrastructure, but this can be undermined with misuse or incorrect setup at the customer implementation level.
Let us consider a situation in which a business has a card payment provider component. This implies the necessity of storing both credit card information but also transaction and audit data in order to ensure traceability of transactions in the future. While transaction data can be saved with only an identifier of the card data, the data itself must be secured and access to it must be appropriately restricted and monitored.
Solution outline
A prerequisite for the setup will be a Virtual Private Cloud with a public and a private subnet. The Public subnet is necessary for any services or instances that need to communicate via the Internet and the private one will ensure that any instances we place there are only accesible from inside our VPC. We can further restrict this access by using network ACLs and security groups.
AWS offers us the option of creating Private REST APIs by using the API Gateway service. Private API can only be accessed from a Virtual Private Cloud and this is done by using an Interface VPC Endpoint. This endpoint will sit in the private subnet, so that only instances in the VPC can have access to it.
To make the whole setup useful, we will also need a public facing API that ingests the private data from the user and then sends them securely to the Private API. This API will sit in the public subnet as shown in the diagram below.
Solution deep-dive
1. VPC setup
Creating a VPC is a simple task, we only need to specify a CIDR block for the internal IP range that we want out network to support. There are considerations here about how many subnets and the number of hosts that are necessary for any particular solution, but there are subnet planning tools to help with that. In a real world scenario, it also makes sense to distribute the workload across multiple Availability Zones and thus create duplicate subnets for each AZ in the region. This will ensure fault tolerance if there is an outage in an AZ data center. In the name of simplicity, for this example we will just go with a single public and a single private subnet.
Another thing to keep in mind at this stage is to enable the DNS hostnames option to make it easier for instances inside the VPC to call the private API.
2. VPC Endpoint setup
In order to enable communication to our Private API, we will need to set up an Interface VPC Endpoint inside the VPC, making sure to set it up in the private subnet we’ve set up in the previous step. We will also need to choose the AWS service that will allow us to access our Private API, and in the case of API Gateway the service is execute-api.
3. Private API setup
The next step is to create our Private API using API Gateway and here we will be using the Endpoint set up in the previous step. This will allow our otherwise isolated API to be accessible from the private subnet.
Once we’ve built and deployed our REST API we need to ensure that the Endpoint can call our API via a Resource Policy. This can be specified as broad or narrow as needed, the example below showing access to all resources and methods on our API. We can also grant access to only some resources or methods by replacing the wildcard for the resource with our desired path.
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-west-1:<account_id>: <api_id>/<stage_name>/*"
}
]
}
Now we should have a functional Private API accessible only inside our VPC via the Endpoint interface. Since we have taken care to enable Private DNS in the VPC setup step, we can use the URL generated when we deploy the API to a stage for calls from the Public API.
This setup can be further enhanced and protected via specific and restrictive security groups or network ACLs and of course the use of appropriate authentication and authorisation on the API level itself. Care should also be used when it comes to logging – it’s no use creating a bullet-proof setup if our applications log sensitive data.
Pricing considerations
A valid concern that may appear when implementing this type of solution with a cloud provider is of course, pricing. There are no costs inferred from the use of the VPC itself, this and the subnets created are completely free. The VPC Endpoint however will result in some costs based on the number of hours it is used and the amount of data processed, but even with five million API calls a month the costs are around the 25$ mark according to AWS private API pricing examples.
Conclusion
Sensitive data is and will continue to be a hot-button topic for users and reassuring clients of the safety of their private information is a necessity. Fortunately, cloud providers do have robust solutions to cover such business scenarios at a reasonable price, so it is entirely within reach to offer secure solutions for areas such as finance or healthcare whenever the business requires it.
About Iulia Dormenco
Iulia Dormenco has been a .NET developer for 8 years, with an interest in testing, quality and lately cloud service providers, especially AWS. Her desire to balance out soft and technical skills has led her to explore mentorship and Scrum master roles, while keeping a firm foothold in developing projects in areas such as insurance, fintech and healthcare.
