×
Community Blog How Alibaba Cloud InCountry Service (ACIS) Works

How Alibaba Cloud InCountry Service (ACIS) Works

In this article, we'll introduce Alibaba Cloud InCountry Service (ACIS) and how it technically resolves data residency issues that appear in the Chinese market.

By Alibaba Cloud & InCountry

Alibaba Cloud, in collaboration with InCountry, has launched a new data residency service in China - Alibaba Cloud InCountry Service (ACIS). This service lets you localize and distribute regulated and sensitive data of Chinese citizens in China within the domestic borders of this data. Now when you serve customers from China, you no longer need to worry about running afloul of any compliance laws or data regulations.

Alibaba Cloud InCountry Service (ACIS) takes the compliance burden from you and your company and lets you focus your efforts on growing your business in the Chinese market, rather than implementing all sorts of controls and technical solutions to handle and process regulated and sensitive data in a compliant manner. But how can you be sure that ACIS guarantees full compliance with local Chinese regulations? In this post, we want to give you an overview of Alibaba Cloud InCountry Service and how it technically resolves data residency issues that appear in the Chinese market.

High-level Overview of the Service

Alibaba Cloud InCountry Service uses a microservice architecture that enables the robust and reliable operation of all the service components in any circumstances. The service itself is comprised of three parts:

  1. Customer self-service part that is represented by ACIS Portal. It provides self-service for customers where they can create secure data stores, manage services, and track their record usage over time.
  2. Data localization and distribution part is represented by MidPOP. This is a secure and compliant data store bundling communication services for data exchange and routing within the data residency service.
  3. Service operation part that unites different services implementing the authentication and authorization, storing sensitive data (like encryption keys), log storage and monitoring tools, microservices for record analytics, and other services needed for its operation.

All these parts are closely interconnected to each other and allow you to design and implement comprehensive data handling scenarios. In this post, we will omit the service operation and customer self-service part and will primarily focus on the data localization and distribution part and its specifics.

MidPOP and Its Components

MidPOP is a service’s part that implements data residency services, geographically distributed across independent availability zones to ensure high availability of services regardless of potential issues in one of the areas. All applications within MidPOP operate through a load balancer that stands before them and distribute the load within the cluster.

MidPOP itself falls down into the following components:

  • Database
  • PoP API
  • REST API
  • Border

Database

At a particular moment of time, one availability zone (AZ1) runs a primary database, that ingests both read and write requests, and the other availability zone (AZ2) runs a secondary database that acts as a synchronous replica. The third availability zone (AZ3) runs a third DB node (so-called DB arbiter) that is needed for consensus management within the database cluster. If a primary database experiences intermittent availability issues, a failover to the secondary database in AZ2 will be performed. Such an approach allows you to continue work with Alibaba Cloud InCountry Service even if one DB node from the cluster stops functioning. Both databases operate as a single cluster supporting a two-phase commit which implements an error handling scenario to avoid data inconsistency issues between two databases. So any creation or update of a record is finalized only once this record is presented in both databases within the cluster. If not, such a transaction is rejected.

AZ1 and AZ2 also store database backups that are continuously captured. Besides regular backups, ACIS also creates a backup of WAL files and maintains a transaction journal for all operations performed within the service so that upon any unexpected failure, a point-in-time recovery for the system can be performed.

Alibaba Cloud InCountry Service implements only the best technics and approaches for data consistency and recoverability, so customers can always be sure that their data will not vanish or get corrupted.

PoP API

PoP API is a ‘heart’ of Alibaba Cloud InCountry Service. This component is responsible for essential data operations with the secure and compliant data store (MidPOP). It bundles an extensive set of methods implementing CRUD operations that you can perform on regulated records retained in ACIS. This application performs, manages, and routes all data requests within the service that come from other MidPOP components. PoP API implements a programmatic interface to communicate with the database cluster and query regulated records. PoP API handles records of a specific structure, but also supports attachments that you can also store in ACIS.

REST API

The REST API bundles a collection of RESTful methods to manage, control, and handle regulated data in your application through API communication. The REST API facilitates the development of web applications and lets you quickly integrate data residency services into your products and applications. The REST API utilizes AES-GCM encryption with a 256-bit AES key and a 96-bit nonce that guarantees data security at the highest level.

The REST API communicates regulated data to Alibaba Cloud InCountry Service and allows you to perform all essential operations on data records:

  • CRUD operations on data records
  • Search for specific data records
  • Manage attachments pertaining to data records
  • Execute resident functions for remote validation or calculation of regulated values

The REST API is a component that is also responsible for the business logic of SaaS integrations (like Salesforce).

Border

Border facilitates the integration of data residency services into your applications and systems. It does not require any significant development effort, as you only need to send your data to Border. It intercepts data communication requests with regulated and non-regulated data and handles them according to pre-defined redaction and unredaction rules. Regulated data is encrypted and saved to ACIS in China, and then redacted values in the tokenized format are returned to your application database without impacting regular data flows while simultaneously keeping your regulated data processed and stored locally. In the case of the unredaction flow, Border unredacts the incoming data payloads by fetching clear-text values from ACIS and then proxying them to your application.

Border besides standard tokenization, supports deterministic tokenization that allows you to produce identical tokens for the same input value, while standard tokenization will produce unique tokens all the time. Such tokenization method can be used for verifying user access without touching regulated data outside its country of origin.

Border also includes several gateways that can simplify your routine operations on objects containing regulated data, such as emails or payloads with regulated data generated by forms or monolithic app.

Email Gateway

Email Gateway allows you to both redact and unredact emails containing sensitive data in place of emails, names, and other sensitive data such as email subjects. When dealing with outgoing emails that you send from your system, Email Gateway captures such outbound emails and identifies placeholders that secure the recipients' sensitive data and swaps these placeholders with their clear-text values by pulling them from the ACIS residing in China. Once sensitive data is replaced, an email with clear-text values is routed to your SMTP server within the same country and this email is further delivered to the target recipient.

When dealing with incoming emails, Email Gateway handles inbound emails and redacts its values, such as sender, subject, email body while saving this sensitive data to Alibaba Cloud InCountry Service in China. After this Email Gateway delivers redacted emails to your system, so regulated data does not even touch your servers as it becomes fully depersonalized.

HTML Gateway

HTML Gateway integrates with your monolithic web application that generates HTML pages with regulated data on the backend. Instead of storing regulated data in your application’s database, you retain it in Alibaba Cloud InCountry Service. HTML Gateway captures the generated HTML pages outputted by your monolithic app, identifies regulated data placeholders, and swaps them with their clear-text values pulled from ACIS. The HTML structure with clear-text values is further passed to the user’s browser for rendering. So your monolithic app does not touch sensitive data, as regulated data is fully handled through HTML Gateway.

Web Form Gateway

Web Form Gateway integrates with your lead or feedback-capturing forms that deal with regulated or sensitive data. When your customers submit their contact details or issue details, Web Form Gateway captures this data, saves it to ACIS, and redacts regulated data before sending it to your application. Redacted data is processed by your application, so you can always be sure that you do not violate compliance anyhow. Clear-text values can be further fetched from Alibaba Cloud InCountry Service through REST API or Border if needed.

What’s Next?

In this post, we tried to cover the technical aspects of Alibaba Cloud InCountry Service operation. If you have any questions regarding details of its operation, please submit your questions in the comments. In the next post, we will describe the anatomy of records and their specifics that you should consider.

0 1 0
Share on

Alibaba Cloud Community

470 posts | 24 followers

You may also like

Comments