AWS Business Intelligence Blog

Secure data in Amazon QuickSight with VPC endpoints powered by AWS PrivateLink

Amazon QuickSight is a fully managed, cloud-centered business intelligence (BI) service that you can use to connect to your data and create interactive dashboards that can be shared with tens of thousands of users. You can use these dashboards within QuickSight or embedded in software as a service (SaaS) applications.

AWS PrivateLink interface VPC endpoints provide private connectivity between a QuickSight website, VPCs, or on-premises networks without exposing traffic to the public internet. Traffic between the VPC and the website doesn’t leave the Amazon network, and all communication between the VPC and the website is kept private within AWS, making sure the data in QuickSight is kept secure. Administrators can also use VPC endpoint policies to restrict access to QuickSight accounts that are not authorized on their network.

In this post, we show how to establish end-to-end private connectivity from users on premises to a QuickSight website using VPC endpoints and AWS Direct Connect.

Use case overview

AnyFinancial institution is a fictitious organization in the financial services space that operates a highly sensitive banking application on AWS. To enhance security and data privacy, AnyFinancial decides to implement interface VPC endpoints for QuickSight. By setting up the VPC endpoint, AnyFinancial makes sure all traffic between their VPC and the QuickSight website occurs securely within the AWS network. This reduces the risk of unauthorized access to data in QuickSight by restricting all traffic except through the VPC endpoint.

Additionally, AnyFinancial can use VPC endpoint policies to implement more granular access control to further enhance their security posture and aid in regulatory compliance. For example, each endpoint can be restricted to only allow access to specific QuickSight accounts, or accounts under a specific AWS organization.

Solution overview

To set up interface VPC endpoints with QuickSight, administrators must do the following:

  1. Create an interface VPC endpoint to QuickSight.
  2. Establish DNS entries to route QuickSight website web requests to the new VPC endpoint.
  3. Make sure end-user browsers resolve using those DNS entries and route their traffic into the VPC such that it can traverse the VPC endpoint.

The following high-level architecture shows how end-user traffic is communicated to the QuickSight website through a VPC endpoint.

The data flow includes the following steps:

  1. The end-user opens quicksight.thinkwithwp.com.
  2. The corporate DNS conditionally forwards a lookup to the Amazon Route 53 inbound resolver endpoint.
  3. The DNS lookup query and response is communicated privately through Direct Connect.
  4. The browser begins HTTPS with QuickSight as resolved to the address of the QuickSight website VPC interface endpoint and the corporate router sends traffic over Direct Connect.
  5. Traffic enters the QuickSight website VPC endpoint.
  6. The VPC endpoint communicates traffic to AWS managed QuickSight website servers.
  7. The browser renders the QuickSight website and requests JavaScript, CSS, and other static assets stored on Amazon CloudFront through the public internet.

Prerequisites

Refer to Prerequisites for information about the prerequisite steps to create a VPC endpoint.

Create a QuickSight VPC endpoint

VPC endpoints are created within a VPC. To create a VPC endpoint, first create or identify a VPC in your AWS account (as mentioned in the prerequisites). VPCs and VPC endpoints are AWS Region-specific, so be sure to use the Region that your end-user browser traffic will be routed through.

Refer to the following example for steps to create a VPC endpoint.

Choose the subnets that your end-user browser traffic will route through, and choose a security group that allows inbound IPv4 and/or IPv6 to port 443 for HTTPS traffic. The private DNS created by the VPC endpoint will be for quicksight-website.<region>.amazonaws.com, but QuickSight website URLs are in the format <region>.quicksight.thinkwithwp.com, so you need to create a private hosted zone and add DNS entries separately for it.

Optionally, you can add a custom VPC endpoint policy to your endpoint. This allows you to restrict usage of the endpoint to specific QuickSight accounts (or accounts under specific AWS organizations). In this case, the account IDs that are allow listed (or deny listed) are those that your end-users will actually sign in with when they visit the QuickSight website in their browser (through the VPC endpoint). The following screenshot shows how to add the custom policy while creating the VPC endpoint for QuickSight.

The following is a sample custom policy JSON:

{
 	"Version": "2012-10-17",
         "Statement": [
 			{
				"Effect": "Allow",
 				"Principal": "*",
 				"Action": "*",
 				"Resource": "*",
 				"Condition": {
 				"StringEquals": {
 				"aws:PrincipalAccount": [ 
					"012345678901" 
				]
 			}
 		}
 	}
 ]
}

Create DNS entries

End-user browsers must resolve the QuickSight domain (quicksight.thinkwithwp.com) to the VPC endpoint that you created. When an end-user accesses QuickSight from their browser, the browser sends its requests through the VPC endpoint rather than the public internet. If you’re using Route 53 for DNS, you can configure A and AAAA records as demonstrated in the following example.

