To preserve Google Workspace Migrate data security and privacy, we design and build our infrastructure to operate securely. Here’s how we help keep your data protected during a Google Workspace migration.
Architecture layout | Data governance | Access requirements & configuration
Architecture layout
The Google Workspace Migrate platform uses multiple asynchronous migration pipelines to achieve maximum throughput during migrations. To increase performance, the Google Workspace Migrate platform can be deployed across several migration servers that are managed and secured from a central location. Each server connects to the other migration servers from within the same network and in close physical proximity.
Data flow
All connections outside of Google Workspace Migrate are secure when migrating from and to remote APIs, like Google Drive. During a migration, the Google Workspace Migrate platform writes information to 2 databases: MySQL and CouchDB. While some metadata is stored in databases, the contents of the binary objects being migrated is never retained.
Note: File data is temporarily stored locally on the nodes for upload, but is not cached in the database servers. No migration data blobs are stored or cached.
Ports
Google Workspace Migrate uses the following ports during a migration:
- 3306—The default port for the MySQL database.
- 5131—Sets the callback address nodes that communicate with the Google Workspace Migrate platform.
- 5984—The default port for the CouchDB database.
Additionally, after you install the node servers, you can optionally set up a port with a TLS certificate. You can then use the port on the node server.
MySQL database
MySQL stores persistent configuration settings and high-level logging details. This includes:
- Mappings of all objects
- High-level connection and configuration information (accounts, connections, bridges, etc.)
- Metadata for objects, lists, and settings templates
- Scan settings, logs, and metadata
- Project user permissions and metadata
- Transaction and execution information except for detailed logging data
CouchDB database
CouchDB stores records of all user mappings and configuration information. This includes:
- List content and settings templates content
- Bridge logs and settings
- Scan settings and report data
- Detailed logging information for transactions
File systems
The platform and node file systems store the following:
- Host settings
- Database credentials
- Encryption keys
- Node association metadata
- The state within the system of each object while it’s being migrated
Encryption
The local file system and MySQL and CouchDB databases are within the scope of the encryption:
- File system and CouchDB—Uses a customer-managed encryption key (CMEK) that you establish during the setup process. For CouchDB, encryption is at the application level. For details, go to Set up the encryption key.
- MySQL—Encryption is at the storage level using MySQL's data-at-rest encryption. You set a key for the encryption during the setup process. For details on MySQL's encryption, go to 15.13 InnoDB Data-at-Rest Encryption.
Data governance
Google Workspace Migrate allows administrators to control the timing and destination of a migration. You create, set up, and control your own Google Cloud instance, which allows you to get to your cloud resources whenever you need.
Google Workspace offers strong contractual commitments regarding data ownership, data use, security, transparency, and accountability. All content you migrate into Google Workspace is yours.
To improve performance, Google Workspace Migrate logs generic telemetry data during migrations. This data includes the:
- Number and types of objects migrated
- Number of affected users and groups
- Latency and error rates
We never log personally identifiable information (PII).
Finally, there’s no advertising in Google Workspace. Google never collects or uses data from Google Workspace services for any advertising purposes. And, we do not sell your data to third parties.
For more information on Google Workspace security, review this Google Workspace security paper.
Data in transit
Securing data in transit is a high priority for Google. During a migration, your data stays on your network. Google Workspace Migrate uses TLS certificates as its cryptographic protocol. We provide you the option of setting up a TLS certificate on the Google Workspace Migrate platform and node servers.
Google Workspace Migrate has a hub and spoke design with the platform as the hub and the nodes at the ends of the spokes. On installation, the user assigns each node a security key that the platform must provide to the node to prove it can associate with it. On the first startup, the node also generates a public and private encryption key.
When the platform associates with a node, it uses these keys to negotiate a shared AES-256 key and a pair of randomized access keys specific to this association. If not properly encrypted or not prepended with the correct access key, requests to services that make up this platform/node communication channel will be rejected.
Standards, regulations, & certifications
Google Cloud provides several independent third-party standards, regulations, and certifications. These audits and certifications by accredited third-party auditors show our commitment to protecting user data. They also help verify the data protection technologies and processes Google is using.
Google Workspace has attained multiple security, privacy, and compliance control certifications including ISO 27001, ISO 27017, ISO 27018, SOC 2, and SOC 3. HIPAA and the General Data Protection Regulation are also followed for regulatory compliance.
For more information on third-party certifications, go to Compliance resource center.
Google Workspace access requirements & configuration
To perform migrations, you need a service account for the Google Workspace Migrate platform and for the Google Workspace target connection.
- Google Workspace Migrate platform—Uses a service account key to access the Admin Directory (for migration admin role management) and the Google Workspace Migrate API. This service account is responsible for authorizing access to the platform (based on your administrator role assignments) and for reporting anonymized, aggregated metrics back to Google. Learn more
- Google Workspace target connection—Requires a service account to actually migrate the data to a Google Workspace instance. It must have domain-wide delegation and be authorized with sufficient scopes of access.
Note: You don't have to create a service account for the target connection. You can use the same service account you set up for the Google Workspace Migrate platform.
Also, multiple Google OAuth API scopes must be authorized on the domain.
Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.