Disaster Recovery — locality-restricted workloads on GCP

[ronakagrawal]

At Google Cloud, the privacy and security of customer data underpins the design of all of the services that we offer. We recognise that our global customers have specific concerns based on their regional and industry-specific requirements. This blog discusses how you can use Google Cloud to architect for disaster recovery (DR) to meet location-specific requirements. For some regulated industries, workloads must adhere to these requirements. In this scenario, one or more of the following requirements apply:

• Data at rest must be restricted to a specified country.
• Data must be processed in the country where it resides.
• Workloads are accessible only from predefined locations.
• Data must be encrypted by using keys that the customer manages.

Terminology

Before you begin architecting for DR for locality-restricted workloads, it’s a good idea to review locality terminology used in Google Cloud.

Google Cloud provides services in regions throughout the Americas, Europe and the Middle East, and Asia Pacific. Regions are further divided into zones where you deploy certain Google Cloud resources like virtual machines, Kubernetes clusters, or Cloud SQL databases. Resources on Google Cloud are multi-regional, regional, or zonal.

The different types of resources on GCP are:

• Multi-regional resources are designed to be redundant and distributed in and across regions. Multi-regional resources are resilient to the failure of a single region.
• Regional resources are redundantly deployed across multiple zones in a region, and are resilient to the failure of a zone within the region.
• Zonal resources operate in a single zone. If a zone becomes unavailable, all zonal resources in that zone are unavailable until service is restored. Consider a zone as a single-failure domain.

Planning for DR for locality-restricted workloads

Define your locality requirements

1. Where is the data at rest? The answer dictates what services you can use and the high availability (HA) and DR methods you can employ to achieve your RTO/RPO values
2. Can you use encryption techniques to mitigate the requirement? If you are able to mitigate locality requirements by employing encryption techniques using Cloud External Key Manager and Cloud Key Management Service, you can use multi-regional and dual-regional services and follow the standard HA/DR techniques.
3. Can data be processed outside of where it rests? You can use products such as Anthos to provide a hybrid environment to address your requirements or implement product-specific controls such as load-balancing Compute Engine instances across multiple zones in a region. Use the Organization policy Resource Location constraint to restrict where resources can be deployed. Configure a VPC Security Controls perimeter to control who can access the data and to restrict what resources can process the data.
4. Do you need to restrict who can access your application? Google Cloud has several products and features that help you restrict who can access your applications:

• Identity-Aware Proxy (IAP). Verifies a user’s identity and then determines whether that user should be permitted to access an application.
• Product-specific locality controls. Refer to each product you want to use in your architecture for appropriate locality constraints. For example, use Anthos configuration manager to apply locality-specific policies to your Anthos-managed GKE clusters. If you’re using Cloud Storage, create buckets in specified regions.

At Google Cloud, we understand that data residency, operational transparency, and privacy on Google Cloud are top of mind for our customers, and we are committed to offering the tools to meet these critical needs and preferences, while setting up locality restricted workloads on GCP.

Data storage & data access

Google Cloud provides you with the ability to control where your data is stored. Our compute and storage services allow you to store customer data in regions. When you choose to configure resources in these locations, Google will store that customer data at rest only in the selected region.

Google Cloud offers Organization Policy constraints, which can be applied at the organization, folder, or project level. You can limit the physical location of a new resource with the Organization Policy Service resource locations constraint. When coupled with Cloud IAM configuration, which helps you to define fine-grained access policies and precisely control access to Google Cloud hosted data, you can prevent your employees from accidentally storing customer data in the wrong Google Cloud region.

Google Cloud also provides you with the ability to control the network locations from which users can access data by using VPC Service Controls. Using VPC Service Controls, you create a service perimeter which defines the virtual boundaries from which a service can be accessed, preventing customer data from being moved outside of those boundaries. It also helps mitigate risks such as the misconfiguration of employee access controls or attackers taking advantage of compromised accounts.

Encryption key management

For many operations, you may want to transfer your data between GCP’s regions. Google Cloud enables encryption in transit by default to encrypt inter-region traffic that is outside the perimeter of Google’s facilities. Google Cloud applies encryption at rest by default. To gain more control over how data is encrypted at rest, Google Cloud customers can use our Cloud Key Management Service (Cloud KMS) to generate, use, rotate, and destroy encryption keys according to the customers’ own policies, a control we refer to as customer-managed encryption keys (CMEK). If you are using Cloud KMS, your cryptographic keys must be stored in the region where you deploy the resource. You can also choose to store your keys in the region you choose with our Cloud Hardware Security Module (HSM) service, which allows customers to host encryption keys and perform cryptographic operations in FIPS 140–2 Level 3 certified HSMs. Customers can also implement Customer Supplied Encryption Keys (CSEK) for supported services so that GCP encrypts data with customer-supplied keys and purges the supplied keys from memory after the customer requested operation is complete.

Cloud administrator access

On GCP, you can configure Cloud IAM permissions to limit access by your own administrators, curating the right amount of access at the project, folder or dataset level. This includes an extensive list of permissions and the predefined roles that grant them. You can also create your own custom roles that contain exactly the permissions you specify.

Compliance controls and support

Since our customers and regulators expect independent verification of security, privacy, and compliance controls, so Google Cloud undergoes several independent third party audits on a regular basis to provide this assurance.

Some of the key international and European standards we are audited against are:

• ISO/IEC 27001 (Information Security Management)
• ISO/IEC 27017 (Cloud Security)
• ISO/IEC 27018 (Cloud Privacy)
• SOC 240 and SOC 341 reports

We also understand that regulations such as GDPR place significant emphasis on enterprises knowing how their data is being processed, who has access to data, and how security incidents will be managed. It’s important to note that GDPR compliance is a shared responsibility. Google Cloud generally acts as a data processor of customer data, and as a data processor we process that data only as instructed by you — our customers. In turn, you own your data, and Google Cloud is committed to providing you with tools and resources that put you in control of your data.

Conclusion

At Google Cloud, we work hard to earn and maintain your trust by giving you a clear and detailed understanding of our process and approach to security. We continue to invest in data privacy and security innovations to anticipate the future needs of our customers so that they can move to Google Cloud today knowing that they are fortified for the future.