Restrict QuickSight website access

Now that you have created a VPC endpoint for QuickSight and added the required DNS entries, you can restrict traffic to flow through the VPC endpoint. This prevents access to your QuickSight account from general internet users, further securing the account.

  1. On the QuickSight console, choose the user profile and choose Manage QuickSight.
  2. Choose Security & permissions.
  3. In the IP and VPC endpoint restrictions section, choose Manage.
  4. Turn on Enforce restrictions to turn on your VPC endpoint restrictions.

This needs to be done by a user with AWS Identity and Access Management (IAM) permissions.

Refer to the following example to enable restrictions on the QuickSight console.

There are two options to restrict access:

  • VPC endpoint ID – If you want to restrict access so that only traffic through VPC endpoints is permitted, you must use VPC endpoint IDs.
  • VPC ID – If you want to restrict access so that only traffic from specific VPCs is permitted, you can use VPC IDs. However, this will allow access from any networking path from the VPC and isn’t as specific and secure.

For this post, we use the VPC endpoint ID option.

In addition to implementing restrictions from the QuickSight administration console, you can enable VPC restriction programmatically using the AWS Command Line Interface (AWS CLI).

The following is a sample AWS CLI command for enabling VPC restrictions:

aws quicksight update-ip-restriction —aws-account-id 12345678999 —region us-east-1 --enabled --vpc-id-restriction-rule-map vpc-012345678abcd999=MyVpcAllowed

The following is a sample AWS CLI command for disabling VPC restrictions:

aws quicksight update-ip-restriction —aws-account-id 12345678999 —region us-east-1 —no-enabled --vpc-id-restriction-rule-map vpc-012345678abcd999=MyVpcAllowed

Test the VPC endpoint for QuickSight

After you enable the VPC restrictions, you can test it by launching an Amazon Elastic Compute Cloud (Amazon EC2) instance that is part of the same VPC and accessing QuickSight from that instance.

The following screenshot shows QuickSight being accessed from a machine within a VPC.

In the following example, you can see the same user trying to access the same QuickSight account outside of the VPC, and access is denied.

Considerations for QuickSight VPC endpoints

The following are considerations when using QuickSight VPC endpoints:

  • VPC endpoints are supported for QuickSight websites, but as of this writing, VPC endpoints for QuickSight public APIs are not supported.
  • QuickSight supports data sources such as Amazon Relational Database Service (Amazon RDS) and self-managed databases on Amazon EC2, which access data in your AWS accounts and make it consumable through the QuickSight website. You need to create data source VPC connections for these services separately if you want to secure traffic from these data sources to QuickSight through a VPC.
  • To access certain administration features of QuickSight, you need to sign in with IAM permissions. If you are signing in to the AWS Management Console through a VPC endpoint, you need configure your VPC endpoints.
  • To access QuickSight content stored in Amazon Simple Storage Service (Amazon S3), such as paginated report PDF downloads, through a VPC endpoint, you need a rule that directs all Amazon S3 traffic over the endpoint. The rule needs to apply to all S3 buckets because there is no predefined set of S3 buckets for QuickSight.
  • Access to CloudFront via the internet is required to get static assets.
  • QuickSight allows you to make your dashboards visible to the public (anyone on the internet) directly and through embedding. See Turning on public access to visuals and dashboards with a 1-click embed code for more information. If you restrict traffic to the QuickSight website to only the VPC endpoint, public sharing will not be truly public because VPC endpoint rules precede all other rules.

Conclusion

With this launch, administrators can enhance the security of their QuickSight deployment. Additional security configurations such as endpoint policies further secure data and QuickSight resources. For more information on securing traffic between your data sources and QuickSight, see Connecting to a VPC with Amazon QuickSight.

Get started by implementing VPC endpoints for Amazon QuickSight!

About the authors

Ashok Dasineni is a Solutions Architect for Amazon QuickSight. Before joining AWS, Ashok worked with clients and organizations in Banking and financial domain, focusing on fraud research and prevention. He designed and implemented innovative solutions to improve business process, reduce cost and increase revenue, enabling companies around the world to achieve their highest potential through data.

Camille Taylor is a Sr. Technical Product Manager focused on Amazon QuickSight administration, identity management, and governance at AWS. Her career has been focused on helping Fortune 500 companies derive value from their data and scale adoption of their business intelligence investments across industries.

Karthik Tharmarajan is a Senior Specialist Solutions Architect for Amazon QuickSight. Karthik has over 15 years of experience implementing enterprise BI solutions and specializes in integration of BI solutions with business applications and enabling data-driven decisions.

Scott is a Senior Specialist Solutions Architect for Networking at AWS. Scott loves to code in his spare working hours to solve unique problems. When not working, Scott is often found either in the desert outside of Las Vegas off-roading or occasionally playing in poker tournaments.